BGP Question - how do work around pigheaded ISPs

Mailman List Mirror (Read Only)
1

Hey there. Due to the pigheadedness of a specific ISP (which I wil *not*
allude to in any way, shape, or form, so don't bother asking), and in the
interest of conserving IP addresses, I've been faced with quite a challenge.

- The Premis:
A parent organization has an unused /16 of address space, for arguments
sake, let's say it's 172.16.0.0/16. It's out of the old "class B" address
range. Two groups within the organization want to bring up independant
Internet datacenters, and need /18 of address space, each. Since the parent
organization owns an unsed /16, the IP registry refuses to give the child
organizations any address space - they insist all address blocks assigned to
the parent organization be used, first.

ISPph (ph=pigheaded) has a BGP policy that filters out all routes in
128.0.0.0/2 longer than /16.

- The network:
One group has Internet connectivity to 2 Tier1 ISPs (ISPa and ISPb) in North
America. They announce out 172.16.0.0/18 to both ISPs from AS65001.

The other group gets Internet connectivity to ISPc and ISPc in South
America. They announce 172.16.64.0/18 to their ISPs from AS65002.

There is no private network connectivity or backbones between the 2
companies.

- The result:
ISPph blocks out the /18s at the peering connections to ISPa, ISPb, ISPc,
and ISPd. So, customers of ISPph cannot see servers on AS65001 or AS65002.

- The workaround:
We announce 172.16.0.0/16 as well as 172.16.0.0/18 from AS65001 to ISPa and
ISPb. In our preliminary testing, we've found that what happens is that
ISPph would route traffic to 172.16.64.0/18 to ISPa (or ISPb, but we'll
assume ISPa has a better connection to ISPph), because it learned the
172.16.0.0/16 route from there. ISPa is hearing the *more specific* /18
from ISPc and ISPd, so it transits the traffic over to ISPc, which then
delivers it to the South American site.

- Questions:
1) is there a reason to announce the /16 from both ASs? Is that "legal?"

2) under normal situations (assume no link failures) would this cause any
problem?

3) Is there a link failure scenario that would cause the /16 to create a
blackhole for the 172.16.64.0/18 network?

4) Would you recommend this as a fix?

Of course, it would make ISPa transit for ISPph, but they're pigheaded
enough to make the Internet suck that way.

Thanks for your time!

2

==>- The Premis:
==>A parent organization has an unused /16 of address space, for arguments
==>sake, let's say it's 172.16.0.0/16. It's out of the old "class B" address
==>range. Two groups within the organization want to bring up independant
==>Internet datacenters, and need /18 of address space, each. Since the parent
==>organization owns an unsed /16, the IP registry refuses to give the child
==>organizations any address space - they insist all address blocks assigned to
==>the parent organization be used, first.

This is a frequent problem for those who have had address space from some
of the older blocks and are trying to go back and better handle.

You don't have to allude to who these ISP's are, they publically state
their policies. Typically, for these ISP's, one premise is that
filtering based on the minimum prefix size that the registry allocated
in that particular /8 shields them from legal challenges related to
having any sort of filtering policies in the first place. IMO, it just
makes the liability greater.

After all, what's the difference between 171.16.0.0/19, 171.16.32.0/19 and
64.255.0.0/19, 64.255.32.0/19, as long as the companies who are announcing
the blocks are doing so responsibly and for good reason? Why should the
first set be filtered but the second not?

The next answer that you'll receive are "some of the older companies don't
know how to responsibly announce their address space", because some do
announce them as /24's. I think that a responsible policy which limits the
announcements in the old B space to the minimum allocation ARIN is
currently utilizing, or even /19, is perfectly sufficient. It keeps
routing tables under control and protects against the infamous UUnet
de-aggregation disaster or bad announcements with lengths longer than,
say, /20.

Yet another off-the-wall answer you'll get is that some ISP's have
taken it into their own hands to stop announcements longer than /16's
because some old companies might want to sell portions of their /16's to
make money. With all the dot-coms closing, I think I'd be more worried
about 209+ and 62/63/64... =)

And finally, there's always the "there might be a chance someone will
pay us to amend our filters for their slot" argument.

/cah

3

[snip]

One point you missed: without good/accurate registry data, there is no
difference between "broken announcments" and "hijacked network". That
is a strong operational reason to strictly follow the registry
allocations, rather than the weak concern about people selling off
chunks of legacy address space.

I have been aware of several times when squatted, stolen, or
misconfigured-into-others'-space has been caught by registry-minded
filters. Specifically regarding slices of classical B-space and
not yet allocated A-space.

Cheers,

Joe

4

Any time a network is caught announcing non-allocated address space, the
registry should bill them accordingly. If they refuse to pay, the
registry should yank their ASN. That would be strong encouragement to do
the right thing.

5

Information on stolen or squatted address space should be published, to
ensure maximum shame for those involved.

Daniel Golding NetRail,Inc.
"Better to light a candle than to curse the darkness"