(usr-tc) Netserver to ARC using Multilink
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.
Any advice? Thanks, Carl - 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.
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.
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.
Thus spake Carl Litt
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
Here's the first incoming lcp config request.... Again...no MPP_MRRU in this, Multi-Link won't work without that attribute being negotiated during the LCP phase. If a system tries to send a multi-link encapsulated packet without negotiating the MRRU, it is considered an error. So, the other side is not negotiating MP correctly. -- 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.
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.
participants (3)
-
Carl Litt -
Jeff Mcadams -
Tatai SV Krishnan