EN ESTA PÁGINA
Descripción general de interfaces lógicas de suscriptor pseudocable
Descripción general de interfaces lógicas pseudocable de suscriptor de anclaje redundancia
Configuración de una interfaz lógica pseudocable para suscriptores
Configuración de un dispositivo de interfaz lógica pseudocable para suscriptores
Cambiar el punto de anclaje para un dispositivo de interfaz lógica pseudocable para suscriptores
Configuración de la interfaz lógica de transporte para una interfaz lógica de pseudocable suscriptor
Configuración de la señalización vpn de capa 2 para interfaces lógicas de suscriptor pseudocable
Configuración de la interfaz lógica del servicio para una interfaz lógica de pseudocable suscriptor
Configuración de la compatibilidad del equilibrio de carga para el tráfico de suscriptores
Interfaces lógicas pseudocables de suscriptor de MPLS
Descripción general de interfaces lógicas de suscriptor pseudocable
La administración de suscriptores admite la creación de interfaces de suscriptor a través de pseudocables MPLS punto a punto. La capacidad de interfaz de suscriptor 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 gestió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, mientras utilizan un único pseudocable para atender a una gran cantidad de suscriptores de DHCP y PPPoE en la red de servicio.
Las interfaces lógicas de suscriptor pseudocable se admiten en concentradores de puerto modular (MPC) con tarjetas de interfaz modular (MIC) de Ethernet solo. 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 la administración de suscriptores de banda ancha de la capa 2 se admite 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 con los suscriptores PPPoE/DHCP en la red del minorista. Para obtener más información, consulte Elementos de configuración y topología mayoristas de la 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 pseudocable transporta el tráfico encapsulado de Ethernet desde un nodo de acceso (por ejemplo, una DSLAM u otro dispositivo de agregación) al enrutador de la serie MX que aloja los servicios de administración del suscriptor. La terminación del túnel 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 del suscriptor. 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 acicalar en el pseudocable de varias maneras, limitadas solo por la cantidad y los tipos de interfaces que se pueden apilar en el pseudocable. Se especifica un punto de anclaje que identifica la interfaz de túnel lógico que termina el pseudo túnel de cable en el nodo de acceso.
de administración de suscriptores
La Figura 2 muestra la pila de protocolo para una interfaz lógica pseudocable de suscriptor. El pseudocable es un dispositivo virtual que se apilan por encima del punto de anclaje de túnel lógico en la interfaz física (IFD), y es compatible con 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 la versión 18.3R1 de Junos OS, en los enrutadores serie MX con interfaces MPC y MIC, se introduce la compatibilidad con la interfaz de servicio de suscriptor pseudocable mediante túneles lógicos redundantes en VPN de capa 3 y VPN de multidifusión draft-rosen. Anteriormente, las VPN de capa 3 proporcionaban soporte para servicios de suscriptores pseudocables solo a través de 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, La multidifusión independiente de protocolo (PIM), en las interfaces de suscriptor pseudocable, que se termina en la instancia de enrutamiento de enrutamiento virtual de enrutamiento (VRF). Además, hay un aumento en los números de escalabilidad de los dispositivos de interfaz lógica pseudocable que proporciona soporte de resistencia adicional para interfaces de suscriptor pseudocable en interfaces de túnel lógico redundante.
Cuando una interfaz de servicio de suscriptor pseudocable está anclada a un túnel lógico redundante cuya interfaz de miembro (o FPC) no existe, la interfaz de túnel se cae. En tales casos, las interfaces de pseudocable (físicas y lógicas) también deben estar inactivos, pero el estado de la interfaz lógica del suscriptor pseudocable permanece activo, aunque los servicios de circuito de capa 2, como el ping hacia un dispositivo de borde de cliente (CE) desde el lado de servicio de la interfaz de servicio de suscriptor pseudocable, no están disponibles.
Esto se debe a que el lado de transporte de la interfaz lógica del suscriptor pseudocable permanece activo, lo que hace que los servicios estén funcionando.
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 la forma en que se apilan a través de una interfaz física.
A partir de Junos OS versión 16.1R1, family inet y family inet6 se admiten en el lado de los servicios de un suscriptor pseudocable de MPLS, así como en la interfaz lógica que no es suscriptor.
A partir de Junos OS versión 16.1R1, IPFIX en línea se admite en el lado de los servicios de una interfaz lógica de suscriptor 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 pseudocable de suscriptor MPLS.
Antes de la versión 19.1R1 de Junos OS, el único tipo de encapsulación compatible en las interfaces de suscriptor pseudocable 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 al transporte de suscriptor pseudocable y a las interfaces lógicas de servicio. La interfaz lógica de transporte admite la encapsulación Ethernet VPLS y las disposiciones para finalizar la interfaz en la instancia de l2backhaul-vpn enrutamiento. La interfaz lógica de servicio admite la encapsulación de conexión cruzada de circuito (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 circuito de capa 2 y VPN de capa 3. Dado que las interfaces de suscriptor 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 distribuida de denegación de servicio (DDoS) se admite en el lado de los servicios de una interfaz lógica pseudocable de suscriptor 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 los servicios de una interfaz lógica pseudocable de suscriptor 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 pseudocable MPLS.
A partir de junos OS versión 17.3R1 y versiones posteriores, la interfaz de túnel lógico redundante (rlt) redundante subyacente proporciona compatibilidad de redundancia de punto de anclaje de estado para la interfaz lógica de pseudocable suscriptor 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 de cara al núcleo contra la falla del ancla PFE (motor de reenvío de paquetes).
Descripción general de interfaces lógicas pseudocable de suscriptor de anclaje redundancia
En las implementaciones pseudocables de MPLS que utilizan interfaces lógicas de suscriptor pseudocable, un error del motor de reenvío de paquetes que aloja el túnel lógico que ancla esas interfaces lógicas conduce a la pérdida de tráfico y la consiguiente pérdida de sesión de suscriptor.
El motor de reenvío de paquetes no depende del plano de control para la detección de fallas; en su lugar, utiliza un mecanismo de detección de vivaza, con un algoritmo subyacente basado en latidos, para detectar la falla de otros motores de reenvío de paquetes en el sistema. La falla de un motor de reenvío de paquetes también indica la falla del túnel lógico alojado, lo 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, las interfaces lógicas de pseudocable suscriptor se pueden instanciar 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 de suscriptor pseudocable sobre interfaces de túnel lógico redundante es proporcionar redundancia de la ruta de reenvío subyacente.
Antes de la versión 18.3R1 de Junos OS, podría especificar un máximo de 2048 dispositivos de interfaz de túnel lógico redundante de suscriptor pseudocable para un enrutador de la serie MX. A partir de junos OS versión 18.3R1, en enrutadores serie MX con interfaces MPC y MIC, el número de dispositivos de interfaz lógica redundante pseudocable aumentó a 7000 dispositivos para proporcionar soporte adicional de resistencia.
Junos OS versión 17.3 también admite una infraestructura agregada mejorada para que un motor de reenvío de paquetes proporcione redundancia de punto de anclaje. La infraestructura agregada mejorada requiere un mínimo de una interfaz lógica de control que se debe crear en una interfaz de túnel lógico redundante. Las interfaces lógicas de transporte y servicios creadas para la interfaz lógica pseudocable del suscriptor 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 pseudocable redundantes y no redundantes.
Los siguientes eventos tienen que activar la eliminación de la interfaz física de un grupo redundante:
-
Falla de hardware en el concentrador de PIC modular (MPC) o en la tarjeta de interfaces modulares (MIC).
-
Falla del MPC debido a una caída de microkernel.
-
MpC o MIC desconectados administrativamente.
-
Falla de alimentación en un MPC o MIC.
La Figura 3 proporciona los detalles de la interfaz lógica pseudocable del suscriptor apilando sobre una interfaz de túnel lógico redundante.
de túnel lógico redundante
El servicio estático ifl no se apilan sobre el transporte si 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 se produzca un error en el vínculo activo, el tráfico se enruta a través del vínculo de copia de seguridad. Cuando se restablece el vínculo activo, el tráfico se enruta automáticamente al vínculo activo. Esto provoca la pérdida de tráfico y la pérdida de sesión del suscriptor.
Para superar la pérdida de tráfico y sesión, puede configurar la protección de vínculos noevera para interfaces de túnel redundantes mediante la instrucción set interfaces rltX logical-tunnel-options link-protection non-revertivede configuración . 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 continúa reenviando en el vínculo de copia de seguridad. Por lo tanto, no hay pérdida de tráfico ni 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 pseudocable del suscriptor 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 pseudocable suscriptor 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 o la interfaz de túnel lógico (lt) subyacente 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 las sesiones de detección de reenvío bidireccional (BFD) de salto único se extiende al suscriptor pseudocable mediante interfaces de túnel lógico redundante. Para el suscriptor pseudocable a través de interfaces de túnel lógico, las interfaces se anclan a un único concentrador de PIC flexible (FPC), como resultado, la distribución en línea de las sesiones de BFD de un salto único se admite 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 de BFD de salto único se operó en un 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 escalabilidad 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 suscriptores pseudocables mediante interfaces lógicas redundantes es la siguiente:
-
Cuando se agrega una nueva sesión BFD, puede anclarse a un FPC activo o de respaldo.
-
Cuando cualquiera de los FPC fallan o se reinician, todas las sesiones alojadas en esa FPC se desactivan y se activa el nuevo anclaje para la siguiente dirección de distribución disponible. Las sesiones BFD vuelven a aparecer después de instalar las sesiones en el otro intercambio de paquetes FPC y BFD se inicia.
Sin embargo, también es posible que las sesiones en la FPC de respaldo no se den cuando la FPC activa falla según el 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 la FPC activa falla, todas las sesiones de BFD se anclan en la FPC de respaldo. De manera similar, si la FPC de respaldo falla, todas las sesiones BFD se anclan en la FPC activa.
-
El re-anclaje de sesión BFD no se activa cuando la FPC activa está en línea de nuevo.
-
Con el comportamiento no revertivo habilitado, cuando el FPC que estaba activo de nuevo está en línea, no se espera que las sesiones se desvíen. Con el comportamiento revertivo predeterminado, es posible que el estado de reenvío deba actualizarse y, dependiendo de la configuración del tiempo de detección, la sesión puede o no flaquear.
Tome en consideración lo siguiente con el soporte de la distribución en línea de sesiones de BFD de un salto único en suscriptor 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 sesiones de 7000 BGP tardan unos seis minutos en establecerse en las interfaces de suscriptor pseudocable ancladas en interfaces de túnel lógico redundante.
-
Se registra un nuevo mensaje de
JTASK_SCHED_SLIPerror de registro del sistema durante el enrutamiento activo (NSR) sin interrupciones. Este es el comportamiento esperado de NSR con alta escala y puede ignorarse de manera segura, a menos que haya otros problemas, como los flaps de sesión, que requieran tomar medidas.
A partir de la versión 21.4R1 de Junos OS, presentamos soporte CoS para un BNG en interfaz de suscriptor en pseudocable a través de una interfaz de túnel lógico redundante activo-activo (RLT) 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ó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 en la 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 principales y de respaldo, CoS asigna nodos de programación en los vínculos primarios y de respaldo para optimizar el uso de nodos de programación. El tráfico de las interfaces dirigidas al suscriptor se distribuirá a todos los enlaces LT principales cuando se aplique CoS al nivel del suscriptor. Además, el tráfico de un suscriptor determinado siempre se procesa mediante el mismo motor de reenvío de paquetes.
La Figura 4 proporciona los detalles de las interfaces principales y secundarias utilizadas para la jerarquía de programador de cuatro niveles para el acceso de suscriptores. El PPPoE IFL dinámico y el conjunto de IFL dinámicos son nodos secundarios. El conjunto ifl de svlan dinámico y el nodo uifl dinámico o estático son nodos primarios.
del suscriptor
Cuando habilita 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 . [edit interfaces ps1 auto-configure stacked-vlan-ranges dynamic-profile] Cree un perfil dinámico configurando interfaces de destino dinámicas y conjuntos de interfaces en [edit dynamic-profiles].
Este es un ejemplo de la configuración de 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 [edit chassis] nivel de jerarquía, ya que esta función solo funciona en modo IP mejorado.
El modo de múltiples vínculos activo-activo con segmentación utiliza los algoritmos de segmentación para la interfaz de RLT para distribuir clientes entre los diferentes miembros de RLT (pares de piernas primarios y secundarios). La segmentación se puede aplicar para suscriptores dinámicos y conjuntos de interfaces dinámicas. El algoritmo de segmentación pasa por la lista de pseudo IFL asociados con el par de vínculos de miembro y selecciona el primer pseudo IFL que tenga suficiente capacidad según la configuración rebalance-subscriber-granularity.
Cuando la segmentación está habilitada, se asigna al suscriptor una ponderación predeterminada de segmentación 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 la IFL es el peso contado contra el pseudo IFL asignado. Para todos los objetos, excepto el IFLset, la asignación y el peso de débito son los mismos 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 mediante el 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 de débito |
|---|---|---|
| Dvlan |
1 |
1 |
| IpDemux |
1 |
1 |
| PPP |
1 |
1 |
| CONJUNTO IFLset |
32 |
0 |
Configuración de una interfaz lógica pseudocable para suscriptores
Una interfaz lógica de pseudocable suscriptor termina un túnel pseudocable de 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 pseudocable para suscriptores:
Configuración de la cantidad máxima de dispositivos de interfaz lógica pseudocable compatibles con el enrutador
Debe establecer la cantidad máxima de dispositivos de interfaz lógica pseudocable (túneles pseudocables) que el enrutador puede usar para las interfaces lógicas del suscriptor. La configuración del número máximo también define los nombres de interfaz para las interfaces pseudocables. Cuando configure las interfaces posteriormente, debe especificar los nombres de interfaz en el intervalo desde ps0 hasta ps(device-count - 1).
Por ejemplo, si establece la cantidad máxima de dispositivos en 5, puede configurar solo las interfaces ps0, ps1, ps2, ps3 y ps4.
Antes de junos OS versión 17.2R1, podría especificar un máximo de 2048 dispositivos de interfaz lógica pseudocable para un enrutador de la serie MX. A partir de Junos OS versión 17.2R1, en enrutadores serie MX con interfaces MPC y MIC, el escalamiento de los dispositivos de interfaz lógica pseudocable a 7000 dispositivos para proporcionar soporte adicional de resistencia.
De manera similar, antes de la versión 18.3R1 de Junos OS, podría especificar un máximo de 2048 dispositivos de interfaz de túnel lógico redundante (rlt) de suscriptor pseudocable para un enrutador de la serie MX. A partir de junos OS versión 18.3R1, en enrutadores serie MX con interfaces MPC y MIC, el número de dispositivos de interfaz lógica redundante pseudocable aumentó a 7000 dispositivos para proporcionar soporte adicional de resistencia.
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 pseudocable.
El PFE aloja el máximo de dispositivos de interfaz lógica pseudocable ofrece la flexibilidad de configuración necesaria para casos especiales que podrían 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 a escala, asegúrese de completar la cantidad adecuada de PFE para el chasis y de que distribuye los dispositivos de interfaz lógica pseudocable entre los PFE de manera que garantice que ningún PFE se vea abrumado por la carga máxima prevista. Como parte de la planificación de red para su implementación en particular, debe considerar la combinación exacta de la distribución de los dispositivos de interfaz lógica pseudowire 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 implemente un número excesivo de dispositivos pseudocables que no tenga la intención de usar.
Para configurar la cantidad de dispositivos de interfaz lógica pseudocables que desea que admita el enrutador:
Configuración de un dispositivo de interfaz lógica pseudocable para suscriptores
Para configurar un dispositivo de interfaz lógica pseudocable que el enrutador utilice para interfaces lógicas de suscriptor, especifique el túnel lógico que procesa la terminación pseudocable. También puede usar túneles lógicos redundantes para proporcionar redundancia para túneles lógicos miembros. Puede configurar parámetros opcionales adicionales para el dispositivo de interfaz, como el método de etiquetado de VLAN, MTU y soporte ARP gratuito.
Debe crear un túnel lógico para el dispositivo de interfaz lógica pseudocable. Si usa túneles lógicos redundantes, debe crear el túnel redundante.
Para configurar el dispositivo de interfaz de suscriptor pseudocable:
Cambiar el punto de anclaje para un dispositivo de interfaz lógica pseudocable para suscriptores
No puede cambiar dinámicamente un punto de anclaje que tenga dispositivos pseudocables activos apilados sobre él. Debe confirmar ciertos cambios antes de mover el punto de anclaje. Algunos ejemplos de esta situación incluyen 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 la caída de los suscriptores que usen 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 la cantidad máxima de dispositivos permitida.
[edit chassis] user@host# set redundancy-group interface-type redundant-logical-tunnel device-count count
Vincule 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 respaldo activo. El túnel lógico de copia de seguridad 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 copia de seguridad 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 ancla en el 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
Reactivar los pseudocables apilados y confirmar.
[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 la caída de los suscriptores que usen 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 ancla en el 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
Reactivar los pseudocables apilados y confirmar.
[edit interfaces] user@host# activate psnumber user@host# commit
Configuración de la interfaz lógica de transporte para una interfaz lógica de pseudocable suscriptor
En este tema se describe cómo configurar una interfaz lógica de transporte pseudocable. Un dispositivo pseudocable solo puede tener una interfaz lógica de transporte.
Un dispositivo lógico 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 capa 2.
Recomendamos que utilice unit 0 para representar la interfaz lógica de transporte para el dispositivo pseudocable. Los números de unidad no cero representan interfaces lógicas de servicio utilizadas para las interfaces de suscriptor pseudocable.
Para configurar una interfaz lógica de transporte pseudocable:
Configuración de señalización de circuito de capa 2 para interfaces lógicas pseudocables del suscriptor
En este tema se describen los pasos para configurar la señalización de circuitos de capa 2 que se utilizan para la compatibilidad con interfaz lógica de pseudocable suscriptor. También puede usar la señalización de VPN de capa 2 para interfaces lógicas de suscriptor pseudocable. Los dos métodos son excluyentes entre sí; solo se 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 pseudocable
En este tema, se describen los pasos para configurar la señalización de VPN de capa 2 que se utiliza para la compatibilidad con interfaz lógica pseudocable de suscriptor. También puede usar señalización de circuito de capa 2 para interfaces lógicas de suscriptor pseudocable. Los dos métodos son excluyentes entre sí; solo se puede usar un método en un pseudocable en particular.
Para configurar la señalización vpn de capa 2 para interfaces pseudocables:
Configuración de la interfaz lógica del servicio para una interfaz lógica de pseudocable suscriptor
En este tema se describe cómo configurar una interfaz lógica de servicio pseudocable. Las interfaces lógicas de servicio representan los circuitos de adjunto para las interfaces lógicas pseudocables.
Como se describe en la Descripción general de interfaces lógicas de suscriptor pseudocable, puede elegir si desea configurar una interfaz lógica de servicio junto con una interfaz lógica de suscriptor más alto, según las necesidades de la empresa. En una configuración de borde de banda ancha, la interfaz lógica de mayor nivel es el punto de demarcación para los suscriptores. Sin embargo, en una configuración de borde empresarial, la interfaz lógica del servicio es el punto de demarcación para los suscriptores empresariales y también sirve como interfaz lógica del suscriptor, por lo que ninguna interfaz lógica del suscriptor está explícitamente configurada.
Los números de unidad no cero representan interfaces lógicas de servicio utilizadas para las interfaces de suscriptor pseudocable. Use unit 0 para representar la interfaz lógica de transporte para el dispositivo pseudocable.
Para configurar una interfaz lógica de servicio pseudocable:
Configuración de una PWHT con soporte de tipo VC 11
RESUMEN Puede configurar una interfaz de terminación de cabecera pseudocables (PWHT) en un enrutador de PE de servicio y configurar ethernet-tcc la encapsulación en la interfaz lógica de transporte pseudocable suscriptor (PS).
Cuando usa esta función, el enrutador de PE de servicio no tiene que admitir el tráfico encapsulado TDM/SONET/SDH procedente de clientes del lado del acceso. El pseudocable de punto a punto basado en IP, que es un FEC 128 con señal de LDP (circuito virtual (VC) tipo 11), conecta el enrutador de PE de servicio al dispositivo de acceso que está conectado al enrutador CE. Puede configurar el pseudocable para terminar en una instancia de VPN de capa 3 o en una tabla de 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 usa la mediación de ARP para resolver direcciones de capa 2 cuando se utilizan protocolos de resolución diferentes en cada extremo de un circuito. Para el enrutador de PE de servicio, el enrutador CE de acceso aparece como si estuviera conectado localmente. Esta mediación de ARP la proporciona el ARP proxy en direcciones IPv4 y el Protocolo de descubrimiento de vecinos (NDP) en direcciones IPv6. El enrutador de 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 l2circuit protocolo para la PWHT con compatibilidad con 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 active 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 de PS
- No admite una palabra de control; para BFD a través de la interfaz PS; o para configuración de espera activa, de espera activa o totalmente activa en el pseudocable IP
Para configurar PWHT en el enrutador de PE de servicio con terminación en una instancia VPN de capa 3:
Configuración de la compatibilidad del equilibrio de carga para el tráfico de suscriptores
Configure la RLT con los vínculos LT del enrutador en modo activo-activo. Las aplicaciones RLT se pueden mejorar para incluir vínculos de miembro secundario LT como una propiedad agregada.
A partir de la versión 21.4R1 de Junos OS, proporcionamos soporte de equilibrio de carga para las sesiones de suscriptores en la interfaz ps a través de varios vínculos de miembro secundario LT de la RLT al mismo tiempo. La propiedad de equilibrio de carga de la interfaz RLT permite que el tráfico de suscriptor en la interfaz PS se disperse y se equilibre la carga en diferentes PIC y tarjetas de línea.
Para la interfaz RLT admite 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 jerárquico de [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 de Ethernet según la información de IP.
Limitaciones
-
El soporte de equilibrio de carga del BNG en la función de interfaz pseudocable suscriptor (PS) solo es compatible con todas las tarjetas de línea basadas en trío que admiten el modelo de acceso BBE en los enrutadores de la serie MX.
-
No puede cambiar el punto de anclaje PS a menos que desactive la interfaz física de PS.
-
Puede producirse una interrupción transitoria del tráfico cuando se agrega o elimina un miembro de RLT. Agregar o eliminar el comportamiento del vínculo de miembro de 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, las estadísticas de PS IFL o IFD agregadas están disponibles para ambas direcciones.
-
El modo activo-activo RLT solo se admite para los servicios del suscriptor.
A continuación no se admiten para el soporte actual de equilibrio de carga en PS a través de RLT a través de varios vínculos LT activos hijos
-
Soporte de interfaz PS sobre RLT en tarjetas de línea MX240, MX480 y MX960.
-
Compatibilidad con coS de una interfaz de policía jerárquica para vínculos de miembros del modo activo-activo
-
Compatibilidad de Ethernet agregada de CoS para el tráfico de suscriptores en la interfaz de servicio pseudocable (PS)
-
IfL del servicio L2 y soporte de borde empresarial (L3) para el vínculo de miembro en modo activo
-
Compatibilidad con interfaz PS en no redundante
-
Soporte de CoS jerárquico para redundancia de puntos de anclaje de interfaces lógicas de pseudocable suscriptor
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 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 circuito (CCC) y disposiciones para terminar la interfaz en circuitos de capa 2 conmutados localmente.
family inet y
family inet6 se admiten en el lado de los servicios de un suscriptor pseudocable de MPLS, así como en la interfaz lógica que no es suscriptor.