BGP filtering policies, UU, and you

Mailman List Mirror (Read Only)
1

Hi Henry et al,

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
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
there. The only possible issue is this:
assume one T1 to UU and one to <non-Verio provider>.
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
the worst case, you could get some sub-optimal
routing, but nothing particularly bad, and Verio is
the only substantive ISP who still uses these filters
(AFAIK).

The bigger issue in that case would be getting the UU
line up faster :slight_smile:

-David Barak
"Quis custodes ipsos custodiet?" - Juvenal

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?

2

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 :slight_smile:

Unfortunately, the vast majority of failure modes for our sites end
up being dependent on the ILEC. It's not a pretty picture.

3

Hi Henry,

I've snipped, and interleaved.

This part is the part that concerns me, as it is
specifically
our scenario:

> assume one T1 to UU and one to <non-Verio
>.

(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.)

The net effect is the same. UU can and does listen to
announcements of its space from ASes other than 701 on
a routine basis. There are many orgs which have a T1
to UU and a T3 to <provider>, but had the UU T1 first,
and thus received UU IP space.

> 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?)

Well, if you look at the soup of 63.64/10, you'll see
some examples of their liberal policies. Here's one:

route-views.oregon-ix.net>sh ip bgp 63.69.154.0 | inc
701
  7018 1239 11548
  6079 701 1239 11548
  6066 701 1239 11548
  701 1239 11548
  6539 701 3561 11548
  14608 701 1239 11548

Notice that UU is propogating announcements from
Sprint and C&W from a downstream customer (11548) on
its own IP space.

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>.

Demonstrated above.

> 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.

Personally, I think the fault lies with filtering on
legacy Class boundaries in the first place, rather
than on those ISPs who follow the RIR guidelines and
permit multi-homing out of CIDR blocks.

you say to-may-to, I say to-mah-to...

I know this is NAnog, but we have important
correspondents in Europe and
Japan.

Accepted, but your biggest issue with those
correspondents will be the intercontinental links
anyway, not an extra peering AS. As CAIDA and others
have reported, the internet is generally becoming more
densely meshed, so this will steadily decrease in
significance.

> The bigger issue in that case would be getting the
UU
> line up faster :slight_smile:

Unfortunately, the vast majority of failure modes
for our sites end
up being dependent on the ILEC. It's not a pretty
picture.

ILEC failures rarely are.