Ajude-nos a melhorar a sua experiência.

Conte-nos a sua opinião.

Tem dois minutos para uma pesquisa?

external-header-nav
keyboard_arrow_up
close
keyboard_arrow_left
list Table of Contents

Esta tradução automática foi útil?

starstarstarstarstar
Go to English page
ISENÇÃO DE RESPONSABILIDADE:

Esta página será traduzida com software de tradução por máquina de terceiros. Embora esforços razoáveis tenham sido feitos para fornecer uma tradução de qualidade, a Juniper Networks não pode garantir sua exatidão. Se houver dúvidas sobre a exatidão das informações contidas nesta tradução, consulte a versão em inglês. O PDF para download está disponível apenas em inglês.

Atualize o Junos OS em uma configuração multihoming EVPN

date_range 31-Aug-23

Sobre este exemplo de configuração de rede

Use este exemplo de configuração de rede para atualizar manualmente o Junos OS em um par de dispositivos Junos OS ou Junos Evolved que estão configurados para EVPN Muiltihoming (também chamado de ESI-LAG) para um servidor conectado (host).

Este exemplo é baseado em uma configuração EVPN de ponte com roteamento de borda (ERB) pré-existente usando switches QFX. As etapas demonstradas aqui também são aplicáveis às arquiteturas de EVPN (CentralLy-Routed Bridging, Pontes e Overlay) com pontes.

Para obter mais informações sobre plataformas suportadas e o suporte de versão Junos ou Junos Evolved para EVPN ESI-LAG, veja Feature Explorer.

Exemplo: atualize o Junos OS em um caso de uso multihoming EVPN

Requisitos

Use esse procedimento para atualizar um par de switches leaf da série QFX que estão configurados para oferecer suporte a anexos de host Multihomed EVPN.

Antes de começar:

  • Certifique-se de que o acesso ao console esteja disponível para ambos os dispositivos leaf.

  • Certifique-se de que o endereço MAC do host esteja presente no banco de dados EVPN de ambos os dispositivos leaf.

  • É recomendável configurar um hold-time up valor de temporizador de 60 segundos (60000 milissegundos), nas interfaces LAG em ambos os switches leaf. Consulte o tempo de espera para obter detalhes sobre essa opção. Configurar um temporizador de espera ajuda a garantir que a interface de membro LAG voltada para o host não fique operacional antes que o switch tenha concluído sua troca de rotas BGP após um evento de reinicialização.

  • Este exemplo gera pings do host multihomed para o endereço de gateway virtual configurado na interface IRB da VLAN. Você deve adicionar a opção virtual-gateway-accept-data às interfaces IRB de ambos os switches para que eles gerem respostas de ping.

Este exemplo usa os seguintes componentes de hardware e software:

  • Dois dispositivos QFX5100-48S-6Q inicialmente executando o Junos OS Release 19.1R3.9

  • Versão Junos OS 19.2R1.8

  • Um servidor Ubuntu ou Centos com um link para ambos os switches ToR. O servidor está configurado com uma interface de vínculo do modo 4 para oferecer suporte à agregação de enlaces baseados em LACP.

Visão geral do procedimento

Esta seção fornece uma visão geral do procedimento de atualização. A sequência de etapas foi projetada para minimizar a interrupção ao atualizar um par de switches leaf que oferecem suporte a hosts multihomed:

  1. Prepare-se para o upgrade:

    • Confirme que as interfaces LAG estão operacionais em ambos os switches e o plano de controle EVPN convergiu.

    • Copie a imagem desejada do Junos OS para o /var/tmp directory em ambos os switches.

  2. Inicie um ping do host multihomed para um destino overlay na mesma VLAN. Por exemplo, uma interface IRB nos dispositivos spine para CRB, ou nos dispositivos leaf para ERB. Essa etapa é realizada para permitir que você determine mais tarde o grau de perda de pacotes associado ao procedimento de atualização.

  3. Selecione o switch para ser atualizado e desativar a interface de downlink para o servidor ou host.

  4. Atualize e reinicialize o switch para a nova versão Junos. Confirme que o switch está executando a nova versão.

  5. Verifique o plano de controle EVPN para confirmar que o switch atualizado ganhou o endereço MAC do host downlink.

  6. Habilite a interface de downlink do switch atualizado.

  7. Repita as etapas 3 a 6 no outro switch para concluir a atualização.

  8. Pare os pings gerados pelo host e confirme o número de pacotes perdidos durante o procedimento de atualização.

    Nota:

    O procedimento de atualização não é imbatível. Os pacotes em trânsito no downlink podem ser perdidos quando a interface é desativada em preparação para a atualização. Uma vez que a interface é desabilitada, o tráfego muda para o outro switch leaf e continua a fluir. Neste procedimento, existem duas janelas de perda pequenas quando você desativa a interface de membro LAG em cada switch que está sendo atualizado. Essas janelas de perda não devem exceder 50 milissegundos.

Topologia

A Figura 1 ilustra a topologia deste exemplo de atualização multihoming EVPN. Observe que ambos os switches têm uma interface IRB configurada para a VLAN associada ao host anexado. Essas IRBs estão configuradas com um endereço de gateway virtual compartilhado de 192.168.0.1. O host recebe o endereço 192.1689.1.100 em sua interface bond0. O diagrama também detalha o endereço MAC da interface bond0 no host e no identificador de segmentos Ethernet (ESI) que está configurado na interface LAG de ambos os switches leaf.

Figura 1: Topologia Topology

Configuração de atualização multihoming da EVPN

Prepare-se para o upgrade

Procedimento passo a passo
  1. Verifique se o Multihoming EVPN está operacional. Faça login no servidor e confirme que a interface de títulos está ativa. Enquanto estiver lá, observe o endereço MAC da interface bond0. Neste exemplo, o host está executando o Ubuntu para que o ifconfig comando seja usado. Se estiver usando uma distribuição Centos, use oip link show bond0 comando. O endereço MAC para a interface bond0 do host neste exemplo é 00:1B:21:79:5A:EC.

    content_copy zoom_out_map
    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)
    
  2. Confirme que a interface LAG está operacional em ambos os dispositivos leaf com um show interfaces ae1 comando. Neste exemplo, a interface LAG está ae1 em ambos os dispositivos leaf. Esteja ciente de que o número de interface agregado é um índice local que pode variar entre os dois dispositivos leaf. Não é o nome da interface, mas a configuração de ESI e system-id parâmetros compatíveis que logicamente ligam a interface LAG entre as duas folhas. Certifique-se de confirmar que a interface LAG está ativa em ambos os dispositivos leaf.

    A saída confirma que a interface LAG está operando uma configuração do ESI como 00:01:01:01:01:01:01:01:01:01:01 em ambas as folhas.

    content_copy zoom_out_map
    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-Primary
    
    content_copy zoom_out_map
    root@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-Primary
    
  3. Use o valor de ESI observado na etapa anterior para confirmar que o endereço MAC do host está presente no banco de dados EVPN de ambos os switches membros.

    content_copy zoom_out_map
    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.100
    
    content_copy zoom_out_map
    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 07 22:06:11  192.168.100.100
    
  4. Exibir a configuração de interface agregada em ambos os dispositivos leaf. Observe que a opção hold-time up está configurada por 6 segundos, de acordo com as recomendações deste exemplo.

    content_copy zoom_out_map
    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;
            }
        }
    }
    
    content_copy zoom_out_map
    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;
            }
        }
    }
    
  5. Observe o nome da interface de membro LAG em ambos os switches. Você precisará desativar essa interface no switch que está sendo atualizado. É comum que os nomes da interface de membro LAG variem entre um par de switches. Neste exemplo, a interface de membro LAG é xe-0/0/46 em ambos os dispositivos leaf.

    content_copy zoom_out_map
    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
    
    . . .
    
    content_copy zoom_out_map
    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
    
    . . .
    
  6. Transfira a imagem desejada do Junos OS para ambos os dispositivos leaf, conforme mostrado na Figura 2. Certifique-se de colocar a imagem no /var/tmp directory nos switches. Normalmente, FTP ou SCP são usados para copiar a imagem para os dispositivos leaf. Para obter mais informações sobre como usar a CLI para copiar arquivos, consulte a cópia do arquivo.

    Nota:

    Considere executar o request system storage cleanup comando antes de transferir a nova imagem para garantir que haja espaço suficiente para a atualização.

    Figura 2: Transfira a nova imagem Transfer the New Junos Image do Junos
  7. Confirme a versão inicial do Junos OS em ambas as folhas EVPN Multihoming. Neste exemplo, a versão inicial do Junos OS é 19.1R3.9. Para brevidade, apenas a saída da leaf 2 é mostrada.

    content_copy zoom_out_map
    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]
    . . .
    
  8. As etapas realizadas até agora indicam que as interfaces LAG estão operacionais e o plano de controle EVPN está convergido. Antes de iniciar a atualização, inicie um ping do host para o endereço IP de gateway virtual atribuído à interface IRB da VLAN. Esse tráfego terá um link de um membro ou outro. Não importa para qual switch o host envia o tráfego, pois ambos os switches estão configurados com o mesmo IP de gateway virtual.

    É importante notar que qualquer switch é capaz de responder ao ping. Isso significa que quando um switch está reiniciando o outro switch permanece disponível e capaz de responder aos pings.

    Nota:

    Para que os pings tenham sucesso, você deve garantir que a interface IRB esteja configurada com a opção virtual-gateway-accept-data em ambos os switches.

    content_copy zoom_out_map
    [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
    ...
Nota:

Certifique-se de que os pings da interface do host para IRB permaneçam sendo executados durante todo o procedimento de atualização para que você possa determinar o número total de pacotes perdidos.

Atualize a leaf 3

Procedimento passo a passo
  1. Inicie o processo de atualização no Leaf 3 desligando o servidor voltado para o membro LAG xe-0/0/46, conforme mostrado pelo "X" vermelho na Figura 3.

    Nota:

    Um pequeno número de pacotes em trânsito na interface xe-0/0/46 da leaf 3 pode ser perdido durante esta etapa. Neste momento, o tráfego de ping flui pelo dispositivo leaf 2 até que a atualização seja concluída e você reativar a interface de downlink no leaf 3.

    Figura 3: Desabile a interface de downlink no Leaf 3 Disable the Downlink Interface on Leaf 3
    content_copy zoom_out_map
    [edit interface xe-0/0/46] 
    root@leaf3# set disable
    
    content_copy zoom_out_map
    [edit interface xe-0/0/46] 
    root@leaf3# commit and-quit
    
  2. Use uma conexão de console para iniciar a atualização na leaf 3 usando um request system software add /var/tmp/jinstall-host-qfx-5e-x86-64-19.2R1.8-secure-signed.tgz reboot comando. O carregamento de imagens e os processos de reinicialização subsequentes são representados pelos ícones de engrenagem na Figura 4. O processo de atualização leva vários minutos para ser concluído. Durante esse período, seus pings devem estar fluindo pela leaf 2, pois ele permanece totalmente operacional durante a atualização da leaf 3.

    Figura 4: Inicie o upgrade do Leaf 3 Start the Upgrade of Leaf 3

    Após as reinicializações do switch, confirme que a atualização foi bem sucedida.

    content_copy zoom_out_map
    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]
    . . .
    
  3. Neste momento, todas as sessões BGP underlay e overlay devem ser restabelecidas. Confirme que todos os pares BGP estão de volta e que o plano de controle EVPN foi reconvergado antes de habilitar a interface de membro lag no leaf 3.

    content_copy zoom_out_map
    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.100
       
  4. Habilite a interface de downlink no leaf 3, conforme mostrado pela marca de verificação verde na Figura 5.

    content_copy zoom_out_map
    [edit interface xe-0/0/46] 
    root@leaf3# delete disable
    
    content_copy zoom_out_map
    [edit interface xe-0/0/46] 
    root@leaf3# commit and-quit
    

Upgrade leaf2

Procedimento passo a passo
  1. Inicie o procedimento de atualização no leaf 2 desativando sua interface de downlink, conforme mostrado pelo X vermelho na Figura 6. Como os pings provavelmente estão fluindo através da folha 2, esta etapa marca a segunda janela de perda no procedimento. Os pings devem continuar a fluir pelo dispositivo leaf 3 enquanto você atualiza a leaf 2.

    Figura 6: Desativar a Interface de Downlink no leaf2 Disable the Downlink Interface on leaf2
    content_copy zoom_out_map
    [edit interface xe-0/0/46] 
    root@leaf2# set disable
    
    content_copy zoom_out_map
    [edit interface xe-0/0/46] 
    root@leaf2# commit and-quit
    
  2. Inicie a carga da imagem e reinicialize na leaf 2 com um request system software add /var/tmp/jinstall-host-qfx-5e-x86-64-19.2R1.8-secure-signed.tgz comando. A atualização e reinicialização do leaf 2 é como mostrado com os ícones de engrenagem na Figura 7.

    Figura 7: Inicie o upgrade no Leaf 2 Start the Upgrade at Leaf 2

    Após as reinicializações do Leaf 2, verifique a versão do Junos OS para ter certeza de que a atualização foi bem sucedida.

    content_copy zoom_out_map
    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]
    . . .
    
  3. Verifique se o plano de controle da EVPN foi reconvergado na leaf 2. Pode levar alguns minutos para que toda a sessão BGP seja restabelecida e que o endereço MAC do host seja preenchido no banco de dados EVPN.

    content_copy zoom_out_map
    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:30
        
  4. Habilite a interface de membro LAG no leaf 2 conforme mostrado pela marca de verificação verde na Figura 8.

    Figura 8: Habilite a interface de downlink no leaf 2 Enable the Downlink Interface on leaf 2
    content_copy zoom_out_map
    [edit interface xe-0/0/46] 
    root@leaf2# delete disable
    
    content_copy zoom_out_map
    [edit interface xe-0/0/46] 
    root@leaf2# commit and-quit
    
  5. Ambos os switches agora estão atualizados e todas as interfaces de membro LAG estão novamente operacionais. Para medir a interrupção do tráfego durante o processo de atualização, pare o ping e observe as estatísticas de ping. Neste exemplo, um total de dois pacotes são perdidos durante a atualização do par de dispositivos leaf que oferecem suporte ao host multihomed.

    Em muitos casos, a perda de um único pacote é mostrada quando um ping contínuo é interrompido. Independentemente disso, se foram 1 ou 2 pacotes que realmente foram perdidos, a atualização é considerada praticamente sem sucesso. Isso está de acordo com as expectativas do procedimento demonstrado neste exemplo.

    content_copy zoom_out_map
    [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
    

Conclusão

O Multihoming EVPN é um recurso importante para uma arquitetura de data center que deve suportar tanto o alto desempenho quanto a alta disponibilidade. Este exemplo demonstrou a configuração e as etapas necessárias para atualizar um par de switches leaf que oferecem suporte a anexos de host multihomed com o mínimo de interrupção.

external-footer-nav