Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Re: Ascend OSPF?
David,
This may or may not be good news for you. I was doing an snmp walk
through the interface mib tree and discovered that our Ascends were
reporting roughly 80 connections up or in ack state to the same ISDN
router customer. I checked the routing table and it was not affected by
this which is probably why I never caught this before. I figured having
80 open connections, most of them invalid, would play havoc on
stacking.
I looked through logs and determined that the customer having these 80
connections were a result of numerous connections and drops in a
relatively short period. The customer using a Cisco 2503 with v10.3
software. I logged onto the 2503 and discovered that the reason for
frequent connections and disconnections was because the bandwidth on the
BRI port had not been configured and defaulted to 16kbps. That reaks
havoc on other configuration options. And the more obvious problem
which was that the idle timeout was not set as high as it could be (of
course we should be able to set this to whatever we want and not have
this problem). I corrected these settings and had to reboot the Cisco
for it to take the changes so it was obviously suffering from brain
damage as well. Since then, that connection has been more stable and
the number of entries in the snmp link status table are down to the
appropriate two entries. Since then, I have had zero reboots or OSPF
failures. I hope you find something like that, too. I looked further
through my logs and found that all of my Cisco customers cause this same
problem but they are not killing me because their configurations were
are not such that there are several connects and disconnects in a short
period of time. I'm obviously not saying this is a Cisco specific
problem but one that is related to customers who require interface based
routing and therefore a static route in the RADIUS table as well for
their subnet.
My reasoning behind why this causes the Ascends to fail is that stacking
is trying to stack all of these connections into a single MPPP
connection. The memory consumption for that would be considerable,
IMHO. I was experiencing considerable packet discards as a result which
I was unable to track down the reason for until this. This also points
out that there is still a fix that Ascend needs to be working on.
Ascend needs to find a way to terminate these connections
appropriately. I remember seeing somewhere in a bug report before that
Ascends were not properly terminating connections when the connection
profile was in RADIUS and had a static route in the profile. This would
match what I'm experiencing.
Todd Bishop
Unicom Communications, Inc.
David Power wrote:
>
> Well I tried all your suggestions And my life has still been miserable. I
> finally downgraded back to p24 (the last stable release I know about) and
> am down to 2 max reboots in 24 hours ( two different maxes ). Let me know
> if they send you a fix. I have 6 other maxes that all have their own
> rotarys. So no stacking is needed and get 30+ days of up time with out a
> problem. The dial up customers have to have stacking and with p36 and p38
> I was getting reboots every 1-3 hours. I havnt tried stacking without ospf
> at this time.
>
> --- On Sun, 18 Jan 1998 10:39:58 -0600 Todd Bishop <todd@unicom.net>
> wrote:
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>
Follow-Ups: