[c-nsp] Strange MLPPP problem ...

[Garry]

I am having a strange problem with two MLPPP links ... actually, one 
started yesterday, the other today ...

We have a central router terminating PPPoE connections handed over via 
l2tp. This works fine, with many dozens of active connections, including 
almost a dozen of MLPPP connections.

Yesterday, one customer called in complaining that his internet was 
down, and that the dial backup via BRI didn't kick in. A quick check 
showed that both links were there, but no IP traffic was possible. After 
some debugging, he pulled out one line, and suddenly the link worked 
again. Plugged it back in, PPPoE connection came up, link dead again. 
Removed the other line - link worked again. So, in essence, when one 
link is active, everything is fine, when both are up, no go. This one is 
an ADSL customer with a 768/128 and 512/128 hookup.

This morning, another customer called, experiencing the same problem. 
This one has a dual 1M SDSL hookup.

Reboot of either router didn't help any. Reboot of the router on our 
side is not possible before maybe Saturday night. Configs on either 
router are unchanged and identical in essential areas to other customers 
who are running fine. Radius config is unchanged and identical, again. 
We set up another router, using the exact radius record apart from the 
IP address and the username, this one worked fine. IOS-Versions of one 
customer's router is identical to a working customer's IOS. The 
non-working (and at least one working customer) use 1841 w/HWIC 4ESW.

"show ppp multi int" for one customer looks like this for one or two 
links up:

Virtual-Access31, bundle name is dsl-15451-001#[...]
   Bundle up for 00:02:00, 24/255 load
   Receive buffer limit 12192 bytes, frag timeout 1000 ms
   Using relaxed lost fragment detection algorithm.
     0/0 fragments/bytes in reassembly list
     0 lost fragments, 0 reordered
     0/0 discarded fragments/bytes, 0 lost received
     0x88 received sequence, 0x0 sent sequence
   Member links: 1 (max not set, min not set)
     mkt:Vi174  (213.172.98.29), since 00:02:01, unsequenced

Virtual-Access31, bundle name is dsl-15451-001#[...]
   Bundle up for 00:02:26, 10/255 load
   Receive buffer limit 24384 bytes, frag timeout 1000 ms
   Using relaxed lost fragment detection algorithm.
     0/0 fragments/bytes in reassembly list
     0 lost fragments, 0 reordered
     0/0 discarded fragments/bytes, 0 lost received
     0x8F received sequence, 0x3A sent sequence
   Member links: 2 (max not set, min not set)
     mkt:Vi136  (213.172.98.25), since 00:00:17, 3360 weight, 1488 frag 
size, unsequenced
     mkt:Vi174  (213.172.98.29), since 00:02:26, 2400 weight, 1488 frag 
size, unsequenced

(not sure whether the frag-size has anything to say, I did a couple 
tries to add or remove features - can't check again until tonight to see 
whether the standard config used has it or not)

The (working) customer's output looks like this:

Virtual-Access72, bundle name is dsl-15458-001#[...]
   Bundle up for 12:52:42, 15/255 load
   Receive buffer limit 24384 bytes, frag timeout 1000 ms
   Using relaxed lost fragment detection algorithm.
     574/0 fragments/bytes in reassembly list
     1695 lost fragments, 436309 reordered
     591/976003 discarded fragments/bytes, 0 lost received
     0x28D00E received sequence, 0x2D9ACC sent sequence
   Member links: 2 (max not set, min not set)
     mkt:Vi124  (213.172.98.29), since 12:52:42, unsequenced
     mkt:Vi30  (213.172.98.25), since 12:52:42, unsequenced

Customer router config looks something like this:

interface Dialer2
  mtu 1456
  ip address negotiated
  ip load-sharing per-packet
  encapsulation ppp
  ip route-cache flow
  dialer pool 2
  no cdp enable
  ppp authentication chap callin
  ppp chap hostname dsl-15451-001#[..]
  ppp chap password xxx
  ppp ipcp dns request
  ppp multilink

Anybody have an idea what else I could check? The customer #1 had the 
router up and running in multilink config for three months now, the 
other was operational for over two weeks ...

Tnx, garry