Re: DoS attacks, NSPs unresponsiveness

From: John Fraizer (no email)
Date: Fri Nov 03 2000 - 23:54:30 EST


On Fri, 3 Nov 2000, Joe Shaw wrote:

>
> > If they're filtering on the /19 or /20 boundry on legacy space, they're
> > VERY misconfigured and breaking a whole bunch of connectivity.
>
> I thought filtering at /19-/20 space was still considered best common
> practice by some of the older Tier 1's who were interested in keeping the
> routing tables small. Maybe with less legacy equipment deployed this
> isn't an issue anymore.
>

I don't think it's a matter of legacy equipment and many networks do
filter on the /19-/20 boundry for address space that is assigned as
shorter than /21. I don't know of anyone who is _purposely_ filtering out
legacy /24's though. By legacy /24's, I am referring to address space
that was allocated by the RIR as /24's. The chances of those /24's being
aggregated into /20 or shorter prefixes are pretty slim.

> Wouldn't it be better, at least from an engineering standpoint, to still
> announce their routes with AS padding to increase the AS-path so in the
> event their other connection(s) goes down they still have some type of
> inbound connectivity? It seems like your example would work in a best
> case scenario, but customer X would drop off of the planet in the event of
> a partial outage without some manual reconfiguration. I did something
> similar to what you are suggesting, but we still announced the routes,
> with padding, so that in the event of a failure the network could still
> function. The link did fail eventually (would you believe me if I
> mentioned there was a backhoe and a contractor involved?), and while the
> network was certainly slower than normal, it continued to function
> adequately so that there was no perceivable outage seen by our customers.

I agree that it would be better. I know of several instances where people
are doing it as I described though, for whatever reasons.

---
John Fraizer
EnterZone, Inc







Hosted Email Solutions

Invaluement Anti-Spam DNSBLs



Powered By FreeBSD   Powered By FreeBSD