Lightboard Lessons: BIG-IP Life of a Packet

Hi @Lucien...it is possible to reuse a self-ip on a virtual, so that implies that the virtual server lookups have to occur first. The object precedence is:

1. Virtual Server (and all the specific precedences here, see K14800 below)
2. NAT
3. SNAT
4. Self-IP

You can piece that together in these support articles on AskF5

• K10388
• K9038
• K14800

Great. Makes sense now. Thanks for sharing the references. And so, since these are listening objects, decision is made at the "Listener Lookup" phase (in your chart above).

Really nice video! In the HUD chain, if you run all of the modules on the same BIG-IP, in which order will they handle the traffic? Is it the same as in the drawing? Because I'm pretty sure that when you are running APM and ASM, you cannot protect an APM webtop with ASM when they are provisioned on the same box because APM triggers before ASM. Please correct me if I'm wrong :)

If you have a listener with multiple modules policies applied, the order of operations is as follows:

Clientside: LTM, AAM, ASM, APM, PROXY

ServerSide: PROXY, LTM, ASM, AAM, APM, LTM

For your particular scenario, APM login triggers before ASM parsing, so the login page is not protected by ASM in a single-VIP deployment, but if you deploy a layered VIP, that's possible as well on a single BIG-IP.

Hey Jason.

A bit beyond the scope of the video but, when using a layered VS for APM, some resources won't work right? Like for instance a Network Access Resources.

Tried setting up a layered VS for this purpose where the resource assignments were Full Webtop, Network Access and some other stuff. Only spent a short period of time on it but never got it to work. Then I stumbled across (if I remember correctly) a devcentral post stating it was not possible (at least for a network access resource). So I dropped it til I had some more time to research it.

Thanks again!

I have a layered VS setup with APM, What network resources do you have that don't work ?

[responding to "epaalx"] As Jason wrote in an earlier comment, the term "HUD" was inspired by the motion picture "The Hudsucker Proxy". The "HUD chain" is essentially a logical stack of filter layers stacked up on either side of the dual-proxy processing paradigm used by the TMM (the Traffic Management Microkernel process). An input packet comes in and goes up the HUD chain on one side (potentially undergoing processing at each layer of the stack), and then from the pinnacle goes down the chain on the other side and then (typically) out to something outside BIG-IP.