[c-nsp] Forcing PPPOE on Interface

[Scott Brown]

I am not sure if this will work in your case - but couldn't you create an
access-list that allows the few hosts in your xx.xx.xx.0/26 network, and
then denies any other address... Apply that ACL to the wireless facing
interfaces... Should you ever need another address - just add another entry
to the ACL...


Something we do every-so-often is not have a default-route out to the
Internet... So even if they set their address statically, they can't get to
the Internet, so they are basically screwed...

Scott Brown
Network Engineer
City of Sandy / SandyNet
sbrown at ci.sandy.or.us 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Paul Stewart
Sent: Wednesday, November 22, 2006 11:36 AM
To: Anton Kapela; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Forcing PPPOE on Interface

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/