Redundancia de suscriptores M:N en BNG
Descripción general de la redundancia de suscriptores M:N en BNG
A partir de Junos OS versión 19.2R1, puede configurar la redundancia de suscriptores M:N como un mecanismo para mejorar la resistencia de la red protegiendo a los suscriptores de una variedad de errores 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.

Una falla en cualquiera de las ubicaciones enumeradas en la Tabla 1 puede desencadenar un BNG primario para conmutar por error a un BNG de respaldo.
Tarjeta de línea de acceso |
Vínculo orientado al núcleo |
Enlace de acceso |
Red de acceso parcial |
Chasis |
Red de núcleo parcial |
Puede usar 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 IP demux; 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 agregó en Junos OS versión 20.1R1.)
- Beneficios de la redundancia de suscriptores M:N en BNG
- Fundamentos de la redundancia M:N
- Sesiones de suscriptor y modo de espera activa
- Redundancia M:N mediante el Protocolo de redundancia de enrutador virtual (VRRP)
- Tiempo de reversión y conmutación por error de VRRP
- Redundancia M:N mediante redundancia de pseudocable
- Descubrimiento de topología de consulta de arrendamiento activo DHCP y redundancia de suscriptores M:N
- Ejemplo de descubrimiento de topología con redundancia VRRP
- Ejemplo de descubrimiento de topología con redundancia de pseudocable
- Suscriptores estáticos y redundancia M:N
- Convergencia y redundancia de suscriptores M:N
Beneficios de la redundancia de suscriptores M:N en BNG
Proporciona una redundancia ligera de suscriptores de capa de aplicación. Puede usarlo 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 de redundancia de suscriptor y como BNG de respaldo para otros grupos de redundancia de suscriptores 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. El chasis virtual de la serie MX requiere un chasis dedicado para la redundancia. Proporciona redundancia 1:1 y se usa con mayor frecuencia en implementaciones centralizadas.
La redundancia M:N con descubrimiento de topología de consulta de arrendamiento activa DHCP protege a los suscriptores de varios puntos únicos de falla de hardware y software diferentes. Estos incluyen fallas en los enlaces de acceso (orientados al suscriptor) o frontales al núcleo y en un módulo de interfaz de acceso o en el chasis. También protege contra fallas de red de acceso parcial y de red central parcial.
Puede activar o desactivar la redundancia M:N para los suscriptores activos. Si quita la configuración de redundancia, los suscriptores que tenían la configuración permanecen intactos tanto en el BNG principal como en el de respaldo.
Puede implementar la redundancia M:N con una única interfaz orientada al núcleo. Esto significa que varios grupos de redundancia de suscriptores pueden compartir una conectividad básica común.
Los suscriptores de redundancia M:N pueden coexistir con los suscriptores sin redundancia. Esto significa que no tiene que tener BNG dedicados a la redundancia de suscriptores.
Puede configurar suscriptores de redundancia M:N en 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 copia de seguridad y, a continuación, 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 (M) grupos de suscriptores en un chasis BNG determinado en varios (N) destinos de chasis diferentes. Nos referimos a estos grupos como grupos de redundancia de suscriptores.
Un grupo de suscriptores está formado por todos los suscriptores que cumplen los siguientes criterios:
(VLAN estáticas) Los suscriptores pertenecen a una VLAN estática particular 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.
(IP demux 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 suscriptores. Un grupo de redundancia de suscriptores determinado usa solo un BNG a la vez. Llamamos a este BNG el primario. Para cada grupo de redundancia de suscriptores, 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 reserva adecuado para el grupo de redundancia afectado. Este BNG de reserva es ahora el nuevo BNG principal para ese grupo. Todas las sesiones de suscriptor activas para ese grupo de redundancia de suscriptor se mantienen durante la conmutación por error al BNG de respaldo.
La figura 2 es un diagrama conceptual que ilustra las relaciones primaria/respaldo de M:N. Muestra cinco BNG en una topología primaria/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 reserva para diferentes grupos de redundancia de suscriptor. Si BNG 2 es el principal, puede configurar BNG 1, 3, 4 y 5 como BNG de reserva, etc.

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 para 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, 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 primarios para los grupos.
La figura 3 muestra una configuración sencilla de grupos de suscriptores y grupos de redundancia de suscriptores en tres agentes de retransmisión DHCP alojados en tres BNG. Los BNG pueden estar conectados directamente entre sí o a través de las redes de acceso o centrales.

El agente de retransmisión RA1 está configurado para los grupos de redundancia de suscriptores, SRG 1 y SRG 2, y el grupo de suscriptores 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.
Los SG A y SG B no están respaldados.
Ahora considere la Figura 4, que muestra la misma topología, pero indica qué BNG es principal y cuál es una copia de seguridad para cada grupo de redundancia. El BNG que aloja RA 1 es el BNG principal para SRG 1 y SRG 2.

Si se produce un error en este BNG, conmuta por error a un BNG de respaldo diferente para SRG 1 y SRG 2, como se muestra en la figura 5.

Para SRG 1, conmuta por error al BNG que aloja RA 3. El BNG de RA 3 se convierte en el nuevo primario para SRG 1.
Para SRG 2, conmuta por error al BNG que aloja RA 2. El BNG de RA 2 se convierte en el nuevo primario para SRG 2.
La falla no tiene ningún efecto en SRG 3.
Sesiones de suscriptor y modo de espera activa
Cada BNG de copia de seguridad está en modo de espera activa para su BNG principal correspondiente para cada grupo de redundancia de suscriptor en la copia de seguridad. Esto significa que el BNG de respaldo está listo para tomar el relevo del BNG primario inmediatamente y sin interrupciones cuando se produce una conmutación por error. Los siguientes comportamientos del BNG principal y de respaldo permiten que funcione el modo de espera activa.
Los enlaces del suscriptor y el estado del suscriptor se reflejan sincrónicamente en el BNG de respaldo, al igual que la información de descubrimiento de vecinos y ARP del BNG principal. Cada suscriptor aparece en el BNG de respaldo y su estado es Activo. Dado que los suscriptores están activos simultáneamente en el BNG principal y en el de respaldo, el BNG de respaldo no realiza ningún procesamiento de suscriptor durante un evento de conmutación por error.
Cada sesión de suscriptor se trata como una sesión continua antes, durante y después de una conmutación por error. Durante el inicio de sesión inicial del suscriptor, los BNG principales y de respaldo envían un mensaje RADIUS Accounting-Start u OCS CCR-I para el suscriptor.
Durante la conmutación por error, la entidad primaria que produce una falla envía un mensaje de detención de cuentas o CCR-T según el máximo esfuerzo. Por ejemplo, envía el mensaje si el vínculo orientado hacia el núcleo sigue activo o si el chasis sigue funcionando. Si el vínculo orientado al núcleo está inactivo o todo el chasis está inactivo, el principal que falla no puede enviar un mensaje de detención de contabilidad o CCR-T.
Cuando el BNG de copia de seguridad se convierte en principal, no envía un mensaje de inicio de cuentas o CCR-I porque los suscriptores están activos en la conmutación por error. Las estadísticas contables se incrementan a partir de la nueva primaria.
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 principal. Cuando el BNG principal conmuta por error, no elimina las rutas de suscriptor de su propia tabla de enrutamiento y no retira las rutas de la red principal. Después de la conmutación por error, el primario fallido no agrega ni propaga ninguna ruta. Como alternativa, puede configurar las rutas de suscriptor que se anunciarán o retirarán del núcleo en función del rol principal de BNG, de modo que no haya pérdida de tráfico como resultado de la conmutación por error.
La sincronización de estado solo se aplica al estado del suscriptor. El estado del servicio no está sincronizado. En función de la configuración de servicios, el BNG puede adjuntar servicios para los suscriptores tanto en suscriptores activos como en suscriptores de reserva. Como alternativa, los servicios pueden volver a conectarse después de la conmutación por error en el nuevo BNG activo.
La redundancia de suscriptor M:N no sincroniza las estadísticas contables del BNG principal con el BNG de respaldo. Hace un mejor esfuerzo para comunicar información de contabilidad a un servidor de contabilidad. Cuando se produce una conmutación por error, las estadísticas contables comienzan a incrementarse desde la nueva principal y dejan de incrementarse desde la principal fallida. Según la gravedad del error, las conmutaciones por error pueden provocar la pérdida de información contable.
Redundancia M:N mediante el Protocolo de redundancia de enrutador virtual (VRRP)
Puede usar 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. El grupo VRRP se configura en la interfaz de acceso respectiva de 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 solo la dirección de puerta de enlace virtual y la dirección MAC virtual a los hosts de suscriptor. 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 conmutación por error de la principal a la copia de seguridad se produce en unos pocos segundos.
La solución VRRP para la redundancia M:N está dirigida a un modelo de acceso de suscriptor 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 tema relacionado 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 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 primario, el protocolo elige el enrutador de reserva como el nuevo principal. El nuevo primario asume la propiedad de las direcciones IP y MAC virtuales. La conmutación por error no afecta al tráfico de datos.
-
Cuando el primario original vuelve a estar en línea, el protocolo determina que tiene una prioridad más alta que el primario actual (copia de seguridad anterior). A continuación, el principal original reanuda el rol principal sin afectar al tráfico de datos.
Nota:Cuando se usa VRRP para redundancia de suscriptor M:N, el número de grupos de redundancia de suscriptor se limita al número de sesiones VRRP admitidas en el dispositivo. Para la pila dual, esta característica requiere sesiones VRRP separadas para IPv4 e IPv6, por lo tanto, el número de grupos de redundancia de suscriptores se reduce a la mitad.
La figura 6 muestra una topología de ejemplo con dos BNG y la configuración de las interfaces correspondientes en cada enrutador:
Las dos interfaces lógicas están en la misma VLAN (1).
Las direcciones de interfaz están 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 primario; el BNG con la prioridad más baja (200) es la copia de seguridad.

La figura 7 muestra cómo la prioridad VRRP configurada determina qué BNG actúa como principal o de respaldo para un grupo 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 suscriptores corresponde a un grupo VRRP diferente. Las flechas indican el enrutador principal y el enrutador de respaldo para cada grupo
Para SRG 1, BNG 1 tiene la prioridad más alta, 250. BNG 3 tiene una prioridad más baja, 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 la copia de seguridad.
Tiempo de reversión y conmutación por error de VRRP
Usando 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 primario para el grupo. El rol principal vuelve automáticamente a BNG 1 cuando vuelve a aparecer. Si la conexión entre los dos BNG es 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 activade consultas de concesión de DHCP.
Cuando se restaura el vínculo de acceso en BNG 1, la consulta de arrendamiento activa DHCP restaura la conexión para la sincronización del suscriptor entre los BNG. DHCP comienza a resincronizar el estado del suscriptor y la información de enlace del principal actual (BNG 3) al primario original recuperado (BNG 1).
Las estadísticas contables pueden verse afectadas si el rol principal vuelve a BNG 1 antes de que se complete la resincronización. Por ejemplo, las estadísticas contables de los 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 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 espera VRRP (en algún momento denominado temporizador revertivo) para que la resincronización se complete antes de que el principal original reanude el rol principal. Utilice la hold-time
instrucción en el nivel jerárquico [edit interfaces]
.
Le recomendamos que configure la redundancia VRRP en modo no revertivo cuando opere a gran escala. En el caso de los sistemas que no funcionan a escala, puede usar el modo no revertivo o configurar el temporizador de retención VRRP (en algún momento denominado temporizador revertivo) con valores lo suficientemente altos como para que la resincronización se complete antes de que el principal original reanude la función principal.
Redundancia M:N mediante redundancia de pseudocable
A partir de Junos OS versión 20.1R1, puede utilizar redundancia de pseudocable para proporcionar redundancia M:N cuando la red de acceso consta de circuitos de capa 2 (L2) a través de IP/MPLS. En este tipo de red de acceso, LDP es el protocolo de señalización que distribuye etiquetas entre vecinos del circuito L2. Cada circuito L2 es un túnel de pseudocable punto a punto entre el nodo de acceso (o dispositivo perimetral 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).

Para los circuitos L2, los pseudocables se configuran como interfaces subyacentes (orientadas hacia el 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. Normalmente, el paquete incluye un conjunto de interfaces VLAN dinámicas. Sin embargo, el paquete puede incluir cualquier combinación de interfaces lógicas de VLAN única, listas de interfaces VLAN e interfaces físicas.
Un circuito L2 discurre 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, especifique el nodo de acceso como vecino y una interfaz de pseudocable local en el BNG que finaliza el circuito L2.
En el nodo de acceso, especifique el BNG como vecino y una interfaz local frente a clientes en el nodo que es el otro extremo del circuito L2.
Tanto en el nodo BNG como en el nodo de acceso, se configura un identificador de circuito virtual (VCI) único 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 primario del BNG. Para establecer la redundancia, configure el pseudocable de copia de seguridad en el nodo de acceso. En la misma interfaz local, especifique otro BNG como vecino de copia de seguridad y especifique que el pseudocable de copia de seguridad 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 primario actual. LDP ya ha establecido un LSP para el vecino de respaldo.
El estado de la interfaz de pseudocable es UP en el BNG principal. El estado de la interfaz de pseudocable es espera remota (RS) en el BNG de respaldo. (Puede usar el show l2circuit connections brief
comando para ver el estado del circuito). Debe configurar las directivas de ruta para que las rutas de subred para este grupo de redundancia se anuncien solo en el BNG principal. Esto garantiza que solo el primario reciba tráfico descendente.
LDP tiene un mecanismo keepalive para detectar fallas. Una falla da como resultado que el circuito L2 conmute por error desde el pseudocable primario y el BNG primario al pseudocable de respaldo y el BNG de respaldo. Cuando detecta un error, LDP cambia el circuito del LSP primario (en el pseudocable primario) al LSP de respaldo (en el pseudocable de respaldo). El BNG de copia de seguridad asume la función principal y su estado pasa a Arriba.
Cuando la antigua primaria vuelve a funcionar, se aplican las mismas consideraciones con respecto a la sincronización para la redundancia de pseudocable que cuando VRRP es el método de redundancia.
Se recomienda configurar la redundancia de pseudocables en modo no revertivo cuando se opera a gran escala. Para los sistemas que no funcionan a escala, puede usar el modo no revertivo o configurar el revert-time
intervalo en la interfaz del nodo de acceso con valores lo suficientemente altos como para que la resincronización se complete antes de que el principal original reanude el rol principal.
Descubrimiento de topología de consulta de arrendamiento activo DHCP y redundancia de suscriptores M:N
Para los suscriptores DHCP, la consulta de arrendamiento activa DHCP y la detección de topología permiten sincronizar el estado del suscriptor y la información de enlace entre los agentes de retransmisión DHCP pares para todos los grupos de redundancia de suscriptores de los pares. Esto permite que las concesiones y el tráfico de datos continúen sin interrupción tanto cuando el BNG principal conmuta por error a la copia de seguridad como cuando reanuda el rol principal.
Aunque configure la redundancia principal/de copia de seguridad a nivel de interfaz para pares de BNG, también corresponde en cierto modo a los agentes de retransmisión DHCP alojados en los BNG principales y de respaldo. Puede pensar que el agente de retransmisión DHCP del BNG principal es el agente de retransmisión principal de un grupo de redundancia de suscriptores. Del mismo modo, puede pensar que el agente de retransmisión DHCP en el BNG de copia de seguridad de un grupo es el agente de retransmisión de copia de seguridad del grupo.
Cada agente de retransmisión que configure con la detección de topología intercambia mensajes con sus pares de leasequery activos configurados para determinar el nombre de las interfaces de acceso en sus pares de agente de retransmisión que corresponden a sus propias interfaces de acceso local y se conectan con ellas. Las interfaces de acceso son las interfaces utilizadas por los grupos de redundancia de suscriptores.
Cuando un agente de retransmisión envía un mensaje de consulta de descubrimiento de topología a un par, ese mensaje incluye opciones DHCP que especifican el nombre de la interfaz de acceso (ID del circuito del agente), la subred o máscara de la interfaz y el ID de VLAN del grupo de redundancia. DHCP también genera un ID de transacción aleatoria para el intercambio que se transmite en el encabezado del paquete. El ID de transacción es único para esa interfaz de acceso.
El agente de retransmisión par receptor utiliza la subred o máscara y el ID de VLAN para determinar si tiene una interfaz de acceso local para esos valores. Si lo hace, el par envía una respuesta de descubrimiento de topología a través de esa interfaz a la interfaz de acceso del agente de retransmisión de consulta. El mensaje de respuesta incluye la subred o máscara, el ID de VLAN y el ID de transacción que recibió en la consulta.
El agente de retransmisión de consultas comprueba que el ID de transacción de la respuesta coincide con la interfaz de acceso en la que recibió la respuesta. El ID de transacción en la respuesta debe corresponder al que envió al par para esa interfaz de acceso. Si el ID de transacción coincide, el agente de retransmisión puede agregar una entrada a su tabla de traducción para asociar las dos interfaces vinculadas.
El agente de consulta repite este proceso para cada una de sus interfaces de acceso local.
La figura 9 muestra esta consulta y respuesta para dos BNG cuando se usa la redundancia VRRP. BNG 1 envía la consulta de su interfaz de acceso, ge-10/1/2, a BNG 2 a través de la conexión TCP. BNG 2 responde a través de la conexión UDP desde su interfaz asociada, ge-2/3/9.
BNG 2 envía una consulta para su interfaz de acceso a BNG 1 a través de la conexión TCP. BNG 1 responde a través de la conexión UDP desde su interfaz asociada ge-10/1/2.

La figura 10 muestra una consulta y una respuesta para dos agentes de retransmisión DHCP en BNG cuando se usa la redundancia de pseudocables. R1 envía la consulta para su interfaz de acceso, ps2.0, a BNG 2 a través de la conexión TCP. R2 responde a través de la misma conexión TCP. R2 también envía una consulta a R1, para su interfaz de acceso, ps5.0. A continuación, R1 responde a esta consulta a través de la conexión TCP. El descubrimiento de topología para la redundancia de pseudocables usa una clave común compartida configurada estáticamente entre los pares de BNG como criterio de coincidencia. Esto contrasta con la redundancia VRRP, donde la coincidencia se realiza en la subred/máscara y el ID de VLAN.

Cada agente par envía consultas a sus pares para que pueda construir su propia tabla de traducción de las interfaces de acceso local y remoto correspondientes. De esta manera, todos los agentes de retransmisión que configure como pares y para la detección de topología aprenderán el conjunto completo de interfaces de acceso remoto para sus interfaces locales. Las tablas de traducción permiten a los pares sincronizar la información del suscriptor de forma adecuada para cada grupo de redundancia de suscriptores.
Una vez completada la detección de la topología, la consulta de arrendamiento activa realiza la sincronización del suscriptor. Active leasequery realiza sus consultas mediante giaddr (DHCPv4) o linkaddr (DHCPv6). Este tipo de consulta garantiza que DHCP sincronice sólo la información de los suscriptores de un grupo de redundancia para cada interfaz.
No puede configurar este tipo de consulta; Es una función de configuración del descubrimiento de topología. Cuando configura la detección de topología, la presencia de query-by-relay-id y giaddr en la opción 82 de DHCPv4 o linkaddr en la opción 18 de DHCPv6 se interpreta como una consulta de giaddr o una consulta de linkaddr, respectivamente.
El agente de retransmisión utiliza la interfaz de acceso como valor para su campo Dirección IP de puerta de enlace (giaddr o linkaddr) cuando envía paquetes al servidor local en nombre de un cliente. El servidor local devuelve giaddr/linkaddr cuando responde al agente de retransmisión. A continuación, el agente de retransmisión utiliza este valor para determinar dónde enviar la información aguas abajo. El giaddr/linkaddr muestra que el paquete se ha enviado para una interfaz lógica de acceso determinada, por lo que el agente de retransmisión reenvía la información al cliente DHCP en esa interfaz.
Lo que esto significa para la redundancia de suscriptor es que al usar la consulta giaddr o linkaddr, activeleasequery solo solicita información para los suscriptores en esa interfaz de acceso. Por consiguiente, solo sincroniza la información del suscriptor del agente de retransmisión principal con el agente de retransmisión de copia de seguridad. Se trata de un conjunto de suscriptores mucho menor que si la consulta de arrendamiento activa usara el método query-by relay-id, que devolvería información para todos los suscriptores en todo el chasis.
El resultado de este proceso es que cada agente par instala los suscriptores para cada grupo de redundancia que controla. Cuando el agente de BNG/retransmisión principal conmuta por error, la copia de seguridad ya tiene la información del suscriptor necesaria para mantener la sesión sin interrupción.
Ejemplo de descubrimiento de topología con redundancia VRRP
La figura 11 muestra una topología simple en la que se configura una consulta de arrendamiento activa con detección de topología para los pares del agente de retransmisión DHCP en dos BNG que están conectados a través de la red de acceso. Las direcciones del mismo nivel configuradas son 192.0.2.1 y 192.0.2.2. Usaremos esta ilustración para comprender cómo funciona la detección de topología cuando se configura VRRP como protocolo de redundancia y cómo se crean las tablas de traducción para cada agente de retransmisión del mismo nivel.

Después de la sincronización TCP, el par 192.0.2.1 envía una consulta de descubrimiento de topología al par 192.0.2.2 para determinar la interfaz remota coincidente para su propia interfaz local, ge-10/1/2.0. Dado que se trata de una topología DHCPv4, el mensaje que envía es una DHCPLEASEQUERY. La consulta se envía a través de la conexión TCP e incluye la siguiente información:
La dirección IP de subred y la máscara (203.0.113.1/24) de la interfaz de acceso local, transmitidas en DHCPv4 opción 43, subopción 2.
El ID de VLAN (10) configurado en la interfaz de acceso, transmitido en DHCPv4 opción 43, subopción 4.
Un ID de transacción temporal o xid (15), transportado en el encabezado del paquete. DHCP genera un xid aleatorio para cada interfaz de acceso. El xid es único en todo el chasis.
También se incluye en la consulta, pero no se muestra en la figura:
El identificador de cliente, transmitido en la opción 61 de DHCPv4.
El par 192.0.2.2 recibe la consulta y hace coincidir la dirección de subred, la máscara y el ID de VLAN recibidos con una de sus interfaces de acceso local. En este caso, la coincidencia es para la interfaz ge-2/3/9.0.
El par 192.0.2.2 envía una respuesta al par 192.0.2.1 a través de la conexión UDP desde su interfaz de acceso correspondiente, ge-2/3/9.0. La respuesta es un mensaje DHCPLEASEACTIVE e incluye la siguiente información:
La dirección IP de subred y la máscara (203.0.113.2/24) de la interfaz de acceso local, transmitidas en DHCPv4 opción 43, subopción 2.
El ID de VLAN (10) configurado en la interfaz de acceso, transmitido en DHCPv4 opción 43, subopción 4.
Nombre de la interfaz correspondiente (ge-2/3/9.0), que figura en la opción 82.
El mismo identificador de transacción temporal que recibió en la consulta, transmitido en el encabezado IP.
La siguiente información también se incluye en la respuesta, pero no se muestra en la figura:
El identificador de cliente, con el mismo valor que el recibido en la consulta, en la opción 61 de DHCPv4.
El identificador del servidor, en DHCPv4 opción 54.
La dirección de destino IP en el encabezado IP. Esta es la dirección de subred recibida del par 192.0.2.1 (203.0.113.1/24).
La dirección IP de origen en el encabezado IP. Esta es la dirección de subred (203.0.113.2/24) de este agente de retransmisión para la interfaz coincidente (ge-2/3/9.0).
El par 192.0.2.1 recibe la respuesta a través de su interfaz de acceso. Confirma que el ID de transacción de la respuesta coincide con el que envió en la consulta. El ID de transacción y las subopciones específicas del proveedor recibidas en la respuesta proporcionan al agente de retransmisión la información que necesita para asignar las dos interfaces de acceso en su tabla de traducción.
El par 192.0.2.2 realiza los mismos cuatro pasos para poder actualizar su propia tabla de traducción. Cada uno de los pares asociados inicia el descubrimiento de topología para todas sus interfaces de acceso local. De esta manera, cada par construye una tabla de traducción completa para todas sus interfaces.
La Figura 11 muestra la tabla de traducción para cada par que resulta del intercambio de mensajes entre cada par de pares:
El agente de retransmisión en BNG 1 inicia el descubrimiento de topología para sus tres interfaces de acceso.
El agente de retransmisión en BNG 2 inicia el descubrimiento de topología para sus tres interfaces de acceso.
El agente de retransmisión en BNG 3 inicia el descubrimiento de topología para sus dos interfaces de acceso.
Dado que el ID de transacción se genera para una sola interfaz de acceso, la detección de topología se realiza correctamente incluso cuando varias interfaces comparten la misma subred e ID de VLAN.
Por ejemplo, supongamos que dos interfaces en el par 192.0.2.2 (ge-2/3/9 y ge-11/0/7) coinciden con la subred y el ID de VLAN que recibió en la consulta.
Este agente de retransmisión envía una respuesta separada desde cada una de estas interfaces a las interfaces ge-10/1/2.0 y ge-4/2/3.0 del par 192.0.2.1. El ID de transacción no coincide con la interfaz ge-4/2/3.0 porque el interlocutor que realiza la consulta (192.0.2.1) generó el ID para la interfaz ge-10/1/2.0. Por consiguiente, el interlocutor que realiza la consulta actualiza su tabla de traducción sólo para la interfaz ge-10/1/2.0.
Para obtener información detallada acerca de la consulta de arrendamiento activa DHCP, el descubrimiento de topología y cómo funciona con la redundancia de suscriptor M:N, consulte Consulta de arrendamiento activo DHCP y Configuración y uso de consulta de arrendamiento activa DHCP. La sección Mensajes de detección de topología de la consulta de arrendamiento activo DHCP proporciona descripciones de la información y las opciones incluidas en los mensajes de consulta y respuesta DHCP.
Ejemplo de descubrimiento de topología con redundancia de pseudocable
La figura 12 muestra una topología simple en la que se configura una consulta de arrendamiento activa con detección de topología para los pares del agente de retransmisión DHCP en dos BNG que están conectados a través de una red de acceso IP/MPLS. Las direcciones del mismo nivel configuradas son 198.51.100.1 y 198.51.100.5. Usaremos esta ilustración para entender cómo funciona el descubrimiento de topología cuando la red de acceso usa túneles de pseudocable a través de la red IP/MPLS. El descubrimiento de topología para la redundancia de pseudocables usa una clave común compartida configurada estáticamente entre los pares de BNG como criterio de coincidencia. Esto contrasta con la redundancia VRRP, donde la coincidencia se realiza en la subred/máscara y el ID de VLAN. En este ejemplo también se describe cómo se crean las tablas de traducción para cada agente de retransmisión del mismo nivel.
La topología muestra sólo una conexión TCP, porque la redundancia M:N de pseudocable no utiliza UDP para el descubrimiento de topología. En cambio, la redundancia M:N de VRRP utiliza conexiones TCP y UDP.

Después de la sincronización TCP, el par 198.51.100.1 envía una consulta de descubrimiento de topología al par 198.51.100.5 para determinar la interfaz remota coincidente para su propia interfaz local, ps2.0. Dado que se trata de una topología DHCPv4, el mensaje que envía es una DHCPLEASEQUERY. La consulta se envía a través de la conexión TCP e incluye la siguiente información:
La clave común compartida (PseudoWireKey-100.1) configurada en la interfaz local, transmitida en DHCPv4 opción 43, subopción 6.
Un ID de transacción temporal o xid (15), transportado en el encabezado del paquete. DHCP genera un xid aleatorio para cada interfaz de acceso. El xid es único en todo el chasis.
También se incluye en la consulta, pero no se muestra en la figura:
El identificador de cliente, transmitido en la opción 61 de DHCPv4.
El par 198.51.100.5 recibe la consulta y hace coincidir la clave común compartida recibida con una de sus interfaces de acceso local. En este caso, la coincidencia es para la interfaz ps5.0.
El par 198.51.100.5 envía una respuesta a través de la conexión TCP al par 198.51.100.1. La respuesta es un mensaje DHCPLEASEACTIVE e incluye la siguiente información:
La clave común compartida (PseudoWireKey-100.1) que recibió en la consulta, transmitida en DHCPv4 opción 43, subopción 6.
El mismo identificador de transacción temporal que recibió en la consulta, transmitido en el encabezado IP.
Nombre de la interfaz coincidente (ps5.0), que se transmite en la opción 82.
La siguiente información también se incluye en la respuesta, pero no se muestra en la figura:
El identificador de cliente, con el mismo valor que el recibido en la consulta, en la opción 61 de DHCPv4.
El identificador del servidor, en DHCPv4 opción 54.
El par 198.51.100.1 recibe la respuesta a través de la conexión TCP en banda. Confirma que el ID de transacción de la respuesta coincide con el que envió en la consulta. El identificador de transacción y las subopciones específicas del proveedor recibidas en la respuesta proporcionan al agente de retransmisión la información que necesita para asignar las dos interfaces de acceso (interfaz local ps2.0 e interfaz remota ps5.0) en su tabla de traducción.
Cada uno de los pares asociados en una topología inicia el descubrimiento de topología para cada una de sus interfaces de acceso local. Cada par utiliza los mismos cuatro pasos descritos anteriormente para crear una tabla de traducción completa que mapee sus interfaces locales con interfaces pares. En esta topología de ejemplo, eso significa:
El agente de retransmisión DHCP (R1) en BNG 1 inicia la detección de topología para sus dos interfaces de acceso, ps2.0 y ps3.0.
El agente de retransmisión DHCP (R2) en BNG 2 inicia el descubrimiento de topología para sus dos interfaces de acceso, ps4.0 y ps5.0.
Puede ver la tabla de traducción para cada par que resulta del intercambio de mensajes entre el par de pares en la Figura 12. La misma clave común compartida se configura en ambas interfaces de pseudocable para cada par. Por ejemplo, ps2.0 y ps5.0 tienen la clave PseudoWireKey-100.1. Las interfaces ps3.0 y ps4.0 comparten una clave diferente (no se muestra en la figura).
Ahora considere la topología un poco más compleja, con tres pares, que se muestra en la Figura 13. Tres agentes de retransmisión DHCP en tres BNG realizan el descubrimiento de topología para sus interfaces de pseudocable. Las tablas de traducción resultantes se muestran debajo de cada agente de retransmisión.

Compare las tablas de traducción y las líneas de conexión de pseudocables de color de la figura 13 con los fragmentos de configuración de claves compartidas para cada agente de retransmisión de la figura 14.

Puede ver que la interfaz ps1.0 en R1 tiene la misma clave compartida que la interfaz ps8.0 en R3. Las tablas de traducción para R1 y R3 muestran que esta relación fue descubierta por el proceso de descubrimiento de topología.
Del mismo modo, la interfaz ps2.0 en R1 y ps5.0 en R2 tienen la misma clave compartida. Una vez más, el descubrimiento de topología determinó esta relación y cada agente actualizó su tabla de traducción en consecuencia. Las otras filas de las tablas de traducción se rellenaron de la misma manera.
Para obtener información detallada acerca de la consulta de arrendamiento activa DHCP, el descubrimiento de topología y cómo funciona con la redundancia de suscriptor M:N, consulte Consulta de arrendamiento activo DHCP y Configuración y uso de consulta de arrendamiento activa DHCP. La sección Mensajes de detección de topología de la consulta de arrendamiento activo DHCP proporciona descripciones de la información y las opciones incluidas en los mensajes de consulta y respuesta DHCPv4 y DHCPv6.
Suscriptores estáticos y redundancia M:N
La redundancia de suscriptores M:N 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 suscriptores M:N.
Suscriptores en interfaces estáticas que no ejecutan un protocolo 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 usan 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. Los atributos VRRP se configuran en la interfaz lógica 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 para 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.
Ambos tipos de suscriptores estáticos son administrados por el demonio jsscd. A veces se les conoce como suscriptores estáticos de JSSCD.
Los siguientes fragmentos de configuración de ejemplo muestran cómo crear un grupo de suscriptores estáticos 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 principal de BNG:
El siguiente fragmento de código configura la interfaz subyacente para la interfaz lógica 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 de VRRP en esta subred establece el grupo (el grupo de redundancia de suscriptores) 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 del VRRP es 230. Cuando la copia de seguridad principal conmuta por error a la copia de seguridad, la asunción de la función principal por 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 de suscriptores) 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 del VRRP es 230. Cuando la copia de seguridad principal conmuta por error a la copia de seguridad, la asunción de la función principal por 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 demux IP, demux0.1, sobre la interfaz subyacente, ge-1/1/9.11. También configura la interfaz de circuito cerrado y permite que la dirección local de la interfaz demux IP se derive de la interfaz de 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áticos, static-ifl, que incluye tanto la interfaz de suscriptor estática demux IP (demux0.1) como la interfaz de suscriptor estática 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 la de copia de seguridad.
La prioridad VRRP se establece en 200 para ambas interfaces. Ese valor hace que este sea el BNG de respaldo, ya que 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 están en la misma subred.
El siguiente fragmento de código configura la interfaz subyacente para la interfaz lógica 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 de VRRP en esta subred establece el grupo (el grupo de redundancia de suscriptores) 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 del VRRP es 200. Cuando la copia de seguridad principal conmuta por error 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 de suscriptores) 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 del VRRP es 200. Cuando la copia de seguridad principal conmuta por error a la copia de seguridad, la asunción de la función principal por 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 demux IP, demux0.1, sobre la interfaz subyacente, ge-3/0/1.11. También configura la interfaz de circuito cerrado y permite que la dirección local de la interfaz demux IP se derive de la interfaz de 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áticos, static-ifl, que incluye tanto la interfaz de suscriptor estática demux IP (demux0.1) como la interfaz de suscriptor estática 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 suscriptores M:N
La convergencia es el proceso en el que los enrutadores de una red actualizan sus tablas de enrutamiento individuales cuando se agregan, eliminan o dejan de ser accesibles las rutas de cualquier enrutador debido a un error de vínculo. Los protocolos de enrutamiento en 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, a continuación, 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 red. Por ejemplo, esto significa que los enrutadores tienen un entendimiento común acerca de qué enlaces 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 de suscriptores M:N admite la convergencia de rutas del lado del acceso (ascendente) y del lado del núcleo (descendente). Debido a 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 conmutación por error; es decir, si se produce un error parcial o completo del chasis.
Depende de usted determinar cómo administrar la convergencia de tráfico ascendente y descendente para su red después de una conmutación por error del BNG principal al 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 primario después de que falle el BNG primario original.
En el BNG principal, la interfaz de acceso o el módulo de interfaz deja de funcionar.
VRRP elige el BNG de respaldo como la nueva primaria.
La nueva primaria transmite mensajes ARP gratuitos a la red de acceso. Envía los mensajes desde su interfaz de acceso correspondiente a la interfaz de acceso de la antigua primaria. 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 primarios y de copia de seguridad en modo de espera activa en el nodo de acceso, LDP establece automáticamente los LSP en los BNG primarios y de respaldo. El protocolo de señalización LDP incluye un mecanismo keepalive para detectar fallas en la ruta. En este caso, la convergencia ascendente se logra mediante un conmutador de túnel de capa 2 de pseudocable desde el BNG primario al BNG de respaldo.
Puede configurar temporizadores de mantenimiento activo de LDP para una detección más rápida de errores. Como alternativa, puede ejecutar el protocolo BFD para una conmutación por error más rápida. Cualquiera de los métodos siguientes puede provocar un cambio del pseudocable primario al pseudocable de reserva:
Utilice el
request l2circuit-switchover
comando para activar manualmente un conmutador del pseudocable principal al pseudocable de reserva.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 de LSP entre el nodo de acceso y el BNG principal. En este caso, el BNG todavía está activo.
Un vecino falla cuando el BNG primario deja de funcionar.
Para ambos tipos, la velocidad de detección y cambio se controla mediante la configuración de la
bfd-liveness-detection
instrucción en el[edit protocols ldp oam]
nivel de jerarquía.
Convergencia del tráfico descendente
El tiempo necesario para la convergencia del tráfico descendente se ve afectado por varios factores, entre los que se incluyen los siguientes:
La publicidad de rutas de suscriptores individuales aumenta el número de recálculos de rutas que deben realizar los enrutadores de red central.
Detectar cuándo una interfaz de acceso deja de funcionar y 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 hacia el 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 suscriptor se agreguen para publicidad en el núcleo siempre que sea posible. La agregación se puede lograr mediante el uso de grupos de direcciones o anuncios de rutas basados en políticas, como se describe a continuación. La reducción del número de rutas que deben recalcularse en los enrutadores centrales 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 la carga del tráfico descendente entre el BNG principal y el de respaldo.
Dos métodos que podría considerar son la publicidad de ruta basada en políticas y los enlaces BNG dedicados.
Publicidad de rutas basada en políticas (VRRP y redundancia de pseudocables): 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, se configura BGP, OSPF o cualquier otro protocolo de enrutamiento para anunciar rutas agregadas hacia el núcleo sólo cuando un BNG se convierte en el principal.
Para la redundancia VRRP, configure las directivas BGP para rastrear la dirección IP virtual VRRP. BGP agrega las rutas de suscriptor en función del grupo de redundancia de suscriptor correspondiente a un grupo VRRP. BGP anuncia las rutas agregadas al núcleo cuando el BNG asume el rol principal de VRRP.
Para la redundancia de pseudocables, configure las directivas de BGP para realizar un seguimiento del estado de la interfaz de pseudocable (Arriba o Abajo). BGP agrega rutas para el grupo de redundancia de suscriptores. BGP anuncia las rutas agregadas al núcleo cuando el estado cambia a Up, lo que significa que el BNG de respaldo es ahora el principal.
En cualquier caso, si el BNG principal conmuta por error a la copia de seguridad, el BGP en el primario fallido retira las rutas de suscriptor agregadas para el núcleo. Cuando el BNG de respaldo se convierte en el nuevo principal, a su vez anuncia grupos de suscriptores agregados en el núcleo.
Vínculos dedicados BNG (solo redundancia VRRP): puede reducir el tiempo que se tarda en detectar un error en el BNG principal conectando los BNG con un enlace dedicado. VRRP se configura en la interfaz de acceso para realizar un seguimiento del estado de la interfaz de vínculo dedicado. También puede configurar VRRP en la interfaz de vínculo dedicado para realizar un seguimiento del estado de la interfaz de acceso.
Un error en la interfaz de acceso en el 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 el BNG de copia de seguridad. Este método es más rápido que esperar a que caduque el temporizador de saludo VRRP.
Cómo configurar la redundancia de suscriptor de M:N con la sincronización de enlaces VRRP y DHCP
La redundancia de suscriptor M:N con sincronización de enlaces VRRP y DHCP requiere que configure todo lo siguiente:
Grupos de suscriptores redundantes para especificar los suscriptores que forman parte de la operación principal/de copia de seguridad.
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.
Consulta de arrendamiento activa DHCP con descubrimiento de topología para todos los agentes de retransmisión DHCP del mismo nivel de la topología. Active leasequery es responsable de sincronizar el estado del suscriptor y enlazar la información entre los agentes de retransmisión del mismo nivel. La detección de topología permite a los agentes de retransmisión del mismo nivel determinar las interfaces de acceso remoto para sus grupos de redundancia de suscriptor, de modo que puedan crear tablas de traducción de interfaces locales y remotas para admitir el esquema de redundancia principal/de reserva de M:N.
En este tema se describen solo las configuraciones básicas necesarias para la redundancia de suscriptor M:N en los BNG que alojan los agentes de retransmisión DHCP del mismo nivel. No describe todos los aspectos de lo siguiente: administración global de suscriptores, la configuración de VRRP que puede usar en la red, agentes de retransmisión DHCP o consulta de arrendamiento DHCP. Para obtener más información sobre estos temas, consulte lo siguiente:
La redundancia de suscriptor M:N requiere que los BNG primarios y de respaldo admitan las mismas versiones de protocolo para DHCP y VRRP. Si la compatibilidad con el protocolo es diferente entre las BNG, es posible que vea efectos secundarios no deseados.
Los suscriptores de redundancia de doble pila tienen los siguientes requisitos:
Configuración DHCP: debe configurar la consulta de concesión activa con detección de topología para DHCPv4 y DHCPv6.
Configuración de 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 rol principal de VRRP para las sesiones IPv4 e IPv6 para un grupo de redundancia determinado, ya que comparten la misma interfaz lógica.
- Configurar redundancia de grupo de suscriptores
- Configurar VRRP para admitir redundancia M:N
- Configuración de Active Leasequery con detección de topología
Configurar redundancia de grupo de suscriptores
Para configurar la redundancia de grupo de suscriptores en un BNG:
Configurar VRRP para admitir redundancia M:N
Para configurar VRRP para que admita la redundancia M:N para un grupo de redundancia de suscriptor en un BNG:
Configuración de Active Leasequery con detección de topología
Habilite la consulta de arrendamiento activa con detección de topología en el par de agentes de retransmisión DHCP que admiten un grupo de redundancia de suscriptor determinado. Debe repetir la configuración para cada par de agentes de retransmisión para diferentes grupos de redundancia.
Los pasos siguientes describen la configuración de DHCPv4. Para DHCPv6, utilice el procedimiento en el nivel de [edit forwarding-options dhcp-relay dhcpv6]
jerarquía.
Para los suscriptores de doble pila, debe configurar la consulta de arrendamiento activa con detección de topología para DHCPv4 y DHCPv6.
Dado que la leasequery activa es una extensión de la leasequery masiva, también debe configurar la leasequery masiva para que funcione la leasequery activa. Debe configurar la consulta de arrendamiento masiva antes de configurar la consulta de arrendamiento activa. Consulte Configuración y uso de la consulta de arrendamiento masivo DHCP.
Cómo configurar la redundancia de suscriptor de M:N con pseudocables y sincronización de enlace DHCP
La redundancia de suscriptores M:N con pseudocables y sincronización de enlaces DHCP requiere que configure todo lo siguiente:
Grupos de suscriptores redundantes para especificar los suscriptores que forman parte de la operación principal/de copia de seguridad.
Consulta de arrendamiento activa DHCP con descubrimiento de topología para todos los agentes de retransmisión DHCP del mismo nivel de la topología. Active leasequery es responsable de sincronizar el estado del suscriptor y enlazar la información entre los agentes de retransmisión del mismo nivel. La detección de topología permite a los agentes de retransmisión del mismo nivel determinar las interfaces de acceso remoto para sus grupos de redundancia de suscriptor, de modo que puedan crear tablas de traducción de interfaces locales y remotas para admitir el esquema de redundancia principal/de reserva de M:N.
La redundancia de suscriptores M:N con pseudocables funciona en una red IP/MPLS donde los túneles de pseudocable desde un nodo de acceso (como un conmutador) forman los circuitos L2 hacia los BNG primarios y de respaldo que actúan como agentes de retransmisión DHCP. Esas configuraciones están fuera del ámbito de esta documentación.
En este tema se describen solo las configuraciones básicas necesarias para la redundancia de suscriptor M:N en los BNG que alojan los agentes de retransmisión DHCP del mismo nivel. No describe todos los aspectos de lo siguiente: administración global de suscriptores, agentes de retransmisión DHCP o consulta de arrendamiento 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 o 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 el BNG principal y el de respaldo admitan las mismas versiones de protocolo para DHCP. Si la compatibilidad con el protocolo es diferente entre las BNG, es posible que vea efectos secundarios no deseados.
Los suscriptores de redundancia de doble pila tienen el siguiente requisito:
Configuración DHCP: debe configurar la consulta de concesión activa con detección de topología para DHCPv4 y DHCPv6.
- Configurar redundancia de grupo de suscriptores
- Configuración de Active Leasequery con detección de topología
Configurar redundancia de grupo de suscriptores
Para configurar la redundancia de grupo de suscriptores en un BNG:
Por ejemplo, puede configurar lo siguiente en un 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. Eso significa que ps2.0 y ps5.0 son las interfaces de acceso asociadas para la redundancia de pseudocables. Del mismo modo, 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
Configuración de Active Leasequery con detección de topología
Habilite la consulta de arrendamiento activa con detección de topología en el par de agentes de retransmisión DHCP que admiten un grupo de redundancia de suscriptor determinado. Debe repetir la configuración para cada par de agentes de retransmisión para diferentes grupos de redundancia.
Los pasos siguientes describen la configuración de DHCPv4. Para DHCPv6, utilice el procedimiento en el nivel de [edit forwarding-options dhcp-relay dhcpv6]
jerarquía.
Para los suscriptores de doble pila, debe configurar la consulta de arrendamiento activa con detección de topología para DHCPv4 y DHCPv6.
Dado que la leasequery activa es una extensión de la leasequery masiva, también debe configurar la leasequery masiva para que funcione la leasequery activa. Debe configurar la consulta de arrendamiento masiva antes de configurar la consulta de arrendamiento activa. Consulte Configuración y uso de la consulta de arrendamiento masivo DHCP.
Comprobación de la redundancia M:N y la información de descubrimiento de topología de Active Leasequery
Propósito
Determine la información de estado y las estadísticas de las interfaces de acceso, los agentes de retransmisión y los suscriptores que forman parte de la topología para la redundancia M:N con la detección de topología de consulta de arrendamiento activa DHCP.
Acción
Para verificar el estado de redundancia VRRP de las interfaces de acceso:
user@host>show vrrp
Para comprobar que el estado de redundancia de una interfaz lógica de acceso especificada se encuentra
Master
en el agente de retransmisión principal yBackup
en el agente de retransmisión de copia de seguridad:user@host>show system subscriber-management redundancy-state dhcp active-leasequery interface interface-name
Esta interfaz puede ser una interfaz de suscriptor o la interfaz VLAN subyacente. Para la redundancia VRRP, el estado de redundancia es el mismo que el estado VRRP de la interfaz lógica subyacente. Para la redundancia de pseudocable, el estado de redundancia se basa en el estado de la interfaz de pseudocable.
Para comprobar que los suscriptores de un grupo de redundancia están activos tanto en el agente de retransmisión principal como en el de respaldo:
user@host>show subscribers option
El
show subscribers
comando tiene varias opciones; puede mostrar suscriptores por dirección IP, nombre de interfaz, ID de VLAN, ID de circuito de agente, estado del suscriptor, etc.Para comprobar que la información del enlace de retransmisión DHCP es la misma para los suscriptores de un grupo de redundancia tanto en los agentes de retransmisión principales como en los de copia de seguridad:
user@host>show dhcp relay binding verbose user@host>show dhcpv6 relay binding verbose
También puede especificar resultados para una dirección IP o una interfaz.
Para ver una lista de todos los pares de leasequery activos:
user@host>show dhcp relay active-leasequery summary user@host>show dhcpv6 relay active-leasequery summary
Para ver la tabla de traducción de detección de topología para un agente de retransmisión del mismo nivel, incluidos los ID de circuito local y remoto (interfaces de acceso), la dirección de interfaz de acceso local, el ID de transacción (xid) y el estado de descubrimiento de topología, redundancia y sincronización de suscriptores:
user@host>show dhcp relay active-leasequery peer address details user@host>show dhcpv6 relay active-leasequery peer address details
Para ver estadísticas de leasequery activas, como el número de enlaces DHCP enviados o recibidos para una interfaz o par.
user@host>show dhcp relay active-leasequery statistics (interface interface-name | peer ip-address) user@host>show dhcpv6 relay active-leasequery statistics (interface interface-name | peer ipv6-address)
Para borrar las estadísticas de leasequery activas.
user@host>clear dhcp relay active-leasequery statistics (interface interface-name | peer ip-address) user@host>clear dhcpv6 relay active-leasequery statistics (interface interface-name | peer ipv6-address)
Tabla de historial de cambios
La compatibilidad con las funciones viene determinada por la plataforma y la versión que esté utilizando. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.