I’ve actually been meaning to write this post for 2 months now, but I keep procrastinating and bingewatching Netflix instead.
I found myself in a precarious situation a while ago, something that we’ve since resolved through changes in our network architecture, but prior to the changes, I learned a thing or two thanks to it.
The issue we were having was an issue where the router which terminated VPN connections sat behind a separate router, usually this would not be an issue as we would have enabled EIGRP on them to exchange the routes. The issue however was that we were utilizing VRF-lite on the VPN terminating router to separate the underlay and overlay networks. Due to this, there was no way to get the border router to properly communicate with the VRF.
Now, a preface to this is that generally speaking, all VPN connections would usually have been over a terrestrial transmission piece (we have our DMVPN clouds separated for full-mesh support on the TDMA), however, we were testing out new campus fiber connections which terminated on our border router. The idea was, due to concerns about wire tapping, that we needed to terminate these connections to our IPSEC DMVPN cloud.
Me being me, I didn’t want to create a separate cloud on the border router to terminate these connections, so I ventured out on a journey to learn how to get them to communicate.
It turns out, it’s actually pretty simple.
- Import campus fiber /24 into the VRF on the internal router.
- Export DMVPN loopback /32 to the global RIB on the internal router, and advertise this network to the border router.
- Verify Phase-1 DMVPN connectivity on campus fiber sourced spokes.
Here is a representation of what we’re working with so you better understand. Understand the “Loopback10” is in the “DMVPN-TERR” VRF.
First, we’re just going to verify that as we have everything setup in our lab, that the following should happen:
- From the inner router, A “show ip route vrf DMVPN-TERR 10.10.150.0” will return 0 entries in the routing table.
- From both the inner router and outer routers global RIB, a “show ip route 10.10.151.224” will return 0 entries.
- The spoke should not be able to ping the “10.10.151.224” address.
Additionally, at first the /27 for the DMVPN tunnel will be routed to the outer router, this is undesirable.
We need to set in place a route filter, going back to some of our older skills we learned, to prevent recursive routing, which would end up in the looped chain, attempting to stack error.
As expected, all of the following tests responded how we expected!
- Create a VRF definition for what we’re going to use as our shared routing table.
- Place all interfaces which currently reside in the Global RIB on the inner router into our shared VRF.
- Create route distinquishers for DMVPN-TERR and our shared VRF.
- Configure EIGRP for our VRF.
To create a VRF
Router(config)#vrf definition <vrf-name>
To place an interface in the VRF
Router(config-if)# vrf forwarding <vrf-name>
Once you place the interface in the VRF, re-assign it’s IP address. You will need to do this for anything that currently resides in the default RIB.
After you do that, you must create the EIGRP instance for the VRF, to do this:
Router(config)#router eigrp <asn>
Router(config-router)#address-family ipv4 vrf <vrf-name> autonomous-system <asn>
Router(config-router-af)#network <network> <wildcard>
Since I’ve started working with EIGRP on multiple VRFs, as well as with IPv6, I’ve taken to EIGRP named mode.
The benefit to named mode is that it’s modular configuration of all EIGRP configurations from within the EIGRP router configuration mode. No longer do I need to enable authentication on a per-interface level.
To read more about EIGRP named mode:
You can also upgrade your current configuration to named mode with the “eigrp upgrade-cli” command.
Next, to assign route distinquishers to a VRF:
Router(config-vrf)# rd [rd:rd]
- Our RD for our DMVPN-TERR will be 9001:900
- Our RD for our SHARED-GLOBAL will be 9001:999
Now, to verify that the SHARED-GLOBAL looked like before, do a “show ip route vrf SHARED-GLOBAL”
Now that we have setup our shared tables, we’re going to use route-maps to select which networks we are going to leak into the shared routing and into the DMVPN-TERR routing table.
- We need to leak the 10.10.150.0/24 into DMVPN-TERR
- We need to leak the 10.10.151.224/32 into the SHARED-GLOBAL
To do this, use ip prefix-lists:
Router(config)#ip prefix-list <prefix-list> seq <#> permit <network/mask>
Once you have done that, create a route-map that matches that prefix-list.
Here is what we are going to do:
Router(config)# ip prefix-list PL-FIBER-TO-DMVPN seq 5 permit 10.10.150.0/24
Router(config)# route-map RM-SHARED-TO-DMVPN
Router(config-route-map)# match ip address prefix-list PL-FIBER-TO-DMVPN
Router(config)# ip prefix-list PL-DMVPN-TO-FIBER seq 5 permit 10.10.151.224/32
Router(config)# route-map RM-DMVPN-TO-SHARED
Router(config-route-map)#match ip address prefix-list PL-DMVPN-TO-FIBER
After we do that, we need to configure the import and export maps on our VRFs, to do this:
Router(config)# vrf definition <vrf-name>
Router(config-vrf)# address-family ipv4
Router(config-vrf-af)# import map <map-name>
Additionally, you have to specify which topology you want to target for import and export.
For our use case, the export will be the self RD, and the import will be the opposite RD.
Router(config-vrf)#route-target import [rd]
Router(config-vrf)#route-target export [rd]
Next, we’re going to enable a BGP instance whose sole purpose is to import/export these routes between the routing tables. I’ve come to call this my “ghost” BGP instance, although I’m not sure if that’s proper whatsoever.
To enable the instance to work with multiple VRFs, use the address family command.
Because the routes we are wishing to share are connected, or learned through a routing protocol, we must utilize the “redistribute” command.
Router(config)#router bgp <asn>
Router(config-router)#address-family ipv4 vrf <vrf-name>
- On the DMVPN-TERR, we will be redistributing connected.
- On the SHARED-GLOBAL, we will be redistributed EIGRP instance 100
Next, verify this by doing a “show ip route vrf SHARED-GLOBAL” and “show ip route vrf DMVPN-TERR”
Next up, redistribute BGP into EIGRP and you should be able to ping from the spoke to the DMVPN loopback interface.
Now, just to verify our adjacency so I can say my job here is done!