<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: <cipe-l,AT,inka,DOT,de>
Subject: RE: CIPE 1.5.4 / NAT / iptables issue
From: "Mark Smith" <mark.smith,AT,avcosystems,DOT,co,DOT,uk>
Date: Fri, 11 Jul 2003 18:01:48 +0100
Importance: Normal
In-reply-to: <16142.55310.676075.458946@saint.heaven.net>

That bit I understand, and the version of iptables I'm using lets me modify
the real MSS:

iptables -A FORWARD -i eth0 -o cipcb0 -p tcp -m tcp --tcp-flags SYN,RST
SYN -j TCPMSS --clamp-mss-to-pmtu

However, this obviously will only work when it is Linux on the end of the
tunnel.  I have the same problem with a Win32 client.  What I'm after is why
PMTUD isn't working when it should be.  I'd rather fix that than fudge the
MSS, as above.

--
Mark Smith - Avco Systems Ltd
email: mark.smith,AT,avcosystems,DOT,co,DOT,uk
Tel: +44 (0)1784 430996 Fax: +44 (0)1784 431078

> -----Original Message-----
> From: owner-cipe-l,AT,inka,DOT,de [mailto:owner-cipe-l,AT,inka,DOT,de 
> Behalf Of
> Dick St.Peters
> Sent: 11 July 2003 16:30
> To: Mark Smith
> Cc: cipe-l,AT,inka,DOT,de
> Subject: RE: CIPE 1.5.4 / NAT / iptables issue
>
>
> Mark Smith writes:
> > I run NAT over CIPE 1.5.4 on 2.4.18 without any apparent
> problem apart from
> > large packets and PMTUD.  I'm still hoping that the person
> that suggested
> > using iptables to clamp mss to pmtu can provide more
> information either
> > where they found that out, or if they know, why it works and what it
> > changes.
>
> I don't think I'm the person who suggested that, but I can
> provide some explanation.  At the beginning of a TCP
> session, each end tells the other the largest packet size it
> can send or receive.  To see what this implies, it helps to
> consider network diagrams, beginning with a trivial one, two
> hosts A and B directly connected by a network link:
>         A <-link-> B
> Both A and B know the largest packet the link will carry
> because they are connected to it.  This is true even if the
> link is a virtual link, such as a CIPE tunnel.
>
> Now advance to a more complex diagram:
>         A <-link 1-> X <-link 2-> Y <-link 3-> B
> If link 2 is a virtual link, its maximum packet size will be
> reduced by the tunnel overhead and will be smaller than for
> links 1 and 3.  Normally neither A nor B will know that.  A
> will only know the largest packet link 1 can carry.  B will
> only know the largest packet link 3 can carry.
>
> However, A and B have to learn about link 2's smaller
> maximum size to talk efficiently.  One way for A to learn
> the link 2 size is for the owner/user of A to clamp A's
> maximum packet size to the maximum size for link 2.  Then
> when A tells B the maximum size A can send/receive, it will
> give the clamped size, not the link 1 maximum size.
>
> There's no way to clamp the size with iptables that I know
> of, but you can do it with the Linux route command.
> However, there's an error in the implementation: the "mss"
> route parameter actually sets the MTU, not the MSS.
> Clamping the real MSS to the path MTU would be wrong, but
> clamping what the route command calls mss to the path MTU is
> correct.
>
> (MTU is the maximum packet size, MSS is the maximum TCP
> payload size - i.e., MTU minus TCP/IP overhead.)
>
> --
> Dick St.Peters, stpeters,AT,NetHeaven,DOT,com
>
> --
> Message sent by the cipe-l,AT,inka,DOT,de mailing list.
> Unsubscribe: mail majordomo,AT,inka,DOT,de, "unsubscribe cipe-l" in body
> Other commands available with "help" in body to the same address.
> CIPE info and list archive:
> <URL:http://sites.inka.de/~bigred/devel/cipe.html>
>


<< | Thread Index | >> ]    [ << | Date Index | >> ]