Redundancia de suscriptor de M:N en BNG
Descripción general de la redundancia de suscriptores de M:N en BNG
A partir de Junos OS versión 19.2R1, puede configurar la redundancia del suscriptor de M:N como un mecanismo para mejorar la resistencia de la red mediante la protección de los suscriptores de una variedad de fallas de software y hardware. Esta protección está disponible en una topología de red típica, como la que se muestra en la Figura 1.
:N
Un error en cualquiera de las ubicaciones enumeradas en la tabla 1 puede hacer que un BNG principal conmute por error a un BNG de respaldo.
Tarjeta de línea de acceso |
Vínculo frontal |
Enlace de acceso |
Red de acceso parcial |
Chasis |
Red central parcial |
Puede utilizar la redundancia M:N para proteger los siguientes tipos de suscriptores:
Suscriptores dinámicos de DHCPv4 y DHCPv6 en VLAN estáticas 1:1 a través de IPoE; Redundancia VRRP
suscriptores estáticos basados en VLAN; Redundancia VRRP
suscriptores estáticos basados en demux IP; Redundancia VRRP
suscriptores de DHCPv4 y DHCPv6 en VLAN dinámicas o estáticas a través de IP/MPLS; Redundancia de pseudocable (Esta compatibilidad se agrega en Junos OS versión 20.1R1.)
- Beneficios de la redundancia de suscriptores de M:N en BNG
- Fundamentos de la redundancia M:N
- Sesiones de suscriptor y modo de espera en caliente
- Redundancia M:N mediante el Protocolo de redundancia de enrutador virtual (VRRP)
- Conmutación por error de VRRP y sincronización de reversión
- Redundancia M:N mediante redundancia de pseudocable
- Suscriptores estáticos y redundancia M:N
- Convergencia y redundancia de suscriptor M:N
Beneficios de la redundancia de suscriptores de M:N en BNG
Proporciona una redundancia ligera de suscriptor de capa de aplicación. Puede utilizarlo para realizar copias de seguridad de varios grupos de suscriptores diferentes en varios chasis BNG diferentes. Cada grupo de suscriptores tiene una copia de seguridad en modo de espera activa.
Varios BNG actúan como BNG activo para uno o más grupos redundancia suscriptor y como BNG de respaldo para otros grupos redundancia suscriptor al mismo tiempo.
La redundancia M:N es complementaria a la redundancia del chasis virtual de la serie MX. La redundancia M:N es adecuada para entornos distribuidos. Chasis virtual de la serie MX requiere un chasis dedicado para la redundancia. Proporciona redundancia 1:1 y se usa con mayor frecuencia en despliegues centralizados.
Puede habilitar o deshabilitar la redundancia M:N para los suscriptores que están activos. Si quita la configuración de redundancia, los suscriptores que tenían la configuración permanecerán intactos tanto en el BNG principal como en el de respaldo.
Puede implementar la redundancia M:N con una única interfaz de núcleo. Esto significa que varios grupos de redundancia de suscriptores pueden compartir una conectividad central común.
Los suscriptores con redundancia M:N pueden coexistir con suscriptores sin redundancia. Esto significa que no tiene que tener BNG dedicados a la redundancia del suscriptor.
Puede configurar suscriptores de redundancia M:N durante el tiempo de ejecución, incluso después de que los suscriptores estén activos. Esto es útil para las actualizaciones de software, ya que puede migrar suscriptores a BNG de respaldo y luego actualizar el software.
Fundamentos de la redundancia M:N
Para simplificar, la mayor parte de la explicación de la redundancia M:N en esta documentación refleja el uso de suscriptores DHCP en VLAN estáticas.
La base de la redundancia M:N es que se puede realizar una copia de seguridad de varios grupos de suscriptores (M) en un chasis BNG determinado en varios (N) destinos de chasis diferentes. Nos referimos a estos grupos como grupos de redundancia de suscriptor.
Un grupo suscriptor está formado por todos los suscriptores que cumplen los siguientes criterios:
(VLAN estáticas) Los suscriptores pertenecen a una VLAN estática determinada y utilizan la misma interfaz de acceso lógico, como ge-1/0/10/1. Un dispositivo de acceso, como un conmutador, DSLAM u OLT, agrega a los suscriptores en la VLAN común.
(VLAN dinámicas) Los suscriptores pertenecen a la misma VLAN dinámica y utilizan la misma interfaz de acceso físico, como ge-1/0/0.
(demux de IP estática) Todos los suscriptores tienen una dirección IP de origen que coincide con la subred configurada.
Cuando se configura la redundancia para un grupo de suscriptores, se convierte en un grupo de redundancia de suscriptor. Un grupo de redundancia de suscriptor determinado solo utiliza un BNG a la vez. Llamamos a este BNG el primario. Para cada grupo de redundancia de suscriptor, solo uno de los otros BNG actúa como respaldo en modo de espera activa. Cuando se produce uno de los errores enumerados en la tabla 1 para el BNG principal, se conmuta por error al BNG de respaldo adecuado para el grupo de redundancia afectado. Este BNG de respaldo es ahora el nuevo BNG principal para ese grupo. Todas las sesiones de suscriptor activas para ese grupo de redundancia de suscriptor se mantienen a través de la tolerancia a fallos al BNG de respaldo.
La Figura 2 es un diagrama conceptual que ilustra las relaciones primarias/de respaldo de M:N. Muestra cinco BNG en una topología principal/de respaldo M:N donde cada BNG tiene una relación con todos los demás BNG. Si BNG 1 es el principal, puede configurar BNG 2, 3, 4 y 5 como BNG de respaldo para diferentes grupos de redundancia de suscriptor. Si BNG 2 es la principal, puede configurar BNG 1, 3, 4 y 5 como BNG de respaldo, y así sucesivamente.
:N
Para la redundancia M:N, es importante entender que puede configurar:
Solo un BNG de respaldo para cada grupo de redundancia de suscriptor.
Un BNG debe ser el enrutador de respaldo para más de un grupo de redundancia.
Esto significa que un BNG dado puede ser simultáneamente el enrutador principal para muchos grupos de redundancia y el enrutador de respaldo para muchos grupos de redundancia diferentes. Cuando se produce un error en un BNG principal, se conmuta por error al enrutador de reserva que configure para cada uno de sus grupos de redundancia. Las sesiones de suscriptor para todos los grupos de redundancia en el BNG principal se mantienen en todos los BNG de respaldo que se convierten en nuevos principales para los grupos.
La Figura 3 muestra una configuración sencilla de grupos de suscriptor y grupos de redundancia suscriptor en tres agentes de retransmisión DHCP alojados en tres BNG. Los BNG pueden estar directamente conectados entre sí o a través de las redes centrales o de acceso.
El agente de retransmisión RA1 está configurado para suscriptor grupos redundancia, SRG 1 y SRG 2, y suscriptor grupo SG A.
El agente de retransmisión RA2 está configurado para SRG 2 y SRG 3.
El agente de retransmisión RA3 está configurado para SRG 1, SRG 3 y SG B.
Otra forma de ver esto es que:
SRG 1 puede estar activo o respaldado en RA1 y RA3.
SRG 2 puede estar activo o respaldado en RA1 y RA2.
SRG 3 puede estar activo o respaldado en RA2 y RA3.
No se realiza una copia de seguridad de SG A y SG B.
Ahora considere la Figura 4, que muestra la misma topología, pero indica qué BNG es principal y cuál es la copia de seguridad para cada grupo de redundancia. El BNG que aloja AR 1 es el BNG principal para SRG 1 y SRG 2.
error
Si se produce un error en este BNG, se conmuta por error a un BNG de respaldo diferente para SRG 1 y SRG 2, como se muestra en la Figura 5.
error
En el caso de SRG 1, conmuta por error al BNG que hospeda el AR 3. El AR 3 BNG se convierte en el nuevo principal para SRG 1.
En el caso de SRG 2, conmuta por error al BNG que hospeda AR 2. El AR 2 BNG se convierte en el nuevo principal para SRG 2.
La falla no tiene ningún efecto en SRG 3.
Sesiones de suscriptor y modo de espera en caliente
Cada BNG de respaldo está en modo de espera activa para su BNG principal correspondiente para cada suscriptor grupo redundancia de la copia de seguridad. Esto significa que el BNG de respaldo está listo para tomar el relevo del BNG principal de inmediato y sin interrupciones cuando se produce una tolerancia a fallos. Los siguientes comportamientos del BNG principal y de respaldo habilitan el modo de espera activa para que funcione.
Los enlaces de suscriptor y el estado de suscriptor se reflejan sincrónicamente en el BNG de respaldo, al igual que el ARP del BNG principal y la información de detección de vecinos. Cada suscriptor aparece en el BNG de respaldo y su estado es Activo. Dado que los suscriptores están activos simultáneamente en la BNG principal y de respaldo, la BNG de respaldo no realiza ningún procesamiento de suscriptor durante un evento de tolerancia a fallos.
Cada sesión de suscriptor se trata como una sesión continua antes, durante y después de una conmutación por tolerancia a fallos. Durante el inicio de sesión inicial del suscriptor, los BNG principales y de respaldo envían un mensaje de inicio de contabilidad de RADIUS o un mensaje CCR-I de OCS para el suscriptor.
Durante la conmutación por tolerancia a fallos, el principal con errores envía un mensaje Accounting-Stop o CCR-T en la medida de lo posible. Por ejemplo, envía el mensaje si el vínculo frontal sigue activo o si el chasis sigue ejecutándose. Si el vínculo frontal está inactivo o todo el chasis está inactivo, el principal que falla no puede enviar un mensaje de detención contable o CCR-T.
Cuando el BNG de respaldo se convierte en principal, no envía un mensaje de inicio de contabilidad o CCR-I porque los suscriptores están activos en la tolerancia a fallos. Las estadísticas contables se incrementan a partir del nuevo principal.
Durante el inicio de sesión inicial del suscriptor, el BNG agrega rutas de suscriptor a su tabla de enrutamiento y propaga las rutas a la red central. Cuando el BNG principal falla, no elimina las rutas de los suscriptores de su propia tabla de enrutamiento y no retira las rutas de la red principal. Después de la tolerancia a fallos, el principal con errores no agrega ni propaga ninguna ruta. Como alternativa, puede configurar las rutas de los suscriptores para que se anuncien o se retiren del núcleo en función de la función principal de BNG, de modo que no haya pérdida de tráfico como resultado de la tolerancia a fallos.
La sincronización de estado solo se aplica al estado del suscriptor. El estado del servicio no está sincronizado. Dependiendo de la configuración de sus servicios, el BNG puede asociar servicios para los suscriptores activos y de respaldo. Como alternativa, los servicios se pueden volver a conectar después de la tolerancia a fallos en el nuevo BNG activo.
La redundancia del suscriptor M:N no sincroniza las estadísticas de contabilidad del BNG principal al BNG de respaldo. Hace un intento de máximo esfuerzo para comunicar información contable a un servidor de contabilidad. Cuando se produce una tolerancia a fallos, las estadísticas de contabilidad comienzan a incrementarse desde la nueva principal y dejan de incrementarse desde la principal con errores. Según la gravedad del error, las conmutaciones por error pueden dar lugar a la pérdida de información contable.
Redundancia M:N mediante el Protocolo de redundancia de enrutador virtual (VRRP)
Puede utilizar VRRP para proporcionar redundancia M:N en una red. La redundancia M:N utiliza VRRP para proporcionar una dirección IP virtual y una dirección MAC compartidas por dos BNG en un grupo VRRP (a veces denominado instancia VRRP). El grupo VRRP corresponde a un único enrutador virtual. Configure el grupo VRRP en la interfaz de acceso correspondiente en cada BNG. La interfaz de acceso es la interfaz lógica orientada al suscriptor que está conectada a la red de acceso.
La dirección IP virtual se convierte en la dirección de puerta de enlace predeterminada para los BNG del grupo. Solo el BNG que actúa como principal envía anuncios VRRP o responde al tráfico destinado a la dirección del enrutador virtual. El BNG anuncia únicamente la dirección de puerta de enlace virtual y la dirección MAC virtual a los hosts de los suscriptores. Dado que ambos enrutadores del grupo comparten la misma dirección de puerta de enlace virtual, no es necesaria ninguna interacción con los hosts y la tolerancia a fallos de la principal a la copia de seguridad se produce en pocos segundos.
La solución VRRP para la redundancia M:N está dirigida a un modelo de acceso de suscriptores N:1 que utiliza interfaces lógicas subyacentes estáticas.
Para obtener información detallada sobre cómo funciona VRRP en general, consulte Descripción de VRRP y temas relacionados en la Guía del usuario de alta disponibilidad.
Puede configurar diferentes prioridades para los dos enrutadores de un grupo VRRP a fin de determinar qué enrutador elige el grupo como el principal:
El enrutador con la prioridad más alta para el grupo es el principal. Cuanto mayor sea el número, mayor será la prioridad. Por ejemplo, entre dos miembros del grupo con prioridades de 100 y 50, respectivamente, el enrutador con prioridad 100 es el principal.
Cuando se produce un error en el principal, el protocolo elige el enrutador de respaldo como el nuevo principal. La nueva principal asume la propiedad de las direcciones IP y MAC virtuales. La conmutación por error no afecta al tráfico de datos.
-
Cuando la principal original vuelve a estar en línea, el protocolo determina que tiene una prioridad más alta que la principal actual (copia de seguridad anterior). A continuación, el principal original reanuda la función principal sin que ello afecte al tráfico de datos.
Nota:Cuando se utiliza VRRP para la redundancia del suscriptor M:N, la cantidad de grupos de redundancia del suscriptor se limita a la cantidad de sesiones VRRP admitidas en el dispositivo. Para la pila dual, esta función requiere sesiones VRRP independientes para IPv4 e IPv6; por lo tanto, la cantidad de grupos de redundancia de suscriptores se reduce a la mitad.
En la figura 6 , se muestra un ejemplo de topología con dos BNG y la configuración de las interfaces correspondientes en cada enrutador:
Las dos interfaces lógicas se encuentran en la misma VLAN (1).
Las direcciones de interfaz se encuentran en la misma subred (203.0.113.1/24 y 203.0.113.2/24).
Las direcciones de interfaz están en el mismo grupo VRRP (27) y comparten la misma dirección IP virtual (203.0.113.25).
El BNG con la prioridad más alta (254) es elegido en las primarias; el BNG con la prioridad más baja (200) es la copia de seguridad.
y de respaldo
La Figura 7 muestra cómo la prioridad VRRP configurada determina qué BNG actúa como principal o respaldo para un grupo redundancia suscriptor.
de redundancia de suscriptores
La topología incluye tres grupos de redundancia de suscriptor (M), SRG 1, SRG 2 y SRG 3 en tres BNG (N). Cada grupo de redundancia de suscriptor corresponde a un grupo VRRP diferente. Las flechas indican el enrutador principal y el enrutador de reserva para cada grupo
Para SRG 1, BNG 1 tiene la prioridad más alta, 250. BNG 3 tiene una prioridad menor, 200. Esto significa que BNG 1 es el principal para SRG 1 y BNG 3 es la copia de seguridad, por lo que BNG 1 conmuta por error a BNG 3. Cuando BNG 1 se recupera, es reelegido primario para SRG 1, porque tiene una prioridad más alta que BNG 3.
Para SRG 2, BNG 1 también tiene la prioridad más alta, 180, y es la principal. BNG 2 tiene una prioridad más baja, 150, y es la copia de seguridad.
Para SRG 3, BNG 2 tiene la prioridad más alta, 100, y es la principal. BNG 3 tiene una prioridad más baja, 75, y es el respaldo.
Conmutación por error de VRRP y sincronización de reversión
Con la configuración de redundancia que se muestra en la figura 7, supongamos que BNG 1 conmuta por error a BNG 3 para SRG 1, de modo que BNG 3 es el nuevo principal para el grupo. La función principal se revierte automáticamente a BNG 1 cuando vuelve a funcionar. Si la conexión entre los dos BNG se realiza a través de la red de acceso (en comparación con un vínculo directo entre los BNG), es posible que los estados del suscriptor no se sincronicen entre los dos BNG cuando se revierta el rol principal. El estado de VRRP es independiente de la sincronización de leasequery activa de DHCP.
Cuando se restaura el vínculo de acceso en BNG 1, la consulta leasequery activa de DHCP restaura la conexión para la sincronización de suscriptores entre los BNG. DHCP comienza a resincronizar el estado del suscriptor y la información de enlace del principal actual (BNG 3) al principal original recuperado (BNG 1).
Las estadísticas contables pueden verse afectadas si la función principal vuelve a BNG 1 antes de que se complete la resincronización. Por ejemplo, las estadísticas de contabilidad para suscriptores que inician sesión no se agregan a la base de datos hasta que se completa la resincronización. Los mensajes de cierre de sesión para los suscriptores que cierran sesión no se procesan hasta que finaliza la sincronización y los suscriptores se recuperan en BNG 1.
Puede mitigar estos efectos configurando el temporizador de retención de VRRP (a veces llamado temporizador de reversión) para que la resincronización se complete antes de que el principal original reanude el rol principal. Use la hold-time instrucción en el nivel de [edit interfaces] jerarquía.
Recomendamos que configure la redundancia VRRP en modo no revertido cuando opere a una escala alta. Para los sistemas que no funcionan a escala, puede usar el modo no revertido o configurar el temporizador de espera VRRP (a veces denominado temporizador de reversión) con valores lo suficientemente altos como para que la resincronización se complete antes de que el principal original reanude el rol principal.
Redundancia M:N mediante redundancia de pseudocable
A partir de Junos OS versión 20.1R1, puede utilizar la redundancia de pseudocable para proporcionar redundancia M:N cuando la red de acceso esté formada por circuitos de capa 2 (L2) mediante IP/MPLS. En este tipo de red de acceso, LDP es el protocolo de señalización que distribuye las etiquetas entre los vecinos del circuito L2. Cada circuito L2 es un túnel de pseudocable punto a punto entre el nodo de acceso (o el dispositivo de borde del cliente) y un BNG. La red puede incluir una mezcla heterogénea de dispositivos L2 o L3.
La Figura 8 muestra una topología simple en la que los nodos de acceso agregan tráfico y lo envían a través de la red a un agente de retransmisión DHCP en el BNG principal. La configuración de redundancia de pseudocable especifica un pseudocable activo (al BNG principal) y un pseudocable de respaldo (al BNG de respaldo).
y de respaldo
En el caso de los circuitos L2, los pseudocables se configuran como las interfaces subyacentes (orientadas al acceso) en los BNG. A continuación, configure las interfaces con conexiones L2, como Ethernet, VLAN dinámicas con detección automática o VLAN estáticas. Las interfaces de pseudocable orientadas al cliente DHCP se agrupan y se agregan a un circuito L2 (el túnel de pseudocable). Por lo general, el paquete incluye un conjunto de interfaces de VLAN dinámicas. Sin embargo, el paquete puede incluir cualquier combinación de interfaces lógicas de VLAN única, listas de interfaces de VLAN e interfaces físicas.
Un circuito L2 corre entre dos vecinos L2; en este caso, entre un nodo de acceso y un BNG. Cada vecino sirve como destino de punto final para una ruta de conmutación de etiquetas (LSP) de MPLS. El circuito se construye configurándolo en una interfaz en cada vecino:
En el BNG, se especifica el nodo de acceso como un vecino y una interfaz de pseudocable local en el BNG que termina el circuito L2.
En el nodo de acceso, se especifica el BNG como un vecino y una interfaz local dirigida a los clientes en el nodo que se encuentra en el otro extremo del circuito L2.
Tanto en el BNG como en el nodo de acceso, se configura un identificador único de circuito virtual (VCI) que distingue ese circuito L2 de entre todos los demás circuitos L2 que terminan en el dispositivo.
Ese circuito L2 es ahora el pseudocable principal del BNG. Para establecer la redundancia, configure el pseudocable de respaldo en el nodo de acceso. En la misma interfaz local, especifique otro BNG como vecino de respaldo y especifique que el pseudocable de respaldo esté en modo de espera activa.
El modo de espera activa garantiza que el vecino de respaldo esté completamente listo para asumir el control como principal si falla el circuito principal actual. LDP ya ha establecido un LSP para el vecino de respaldo.
El estado de la interfaz del pseudocable es UP en el BNG principal. El estado de la interfaz pseudowire es espera remota (RS) en la BNG de respaldo. (Puede usar el show l2circuit connections brief comando para ver el estado del circuito.) Debe configurar las políticas de ruta de manera que las rutas de subred para este grupo de redundancia se anuncien únicamente en el BNG principal. Esto garantiza que solo el principal reciba tráfico descendente.
LDP tiene un mecanismo de keepalive para detectar fallas. Una falla da como resultado la conmutación por error del circuito L2 del pseudocable principal y el BNG principal al pseudocable de respaldo y al BNG de respaldo. Cuando detecta un error, LDP cambia el circuito del LSP principal (en el pseudocable principal) al LSP de respaldo (en el pseudocable de respaldo). El BNG de respaldo asume el rol principal y su estado pasa a Activo.
Cuando el principal antiguo vuelve a funcionar, se aplican las mismas consideraciones relativas a la sincronización para la redundancia de pseudocable que cuando VRRP es el método de redundancia.
Recomendamos que configure la redundancia de pseudocable en modo no revertido cuando opere a una escala alta. En el caso de los sistemas que no funcionan a escala, puede utilizar el modo no reversible o configurar el intervalo en la interfaz del nodo de acceso con valores lo suficientemente altos como para que la revert-time resincronización se complete antes de que el principal original reanude el rol principal.
Suscriptores estáticos y redundancia M:N
M:N suscriptor redundancia admite dos categorías de suscriptores:
Suscriptores que utilizan el protocolo de cliente DHCP a través de una VLAN estática. Este es el tipo de suscriptor más común para la redundancia de suscriptor M:N.
Suscriptores en interfaces estáticas que no ejecutan un protocolo de cliente. Este tipo de suscriptor es típico de las pequeñas y medianas empresas que tienen su propia dirección IP estática y no utilizan nada como DHCP.
Los suscriptores estáticos constan de los siguientes tipos:
Suscriptores estáticos basados en VLAN: los suscriptores se crean sobre la interfaz lógica de VLAN. Configure los atributos de VRRP en la interfaz lógica de VLAN.
Suscriptores estáticos basados en demux IP: los suscriptores se crean en una interfaz demux IP a través de una interfaz subyacente. El tráfico de estos suscriptores incluye una dirección IP de origen que coincide con la subred configurada para la interfaz del suscriptor. Los atributos VRRP se configuran en la interfaz lógica subyacente.
El daemon jsscd administra ambos tipos de suscriptores estáticos. A veces se les denomina suscriptores estáticos de JSSCD.
En los siguientes fragmentos de configuración de ejemplo, se muestra cómo crear un grupo de suscriptores estático con dos interfaces configuradas para VRRP en un BNG principal y un BNG de respaldo. Una interfaz es una interfaz demux IP y la otra es una interfaz VLAN. La configuración muestra cómo se configura VRRP en cada interfaz.
Configuración de BNG principal:
El siguiente fragmento de código configura la interfaz subyacente para la interfaz lógica de demux IP, ge-1/1/9.11. Especifica el ID de VLAN como 11. La subred de la interfaz de acceso se establece en 203.0.113.1/24. La configuración VRRP en esta subred establece el grupo (el grupo de redundancia del suscriptor) en 11 y especifica la dirección del enrutador virtual. El enrutador virtual consta de los BNG principales y de respaldo para este grupo de redundancia de suscriptor. La prioridad VRRP es 230. Cuando la conmutación por error principal a la copia de seguridad, la asunción de la función principal por parte de la copia de seguridad se retrasa 30 segundos.
[edit] interfaces { ge-1/1/9 { unit 11 { demux-source inet; vlan-id 11; family inet { address 203.0.113.1/24 { vrrp-group 11 { virtual-address 203.0.113.25; priority 230; preempt { hold-time 30; } } } } } } }El siguiente fragmento de código configura la interfaz lógica de VLAN, ge-1/1/9.20. Especifica el ID de VLAN como 20. La subred de la interfaz de acceso se establece en 192.0.2.1/24. La configuración de VRRP en esta subred establece el grupo (el grupo de redundancia del suscriptor) en 20 y especifica la dirección del enrutador virtual. El enrutador virtual consta de los BNG principales y de respaldo para este grupo de redundancia de suscriptor. La prioridad VRRP es 230. Cuando la conmutación por error principal a la copia de seguridad, la asunción de la función principal por parte de la copia de seguridad se retrasa 30 segundos.
[edit] interfaces { ge-1/1/9 { unit 20 { vlan-id 20 ; family inet { address 192.0.2.1/24 { vrrp-group 20 { virtual-address 192.0.2.25; priority 230; preempt { hold-time 30; } } } } } } }El siguiente fragmento de código configura la interfaz lógica de demux IP, demux0.1, sobre la interfaz subyacente, ge-1/1/9.11. También configura la interfaz circuito cerrado y permite que la dirección local de la interfaz demux IP se derive de la interfaz circuito cerrado.
[edit] interfaces { demux0 { unit 1 { demux-options { underlying-interface ge-1/1/9.11; } family inet { unnumbered-address lo0.0; } } } lo0 { unit 0 { family inet { address 192.168.10.32/32; } } } }El siguiente fragmento de código configura un grupo de suscriptores estático, static-ifl, que incluye tanto la interfaz de suscriptor estático de demux de IP (demux0.1) como la interfaz de suscriptor estático de VLAN (ge-1/1/9.20). Asocia un perfil de acceso con el grupo, establece la contraseña y un prefijo para el nombre de usuario.
[edit system services] static-subscribers { group static-ifl { access-profile { staticauth; } authentication { password "$ABC123$ABC123"; ## SECRET-DATA username-include { user-prefix test-static; } } interface ge-1/1/9.20; interface demux0.1; } }El siguiente fragmento de código configura un perfil de acceso para el grupo de suscriptores estáticos.
[edit access] profile staticauth { authentication-order none; }
Configuración de BNG de respaldo:
En este ejemplo, algunos detalles de configuración son diferentes y otros deben ser los mismos.
Las interfaces de acceso son diferentes. Como alternativa, puede configurar las interfaces de acceso para que sean las mismas en la principal y en la copia de seguridad.
La prioridad VRRP se establece en 200 para ambas interfaces. Ese valor lo convierte en el BNG de respaldo, porque es menor que la prioridad en el otro BNG (230).
Las direcciones de interfaz son diferentes. La dirección virtual es la misma para ambos, como debe ser, de modo que ambos BNG estén en el mismo enrutador virtual.
Las interfaces de acceso se encuentran en la misma subred.
El siguiente fragmento de código configura la interfaz subyacente para la interfaz lógica de demux IP, ge-3/0/1.11. Especifica el ID de VLAN como 11. La subred de la interfaz de acceso se establece en 203.0.113.2/24. La configuración VRRP en esta subred establece el grupo (el grupo de redundancia del suscriptor) en 11 y especifica la dirección del enrutador virtual. El enrutador virtual consta de los BNG principales y de respaldo para este grupo de redundancia de suscriptor. La prioridad VRRP es 200. Cuando la conmutación por error principal a la copia de seguridad, la asunción de la función principal por parte de la copia de seguridad se retrasa 30 segundos.
[edit] interfaces { ge-3/0/1 { unit 11 { demux-source inet; vlan-id 11; family inet { address 203.0.113.2/24 { vrrp-group 11 { virtual-address 203.0.113.25; priority 200; preempt { hold-time 30; } } } } } } }El siguiente fragmento de código configura la interfaz lógica de VLAN, ge-3/0/1.20. Especifica el ID de VLAN como 20. La subred de la interfaz de acceso se establece en 192.0.2.2/24. La configuración de VRRP en esta subred establece el grupo (el grupo de redundancia del suscriptor) en 20 y especifica la dirección del enrutador virtual. El enrutador virtual consta de los BNG principales y de respaldo para este grupo de redundancia de suscriptor. La prioridad VRRP es 200. Cuando la conmutación por error principal a la copia de seguridad, la asunción de la función principal por parte de la copia de seguridad se retrasa 30 segundos.
[edit] interfaces { ge-3/0/1 { unit 20 { vlan-id 20 ; family inet { address 192.0.2.2/24 { vrrp-group 20 { virtual-address 192.0.2.25; priority 200; preempt { hold-time 30; } } } } } } }El siguiente fragmento de código configura la interfaz lógica de demux IP, demux0.1, a través de la interfaz subyacente, ge-3/0/1.11. También configura la interfaz circuito cerrado y permite que la dirección local de la interfaz demux IP se derive de la interfaz circuito cerrado.
[edit] interfaces { demux0 { unit 1 { demux-options { underlying-interface ge-3/0/1.11; } family inet { unnumbered-address lo0.0; } } } lo0 { unit 0 { family inet { address 192.168.10.32/32; } } } }El siguiente fragmento de código configura un grupo de suscriptores estático, static-ifl, que incluye tanto la interfaz de suscriptor estático de IP demux (demux0.1) como la interfaz de suscriptor estático de VLAN (ge-3/0/1.20). Asocia un perfil de acceso con el grupo, establece la contraseña y un prefijo para el nombre de usuario.
[edit system services] static-subscribers { group static-ifl { access-profile { staticauth; } authentication { password "$ABC123"; ## SECRET-DATA username-include { user-prefix test-static; } } interface ge-3/0/1.20; interface demux0.1; } }El siguiente fragmento de código configura un perfil de acceso para el grupo de suscriptores estáticos.
[edit access] profile staticauth { authentication-order none; }
Convergencia y redundancia de suscriptor M:N
La convergencia es el proceso mediante el cual los enrutadores en una red actualizan sus tablas de enrutamiento individuales cuando se agregan o eliminan rutas en cualquier enrutador, o ya no se puede acceder a ellas debido a un fallo en un vínculo. Los protocolos de enrutamiento de los enrutadores anuncian los cambios de ruta en toda la red. A medida que cada enrutador recibe las actualizaciones, vuelve a calcular las rutas y, luego, crea nuevas tablas de enrutamiento basadas en los resultados.
Una red converge cuando todas las tablas de enrutamiento coinciden en la topología general de la red. Por ejemplo, esto significa que los enrutadores tienen un entendimiento común acerca de qué vínculos están activos o inactivos, y así sucesivamente. El tiempo que tardan los enrutadores en alcanzar un estado de convergencia se denomina tiempo de convergencia. La duración del tiempo de convergencia depende de varios factores, como el tamaño y la complejidad de la red y el rendimiento de los protocolos de enrutamiento.
La redundancia del suscriptor M:N admite la convergencia de rutas tanto del lado de acceso (ascendente) como del lado del núcleo (descendente). Dado que cada suscriptor está activo simultáneamente en el BNG principal y en el de respaldo, la convergencia del tráfico puede ser muy rápida. Sin embargo, la convergencia de rutas es el mejor esfuerzo y depende del grado de tolerancia a fallos; es decir, si se produce una falla parcial o total del chasis.
Depende de usted determinar cómo administrar la convergencia del tráfico ascendente y descendente para su red después de una tolerancia a fallos de BNG principal a BNG de respaldo.
- Convergencia de tráfico ascendente (redundancia VRRP)
- Convergencia de tráfico ascendente (redundancia de pseudocable)
- Convergencia del tráfico descendente
Convergencia de tráfico ascendente (redundancia VRRP)
Puede mejorar la convergencia del tráfico ascendente mediante el uso de ARP gratuito para reducir el tiempo que tarda la red de acceso en comenzar a enviar tráfico al nuevo BNG principal después de que falle el BNG principal original.
En el BNG principal, la interfaz de acceso o el módulo de interfaz desciende.
VRRP elige el BNG de respaldo como el nuevo principal.
El nuevo principal transmite mensajes ARP gratuitos a la red de acceso. Envía los mensajes desde su interfaz de acceso correspondientes a la interfaz de acceso del principal anterior. El mensaje ARP contiene la dirección IP virtual VRRP y la dirección MAC virtual que definen el enrutador virtual que incluye los dos BNG.
El conmutador u otro dispositivo de la red de acceso vuelve a aprender la dirección IP de la puerta de enlace (la dirección virtual). Cuando envía tráfico a esa dirección, el nuevo BNG principal lo recibe en la interfaz de acceso.
Convergencia de tráfico ascendente (redundancia de pseudocable)
Cuando se configuran los pseudocables principal y de respaldo en modo de espera activa en el nodo de acceso, LDP establece automáticamente LSP en los BNG principal y de respaldo. El protocolo de señalización LDP incluye un mecanismo de keepalive para detectar fallas en la ruta. En este caso, la convergencia aguas arriba se logra mediante un conmutador de túnel de capa 2 pseudocable desde el BNG principal al BNG de respaldo.
Puede configurar temporizadores de mantenimiento de LDP para una detección más rápida de fallas. Como alternativa, puede ejecutar el protocolo BFD para una tolerancia a fallos más rápida. Cualquiera de los siguientes métodos puede provocar un cambio del pseudocable principal al pseudocable de respaldo:
Utilice el
request l2circuit-switchovercomando para activar manualmente un conmutador del pseudocable principal al pseudocable de respaldo.Puede configurar la detección de reenvío bidireccional (BFD) para los LSP de LDP. La detección de vida de BFD puede detectar dos tipos diferentes de errores:
Un error de vínculo en la ruta del LSP entre el nodo de acceso y el BNG principal. En este caso, el BNG todavía está activo.
Falla de vecino caído cuando el BNG principal deja de funcionar.
Para ambos tipos, la velocidad de detección y conmutación se controla mediante la configuración de la
bfd-liveness-detectioninstrucción en el[edit protocols ldp oam]nivel jerárquico.
Convergencia del tráfico descendente
El tiempo requerido para la convergencia del tráfico descendente se ve afectado por varios factores, incluidos los siguientes:
La publicidad de rutas de suscriptores individuales aumenta la cantidad de recálculos de rutas que deben realizar los enrutadores de red central.
Detectar cuándo una interfaz de acceso deja de funcionar y luego enviar la notificación de cambio de ruta adecuada al núcleo a veces puede ser difícil o llevar mucho tiempo.
Es posible que los protocolos de enrutamiento en el núcleo no aprendan inmediatamente cuando falla un vínculo orientado al núcleo o todo el chasis. Los protocolos de enrutamiento suelen depender de algún tipo de tiempo de espera para detectar la pérdida, por lo que siempre hay un retraso esperando a que expire el tiempo de espera.
Recomendamos las siguientes pautas:
Asegúrese de que las rutas de los suscriptores se agreguen para su publicidad al núcleo siempre que sea posible. La agregación se puede lograr mediante el uso de grupos de direcciones o anuncios de ruta basados en políticas como se describe a continuación. Al reducir el número de rutas que se deben volver a calcular en los enrutadores centrales, se reduce el tiempo de convergencia, especialmente a medida que aumenta la escala de suscriptores.
Configure las rutas que se anunciarán desde ambos BNG con diferentes preferencias. Utilice técnicas de reenrutamiento rápido en el núcleo.
Evite equilibrar el equilibrio de carga del tráfico descendente entre los BNG principal y de respaldo.
Dos métodos que puede considerar son la publicidad de ruta basada en políticas y los enlaces BNG dedicados.
Anuncio de ruta basado en políticas (VRRP y redundancia de pseudocable): esta técnica puede reducir el tiempo de convergencia del tráfico descendente, ya que solo se actualizan las rutas agregadas en la red principal, en lugar de numerosas rutas de suscriptores individuales. Para este método, configure BGP, OSPF o cualquier otro protocolo de enrutamiento para anunciar rutas agregadas hacia el núcleo solo cuando un BNG se convierte en el principal.
Para lograr la redundancia de VRRP, configure las políticas del BGP para realizar un seguimiento de la dirección IP virtual de VRRP. BGP agrega las rutas de los suscriptores según el grupo de redundancia del suscriptor correspondiente a un grupo VRRP. El BGP anuncia las rutas agregadas al núcleo cuando el BNG asume el rol principal de VRRP.
Para lograr una redundancia de pseudocable, configure las políticas del BGP para realizar un seguimiento del estado de la interfaz de pseudocable (arriba o abajo). El BGP agrega rutas para el grupo de redundancia del suscriptor. El BGP anuncia las rutas agregadas al núcleo cuando el estado cambia a Up, lo que significa que el BNG de respaldo ahora es el principal.
En cualquier caso, si el BNG principal conmuta por error a la copia de seguridad, el BGP en el principal con errores retira las rutas de suscriptores agregadas para el núcleo. Cuando el BNG de respaldo se convierte en el nuevo principal, a su vez anuncia grupos de suscriptores agregados al núcleo.
Vínculos dedicados de BNG (solo redundancia de VRRP): puede reducir el tiempo que se tarda en detectar un error en el BNG principal conectando los BNG con un vínculo dedicado. Configure VRRP en la interfaz de acceso para realizar un seguimiento del estado de la interfaz de vínculo dedicada. También configure VRRP en la interfaz de vínculo dedicada para realizar un seguimiento del estado de la interfaz de acceso.
Un error en la interfaz de acceso en la principal hace que el rol principal de VRRP cambie en el vínculo dedicado. Ese cambio, a su vez, hace que la función principal cambie inmediatamente en la interfaz de acceso en la BNG de respaldo. Este método es más rápido que esperar a que caduque el temporizador de saludo VRRP.
Cómo configurar la redundancia del suscriptor M:N con la sincronización de enlaces VRRP y DHCP
La redundancia del suscriptor M:N con la sincronización de enlaces VRRP y DHCP requiere que configure todo lo siguiente:
Grupos de suscriptor redundantes para especificar los suscriptores que forman parte de la operación principal/de respaldo.
VRRP en todos los enrutadores redundantes de la topología. VRRP es el protocolo que proporciona la capacidad de redundancia subyacente para los grupos de suscriptores y los agentes de retransmisión DHCP.
En este tema se describen solo las configuraciones básicas necesarias para la redundancia del suscriptor M:N en los BNG que hospedan los agentes de retransmisión DHCP par. No describe todos los aspectos de lo siguiente: la administración global de suscriptores, la configuración de VRRP que puede usar en su red, los agentes de retransmisión DHCP o DHCP leasequery. Para obtener más información sobre estos temas, consulte lo siguiente:
La redundancia del suscriptor M:N requiere que los BNG primarios y de respaldo admitan las mismas versiones de protocolo para DHCP y VRRP. Si el soporte del protocolo es diferente entre los BNG, es posible que vea efectos secundarios no deseados.
Los suscriptores de redundancia de doble pila tienen el requisito de configuración VRRP. Debe configurar ambas familias de direcciones en la interfaz de acceso, ya que los suscriptores de doble pila requieren dos sesiones, una para IPv4 e IPv6. También debe configurar la misma prioridad de función principal VRRP para las sesiones IPv4 e IPv6 para un grupo de redundancia dado, ya que comparten la misma interfaz lógica.
Configurar redundancia de grupo de suscriptores
Para configurar la redundancia del grupo de suscriptores en un BNG:
Configure VRRP para que admita redundancia M:N
Para configurar VRRP de modo que admita la redundancia M:N para un grupo de redundancia de suscriptor en un BNG:
Cómo configurar la redundancia del suscriptor M:N con pseudocables y sincronización de enlace DHCP
Las redundancia suscriptor M:N con pseudocables y sincronización de enlace DHCP requieren la configuración de grupos de suscriptor redundantes para especificar los suscriptores que forman parte de la operación principal/de respaldo.
La redundancia del suscriptor M:N con pseudocables funciona en una red IP/MPLS donde los túneles de pseudocables desde un nodo de acceso (como un conmutador) forman los circuitos L2 hasta los BNG primarios y de respaldo que actúan como agentes de retransmisión DHCP. Esas configuraciones están fuera del alcance de esta documentación.
En este tema se describen solo las configuraciones básicas necesarias para la redundancia del suscriptor M:N en los BNG que hospedan los agentes de retransmisión DHCP par. No describe todos los aspectos de lo siguiente: administración global de suscriptores, agentes de retransmisión DHCP o leasequery DHCP. No describe cómo configurar la red IP/MPLS, el nodo de acceso que crea los circuitos L2 a los agentes de retransmisión DHCP ni los túneles de pseudocable. Para obtener más información sobre estos temas, consulte lo siguiente:
La redundancia del suscriptor M:N requiere que los BNG principal y de respaldo admitan las mismas versiones de protocolo para DHCP. Si el soporte del protocolo es diferente entre los BNG, es posible que vea efectos secundarios no deseados.
Configurar redundancia de grupo de suscriptores
Para configurar la redundancia del grupo de suscriptores en un BNG:
Por ejemplo, puede configurar lo siguiente en una BNG:
[edit system services subscriber-management redundancy] user@host# set protocol pseudo-wire user@host# set interface ps2.0 local-inet-address 10.80.1.2 user@host# set interface ps2.0 local-inet6-address 2001:db8:: user@host# set interface ps2.0 shared-key pskey-2.0-abc-215 user@host# set interface ps3.0 local-inet-address 10.10.0.1 user@host# set interface ps3.0 local-inet6-address 2001:db8:ff:f8:: user@host# set interface ps3.0 shared-key pskey-3.0-def-43 user@host# set no-advertise-routes-on-backup
A continuación, configure lo siguiente en un BNG par. Tenga en cuenta que ps5.0 en este BNG comparte la misma clave que ps2.0 en el otro. Esto significa que ps2.0 y ps5.0 son las interfaces de acceso asociadas para la redundancia de pseudocable. De manera similar, las interfaces asociadas ps3.0 y ps4.0 tienen la misma clave compartida entre sí.
[edit system services subscriber-management redundancy] user@host# set protocol pseudo-wire user@host# set interface ps4.0 local-inet-address 10.55.3.0 user@host# set interface ps4.0 local-inet6-address 2001:db8:1C:44:: user@host# set interface ps4.0 shared-key pskey-3.0-def-43 user@host# set interface ps5.0 local-inet-address 10.60.20.1 user@host# set interface ps5.0 local-inet6-address 2001:db8:01:10:cd:: user@host# set interface ps5.0 shared-key pskey-2.0-abc-215 user@host# set no-advertise-routes-on-backup
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.