EN ESTA PÁGINA
Descripción general de interfaces lógicas de suscriptor de pseudocable
Redundancia de anclaje Descripción general de interfaces lógicas de suscriptor de pseudocable
Configuración de una interfaz lógica de suscriptor de pseudocable
Configuración de un dispositivo de interfaz lógica de suscriptor de pseudocable
Cambiar el punto de anclaje de un dispositivo de interfaz lógica de suscriptor de pseudocable
Configuración de la señalización VPN de capa 2 para interfaces lógicas de suscriptor de pseudocable
Configuración del soporte de equilibrio de carga para el tráfico de suscriptor
Interfaces lógicas de suscriptor de pseudocable MPLS
Descripción general de interfaces lógicas de suscriptor de pseudocable
La administración de suscriptores admite la creación de interfaces de suscriptores mediante pseudocables MPLS punto a punto. La capacidad de interfaz de suscriptor pseudowire permite a los operadores de telecomunicaciones extender un dominio MPLS desde la red de acceso-agregación hasta el borde del servicio, donde se realiza la administración de suscriptores. Los proveedores de servicios pueden aprovechar las capacidades de MPLS, como la tolerancia a fallos, el reenrutamiento y el aprovisionamiento uniforme de etiquetas de MPLS, mientras usan un único pseudocable para dar servicio a una gran cantidad de suscriptores de DHCP y PPPoE en la red de servicios.
Las interfaces lógicas del suscriptor de pseudocable solo se admiten en concentradores de puertos modulares (MPC) con tarjetas de interfaz modular Ethernet (MIC). La terminación PPPoE y L2TP no se admite cuando se usa la encapsulación VPLS y la autenticación DHCP para la interfaz lógica de transporte. Sin embargo, la funcionalidad de venta al por mayor de capa 2 de administración de suscriptores de banda ancha es compatible con la encapsulación VPLS. Se crea una interfaz VLAN dinámica con encapsulación VPLS en un enrutador mayorista que realiza conmutación de etiquetas VLAN para terminar los suscriptores PPPoE/DHCP en la red del minorista. Para obtener más información, consulte Elementos de configuración y topología de venta al por mayor de capa 2 de administración de suscriptores de banda ancha.
El pseudocable es un túnel que es una VPN de capa 2 basada en MPLS o un circuito de capa 2. El túnel de pseudocable transporta el tráfico encapsulado Ethernet desde un nodo de acceso (por ejemplo, un DSLAM u otro dispositivo de agregación) al enrutador de la serie MX que aloja los servicios de administración de suscriptores. La terminación del túnel de pseudocable en el enrutador de la serie MX es similar a una terminación Ethernet física y es el punto en el que se realizan las funciones de administración de suscriptores. Un proveedor de servicios puede configurar múltiples pseudocables por DSLAM y luego aprovisionar soporte para una gran cantidad de suscriptores en un pseudocable específico.
La Figura 1 muestra una red MPLS que proporciona soporte de administración de suscriptores.
En el extremo del nodo de acceso del pseudocable, el tráfico del suscriptor se puede preparar en el pseudocable de varias maneras, limitadas únicamente por el número y los tipos de interfaces que se pueden apilar en el pseudocable. Especifique un punto de anclaje, el cual identifica la interfaz de túnel lógico que termina el túnel de pseudocable en el nodo de acceso.
de administración de suscriptores
La figura 2 muestra la pila de protocolos para una interfaz lógica de suscriptor pseudowire. El pseudocable es un dispositivo virtual que se apila por encima del punto de anclaje del túnel lógico en la interfaz física (el IFD) y admite un protocolo de capa 2 orientado a circuitos (ya sea VPN de capa 2 o circuito de capa 2). El protocolo de capa 2 proporciona las interfaces lógicas de transporte y servicio, y es compatible con la familia de protocolos (IPv4, IPv6 o PPPoE).
A partir de Junos OS versión 18.3R1, en enrutadores de la serie MX con interfaces MPC y MIC, la compatibilidad con la interfaz de servicio de suscriptor pseudowire sobre túneles lógicos redundantes se introduce en las VPN de capa 3 y las VPN de multidifusión draft-rosen. Anteriormente, las VPN de capa 3 proporcionaban compatibilidad con servicios de suscriptor de pseudocable solo en interfaces de túnel lógico, y estas interfaces utilizaban protocolos de enrutamiento de unidifusión, como OSPF o BGP. Con esta compatibilidad, puede aprovisionar un protocolo de enrutamiento de multidifusión, Multidifusión independiente de protocolo (PIM), en las interfaces de suscriptor de pseudocable, el cual finaliza en la instancia de enrutamiento de enrutamiento y reenvío virtual (VRF). Además, hay un aumento en los números de escalado de los dispositivos de interfaz lógica pseudowire que proporciona soporte de resistencia adicional para las interfaces de suscriptor pseudowire en interfaces de túnel lógico redundantes.
Cuando una interfaz de servicio de suscriptor de pseudowire está anclada a un túnel lógico redundante cuya interfaz miembro (o FPC) no existe, la interfaz de túnel desciende. En estos casos, las interfaces de pseudocable (físicas y lógicas) también deben estar inactivas, pero, sin embargo, el estado de la interfaz lógica del suscriptor de pseudocable permanece activo, aunque los servicios de circuito de capa 2, como hacer ping hacia un dispositivo de borde de cliente (CE) desde el lado del servicio de la interfaz de servicio de suscriptor de pseudocable, no estén disponibles.
Esto se debe a que el lado de transporte de la interfaz lógica del suscriptor del pseudocable permanece activo, lo que hace que los servicios estén activos.
La configuración de pseudocable es transparente para las aplicaciones de administración de suscriptores y no tiene ningún impacto en las cargas de paquetes que se utilizan para la administración de suscriptores. Las aplicaciones de suscriptor, como DHCP y PPPoE, se pueden apilar en la capa 2, de manera similar a como se apilan en una interfaz física.
A partir de Junos OS versión 16.1R1, family inet y family inet6 son compatibles con los servicios de un suscriptor de pseudocable MPLS, así como con una interfaz lógica que no sea de suscriptor.
A partir de Junos OS versión 16.1R1, se admite IPFIX en línea en el lado de servicios de una interfaz lógica de suscriptor de pseudocable MPLS.
A partir de Junos OS versión 15.1R3 y 16.1R1 y versiones posteriores, la encapsulación CCC es compatible en el lado de transporte de una interfaz lógica de suscriptor de pseudocable MPLS.
Antes de Junos OS versión 19.1R1, el único tipo de encapsulación admitido en las interfaces de suscriptor de pseudowire incluía:
-
Interfaces lógicas de transporte: encapsulación de conexión cruzada de circuitos (CCC).
-
Service logical interfaces:
-
Encapsulación Ethernet VPLS
-
Encapsulación de puente VLAN
-
Encapsulación VPLS de VLAN
-
A partir de Junos OS versión 19.1R1, se agregan encapsulaciones adicionales al transporte de suscriptores de pseudocable y a las interfaces lógicas de servicio. La interfaz lógica de transporte admite la encapsulación VPLS de Ethernet y disposiciones para terminar la interfaz en la l2backhaul-vpn instancia de enrutamiento. La interfaz lógica de servicio admite la encapsulación de conexión cruzada de circuitos (CCC) y disposiciones para terminar la interfaz en circuitos de capa 2 conmutados localmente.
Con la compatibilidad de tipos de encapsulación adicionales, puede beneficiarse de la demux de una l2backhaul VPN en varios servicios VPN, como el circuito de capa 2 y la VPN de capa 3. Dado que las interfaces de suscriptor de pseudowire están ancladas a túneles lógicos redundantes, esta mejora también proporciona redundancia de tarjeta de línea.
A partir de Junos OS versión 15.1R3 y 16.1R1 y versiones posteriores, se admite la protección de denegación de servicio distribuido (DDoS) en el lado de servicios de una interfaz lógica de suscriptor MPLS pseudowire.
A partir de Junos OS versión 15.1R3 y 16.1R1 y versiones posteriores, se admiten Policer y Filter en el lado de servicios de una interfaz lógica de suscriptor de pseudocable MPLS.
A partir de Junos OS versión 15.1R3 y 16.1R1 y versiones posteriores, se admiten estadísticas de transmisión precisas en la interfaz lógica en el lado de los servicios de una interfaz lógica de suscriptor MPLS pseudowire.
A partir de Junos OS versión 17.3R1 y versiones posteriores, la compatibilidad con la redundancia de punto de anclaje con estado se proporciona a la interfaz lógica del suscriptor de pseudocable mediante la interfaz de túnel lógico redundante (rlt) subyacente en modo de copia de seguridad activa. Esta redundancia protege el acceso y el vínculo frontal del núcleo contra el fallo del motor de reenvío de paquetes (PFE) de anclaje.
Redundancia de anclaje Descripción general de interfaces lógicas de suscriptor de pseudocable
En los despliegues de pseudocable MPLS que utilizan interfaces lógicas de suscriptor pseudocable, un error en el motor de reenvío de paquetes que aloja el túnel lógico que ancla esas interfaces lógicas provoca pérdida de tráfico y la consiguiente pérdida de la sesión del suscriptor.
El motor de reenvío de paquetes no se basa en el plano de control para la detección de errores; en su lugar, utiliza un mecanismo de detección de vida, con un algoritmo subyacente basado en latidos, para detectar el fallo de otros motores de reenvío de paquetes en el sistema. El error de un motor de reenvío de paquetes también indica el error del túnel lógico alojado, lo que en última instancia conduce a la pérdida de la sesión. Para evitar esta pérdida de sesión, se requiere un punto de anclaje redundante al que se pueda mover la sesión sin perder tráfico.
Las interfaces lógicas de suscriptor de pseudocable se pueden instanciar a través de una interfaz de túnel lógico redundante (RLT) subyacente en modo activo-activo o activo-copia de respaldo. Esto se agrega a la instalación de pseudocables en interfaces de un solo túnel lógico. La ventaja más notable de implementar la interfaz lógica del suscriptor pseudowire sobre interfaces RLT es proporcionar redundancia de la ruta de reenvío subyacente. Esto permite que el sistema genere nuevos suscriptores y mantenga operativos a los suscriptores existentes, incluso si una interfaz miembro del RLT deja de funcionar debido a una deshabilitación de PFE. Los suscriptores permanecerán activos siempre que haya al menos un enlace de miembro de RLT en un PFE activo.
Antes de Junos OS versión 18.3R1, podía especificar un máximo de 2048 dispositivos de interfaz de túnel lógico redundantes para el suscriptor de pseudowire para un enrutador de la serie MX. A partir de la versión 18.3R1 de Junos OS, en enrutadores de la serie MX con interfaces MPC y MIC, el número de escalado de dispositivos de interfaz lógica redundante pseudowire aumentó a 7000 dispositivos para proporcionar soporte de resistencia adicional.
La versión 17.3 de Junos OS también admite una infraestructura agregada mejorada para un motor de reenvío de paquetes a fin de proporcionar redundancia de punto de anclaje. La infraestructura agregada mejorada requiere un mínimo de una interfaz lógica de control que debe crearse en una interfaz de túnel lógico redundante. Tanto las interfaces lógicas de transporte como las de servicios creadas para la interfaz lógica del suscriptor de pseudocable se apilan en la interfaz lógica de control subyacente para el túnel lógico redundante. Este modelo de apilamiento se utiliza para interfaces lógicas de suscriptor pseudowire redundantes y no redundantes.
Los siguientes eventos tienen que desencadenar la eliminación de la interfaz física de un grupo redundante:
-
Error de hardware en el concentrador de PIC modular (MPC) o en la tarjeta de interfaces modulares (MIC).
-
Falla de MPC debido a un bloqueo del microkernel.
-
MPC o MIC desconectados administrativamente.
-
Falla de alimentación en un MPC o MIC.
La Figura 3 proporciona los detalles del apilamiento de la interfaz lógica del suscriptor de pseudowire sobre una interfaz de túnel lógico redundante.
de túnel lógico redundante
El ifl de servicio estático no se apila sobre el ifl de transporte cuando se usa RLT.
De forma predeterminada, la protección de vínculos para interfaces de túnel redundantes es reversible. En caso de que se produzca un error en el vínculo activo, el tráfico se enruta a través del vínculo de respaldo. Cuando se restablece el vínculo activo, el tráfico se enruta automáticamente de vuelta al vínculo activo. Esto provoca pérdida de tráfico y pérdida de la sesión del suscriptor.
Para superar la pérdida de tráfico y de sesión, puede configurar la protección de vínculos no revertidos para interfaces de túnel redundantes mediante la instrucción set interfaces rltX logical-tunnel-options link-protection non-revertiveconfiguration . Con esta configuración, cuando se restablece el vínculo activo, el tráfico no se enruta de vuelta al vínculo activo y se sigue reenviando en el vínculo de respaldo. Por lo tanto, no hay pérdida de tráfico ni pérdida de sesión del suscriptor. También puede cambiar manualmente el tráfico del vínculo de respaldo al vínculo activo mediante el request interface (revert | switchover) interface-name comando.
La conmutación manual del tráfico incurre en pérdida de tráfico.
-
Una interfaz lógica de control se crea implícitamente en una interfaz de túnel redundante con la configuración de interfaz lógica del suscriptor pseudowire y, por lo tanto, no se necesita ninguna configuración adicional.
-
Una interfaz de túnel lógico redundante permite interfaces físicas de túnel lógico de 32 miembros. Sin embargo, una interfaz lógica de suscriptor pseudowire alojada en la interfaz de túnel lógico redundante limita el número de interfaces físicas de túnel lógico a dos.
No puede deshabilitar la interfaz de túnel lógico (rlt) redundante subyacente ni la interfaz de túnel lógico (lt) subyacente cuando un pseudocable está anclado a esa interfaz. Si desea deshabilitar la interfaz subyacente, primero debe desactivar el pseudocable.
A partir de la versión 18.4R1 de Junos OS, el soporte para la distribución en línea de sesiones de detección de reenvío bidireccional (BFD) de un solo salto se extiende al suscriptor de pseudowire a través de interfaces de túnel lógico redundantes. Para el suscriptor de pseudocable a través de interfaces de túnel lógico, las interfaces se anclan en un único concentrador de PIC flexible (FPC); como resultado, la distribución en línea de sesiones BFD de un solo salto es compatible de forma predeterminada. Con las interfaces lógicas redundantes de pseudowire, las interfaces de túnel lógico miembro se pueden alojar en diferentes tarjetas de línea. Dado que la dirección de distribución no está disponible para las interfaces lógicas redundantes, la distribución de las sesiones de BFD de un solo salto se operaba en modo centralizado antes de la versión 18.4R1 de Junos OS.
Con el soporte para la distribución en línea de sesiones de BFD de un solo salto a través de interfaces lógicas redundantes de pseudocable, existe una ventaja de escalado de hasta 2000 sesiones de BFD de un solo salto en un intervalo de un segundo y una mejora en el tiempo de detección que mejora el rendimiento de las sesiones.
La operación BFD para el suscriptor pseudowire sobre interfaces lógicas redundantes es la siguiente:
-
Cuando se agrega una nueva sesión de BFD, se puede anclar a una FPC activa o de respaldo.
-
Cuando se produce un error en alguna de las FPC o se reinicia, todas las sesiones alojadas en esa FPC dejan de funcionar y se activa el reanclaje para la siguiente dirección de distribución disponible. Las sesiones de BFD vuelven a funcionar después de que las sesiones se instalan en la otra FPC y se inicia el intercambio de paquetes de BFD.
Sin embargo, también es posible que las sesiones en la FPC de respaldo no desactiven cuando se produzca un error en la FPC activa en función del tiempo de detección de BFD configurado, ya que el estado de reenvío de la nueva FPC activa puede tardar algún tiempo en programarse.
-
Cuando se produce un error en la FPC activa, todas las sesiones de BFD se anclan a la FPC de respaldo. Del mismo modo, si se produce un error en la FPC de respaldo, todas las sesiones de BFD se anclan en la FPC activa.
-
El reanclaje de la sesión BFD no se activa cuando la FPC activa vuelve a estar en línea.
-
Con el comportamiento no revertido habilitado, cuando la FPC activa anteriormente vuelva a estar en línea, no se espera que las sesiones se interrumpan. Con el comportamiento de reversión predeterminado, es posible que sea necesario actualizar el estado de reenvío y, dependiendo de la configuración del tiempo de detección, la sesión puede oscilar o no.
Tenga en cuenta lo siguiente con el soporte de la distribución en línea de sesiones de BFD de un solo salto en interfaces de suscriptor de pseudowire a través de túnel lógico:
-
En la MPC 7e de tipo FPC, con la activación de la instancia de enrutamiento 7000, las sesiones de BGP 7000 tardan unos seis minutos en establecerse en las interfaces de suscriptor de pseudocable ancladas en interfaces de túnel lógico redundantes.
-
Se registra un nuevo mensaje de error de registro del sistema:
JTASK_SCHED_SLIP- durante el enrutamiento activo sin paradas (NSR). Este es el comportamiento esperado de NSR con alta escala y se puede ignorar con seguridad, a menos que haya otros problemas, como fallas de sesión, que requieran que se tomen medidas.
A partir de la versión 21.4R1 de Junos OS, introdujimos el soporte de CoS para un BNG en la interfaz del suscriptor en un pseudocable a través de una interfaz de túnel lógico redundante (RLT) activa-activa para aplicaciones de suscriptor, como DHCP y PPPoE. Esta propiedad CoS se logra proporcionando los nodos de programación para los vínculos de túnel lógicos. Para interfaces dinámicas, conjuntos de interfaces, interfaces subyacentes estáticas e interfaces subyacentes dinámicas a través de RLT, CoS asigna nodos de programación para cada vínculo en el RLT, que tiene varios vínculos de túnel lógico en modo activo-activo. En el caso de interfaces de destino y conjuntos de interfaces de destino que tienen vínculos primarios y de respaldo, la CoS asigna nodos de programación en los vínculos primarios y de respaldo para optimizar el uso de los nodos de programación. El tráfico de las interfaces de destino del suscriptor se distribuirá a todos los vínculos LT principales cuando se aplique CoS a nivel de suscriptor. Además, el tráfico de cualquier suscriptor dado siempre se procesa por el mismo motor de reenvío de paquetes.
En la figura 4, se proporcionan los detalles de las interfaces principal e secundaria utilizadas para la jerarquía del programador de cuatro niveles para el acceso de los suscriptores. La IFL PPPoE dinámica y el conjunto dinámico de IFL son nodos secundarios. El conjunto dinámico de svlan IFL y el nodo uifl dinámico o estático son nodos principales.
de suscriptores
Cuando habilite la segmentación en un nodo, debe habilitar la segmentación para todos los nodos secundarios para que la CoS funcione correctamente. Para habilitar los nodos secundarios, configure el perfil dinámico en el nivel . [edit interfaces ps1 auto-configure stacked-vlan-ranges dynamic-profile] Cree un perfil dinámico mediante la configuración de interfaces de destino dinámico y conjuntos de interfaces en [edit dynamic-profiles].
A continuación, se muestra un ejemplo de la configuración del perfil dinámico:
dvlanProf {
interfaces {
"$junos-interface-ifd-name" {
unit "$junos-interface-unit" {
demux-source [ inet inet6 ];
no-traps;
proxy-arp;
vlan-tags outer "$junos-stacked-vlan-id" inner "$junos-vlan-id";
targeted-distribution;
family inet {
unnumbered-address lo0.0 preferred-source-address 100.0.0.1;
}
family inet6 {
unnumbered-address lo0.0 preferred-source-address 1000:0::1;
}
family pppoe {
duplicate-protection;
dynamic-profile pppoeClientSvlanSetVar;
}
}
}
}
}
pppoeClientSvlanSetVar {
interfaces {
interface-set "$junos-svlan-interface-set-name" {
targeted-distribution;
interface pp0 {
unit "$junos-interface-unit";
}
}
pp0 {
unit "$junos-interface-unit" {
actual-transit-statistics;
ppp-options {
pap;
}
pppoe-options {
underlying-interface "$junos-underlying-interface";
server;
}
targeted-distribution;
keepalives interval 30;
family inet {
unnumbered-address "$junos-loopback-interface";
}
}
}
}
}
Además, debe configurar los servicios enhanced-ip de red en el nivel de jerarquía, ya que esta función solo funciona en el [edit chassis] modo IP mejorado.
El modo de vínculo múltiple activo-activo con destino utiliza los algoritmos de destino de la interfaz RLT para distribuir los clientes entre los distintos miembros de RLT (pares de tramo primario/secundario). La segmentación se puede aplicar a suscriptores dinámicos y conjuntos de interfaces dinámicas. El algoritmo de segmentación revisa la lista de pseudo IFL asociadas con el par de vínculos miembro y selecciona la primera pseudo IFL que tenga suficiente capacidad en función del archivo rebalance-subscriber-granularity.
Cuando la segmentación está habilitada, al suscriptor se le asigna un peso de segmentación predeterminado basado en el tipo de cliente. El algoritmo de segmentación utiliza el peso de asignación en el proceso de selección de pseudo IFL y el peso de débito de IFL es el peso contado contra el pseudo IFL asignado. Para todos los objetos excepto el IFLset, la asignación y el peso del débito son los mismos y puede modificarlos a través del perfil del cliente. En el caso del IFLset, solo se puede modificar el atributo de peso de asignación a través del perfil del cliente, y el peso de débito para el IFLset se fija en un valor de 0.
| Tipo de cliente |
Peso de asignación |
Peso de débito |
|---|---|---|
| DVLAN |
1 |
1 |
| IpDemux |
1 |
1 |
| APP |
1 |
1 |
| IFLset |
32 |
0 |
PWHT para dispositivos ACX
Para los dispositivos ACX que utilizan el modo BNG CUPS para la administración de suscriptores, PWHT finaliza el control de pseudocable MPLS y reenvía los paquetes de datos a su destino utilizando el protocolo IP estándar.
Las funciones de pseudocable y PWHT (terminación de la cabecera del pseudocable) en dispositivos ACX que admiten esta función requieren que el dispositivo se ejecute en modo BNG CUPS. En el modo CUPS, el plano de control se ejecuta desde una nube centralizada, mientras que el plano de usuario se ejecuta en el dispositivo. Todas las funciones de pseudocable y PWHT están disponibles para usted en el modo BNG CUPS. Consulte la Guía del usuario de BNG CUPS para obtener más detalles sobre cómo configurar su dispositivo en modo CUPS.
Use el Explorador de características para confirmar la compatibilidad de plataforma y versión para características específicas.
PWHT se utiliza para terminar el control de pseudocable MPLS en el enrutador de borde del proveedor de servicios. Al salir del pseudocable, la información de control (mensajes de señalización PPPoE o DHCP) se envía al plano de control centralizado, mientras que los datos regulares se reenvían a su destino como paquetes IP estándar.
Para configurar PWHT en su dispositivo ACX, primero debe configurarlo para el modo CUPS. Consulte Configuración del controlador BNG CUPS y Configuración de planos de usuario BNG para obtener más información.
La configuración PWHT se produce en el plano de usuario (su dispositivo) en lugar de en el plano de control (nube). Esto se hace porque las interfaces de túnel lógico (lt) y pseudocable (ps) se deben crear dentro del plano de usuario dentro de Junos OS evolucionado. Los comandos para configurar las interfaces lt y ps son los mismos que en Junos OS; sin embargo, los dispositivos ACX requieren los números de ranura y núcleo del anclaje PWHT en la configuración. Los dispositivos ACX también requieren que configure manualmente su reserva de ancho de banda.
A diferencia de Junos OS, las interfaces LT se crean en función del número FPC o FEB, el número PFE, el número de núcleo y el canal que se seleccionan durante el comando de configuración. Esta ubicación no se basa en el ancho de banda. En los ejemplos siguientes, el IFD LT sería lt-0/0/0:0. Si se necesitara otra interfaz LT en esa misma ranura, estaría en un canal diferente, por ejemplo, lt-0/0/0:1.
Este es un ejemplo de una configuración para un dispositivo ACX basado en FEB.
chassis {
feb 0 {
pfe 0 {
core 0 {
channel 0 {
tunnel-services {
bandwidth 10g;
}
}
}
}
}
}
Este es un ejemplo de una configuración para un dispositivo ACX basado en FPC.
chassis {
fpc 0 {
pfe 0 {
core 0 {
channel 0 {
tunnel-services {
bandwidth 10g;
}
}
}
}
}
}
Este es un ejemplo de una configuración de interfaz pseudowire (ps).
interfaces {
ps1 {
anchor-point {
lt-0/0/0:0 {
}
flexible-vlan-tagging;
auto-configure {
stacked-vlan-ranges {
dynamic-profile svlan-prof {
accept [dhcp-v4 dchp-v6 pppoe];
ranges {
any,any;
}
}
}
}
set interfaces ps1 unit 0 encapsulation ethernet-ccc
}
}
Ver también
Configuración de PWHT para dispositivos ACX
Cómo configurar PWHT en dispositivos ACX en modo BNG CUPS.
Los dispositivos ACX compatibles con funciones PWHT deben estar en modo CUPS. Consulte la Guía del usuario de BNG CUPS para configurar su dispositivo en modo CUPS.
Para configurar la interfaz lt y el ancho de banda reservado total, siga estos pasos.
Configuración de una interfaz lógica de suscriptor de pseudocable
Una interfaz lógica de suscriptor pseudowire finaliza un túnel de pseudocable MPLS desde un nodo de acceso al enrutador de la serie MX que aloja la administración de suscriptores y le permite realizar servicios de administración de suscriptores en la interfaz.
Para crear una interfaz lógica de suscriptor pseudowire:
Configuración del número máximo de dispositivos de interfaz lógica Pseudowire admitidos en el enrutador
Debe establecer la cantidad máxima de dispositivos de interfaz lógica pseudowire (túneles pseudowire) que el enrutador puede utilizar para las interfaces lógicas del suscriptor. Al establecer el número máximo, también se definen los nombres de interfaz para las interfaces pseudowire. Cuando configure posteriormente las interfaces, debe especificar los nombres de interfaz en el intervalo entre ps0 y ps(device-count - 1).
Por ejemplo, si establece la cantidad máxima de dispositivos en 5, solo puede configurar las interfaces ps0, ps1, ps2, ps3 y ps4.
Antes de la versión 17.2R1 de Junos OS, podía especificar un máximo de 2048 dispositivos de interfaz lógica pseudowire para un enrutador de la serie MX. A partir de la versión 17.2R1 de Junos OS, en enrutadores de la serie MX con interfaces MPC y MIC, el número de escalado de dispositivos de interfaz lógica pseudowire aumentó a 7000 dispositivos para proporcionar soporte de resistencia adicional.
Del mismo modo, antes de Junos OS versión 18.3R1, podía especificar un máximo de 2048 dispositivos de interfaz de túnel lógico redundante (rlt) de suscriptor de pseudowire para un enrutador de la serie MX. A partir de la versión 18.3R1 de Junos OS, en enrutadores de la serie MX con interfaces MPC y MIC, el número de escalado de dispositivos de interfaz lógica redundante pseudowire aumentó a 7000 dispositivos para proporcionar soporte de resistencia adicional.
A partir de la versión 20.4R1 de Junos OS, en enrutadores MX2010 y MX2020 con la tarjeta de línea MX2K-MPC9E o MX2K-MPC11E, puede especificar hasta 18000 dispositivos de interfaz lógica pseudowire.
El PFE que aloja el máximo de dispositivos de interfaz lógica de pseudocable proporciona la flexibilidad de configuración necesaria para casos especiales que pueden ocurrir en escenarios de borde empresarial. Sin embargo, puede superar los recursos de PFE disponibles a medida que configura servicios adicionales en los puertos de dispositivos de interfaz lógica pseudowire. Para admitir una configuración escalada, asegúrese de rellenar el número adecuado de PFE para el chasis y de distribuir los dispositivos de interfaz lógica pseudowire entre las PFE de tal manera que se garantice que ninguna PFE se vea abrumada por la carga máxima anticipada. Como parte de la planeación de red para su implementación particular, debe considerar la combinación exacta de la distribución de los dispositivos de interfaz lógica de pseudocable y los servicios asociados con los dispositivos.
Un dispositivo de interfaz lógica pseudocable configurado consume recursos de grupos compartidos incluso cuando el dispositivo no tiene interfaces lógicas de suscriptor activas. Para conservar recursos, no despliegue una cantidad excesiva de dispositivos pseudowire que no tenga intención de usar.
Para configurar la cantidad de dispositivos de interfaz lógica pseudowire que desea que admita el enrutador:
Configuración de un dispositivo de interfaz lógica de suscriptor de pseudocable
Para configurar un dispositivo de interfaz lógica pseudowire que el enrutador utiliza para las interfaces lógicas del suscriptor, especifique el túnel lógico que procesa la terminación del pseudocable. También puede usar túneles lógicos redundantes para proporcionar redundancia a los túneles lógicos miembro. Puede configurar parámetros opcionales adicionales para el dispositivo de interfaz, como el método de etiquetado VLAN, la UMT y la compatibilidad con ARP gratuita.
Debe crear un túnel lógico para el dispositivo de interfaz lógica pseudowire. Si usa túneles lógicos redundantes, debe crear el túnel redundante.
Para configurar el dispositivo de interfaz de suscriptor pseudowire:
Cambiar el punto de anclaje de un dispositivo de interfaz lógica de suscriptor de pseudocable
No se puede cambiar dinámicamente un punto de anclaje que tenga dispositivos pseudocables activos apilados encima de él. Debe confirmar ciertos cambios antes de mover el punto de anclaje. Algunos ejemplos de esta situación son mover el punto de anclaje de un túnel lógico a otro túnel lógico, de un túnel lógico a un túnel lógico redundante y de un túnel lógico redundante a un túnel lógico.
Para mover el punto de anclaje entre interfaces de túnel lógico:
Para mover el punto de anclaje de una interfaz de túnel lógico a una interfaz de túnel lógico redundante:
Desactive los pseudocables apilados y confirme. Esto puede requerir derribar a cualquier suscriptor que use los pseudocables.
[edit interfaces] user@host# deactivate psnumber user@host# commit
Agregue la nueva interfaz de túnel lógico redundante y confirme.
Cree el túnel y establezca el número máximo de dispositivos permitidos.
[edit chassis] user@host# set redundancy-group interface-type redundant-logical-tunnel device-count count
Enlazar cada túnel lógico miembro al túnel lógico redundante.
Nota:Los túneles lógicos redundantes requieren que los miembros estén en modo de copia de seguridad activa. El túnel lógico de respaldo debe encontrarse en una FPC distinta a la del túnel lógico activo. Por ejemplo, si el túnel activo está en FPC 3, el túnel de respaldo debe estar en una FPC diferente, como FPC 4.
[edit interfaces rltnumber] user@host# set redundancy-group member-interface lt-fpc/pic/port active user@host# set redundancy-group member-interface lt-fpc/pic/port backup
Confirme los cambios.
[edit interfaces rltnumber] user@host# commit
Cambie el anclaje del pseudocable desactivado a la nueva interfaz de túnel lógico redundante y confirme.
[edit interfaces] user@host# set psnumber anchor-point rltnumber user@host# commit
Reactive los pseudocables apilados y confirme.
[edit interfaces] user@host# activate psnumber user@host# commit
Para mover el punto de anclaje de una interfaz de túnel lógico redundante a una interfaz de túnel lógico que sea miembro del túnel lógico redundante:
Desactivar los pseudocables apilados; Esto puede requerir derribar a cualquier suscriptor que use los pseudocables. Elimine la interfaz de túnel lógico redundante y confirme los cambios.
[edit interfaces] user@host# deactivate psnumber user@host# delete rltnumber user@host# commit
Cambie el anclaje del pseudocable desactivado a la nueva interfaz de túnel lógico y confirme.
[edit interfaces] user@host# set psnumber anchor-point lt-fpc/pic/port user@host# commit
Reactive los pseudocables apilados y confirme.
[edit interfaces] user@host# activate psnumber user@host# commit
Configuración de la interfaz lógica de transporte para una interfaz lógica de suscriptor de pseudocable
En este tema se describe cómo configurar una interfaz lógica de transporte de pseudocable. Un dispositivo pseudocable solo puede tener una interfaz lógica de transporte.
Un dispositivo lógico de pseudocable y sus interfaces lógicas de pseudocable relacionadas dependen del estado del dispositivo de interfaz de transporte lógico subyacente, que es la VPN de capa 2 o el circuito de capa 2.
Recomendamos que lo use unit 0 para representar la interfaz lógica de transporte para el dispositivo pseudowire. Los números de unidad distintos de cero representan interfaces lógicas de servicio utilizadas para interfaces de suscriptor de pseudocable.
Para configurar una interfaz lógica de transporte de pseudocable:
Configuración de la señalización de circuito de capa 2 para interfaces lógicas de suscriptor de pseudocable
En este tema se describen los pasos para configurar la señalización de circuito de capa 2 que se utiliza para la compatibilidad con la interfaz lógica del suscriptor de pseudocable. También puede utilizar la señalización VPN de capa 2 para interfaces lógicas de suscriptor pseudowire. Los dos métodos son mutuamente excluyentes; Solo puede usar un método para un pseudocable en particular.
Para configurar la señalización de circuito de capa 2 para interfaces de pseudocable:
Para obtener más información acerca de los circuitos de capa 2, consulte Configuración de interfaces para circuitos de capa 2.
Configuración de la señalización VPN de capa 2 para interfaces lógicas de suscriptor de pseudocable
En este tema se describen los pasos para configurar la señalización VPN de capa 2 que se utiliza para la compatibilidad con la interfaz lógica del suscriptor pseudowire. También puede utilizar la señalización de circuito de capa 2 para interfaces lógicas de suscriptor de pseudocable. Los dos métodos son mutuamente excluyentes; Solo puede usar un método en un pseudocable en particular.
Para configurar la señalización VPN de capa 2 para interfaces pseudowire:
Configuración de la interfaz lógica de servicio para una interfaz lógica de suscriptor de pseudocable
En este tema se describe cómo configurar una interfaz lógica de servicio pseudowire. Las interfaces lógicas de servicio representan los circuitos de conexión para las interfaces lógicas de pseudocable.
Como se describe en la Descripción general de interfaces lógicas de suscriptor de Pseudowire, puede elegir si desea configurar una interfaz lógica de servicio junto con una interfaz lógica de mayor suscriptor, según la necesidad empresarial. En una configuración de borde de banda ancha, la interfaz lógica de suscriptor más alta es el punto de demarcación para suscriptores. Sin embargo, en una configuración de borde empresarial, la interfaz lógica de servicio es el punto de demarcación para los suscriptores empresariales y también sirve como interfaz lógica de suscriptor, por lo que no se configuran explícitamente interfaces lógicas de suscriptor.
Los números de unidad distintos de cero representan interfaces lógicas de servicio utilizadas para interfaces de suscriptor de pseudocable. Se utiliza unit 0 para representar la interfaz lógica de transporte para el dispositivo pseudowire.
Para configurar una interfaz lógica de servicio pseudowire:
Configuración de un PWHT con soporte de tipo VC 11
Puede configurar una interfaz de terminación de cabecera de pseudocable (PWHT) en un enrutador de PE de servicio y configurar ethernet-tcc la encapsulación en la interfaz lógica de transporte del suscriptor de pseudocable (PS).
Cuando utilice esta función, el enrutador de PE de servicio no tiene que admitir tráfico encapsulado TDM/SONET/SDH procedente de clientes del lado de acceso. El pseudocable punto a punto basado en IP, que es un FEC 128 con señalización LDP (circuito virtual [VC] tipo 11), conecta el enrutador de PE de servicio al dispositivo de acceso que está conectado al enrutador CE. Configure el pseudocable para que termine en una instancia VPN de capa 3 o en una tabla IP global.
La función es compatible con cargas IPv4 e IPv6, así como con tráfico de unidifusión y multidifusión.
El enrutador de PE de servicio utiliza mediación ARP para resolver direcciones de capa 2 cuando se utilizan protocolos de resolución diferentes en cualquier extremo de un circuito. Para el enrutador de PE de servicio, el enrutador de CE de acceso aparece como si estuviera conectado localmente. Esta mediación ARP es proporcionada por ARP de proxy en direcciones IPv4 y por Neighbor Discovery Protocol (NDP) en direcciones IPv6. El enrutador de PE de servicio crea una entrada ARP local que corresponde a la dirección IPv4 del enrutador de CE de acceso o agrega la dirección IPv6 del enrutador de CE de acceso a la tabla de vecinos.
Antes de configurar las interfaces y el l2circuit protocolo para el PWHT con compatibilidad de tipo VC 11:
- Configure la sesión de LDP de destino para el circuito de capa 2. Consulte Configurar LDP para circuitos de capa 2 .
- Configure la VPN de capa 3. Consulte Introducción a la configuración de VPN de capa 3.
Cuando habilite family tcc y encapsulation ethernet-tcc en una interfaz PS, tenga en cuenta las siguientes restricciones en la configuración:
- Soporte para un solo pseudocable IP por interfaz física PS
- No hay soporte para una palabra de control; para BFD a través de la interfaz PS; o para una configuración activa-standby, hot-standby o all-active en el pseudocable IP
Para configurar PWHT en el servicio del enrutador de PE con terminación en una instancia VPN de capa 3:
Configuración del soporte de equilibrio de carga para el tráfico de suscriptor
Configure el RLT con los vínculos LT del enrutador en modo activo-activo. Las aplicaciones RLT se pueden mejorar para incluir vínculos de miembros secundarios LT como una propiedad agregada.
A partir de la versión 21.4R1 de Junos OS, ofrecemos soporte de equilibrio de carga para sesiones de suscriptores en la interfaz PS sobre varios vínculos de miembro secundario LT del RLT al mismo tiempo. La propiedad de equilibrio de carga de la interfaz RLT permite que el tráfico del suscriptor en la interfaz PS se disperse y equilibre la carga en diferentes PIC y tarjetas de línea.
Para la interfaz RLT, admite la redundancia del punto de anclaje PS para mejorar el modo LAG. Utilice la enhanced-ip opción o la enhanced-ethernet opción en el nivel de jerarquía [edit chassis network-services] mientras configura PS IFD anclado en RLT.
El hash calculado se utiliza para seleccionar una ruta ECMP y el equilibrio de carga. Puede configurar el equilibrio de carga para el tráfico IPv4 mediante pseudocables Ethernet de capa 2. También puede configurar el equilibrio de carga para pseudocables Ethernet en función de información IP.
Limitaciones
-
La compatibilidad con el equilibrio de carga BNG en la función de interfaz de suscriptor (PS) pseudowire solo se admite para todas las tarjetas de línea basadas en Trio que admitan el modelo de acceso BBE en enrutadores de la serie MX.
-
No puede cambiar el punto de anclaje de PS a menos que deshabilite la interfaz física de PS.
-
Puede producirse una interrupción transitoria del tráfico al agregar o eliminar un miembro de RLT. Agregar o eliminar el comportamiento de vínculo de miembro RLT es similar a cualquier otro comportamiento de interfaz agregada.
-
Las estadísticas de entrada para cada miembro LT no están disponibles. Sin embargo, se dispone de estadísticas agregadas de PS IFL o IFD para ambas direcciones.
-
El modo activo-activo RLT solo se admite para servicios de suscriptor.
A continuación no se admiten para el soporte actual de equilibrio de carga en PS sobre RLT sobre varios vínculos LT secundarios activos
-
Compatibilidad con la interfaz PS sobre RLT en tarjetas de línea MX240, MX480 y MX960.
-
Compatibilidad con CoS de la interfaz de policía jerárquica para vínculos de miembro en modo activo-activo
-
Soporte Ethernet agregado de CoS para el tráfico de suscriptores en la interfaz del servicio de pseudocable (PS)
-
Compatibilidad con IFL de servicio L2 y borde empresarial (L3) para vínculo de miembro en modo activo-activo
-
Soporte de interfaz PS en no redundante
-
Soporte de CoS jerárquico para la redundancia del punto de anclaje de las interfaces lógicas del suscriptor de pseudocable
Para configurar la compatibilidad con equilibrio de carga para el tráfico de suscriptores:
Ver también
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.
ethernet-tcc encapsulación en la interfaz. El pseudocable es VC tipo 11.
l2backhaul-vpn instancia de enrutamiento. La terminación PPPoE y L2TP no se admite cuando se usa la encapsulación VPLS para la interfaz lógica de transporte. La interfaz lógica de servicio admite la encapsulación de conexión cruzada de circuitos (CCC) y disposiciones para terminar la interfaz en circuitos de capa 2 conmutados localmente.
family inet y
family inet6 son compatibles con los servicios de un suscriptor de pseudocable MPLS, así como con una interfaz lógica que no sea de suscriptor.