Discovery of failover peer using iControl

Derek,

 

 

Your question on cases where you would have a legitimate case of an HA pair configured WITHOUT a floating IP is better suited for a different forum such as the Advanced Config/Design forum on DevCentral.

 

 

Even though your backend servers don't have BIG-IP as a default gateway in a typical load-balancing scenario the return packets must go via the BIG-IP(using SNAT Automap for example) in order for the response packets to reach the client (and BIG-IP to manipulate/compress the response if required).

 

 

nPath routing (returning packets from backend servers bypassing the BIG-IP) is only applicable in specific cases ( see https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_sol_guide_943/sol_npath.html )

 

 

 

Sam

 

 

Thanks Sam, I'll post the question on the Advanced Config/Design forum.

 

 

In our scenario the packets will always go to the F5 as it has a self IP on the server VLAN, so when it communicates with a server it's all via directly connected subnet thus a default gateway or other routing decision is not needed for either the F5 or the servers. I'm still unclear just what having a floating self-ip would buy us in this design (other than me being able to detect a failover pair!), but again that's probably a question best suited for the Advanced Config/Design forum.

 

 

Thanks,

 

-Derek

Okay, the consensus from the Advanced Config/Design forum is that a floating self-ip is not necessary in certain scenarios, and thus I cannot rely on a floating self-ip being present on an LTM.

 

 

At this point I think maybe human input is the only way to definitively discern which two LTMs are indeed in a failover pair. While it would be nice to automatically detect this, I suppose it's not unrealistic to think that someone using the software I'm working on should really know which two LTMs are in a failover pair.

 

 

As a last effort, are there any other ideas??? I suppose the floating IP address could be a primary means of detection if it exists, then fallback to human input should no floating self-ip exist on the device.

 

 

Thanks,

 

-Derek

Also, a nice feature request for a future SDK would be to have an object you could query that would give you the *management* IP of the failover peer. Do you guys agree that would suffice?

Out of curiosity, could he not get the 'peer' address from the HA status.

 

 

Then compare that against the selfIP table? They are both SelfIP's.

 

 

If your peer exists in the selfip table, they are peers.

 

 

That is, unless you use the same peer address for all of your pairs.

 

 

--J

I think, this can be easily achieved

 

 

use the iControl API

 

 

Step 1: Connect to a box using iControl

 

Step 2: get_failover_state , It will respond 1 for Active and 0 for the Standby

 

Step 3: get_peer_address, It will give you the IP address for Peer

 

Step 4: Connect to the IP address that ou just got , using iControl

 

Step 5: get_failover_state, you will get the response

 

 

If the response got from step 2 and step 5 are "1" then it is Active Active config, if not, its active standby.

 

 

You could chose to add the "is_redundant" before the script gets into all the computation. I think this is logically consistant.

Alok,

 

 

Well, I've already been down that road, and it may work under certain circumstances, but will not work under all circumstances. get_peer_address will give you the address of the config_sync peer, whatever that is configured to be. Many folks will use a separate VLAN for this, which is not routable, and is only for configuration synchronization between two LTMs in an HA pair, thus you could not connect via iControl to the IP address you receive from get_peer_address. Additionally, there is nothing stopping people from configuring the same config sync IP address for every HA pair they have, e.g. 192.168.0.1 and 192.168.0.2, if they use an isolated VLAN so that they are not routable. There's no real reason you couldn't do this (and I've seen it done). So in this scenario, you could end up with two different individual LTMs with the exact same failover IP address, and no real way to tell which one is the right config sync peer.

 

 

Basically, there is no current reliable way that I have found to automatically detect a failover peer. Where I left off on this issue is that I'm going to go back and try this using the ARP tables, more specifically Networking/ARP->get_dynamic_arp. Basically given an arbitrary number of LTMs in a network, figure out which two are talking to each other by looking at all of the ARP tables and then figuring out which two LTMs have each other's MAC address in their respective ARP table. I know, it's crazy but it just might work, but we shall see.

 

 

I will certainly post back to this thread if I am successful.

 

 

Thanks,

 

-Derek

Well, Thats there, the ARP thing is some thing i also tried out, but ARP is always not available (if we could execute a Ping on the broadcast address using the iControl, which i assume is not possible now, we could get all the ARP's of the devices connected in that network) We could get all ARP entries and filter that forOUI (00-01-D7). This might also get some VIP's arp if proxy arp was enabled

 

 

I have 2 pairs of Big IP's on the same external network, so when I was doing the ARP, some it was also giving the ARP of the other boxes even if I filtered out based on the OUI (00-01-D7)

 

 

Now, we have to actually go to the boxes and conform if they are the failover pair. If the network is well designed, like .1 for floating .2 and .3 for individual boxes, we can use that logic.

 

 

If we have a list of boxes, the logic could be

 

 

1. iControl in to each box, take the o/p is redundant and the floating self IP's

 

2. Save that data in an array

 

3. Check if any 2 boxes have same saet of floating IP's and then they can be considered a pair

 

4. icontrol into them and get the failover status

 

 

 

Thats just a thought .. what do you think ?

There is another thing, if we could manage to save the UCS file of the other box when the config sync is done, rather than deleting it after sync was over. We could execute a config sync pull (getting the remote UCS) and then use the file transfer wizard take it .. and then check the bigip_base file for the self IP address. this will be very accurate. Though I think this is not really possible using iControl

Hm, I would think that the ARP entry for the failover communication IP addresses would always be in the ARP cache, since there is quite a bit of communication which happens on that link.

 

 

Using the floating IP addresses will not work 100% of the time either, in the following cases:

 

 

- there are no floating self-ip addresses on the LTM because it is not the default gateway for hosts

 

- there are identical self-ip addresses defined on multiple pairs because you are using anycast (having the same VIP IP in multiple data centers)

 

 

I could definitely ssh to the admin interface and run bigpipe commands to get the configuration, then store the configuration for parsing later, so there are ways around this. I just thought it would be cleaner to do everything in iControl.