[c-nsp] Problem mith MLPPPoE after provider switches from J to C ...

[Djerk Geurts]

Have you looked at the MLP buffers? Packet reordering is costly for MLP
processing at either end an increased jitter could cause this. The result
will be backet loss due to the MLP buffers overflowing or timeing out
(excuse the ill use of terms but I hope you get the point) and dropping all
fragments. MLP fragments packets by default across all links...

> ip load-sharing per-packet
Has no influence over MLP and only makes sense when doing equal cost routing
across L3 links..

-- 
Djerk
www.djerk.nl 

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Garry
> Sent: donderdag 22 februari 2007 7:57
> To: cisco-nsp
> Subject: [c-nsp] Problem mith MLPPPoE after provider switches 
> from J to C ...
> 
> OK, here's the background ...
> 
> We have multiple customers set up to use multilink PPP on *DSL lines.
> The DSL lines themselves come from German Telekom, which forwards
> connections via L2TP to another provider, which in turn 
> forwards them to
> us, again via L2TP. Our LAC does IP provisioning, including IP
> addresses, VRF etc.
> 
> On two sites that had been using a multilink connection with 2 and 3
> SDSL lines for over a year, multilink stopped working when Telecom did
> some announced maintenance work. Going back to just a single line
> (doesn't matter which of the 2/3 lines, as long as it's only 
> one) works
> fine, though of course losing the bandwidth isn't an option.
> 
> Now, after investigating (and kicking their @** for messing around) I
> was told yesterday that during the maintenance window, the customer
> lines for both sites had been switched over from a Juniper 
> box to Cisco.
> 
> Our setup is probably as basic as it gets, LAC looks 
> something like this:
> 
> vpdn-group 1
>  description Template fuer T-DSL-Sessions
>  accept-dialin
>   protocol l2tp
>   virtual-template 1
>  terminate-from hostname dslhandover
>  lcp renegotiation always
>  l2tp tunnel password xxx
>  l2tp tunnel timeout no-session 30
> 
> interface Virtual-Template1
>  description Template fuer T-DSL-Sessions
>  mtu 1492
>  ip unnumbered FastEthernet0/0.99
>  ip route-cache flow
>  ip tcp adjust-mss 1416
>  peer default ip address pool dsl-pool
>  keepalive 60
>  down-when-looped
>  ppp authentication chap pap callin
>  ppp multilink
> 
> Customer side is pretty much standard, too ...
> 
> interface Dialer1
>  ip address negotiated
>  ip mtu 1492
>  ip load-sharing per-packet
>  encapsulation ppp
>  no ip mroute-cache
>  dialer pool 1
>  dialer string dsl
>  dialer-group 1
>  keepalive 30
>  ppp authentication chap callin
>  ppp chap hostname xxx
>  ppp chap password xxx
>  ppp multilink
> 
> I'm kinda puzzled what could be causing this problem. The connection
> still comes up fine as Multilink-bundle on both sides. One 
> thing I have
> noticed though is that one router (2600 w/ c2600-j1s3-mz.123-12a) sets
> up the connection, and when doing more than one line, spits out this
> error shortly after activating the second line:
> 
> 1y50w: %SYS-2-INPUT_GETBUF: Bad getbuffer, bytes= 65535, for 
> interface=
> Virtual-Access4
> -Process= "PPP Events", ipl= 3, pid= 105
> -Traceback= 8033BBAC 80433838 8028134C 80281884 80281DC0 806A9594
> 806A2850 803BB370 806A27FC 8066E3B8 8068FC0C 8068FDA0 
> 8066E914 803BD59C
> 803C0C48
> 
> Has anybody had something like this before, and could give me 
> a hint as
> to what could be causing this problem? If it can't be solved, 
> I can have
> the customer lines moved back to the Juniper system, though I would
> prefer to find a solution that would also work for sites that do not
> have a J system available ...
> 
> Tnx, -gg
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/