Upgrade Junos OS in an EVPN Multihoming Setup

Verify that EVPN Multihoming is operational. Log into the server and confirm the bond interface is up. While there, make a note of the bond0 interface's MAC address. In this example the host is running Ubuntu so the ifconfig command is used. If using a Centos distribution use theip link show bond0 command. The MAC address for the host’s bond0 interface in this example is 00:1B:21:79:5A:EC.

Confirm the LAG interface is operational on both leaf devices with a show interfaces ae1 command. In this example the LAG interface is ae1 on both the leaf devices. Be aware that the aggregated interface number is a local index that can vary between the two leaf devices. It’s not the interface name, but the configuration of matched ESI and system-id parameters that logically binds the LAG interface between the two leaves. Be sure to confirm that the LAG interface is up on both leaf devices.

The output confirms that the LAG interface is operation an that the ESI is configured as 00:01:01:01:01:01:01:01:01:01 on both leaves.

Use the ESI value noted in the previous step to confirm the host MAC address is present in the EVPN database of both member switches.

Display the aggregated interface configuration on both leaf devices. Note that the hold-time up option is configured for 6 seconds, in keeping with the recommendations in this example.

Take note of the LAG member interface name on both switches. You will need to shut down this interface on the switch that is being upgraded. Its common for LAG member interface names to vary between a pair of switches. In this example the LAG member interface is xe-0/0/46 on both leaf devices.

Transfer the desired Junos OS image to both leaf devices as shown in Figure 2. Be sure to place the image in the /var/tmp directory on the switches. Typically, either FTP or SCP is used to copy the image to the leaf devices. For details on using the CLI to copy files, see file copy.

Figure 2: Transfer the New Junos Image

Confirm the starting Junos OS version on both the EVPN Multihoming leaves. In this example the starting Junos OS version is 19.1R3.9. For brevity only the output from leaf 2 is shown.

The steps performed thus far indicate the LAG interfaces are operational and the EVPN control plane is converged. Before beginning the upgrade, start a ping from the host to the virtual gateway IP address assigned to the VLAN’s IRB interface. This traffic will hash to one member link or the other. It does not matter which switch the host sends the traffic to because both switches are configured with the same virtual gateway IP.

It’s important to note that either switch is able to reply to the ping. This means that when one switch is rebooting the other switch remains available and able to respond to the pings.

Begin the upgrade process on Leaf 3 by shutting down the server facing LAG member xe-0/0/46, as shown in by the red “X” in Figure 3.

Figure 3: Disable the Downlink Interface on Leaf 3

Use a console connection to start the upgrade at leaf 3 using a request system software add /var/tmp/jinstall-host-qfx-5e-x86-64-19.2R1.8-secure-signed.tgz reboot command. The image loading and subsequent reboot processes are represented by the gear icons in Figure 4. The upgrade process takes several minutes to complete. During this time your pings should be flowing through leaf 2, because it remains fully operational during the upgrade of leaf 3.

Figure 4: Start the Upgrade of Leaf 3

After the switch reboots confirm that the upgrade was successful.

At this time all underlay and overlay BGP sessions should be reestablished. Confirm that all BGP peers are back up and that the EVPN control plane has reconverged before enabling the lag member interface at leaf 3.

Enable the downlink interface on leaf 3, as shown by the green check mark in Figure 5.

Figure 5: Enable the Downlink Interface at Leaf 3

Begin the upgrade procedure on leaf 2 by disabling its downlink interface, as shown by the red X in Figure 6. Because the pings are likely flowing through leaf 2, this steps marks the second loss window in the procedure. The pings should continue to flow through the leaf 3 device as you upgrade leaf 2.

Figure 6: Disable the Downlink Interface on leaf2

Start the image load and reboot at leaf 2 with a request system software add /var/tmp/jinstall-host-qfx-5e-x86-64-19.2R1.8-secure-signed.tgz command. The upgrade and reboot of leaf 2 is as shown with the gear icons in Figure 7.

Figure 7: Start the Upgrade at Leaf 2

After leaf 2 reboots, check the Junos OS version to make sure that the upgrade was successful.

Check that the EVPN control plane has reconverged at leaf 2. It may take a few minutes for all BGP session to reestablish and for the MAC address of the host to be populated in the EVPN database.

Enable the LAG member interface on leaf 2 as shown by the green check mark in Figure 8.

Figure 8: Enable the Downlink Interface on leaf 2

Both switches are now upgraded and all LAG member interfaces are again operational. To measure the traffic disruption during the upgrade process, stop the ping and note the ping statistics. In this example a total of two packets are lost during the upgrade of the pair of leaf devices that support the multihomed host.

In many cases the loss of a single packet is shown when an ongoing ping is disrupted. Regardless, whether it was 1 or 2 packets that are actually lost, the upgrade is deemed virtually hitless. This is in accordance with the expectations of the procedure demonstrated in this example.