How TCP RETRANSMISSIONS Work // Analyzing Packet Loss

[@predatorishi]

I’m a senior TAC engineer at Cisco and currently mentoring new hires in my team , I have shared your channel for them to brush up their wireshark skills and I must say that my students are super impressed with you Chris, Great Job!! these videos are gold .

[@ChrisGreer]

Thank you! By chance are you at Cisco live? Let’s meet up!

[@benedictjojo5761]

Cisco TAC Engineer here as well and damn this guy is really good!

[@krishnaSagar69]

I'm working as a Palo Alto TAC and we all watch your videos all the time. Literally everyone. It's a basic necessity

[@ChrisGreer]

@@krishnaSagar69 that is awesome! Let’s do an in-person training for you guys 😉

[@tonioyendis4464]

Learning layer 4 (transport-layer) is crucial to troubleshooting network/application issues! Most app and most server teams don't understand the importance of TCP- tuning; they have little clue about window-scaling/sizing, SACK-tuning or how much retrans is too much. The BDP calculator is your friend as a network-analyst, most of the issues I discover are usually at layer 4 or below.

[@geneva93]

Thanks!

[@ChrisGreer]

Thank you!

[@nacereddinezekri436]

Thank you Chris, your way of explaining very complexe things in a simple and direct way is very valuable.

[@bellaambiens]

Very interesting video, you’re now in my go to channels list.

[@ChrisGreer]

Thanks for the comment!

[@TheEitler]

way better than the provided lecture notes at university -> best way to learn for the practical exam is to watch your videos! 👍

[@ChrisGreer]

Glad you think so!

[@atzelepis1]

thnk you chris,i am a technical support negineer for several years,feel i am gaining good enough knowledge here

[@ChrisGreer]

Thanks for the comment!

[@IK-iu4rz]

Always facing Retransmission issues, This video is a life save. :)

[@ChrisGreer]

Glad it helped! Thanks for the comment.

[@axelcastrejon6730]

These videos are so good I can't believe they aren't more widely recognised

[@ChrisGreer]

Thank you!

[@RicardoDiaz21129]

Been learning so much from your videos. Thanks you Chris

[@vedsachit604]

One of the best video on explaining the reason for retransmission.. Subscribed your channel.. looking for more videos..on packet analysis

[@kadirrangwala]

Amazing Content ! Please continue to upload such videos regularly. Suggestion for next video: I would like to see PCAP analysis of a voip call with choppy audio/One Way audio.

[@ChrisGreer]

Nice suggestion, thanks!

[@tomschulte3237]

Great Idea. Kinda similar problem. I have a partially (what ever that means) working VoIP-phone behind a second router (USG3 Ubiquiti). The phone works well at the first router (AVM Fritzbox 7940 - a consumer router very popular in the EU in particular in Germany ) which runs the software and my other phones. Even if this is not going to be covered, it would be very interesting to see some VoIP "debugging" in general.

[@raulbalderrama9396]

What a valuable video! I have learned too much from you Chris, thanks a lot!

[@ChrisGreer]

Glad it was helpful! Thanks Raul.

[@aminderpuri9392]

What else is there to say, informative and well presented. Like your videos a lot

[@ChrisGreer]

I appreciate that - Thank you for stopping by the channel!

[@ravishere-mn6no]

Thank you very much for all the knowledge you have been sharing!!!

[@inline-SGT]

Nice post, looking for depth on this topic Chris. Thanks

[@ChrisGreer]

Great Praveen! Great you have to stop by the channel.

[@DanielAlmonte-t3q]

Great video and explanation, thanks

[@wiresharkmania709]

Hello Chris, once again...Thanks ;-)

[@ChrisGreer]

Happy you stopped by and thank you for the comment.

[@mcgirishnetwork]

Thank you for the informative video.

[@ChrisGreer]

Thanks for the comment Girish!

[@andreizoom]

Great video! Thank you!

[@ChrisGreer]

Glad you liked it!

[@maumotec2345]

Always the best. Great content. Thank you for much for it.

[@ChrisGreer]

Glad it helps!

[@malkeetkalera7520]

I always wait for uer new video 👍

[@ChrisGreer]

More to come!

[@socat9311]

Would love to see a video on SIP packet troubleshooting :)

[@ChrisGreer]

Thanks for the idea!

[@adajatobi7866]

Thank you Chris. This really helped me 😁

[@ChrisGreer]

You're very welcome!

[@m.adnankhan8245]

Thanks for making it.

[@EduardKhiaev]

Thank you so much!

[@ChrisGreer]

You're welcome!

[@shivamt157]

Thank you!

[@emirh.9376]

Thanks Chris!

[@ChrisGreer]

You bet!

[@jjames7206]

Great tips Thanks a lot

[@ChrisGreer]

My pleasure!

[@MrSomaaoo]

amazing video , thanks so much

[@ChrisGreer]

Glad you liked it!

[@gofai2003]

Great Chris

[@vedsachit604]

Need more videos on RETRANSMISSION

[@breakingbisley]

Hey Chris, great video. Just a quick confirmation, in the three way handshake, I see the (TX - Sender) has a MSS of 1460 whereas the (RXR - Server) has a MSS of 1440. Could that be a potential problem, or based on the three handshake. Will both parties agree to some diligence in the network like with windowing sizing? Thanks

[@ChrisGreer]

Great question - The easy answer is no. The MSS is not negotiated, so both ends are allowed to support different values. The MSS is an advertisement of the largest segment that the endpoint can receive. In effect, telling the other side not to send anything larger than this length of payload in one segment. After that, TCP leaves it to IP to sort out MTU and fragmentation.

[@davepete9537]

What causes [TCP Retransmission] [TCP Port numbers reused] and how to fix it?

[@haroldcalderon4514]

I'm here because David bom and subscribed 🎉🎉🎉🎉🎉🚀🚀🚀🚀🚀🚀

[@ChrisGreer]

Welcome to the channel!

[@gofai2003]

Chris, how do we analyze or troubleshoot esp/ipsec packet loss in wireshark?

[@ChrisGreer]

Easiest answer? It's complicated. 😄 I rarely get in and try to decrypt it. Mostly I watch for shifts in roundtrip time, throughput, and network indicators of loss (ICMP or other layer 2 protocols). Or... I forget trying to capture the tunnel itself and install Wireshark on one of the endpoints and capture before traffic enters the tunnel. If things look healthy going in and coming out, then I move to the encrypted traffic.

[@gofai2003]

@@ChrisGreer thanks a lot

[@luisfelipeortizmartinez6615]

Hello Chris, Great videos, on a particular case where we have a constant but high latency, is it a good idea to have frto or is a better approach to deactivate the frto at the source. Thanks.

[@krishangopal4156]

U are awesome 🤠

[@ChrisGreer]

Thanks for watching!

[@ranjanadissanayaka5390]

boom ...more knowledge transmitted successfully from server(Chris) to client(me).

[@srinivasann62]

Hi Chris, Great Stuff as always! I've a question. Why is server/receiver trying to send with the default MSS value of 536 when it has already negotiated its MSS value of 1440 during TCP 3-way handshake (SYN-ACK)?

[@ChrisGreer]

That is the "When in doubt" default MSS. So if one side or the other is uncertain of the MSS due to retransmission, or a network-level change of MSS, it will try 536 as a last ditch effort before quitting.

[@inline-SGT]

@Chris, does tcp retransmission change the IP.ID field with each retransmission or it remain same

[@ChrisGreer]

It will change since the retransmission will be encapsulated in a new IP packet.

[@inline-SGT]

@@ChrisGreer ok thanks

[@AbhisekMishra]

Hey can you please explain me that what is "client hello" which is written in 4th line after 3 way handshake.

[@wiresharkmania709]

Hello, it's the first request from the client to the server telling him : " Hey, I want to make a secure (TLSv1.2) communication with you. But unfortunately the server doesn't answer in the Chris example. Take a look at this Wikipedia TLS page : en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake

[@ChrisGreer]

What WiresharkMania said.... Basically it is the first part of the TLS handshake. Now I need to do a series on that, so thanks for the question!

[@tomrt2]

Hi, in an holistic troubleshooting method I would like to get some quick view informations table about the many tcp connections I can capture in my trace files. For each TCP connections I would like to find , the number of packet retransmitions, ther average TCP RTT, the average application RTT, the number of 0 window, and so on. Is there any way to get this in Wireshark ? Or is there any other packet analyser doing this on the market ?

[@scottb4029]

Awesome video and series. Simple and stupid question, what's a MTU ?

[@ChrisGreer]

kzbin.info/www/bejne/jn7GiqqoYt59faM - Here ya go. Here is a video about it.

[@scottb4029]

Thanks Chris, the video was perfect. Funny thing, it was the next video in the series I was watching on your playlist. The TCP series is well done. I would like to see a deep dive into UDP.

[@nicoleanne967]

Hi Chris, I know you are not troubleshooting just for anyone so I would like your input to guide me to resources to help me find out what is wrong with my connections. I don't know what to ask I dont know what to look for so a bit of guidance to the right direction would be a great help. My clients can't seem to connect to a certain website, im sure my firewall does not allow this connection. But my firewall log says it allowing it. I decided to check packet logs and found that my TCP SYN "conversation completeness: incomplete 37". I'm guessing my firewall will not trust that. Of course, without firewall, I tried to access the website which works but I also see my TCP SYN "Conversation completeness: incomplete, DATA (15)". on firewall: TCP sequence is Client SYN (time:1) > TCP Retransmission x 4 > Server ACK (time 16) > Client TCP RST (time 16) Where should I go? What could be causing this?

[@ChrisGreer]

If your conv completeness is that high, sounds like you are getting a reset. Guessing it’s a syn/rst. Look at the TTL of the reset and see if it is coming from a local or nearby device. Check out my video on tshooting resets I walk you though all that.

[@nicoleanne967]

@@ChrisGreer Thank you Chris! will do

[@pranavsingh8503]

All TAC and Escalation engineers watching this video, give a like !

[@DaystarHiker]

If the smallest MSS allowed by TCP is 536. Why is packet 16 314

[@ChrisGreer]

I get why that is confusing! So 536 is the minimum value that the MSS can be. So it is a minimum maximum. Packets can still be smaller than that, but the max needs to be at least 536.

[@mahavirsinghrajpurohit8004]

Video 3

[@zelekewbake7652]

Cool

[@tomschulte3237]

Always the same problem - having 2 thumbs but only 1 thumb up allowed to give! So please feel it doubled

[@ChrisGreer]

Thanks for the comment!

[@zsahe21]

!!!

[@troysipple2591]

Very good information

[@ChrisGreer]

Thanks