Re: Migrating from PPP to DHCPo82

[Mark Smith <nanog () 85d5b20a518b8f6864949bd940457dc124746ddc nosense org>]

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.