documentation: using ALB with DSR

[chen23]

Description

Working with a Microsoft Azure Architect we had a discussion/POC with a customer where MS had created a configuration of using a Public IP address configured with DSR to the BIG-IP in the template "failover-lb".

This met a requirement of being able to see the Public IP directly on the BIG-IP and not perform any address/port translation. It does complicate how to create a health probe. MS had used the MGMT Web UI as a health probe, I've created specific iRules that return "OK".

Ideally we would have guidance on a sane setup for supporting this configuration or caveats about using this setup. IMHO it's a good solution.

Template

"cluster-lb"

Severity Level

For bugs, enter the bug severity level. Do not set any labels.

Severity: 5

[jmcalalang]

I did this for a customer about a year ago on a recommendation of a MS SA for port exhaustion on an Azure LB, it works like a champ, of course it required the LB out front so it took out the HA-AVSET option from the customer i was working with.

Name removed for the VIP, if you need the actual customer let me know.

[chen23]

FYI, here's a (lame) iRule that I used to send back a happy health check (for A/A):

A/A

when HTTP_REQUEST {
  HTTP::respond 200 content "OK"
}

Apply this to the IP:PORT that ALB is configured to monitor. i.e. 10.0.1.5:8888 on bigip1 and 10.0.1.6 on bigip2 these could either be the selfip (primary private address) or secondary. For some reason I think ALB prefers to monitor the primary (tcpdump is your friend to verify).

This should only respond when BIG-IP is fully up (management ports could be up before the device is able to pass traffic).

A/S

The other option for a A/S (there may be a better way?):

Use the above iRule on a virtual that is not on routable space (255.255.255.254:8888) and assign it to the preferred traffic-group (i.e. traffic-group-1).

Add the following iRule to the IP:PORT that ALB uses:

when CLIENT_ACCEPTED {
    virtual float_is_alive_vs
}

Assuming that the "real" monitor is on a virtual named "float_is_alive_vs" this will only be able to respond to ALB if the device is "active". This is following the behavior that is documented at: https://support.f5.com/csp/article/K10379 where you can use the virtual command to route traffic from one virtual to the another. The first virtual is set for traffic-group-none and will always respond to traffic. The second virtual will only respond to traffic if the device is active for that particular traffic-group.

A potential optimization would be to reference the actual virtual that you want to monitor (you would need to define a separate ALB health probe for each service similar to when you do not use DSR).

I also think that using "traffic-group-none", on the virtual that handles traffic, keeps things flowing a little bit better b/c the BIG-IP will still accept a flow regardless of what the device thinks is the current "active" device (this trick only works in a case like Azure where the BIG-IP is not able to ARP for IPs, this is a bit of a disaster if you try this in a "normal" network b/c both devices would be trying to ARP and you would get IP conflicts).

[mikeshimkus]

Internal issue 1179.

[rftoccijr]

+1 on the DSR. I used this recently for a customer because he was given carved up networks in /28. This limited us to 11 IPs in the subnmet itself (16 addreses minus network and broadcase, minus the top three used by Azure as a gateway and dns).

If I didn't use DSR, then I'd have to spend 2 private IPs in the range (one for each BIG-IP so I can "fail over"), meaning I can only deploy 5 applications. I could port map, but that makes the configuration even more complicated.

This allowed me to use up to 20 public IPs and just push them to the BIG-IP.

[shyawnkarim]

Closing due to age. These legacy templates are now in maintenance mode and are being replaced by our next-generation templates available in the Cloud Templates 2.0 GitHub repo.