H3C proprietary VRRP load-balancing
VRRP standard was not made to enable any form of load-balancing on single virtual IP (default gateway) like the GLBP standard does. But that didn’t stopped one Chinese vendor to provide it for their network devices. This post will take you through basic configuration of this kind of load-balancing on H3C.
HP owned H3C equipment (created after merging of 3Com with Huawei and later bought by HP) is having a very interesting feature added to the VRRP implementation that is definitelly not part of VRRP standard! But unlocks some load-balancing potencial that is by general knowledge associated only with GLBP protocol.
This is high overview of this functionality:
• The VRRP group’s virtual IP address is mapped to multiple virtual MAC address.
• The master VRRP assigns each router a virtual MAC address.
•When the master receives an ARP request, it uses an algorithm to select a virtual MAC address from the available routers.
• Hosts then use that MAC address for the default gateway.
On the following picture we have a basic VRRP enabled ethernet subnet (Broadcast network). The basic VRRP master election already passed and R1 was elected master with the highest priority of 254.
When VRRP backup routers come up, they send a request packet to the master. The master then assigns each router in the VRRP group a virtual MAC address (using reply packets).
Once each VRRP router learns it’s MAC address from the master, it creates an association between the virtual VRRP IP and its virtual mac-address called “Virtual Forwarder” (VF) and it advertises this bindings to the other VRRP routers along with his priority similarly as masters presence is advertised.
Then when host sends an ARP request (for IPv4) or Neighbor Discovery (for IPv6), the master then assigns each requesting host a mac-address from one of all the available VRRP routers. Backup VRRP routers do not reply to ARP/ND, but they do route traffic as host get their virtual MAC addresses from the master.
NOTE: Also note that because all the VRRP routers use binding of virtual mac-address to the virtual IP, no VRRP router can be owner (priority 255 forced by using physical interface IP the same as virtual IP).
Configuration
Routers are R1 and R2 starting with basic VRRP configuration on vlan 50 interface. HW used is H3C A-Series 5800 Switch (L3).
R1 interface configuration:
interface Vlan-interface50 ip address 5.0.0.3 255.255.255.0 vrrp vrid 69 virtual-ip 5.0.0.1 vrrp vrid 69 priority 254
R2 interface configuration:
interface Vlan-interface50 ip address 5.0.0.2 255.255.255.0 vrrp vrid 69 virtual-ip 5.0.0.1 vrrp vrid 69 priority 1
Verification:
[R1-Vlan-interface50]display vrrp IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface VRID State Run Adver Auth Virtual Pri Timer Type IP --------------------------------------------------------------------- Vlan50 69 Master 254 1 None 5.0.0.1[R2]display vrrp IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface VRID State Run Adver Auth Virtual Pri Timer Type IP --------------------------------------------------------------------- Vlan50 69 Backup 1 1 None 5.0.0.1
Please not the “Run Mode : Standard” that is RFC compatible VRRP mode. The only thing to add on this point to create the proprietary mode is this:
[R1]vrrp mode ? load-balance Set VRRP to support load-balance[R1]vrrp mode load-balance
NOTE: Look at this! If we move only one of the router VRRP mode to load-balance, it looses contact with the other peer and we have a collision even between two H3C devices running VRRPs in different mode.
[R1]display vrrp IPv4 Standby Information: Run Mode : Load Balance Run Method : Virtual MAC Total number of virtual routers : 1 Interface VRID State Run Address Active Pri ---------------------------------------------------------------------- Vlan50 69 Master 254 5.0.0.1 Local ----- VF 1 Active 255 000f-e2ff-0451 Local[R2]display vrrp IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface VRID State Run Adver Auth Virtual Pri Timer Type IP --------------------------------------------------------------------- Vlan50 69 Master 1 1 None 5.0.0.1
There is no communication and therefore conflict!
Now in order to fix this, we add the R2 to load-balanced status as well.
[R2]vrrp mode load-balance [R2]display vrrp IPv4 Standby Information: Run Mode : Load Balance Run Method : Virtual MAC Total number of virtual routers : 1 Interface VRID State Run Address Active Pri ---------------------------------------------------------------------- Vlan50 69 Backup 1 5.0.0.1 5.0.0.3 ----- VF 1 Listening 127 000f-e2ff-0451 5.0.0.3 ----- VF 2 Active 255 000f-e2ff-0452 Local[R1]display vrrp IPv4 Standby Information: Run Mode : Load Balance Run Method : Virtual MAC Total number of virtual routers : 1 Interface VRID State Run Address Active Pri ---------------------------------------------------------------------- Vlan50 69 Master 254 5.0.0.1 Local ----- VF 1 Active 255 000f-e2ff-0451 Local ----- VF 2 Listening 127 000f-e2ff-0452 5.0.0.2
You can see that both routers now have their VF with virtual mac address and are even doing backup for each other virtual mac-address in case one of them fails.
Hope you find this informative,