|
0:00:13
|
Our next topic here in BGP
|
|
0:00:16
|
is the BGP community attribute
|
|
0:00:19
|
that is essentially BGP's implementation of a route tag.
|
|
0:00:24
|
Now, we saw it previously when we were dealing with IGP redistribution
|
|
0:00:27
|
that we could use route tagging in order to group prefixes together
|
|
0:00:32
|
for a common filtering policy.
|
|
0:00:35
|
Now, in the case of BGP, we can use this tag value or the community value
|
|
0:00:39
|
not only for a filtering policy,
|
|
0:00:42
|
but to control how prefixes are going to be advertised
|
|
0:00:46
|
whether they should be advertised to internal peers or external peers,
|
|
0:00:49
|
or a certain subset of peers,
|
|
0:00:51
|
and also, grouping them together for the purposes of best path selection.
|
|
0:00:57
|
Now, I already mentioned the case where communities are used in the Internet
|
|
0:01:01
|
to signal that the local preference should be changed for particular routes,
|
|
0:01:05
|
and we'll see that the community policies also generally can be used
|
|
0:01:09
|
to make other attribute changes
|
|
0:01:11
|
like the AS path information,
|
|
0:01:13
|
or whether the prefix is gonna be advertised to external peers versus internal peers,
|
|
0:01:19
|
or peers that are within the local sub-AS for confederation.
|
|
0:01:26
|
Now, one of the key points to remember about communities
|
|
0:01:29
|
is that they are an optional transitive attribute,
|
|
0:01:33
|
which means that they are not exchanged between the peers by default.
|
|
0:01:38
|
This is gonna be true both of iBGP peers and EBGP peers.
|
|
0:01:43
|
Anytime that we want to include the community value with the update,
|
|
0:01:47
|
we do need to add the additional neighbor command that has the send community argument on to it.
|
|
0:01:53
|
Now, we'll see later when we get into Layer 3 MPLS VPNs,
|
|
0:01:57
|
BGP extended community attributes
|
|
0:01:59
|
will be used to encode additional information
|
|
0:02:03
|
like the MPLS VPN route tag,
|
|
0:02:06
|
or excuse me, the route target.
|
|
0:02:09
|
Then, a different protocol specific attribute like the EIGRP cost community,
|
|
0:02:13
|
the OSPF domain ID, the OSPF originator ID
|
|
0:02:17
|
for updates that are encoded inside of multiple protocol BGP.
|
|
0:02:22
|
But for our implementation today, we're looking at just the standard community attributes,
|
|
0:02:27
|
which are essentially number values
|
|
0:02:31
|
that are a 4-byte value.
|
|
0:02:35
|
Now, there's two different ways that we can denote these
|
|
0:02:37
|
either just as a flat decimal value,
|
|
0:02:40
|
and as you can see, by the range of numbers from 0 to 4.2 billion,
|
|
0:02:44
|
a lot of the times, it's hard to read what the particular number is,
|
|
0:02:48
|
and what it's actual affect that it's gonna have on the network is.
|
|
0:02:52
|
So, visually, a lot of the times, it's easier to denote this as two separate 2-byte values,
|
|
0:02:58
|
where the first portion of the community is the autonomous system number
|
|
0:03:03
|
and the second portion is some locally significant value to that particular AS.
|
|
0:03:09
|
Whereas if I am AS 100, the community 100:1 would be significant to me.
|
|
0:03:17
|
Now regardless of which type that we're using,
|
|
0:03:20
|
the decimal notation or the new format notation,
|
|
0:03:25
|
the community value is still gonna be the same in binary in the actual update.
|
|
0:03:30
|
So, o whether we issue the IP BGP community new format command or not,
|
|
0:03:34
|
it's not gonna change the actual value of the community that is either matched or set in the actual BGP update.
|
|
0:03:42
|
So, the AS:notation is just for us visually
|
|
0:03:47
|
to figure out what exactly the community is referring to.
|
|
0:03:52
|
Now, out of these values, there are three well-known reserved communities
|
|
0:03:57
|
that are no export, no advertised and local AS.
|
|
0:04:02
|
So, you can see the specific values of those in hex there.
|
|
0:04:06
|
It means that when you're saying on the IOS command line,
|
|
0:04:09
|
Set Community No Export,
|
|
0:04:11
|
you're actually setting it to FFFFFF01.
|
|
0:04:17
|
Now, these three well-known communities, what they are gonna control
|
|
0:04:20
|
is what type of peer
|
|
0:04:23
|
can a particular prefix be advertised to
|
|
0:04:25
|
if the route is in the community no export versus no advertised versus local AS.
|
|
0:04:33
|
Where the first to the well-known communities no export these that were not advertise this to EBGP peers.
|
|
0:04:39
|
This means through EBGP peers,
|
|
0:04:42
|
this is unrelated to confederation EBGP peers.
|
|
0:04:48
|
No advertised community means we're not gonna advertise it to any peer
|
|
0:04:51
|
regardless of whether they are iBGP, EBGP, or confederation EBGP,
|
|
0:04:57
|
and lastly local AS means we're gonna advertise the routes to confederation EBGP peers
|
|
0:05:03
|
or regular EBGP peers.
|
|
0:05:07
|
So, this one is specifically for confederation
|
|
0:05:10
|
where we're trying to keep a prefix inside or sub-autonomous system
|
|
0:05:14
|
where sometimes, this is defined as no export sub-confed.
|
|
0:05:20
|
Now, for local AS and no export,
|
|
0:05:22
|
if we are not using confederation,
|
|
0:05:24
|
then, local AS is gonna behave exactly the same as no export.
|
|
0:05:29
|
So, you can use the two interchangeably if you're not in confederation.
|
|
0:05:34
|
If you are in confederation, then, they will behave differently.
|
|
0:05:37
|
Where no export will be passed between the confederation EBGP peers.
|
|
0:05:42
|
So, it means it can go between the sub-ASs,
|
|
0:05:45
|
where local AS is gonna say just inside
|
|
0:05:48
|
that one particular sub-autonomous system.
|
|
0:05:52
|
So, essentially, we're grouping these together in order to implement a filtering policy.
|
|
0:05:58
|
The rest of the values, we can use it for setting any arbitrary policy that we want.
|
|
0:06:03
|
So, we could say, set the community to be 1.2.3.4.
|
|
0:06:07
|
And then, based on that, we're gonna match the community 1.2.3.4
|
|
0:06:09
|
and set some type of BGP attribute or either permit or deny the route.
|
|
0:06:17
|
Now, in order to do this,
|
|
0:06:20
|
we'll use a route map with BGP that's gonna apply on to the peer,
|
|
0:06:25
|
but there is a difference in the implementation of setting the community versus matching the community.
|
|
0:06:31
|
And it's a very common mistake that we see an implementation
|
|
0:06:35
|
where the setting of the community can occur directly inside the route map.
|
|
0:06:41
|
So, we can say Set Community No Export, Set Community No Advertised,
|
|
0:06:46
|
but when we are matching the community,
|
|
0:06:50
|
it has to be matched from inside the community list.
|
|
0:06:54
|
So, the common mistake for this,
|
|
0:06:57
|
if we were to look at the command line
|
|
0:06:59
|
would be to say under a route map,
|
|
0:07:05
|
let's say, Route Map Match No Export
|
|
0:07:11
|
that says Match Community No-Export.
|
|
0:07:17
|
Then, if we Show Run Section Route Map,
|
|
0:07:23
|
we'll see that this configuration does show up in the running config it says, Match Community No Export.
|
|
0:07:28
|
But the problem is if we look in more detail in this particular syntax,
|
|
0:07:35
|
and look at the match community question mark,
|
|
0:07:40
|
this is actually a community list name.
|
|
0:07:44
|
So, instead of actually matching the community value no export,
|
|
0:07:47
|
we're matching a community list name which name is No-Export.
|
|
0:07:54
|
So, for setting communities, that can occur directly inside of the route map.
|
|
0:07:57
|
Where for matching them, it has to be called from a list first.
|
|
0:08:04
|
Now, with the list of values, there's two different types, there are standard lists and expanded lists,
|
|
0:08:10
|
-where the standard list are gonna match the exact community name or number
|
|
0:08:13
|
like no export no advertise community 100:1
|
|
0:08:18
|
and the expanded community is gonna match regular expression.
|
|
0:08:23
|
So, in this case, we're saying IP Community List Expanded AS 100 Permit 100:
|
|
0:08:29
|
A range of digits 0 through 9,
|
|
0:08:34
|
Then one or more instance of the previous character.
|
|
0:08:39
|
So, in a few minutes, we'll talk about regular expressions here, but essentially what this means
|
|
0:08:44
|
is match any community value that starts with 100:
|
|
0:08:48
|
It would match 100:0 from all the way up to 100:65535.
|
|
0:08:56
|
Then, once we have specified the community list name,
|
|
0:08:59
|
then, we're gonna match that from inside of the route map.
|
|
0:09:03
|
But the key here is that if we are setting, it set directly in the route map,
|
|
0:09:06
|
but when we're matching, it has to be called indirectly from the community list.
|
|
0:09:17
|
Additionally, if we look back at the the route map syntax,
|
|
0:09:21
|
and say Set Community,
|
|
0:09:25
|
we can specify a decimal value,
|
|
0:09:29
|
we can specify it in the AS:notation.
|
|
0:09:34
|
The well-known communities, or local AS, no advertise, or no export.
|
|
0:09:38
|
The Internet community technically, everything is in that by default.
|
|
0:09:42
|
So, it's the same as the null community.
|
|
0:09:44
|
Set Community None would be to strip an advertisement of its community values.
|
|
0:09:51
|
Then, set community additive
|
|
0:09:54
|
means to add whatever community attribute that you want on to the prefix,
|
|
0:09:59
|
but don't remove the previous values.
|
|
0:10:05
|
So, if we look at our particular topology
|
|
0:10:08
|
this would mean that router 5 could set a community out of router 4 that is 100:1.
|
|
0:10:16
|
Router 4 could set a community that is 54:2 out to BB3,
|
|
0:10:22
|
and one router 4 does this, if it says, Set Community Additive,
|
|
0:10:26
|
then, it is not going to strip the original value of 100:1.
|
|
0:10:33
|
So, as I mentioned previously, generally on the Internet, the communities will be additive.
|
|
0:10:38
|
Technically, the providers don't have to honor the community values that can strip them.
|
|
0:10:43
|
It's just had a bad etiquette for them to do that.
|
|
0:10:45
|
So generally, all the Tier 1 providers, they will allow you to transit your community attributes through them
|
|
0:10:52
|
in order to affect some sort of path selection for a ASs that are multiple hops away.
|
|
0:10:59
|
So, let's look at a couple of of examples here of using the well-known community values,
|
|
0:11:04
|
and then using the numbered community values in order to change the path selection
|
|
0:11:09
|
and also to implement a filtering policy.
|
|
0:11:14
|
Now, the first thing to remember again about the community attribute
|
|
0:11:18
|
is that it is on optional transitive attribute, which means that it is not exchanged by default
|
|
0:11:25
|
If we do exchange it, it will go between both EBGP and iBGP peers,
|
|
0:11:30
|
but it's not processed automatically.
|
|
0:11:33
|
This means that if we do not have the Send Community command,
|
|
0:11:37
|
it is going to not only not set a community out,
|
|
0:11:41
|
but it will automatically strip all the community values as the updates are going out.
|
|
0:11:53
|
So first, let's look at this from inside of AS 400.
|
|
0:11:58
|
Switch 4 is generating
|
|
0:12:00
|
an advertisement for its loopback zero interface.
|
|
0:12:04
|
If I wanted to constrain this particular advertisement to stay inside AS 400,
|
|
0:12:10
|
I have a bunch of different options in BGP.
|
|
0:12:12
|
I could just simply do a filter with an access list or prefix list,
|
|
0:12:16
|
and on the network edge, on router 5, configure it not to advertise this out to the other BGP peers.
|
|
0:12:25
|
But the key with the community attribute is that it's very flexible
|
|
0:12:29
|
because as long as the routers are processing the community attribute to begin with,
|
|
0:12:34
|
then, we could set the value anywhere throughout the entire autonomous system,
|
|
0:12:37
|
and it's going to affect all of the neighbors automatically.
|
|
0:12:42
|
So, in order to do this first step would be to make sure that we are actually exchanging
|
|
0:12:47
|
the community attribute between the neighbors.
|
|
0:12:49
|
So, let's go to the command line on switch 4,
|
|
0:12:56
|
and if we look at the current configuration for BGP,
|
|
0:13:03
|
we see that with our current neighbor who is switch 2 right now were not exchanged the community attribute.
|
|
0:13:09
|
So, we need to go to router BGP 400.
|
|
0:13:12
|
Say Neighbor 150.28.8.8.
|
|
0:13:17
|
I want to Send Communities.
|
|
0:13:23
|
From switch 2, if we Show IP BGP Summary,
|
|
0:13:28
|
I would also want to send communities out to router 5 and to switch 4.
|
|
0:13:33
|
Technically, you do not have to do it in both directions,
|
|
0:13:37
|
but really, there's no reason why you would not to.
|
|
0:13:39
|
So, in any new implementation of BGP,
|
|
0:13:42
|
whenever you're turning the the process on for the first time,
|
|
0:13:45
|
in production, not within the scope of the lab exam,
|
|
0:13:48
|
but in a real design, you would want to enable the community attribute.
|
|
0:13:53
|
Within the scope of the lab exam, it just depends on whether you're actually gonna need it based on the question.
|
|
0:13:58
|
So, as long as the question does not say, "Don't use communities",
|
|
0:14:01
|
then, you're not gonna lose any points by adding the send community command.
|
|
0:14:06
|
But the key is that...
|
|
0:14:07
|
if you want to use the community attribute, then, you do have to specify the syntax, Send Community
|
|
0:14:13
|
to whatever particular neighbor you wanna send in. For both iBGP and EBGP.
|
|
0:14:26
|
So now, I have the send community configured from switch 4 to switch 2,
|
|
0:14:31
|
switch 2 to switch 4, and switch 2 to router 5.
|
|
0:14:36
|
This should now mean, if I were to set a community value on switch 4,
|
|
0:14:40
|
it should be propagated both the switch 2 and to router 5.
|
|
0:14:48
|
To do this, let's go on to the BGP process of switch 4,
|
|
0:14:53
|
and we could see previously, we had a network statement for our loopback.
|
|
0:14:57
|
And now, I'm gonna change the attributes locally as I'm originating the network
|
|
0:15:04
|
with a route map that is gonna specify, "This is in the community No-Export."
|
|
0:15:11
|
So, in route map no export, I'll say, Set Community No...
|
|
0:15:17
|
No Export.
|
|
0:15:19
|
Then, under BGP 400,
|
|
0:15:24
|
network...
|
|
0:15:27
|
150.28.10.10...
|
|
0:15:33
|
is using the route map no_export.
|
|
0:15:46
|
Now, since I said the route map locally on the network statement itself,
|
|
0:15:50
|
this now means when I locally on switch 4 look at the Show IP BGP 150.28.8.0/24,
|
|
0:15:59
|
if this setting was correct,
|
|
0:16:01
|
I should now see this as the community no export. Actually, 10.0.
|
|
0:16:07
|
Which it is.
|
|
0:16:09
|
We see the community value no export.
|
|
0:16:12
|
Now, technically, this would be the same as saying, "Set the community to be...
|
|
0:16:17
|
whatever the decimal value equivalent of FFFFFF01 is.
|
|
0:16:24
|
So, this keyword, no export is just a shortcut for whatever binary value that is
|
|
0:16:28
|
pretty actual community no export.
|
|
0:16:32
|
Now, since switch 4 is sending the community attribute to switch 2,
|
|
0:16:37
|
on switch 2, we could look at the Show IP BGP Community,
|
|
0:16:41
|
which looks at our BGP table,
|
|
0:16:44
|
and outputs whatever prefixes have community set,
|
|
0:16:49
|
we could also look at the Show IP BGP Community No Export,
|
|
0:16:55
|
which specifically lists what prefixes are in no export.
|
|
0:16:59
|
Or we could say, Show IP BGP 150.28.10.0/24.
|
|
0:17:05
|
This is gonna show us the specific details about this prefix,
|
|
0:17:08
|
and it should be in the community no export.
|
|
0:17:13
|
We can see, it is being advertised to our update group,
|
|
0:17:16
|
which essentially is our route reflector clients here.
|
|
0:17:20
|
But it says, it's not gonna be advertised to any EBGP peers,
|
|
0:17:26
|
because community no export means don't advertise to EBGP neighbors.
|
|
0:17:31
|
So now, once we get to router 5, if we look at the same thing,
|
|
0:17:35
|
Show IP BGP for 150.28.10.0/24.
|
|
0:17:40
|
It says, the community is no export.
|
|
0:17:44
|
We can see, it's not being advertised to any peer.
|
|
0:17:47
|
If we were to look at the Show IP BGP Neighbor Advertised Routes,
|
|
0:17:50
|
we would see router 5 is not including this in the updates that are going to either...
|
|
0:17:55
|
routers 1, 2, 3, or 4.
|
|
0:18:00
|
If we Show IP BGP Summary,
|
|
0:18:04
|
we can see those four neighbors, 1, 2, 3, and 4,
|
|
0:18:08
|
1, 2, 3, and 4, they are in different autonomous systems
|
|
0:18:11
|
than us locally we are in AS 400,
|
|
0:18:15
|
which means that we would not send them any prefix that is in the community no export.
|
|
0:18:22
|
So, there's a lot of different uses for these particular communities
|
|
0:18:25
|
whether we're looking at the numbered value or the...
|
|
0:18:30
|
the well-known communities.
|
|
0:18:32
|
Another potential application would be to prevent our autonomous system from being used as transit.
|
|
0:18:39
|
So, let's say that AS 300 is an end customer of 100 and 400,
|
|
0:18:45
|
and we wanna make sure that there's no circumstance the traffic comes into our AS,
|
|
0:18:50
|
and then goes back out to another autonomous system.
|
|
0:18:55
|
This means as router 3 received routes in,
|
|
0:18:59
|
we shouldn't advertise the router 1.
|
|
0:19:02
|
And we shouldn't advertise them likewise from switch 1 to router 6,
|
|
0:19:05
|
or when 6 sends them into switch 1, router 3 should not advertise them out to any other EBGP peers.
|
|
0:19:13
|
So, to implement this with communities,
|
|
0:19:16
|
we could say on both router 3 and switch 1,
|
|
0:19:19
|
as updates are received from all of our EBGP peers,
|
|
0:19:24
|
we could set the community to be no export.
|
|
0:19:28
|
Or we could technically set it to be local AS.
|
|
0:19:32
|
Because when we are not in confederation,
|
|
0:19:35
|
community local AS is gonna behave the same as community no export.
|
|
0:19:41
|
Then, the third one, no advertise simply means we're not gonna advertise it to any peer.
|
|
0:19:46
|
Either iBGP, EBGP, or confederation EBGP.
|
|
0:19:53
|
Now, as for the numbered values,
|
|
0:19:56
|
we can use these basically just as a route tag
|
|
0:19:58
|
to do any type of filtering or any type of attribute change
|
|
0:20:01
|
that we manually define under the route-map.
|
|
0:20:04
|
So, it's very flexible as to the policy that we can define.
|
|
0:20:07
|
It's just a simple way to group the different prefixes together based on the particular value.
|
|
0:20:14
|
So, let's now say for example on...
|
|
0:20:18
|
switch 4 and switch 2,
|
|
0:20:21
|
when we are originating the VLAN 10 interface and VLAN 8 interface,
|
|
0:20:26
|
we're gonna set the community to be 400:1.
|
|
0:20:32
|
This should then mean when the prefixes are sent to router 5.
|
|
0:20:35
|
Router 5 receives them as community 400:1.
|
|
0:20:39
|
Then we'll say as we send updates out to router 4,
|
|
0:20:43
|
if the community 400:1 is there,
|
|
0:20:47
|
we'll do AS path prepending in order to add our...
|
|
0:20:51
|
autonomous system path one time.
|
|
0:20:55
|
I'll also say that if the community is 400:2,
|
|
0:20:59
|
I'm gonna add our autonomous system path 2 times.
|
|
0:21:04
|
So, first let's go to router 5 and we'll define the policy where we are matching the communities.
|
|
0:21:10
|
This would be with the IP community list.
|
|
0:21:14
|
Again the standard one is gonna match the community name or number
|
|
0:21:17
|
where the expanded list is gonna match a regular expression.
|
|
0:21:22
|
Also, community list standard, I'm gonna give it a name of 400:1.
|
|
0:21:28
|
Just for clarity so I know that this is actually matching community 400:1.
|
|
0:21:35
|
So in this case the name of the the list is the same as the community I'm matching.
|
|
0:21:41
|
To make a little bit easier to remember what the values that you're matching on the list are.
|
|
0:21:47
|
I'll have a separate list that is 400:2 that says permits 400:2.
|
|
0:21:55
|
Next I'll have a route-map that is going out to router 4.
|
|
0:22:01
|
This is sequence number 10, so, permit 10.
|
|
0:22:05
|
If the community is the match in the list 400:1,
|
|
0:22:11
|
Then I'm gonna set AS path prepending one time.
|
|
0:22:16
|
So, I'll set 400 once.
|
|
0:22:20
|
Then sequence number 20,
|
|
0:22:22
|
if the community is 400:2, I'm gonna do prepending twice.
|
|
0:22:32
|
For everything after that, I'm simply going to allow a truce, so, I'll say permit 1000.
|
|
0:22:39
|
Next under the BGP process router BGP...
|
|
0:22:45
|
Router BGP 400, I'm going to apply this out to router 4.
|
|
0:22:52
|
So, a route-map to router 4...
|
|
0:22:57
|
out.
|
|
0:23:01
|
So, now, when I originate prefixes into AS 400,
|
|
0:23:04
|
if I tag them with 400:1, we should see that the prefix is prepended once as it goes out to router 4.
|
|
0:23:11
|
But if it's set to 400:2, it's gonne be prepended twice.
|
|
0:23:17
|
So, next on switch 2, I'm going to originate a route.
|
|
0:23:21
|
And we'll have it prepended twice.
|
|
0:23:24
|
So, on switch 2, let's say route-map set community
|
|
0:23:30
|
that will set the community to 400:2.
|
|
0:23:36
|
Next, under the BGP process, this is going to correspond to my LAN interface,
|
|
0:23:41
|
which is 155.28.8.0...
|
|
0:23:46
|
/24. I'll use the route-map, set...
|
|
0:23:52
|
community.
|
|
0:23:57
|
If we look at the show IP BGP for 155.28.8.0,
|
|
0:24:03
|
we can see the community value has been set.
|
|
0:24:08
|
But by default, the show output is gonna come up in the decimal format for the community.
|
|
0:24:16
|
Now, there's no difference again in binary from this value here,
|
|
0:24:22
|
which is 26 million versus the 400:2.
|
|
0:24:27
|
The only difference is that from our perspective, a lot of times it's easier to read 400:2
|
|
0:24:31
|
as opposed to 26,214,402.
|
|
0:24:38
|
So therefore, in global config, I'll also say IP BGP community new format.
|
|
0:24:44
|
Again, this is not changing the value of the community,
|
|
0:24:47
|
just it changes the output of the show command.
|
|
0:24:52
|
If I now look at router 4, and look at the Show IP BGP regular expression_400$,
|
|
0:25:01
|
So, I'm looking at prefixes that originated in AS 400.
|
|
0:25:06
|
Note that the prefix 155.28.8.0 is being prepended twice
|
|
0:25:12
|
as it is being received in the peering directly from router 5.
|
|
0:25:21
|
Now, there's also a second route to this
|
|
0:25:24
|
that says, it's via the same hop, the next hop value 155.28.0.5.
|
|
0:25:29
|
But if we Show IP BGP for 155.28.8.0,
|
|
0:25:34
|
I'm actually learning this from two separate neighbors.
|
|
0:25:36
|
One of them is coming from router 1, one of them is coming directly from router 5.
|
|
0:25:41
|
The reason that we see both of them is the next top value of router 5,
|
|
0:25:46
|
is that when 5 sends this update to 1, and 1 sends it to 4,
|
|
0:25:53
|
this is an EBGP learned route being sent to on an iBGP neighbor.
|
|
0:25:59
|
So, router 1 is not changing the next hop value.
|
|
0:26:04
|
Only if router 1 were to say next hop self
|
|
0:26:07
|
or manually use a route-map in order to modify the next hop value when we see that changed.
|
|
0:26:14
|
Now, if I were to change the community attribute to be 400:1,
|
|
0:26:19
|
then router 5 would only prepend this once as it goes out to that particular neighbor.
|
|
0:26:24
|
But the key point here with these communities
|
|
0:26:27
|
is that in the real world, the service providers will have standard templates are defined
|
|
0:26:32
|
that you can use different community values in order to signal them to change
|
|
0:26:37
|
how your routes are received or how they're advertised.
|
|
0:26:42
|
So, if we were again to look at like AT&T's policy,
|
|
0:26:45
|
not only does it say that 7018:100 through 70,
|
|
0:26:49
|
it means that were gonna change the local preference,
|
|
0:26:52
|
it says that if we were to, actually this one doesn't say the details of the policy.
|
|
0:27:00
|
Let's look for, let's say Level 3 BGP community policy.
|
|
0:27:09
|
And this website here, onesc.net, it has a lot of this information about BGP.
|
|
0:27:20
|
It says that depending on where the prefix was received from,
|
|
0:27:26
|
so based on the physical location, it's gonna get different community values.
|
|
0:27:31
|
So, Level 3 must be 3356.
|
|
0:27:34
|
But if we look at the values that it is applying or that they are specifying,
|
|
0:27:40
|
it says that if you give us 65001:0, we're gonna prepend once to all peers.
|
|
0:27:50
|
But if you set us 65001:XXX, where XXX is the remote AS number,
|
|
0:27:58
|
we're gonna prepend once to all peerings at that particular AS number.
|
|
0:28:05
|
Now, what this essentially means, if we were to look at the peerings for Level 3 visually,
|
|
0:28:12
|
Level 3 then is 3356, where AT&T is 7018.
|
|
0:28:22
|
Let's say that we are a customer of Level 3,
|
|
0:28:31
|
and we're also a customer of Sprint.
|
|
0:28:38
|
Okay, Sprint is peering with AT&T as well.
|
|
0:28:42
|
So, now, I want return traffic from AT&T to use Sprint to get to me and not use Level 3.
|
|
0:28:51
|
But I know based on Level 2's policy, if I set the community to be 65001:7018,
|
|
0:28:59
|
it means that when they're sending the advertisement out there,
|
|
0:29:04
|
they're automatically gonna prepend 3356.
|
|
0:29:11
|
So, what essentially means on the provider edge routers of the internet,
|
|
0:29:15
|
they have these giant standardized route-map policies
|
|
0:29:20
|
that say, match these particular communities and if that community is true,
|
|
0:29:24
|
then I'm going to set these particular attributes.
|
|
0:29:26
|
Whether it'd be prepending or setting local preference.
|
|
0:29:30
|
A lot of times, you'll also see this can be used for filtering
|
|
0:29:34
|
there's certain values I could say, like I don't want to advertise this to my European peers,
|
|
0:29:38
|
I only want to advertise it to US West Coast or East coast.
|
|
0:29:41
|
But policies can get very granular, depending on the particular provider that you are peering with.
|
|
0:29:56
|
Now, again, for the expanded community lists,
|
|
0:29:58
|
that's gonna be using a regular expression to figure out what the particular community value is.
|
|
0:30:04
|
Which means in order to implement this,
|
|
0:30:05
|
we need to know what is the regular expression syntax look like.
|
|
0:30:10
|
Now, regular expressions is gonna be used for a bunch of different applications in IOS.
|
|
0:30:15
|
And it's not an IOS specific thing.
|
|
0:30:17
|
It's generally a standardized open source version of regular expressions that a lot of different...
|
|
0:30:26
|
a lot of different codes are gonna use.
|
|
0:30:29
|
Now, specifically in IOS, some of the things that we can use this for
|
|
0:30:32
|
would be filtering the show command outputs.
|
|
0:30:35
|
Like when we say Show Run Include...
|
|
0:30:38
|
We could match against a regular expression or Show IP Route, match against a reg exp.
|
|
0:30:43
|
It could also be used in the TCL or the EEM scripting
|
|
0:30:48
|
in order to filter through different types of output.
|
|
0:30:51
|
For our case, most of the time is either gonna be for a BGP AS path access list.
|
|
0:30:57
|
Or for the BGP expanded community list.
|
|
0:31:01
|
Where the AS path access list is gonna match the AS path value of the update.
|
|
0:31:06
|
So, we could match prefixes that came from as 100
|
|
0:31:10
|
or were passed through AS 200 or relearned through AS 300
|
|
0:31:16
|
based on the particular string matching that we do.
|
|
0:31:20
|
Now, in order to use these, the key is that you need to know the syntax exactly.
|
|
0:31:24
|
Because just like the EEM scripting and the TCL scripting,
|
|
0:31:28
|
it's basically programming syntax, so, it has to be exact.
|
|
0:31:30
|
The IOS is not gonna give you context sensitive help
|
|
0:31:33
|
as to what the regular expression is supposed to say.
|
|
0:31:37
|
Now, it will generally give you an error message if you're regular expression cannot be compiled.
|
|
0:31:44
|
Which means it has some major syntax error.
|
|
0:31:46
|
It'll just simply say that that is not valid or regular expression failed to compile.
|
|
0:31:54
|
Now, the documentation path for this is kind of strange if you didn't already know where it was.
|
|
0:31:58
|
So, one of those kind of things, it would be very, very difficult to locate.
|
|
0:32:03
|
So, if we go to the main documentation page,
|
|
0:32:06
|
from the 12.4 T configuration,
|
|
0:32:09
|
then go all the way down to the bottom
|
|
0:32:12
|
to the terminal services configuration guide.
|
|
0:32:17
|
It's under the appendix then Regular Expressions.
|
|
0:32:24
|
And the reason that you may want to see this document
|
|
0:32:26
|
is that there's the list of what are the actual characters
|
|
0:32:31
|
that we would need to match against.
|
|
0:32:36
|
Now, as I mentioned earlier, one of the...
|
|
0:32:41
|
one of the uses for the route servers that I was telnetting into before,
|
|
0:32:45
|
it could be to test out the regular expressions to see how the pattern matching works
|
|
0:32:50
|
against much longer AS path information.
|
|
0:32:54
|
Because whether you're doing these exercises on our equipment
|
|
0:32:57
|
or you're rack somewhere else.
|
|
0:33:00
|
Unless you have very diverse AS path information that you've configured,
|
|
0:33:03
|
a lot of times it's hard to figure out exactly what the different regular expressions are used for.
|
|
0:33:10
|
So, if we go to the command line
|
|
0:33:12
|
and open a connection to one of the route servers, let's say routeviews.org.
|
|
0:33:26
|
From here, if we look at the Show IP BGP,
|
|
0:33:31
|
we can see that the AS path information is fairly long for these prefixes.
|
|
0:33:37
|
Now, we see that some of the routes are being originated by 44101, this particular prefix.
|
|
0:33:47
|
The next ones are coming from 4725.
|
|
0:33:49
|
If we were to match the autonomous system number
|
|
0:33:53
|
that is the originator of the prefix,
|
|
0:33:56
|
this is gonna be the one that is the rightmost value in the path.
|
|
0:34:01
|
So, from a regular expression logic,
|
|
0:34:04
|
this means that we want to find the number followed by the ($), which is the end of the line.
|
|
0:34:15
|
So, ($) is the end of the line where (^) is the beginning of the line.
|
|
0:34:20
|
On (_), either match is the beginning of the line, the end of the line,
|
|
0:34:25
|
a space or other special characters like a brace or comma.
|
|
0:34:31
|
Within the case of the AS path access lists,
|
|
0:34:34
|
it generally means, it's gonna match the beginning, the end or a space.
|
|
0:34:40
|
So, this then means, if I were to say Show IP BGP
|
|
0:34:46
|
Reg Exp_7018$, this would show me any prefixes that were originated by 7018.
|
|
0:34:56
|
If I said Show IP BGP regular expression
|
|
0:35:03
|
^3356_,
|
|
0:35:08
|
This would be the prefixes that I am learning from AS 3356.
|
|
0:35:15
|
If I were to look for any value with two underscores,
|
|
0:35:23
|
Let's say Show IP BGP Reg Exp_100_,
|
|
0:35:31
|
this would then match any route that was either originated in 100
|
|
0:35:36
|
learned from 100 or passed through 100.
|
|
0:35:41
|
So, any instance of that value, could be at the beginning, could be in the middle, could be at the end.
|
|
0:35:48
|
So, a couple of the common expressions that we would want
|
|
0:35:51
|
would be _100$, which means originated in 100.
|
|
0:36:00
|
^100_, which would mean learn from 100.
|
|
0:36:05
|
_100_, would be any instance of 100.
|
|
0:36:11
|
So, whether it's learn from them, originated from them, or transitted through them.
|
|
0:36:17
|
A (.) is any character. An (*) means 0 or more. So, (.*) would be anything.
|
|
0:36:26
|
Between the brackets, this matches a range. So if I were to say, 0 to 9,
|
|
0:36:33
|
this would mean any number.
|
|
0:36:37
|
(+) is one or more.
|
|
0:36:40
|
So, if I were to say, a range of 0-9+, this means any number of digits.
|
|
0:36:50
|
Or essentially one a utonomous system.
|
|
0:36:53
|
So, let's say, I want to search for AS paths that are exactly two ASs long.
|
|
0:36:59
|
I could then say Show IP BGP Reg Ex.
|
|
0:37:03
|
^[0-9]+
|
|
0:37:10
|
Then there's a space.
|
|
0:37:14
|
Then again [0-9]+
|
|
0:37:20
|
then the end of the line $.
|
|
0:37:24
|
So, this would be exactly two ASs long.
|
|
0:37:34
|
The parentheses are either used for a mathematical grouping or for recall,
|
|
0:37:41
|
where if I wanted to match, let's say, all ASs that are prepended.
|
|
0:37:48
|
I could say, look for any particular AS number.
|
|
0:37:55
|
So I'll say inside parentheses ([0-9]+
|
|
0:38:09
|
then there's a space after that followed by a closed parenthesis. ([0-9]+)
|
|
0:38:14
|
Then if I say backslash 1, this means reiteration of whatever is in the first parentheses that I defined.
|
|
0:38:25
|
So this should then mean, match one particular AS number
|
|
0:38:31
|
and then reiterate it again
|
|
0:38:32
|
Now, sometimes, you'll see in the route servers, there's certain...
|
|
0:38:35
|
regular expressions that are disallowed
|
|
0:38:38
|
because some different versions of IOS, they actually have bugs in the reg exp engine.
|
|
0:38:43
|
Where you can actually crash the router by giving it on infinite loop of the reg exp search.
|
|
0:38:51
|
So, let's try these on one of the other ones. Let's see if AT&T will allow us to do this.
|
|
0:38:57
|
This one's fine. So now, if we look at this
|
|
0:39:00
|
AS path output, this is gonna match only AS paths that are prepended.
|
|
0:39:09
|
So, this one is 18101.
|
|
0:39:16
|
Now, if I said it three times, let's say /1/1,
|
|
0:39:21
|
this would mean it would have to be the same autonomous system three times in a row.
|
|
0:39:26
|
So, this would only be people who are prepending three times.
|
|
0:39:30
|
So, let's say, let's see if anyone is doing it five times.
|
|
0:39:33
|
So, 4637 is prepending at least, well, they're prepending a lot there.
|
|
0:39:40
|
But the key with this is that with the documentation, there's really not a lot of help
|
|
0:39:46
|
other than just what the characters are.
|
|
0:39:49
|
So, you'll see in the different work books, there's a lot of different examples of what these are.
|
|
0:39:53
|
But by far, the vast majority of the common ones would be the first three.
|
|
0:39:58
|
You can get really complex as to what you want to match with these.
|
|
0:40:02
|
But sometimes it's easier just to use multiple lines in an access list.
|
|
0:40:07
|
So, instead of doing a one line regular expression that's really, really complicated,
|
|
0:40:11
|
I could just match it multiple times.
|
|
0:40:14
|
Or match it with multiple lines.
|
|
0:40:18
|
Okay, there was a question.
|
|
0:40:19
|
"If there's no $ signifying the end of the expression, how would that change the meaning?"
|
|
0:40:27
|
It just means, you're not searching exactly for the end of the line.
|
|
0:40:34
|
So, let's say, I wanna look for prefixes that are originating
|
|
0:40:38
|
in an AS that's actually doing the prepending.
|
|
0:40:42
|
So, if I look for this, which is prepending, but then follow it by the $,
|
|
0:40:48
|
it would mean that it has to originate from the AS that did the prepending.
|
|
0:40:56
|
Now, sometimes, you'll see that these routers take a long time to search
|
|
0:40:59
|
because we're looking at millions and millions of routes in order to compile the expressions.
|
|
0:41:05
|
So, if you're doing this in production, you're trying to define some policy on a regular expression,
|
|
0:41:11
|
keep in mind that the more complex your reg exp is
|
|
0:41:14
|
then the more processing cycles the searches gonna have to go through
|
|
0:41:18
|
in order to figure out if it matches the routes in the table are not.
|
|
0:41:22
|
Now, there are a few minor examples of this in the BGP configuration guide
|
|
0:41:28
|
that says, connecting to a service provider with BGP.
|
|
0:41:30
|
Which talks about how you can change the different attributes for changing the best path selection.
|
|
0:41:36
|
But for most of the time it's just gonna link you back to this document,
|
|
0:41:42
|
which is the regular expression pattern matching.
|
|
0:41:48
|
So, again, this is under terminal services configuration
|
|
0:41:51
|
then the appendix and then the regular expressions.
|
