Upgrade von Junos OS in einem EVPN-Multihoming-Setup
Informationen zu diesem Beispiel für eine Netzwerkkonfiguration
Verwenden Sie dieses Beispiel für eine Netzwerkkonfiguration, um das Junos OS auf einem Paar von Junos OS- oder Junos Evolved-Geräten, die für EVPN Muiltihoming (auch ESI-LAG genannt) konfiguriert sind, manuell auf einen angeschlossenen Server (Host) zu aktualisieren.
Dieses Beispiel basiert auf einer bereits vorhandenen ERB-EVPN-Konfiguration (Edge-Routing-Bridging) mit QFX-Switches. Die hier gezeigten Schritte gelten auch für CRB- (Centrally-Roudging) und Bridged-Overlay-EVPN-Architekturen.
Ausführliche Informationen zu unterstützten Plattformen und zur Versionsunterstützung von Junos oder Junos Evolved für EVPN ESI-LAG finden Sie im Funktions-Explorer.
Beispiel: Upgrade von Junos OS in einem EVPN-Multihoming-Anwendungsfall
Anforderungen
Gehen Sie wie folgt vor, um ein Paar Leaf-Switches der QFX-Serie zu aktualisieren, die für die Unterstützung von EVPN Multihomed-Hostanlagen konfiguriert sind.
Bevor Sie beginnen:
Stellen Sie sicher, dass der Konsolenzugriff für beide Leaf-Geräte verfügbar ist.
Stellen Sie sicher, dass die MAC-Adresse des Hosts in der EVPN-Datenbank beider Leaf-Geräte vorhanden ist.
Es wird empfohlen, einen
hold-time upTimer-Wert von 60 Sekunden (60000 Millisekunden) für die LAG-Schnittstellen an beiden Leaf-Switches zu konfigurieren. Weitere Informationen zu dieser Option finden Sie unter Haltezeit . Durch die Konfiguration eines Hold-up-Timers wird sichergestellt, dass die dem Host zugewandte LAG-Mitgliedsschnittstelle erst betriebsbereit ist, wenn der Switch seinen BGP-Routenaustausch nach einem Neustartereignis abgeschlossen hat.In diesem Beispiel werden Pings vom mehrfach vernetzten Host an die virtuelle Gateway-Adresse generiert, die auf der IRB-Schnittstelle des VLANs konfiguriert ist. Sie müssen die
virtual-gateway-accept-dataOption zu den IRB-Schnittstellen beider Switches hinzufügen, damit sie Ping-Antworten generieren können.
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
Zwei QFX5100-48S-6Q-Geräte, auf denen zunächst Junos OS Version 19.1R3.9 ausgeführt wird
Junos OS Version 19.2R1.8
Ein Ubuntu- oder Centos-Server mit einer Verbindung zu beiden ToR-Switches. Der Server ist mit einer Mode-4-Bond-Schnittstelle zur Unterstützung von LACP-basierter Link-Aggregation konfiguriert.
Übersicht über das Verfahren
In diesem Abschnitt erhalten Sie eine Übersicht über das Upgrade-Verfahren. Die Abfolge der Schritte dient dazu, Unterbrechungen beim Upgrade eines Leaf-Switch-Paares, das mehrfach vernetzte Hosts unterstützt, zu minimieren:
Bereiten Sie sich auf das Upgrade vor:
Vergewissern Sie sich, dass die LAG-Schnittstellen auf beiden Switches betriebsbereit sind und die EVPN-Steuerungsebene konvergiert ist.
Kopieren Sie das gewünschte Junos OS-Image in das Verzeichnis /var/tmp auf beiden Switches.
Starten Sie einen Ping vom mehrfach vernetzten Host zu einem Overlay-Ziel im selben VLAN. Zum Beispiel eine IRB-Schnittstelle auf den Spine-Geräten für CRB oder auf den Leaf-Geräten für ERB. Dieser Schritt wird ausgeführt, damit Sie später den Grad des Paketverlusts im Zusammenhang mit dem Upgradevorgang ermitteln können.
Wählen Sie den zu aktualisierenden Switch aus und deaktivieren Sie die Downlink-Schnittstelle zum Server oder Host.
Führen Sie ein Upgrade durch, und starten Sie den Switch auf die neue Junos-Version neu. Vergewissern Sie sich, dass auf dem Switch die neue Version ausgeführt wird.
Überprüfen Sie die EVPN-Steuerungsebene, um sicherzustellen, dass der aktualisierte Switch die MAC-Adresse des Downlink-Hosts neu gelernt hat.
Aktivieren Sie die Downlink-Schnittstelle des aktualisierten Switches.
Wiederholen Sie die Schritte 3 bis 6 auf dem anderen Switch, um das Upgrade abzuschließen.
Stoppen Sie die vom Host generierten Pings und bestätigen Sie die Anzahl der Pakete, die während des Upgrade-Vorgangs verloren gegangen sind.
Hinweis:Der Upgrade-Vorgang ist nicht ohne Treffer. Pakete, die auf dem Downlink übertragen werden, können verloren gehen, wenn die Schnittstelle in Vorbereitung auf das Upgrade deaktiviert wird. Sobald die Schnittstelle deaktiviert ist, wechselt der Datenverkehr zum anderen Leaf-Switch und fließt weiter. Bei diesem Verfahren gibt es zwei kleine Verlustfenster, wenn Sie die LAG-Member-Schnittstelle auf jedem Switch deaktivieren, der aktualisiert wird. Diese Verlustfenster sollten 50 Millisekunden nicht überschreiten.
Topologie
Abbildung 1 veranschaulicht die Topologie für dieses EVPN Multihoming-Upgrade-Beispiel. Beachten Sie, dass für beide Switches eine IRB-Schnittstelle für das VLAN konfiguriert ist, das dem angeschlossenen Host zugeordnet ist. Diese IRBs sind mit der freigegebenen virtuellen Gateway-Adresse 192.168.0.1 konfiguriert. Dem Host wird die Adresse 192.1689.1.100 auf seiner bond0-Schnittstelle zugewiesen. Das Diagramm enthält außerdem die MAC-Adresse der bond0-Schnittstelle auf dem Host und den Ethernet Segment Identifier (ESI), der auf der LAG-Schnittstelle beider Leaf-Switches konfiguriert ist.
EVPN-Multihoming-Upgrade-Konfiguration
Vorbereiten des Upgrades
Schritt-für-Schritt-Anleitung
Stellen Sie sicher, dass EVPN Multihoming betriebsbereit ist. Melden Sie sich beim Server an und vergewissern Sie sich, dass die Bond-Schnittstelle aktiv ist. Notieren Sie sich dort die MAC-Adresse der bond0-Schnittstelle. In diesem Beispiel wird auf dem Host Ubuntu ausgeführt, daher wird der
ifconfigBefehl verwendet. Wenn Sie eine Centos-Verteilung verwenden, verwenden Sie denip link show bond0Befehl. Die MAC-Adresse für die bond0-Schnittstelle des Hosts lautet in diesem Beispiel 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)Vergewissern Sie sich mit einem
show interfaces ae1Befehl, dass die LAG-Schnittstelle auf beiden Leaf-Geräten betriebsbereit ist. In diesem Beispiel befindet sich ae1 die LAG-Schnittstelle auf beiden Leaf-Geräten. Beachten Sie, dass es sich bei der aggregierten Schnittstellennummer um einen lokalen Index handelt, der zwischen den beiden Leaf-Geräten variieren kann. Es ist nicht der Schnittstellenname, sondern die Konfiguration der übereinstimmenden ESI undsystem-idParameter, die die LAG-Schnittstelle logisch zwischen den beiden Leaves bindet. Stellen Sie sicher, dass die LAG-Schnittstelle auf beiden Leaf-Geräten aktiv ist.Die Ausgabe bestätigt, dass die LAG-Schnittstelle in Betrieb ist und dass die ESI auf beiden Leaves als 00:01:01:01:01:01: 01:01:01 konfiguriert ist.
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-PrimaryVerwenden Sie den im vorherigen Schritt angegebenen ESI-Wert, um zu bestätigen, dass die MAC-Adresse des Hosts in der EVPN-Datenbank beider Mitglieds-Switches vorhanden ist.
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.100Zeigen Sie die aggregierte Schnittstellenkonfiguration auf beiden Leaf-Geräten an. Beachten Sie, dass die
hold-time upOption für 6 Sekunden konfiguriert ist, in Übereinstimmung mit den Empfehlungen in diesem Beispiel.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; } } }Notieren Sie sich den Namen der LAG-Member-Schnittstelle auf beiden Switches. Sie müssen diese Schnittstelle auf dem Switch, der aktualisiert wird, herunterfahren. Es ist üblich, dass die Namen der LAG-Mitgliedsschnittstellen zwischen einem Switch-Paar variieren. In diesem Beispiel ist die LAG-Member-Schnittstelle xe-0/0/46 auf beiden Leaf-Geräten.
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 . . .Übertragen Sie das gewünschte Junos OS-Image auf beide Leaf-Geräte, wie in Abbildung 2 dargestellt. Stellen Sie sicher, dass Sie das Image im Verzeichnis /var/tmp auf den Switches ablegen. In der Regel wird entweder FTP oder SCP verwendet, um das Image auf die Leaf-Geräte zu kopieren. Weitere Informationen zur Verwendung der CLI zum Kopieren von Dateien finden Sie unter Kopieren von Dateien.
Hinweis:Erwägen Sie, den
request system storage cleanupBefehl vor dem Übertragen des neuen Images auszuführen, um sicherzustellen, dass genügend Speicherplatz für das Upgrade vorhanden ist.Abbildung 2: Übertragen des neuen Junos-Images
Bestätigen Sie die Startversion von Junos OS auf beiden EVPN Multihoming-Leaves. In diesem Beispiel ist die Startversion von Junos OS 19.1R3.9. Der Kürze halber wird nur die Ausgabe von Blatt 2 angezeigt.
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] . . .Die bisher durchgeführten Schritte deuten darauf hin, dass die LAG-Schnittstellen betriebsbereit sind und die EVPN-Steuerungsebene konvergiert ist. Bevor Sie mit dem Upgrade beginnen, starten Sie einen Ping vom Host an die IP-Adresse des virtuellen Gateways, die der IRB-Schnittstelle des VLANs zugewiesen ist. Dieser Datenverkehr wird an den einen oder anderen Mitgliederlink weitergeleitet. Es spielt keine Rolle, an welchen Switch der Host den Datenverkehr sendet, da beide Switches mit derselben IP-Adresse des virtuellen Gateways konfiguriert sind.
Es ist wichtig zu beachten, dass beide Switches in der Lage sind, auf den Ping zu antworten. Das bedeutet, dass beim Neustart eines Switches der andere Switch verfügbar bleibt und auf die Pings reagieren kann.
Hinweis:Damit die Pings erfolgreich ausgeführt werden können, müssen Sie sicherstellen, dass die IRB-Schnittstelle mit der
virtual-gateway-accept-dataOption auf beiden Switches konfiguriert ist.[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 ...
Stellen Sie sicher, dass die Pings der Host-zu-IRB-Schnittstelle während des gesamten Upgrade-Vorgangs ausgeführt werden, damit Sie die Gesamtzahl der verlorenen Pakete ermitteln können.
Upgrade von Leaf 3
Schritt-für-Schritt-Anleitung
Beginnen Sie den Upgrade-Vorgang auf Leaf 3, indem Sie das dem Server zugewandte LAG-Member xe-0/0/46 herunterfahren, wie durch das rote "X" in Abbildung 3 dargestellt.
Hinweis:Eine kleine Anzahl von Paketen, die sich während der Übertragung auf der xe-0/0/46-Schnittstelle von Leaf 3 befinden, kann während dieses Schritts verloren gehen. Zu diesem Zeitpunkt fließt der Ping-Datenverkehr über das Gerät von Leaf 2, bis das Upgrade abgeschlossen ist und Sie die Downlink-Schnittstelle auf Leaf 3 wieder aktivieren.
Abbildung 3: Deaktivieren der Downlink-Schnittstelle auf Leaf 3
[edit interface xe-0/0/46] root@leaf3# set disable
[edit interface xe-0/0/46] root@leaf3# commit and-quit
Verwenden Sie eine Konsolenverbindung, um das Upgrade auf Leaf 3 mit einem
request system software add /var/tmp/jinstall-host-qfx-5e-x86-64-19.2R1.8-secure-signed.tgz rebootBefehl zu starten. Das Laden des Images und die nachfolgenden Neustartprozesse werden durch die Zahnradsymbole in Abbildung 4 dargestellt. Der Upgrade-Vorgang dauert einige Minuten. Während dieser Zeit sollten Ihre Pings durch Leaf 2 fließen, da es während des Upgrades von Leaf 3 voll funktionsfähig bleibt.Abbildung 4: Starten des Upgrades von Leaf 3
Vergewissern Sie sich nach dem Neustart des Switches, dass das Upgrade erfolgreich war.
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] . . .Zu diesem Zeitpunkt sollten alle Underlay- und Overlay-BGP-Sitzungen wiederhergestellt werden. Vergewissern Sie sich, dass alle BGP-Peers wieder verfügbar sind und dass die EVPN-Steuerungsebene erneut konvergiert ist, bevor Sie die Lag-Member-Schnittstelle auf Leaf 3 aktivieren.
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.100Aktivieren Sie die Downlink-Schnittstelle auf Blatt 3, wie durch das grüne Häkchen in Abbildung 5 dargestellt.
Abbildung 5: Aktivieren der Downlink-Schnittstelle auf Leaf 3
[edit interface xe-0/0/46] root@leaf3# delete disable
[edit interface xe-0/0/46] root@leaf3# commit and-quit
Upgrade-Blatt2
Schritt-für-Schritt-Anleitung
Beginnen Sie den Upgrade-Vorgang auf Leaf 2, indem Sie die Downlink-Schnittstelle deaktivieren, wie durch das rote X in Abbildung 6 dargestellt. Da die Pings wahrscheinlich durch Leaf 2 fließen, markiert dieser Schritt das zweite Verlustfenster in der Prozedur. Die Pings sollten weiterhin durch das Leaf 3-Gerät fließen, wenn Sie Leaf 2 aktualisieren.
Abbildung 6: Deaktivieren der Downlink-Schnittstelle auf leaf2
[edit interface xe-0/0/46] root@leaf2# set disable
[edit interface xe-0/0/46] root@leaf2# commit and-quit
Starten Sie das Laden des Images und starten Sie auf Blatt 2 mit einem
request system software add /var/tmp/jinstall-host-qfx-5e-x86-64-19.2R1.8-secure-signed.tgzBefehl neu. Das Upgrade und der Neustart von Blatt 2 sind wie mit den Zahnradsymbolen in Abbildung 7 dargestellt.Abbildung 7: Starten des Upgrades auf Leaf 2
Überprüfen Sie nach dem Neustart von Leaf 2 die Junos OS-Version, um sicherzustellen, dass das Upgrade erfolgreich war.
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] . . .Vergewissern Sie sich, dass die EVPN-Steuerungsebene bei Leaf 2 wieder konvergiert ist. Es kann einige Minuten dauern, bis alle BGP-Sitzungen wiederhergestellt sind und die MAC-Adresse des Hosts in der EVPN-Datenbank eingetragen ist.
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:30Aktivieren Sie die LAG-Elementschnittstelle auf Blatt 2, wie durch das grüne Häkchen in Abbildung 8 dargestellt.
Abbildung 8: Aktivieren der Downlink-Schnittstelle auf Blatt 2
[edit interface xe-0/0/46] root@leaf2# delete disable
[edit interface xe-0/0/46] root@leaf2# commit and-quit
Beide Switches sind jetzt aufgerüstet und alle LAG-Mitgliedsschnittstellen sind wieder betriebsbereit. Um die Unterbrechung des Datenverkehrs während des Upgrade-Vorgangs zu messen, stoppen Sie den Ping und notieren Sie sich die Ping-Statistiken. In diesem Beispiel gehen während des Upgrades des Leaf-Gerätepaars, das den mehrfach vernetzten Host unterstützt, insgesamt zwei Pakete verloren.
In vielen Fällen wird der Verlust eines einzelnen Pakets angezeigt, wenn ein laufender Ping unterbrochen wird. Unabhängig davon, ob es sich um 1 oder 2 Pakete handelt, die tatsächlich verloren gegangen sind, gilt das Upgrade als praktisch ohne Treffer. Dies entspricht den Erwartungen an das in diesem Beispiel demonstrierte Verfahren.
[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
Schlussfolgerung
EVPN Multihoming ist eine wichtige Funktion für eine Datencenterarchitektur, die sowohl hohe Leistung als auch hohe Verfügbarkeit unterstützen muss. In diesem Beispiel wurden die Konfiguration und die Schritte veranschaulicht, die erforderlich sind, um ein Paar Leaf-Switches zu aktualisieren, die mehrfach vernetzte Hostanlagen mit minimaler Unterbrechung unterstützen.