Actualizar Junos OS en una configuración de multiconexión EVPN
Acerca de este ejemplo de configuración de red
Utilice este ejemplo de configuración de red para actualizar manualmente Junos OS en un par de dispositivos Junos OS o Junos Evolved configurados para EVPN Muiltihoming (también llamado ESI-LAG) a un servidor conectado (host).
Este ejemplo se basa en una configuración preexistente de EVPN de puente enrutado en borde (ERB) mediante conmutadores QFX. Los pasos que se muestran aquí también se aplican a las arquitecturas de puentes de enrutamiento centralizado (CRB) y EVPN de superposición en puente.
Para obtener más información sobre las plataformas compatibles y la compatibilidad de las versiones de Junos o Junos Evolved para EVPN ESI-LAG, consulte el Explorador de características.
Ejemplo: Actualizar Junos OS en un caso de uso de multiconexión EVPN
- Requisitos
- Descripción general del procedimiento
- Configuración de actualización de multiconexión EVPN
- Conclusión
Requisitos
Use este procedimiento para actualizar un par de conmutadores leaf serie QFX que están configurados para admitir datos adjuntos de host multihost EVPN.
Antes de empezar:
Asegúrese de que el acceso a la consola esté disponible para ambos dispositivos leaf.
Asegúrese de que la dirección MAC del host esté presente en la base de datos EVPN de ambos dispositivos leaf.
Se recomienda configurar un
hold-time upvalor de temporizador de 60 segundos (60000 milisegundos) en las interfaces LAG en ambos conmutadores de hoja. Consulte el tiempo de espera para obtener más información sobre esta opción. La configuración de un temporizador de retención ayuda a garantizar que la interfaz de miembro LAG orientada al host no entre en funcionamiento antes de que el conmutador haya completado su intercambio de ruta BGP después de un evento de reinicio.En este ejemplo se generan pings desde el host de host múltiple a la dirección de puerta de enlace virtual configurada en la interfaz IRB de la VLAN. Debe agregar la
virtual-gateway-accept-dataopción a las interfaces IRB de ambos conmutadores para que generen respuestas de ping.
En este ejemplo se utilizan los siguientes componentes de hardware y software:
Dos dispositivos QFX5100-48S-6Q que inicialmente ejecutan Junos OS versión 19.1R3.9
Junos OS versión 19.2R1.8
Un servidor Ubuntu o Centos con un enlace a ambos conmutadores ToR. El servidor está configurado con una interfaz de enlace en modo 4 para admitir la agregación de vínculos basada en LACP.
Descripción general del procedimiento
En esta sección se proporciona información general sobre el procedimiento de actualización. La secuencia de pasos está diseñada para minimizar las interrupciones al actualizar un par de conmutadores leaf que admiten hosts de host múltiple:
Prepárese para la actualización:
Confirme que las interfaces LAG estén operativas en ambos conmutadores y que el plano de control de EVPN haya convergido.
Copie la imagen de Junos OS deseada en el directorio /var/tmp de ambos conmutadores.
Inicie un ping desde el host de host múltiple a un destino de superposición en la misma VLAN. Por ejemplo, una interfaz IRB en los dispositivos de columna vertebral para CRB o en los dispositivos leaf para ERB. Este paso se realiza para permitirle determinar posteriormente el grado de pérdida de paquetes asociado con el procedimiento de actualización.
Seleccione el conmutador que desea actualizar y desactive la interfaz de enlace descendente al servidor o host.
Actualice y reinicie el conmutador a la nueva versión de Junos. Confirme que el conmutador está ejecutando la nueva versión.
Compruebe el plano de control de EVPN para confirmar que el conmutador actualizado ha vuelto a aprender la dirección MAC del host del enlace descendente.
Habilite la interfaz de enlace descendente del conmutador actualizado.
Repita los pasos 3 a 6 en el otro conmutador para completar la actualización.
Detenga los pings generados por el host y confirme el número de paquetes perdidos durante el procedimiento de actualización.
Nota:El procedimiento de actualización no está exento de hits. Los paquetes en tránsito en el vínculo descendente se pueden perder cuando la interfaz está deshabilitada en preparación para la actualización. Una vez que la interfaz está deshabilitada, el tráfico cambia al otro conmutador leaf y continúa fluyendo. En este procedimiento, hay dos pequeñas ventanas de pérdida cuando se deshabilita la interfaz de miembro LAG en cada conmutador que se va a actualizar. Estas ventanas de pérdida no deben exceder los 50 milisegundos.
Topología
La figura 1 ilustra la topología de este ejemplo de actualización de EVPN Multihoming. Tenga en cuenta que ambos conmutadores tienen una interfaz IRB configurada para la VLAN asociada con el host conectado. Estos IRB se configuran con una dirección de puerta de enlace virtual compartida de 192.168.0.1. Al host se le asigna la dirección 192.1689.1.100 en su interfaz bond0. El diagrama también detalla la dirección MAC de la interfaz bond0 en el host y el identificador de segmento Ethernet (ESI) configurado en la interfaz LAG de ambos conmutadores leaf.
Configuración de actualización de multiconexión EVPN
Preparación para la actualización
Procedimiento paso a paso
Compruebe que la multiconexión de EVPN esté operativa. Inicie sesión en el servidor y confirme que la interfaz de enlace está activa. Mientras esté allí, tome nota de la dirección MAC de la interfaz bond0. En este ejemplo, el host está ejecutando Ubuntu, por lo que se usa el
ifconfigcomando. Si utiliza una distribución de Centos utilice elip link show bond0comando. La dirección MAC de la interfaz bond0 del host en este ejemplo es 00:1B:21:79:5A:EC.root@server-host# ifconfig bond0 bond0 Link encap:Ethernet HWaddr 00:1B:21:79:5A:EC inet addr:192.168.100.100 Bcast:192.168.100.255 Mask:255.255.255.0 inet6 addr: fe80::21b:21ff:fe79:5aec/64 Scope:Link UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:99980 errors:0 dropped:0 overruns:0 frame:0 TX packets:2997762 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:12393700 (11.8 MiB) TX bytes:371717722 (354.4 MiB)Confirme que la interfaz LAG esté operativa en ambos dispositivos leaf con un
show interfaces ae1comando. En este ejemplo, la interfaz LAG está ae1 en ambos dispositivos leaf. Tenga en cuenta que el número de interfaz agregado es un índice local que puede variar entre los dos dispositivos leaf. No es el nombre de la interfaz, sino la configuración de ESI ysystem-idparámetros coincidentes lo que enlaza lógicamente la interfaz LAG entre las dos hojas. Asegúrese de confirmar que la interfaz LAG esté activa en ambos dispositivos leaf.El resultado confirma que la interfaz LAG está operativa y que el ESI está configurado como 00:01:01:01:01:01:01:01 :01:01 en ambas hojas.
root@leaf3> show interfaces ae1 Physical interface: ae1, Enabled, Physical link is Up Interface index: 640, SNMP ifIndex: 529 Link-level type: Ethernet, MTU: 1514, Speed: 10Gbps, BPDU Error: None, Ethernet-Switching Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled, Minimum links needed: 1, Minimum bandwidth needed: 1bps Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x4000 Current address: 10:0e:7e:b5:7e:f0, Hardware address: 10:0e:7e:b5:7e:f0 Ethernet segment value: 00:01:01:01:01:01:01:01:01:01, Mode: all-active Last flapped : 2020-05-06 21:44:35 UTC (1d 09:25 ago) Input rate : 960 bps (0 pps) Output rate : 0 bps (0 pps) Logical interface ae1.0 (Index 550) (SNMP ifIndex 530) Flags: Up SNMP-Traps 0x24024000 Encapsulation: Ethernet-Bridge Statistics Packets pps Bytes bps Bundle: Input : 0 0 0 0 Output: 0 0 0 0 Adaptive Statistics: Adaptive Adjusts: 0 Adaptive Scans : 0 Adaptive Updates: 0 Protocol eth-switch, MTU: 1514 Flags: Is-Primaryroot@leaf2> show interfaces ae1 Physical interface: ae1, Enabled, Physical link is Up Interface index: 640, SNMP ifIndex: 541 Link-level type: Ethernet, MTU: 1514, Speed: 10Gbps, BPDU Error: None, Ethernet-Switching Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled, Minimum links needed: 1, Minimum bandwidth needed: 1bps Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x4000 Current address: f4:b5:2f:44:af:30, Hardware address: f4:b5:2f:44:af:30 Ethernet segment value: 00:01:01:01:01:01:01:01:01:01, Mode: all-active Last flapped : 2020-05-08 05:58:07 UTC (01:22:18 ago) Input rate : 968 bps (0 pps) Output rate : 0 bps (0 pps) Logical interface ae1.0 (Index 554) (SNMP ifIndex 542) Flags: Up SNMP-Traps 0x24024000 Encapsulation: Ethernet-Bridge Statistics Packets pps Bytes bps Bundle: Input : 0 0 0 0 Output: 0 0 0 0 Adaptive Statistics: Adaptive Adjusts: 0 Adaptive Scans : 0 Adaptive Updates: 0 Protocol eth-switch, MTU: 1514 Flags: Is-PrimaryUtilice el valor ESI indicado en el paso anterior para confirmar que la dirección MAC del host está presente en la base de datos EVPN de ambos conmutadores miembro.
root@leaf3> show evpn database | match esi 00:01:01:01:01:01:01:01:01:01 Instance: default-switch VLAN DomainId MAC address Active source Timestamp IP address 10100 00:1b:21:79:5a:ec 00:01:01:01:01:01:01:01:01:01 May 08 08:23:11 192.168.100.100root@leaf3> show evpn database | match esi 00:01:01:01:01:01:01:01:01:01 Instance: default-switch VLAN DomainId MAC address Active source Timestamp IP address 10100 00:1b:21:79:5a:ec 00:01:01:01:01:01:01:01:01:01 May 07 22:06:11 192.168.100.100Muestra la configuración de interfaz agregada en ambos dispositivos leaf. Tenga en cuenta que la
hold-time upopción está configurada para 6 segundos, de acuerdo con las recomendaciones de este ejemplo.root@leaf3> show configuration interfaces ae1 esi { 00:01:01:01:01:01:01:01:01:01; all-active; } aggregated-ether-options { lacp { active; system-id 00:00:01:01:01:01; hold-time up 6000; } } unit 0 { family ethernet-switching { interface-mode access; vlan { members v100; } } }root@leaf2> show configuration interfaces ae1 esi { 00:01:01:01:01:01:01:01:01:01; all-active; } aggregated-ether-options { lacp { active; system-id 00:00:01:01:01:01; hold-time up 6000; } } unit 0 { family ethernet-switching { interface-mode access; vlan { members v100; } } }Tome nota del nombre de la interfaz de miembro LAG en ambos conmutadores. Deberá apagar esta interfaz en el conmutador que se está actualizando. Es común que los nombres de interfaz de los miembros del LAG varíen entre un par de conmutadores. En este ejemplo, la interfaz miembro del LAG es xe-0/0/46 en ambos dispositivos leaf.
root@leaf3> show lacp interfaces Aggregated interface: ae1 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-0/0/46 Actor No No Yes Yes Yes Yes Fast Active xe-0/0/46 Partner No No Yes Yes Yes Yes Slow Active LACP protocol: Receive State Transmit State Mux State xe-0/0/46 Current Slow periodic Collecting distributing . . .root@leaf2# run show lacp interfaces Aggregated interface: ae1 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-0/0/46 Actor No No Yes Yes Yes Yes Fast Active xe-0/0/46 Partner No No Yes Yes Yes Yes Slow Active LACP protocol: Receive State Transmit State Mux State xe-0/0/46 Current Slow periodic Collecting distributing . . .Transfiera la imagen de Junos OS deseada a ambos dispositivos leaf, como se muestra en la figura 2. Asegúrese de colocar la imagen en el directorio /var/tmp de los conmutadores. Normalmente, se utiliza FTP o SCP para copiar la imagen en los dispositivos leaf. Para obtener más información sobre el uso de la CLI para copiar archivos, consulte Copia de archivos.
Nota:Considere la posibilidad de ejecutar el comando antes de transferir la nueva imagen para asegurarse de que hay suficiente espacio para la
request system storage cleanupactualización.Figura 2: Transferir la nueva imagen
de Junos
Confirme la versión inicial de Junos OS en ambas hojas de multiconexión de EVPN. En este ejemplo, la versión inicial de Junos OS es 19.1R3.9. Para abreviar, solo se muestra la salida de la hoja 2.
root@leaf2> show version localre: -------------------------------------------------------------------------- Hostname: leaf2 Model: qfx5100-48s-6q Junos: 19.1R3.9 JUNOS OS Kernel 64-bit [20200219.fb120e7_builder_stable_11] JUNOS OS libs [20200219.fb120e7_builder_stable_11] JUNOS OS runtime [20200219.fb120e7_builder_stable_11] JUNOS OS time zone information [20200219.fb120e7_builder_stable_11] JUNOS OS libs compat32 [20200219.fb120e7_builder_stable_11] JUNOS OS 32-bit compatibility [20200219.fb120e7_builder_stable_11] JUNOS py extensions [20200326.053318_builder_junos_191_r3] . . .Los pasos realizados hasta ahora indican que las interfaces LAG están operativas y que el plano de control EVPN está en convergencia. Antes de comenzar la actualización, inicie un ping desde el host a la dirección IP de la puerta de enlace virtual asignada a la interfaz IRB de la VLAN. Este tráfico se dirigirá a un enlace de miembro u otro. No importa a qué conmutador envíe el tráfico el host, ya que ambos conmutadores están configurados con la misma IP de puerta de enlace virtual.
Es importante tener en cuenta que cualquiera de los modificadores puede responder al ping. Esto significa que cuando un conmutador se está reiniciando, el otro permanece disponible y capaz de responder a los pings.
Nota:Para que los pings se realicen correctamente, debe asegurarse de que la interfaz IRB esté configurada con la
virtual-gateway-accept-dataopción en ambos conmutadores.[root@serverhost ~]# ping 192.168.100.1 PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data. 64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=3.80 ms 64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=1.93 ms 64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=8.81 ms 64 bytes from 192.168.100.1: icmp_seq=4 ttl=64 time=2.91 ms 64 bytes from 192.168.100.1: icmp_seq=5 ttl=64 time=1.34 ms 64 bytes from 192.168.100.1: icmp_seq=6 ttl=64 time=15.0 ms ...
Asegúrese de que los pings de la interfaz de host a IRB permanezcan ejecutándose durante todo el procedimiento de actualización para que pueda determinar el número total de paquetes que se pierden.
Actualizar hoja 3
Procedimiento paso a paso
Para comenzar el proceso de actualización en la hoja 3, apague el servidor orientado hacia el miembro del LAG xe-0/0/46, como se muestra en la "X" roja de la figura 3.
Nota:Un pequeño número de paquetes en tránsito en la interfaz xe-0/0/46 de la hoja 3 puede perderse durante este paso. En este momento, el tráfico de ping fluye a través del dispositivo leaf 2 hasta que se completa la actualización y se vuelve a habilitar la interfaz de enlace descendente en leaf 3.
Figura 3: Deshabilitar la interfaz de enlace descendente en Leaf 3
[edit interface xe-0/0/46] root@leaf3# set disable
[edit interface xe-0/0/46] root@leaf3# commit and-quit
Utilice una conexión de consola para iniciar la actualización en la hoja 3 mediante un
request system software add /var/tmp/jinstall-host-qfx-5e-x86-64-19.2R1.8-secure-signed.tgz rebootcomando. La carga de imágenes y los procesos de reinicio posteriores están representados por los iconos de engranaje de la figura 4. El proceso de actualización tarda varios minutos en completarse. Durante este tiempo, sus pings deben fluir a través de la hoja 2, ya que permanece completamente operativa durante la actualización de la hoja 3.Figura 4: Iniciar la actualización de Leaf 3
Después de reiniciar el conmutador, confirme que la actualización se realizó correctamente.
root@leaf3> show version localre: -------------------------------------------------------------------------- Hostname: leaf3 Model: qfx5100-48s-6q Junos: 19.2R1.8 JUNOS OS Kernel 64-bit [20190517.f0321c3_builder_stable_11] JUNOS OS libs [20190517.f0321c3_builder_stable_11] JUNOS OS runtime [20190517.f0321c3_builder_stable_11] JUNOS OS time zone information [20190517.f0321c3_builder_stable_11] JUNOS OS libs compat32 [20190517.f0321c3_builder_stable_11] JUNOS OS 32-bit compatibility [20190517.f0321c3_builder_stable_11] JUNOS py extensions [20190621.152752_builder_junos_192_r1] JUNOS py base [20190621.152752_builder_junos_192_r1] JUNOS OS vmguest [20190517.f0321c3_builder_stable_11] JUNOS OS crypto [20190517.f0321c3_builder_stable_11] . . .En este momento, se deben restablecer todas las sesiones de BGP subyacentes y superpuestas. Confirme que todos los pares BGP hayan realizado una copia de seguridad y que el plano de control de EVPN haya vuelto a converger antes de habilitar la interfaz de miembro lag en la hoja 3.
root@leaf3> show evpn database esi 00:01:01:01:01:01:01:01:01:01 Instance: default-switch VLAN DomainId MAC address Active source Timestamp IP address 10100 00:1b:21:79:5a:ec 00:01:01:01:01:01:01:01:01:01 May 08 08:40:33 192.168.100.100Habilite la interfaz de enlace descendente en la hoja 3, como se muestra en la marca de verificación verde de la figura 5.
Figura 5: Habilitar la interfaz de enlace descendente en la hoja 3
[edit interface xe-0/0/46] root@leaf3# delete disable
[edit interface xe-0/0/46] root@leaf3# commit and-quit
Actualizar leaf2
Procedimiento paso a paso
Comience el procedimiento de actualización en la hoja 2 deshabilitando su interfaz de vínculo descendente, como se muestra en la X roja de la figura 6. Debido a que es probable que los pings fluyan a través de la hoja 2, este paso marca la segunda ventana de pérdida en el procedimiento. Los pings deben seguir fluyendo a través del dispositivo leaf 3 a medida que actualiza leaf 2.
Figura 6: Deshabilitar la interfaz de enlace descendente en leaf2
[edit interface xe-0/0/46] root@leaf2# set disable
[edit interface xe-0/0/46] root@leaf2# commit and-quit
Inicie la carga de la imagen y reinicie en la hoja 2 con un
request system software add /var/tmp/jinstall-host-qfx-5e-x86-64-19.2R1.8-secure-signed.tgzcomando. La actualización y el reinicio de la hoja 2 son como se muestran con los iconos de engranaje de la figura 7.Figura 7: Iniciar la actualización en Leaf 2
Después de reiniciar la hoja 2, compruebe la versión de Junos OS para asegurarse de que la actualización se realizó correctamente.
root@leaf2> show version localre: -------------------------------------------------------------------------- Hostname: leaf2 Model: qfx5100-48s-6q Junos: 19.2R1.8 JUNOS OS Kernel 64-bit [20190517.f0321c3_builder_stable_11] JUNOS OS libs [20190517.f0321c3_builder_stable_11] JUNOS OS runtime [20190517.f0321c3_builder_stable_11] JUNOS OS time zone information [20190517.f0321c3_builder_stable_11] JUNOS OS libs compat32 [20190517.f0321c3_builder_stable_11] JUNOS OS 32-bit compatibility [20190517.f0321c3_builder_stable_11] JUNOS py extensions [20190621.152752_builder_junos_192_r1] JUNOS py base [20190621.152752_builder_junos_192_r1] JUNOS OS vmguest [20190517.f0321c3_builder_stable_11] JUNOS OS crypto [20190517.f0321c3_builder_stable_11] . . .Compruebe que el plano de control de EVPN ha vuelto a converger en la hoja 2. Toda la sesión BGP puede tardar unos minutos en restablecerse y en rellenar la dirección MAC del host en la base de datos EVPN.
root@leaf2> show evpn database esi 00:01:01:01:01:01:01:01:01:01 Instance: default-switch VLAN DomainId MAC address Active source Timestamp IP address 10100 00:1b:21:79:5a:ec 00:01:01:01:01:01:01:01:01:01 May 08 08:53:30Habilite la interfaz de miembro LAG en la hoja 2, como se muestra con la marca de verificación verde de la figura 8.
Figura 8: Habilitar la interfaz de enlace descendente en la hoja 2
[edit interface xe-0/0/46] root@leaf2# delete disable
[edit interface xe-0/0/46] root@leaf2# commit and-quit
Ambos conmutadores ya están actualizados y todas las interfaces miembro del LAG vuelven a estar operativas. Para medir la interrupción del tráfico durante el proceso de actualización, detenga el ping y anote las estadísticas de ping. En este ejemplo, se pierden un total de dos paquetes durante la actualización del par de dispositivos leaf que admiten el host de host múltiple.
En muchos casos, la pérdida de un solo paquete se muestra cuando se interrumpe un ping en curso. En cualquier caso, ya sea que se hayan perdido 1 o 2 paquetes, la actualización se considera prácticamente sin problemas. Esto está de acuerdo con las expectativas del procedimiento demostrado en este ejemplo.
[root@serverhost ~]# ping 192.168.100.1 ... 64 bytes from 192.168.100.1: icmp_seq=1621 ttl=64 time=0.465 ms 64 bytes from 192.168.100.1: icmp_seq=1622 ttl=64 time=7.52 ms 64 bytes from 192.168.100.1: icmp_seq=1623 ttl=64 time=0.920 ms 64 bytes from 192.168.100.1: icmp_seq=1624 ttl=64 time=8.48 ms 64 bytes from 192.168.100.1: icmp_seq=1625 ttl=64 time=9.89 ms 64 bytes from 192.168.100.1: icmp_seq=1626 ttl=64 time=8.95 ms 64 bytes from 192.168.100.1: icmp_seq=1627 ttl=64 time=1.85 ms ^C --- 192.168.100.1 ping statistics --- 1627 packets transmitted, 1625 received, 0% packet loss, time 1628654ms rtt min/avg/max/mdev = 0.260/8.371/87.282/11.096 ms
Conclusión
La multiconexión de EVPN es una característica importante para una arquitectura de centro de datos que debe admitir tanto alto rendimiento como alta disponibilidad. En este ejemplo se muestra la configuración y los pasos necesarios para actualizar un par de conmutadores leaf que admiten conexiones de host multihost con una interrupción mínima.