Canadian routes with BGP no-export communities

Curtis Villamizar curtis at
Fri Jun 7 02:30:05 UTC 1996

In message <960606181706.9ede at SDG.DRA.COM>, Sean Donelan writes:
> Does anyone know what's going on in Canada?
> In the last couple of weeks fONOROLA/ changed how they
> announce aggregated networks.  Now fONOROLA is sending some more
> specific network announcements for multi-homed networks in
> with a "no-export" BGP community to MCI, and ANS.
> As long as you only connect with MCI or ANS, and use their IGP,
> things look pretty typical because the more specifics are carried
> internally.  But if you use BGP, the no-export means any peers
> with MCI won't see the more specific network announcement from MCI.
> The problem shows up when you see routes from Sprintlink.  A few
> Canadian network connect through Sprint/Canada as well as fONOROLA.
> The more specific networks from 198.53 are announced by Sprintlink.
> Since the no-export suppressed the more specific announcement to
> MCI BGP peers, the traffic for those Canadian sites follows the
> more specific network announcement and heads for Sprint.
> I understand the BGP mechanics are working as specified, so it
> isn't "broken" per se. But I'm just wondering if Canadian sites
> really expect traffic to go via Stockton, California?
> I haven't been able to reach anyone at fONOROLA/Istar.  I was just
> wondering if any other North American network operators had heard
> what was supposed to happen last month when fONOROLA made these
> changes.
> --
> Sean Donelan, Data Research Associates, Inc, St. Louis, MO
>   Affiliation given for identification not representation


I can't speak for Istar, but I do know that they had tried to make
this a painless aggregation by indicating to both ANS and MCI which
prefixes were in their aggregates that did not need to be advertised
outside of ANS and MCI.  Istar saved some 750 prefixes.  I think this
is roughly half what they had previously been announcing and they have
over 3500 prefixes registered, indicating a lot were already site
aggregated.  This is certainly commendable.

Unfortunately, since there is no way for them to know which Istar
prefixes also have connectivity through Sprint or someone else (with
Sprint failing to register this in the IRR), there is no way that
Istar can determine that those component have to be passed on by ANS
and MCI except to aggregate and see what breaks.  This is the type of
"information exchange" and provider cooperation through the IRR that
we have been talking about that isn't universally accepted.

As this type of non-trivial aggregation becomes more common, we can
expect this sort of thing to be a regular occurance unless certain
other providers take the time to register things.  Yes, we know it is
work, but nothing near the work Istar did to get these prefixes
aggregated with as little disruption as possible.

The more specific prefixes blocked by ANS and MCI are listed below.
We can determine which are heard from Sprint with a routing dump and
unblock them.  This is the "break it, see what broke, then fix it"
method, but the end result will work.



echo '( AS2493 AND ANSIGPONLY )' | Peval


More information about the NANOG mailing list