lalahop

TP réseaux d’opérateur II : MPLS/MPLS-TE

Aujourd'hui, suite des travaux pratiques concernant des technologies utilisées par les opérateurs réseaux. Après BGP : MPLS.

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é

Déployer MPLS sur un réseau de test

Topologie plus complexe.

  1. Q1. Dans l’environnement dynamips/dynagen, construire le réseau ci-dessus (le lien R5-R6 a un débit plus faible que les autres). Configurez l’adressage IP et le routage OSPF, ainsi que des adresses de loopback sur chaque routeur. Après avoir vérifié que le réseau IP fonctionne, activez MPLS sur les réseaux d’interconnexion. Visualisez les tables de label des différents routeurs.
  2. Q2. Pour le préfixe P4 de l’interface de loopback de R4, donnez le contenu des tables de routage et de labels des différents routeurs. En déduire les paquets (avec leurs labels) qui vont transiter de R1à R4 (et retour) si on exécute ping P4 depuis R1. Vérifiez (ou infirmez) ce comportement avec des captures de trames analysées avec wireshark et avec traceroute.
  3. Q3. Les labels utilisés de R2 à R3 (pour un même préfixe, par exemple P4) dépendent-ils de l’interface d’entrée dans R2 ? Un label peut-il être utilisé dans les deux sens sur le même lien ? Peut-il être utilisé sur plusieurs liens d’un même routeur ?
  4. Q4. Les routeurs utilisent-ils le penultimate popping ? Montrez l’effet sur le plus long tunnel.
  5. Q5. Étudiez et montrez l’effet de la commande de configuration : [no] mpls ip propagate-ttl
  6. Q6. Étudiez et montrez l’effet de la commande de configuration : [no] mpls ip ttl-expiration pop labels
  7. Q7. Quels sont les types de tunnels que vous pouvez construire via ces commandes ? Qu’observez vous au niveau des chemins A/R ?
  8. Q8. Un nouveau préfixe P5 est ajouté sur R4 (interface lo1 sur R4). Décrivez tous les échanges de protocole (OSPF, LDP, etc) qui ont lieu suite à cette configuration. L’affectation des labels est elle downstream on demand (justifiez votre réponse) ?
  9. Q9. De même si le lien R1-R2 est coupé, quels sont les échanges des différents protocoles ?
  10. Q10. Demo de routage contraint : illustrez l’algorithme CSPF/MPLS-TE via avec les chemins et les capacités de votre choix.

Cet énoncé est 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 II : MPLS. Et comme à chaque fois, les sources LaTeX sont disponibles ici : sources LaTeX.

Le travail ci-dessous a été réalisé conjointement avec Hamza HMAMA.

Avant de commencer

Adressage IPv4

Concernant l'adressage IP, nous avons décidé de choisir notre préfixe dans la plage réservée à l'IANA pour les tests : 198.18.0.0/15. Pour une plus grande facilité, nous avons décidé d'utiliser le sous-préfixe 198.18.0.0/16.

Pour faciliter l'adressage, nous avons décidé de découper ce préfixe en plusieurs préfixes de longueur /20 :

  1. Les premiers /20 sont dédiés aux "services" : chacune des loopback demandées dans l'énoncé se trouvera dans un /20 différent.
  2. Le milieu est réservé pour un usage futur (expansion des "services", expansion des interconnexions, ...).
  3. Le dernier /20 est dédié aux interconnexions des routeurs internes. Il sera découpé en /31, chaque /31 étant dédié à une interconnexion.

Nous ne prévoyons pas d'avoir plus de 2048 interconnexions internes mais si c'était le cas, on prendrait des préfixes dans le milieu en suivant mais en partant de la fin.

Les interconnexions se font en /31 car les IPv4 sont rares et il faut donc les économiser. Même si nous utilisons un préfixe de documentation/test, nous avons fait ce choix car, d'après nos 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, ...).

Les préfixes de nos loopback seront :

  • R1 - P1 : 198.18.15.254/20
  • R2 - P2 : 198.18.31.254/20
  • R3 - P3 : 198.18.47.254/20
  • R4 - P4 : 198.18.63.254/20
  • R5 - P5 : 198.18.79.254/20
  • R6 - P6 : 198.18.95.254/20

Note : les sorties des commandes de vérification (show ...) seront allégées/tronquées pour ne garder que l'essentiel afin de ne pas surcharger ce rapport.

Schéma

En figure 1 se trouve le schéma donné dans l'énoncé complété avec notre plan d'adressage.

Schéma de notre maquette

Figure 1 - Schéma de notre maquette. D'après l'énoncé.

Question 1

La configuration de dynagen pour ce TP est donnée en annexe 1.

La configuration des routeurs se fait facilement : il n'y a pas de commandes que nous n'avons pas vues lors du premier TP ou qui n'ont pas été données lors de la séance de TP. Les configurations intégrales de nos routeurs se trouvent en annexe 2.

Pour illustration, voici un extrait de la LIB (Label Information Base) et la LFIB (Label Forwarding Information Base) de notre routeur R1 :

R1#show mpls ldp bindings 
[...]
  tib entry: 198.18.31.254/32, rev 8
	local binding:  tag: 16
	remote binding: tsr: 198.18.79.254:0, tag: 26
  tib entry: 198.18.47.254/32, rev 24
	local binding:  tag: 23
	remote binding: tsr: 198.18.79.254:0, tag: 19
	remote binding: tsr: 198.18.31.254:0, tag: 23
  tib entry: 198.18.63.254/32, rev 26
	local binding:  tag: 24
	remote binding: tsr: 198.18.79.254:0, tag: 27
	remote binding: tsr: 198.18.31.254:0, tag: 24
[...]
  tib entry: 198.18.240.10/31, rev 18
        local binding:  tag: 20
        remote binding: tsr: 198.18.79.254:0, tag: 22
        remote binding: tsr: 198.18.31.254:0, tag: 19
  tib entry: 198.18.240.12/31, rev 16
        local binding:  tag: 19
        remote binding: tsr: 198.18.79.254:0, tag: 18
        remote binding: tsr: 198.18.31.254:0, tag: 20
  tib entry: 198.18.240.14/31, rev 20
        local binding:  tag: 21
        remote binding: tsr: 198.18.79.254:0, tag: 23
        remote binding: tsr: 198.18.31.254:0, tag: 21
 
 
R1#show mpls forwarding-table
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface              
16     Untagged    198.18.31.254/32  0          Fa1/0      198.18.240.1 
17     Pop tag     198.18.240.4/31   0          Fa2/0      198.18.240.3 
       Pop tag     198.18.240.4/31   0          Fa1/0      198.18.240.1 
18     Pop tag     198.18.240.6/31   0          Fa1/0      198.18.240.1 
19     20          198.18.240.12/31  0          Fa1/0      198.18.240.1 
20     19          198.18.240.10/31  0          Fa1/0      198.18.240.1 
21     21          198.18.240.14/31  0          Fa1/0      198.18.240.1 
22     Pop tag     198.18.240.8/31   0          Fa2/0      198.18.240.3 
23     23          198.18.47.254/32  0          Fa1/0      198.18.240.1 
24     24          198.18.63.254/32  0          Fa1/0      198.18.240.1 
25     Untagged    198.18.79.254/32  0          Fa2/0      198.18.240.3 
26     26          198.18.95.254/32  0          Fa1/0      198.18.240.1 
27     27          198.18.111.254/32 0          Fa1/0      198.18.240.1

On observe aussi que chaque routeur crée automatiquement un LSP vers la loopback de chaque autre routeur, ce qui est le comportement attendu.

Question 2

Pour répondre à cette question, nous nous sommes mis dans la situation où nous pingons P4 en mettant P1 en adresse source. Il est toujours mieux de pinger d'une loopback à l'autre. Nous ferons ainsi pour le reste de ce TP.

On interroge récursivement les LFIB de nos routeurs. D'abord pour l'aller :

R1#show mpls forwarding-table 198.18.63.254           
24     24          198.18.63.254/32  0          Fa1/0      198.18.240.1 ! -> R2
 
R2#show mpls forwarding-table 198.18.63.254            
24     24          198.18.63.254/32  0          Fa3/0      198.18.240.7 ! -> R3 
 
R3#show mpls forwarding-table 198.18.63.254      
24     Untagged    198.18.63.254/32  0          Fa2/0      198.18.240.11 ! -> R4

Puis pour le retour :

R4#show mpls forwarding-table 198.18.15.254        
22     22          198.18.15.254/32  0          Fa1/0      198.18.240.10 ! -> R3
 
R3#show mpls forwarding-table 198.18.15.254            
22     16          198.18.15.254/32  0          Fa1/0      198.18.240.6 ! -> R2
 
R2#show mpls forwarding-table 198.18.15.254     
16     Untagged    198.18.15.254/32  0          Fa1/0      198.18.240.0 ! -> R1

À l'aller, on aura donc le chemin et les labels MPLS suivants :
R1 -> [24] -> R2 -> [24] -> R3 -> [] -> R4

Au retour, on aura le chemin et les labels MPLS suivants :
R4 -> [22] -> R3 -> [16] -> R2 -> [] -> R1

Vérifications avec des traceroute :

R1#traceroute 198.18.63.254 source 198.18.15.254
  1 198.18.240.1 [MPLS: Label 24 Exp 0] 8 msec 20 msec 12 msec
  2 198.18.240.7 [MPLS: Label 24 Exp 0] 8 msec 8 msec 8 msec
  3 198.18.240.11 44 msec *  16 msec
 
R4#traceroute 198.18.15.254 source 198.18.63.254
  1 198.18.240.10 [MPLS: Label 22 Exp 0] 12 msec 44 msec 44 msec
  2 198.18.240.6 [MPLS: Label 16 Exp 0] 40 msec 8 msec 12 msec
  3 198.18.240.0 8 msec *  16 msec

Vérification avec nos captures réseau. À l'aller :

Capture réseau. Ping P4 (198.18.63.254) depuis P1 (198.18.15.254). Aller

Figure 2 - Capture réseau. Ping P4 (198.18.63.254) depuis P1 (198.18.15.254). Aller.

Au retour :

Capture réseau. Ping P4 (198.18.63.254) depuis P1 (198.18.15.254). Retour

Figure 3 - Capture réseau. Ping P4 (198.18.63.254) depuis P1 (198.18.15.254). Retour.

Question 3

Avant de répondre, regardons les LFIB de R1, R5, R2 et R3 :

R1#show mpls forwarding-table 198.18.63.254           
24     24          198.18.63.254/32  0          Fa1/0      198.18.240.1
 

R5#show mpls forwarding-table 198.18.63.254
27     24          198.18.63.254/32  0          Fa2/0      198.18.240.4
 
R2#show mpls forwarding-table 198.18.63.254            
24     24          198.18.63.254/32  0          Fa3/0      198.18.240.7
 
R3#show mpls forwarding-table 198.18.63.254
24     Untagged    198.18.63.254/32  2474       Fa2/0      198.18.240.11

On constate bien que, quelle que soit l'interface d'entrée dans R2, un paquet à destination de P4 sera toujours tagué avec le label 24. Pour commuter un paquet destiné à P4, R3 attend qu'il soit tagué avec le label 24, peu importe quel routeur, "caché" derrière R2, a envoyé ce paquet. Cela est tout à fait logique : il y a un label par destination par routeur.

Un même label ne peut pas être utilisé dans deux sens sur un même lien car il y a un label par destination et il faut éviter la formation de boucles. Supposons que, pour le retour de la question 2, R4 aurait envoyé un paquet tagué avec le label 24 à R3. Pour R3, 24 est associé à 198.18.63.254 via R4. R3 aurait donc transféré ce paquet à R4, non à R2 (pour que lui-même transmette à R1).

Un même label peut être utilisé sur plusieurs liens d'un même routeur mais pour une même destination uniquement. Illustration :

R5#traceroute 198.18.111.254 source 198.18.79.254 
  1 198.18.240.9 [MPLS: Label 26 Exp 0] 12 msec 12 msec 12 msec
  2 198.18.240.12 [MPLS: Label 26 Exp 0] 12 msec 12 msec 12 msec
  3 198.18.240.11 8 msec *  28 msec

Ici, on a coupé les liens R2<->R3 et R6<->R4. On constate qu'entre R5 et R6, le label utilisé est 26 qui est le même entre R6 et R3. On a donc deux liens, partant du même routeur (R6), qui portent le même label pour une même destination.

Question 4

La fonctionnalité penultimate hop popping permet de faire supprimer le label non pas par le routeur de sortie, l'Egress, mais par l'avant-dernier. Cela permet d'éviter au routeur Egress une double itération : l'une dans sa LFIB et l'autre dans sa table de routage IP. L'opération de recherche sur le label dans sa LFIB est inutile, car dans tous les cas le routeur devra effectuer une recherche dans sa table de routage IP. En utilisant la fonctionnalité PHP, l'Egress doit simplement faire une recherche dans sa table de routage IP.

Par défaut, les routeurs Cisco font du penultimate popping. Source : http://www.cisco.com/en/US/docs/routers/asr9000/software/mpls/configuration/guide/gcasr9kldp.html.

Pour constater ce phénomène, il suffit de revenir à la question 2 : quand R1 veut joindre la loopback de R4, c'est R3, qui est directement connecté à R4, qui supprime le label. On a donc du penultimate hop popping.

Si l'on faisait un traceroute entre deux adresses IP de lien (pas des loopback), comme 198.18.240.0->198.18.240.11, on observerait que l'on perd un label MPLS supplémentaire (R2 supprimerait le label) ce qui correspond bien au comportement du PHP.

Question 5

Cette commande permet d'activer ou de désactiver la propagation du TTL depuis le paquet IP original vers le header MPLS. La désactivation de cette propagation est utilisée par les opérateurs qui veulent masquer les tunnels MPLS de leurs réseaux.

Par défaut, les routeurs Cisco propagent le TTL IP vers MPLS. Source : http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_m1.html#wp1013846

Quand la fonctionnalité est activée, un traceroute met en évidence tous les routeurs d'un chemin comme nous l'avons vu lors des questions précédentes.

Il suffit de désactiver la fonctionnalité sur l'Ingress pour qu'elle soit prise en compte. En effet, quelle que soit la configuration des autres routeurs, seule celle de l'Ingress compte : si ce dernier met un TTL fixe (255 sur Cisco, mais cela change selon les équipementiers) car la propagation est désactivée, il est ensuite trop tard pour revenir sur ce choix.

Illustration : nous désactivons le propagate-ttl sur R1 et nous faisons un traceroute vers R4 :

traceroute 198.18.63.254 source 198.18.15.254
  1 198.18.240.7 [MPLS: Label 23 Exp 0] 12 msec 8 msec 8 msec
  2 198.18.240.11 48 msec *  8 msec

On constate bien que l'absence de la propagation du TTL du paquet IP original vers le header MPLS. Cela fait que les routeurs intermédiaires du tunnel MPLS (ici : R2) disparaissent du traceroute.

Question 6

Cette commande permet de spécifier comment une réponse ICMP à un paquet ayant un TTL expiré est renvoyée : on utilise MPLS ou la table de routage IP ? Plus précisément, elle permet de définir un seuil. Si le nombre de labels dans le paquet reçu est supérieur à ce seuil, alors le paquet sera commuté avec MPLS. Sinon, on utilisera le routage IP classique.

La commande mpls ip ttl-expiration pop 1 est la commande la plus utilisée par les opérateurs pour activer le transfert (forward) basé sur plusieurs labels.

Le détail de la fonctionnalité est donné en : http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_m1.html#wp1013945.

Vérification :

Dans un premier temps, on utilise la configuration par défaut, c'est-à-dire sans la fonctionnalité ttl-expiration pop.

On fait alors un traceroute de 100 paquets avec un TTL fixé à 1 entre la loopback de R1 et celle de R4. R2 va recevoir les paquets. Il va le supprimer et générer un message ICMP TTL exceeded pour chacun des 100 paquets. Ces paquets vont être transférés jusqu'à R4 qui va les renvoyer à R1 via R3 et R2.

Pour illustrer cela, nous regardons les statistiques de l'interface f1/0 (qui est connectée à R3) de R4 : on remarque que R4 a reçu les 100 paquets ICMP et les a retransmis par la même interface.

Avant (ligne « Route cache ») :

R4#show int F1/0 stats
FastEthernet1/0
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor      35903    3130038      35580    3065492
              Route cache      1012     184184       1030     191580 
                   Total      36915    3314222      36610    3257072

Commande utilisée :

R1#traceroute          
Protocol [ip]: 
Target IP address: 198.18.63.254
Source address: 198.18.15.254
Numeric display [n]: 
Timeout in seconds [3]: 1
Probe count [3]: 100
Minimum Time to Live [1]: 1
Maximum Time to Live [30]: 1
Port Number [33434]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Type escape sequence to abort.
Tracing the route to 198.18.63.254
 
  1 198.18.240.1 [MPLS: Label 24 Exp 0] 68 msec 44 msec 12 msec 12 msec 12 msec 
8 msec 12 msec 8 msec 52 msec 8 msec 12 msec 44 msec 40 msec 8 msec 12 msec 
12 msec 8 msec 44 msec 44 msec 12 msec 12 msec 12 msec 8 msec 12 msec 12 msec 
[...]

Après (ligne « Route cache ») :

R4#show int F1/0 stats
FastEthernet1/0
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor      35912    3130722      35588    3066070
             Route cache       1112     202384       1130     210180 
                   Total      37024    3333106      36718    3276250

On voit bien qu'il y a eu précisément 100 paquets reçus et réémis.

Illustration :

On observe que R4 reçoit bien les paquets ICMP exceeded

Figure 4 - On observe que R4 reçoit bien les paquets ICMP exceeded.

Dans un deuxième temps, on utilise la fonctionnalité ttl-expiration pop 1 et on reproduit l'expérience donnée ci-dessus. R2 va donc recevoir les 100 paquets. Puisqu'on a un seul label, R2 va poper le label et émettre des messages ICMP TTL exceeded en utilisant la table de routage IP. Cela fait que, dans ce cas, les messages ICMP vont être retransmis directement à R1 sans passer par R3 et R4.

Avant :

R4#show int F1/0 stats
FastEthernet1/0
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor      35966    3135652      35640    3070754
             Route cache       1112     202384       1130     210180 
                   Total      37078    3338036      36770    3280934

Commande utilisée :

R1#traceroute   
Protocol [ip]:           
Target IP address: 198.18.63.254
Source address: 198.18.15.254
Numeric display [n]:              
Timeout in seconds [3]: 1
Probe count [3]: 100
Minimum Time to Live [1]: 1
Maximum Time to Live [30]: 1
Port Number [33434]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Type escape sequence to abort.
Tracing the route to 198.18.63.254
 
  1 198.18.240.1 [MPLS: Label 24 Exp 0] 32 msec 4 msec 4 msec 4 msec 4 msec 4 msec
 8 msec 32 msec 4 msec 4 msec 4 msec 8 msec 8 msec 32 msec 4 msec 4 msec 8 msec
4 msec 4 msec 4 msec 40 msec 4 msec 4 msec 4 msec 4 msec 4 msec 40 msec 4 msec
[...]

On remarque un RTT moyen inférieur à celui obtenu lors de la première étape ce qui tend à confirmer, dans le contexte de notre maquette (la réalité demanderait plus de prudence), que le chemin de retour est raccourci.

Après :

R4#show int F1/0 stats
FastEthernet1/0
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor      35968    3135822      35644    3071060
             Route cache       1112     202384       1130     210180 
                   Total      37080    3338206      36774    3281240

Question 7

Il y a quatre types de tunnels :

  1. Explicit : support du RFC 4950 et activation du propagate-ttl. On voit donc chaque routeur et l'on sait qu'il y a un tunnel MPLS.
  2. Implicit : pas de support du RFC 4950 et activation du propagate-ttl. On voit donc chaque routeur mais l'on ne sait pas qu'il y a un tunnel MPLS.
  3. Opaque : support du RFC 4950 et désactivation du propagate-ttl. On voit donc uniquement le dernier routeur du tunnel MPLS ainsi que la destination et l'on sait qu'il y a un tunnel MPLS sans avoir les détails du tunnel (routeurs intermédiaires).
  4. Invisible : pas de support du RFC 4950 et désactivation du propagate-ttl. On ne voit pas les routeurs intermédiaires du tunnel et l'on ne sait pas qu'il y a un tunnel MPLS sur le chemin.
Les différents types de tunnels MPLS en fonction des fonctions supportées/activées

Figure 5 - Les différents types de tunnels MPLS en fonction des fonctions supportées/activées. Source : http://www.slideshare.net/edge7/slides-mpls-tunnel.

Quand on utilise propagate-ttl sur l'Ingress, on obtient un tunnel explicit. Exemple : de la loopback de R1 à celle de R4.

R1#traceroute 198.18.63.254 source 198.18.15.254
  1 198.18.240.1 [MPLS: Label 24 Exp 0] 8 msec 8 msec 8 msec
  2 198.18.240.7 [MPLS: Label 23 Exp 0] 8 msec 8 msec 8 msec
  3 198.18.240.11 8 msec *  16 msec

Quand on désactive propagate-ttl sur l'Ingress, on obtient un tunnel opaque. Exemple : de la loopback de R1 à celle de R4.

R1#traceroute 198.18.63.254 source 198.18.15.254
  1 198.18.240.7 [MPLS: Label 23 Exp 0] 8 msec 8 msec 44 msec
  2 198.18.240.11 8 msec *  8 msec

On ne peut pas obtenir les deux autres types de tunnels car cela nécessite de désactiver les extensions du RFC 4950 et il n'y a pas de commandes sur l'IOS pour faire ça. La seule solution est d'utiliser une ancienne image de l'IOS sortie avant la publication du RFC 4950.

Nous avons essayé quelques images (localisées avec un moteur de recherche et « intitle:"index of" IOS [7200] ») sans succès : même la version 12.0 de l'IOS de la série 7200 supporte les extensions du RFC 4950 ! Comme ce point n'est pas le plus fondamental de ce TP, nous n'avons pas insisté.

Par défaut, c'est-à-dire avec la propagation du TTL IP vers MPLS et la fonctionnalité ttl-expiration pop désactivée, les réponses echo-reply seront directement émises et transmises à la source (la machine qui a lancé l'echo request) alors que les messages ICMP TTL-exceeded seront transmis à la source en passant d'abord par le dernier routeur du tunnel. C'est ce que résume l'illustration suivante :

Différence de chemin A/R entre un echo request/reply et un ttl-exceeded

Figure 6 - Différence de chemin A/R entre un echo request/reply et un ttl-exceeded. Source : http://www.caida.org/publications/papers/2012/revealing_mpls_tunnels/revealing_mpls_tunnels.pdf.

Illustration entre la loopback de R1 et celle de R4 :

R1#traceroute   
Protocol [ip]:           
Target IP address: 198.18.63.254
Source address: 198.18.15.254
Numeric display [n]:              
Timeout in seconds [3]: 1            
Probe count [3]: 1
Minimum Time to Live [1]: 
Maximum Time to Live [30]: 
Port Number [33434]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Type escape sequence to abort.
Tracing the route to 198.18.63.254
 
  1 198.18.240.1 [MPLS: Label 23 Exp 0] 32 msec
  2 198.18.240.7 [MPLS: Label 23 Exp 0] 48 msec
  3 198.18.240.11 8 msec

Avec une capture réseau, nous voyons que le message ICMP TTL-exceeded de R2 (198.18.240.1) revient avec un TTL de 251 :

Quand R1 fait un traceroute vers R4, R2 envoie un ICMP TTL-exceeded avec un TTL de 251

Figure 7 - Quand R1 fait un traceroute vers R4, R2 envoie un ICMP TTL-exceeded avec un TTL de 251.

Or, un ping direct sur 198.18.240.1 nous indique qu'il n'y a pas de routeur intermédiaire entre R1 et R2 :

Quand R1 fait ping vers 198.18.240.1, on observe un TTL de 255

Figure 8 - Quand R1 fait ping vers 198.18.240.1, on observe un TTL de 255.

Donc le message ICMP ttl-exceeded a fait le tour de notre tunnel MPLS alors que l'echo reply est revenu directement.

Concernant le traceroute, R2 a reçu un paquet IP avec un TTL de 1. Il effectue la décrémentation avant transfert. Il se rend compte que le TTL est de 0. Il détruit le paquet et émet un message ICMP TTL-exceeded à destination de R1. Ce nouveau paquet IP a donc un TTL de 255. Le paquet arrive en R3, qui va décrémenter le TTL (254) puis transmettre le paquet à R4 qui va décrémenter le TTL (253) puis transmettre le paquet à R3 qui va décrémenter à nouveau le TTL (252) puis transmettre le paquet à R2 qui va décrémenter le TTL (251) puis transmettre à R1.

En excluant le dernier saut R2-> R1 du message ICMP, on se rend compte qu'il y a 3 routeurs intermédiaires et que 198.18.240.11 est l'Egress d'un tunnel MPLS et que R2 et R3 sont aussi traversés par ce tunnel.

On pourra confirmer cela en analysant les TTL des autres messages ICMP TTL-exceeded (ceux de R3 et R4).

C'est sur cette différence entre les TTL que se base la détection des tunnels MPLS implicit.

Question 8

Le nouveau préfixe P5 sera 198.18.111.254.

Théoriquement, R4 devra annoncer la nouvelle loopback via OSPF puis on devrait avoir des échanges LDP.

Vérification : on obtient bien le comportement décrit ci-dessus.

R4 annonce sa nouvelle loopback en OSPF

Figure 9 - R4 annonce sa nouvelle loopback en OSPF.

R4 annonce sa nouvelle loopback via LDP

Figure 10 - R4 annonce sa nouvelle loopback via LDP.

Attribution des labels pour la nouvelle loopback : pour transmettre des paquets à destination de la nouvelle loopback, R3 attend qu'ils soient tagués avec le label 26

Figure 11 - Attribution des labels pour la nouvelle loopback : pour transmettre des paquets à destination de la nouvelle loopback, R3 attend qu'ils soient tagués avec le label 26.

Non, l'attribution des labels n'est pas downstream on demand car, dans ce mode-là, un PDU LDP Request descend depuis l'Ingress et une réponse LDP Mapping remonte jusqu'à l'Ingress.

Or, dans notre cas, R4 ne répond pas à une requête mais informe spontanément ses voisins. On est donc dans un mode unsollicited downstream où c'est l'Egress qui initie le mapping.

Question 9

Théoriqement, des messages OSPF de type LS UPDATE seront émis et l'on constatera la disparition du lien R1<->R2. Puis, des échanges LDP devront aussi indiquer la disparition du voisin.

Vérification : on "éteint" l'interface f1/0 de R1.

R2 émet un LS UPDATE dans lequel il n'annonce plus avoir un lien avec R1 (absence de 198.18.240.0 et de 198.18.15.254)

Figure 12 - R2 émet un LS UPDATE dans lequel il n'annonce plus avoir un lien avec R1 (absence de 198.18.240.0 et de 198.18.15.254).

R2 annonce à R3 la disparition de R1 (198.18.240.0) avec un message LDP Withdrawal. R3 annonce la disparition d'un routeur en amont (R1) avec un message LDP Release

Figure 13 - R2 annonce à R3 la disparition de R1 (198.18.240.0) avec un message LDP Withdrawal. R3 annonce la disparition d'un routeur en amont (R1) avec un message LDP Release.

Dans le même temps, R1 annoncera aussi, à R5, en OSPF et via LDP, sa perte de connectivité avec R2.

On observe le même comportement (LS UPDATE puis LDP Withdrawal puis LDP Release) sur R5. Sur les autres routeurs, on aura LS UPDATE et LDP Release.

Question 10

Voici le schéma de notre maquette avec la capacité réservable pour chaque lien.

Schéma de notre maquette avec la capacité réservable sur chaque lien

Figure 14 - Schéma de notre maquette avec la capacité réservable sur chaque lien. D'après l'énoncé.

Notes :

  • Sur chaque lien, nous n'avons pas l'égalité « capacité réservable = capacité réelle » car nous avons laissons de la place pour le trafic best-effort comme cela est recommandé.
  • Dans un premier temps, nous avons un seul niveau de priorité.

Pour mettre en œuvre l'ingénierie de trafic sur notre maquette, il faut activer les tunnels TE et OSPF-TE puis indiquer, pour chaque lien, la capacité réservable. Sur les routeurs Cisco, cela se fait avec les commandes suivantes (ici, sur R1) :

!Tunnels TE
mpls traffic-eng
 
!OSPF-TE
router ospf 1
mpls traffic-eng router-id Loopback1
mpls traffic-eng area 0
 
!Pour chaque lien, la capacité réservable
interface FastEthernet1/0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 50000 50000

Les configurations intégrales de nos routeurs se trouvent en annexe 3.

On remarque que, dès l'activation d'OSPF-TE sur R1, celui-ci annonce de nouveaux LSA, des LSA-TE, qui se propagent dans toute notre maquette. Ici, sur R4 :

R1 annonce la capacité du lien R1<->R2 mais indique une capacité réservable nulle

Figure 15 - R1 annonce la capacité du lien R1<->R2 mais indique une capacité réservable nulle.

Puis, quand on configure la capacité réservable sur le lien R1<->R2, R1 l'annonce dans ses LSA-TE. Toujours sur R4 :

Maintenant, R1 annonce aussi la capacité réservable sur le lien R1<->R2

Figure 16 - Maintenant, R1 annonce aussi la capacité réservable sur le lien R1<->R2.

Nous pouvons maintenant construire nos tunnels. Nous avons choisi de construire 3 tunnels :

  1. T0, de R1 jusqu'à P4 : 30. Ce tunnel nous permettra de constater que ce n'est pas toujours le chemin le plus court qui est sélectionné mais celui qui répond d'abord à la contrainte de capacité.
  2. T1, de R1 jusqu'à P3 : 3. Ce tunnel nous permettra de constater ce qui arrive quand le lien R2<->R3 n'a plus de capacité réservable.
  3. T2, de R1 jusqu'à P6 : 15. Ce tunnel nous permettra de constater ce qui arrive quand une contrainte ne peut pas être satisfaite.

Créons T0 :

interface Tunnel0
ip unnumbered Loopback1
tunnel destination 198.18.63.254
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce 
tunnel mpls traffic-eng priority 1 1 
tunnel mpls traffic-eng bandwidth 30000
tunnel mpls traffic-eng path-option 1 dynamic
no routing dynamic

Nous constatons qu'un PDU RSVP-TE de type PATH part de R1 jusqu'à R4 en passant par R2, R3 et R6. Illustrations sur R1 et R2 :

R1 fait sa demande de tunnel avec un PDU RSVP-TE de type PATH

Figure 17 - R1 fait sa demande de tunnel avec un PDU RSVP-TE de type PATH.

R2 transmet simplement la demande de tunnel de R1

Figure 18 - R2 transmet simplement la demande de tunnel de R1.

R4 est en mesure de satisfaire la demande et il répond donc à R1 avec un PDU RSVP-TE de type RESV. Cette fois-ci, le message est adressé au prochain nœud du chemin : R6.

R4 émet un PDU RSVP-TE de type RESV à destination de R6

Figure 19 - R4 émet un PDU RSVP-TE de type RESV à destination de R6.

R6 peut satisfaire la demande et émet donc un nouveau PDU RSVP-TE RESV à R3.

R6 émet un PDU RSVP-TE de type RESV à destination de R3

Figure 20 - R6 émet un PDU RSVP-TE de type RESV à destination de R3.

Cela continue jusqu'à R1 :

R1 reçoit le PDU RSVP-TE RESV de R2 et sait donc que son tunnel TE est prêt

Figure 21 - R1 reçoit le PDU RSVP-TE RESV de R2 et sait donc que son tunnel TE est prêt.

En parallèle, OSPF propage les nouvelles métriques TE pour tenir compte des changements concernant la capacité réservable sur les liens traversés. Exemple : R2 annonce qu'on ne peut plus réserver de capacité sur le lien R2<->R3 sauf si l'on est plus prioritaire que le précédent demandeur (comme R1 était en priorité 1, il faut être en priorité 0) :

R2 annonce, en OSPF, que plus aucune capacité n'est réservable sur le lien R2<->R3

Figure 22 - R2 annonce, en OSPF, que plus aucune capacité n'est réservable sur le lien R2<->R3.

On vérifie la bonne création du tunnel sur R1 :

R1#show mpls traffic-eng tunnels Tunnel 0
Name: R1_t0                               (Tunnel0) Destination: 198.18.63.254
  Status:
    Admin: up         Oper: up     Path: valid       Signalling: connected
 

    path option 1, type dynamic (Basis for Setup, path weight 4)
 
  InLabel  :  - 
  OutLabel : FastEthernet1/0, 18
  RSVP Signalling Info:
       Src 198.18.15.254, Dst 198.18.63.254, Tun_Id 0, Tun_Instance 86
    RSVP Path Info:
      My Address: 198.18.240.0   
      Explicit Route: 198.18.240.1 198.18.240.6 198.18.240.7 198.18.240.12 
                      198.18.240.13 198.18.240.15 198.18.240.14 198.18.63.254 
      Record Route:  NONE
      Tspec: ave rate=30000 kbits, burst=1000 bytes, peak rate=30000 kbits
    RSVP Resv Info:
      Record Route:  NONE
      Fspec: ave rate=30000 kbits, burst=1000 bytes, peak rate=30000 kbits
  Shortest Unconstrained Path Info:
    Path Weight: 3 (TE)
    Explicit Route: 198.18.240.0 198.18.240.1 198.18.240.6 198.18.240.7 
                    198.18.240.10 198.18.240.11 198.18.63.254 
 
R1#traceroute 198.18.63.254 source 198.18.15.254
  1 198.18.240.1 [MPLS: Label 16 Exp 0] 20 msec 40 msec 40 msec
  2 198.18.240.7 [MPLS: Label 27 Exp 0] 80 msec 12 msec 12 msec
  3 198.18.240.13 [MPLS: Label 27 Exp 0] 80 msec 44 msec 40 msec
  4 198.18.240.14 44 msec *  56 msec

On constate que le tunnel est en cours de fonctionnement et que, comme prévu, le chemin suivi n'est pas le plus court mais celui qui respecte la contrainte de capacité : R1<->R2<->R3<->R6<->R4.

Créons notre deuxième tunnel (T1) :

interface Tunnel1
ip unnumbered Loopback1
tunnel destination 198.18.47.254
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce 
tunnel mpls traffic-eng priority 1 1 
tunnel mpls traffic-eng bandwidth 4000 
tunnel mpls traffic-eng path-option 1 dynamic
no routing dynamic

Nous passons le processus et nous regardons directement le résultat sur R1 :

R1#show mpls traffic-eng tunnels Tunnel 1
Name: R1_t1                               (Tunnel1) Destination: 198.18.47.254
  Status:
    Admin: up         Oper: up     Path: valid       Signalling: connected
 
    path option 1, type dynamic (Basis for Setup, path weight 12)
 
  InLabel  :  - 
  OutLabel : FastEthernet2/0, 16
  RSVP Signalling Info:
       Src 198.18.15.254, Dst 198.18.47.254, Tun_Id 1, Tun_Instance 12
    RSVP Path Info:
      My Address: 198.18.240.2   
      Explicit Route: 198.18.240.3 198.18.240.8 198.18.240.9 198.18.240.13 
                      198.18.240.12 198.18.47.254 
      Record Route:  NONE
      Tspec: ave rate=4000 kbits, burst=1000 bytes, peak rate=4000 kbits
    RSVP Resv Info:
      Record Route:  NONE
      Fspec: ave rate=4000 kbits, burst=1000 bytes, peak rate=4000 kbits
  Shortest Unconstrained Path Info:
    Path Weight: 2 (TE)
    Explicit Route: 198.18.240.0 198.18.240.1 198.18.240.6 198.18.240.7 
                    198.18.47.254
R1#traceroute 198.18.47.254 source 198.18.15.254
  1 198.18.240.3 [MPLS: Label 16 Exp 0] 44 msec 8 msec 8 msec
  2 198.18.240.9 [MPLS: Label 28 Exp 0] 8 msec 12 msec 12 msec
  3 198.18.240.12 8 msec *  8 msec

On constate que le tunnel est fonctionnel. Comme il n'y a plus de capacité disponible sur le lien R2<->3 et que l'on n'est pas plus prioritaire que le créateur du tunnel précédent, on passe par le lien R5<->R6 qui, là encore, n'est pas le plus court chemin mais celui qui satisfait notre contrainte de capacité.

Créons notre dernier tunnel :

interface Tunnel2
ip unnumbered Loopback1
tunnel destination 198.18.95.254
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce 
tunnel mpls traffic-eng priority 1 1 
tunnel mpls traffic-eng bandwidth 15000 
tunnel mpls traffic-eng path-option 1 dynamic
no routing dynamic

Regardons le résultat sur R1 :

R1#show mpls traffic-eng tunnels Tunnel 2
Name: R1_t2                               (Tunnel2) Destination: 198.18.95.254
  Status:
    Admin: up         Oper: down   Path: not valid   Signalling: Down
    path option 1, type dynamic
  Config Parameters:
    Bandwidth: 15000    kbps (Global)  Priority: 1  1   Affinity: 0x0/0xFFFF
    Metric Type: TE (default)
    AutoRoute:  enabled   LockDown: disabled  Loadshare: 15000    bw-based
    auto-bw: disabled
  Shortest Unconstrained Path Info:
    Path Weight: 3 (TE)
    Explicit Route: 198.18.240.0 198.18.240.1 198.18.240.6 198.18.240.7 
                    198.18.240.12 198.18.240.13 198.18.95.254 
      Last Error: PCALC:: No path to destination, 198.18.95.254

Le tunnel n'est pas fonctionnel car la contrainte TE n'a pas pu être satisfaite : le lien R2<->R3 est "plein" et nous ne sommes pas plus prioritaires. De plus, la capacité que nous demandons ne peut pas être réservée sur le lien R5<->R6.

Notons qu'au niveau réseau, aucun paquet RSVP-TE n'a été émis. C'est tout à fait logique : en effectuant l'algorithme CSPF, R1 s'est rendu compte qu'aucun chemin respectant la contrainte n'était disponible.

Comme dernier exercice, augmentons la priorité de notre dernier tunnel :

interface Tunnel2
tunnel mpls traffic-eng priority 0 0 
shutdown
no shutdown

Cette fois-ci, notre demande a pu être satisfaite :

R1#show mpls traffic-eng tunnels Tunnel 2
Name: R1_t2                               (Tunnel2) Destination: 198.18.95.254
  Status:
    Admin: up         Oper: up     Path: valid       Signalling: connected
 
    path option 1, type dynamic (Basis for Setup, path weight 3)
 
  Config Parameters:
    Bandwidth: 15000    kbps (Global)  Priority: 0  0   Affinity: 0x0/0xFFFF
    Metric Type: TE (default)
    AutoRoute:  enabled   LockDown: disabled  Loadshare: 15000    bw-based
    auto-bw: disabled

 
  InLabel  :  - 
  OutLabel : FastEthernet1/0, 16
  RSVP Signalling Info:
       Src 198.18.15.254, Dst 198.18.95.254, Tun_Id 2, Tun_Instance 40
    RSVP Path Info:
      My Address: 198.18.240.0   
      Explicit Route: 198.18.240.1 198.18.240.6 198.18.240.7 198.18.240.12 
                      198.18.240.13 198.18.95.254 
      Record Route:  NONE
      Tspec: ave rate=15000 kbits, burst=1000 bytes, peak rate=15000 kbits
    RSVP Resv Info:
      Record Route:  NONE
      Fspec: ave rate=15000 kbits, burst=1000 bytes, peak rate=15000 kbits
  Shortest Unconstrained Path Info:
    Path Weight: 3 (TE)
    Explicit Route: 198.18.240.0 198.18.240.1 198.18.240.6 198.18.240.7 
                    198.18.240.12 198.18.240.13 198.18.95.254

Quelques instants plus tard, notre premier tunnel tombe : réception d'un PDU RSVP-TE PATH ERROR : notre demande n'étant plus la plus prioritaire et en l'absence de liens alternatifs disposant d'une capacité réservable suffisante, il n'est plus possible de réserver 30 mégas sur le lien R2<->R3. Illustration :

R1 reçoit un PDU RSVP-TE PATH ERROR pour notre premier tunnel dont la contrainte ne peut plus être satisfaite

Figure 23 - R1 reçoit un PDU RSVP-TE PATH ERROR pour notre premier tunnel dont la contrainte ne peut plus être satisfaite.

Vérifions sur R1 :

R1#show mpls traffic-eng tunnels Tunnel 0
Name: R1_t0                               (Tunnel0) Destination: 198.18.63.254
  Status:
    Admin: up         Oper: down   Path: not valid   Signalling: Down
    path option 1, type dynamic
  Config Parameters:
    Bandwidth: 30000    kbps (Global)  Priority: 1  1   Affinity: 0x0/0xFFFF
  Shortest Unconstrained Path Info:
    Path Weight: 3 (TE)
    Explicit Route: 198.18.240.0 198.18.240.1 198.18.240.6 198.18.240.7 
                    198.18.240.10 198.18.240.11 198.18.63.254 
    Prior LSP:
      ID: path option 1 [63]
      Removal Trigger: path error

Dès que l'on démonte/"éteint" ce dernier tunnel, le premier tunnel est remonté automatiquement.

Pour terminer, nous voulions faire des demandes de réservation de tunnels depuis plusieurs routeurs, pas seulement depuis R1. Après avoir supprimé le dernier tunnel de R1, nous avons tenté de le faire depuis R5 et avons obtenu le même résultat : sans priorité, on ne passe pas. Avec une priorité plus forte, on passe et le premier tunnel sur R1 tombe.

Bibliographie

Dans l'ordre d'utilisation.

Annexes

Fichier de configuration Dynagen pour tout le TP

[localhost]
    [[7200]]
        image = ./C7200-AD.BIN
        ram = 256
        idlepc = 0x607335f0
 
    [[ROUTER R1]]
        model = 7200
        f1/0 = R2 f1/0
        f2/0 = R5 f1/0
 

    [[ROUTER R2]]
        model = 7200
        f2/0 = R5 f2/0
        f3/0 = R3 f1/0
 
    [[ROUTER R3]]
        model = 7200
        f2/0 = R4 f1/0
        f3/0 = R6 f2/0
 
    [[ROUTER R4]]
        model = 7200
        f2/0 = R6 f3/0
 
    [[ROUTER R5]]
        model = 7200
        f3/0 = R6 f1/0
 
    [[ROUTER R6]]
        model = 7200

Commandes IOS pour tout le TP

R1
enable
conf t
hostname R1
no ip domain lookup
 
int fastEthernet 1/0
ip address 198.18.240.0 255.255.255.254
mpls ip
no shutdown
exit
int fastEthernet 2/0
ip address 198.18.240.2 255.255.255.254
mpls ip
no shutdown
exit
int loopback 1
ip address 198.18.15.254 255.255.240.0
no shutdown
exit
 
router ospf 1
network 198.18.0.0 0.0.255.255 area 0
exit
 
ip cef
mpls label protocol ldp
R2
enable
conf t
hostname R2
no ip domain lookup
 

int fastEthernet 1/0
ip address 198.18.240.1 255.255.255.254
mpls ip
no shutdown
exit
int fastEthernet 2/0
ip address 198.18.240.4 255.255.255.254
mpls ip
no shutdown
exit
int fastEthernet 3/0
ip address 198.18.240.6 255.255.255.254
mpls ip
no shutdown
exit
int loopback 1
ip address 198.18.31.254 255.255.240.0
no shutdown
exit
 
router ospf 1
network 198.18.0.0 0.0.255.255 area 0
exit
 
ip cef
mpls label protocol ldp
R3
enable
conf t
hostname R3
no ip domain lookup
 
int fastEthernet 1/0
ip address 198.18.240.7 255.255.255.254
mpls ip
no shutdown
exit
int fastEthernet 2/0
ip address 198.18.240.10 255.255.255.254
mpls ip
no shutdown
exit
int fastEthernet 3/0
ip address 198.18.240.12 255.255.255.254
mpls ip
no shutdown
exit
int loopback 1
ip address 198.18.47.254 255.255.240.0
no shutdown
exit
 
 
router ospf 1
network 198.18.0.0 0.0.255.255 area 0
exit
 

ip cef
mpls label protocol ldp
R4
enable
conf t
hostname R4
no ip domain lookup
 
int fastEthernet 1/0
ip address 198.18.240.11 255.255.255.254
mpls ip
no shutdown
exit
int fastEthernet 2/0
ip address 198.18.240.14 255.255.255.254
mpls ip
no shutdown
exit
int loopback 1
ip address 198.18.63.254 255.255.240.0
no shutdown
exit
 
router ospf 1
network 198.18.0.0 0.0.255.255 area 0
exit
 
ip cef
mpls label protocol ldp
R5
enable
conf t
hostname R5
no ip domain lookup
 
int fastEthernet 1/0
ip address 198.18.240.3 255.255.255.254
mpls ip
no shutdown
exit
int fastEthernet 2/0
ip address 198.18.240.5 255.255.255.254
mpls ip
no shutdown
exit
int fastEthernet 3/0
bandwidth 10000 !restreindre le lien R5-R6 à 10 mégas
ip address 198.18.240.8 255.255.255.254
mpls ip
no shutdown
exit
int loopback 1
ip address 198.18.79.254 255.255.240.0
no shutdown
exit
 
router ospf 1
network 198.18.0.0 0.0.255.255 area 0
exit
 
ip cef
mpls label protocol ldp
R6
enable
conf t
hostname R6
no ip domain lookup
 
int fastEthernet 1/0
ip address 198.18.240.9 255.255.255.254
bandwidth 10000 !restreindre le lien R5-R6 à 10 mégas
mpls ip
no shutdown
exit
int fastEthernet 2/0
ip address 198.18.240.13 255.255.255.254
mpls ip
no shutdown
exit
int fastEthernet 3/0
ip address 198.18.240.15 255.255.255.254
mpls ip
no shutdown
exit
int loopback 1
ip address 198.18.95.254 255.255.240.0
no shutdown
exit
 

router ospf 1
network 198.18.0.0 0.0.255.255 area 0
exit
 
ip cef
mpls label protocol ldp

Commandes IOS supplémentaires spécifiques à la question 10

R1
en
conf t
mpls traffic-eng tunnels
router ospf 1
mpls traffic-eng router-id Loopback1
mpls traffic-eng area 0
exit
 
interface FastEthernet1/0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 50000 50000
 
interface FastEthernet2/0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 60000 60000
exit
exit
R2
en
conf t
mpls traffic-eng tunnels
router ospf 1
mpls traffic-eng router-id Loopback1
mpls traffic-eng area 0
exit
 
interface FastEthernet1/0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 50000 50000
 
interface FastEthernet2/0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 70000 70000
 
interface FastEthernet3/0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 30000 30000
exit
exit
R3
en
conf t
mpls traffic-eng tunnels
router ospf 1
mpls traffic-eng router-id Loopback1
mpls traffic-eng area 0
exit
 

interface FastEthernet1/0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 30000 30000
 
interface FastEthernet2/0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 20000 20000
 
interface FastEthernet3/0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 50000 50000
exit
exit
R4
en
conf t
mpls traffic-eng tunnels
router ospf 1
mpls traffic-eng router-id Loopback1
mpls traffic-eng area 0
exit
 
interface FastEthernet1/0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 20000 20000
 
interface FastEthernet2/0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 80000 80000
exit
exit
R5
en
conf t
mpls traffic-eng tunnels
router ospf 1
mpls traffic-eng router-id Loopback1
mpls traffic-eng area 0
exit
 
interface FastEthernet1/0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 60000 60000
 
interface FastEthernet2/0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 70000 70000
 
interface FastEthernet3/0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 7000 7000
exit
exit
R6
en
conf t
mpls traffic-eng tunnels
router ospf 1
mpls traffic-eng router-id Loopback1
mpls traffic-eng area 0
exit
 

interface FastEthernet1/0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 7000 7000
 
interface FastEthernet2/0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 50000 50000
 
interface FastEthernet3/0
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 80000 80000
exit
exit

Table des figures

Figure 1 - Schéma de notre maquette. D'après l'énoncé.
Figure 2 - Capture réseau. Ping P4 (198.18.63.254) depuis P1 (198.18.15.254). Aller.
Figure 3 - Capture réseau. Ping P4 (198.18.63.254) depuis P1 (198.18.15.254). Retour.
Figure 4 - On observe que R4 reçoit bien les paquets ICMP exceeded.
Figure 5 - Les différents types de tunnels MPLS en fonction des fonctions supportées/activées. Source : http://www.slideshare.net/edge7/slides-mpls-tunnel.
Figure 6 - Différence de chemin A/R entre un echo request/reply et un ttl-exceeded. Source : http://www.caida.org/publications/papers/2012/revealing_mpls_tunnels/revealing_mpls_tunnels.pdf.
Figure 7 - Quand R1 fait un traceroute vers R4, R2 envoie un ICMP TTL-exceeded avec un TTL de 251.
Figure 8 - Quand R1 fait ping vers 198.18.240.1, on observe un TTL de 255.
Figure 9 - R4 annonce sa nouvelle loopback en OSPF.
Figure 10 - R4 annonce sa nouvelle loopback via LDP.
Figure 11 - Attribution des labels pour la nouvelle loopback : pour transmettre des paquets à destination de la nouvelle loopback, R3 attend qu'ils soient tagués avec le label 26.
Figure 12 - R2 émet un LS UPDATE dans lequel il n'annonce plus avoir un lien avec R1 (absence de 198.18.240.0 et de 198.18.15.254).
Figure 13 - R2 annonce à R3 la disparition de R1 (198.18.240.0) avec un message LDP Withdrawal. R3 annonce la disparition d'un routeur en amont (R1) avec un message LDP Release.
Figure 14 - Schéma de notre maquette avec la capacité réservable sur chaque lien. D'après l'énoncé.
Figure 15 - R1 annonce la capacité du lien R1<->R2 mais indique une capacité réservable nulle.
Figure 16 - Maintenant, R1 annonce aussi la capacité réservable sur le lien R1<->R2.
Figure 17 - R1 fait sa demande de tunnel avec un PDU RSVP-TE de type PATH.
Figure 18 - R2 transmet simplement la demande de tunnel de R1.
Figure 19 - R4 émet un PDU RSVP-TE de type RESV à destination de R6.
Figure 20 - R6 émet un PDU RSVP-TE de type RESV à destination de R3.
Figure 21 - R1 reçoit le PDU RSVP-TE RESV de R2 et sait donc que son tunnel TE est prêt.
Figure 22 - R2 annonce, en OSPF, que plus aucune capacité n'est réservable sur le lien R2<->R3.
Figure 23 - R1 reçoit un PDU RSVP-TE PATH ERROR pour notre premier tunnel dont la contrainte ne peut plus être satisfaite.

Les commentaires sont fermés