[c-nsp] Re: Multilink PPP IPCP Negotiation Problem

[Douglas E. Warner]

Two months later, I was able to get this solved (mostly), so I figured I 
should reply so it can be archived.

We weren't able to run dCEF on the VIP we had because it was an old VIP2-40 
with only 64M of RAM - not enough to load our FIB table when running 12.4(3).  
We think that this along with some CEF bug kept the bundle from coming up.
When we replaced the VIP2-40 with a VIP2-50 with 128M of RAM, dCEF still 
wouldn't come up correctly (even with: no ip cef d; no ip cef; ip cef; ip cef 
d), so we had to do a router reload.  After this, I was able to configure 
Multilink PPP as normal - no problems.
Well, I wouldn't say "no problems," actually, because when I put the serial 
links into the multilink bundle they didn't remove the queuing on the 
interface and I was seeing a high number of "lost fragments."  I had to 
remove each serial interface from the bundle, type 'no fair-queue' and and 
put them back in.
I'm still seeing some incrementing lost packets, and a high number of 
reordered packets, but that's for another thread.

Hopefully this provides some help to somebody down the road.

-Doug 


On Thursday 25 August 2005 09:57, Douglas E. Warner wrote:
> I'm trying to setup MLPPP between two 7505's running RSP4s on 12.4(3) over
> 4xT1 on PA-MC-8T1 cards.  The problem I'm having is that the Multilink
> interface gets stuck in IPCP trying to agree on IPs, even though I have the
> Multilink interface configured with the IP on both ends.
>
> Unfortunately, my log server ate the debugs from my one router, but they
> were still in the buffer on the other.  To me, it looks like rtr0.tc sends
> a CONFREQ to rtr0.mbrg saying "I have this IP"; rtr0.mbrg then
> acknowledges, but it looks like rtr0.tc never receives it.
>
> Below is a snippet of the logs from rtr0.mbrg:
>
> ---------------------------------
> Aug 24 19:13:07: Mu1 IPCP: O CONFREQ [ACKsent] id 8 len 10
> Aug 24 19:13:07: Mu1 IPCP:    Address 172.16.5.18 (0x0306AC100512)
> Aug 24 19:13:09: Mu1 IPCP: I CONFREQ [ACKsent] id 9 len 10
> Aug 24 19:13:09: Mu1 IPCP:    Address 172.16.5.17 (0x0306AC100511)
> Aug 24 19:13:09: Mu1 IPCP: O CONFACK [ACKsent] id 9 len 10
> Aug 24 19:13:09: Mu1 IPCP:    Address 172.16.5.17 (0x0306AC100511)
> Aug 24 19:13:09: Mu1 IPCP: TIMEout: State ACKsent
> Aug 24 19:13:09: Mu1 IPCP: O CONFREQ [ACKsent] id 9 len 10
> Aug 24 19:13:09: Mu1 IPCP:    Address 172.16.5.18 (0x0306AC100512)
> Aug 24 19:13:11: Mu1 IPCP: I CONFREQ [ACKsent] id 10 len 10
> Aug 24 19:13:11: Mu1 IPCP:    Address 172.16.5.17 (0x0306AC100511)
> Aug 24 19:13:11: Mu1 IPCP: O CONFACK [ACKsent] id 10 len 10
> Aug 24 19:13:11: Mu1 IPCP:    Address 172.16.5.17 (0x0306AC100511)
> Aug 24 19:13:11: Mu1 IPCP: TIMEout: State ACKsent
> Aug 24 19:13:11: Mu1 IPCP: O CONFREQ [ACKsent] id 10 len 10
> Aug 24 19:13:11: Mu1 IPCP:    Address 172.16.5.18 (0x0306AC100512)
> Aug 24 19:13:13: Mu1 IPCP: TIMEout: State ACKsent
> Aug 24 19:13:13: Mu1 IPCP: State is ACKsent
> ---------------------------------
>
> Has anyone seen this behavior before?

-- 
Douglas E. Warner    <dwarner at ctinetworks.com>     Network Engineer
CTI Networks, Inc.   http://www.ctinetworks.com    +1 717 975 9000
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://puck.nether.net/pipermail/cisco-nsp/attachments/20051021/7c5d063d/attachment.bin