Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Jun 2002 19:17:43 -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.20020618191155.01c08f18@192.168.0.12>
In-Reply-To: <Pine.BSF.4.05.10206181454460.23627-100000@misery.sdf.com>
References:  <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca>

next in thread | previous in thread | raw e-mail | index | archive | help

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


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.20020618191155.01c08f18>