mailing list archives
RE: ISP Filter Policies--Follow Up--Verio Verification
From: "Murphy, Brennan" <Brennan_Murphy () NAI com>
Date: Thu, 10 May 2001 12:18:56 -0700
I wanted to follow up on my query below. I found a real-world case
where a company advertises /16, /19 and /24 nets from the same Class
B space....yet all are reachable from Verio's network (I tested this with
Verio's Traceroute Server). A phone call to Verio verified for me why
all 3 nets are reachable. (interestingly, the traceroutes themselves
sort of masked how this was working--hence, the need to talk to Verio)
Basically, it was as I had thought--because at least one of the sites
advertises /16, this is enough to get traffic off of Verio's net, ie,
all traffic destined for any piece of the /16 is passed to its "nearest"
neighbor. If that neighbor in turn has the /19 & /24 in addition to the
/16, the routing from that point on will be optimal. If not, it
passes it to the neighbor from which it received the /16...and so on, until
has the full /19 or /24 net.
So, when I originally posted the note below, I was worried that Verio
not be able to reach certain networks with prefixes longer than /16, ie,
sort of blackholing the routes to those destinations. (Remember, I'm
new to Internet routing.) That would indeed seem to be the case if there
were no /16 advertisement in addition to the more specific announcements.
That's the generic BGP/Verio lesson I drew. The more specific lesson is that
if your working with a large provider like Internap or Genuity in all your
sites, traffic destined for your location is going to get back to you as
long as they are advertising the /16 in addition to the more specific nets.
...even if the source hosts are on networks like Verio's.
Any further comments appreciated.
From: Murphy, Brennan [mailto:Brennan_Murphy () NAI com]
Sent: Tuesday, May 08, 2001 12:07 PM
To: 'nanog () merit edu'
Subject: ISP Filter Policies--Effect is what?
I'm trying to figure out to what degree the existence of these policies
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:
Consider the following theoretical scenario:
Site BGP Advertisement to ISP
Amsterdam 188.8.131.52/24 AMSISP
Austin 184.108.40.206/24 Genuity & Internap
SanFran 220.127.116.11/24 Genuity & Internap
Tokyo 18.104.22.168/24 TOKISP
Sydney 22.214.171.124/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
that wants to extend connectivity to verio customers (and any
other ISP with similar policies) must include a /16 advertisement from at
one of the sites.
2. Suppose a customer of a Verio-like ISP, wishes to go to ftp. foo.org. DNS
returns 126.96.36.199 (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?
means, a path exists for that user to the amsterdam server and the only
with routing to Amsterdam is that Verio possibly handed the traffic to a
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
each of them had this vague memory of Verio's policy but couldnt really tell
in plain language how it might affect the above scenario. Obviously, I
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.
- RE: ISP Filter Policies--Follow Up--Verio Verification Murphy, Brennan (May 10)