Discovery of failover peer using iControl

Hi Derek,

What is a "routable" IP address on your network? 192.168.255.x could be routable from somewhere on your network if it's what a unit is configured for. Are your LTM's configured with hostnames which might allow you to identify the peer (i.e. sfo-bigip-1, sfo-bigip-2)? Do they use MAC masquerading for any VLANs? This might allow you to identify two peer units.

Worst case, maybe you could create a datagroup named "unit_hostnames" which would contain the two hostnames and the IP addresses you'd prefer to access them by?

 
 class unit_hostnames { 
    sfo-bigip-1 212.1.1.1 
    sfo-bigip-2 212.1.1.2 
 } 
 

Aaron

HA pair boxes are typicaly configured for failover using a private VLAN shared only between that pair. By asking one box about its peer address you will only get that private (and in your case non-routable) self IP.

 

In your iControl application you can first query ALL your BIG-IP boxes using their routable *management IP* addresses for their floating Self-IPs using Networking.SelfIP.get_list and Networking.SelfIP.get_floating_state iControl calls and store all the Self IPs in your application in some sort of a structure/array for comparison purposes.

 

 

You will then need to do a FloatingIP comparison/matching in your application code to figure out which boxes are HA peers.

 

 

Do not use the VIP comparison method - as you have spotted yourself it is highly unreliable.

I don't think that will work...

 

 

thx

 

 

-d

 

 

anyone else???

What won't work? Sam's suggestion seems like it would work.

 

 

How are you connecting to the first unit to start with? Can you use that initial hint to pick a "routable" address from the peer's configuration?

 

 

Aaron

I'll try that thanks

Can you clarify what you're trying to do and a little background on why? What you've provided so far isn't very clear.

 

 

A redundant pair can have several IP addresses:

 

 

Failover Address

 

Primary Connection Mirror Address

 

Secondary Connection Mirror Address

 

Self IP addresses

 

Management IP address

 

 

'Routable' in this context can mean many things. RFC1918 IP addresses may not be routable on the internet, but they can be routable on an internal network. For your user, which category of BIG-IP IP addresses are usable? Which IP address are you using to make the iControl calls to one unit? What information will your user provide? What information will your user want to receive? i.e. what data are you starting with and what data do you want to find?

 

 

Your user doesn't have to be intelligent to implement a solution like what Sam suggested--your iControl program does.

 

 

Aaron

Derek, so you don't know the management IP addresses of all your BIG-IP boxes? How are you planning to do the discovery of any F5 devices?

 

 

For example by scanning your network for iControl responses on port 443 you can discover all your BIG-IP devices and store their SelfIPs in your application, then query all of them (since you have discovered them and know all their IPs) for their Failover status (ACTIVE/STANDBY) and then just do the Floating IP match to tie the HA pair together.

 

 

If you ask each box "tell me your peer IP address" you will get the only IP address which is known to that box - which could be a non-routable one, so you won't be able to match that with anything. I think this is what you are trying to do and this is your current problem.

 

 

So DO NOT ask each box for its failover peer IP address as this information is useless to you.

 

 

Instead ask each box: "give me your floating IP address and your failover status" using iControl. Whichever Standby box replies with the same Floating IP as previously seen Floating IP for an ACTIVE box is its peer.

 

 

If management IP addresses of all your boxes are not known to your application or you don't want to discover all the boxes for some reason then the above solution will not work.

 

 

If you want to connect to just one F5 box and figure out the routable IP of its failover peer then it is not possible. The only other workaround is if you have Connection Mirroring configured and one of the Connection Mirror IP addresses(primary or secondary) is routable. In this case you can ask each box - "give me your connection mirroring peer IP addresses". These are "StateMirror.PeerIpaddr" or "StateMirror.Secondary.PeerIpaddr" BIG DB variables.

 

 

Hope this helps,

 

Sam

 

Sam, I'll put another vote in for your approach - I really think this will work well, or at least it'll give you all of the data you need to figure this out programatically.

😧 I'm not clear at all as to why Sam's original method wouldn't work here...sorry if I am missing something, but to reiterate:

1) Discover units - if there's something listening on 443 and it's got a valid iControl URI you can assume it's a BigIP. Hit it via iControl and do a get_version() to be certain.

2) Interrogate Self-IP information on the unit using the calls Sam outlines above. Stuff this info into a structure that you can build/compare against other systems.

Once you build a structure you can go nuts with comparisons intersections, etc. Here's an example of building a Python dictionary (or perl hash, etc) from the pertinent info:

 
 In [20]: self_ips1 = b.Networking_SelfIP.get_list()['return'] 
 In [26]: print self_ips1 
 ['10.0.0.90', '172.16.1.1', '172.16.1.2'] 
  
 In [27]: floating_ips1 = b.Networking_SelfIP.get_floating_state(self_ips = self_ips1)['return'] 
 In [28]: combined = dict(zip(self_ips1, floating_ips1)) 
  
 In [30]: print combined 
 {'172.16.1.2': 'STATE_DISABLED', '10.0.0.90': 'STATE_DISABLED', '172.16.1.1': 'STATE_ENABLED'} 
 ...then build your other data structure, and: 
 In [33]: '172.16.1.1' in combined2.keys() 
 Out[33]: True 
 

So we now know that these two units share 172.16.1.1, and are therefore a pair...this should get you very close, no?

-Matt

Let me clarify what I'm trying to achieve.

 

 

I'm basically writing an application that will store all information about our F5's in a database. One of the requirements is that we have the ability to correctly detect which F5's are in a redundant pair, either Active-Standby or Active-Active.

 

 

First, it is reasonable to think that I would know the management IP of all F5 devices. I am depending on user input for the management IP address of the F5. The program I'm working on just needs to be able to correctly identify a Failover pair.

 

 

Now that I look at this more, I think Sam's idea is solid, and that is the method I'm going to work with today to see if I can do this.

 

 

Thanks again,

 

 

--Derek

 

 

So I've done some more work on this today, and discovered that our enterprise actually has a pair of LTMs without any floating self-ip addresses. They have self-ip addresses assigned to their respective vlans, yet they do not have any floating self-ip addresses assigned. Are there any conceivable designs where this could be a proper configuration? I don't think this particular pair was configured correctly, but it has proven that this case can exist, and that this configuration does appear to work in this scenario. Since the servers do not use the F5 as their default gateway (we have a pair of core routers for that), the only benefit I came up with to having a floating self-ip would be that the connections in progress could be failed over to the standby LTM in case of failure, if connection mirroring was enabled.

 

 

I'm trying to determine if there are fringe cases in which no floating self-ip addresses would exist, thus I would be unable to correctly identify a redundant pair. I can imagine that in some more complex networks (or networks operated by people that like pain and agony) you could run across OSPF or other routing protocol which would be relied on instead of a floating IP address for failover. Has anyone seen such a design?

 

 

Also, I am curious if there is any distinct drawback to not having a floating self-ip assigned to the internal VLAN. If there is no requirement for the F5 to be the default gateway, the floating self-ip seems to not be as critical.

 

 

I considered making an assumption that any self-ip addresses within the same netmask (say 10.0.0.100/24 and 10.0.0.101/24) would give me a good enough "guess" that these two LTMs are a redundant pair. I can already think of reasons this assumption would be wrong, in that possibly an enterprise would have a large subnet for application servers (such as 10.10.0.0/20). There could conceivably be multiple LTM pairs with self-ip addresses on this large network.

 

 

So, do you folks think that I can safely assume that coming across a pair of redundant LTMs without any floating IP between them would be a fringe case of mis-configuration?

 

 

Thanks,

 

-Derek