NoSwitchport.com

Internet-based DMVPN coming through your front-door (VRF, that is)

Posted in Networking by shaw38 on April 20, 2010

While working on the design for a 20+ site DMVPN migration, I realized something often overlooked in the documentation for an internet-based DMVPN deployment. To maintain a zero (or minimal) touch deployment model in an internet-based DMVPN, default routing is a must for dynamic tunnel establishment between hubs and spokes. The public addressing of spoke routers is typically at the mercy of one or more service providers and even if you have been allocated a static address per the service contract, these still have a tendency to change due to reasons out of the customer’s control. This is especially true in teleworker-type deployments with a broadband service provider. To deal with this issue, an engineer has two options: maintain a list of static routes on every hub/spoke router comprised of every public and next-hop address in the DMVPN environment or use a static default route pointing out the public interface.

Tough decision, huh? Not so fast.

What happens when you have a transparent proxy deployed in your network at the hub site? No problem, just have the spoke routers carry a default route advertised into the IGP from the hub site. Wait…we are already using a default route to handle DMVPN tunnel establishment between spoke routers. To resolve this issue, we need two default routes: one for clients within the VPN and one for establishing spoke-to-spoke tunnels. We could add two defaults to the same routing table with the same administrative distance but load balancing is not the behavior we want and our tunnels would throw a fuss due to route recursion. How about policy-based routing with the local policy command configured for router-initiated traffic? Pretty ugly. Enter FVRF or Front-door VRF.

Front-door VRF takes advantage of the VRF-aware features of IPSec. While touted as a security feature in the scant Cisco documentation by separating your private routing table into an isolated construct from your public address space, this feature also provides an ideal solution for maintaining separate routing topologies for DMVPN control-plane traffic and user data-plane traffic.

So how does all this work? Pretty simply if you are familiar with the VRF concept. First, on your spoke routers, create a VRF to be used for resolving tunnel endpoints:

ip vrf FVRF
 description FRONT_DOOR_VRF_FOR_TUNNEL_MGMT
 rd 1:1

Add the publicly addressed or outside-facing interface to the VRF:

interface FastEthernet0/1
 ip vrf forwarding FVRF
 ip address 10.1.1.1 255.255.255.252

Now, we need to configure our ISAKMP/IPSec policy in a VRF-aware fashion:

crypto isakmp policy 1
 authentication pre-share
 group 2
 encr 3des
!
crypto keyring DMVPN vrf FVRF
 pre-shared-key address 0.0.0.0 0.0.0.0 key PR35H4R3D
!
crypto ipsec transform-set DMVPN esp-3des
 mode transport
!
crypto ipsec profile DMVPN
 set security-association lifetime seconds 1800
 set transform-set DMVPN 
 set pfs group2

Note the only VRF-specific configuration is the crypto keyring statement. Both the ISAKMP policy and IPSec transform-set configuration is no different than a typical deployment. GET VPN could be used instead, if your security posture calls for it.

Next up–configuration of the mGRE interface:

interface Tunnel1
 ip address 10.2.2.2.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication DMVPN
 ip nhrp map multicast 2.2.2.2
 ip nhrp map 10.2.2.254 2.2.2.2
 ip nhrp network-id 1
 ip nhrp holdtime 450
 ip nhrp nhs 10.2.2.254
 ip nhrp shortcut
 ip nhrp redirect
 ip tcp adjust-mss 1360
 load-interval 30
 qos pre-classify
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 tunnel key 1
 tunnel vrf FVRF
 tunnel protection ipsec profile DMVPN

Configuring the tunnel interface is standard fare except for the “tunnel vrf” argument. This command forces the far-side tunnel endpoint to be resolved in the VRF specified. By default, tunnel endpoint resolution takes place in the global table which is obviously not the behavior we want. Also, notice the “ip nhrp shortcut” and “ip nhrp redirect” arguments. These two commands mean we are using DMVPN Phase 3 and it’s fancy CEF rewrite capable for spoke-to-spoke tunnel creation.

Last, lets add our default route within the VRF:

ip route vrf FVRF 0.0.0.0 0.0.0.0 10.1.1.2 name DEFAULT_FOR_FVRF

And we’re done! At this point, assuming your hub site configuration is correct, you should have a working DMVPN tunnel.

In the output below, notice the “fvrf” and “ivrf” sections under tunnel interface 1. The concept of IVRF is the exact opposite of FVRF: tunnel control-plane traffic operates in the global routing table, and your private side operates in a VRF. IVRF can be tricky in that, if your spoke routers are managed over the tunnel, all management functionality (SNMP, SSH, etc.) must be VRF-aware. Recent IOS releases have been much better with VRF-aware features but YMMV:

Test-1841#sh crypto session detail 
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection     
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation     
X - IKE Extended Authentication, F - IKE Fragmentation

Interface: Tunnel1
Uptime: 3d22h
Session status: UP-ACTIVE     
Peer: 2.2.2.2 port 500 fvrf: FVRF ivrf: (none)
      Phase1_id: 2.2.2.2
      Desc: (none)
  IKE SA: local 10.1.1.1/500 remote 2.2.2.2/500 Active 
          Capabilities:D connid:1048 lifetime:01:41:34
  IPSEC FLOW: permit 47 host 10.1.1.1 host 2.2.2.2
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 114110 drop 0 life (KB/Sec) 4396354/1063
        Outbound: #pkts enc'ed 119898 drop 492 life (KB/Sec) 4396347/1063

You can now configure your favorite flavor of IGP as would normally would (globally, that is) without impacting DMVPN control-plane traffic. In this scenario, OSPF is used with the tunnel interfaces configured as a point-to-multipoint network type. The static default route in the FVRF table handles tunnel establishment while the dynamically-learned default via OSPF handles the user data plane within the VPN:

Test-1841#sh ip route vrf FVRF 0.0.0.0

Routing Table: FVRF
Routing entry for 0.0.0.0/0, supernet
  Known via "static", distance 1, metric 0, candidate default path
  Routing Descriptor Blocks:
  * 10.1.1.2
      Route metric is 0, traffic share count is 1
Test-1841#
Test-1841#
Test-1841#
Test-1841#sh ip route 0.0.0.0

Routing entry for 0.0.0.0/0, supernet
  Known via "ospf 100", distance 110, metric 101, candidate default path, type inter area
  Last update from 10.2.2.254 on Tunnel1, 3d23h ago
  Routing Descriptor Blocks:
  * 10.2.2.254, from 10.2.2.254, 3d23h ago, via Tunnel1
      Route metric is 101, traffic share count is 1

Front-door VRF works best when used on both hub and spoke routers. Why? Well, anytime a new spoke is to be provisioned, you have to do zero configuration on the hub site. Configure the spoke router, ship it out the door, and have the field plug it in at their convenience.

Advertisements
Tagged with: , ,

9 Responses

Subscribe to comments with RSS.

  1. sergiu said, on May 1, 2010 at 4:50 am

    well, hello i have some missunderstandings
    i have the next HQ router configuration

    crypto isakmp policy 10
    encr 3des
    authentication pre-share
    crypto isakmp key cisco address 10.20.1.2
    crypto isakmp keepalive 60 10
    !
    !
    crypto ipsec transform-set vpn ah-sha-hmac esp-3des
    mode transport
    !
    crypto ipsec profile vpn
    set transform-set vpn
    set pfs group1

    interface Tunnel10
    ip address 192.168.20.7 255.255.255.0
    no ip redirects
    ip mtu 1400
    ip nhrp authentication cisco
    ip nhrp map multicast dynamic
    ip nhrp network-id 10
    ip nhrp holdtime 300
    ip nhrp shortcut
    ip nhrp redirect
    ip tcp adjust-mss 1360
    load-interval 30
    qos pre-classify
    keepalive 100 3
    tunnel source FastEthernet0
    tunnel mode gre multipoint
    tunnel key 10
    tunnel protection ipsec profile vpn

    interface FastEthernet0
    description Satellite Switch Port 43
    ip address 172.24.4.254 255.255.255.0

    and the configuration of th spoke router:

    ip vrf test_VR1
    rd 65000:4
    route-target export 65000:4
    route-target import 65000:4

    crypto keyring vpn vrf test_VR1
    pre-shared-key address 172.24.4.254 key cisco
    !
    crypto isakmp policy 10
    encr 3des
    authentication pre-share
    crypto isakmp profile vpn
    keyring vpn
    match identity address 172.24.4.254 255.255.255.255 test_VR1
    keepalive 10 retry 2
    !
    !
    crypto ipsec transform-set vpn ah-sha-hmac esp-3des
    mode transport
    !
    crypto ipsec profile vpn
    set transform-set vpn
    set pfs group1
    set isakmp-profile vpn

    interface Tunnel10
    ip vrf forwarding test_VR1
    ip address 192.168.20.2 255.255.255.0
    no ip redirects
    ip mtu 1400
    ip nhrp authentication cisco
    ip nhrp map 192.168.20.7 172.24.4.254
    ip nhrp map multicast 172.24.4.254
    ip nhrp network-id 10
    ip nhrp holdtime 300
    ip nhrp nhs 192.168.20.7
    ip nhrp cache non-authoritative
    ip nhrp shortcut
    ip nhrp redirect
    ip tcp adjust-mss 1360
    load-interval 30
    qos pre-classify
    keepalive 100 3
    tunnel source FastEthernet0/1.24
    tunnel mode gre multipoint
    tunnel key 10
    tunnel vrf test_VR1
    tunnel protection ipsec profile vpn

    interface FastEthernet0/1.24
    encapsulation dot1Q 24
    ip vrf forwarding test_VR1
    ip address 10.20.1.2 255.255.255.0

    Lets say tha isakmp association is ok. i cannot ping the through tunnel interface from HQ to spoke router. th ipsec association seems to be ok too

    can you give an advice me pleace

    thanks

    • shaw38 said, on May 3, 2010 at 2:06 pm

      You need to remove the vrf statement from under your tunnel interface configuration on the spoke:

      interface Tunnel10
      ip vrf forwarding test_VR1
      ip address 192.168.20.2 255.255.255.0

      You want your tunneled traffic to be routed via the global routing table, not via the FVRF.

  2. Aitaseller said, on July 13, 2010 at 9:49 am

    Hello and thanks for a really interesting article.

    I have configured a DMVPN for one of our Customer with 20 spokes and a dual hub setup.

    As the customer wanted to route all the spoke traffic through the hub I have configured VRF on the spokes but not on the hub routers (2x Cisco 2921). Everything is working fine so far;-) From you sais I guess I have used IVRF as private IP are in the VRF and ISP in the global RIB.

    What I don’t understand it what you say:

    “Front-door VRF works best when used on both hub and spoke routers. Why? Well, anytime a new spoke is to be provisioned, you have to do zero configuration on the hub site. Configure the spoke router, ship it out the door, and have the field plug it in at their convenience. ”

    It is not the same with my config? When our customer adds a spoke there is no extra config on the Hub.

    Apart from the drawbacks listed regarding IVRF and there other drawbacks compare to FVRF?

    What would be the point to configure VRF on the Hub location also?

    Many questions I am asking you;-) I hope you will have the time to reply to them.

    Best regards,
    Aitaseller

    • shaw38 said, on July 13, 2010 at 10:21 am

      Hi Aitaseller,

      A situation for configuring an FVRF on both the hub and spoke routers would be when you need to carry a default route for client internet traffic. Without creating an FVRF on the hub router(s), internet traffic from the spoke routers will be forwarded correctly up to the hub but then be forward back out the public facing interface since only a single default route exists in the global table. If the clients residing behind the spoke routers are using a proxy server configured in their browsers, this is a non-issue since all internet-bound traffic will have a destination of the proxy server and the hub routers will forward based on the more specific internal route as opposed to the default. My guess is your customer uses a proxy server configuration in their client browsers.

      -Steve

  3. Aitaseller said, on July 14, 2010 at 10:16 am

    Hi Steve,

    Thanks for your reply.

    With only one VRF configured on the spoke and no VRF on the HUB I can reach Internet From HUB without problem. So what do you mean here: “Without creating an FVRF on the hub router(s), internet traffic from the spoke routers will be forwarded correctly up to the hub but then be forward back out the public facing interface since only a single default route exists in the global table” ? Can you give me a more detailed example?

    Best regards,
    Laurent

  4. Aitaseller said, on July 14, 2010 at 10:53 am

    In my previous post made a mistake.

    I meant this instead: “With only one VRF configured on the spokes and no VRF on the HUB I can reach Internet From spokes without problem. There are no proxy server configured yet.”

    • shaw38 said, on July 14, 2010 at 11:39 am

      Is the hub router also the internet gateway?

      • Aitaseller said, on July 14, 2010 at 4:40 pm

        Yes the hub router is also the Internet Gateway.

  5. Maikel said, on September 8, 2015 at 9:30 am

    Thanks for this, helped me a lot ! (even 5 years later 🙂 )


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: