Solución de problemas de MPLS
Verificar interfaces MPLS
Propósito
Si el protocolo MPLS no está configurado correctamente en los enrutadores de su red, las interfaces no pueden realizar conmutación MPLS.
Para que una ruta etiquetada se resuelva a través de una interfaz, family mpls debe configurarse en el [edit interfaces] nivel de 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 verificar las interfaces MPLS, escriba el siguiente comando de modo operativo de interfaz de línea de comandos (CLI) de Junos OS:
user@host> show mpls interface
Salida de muestra 1
nombre de comando
La siguiente salida 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>
Salida de muestra 2
nombre de 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
Salida de muestra 3
nombre de comando
user@host> show mpls interface MPLS not configured
Significado
La salida de ejemplo 1 muestra que todas las interfaces MPLS de todos los enrutadores de la red están habilitadas (Up) y pueden realizar conmutación MPLS. Si no se puede configurar la interfaz correcta en el nivel de jerarquía [edit protocols mpls] o si 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 conmutación MPLS y no aparece en la salida 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 así fuera, el resultado indicaría qué bits de clase de afinidad están habilitados en el enrutador.
La salida de ejemplo 2 muestra que falta una interfaz so-0/0/2.0 y, por lo tanto, puede 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 el RSVP aún no haya señaldo a través de esta interfaz. Para obtener más información sobre cómo determinar qué interfaz está configurada incorrectamente, consulte Verificar familias de protocolos.
La salida 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 MPLS habilitada, no puede realizar 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 comprobar las familias de protocolos configuradas en los enrutadores de la red, escriba el siguiente comando de modo operativo de CLI de Junos OS:
user@host> show interfaces terse
Salida de muestra 1
nombre de 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
Salida de muestra 2
nombre de 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
La salida 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 de 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].
Verificar la configuración de MPLS
Propósito
Después de comprobar el tránsito y los enrutadores de entrada, utilice el traceroute comando para comprobar el siguiente salto del BGP y el ping comando para comprobar la ruta activa, puede comprobar si hay problemas con la configuración de MPLS en los [edit protocols mpls] niveles de jerarquía y [edit interfaces] .
Para que una ruta etiquetada se resuelva a través de una interfaz, family mpls debe configurarse en el [edit interfaces] nivel de 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, escriba los siguientes comandos desde los enrutadores de entrada, tránsito y salida:
user@host> show configuration protocols mpls user@host> show configuration interfaces
Salida de muestra 1
nombre de 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
Salida de muestra 2
nombre de 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
La salida de ejemplo 1 de los enrutadores de entrada, tránsito y salida muestra que la configuración de 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.
La salida de ejemplo 2 muestra que las interfaces están correctamente configuradas para MPLS en el enrutador R6de salida. Las interfaces también están correctamente configuradas en los enrutadores de entrada y tránsito (no se muestran).
Comprobación de la capa MPLS
Propósito
Después de configurar la ruta de conmutación de etiquetas (LSP), se emitió el show mpls lsp comando y se determinó que hay un error, es posible que encuentre que el error no se encuentra en las capas física, 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 por capas.
Con la capa MPLS, comprueba si el LSP está funcionando correctamente. Si la red no funciona en esta capa, el LSP no funciona como configurado.
Figura 2 ilustra la red MPLS utilizada en este tema.
La red que se muestra en es una configuración completamente mallada en Figura 2 la que cada interfaz conectada directamente puede recibir y enviar paquetes a cualquier otra interfaz similar. El LSP de esta red está configurado para que se ejecute desde el enrutador de entrada, a través del enrutador R1de tránsito, al enrutador R3R6de salida. Además, un LSP inverso está configurado para ejecutarse desde R6 el a través R3 hasta R1, creando tráfico bidireccional.
Sin embargo, en este ejemplo, el LSP inverso está caído sin una ruta de R6 a R1.
La cruz que se muestra en Figura 2 indica dónde está roto el LSP. Algunas posibles razones por las que el LSP está roto pueden incluir un protocolo MPLS configurado incorrectamente o interfaces que están configuradas incorrectamente para MPLS.
En la red que se muestra en Figura 2, un error de configuración en el enrutador R6 de salida impide que el LSP transite por la red como se esperaba.
Para comprobar la capa MPLS, siga estos pasos:
- Verificar 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 adecuadas
- Verificar el LSP de nuevo
Verificar el LSP
Propósito
Normalmente, se usa el show mpls lsp extensive comando para comprobar el LSP. Sin embargo, para verificar rápidamente el estado del LSP, utilice el show mpls lsp comando. Si el LSP está inactivo, utilice la extensive opción (show mpls lsp extensive) como seguimiento. Si su red tiene varios LSP, podría considerar especificar el nombre del LSP, utilizando 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 comandos siguientes 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
Salida de muestra 1
nombre de 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
Salida de muestra 2
nombre de 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
Salida de muestra 3
nombre de 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
Salida de muestra 4
nombre de 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
La salida 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 de entrada y del enrutador R1 de salida muestra que ambos LSP están caídos y R6-toR1R1-to-R6 .R6 Con los LSP configurados y R1R6, esperaríamos sesiones de LSP de salida en ambos R1 y R6. Además, el enrutador R3 de tránsito no tiene sesiones de tránsito.
La salida de ejemplo 2 muestra toda la información sobre los LSP, incluyendo todo el historial de estado pasado y la razón por la que un LSP falló. La salida desde R1 e R6 indica que no hay ninguna ruta al destino porque el algoritmo de primera ruta más corta restringida (CSPF) falló.
Los resultados de ejemplo 3 y 4 muestran ejemplos de la salida para el show mpls lsp name comando con la extensive opción. En este caso, el resultado es muy similar al show mpls lsp comando, ya que solo 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 muy diferentes entre los dos comandos.
Verificar la ruta LSP en el enrutador de tránsito
Propósito
Si el LSP está activo, la ruta LSP debería aparecer en la tabla de mpls.0 enrutamiento. MPLS mantiene una tabla de enrutamiento de rutas MPLS (mpls.0), que contiene una lista del siguiente enrutador conmutado por etiqueta en cada LSP. Esta tabla de enrutamiento se utiliza en enrutadores de tránsito para enrutar paquetes al enrutador siguiente 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 comando siguiente desde el enrutador de tránsito:
user@host> show route table mpls.0
Salida de muestra 1
nombre de 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
Salida de muestra 2
nombre de 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 verificación para verificar el uso de LSP.
Por el contrario, la salida de muestra 2 muestra las etiquetas y rutas MPLS para un LSP correctamente configurado. 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, ya que los valores de la pila en el encabezado MPLS pueden ser diferentes. Para cada ruta, la segunda entrada 100864 (S=0)100880 (S=0) indica que la profundidad de la pila no es 1, y que se incluyen valores de etiqueta adicionales en el paquete. Por el contrario, la primera entrada 100864100880 tiene un valor S=1 inferido que indica una profundidad de pila de 1 y convierte a cada etiqueta en la última etiqueta de 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 inet.3 tabla de 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
Salida de muestra 1
nombre de 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
Salida de muestra 2
nombre de 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 las entradas solo en la tabla de inet.0 enrutamiento. La inet.3 tabla de enrutamiento no está en la salida porque el LSP no funciona. La inet.0 tabla de enrutamiento es utilizada por los protocolos de puerta de enlace interior (IGP) y el protocolo de puerta de enlace de borde (BGP) para almacenar la información de enrutamiento. En este caso, el IGP es de sistema intermedio a sistema intermedio (IS-IS). Para obtener más información sobre la inet.0 tabla de enrutamiento, consulte la Guía de configuración de aplicaciones de Junos MPLS.
Si el LSP estaba funcionando, esperaríamos ver entradas que incluyan el LSP en la tabla de inet.3 enrutamiento. La inet.3 tabla de enrutamiento se utiliza en enrutadores de entrada para enrutar paquetes BGP al enrutador de salida de destino. El BGP usa la inet.3 tabla de enrutamiento del enrutador de entrada para ayudar a resolver las direcciones del salto siguiente. El BGP se configura en la red de ejemplo que se muestra en la 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 el inet.0 enrutamiento, lo que indica que los LSP R1-to-R6 y R6-to-R1 están disponibles.
Verificar etiquetas MPLS con el comando traceroute
Propósito
Muestra los paquetes de ruta que toman a un destino BGP en el que el siguiente salto del BGP para esa ruta es la dirección de salida del LSP. De forma predeterminada, el BGP usa las inet.0 tablas de inet.3 enrutamiento y para resolver la dirección del siguiente salto. Cuando la dirección del salto siguiente de la ruta del BGP no es el ID del enrutador de salida, el tráfico se asigna a las rutas de IGP, no al LSP. Utilice el traceroute comando como herramienta de depuración para determinar si el LSP se utiliza para reenviar tráfico.
Acción
Para verificar las etiquetas MPLS, escriba el siguiente comando desde el enrutador de entrada:
user@host> traceroute hostname
Salida de muestra 1
nombre de 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
Salida de muestra 2
nombre de 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 del 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 está usando el IGP (IS-IS, en la red de ejemplo en red MPLS rota en la capa MPLS) para llegar a la dirección de salida LSP del siguiente salto del BGP. El comportamiento predeterminado de Junos OS usa LSP para el tráfico del BGP cuando el siguiente salto del BGP es igual a la dirección de salida de LSP.
La salida de ejemplo 2 es un ejemplo de salida para un LSP correctamente configurado. El resultado muestra las etiquetas MPLS, lo que indica que el tráfico del 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íen a través del LSP como paquetes MPLS.
Acción
Para comprobar 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
Salida de muestra 1
nombre de 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.
Salida de muestra 2
nombre de 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
La salida 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 la salida que debe recibir cuando el LSP está activo y reenvío de paquetes.
Tome las medidas adecuadas
Problema
Descripción
Según el error que haya encontrado en su investigación, debe tomar las medidas adecuadas para corregir el problema. En este ejemplo, una interfaz se configura incorrectamente en el nivel jerárquico [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
Verifique 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 se activa en el nivel de jerarquía [edit protocols mpls]. El LSP ahora puede venir.
Verificar el LSP de nuevo
Propósito
Después de tomar la acción adecuada para corregir el error, el LSP debe comprobarse de nuevo para confirmar que el problema en la capa del BGP se ha resuelto.
Acción
Para comprobar el LSP de nuevo, escriba el siguiente comando desde los enrutadores de entrada, tránsito y salida:
user@host> show mpls lsp extensive
Salida de muestra
nombre de 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 el estado está activo.
La salida de ejemplo 2 del enrutador R3 de tránsito muestra que hay dos sesiones de LSP de tránsito, una desde R1 hacia R6 y la otra desde R6 hacia R1. Ambos LSP están en marcha.
La salida de muestra 3 del enrutador R6 de salida muestra que el LSP está activo y la ruta activa es la ruta principal. El LSP ahora atraviesa la red a lo largo de la ruta esperada, de R1 a través R3 a R6, y el LSP inverso, de R6 a través R3 a R1.
Verifique 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 omisión estén activa. También puede comprobar la cantidad de LSP protegidos por las rutas de omisión. En la red que se muestra en Node-Link Protection, deben existir dos rutas de omisión: una ruta de omisión del salto siguiente que protege el vínculo entre R1 y R2 (o siguiente salto 10.0.12.14), y una ruta de omisión del salto siguiente que evita R2.
Acción
Para comprobar la protección de vínculos de nodo (copia de seguridad varios a uno), escriba los siguientes comandos del 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 omisión para 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 de 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 desde R1 para el show mpls lsp comando muestra una breve descripción del estado de los LSP configurados y activos para el cual R1 es el enrutador de entrada, tránsito y salida. Todos los LSP están en marcha. R1 es el enrutador de entrada para lsp2-r1-to-r5, y el enrutador de salida para LSP r5-to-r1de retorno. Dos LSP transitan R1y lsp1-r6-to-r0 el LSP r0-to-t6de retorno. Para obtener información más detallada acerca del LSP, incluya la extensive opción cuando emita 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 desde R1 para el show mpls lsp extensive comando muestra información detallada de todos los LSP para los cuales R1 es el enrutador de entrada, salida o tránsito, incluyendo todo el historial de estados pasados y la razón por la que se produjo un error en un LSP. Todos los LSP están en marcha. Los dos LSP lsp2-r1-to-r5 principales 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 la protección del vínculo está activa. En la sección de tránsito de la salida, el Type: Node/Link protected LSP campo muestra que lsp1-r6-to-r0 tiene la protección del vínculo del nodo activa y, en caso de falla, utilizará 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
La salida de ejemplo desde 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 podrían indicar sesiones para los dos LSP principales, lsp1-r6-to-r0 e lsp2-r1-to-r5. 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 sobre lo que está sucediendo en la interfaz fe-0/1/0.0, emita 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
La salida de ejemplo desde R1 para el show rsvp interface extensive comando muestra información más detallada acerca de la actividad en todas las interfaces RSVP (3). Sin embargo, solo se muestra el resultado para fe-0/1/0.0 . La protección está habilitada (Protection: On), con dos rutas de omisió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 omisión 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 omisión es un LSP protegido por vínculo de nodo, evitando R2 en caso de falla de 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 R1 muestra muestra información detallada sobre las sesiones RSVP activas en R1. Todas las sesiones están activas, con dos sesiones de entrada, 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 omisión, 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 indica el Type: Node/Link protected LSP campo.
Conclusión
La protección de vínculos de ruta conmutada por etiquetas (LSP) de conmutación de etiquetas multiprotocolo (MPLS) y la protección de vínculo de nodo son métodos basados en las instalaciones que se utilizan para reducir la cantidad de tiempo necesario para reenrutar el tráfico de LSP. Estos métodos de protección a menudo se comparan con el reenrutamiento rápido, el otro método de protección LSP de Junos OS.
Mientras que el reenrutamiento rápido protege los LSP de uno a uno, la protección de vínculo y la protección de vínculo de nodo protegen varios LSP mediante el uso de un único LSP de omisión lógica. La protección de vínculos proporciona un soporte de copia de seguridad sólido para un vínculo, la protección de vínculo de nodo pasa por alto un nodo o un vínculo, y ambos tipos de protección están diseñados para interoperar con otros equipos de proveedores. Esta funcionalidad hace que la protección de vínculos y de nodo sea una opción excelente para la escalabilidad, la redundancia y el rendimiento en redes habilitadas para MPLS.
Información relacionada
Para obtener más información acerca del reenrutamiento rápido de 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 junos MPLS
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
Compruebe que la protección de vínculos está activa
Propósito
Cuando compruebe la protección del vínculo, debe comprobar que el LSP de omisión esté activo. También puede comprobar la cantidad de LSP protegidos por el bypass. En la red que se muestra en Protección de vínculos o varios a uno, debe haber una ruta de omisión para proteger el vínculo entre R1 y R2, o el salto siguiente 10.0.12.14, y los dos LSP que atraviesan el vínculo, lsp2-r1-to-r5 y lsp1-r6-to-r0.
Acción
Para comprobar la protección del vínculo (copia de seguridad varios a uno), escriba 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 de 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 eso lsp2-r1-to-r5 y lsp1-r6-to-r0 tienen protección de vínculo activa, y ambos LSP utilizan la ruta de omisión, 10.0.12.14. Sin embargo, el show mpls lsp comando no enumera la ruta de omisión. Para obtener más información acerca de la ruta de omisió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. Alguna 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 característica RSVP, se proporciona información sobre las rutas de omisión. La ruta de omisió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 omisión se genera automáticamente. De forma predeterminada, el nombre aparece como Bypass > interface-address, donde la dirección de 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 del resultado, el LSP que se origina en R1 (lsp2-r1-to-r5) se muestra solicitando protección de vínculo. Dado que una ruta de derivación está en su lugar para proteger el vínculo descendente, lsp2-r1-to-r5 se asocia con la derivación, como se indica en el Link protected LSP campo.
La sección de salida de la salida muestra el LSP r5-to-r1devuelto, 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. Since una ruta de derivación para proteger el vínculo descendente, lsp1-r6-to-r0 está asociada con el bypass, como indica el Link protected LSP campo. También se incluye en la sección de tránsito de la salida el LSP r0-to-r6de retorno, 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, la interfaz entre y 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, la omisión (10.0.12.14); interfaz fe-0/1/2.0 entre R6 y R1 no tiene reservas de LSP; e interfaz so-0/0/3.0 entre R6 y R1 tiene una reserva de LSP, lsp1-r6-to-r0.R2R1fe-0/1/0.0
Verificar copias de seguridad uno a uno
Propósito
Puede comprobar que la copia de seguridad uno a uno se establece mediante el examen del enrutador de entrada y los demás enrutadores de la red.
Acción
Para verificar la copia de seguridad uno a uno, escriba 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 de comando
La siguiente salida de ejemplo es 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
El resultado de R1 muestra muestra que el FastReroute desired objeto se incluyó en los mensajes Path para el LSP, lo que permite R1 seleccionar la ruta activa para el LSP y establecer una ruta de 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 los enrutadores R2 de tránsito y R4 han establecido sus rutas de desvío.
R2, 10.0.12.14, incluye (flag=9), indica que la protección del nodo está disponible para el nodo y el vínculo descendentes. R4, 10.0.24.2incluye (flag=1), lo que indica que la protección de vínculo está disponible para el siguiente vínculo descendente. En este caso, R4 puede proteger solo 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 las marcas, consulte la Guía 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 que utilizan 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
La siguiente salida de ejemplo es 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
El resultado de R1 muestra 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 R5, el enrutador de salida.
Salida de muestra
La siguiente salida de ejemplo es 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
La salida de R2 muestra muestra que el desvío está establecido (Detour is Up) y evita R4, y el vínculo se R4 conecta 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. R1 tiene el desvío pasando por el 10.0.17.14 vínculo en R7, mientras R1 se utiliza el 10.0.27.2 vínculo. Ambos desvíos se fusionan a R9 través del 10.0.79.2 vínculo a R5 (10.0.59.1).
Salida de muestra
La siguiente salida de ejemplo es 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
El resultado de R4 muestra que el desvío está establecido (Detour is Up) y evita que el vínculo se R4 conecte y R5 (10.0.45.2). La ruta de desvío se encuentra 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 el resultado para R1 y R2. Sin embargo, la ruta explícita para el desvío es diferente, pasando por el vínculo que conecta R4 y R9 (so-0/0/3 o 10.0.49.2.
Salida de muestra
La siguiente salida de ejemplo es de R7, que se utiliza en la ruta de desvío de la red que se muestra en los 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
El resultado de R7 muestra muestra la misma información que 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; la primera para evitar R4 (192.168.4.1) y la segunda para evitar R2 (192.168.2.1). Porque R7 se utiliza como enrutador de tránsito por R2 y R4, R7 puede fusionar las rutas de desvío juntas como lo indica el valor idéntico Label out (100368) para ambas rutas de desvío. Si R7 recibe tráfico desde R4 un valor de etiqueta de 100736 o desde 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
La siguiente salida de ejemplo es de R9, que es un enrutador utilizado en la ruta de desvío de la red que se muestra en los 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
La salida de ejemplo de R9 muestra que R9 es el penúltimo enrutador para la ruta de desvío, la ruta explícita incluye solo la dirección del vínculo de salida (10.0.59.1) y el Label out valor (3) indica que R9 se ha realizado el penúltimo salto de etiquetas. Además, la rama de desvío desde no incluye información de 10.0.27.1 ruta, ya que R7 fusionó las rutas de desvío desde R2 y R4. Observe que el Label out valor de la rama de desvío desde 10.0.17.13 es 100368, el mismo valor que el valor de R7Label out .
Salida de muestra
La siguiente salida de ejemplo es del enrutador de salida R5 de 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
El resultado de R5 muestra muestra el LSP principal en el Record route campo y los desvíos a través de la red.
Verificar que la ruta principal esté operativa
Propósito
Las rutas principales siempre se deben usar en la red si están disponibles, por lo tanto, un LSP siempre vuelve a la ruta principal después de una falla, 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 Prevención del uso de una ruta que anteriormente falló.
Acción
Para comprobar que la ruta principal está operativa, escriba los siguientes comandos de modo operativo de interfaz de línea de comandos (CLI) de Junos OS:
user@host> show mpls lsp extensive ingress user@host> show rsvp interface
Salida de muestra 1
nombre de 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
Salida de muestra 2
nombre de 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 utiliza 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 mantención, 6 6. La prioridad 0 es la prioridad más alta (la mejor) y la 7 es la prioridad más baja (peor). El valor predeterminado de Junos OS para la configuración y la prioridad de mantenimiento es 7:0. A menos que algunos LSP sean más importantes que otros, conservar el valor predeterminado es una buena práctica. No se permite configurar una prioridad de instalación que sea mejor que la prioridad de espera, lo que da como resultado una confirmación fallida para evitar bucles de preferencia.
Compruebe que la ruta secundaria está establecida
Propósito
Cuando la ruta secundaria está configurada con la standby instrucción, la ruta secundaria debe estar activa pero no activa; se volverá activa si se produce un error en la ruta principal. Una ruta secundaria configurada sin la standby instrucción no aparecerá a menos que se falle la ruta principal. Para probar que la ruta secundaria está correctamente configurada y que aparece si la ruta principal falla, 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 de comando
La siguiente salida de ejemplo muestra una ruta secundaria correctamente configurada antes y después de que aparezca. En el ejemplo, la interfaz fe-0/1/0 activada R2 está desactivada, lo que lleva a 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 muestra del enrutador R1 de salida muestra una ruta secundaria en espera correctamente configurada en un estado descendente, ya que la ruta principal sigue activa. Al desactivar una interfaz (interface fe-0/1/0 en R2) crítica para la ruta principal, la ruta via-r2 principal cae 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 por capas.
Con esta capa, debe asegurarse de que los enrutadores estén conectados y de que las interfaces estén activadas 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 funciona como está configurada.
Figura 4 muestra la red MPLS y el problema descrito en este tema.
La red que se muestra en es una configuración completamente mallada en Figura 4 la que cada interfaz conectada directamente puede recibir y enviar paquetes a cualquier otra interfaz similar. El LSP de esta red está configurado para que se ejecute desde el enrutador de entrada, a través del enrutador R1de tránsito, al enrutador R3R6de salida. Además, un LSP inverso está configurado para ejecutarse desde R6 el a través R3 hasta R1, creando tráfico bidireccional.
Sin embargo, en este ejemplo, el tráfico no usa el LSP configurado. En su lugar, el tráfico utiliza la ruta alternativa de R1 a través R2 a R6, y en la dirección inversa, desde R6 a través R5 to R1.
Cuando se percata de una situación en la que se utiliza una ruta alternativa en lugar del LSP configurado, compruebe que la capa física funcione correctamente. Es posible que los enrutadores no estén conectados o que las interfaces no estén activadas 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:
- Verificar el LSP
- Verificar la conexión del enrutador
- Verificar interfaces
- Tome las medidas adecuadas
- Verificar el LSP de nuevo
Verificar el LSP
Propósito
Normalmente, se usa el show mpls lsp extensive comando para comprobar el LSP. Sin embargo, para verificar rápidamente el estado del LSP, utilice el show mpls lsp comando. Si el LSP está inactivo, utilice la extensive opción (show mpls lsp extensive) como seguimiento. Si su red tiene varios LSP, podría considerar especificar el nombre del LSP, utilizando 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 de 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á usando una ruta alternativa en lugar de la ruta configurada. La ruta configurada para el LSP es R1R3 hasta R6, y para el LSP inverso, R6 hasta R3R1. La ruta alternativa utilizada por el LSP es R1R2 hasta R6, y para el LSP inverso, R6 t hrough R5 a R1.
Verificar la conexión del enrutador
Propósito
Confirme que los enrutadores de entrada, tránsito y salida adecuados funcionen mediante el examen de si los paquetes se han recibido y transmitido con una pérdida de paquete 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 de 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
La salida 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 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 de 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 del 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].
El resultado de los enrutadores de tránsito y salida (no mostrados) muestra que las interfaces de esos enrutadores están configuradas correctamente.
Tome las medidas adecuadas
Problema
Descripción
Según el error que haya encontrado en su 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 family mpls instrucción está configurada correctamente para la interfaz so-0/0/2.0y que el LSP funciona ahora como estaba configurado originalmente.
Verificar el LSP de nuevo
Propósito
Después de tomar la acción adecuada para corregir el error, el LSP debe comprobarse de nuevo para confirmar que el problema en la capa física se ha resuelto.
Acción
Para comprobar que el LSP está activo y atravesando la red como se esperaba, ingrese el siguiente comando:
user@host> show mpls lsp extensive
Salida de muestra 1
nombre de 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
Salida de muestra 2
nombre de 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 atraviesa la red a lo largo de la ruta esperada, desde R1 a través R3 hasta 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 se desactiva 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 es 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), se emitió el show mpls lsp extensive comando y se determinó que hay un error, es posible que encuentre que el error no se encuentra en la capa física. Continúe investigando el problema en la capa de vínculo de datos de la red.
Figura 5 ilustra la capa de vínculo de datos del modelo MPLS por capas.
Con esta capa, debe comprobar el modo de encapsulación, por ejemplo, el protocolo punto a punto (PPP) o el control de vínculo de datos de alto nivel de Cisco (HDLC); Opciones PPP, por ejemplo, encapsulación de encabezado; tamaño de la secuencia de comprobación de tramas (FCS); y si las tramas de mantención están habilitadas o deshabilitadas. 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 es una configuración completamente mallada en Figura 6 la que cada interfaz conectada directamente puede recibir y enviar paquetes a cualquier otra interfaz similar. El LSP de esta red está configurado para que se ejecute desde el enrutador de entrada, a través del enrutador R1de tránsito, al enrutador R3R6de salida. Además, un LSP inverso está configurado para ejecutarse desde R6 el a través R3 hasta R1, creando tráfico bidireccional.
Sin embargo, en este ejemplo, el LSP está caído sin una ruta en ninguna dirección, desde o hacia R1R6R6R1.
Cuando compruebe que la capa de vínculo de datos no funciona correctamente, es posible que encuentre una discordancia con la encapsulación PPP o Cisco HDLC, las opciones PPP o las tramas de mantención.
La cruz que se muestra en Figura 6 indica dónde el LSP está roto debido a un error de configuración en el enrutador R1 de entrada que impide que el LSP transite por la red como se esperaba.
Para comprobar la capa de vínculo de datos, siga estos pasos:
Verificar el LSP
Propósito
Normalmente, se usa el show mpls lsp extensive comando para comprobar el LSP. Sin embargo, para verificar rápidamente el estado del LSP, utilice el show mpls lsp comando. Si el LSP está inactivo, utilice la extensive opción (show mpls lsp extensive) como seguimiento. Si su red tiene varios LSP, podría considerar especificar el nombre del LSP, utilizando 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
Salida de muestra 1
nombre de 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á caído, sin una ruta desde R1 hacia R6. Porque un LSP inverso está configurado en la red que se muestra en red MPLS Rota en la capa de vínculo de datos, esperaríamos que una sesión de LSP de salida esté activa. Sin embargo, R1 no tiene LSP de salida, lo que indica que el LSP de R6 a no R1 funciona.
Verificar interfaces
Propósito
Desde su topología de red, determine las interfaces adyacentes a través de las cuales el LSP está destinado a atravesar, y examine la salida para el tipo de encapsulación, las opciones PPP, el tamaño de FCS y si las tramas de mantención están habilitadas o deshabilitadas.
Antes de continuar con este paso, compruebe la capa física para asegurarse de que el problema no se encuentra en la capa física.
Acción
Para comprobar el funcionamiento de interfaces adyacentes, escriba los siguientes comandos desde los enrutadores pertinentes:
user@host> show interfaces type-fpc/pic/port extensive user@host> show interfaces type-fpc/pic/port
Salida de muestra 1
nombre de 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
Salida de muestra 2
nombre de 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 o defectos de SONET (none), los estados son todos OK, y el seguimiento de ruta muestra el extremo lejano (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 vínculo a nivel 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 da como resultado que el LSP disminuya.
Tome las medidas adecuadas
Problema
Descripción
Según el error que haya encontrado en su 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 evitó que el LSP usara la ruta deseada. El problema se corrigió cuando se eliminó la encapsulation instrucción y la configuración confirmada.
Verificar el LSP de nuevo
Propósito
Después de tomar la acción adecuada para corregir el error, el LSP debe comprobarse de nuevo para confirmar que el problema en la capa de vínculo de datos se ha resuelto.
Acción
Desde los enrutadores de entrada, salida y tránsito, verifique que el LSP esté activo y recorriendo la red como se esperaba:
user@host> show mpls lsp extensive
Salida de muestra 1
nombre de 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
Salida de muestra 2
nombre de 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
Salida de muestra 3
nombre de 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
Salida de muestra 4
nombre de 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
Las salidas de muestra 1 y 2 del enrutador de entrada y el enrutador R1 R6, de salida, respectivamente, muestran que el LSP ahora atraviesa la red a lo largo de la ruta esperada, de R1 a través R3 a R6, y el LSP inverso, desde R6 hasta .R1R3
La salida de ejemplo 3 del enrutador R3 de tránsito muestra que hay dos sesiones de LSP de tránsito, una desde R1 hacia R6 y la otra desde R6 hacia R1.
La salida 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 es correcta, el LSP seguiría atravesando la red a través de la ruta alternativa.
Verificar las capas IP e IGP
Problema
Descripción
Después de configurar la ruta de conmutación de etiquetas (LSP), se emitió el show mpls lsp extensive comando y se determinó que hay un error, es posible que encuentre que el error no se encuentra 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 por capas.
Solución
En las capas IP e IGP, debe comprobar lo siguiente:
Las interfaces tienen direccionamiento IP correcto, y se establecen los vecinos o adyacencias IGP.
Los protocolos open Shortest Path First (OSPF) o de sistema intermedio a sistema intermedio (IS-IS) están configurados y se ejecutan correctamente.
Si el protocolo OSPF está configurado, compruebe primero la capa IP y, luego, la configuración del OSPF, para asegurarse de que el protocolo, las interfaces y la ingeniería de tráfico estén correctamente configurados.
Si el protocolo IS-IS está configurado, no importa si marca primero IS-IS o IP, ya que ambos protocolos son independientes entre sí. Compruebe que las adyacencias IS-IS estén funcionando y que las interfaces y el protocolo IS-IS estén configurados correctamente.
Nota:El protocolo IS-IS tiene la ingeniería de tráfico habilitada de forma predeterminada.
Si la red no funciona en las capas IP o IGP, el LSP no funciona como está configurado.
Figura 8 ilustra la red MPLS utilizada en este tema.
La red que se muestra en es una configuración completamente mallada en Figura 8 la que cada interfaz conectada directamente puede recibir y enviar paquetes a cualquier otra interfaz similar. El LSP de esta red está configurado para que se ejecute desde el enrutador de entrada, a través del enrutador R1de tránsito, al enrutador R3R6de salida. Además, un LSP inverso está configurado para ejecutarse desde R6, a través R3de , a R1, creando tráfico bidireccional. Los cruces en indican dónde el LSP no funciona debido a los siguientes problemas en Figura 8 la capa IP e IGP:
Una dirección IP está configurada incorrectamente en el enrutador de entrada (R1).
El protocolo OSPF está configurado con un ID de enrutador (RID) pero sin la interfaz de circuito cerrado (lo0) y falta ingeniería de tráfico del enrutador de tránsito (R3).
Los niveles de la red IS-IS no son coincidedores.
Verificar la capa IP
Propósito
Puede comprobar la capa IP antes o después de comprobar la capa del protocolo de puerta de enlace interior (IGP), dependiendo de si tiene OSPF o IS-IS configurado como IGP. Si su red MPLS está configurada con OSPF como IGP, primero debe comprobar la capa IP, comprobar que las interfaces tengan el direccionamiento IP correcto y que los vecinos OSPF estén establecidos antes de comprobar la capa OSPF.
Si tiene IS-IS configurado como IGP en su red MPLS, puede comprobar primero la capa IP o la capa de protocolo IS-IS. El orden en el que compruebe la capa IP o IS-IS no afecta a los resultados.
El cruce Figura 9 indica dónde se rompe el LSP debido a la configuración incorrecta de una dirección IP en el enrutador R1de entrada.
- Verificar el LSP
- Verificar el direccionamiento IP
- Verificar vecinos o adyacencias en la capa IP
- Tome las medidas adecuadas
- Verificar el LSP de nuevo
Verificar 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 la verificació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 varios LSP, puede considerar 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
Salida de muestra 1
nombre de 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 el algoritmo de primera ruta más corta restringida (CSPF) falló, lo que da como resultado que no haya una ruta al destino 10.0.0.6 en R6.
Verificar el direccionamiento IP
Propósito
Cuando investiga la capa IP, verifica que las interfaces tengan el direccionamiento IP correcto y que se hayan establecido los vecinos OSPF o las adyacencias IS-IS. En este ejemplo, una dirección IP se configura 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 de 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 en R1 y la interfaz so-0/0/2.0 en R3 son 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 de forma incorrecta, es necesario comprobar los vecinos OSPF o las adyacencias IS-IS para determinar si se han establecido uno o ambos.
Acción
Para comprobar los vecinos (OSPF) o las adyacencias (IS-IS), ingrese los siguientes comandos desde los enrutadores de entrada, tránsito y salida:
user@host> show ospf neighbor extensive user@host> show isis adjacency extensive
Salida de muestra 1
nombre de 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
Salida de muestra 2
nombre de 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 muestra 1 de los enrutadores de entrada, tránsito y salida muestra que R1 y R3 no son vecinos 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, es de esperar esto. El protocolo OSPF enruta paquetes IP según la dirección IP de destino contenida en el encabezado del paquete IP. Por lo tanto, las direcciones IP idénticas en el sistema autónomo (AS) dan como resultado que los vecinos no se establezcan.
La salida de muestra 2 de los enrutadores de entrada, tránsito y salida muestra que R1 y R3 han establecido una adyacencia IS-IS a pesar de las direcciones IP idénticas configuradas en interfaces so-0/0/2.0 en R1 y R3. El protocolo IS-IS se comporta de manera diferente al protocolo OSPF, ya que no depende de IP para establecer una adyacencia. Sin embargo, si el LSP no está activo, sigue siendo útil comprobar el direccionamiento de subred IP en caso de que haya un error en esa capa. Corregir el error de direccionamiento podría hacer que el LSP vuelva a activar.
Tome las medidas adecuadas
Problema
Descripción
Según el error que haya encontrado en su 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
La salida de ejemplo muestra que la interfaz so-0/0/2 del 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 red MPLS rota en las capas IP e IGP, y la posibilidad de que el LSP pueda aparecer.
Verificar el LSP de nuevo
Propósito
Después de tomar la acción adecuada para corregir el error, el LSP debe comprobarse de nuevo para confirmar que el problema en el protocolo OSPF se ha resuelto.
Acción
Para comprobar el LSP de nuevo, escriba el siguiente comando en los enrutadores de entrada, tránsito y salida:
user@host> show mpls lsp extensive
Salida de muestra 1
nombre de 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
Salida de muestra 2
nombre de 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
Salida de muestra 3
nombre de 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 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 desde R1 hacia R6 y la otra desde R6 hacia R1. Ambos LSP están activo.
La salida de muestra 3 del enrutador R6 de salida muestra que el LSP está activo y la ruta activa es la ruta principal. El LSP ahora atraviesa la red a lo largo de la ruta esperada, de R1 a través R3 a R6, y el LSP inverso, de R6 a través R3 a R1.
Verificar el LSP de nuevo
Propósito
Después de tomar las medidas adecuadas para corregir el error, el LSP debe comprobarse de nuevo para confirmar que el problema en el protocolo IS-IS se ha resuelto.
Acción
Para comprobar que el LSP está activo y atravesando la red como se esperaba, ingrese el siguiente comando desde los enrutadores de entrada, salida y tránsito:
user@host> show mpls lsp extensive
Salida de muestra
nombre de 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 de entrada y del enrutador R1 R6 de salida muestra que el LSP ahora atraviesa la red a lo largo de la ruta esperada, de R1 a través R3 a R6, y el LSP inverso, de R6 a través R3 a R1. Además, la salida de muestra 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 R1.
Comprobar la capa RSVP
Propósito
Después de configurar la ruta de conmutación de etiquetas (LSP), emitió el show mpls lsp extensive comando y determinó que hay un error, es posible que el error no se encuentre en las capas físicas, de vínculo de datos o de Protocolo de Internet (IP) y 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 por capas.
Con esta capa, se comprueba que la señalización dinámica de RSVP se produzca 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 como configurado.
Figura 11 ilustra la red MPLS utilizada en este tema.
La red que se muestra en es una configuración completamente mallada en Figura 11 la que cada interfaz conectada directamente puede recibir y enviar paquetes a cualquier otra interfaz similar. El LSP de esta red está configurado para que se ejecute desde el enrutador de entrada, a través del enrutador R1de tránsito, al enrutador R3R6de salida. Además, un LSP inverso está configurado para ejecutarse desde R6 el a través R3 hasta R1, creando tráfico bidireccional.
Sin embargo, en este ejemplo, el LSP está caído sin una ruta en ninguna dirección, desde o hacia R1R6R6R1.
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 podrían incluir que la señalización dinámica del RSVP no se está produciendo como se esperaba, que los vecinos no están conectados o que las interfaces están configuradas incorrectamente para RSVP.
En la red en , un error de configuración en Figura 11el enrutador R3 de tránsito impide que el LSP atravese la red como se esperaba.
Para comprobar la capa RSVP, siga estos pasos:
- Verificar el LSP
- Verificar sesiones de RSVP
- Verificar vecinos de RSVP
- Verificar interfaces RSVP
- Verificar la configuración del protocolo RSVP
- Tome las medidas adecuadas
- Verificar el LSP de nuevo
Verificar el LSP
Propósito
Normalmente, se usa el show mpls lsp extensive comando para comprobar el LSP. Sin embargo, para verificar rápidamente el estado del LSP, utilice el show mpls lsp comando. Si el LSP está inactivo, utilice la extensive opción (show mpls lsp extensive) como seguimiento. Si su red tiene varios LSP, podría considerar especificar el nombre del LSP, utilizando 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
Salida de muestra 1
nombre de 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
El resultado de ejemplo muestra que el LSP está descendente en ambas direcciones, de R1 a R6, y de R6 a R1. El resultado de R1 muestra que R1 está usando un LSP sin cspf desde que intentó originar la llamada sin poder llegar al destino. El resultado de R6 muestra que el algoritmo de primera ruta más corta restringida (CSPF) falló, lo que da como resultado ninguna ruta al destino 10.0.0.1.
Verificar sesiones de RSVP
Propósito
Cuando se crea correctamente una sesión RSVP, el LSP se configura a lo largo de las rutas creadas por la sesión RSVP. Si la sesión RSVP no funciona correctamente, el LSP no funciona como está configurado.
Acción
Para comprobar las sesiones RSVP activas actualmente, ingrese el siguiente comando desde los enrutadores de entrada, tránsito y salida:
user@host> show rsvp session
Salida de muestra 1
nombre de 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
Salida de muestra 2
nombre de 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 ejemplo 1 de todos los enrutadores muestra que no se crearon correctamente ninguna sesión RSVP, aunque el LSP R6-to-R1 esté configurado.
A diferencia de la salida de muestra 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 del RSVP es correcta y el LSP atraviesa la red como está configurada. R1 y R6 ambos muestran una sesión RSVP de entrada y salida, con el LSP R1-to-R6, y el LSP R6-to-R1inverso. El enrutador R3 de tránsito muestra dos sesiones RSVP de tránsito.
Verificar vecinos de RSVP
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 se elimine la configuración del RSVP del enrutador.
Acción
Para comprobar los vecinos del RSVP, escriba el siguiente comando desde los enrutadores de entrada, tránsito y salida:
user@host> show rsvp neighbor
Salida de muestra 1
nombre de 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
Salida de muestra 2
nombre de 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
La salida de muestra 1 muestra que R1 y R6 tienen un RSVP vecino 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 es. Cuando la cuenta ascendente es uno más que la cuenta descendente, el vecino está activo; si los valores son iguales, el vecino está caído. Los valores para R6 son iguales, 1/1lo que indica que el vecino R3 está caído.
El enrutador R3 de tránsito conoce dos vecinos y R1R6. El Up/Dn campo indica que R1 es un vecino activo y R6 que está inactivo. En este punto no es posible determinar si el problema reside con R3 o R6, porque ambos vecinos no están activos.
A diferencia de 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 de tránsito y el enrutador R3 R6de salida. El Up/Dn campo muestra la cuenta ascendente como una más que la cuenta descendente, 1/0lo 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
Salida de muestra 1
nombre de 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
Salida de muestra 2
nombre de 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 muestra 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 se incluye en la configuración. La inclusión de esta interfaz es fundamental para el éxito del LSP.
A diferencia de la salida de la 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 RSVP, las interfaces, los vecinos y determinar que puede haber un error de configuración, compruebe la configuración del protocolo RSVP.
Acción
Para comprobar la configuración del RSVP, escriba el siguiente comando desde los enrutadores de entrada, tránsito y salida:
user@host> show configuration protocols rsvp
Salida de muestra
nombre de 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 de la configuración del protocolo RSVP. Esta interfaz es fundamental para el correcto funcionamiento del LSP.
Tome las medidas adecuadas
Problema
Descripción
Según el error que haya encontrado en su 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
Verifique 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 como resultado la posibilidad de que el LSP pueda surgir.
Verificar el LSP de nuevo
Propósito
Después de tomar las medidas adecuadas para corregir el error, el LSP debe comprobarse de nuevo para confirmar que el problema en la capa MPLS se ha resuelto.
Acción
Para comprobar el LSP de nuevo, escriba el siguiente comando en los enrutadores de entrada, tránsito y salida:
user@host> show mpls lsp extensive
Salida de muestra 1
nombre de 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
Salida de muestra 2
nombre de 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
Salida de muestra 3
nombre de 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 el estado está activo.
La salida de ejemplo 2 del enrutador R3 de tránsito muestra que hay dos sesiones de LSP de tránsito, una desde R1 hacia R6 y la otra desde R6 hacia R1. Ambos LSP están en marcha.
La salida de muestra 3 del enrutador R6 de salida muestra que el LSP está activo y la ruta activa es la ruta principal. El LSP ahora atraviesa la red a lo largo de la ruta esperada, de R1 a través R3 a R6, y el LSP inverso, de R6 a través R3 a R1.
Determinar estadísticas de LSP
Propósito
Muestra información detallada acerca de los objetos RSVP para ayudar en el diagnóstico de un problema de LSP.
Acción
Para comprobar los objetos RSVP, escriba el siguiente comando de modo operativo de la CLI de Junos OS:
user@host> show rsvp session detail
Salida de muestra
nombre de 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
El resultado de ejemplo muestra que hay una sesión RSVP de entrada y una sesión 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 agraciado a su vecino para recuperar un estado de reenvío. Es probablemente la etiqueta antigua que el enrutador anunció antes de que se cayese.
Esta sesión utiliza el filtro fijo (FF) estilo de reserva (Resv style). Dado que se trata de un enrutador de entrada, no hay ninguna etiqueta de entrada. La etiqueta de salida (proporcionada por el siguiente enrutador descendente) es 100064.
El Time Left campo proporciona la cantidad de segundos que quedan 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 de túnel IPv4, mientras que el número de puerto de remitente/receptor es el ID de LSP. El ID de túnel IPv4 es único para la vida útil del LSP, mientras que el ID de LSP de remitente/receptor puede cambiar, por ejemplo, con una reserva de estilo SE.
El PATH rcvfrom campo incluye el origen del mensaje de ruta. Dado que se trata del enrutador de entrada, el cliente local originó el mensaje de ruta.
El PATH sentto campo incluye el destino del mensaje de ruta (10.1.13.2) y la interfaz de salida (so-0/0/2.0). El RESV rcvfrom campo incluye tanto el origen del mensaje de Resv recibido (10.1.13.2) como la interfaz de entrada (so-0/0/2.0).
La ruta explícita del RSVP y los valores del 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, con el total igual a la suma de las sesiones de arriba y abajo. En este ejemplo, hay una sesión de entrada, una sesión de salida y ninguna sesión RSVP de tránsito.
Verificar el uso de LSP en su red
Propósito
Cuando compruebe el uso válido de un LSP en los enrutadores de entrada y tránsito de su red, puede determinar si hay un problema con la conmutación de etiquetas multiprotocolo (MPLS) en su red. Figura 12 describe la red de ejemplo utilizada en este tema.
La red MPLS en muestra una red solo para Figura 12 enrutadores con interfaces SONET que consta de los siguientes componentes:
Una topología del Protocolo de puerta de enlace de borde interior (IBGP) de malla completa mediante el AS 65432
MPLS y el Protocolo de reserva de recursos (RSVP) habilitados en todos los enrutadores
Una send-statics política en 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 de borde (BGP). Dado que los reflector de ruta y las confederaciones no se utilizan para propagar rutas aprendidas del BGP, cada enrutador debe tener una sesión de BGP con todos los demás enrutadores que ejecutan BGP.
Para comprobar el uso de LSP en su red, siga estos pasos:
Verificar un LSP en el enrutador de entrada
Propósito
Puede verificar la disponibilidad de un LSP cuando está activo mediante el examen de la inet.3 tabla de enrutamiento en el 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. El BGP usa la inet.3 tabla de enrutamiento del enrutador de entrada para ayudar a resolver las direcciones del salto siguiente.
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 de 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) de BGP y MPLS pueden usar la tabla de rutas para resolver la inet.3 información del próximo salto. En la tabla de rutas, se enumera un destino, 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 conmutada por etiqueta 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 salto siguiente.
Por lo general, el penúltimo enrutador en el LSP extrae la etiqueta del paquete o cambia la etiqueta a un valor de 0. Si el penúltimo enrutador aparece en la etiqueta superior y un paquete IPv4 está debajo, el enrutador de salida enruta el paquete IPv4, consultando la tabla inet.0 de enrutamiento IP para determinar cómo reenviar el paquete. Si otro tipo de etiqueta (como una creada por el protocolo de distribución de etiquetas (LDP) de tunelización o VPN, pero no IPv4) está debajo de la etiqueta superior, el enrutador de salida no examina la tabla de inet.0 enrutamiento. En su lugar, examina la tabla de mpls.0 enrutamiento para tomar 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, lo que indica que sigue un paquete IPv4. La tabla de enrutamiento examina el inet.0 paquete para tomar decisiones de reenvío.
Cuando un enrutador de tránsito o salida recibe un paquete MPLS, la información de la tabla de reenvío MPLS se utiliza para determinar el siguiente enrutador de tránsito en el LSP o si este enrutador es el enrutador de salida.
Cuando el BGP resuelve un prefijo del siguiente salto, examina las tablas y inet.3 el inet.0 enrutamiento, buscando el siguiente salto con la preferencia más baja; por ejemplo, se prefiere la preferencia 7 de RSVP sobre la preferencia 10 de OSPF. El LSP señal de 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 mediante un LSP, el tráfico del BGP usa el LSP para reenviar el tráfico de tránsito del BGP.
Verificar un LSP en un enrutador de tránsito
Propósito
Puede comprobar la disponibilidad de un LSP cuando esté activo mediante el examen de la tabla de mpls.0 enrutamiento en un enrutador de tránsito. MPLS mantiene la mpls.0 tabla de enrutamiento, que contiene una lista del siguiente enrutador conmutado por etiqueta en cada LSP. Esta tabla de enrutamiento se utiliza en enrutadores de tránsito para enrutar paquetes al enrutador siguiente a lo largo de un LSP.
Acción
Para comprobar un LSP en un enrutador de tránsito, ingrese el siguiente comando de modo operativo de CLI de Junos OS:
user@host> show route table mpls.0
Salida de muestra
nombre de 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 muestra del enrutador R3 de tránsito muestra las entradas de ruta en forma de entradas de etiquetas 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 null explícita IPv4. La etiqueta 1 es el equivalente MPLS de la etiqueta alerta del enrutador IP y la etiqueta 2 es la etiqueta IPv6 explícita null.
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. Por el contrario, la primera entrada de 100064 tiene un S=1 inferido que indica una profundidad de pila de 1 y la convierte en la última etiqueta del paquete. La entrada dual 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 la RSVP asigna al vecino ascendente. Los enrutadores de Juniper Networks asignan etiquetas dinámicamente para LSP diseñados por tráfico RSVP en el rango de 100 000 a 1048 575.
El enrutador asigna etiquetas a partir de la etiqueta 100 000, en incrementos de 16. La secuencia de asignación de etiquetas es 100 000, 100 016, 100 032, 100 048, etc. Al final de las etiquetas asignadas, los números de etiquetas comienzan de nuevo en 100001, aumentando en unidades de 16. Juniper Networks reserva etiquetas para diversos propósitos. Tabla 1 enumera las diversas 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 asignación de LSP estática |
1024 a través de 9999 |
Reservado para uso interno (por ejemplo, etiquetas CCC) |
10,000 a través de 99,999 |
Reservado para asignación de LSP estática |
100,000 a través de 1,048,575 |
Reservado para asignación dinámica de etiquetas |
Compruebe que el equilibrio de carga funciona
Propósito
Después de configurar el equilibrio de carga, compruebe que el tráfico tiene un equilibrio de carga igual entre 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 la topología de equilibrio de carga de red. Los clear comandos se utilizan 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 en interfaces y LSP, utilice el siguiente comando en el enrutador de entrada:
user@host# show configuration
Para comprobar el equilibrio de carga en 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 de comando
El siguiente resultado de ejemplo es para la configuración del 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á correctamente configurado con la lbpp instrucción policy. Además, la lbpp política se exporta a la tabla de reenvío en el [edit routing-options] nivel jerárquico.
- 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 es 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 del ángulo derecho (>) suele indicar la ruta activa, en este caso no lo hace, como se muestra en las cuatro salidas de muestra siguientes.
Salida de muestra
La siguiente salida de ejemplo es 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 monitor interface traffic comando emitido en el enrutador R2 de 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 es 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 show mpls lsp statistics comando emitido en el 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 es 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 está funcionando. Las dos unidifusión (ucst) las entradas en el Type campo son los dos saltos siguientes para los LSP.
Salida de muestra
La siguiente salida de ejemplo es 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
La salida 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 salto siguiente. 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 null explícita IPv4. La etiqueta 1 es el equivalente MPLS de la etiqueta alerta del enrutador IP, y la etiqueta 2 es la etiqueta null explícita IPv6.
Las cinco etiquetas restantes de la Destination columna son etiquetas sin servicio que el enrutador utiliza para reenviar tráfico, y la última columna Netif, muestra las interfaces utilizadas para enviar el tráfico etiquetado. En el caso de las etiquetas sin servicio, 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 paquete de salida. Por ejemplo, los paquetes con la etiqueta 100112 se intercambian 100032 para antes de que se empujen fuera 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 está realizando un equilibrio de carga de costo desigual entre rutas LSP, el show route detail comando muestra un campo de equilibrio asociado con cada salto siguiente que se utiliza.
Acción
Para comprobar que un LSP RSVP está desigualmente equilibrado con la carga, 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 de 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 según la configuración de ancho de banda 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 verificar etiquetas MPLS
Propósito
Puede usar 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 se encuentra la dirección IP o el nombre del host remoto:
user@host> traceroute host-name
Salida de muestra 1
nombre de 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
Salida de muestra 2
nombre de 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
La salida 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 la cantidad de saltos que este paquete MPLS puede viajar a través de la red (1). Se decrementa 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 muestra 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 usa LSP para el tráfico del BGP cuando el siguiente salto del BGP es igual a la dirección de salida de LSP.
La salida de ejemplo 2 muestra que las etiquetas MPLS no aparecen en la salida del traceroute comando. Si el siguiente salto del BGP no es igual a la dirección de salida del LSP o si el destino es una ruta IGP, el tráfico del BGP no usa el LSP. En lugar de usar el LSP, el tráfico del BGP está usando 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
Descripción
El canal de control lógico para GMPLS debe ser un vínculo de punto a punto y debe tener algún tipo de accesibilidad IP. En interfaces de difusión o cuando hay varios saltos entre los 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 de Junos MPLS 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 compatible de la interfaz basada en gre software. Cualquier otro uso no es compatible 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 tenga un salto siguiente 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 en el siguiente 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 show interfaces muestra el tipo de encapsulación y el encabezado, 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: NoneA continuación, se presentan varios requisitos cuando se configura 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 otro.
El túnel GRE se debe configurar indirectamente con la peer-interface
peer-nameinstrucción en el[edit protocol ospf]nivel jerárquico.La interfaz GRE debe estar deshabilitada en los
[edit protocols ospf]niveles de jerarquía y[edit protocols rsvp].Los canales de datos y de control se deben definir correctamente en la configuración de LMP.
Es opcional deshabilitar la primera ruta más corta restringida (CSPF) con la
no-cspfinstrucción.
Este caso se centra en la configuración incorrecta de los puntos de conexión del túnel GRE. Sin embargo, puede usar un proceso y comandos similares para diagnosticar otros problemas de túnel GRE. Figura 13 ilustra una topología de red con MPLS tunelizadas a través de una interfaz GRE.
La topología Figura 13 de red MPLS 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 al enrutador de salida.
En el enrutador de entrada, CSPF se desactivó con la
no-cspfinstrucción en el nivel de jerarquía [edit protocol mpls label-switched-path lsp-name].Enlaces de ingeniería de tráfico y canales de control dentro de la
peerinstrucción en el nivel jerárquico [edit protocols link-management] en todos los enrutadores.Ingeniería de tráfico OSPF y OSPF configurada en todos los enrutadores.
Una referencia a los peer-interface dos OSPF y RSVP en todos los enrutadores.
Un problema de tipo de conmutación 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 resumida de las sesiones de RSVP. Puede usar cualquiera de los comandos para comprobar el estado del LSP. En este caso, 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 útiles a la hora de solucionar un problema. En este tema, se proporciona una breve descripción de cada comando, seguido de un resultado de ejemplo, y una discusión del resultado en relación con el problema.
Puede usar 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 extensivo 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 192.168.4.1 configuración MPLS.
Salida de muestra
Utilice el comando show rsvp session detail comando para mostrar información detallada acerca de 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á caído (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 en 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 mostrar par de administración de vínculos para mostrar la información del vínculo 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 de 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 del resultado muestra la siguiente información:
Nombre del par, tester2 o tester3, que es el mismo en enrutadores vecinos para facilitar la resolución de problemas.
Identificador interno del par, 48428 para tester2 y 48429 para tester3. El identificador interno es un intervalo de valores del 0 al 64 000.
El estado del par, que puede estar arriba o abajo. En este caso, todos los pares están en activo.
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 ser ascendente, descendente o activo.
Los vínculos diseñados por ingeniería de tráfico administrados por su par, lo que indica que el canal gre.0 de control está administrado por tester3.
Salida de muestra
Utilice el comando show link-management te-link para mostrar los recursos utilizados para configurar las rutas de reenvío de conmutación de etiquetas multiprotocolo (MPLS) diseñadas por tráfico.
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 diseñados por tráfico y te-tester3. Los recursos son las interfaces SONET y so-0/0/1. On R1 y R2, tlas interfaces so-0/0/0 SONET se utilizan para el LSPgmpls-r1-to-r3, como se indica Yes en el Used campo.Sin embargo, la interfaz so-0/0/1 SONET activada R3 está desactivada (Dn) y no se utiliza para el LSP (Used No). Se requiere más investigación para descubrir por qué la interfaz SONET está desactivada R3 .
Muestra de Outut
Utilice el comando show log filename para mostrar el contenido del archivo de registro especificado. En este caso, el archivo de registro rsvp.log está configurado en el nivel de jerarquía de [edit protocol rsvp traceoptions]. Cuando se configura el archivo de registro, debe emitir el comando monitor start filename 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 el resultado de 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
El resultado 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 del 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 conexión R2 de la interfaz SONET y R3. Se requiere una investigación más profunda de la configuración de la LMP en R2 y R3 .
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 de tránsito y del enrutador R2 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 te-tester3 enrutador R2 de 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 de 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 de 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 de GMPLS LSP 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 y los comandos correctos para comprobar que el LSP 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
El resultado de ejemplo para el show protocols link-management, show mpls lspy show link-management te-link los comandos del enrutador R3 de entrada muestran que el problema se ha resuelto. La LMP está correctamente configurada, 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 ser el mismo tipo de encapsulación o interfaz. En este caso, se muestra la configuración correcta del canal de datos. Los principios son los mismos para el canal de control.
Configuraciones de 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;
}
}
}
Determinar el estado de LSP
Muestra información detallada sobre los objetos del Protocolo de reserva de recursos (RSVP) y el historial de rutas conmutadas por 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:
Compruebe el estado del LSP
Propósito
Muestra el estado de la ruta conmutada por etiqueta (LSP).
Acción
Para determinar el estado de LSP, en el enrutador de entrada, escriba el siguiente comando de modo operativo de interfaz de línea de comandos (CLI) de Junos OS:
user@host> show mpls lsp
Salida de muestra
nombre de 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 muestra es del enrutador de entrada (R1) y muestra la 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 pasan por este enrutador.
Hay una ruta de entrada de R1 (10.0.0.1) a R6 (10.0.0.6). Esta ruta está activa y está instalada en la tabla de enrutamiento (Rt). El LSP R1-to-R6 es la ruta principal (P) en lugar de la ruta secundaria, y se indica mediante un asterisco (*). La ruta a R6 no contiene una ruta con nombre (ActivePath).
Hay un LSP de salida de R6 a R1. El State sistema 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 de comodín). Hay tres etiquetas entrantes (Labelin) y ninguna etiqueta sale (Labelout) para este LSP.
No hay LSP de tránsito.
Para obtener más información sobre cómo comprobar el estado del LSP, consulte Lista de verificación para trabajar con el modelo de solución de problemas de MPLS por capas.
Mostrar estado extenso sobre el LSP
Propósito
Muestra información extensa acerca de los LSP, incluyendo todos los historiales de estados pasados y las razones por las que un LSP podría haber fallado.
Acción
Para mostrar información extensa acerca de LSP, en el enrutador de entrada, ingrese el siguiente comando del modo operativo de CLI de Junos OS:
user@host> show mpls lsp extensive
Salida de muestra
nombre de 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
La salida de muestra es del enrutador de entrada (R1) y muestra la información de LSP de entrada, salida y tránsito en detalle, incluyendo todos los historiales de estado pasados y las razones por las 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á activa actualmente (State), con una ruta que usa activamente el LSP, R1-to-R6. La ruta LSP activa es la ruta principal. Incluso si el LSP no contiene una primary palabra clave, secondary el enrutador aún trata el LSP como un LSP principal, lo que indica que si el LSP falla, el enrutador intentará señalar 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 en el vínculo menos utilizado de las rutas de igual costo con igual número de saltos. Most-fill Coloca el LSP en el vínculo más utilizado de las rutas de igual costo que comparten un recuento de saltos igual. 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 generalizados (GMPLS) (Packet)que indican IPv4. El Switching type is , Packety el identificador de carga generalizada (GPID) es IPv4.
La ruta principal es la ruta activa, como indica un asterisco (*). El estado del LSP es Up.
El Objeto de ruta explícita (ERO) incluye el costo20 de primera ruta más corta restringida (CSPF) para la ruta física que sigue el LSP. La presencia de la métrica CSPF indica que se trata de un LSP CSPF. La ausencia de la métrica CSPF indica un LSP sin CSPF.
El campo 10.1.13.2 S indica el ERO real. Los mensajes de señalización RSVP fueron estrictamente 10.1.13.2 (como 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 Record Route (RRO) recibido tiene las siguientes marcas 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 solo 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 vínculo sobre el que se enrutaba 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 copia de seguridad 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 copia de seguridad de protección de vínculos, se establece el bit "Protección local disponible", pero el bit de "Protección de nodo" está despejado.
0x10—Preferencia pendiente. El nodo de preferencia establece esta marca si hay una preferencia pendiente en curso para el LSP diseñado para el tráfico. Esto indica al enrutador de borde de etiqueta de entrada (LER) de este LSP que debe reenrutarse.
Para obtener más información sobre los indicadores de protección, consulte referencia de comando de protocolos de enrutamiento y políticas de Junos.
El campo 10.1.13.2.10.1.36.2 es la ruta de registro recibida real (RRO). Tenga en cuenta que las direcciones del RRO campo coinciden con las del ERO campo. Este es el caso normal de los LSP de CSPF. Si las direcciones RRO y ERO no coinciden con un LSP CSPF, el LSP tiene que redirigir o desviar.
Las líneas numeradas del 91 al 42 contienen las 49 entradas más recientes al registro de historial. Cada línea tiene una marca de tiempo. Las entradas más recientes tienen el número más grande del historial de registros y se encuentran en la parte superior del registro, lo que indica que la línea 91 es la entrada de registro del historial más reciente. Cuando lea el registro, comience con la entrada más antigua (42) y la más reciente (91).
El registro de 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 preempejó debido a un ResvTear, se deseleccionó como activo y se desactivó. Al final, el enrutador calculó un ERO CSPF, señaló la llamada, el LSP ideó la RRO listada (línea 90) y se incluyó como activo.
Para obtener más información sobre los mensajes de error, consulte junos MPLS Network Operations Guide Log Reference.
La cantidad total de LSP de entrada que se muestran 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 sistema 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 de comodín). Hay tres etiquetas entrantes (Labelin) y ninguna etiqueta sale (Labelout) para este LSP.
No hay LSP de tránsito.
Para obtener más información sobre cómo comprobar el estado del LSP, consulte Lista de verificación para trabajar con el modelo de solución de problemas de MPLS por capas.
Comprobar que se envían y reciben mensajes de ruta RSVP
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 su red. Por ejemplo, si se producen mensajes de ruta en la salida sin mensajes de Resv, podría indicar que no se están creando rutas conmutadas por etiquetas (LSP).
Acción
Para comprobar que se envían y reciben mensajes de ruta RSVP, escriba el siguiente comando de modo operativo de interfaz de línea de comandos (CLI) de Junos OS:
user@host> show rsvp statistics
Salida de muestra
nombre de 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 envió ni recibió ningún mensaje.
Un total de 5 PathErr mensajes fueron enviados y 10 recibidos. Cuando se producen errores de ruta (generalmente debido a problemas de parámetros en un mensaje de ruta), el enrutador envía un mensaje PathErr de unidifusión al remitente que emitió el mensaje de ruta. En este caso, R1 envió al menos 10 mensajes de ruta con un error, como indican los mensajes de 10 PathErr recibidos R1 . El enrutador descendente envió R1 cinco mensajes de ruta con un error, como lo indican los cinco mensajes PathErr enviados R1 . Los mensajes PathErr se transmiten en la dirección opuesta a los mensajes de ruta.
Un total de 12 PathTear mensajes fueron enviados y 6 recibidos, ninguno en los últimos 5 segundos. A diferencia de los mensajes de PathErr, los mensajes 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 PathTear también se envían y reciben. Sin embargo, si solo se envían mensajes de ruta, solo aparecerán los mensajes PathTear que se envían en la salida.
Se enviaron un total de 80 515 mensajes de reservaResv con el estilo de reserva de filtro fijo (FF) y se recibieron 111 476, ninguno en los últimos 5 segundos. Un FF estilo de 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 de comodín (WF) ni para 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 de Junos MPLS.
No se envían ni reciben otros tipos de mensajes RSVP. Para obtener más información sobre los tipos de mensaje ResvErr, ResvTear y Resvconf, consulte la Guía de configuración de aplicaciones de Junos MPLS.
Los mensajes de actualización de ack y resumen (SRefresh) no aparecen en el resultado. Los mensajes de actualización de ack y resumen 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.
Un total de 915.851 mensajes de saludo fueron enviados y 915.881 recibidos, sin ninguno transmitido o recibido 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 de RSVP. Estos contadores solo se incrementan cuando RSVP reenvía mensajes RSVP heredados emitidos por un cliente de red privada virtual (VPN) para el tránsito a través de la red troncal a los otros sitios de la VPN. Se denominan 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 .