BHNIX - Bosnia and Herzegovina Neutral Internet Exchange
Menu
The present document describes the Technical Specifications which must be followed by ISP connecting to the BHNIX Peering LAN.
Ethernet Frame Format
Only Ethernet Version 2, 802.3 or DIX Ethernet frames are allowed on the BHNIX peering LAN.
Ethernet Data Types
The following Data Types are accepted:
0x0800 (Internet Protocol version 4, or IPv4)
0x0806 (Address Resolution Protocol, or ARP)
0x086dd (Internet Protocol version 6, or IPv6)
Maximum Transmission Unit
All Participants must explicitly set a Maximum Transmission Unit (MTU) of 9000 bytes on any interface facing the BHNIX switching platform.
Broadcast and Multicast Traffic
Broadcast or multicast traffic may not transmitted on the BHNIX switching platform except for ARP, IPv6 Neighbor Solicitation.
Proxy ARP
Peering equipment interfaces can not be configured with Proxy Arp service enabled.
Participant Port Congestion Management
Because the commonly-used five-minute average traffic statistics mask congestion-causing microbursts of traffic, Participant ports peaking above 85% average utilization within any five-minute period in any three consecutive days shall receive additional or larger BHNIX core switch ports as necessary to bring the peak utilization below the upgrade threshold, and the Participant shall be obligated to use those ports to increase interconnection bandwidth to their network at their own cost. Responsible Participants will proactively monitor traffic levels and anticipate the need for such upgrades.
MAC Address Limitation
BHNIX will turn on port security with the layer-2 MAC address connected from a single participant’s layer-3 router to the BHNIX switching platform. At any time, only one MAC address will be allowed on each BHNIX port and BHNIX participant must inform BHNIX NOC by email if there is any change or maintenance on the router MAC address.
Quarantine
Upon initial connection and subsequently if they deem necessary, the BHNIX may place a Participant’s port into a separate “quarantine” VLAN for diagnostic purposes or to verify policy-compliant operation.
Link-local protocols
Link-local protocols (excluding ARP and IPv6ND) are not allowed. A incomplete list of Link local protocols explicitly forbidden follows:
IPv6 Transport of BGP
Technically, IPv4 routes and IPv6 routes may be exchanged over IPv4 transport, IPv6 transport, or both.
Next Hop Self
In order to prevent the propagation of third-party routes, participants must set NEXT_HOP_SELF on all routes advertised through the BHNIX.
Public Autonomous System Numbers
Participants shall use public Autonomous System Numbers allocated uniquely to them by a Regional Internet Registry. Participants may not use private, reserved-range Autonomous System Numbers.
Routing Aggregation
Participants are encouraged to aggregate their IP prefix announcements into the fewest prefixes feasible, in accordance with best practices. Disaggregation for purposes of “traffic management” places a burden on peers and the rest of the network and creates a detrimental externality.
Prefixes Advertised
All IP prefixes advertised at the BHNIX must be delegated for unique use by a Regional Internet Registry, and the Participant advertising them must have the legal right to do so clearly conferred to them by the current registrant.
No Broadcast Protocols
In order to reduce unnecessary broadcast traffic, Participants must disable Interior Gateway Protocols, service discovery protocols, and other broadcast protocols toward the BHNIX. Participants must filter IP directed broadcast packets addressed to the BHNIX broadcast addresses before they reach the BHNIX peering subnets.
No Redistribution of the IXP Prefixes
Participants may not propagate the IXP IPv4 or IPv6 peering prefixes in any routing protocol. The BHNIX suggests that Participants set Next-Hop-Self towards peers within their own AS, in order to avoid having to carry the IXP prefixes as next-hops for their iBGP internal peers.
No Transit Through the Switch
While the Participants hope that the BHNIX will serve as a marketplace for diverse Internet services in BHNIX, the BHNIX switch fabric itself is a constrained and shared resource. In order to avoid a tragedy of the commons, the Participants agree to not provide IP transit service across the switch. Instead, IP transit services should be provided across other media, such as private cross-connects.