Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(ASCEND) NAT dropping dead on Pipelines...
Hello all,
OK, so here's the deal... I posted about a week ago about NAT problems I
am having with PL130s and a huge and ugly thread was born. Some people
jumped all over Ascend claiming that their implementation of NAT is, in
some way, bogus. The Ascend fellows on this list defended Ascend and
asked for specific information -- TRs and the like...
To fill in:
Our customers are using NAT on PL130s with nailed connections. They are
not using ISDN -- they have PL130s with V.35 going to CSU/DSUs and then to
our Max4000. What happens is, after some amount of time, NAT just stops
working. The only way to bring it back to life is to issue a 'hangup' to
the session which causes the PL130 to just reconnect right away. This
seems to clear some overfull table and make everything work again.
I called in my problem and a trouble ticket was opened (202012). When I
was called back, I was asked what version of the code I was running -- my
answer was 5.1Ap8. I was told that I should upgrade to 6.0.0. I asked if
there were known NAT problems in 5.1Ap8 that were fixed in 6.0.0 and I was
told that he didn't know but I "really should upgrade". So, we upgraded
our customer's PL130 to 6.0.0. and things are exactly as they were -- no
better. Well, I called today and was told that this was a known problem
(TR2928) and that engineering was working on it.
What is not clear to me is whether this problem happens only when some
particular thing happens or whether just having NAT running on a nailed
connection is the problem.
I guess what bothers me is it seems that the NAT table entries don't seem
to go away as they should -- Is it possible that, under certain
circumstances, the table entries don't go away? Perhaps socket connections
which are opened and closed properly *do* go away but socket connections
that are left hanging never leave the table -- I don't know...
Another *very* important feature I would like to see exist is to make a
Pipeline running NAT respond to pings from the MAX side -- software
packages like 'Whatsup' can't tell if a circuit is down if my customer is
running with NAT.
So, the bottom line is, any further info on TR2928 would be nice.
Steve Camas
Long Island Information Inc. (516/718)INTERNET
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>