Date: Tue, 18 Jun 2002 21:58:10 -0400 From: Mike Tancsa <mike@sentex.net> To: Tom Samplonius <tom@sdf.com> Cc: freebsd-net@FreeBSD.ORG Subject: Re: tracking down strange MTU issues with PPPoE) Message-ID: <5.1.0.14.0.20020618215651.05137298@192.168.0.12> In-Reply-To: <Pine.BSF.4.05.10206181654290.23627-100000@misery.sdf.com> References: <5.1.0.14.0.20020618191155.01c08f18@192.168.0.12>
next in thread | previous in thread | raw e-mail | index | archive | help
Actually, I spoke too soon. The host I was testing against was the wrong
one :( Its still broken with the
set mtu max 1452
statement.
---Mike
At 05:16 PM 6/18/2002 -0700, Tom Samplonius wrote:
> Possibly. There is a PPPoE session to the Redback (or ERX), then
>usually a L2TP session to the ISP. A PPPoE client connecting to the
>Redback (or ERX) should be told a valid MTU. PPP tunel to L2TP tunnel
>raises some interesting possiblities. I wonder how much mucking about the
>SMS does to the protocol. Obviously it is doing something, since the
>Redback works, but the ERX does not. Or the Bell network is broken :)
>
>
>Tom
>
>
>On Tue, 18 Jun 2002, Mike Tancsa wrote:
>
> >
> > Hi,
> > In terms of the MTU, I can set that in my router as I am the ISP
> > :-) Not sure how it works with Telus on the west coast, but with Bell,
> > PPPoE is done between the client and the DSL concentrator. Then the
> session
> > is handed off to the ISP via an L2TP tunnel. I can control that part
> on my
> > router (a cisco)
> >
> > e.g.
> >
> > vpdn-group 72
> > description info describing the particular DSL concentrator - redback
> or ERX
> > accept-dialin
> > protocol any
> > virtual-template 3
> > terminate-from hostname our-l2tp-tunnel-endpoint
> > local name my-local-auth-name-to-the-telco
> > lcp renegotiation always
> > l2tp tunnel password the-big-pass-to-that-concentrator
> > source-ip 1.2.3.4
> > !
> >
> > Then with the virt-template, I can control what the other end
> negotiates as
> > the MTU size. In the past, 1492 and all was happy on the planet.
> >
> >
> > interface Virtual-Template3
> > description ERX-Only-Virtual-Template
> > mtu 1492
> > ip unnumbered Loopback0
> > peer default ip address pool -our-pool-names
> > ppp authentication pap chap callin
> > !
> >
> >
> > I have tried adjusting the MTU to various sizes but with no luck. In case
> > someone reading this has been down the same boat, yes, I do clear vpdn
> lt2p
> > tun our-l2tp-tunnel-endpoint and then connect again with the client...
> > ifconfig tun0 on the client side does indeed show the MTU specified in the
> > virt-template.
> >
> > ---Mike
> >
> > At 03:09 PM 6/18/2002 -0700, Tom Samplonius wrote:
> >
> > > Well, if you need to find the MTU, the ppp logs should tell you
> what the
> > >remote end is telling you to use.
> > >
> > > Usually, if you are having a MTU problem, it relates to fragmentation,
> > >MTU detection and ICMP filters. FreeBSD uses MTU detection by default.
> > >However, MTU detection requires that ICMP "can't fragment" messages be
> > >received, and some broken sites filter all ICMP. I know that the Redback
> > >has an "ignore don't fragment" feature. If this is enabled, it will
> > >fragment packets, it would normally throw away. This feature will break
> > >MTU detection too, but at least the end user won't notice, and packets
> > >will flow.
> > >
> > >
> > >Tom
> > >
> > >
> > >On Tue, 18 Jun 2002, Mike Tancsa wrote:
> > >
> > > >
> > > > The DSL whole supplier we use (Bell Canada) has been turfing their
> Redback
> > > > SMSes and moving to an ERX from unisphere networks.
> > > >
> > > > With the Redback, all was great... I had a FreeBSD box acting as a NAT
> > > > gateway for a number of Windows boxes and all was great. Then, the
> > > > customer got moved over to one of these ERXes and there is now some
> > > strange
> > > > MTU problem. Couple of things. Supposedly the default MTU on the
> ERX is
> > > > 1472 (or 1452) depending on who you talk to and not 1492.
> > > >
> > > > e.g. when doing a fetch to
> > > > >> lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in
> /usr/ports/distfiles/.
> > > > >> Attempting to fetch from http://lynx.isc.org/current/.
> > > > Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C
> > > > 16682 bytes transferred in 89.5 seconds (186.41 Bps)
> > > > fetch: transfer interrupted
> > > >
> > > > Notice the speed... Its totally brutal. yet, a transfer from just a few
> > > > hops away is fine.
> > > >
> > > > My question is, how can I track this problem down ? There seems to be
> > > some
> > > > strange interaction with FreeBSD because if I put a Windows box on the
> > > > other end, it does not suffer from this same problem. I can easily
> repeat
> > > > the problem, but the question is, how can I track down the issue
> and then
> > > > explain it to my telco.
> > > >
> > > > (Note, I have tried various MTU and MRU settings.
> > > >
> > > > Thanks for any pointers.
> > > >
> > > > 4.6-STABLE FreeBSD 4.6-STABLE #0: Tue Jun 18
> > > >
> > > >
> > > > default:
> > > > set log Phase Chat LCP IPCP CCP tun command
> > > > ident user-ppp VERSION (built COMPILATIONDATE)
> > > >
> > > > # Ensure that "device" references the correct serial port
> > > > # for your modem. (cuaa0 = COM1, cuaa1 = COM2)
> > > > #
> > > > set device /dev/cuaa1
> > > >
> > > > set speed 115200
> > > > set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \
> > > > \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT"
> > > > set timeout 180 # 3 minute idle timer (the
> > > default)
> > > > enable dns # request DNS info (for
> > > resolv.conf)
> > > >
> > > >
> > > > pppoe:
> > > > set device PPPoE:fxp1
> > > > #set mtu 1452
> > > > #set mru 1452
> > > > set speed sync
> > > > enable lqr
> > > > set lqrperiod 5
> > > > set cd 5
> > > > set dial
> > > > set login
> > > > set timeout 0
> > > > disable deflate pred1 mppe
> > > > deny deflate pred1 mppe
> > > > set authname user@example.com
> > > > set authkey thepassword
> > > > set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
> > > > add default HISADDR
> > > >
> > > >
> > > >
> > > > ---Mike
> > > > --------------------------------------------------------------------
> > > > Mike Tancsa, tel +1 519
> 651 3400
> > > > Sentex Communications, mike@sentex.net
> > > > Providing Internet since 1994 www.sentex.net
> > > > Cambridge, Ontario Canada www.sentex.net/mike
> > > >
> > > >
> > > > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > > > with "unsubscribe freebsd-isp" in the body of the message
> > > >
> > > >
> >
> > --------------------------------------------------------------------
> > Mike Tancsa, tel +1 519 651 3400
> > Sentex Communications, mike@sentex.net
> > Providing Internet since 1994 www.sentex.net
> > Cambridge, Ontario Canada www.sentex.net/mike
> >
> >
> >
--------------------------------------------------------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike@sentex.net
Providing Internet since 1994 www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.1.0.14.0.20020618215651.05137298>