Ejemplo de Configuración, Funciones y Funcionalidad de MPLS Unificadas
Contenido
Introducción
Este documento describe Unified Multiprotocol Label Switching (MPLS), que consiste en la ampliación. Proporciona un marco de soluciones tecnológicas para ofrecer servicios o tráfico de extremo a extremo en una infraestructura tradicionalmente segmentada. Utiliza las ventajas de una infraestructura jerárquica a medida que mejora la escalabilidad y la simplicidad del diseño de la red.
Prerequisites
Requirements
No hay requisitos específicos para este documento.
Componentes Utilizados
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Configurar
Evolución de la red
Cuando se observa el historial de los servicios basados en paquetes de red, se puede observar un cambio en los valores empresariales de la red. Esto va desde mejoras de conectividad discretas para hacer que las aplicaciones sean lo más fluidas posible, hasta tecnologías de colaboración para admitir la colaboración móvil. Por último, los servicios en la nube a demanda se introducen con los servicios de aplicaciones para optimizar las herramientas utilizadas con una organización y mejorar la estabilidad y el coste de propiedad.
Figure 1
Esta mejora continua del valor y la funcionalidad de la red se traduce en una necesidad mucho más generalizada de simplicidad, capacidad de gestión, integración y estabilidad de la red, en la que las redes se han segmentado como resultado de las islas operativas inconexas y de la ausencia de un control de ruta de extremo a extremo real. Ahora es necesario combinarlo todo con una única arquitectura fácil de gestionar, que proporcione escalabilidad a 100 000 nodos y utilice las tecnologías de alta disponibilidad y convergencia rápida actuales. Esto es lo que Unified MPLS aporta a la tabla, que es la red segmentada en un único plano de control y una visibilidad de ruta de extremo a extremo.
Requisitos de red modernos
- Aumento de la demanda de ancho de banda (Vídeo)
- Aumentar la complejidad de las aplicaciones (nube y virtualización)
- Aumento de la necesidad de convergencia (movilidad)
¿Cómo puede simplificar las operaciones MPLS en redes cada vez más grandes con requisitos de aplicaciones más complejos?
Retos MPLS tradicionales con diferentes tecnologías de acceso
- Complejidad para lograr una convergencia de 50 milisegundos con Traffic Engineering Fast Reroute (TE FRR)
- Necesidad de sofisticados protocolos de routing e interacción con protocolos de capa 2
- Dividir grandes redes en dominios mientras los servicios se proporcionan de extremo a extremo
- Mecanismos comunes de resistencia y convergencia integral
- Solución de problemas y aprovisionamiento integral en varios dominios
La atracción de Unified MPLS se resume en esta lista:
- Reducción del número de puntos operativos.
- En las plataformas de transporte en general, se debe configurar un servicio en cada elemento de red a través de los Puntos Operativos. El sistema de administración debe conocer la topología.
- En Unified MPLS, con la integración de todas las islas MPLS, se logra el número mínimo de puntos operativos.
- Posibilidad de aprovisionar servicios fácilmente: VPN de capa 3 (L3), servicio de cable privado virtual (VPWS), servicio de LAN privada virtual (VPLS), sin mecanismos de conexión de pseudowire (PW-stitching) o InterAS. Con la introducción de MPLS dentro de la agregación, se evita alguna configuración estática que crea islas MPLS.
- Proporcione transporte MPLS de extremo a extremo.
- Mantenga separadas las áreas de protocolo de gateway interior (IGP) y las tablas de routing pequeñas.
- Convergencia Rápida.
- Fácil de configurar y resolver problemas.
- Capacidad de integración con cualquier tecnología de acceso.
- Preparación para IPv6.
MPLS unificado de Cisco
Unified MPLS se define por la incorporación de funciones adicionales con MPLS clásico/tradicional y ofrece más escalabilidad, seguridad, simplicidad y capacidad de gestión. Para ofrecer los servicios MPLS de extremo a extremo, se necesita una ruta de switches etiquetados (LSP) de extremo a extremo. El objetivo es mantener los servicios MPLS (MPLS VPN, MPLS L2VPN) tal como están, pero introducir una mayor escalabilidad. Para hacer esto, mueva algunos de los prefijos IGP al protocolo de gateway fronterizo (BGP) (los prefijos de loopback de los routers de borde del proveedor (PE)), que luego distribuye los prefijos de extremo a extremo.
Figure 2
Antes de que se hable de la arquitectura de Cisco Unified MPLS, es importante comprender las funciones clave que se utilizan para que esto se haga realidad.
Características y componentes
Información de la Etiqueta de Carga en BGP-4 (RFC 3107)
Es un requisito previo tener un método escalable para intercambiar prefijos entre segmentos de red. Puede combinar los IGP (Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS) o Enhanced Interior Gateway Routing Protocol (EIGRP) en un único dominio. Sin embargo, un IGP no está diseñado para llevar 100.000 prefijos. El protocolo de elección para ese fin es BGP. Se trata de un protocolo bien probado que admite Internet con 100 000 rutas y entornos MPLS-VPN con millones de entradas. Cisco Unified MPLS utiliza BGP-4 con intercambio de información de etiquetas (RFC3107). Cuando BGP distribuye una ruta, también puede distribuir una etiqueta MPLS asignada a esa ruta. La información de asignación de etiquetas MPLS para la ruta se transporta en el mensaje de actualización BGP que contiene la información sobre la ruta. Si no se cambia el salto siguiente, se conserva la etiqueta y ésta cambia si cambia el salto siguiente. En Unified MPLS, el salto siguiente cambia en los routers de borde de área (ABR).
Cuando habilita el RFC 3107 en ambos routers BGP, los routers se anuncian mutuamente que luego pueden enviar etiquetas MPLS con las rutas. Si los routers negocian con éxito su capacidad para enviar etiquetas MPLS, los routers agregan etiquetas MPLS a todas las actualizaciones de BGP salientes.
El intercambio de etiquetas es necesario para mantener la información de trayectoria de extremo a extremo entre los segmentos. Como resultado, cada segmento se vuelve lo suficientemente pequeño como para ser administrado por los operadores y al mismo tiempo hay información de circuito distribuida para el reconocimiento de trayecto entre dos altavoces IP diferentes.
¿Cómo funciona?
Figure 3
En la figura 3 puede ver que hay tres segmentos con la ruta de los switches etiquetados de protocolo de descubrimiento de etiquetas (LDP LSP) y que la red de acceso no tiene LDP habilitado. El objetivo es unirlos para que haya una única ruta MPLS (LSP jerárquico de BGP interno (iBGP)) entre nodos de preagregación (Pre-agregación). Como la red es un único sistema autónomo BGP (AS), todas las sesiones son sesiones iBGP. Cada segmento ejecuta sus propias trayectorias IGP (OSPF, IS-IS o EIGRP) y LDP LSP dentro del dominio IGP. Dentro de Cisco Unified MPLS, los routers (ABR) que se unen a los segmentos deben ser reflectores de ruta en línea BGP con Next-Hop-Self y RFC 3107 para llevar un IPv4 + Label configurado en las sesiones. Estos altavoces BGP se encuentran dentro de la arquitectura Cisco Unified MPLS a la que se hace referencia como ABR.
¿Por qué los ABR están en línea para los reflectores de ruta?
Uno de los objetivos de Unified MPLS es contar con una infraestructura integral altamente escalable. Por lo tanto, cada segmento debe mantenerse sencillo para funcionar. Todos los pares son pares iBGP, por lo tanto, existe la necesidad de una malla completa de pares entre todos los altavoces iBGP dentro de la red completa. Esto resulta en un entorno de red muy poco práctico si hay miles de altavoces BGP. Si los ABR se convierten en reflectores de ruta, el número de peering iBGP se reduce al número de altavoces BGP 'por segmento' en lugar de entre 'todos' los altavoces BGP del AS completo.
¿Por qué el próximo salto?
BGP funciona en la base de búsquedas de ruteo recursivas. Esto se hace para dar cabida a la escalabilidad dentro del IGP subyacente que se utiliza. Para la búsqueda recursiva, BGP utiliza Next-Hop asociado a cada entrada de ruta BGP. Por ejemplo, si un Nodo de Origen desea enviar un paquete a un Nodo de Destino y si el paquete llega al router BGP, entonces el router BGP realiza una búsqueda de ruteo en su tabla de ruteo BGP. Encuentra una ruta hacia Destination-Node y encuentra el Next-Hop como el siguiente paso. El IGP subyacente debe conocer este salto siguiente. Como paso final, el router BGP reenvía el paquete a partir de la información de etiqueta IP y MPLS conectada a ese Siguiente Salto.
Para asegurarse de que dentro de cada segmento solamente el IGP necesita conocer los Next-Hops, es necesario que el Next-Hop asociado a la entrada BGP esté dentro del segmento de red y no dentro de un vecino o un segmento más alejado. Si reescribe el Siguiente Salto BGP con la función Siguiente-Salto-Automático, asegúrese de que el Siguiente Salto esté dentro del segmento local.
Ponerlo todo
Figure 4
La figura 4 proporciona un ejemplo de cómo funciona el prefijo VPN L3 'A' y el intercambio de etiquetas y cómo se crea la pila de etiquetas MPLS para tener la información de trayectoria de extremo a extremo para el flujo de tráfico entre ambos PE.
La red se divide en tres dominios independientes IGP/LDP. El tamaño reducido de las tablas de ruteo y reenvío en los routers es para permitir una mejor estabilidad y una convergencia más rápida. El LDP se utiliza para generar LSP intradománicos dentro de los dominios. Las etiquetas IPv4+ de BGP RFC 3107 se utilizan como protocolo de distribución de etiquetas entre dominios para generar LSPs BGP jerárquicos en los dominios. BGP3107 inserta una etiqueta adicional en la pila de etiquetas de reenvío en la arquitectura de Unified MPLS.
Intradomain - LDP LSP
Interdominio - LSP jerárquico BGP
Figure 5
El PE31 anuncia el prefijo VPN 'A' a PE11 con la etiqueta de servicio L3VPN 30 y el salto siguiente como loopback de PE31 a través de BGP jerárquico de extremo a extremo entre dominios . Ahora, observe la trayectoria de reenvío para el prefijo VPN 'A' de PE11 a PE31.
- En PE11, el Prefijo A se conoce a través de la sesión BGP con PE31 ya que el PE31 de salto siguiente y el PE31 se puede alcanzar recursivamente a través de P1 con la etiqueta BGP 100. PE11 recibió información de IPv4 + Label de P1 como actualizaciones de BGP porque está habilitado con la función RFC 3107 para enviar la información de IPv4 + Label.
- P1 es accesible desde PE11 a través de LDP LSP intradomain y agrega otra etiqueta LDP sobre la etiqueta BGP. Finalmente, el paquete sale del nodo PE11 con tres etiquetas. Por ejemplo, la etiqueta de servicio 30 L3VPN, la etiqueta 100 BGP y la etiqueta 200 LDP IGP.
- La etiqueta superior de LDP continúa intercambiándose en LDP LSP de LDP intradomain y el paquete alcanza P1 con dos etiquetas después de Popping de Salto Penúltimo (PHP).
- P1 se configura como Reflector de ruta en línea (RR) con uno de salto siguiente y se une a dos dominios IGP o LDP.
- En P1, el salto siguiente para PE31 se cambia a P2 y la actualización se recibe a través de BGP con IPv4 + Label (RFC3107). La etiqueta BGP se intercambia con la nueva etiqueta porque se cambia el siguiente salto y la etiqueta IGP se empuja arriba.
- El paquete sale del nodo P1 con tres etiquetas y la etiqueta de servicio 30 está intacta. Es decir, la etiqueta de servicio 30 L3VPN, la etiqueta 101 BGP y la etiqueta 201 LDP.
- La etiqueta superior LDP intercambia en LDP LSP intradomain y el paquete alcanza P2 con dos etiquetas después de PHP.
- En P2, el salto siguiente para PE31 se cambia de nuevo y se puede alcanzar a través de IGP. La etiqueta BGP se elimina ya que se recibe una etiqueta BGP implícita-nula de PE31 para PHP.
- El paquete sale con dos etiquetas. Por ejemplo, la etiqueta de servicio 30 L3VPN y la etiqueta 110 LDP.
- En PE31, el paquete llega con una etiqueta después de PHP de la etiqueta LDP y basada en la etiqueta de servicio 30. El paquete sin etiqueta se reenvía al destino CE31 en Virtual Routing and Forwarding (VRF).
Cuando observa la pila de etiquetas MPLS, el switching del paquete entre un dispositivo de origen y de destino basado en el prefijo anterior y el intercambio de etiquetas se observa dentro del entorno de conmutación MPLS.
‘Figura 6’
Convergencia independiente de prefijos BGP (BGP PIC)
Esta es una tecnología de Cisco que se utiliza en escenarios de falla de BGP. La red converge sin perder los segundos tradicionales en la reconvergencia BGP. Cuando se utiliza BGP PIC, la mayoría de los escenarios de fallas se pueden reducir a un tiempo de reconvergencia inferior a 100 mseg.
¿Cómo se hace?
Tradicionalmente, cuando BGP detecta una falla, vuelve a calcular para cada entrada BGP para la mejor trayectoria. Cuando hay una tabla de ruteo con miles de entradas de ruta, esto puede tomar una cantidad considerable de tiempo. Además, este router BGP necesita distribuir todos esos mejores trayectos nuevos a cada uno de sus vecinos para informarles de la topología de red modificada y los mejores trayectos modificados. Como último paso, cada uno de los altavoces BGP del receptor necesita hacer un mejor cálculo de trayectoria para encontrar las nuevas mejores trayectorias.
Cada vez que el primer altavoz BGP detecta algo incorrecto, comienza el mejor cálculo de trayectoria hasta que todos los altavoces BGP vecinos hayan hecho su recálculo, el flujo de tráfico podría ser descartado.
Figura 7
La función BGP PIC for IP and MPLS VPN mejora la convergencia BGP después de una falla de red. Esta convergencia se aplica tanto a las fallas de núcleo como de borde y se puede utilizar tanto en redes IP como MPLS. El BGP PIC para IP y la función MPLS VPN crean y almacenan una ruta de respaldo/alternativa en la base de información de routing (RIB), la base de información de reenvío (FIB) y Cisco Express Forwarding (CEF) para que, cuando se detecta una falla, la ruta de respaldo/alternativa pueda tomar el control inmediatamente, por lo que habilita una conmutación por fallas rápida.
Con una sola reescritura de la información del siguiente salto, se restaura el flujo de tráfico. Además, la convergencia de BGP de red se produce en segundo plano, pero los flujos de tráfico ya no se ven afectados. Esta reescritura se produce dentro de los 50 milisegundos. Si utiliza esta tecnología, la convergencia de la red se reduce de segundos a 50 mseg, además de la convergencia IGP.
BGP Add-Path
BGP Add-Path es una mejora en cómo se comunican las entradas BGP entre los altavoces BGP. Si en un determinado altavoz BGP hay más de una entrada hacia un destino determinado, entonces ese altavoz BGP sólo envía la entrada que es su mejor trayectoria para ese destino a sus vecinos. El resultado es que no se hacen provisiones para permitir el anuncio de varias trayectorias para el mismo destino.
BGP Add-Path es una función BGP que permite más como sólo la mejor trayectoria, y permite múltiples trayectorias para el mismo destino sin que las nuevas trayectorias reemplacen implícitamente a las anteriores. Esta extensión a BGP es particularmente importante para ayudar con BGP PIC, cuando se utilizan los reflectores de ruta BGP, de modo que los diferentes altavoces BGP dentro de un AS tengan acceso a más trayectorias BGP como sólo la 'mejor trayectoria BGP' de acuerdo con el reflector de ruta.
Alternativas sin loops y rLFA para IGP Fast-Convergence
Las operaciones para lograr una restauración de 50 milisegundos después de una falla de nodo o de enlace pueden simplificarse drásticamente con la introducción de una nueva tecnología denominada alternativas sin loops (LFA). LFA mejora los protocolos de routing de estado de link (IS-IS y OSPF) para encontrar rutas de routing alternativas de una manera sin bucles. LFA permite a cada router definir y utilizar una trayectoria de respaldo predeterminada si falla una adyacencia (nodo de red o enlace). Para ofrecer un tiempo de restauración de 50 ms en caso de fallas de link o nodo, se puede implementar MPLS TE FRR. Sin embargo, esto requiere la adición de otro protocolo (Resource Reservation Protocol o RSVP) para la configuración y administración de túneles TE. Aunque esto podría ser necesario para la administración del ancho de banda, la operación de protección y restauración no requiere la administración del ancho de banda. Por lo tanto, la sobrecarga asociada con la adición de RSVP TE se considera alta para la simple protección de links y nodos.
LFA puede proporcionar una técnica sencilla y sencilla sin la implementación de RSVP TE en tales escenarios. Como resultado de estas técnicas, los routers interconectados de hoy en día en redes a gran escala pueden ofrecer una restauración de 50 mseg para fallas de link y nodo sin necesidad de configuración para el operador.
Figura 8
El LFA-FRR es un mecanismo que proporciona protección local para el tráfico unidifusión en IP, MPLS, Ethernet sobre MPLS (EoMPLS), Multiplexación Inversa sobre ATM (IMA) sobre MPLS, Circuit Emulation Service sobre Packet Switched Network (CESoPSN) sobre MPLS y Multiplexación por División de Tiempo Independiente de Estructura sobre Paquetes (SAToP) sobre redes MPLS. Sin embargo, algunas topologías (como la topología de anillo) requieren una protección que no ofrece el LFA-FRR solo. La función LFA-FRR remoto es útil en tales situaciones.
El LFA-FRR remoto amplía el comportamiento básico de LFA-FRR a cualquier topología. Reenvía el tráfico alrededor de un nodo fallido a un LFA remoto que está a más de un salto de distancia. En la Figura 9, si el link entre C1 y C2 no alcanza el A1, entonces C2 envía el paquete a través de una sesión LDP dirigida a C5 que tiene alcance a A1.
Figura 9
En LFA-FRR remoto, un nodo calcula dinámicamente su nodo LFA. Después de determinar el nodo alternativo (que no está conectado directamente), el nodo establece automáticamente una sesión de protocolo de distribución de etiquetas dirigido (LDP) en el nodo alternativo. La sesión LDP dirigida intercambia etiquetas para la corrección de errores de reenvío específica (FEC).
Cuando el link falla, el nodo utiliza el apilamiento de etiquetas para tunelizar el tráfico al nodo LFA remoto, para reenviar el tráfico al destino. Todos los intercambios de etiquetas y la tunelización al nodo LFA remoto son de naturaleza dinámica y no se requiere el preaprovisionamiento. Todo el mecanismo de intercambio y tunelización de etiquetas es dinámico y no implica ningún aprovisionamiento manual.
Para los LSPs intradomanianos, el LFA FRR remoto se utiliza para el tráfico MPLS de unidifusión en topologías de anillo. El LFA FRR remoto precalcula una trayectoria de respaldo para cada prefijo en la tabla de ruteo IGP, lo que permite que el nodo cambie rápidamente a la trayectoria de respaldo cuando se detecta una falla. Esto proporciona tiempos de recuperación del orden de 50 milisegundos.
Ejemplo de Arquitectura de Cisco Unified MPLS
Cuando todas las herramientas y funciones anteriores se combinan en un entorno de red, crea el entorno de red Cisco Unified MPLS. Este es el ejemplo de arquitectura para los grandes proveedores de servicios.
Figura 10
- El núcleo y la agregación se organizan como dominios IGP/LDP distintos.
- LSP jerárquicos entre dominios basados en RFC 3107, etiquetas IPv4+ BGP que se extienden hasta la edad previa.
- LSPs intradomain basados en LDP.
- Los LSPs de Agregación/Núcleo entre dominios se amplían en las redes de acceso mediante la distribución del Protocolo de gateway interior de redes de acceso de radio (RAN IGP) en el iBGP entre dominios y distribuyen los prefijos iBGP etiquetados necesarios (gateway MPC (Núcleo de paquete móvil) en RAN IGP (a través de comunidades BGP).
Ejemplo de configuración de MPLS unificado
A continuación se muestra un ejemplo simplificado de Unified MPLS.
Router de borde de área principal - Cisco IOS® XR
Routers de gateway de sitio de celdas y de agregación previa - Cisco IOS
Figura 11
| 200:200 | Comunidad MPC |
| 300:300 | Comunidad de agregación |
| Dominio IGP del núcleo | Nivel 2 de ISIS |
| Dominio IGP de agregación | Nivel de ISIS 1 |
| Acceso a dominio IGP | Áreas OSPF 0 |
Configuración del router de borde de área principal
Figura 12
! IGP Configuration
router isis core-agg
net 49.0100.1010.0001.0001.00
address-family ipv4 unicast
metric-style wide
propagate level 1 into level 2 route-policy drop-all ! Disable L1 to L2 redistribution
!
interface Loopback0
ipv4 address 10.10.10.1 255.255.255.255
passive
!
interface TenGigE0/0/0/0
!
interface TenGigE0/0/0/1
circuit-type level-2-only ! Core facing ISIS L2 Link
!
interface TenGigE0/0/0/2
circuit-type level-1 ! Aggregation facingis ISIS L1 Link
!
route-policy drop-all
drop
end-policy
! BGP Configuration
router bgp 100
ibgp policy out enforce-modifications
bgp router-id 10.10.10.1
address-family ipv4 unicast
allocate-label all ! Send labels with BGP routes
!
session-group infra
remote-as 100
cluster-id 1001
update-source Loopback0
!
neighbor-group agg
use session-group infra
address-family ipv4 labeled-unicast
route-reflector-client
route-policy BGP_Egress_Filter out ! BGP Community based Egress filtering
next-hop-self
!
neighbor-group mpc
use session-group infra
address-family ipv4 labeled-unicast
route-reflector-client
next-hop-self
!
neighbor-group core
use session-group infra
address-family ipv4 labeled-unicast
next-hop-self
community-set Allowed-Comm
200:200,
300:300,
!
route-policy BGP_Egress_Filter
if community matches-any Allowed-Comm then
pass
Configuración previa a la agregación
Figura 13
interface Loopback0
ipv4 address 10.10.9.9 255.255.255.255
!
interface Loopback1
ipv4 address 10.10.99.9 255.255.255.255
! Pre-Agg IGP Configuration
router isis core-agg
net 49.0100.1010.0001.9007.00
is-type level-1 ! ISIS L1 router
metric-style wide
passive-interface Loopback0 ! Core-agg IGP loopback0
!RAN Access IGP Configuration
router ospf 1
router-id 10.10.99.9
redistribute bgp 100 subnets route-map BGP_to_RAN ! iBGP to RAN IGP redistribution
network 10.9.9.2 0.0.0.1 area 0
network 10.9.9.4 0.0.0.1 area 0
network 10.10.99.9 0.0.0.0 area 0
distribute-list route-map Redist_from_BGP in ! Inbound filtering to prefer
labeled BGP learnt prefixes
ip community-list standard MPC_Comm permit 200:200
!
route-map BGP_to_RAN permit 10 ! Only redistribute prefixes
marked with MPC community
match community MPC_Comm
set tag 1000
route-map Redist_from_BGP deny 10
match tag 1000
!
route-map Redist_from_BGP permit 20
! BGP Configuration
router bgp 100
ibgp policy out enforce-modifications
bgp router-id 10.10.9.10
bgp cluster-id 909
neighbor csr peer-group
neighbor csr remote-as 100
neighbor csr update-source Loopback100 ! Cell Site - Routers RAN IGP
loopback100 as source
neighbor abr peer-group
neighbor abr remote-as 100
neighbor abr update-source Loopback0 ! Core POP ABRs - core-agg IGP
loopback0 as source
neighbor 10.10.10.1 peer-group abr
neighbor 10.10.10.2 peer-group abr
neighbor 10.10.13.1 peer-group csr
!
address-family ipv4
bgp redistribute-internal
network 10.10.9.10 mask 255.255.255.255 route-map AGG_Comm ! Advertise with
Aggregation Community (300:300)
redistribute ospf 1 ! Redistribute RAN IGP prefixes
neighbor abr send-community
neighbor abr next-hop-self
neighbor abr send-label ! Send labels with BGP routes
neighbor 10.10.10.1 activate
neighbor 10.10.10.2 activate
exit-address-family
!
route-map AGG_Comm permit 10
set community 300:300
Configuración de la puerta de enlace del sitio de la celda (CSG)
Figura 14
interface Loopback0
ip address 10.10.13.2 255.255.255.255
! IGP Configuration
router ospf 1
router-id 10.10.13.2
network 10.9.10.0 0.0.0.1 area 0
network 10.13.0.0 0.0.255.255 area 0
network 10.10.13.3 0.0.0.0 area 0
Configuración de MTG
Figura 15
Interface lookback0
ip address 10.10.11.1 255.255.255.255
! IGP Configuration
router isis core-agg
is-type level-2-only ! ISIS L2 router
net 49.0100.1010.0001.1001.00
address-family ipv4 unicast
metric-style wide
! BGP Configuration
router bgp 100
ibgp policy out enforce-modifications
bgp router-id 10.10.11.1
address-family ipv4 unicast
network 10.10.11.1/32 route-policy MPC_Comm ! Advertise Loopback-0 with MPC Community
allocate-label all ! Send labels with BGP routes
!
session-group infra
remote-as 100
update-source Loopback0
!
neighbor-group abr
use session-group infra
address-family ipv4 labeled-unicast
next-hop-self
!
neighbor 10.10.6.1
use neighbor-group abr
!
neighbor 10.10.12.1
use neighbor-group abr
community-set MPC_Comm
200:200
end-set
!
route-policy MPC_Comm
set community MPC_Comm
end-policy
Verificación
El prefijo de loopback de la gateway de paquetes móviles (MPG) es 10.10.11.1/32, por lo que el prefijo es de interés. Ahora, observe cómo se reenvían los paquetes de CSG a MPG.
El router CSG conoce el prefijo MPC 10.10.11.1 desde Pre-agg con la etiqueta de ruta 1000 y se puede reenviar como un paquete etiquetado con la etiqueta LDP saliente 31 (LDP dentro del dominio). La comunidad MPC 200:200 se mapeó con la etiqueta de ruta 1000 en el nodo Pre-Ag mientras la redistribución está en OSPF.
Salida del nodo CSG
CSG#sh mpls forwarding-table 10.10.11.1 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
34 31 10.10.11.1/32 0 Vl40 10.13.1.0
MAC/Encaps=14/18, MRU=1500, Label Stack{31}
Salidas de nodos anteriores al agregado
En el nodo anterior, el prefijo MPC se redistribuye del BGP al proceso OSPF de acceso RAN con filtrado basado en la comunidad y el proceso OSPF se redistribuye en BGP. Esta redistribución controlada es necesaria para lograr una disponibilidad de IP de extremo a extremo, al mismo tiempo cada segmento tiene rutas mínimas requeridas.
El prefijo 10.10.11.1/32 se conoce a través del BGP 100 jerarquí con la comunidad MPC 200:200 conectada. La etiqueta 16020 BGP 3107 recibida del router de borde de área de núcleo (ABR) y la etiqueta LDP 22 se agrega en la parte superior para el reenvío dentro del dominio después de la búsqueda recursiva de salto siguiente.
Pre-AGG1#sh ip route 10.10.11.1
Routing entry for 10.10.11.1/32
Known via "bgp 100", distance 200, metric 0, type internal
Redistributing via ospf 1
Advertised by ospf 1 subnets tag 1000 route-map BGP_TO_RAN
Routing Descriptor Blocks:
* 10.10.10.2, from 10.10.10.2, 1d17h ago
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: 16020
Pre-AGG1#sh bgp ipv4 unicast 10.10.11.1
BGP routing table entry for 10.10.11.1/32, version 116586
Paths: (2 available, best #2, table default)
Not advertised to any peer
Local
<SNIP>
Local
10.10.10.2 (metric 30) from 10.10.10.2 (10.10.10.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: 200:200
Originator: 10.10.11.1, Cluster list: 0.0.3.233, 0.0.2.89
mpls labels in/out nolabel/16020
Pre-AGG1#sh bgp ipv4 unicast labels
Network Next Hop In label/Out label
10.10.11.1/32 10.10.10.1 nolabel/16021
10.10.10.2 nolabel/16020
Pre-AGG1#sh mpls forwarding-table 10.10.10.2 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
79 22 10.10.10.2/32 76109369 Vl10 10.9.9.1
MAC/Encaps=14/18, MRU=1500, Label Stack{22}
Pre-AGG#sh mpls forwarding-table 10.10.11.1 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
530 16020 10.10.11.1/32 20924900800 Vl10 10.9.9.1
MAC/Encaps=14/22, MRU=1496, Label Stack{22 16020}
Resultados de los nodos ABR de núcleo
El prefijo 10.10.11.1 se conoce a través de IGP intradomain (ISIS-L2) y según la tabla de reenvío MPLS. Es accesible a través de LDP LSP.
ABR-Core2#sh ip route 10.10.11.1
Routing entry for 10.10.11.1/32
Known via "isis core-agg", distance 115, metric 20, type level-2
Installed Sep 12 21:13:03.673 for 2w3d
Routing Descriptor Blocks
10.10.1.0, from 10.10.11.1, via TenGigE0/0/0/0, Backup
Route metric is 0
10.10.2.3, from 10.10.11.1, via TenGigE0/0/0/3, Protected
Route metric is 20
No advertising protos.
Para la distribución de los prefijos entre las áreas segmentadas, se utiliza BGP con la etiqueta (RFC 3107). Lo que aún debe residir dentro de las áreas segmentadas del IGP son los loopbacks de los PE y las direcciones relacionadas con la infraestructura central.
Los routers BGP que conectan diferentes áreas juntos son los ABR que actúan como un Route-Reflector BGP. Estos dispositivos utilizan la función Next-Hop-Self para evitar la necesidad de tener todos los Next-Hops del sistema autónomo completo dentro del IGP, en lugar de solamente las direcciones IP de los PE y la infraestructura central. La detección del loop se completa en función de los ID de clúster BGP.
Para la resistencia de la red, BGP PIC con la función BGP Add Path se debe utilizar con BGP y LFA con IGP. Estas características no se utilizan en el ejemplo anterior.
Troubleshoot
Actualmente, no hay información específica de troubleshooting disponible para esta configuración.
Comentarios