Multiple "Outside" interfaces and routing lookups

Doesn't sound like an optimal design but regardless, the Auto Last Hop feature will save you here but not if your firewalls are clustered and use VRRP things get a bit sticky.

You can find more information on ALH here: http://support.f5.com/kb/en-us/solutions/public/13000/800/sol13876.html.

From a design POV, could you not route the traffic from the additional f/w through the existing one perhaps? No idea of your set-up and even that doesn't sound great I guess. My worry is one day someone will disable ALH and things will go very wrong.

What Lies Beneath,

Thanks for your answer. As if you couldn't tell my LTM knowledge is limited to VIP's and Pools. I never heard of Auto Last Hop but that does sound like something I'll need if we move to multiple interfaces on the outside (more to come on this).

In a question surrounding design I'll put this past you for your input if you have time. Ultimately here are the requirements.

• We have two VIP subnets (say 10.10.10.0/24 and 10.20.20.0/24).
• There are multiple pools underneath which aren't at issue.
• We would like to keep all VIP addresses the same to ease the switch to a new site.

Additional Questions: Can the LTM have one outside netblock (say 10.30.30.0/24) with the current VIP's still on 10.0.10.0/10.20.20.0 (as long as a FW or router can route the 10.10.10.0 and 10.20.20.0 traffic to the LTM 10.30.30.0 address?

If it doesn't need to have an interface per VIP subnet that makes for a much easier transition.

Regards, Ken

You'll be glad to know the Virtual Server subnets do not have to exist anywhere, everything just works as long as you route the VS subnets to the F5 outside interface from your firewall. I'll upload a diagram demonstrating this shortly.

Makes perfect sense. Thanks for shedding light on this. I was tied to thinking the VIP's were required to have a physical interface which complicated everything. The information you provided is much appreciated!

Maybe one more question to solidfy my thinking on this.

It appears the LTM is basically a router under the covers. When it receives a packet it will check the destination and if it is a VIP will perform its magic, tie it to a node eventually and then look in the routing table for destination interface on where to send it. If it receives a packet from a node it will look to see how to un-do the connection (Node for VIP address) and once again look into it's route table to decide how to forward the packet. Basically as long as the route table on the LTM has the correct paths to the destination networks the LTM could care less from what interface the packet arrived on (of course without some of the other tweaks that could be made like ALH). Ultimately the routing table decides the destination interface and nothing else.

Is this a correct way of thinking?

I'm afraid not. Think of it more like a stateful firewall (unless you implement VS's to mimic stateless routing). The only difference is that the return traffic path ignores the routing table and uses ALH instead. ALH will return the traffic to the L2 MAC address it originally received it from rather than consult the routing table. You can of course change this behaviour.

OK I'll try this again to get my thinking in order.

First off there is no designation for "outside" or "inside" networks from what I can tell.

When a packet comes into the LTM destined for a VIP address the LTM creates a state entry which includes keeping track of the interface and MAC that the packet came in on. The LTM will then load balance or perform other functionality and send the packet on. When the return packet comes back the LTM associates this with the previously created state entry, rebuilds the packet for the VIP address and sends it to the interface and MAC it stored in the state entry. For any stateful connection the route table is not consulted to determine which interface to send the packet through. The destination will always be which interface and MAC sent the initial packet to the LTM.

Got it now?

Correct. You can of course change this behaviour but ideally you wouldn't.

You can have a look at your connection table:

tmsh show sys conn all-properties

As W.L.B. already pointed out, beside the tuple and timeouts also the last hop information (MAC address) is stored, the ingress VLAN and even the egress VLAN (not on display unfortunately).

Using virtual address space (both for VIPs and SNATs / NATs) to be reached via floating self IPs is a common concept in F5 deployments. And yes, 1st time it sounds strange to everyone who is familiar with typical router / firewall deployments. 🙂

PS: Things become complicated in active / active deployments (multiple traffic groups).

W.L.B / Stephan,

Thank you very much for these detailed responses.  Much Appreciated! 

Ken