Because everything is tunneled over the PPP connection. Each client connects
via a dedicated tunnel to the PPP Server, which performs all the requests on
teh clients behalf (for instance answering ARP requests - Proxy ARP's). It's
better to visualise a PPP session as a link between the customer and the PPP
Server, as opposed to the current way which is the Customer --> Access Point
then ---> NOC/Shaping system. To illustrate:


Customer PC<=============================>ROUTER (Logical Layout in PPP)
Customer PC<----->CPE<---->AP<---->SWITCH<---->ROUTER (Physical Layout)

Because *All* client traffic is *forced* down the PPP tunnel (ICMP, et al),
you have full control over what your customers can and cannot do. For
instance, when they reach the PPP Server (Access Concentrator) - All Netbios
(Windows File & Printer Sharing) can be blocked, all ICMP traffic could be
blocked (if you wanted), All packets can be shaped so the customer can only
transmit/receive at the alloted bandwidth, you can also block virus
prolifiration ports. If you are running a pure Layer 2 Network (I.e. teh
only router is at your NOC), then this would be ideal because each client
that connects will go through the PPPoE server at the NOC. Think of it as a
transparent proxy server, Basically thats what it is. PPP is NOT IP traffic,
PPP is an encapsulation protocol (like a bucket which you can fill with many
things).

Just for your info, 99.9% of routers support PPPoE, - Most DSL ISP's use
PPPoE or PPPoA for authenticaing and controlling their customers. Because
you have a fixed point which concentrates access, you have a high degree of
control over your network. Also, you can 'share' a PPPoE connection via
Windows ICS - negating the need for cheapskates who don't want to buy a
router.

Regards

Colin




----- Original Message -----
From: "Roger Howard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 10, 2003 4:58 PM
Subject: Re: [smartBridges] sB Network Issue


> How can PPPoE stop a client from sending out ICMP echo requests? If the
> traffic gets dropped at the NOC queue then that customer can still tie up
> all the air time of the access point and bring the wireless side of the
> network to it's knees. It keeps pinging whether it gets a response or not,
> whether the packets are dropped somewhere or not.
>
> I am looking into using PPPoE, I might set this up yet.
>
> Thanks,
> Roger
>
> ----- Original Message -----
> From: "Colin Watson" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, November 10, 2003 10:24 AM
> Subject: Re: [smartBridges] sB Network Issue
>
>
> > Or, C) Use PPPoE :)
> >
> > PPPoE overcomes all these problems, it also ensures you remove IP
traffic
> > from your client <-> AP wireless link (You tunnel everything over PPP).
> > Basically, if you use PPP you get to control the entire connection, from
> the
> > IP leasing (So the user hasn't gotta configure anything, cept press
> > Next->Next->Next), dns servers, and netmask. In addition you get all the
> > logging functionality (if you auth to a radius server). The other (and
the
> > one I imagine you are most interested) is the ability to traffic limit.
> > Because all traffic *has* to go through the PPP Tunnel, your client can
> only
> > receive teh bandwidth you have designated him/her. So if one of the
> buggers
> > contracts a nasty strain of MSBLaST, and are paying for a 128/128
> > connection, then they will only be able to spew traffic out at 128K - no
> > more, because the rest will get dropped at the NOC's queue. Also, it
means
> > clients can communicate with each other, even when Interlcient
> communication
> > is disabled - but only at the bandwidth they are paying for - So no one
> can
> > hog all the air bandwidth - Really is a fantastic System :)
> >
> > Regards
> >
> > Colin.
> >
> > ----- Original Message -----
> > From: "Roger Howard" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, November 10, 2003 5:04 AM
> > Subject: [smartBridges] sB Network Issue
> >
> >
> > > One of the problems I seem to be facing frequently these days is that
a
> > > single customer can get a virus and generate tremendous amounts of
> > traffic,
> > > which brings the whole network to a crawl. Normally bandwidth shaping
at
> > the
> > > NOC will limit the amount the customer can transmit, due to the
> > Transmission
> > > Control Protocol part of TCP/IP. But if it is something like the
> > Nachi.worm
> > > it is ping packets which do not have transmission control and can be
> > spewed
> > > out at tremendous rates that no bandwidth shaper can control. So
what's
> > the
> > > solution to stop these slowdowns and outages caused by these viruses?
> > >
> > > A) Reduce the customer's functionality by insisting they use a router
or
> > > firewall.
> > > B) Have bandwidth shaping at the CPE.
> > >
> > > Personally I prefer B.... but that seems to be expensive, usually.
> > > Smartbridges, it might be something you can include in your Nexus
> product?
> > >
> > > Thanks,
> > > Roger
> > >
> > > The PART-15.ORG smartBridges Discussion List
> > > To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe
> > smartBridges <yournickname>
> > > To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe
> > smartBridges)
> > > Archives: http://archives.part-15.org
> > >
> > >
> >
> >
> >
> > The PART-15.ORG smartBridges Discussion List
> > To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe
> smartBridges <yournickname>
> > To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe
> smartBridges)
> > Archives: http://archives.part-15.org
>
> The PART-15.ORG smartBridges Discussion List
> To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe
smartBridges <yournickname>
> To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe
smartBridges)
> Archives: http://archives.part-15.org
>
>



The PART-15.ORG smartBridges Discussion List
To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe smartBridges 
<yournickname>
To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe smartBridges)
Archives: http://archives.part-15.org  

Reply via email to