cfrantse@csc.com writes:
> About CNAT, the main problem as we see it is that customers are
> using networks such as 172.16.0.0/16. This means we have to have a
> huge adress space to be able to cover all customers since we have a
> policy that states that no RFC1918 address space shall be imported
> into the management network.
Ding! Yes, traditional network tools like netview have problems
in this sort of service provider environment.
> I haven't used CNAT personally, only read the documentation so maybe
> I have missed something?
CNAT works well provided you have a NAT address space you can
control--because you have to maintain the unique mapping. If you're
working with privately addressed environments that can use any of the
private address space they want, you're indeed in quite a pickle. If
you have N customers each using an unregulated private address space
that's Y big, you'll need an address space of N*Y to map into... and
well, in general, no one's gonna have that. :-)
CNAT, therefore, has as a tacit requirement that you have some sort of
control of your address space....and have enough IP's to map into.
I don't see a way around dedicated NetView servers.
How's the budget? Some big iron would fix ya--an s/390 server and
slap several instances of NetView for zOS Integrated TCP/IP Services
7.1.3 ("netview for zLinux") on that puppy and create a Linux virtual
machine for each private address space, run DNS in each virtual server
to get your events populated with hostnames that are
customer-specific, then have them all forward events to a common TEC.
I even think the licensing of that product is such that you don't get
with with a per-instance license fee....
Caveat: I own IBM stock. Buy two s/390's -- they're small.
Best Regards,
--
Todd H
http://www.toddh.net/
|