[Dr.WoW] [No.49] The Story of VRRP and VGMP-part 2

Latest reply: Jan 8, 2016 09:37:41 8530 1 1 0

4 The Creation of VGMP Solves VRRPs' Problems

In order to resolve this problem of a lack of state unity in multiple VRRP groups, Huawei's firewalls incorporate VGMP (VRRP group Management Protocol) in exercising unified management over VRRP groups to guarantee the state consistency in VRRP groups. We add all VRRP groups on a firewall into a VGMP group, and the VGMP group centrally supervises and manages the states of all VRRP groups. If the VGMP group discovers that one of its VRRP groups' state has changed, the VGMP group will mandate that all of the VRRP groups in the VGMP group undergo unified state switching, guaranteeing the state consistency in all VRRP groups.

A VGMP group has two basic attributes (state and priority) and three basic operating principles:

l   A VGMP group's state determines the state of the VRRP groups within the group, and also determines its firewall's active/standby state.

l   The VGMP group states of two firewalls are determined by mutual priority comparison. The state of the VGMP group with the higher priority is active, while the state of the VGMP group(s) with the lower priority is standby.

l   A VGMP group will update its own priority according to state changes by the VRRP groups within it. When a VRRP group's state changes to Initialize, the VGMP group's priority will decrease by 2.

Now that we understand and are intimately familiar with the basic principles of VGMP group operation, we'll together take a look at how the VGMP protocol resolves the problem of VRRP group state discordance.

As shown in Figure 1-1, on FW1 we've added both VRRP group 1 and VRRP group 2 to a VGMP group in the active state. On FW2 we've added VRRP group 1 and VRRP group 2 to a VGMP group in the standby state. As a VGMP group's state determines the states of the group's VRRP groups, the states of VRRP groups 1 and 2 on FW1 are both active, and the states of VRRP groups 1 and 2 on FW2 are both standby. Therefore, FW1 is the active router in VRRP group 1 and VRRP group 2 (it is the primary device of the two firewalls), while FW2 is the standby router for them (it is the backup device of the two firewalls), and therefore upstream and downstream service traffic will all be directed to the primary device FW1 for forwarding.

Figure 1-1 VGMP ensuring unified VRRP state switching

[Dr.WoW] [No.49] The Story of VRRP and VGMP-part 2-1039635-1 

NOTE

A heartbeat cable is needed between two firewalls to exchange VGMP protocol packets.

[Question from Dr. WoW] Above, while explaining VRRPs, the states we studied were all "Master" and "standby"why have these changed to "active" and "standby" here?

Answer: In the USG6000 series of firewalls, hot standby states (originally "Master" and "Slave") and VRRP states (originally "Master" and "standby") have been uniformly changed to read "active" and "standby". Therefore, when you see other documents use multiple different terms to describe states, please don't think this unusual; understanding these states as the "active" and "standby" described here will work just fine.

As shown in Figure 1-1, when one of FW1's interfaces fails, the process by which the VGMP group controls unified state switching of the VRRP groups is as follows:

1.         When FW1's GE1/0/1 interface fails, VRRP group 1 on FW1 switches states (switches from active to initialize).

2.         After FW1's VGMP group perceives this failure, it will lower its own priority, and then compare priorities with FW2's VGMP group and renegotiate their active/standby states.

3.         After negotiation, the state of the VGMP group on FW1 switches from active to standby, and the state of the VGMP group on FW2 switches from standby to active.

4.         At the same time, as a VGMP group's state determines the state of the group's VRRP groups, FW1's VGMP group will mandate that its VRRP group 2 switch from the active state to the standby state, and FW2's VGMP group will also mandate that its VRRP groups 1 and 2 switch from the standby state to the active state.

In this way, FW2 becomes the active router in VRRP group 1 and VRRP group 2, and also is thus the primary device of the two firewalls; meanwhile, FW1 becomes the standby router in VRRP group 1 and VRRP group 2, and is thus also the backup device of the two firewalls.

5.         FW2 will send gratuitous ARP packets to both LSW1 and LSW2 to update their MAC address tables, causing PC1's upstream packets and return packets accessing PC2 to be forwarded to FW2. This completes the unified switching of VRRP group states, and guarantees uninterrupted service traffic.

5 VGMP Packet Structure

After reading through the above content, everyone should understand that VGMP not only allows for unified management of VRRP groups, but also replaces VRRP in managing firewall active/standby states as needed. At this point a question arises: how is information about states and priorities sent between two firewalls' VGMP groups?

In 2 VRRP Working Mechanisms above, we explained that two routers' VRRP groups use VRRP packets to send state and priority information. So, do two firewalls' VGMP groups still use VRRP packets to send state and priority information? This is of course not very likely, as new leadership naturally brings with it new methods.

During hot standby, two firewalls' VGMP groups use VGMP packets to send state and priority information. VGMP is Huawei's proprietary protocol, and this protocol expands on and alters VRRP packets to achieve the firewall hot standby function, deriving multiple kinds of packets that use VGMP headers in their encapsulation. An understanding of VGMP packets and headers is the foundation necessary to understand VGMP state negotiation and switching, so let's first have a look at the structure of VGMP packets.

NOTE

The VGMP packet structure discussed in this section applies to the USG2000/5000/6000 firewall series and the USG9500 firewall series' V100R003 version.

Figure 1-2 VGMP packet structure

[Dr.WoW] [No.49] The Story of VRRP and VGMP-part 2-1039635-2 

From the sequence of VGMP packet encapsulation shown in Figure 1-2, we can see that VGMP packets are rooted in VRRP packets, and are encapsulated from VRRP header. However, the VRRP header is not standard VRRP header, but is "new VRRP header" that has been expanded on and amended by Huawei. The specific changes are listed below:

l   Standard VRRP header' "Type" field only has a value of "1", while the new VRRP header has added a value of "2". This is to say that if Type=1, this is a standard VRRP header; if Type=2, this is a new kind of VRRP header that has been altered by us.

l   Standard VRRP header' "Virtual Rtr ID" field represents the VRRP group ID, while the new, altered VRRP header' "Virtual Rtr ID" value is always set to "0".

l   The standard VRRP header's "IP address" field has been eliminated from the new, altered VRRP header.

l   The "Priority" field in the standard VRRP header has been changed to a "Type2" field in the new VRRP header.

?       When Type2=1, packets are encapsulated as heartbeat link detection packets. Heartbeat link detection packets are used to detect whether or not the peer device's heartbeat interface can receive packets from the sending device; this verifies whether or not the heartbeat interface can be used.

?       When Type2=5, the packets are encapsulated as consistency check packets. Consistency check packets are used to inspect whether two firewalls in hot standby state have the same hot standby and policy configuration.

?       Only when Type2=2 will VRRP packets be further encapsulated into a VGMP header. These packets are further separated into three kinds of packets according to the VGMP header's "vType" field.

ü  VGMP packets (VGMP Hello packets). VGMP Hello packets are used to negotiate active/standby states between two firewalls' VGMP groups.

ü  HRP heartbeat packets (HRP Hello packets). HRP heartbeat packets are used to detect whether a peer VGMP group is in a working state. A VGMP group in the active state will send HRP heartbeat packets to its peer VGMP group at intervals (the default is 1s), and these are used to notify the peer of the sending group's VGMP group state and priority. If a VGMP group in the standby state doesn't receive HRP heartbeat packets sent from its peer group for three consecutive intervals, it will deem this to mean there has been a failure on the peer VGMP group, and will switch its own state to active.

ü  HRP data packets. Only by adding an HRP header after the VGMP header can a packet be encapsulated into an HRP data packet. HRP data packets are used for data backup between active and standby devices, and include backup of command line configuration and state information.

By this point, everyone is likely wondering: if during firewall hot standby a new VRRP header is used to encapsulate VGMP packets, then do standard VRRP packets still exist, and if so, what are they used for? The answer is that standard VRRP packets still exist, and they are still used for internal communication within VRRP groups. However, as their priority field (Priority) is already a fixed value, it cannot be configured, and so standard VRRP packets actually exist in name only. The loss of the Priority field means that standard VRRP packets can no longer control negotiation of VRRP group state, and can only provide notification of VRRP group states and virtual IP addresses between the active and standby firewalls. This is the same as the role of the "emperor" in a constitutional monarchy―their title is preserved but they lack the power to manage the nation.

VGMP's desire to take over management of firewall and VRRP group states means that VGMP packets must contain VGMP group state and priority information. Let's look again at the structure of the VGMP header.

l   The "Mode" field states whether this is a request packet or a response packet.

l   The "vgmpID" field states whether the VGMP group is an active group or a standby group.

l   The "vPriority" field states the VGMP group's priority.

In addition, information about a VGMP group's state is contained in VGMP packet "data". These two points demonstrate that the VGMP protocol possesses the material basis necessary to allow it to replace the standard VRRP protocol in managing VRRP group and firewall states.

To summarize the above, the VGMP protocol alters the standard VRRP header and defines different kinds of packets that use the VGMP header in encapsulation. With this in mind, through what channel are these packets sent between two firewalls? Above, we discussed the fact that firewalls use a failover channel (the heartbeat cable) to send backup data, and it's obvious that HRP data packets are transmitted through the failover channel. Indeed, all of the various VGMP packets discussed above (with the exception of standard VRRP packets) are transmitted through the failover channel.

In addition, the USG6000 firewall series and the USG2000/5000 firewall series' V300R001 version also support the encapsulation of the various VGMP and HRP packets discussed above (with the exception of standard VRRP packets) into UDP packets. The structure for this is shown in Figure 1-3.

Figure 1-3 Using UDP to encapsulate a VGMP packet

[Dr.WoW] [No.49] The Story of VRRP and VGMP-part 2-1039635-3 

So what is the difference between using VRRP-encapsulated VGMP packets and UDP-encapsulated VGMP packets? The former are multicast packets, can't be transmitted outside the subnet, and aren't controlled by security policies; the latter are unicast packets, and can be transmitted outside of the subnet as long as the route is accessible, and they are controlled by security policies. A bit more specifically, if multicast packets are used, then the two firewalls' heartbeat interfaces must be directly connected or connected through a Layer 2 switch, but no security policy needs to be configured. If unicast packets are used, then the two firewalls' heartbeat interfaces can be connected through a Layer 3 device such as a router, but a security policy permitting packets to pass in both directions between the Local zone and the security zone the heartbeat interface is located in must be configured. In addition, when using a service interface as the heartbeat interface, UDP-encapsulated VGMP packets must be used.

6 Firewall VGMP Groups' Default States

In 4 The Creation of VGMP Solves VRRPs' Problems, we already made a simple introduction into how VGMP guarantees unified switching of VRRP group states, but the actual switching process and packet exchange is a bit more complicated. Before introducing the formation of VGMP states and the switching process in more detail, we'll first introduce firewalls' VGMP groups' default states and priorities.

In Figure 1-4, each firewall provides two VGMP groups: the active group and the standby group. By default, the active group's priority is 65001, and its state is active; the standby group's priority is 65000, and its state is standby. In an active/standby failover scenario, the primary device enables the active group, and all members (for example, VRRP groups) join the active group; the backup device enables the standby group, and all members join the standby group. In a load sharing scenario, both firewalls enable the active and standby groups, and all members on each device join both the active group and the standby group. FW1's active group and FW2's standby group form one "active/standby" group, and FW2's active group and FW1's standby group form another "active/standby" group; the two firewalls are both complementing each other's "active/standby", creating load sharing.

Figure 1-4 Firewall VGMP groups

[Dr.WoW] [No.49] The Story of VRRP and VGMP-part 2-1039635-4 

The above description is applicable to the USG2000/5000/6000 firewall series. As the USG9500 firewall has both interface boards and service boards, their default priorities are different.

The USG9500 firewall series' V100R003 version's VGMP group's default priorities are as follows:

Master (active) group's default priority = 45001 + 1000 x (# of service boards + # of interface boards)

Slave (standby) group's default priority = 45000 + 1000 x (# of service boards + # of interface boards)

 

 

 

To view the list of all Dr. WoW technical posts, click here.

  • x
  • convention:

user_2790689
Created Jan 8, 2016 09:37:41 Helpful(0) Helpful(0)

Thank you for sharing.
  • x
  • convention:

Reply

Reply
You need to log in to reply to the post Login | Register

Notice Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Login and enjoy all the member benefits

Login and enjoy all the member benefits

Login