Network Diagnosis

hi,
in order to understand the concept of duplicate acknowledge or DUPACK, you need to know what is FRR or Fast Retransmit & Recovery :
In TCP/IP, fast retransmit and recovery (FRR) is a congestion control algorithm that makes it possible to quickly recover lost data packets. Without FRR, the TCP uses a timer that requires a retransmission timeout if a packet is lost. No new or duplicate packets can be sent during the timeout period. With FRR, if a receiver receives a data segment that is out of order, it immediately sends a duplicate acknowledgement to the sender. If the sender receives three duplicate acknowledgements, it assumes that the data segment indicated by the acknowledgements is lost and immediately retransmits the lost segment.
hence the TCP DUPACK are packets send and received on either ends to minimize time lost in retransmission while waiting for clock timeouts, and bring about a preemptive removal of delays in the network traffic.

i know all the rfc's can be very boring, but if you really want to know about something inherent to a protocol, its a must that you go through some of them.
the best way to deal with a "dry" rfc is to go through slowly, and read the complex and confusing part over and over again to make sure you have made yourself clear on the topic. there is not shortcut way of cracking the mystery behind rfc's apart from reading it and understanding it.
the best place for searching RFC's is:
www.ietf.org/rfc

Hi Arani,

Thanks very much for the post, i must admit it didn't make a lot of sense to me so guess what, yup, off to the TCP rfc for me :lol:

The only thing that i can say is, on this packet capture, i did not notice any Out-of-Order packets although there were some retransmission packets. Another thing was that the Dup ACK appear to be 10/11 at a time.

Anyhow, i will let ya know how far i get with the rfc, and once again thanks very much for the replies, your a star, just hope i have some knowledge i can share to the group

Well, opened a TAC case on this issue and they have stopped now over Design concerns with my current network infrastructure.

My account manager is on holiday so will pick this up with him because i have just been through the config and there are definately no loops in the design (they have spotted two ports going into the same switch, only thing is that the switch they go into are VLAN'd because it goes over a Trunk to another building over a 100Mb LEZ where it then goes into two different switches).

Will keep everyone informed on what was causing all this.

So, i have got a response from TAC on this issue. Apparently the problem is with the way i did the SPAN on the switch. I have SPAN'd the whole VLAN to watch the traffic that is going on and this has caused my issue.

Apparently, because the SPAN is showing the Send/Receive we are seeing traffic being sent from the source and then we are seeing the same duplicate traffic received at the destination. This still doesn't explain the duplicate ACK (around 60 of them) which they will now start to look at for me.

One of the things that I've noticed about the Cisco switches that I use is that if I mirror a port and tell it to mirror both transmit and receive traffic, I will get duplicate traffic because all the traffic that is received on the terface is mirrored as well as the transmit traffic, so in essence you are making a copy of the same packet twice. Now some network sniffers are smart enough to know the differenced based on the TCP sequence number but some just reports them as being duplicate packets, etc... you might want to try that before you go any further with this because I don't believe you are experience any congestion on a 22 Gbs backplane.