North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Regarding global BGP community values

  • From: Aleksi Suhonen
  • Date: Sun Oct 17 08:55:03 1999

On Mon, 11 Oct 1999 22:19:21 -0600 Danny McPherson <[email protected]> wrote:

> While it's clear that a considerable amount of disagreement exists regarding 
> transitive communities dynamically doing things, it's extremely simple for 
> providers to just not pay attention to them.

Which is desirable. Customers who want them to work will buy from
providers who can make them work. There will still be customers who
don't need them for those providers who don't want to pay attention
to such communities. The rest shall be history.

> Another potential application for global transitive communities,
> which is likely even more debatable than path selection issues,
> is using them in conjunction with MEDs and "more specifics" of
> provider aggregates (to fix some of the brokenness of aggregates
> and MEDs) in order to provide a safety net for potential route leaking.  

This is what the already well established community "no-export" is for.

You announce the supernet as you would any normal route and you
announce the specifics with "no-export" at only their "best-exits"
and only to your multi-exit-peers. That way the specifics can't
(well shouldn't be able to at least) leak but no connectivity is
lost since the supernet is never a candidate for filtering or

The traffic will follow the supernet until it gets to a network
that has the more specifics. No need to litter the routing tables
of thousands of autonomous systems that don't have a need to know.

The community 65530:arg was in my message for two purposes:
("when announcing to <arg>, replace this community with no-export")

* So that you can scratch those hard to reach places, I.e. peers
  of transits. Tier 1 providers don't have those of course.
* So that you can tag your specifics when injecting them with a
  community that will get automatically replaced with no-export
  when exporting to your own direct peers. More useful for Tier 1s.

It doesn't have the desired effect alone of course, but a trained
mind can easily see what other communities are needed to create the
correct combination in their own environment.

	Aleksi Suhonen

PS. Andrew Partan suggested that I'd write up an example implementation
of these communities for Cisco, Juniper and Gated. The Cisco version
was already included in the end of my original message, but I'm having
trouble with the Juniper implementation. I have no access to a Juniper
router and all the references for a configuration manual on
were password protected. Hence I need pointers that would tell me how
to configure a Juniper router.