Hey folks... I'm meeting with a customer tomorrow (service provider, rural telco) and we're pitching they move to a PPPOE platform most likely. But to be fair, I'm looking to draw up a comparison so they are "well informed" of the pros/cons. Has anyone done this? I came up with the following brief start: PPPOE vs DHCP PPPOE Pros ---------- Allows full authentication of customers (requires username/password) Allows control over customer connections (suspend accounts, create accounts etc) Easily assign static IP to customer (no MAC address or CPE information required) Assign public subnet to customer with ease (no manual routing required) IPv4/IPv6 fully supported on Juniper platform as required Usage tracking (GB transfer) from radius generated data PPPOE Cons ---------- Requires PPPOE termination router (Juniper ERX for example) 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 DHCP Pros --------- Simplistic - plug and play 90% of the time No MTU overhead, full 1500 MTU frame size DHCP Cons --------- No authentication occurs (anyone physically connected can use Internet generally) No user tracking without tracking customer CPE MAC addresses No usage tracking builtin to DHCP (GB transfer) 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".... Thanks ;) Paul
On Tue, 25 Jan 2011, Paul Stewart wrote:
I'm meeting with a customer tomorrow (service provider, rural telco) and we're pitching they move to a PPPOE platform most likely. But to be fair, I'm looking to draw up a comparison so they are "well informed" of the pros/cons. Has anyone done this?
Of course. There are plenty of ISPs doing ETTH with DHCP based solutions. and L2 and L3 switches for switching/routing. Only reason I would ever roll out PPP today is because of some regulatory demand to provide bitstream to others, and most likely not even then (there are better ways). Basically all your "con:s" on DHCP isn't true, they can all be solved and has been for 10 years by others. -- Mikael Abrahamsson email: swmike@swm.pp.se
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
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). No, we're not putting ERX's at people's homes ... not sure where you got that from? What I was saying is that if you're running PPPOE then you have have somewhere in the service provider network to "terminate" the sessions.... Paul
On 1/26/2011 8:12 AM, Paul Stewart wrote:
No, we're not putting ERX's at people's homes ... not sure where you got that from? What I was saying is that if you're running PPPOE then you have have somewhere in the service provider network to "terminate" the sessions....
Hey. It was the middle of the night. I completely misread which side of the termination you were referring to. Terminating PPPoE generally isn't much different than terminating VLANs. In Juniper world, it requires the right equipment. Cisco world, it's not generally a big deal. Jack
Terminating PPPoE generally isn't much different than terminating VLANs. In Juniper world, it requires the right equipment. Cisco world, it's not generally a big deal.
Unless, for example, you already sunk a chunk of change into Cisco 10Ks, and now want IPv6 on your PPPoE. Not that I'm becomming increasingly bitter about that platform or anything... Regards, Tim.
On 1/26/2011 9:36 AM, Tim Franklin wrote:
Terminating PPPoE generally isn't much different than terminating VLANs. In Juniper world, it requires the right equipment. Cisco world, it's not generally a big deal.
Unless, for example, you already sunk a chunk of change into Cisco 10Ks, and now want IPv6 on your PPPoE. Not that I'm becomming increasingly bitter about that platform or anything...
10K isn't supporting IPv6 on PPPoE? I thought the 10K specialized in utilizing the IOS SR line. I've played with PPPoE and bridging on the 7200s mostly. I need to kick up an ASR, as I hear it's specialized code line has much better IPv6 support than IOS SR. both XR/XE codes seem to be much more richly featured, especially for radius backending DHCP. Jack
10K isn't supporting IPv6 on PPPoE? I thought the 10K specialized in utilizing the IOS SR line. I've played with PPPoE and bridging on the 7200s mostly. I need to kick up an ASR, as I hear it's specialized code line has much better IPv6 support than IOS SR. both XR/XE codes seem to be much more richly featured, especially for radius backending DHCP.
So they're telling us, at least for PPPoE specifically. Cisco solution is "buy ASR". Regards, Tim.
On 1/26/2011 11:03 AM, Tim Franklin wrote:
So they're telling us, at least for PPPoE specifically. Cisco solution is "buy ASR".
This is same solution they've given for the 7206 and other traditional IOS platforms. I haven't checked, but all the RBE/unnumbered vlan support for IPv6 with proxy-ND, better radius backend for DHCPv6, and supposedly IA_TA support for DHCPv6 will be in the ASR only. The features in IOS SR train are somewhat functional but extremely limited. If I find myself having to spend money on ASRs, I may just spend the money replacing them with Juniper. Only reason I haven't is that I haven't needed to spend the money at all. Jack
If Cisco won't do a good job of RBE on the 7206VXR, I may just need to stick with PPPoEv6 on the SR train. I have that successfully working in a test bed. Frank -----Original Message----- From: Jack Bates [mailto:jbates@brightok.net] Sent: Wednesday, January 26, 2011 12:04 PM To: nanog@nanog.org Subject: Re: PPPOE vs DHCP On 1/26/2011 11:03 AM, Tim Franklin wrote:
So they're telling us, at least for PPPoE specifically. Cisco solution is "buy ASR".
This is same solution they've given for the 7206 and other traditional IOS platforms. I haven't checked, but all the RBE/unnumbered vlan support for IPv6 with proxy-ND, better radius backend for DHCPv6, and supposedly IA_TA support for DHCPv6 will be in the ASR only. The features in IOS SR train are somewhat functional but extremely limited. If I find myself having to spend money on ASRs, I may just spend the money replacing them with Juniper. Only reason I haven't is that I haven't needed to spend the money at all. Jack
By IA_TA support, do you mean the ability for the 7206VXR to act as the DHCPv6 server? If I understand you correctly, I have it working well with DHCPv6 relay. Frank -----Original Message----- From: Jack Bates [mailto:jbates@brightok.net] Sent: Wednesday, January 26, 2011 12:04 PM To: nanog@nanog.org Subject: Re: PPPOE vs DHCP On 1/26/2011 11:03 AM, Tim Franklin wrote:
So they're telling us, at least for PPPoE specifically. Cisco solution is "buy ASR".
This is same solution they've given for the 7206 and other traditional IOS platforms. I haven't checked, but all the RBE/unnumbered vlan support for IPv6 with proxy-ND, better radius backend for DHCPv6, and supposedly IA_TA support for DHCPv6 will be in the ASR only. The features in IOS SR train are somewhat functional but extremely limited. If I find myself having to spend money on ASRs, I may just spend the money replacing them with Juniper. Only reason I haven't is that I haven't needed to spend the money at all. Jack
On 1/27/2011 1:05 AM, Frank Bulk wrote:
By IA_TA support, do you mean the ability for the 7206VXR to act as the DHCPv6 server? If I understand you correctly, I have it working well with DHCPv6 relay.
Yeah, IA_TA is the temporary addresses (compared to prefix delegation). I haven't tested it with relay, as I've hoped to avoid that (hate depending on remote servers). I'm interested, though, if RBE and unnumbered vlans can be made to work with IPv6 even with the relay as they do in IPv4. Documentation leads me to believe they won't (given cisco docs state that they figured one prefix per subinterface and no proxynd as they did in IPv4). I guess you could possibly manually activate proxynd on each subinterface? I know the routing mechanisms themselves work, verified with prefix delegations. Jack
In article <051001cbbcf0$c33e8b20$49bba160$@org> you write:
PPPOE vs DHCP Allows full authentication of customers (requires username/password)
You probably want to authenticate on circuit id, not username/password. ATM port/vpi/vci for ATM connections, or PPPoE circuit id tag added by the DSLAM or FTTH access switch when using an ethernet transport layer. It's just a different radius attribute to authenticate on, no magic. We do that so a customer doesn't have to configure his/her router to get online.
Easily assign static IP to customer (no MAC address or CPE information required)
Don't need that with DHCP either, if you run a DHCP server that can assign IP addresses based on option82. I run a patched ISC dhcp3 server, but I understand that ISC dhcp4 makes this pretty easy
Assign public subnet to customer with ease (no manual routing required)
Don't need manual routing with DHCP either, if you use a real bras such as a juniper, since you can have it authenticate off radius first before doing DHCP, and in the radius reply you can return a static route.
Usage tracking (GB transfer) from radius generated data
True, at least juniper e-series BRASes don't send radius accounting for atm rfc1483/bridged connections for some reason.
DHCP Cons
---------
One more DHCP con is that if you have an ethernet transport network from the DSLAM or FTTH access switch to your router that lumps together multiple customers in one VLAN, something along the way is probably doing DHCP sniffing to set up routing. And you can be just about sure that won't work with IPv6. VLAN-per-customer will work (and is a really a great model, for all types of encapsulation) Mike.
I just wanted to say thank you for a TONNE of feedback I received on this topic. This has been of great help in filling in some items I missed in my quick list. Will try to respond offlist to several of you that responded - got over 100 replies offline with some interesting ideas. I definitely learned I should have made my original post a bit clearer though and specifically the usage tracking component ;) Normally I would post a summary on these kinds of topics but quite honestly there is such a huge varience in opinions and options around this that I'll probably just invite anyone to hit me offlist if they are interested in the feedback received so far... Thanks folks, Paul
Thank you for the response... I should have made this a bit clearer - option 82 is an option on their DSLAM's today and is supposed to work "not bad". But this customer may also be looking at other services such as wireless in the future which does not support option 82 - they want a unified delivery of their product. I left out this detail as you can see ;) Also, the comment " so a customer doesn't have to configure his/her router to get online" is also interesting - we WANT our customers to configure their routers and understand them to a basic degree... this coming from a security perspective where we are seeing a magnitude to customer routers getting hacked or their wireless left open etc. Usage based billing is a very hot topic in this area (Ontario, Canada) and we will confirm with the customer today that they do indeed want to track all GB usage per customer... Today, they have no interest nor can they get IPv6 which is a shame.... having said that, we want to provide a solution to them than can do IPv6 in the future... Thanks, Paul -----Original Message----- From: Miquel van Smoorenburg [mailto:mikevs@xs4all.net] Sent: Wednesday, January 26, 2011 4:16 AM To: paul@paulstewart.org Cc: nanog@nanog.org Subject: Re: PPPOE vs DHCP In article <051001cbbcf0$c33e8b20$49bba160$@org> you write:
PPPOE vs DHCP Allows full authentication of customers (requires username/password)
You probably want to authenticate on circuit id, not username/password. ATM port/vpi/vci for ATM connections, or PPPoE circuit id tag added by the DSLAM or FTTH access switch when using an ethernet transport layer. It's just a different radius attribute to authenticate on, no magic. We do that so a customer doesn't have to configure his/her router to get online.
Easily assign static IP to customer (no MAC address or CPE information required)
Don't need that with DHCP either, if you run a DHCP server that can assign IP addresses based on option82. I run a patched ISC dhcp3 server, but I understand that ISC dhcp4 makes this pretty easy
Assign public subnet to customer with ease (no manual routing required)
Don't need manual routing with DHCP either, if you use a real bras such as a juniper, since you can have it authenticate off radius first before doing DHCP, and in the radius reply you can return a static route.
Usage tracking (GB transfer) from radius generated data
True, at least juniper e-series BRASes don't send radius accounting for atm rfc1483/bridged connections for some reason.
DHCP Cons
---------
One more DHCP con is that if you have an ethernet transport network from the DSLAM or FTTH access switch to your router that lumps together multiple customers in one VLAN, something along the way is probably doing DHCP sniffing to set up routing. And you can be just about sure that won't work with IPv6. VLAN-per-customer will work (and is a really a great model, for all types of encapsulation) Mike.
http://www.cisco.com/en/US/products/hw/routers/ps295/products_configuration_... http://s-tools1.juniper.net/solutions/literature/white_papers/200187.pdf 3rd party vendors might want to have me onboard :-) otherwise you can come up w/ your own piece of kit, rfc' it and a few white papers bla and boom, start your own business like the others have done in the past .......... ________________________________ From: Paul Stewart <paul@paulstewart.org> To: Miquel van Smoorenburg <mikevs@xs4all.net> Cc: nanog@nanog.org Sent: Wed, January 26, 2011 1:40:49 PM Subject: RE: PPPOE vs DHCP Thank you for the response... I should have made this a bit clearer - option 82 is an option on their DSLAM's today and is supposed to work "not bad". But this customer may also be looking at other services such as wireless in the future which does not support option 82 - they want a unified delivery of their product. I left out this detail as you can see ;) Also, the comment " so a customer doesn't have to configure his/her router to get online" is also interesting - we WANT our customers to configure their routers and understand them to a basic degree... this coming from a security perspective where we are seeing a magnitude to customer routers getting hacked or their wireless left open etc. Usage based billing is a very hot topic in this area (Ontario, Canada) and we will confirm with the customer today that they do indeed want to track all GB usage per customer... Today, they have no interest nor can they get IPv6 which is a shame.... having said that, we want to provide a solution to them than can do IPv6 in the future... Thanks, Paul -----Original Message----- From: Miquel van Smoorenburg [mailto:mikevs@xs4all.net] Sent: Wednesday, January 26, 2011 4:16 AM To: paul@paulstewart.org Cc: nanog@nanog.org Subject: Re: PPPOE vs DHCP In article <051001cbbcf0$c33e8b20$49bba160$@org> you write:
PPPOE vs DHCP Allows full authentication of customers (requires username/password)
You probably want to authenticate on circuit id, not username/password. ATM port/vpi/vci for ATM connections, or PPPoE circuit id tag added by the DSLAM or FTTH access switch when using an ethernet transport layer. It's just a different radius attribute to authenticate on, no magic. We do that so a customer doesn't have to configure his/her router to get online.
Easily assign static IP to customer (no MAC address or CPE information required)
Don't need that with DHCP either, if you run a DHCP server that can assign IP addresses based on option82. I run a patched ISC dhcp3 server, but I understand that ISC dhcp4 makes this pretty easy
Assign public subnet to customer with ease (no manual routing required)
Don't need manual routing with DHCP either, if you use a real bras such as a juniper, since you can have it authenticate off radius first before doing DHCP, and in the radius reply you can return a static route.
Usage tracking (GB transfer) from radius generated data
True, at least juniper e-series BRASes don't send radius accounting for atm rfc1483/bridged connections for some reason.
DHCP Cons
---------
One more DHCP con is that if you have an ethernet transport network from the DSLAM or FTTH access switch to your router that lumps together multiple customers in one VLAN, something along the way is probably doing DHCP sniffing to set up routing. And you can be just about sure that won't work with IPv6. VLAN-per-customer will work (and is a really a great model, for all types of encapsulation) Mike.
We were a mostly PPPoA shop, and were doing PPPoE on our FTTH but moved to DHCP because of our desire to move to v6 without waiting for the access vendor and to get rid of supporting that username/password combo. And DSL modems that we're replacing in the field we're moving from PPPoA to PPPoE because of Ethernet transport because I'm not as sold on RBE in a 7206VXR, even though I really could use the same Option 82 in the same way as we do for FTTH. VLAN-per-user seems like a lot of router config overhead, though I could be proved wrong if I misunderstand. Frank -----Original Message----- From: Paul Stewart [mailto:paul@paulstewart.org] Sent: Tuesday, January 25, 2011 6:34 PM To: nanog@nanog.org Subject: PPPOE vs DHCP Hey folks... I'm meeting with a customer tomorrow (service provider, rural telco) and we're pitching they move to a PPPOE platform most likely. But to be fair, I'm looking to draw up a comparison so they are "well informed" of the pros/cons. Has anyone done this? <snip>
On 1/27/2011 1:09 AM, Frank Bulk wrote:
I'm not as sold on RBE in a 7206VXR, even though I really could use the same Option 82 in the same way as we do for FTTH.
What was your problem with RBE? I've loved it (except for the 3000 interface configs that take 3-5minutes to write). Jack
Hi, I have not seen this in the discussion yet. http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 CPE support does not seem to be very broad yet. As far as I can see there is almost PPPoE only for IPv6 in Europe. In Germany cable is a mess by regulation. So no cable/dhcp. There used to be a DTAG monopoly with aDSL only and PPPoE only. Most ISPs still rely on the DTAG infrastructure. That is why very PPPoE biased. There is a high concentration of AVM in the CPE with Infineon chipsets in both DSLAM and DSL-Modem / Router --- OT --- Living in the outback with DSL-1000 max I made some tests with CIS-modem, Broadcom Cipset (Hitachi) and Infineon/AVM. The CIS-modem is no longer sold but far superior to the others. I had trouble to get some of the Broadcoms working. Replacing the power supply unit (wallwart, not regulated) with a regulated and filtered 13.5 volts power supply unit for my hamradio both the bradcoms and the AVW worked almost a good as the CIS-modem. Some of you might remember tuneable hum noise in ancient am-radios. That noise could be cured by shunting the rectifiers with 4.7 nano farad capacitors. The spectrum of the modem shows a lattice that goes away with a reulated and filtered power source. Of coarse you cannot spend a week experimenting at any client site. So excuse the noise. --- /OT --- -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48
On Jan 27, 2011, at 8:03 PM, Peter Dambier wrote:
Hi,
I have not seen this in the discussion yet.
http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011
CPE support does not seem to be very broad yet. As far as I can see there is almost PPPoE only for IPv6 in Europe.
As long as there is an ADSL interface they usually support both, goes for major vendors as well as some smaller ones.
In Germany cable is a mess by regulation. So no cable/dhcp.
There used to be a DTAG monopoly with aDSL only and PPPoE only. Most ISPs still rely on the DTAG infrastructure. That is why very PPPoE biased.
There is a high concentration of AVM in the CPE with Infineon chipsets in both DSLAM and DSL-Modem / Router
Part of the DTAG modems seem to be 7570 based and for what I have been told by German friends these can be flashed to the standard production releases. Not of much use for native, but you will get tunnel support in the box. Marco
participants (9)
-
Frank Bulk -
isabel dias -
Jack Bates -
Marco Hogewoning -
Mikael Abrahamsson -
Miquel van Smoorenburg -
Paul Stewart -
Peter Dambier -
Tim Franklin