BGP prefix filter list

Thomas Bellman bellman at
Fri May 31 15:34:29 UTC 2019

On 2019-05-31 01:18 +0000, Mel Beckman wrote:

> No, that's not the situation being discussed.

Actually, that *was* the example I was trying to give, where I
suspect many are *not* following the rules of RFC 1930.

> As I've pointed out, a multi homed AS without an IGP connecting all
> prefixes is non-compliant with the BGP definition of an AS. Your
> Tokyo/DC example is additionally non-compliant because it doesn't
> have a single routing policy. It has two policies. That this may
> work in certain circumstances doesn't make it compliant with the
> standard.

So, an *organization* with one Tokyo office and one DC office, each
having a PI prefix, and with their own Internet connection(s), and
no private interconnect with an IGP connecting the sites.  They can
handle this in several ways:

1) Use the same ASN for both sites, each site announcing only its
   own, prefix over eBGP to its ISPs.  They won't be able to receive
   the other site's prefix over eBGP, since the loop detection in BGP
   will see the common ASN in the announcments from the other site and
   drop it, but that can be easily handled by the sites adding static
   routes via their ISPs (or by just getting default routes from their

   This violates RFC 1930; I agree with that.  But does it fail in
   the real world?  Will ARIN/APNIC revoke their ASN and/or prefixes
   due to violating RFC 1930?  Will the rest of the Internet try to
   route the Tokyo prefix to DC, or vice versa, due to them being
   originated from the same ASN?  Any other problems?
2) Get a separate ASN for each site.  Continue with not having an
   IGP between the sites, and continue with announcing different
   prefixes from each site.  They can however now receive each
   others prefixes over BGP.

   This does not violate RFC 1930; nowhere in that document does
   it say that an organization can only have a single ASN.

   But will ARIN/APNIC be willing to give out two ASNs to that one
   organization?  Does the answer change if it is not one site in
   Asia and one in America, but one site in every US state?  Or one
   such site in each of the 290 municipalities in Sweden (and pre-
   sumably trying to get ASNs from RIPE instead of ARIN)?

3) Pay the high fees for getting private interconnects between the
   continents (or for each of the 290 offices in the Swedish example),
   and let all sites announce all of each others prefixes, acting as
   transits for reaching the other sites.

   This obviously costs more money.  I have never priced such an
   interconnect, so I don't know how much it would cost, but I expect
   it to be fairly expensive.

   Also: what happens if the interconnect breaks, partitioning the
   AS?  Then they are in effect at situation (1), violating RFC 1930,
   with of course the same questions/problems.

4) Pay the high fees for private interconnects, use the same ASN
   at both sites, but let each site announce the other's prefix
   with larger amounts of AS path prepending so "no-one" tries to
   send their traffic to the wrong site.

   This also violates RFC 1930, as far as I understand, as the two
   sites have different routing policies.  But does it cause any real-
   world problems?  Does the IP police arrest them?  Will the rest of
   the world ignore the policies and send their traffic to the wrong
   site since the prefixes are originated from the same ASN?

I suspect that there are a fair number of organizations that does
one of (1), (2) or (4) above, and I *believe* that it actually works.
And some of the things I see in our ISP's BGP tables looks like at
least some people are doing (4), or possibly (1).

RFC 1930 might be the law on the book, but does people actually
follow it?  Or is it just an outdated law that no-one knows or
cares about, but no-one has bothered to formally deprecate?
(The parts of RFC 1930 implying that we should have migrated to
IDRP by now are obviously not in touch with current reality. :-)

My personal feelings is that requiring (3) would be a bad thing,
as it would cost lots of money.  (2) is OK, but I think many people
would forget or ignore getting a separate ASN for each site.

But I have only a little experience in running BGP, and have only
done so for a single-site organization (or at least single-site
in terms of where we have our Internet connection).  Answers to
the questions I make above are appreciated.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the NANOG mailing list