Commutation multiprotocole par étiquette (MPLS) : Commutation multiprotocole par étiquette sur ATM (MPLS sur ATM)

Présentation du caractère obligatoire des étiquettes dans le cas de la commutation multiprotocole par étiquette (MPLS) dans un environnement ATM

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document décrit le chemin utilisé par un paquet IP quand il voyage par un noyau MPLS-activé atmosphère et décrit les principales commandes show.

Remarque: Les Routeurs dans ce document sont de la gamme Cisco 3600 qui exécutent la version 12.0(7)T de Ý de Cisco IOS et utilisent les interfaces OC-3. L'atmosphère LSR est un 8540MSR.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Diagramme du réseau

Les scénarios dans ce document sont basés sur cette installation. Afin de visualiser les configurations pour ces périphériques, référez-vous à cette configuration d'échantillon.

/image/gif/paws/10477/MPLSoATM-1.gif

Commandes show

Guilder

Le Guilder est un routeur intéressant dans cette installation puisqu'il impose des étiquettes dans les paquets IP qui proviennent le côté Ethernet. Puisque nous travaillons à une interface ATM qui est connectée à un noyau MPLS-activé atmosphère, l'étiquette imposée signifie un paquet IP expédié sur un circuit virtuel de balise (TVC).

Dans ce scénario, le dièse envoie des paquets IP à la Lire. Par exemple, si vous cinglez 125.125.0.2 de dièse, cela fonctionne comme prévu :

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

De la table de routage du Guilder, nous pouvons facilement voir que la destination peut être accédée par le nuage ATM :

Guilder#show ip route 125.125.0.2
Routing entry for 125.125.0.0/16
  Known via "ospf 1", distance 110, metric 12, type inter area
  Redistributing via ospf 1
  Last update from 129.129.0.2 on ATM1/0.1, 01:15:26 ago
  Routing Descriptor Blocks:
  * 129.129.0.2, from 120.120.0.1, 01:15:26 ago, via ATM1/0.1
      Route metric is 12, traffic share count is 1

Nous avons configuré la sous-interface 1/0.1 atmosphère pour étiqueter les paquets IP sortants, ainsi nous pouvons recevoir plus de détails par la table d'expédition de balise :

Guilder#show tag-switching forwarding-table 125.125.0.2 detail
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface              
30     2/36        125.125.0.0/16    0          AT1/0.1    point2point
        MAC/Encaps=4/8, MTU=4470, Tag Stack{2/36(vcd=299)}
        012B0900 0012B000

Nous voyons maintenant que le Guilder impose le TVC sortant VPI 2, VCI 36, qui correspond à VCD 299. Ces informations sont enregistrées dans la table d'expédition de CEF :

Guilder#show ip cef 125.125.0.2 detail
125.125.0.0/16, version 143, cached adjacency to ATM1/0.1
0 packets, 0 bytes
  tag information set
    local tag: 30
    fast tag rewrite with AT1/0.1, point2point, tags imposed: {2/36(vcd=299)}
  via 129.129.0.2, ATM1/0.1, 0 dependencies
    next hop 129.129.0.2, ATM1/0.1
    valid cached adjacency
    tag rewrite with AT1/0.1, point2point, tags imposed: {2/36(vcd=299)}

Les paquets IP sont en effet envoyés sur le circuit virtuel droit :

Guilder#show atm vc 299
ATM1/0.1: VCD: 299, VPI: 2, VCI: 36
UBR, PeakRate: 155000
AAL5-MUX, etype:0x8847, Flags: 0x40C84, VCmode: 0x0
OAM frequency: 0 second(s)
InARP DISABLED
Transmit priority 0
InPkts: 0, OutPkts: 5, InBytes: 0, OutBytes: 540
InPRoc: 0, OutPRoc: 0
InFast: 0, OutFast: 5, InAS: 0, OutAS: 0
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 
0OAM cells received: 
0OAM cells sent: 0
Status: UP
Tag VC: local tag: 0

Comme vous voyez, seulement cinq paquets IP ont été envoyés. Ceci est synchronisé avec le ping simple que nous avons initié. En même temps, vous pouvez se demander pourquoi nous ne voyons pas cinq paquets en entrée. En d'autres termes, pourquoi les chemins sortants et d'arrivée sont-ils différents ? C'est normal puisqu'il y a un circuit virtuel par entrée de route (par préfixe), et, en conséquence, le TVCs sont unidirectionnel.

Capri

Étonnant, il n'y a pas beaucoup que nous pouvons obtenir du commutateur quand toutes les artères/VCs sont stables ; il commute simplement des cellules atmosphère. Reportez-vous à l’exemple suivant :

Capri#show tag atm-tdp bindings 125.125.0.0 16
 Destination: 125.125.0.0/16
    Transit ATM3/0/3 2/36 Active -> ATM3/0/0 2/38 Active

Quelques détails doivent être précisés. Examinez cette sortie :

Capri#show atm vc conn-type tvc int atm 3/0/3
Interface         VPI  VCI   Type   X-Interface      X-VPI X-VCI Encap  Status 
ATM3/0/3          2    33    TVC(I) ATM3/0/0          2    36           UP
ATM3/0/3          2    33    TVC(O) ATM3/0/0          2    53           UP
ATM3/0/3          2    34    TVC(I) ATM0              0    317   MUX    UP
ATM3/0/3          2    34    TVC(O) ATM3/0/0          2    54           UP
ATM3/0/3          2    35    TVC(I) ATM3/0/0          2    37           UP
ATM3/0/3          2    35    TVC(O) ATM3/0/0          2    55           UP
ATM3/0/3          2    36    TVC(I) ATM3/0/0          2    38           UP
ATM3/0/3          2    37    TVC(I) ATM0              0    318   MUX    UP

Comme nous pouvons voir, une certaine extrémité de TVCs sur l'interface ATM0. Sur un 8540MSR, l'interface ATM0 correspond à la CPU. Ces TVCs correspondent aux adresses IP locales au 8540MSR, tel qu'un bouclage local.

Nous savons que le Guilder envoie des paquets IP avec la destination 125.125.0.2 sur TVC 2/36. Du côté LSR, ce TVC est (i) un TVC d'arrivée seulement.

Damme

Afin d'atteindre 125.125.0.2, nous attendons les paquets IP à envoyer au port Fast Ethernet 0/0 selon le schéma de réseau. Nous savons que nous n'avons pas configuré la commutation par étiquette sur ce port Fast Ethernet. C'est le résultat :

damme#show tag-switching forwarding-table 125.125.0.2 detail
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface
damme#

En conséquence, il n'y a aucune étiquette à ajouter. Seulement les informations de la table de routage sont utilisées :

damme#show ip route 125.125.0.2
 Routing entry for 125.125.0.0/16
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Redistributing via ospf 1
  Routing Descriptor Blocks:
  * directly connected, via FastEthernet0/0
      Route metric is 0, traffic share count is 1

Ces informations sont enregistrées de nouveau dans la table de commutation de CEF :

damme#show ip cef 125.125.0.2 detail
125.125.0.2/32, version 62, connected, cached adjacency 125.125.0.2
0 packets, 0 bytes
  via 125.125.0.2, FastEthernet0/0, 0 dependencies
    next hop 125.125.0.2, FastEthernet0/0
    valid cached adjacency 

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 10477