Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Nat won't, nailed ain't!
Darkshot <darkshot@chudys.com> writes:
> I've got 2 ISDN users (total) on one MAX 4K and both of them are
> using Pipeline 130 ISDN/BRI and NAT. When I tried to implement some
> static maps I found it didn't work, and I also found that I could
> not even ping their "real" IP address here. Other users/connections
> are pingable, but not these ISDN ones.
>
> These accounts are both nailed to a static IP address (each has a
> different one, of course) but it does not show up on the network,
> although the connections are active and working.
>
> I have a nailed (usually) analog connection at home, and it's pingable
> via the IP number, but of course it's not running NAT.
>
> I set up the NAT on both these 130's as per the instructions on
> Ascend's web site, and they're both running 5.1Ap6
As far as I understand NAT on the pipeline, an incoming ping just
doesn't work. Only TCP and UDP are supported as protocols eligible for
address translation inbound. Ping works outbound from a masqueraded
address, but ICMP-based traceroute programs (eg. Win95 tracert) only
seem show the last hop.
I'm not sure if the lack of incoming ping-ability is broken behaviour
or not: RFC1631 (NAPT) seems to be the closest thing to defining the
official spec. that I've seen. A cisco 2501 running IOS 11.2 seemed to
do the same thing: you couldn't ping the single 'public' address
(admittedly, though, the version I saw seemed to be cut down and
didn't support incoming static NAT maps either).
I've seen other reports of static NAT maps not operating properly on
the Pipeline, but I can confirm that in the P130 cases I've seen on
5.1Ap4, 5.1Ap9 and 6.0.X the static maps *do* seem to work without
grief.
The real problem is with the dynamic maps built for outgoing
connections - ie. the maps viewable via the diagnostic command
NAPT. There seems to be a static limit of 500 dynamic mappings across
the router at any one time - this would be fine, but the pipeline
doesn't seem to delete the mappings on the passing of a TCP RST or FIN
packet, instead letting them timeout after 24 hours. In my experience,
this usually tends to lead to a P130 refusing to map any more outgoing
connections for ~20 hours. For more details se:
http://www.noc.colt.net/ascend/grief/2.html
Ascend have no fix for this as I'm far as I'maware. If I were you I'd
steer clean of Ascend Pipeline Single-IP NAT with the possible
exceptions of single user setups where you could be fairly sure that
less than 500 TCP/UDP sessions within 24 hours would be required. :<
-- Adam.
++ 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:
References: