So now that we've got a vLTM installed and running, what can we do with it... There's a lot of examples out there of perl, python and Java. But not a lot of C...

I've also got an iPhone... Sadly we can't use my favourite SOAP programming language on the iPhone. In case you're wondering that's perl. Why perl? Well, mainly I'm a bit lazy, and perl does everything for you... Obviously you're more productive when that's the case, and the SOAP::Lite module has spoiled me for years I'm afraid, but it's time to do some hacking (And in the early days it gets quite ugly) in what I'd consider to be a rather obscure variant of C. Yes, it's Objective-C...

Like I've mentioned, the network map is a cool feature. One page showing your BigIP status. Virtual Servers, Default Pools, iRules, PoolMembers etc... Wouldn't that be nice on your iPhone? (Or better yet, your iPad). Obviously some things need to be altered a bit, the iPhone screen isn't exactly the best for viewing a lot of information at once, but it's nice to be able to pull it out of your pocket and quickly check the status when in a meeting...

But this isn't about iPhone programming. It's about getting your iPhone to talk to BigIP. And for that we use iControl. The F5 SOAP API to monitor and control an F5 appliance.

Opening a connection

First off. How to talk to the F5... Well, iControl is a SOAP interface. And this is based upon HTTP. Basically we open an HTTPS connection to the iControl server and send it a few pages of XML that tell it what we want it to do. Then it sends us several more pages of XML to tell us the 4 or so lines we wanted to know... (In case you get the opinion I think SOAP and XML are a wee bit excessive, you're probably right).

In objective-C we do something like this

-(XMLNode *)queryF5:(NSString *)operation namespace:(NSString *)namespace params:(NSMutableDictionary *)params {

NSString *targetURL = [NSString stringWithFormat: @"https://%@:%@@%@:443/iControl/iControlPortal.cgi", adminUser, adminPass, managementHost];


NSMutableURLRequest *req = [SOAPRequest requestForOperation:operation

atURL:[NSURL URLWithString: targetURL]



[req setTimeoutInterval:10];


NSURLResponse *resp;

NSData *respData = [NSURLConnection sendSynchronousRequest:req returningResponse:&resp error:nil];

NSString *debugString = [[NSString alloc] initWithData:respData encoding:NSUTF8StringEncoding];

if (respData == nil) {

// Error while sending SOAP request");

return nil;


// Successfully sent SOAP request, getting response

XMLNode *response = [SOAPResponse responseWi

return response;


What does this do? Well, ignoring the fact that some of the variables are seemingly appearing out of thin air (They're not really, they are class member variables. e.g. the adminUser, adminPass etc). First we setup the URL we want to talk to. That's the string


and we replace all those %@'s with the adminUser, adminPassword and ManagementHost respectively. I'll leave the discussion of what those variables actually are to their descriptive names. But basically we're accessing a URL using (semi) standard URL format. Note that the semi-standard nature of this format is due to the fact that the user:password@host is not actually a part of the HTTP standards. It's an extension made popular by usage only. And luckily the F5's recognise and respond to it.

Even though I said this wasn't about iPhone programming, in iPhone world, there is one extra piece of work we have to do. By default an F5 uses a self-signed cert for the HTTPS connection we're using for iControl. And by default an iPhone the iPhone wants to verify the cert trust. Which of course it can't. So we need to over-ride the check. That's done with a piece of code I found on the net...


@implementation NSURLRequest(DataController)

+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host


return YES; // Should probably return YES only for a specific host



Which over-rides the certificate check for the NSURLRequest class we're using to make a SOAP request.

Next Time

Well. Next time I'll show an actual request and response. And the work that goes into decoding an XML response from a SOAP server. I'd doit in perl, but that's so easy, it's only worth a few lines of code and saying go for it... Doing it in C (Or objective-C in this case) is a fairly surprising piece of work.

Other Random Notes

  • Static IP's... Normally you'd run an LTM with either a full-blown DHCP/DDNS architecture, or with a static IP. Most likely a static IP. However in the vLTM world, we're presented with a DHCP configuration on the vLTM and an environment (IN VMWare Fusion) that doesn't really do DDNS, and has a nasty habit of allocating a new IP everytime you suspend your laptop... There are plenty of reasons that I like to run static IP's on my LTM's, but vLTM seems remarkably resistant to allowing this (It may be a bug?). The result is to configure a static IP I had to resort to the command line config utility... I haven't used that since v4...
Comments on this Article
Comment made 19-Feb-2012 by website development 0
I followed your instructions and everything turned right for my process of website development! Thx!
I am waiting for information about XML response from a SOAP server!