Due to service needs, a newly deployed office needs a new server with access to NMS network. This server is not in the same network segment as the service server.
For service needs, the new server accesses the external system. After sub-interfaces are created on the Eudemon 1000E firewall, the HRP group fails.
1. According to the ping test, access from the internal service server to all systems is normal after the sub-interfaces are created on the Eudemon 1000E. Therefore, the conclusion is that newly-added configuration is correct. The problem lies in HRP configuration.
2. Query the HRP configurations on the active and standby firewalls, results are as follows:
hrp interface Ethernet2/0/2 transfer-only
hrp interface Ethernet2/0/1
hrp interface Ethernet2/0/0
After the new sub-interfaces are added to HRP configuration, the HRP group takes effect and the fault is cleared. According to HRP documents, the problem is located: ports Ethernet 2/0/2 through which two firewalls interconnect have not been assigned IP addresses. Therefore, hrp interface Ethernet 2/0/2 transfer-only in the configuration script does not take effect.
Problem lies in the HRP configuration after sub-interfaces creation.
HRP has such a mechanism: if the port specified as transfer-only does not take effect, the next HRP port will by default be specified as transfer-only and be used to send HRP packets. The firewall interconnection port at the office was not assigned an IP address, and the HRP group functioned properly. That is because default HRP packet transferring port was ports Ethernet 2/0/1 and HRP turns invalid after sub-interfaces are created on HRP ports Ethernet 2/0/1 and ports Ethernet 2/0/0.
For added performance and security, it is recommended to assign an exclusive IP address for the interconnection port of two firewalls to send HRP packets. Sending HRP packets through service port is not recommended.