[c-nsp] PPPoE efficiency

[insan praja]

Thanks Anton
--- Anton Kapela <tk at 5ninesdata.com> wrote:

> 
> > I'm currently designing canopy wireless network. 
> 
> If you can wait until version 8 software is
> released, you'll probably be
> more satisfied. Read further for more details.
> 
> > We are 
> > planning to occupy 100 users/AP, 6 APs/cluster and
> segment 
> > the network using cisco routers. I'm looking for a
> way to 
> > authenticate, authorize and allocate bandwidth
> usage to the 
> > clients. I've heard about PPPoE, I just don't
> think that its 
> > efficient enough to use in canopy wireless
> networks. 
> 
> With approximately 8 more bytes of overhead per
> frame, I cannot imagine
> this overhead will be felt. Also, canopy supports
> >1518 byte frames, so
> in theory you could up the MTU's of your CPE
> router(s) if you wanted to
> avoid shenanigans like tcp mss adjustment, etc. 
> 
> > I know 
> > this is a Cisco forum, I just thought that you
> guys had some 
> > experiences with this.
> 
> My experience with canopy multipoint on 6.x and 7.x
> code has been
> favorable. The key issue at hand in canopy canopy
> deployment is  a lack
> of 'subscriber to subscriber' layer-2 isolation.
> Version 8 will finally
> see some new smarts added to support things like
> 'rfc1483 half-bridge'
> behavior. The goal here is to ensure that any
> unicast frame sent from a
> customer SM cannot be switched towards any other
> users SM directly on
> layer 2. The same goes for any broadcast or
> multicast frames sent from a
> customer SM; these should also not be re-propagated
> down to other SM's. 
> 
> The only way to achieve this behavior today using
> 7.x software would be
> to configure a vlan per customer SM and create
> (perhaps bulk-create on
> 12.3T or later with 'range' command support) several
> hundred vlan dot1q
> subints, essentially providing isolated layer-2
> space per customer SM.
> From here, you could simply use DHCP, or enable
> (again, enabled per vlan
> subint) a PPPoE listener within each subint. For
> more coverage of what
> I'm referring to, see [1].
> 
> Back to your original point; how to authenticate and
> allocate bandwidth.
> I can see definite merit in using existing radius
> backends via pppoe to
> support this, however, I'd strongly suggest you
> check into the BAM
> software for canopy. Fwiw, BAM also supports user
> auth via radius, as
> well as it's own user database. At any rate, a key
> issue with nearly
> every multi-access radio is upstream contention. I
> would not suggest
> that folks rely on virtual templates/dialer
> interfaces on cisco to take
> care of bandwidth shaping; this puts the bottleneck
> too far upstream of
> the user. Bandwidth shaping should happen, imho, as
> close to the user as
> you can achieve. Essentially, a user could sit on
> their upstream at
> whatever the air-rate happens to be, only being
> limited once the pppoe
> frames get to the concentrator. 
> 
> So, when it comes to canopy, look to do whatever you
> can on the air link
> directly (bandwidth, auth, etc), and pay close
> attention to the use of
> vlans for l2 isolation.
> 
> -Tk
> 
> [1]
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft
> /123t/123t_4/gtunvlan.htm
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com