|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: NAT for an ISP
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. William -----Original Message----- From: [email protected] [mailto:[email protected]]On Behalf Of Andy Dills Sent: Wednesday, June 04, 2003 5:24 PM To: Dan Armstrong Cc: [email protected] 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 our > 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 same > 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 the > 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 ways. > (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 sold. 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. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
|