The next attribute we will look at is
the BGP community.
BGP communities are described in RFC 1997.
The communities
are a transitive attribute and they're optional.
So you don't have to set them
and indeed several operators make no use of BGP communities whatsoever.
But in fact BGP communities, of all the attributes,
is probably one of the most
useful and most powerful attributes
when it comes to implementing BGP policies on
the internet today.
And we will be looking at communities in much more depth later on in this series.
BGP community is a 32-bit attribute.
But is commonly represented today on the internet as two 16-bit integers.
There was a supporting RFC, RFC1998 which
was written by a network operator
describing how they used
the early BGP community when it first appeared in
router implementations
and they represented it as two 16-bit integers
really because two 16-bit integers were easier for us humans to understand than
one long 32-bit integer was.
So the common format used is, inserting your
local AS number then a colon and then another 16-bit integer
which is used to
represent your local policy.
It's not a standard format but it's the commonly
used convention today as we'll see.
There are a range of reserved communities in
traditional IETF fashion,
the first 65,000 and the last 65,000 are reserved.
Now communities are used to group destinations
and each destination can be
a member of multiple communities.
The destinations are defined by the network operator.
There are no standard defined destinations,
as such it's entirely up to
the network operator what these destinations are.
And as I hinted at, these are really useful for applying policies within and
between autonomous systems.
Let's have a look at an example just to
show how they work.
So in the days before BGP communities,
a network operator would be
connecting BGP customers or even normal standard statically connected customers.
Every time they'd connect a customer, they would have to set up a BGP filter,
to allow that BGP announcement into the network.
We've got AS 300 here in the
diagram, customer AS 100 announcing a prefix,
so we set up an incoming filter
to allow 160.10.0.0/16 inbound.
That's all fine.
But we want to give AS 100 transit
to our upstream provider in AS 400.
So we have to update the filter in our
border router, router E, to allow 160.10.0.0/16 out.
That's fine as well.
Certainly in the early Internet days, in the 90s, we had very few BGP features to let
us do this
without actually doing it in a maintenance period.
Nowadays it's much easier.
And indeed when BGP communities arrived it made it much easier as well.
In the early days, before communities, we would have to shut down BGP on router E,
the border router, and then bring it back up again.
And that of course is disruptive,
in the early internet days it was less of an issue as the internet was not mission
critical for many organizations and end users.
Nowadays it's unimaginable to shut
down any connection just to update a configuration.
So imagine what happens
when a second customer comes along,
170.10.0.0/16, we have to update our
incoming filter to allow that prefix in
and update our outbound filter to let
that prefix out.
Which usually would mean another shutdown BGP,
bring it up again
and all the disruption that that caused.
And it's also the management of BGP
filters, I've only shown one border router to one upstream.
What if you had more upstreams?
What about if you had peers?
What filters
would we have to update to manage all this?
And for a sizable network this
became really complicated to manage.
Every time you add a customer
you have to make sure you update border filters
everywhere across the network or at
least in the places across the network you wanted to allow this new prefix to have access to.
So we ended up with a management and manageability
problem, never mind a scaling problem.
So when BGP communities came along, can you
imagine how this all changed?
If we look at the diagram again now with
communities in place, prefix comes in from AS 100 on to router C.
Sure we still have our inbound prefix filter,
but now what we do, we also tag the prefix with a
community and I've chosen 300:1.
300 is our AS number and 1 means,
transit customer perhaps.
We go to router E and all we do now is, we set up a filter that says:
"Let any member of community 300:1 out."
So we don't look at the prefixes anymore we just say:
"Is the prefix a member of community 300:1?
If so, let it out."
So when a new customer comes along,
we just drop them
into community 300:1
and they automatically get announced out to the
internet without any recycling of the BGP session.
And now we can set up all
the configuration on all the border routers, whether with our peers or with our transits,
to do the filtering based entirely on communities.
In fact,
throughout my career with helping network operators almost the first thing I've done,
is done a good analysis of all the filters
and all the border routers
whether to upstreams and to peers,
and we've replaced the static prefix filters
with BGP communities,
because this makes the network much easier to manage and
much much more scalable.
And of course, usually when operators
have discovered the power of communities,
they all implement big projects to
migrate away from static outbound prefix lists
to using bgp communities instead
as they discover the great flexibility
and scalability that they offer.
© 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.