[c-nsp] Forcing PPPOE on Interface

Anton Kapela tk at 5ninesdata.com
Wed Nov 22 14:32:04 EST 2006


 

> What I want to prevent is someone figuring out they could manually
> assign xx.xx.xx.50/26 on their system and bypass PPPOE all 
> together....
> we've tested this and it works....
> 
> Thoughts? ;)

I'd recommend using the canopy 'management vlan' as it was intended.
What I do is configure each of my SMs and APs with 'management vlan ID:
N' where N is something meaningful to each AP cluster/rooftop
area/domain where you have a router located. That is to say, we'll
assign vlan 10 as the management vlan on our agg router, and bind
something like 10/8 for management addresses. On each AP and SM we
deploy, we'll likewise set vlan ID 10 for 'management access' over the
airlink to that SM. This is part of our technicians standard process, so
it's no 'big deal.' It may represent a few extra emails or discussions
with your staff to cover this, but it's worth the effort. 

Once the SMs management IP's are in vlan id 10 (for example), you can
leave the customer port untagged/unbound to a vlan and simply pass your
PPPoE frames up to whatever untagged interface you're terminating on.
For extra points, configure per-customer (or at least per-access-type
vlans; i.e. PPPoE vlan, dhcp vlan, vlans for static-routed customers
with /30's, etc) access vlans starting now. Customer access then will be
'facing' a dry interface which is only listening for PPPoE, and they
won't be able to 'get out' as you describe, and you get the added
benefit of true user to user layer-2 isolation. Without this, users
could easily co-opt your AP for site-to-site transit, as they can "arp"
for each other and directly exchange layer-2 frames over the airlink. 

-Tk



More information about the cisco-nsp mailing list