Hi Kevin, I haven't really followed the rest of the thread, but one thing caught my eye. You mention an MPP connection - this is Ascend's proprietary Multilink Protocol, when attempting a multi-link connection with another vendor's equipment you should use MP instead of MPP. I know all this is supposed to "fall back, re-negotiate, and automatically work" but many times different vendors products negotiate incompatibly. The fact that you have a problem upon disconnecting seems to point to some issue like this, as the MPP handles adding and subtracting bandwith differently than MP - the channel addition may work ok, but something is happening upon disconnect that one or the other router doesn't understand.. I have also seen where using compression has created problems. This would seem to be unrelated but incompatabilities in compression have created connection problems as it's one of the parameters negotiated setting up a connection. I'm not sure if any compression negotiation happens when a channel disconnects though. Good luck, Scott Starbuck Aobe Network Group ----------------------- ascend at saffron.colloquium.co.uk wrote: > Hi; > > Thanks again, everyone, for your help - unfortunately, things still aren't working quite right. To recap, what we're trying to do is get a Cisco 1603R connecting to an Ascend Max 4000 via ISDN. When negotiating a normal PPP connection (ie single channel) everything works fine - it dials up, authenticates, you get the transfer rates you'd expect, and when idle timeout is reached the line drops. However, when we enable multilink, and it negotiates an MPP connection, the following is happening. > > Everything appears to work at first - first, one channel comes up and then, as demand rises, the other. However, when the idle timeout has been reached, something goes wrong. The Cisco thinks it has dropped the channel, or channels, but on our Ascend, the user still shows up as connected even though the link light(s) on the Cisco have gone out. What this means is that when the two channels are brought up, they don't go back down again ever at our end, thus preventing all future connections from this user until we power-cycle the Cisco, or kick the session off the Ascend. > > I've tried the config file sample that Troy provided, and the username fix that Craig suggested, but to no avail. When both channels are up they function perfectly, with the transfer rates/ping times one would expect - it's just when it comes time for the channels to drop after idle timeout that everything goes horribly wrong. > > If anyone has any ideas, I'd be very grateful. > > Cheers; > Kevin Drysdale, Colloquium Internet Technical Support. > > ++ Ascend Users Mailing List ++ > To unsubscribe: send unsubscribe to ascend-users-request at bungi.com > To get FAQ'd: <http://www.nealis.net/ascend/faq> ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request at bungi.com To get FAQ'd: <http://www.nealis.net/ascend/faq>