Forum Discussion
What_Lies_Bene1
Cirrostratus
CirrostratusTCP Traffic Path Diagram
Hi all,
It's bugged me ever since I looked at the ADF exam blueprint that there still wasn't a definitive document or diagram available that described or showed the TCP Traffic Path and Order of Operations of a packet passing through an F5. I'm aware of the BigIP Path Graph v1.7 from Red Education but that's five years old and hasn't been subject to any review. To that end I've recently started my own as you can see below.
Comments and more importantly corrections or queries are encouraged. Note as it stands I've not added many iRule events as I'd like to get the flow and order sorted first. I'm pretty sure what I've done is mostly correct but I'd love some review before I continue and finish off the server side operations. Many thanks in advance. You may need to right-click, open image/in new tab to see it full size.
New version - December 2015:
jsprattlerNimbostratus
Awesome, thank you for putting in the time on this!
What_Lies_Bene1@Aurel, you should be able to see the new version (the second diagram). Note this diagram relates to a standard VS (mainly). The flow/logical steps would be slightly different for a forwarding VS As @Andrew has already noted, if there's no connection table entry and Loose Initiation isn't enabled on a FastL4/Performance, the packet gets dropped. If you're talking about a Forwarding(IP) VS then I'd imagine there is no connection table lookup. I'll double-check and confirm.
andrew_C1@Aurel , F5 is a statefull default deny box, you have an entry in the conn table for every flow(pair). If you want to use your F5 like a router then you have to make your device as close to a router as possible. Routers dont act on flows they just do Destination lookups. Now back to the default deny bit, if you dont have a flow and your not a syn frame then by default your in the bit bucket to get around this there is the "loose initiation" : which as quoting f5 : "The Loose Initiation option allows the BIG-IP to initialize a connection when any TCP packet is received, rather than requiring a SYN packet for connection initiation." As far as i know from a conn table perspective there is no discrimination between a forward or a standard etc VIP they are all just mappings of translations (inside local, inside global, outside local, outside global)
marta_atance_11Hi, This is a great and very complete diagram. But I have a doubt: When a packet is processed it is first checked if an existing connection in Connection table exists, isn´t it? And it would be great if you could add the Self IPs also to you diagram and the end of it that would be the DROP.
- What_Lies_Bene1Hey Marta. My understanding is that the packet filtering comes first. It's not an F5 document but see here: https://devcentral.f5.com/d/big-ip-v9-flow-path. However, I have seen documentation (not official) stating it's the way round that you suggest. Not sure how to confirm? I think this confusion is due to the 'Filter established connections' option for a packet filter. I shall investigate further. OK, this seems to confirm what you have asserted Marta: https://support.f5.com/kb/en-us/solutions/public/12000/800/sol12831.html. I'll update the diagram shortly. DONE. Let me know if I've missed anything else?
- marta_atance_11Hi, thank you for replying :) When a packet is process on the BIG-IP, the secuence is: 1) Check connections in Connection Table 2) Packet Filter 3) Virtual server (following order on SOL14800) -> If VS with SNAT (process stops here). Otherwise it goes to Global SNAT. 4) SNAT 5) NAT 6) SELFIP 7) DROP So, in your diagram the "packet filter" is process ahead the "Connection table" (what will only happen with AFM in Firewall mode)... Maybe that´s what you want to show with your diagram.. Is it?
- What_Lies_Bene1Thanks @Marta. I've shown the connection table check (for non-SYN packets). Unless a connection has shut down uncleanly I believe this is the expected behaviour. Note this is for a standard VS. I'm not entirely clear where SNAT/NAT is concerned, I'll look it up and get back to you. I'm not clear where you'd like me to add the Self IPs - could you elaborate please?
AurelCirrus
@ What Lies Beneath : Hi What, thanks for replying. Well, everything not terminating on the BigIP could be existing as a previous SYN has been seen, but not in the BigIP connection table. I'm interested on the new version you're talking about, could you tell something ? Thanks.- Aurel@ andrew : Hi Andrew, i don't get everything you said. But i got that there's is a first "table" for SYN packets not terminating on the BigIP. Forwarding VS is a case where TCP connections are not terminating here. Could you just explain " You don't want those to be denied" ? Thank you for your reply.
- What_Lies_Bene1Hey ~jsprattler, the general order doesn't change: VS, then SNAT, then NAT. The preference when different types of VS's could match is the most specific match based on this (now added to the diagram anyway): - IP Address:Service Port - IP Address:* - IP Network:Service Port - IP Network:* - *:Service Port - *:*
- jsprattlerCould you please tell me where a Network Forwarding Virtual Server (NFVS) would fit in this diagram? I'm particularly wondering the order of precedence for: NFVS, VS, SNAT
- What_Lies_Bene1Hey @Aurel. You have a point. There are a few possibilities, one, it's a FastL4/Performance VS with Loose options enabled or two, a timeout of some sort has occurred. I'm just working on a new version so I'll think this through some more.
- andrew_C1Aurel, to answer, with routing. If the F5 is in path in a multipath environment and a failure on another path occours you can have traffic that matches a forwarding VIP that is mid flow appear and you dont want those flows to be denied.