Configuración GMPLS
Introducción a GMPLS
La MPLS tradicional está diseñada para transportar tráfico IP de capa 3 utilizando rutas establecidas basadas en IP y asociando estas rutas con etiquetas asignadas arbitrariamente. Estas etiquetas pueden ser configuradas explícitamente por un administrador de red, o pueden ser asignadas dinámicamente por medio de un protocolo como LDP o RSVP.
GMPLS generaliza MPLS en el sentido de que define etiquetas para conmutación de diversos tipos de tráfico de capa 1, capa 2 o capa 3. Los nodos GMPLS pueden tener vínculos con una o más de las siguientes capacidades de conmutación:
Capacidad con conmutación de fibra (FSC)
Capacidad con conmutación lambda (LSC)
Multiplexación por división de tiempo (TDM) conmutada (TSC)
Capacidad de conmutación de paquetes (PSC)
Las rutas de conmutación de etiquetas (LSP) deben comenzar y terminar en vínculos con la misma capacidad de conmutación. Por ejemplo, los enrutadores pueden establecer LSP conmutados por paquetes con otros enrutadores. Los LSP pueden transportarse a través de un LSP conmutado TDM entre multiplexores de adición/caída (ADM) SONET, que a su vez pueden transferirse a través de un LSP con conmutación lambda.
El resultado de esta extensión del protocolo MPLS es una expansión en el número de dispositivos que pueden participar en la conmutación de etiquetas. Los dispositivos de capa inferior, como los OXC y los ADM SONET, ahora pueden participar en la señalización GMPLS y configurar rutas para transferir datos. Un enrutador puede participar en la señalización de rutas ópticas a través de una red de transporte.
Dos modelos de servicio determinan la visibilidad que un nodo cliente (un enrutador, por ejemplo) tiene en el núcleo óptico o en la red de transporte. La primera es a través de una interfaz de usuario a red (UNI), que a menudo se conoce como el modelo de superposición. El segundo se conoce como el modelo de pares. Juniper Networks admite ambos modelos.
No existe necesariamente una correspondencia uno a uno entre una interfaz física y una interfaz GMPLS. Si una conexión GMPLS utiliza un conector físico no canalizado, la etiqueta GMPLS puede utilizar el ID de puerto físico. Sin embargo, la etiqueta para las interfaces canalizadas a menudo se basa en un canal o intervalo de tiempo. Por consiguiente, es mejor referirse a las etiquetas GMPLS como identificadores de un recurso en un vínculo de ingeniería de tráfico.
Para establecer LSP, GMPLS utiliza los siguientes mecanismos:
Un canal de control fuera de banda y un canal de datos: los mensajes RSVP para la configuración de LSP se envían a través de una red de control fuera de banda. Una vez que se completa la configuración del LSP y se aprovisiona la ruta, el canal de datos está activo y se puede usar para transportar tráfico. El protocolo de administración de vínculos (LMP) se utiliza para definir y administrar los canales de datos entre un par de nodos. Opcionalmente, puede utilizar LMP para establecer y mantener canales de control LMP entre pares que ejecuten la misma versión de Junos OS.
Extensiones RSVP-TE para GMPLS: RSVP-TE ya está diseñado para señalar la configuración de paquetes LSP. Esto se ha extendido para que GMPLS pueda solicitar la configuración de rutas para varios tipos de LSP (no empaquetados) y solicitar etiquetas como longitudes de onda, intervalos de tiempo y fibras como objetos de etiqueta.
LSP bidireccionales: los datos pueden viajar en ambos sentidos entre dispositivos GMPLS a través de una sola ruta, por lo que los LSP que no son paquetes se señalan como bidireccionales.
Términos y siglas de GMPLS
MPLS generalizada (GMPLS)
Una extensión de MPLS que permite conmutar datos de varias capas a través de rutas de conmutación de etiquetas (LSP). Las conexiones LSP GMPLS son posibles entre dispositivos similares de capa 1, capa 2 y capa 3.
Adyacencia de reenvío
Una ruta de reenvío para enviar datos entre dispositivos habilitados para GMPLS.
Etiqueta GMPLS
Identificadores de capa 3, puerto de fibra, ranura de tiempo de multiplexación por división de tiempo (TDM) o longitud de onda de multiplexación por división de longitud de onda densa (DWDM) de un dispositivo habilitado para GMPLS utilizado como identificador de salto siguiente.
Tipos de LSP de GMPLS
Los cuatro tipos de LSP de GMPLS son:
Capacidad de conmutación de fibra (FSC): los LSP se conmutan entre dos dispositivos basados en fibra, como las conexiones cruzadas ópticas (OXC) que funcionan a nivel de fibras individuales.
Capacidad con conmutación lambda (LSC): los LSP se conmutan entre dos dispositivos DWDM, como los OXC que funcionan a nivel de longitudes de onda individuales.
Capacidad conmutada TDM (TDM): los LSP se conmutan entre dos dispositivos TDM, como los ADM SONET.
Capacidad de conmutación de paquetes (PSC): los LSP se conmutan entre dos dispositivos basados en paquetes, como enrutadores o conmutadores ATM.
Protocolo de administración de vínculos
Protocolo utilizado para definir una adyacencia de reenvío entre pares y para mantener y asignar recursos en los vínculos de ingeniería de tráfico.
Enlace de ingeniería de tráfico
Una conexión lógica entre dispositivos habilitados para GMPLS. Los vínculos de ingeniería de tráfico pueden tener direcciones o identificadores y están asociados con determinados recursos o interfaces. También tienen ciertos atributos (tipo de codificación, capacidad de conmutación, ancho de banda, etc.). Las direcciones lógicas pueden ser enrutables, aunque esto no es necesario porque actúan como identificadores de vínculo. Cada vínculo de ingeniería de tráfico representa una adyacencia de reenvío entre un par de dispositivos.
Operación GMPLS
La funcionalidad básica de GMPLS requiere una estrecha interacción entre RSVP y LMP. Funciona en la siguiente secuencia:
LMP notifica a RSVP de las nuevas entidades:
Enlace de ingeniería de tráfico (adyacencia de reenvío)
Recursos disponibles para el vínculo de ingeniería de tráfico
Par de control
GMPLS extrae los atributos LSP de la configuración y solicita RSVP para señalar una o más rutas específicas, que se especifican mediante las direcciones de vínculo de ingeniería de tráfico.
RSVP determina el vínculo de ingeniería de tráfico local, la adyacencia de control correspondiente y el canal de control activo, y los parámetros de transmisión (como el destino IP). Solicita que LMP asigne un recurso desde el vínculo de ingeniería de tráfico con los atributos especificados. Si LMP encuentra un recurso que coincida con los atributos, la asignación de etiquetas se realiza correctamente. RSVP envía un PathMsg salto a salto hasta que llega al enrutador de destino.
Cuando el enrutador de destino recibe el PathMsg, RSVP solicita nuevamente que LMP asigne un recurso basado en los parámetros señalados. Si la asignación de etiquetas se realiza correctamente, el enrutador devuelve un ResvMsg.
Si la señalización se realiza correctamente, se aprovisiona una ruta óptica bidireccional.
GMPLS y OSPF
Puede configurar OSPF para GMPLS. El OSPF es un protocolo de pasarela interior (IGP) que enruta paquetes dentro de un único sistema autónomo (AS). OSPF utiliza información de estado de vínculo para tomar decisiones de enrutamiento.
GMPLS y CSPF
GMPLS introduce restricciones adicionales para las rutas informáticas para los LSP de GMPLS que utilizan CSPF. Estas restricciones adicionales afectan a los siguientes atributos de vínculo:
Tipo de señal (ancho de banda LSP mínimo)
Tipo de codificación
Tipo de conmutación
Estas nuevas restricciones se rellenan en la base de datos de ingeniería de tráfico con el intercambio de un tipo, longitud y valor (TLV) de descriptor de capacidad de conmutación de interfaz a través de un IGP.
Las restricciones ignoradas que se intercambian a través del descriptor de capacidad de conmutación de interfaz incluyen:
Ancho de banda LSP máximo
Unidad máxima de transmisión (MTU)
El cálculo de la ruta CSPF es el mismo que en entornos que no son GMPLS, excepto que los vínculos también están limitados por restricciones GMPLS.
Cada vínculo puede tener varios descriptores de capacidad de conmutación de interfaz. Todos los descriptores se comprueban antes de rechazar un enlace.
Las restricciones se comprueban en el orden siguiente:
El tipo de señal configurado para el LSP GMPLS indica la cantidad de ancho de banda solicitado. Si el ancho de banda deseado es inferior al ancho de banda LSP mínimo, se rechaza el descriptor de conmutación de interfaz.
El tipo de codificación del vínculo para las interfaces de entrada y salida debe coincidir. El tipo de codificación se selecciona y almacena en el nodo de entrada después de que el vínculo satisfaga todas las restricciones y se utiliza para seleccionar el vínculo en el nodo de salida.
El tipo de conmutación de los enlaces de los conmutadores intermedios debe coincidir con el del LSP GMPLS especificado en la configuración.
Características de GMPLS
Junos OS incluye la siguiente funcionalidad GMPLS:
Un plano de control fuera de banda permite señalar la configuración de la ruta del LSP.
Las extensiones RSVP-TE admiten objetos adicionales más allá de los paquetes de capa 3, como puertos, ranuras de tiempo y longitudes de onda.
El protocolo LMP crea y mantiene una base de datos de vínculos de ingeniería de tráfico e información de pares. Solo la versión estática de este protocolo es compatible con Junos OS. Opcionalmente, puede configurar LMP para establecer y mantener canales de control LMP entre pares que ejecuten la misma versión de Junos OS.
Se requieren LSP bidireccionales entre dispositivos.
Se admiten varios tipos de etiquetas GMPLS que se definen en RFC 3471, MPLS generalizada: descripción funcional de señalización, como MPLS, generalizada, SONET/SDH, sugerida y ascendente. Las etiquetas generalizadas no contienen un campo de tipo, ya que los nodos deben saber por el contexto de su conexión qué tipo de etiqueta esperar.
Los parámetros de tráfico facilitan la codificación del ancho de banda GMPLS y el formato SONET/SDH.
Otros atributos admitidos incluyen la identificación de interfaz y la identificación de interfaz errónea, la señalización de estilo de usuario a red (UNI) y las rutas secundarias de LSP.
Configuración de rutas MPLS para GMPLS
Como parte de la configuración de GMPLS, debe establecer una ruta MPLS para cada dispositivo único conectado a través de GMPLS. Configure la dirección remota del vínculo de ingeniería de tráfico como la dirección en el nivel jerárquico [edit protocols mpls path path-name] . Se admite la ruta más corta restringida primero (CSPF), por lo que puede elegir la strict opción o loose con la dirección.
Consulte Descripción general de la configuración de LMP para obtener información acerca de cómo obtener una dirección remota de vínculo de ingeniería de tráfico.
Para configurar la ruta de acceso MPLS, incluya la path instrucción en el nivel de [edit protocols mpls] jerarquía:
[edit protocols mpls] path path-name { next-hop-address (strict | loose); }
Para obtener información acerca de cómo configurar rutas MPLS, consulte Creación de rutas con nombre.
Seguimiento del tráfico LMP
Para realizar un seguimiento del tráfico del protocolo LMP, incluya la traceoptions instrucción en el nivel de [edit protocols link-management] jerarquía:
[edit protocols link-management] traceoptions { file filename <files number> <size size> <world-readable | no-world-readable>; flag flag <flag-modifier> <disable>; }
Utilice la file instrucción para especificar el nombre del archivo que recibe el resultado de la operación de seguimiento. Todos los archivos se colocan en el directorio /var/log.
Los siguientes indicadores de seguimiento muestran las operaciones asociadas con el envío y la recepción de varios mensajes LMP:
all—Rastree todas las operaciones disponibleshello-packets—Rastree paquetes de hola en cualquier canal de control LMPinit: salida de los mensajes de inicializaciónpackets: rastrea todos los paquetes que no sean paquetes de hola en cualquier canal de control LMPparse—Funcionamiento del analizadorprocess—Funcionamiento de la configuración generalroute-socket—Operación de eventos de socket de rutarouting—Funcionamiento de los protocolos de enrutamientoserver—Operaciones de procesamiento del servidorshow—Operaciones de mantenimiento parashowcomandosstate—Transiciones de estado de traza de los canales de control LMP y enlaces de ingeniería de tráfico
Cada bandera puede llevar uno o más de los siguientes modificadores de bandera:
detail—Proporcionar información de rastreo detalladareceive—Paquetes que se recibensend—Paquetes que se transmiten
Configuración de LSP MPLS para GMPLS
Para habilitar los parámetros de conmutación GMPLS adecuados, configure los atributos de ruta de conmutación de etiquetas (LSP) adecuados para su conexión de red. El valor predeterminado de switching-type es psc-1, que también es adecuado para MPLS estándar.
Para configurar los atributos LSP, incluya la lsp-attributes instrucción en el nivel de [edit protocols mpls label-switched-path lsp-name] jerarquía:
[edit protocols mpls label-switched-path lsp-name] lsp-attributes { encoding-type type; gpid gpid; signal-bandwidth type; switching-type type; }
Si incluye la no-cspf instrucción en la configuración de la ruta de conmutación de etiquetas, también debe configurar las rutas principal y secundaria, o no se podrá confirmar la configuración.
En las secciones siguientes se describe cómo configurar cada uno de los atributos LSP para un LSP GMPLS:
- Configuración del tipo de codificación
- Configuración del GPID
- Configuración del tipo de ancho de banda de la señal
- Configuración de LSP bidireccionales GMPLS
- Permitir que los LSP GMPLS que no son de paquetes establezcan rutas a través de enrutadores que ejecutan Junos OS
Configuración del tipo de codificación
Debe especificar el tipo de codificación de la carga útil que lleva el LSP. Puede ser cualquiera de los siguientes:
ethernet—Ethernetpacket—Paquetepdh—Jerarquía digital plesiócrona (PDH)sonet-sdh—SONET/SDH
El valor predeterminado es packet.
Para configurar el tipo de codificación, incluya la encoding-type instrucción en el nivel de [edit protocols mpls label-switched-path lsp-name lsp-attributes] jerarquía:
[edit protocols mpls label-switched-path lsp-name lsp-attributes] encoding-type type;
Configuración del GPID
Debe especificar el tipo de carga útil que transporta el LSP. La carga útil es el tipo de paquete debajo de la etiqueta MPLS. La carga se especifica mediante el identificador de carga generalizada (GPID).
Puede especificar el GPID con cualquiera de los siguientes valores:
hdlc—Control de vínculo de datos de alto nivel (HDLC)ethernet—Ethernetipv4—IP versión 4 (predeterminada)pos-scrambling-crc-16—Para la interoperabilidad con equipos de otros proveedorespos-no-scrambling-crc-16—Para la interoperabilidad con equipos de otros proveedorespos-scrambling-crc-32—Para la interoperabilidad con equipos de otros proveedorespos-no-scrambling-crc-32—Para la interoperabilidad con equipos de otros proveedoresppp—Protocolo punto a punto (PPP)
Para configurar el GPID, incluya la gpid instrucción en el nivel de [edit protocols mpls label-switched-path lsp-name lsp-attributes] jerarquía:
[edit protocols mpls label-switched-path lsp-name lsp-attributes] gpid gpid;
Configuración del tipo de ancho de banda de la señal
El tipo de ancho de banda de la señal es la codificación utilizada para el cálculo de la ruta y el control de admisión. Para configurar el tipo de ancho de banda de la señal, incluya la signal-bandwidth instrucción en el nivel de [edit protocols mpls label-switched-path lsp-name lsp-attributes] jerarquía:
[edit protocols mpls label-switched-path lsp-name lsp-attributes] signal-bandwidth type;
Configuración de LSP bidireccionales GMPLS
Dado que MPLS y GMPLS utilizan la misma jerarquía de configuración para los LSP, resulta útil saber qué atributos de LSP controlan la funcionalidad de LSP. Los LSP estándar de conmutación de paquetes MPLS son unidireccionales, mientras que los LSP GMPLS no empaquetados son bidireccionales.
Si utiliza el tipo predeterminado de conmutación de paquetes de psc-1, el LSP se convierte en unidireccional. Para habilitar un LSP bidireccional GMPLS, debe seleccionar una opción de tipo que no sea de conmutación de paquetes, como lambda, fiber, o ethernet. Incluya la switching-type instrucción en el nivel jerárquico [edit protocols mpls label-switched-path lsp-name lsp-attributes] :
[edit protocols mpls label-switched-path lsp-name lsp-attributes] switching-type (lambda | fiber | ethernet);
Permitir que los LSP GMPLS que no son de paquetes establezcan rutas a través de enrutadores que ejecutan Junos OS
Estableciendo el bit A en el objeto Admin Status. puede habilitar los LSP GMPLS que no sean de paquetes para que establezcan rutas a través de enrutadores que ejecuten Junos. Cuando un enrutador de entrada envía un mensaje RSVP PATH con el bit A de estado de administrador establecido, un dispositivo externo (no un enrutador que ejecute Junos OS) puede realizar una prueba de configuración de ruta de capa 1 o ayudar a abrir una conexión cruzada óptica.
Cuando se establece, el bit A del objeto Admin Status indica el estado administrativo inactivo de un LSP GMPLS. Esta característica es utilizada específicamente por los LSP GMPLS que no son paquetes. No afecta a la configuración de la ruta de control ni al reenvío de datos para los LSP de paquetes.
Junos no distingue entre la configuración de la ruta de control y la configuración de la ruta de datos. Otros nodos a lo largo de la ruta de red utilizan la señalización RSVP PATH utilizando el bit A de una manera significativa.
Para configurar el objeto Admin Status para un LSP de GMPLS, incluya la admin-down instrucción:
admin-down;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit protocols mpls label-switched-path lsp-name][edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]
Derribando con gracia los LSP GMPLS
Puede desactivar con gracia los LSP GMPLS que no son paquetes. Un LSP que se derriba abruptamente, un proceso común en una red conmutada por paquetes, puede causar problemas de estabilidad en redes sin conmutación de paquetes. Para mantener la estabilidad de las redes sin conmutación de paquetes, puede ser necesario derribar los LSP correctamente.
Las siguientes secciones describen cómo derribar los LSP GMPLS con gracia:
- Eliminación temporal de LSP de GMPLS
- Eliminación permanente de LSP de GMPLS
- Configuración del intervalo de tiempo de espera de eliminación correcta
Eliminación temporal de LSP de GMPLS
Puede desactivar correctamente un LSP GMPLS usando el clear rsvp session gracefully comando.
Este comando desactiva correctamente una sesión RSVP para un LSP que no es de paquete en dos pasadas. En el primer paso, el objeto Admin Status se señaliza a lo largo de la ruta al extremo del LSP. Durante la segunda pasada, el LSP se desactiva. Con este comando, el LSP se desactiva temporalmente. Después del intervalo apropiado, el LSP GMPLS se vuelve a señalar y luego se restablece.
El clear rsvp session gracefully comando tiene las siguientes propiedades:
Solo funciona en los enrutadores de entrada y salida de una sesión RSVP. Si se utiliza en un enrutador de tránsito, tiene el mismo comportamiento que el
clear rsvp sessioncomando.Solo funciona para LSP que no son paquetes. Si se usa con LSP de paquetes, tiene el mismo comportamiento que el
clear rsvp sessioncomando.
Para obtener más información, consulte el Explorador de CLI.
Eliminación permanente de LSP de GMPLS
Cuando deshabilita un LSP en la configuración, el LSP se elimina permanentemente. Mediante la configuración de la disable instrucción, puede deshabilitar un LSP GMPLS de forma permanente. Si el LSP que se deshabilita es un LSP que no es de paquete, se utilizan los procedimientos de desmontaje de LSP correctos que utilizan el objeto Admin Status. Si el LSP que se deshabilita es un LSP de paquete, se utilizan los procedimientos de señalización regulares para la eliminación de LSP.
Para deshabilitar un LSP de GMPLS, incluya la disable instrucción en cualquiera de los siguientes niveles de jerarquía:
[edit protocols mpls label-switched-path lsp-name]: deshabilite el LSP.[edit protocols link-management te-link te-link-name]: deshabilita un vínculo de ingeniería de tráfico.[edit protocols link-management te-link te-link-name interface interface-name]: deshabilita una interfaz utilizada por un vínculo de ingeniería de tráfico.
Configuración del intervalo de tiempo de espera de eliminación correcta
El enrutador que inicia el procedimiento de eliminación correcta para una sesión RSVP espera el intervalo de tiempo de espera de eliminación correcta para asegurarse de que todos los enrutadores a lo largo de la ruta (especialmente los enrutadores de entrada y salida) se han preparado para que se retire el LSP.
El enrutador de entrada inicia el procedimiento de eliminación correcta enviando el objeto Admin Status en el mensaje de ruta con el D bit establecido. El enrutador de entrada espera recibir un mensaje Resv con el D bit establecido desde el enrutador de salida. Si el enrutador de entrada no recibe este mensaje dentro del tiempo especificado por el intervalo de tiempo de espera de eliminación correcta, inicia un desmontaje forzado del LSP enviando un mensaje PathTear.
Para configurar el intervalo de tiempo de espera de eliminación correcta, incluya la graceful-deletion-timeout instrucción en el nivel de [edit protocols rsvp] jerarquía. Puede configurar un tiempo entre 1 y 300 segundos. El valor predeterminado es 30 segundos.
graceful-deletion-timeout seconds;
Puede configurar esta instrucción en los siguientes niveles jerárquicos:
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
Puede usar el show rsvp version comando para determinar el valor actual configurado para el tiempo de espera de eliminación correcta.
Descripción general de la señalización GMPLS RSVP-TE VLAN LSP
- Descripción de la señalización GMPLS RSVP-TE
- Necesidad de GMPLS RSVP-TE VLAN LSP Señalización
- Funcionalidad de señalización GMPLS RSVP-TE VLAN LSP
- Jerarquía LSP con GMPLS RSVP-TE VLAN LSP
- Especificación de ruta para GMPLS RSVP-TE VLAN LSP
- Configuración GMPLS RSVP-TE VLAN LSP
- LSP de paquetes bidireccionales asociados
- Preparación antes de la interrupción para paquetes bidireccionales asociados y LSP RSVP-TE VLAN GMPLS
- Características admitidas y no compatibles
Descripción de la señalización GMPLS RSVP-TE
La señalización es el proceso de intercambiar mensajes dentro del plano de control para configurar, mantener, modificar y terminar rutas de datos (rutas de conmutación de etiquetas [LSP]) en el plano de datos. MPLS generalizada (GMPLS) es un conjunto de protocolos que extiende el plano de control existente de MPLS para administrar otras clases de interfaces y admitir otras formas de conmutación de etiquetas, como la multiplexación por división de tiempo (TDM), la fibra (puerto), Lambda, etc.
GMPLS extiende las conexiones IP/MPLS inteligentes desde la capa 2 y la capa 3 hasta los dispositivos ópticos de capa 1. A diferencia de MPLS, que es compatible principalmente con enrutadores y conmutadores, GMPLS también puede ser compatible con plataformas ópticas, incluidas SONET/SDH, conexiones cruzadas ópticas (OXC) y multiplexación por división de onda densa (DWDM).
Además de las etiquetas, que se utilizan principalmente para reenviar datos en MPLS, otras entradas físicas, como longitudes de onda, intervalos de tiempo y fibras, se pueden utilizar como objetos de etiqueta para reenviar datos en GMPLS, aprovechando así los mecanismos del plano de control existentes para señalar diferentes tipos de LSP. GMPLS utiliza RSVP-TE para poder solicitar a los otros objetos de etiqueta que señalen los diversos tipos de LSP (no paquetes). Los LSP bidireccionales y un canal de control fuera de banda y un canal de datos mediante el Protocolo de administración de vínculos (LMP) son los otros mecanismos que utiliza GMPLS para establecer LSP.
Necesidad de GMPLS RSVP-TE VLAN LSP Señalización
Los servicios punto a punto tradicionales de capa 2 utilizan circuitos de capa 2 y tecnologías VPN de capa 2 basadas en LDP y BGP. En la implementación tradicional, los dispositivos perimetrales del cliente (CE) no participan en la señalización del servicio de capa 2. Los dispositivos perimetrales del proveedor (PE) administran y aprovisionan el servicio de capa 2 para proporcionar conectividad de extremo a extremo entre los dispositivos CE.
Uno de los mayores desafíos de hacer que los dispositivos PE aprovisionen los servicios de capa 2 para cada circuito de capa 2 entre un par de dispositivos CE es la carga de administración de red en la red del proveedor.
Figura 1 ilustra cómo los enrutadores CE configuran y utilizan el servicio de capa 2 en una tecnología VPN de capa 2 basada en LDP/BGP. Dos enrutadores CE1 y CE2 CE están conectados a una red MPLS de proveedor a través de los enrutadores PE PE1 y PE2 respectivamente. Los enrutadores CE están conectados a los enrutadores PE mediante vínculos Ethernet. Los enrutadores CE1 y CE2 están configurados con interfaces lógicas de capa 3 VLAN1 y VLAN2, por lo que parecen estar conectados directamente. Los enrutadores PE1 y PE2 están configurados con un circuito de capa 2 (pseudocable) para transportar el tráfico VLAN de capa 2 entre los enrutadores CE. Los enrutadores PE utilizan paquetes MPLS LSP dentro de la red MPLS del proveedor para transportar el tráfico VLAN de capa 2.
Con la introducción de la señalización VLAN LSP basada en GMPLS, se minimiza la necesidad de que la red PE (también llamada capa de servidor) aprovisione cada conexión individual de capa 2 entre los dispositivos CE (también denominados cliente). El enrutador cliente solicita al enrutador de capa de servidor al que está conectado directamente que configure el servicio de capa 2 para conectarse con un enrutador cliente remoto a través de la señalización GMPLS.
Los dispositivos de capa de servidor extienden la señalización a través de la red de capa de servidor para conectarse con los enrutadores de cliente remoto. En el proceso, el dispositivo de capa de servidor configura el plano de datos para el servicio de capa 2 en el borde servidor-cliente y configura el plano de datos para transportar el tráfico de capa 2 dentro de la red de capa de servidor. Con la configuración del servicio de capa 2, los enrutadores cliente pueden ejecutar IP/MPLS directamente sobre el servicio de capa 2 y tener adyacencia IP/MPLS entre sí.
Además de reducir la actividad de aprovisionamiento necesaria en los dispositivos de capa de servidor, la señalización GMPLS también proporciona a los enrutadores cliente la flexibilidad de abrir los circuitos de capa 2 bajo demanda sin depender de la administración de la capa de servidor para el aprovisionamiento del servicio de capa 2.
Con la misma topología que en la figura 1, Figura 2 se ilustra cómo los enrutadores cliente configuran y utilizan el servicio de capa 2 en la tecnología VPN de capa 2 basada en RSVP-TE de GMPL.
En Figura 2, en lugar de configurar un pseudocable para transportar el tráfico VLAN de capa 2 entre los enrutadores cliente, los enrutadores PE1 y PE2 se configuran con un canal de comunicación basado en IP y otras configuraciones específicas de GMPLS (identificación de vínculos Ethernet como vínculos TE) para permitir el intercambio de mensajes de señalización GMPLS RSVP-TE con los enrutadores cliente. Los enrutadores CE1 y CE2 también están configurados con un canal de comunicación basado en IP y la configuración GMPLS relevante para intercambiar los mensajes de señalización GMPLS RSVP-TE con los enrutadores de capa de servidor. Los enrutadores CE1 y CE2 establecen una adyacencia IP/MPLS sobre este servicio de capa 2.
Funcionalidad de señalización GMPLS RSVP-TE VLAN LSP
Figura 2En función de , el enrutador cliente establece el servicio de capa 2 en la red de capa de servidor de la siguiente manera:
El enrutador CE1 inicia la señalización RSVP-TE de GMPLS con el enrutador PE1. En este mensaje de señalización, el enrutador CE1 indica la VLAN en el vínculo Ethernet para el que necesita el servicio de capa 2 y el enrutador CE remoto, enrutador CE2, con el que debe conectarse la VLAN.
El enrutador CE1 también indica el enrutador de PE remoto, el enrutador PE2, al que está conectado el enrutador CE2, y el vínculo Ethernet exacto que conecta el enrutador CE2 con el enrutador PE2 en el que se requiere el servicio de capa 2 en el mensaje de señalización.
El enrutador PE1 utiliza la información del enrutador CE1 en el mensaje de señalización y determina el enrutador de PE remoto, el enrutador PE2, al que está conectado el enrutador CE2. Luego, el enrutador PE1 establece un paquete MPLS LSP (bidireccional asociado) a través de la red MPLS de capa de servidor para transportar el tráfico VLAN y, a continuación, pasa el mensaje de señalización RSVP-TE de GMPLS al enrutador PE2 mediante el mecanismo de jerarquía de LSP.
El enrutador PE2 propaga el mensaje de señalización RSVP-TE de GMPLS al enrutador CE2 con la VLAN que se utilizará en el vínculo Ethernet PE2-CE2.
El enrutador CE2 responde con un acuse de recibo al mensaje de señalización RSVP-TE de GMPLS al enrutador PE2. A continuación, el enrutador PE2 lo propaga al enrutador PE1, que a su vez lo propaga al enrutador CE1.
Como parte de esta propagación de mensajes, los enrutadores PE1 y PE2 configuran el plano de reenvío para permitir el flujo bidireccional del tráfico de capa 2 de VLAN entre los enrutadores CE1 y CE2.
Jerarquía LSP con GMPLS RSVP-TE VLAN LSP
El servicio de capa 2 en la señalización LSP RSVP-TE VLAN GMPLS se activa mediante un mecanismo de jerarquía en el que se crean dos LSP RSVP diferentes para el servicio de capa 2:
Un LSP VLAN de extremo a extremo que tiene información de estado en los enrutadores de capa de cliente y servidor.
Un LSP de transporte de paquetes bidireccional asociado que está presente en los enrutadores de capa de servidor (PE y P) de la red de capa de servidor.
La jerarquía de LSP evita compartir información sobre las características de LSP específicas de la tecnología con los nodos centrales de la red de capa de servidor. Esta solución separa limpiamente el estado de LSP de VLAN y el estado de LSP de transporte, y garantiza que el estado de LSP de VLAN solo esté presente en los nodos (PE, CE) donde se necesita.
Especificación de ruta para GMPLS RSVP-TE VLAN LSP
La ruta de acceso para el lsp RSVP-TE de GMPLS se configura como un objeto de ruta explícito (ERO) en el enrutador del cliente iniciador. Como este LSP atraviesa diferentes dominios de red (iniciando, terminando en la red cliente y atravesando la red de capa de servidor), la configuración de LSP cae bajo la categoría de una configuración de LSP entre dominios. En un escenario entre dominios, un dominio de red generalmente no tiene visibilidad completa de la topología del otro dominio de red. Por lo tanto, el ERO que se configura en el enrutador del cliente iniciador no tiene información de salto completo para la parte de la capa de servidor. Esta característica requiere que el ERO configurado en el enrutador CE tenga tres saltos, siendo el primer salto un salto estricto que identifica el vínculo Ethernet CE1-PE1, el segundo salto es un salto suelto que identifica el enrutador PE de salida (PE2) y el tercer salto es un salto estricto que identifica el vínculo Ethernet CE2-PE2.
Configuración GMPLS RSVP-TE VLAN LSP
La configuración necesaria para establecer un LSP de VLAN GMPLS en los enrutadores cliente y servidor utiliza el modelo de configuración GMPLS existente con algunas extensiones. El modelo de configuración GMPLS de Junos OS para LSP que no son de paquetes tiene como objetivo poner las interfaces físicas en funcionamiento a través de la señalización GMPLS RSVP-TE, mientras que la señalización de un lsp de VLAN RSVP-TE de GMPLS tiene como objetivo colocar VLAN individuales sobre una interfaz física. La ethernet-vlan instrucción de configuración bajo la [edit protocols link-management te-link] jerarquía permite esto.
El enrutador cliente tiene interfaces físicas conectadas a una red de servidores, y la red de servidores proporciona una conexión punto a punto entre dos enrutadores cliente a través de las interfaces físicas adjuntas. La interfaz física es puesta en un estado operativo por GMPLS RSVP-TE de la siguiente manera:
El enrutador cliente mantiene una adyacencia de enrutamiento o señalización con el nodo de red del servidor al que está conectada la interfaz física, normalmente a través de un canal de control diferente de la interfaz física, ya que la propia interfaz física se activa y se ejecuta solo después de la señalización.
El enrutador cliente y el nodo de red del servidor identifican las interfaces físicas que los conectan mediante el mecanismo TE-link.
El enrutador cliente y el nodo de red del servidor utilizan el identificador TE-link (dirección IP) como salto RSVP de GMPLS y el identificador de interfaz física como valores de etiqueta GMPLS en los mensajes de señalización RSVP-TE de GMPLS para llevar la interfaz física a un estado operativo.
En la configuración GMPLS existente, los nodos de red del servidor y del cliente utilizan la instrucción configuration protocols link-management peer peer-name para especificar el nodo del mismo nivel adyacente. Dado que un enrutador cliente puede tener una o más interfaces físicas conectadas al nodo de red del servidor, estas interfaces físicas se agrupan e identifican mediante una dirección IP mediante la instrucción de protocols link-management te-link link-name configuración. Al vínculo TE se le asigna una dirección IP local, una dirección IP remota y una lista de interfaces físicas. A continuación, el vínculo TE se asocia a la instrucción de protocols link-management peer peer-name te-link te-link-list configuración.
El canal de control fuera de banda necesario para intercambiar mensajes de señalización se especifica mediante la instrucción configuration protocols link-management peer peer-name control-channel interface-name . La existencia del nodo de red del servidor o cliente se hace visible para los protocolos RSVP e IGP (OSPF) mediante la instrucción de peer-interface interface-name configuración en los [edit protocols rsvp] niveles de jerarquía y [edit protocols ospf] .
En la configuración GMPLS existente, la etiqueta (etiqueta ascendente y etiqueta resv) que se incluye en el mensaje de señalización es un identificador entero que identifica la interfaz física que se debe abrir. Como la etiqueta se utiliza para identificar la interfaz física, la configuración GMPLS existente permite agrupar varias interfaces bajo un único vínculo TE. En la configuración GMPLS existente, hay suficiente información en el mensaje de señalización RSVP-TE de GMPLS, como la dirección del vínculo TE y el valor de la etiqueta, para identificar la interfaz física que se debe abrir. Por el contrario, para la configuración GMPLS RSVP-TE VLAN LSP, el valor del ID de VLAN se utiliza como etiqueta en el mensaje de señalización.
En la configuración de LSP VLAN RGPLS RSVP-TE DE GMPLS, si se permite configurar varias interfaces en un único vínculo TE, el uso del ID de VLAN como valor de etiqueta en el mensaje de señalización puede causar ambigüedad en cuanto a la interfaz física en la que se debe aprovisionar la VLAN. Por lo tanto, el vínculo TE se configura con la ethernet-vlan instrucción configuration si el número de interfaces físicas que se pueden configurar en el vínculo TE está restringido a una sola.
En la configuración GMPLS existente, el ancho de banda para un LSP que no es de paquete es una cantidad discreta que corresponde al ancho de banda de la interfaz física que se debe abrir. Por lo tanto, la configuración LSP de GMPLS no permite especificar ningún ancho de banda, pero permite que el ancho de banda se especifique solo a través de la instrucción de signal-bandwidth configuración en el nivel de [protocols mpls label-switched-path lsp-name lsp-attributes] jerarquía. En la configuración de LSP de VLAN de GMPLS, el ancho de banda se especifica de manera similar a la de un LSP de paquete. En la configuración de LSP VLAN GMPLS, la bandwidth opción es compatible y signal-bandwidth no admitida.
LSP de paquetes bidireccionales asociados
El lsp de VLAN RSVP-TE de GMPLS se lleva a cabo en un LSP de transporte bidireccional asociado dentro de la red de capa de servidor, que es un LSP aprovisionado de un solo lado. La señalización LSP de transporte se inicia como un LSP unidireccional desde el enrutador de origen al enrutador de destino en la dirección de avance, y el enrutador de destino a su vez inicia la señalización del LSP unidireccional en la dirección inversa de regreso al enrutador de origen.
Preparación antes de la interrupción para paquetes bidireccionales asociados y LSP RSVP-TE VLAN GMPLS
La compatibilidad de hacer antes de la interrupción para un LSP de transporte bidireccional asociado sigue un modelo similar, donde el enrutador de destino para la dirección directa del LSP bidireccional no realiza ninguna operación de hacer antes de la interrupción en la dirección inversa del LSP bidireccional. Es el enrutador de origen (iniciador del LSP bidireccional asociado) el que inicia la instancia más reciente de hacer antes de interrumpir del LSP bidireccional asociado, y el enrutador de destino a su vez inicia la instancia más reciente de hacer antes de romper en la otra dirección.
Por ejemplo, en Figura 2, el LSP de transporte unidireccional se inicia del enrutador PE1 al enrutador PE2 en la dirección de reenvío y, a su vez, el enrutador PE2 inicia el LSP de transporte al enrutador PE1 en la dirección inversa. Cuando se produce una instancia de preparación previa, solo el enrutador PE1 como enrutador cliente iniciador puede establecer una nueva instancia del LSP bidireccional asociado. A su vez, el enrutador PE2 inicia la instancia más reciente de hacer antes de romper en la dirección inversa.
La compatibilidad de hacer antes de interrumpir para el LSP de transporte bidireccional asociado sólo se usa en escenarios en los que el LSP de transporte entra en un estado de protección local debido a un error de vínculo o nodo en la ruta del LSP. El lsp de VLAN RSVP-TE de GMPLS utiliza el mecanismo de hacer antes de la interrupción para ajustar los cambios de ancho de banda sin problemas.
La reoptimización periódica no está habilitada para los LSP de transporte bidireccional asociados.
La instancia más reciente de hacer antes de romper el lsp de VLAN de GMPLS se admite con las siguientes restricciones:
Debe originarse en el mismo enrutador cliente que la instancia anterior y estar destinado al mismo enrutador cliente que la instancia anterior.
Debe utilizar los mismos vínculos servidor-cliente en los extremos servidor-cliente que en la instancia anterior.
Debe utilizar la misma etiqueta de VLAN en los vínculos servidor-cliente que la instancia anterior.
El LSP de VLAN de GMPLS debe configurarse como
adaptivecuando se inicia el cambio de ancho de banda desde la CLI o, de lo contrario, la instancia actual del LSP de VLAN se desactiva y se establece una nueva instancia de LSP de VLAN.
La operación de hacer antes de la interrupción para el LSP VLAN GMPLS en el enrutador perimetral de capa de servidor se rechaza si no se cumplen estas restricciones.
En los enrutadores perimetrales de capa de servidor, cuando se ve una instancia de configuración previa del lsp de VLAN de GMPLS, se crea un LSP de transporte bidireccional asociado completamente nuevo e independiente para admitir esta instancia de hacer antes de interrumpir. El LSP bidireccional asociado existente (compatible con la instancia anterior) no se activa para iniciar una instancia de hacer antes de interrumpir en el nivel de LSP de transporte. Una implicación de esta elección (de iniciar un nuevo LSP de transporte) es que en la capa de servidor el uso compartido de recursos/ancho de banda no ocurre cuando se realiza una operación de hacer antes de la interrupción para el lsp de VLAN GMPLS.
Características admitidas y no compatibles
Junos OS admite las siguientes funciones con GMPLS RSVP-TE VLAN LSP:
Solicitud de ancho de banda específico y protección local para el LSP de VLAN en el enrutador cliente al enrutador de capa de servidor.
Compatibilidad con enrutamiento activo sin interrupciones (NSR) para el LSP VLAN GMPLS en los enrutadores cliente, enrutadores perimetrales de capa de servidor y LSP de transporte bidireccional asociado en los enrutadores perimetrales de capa de servidor.
Soporte multichasis.
Junos OS admite not la siguiente funcionalidad GMPLS RSVP-TE VLAN LSP:
Soporte de reinicio correcto para LSP de paquetes bidireccionales asociados y LSP VLAN GMPLS.
Cálculo de ruta de extremo a extremo para LSP VLAN GMPLS mediante el algoritmo CSPF en el enrutador cliente.
Descubrimiento de enrutadores del próximo salto no basados en enrutamiento CSPF por parte de los diferentes enrutadores perimetrales de capa de servidor del cliente.
Aprovisionamiento automático de las interfaces VLAN de capa 3 del cliente tras la configuración correcta del LSP de VLAN en los enrutadores cliente.
MPLS OAM (LSP-ping, BFD).
Aplicaciones MPLS de paquetes, como el siguiente salto en ruta estática y en accesos directos de IGP.
Mecanismo de conexión cruzada local, donde un enrutador cliente se conecta a un enrutador cliente remoto que está conectado al mismo enrutador servidor.
Marco de servicios de Junos OS.
Compatibilidad con IPv6.
Sistemas lógicos.
Interfaces Ethernet/SONET/IRB agregadas en el vínculo servidor-cliente.
Ejemplo: Configuración de la señalización GMPLS RSVP-TE VLAN LSP
En este ejemplo se muestra cómo configurar la señalización LSP RSVP-TE VLAN GMPLS en los enrutadores cliente para permitir que un enrutador cliente se conecte con un enrutador cliente remoto a través de una red de capa de servidor mediante la jerarquía LSP. Esto permite a los enrutadores cliente establecer, mantener y aprovisionar los servicios de capa 2, sin depender de la administración de la capa de servidor, lo que reduce la carga sobre los gastos operativos de la red del proveedor.
Requisitos
En este ejemplo, se utilizan los siguientes componentes de hardware y software:
-
Seis enrutadores que pueden ser una combinación de enrutadores de borde multiservicio serie M, plataformas de enrutamiento universal 5G serie MX, enrutadores de núcleo serie T y enrutadores de transporte de paquetes serie PTX
-
Junos OS versión 14.2 o posterior ejecutándose en los enrutadores cliente y en los enrutadores perimetrales de capa de servidor
Antes de empezar:
-
Configure las interfaces del dispositivo.
-
Configure las VLAN asociadas a la interfaz.
-
Configure los siguientes protocolos de enrutamiento:
-
Confirmación de asistencia (RSVP)
-
MPLS
-
LMP
-
Descripción general
A partir de Junos OS versión 14.2, los servicios de capa 2 entre dos enrutadores cliente en una red de capa de servidor externa o de terceros son configurados por los enrutadores cliente bajo demanda a través de la señalización RSVP-TE de GMPLS. Esta característica proporciona a los enrutadores cliente la flexibilidad para establecer, mantener y aprovisionar los servicios de capa 2, sin depender de la administración de la capa de servidor, lo que reduce la carga sobre los gastos operativos de la red del proveedor. En la tecnología VPN tradicional de capa 2 basada en LDP y BGP, la red del proveedor manejaba la actividad de aprovisionamiento para cada circuito de capa 2 establecido entre dos enrutadores cliente.
Figura 3 ilustra la configuración y señalización del lsp de VLAN GMPLS entre dos enrutadores cliente, CE1 y CE2, en una red de capa de servidor con dos enrutadores perimetrales de capa de servidor, PE1 y PE2, y un enrutador central de capa de servidor, P.
La señalización de GMPLS VLAN LSP se ejecuta de la siguiente manera:
-
Initiating GMPLS VLAN LSP at CE1El enrutador CE1 inicia la configuración de LSP de VLAN de GMPLS enviando el mensaje de ruta RSVP-TE de GMPLS al enrutador PE1. La señalización entre CE1 y PE1 se realiza a través de un canal de control fuera de banda, que es una VLAN de control independiente configurada en el vínculo Ethernet que conecta los dos enrutadores.
El mensaje de ruta RSVP-TE de GMPLS iniciado por el enrutador CE1 se utiliza para realizar lo siguiente:
-
Identifique el vínculo Ethernet en el que está activa la VLAN.
-
Abstraiga el vínculo Ethernet como un vínculo TE y asigne una dirección IP para identificar el vínculo Ethernet.
-
Asigne un ID de VLAN del conjunto de VLAN libres administradas por el enrutador CE1 para cada enlace Ethernet que conecte el enrutador PE1 al vínculo Ethernet identificado.
Este ID de VLAN también se puede utilizar para el lsp de VLAN de GMPLS en el vínculo Ethernet CE2-PE2.
-
Identifique la VLAN para la que se requiere configurar el servicio de capa 2 utilizando el ID de VLAN asignado como objeto de etiqueta ascendente y el valor de etiqueta de dirección ascendente.
-
Incluya un objeto ERO que ayude al enrutador PE1 a establecer el LSP de VLAN a través de la red de capa de servidor hasta el enrutador cliente remoto, CE2. El objeto ERO en el mensaje de ruta de acceso incluye tres saltos:
-
Primer salto: salto estricto que identifica el vínculo Ethernet cliente-servidor iniciador, PE1-CE1.
-
Segundo salto: salto suelto que identifica el enrutador de capa de servidor remoto, PE2.
-
Tercer salto: salto estricto que identifica el vínculo Ethernet clinet-servidor remoto, PE2-CE2.
-
-
Incluya el ancho de banda requerido para el lsp de VLAN GMPS.
-
Incluya cualquier protección local necesaria dentro de la red de capa de servidor para el LSP de VLAN.
-
-
Initiating Associated Bidirectional Transport LSP at PE1Después de que el enrutador PE1 recibe el mensaje de ruta del enrutador CE1, el mensaje se valida para comprobar la disponibilidad del vínculo Ethernet y del ID de VLAN. En la red de capa de servidor, los servicios de capa 2 entre los enrutadores de capa de servidor, PE1 y PE2, se proporcionan en el plano de datos de manera similar a los circuitos de capa 2. El enrutador PE1 muestra un LSP de transporte al enrutador PE2 y, a continuación, extiende el LSP de VLAN de GMPLS como un LSP jerárquico que se ejecuta sobre el LSP de transporte PE1-PE2. El LSP de transporte PE1-PE2 es un LSP de paquete y es de naturaleza bidireccional. Esto se debe a que el lsp de VLAN GMPLS es bidireccional y cada enrutador de capa de servidor debe poder hacer lo siguiente:
-
Reciba tráfico del vínculo Ethernet servidor-cliente (por ejemplo, el vínculo PE1-CE1) y envíelo al enrutador remoto de capa de servidor, PE2.
-
Reciba tráfico del enrutador remoto PE2 y envíelo por el vínculo Ethernet PE1-CE1.
Para cada lsp de VLAN GMPLS, se configura un LSP de transporte de paquetes dentro de la red de capa de servidor. El LSP de transporte se utiliza exclusivamente para transportar tráfico del LSP VLAN GMPLS para el que fue creado. El LSP de transporte se crea dinámicamente en el momento de recibir el lsp de VLAN GMPLS; por lo tanto, no se requiere ninguna configuración para desencadenar su creación. El LSP de transporte establecido para el LSP de VLAN hereda el ancho de banda y los atributos de protección local del LSP de VLAN.
El enrutador PE1 señala el LSP de transporte PE1-PE2 al enrutador PE2. El enrutador PE1 determina el destino del LSP de transporte a partir del salto suelto especificado en el objeto ERO del mensaje de ruta RSVP-TE de GMPLS del enrutador CE1 y, a continuación, señala el LSP de VLAN. Sin embargo, si el LSP de transporte PE1-PE2 no se establece, el enrutador PE1 devuelve un mensaje de error de ruta al enrutador CE1 y el LSP de VLAN de GMPLS no se establece también.
-
-
Setting Up the Associated Bidirectional Transport LSP Between the Server-Layer RoutersEl LSP bidireccional asociado entre los enrutadores PE1 y PE2 consta de dos LSP de paquetes unidireccionales:
-
PE1 a PE2
-
PE2 a PE1
El enrutador PE1 inicia la señalización de un LSP de paquete unidireccional al enrutador PE2. Este LSP de paquete unidireccional constituye la dirección de avance (PE1 a PE2) del LSP bidireccional asociado, y el mensaje de ruta lleva el objeto de asociación extendida que indica que se trata de un modelo de aprovisionamiento de una sola cara. Al recibir el mensaje de ruta para el LSP, el enrutador PE2 responde con un mensaje Resv y activa la señalización de un LSP de paquete unidireccional al enrutador PE1 con la misma ruta que (PE1 a PE2) en la dirección inversa. Este LSP de paquete unidireccional utiliza la dirección PE2 a PE1 del LSP bidireccional asociado, y este mensaje de ruta lleva el mismo objeto de asociación extendida que se ve en el mensaje de ruta de PE1 a PE2.
Cuando el enrutador PE1 recibe el mensaje Resv para el LSP unidireccional de PE1 a PE2 y el mensaje de ruta para el LSP unidireccional de PE2 a PE1, PE1 enlaza los LSP unidireccionales PE1 a PE2 y PE2 a PE1 haciendo coincidir los objetos de asociación extendida que se llevan en los mensajes de ruta respectivos. Para el mensaje de ruta para el LSP unidireccional de PE2 a PE1, el enrutador PE1 responde con el mensaje Resv. Al recibir el mensaje Resv para el LSP PE1 a PE2 y el mensaje de ruta para el LSP PE2 a PE1, el enrutador PE1 ha establecido el LSP de transporte de paquetes bidireccional asociado.
-
-
Setting Up the GMPLS VLAN LSP at Router PE1Después de establecer correctamente el LSP de transporte, el enrutador PE1 activa la señalización del lsp de VLAN GMPLS. El enrutador PE1 envía el mensaje de ruta RSVP-TE de GMPLS correspondiente al LSP de VLAN directamente al enrutador PE2, que es de naturaleza bidireccional e incluye el objeto de etiqueta ascendente.
El enrutador PE2 no es consciente de la asociación entre el LSP de transporte y el LSP de VLAN. Esta asociación se indica al enrutador PE2 por el enrutador PE1.
-
Setting Up the GMPLS VLAN LSP at Router PE2Al recibir el mensaje de ruta LSP de VLAN del enrutador PE1, el enrutador PE2 verifica la disponibilidad del LSP de transporte. Si el LSP de transporte no está disponible o la configuración del LSP está en curso, el procesamiento de LSP de VLAN se pone en espera. Cuando el LSP de transporte está disponible, el enrutador PE2 procesa el mensaje de ruta del LSP de VLAN. El objeto ERO en este mensaje de ruta indica que el siguiente salto es un salto estricto que identifica el vínculo Ethernet PE2 a CE2. El objeto ERO puede indicar el ID de VLAN que se utilizará en el vínculo Ethernet PE2 a CE2 en el vínculo Ethernet PE2.
El enrutador PE2 asigna correctamente el ID de VLAN que se enviará como etiqueta ascendente en el mensaje de ruta LSP de VLAN al enrutador CE2 y lo envía a través de un canal de control fuera de banda.
-
Processing the GMPLS VLAN LSP at Router CE2Al recibir el LSP RSVP-TE GMPLS del enrutador PE2, el enrutador CE2 valida la disponibilidad del ID de VLAN para su asignación en el vínculo PE2 a CE2. Luego, el enrutador CE2 asigna el ID de VLAN para este LSP de VLAN y devuelve un mensaje Resv al enrutador PE2 con el ID de VLAN como objeto label en el mensaje de Resp.
-
Processing the GMPLS VLAN LSP at Router PE2Al recibir el mensaje Resv del enrutador CE2, el enrutador PE2 valida que el objeto label del mensaje Resv tenga el mismo ID de VLAN que en el mensaje de ruta. A continuación, el enrutador PE2 asigna una etiqueta MPLS de 20 bits, que se incluye en el mensaje Resv enviado al enrutador PE1.
A continuación, el enrutador PE2 programa el plano de reenvío con las entradas para proporcionar la funcionalidad del servicio de capa 2.
Nota:Para todos los ID de VLAN que se pueden asignar como etiquetas en los vínculos Ethernet PE1 a CE1 y PE2-CE2, debe configurar manualmente las interfaces lógicas con fines de conexión cruzada de circuitos (CCC) en los enrutadores perimetrales de capa de servidor y no para otras familias, como IPv4, IPv6 o MPLS.
-
Processing the GMPLS VLAN LSP at Router PE1Al recibir el mensaje Resv para el LSP de VLAN del enrutador PE2, el enrutador PE1 envía un mensaje Resv al enrutador CE1 con el mismo ID de VLAN que recibió como etiqueta ascendente del enrutador CE1. El enrutador PE1 programa el plano de reenvío con las entradas para proporcionar la funcionalidad del servicio de capa 2 como enrutador PE2.
-
Processing the GMPLS VLAN LSP at Router CE1Al recibir el mensaje Resv del enrutador PE1, el enrutador CE1 valida que el ID de VLAN recibido en el mensaje de Resv coincida con el ID de VLAN en la etiqueta ascendente del mensaje de ruta que envió. Esto completa la configuración del LSP VLAN GMPLS del enrutador CE1 al enrutador CE2.
Nota:-
La configuración de LSP VLAN GMPLS no da como resultado la adición de ninguna entrada de plano de reenvío en los enrutadores cliente, CE1 y CE2. Solo los enrutadores de capa de servidor, PE1 y PE2, agregan las entradas del plano de reenvío para el lsp de VLAN GMPLS.
-
No hay intercambio de información de enrutamiento entre el cliente y los enrutadores de capa de servidor. Los enrutadores de capa de cliente y servidor no intercambian su información de topología de red entre sí.
-
-
Accounting for Bandwidth of the GMPLS VLAN LSPAl configurar correctamente el lsp de VLAN GMPLS, tanto el enrutador de capa de cliente como el de capa de servidor reducen la cantidad de ancho de banda disponible en los vínculos Ethernet servidor-cliente en la cantidad de ancho de banda asignada para el lsp de VLAN GMPLS. Esta información de contabilidad de ancho de banda se utiliza con fines de control de admisión cuando se muestran LSP VLAN GMPLS adicionales en los vínculos Ethernet servidor-cliente.
-
Using GMPLS VLAN LSP by the Client RoutersDespués de configurar correctamente el lsp de VLAN GMPLS, los enrutadores cliente (CE1 y CE2) deben configurarse manualmente con la interfaz lógica VLAN sobre los vínculos Ethernet servidor-cliente con el ID de VLAN señalado. Esta interfaz lógica debe configurarse con la dirección IP y debe incluirse en el protocolo IGP. Como resultado de esta configuración, los Routers CE1 y CE2 establecen adyacencia IGP e intercambian tráfico de datos a través del servicio de Capa 2 establecido a través de la señalización GMPLS.
Figura 4 Ilustra el flujo de tráfico de datos del LSP de VLAN GMPLS del enrutador CE1 al enrutador CE2 una vez completada la configuración del LSP y establecida la adyacencia IGP/MPLS CE1 a CE2 necesaria. El LSP de transporte de capa de servidor se origina en el enrutador PE1, atraviesa un único enrutador central de capa de servidor, el enrutador P, y llega al enrutador PE2. El LSP de transporte de la capa de servidor se muestra como un LSP pop de penúltimo salto, donde el enrutador P muestra la etiqueta de LSP de transporte y solo la etiqueta de servicio está presente en el vínculo P-to-PE2.
Figura 4: Flujo de tráfico de datos de GMPLS VLAN LSP
Topología
En Figura 5, la señalización LSP RSVP-TE VLAN GMPLS se utiliza para establecer los servicios de capa 2 entre los enrutadores cliente, el enrutador CE1 y el enrutador CE2. Los enrutadores de servidor, Enrutador PE1 y Enrutador PE2, tienen un túnel GRE establecido con cada uno de los enrutadores cliente conectados directamente. Los enrutadores P1 y P2 también son enrutadores de servidor en la red de capa de servidor.
Configuración
- Configuración rápida de CLI
- Configuración del enrutador cliente
- Configuración del enrutador del servidor
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía [edit] y, luego, ingrese commit desde el modo de configuración.
CE1
set interfaces ge-0/0/0 vlan-tagging set interfaces ge-0/0/0 unit 1 vlan-id 1 set interfaces ge-0/0/0 unit 1 family inet address 10.1.1.1/30 set interfaces ge-0/0/0 unit 1 family mpls set interfaces ge-0/0/0 unit 10 vlan-id 10 set interfaces ge-0/0/0 unit 10 family inet address 10.10.10.1/24 set interfaces ge-0/0/0 unit 10 family mpls set interfaces gre unit 0 tunnel source 10.1.1.1 set interfaces gre unit 0 tunnel destination 10.1.1.2 set interfaces gre unit 0 family inet address 10.35.100.25/30 set interfaces lo0 unit 0 family inet address 10.255.10.1/32 set routing-options router-id 10.255.10.1 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols rsvp peer-interface PE1 set protocols mpls no-cspf set protocols mpls label-switched-path CE1-to-CE2 from 10.255.10.1 set protocols mpls label-switched-path CE1-to-CE2 to 10.255.10.6 set protocols mpls label-switched-path CE1-to-CE2 lsp-attributes switching-type ethernet-vlan set protocols mpls label-switched-path CE1-to-CE2 lsp-attributes upstream-label vlan-id 10 set protocols mpls label-switched-path CE1-to-CE2 bandwidth 100m set protocols mpls label-switched-path CE1-to-CE2 primary path1 set protocols mpls path path1 10.35.1.2 strict set protocols mpls path path1 10.255.10.5 loose set protocols mpls path path1 10.36.1.1 strict set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols link-management te-link link10 local-address 10.35.1.1 set protocols link-management te-link link10 remote-address 10.35.1.2 set protocols link-management te-link link10 ethernet-vlan set protocols link-management te-link link10 interface ge-0/0/0 set protocols link-management peer PE1 address 10.255.10.2 set protocols link-management peer PE1 control-channel gre.0 set protocols link-management peer PE1 te-link link10
PE1
set interfaces ge-0/0/0 vlan-tagging set interfaces ge-0/0/0 encapsulation flexible-ethernet-services set interfaces ge-0/0/0 unit 1 vlan-id 1 set interfaces ge-0/0/0 unit 1 family inet address 10.1.1.2/30 set interfaces ge-0/0/0 unit 1 family mpls set interfaces ge-0/0/0 unit 10 encapsulation vlan-ccc set interfaces ge-0/0/0 unit 10 vlan-id 10 set interfaces ge-0/0/1 unit 0 family inet address 10.70.70.1/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 10.20.20.1/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces gre unit 0 tunnel source 10.1.1.2 set interfaces gre unit 0 tunnel destination 10.1.1.1 set interfaces gre unit 0 family inet address 10.35.100.26/30 set interfaces lo0 unit 0 family inet address 10.255.10.2/32 set routing-options router-id 10.255.10.2 set protocols rsvp associated-bidirectional-lsp single-sided-provisioning set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols rsvp peer-interface CE1 dynamic-bidirectional-transport set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols link-management te-link link1 local-address 10.35.1.2 set protocols link-management te-link link1 remote-address 10.35.1.1 set protocols link-management te-link link1 ethernet-vlan vlan-id-range 1-1000 set protocols link-management te-link link1 interface ge-0/0/0 set protocols link-management peer CE1 address 10.255.10.1 set protocols link-management peer CE1 control-channel gre.0 set protocols link-management peer CE1 te-link link1
P1
set interfaces ge-0/0/0 unit 0 family inet address 10.90.90.1/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.70.70.2/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 10.80.80.2/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.10.3/32 set routing-options router-id 10.255.10.3 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable
P2
set interfaces ge-0/0/0 unit 0 family inet address 10.90.90.2/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.30.30.1/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 10.20.20.2/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.10.4/32 set routing-options router-id 10.255.10.4 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable
PE2
set interfaces ge-0/0/0 vlan-tagging set interfaces ge-0/0/0 encapsulation flexible-ethernet-services set interfaces ge-0/0/0 unit 0 vlan-id 1 set interfaces ge-0/0/0 unit 0 family inet address 10.2.2.2/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/0 unit 10 encapsulation vlan-ccc set interfaces ge-0/0/0 unit 10 vlan-id 10 set interfaces ge-0/0/1 unit 0 family inet address 10.30.30.2/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 10.80.80.1/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces gre unit 0 tunnel source 10.2.2.2 set interfaces gre unit 0 tunnel destination 10.2.2.1 set interfaces gre unit 0 family inet address 10.35.101.26/30 set interfaces lo0 unit 0 family inet address 10.255.10.5/32 set routing-options router-id 10.255.10.5 set protocols rsvp associated-bidirectional-lsp single-sided-provisioning set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols rsvp peer-interface CE2 dynamic-bidirectional-transport set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols link-management te-link link1 local-address 10.36.1.2 set protocols link-management te-link link1 remote-address 10.36.1.1 set protocols link-management te-link link1 ethernet-vlan vlan-id-range 1-1000 set protocols link-management te-link link1 interface ge-0/0/0 set protocols link-management peer CE2 address 10.255.10.6 set protocols link-management peer CE2 control-channel gre.0 set protocols link-management peer CE2 te-link link1
CE2
set interfaces ge-0/0/0 vlan-tagging set interfaces ge-0/0/0 unit 1 vlan-id 1 set interfaces ge-0/0/0 unit 1 family inet address 10.2.2.1/24 set interfaces ge-0/0/0 unit 1 family mpls set interfaces ge-0/0/0 unit 10 vlan-id 10 set interfaces ge-0/0/0 unit 10 family inet address 10.10.10.2/24 set interfaces ge-0/0/0 unit 10 family mpls set interfaces gre unit 0 tunnel source 10.2.2.1 set interfaces gre unit 0 tunnel destination 10.2.2.2 set interfaces gre unit 0 family inet address 10.35.101.25/30 set interfaces lo0 unit 0 family inet address 10.255.10.6/32 set routing-options router-id 10.255.10.6 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols rsvp peer-interface PE2 set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols link-management te-link link10 local-address 10.36.1.1 set protocols link-management te-link link10 remote-address 10.36.1.2 set protocols link-management te-link link10 ethernet-vlan vlan-id-range 1-1000 set protocols link-management te-link link10 interface ge-0/0/0 set protocols link-management peer PE2 address 10.255.10.5 set protocols link-management peer PE2 control-channel gre.0 set protocols link-management peer PE2 te-link link10
Configuración del enrutador cliente
Procedimiento paso a paso
El ejemplo siguiente requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI.
Para configurar el enrutador CE1:
Repita este procedimiento para el enrutador CE2 en la red de capa de servidor, después de modificar los nombres de interfaz, las direcciones y cualquier otro parámetro adecuados para el enrutador.
-
Configure la interfaz que conecta el enrutador CE1 al enrutador PE1.
[edit interfaces] user@CE1# set ge-0/0/0 vlan-tagging
-
Configure la VLAN de control para la interfaz ge-0/0/0.
[edit interfaces] user@CE1# set ge-0/0/0 unit 1 vlan-id 1 user@CE1# set ge-0/0/0 unit 1 family inet address 10.1.1.1/30 user@CE1# set ge-0/0/0 unit 1 family mpls
-
Configure la VLAN LSP en la interfaz ge-0/0/0.
[edit interfaces] user@CE1# set ge-0/0/0 unit 10 vlan-id 10 user@CE1# set ge-0/0/0 unit 10 family inet address 10.10.10.1/24 user@CE1# set ge-0/0/0 unit 10 family mpls
-
Configure el túnel GRE como interfaz de control para el enrutador CE1.
[edit interfaces] user@CE1# set gre unit 0 tunnel source 10.1.1.1 user@CE1# set gre unit 0 tunnel destination 10.1.1.2 user@CE1# set gre unit 0 family inet address 10.35.100.25/30
-
Configure la interfaz de circuito cerrado del enrutador CE1.
[edit interfaces] user@CE1# set lo0 unit 0 family inet address 10.255.10.1/32
-
Configure la dirección de circuito cerrado del enrutador CE1 como su ID de enrutador.
[edit routing-options] user@CE1# set router-id 10.255.10.1
-
Active RSVP en todas las interfaces del enrutador CE1, excluyendo la interfaz de administración.
[edit protocols] user@CE1# set rsvp interface all user@CE1# set rsvp interface fxp0.0 disable
-
Configure la interfaz del par RSVP para el enrutador CE1.
[edit protocols] user@CE1# set rsvp peer-interface PE1
-
Deshabilite el cálculo automático de rutas para rutas conmutadas por etiquetas (LSP).
[edit protocols] user@CE1# set mpls no-cspf
-
Configure el LSP para conectar el enrutador CE1 al enrutador CE2.
[edit protocols] user@CE1# set mpls label-switched-path CE1-to-CE2 from 10.255.10.1 user@CE1# set mpls label-switched-path CE1-to-CE2 to 10.255.10.6
-
Configure los atributos LSP de CE1 a CE2.
[edit protocols] user@CE1# set mpls label-switched-path CE1-to-CE2 lsp-attributes switching-type ethernet-vlan user@CE1# set mpls label-switched-path CE1-to-CE2 lsp-attributes upstream-label vlan-id 10 user@CE1# set mpls label-switched-path CE1-to-CE2 bandwidth 100m
-
Configure la ruta LSP CE1 a CE2 y los parámetros de ruta.
[edit protocols] user@CE1# set mpls label-switched-path CE1-to-CE2 primary path1 user@CE1# set mpls path path1 10.35.1.2 strict user@CE1# set mpls path path1 10.255.10.5 loose user@CE1# set mpls path path1 10.36.1.1 strict
-
Habilite MPLS en todas las interfaces del enrutador CE1, excluyendo la interfaz de administración.
[edit protocols] user@CE1# set mpls interface all user@CE1# set mpls interface fxp0.0 disable
-
Configure un vínculo de ingeniería de tráfico y asigne direcciones para el extremo local y remoto del vínculo.
[edit protocols] user@CE1# set link-management te-link link10 local-address 10.35.1.1 user@CE1# set link-management te-link link10 remote-address 10.35.1.2
-
Habilite la configuración de LSP VLAN de capa 2 en el vínculo de ingeniería de tráfico link10.
[edit protocols] user@CE1# set link-management te-link link10 ethernet-vlan
-
Configure la interfaz CE1 del enrutador como interfaz miembro del vínculo de ingeniería de tráfico link10.
[edit protocols] user@CE1# set link-management te-link link10 interface ge-0/0/0
-
Configure el enrutador PE1 como par del protocolo de administración de vínculos (LMP) para el enrutador CE1 y configure los atributos del mismo nivel.
[edit protocols] user@CE1# set link-management peer PE1 address 10.255.10.2 user@CE1# set link-management peer PE1 control-channel gre.0 user@CE1# set link-management peer PE1 te-link link10
Resultados
Desde el modo de configuración, escriba los comandos , y show protocols para confirmar la show interfacesconfiguración. show routing-options Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
user@CE1# show interfaces
ge-0/0/0 {
vlan-tagging;
unit 1 {
vlan-id 1;
family inet {
address 10.1.1.1/30;
}
family mpls;
}
unit 10 {
vlan-id 10;
family inet {
address 10.10.10.1/24;
}
family mpls;
}
}
gre {
unit 0 {
tunnel {
source 10.1.1.1;
destination 10.1.1.2;
}
family inet {
address 10.35.100.25/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.255.10.1/32;
}
}
}
user@CE1# show routing-options router-id 10.255.10.1;
user@CE1# show protocols
rsvp {
interface all;
interface fxp0.0 {
disable;
}
peer-interface PE1;
}
mpls {
no-cspf;
label-switched-path CE1-to-CE2 {
from 10.255.10.1;
to 10.255.10.6;
lsp-attributes {
switching-type ethernet-vlan;
upstream-label {
vlan-id 10;
}
}
bandwidth 100m;
primary path1;
}
path path1 {
10.35.1.2 strict;
10.255.10.5 loose;
10.36.1.1 strict;
}
interface all;
interface fxp0.0 {
disable;
}
}
link-management {
te-link link10 {
local-address 10.35.1.1;
remote-address 10.35.1.2;
ethernet-vlan;
interface ge-0/0/0;
}
peer PE1 {
address 10.255.10.2;
control-channel gre.0;
te-link link10;
}
}
Configuración del enrutador del servidor
Procedimiento paso a paso
El ejemplo siguiente requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI.
Para configurar el enrutador PE1:
Repita este procedimiento para el enrutador PE2 en la red de capa de servidor, después de modificar los nombres de interfaz, las direcciones y cualquier otro parámetro adecuados para el enrutador.
-
Configure la interfaz que conecta el enrutador PE1 con el enrutador CE1.
[edit interfaces] user@PE1# set ge-0/0/0 vlan-tagging user@PE1# set ge-0/0/0 encapsulation flexible-ethernet-services
-
Configure la VLAN de control para la interfaz ge-0/0/0.
[edit interfaces] user@PE1# set ge-0/0/0 unit 1 vlan-id 1 user@PE1# ge-0/0/0 unit 1 family inet address 10.1.1.2/30 user@PE1# set ge-0/0/0 unit 1 family mpls
-
Configure la VLAN LSP en la interfaz ge-0/0/0.
[edit interfaces] user@PE1# set ge-0/0/0 unit 10 encapsulation vlan-ccc user@PE1# set ge-0/0/0 unit 10 vlan-id 10
-
Configure la interfaz que conecta el enrutador PE1 con los enrutadores principales (enrutador P1 y enrutador P2).
[edit interfaces] user@PE1# set ge-0/0/1 unit 0 family inet address 10.70.70.1/30 user@PE1# set ge-0/0/1 unit 0 family mpls user@PE1# set ge-0/0/2 unit 0 family inet address 10.20.20.1/30 user@PE1# set ge-0/0/2 unit 0 family mpls
-
Configure el túnel GRE como interfaz de control para el enrutador PE1.
[edit interfaces] user@PE1# set gre unit 0 tunnel source 10.1.1.2 user@PE1# set gre unit 0 tunnel destination 10.1.1.1 user@PE1# set gre unit 0 family inet address 10.35.100.26/30
-
Configure la interfaz de circuito cerrado del enrutador PE1.
[edit interfaces] user@PE1# set lo0 unit 0 family inet address 10.255.10.2/32
-
Configure la dirección de circuito cerrado del enrutador PE1 como su ID de enrutador.
[edit routing-options] user@PE1# set router-id 10.255.10.2
-
Configure un LSP bidireccional asociado y habilite la configuración unidireccional de LSP inverso para el LSP directo aprovisionado de una cara.
[edit protocols] user@PE1# set rsvp associated-bidirectional-lsp single-sided-provisioning
-
Active RSVP en todas las interfaces del enrutador PE1, excluyendo la interfaz de administración.
[edit protocols] user@PE1# set rsvp interface all user@PE1# set rsvp interface fxp0.0 disable
-
Configure la interfaz del par RSVP para el enrutador PE1 y habilite la configuración dinámica del LSP de paquetes bidireccional para transportar LSP GMPLS que no sea de paquete.
[edit protocols] user@PE1# set rsvp peer-interface CE1 dynamic-bidirectional-transport
-
Habilite MPLS en todas las interfaces del enrutador PE1, excluyendo la interfaz de administración.
[edit protocols] user@PE1# set mpls interface all user@PE1# set mpls interface fxp0.0 disable
-
Configure OSPF con capacidades de ingeniería de tráfico.
[edit protocols] user@PE1# set ospf traffic-engineering
-
Habilite el área 0 de OSPF en todas las interfaces del enrutador PE1, excluyendo la interfaz de administración.
[edit protocols] user@PE1# set ospf area 0.0.0.0 interface all user@PE1# set ospf area 0.0.0.0 interface fxp0.0 disable
-
Configure un vínculo de ingeniería de tráfico y asigne direcciones para el extremo local y remoto del vínculo.
[edit protocols] user@PE1# set link-management te-link link1 local-address 10.35.1.2 user@PE1# set link-management te-link link1 remote-address 10.35.1.1
-
Habilite la configuración de un LSP de VLAN de capa 2 para un rango específico de VLAN en el vínculo de ingeniería de tráfico link1.
[edit protocols] user@PE1# set link-management te-link link1 ethernet-vlan vlan-id-range 1-1000
-
Configure la interfaz PE1 del enrutador como interfaz miembro del vínculo de ingeniería de tráfico link1.
[edit protocols] user@CE1# set link-management te-link link1 interface ge-0/0/0
-
Configure el enrutador CE1 como el par LMP para el enrutador PE1 y configure los atributos del mismo nivel.
[edit protocols] user@CE1# set link-management peer CE1 address 10.255.10.1 user@CE1# set link-management peer CE1 control-channel gre.0 user@CE1# set link-management peer CE1 te-link link1
Resultados
Desde el modo de configuración, escriba los comandos , y show protocols para confirmar la show interfacesconfiguración. show routing-options Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
user@PE1# show interfaces
ge-0/0/0 {
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 1 {
vlan-id 1;
family inet {
address 10.1.1.2/30;
}
family mpls;
}
unit 10 {
encapsulation vlan-ccc;
vlan-id 10;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.70.70.1/30;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 10.20.20.1/30;
}
family mpls;
}
}
gre {
unit 0 {
tunnel {
source 10.1.1.2;
destination 10.1.1.1;
}
family inet {
address 10.35.100.26/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.255.10.2/32;
}
}
}
user@PE1# show routing-options router-id 10.255.10.2;
user@PE1# show protocols
rsvp {
associated-bidirectional-lsp single-sided-provisioning;
interface all;
interface fxp0.0 {
disable;
}
peer-interface CE1 {
dynamic-bidirectional-transport;
}
}
mpls {
interface all;
interface fxp0.0 {
disable;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
}
}
link-management {
te-link link1 {
local-address 10.35.1.2;
remote-address 10.35.1.1;
ethernet-vlan {
vlan-id-range 1-1000;
}
interface ge-0/0/0;
}
peer CE1 {
address 10.255.10.1;
control-channel gre.0;
te-link link1;
}
}
Verificación
Confirme que la configuración funcione correctamente.
- Verificación del estado del vínculo de ingeniería de tráfico en los enrutadores cliente
- Verificación del estado de la sesión RSVP en los enrutadores cliente
- Comprobación del estado de LSP en el enrutador del servidor
- Comprobación de las entradas CCC en la tabla de enrutamiento MPLS de los enrutadores servidor
- Verificación de la conectividad de extremo a extremo
Verificación del estado del vínculo de ingeniería de tráfico en los enrutadores cliente
Propósito
Verifique el estado del vínculo de ingeniería de tráfico configurado entre el enrutador CE1 y el enrutador CE2.
Acción
Desde el show link-management te-link detail modo operativo, ejecute los show link-management comandos y.
user@CE1> show link-management
Peer name: PE1, System identifier: 50740
State: Up, Control address: 10.255.10.2
Hello interval: 150, Hello dead interval: 500
Control-channel State
gre.0 Active
TE links:
link10
TE link name: link10, State: Up
Local identifier: 65075, Remote identifier: 0, Local address: 10.35.1.1, Remote address: 10.35.1.2, Encoding: Ethernet, Switching: EVPL, Minimum bandwidth: 0bps,
Maximum bandwidth: 1000Mbps, Total bandwidth: 1000Mbps, Available bandwidth: 900Mbps
Name State Local ID Remote ID Bandwidth Used LSP-name
ge-0/0/0 Up 54183 0 1000Mbps Yes CE1-to-CE2user@CE1> show link-management te-link detail
TE link name: link10, State: Up
Local identifier: 65075, Remote identifier: 0, Local address: 10.35.1.1, Remote address: 10.35.1.2, Encoding: Ethernet, Switching: EVPL, Minimum bandwidth: 0bps,
Maximum bandwidth: 1000Mbps, Total bandwidth: 1000Mbps, Available bandwidth: 900Mbps
Resource: ge-0/0/0, Type: IFD, System identifier: 137, State: Up, Local identifier: 54183, Remote identifier: 0
Total bandwidth: 1000Mbps, Unallocated bandwidth: 900Mbps
Traffic parameters: Encoding: Ethernet, Switching: EVPL, Granularity: Unknown
Maximum allocations: 4094, Number of allocations: 1, Unique allocations: 1, In use: Yes
LSP name: CE1-to-CE2, Local label: 10, Remote label: 10, Allocated bandwidth: 100Mbpsuser@CE2> show link-management
Peer name: PE2, System identifier: 50743
State: Up, Control address: 10.255.10.5
Hello interval: 150, Hello dead interval: 500
Control-channel State
gre.0 Active
TE links:
link10
TE link name: link10, State: Up
Local identifier: 65075, Remote identifier: 0, Local address: 10.36.1.1, Remote address: 10.36.1.2, Encoding: Ethernet, Switching: EVPL, Minimum bandwidth: 0bps,
Maximum bandwidth: 1000Mbps, Total bandwidth: 1000Mbps, Available bandwidth: 900Mbps
Name State Local ID Remote ID Bandwidth Used LSP-name
ge-0/0/0 Up 54183 0 1000Mbps Yes CE1-to-CE2Significado
El emparejamiento del Protocolo de administración de vínculos (LMP) se ha establecido entre los enrutadores cliente, y el vínculo de ingeniería de tráfico está activo en los enrutadores CE1 y CE2.
Verificación del estado de la sesión RSVP en los enrutadores cliente
Propósito
Verifique el estado de las sesiones RSVP entre el enrutador CE1 y el enrutador CE2.
Acción
Desde el modo operativo, ejecute el show rsvp session comando.
user@CE1> show rsvp session Ingress RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname 10.255.10.6 10.255.10.1 Up 0 1 FF - 10 CE1-to-CE2 Bidir Total 1 displayed, Up 1, Down 0 Egress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0
user@CE2> show rsvp session Ingress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname 10.255.10.6 10.255.10.1 Up 0 1 FF 10 - CE1-to-CE2 Bidir Total 1 displayed, Up 1, Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0
Significado
Las sesiones RSVP se establecen entre el enrutador de entrada, el enrutador CE1, y el enrutador de salida, el enrutador CE2.
Comprobación del estado de LSP en el enrutador del servidor
Propósito
Verifique el estado del LSP MPLS en el enrutador PE1.
Acción
Desde el modo operativo, ejecute el show mpls lsp comando.
user@PE1> show mpls lsp Ingress LSP: 1 sessions To From State Rt P ActivePath LSPname 10.255.10.5 10.255.10.2 Up 0 * vlan:0:10:8176:10.255.10.2->10.255.10.5 Assoc-Bidir Total 1 displayed, Up 1, Down 0 Egress LSP: 1 sessions To From State Rt Style Labelin Labelout LSPname 10.255.10.2 10.255.10.5 Up 0 1 FF 3 - vlan:0:10:8176:10.255.10.2->10.255.10.5:rev Total 1 displayed, Up 1, Down 0 Transit LSP: 1 sessions To From State Rt Style Labelin Labelout LSPname 10.255.10.6 10.255.10.1 Up 0 1 FF 10 299808 CE1-to-CE2 Bidir Total 1 displayed, Up 1, Down 0
Significado
Se establece el LSP CE1 a CE2 y el resultado muestra los atributos LSP.
Comprobación de las entradas CCC en la tabla de enrutamiento MPLS de los enrutadores servidor
Propósito
Compruebe las entradas de la interfaz de conexión cruzada de circuitos (CCC) en la tabla de enrutamiento MPLS.
Acción
Desde el show route forwarding-table ccc ccc-interface modo operativo, ejecute los show route table mpls.0 comandos y.
user@PE1> show route table mpls.0
mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 1d 22:14:51, metric 1
Receive
1 *[MPLS/0] 1d 22:14:51, metric 1
Receive
2 *[MPLS/0] 1d 22:14:51, metric 1
Receive
13 *[MPLS/0] 1d 22:14:51, metric 1
Receive
299824 *[RSVP/7/1] 17:32:07, metric 1
> via ge-0/0/0.10, Pop
ge-0/0/0.10 *[RSVP/7/1] 17:32:07, metric 1
> to 10.20.20.2 via ge-0/0/2.0, label-switched-path CE1-to-CE2user@PE1> show route forwarding-table ccc ge-0/0/0.10 Routing table: default.mpls MPLS: Destination Type RtRef Next hop Type Index NhRef Netif ge-0/0/0.10 (CCC) user 0 10.20.20.2 Push 299808, Push 299872(top) 581 2 ge-0/0/2.0 Routing table: __mpls-oam__.mpls MPLS: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 dscd 534 1
Significado
El resultado muestra la interfaz CCC que es la interfaz orientada al enrutador cliente y los detalles del próximo salto para esa interfaz.
Verificación de la conectividad de extremo a extremo
Propósito
Compruebe la conectividad entre el enrutador CE1 y el enrutador cliente remoto, enrutador CE2.
Acción
Desde el modo operativo, ejecute el ping comando.
user@CE1> ping 10.10.10.2 PING 10.10.10.2 (10.10.10.2): 56 data bytes 64 bytes from 10.10.10.2: icmp_seq=0 ttl=64 time=15.113 ms 64 bytes from 10.10.10.2: icmp_seq=1 ttl=64 time=13.353 ms 64 bytes from 10.10.10.2: icmp_seq=2 ttl=64 time=13.769 ms 64 bytes from 10.10.10.2: icmp_seq=3 ttl=64 time=10.341 ms 64 bytes from 10.10.10.2: icmp_seq=4 ttl=64 time=12.597 ms ^C --- 10.10.10.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 10.341/13.035/15.113/1.575 ms
Significado
El ping del enrutador CE1 al enrutador CE2 se realiza correctamente.