Optimización
Los capítulos anteriores han examinado varios casos de uso para introducir el enrutamiento del segmento. Este capítulo se centra específicamente en los aspectos de la ingeniería de tráfico (TE) de SR. En particular, describe lo siguiente:
Modelo del proceso de TE
La función de la definición de ruta explícita
Restricciones de enrutamiento y varias propiedades destacables de los tipos de SID de SR
Computación de paths centralizada y distribuida
Y, por último, una solución SR-TE de extremo a extremo para la red de muestra, que utiliza una controladora centralizada.
Modelo del proceso de TE
En el modelo del proceso de TE Figure 1incluido en el operador, o en un autómata adecuado, actúa “como” controlador en un sistema de control de retroalimentación adaptable. Este sistema incluye:
Un conjunto de elementos de red interconectados (red IP/MPLS)
Un elemento de supervisión de estado o topología de red
Un elemento de supervisión de rendimiento de red
Un elemento de administración de configuración de red
El operador/autómata formula una política de control, observa el estado de la red a través del sistema de supervisión, caracteriza el tráfico y aplica acciones de control para dirigir la red a un estado óptimo. Esto se puede llevar a cabo de forma reactiva, basándose en el estado actual de la red, o de forma proactiva, basándose en un estado futuro pronosticado.
El bucle de adaptación de comentarios puede implementarse en cada nodo de la red, es decir, como si se distribuyea, o de manera centralizada, es decir, mediante un elemento de cálculo de ruta (PCE). Además, es posible disponer de varios modelos híbridos.
Enrutamiento explícito: Una herramienta para TE
Es posible que se desee un enrutamiento explícito para optimizar los recursos de red o proporcionar garantías de servicio muy estrictas, pero no es por sí misma una solución TE. El resultado del modelo del proceso de TE, la parte importante de una solución de ingeniería de tráfico, probablemente requiere la programación de una ruta explícita para programar el cálculo resultante. Por lo tanto, se desea que sea capaz de definir una ruta de acceso estricta en toda la red para uno o más proveedores de idiomas. Tanto RSVP-TE como SR proporcionan un medio para definir explícitamente rutas estrictas (saltos estrictos, saltos sueltos y/o saltos abstractos/multidifusión) a través de una red.
Explicit Routing with RSVP
Los operadores de red solicitan, normalmente a través de la configuración, LSP que cumplan determinadas limitaciones. Por ejemplo, un operador de red podría solicitar a un LSP que se originó en el nodo R1, termina en el nodo R6, reserva 100 megabits por segundo y atraviesa sólo interfaces azules. Un módulo de computación de rutas de acceso, – ubicado en un controlador – central, como el PCE o en el enrutador de entrada, calcula una ruta que satisface todas las restricciones. Figure 3 ilustra el programa de instalación resultante de la ruta RSVP y la mensajería de reserva para configurar el LSP y las operaciones de etiqueta de tabla de reenvío de MPLS resultante.
En el siguiente ejemplo de configuración se muestra la configuración requerida. ’Merece la pena señalar que no hay restricciones de enrutamiento definidas para el LSP. En otras palabras, la única configuración mostrada es la definición de la ruta de acceso explícita. En muchas (o más) implementaciones de RSVP-TE las rutas no se definen de forma explícita, sino que se define una restricción de enrutamiento, como el ancho de banda o la afinidad del vínculo, de tal forma que el nodo de entrada o el CSPF externo calcule dinámicamente la ruta de acceso explícita para que cumpla con el enrutamiento Check.
R1 configuration
Explicit Path Definition with SR
De forma muy similar a RSVP-TE LSP, un operador de red solicitará, normalmente mediante configuración, LSP que cumplan determinadas limitaciones. La diferencia principal no es solo la sintaxis de configuración específica, aunque son bastante similares, sino el concepto de describir la ‘restricción’ de enrutamiento con las mismas construcciones de la CLI. Para proporcionar delimitaciones de TE de TE complejas, es posible que un nodo de la revisión de entrada necesite confiar en un controlador externo o PCE.
Utilizando el mismo ejemplo que en el ejemplo de RSVP-TE, un operador de red podía solicitar un LSP que se origina en el nodo R1, termina en el nodo R6, reserva 100 megabits por segundo y atraviesa interfaces azules únicamente, pero requiere un controlador externo/PCE para calcular la ruta de acceso. Solo se requiere un PCE externo debido a la restricción de ancho de banda especificada,’ya que Sr no realiza una señal de sus reservas. Si no se requiere ancho de banda, un cálculo de paths distribuido completado por R1 bastaría para calcular la ruta de SR. Figure 4 ilustra la ruta de acceso de Sr resultante y las operaciones de etiquetas de tabla de reenvío de MPLS. Tenga en cuenta que existe una diferencia bastante importante en las operaciones de reenvío de etiquetas de un LSP de la actualización de SR-TE en comparación con el LSP de la SR de SPF y el LSP anterior de RSVP-TE.
Los SID de adyacencia de SR se asignan dinámicamente de forma predeterminada. Dado que en el siguiente ejemplo de configuración se muestra el uso de técnicas de la CLI tradicional para describir la ruta de acceso explícita, en la que cada salto de la ruta se especifica mediante su etiqueta/SID, se recomienda que las etiquetas se preplanifiquen y se asignen estáticamente para que cada vínculo tenga una etiqueta/SID único, de manera similar a cómo se controla el direccionamiento IP. ’Merece la pena advertir que una ruta de Sr-te también se puede describir, mediante la CLI, utilizando direcciones IP tradicionales como los saltos especificados en la ruta de acceso y permitiendo que el enrutador de entrada resuelva el SID y la pila de etiquetas.
R1: defining static adjacency SIDs
R1: defining explicit SR tunnels
Como se mencionó anteriormente, puede usar la opción de traducción automática y describir la ruta de acceso como una serie de saltos de IP, como una ruta RSVP-TE, y Junos traducirá los SID. Esto tiene una ventaja de quitar la necesidad de configurar estáticamente los SID de adyacencia, lo que asegura que un controlador, que puede haber calculado la ruta de acceso, no es necesario para cambiar la ruta de acceso en el caso de que se produce un vínculo en transición.
Saltos sueltos, prefijos-SID y difusión por proximidad-SID
Segment Routing SIDs
Un identificador de segmento (SID) identifica cada segmento. Los operadores de red asignan SID mediante procedimientos similares a los que se utilizan para asignar direcciones IP privadas (es decir, RFC 1918). Todos los SID se asignan a una etiqueta MPLS con SR-MPLS. Los enrutadores compatibles con SR anuncian los SID a través de la IGP. El IGP inunda estos datos, además de los atributos del vínculo de TE antes mencionados, en todo el dominio de IGP. Por lo tanto, cada nodo del dominio IGP mantiene una copia idéntica de una base de datos de estado de vínculos (LSDB) y una base de datos de ingeniería de tráfico (TED). Los siguientes tipos de segmentos son los más comunes y se utilizarán en este capítulo para describir varios de los casos de uso relevantes.
Adyacencia: Los segmentos de adyacencia representan una IGP Adyacencia entre dos enrutadores. Junos asigna los SID de adyacencia de forma dinámica, pero también se pueden configurar estáticamente. Tal y como se mencionó anteriormente, esto puede ser útil en algunos casos:
Prefix: Los segmentos de prefijo representan el IGP ruta de menor costo entre cualquier enrutador y un prefijo especificado. Los segmentos de prefijos contienen uno o más saltos de enrutador. Un SID de nodo también es un tipo de prefijo de SID:
Anycast: Los segmentos de difusión por proximidad son como los segmentos de prefijo en el que representan la IGP ruta de menor costo entre cualquier enrutador y un prefijo especificado. Sin embargo, el prefijo especificado puede anunciarse desde varios puntos de la red. Tenga en cuenta que, en el ejemplo, la CLI muestra un único nodo que anuncia el SID de difusión por proximidad. En una implementación real, todos los nodos que forman parte del grupo Anycast verían el mismo "Anycast".
Binding: Los prefijos de enlace representan túneles del dominio SR. El túnel puede ser otra ruta SR, un LSP señalado por LDP, un LSP señalado por RSVP-TE o cualquier otra encapsulación:
The Critical Role of Maximum SID Depth
La profundidad máxima de SID (MSD) es un concepto genérico que define el’número de SID s LSR hardware y software capaz de imponer en un nodo dado. Se define en varios borradores IETF OSPF/ISIS/BGP-LS/PCEP. Cuando se computan los paths de SR, es fundamental que la entidad informática conozca el MSD que puede imponerse en cada nodo o enlace para una ruta de acceso de SR determinada. Esto garantiza que la profundidad de pila del SID de una ruta de acceso calculada no supere el número de SID que el nodo es capaz de imponer.
Setting, Reporting, and Advertising MSD
Al usar PCEP para comunicarse con el PCE para la creación de informes, controles y aprovisionamientos de estado de LSP, se informa del MSD. La siguiente CLI se puede usar para aumentar el valor de MSD notificado de 5:
Aunque este informe informa de MSD a un controlador a través de un protocolo de plano de control, Junos también requiere que las interfaces de entrada que impongan etiquetas también tengan su imposición de etiquetas incrementada a partir del valor predeterminado 3:
SID Depth Reduction
Dado que MSD supone una preocupación tan importante en muchos escenarios de SR, la idea de que no es necesario especificar completamente el path de extremo a extremo es una idea muy popular. En los ejemplos anteriores, la CLI de ejemplo especificó los saltos individuales del LSP de la revisión de la SR-to (y del LSP de RSVP-TE), a los que se puede hacer referencia como estrictos. Un salto estricto significa que el LSR especificado debe estar conectado directamente con el salto anterior. Por otro lado, un salto suelto significa que la ruta de acceso debe pasar a través del LSR especificado, pero no es necesario que el LSR se conecte directamente con el último salto; se puede utilizar cualquier ruta válida entre ambas. Echemos’un vistazo a un ejemplo de uso de la topología Figure 5que se muestra en la.
’Supongamos que desea que un LSP pase de R1 a R6 a través de la ruta más baja de R3, R4 y R5. Para lograr este objetivo basta con especificar R3 como primer salto en la ruta y dejar que el enrutamiento normal se haga cargo de él ya que el trazado de R3 a R6 mediante R5 tiene una métrica de IGP de 30, mientras que el path a través de R1 tiene una métrica IGP de 40. La pila de etiquetas resultante para el LSP de la SR-TE está basada en dos rótulos (el SID de nodo para R3 y el SID de nodo para R6) en lugar de cuatro como vistos anteriormente:
Puede igualar esto, y los ejemplos anteriores, a la versión MPLS de una ruta estática. Al igual que las rutas estáticas, las rutas configuradas manualmente son útiles cuando se desea un control explícito, pero también como rutas estáticas, plantean un problema administrativo cuando es necesario establecer muchas rutas y/o desear que la red reaccione dinámicamente ante eventos nuevos, como un vínculo que entra o sale.
Debe tener especial cuidado cuando configure explícitamente saltos sueltos para una ruta de acceso, RSVP o SR. Los errores de vínculo pueden dar como resultado un comportamiento de reenvío inesperado. Por ejemplo,’Supongamos que se produce un error en el enlace entre R1 y R3 Figure 6, tal y como se muestra en la. Dado que SR-TE LSP es un conjunto de instrucciones estáticas y que el SID del nodo especificado en la ruta sigue siendo accesible en la red,’la ruta del LSP resultante será más óptima, aunque es válida.
Los SID de enlace representan otra opción para reducir la profundidad de la pila de etiqueta al configurar rutas Figure 7explícitas, como se muestra en la. Utilizando la misma topología de ejemplo sencilla, un LSP de la actualización SR-TE podría crearse de R3 a R5 y anunciarse con un SID de enlace tal que el LSP de entrada de R1 a R6 hacía referencia al SID de enlace de su ruta y a la pila de etiqueta resultante es tan solo dos.
R3 to R5 SR-TE LSP with binding-SID = 2000
And then the SR-TE LSP from R1 to R6 would look like:
Los SID de difusión por proximidad representan otro tipo de SID usado para crear algunos comportamientos de reenvío interesantes en las redes de SR. Dado que varios nodos, que forman el grupo Anycast, anuncian el mismo prefijo SID, un nodo de entrada o de tránsito avanza hacia el nodo más cercano, desde una perspectiva de IGP métrica, anunciando el prefijo SID. Esto permite a un operador introducir escenarios de alta disponibilidad y equilibrio de carga que son en cierto modo exclusivos de las redes SR. De nuevo, utilizando nuestra topología de red sencilla que Figure 8se muestra’en la, supongamos que R4 y R5 ANUNCIAn el mismo SID de difusión por proximidad, 405. Ahora puede crear un LSP de entrada desde R1 a R6 que tiene como resultado un balanceo de carga de igual costo entre las rutas R1, R2, R5, R6 y R1, R3, R4, R5 y R6, tal y como se muestra.
De nuevo, aunque no es el principal objetivo de usar SID de difusión por proximidad, la pila de etiquetas se ha reducido especificando el SID de difusión por proximidad como un salto en nuestra ruta de acceso de LSP de SR-TE:
Otra forma de que la LSR de entrada determine que la ruta de acceso es calcularla de forma dinámica. Al igual que OSPF y IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS Constrained Shortest Path First -IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS-IS Analicemos’el cálculo de la ruta dinámica a continuación.
El cálculo de paths dinámicos y las restricciones de enrutamiento
Hasta ahora hemos echado un vistazo a varias maneras de definir una ruta de acceso no más corta o explícita con los distintos tipos de SID que ofrece SR, junto con algunas consideraciones especiales. Pero definir y administrar decenas, cientos, miles o decenas de miles de rutas de SR estáticas no es escalable. Por lo tanto, debemos volver al modelo del proceso de TE y explorar cómo ‘definir’ restricciones sencillas de enrutamiento que describan cómo deben computarse las rutas del LSP de Sr-te. En otras palabras, las rutas de la referencia explícitas no son TE, sino un medio de habilitar TE. Primero, deje’a la vista la distribución de la información o el monitoreo del estado o la topología.
Link and Node Attributes and Routing Constraints
El requisito más importante para TE es la diseminación de las características de vínculos y nodos. Al igual que los SID se inundan de manera fiable a través de un dominio de enrutamiento, las características de vínculo y nodo, junto con la disponibilidad de recursos orientada a la TE, también se inundan a través de un dominio TE, que utiliza extensiones para el IGPs. La incorporación de extensiones al Protocolo de enrutamiento de estado de vínculo permite el uso de protocolos de enrutamiento de estado de vínculos para propagar eficazmente la información relacionada con la disponibilidad de recursos en sus actualizaciones de enrutamiento. Los protocolos de enrutamiento de estado de vínculos administran no solo la inundación de actualizaciones en la red en el estado de vínculo o cambio de métrica, sino también disponibilidad de ancho de banda desde la perspectiva de TE. El conjunto de enrutadores de la red inunda estos atributos de recursos para ponerlos a disposición de los enrutadores de Heading para utilizarlos computación de rutas de acceso de proveedores de servicios de fondo (túneles dinámicos).
Los anuncios de estado de vínculo contienen listas de información que describen las’redes conectadas s de enrutador, información de recursos de red y otros datos relevantes que pertenecen a la disponibilidad de recursos real que puede ser necesaria posteriormente para realizar un cálculo SPF basado en restricciones. OSPF y IS-IS se ha suministrado con Extensions para permitir que su uso en un entorno MPLS TE propague la información relacionada con la disponibilidad de recursos y la selección de rutas de LSP dinámicas. Estos atributos de vínculo y nodo adoptan la forma de colores de vínculo, asociaciones de grupos de vínculos de riesgo compartido, ancho de banda disponible y tipos de métricas (TE o IGP), por nombrar algunos. Estos atributos están disponibles en TED, que será utilizado por la entidad computación. De nuevo, utilizando nuestra topología de ejemplo sencilla que Figure 9se muestra en, se ha agregado a R5 lo siguiente:
Esto da como resultado una topología de TE similar a Figure 9 la que se ha coloreado el vínculo R5 a R2 blue y se agrega a la SRLG denominada common-254 y se ha coloreado el vínculo de R5 a R4 red, dado un te-metric de 100 y también se agrega al mismo SRLG.
’Observemos el contenido del bloque Ted para R5’s Link para R4 y veamos cómo la información de vínculo te ha sido inundada en R1, usando extensiones de Isis te, para que se pueda utilizar para computación de paths y, específicamente, para, inclusión o exclusión de restricciones:
user@R1> show ted database R5.00 extensive To: R4.00(1.1.1.4), Local: 10.1.45.2, Remote: 10.1.45.1 Local interface index: 335, Remoteinterface index: 334 Color: 0x800000 red Metric: 100 IGP metric: 10 Static BW: 1000Mbps Reservable BW: 1000Mbps Available BW [priority] bps: [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps SRLGs: common-254 P2P Adjacency-SID: IPV4, SID: 299840, Flags: 0x30, Weight: 0 <output truncated>
Distributed SR Constraint-based SPF
En el proceso normal de cálculo de SPF, un enrutador se coloca en el encabezado del árbol con las rutas más cortas calculadas para cada uno de los destinos, teniendo en cuenta solo la mínima métrica, o la ruta de costo, en el destino. En este cálculo, un concepto clave a tener en cuenta es que no se considera que el ancho de banda del cálculo de ruta dinámica y el enrutamiento restringen los vínculos de otras rutas. Si los atributos necesarios para un path dado incluyen parámetros que van más allá del IGP costo o la métrica, como el color del vínculo, la topología se puede restringir para eliminar los vínculos que no permiten los requisitos mencionados, como el algoritmo SPF, devuelve una ruta de acceso con los requisitos de costo de vínculo y de inclusión/exclusión de vínculos.
Con CSPF, puede usar más que el costo de vínculo para identificar las rutas probables que se pueden usar en las rutas de LSP de TE. La decisión de qué ruta se elige para configurar una ruta de LSP de TE se realiza en la entidad informática, después de resolver todos los vínculos que no cumplen determinados criterios, como los colores de los vínculos, además de los te-cost del vínculo. El resultado del cálculo de CSPF es un conjunto ordenado de SID que se asignan a las direcciones de próximo salto de los enrutadores que conforman el LSP. Por lo tanto, se podrían crear instancias de varios LSP de TE mediante CSPF para identificar los vínculos probables de la red que cumplan los criterios.
El SPF basado en restricciones puede utilizar ponderaciones administrativas o marcas de TE durante el cálculo basado en restricciones. En caso de empate, el trazado con el ancho de banda mínimo más alto tiene prioridad, seguido del menor número de saltos a lo largo de la ruta de acceso. Si todo lo demás es igual, CSPF selecciona una ruta de forma aleatoria y elige lo mismo que la ruta de acceso del LSP de TE de preferencia.
Como se mencionó anteriormente, las rutas de SR contienen algunos atributos destacados, principalmente los atributos de MSD y ECMP, lo que provoca la necesidad de resultados CSPF ligeramente distintos a los de las rutas RSVP-TE tradicionales. Como resultado, Junos como una CSPF distribuida (nosotros’hablamos sobre external, centralizado, CSPFs en un momento) se ha mejorado para no proporcionar sólo un conjunto ordenado de SID de adyacencia para una ruta de acceso, sino también para minimizar o hacer frente al MSD en un enrutador’de entrada s dado, así como aprovechar cualquier ECMPs disponible a lo largo del conjunto resultante de rutas de acceso candidatas ofreciendo los SID de nodo dentro de la lista de segmentos.
Se calcularán localmente las rutas candidatas a SR-TE para que cumplan con las restricciones de enrutamiento configuradas. Los resultados de la computación de CSPF de ruta múltiple serán un conjunto ordenado de SID de adyacencia cuando la compresión de pila de etiquetas esté deshabilitada. Cuando la compresión de pilas de etiquetas está habilitada, el resultado sería un conjunto de pilas de etiquetas comprimidas (compuestas por identificadores de valor de ajuste y SID de nodo) que proporcionan el comportamiento de reenvío ECMP detipo IP siempre que sea posible.
Para todos los resultados de computación, usamos un enfoque orientado a eventos para proporcionar resultados actualizados coherentes con el estado actual de la red en forma oportuna. Sin embargo, debemos asegurarnos de que nuestros cálculos no se saturan durante esos períodos con grandes cantidades de eventos de red. Por lo tanto, el algoritmo tiene las siguientes propiedades:
Reacción muy rápida para un solo evento (p. ej., fallo de enlace)
Reacción rápida de varios IGP eventos que se cierran temporalmente, mientras que el cálculo y la capacidad de consumir resultados se consideran aceptables.
La reacción retrasada cuando el cálculo y la capacidad de consumir resultados son problemáticos
Además, la reacción ante determinados eventos de red varía dependiendo de si la compresión de la pila de etiquetas está habilitada o no. Para los siguientes sucesos, no hay que volver a calcular inmediatamente las listas de SID de las rutas candidatas cuando la compresión está desactivada:
Cambio en la métrica de TE de vínculos
Vincular sucesos en los que el vínculo no es recorrido por un candidato
Evento de vinculación
Cuando la compresión de la pila de etiquetas está activada, se actúa sobre los eventos anteriores para ver si los resultados del cálculo se han visto afectados.
R1: CSPF
Esta configuración hace que se creen los LSP de la revisión del SR- Figure 11te como se muestra en la.
Verifying the SR-TE LSPs computed by the Distributed SR CSPF
user@R1# run show spring-traffic-engineering lsp detail Name: sr-te-lsp-to-r6 Tunnel-source: Static configuration To: 1.1.1.6 State: Up Path: 1st-seg-to-r6 Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Enabled , Compute Result:success , Compute-Profile Name:red-lsp Total number of computed paths: 1 Computed-path-index: 1 BFD status: N/A BFD name: N/A computed segments count: 2 computed segment : 1 (computed-node-segment): node segment label: 104 router-id: 1.1.1.4 computed segment : 2 (computed-node-segment): node segment label: 100 router-id: 1.1.1.6 Path: 2nd-seg-to-r6 Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Enabled , Compute Result:success , Compute-Profile Name:blue-lsp Total number of computed paths: 1 Computed-path-index: 1 BFD status: N/A BFD name: N/A computed segments count: 1 computed segment : 1 (computed-node-segment): node segment label: 100 router-id: 1.1.1.6
Como puede ver en el resultado, Junos calcula un trazado que consta solo del SID del nodo para R4 para cumplir con las restricciones de la ruta de acceso de color rojo y también determina que la ruta de acceso azul es simplemente la ruta de acceso más corta y, por lo tanto, solo utiliza el SID del nodo para R6, en lugar de computar una ruta de acceso completa de los SID Por el contrario, si agrega el no-label-stack-compression palabra clave puede ver cómo se calcula una lista de SID completamente calificada, compuesta de SID de adyacencia.
Configuration example for R1
Verifying the SR-TE LSPs computed by the Distributed SR CSPF
user@R1# run show spring-traffic-engineering lsp detail Name: sr-te-lsp-to-r6 Tunnel-source: Static configuration To: 1.1.1.6 State: Up Path: 1st-seg-to-r6 Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Enabled , Compute Result:success , Compute-Profile Name:red-lsp Total number of computed paths: 1 Computed-path-index: 1 BFD status: N/A BFD name: N/A computed segments count: 4 computed segment : 1 (computed-adjacency-segment): label: 16 source router-id: 1.1.1.1, destination router-id: 1.1.1.3 source interface-address: 10.1.13.1, destination interface-address: 10.1.13.2 computed segment : 2 (computed-adjacency-segment): label: 18 source router-id: 1.1.1.3, destination router-id: 1.1.1.4 source interface-address: 10.1.34.1, destination interface-address: 10.1.34.2 computed segment : 3 (computed-adjacency-segment): label: 20 source router-id: 1.1.1.4, destination router-id: 1.1.1.5 source interface-address: 10.1.45.1, destination interface-address: 10.1.45.2 computed segment : 4 (computed-adjacency-segment): label: 24 source router-id: 1.1.1.5, destination router-id: 1.1.1.6 source interface-address: 10.1.56.1, destination interface-address: 10.1.56.2 Path: 2nd-seg-to-r6 Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Enabled , Compute Result:success , Compute-Profile Name:blue-lsp Total number of computed paths: 1 Computed-path-index: 1 BFD status: N/A BFD name: N/A computed segments count: 3 computed segment : 1 (computed-adjacency-segment): label: 19 source router-id: 1.1.1.1, destination router-id: 1.1.1.2 source interface-address: 10.1.12.1, destination interface-address: 10.1.12.2 computed segment : 2 (computed-adjacency-segment): label: 21 source router-id: 1.1.1.2, destination router-id: 1.1.1.5 source interface-address: 10.1.25.1, destination interface-address: 10.1.25.2 computed segment : 3 (computed-adjacency-segment): label: 24 source router-id: 1.1.1.5, destination router-id: 1.1.1.6 source interface-address: 10.1.56.1, destination interface-address: 10.1.56.2
Por último, como se explicó anteriormente, la profundidad máxima de SID sigue desempeñando una función importante durante la CSPF dinámica. Al igual que en el ejemplo anterior de PCEP, se puede establecer una profundidad de SID máxima para cada perfil de proceso específico mediante el maximum-segment-list-depth<value> Palabras clave.
Configuration example for R1
Un controlador centralizado o PCE para el CSPF externo
Cuando se habla de SR hay a menudo una suposición de la presencia de un controlador o un PCE’centralizado, así que Analicemos brevemente cómo puede aprovecharse el controlador Northstar te como una ruta externa que procesa el origen de las rutas Sr.
BGP Link-state for Topology Discovery
Para que el controlador (PCE) realice cualquier tipo de cálculo de la ruta de acceso, debe estar sincronizado con la topología “de red.”Una topología de red puede adoptar la forma de una base de datos de ingeniería de tráfico (TED), muy similar a la que utiliza RSVP-TE para el cálculo de rutas de acceso, a una base de datos de estado de vínculos (LSDB) o, incluso, más formas físicas. En el ejemplo siguiente se muestra cómo el uso de BGP-LS transmitirá’un TED a Juniper s controlador Northstar.
Para obtener un ejemplo de configuración BGP-LS, consulte la sección visualización en el capítulo sobre la Observability .
PCEP for SR-TE LSP Creation and Control
La siguiente información relevante que requiere un controlador es ser capaz de aprender o crear un estado LSP de la revisión de la SR-TE. En el siguiente ejemplo de configuración se muestra una sesión de protocolo de elemento de computación (PCEP) de ruta entre un cliente de computación de ruta de acceso (PCC) o el enrutador de entrada, y el controlador. Figure 13 muestra los parámetros de sesión PCEP.
Ahora,’vamos a revisar algunos de los tipos de SID específicos de Sr y veremos ‘cómo’ parecen en el controlador y cómo anunciarlos.
Los SID de difusión por proximidad son anunciados por las extensiones IGP SR durante la LSDB, mediante inundación, creando una segunda serie de direcciones 0,0 y anunciando un prefijo-SID para ellos. El siguiente ejemplo anuncia el SID de difusión por proximidad 123 de los nodos P1. NYC y P2. nyc.
Announcing anycast SIDs from p1.nyc and p2.nyc
Verifying on pe1.nyc
user@pe1.nyc> show isis database p2.nyc.00-00 extensive | match “1.1.2.3|123” IP prefix: 1.1.2.3/32 Metric: 0 Internal Up IP prefix: 1.1.2.3/32, Internal, Metric: default 0, Up IP extended prefix: 1.1.2.3/32 metric 0 up Prefix SID, Flags: 0x00(R:0,N:0,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 123 IP address: 1.1.2.3 user@pe1.nyc> show isis database p1.nyc.00-00 extensive | match “1.1.2.3|123” IP prefix: 1.1.2.3/32 Metric: 0 Internal Up IP prefix: 1.1.2.3/32, Internal, Metric: default 0, Up IP extended prefix: 1.1.2.3/32 metric 0 up Prefix SID, Flags: 0x00(R:0,N:0,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 123 IP address: 1.1.2.3
El SID de difusión por proximidad puede verse como una propiedad de nodo en la interfaz gráfica de’usuario de Northstar y posteriormente se elige como un salto estricto o suelto (más probablemente un salto suelto) al crear el LSP de Sr-te. Los SID de enlace se agregan a un LSP de SR-TE Figure 14, como se muestra en y, a continuación, se anuncian a Northstar a través del protocolo PCE.
Creating a Core SR-TE LSP with a binding SID
Verifying the core LSP on P1.NYC
user@p1.nyc# run show spring-traffic-engineering lsp detail Name: P1NYC-2-P1IAD Tunnel-source: Static configuration To: 128.49.106.9 State: Up Telemetry statistics: Sensor-name: ingress-P1NYC-2-P1IAD, Id: 3758096386 Sensor-name: transit-P1NYC-2-P1IAD, Id: 3758096387 Path: P1NYC-2-P1IAD Outgoing interface: ge-0/0/4.0 Auto-translate status: Enabled Auto-translate result: Success BFD status: N/A BFD name: N/A SR-ERO hop count: 2 Hop 1 (Strict): NAI: IPv4 Adjacency ID, 0.0.0.0 -> 192.0.2.15 SID type: 20-bit label, Value: 94 Hop 2 (Strict): NAI: IPv4 Adjacency ID, 0.0.0.0 -> 192.0.2.26 SID type: 20-bit label, Value: 51 Total displayed LSPs: 1 (Up: 1, Down: 0)
Verifying the routing table on p1.nyc
user@p1.nyc# run show route protocol spring-te inet.0: 49 destinations, 60 routes (46 active, 0 holddown, 3 hidden) inet.3: 11 destinations, 15 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 128.49.106.9/32 *[SPRING-TE/8] 00:02:45, metric 1, metric2 20 > to 192.0.2.21 via ge-0/0/5.0, Push 1009 to 192.0.2.13 via ge-0/0/1.0, Push 1009, Push 1008(top) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 62 destinations, 62 routes (62 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1000001 *[SPRING-TE/8] 00:02:45, metric 1, metric2 20 > to 192.0.2.21 via ge-0/0/5.0, Swap 1009 to 192.0.2.13 via ge-0/0/1.0, Swap 1009, Push 1008(top)
Verifying binding SIDs on the Northstar TE Controller
Los SID de enlace se pueden comprobar mediante propiedades de LSP o agregando una columna de SID de enlace a la ficha túneles.
Ahora que ha explorado varios aspectos de TE, varios de los tipos de SID específicos de SR y cómo se sincroniza la información básica con una controladora, deje’que revisemos la red de ejemplo de los capítulos anteriores y incorporemos una solución completa.
Solución de TE de extremo a extremo
Uno de los objetivos principales de la transición de la red de ejemplo al enrutamiento de segmentos será replicar una “forma de” optimización de banda ancha (te) al dominio principal, de nivel 2, donde actualmente los LSP de banda ancha automático de RSVP-te proporcionan una optimización de banda ancha por ruta de acceso relativamente granular. Dado que SR no mantiene el estado por LSP y, por lo tanto, las estadísticas de LSP, una solución de optimización de banda ancha para una red SR requiere que un controlador adquiera datos de otro origen, como fuentes de telemetría de streaming como se describe en el capítulo de Observability , para terminar en una solución de otra forma que RSVP-te tendría.
En primer’lugar, deje que s empiece por crear una malla de LSP de Table 1Sr-te (ver) entre PE1. NYC y todos los PES del IAD pop. Estos LSP se crearán, efímeramente, con el protocolo PCE de forma que el controlador Northstar tenga un control explícito de cada una de sus rutas.
Table 1: Malla de SR-TE LSP
Nombre LSP | Enrutador de entrada | Enrutador de salida |
|---|---|---|
pe1.nyc-pe1.iad | pe1.nyc | pe1.iad |
pe1.nyc-pe2.iad | pe1.nyc | pe2.iad |
pe1.nyc-pe3.iad | pe1.nyc | pe3.iad |
pe1.iad-pe1.nyc | pe1.iad | pe1.nyc |
pe2.iad-pe1.nyc | pe2.iad | pe1.nyc |
pe3.iad-pe1.nyc | pe3.iad | pe1.nyc |
Para crear un LSP de SR-TE en el controlador de Northstar utilice la opción de menú desplegable Applications > provision LSP o el botón Agregar de la ficha túnel. Aparecerá una ventana emergente en la que se agregarán los atributos del LSP, tal y como Figure 16se muestra en la. Un atributo clave al crear un LSP de SR-TE es proporcionarles un valor ‘nominal de’ ancho de banda planeado. De este modo, se garantiza que durante la reoptimización periódica o una reoptimización desencadenada, la congestión de los enlaces pueda ser’contabilizada por Northstar s CSPF, como se verá más adelante.
En el momento de redactar este acuerdo, las estadísticas de contrataciones de la Directiva de SR no estaban disponibles para el controlador de Northstar. En el futuro, el ancho de banda estático de 10k que se asigna a cada LSP de SR-TE puede reemplazarse por un valor de estadísticas de plano de datos dinámicos en tiempo real para poder realizar una optimización más granular del ancho de banda.
La malla de la SR-TE del LSP resultante Figure 17se muestra en la. Aquí puede ver qué vínculos se atraviesan con la malla.
Desde la perspectiva de Ingress PCC, puede ver que se han señalado tres LSP de SR-TE a través del controlador (PCE):
user@pe1.nyc> show path-computation-client lsp Name Status PLSP-Id LSP-Type Controller Path-Setup-Type pe1.nyc-pe1.iad Primary(Act) 10 ext-provised NS1 spring-te pe1.nyc-pe2.iad Primary(Act) 11 ext-provised NS1 spring-te pe1.nyc-pe3.iad Primary(Act) 12 ext-provised NS1 spring-te
Y que cada uno se haya instalado en inet. 3 RIB de PE1. NYC:
user@pe1.nyc# run show route protocol spring-te table inet.3 inet.3: 8 destinations, 12 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 128.49.106.10/32 *[SPRING-TE/8] 00:06:23, metric 1, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 18, Push 18, Push 22(top) 128.49.106.11/32 [SPRING-TE/8] 1d 00:38:38, metric 1, metric2 0 > to 192.0.2.7 via ge-0/0/2.0, Push 28, Push 20, Push 18(top) 128.49.106.13/32 *[SPRING-TE/8] 00:05:30, metric 1, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 20, Push 20, Push 26(top)
Puede comprobar la pila de etiquetas para cada LSP de SR-TE mediante la GUI del controlador Northstar, que Figure 18se muestra en el, como se muestra en las columnas grabar ruta y ero, y mostrar los SID de adyacencia para la topología.
Como puede ver en el Junos entrada detallada del enrutador’de entrada de la revisión s-te de LSP, la pila de etiquetas coincide. ’Vale la pena señalar que la primera etiqueta (en el caso del LSP de Sr-te de PE1. NYC-PE1. IAD) no se impone en realidad al paquete, ya que la dirección IP del campo PCEP NAI (nodo o identificador de proximidad) se utiliza para la selección de la interfaz de salida. Esto se ilustra en la siguiente salida.
Detailed SR-TE LSP output:
user@pe1.nyc> show spring-traffic-engineering lsp detail Name: pe1.nyc-pe1.iad Tunnel-source: Path computation element protocol(PCEP) To: 128.49.106.11 State: Up Telemetry statistics: Sensor-name: ingress-pe1.nyc-pe1.iad, Id: 3758096391 Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A BFD status: N/A BFD name: N/A SR-ERO hop count: 4 Hop 1 (Strict): NAI: IPv4 Adjacency ID, 192.0.2.6 -> 192.0.2.7 SID type: 20-bit label, Value: 17 Hop 2 (Strict): NAI: IPv4 Adjacency ID, 192.0.2.22 -> 192.0.2.23 SID type: 20-bit label, Value: 18 Hop 3 (Strict): NAI: IPv4 Adjacency ID, 192.0.2.33 -> 192.0.2.32 SID type: 20-bit label, Value: 20 Hop 4 (Strict): NAI: IPv4 Adjacency ID, 192.0.2.39 -> 192.0.2.38 SID type: 20-bit label, Value: 28
JUNOS inet.3 RIB entry for the SR-TE LSPs:
user@pe1.nyc# run show route protocol spring-te table inet.3 inet.3: 8 destinations, 12 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 128.49.106.10/32 *[SPRING-TE/8] 00:06:23, metric 1, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 18, Push 18, Push 22(top) 128.49.106.11/32 [SPRING-TE/8] 1d 00:38:38, metric 1, metric2 0 > to 192.0.2.7 via ge-0/0/2.0, Push 28, Push 20, Push 18(top) 128.49.106.13/32 *[SPRING-TE/8] 00:05:30, metric 1, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 20, Push 20, Push 26(top)
Nuestra red de ejemplo ofrece varios servicios a enrutadores de CE conectados. Desde CE1. NYC puede ver la pila de etiquetas resultante del transporte de SR-TE LSP entre PE1. NYC y PE2. IAD:
user@ce1.nyc> traceroute 198.51.100.60 traceroute to 198.51.100.60 (198.51.100.60), 30 hops max, 40 byte packets 1 pe1.nyc-ge-0-0-10.1 (198.51.100.1) 3.008 ms 1.918 ms 1.972 ms 2 p1.nyc-ge-0-0-2.0 (192.0.2.5) 12.785 ms 9.685 ms 24.882 ms MPLS Label=22 CoS=0 TTL=1 S=0 MPLS Label=18 CoS=0 TTL=1 S=0 MPLS Label=18 CoS=0 TTL=1 S=1 3 p1.ewr-ge-0-0-2.0 (192.0.2.15) 8.927 ms 14.411 ms 8.648 ms MPLS Label=18 CoS=0 TTL=1 S=0 MPLS Label=18 CoS=0 TTL=2 S=1 4 p1.iad-ge-0-0-6.0 (192.0.2.26) 9.039 ms 8.564 ms 10.233 ms MPLS Label=18 CoS=0 TTL=1 S=1 5 pe2.iad-ge-0-0-1.0 (192.0.2.40) 7.857 ms 7.481 ms 17.570 ms 6 ce1.iad-ge-0-0-7.0 (198.51.100.60) 8.767 ms 13.242 ms 15.533 ms user@ce1.nyc> ping 198.51.100.54 rapid count 100000000 size 500 PING 198.51.100.54 (198.51.100.54): 500 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [output truncated]
Ahora vamos’a ver cómo proporcionar un servicio de optimización de ancho de banda para un dominio de nivel 2 con el controlador Northstar. La red principal original se creó con el RSVP-TE LSP de ancho de banda automático. Estas se adaptan dinámicamente a las velocidades de tráfico crecientes y decrecientes. El enrutamiento en segmentos no tiene capacidades equivalentes, principalmente debido a la falta de estado del LSP de tránsito. Habilitaremos un atributo en el controlador Northstar para reaccionar a la congestión de interfaz para activar la reoptimización del LSP de SR-TE basándose únicamente en la recopilación de estadísticas de entrada. Para activar esta función del controlador de Northstar, vaya a los análisis de > de administración y alterne la función de redireccionamiento según se muestra en Figure 20la.
Para garantizar que la topología también muestre estadísticas de interfaz en tiempo real, utilice el cuadro desplegable del lado izquierdo de la interfaz gráfica de usuario. Seleccione rendimiento y active la utilización de interfaces, como Figure 21se muestra en la.
Para simular el tráfico en la red, con el fin de ilustrar la capacidad del controlador’para redireccionar LSP de la extensión de proveedores de’distribución fuera de enlaces congestionados, deje que un s inicie algunos pings extendidos con grandes tamaños de paquetes entre PE1. NYC y P1. IAD:
user@pe1.nyc> traceroute 192.0.2.26 traceroute to 192.0.2.26 (192.0.2.26), 30 hops max, 40 byte packets 1 p1.nyc-ge-0-0-2.0 (192.0.2.5) 3.569 ms 2.412 ms 3.261 ms 2 p1.ewr-ge-0-0-2.0 (192.0.2.15) 6.769 ms 3.793 ms 3.152 ms 3 p1.iad-ge-0-0-6.0 (192.0.2.26) 6.040 ms 5.814 ms 5.074 ms user@pe1.nyc> ping rapid 192.0.2.26 count 100000000 size 500 PING 192.0.2.26 (192.0.2.26): 500 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [output truncated]
Y, asimismo, en la otra dirección…
user@p1.iad> traceroute 128.49.106.1 traceroute to 128.49.106.1 (128.49.106.1), 30 hops max, 40 byte packets 1 p1.phl-ge-0-0-3.0 (192.0.2.31) 2.637 ms 2.077 ms 2.322 ms 2 p1.nyc-ge-0-0-5.0 (192.0.2.20) 3.493 ms 5.646 ms 3.116 ms 3 pe1.nyc-lo0.0 (128.49.106.1) 7.056 ms 5.973 ms 7.435 ms user@p1.iad> ping 128.49.106.1 rapid count 10000000 size 1000 PING 128.49.106.1 (128.49.106.1): 1000 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [output truncated]
Como puede ver en Figure 22, Northstar detecta la congestión del enlace, lo que activará una reoptimización de la ruta y redirigirá los LSP de la Sr-te fuera de los vínculos congestionados.
Si selecciona escala de tiempo en el panel izquierdo, podrá ver Figure 23 que se ha detectado en la congestión del vínculo, según el umbral de congestión de la interfaz, y que los proveedores de idiomas que atravesaron el vínculo congestionado se han programado para su redireccionamiento.
Volviendo a la vista’de túnel Northstar s Topology >, puede ver el LSP de Sr-te entre PE1. NYC y PE2. IAD Figure 24. Puede ver que ahora el LSP está en un nuevo camino evitando los enlaces congestionados.
Y el enrutador’de entrada s-te LSP se ha actualizado también:
user@pe1.nyc> show route table inet.3 protocol spring-te inet.3: 8 destinations, 12 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 128.49.106.10/32 *[SPRING-TE/8] 00:00:07, metric 5, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 18, Push 20, Push 26(top) 128.49.106.11/32 [SPRING-TE/8] 00:00:07, metric 5, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 28, Push 18, Push 22(top) 128.49.106.13/32 *[SPRING-TE/8] 00:00:07, metric 5, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 20, Push 18, Push 22(top)
La ingeniería de tráfico es una función indispensable en la mayoría de las redes de área extensa de red troncal. Un objetivo principal de TE de hoy es la optimización del uso de los recursos. RSVP-TE tiene un largo historial y una gran casilla de herramientas para aprovecharse a la vez que SR necesita aprovechar nuevas herramientas, como la telemetría y controladoras de streaming, para lograr un mejor uso de los recursos. Este capítulo ofrecía varias opciones específicas de SR para crear rutas explícitas, varias formas de cálculo distribuido y centralizado de rutas y, finalmente, cómo se puede migrar nuestra red de ejemplo a un SR. Mientras que la solución de optimización del ancho de banda difiere bastante del RSVP tradicional, puede proporcionar un medio para reaccionar ante la congestión de interfaz para optimizar la optimización de los recursos.