Subject: (usr-tc) Stalling web pages w/TC products

From: Cheryl Johnson <[email-masked]>
Date: Thu, 02 Dec 1999 17:38:40 +0000

We have been having problems recently showing up with the TC chassis. We are using the HiPerARC and DSP with channelized T1s. The software version is
ARC 4.1.59-6 and DSP 1.2.37 and testing 2.0.60 on some DSP cards. Customers are beginning to complain about web pages are timing out from more than one POP site. Strange thing is nothing has been changed on the chassis except the radius server. Checked the configs but nothings seems different. Anyone have any idea what could be the problem? Any ideas are appreciated.

Cheryl Johnson
Network Administrator
Seidata Network Services, Inc.
http://www.seidata.com

---

From: Dave <[email-masked]>
Date: Thu, 02 Dec 1999 18:19:37 +0000

Cheryl,
	I saw the exact problem after changing my radius server here. The 
problem was caused by the MTU assignment set in the radius software on 
the new box, 576 was the size being set for users. To see what the size 
is being assigned currently do a 'show remote user [user name]' while 
logged in to the HiPerARC. If your Framed MTU setting is lower than 15xx 
adjust the setting in your radius software to 1500. That solved it for me.
Hope this helps you out.

Dave Lajoie
Senior System Operator 
North Country Internet Access
38 Glen Ave.
Berlin, NH. 03570
[email-masked]

On Thu, 2 Dec 1999, Cheryl Johnson wrote:

> We have been having problems recently showing up with the TC chassis. We =
> are using the HiPerARC and DSP with channelized T1s. The software =
> version is
> ARC 4.1.59-6 and DSP 1.2.37 and testing 2.0.60 on some DSP cards. =
> Customers are beginning to complain about web pages are timing out from =
> more than one POP site. Strange thing is nothing has been changed on the =
> chassis except the radius server. Checked the configs but nothings seems =
> different. Anyone have any idea what could be the problem? Any ideas are =
> appreciated.
> 
> Cheryl Johnson
> Network Administrator

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 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.

---

From: Cheryl Johnson <[email-masked]>
Date: Thu, 02 Dec 1999 19:25:20 +0000

What radius software are you using? And what version?

----- Original Message -----
From: Dave <[email-masked]>
To: <[email-masked]>
Sent: Thursday, December 02, 1999 11:14 AM
Subject: Re: (usr-tc) Stalling web pages w/TC products

-

---

From: Cheryl Johnson <[email-masked]>
Date: Thu, 02 Dec 1999 19:43:50 +0000

I am thinking you mean to change the TC chassis MTU setting to 1500. I could
be wrong.  If so, do you know the command set to apply this to chassis?

----- Original Message ----
From: Dave <[email-masked]>
To: <[email-masked]>
Sent: Thursday, December 02, 1999 11:14 AM
Subject: Re: (usr-tc) Stalling web pages w/TC products

-

---

From: Dave <[email-masked]>
Date: Thu, 02 Dec 1999 21:32:04 +0000

I'm using 'Cistron 1.6.1 Stable' at this time. If that is what you are 
using you would modify the Framed MTU setting from the default of 576 to 
1500. I am running Linux 6.1 on the box, the file to alter is users 
and the dir would be etc/raddb.

Dave Lajoie
Senior System Operator

-

---

From: Dave <[email-masked]>
Date: Thu, 02 Dec 1999 22:07:34 +0000

First look to see what the current users MTU settings are, if your using 
Radius software it will be assigning the MTU and thats where you will 
need to make the change if it isn't set to 1500. Unless all your user 
accounts are setup on the ARC, changing the settings there won't help. 
After all ... you did say the only thing changed was the "radius server", 
Look there.

Dave Lajoie
Senior System Operator

-

---

From: Jeff Mcadams <[email-masked]>
Date: Thu, 02 Dec 1999 22:45:28 +0000

Thus spake Dave
>After all ... you did say the only thing changed was the "radius server", 

Actually...

The defaut MTU value on the Arcs (like all other default values) is
pulled from the user "default" that's defined on the Arc's.  The value
is only updated by RADIUS if the user profile in RADIUS has the
Framed-MTU setting included.  Otherwise RADIUS doesn't send the MTU
value and the default from the Arc's default user is used.

So, even if you're authenticating your users via RADIUS, the MTU *might*
be getting pulled from the Arc's default user definition.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Dave <[email-masked]>
Date: Fri, 03 Dec 1999 00:28:28 +0000

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. 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. 

Dave Lajoie
Senior System Operator

 Jeff Mcadams says:

 Actually...

 

-

---

From: Jeff Mcadams <[email-masked]>
Date: Fri, 03 Dec 1999 03:59:36 +0000

Thus spake Dave
>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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Brian <[email-masked]>
Date: Fri, 03 Dec 1999 18:25:50 +0000

On Thu, 2 Dec 1999, Cheryl Johnson wrote:

> We have been having problems recently showing up with the TC chassis.
> We are using the HiPerARC and DSP with channelized T1s. The software
> version is ARC 4.1.59-6 and DSP 1.2.37 and testing 2.0.60 on some DSP
> cards. Customers are beginning to complain about web pages are timing
> out from more than one POP site. Strange thing is nothing has been
> changed on the chassis except the radius server. Checked the configs
> but nothings seems different. Anyone have any idea what could be the
> problem? Any ideas are appreciated.

What does your input/output bandwidth utilization look like on your
upstream t1's?

> Seidata Network Services, Inc.

-----------------------------------------------------
Brian Feeny (BF304)     [email-masked]   
318-222-2638 x 109	http://www.shreve.net/~signal      
Network Administrator   ShreveNet Inc. (ASN 11881) 	      

-