VRF Route Leaking

Packages required: routing-test, mpls-test, RouterOS version 3.25+

Description

When running a multi-tenant MPLS network, it can be useful to leak routes between VRFs. A classic use for this would be to leak your link-nets to a management VRF, or assigning a management address to your CE routers as a /32 address and leaking that. Other uses could be leaking public ip addresses to a separate VRF, to be handled by a different router than the LAN addresses. It is necessary to filter your route leaking to make sure that only non-overlapping addresses are leaked, and it is important to make sure that one VRF doesn't have access to routes of another VRF. This is done by using routing filters and the method of filtering outgoing VRF routes added by the 3.25 software version of RouterOS.

Example Diagram

In this example design, we have two customer VRFs as well as a management VRF. It is assumed that each customer VRF will have potential overlapping IP addresses, however the link addresses are assumed to be non-overlapping. The VRFs are aggregated at the PE1 router and the exit point of the network is at PE2, where the management system is also connected. The management system could be The Dude, or any other NMS software.

VRF Setup

First we take a look at how each VRF is set up at PE1:

/ip route vrf 
add routing-mark=red route-distinguisher=111:500 import-route-targets=111:500,111:999 \
export-route-targets=111:500 interfaces=ether1.500
/ip route vrf 
add routing-mark=green route-distinguisher=111:600 import-route-targets=111:600,111:999 \
export-route-targets=111:600 interfaces=ether1.600

This determines that routes learned from the red VRF will on this PE be marked with the BGP extended community 111:500, and exported with same community. The VRF will import routes with the communities 111:500 and 111:999. 111:999 will be imported to ensure that the router can reach the management VRF. Same goes for the green VRF.

/routing bgp instance vrf 
add instance=default routing-mark=red redistribute-connected=yes redistribute-ospf=yes \
 redistribute-static=yes out-filter=red-out
/routing bgp instance vrf 
add instance=default routing-mark=green redistribute-connected=yes redistribute-ospf=yes \
 redistribute-static=yes out-filter=green-out

Nothing out of the ordinary happening here, except that it is specified that each vrf will use an out-filter.

The management VRF will be set up on PE2 as follows:

/ip route vrf 
add routing-mark=management route-distinguisher=111:999 import-route-targets=111:999,111:1000 \
export-route-targets=111:999 interfaces=ether1.999
/routing bgp instance vrf add instance=default routing-mark=management

The red and green VRF will be set up here as well with a standard configuration. Notice the additional community that the management VRF imports. It is used the import community for customer routes to keep them separate from the community that the management VRF exports.

Routing filters

On PE1 we set up the red-out and green-out filter:

/routing filter 
add chain=red-out match-chain=connected-in append-route-targets=111:1000 action=passthrough
add chain=green-out match-chain=connected-in append-route-targets=111:1000 action=passthrough

These filters match all routes of the connected type in a VRF (ie. the link address) and appends the extended community 111:1000 to these routes. On PE2 these routes will then be imported into the management VRF.

I recognice that the two filters are essentially the same, but trust me, you would rather have separate chains from the beginning, than reconfigure everyone, when you need extra rules for a certain VRF.

Same setup with loopback management

The previous setup assumed your link addresses were unique. If they are not, you can achieve the same effect by adding a loopback interface (ie. a bridge without members). Distribute a /32 address to all the CE routers you wish to manage this way. It is advisable to use either public ip addresses or addresses that you are sure that none of your customers use - 198.18.0.0/15 is handy. You must then match that network in your routing filters, but it's principally the same thing.