Migrating from PPP to DHCPo82
Hi list I work for an small ISP, which does traditional xDSL service with PPPoE. Currently we are in the process of migrating most of our customers to DHCP (some customers are getting new CPEs and some will be sw upgraded remotely ). It would be great if someone has the time to share their experience (on- or offline) from such a migration. Common pitfals and perhaps what whey would do differently "next time". I know that every network is different but I believe that there are some general concerns, specially around security of DHCP and security features for vendors around DHCP and DHCP snooping etc. What about 802.1x, is that generally being deployed with option82? Regards MKS
Hi,
I work for an small ISP, which does traditional xDSL service with PPPoE. Currently we are in the process of migrating most of our customers to DHCP (some customers are getting new CPEs and some will be sw upgraded remotely ). It would be great if someone has the time to share their experience (on- or offline) from such a migration. Common pitfals and perhaps what whey would do differently "next time". I know that every network is different but I believe that there are some general concerns, specially around security of DHCP and security features for vendors around DHCP and DHCP snooping etc.
option82 is great, but differs from vendor to vender - I use always a custom string. a pitfal is, when you try to give a dslam port a static ip with a isc-dhcpd, thats not possible. (I have modfied isc-dhcpd to have a fixed size option82 hardware type). also pools and leasetimes could be problematic, when getting low.
What about 802.1x, is that generally being deployed with option82?
more security - but not always supported, I have not yet tested or needed this feature. Kind regards, Ingo Flaschberger
a pitfal is, when you try to give a dslam port a static ip with a isc-dhcpd, thats not possible. (I have modfied isc-dhcpd to have a fixed size option82 hardware type).
also pools and leasetimes could be problematic, when getting low. Can you elaborate a bit more on this issue? What is the difference between a low pool for PPPoE and DHCP?
Regards MKS
On 11/9/2010 3:24 AM, MKS wrote:
Can you elaborate a bit more on this issue? What is the difference between a low pool for PPPoE and DHCP?
That may be implementation specific, or a reference to high IP rotation rates (which I like). PPPoE doesn't change it's IP as long as a connection is established. DHCP can change at the half life of the lease time. In my case, end systems which are currently busy will hold their lease in 10 minute intervals (I think it's 10) until that transmission is complete, and then it will renew to the new IP. There were a few legacy systems which didn't like changing IPs with 1 hour leases, but those are now obsolete and I haven't heard of a problem in years. I expect new IPv6 support on CPEs to return to the old days of being horribly broken and have to work their way up to sanely handling renumbering (especially with DHCPv6-PD). Jack
On 11/8/2010 9:40 AM, MKS wrote:
I work for an small ISP, which does traditional xDSL service with PPPoE. Currently we are in the process of migrating most of our customers to DHCP (some customers are getting new CPEs and some will be sw upgraded remotely ). It would be great if someone has the time to share their experience (on- or offline) from such a migration. Common pitfals and perhaps what whey would do differently "next time". I know that every network is different but I believe that there are some general concerns, specially around security of DHCP and security features for vendors around DHCP and DHCP snooping etc.
While I'm looking at running option-82 (have limited support in a few places), I generally run q-in-q providing 100% isolation of customer ports. This gives me the same protections and tracking that PPPoE or ATM give me. This also allows me to turn off the security of the DSLAM and handle all security at the router level. There are a few deployments we have where q-in-q isn't possible (poor dslam implementations), and we have utilized dslam security (dhcp snooping, but currently security breaks IPv6 til the DSLAM gets a future code update) + option 82 in those cases. A few don't support option-82 or q-in-q, and those generally are static assignments in a CPE. The only benefit I've ever seen for PPPoE/A is dslam agnostics and uniform support across all vendors. It has the downside of having to terminate PPPoE/A on a cpe device. DHCP requires a plan with DLSAM and router support. Cisco simple (ip unnumbered vlan feature w/ q-in-q, 1 subint per customer, snmp probe every 5 minutes for the routing table to store IP->MAC->subint in a database). The only reason I've considered adding option 82 is to reduce the waste caused by probing (ie, an IP won't change without the DHCP request, so option 82 lets me get more granular and not probe). Jack
Hi Jack, On Mon, 08 Nov 2010 10:36:45 -0600 Jack Bates <jbates@brightok.net> wrote:
On 11/8/2010 9:40 AM, MKS wrote:
I work for an small ISP, which does traditional xDSL service with PPPoE. Currently we are in the process of migrating most of our customers to DHCP (some customers are getting new CPEs and some will be sw upgraded remotely ). It would be great if someone has the time to share their experience (on- or offline) from such a migration. Common pitfals and perhaps what whey would do differently "next time". I know that every network is different but I believe that there are some general concerns, specially around security of DHCP and security features for vendors around DHCP and DHCP snooping etc.
While I'm looking at running option-82 (have limited support in a few places), I generally run q-in-q providing 100% isolation of customer ports. This gives me the same protections and tracking that PPPoE or ATM give me. This also allows me to turn off the security of the DSLAM and handle all security at the router level.
There are a few deployments we have where q-in-q isn't possible (poor dslam implementations), and we have utilized dslam security (dhcp snooping, but currently security breaks IPv6 til the DSLAM gets a future code update) + option 82 in those cases. A few don't support option-82 or q-in-q, and those generally are static assignments in a CPE.
The only benefit I've ever seen for PPPoE/A is dslam agnostics and uniform support across all vendors. It has the downside of having to terminate PPPoE/A on a cpe device. DHCP requires a plan with DLSAM and router support.
Cisco simple (ip unnumbered vlan feature w/ q-in-q, 1 subint per customer, snmp probe every 5 minutes for the routing table to store IP->MAC->subint in a database). The only reason I've considered adding option 82 is to reduce the waste caused by probing (ie, an IP won't change without the DHCP request, so option 82 lets me get more granular and not probe).
Couple of questions if you don't mind. Firstly, is your customer base primarily residential or is it SOHO/SME business (or something else entirely) ? Secondly, would I be right if I assume that you pre-allocate and pre-configure the Q-in-Q id's per customer? Or are they some how dynamically allocated or configured (maybe just on the BRAS, not on the DSLAM), and reported via something like RADIUS? Something like the latter (if it exists) would make it easier to handle residential style/size customer bases. Thanks, Mark.
On 11/9/2010 3:01 AM, Mark Smith wrote:
Firstly, is your customer base primarily residential or is it SOHO/SME business (or something else entirely) ?
At that level, the customers are those of a traditional rural ILEC, which means all of the above.
Secondly, would I be right if I assume that you pre-allocate and pre-configure the Q-in-Q id's per customer? Or are they some how dynamically allocated or configured (maybe just on the BRAS, not on the DSLAM), and reported via something like RADIUS? Something like the latter (if it exists) would make it easier to handle residential style/size customer bases.
Good old script, c&p for all dslams/ports into the router. I manage the router while telco manages the dslam, so I am usually configured well before they are. IOS is extremely limited, though Cisco has mentioned more dynamic profiles in the ASR line. With my current Cisco setup, I'm screwed. The ASR w/ XE software has better support for radius backend. Juniper also has support for radius backends for their DHCP implementation. Both of course could do proxy, but I dislike the methodology. My rule is that the router should answer even if the pop is isolated, so when I do shift to radius, I will only accept an implementation that supports a default profile for when the radius servers are unreachable. This assists in troubleshooting and for pops that have local servers, it allows redirection for customer notification when there is an outage. I've a long standing of using 7200s with IOS, but it is lacking a lot of support which Cisco is only putting in the ASR. I'm also considering switching to a non-cisco solution. It's just a matter of finding something that will do exactly what I want. Many of these ILECs are single router setups, so replacing the 7200 or putting something beside it requires a lot of capability and flexibility (mpls, v6, rsvp-te, is-is, BGP, and the BRAS functionality). Jack
MKS wrote:
Hi list
I work for an small ISP, which does traditional xDSL service with PPPoE. Currently we are in the process of migrating most of our customers to DHCP (some customers are getting new CPEs and some will be sw upgraded remotely ). It would be great if someone has the time to share their experience (on- or offline) from such a migration. Common pitfals and perhaps what whey would do differently "next time". I know that every network is different but I believe that there are some general concerns, specially around security of DHCP and security features for vendors around DHCP and DHCP snooping etc.
We run PPPoE for the reasons that it's easier to manage and account for and does not rely on the middle layer for any security (implemented at the pppoe concentrator). There are also technical features we like, such as being able to route subnets easilly, and per-user filtering rules if necessary, as well as a high level of integration with radius that really makes things sing along. A downside is rampant poor, non-compliant and downright buggy pppoe client implementations. It's gotten better over the years with more linux replacing other embedded development tool sets but still, it's downright criminal sometimes what that lower end consumer junk does in the field - and ALWAYS, being resolved by pulling the power and cycling it... <sigh> I've recently implemented PPPoE Intermediate agent support as a patch against the opensource RP-PPPOE server software, along with documentation on integrating it with freeradius, and this enables you to ditch completely the username / password and just go with DSLAM port-id based authentication, reducing the strain on your support staff as end users forget or lose this otherwise most critical information. For anyone who cares, the code is on sourceforge - http://ilc-ppp.sourceforge.net Mike-
participants (5)
-
Ingo Flaschberger -
Jack Bates -
Mark Smith -
Mike -
MKS