ISP Filter Policies--Effect is what?

Steve Schaefer schaefer at simone.dashbit.com
Tue May 8 17:16:21 UTC 2001


This discussion is basically correct.  Some comments:

1) You always want to advertise the entire block (in this case, a /16).
If you don't own the entire block, then you should have a relationship
with to BGP originator of the block advertisement such that you can
receive traffic from them where you expect it (if, for example, you AS is
not really "well connected".)

2) There is no substitute for looking at things in the real world.  To
understand how filtering works and routes propagate, I suggest two
resources:

University of Oregon Route Views Project
http://antc.uoregon.edu/route-views
telnet route-views.oregon-ix.net

The route-views.oregon-ix.net router receives BGP from all but a few of
the major backbones and an assortment of others as well.  You can query
that router to see who hears what routes.  I was able to verify, for
example that Verio filters all Class B subnets (including /18, for
example).

Traceloop  (I am affiliated)
http://www.traceloop.com

The Traceloop network is basically a searchable community of traceroute
servers.  You'll have to sign up to get a personal login, since the Guest
Login doesn't have all the features that you'll want.  If you type
"AS2914" in the search field (for example), you'll get a list of test
points in Verio's AS (although the formatting is poor).  If you type
"www.verio.net" in the search field, you'll get a list of test points in
Verio's AS and some that use Verio for outbound routes, too.  By choosing
test points in various AS's, you can see how traffic is actually routed.


-steve



Dashbit -- The Leader In Internet Topology
www.dashbit.com          www.traceloop.com


On Tue, 8 May 2001, Murphy, Brennan wrote:

>
> I'm trying to figure out to what degree the existence of these policies
> should
> be accounted for in a BGP design which includes sites around the world.
>
> I've read through a few of the threads having to do with Verio's
> Filtering Policy. And I read the policies listed here:
> http://www.nanog.org/filter.html
>
> Consider the following theoretical scenario:
>
> Site			BGP Advertisement	 to	ISP
> Amsterdam		169.61.201.0/24		AMSISP
> Austin		169.61.111.0/24		Genuity & Internap
> SanFran		169.61.119.0/24		Genuity & Internap
> Tokyo			169.61.202.0/24		TOKISP
> Sydney		169.61.156.0/24		SYDISP
>
> 1. Since Verio says they would not accept /24 nets drawn from Class B space,
> I assume this means that they don't insert a /16 into their tables so that
> the /24 nets appear to Verio customers as unreachable. In this case, a
> design
> that wants to extend connectivity to verio customers (and any
> other ISP with similar policies) must include a /16 advertisement from at
> least
> one of the sites.
>
> 2. Suppose a customer of a Verio-like ISP, wishes to go to ftp. foo.org. DNS
> returns 169.61.201.155 (in amsterdam, see above). Verio passes the traffic
> to the neighbor it received the /16 advertisement from. At this point, the
> best thing that could happen
> is if that neighbor has the /16 and /24 networks in its route table, right?
> That
> means, a path exists for that user to the amsterdam server and the only
> problem
> with routing to Amsterdam is that Verio possibly handed the traffic to a
> sub-optimal
> neighbor. Am I understanding this issue correctly?
>
> I'm new to BGP. I've tried to get a handle on this issue on my own and by
> working with Genuity, Internap and Cisco. No disrespect to those companies
> but
> each of them had this vague memory of Verio's policy but couldnt really tell
> me
> in plain language how it might affect the above scenario. Obviously, I
> wasn't talking
> to chief engineers. Someone from the CCIE mailing list suggested I browse
> the archives of this list, which I did. But I didnt find a clear enough
> answer to my questions--perhaps because they are too basic to be discussed
> here or I'm not good at using this lists archive search engine.
> Either way, any guidance on the above scenario is greatly appreciated.
>
> -BM
>
>
>
>
>






More information about the NANOG mailing list