Subject: (usr-tc) ARC amnesia

From: Charles Sprickman <[email-masked]>
Date: Mon, 31 Jan 2000 20:22:37 +0000

Hi,

I was paged out of bed last night by an arc card that stopped responding
to pings...  I went into tcm to have a look, and all was green, but going
to the config screen showed that the card had no IP address
anymore.  Doing a hard reset brought it back, and it's working fine.  Has
anyone else seen this?  Just a fluke, or an issue with the 4.3.32-1 code?

Thanks,

Charles

-- 
=-----------------=                                        = 
| Charles Sprickman                       Internet Channel |
| INCH System Administration Team         (212)243-5200    |
| [email-masked]                          [email-masked]  |
=                                         =----------------=

-
 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: Richard Stuplich <[email-masked]>
Date: Mon, 31 Jan 2000 21:49:28 +0000

I have seen this.  I posted a question about this with no answer (yet).  This
is the default route taking off on you I would bet.  I was dealing with this
for a long time and found that the HiperARC doesn't deal with the radius
properly (as far as I can tell).

This will break the default route:

mmanuf  Password = "UNIX"
        User-Service-Type = Framed-User,
        Framed-Protocol = PPP,
        Framed-Address = 207.0.68.214,
        Framed-Netmask = 255.255.255.255,
        Framed-Route = "207.0.68.213 207.0.68.214 1"
        Framed-Compression = Van-Jacobsen-TCP-IP,
        Idle-Timeout = 0,
        Framed-MTU = 576

Where this will simply not work at all:

mmanuf  Password = "UNIX"
        User-Service-Type = Framed-User,
        Framed-Protocol = PPP,
        Framed-Address = 207.0.68.214,
        Framed-Netmask = 255.255.255.255,
        Framed-Route = "207.0.68.213/32 207.0.68.214 1"
        Framed-Compression = Van-Jacobsen-TCP-IP,
        Idle-Timeout = 0,
        Framed-MTU = 576

Note: The first and 2nd work fine on Livingston/Lucent devices.  In both
above examples it does not work (route the 2nd IP address over the dialup).
In the first case it breaks the rack be claminig the default route and in the
2nd it only does the promary IP address.

Check your radius users file for "Framed-Route" lines.  These may be causing
this.

Note: This is the 3rd rev of the code that still does this.

-

---

From: Jeff Mcadams <[email-masked]>
Date: Mon, 31 Jan 2000 22:00:53 +0000

Thus spake Richard Stuplich

>        Framed-Route = "207.0.68.213 207.0.68.214 1"
                                  ^^^^
There is no indication of the netmask to use...from RFC2138:

      For IP routes, it SHOULD contain a destination prefix in dotted
      quad form optionally followed by a slash and a decimal length
      specifier stating how many high order bits of the prefix should be
      used.  That is followed by a space, a gateway address in dotted
      quad form, a space, and one or more metrics separated by spaces.
      For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length
      specifier may be omitted in which case it should default to 8 bits
      for class A prefixes, 16 bits for class B prefixes, and 24 bits
      for class C prefixes.  For example, "192.168.1.0 192.168.1.1 1".

This means (assuming the Arc follows this correctly...I haven't checked)
that you're setting the route as "207.0.68.0"(!) as a class C or /24
route to the user's IP address...not what you want I think.

>        Framed-Compression = Van-Jacobsen-TCP-IP,

Hrmm...this *should* work...in theory at least...why this isn't working
for you I'm not sure (again...I haven't thoroughly tested the Arc's
routing behavior).

Keep in mind that some of this may be dependant on how your customer is
using this extra IP...
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Mark Thornton <[email-masked]>
Date: Mon, 31 Jan 2000 22:10:05 +0000

I seem to recall that 3Com stated that the routes introduced by raduis are
not handled correctly by the source address verification feature. I believe
the release note indicated if you turn on source address verification for
the entire chasis (we did), you can only route by the ip address and subnet
assigned to the port in radius, not additional routes added via radius, or
static in the Arc. Could this be the problem?

Mark Thornton
San Marcos Internet, Inc.
512-393-5300

----- Original Message -----
From: Jeff Mcadams <[email-masked]>
To: <[email-masked]>
Sent: Monday, January 31, 2000 1:57 PM
Subject: Re: (usr-tc) ARC amnesia

-

---

From: Jeff Mcadams <[email-masked]>
Date: Mon, 31 Jan 2000 22:13:10 +0000

Thus spake Mark Thornton
>I seem to recall that 3Com stated that the routes introduced by raduis
>are not handled correctly by the source address verification feature. I
>believe the release note indicated if you turn on source address
>verification for the entire chasis (we did), you can only route by the
>ip address and subnet assigned to the port in radius, not additional
>routes added via radius, or static in the Arc. Could this be the
>problem?

Certainly could be...need to find out if Richard has source address
verification enabled.  :)  What say ye, Richard?  ;)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Charles Sprickman <[email-masked]>
Date: Mon, 31 Jan 2000 22:24:44 +0000

I think I have something different.  It lost all IP settings, at the
least, not just the default route.  We also don't have any customers with
routed connections...

Thanks though,

Charles

-

---

From: D A Substanley <[email-masked]>
Date: Tue, 01 Feb 2000 03:18:19 +0000

Yes, I had one the other day that was sporadically allowing users to connect 
then not.  I tried logging in, and it had forgotten the password.  Hardware
reset, thankfully, brought it out of its fugue.

das

-- 
______________________________________________
Alex Substanley     Exodus Communications K.K.
  		    Engineering Department
Das Man             TEL: 81-3-5334-1700
Systems Engineer    FAX: 81-3-5334-1711
______________________________________________

-

---

From: Richard Stuplich <[email-masked]>
Date: Tue, 01 Feb 2000 03:51:40 +0000

HiPer>> show ip sec set

IP SECURITY SETTINGS
Drop All Fragoffset1:                      ENABLED
Drop TCP Fragoffset1:                      ENABLED
Disallow All Header Options:               DISABLED
Disallow Source Route Options:             DISABLED

Do I need to change enything here.  We try to change as little as possible
on these units.  Safer that way we have found.

-

---

From: Kalev Nurklik <[email-masked]>
Date: Tue, 01 Feb 2000 10:12:55 +0000

Could be a memory issue. I had one 64MB HARC with 4.2.32-1 rev.
choke on me when I turned some debuging on e.g. I set couple of
facilities to something else than critical and typed "show events"
on the cli.
Everything went fine but when I logged out and in again after some
time had gone by - I got dumped. Just couldn't telnet to HARC...
Rebooted and everything was OK.
So from the logs I got these results -
HARC was saying something like:
"couldn't spawn child process for cli session - not enough memory!"
or something like that.
And when I took a look at the radius logs afterwards I saw definite
connection troubles during the same time interval - a lot more
unauthenticated accounting stops.

Date sent:      	Tue, 1 Feb 2000 10:12:36 +0900
From:           	D A Substanley <[email-masked]>
To:             	[email-masked]
Subject:        	Re: (usr-tc) ARC amnesia
Send reply to:  	[email-masked]

> > anyone else seen this?  Just a fluke, or an issue with the 4.3.32-1 code?

__________________________________
Kalev Nurklik
Delfi Online
Pa"rnu mnt. 158, 11317 Tallinn, Estonia
Tel: +372 6501709
Fax: +372 6501708
E-mail: [email-masked]
http://online.delfi.ee

-