Need to know your dial out script on the NETServer - You can program the dial out number on the modem and foce it to dial immediately or you could have the number of session set to 2 (max ports) - I am not sure but one of the above method does negotiate multilink and the other does not - guess it changes the mpedo. krish On Wed, 29 Sep 1999, Carl Litt wrote:
Yes, I did clip out a bit of info... here's the complete output:
Monitoring the next session to start up. Decode tracing started, press ESCAPE to stop; press X for hex tracing. ....Tracing the current/next session; Escape to stop...
Outgoing PPP Data on interface: slot:10/mod:12 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 MAGIC_NUM 9e 5a aa e5 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00
Incoming PPP Data on interface: slot:10/mod:12 LCP CFG_REQ MPP_ENDPTID 04 6f f7 09 08 ASYNC_MAP 00 00 00 00 MAGIC_NUM eb c4 d4 f4
Outgoing PPP Data on interface: slot:10/mod:12 LCP CFG_ACK MPP_ENDPTID 04 6f f7 09 08 ASYNC_MAP 00 00 00 00 MAGIC_NUM eb c4 d4 f4
Incoming PPP Data on interface: slot:10/mod:12 LCP CFG_ACK MRU 05 ea ASYNC_MAP 00 00 00 00 MAGIC_NUM 9e 5a aa e5 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00
I've also tried durning off PPP offloading for the hell of it, but no difference.
Thanks, Carl
On Wed, 29 Sep 1999, Jeff Mcadams wrote:
Thus spake Carl Litt
Is it possible to get a Netserver to connect to a HiPer ARC with more than one channel (by using multilink)?
We're trying to move a customer over from dialing into another Netserver (not ours) into an ARC running 4.1.59. The login is set in RADIUS, and does work for a single channel. We have no Port-Limits set, and the ARC has the default 2 Max-Chan.
We can get the first channel up, but the second channel connects then drops. Here is the "mon ppp" output:
Incoming PPP Data on interface: slot:10/mod:23 LCP CFG_ACK MRU 05 ea ASYNC_MAP ff ff ff ff MAGIC_NUM 4c 56 1b da PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00
Incoming PPP Data on interface: slot:10/mod:23 LCP CFG_REQ MPP_ENDPTID 04 6f f7 09 08 ASYNC_MAP ff ff ff ff MAGIC_NUM 23 ea 32 19
Outgoing PPP Data on interface: slot:10/mod:23 LCP CFG_ACK MPP_ENDPTID 04 6f f7 09 08 ASYNC_MAP ff ff ff ff MAGIC_NUM 23 ea 32 19 --- [The call is then dropped] ---
From what I can see, there are no NAK's which should cause a protocol termination. In the RADIUS accounting logs, the session has a Term-Cause of NAS-Error.
Well...you're apparently not catching all of the PPP negotiation...which means we might be missing some useful data, but...
You'll notice that the incoming config request does *not* have the MPP_MRRU attribute in it. The MPP_MRRU attribute is the attribute/value that indicates that Multi-Link can/will be used on that link. If one side doesn't negotiation the MPP_MRRU, then Multi-Link can't work on that link. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.