Knowledge Search


×
 

[EX/QFX] Avoiding traffic drops while replacing member switches of VC formed with QFX5100-24Q or EX4600

  [KB34384] Show Article Properties


Summary:

When replacing a member of the virtual chassis that is formed with either a QFX5100-24Q device or an EX4600 device with two expansion modules installed on the device, there is a possibility that traffic might get dropped after replacing the member in certain situations (see PR1402623).

This article describes how to replace the member by using the procedure described in Removing or Replacing a Member Switch of a Virtual Chassis Configuration without encountering traffic loss.

 

Symptoms:

Issue Scenario

  • Assume that Member0 is the device that needs to be replaced.

  • The virtual chassis configuration is as follows:

set virtual-chassis no-split-detection
set virtual-chassis member 0 mastership-priority 255
set virtual-chassis member 1 mastership-priority 255
  • Need to power off Member0 and replace it with the new Member0 that has a factory default configuration.

  • The VC priority of the factory default configuration is 128 so Member0 will be added in a backup role to the VC.

  • The Packet Forwarding Engine (PFE) on Member0 goes for a planned restart.

 
Given the above scenario:
  1. When two expansion modules are NOT installed​ on Member0, the VC will be stable and Member0 is added to the VC in a backup role.

  2. However, if two expansion modules are installed on Member0, the PFE takes over 120 seconds to come up. The VC sync timer is set to 120 seconds. When this timer expires, Member0 takes mastership and the VC become a Dual master.

After the PFE on Member0 comes up, master election will run since both nodes are master. For details on the master election algorithm, see Understanding How the Master in a Virtual Chassis Is Elected.

In this case, we want Member1 to keep mastership but if the MAC address of Member0 is lower than Member1, Member0 will take mastership.

At this time, traffic will get dropped because the PFE is in between a convergence and Member0 is not yet ready to forward any traffic yet.

 

Cause:

Traffic impact might occur if all of the following conditions are met:

  • The priority of Member0 and Member1 is the same.

  • The virtual chassis (VC) is created with either QFX5100-24Q or EX4600.

  • Two expansion modules have been installed on the QFX5100-24Q VC or EX4600 VC.

Example:

EX4600-EM-8F is one of the expansion modules that can be used for QFX5100 and EX4600.

{master:0}
root@switch> show chassis fpc pic-status
Slot 0   Online       QFX5100-24Q-2P
  PIC 0  Online       24x 40G-QSFP
  PIC 1  Online       EX4600-EM-8F
  PIC 2  Online       EX4600-EM-8F
Slot 1   Online       QFX5100-24Q-2P
  PIC 0  Online       24x 40G-QSFP
  PIC 1  Online       EX4600-EM-8F
  PIC 2  Online       EX4600-EM-8F

 

Solution:

To avoid traffic impact after replacing a member, the existing member must keep the master role.

Use the following procedure to ensure that there is no switchover after a member is replaced. Refer to Removing or Replacing a Member Switch of a Virtual Chassis Configuration for all steps in detail, except step 4 and step 7. Steps 4 and 7 are specifically to deal with this issue.

  1. Power off and disconnect the member switch that is to be replaced.
  2. If the member switch to be replaced has been previously configured, revert that switch’s configuration to factory defaults. Use the request system zeroize command. The replacement member switch should be powered on and running with the factory default configuration at the end of this step.

  3. Ensure that the correct version of Junos OS is installed on the new member switch.

  4. Change the role or priority. Change the role to line-card or decrease the mastership priority of the member that you are adding to the virtual chassis on the master node. For example, if Member0 is the device to be replaced:
    Pre-provisioned configuration
     
    1. ​​Save the current configuration before making any changes.
      root#show virtual-chassis | display set
      set virtual-chassis preprovisioned
      set virtual-chassis no-split-detection
      set virtual-chassis member 0 role routing-engine
      set virtual-chassis member 0 serial-number xxxxxxxxxxxx
      set virtual-chassis member 1 role routing-engine
      set virtual-chassis member 1 serial-number yyyyyyyyyyyy
    2. Ensure that Member0 does not take mastership after replacing the module. There are two ways to do this. Use either i) or ii).
      1. Change the role of Member0 from routing-engine to line-card.
        set virtual-chassis member 0 role line-card
        set virtual-chassis member 1 role routing-engine
      2. Delete the current virtual chassis configuration and reduce the priority of the member that is being replaced.
        delete virtual-chassis preprovisioned
        delete virtual-chassis member 0
        delete virtual-chassis member 1
        
        set virtual-chassis member 0 mastership-priority 128
        set virtual-chassis member 1 mastership-priority 255
    3. Commit the configuration.


    Non-provisioned configuration
    1. ​​Save the current configuration before making any changes.
      root#show virtual-chassis | display set
      set virtual-chassis no-split-detection
      set virtual-chassis member 0 mastership-priority 255
      set virtual-chassis member 1 mastership-priority 255
    2. Reduce the priority of the member that is being replaced.
      set virtual-chassis member 0 mastership-priority 128
      set virtual-chassis member 1 mastership-priority 255
    3. Commit the configuration.
  5. Connect the VCP link from the replacement member switch to the virtual chassis.

  6. Confirm that the new member switch is now included in the virtual chassis.

  7. Roll back the configuration.
    Pre-provisioned configuration
    1. If you have changed member role before replacing the device in Step 4-B-i, use Step i) below. If you have changed the virtual-chassis configuration from pre-provisioned to priority base in Step 4-B-ii, use Step ii) as below.
      1. Change the role of Member0 from line-card to routing-engine. The new role will be applied in one or two minutes after configuration commit.

        set virtual-chassis member 0 role routing-engine
        set virtual-chassis member 1 role routing-engine
      2. Delete the current virtual-chassis configuration and roll back to the configuration that was used before replacing the device.

        delete virtual-chassis member 0
        delete virtual-chassis member 1
        
        set virtual-chassis preprovisioned
        set virtual-chassis no-split-detection
        set virtual-chassis member 0 role routing-engine
        set virtual-chassis member 0 serial-number xxxxxxxxxxxx
        set virtual-chassis member 1 role routing-engine
        set virtual-chassis member 1 serial-number yyyyyyyyyyyy
    2. Commit the configuration.



    Non-provisioned configuration
    1. ​​Change priority to the value that was used before replacing the device.

      root#show virtual-chassis | display set
      set virtual-chassis no-split-detection
      set virtual-chassis member 0 mastership-priority 255
      set virtual-chassis member 1 mastership-priority 255
    2. Commit the configuration.

 

Modification History:

2019-07-08: Step 4 and Step 7 modified to include additional instructions under Pre-provisioned and Non-provisioned sections in Solution

 

Related Links: