TCP Duplicate Acks Explained // How to Troubleshoot Them

duplicate acknowledgements i've got hundreds of them chris my network's falling apart hey you don't have to go far in a trace file to find a few duplicate acknowledgements it's good i understand that we see them all the time but how do we interpret them and what do we do about them stick around all right so in this video we're going to be taking another deep dive into tcp and we're going to be taking a look at duplicate acknowledgments hey it's something you're going to see don't have to look far to find them now i'm going to go ahead and use the trace file that is in the link down below if you went ahead and watched the retransmission video or the sequence analysis video this is exactly the same trace file we're just building on these topics to get a deeper understanding of how tcp works so you might want to go check out those videos first before we dig into this one but let's go ahead and get into the video alright so duplicating acknowledgements what does that mean well kind of like the name implies right duplicate ack but it's very specific in why wireshark flags it that way so let's go ahead and take a look at one in this trace file so here we've got our cincinnati act we've got our handshake we've got our client hello we've got some re-transmissions we've already talked about this so far in this trace file but what i'm going to do is come down here to our dupe act okay so i see that one and i also see a few more down here dupac 2 do pack 3 but what do these mean and what do i do all right so basically the reason why they're called duplicate acknowledgements is because if i come over here to my act number you notice the act number in this direction so this is the client acting data that came in so the client is saying okay 1609 i'm good to that sequence number but if we look up above i already saw 1609 up here so we've already seen an acknowledgement for 1609 come from the client to the server acting that data but the thing is the reason why this is flagged as a duplicate acknowledgement is because you see the sequence numbers 215 that means that i've sent 215 bytes to the server this happened previous it happened up at the client hello and so that data was acknowledged all right so i don't have to retransmit it but i'm up to 215 in my sequence numbers if i come down here in the dupac my sequence number is the same it's 215. so you're going to see a dupac when your sequence number has not advanced or you're not sending data this is just an empty packet okay so you're not advancing data in the opposite direction but this acknowledgement is repeated you're saying it again so by definition it is a duplicate acknowledgement but here's the deal there's a lot of times when you see duke acts what we got to do the important part isn't in the actual act number or in the actual upper part of the tcpa header itself what i'm going to be interested in doing in dupac's is i want to come down here to options and when i'm dealing with a station that is sac capable selective acknowledgement able then i'm going to see a sac block down here a lot of times now we're going to take a look at selective acknowledgement in a deep level in another video however what we want to really understand about duplicate acknowledgements is oftentimes they're carrying a sac block and this is where i'm going to focus my attention when i'm doing my analysis so let's go ahead and take a look at another dupac in our trace file so if i come down here to this next one this is dupac number two here i see the same act number same sequence number do back number three say max number same sequence number but if we look down at the sac blocks see those have grown a little bit again don't worry too much about that right now just know that if i see any more acts coming from the client that are not moving that act number forward as long as i get stuck on 1609 then i'm going to see dupac's so what if you have a trace file where you have hundreds of dupaks does that mean the sky is falling and everything is falling apart well no not really slow down a minute basically that means in most cases that you just have a lot of latency between the client and the server between those two tcp stacks that are exchanging data that just means you have a lot of time or maybe you could think of it this way imagine that i sent you a hundred packets all right and i just popped them off just one two three four five six seven eight nine ten all the way up to packet number one hundred but the network dropped packet number two let's say you got one and then three four five six seven all the way up to one hundred okay there's gonna be a gap in the sequence numbers so what you're going to do on your side is you're going to say okay chris i'm good to 1 and then you jump the sequence number right so so you never got packet 2 this these sequence numbers that are within packet 2. i'm just going to make it easy in column packets but anyway you didn't get the data in packet 2 so what you're going to start doing is acting for the data in packet 3 packet 4 packet 5 packet 6. so all of those acknowledgements following our point of loss packet 2 all of the acknowledgements for that subsequent data is going to look like a dupe back that's how wireshark is going to flag it so after that point of loss you're literally for every single other packet once tcp realizes that there's loss it goes into its lost recovery so every packet gets act you're going to send me an ack for every single packet all the way up to packet 100. so on my end i'm going to see 97 dupacs come flying in but all of them are going to be telling me about that loss in packet number two now why are they dupaks because in every single one of those acknowledgments the act number here in the tcp header this act number is not going to be advancing it's going to be stuck on packet number one you're gonna tell me okay i got packet number one and packet three i got packet number one three and four i got packet number one three four five packet number one right so you're gonna be telling me about the successful receipt of all those sequence numbers but what wireshark is going to do is label them as dukebacks so here's our take away point if you see a dukeback don't sweat too much it just means that there was some data loss and tcp is trying to recover it a dupac literally means that this is the same sequence number that's not being advanced so we're not sending any data in this packet and the acknowledgement number is exactly the same that's when wireshark will flag it as a dupac so when are dupe acts a big deal when should we be worried when we see dupacs well basically do backs are indicating that we have packet loss so if we're on our network and this is a system that we completely control from one endpoint to another endpoint or maybe it's a local server and you have your local clients this means if you see a lot of dupacs or they're happening almost like a cycle you're seeing them and you're seeing them and then they clear out then you see them again those indicate that you're getting packet loss on your network so this is something we might want to go investigate take a look at our switches take a look at our routers for any kind of indicators any kind of discards any kind of fcs issues layer two problems and that can help us to troubleshoot re-transmissions and dukebacks that go along with them all right so i hope this video was helpful for you please comment down below let me know what you thought also let me know what else you would like to see when we're doing our tcp deep dive soon we're going to be talking about selective acknowledgement so go ahead and wait for that video it's coming soon and i'll see you on that video take care [Music] you

Channel: Chris Greer

Views: 31,636

Keywords: intro to wireshark, wireshark, tcp/ip analysis, introduction to wireshark, chris greer, free wireshark training, getting started with wireshark, wireshark for beginners, wireshark tutorial, wireshark tutorial 2021, wireshark training, tcp/ip, tcp vs udp, how tcp works, ccna tcp, network+ tcp, tcp, wireshark case study, packet analysis, tcp acks, tcp acknowledgements, tcp SACK explained, tcp duplicate ack

Id: Hq-nOMEPh4U

Length: 7min 33sec (453 seconds)

Published: Wed Jan 12 2022