Re: Path MTU Problem

Hash: SHA1

_lion_2000@xxxxxxx <_lion_2000@xxxxxxx> wrote:

Hi, i have a FreeBSD 6.3, fresh install. It is in the corporate
network and i can't use any tcp network service on that machine from
any other, which is behind cisco routers with tunnels.

This is a classic PMTU Discovery problem.

Well, not all services, but some, when large packets are sent from
that box. After some investigation i found, what router sends ICMP
Frag packets to that box, but it doesn't reduce packets size and keep
sending large packets:

Is it possible that you have PF or IPFW filter rules in place that drop
ICMP? Just because tcpdump shows you the frame arrived at your system,
does not mean that it was "seen" by the kernel.

here comes icmp frag packets. strange what sometimes tcpdump complains about
tcp header in icmp packet and sometimes not

The reason for this complaint is that frag_needed packets return a
portion of the original IP frame back to the sender, but the number of
bytes is not sufficient to see the entire TCP header. However, there is
enough to see the src/dest IP's and src/dest port numbers, as tcpdump
shows you. But tcpdump cannot decode past the end of the returned
frame, so it shows an error.

- --
David DeSimone == Network Admin == fox@xxxxxxxxx
"This email message is intended for the use of the person to whom
it has been sent, and may contain information that is confidential
or legally protected. If you are not the intended recipient or have
received this message in error, you are not authorized to copy, dis-
tribute, or otherwise use this message or its attachments. Please
notify the sender immediately by return e-mail and permanently delete
this message and any attachments. Verio, Inc. makes no warranty that
this email is error or virus free. Thank you." --Lawyer Bot 6000
Version: GnuPG v1.4.1 (GNU/Linux)

freebsd-net@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: UPD better than TCP in streaming video/audio ?
    ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
  • Re: Simulating smaller MTU? ie sending small packets.
    ... This is due to the fact that TCP ... If you want smaller packets, ... >> set there as the MSS is announced by the receiver during the ... Yes, per connection. ...
  • Re: NTP and Firewall help needed.
    ... >port 123 for udp and tcp. ... Also the idea of combining rules for packets arriving at the local machine ... ACCEPT any and all traffic coming from the localhost interface ...
  • Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues
    ... I'll be able to run some more basic tests tomorrow to see some results, but want to wrap my head around what's actually logically meant to be happening based on adjustments, etc. [I suspect this'll do nothing for the UDP issue, but at least I might be able to pipe some TCP traffic] ... Little packets with ip lengths of 28-29 bytes seem to do the most damage. ... UDP floods are much better handled - an ipfw block rule for the packet type and the machine responds as if there were no flood at all (until total bandwidth saturation or PPS limits of the hardware, which in this case was around 950Mbps). ...
  • tcp hostcache and ip fastforward for review
    ... this patch contains three things (to be separated for committing): ... - removes ip route cache in ip_input.c (locking much easier) ... - removes most (tcp specific) metrics from rtentry metrics ... - fixes wrong goto in tcp_input.c which sends two RST packets ...