La cuisine de Gandi

Accueil > Réseaux > Quand Null0 et BGP peuvent causer problème

Quand Null0 et BGP peuvent causer problème

Prenons comme exemple une paire de système autonome (AS : autonomous systems). Sur la gauche, AS1 et AS2 sur la droite; ces deux réseaux ont une connectivité vers Internet et en même temps une relation de peering directe entre-eux. Dans les circonstances normales, le trafic réseau entre les clients d'AS1 et les serveurs dans l'AS2 vont suivre le chemin le plus court (AS-Path) qui, dans ce cas, passera par la session de peering.

Dans cet exemple, les routeurs ont des routes statiques sur null0 pour 'fixer' les préfixes qu'ils annoncent en BGP par leurs ASNs respectifs. La seule différence significative dans cette exemple entre les deux réseaux vient de la connexion mono-lien entre R2 dans l'ASN1 et le reste du réseau de l'AS1. Après tout, cela est juste un routeur de peering et il est moins critique que les routeurs de coeur de réseau ou de transit Internet, non ? Prenons le temps de regarder la situation.

Imaginons que la connectivité entre R2 et le reste du réseau derrière l'AS1 soit coupée. Les routes vers les réseaux dans l'AS2 ne seront alors vu sur Internet que par les connections de transit, comme indiqué dans les annonces BGP. Avec une configuration correcte, le trafic entre les deux réseaux devrait maintenant passé par Internet par leurs connections de transit respectifs comme indiqué par le schéma suivant :

Dans cette exemple cependant, les connections de R2 vers la session de peering entre les deux ASNs sont encore actives et de ce fait, la session BGP est encore active entre les deux. Comme R2 a "fixé" statiquement les préfixes réseaux par une route vers null0, ces préfixes sont toujours annoncés à R3 dans l'AS2.

Ainsi, le trafic des paquets de retour suivant le chemin le plus court (AS-Path) seront envoyés par R3 vers R2. Malheureusement, du fait de la coupure de connectivité entre R2 et le reste de son réseau, la destination du client est injoignable. Cela provoque donc un "trou noir" partiel causé par la coupure de connexion et amplifié par, ce qui semble semble être, un problème d'administration ou une mauvaise compréhension de la topologie du réseau au moment de la configuration.

Comment peut-on corriger ce problème ?

Il y a trois façons de diminuer l'impact de ce problème. La première méthode demande d'ajouter une connexion redondante séparée depuis R2 au reste du réseau d' AS 1 (de la même façon  qu'avec R3 et AS 2 dans les schéma au dessus. Cela réduit le risque que R2 soit isolé complètement et du coup que l'on se trouve avec black hole partiel. En fonction de la distance cela peut ajouter des frais. 

Une autre alternative pourrait être de mettre les préfixes seulement sur le core (qui normalement devrait déjà avoir une connexion redondante), et annoncer ceux là avec un protocole de routage interne comme OSPF ou IS-IS au reste des équipements extérieurs.

Si R2 perds  sa connectivité au reste du réseau de AS1, il ne reçoit plus les annonces interne pour l'ensemble des préfixes. Du fait que ces préfixes ne sont plus dans la table de routage de R2, ils ne seront plus annoncés a tout les  peers BGP. De ce fait le trafic retour de AS2 à AS1 passera par le dernier chemin restant dans l'internet en utilisant les connexions de transit.

La troisième alternative implique une configuration plus compliqué et demande un protocole interne de routage dynamique au sein de l'AS. Avec ce scénario les annonces BGP seront fonction de l'existence (ou de la non existence selon les préférences) d'un autre préfixe dans les tables de routage. Cette autre préfixe sera reçu par  le protocol interne de routage. Cela est parfois appelé comme le "BGP Conditional Route Injection". Sur les équipements Cisco, cela implique d'utiliser "advertise-maps" dans la configuration BGP et la documentation à ce sujet est disponible sur le site de Cisco.

En complément de ces méthodes, une quatrième possibilité pourrait être de lier la route statique vers null0 à un objet de suivi associé avec un agent de surveillance de la disponibilité (SLA) IP. Par exemple, le routeur peut être configuré pour vérifier régulièrement une adresse IP située ailleurs mais dans le réseau en utilisant PING ou un autre protocole. En liant cette agent de surveillance et l'objet de suivi avec la route statique vers null0, cette route ne va rester dans la table de routage que si l'agent de surveillance à un code de retour valide. (Le seuil peut-être configuré par la même occasion pour éviter des faux négatifs issus de micro-coupure ...) Si l'agent de surveillance échoue, la route est alors retirée de la table de routage et ainsi le préfixe n'est plus annoncé dans les annonces BGP.