On 1/25/2011 6:34 PM, Paul Stewart wrote:
PPPOE Pros
----------
Allows full authentication of customers (requires username/password)
Authentication isn't necessary if you have other methods of turning off a port. Authentication can actually be a Con, as the username/password can be forgotten and a truck rolled to reprogram a CPE because the user uses gmail (email often being the only other time the username/password is used).
Allows control over customer connections (suspend accounts, create accounts etc)
Depending on telco processes, this is easily handled in the DLC (often times combined with turning off their phone service).
Easily assign static IP to customer (no MAC address or CPE information required)
Option-82!
Assign public subnet to customer with ease (no manual routing required)
I'll give you this one.
IPv4/IPv6 fully supported on Juniper platform as required
I'm pretty sure it's supported for bridging/DHCP environments too.
Usage tracking (GB transfer) from radius generated data
It works, but there are other accounting methods.
PPPOE Cons
----------
Requires PPPOE termination router (Juniper ERX for example)
You're putting Juniper ERXs at customer houses? Really? I'd expect to see DSL/Cable drops which will utilize cheap end CPE (most of which don't support IPv6 hardly at all).
Requires Radius server(s) to assign and track customer IP assignments/usage
Customers require username/password to connect
Customers require PPPOE client software or router to connect
8 bytes MTU overhead
The 8 bytes usually isn't too bad and is counteracted in bridging environments by vlan tags (often dual tagged for proper isolation). You can usually set the MTUs 8 bytes larger to compensate and still allow 1500 byte IP packets.
DHCP Pros
---------
Simplistic - plug and play 90% of the time
Not when it's done right.
No MTU overhead, full 1500 MTU frame size
Yes and no. When you run vlan tags, it's a bit more complex. If using ATM termination, it's less complex.
DHCP Cons
---------
No authentication occurs (anyone physically connected can use Internet generally)
For consumer use, not a concern. Hijacking a phone line, for example, may get you connected, but you've also broken the customer's connection. If you are on site, plug in behind the CPE and you're golden either way.
No user tracking without tracking customer CPE MAC addresses
option-82, and when I do track, I track IP -> MAC -> Interface. The MAC is just because customers ask which MAC. I only really care about IP -> Interface.
No usage tracking builtin to DHCP (GB transfer) Granted.
There are several factors involved here. The first major thing is that we believe the customer wants to move towards caps on their customer usage (X amount of GB per month). Today, they are doing static IP assignments but the interesting thing is that the CPE they have control over today (Comtrend routers with DSL modem builtin). I know there's not always a good vs bad here but looking for opinions from folks who may have already done this comparison for a "boardroom discussion"....
Over the last decade, I've been building out all DSL networks as ATM, 1 pvc per interface (cisco RBE ftw) and Double tagged vlans, 1 vlan per interface (cisco unnumbered subinterfaces ftw). Juniper has similar stuff. We utilize proxy arp for customer communications. This creates a fully isolated environment with the router handling all the security and provisioning. Massive configs as I have it currently, though templating and dynamic configurations with radius backends has been getting added into newer code (hear the ASR has some nice backend options). All DSL cpes provided by the telcos are in bridging mode only (even wireless model were bridged). Why did I do this? IPv6. Telcos who did not follow my advice currently have the following issues. 1) PPPoE, must now replace every customer CPE (given out for free, customer expects telco to pay for replacement). Every DSL modem vendor I've talked to has stated that IPv6 support will not be in the older CPEs. 2) DSLAMs without q-in-q support or extremely limited vlan support requiring the DSLAM to do DHCP snooping and it's own security. IPv6 does not work... Period. Code will have to be upgraded for each of these DSLAMs to support IPv6. Vendors currently don't support it, and word is vendors are changing to support more vlans quickly. :) Ideally? You are starting a brand new network with no broadband customers. You have an inexpensive CPE which already supports IPv6 beautifully. All network equipment supports baby giants, or even better, jumbo frames. You adjust the MTU, you run PPPoE w/ v4/v6 and 1500 byte IP packets. Have a nice day. If you don't have the benefit/capability, other options tend to be more cost effective. Jack