Conectividad
Este capítulo presenta una red Brownfield (contiene sistemas heredados) que utiliza LDP en la periferia, y que se tuneliza a través de un núcleo sólo de RSVP-TE-te. La primera’tarea del capítulo s consiste en introducir la revisión de Sr de manera inteligente y deliberada; a continuación, observará en qué medida puede subsume todas las responsabilidades de distribución de etiquetas.
Es posible que parte de la funcionalidad detallada en este documento todavía no esté disponible para el público en general en el momento en que se publicó este libro. Póngase en contacto con su administrador de cuenta de Juniper para obtener escalas de tiempo.
Disponibilidad
La conectividad esencial de SR se consigue mediante el prefijo de la publicidad y los segmentos de adyacencia. Se indican mediante identificadores de segmento (SID). Existen muchos otros tipos de SID, cada uno de ellos sirve para un propósito diferente, pero estos dos son suficientes para establecer el alcance de la accesibilidad básica. El prefijo y su formato de SID de nodo especializado identifican de forma exclusiva un enrutador de una topología dada, a la que se puede tener acceso a través de un algoritmo de búsqueda de rutas de acceso determinado; el SID de adyacencia identifica un vínculo enrutado a un vecino IGP.
Hay más tipos de segmentos que hay espacio para hablar de ellos. Los segmentos de difusión por proximidad representan un prefijo compartido entre los nodos que podría utilizarse para la redundancia y el uso compartido de carga sencillo y sin estado. Un SID de adyacencia de nivel 2 representa los vínculos de miembro individuales de un paquete de posposición y se espera que se utilice para comprobar el mantenimiento seguros de vínculo por miembro; su corollado es el conjunto de adyacencia que agrupa las adyacencias en un solo segmento. Los SID de enlace representan túneles. Algunos de estos SID se exploran en detalle en la sección de Observability : optimización.
Algunos segmentos se anuncian directamente como etiquetas, como en el caso de los SID de adyacencia; los SID de prefijo y nodo se anuncian indirectamente como índices en un bloque global SR (SRGB). El SRGB representa el espacio de etiqueta que los nodos utilizan para hacer referencia a los segmentos globales. Es una razón por la cual SR no necesita anunciar una etiqueta por cada prefijo aprendido IGP. El SRGB es configurable y, idealmente, coherente en todo el dominio SR.
Hay al menos un segmento asociado con un prefijo IPv4 y posiblemente otro para IPv6. Los segmentos de nodo se asocian’con la dirección de bucle invertido del enrutador. De hecho, se espera que los índices de nodo IPv4 e IPv6 se traten del mismo modo – que el operador y un dominio Sr único administran la dirección de bucle invertido por nodo.
De forma predeterminada, los segmentos de adyacencia se asignan dinámicamente con un pop y se reenvían a través de la acción de adyacencia de la IGP correspondiente. Se utilizan para una dirección estricta, incluida la protección del tráfico. A diferencia de los SID de nodo, los SID de adyacencia tienen la opción de ser local o globalmente significativa (aunque no son frecuentes los SID de adyacencia globalmente significativos).
Hablando de forma rigurosa, los SID de nodo solo son coherentes a nivel global cuando todos los enrutadores comparten una SRGB común. Este es el modo de implementación recomendado. Un SID de nodo coherente de forma global simplifica enormemente las operaciones, incluida la solución de problemas, ya que un enrutador determinado se representa mediante una entrada idéntica en la base de información de reenvío de etiqueta (LFIB) de todos los demás enrutadores del mismo dominio SR.
Brownfields
Nuestra red de ejemplo se muestra en Figure 1la. Se trata de un diseño común para muchos operadores. El servicio de superposición de Internet y VPN se ofrece mediante la combinación de LDP/RSVP-TE como protocolos de distribución de etiquetas, mientras que el de varias áreas es el IGP de elección.
Dado que nuestro enfoque es el subyacente, deje que Internet y L3VPN conectividad sean suficientes como prueba de nuestro trabajo. Por supuesto, cualquier servicio – de MPLS 6PE, 6VPE, L2VPN, EVPN, et. al., – podría entregarse a través de esta misma red.
Para nosotros, vamos’a ejecutar el traceroute del CE en Nueva York (CE1. NYC) a Washington (CE1. IAD).
Por motivos de brevedad, Washington, DC se llama Washington a partir de ahora.
Connectivity verification
user@ce1.nyc> traceroute 198.51.100.54 routing-instance svc-inet traceroute to 198.51.100.54 (198.51.100.54), 30 hops max, 40 byte packets 1 pe1.nyc-ge-0-0-10.1 (198.51.100.1) 2.427 ms 1.646 ms 3.676 ms 2 p2.nyc-ge-0-0-2.0 (192.0.2.7) 70.034 ms p1.nyc-ge-0-0-2.0 (192.0.2.5) 7.387 ms p2.nyc-ge-0-0-2.0 (192.0.2.7) 52.897 ms MPLS Label=119 CoS=0 TTL=1 S=1 3 p1.phl-ge-0-0-2.0 (192.0.2.21) 55.576 ms p2.ewr-ge-0-0-2.0 (192.0.2.17) 6.849 ms p1.phl-ge-0-0-2.0 (192.0.2.21) 80.628 ms MPLS Label=313824 CoS=0 TTL=1 S=0 MPLS Label=352896 CoS=0 TTL=1 S=1 4 p2.iad-ge-0-0-6.0 (192.0.2.28) 7.129 ms p1.iad-ge-0-0-5.0 (192.0.2.30) 80.143 ms 73.898 ms MPLS Label=352896 CoS=0 TTL=1 S=1 5 pe1.iad-ge-0-0-1.0 (192.0.2.36) 6.994 ms 8.681 ms 5.971 ms 6 ce1.iad-ge-0-0-4.0 (198.51.100.54) 8.125 ms 7.631 ms 10.807 ms
Tenga en cuenta que las etiquetas en uso cambiarán una vez que se empiece a utilizar SR.
Por ahora, permita’que s habilite Sr en PE1. NYC y trace cuidadosamente los cambios en el control y en el reenvío de planos.
Enabling SR on pe1.nyc
La SRGB se configura en un rango comprendido entre 1000 y 1127, inclusive. Dentro de ese intervalo, este enrutador representa su dirección IPv4 de bucle de retroceso como 1001 (1000 + 1, su índice IPv4). ’Confirme que es así.
Control plane: node SID verification
user@pe1.nyc> show isis overview Instance: master Router ID: 128.49.106.1 Hostname: pe1.nyc Sysid: 0128.0049.1061 Areaid: 49.0001 Adjacency holddown: enabled Maximum Areas: 3 LSP life time: 1200 Attached bit evaluation: enabled SPF delay: 200 msec, SPF holddown: 5000 msec, SPF rapid runs: 3 Overload bit at startup is set Overload high metrics: disabled Allow route leaking: disabled Allow internal prefix overloading: disabled Allow external prefix overloading: disabled IPv4 is enabled, IPv6 is enabled, SPRING based MPLS is enabled Traffic engineering: enabled Restart: Disabled Helper mode: Enabled Layer2-map: Disabled Source Packet Routing (SPRING): Enabled SRGB Config Range: SRGB Start-Label : 1000, SRGB Index-Range : 128 SRGB Block Allocation: Success SRGB Start Index : 1000, SRGB Size : 128, Label-Range: [ 1000, 1127 ] Node Segments: Enabled Ipv4 Index : 1, Ipv6 Index : 61 Post Convergence Backup: Disabled Level 1 Internal route preference: 15 External route preference: 160 Prefix export count: 0 Wide metrics are enabled Source Packet Routing is enabled Level 2 Internal route preference: 18 External route preference: 165 Prefix export count: 0 Wide metrics are enabled, Narrow metrics are enabled Source Packet Routing is enabled
Aparte del SID del nodo configurado manualmente, vamos’a comprobar que también se han asignado dinámicamente los SID de adyacencia.
Control plane: adjacency SID verification
user@pe1.nyc> show isis database pe1.nyc level 1 extensive IS-IS level 1 link-state database: pe1.nyc.00-00 Sequence: 0x496, Checksum: 0x981e, Lifetime: 771 secs IPV4 Index: 1 Node Segment Blocks Advertised: Start Index : 0, Size : 128, Label-Range: [ 1000, 1127 ] IS neighbor: p2.nyc.00 Metric: 10 Two-way fragment: p2.nyc.00-00, Two-way first fragment: p2.nyc.00-00 P2P IPv4 Adj-SID: 26, Weight: 0, Flags: --VL-- IS neighbor: p1.nyc.00 Metric: 10 Two-way fragment: p1.nyc.00-00, Two-way first fragment: p1.nyc.00-00 P2P IPv4 Adj-SID: 27, Weight: 0, Flags: --VL-- IP prefix: 128.49.106.1/32 Metric: 0 Internal Up Header: LSP ID: pe1.nyc.00-00, Length: 191 bytes Allocated length: 1492 bytes, Router ID: 128.49.106.1 Remaining lifetime: 771 secs, Level: 1, Interface: 0 Estimated free bytes: 1257, Actual free bytes: 1301 Aging timer expires in: 771 secs Protocols: IP, IPv6 Packet: LSP ID: pe1.nyc.00-00, Length: 191 bytes, Lifetime : 1198 secs Checksum: 0x981e, Sequence: 0x496, Attributes: 0x5 <L1 Overload=> NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 18, Packet version: 1, Max area: 0 TLVs: Area address: 49.0001 (3) LSP Buffer Size: 1492 Speaks: IP Speaks: IPV6 IP router id: 128.49.106.1 IP address: 128.49.106.1 Hostname: pe1.nyc Router Capability: Router ID 128.49.106.1, Flags: 0x00 SPRING Capability - Flags: 0xc0(I:1,V:1), Range: 128, SID-Label: 1000 SPRING Algorithm - Algo: 0 Extended IS Reachability TLV, Type: 22, Length: 80 IS extended neighbor: p2.nyc.00, Metric: default 10 SubTLV len: 29 IP address: 192.0.2.6 Neighbor’s IP address: 192.0.2.7 Local interface index: 336, Remote interface index: 334 P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0,P:0), Weight:0, Label: 26 P2P IPv4 Adj-SID: 26, Weight: 0, Flags: --VL-- IS extended neighbor: p1.nyc.00, Metric: default 10 SubTLV len: 29 IP address: 192.0.2.4 Neighbor’s IP address: 192.0.2.5 Local interface index: 335, Remote interface index: 334 P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0,P:0), Weight:0, Label: 27 P2P IPv4 Adj-SID: 27, Weight: 0, Flags: --VL-- IP extended prefix: 128.49.106.1/32 metric 0 up 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 1 No queued transmissions </L1
Hay un SID de adyacencia en cada uno de PE1’. NYC s es-es vecinos. Además, el SID del nodo se realza como un sub-TLV del TLV del prefijo extendido IP. Las marcas también aclaran y contrastan los dos tipos de SID. ‘V’ indica si el subTLV contiene un valor (como en el caso de un SID de adyacencia) o un índice (como con un SID de nodo). ‘L’ representa el significado de local frente a global. Por último, ‘el’ indicador N indica que un SID de prefijo determinado es más específicamente un SID de nodo que se adjunta’a la dirección del bucle de retroceso del enrutador.
Forwarding plane: PE1’s FIB
user@pe1.nyc> show route table mpls.0 protocol isis mpls.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 26 *[L-ISIS/14] 00:44:02, metric 0 > to 192.0.2.7 via ge-0/0/2.0, Pop 26(S=0) *[L-ISIS/14] 00:02:40, metric 0 > to 192.0.2.7 via ge-0/0/2.0, Pop 27 *[L-ISIS/14] 00:44:02, metric 0 > to 192.0.2.5 via ge-0/0/1.0, Pop 27(S=0) *[L-ISIS/14] 00:02:40, metric 0 > to 192.0.2.5 via ge-0/0/1.0, Pop
L-Isis significa que es-IS-IS. Los SID de adyacencia están instalados en el FIB, pero parece que falta el SID del nodo. Esto es normal. Dado que ‘la’ marca P (php desactivado) no se estableció, este enrutador no espera recibir paquetes con la etiqueta superior 1001. En su lugar, los vecinos lo extraen 1001 (una vez que están habilitados para SR). Esto es análogo al comportamiento nulo implícito utilizado por los protocolos tradicionales de distribución de etiquetas.
Inter-area
Dado que ninguno de los otros enrutadores está actualmente habilitado para SR,’PE1. NYC’s todavía lo aprendieron los enrutadores externos de área. Enrutadores dentro del área, como PE2. NYC, se explican pero se omiten.
user@ce1.nyc> traceroute 198.51.100.54 routing-instance svc-inet traceroute to 198.51.100.54 (198.51.100.54), 30 hops max, 40 byte packets 1 pe1.nyc-ge-0-0-10.1 (198.51.100.1) 6.659 ms 2.265 ms 2.116 ms 2 p2.nyc-ge-0-0-2.0 (192.0.2.7) 8.626 ms 8.556 ms 13.895 ms MPLS Label=119 CoS=0 TTL=1 S=1 3 p2.ewr-ge-0-0-2.0 (192.0.2.17) 20.193 ms p1.phl-ge-0-0-2.0 (192.0.2.21) 18.045 ms 11.514 ms MPLS Label=313824 CoS=0 TTL=1 S=0 MPLS Label=352896 CoS=0 TTL=1 S=1 4 p1.iad-ge-0-0-5.0 (192.0.2.30) 10.881 ms 9.305 ms 8.683 ms MPLS Label=352896 CoS=0 TTL=1 S=1 5 pe1.iad-ge-0-0-1.0 (192.0.2.36) 8.032 ms pe1.iad-ge-0-0-2.0 (192.0.2.38) 8.232 ms pe1.iad-ge-0-0-1.0 (192.0.2.36) 7.529 ms 6 ce1.iad-ge-0-0-4.0 (198.51.100.54) 15.007 ms 10.747 ms 12.320 ms
No ha cambiado nada, como cabría esperar. Etiquetada IS-IS tiene una preferencia de protocolo más baja que LDP o RSVP-TE, y requiere la intervención del operador para comenzar a usarse. No se produce el reenvío SR ya que nuestro dominio SR es una isla de uno, tal y Figure 2como se muestra en la. En la sección siguiente,’configuramos los SID de nodo en todos los enrutadores de Nueva York (que también comparten un área de IS-IS común), comenzando con el anexo-L2 adjunto P1. nyc.
Enabling SR on p1.nyc
Control plane
Deje’que s Compruebe lo que ha cambiado más rápidamente y brevemente esta vez. El resultado abreviado se mostrará para destacar los puntos de interés indicados por…puntos suspensivos ().
user@p1.nyc> show isis database extensive p1.nyc IS-IS level 1 link-state database: p1.nyc.00-00 Sequence: 0x4b8, Checksum: 0x6c1a, Lifetime: 546 secs IPV4 Index: 3 Node Segment Blocks Advertised: Start Index : 0, Size : 128, Label-Range: [ 1000, 1127 ] IS neighbor: pe2.nyc.00 Metric: 10 Two-way fragment: pe2.nyc.00-00, Two-way first fragment: pe2.nyc.00-00 P2P IPv4 Adj-SID: 30, Weight: 0, Flags: --VL-- IS neighbor: pe1.nyc.00 Metric: 10 Two-way fragment: pe1.nyc.00-00, Two-way first fragment: pe1.nyc.00-00 P2P IPv4 Adj-SID: 31, Weight: 0, Flags: --VL-- IS neighbor: p2.nyc.00 Metric: 10 Two-way fragment: p2.nyc.00-00, Two-way first fragment: p2.nyc.00-00 P2P IPv4 Adj-SID: 32, Weight: 0, Flags: --VL-- ... TLVs: ... IP extended prefix: 128.49.106.3/32 metric 0 up 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 3 IS-IS level 2 link-state database: p1.nyc.00-00 Sequence: 0x758, Checksum: 0xc13, Lifetime: 967 secs IPV4 Index: 3 Node Segment Blocks Advertised: Start Index : 0, Size : 128, Label-Range: [ 1000, 1127 ] IS neighbor: p2.nyc.00 Metric: 999999 Two-way fragment: p2.nyc.00-00, Two-way first fragment: p2.nyc.00-00 P2P IPv4 Adj-SID: 33, Weight: 0, Flags: --VL-- IS neighbor: p1.ewr.00 Metric: 10 Two-way fragment: p1.ewr.00-00, Two-way first fragment: p1.ewr.00-00 P2P IPv4 Adj-SID: 29, Weight: 0, Flags: --VL-- IS neighbor: p1.phl.00 Metric: 10 Two-way fragment: p1.phl.00-00, Two-way first fragment: p1.phl.00-00 P2P IPv4 Adj-SID: 28, Weight: 0, Flags: --VL-- ... TLVs: ... IP extended prefix: 128.49.106.3/32 metric 0 up 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 3 IP extended prefix: 128.49.106.1/32 metric 10 up 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0xe0(R:1,N:1,P:1,E:0,V:0,L:0), Algo: SPF(0), Value: 1
En comparación con PE1. NYC, aparentes dos diferencias. Como enrutador de borde de área (ABR), P1. NYC no solo anuncia su propio SID de nodo en las áreas L1 y L2, sino que también vuelve a originar’PE1. anuncio de SID del nodo NYC s en todas las áreas. Esto permite la aprendizaje de los segmentos globales en todas IGP áreas. El ‘indicador’ R indica que el SID de este nodo se está volviendo a anunciar a través de áreas o niveles.
De forma crucial, ‘el’ indicador P se establece en este SID del nodo que se vuelve a anunciar, lo que resulta muy’bien contrasta con P1. NYC s propietario de nodo. Esto indica a los vecinos compatibles con SR que P1. NYC espera que utilicen la acción continuar (swap) y mantengan la etiqueta superior que interpreta como instrucción de reenvío para PE1. nyc.
Forwarding plane: P1’s FIB
Podemos confirmar que P1. NYC ha instalado una entrada para la etiqueta 1001, que representa PE1. NYC’s SID de nodo:
user@p1.nyc> show route table mpls.0 protocol isis mpls.0: 31 destinations, 31 routes (31 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 28 *[L-ISIS/14] 00:34:55, metric 0 > to 192.0.2.21 via ge-0/0/5.0, Pop 28(S=0) *[L-ISIS/14] 00:09:21, metric 0 > to 192.0.2.21 via ge-0/0/5.0, Pop 29 *[L-ISIS/14] 00:34:55, metric 0 > to 192.0.2.15 via ge-0/0/4.0, Pop 29(S=0) *[L-ISIS/14] 00:09:21, metric 0 > to 192.0.2.15 via ge-0/0/4.0, Pop 30 *[L-ISIS/14] 00:34:55, metric 0 > to 192.0.2.8 via ge-0/0/3.0, Pop 30(S=0) *[L-ISIS/14] 00:07:10, metric 0 > to 192.0.2.8 via ge-0/0/3.0, Pop 31 *[L-ISIS/14] 00:34:55, metric 0 > to 192.0.2.4 via ge-0/0/2.0, Pop 31(S=0) *[L-ISIS/14] 00:07:10, metric 0 > to 192.0.2.4 via ge-0/0/2.0, Pop 32 *[L-ISIS/14] 00:34:55, metric 0 > to 192.0.2.13 via ge-0/0/1.0, Pop 32(S=0) *[L-ISIS/14] 00:07:10, metric 0 > to 192.0.2.13 via ge-0/0/1.0, Pop 33 *[L-ISIS/14] 00:34:55, metric 0 > to 192.0.2.13 via ge-0/0/1.0, Pop 33(S=0) *[L-ISIS/14] 00:09:21, metric 0 > to 192.0.2.13 via ge-0/0/1.0, Pop 1001 *[L-ISIS/14] 00:34:55, metric 10 > to 192.0.2.4 via ge-0/0/2.0, Pop 1001(S=0) *[L-ISIS/14] 00:07:10, metric 10 > to 192.0.2.4 via ge-0/0/2.0, Pop
No solo puede ver una acción pop (la MPLS versión de plano’de reenvío continuede la s) para la etiqueta entrante 1001, puede ver las acciones pop para las etiquetas SID de adyacencia 28-33.
Forwarding plane: PE1’s FIB
user@pe1.nyc> show route protocol isis table mpls.0 mpls.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 26 *[L-ISIS/14] 02:06:55, metric 0 > to 192.0.2.7 via ge-0/0/2.0, Pop 26(S=0) *[L-ISIS/14] 00:10:50, metric 0 > to 192.0.2.7 via ge-0/0/2.0, Pop 27 *[L-ISIS/14] 00:48:12, metric 0 > to 192.0.2.5 via ge-0/0/1.0, Pop 27(S=0) *[L-ISIS/14] 00:10:50, metric 0 > to 192.0.2.5 via ge-0/0/1.0, Pop 1003 *[L-ISIS/14] 00:35:14, metric 10 > to 192.0.2.5 via ge-0/0/1.0, Pop 1003(S=0) *[L-ISIS/14] 00:10:50, metric 10 > to 192.0.2.5 via ge-0/0/1.0, Pop
En PE1. NYC ahora hay una entrada de reenvío para la etiqueta 1003, que representa el’SID del nodo de P1. nyc.
Inter-area
Distinto de PE1. NYC, ninguno de P1. NYC’s otros vecinos son compatibles con Sr. Todos los vecinos L2 aprenden, pero ignoran, los segmentos.
Connectivity verification
user@ce1.nyc> traceroute 198.51.100.54 routing-instance svc-inet traceroute to 198.51.100.54 (198.51.100.54), 30 hops max, 40 byte packets 1 pe1.nyc-ge-0-0-10.1 (198.51.100.1) 3.118 ms 2.042 ms 1.803 ms 2 p2.nyc-ge-0-0-2.0 (192.0.2.7) 7.747 ms p1.nyc-ge-0-0-2.0 (192.0.2.5) 101.823 ms p2.nyc-ge-0-0-2.0 (192.0.2.7) 23.312 ms MPLS Label=119 CoS=0 TTL=1 S=1 3 p1.phl-ge-0-0-2.0 (192.0.2.21) 7.152 ms p2.ewr-ge-0-0-2.0 (192.0.2.17) 69.566 ms 67.497 ms MPLS Label=314 CoS=0 TTL=1 S=0 MPLS Label=355776 CoS=0 TTL=1 S=1 4 p1.iad-ge-0-0-5.0 (192.0.2.30) 11.528 ms 9.755 ms p2.iad-ge-0-0-6.0 (192.0.2.28) 6.276 ms MPLS Label=355776 CoS=0 TTL=1 S=1 5 pe1.iad-ge-0-0-1.0 (192.0.2.36) 5.667 ms 8.056 ms pe1.iad-ge-0-0-2.0 (192.0.2.38) 10.915 ms 6 ce1.iad-ge-0-0-4.0 (198.51.100.54) 169.285 ms 11.048 ms 9.896 ms
No tan emocionante como la falta de cambio en el comportamiento de reenvío, esto es tranquilizador. La habilitación de SR no cambia sin querer, lo que deja de daños de manera autónoma, los servicios existentes. Después de todo, es preferible una implementación controlada.
Enabling SR on the remaining New York routers
Control plane
En este punto, sabrá qué se debe esperar. Dos nuevos SID de nodo se anunciarían en el área L1; el SID del’nodo PE2. NYC se volvería a anunciar en P1. NYC y P2. NYC en el subdominio L2. Como PE1. NYC’antes de hacerlo, los enrutadores L2 no compatibles con Sr no podrán pasarlos por ahora. Veamos’:
user@p2.nyc> show isis database p2.nyc extensive IS-IS level 1 link-state database: p2.nyc.00-00 Sequence: 0x4a3, Checksum: 0x28ab, Lifetime: 851 secs IPV4 Index: 2 Node Segment Blocks Advertised: Start Index : 0, Size : 128, Label-Range: [ 1000, 1127 ] IS neighbor: pe2.nyc.00 Metric: 10 Two-way fragment: pe2.nyc.00-00, Two-way first fragment: pe2.nyc.00-00 P2P IPv4 Adj-SID: 265, Weight: 0, Flags: --VL-- IS neighbor: pe1.nyc.00 Metric: 10 Two-way fragment: pe1.nyc.00-00, Two-way first fragment: pe1.nyc.00-00 P2P IPv4 Adj-SID: 266, Weight: 0, Flags: --VL-- IS neighbor: p1.nyc.00 Metric: 10 Two-way fragment: p1.nyc.00-00, Two-way first fragment: p1.nyc.00-00 P2P IPv4 Adj-SID: 267, Weight: 0, Flags: --VL-- ... TLVs: ... IP extended prefix: 128.49.106.2/32 metric 0 up 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 2 IS-IS level 2 link-state database: p2.nyc.00-00 Sequence: 0x4a0, Checksum: 0x8f75, Lifetime: 851 secs IPV4 Index: 2 Node Segment Blocks Advertised: Start Index : 0, Size : 128, Label-Range: [ 1000, 1127 ] IS neighbor: p1.nyc.00 Metric: 999999 Two-way fragment: p1.nyc.00-00, Two-way first fragment: p1.nyc.00-00 P2P IPv4 Adj-SID: 268, Weight: 0, Flags: --VL-- IS neighbor: p2.ewr.00 Metric: 10 Two-way fragment: p2.ewr.00-00, Two-way first fragment: p2.ewr.00-00 P2P IPv4 Adj-SID: 264, Weight: 0, Flags: --VL-- IS neighbor: p2.phl.00 Metric: 10 Two-way fragment: p2.phl.00-00, Two-way first fragment: p2.phl.00-00 P2P IPv4 Adj-SID: 263, Weight: 0, Flags: --VL-- ... TLVs: ... IP extended prefix: 128.49.106.2/32 metric 0 up 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 2 IP extended prefix: 128.49.106.0/32 metric 10 up 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0xe0(R:1,N:1,P:1,E:0,V:0,L:0), Algo: SPF(0), Value: 0 IP extended prefix: 128.49.106.1/32 metric 10 up 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0xe0(R:1,N:1,P:1,E:0,V:0,L:0), Algo: SPF(0), Value: 1 IP extended prefix: 128.49.106.3/32 metric 10 up 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0xe0(R:1,N:1,P:1,E:0,V:0,L:0), Algo: SPF(0), Value: 3
Ahora debería ser familiar, que hay SID de proximidad para cada uno, es vecino (compatible con SR o no), así como SID de nodo (se vuelve a anunciar en todos los casos menos uno) para todos los enrutadores compatibles con SR.
Connectivity verification
user@ce1.nyc> traceroute 198.51.100.54 routing-instance svc-inet traceroute to 198.51.100.54 (198.51.100.54), 30 hops max, 40 byte packets 1 pe1.nyc-ge-0-0-10.1 (198.51.100.1) 27.852 ms 38.214 ms 2.399 ms 2 p2.nyc-ge-0-0-2.0 (192.0.2.7) 8.883 ms p1.nyc-ge-0-0-2.0 (192.0.2.5) 7.776 ms p2.nyc-ge-0-0-2.0 (192.0.2.7) 6.584 ms MPLS Label=119 CoS=0 TTL=1 S=1 3 p1.phl-ge-0-0-2.0 (192.0.2.21) 6.929 ms p2.ewr-ge-0-0-2.0 (192.0.2.17) 7.092 ms 8.230 ms MPLS Label=314 CoS=0 TTL=1 S=0 MPLS Label=355776 CoS=0 TTL=1 S=1 4 p1.iad-ge-0-0-5.0 (192.0.2.30) 7.097 ms 6.988 ms p2.iad-ge-0-0-6.0 (192.0.2.28) 7.142 ms MPLS Label=355776 CoS=0 TTL=1 S=1 5 pe1.iad-ge-0-0-1.0 (192.0.2.36) 6.132 ms pe1.iad-ge-0-0-2.0 (192.0.2.38) 8.677 ms 5.444 ms 6 ce1.iad-ge-0-0-4.0 (198.51.100.54) 11.672 ms 9.005 ms 7.873 ms
Por último, puede confirmar que no hay cambios en el reenvío de tráfico.
Todo este trabajo a sin fin? Apenas. Se ha comprobado que la activación del plano de control SR no obliga a un operador a utilizar inmediatamente su plano de reenvío. De hecho, es probable que esto sea el primer paso de cualquier migración a – verificación del avión de control de Sr junto con el cumplimiento continuo del servicio.
Cambiar a SR
SR está ahora activado en Nueva York. Todo lo que se necesita para hacer el ajuste es una preferencia de protocolo en un enrutador de entrada. Hasta ahora, hemos estado probando el reenvío entre CEs en Nueva York y Washington. Dado que nuestro dominio SR está restringido a lo primero, deje’que se verifique rápidamente la conectividad entre los CES de la región.
Connectivity verification
user@ce1.nyc> traceroute routing-instance svc-inet 198.51.100.0 traceroute to 198.51.100.0 (198.51.100.0), 30 hops max, 40 byte packets 1 pe2.nyc-ge-0-0-10.1 (198.51.100.3) 235.860 ms 226.521 ms 69.491 ms 2 p1.nyc-ge-0-0-3.0 (192.0.2.9) 11.960 ms 4.510 ms p2.nyc-ge-0-0-3.0 (192.0.2.11) 4.477 ms MPLS Label=257 CoS=0 TTL=1 S=1 3 pe1.nyc-ge-0-0-1.0 (192.0.2.4) 3.625 ms 4.503 ms pe1.nyc-ge-0-0-2.0 (192.0.2.6) 5.833 ms 4 ce1.nyc-ge-0-0-1.1 (198.51.100.0) 6.088 ms 6.480 ms 7.580 ms
Ninguna etiqueta SR está en uso. Esto tiene sentido ya que PE2. NYC, el enrutador de entrada sigue preferentemente los saltos siguientes de LDP al hacer BGP la resolución de rutas de servicio.
Control plane
Permita’que s Compruebe la ruta de servicio y su siguiente salto en el PE de entrada:
user@pe2.nyc> show route 198.51.100.0 active-path extensive inet.0: 30 destinations, 37 routes (30 active, 0 holddown, 0 hidden) 198.51.100.0/31 (2 entries, 1 announced) ... Indirect next hops: 1 Protocol next hop: 128.49.106.1 Metric: 1 Indirect next hop: 0xba57f80 1048577 INH Session ID: 0x165 Indirect path forwarding next hops: 2 Next hop type: Router Next hop: 192.0.2.9 via ge-0/0/1.0 weight 0x1 Session Id: 0x0 Next hop: 192.0.2.11 via ge-0/0/2.0 weight 0x1 Session Id: 0x0 user@pe2.nyc> show route 128.49.106.1 table inet.3 inet.3: 8 destinations, 11 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 128.49.106.1/32 *[LDP/9] 00:54:50, metric 1 to 192.0.2.9 via ge-0/0/1.0, Push 18 > to 192.0.2.11 via ge-0/0/2.0, Push 257 [L-ISIS/14] 00:54:29, metric 20 to 192.0.2.9 via ge-0/0/1.0, Push 1001 > to 192.0.2.11 via ge-0/0/2.0, Push 1001 user@pe2.nyc> show isis adjacency Interface System L State Hold (secs) SNPA ge-0/0/1.0 p1.nyc 1 Up 26 ge-0/0/2.0 p2.nyc 1 Up 26 user@pe2.nyc> show ldp database | match “put|128.49.106.1/32” Input label database, 128.49.106.0:0--128.49.106.2:0 257 128.49.106.1/32 ...
El BGP ruta que’remitimos se aprendirá con un siguiente salto – de protocolo de 128.49.106.1 se’trata de la dirección de bucle de retroceso PE1. NYC s. Se asocia una etiqueta a esta clase de equivalencia de reenvío (FEC) de los vecinos LDP y SR (L-ISIS de las siglas IS-IS). El primero cuenta con una preferencia de protocolo superior, que conduce a PE2. NYC imponiendo la etiqueta 257 aprendida por LDP del vecino elegido (P2. NYC).
Dado que ECMP está en vigor, PE2. NYC también podría tener la etiqueta 18, anunciada por P1. NYC para el mismo FEC. Se trata de una decisión del plano de reenvío. Es el resultado de aplicar un algoritmo hash a los encabezados de paquetes entrantes y utilizar el resultado para seleccionar una sola ruta saliente para cada flujo.
Para hacer el cambio, deje’que se mejore la preferencia de protocolo de L-Isis en PE2. nyc.
Prefer SR for intra-region traffic originating at pe2.nyc
Control plane: confirm pe2.nyc performs route resolution using SR instead of LDP
user@pe2.nyc> show route 128.49.106.1 table inet.3 inet.3: 8 destinations, 11 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 128.49.106.1/32 *[L-ISIS/8] 00:00:41, metric 20 to 192.0.2.9 via ge-0/0/1.0, Push 1001 > to 192.0.2.11 via ge-0/0/2.0, Push 1001 [LDP/9] 01:10:36, metric 1 to 192.0.2.9 via ge-0/0/1.0, Push 18 > to 192.0.2.11 via ge-0/0/2.0, Push 257
Ahora, el protocolo Next hop es preferible a la etiqueta SR divined (1001,’PE1. NYC de nodo s SID). Esto debería haber afectado (por fin) al plano de reenvío.
Connectivity verification: intra-NY traffic is SR-switched
user@ce1.nyc> traceroute routing-instance svc-inet 198.51.100.0 traceroute to 198.51.100.0 (198.51.100.0), 30 hops max, 40 byte packets 1 pe2.nyc-ge-0-0-10.1 (198.51.100.3) 2.903 ms 3.001 ms 1.934 ms 2 p2.nyc-ge-0-0-3.0 (192.0.2.11) 5.263 ms p1.nyc-ge-0-0-3.0 (192.0.2.9) 35.811 ms 87.604 ms MPLS Label=1001 CoS=0 TTL=1 S=1 3 pe1.nyc-ge-0-0-1.0 (192.0.2.4) 188.617 ms 47.428 ms 8.965 ms 4 ce1.nyc-ge-0-0-1.1 (198.51.100.0) 10.858 ms 5.580 ms 5.275 ms
Observe el cambio en la etiqueta insertado por PE2. NYC de 257 a 1001. Esto confirma que el tráfico del dominio SR está ejerciendo los segmentos de tejidos de los LSP. Para asegurarse de que todo el tráfico de la regional no se vea afectado por el cambio de preferencias del protocolo en PE2. NYC, un seguimiento hacia el destino de todo el país en Washington, sigue siendo tradicionalmente conmutado por etiqueta.
Connectivity verification: extra-NY traffic still uses LDP
user@ce1.nyc> traceroute 198.51.100.54 routing-instance svc-inet traceroute to 198.51.100.54 (198.51.100.54), 30 hops max, 40 byte packets 1 pe2.nyc-ge-0-0-10.1 (198.51.100.3) 49.540 ms 78.154 ms 68.680 ms 2 p1.nyc-ge-0-0-3.0 (192.0.2.9) 62.733 ms 64.765 ms p2.nyc-ge-0-0-3.0 (192.0.2.11) 64.562 ms MPLS Label=119 CoS=0 TTL=1 S=1 3 p1.phl-ge-0-0-2.0 (192.0.2.21) 60.903 ms 6.794 ms p2.ewr-ge-0-0-2.0 (192.0.2.17) 33.531 ms MPLS Label=314 CoS=0 TTL=1 S=0 MPLS Label=355776 CoS=0 TTL=1 S=1 4 p2.iad-ge-0-0-6.0 (192.0.2.28) 6.553 ms p1.iad-ge-0-0-5.0 (192.0.2.30) 96.063 ms 67.346 ms MPLS Label=352896 CoS=0 TTL=1 S=1 5 pe1.iad-ge-0-0-2.0 (192.0.2.38) 8.891 ms pe1.iad-ge-0-0-1.0 (192.0.2.36) 6.837 ms 6.421 ms 6 ce1.iad-ge-0-0-4.0 (198.51.100.54) 30.158 ms 108.181 ms 84.979 ms
Ahora que nos hemos convencido de que no hay ninguna descontinuidad del servicio como resultado de nuestras acciones,’deje que s Mirror PE2. NYC’s preferencia Sr en todos los enrutadores de Nueva York. La configuración es idéntica:
En este momento, los enrutadores de Nueva York prefieren a LDP la resolución de próximo salto en otros enrutadores de Nueva York. Los enrutadores externos a la región permanecen sin SR y el tráfico sigue enviándose sin interrupciones.
Clase de conservación de servicios
Ahora que nuestra isla funciona, echemos’un vistazo breve a la forma en que Sr es compatible con redes que ofrecen SLA estrictos en torno al tiempo activo y clase de servicio (COS). Una técnica ampliamente desplegada consiste en deshabilitar el penúltimo salto (PHP) en favor del comportamiento pop-like (UHP) del último salto. Dado que SR no envía directamente los SID de los nodos como etiquetas, utiliza indicadores para solicitar un comportamiento UHP de enrutadores de nivel superior. Dejemos’activar UHP en PE1. NYC y revise el cambio en su FIB’ Neighbors.
Enable explicit-null UHP behavior on egress router pe1.nyc
Control plane: verify the change in pe1.nyc’s IS-IS LSP
user@pe1.nyc> show isis database pe1.nyc extensive IS-IS level 1 link-state database: pe1.nyc.00-00 Sequence: 0x4d4, Checksum: 0x4f97, Lifetime: 1195 secs IPV4 Index: 1 ... IP extended prefix: 128.49.106.1/32 metric 0 up \ 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0x70(R:0,N:1,P:1,E:1,V:0,L:0), Algo: SPF(0), Value: 1
A diferencia de lo que ocurre con la salida anterior, PE1. NYC anuncia ahora su SID de nodo con el‘P’(PHP-desactivado o deshabilitar PHP) y‘E’(habilite los marcadores Explicit-null o use reservó Label 0).
Esto conduce sus vecinos, P1. NYC y P2. NYC, para usar la acción continuar (swap) en lugar de la siguiente (pop) para la etiqueta 1001 (PE1.’NYC el índice de nodo es 1, y la red utiliza un sRGB común de 1K, tal y como se explicó anteriormente). No hay ningún cambio en PE2. NYC’s FIB. No está conectado directamente a PE1. nyc. Los comportamientos de PHP y UHP solo son relevantes para los enrutadores inmediatamente en el mismo nivel.
Forwarding plane: verify pe1.nyc neighbors’ FIB
user@p1.nyc> show route label 1001 mpls.0: 35 destinations, 35 routes (35 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1001 *[L-ISIS/8] 00:04:03, metric 10 > to 192.0.2.4 via ge-0/0/2.0, Swap 0 1001(S=0) *[L-ISIS/8] 00:04:03, metric 10 > to 192.0.2.4 via ge-0/0/2.0, Pop user@p2.nyc> show route label 1001 mpls.0: 40 destinations, 40 routes (40 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1001 *[L-ISIS/8] 00:04:05, metric 10 > to 192.0.2.6 via ge-0/0/2.0, Swap 0 1001(S=0) *[L-ISIS/8] 00:04:05, metric 10 > to 192.0.2.6 via ge-0/0/2.0, Pop user@pe2.nyc> show route label 1001 mpls.0: 26 destinations, 26 routes (26 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1001 *[L-ISIS/8] 09:14:56, metric 20 to 192.0.2.9 via ge-0/0/1.0, Swap 1001 > to 192.0.2.11 via ge-0/0/2.0, Swap 1001
Tanto P1 como P2 están cambiando ahora la etiqueta 1001 con la etiqueta 0, que es la etiqueta null de IPv4 explícitamente conocida. Esta etiqueta garantiza que el MPLS clase de tráfico (anteriormente conocido también como bits experimentales) se copie de forma coherente en el último enrutador de saltos. En ese último salto, se saca la etiqueta 0 y se produce una búsqueda IPv4. La existencia de la etiqueta 0 ha habilitado la conservación y transparencia de la CES.
Antes de continuar, tenga en cuenta que UHP también está habilitado en PE2. nyc.
Protección y restauración del tráfico
Las redes de paquetes han sido mucho tiempo capaces de brindar protección dentro del 50ms del fallo, mediante el paso de las barras establecidas por las redes SONET/SDH. La reenrutación rápida basada en IP (FRR) está disponible para LDP como alternativa sin bucles (LFA) y LFA remotos (rLFA). A su vez, RSVP-TE tiene mecanismos completos para proteger contra la pérdida de recursos de vínculos, nodos o uso compartido de suplantación identificados como grupos de vínculos de riesgo compartido (SRLG).
Ninguno de los enfoques se encuentra sin sus salvedades. LFA depende de la topología en su capacidad de proporcionar protección; rLFA mejora esto, a costa de la complejidad y el estado de sesión LDP agregados y destinados. RSVP-TE tiene el conjunto de características más completo, lo que depende de la señal y el mantenimiento de estado adicionales de LSP y Detour.
La’capacidad de la Sr de origen para dirigir la ruta, el control explícito y la falta de control de tránsito estado del plano se presta bien para establecer rutas de protección local sin costo. Mientras haya redundancia física en una topología, la alternativa de bucle independiente de la topología (TI-LFA) buscará rutas alternativas. Puede volver a enrutar los vínculos protegidos, los nodos o los grupos de uso compartido de destino definidos localmente. Otra mejora con respecto a las tecnologías de protección erstwhile es que las rutas de protección de TI LFA son también ECMPs.
La protección de LFA TI es local en el punto de la reparación local (PLR). Los paths de backup se han computado previamente pero no se han señalado previamente. No hay punto de combinación singular (MP), ya que cada punto de liberación puede optimizarse por prefijo. Los trazados precalculados eliminan o reducen considerablemente el recurso protegido de la topología para calcular rutas de convergencia posteriores a la IGP. Un fallo del recurso protegido da como resultado una única actualización del plano de datos, que combina la reparación local y la global en un solo paso.
Deje’que se active la protección de vínculos en P1. NYC y observe el cambio resultante en sus vecinos de Sr.
Enable TI-LFA link protection for all level 1 links on p1.nyc
Control plane: verify p1.nyc is announcing its adjacency SIDs as protection-eligible
user@p1.nyc> show isis database extensive p1.nyc level 1 IS-IS level 1 link-state database: p1.nyc.00-00 Sequence: 0x510, Checksum: 0x192f, Lifetime: 1078 secs IPV4 Index: 3 Node Segment Blocks Advertised: Start Index : 0, Size : 128, Label-Range: [ 1000, 1127 ] IS neighbor: pe2.nyc.00 Metric: 10 Two-way fragment: pe2.nyc.00-00, Two-way first fragment: pe2.nyc.00-00 P2P IPv4 Adj-SID: 47, Weight: 0, Flags: -BVL-- IS neighbor: pe1.nyc.00 Metric: 10 Two-way fragment: pe1.nyc.00-00, Two-way first fragment: pe1.nyc.00-00 P2P IPv4 Adj-SID: 48, Weight: 0, Flags: -BVL-- IS neighbor: p2.nyc.00 Metric: 10 Two-way fragment: p2.nyc.00-00, Two-way first fragment: p2.nyc.00-00 P2P IPv4 Adj-SID: 35, Weight: 0, Flags: -BVL—
El ‘indicador’ B señala que P1. NYC considera estos identificadores de SID de adyacencia para su protección. Echemos’un vistazo a uno de estos en – detail SID 47, que representa el vínculo a PE2. nyc.
Forwarding plane: verify p1.nyc has installed backup paths for protection-eligible SIDs
user@p1.nyc> show route label 47 extensive mpls.0: 35 destinations, 35 routes (35 active, 0 holddown, 0 hidden) … Next hop: 192.0.2.8 via ge-0/0/3.0 weight 0x1, selected Label operation: Pop … Next hop: 192.0.2.13 via ge-0/0/1.0 weight 0xf000 Label operation: Swap 1000 user@p1.nyc> show isis adjacency Interface System L State Hold (secs) SNPA ge-0/0/1.0 p2.nyc 3 Up 23 ... ge-0/0/3.0 pe2.nyc 1 Up 20
Hay dos saltos siguientes distintos, que se acaban de agregar como copia de seguridad. Tenga en cuenta que P1’. NYC s calculód backup para alcanzar PE2. NYC, evitando el vínculo protegido GE-0/0/3, es a través de P2. nyc. La acción principal de la etiqueta entrante 47 sería pop y enviarla directamente a PE2. nyc. La acción de copia de seguridad es intercambiarla para’PE2. NYC del nodo SID (etiqueta 1000) y enviar a P2. NYC, Figure 3como se muestra en la. En ese enrutador, la etiqueta se intercambia por 0, como resultado de PE2. NYC anunciar su alcance de acceso a través de un valor null explícito.
Forwarding plane: verify p2.nyc acts as a transit router on this stateless protection path
user@p2.nyc> show route label 1000 mpls.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1000 *[L-ISIS/8] 12:18:02, metric 10 > to 192.0.2.10 via ge-0/0/3.0, Swap 0 1000(S=0) *[L-ISIS/8] 00:03:43, metric 10 > to 192.0.2.10 via ge-0/0/3.0, Pop
Esto concluye la primera pierna: SR está habilitado y en uso está activo, aunque se encuentre en una parte de la red. La accesibilidad y la capacidad para conservar los marcadores CoS, además de ofrecer protección de tráfico sin estado y restauración.
El siguiente paso consiste en Broach SR en el resto de la red.