Posts

Change hostname on a HA Pair or Single BigIP LTM F5

Below is an exmaple of how to change hostname on a HA Pair BigIP LTM F5

This change requires the command “bigstart restart” which will restart the BIG-IP system services, so don’t run this on a live system without notice

To change this login as root and issue these commands:

BigIP F5 LTM Copying Configuration to another volume

When upgrading an F5 you use different Volumes and when doing this configuration can be lost this shows you how to copy the configuration to the upgrading volume. You can use the cpcfg utility to copy the running configuration from one installation location to another. This is a quick way to update an offline location to the latest configuration, and is useful when applying hotfixes, where the configuration and license are not applied to the target.

The operation replaces the configuration on the target. The destination for the copy operation must represent an installation location that is not currently active, and that contains a configuration older than the source.

To copy the running configuration
# On the source, log on to the command line using an account with administrative permissions.
# Type the following command:

If you do not specify a source, the operation uses the configuration from the active installation location. For example, to copy the active configuration from HD1.3 to HD1.1, if you are logged on to HD1.3, you run the following command:

reference:
http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip_getting_started_guide_10_1_0/bip_gs_pre_install.html

BigIP F5 LTM Check HA Serial Cable Connection

How to verify if the HA serial cable is connected:

F5 LTM – Packet Sniffing HTTP Headers

To confirm that an F5 is adding HTTP headers you can use the following command (via the shell) using tcpdump you can sniff the HTTP Headers

BigIP F5 LTM €œVLAN-Keyed Connections Auto last hop

F5-vlan-key-auto-map

Please refer to the above diagram.

Server A needs to access Server B, the initial SYN packet will go to the firewall, which has a route in place to send traffic to Server B toward the F5 via the €œVIP€ segment. F5 will then route this out of its RC interface.

When Server B replies with SYN+ACK, the F5 will route this directly to Server A, through its connection to the WEB segment.

This causes a problem when Server A replies with ACK as this goes to the firewall which didnt see the SYN+ACK from server B and thus drops the connection.

Below couple of ways to solve this asymmetric routing problem:-

  • Configure a static route on Server A to use the F5 as next hop for the traffic,€“ this is not practical as really Server A represents several servers with more over time.
  • Use of SNAT on the F5 to create a local IP representing Server B on the WEB segment€“ not feasible as Server B represents several servers with more over time.
  • Enable Auto Last Hop on the F5 to have the F5 send Server B’s replies to the firewall ignoring it’s connected route out of the WEB segment.

Point 3 seems the most logical choice however we would also need to disable the setting €œVLAN-Keyed Connections€.

According to F5 documentation it does this:-

Specifies, when checked (enabled), that the system uses VLAN-keyed connections. When enabled, the system uses VLAN-keyed connections when traffic for the same connection must pass through the system several times, on multiple pairs of VLANs (or in different VLAN groups). You should disable this setting for asymmetic routing to work correctly. The default is enabled.

What does this mean in English and as it needed with or without Auto Last hop to solve the issue specified above?

Response from F5:

VLAN-keyed connections is a feature that tells the BIG IP how to handle the connections. Basically, When VLAN-keyed connections are disabled, connection flows are allowed to match any VLANs. Therefore, a connection can be matched to an existing flow and updated, regardless of the VLAN the packet was received on . This is why it is recommended to disable this feature in order to allow Asymetric routing across multiple Vlan.

Here is the solution which explains how you can set up your BIG IP to allow asymmetric routed connections across multiple VLANs:
http://support.f5.com/kb/en-us/solutions/public/10000/300/sol10346.html?sr=21315050
For your implementation , have you also considered npath Routing may be ? Here is the documentation , just in case it could be of any use
http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_implementation/sol_npath.html?sr=21315630

BigIP F5 LTM Verifying that a Certificate and Key Match

Below is an example of how to verify that the Certificate and Key match using the command-line openssl tool.

  1. Open an SSH session to the load balancer using the root account.
  2. Run the first command:
  3. Run the second command:
  4. Each command will output a modulus. If they match, the key and certificate match too.

 

Example

BigIP F5 LTM Auto Last Hop

F5 Big-IP Auto Last Hop

Here is a quick note on a not very well understood Big-IP feature

Auto Last Hop maintains a connection table recording the interface and MAC address of the upstream device which sent the flow to the Big-IP and sends reply packets to this interface/MAC address. This feature can also be called €œreverse persistence€.

So when Auto Last Hop is enabled the following occurs:

  1. A South bound flow comes into the Big-IP
  2. The Big-IP records the ingress interface and source MAC address of the flow
  3. The Big-IP then load balances the flow and routes the packet towards the web server using the routing table
  4. Next a North bound flow comes into the Big-IP (ie a reply packet from the web server)
  5. The Big-IP ignores the routing table and uses the interface/MAC pair recorded in step 2 to switch the traffic

If we disable Auto Last Hop then we use the routing table in step 5 instead.

This is designed to be used on the second layer of load balancers in a firewall sandwich (ie LB/FW/LB). The goal is to load balance traffic to a bank of firewalls and on the second layer of load balancers send the reply packet back to the same firewall. This is to maintain the load distribution and avoid asymmetric routing. With IP routing this isn’t possible, so auto last hop enables this by using Layer 2 information. It can also be useful if you are using a single physical Big-IP to load balance multiple environments, each with their own internet gateway via different physical interfaces.

However in some circumstances it can cause issues. If the upstream device is a resilient pair of routers/firewalls and we have a failover you may find the upstream MAC address changes. Therefore we get an outage as the Big-IP is sending traffic to an old MAC and every session through the Big-IP needs to be rebuilt.

So some more specific examples. If the upstream device is an ASA we are OK as the MAC address will fail across with the IP. If the upstream device is a HSRP address then the MAC address will change (remember the HSRP MAC is in response to ARP requests to the HSRP IP, the Big-IP is just recording the MAC it received from the inbound flow, which is the physical MAC of the routers egress interface).

Auto last hop is enabled by default and can be disabled under System -> Configuration -> Local Traffic

reference:
http://jaluther.blogspot.co.uk/2012/03/f5-bigip-auto-last-hop.html

BigIP F5 LTM TCP Profile for High Bandwidth

The default TCP profiles are perfect in most cases such as websites. The default TCP window size is very conservative, and doesn’t work well when downloading large files. The profile example below is designed to enable high speed downloads, however it should be noted that using this profile may result in higher memory utilization, ultimately limiting the total number of connections the F5 can handle at any given time.

There are two profiles that should be applied to the virtual server; a LAN profile and a WAN profile

LAN Profile

WAN Profile

BigIP F5 LTM Monitor receive ‘200 OK’ as the string

The standard send string most commonly used will look like this:

This works fine, however only allows you to configure a return string based on the actual page which is returned. If you want to check based on the HTTP return code, rather than the page content, you’ll need to use the following send string as a template:

This will then allow you to add “200 OK” to the recieve string.

How is this working

This can be illustrated with a basic telnet session. If you just do a normal GET, this is what you’ll see:

Note that the page content has been delivered, but no return code is present. Using the updated string though:

As you can see, send the additional headers to the server allows it to respond properly including a return code.