Our Support Central Blogs can help you resolve your questions without the need for contacting our support organization. Please let us know if this, or any other Support Central Blog has helped you by clicking on the "thumbs up" at the bottom of this post, or leaving a comment.
Problem Summary
How do I troubleshoot network issue with High Availability (HA) pairs?
Customer Environment
Infoblox appliances configured as an HA pair
Versions
All NIOS versions
Cause
When working with High Availability (HA) pairs of Infoblox devices, you may have to troubleshoot connectivity issues. For this reason, this article will show a working HA pair, and show traffic patterns that should be seen when a passive device connects to its active partner.
Resolution
Please see the attached analyzer trace in conjunction with the description (below) for a "picture" of what is going on from the IP packet perspective.
Given the following information:
VIP: 10.10.156.2
VRID: 78
Box 1
Status: Active
LAN: 10.10.156.22
HA: 10.10.156.42
Box 2
Status: Passive
LAN: 10.10.156.16
HA: 10.10.156.46
Assume we are starting with Box 1 already up on the network, and configured to be an HA pair. The trace was taken on Box 1, so when you see the VRRP packets, you will see two packets for every one that you would expect to see. This is because the same device sending them is also receiving them as the Active sends from the HA port, but will see it on the LAN port. This is by design and helps the Active know that the VRRP traffic is actually making it out to the network for the Passive to hear.
--------------------------------------------------------------------------------
Packets 1 - 72 are VRRP keep alive packets from the only box running (the active). We can see the source address is that of the HA port. If we had enabled the option to run the VPN over the MGMT port, we would see that port being used instead, but for this example, the HA port is used.
Starting with Packet 73, we see the LAN port of the Passive sending UDP traffic to port 2114 of the VIP address. This is the initial contact for the Passive, and it will try to connect to the VIP address (which, by definition, will always be found on the Active device.)
From packets 74 - 86, VPN negotiations are taking place. We see a few VRRP packets in there, too, but that is just more keep alive packets, just like packets 1 - 72. During this negotiation process, VPN parameters are passed back and forth, and the "real" UDP port is given by the Active to Passive so a "permanent" connection can be made. The real work that needs to be done, like data syncing, over the HA communications is done over this connection, once it is established, and not via the initial conversation on port 2114.
Starting with packet 87, we see the Passive start a new conversation. Again, it's being sent from the LAN port of the Passive, to the VIP (which is on the Active.) This time, it is using UDP port 1194, which is the default port to use for VPN communications.
A sync of the database now happens so that the device can figure out what its configuration is (packets 87 - 190), and then the device restarts (not a reboot, but a restart) so that it can come up with it's newly acquired database. Since it's restarting, it will (again) connect at port 2214 (as seen in packets 193 - 196), negotiate the other UDP port number to use, and reconnect using that port (UDP port 1194 in this example) as seen in packet 199.
At this point, the HA pair is up and running. The active will continue to send VRRP keep alive packets, and UDP port 1194 traffic will be sent back and forth as data needs to be exchanged.
