VRF Export Maps

8/13/2019 VRF Export Maps

1/9

http://packetlife.net/blog/2013/sep/26/vrf-export-maps/ Page 1

VRF Export MapsBy stretch | Thursday, September 26, 2013 at 10:48 p.m. UTC

VRFs are an excellent tool for maintaining segregated routing topologies for separate customers or services. I've previouslycovered inter-VRF routing using route targets, but what if we only want to export a subset of the routes within a VRF? Here's ascenario in which this would be desirable.

Customers A and B each have a site network and a colocation network, and both customers need access to the 192.168.0.0/24network i n the Services VRF. The customers must utilize uniqu e IP space in order to prevent overlapping networks, so eachcustomer has been allocated dedicated IP space from their common provider out o 10.0.0.0/8. Unfortunately, customer A is stillhas some networks within the 172.16.0.0/16. These networks need to access services in the host colo, but the service providercan't allow this space to be advertised into the Services VRF as it's not approved IP space.

Our goal is to export only the networks within the 10.0.0.0/8 space from the customer VRFs to the Services VRF. How can weaccomplish this?

Let's hav e a look at the initial network state. (This lab was perfo rmed using a single router for simplicity. In the real world, thesecustomers would typically be connected via an MPLS VPN.) Each customer and colo network has its own VRF and dedicatedroute target (RT). The Services VRF has been configured with an import/export RT pair for scalability reasons. No export amongVRFs has yet been configured.

ip vrf Customer_A

rd 65000:1001

route-target export 65000:1001

route-target import 65000:1001

!

ip vrf Customer_A_Colo

rd 65000:2001


rout e-target import 65000:2001

!

ip vrf Customer_B

rd 65000:1002
http://packetlife.net/blog/2013/sep/26/vrf-export-maps/http://packetlife.net/blog/2013/sep/26/vrf-export-maps/http://packetlife.net/blog/2013/sep/26/vrf-export-maps/http://packetlife.net/blog/2010/mar/29/inter-vrf-routing-vrf-lite/http://packetlife.net/users/stretch/http://packetlife.net/blog/2013/sep/26/vrf-export-maps/http://packetlife.net/blog/2013/sep/26/vrf-export-maps/


2/9




!

ip vrf Customer_B_Colo

rd 65000:2002



!

ip vrf Servicesrd 65000:100




!

interface Loopback100

ip vrf forwarding Services

ip address 192.168.0.1 255.255.255.0

!


ip vrf forwarding Customer_Aip address 172.16.0.1 255.255.0.0 secondary

ip address 10.1.1.1 255.255.255.0

!


ip vrf forwarding Customer_B

ip address 10.1.2.1 255.255.255.0

!


ip vrf forwarding Customer_A_Colo

ip address 10.2.1.1 255.255.255.0

!interface Loopback2002

ip vrf forwarding Customer_B_Colo

ip address 10.2.2.1 255.255.255.0

!

router bgp 65000

!

address-family ipv4 vrf Services

redistribute connected

exit-address-family

!

address-family ipv4 vrf Customer_B_Coloredistribute connected

exit-address-family

!

address-family ipv4 vrf Customer_B


exit-address-family

!

address-family ipv4 vrf Customer_A_Colo


exit -address-family

!address-family ipv4 vrf Customer_A

http://packetlife.net/blog/2013/sep/26/vrf-export-maps/http://packetlife.net/blog/2013/sep/26/vrf-export-maps/


3/9


exit-address-family

First, we want to enable route exchange between each customer VRF and its respective colo. This is easily accomplished byadding an additional import RT to each customer VRF:

ip vrf Customer_A


!

ip vrf Customer_A_Coloroute-target import 65000:1001

!

ip vrf Customer_B

rout e-target import 65000:2002

!

ip vrf Customer_B_Colo


The Customer_A VRF now has a route for the Customer_A_Colo networks, and vice versa. The same goes for Customer_B and

its colo network. You could check the routing table for each VRF independently ( show ip route vrf NAME ), or you can use thecommand show ip bgp vpnv4 all to quickly dump the routes from all VRFs:

Router# show ip bgp vpnv4 all

BGP table version is 18, local router ID is 1.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

Rout e Distinguisher: 65000:100 (default for vrf Services)

*> 192.168.0.0 0.0.0.0 0 32768 ?

Route Distinguisher: 65000:1001 (default for vrf Customer_A)

*> 10.1.1.0/24 0.0.0.0 0 32768 ?
http://packetlife.net/blog/2013/sep/26/vrf-export-maps/http://packetlife.net/blog/2013/sep/26/vrf-export-maps/http://packetlife.net/blog/2013/sep/26/vrf-export-maps/


4/9


*> 10.2.1.0/24 0.0.0.0 0 32768 ?

*> 172.16.0.0 0.0.0.0 0 32768 ?

Route Distinguisher: 65000:1002 (default for vrf Customer_B)

*> 10.1.2.0/24 0.0.0.0 0 32768 ?

*> 10.2.2.0/24 0.0.0.0 0 32768 ?

Route Distinguisher: 65000:2001 (default for vrf Customer_A_Colo)

*> 10.1.1.0/24 0.0.0.0 0 32768 ?

*> 10.2.1.0/24 0.0.0.0 0 32768 ?

*> 1 72.16.0.0 0.0.0.0 0 32768 ?Route Distinguisher: 65000:2002 (default for vrf Customer_B_Colo)

*> 10.2.1.0/24 0.0.0.0 0 32768 ?

*> 10.2.2.0/24 0.0.0.0 0 32768 ?

Notice that the Customer_A and Customer_A_Colo VRFs both contain the same set of routes, as do the two VRFs for Customer B.(If the routes don't appear to be exchanged, ensure that MP-BGP is running and has a router ID configured.)

Next, we need to exchange routes among the four customer VRFs and the common services VRF. We do this by adding the importand export RT for the Services VRF.

ip vrf Customer_Aroute-target import 65000:100


!

ip vrf Customer_A_Colo



!

ip vrf Customer_B



!ip vrf Customer_B_Colo




5/9


We can see that the Services VRF now see all customer routes, and all customer VRFs have a route to the services network:







Route Distinguisher: 65000:100 (default for vrf Services)

*> 10.1.1.0/24 0.0.0.0 0 32768 ?

*> 10.1.2.0/24 0.0.0.0 0 32768 ?

*> 10.2.1.0/24 0.0.0.0 0 32768 ?

*> 10.2.2.0/24 0.0.0.0 0 32768 ?

*> 172.16.0.0 0.0.0.0 0 32768 ?

*> 192.168.0.0 0.0.0.0 0 32768 ?


*> 10.1.1.0/24 0.0.0.0 0 32768 ?

*> 10.2.1.0/24 0.0.0.0 0 32768 ?

*> 172.16.0.0 0.0.0.0 0 32768 ?

*> 192.168.0.0 0.0.0.0 0 32768 ?


*> 10.1.2.0/24 0.0.0.0 0 32768 ?

*> 10.2.2.0/24 0.0.0.0 0 32768 ?

*> 192.168.0.0 0.0.0.0 0 32768 ?


*> 10.1.1.0/24 0.0.0.0 0 32768 ?

*> 10.2.1.0/24 0.0.0.0 0 32768 ?

*> 1 72.16.0.0 0.0.0.0 0 32768 ?

*> 192.168.0.0 0.0.0.0 0 32768 ?

Route Distinguisher: 65000:2002 (default for vrf Customer_B_Colo)

*> 10.2.1.0/24 0.0.0.0 0 32768 ?


6/9


*> 10.2.2.0/24 0.0.0.0 0 32768 ?

*> 192.168.0.0 0.0.0.0 0 32768 ?

But now we have a problem: The legacy 172.16.0.0/16 prefix from Customer_A is polluting the Services VRF. We need to find away to prevent it from being exported to the Services VRF while still permitting the valid 10.1.1.0/24 route. This is where exportmaps come in handy.

Export Maps

Let's take a closer look at the routes being exported from the Customer_A VRF:

Router# show ip bgp vpnv4 vrf Customer_A 10.1.1.0

BGP routing table entry for 65000:1001:10.1.1.0/24, version 25

Paths: (1 available, best #1, table Customer_A)

Not advertised to any peer

Local

0.0.0.0 from 0.0.0.0 (1.1.1.1)

Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best

Extended Community: RT:65000:101 RT:65000:1001

mpls labels in/out 18/aggregate(Customer_A)





Local

0.0.0.0 from 0.0.0.0 (1.1.1.1)




Recall th at a route target is just a type of BGP community. Here we can see that the two route targets (communities) we configuredusing the route-target export command under VRF configuration have been attached to both routes from this VRF, asexpected. The 65000:101 RT is what's causing the Services VRF to import these routes. What we want to do is prevent the65000:101 RT from being added to the 172.16.0.0/16 route while still including it on the 10.1.1.0/24 route.

We can define a route-map to overwrite the set of RTs attached to a route with whatever we want, and apply it to the Customer_AVRF as an export map. We'll use a prefix list to match any routes within 172.16.0.0/16.

ip prefix-list Customer_A_Legacy seq 5 permit 172.16.0.0/16 le 32

!

route-map Customer_A_Export permit 10match ip address prefix-list Customer_A_Legacy

set extcommunity rt 65000:1001

Note that the set extcommunity command in this instance is not adding an RT (because we did not include the additivekeyword). Rather, we are overwriting the existing set of RTs with our own set (which happens to be only a single RT). Essentially,this line says, "Get rid of any existing RTs and add an RT for 65000:1001."

The route map is applied to the VRF using the export map command:

ip vrf Customer_A

export map Customer_A_Export

Let's take a look at those two routes again:


7/9






Local

0.0.0.0 from 0.0.0.0 (1.1.1.1)



mpls labels in/out 18/aggregate(Customer_A)Router# show ip bgp vpnv4 vrf Customer_A 172.16.0.0



Flag: 0xA00


Local

0 .0.0.0 from 0.0.0.0 (1.1.1.1)


Extended Community: RT:65000:1001


Success! The route for 172.16.0.0/16 no longer has the 65000:101 RT attached to it, which means it should no longer be importedby the Services VRF. The Customer_A_Colo VRF will still import the route because of the 65000:1001 RT.







Route Distinguisher: 65000:100 (default for vrf Services)*> 10.1.1.0/24 0.0.0.0 0 32768 ?

*> 10.1.2.0/24 0.0.0.0 0 32768 ?

*> 10.2.1.0/24 0.0.0.0 0 32768 ?

*> 10.2.2.0/24 0.0.0.0 0 32768 ?

*> 192.168.0.0 0.0.0.0 0 32768 ?


*> 10.1.1.0/24 0.0.0.0 0 32768 ?

*> 10.2.1.0/24 0.0.0.0 0 32768 ?

*> 172.16.0.0 0.0.0.0 0 32768 ?

*> 192.168.0.0 0.0.0.0 0 32768 ?

Route Distinguisher: 65000:1002 (default for vrf Customer_B)*> 10.1.2.0/24 0.0.0.0 0 32768 ?

*> 10.2.2.0/24 0.0.0.0 0 32768 ?

*> 192.168.0.0 0.0.0.0 0 32768 ?


*> 10.1.1.0/24 0.0.0.0 0 32768 ?

*> 10.2.1.0/24 0.0.0.0 0 32768 ?

*> 172.16.0.0 0.0.0.0 0 32768 ?

*> 192.168.0.0 0.0.0.0 0 32768 ?

Rout e Distinguisher: 65000:2002 (default for vrf Customer_B_Colo)

*> 10.2.1.0/24 0.0.0.0 0 32768 ?

*> 10.2.2.0/24 0.0.0.0 0 32768 ?*> 192.168.0.0 0.0.0.0 0 32768 ?


8/9


Great, that's exactly what we wanted!

By the way, did you notice that our route map is not permitting any other routes, yet the 10.1.1.0/24 network is still exported? Thisis contrary to how route maps typically work and an important caveat to remember. Think of it this way: Your export map matchesexported routes which you want to modify , not the routes you want to export in the first place.

There's o ne last concern to address with our solution. The curre nt configuration explicitly denies certain routes and allows allothers. This is contrary to the preferred practice of allowing only routes which we explicitly permit and denying everything else. Ifcustomer A was to announce another unwanted network (e.g. 172.17.0.0/16), our export map wouldn't prevent it from beingexported to the Services VRF.

We can fix this by inverting our VRF export logic: Instead of removing the 65000:101 RT from routes we don't want, we'll only add itto routes we do want. First, let's remove the route-target export 65000:101 from the Customer_A VRF. This will removeboth Customer_A routes from the Services VRF.

ip vrf Customer_A

no route-target export 65000:101

no export map Customer_A_Export

Next, we'll recreate our prefix list and route-map to reflect the new logic:

no route-map Customer_A_Export

no ip prefix-list Customer_A_Legacy

!

ip prefix-list Customer_A_Networks permit 10.1.1.0/24

!

route-map Customer_A_Export permit 10

match ip address prefix-list Customer_A_Networks

set extcommunity rt 65000:101 additive

!

ip vrf Customer_A

export map Customer_A_Export

We still see the same BGP communities as with the previous configuration: Only the 10.1.1.0/24 network has the 65000:101 RTattached.





Local

0.0.0.0 from 0.0.0.0 (1.1.1.1)








Local

0 .0.0.0 from 0.0.0.0 (1.1.1.1)


Extended Community: RT:65000:1001

http://packetlife.net/blog/2013/sep/26/vrf-export-maps/http://packetlife.net/blog/2013/sep/26/vrf-export-maps/http://packetlife.net/blog/2013/sep/26/vrf-export-maps/http://packetlife.net/blog/2013/sep/26/vrf-export-maps/


9/9


But now, if we add a second rogue network to the Customer_A VRF, it won't get exported to the Services VRF because it won't bematched by our prefix list.







Route Distinguisher: 65000:100 (default for vrf Services)

*> 10.1.1.0/24 0.0.0.0 0 32768 ?

*> 10.1.2.0/24 0.0.0.0 0 32768 ?

*> 10.2.1.0/24 0.0.0.0 0 32768 ?

*> 10.2.2.0/24 0.0.0.0 0 32768 ?

*> 192.168.0.0 0.0.0.0 0 32768 ?


*> 10.1.1.0/24 0.0.0.0 0 32768 ?

*> 10.2.1.0/24 0.0.0.0 0 32768 ?

*> 172.16.0. 0 0.0.0.0 0 32768 ?*> 172.17.0.0 0.0.0.0 0 32768 ?

*> 192.168.0.0 0.0.0.0 0 32768 ?


*> 10.1.2.0/24 0.0.0.0 0 32768 ?

*> 10.2.2.0/24 0.0.0.0 0 32768 ?

*> 192.168.0.0 0.0.0.0 0 32768 ?


*> 10.1.1.0/24 0.0.0.0 0 32768 ?

*> 10.2.1.0/24 0.0.0.0 0 32768 ?

*> 172.16.0.0 0.0.0.0 0 32768 ?

*> 172.17.0.0 0.0.0.0 0 32768 ?*> 192.168.0.0 0.0.0.0 0 32768 ?

Rout e Distinguisher: 65000:2002 (default for vrf Customer_B_Colo)

*> 10.2.1.0/24 0.0.0.0 0 32768 ?

*> 10.2.2.0/24 0.0.0.0 0 32768 ?

*> 192.168.0.0 0.0.0.0 0 32768 ?

There's one important caveat to address before we wrap up. Although the Services VRF doesn't have a route to the 172.16.0.0/16network at customer A, it's still possible for customer A to send traffic from this network into the Services VRF. Return traffic won'tmake it back, however this leaves the door open for denial of service attacks (for example, spoofing traffic so that it appears tocome from customer B, and flooding that customer with responses). Additional controls such as unicast RPF or even plain old

access lists are needed at the customer edge to block invalid traffic.

Posted in Routing
http://packetlife.net/blog/category/routing/http://packetlife.net/blog/2013/sep/26/vrf-export-maps/http://packetlife.net/blog/2013/sep/26/vrf-export-maps/http://packetlife.net/blog/category/routing/http://packetlife.net/blog/2009/jul/20/urpf-access-layer-deter-ddos-attacks/http://packetlife.net/blog/2013/sep/26/vrf-export-maps/

VRF Export Maps

Documents

Transcript of VRF Export Maps