[c-nsp] Forcing PPPOE on Interface

[Eric Helm]

Paul,
Both Canopy and Trango have filters you can put on the Subscriber gear
to allow only PPPoE traffic to pass, and still allow the Management IP
that resides on the RF side. I recommend setting these up, as they will
also help prevent some of the other issues on a bridged network, such as
unintentional (or intentional) DHCP servers, broadcast storms, etc.

/Eric

Paul Stewart wrote:
> Thanks for the input...
> 
> I should have picked a more generic example...;)  A major part of our
> wireless network is also Trango powered so I was hoping to find
> something on the Cisco side of things to control this.... is there
> anything that could be done when the wireless gear does *not* support
> VLAN'ing?
> 
> Appreciate it...
> 
> Paul
>  
> 
> -----Original Message-----
> From: Anton Kapela [mailto:tk at 5ninesdata.com] 
> Sent: Wednesday, November 22, 2006 2:32 PM
> To: Paul Stewart; cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] Forcing PPPOE on Interface
> 
>  
> 
>> 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
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>