Solución de problemas de MPLS
Comprobar interfaces MPLS
Propósito
Si el protocolo MPLS no está configurado correctamente en los enrutadores de la red, las interfaces no podrán realizar la conmutación MPLS.
Para que una ruta etiquetada se resuelva a través de una interfaz, family mpls debe configurarse en el nivel de [edit interfaces] jerarquía para que la ruta se resuelva correctamente. Cuando la interfaz no está configurada con family mpls, las rutas etiquetadas no se resuelven.
Acción
Para comprobar las interfaces MPLS, escriba el siguiente comando de modo operativo de la interfaz de línea de comandos (CLI) de Junos OS:
user@host> show mpls interface
Ejemplo de salida 1
nombre-comando
El siguiente resultado de ejemplo es para todos los enrutadores de la red que se muestran en la topología de red MPLS.
user@R1> show mpls interface Interface State Administrative groups so-0/0/0.0 Up <none> so-0/0/1.0 Up <none> so-0/0/2.0 Up <none> user@R2> show mpls interface Interface State Administrative groups so-0/0/0.0 Up <none> so-0/0/1.0 Up <none> so-0/0/2.0 Up <none> so-0/0/3.0 Up <none> user@R3> show mpls interface Interface State Administrative groups so-0/0/0.0 Up <none> so-0/0/1.0 Up <none> so-0/0/2.0 Up <none> so-0/0/3.0 Up <none> user@R4> show mpls interface Interface State Administrative groups so-0/0/0.0 Up <none> so-0/0/1.0 Up <none> so-0/0/2.0 Up <none> so-0/0/3.0 Up <none> user@R5> show mpls interface Interface State Administrative groups so-0/0/0.0 Up <none> so-0/0/1.0 Up <none> so-0/0/2.0 Up <none> user@R6> show mpls interface Interface State Administrative groups so-0/0/0.0 Up <none> so-0/0/1.0 Up <none> so-0/0/2.0 Up <none> so-0/0/3.0 Up <none>
Ejemplo de salida 2
nombre-comando
user@R6> show mpls interface Interface State Administrative groups so-0/0/0.0 Up <none> so-0/0/1.0 Up <none> so-0/0/3.0 Up <none> # so-0/0/2.0 is missing
Ejemplo de salida 3
nombre-comando
user@host> show mpls interface MPLS not configured
Significado
El resultado de ejemplo 1 muestra que todas las interfaces MPLS en todos los enrutadores de la red están habilitadas (Up) y pueden realizar conmutación MPLS. Si no puede configurar la interfaz correcta en el nivel de jerarquía [edit protocols mpls] o no incluye la family mpls instrucción en el nivel de jerarquía [edit interfaces type-fpc/pic/port unit number ], la interfaz no puede realizar la conmutación MPLS y no aparece en el resultado del show mpls interface comando.
Los grupos administrativos no se configuran en ninguna de las interfaces que se muestran en la red de ejemplo en la topología de red MPLS. Sin embargo, si lo fueran, la salida indicaría qué bits de clase de afinidad están habilitados en el enrutador.
El resultado de ejemplo 2 muestra que falta la interfaz so-0/0/2.0 y, por lo tanto, podría estar configurada incorrectamente. Por ejemplo, es posible que la interfaz no se incluya en el nivel de jerarquía [edit protocols mpls] o que la family mpls instrucción no se incluya en el nivel de jerarquía [edit interfaces type-fpc/pic/port unit number]. Si la interfaz está configurada correctamente, es posible que RSVP aún no haya señalado a través de esta interfaz. Para obtener más información sobre cómo determinar qué interfaz está configurada incorrectamente, consulte Comprobar familias de protocolos.
El resultado de ejemplo 3 muestra que el protocolo MPLS no está configurado en el nivel de jerarquía [edit protocols mpls].
Verificar familias de protocolos
Propósito
Si una interfaz lógica no tiene habilitada MPLS, no podrá realizar la conmutación MPLS. Este paso le permite determinar rápidamente qué interfaces están configuradas con MPLS y otras familias de protocolos.
Acción
Para verificar las familias de protocolos configuradas en los enrutadores de su red, ingrese el siguiente comando de modo operativo de la CLI de Junos OS:
user@host> show interfaces terse
Ejemplo de salida 1
nombre-comando
user@R1> show interfaces terse
Interface Admin Link Proto Local Remote
so-0/0/0 up up
so-0/0/0.0 up up inet 10.1.12.1/30
iso
mpls
so-0/0/1 up up
so-0/0/1.0 up up inet 10.1.15.1/30
iso
mpls
so-0/0/2 up up
so-0/0/2.0 up up inet 10.1.13.1/30
iso
mpls
so-0/0/3 up down
user@R2> show interfaces terse
Interface Admin Link Proto Local Remote
so-0/0/0 up up
so-0/0/0.0 up up inet 10.1.12.2/30
iso
mpls
so-0/0/1 up up
so-0/0/1.0 up up inet 10.1.23.1/30
iso
mpls
so-0/0/2 up up
so-0/0/2.0 up up inet 10.1.26.1/30
iso
mpls
so-0/0/3 up up
so-0/0/3.0 up up inet 10.1.24.1/30
iso
mpls
user@R3> show interfaces terse
Interface Admin Link Proto Local Remote
so-0/0/0 up up
so-0/0/0.0 up up inet 10.1.34.1/30
iso
mpls
so-0/0/1 up up
so-0/0/1.0 up up inet 10.1.23.2/30
iso
mpls
so-0/0/2 up up
so-0/0/2.0 up up inet 10.1.13.2/30
iso
mpls
so-0/0/3 up up
so-0/0/3.0 up up inet 10.1.36.1/30
iso
mpls
user@R4> show interfaces terse
Interface Admin Link Proto Local Remote
so-0/0/0 up up
so-0/0/0.0 up up inet 10.1.34.2/30
iso
mpls
so-0/0/1 up up
so-0/0/1.0 up up inet 10.1.46.1/30
iso
mpls
so-0/0/2 up up
so-0/0/2.0 up up inet 10.1.45.1/30
iso
mpls
so-0/0/3 up up
so-0/0/3.0 up up inet 10.1.24.2/30
iso
mpls
user@R5> show interfaces terse
Interface Admin Link Proto Local Remote
so-0/0/0 up up
so-0/0/0.0 up up inet 10.1.56.1/30
iso
mpls
so-0/0/1 up up
so-0/0/1.0 up up inet 10.1.15.2/30
iso
mpls
so-0/0/2 up up
so-0/0/2.0 up up inet 10.1.45.2/30
iso
mpls
so-0/0/3 up down
user@R6> show interfaces terse
Interface Admin Link Proto Local Remote
so-0/0/0 up up
so-0/0/0.0 up up inet 10.1.56.2/30
iso
mpls
so-0/0/1 up up
so-0/0/1.0 up up inet 10.1.46.2/30
iso
mpls
so-0/0/2 up up
so-0/0/2.0 up up inet 10.1.26.2/30
iso
mpls
so-0/0/3 up up
so-0/0/3.0 up up inet 10.1.36.2/30
iso
mpls
Ejemplo de salida 2
nombre-comando
user@R6> show interfaces terse
Interface Admin Link Proto Local Remote
so-0/0/0 up up
so-0/0/0.0 up up inet 10.1.56.2/30
iso
mpls
so-0/0/1 up up
so-0/0/1.0 up up inet 10.1.46.2/30
iso
mpls
so-0/0/2 up up
so-0/0/2.0 up up inet 10.1.26.2/30
iso #The mpls statement is missing.
so-0/0/3 up up
so-0/0/3.0 up up inet 10.1.36.2/30
iso
mpls
Significado
El resultado de ejemplo 1 muestra la interfaz, el estado administrativo del vínculo (Admin), el estado de la capa de vínculo de datos del vínculo (Link), las familias de protocolos configuradas en la interfaz (Proto) y las direcciones locales y remotas en la interfaz.
Todas las interfaces en todas las rutas de la red que se muestran en la topología de red MPLS están habilitadas administrativamente y funcionan en la capa de vínculo de datos con MPLS e IS-IS, y tienen una inet dirección. Todos están configurados con una familia de protocolos IPv4 (inet) y tienen las familias de protocolos IS-IS (iso) y MPLS (mpls) configuradas en el nivel de jerarquía [edit interfaces type-fpc/pic/port unit number].
El resultado de ejemplo 2 muestra que la interfaz so-0/0/2.0 en R6 no tiene la mpls instrucción incluida en el nivel de jerarquía [edit interfaces type-fpc/pic/port unit number].
Comprobar la configuración de MPLS
Propósito
Después de comprobar los enrutadores de tránsito y entrada, utilice el traceroute comando para comprobar el próximo salto del BGP y utilice el ping comando para comprobar la ruta activa, puede comprobar si hay problemas con la configuración de MPLS en los niveles jerárquico [edit protocols mpls] y [edit interfaces] .
Para que una ruta etiquetada se resuelva a través de una interfaz, family mpls debe configurarse en el nivel de [edit interfaces] jerarquía para que la ruta se resuelva correctamente. Cuando la interfaz no está configurada con family mpls, las rutas etiquetadas no se resuelven.
Acción
Para comprobar la configuración de MPLS, introduzca los siguientes comandos desde los enrutadores de entrada, tránsito y salida:
user@host> show configuration protocols mpls user@host> show configuration interfaces
Ejemplo de salida 1
nombre-comando
user@R1> show configuration protocols mpls
label-switched-path R1-to-R6 {
to 10.0.0.6;
}
inactive: interface so-0/0/0.0;
inactive: interface so-0/0/1.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
user@R3> show configuration protocols mpls
interface fxp0.0 {
disable;
}
inactive: interface so-0/0/0.0;
inactive: interface so-0/0/1.0;
interface so-0/0/2.0;
interface so-0/0/3.0;
user@R6> show configuration protocols mpls
label-switched-path R6-to-R1 {
to 10.0.0.1;
}
inactive: interface so-0/0/0.0;
inactive: interface so-0/0/1.0;
inactive: interface so-0/0/2.0;
inactive: interface so-0/0/3.0; <<< Incorrectly configured
Ejemplo de salida 2
nombre-comando
user@R6> show configuration interfaces
so-0/0/0 {
unit 0 {
family inet {
address 10.1.56.2/30;
}
family iso;
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.46.2/30;
}
family iso;
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.1.26.2/30;
}
family iso;
family mpls;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.36.2/30;
}
family iso;
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.148/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.6/32;
address 127.0.0.1/32;
}
family iso {
address 49.0003.1000.0000.0006.00;
}
}
}
Significado
El ejemplo de salida 1 de los enrutadores de entrada, tránsito y salida muestra que la configuración de las interfaces en el enrutador R6 de salida es incorrecta. La interfaz so-0/0/3.0 se incluye como inactiva en el nivel de jerarquía [edit protocols mpls], cuando debería estar activa porque es la interfaz por la que viaja el LSP.
El resultado de ejemplo 2 muestra que las interfaces están configuradas correctamente para MPLS en el enrutador R6de salida. Las interfaces también están configuradas correctamente en los enrutadores de entrada y tránsito (no se muestra).
Comprobación de la capa MPLS
Propósito
Después de configurar la ruta de conmutación de etiquetas (LSP), emitir el show mpls lsp comando y determinar que hay un error, es posible que el error no esté en las capas física, de vínculo de datos, Protocolo de Internet (IP), Protocolo de puerta de enlace interior (IGP) o Protocolo de reserva de recursos (RSVP). Continúe investigando el problema en la capa MPLS de la red.
Figura 1 ilustra la capa MPLS del modelo MPLS en capas.
Con la capa MPLS, se comprueba si el LSP está funcionando correctamente. Si la red no funciona en esta capa, el LSP no funciona según lo configurado.
Figura 2 ilustra la red MPLS utilizada en este tema.
La red que se muestra en Figura 2 es una configuración completamente mallada donde cada interfaz conectada directamente puede recibir y enviar paquetes a cualquier otra interfaz similar. El LSP de esta red está configurado para ejecutarse desde el enrutador R1de entrada, pasando por el enrutador R3de tránsito, hasta el enrutador R6de salida. Además, un LSP inverso está configurado para ejecutarse desde R6 hasta R1R3 , creando tráfico bidireccional.
Sin embargo, en este ejemplo, el LSP inverso está inactivo sin una ruta de acceso de R6 a R1.
La cruz que se muestra en Figura 2 indica dónde se rompe el LSP. Algunas posibles razones por las que el LSP está roto pueden incluir un protocolo MPLS configurado incorrectamente o interfaces configuradas incorrectamente para MPLS.
En la red mostrada en Figura 2, un error de configuración en el enrutador R6 de salida impide que el LSP atraviese la red como se esperaba.
Para comprobar la capa MPLS, siga estos pasos:
- Comprobar el LSP
- Verificar la ruta LSP en el enrutador de tránsito
- Verificar la ruta LSP en el enrutador de entrada
- Verificar etiquetas MPLS con el comando traceroute
- Verificar etiquetas MPLS con el comando ping
- Tome las medidas apropiadas
- Compruebe de nuevo el LSP
Comprobar el LSP
Propósito
Normalmente, se utiliza el show mpls lsp extensive comando para comprobar el LSP. Sin embargo, para una comprobación rápida del estado de LSP, utilice el show mpls lsp comando. Si el LSP no funciona, utilice la extensive opción (show mpls lsp extensive) como seguimiento. Si su red tiene numerosos LSP, podría considerar especificar el nombre del LSP, usando la name opción (show mpls lsp name name o show mpls lsp name name extensive).
Acción
Para comprobar que el LSP está activo, escriba algunos o todos los siguientes comandos desde el enrutador de entrada:
user@host> show mpls lsp user@host> show mpls lsp extensive user@host> show mpls lsp name name user@host> show mpls lsp name name extensive
Ejemplo de salida 1
nombre-comando
user@R1> show mpls lsp Ingress LSP: 1 sessions To From State Rt ActivePath P LSPname 10.0.0.6 10.0.0.1 Dn 0 - R1-to-R6 Total 1 displayed, Up 0, Down 1 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0 user@R3> show mpls lsp Ingress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0 user@R6> show mpls lsp Ingress LSP: 1 sessions To From State Rt ActivePath P LSPname 10.0.0.1 10.0.0.6 Dn 0 - R6-to-R1 Total 1 displayed, Up 0, Down 1 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
Ejemplo de salida 2
nombre-comando
user@R1> show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.6
From: 10.0.0.1, State: Dn, ActiveRoute: 0, LSPname: R1-to-R6
ActivePath: (none)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
Primary State: Dn
Will be enqueued for recomputation in 22 second(s).
1 Nov 2 14:43:38 CSPF failed: no route toward 10.0.0.6 [175 times]
Created: Tue Nov 2 13:18:39 2004
Total 1 displayed, Up 0, Down 1
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
user@R3> show mpls lsp extensive
Ingress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
user@R6> show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.1
From: 10.0.0.6, State: Dn, ActiveRoute: 0, LSPname: R6-to-R1
ActivePath: (none)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
Primary State: Dn
Will be enqueued for recomputation in 13 second(s).
1 Nov 2 14:38:12 CSPF failed: no route toward 10.0.0.1 [177 times]
Created: Tue Nov 2 13:12:22 2004
Total 1 displayed, Up 0, Down 1
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Ejemplo de salida 3
nombre-comando
user@R1> show mpls lsp name R1-to-R6 Ingress LSP: 1 sessions To From State Rt ActivePath P LSPname 10.0.0.6 10.0.0.1 Dn 0 - R1-to-R6 Total 1 displayed, Up 0, Down 1 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
Ejemplo de salida 4
nombre-comando
user@R1> show mpls lsp name R1-to-R6 extensive
Ingress LSP: 1 sessions
10.0.0.6
From: 10.0.0.1, State: Dn, ActiveRoute: 0, LSPname: R1-to-R6
ActivePath: (none)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
Primary State: Dn
Will be enqueued for recomputation in 10 second(s).
1 Nov 2 14:51:53 CSPF failed: no route toward 10.0.0.6[192 times]
Created: Tue Nov 2 13:18:39 2004
Total 1 displayed, Up 0, Down 1
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Significado
El resultado de ejemplo 1 muestra una breve descripción del estado del LSP para los enrutadores de entrada, tránsito y salida. La salida del enrutador R1 de entrada y del enrutador R6 de salida muestra que ambos LSP están inactivos, R1-to-R6 y R6-toR1. Con los LSP configurados activados y R6, esperaríamos sesiones LSP de salida tanto R1 en como R1R6en . Además, el enrutador R3 de tránsito no tiene sesiones de tránsito.
La salida de muestra 2 muestra toda la información sobre los LSP, incluido todo el historial de estado pasado y la razón por la que falló un LSP. Salida de R1 e R6 indica que no hay ninguna ruta al destino porque se produjo un error en el algoritmo de la ruta más corta restringida primero (CSPF).
Los resultados de ejemplo 3 y 4 muestran ejemplos del resultado del show mpls lsp name comando con la extensive opción. En este caso, el resultado es muy similar al show mpls lsp comando porque sólo se configura un LSP en la red de ejemplo en Red MPLS rota en la capa MPLS. Sin embargo, en una red grande con muchos LSP configurados, los resultados serían bastante diferentes entre los dos comandos.
Verificar la ruta LSP en el enrutador de tránsito
Propósito
Si el LSP está activo, la ruta del LSP debe aparecer en la tabla de mpls.0 enrutamiento. MPLS mantiene una tabla de enrutamiento de ruta MPLS (mpls.0), que contiene una lista del siguiente enrutador conmutado por etiquetas en cada LSP. Esta tabla de enrutamiento se utiliza en enrutadores de tránsito para enrutar paquetes al siguiente enrutador a lo largo de un LSP. Si las rutas no están presentes en la salida del enrutador de tránsito, compruebe la configuración del protocolo MPLS en los enrutadores de entrada y salida.
Acción
Para comprobar la ruta LSP en el enrutador de tránsito, escriba el siguiente comando desde el enrutador de tránsito:
user@host> show route table mpls.0
Ejemplo de salida 1
nombre-comando
user@R3> show route table mpls.0
mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 16w2d 21:52:40, metric 1
Receive
1 *[MPLS/0] 16w2d 21:52:40, metric 1
Receive
2 *[MPLS/0] 16w2d 21:52:40, metric 1
Receive
Ejemplo de salida 2
nombre-comando
user@R3> show route table mpls.0
mpls.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 16w2d 22:26:08, metric 1
Receive
1 *[MPLS/0] 16w2d 22:26:08, metric 1
Receive
2 *[MPLS/0] 16w2d 22:26:08, metric 1
Receive
100864 *[RSVP/7] 00:07:23, metric 1
> via so-0/0/2.0, label-switched-path R6-to-R1
100864(S=0) *[RSVP/7] 00:07:23, metric 1
> via so-0/0/2.0, label-switched-path R6-to-R1
100880 *[RSVP/7] 00:07:01, metric 1
> via so-0/0/3.0, label-switched-path R1-to-R6
100880(S=0) *[RSVP/7] 00:07:01, metric 1
> via so-0/0/3.0, label-switched-path R1-to-R6
Significado
La salida de muestra 1 del enrutador R3 de tránsito muestra tres entradas de ruta en forma de entradas de etiqueta MPLS. Estas etiquetas MPLS son etiquetas MPLS reservadas definidas en RFC 3032 y siempre están presentes en la mpls.0 tabla de enrutamiento, independientemente del estado del LSP. Las etiquetas entrantes asignadas por RSVP al vecino ascendente faltan en la salida, lo que indica que el LSP está inactivo. Para obtener más información sobre las entradas de etiquetas MPLS, consulte Lista de comprobación para verificar el uso de LSP.
Por el contrario, la salida de ejemplo 2 muestra las etiquetas MPLS y las rutas para un LSP configurado correctamente. Las tres etiquetas MPLS reservadas están presentes, y las otras cuatro entradas representan las etiquetas entrantes asignadas por RSVP al vecino ascendente. Estas cuatro entradas representan dos rutas. Hay dos entradas por ruta porque los valores de pila en el encabezado MPLS pueden ser diferentes. Para cada ruta, la segunda entrada 100864 (S=0) e 100880 (S=0) indica que la profundidad de pila no es 1 y se incluyen valores de etiqueta adicionales en el paquete. En contraste, la primera entrada, 100864 y 100880 tiene un valor S = 1 inferido que indica una profundidad de pila de 1 y hace que cada etiqueta sea la última etiqueta en ese paquete en particular. Las entradas duales indican que este es el penúltimo enrutador. Para obtener más información sobre el apilamiento de etiquetas MPLS, consulte RFC 3032, Codificación de pila de etiquetas MPLS.
Verificar la ruta LSP en el enrutador de entrada
Propósito
Compruebe si la ruta LSP está incluida en las entradas activas de la tabla de inet.3 enrutamiento para la dirección especificada.
Acción
Para comprobar la ruta LSP, escriba el siguiente comando desde el enrutador de entrada:
user@host> show route destination
Ejemplo de salida 1
nombre-comando
user@R1> show route 10.0.0.6
inet.0 : 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.6/32 *[IS-IS/18] 6d 01:41:37, metric 20
to 10.1.12.2 via so-0/0/0.0
> to 10.1.15.2 via so-0/0/1.0
to 10.1.13.2 via so-0/0/2.0
user@R6> show route 10.0.0.1
inet.0 : 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.1/32 *[IS-IS/18] 5d 01:01:38, metric 20
to 10.1.56.1 via so-0/0/0.0
> to 10.1.26.1 via so-0/0/2.0
to 10.1.36.1 via so-0/0/3.0
Ejemplo de salida 2
nombre-comando
user@R1> show route 10.0.0.6
inet.0: 28 destinations, 28 routes (27 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.6/32 *[IS-IS/18] 6d 02:13:42, metric 20
to 10.1.12.2 via so-0/0/0.0
> to 10.1.15.2 via so-0/0/1.0
to 10.1.13.2 via so-0/0/2.0
inet.3 : 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.6/32 *[RSVP/7] 00:08:07, metric 20
> via so-0/0/2.0, label-switched-path R1-to-R6
user@R6> show route 10.0.0.1
inet.0: 29 destinations, 29 routes (28 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.1/32 *[IS-IS/18] 5d 01:34:03, metric 20
to 10.1.56.1 via so-0/0/0.0
> to 10.1.26.1 via so-0/0/2.0
to 10.1.36.1 via so-0/0/3.0
inet.3 : 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.1/32 *[RSVP/7] 00:10:39, metric 20
> via so-0/0/3.0, label-switched-path R6-to-R1
Significado
La salida de ejemplo 1 muestra solo las entradas de la tabla de inet.0 enrutamiento. Falta la inet.3 tabla de enrutamiento en la salida porque el LSP no funciona. Los inet.0 protocolos de puerta de enlace interior (IGP) y el protocolo de puerta de enlace de borde (BGP) utilizan la tabla de enrutamiento para almacenar información de enrutamiento. En este caso, el IGP es Sistema Intermedio a Sistema Intermedio (IS-IS). Para obtener más información sobre la tabla de inet.0 enrutamiento, consulte la Guía de configuración de aplicaciones MPLS de Junos.
Si el LSP funcionaba, esperaríamos ver entradas que incluyeran el LSP en la tabla de inet.3 enrutamiento. La inet.3 tabla de enrutamiento se utiliza en los enrutadores de entrada para enrutar paquetes BGP al enrutador de salida de destino. BGP utiliza la tabla de enrutamiento del enrutador de entrada para ayudar a resolver las inet.3 direcciones del próximo salto. BGP se configura en la red de ejemplo que se muestra en Red MPLS rota en la capa MPLS.
La salida de muestra 2 muestra la salida que debe recibir cuando el LSP está activo. El resultado muestra las tablas y inet.3 de inet.0 enrutamiento, lo que indica que los R1-to-R6 LSP y R6-to-R1 están disponibles.
Verificar etiquetas MPLS con el comando traceroute
Propósito
Muestra la ruta que los paquetes llevan a un destino BGP donde el siguiente salto del BGP para esa ruta es la dirección de salida de LSP. De forma predeterminada, BGP utiliza las tablas de inet.0 enrutamiento y para inet.3 resolver la dirección del salto siguiente. Cuando la dirección del próximo salto de la ruta BGP no es el ID de enrutador del enrutador de salida, el tráfico se asigna a rutas IGP, no al LSP. Utilice el traceroute comando como herramienta de depuración para determinar si el LSP se está utilizando para reenviar tráfico.
Acción
Para comprobar las etiquetas MPLS, escriba el siguiente comando desde el enrutador de entrada:
user@host> traceroute hostname
Ejemplo de salida 1
nombre-comando
user@R1> traceroute 100.100.6.1 traceroute to 100.100.6.1 (100.100.6.1), 30 hops max, 40 byte packets 1 10.1.12.2 (10.1.12.2) 0.627 ms 0.561 ms 0.520 ms 2 10.1.26.2 (10.1.26.2) 0.570 ms !N 0.558 ms !N 4.879 ms !N user@R6> traceroute 100.100.1.1 traceroute to 100.100.1.1 (100.100.1.1), 30 hops max, 40 byte packets 1 10.1.26.1 (10.1.26.1) 0.630 ms 0.545 ms 0.488 ms 2 10.1.12.1 (10.1.12.1) 0.551 ms !N 0.557 ms !N 0.526 ms !N
Ejemplo de salida 2
nombre-comando
user@R1> traceroute 100.100.6.1
to 100.100.6.1 (100.100.6.1), 30 hops max, 40 byte packets
1 10.1.13.2 (10.1.13.2) 0.866 ms 0.746 ms 0.724 ms
MPLS Label=100912 CoS=0 TTL=1 S=1
2 10.1.36.2 (10.1.36.2) 0.577 ms !N 0.597 ms !N 0.546 ms !N
user@R6> traceroute 100.100.1.1
traceroute to 100.100.1.1 (100.100.1.1), 30 hops max, 40 byte packets
1 10.1.36.1 (10.1.36.1) 0.802 ms 0.716 ms 0.688 ms
MPLS Label=100896 CoS=0 TTL=1 S=1
2 10.1.13.1 (10.1.13.1) 0.570 ms !N 0.568 ms !N 0.546 ms !N
Significado
La salida de ejemplo 1 muestra que el tráfico BGP no utiliza el LSP, por lo que las etiquetas MPLS no aparecen en la salida. En lugar de usar el LSP, el tráfico del BGP usa el IGP (IS-IS, en la red de ejemplo en MPLS Network Broken at the MPLS Layer) para llegar a la dirección de salida de LSP del próximo salto del BGP. El comportamiento predeterminado de Junos OS utiliza LSP para el tráfico BGP cuando el próximo salto del BGP es igual a la dirección de salida del LSP.
La salida de ejemplo 2 es un ejemplo de salida para un LSP configurado correctamente. El resultado muestra etiquetas MPLS, lo que indica que el tráfico BGP está utilizando el LSP para alcanzar el siguiente salto del BGP.
Verificar etiquetas MPLS con el comando ping
Propósito
Cuando hace ping a un LSP específico, comprueba que las solicitudes de eco se envían a través del LSP como paquetes MPLS.
Acción
Para verificar las etiquetas MPLS, escriba el siguiente comando desde el enrutador de entrada para hacer ping al enrutador de salida:
user@host> ping mpls rsvp lsp-name detail
Por ejemplo:
user@R1> ping mpls rsvp R1-to-R6 detail
Ejemplo de salida 1
nombre-comando
user@R1> ping mpls rsvp R1-to-R6 detail LSP R1-to-R6 - LSP has no active path, exiting. user@R6> ping mpls rsvp R6-to-R1 detail LSP R6-to-R1 - LSP has no active path, exiting.
Ejemplo de salida 2
nombre-comando
user@R1> traceroute 10.0.0.6 traceroute to 10.0.0.6 (10.0.0.6), 30 hops max, 40 byte packets 1 10.1.15.2 (10.1.15.2) 0.708 ms 0.613 ms 0.576 ms 2 10.0.0.6 (10.0.0.6) 0.763 ms 0.708 ms 0.700 ms user@R1> ping mpls rsvp R1-to-R6 detail Request for seq 1, to interface 69, label 100880 Reply for seq 1, return code: Egress-ok Request for seq 2, to interface 69, label 100880 Reply for seq 2, return code: Egress-ok Request for seq 3, to interface 69, label 100880 Reply for seq 3, return code: Egress-ok Request for seq 4, to interface 69, label 100880 Reply for seq 4, return code: Egress-ok Request for seq 5, to interface 69, label 100880 Reply for seq 5, return code: Egress-ok --- lsping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss user@R6> ping mpls rsvp R6-to-R1 detail Request for seq 1, to interface 70, label 100864 Reply for seq 1, return code: Egress-ok Request for seq 2, to interface 70, label 100864 Reply for seq 2, return code: Egress-ok Request for seq 3, to interface 70, label 100864 Reply for seq 3, return code: Egress-ok Request for seq 4, to interface 70, label 100864 Reply for seq 4, return code: Egress-ok Request for seq 5, to interface 70, label 100864 Reply for seq 5, return code: Egress-ok --- lsping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss
Significado
El resultado de ejemplo 1 muestra que el LSP no tiene una ruta activa para reenviar solicitudes de eco, lo que indica que el LSP está inactivo.
La salida de ejemplo 2 es un ejemplo de salida que debe recibir cuando el LSP está activo y reenviando paquetes.
Tome las medidas apropiadas
Problema
Description
En función del error que haya encontrado en la investigación, debe tomar las medidas adecuadas para corregir el problema. En este ejemplo, una interfaz está configurada incorrectamente en el nivel de jerarquía [edit protocols mpls] en el enrutador de salida R6.
Solución
Para corregir el error de este ejemplo, siga estos pasos:
Active la interfaz en la configuración del protocolo MPLS en el enrutador R6de salida:
user@R6> edit user@R6# edit protocols mpls [edit protocols mpls] user@R6# show user@R6# activate interface so-0/0/3.0
Compruebe y confirme la configuración:
[edit protocols mpls] user@R6# show user@R6# commit
Salida de muestra
user@R6> edit
Entering configuration mode
[edit]
user@R6# edit protocols mpls
[edit protocols mpls]
user@R6# show
label-switched-path R6-to-R1 {
to 10.0.0.1;
}
inactive: interface so-0/0/0.0;
inactive: interface so-0/0/1.0;
inactive: interface so-0/0/2.0;
inactive: interface so-0/0/3.0; <<< Incorrectly configured interface
[edit protocols mpls]
user@R6# activate interface so-0/0/3
[edit protocols mpls]
user@R6# show
label-switched-path R6-to-R1 {
to 10.0.0.1;
}
inactive: interface so-0/0/0.0;
inactive: interface so-0/0/1.0;
inactive: interface so-0/0/2.0;
interface so-0/0/3.0; <<< Correctly configured interface
[edit protocols mpls]
user@R6# commit
commit complete
Significado
El resultado de ejemplo muestra que la interfaz so-0/0/3.0 configurada incorrectamente en el enrutador R6 de salida ahora está activada en el nivel de jerarquía [edit protocols mpls]. El LSP ahora puede surgir.
Compruebe de nuevo el LSP
Propósito
Después de tomar las medidas adecuadas para corregir el error, es necesario comprobar de nuevo el LSP para confirmar que se ha resuelto el problema en la capa BGP.
Acción
Para comprobar de nuevo el LSP, escriba el siguiente comando desde los enrutadores de entrada, tránsito y salida:
user@host> show mpls lsp extensive
Salida de muestra
nombre-comando
user@R1> show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.6
From: 10.0.0.1, State: Up , ActiveRoute: 1 , LSPname: R1-to-R6
ActivePath: (primary)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20)
10.1.13.2 S 10.1.36.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.1.13.2 10.1.36.2
6 Nov 2 15:48:52 Selected as active path
5 Nov 2 15:48:52 Record Route: 10.1.13.2 10.1.36.2
4 Nov 2 15:48:52 Up
3 Nov 2 15:48:52 Originate Call
2 Nov 2 15:48:52 CSPF: computation result accepted
1 Nov 2 15:48:22 CSPF failed: no route toward 10.0.0.6[308 times]
Created: Tue Nov 2 13:18:39 2004
Total 1 displayed, Up 1, Down 0
Egress LSP: 1 sessions
10.0.0.1
From: 10.0.0.6, LSPstate: Up , ActiveRoute: 0
LSPname: R6-to-R1 , LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 159, Since: Tue Nov 2 15:48:30 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 39106 protocol 0
PATH rcvfrom: 10.1.13.2 (so-0/0/2.0) 10 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.1.36.2 10.1.13.2 <self>
Total 1 displayed, Up 1, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
user@R3> show mpls lsp extensive
Ingress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 2 sessions
10.0.0.1
From: 10.0.0.6, LSPstate: Up, ActiveRoute: 1
LSPname: R6-to-R1, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 3
Resv style: 1 FF, Label in: 100864, Label out: 3
Time left: 123, Since: Tue Nov 2 15:35:41 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 39106 protocol 0
PATH rcvfrom: 10.1.36.2 (so-0/0/3.0) 10 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.1.13.1 (so-0/0/2.0) 10 pkts
RESV rcvfrom: 10.1.13.1 (so-0/0/2.0) 10 pkts
Explct route: 10.1.13.1
Record route: 10.1.36.2 <self> 10.1.13.1
10.0.0.6
From: 10.0.0.1, LSPstate: Up, ActiveRoute: 1
LSPname: R1-to-R6, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 3
Resv style: 1 FF, Label in: 100880, Label out: 3
Time left: 145, Since: Tue Nov 2 15:36:03 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 48015 protocol 0
PATH rcvfrom: 10.1.13.1 (so-0/0/2.0) 10 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.1.36.2 (so-0/0/3.0) 10 pkts
RESV rcvfrom: 10.1.36.2 (so-0/0/3.0) 10 pkts
Explct route: 10.1.36.2
Record route: 10.1.13.1 <self> 10.1.36.2
Total 2 displayed, Up 2, Down 0
user@R6> show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.1
From: 10.0.0.6, State: Up, ActiveRoute: 1, LSPname: R6-to-R1
ActivePath: (primary)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20)
10.1.36.1 S 10.1.13.1 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.1.36.1 10.1.13.1
6 Nov 2 15:41:44 Selected as active path
5 Nov 2 15:41:44 Record Route: 10.1.36.1 10.1.13.1
4 Nov 2 15:41:44 Up
3 Nov 2 15:41:44 Originate Call
2 Nov 2 15:41:44 CSPF: computation result accepted
1 Nov 2 15:41:14 CSPF failed: no route toward 10.0.0.1[306 times]
Created: Tue Nov 2 13:12:21 2004
Total 1 displayed, Up 1, Down 0
Egress LSP: 1 sessions
10.0.0.6
From: 10.0.0.1, LSPstate: Up, ActiveRoute: 0
LSPname: R1-to-R6 , LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 157, Since: Tue Nov 2 15:42:06 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 48015 protocol 0
PATH rcvfrom: 10.1.36.1 (so-0/0/3.0) 11 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.1.13.1 10.1.36.1 <self>
Total 1 displayed, Up 1, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Significado
La salida de muestra 1 del enrutador R1 de entrada muestra que el LSP R1-to-R6 tiene una ruta activa hacia R6 y que el estado está activo.
La salida de ejemplo 2 del enrutador R3 de tránsito muestra que hay dos sesiones LSP de tránsito, una de R1 a R6 y la otra de R6 a .R1 Ambos LSP están activos.
La salida de muestra 3 del enrutador R6 de salida muestra que el LSP está activo y que la ruta activa es la ruta principal. El LSP ahora atraviesa la red a lo largo de la ruta esperada, desde R1 hasta R3 , y el LSP inverso, desde R6 hasta R3R1.R6
Verificar que la protección de vínculo de nodo esté activa
Propósito
Después de configurar la protección de vínculo de nodo, debe comprobar que las rutas de desvío estén activas. También puede comprobar el número de LSP protegidos por las rutas de desvío. En la red que se muestra en Node-Link Protection, deben estar activas dos rutas de derivación: una ruta de derivación del salto siguiente que protege el vínculo entre R1 y R2 (o el salto 10.0.12.14siguiente) y una ruta de derivación del siguiente salto que evita R2.
Acción
Para verificar la protección de vínculo de nodo (copia de seguridad varios a uno), introduzca los siguientes comandos de modo operativo de la CLI de Junos OS en el enrutador de entrada. También puede emitir los comandos en enrutadores de tránsito y otros enrutadores utilizados en la ruta de derivación para obtener información ligeramente diferente.
show mpls lsp show mpls lsp extensive show rsvp interface show rsvp interface extensive show rsvp session detail
Salida de muestra
nombre-comando
user@R1> show mpls lsp
Ingress LSP: 1 sessions
To From State Rt ActivePath P LSPname
192.168.5.1 192.168.1.1 Up 0 via-r2 * lsp2-r1-to-r5
Total 1 displayed, Up 1 , Down 0
Egress LSP: 1 sessions
To From State Rt Style Labelin Labelout LSPname
192.168.1.1 192.168.5.1 Up 0 1 FF 3 - r5-to-r1
Total 1 displayed, Up 1 , Down 0
Transit LSP: 2 sessions
To From State Rt Style Labelin Labelout LSPname
192.168.0.1 192.168.6.1 Up 0 1 FF 100464 101952 lsp1-r6-to-r0
192.168.6.1 192.168.0.1 Up 0 1 FF 100448 3 r0-to-t6
Total 2 displayed, Up 2, Down 0
Significado
La salida de ejemplo de R1 para el show mpls lsp comando muestra una breve descripción del estado de los LSP configurados y activos para los que R1 es el enrutador de entrada, tránsito y salida. Todos los LSP están activos. R1 es el enrutador de entrada para lsp2-r1-to-r5y el enrutador de salida para el LSP r5-to-r1de retorno. Dos LSPs transitan R1, lsp1-r6-to-r0 y el LSP r0-to-t6de retorno. Para obtener información más detallada acerca del LSP, incluya la extensive opción cuando ejecute el show mpls lsp comando.
- Salida de muestra
- Significado
- Salida de muestra
- Significado
- Salida de muestra
- Significado
- Salida de muestra
- Significado
- Conclusión
- Información relacionada
Salida de muestra
user@R1> show mpls lsp extensive
Ingress LSP: 1 sessions
192.168.5.1
From: 192.168.1.1, State: Up , ActiveRoute: 0, LSPname: lsp2-r1-to-r5
ActivePath: via-r2 (primary)
Node/Link protection desired
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary via-r2 State: Up
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
10.0.12.14 S 10.0.24.2 S 10.0.45.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.0.12.14(Label=101872) 10.0.24.2(Label=101360) 10.0.45.2(Label=3)
11 Jul 11 14:30:58 Link-protection Up
10 Jul 11 14:28:28 Selected as active path
[...Output truncated...]
Created: Tue Jul 11 14:22:58 2006
Total 1 displayed, Up 1, Down 0
Egress LSP: 1 sessions
192.168.1.1
From: 192.168.5.1, LSPstate: Up, ActiveRoute: 0
LSPname: r5-to-r1, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 146, Since: Tue Jul 11 14:28:36 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 29228 protocol 0
PATH rcvfrom: 10.0.12.14 (fe-0/1/0.0) 362 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.0.45.2 10.0.24.2 10.0.12.14 <self>
Total 1 displayed, Up 1, Down 0
Transit LSP: 2 sessions
192.168.0.1
From: 192.168.6.1, LSPstate: Up, ActiveRoute: 0
LSPname: lsp1-r6-to-r0, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 101952
Resv style: 1 SE, Label in: 100464, Label out: 101952
Time left: 157, Since: Tue Jul 11 14:31:38 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 11131 protocol 0
Node/Link protection desired
Type: Node/Link protected LSP, using Bypass->10.0.12.14->10.0.24.2
1 Jul 11 14:31:38 Node protection up, using Bypass->10.0.12.14->10.0.24.2
PATH rcvfrom: 10.0.16.2 (so-0/0/3.0) 509 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.0.12.14 (fe-0/1/0.0) 356 pkts
RESV rcvfrom: 10.0.12.14 (fe-0/1/0.0) 358 pkts
Explct route: 10.0.12.14 10.0.24.2 10.0.45.2 10.0.50.2
Record route: 10.0.16.2 <self> 10.0.12.14 10.0.24.2 10.0.45.2 10.0.50.2
192.168.6.1
From: 192.168.0.1, LSPstate: Up, ActiveRoute: 0
LSPname: r0-to-t6, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 3
Resv style: 1 FF, Label in: 100448, Label out: 3
Time left: 147, Since: Tue Jul 11 14:31:36 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 23481 protocol 0
PATH rcvfrom: 10.0.12.14 (fe-0/1/0.0) 358 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.0.16.2 (so-0/0/3.0) 350 pkts
RESV rcvfrom: 10.0.16.2 (so-0/0/3.0) 323 pkts
Explct route: 10.0.16.2
Record route: 10.0.50.2 10.0.45.2 10.0.24.2 10.0.12.14 <self> 10.0.16.2
Total 2 displayed, Up 2, Down 0
Significado
La salida de ejemplo de para el show mpls lsp extensive comando muestra información detallada sobre todos los LSP para los que R1 es el enrutador de entrada, salida o tránsito, incluido todo el historial de R1 estado pasado y la razón por la que se produjo un error en un LSP. Todos los LSP están activos. Los dos principales LSP lsp2-r1-to-r5 y lsp1-r6-to-r0 tienen protección de vínculo de nodo como lo indica el Node/Link protection desired campo en las secciones de entrada y tránsito de la salida. En la sección de entrada de la salida, el Link-protection Up campo muestra que lsp2-r1-to-r5 tiene la protección del vínculo activada. En la sección de tránsito de la salida, el Type: Node/Link protected LSP campo muestra que lsp1-r6-to-r0 tiene protección de vínculo de nodo y, en caso de fallo, usará el bypass LSP Bypass->10.0.12.14->10.0.24.2.
Salida de muestra
user@R1> show rsvp interface
RSVP interface: 4 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
fe-0/1/0.0 Up 2 100% 100Mbps 100Mbps 0bps 0bps
fe-0/1/1.0 Up 1 100% 100Mbps 100Mbps 0bps 0bps
fe-0/1/2.0 Up 0 100% 100Mbps 100Mbps 0bps 0bps
so-0/0/3.0 Up 1 100% 155.52Mbps 155.52Mbps 0bps 0bps
Significado
El resultado de ejemplo de R1 para el show rsvp interface comando muestra cuatro interfaces habilitadas con RSVP (Up). La interfaz fe-0/1/0.0 tiene dos reservas de RSVP activas (Active resv) que pueden indicar sesiones para los dos LSP principales, lsp1-r6-to-r0 y lsp2-r1-to-r5. la interfaz fe-0/1/0.0 es la interfaz de conexión entre R1 y R2, y ambos LSP están configurados con una ruta estricta a través de fe-0/1/0.0. Para obtener información más detallada acerca de lo que está sucediendo en la interfaz fe-0/1/0.0, ejecute el show rsvp interface extensive comando.
Salida de muestra
user@R1> show rsvp interface extensive
RSVP interface: 3 active
fe-0/1/0.0 Index 67, State Ena/Up
NoAuthentication, NoAggregate, NoReliable, LinkProtection
HelloInterval 9(second)
Address 10.0.12.13
ActiveResv 2, PreemptionCnt 0, Update threshold 10%
Subscription 100%,
bc0 = ct0, StaticBW 100Mbps
ct0: StaticBW 100Mbps, AvailableBW 100Mbps
MaxAvailableBW 100Mbps = (bc0*subscription)
ReservedBW [0] 0bps[1] 0bps[2] 0bps[3] 0bps[4] 0bps[5] 0bps[6] 0bps[7] 0bps
Protection: On, Bypass: 2, LSP: 2, Protected LSP: 2, Unprotected LSP: 0
2 Jul 14 14:49:40 New bypass Bypass->10.0.12.14
1 Jul 14 14:49:34 New bypass Bypass->10.0.12.14->10.0.24.2
Bypass: Bypass->10.0.12.14, State: Up, Type: LP, LSP: 0, Backup: 0
3 Jul 14 14:49:42 Record Route: 10.0.17.14 10.0.27.1
2 Jul 14 14:49:42 Up
1 Jul 14 14:49:42 CSPF: computation result accepted
Bypass: Bypass->10.0.12.14->10.0.24.2, State: Up, Type: NP, LSP: 2, Backup:0
4 Jul 14 14:50:04 Record Route: 10.0.17.14 10.0.79.2 10.0.59.1 10.0.45.1
3 Jul 14 14:50:04 Up
2 Jul 14 14:50:04 CSPF: computation result accepted
1 Jul 14 14:49:34 CSPF failed: no route toward 10.0.24.2
[...Output truncated...]
Significado
El resultado de ejemplo de R1 para el show rsvp interface extensive comando muestra información más detallada sobre la actividad en todas las interfaces RSVP (3). Sin embargo, solo se muestra la salida para fe-0/1/0.0 . La protección está habilitada (Protection: On), con dos rutas de derivación (Bypass: 2) que protegen dos LSP (Protected LSP: 2). Todos los LSP están protegidos, como lo indica el Unprotected LSP: 0 campo. El primer bypass Bypass->10.0.12.14es una ruta de bypass de protección de vínculo (Type: LP), que protege el vínculo entre R1 y R2 fe-0/1/0.0. La segunda ruta 10.0.12.14->10.0.24.2 de bypass es un LSP protegido por nodo-link, evitando R2 en caso de fallo del nodo.
Salida de muestra
user@R1> show rsvp session detail
Ingress RSVP: 2 sessions
192.168.4.1
From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0
LSPname: Bypass->10.0.12.14->10.0.24.2
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 102000
Resv style: 1 SE, Label in: -, Label out: 102000
Time left: -, Since: Tue Jul 11 14:30:53 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 60120 protocol 0
Type: Bypass LSP
Number of data route tunnel through: 2
Number of RSVP session tunnel through: 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 10.0.17.14 (fe-0/1/1.0) 336 pkts
RESV rcvfrom: 10.0.17.14 (fe-0/1/1.0) 310 pkts
Explct route: 10.0.17.14 10.0.79.2 10.0.59.1 10.0.45.1
Record route: <self> 10.0.17.14 10.0.79.2 10.0.59.1 10.0.45.1
192.168.5.1
From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0
LSPname: lsp2-r1-to-r5, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 101872
Resv style: 1 SE, Label in: -, Label out: 101872
Time left: -, Since: Tue Jul 11 14:28:28 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 2 receiver 60118 protocol 0
Node/Link protection desired
Type: Node/Link protected LSP
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 10.0.12.14 (fe-0/1/0.0) 344 pkts
RESV rcvfrom: 10.0.12.14 (fe-0/1/0.0) 349 pkts
Explct route: 10.0.12.14 10.0.24.2 10.0.45.2
Record route: <self> 10.0.12.14 10.0.24.2 10.0.45.2
Total 2 displayed, Up 2, Down 0
Egress RSVP: 1 sessions
192.168.1.1
From: 192.168.5.1, LSPstate: Up, ActiveRoute: 0
LSPname: r5-to-r1, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 147, Since: Tue Jul 11 14:28:36 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 29228 protocol 0
PATH rcvfrom: 10.0.12.14 (fe-0/1/0.0) 348 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.0.45.2 10.0.24.2 10.0.12.14 <self>
Total 1 displayed, Up 1, Down 0
Transit RSVP: 2 sessions
192.168.0.1
From: 192.168.6.1, LSPstate: Up, ActiveRoute: 0
LSPname: lsp1-r6-to-r0, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 101952
Resv style: 1 SE, Label in: 100464, Label out: 101952
Time left: 134, Since: Tue Jul 11 14:31:38 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 11131 protocol 0
Node/Link protection desired
Type: Node/Link protected LSP
PATH rcvfrom: 10.0.16.2 (so-0/0/3.0) 488 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.0.12.14 (fe-0/1/0.0) 339 pkts
RESV rcvfrom: 10.0.12.14 (fe-0/1/0.0) 343 pkts
Explct route: 10.0.12.14 10.0.24.2 10.0.45.2 10.0.50.2
Record route: 10.0.16.2 <self> 10.0.12.14 10.0.24.2 10.0.45.2 10.0.50.2
192.168.6.1
From: 192.168.0.1, LSPstate: Up, ActiveRoute: 0
LSPname: r0-to-t6, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 3
Resv style: 1 FF, Label in: 100448, Label out: 3
Time left: 158, Since: Tue Jul 11 14:31:36 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 23481 protocol 0
PATH rcvfrom: 10.0.12.14 (fe-0/1/0.0) 344 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.0.16.2 (so-0/0/3.0) 337 pkts
RESV rcvfrom: 10.0.16.2 (so-0/0/3.0) 310 pkts
Explct route: 10.0.16.2
Record route: 10.0.50.2 10.0.45.2 10.0.24.2 10.0.12.14 <self> 10.0.16.2
Total 2 displayed, Up 2, Down 0
Significado
El resultado de muestra muestra R1 información detallada sobre las sesiones de RSVP activas en R1. Todas las sesiones están activas, con dos sesiones de ingreso, una sesión de salida y dos sesiones de tránsito.
Dentro de la sección de entrada, la primera sesión es una ruta de desvío, como lo indica el Type: Bypass LSP campo; y la segunda sesión es un LSP protegido (lsp2-r1-to-r5) originado en R1, como lo indica el Type: Node/Link protected LSP campo.
Conclusión
La protección de vínculos de ruta conmutada de etiquetas (LSP) y la protección de vínculo de nodo de conmutación de etiquetas multiprotocolo (MPLS) son métodos basados en instalaciones que se utilizan para reducir la cantidad de tiempo necesario para redireccionar el tráfico de LSP. Estos métodos de protección suelen compararse con el reenrutamiento rápido, el otro método de protección LSP de Junos OS.
Mientras que el reenrutamiento rápido protege a los LSP de forma individual, la protección de vínculos y la protección de vínculo de nodo protegen múltiples LSP mediante un único LSP de derivación lógica. La protección de vínculos proporciona un sólido soporte de copia de seguridad para un vínculo, la protección nodo-vínculo evita un nodo o un vínculo, y ambos tipos de protección están diseñados para interoperar con equipos de otros proveedores. Dicha funcionalidad hace que la protección de vínculos y la protección de vínculos de nodo sean excelentes opciones de escalabilidad, redundancia y rendimiento en redes habilitadas para MPLS.
Información relacionada
Para obtener información adicional acerca del reenrutamiento rápido MPLS y los métodos de protección MPLS, consulte lo siguiente:
Guía del usuario de Junos
Guía de configuración de aplicaciones MPLS de Junos
Semeria, Chuck. Extensiones de señalización RSVP para ingeniería de tráfico MPLS. Informe técnico. 2002
Semeria, Chuck. Confiabilidad de IP: Protección de nodos y vínculos de red. Informe técnico. 2002
RFC 4090, Extensiones de reenrutamiento rápido a RSVP-TE para túneles LSP
Comprobar que la protección de vínculos esté activa
Propósito
Cuando verifique la protección de vínculos, debe comprobar que el LSP de omisión esté activo. También puede comprobar el número de LSP protegidos por el bypass. En la red mostrada en Protección varios a uno o de vínculo, una ruta de derivación debe estar lista para proteger el vínculo entre R1 y , R2o el salto 10.0.12.14siguiente , y los dos LSP que atraviesan el vínculo, lsp2-r1-to-r5 y lsp1-r6-to-r0.
Acción
Para verificar la protección de vínculos (copia de seguridad varios a uno), introduzca los siguientes comandos del modo operativo de la CLI de Junos OS en el enrutador de entrada:
user@host> show mpls lsp extensive user@host> show rsvp session detail user@host> show rsvp interface
Salida de muestra
nombre-comando
user@R1> show mpls lsp extensive | no-more
Ingress LSP: 1 sessions
192.168.5.1
From: 192.168.1.1, State: Up, ActiveRoute: 0, LSPname: lsp2-r1-to-r5
ActivePath: via-r2 (primary)
Link protection desired
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary via-r2 State: Up
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
10.0.12.14 S 10.0.24.2 S 10.0.45.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.0.12.14(Label=101264) 10.0.24.2(Label=100736) 10.0.45.2(Label=3)
6 Jun 16 14:06:33 Link-protection Up
5 Jun 16 14:05:39 Selected as active path
4 Jun 16 14:05:39 Record Route: 10.0.12.14(Label=101264) 10.0.24.2(Label=100736) 10.0.45.2(Label=3)
3 Jun 16 14:05:39 Up
2 Jun 16 14:05:39 Originate Call
1 Jun 16 14:05:39 CSPF: computation result accepted
Created: Fri Jun 16 14:05:38 2006
Total 1 displayed, Up 1, Down 0
[...Output truncated...]
Transit LSP: 2 sessions
192.168.0.1
From: 192.168.6.1, LSPstate: Up, ActiveRoute: 0
LSPname: lsp1-r6-to-r0, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 101296
Resv style: 1 SE, Label in: 100192, Label out: 101296
Time left: 116, Since: Mon Jun 19 10:26:32 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 58739 protocol 0
Link protection desired
Type: Link protected LSP, using Bypass->10.0.12.14
1 Jun 19 10:26:32 Link protection up, using Bypass->10.0.12.14
PATH rcvfrom: 10.0.16.2 (so-0/0/3.0) 579 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.0.12.14 (fe-0/1/0.0) 474 pkts
RESV rcvfrom: 10.0.12.14 (fe-0/1/0.0) 501 pkts
Explct route: 10.0.12.14 10.0.24.2 10.0.45.2 10.0.50.2
Record route: 10.0.16.2 <self> 10.0.12.14 10.0.24.2 10.0.45.2 10.0.50.2
[...Output truncated...]
Significado
La salida de ejemplo del enrutador R1 de entrada muestra que lsp2-r1-to-r5 y lsp1-r6-to-r0 tiene la protección de vínculo activada, y ambos LSP están utilizando la ruta de derivación, 10.0.12.14. Sin embargo, el show mpls lsp comando no muestra la ruta de derivación. Para obtener información acerca de la ruta de derivación, utilice el show rsvp session comando.
Salida de muestra
user@R1> show rsvp session detail
Ingress RSVP: 2 sessions
192.168.2.1
From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0
LSPname: Bypass->10.0.12.14
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 101456
Resv style: 1 SE, Label in: -, Label out: 101456
Time left: -, Since: Fri May 26 18:38:09 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 18709 protocol 0
Type: Bypass LSP
Number of data route tunnel through: 2
Number of RSVP session tunnel through: 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 10.0.17.14 (fe-0/1/1.0) 51939 pkts
RESV rcvfrom: 10.0.17.14 (fe-0/1/1.0) 55095 pkts
Explct route: 10.0.17.14 10.0.27.1
Record route: <self> 10.0.17.14 10.0.27.1
192.168.5.1
From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0
LSPname: lsp2-r1-to-r5, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 101264
Resv style: 1 SE, Label in: -, Label out: 101264
Time left: -, Since: Fri Jun 16 14:05:39 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 18724 protocol 0
Link protection desired
Type: Link protected LSP
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 10.0.12.14 (fe-0/1/0.0) 8477 pkts
RESV rcvfrom: 10.0.12.14 (fe-0/1/0.0) 8992 pkts
Explct route: 10.0.12.14 10.0.24.2 10.0.45.2
Record route: <self> 10.0.12.14 10.0.24.2 10.0.45.2
Total 2 displayed, Up 2, Down 0
Egress RSVP: 1 sessions
192.168.1.1
From: 192.168.5.1, LSPstate: Up, ActiveRoute: 0
LSPname: r5-to-r1, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 159, Since: Mon May 22 22:08:16 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 64449 protocol 0
PATH rcvfrom: 10.0.17.14 (fe-0/1/1.0) 63145 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.0.59.1 10.0.79.2 10.0.17.14 <self>
Total 1 displayed, Up 1, Down 0
Transit RSVP: 2 sessions
192.168.0.1
From: 192.168.6.1, LSPstate: Up, ActiveRoute: 0
LSPname: lsp1-r6-to-r0, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 101296
Resv style: 1 SE, Label in: 100192, Label out: 101296
Time left: 129, Since: Mon Jun 19 10:26:32 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 58739 protocol 0
Link protection desired
Type: Link protected LSP
PATH rcvfrom: 10.0.16.2 (so-0/0/3.0) 3128 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.0.12.14 (fe-0/1/0.0) 2533 pkts
RESV rcvfrom: 10.0.12.14 (fe-0/1/0.0) 2685 pkts
Explct route: 10.0.12.14 10.0.24.2 10.0.45.2 10.0.50.2
Record route: 10.0.16.2 <self> 10.0.12.14 10.0.24.2 10.0.45.2 10.0.50.2
192.168.6.1
From: 192.168.0.1, LSPstate: Up, ActiveRoute: 0
LSPname: r0-to-r6, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 3
Resv style: 1 FF, Label in: 100128, Label out: 3
Time left: 143, Since: Thu May 25 12:30:26 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 4111 protocol 0
PATH rcvfrom: 10.0.17.14 (fe-0/1/1.0) 57716 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.0.16.2 (so-0/0/3.0) 54524 pkts
RESV rcvfrom: 10.0.16.2 (so-0/0/3.0) 50534 pkts
Explct route: 10.0.16.2
Record route: 10.0.50.2 10.0.59.1 10.0.79.2 10.0.17.14 <self> 10.0.16.2
Total 2 displayed, Up 2, Down 0
Significado
La salida de ejemplo del enrutador R1 de entrada muestra los LSP de entrada, salida y tránsito para R1. Parte de la información es similar a la que se encuentra en el show mpls lsp comando. Sin embargo, dado que la protección de vínculos es una función RSVP, se proporciona información acerca de las rutas de desvío. La ruta de derivación aparece como una sesión de entrada RSVP independiente para la interfaz protegida, como lo indica el Type campo.
El nombre de la ruta de derivación se genera automáticamente. De forma predeterminada, el nombre aparece como Bypass > interface-address, donde la dirección de la interfaz es la siguiente interfaz del enrutador descendente (10.0.12.14). La ruta 10.0.17.14 10.0.27.1 explícita de la sesión se muestra R7 como el nodo de tránsito y R2 como el nodo de salida.
Dentro de la sección RSVP de entrada de la salida, el LSP que se origina en R1 (lsp2-r1-to-r5) se muestra solicitando protección de vínculo. Dado que existe una ruta de derivación para proteger el vínculo descendente, lsp2-r1-to-r5 se asocia con la derivación, como lo indica el Link protected LSP campo.
La sección de salida de la salida muestra el LSP r5-to-r1de retorno, que no está protegido.
La sección de tránsito de la salida muestra la protección del vínculo solicitada por lsp1-r6-to-r0. Dado que existe una ruta de derivación para proteger el vínculo descendente, lsp1-r6-to-r0 está asociada al bypass, como lo indica el Link protected LSP campo. También se incluye en la sección de tránsito de la salida el retorno LSP r0-to-r6, que no está protegido.
Salida de muestra
user@R1> show rsvp interface
RSVP interface: 4 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
fe-0/1/0.0 Up 2 100% 100Mbps 100Mbps 0bps 35Mbps
fe-0/1/1.0 Up 1 100% 100Mbps 100Mbps 0bps 0bps
fe-0/1/2.0 Up 0 100% 100Mbps 100Mbps 0bps 0bps
so-0/0/3.0 Up 1 100% 155.52Mbps 155.52Mbps 0bps 0bps
Significado
La salida de ejemplo del enrutador R1 de entrada muestra el número de LSP que pasan por las interfaces configuradas en R1. El Active resv campo muestra el número de LSP para cada interfaz. Por ejemplo, interfaz fe-0/1/0.0 entre R1 y R2 tiene dos reservas activas, lsp1-r6-to-r0 y lsp2-r1-to-r5; interfaz fe-0/1/1.0 entre R1 y R7 tiene una, el bypass (10.0.12.14); interfaz fe-0/1/2.0 entre R6 y R1 no tiene reservas LSP; e interfaz so-0/0/3.0 entre R6 y R1 tiene una reserva LSP, lsp1-r6-to-r0.
Verificar copia de seguridad individual
Propósito
Para comprobar que se ha establecido una copia de seguridad individual, examine el enrutador de entrada y los demás enrutadores de la red.
Acción
Para verificar la copia de seguridad uno a uno, ingrese los siguientes comandos del modo operativo de la CLI de Junos OS:
user@host> show mpls lsp ingress extensive user@host> show rsvp session
Salida de muestra
nombre-comando
La siguiente salida de ejemplo proviene del enrutador R1 de entrada:
user@R1> show mpls lsp ingress extensive
Ingress LSP: 1 sessions
192.168.5.1
From: 192.168.1.1, State: Up, ActiveRoute: 0, LSPname: r1-to-r5
ActivePath: via-r2 (primary)
FastReroute desired
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary via-r2 State: Up
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
10.0.12.14 S 10.0.24.2 S 10.0.45.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.0.12.14(flag=9) 10.0.24.2(flag=1) 10.0.45.2
8 May 11 14:51:46 Fast-reroute Detour Up
7 May 11 14:50:55 Record Route: 10.0.12.14(flag=9) 10.0.24.2(flag=1) 10.0.45.2
6 May 11 14:50:55 Record Route: 10.0.12.14(flag=9) 10.0.24.2 10.0.45.2
5 May 11 14:50:52 Selected as active path
4 May 11 14:50:52 Record Route: 10.0.12.14 10.0.24.2 10.0.45.2
3 May 11 14:50:52 Up
2 May 11 14:50:52 Originate Call
1 May 11 14:50:52 CSPF: computation result accepted
Created: Thu May 11 14:50:52 2006
Total 1 displayed, Up 1, Down 0
Significado
La salida de ejemplo muestra que el FastReroute desired objeto se incluyó en los mensajes de ruta para el LSP, lo que permite R1 seleccionar la ruta activa para el LSP y establecer una ruta de R1 desvío para evitar R2.
En la línea 8, Fast-reroute Detour Up muestra que el desvío está operativo. Las líneas 6 y 7 indican que transitan enrutadores y R4 han establecido sus rutas de R2 desvío.
R2, 10.0.12.14, incluye (flag=9), que indica que la protección del nodo está disponible para el nodo descendente y el vínculo. R4, 10.0.24.2incluye , indica (flag=1)que la protección del vínculo está disponible para el siguiente vínculo descendente. En este caso, R4 sólo se puede proteger el vínculo descendente porque el nodo es el enrutador R5de salida, que no se puede proteger. Para obtener más información acerca de los indicadores, consulte el Manual del usuario de Junos.
El resultado del show mpls lsp extensive comando no muestra la ruta real del desvío. Para ver los vínculos reales utilizados por las rutas de desvío, debe usar el show rsvp session ingress detail comando.
- Salida de muestra
- Significado
- Salida de muestra
- Significado
- Salida de muestra
- Significado
- Salida de muestra
- Significado
- Salida de muestra
- Significado
- Salida de muestra
- Significado
Salida de muestra
El siguiente resultado de ejemplo procede del enrutador R1 de entrada en la red que se muestra en Desvíos de copia de seguridad uno a uno.
user@R1> show rsvp session ingress detail
Ingress RSVP: 1 sessions
192.168.5.1
From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0
LSPname: r1-to-r5, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 100848
Resv style: 1 FF, Label in: -, Label out: 100848
Time left: -, Since: Thu May 11 14:17:15 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 9228 protocol 0
FastReroute desired
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 10.0.12.14 (fe-0/1/0.0) 35 pkts
RESV rcvfrom: 10.0.12.14 (fe-0/1/0.0) 25 pkts
Explct route: 10.0.12.14 10.0.24.2 10.0.45.2
Record route: <self> 10.0.12.14 10.0.24.2 10.0.45.2
Detour is Up
Detour Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Detour adspec: sent MTU 1500
Path MTU: received 1500
Detour PATH sentto: 10.0.17.14 (fe-0/1/1.0) 23 pkts
Detour RESV rcvfrom: 10.0.17.14 (fe-0/1/1.0) 20 pkts
Detour Explct route: 10.0.17.14 10.0.79.2 10.0.59.1
Detour Record route: <self> 10.0.17.14 10.0.79.2 10.0.59.1
Detour Label out: 100848
Total 1 displayed, Up 1, Down 0
Significado
La salida de ejemplo de R1 muestra la sesión RSVP del LSP principal. Se establece la ruta de desvío, Detour is Up. La ruta física del desvío se muestra en Detour Explct route. La ruta de desvío utiliza R7 y R9 como enrutadores de tránsito para llegar a R5, el enrutador de salida.
Salida de muestra
El siguiente resultado de ejemplo procede del primer enrutador de tránsito R2 de la red que se muestra en Desvíos de copia de seguridad uno a uno:
user@R2> show rsvp session transit detail
Transit RSVP: 1 sessions
192.168.5.1
From: 192.168.1.1, LSPstate: Up, ActiveRoute: 1
LSPname: r1-to-r5, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 100448
Resv style: 1 FF, Label in: 100720, Label out: 100448
Time left: 126, Since: Wed May 10 16:12:21 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 5 receiver 9216 protocol 0
FastReroute desired
PATH rcvfrom: 10.0.12.13 (fe-0/1/0.0) 173 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.0.24.2 (so-0/0/1.0) 171 pkts
RESV rcvfrom: 10.0.24.2 (so-0/0/1.0) 169 pkts
Explct route: 10.0.24.2 10.0.45.2
Record route: 10.0.12.13 <self> 10.0.24.2 10.0.45.2
Detour is Up
Detour Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Detour adspec: received MTU 1500 sent MTU 1500
Path MTU: received 1500
Detour PATH sentto: 10.0.27.2 (so-0/0/3.0) 169 pkts
Detour RESV rcvfrom: 10.0.27.2 (so-0/0/3.0) 167 pkts
Detour Explct route: 10.0.27.2 10.0.79.2 10.0.59.1
Detour Record route: 10.0.12.13 <self> 10.0.27.2 10.0.79.2 10.0.59.1
Detour Label out: 100736
Total 1 displayed, Up 1, Down 0
Significado
El resultado de ejemplo de R2 muestra que el desvío está establecido (Detour is Up) y evita R4, y el vínculo que conecta R4 y R5 (10.0.45.2). La ruta de desvío es a través R7 de (10.0.27.2) y R9 (10.0.79.2) a R5 (10.0.59.1), que es diferente de la ruta explícita para el desvío de . R1 tiene el desvío que R1pasa a través del 10.0.17.14 vínculo en R7, mientras R1 se utiliza el 10.0.27.2 vínculo. Ambos desvíos se fusionan en R9 a través del 10.0.79.2 enlace a R5 (10.0.59.1).
Salida de muestra
El siguiente resultado de ejemplo procede del segundo enrutador de tránsito R4 de la red que se muestra en Desvíos de copia de seguridad uno a uno:
user@R4> show rsvp session transit detail
Transit RSVP: 1 sessions
192.168.5.1
From: 192.168.1.1, LSPstate: Up, ActiveRoute: 1
LSPname: r1-to-r5, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 3
Resv style: 1 FF, Label in: 100448, Label out: 3
Time left: 155, Since: Wed May 10 16:15:38 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 5 receiver 9216 protocol 0
FastReroute desired
PATH rcvfrom: 10.0.24.1 (so-0/0/1.0) 178 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.0.45.2 (so-0/0/2.0) 178 pkts
RESV rcvfrom: 10.0.45.2 (so-0/0/2.0) 175 pkts
Explct route: 10.0.45.2
Record route: 10.0.12.13 10.0.24.1 <self> 10.0.45.2
Detour is Up
Detour Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Detour adspec: received MTU 1500 sent MTU 1500
Path MTU: received 1500
Detour PATH sentto: 10.0.49.2 (so-0/0/3.0) 176 pkts
Detour RESV rcvfrom: 10.0.49.2 (so-0/0/3.0) 175 pkts
Detour Explct route: 10.0.49.2 10.0.59.1
Detour Record route: 10.0.12.13 10.0.24.1 <self> 10.0.49.2 10.0.59.1
Detour Label out: 100352
Total 1 displayed, Up 1, Down 0
Significado
La salida de ejemplo de R4 muestra que el desvío se ha establecido (Detour is Up) y evita el vínculo que conecta R4 y R5 (10.0.45.2). La ruta de desvío es a través de R9 (10.0.49.2) a R5 (10.0.59.1). Parte de la información es similar a la que se encuentra en la salida para R1 y R2. Sin embargo, la ruta explícita para el desvío es diferente, pasando por el enlace que conecta R4 y R9 (so-0/0/3 o 10.0.49.2.
Salida de muestra
El siguiente resultado de ejemplo es de , que se utiliza en la ruta de R7desvío en la red que se muestra en Desvíos de copia de seguridad uno a uno:
user@R7> show rsvp session transit detail
Transit RSVP: 1 sessions, 1 detours
192.168.5.1
From: 192.168.1.1, LSPstate: Up, ActiveRoute: 1
LSPname: r1-to-r5, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 100368
Resv style: 1 FF, Label in: 100736, Label out: 100368
Time left: 135, Since: Wed May 10 16:14:42 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 5 receiver 9216 protocol 0
Detour branch from 10.0.27.1, to skip 192.168.4.1, Up
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Adspec: received MTU 1500
Path MTU: received 0
PATH rcvfrom: 10.0.27.1 (so-0/0/3.0) 179 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.0.79.2 (so-0/0/1.0) 177 pkts
RESV rcvfrom: 10.0.79.2 (so-0/0/1.0) 179 pkts
Explct route: 10.0.79.2 10.0.59.1
Record route: 10.0.12.13 10.0.27.1 <self> 10.0.79.2 10.0.59.1
Label in: 100736, Label out: 100368
Detour branch from 10.0.17.13, to skip 192.168.2.1, Up
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Adspec: received MTU 1500
Path MTU: received 0
PATH rcvfrom: 10.0.17.13 (fe-0/1/1.0) 179 pkts
Adspec: received MTU 1500
PATH sentto: 10.0.79.2 (so-0/0/1.0) 0 pkts
RESV rcvfrom: 10.0.79.2 (so-0/0/1.0) 0 pkts
Explct route: 10.0.79.2 10.0.59.1
Record route: 10.0.17.13 <self> 10.0.79.2 10.0.59.1
Label in: 100752, Label out: 100368
Total 1 displayed, Up 1, Down 0
Significado
La salida de ejemplo muestra la misma información que R7 para un enrutador de tránsito regular utilizado en la ruta principal del LSP: la dirección de entrada (192.168.1.1), la dirección de salida (192.168.5.1 ) y el nombre del LSP (r1-to-r5). Se muestran dos rutas de desvío; el primero para evitar R4 (192.168.4.1) y el segundo para evitar R2 (192.168.2.1). Dado que R7 es utilizado como enrutador de tránsito por R2 y R4, R7 puede combinar las rutas de desvío según lo indicado por el valor idéntico Label out (100368) para ambas rutas de desvío. Si R7 recibe tráfico de R4 con un valor de etiqueta de 100736 o de R2 con un valor de etiqueta de 100752, R7 reenvía el paquete a R5 con un valor de etiqueta de 100368.
Salida de muestra
El siguiente resultado de ejemplo es de R9, que es un enrutador que se usa en la ruta de desvío en la red que se muestra en Desvíos de copia de seguridad uno a uno:
user@R9> show rsvp session transit detail
Transit RSVP: 1 sessions, 1 detours
192.168.5.1
From: 192.168.1.1, LSPstate: Up, ActiveRoute: 1
LSPname: r1-to-r5, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 3
Resv style: 1 FF, Label in: 100352, Label out: 3
Time left: 141, Since: Wed May 10 16:16:40 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 5 receiver 9216 protocol 0
Detour branch from 10.0.49.1, to skip 192.168.5.1, Up
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Adspec: received MTU 1500
Path MTU: received 0
PATH rcvfrom: 10.0.49.1 (so-0/0/3.0) 183 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.0.59.1 (so-0/0/0.0) 182 pkts
RESV rcvfrom: 10.0.59.1 (so-0/0/0.0) 183 pkts
Explct route: 10.0.59.1
Record route: 10.0.12.13 10.0.24.1 10.0.49.1 <self> 10.0.59.1
Label in: 100352, Label out: 3
Detour branch from 10.0.27.1, to skip 192.168.4.1, Up
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Adspec: received MTU 1500
Path MTU: received 0
Detour branch from 10.0.17.13, to skip 192.168.2.1, Up
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Adspec: received MTU 1500
Path MTU: received 0
PATH rcvfrom: 10.0.79.1 (so-0/0/1.0) 181 pkts
Adspec: received MTU 1500
PATH sentto: 10.0.59.1 (so-0/0/0.0) 0 pkts
RESV rcvfrom: 10.0.59.1 (so-0/0/0.0) 0 pkts
Explct route: 10.0.59.1
Record route: 10.0.12.13 10.0.27.1 10.0.79.1 <self> 10.0.59.1
Label in: 100368, Label out: 3
Total 1 displayed, Up 1, Down 0
Significado
El resultado de ejemplo de R9 muestra que R9 es el penúltimo enrutador para la ruta de desvío, la ruta explícita incluye sólo la dirección de vínculo de salida (10.0.59.1), y el Label out valor (3) indica que R9 se ha realizado la ventana emergente de la etiqueta del penúltimo salto. Además, la bifurcación de desvío de no incluye información R7 de ruta porque 10.0.27.1 ha fusionado las rutas de desvío de R2 y R4. Observe que el Label out valor en la rama de desvío de 10.0.17.13 es 100368, el mismo valor que el Label out valor en R7.
Salida de muestra
El siguiente resultado de ejemplo proviene del enrutador de salida R5 en la red que se muestra en Desvíos de copia de seguridad uno a uno:
user@R5> show rsvp session egress detail
Egress RSVP: 1 sessions, 1 detours
192.168.5.1
From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0
LSPname: r1-to-r5, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 119, Since: Thu May 11 14:44:31 2006
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 9230 protocol 0
FastReroute desired
PATH rcvfrom: 10.0.45.1 (so-0/0/2.0) 258 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.0.12.13 10.0.24.1 10.0.45.1 <self>
Detour branch from 10.0.49.1, to skip 192.168.5.1, Up
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Adspec: received MTU 1500
Path MTU: received 0
Detour branch from 10.0.27.1, to skip 192.168.4.1, Up
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Adspec: received MTU 1500
Path MTU: received 0
Detour branch from 10.0.17.13, to skip 192.168.2.1, Up
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Adspec: received MTU 1500
Path MTU: received 0
PATH rcvfrom: 10.0.59.2 (so-0/0/0.0) 254 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.0.12.13 10.0.24.1 10.0.49.1 10.0.59.2 <self>
Label in: 3, Label out: -
Total 1 displayed, Up 1, Down 0
Significado
La salida de muestra muestra el LSP principal en el Record route campo y los desvíos a través de R5 la red.
Comprobar que la ruta principal está operativa
Propósito
Las rutas principales siempre deben usarse en la red si están disponibles; por lo tanto, un LSP siempre se mueve de nuevo a la ruta principal después de un error, a menos que se ajuste la configuración. Para obtener más información sobre cómo ajustar la configuración para evitar que se restablezca una ruta principal con errores, consulte Impedir el uso de una ruta de acceso que anteriormente falló.
Acción
Para comprobar que la ruta principal está operativa, escriba los siguientes comandos del modo operativo de la interfaz de línea de comandos (CLI) de Junos OS:
user@host> show mpls lsp extensive ingress user@host> show rsvp interface
Ejemplo de salida 1
nombre-comando
user@R1> show mpls lsp extensive ingress
Ingress LSP: 1 sessions
192.168.5.1
From: 192.168.1.1, State: Up, ActiveRoute: 0, LSPname: r1-to-r5
ActivePath: via-r2 (primary)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary via-r2 State: Up
Priorities: 6 6
Bandwidth: 35Mbps
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 11)
10.0.12.14 S 10.0.24.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.0.12.14 10.0.24.2
5 Apr 29 14:40:43 Selected as active path
4 Apr 29 14:40:43 Record Route: 10.0.12.14 10.0.24.2
3 Apr 29 14:40:43 Up
2 Apr 29 14:40:43 Originate Call
1 Apr 29 14:40:43 CSPF: computation result accepted
Standby via-r7 State: Dn
SmartOptimizeTimer: 180
No computed ERO.
Created: Sat Apr 29 14:40:43 2006
Total 1 displayed, Up 1, Down 0
Ejemplo de salida 2
nombre-comando
user@R1> show rsvp interface
RSVP interface: 3 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
fe-0/1/0.0 Up 2 100% 100Mbps 100Mbps 0bps 0bps
fe-0/1/1.0 Up 1 100% 100Mbps 100Mbps 0bps 0bps
so-0/0/3.0 Up 1 100% 155.52Mbps 155.52Mbps 0bps 0bps
Significado
La salida de ejemplo 1 muestra que el LSP está operativo y está utilizando la ruta principal (via-r2) con R2 (10.0.12.14) y R4 (10.0.24.2) como enrutadores de tránsito. Los valores de prioridad son los mismos para la configuración y la retención, 6 6. La prioridad 0 es la prioridad más alta (mejor) y 7 es la prioridad más baja (peor). El valor predeterminado de Junos OS para la configuración y la prioridad de espera es 7:0. A menos que algunos LSP sean más importantes que otros, preservar el valor predeterminado es una buena práctica. No se permite configurar una prioridad de configuración que sea mejor que la prioridad de retención, lo que da como resultado una confirmación fallida para evitar bucles de preferencia.
Comprobar que la ruta secundaria está establecida
Propósito
Cuando la ruta secundaria se configura con la standby instrucción, la ruta secundaria debe estar activa pero no activa; se activará si se produce un error en la ruta principal. Una ruta secundaria configurada sin la standby instrucción no aparecerá a menos que se produzca un error en la ruta principal. Para comprobar que la ruta secundaria está configurada correctamente y que surgiría si se produjera un error en la ruta principal, debe desactivar un vínculo o nodo crítico para la ruta principal y, a continuación, emitir el show mpls lsp lsp-path-name extensive comando.
Acción
Para comprobar que la ruta secundaria está establecida, escriba el siguiente comando del modo operativo de la CLI de Junos OS:
Salida de muestra
user@R1> show mpls lsp extensive
Salida de muestra
nombre-comando
La siguiente salida de ejemplo muestra una ruta secundaria configurada correctamente antes y después de que aparezca. En el ejemplo, la interfaz fe-0/1/0 activada R2 está desactivada, lo que muestra la ruta via-r2principal. El enrutador R1 de entrada cambia el tráfico a la ruta via-r7secundaria.
user@R1> show mpls lsp extensive
Ingress LSP: 1 sessions
192.168.5.1
From: 192.168.1.1, State: Up, ActiveRoute: 0, LSPname: r1-to-r5
ActivePath: via-r2 (primary)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary via-r2 State: Up
Priorities: 6 6
Bandwidth: 35Mbps
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
10.0.12.14 S 10.0.24.2 S 10.0.45.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.0.12.14 10.0.24.2 10.0.45.2
5 Apr 29 14:40:43 Selected as active path
4 Apr 29 14:40:43 Record Route: 10.0.12.14 10.0.24.2
3 Apr 29 14:40:43 Up
2 Apr 29 14:40:43 Originate Call
1 Apr 29 14:40:43 CSPF: computation result accepted
Secondary via-r7 State: Dn
SmartOptimizeTimer: 180
No computed ERO.
Created: Sat Apr 29 14:40:43 2006
Total 1 displayed, Up 1, Down 0
[edit interfaces]
user@R2# deactivate fe-0/1/0
[edit interfaces]
user@R2# show
inactive: fe-0/1/0 {
unit 0 {
family inet {
address 10.0.12.14/30;
}
family iso;
family mpls;
}
}
user@R1> show mpls lsp name r1-to-r4 extensive
Ingress LSP: 1 sessions
192.168.4.1
From: 192.168.1.1, State: Up, ActiveRoute: 0, LSPname: r1-to-r4
ActivePath: via-r7 (secondary)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
Primary via-r2 State: Dn
Priorities: 6 6
Bandwidth: 35Mbps
SmartOptimizeTimer: 180
Will be enqueued for recomputation in 14 second(s).
10 Apr 29 14:52:33 CSPF failed: no route toward 10.0.12.1 4[21 times]
9 Apr 29 14:42:48 Clear Call
8 Apr 29 14:42:48 Deselected as active
7 Apr 29 14:42:48 Session preempted
6 Apr 29 14:42:48 Down
5 Apr 29 14:40:43 Selected as active path
4 Apr 29 14:40:43 Record Route: 10.0.12.14 10.0.24.2
3 Apr 29 14:40:43 Up
2 Apr 29 14:40:43 Originate Call
1 Apr 29 14:40:43 CSPF: computation result accepted
*Standby via-r7 State: Up
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 11)
10.0.17.14 S 10.0.47.1 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.0.17.14 10.0.47.1
5 Apr 29 14:42:48 Selected as active path
4 Apr 29 14:41:12 Record Route: 10.0.17.14 10.0.47.1
3 Apr 29 14:41:12 Up
2 Apr 29 14:41:12 Originate Call
1 Apr 29 14:41:12 CSPF: computation result accepted
Created: Sat Apr 29 14:40:43 2006
Total 1 displayed, Up 1, Down 0
Significado
La salida de ejemplo del enrutador R1 de salida muestra una ruta secundaria en espera configurada correctamente en estado inactivo porque la ruta principal sigue activa. Tras la desactivación de una interfaz (interface fe-0/1/0 on R2) crítica para la ruta principal, la ruta via-r2 principal disminuye y aparece la ruta via-r7 secundaria en espera, lo que permite R1 cambiar el tráfico a la ruta secundaria en espera.
Verificación de la capa física
Propósito
Después de configurar el LSP, emitir el show mpls lsp extensive comando y determinar que hay un error, puede comenzar a investigar el problema en la capa física de la red.
Figura 3 ilustra la capa física del modelo MPLS en capas.
Con esta capa, debe asegurarse de que los enrutadores estén conectados y de que las interfaces estén activas y configuradas correctamente en los enrutadores de entrada, salida y tránsito.
Si la red no funciona en esta capa, la ruta de conmutación de etiquetas (LSP) no funcionará según lo configurado.
Figura 4 ilustra la red MPLS y el problema descrito en este tema.
La red que se muestra en Figura 4 es una configuración completamente mallada donde cada interfaz conectada directamente puede recibir y enviar paquetes a cualquier otra interfaz similar. El LSP de esta red está configurado para ejecutarse desde el enrutador R1de entrada, pasando por el enrutador R3de tránsito, hasta el enrutador R6de salida. Además, un LSP inverso está configurado para ejecutarse desde R6 hasta R1R3 , creando tráfico bidireccional.
Sin embargo, en este ejemplo, el tráfico no utiliza el LSP configurado. En su lugar, el tráfico utiliza la ruta alternativa de R1 hasta , y R6en la dirección inversa, de a través R5 to R1de R6R2 .
Cuando tenga conocimiento de una situación en la que se utiliza una ruta alternativa en lugar del LSP configurado, compruebe que la capa física funciona correctamente. Es posible que los enrutadores no estén conectados o que las interfaces no estén activas y configuradas correctamente en los enrutadores de entrada, salida o tránsito.
La cruz que se muestra en Figura 4 indica dónde se rompe el LSP debido a un error de configuración en el enrutador R1de entrada.
Para comprobar la capa física, siga estos pasos:
- Comprobar el LSP
- Verificar la conexión del enrutador
- Verificar interfaces
- Tome las medidas apropiadas
- Compruebe de nuevo el LSP
Comprobar el LSP
Propósito
Normalmente, se utiliza el show mpls lsp extensive comando para comprobar el LSP. Sin embargo, para una comprobación rápida del estado de LSP, utilice el show mpls lsp comando. Si el LSP no funciona, utilice la extensive opción (show mpls lsp extensive) como seguimiento. Si su red tiene numerosos LSP, podría considerar especificar el nombre del LSP, usando la name opción (show mpls lsp name name o show mpls lsp name name extensive).
Acción
Para determinar si el LSP está activo, escriba el siguiente comando desde el enrutador de entrada:
user@ingress-router> show mpls lsp extensive
Salida de muestra
nombre-comando
user@R1> show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.6
From: 10.0.0.1, State: Up, ActiveRoute: 1, LSPname: R1-to-R6
ActivePath: (primary)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20)
10.1.12.2 S 10.1.26.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.1.12.2 10.1.26.2
99 Sep 18 14:19:04 CSPF: computation result accepted
98 Sep 18 14:19:04 CSPF: link down/deleted
10.1.13.1(R1.00/10.0.0.1)->10.1.13.2(R3.00/10.0.0.3)
97 Sep 18 14:19:01 Record Route: 10.1.12.2 10.1.26.2
96 Sep 18 14:19:01 Up
95 Sep 18 14:19:01 Clear Call
94 Sep 18 14:19:01 CSPF: computation result accepted
93 Sep 18 14:19:01 MPLS label allocation failure
92 Sep 18 14:19:01 Down
91 Aug 17 12:22:52 Selected as active path
90 Aug 17 12:22:52 Record Route: 10.1.13.2 10.1.36.2
89 Aug 17 12:22:52 Up
[...Output truncated...]
Created: Sat Jul 10 18:18:44 2004
Total 1 displayed, Up 1, Down 0
Egress LSP: 1 sessions
10.0.0.1
From: 10.0.0.6, LSPstate: Up, ActiveRoute: 0
LSPname: R6-to-R1, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 144, Since: Tue Aug 17 12:23:14 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 39024 protocol 0
PATH rcvfrom: 10.1.15.2 (so-0/0/1.0) 67333 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.1.56.2 10.1.15.2 <self>
Total 1 displayed, Up 1, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Significado
La salida de ejemplo del enrutador R1 de entrada muestra que el LSP está utilizando una ruta alternativa en lugar de la ruta configurada. La ruta configurada para el LSP es R1 a través R6, R3 de y para el LSP inverso, R6 a través de R3R1. La ruta alternativa utilizada por el LSP es R1 a través de R2 y para el LSP inverso,a R6 t través de R5 R1.R6,
Verificar la conexión del enrutador
Propósito
Confirme que los enrutadores de entrada, tránsito y salida adecuados están funcionando examinando si los paquetes se recibieron y transmitieron con una pérdida de paquetes del 0%.
Acción
Para determinar que los enrutadores están conectados, escriba el siguiente comando desde los enrutadores de entrada y tránsito:
user@host> ping host
Salida de muestra
nombre-comando
user@R1> ping 10.0.0.3 count 3 PING 10.0.0.3 (10.0.0.3): 56 data bytes 64 bytes from 10.0.0.3: icmp_seq=0 ttl=254 time=0.859 ms 64 bytes from 10.0.0.3: icmp_seq=1 ttl=254 time=0.746 ms 64 bytes from 10.0.0.3: icmp_seq=2 ttl=254 time=0.776 ms --- 10.0.0.3 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.746/0.794/0.859/0.048 ms user@R3> ping 10.0.0.6 count 3 PING 10.0.0.6 (10.0.0.6): 56 data bytes 64 bytes from 10.0.0.6: icmp_seq=0 ttl=255 time=0.968 ms 64 bytes from 10.0.0.6: icmp_seq=1 ttl=255 time=3.221 ms 64 bytes from 10.0.0.6: icmp_seq=2 ttl=255 time=0.749 ms --- 10.0.0.6 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.749/1.646/3.221/1.117 ms
Significado
El resultado de ejemplo muestra que el enrutador R1 de entrada está recibiendo paquetes del enrutador R3de tránsito y que el enrutador de tránsito está recibiendo paquetes del enrutador de salida. Por lo tanto, los enrutadores del LSP están conectados.
Verificar interfaces
Propósito
Confirme que las interfaces están configuradas correctamente con la family mpls instrucción.
Acción
Para determinar que las interfaces relevantes están correctamente activas y configuradas, escriba los siguientes comandos desde los enrutadores de entrada, tránsito y salida:
user@host> show interfaces terse
user@host> show configuration interfaces type-fpc/pic/port
Salida de muestra
nombre-comando
user@R1> show interfaces so* terse
Interface Admin Link Proto Local Remote
so-0/0/0 up up
so-0/0/0.0 up up inet 10.1.12.1/30
iso
mpls
so-0/0/1 up up
so-0/0/1.0 up up inet 10.1.15.1/30
iso
mpls
so-0/0/2 up up
so-0/0/2.0 up up inet 10.1.13.1/30
iso <<< family mpls is missing
so-0/0/3 up down
user@R1> show configuration interfaces so-0/0/2
unit 0 {
family inet {
address 10.1.13.1/30;
}
family iso; <<< family mpls is missing
}
Significado
El resultado de ejemplo muestra que la interfaz so-0/0/2.0 en el enrutador de entrada no tiene la family mpls instrucción configurada en el nivel de jerarquía [edit interfaces type-fpc/pic/port], lo que indica que la interfaz está configurada incorrectamente para admitir el LSP. El LSP está configurado correctamente en el nivel de jerarquía [edit protocols mpls].
La salida de los enrutadores de tránsito y salida (no se muestra) muestra que las interfaces de esos enrutadores están configuradas correctamente.
Tome las medidas apropiadas
Problema
Description
En función del error que haya encontrado en la investigación, debe tomar las medidas adecuadas para corregir el problema. En el ejemplo siguiente, la family mpls instrucción, que faltaba, se incluye en la configuración del enrutador R1de entrada.
Solución
Para corregir el error de este ejemplo, escriba los siguientes comandos:
[edit interfaces type-fpc/pic/port]
user@R1# set family mpls
user@R1# show
user@R1# commit
Salida de muestra
[edit interfaces so-0/0/2 unit 0]
user@R1# set family mpls
[edit interfaces so-0/0/2 unit 0]
user@R1# show
family inet {
address 10.1.13.1/30;
}
family iso;
family mpls;
[edit interfaces so-0/0/2 unit 0]
user@R1# commit
commit complete
Significado
La salida de ejemplo del enrutador R1 de entrada muestra que la instrucción está configurada correctamente para la family mpls interfaz so-0/0/2.0y que el LSP ahora funciona como se configuró originalmente.
Compruebe de nuevo el LSP
Propósito
Después de tomar las medidas adecuadas para corregir el error, es necesario comprobar de nuevo el LSP para confirmar que se ha resuelto el problema en la capa física.
Acción
Para comprobar que el LSP está activo y atravesando la red como se esperaba, escriba el siguiente comando:
user@host> show mpls lsp extensive
Ejemplo de salida 1
nombre-comando
user@R1> show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.6
From: 10.0.0.1, State: Up, ActiveRoute: 1, LSPname: R1-to-R6
ActivePath: (primary)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20)
10.1.13.2 S 10.1.36.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.1.13.2 10.1.36.2
112 Sep 21 16:27:33 Record Route: 10.1.13.2 10.1.36.2
111 Sep 21 16:27:33 Up
110 Sep 21 16:27:33 CSPF: computation result accepted
109 Sep 21 16:27:33 CSPF: link down/deleted 10.1.12.1(R1.00/10.0.0.1)->10.1.12.2(R2.00/10.0.0.2)
108 Sep 21 16:27:33 CSPF: link down/deleted 10.1.15.1(R1.00/10.0.0.1)->10.1.15.2(R5.00/10.0.0.5)
[Output truncated...]
Created: Sat Jul 10 18:18:44 2004
Total 1 displayed, Up 1, Down 0
Egress LSP: 1 sessions
10.0.0.1
From: 10.0.0.6, LSPstate: Up, ActiveRoute: 0
LSPname: R6-to-R1, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 149, Since: Tue Sep 21 16:29:43 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 2 receiver 39024 protocol 0
PATH rcvfrom: 10.1.13.2 (so-0/0/2.0) 7 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.1.36.2 10.1.13.2 <self>
Total 1 displayed, Up 1, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Ejemplo de salida 2
nombre-comando
[edit protocols mpls]
user@R1# show
label-switched-path R1-to-R6 {
to 10.0.0.6;
}
interface fxp0.0 {
disable;
}
inactive: interface so-0/0/0.0;
inactive: interface so-0/0/1.0;
interface so-0/0/2.0;
Significado
La salida de muestra 1 del enrutador R1 de entrada muestra que el LSP ahora está atravesando la red a lo largo de la ruta esperada, desde R1 hasta R3 R6, y el LSP inverso, desde R6 hasta R3R1.
La salida de ejemplo 2 del enrutador R1 de entrada muestra que el LSP se ve obligado a tomar la ruta deseada porque MPLS está desactivado en R1 las interfaces so-0/0/0.0 y so-0/0/1.0. Si estas interfaces no se desactivaran, aunque la configuración ahora sea correcta, el LSP seguiría atravesando la red a través de la ruta alternativa.
Comprobación de la capa de vínculo de datos
Propósito
Después de configurar la ruta de conmutación de etiquetas (LSP), emitir el show mpls lsp extensive comando y determinar que hay un error, es posible que el error no esté en la capa física. Continúe investigando el problema en la capa de vínculo de datos de la red.
Figura 5 muestra la capa de vínculo de datos del modelo MPLS en capas.
Con esta capa, debe verificar el modo de encapsulación, por ejemplo, Protocolo punto a punto (PPP) o Control de enlace de datos de alto nivel (HDLC) de Cisco; Opciones de PPP, por ejemplo, encapsulación de encabezado; tamaño de la secuencia de verificación de fotogramas (FCS); y si los marcos keepalive están habilitados o deshabilitados. Además, compruebe los enrutadores de entrada, salida y tránsito.
Figura 6 ilustra la red MPLS utilizada en este tema.
La red que se muestra en Figura 6 es una configuración completamente mallada donde cada interfaz conectada directamente puede recibir y enviar paquetes a cualquier otra interfaz similar. El LSP de esta red está configurado para ejecutarse desde el enrutador R1de entrada, pasando por el enrutador R3de tránsito, hasta el enrutador R6de salida. Además, un LSP inverso está configurado para ejecutarse desde R6 hasta R1R3 , creando tráfico bidireccional.
Sin embargo, en este ejemplo, el LSP está inactivo sin una ruta en ninguna dirección, de R1 a R6 o de R6 a R1.
Cuando compruebe que la capa de vínculo de datos no funciona correctamente, es posible que encuentre una discrepancia con la encapsulación PPP o Cisco HDLC, las opciones PPP o las tramas keepalive.
La cruz que se muestra en Figura 6 indica dónde se rompe el LSP debido a un error de configuración en el enrutador R1 de entrada que impide que el LSP atraviese la red como se esperaba.
Para comprobar la capa de vínculo de datos, siga estos pasos:
Comprobar el LSP
Propósito
Normalmente, se utiliza el show mpls lsp extensive comando para comprobar el LSP. Sin embargo, para una comprobación rápida del estado de LSP, utilice el show mpls lsp comando. Si el LSP no funciona, utilice la extensive opción (show mpls lsp extensive) como seguimiento. Si su red tiene numerosos LSP, podría considerar especificar el nombre del LSP, usando la name opción (show mpls lsp name name o show mpls lsp name name extensive).
Acción
Para determinar si el LSP está activo, escriba el siguiente comando desde el enrutador de entrada:
user@host> show mpls lsp extensive
Ejemplo de salida 1
nombre-comando
user@R1> show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.6
From: 10.0.0.1 , State: Dn, ActiveRoute: 0, LSPname: R1-to-R6
ActivePath: (none)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
Primary State: Dn
Will be enqueued for recomputation in 15 second(s).
140 Sep 30 12:01:12 CSPF failed: no route toward 10.0.0.6[26 times]
139 Sep 30 11:48:57 Deselected as active
138 Sep 30 11:48:56 CSPF failed: no route toward 10.0.0.6
137 Sep 30 11:48:56 Clear Call
136 Sep 30 11:48:56 CSPF: link down/deleted
10.1.36.1(R3.00/10.0.0.3)->10.1.36.2(R6.00/10.0.0.6)
135 Sep 30 11:48:56 ResvTear received
134 Sep 30 11:48:56 Down
133 Sep 30 11:48:56 CSPF failed: no route toward 10.0.0.6
132 Sep 30 11:48:56 10.1.13.2: No Route toward dest
[...Output truncated...]
Created: Sat Jul 10 18:18:44 2004
Total 1 displayed, Up 0, Down 1
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Significado
La salida de ejemplo del enrutador R1 de entrada muestra los LSP en los que participa. El LSP de entrada está inactivo, sin una ruta de acceso desde a R6. Dado que se configura un LSP inverso en la red que se muestra en MPLS Red rota en la capa de vínculo de datos, esperaríamos que una sesión de R1 LSP de salida estuviera activa. Sin embargo, R1 no tiene ningún LSP de salida, lo que indica que el LSP de R6 a R1 no está funcionando.
Verificar interfaces
Propósito
Desde la topología de red, determine las interfaces adyacentes a través de las cuales el LSP debe atravesar y examine la salida para el tipo de encapsulación, las opciones de PPP, el tamaño de FCS y si las tramas keepalive están habilitadas o deshabilitadas
Antes de continuar con este paso, compruebe la capa física para asegurarse de que el problema no está en la capa física.
Acción
Para verificar el funcionamiento de las interfaces adyacentes, introduzca los siguientes comandos desde los enrutadores correspondientes:
user@host> show interfaces type-fpc/pic/port extensive user@host> show interfaces type-fpc/pic/port
Ejemplo de salida 1
nombre-comando
user@R6> show interfaces so-0/0/3 extensive
Physical interface: so-0/0/3, Enabled, Physical link is Up
Interface index: 131, SNMP ifIndex: 27, Generation: 14
Link-level type: Cisco-HDLC , MTU: 4474, Clocking: Internal, SONET mode, Speed: OC3, Loopback: None,
FCS: 16 , Payload scrambler: Enabled
Device flags : Present Running
Interface flags: Link-Layer-Down Point-To-Point SNMP-Traps 16384
Link flags : Keepalives
Hold-times : Up 0 ms, Down 0 ms
Keepalive settings: Interval 10 seconds, Up-count 1, Down-count 3
Keepalive statistics:
Input : 0 (last seen: never)
Output: 357 (last sent 00:00:04 ago)
CoS queues : 4 supported
Last flapped : 2004-07-21 16:03:49 PDT (10w0d 07:01 ago)
Statistics last cleared: Never
Traffic statistics:
Input bytes : 203368873 0 bps
Output bytes : 186714992 88 bps
Input packets: 3641808 0 pps
Output packets: 3297569 0 pps
Input errors:
Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Giants: 0, Bucket drops: 0,
Policed discards: 1770, L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0,
HS link CRC errors: 0, HS link FIFO overflows: 0
Output errors:
Carrier transitions: 1, Errors: 0, Drops: 0, Aged packets: 0, HS link FIFO underflows: 0,
MTU errors: 0
Queue counters: Queued packets Transmitted packets Dropped packets
0 best-effort 197012 197012 0
1 expedited-fo 0 0 0
2 assured-forw 0 0 0
3 network-cont 3100557 3100557 0
SONET alarms : None
SONET defects : None
SONET PHY: Seconds Count State
PLL Lock 0 0 OK
PHY Light 0 0 OK
SONET section:
BIP-B1 0 0
SEF 1 3 OK
LOS 1 1 OK
LOF 1 1 OK
ES-S 1
SES-S 1
SEFS-S 1
SONET line:
BIP-B2 0 0
REI-L 0 0
RDI-L 0 0 OK
AIS-L 0 0 OK
BERR-SF 0 0 OK
BERR-SD 0 0 OK
ES-L 1
SES-L 1
UAS-L 0
ES-LFE 0
SES-LFE 0
UAS-LFE 0
SONET path:
BIP-B3 0 0
REI-P 0 0
LOP-P 0 0 OK
AIS-P 0 0 OK
RDI-P 0 0 OK
UNEQ-P 0 0 OK
PLM-P 0 0 OK
ES-P 1
SES-P 1
UAS-P 0
ES-PFE 0
SES-PFE 0
UAS-PFE 0
Received SONET overhead:
F1 : 0x00, J0 : 0x00, K1 : 0x00, K2 : 0x00
S1 : 0x00, C2 : 0xcf, C2(cmp) : 0xcf, F2 : 0x00
Z3 : 0x00, Z4 : 0x00, S1(cmp) : 0x00
Transmitted SONET overhead:
F1 : 0x00, J0 : 0x01, K1 : 0x00, K2 : 0x00
S1 : 0x00, C2 : 0xcf, F2 : 0x00, Z3 : 0x00
Z4 : 0x00
Received path trace: R3 so-0/0/3
52 33 20 73 6f 2d 30 2f 30 2f 33 00 00 00 00 00 R3 so-0/0/3.. ...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 0d 0a ................
Transmitted path trace: R6 so-0/0/3
52 36 20 73 6f 2d 30 2f 30 2f 33 00 00 00 00 00 R6 so-0/0/3 .....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
HDLC configuration:
Policing bucket: Disabled
Shaping bucket : Disabled
Giant threshold: 4484, Runt threshold: 3
Packet Forwarding Engine configuration:
Destination slot: 0, PLP byte: 1 (0x00)
CoS transmit queue Bandwidth Buffer Priority Limit
% bps % bytes
0 best-effort 95 147744000 95 0 low none
3 network-control 5 7776000 5 0 low none
Logical interface so-0/0/3.0 (Index 71) (SNMP ifIndex 28) (Generation 16)
Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: Cisco-HDLC
Traffic statistics:
Input bytes : 406737746
Output bytes : 186714992
Input packets: 7283616
Output packets: 3297569
Local statistics:
Input bytes : 203368873
Output bytes : 186714992
Input packets: 3641808
Output packets: 3297569
Transit statistics:
Input bytes : 203368873 0 bps
Output bytes : 0 0 bps
Input packets: 3641808 0 pps
Output packets: 0 0 pps
Protocol inet, MTU: 4470, Generation: 46, Route table: 0
Flags: None
Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
Destination: 10.1.36.0/30, Local: 10.1.36.2, Broadcast: 10.1.36.3, Generation: 38
Protocol iso, MTU: 4469, Generation: 47, Route table: 0
Flags: None
Protocol mpls, MTU: 4458, Generation: 48, Route table: 0
Flags: None
Ejemplo de salida 2
nombre-comando
user@R3> show interfaces so-0/0/3
Physical interface: so-0/0/3, Enabled, Physical link is Up
Interface index: 131, SNMP ifIndex: 24
Link-level type: PPP , MTU: 4474, Clocking: Internal, SONET mode, Speed: OC3, Loopback: None, FCS: 16 ,
Payload scrambler: Enabled
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Link flags : Keepalives
Keepalive settings: Interval 10 seconds, Up-count 1, Down-count 3
Keepalive: Input: 736827 (00:00:03 ago), Output: 736972 (00:00:05 ago)
LCP state: Opened
NCP state: inet: Opened, inet6: Not-configured, iso: Opened, mpls: Opened
CHAP state: Not-configured
CoS queues : 4 supported
Last flapped : 2004-07-21 16:08:01 PDT (10w5d 19:57 ago)
Input rate : 40 bps (0 pps)
Output rate : 48 bps (0 pps)
SONET alarms : None
SONET defects : None
Logical interface so-0/0/3.0 (Index 70) (SNMP ifIndex 51)
Flags: Point-To-Point SNMP-Traps Encapsulation: PPP
Protocol inet, MTU: 4470
Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.1.36.0/30, Local: 10.1.36.1, Broadcast: 10.1.36.3
Protocol iso, MTU: 4470
Flags: None
Protocol mpls, MTU: 4458
Flags: None
Significado
La salida de muestra 1 del enrutador R6 de salida muestra que no hay alarmas ni defectos de SONET (none), los estados son todos OKy el seguimiento de ruta muestra el extremo distante (R3 so-0.0.0), lo que indica que el vínculo físico está activo. Sin embargo, el vínculo lógico está inactivo y el tipo de nivel de vínculo es Cisco HDLC.
La salida de muestra 2 del enrutador R3 de tránsito muestra que el tipo de nivel de vínculo es PPP, lo que indica que los tipos de encapsulación no coinciden, lo que hace que el LSP disminuya.
Tome las medidas apropiadas
Problema
Description
En función del error que haya encontrado en la investigación, debe tomar las medidas adecuadas para corregir el problema. En el ejemplo siguiente, los tipos de encapsulación no coinciden.
Solución
Para corregir el error de este ejemplo, escriba los siguientes comandos:
[edit interfaces so-0/0/3] user@R1# show user@R1# delete encapsulation user@R1# show user@R1# commit
Salida de Sampel
[edit interfaces so-0/0/3]
user@R6# show
encapsulation cisco-hdlc;
unit 0 {
family inet {
address 10.1.36.2/30;
}
family iso;
family mpls;
}
[edit interfaces so-0/0/3]
user@R6# delete encapsulation
[edit interfaces so-0/0/3]
user@R6# show
unit 0 {
family inet {
address 10.1.36.2/30;
}
family iso;
family mpls;
}
[edit interfaces so-0/0/3]
user@R6# commit
commit complete
Significado
La salida de ejemplo del enrutador R6 de salida muestra que Cisco HDLC se configuró incorrectamente en la interfaz so-0/0/3 , lo que impidió que el LSP utilizara la ruta deseada. El problema se corrigió cuando se eliminó la encapsulation instrucción y se confirmó la configuración.
Compruebe de nuevo el LSP
Propósito
Después de tomar las medidas adecuadas para corregir el error, es necesario comprobar de nuevo el LSP para confirmar que se ha resuelto el problema en la capa de vínculo de datos.
Acción
Desde los enrutadores de entrada, salida y tránsito, compruebe que el LSP esté activo y atravesando la red como se esperaba:
user@host> show mpls lsp extensive
Ejemplo de salida 1
nombre-comando
user@R1> show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.6
From: 10.0.0.1 , State: Up, ActiveRoute: 1 , LSPname: R1-to-R6
ActivePath: (primary)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20)
10.1.13.2 S 10.1.36.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.1.13.2 10.1.36.2
145 Sep 30 12:25:01 Selected as active path
144 Sep 30 12:25:01 Record Route: 10.1.13.2 10.1.36.2
143 Sep 30 12:25:01 Up
142 Sep 30 12:25:01 Originate Call
141 Sep 30 12:25:01 CSPF: computation result accepted
140 Sep 30 12:24:32 CSPF failed: no route toward 10.0.0.6[74 times]
139 Sep 30 11:48:57 Deselected as active
138 Sep 30 11:48:56 CSPF failed: no route toward 10.0.0.6
137 Sep 30 11:48:56 Clear Call
136 Sep 30 11:48:56 CSPF: link down/deleted 10.1.36.1(R3.00/10.0.0.3)->10.1.36.2(R6.00/10.0.0.6)
[...Output truncated...]
Created: Sat Jul 10 18:18:43 2004
Total 1 displayed, Up 1 , Down 0
Egress LSP: 1 sessions
10.0.0.1
From: 10.0.0.6 , LSPstate: Up, ActiveRoute: 0
LSPname: R6-to-R1, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 134, Since: Thu Sep 30 12:24:56 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 6 receiver 39024 protocol 0
PATH rcvfrom: 10.1.13.2 (so-0/0/2.0) 7 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.1.36.2 10.1.13.2 <self>
Total 1 displayed, Up 1, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Ejemplo de salida 2
nombre-comando
user@R6> show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.1
From: 10.0.0.6, State: Up, ActiveRoute: 1, LSPname: R6-to-R1
ActivePath: (primary)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20)
10.1.36.1 S 10.1.13.1 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.1.36.1 10.1.13.1
50 Sep 30 12:24:12 Selected as active path
49 Sep 30 12:24:12 Record Route: 10.1.36.1 10.1.13.1
48 Sep 30 12:24:12 Up
47 Sep 30 12:24:12 Originate Call
46 Sep 30 12:24:12 CSPF: computation result accepted
45 Sep 30 12:23:43 CSPF failed: no route toward 10.0.0.1[73 times]
44 Sep 30 11:48:12 Deselected as active
43 Sep 30 11:48:12 CSPF failed: no route toward 10.0.0.1
42 Sep 30 11:48:12 CSPF: link down/deleted 10.1.36.2(R6.00/10.0.0.6)->10.1.36.1(R3.00/10.0.0.3)
[...Output truncated...]
Created: Tue Aug 17 12:18:34 2004
Total 1 displayed, Up 1, Down 0
Egress LSP: 1 sessions
10.0.0.6
From: 10.0.0.1 , LSPstate: Up, ActiveRoute: 0
LSPname: R1-to-R6, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 159, Since: Thu Sep 30 12:24:16 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 19 receiver 44251 protocol 0
PATH rcvfrom: 10.1.36.1 (so-0/0/3.0) 4 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.1.13.1 10.1.36.1 <self>
Total 1 displayed, Up 1, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Ejemplo de salida 3
nombre-comando
user@R3> show mpls lsp extensive Ingress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 2 sessions 10.0.0.1 From: 10.0.0.6 , LSPstate: Up, ActiveRoute: 1 LSPname: R6-to-R1, LSPpath: Primary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 3 Resv style: 1 FF, Label in: 100176, Label out: 3 Time left: 143, Since: Thu Sep 30 12:21:25 2004 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 6 receiver 39024 protocol 0 PATH rcvfrom: 10.1.36.2 (so-0/0/3.0) 10 pkts Adspec: received MTU 1500 sent MTU 1500 PATH sentto: 10.1.13.1 (so-0/0/2.0) 9 pkts RESV rcvfrom: 10.1.13.1 (so-0/0/2.0) 9 pkts Explct route: 10.1.13.1 Record route: 10.1.36.2 <self> 10.1.13.1 10.0.0.6 From: 10.0.0.1 , LSPstate: Up, ActiveRoute: 1 LSPname: R1-to-R6, LSPpath: Primary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 3 Resv style: 1 FF, Label in: 100192, Label out: 3 Time left: 148, Since: Thu Sep 30 12:21:30 2004 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 19 receiver 44251 protocol 0 PATH rcvfrom: 10.1.13.1 (so-0/0/2.0) 9 pkts Adspec: received MTU 1500 sent MTU 1500 PATH sentto: 10.1.36.2 (so-0/0/3.0) 9 pkts RESV rcvfrom: 10.1.36.2 (so-0/0/3.0) 9 pkts Explct route: 10.1.36.2 Record route: 10.1.13.1 <self> 10.1.36.2 Total 2 displayed, Up 2, Down 0
Ejemplo de salida 4
nombre-comando
user@R1> show configuration protocols mpls
label-switched-path R1-to-R6 {
to 10.0.0.6;
}
inactive: interface so-0/0/0.0;
inactive: interface so-0/0/1.0;
interface so-0/0/2.0;
user@R6> show configuration protocols mpls
label-switched-path R6-to-R1 {
to 10.0.0.1;
}
inactive: interface so-0/0/0.0;
inactive: interface so-0/0/1.0;
inactive: interface so-0/0/2.0;
interface so-0/0/3.0;
user@R3> show configuration protocols mpls
interface fxp0.0 {
disable;
}
inactive: interface so-0/0/0.0;
inactive: interface so-0/0/1.0;
interface so-0/0/2.0;
interface so-0/0/3.0;
Significado
Los resultados de muestra 1 y 2 del enrutador R1 de entrada y del enrutador R6, de salida, respectivamente, muestran que el LSP ahora atraviesa la red a lo largo de la ruta esperada, desde R1 hasta R3 R6, y el LSP inverso, desde R6 hasta R3R1.
La salida de ejemplo 3 del enrutador R3 de tránsito muestra que hay dos sesiones LSP de tránsito, una de R1 a R6 y la otra de R6 a .R1
El resultado de ejemplo 4 muestra las interfaces que se desactivaron en los enrutadores de entrada, salida y tránsito, lo que obliga al LSP a tomar la ruta deseada. Si estas interfaces no se desactivaran, aunque la configuración ahora sea correcta, el LSP seguiría atravesando la red a través de la ruta alternativa.
Verificación de las capas IP e IGP
Problema
Description
Después de configurar la ruta de conmutación de etiquetas (LSP), emitir el show mpls lsp extensive comando y determinar que hay un error, es posible que el error no esté en las capas físicas o de vínculo de datos. Continúe investigando el problema en las capas IP e IGP de la red.
Figura 7 ilustra las capas IP e IGP del modelo MPLS en capas.
Solución
En las capas IP e IGP, debe verificar lo siguiente:
Las interfaces tienen el direccionamiento IP correcto, y se establecen los vecinos o adyacencias del IGP.
Los protocolos Open Shortest Path First (OSPF) o Intermediate System-to-Intermediate System (IS-IS) están configurados y se ejecutan correctamente.
Si el protocolo OSPF está configurado, compruebe primero la capa IP y, a continuación, la configuración de OSPF, asegurándose de que el protocolo, las interfaces y la ingeniería de tráfico estén configurados correctamente.
Si el protocolo IS-IS está configurado, no importa si comprueba primero IS-IS o IP, ya que ambos protocolos son independientes entre sí. Compruebe que las adyacencias de IS-IS estén activas y que las interfaces y el protocolo IS-IS estén configurados correctamente.
Nota:El protocolo IS-IS tiene habilitada la ingeniería de tráfico de forma predeterminada.
Si la red no funciona en las capas IP o IGP, el LSP no funciona según lo configurado.
Figura 8 ilustra la red MPLS utilizada en este tema.
La red que se muestra en Figura 8 es una configuración completamente mallada donde cada interfaz conectada directamente puede recibir y enviar paquetes a cualquier otra interfaz similar. El LSP de esta red está configurado para ejecutarse desde el enrutador R1de entrada, pasando por el enrutador R3de tránsito, hasta el enrutador R6de salida. Además, un LSP inverso está configurado para ejecutarse desde R6, pasando por R3, hasta , creando R1tráfico bidireccional. Los cruces en Figura 8 indican dónde el LSP no funciona debido a los siguientes problemas en la capa IP e IGP:
Una dirección IP está configurada incorrectamente en el enrutador de entrada (R1).
El protocolo OSPF se configura con un ID de enrutador (RID) pero sin la interfaz de circuito cerrado (lo0) y falta ingeniería de tráfico en el enrutador de tránsito (R3).
Los niveles de la red IS-IS no coinciden.
Verificación de la capa IP
Propósito
Puede comprobar la capa IP antes o después de comprobar la capa de protocolo de puerta de enlace interior (IGP), dependiendo de si tiene OSPF o IS-IS configurado como IGP. Si la red MPLS está configurada con OSPF como IGP, primero debe verificar la capa IP, comprobando que las interfaces tienen el direccionamiento IP correcto y que los vecinos de OSPF están establecidos antes de comprobar la capa OSPF.
Si tiene IS-IS configurado como IGP en su red MPLS, puede verificar primero la capa IP o la capa de protocolo IS-IS. El orden en que se comprueba la capa IP o IS-IS no afecta a los resultados.
La entrada cruzada Figura 9 indica dónde se rompe el LSP debido a una configuración incorrecta de una dirección IP en el enrutador R1de entrada.
- Comprobar el LSP
- Verificar el direccionamiento IP
- Verificar vecinos o adyacencias en la capa IP
- Tome las medidas apropiadas
- Compruebe de nuevo el LSP
Comprobar el LSP
Propósito
Después de configurar el LSP, debe comprobar que el LSP esté activo. Los LSP pueden ser de entrada, tránsito o salida. Utilice el show mpls lsp comando para una comprobación rápida del estado del LSP, con la extensive opción (show mpls lsp extensive) como seguimiento si el LSP está inactivo. Si su red tiene numerosos LSP, podría considerar la posibilidad de especificar el nombre del LSP mediante la name opción (show mpls lsp name name o show mpls lsp name name extensive).
Acción
Para comprobar que el LSP está activo, escriba el siguiente comando desde el enrutador de entrada:
user@host> show mpls lsp extensive
Ejemplo de salida 1
nombre-comando
user@R1> show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.6
From: 10.0.0.1, State: Dn, ActiveRoute: 0, LSPname: R1-to-R6
ActivePath: (none)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
Primary State: Dn
Will be enqueued for recomputation in 25 second(s).
44 Oct 15 16:56:11 CSPF failed: no route toward 10.0.0.6 [2685 times]
43 Oct 14 19:07:09 Clear Call
42 Oct 14 19:06:56 Deselected as active
41 Oct 14 19:06:56 10.1.12.1: MPLS label allocation failure
40 Oct 14 19:06:56 Down
39 Oct 14 18:43:43 Selected as active path
38 Oct 14 18:43:43 Record Route: 10.1.13.2 10.1.36.2
37 Oct 14 18:43:43 Up
[...Output truncated...]
Created: Thu Oct 14 16:04:33 2004
Total 1 displayed, Up 0, Down 1
Egress LSP: 0 sessions
Total 0 displayed , Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed , Up 0, Down 0
Significado
La salida de ejemplo del enrutador R1 de entrada muestra que se produjo un error en la asignación de etiquetas MPLS y que falló el algoritmo CSPF (Constrained Shortest Path First), lo que provocó que no se enrutara al destino 10.0.0.6 en R6.
Verificar el direccionamiento IP
Propósito
Cuando se investiga la capa IP, se comprueba que las interfaces tienen el direccionamiento IP correcto y que se han establecido vecinos de OSPF o adyacencias IS-IS. En este ejemplo, una dirección IP está configurada incorrectamente en el enrutador de entrada (R1).
Acción
Para comprobar el direccionamiento IP, escriba el siguiente comando desde los enrutadores de entrada, tránsito y salida:
user@host> show interfaces terse
Salida de muestra
nombre-comando
user@R1> show interfaces terse
Interface Admin Link Proto Local Remote
so-0/0/0 up up
so-0/0/0.0 up up inet 10.1.12.1/30
iso
mpls
so-0/0/1 up up
so-0/0/1.0 up up inet 10.1.15.1/30
iso
mpls
so-0/0/2 up up
so-0/0/2.0 up up inet 10.1.13.2 <<< Incorrect IP address
iso
mpls
lo0 up up
lo0.0 up up inet 10.0.0.1
iso 49.0004.1000.0000.0001.00
user@R3> show interfaces terse
Interface Admin Link Proto Local Remote
so-0/0/0 up up
so-0/0/0.0 up up inet 10.1.34.1/30
iso
mpls
so-0/0/1 up up
so-0/0/1.0 up up inet 10.1.23.2/30
iso
mpls
so-0/0/2 up up
so-0/0/2.0 up up inet 10.1.13.2/30 <<< Identical to R1
iso
mpls
so-0/0/3 up up
so-0/0/3.0 up up inet 10.1.36.1/30
iso
mpls
lo0 up up
lo0.0 up up inet 10.0.0.3
iso 49.0004.1000.0000.0003.00
user@R6> show interfaces terse
Interface Admin Link Proto Local Remote
so-0/0/0 up up
so-0/0/0.0 up up inet 10.1.56.2/30
iso
mpls
so-0/0/1 up up
so-0/0/1.0 up up inet 10.1.46.2/30
iso
mpls
so-0/0/2 up up
so-0/0/2.0 up up inet 10.1.26.2/30
iso
mpls
so-0/0/3 up up
so-0/0/3.0 up up inet 10.1.36.2/30
iso
mpls
lo0.0 up up inet 10.0.0.6
iso 49.0004.1000.0000.0006.00
Significado
El resultado de ejemplo muestra que las direcciones IP para la interfaz so-0/0/2.0 activada R1 y la interfaz so-0/0/2.0 activada son R3 idénticas. Las direcciones IP de interfaz dentro de una red deben ser únicas para que la interfaz se identifique correctamente.
Verificar vecinos o adyacencias en la capa IP
Propósito
Si el direccionamiento IP está configurado incorrectamente, es necesario comprobar los vecinos de OSPF o las adyacencias IS-IS para determinar si una o ambas están establecidas.
Acción
Para comprobar vecinos (OSPF) o adyacencias (IS-IS), introduzca los siguientes comandos desde los enrutadores de entrada, tránsito y salida:
user@host> show ospf neighbor extensive user@host> show isis adjacency extensive
Ejemplo de salida 1
nombre-comando
user@R1> show ospf neighbor extensive Address Interface State ID Pri Dead 10.1.12.2 so-0/0/0.0 Full 10.0.0.2 128 34 area 0.0.0.0, opt 0x42, DR 0.0.0.0, BDR 0.0.0.0 Up 1d 04:45:20, adjacent 1d 04:45:20 10.1.15.2 so-0/0/1.0 Full 10.0.0.5 128 35 area 0.0.0.0, opt 0x42, DR 0.0.0.0, BDR 0.0.0.0 Up 1d 04:45:20, adjacent 1d 04:45:10 <<< no adjacency with R3 so-0/0/2 user@R3> show ospf neighbor extensive Address Interface State ID Pri Dead 10.1.23.1 so-0/0/1.0 Full 10.0.0.2 128 35 area 0.0.0.0, opt 0x42, DR 0.0.0.0, BDR 0.0.0.0 Up 1w2d 04:54:30, adjacent 1w2d 04:54:21 10.1.36.2 so-0/0/3.0 Full 10.0.0.6 128 39 area 0.0.0.0, opt 0x42, DR 0.0.0.0, BDR 0.0.0.0 Up 1w2d 04:54:30, adjacent 1w2d 04:54:30 <<< no adjacency with R1 so-0/0/2 user@R6> show ospf neighbor extensive Address Interface State ID Pri Dead 10.1.56.1 so-0/0/0.0 Full 10.0.0.5 128 39 area 0.0.0.0, opt 0x42, DR 0.0.0.0, BDR 0.0.0.0 Up 1d 02:59:35, adjacent 1d 02:59:35 10.1.26.1 so-0/0/2.0 Full 10.0.0.2 128 36 area 0.0.0.0, opt 0x42, DR 0.0.0.0, BDR 0.0.0.0 Up 1w2d 04:57:30, adjacent 1w2d 04:57:30 10.1.36.1 so-0/0/3.0 Full 10.0.0.3 128 36 area 0.0.0.0, opt 0x42, DR 0.0.0.0, BDR 0.0.0.0 Up 1w2d 04:56:11, adjacent 1w2d 04:56:11
Ejemplo de salida 2
nombre-comando
user@R1> show isis adjacency extensive R2 Interface: so-0/0/0.0, Level: 2, State: Up , Expires in 23 secs Priority: 0, Up/Down transitions: 1, Last transition: 05:57:16 ago Circuit type: 2, Speaks: IP , IPv6 Topologies: Unicast Restart capable: Yes IP addresses: 10.1.12.2 Transition log: When State Reason Fri Oct 15 14:58:35 Up Seenself R5 Interface: so-0/0/1.0, Level: 2, State: Up, Expires in 26 secs Priority: 0, Up/Down transitions: 1, Last transition: 05:56:52 ago Circuit type: 2, Speaks: IP , IPv6 Topologies: Unicast Restart capable: Yes IP addresses: 10.1.15.2 Transition log: When State Reason Fri Oct 15 14:59:00 Up Seenself R3 Interface: so-0/0/2.0, Level: 2, State: Up, Expires in 26 secs Priority: 0, Up/Down transitions: 1, Last transition: 05:56:51 ago Circuit type: 2, Speaks: IP , IPv6 Topologies: Unicast Restart capable: Yes IP addresses: 10.1.13.2 Transition log: When State Reason Fri Oct 15 14:59:01 Up Seenself user@R3> show isis adjacency extensive R4 Interface: so-0/0/0.0, Level: 2, State: Up , Expires in 25 secs Priority: 0, Up/Down transitions: 1, Last transition: 1w1d 00:22:51 ago Circuit type: 2, Speaks: IP , IPv6 Topologies: Unicast Restart capable: Yes IP addresses: 10.1.34.2 Transition log: When State Reason Thu Oct 28 15:13:12 Up Seenself R2 Interface: so-0/0/1.0, Level: 2, State: Up , Expires in 25 secs Priority: 0, Up/Down transitions: 1, Last transition: 2w2d 18:02:48 ago Circuit type: 2, Speaks: IP , IPv6 Topologies: Unicast Restart capable: Yes IP addresses: 10.1.23.1 Transition log: When State Reason Tue Oct 19 21:33:15 Up Seenself R1 Interface: so-0/0/2.0, Level: 2, State: Up , Expires in 22 secs Priority: 0, Up/Down transitions: 1, Last transition: 2w2d 17:24:06 ago Circuit type: 2, Speaks: IP , IPv6 Topologies: Unicast Restart capable: Yes IP addresses: 10.1.13.1 Transition log: When State Reason Tue Oct 19 22:11:57 Up Seenself R6 Interface: so-0/0/3.0, Level: 2, State: Up , Expires in 21 secs Priority: 0, Up/Down transitions: 1, Last transition: 2w1d 00:07:00 ago Circuit type: 2, Speaks: IP , IPv6 Topologies: Unicast Restart capable: Yes IP addresses: 10.1.36.2 Transition log: When State Reason Thu Oct 21 15:29:03 Up Seenself user@R6> show isis adjacency extensive R5 Interface: so-0/0/0.0, Level: 2, State: Up , Expires in 23 secs Priority: 0, Up/Down transitions: 1, Last transition: 1w2d 01:10:03 ago Circuit type: 2, Speaks: IP , IPv6 Topologies: Unicast Restart capable: Yes IP addresses: 10.1.56.1 Transition log: When State Reason Wed Oct 27 14:35:32 Up Seenself R4 Interface: so-0/0/1.0, Level: 2, State: Up , Expires in 25 secs Priority: 0, Up/Down transitions: 1, Last transition: 1w1d 00:26:50 ago Circuit type: 2, Speaks: IP , IPv6 Topologies: Unicast Restart capable: Yes IP addresses: 10.1.46.1 Transition log: When State Reason Thu Oct 28 15:18:45 Up Seenself R2 Interface: so-0/0/2.0, Level: 2, State: Up , Expires in 24 secs Priority: 0, Up/Down transitions: 1, Last transition: 2w1d 00:11:40 ago Circuit type: 2, Speaks: IP , IPv6 Topologies: Unicast Restart capable: Yes IP addresses: 10.1.26.1 Transition log: When State Reason Thu Oct 21 15:33:55 Up Seenself R3 Interface: so-0/0/3.0, Level: 2, State: Up , Expires in 19 secs Priority: 0, Up/Down transitions: 1, Last transition: 2w1d 00:11:40 ago Circuit type: 2, Speaks: IP , IPv6 Topologies: Unicast Restart capable: Yes IP addresses: 10.1.36.1 Transition log: When State Reason Thu Oct 21 15:33:55 Up Seenself
Significado
La salida de ejemplo 1 de los enrutadores de entrada, tránsito y salida muestra que R1 y R3 no son vecinos de OSPF establecidos. Teniendo en cuenta que las dos interfaces so-0/0/2.0 (R1 y R3) están configuradas con direcciones IP idénticas, cabría esperar esto. El protocolo OSPF enruta paquetes IP basándose únicamente en la dirección IP de destino contenida en el encabezado del paquete IP. Por lo tanto, direcciones IP idénticas en el sistema autónomo (AS) dan como resultado que los vecinos no se establezcan.
El resultado de muestra 2 de los enrutadores de entrada, tránsito y salida muestra que R1 y han establecido una adyacencia IS-IS a pesar de las direcciones IP idénticas configuradas en las interfaces so-0/0/2.0R1 en y R3R3 . El protocolo IS-IS se comporta de manera diferente al protocolo OSPF porque no depende de IP para establecer una adyacencia. Sin embargo, si el LSP no está activo, sigue siendo útil comprobar el direccionamiento de la subred IP en caso de que haya un error en esa capa. Si se corrige el error de direccionamiento, es posible que el LSP vuelva a funcionar.
Tome las medidas apropiadas
Problema
Description
En función del error que haya encontrado en la investigación, debe tomar las medidas adecuadas para corregir el problema. En este ejemplo, la dirección IP de una interfaz en el enrutador R2 de tránsito está configurada incorrectamente.
Solución
Para corregir el error de este ejemplo, escriba los siguientes comandos:
[edit interfaces so-0/0/2]
user@R1# show
user@R1# rename unit 0 family inet address 10.1.13.2/30 to address 10.1.13.1/30
user@R1# show
user@R1# commit
Salida de muestra
[edit interfaces so-0/0/2]
user@R1# show
unit 0 {
family inet {
address 10.1.13.2/30; <<< Incorrect IP address
}
family iso;
family mpls;
}
[edit interfaces so-0/0/2]
user@R1# rename unit 0 family inet address 10.1.13.2/30 to address 10.1.13.1/30
[edit interfaces so-0/0/2]
user@R1# show
unit 0 {
family inet {
address 10.1.13.1/30; <<< Correct IP address.
}
family iso;
family mpls;
}
[edit interfaces so-0/0/2]
user@R1# commit
commit complete
Significado
El resultado de ejemplo muestra que la interfaz so-0/0/2 en el enrutador R1 de entrada ahora está configurada con la dirección IP correcta. Esta corrección da como resultado direcciones IP de subred únicas para todas las interfaces de la red MPLS en MPLS Network Broken at the IP and IGP Layers, y la posibilidad de que aparezca el LSP.
Compruebe de nuevo el LSP
Propósito
Después de tomar las medidas adecuadas para corregir el error, es necesario comprobar de nuevo el LSP para confirmar que se ha resuelto el problema en el protocolo OSPF.
Acción
Para comprobar de nuevo el LSP, escriba el siguiente comando en los enrutadores de entrada, tránsito y salida:
user@host> show mpls lsp extensive
Ejemplo de salida 1
nombre-comando
user@R1> show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.6
From: 10.0.0.1, State: Up, ActiveRoute: 1 , LSPname: R1-to-R6
ActivePath: (primary)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20)
10.1.13.2 S 10.1.36.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.1.13.2 10.1.36.2
54 Oct 15 21:28:16 Selected as active path
53 Oct 15 21:28:16 Record Route: 10.1.13.2 10.1.36.2
52 Oct 15 21:28:16 Up
51 Oct 15 21:28:16 10.1.15.1: MPLS label allocation failure[2 times]
50 Oct 15 21:28:11 CSPF: computation result accepted
49 Oct 15 21:27:42 10.1.15.1: MPLS label allocation failure
48 Oct 15 21:27:42 CSPF: computation result accepted
47 Oct 15 21:27:31 10.1.15.1: MPLS label allocation failure[4 times]
46 Oct 15 21:27:13 Originate Call
45 Oct 15 21:27:13 CSPF: computation result accepted
[...Output truncated...]
Created: Thu Oct 14 16:04:34 2004
Total 1 displayed, Up 1 , Down 0
Egress LSP: 1 sessions
10.0.0.1
From: 10.0.0.6, LSPstate: Up , ActiveRoute: 0
LSPname: R6-to-R1 , LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 149, Since: Fri Oct 15 21:28:13 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 13 receiver 39024 protocol 0
PATH rcvfrom: 10.1.13.2 (so-0/0/2.0) 10 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.1.36.2 10.1.13.2 <self>
Total 1 displayed, Up 1 , Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Ejemplo de salida 2
nombre-comando
user@R3> show mpls lsp extensive Ingress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 2 sessions 10.0.0.1 From: 10.0.0.6, LSPstate: Up , ActiveRoute: 1 LSPname: R6-to-R1 , LSPpath: Primary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 3 Resv style: 1 FF, Label in: 100336, Label out: 3 Time left: 156, Since: Fri Oct 15 21:15:47 2004 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 13 receiver 39024 protocol 0 PATH rcvfrom: 10.1.36.2 (so-0/0/3.0) 11 pkts Adspec: received MTU 1500 sent MTU 1500 PATH sentto: 10.1.13.1 (so-0/0/2.0) 11 pkts RESV rcvfrom: 10.1.13.1 (so-0/0/2.0) 11 pkts Explct route: 10.1.13.1 Record route: 10.1.36.2 <self> 10.1.13.1 10.0.0.6 From: 10.0.0.1, LSPstate: Up , ActiveRoute: 1 LSPname: R1-to-R6 , LSPpath: Primary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 3 Resv style: 1 FF, Label in: 100352, Label out: 3 Time left: 159, Since: Fri Oct 15 21:15:50 2004 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 5 receiver 47901 protocol 0 PATH rcvfrom: 10.1.13.1 (so-0/0/2.0) 11 pkts Adspec: received MTU 1500 sent MTU 1500 PATH sentto: 10.1.36.2 (so-0/0/3.0) 11 pkts RESV rcvfrom: 10.1.36.2 (so-0/0/3.0) 11 pkts Explct route: 10.1.36.2 Record route: 10.1.13.1 <self> 10.1.36.2 Total 2 displayed, Up 2 , Down 0
Ejemplo de salida 3
nombre-comando
user@R6> show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.1
From: 10.0.0.6, State: Up , ActiveRoute: 1, LSPname: R6-to-R1
ActivePath: (primary)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20)
10.1.36.1 S 10.1.13.1 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.1.36.1 10.1.13.1
187 Oct 15 21:20:05 Selected as active path
186 Oct 15 21:20:05 Record Route: 10.1.36.1 10.1.13.1
185 Oct 15 21:20:05 Up
184 Oct 15 21:20:05 Clear Call
183 Oct 15 21:20:05 CSPF: computation result accepted
182 Oct 15 21:20:05 CSPF: link down/deleted 10.1.13.2(R3.00/10.0.0.3)->10.1.13.2(R1.00/10.0.0.1)
[...Output truncated...]
Created: Tue Aug 17 12:18:33 2004
Total 1 displayed, Up 1 , Down 0
Egress LSP: 1 sessions
10.0.0.6
From: 10.0.0.1, LSPstate: Up, ActiveRoute: 0
LSPname: R1-to-R6 , LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 144, Since: Fri Oct 15 21:20:08 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 5 receiver 47901 protocol 0
PATH rcvfrom: 10.1.36.1 (so-0/0/3.0) 11 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.1.13.1 10.1.36.1 <self>
Total 1 displayed, Up 1 , Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Significado
La salida de muestra 1 del enrutador R1 de entrada muestra que el LSP R1-to-R6 tiene una ruta activa hacia R6 y que el estado está activo. El resultado muestra que la sesión R6-to-R1 LSP de salida recibió y envió una etiqueta de recuperación.
La salida de muestra 2 del enrutador R3 de tránsito muestra que hay dos sesiones de LSP de tránsito, una de R1 a R6 y la otra de R6 a Ambos R1. LSP están activos.
La salida de muestra 3 del enrutador R6 de salida muestra que el LSP está activo y que la ruta activa es la ruta principal. El LSP ahora atraviesa la red a lo largo de la ruta esperada, desde R1 hasta R3 , y el LSP inverso, desde R6 hasta R3R1.R6
Compruebe de nuevo el LSP
Propósito
Después de tomar las medidas adecuadas para corregir el error, es necesario comprobar de nuevo el LSP para confirmar que se ha resuelto el problema en el protocolo IS-IS.
Acción
Para comprobar que el LSP está activo y atravesando la red como se esperaba, escriba el siguiente comando desde los enrutadores de entrada, salida y tránsito:
user@host> show mpls lsp extensive
Salida de muestra
nombre-comando
user@R1> show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.6
From: 10.0.0.1, State: Up , ActiveRoute: 1, LSPname: R1-to-R6
ActivePath: (primary)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.1.13.2 10.1.36.2
4 Oct 19 21:22:54 Selected as active path
3 Oct 19 21:22:53 Record Route: 10.1.13.2 10.1.36.2
2 Oct 19 21:22:53 Up
1 Oct 19 21:22:53 Originate Call
Created: Tue Oct 19 21:22:53 2004
Total 1 displayed, Up 1 , Down 0
Egress LSP: 1 sessions
10.0.0.1
From: 10.0.0.6, LSPstate: Up , ActiveRoute: 0
LSPname: R6-to-R1 , LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 117, Since: Tue Oct 19 21:17:42 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 2 receiver 39064 protocol 0
PATH rcvfrom: 10.1.13.2 (so-0/0/2.0) 10 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.1.36.2 10.1.13.2 <self>
Total 1 displayed, Up 1 , Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
user@R3> show mpls lsp extensive
Ingress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 2 sessions
10.0.0.1
From: 10.0.0.6, LSPstate: Up, ActiveRoute: 1
LSPname: R6-to-R1 , LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 3
Resv style: 1 FF, Label in: 100416, Label out: 3
Time left: 139, Since: Tue Oct 19 21:05:11 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 2 receiver 39064 protocol 0
PATH rcvfrom: 10.1.36.2 (so-0/0/3.0) 11 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.1.13.1 (so-0/0/2.0) 11 pkts
RESV rcvfrom: 10.1.13.1 (so-0/0/2.0) 11 pkts
Explct route: 10.1.13.1
Record route: 10.1.36.2 <self> 10.1.13.1
10.0.0.6
From: 10.0.0.1, LSPstate: Up, ActiveRoute: 1
LSPname: R1-to-R6 , LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 3
Resv style: 1 FF, Label in: 100448, Label out: 3
Time left: 135, Since: Tue Oct 19 21:10:22 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 47951 protocol 0
PATH rcvfrom: 10.1.13.1 (so-0/0/2.0) 4 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.1.36.2 (so-0/0/3.0) 4 pkts
RESV rcvfrom: 10.1.36.2 (so-0/0/3.0) 4 pkts
Record route: 10.1.13.1 <self> 10.1.36.2
Total 2 displayed, Up 2 , Down 0
user@R6> run show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.1
From: 10.0.0.6, State: Up, ActiveRoute: 1, LSPname: R6-to-R1
ActivePath: (primary)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 2)
10.1.36.1 S 10.1.13.1 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.1.36.1 10.1.13.1
19 Oct 19 21:09:52 Selected as active path
18 Oct 19 21:09:52 Record Route: 10.1.36.1 10.1.13.1
17 Oct 19 21:09:52 Up
16 Oct 19 21:09:52 Originate Call
15 Oct 19 21:09:52 CSPF: computation result accepted
Created: Tue Oct 19 18:30:09 2004
Total 1 displayed, Up 1 , Down 0
Egress LSP: 1 sessions
10.0.0.6
From: 10.0.0.1, LSPstate: Up, ActiveRoute: 0
LSPname: R1-to-R6 , LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 120, Since: Tue Oct 19 21:15:03 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 47951 protocol 0
PATH rcvfrom: 10.1.36.1 (so-0/0/3.0) 4 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.1.13.1 10.1.36.1 <self>
Total 1 displayed, Up 1 , Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Significado
La salida de ejemplo del enrutador R1 de entrada y del enrutador R6 de salida muestra que el LSP ahora está atravesando la red a lo largo de la ruta esperada, desde R1 hasta R3 R6, y el LSP inverso, desde R6 hasta R3R1. Además, la salida de ejemplo del enrutador R3 de tránsito muestra que hay dos sesiones LSP de tránsito, una de R1 a R6y la otra de R6 a R1.
Comprobación de la capa RSVP
Propósito
Después de configurar la ruta de conmutación de etiquetas (LSP), emitir el show mpls lsp extensive comando y determinar que hay un error, es posible que el error no esté en las capas física, de vínculo de datos o de protocolo de Internet (IP) y de protocolo de puerta de enlace interior (IGP). Continúe investigando el problema en la capa RSVP de la red.
Figura 10 ilustra la capa RSVP del modelo MPLS en capas.
Con esta capa, se comprueba que la señalización dinámica de RSVP se está produciendo como se esperaba, que los vecinos están conectados y que las interfaces están configuradas correctamente para RSVP. Compruebe los enrutadores de entrada, salida y tránsito.
Si la red no funciona en esta capa, el LSP no funciona según lo configurado.
Figura 11 ilustra la red MPLS utilizada en este tema.
La red que se muestra en Figura 11 es una configuración completamente mallada donde cada interfaz conectada directamente puede recibir y enviar paquetes a cualquier otra interfaz similar. El LSP de esta red está configurado para ejecutarse desde el enrutador R1de entrada, pasando por el enrutador R3de tránsito, hasta el enrutador R6de salida. Además, un LSP inverso está configurado para ejecutarse desde R6 hasta R1R3 , creando tráfico bidireccional.
Sin embargo, en este ejemplo, el LSP está inactivo sin una ruta en ninguna dirección, de R1 a R6 o de R6 a R1.
Los cruces que se muestran en Figura 11 indican dónde se rompe el LSP. Algunas posibles razones por las que el LSP está roto pueden incluir que la señalización dinámica de RSVP no se está produciendo como se esperaba, los vecinos no están conectados o las interfaces están configuradas incorrectamente para RSVP.
En la red en Figura 11, un error de configuración en el enrutador R3 de tránsito impide que el LSP atraviese la red como se esperaba.
Para comprobar la capa RSVP, siga estos pasos:
- Comprobar el LSP
- Verificar sesiones RSVP
- Verificar confirmar RSVP vecinos
- Verificar interfaces RSVP
- Verificar la configuración del protocolo RSVP
- Tome las medidas apropiadas
- Compruebe de nuevo el LSP
Comprobar el LSP
Propósito
Normalmente, se utiliza el show mpls lsp extensive comando para comprobar el LSP. Sin embargo, para una comprobación rápida del estado de LSP, utilice el show mpls lsp comando. Si el LSP no funciona, utilice la extensive opción (show mpls lsp extensive) como seguimiento. Si su red tiene numerosos LSP, podría considerar especificar el nombre del LSP, usando la name opción (show mpls lsp name name o show mpls lsp name name extensive).
Acción
Para determinar si el LSP está activo, escriba el siguiente comando desde el enrutador de entrada:
user@host> show mpls lsp extensive
Ejemplo de salida 1
nombre-comando
user@R1> show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.6
From: 10.0.0.1, State: Dn, ActiveRoute: 0, LSPname: R1-to-R6
ActivePath: (none)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
Primary State: Dn
2 Oct 27 15:06:05 10.1.13.2: No Route toward dest [4 times]
1 Oct 27 15:05:56 Originate Call
Created: Wed Oct 27 15:05:55 2004
Total 1 displayed, Up 0, Down 1
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
user@R3> show mpls lsp extensive
Ingress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
user@R6> show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.1
From: 10.0.0.6, State: Dn, ActiveRoute: 0, LSPname: R6-to-R1
ActivePath: (none)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
Primary State: Dn
Will be enqueued for recomputation in 22 second(s).
1 Oct 27 14:59:12 CSPF failed: no route toward 10.0.0.1 [4 times]
Created: Wed Oct 27 14:57:44 2004
Total 1 displayed, Up 0, Down 1
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Significado
La salida de ejemplo muestra que el LSP está inactivo en ambas direcciones, de R1 a R6, y de R6 a .R1 La salida de R1 muestra que está usando un LSP no-cspf ya que R1 intentó originar la llamada sin poder llegar al destino. El resultado de R6 muestra que el algoritmo CSPF (Restricted Shortest Path First) falló, lo que da como resultado que no haya ninguna ruta a destino 10.0.0.1.
Verificar sesiones RSVP
Propósito
Cuando una sesión RSVP se crea correctamente, el LSP se configura a lo largo de las rutas creadas por la sesión RSVP. Si la sesión RSVP no se realiza correctamente, el LSP no funciona según lo configurado.
Acción
Para verificar las sesiones RSVP actualmente activas, ingrese el siguiente comando desde los enrutadores de entrada, tránsito y salida:
user@host> show rsvp session
Ejemplo de salida 1
nombre-comando
user@R1> show rsvp session Ingress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 user@R3> show rsvp session Ingress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 user@R6> show rsvp session Ingress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0
Ejemplo de salida 2
nombre-comando
user@R1> show rsvp session Ingress RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname 10.0.0.6 10.0.0.1 Up 1 1 FF - 100768 R1-to-R6 Total 1 displayed, Up 1 , Down 0 Egress RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname 10.0.0.1 10.0.0.6 Up 0 1 FF 3 - R6-to-R1 Total 1 displayed, Up 1 , Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 user@R3> show rsvp session Ingress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit RSVP: 2 sessions To From State Rt Style Labelin Labelout LSPname 10.0.0.1 10.0.0.6 Up 1 1 FF 100784 3 R6-to-R1 10.0.0.6 10.0.0.1 Up 1 1 FF 100768 3 R1-to-R6 Total 2 displayed, Up 2 , Down 0 user@R6> show rsvp session Ingress RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname 10.0.0.1 10.0.0.6 Up 1 1 FF - 100784 R6-to-R1 Total 1 displayed, Up 1 , Down 0 Egress RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname 10.0.0.6 10.0.0.1 Up 0 1 FF 3 - R1-to-R6 Total 1 displayed, Up 1 , Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0
Significado
La salida de muestra 1 de todos los enrutadores muestra que no se crearon correctamente sesiones RSVP, aunque el LSP R6-to-R1 esté configurado.
A diferencia de la salida de ejemplo 1y para ilustrar la salida correcta, la salida de muestra 2 muestra la salida de los enrutadores de entrada, tránsito y salida cuando la configuración RSVP es correcta y el LSP atraviesa la red tal como está configurado. R1 y R6 ambos muestran una sesión RSVP de entrada y salida, con el LSP R1-to-R6y el LSP R6-to-R1inverso. El enrutador R3 de tránsito muestra dos sesiones RSVP de tránsito.
Verificar confirmar RSVP vecinos
Propósito
Muestra una lista de vecinos RSVP que aprendieron dinámicamente al intercambiar paquetes RSVP. Una vez que se aprende un vecino, nunca se elimina de la lista de vecinos RSVP a menos que la configuración RSVP se elimine del enrutador.
Acción
Para verificar los vecinos de RSVP, ingrese el siguiente comando desde los enrutadores de entrada, tránsito y salida:
user@host> show rsvp neighbor
Ejemplo de salida 1
nombre-comando
user@R1> show rsvp neighbor RSVP neighbor: 1 learned Address Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd 10.1.13.2 10 1/0 9:22 9 64/64 32 user@R3> show rsvp neighbor RSVP neighbor: 2 learned Address Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd 10.1.13.1 0 1/0 28:20 9 190/190 41 10.1.36.2 16:50 1/1 15:37 9 105/78 38 user@R6> show rsvp neighbor RSVP neighbor: 1 learned Address Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd 10.1.36.1 17:30 1/1 16:15 9 104/78 39
Ejemplo de salida 2
nombre-comando
user@R3> show rsvp neighbor RSVP neighbor: 2 learned Address Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd 10.1.13.1 5 1/0 9:14 9 63/63 33 10.1.36.2 5 1/0 9:05 9 62/62 32 user@R6> show rsvp neighbor RSVP neighbor: 1 learned Address Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd 10.1.36.1 5 1/0 8:54 9 61/61 32
Significado
El resultado de ejemplo 1 muestra que R1 y R6 tienen un vecino RSVP cada uno, R3. Sin embargo, los valores en el Up/Dn campo son diferentes. R1 tiene un valor de 1/0 y R6 tiene un valor de 1/1, lo que indica que R1 es un vecino activo con R3, pero R6 no lo es. Cuando el conteo ascendente es uno más que el conteo descendente, el vecino está activo; Si los valores son iguales, el vecino está abajo. Los valores para R6 son iguales, 1/1, lo que indica que el vecino R3 está inactivo.
El enrutador R3 de tránsito conoce a dos vecinos R1 y R6. El Up/Dn campo indica que R1 es un vecino activo y R6 está inactivo. En este punto no es posible determinar si el problema reside en R3 o R6, porque ambos vecinos no están activos.
En contraste con la salida de muestra 1 y para ilustrar la salida correcta, la salida de muestra 2 muestra la relación de vecino correcta entre el enrutador R3 de tránsito y el enrutador R6de salida. El Up/Dn campo muestra que el conteo ascendente es uno más que el conteo descendente, 1/0, lo que indica que los vecinos están activos.
Verificar interfaces RSVP
Propósito
Muestra el estado de cada interfaz en la que RSVP está habilitado para determinar dónde se produjo el error de configuración.
Acción
Para comprobar el estado de las interfaces RSVP, escriba el siguiente comando desde los enrutadores de entrada, tránsito y salida:
user@host> show rsvp interface
Ejemplo de salida 1
nombre-comando
user@R1> show rsvp interface
RSVP interface: 3 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
so-0/0/0.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
so-0/0/1.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
so-0/0/2.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
user@R3> show rsvp interface
RSVP interface: 3 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
so-0/0/0.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
so-0/0/1.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
so-0/0/2.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
<<< Missing interface so-0/0/3.0
user@R6> show rsvp interface
RSVP interface: 4 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
so-0/0/0.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
so-0/0/1.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
so-0/0/2.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
so-0/0/3.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
Ejemplo de salida 2
nombre-comando
user@R1> show rsvp interface
RSVP interface: 3 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
so-0/0/0.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
so-0/0/1.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
so-0/0/2.0 Up 1 100% 155.52Mbps 155.52Mbps 0bps 0bps
user@R3> show rsvp interface
RSVP interface: 4 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
so-0/0/0.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
so-0/0/1.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
so-0/0/2.0 Up 1 100% 155.52Mbps 155.52Mbps 0bps 0bps
so-0/0/3.0 Up 1 100% 155.52Mbps 155.52Mbps 0bps 0bps
user@R6> show rsvp interface
RSVP interface: 4 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
so-0/0/0.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
so-0/0/1.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
so-0/0/2.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
so-0/0/3.0 Up 1 100% 155.52Mbps 155.52Mbps 0bps 0bps
Significado
La salida de ejemplo 1 muestra que aunque cada enrutador tiene interfaces que están activas y tienen RSVP activo, no hay reservas (Active resv) en ninguno de los enrutadores. En este ejemplo, esperaríamos al menos una reserva en los enrutadores de entrada y salida, y dos reservas en el enrutador de tránsito.
Además, la interfaz so-0/0/3 en el enrutador R3 de tránsito no está incluida en la configuración. La inclusión de esta interfaz es fundamental para el éxito del LSP.
A diferencia de la salida de muestra 1 y para ilustrar la salida correcta, la salida de muestra 2 muestra las interfaces relevantes con reservas activas.
Verificar la configuración del protocolo RSVP
Propósito
Después de comprobar las sesiones de RSVP, las interfaces y los vecinos, y de determinar que puede haber un error de configuración, compruebe la configuración del protocolo RSVP.
Acción
Para verificar la configuración de RSVP, ingrese el siguiente comando desde los enrutadores de entrada, tránsito y salida:
user@host> show configuration protocols rsvp
Salida de muestra
nombre-comando
user@R1> show configuration protocols rsvp
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
user@R3> show configuration protocols rsvp
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0; <<< Missing interface so-0/0/3.0
interface fxp0.0 {
disable;
}
user@R6> show configuration protocols rsvp
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fxp0.0 {
disable;
}
Significado
El resultado de ejemplo muestra que R3 falta una interfaz so-0/0/3.0 en la configuración del protocolo RSVP. Esta interfaz es crítica para el correcto funcionamiento del LSP.
Tome las medidas apropiadas
Problema
Description
En función del error que haya encontrado en la investigación, debe tomar las medidas adecuadas para corregir el problema. En este ejemplo, falta una interfaz en la configuración del enrutador R3.
Solución
Para corregir el error de este ejemplo, siga estos pasos:
Incluya la interfaz que falta en la configuración del enrutador de tránsito R3:
user@R3> edit user@R3# edit protocols rsvp [edit protocols rsvp] user@R3# show user@R3# set interface so-0/0/3.0
Compruebe y confirme la configuración:
[edit protocols rsvp] user@R3# show user@R3# commit
Salida de muestra
user@R3> edit
Entering configuration mode
[edit]
user@R3# edit protocols rsvp
[edit protocols rsvp]
user@R3# show
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0; <<< Missing interface so-0/0/3.0
interface fxp0.0 {
disable;
}
[edit protocols rsvp]
user@R3# set interface so-0/0/3.0
[edit protocols rsvp]
user@R3# show
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
interface so-0/0/3.0; <<< Interface now included in the configuration
[edit protocols rsvp]
user@R3# commit
commit complete
Significado
El resultado de ejemplo muestra que la interfaz so-0/0/3.0 que falta en el enrutador R3 de tránsito ahora se incluye correctamente en el nivel de jerarquía [edit protocols rsvp]. Esto da lugar a la posibilidad de que el LSP pueda surgir.
Compruebe de nuevo el LSP
Propósito
Después de tomar las medidas adecuadas para corregir el error, es necesario comprobar de nuevo el LSP para confirmar que se ha resuelto el problema en la capa MPLS.
Acción
Para comprobar de nuevo el LSP, escriba el siguiente comando en los enrutadores de entrada, tránsito y salida:
user@host> show mpls lsp extensive
Ejemplo de salida 1
nombre-comando
user@R1> show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.6
From: 10.0.0.1, State: Up, ActiveRoute: 1 , LSPname: R1-to-R6
ActivePath: (primary)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.1.13.2 10.1.36.2
5 Oct 27 15:28:57 Selected as active path
4 Oct 27 15:28:57 Record Route: 10.1.13.2 10.1.36.2
3 Oct 27 15:28:57 Up
2 Oct 27 15:28:44 10.1.13.2: No Route toward dest[35 times]
1 Oct 27 15:05:56 Originate Call
Created: Wed Oct 27 15:05:56 2004
Total 1 displayed, Up 1, Down 0
Egress LSP: 1 sessions
10.0.0.1
From: 10.0.0.6, LSPstate: Up, ActiveRoute: 0
LSPname: R6-to-R1, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 136, Since: Wed Oct 27 15:29:20 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 39092 protocol 0
PATH rcvfrom: 10.1.13.2 (so-0/0/2.0) 6 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.1.36.2 10.1.13.2 <self>
Total 1 displayed, Up 1, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Ejemplo de salida 2
nombre-comando
user@R3> show mpls lsp extensive Ingress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 2 sessions 10.0.0.1 From: 10.0.0.6, LSPstate: Up, ActiveRoute: 1 LSPname: R6-to-R1, LSPpath: Primary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 3 Resv style: 1 FF, Label in: 100672, Label out: 3 Time left: 152, Since: Wed Oct 27 15:16:39 2004 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 39092 protocol 0 PATH rcvfrom: 10.1.36.2 (so-0/0/3.0) 7 pkts Adspec: received MTU 1500 sent MTU 1500 PATH sentto: 10.1.13.1 (so-0/0/2.0) 7 pkts RESV rcvfrom: 10.1.13.1 (so-0/0/2.0) 7 pkts Explct route: 10.1.13.1 Record route: 10.1.36.2 <self> 10.1.13.1 10.0.0.6 From: 10.0.0.1, LSPstate: Up, ActiveRoute: 1 LSPname: R1-to-R6, LSPpath: Primary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 3 Resv style: 1 FF, Label in: 100656, Label out: 3 Time left: 129, Since: Wed Oct 27 14:53:14 2004 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 47977 protocol 0 PATH rcvfrom: 10.1.13.1 (so-0/0/2.0) 40 pkts Adspec: received MTU 1500 sent MTU 1500 PATH sentto: 10.1.36.2 (so-0/0/3.0) 7 pkts RESV rcvfrom: 10.1.36.2 (so-0/0/3.0) 7 pkts Record route: 10.1.13.1 <self> 10.1.36.2 Total 2 displayed, Up 2, Down 0
Ejemplo de salida 3
nombre-comando
user@R6> show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.1
From: 10.0.0.6, State: Up, ActiveRoute: 1 , LSPname: R6-to-R1
ActivePath: (primary)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20)
10.1.36.1 S 10.1.13.1 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.1.36.1 10.1.13.1
6 Oct 27 15:22:06 Selected as active path
5 Oct 27 15:22:06 Record Route: 10.1.36.1 10.1.13.1
4 Oct 27 15:22:06 Up
3 Oct 27 15:22:06 Originate Call
2 Oct 27 15:22:06 CSPF: computation result accepted
1 Oct 27 15:21:36 CSPF failed: no route toward 10.0.0.1[50 times]
Created: Wed Oct 27 14:57:45 2004
Total 1 displayed, Up 1, Down 0
Egress LSP: 1 sessions
10.0.0.6
From: 10.0.0.1, LSPstate: Up, ActiveRoute: 0
LSPname: R1-to-R6, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 119, Since: Wed Oct 27 15:21:43 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 47977 protocol 0
PATH rcvfrom: 10.1.36.1 (so-0/0/3.0) 7 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.1.13.1 10.1.36.1 <self>
Total 1 displayed, Up 1, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Significado
La salida de muestra 1 del enrutador R1 de entrada muestra que el LSP R1-to-R6 tiene una ruta activa hacia R6 y que el estado está activo.
La salida de ejemplo 2 del enrutador R3 de tránsito muestra que hay dos sesiones LSP de tránsito, una de R1 a R6 y la otra de R6 a .R1 Ambos LSP están activos.
La salida de muestra 3 del enrutador R6 de salida muestra que el LSP está activo y que la ruta activa es la ruta principal. El LSP ahora atraviesa la red a lo largo de la ruta esperada, desde R1 hasta R3 , y el LSP inverso, desde R6 hasta R3R1.R6
Determinación de estadísticas de LSP
Propósito
Muestra información detallada sobre los objetos RSVP para ayudar al diagnóstico de un problema de LSP.
Acción
Para comprobar los objetos RSVP, escriba el siguiente comando del modo operativo de la CLI de Junos OS:
user@host> show rsvp session detail
Salida de muestra
nombre-comando
user@R1> show rsvp session detail Ingress RSVP: 1 sessions 10.0.0.6 From: 10.0.0.1, LSPstate: Up, ActiveRoute: 1 LSPname: R1-to-R6 , LSPpath: Primary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 100064 Resv style: 1 FF, Label in: -, Label out: 100064 Time left: -, Since: Tue Aug 17 12:22:52 2004 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 12 receiver 44251 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 PATH sentto: 10.1.13.2 (so-0/0/2.0) 182 pkts RESV rcvfrom: 10.1.13.2 (so-0/0/2.0) 159 pkts Explct route: 10.1.13.2 10.1.36.2 Record route: <self> 10.1.13.2 10.1.36.2 Total 1 displayed, Up 1, Down 0 Egress RSVP: 1 sessions 10.0.0.1 From: 10.0.0.6 , LSPstate: Up, ActiveRoute: 0 LSPname: R6-to-R1, LSPpath: Primary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: - Resv style: 1 FF, Label in: 3, Label out: - Time left: 135, Since: Tue Aug 17 12:23:14 2004 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 39024 protocol 0 PATH rcvfrom: 10.1.15.2 (so-0/0/1.0) 158 pkts Adspec: received MTU 1500 PATH sentto: localclient RESV rcvfrom: localclient Record route: 10.1.56.2 10.1.15.2 <self> Total 1 displayed, Up 1, Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0
Significado
La salida de ejemplo muestra que hay una sesión RSVP de entrada y una de salida. La sesión de entrada tiene una dirección de origen de 10.0.0.1 (R1), y la sesión está activa, con una ruta activa. El nombre del LSP es R1-to-R6 y es la ruta principal del LSP.
La etiqueta de recuperación (100064) es enviada por un enrutador de reinicio elegante a su vecino para recuperar un estado de reenvío. Probablemente sea la vieja etiqueta que el enrutador anunciaba antes de que se cayera.
Esta sesión utiliza el filtro fijo (FF) estilo de reserva (Resv style). Dado que se trata de un enrutador de entrada, no hay una etiqueta de entrada. La etiqueta de salida (proporcionada por el siguiente enrutador descendente) es 100064.
El Time Left campo proporciona el número de segundos restantes en la sesión RSVP y el Tspec objeto proporciona información sobre la velocidad de carga controlada (rate) y el tamaño máximo de ráfaga (peak), un valor infinito (Infbps) para la opción de entrega garantizada y la indicación de que los paquetes menores de 20 bytes se tratan como 20 bytes, mientras que los paquetes mayores de 1500 bytes se tratan como 1500 bytes.
El número de puerto es el ID del túnel IPv4, mientras que el número de puerto del remitente/receptor es el ID del LSP. El ID de túnel IPv4 es único durante la vida del LSP, mientras que el ID de LSP del remitente/receptor puede cambiar, por ejemplo, con una reserva de estilo SE.
El PATH rcvfrom campo incluye el origen del mensaje de ruta de acceso. Dado que este es el enrutador de entrada, el cliente local originó el mensaje de ruta de acceso.
El PATH sentto campo incluye la ruta de destino10.1.13.2 del mensaje () y la interfaz de salida (so-0/0/2.0). El RESV rcvfrom campo incluye tanto el origen del mensaje Resv recibido (10.1.13.2) como la interfaz entrante (so-0/0/2.0).
Los valores de ruta explícita RSVP y registro de ruta son idénticos: 10.1.13.2 y 10.1.36.2. En la mayoría de los casos, los valores de ruta explícita y ruta de registro son idénticos. Las diferencias indican que se ha producido algún reenrutamiento de ruta, normalmente durante el reenrutamiento rápido.
Los Total campos indican el número total de sesiones RSVP de entrada, salida y tránsito, siendo el total igual a la suma de las sesiones ascendentes y descendentes. En este ejemplo, hay una sesión de entrada, una sesión de salida y ninguna sesión de RSVP de tránsito.
Verificación del uso de LSP en la red
Propósito
Cuando compruebe el uso válido de un LSP en los enrutadores de entrada y tránsito de la red, puede determinar si hay algún problema con la conmutación de etiquetas multiprotocolo (MPLS) en la red. Figura 12 Describe el ejemplo de red utilizado en este tema.
La red MPLS en Figura 12 ilustra una red solo de enrutador con interfaces SONET que constan de los siguientes componentes:
Una topología de Protocolo de puerta de enlace fronteriza interior (IBGP) de malla completa, mediante el AS 65432
MPLS y protocolo de reserva de recursos (RSVP) habilitado en todos los enrutadores
Una send-statics política sobre los enrutadores R1 y R6 que permite anunciar una nueva ruta en la red
Un LSP entre los enrutadores R1 y R6
La red que se muestra en Figura 12 es una red de malla completa del Protocolo de puerta de enlace fronteriza (BGP). Dado que los reflectores de ruta y las confederaciones no se utilizan para propagar las rutas aprendidas del BGP, cada enrutador debe tener una sesión de BGP con todos los demás enrutadores que ejecuten BGP.
Para comprobar el uso de LSP en la red, siga estos pasos:
- Verificación de un LSP en el enrutador de entrada
- Verificación de un LSP en un enrutador de tránsito
Verificación de un LSP en el enrutador de entrada
Propósito
Puede comprobar la disponibilidad de un LSP cuando está activo examinando la inet.3 tabla de enrutamiento del enrutador de entrada. La inet.3 tabla de enrutamiento contiene la dirección de host del enrutador de salida de cada LSP. Esta tabla de enrutamiento se utiliza en enrutadores de entrada para enrutar paquetes BGP al enrutador de salida de destino. BGP utiliza la tabla de enrutamiento del enrutador de entrada para ayudar a resolver las inet.3 direcciones del próximo salto.
Acción
Para comprobar un LSP en un enrutador de entrada, escriba el siguiente comando de modo operativo de interfaz de línea de comandos (CLI) de Junos OS:
user@host> show route table inet.3
Salida de muestra
nombre-comando
user@R1> show route table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.6/32 *[RSVP/7] 4w0d 22:40:57, metric 20
> via so-0/0/2.0, label-switched-path R1-to-R6
Significado
El resultado de ejemplo muestra la tabla de inet.3 enrutamiento. De forma predeterminada, solo las redes privadas virtuales (VPN) BGP y MPLS pueden usar la tabla de rutas para resolver la inet.3 información del próximo salto. Un destino aparece en la tabla de rutas, 10.0.0.6. Este destino (10.0.0.6) está señalado por RSVP y es la ruta activa actual, como lo indica el asterisco (*). La preferencia de protocolo para esta ruta es 7 y la métrica asociada a ella es 20. La ruta de conmutación de etiquetas es R1-to-R6, a través de la interfaz so-0/0/2.0, que es la interfaz física de tránsito del siguiente salto.
Normalmente, el penúltimo enrutador del LSP abre la etiqueta del paquete o cambia la etiqueta a un valor de 0. Si el penúltimo enrutador muestra la etiqueta superior y hay un paquete IPv4 debajo, el enrutador de salida enruta el paquete IPv4 y consulta la tabla inet.0 de enrutamiento IP para determinar cómo reenviar el paquete. Si otro tipo de etiqueta (como una creada por tunelización del Protocolo de distribución de etiquetas (LDP) o VPN, pero no IPv4) está debajo de la etiqueta superior, el enrutador de salida no examina la inet.0 tabla de enrutamiento. En su lugar, examina la tabla de mpls.0 enrutamiento para las decisiones de reenvío.
Si el penúltimo enrutador cambia la etiqueta del paquete a un valor de 0, el enrutador de salida elimina la etiqueta 0 e indica que le sigue un paquete IPv4. La tabla de enrutamiento examina el inet.0 paquete para las decisiones de reenvío.
Cuando un enrutador de tránsito o de salida recibe un paquete MPLS, la información de la tabla de reenvío de MPLS se utiliza para determinar el siguiente enrutador de tránsito en el LSP o si este enrutador es el enrutador de salida.
Cuando BGP resuelve un prefijo de salto siguiente, examina tanto las tablas como las de enrutamiento, buscando el siguiente salto con la preferencia más baja; por ejemplo, se prefiere la preferencia 7 de RSVP sobre la inet.0inet.3 preferencia 10 de OSPF. El LSP señalizado RSVP se utiliza para alcanzar el siguiente salto del BGP. Este es el valor predeterminado cuando el siguiente salto del BGP es igual a la dirección de salida del LSP. Una vez que el siguiente salto del BGP se resuelve a través de un LSP, el tráfico del BGP utiliza el LSP para reenviar el tráfico de tránsito del BGP.
Verificación de un LSP en un enrutador de tránsito
Propósito
Puede comprobar la disponibilidad de un LSP cuando está activo examinando la mpls.0 tabla de enrutamiento en un enrutador de tránsito. MPLS mantiene la mpls.0 tabla de enrutamiento, que contiene una lista del siguiente enrutador con conmutación de etiquetas en cada LSP. Esta tabla de enrutamiento se utiliza en enrutadores de tránsito para enrutar paquetes al siguiente enrutador a lo largo de un LSP.
Acción
Para verificar un LSP en un enrutador de tránsito, ingrese el siguiente comando de modo operativo de la CLI de Junos OS:
user@host> show route table mpls.0
Salida de muestra
nombre-comando
user@R3> show route table mpls.0
mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 * [MPLS/0] 7w3d 22:20:56, metric 1
Receive
1 * [MPLS/0] 7w3d 22:20:56, metric 1
Receive
2 * [MPLS/0] 7w3d 22:20:56, metric 1
Receive
100064 * [RSVP/7] 2w1d 04:17:36, metric 1
> via so-0/0/3.0, label-switched-path R1-to-R6
100064 (S=0) * [RSVP/7] 2w1d 04:17:36, metric 1
> via so-0/0/3.0, label-switched-path R1-to-R6
Significado
La salida de ejemplo del enrutador R3 de tránsito muestra las entradas de ruta en forma de entradas de etiqueta MPLS, lo que indica que solo hay una ruta activa, aunque haya cinco entradas activas.
Las tres primeras etiquetas MPLS son etiquetas MPLS reservadas definidas en RFC 3032. Los paquetes recibidos con estos valores de etiqueta se envían al motor de enrutamiento para su procesamiento. La etiqueta 0 es la etiqueta nula explícita de IPv4. La etiqueta 1 es el equivalente MPLS de la etiqueta de alerta del enrutador IP y la etiqueta 2 es la etiqueta nula explícita IPv6.
Las dos entradas con la 100064 etiqueta son para el mismo LSP, R1-to-R6. hay dos entradas porque los valores de pila en el encabezado MPLS pueden ser diferentes. La segunda entrada, 100064 (S=0), indica que la profundidad de la pila no es 1 y que se incluyen valores de etiqueta adicionales en el paquete. En contraste, la primera entrada de 100064 tiene una S = 1 inferida que indica una profundidad de pila de 1 y la convierte en la última etiqueta del paquete. La entrada doble indica que este es el penúltimo enrutador. Para obtener más información sobre el apilamiento de etiquetas MPLS, consulte RFC 3032, Codificación de pila de etiquetas MPLS.
La etiqueta entrante es el encabezado MPLS del paquete MPLS y RSVP la asigna al vecino ascendente. Los enrutadores de Juniper Networks asignan dinámicamente etiquetas para los LSP de ingeniería de tráfico RSVP en el intervalo de 100 000 a 1 048 575.
El enrutador asigna etiquetas a partir de la etiqueta 100.000, en incrementos de 16. La secuencia de asignaciones de etiquetas es 100.000, 100.016, 100.032, 100.048, etc. Al final de las etiquetas asignadas, los números de etiqueta comienzan de nuevo en 100001, incrementándose en unidades de 16. Juniper Networks se reserva las etiquetas para diversos fines. Tabla 1 enumera las distintas asignaciones de rango de etiquetas para las etiquetas entrantes.
Etiqueta entrante |
Estado |
|---|---|
0 a través de 15 |
Reservado por IETF |
16 a través de 1023 |
Reservado para la asignación de LSP estático |
1024 a través de 9999 |
Reservado para uso interno (por ejemplo, etiquetas CCC) |
10,000 a través de 99,999 |
Reservado para la asignación de LSP estático |
100,000 a través de 1,048,575 |
Reservado para la asignación dinámica de etiquetas |
Comprobar que el equilibrio de carga funciona
Propósito
Después de configurar el equilibrio de carga, compruebe que el tráfico tiene el mismo equilibrio de carga en todas las rutas. En esta sección, el resultado del comando refleja la configuración de equilibrio de carga de la red de ejemplo que se muestra en Topología de red de equilibrio de carga. Los clear comandos se usan para restablecer el LSP y los contadores de interfaz a cero, de modo que los valores reflejen el funcionamiento de la configuración de equilibrio de carga.
Acción
Para comprobar el equilibrio de carga entre interfaces y LSP, utilice el siguiente comando en el enrutador de entrada:
user@host# show configuration
Para comprobar el equilibrio de carga entre interfaces y LSP, utilice los siguientes comandos en un enrutador de tránsito:
user@host# show route user@host# show route forwarding-table user@host# show mpls lsp statistics user@host# monitor interface traffic user@host# clear mpls lsp statistics user@host# clear interface statistics
Salida de muestra
nombre-comando
La siguiente salida de ejemplo es para la configuración en el enrutador R1de entrada:
user@R1> show configuration | no-more
[...Output truncated...]
routing-options {
[...Output truncated...]
forwarding-table {
export lbpp;
}
}
[...Output truncated...]
policy-options {
policy-statement lbpp {
then {
load-balance per-packet;
}
}
}
Significado
El resultado de ejemplo para el comando en el show configuration enrutador R1 de entrada muestra que el equilibrio de carga está configurado correctamente con la instrucción policy lbpp . Además, la lbpp directiva se exporta a la tabla de reenvío en el nivel jerárquico [edit routing-options] .
- Salida de muestra
- Significado
- Salida de muestra
- Significado
- Salida de muestra
- Significado
- Salida de muestra
- Significado
- Salida de muestra
- Significado
Salida de muestra
La siguiente salida de ejemplo procede del enrutador de tránsito R2:
user@R2> show route 192.168.0.1 terse
inet.0: 25 destinations, 27 routes (25 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 192.168.0.1/32 O 10 3 so-0/0/1.0
>so-0/0/2.0
[...Output truncated...]
Significado
El resultado de ejemplo para el show route comando emitido en el enrutador R2 de tránsito muestra las dos rutas de igual costo (so-0/0/1 y so-0/0/2) a través de la red hasta la dirección de circuito cerrado a R0 (192.168.0.1). Aunque el corchete angular derecho (>) generalmente indica la ruta activa, en este caso no lo hace, como se muestra en las siguientes cuatro salidas de muestra.
Salida de muestra
La siguiente salida de ejemplo procede del enrutador de tránsito R2:
user@R2> monitor interface traffic R2 Seconds: 65 Time: 11:41:14 Interface Link Input packets (pps) Output packets (pps) so-0/0/0 Up 0 (0) 0 (0) so-0/0/1 Up 126 (0) 164659 (2128) so-0/0/2 Up 85219 (1004) 164598 (2128) so-0/0/3 Up 0 (0) 0 (0) fe-0/1/0 Up 328954 (4265) 85475 (1094) fe-0/1/1 Up 0 (0) 0 (0) fe-0/1/2 Up 0 (0) 0 (0) fe-0/1/3 Up 0 (0) 0 (0) [...Output truncated...]
Significado
La salida de ejemplo para el comando emitido en el enrutador R2 de monitor interface traffic tránsito muestra que el tráfico de salida se distribuye uniformemente entre las dos interfaces so-0/0/1 y so-0/0/2.
Salida de muestra
La siguiente salida de ejemplo procede del enrutador de tránsito R2:
user@R2> show mpls lsp statistics Ingress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 5 sessions To From State Packets Bytes LSPname 192.168.0.1 192.168.1.1 Up 87997 17951388 lsp1 192.168.0.1 192.168.1.1 Up 87997 17951388 lsp2 192.168.0.1 192.168.1.1 Up 87997 17951388 lsp3 192.168.0.1 192.168.1.1 Up 87997 17951388 lsp4 192.168.6.1 192.168.0.1 Up 0 0 r0-r1 Total 5 displayed, Up 5, Down 0
Significado
La salida de ejemplo para el comando emitido en el show mpls lsp statistics enrutador R2 de tránsito muestra que el tráfico de salida se distribuye uniformemente entre los cuatro LSP configurados en el enrutador R6de entrada.
Salida de muestra
La siguiente salida de ejemplo procede del enrutador de tránsito R2:
user@R2> show route forwarding-table destination 10.0.90.14
Routing table: inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
10.0.90.12/30 user 0 ulst 262144 6
ucst 345 5 so-0/0/1.0
ucst 339 2 so-0/0/2.0
Significado
El resultado de ejemplo para el show route forwarding-table destination comando emitido en el enrutador R2 de tránsito se muestra ulst en el Type campo, lo que indica que el equilibrio de carga funciona. Las dos entradas unicast (ucst) en el Type campo son los dos saltos siguientes para los LSP.
Salida de muestra
La siguiente salida de ejemplo procede del enrutador de tránsito R2:
user@R2> show route forwarding-table | find mpls Routing table: mpls MPLS: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 dscd 38 1 0 user 0 recv 37 3 1 user 0 recv 37 3 2 user 0 recv 37 3 100112 user 0 Swap 100032 so-0/0/1.0 100128 user 0 Swap 100048 so-0/0/1.0 100144 user 0 10.0.12.13 Swap 100096 fe-0/1/0.0 100160 user 0 Swap 100112 so-0/0/2.0 100176 user 0 Swap 100128 so-0/0/2.0
Significado
El resultado de ejemplo para el comando emitido en el show route forwarding-table | find mpls enrutador de tránsito R2 muestra la tabla de enrutamiento MPLS que contiene las etiquetas recibidas y utilizadas por este enrutador para reenviar paquetes al enrutador del próximo salto. Esta tabla de enrutamiento se utiliza principalmente en enrutadores de tránsito para enrutar paquetes al siguiente enrutador a lo largo de un LSP. MPLS introduce automáticamente las tres primeras etiquetas de la Destination columna (etiqueta 0, etiqueta 1 y etiqueta 2) cuando el protocolo está habilitado. Estas etiquetas son etiquetas MPLS reservadas definidas en RFC 3032. La etiqueta 0 es la etiqueta nula explícita de IPv4. La etiqueta 1 es el equivalente MPLS de la etiqueta de alerta del enrutador IP y la etiqueta 2 es la etiqueta nula explícita IPv6.
Las cinco etiquetas restantes de la Destination columna son etiquetas no reservadas que el enrutador utiliza para reenviar el tráfico, y la última columna Netif, muestra las interfaces utilizadas para enviar el tráfico etiquetado. Para las etiquetas no reservadas, la segunda Type columna muestra la operación realizada en paquetes coincidentes. En este ejemplo, todos los paquetes no reservados se intercambian por etiquetas de paquetes salientes. Por ejemplo, a los paquetes con la etiqueta 100112 se les intercambia la etiqueta antes 100032 de que salgan de la interfaz so-0/0/1.0.
Verificar el funcionamiento del equilibrio de carga de ancho de banda desigual
Propósito
Cuando un enrutador realiza un equilibrio de carga de costo desigual entre rutas de LSP, el show route detail comando muestra un campo de equilibrio asociado con cada próximo salto que se utiliza.
Acción
Para comprobar que un LSP RSVP tiene un equilibrio de carga desigual, utilice los siguientes comandos del modo operativo de la CLI de Junos OS:
user@host> show route protocol rsvp detail user@host> show mpls lsp statistics
Salida de muestra
nombre-comando
user@R1> show route protocol rsvp detail
inet.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)
10.0.90.14/32 (1 entry, 1 announced)
State: <FlashAll>
*RSVP Preference: 7
Next-hop reference count: 7
Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 10%
Label-switched-path lsp1
Label operation: Push 100768
Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 20%
Label-switched-path lsp2
Label operation: Push 100736
Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 30%,
selected
Label-switched-path lsp3
Label operation: Push 100752
Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 40%
Label-switched-path lsp4
Label operation: Push 100784
State: <Active Int>
Local AS: 65432
Age: 8:03 Metric: 4
Task: RSVP
Announcement bits (2): 0-KRT 4-Resolve tree 1
AS path: I
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
192.168.0.1/32 (1 entry, 1 announced)
State: <FlashAll>
*RSVP Preference: 7
Next-hop reference count: 7
Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 10%
Label-switched-path lsp1
Label operation: Push 100768
Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 20%
Label-switched-path lsp2
Label operation: Push 100736
Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 30%
Label-switched-path lsp3
Label operation: Push 100752
Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 40%, selected
Label-switched-path lsp4
Label operation: Push 100784
State: <Active Int>
Local AS: 65432
Age: 8:03 Metric: 4
Task: RSVP
Announcement bits (1): 1-Resolve tree 1
AS path: I
user@R1> show mpls lsp statistics
Ingress LSP: 4 sessions
To From State Packets Bytes LSPname
192.168.0.1 192.168.1.1 Up 10067 845628 lsp1
192.168.0.1 192.168.1.1 Up 20026 1682184 lsp2
192.168.0.1 192.168.1.1 Up 29796 2502864 lsp3
192.168.0.1 192.168.1.1 Up 40111 3369324 lsp4
Total 4 displayed, Up 4, Down 0
Egress LSP: 1 sessions
To From State Packets Bytes LSPname
192.168.1.1 192.168.0.1 Up NA NA r0-r1
Total 1 displayed, Up 1, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Significado
La salida de ejemplo del enrutador R1 de entrada muestra que el tráfico se distribuye de acuerdo con la configuración de ancho de banda de LSP, como lo indica el Balance: xx% campo. Por ejemplo, lsp1 tiene configurados 10 Mbps de ancho de banda, como se refleja en el Balance: 10% campo.
Usar el comando traceroute para comprobar las etiquetas MPLS
Propósito
Puede utilizar el traceroute comando para comprobar que los paquetes se envían a través del LSP.
Acción
Para comprobar las etiquetas MPLS, escriba el siguiente comando de modo operativo de la CLI de Junos OS, donde host-name es la dirección IP o el nombre del host remoto:
user@host> traceroute host-name
Ejemplo de salida 1
nombre-comando
user@R1> traceroute 100.100.6.1
traceroute to 100.100.6.1 (100.100.6.1), 30 hops max, 40 byte packets
1 10.1.12.2 (10.1.12.2) 0.861 ms 0.718 ms 0.679 ms
MPLS Label=100048 CoS=0 TTL=1 S=1
2 10.1.24.2 (10.1.24.2) 0.822 ms 0.731 ms 0.708 ms
MPLS Label=100016 CoS=0 TTL=1 S=1
3 10.1.46.2 (10.1.46.2) 0.571 ms !N 0.547 ms !N 0.532 ms !N
Ejemplo de salida 2
nombre-comando
user@R1> traceroute 10.0.0.6 traceroute to 10.0.0.6 (10.0.0.6), 30 hops max, 40 byte packets 1 10.1.13.2 (10.1.13.2) 0.605 ms 0.548 ms 0.503 ms 2 10.0.0.6 (10.0.0.6) 0.761 ms 0.676 ms 0.675 ms
Significado
El resultado de ejemplo 1 muestra que las etiquetas MPLS se utilizan para reenviar paquetes a través de la red. En el resultado se incluye un valor de etiqueta (MPLS Label=100048), el valor de tiempo de vida (TTL=1) y el valor de bit de pila (S=1).
El MPLS Label campo se utiliza para identificar el paquete de un LSP determinado. Es un campo de 20 bits, con un valor máximo de (2^^20-1), o aproximadamente 1.000.000.
El valor TTL contiene un límite en el número de saltos que este paquete MPLS puede viajar a través de la red (1). Se disminuye en cada salto, y si el valor TTL cae por debajo de uno, el paquete se descarta.
La parte inferior del valor de bit de pila (S=1) indica que es la última etiqueta de la pila y que este paquete MPLS tiene una etiqueta asociada. La implementación de MPLS en Junos OS admite una profundidad de apilamiento de 3 en los enrutadores de la serie M y hasta 5 en las plataformas de la serie T. Para obtener más información sobre el apilamiento de etiquetas MPLS, consulte RFC 3032, Codificación de pila de etiquetas MPLS.
Las etiquetas MPLS aparecen en la salida de ejemplo 1 porque el traceroute comando se emite a un destino BGP donde el siguiente salto del BGP para esa ruta es la dirección de salida del LSP. El comportamiento predeterminado de Junos OS utiliza LSP para el tráfico BGP cuando el próximo salto del BGP es igual a la dirección de salida del LSP.
El resultado de ejemplo 2 muestra que las etiquetas MPLS no aparecen en el resultado del traceroute comando. Si el siguiente salto del BGP no es igual a la dirección de salida del LSP o el destino es una ruta del IGP, el tráfico del BGP no utiliza el LSP. En lugar de utilizar el LSP, el tráfico BGP utiliza el IGP (IS-IS, en este caso) para llegar a la dirección de salida (R6).
Solución de problemas de GMPLS y túnel GRE
Problema
Description
El canal de control lógico para GMPLS debe ser un vínculo punto a punto y debe tener algún tipo de accesibilidad IP. En interfaces de difusión o cuando hay varios saltos entre pares del canal de control, utilice un túnel GRE para el canal de control. Para obtener información más detallada sobre los túneles GMPLS y GRE, consulte la Guía de configuración de aplicaciones MPLS de Junos y la Guía del usuario de Junos.
No se requiere una PIC de túnel para configurar un túnel GRE para el canal de control GMPLS. En su lugar, utilice la interfaz basada en gre software, en lugar de la interfaz basada en gr-fpc/pic/port hardware.
Debido a las restricciones de la interfaz basada en gre software, el canal de control GMPLS es el único uso admitido de la interfaz basada en gre software. Cualquier otro uso no se admite expresamente y puede causar un error en la aplicación.
En el ejemplo siguiente se muestra una configuración de interfaz básica gre . En este caso, el origen del túnel es la dirección de circuito cerrado del enrutador local y la dirección de destino es el destino de circuito cerrado del enrutador remoto. El tráfico que tiene un próximo salto del destino del túnel utilizará el túnel. El túnel no es utilizado automáticamente por todo el tráfico que pasa por la interfaz. Solo el tráfico con el destino del túnel como próximo salto utiliza el túnel.
Salida de muestra
user@R1> show configuration interfaces
[...Output truncated...]
gre {
unit 0 {
tunnel {
source 10.0.12.13;
destination 10.0.12.14;
}
family inet {
address 10.35.1.6/30;
}
family mpls;
}
}
Salida de muestra
El siguiente resultado de ejemplo para el comando mostrar interfaces muestra el tipo y encabezado de encapsulación, la velocidad máxima, los paquetes a través de la interfaz lógica, el destino y la dirección lógica.
user@R1> show interfaces gre
Physical interface: gre, Enabled, Physical link is Up
Interface index: 10, SNMP ifIndex: 8
Type: GRE, Link-level type: GRE, MTU: Unlimited, Speed: Unlimited
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Input packets : 0
Output packets: 0
Logical interface gre.0 (Index 70) (SNMP ifIndex 47)
Flags: Point-To-Point SNMP-Traps 0x4000
IP-Header 10.0.12.14:10.0.12.13:47:df:64:0000000000000000
Encapsulation: GRE-NULL
Input packets : 171734
Output packets: 194560
Protocol inet, MTU: 1476
Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.35.1.4/30, Local: 10.35.1.6, Broadcast: 10.35.1.7
Protocol mpls, MTU: 1464
Flags: NoneLos siguientes son varios requisitos al configurar un LSP GMPLS mediante un túnel GRE:
El canal de datos debe comenzar y terminar en el mismo tipo de interfaz.
El canal de control puede ser un túnel GRE que comienza y termina en el mismo tipo de interfaz o en un tipo diferente.
El túnel GRE debe configurarse indirectamente con la peer-interface
peer-nameinstrucción en el nivel jerárquico[edit protocol ospf].La interfaz GRE debe estar deshabilitada en los niveles jerárquicos
[edit protocols ospf]y[edit protocols rsvp].Los canales de datos y control deben definirse correctamente en la configuración LMP.
Es opcional deshabilitar primero la ruta restringida más corta (CSPF) con la
no-cspfinstrucción.
Este caso se centra en la configuración incorrecta de los puntos finales del túnel GRE. Sin embargo, puede utilizar un proceso y comandos similares para diagnosticar otros problemas de túnel GRE. Figura 13 ilustra una topología de red con MPLS tunelizada a través de una interfaz GRE.
La topología de red MPLS en Figura 13 muestra los enrutadores de Juniper Networks configurados con un túnel GRE que consta de los siguientes componentes:
Una ruta LSP GMPLS estricta desde el enrutador de entrada hasta el enrutador de salida.
En el enrutador de entrada, CSPF deshabilitado con la
no-cspfinstrucción en el nivel de jerarquía [edit protocol mpls label-switched-path lsp-name].Vínculos de ingeniería de tráfico y canales de control dentro de la
peerinstrucción en el nivel de jerarquía [edit protocols link-management] en todos los enrutadores.Ingeniería de tráfico OSPF y OSPF configurada en todos los enrutadores.
Una referencia al peer-interface en OSPF y RSVP en todos los enrutadores.
Un problema de tipo conmutador entre R2 y R3.
Síntoma
El LSP en la red que se muestra en Figura 13 está inactivo, como lo indica la salida de los show mpls lsp comandos y show rsvp session , que muestran información muy similar. El show mpls lsp comando muestra todos los LSP configurados en el enrutador, así como todos los LSP de tránsito y salida. El show rsvp session comando muestra información de resumen sobre las sesiones RSVP. Puede utilizar cualquiera de los comandos para comprobar el estado del LSP. En este caso, el LSP gmpls-r1-to-r3 está inactivo (Dn).
Salida de muestra
user@R1> show mpls lsp Ingress LSP: 1 sessions To From State Rt ActivePath P LSPname 192.168.4.1 192.168.1.1 Dn 0 - gmpls-r1-to-r3 Bidir Total 1 displayed, Up 0, Down 1 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0 user@R1> show rsvp session Ingress RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname 192.168.4.1 192.168.1.1 Dn 0 0 - - - gmpls-r1-to-r3 Bidir Total 1 displayed, Up 0, Down 1 Egress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0
Causa
La causa del problema con el LSP GMPLS es la configuración de diferentes tipos de interfaz en ambos extremos del canal de datos GMPLS.
Comandos de solución de problemas
Junos OS incluye comandos que son útiles para solucionar un problema. En este tema se proporciona una breve descripción de cada comando, seguida de un resultado de ejemplo y una explicación del resultado en relación con el problema.
Puede utilizar los siguientes comandos al solucionar un problema de GMPLS:
user@host> show mpls lsp extensive user@host> show rsvp session detail user@host> show link-management peer user@host> show link-management te-link user@host> show configuration protocols mpls user@host> monitor start filename user@host> show log filename
Salida de muestra
Utilice el comando show mpls lsp extensive en el enrutador de tránsito R1 para mostrar información detallada sobre todos los LSP que transitan, terminan y están configurados en el enrutador.
user@R1> show mpls lsp extensive
Ingress LSP: 1 sessions
192.168.4.1
From: 192.168.1.1, State: Dn, ActiveRoute: 0, LSPname: gmpls-r1-to-r3
Bidirectional
ActivePath: (none)
LoadBalance: Random
Encoding type: SDH/SONET, Switching type: PSC-1, GPID: IPv4
Primary p1 State: Dn
SmartOptimizeTimer: 180
8 Dec 20 18:08:02 192.168.4.1: MPLS label allocation failure [3 times]
7 Dec 20 18:07:53 Originate Call
6 Dec 20 18:07:53 Clear Call
5 Dec 20 18:07:53 Deselected as active
4 Dec 20 18:06:13 Selected as active path
3 Dec 20 18:06:13 Record Route: 100.100.100.100 93.93.93.93
2 Dec 20 18:06:13 Up
1 Dec 20 18:06:13 Originate Call
Created: Wed Dec 20 18:06:12 2006
Total 1 displayed, Up 0, Down 1
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Significado
El resultado de ejemplo para el show mpls lsp extensive comando muestra un mensaje de error (MPLS label allocation failure) en la sección de registro de la salida. Este evento LSP indica que el protocolo MPLS o la family mpls instrucción no se configuraron correctamente. Cuando el evento LSP está precedido por una dirección IP, la dirección suele ser el enrutador que tiene el error de configuración MPLS. En este caso, parece que el enrutador con la lo0 dirección de (R3) tiene un error de configuración MPLS 192.168.4.1 .
Salida de muestra
Utilice el comando mostrar detalles de la sesión RSVP para mostrar información detallada sobre las sesiones RSVP.
user@R1> show rsvp session detail Ingress RSVP: 1 sessions 192.168.4.1 From: 192.168.1.1, LSPstate: Dn, ActiveRoute: 0 LSPname: gmpls-r1-to-r3, LSPpath: Primary Bidirectional, Upstream label in: 21253, Upstream label out: - Suggested label received: -, Suggested label sent: 21253 Recovery label received: -, Recovery label sent: - Resv style: 0 - , Label in: -, Label out: - Time left: -, Since: Wed Dec 20 18:07:53 2006 Tspec: rate 0bps size 0bps peak 155.52Mbps m 20 M 1500 Port number: sender 2 receiver 46115 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 0 PATH sentto: 10.35.1.5 (tester2) 3 pkts Explct route: 100.100.100.100 93.93.93.93 Record route: <self> ...incomplete Total 1 displayed, Up 0, Down 1 Egress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0
Significado
El resultado de ejemplo para el show rsvp session detail comando muestra que LSP gmpls-r1-to-r3 está inactivo (LSPstate: Dn). El registro de ruta está incompleto, lo que indica un problema con la ruta 100.100.100.100 93.93.93.93explícita. La dirección 100.100.100.100 es el canal de datos de R2 so-0/0/0, y la dirección 93.93.93.93 es el canal de datos de R3.
Salida de muestra
Utilice el comando show link-management peer para mostrar la información del vínculo del par MPLS.
user@R1> show link-management peer Peer name: tester2, System identifier: 48428 State: Up, Control address: 10.35.1.5 Control-channel State gre.0 Active TE links: tester2 user@R2> show link-management peer Peer name: tester2, System identifier: 48428 State: Up, Control address: 10.35.1.6 Control-channel State gre.0 Active TE links: te-tester2 Peer name: tester3 , System identifier: 48429 State: Up , Control address: 10.35.1.2 Control-channel State gre.1 Active TE links: te-tester3 user@R3> show link-management peer Peer name: tester3, System identifier: 48429 State: Up, Control address: 10.35.1.1 Control-channel State gre.0 Active TE links: te-tester3
Significado
La salida de ejemplo de todos los enrutadores en la red de ejemplo en Figura 13 para el show link-management peer comando muestra que todos los canales de control están activos y activos. Un análisis detallado de la salida muestra la siguiente información:
Nombre del par tester2 o tester3, que es el mismo en los enrutadores vecinos para facilitar la solución de problemas.
Identificador interno del par, 48428 para tester2 y 48429 para tester3. El identificador interno es un rango de valores del 0 al 64.000.
El estado del par, que puede estar arriba o abajo. En este caso, todos los compañeros están arriba.
La dirección en la que se establece un canal de control, por ejemplo, 10.35.1.5.
El estado del canal de control, que puede estar arriba, abajo o activo.
Los vínculos de ingeniería de tráfico administrados por su par, lo que indica que el canal gre.0 de control es administrado por tester3.
Salida de muestra
Utilice el comando show link-management te-link para mostrar los recursos usados para configurar rutas de reenvío diseñadas para el tráfico de conmutación de etiquetas multiprotocolo (MPLS).
user@R1> show link-management te-link
TE link name: tester2, State: Up
Local identifier: 2005, Remote identifier: 21253, Local address: 90.90.90.90, Remote address: 100.100.100.100,
Encoding: SDH/SONET, Switching: PSC-1, Minimum bandwidth: 155.52Mbps, Maximum bandwidth: 155.52Mbps, Total bandwidth: 155.52Mbps,
Available bandwidth: 0bps
Name State Local ID Remote ID Bandwidth Used LSP-name
so-0/0/0 Up 21253 21253 155.52Mbps Yes gmpls-r1-to-r3
user@R2> show link-management te-link
TE link name: te-tester2, State: Up
Local identifier: 7002, Remote identifier: 22292, Local address: 100.100.100.100, Remote address: 90.90.90.90,
Encoding: SDH/SONET, Switching: PSC-1, Minimum bandwidth: 155.52Mbps, Maximum bandwidth: 155.52Mbps, Total bandwidth: 155.52Mbps,
Available bandwidth: 0bps
Name State Local ID Remote ID Bandwidth Used LSP-name
so-0/0/0 Up 21253 21253 155.52Mbps Yes gmpls-r1-to-r3
TE link name: te-tester3, State: Up
Local identifier: 7003, Remote identifier: 21254, Local address: 103.103.103.103, Remote address: 93.93.93.93,
Encoding: SDH/SONET, Switching: PSC-1, Minimum bandwidth: 155.52Mbps, Maximum bandwidth: 155.52Mbps, Total bandwidth: 155.52Mbps,
Available bandwidth: 0bps
Name State Local ID Remote ID Bandwidth Used LSP-name
so-0/0/1 Up 21252 21252 155.52Mbps Yes gmpls-r1-to-r3
user@R3> show link-management te-link
TE link name: te-tester3, State: Up
Local identifier: 7003, Remote identifier: 21254, Local address: 93.93.93.93,
Remote address: 103.103.103.103,
Encoding: SDH/SONET, Switching: PSC-1, Minimum bandwidth: 0bps, Maximum bandwidth: 0bps, Total bandwidth: 0bps,
Available bandwidth: 0bps
Name State Local ID Remote ID Bandwidth Used LSP-name
so-0/0/1 Dn 21252 21252 155.52Mbps No
Significado
El resultado de ejemplo para el show link-management te-link comando emitido en los tres enrutadores de la red en Figura 13 muestra los recursos asignados a los vínculos te-tester2 de ingeniería de tráfico y te-tester3. Los recursos son las interfaces so-0/0/0 SONET y so-0/0/1. las interfaces On R1 y R2, tSONET se utilizan para el LSP gmpls-r1-to-r3, como se indica Yes en el Used campo.Sin embargo, la interfaz so-0/0/1 SONET activada está R3 inactiva (Dn) y no se utiliza para el LSP (Used No). Se requiere más investigación para descubrir por qué la interfaz SONET está inactiva R3 .
Muestra de salida
Utilice el comando show log filename para mostrar el contenido del archivo de registro especificado. En este caso, la rsvp.log del archivo de registro se configura en el nivel jerárquico [edit protocols rsvp traceoptions]. Cuando se configura el archivo de registro, debe emitir el comando de inicio filename del monitor para comenzar a registrar mensajes en el archivo.
user@R1> show configuration protocols rsvp
traceoptions {
file rsvp.log size 3m world-readable;
flag state detail;
flag error detail;
flag packets detail;
}
user@R1> monitor start rsvp.log
La find Error opción introducida después de la canalización ( | ) busca en la salida una instancia del término Error.
Salida de muestra
user@R3> show log rsvp.log | find Error Dec 28 17:23:32 Error Len 20 Session preempted flag 0 by 192.168.4.1 TE-link 103.103.103.103 [...Output truncated...] Dec 28 17:23:32 RSVP new resv state,session 192.168.4.1(port/tunnel ID 46115 Ext-ID 192.168.1.1)Proto 0 Dec 28 17:23:32 RSVP-LMP reset LMP request for gmpls-r1-to-r3 Dec 28 17:23:32 RSVP->LMP request - resource for LSP gmpls-r1-to-r3 Dec 28 17:23:32 LMP->RSVP resource request gmpls-r1-to-r3 failed cannot find resource encoding type SDH/SONET remote label 21252 bandwidth bw[0 Dec 28 17:23:32 RSVP-LMP reset LMP request for gmpls-r1-to-r3 Dec 28 17:23:32 RSVP originate PathErr 192.168.4.1->192.168.2.1 MPLS label allocation failure LSP gmpls-r1-to-r3(2/46115) Dec 28 17:23:32 RSVP send PathErr 192.168.4.1->192.168.2.1 Len=196 tester3 Dec 28 17:23:32 Session7 Len 16 192.168.4.1(port/tunnel ID 46115 Ext-ID 192.168.1.1) Proto 0 Dec 28 17:23:32 Hop Len 20 192.168.4.1/0x086e4770 TE-link 103.103.103.103 Dec 28 17:23:32 Error Len 20 MPLS label allocation failure flag 0 by 192.168.4.1 TE-link 103.103.103.103 Dec 28 17:23:32 Sender7 Len 12 192.168.1.1(port/lsp ID 2) Dec 28 17:23:32 Tspec Len 36 rate 0bps size 0bps peak 155.52Mbps m 20 M 1500 Dec 28 17:23:32 ADspec Len 48 MTU 1500 Dec 28 17:23:32 RecRoute Len 20 103.103.103.103 90.90.90.90 Dec 28 17:23:32 SuggLabel Len 8 21252 Dec 28 17:23:32 UpstrLabel Len 8 21252
Significado
La salida de ejemplo del enrutador R3 de salida para el show log rsvp.log comando es un fragmento tomado del archivo de registro. El fragmento muestra una solicitud de recurso de protocolo de administración de vínculos (LMP) para el LSP gmpls-r1-to-r3. La solicitud tiene problemas con el tipo de codificación (SDH/SONET), lo que indica un posible error con la interfaz SONET que conecta R2 y R3. Se requiere más investigación de la configuración del LMP en R2 y R3 se requiere.
Salida de muestra
Utilice el comando show configuration statement-path para mostrar una jerarquía de configuración específica; en este caso, administración de vínculos.
user@R2> show configuration protocols link-management
te-link te-tester2 {
local-address 100.100.100.100;
remote-address 90.90.90.90;
remote-id 22292;
interface so-0/0/0 {
local-address 100.100.100.100;
remote-address 90.90.90.90;
remote-id 21253;
}
}
te-link te-tester3 {
local-address 103.103.103.103;
remote-address 93.93.93.93;
remote-id 21254;
interface so-0/0/1 {
local-address 103.103.103.103;
remote-address 93.93.93.93;
remote-id 21252;
}
}
peer tester2 {
address 10.35.1.6;
control-channel gre.0;
te-link te-tester2;
}
peer tester3 {
address 10.35.1.2;
control-channel gre.1;
te-link te-tester3;
}
user@R3> show configuration protocols link-management
te-link te-tester3 {
local-address 93.93.93.93;
remote-address 103.103.103.103;
remote-id 21254;
}
interface at-0/3/1 {
local-address 93.93.93.93;
remote-address 103.103.103.103;
remote-id 21252;
}
}
peer tester3 {
address 10.35.1.1;
control-channel gre.0;
te-link te-tester3;
}
Significado
La salida de ejemplo del enrutador R2 de tránsito y del enrutador R3 de entrada para el show configuration protocols link-management comando muestra que el tipo de interfaz en los dos enrutadores es diferente. El recurso asignado al enrutador R2 en te-tester3 tránsito es una interfaz SONET, mientras que el recurso asignado al te-tester3 enrutador R3 de salida es una interfaz ATM. El tipo de interfaz en cada extremo de los canales de datos o control debe ser del mismo tipo. En este caso, ambos extremos deben ser SONET o ATM.
Solución
- Solución
- Salida de muestra
- Significado
- Conclusión
- Configuraciones del enrutador
- Salida de muestra
- Salida de muestra
- Salida de muestra
Solución
La solución al problema de diferentes tipos de interfaz o encapsulación en cada extremo del LGP GMPLS es asegurarse de que el tipo de interfaz sea el mismo en ambos extremos. En este caso, la interfaz ATM se eliminó de la configuración de administración de vínculos en R3, y en su lugar se configuró una interfaz SONET.
Los siguientes comandos ilustran la configuración correcta y los comandos para comprobar que el LSP de GMPLS está activo y utilizando el canal de datos:
user@R3> show configuration protocols link-management user@R3> show mpls lsp user@R3> show link-management te-link
Salida de muestra
user@R3> show configuration protocols link-management
te-link te-tester3 {
local-address 93.93.93.93;
remote-address 103.103.103.103;
remote-id 21254;
interface so-0/0/1 { # SONET interface replaces the incorrect ATM interface
local-address 93.93.93.93;
remote-address 103.103.103.103;
remote-id 21252;
}
}
peer tester3 {
address 10.35.1.1;
control-channel gre.0;
te-link te-tester3;
}
user@R3> show mpls lsp
Ingress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Egress LSP: 1 sessions
To From State Rt Style Labelin Labelout LSPname
192.168.4.1 192.168.1.1 Up 0 1 FF 21252 - gmpls-r1-to-r3
Bidir
Total 1 displayed, Up 1, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
user@R3> show link-management te-link
TE link name: te-tester3, State: Up
Local identifier: 7003, Remote identifier: 21254, Local address: 93.93.93.93, Remote address: 103.103.103.103,
Encoding: SDH/SONET, Switching: PSC-1, Minimum bandwidth: 155.52Mbps, Maximum bandwidth: 155.52Mbps, Total bandwidth: 155.52Mbps,
Available bandwidth: 0bps
Name State Local ID Remote ID Bandwidth Used LSP-name
so-0/0/1 Up 21252 21252 155.52Mbps Yes gmpls-r1-to-r3Significado
La salida de ejemplo para los comandos , show mpls lsp, y show link-management te-link del show protocols link-managementenrutador R3 de entrada muestra que el problema está resuelto. LMP está configurado correctamente, y el LSP gmpls-r1-to-r3 está activo y utilizando el canal so-0/0/1de datos.
Conclusión
En conclusión, ambos extremos de un canal de datos GMPLS deben tener la misma encapsulación o tipo de interfaz. Este caso ilustra la configuración correcta del canal de datos. Los principios son los mismos para el canal de control.
Configuraciones del enrutador
Salida que muestra las configuraciones del enrutador de entrada en la red. La no-more opción introducida después de la canalización ( | ) impide que la salida se pagina si la salida es más larga que la longitud de la pantalla del terminal.
Salida de muestra
La siguiente salida de ejemplo es para el enrutador de entrada R1:
user@R1> show configuration | no-more
[...Output truncated...]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.0.12.1/32 {
destination 10.0.12.2;
}
}
family mpls;
}
}
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.12.13/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.143/21;
}
}
}
gre {
unit 0 {
tunnel {
source 10.0.12.13;
destination 10.0.12.14;
}
family inet {
address 10.35.1.6/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.1/32;
}
}
}
}
routing-options {
static {
/* corporate and alpha net */
route 172.16.0.0/12 {
next-hop 192.168.71.254;
retain;
no-readvertise;
}
/* old lab nets */
route 192.168.0.0/16 {
next-hop 192.168.71.254;
retain;
no-readvertise;
}
route 0.0.0.0/0 {
discard;
retain;
no-readvertise;
}
}
router-id 192.168.1.1;
autonomous-system 65432;
}
protocols {
rsvp {
traceoptions {
file rsvp.log size 3m world-readable;
flag state detail;
flag error detail;
flag packets detail;
}
interface fxp0.0 {
disable;
}
interface all;
interface lo0.0;
interface gre.0 {
disable;
}
peer-interface tester2;
}
mpls {
label-switched-path gmpls-r1-to-r3 {
from 192.168.1.1;
to 192.168.4.1;
lsp-attributes {
switching-type psc-1;
encoding-type sonet-sdh;
}
no-cspf;
primary p1;
}
path p1 {
100.100.100.100 strict;
93.93.93.93 strict;
}
interface all;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0;
interface fe-0/1/0.0;
interface fxp0.0 {
disable;
}
interface gre.0 {
disable;
}
peer-interface tester2;
}
}
link-management {
te-link tester2 {
local-address 90.90.90.90;
remote-address 100.100.100.100;
remote-id 21253;
interface so-0/0/0 {
local-address 90.90.90.90;
remote-address 100.100.100.100;
remote-id 21253;
}
}
peer tester2 {
address 10.35.1.5;
control-channel gre.0;
te-link tester2;
}
}
}
Salida de muestra
El siguiente resultado de ejemplo es para el enrutador de tránsito R2:
user@R2>show configuration | no-more
[...Output truncated...]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.0.12.2/32 {
destination 10.0.12.1;
}
}
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.0.24.1/32 {
destination 10.0.24.2;
}
}
family mpls;
}
}
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.12.14/30;
}
family mpls;
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.24.13/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.144/21;
}
}
}
gre {
unit 0 {
tunnel {
source 10.0.12.14;
destination 10.0.12.13;
}
family inet {
address 10.35.1.5/30;
}
family mpls;
}
unit 1 {
tunnel {
source 10.0.24.13;
destination 10.0.24.14;
}
family inet {
address 10.35.1.1/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.2.1/32;
}
}
}
}
routing-options {
static {
route 172.16.0.0/12 {
next-hop 192.168.71.254;
retain;
no-readvertise;
}
route 192.168.0.0/16 {
next-hop 192.168.71.254;
retain;
no-readvertise;
}
route 0.0.0.0/0 {
discard;
retain;
no-readvertise;
}
}
router-id 192.168.2.1;
autonomous-system 65432;
}
protocols {
rsvp {
traceoptions {
file rsvp.log size 3m world-readable;
flag packets detail;
flag state detail;
flag error detail;
}
interface fxp0.0;
interface lo0.0;
interface all;
interface gre.0 {
disable;
}
peer-interface tester2;
peer-interface tester3;
}
mpls {
interface all;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0;
interface fxp0.0 {
disable;
}
interface gre.0 {
disable;
}
interface fe-0/1/0.0;
interface fe-0/1/2.0;
interface gre.1 {
disable;
}
peer-interface tester2;
peer-interface tester3;
}
}
link-management {
te-link te-tester2 {
local-address 100.100.100.100;
remote-address 90.90.90.90;
remote-id 22292;
interface so-0/0/0 {
local-address 100.100.100.100;
remote-address 90.90.90.90;
remote-id 21253;
}
}
te-link te-tester3 {
local-address 103.103.103.103;
remote-address 93.93.93.93;
remote-id 21254;
interface so-0/0/1 {
local-address 103.103.103.103;
remote-address 93.93.93.93;
remote-id 21252;
}
}
peer tester2 {
address 10.35.1.6;
control-channel gre.0;
te-link te-tester2;
}
peer tester3 {
address 10.35.1.2;
control-channel gre.1;
te-link te-tester3;
}
}
}
Salida de muestra
La siguiente salida de ejemplo es para el enrutador de salida R3:
user@R3> show configuration | no-more
[...Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.0.24.2/32;
}
family mpls;
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.24.14/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.146/21;
}
}
}
gre {
unit 0 {
tunnel {
source 10.0.24.14;
destination 10.0.24.13;
}
family inet {
address 10.35.1.2/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.4.1/32;
}
}
}
}
routing-options {
static {
route 172.16.0.0/12 {
next-hop 192.168.71.254;
retain;
no-readvertise;
}
route 192.168.0.0/16 {
next-hop 192.168.71.254;
retain;
no-readvertise;
}
route 0.0.0.0/0 {
discard;
retain;
no-readvertise;
}
}
router-id 192.168.4.1;
autonomous-system 65432;
}
protocols {
rsvp {
traceoptions {
file rsvp.log size 3m world-readable;
flag packets detail;
flag error;
flag state;
flag lmp;
}
interface fxp0.0 {
disable;
}
interface all;
interface lo0.0;
interface gre.0 {
disable;
}
peer-interface tester3;
}
mpls {
interface all;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface fe-0/1/2.0;
interface gre.0 {
disable;
}
interface lo0.0;
peer-interface tester3;
}
}
link-management {
te-link te-tester3 {
local-address 93.93.93.93;
remote-address 103.103.103.103;
remote-id 21254;
interface so-0/0/1 {
local-address 93.93.93.93;
remote-address 103.103.103.103;
remote-id 21252;
}
}
peer tester3 {
address 10.35.1.1;
control-channel gre.0;
te-link te-tester3;
}
}
}
Determinación del estado de LSP
Muestra información detallada sobre los objetos del Protocolo de reserva de recursos (RSVP) y el historial de rutas de conmutación de etiquetas (LSP) para identificar un problema con el LSP.
Figura 14 Muestra la topología de red utilizada en este tema.
Para determinar el estado de LSP, siga estos pasos:
Comprobar el estado del LSP
Propósito
Muestra el estado del dispositivo conmutado por etiquetas (LSP).
Acción
Para determinar el estado del LSP, en el enrutador de entrada, escriba el siguiente comando de modo operativo de la interfaz de línea de comandos (CLI) de Junos OS:
user@host> show mpls lsp
Salida de muestra
nombre-comando
user@R1> show mpls lsp Ingress LSP: 1 sessions To From State Rt ActivePath P LSPname 10.0.0.6 10.0.0.1 Up 1 * R1-to-R6 Total 1 displayed, Up 1, Down 0 Egress LSP: 1 sessions To From State Rt Style Labelin Labelout LSPname 10.0.0.1 10.0.0.6 Up 0 1 FF 3 - R6-to-R1 Total 1 displayed, Up 1, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
Significado
La salida de ejemplo procede del enrutador de entrada (R1) y muestra información de LSP de entrada, salida y tránsito. La información de entrada es para las sesiones que se originan en este enrutador, la información de salida es para las sesiones que terminan en este enrutador y la información de tránsito es para las sesiones que transitan por este enrutador.
Hay una ruta de entrada de R1 (10.0.0.1) a R6 (10.0.0.6). Esta ruta está actualmente activa y es una ruta activa instalada en la tabla de enrutamiento (Rt). El LSP R1-to-R6 es la ruta principal (P) en contraposición a la ruta secundaria, y se indica con un asterisco (*). La ruta a R6 no contiene una ruta con nombre (ActivePath).
Hay un LSP de salida de R6 a R1. El State está activo, sin rutas instaladas en la tabla de enrutamiento. El estilo de reserva RSVP (Style) consta de dos partes. El primero es el número de reservas activas (1). El segundo es el estilo de reserva, que es FF (filtro fijo). El estilo de reserva puede ser FF, SE (explícito compartido) o WF (filtro comodín). Hay tres etiquetas entrantes (Labelin) y ninguna etiqueta que salga (Labelout) para este LSP.
No hay LSP de tránsito.
Para obtener más información sobre cómo comprobar el estado de LSP, consulte Lista de comprobación para trabajar con el modelo de solución de problemas de MPLS en capas.
Mostrar un estado extenso sobre el LSP
Propósito
Muestre amplia información sobre los LSP, incluida toda la historia pasada del estado y las razones por las que un LSP podría haber fallado.
Acción
Para mostrar amplia información acerca de los LSP, en el enrutador de entrada, introduzca el siguiente comando de modo operativo de la CLI de Junos OS:
user@host> show mpls lsp extensive
Salida de muestra
nombre-comando
user@R1> show mpls lsp extensive
Ingress LSP: 1 sessions
10.0.0.6
From: 10.0.0.1, State: Up , ActiveRoute: 1 , LSPname: R1-to-R6
ActivePath: (primary)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20)
10.1.13.2 S 10.1.36.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.1.13.2 10.1.36.2
91 Aug 17 12:22:52 Selected as active path
90 Aug 17 12:22:52 Record Route: 10.1.13.2 10.1.36.2
89 Aug 17 12:22:52 Up
88 Aug 17 12:22:52 Originate Call
87 Aug 17 12:22:52 CSPF: computation result accepted
86 Aug 17 12:22:23 CSPF failed: no route toward 10.0.0.6[13920 times]
85 Aug 12 19:12:51 Clear Call
84 Aug 12 19:12:50 10.1.56.2: MPLS label allocation failure
83 Aug 12 19:12:47 Deselected as active
82 Aug 12 19:12:47 10.1.56.2: MPLS label allocation failure
81 Aug 12 19:12:47 ResvTear received
80 Aug 12 19:12:47 Down
79 Aug 12 19:12:31 10.1.56.2: MPLS label allocation failure[4 times]
78 Aug 12 19:09:58 Selected as active path
77 Aug 12 19:09:58 Record Route: 10.1.15.2 10.1.56.2
76 Aug 12 19:09:58 Up
75 Aug 12 19:09:57 Originate Call
74 Aug 12 19:09:57 CSPF: computation result accepted
73 Aug 12 19:09:29 CSPF failed: no route toward 10.0.0.6[11 times]
72 Aug 12 19:04:36 Clear Call
71 Aug 12 19:04:23 Deselected as active
70 Aug 12 19:04:23 ResvTear received
69 Aug 12 19:04:23 Down
68 Aug 12 19:04:23 CSPF failed: no route toward 10.0.0.6
67 Aug 12 19:04:23 10.1.15.2: Session preempted
66 Aug 12 16:45:35 Record Route: 10.1.15.2 10.1.56.2
65 Aug 12 16:45:35 Up
64 Aug 12 16:45:35 Clear Call
63 Aug 12 16:45:35 CSPF: computation result accepted
62 Aug 12 16:45:35 ResvTear received
61 Aug 12 16:45:35 Down
60 Aug 12 16:45:35 10.1.13.2: Session preempted
59 Aug 12 14:50:52 Selected as active path
58 Aug 12 14:50:52 Record Route: 10.1.13.2 10.1.36.2
57 Aug 12 14:50:52 Up
56 Aug 12 14:50:52 Originate Call
55 Aug 12 14:50:52 CSPF: computation result accepted
54 Aug 12 14:50:23 CSPF failed: no route toward 10.0.0.6[7 times]
53 Aug 12 14:47:22 Deselected as active
52 Aug 12 14:47:22 CSPF failed: no route toward 10.0.0.6
51 Aug 12 14:47:22 Clear Call
50 Aug 12 14:47:22 CSPF: link down/deleted 10.1.12.1(R1.00/10.0.0.1)->10.1.12.2(R2.00/10.0.0.2)
49 Aug 12 14:47:22 CSPF: link down/deleted 10.1.15.1(R1.00/10.0.0.1)->10.1.15.2(R5.00/10.0.0.5)
48 Aug 12 14:47:22 10.1.15.1: MPLS label allocation failure
47 Aug 12 14:47:22 Clear Call
46 Aug 12 14:47:22 CSPF: computation result accepted
45 Aug 12 14:47:22 10.1.12.1: MPLS label allocation failure
44 Aug 12 14:47:22 MPLS label allocation failure
43 Aug 12 14:47:22 Down
42 Jul 23 11:27:21 Selected as active path
Created: Sat Jul 10 18:18:44 2004
Total 1 displayed, Up 1, Down 0
Egress LSP: 1 sessions
10.0.0.1
From: 10.0.0.6, LSPstate: Up , ActiveRoute: 0
LSPname: R6-to-R1 , LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 FF , Label in: 3 , Label out: -
Time left: 141, Since: Tue Aug 17 12:23:14 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 39024 protocol 0
PATH rcvfrom: 10.1.15.2 (so-0/0/1.0) 130 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.1.56.2 10.1.15.2 <self>
Total 1 displayed, Up 1, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Significado
El resultado de ejemplo procede del enrutador de entrada (R1) y muestra detalladamente la información de LSP de entrada, salida y tránsito, incluidos todos los antecedentes de estado y los motivos por los que se produjo un error en un LSP. La información de entrada es para las sesiones que se originan en este enrutador, la información de salida es para las sesiones que terminan en este enrutador y la información de tránsito es para las sesiones que transitan por este enrutador.
Hay una ruta de entrada de R1 (10.0.0.1) a R6 (10.0.0.6). Esta ruta está actualmente activa (State), con una ruta que utiliza activamente el LSP, R1-to-R6. La ruta activa de LSP es la ruta principal. Incluso si el LSP no contiene una primary palabra clave o secondary , el enrutador sigue tratando al LSP como un LSP primario, lo que indica que si el LSP falla, el enrutador intentará señalar los LSP inactivos a intervalos de 30 segundos, de forma predeterminada.
El equilibrio de carga es Random, que es el valor predeterminado, lo que indica que al seleccionar la ruta física para un LSP, el enrutador selecciona aleatoriamente entre rutas de igual costo que tienen un recuento de saltos igual. Otras opciones que puede configurar son Least-fill y Most-fill. Least-fill coloca el LSP sobre el vínculo menos utilizado de las rutas de igual costo con igual número de saltos. Most-fill coloca el LSP sobre el vínculo más utilizado de las rutas de igual costo que comparten un recuento de saltos iguales. La utilización se basa en el porcentaje de ancho de banda disponible.
El Encoding type campo muestra los parámetros de señalización de MPLS generalizada (GMPLS) (Packet), lo que indica IPv4. El Switching type es Packet, y el identificador de carga generalizada (GPID) es IPv4.
La ruta principal es la ruta activa, como lo indica un asterisco (*). El estado del LSP es Up.
El objeto de ruta explícita (ERO) incluye el costo () de la ruta de acceso más corta restringida primero (20CSPF) para la ruta física que sigue el LSP. La presencia de la métrica CSPF indica que se trata de un LSP de CSPF. La ausencia de la métrica CSPF indica un LSP sin CSPF.
El campo 10.1.13.2 S indica la ERO real. Los mensajes de señalización RSVP fueron a 10.1.13.2 estrictamente (como un siguiente salto) y terminaron en 10.1.36.2 estrictamente. Todas las direcciones ERO son saltos estrictos cuando el LSP es un LSP CSPF. Los saltos sueltos solo se pueden mostrar en un LSP sin CSPF.
El objeto de ruta de registro (RRO) recibido tiene los siguientes indicadores de protección:
0x01—Protección local disponible. El vínculo descendente de este nodo está protegido por un mecanismo de reparación local. Este indicador sólo se puede establecer si el indicador de protección local se estableció en el objeto SESSION_ATTRIBUTE del mensaje de ruta correspondiente.
0x02—Protección local en uso. Se utiliza un mecanismo de reparación local para mantener este túnel (generalmente debido a una interrupción del enlace sobre el que se enrutó anteriormente).
0x04— Protección del ancho de banda. El enrutador descendente tiene una ruta de respaldo que proporciona la misma garantía de ancho de banda que el LSP protegido para la sección protegida.
0x08—Protección de nodos. El enrutador descendente tiene una ruta de respaldo que proporciona protección contra fallas de vínculo y nodo en la sección de ruta correspondiente. Si el enrutador descendente solo puede configurar una ruta de respaldo de protección de enlaces, se establece el bit "Protección local disponible", pero se borra el bit "Protección del nodo".
0x10—Pendiente de preferencia. El nodo preferencia establece este indicador si hay una preferencia pendiente en curso para el LSP de ingeniería de tráfico. Esto indica al enrutador de borde de etiqueta de entrada (LER) de este LSP que se debe reenrutar.
Para obtener más información acerca de los indicadores de protección, consulte la Referencia de comandos de protocolos y políticas de enrutamiento de Junos.
El campo 10.1.13.2.10.1.36.2 es la ruta real del registro recibido (RRO). Tenga en cuenta que las direcciones del RRO campo coinciden con las ERO del campo. Este es el caso normal de los LSP de CSPF. Si las direcciones RRO y ERO no coinciden con un LSP de CSPF, el LSP tiene que desviarse o desviarse.
Las líneas numeradas del 91 al 42 contienen las 49 entradas más recientes en el registro histórico. Cada línea tiene una marca de tiempo. Las entradas más recientes tienen el número de historial de registro más grande y se encuentran en la parte superior del registro, lo que indica que la línea 91 es la entrada de registro de historial más reciente. Cuando lea el registro, comience con la entrada más antigua (42) a la más reciente (91).
El registro del historial se inició el 10 de julio y muestra la siguiente secuencia de actividades: se seleccionó un LSP como activo, se encontró que estaba inactivo, se produjo un error en la asignación de etiquetas MPLS varias veces, se eliminó varias veces, se tuvo preferencia debido a un ResvTear, se anuló la selección como activo y se borró. Al final, el enrutador calculó un ERO CSPF, señaló la llamada, el LSP obtuvo el RRO listado (línea 90) y fue listado como activo.
Para obtener más información acerca de los mensajes de error, consulte la Referencia del registro de la Guía de operaciones de red MPLS de Junos.
El número total de LSP de entrada mostrados es 1, con 1 arriba y 0 abajo. El número del Up campo más el número del Down campo debe ser igual al total.
Hay una sesión LSP de salida de R6 a R1. El State está activo, sin rutas instaladas en la tabla de enrutamiento. El estilo de reserva RSVP (Style) consta de dos partes. El primero es el número de reservas activas (1). El segundo es el estilo de reserva, que es FF (filtro fijo). El estilo de reserva puede ser FF, SE (explícito compartido) o WF (filtro comodín). Hay tres etiquetas entrantes (Labelin) y ninguna etiqueta que salga (Labelout) para este LSP.
No hay LSP de tránsito.
Para obtener más información sobre cómo comprobar el estado de LSP, consulte Lista de comprobación para trabajar con el modelo de solución de problemas de MPLS en capas.
Comprobar que los mensajes de ruta RSVP se envían y reciben
Propósito
La presencia o ausencia de varios mensajes RSVP puede ayudar a determinar si hay un problema con la conmutación de etiquetas multiprotocolo (MPLS) en la red. Por ejemplo, si se producen mensajes de ruta de acceso en la salida sin mensajes ReSV, podría indicar que no se están creando rutas de conmutación de etiquetas (LSP).
Acción
Para comprobar que los mensajes de ruta RSVP se envían y reciben, escriba el siguiente comando de modo operativo de la interfaz de línea de comandos (CLI) de Junos OS:
user@host> show rsvp statistics
Salida de muestra
nombre-comando
user@R1> show rsvp statistics
PacketType Total Last 5 seconds
Sent Received Sent Received
Path 114523 80185 1 0
PathErr 5 10 0 0
PathTear 12 6 0 0
Resv FF 80515 111476 0 0
Resv WF 0 0 0 0
Resv SE 0 0 0 0
ResvErr 0 0 0 0
ResvTear 0 5 0 0
ResvConf 0 0 0 0
Ack 0 0 0 0
SRefresh 0 0 0 0
Hello 915851 915881 0 0
EndtoEnd RSVP 0 0 0 0
Errors Total Last 5 seconds
Rcv pkt bad length 0 0
Rcv pkt unknown type 0 0
Rcv pkt bad version 0 0
Rcv pkt auth fail 0 0
Rcv pkt bad checksum 0 0
Rcv pkt bad format 0 0
Memory allocation fail 0 0
No path information 0 0
Resv style conflict 0 0
Port conflict 0 0
Resv no interface 0 0
PathErr to client 15 0
ResvErr to client 0 0
Path timeout 0 0
Resv timeout 0 0
Message out-of-order 0 0
Unknown ack msg 0 0
Recv nack 0 0
Recv duplicated msg-id 0 0
No TE-link to recv Hop 0 0
Significado
El resultado de ejemplo muestra los mensajes RSVP enviados y recibidos. El número total de mensajes de ruta RSVP es de 11.4532 enviados y 80.185 recibidos. En los últimos 5 segundos, no se ha enviado ni recibido ningún mensaje.
Se enviaron un total de 5 PathErr mensajes y se recibieron 10. Cuando se producen errores de ruta de acceso (normalmente debido a problemas de parámetros en un mensaje de ruta de acceso), el enrutador envía un mensaje PathErr de unidifusión al remitente que emitió el mensaje de ruta de acceso. En este caso, R1 envió al menos 10 mensajes de ruta con un error, como lo indican los 10 mensajes PathErr que R1 ha recibido. El enrutador descendente envió R1 cinco mensajes de ruta con un error, como lo indican los cinco mensajes PathErr que R1 ha enviado. Los mensajes de PathErr se transmiten en la dirección opuesta a los mensajes de ruta de acceso.
Se enviaron un total de 12 PathTear mensajes y se recibieron 6, ninguno en los últimos 5 segundos. A diferencia de los mensajes de PathErr, los mensajes de PathTear viajan en la misma dirección que los mensajes de ruta. Dado que los mensajes de ruta se envían y reciben, los mensajes de PathTear también se envían y reciben. Sin embargo, si solo se envían mensajes de ruta de acceso, solo aparecen en la salida los mensajes PathTear que se envían.
Se enviaron un total de 80.515 mensajes de reserva (Resv) con el estilo de reserva de filtro fijo (FF) y se recibieron 111.476, ninguno en los últimos 5 segundos. Un estilo de FF reserva indica que dentro de cada sesión, cada receptor establece su propia reserva con cada remitente ascendente y que se enumeran todos los remitentes seleccionados. No se envían ni reciben mensajes para el filtro comodín (WF) o los estilos de reserva explícitos compartidos (SE). Para obtener más información sobre los estilos de reserva de RSVP, consulte la Guía de configuración de aplicaciones MPLS de Junos.
Otros tipos de mensajes RSVP no se envían ni se reciben. Para obtener información sobre los tipos de mensaje ResvErr, ResvTear y Resvconf, consulte la Guía de configuración de aplicaciones MPLS de Junos.
Los mensajes Ack y de actualización de resumen (SRefresh) no aparecen en el resultado. Los mensajes de actualización de resumen y Ack se definen en RFC 2961 y forman parte de las extensiones RSVP. Los mensajes Ack se utilizan para reducir la cantidad de tráfico de control RSVP en la red.
Se enviaron un total de 915.851 mensajes de saludo y se recibieron 915.881, y ninguno se transmitió o recibió en los últimos 5 segundos. El intervalo de saludo RSVP es de 9 segundos. Si se envía o recibe más de un mensaje de saludo en los últimos 5 segundos, implica que más de una interfaz admite RSVP.
EndtoEnd Los mensajes RSVP son mensajes RSVP heredados que no se utilizan para la ingeniería de tráfico RSVP. Estos contadores solo se incrementan cuando RSVP reenvía mensajes RSVP heredados emitidos por un cliente de red privada virtual (VPN) para su tránsito a través de la red troncal a los otros sitios de la VPN. Se llaman mensajes de extremo a extremo porque están destinados al lado opuesto de la red y solo tienen significado en los dos extremos de la red del proveedor.
La Errors sección de la salida muestra estadísticas sobre paquetes RSVP con errores. Se enviaron un total de 15 PathErr to client paquetes al motor de enrutamiento. El total combina los paquetes enviados y recibidos PathErr .