[AUDIO LOGO]
So we've looked at several different BGP attributes
that we can use to change BGP path selection.
Now there's another attribute we need
to look at here, communities.
Now, the thing with communities, they're
not going to affect BGP's decision in any way directly.
Communities are just a way to tag or mark a prefix.
The device receiving that community
then has to be set to do something with it.
What's it going to do?
Well, that's going to be for us to decide.
But one of the things that can do
is change one of the attributes that we've already discussed.
So maybe it changes weight, maybe
it changes local preference.
And that would affect the outbound decision
of the other AS that we're sending the community
to, therefore, affecting our inbound traffic when
that AS sends traffic to us.
So effectively what we would be doing is using communities
to affect the inbound traffic, but we're doing it
indirectly because really what's happening
is the other AS is affecting their outbound policy based
on the communities we send.
Now for any of this to work, the ASs
would have to communicate the communities with each other.
I can't just guess what community
to send to a particular service provider
to get them to do a particular thing with my networks.
So this is information that's generally
going to be published somewhere on each service provider's
site.
As a service provider when you're
interacting with other service providers,
you have to know their policies just
as much as you're going to have to notify them
of your policies.
So whatever communities you decide
to use to allow them to influence traffic,
you have to publish those probably on a website,
but the point is everybody has to be
aware of these communities or else nobody can use them.
So what we're going to be doing is
we're going to be sending some updates between our AS numbers,
and we're going to use communities
to affect the return traffic coming back to our AS.
So as always let's take a look at our topology first,
put together a game plan, and then we'll
jump into the command line and get communities
working in our topology.
So for this demonstration, we're going to focus on that loopback
interface on router 8 which is 100.8.8.0/24.
And what we're going to be doing is
having AS 65001 influence the path
that service provider 1 or AS 100
is using to get to that network.
What should be happening right now,
and we will, of course, verify this, router 1 and router 3
should be sending traffic directly to router 7.
What we want to accomplish is we want to get both of them
to switch over and send the traffic to AS 1000.
Now we're going to approach this from the perspective
that we only have control over customer A.
Now what I mean by that is we'll be doing the configuration
to influence the path selection on router 7.
We will, of course, have to do configuration on router 1
and router 3 to get this to work to begin with.
The service provider routers for the neighboring AS, of course,
have to be configured.
We also have to choose how we're going to do this.
What we need to remember is this prefix
that we want to use is being learned from router 6
to router 1, and there's no local preference or weight
or anything being set on that.
Therefore, it's going to have the default local preference
of 100.
And we will use local preference to influence this path
selection just because generally it's a better choice.
So keeping in mind that we're going
to be getting that default local preference, what we need
to do since higher local preference wins,
is when router 7 is sending out its updates to AS 100,
we're going to have to set the local preference to something
different like, for example, maybe 80.
So we will have to assign community strings for this
to happen.
I would recommend that we're probably
going to use community 100:80.
The first part of the community is usually
the AS number that's assigning this community string,
and then the second part is usually
something that just makes sense based
on what we're trying to set.
And since we're trying to set the local preference to 80,
it would make sense to make the second part of this 80.
Technically it could be any number
you want, but we'll use 100:80 to get router 1 and router 3
to lower their local preference to 80.
Therefore, they will choose the path
with the default local preference going to router 6.
So let's begin by, of course, verifying the current path
selection.
We'll jump into the routers, and we'll
make sure that router 1 and router 3
are currently going directly to router 7.
So let's begin with the show BGP for the prefix we're
looking for.
What we see here is that it has three available paths.
The first one is learned from router 3.
Now this one actually has an inaccessible next hop
of 10.7.7.7.
If we intended to actually try to use that path,
we would want to fix this because that path is not
usable.
And particularly for redundancy, that should probably be fixed.
However, in this particular demonstration,
that's not the path that we're going to try to choose,
so it really shouldn't affect how
we're going to be changing our path selection.
So for right now, we're not going to worry about that.
The second path we can see is the path
learned through router 6.
This is the path that we ultimately want to use,
and then, of course, we have path 3,
which is the one that's currently the best.
This is the path learned directly from router 7
with router 7 itself being the next hop.
Let's verify what we have on router 3 as well.
Remember, in this example, that router 3
is a route-reflector client of router 1 and router 2.
So notice that we're getting the prefix from both of our route
reflectors, and both of them are showing a next hop of router 1.
Now the other path we have here, of course, the one that's
currently best is, again, the one directly from router 7
with router 7 as the next hop.
So again, these are things that we're
going to want to change through using local preference
and communities.
So the first thing we have to do to get this to work,
we have to start by setting up router 1 and router
3, our service provider routers, in order
to accept the communities and do what
we want with those communities to effect the BGP updates.
So let's go ahead and configure that first.
We'll start on router 1.
First thing we'll need is a community-set.
We'll call this CS_FROM_CUSTOMERS.
What we're going to match on is the 100:80
that we said we were going to use in our game plan.
We'll end the set, and then we'll write our route policy.
We'll also call this FROM_CUSTOMERS.
And for our logic, we're going to say if community.
We'll do a matches-any, meaning it will accept anything
in the list.
It doesn't particularly matter since there's
only one item in our list, but here we'll
put our community-set.
Then what we're going to do is set the local preference,
and we're going to set the local preference to 80 exactly
like we said in our game plan.
We'll then forward the route.
And again, we're not trying to filter,
so we will pass all the other routes
as well if they don't match our community-set.
We'll exit out of our if.
We'll exit out of our policy.
Go into BGP for our neighbor.
This would be towards router 7.
Into our address family, and we'll assign our route policy.
This will be an inbound policy because we're
going to be applying this as the router coming in
from the customers.
We'll commit our changes and exit configuration.
Router 3's configuration is going
to be identical to router 1 here,
so we'll just copy and paste.
This is what we're going to be pasting in on router 3.
As you can see, it's exactly what we just typed on router 1.
So let's go ahead and paste that in and the exit configuration.
Our next step is going to be configuring router 7
to send the community to router 3 and router 1 so that it
influences the path selection.
So now let's go configure this on iOS XE on router 7.
So the first thing we're going to need is a route map.
We'll call it RM_TO_SP1.
And what we're going to do is simply set the community
to the 100:80.
Now if you haven't seen this before,
iOS XE does something interesting with community
strings and how it displays them.
If we were to say do show route-map,
we can see here that on the route map, RM_TO_SP1,
it's displaying the community as 6553680.
Not exactly the 100:80 as we typed it in.
This is the older way of displaying community strings
in decimal format.
This is still the default on iOS XE.
If we want to see this in the newer format like the way we
entered it, we have to put in one configuration
command on the router.
Let's go ahead and take a look at it.
So we have to type ip bgp new-format.
Now this will, of course, take us out
of route-map configuration mode because this is actually
a global command.
But if we look at our route-map again,
we can see that now the community is listed nicely
as 100:80.
Keep in mind this just affects how it's displayed.
This doesn't actually affect the functionality
of the communities in any way.
However, it is much nicer.
So now that we have that in there,
let's go ahead and configure our router.
So we're going to router BGP 65001.
Now we haven't really looked at the running configuration
on router 7.
If we do a show run section BGP, what we need to see here
is we're actually using peer policy templates and peer
session templates here on router 7.
Now, we could still put these commands directly
on the neighbors, but it's going to make a lot more sense
to use these templates since we already have them here.
So we're going to say template peer-policy Main.
Now we're not trying to apply the route-map to all
the neighbors, but we are trying to get it to send communities,
and we have to tell iOS XE to do that.
So we have to say send-community.
Then we have to choose if we want to send
extended, standard, or both.
By the way, all of this is simply about the fact
that iOS XE does not send communities by default.
So since we're going to write a route-map that's
setting communities, and then apply it to a neighbor,
it would probably help if we were actually
sending those communities.
The default behavior, like I said, is not to.
So all we're really doing is enabling
a feature, the ability to send communities.
It doesn't mean it's going to start magically doing that.
The reason I'm saying it this way is I usually turn on both.
Some people look at this and say, well, you're
not even using extended communities right now.
That's true.
I'm not.
But on the other hand, it doesn't really
hurt to turn them on even if you're not using them,
and then you would be ready to use them in the future
if you wanted to.
So when I'm enabling communities on the router,
I usually do both just because it
doesn't hurt to have them enabled
even if you're not using them.
So we'll just go ahead and do both.
Now at this point, we're probably
going to want a peer-policy specifically
for service provider 1, so let's go ahead and create one.
So we'll say template peer-policy,
and let's just call it something like SP1.
And what we're going to do is we're
going to apply our route-map, so route-map RM_TWO_SP1,
and that would be applied outbound.
And then, of course, just like the other peer policies,
we're going to tell this to inherit.
Now when you're inheriting these,
you have to give it a sequence number
because if you're inheriting more than one policy,
they have to be inherited in a specific order.
Now in this case, we're only inheriting one policy,
so it doesn't really matter.
We'll say to inherit this one first.
Now let's configure our neighbors
we'll start with 50.0.167.1, that's router 1's address.
And what are we going to do?
We're going to tell it to inherit peer-policy SP1.
Then we're just going to hit the up arrow,
and we'll change our neighbor statement.
This is going to be for 10.3.3.3.
So just a quick recap of what we had to configure here.
We had to set up our route-map, which goes ahead
and sets the community on the updates being sent out
to service provider 1.
Then we updated our Main peer-policy
to tell it to send communities both extended and standard.
Then we created a new peer template
that inherits the main template and applies our new route map.
We then configured both of our neighbors router 1
and router 3 in service provider 1 or AS 100 to then
inherit that new policy that we put on the neighborship.
So now we should be able to clear our outbound updates
and see the changes actually happen on router 1
and router 3.
Now before we actually do that, let's set up a Wireshark
capture just on router 1, so we can see this update coming in
and take a look at the community strings on that update.
So I started up that Wireshark capture.
We've seen that quite a few times.
I don't think we need to see the setup,
but let's go ahead and do our clear now.
So first, let's go to router 1 and see if it got the updates.
We'll just do a show BGP for our prefix.
And what we see here is our first path
is the path through AS 1000.
It has the default local preference of 100,
and therefore, is being chosen as best.
The route that we did not want to use, the one from router 7,
we can see is now being set to a local preference of 80 exactly
as we wanted.
And we can see the community of 100:80 attached to this update.
So now let's go take a look at what
this looks like in Wireshark.
So looking here in Wireshark, we can
see that we've received this update from router 7.
And if we look down in the update itself,
first for the NLRI, we can see that this is in fact,
for the 100.8.8.0/24 prefix.
And then here under the path attributes,
we can see quite clearly where it's carrying
that community of 100:80.
Now just as one final verification just
to make sure everything's working as it should be,
let's also verify this on router 3.
So on router 3 we'll just do a show BGP.
And what we see is that for the 100.8.8.0/24 prefix,
the next hop of 10.1.1.1 has been selected going to an AS
path of the 10000 65001.
So this has also worked where it's not
trying to go directly to router 7,
but rather going up to router 1 who's
then going over to AS 1000.
So this is local preference being
manipulated by community strings working exactly as we designed.
In this video, we took a look at how
to use communities to actually manipulate inbound BGP path
selection.
And we do this by sending a specific community
to our neighboring AS who then has a policy implemented
to do something with that prefix, such as change
the local preference, which is what we did.
Theoretically, they could also change
the weight or some other BGP attribute
to influence the path selection, but local preference
is a very common thing to do here.
So in that way, we actually influenced the outbound path
selection of our neighboring AS, which,
of course, is effectively our inbound path selection.
I hope this has been informative for you,
and I'd like to thank you for viewing.