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