An Explanation of the HRP Protocol [Dr.WoW] [No.53]

Latest reply: May 19, 2018 01:31:36 7783 4 3 0

This post underlines an explanation of the HRP protocol. Please read further for details.


In the above introduction to VGMP packet structure we reviewed several kinds of HRP packets, and in this section I'll explain the HRP protocol and several kinds of HRP packets for everyone, including: HRP data packets, heartbeat link detection packets and HRP consistency check packets.

You may be wondering: "Isn't HRP responsible only for data backup between two devices― what's so difficult about this? Actually, there is still much more to discuss about HRP, and I'll now reveal these juicy details about HRP for everyone.

1 HRP Overview

Firewalls use commands (Web configuration is actually also executing a command(s)) to achieve the various functions required by users. If a configuration command is not backed up to the backup device prior to a backup device becoming the primary device, then the backup will not be able to achieve the primary device's functions, resulting in a service interruption.

In Figure 1-1, a security policy permitting an intranet user to access an external network has been configured on the primary device (FW1). If the security policy configured on primary device FW1 has not been backed up to backup device FW2, then if the primary device's state changes, the new primary device (FW2) will not permit the intranet user to access the external network (because the firewall's implicit deny policy denies packets that fail to match any policy).

Figure 1-1 Scenario where a configuration command has not been backed up

569c50f47906c.png 

The firewalls are stateful inspection firewalls, and have session table entries corresponding with every dynamically generated connection. Many dynamic sessions are created on the primary device, but not on the backup device, because no packets pass through it. If sessions are not backed up to the backup device before the backup device becomes the primary device, subsequent service packets will not match any session and will be discarded.

In Figure 1-2, a session for PC1 accessing PC2 (source address 10.1.1.10, destination address 200.1.1.10), has been created on primary device FW1, and subsequent packets between PC1 and PC2 will be forwarded according to this session. If the session on the primary device (FW1) cannot be backed up to the backup device FW2, then after active/standby state switching, PC1's subsequent packets accessing PC2 will not match a session on FW2. This will result in the interruption of PC1's services accessing PC2.

Figure 1-2 Scenario in which the session has not been backed up

569c51083e2e5.pngTherefore, in order to ensure that the backup device is able to smoothly take over work when the primary device fails, key configuration commands and state information such as session tables, must be backed up between the primary and backup devices. To achieve this, Huawei has introduced the HRP (Huawei Redundancy Protocol) protocol.

In Figure 1-3, a security policy permitting an intranet user to access an external network(s) is configured on FW1, and FW1 will thus permit packets from intranet PC1 to the external network's PC2, and will establish a session. As the HRP protocol (with hot standby configured) is used on both FW1 and FW2, the security policy configured on FW1, as well as the session created on FW1, will both be backed up to the backup device FW2. Therefore, packets from PC1 to PC2 will not be denied after the active/standby failover.

Figure 1-3 Scenario when session and configurations are backed up

569c5118ce400.pngTo summarize the above, in an active/standby failover network, configuration commands and state information are both backed up to the backup device from the primary device.

However, in a load sharing network, the two firewalls are both primary devices (they both have active VGMPs), and thus if the primary devices are permitted to synchronize commands between them, the two firewalls' commands may be overlapping or conflicting with one another. Therefore, to avoid such problems, we define that in a load sharing network, configuration commands are backed up only from the master configuration device (whose command line prompt begins with HRP_A) to the backup configuration device (whose command line prompt begins with HRP_S). However, state information is backed up between both devices.

NOTE

 

In load sharing, the first device on which hot standby is enabled is the master configuration device (whose command line prompt begins with HRP_A).

2 HRP Packet Structure and Implementation Mechanisms

Firewalls use heartbeat interfaces (the HRP failover channel) to send and receive HRP data packets to synchronize configuration and state information. In Figure 1-4, HRP data packets have been sequentially encapsulated with a VRRP header, a VGMP header, and an HRP header (listed from outside>in). Of these, the VRRP header's Type=2 and Type2=2. In the VGMP header, the field "vType" corresponds with the "HRP data packet" value.

Figure 1-4 Structure of an HRP data packet

569c5128abe4a.png 

An explanation of the key parameters in an HRP header follows:

l   Source Module ID and Source Sub Module ID state which of this firewall's modules and sub-modules' data need to be backed up.

l   Dest Module ID and Dest Sub Module ID state which modules and submodules data need to be synchronied to the peer firewall.

The process of HRP data backup is shown in Figure 1-5:

1.         When FW1 sends an HRP data packet, it will write the ASPF module's ID into the HRP headers' "Source Module ID" and "Dest Module ID" fields, and encapsulate the ASPF module's configuration and table entry information into the HRP data packet.

2.         FW1 sends the HRP data packet through the failover channel (heartbeat cable) to FW2.

After FW2 receives the HRP data packet, it will send configuration and table entry information in the packet to its own ASPF module according to the "Source Module ID" and "Dest Module ID" fields in the HRP header, and issues the configuration and table entries.

Figure 1-5 HRP data backup process

569c51369c8ba.png 

Above, I mentioned that USG6000 series firewalls and the USG2000/5000 series' V300R001 version firewall also support many kinds of VGMP and HRP packets being encapsulated into UDP packets. Of course, we're introducing HRP data packets here, and the heartbeat link detection packets and consistency check packets that I will discuss below can also be encapsulated into UDP packets by adding a UDP header to the VRRP header. The structure of UDP HRP data packets is shown in Figure 1-6.

Figure 1-6 Structure of UDP HRP data packets

569c514362387.png 

A benefit of using UDP packets is that UDP packets can be transmitted across networks and controlled by security policies because UDP packets are unicast packets.

3 HRP Backup Methods

Hot standby's HRP supports three backup methods―automatic backup, manual batch backup, and fast backup. I'll describe these backup methods, and the differences between them, one by one below

l   Automatic backup

The automatic backup function (the command is hrp auto-sync [ config | connection-status ]) is enabled by default to automatically back up configuration commands in real time and periodically back up state information; this function is used in various hot standby networks.

?       After the automatic backup function is enabled, each time a command that can be backed up is executed on the primary (master configuration) device, the configuration command will be immediately synced and backed up onto the backup (backup configuration) device.

Configuration commands (that can be backed up) can only be configured on the primary (master configuration) device, and cannot be configured on the backup (backup configuration) device. Configuration commands that cannot be backed up can be configured manually on the backup (backup configuration) device. To view which configuration commands can or cannot be backed up, please see 04 Configurations and State Information that HRP Can Back Up.

?       After enabling the automatic backup function, the primary device will periodically back up state information (so long as it can be backed up) onto the backup device. This means that the state information established on the primary device won't be backed up in real time.

Automatic backup will not back up the following session types (only supported by fast session backup):

ü  Sessions to the firewall itself, for example a session generated when an administrator logs in to the firewall

ü  Half-open TCP connection sessions that have not completed a three way handshake

ü  Sessions that were only created for an initial UDP packet and are not matched by subsequent packets.

l   Manual batch backup

Manual batch backup is done by executing the hrp sync { config | connection-status } command on the primary device. After the command is executed:

?       The primary (master configuration) device will immediately sync configuration commands (so long as they can be backed up) to a backup (backup configuration) device.

?       The primary device will immediately sync state information (so long as it can be backed up) to the backup device.

l   Fast backup

The fast session backup function (the command is hrp mirror session enable), is used in load sharing to address scenarios in which the forward and return paths are not the same. To ensure that state information is immediately synchronized, the fast backup function only backs up state information, not configuration commands. The backup of configuration commands is done by the automatic backup function.

After the fast backup function is enabled, the primary device will immediately synchronize established state information that can be backed up (including the sessions mentioned above that automatic backup does not support) onto the backup device in real time.

To summarize the above, these three backup methods are generally used as follows: automatic backup (hrp auto-sync [ config | connection-status ] is enabled by default, and shouldn't be disabled; if configuration between primary/backup devices is not synced, then the manual batch backup command (hrp sync [ config | connection-status ]) needs to be executed; if the network uses load sharing, this generally requires enabling the fast session backup function (hrp mirror session enable).

Below I'll explain why fast session backup is especially useful in load sharing networks.

In load sharing networks, as the two firewalls are both primary devices, they can both forward packets, and so there may be situations in which the forward and return packets take different paths (passing through different firewalls). When this happens, if the state information has not been immediately backed up between the firewalls, return packets will be discarded they cannot match any state information, resulting in a service interruption.

To prevent this, the fast session backup function must be enabled in load sharing networks to allow two firewalls to mutually back up state information in real time, so that return packets can match the state information, regardless of which firewall they pass through.

In the example in Figure 1-7, FW1 and FW2 have formed a load sharing network. Packets from an intranet PC to the server on the external network are forwarded through FW1, and a session is established. As the forward and return paths are not the same, the return packets sent from the server to the PC are forwarded to FW2. If at this time only the automatic backup function is enabled, then FW1's session has not been backed up onto FW2. This means that the return packets cannot match a session on FW2 and will be discarded.

If the fast session backup function is enabled, then sessions generated on FW1 will be immediately backed up onto FW2. Therefore, return packets can match a session on FW2 and be forwarded to the PC.

Figure 1-7 Scenario in which forward and return packets take different paths

569c515158c9f.png 

4 Configurations and State Information that HRP Can Back Up

The configurations firewalls can back up are shown below (as applies to the USG6000 firewall series' V100R001 version):

l   Policies: security, NAT, bandwidth management, authentication, and attack defense policies, blacklists, and ASPF

l   Objects: addresses, regions, services, applications, users, authentication servers, time intervals, URL classifications, keyword groups, email address groups, signatures, security profiles (antivirus, intrusion prevention, URL filtering, file filtering, content filtering, application behavior control, and email filtering profiles)

l   Networks: new logical interfaces, security zones, DNS, IPSec, SSL VPN, TSM interworking

l   Systems: administrator and log configuration

NOTE

Backup of display, reset and debugging commands is typically not supported.

From the above description we can see that a firewall network's basic configurations (such as interface addresses and routes) cannot be backed up, and configuration of these needs to be completed prior to the successful establishment of a hot standby state. Meanwhile, the supported configurations listed above can be configured on the primary device alone after a hot standby state has been successfully established.

The stateful information that firewalls can back up is shown below:

l   Session tables

l   Server-map tables

l   IP monitoring tables

l   Fragment caching tables

l   GTP tables

l   Blacklists

l   PAT port mapping tables

l   NO-PAT address mapping tables

5 Heartbeat Interface and Heartbeat Link Detection Packets

As shown in Figure 1-8, data backed up between two firewalls is sent and received through the firewalls' heartbeat interfaces over the heartbeat link (the failover channel). A heartbeat interface must have an IP address. This can be a physical interface or a logical interface (such as an Eth-Trunk interface bonded by multiple physical interfaces to increase bandwidth). Under normal circumstances, backup data constitutes about 20%-25% of service traffic, so the number of physical interfaces depends on the volume of backup data.

Figure 1-8 Physical and logical interfaces serving as the heartbeat interfaces

569c5161c9d1d.png 

A heartbeat interface has five possible states (viewed by executing the command display hrp interface):

l   invalid: this state is displayed when a firewall's heartbeat interface is incorrectly configured (the interface is up, but the line protocol is down)―for example, the specified heartbeat interface is a Layer 2 interface or the heartbeat interface's IP address has not been configured.

l   Down: this state is displayed when a firewall's both the heartbeat interface and the line protocol are down.

l   peerDown: when both the heartbeat interface and the line protocol are up, the heartbeat interface will send a heartbeat link detection packet to its peer device's heartbeat interface. If no response packet from the peer is received, the first firewall will set its heartbeat interface's state as peerDown. However, the heartbeat interface will continue to send heartbeat link detection packets to restore the link once the peer's heartbeat interface is up.

l   ready: when both the heartbeat interface and the line protocol are up, the heartbeat interface will send heartbeat link detection packets to the peer device's heartbeat interface. If the peer's heartbeat interface responds to these packets (by also sending heartbeat link detection packets), then the firewall will set its heartbeat interface's state as ready, and be prepared to send and receive heartbeat packets at any time. The heartbeat interface will continue to send heartbeat link detection packets to monitor the state of the heartbeat link.

l   running: when a firewall has multiple heartbeat interfaces in the ready state, the firewall will choose the heartbeat interface that was first configured to form the heartbeat link, and will set this heartbeat interface's state as 'running'. If there is only one heartbeat interface in the ready state, then it will naturally be the heartbeat interface that enters the running state. The interface in the running state is responsible for sending HRP heartbeat packets, HRP data packets, HRP consistency check packets and VGMP packets. The remaining 'ready' heartbeat interfaces will be in backup state, and if the heartbeat interface in the running state or the heartbeat link fails, the remaining heartbeat interfaces in ready state will replace the current heartbeat interface one by one in configuration order. As shown in Figure 1-9, the order in which two firewalls' heartbeat interfaces are configured is the same as the interface numbering scheme, so GE1/0/3 changes into the running state, and GE1/0/4 is in a backup state.

Figure 1-9 Heartbeat interface states

569c516f7be04.png 

To summarize the above, the role of heartbeat link detection packets is to detect whether a peer device's heartbeat interface can receive the other device's packets to determine whether a heartbeat link can be used. So long as the sending device's heartbeat interface and line protocol are both up, the heartbeat interface will send heartbeat link detection packets to the peer's heartbeat interface.

Heartbeat link detection packets are also encapsulated with the new VRRP header. When Type=2, and Type2=1 in the new VRRP header, packets are encapsulated into heartbeat link detection packets.

Above, we discussed the fact that HRP heartbeat packets are used to detect whether the peer device (VGMP group) is working normally. HRP heartbeat packets are only sent by the primary device's VGMP group through a heartbeat interface in the running state.

6 HRP Consistency Check Packets' Role and Mechanism

HRP consistency check packets are used to check whether the hot standby configurations of two firewalls in hot standby states are consistent and if their policy configurations are identical. Consistency checking of hot standby configuration includes checking whether two firewalls are monitoring the same service interfaces, and whether the same heartbeat interfaces are configured on them. Policy configuration consistency checks primarily involve checking whether two firewalls have identical policies, including security, bandwidth, NAT, authentication, and audit policies. HRP consistency check packets are also encapsulated by VRRP headers. When Type=2 and Type2=5 in a VRRP header, packets are encapsulated into HRP consistency check packets.

The implementation mechanism of the HRP consistency check is as follows:

3.         After the consistency check command (hrp configuration check { all | audit-policy | auth-policy | hrp | nat-policy | security-policy | traffic-policy }) is executed, the device will send a consistency check request packet to its peer and collect the brief configuration information from its own relevant modules.

4.         After the peer device receives the request, it will collect the brief configuration information from its own relevant modules, and then encapsulate the information into a consistency check packet to return to the first device.

5.         The first device compares its own brief configuration with its peer's configuration, and then records the compared information. The customer can execute the command display hrp configuration check to view the results of the consistency check. The below results show that the hot standby configuration is consistent.

HRP_A<FWA> display hrp configuration check hrp

Module     State   Start-time            End-time               Result

hrp         finish 2008/09/08 14:21:56 2008/09/08 14:21:56 same configuration

 

 

 

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


  • x
  • convention:

user_2790689
Created Jan 18, 2016 03:58:51 Helpful(0) Helpful(0)

Thank you.
  • x
  • convention:

matuss
Created Nov 27, 2017 11:40:44 Helpful(0) Helpful(0)

When you have problem, as traffic flows through slave, not through master (active/standby mode) and all other (hrp, vrrp) have good config.
Check: http://forum.huawei.com/enterpri ... p;page=1#pid2009749 This post was last edited by user_2904663 at 2017-11-27 13:11.
  • x
  • convention:

magog
Created Feb 11, 2018 08:59:56 Helpful(0) Helpful(0)

good document. thanks :)
  • x
  • convention:

w1
Created May 19, 2018 01:31:36 Helpful(0) Helpful(0)

useful document, thanks:
  • 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