Re: BGP filtering policies, UU, and you

[Henry Yen <henry () AegisInfoSys com>]

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