La configuration BGP a l’aide du GRE Tunnel

Dans cet article, nous allons expliquer comment le tunnel Generic Routing Encapsulation (GRE) peut être utilisé dans la situation où les routeurs parlant BGP (Border Gateway Protocol) sont connectés via des routeurs ne parlant pas BGP.

Jetons un coup d’œil au scénario suivant:

La société A exploite les routeurs Cisco CE1, Core1 et CE2 et utilise deux fournisseurs d’accès à Internet (FAI) – ISP1 et ISP2. Le numéro de système autonome (ASN) attribué à l’entreprise est 64500, le protocole BGP étant activé sur les routeurs CE1 et CE2. Le routeur CE1 est connecté au routeur PE_ISP1 (ASN 64501) et le routeur CE2 est connecté au routeur PE_ISP2 (ASN 64502). En plus du protocole de routage BGP, le protocole Open Shortest Path First (OSPF) est également activé sur tous les routeurs de l’entreprise.

Image 1 – Topologie du réseau

Maintenant, vérifions la configuration des deux routeurs FAI.

1. La configuration des routeurs FAI

Les deux routeurs ISP comprennent la configuration BGP de base qui est nécessaire afin d’établir une session eBGP avec CE1 et CE2 dans l’AS 64500. Les FAI et les routeurs des clients se connectent à l’aide de leurs adresses IP Loopback. Par conséquent, la commande update-source Loopback0 est utilisée dans la configuration BGP. En plus de cela, afin de lancer la session eBGP, on doit configurer une route statique sur les routeurs des fournisseurs et des clients vers leurs voisins eBGP.

La commande disable-connected-check est requise à la fois sur les FAI ainsi que sur les routeurs clients. Cette commande désactive le processus de vérification de connexion pour les sessions eBGP qui sont accessibles par un seul saut mais qui sont configurées sur un interface Loopback.

La commande redistribute connected – redistribue toutes les routes connectées via le protocole BGP.

1.1. La configuration du routeur PE-ISP1

1.2. La configuration du routeur PE-ISP2

2. La configuration des routeurs clients

Les routeurs CE1 et CE2 du client sont des voisins BGP avec les routeurs des fournisseurs. De plus, les routeurs CE1 et CE2 sont configurés afin d’établir un voisinage iBGP entre eux. Afin de changer l’attribut du prochain saut de 1.1.1.4 à 1.1.1.1 pour l’annonce BGP envoyée de CE1 à CE2, on doit ajouter command neighbor 1.1.1.2 next-hop-self à la configuration BGP du routeur CE1. Sinon, le routeur CE2 n’ajoutera pas les routes avec le prochain saut 1.1.1.4 à sa table de routage car il n’a pas de route vers le réseau 1.1.1.4/32 dans sa table de routage. Une commande similaire doit être ajoutée dans la configuration BGP du CE2 pour configurer le routeur CE2 en tant que prochain saut (1.1.1.2) pour l’annonce reçue de l’ISP2 et envoyée vers CE1.

Comme mentionné auparavant, le protocole OSPF est activé sur les routeurs CE1, Core et CE2. Pour empêcher l’envoi de messages OSPF Hello vers les routeurs ISP, on doit ajouter la commande passive-interface GigabitEthernet0/0 dans la configuration du protocole OSPF.

2.1. La configuration du routeur CE1

2.2. La configuration du routeur CE2

2.3. Configuration du routeur principal (Core)

3. La configuration du tunnel GRE

Maintenant, nous allons analyser où se situe la configuration du tunnel GRE dans notre scénario. Vérifions d’abord une table de routage sur le routeur PE-ISP2.

Comme on peut le voir, le routeur PE-ISP2 a réussi à mettre tous les réseaux présents dans sa table de routage. Lorsqu’on active le débogage des paquets ICMP avec la commande debug ip icmp sur le routeur Core, on verra le message suivant.

Le message d’erreur révèle que le routeur Core ne sait pas où envoyer un paquet destiné à l’adresse IP 8.8.8.1. Ce problème a plusieurs solutions. Par exemple, on peut redistribuer les routes BGP dans le protocole OSPF sur les routeurs CE1 et CE2. Une autre solution est de configurer BGP sur le routeur Core et de l’appairer avec les routeurs CE1 et CE2. Lorsqu’on veut examiner l’utilisation du tunnel GRE dans notre scénario, on se concentre sur la deuxième option.

Le routeur CE1

Le routeur CE2

À ce stade, l’interface du tunnel est activée et nous devrions être en mesure d’effectuer un ping entre les adresses IP du tunnel. L’étape suivante est la reconfiguration de CE1 et CE2. Les routeurs seront configurés de définir une adresse IP particulière de tunnel en tant qu’attribut de saut suivant pour le NLRI (Network Layer Reachability Information) reçu dans les messages de mise à jour BGP. On va créer une route-map sur le routeur CE1 qui change l’adresse IP du prochain saut 1.1.1.1 en 192.168.1.1 pour les mises à jour envoyées vers le routeur CE2. Ensuite, on appliquera la route-map pour le voisin iBGP 1.1.1.2

Le routeur CE1

Un bref coup d’œil sur la table BGP pour la route 8.8.8.0 sur le routeur CE2 nous montre que l’interface de tunnel IP 192.168.1.1 est maintenant utilisée comme prochain saut pour la route 8.8.8.0/24.

Dans le sens inverse sur le routeur CE2, le processus est le même.

Le routeur CE2

Allons vérifier le saut suivant pour la route 9.9.9.0/24 sur le routeur CE1.

Maintenant, on pourra envoyer un ping de ISP2 à ISP1 et vice versa.

Et la sortie de la commande traceroute est la suivante:

4. Les problèmes du tunnel GRE et du MTU

La longueur maximale d’un paquet IP est de 65 535 octets. Il comprend 20 octets d’en-tête IP plus 65515 octets de charge utile. Cependant, la plus petite taille de paquet IP est normalement utilisée sur les liens en fonction du type de protocole layer 2. Cette longueur est définie par la valeur Maximum Transmission Unit (MTU). Ainsi, la valeur MTU indique la quantité de données que l’hôte d’envoi peut mettre dans un paquet.

La valeur MTU pour un lien Ethernet est de 1500 octets, sans compter l’en-tête Ethernet et du postambule. Il comprend 20 octets pour l’en-tête TCP, 20 octets pour l’en-tête IP et 1460 octets pour la charge utile. Lorsque l’interface de tunnel est créée, la valeur MTU de l’interface de tunnel est automatiquement configuré avec un MTU de 1476 octets parce qu’on doit prendre en compte les 24 octets du tunnel GRE.

Si le paquet avec une valeur MTU supérieure à 1476 octets est reçu, le routeur doit fragmenter ce paquet en petits morceaux. Ces fragments ont une valeur MTU de 1476 octets, avec laquelle ils sont envoyés dans le tunnel GRE. L’inconvénient de la fragmentation est évident : un routeur doit générer de nouveaux en-têtes et il utilise ses ressources (CPU et mémoire) ainsi que des exigences supplémentaires en matière de bande passante. De l’autre côté du tunnel GRE, le routeur réassemble les morceaux dans un paquet original de taille normale.

La valeur MTU configurée sur la route du point A au point B peut être rapidement testée avec la commande ping associée à l’option « ne pas fragmenter » et en choisissant une certaine valeur MTU.

Le message ICMP reçu sur le routeur PE-ISP1 indique qu’un routeur avec l’adresse IP 2.2.2.1 (CE1) a la valeur MTU réglée sur 1476 octets sur l’un de ses liens. Cependant, on interdit strictement la fragmentation, de sorte que la commande ping échoue.

De cette façon, il apparaît une question : Pourquoi un routeur prend-il la peine de renvoyer un message ICMP à l’hôte d’envoi?

Si l’indicateur DF (Don’t fragment) est réglé sur 1, le routeur n’est pas autorisé à fragmenter un paquet. Si le paquet contient plus que 1476 octets, le message ICMP de type 3 Destination unreachable et le code 4 Fragmentation needed sont envoyés à l’hôte expéditeur, contenant les informations sur la valeur MTU du prochain saut :1476 octets. L’hôte expéditeur prend en compte ces informations et règle la valeur MTU sur 1476 octets. Ce mécanisme, appelé Path MTU Discovery (PMTUD), est décrit dans le RFC 1191. PMTUD est supporté par les protocoles TCP et UDP et il est généralement activé sur les hôtes avec le bit DF réglé sur 1. Et c’est grâce au PMTUD que l’hôte expéditeur peut définir la valeur MTU correcte (c’est-à-dire la plus faible sur un lien) et que les paquets ne sont pas fragmentés.

Le problème survient lorsque les messages ICMP sont bloqués quelque part sur la route par un ACL. Le routeur avec une valeur MTU configurée comme inférieure à celle du paquet IP envoyé renvoie le message ICMP Destination Unreachable, Fragmentation needed à l’hôte expéditeur.
Cependant, l’hôte expéditeur ne peut pas le recevoir et ainsi prendre en compte la valeur MTU correcte. Il continue à utiliser le DF réglé sur 1 dans les en-têtes IP des paquets envoyés. En conséquence, le routeur avec la valeur MTU inférieure configurée sur le lien représente un goulot d’étranglement MTU sur la route. Et lorsqu’il n’est pas autorisé de fragmenter les paquets, la connexion échoue.

5. Le routage récursif

Le routage récursif est très certainement un problème indésirable pour un réseau. Il se produit lorsqu’un routeur essaie d’acheminer du trafic vers l’adresse de destination du tunnel à l’aide de l’interface du tunnel lui-même. Une fois que le routeur aperçoit un routage récursif, il désactive volontairement l’interface du tunnel pendant un certain laps de temps. Ensuite, l’interface du tunnel est rétabli par le routeur et le processus se répète. En conséquence, les routes OSPF et BGP de l’interface du tunnel oscillent.

Afin de simuler un routage récursif, nous allons activer le protocole OSPF sur les interfaces tunnel des routeurs CE1 et CE2.

Ensuite, on vérifie les voisins OSPF.

Il y a deux voisins OSPF présentés dans la sortie de la commande. La première adjacence OSPF est formée sur l’interface tunnel, tandis que la seconde l’est sur l’interface Gigabit Ethernet. Jusqu’ici, la table de routage du routeur CE1 ne contient aucune route récursive. Toutes les routes OSPF sont apprises via l’interface GigabitEthernet1/0.

Maintenant, nous allons vérifier le coût OSPF pour le tunnel et les interfaces Ethernet Gigabit sur le routeur CE1.

Ainsi, le protocole OSPF préfère l’interface Gigabit Ethernet à l’interface tunnel puisque son coût est de 1 par rapport au coût de 1000 qui est appliqué pour l’interface tunnel. Pour simuler un routage récursif, on va modifier le coût de l’interface tunnel à 1 sur les deux routeurs CE.

Après un certain temps, on peut voir les logs suivants.

A partir de là, l’interface tunnel et les tables de routage des routeurs CE1 et CE2 oscillent indéfiniment. Certaines routes de la table de routage de CE1 sont désormais disponibles via l’interface du tunnel.

Alors, que s’est-il passé exactement ? Nous allons l’expliquer dans l’exemple suivant.

Auparavant, nous avons activé le protocole OSPF sur l’interface de tunnel 192.168.1.1 du routeur CE1. Supposons que le CE1 envoie un message OSPF hello avec une adresse IP source 192.168.1.1 à l’adresse IP multicast OSPF 224.0.0.5. L’interface du tunnel ajoute l’en-tête GRE au paquet et l’en-tête IP extérieur avec l’adresse IP source 1.1.1.1 et l’adresse IP de destination 1.1.1.2. Ensuite, la route 1.1.1.2/32 est recherchée dans la table de routage de CE1. Cependant, la route a été apprise via l’interface tunnel. Pour cette raison, l’en-tête GRE et l’en-tête IP extérieur seraient à nouveau ajoutés au paquet GRE précédemment encapsulé. Et si le routeur CE1 n’avait pas désactivé l’interface tunnel au préalable, le processus se répéterait encore et encore.

Afin d’éviter le routage récursif, on peut augmenter le coût ospf pour l’interface tunnel à 1000 en utilisant la commande no ip ospf cost 1 sur les routeurs CE1 et CE2. Cela empêcherait les routeurs d’utiliser les routes apprises via l’interface tunnel.

Chez Noction, nous pouvons implémenter la configuration BGP à l’aide du tunnel GRE lors du déploiement de notre plate-forme de routage intelligent (IRP) dans les réseaux de certains clients. Dans des scénarios complexes spécifiques, le trafic du serveur IRP doit passer par plusieurs routeurs afin d’arriver au fournisseur. Et s’il n’est pas possible de configurer un Vlan de sondage séparé sur tous les routeurs, la solution optimale sera alors de configurer les tunnels GRE d’IRP vers les routeurs Edge.

Accéder à la version anglaise de cet article – BGP over GRE Tunnel