Inter VRF Routing using Import Export Policies and Multi-Protocol BGP

Inter VRF routing can be achieved by several methods. Following are 6 ways you can do it. There can be some more methods but most commonly you will see one of the following methods in your network.

1. Using static routes
2. Using route maps
3. Import - Export Policies plus Multi-Protocol BGP
4. Connecting two interfaces which belongs to two VRFs
5. Pointing traffic to a Firewall
6. Inter VRF Tunneling

Go here to know how to do inter VRF routing using static routes.
Go here to know how to do inter VRF routing using route-maps.
Go here to know how to do inter VRF tunneling.

In this post I am doing it using Import Export policies and Multi-Protocol BGP.

Route Distinguishers & Route Targets

Route Distinghuisher is used to identify the VRF the route came in. It is basically used to identify the VRF which the routes are generated so that it can be used for further policies to control traffic.

Route Targets on the other hand are used to exchange the routes between VRFs. You can export routes in a VRF using route-target export command and import routes in a VRF using route-target import command.

Let's see a configuration example.

R2(config)#ip vrf ONE
R2(config-vrf)#rd 65:10

R2(config)#ip vrf TWO
R2(config-vrf)#rd 65:20

R2(config)#ip vrf THREE
R2(config-vrf)#rd 65:30

For our task, RD is not useful but must be configured in order to configure address families of Multi-Protocol BGP. Following are the current routing tables with some connected and static routes.

Configuring Multi-Protocol BGP..

Address family per VRF is created which will create BGP tables per VRF / address family automatically. Within the address families, connected and static routes are redistributed.

By the configuration up to now, all the routes in separate VRFs are redistributed in to the BGP tables of corresponding VRFs. What we do using route targets are exchanging routes between BGP tables.





Configuring route targets..

Routes in VRF ONE is exported as 1:1 and imported to VRFs TWO and THREE.

Routes in VRFs TWO and THREE are exported as 2:2 and 3:3 and imported to VRF ONE..





Now let's see the routing tables..

You can see the routes have been leaked. You can use the redistribution route filtering methods of BGP to filter unwanted traffic.

Traffic Source Based Inter VRF Routing using Route Maps

Inter VRF routing can be achieved by several methods. Following are 6 ways you can do it. There can be some more methods but most commonly you will see one of the following methods in your network.

1. Using static routes
2. Using route maps
3. Import - Export Policies plus Multi-Protocol BGP
4. Connecting two interfaces which belongs to two VRFs
5. Pointing traffic to a Firewall
6. Inter VRF Tunneling

Go here to know how to do inter VRF routing using static routes.
Go here to know how to do inter VRF routing using import export policies.
Go here to know how to do inter VRF inter VRF tunneling.

In this post I am doing it using route-maps. It is easy to use this method when you need to leak VRFs based on traffic source..

Diagram and configuration are like the following..

R1 has several interfaces configured to test traffic from several sources.. No VRFs configured..

IP routing table has a default route to R2's e0/0 interface..

R2 has 3 VRFs configured like the following and the ports are assigned like the following..

Routing tables of R2..

R3 has 2 VRFs configured like the following and the ports are assigned like the following..

Routing tables of R3..

As you can notice R2 is the only router which has the VRF ONE configured. So all the traffic is coming from VRF ONE and we leak the VRFs in R2 based on the source address of the traffic.

R3 has only the VRFs TWO and THREE configured. So the routing tables will have default routes back to R2's corresponding sub interfaces in order to reply back to the sources.

Now let's create route-maps to leak the VRFs..


Two route-maps are needed. One to identify traffic coming from R1 and switch VRFs, and another to grab return traffic from R3 and point to VRF ONE's interface.

Both maps are created in R2.

Creating ACLs to capture traffic..

Following route-map is switching traffic to VRFs based on sources..

Applying policy to interface..

R2(config)#int e0/0
R2(config-subif)#ip policy route-map SWITCH-VRF

Creating an ACL to capture all traffic..

Following route-map is switching returning traffic back to VRF ONE..

Applying policy to interfaces..

R2(config)#int e0/1.2
R2(config-subif)#ip policy route-map SWITCH-BACK-TO-ONE

R2(config)#int e0/1.3
R2(config-subif)#ip policy route-map SWITCH-BACK-TO-ONE

Now when you ping loopback 2 of R3 from Loopback 2 of R1, the traffic will go and return successfully and when you ping loopback 3 of R3 sourcing from loopback 3 of R1, the traffic will go and return successfully but same will not true when you change the sources.

Stateful Traffic Filtering in Cisco IOS by Reflective ACLs

Stateful filtering is normally done through a firewall. But for small implementations you can do it in a router too.

Let's refer the diagram. Imagine R3 is Internet. Requirement is R1 wants to access R3 but R3 cannot access R1. This cannot be achieved by regular ACLs. Because if you block R3's traffic to R1 using an ACL, R1 will not be able to access R3 as R1 to R3's reply traffic will also be denied. This is because the reply traffic has the source address of R3 which will be blocked by the ACL.

So someway to remember R1 to R3 traffic must be needed in order to allow only it's reply traffic to come in.. This can be achieved by following 3 methods in Cisco IOS.

1. Reflective ACLs
2. Context Based Access Control (CBAC)
3. Zone Based IOS firewall implementation

In this post I am going to do it by Reflective ACL method.

First I am creating an ACL which has a permit statement for the traffic sourced from 192.168.12.1 and destined to any. I use the reflect option for that traffic which will create a dynamic mirror ACL (source and destination swapped) called REMEMBER.

R2(config)#ip access-list extended GOING-OUT
R2(config-ext-nacl)#permit ip host 192.168.12.1 any reflect REMEMBER
R2(config-ext-nacl)#permit ip any any log

The second permit statement above will allow all other traffic to go through but without reflect option, their reply traffic will be blocked by the following ACL.

This ACL which refers REMEMBER denies all other traffic.

R2(config)#ip access-list extended COMMING-IN
R2(config-ext-nacl)#evaluate REMEMBER
R2(config-ext-nacl)#deny ip any any

Now the following configuration will apply the above 2 ACLs to the outgoing interface of R2.

R2(config)#interface e0/1
R2(config-if)#ip access-group GOING-OUT out
R2(config-if)#ip access-group COMMING-IN in

As you can see, a new reflective ACL is dynamically created with source and destinations swapped. You can also see that it has a time left value. This value is default to 300 seconds and can be adjusted. It is the time duration which the router remembers the passed traffic.

BGP Route Filtering using AS-PATH Filter Lists

There can be cases where you are asked to filter BGP updates from a certain autonomous system. You will need to know the configuration of special type of ACLs called AS-Path ACLs.

As you can see, R1 has learned 2 routes which are coming trough AS number 3. Let's say you are asked to filter them.

In the deny statement '3' means that if the AS-PATH list matches any AS number 3 it will filter the route. Note that if there is an ASN 30 is there, it will also be blocked by the ACL used here. But you can use regular expressions to match what you want to filter.

In the last statement in ACL .* is a regular expression used to match everything.

R1(config)#ip as-path access-list 200 deny 3
R1(config)#ip as-path access-list 200 permit .*

Binding the filter list with the neighbor.

R1(config)#router bgp 1
R1(config-router)#neighbor 11.1.12.2 filter-list 200 in

Filtering Subnets of a Summary using BGP Suppress Maps

aggregate address sub command of BGP can be used for manual sumarization of BGP routes and when it is used with summary only keyword, it can filter all component subnets of the summary or when the summary only keyword is not used, it can advertise all the component subnets along with the summary address. Refer this post for more research on aggregate address command.

Anyhow this means you can either advertise all the component subnets of the summary or you can stop advertising all the component subnets of the summary. But what if you want to filter some component subnets of the summary? Here is the application of Suppress Map comes in..

What to remember is;

The prefixes which are permitted by the route-map are suppressed which means the prefixes which are denied route-map are advertised..

I am getting the same example scenario used in the Route Summarization using Aggregate Address Command in BGP post.

The BGP configuration is like the following in R1;

Routes advertised by R1 are like the following..









Routes learned by R3 from R1 are like the following..

The tricky part is that in suppress maps, the selecting logic is bit different. The subnets not to be advertised (suppressed) will be matched with a permit statement in both ACL and in route-map.

Note that the extended ACL is used here using both source and destination portions to match the network id and the subnet mask. This is a bit rare configuration method. Ofcourse you can use a standard ACL too.

R1(config)#ip access-list extended SP-MAP-ACL
R1(config-ext-nacl)#permit ip host 11.20.1.0 host 255.255.255.0

R1(config)#route-map SP-MAP permit 10
R1(config-route-map)#match ip address SP-MAP-ACL

The aggregate address is 11.0.0.0/8 in this scenario. So the suppress map is bound to the following command.

R1(config)#router bgp 65001
R1(config-router)#aggregate-address 11.0.0.0 255.0.0.0 suppress-map SP-MAP

Now you can see the suppressed subnet is shown in 's'

As you can see, the suppressed subnet is not advertised to the neighbors..

Route-Map Match Statement Logic with ACLs / Prefix-Lists

This seems to be a confusing topic for many students so I tried here to make a simple note. Really the logic behind route-maps is very simple and easy and can be helpful to understand many complex configurations with redistribution, filtering , policy based routing etc..

The confusion comes with mix permit and deny statements in ACLs when used with permit and deny statements in route-maps. I take the example of ACLs here but it also applies to Prefix-Lists too..

Let's get a universal example and let's assume A and B are network IDs.

ACL
 - Permit A
 - Deny B

Route maps can have either permit statements or deny statements just like in ACLs. And also they have an implicit deny at the end just like in ACLs..

Let's say the above ACL is matched in a route-map with a permit statement.

route-map RMAP permit 10
 - match ip address ACL

What happens is that A in ACL will be selected and B will be moved to the next statement of the route-map. If there is no next statement B will be not selected for the application.

Let's say the above ACL is matched in a route-map with a deny statement.

route-map RMAP deny 10
 - match ip address ACL

What happens is that A in ACL will not be selected and B will be moved to the next statement of the route-map. If there is no next statement B will be not selected for the application too.

If you want to match the Denied networks of an ACL through route-map statements, you have to configure the last statement of the route-map as a permit statement without any matching statement, here match nothing means matching everything..

route-map RMAP permit <last sequence number>

In policy based routing, if you don't use the last statement, the filtered traffic will be routed according to the ip routing table.

Only thing to remember is that;

Permit statements in ACL will be permitted by Permit Statements and denied by the Deny statements in route-maps and the Deny statements in ACL will be moved to the next statement of the route-map..

Also you can use logical operators "OR" and "AND" with match statements of route-maps.
When 2 or more ACLs are in one match statement, it will be "OR" selection and when 2 or more match statements are inline after line the selection will be "AND"

OR

route-map RMAP permit 10
 - match ip address ACL-1 ACL-2

AND

route-map RMAP permit 10
 - match ip address ACL-1 
 - match ip address ACL-2

Refer some examples in my blog for policy based routing & redistribution using route-maps.

ACL Selection Logic Example for Redistribution through Route-Maps

When access control lists are used for redistribution in route-maps, it seems a bit confusing specially when deny statements are in both ACLs and route maps.

Simple logic in here to understand is like the following..

1. Networks permitted in an ACL will be redistributed if the route map has a permit statement.
2. Networks permitted in an ACL will not be redistributed if the route map has a deny statement.
3. Networks denied in an ACL will be pushed down further through the route map.

Let's get an example and go through the selection logic using a flow diagram..

Following ACLs will be used in route map. Note that a deny any is shown here which is actually the implicit deny in any ACL..

ip access-list standard ACL-PERMIT_11
 permit 11.0.0.0
 deny any

ip access-list standard ACL-DENY_12-PERMIT_13
 deny   12.0.0.0
 permit 13.0.0.0
 deny any

ip access-list standard ACL-DENY_14-PERMIT_15
 deny   14.0.0.0
 permit 15.0.0.0
 deny any

ip access-list standard ACL-PERMIT_16
 permit 16.0.0.0
 deny any

Following is the route map defined. Note that implicit deny is shown here, which is not to be configured but it comes by default like in ACLs..

route-map REDISTRIBUTE permit 10
 match ip address ACL-PERMIT_11

route-map REDISTRIBUTE permit 20
 match ip address ACL-DENY_12-PERMIT_13

route-map REDISTRIBUTE deny 30
 match ip address ACL-DENY_14-PERMIT_15

route-map REDISTRIBUTE deny 40
 match ip address ACL-PERMIT_16

implicit deny all

Following is the selection logic diagram.

If you want to redistribute 12 and 14 networks, you should add implicit permit all as the last statement by just configuring a match all statement.