EN ESTA PÁGINA
Descripción general de las interfaces lógicas de suscriptor de Pseudowire
Redundancia de anclaje Descripción general de las interfaces lógicas de suscriptor de suscriptor
Configuración de una interfaz lógica de suscriptor de Pseudowire
Configuración de un dispositivo de interfaz lógica de suscriptor Pseudowire
Cambio del punto de anclaje para 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 de la compatibilidad de equilibrio de carga para el tráfico de suscriptores
Interfaces lógicas de suscriptor de pseudocable MPLS
Descripción general de las interfaces lógicas de suscriptor de Pseudowire
La administración de suscriptores admite la creación de interfaces de suscriptores a través de pseudocables MPLS punto a punto. La capacidad de la interfaz de suscriptor de pseudocable permite a los proveedores de servicios extender un dominio MPLS desde la red de agregación de acceso 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 conmutación por error, el reenrutamiento y el aprovisionamiento uniforme de etiquetas MPLS, a la vez que utilizan un solo pseudocable para dar servicio a un gran número de suscriptores DHCP y PPPoE en la red de servicio.
Las interfaces lógicas de suscriptor de pseudocable solo son compatibles con concentradores de puertos modulares (MPC) con tarjetas de interfaz modular Ethernet (MIC). La terminación PPPoE y L2TP no se admite cuando se utiliza la encapsulación VPLS y la autenticación DHCP para la interfaz lógica de transporte. Sin embargo, la funcionalidad mayorista 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 la 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 mayorista de capa 2 de administración de suscriptores de banda ancha.
El pseudocable es un túnel que es un circuito VPN de capa 2 o de capa 2 basado en MPLS. El túnel de pseudocable transporta tráfico encapsulado de 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 varios pseudocables por DSLAM y luego proporcionar soporte para un gran número 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, limitado solo por el número y los tipos de interfaces que se pueden apilar en el pseudocable. Especifique un punto de anclaje, que 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 de pseudocable. 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 admite la familia de protocolos (IPv4, IPv6 o PPPoE).
A partir de Junos OS versión 18.3R1, en los enrutadores serie MX con interfaces MPC y MIC, la compatibilidad con la interfaz de servicio de suscriptor de pseudocable a través de túneles lógicos redundantes se introduce en las VPN de capa 3 y las VPN de multidifusión de borrador. Anteriormente, las VPN de capa 3 proporcionaban soporte para servicios de suscriptor de pseudocable solo a través de interfaces de túnel lógico, y estas interfaces usaban protocolos de enrutamiento de unidifusión. como OSPF o BGP. Con esta compatibilidad, puede aprovisionar un protocolo de enrutamiento de multidifusión, Protocol Independent Multicast (PIM), en las interfaces de suscriptor de pseudocable, que finaliza en la instancia de enrutamiento de enrutamiento y reenvío virtual (VRF). Además, hay un aumento en los números de escala de los dispositivos de interfaz lógica de pseudocable que proporciona soporte de resistencia adicional para interfaces de suscriptor de pseudocable en interfaces de túnel lógico redundantes.
Cuando una interfaz de servicio de suscriptor de pseudocable está anclada a un túnel lógico redundante cuya interfaz miembro (o FPC) no existe, la interfaz de túnel deja de funcionar. En tales casos, las interfaces de pseudocable (físicas y lógicas) también deberían 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 el ping hacia un dispositivo de borde del cliente (CE) desde el lado de 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 de pseudocable permanece activo, lo que hace que los servicios estén activos.
de protocolo de interfaz de suscriptor de pseudocable
La configuración de pseudocable es transparente para las aplicaciones de administración de suscriptores y no afecta a las cargas de paquetes que se usan 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, y family inet6 se admiten en el lado de servicios de un suscriptor de pseudocable MPLS, family inet así como en una interfaz lógica de no suscriptor.
A partir de Junos OS versión 16.1R1, Inline IPFIX se admite en el lado de los 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 se admite 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 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 VLAN VPLS
A partir de Junos OS versión 19.1R1, se agregan encapsulaciones adicionales a las interfaces lógicas de servicio y transporte de suscriptores de pseudocable. La interfaz lógica de transporte admite la encapsulación de Ethernet VPLS y provisiones 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 provisiones para terminar la interfaz en circuitos de capa 2 conmutados localmente.
Con el soporte de tipos de encapsulación adicionales, puede beneficiarse de la demux de una l2backhaul VPN en múltiples servicios VPN, como el circuito de capa 2 y la VPN de capa 3. Dado que las interfaces de suscriptor de pseudocable están ancladas en 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, la protección de denegación de servicio distribuido (DDoS) se admite 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, Policer y Filter se admiten 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 servicios de una interfaz lógica de suscriptor MPLS.
A partir de Junos OS versión 17.3R1 y versiones posteriores, la interfaz de túnel lógico (rlt) redundante subyacente en modo de copia de seguridad activa proporciona compatibilidad con redundancia de punto de anclaje con estado para la interfaz lógica del suscriptor de pseudocable. Esta redundancia protege el acceso y el vínculo orientado hacia el núcleo contra fallas del ancla PFE (motor de reenvío de paquetes).
Redundancia de anclaje Descripción general de las interfaces lógicas de suscriptor de suscriptor
En las implementaciones de pseudocables MPLS que usan interfaces lógicas de suscriptor de pseudocable, el error del motor de reenvío de paquetes que hospeda el túnel lógico que ancla esas interfaces lógicas provoca la pérdida de tráfico y la consiguiente pérdida de la sesión del suscriptor.
El motor de reenvío de paquetes no depende del 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 la falla 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, que en última instancia conduce a la pérdida de 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.
A partir de la versión 17.3 de Junos OS en adelante, se pueden crear instancias de interfaces lógicas de suscriptor de pseudocable a través de una interfaz de túnel lógico redundante (rlt) subyacente en modo de copia de seguridad activa. Esto se suma a la instalación de pseudocables en una sola interfaz de túnel lógico. La ventaja más notable de implementar la interfaz lógica del suscriptor de pseudocable sobre las interfaces de túnel lógico redundantes es proporcionar redundancia de la ruta de reenvío subyacente.
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 de suscriptor para un enrutador serie MX. A partir de Junos OS versión 18.3R1, en los enrutadores serie MX con interfaces MPC y MIC, el número de escalado de dispositivos de interfaz lógica redundantes de pseudocable ha aumentado a 7000 dispositivos para proporcionar soporte de resistencia adicional.
Junos OS versión 17.3 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. Las interfaces lógicas de transporte y 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 de pseudocable redundantes y no redundantes.
Los eventos siguientes tienen que desencadenar la eliminación de la interfaz física de un grupo redundante:
-
Error de hardware en el concentrador PIC modular (MPC) o en la tarjeta de interfaces modulares (MIC).
-
Error de MPC debido a un bloqueo del microkernel.
-
MPC o MIC desconectados administrativamente.
-
Fallo de alimentación en un MPC o un MIC.
La figura 3 proporciona los detalles del apilamiento de la interfaz lógica del suscriptor de pseudocable 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 utiliza RLT.
De forma predeterminada, la protección de vínculos para interfaces de túnel redundantes es revertiva. En caso de que el vínculo activo falle, el tráfico se enruta a través del enlace de respaldo. Cuando se restablece el vínculo activo, el tráfico se enruta automáticamente de vuelta al vínculo activo. Esto provoca la pérdida de tráfico y de la sesión del suscriptor.
Para superar la pérdida de tráfico y sesión, puede configurar la protección de vínculos no revertivos 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 continúa reenviándose en el vínculo de copia de seguridad. Por lo tanto, no hay pérdida de tráfico ni pérdida de sesión de suscriptor. También puede cambiar manualmente el tráfico del vínculo de copia de seguridad 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 de pseudocable 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 redundante (rlt) subyacente ni la interfaz de túnel lógico subyacente (lt) cuando un pseudocable está anclado en esa interfaz. Si desea deshabilitar la interfaz subyacente, primero debe desactivar el pseudocable.
A partir de Junos OS versión 18.4R1, la compatibilidad con 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 pseudocable 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 están ancladas en un único concentrador 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 pseudocable, 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 sesiones BFD de un solo salto se operaba en modo centralizado antes de Junos OS versión 18.4R1.
Con el soporte para la distribución en línea de sesiones BFD de un solo salto a través de interfaces lógicas redundantes de pseudocable, hay una ventaja de escalado de hasta 2000 sesiones 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 de BFD para el suscriptor de pseudocable a través de interfaces lógicas redundantes es la siguiente:
-
Cuando se agrega una nueva sesión de BFD, se puede anclar en un FPC activo o de respaldo.
-
Cuando se produce un error o se reinicia cualquiera de los FPC, todas las sesiones alojadas en ese FPC dejan de funcionar y se activa el reanclaje para la siguiente dirección de distribución disponible. Las sesiones BFD vuelven a aparecer después de instalar las sesiones en el otro FPC y se inicia el intercambio de paquetes BFD.
Sin embargo, también es posible que las sesiones de la FPC de copia de seguridad no dejen de funcionar cuando falla la FPC activa, dependiendo 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 en la FPC de copia de seguridad. Del mismo modo, si se produce un error en la FPC de copia de seguridad, todas las sesiones de BFD se anclan en la FPC activa.
-
El reanclaje de la sesión BFD no se activa cuando el FPC activo vuelve a estar en línea.
-
Con el comportamiento no revertivo habilitado, cuando el FPC previamente activo vuelva a estar en línea, no se espera que las sesiones dejen de funcionar. Con el comportamiento revertivo 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 o no oscilar.
Tenga en cuenta lo siguiente con el soporte de la distribución en línea de sesiones BFD de un solo salto en suscriptores de pseudocable a través de interfaces de túnel lógico:
-
En FPC tipo MPC 7e, con la activación de la instancia de enrutamiento 7000, las 7000 sesiones BGP 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
JTASK_SCHED_SLIPde error de registro del sistema - - durante el enrutamiento activo sin interrupciones (NSR). Este es el comportamiento esperado de NSR con alta escala y se puede ignorar con seguridad, a menos que haya otros problemas, como colgajos de sesión, que requieran que se tomen medidas.
A partir de la versión 21.4R1 de Junos OS, introdujimos la compatibilidad con CoS para un BNG en la interfaz de suscriptor en pseudocable a través de una interfaz de túnel lógico redundante (RLT) activo-activo para aplicaciones de suscriptor como DHCP y PPPoE. Esta propiedad CoS se consigue proporcionando los nodos de programación para los vínculos de túnel lógico. 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 del 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, 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 para las interfaces de destino del suscriptor se distribuirá a todos los enlaces LT principales cuando se aplique CoS a nivel del suscriptor. Además, el tráfico de cualquier suscriptor dado siempre es procesado por el mismo motor de reenvío de paquetes.
La figura 4 proporciona los detalles de las interfaces primaria y secundaria usadas para la jerarquía de programador de cuatro niveles para el acceso de suscriptores. El IFL PPPoE dinámico y el conjunto IFL dinámico son nodos secundarios. El conjunto IFL de svlan dinámico y el nodo uifl dinámico o estático son nodos primarios.
de suscriptores
Cuando habilite la segmentación en un nodo, debe habilitar la segmentación para todos los nodos secundarios para que CoS funcione correctamente. Para habilitar los nodos secundarios, configure el perfil dinámico en el [edit interfaces ps1 auto-configure stacked-vlan-ranges dynamic-profile]. Cree un perfil dinámico configurando interfaces dinámicas específicas y conjuntos de interfaces en [edit dynamic-profiles].
Este es un ejemplo de la configuración de perfiles dinámicos:
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 característica solo funciona en modo [edit chassis] IP mejorado.
El modo de vínculo múltiple activo-activo con segmentación utiliza los algoritmos de segmentación para la interfaz RLT para distribuir los clientes entre los diferentes miembros de RLT (pares de patas primarios/secundarios). La segmentación se puede aplicar a suscriptores dinámicos y conjuntos de interfaces dinámicas. El algoritmo de segmentación recorre la lista de pseudo IFLs asociados con el par de vínculos miembro y selecciona el primer pseudo IFL que tiene suficiente capacidad en función del rebalance-subscriber-granularityarchivo .
Cuando la segmentación está habilitada, al suscriptor se le asigna una ponderación de segmentación predeterminada en función del 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, el peso de asignación y débito es el mismo y se puede modificar a través del perfil de cliente. En el caso del IFLset, solo se puede modificar el atributo de peso de asignación a través del perfil de 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 deudor |
|---|---|---|
| Dvlan |
1 |
1 |
| IpDemux |
1 |
1 |
| PPP |
1 |
1 |
| IFLset |
32 |
0 |
Configuración de una interfaz lógica de suscriptor de Pseudowire
Una interfaz lógica de suscriptor de pseudocable termina 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 de pseudocable:
Configuración del número máximo de dispositivos de interfaz lógica Pseudowire admitidos en el enrutador
Debe establecer el número máximo de dispositivos de interfaz lógica de pseudocable (túneles de pseudocable) que el enrutador puede utilizar para las interfaces lógicas de suscriptor. Al establecer el número máximo, también se definen los nombres de interfaz para las interfaces de pseudocable. Cuando configure posteriormente las interfaces, debe especificar los nombres de interfaz en el intervalo de ps0 a ps(device-count - 1).
Por ejemplo, si establece el número máximo de dispositivos en 5, solo puede configurar interfaces ps0, ps1, ps2, ps3 y ps4.
Antes de Junos OS versión 17.2R1, podía especificar un máximo de 2048 dispositivos de interfaz lógica pseudowire para un enrutador serie MX. A partir de Junos OS versión 17.2R1, en los enrutadores serie MX con interfaces MPC y MIC, el número de escalado de dispositivos de interfaz lógica pseudowire ha aumentado 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 para un enrutador serie MX. A partir de Junos OS versión 18.3R1, en los enrutadores serie MX con interfaces MPC y MIC, el número de escalado de dispositivos de interfaz lógica redundantes de pseudocable ha aumentado a 7000 dispositivos para proporcionar soporte de resistencia adicional.
A partir de Junos OS versión 20.4R1, 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 de pseudocables.
El PFE que aloja la cantidad máxima 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 PFE disponibles a medida que configura servicios adicionales en los puertos de dispositivos de interfaz lógica pseudocable. 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 de pseudocable entre los PFE de tal manera que garantice que ningún PFE se vea abrumado por la carga máxima prevista. 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 de pseudocable configurado consume recursos de grupos compartidos incluso cuando el dispositivo no tiene interfaces lógicas de suscriptor activas. Para conservar recursos, no despliegue un número excesivo de dispositivos de pseudocable que no tenga intención de utilizar.
Para configurar el número de dispositivos de interfaz lógica de pseudocable que desea que admita el enrutador:
Configuración de un dispositivo de interfaz lógica de suscriptor Pseudowire
Para configurar un dispositivo de interfaz lógica de pseudocable que el enrutador utiliza para las interfaces lógicas de suscriptor, especifique el túnel lógico que procesa la terminación del pseudocable. También puede utilizar túneles lógicos redundantes para proporcionar redundancia a los túneles lógicos miembros. Puede configurar parámetros opcionales adicionales para el dispositivo de interfaz, como el método de etiquetado VLAN, MTU y compatibilidad con ARP gratuita.
Debe crear un túnel lógico para el dispositivo de interfaz lógica pseudocable. Si utiliza túneles lógicos redundantes, debe crear el túnel redundante.
Para configurar el dispositivo de interfaz de suscriptor pseudowire:
Cambio del punto de anclaje para un dispositivo de interfaz lógica de suscriptor de pseudocable
No puede cambiar dinámicamente un punto de anclaje que tenga dispositivos de pseudocable 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, 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 estar en una FPC diferente a la del túnel lógico activo. Por ejemplo, si el túnel activo está en FPC 3, entonces el túnel de respaldo debe estar en un 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:
Desactive 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 pseudocables. 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 el circuito VPN de capa 2 o de capa 2.
Se recomienda utilizarla unit 0 para representar la interfaz lógica de transporte del dispositivo de pseudocable. 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 pseudocables:
Configuración de la señalización de circuitos 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 utilizada 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 suscriptores de pseudocables. 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 circuitos de capa 2 para interfaces de pseudocables:
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 utilizada 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 pseudocables. 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 de pseudocable:
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 de pseudocable. Las interfaces lógicas de servicio representan los circuitos de conexión para las interfaces lógicas de pseudocables.
Como se describe en la Descripción general de las interfaces lógicas del suscriptor de Pseudowire, puede elegir si desea configurar una interfaz lógica de servicio junto con una interfaz lógica de suscriptor superior, según las necesidades del negocio. En una configuración de borde de banda ancha, la interfaz lógica del suscriptor superior es el punto de demarcación para los 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 del dispositivo de pseudocable.
Para configurar una interfaz lógica de servicio de pseudocable:
Configuración de una PWHT con soporte de tipo VC 11
RESUMEN 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 de suscriptor de pseudocable (PS).
Cuando se utiliza esta función, el enrutador PE de servicio no tiene que admitir tráfico encapsulado en 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ñal LDP (circuito virtual (VC) tipo 11), conecta el enrutador PE de servicio al dispositivo de acceso que está conectado al enrutador CE. Configure el pseudocable para terminar en una instancia de VPN de capa 3 o en una tabla IP global.
La función admite cargas IPv4 e IPv6 y tráfico de unidifusión y multidifusión.
El enrutador de PE de servicio utiliza la mediación ARP para resolver direcciones de capa 2 cuando se utilizan protocolos de resolución diferentes en cada extremo de un circuito. Para el enrutador PE de servicio, el enrutador CE de acceso aparece como si estuviera conectado localmente. Esta mediación ARP es proporcionada por ARP de proxy en direcciones IPv4 y por Protocolo de descubrimiento de vecinos (NDP) en direcciones IPv6. El enrutador PE de servicio crea una entrada ARP local que corresponde a la dirección IPv4 del enrutador CE de acceso o agrega la dirección IPv6 del enrutador CE de acceso a la tabla de vecinos.
Antes de configurar las interfaces y el protocolo para el l2circuit PWHT con soporte de tipo VC 11:
- Configure la sesión LDP de destino para el circuito de capa 2. Consulte Configuración de 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:
- Compatibilidad con un solo pseudocable IP por interfaz física PS
- No hay soporte para una palabra de control; para BFD sobre la interfaz PS; o para la configuración en espera activa, espera activa o totalmente activa en el pseudocable IP
Para configurar PWHT en el enrutador PE de servicio con terminación en una instancia de VPN de capa 3:
Configuración de la compatibilidad de equilibrio de carga para el tráfico de suscriptores
Configure el RLT con los vínculos LT del enrutador en modo activo-activo. Las aplicaciones RLT se pueden mejorar para incluir enlaces de miembros secundarios LT como una propiedad agregada.
A partir de Junos OS versión 21.4R1, proporcionamos compatibilidad de equilibrio de carga para sesiones de suscriptor en la interfaz PS a través de varios vínculos de miembro secundario LT de RLT al mismo tiempo. La propiedad de equilibrio de carga de la interfaz RLT permite que el tráfico de suscriptores 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 opción o la enhanced-ip 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 equilibrar la carga. Puede configurar el equilibrio de carga para el tráfico IPv4 a través de pseudocables Ethernet de capa 2. También puede configurar el equilibrio de carga para pseudocables Ethernet en función de la información IP.
Limitaciones
-
La compatibilidad con el equilibrio de carga BNG en la función de interfaz de suscriptor pseudocable (PS) solo se admite para todas las tarjetas de línea basadas en trío que admitan el modelo de acceso BBE en los enrutadores de la serie MX.
-
No puede cambiar el punto de anclaje PS a menos que deshabilite la interfaz física de PS.
-
Puede producirse una interrupción transitoria del tráfico al agregar o quitar un miembro RLT. Agregar o eliminar el comportamiento del vínculo de miembro RLT es similar a cualquier otro comportamiento de interfaz agregado.
-
Las estadísticas de ingreso de cada miembro de LT no están disponibles. Sin embargo, las estadísticas agregadas de PS IFL o IFD están disponibles para ambas direcciones.
-
El modo activo-activo RLT solo se admite para los servicios de suscriptor.
Los siguientes no son compatibles con la compatibilidad actual de equilibrio de carga en PS sobre RLT sobre varios vínculos LT secundarios activos
-
Compatibilidad con la interfaz PS a través de RLT en tarjetas de línea MX240, MX480 y MX960.
-
Compatibilidad de CoS con la interfaz de policía jerárquica para vínculos de miembro del modo activo-activo
-
Soporte Ethernet agregado de CoS para el tráfico de suscriptores en la interfaz de servicio pseudocable (PS)
-
Compatibilidad con IFL de servicio L2 y borde empresarial (L3) para el vínculo de miembro del modo activo-activo
-
Soporte de interfaz PS en no redundantes
-
Compatibilidad con CoS jerárquica para la redundancia del punto de anclaje de interfaces lógicas de suscriptor de pseudocable
Para configurar la compatibilidad con el equilibrio de carga para el tráfico de suscriptores:
Ver también
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 utiliza 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 provisiones para terminar la interfaz en circuitos de capa 2 conmutados localmente.
family inet6 se admiten en el lado de servicios de un suscriptor de pseudocable MPLS,
family inet así como en una interfaz lógica de no suscriptor.