10-03-2007 02:25 AM
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
10-03-2007 05:33 AM
What version of IOS are you using?
Thanks,
10-03-2007 06:19 AM
12.4(8), c2800nm-ipbase-mz.124-8.bin on a 2811.
10-03-2007 11:12 AM
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.
10-03-2007 12:36 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide