What are you doing to router subnets over PPPoE?
Are you assigning a RFC 1918 address with PPPoE, then routing the public subnet to the CPE or something similar? Or are you doing something entirely different?
-Eric
John Hokenson wrote:
You can route subnets over PPPoE if you want.
JH
----- Original Message ----- From: "Roger Howard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 10, 2003 10:39 AM
Subject: Re: [smartBridges] sB Network Issue
This is suddenly looking more attractive. I was going to persue routing
each
customer and providing a subnet of IP addresses to each one. I think I'll experiment with pppoe and see how it works out.
Thanks for the info. Roger
----- Original Message ----- From: "Colin Watson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 10, 2003 11:59 AM
Subject: Re: [smartBridges] sB Network Issue
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
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
