(usr-tc) Restricting MPPP
Hi, Same problem as I figured out last time--- multiple users, one of them is setup (client) for MPPP, any connections afterwards will get dropped as they definately won't be able to bond to the other connection. IS there a way to limit MPPP with a RADIUS attribute? (using livingston 2.01). Seems like I ought to be able to <not allow> MPPP, but not as a check event as in IF you want MPPP, but we say no, drop the connection (pain in the butt), but more like So you want MPPP, fine, we're not going to allow it but you think what you want to think. Make sense? Port-Limit attibute wouldn't do it. Not seeing any other attributes that really do it either. I did look through the usr-tc archive. Anyone know? I would really think this'd be something I ought to be able to control. I can't even filter for it either, now can I? It's grabbing the username at the HiperARC upon login. SMT - 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 Scott Trautman
Same problem as I figured out last time--- multiple users, one of them is setup (client) for MPPP, any connections afterwards will get dropped as they definately won't be able to bond to the other connection.
IS there a way to limit MPPP with a RADIUS attribute? (using livingston 2.01). Seems like I ought to be able to <not allow> MPPP, but not as a check event as in IF you want MPPP, but we say no, drop the connection (pain in the butt), but more like So you want MPPP, fine, we're not going to allow it but you think what you want to think.
Make sense?
Not really.
Port-Limit attibute wouldn't do it. Not seeing any other attributes that really do it either. I did look through the usr-tc archive.
Anyone know? I would really think this'd be something I ought to be able to control. I can't even filter for it either, now can I? It's grabbing the username at the HiperARC upon login.
So...what exactly is your problem here...I didn't follow. You have multiple people logging in with the same userid? You limit that with Simultaneous-Use (non-reliably as far as I'm concerned), or with a script that goes in and checks for duplicate logins (I recommend SNMP for this). Port-Limit will limit the number of channels allowed in a multi-link bundle. These really shouldn't interact. There is no way really to enable or disable multi-link on a per-user basis...you can disable it on the whole Arc with "disable ppp multilink_ppp", but then you won't let *anyone* use MP...not what you want I suspect. Port-Limit can be set to 1, which would allow them to run MP, but only allow one link in the bundle...essentially, they get no benefit from MP at that point, but technically they can still run the MP protocol. If you're running into multiple users running multi-link logging in seperately, but your Arcs are trying to bundle the links together, then you need to get a log of the LCP negotiation of the connections...it sounds like they're not sending a Multi-Link endpoint discriminator, or the Arc is handing it incorrectly. If they're logging in from seperate locations, they should have seperate EDO's, and the Arc should (and I haven't seen any problems with this) handle the connections as totally seperate sessions, Port-Limit wouldn't apply, Multi-Link is a moot point. Anyway...maybe you can give a better description of what you're seeing...and the behavior you'd like to see...there should be a way of doing what you want without actually disabling MP for the user. There's really very little reason to need to actually disable MP for a user. -- 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.
participants (2)
-
Jeff Mcadams -
Scott Trautman