Can't find what you need?


• Ask the Community
• Create a Case
Reset Search
 

 

Article

Why MLAG ports on VRRP Master and VRRP backup has different Tx/Rx utilization and don’t seem to be load sharing properly?

« Go Back

Information

 
TitleWhy MLAG ports on VRRP Master and VRRP backup has different Tx/Rx utilization and don’t seem to be load sharing properly?
Question
Why MLAG ports on VRRP Master and VRRP backup has different Tx/Rx utilization and don’t seem to be load sharing properly?
Per the below output, MLAG ports on VRRP Master and VRRP backup switches are not load sharing properly from Tx perspective.

  
VRRP Master
slot-1 core1build.3 # show port 1:47 utilization
Link Utilization Averages                            Fri Mar  7 10:11:42 2014
Port     Link    Rx              Peak Rx          Tx               Peak Tx
         State   pkts/sec        pkts/sec         pkts/sec         pkts/sec
================================================================================
1;47_t1b> A         90176         535626           236956          887963
 
Link Utilization Averages                            Fri Mar  7 10:11:55 2014
Port     Link    Rx              Peak Rx          Tx               Peak Tx
         State   pkts/sec        pkts/sec         pkts/sec         pkts/sec
================================================================================
1;47_t1b> A         95615         535626           266171          887963

 
VRRP Backup
Slot-1 core2build.2 # sh port 1:47 utilization    
 
Port     Link    Rx              Peak Rx          Tx               Peak Txc
         State   pkts/sec        pkts/sec         pkts/sec         pkts/sec
================================================================================
1;47_t1b> A        234582         241352           0             109
 
Port     Link    Rx              Peak Rx          Tx               Peak Txc
         State   pkts/sec        pkts/sec         pkts/sec         pkts/sec
================================================================================
1;47_t1b> A        190456         241352           2             109


 
Environment
  • EXOS All
  • Summit All
  • BlackDiamond All
Answer
Based on the explanation provided by Engineering, this is the expected behavior with MLAG/VRRP setup

Per the below topology, switch1 and switch2 are MLAG peers where sw1 is VRRP Master and sw2 is VRRP Backup. All the traffic will be routed through VRRP master. All the Egress traffic will be forwarded via VRRP master switch (i.e. sw1). Now sw1 and sw2 have an entry to reach the destination since both have FDB entries. By Default, If VRRP Switch knows the path to reach the destination, then the packet will be forwarded directly to destination and it won't go via VRRP Backup. If suppose server1 switch MLAG port goes down, then server1 switch will show FDB entry towards sw2 MLAG peer switch and then the packet will be forwarded to destination. That is, FDB entry will switch path from MLAG port to ISC port. 


User-added image

Additional Clarification on Expected Behavior for MLAG
 
Layer-3 Unicast
 
The MLAG feature requires users to configure VRRP or ESRP on the peer switches for L3 unicast forwarding to work correctly. When VRRP is used the server is configured with the default gateway set to the VRRP virtual router IP address. ARP requests emanating from the server can hash to any of the links in its LAG group. Consider the topology shown above, The trivial case is ARP requests from the server being sent out on the link that is directly connected to Switch1 which is the VRRP master in our example. Switch1 will respond back directly to the server over the P1 link. The more interesting case is when the ARP request is sent over the Server to Switch2 link. The ARP request is both L2 flooded over the ISC and is also examined by the CPU on Switch2. Since Switch2 is VRRP standby, it does not respond to the ARP but learns the binding of the Server’s IP address to MAC. When the VRRP master (Switch1) receives the ARP packet, it can:
  • Send the ARP response over P1 if it has an FDB entry present for the server’s MAC (learnt directly or through FDB check-pointing from Switch2) or
  • For a transient period of time (till check-pointing messages are received from Switch2) flood the response back. 
Note that there is no learning on the ISC link hence the ARP request will not result in an FDB entry (pointing to the ISC port) for the server MAC being created.

L3 traffic from this point on can be sent on any of the LAG links from the server with the MAC DA set to the VRRP virtual MAC. Since Switch2 never installs the virtual MAC in hardware, it L2 forwards the traffic to Switch1, which takes care of L3 forwarding.
 



 
Additional notes
L3 forwarding with MLAG may sometimes result in inefficient use of ISC bandwidth. L3 traffic between two servers connected to the same pair of switches on different MLAG links could end up traversing the ISC link in both directions depending on the hashing algorithm used on the servers. 

User-added image

Consider the topology shown above. Server1 is connected to VLAN “Blue” in network 10.1.1.0/24 and Server2 is connected to VLAN “Red” in network 20.1.1.0/24. Both VLANs have Switch1 as the VRRP master. When the two servers send bidirectional L3 traffic, traffic may get sent over the ISC in both directions depending on how hashing works on the servers.

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255