F5 troubleshooting using tcp dump utility

hello everyone my name is Vernon in this video we are going to discuss about f5 ldm packet capture we will be discussing about TCP handshake wyshak capture and capture using TCP dump utility in f5 for our practical purpose we will be using one arm load balancer topology where we have a client with IP address 192 168 30 1.1 which will be accessing the virtual server IP address that is 192 168 30 1.10 what the request will be back in servers that are 192 168 31.5 and 192 168 31.6 and before sending the request to the backend server bigeye we will do the source net as well as the destination that it will be changing the source IP from 192 168 31.1 to the internal self IP of internal interface that is 192 168 31.3 and will be changing the destination IP from 192 168 31 10.10 to any of the back-end web server IP before we proceed further let us discuss about TCP handshake as the TCP is a connection-oriented protocol so before sending any traffic client and server or two machines which wants to transfer the packets using a TCP protocol first create a session after which they start forwarding the traffic in case of load balancer there are two TCP sessions which are stablished one between client and big IP that is the f5 load balancer and the other one is between the load balancer and this server so first the client will establish a TCP connection with these with the load balancer then load balancer will establish a TCP connection with this server in order to establish a connection first sends a sin message to the big-ip requesting to make a connection big-ip respond by its own send message and the acknowledgement then client acknowledged acknowledges the response from the big IP and the TCP connection is established after which the break IP establish another connection with the backend servers using the same mechanism so this is a server that is 192 168 31.5 we will be first doing the abaya capture we have the wyshak installed in this server so this is the web server 192 168 could be 1.5 we have we are going to start the capture on the interface so and this is the big IP load balancer and we have the virtual server configured here so this is the virtual server which we will be accessing 192 168 30 1.10 [Music] the self IP which are configured in this load balancer is 192 168 31.3 for the internal interface so when the traffic will be coming on the virtual server 192 168 30 1.10 to this elf IP internal self IP any destination will be changed to the backend server okay now we are going to do the packet capture on the Wireshark so here we received all the packets so what we can do we can put a filter on TCP port 80 okay so this is the society which is a client IP and this is the load balancer IP so as you discussed with load balancer we have two TCP session one between the client and the load balancer and other one with between the load balancer and the server so this one is the connection between client and the load balancer whereas once this connection is established there is one more connection that is this one this is 192 168 31 about 3 is the self IP of the internal interface and this is the IP of the back-end server 192 168 31.5 so this is the second TCP connection so first there was a connection initiated from 192 168 31.5 the words 192 168 31.10.2011 0 87 and the destination port is 80 so first the source sent a single message to the load balancer asking to establish a connection load balancer then replied back with a syn ACK with the acknowledgement of this same sent by the client and its own sin and that goes from 84 2 5 1 0 87 then the client in the end sent the acknowledgement to complete the connection after which there is one more connection formed between the load balancer and the server so load balancer IP 31.3 so 31.3 send us into 31.5 asking to establish a connection 31.5 send us a neck and then 31.3 sent the X so here the connection was established so let's first study the traffic flow in between declined and dick load balancer so we will put our filter in order to put a filter in by a shaft for any address you can use IP a double dia it's for a full IP of the line and we need a we need the traffic between the client and the load balancer so we will put another IP of load balancer here so this is the complete traffic flow between the load balancer and the client so first as we discuss Lane send us in message of the sequence zero then the load balancer Sanderson act with the sequence zero in acknowledgment one and so what happens with TCP before or like before getting an acknowledgment for any tiny traffic sent the the the at the end device will not send the traffic at the further traffic until it receives an acknowledgment for its first traffic so when the client send us in then server send us in ACK then the client then the client again saying to act after which the actual traffic communication started so after after each traffic there is an acknowledgment from from other side then 31.1 sent a get request to 31.73 1.10 acknowledges it and then 31.1 against an get traffic and then again 30 1.10 with or without acknowledgement the earth being work there will be no more traffic flow so in order to you know in order to avoid any kind of you know traffic message these these TCP uses sequence number so with each traffic it's a it's a sickness number and for first first send message the sequence number was 0 for second when the server sent like load balancer sent to the client again this sin is zero sequence is zero in a kiss 1 this acknowledgment means that the receipt that the over here that the client were a client expect the next packet next sequence from the so if the load balancer expect next sequence from the client should be 1 so whatever is there in the acknowledgment should be there in the next packet received from thee from the receiver so in this case when when the load balancer 192 168 31.10.2012 330 1.1 with acknowledgment one expect 192 168 31.1 to send the next packet with this sequence of 1 so the next packet between between 192 168 31.1 and 31.8 NS and if we check this packet the sequence number is 1 so in order to you know avoid any any traffic any packet miss or if it uses the sequence numbers of whatever the acknowledgement is sent from from you know from one end to another end the the sending end expect the other end to send this same sequence number for example over here 192 168 31.1 sent a secure acknowledgment of 1 to 192 168 31.10.2012 state 31.10.2011 should have a sequence of 1 so we are checking it for the connection which is established using the source port 5 1 0 87 so the next packet from [Music] so yeah it was this one so when the 31.1 sent a sequence acknowledgment of 1 to 192 168 31.10.2011 so this is the one here when this when the load balancer applied back to this to the client it uses the sequence number 1 now it has it has also sent a acknowledgement of 390 means whenever now whenever 192 168 31.1 was sent next packet to 192 168 31.77948 for 1 over 5 1 0 87 to 80 being sequence number will be 390 this one so this is the next packet from 5 1 0 87 280 like from 192 168 31.1 to 192 168 31.10.2012 connection was established the client sent the get request to the load balancer then the load balancer acknowledges the gadget or the get request and so this this see we have two communication here one from this source 192 168 31.1 using the source port 5 1 0 7 other one is using the source port 5 1 0 8 6 so first we are tracking 5 1 0 h7 so once the load balancer acknowledges the get request from 31.1 then the load balancer replies replies back with the with the with the back page over here now once once the back page is displayed then four four five one zero h7 the basic the client acknowledges that it acknowledges the back page and then client closes the connections of in order to close this session client first sender Finnick to the to the load balancer with a sequence 390 an acknowledgement of 1383 so next packet which is coming from the load balancer that is 192 168 31.10.2012 830 1.1 for source code 5 1 0 8 7 and destination port 80 or or the source port 80 and the destination port 5 1 0 h7 should be 1383 here at SC the sequence number is always similar to the last packet acknowledgement number this is how you can track whether there is any miss of the packet or not now the load balancer acknowledges the session closer and it also sent of Finnick to close the session and the client acknowledges it this is how the session is closed similarly there is there is a session between load balancer and the server as well so in order to check it the load balancer itself is 192 168 31.3 and the backend server IP is 192 168 21.5 so once once the session was established between the load balancer and the client load balancer initiated our session with the back-end server using a syn message so first load balancer initiated a syn message towards the backend server and the source port is 4 1 4 8 9 and the and the destination port is 80 with the sequence of 0 then the the back-end server replied back to the load balancer with a cynic and it has sent a sequence of 0 and acknowledgement of 1 means in the next packet which will be coming from 31.3 towards 31.5 will be of sequence number one then 31.3 close 31.3 acknowledges the acknowledges the Cenac from 31.5 and set the sequence of 1 which is equal to the acknowledgment of the last packet and it sets the acknowledgement of 1 now when 192 168 31.5 will send a packet to 31.3 it will again send a set of sequence of one which is this one so 192 168 31.3 sent our HTTP GET request which it received from the client to the back-end server and if you checked the sequence number it is 1 here which was which was same as the acknowledgement of the last packet then fixed back-end server acknowledges the request acknowledges the request and say and give and said send the acknowledgement of 319 means the next traffic which will be coming from 192 168 31.3 2 verse 30 1.5 will have the sequence of 390 which is this one so when 31.3 divided by 230 1.5 it it will it uses the sequence number of 390 and in the end it this close it closes the connection this is how you can analyze the packet capture using the Wireshark now we will see how we can do the same capture using the TC from participative utility in big IP so in order to use the TCP dump utility you have to go to a SSS session and the command is TCP dump and in order to check all the parameters you can use the CB de - help demand these all parameters can be used while running the TCP dump in while learning the TCP dump in big IP so mine so the main parameters which are uses TCP dump - I using TCP dump - I you can define any interface or a villain for which you want to take the capture so in our case as we are taking the capture on the internal interface which is 1.1 so we will use 1.1 here or if you if you are using some other interface you can use that interface let's say 1.2 so we are using 1 not worth so I put I'll put 1.1 here then you can put a filter for particular host or a port or a combination of end quote let's say if I want to put a filter for host that F or client for our client 82 168 31.1 and for the destination of load balancer I can use this command once I run it it brother you should use end in between here it will give all the traffic which is flowing between 192 168 RT but 1.4 which is the client IP and within the load balancer so if I initiate the connection again if we should be traffic here so this is the traffic flow this is same as what we have seen in Wireshark first 31 not burn initiated oh yeah so first 31.1 send us in message 220 1.10 30 1.10 this is these are the flag as means sin as dot means act dot his act and then the client replied with an acknowledgment this is act then the client sent a gat request that is a push request with push and I push act flag with the push at flag then the load balance are applied with the acknowledgement of receiving that request then declined again sent uh this this is from be another port so client sender is send another send request from port 5.30 for previous was from five one three zero five so you can similarly as we analyze the traffic in the by shot we can you we can use TCP dump utility to analyze you traffic there are other option as well for now we have used this host even if you want for any particular port we can use end a step or port number as well and put it t over here it only gives the traffic for that port 80 only so if I initiate a traffic the pain to me so we again got the request so we can also use the poor parameter also if you want if you want to use any other interface as 1.2 I have external interface 1.2 I can use 1.2 here though I have no traffic there so it will not show anything now the other options are if you want a PCP dump to be captured in a txt file then you can use the same command and you can use two arrows and just rightly fine name for example if I want to capture the traffic of this in the text file then I will just write this now whatever the traffic will be flowing will be captured in this test file so now all the traffic will be captured in a test file in order to stop the capture you can use control-c so it has captured 14 packets and it is same it is saved in the same directory where you have when this command in order to check that file you can use dir command so here we have the file and in order to open it you can use cat command so it will show all the traffic which has been captured and in order to remove the file you can use RM command so by this way you captured the the dump in our in a text file if you want to do it in a you know you know enough you know in a packet capture file which you can analyze using any packet capture tool then you can use - W command with the file name once you run this command it will come it will create it up capture file which can be analyzed by a capturing tool like by Asha so and this is the way to capture the these are the different way to capture the traffic using TCP dump utility and it gives same output as we have analyzed in the Bioshock I hope this video is helpful for you if you have any queries please post it in the comment section thank you you

Channel: Varun Agrawal

Views: 4,918

Keywords: packet capture, wireshark packet capture, f5 tcp dump, how to take packet capture in f5, analyzing wireshark, tcp three way handshake, one arm load balancer, F5 troublehooting, F5 tutorial, F5 training, tcpdump, big ip tcpdump, tcp dump, F5 LTM TROUBLESHOOTING, F5 troubleshooting, ltm troubleshooting

Id: DG2y4ub3gTs

Length: 23min 39sec (1419 seconds)

Published: Sun Apr 26 2020