Re: Canadian routes with BGP no-export communities

[Jeremy Porter <jerry () fc net>]

Curtis, Sean,

Since these networks presumable are being announced
as more specific by customers of fONOROLA/iStar.net,
wouldn't it be best to try and get someone who has
an interest in making it work right to do the work,
stead of kicking the backbone provider?

Since the prefix originator is the one who's routing
is breaking, and if they can just register in the RADB to
fix things, I don't really see a problem.

Personally, I'd like to see this type of aggregation
working more often.  This seems to be the best way
to get reasonable aggregation out of the "SWAMP" and the
rest of the ~20,000 legacy addresses.  This combined with
prefix length filtering, to help "encourage" people to get
address space from their providers, will greatly reduce
the total number of prefixes in the IPv4, "end state"
routing table.  (I suspect, but don't have data to prove (YET),
that the best we will be able to do with the ~20,000 is reduce it
to ~10k to ~15k.).

If your routers can hold then hold about 100,000 prefixes
at ~4 paths per prefix, you should be pretty well off for the
next year or so.

I personally think that allowing /19s in 208-223 is a little too
generous with router ram.  (And there is the issue of what
happens to 64k Cisco SSP's when forwarding tables exceed 64k)...

Of course if you are using a different routing vendor, you
will see slightly different resource limits.



> In message <960606181706.9ede () SDG DRA COM>, Sean Donelan writes:
> > Does anyone know what's going on in Canada?
> >
> > In the last couple of weeks fONOROLA/iStar.net changed how they
> > announce aggregated networks.  Now fONOROLA is sending some more
> > specific network announcements for multi-homed networks in 198.53.0.0
> > 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
>
>
> Sean,
>
> 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.
>
> Cheers,
>
> Curtis


-- 
Jeremy Porter, Freeside Communications, Inc.      jerry () fc net
PO BOX 80315 Austin, Tx 78708  |  1-800-968-8750  |  512-339-6094
http://www.fc.net
- - - - - - - - - - - - - - - - -