Switching por etiquetas multiprotocolo (MPLS) : Switching por etiquetas multiprotocolo por ATM (MPLS over ATM)

Introducción al Multiprotocol Label Switching (MPLS) y su imposición en un entorno ATM

16 Enero 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (9 Noviembre 2015) | Comentarios


Contenido


Introducción

Este documento describe la trayectoria usada por un paquete del IP cuando viaja con núcleo ATM habilitado para MPLS y describe los comandos show principales.

Nota: El Routers en este documento es de las Cisco 3600 Series que funcionan con la versión 12.0(7)T del � del Cisco IOS y utilizan las interfaces OC-3. La atmósfera LSR es un 8540MSR.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Diagrama de la red

Los escenarios en este documento se basan en esta configuración. Para ver las configuraciones para estos dispositivos, refiera a esta configuración de muestra.

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

Comandos show

Guilder

El florín es un router interesante en esta configuración puesto que impone las escrituras de la etiqueta a los paquetes del IP que vienen del lado Ethernet. Puesto que trabajamos en una interfaz ATM que esté conectada con núcleo ATM habilitado para MPLS, la escritura de la etiqueta impuesta significa un paquete del IP remitido en un Tag VC (TVC).

En este escenario, la libra envía los paquetes del IP a la lira. Por ejemplo, si usted hace ping 125.125.0.2 de la libra, trabaja como se esperaba:

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 tabla de ruteo del florín, podemos ver fácilmente que el destino se puede alcanzar a través de la nube 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

Hemos configurado la subinterfaz ATM 1/0.1 para etiquetar los paquetes del IP salientes, así que podemos recibir más detalles a través de la tabla de reenvío de la etiqueta:

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

Vemos ahora que el florín impone el TVC saliente VPI2, el VCI 36, que corresponde a VCD 299. Esta información se guarda en la tabla de reenvío 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)}

Los paquetes del IP se envían de hecho en el VC derecho:

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

Como usted ve, sólo se han enviado cinco paquetes del IP. Esto se sincroniza con el ping simple que iniciamos. Al mismo tiempo, usted puede preguntarse porqué no vemos cinco paquetes de entrada. ¿Es decir porqué son el saliente y los trayectos de entrada diferentes? Esto es normal puesto que hay un VC por la entrada de la ruta (por el prefijo), y, como consecuencia, los TVC son unidireccionales.

Capri

Asombrosamente, no hay mucho que podemos conseguir del Switch cuando todas las rutas/VCs son estables; conmuta simplemente a las células ATM. Observe este ejemplo:

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

Algunos detalles deben ser señalados. Examine esta salida:

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

Como podemos ver, algunos TVC terminan en la interfaz ATM0. En un 8540MSR, la interfaz ATM0 corresponde al CPU. Esos TVC corresponden a los IP Addresses locales al 8540MSR, tal como un Local Loopback.

Sabemos que el florín envía los paquetes del IP con el destino 125.125.0.2 en TVC 2/36. En el lado LSR, este TVC es (i) un TVC entrante solamente.

Damme

Para alcanzar 125.125.0.2, esperamos que los paquetes del IP sean enviados a la interfaz Fast Ethernet 0/0 de acuerdo con el diagrama de la red. Sabemos que no hemos configurado el switching por etiquetas en esta interfaz Fast Ethernet. Éste es el resultado:

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#

Como consecuencia, no hay escritura de la etiqueta a agregar. Solamente la información de la tabla de ruteo se utiliza:

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

Esta información se guarda de nuevo en la tabla del CEF Switching:

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 

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 10477