Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Configurar

Evolución de la red

MPLS unificado de Cisco

Características y componentes

Información de la Etiqueta de Carga en BGP-4 (RFC 3107)

Convergencia independiente de prefijos BGP (BGP PIC)

BGP Add-Path

Alternativas sin loops y rLFA para IGP Fast-Convergence

Ejemplo de Arquitectura de Cisco Unified MPLS

Ejemplo de configuración de MPLS unificado

Router de borde de área principal - Cisco IOS® XR

Configuración del router de borde de área principal

Configuración previa a la agregación

Configuración de la puerta de enlace del sitio de la celda (CSG)

Configuración de MTG

Verificación

Salida del nodo CSG

Salidas de nodos anteriores al agregado

Resultados de los nodos ABR de núcleo

Troubleshoot

Información Relacionada

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.

Información Relacionada

- Arquitectura MPLS perfecta

- Informe técnico de Cisco Unified MPLS

- Sistema de transporte de paquetes de operador (CPT) de Cisco

- Soporte Técnico y Documentación - Cisco Systems