Conditions d'adhésion au BNIX

• Être en possession d'un numéro d'AS public attribué par l'IANA.
• Utiliser BGP-4 pour la mise en place des sessions de peering.
• Utiliser le numéro d'AS public pour configurer le peering bilatéral et le peering avec le Route Serveur.
• Le trafic ne sera pas échangé de façon routinière entre deux ports BNIX appartenant au même participant BNIX.

Ports, IPv4 et IPv6

Tous les ports de l'infrastructure d'échange public du BNIX sont de type Ethernet et sont disponibles aux vitesses suivantes:

• 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

En outre, le BNIX est capable d’agréger des ports GE, 10GE ou 100GE pour fournir des lignes à bande passante plus élevée. De même, en utilisant les limites de débit, vous pouvez vous connecter physiquement à un certain débit de ligne, mais ne payer que pour la quantité de bande passante que vous utilisez.

Les participants peuvent s’échanger des informations en IPv4, IPv6 ou les deux. BNIX recommande fortement le peering avec les familles d’adresses IPv4 et IPv6.

Le Route Serveur

Détails de peering:

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

Il est conseillé de mettre en place un peering avec les deux serveurs afin de garantir la redondance.

Le Route Serveur est exécuté sur le démon de routage Birdv2 et utilise le filtrage IRRDB et RPKI afin de déterminer la liste de préfixes. Il est conseillé de vérifier si vos objets de route sont correctement configurés. Les communautés sont autorisées afin de déterminer à qui vous souhaitez annoncer vos préfixes via le Route Serveur.

Couche MAC 

Trame Ethernet 

L'infrastructure BNIX est basée sur le standard Ethernet II (ou “DIX Ethernet”). Cela signifie que l'encapsulation LLC/SNAP (802.2) n'est pas autorisée.

Ethertypes

Les trames transmises aux ports BNIX doivent avoir l'un des types Ether suivants:

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

Une adresse MAC par port

Les trames transmises à un port individuel BNIX doivent toutes avoir la même adresse MAC de destination. BNIX utilise le filtrage MAC sur le port. Il est conseillé de configurer un MAC statique pour faciliter les migrations vers un autre périphérique de couche 3.

Nous encourageons que la connexion au BNIX se termine sur un périphérique Layer3 et qu'il n'y ait pas de commutateur entre les deux.

Les exceptions sont les ports qui appartiennent à un revendeur.

Pas de proxy ARP

L'utilisation d'un proxy ARP sur l'interface du routeur vers le point d'échange n'est pas autorisée.

Unicast uniquement

Les trames transmises aux ports BNIX ne doivent pas être adressées à une adresse MAC de destination multicast ou broadcast, sauf dans les cas suivants:

• les paquets ARP Broadcast
• les paquets Multicast ICMPv6 Neighbour Discovery. Cela N'INCLUT PAS les paquets Router Discovery.

Pas de trafic lien-local

Le trafic des protocoles lien-local ne doit pas être transmis aux ports BNIX. Les protocoles lien-local comprennent, sans s'y limiter, la liste suivante:

• IRDP
• Redirections ICMP 
• IEEE 802 Spanning Tree
• Les protocoles propriétaires des vendeurs. Il s'agit, entre autres, de: - Protocoles de découverte: CDP, EDP - protocoles VLAN/trunking: VTP, DTP Les diffusions de protocoles de routage internes (p.e. OSPF, ISIS, IGRP, EIGRP)
• BOOTP/DHCP
• PIM-SM
• PIM-DM
• DVMRP
• ICMPv6 ND-RA
• UDLD
• L2 Keepalives

Les protocoles lien-local sont des exceptions et sont autorisés (mais à débit limité):

• ARP
• IPv6 ND

BFD (Bidirectional Forwarding Detection)

BNIX recommande de configurer BFD comme mécanisme de détection de défaillance sur toutes les sessions de peering BGP, que ce soit en peer-to-peer ou avec les Route Serveurs.

BFD est un protocole générique de keepalive et de détection des défaillances qui fonctionne sur presque tous les supports de communication. Il permet de détecter les défaillances en moins d'une seconde, si les systèmes participants sont suffisamment rapides. Il est conçu comme un protocole léger qui peut fonctionner de manière autonome dans le plan de commutation des dispositifs du réseau, indépendamment du plan de contrôle.

Dans notre cas, BFD peut être configuré comme un mécanisme supplémentaire de détection des défaillances pour BGP. Chaque session BGP sera doublée par une session BFD dédiée qui fonctionne sur les ports UDP 3784 et 3785, sur les mêmes adresses IPv4 ou IPv6 que la session BGP elle-même. Lorsque BFD détecte la défaillance d'un voisin, il en informe le processus BGP qui déclenche immédiatement le retrait des routes du voisin, raccourcissant ainsi les délais d'attente trop généreux de BGP et permettant l'utilisation immédiate d'une route alternative.

BNIX encourage désormais les participants à utiliser BFD sur leurs sessions de peer-to-peer. Cela permet un basculement extrêmement rapide en cas d'interruption des chemins de données pour quelque raison que ce soit. Par ailleurs, nous allons commencer à offrir le support BFD sur les Route Serveurs. Ainsi, les sessions BGP avec les Route Serveurs peuvent également être protégées avec BFD.

Voici les valeurs de temporisation que nous recommandons actuellement pour BFD:

• Intervalle 500ms
• Multiplicateur 10