Flux de paquets dans un environnement MPLS VPN

Introduction

Ce document illustre le flux de paquets via un cloud VPN (Virtual Private Network) MPLS (Multiprotocol Label Switching). Il introduit également le concept d'avoir plusieurs étiquettes dans un paquet.

Le VPN, lorsqu'il est utilisé avec MPLS, permet à plusieurs sites d'interconnecter de manière transparente via le réseau d'un fournisseur de services. Un réseau du fournisseur de service peut prendre en charge plusieurs VPN d'IP différents. Chacun de ces derniers apparaît à ses utilisateurs en tant que réseau privé, séparé de tous les autres réseaux. Dans un VPN, chaque site peut envoyer des paquets IP à n'importe quel autre site dans le même VPN.

Chaque VPN est associé avec un ou plusieurs VPN de routage ou instances de transmission (VRF). Un VRF se compose d'une table de routage IP, d'une table CEF (Cisco Express Forwarding) dérivée et d'un ensemble d'interfaces qui utilisent cette table de transfert.

Le routeur conserve un routage distinct et la table CEF pour chaque VRF. Ceci empêche l'information d'être envoyée en dehors du VPN et permet au même sous-réseau d'être utilisé dans plusieurs VPN sans causer de problèmes d'adresse IP en double.

Le routeur utilisant le protocole BGP (Border Gateway Protocol) distribue les informations de routage VPN à l'aide des communautés étendues BGP.

Pour plus d'informations sur la propagation des mises à jour via un VPN, reportez-vous aux documents suivants :

• Communautés cibles de routage VPN.

• Distribution BGP des informations de routage VPN.

• Transfert MPLS.

• Lien vers un exemple de configuration.

La fonctionnalité VPN MPLS a été introduite dans le logiciel Cisco IOS^® Version 12.0(5)T.

Avant de commencer

Conventions

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

Conditions préalables

Aucune condition préalable spécifique n'est requise pour ce document.

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.

Diagramme du réseau

Afin de comprendre le fonctionnement de VPN MPLS, prenons l'exemple de configuration suivant :

Dans cette configuration :

• Rapid et Pound sont les périphériques de périphérie client (CE) qui n'exécutent pas MPLS. Ils sont associés au VPN VRF101. Pour plus de simplicité, nous n'utilisons qu'un seul VRF ici.

• Farm et Medina sont les périphériques de périphérie du fournisseur (PE).

• Miles et Yard sont des routeurs LightStream 1010. Ils constituent le réseau fédérateur MPLS.

Processus de flux de paquets

Le résultat ci-dessous montre ce qui se passe lorsque Rapid envoie des paquets à Pound à l'intérieur du VPN VRF101 :

rapid#ping 11.5.5.5
      
     Type escape sequence to abort.
     Sending 5, 100-byte ICMP Echos to 11.5.5.5, timeout is 2 seconds:
     !!!!!
     Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

     rapid#show ip route 11.5.5.5
     Routing entry for 11.5.5.4/30
       Known via "rip", distance 120, metric 1
       Redistributing via rip
       Last update from 150.150.0.1 on FastEthernet0/1, 00:00:16 ago
       Routing Descriptor Blocks:
       * 150.150.0.1, from 150.150.0.1, 00:00:16 ago, via FastEthernet0/1
           Route metric is 1, traffic share count is 1

Farm apprend l'adresse 11.5.5.5 de Med ina par le biais d'annonces BGP :

Farm#show ip bgp vpnv4 vrf vrf101 11.5.5.5 
     BGP routing table entry for 1:101:11.5.5.4/30, version 56 
        Paths: (1 available, best #1, table vrf101) 
        Not advertised to any peer 
        Local 
          125.2.2.2 (metric 4) from 125.2.2.2 (125.2.2.2) 
            Origin incomplete, metric 1, localpref 100, valid, internal, best 
            Extended Community: RT:1:101 

     Farm#show ip route vrf vrf101 11.5.5.5 
     Routing entry for 11.5.5.4/30 
        Known via "bgp 1", distance 200, metric 1, type internal 
        Redistributing via rip 
        Advertised by rip metric 0 
        Last update from 125.2.2.2 01:29:20 ago 
        Routing Descriptor Blocks: 
        * 125.2.2.2 (Default-IP-Routing-Table), from 125.2.2.2, 01:29:20 ago      
            Route metric is 1, traffic share count is 1      
            AS Hops 0 

Remarque : 125.2.2.2 est un bouclage sur Medina et est utilisé pour créer le jumelage BGP avec Farm.

Afin de transférer le paquet destiné à 11.5.5.5 à Medina, Farm utilise deux étiquettes. Pour voir ceci, consultez le CEF et la table de transfert d'étiquette VPN sur la batterie :

Farm#show tag forwarding
-table vrf vrf101 11.5.5.5 detail 
     Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
     tag    tag or VC   or Tunnel Id      switched   interface              
     None   2/91        11.5.5.4/30       0          AT4/0.1    point2point  
             MAC/Encaps=4/12, MTU=4466, Tag Stack{2/91(vcd=69) 40}
             00458847 0004500000028000

     Farm#show ip cef vrf vrf101 11.5.5.5
     11.5.5.4/30, version 25, cached adjacency to ATM4/0.1
     0 packets, 0 bytes
       tag information set
         local tag: VPN-route-head
         fast tag rewrite with AT4/0.1, point2point, tags imposed: {2/91(vcd=69) 40}
       via 125.2.2.2, 0 dependencies, recursive
         next hop 10.0.0.14, ATM4/0.1 via 125.2.2.2/32
         valid cached adjacency
         tag rewrite with AT4/0.1, point2point, tags imposed: {2/91(vcd=69) 40}

Deux étiquettes sont appliquées aux paquets qui quittent la batterie et sont destinés à 11.5.5.5. Ils peuvent être représentés comme suit :

L'étiquette 40 est ajoutée au paquet et elle est ensuite segmentée en cellules avec 2/91 comme valeurs VPI/VCI. Cela signifie que l'étiquette est également appelée 2/91.

Remarque : lors de la réception d'une trame comportant plusieurs étiquettes, le périphérique récepteur ne vérifie que la première.

Les étiquettes sont attribuées comme suit :

• 2/91 est attribué par Yard et correspond à l'adresse 125.2.2.2. Cette adresse est utilisée pour créer le jumelage BGP avec la batterie. Référez-vous à VPN MPLS sur ATM : avec BGP ou RIP sur le site du client pour plus d'informations. L'étiquette est utilisée dans le coeur MPLS pour envoyer des trames de Farm à 125.2.2.2 sur Medina.

• 40 est assigné à 11.5.5.5 par Médine. Lorsqu’un PE (Medina dans ce cas) apprend un préfixe IP à partir d’un CE (livre), le PE attribue une étiquette spécifique à cette route. L'étiquette dépend du VPN VRF que la route a appris. Il annonce la route et l'étiquette aux autres PE à l'aide de communautés BGP améliorées.

Jetons un coup d'oeil à Médina :

Medina#show tag forwarding
-table vrf vrf101 11.5.5.5 detail
     Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
     tag    tag or VC   or Tunnel Id      switched   interface              
     40     Untagged    11.5.5.4/30[V]    570        Et1/1      11.3.3.2     
             MAC/Encaps=0/0, MTU=1500, Tag Stack{}
             VPN route: vrf101
         Per-packet load-sharing

Maintenant que nous savons d'où viennent les étiquettes, nous pouvons voir ce qui arrive aux paquets destinés à 11.5.5.5. La batterie envoie le paquet segmenté sur le circuit virtuel 2/91. Yard reçoit ça. Pour voir ce que fait Yard avec ces cellules, utilisez la commande suivante :

Yard#show tag atm
-tdp bindings 125.2.2.2 32
      Destination: 125.2.2.2/32
         Transit ATM0/1/1 2/91 Active -> ATM4/0/0 1/82 Active

Sur réception de ces cellules sur le VC 2/91 (cellules qui sont destinées à 125.2.2.2, également appelé Médine), Yard les transfère à Miles en utilisant le VC 1/82 sortant.

Note : Yard n'a pas vérifié ou modifié l'étiquette 40.

La même chose se passe sur Miles, en changeant les cellules en Médine sur le VC 1/33 :

Miles#show tag atm
-tdp bindings 125.2.2.2 32
      Destination: 125.2.2.2/32
         Transit ATM0/1/3 1/82 Active -> ATM0/1/1 1/33 Active

Le paquet qui arrive à Medina peut être représenté comme ceci :

Lors de la réception des cellules du VC 1/33, Medina vérifie l'étiquette 1/33 et constate que cette étiquette est locale au routeur. Ce faisant, Medina voit que le paquet est destiné à l'une de ses propres adresses :

Medina#show tag
-switching atm-tdp bindings local-tag 1 33
      Destination: 125.2.2.2/32
         Tailend Router ATM2/0.66 1/33 Active, VCD=406

Medina retire donc la première étiquette (1/33) et voit que le paquet a une autre étiquette (40). Il vérifie ensuite à quoi correspond cette étiquette et commute le paquet en conséquence :

Medina#show tag
-switching forwarding-table tags 40
     Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
     tag    tag or VC   or Tunnel Id      switched   interface              
     40     Untagged    11.5.5.4/30[V]    570        Et1/1      11.3.3.2

Dans ce cas, Medina voit que le paquet est destiné à un site connecté par une liaison IP ordinaire. Il ignore l'étiquette et transfère le paquet IP sur l'interface Ethernet 1/1.

Informations connexes

• Outils et ressources
• Support et documentation techniques - Cisco Systems

Historique de révision