Route maps
Route maps have more than one use. For BGP, it is filtering or manipulating prefixes and the associated attributes.
The structure of a route map is similar to the one of access control lists. Statements are parsed, and if there is a hit or match, action is taken…unless thee command continue is used, in which case the parsing move to the next statement.
Just like ACE, there is an implicit deny at the end of the statements, if nothing is matched, it is simply denied.
Prefix lists
Following up on the previous demo for BGP best path selection, let’s take a deep look at the route maps used.
In below example, route map PATHS is used to match a given prefix, and set a local preference value, this way influencing the selected outbound path for traffic from AS100.
Can access lists be used instead of prefix lists ? Yes they can, but prefix lists just seem to be a bit simpler and easier. Prefix lists also provide flexibility for prefix length, where you can filter using ge and le for greater or equal or less or equal respectively.
The use of ge, le or neither is best explained by examples and results in below table.
Assume the following 5 routes or prefixes, and see how they will match or not the prefix lists and prefix length applied.
- 10.0.0/8
- 10.1.1.0/24
- 10.1.2.0/24
- 10.128.10.4/30
- 10.128.10.8/30
| prefix list | Routes number matched | Comments |
|---|---|---|
| 10.0.0.0/8 | 1 | Exact match to route 1 |
| 10.0.0.0/8 ge 9 | 2-5 | /8 means we match 1st 8 bits, so 10. Then all 32 bits starting with 9. |
| 10.0.0.0/8 ge 24 le 24 | 2-3 | 1st octet is 10, then 24 for floating bits. |
| 10.0.0.0/8 le 28 | 1-3 | 1st octet is 10, then prefix length mist be less than 28, so /30 is not valid. |
| 0.0.0.0/0 | None | Exact match of a default route |
| 0.0.0.0/32 | All | This will cover all bits and prefix lengths. |
In our current demo, 2 prefixes are received from AS200, 192.168.10.0/24 and 192.168.20.0/24. Let’s match both prefixes on new set, and use a new route map to set LocPrf 300.
It is clear that the selected new prefix will match more than just the 2 /24 we intended to manipulate. In a production network, great care must be taken when selecting the prefixes length. In fact our prefix-list LAB3 permit 192.168.0.0/19 ge 24 le 24 would match 32 /24 subnets [191.168.0.1 – 191.168.31.254].
If we add 2 new loopback to R10, 192.168.0.1/24 & 192.168.31.1/24. Then advertise them using network statement under AFI, they will be announced and received by R2. Note, that R1 doe snot have a route map inbound, so it would accept all prefixes. For the purpose of this demo, that eBGP session has been admined down.
Adding another loopback out of the prefix list range, will be denied. This will confirm the implicit deny statement, due to no match.
192.168.40.1/24 is not accepted by R2.
BGP communities
Communities are very powerful tools in BGP. Used as tags, route maps can match them and apply chosen sets. Instead of matching a prefix set, matching communities will yield the same effects.
BGP communities are 32, and often presented as a set of 2 16 bits separated by a colon. In some IOS version, command “ip bgp-community new-format” must be used to modify the communities display and make easier to read.
Still on R2, let’s replace our previous route-map DEMO3, by a new DEMO4, and apply it inbound on R20 BGP session.
192.168.10.0/24 is set with community 200:10 & 192.168.20.0/24 with 200:20. See how the community is showing as: Community: 13107210 (line 25) under sh bgp. Once “R2(config)#ip bgp-community new-format” is added, the sam entry is much more readable as 200:10 (line 65).
On R3, the 2 prefixes are received, but no communities are showing.
This is ios default behaviour, R2 must explicitly sent communities to its neighbour. This can be for standard communities, extended ones or both.
Leave A Comment