The eSpace U1980, IP phone, and UA5000 are on the same network segment. The Virtual Router Redundancy Protocol (VRRP) is enabled on both switches. The active SMCU board on the eSpace U1980 connects to one switch, and the standby SMCU board connects to the other switch to implement redundancy, as shown in the following figure.
The following problem is found during the onsite test:
When the active SMCU board is removed from the eSpace U1980 and the standby SMCU board is installed, all devices on the network work properly.
When the standby SMCU board is removed and the active SMCU board is installed, the IP phone and UA5000 fail to register with the eSpace U1980.
When the active SMCU board is removed, the standby SMCU board broadcasts gratuitous Address Resolution Protocol (ARP) packets, and all devices on the same network segment update their ARP entries. Therefore, these devices work properly.
When the standby SMCU board is removed and the active SMCU board is installed, the IP phone and UA5000 fail to register with the eSpace U1980 due to the following causes:
Before the active SMCU board is installed and after the standby SMCU board is removed, no SMCU board is available for a short period of time. When the active SMCU board is installed, the eSpace U1980 does not consider that the active SMCU board replaces the standby SMCU board. Therefore, the active SMCU board directly starts working without broadcasting gratuitous ARP packets. The active SMCU board proactively looks for the gateway and sends the ARP REQUEST packet to the gateway. The gateway upgrades the ARP entry. Therefore, the communication with other network segments is not affected.
However, the IP phone and UA5000 still store their ARP entries for the standby SMCU board. (The aging time is 20 minutes.) Without receiving the update notification from the active SMCU board, the IP phone and UA5000 communicate with the eSpace U1980 based on expired ARP entries. As a result, the IP phone and UA5000 fail to register with the eSpace U1980.
The active/standby redundancy function is incorrectly understood.
This problem is not a fault. It is caused by misoperations. This problem seldom occurs in the real environment but often occurs during the onsite test. The customer may consider this as a switchover failure between the active and standby SMCU boards. Front-line engineers must understand that this is not a fault. In addition, if you test the switchover function between the active and standby SMCU boards by connecting and disconnecting network cables, the same problem will occur.
You are advised to strictly follow test procedures during tests.