Re: (PM) PM3 Lockups and 2 Class Cs

Josh Richards (jrichard@livingston.com)
Mon, 8 Jun 1998 00:47:00 -0700 (PDT)

On 5 Jun 1998, Patrick Darden wrote:

> A little over a month ago we started having lockups with our PM3s. We
> have 4 PM3s that until then had been working with practically no
> problems. After working with Lucent tech support for two weeks (most of
> which was spent playing phone tag since they kept calling after hours,
> once we actually got in contact they were quite fast about clearing the
> problem up), they informed me that we can't make use of two different
> class Cs. This makes no sense at all to me, as multiple Class Cs are a
> necessity for "large" operations. Here was our situation:
>
> pm3-1 class c1
> pm3-2 class c1
> pm3-3 class c1
> pm3-4 class c2
>
> After a certain load point, pm3s 3 and 4 would lock up.
>
> We fixed this by consolidating all the pm3s in a single class C--but this
> leaves us little room for expansion. Lucent tech support advised adding a
> new dialup number, which is unacceptable. At my insistence, they agreed
> to look into what other large operations were doing, but they never got
> back in touch with me. I still have an open ticket (55854), but they have
> not called me back for over a month now.

Support was referring to the fact that in <= 3.7.x we do/did not support
Ethernet subinterfaces (we do in the 3.8 beta). You certainly can route
however many networks you feel like through a PortMaster without a
problem.

I don't see where this would have been your cause for having any
"lockups", though--at least not directly. *BUT* my assumption is that
they (the technician) may have felt that your "lockups" were a result of
running a routing protocol on your networks in some particular
configuration that was causing problems. How were you handling the
network path between the two networks (e.g. what was serving as the router
between them)? What routing protocols are you using? What ComOS release?
Etc.

Yes, if you were able to lock-up the PM strictly just because of a
particular configuration you were using, then there IS definitely a
problem somewhere (read: our problem). Both RIP & OSPF are rock-solid and
I've never heard or experienced anything to the contrary before (in a
released product that is...obviously being in Beta I've seen a lot of
weird things go funny at times), so this would be most unusual.
Obviously, it could be hardware too, although you did say two PMs and that
your resulting re-configuration onto the same network appeared to take
care of the issue.

Were the "lockups" truly frozen and non-responsive (requiring a hard
reboot) or did the PMs reboot themselves? If they rebooted, they should
have dumped a stack trace out to the console port (note, not just a
console session--it MUST be the console port) which would be most useful
in tracking things down.

Regardless, I'd call Support again and ask to escalate it if you aren't
happy with the answer. I'm sure whomever you spoke with meant to get back
to you, but I'm not in a position to say what happened. They are probably
still trying to get a satisfactory answer for you. The only thing I can
try to do for you is (1) get you pointed in the right direction and (2)
possibly, if need be, give that someone here, at Lucent RABU, a nudge for
you if you'd like me too. ;-)

-jr

----
Josh Richards - <jrichard@livingston.com> - <josh@lucent.com>
[Beta Engineer] - LUCENT Technologies - Remote Access Business Unit
<URL:http://www.livingston.com/> * <URL:http://www.lucent.com/dns/>

-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>