Aujourd'hui et dans les jours qui viennent, je vais vous proposer trois travaux pratiques en rapport avec des technologies utilisées par les opérateurs réseaux : BGP, MPLS et L3VPN. Commençons avec BGP.
Même si ces TPs se placent dans un cadre scolaire (« bouh c'est nul, on ne fait pas comme ça en vrai ! » diront certains), j'ai trouvé ces TPs géniaux justement par leur ouverture et parce qu'ils tendent à mettre en exergue les limites auxquelles certaines méthodes utilisables dans un TP seront confrontées « dans la vraie vie ». Ils sont extrêmement formateurs. C'est ce qui m'amène à les partager avec vous accompagnés de mes pistes de réflexion.
Ceux qui aiment bidouiller autour des réseaux devraient tenter de répondre aux questions avant de regarder mes pistes de réflexion. Vous ne devriez pas être déçus.
Table des matières
Énoncé
Créez le fichiez file.net décrivant la configuration d’interconnexion des routeurs :
Topologie plus complexe.
Lancez Dynagen avec cette configuration.
Il ne reste plus qu’à se connecter sur les routeurs et à les configurer... Lors des expérimentations, gardez les résultats utiles pour le rapport (configurations, résultats de ping, traceroute, tcpdump, etc.).
Exercice 3 : Configuration de base sans politique
- Q1. Créez une configuration de 2 AS et 6 routeurs suivant le schéma ci-dessus, les routeurs internes n’utilisant pas BGP, mais un routage IGP interne : OSPF.
- Q2. Créez deux préfixes (via loopback) à annoncer sur chaque routeur interne.
- Q3. Assurez-vous que le routage interne de chaque AS fonctionne.
- Q4. Activez BGP sur les 4 routeurs inter-domaines et vérifiez que les quatre préfixes sont accessibles depuis chaque routeur BGP. Assurez vous notamment que toutes les adresses IP alloués soient joignables et justifiez vos choix d’adressage IP au niveau inter-domaine.
- Q5. Déterminez par quelles routes passent les paquets pour chaque sous-réseau. Peut-on observer des routes asymétriques ? Pourquoi ? Comment changer ça ?
- Q6. Vérifiez ce qu’il se passe quand l’un des deux liens inter-domaines est coupé (messages BGP, OSPF, ...).
- Q7. Même question si l’un des préfixes associés à une interface de loopback est désactivé.
- Q8. Reprenez votre configuration avec un des deux AS contenant 4 routeurs avec un découpage en zone. Deux d’entres eux seront dans la zone backbone et les deux autres dans deux zones tierces. Commentez alors l’échange des LSA dans cet AS.
Exercice 4 : Configuration avec politiques de routage BGP
Attention : dans cet exercice, on se considère root uniquement sur l'AS sur lequel porte la question. On ne se considère pas root sur les deux AS en même temps pour tenter de résoudre plus facilement un problème (le trafic entrant d'un AS étant le trafic sortant de l'autre 😉 ).
- Q1. L’AS2 souhaite que le trafic provenant de l’AS1 passe de préférence par le lien de gauche, mais en gardant la connectivité en cas de coupure de ce lien. Configurez le routage de l’AS2 à cette fin et vérifiez son bon fonctionnement dans tous les cas. En admettant que l’AS1 soit un AS de transit, la préférence du lien gauche ne devra s’appliquer que pour le trafic issu de l’AS1 lui-même.
- Q2. L’AS2 souhaite que le trafic qu’il dirige vers l’AS1 utilise de préférence le lien de droite. Configurez le routage de l’AS2 en conséquence.
- Q3. Pour le trafic sortant de l’AS2, peut-on préférer le lien de droite uniquement pour le trafic destiné à l’AS1 lui-même (ou réciproquement uniquement pour le trafic transitant par l’AS1) ? Si oui, comment (donnez les configurations requises) ?
- Q4. Configurez 3 préfixes dans l’AS1 (P1, P2, P3) et implantez la politique de l’AS2 : P1 doit être accessible de préférence via le lien gauche, le préfixe P2 de préférence via le lien droit, et P3 uniquement par le lien droit. Testez dans tous les cas.
- Q5. Reprendre la question 1 en utilisant la technique de l’AS prepending.
- Q6. Reprendre la question 2 en utilisant l’attribut community.
- Q7. Reprendre le TP en utilisant 2 PC (1 par AS) en faisant communiquer les dynamips des 2 PC.
Cet énoncé est extrait de celui de Jean-Jacques Pansiot et Pascal Mérindol de l'université de Strasbourg.
Pour ceux qui préfèrent lire un si gros pavé en PDF : TP réseaux d'opérateur I : BGP. Et comme à chaque fois, les sources LaTeX sont disponibles ici : sources LaTeX.
Avant de commencer
Adressage
ASN
En ce qui concerne les numéros d'AS, j'ai décidé d'en choisir deux parmi la plage d'ASN réservés à l'IANA pour la documentation : 64496-64511,65536-65551.
- AS 1 devient AS 64501
- AS 2 devient AS 64502
IPv4
Concernant l'adressage IP, j'ai décidé de choisir mes préfixes dans le préfixe réservé à l'IANA pour les tests : 198.18.0.0/15. Ayant deux réseaux à adresser, il m'a paru naturel de découper ce préfixe /15 en deux préfixes /16 de telle sorte de pouvoir attribuer un préfixe /16 à chacun de mes deux AS.
- AS 64501 reçoit l'allocation 198.18.0.0/16
- AS 64502 reçoit l'allocation 198.19.0.0/16
J'ai ensuite décidé que chacun de mes AS va découper son allocation en plusieurs préfixes de longueur /20 :
- Le premier /20 est dédié aux services que l'AS met à disposition du public.
- Le milieu est réservé pour un usage futur (expansion des services, expansion des interconnexions, ...).
- L'avant-dernier /20 est dédié aux interconnexions des routeurs internes. Il sera découpé en /31, chaque /31 étant dédié à une interconnexion.
- Le dernier /20 est dédié aux interconnexions externes (inter-AS). Il sera découpé en /31, chaque /31 étant dédié à une interconnexion.
Je ne prévois pas que mes AS aient plus de 2048 interconnexions externes ni plus 2048 interconnexions internes mais si c'était le cas, on prendrait des préfixes dans le milieu en suivant la même logique : avant-dernier préfixe pris pour les interconnexions internes, dernier préfixe pour les interconnexions externes.
Les interconnexions se font en /31 car les IPv4 sont rares et il faut donc les économiser. Même si j'utilise un préfixe de documentation/test, je fais ce choix car, d'après mes renseignements, il s'agit d'une BCP donc pourquoi ne pas s'y conformer, même sur une maquette ? De plus, cela amène des avantages (pas de broadcast, ...).
En pratique, pour l'AS 64501, ce découpage donnera :
- 198.18.0.0/20 - Services.
- 198.18.16-208.0/20 - Réservés pour un usage futur.
- 198.18.224.0/20 - Interconnexions internes.
- 198.18.240.0/20 - Interconnexions inter-AS.
Le découpage est similaire pour l'AS 64502, seul le deuxième octet des préfixes change.
Schéma
Voici le schéma donné dans l'énoncé complété avec mon plan d'adressage :
Figure 1 - Schéma de ma maquette. D'après l'énoncé.
Note : les sorties des commandes de vérification (show ...) seront allégées pour ne garder que l'essentiel afin de ne pas surcharger ce rapport.
Exercice 3
Questions 1 et 2
Voir en annexe la liste des commandes néccesaires à la réalisation de ces questions.
Question 3
D'abord, on observe que les routeurs se redistribuent bien les routes dont ils ont connaissance via OSPF. Exemple :
Figure 2 - Ici, on voit IR2, dont le démon OSPF vient de démarrer, s'initialiser et annoncer les routes qu'il connaît.
Ensuite, sur les trois routeurs de chaque AS, on observe que les tables de routage se sont construites. Par exemple, sur ASBR3 :
ASBR3#show ip route
198.18.224.0/31 is subnetted, 2 subnets
O 198.18.224.0 [110/2] via 198.18.224.2, 00:00:00, FastEthernet1/0
C 198.18.224.2 is directly connected, FastEthernet1/0
198.19.240.0/31 is subnetted, 1 subnets
C 198.19.240.0 is directly connected, FastEthernet2/0
198.18.240.0/31 is subnetted, 1 subnets
O 198.18.240.0 [110/3] via 198.18.224.2, 00:00:00, FastEthernet1/0
198.18.15.0/32 is subnetted, 1 subnets
O 198.18.15.254 [110/2] via 198.18.224.2, 00:00:00, FastEthernet1/0
|
Enfin, en utilisant la commande ping, on arrive à la même conclusion : toutes les adresses IP attribuées au sein de l'AS 64501 sont joignables depuis n'importe quel routeur de l'AS. Exemple depuis ASBR1 :
ASBR3#show ip route
198.18.224.0/31 is subnetted, 2 subnets
O 198.18.224.0 [110/2] via 198.18.224.2, 00:00:00, FastEthernet1/0
C 198.18.224.2 is directly connected, FastEthernet1/0
198.19.240.0/31 is subnetted, 1 subnets
C 198.19.240.0 is directly connected, FastEthernet2/0
198.18.240.0/31 is subnetted, 1 subnets
O 198.18.240.0 [110/3] via 198.18.224.2, 00:00:00, FastEthernet1/0
198.18.15.0/32 is subnetted, 1 subnets
O 198.18.15.254 [110/2] via 198.18.224.2, 00:00:00, FastEthernet1/0
|
Il en va de même dans l'AS 64502. Nous n'allons pas recommencer toute la démonstration et nous allons donc simplement afficher la table de routage d'ASBR4 :
ASBR4#show ip route
198.19.224.0/31 is subnetted, 2 subnets
C 198.19.224.0 is directly connected, FastEthernet2/0
O 198.19.224.2 [110/2] via 198.19.224.1, 01:45:51, FastEthernet2/0
198.19.240.0/31 is subnetted, 1 subnets
O 198.19.240.0 [110/3] via 198.19.224.1, 01:45:51, FastEthernet2/0
198.18.240.0/31 is subnetted, 1 subnets
C 198.18.240.0 is directly connected, FastEthernet1/0
198.19.15.0/32 is subnetted, 1 subnets
O 198.19.15.254 [110/2] via 198.19.224.1, 01:45:51, FastEthernet2/0
|
Question 4
Plusieurs méthodes sont à notre disposition pour redistribuer nos préfixes dans BGP, parmi lesquelles :
- Annoncer uniquement les préfixes réellement utilisés (pour chaque AS : trois /31 + la loopback).
- Annoncer toute notre allocation (un /16 par AS).
J'ai choisi d'annoncer toute l'allocation de chaque AS : l'AS 64501 annoncera 198.18.0.0/16 et l'AS 64502 annoncera 198.19.0.0/16.
D'une part, c'est totalement légitime (un /16 a été attribué, pourquoi ne pas l'annoncer dans sa globalité ?). Si des préfixes entiers sont non utilisés, c'est un problème de routage interne qui est à l'entière discrétion de notre AS, pas à celle des autres AS. D'autre part, cela évite l'encombrement de nos tables de routage (une entrée, le /16 au lieu de quatre, les 3 * /31 + loopback).
Pour qu'un routeur Cisco accepte d'émettre une annonce BGP pour une route, il faut avoir une entrée correspondante dans la table de routage. Pour cela, j'utilise une interface Null. Lorsque l'on fera communiquer nos routeurs entre eux, si les routeurs de bordure connaissent une route plus spécifique (via OSPF), ils transmettront les paquets. Sinon, les paquets finiront chez Dave Null et l'émetteur recevra un ICMP Destination Unreachable.
Pour que toutes les adresses IP soient joignables depuis n'importe quel routeur, et notamment pour que les routeurs internes puissent joindre les machines de l'autre AS, il convient de faire de la redistribution BGP dans OSPF.
Concernant les préfixes d'interconnexion : dans la vraie vie, dans le cadre d'un GIX, le préfixe d'interconnexion est fourni par le GIX lui-même.
Dans le cadre d'un accord transitaire-client, le transitaire fournit généralement le préfixe d'interconnexion (/30 ou /31 ).
Dans le cadre d'une interconnexion privée, les parties se mettent d'accord sur l'adressage.
Dans notre cas, on considérera que les AS se sont mis d'accord pour fournir, chacun, un des deux préfixes d'interconnexion dans leur allocation respective.
Voir les annexes pour les commandes basiques nécessaires à la mise en place de BGP.
D'abord, on observe que les routeurs de bordure se redistribuent bien leurs préfixes respectifs via BGP. Exemple :
Figure 3 - Ici, on voit ASBR6, dont le démon BGP vient de démarrer, initialiser une session BGP avec ASBR3 (TCP handshake + PDU BGP OPEN). Puis vient l'échange des préfixes (PDU BGP UPDATE).
Ensuite, on observe que les tables de routage se sont construites. Par exemple, sur ASBR3 :
ASBR3>show ip route
B 198.19.0.0/16 [20/0] via 198.19.240.0, 00:04:32
S 198.18.0.0/16 is directly connected, Null0
|
Ou bien encore sur ASBR4 :
ASBR4#show ip route
S 198.19.0.0/16 is directly connected, Null0
B 198.18.0.0/16 [20/0] via 198.18.240.0, 02:41:16
|
Enfin, en utilisant la commande ping, on arrive à la conclusion que toutes les adresses IP attribuées sont joignables. Illustration depuis IR5 :
IR5>ping 198.19.224.0
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms
IR5>ping 198.19.224.3
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/12 ms
IR5>ping 198.19.240.0
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/15/32 ms
IR5>ping 198.19.240.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/28 ms
IR5>ping 198.18.240.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms
IR5>ping 198.18.240.0
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/28 ms
IR5>ping 198.18.224.0
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/20 ms
IR5>ping 198.18.224.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/15/28 ms
IR5>ping 198.18.224.2
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/15/28 ms
IR5>ping 198.18.224.3
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/10/16 ms
IR5>ping 198.18.15.254
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/13/20 ms
|
Question 5
Les routes empruntées ne dépendent pas que du sous-préfixe de destination mais aussi de la machine émettrice et des calculs de l'IGP, comme nous allons le voir.
Oui, on peut observer des chemins asymétriques :
- Entre les routeurs de la même diagonale, c'est-à-dire entre ASBR1 et ASBR6 ou entre ASBR3 et ASBR4.
- En fonction des chemins sélectionnés par l'IGP, ici OSPF, les routeurs internes peuvent aussi avoir des chemins asymétriques pour les routeurs de l'autre AS.
Une petite illustration de l'asymétrie entre ASBR1 et ASBR6 : que se passe-t-il si ASBR1 veut pinguer ASBR6 ?
ASBR1#show ip route
B 198.19.0.0/16 [20/0] via 198.18.240.1, 01:15:43
|
Donc le paquet sera transmis à 198.18.18.240.1 (ASBR4) qui le transmettra à IR2 puis à ASBR6.
Pour le retour maintenant :
ASBR6#show ip route
B 198.18.0.0/16 [20/0] via 198.19.240.1, 01:16:35
|
Donc la réponse sera envoyée à ASBR3, pas à ASBR4.
Cela se vérifie avec deux captures réseau : l'une sur l'interface f1/0 d'ASBR1, l'autre sur l'interface f2/0 d'ASBR1. Lors d'un ping 198.19.224.3 (f1/0 ASBR6) depuis ASBR1 :
Figure 4 - ether.src : ca:00:53:1e:00:38 (f2/0 de ASBR1) -> ether.dst = ca:03:53:1e:00:1c (f1/0 de ASBR4).
Figure 5 - ether.src = ca:01:53:1e:00:1c (f1/0 d'IR2) -> ether.dst = ca:00:53:1e:00:1c (f1/0 d'ASBR1).
Ce comportement est tout à fait normal et s'explique par la politique dite de la patate chaude : on cherche à faire sortir de notre réseau, le plus tôt possible, un paquet destiné à un autre réseau. Ceci est la politique par défaut de BGP car elle nous protège contre un AS malveillant. Si l'on applique la politique de la patate froide mais que l'AS "d'en face" suit la politique de la patate chaude, on se retrouve à acheminer l'aller et le retour par notre réseau. Si l'on suit la politique de la patate chaude, quoi que fasse l'AS "d'en face", patate chaude (on est à égalité, chacun a acheminé une partie de la communication) ou patate froide (on est gagnant, l'AS "d'en face" a tout acheminé sur son réseau), on n'est jamais perdant. La patate chaude permet une certaine justice. Sauf dans le cas de trafic asymétrique mais ce n'est pas le sujet.
Il est parfois utile de convenir, avec son(ses) transitaire(s), d'un routage en patate froide. Cela peut servir à faire de l'ingénierie de trafic. Exemples : faire privilégier un chemin plus direct, moins couteux ou plus rapide.
On peut donc changer le comportement du routage en jouant sur la politique de routage : utiliser l'attribut MED, utiliser la méthode de l'AS-Prepending, faire en sorte que notre préfixe ne soit annoncé que depuis un transitaire à la fois et garder l'autre transitaire en sauvegarde, ...
Question 6
En théorie, quand un lien inter-domaine tombe, BGP s'en rend compte (à cause de l'absence de messages KEEPALIVE et des ACK TCP associés) et la session tombe totalement après le délai "hold-time" (180 secondes par défaut sur les Cisco). L'IGP, OSPF dans notre cas, recalculera les chemins disponibles et le trafic inter-domaine sera redirigé vers le lien inter-domaine restant.
Pour mettre ça en pratique, nous allons éteindre l'interface f1/0 d'ASBR4.
Dans un premier temps, les messages KEEPALIVE d'ASBR1 ne sont pas acquittés par ASBR4 donc sa pile TCP les réémet :
Figure 6 - Les PDU KEEPALIVE d'ASBR1 ne sont pas acquittés par ASBR4 donc sa pile TCP les réémet.
Comme la situation ne se rétablit pas avant l'expiration du délai "hold-time", ASBR1 abandonne la session BGP :
%BGP-5-ADJCHANGE: neighbor 198.18.240.1 Down BGP Notification sent
%BGP-3-NOTIFICATION: sent to neighbor 198.18.240.1 4/0 (hold time expired)
|
ASBR1 indique aux autres routeurs de l'AS 64501, via OSPF, qu'il a perdu la connectivité pour 198.19.0.0/16.
Figure 7 - ASBR1 perd la connectivité vers 198.19.0.0/16 : la métrique explose puis la route ne sera plus annoncée via OSPF.
ASBR1 choisit donc la route qu'IR2 lui annonce pour joindre 198.19.0.0/16 : IR2 -> ASBR3 -> ASBR6
Figure 8 - IR2 annonce à ASBR1 la route qu'il connaît pour joindre 198.19.0.0/16 : IR2 -> ASBR3 -> ASBR6.
On constate que les tables de routage d'ASBR1 et d'ASBR4 se sont mises à jour :
ASBR1#show ip route
O E2 198.19.0.0/16 [110/1] via 198.18.224.1, 00:00:50, FastEthernet1/0
ASBR4#show ip route
O E2 198.18.0.0/16 [110/1] via 198.19.224.1, 00:04:53, FastEthernet2/0
|
Question 7
En théorie, quand l'une des loopback sera désactivée, l'annonce OSPF du routeur interne contiendra une annonce de moins. Les autres routeurs de l'AS seront informés, par OSPF, du fait que le préfixe associé à la loopback n'est plus joignable. Rien ne se passera au niveau de BGP : l'annonce porte sur le sur-réseau /16. Il y aurait eu des UPDATE BGP si j'avais choisi d'annoncer uniquement les préfixes réellement attribués.
Pour la mise en pratique, on va éteindre l'interface loopback 1 d'IR2. La table de routage d'IR2 se met à jour puis IR2 n'annonce plus le préfixe de la loopback via OSPF.
Figure 9 - IR2 n'annonce plus sa loopback en OSPF.
Les autres routeurs de l'AS (ASBR1 et ASBR3) mettent à jour leur table de routage. Si un routeur de l'AS 64502 essaye de joindre le préfixe de la loopback, il recevra un message ICMP Destination Unreachable de la part d'un des routeurs de bordures de l'AS 64501. Exemple :
Figure 10 - ASBR6 tente de pinger la loopback 1 d'IR2. ASBR3, auquel ASBR6 a envoyé le paquet, ne connaît aucune route pour aller à cette adresse donc il émet un ICMP dst unreachable.
Quand on remonte l'interface loopback, IR2 l'annonce à nouveau en OSPF et tout rentre dans l'ordre.
Figure 11 - IR2 annonce, à nouveau, sa loopback via OSPF.
Question 8
J'ai choisi d'adapter mon AS 64501. Voici un schéma qui représente la nouvelle configuration interne de cet AS :
Figure 12 - Schéma de la nouvelle configuration interne de l'AS 64501.
Comme toujours, il y a plusieurs topologies qui répondent à l'énoncé. J'ai choisi celle-ci car elle me paraît intelligible : il est évident qu'ASBR1 et ASBR3 forment la dorsale de l'AS 64501 puisqu'ils ont la connectivité vers l'extérieur. IR2 et IR7 ne sont que des routeurs "secondaires" de l'AS. C'est pour cette raison que je les ai mis dans des zones OSPF différentes.
Les commandes de configuration nécessaires sont présentées en annexe.
Regardons l'une des tables de routage, celle d'ASBR1, par exemple :
ASBR1#show ip route
198.18.224.0/31 is subnetted, 3 subnets
O IA 198.18.224.4 [110/2] via 198.18.224.1, 00:23:29, FastEthernet1/0
C 198.18.224.0 is directly connected, FastEthernet1/0
C 198.18.224.2 is directly connected, FastEthernet3/0
198.18.31.0/32 is subnetted, 1 subnets
O IA 198.18.31.254 [110/3] via 198.18.224.1, 00:23:24, FastEthernet1/0
198.18.240.0/31 is subnetted, 1 subnets
C 198.18.240.0 is directly connected, FastEthernet2/0
198.18.15.0/32 is subnetted, 1 subnets
O 198.18.15.254 [110/2] via 198.18.224.3, 00:23:41, FastEthernet3/0
|
La commande ping nous permet de vérifier que tout notre routage, interne et inter-AS, fonctionne :
IR2#ping 198.18.224.2
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/16/36 ms
IR2#ping 198.18.224.0
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/36 ms
IR2#ping 198.18.224.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/24 ms
IR2#ping 198.18.224.4
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/13/28 ms
IR2#ping 198.18.224.5
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/17/28 ms
IR2#ping 198.18.31.254
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/24 ms
IR2#ping 198.18.240.0
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/10/20 ms
IR2#ping 198.18.240.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/17/40 ms
IR2#ping 198.19.224.0
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/24 ms
IR2#ping 198.19.224.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/16 ms
IR2#ping 198.19.224.2
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/24 ms
IR2#ping 198.19.224.3
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/18/24 ms
IR2#ping 198.19.240.0
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/18/32 ms
IR2#ping 198.19.240.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/16/24 ms
|
En ce qui concerne, les échanges des LSA, on remarque que, à l'intérieur de chaque aire, rien n'a changé : on a toujours les types de LSA 1 (router), 2 (network) et 5 (external). Mais maintenant, ASBR1 et ASBR3 portent pleinement leurs noms : ils sont à la fois des routeurs de la dorsale (backbone), des routeurs inter-aires (ABR) et des routeurs qui injectent des routes externes (ASBR). On a donc des échanges supplémentaires : les échanges inter-aires (3-summary ; 4-interarea summary), assurés par ASBR1 et ASBR3.
Au niveau OSPF, ASBR1 et ASBR3 maintiennent une base des données topologiques des aires auxquelles ils appartiennent (ASBR 1 : aire 0 et 1 ; ASBR2 : aire 0 et 2). De plus, comme ils sont aussi des routeurs de la dorsale, ils redistribueront les informations de la topologie aux autres aires (1 et 2). Pour les deux autres routeurs, le fonctionnement est identique à celui que nous avions avant.
Quelques captures qui présentent les échanges inter-aires :
Figure 13 - ASBR3 annonce, dans l'aire 0, les routes de l'aire 2.
Figure 14 - Quelques secondes plus tard, ASBR1 redistribue les routes de l'aire 2 dans l'aire 1.
Exercice 4
Avant de commencer
Avant de commencer cet exercice, on établit des sessions iBGP entre tous les routeurs de bordure d'un même AS (ASBR1<->ASBR3 ; ASBR4<->ASBR6) afin qu'ils s'échangent les meilleures routes et s'accordent sur les valeurs associées (métrique, préférence locale, ...). Cela se fait simplement en utilisant la commande habituelle « neighbor » mais avec notre numéro d'AS. Exemple, sur ASBR1 :
router bgp 64501
neighbor 198.18.224.3 remote-as 64501
|
De plus, la commande suivante permet d'appliquer les modifications (route-map, ...) plus rapidement :
Pour cet exercice, la configuration de Dynagen est la même que celle utilisée pour l'exercice 3 hors aires OSPF. La configuration des routeurs est aussi celle de l'exercice 3 hors aires OSPF. Ces deux configurations sont disponibles en annexes.
Sauf mention contraire, j'ai considéré que les questions étaient indépendantes et je reviens donc à la configuration "de base" (celle de l'exercice 3 hors aires OSPF + iBGP présenté ci-dessus) entre chaque question.
Question 1
Pour tenter de contrôler le lien par lequel les flux entrent dans notre AS, nous avons plusieurs outils à notre disposition :
- L'attribut Multi-Exit Discriminator
- La méthode de l'AS prepending
- Les communautés
- Subnetter l'allocation, annoncer des préfixes plus précis et ainsi pouvoir définir des comportements plus précis pour les flux entrants dans notre AS.
Comme l'AS prepending sera demandé à la question 7 et que la dernière méthode est à utiliser en dernier ressort seulement (inflation de la table de routage globale), j'ai choisi d'utiliser l'attribut MED qui est prévu pour privilégier, de manière propre, un lien parmi plusieurs disponibles (possiblement géographiquement répartis) entre deux AS.
Par défaut, sur Cisco, la métrique est de 0 et elle est considérée comme étant la meilleure. Donc, si ASBR6 annonce, à ASBR3, une métrique de 10 pour 198.19.0.0/16, tout le trafic à destination de l'AS 64502 sera redirigé vers le lien de gauche. Cela se fait avec les commandes suivantes :
neighbor 198.19.240.1 route-map setmed out
route-map setmed permit 10
set metric 10
|
On constate que les tables de routage se mettent à jour en conséquence. Ici, sur IR2 :
IR2#show ip route
O E2 198.19.0.0/16 [110/1] via 198.18.224.0, 00:03:13, FastEthernet1/0
|
Ou encore sur ASBR3 :
ASBR3#show ip route
O E2 198.19.0.0/16 [110/1] via 198.18.224.2, 00:03:41, FastEthernet1/0
|
Pour pouvoir tester ma configuration concernant la deuxième partie de la question, faire en sorte que la préférence du lien de gauche ne s'applique qu'au trafic issu de l'AS 64501 lui-même, je rajoute un AS 64503 à ma maquette. Le préfixe qu'il annonce est 10.0.0.0/8. Cet AS est composé de deux routeurs, ASBR7 et ASBR8 qui communiquent entre eux en iBGP. ASBR7 est raccordé à ASBR1 et ASBR8 est raccordé à ASBR3.
On constate que, lorsque ASBR7 veut joindre 198.19.0.0/16 (AS 64502), il passe par ASBR1 puis par le lien de gauche. En revanche, quand ASBR8 veut faire la même chose, il passe par ASBR3. Mais, à cause de la modification de la MED, ASBR3 envoie tout à ASBR1 et tout passe par le lien de gauche alors que le lien de droite serait mieux dans le cas présent.
Le comportement est logique et résulte de notre modification. On se rend compte que le problème est "local" à ASBR3, et qu'il est dépendant de la manière dont sa table de routage est construite.
Il n'est pas possible de répondre à cette contrainte sans intervenir sur l'AS 64501. On peut influencer le trafic entrant dans notre AS mais on ne peut pas le différencier en fonction de son origine "présumée" pour ensuite influencer son entrée dans notre AS depuis l'AS 64502 car aucun outil purement BGP ne permet de le faire. En effet, les route-map et autres outils de capture d'éléments dont j'ai connaissance permettent de prendre des décisions et d'agir uniquement sur les annonces BGP envoyées/reçues par l'AS lui-même, pas sur des paramètres connus seulement par un autre AS. Une "condition" du type "bon, AS1, si le trafic vient de toi, MED = 10, sinon MED = 0", envoyée par AS 64502, n'est pas possible car on ne peut pas matcher l'inconnu et car il y a une dualité à exprimer.
Même si l'on avait le contrôle de l'AS 64501, imposer cette contrainte me paraît extrêmement difficile en utilisant les outils purement BGP (pas de MPLS, ...) car cela signifie qu'il faut modifier la table de routage "à la demande", en temps réel : si le trafic vient d'un autre AS et s'il est à destination de l'AS 64502, il faut router sur le lien de droite mais le reste du temps, la table de routage doit contenir une entrée pour router via ASBR1.
J'ai quand même pensé à plusieurs solutions basées sur l'attribut MED, sur la préférence locale et sur la communauté no-advertise (entre ASBR1 et ASBR3) mais toutes échoueront en théorie (à cause de la distribution OSPF, à cause du manque de redondance si un lien tombe, ...) donc je ne les ai pas mises en pratique.
Question 2
Pour influencer les flux sortants de notre AS, plusieurs outils sont à notre disposition :
- L'attribut local-preference
- Les communautés
- Jouer sur les poids des métriques dans l'IGP
J'ai choisi d'utiliser la manière de faire la plus courante et la plus facile d'utilisation : définir la préférence locale. En définissant une préférence locale plus faible sur ASBR4, le trafic sortant sera dirigé vers ASBR6.
On peut redéfinir la valeur par défaut de la préférence locale sur ASBR4 :
router bgp 64502
bgp default local-preference 90
|
Ainsi, on a le choix entre une route avec une préférence locale de 90 propagée par ASBR4 et une route avec une préférence locale de 100 (par défaut) propagée par ASBR6. ASBR6 sera choisi comme routeur de sortie de l'AS 64502 pour toutes les destinations annoncées ou relayées par l'AS 64501.
Table de routage avant/après sur ASBR4 :
ASBR4#show ip bgp
*> 198.18.0.0/16 198.18.240.0 0 0 64501 i
* i 198.19.240.1 0 100 0 64501 i
*> 198.19.0.0/16 0.0.0.0 0 32768 i
* i 198.19.224.3 0 100 0 i
----
r 198.18.0.0/16 198.18.240.0 0 0 64501 i
r>i 198.19.240.1 0 100 0 64501 i
*> 198.19.0.0/16 0.0.0.0 0 32768 i
* i 198.19.224.3 0 100 0 i
ASBR4#show ip route
O E2 198.18.0.0/16 [110/1] via 198.19.224.1, 00:07:47, FastEthernet2/0
----
ASBR4#traceroute 198.18.224.0
1 198.19.224.1 8 msec 4 msec 4 msec
2 198.19.224.3 12 msec 12 msec 12 msec
3 198.19.240.1 16 msec 16 msec 16 msec
4 198.18.224.2 12 msec 12 msec 16 msec
5 198.18.224.0 16 msec * 24 msec
|
On constate qu'IR5 aussi passera par ASBR6 pour joindre 198.18.0.0/16 :
IR5#show ip route
O E2 198.18.0.0/16 [110/1] via 198.19.224.3, 00:07:11, FastEthernet2/0
|
On notera que, pour obtenir le même résultat, on aurait aussi pu créer, sur ASBR4, une route-map contenant un « set local-preference 90 » sans filtrer les préfixes auxquels elle s'applique que l'on appliquerait sur les préfixes en provenance de ASBR1.
Question 3
Pour utiliser le lien de droite uniquement pour le trafic sortant vers l'AS 64501 lui-même, il suffit de reprendre le raisonnement de la question précédente mais en appliquant la préférence locale uniquement à l'AS 64501 et à ses préfixes.
Pour se faire, on utilise les commandes suivantes sur ASBR4 :
ip prefix-list as64501 permit 198.18.0.0/16
route-map liendroite permit 10
match ip address prefix-list as64501
set local-preference 90
route-map liendroite permit 20
set local-preference 110 !pour attirer le trafic pour 10.0.0.0/8, pas obligatoire.
router bgp 64502
neighbor 198.18.240.0 route-map liendroite in
|
Pour éviter des mises à jour fastidieuses dans le cas où l'AS 64501 aurait de nouveaux préfixes, on peut aussi faire une sélection basée sur le chemin d'AS :
ip as-path access-list 1 permit ^64501$ ! AS-PATH contient uniquement 64501
route-map liendroite permit 10
match as-path 1
set local-preference 90
route-map liendroite permit 20
set local-preference 110 !pour attirer le trafic pour 10.0.0.0/8, pas obligatoire.
router bgp 64502
neighbor 198.18.240.0 route-map liendroite in
|
Pour tester, on reprend notre configuration avec trois AS et huit routeurs présentée à la question 1 et l'on regarde les tables de routage :
ASBR4#show ip route
B 10.0.0.0/8 [20/0] via 198.18.240.0, 00:01:17
O E2 198.18.0.0/16 [110/1] via 198.19.224.1, 00:04:53, FastEthernet2/0
----
IR5#show ip route
O E2 10.0.0.0/8 [110/1] via 198.19.224.0, 00:01:41, FastEthernet1/0
O E2 198.18.0.0/16 [110/1] via 198.19.224.3, 00:05:17, FastEthernet2/0
----
ASBR6#show ip route
O E2 10.0.0.0/8 [110/1] via 198.19.224.2, 00:01:56, FastEthernet1/0
B 198.18.0.0/16 [20/0] via 198.19.240.1, 00:50:13
|
Les traceroute pour 198.18.0.0/16 donnent les mêmes résultats qu'à la question précédente. Voici pour 10.0.0.0/8 :
ASBR4#traceroute 10.0.0.1
1 198.18.240.0 24 msec 8 msec 4 msec
2 198.18.240.3 32 msec 12 msec 12 msec
|
Question 4
Voici la correspondance entre les préfixes et leur nom dans l'énoncé :
- P1 : 198.18.15.254/32
- P2 : 198.18.31.254/32
- P3 : 198.18.47.254/32
Ces préfixes seront attribués à des interfaces loopback sur IR2. P1 est déjà attribué à la loopback 1. Pour les autres préfixes :
int loopback 2
ip address 198.18.31.254 255.255.240.0
int loopback 3
ip address 198.18.47.254 255.255.240.0
|
Il y a au moins deux manières d'aborder le problème :
- Si l'AS d'origine diffuse des préfixes plus spécifiques pour certains de ses services, il suffit d'utiliser une route-map et d'appliquer une préférence locale pour diriger le trafic sortant sur le lien qui nous convient. Dans la vraie vie, d'après mes informations, l'annonce de préfixes plus spécifiques semble être courante pour les gros services. Exemple : Youtube est dans un /24. Cela permet donc de différencier le trafic à destination de Google Search de celui à destination de Youtube.
- Si l'AS d'origine ne diffuse pas des préfixes plus spécifiques, il faut alors se débrouiller en local pour désagréger l'annonce plus générale à l'aide de routes statiques, d'annonces conditionnelles et d'autres joyeusetés.
Dans un premier temps, seule la première solution était réellement fonctionnelle dans ma maquette. Voici la configuration que j'utilisais :
ASBR1#network 198.18.15.254 mask 255.255.255.255
ASBR1#network 198.18.31.254 mask 255.255.255.255
ASBR3#network 198.18.15.254 mask 255.255.255.255
ASBR3#network 198.18.31.254 mask 255.255.255.255
ASBR4#ip prefix-list p1 permit 198.18.15.254/32
ASBR4#route-map setlocalpref permit 10
ASBR4#match ip address prefix-list p1
ASBR4#set local-preference 110
ASBR4#route-map setlocalpref permit 20
ASBR4#neighbor 198.18.240.0 route-map setlocalpref in
ASBR6#ip prefix-list p2 permit 198.18.31.254/32
ASBR6#route-map setlocalpref permit 10
ASBR6#match ip address prefix-list p2
ASBR6#set local-preference 110
ASBR6#route-map setlocalpref permit 20
ASBR6#neighbor 198.19.240.1 route-map setlocalpref in
|
En temps normal, le trafic pour P1 passe sur le lien de gauche et le trafic pour P2 passe sur le lien de droite. En cas de coupure d'un lien, le trafic est correctement redirigé sur le lien inter-domaines restant.
Dans un deuxième temps, je me suis souvenu qu'avec certains routeurs purement logiciels, notamment BIRD, il est possible de créer des routes quasiment statiques dont l'existence est conditionnée par l'existence d'une route BGP. Malgré mes recherches, je n'ai rien trouvé de comparable chez Cisco.
Dans un troisième temps, je me suis penché sur les routes statiques et les annonces conditionnelles. Je vais developper le raisonnement pour P1, il est identique pour P2.
L'idée de la manipulation est que, si ASBR4 reçoit une route pour 198.18.0.0/16, depuis ASBR1, alors il annonce, à ASBR6, en iBGP, une meilleure route pour 198.18.15.254. La route étant plus spécifique, elle l'emporte. Si l'un des deux liens tombe, le routeur restant doit annoncer la route.
Sur Cisco, pour annoncer une route via BGP, il faut posséder une entrée correspondante dans la table de routage. On crée donc une route statique sur ASBR4 et sur ASBR6, pas une interface Null sinon on devient des trous noirs.
Sur ASBR4 :
ip route 198.18.15.254 255.255.255.255 198.18.240.0
ip prefix-list p1 permit 198.18.15.254/32
route-map filterfuites deny 10
match ip address prefix-list p1
route-map filterfuites permit 20
access-list 1 permit 198.18.15.254 0.0.0.0
access-list 2 permit 198.18.0.0 0.0.255.255
ip prefix-list ROUTE_SOURCE permit 198.18.240.0/32
route-map ADV permit 10
match ip address 1
set ip next-hop 198.19.224.0
set community no-export !évite qu'ASBR6 ne fasse fuiter
route-map NotThere permit 10
match ip address 2
match ip route-source prefix-list ROUTE_SOURCE
router bgp 64502
neighbor 198.18.240.0 route-map filterfuites out ! on évite que les annonces fuitent vers AS1
neighbor 198.19.224.3 advertise-map ADV exist-map NotThere
neighbor 198.19.224.3 send-community ! sans ça, les communautés ne sont pas tranmises
redistribute static ! on distribue nos routes statiques en (i)BGP
#Il faut redistribuer nos routes statiques via OSPF pour IR5
router ospf 1
redistribute static subnets
|
Sur ASBR6 :
ip route 198.18.15.254 255.255.255.255 198.19.240.1 110
#Pour qu'une route iBGP soit préférée à une route OSPF, il faut diminuer la distance
#administrative par défaut d'iBGP (200 -> 100 < 110 (OSPF)).
router bgp 64502
distance bgp 20 100 100
#Il faut redistribuer nos routes statiques via OSPF pour IR5
router ospf 1
redistribute static-subnets
|
On regarde le résultat quand les deux liens sont opérationnels :
ASBR4#show ip route
198.18.15.0/32 is subnetted, 1 subnets
S 198.18.15.254 [1/0] via 198.18.240.0
B 198.18.0.0/16 [20/0] via 198.18.240.0, 00:05:02
IR5#show ip route
O E2 198.18.15.254 [110/20] via 198.19.224.0, 00:02:37, FastEthernet1/0
ASBR6#show ip route
198.18.15.0/32 is subnetted, 1 subnets
B 198.18.15.254 [100/0] via 198.19.224.0, 00:01:51
B 198.18.0.0/16 [20/0] via 198.19.240.1, 00:14:45
ASBR6#traceroute 198.18.15.254
1 198.19.224.2 20 msec 4 msec 8 msec
2 198.19.224.0 28 msec 12 msec 44 msec
3 198.18.240.0 [AS 64501] 48 msec 28 msec 52 msec
4 198.18.224.1 [AS 64501] 48 msec * 60 msec
|
On regarde le résultat quand le lien de gauche tombe :
ASBR4#show ip route
198.18.15.0/32 is subnetted, 1 subnets
S 198.18.15.254 [1/0] via 198.18.240.0
O E2 198.18.0.0/16 [110/1] via 198.19.224.1, 00:01:31, FastEthernet2/0
IR5#show ip route
O E2 198.18.15.254 [110/20] via 198.19.224.3, 00:01:22, FastEthernet2/0
[110/20] via 198.19.224.0, 00:01:22, FastEthernet1/0
O E2 198.18.0.0/16 [110/1] via 198.19.224.3, 00:01:57, FastEthernet2/0
ASBR6#show ip route
198.18.15.0/32 is subnetted, 1 subnets
S 198.18.15.254 [110/0] via 198.19.240.1
B 198.18.0.0/16 [20/0] via 198.19.240.1, 00:08:45
IR5#traceroute 198.18.15.254
1 198.19.224.3 4 msec
2 198.19.240.1 24 msec *
3 198.18.224.2 40 msec * 36 msec
|
Et pour P2 ? La démarche est la même : ASBR4 et ASBR6 auront des routes statiques, ASBR6 fera une annonce conditionnelle, ...
Cette solution présente, selon moi, deux inconvénients :
- C'est une solution palliative, du bidouillage : on modifie des paramètres (les distances administratives iBGP par exemple) qui auront sûrement un impact sur d'autres comportements attendus. Comme notre maquette est limitée, on ne voit rien mais dans un vrai déploiement ...
- On remarque que ASBR4 garde toujours sa route statique pour P1 et qu'ASBR6 fait de même pour P2. Quand le lien tombe, le routeur ne peut plus joindre le préfixe associé (ie : ASBR4 ne peut plus joindre 198.18.15.254). On peut se dire que ce n'est pas grave car au moment où un lien tombe, le routeur associé ne sert plus à rien : il ne reçoit plus de trafic car l'IGP bascule sur l'autre routeur. L'impact est donc limité au routeur lui-même. Malgré mes tentatives, je n'ai pas trouvé une solution à ce problème :
- Même en changeant les distances administratives ou le poids des routes, j'arrive toujours à "une boucle" ou plutôt à un problème d'amorçage (il faut une route dans la table de routage pour que le processus BGP Cisco accepte d'annoncer une route). Soit un routeur préfère une route OSPF à sa statique et on se retrouve à vouloir injecter de l'OSPF dans BGP, ce qui est déconseillé, soit un router préfère une route iBGP à sa statique et on se retrouve à vouloir réinjecter une route apprise en iBGP dans iBGP, ce qui n'est pas possible : formation d'une boucle.
- On peut aussi demander la suppression de la route statique en fonction d'un événement comme une adresse IP qui n'est plus joignable (exemple). Mais comme on a une double connectivité, toutes les adresses sont joignables en permanence donc la route statique restera en permanence car le test retournera toujours vrai.
Enfin, j'ai découvert la fonctionnalité « inject-map » de l'IOS qui permet de désagréger, sous conditions, un préfixe donné en préfixes plus spécifiques. Si ASBR4 reçoit une route pour 198.18.0.0/16, via BGP, de la part d'ASBR1 alors il désagrège et annonce 198.18.15.254. Le raisonnement est identique pour ASBR6 et 198.18.31.254.
Voici la configuration que j'utilise :
ASBR4#ip prefix-list ROUTE permit 198.18.0.0/16
ASBR4#ip prefix-list ROUTE_SOURCE permit 198.18.240.0/32
ASBR4#ip prefix-list UNAGGREGATED_ROUTE permit 198.18.15.254/32
ASBR4#route-map ORIGINATE permit 10
ASBR4#set ip address prefix-list UNAGGREGATED_ROUTE
ASBR4#route-map LEARNED_ROUTE permit 10
ASBR4#match ip address prefix-list ROUTE
ASBR4#match ip route-source prefix-list ROUTE_SOURCE
ASBR4#bgp inject-map ORIGINATE exist-map LEARNED_ROUTE
ASBR6#ip prefix-list ROUTE permit 198.18.0.0/16
ASBR6#ip prefix-list ROUTE_SOURCE permit 198.19.240.1/32
ASBR6#ip prefix-list UNAGGREGATED_ROUTE permit 198.18.31.254/32
ASBR6#route-map ORIGINATE permit 10
ASBR6#set ip address prefix-list NAGGREGATED_ROUTE
ASBR6#route-map LEARNED_ROUTE permit 10
ASBR6#match ip address prefix-list ROUTE
ASBR6#match ip route-source prefix-list ROUTE_SOURCE
ASBR6#bgp inject-map ORIGINATE exist-map LEARNED_ROUTE
|
Attention : la désagrégation prend un peu de temps avant d'être effective.
Pour éviter les fuites des routes plus spécifiques vers l'AS 64501, on les filtre en sortie sur les 2 routeurs de l'AS 64502. Ci-dessous les commandes pour ASBR4 :
ip prefix-list ctrl permit 198.18.15.254/32
ip prefix-list ctrl permit 198.18.31.254/32
route-map filterfuites deny 10
match ip address prefix-list ctrl
route-map filterfuites permit 20
neighbor 198.18.240.0 route-map filterfuites out
|
On regarde les tables de routage :
ASBR4#show ip route
198.18.31.0/32 is subnetted, 1 subnets
O E2 198.18.31.254 [110/1] via 198.19.224.1, 00:07:18, FastEthernet2/0
198.18.15.0/32 is subnetted, 1 subnets
B 198.18.15.254 [20/0] via 198.18.240.0, 00:31:26
B 198.18.0.0/16 [20/0] via 198.18.240.0, 00:31:39
IR5#show ip route
198.18.31.0/32 is subnetted, 1 subnets
O E2 198.18.31.254 [110/1] via 198.19.224.3, 00:07:43, FastEthernet2/0
198.18.15.0/32 is subnetted, 1 subnets
O E2 198.18.15.254 [110/1] via 198.19.224.0, 00:31:51, FastEthernet1/0
ASBR6#show ip route
198.18.31.0/32 is subnetted, 1 subnets
B 198.18.31.254 [20/0] via 198.19.240.1, 00:07:58
198.18.15.0/32 is subnetted, 1 subnets
O E2 198.18.15.254 [110/1] via 198.19.224.2, 00:32:06, FastEthernet1/0
B 198.18.0.0/16 [20/0] via 198.19.240.1, 00:08:32
|
Quelques traceroute pour vérifier :
IR5#traceroute 198.18.15.254
1 198.19.224.0 20 msec 76 msec 20 msec
2 198.18.240.0 24 msec 36 msec 12 msec
3 198.18.224.1 300 msec * 20 msec
IR5#traceroute 198.18.31.254
1 198.19.224.3 108 msec 36 msec 12 msec
2 198.19.240.1 84 msec 464 msec 28 msec
3 198.18.224.2 28 msec * 40 msec
ASBR4#traceroute 198.18.15.254
1 198.18.240.0 [AS 64501] 80 msec 40 msec 52 msec
2 198.18.224.1 [AS 64501] 8 msec * 4 msec
ASBR4#traceroute 198.18.31.254
1 198.19.224.1 8 msec 32 msec 28 msec
2 198.19.224.3 32 msec 32 msec 24 msec
3 198.19.240.1 196 msec 48 msec 36 msec
4 198.18.224.2 [AS 64501] 16 msec * 172 msec
|
On constate que chaque préfixe passe par le lien désiré.
Quand le lien de gauche tombe, P1 disparaît et la route moins-spécifique reprend le dessus :
ASBR4#show ip route
198.18.31.0/32 is subnetted, 1 subnets
O E2 198.18.31.254 [110/1] via 198.19.224.1, 00:13:08, FastEthernet2/0
O E2 198.18.0.0/16 [110/1] via 198.19.224.1, 00:02:22, FastEthernet2/0
IR5#show ip route
198.18.31.0/32 is subnetted, 1 subnets
O E2 198.18.31.254 [110/1] via 198.19.224.3, 00:13:42, FastEthernet2/0
O E2 198.18.0.0/16 [110/1] via 198.19.224.3, 00:02:55, FastEthernet2/0
ASBR6#show ip route
198.18.31.0/32 is subnetted, 1 subnets
B 198.18.31.254 [20/0] via 198.19.240.1, 00:13:59
B 198.18.0.0/16 [20/0] via 198.19.240.1, 00:14:33
IR5#traceroute 198.18.15.254
1 198.19.224.3 20 msec 8 msec 12 msec
2 198.19.240.1 40 msec 28 msec 28 msec
3 198.18.224.2 24 msec * 208 msec
IR5#traceroute 198.18.31.254
1 198.19.224.3 76 msec 28 msec 20 msec
2 198.19.240.1 16 msec 24 msec 20 msec
3 198.18.224.2 44 msec * 208 msec
|
On constate que tout a bien été redirigé vers le lien de droite.
On se doute qu'une situation similaire va se produire si c'est le lien de droite qui tombe à la place du lien de gauche. Vérification concise :
IR5#traceroute 198.18.15.254
1 198.19.224.0 16 msec 12 msec 4 msec
2 198.18.240.0 32 msec 12 msec 28 msec
3 198.18.224.1 36 msec * 16 msec
IR5#traceroute 198.18.31.254
1 198.19.224.0 28 msec 4 msec 16 msec
2 198.18.240.0 8 msec 28 msec 36 msec
3 198.18.224.1 20 msec * 208 msec
|
Et concernant P3 ? BGP, comme tout protocole de construction dynamique de tables de routage a pour but de s'adapter aux fluctuations afin de maintenir, tant que possible, une connectivité. Il n'est donc pas le candidat idéal pour forcer le trafic sur un lien même quand celui-ci tombe. Dans un genre similaire : dans une configurations multi-homée, il est toujours délicat de forcer le trafic à entrer/sortir d'un AS via un seul upstream. Par exemple, cela en fait une thématique récurrente sur FRnOG. Exemples choisis : Session BGP priorité et multihome BGP avec annonces conditionnelles et statiques
Dans notre cas, une route statique, mise en place sur ASBR6 me paraît être une méthode plus cohérente en raison de sa plus grande priorité administrative.
Mise en œuvre :
ip route 198.18.47.254 255.255.255.255 198.19.240.1
router ospf 1 #Il faut redistribuer notre route statique, via OSPF, pour IR5/ASBR4
resdistribute static subnets
|
On constate la bonne mise en place de la route :
ASBR4#show ip route
198.18.47.0/32 is subnetted, 1 subnets
O E2 198.18.47.254 [110/20] via 198.19.224.1, 00:07:17, FastEthernet2/0
ASBR4#traceroute 198.18.47.254
1 198.19.224.1 4 msec 8 msec 8 msec
2 198.19.224.3 8 msec 8 msec 12 msec
3 198.19.240.1 12 msec 12 msec 12 msec
4 198.18.224.2 [AS 64501] 16 msec * 64 msec
|
Quand le lien de droite tombe, ASBR6 continue d'annoncer une route vers P3 et devient ainsi un trou noir pour ce préfixe pour tout l'AS, comme désiré. Vérification :
IR5#show ip route
198.18.47.0/32 is subnetted, 1 subnets
O E2 198.18.47.254 [110/20] via 198.19.224.3, 00:17:48, FastEthernet2/0
O E2 198.18.0.0/16 [110/1] via 198.19.224.0, 00:03:30, FastEthernet1/0
IR5#traceroute 198.18.47.254
1 198.19.224.3 24 msec 8 msec 32 msec
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
...
|
Question 5
Il suffit de rallonger le chemin d'AS pour les annonces qu'ASBR6 distribuent à ASBR3.
route-map asprepending permit 10
set as-path prepend 64502 64502 !une seule fois suffirait mais par sécurité ...
router bgp 64502
neighbor 198.19.240.1 route-map asprepending out
|
On regarde le résultat sur les routeurs de l'AS 64501 :
ASBR3>show ip bgp
r 198.19.0.0/16 198.19.240.0 0 0 64502 64502 64502 i
r>i 198.18.240.1 0 100 0 64502 i
ASBR3#show ip route
O E2 198.19.0.0/16 [110/1] via 198.18.224.2, 00:06:49, FastEthernet1/0
IR2#show ip route
O E2 198.19.0.0/16 [110/1] via 198.18.224.0, 00:06:40, FastEthernet1/0
|
Un traceroute confirme le résultat :
ASBR3#traceroute 198.19.15.254
1 198.18.224.2 8 msec 8 msec 8 msec
2 198.18.224.0 12 msec 12 msec 8 msec
3 198.18.240.1 12 msec 16 msec 12 msec
4 198.19.224.1 16 msec * 52 msec
|
Question 6
Les communautés sont des marques inter-AS positionnées par un AS sur les routes, qui permettent de déclencher une action spécifique dans un autre AS (affecter une préférence locale, ne pas ré-annoncer le préfixe, ne pas annoncer sur tel GIX, as-prepend vers tel peer, ...). Les listes des communautés disponibles au sein d'un AS sont échangées lorsque deux AS "contractualisent" (peering ou transit) en même temps que l'accord sur un préfixe d'interconnexion.
Dans notre cas, et comme toujours, il y a au moins deux manières de procéder :
- Soit ASBR6 positionne une communauté pour le préfixe de l'AS 64501. ASBR4 l'interprète et affecte une préférence locale plus élevée à cette route. Méthode un peu inutile car on peut positionner directement une préférence locale sur une session iBGP, ce qu'on ne peut pas faire en eBGP.
- Soit l'AS 64501 positionne une communauté pour son préfixe. Seul ASBR6 l'interprète et affecte une préférence locale plus élevée à cette route. On remarquera que si l'on met ça en place, d'un point de vue de l'AS 64501, cela lui permet d'influencer le trafic entrant sur son AS (réflexion relative à la question 1).
La deuxième méthode me paraît plus cohérente mais comme l'énoncé précise que l'on ne doit pas toucher aux deux AS en même temps, il ne reste donc que la première méthode.
Voici la configuration sur ASBR6 :
ip bgp-community new-format ! communauté de la forme ASN:xxxxx
ip prefix-list as64501 permit 198.18.0.0/16
route-map setcomm permit 10
match ip address prefix-list as64501
set community 64502:110
route-map setcomm permit 20
router bgp 64502
neighbor 198.19.224.0 route-map setcomm out
neighbor 198.19.224.0 send-community ! sans ça, les communautés ne sont pas tranmises
|
Voici la configuration sur ASBR4 :
ip bgp-community new-format ! communauté de la forme ASN:xxxxx
ip community-list 1 permit 64502:110
route-map getcomm permit 10
match community 1
set local-preference 110
route-map getcomm permit 20
router bgp 64502
neighbor 198.19.224.3 route-map getcomm in
|
On remarque qu'avec cette configuration, on aura le même comportement qu'à la question 3 : seul le trafic destiné à 198.18.0.0/16 passera par le lien de droite, pas les autres préfixes. Pour obtenir strictement le même comportement qu'à la question 2, il suffit qu'ASBR6 tague toutes les routes (pas de match par préfixe ou autre) ou plus simplement, de ne pas utiliser les communautés de cette manière.
On vérifie les tables de routage :
ASBR4#show ip route
O E2 198.18.0.0/16 [110/1] via 198.19.224.1, 00:06:10, FastEthernet2/0
----
IR5#show ip route
O E2 198.18.0.0/16 [110/1] via 198.19.224.3, 00:05:43, FastEthernet2/0
----
ASBR6#show ip route
B 198.18.0.0/16 [20/0] via 198.19.240.1, 00:46:59
|
Question 7
Seule la configuration de Dynagen change dans cette question. Le nouveau fichier utilisé est annexé au présent document.
La topologie réelle est celle-ci :
- PC1 - 192.168.1.2 - AS 64501
- PC2 - 192.168.1.8 - AS 64502
Dynamips crée 2 sockets UDP par liaison pour y encapsuler les échanges. Nous avons 4 liens par AS. Nous aurons donc 6 sockets par machines (4*2 - 2, car la terminaison de deux liaisons sont dans l'autre AS).
Vérification, sur PC1, avec netstat :
PC1#netstat -taupn | grep dynamips
tcp 0 0 0.0.0.0:2000 0.0.0.0:* LISTEN 12460/dynamips
tcp 0 0 0.0.0.0:2001 0.0.0.0:* LISTEN 12460/dynamips
tcp 0 0 0.0.0.0:2002 0.0.0.0:* LISTEN 12460/dynamips
tcp 0 0 0.0.0.0:7200 0.0.0.0:* LISTEN 12460/dynamips
tcp 0 0 192.168.1.2:2001 192.168.1.2:39539 ESTABLISHED 12460/dynamips
tcp 0 0 192.168.1.2:2002 192.168.1.2:60981 ESTABLISHED 12460/dynamips
tcp 0 0 192.168.1.2:7200 192.168.1.2:49847 ESTABLISHED 12460/dynamips
tcp 0 0 192.168.1.2:2000 192.168.1.2:50270 ESTABLISHED 12460/dynamips
udp 0 0 127.0.0.1:10000 127.0.0.1:10001 ESTABLISHED 12460/dynamips
udp 0 0 127.0.0.1:10001 127.0.0.1:10000 ESTABLISHED 12460/dynamips
udp 0 0 192.168.1.2:10002 192.168.1.8:10000 ESTABLISHED 12460/dynamips
udp 0 0 127.0.0.1:10003 127.0.0.1:10004 ESTABLISHED 12460/dynamips
udp 0 0 127.0.0.1:10004 127.0.0.1:10003 ESTABLISHED 12460/dynamips
udp 0 0 192.168.1.2:10005 192.168.1.8:10001 ESTABLISHED 12460/dynamips
|
On a donc les liens 1000<-> 1001 et 1003<->10004 pour les liaisons ASBR1<->IR2<->ASBR3. On a les connexions 192.168.1.2:10002<->192.168.1.8:10000 et 192.168.1.2:10005<->192.168.1.8:10001 pour les liaisons ASBR1<->ASBR4 et ASBR3<->ASBR6 respectivement. Le reste des sockets est habituel : pour les liaisons séries (200X) et pour se brancher à l'hyperviseur (7200).
Avec la commande ping, on constate que les liaisons inter-AS (et donc inter-PC) sont fonctionnelles. Exemple :
ASBR1#ping 198.18.240.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms
|
En faisant une capture du trafic réseau sur les interfaces physiques des PC utilisés, on remarque bien l'échange de paquets entre les 2 dynamips donc entre les deux routeurs de nos 2 AS. Exemple :
Figure 15 - ASBR1, sur PC1, ping ASBR4, sur PC2. Dynamips encapsule le trafic dans des datagrammes UDP.
Bibliographie
Dans l'ordre d'utilisation.
Exercice 3
Exercice 4
Annexes
Fichier de configuration Dynagen pour l'exercice 3/4 (sauf question 8)
[localhost]
[[7200]]
image = ./C7200-AD.BIN
ram = 256
idlepc = 0x607335f0
[[ROUTER ASBR1]]
model = 7200
f1/0 = IR2 f1/0
f2/0 = ASBR4 f1/0
[[ROUTER IR2]]
model = 7200
f2/0 = ASBR3 f1/0
[[ROUTER ASBR3]]
model = 7200
f2/0 = ASBR6 f2/0
[[ROUTER ASBR4]]
model = 7200
f2/0 = IR5 f1/0
[[ROUTER IR5]]
model = 7200
f2/0 = ASBR6 f1/0
[[ROUTER ASBR6]]
model = 7200
|
Commandes IOS pour l'exercice 3 (sauf question 8)
ASBR1
enable
conf t
hostname ASBR1
no ip domain lookup !pas de réso DNS = gain de temps traceroute, ping, ...
int fastEthernet 1/0
ip address 198.18.224.0 255.255.255.254
no shutdown
exit
int fastEthernet 2/0
ip address 198.18.240.0 255.255.255.254
no shutdown
exit
router ospf 1
network 198.18.0.0 0.0.255.255 area 0
passive-interface F2/0 !aucun routeur ne répondra ici, pas la peine de gâcher des ressources
redistribute bgp 64501 subnets
exit
ip route 198.18.0.0 255.255.0.0 Null 0
router bgp 64501
network 198.18.0.0 mask 255.255.0.0
neighbor 198.18.240.1 remote-as 64502
|
IR2
enable
conf t
hostname IR2
no ip domain lookup !pas de réso DNS = gain de temps traceroute, ping, ...
int fastEthernet 1/0
ip address 198.18.224.1 255.255.255.254
no shutdown
exit
int fastEthernet 2/0
ip address 198.18.224.2 255.255.255.254
no shutdown
exit
int loopback 1
ip address 198.18.15.254 255.255.240.0
exit
router ospf 1
network 198.18.0.0 0.0.255.255 area 0
exit
|
ASBR3
enable
conf t
hostname ASBR3
no ip domain lookup !pas de réso DNS = gain de temps traceroute, ping, ...
int fastEthernet 1/0
ip address 198.18.224.3 255.255.255.254
no shutdown
exit
int fastEthernet 2/0
ip address 198.19.240.1 255.255.255.254
no shutdown
exit
router ospf 1
network 198.18.0.0 0.0.255.255 area 0
passive-interface F2/0 !aucun routeur ne répondra ici, pas la peine de gâcher des ressources
redistribute bgp 64501 subnets
exit
ip route 198.18.0.0 255.255.0.0 Null 0
router bgp 64501
network 198.18.0.0 mask 255.255.0.0
neighbor 198.19.240.0 remote-as 64502
|
ASBR4
enable
conf t
hostname ASBR4
no ip domain lookup !pas de réso DNS = gain de temps traceroute, ping, ...
int fastEthernet 1/0
ip address 198.18.240.1 255.255.255.254
no shutdown
exit
int fastEthernet 2/0
ip address 198.19.224.0 255.255.255.254
no shutdown
exit
router ospf 1
network 198.19.0.0 0.0.255.255 area 0
passive-interface F1/0 !aucun routeur ne répondra ici, pas la peine de gâcher des ressources
redistribute bgp 64502 subnets
exit
ip route 198.19.0.0 255.255.0.0 Null 0
router bgp 64502
network 198.19.0.0 mask 255.255.0.0
neighbor 198.18.240.0 remote-as 64501
|
IR5
enable
conf t
hostname IR5
no ip domain lookup !pas de réso DNS = gain de temps traceroute, ping, ...
int fastEthernet 1/0
ip address 198.19.224.1 255.255.255.254
no shutdown
exit
int fastEthernet 2/0
ip address 198.19.224.2 255.255.255.254
no shutdown
exit
int loopback 1
ip address 198.19.15.254 255.255.240.0
exit
router ospf 1
network 198.19.0.0 0.0.255.255 area 0
exit
|
ASBR6
enable
conf t
hostname ASBR6
no ip domain lookup !pas de réso DNS = gain de temps traceroute, ping, ...
int fastEthernet 1/0
ip address 198.19.224.3 255.255.255.254
no shutdown
exit
int fastEthernet 2/0
ip address 198.19.240.0 255.255.255.254
no shutdown
exit
router ospf 1
network 198.19.0.0 0.0.255.255 area 0
passive-interface F2/0 !aucun routeur ne répondra ici, pas la peine de gâcher des ressources
redistribute bgp 64502 subnets
exit
ip route 198.19.0.0 255.255.0.0 Null 0
router bgp 64502
network 198.19.0.0 mask 255.255.0.0
neighbor 198.19.240.1 remote-as 64501
|
Fichier de configuration Dynagen pour la question 8 de l'exercice 3
[localhost]
[[7200]]
image = ./C7200-AD.BIN
ram = 256
idlepc = 0x607335f0
[[ROUTER ASBR1]]
model = 7200
f1/0 = ASBR3 f1/0
f2/0 = ASBR4 f1/0
f3/0 = IR2 f1/0
[[ROUTER IR2]]
model = 7200
[[ROUTER ASBR3]]
model = 7200
f2/0 = ASBR6 f2/0
f3/0 = IR7 f1/0
[[ROUTER ASBR4]]
model = 7200
f2/0 = IR5 f1/0
[[ROUTER IR5]]
model = 7200
f2/0 = ASBR6 f1/0
[[ROUTER ASBR6]]
model = 7200
[[ROUTER IR7]]
model = 7200
|
Commandes IOS pour la question 8 de l'exercice 3
ASBR1
router ospf 1
network 198.18.224.0 0.0.0.1 area 0
network 198.18.224.2 0.0.0.1 area 1
passive-interface F2/0 !aucun routeur ne répondra ici, pas la peine de gâcher des ressources
exit
|
IR2
router ospf 1
network 198.18.224.2 0.0.0.1 area 1
network 198.18.0.0 0.0.15.255 area 1
exit
|
ASBR3
router ospf 1
network 198.18.224.0 0.0.0.1 area 0
network 198.18.224.4 0.0.0.1 area 2
passive-interface F2/0 !aucun routeur ne répondra ici, pas la peine de gâcher des ressources
exit
|
IR7
router ospf 1
network 198.18.224.4 0.0.0.1 area 2
network 198.18.16.0 0.0.15.255 area 2
exit
|
Fichier de configuration Dynagen pour la question 7 de l'exercice 4
[192.168.1.2]
udp=10000
[[7200]]
image = ./C7200-AD.BIN
ram = 256
idlepc = 0x607335f0
[[ROUTER ASBR1]]
model = 7200
f1/0 = IR2 f1/0
f2/0 = ASBR4 f1/0
[[ROUTER IR2]]
model = 7200
f2/0 = ASBR3 f1/0
[[ROUTER ASBR3]]
model = 7200
f2/0 = ASBR6 f2/0
[192.168.1.8]
udp=10000
[[7200]]
image = ./C7200-AD.BIN
ram = 256
idlepc = 0x607335f0
[[ROUTER ASBR4]]
model = 7200
f2/0 = IR5 f1/0
[[ROUTER IR5]]
model = 7200
f2/0 = ASBR6 f1/0
[[ROUTER ASBR6]]
model = 7200
|
Figure 1 - Schéma de ma maquette. D'après l'énoncé.
Figure 2 - Ici, on voit IR2, dont le démon OSPF vient de démarrer, s'initialiser et annoncer les routes qu'il connaît.
Figure 3 - Ici, on voit ASBR6, dont le démon BGP vient de démarrer, initialiser une session BGP avec ASBR3 (TCP handshake + PDU BGP OPEN). Puis vient l'échange des préfixes (PDU BGP UPDATE).
Figure 4 - ether.src : ca:00:53:1e:00:38 (f2/0 de ASBR1) -> ether.dst = ca:03:53:1e:00:1c (f1/0 de ASBR4).
Figure 5 - ether.src = ca:01:53:1e:00:1c (f1/0 d'IR2) -> ether.dst = ca:00:53:1e:00:1c (f1/0 d'ASBR1).
Figure 6 - Les PDU KEEPALIVE d'ASBR1 ne sont pas acquittés par ASBR4 donc sa pile TCP les réémet.
Figure 7 - ASBR1 perd la connectivité vers 198.19.0.0/16 : la métrique explose puis la route ne sera plus annoncée via OSPF.
Figure 8 - IR2 annonce à ASBR1 la route qu'il connaît pour joindre 198.19.0.0/16 : IR2 -> ASBR3 -> ASBR6.
Figure 9 - IR2 n'annonce plus sa loopback en OSPF.
Figure 10 - ASBR6 tente de pinger la loopback 1 d'IR2. ASBR3, auquel ASBR6 a envoyé le paquet, ne connaît aucune route pour aller à cette adresse donc il émet un ICMP dst unreachable.
Figure 11 - IR2 annonce, à nouveau, sa loopback via OSPF.
Figure 12 - Schéma de la nouvelle configuration interne de l'AS 64501.
Figure 13 - ASBR3 annonce, dans l'aire 0, les routes de l'aire 2.
Figure 14 - Quelques secondes plus tard, ASBR1 redistribue les routes de l'aire 2 dans l'aire 1.
Figure 15 - ASBR1, sur PC1, ping ASBR4, sur PC2. Dynamips encapsule le trafic dans des datagrammes UDP.
Les commandes de la fin
Pour avoir un term sur chacun des routeurs de manière pratique, on peut utiliser la commande suivante (si vous utilisez gnome 🙂 ) :
gnome-terminal \
--tab-with-profile=labRO \
--tab-with-profile=labRO -t "ASBR1" -e "telnet localhost 2000" \
--tab-with-profile=labRO -t "IR2" -e "telnet localhost 2001" \
--tab-with-profile=labRO -t "ASBR3" -e "telnet localhost 2002" \
--tab-with-profile=labRO -t "ASBR4" -e "telnet localhost 2003" \
--tab-with-profile=labRO -t "IR5" -e "telnet localhost 2004" \
--tab-with-profile=labRO -t "ASBR6" -e "telnet localhost 2005" \
|
Cette commande vient de johndescs. Attention, le profile avec le nom correspondant (ici : « labRO ») doit exister, voir dans Édition -> Préférences du profil. Le premier onglet contient un terminal vide qui permet d'exécuter des commandes, au cas où ...
On peut aussi utiliser screen pour produire le même résultat :
screen -AdmS labRO -t tab0 bash
screen -S labRO -X screen -t ASBR1 telnet localhost 2000
screen -S labRO -X screen -t IR2 telnet localhost 2001
screen -S labRO -X screen -t ASBR3 telnet localhost 2002
screen -S labRO -X screen -t ASBR4 telnet localhost 2003
screen -S labRO -X screen -t IR5 telnet localhost 2004
screen -S labRO -X screen -t ASBR6 telnet localhost 2005
screen -S labRO -X caption always "%{= wk}%-w%{= BW}%n %t%{-}%+w %-="
|
Le premier onglet contient un terminal vide qui permet d'exécuter des commandes, au cas où ... Les commandes nécéssaires sont les classiques « screen -Rd » pour attacher la session, « screen -S labRO -X quit » pour la quitter de l'extérieur, Ctrl+A + :quit pour quitter la session de l'intérieur, Ctrl+a+d pour détacher screen, Ctrl+a+(n|p|[0-6]) pour naviguer dans les onglets.
