These technical requirements define the ways in which Balkan-IX members may or may not make use of the Balkan-IX services.
Frames forwarded to Balkan-IX ports SHALL have one of the following EtherTypes:
-0x0800 – (Internet Protocol version 4, or IPv4)
-0x86dd – (Internet Protocol version 6, or Ipv6)
-0×0806 – (Address Resolution Protocol, or ARP)
Only one MAC address is allowed on a service port. All frames of a service forwarded to an individual Balkan-IX port shall have the same source MAC address.
It is NOT ALLOWED to use Spanning Tree Protocol enabled on a port connected to Balkan-IX.
It is NOT ALLOWED to use proxy ARP enabled on a router port connected to Balkan-IX.
Frames forwarded to Balkan-IX ports SHALL NOT be addressed to a multicast or broadcast MAC destination address except as follows:
-broadcast ARP packets
-multicast IPv6 Neighbor Discovery (ND) packets
-others, if explicitly allowed for that port (e.g. multicast service)
Traffic for link-local protocols SHALL NOT be forwarded to Balkan-IX ports except for the ARP but not proxy ARP and IPv6 ND. These link-local protocols include but are not limited to the following list:
-IEEE802 Spanning Tree
-Vendor proprietary discovery protocols. (e.g. Cisco CDP, VTP)
-Interior Routing Protocols IGP (e.g. RIP, OSPF, IS-IS, IGRP, EIGRP) /Multicast
–BOOTP / DHCP
Interfaces connected to Balkan-IX ports SHALL ONLY use IP addresses (IPv4 and IPv6) and netmasks assigned to them by Balkan-IX.
IP packets addressed to Balkan-IX Peering LAN’s directed broadcast address SHALL NOT be automatically forwarded to Balkan-IX ports.
IP address space assigned to Balkan-IX Peering LANs SHALL NOT be advertised to other networks.
IP Traffic Exchange
IP traffic should be exchanged between Balkan-IX members using BGP4 protocol by the following ways:
-by using route servers (RS) – two RSs for redundancy and resilience;
-by direct BGP4 sessions between Balkan-IX members with theirs mutual agreements.
Disabling first AS check
The Route Servers do not have their AS first in the AS_PATH. In some cases you might need to disable the first AS check in your BGP configuration.
On Cisco routers please specify ‘no bgp enforce-first-as’ or ‘bgp enforce-first-as disable’ to disable the enforcement.
Autonomous System Number (ASN)
Balkan-IX supports both 16-bit and 32-bit AS numbers.
Balkan-IX members SHOULD have public ASNs and route-objects, registered in a recognized Internet Routing Registry.
Balkan-IX members MUST use the same peering ASN at each point and must announce a consistent set of routes at each point, unless otherwise mutually agreed.
When peering with the route servers we mandate that routers are set up to connect to both route servers and advertise the same amount and length of prefixes for redundancy and resilience.
Balkan-IX generally ADVISES a maximum-prefix to be set.
Incoming Prefixes Sanitization
The Balkan-IX route servers implement very basic incoming filters for private ASNs and prefixes received from clients. Balkan-IX BLOCKs private ASNs, RFC1918 ranges, bogon prefixes and the default route.
Outgoing Prefixes Filtering Among Route Server Clients
The Balkan-IX route servers implement outgoing filtering based on policies defined by the route server participants. This filtering is applied on outgoing advertisements.
Maintain your peering policy
Peers SHOULD register and maintain proper route objects in a recognized Internet Routing Registry: ARIN, RIPE, APNIC, LACNIC or AfriNIC.
Balkan-IX member SHOULD NOT exchange traffic between ports they own from Balkan-IX infrastructure.
Balkan-IX members SHOULD aggregate theirs announced prefixes. Balkan-IX will deny all network updates with a network mask length greater than /24.
Balkan-IX members SHOULD announce only theirs own prefixes or theirs clients’ prefixes. Balkan-IX members SHOULD NOT announce prefixes from transit ASN without transit owners’ permissions.
When maximum daily traffic is over 90% of the physical port speed for the last month, Balkan-IX member is asked to increase its capacity to Balkan-IX.
Balkan-IX shall implement “shortest exit/hot potato routing” and advertise routes consistent with that policy, unless mutually agree otherwise based on special circumstances.
Only send traffic that destined for the prefixes Balkan-IX announce to you. DO NOT point default at us or use static routes to send us traffic that does not match the routes we announce to you.
Balkan-IX policies may be updated from time to time, as market and traffic conditions affecting network interconnections change. Balkan-IX reserves the right to modify, replace, or nullify policies at any time.
Route Servers Details
|Platform||Quagga B-IX||Quagga B-IX|
|Platform||Quagga B-IX||Quagga B-IX|
All peers to Balkan Internet Exchange route servers can use communities to control incoming and outgoing information.
In relation to the incoming traffic (which announces are accepted) the control is in the client – he can filter which ones of the received from RS announces he will accept.
Balkan-IX RSs remove its own AS from the route, which will make them seem directly connected without a necessary BGP session between them.
With the help of BGP Community Balkan-IX member may decide who he wants to “give” the traffic to. The following BGP Community is maintained for every announced prefix.
Communities coming from Balkan Internet Exchange RS:
|0:<peer AS>||Prefix is announced from ‘<peer AS>’|
|59900:1002||Prefix is announced from Bulgarian peer|
|59900:1003||Prefix is announced from Romanian peer|
|59900:1004||Prefix is announced from Macedonian peer|
|59900:1005||Prefix is announced from Serbian peer|
Communities that are accepted from Balkan Internet Exchange RS:
By default all incoming prefixes are announced to all Balkan-IX members, if they do not have BalkanIX specific community – 59900:.*.
|59900:0||Block Your prefix to all peers|
|59900:0 59900:||Block Your prefix to all peers EXCEPT|
|59900:||Block Your prefix to|
BGP communities for traffic management to providers:
Communities for peers with 32-bit ASNs:
Balkan-IX implements N:M filtering based on standard community strings. As standard BGP communities support only 4
bytes, this only works for 2-byte ASNs and peers with 2-byte ASNs.
Therefore, the following community format is applicable: <65000 + last octet from peer IP address>.
For BGP peers with 32-bit ASN use current table for community:
|Peer||32-bit ASN||BGP Community|
Sample client configurations for peering
Configuration example for Cisco equipment
ip prefix-list -OUT seq 5 permit x.x.x.x/xx le 24
ip prefix-list -OUT seq 10 permit x.x.x.x/xx le 24
route-map B-IX-out permit 10
match ip address prefix-list -OUT
route-map B-IX-in permit 10
set local-preference xxx
no bgp enforce-first-as
neighbor remote-as 59900
neighbor description B-IX-RS
neighbor send-community both
neighbor soft-reconfiguration inbound
neighbor route-map B-IX-in in
neighbor route-map B-IX-out out
Configuration example for Huawei equipment
ip ip-prefix -OUT index 5 permit x.x.x.x x greater-equal x less-equal 24
ip ip-prefix -OUT index 10 permit x.x.x.x x greater-equal x less-equal 24
route-policy B-IX-out permit node 10
if-match ip-prefix -OUT
route-policy B-IX-in permit node 10
apply local-preference xxx
bgp undo check-first-as
peer as-number 59900
peer description B-IX-RS
peer capability-advertise route-refresh
peer route-policy B-IX-in import
peer route-policy B-IX-out export
Configuration example for JunOS equipment
set protocols bgp group B-IX neighbor description RS-B-IX
set protocols bgp group B-IX neighbor import B-IX-IN
set protocols bgp group B-IX neighbor export B-IX-OUT
set protocols bgp group B-IX neighbor peer-as 59900
set policy-options policy-statement B-IX-IN term 1 then local-preference …
set policy-options policy-statement B-IX-IN term 1 then accept
set policy-options policy-statement B-IX-OUT term 1 from prefix-list …
set policy-options policy-statement B-IX-OUT term 1 then accept
set policy-options policy-statement B-IX-OUT term last then reject