Using separate external interfaces for DMVPN and Internet access

[lincolnwebber]

I Have a setup using DMVPN between a hub and about 18 other spokes. Direct spoke to spoke connectivity is allowed also. The transport for the connections is the internet, so each site has a default route to the ISP and the VPN is established from there. Both internet traffic and VPN traffic use this interface.

Now there is a requirement for a second internet connection that will be used exclusively for Internet browsing. How do I force internet traffic through the new ISP link, while still maintaining the dynamic nature of NHRP for initiating tunnels to other spokes using the original external interface? How can I achieve this with Policy Based Routing?

[paolo bevilacqua]

You can for example configure router-sourced GRE traffic to one interface, all the rest the other.

[Peter Paluch]

Hi Lincoln,

I am wondering whether the PBR is actually needed in your case.

Let me restate the problem to see if I understand it correctly: Your spoke routers use the internet as a transport network to build a DMVPN, and they are using a particular ISP and interface to access it. Now, you are going to add another ISP and another interface and you want to use that exclusively for the purposes of internet access but no DMVPN data shall be sent through it. I also assume you are running a dynamic routing protocol in the DMVPN (EIGRP perhaps?)

I see two possible ways of solving your requirement. The first option is to modify the routing tables on the routers. Your multipoint GRE tunnels are configured with the IP address of the NHRP server, and there is certainly a mapping configured to map the internal NHRP server address to the "true internet" (NBMA) address. And I assume that right now, you have a default route pointing out through the interface you've been using so far.

Then:

1. Remove this default route and instead point it towards the second ISP
2. Add a set of static /32 routes on each CE router to point towards the remaining routers through the first ISP and the appropriate interface
   

This setup has an obvious disadvantage of losing some of the scalability because of the need to maintain the set of routing entries to point towards all other routers (their public addresses) in the DMVPN.

The second option is using the PBR to cause your routers to:

1. Send the GRE packets through the first ISP/interface
2. Send all other packets through the second ISP/interface

This solution, however, would not be configured on an interface but rather using the command ip local policy because the GRE packets we will be looking for are not routed by your CE routers, rather they are locally originated.

Which solution would you personally like better here?

Best regards,

Peter

[lincolnwebber]

Thanks Paolo and Peter. The PBR option is the more attractive of the two to me. So the default route would still point out the DMVPN connected interface right? So as to maintain its dynamic nature.

[Peter Paluch]

Hello Lincoln,

I see. Okay. Let's summarize our requirements:

1. The GRE traffic originated by a router shall go through the first interface.
2. Other traffic originated by the router shall go through the second interface.
3. Routed traffic to internet (i.e. the traffic not locally originated by the router) shall go through second interface.
4. Routed traffic within the DMVPN shall not have its routing modified

Let's assume that the next hop IP address behind the first interface is 1.1.1.1 while the next hop behind the second interface is 2.2.2.2.

The modification could thus be done as follows:

ip access-list extended DMVPN
 permit gre any any
!
route-map LocalRouting permit 10
 match ip address DMVPN
 set ip next-hop 1.1.1.1
!
route-map LocalRouting deny 20
!
ip local policy route-map LocalRouting
no ip route 0.0.0.0 0.0.0.0
ip route 0.0.0.0 0.0.0.0 2.2.2.2

This should do the trick: the GRE packets will be sent through the next hop 1.1.1.1, all other packets, both locally originated and routed, will be sent according to the routing table - and the routing table is modified so that for default route, it points towards 2.2.2.2.

Please give it a try. As always, it is wise to make a backup copy of your current working configuration so that you can revert back to it should anything go wrong.

Best regards,

Peter

[lincolnwebber]

Thanks for your response Peter. I will lab this ASAP. Does the fact that encryption is taking place bear any significance on the access list statement? I ask this because the GRE traffic should be encrypted after its GRE encapsulated. I was wondering if the access list statement should reference ESP rather than GRE.

[Peter Paluch]

Lincoln,

This is a VERY good question The truth is - I don't know But I believe that it won't do any harm to specify both GRE and ESP in the ACL. Please also note that because the IPsec tunnel is negotiated using ISAKMP, you may also want to include the traffic destined to UDP/500 and UDP/4500 into the ACL to make sure that the signalling for the tunnel goes through the same interface as the GRE/ESP itself.

I shall lab it up as well... I am really not quite sure whether the local PBR policy catches the GRE or the ESP in this case.

Best regards,

Peter

[lincolnwebber]

I set this up in a lab and didnt see any matches for the ESP traffic, very few for GRE. I did however achieve my desired result using the following concept.

1. Keep the default route pointing out the DMVPN connected interface

2. Create an extended access list denying traffic sourced from the local protected network to the remote protected networks, while permitting all other    destinations.

3. Create a route map with match statement referencing the above mentioned access list and set a clause referencing the next hop of the new Internet connection.

4. Apply this route map to the internal interface of the router.

The ambiguity of which protocols are involved in the NHRP, GRE, VPN communication is avoided because they all use the default route pointing to the DMVPN Internet connection.

[j-marenda]

You want to use VRF 's to seperate the two differnet Upstrems and the Custormer's LAN.

This will make things much easier and more elegant without route-maps etc.

Works also with cable providers and WAN-IP by dhcp.

On the mutlilink gre-tunnel, you can select

a) which vrf if for the inside tunnel traffic

b) which vrf is for the gre/ip packets .

   This will probably inherited by the tunnel source interface command.

Yes, this works !

(tested on multiple 87x er)

Juergen.