user-maxlinks bug

Kevin Dorrell · ‎10-03-2007

I am seeing a curious bug concerning maxlinks and currlinks.

In my dialin router, I have several users defined locally. Each username is allowed to use ppp multilink, and I have also defined a maxlinks in the username command:

<b>

username xxxx user-maxlinks 2 secret ...

</b>

Sometimes, I find that users cannot add a second link to their bundle. If I debug dialer events, I see that currlinks=2, maxlinks=2, so the new call is rejected. But the user has only one link up.

This looks like a bug in the router's running count of currlinks. I have the impression that sometimes when a call gets cleared, the currlinks gets decremented against the wrong username, or something like that. My evidence is two debug messages:

Se1/0:2: Dialer-peruser: Decremented user yyyy's currlinks, currlinks=0 maxlinks=2

Se1/0:1: Dialer-peruser: User yyyy's dialerperuser structure freed already

Serial1/0:1: Dialer-peruser: failure decrementing currlinks during mlp_remove_link

Maybe the error message above occurs because the bundle can be dialout as well as dialin. Is is possible that currlinks gets incremented on dial in, but not on dial out, but decremented when both types of call get cleared? Certainly the pattern for the case above was for a user that was allowed 4 links. I dialed out one channel, then he added another two to the ML bundle.

Maybe we are dealing with two different bugs here?

Anyone else seen this?

Kevin Dorrell

Luxembourg

gunner07971 · ‎10-03-2007

What version of IOS are you using?

Thanks,

Kevin Dorrell · ‎10-03-2007

12.4(8), c2800nm-ipbase-mz.124-8.bin on a 2811.

paolo bevilacqua · ‎10-03-2007

It may be very well that a bug exists, but the burden of proving that to cisco is on you. The first step is to upgrade to latest maintenance of selected train, and provide adeguate traces to the TAC.

[edit] Considering Kevin is a long-time NetPro and cisco user, he probably knows that already :)

Just consider my post a reiteration then.

Kevin Dorrell · ‎10-03-2007

Whether I persue it or not will depend on how much pain it gives me, how easy it is to demonstrate, and whether my time is better spent doing other work like learning in the lab or on NetPro.

This bug actually is likely to give quite a lot of pain in the long term, because it will limit the capacity of the dialins over time. But there is a workaround, which is not to limit the number of links.

The real reason for exposing the bug here is to see if anyone else has noticed it, and help me characterize it. When presenting a bug to Cisco, if you can present a repeatable set of conditions that produce it, then they are more likely to take notice.

Characterizing the bug also makes it easier to test if it has been fixed in the next release. I think this one should be quite easy to reproduce. It just needs a bit of detective work, which is presicely the sort of work I really enjoy!

Kevin Dorrell

Luxembourg