There are several well-known communities,
and these are listed on the IANA website at the URL reference there.
There are several common ones,
I've listed five of them that are most commonly used.
The no-export community I'll show you an example of in a minute.
No-advertise is quite useful as well,
no-advertise simply means do not
advertise this prefix to any BGP peer.
For example you may learn a prefix from
a neighbor on your border router
and you may decide I don't want to announce this
to anywhere else in my network.
Now the standard way of doing it, you would think
yes I'll just put a prefix filter on all my internal BGP sessions.
Then you've got to manage it and you've got to update it and you've got to add as more
iBGP sessions are set up.
What happens if you forget?
What could go wrong?
Instead it's actually much easier as the prefix comes in tag it with no-advertise.
And the BGP sessions when they see the no-advertise attached to the prefix will automatically drop it.
Much easier to manage.
The no-export-subconfed is
all to do with BGP confederations.
We'll make short mention of confederations but
I'm not going to cover this well-known community outside of that.
There's a no-peer community
which arrived much more recently.
That has some use across the
internet today but is not as widely used
as many of us had hoped for.
What this one does,
it lets operators know not to advertise
this prefix to the peers.
This is bilateral peers, as opposed to
upstream transit providers.
As I say, some operators have used it,
many operators are simply unaware that this useful
community actually exists.
The idea behind it is to ensure that we don't end
up filling the global default-free zone
full of traffic engineering prefixes in BGP, and again
I've got a short example to show you how it works.
The final one is the Blackhole community.
This is the most recent defined well-known community, RFC7999.
And this is to null route a prefix.
If the prefix is announced to a neighbor with the
Blackhole community set,
it tells the neighbor
to null route any traffic to that prefix.
It's extremely useful for the
Remote Triggered Black Hole filtering
BGP security feature that is widely used on
the internet today to help defeat denial of service attacks.
We'll now look at the no-export community.
The no-export community tells the neighboring AS not
to announce this prefix to any other autonomous system.
It's most commonly
used in load balancing situations when your're multihoming with a neighboring AS.
So the example I have here, has three links between AS 100 and AS 200.
The traditional way of multihoming as we'll see later on in this series, is to
announce the aggregate on all three links,
as well as announce three subnets of
the aggregate, one on each link.
The subnets we will announce with the no-export community.
And that will tell the neighboring AS,
AS 200, not to announce
the subnets to the wider Internet.
Router G will spot the no-export community and
not announce these prefixes to any other operator that it connects to.
So the intention here is really to
implement the traffic engineering
between AS 100 and 200
without leaking local traffic engineering prefixes to
the global Internet.
As we've mentioned already the default-free zone in the
global Internet
is a very, very large number of prefixes,
660,000 in October 2017,
and this number is only growing.
Again, mostly caused by traffic
engineering prefixes leaking out into the wider internet.
So the no-export community is very, very useful community intended to
help deal with
this big growing problem on the Internet.
The second one I want to show is the
no-peer community.
The no-peer community,
as you can see in the diagram,
is intended to let upstream networks know
to only send this prefix
to the upstreams and not to their bilateral peers.
So we start off in router A.
Again, we're trying to load balance we send the aggregate to our 3 upstreams.
and we send the traffic engineering subnets
with no peer attached to them, one on each link.
Now the upstream operators that peer with
each other, C, D, and E, in the diagram,
they're all peers, for example they might be tier ones.
All they want to see and all they need to see,
are the actual aggregates
they don't need to see the sub-prefixes.
The sub-prefixes, you have
sent with the no-peer community attached to them.
So the border routers on those
upstream providers will not send those
subnets tagged with no-peer.
Now I've talked about the format in RFC1998
as being: <AS number>:<Any other number>.
We've taken the 32-bit attribute and divided it into two 16-bit integers.
But as we've seen already, AS numbers are now 4-bytes, 32-bits.
So what happens if you have a 32-bit AS number,
an AS number bigger than 65535?
You can't use this "standard" or so-called "standard" practice.
Even though this is just a convention,
a convenient convention used by operators,
it's not standardized.
But this is now so
fixed in operational community best practices,
that we tend to expect the format is now:
<AS number>:<Some local number you define>.
So the solutions, certainly over recent years,
has been to use a private AS number for
the first 16-bits.
More recently, RFC8092
has defined BGP large communities, this was standardized in early 2017.
And this is a new BGP attribute
to deal with the case,
nowadays, where most operators
have 4-byte AS numbers.
So the BGP large community attribute is a new attribute designed to accommodate the local 32-bit AS number,
a Local Operator Defined Action, which can
be up to 32-bits big,
and a Remote Operator Defined Action,
which also is 32-bits big.
Which allows operators using 32-bit AS numbers
to peer with others using 32-bit AS numbers
and define policy actions as well.
So this is much
superior to the original community definition
which only accommodated 16-bits of ASN's and 16-bits of action.
So I've got some examples here showing
common community conventions.
And we're going to cover this in much more detail
later on in this series.
So the first example, 131072:3:131074,
that might be AS 131072
requesting AS 131074 to do a three times prepend of this prefix on AS 131074's peerings.
It means that AS 131074 has to look out for this community,
and do three times prepend on it's peerings
for AS 131072 prefixes.
Or what about 131072:0:131074?
AS 131072
requests AS 131074 not to announce this prefix at all.
Again, using common conventions for what some of these policy numbers mean in BGP communities.
© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.
Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.