BGP Maps - Part 3

7) Inject Map:-

To understand inject-map, let's look at the scenario shown in the diagram.

We have four routers, each in different BGP AS. They have EBGP neighbourship with directly connected peer. From R1, we are advertising 192.168.1.0/24 subnet and it's visible on R4 via two paths.

R4 considers the path received via R2 as the best path because of the lower neighbour id. 

If we want the returning traffic towards 192.168.0.0/24 to be routed through R3 then we can advertise the route with high AS prepend to R2. 

However if there is an inbound local preference configured on R4 which prefers R2 over R3 then no matter what BGP attributes other AS's manipulating, the traffic will still go through R2. 

In the CCIE lab exam they can ask questions like this. R4 must prefer the path through R3 but you are not allowed to change any BGP attribute or do aggregation on any routers. How can we achieve this? If we can split /24 into 2 x /25 then based on the longest prefix match R4 will follow the specific route but we don't have /25s in the routing table. The solution is inject-map. 

Let's see how we can configure it.

We will configure three different prefix-lists and match them in route-map.

First prefix-list will include what we want to advertise i.e. 192.168.0.0/25 and 192.168.1.128/25 and "set" it in a route-map. **Remember it's "SET" not "MATCH"

The second prefix-list will include the actual prefix we are splitting here. i.e. 192.168.1.0/24

The last prefix-list will include the actual source of the route. In our case, R3 is learning it from 10.1.13.1.

We will configure a route-map which will match both of these prefix lists.

These route-maps will now be called in the inject-map statement under the BGP process.

This statement says that it will check if the subnet 192.168.1.0/24 is in the BGP table. It will check if the route source is 10.1.13.1. If both these conditions are true then it will generate the prefixes 192.168.1.0/25 and 192.168.1.128/25. 

Remember that you cannot generate the prefixes which are not part of the actual subnet. Also you can't match a route source which is not part of your neighbor list. 

If we check R4's BGP table

The specific /25 routes are in the BGP table. However R4 is also learning it from R2. So let's quickly filter those routes out.

R4 now has two /25 received from R3 installed in the routing table which will be preferred to send traffic to the destination 192.168.1.0/24.

Traceroute confirms this

8) Table Map:-

As shown in the topology, We have R1, R2 and R3 in the BGP AS 100. We have OSPF running as an IGP on all three routers. There is IBGP neighborship between R1 and R2 and R2 and R3. R2 works as a route-reflector. (For IBGP neighborship I have configured loopback 1.1.1.1/32, 2.2.2.2/32 and 3.3.3.3/32 on R1, R2 and R3 respectively)

The networks 192.168.1.0/24 & 192.168.2.0/24 have been advertised from R1 into BGP. Similarly the networks 192.168.3.0/24 & 192.168.4.0/24 have been advertised from R3 into BGP.

Let's look at the BGP table of R1

We can see that, it's learning the prefixes originated from R3 through the route-reflector. The next hop is preserved by the route-reflector (3.3.3.3 is the loopback interface on R3 which is used to establish IBGP neighbourship).

R1 is learning the prefix 3.3.3.3/32 via OSPF from it's directly connected link with R3.

It is the same case with R3. R3 uses it's directly connected link with R1 to reach the routes received via BGP.

This shows that R2 which acts as the route-reflector is not in the data path between R1 and R3. 

Let's check R2's BGP table and routing table

We can see that R2 has learned all four prefixes and installed it in the routing table.

In our toplogy we only have four BGP prefixes but what if there are thousands of BGP prefixes learned from different peers and R2 is not in the data path on any of them. 

R2 doesn't need to install all the prefixes in the routing table as it will consume unnecessary memory. 

To prevent routes from entering into the RIB from BGP table, we can use "table-map" command.

On R2, let's create a route-map which denies anything

Under R2's BGP process, we can apply this with the command "table-map" with the filter keyword at the end.

Now we will apply the command "clear ip bgp table-map" which will reload the RIB to put changes into the effect.

We can see that the routes are in R2's BGP table but not in the routing table.

The connectivity between R1 and R3 is still unchanged.

The table-map command can be used with "filter" keyword or without it. Here is the difference between both of them (from Cisco's documentation)

• When the table-map command is used without the filter keyword, the route map referenced in the table-map command is used to set certain properties (such as the traffic index) of the routes for installation into the RIB. The route is always downloaded, regardless of whether it is permitted or denied by the route map.
• When the table-map command is used with the filter keyword, the route map referenced is also used to control whether a BGP route is to be downloaded to the RIB (hence the filter). A BGP route is not downloaded to the RIB if it is denied by the route map.

I am yet to see a practical use of this command without the filter keyword.