Re: Problem with large pings with don't fragment set

From: Clifford Kite (kite_at_see.signature.id)
Date: 06/10/04

  • Next message: Michael Heiming: "Re: With iptables, why do we need other firewall software"
    Date: Thu, 10 Jun 2004 11:45:15 -0500
    
    

    Pete <pacalvert@qinetiq.com> wrote:

    > I have been having a problem when experimenting with sending large
    > pings with the DF bit set over a GRE tunnel.

    > I can send pings with a size of upto about 1450 over the tunnel, but
    > when they get any larger then I have problems. I send the packet and

    The ping message header is 8 bytes, so the size of data in the message
    is limited to 1472, assuming an Ethernet interface to the Internet with
    an MTU of 1500. I don't know about GRE tunnels but they very likely add
    more overhead.

    > I get the ICMP reply about not being able to send the send the packet
    > as it is too large and needs fragmenting. However I then try and send
    > a smaller packet and I still get the same reply, but now it is saying
    > the MTU on the tunnel interface is 552. This means that while I

    The size is limited by both the Ethernet and GRE interface MTUs.
    It sounds to me like the first time it's the Ethernet interface MTU
    that causes the PMTU Discovery reply and the second time it's the
    GRE interface MTU.

    > should be able to send packets which are say 1000 bytes I can't until
    > this problem times out after a few minutes.

    I can't parse this.

    > I suspect the problem is related to how PMTU discovery works. But I
    > can't work out if it supposed to work like this or there is some sort
    > of a bug. It seems strange that the MTU size would drop just because
    > one larger packet was sent.

    If the smaller message (1000 octets) passed through the Internet Ethernet
    interface and afterwards encountered the GRE interface with the 552 MTU
    then that should explain it.

    > I am doing the ping with the following: ping -s 1480 -M do w.x.y.z,
    > then I change the packet size to 1000 and it still doesn't work, until
    > this timeout happens. The inferrence from the PMTU discovery RFC is
    > that the maximum value to use is 576, so this is why I suspect this
    > could be the problem, but it seems to be a strange way of handling
    > this situation. I can't take the PMTU discovery off the tunnel as I

    Read section 7.1 of RFC 1191.

    > am tunnelling OSPF through the tunnel and need the ttl to be larger
    > otherwise the TTL is exceeded and changing the TTL is incompatable
    > with nopmtudisc for some reason.

    > Has anyone had this sort of problem before, and do they know a
    > workaround to either reduce the timeout or elimate it totally, as it
    > is causing problems with my experiments waiting for this timeout.

    The maximum ICMP echo-request data size you will be able to send through
    the GRE tunnel without fragmenting is 552 - 28 = 524 octets.

    Setting the MTU for the Ethernet interface of the host originating
    the ping echo-requests to 552 should cause large echo-requests to be
    broken into packets of this size before going out that interface.
    This repacketization doesn't involve PMTU Discovery, but likely does
    mean that PMTU Discovery is then unnecessary.

    I'm *not* an expert on networking protocols, so beware.

    -- 
    Clifford Kite                Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads:                      http://ckite.no-ip.net/
    

  • Next message: Michael Heiming: "Re: With iptables, why do we need other firewall software"

    Relevant Pages

    • Re: VRFs & GRE
      ... I now have a situation where I have to use a GRE tunnel across a carrier ... When a VRF is configured, is the VRF / RD value physically 'tagged' to a ... VRF is a routing instance why was it needed on the interface? ...
      (comp.dcom.sys.cisco)
    • Re: FRS Only replicates on inbound connection, no changes go out.
      ... Mike Drechsler - SPAM PROTECTED EMAIL ... protocol can go higher than this on a physical interface that supports larger packet sizes such as gigabit ethernet. ... Ethernet has just become so common that you might assume that 1500 is somehow tied to basic TCP/IP specifications. ... LDAP will work just fine with MTU values lower than 1500 unless you are thinking about the problem experienced with Windows 2003 sp1 or the MS05-019 patch resolved in a hotfix referred to in KB article 898060? ...
      (microsoft.public.windows.server.active_directory)
    • Re: Panic in 6.2-PRERELEASE with bge on amd64
      ... interface is enough to completely panic the driver and then the kernel, ... I added some sysctls and found it annoying to have to do down/up ... Similarly for the mtu ioctl. ... As this was connected to a gigE switch with mtu left at 1500 I supposed ...
      (freebsd-stable)
    • Re: 6.2 mtu now limits size of incomming packet
      ... Incoming interface must have mtu set to the same mtu as all other hosts on the same L2 network. ... Thus the router can accept the incoming packet but may drop and notify on a frame that is too large to exit the outgoing interface. ...
      (freebsd-net)
    • Re: Dropped packets via ISR
      ... I also used ping plotter... ... Tried changing from full duplex to half duplex to auto and that did ... "1) Interface MTU at 1500 is fine. ...
      (comp.dcom.sys.cisco)