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 | | spork@inch.com access@inch.com | = =----------------= - 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.
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. Charles Sprickman wrote:
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 | | spork@inch.com access@inch.com | = =----------------=
- 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 Richard Stuplich
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" ^^^^ 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.
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
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: 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.
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 <jeffm@iglou.com> To: <usr-tc@lists.xmission.com> Sent: Monday, January 31, 2000 1:57 PM Subject: Re: (usr-tc) ARC amnesia
Thus spake Richard Stuplich
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" ^^^^ 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.
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
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: 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 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: 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.
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. Jeff Mcadams wrote:
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: 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.
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 On Mon, 31 Jan 2000, Richard Stuplich wrote:
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.
Charles Sprickman wrote:
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 | | spork@inch.com access@inch.com | = =----------------=
- 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.
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 Charles Sprickman (spork@inch.com) spake:
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 | | spork@inch.com access@inch.com | = =----------------=
- 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.
-- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________ - 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.
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 <das@gol.com> To: usr-tc@lists.xmission.com Subject: Re: (usr-tc) ARC amnesia Send reply to: usr-tc@lists.xmission.com
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
Charles Sprickman (spork@inch.com) spake:
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 | | spork@inch.com access@inch.com | = =----------------=
- 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.
-- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________
- 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.
__________________________________ Kalev Nurklik Delfi Online Pa"rnu mnt. 158, 11317 Tallinn, Estonia Tel: +372 6501709 Fax: +372 6501708 E-mail: k.nurklik@online.ee http://online.delfi.ee - 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 (6)
-
Charles Sprickman -
D A Substanley -
Jeff Mcadams -
Kalev Nurklik -
Mark Thornton -
Richard Stuplich