Introducción al Multiprotocol Label Switching (MPLS) y su imposición en un entorno ATM
Contenido
Introducción
Este documento describe la trayectoria utilizada por un paquete IP cuando viaja a través de un núcleo ATM habilitado para MPLS y describe los principales comandos show.
Nota: Los routers en este documento son de la serie Cisco 3600 que ejecutan Cisco IOS® versión 12.0(7)T y utilizan interfaces OC-3. El LSR ATM es un 8540MSR.
Prerequisites
Requirements
No hay requisitos específicos para este documento.
Convenciones
Diagrama de la red
Los escenarios de este documento se basan en esta configuración. Para ver las configuraciones para estos dispositivos, consulte esta configuración de ejemplo.
Comandos show
Guilder
Guilder es un router interesante en esta configuración ya que impone etiquetas a los paquetes IP que vienen del lado Ethernet. Dado que trabajamos en una interfaz ATM que está conectada a un núcleo ATM habilitado para MPLS, la etiqueta impuesta significa un paquete IP reenviado en un Tag VC (TVC).
En este escenario, Pound envía paquetes IP a Lira. Por ejemplo, si hace ping 125.125.0.2 desde la Libra, funciona como se espera:
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
Desde la tabla de ruteo de Guilder, 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 IP salientes, de modo que podamos recibir más detalles a través de la tabla de reenvío de etiquetas:
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
Ahora vemos que Guilder impone el TVC de salida VPI 2, VCI 36, que corresponde a VCD 299. Esta información se guarda en la tabla de reenvío 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)}
De hecho, los paquetes IP se envían en el VC correcto:
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 puede ver, sólo se han enviado cinco paquetes IP. Esto se sincroniza con el simple ping que iniciamos. Al mismo tiempo, puede preguntarse por qué no vemos cinco paquetes de entrada. En otras palabras, ¿por qué son diferentes las trayectorias de salida y de entrada? Esto es normal ya que hay un VC por entrada de ruta (por prefijo) y, como resultado, los TVC son unidireccionales.
Capri
Sorprendentemente, no hay mucho que podamos obtener del switch cuando todas las rutas/VC son estables; simplemente conmuta las celdas 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
Hay que señalar algunos detalles. Examine este resultado:
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 a la CPU. Esos TVC corresponden a las direcciones IP locales de 8540MSR, como un loopback local.
Sabemos que Guilder envía paquetes IP con destino 125.125.0.2 en TVC 2/36. En el lado LSR, este TVC es un TVC entrante (I) solamente.
Damme
Para alcanzar 125.125.0.2, esperamos que los paquetes IP se envíen a la interfaz Fast Ethernet 0/0 de acuerdo con el diagrama de red. Sabemos que no hemos configurado Label Switching en esta interfaz Fast Ethernet. Este 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 resultado, no hay ninguna etiqueta que agregar. Sólo se utiliza la información de la tabla de ruteo:
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 una vez más en la tabla de conmutación 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
Información Relacionada
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
05-Jun-2005 |
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)