Home page logo
/

nanog logo nanog mailing list archives

Re: Verio Peering Question
From: "E.B. Dreger" <eddy+public+spam () noc everquick net>
Date: Sat, 29 Sep 2001 19:42:52 +0000 (GMT)


Date: Sat, 29 Sep 2001 14:58:09 -0400 (EDT)
From: Paul Schultz <pschultz () pschultz com>

if you have 64.x.x.x/15, slice it into as many /20's as you can
and bloat as much as you want.. we feel this is an acceptable
practice.  Yet, if you're a legitimately multihomed customer
wants to push out a single /24 (1 AS, 1 prefix) that is not
considered acceptable.

Right.

The only kind of prefix filtering I would want to implement is
something that can accomplish:

[ snip ]

An interesting thought.  Group BGP adverts / table updates by
prefix length... get connectivity up and going, then chew on
the smaller details as needed.  Sort of like real-time process
priorities; if you can get there, queue longer prefixes until
_after_ all others have been processed.

This way I could get rid of redundant information yet at the
same time not cause any trouble to smaller multihomed
customers.  I'm not saying that we should allow /32's to be
pushed everywhere either.  As you said there has to be a limit,
and /24 seems to be a pretty good one if something along
the lines of the above mentioned filtering algorithm could be
used.

Seems to me that "saving the Internet" means strict ingress
filtering[1] of downstreams and strict egress filtering[2] to
peers and upstreams... which is pretty much the opposite of what
Verio does.

[1] Providers SHOULD filter/aggregate downstream routes, unless
    there's some overriding reason not to.  There's enough bad
    BGP that trusting Joe Provider to do things right scares me.
    (I'm no <insert favorite NANOG routing superhuman guru>
    myself, but at least I know enough to speak decent BGP and to
    "tune" things.)

[2] Want to tune inbound traffic?  Fine... advertise those longer
    prefixes to your upstreams/peers.  But don't make the rest of
    the Internet suffer.  Communities good.  Extra routes bad.

I'm sure in reality there's many reasons this would not be able
to be implemented (CPU load perhaps) but it would atleast do
something more than a "gross hack" that nails some offenders,
not all by any means, and impacts multihomed customers who are
only a portion of the problem that the current prefix filtering
solution does not solve.

Filter/aggregate as close to origination as possible.

"Be conservative in what you send, and liberal in what you
receive."  Haven't I heard that somewhere before?  (Bonus points
for anyone who can name the RFC without wimping out and using a
search like yours truly alas had to do.)


Eddy

---------------------------------------------------------------------------
Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
---------------------------------------------------------------------------

Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist () brics com>
To: blacklist () brics com
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.  Do NOT
send mail to <blacklist () brics com>, or you are likely to be blocked.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault