Load Balancers


I have a new rule in my F5:

when HTTP_RESPONSE {
if { [regsub -all "<title>" [HTTP::payload] "<title>[LB::server addr] -" newdata] } {
HTTP::payload replace 0 [HTTP::payload length] $newdata
}
}

This is tagged to a virtual server with “Rechunk” enabled. Most of the rules I’ve seen on http://devcentral.f5.com are forcing clients to HTTP/1.0 and disabling chunking, but simply “rechunk”ing the stream seems to allow the F5 to read the data, and not break the app. This is one of 2 rules I have using this feature. Anyways, to the problem:

Documentation on [LB::server name] has been updated. It used to say that [LB::server name] would return the name of the pool member that the client was attached to. I had to open a ticket saying it doesn’t work, and ask why not. Their answer was: yeah, the documentation is wrong. So how to get the feature I want – the pool member name in the title, rather than it’s private IP?

Right now, the only way to get the name of the pool member that the client is pinned to, is [NS::lookup [LB::server addr]]. Depending on utilitzation, however, since you’re rewriting every single page hit, and Linux doesn’t have a client-side caching resolver like Windows does, you might have to dedicate a DNS server just to the F5 for this (I would have to). Or use /etc/hosts. I am NOT a fan of putting anything in /etc/hosts, but for now, I may have to for this system.

Update coming when I get a better fix.

Despite what the documentation may or may not say, do not attempt to upgrade your BIGIP without a working, directly connected console cable. We bricked an LTM 6400 by performing the upgrade exactly as the steps stated, but without using a console cable to watch the output.

Technically, a co-worker was doing the upgrade, so I don’t have full details (I did review the CR and steps), but he was doing the “local network install” via crossover cable into the management interface, so there should have been no issues, since the documentation states that’s OK. But we still completely ruined the box. Thank God no impact to the business, due to the HA pair working properly.

Ran the upgrade on the replacement box today with the “console cable” trick from the support guys, saw an error, fixed it, and everything went smoothly. Now to failover from 9.2.3 to 9.4.1 and reap the benefits of administrative domains! (And teach the other IT groups how to put their own stuff in maintenance/disabled mode.)

Edit: due to several searches ending up here:
Connect with a Null Modem cable, set: 9600,8n1. Make sure that your laptop’s serial port is actually working, by testing with a Cisco device or similar – we have 2 laptops that didn’t get any data on the 9.2.3 OS, but did on 9.1.2, changing laptops (or OS in my case) got us back online.