Thus spake Dave
Thanks for correcting me. Your right there. However, if the radius software is setting the MTU the ARC will use the assigned value set by the Radius server.
Absolutely...and this bit us when we first switched to Arc's from NETServers. Because MTU is negotiated in LCP, which is before the user information is available (typically), many systems will get the MTU information from the RADIUS server (or local user profile) and think, "Oh, I've already negotiated MTU...its too late to do anything with this" and not do anything. The NETServer seemed to behave this way. The Arc actually does change the MTU (I assume only if the MTU is less than what was negotiated in LCP...if its greater and it changes it without notifying the peer, that would be Bad(tm) :). So, when we switched from NETServers to Arcs we started seeing a significant change in behavior that was terribly unexpected. We figured it out quickly enough...but it was a bizarre couple of hours figuring it out. :)
Which was what happened in my case and is probably happening in this one as well. Just trying to help, sorry if I misrepresented the facts.
Indeed, it does sound like an MTU problem. What I don't understand though is, why is there so many problems with MTU issues with Arc's specifically...Like I mentioned above, many Access Servers won't change the MTU after LCP negotiation, but I can't believe the Arc's are the only one's that do it. I understand that some providers filter all ICMP, including "fragmentation needed but DF set", or use RFC1918 space which causes similar problems, but I know that neither of those two situations are the case in my network, and I was seeing these same sorts of pauses connecting to our Solaris servers. Is the Arc not generating the ICMP correctly? Is Solaris not doing PMTUD correctly? (I'm relatively sure this isn't the case, I've watched it do it in snoops of other traffic). What else could cause this sort of problem? I haven't had a chance to set up a test of this yet, but given that its cropping up a bit more, I think I'm gonna try to find a chance to do that and see what's going on with it. -- 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.