Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Interoperabilidad

 

Como se sabe en el capítulo sobre Connectivity , Nueva York ha pasado a usar Sr para todo el tráfico dentro de cada región. El tráfico extra de la región sigue dependiendo de LDP, que continúa ejecutándose en todos los enrutadores de Nueva York. Este capítulo reduce nuestra dependencia de LDP, mientras que al igual que antes, la continuidad del servicio sigue siendo de suma importancia.

A medida que se obtiene confianza en la implementación de SR, LDP puede eliminarse por completo. Este capítulo se centra en llegar a una situación en la que LDP ya no anuncia la unidifusión IPv4 o IPv6 FECs.

Interfuncionamientos de SR y LDP

LDP continúa distribuyendo etiquetas para todos los enrutadores, aunque se prefieran los SID del prefijo SR en Nueva York. Conceder a SR una preferencia más alta sólo entra en vigor si se detecta una ruta de la – competencia a través de LDP cuando los enrutadores externos a Nueva York sólo tienen etiquetas anunciadas a través de LDP, el tráfico hacia esos destinos sigue enrutado sin segmentos. Si el plan es desactivar LDP, debe asegurarse de mantener una ruta de acceso contigua con etiqueta, ya que LDP lo hace por ahora (Figure 1). Esto es importante tanto en las direcciones de SR-to-LDP como de LDP-to-SR.

Figure 1: LDP en la periferia (áreas de L1) y en túnel sobre la malla de RSVP-TE en Core (es en el subdominio L2)
LDP en la periferia (áreas de L1) y en túnel sobre la malla de RSVP-TE en Core (es en el subdominio L2)

SR-to-LDP

SR requiere que un SID pueda obtener acceso a todos los enrutadores. La mayor parte de la red carece de esa parte frontal. No hay ningún SID de prefijo para los enrutadores remotos ya que aún no se ejecuta SR. Elimine LDP en Nueva York y no habrá ningún LSP contiguo fuera de la región. Evidentemente, necesita un mecanismo que asocie indirectamente los SID de prefijo con los enrutadores que no admiten SR.

El servidor de asignación de Sr (SRMS) es tan solo una función de plano de control. Anuncia los SID de prefijo en nombre de los sistemas no compatibles con SR. Como cabría esperar ahora, esto es más TLVs que los altavoces SR consumen y que los no de los altavoces lo ignoran. Los enrutadores SR instalarán los SID aprendidos desde los servidores de asignación, igual que instalan los SID de prefijo nativo, en inet. 3.

Al igual que todos los proxies, SRMS debe disponer de una alta disponibilidad y su información difundida debe seguir siendo coherente – , configurando más de un enrutador como SRMS. La coherencia de la asignación es el resultado de la aspiración de las siguientes prácticas operativas recomendadas modernas, incluida la generación de la configuración con plantilla, los repositorios de configuración con control de versiones y la capacidad de deshacer rápidamente los cambios no intencionados.

Note

Existen reglas complejas de desempate si se producen incoherencias en la asignación. Cada asignación SRMS incluye una preferencia. Se seleccionan las asignaciones de SRMS con las preferencias más altas. Si varios SRMS tienen igual preferencia pero anuncian información conflictiva, entrarán en vigor reglas de colisión de etiquetas SR.

SRMS sólo existe para anunciar el prefijo a las asignaciones de SID. Dichos prefijos podrán o no ser accesibles a través de la SRMS; de hecho, es posible que los prefijos sean totalmente inalcanzables. Por supuesto, las asignaciones de SID de publicidad para prefijos ficticios se considerarían una configuración errónea, por lo que los controles estándar del proceso de revisión de cambios’deben estar en vigor para garantizar que las asignaciones incorrectas no entren en vigencia.

El análogo a un servidor es un cliente. Para que un servidor de asignaciones retenga cualquier Sway, debe existir un cliente de asignación (SRMC). A diferencia de la mayoría de los protocolos, SR de’asignación de clientes y servidores no forman una relación de control de un plano entre sí distintos. En su lugar, los clientes simplemente utilizan las asignaciones anunciadas. Un SRMS puede ser simultáneamente un servidor, así como un cliente.

Los enrutadores que Borden ambos dominios son responsables de unir los segmentos enrutados con LDP. El enrutador de borde habla tanto de SR como de LDP; al recibir una asignación, crea una entrada de intercambio de etiqueta para que un SID de nodo entrante se conmute por la entrada aprendida con LDP para el mismo FEC en la tabla MPLS. 0.

En esta red’Book, ambos P1. NYC y P2. NYC actuarán como enrutadores de borde. Si bien es posible que sea más intuitivo configurar primero un SRMS, Esto interrumpiría la conectividad. Dado que los enrutadores de Nueva York prefieren SR sobre LDP, Learning SR mappings for The Washington FECs sustituye de forma inmediata a las etiquetas existentes expedidas por LDP en la tabla PE’inet. 3. Sin habilitar de forma explícita el comportamiento de creación de complementos de LDP, cuando PE1. NYC y PE2. NYC intentan usar SR para tráfico de largo alcance, el tráfico se descarta en P1. NYC y P2. NYC cuya tabla MPLS. 0 carecería de la acción correspondiente de la etiqueta SR entrante.

Enabling SR to LDP Stitching

’Configure tanto P1. NYC como P2. NYC como enrutadores de borde, que actúan como traductores de Sr/LDP:

No debería haber ningún cambio todavía al comportamiento de reenvío.

Connectivity verification: cross-country traffic still uses LDP labels

Aquí, tanto P1. NYC como P2. NYC están esperando en la asignación de entradas de una SRMS. Para empezar, P1. NYC se configurará como nuestro primer SRMS. Anunciará las asignaciones para los PEs en Washington. Recuerde que cualquier enrutador compatible con SR puede actuar como – una SRMS su ubicación topológica es irrelevante. Con BGP reflectores de ruta (en topologías de gran tamaño, es necesario colocar un reflector de ruta razonable o el uso de una reflexión de ruta óptima):

La Directiva se crea en una sección independiente del Protocolo de la configuración. A esa Directiva se hace referencia en la jerarquía específica del protocolo para permitir que P1. NYC actúe como SRMS usar IS-IS.

Note

Recuerde que SR es independiente de la elección de IGPs – que funcionaría igual de bien, si nuestra red se hubiera basado OSPF.

Vamos’a hacer un rompecabezas de esta configuración. El nombre de la Directiva es un asunto local. Dentro de eso, anunciamos una entrada de asignación que abarca una serie de cuatro prefijos IPv4, comenzando con 128.49.106.10 (PE1. IAD’s ID. de enrutador).

Esto se codifica de manera eficaz como un TLV de enlace de etiqueta único en P1.’NYC s es un LSP. En la siguiente verificación, el Range corresponde a la palabra clave size. El prefijo IPv4 es nuestro prefijo de inicio. Lo que configuramos como el start-index se representa como Value.

Control plane: verify p1.nyc is acting as an SRMS

Las entradas resultantes de las tablas inet. 3 de la SRMC deberían Table 1ser las de.

Table 1: Entradas de asignación de SRMS P1. NYC

Anteponga

Etiqueta (SRGB + index)

¿Es accesible?

128.49.106.10

1010 (1000 + 10)

128.49.106.11

1011 (1000 + 11)

128.49.106.12

1012 (1000 + 12)

No

128.49.106.13

1013 (1000 + 13)

128.49.106.10

1010 (1000 + 10)

128.49.106.11

1011 (1000 + 11)

Forwarding plane: verify pe1.nyc prefers SR to LDP

Como puede ver, las rutas LDP se han ignorado en favor de los SID de prefijo SR recién aprendidos de P1. NYC actuando como SRMS. Donde PE2. NYC insertaría anteriormente la etiqueta LDP aprendida de P1. NYC o P2. NYC, ahora utiliza las etiquetas SR conocidas a 1000.

Sin embargo, el crux real es ver qué P1. NYC y P2. NYC pueden hacerlo cuando reciben estas etiquetas de entrada. Dado que son enrutadores de borde, deben intercambiar la etiqueta derivada del servidor de asignación para la etiqueta aprendida por LDP. Más específicamente, los enrutadores de borde deben intercambiar la etiqueta SR entrante de la pila de etiquetas salientes asociada con el mismo FEC. Si no se trata de un paso crucial, tendría rutas de conmutación de etiquetas no contiguas.

’En primer lugar, tome nota de la pila’de etiquetas de NYC s de la salida P1 hacia P1.’IAD y su conocimiento a través de LDP.

Forwarding plane: verify p1.nyc’s outgoing label stack for p1.iad’s FEC

Dado que los LSP de MPLS pueden ser recursivos, esto es claramente un caso de túnel. La etiqueta 17 se aprendirá desde’P1. NYC es LDP Neighbor, que es su próximo salto elegido hacia la FEC. Ese vecino es P1. IAD, alcanzable a través del LSP de RSVP en el que se realiza el túnel de una sesión LDP.

Control plane: verify how p1.nyc created the label stack to reach p1.iads

En función de este resultado, deberíamos esperar P1. NYC para intercambiar la etiqueta entrante 1011 con 17 (SR a LDP), antes de presionar 18 encima (de túnel a través de LSP de RSVP que se exporta como adyacencia de reenvío).

Forwarding plane: confirm p1.nyc swaps the SR label for the LDP/RSVP combination

Voilá! La operación de etiqueta para FEC en inet. 3 y la etiqueta correspondiente en MPLS. 0 son idénticas. When PE1. NYC introduce la etiqueta 1011 sobre el tráfico destinado a PE1. IAD, P1. NYC (y P2. NYC) lo intercambia para la etiqueta LDP (que una etiqueta RSVP se inserta a continuación es incidental).

La clave está en la medida en que SR coexiste con los protocolos de distribución de etiquetas clásicos, tanto en LDP como en namesake, así como en el eficaz RSVP.

Deje’que s ejecute el traceroute de larga distancia. Debe confirmar que PE1. NYC y PE2. NYC utilizan ahora la asignación anunciada de SRMS para PE1. IAD. Por supuesto, PE1. IAD, como con otros enrutadores que no son de Nueva York, sigue siendo SR-oblivious.

Connectivity verification: pe2.nyc now pushes SR label 1011, instead of the earlier LDP-learned label

Sería remiss si’no validamos la falta de los cambios esperados en el tráfico intra-New York.

Connectivity verification: traffic within New York continues to use SR

Ideal. No hay ningún cambio en las anteriores traceroute.

Antes de continuar, permita’que las s se enfrenten a la falta de redundancia de SRMS mediante la configuración de P2. NYC como nuestro segundo servidor de mapping. Puede configurarlo de forma idéntica a P1. NYC:

Control plane: p2.nyc also originates a label-binding SID with the same mapping as p1.nyc

No se produce ningún cambio en el comportamiento de reenvío. Si P1. NYC deja de estar disponible, las asignaciones de P2. NYC continúan apareciendo como SID de nodo suplente.

Para comprender un enfoque distinto de la configuración de entradas SRMS,’Elimine esta configuración de P2. NYC y, en su lugar, agregue entradas de prefijo individuales e investigue cómo se codifican de manera diferente en el LSP is, pero lleve al mismo comportamiento de reenvío:

Hemos creado asignaciones para prefijos individuales, en lugar de un rango. A diferencia del rango que incluía un prefijo’que actualmente no es parte de nuestra red (128.49.106.12), este formulario permite asignaciones no contiguas. Como cabría esperar, requiere TLVs separados en P2. NYC’s es una PDU.

Control plane: p2.nyc now has multiple label binding TLVs

Allí donde antes vimos un solo TLV proporcionan las asignaciones para todos los’enrutadores PE de Washington (así como también una entrada extraña), ahora encontramos tres TLVs, uno para cada PE. Si los prefijos no son contiguos, será necesario este formato. Tenga en cuenta que ambos enfoques tienen sus propias consideraciones:

  • Los intervalos de prefijo son la forma más compacta de distribuir esta información. Su alcance puede ser demasiado amplio, lo que incluye prefijos que deberían o no necesitan SRMS servicios.

  • Varios TLVs de enlace de etiquetas son más precisos pero conducen a la inflación de las PDU IGP, en la que la inundación y la fragmentación pueden hacer que la distribución sea menos eficiente.

Por supuesto, ambos enfoques se pueden usar – simultáneamente en un intervalo cuando los prefijos se abordan adecuadamente, y las entradas se separan cuando resultan poco convenientes.

Conflict Resolution

Analicemos’este enfoque híbrido con una idea – siguiente anuncie las asignaciones para nodos compatibles con Sr, desde P2. nyc. El SRMS P2. NYC seguirá anunciando entradas individuales para enrutadores de Washington y agregará un rango que cubra los enrutadores de Nueva York. El propósito es simplemente comprender si esto causa confusión o daños:

Puede ver los movimientos existentes incrementados por un rango a partir de PE2. NYC’s ID enrutador (128.49.106.0). Dado que PE2. NYC ya está anunciando su índice de nodo, y el índice coincide con lo que el SRMS pretende originar, no se produce ningún cambio en el comportamiento de reenvío.

Control plane: p2.nyc is advertising ranges for both SR-capable and incapable routers

Ejercicio que sirve para instruir que tanto el rango individual como el prefijo se pueden utilizar juntos. Aunque no dañen, esta configuración no representa una práctica recomendada de funcionamiento. La complicación de su intención con anuncios ingratuitos es, en el mejor, confuso y en el peor de los comportamientos de software o cambios en las especificaciones de los estándares posteriores.

Quite el intervalo de segmentos de prefijo innecesarios.

LDP-to-SR

¿Ahora hemos eliminado la necesidad de LDP en todos los enrutadores PE de Nueva York? Tienen una posibilidad de acceso entre sí a través de los SID de nodo SR; Además, han aprendido los SID de nodo sintético para los enrutadores PE de Washington. ¿Sigue siendo necesario LDP? Después de un último paso, lo haremos con el PEs.

Recuerde que los enrutadores de Washington aprenden más acerca de Nueva York FECs a través de LDP. Se encuentra en el túnel sobre los LSP de RSVP que se originan en P1. NYC y P2. NYC, y termina en P1. IAD y P2. IAD. LDP no’puede desactivarse en estos enrutadores sin interrumpir el LSP contiguo.

Podemos desactivar LDP en PE1. NYC y PE2. nyc. Primero’vamos a pensar en cómo podemos seguir anunciando etiquetas para ellos a través de LDP en los enrutadores de Washington. Dado que la sesión LDP entre los enrutadores P y PE se eliminaría, los enrutadores P deben configurarse para que originen una etiqueta LDP en nombre del PEs.

Esta es la misma idea que la SRMS, que se ha girado al revés, a través de la conocida. En vez de prefijos de anuncio de los SID en nombre del no capacitado en la revisión, necesitamos anunciar las asignaciones de FEC del proxy para LDP-averse.

Antes de hacer cambios,’vamos a comprobar las etiquetas LDP que se anuncian para llegar a PE2. NYC por P2. nyc.

Control plane: p2.nyc is advertising label 56 to its LDP neighbors

Forwarding plane: p2.nyc pops label 56 as its performing PHP to pe2.nyc

Connectivity verification: traffic from Washington to pe2.nyc uses label 56

Enabling LDP to SR Stitching

A continuación’, permita que s habilite la funcionalidad de LDP a Sr a P2. NYC y observe el cambio en las etiquetas anunciadas:

Control plane: p2.nyc allocates new LDP label 59, withdrawing label 56

Control plane: LDP-to-SR stitching functionality is enabled

Forwarding plane: label 59 is swapped with 0 as pe2.nyc requests SR UHP treatment

Connectivity verification: label 59 is now in use by p2.nyc’s LDP neighbors to reach pe2.nyc

Puede habilitar al – cliente de asignación de LDP Sr’qué elementos a los que se hace referencia como Complementos de LDP-to-Sr – , así como en P1. NYC, para garantizar que hay varios paths a Nueva York. A continuación, puede desactivar LDP en PE1. NYC y PE2. nyc. Ya no publicarán una etiqueta LDP para sí mismos, pero P1. NYC y P2. NYC seguirán haciendo esto, tal y como Figure 2se muestra en la.

Figure 2: Se eliminó LDP en enrutadores PE de Nueva York
Se eliminó LDP en enrutadores PE de Nueva York

Puede persistir durante el tiempo que sea necesario en este estado. Puede ser un modo de funcionamiento legítimo si los enrutadores externos a Nueva York no van a ser compatibles con SR para el futuro previsible. Las capacidades inadecuadas de hardware o software en una parte de la red no deben impedir la implementación de Sr. Bien planeada y ejecutada aunque sea necesario el cambio, no necesita ser un evento de exclamación de gran tamaño que requiera que todas las plataformas se conviertan simultáneamente en enrutamiento segmentado.

SR y RSVP-TE

Se ha tratado brevemente que existe una malla completa de los LSP de la tunelización de LDP-TE de LPD entre los enrutadores de Nueva York y Washington P. Al final de la sección anterior, LDP se eliminó de PE1. NYC y PE2. nyc. Sin embargo, LDP permaneció en uso en P1. NYC, P2. NYC y sus homólogos de Washington.

Interworking: SR over RSVP-TE

’Revierta sus recambios en un reflejo de los cambios que hemos estuviéramos en Nueva York:

  1. Activar SR en todos los enrutadores de Washington.

  2. Preferir SR para LDP en el PEs de Washington.

Una vez que todos los enrutadores de entrada hayan cambiado a SR, podemos entonces erradicar finalmente LDP. Que incluirán el cliente de asignación de SRMS y LDP SR configurado en P1. NYC y P2. NYC, tal Figure 3y como se muestra en la.

Figure 3: Se eliminó LDP en todos los enrutadores
Se eliminó LDP en todos los enrutadores

La importancia del planeamiento del SID del prefijo no puede ser sobrefijada. Los enrutadores de Nueva York lo aprenden a través del par de SRMS. La configuración del SID del nodo nativo debe conservar valores idénticos. De hecho, el diseño de la dimensión SRGB, el desplazamiento y el SID son fundamentales para el éxito de cualquier implementación de enrutamiento de segmentos. No tenga en cuenta las implementaciones en vivo sin tener un cuidado minucioso en los casos de uso, así como la capacidad de un equipo de uso idéntico para que sea similar, y que tenga un tamaño uniforme, SRGB.

También debe tener cuidado con el orden en el que activa la funcionalidad SR en Washington. Si se habilita por primera vez en los enrutadores P, la conectividad se interrumpirá. Esto se debe a que P1. NYC y P2. NYC determinarán que los vecinos de Washington, de repente, son compatibles con SR. Dejarán de intercambiar la etiqueta SRMS, que anuncian para PE1. NYC y PE2. NYC para insertar, con la etiqueta LDP aprendida a través del LSP de RSVP-TE. La funcionalidad de creación de la actualización de la revisión a LDP se considerará innecesaria.

En su lugar, SR se activa primero en todos los PEs de Washington:

Deje’comprobarlo para asegurarse de que no hay interrupción.

Connectivity verification: traffic forwarding within New York is unchanged

Connectivity verification: traffic forwarding cross-country is unchanged

Ningún cambio es bueno (en este caso). Washington es un área separada de nivel 1 y los enrutadores L1/L2 P aún no están habilitados para SR. La creación de "SR-to-LDP" sigue siendo un proceso no sobrepuesto. La SR de momento está habilitada en P1. IAD y P2. IAD, la necesidad de una Unión se convertirá en Moot.

Esto puede parecer gratuito, pero merece la pena pensar en cómo se determina la necesidad de crear una grapa. Si un vecino no’anuncia la capacidad de Sr, P1. NYC y P2. NYC cambiará Merrily una etiqueta Sr para LDP. En nuestra red, además, insertamos una etiqueta de LSP de RSVP-TE sobre la que encontrarás encima.

Si a continuación se configura P1. IAD (o P2. IAD) con un SID de nodo, tanto P1. NYC como P2. NYC verán que su actualización es un LSP de nivel 2. Correctamente, dejarán de considerarlo para la creación de la revisión a LDP, ya que es evidente que P1. IAD (o P2. IAD) podrá enviar etiquetas de SR-nativo.

Esto es exactamente cómo proceder, con una arruga. ’Recargomos el enrutador de Washington P que no está habilitado primero para Sr. Esto asegurará que todo el tráfico entre regiones será distribuido por segmentos; y no solo eso, será transportado a través de RSVP-TE LSP, mostrando SR over RSVP-TE.

Arbitrariamente, deje’que Active Sr en P2. IAD y Overload P1. IAD:

Esto obliga a todo el tráfico enlazado de Washington hacia P2. IAD.

Connectivity verification: traffic forwarding to Washington is no longer multi-pathed

Connectivity verification: traffic forwarding within New York remains unaffected

Forwarding plane: both New York P routers swap the inbound SR label for LDP-o-RSVP

Esta salida muestra los enrutadores swap 1011 para 22, la etiqueta LDP anunciada por P2. IAD a través de la sesión LDP en túnel a través de RSVP-TE. A continuación, se inserta la etiqueta RSVP-TE LSP. Existen dos rutas de costo sin igual, que son las últimas que representan el bypass de RSVP-TE.

SR is then enabled on p2.iad:

Los enrutadores NY e siguen evitando el P1. IAD. Y en vez de intercambiar 1011 para una etiqueta LDP, simplemente intercambian la siguiente instrucción SR. Esto resulta ser idempotente, una acción continue , lo que da como resultado que el 1011 se intercambie para 1011.

Forwarding plane: both New York P routers now swap the inbound SR label for another SR label

Observe que las etiquetas’RSVP-te LSP insertadas no cambiamos. Se trata de la etiqueta inferior que ya no se une entre SR y LDP. Deje’que el s Compruebe que se mantiene la conectividad y que Sr se transporta ahora correctamente a través del núcleo RSVP-te.

Connectivity verification: no change within New York as expected

Connectivity verification: outside New York, SR labels are carried all the way until pe1.iad, not just the L1/L2

Esto es geográficamente más lejano de lo que hemos conseguido con SR. Hasta ahora, la compleja interpartida de la Unión y el túnel LDP permitía que el tráfico de SR se transportase a través de los LSP de RSVP-TE sin configuración explícita adicional.

Como hemos aprendido, hacer que nuestro propósito es explícito es tanto un objetivo de noble como una práctica operativa recomendada. Los valores predeterminados de plataforma son deficientes, por años. El menos depender de que un operador esté en – un comportamiento Orthodox una vez – deseada, más adelante de la red sea más sólida. Explicating es tanto documentación como un modo de imponer la coherencia entre las distintas plataformas, versiones de software y los responsables de las mismas.

Supongamos que’lo he configurado, configurando Sr para que se transfieran explícitamente sobre RSVP-te LSP. Esto no debería ocasionar ningún cambio inmediato, pero una vez que se elimina LDP, aseguramos que mantenga la conectividad. En ambos enrutadores P en Nueva York y Washington,’permitir que el Sr shortcuts:

Connectivity verification: no change in either traffic flow

Todo lo que queda ahora es quitar LDP (incluidas SRMS y cooperando en ambas direcciones en los enrutadores de Nueva York P, al igual que con el túnel LDP en los LSP de RSVP-TE), habilitar SR en P1. IAD y devolverle al funcionamiento.

Estos pasos se han explicado, se han diseccionado y se han detallado. ’No es necesario que se les haya puesto fin al trabajo. Una vez finalizado, habrá hecho buena en la promesa de haber sustituido a LDP por SR. En todo lo que hemos visto se ajusta a la arquitectura de enrutamiento de segmentos con los protocolos de distribución de etiquetas de MPLS.

Connectivity verification: complete reachability intra- and inter-region using SR

Con el SR.’1 se transportó con éxito a través del núcleo de tráfico diseñado, tome nota del hecho de que, de nuevo, esto podría ser un modo perpetuo de funcionar. La probabilidad de multi-pathing es superior a la región, donde se ha distribuido SR. Donde el multipathing es más – pobre, como en – las regiones, RSVP-te se ejerce. Los dos pueden coexistir a partir de la misma.

Sin embargo, para nuestros fines, nada volvamos a activar SR en todo el subdominio L2. La configuración es similar a los ejemplos anteriores y no es necesario repetirla. Dado que se ha cumplido nuestro objetivo de demostrar la interfuncionación’, supongamos que también descuenta a los LSP de RSVP-te entre P1 y P2 en Nueva York y Washington, de manera que todo el tráfico comprendido entre el y el interior se transporte por completo con Sr.

Coexistence: SR-aware Bandwidth Reservation with RSVP-TE

RSVP-TE tiene un conjunto de características escalonadas, acumuladas a lo largo de más de décadas en experiencia operativa en el mundo real. Una característica especialmente conocida y de uso muy extendido es auto-bandwidth: Cambie el tamaño y enrute LSP para que coincida con la carga de tráfico que se ofrece. El ancho de banda automático puede parecer casi mágico, con no introducir datos manuales, guardar los parámetros de configuración iniciales y una ruta de acceso óptima puede ser cleaved.

En términos brutos, el ancho de banda automático depende de dos valores: el tamaño de reserva del LSP y el ancho de banda disponible en una interfaz dada de la red. El primero lo deriva el enrutador de entrada del LSP mediante la medición periódica del ritmo, suavizada sobre un intervalo. Esto último se difunde en todo el área IGP por parte de todos los enrutadores a medida que el ancho de banda se agota o libera. Los dos forman un bucle de retroalimentación que controla el cálculo de ancho de banda automático distribuido.

En este Affair Clockwork suizo se asume que RSVP-TE se utiliza exclusivamente para el tráfico de transporte. El ancho de banda de interfaz disponible se almacena en la base de datos de ingeniería de tráfico (TED), cuya instantánea de uso solo lo rellena RSVP-TE. Si la interfaz también transporta tráfico que no sea RSVP-TE, una unappetizing de la TI es cerrar el ancho de banda de RSVP-TE, reservable, hasta una fracción de la capacidad de una interfaz’. Esto impedirá que los LSP de RSVP-TE compitan con otros usuarios de ese ancho de banda, como el tráfico no MPLS, a costa de la posible utilización de vínculos inexistentes.

Note

RFC8426 (https://datatracker.ietf.org/doc/rfc8426/) detalla esta declaración de problema de ancho de banda oscuro, así como otros enfoques para abordarla. El ancho de banda de la partición no es la panacea. No hay garantía de que los usuarios no RSVP: TE limitaremos de forma natural a su capacidad prorrateada.

En nuestra red, el tráfico de SR-MPLS sería un consumidor del ancho de banda, junto con RSVP-TE. Para que los dos tengan que coexistir, al menos hasta que se realice una migración completa, la utilización del tráfico de SR’debe reflejarse en el ancho de banda máximo de interfaz recargable de Ted s. Por lo tanto, se hace indirectamente a RSVP-TE LSP de que es posible que no tengan acceso a la capacidad de manera exclusiva, sin necesidad de particionar el ancho de banda de forma estática.

A pesar de que hemos agotado el RSVP-TE LSP hasta ahora, sigue existiendo RSVP-TE LSP que transportan el tráfico entre dispositivos no compatibles con SR fuera de Washington y Nueva York. Por razones’de brevedad, deje’que no se Centre demasiado en estos enrutadores o – LSP de hecho,’aunque no se representen en el diagrama. En su lugar,’voy a asegurar que el teds de todos los enrutadores represente una vista’precisa del ancho de banda de la red disponible.

Aunque no quedan más los LSP de RSVP-TE originados y terminamos entre Nueva York y Washington, otros continúan en persista entre otras regiones. Algunas de las mismas interfaces que utiliza RSVP-TE LSP también conmutarían el tráfico de SR, ahora de forma nativa. ’Por lo tanto, configure P1 y P2 en Nueva York y Washington para medir el tráfico de Sr y deducir del resto del ancho de banda de la interfaz (disponible para RSVP-te):

El servicio collection-interval representa la frecuencia con la que se seleccionan las estadísticas. El servicio adjust intervalo es la duración de la ventana en la que se recopilan muestras del contador. El promedio de esos ejemplos – en nuestro caso, serían tres muestras – que representa la carga de tráfico de Sr actual por vínculo. Si esta carga excede el umbral de ajuste, que es la diferencia entre el promedio actual y anterior calculado, el IGP inunda el máximo ancho de banda Reservable, lo que actualiza TED.

Es posible que el resultado implique que se haya tenido preferencia sobre RSVP-TE LSP, que se haya redireccionado, así como el IGP inundar el máximo ancho de banda reorganizable revisado para el vínculo TE de TE. Sin tráfico de SR en el vuelo,’permita ver qué cantidad de ancho de banda está disponible para la reserva en el vínculo entre P1. NYC y P1. PHL.

Control plane: 3Kbps in use, 97Kbps available to RSVP-TE

Ahora permita’que el tráfico sea un segmento enrutado que se enrute y observe la reducción del ancho de banda disponible en el informe.

Control plane: ~67Kbps used by SR

Control plane: 31Kbps available to RSVP-TE, reduced by ~67Kbps

Control plane: LSDB reflects updated bandwidth

Esta reflexión también funciona en orden inverso. Deje’que s staunch el tráfico de Sr y observe cómo se vuelve a aumentar el ancho de banda disponible una vez más.

Control plane: SR utilization drops to ~40Kbps

Control plane: RSVP-TE now indicates 54Kbps available

Control plane: The LSDB values are flooded to neighbors & match RSVP-TE’s reported values

Esta coexistencia correcta de SR y RSVP-TE anticipa a las necesidades de los operadores. Para quienes tienen implantaciones exigentes, es poco probable que RSVP-TE sea desplazado rápidamente. Garantizar que el ancho de banda disponible refleja más de un consumidor permite reservas precisas.

SR y IPv6

Sea cual fuere su opinión sobre’IPv6, es probable que sea correcto. Si no ve un controlador de alto nivel, es probable que no’exista para el negocio en el que se encuentre; Si se altar de los ojo, no es’menos que un diferenciador imperativo y tecnológico.

Note

Un ojo feliz es un conjunto de algoritmos definidos por IETF. Se propone una experiencia de usuario superior al utilizar hosts de doble pila. Se prefiere IPv6, si está disponible. Consulte https://Tools.ietf.org/html/rfc8305 para obtener más detalles.

La compatibilidad con IPv6 para protocolos de distribución de etiquetas de MPLS existentes varía: LDPv6 extiende el protocolo base; La instalación de RSVP, hasta esta fecha,’no ofrece una implementación general disponible; BGP sigue siendo una familia de direcciones válida, pero por’supuesto que no es un IGP.

La buena noticia es que el enrutamiento del segmento trata la accesibilidad de IPv6 como un ciudadano de primera clase. SR ganó’t convenció que usted implementó IPv6 una vez más, pero luego’ganó que también se convierta en un obstáculo para la entrada. Los SID de nodo, adyacencia y difusión por proximidad’(de los cuales utilizamos los dos primeros, hasta ahora), vienen en dos versiones, IPv4 e IPv6.

Caution

La compatibilidad con enrutamiento de segmentos para IPv6 se suele comprender para asociar SID con prefijos de IPv6. El plano de datos sigue MPLS. Por el contrario, SRv6 es un radical que restan el reenvío IPv6 nativo. No hace uso de MPLS. SRv6 puede ser un tema para un libro independiente.

De todos modos, la configuración es casi idéntica’, de modo que se debe desprofundizar y crear un subyacente encapsulado por IPv6 MPLS. Se muestra la sintaxis para PE1. nyc. La asignación de SID se detalla Table 2 a fin de evitar repetir la configuración casi idéntica, Figure 4 e ilustra la configuración.

Table 2: Asignación de SID de nodo IPv6

E-mail

Dirección lo0 IPv6

SID del nodo IPv6 (índice + SRGB)

pe1.nyc

2001:db8::128:49:106:1

1061 (61 + 1000)

pe2.nyc

2001:db8::128:49:106:0

1060 (60 + 1000)

p1.nyc

2001:db8::128:49:106:3

1063 (63 + 1000)

p2.nyc

2001:db8::128:49:106:2

1062 (62 + 1000)

pe1.iad

2001:db8::128:49:106:11

1071 (71 + 1000)

pe2.iad

2001:db8::128:49:106:10

1070 (70 + 1000)

pe3.iad

2001:db8::128:49:106:13

1073 (73 + 1000)

p1.iad

2001:db8::128:49:106:9

1069 (69 + 1000)

p2.iad

2001:db8::128:49:106:8

1068 (68 + 1000)

Figure 4: IPv6, direccionamiento ISO y numeración adicional de los SID de nodo
IPv6, direccionamiento ISO y numeración adicional de los SID de nodo

En cuanto esta configuración entra en vigor, cada enrutador comienza además a anunciar un índice de nodo IPv6 (junto con el índice de nodo IPv4), así como los SID de adyacencia IPv6.

Control plane: Additional IPv6 node index and adjacency SIDs

El ‘indicador’ F del SID de adyacencia indica una adyacencia compatible con IPv6. Sorprendentemente,’verá nuevas entradas en la tabla de enrutamiento recién llenada de inet 6.3.

Control plane: FECs in inet6.3 use native addresses, not mapped IPv4 addresses

Y permita’que s Verifique la conectividad con estas nuevas rutas de servicio, tanto intraregión como entre regiones. A continuación, puede ver que el transporte IPv6 está llevando a cabo los prefijos de servicio IPv6. 6PE’s las direcciones IPv4 asignadas y el uso de IPv6 Explicit null pueden estar dispuestos a REST.

Connectivity verification: Intra-region using the new IPv6 node SIDs

Connectivity verification: inter-region using the new IPv6 node SIDs

SR y multidifusión

Un mito común es que la multidifusión necesita un tratamiento especial en una red enrutada de segmentos. Como la mayoría de los mitos, esto se deriva de una falta de entendimiento.

El reenvío de multidifusión es ortogonal a unidifusión. Enfoques – existentes la multidifusión de IPv4, la multidifusión IPv6, MPLS la multidifusión – siguen siendo utilizables incluso cuando Sr está habilitada. Cuando se trata de MPLS la multidifusión, puede que en realidad signifique que LDP y – RSVP-te dos protocolos que – preceden a Sr se quedan intactos para el reenvío de multidifusión.

Mientras mLDP ofrece árboles de replicación tanto de punto a multipunto (P2MP) como de multipunto a multipunto (MP2MP); RSVP-TE ofrece replicación de entrada de punto a punto (P2P), así como P2MP de la replicación de red. Admiten el suministro de tráfico VPN de multidifusión y no VPN.

Enfoques nativos de SR, como pulverizador y SID de árbol, para ofrecer la replicación de entrada y de red, respectivamente. Técnicamente, la BIER no encaminará al enrutamiento de segmentos, sino que sigue una solución similar a la de los nodos de tránsito. Hasta que estas tecnologías se maduren, los operadores pueden confiar en los mecanismos de multidifusión existentes.