Are we talking business grade DSL or Resi grade DSL?
Hello,
Business grade. And it was suggested that I follow up with more specific
location.
California, San Francisco bay area.
Thanks,
Michael...
Jason Lixfeld wrote:
Are we talking business grade DSL or Resi grade DSL?
Residential DSL is typically a bridged solution, meaning you don't
even get to use a router... which renders the answer to this question a
moot point...
Why?
You can announce the space on the clients' behalf...
I said
> Residential DSL is typically a bridged solution, meaning you don't
> even get to use a router... which renders the answer to this question a
> moot point...
Alex Rubenstein questioned:
Why?
You can announce the space on the clients' behalf...
Ok, and what will they do with it, since I don't know of any residential
DSL services that offer routing?
**SJS (who is apparently missing something obvious)
Just becuase the medium is a layer 2 bridge between you doesn't mean they
couldn't stick a cisco xxxx and run BGP on the other end, ethernet to
'ethernet (really BVI).
ISP>-atm0------|DSL Cloud|-------|DSL bridge|-----e0-|cisco something|
Just becuase the medium is a layer 2 bridge between you doesn't mean they
couldn't stick a cisco xxxx and run BGP on the other end, ethernet to
'ethernet (really BVI).ISP>-atm0------|DSL Cloud|-------|DSL bridge|-----e0-|cisco something|
Why not just find someone else willing to advertise your /24 and tunnel
your packets to you?
DS
Why not just find someone else willing to advertise your /24 and tunnel
> your packets to you?
Because he'd be using three times as much bandwidth, perhaps?
-Bill
Why not just find someone else willing to advertise
your /24 and tunnel
your packets to you?
Because he'd be using three times as much bandwidth, perhaps?
-Bill
Three times as much is absolute worst case. In reality, it's more like
twice as much for just his incoming traffic. In any event, an entry in the
global routing table for a DSL line is not exactly polite networking anyway,
so what's a bit more excess?
DS
Three times as much is absolute worst case. In reality, it's more like
> twice as much for just his incoming traffic.
Uh, how do you figure? Each inbound packet comes into the tunnel-host
site, out of the tunnel-host site, and into the DSL host site. Each
outbound packet takes the reverse path. Three times as much bandwidth.
-Bill
[ On Monday, March 26, 2001 at 08:53:08 (-0800), Bill Woodcock wrote: ]
Subject: RE: dsl providers that will route /24
> Three times as much is absolute worst case. In reality, it's more like
> twice as much for just his incoming traffic.Uh, how do you figure? Each inbound packet comes into the tunnel-host
site, out of the tunnel-host site, and into the DSL host site. Each
outbound packet takes the reverse path. Three times as much bandwidth.
Well, yes, but only if the tunnel host has only one network connection.
If the tunnel host is also connected to the same DSL network then things
are just peachy for both parties and the DSL provider sees almost none
(just that which is NAT'ed) of the DSL user's bandwidth on their
upstream(s) (though the DSL user's bandwidth in either direction will be
limited to the lower of either the tunnel host's primary upstream link,
or the uplink bandwidth of the tunnel host's DSL connection).
This can still be a great benefit to a small network, especialy if the
DSL provider has a nice big HTTP cache and maybe an NNTP server too,
etc.
I ran my home network with basically this setup for over a year on a
cable modem and other than the fact that the cable provider has an
extrememly broken internal network (7% *minimum* loss!), I had great
success.
> Three times as much is absolute worst case. In
>reality, it's more like
> twice as much for just his incoming traffic.Uh, how do you figure? Each inbound packet comes into the tunnel-host
site, out of the tunnel-host site, and into the DSL host site. Each
outbound packet takes the reverse path. Three times as much bandwidth.-Bill
Each inbound packet goes from its source to the tunnel-host, then from the
tunnel-host to its destination. That's two transits instead of one. If the
tunnel-host is very close to the destination, the added leg will tend to be
less than the first leg, so even a doubling may be an overestimate.
As for outbound packets, why do they need to take the reverse path? There's
no reason the tunnel can't be unidirectional. Even if the ISP is stupid and
filters its customers' legitimate traffic, forcing them to encapsulate the
outbound packets, the same argument still applies.
Obviously, you have to choose a tunnel-host wisely. Ideally, you would pick
one that meets your DSL provider very closely.
In any event, the argument that VPNs "waste Internet bandwidth" rings
pretty hollow. People buy Internet access to have Internet bandwidth to use
for whatever applications they have. Heck, I would argue that USENET is the
biggest waste of Internet bandwidth there is. That doesn't mean it should go
away.
DS
I think you're getting caught up in semantics here. You're arguing about
total bandwidth used on the Internet (let's say amount of data times
distance traveled, for lack of a better metric), which will vary highly
depending on the individual setup. Bill is talking about the amount of
data sent over customer local loops, which in many (but of course not all)
Internet access billing arrangements is what costs the customer money.
Anyhow, quibbling over exact usage measurements doesn't really detract
from Bill's main point, that tunneling in and out of one network to get to
another uses more resources than not doing so.
Hopefully we can all agree that tunnels/VPNs/whatever you want to call
them use some resources, are extremely useful in some situations, but
aren't the best solution for every possible problem, without having to get
into yet another huge flame war.
-Steve
Ummm, s/if the ISP is stupid/if the ISP is doing the right thing/
You do filter what source addresses your customers can use, don't you?
No, I don't. If I see illegitimate traffic, I block it. If I see suspicious
traffic, I investigate it. But I give my customers the benefit of the doubt.
They pay me for Internet access. That means they can do whatever they want
with the Internet provided it's legal and doesn't impose an undue burden on
anyone else using the Internet. A one-way VPN is a legitimate use and
shouldn't be subject to prior restraint.
On the other hand, if I saw a customer abusing this privilege, I would
definitely *NOT* respond with a filter (except maybe as a stopgap until I
could contact the relvant administrators). The fact is, silently covering
over a problem doesn't help anyone. In specific, it doesn't help my customer
find the problem, which is most likely a root compromise on one of their
machines.
It is, IMO, stupid to hide a serious problem with a filter. That won't make
the problem go away. In this instance, the problem is a compromised machine,
a misconfiguration, or a customer who is trying to launch network attacks.
I'm sure we've all heard stories of major network disruptions being caused
by this type of filtering policy. ISP1 filters routes it hears from
CUSTOMER1. So the fact the CUSTOMER1's filters are broken is never noticed.
Then one day, ISP1 accidentally breaks its filters. Boom!
Filtering should be a last resort if there is no other way to accomplish
the desired goal or where small misconfigurations on the other end have the
ability to cause massive damage in a very small amount of time. Filtering
should _never_ be used to hide a real problem unless there is absolutely no
other option. In this case, there are *many* other options.
DS
On Tue, Mar 27, 2001 at 01:22:26PM -0800, David Schwartz had this to say:
They pay me for Internet access. That means they can do whatever they want
In the interests of preserving bandwidth (and Susan's sanity 
) can we
please head off this religious war before it starts again? We have flamed each
other about this at least 3 times in the past 6 months already (e.g. the "they
pay me, they can do what they like" vs. "enforce the Right Thing" argument)
I'm sure we've all heard stories of major network disruptions being caused
by this type of filtering policy. ISP1 filters routes it hears from
CUSTOMER1. So the fact the CUSTOMER1's filters are broken is never noticed.
Then one day, ISP1 accidentally breaks its filters. Boom!
Um, look at what you wrote. Filter breaks, Boom.
We egress filter on our customers routers and ingress filter on our
routers. That way, in the event of either breaking down, there is
(hopefully) still an appropriate filter in place to prevent a Boom!
Filtering should be a last resort if there is no other way to accomplish
the desired goal or where small misconfigurations on the other end have the
ability to cause massive damage in a very small amount of time. Filtering
should _never_ be used to hide a real problem unless there is absolutely no
other option. In this case, there are *many* other options.DS
Forgive me if I (and the vast majority of the network ops I know) don't
subscribe to this point of view. Filter, Filter, Filter. If you want to
know about broken customer filters, filter on their ingress to your
network with logging.
Flat out not filtering just so you know when "there is a problem" is, in
my humble opinion, irresponsible network administration.
> I'm sure we've all heard stories of major network
> disruptions being caused
> by this type of filtering policy. ISP1 filters routes it hears from
> CUSTOMER1. So the fact the CUSTOMER1's filters are broken is
> never noticed.
> Then one day, ISP1 accidentally breaks its filters. Boom!
Um, look at what you wrote. Filter breaks, Boom.
Exactly, because the presence of the filter allowed the actual problem to
be ignored. In this case, the error isn't in applying the filter --- you
have to in this case because too much damage could be done too quickly
without it. The error was in pretending that the filter solved the problem.
We egress filter on our customers routers and ingress filter on our
routers. That way, in the event of either breaking down, there is
(hopefully) still an appropriate filter in place to prevent a Boom!
Do you confirm that the egree filters are working? Or do you assume that
the presence of the ingress filters allows you to not worry about it?
Filters are a necessary tool in cases where large amounts of damage can be
done in very small amounts of time. But they don't solve any actual
problems, they just minimize the damage.
> Filtering should be a last resort if there is no other way
> to accomplish
> the desired goal or where small misconfigurations on the other
> end have the
> ability to cause massive damage in a very small amount of time.
> Filtering
> should _never_ be used to hide a real problem unless there is
> absolutely no
> other option. In this case, there are *many* other options.
Forgive me if I (and the vast majority of the network ops I know) don't
subscribe to this point of view. Filter, Filter, Filter. If you want to
know about broken customer filters, filter on their ingress to your
network with logging.
The problem is, the filter will block legitimate traffic. IP does not
provide any sure way to tell a spoofed packet from an unspoofed packet.
Do an informal survey. Ask network operators who ingress filter whether
they log and investigate packets that hit the filter. I will bet you that
more than 2/3 say they don't. In other words, the filter substitutes for
fixing the problem, and the problem could be as serious as a root
compromise.
Flat out not filtering just so you know when "there is a problem" is, in
my humble opinion, irresponsible network administration.
That's not the reason I don't filter. I don't filter because the filter
will stop legitimate traffic and isn't necessary if the network is
competently administered. So long as you can quickly resolve the problem
when there is actual abuse, the filter is not the right solution.
DS
The problem is, the filter will block legitimate traffic. IP does not
provide any sure way to tell a spoofed packet from an unspoofed packet.
Hmm.. if I *know* that my customer has a single-homed /24, and I see a
packet come in from his /24 that has a source address outside that /24,
there's a *pretty* *good* chance that something squirrely is going on.
But we *know* that this crowd is a "tough room" - we just *had* a flame
fest regarding filtering RFC1918 addresses. So I won't go there again. 
Do an informal survey. Ask network operators who ingress filter whether
they log and investigate packets that hit the filter. I will bet you that
more than 2/3 say they don't. In other words, the filter substitutes for
And a survey of DNS servers quite recently showed that 16% still haven't
upgraded to non-hackable versions of BIND. A lot of people drive without
seat belts too. Just because 2/3 of a group do something doesn't mean
it's a good idea.
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech