North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
RE: NAT for an ISP
- From: William Devine, II
- Date: Wed Jun 04 19:53:33 2003
We used to do NAT for DSL customers as well. We started with two T1's to
Verizon, Cisco 3620 for DSL only and had problems here and there (couldn't
stop packets between customers in the same bridge group, such as netbios
broadcasts but could ACL tcp/udp connections between them easily.) We
switched to a Riverstone 8600 with an ATM DS3 from Verizon, moved everyone
over, and now don't do NAT for our customers at all. We provide the
customer with an ATM DSL Modem (Verizon provides Westells with ethernet &
USB.) Residential users are self-install almost always, except those that
want to pay a decently high install charge. Business users are always
charged a high enough install charge to do one quick wire drop or extension
& once DSL is verified operational, everything else is charged $85/hr. We
don't provide nor install a router for customers flat fee, only our regular
rate. When (not if) their $65 Linksys NAT Router has fits and overheats or
they touch it and it breaks, they pay a service charge to fix the problem.
By doing NAT ourselves, customers didn't need a router and thus did not need
us to provide any onsite networking services. Our consulting income has
increased noticeably since we don't do NAT and require customers to provide
their own NAT Router if they want one.
Why am I telling you this? If you're doing NAT for your customers,
providing vlan's across multiple DSL circuits to create an effective vlan
between offices, or doing all of the services for your customers on YOUR
router, you don't get to charge them for selling them hardware VPN routers
and configuring a VPN between them all. Business like buzzwords like VPN,
firewall, encryption & NAT, and they're more than willing to buy a $200
snapgear or $800 PIX 501 (w/3DES) to have their onsite firewall that
encrypts all data across their DSL circuit through a VPN tunnel to their
other offices, EVEN though it's going through the same router on your end
and on it's own VLAN where other clients can't possibly see it, AND you're
doing NAT for it so the outside world can't see it. Doesn't matter, you
MAKE NOTHING if you do it all on your router. You still get to manage their
router, firewall, whatever AND you get paid for it, AND you sell more of
them (one per site)
I know I don't run a non-profit and finding out that your customers don't
expect you to (at least most businesses :-P ) is a nice thing.
From: email@example.com [mailto:firstname.lastname@example.org]On Behalf Of
Sent: Wednesday, June 04, 2003 5:24 PM
To: Dan Armstrong
Subject: Re: NAT for an ISP
On Wed, 4 Jun 2003, Dan Armstrong wrote:
> More stuff to manage if we push it out to the CPE.
> I know this is mean to say, but most customers are STUPID and keeping it
> centralized reduces our support load. Give them enough rope, they hang
> themselves. We used to do lots more on the CPE, but between bad power
> supplies, lost passwords, software upgrades, "power users", etc. we find
> time is better spent managing it all centrally.
Well, wait. You either manage their router or you don't. I'm not
following...so in your new setup where YOUR routers manage NAT, you now
refuse to fix a problem on the CPE? If you manage the router, so they
don't get a password, then do NAT there, at the CPE. If you don't manage
the router, not having NAT on the CPE does nothing for you anyway, you
still have the issue of stupid users breaking things.
> Also, customers might exist in several locations, we can give them the
> 1918 network in all locations, run NAT for them, do VPNs for them, bring
> L2TP DSL into the fray, and only bill them for traffic that goes "out to
> Internet" quite easily.
Why would you want to only bill them for the egress bandwidth? You should
be finding reasons to make that impossible, not the other way around. You
running a non-profit over there? You seem to assume a network with a
single NOC...I don't want to pay to backhaul Joe's file and print sharing
between states so that he won't have to.
As for the other reasons, still not convinced. This isn't as whacky as the
guy who runs his entire ISP behind a NAT box, but I still don't see what
efficiency you've created. The things you mention could be solved in other
> (apologies to vendors watching) but I really think this "push intelligence
> out to the edge" concept is entirely vendor invented to sell more stuff.
> There are more edge devices than core devices.....
How do you figure? The customer needs a router, period. Whether or not you
do NAT on your router or their router should be a function of how much
other stuff your router does.
If the customer needs a router regardless, there are no more devices being
If you have to fix CPE problems unrelated to NAT _anyway_, why create
potential problems at your edge (let's set ourselves up for a multi-day
outage for most of our high-margin customers!) by doing the NAT for them,
when you could push that to their router?
Hell, unless there is a DOS underway, we make our customers filter there
own packets too. Why? That's the way it should be done.
I'll repeat your last sentence: "There are more edge devices than core
devices"...yes, and more CPEs than edge devices. That's hierarchy at
work...the point is that "work" (anything other than forwarding packets)
must be pushed as far away from the core as possible.
Furthermore, there's a general principle of "easy to manage, easy to
break" at work here. Implement NAT in one box, if NAT breaks, every single
customer attached dies. Implement NAT in one box for each customer, and if
NAT breaks, a single customer dies.