dpeng at cisco
Dec 9, 2004, 5:07 PM
Post #5 of 5
(360 views)
Permalink
|
Dennis Peng [dpeng [at] cisco] wrote:
> Clayton Zekelman [clayton [at] mnsi] wrote:
> >
> >
> > It may have indirectly been MTU issues.
> >
> > Somewhere along the way, IOS started treating the RADIUS Framed-Compression=Van-Jacobsen-TCP-IP attribute differently.
> >
> > Users who had that attribute set in the RADIUS users file were failing. Everyone without it (our DEFAULT entry) was fine. It was one of those things we always set during the dialup days, and it never appeared to cause a problem on DSL until we went to 12.3(11)T.
>
> For the archives, this problem exists in 12.3(7)T or later. I've
> opened up a bug on this, CSCsa49007. The release note says:
Sorry, this should have said CSCsa47008.
Dennis
> In IOS releases 12.3(7)T or later, if the command <CmdBold>ip tcp
> header-compression<NoCmdBold> is configured on VPDN virtual-access
> interfaces, TCP traffic will fail to pass. The command may also be
> enabled via the RADIUS Framed-Compression attribute. VJ header
> compression does not have to be negotiated successfully for TCP
> traffic to be affected, it just needs to be configured. The workaround
> is to either remove the <CmdBold>ip tcp header-compression<NoCmdBold>
> command, filter the Framed-Compression attribute using the RADIUS
> Attribute Filtering feature in IOS, or remove the attribute from the
> user's RADIUS profile.
>
> If you have RADIUS profiles with the Framed-Compression set to VJ
> header compression, or would like to use VJ header compression on your
> LNS (eg you are aggregating modem links), please open up a TAC case
> and request that they link the case to this bug. I'd greatly appreciate
> your support in documenting your requests/needs.
>
> > I suspect that somehow when the TCP/IP header was decompressed with VJ, it grew larger and broke things due to the PPPoE packet size limitations.
> >
> > Either way:
> > 12.3(9) - VJ "on" causes no problems.
> > 12.3(11)T - VJ "on" breaks things.
> >
> > I'd rather avoid using ip tcp adjust-mss. From what I remember in earlier releases, it blocked creation of Virtual-Access Subinterfaces, and caused some performance hits. I don't know if this is still true. Since my L2TP tunnels come in on an ATM interface, I don't hit the maximum L2TP packet size over Ethernet issue.
>
> TCP adjust-mss is sub-interface capable in 12.3(3) and later
> (CSCea31101). However, anyone using the command on the sub-interface
> should make sure they have the fix for CSCee75569, in 12.3(10) or
> later. Otherwise you will only see TCP adjust-mss sporadically working
> which will cause performance problems.
>
> Dennis
>
> > I opened a TAC case, but the front line guy is still stuck on having me make sure I have "enable vpdn" turned on (despite the fact that the syntax is "vpdn enable" - which of course I must have on to even be able to encounter this problem...<sigh>).
> >
> > I'll send him what I found in the morning.
> >
> >
> > ----- Original Message ---------------
> >
> > Subject: RE: [cisco-bba] LNS issues on a 7301
> > From: "Arie Vayner" <ariev [at] netvision>
> > Date: Fri, 3 Dec 2004 10:17:00 +0200
> > To: "Clayton Zekelman" <clayton [at] MNSi>,
> > <cisco-bba [at] puck>
> >
> > >You may be hitting some MTU issues?
> > >Try using tcp mss-adjust
> > >
> > >Arie
> > >
> > >-----Original Message-----
> > >From: cisco-bba-bounces [at] puck
> > >[mailto:cisco-bba-bounces [at] puck] On Behalf Of Clayton Zekelman
> > >Sent: Thursday, December 02, 2004 5:19 PM
> > >To: cisco-bba [at] puck
> > >Subject: [cisco-bba] LNS issues on a 7301
> > >
> > >
> > >
> > >We just purchased a new 7301 running 12.3(11)T as an LNS.
> > >
> > >Customers are coming in via L2TP tunnels from a Juniper ERX-1400 on an
> > >ATM OC3c interface.
> > >
> > >We just cut over from a 6400 NRP-1 running 12.2(15)T1, and now some
> > >customers who terminate in PTA's are having connectivity issues. These
> > >customers were also working fine on a 6400 NRP-1 running 12.3(9) a few
> > >weeks back.
> > >
> > >Currently, it looks as if the customers we tunnel THROUGH the 7301 work
> > >just fine. Customers terminating are reporting various issues.
> > >Interesting to note that we can ping most of the users from outside our
> > >network just fine. The ones we can't ping I suspect have ping responses
> > >turned off on their CPE routers.
> > >
> > >As a quick fix, I'm tunneling the users through to another LNS. Any
> > >suggestions?
> > >
> > >Here's our Virtual Template:
> > >
> > >interface Virtual-Template1
> > > mtu 1492
> > > ip unnumbered GigabitEthernet0/0
> > > no logging event link-status
> > > load-interval 30
> > > peer default ip address pool dynamic1
> > > ppp authentication pap ppp_local
> > > ppp authorization ppp_local
> > > ppp ipcp dns 216.8.137.204 216.8.137.203
> > >
> > >
> > >
> > >---
> > >Clayton Zekelman
> > >Managed Network Systems Inc. (MNSi)
> > >344-300 Tecumseh Rd. E.
> > >Windsor, Ontario
> > >N8X 5E8
> > >
> > >tel. 519-985-8410
> > >fax. 519-258-3009
> > >
> > >_______________________________________________
> > >cisco-bba mailing list
> > >cisco-bba [at] puck
> > >https://puck.nether.net/mailman/listinfo/cisco-bba
> > >
> > >
> > >
> >
> > _______________________________________________
> > cisco-bba mailing list
> > cisco-bba [at] puck
> > https://puck.nether.net/mailman/listinfo/cisco-bba
|
