[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2370
  • Last Modified:

TCP SEGMENT OR A REASSEMBLED PDU

I am currently having a intermittent problem with communication between two Servers.

When the data flow is sniffed using Ethereal the primary message displayed though-out the sniff is
"TCP SEGMENT OR A REASSEMBLED PDU"


What would cause this frequent info response from Ethereal?  Also, any documentation on the subject may be helpful.
0
sectel
Asked:
sectel
  • 5
  • 4
1 Solution
 
harbor235Commented:

Must be some fragmentation going on, do you have all standard MTUs set in the path or have you lowered them for any reason? IPSEC, GRE, ....

harbor235 ;}
0
 
sectelAuthor Commented:
Correct on both fronts,

We are running GRE and IPSEC.

On the network side that i administer, the fronting router has this command " IP tcp mss adust 1300" coded on the LAN facing interface to ensure fragmentation does not occur from traffic originating from our Servers.   I do not believe it is being implemented on the other end.
I think they are simply using the command " ip mtu 1300" on the fronting router interface and relying on
PMTUD to do the work.



0
 
harbor235Commented:

wow thats pretty low, you are pretty much going to fragment just about all large packets since the ip mtu 1300 is in the path. Setting the tcp mss to 1300 allows for a larger overall packet size,
but it is really negligable. I am sure you are experiencing performance issues.

I would something larger like 1460, assuming there is no other additional encapsulation going on.
Typically TCP mss is 40 bytes smaller than ip mtu because of headders.

harbor235 ;}

harbor235 ;}
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
sectelAuthor Commented:
Don't think the MTU is the problem, the " IP TCP MSS ADJUST" should force the servers to never transmit anything over 1300 bytes hence fragmentation should not occur on the one side.

Since they are relying on PMTUD to ensue non fragmentation it may be an issue on the other side of the network.

These networks are very proprietary in the way traffic is delivered.  They first enter a GRE tunnel and are later encrypted over an IPSEC link.

j
0
 
harbor235Commented:
tcp mss and mtu go hand in hand, also a flow is birectional so it does not really matter that the initial path
forces the servers to lower the mtu. in the end its the return path that is killing you. Fragmentation is not happening at the server on the other side.

What is the source of the fragment?

I stated that you should try higher values, of course i meant end to end, if you are saying you only control the one side then request that they configure the same as you. Unfortunatley your are impacting performance either on the server or the network.


harbor235 ;}


0
 
sectelAuthor Commented:
The " TCP SEGMENT OR A REASSEMBLED PDU" message,

At what layer is this message referring to?    Is this message referring to LAYER 3 ( reconstructing an IP Packet) or Layer 4 (reconstructing a TCP segment)?

J.
0
 
harbor235Commented:

My fault, i believe you are on the correct path. I did not look at the message close enough and assumed IP fragmentation issues.

Your message is informational, it means that a higher layer protocol needed multiple tcp segmets to construct the PDU, agin this is informational only.

check it out;

http://www.wireshark.org/lists/wireshark-users/200806/msg00047.html

harbor235 ;}
0
 
sectelAuthor Commented:
Thanks

Good article,

I have noticed that the TCP window size varies between the two Servers.  On the one end the window is constant at 501 while on the end of the circuit the window is 1687/

Do you see any issues with this.

Windowing is a weak area with me...can you recommend any good articles.

thanks
0
 
harbor235Commented:

Newer systems should support auto scaling which negoitates the largest possible window for given circumstances, latency, packet loss , etc ... There is no doubt that large window sizes are essential for high perfromance transfers. I am curious concerning the type of OS you are running, Windows, *NIX ?

Unelss there are issues on your network your systems potentially could negoitate up to a 128kb window size, sometimes the window is hard set causing issues and there can also be problems with some older routers rewriting the tcp options field.

http://lwn.net/Articles/92727/
http://www.speedguide.net/read_articles.php?id=2574
http://www.psc.edu/networking/projects/tcptune/OStune/winxp/winxp_stepbystep.html
http://www.psc.edu/networking/projects/tcptune/

Also, TCP/IP Illustrated version 1 is a great book, i am not sure if there is an update or not, you may be able to review the book on Safari.

harbor235 ;}

0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now