Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

TCP 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.

Image Text

New version - December 2015:

Image Text

12
Rate this Discussion
Comments on this Discussion
Comment made 13-May-2014 by What Lies Beneath 6587
Oh, and for the purposes of simplification at this point, I'm assume a standard VS where relevant.
0
Comment made 23-Oct-2014 by ch4f5 4
This is awesome, thx! It is incredibly helpful to see the visual flow of order of operations on a VS.
0
Comment made 27-Oct-2014 by What Lies Beneath 6587
You're welcome. Always great to get feedback.
1
Comment made 11-Mar-2015 by G. Scott Harris 1503
Excellent diagram! Thank you for taking the time to put this together. I might add one additional entry and that is the virtual server "source" setting which appeared in v11.4? If defined the VS will accept connections from that source address only.
0
Comment made 19-Mar-2015 by What Lies Beneath 6587
Thanks G. Scott, I'll sort this out shortly. Update: Finally added November 2015.
0
Comment made 04-Nov-2015 by Aurel 170
Just great.
0
Comment made 04-Nov-2015 by Aurel 170
I'm wondering how a connection can be an existing one ( New TCP Connection SYN => NO) and also not in the Connection Table Entry (Connection Table Entry =>NO). Or does it mean that this is checked twice ?
0
Comment made 11-Nov-2015 by andrew 176
Aurel, 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.
0
Comment made 23-Nov-2015 by What Lies Beneath 6587
Hey @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.
0
Comment made 24-Nov-2015 by jsprattler 123
Could 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
0
Comment made 25-Nov-2015 by What Lies Beneath 6587
Hey ~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 - *:*
0
Comment made 25-Nov-2015 by Aurel 170
@ 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.
0
Comment made 25-Nov-2015 by Aurel 170
@ 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.
0
Comment made 29-Nov-2015 by andrew 176
@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)
0
Comment made 01-Dec-2015 by What Lies Beneath 6587
@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.
0
Comment made 25-Oct-2016 by Luis Araujo 179

It´s greate! Well done.

0
Comment made 3 months ago by SAM 482

Helpfull :)

0

Replies to this Discussion

placeholder+image

thanks for the diagram. this is exactly what I was looking for.

0
Comments on this Reply
Comment made 21-May-2014 by What Lies Beneath 6587
You're welcome. It's still a work in progress but I'm pretty sure it's accurate.
0
placeholder+image

I have a question specifically regarding after a decision has been made to send a packet to be snatted or routed. If I leave the SNAT setting on my VIP as auto-map I know that the routing and forwarding from there on uses the self-IP of the vlan that is used in the static route. If I have a SNAT Pool implemented is there a decision that is made before the traffic is sent to the routing table? I am new to SNAT Pools. any help you can provide is greatly appreciated.

0
placeholder+image

I don't think there is any difference where routing is concerned. Routing is concerned with the destination, not the source so any changes in the source have no affect. Hope that helps, if not, please do post back.

0
placeholder+image

Nice diagram, would it be possible to add the tcp profile client-side and server-side to the diagram please.

0
Comments on this Reply
Comment made 19-Mar-2015 by What Lies Beneath 6587
Hey again @Graham, I've now incorporated that with mention of where each profile is applied. There's no documentation on which event the commands are valid in but I'm pretty sure it's CLIENT_ACCEPTED, do tell me if I'm wrong.
0
placeholder+image

You are more than welcome and thanks for the flow diagrams, the main driver behind the question is that F5 exposed some tcp profile parameters via iRule in v11.6.

0
placeholder+image

Hi, 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.

0
Comments on this Reply
Comment made 01-Dec-2015 by What Lies Beneath 6587
Thanks @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?
0
Comment made 01-Dec-2015 by marta.atance 1
Hi, 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?
0
Comment made 01-Dec-2015 by What Lies Beneath 6587
Hey 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?
0
placeholder+image

Awesome, thank you for putting in the time on this!

0
Comments on this Reply
Comment made 03-Dec-2015 by What Lies Beneath 6587
Thanks! You're welcome.
0
placeholder+image

Excellent Diagram!! Just an extra kicker here, Jason Rahm(F5 solution architect) has a video on their Whiteboard Wednesday show. Heres the link. He covers this in "Life of a Packet" https://www.youtube.com/watch?v=bYfcNIndSPQ

0
Comments on this Reply
Comment made 03-Dec-2015 by What Lies Beneath 6587
Thanks, I'll check it out. Cheers
0
placeholder+image

Wow great. Two remarks though:

  1. Actually, I think in order to be 100% precise at the point where the matching VS is selected, you ought to move the "source permitted" question into the blue box that depicts the selection of the VS, right?

  2. Receiving non-SYN packets for a connection which is not included in the connection table does not necessarily lead to the packet being dropped. There might be a fastL4 or TCP profile with loose initiation in place. But I also understand that reflecting all such possibilities in one diagram might be impossible...

0
Comments on this Reply
Comment made 04-Dec-2015 by What Lies Beneath 6587
Thanks. 1. Here I would wonder whether 'enabled on VLAN' and 'Source Permitted' are actually a part of the selection process? I'd imagine enabled on VLAN is. But, if a VS matches but the source is not permitted, is the next closest VS selected? Something I'd like to test I think. Anyway, in either case, you are probably correct that one or both should be incorporated into the VS selection criterea - will sort once I know more about the source option. 2. It might not actually be too hard, I'll see what I can do. The diagram as it stands does 'say' Standard VS but I think it would help to add that if nothing else.
0
Comment made 04-Dec-2015 by Ed Summers 1066
According to SOL14800 the source is part of the match criteria. I would assume if the source did not match, selection would continue. [https://support.f5.com/kb/en-us/solutions/public/14000/800/sol14800.html?sr=49862858] A test would be interesting nonetheless. I generally like to 'see' it work if possible.
0
Comment made 07-Dec-2015 by What Lies Beneath 6587
Updated the diagram accordingly. No time for testing unfortunately but the logic seems sound. Cheers
0
Comment made 07-Dec-2015 by tatmotiv 918
Cool, thanks! Actually, the source IP check MUST be part of the matching VS evaluation process, because otherwise it would not be possible to have two virtuals with the same destination IP and port definition, enabled on the same VLAN(s) that only differ concerning their source IP(s). "if a VS matches but the source is not permitted, is the next closest VS selected?" Absolutely, yes.
0
Comment made 11-Dec-2015 by What Lies Beneath 6587
Good point. Thanks
0
placeholder+image

Hello Steven

First of all many thanks for this diagram which helps me a lot.

I just want to unsure that I got it right, in the new version diagram :

After the CLIENT_ACCEPTED Irule event and if there's no virtual server matching, we should also have the "Most specific match enabled on ingress" vertical box between the SNAT box and the NAT box, right?

I mean if we only have two object configured on the bigip :

One SNAT that listents for traffics comming from 10.0.0.0/8

One NAT that listents for traffics comming from 10.0.0.1/32

if the client 10.0.0.1 comes, then the NAT will precede the SNAT, right ?

Regards,

Karim

0
placeholder+image

Hi all Diagram is great , but can someone tell me when traffic is going to vip 443 with SSL offload and irule ... 1 it will hit vip than 2 cert will go first or irule ?

0
Comments on this Reply
Comment made 29-Jan-2017 by boneyard 5084

you mean if it will hit the irule before or after the SSL offloading? it doesn't work like that, there will be EVENTs within the irule hit before the SSL offloading, i.e. TCP events and ones after, like HTTP events.

0
Comment made 29-Jan-2017 by slesh 200

yes i mean that . i wanted to know for example like traffic will come to vip it will process all things and what is first what is second will it go for cert first and irule later or ...

0
Comment made 30-Jan-2017 by boneyard 5084

like i said: it doesn't work like that, there will be iRule EVENTs within the iRule hit before the SSL offloading, i.e. TCP events and ones after, like HTTP events.

the image at the start of this question does exaxtly details which iRule EVENTs happen when.

0
placeholder+image

Has anyone seen this Diagram for 13 code yet?

0
Comments on this Reply
Comment made 4 months ago by boneyard 5084

do you have a reason to assume it isn't valid for version 13.x? in principle not much changes, if you have some specific point please mention it.

0
Comment made 4 months ago by Darrell Paul 1

Engineers looking at our issue have been leaning towards new security features in the 13 code that may be triggered along the path across the path. e.g. you have the ddos notes along this flow. I 'assume' there are newer things in the flow that the F5 Engineers were referring to.

0
placeholder+image

Hello,

I just wanted to say that the FLOW_INIT is triggered after packet filter. It was well represented in version 0.1 however in version 0.5 the "Packet filter on VLAN" was moved down below "AFM/TMM Processing begins" .

Could you please explain why you made such a modification ?

0
Comments on this Reply
Comment made 3 months ago by boneyard 5084

are you really sure Karim? logically i would say that FLOW_INIT doesnt trigger if a packet filter already has blocked the connection to start with.

this is where What Lies Beneath determined the situation i believe: https://devcentral.f5.com/questions/the-flow_init-event-and-event-order

if i test this and block traffic with a packet filter i don't get a FLOW_INIT event, if i remove the packet filter i get it, tells me the diagram is ok.

0
Comment made 3 months ago by Karim.Benyelloul 124

boneyard, We are saying the same thing: If the packet filter blocks the packet we'll not get the flow init event.

However, the diagram v0.5, the flow_init box is represented before the packet filter box. Which seems to say that whether we're blocked or not by packet filter we always get the flow init event (which I think is incorrect)

You can see that in v0.1 of the diagram, the flow_init box was set after the packet filter box, which make more sens for me.

Thanks,

0
Comment made 3 months ago by boneyard 5084

ah now i see it, i didn't notice the two pictures. well we touched the question a few times, perhaps Steven will pop up and explain :)

0