BGP filtering policies, UU, and you
Henry Yen
henry at AegisInfoSys.com
Tue Apr 9 20:16:59 UTC 2002
On Tue, Apr 09, 2002 at 12:29:46PM -0700, David Barak wrote:
> There's no real problem with your current space.
> Assume for the minute that each of your offices has a
> UU T1. You announce the chunks of your /22 through
For the time being, only one uunet transit link.
> your various T1s, and that announcement (along with
> the UU/14) is passed along to UU customers and peers.
> Verio will ignore the /22, but will direct traffic to
> UU because they will accept the /14. so no problem
That part I am clear about.
> there. The only possible issue is this:
This part is the part that concerns me, as it is specifically
our scenario:
> assume one T1 to UU and one to <non-Verio provider>.
(make that one uunet link and more-than-one <provider>, as well
as both private links as well as over-the-'net tunnels interconnecting
some of our sites.)
> UU T1 goes down, therefore /22 withdrawn there, /22
> announcement through <provider> becomes only route.
> Verio ignores this, and directs traffic to UU (via the
> /14), and UU will then direct traffic to <provider>
> because UU has very liberal routing policies. So in
Uh, what's "very liberal routing policies" mean? (And which uunet
URL details this?) I assume you mean that uunet will accept announcements
for its own blocks (and specifics, not aggregates) from other
<providers>; that is, I also advertise this uunet block on my
other <provider> link, and they'll accept and propagate it (right?).
And uunet will accept this route of their own block from <provider>?
If this works as laid out, then uunet would realize that the
uunet link is down and send traffic over to the other <provider>.
> the worst case, you could get some sub-optimal
> routing, but nothing particularly bad, and Verio is
No, not particularly bad, but not as good as it could be "if only"
the block were allocated in class C space to begin with.
> the only substantive ISP who still uses these filters
> (AFAIK).
I know this is NAnog, but we have important correspondents in Europe and
Japan.
> The bigger issue in that case would be getting the UU
> line up faster :)
Unfortunately, the vast majority of failure modes for our sites end
up being dependent on the ILEC. It's not a pretty picture.
> Henry Yen wrote:
> We were recently assigned a /22 from UUNet in
> conjunction with some
> transit we're buying from them. The space is inside
> their superblock,
> 65.242.0.0/14. We are concerned that our route
> announcement of this
> block would be filtered out by some other providers,
> as it's not
> class C/swamp space (or even class B space for that
> matter).
> Verio's current policy, for one, indicates that this
> would be so.
>
> This is of particular concern to us as our little
> network encompasses
> several physical partially-meshed locations, with a
> mix of varying
> bandwidths both upstream as well as intra-location.
> Traffic Engineering
> is what we think is a reasonable (business) approach
> to address our
> flexibility needs, and so we're trying to move to
> address space(s) that
> would be least likely to be BGP filtered.
>
> We've asked for a different block from UUNet but the
> request didn't
> meet with success; UUNet suggested that any problems
> encountered
> as a result of this allocation could probably solved
> by e-mailing
> any NSP whose traffic interchange with us might be
> negatively
> affected (unlikely, to be sure, but still...), and
> would then
> change their filter (I'm unconvinced of this
> scenario).
>
> I briefly browsed the NANOG archives, and didn't see
> this issue discussed
> recently. Have the BGP filtering policies for "most"
> ISP/NSP's been
> relaxed to the level of "accept /24's from class A
> (ARIN-allocated) space"?
> Am I mis-reading Verio's posted policy? Is there
> anyone from UUNet
> who might choose to comment? Is there something else
> I'm misunderstanding?
--
Henry Yen Aegis Information Systems, Inc.
Senior Systems Programmer Hicksville, New York
More information about the NANOG
mailing list