Vereisten om aan te sluiten op BNIX

• In het bezit zijn van een publiek AS-nummer zoals toegewezen door IANA.
• Gebruik maken van BGP-4 voor het opzetten van peering sessies.
• Het publieke AS-nummer gebruiken voor het opzetten van bilaterale peering en peering met de route server.
• Verkeer mag niet routinematig worden uitgewisseld tussen 2 BNIX-poorten die eigendom zijn van dezelfde BNIX participant.

Poorten, IPv4 and IPv6

Alle poorten op de BNIX public exchange infrastructure zijn van het type Ethernet en zijn beschikbaar met volgende snelheden:

• 1 Gbps (GE) - 1000BASE-LX
• 1 Gbps (GE) – 1000BASE-SX
• 1 Gbps (GE) – 1000BASE-T
• 10 Gbps (10GE) - 10GBASE-LR
• 10 Gbps (10GE) - 10GBASE-SR
• 100 Gbps (100GE) – 100GBASE-LR4

Bovendien kan BNIX GE, 10GE of 100GE-poorten samenvoegen om trunks met hogere bandbreedte te bieden. Met behulp van snelheidslimieten kunt u ook fysiek verbinding maken met een bepaalde lijnsnelheid, maar enkel betalen voor de hoeveelheid bandbreedte die u gebruikt. 

Participanten kunnen peeren met IPv4, IPv6 of beide. BNIX beveelt sterk peering aan in zowel IPv4- als IPv6.

Route server

Peering details:

rs.bruzav.bnix.net 194.53.172.1, 2001:7f8:26::a500:5406:1, AS5406

rs.brueve.bnix.net 194.53.172.2, 2001:7f8:26::a500:5406:2, AS5406

Het wordt aanbevolen om een peering met beide servers op te zetten om redundantie te garanderen.

De route server draait op de routing daemon Birdv2 en gebruikt IRRDB- en RPKI-filtering om de prefixlijst te bepalen. Het is raadzaam om te controleren of uw routeobjecten correct geconfigureerd zijn. Community strings zijn toegestaan om te beslissen aan wie u uw prefixen wilt aankondigen via de route server.

MAC Layer

Ethernet framing

De BNIX-infrastructuur is gebaseerd op de Ethernet II-standaard (of “DIX Ethernet”). Dit betekent dat LLC/SNAP inkapseling (802.2) niet is toegestaan.

Ethertypes

Frames die worden doorgestuurd naar BNIX-poorten moeten een van de volgende Ether-types hebben:

• 0x0800 - IPv4
• 0x0806 - ARP
• 0x86dd - IPv6

Een MAC-adres per poort

Frames die naar een individuele BNIX-poort worden doorgestuurd, moeten allemaal hetzelfde MAC-bestemmingsadres hebben. Een uitzondering hierop zijn de resellerpoorten.

Geen proxy ARP

Het gebruik van proxy ARP op de interface geconnecteerd op de Internet Exchange is niet toegestaan.

Alleen Unicast 

Frames die worden doorgestuurd naar BNIX-poorten mogen niet worden geadresseerd aan een multicast of broadcast MAC-bestemmingsadres, tenzij als volgt:

• broadcast ARP-pakketten
• multicast ICMPv6 Neighbour Discovery pakketten. Deze omvatten geen Router Discovery pakketten.

Geen link-local verkeer

Verkeer voor link-local protocollen mag niet worden doorgestuurd naar BNIX-poorten. Link-local protocollen omvatten, maar zijn niet beperkt tot volgende lijst:

• IRDP
• ICMP-omleidingen
• IEEE 802 Spanning Tree
• Vendor proprietary protocollen. Deze omvatten, maar zijn niet beperkt tot: - Discovery protocollen: CDP, EDP - VLAN/trunking protocollen: VTP, DTP Interior routing protocol broadcasts (e.g. OSPF, ISIS, IGRP, EIGRP)
• BOOTP/DHCP
• PIM-SM
• PIM-DM
• DVMRP
• ICMPv6 ND-RA
• UDLD
• L2 Keepalives

Volgende link-local protocollen vormen een uitzondering en zijn wel toegestaan:

• ARP
• IPv6 ND

BFD (Bidirectional Forwarding Detection)

BNIX raadt aan om BFD te configureren als mechanisme voor foutdetectie op alle BGP peering sessies, of deze nu peer-to-peer zijn of met de route servers.

BFD is een universeel keep-alive en foutdetectieprotocol dat op bijna alle communicatiemedia draait. Het maakt foutdetectie in minder dan een seconde mogelijk, als de deelnemende systemen snel genoeg zijn. Het is ontworpen als een light protocol dat autonoom kan draaien in de forwarding engine van netwerkapparatuur, onafhankelijk van de control plane.

In ons geval, kan BFD worden geconfigureerd als een extra foutdetectiemechanisme voor BGP. Elke BGP-sessie wordt verdubbeld door een specifieke BFD-sessie die draait op UDP-poorten 3784 en 3785, op dezelfde IPv4- of IPv6-adressen als de BGP-sessie zelf. Wanneer BFD een fout bij een buur detecteert, informeert het het BGP-proces dat onmiddellijk de routes van de buur terugtrekt, waardoor al te genereuze BGP-timeouts worden verkort en het onmiddellijk gebruik van een  alternatieve route mogelijk wordt.

Op BNIX moedigen we participanten aan om BFD te gebruiken voor hun peer-to-peer peering sessies. Dit zorgt voor een uiterst snelle omschakeling bij een uitval van een datapad om welke reden dan ook. Daarnaast gaan we BFD-ondersteuning aanbieden op de route servers. Zo kunnen BGP-sessies met de route servers ook met BFD beveiligd worden.

Hieronder vindt u onze huidige aanbevolen timerwaarden voor BFD:

• Interval 500ms
• Multiplier 10