What Do These Ethereal TCP Message Mean

[808.mark.lee]

Hi all:

I had posted a bit earlier about some frame errors that I was seeing on my 7204 router. Whenever a machine tries to download a file from a remote site, I get a lot of the following errors:

TCP Previous Segment Lost

TCP Dup Ack

TCP Retransmission

I have attached my ethereal capture.

My Fluke shows about 10% jabber errors when a large file transfer occurs.

We are doing per packet load balancing over two T1s to the remote site. In my earlier post, it was suggested to change to per destination. Do you think that will solve this problem?

It was also suggested to change the MSS size on my fast ethernet connection with the following entry:

ip tcp adjust-mss 1350

Will this help to alleviate the problem I am experiencing?

Any other input would be appreciated. I'm meeting with our providers and want to be prepared to address this situation.

Thanks for your help.

Mark Lee

Network Administrator

Young Brothers

[Georg Pauwen]

Hello Mark Lee,

adjusting the MSS would definitely be worth a try. Here is what happens when you change the MSS (this is actually an excerpt ffrom a previous post by Rick Burts, very very useful):

When end stations establish a TCP session they negotiate an MTU that is related to the MSS (maximum segment size). Normally that negotiation establishes an MTU that matches the interface. However if there is something in the path of the connection with a smaller MTU, this may introduce the need to fragment. But the TCP packets may have the Dont Fragment bit set. If DF is set and the packet needs fragmentation, then the packet must be discarded. The ´ip tcp adjust-mss´ command tells the router that as it sees the packets go by that negotiate the TCP session to re-write the mss in the packet to a smaller size. The end station now negotiates a max size that will not require fragmentation.

HTH,

GP

[Richard Burts]

Georg

Thanks for the kind words and the quote from a previous discussion. I agree that it is worth trying to adjust the mss but I feel that changing from per packet to per destination load balancing is even more likely to improve this situation. When you do per packet load balancing you increase the likelihood of out of order packets. And the error messages referred to in the original post sound to me to possibly indicate out of order packets at least as much as packets dropped because of segment size.

Of course Mark Lee could make both changes and see if one is more effective than the other.

HTH

Rick

[Georg Pauwen]

Rick,

I hope you don´t mind being quoted. Your posts are absolutely more than helpful, and full of interesting stuff.

Then again, by law, as far as I remember, it is allowed to quote an author, as long as you name the source...;)

Regards,

GP

[Richard Burts]

Georg

I absolutely enjoy being quoted. I take it as a compliment that things I have contributed are good enough that you remember and mark them and quote them. So feel free to quote me as often as you find appropriate.

HTH

Rick

[mheusinger]

Hello everyone,

sorry not to cite anyone ;-)

Well what I can see is a maximum frame size of 1314 Bytes in the trace. This does not correspond to the router configuration given.

So my question is: what is causing the MTU in the path of the TCP session? I can not see that the router config posted would result in that.

So what is missing in the picture?

My impression is, that there are other active components (routers, tunnels, etc.) in the path, which are more likely to be the cause of the problem.

Could you please shed some light on the end to end topology between the two hosts 192.168.50.121 and 192.168.1.245? What could have a MTU of 1314 bytes?

As a sidenote: adjusting mss to 1350 will not add anything new to this picture as the original frames seem to have a mss of 1260 already.

Hope this helps

Martin

P.S.: on a second thought: a cisco VPN client will set the MTU on a PC to 1300 byte per default, which could explain the MTU of 1314 on the ethernet monitored. Is there a VPN tunnel involved in transmission? If so the (lousy) internet connection of this client could explain the poor performance.

EDIT:

Jabber - Term used with Ethernet to describe the act of continuously sending data. A jabbering station is one whose circuitry or logic has failed, and which has locked up a network channel with its incessant transmission.

I have overlooked that you mentioned your jabber errors. You also could have a faulty NIC. OR you can have a duplex mismatch at one of the ethernet interfaces involved.

Could you please set the duplex and speed settings on the router to fixed values and check, whether this solves the problem (f.e. duplex full, speed 100)?

Hope this helps! Please rate all posts

[808.mark.lee]

Thank you all for the information. I appreaciate all your help and input. To clafify my setup. We have a 7204 router in our main office here. We are connected by two T1 lines to a co-location site where our some of our servers are held. The ip address of 1.245 is on our local network and the 5.121 is a file server in the co-location site. I do not know what type of router is at the co-location site nor do I know how its configured. It is managed by the vendor for the co-lo services. I need to get as much information as I can so that when we meet with them to discuss these issues I can bring up these points with them.

As for the Jabber errors, this is what a Fluke LanMeter reports the errors as. I have the Fluke on a Span switch port picking up all the traffic from the Fast Ethernet port. It has been averaging 10% errors over an extended period of time. I'm just guessing from my ethereal output that these are the tcp errors. Is this a wrong assumption. I did try another fast ethernet module but had the same problem. When we talk to the vendor I will see if we can fix the duplex and port speed on each router.

Thanks again for all your input, I really appreciate it.

Mark