cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2013
Views
5
Helpful
6
Replies

DMVPN + MPLS best-path selection

moore12
Level 1
Level 1

Dear Community

 

We're in the process of deploying DMVPN as a backup solution to MPLS. All that is working great!

The DMVPN wan is dual-cloud, with 2 hub routers in each cloud. Phase 3 (nhrp shortcut) is enabled on all the spokes.

For routing, all the customer subnets are advertised in MPLS, whereas for DMVPN hub advertises only a summary to 10.0.0.0/8. The protocol for both is BGP. For DMVPN, the hub routers resides in one AS (65002) and all the spokes another common AS 65102. DMVPN is therefore peered eBGP hub > spoke.

For customers connected to MPLS, the DMVPN serves as backup only solution. Best-path selection by longest prefix match.

We have other customers coming on board who wish to join the same WAN but don't have the $$$ for MPLS so are opting for DMVPN only.

 

Now, I have a requirement to enable spoke-to-spoke for a DMVPN only site (spokeA) to an MPLS site (spokeB). The problem is it doesn't seem to work properly as the hub router sees the best path to spokeB site via MPLS, not via DMVPN. The spoke-to-spoke is never formed, and remains spokeA > hub > mpls > spokeB. The return path is better = spokeB > DMVPN > hub > spokeA (this is because spokeB sees no route from MPLS for spokeA, so follows 10.0.0.0/8) route.

I look for any feedback that can help to meet this requirement?

And if any advice on the general design would be really appreciated.

Thanks a lot!

Phil

6 Replies 6

Marcin Latosiewicz
Cisco Employee
Cisco Employee

Phil, 

 

Why was the spokeA > hub > mpls > spokeB path chosen by BGP as prefered?

Shorter as path? local preference? MED? I understand both links are actually eBGP?

I would have expected hubs see all the specific routes from spokes, and not some summaries? 

 

Maybe it's just a question of tweaking local preference on your hubs ;]

 

M.

 

hi marcin

thanks for reply :)

sorry, I didn't explain very well. The hub sees all routes for all spokes, the spoke sees the summary route.

spokeb via mpls was chosen by the hub by local pref.

The point I was getting at is that spokea could potentially reach spokeb by DMVPN, but I think because of the routing at hub the spoke2spoke never starts. I would have to amend routing from hub to spokeb via DMVPN.

But, problem is that the hub itself (and connected LAN) needs to reach spokeb via MPLS. so I have a conflict.

Any ideas?

cheerio

Phil, 

Not sure if that's the answer you wanted to hear but looks like a good case for multiple VRFs (on hub) and possibly some route leaking. 

I.e. leak a default route into DMVPN iVRF and leak the specific prefixes into (global?) MPLS VRF, they still should aggregated if I remember my BGP correctly. 

Otherwise ... PBR... but that's just nasty ;-)

Orrrr.... the hubs are doing MPLS too, or are just a CE for MPLS provider or is there another CE/PE we can influence?

M.

Hi M,

Thanks for reply. Now you got me thinking!

So, I'll just check the basic premise of spoke2spoke is that it has to egress the DMVPN tunnel interface. It can't have a route from hub to MPLS and somehow magically nhrp can ignore that and detect that it has a DMVPN path also and choose that instead?

I think there is also alternative where if we were using iBGP in DMVPN with no summarisation by hub that as next-hop would be preserved I wouldn't have this issue to begin with. But I like the summarisation, I have to say, and some of the routers are quite old so don't support the next-hop self all so iBGP was out from the start :(

On your suggestion, I think I begin to understand why in the Cisco Validated Designs they always recommend having separate routers for MPLS vs DMVPN. That's practically the same as you're suggesting, only with VRF is virtual separation rather than physical. Smart!

We opted for dual-router with both DMVPN and MPLS terminated on each router for redundancy. Yeah, added redundancy but now we carry the complexity!

I will try labbing it and see how I go. I may also consider a cable between DMVPN vrf and global rather than route leak as I've never been too keen on that. (Our NOC could probably handle sh ip route but not vrf import/export) The route pref tweaking will also need some thought (or maybe a summary advertised from global to vrf would be enough).

PBR .... just nasty heh heh :) you're right.....but sadly it would not be the first time with this customer!

 

Cheerio!

Phil, 

I did a short lab around this ... wanted to make sure I'm not saying something stupid. 

While I can't claim it's the _optimal_ solution for your setup it seems to work in my lab.

 

Spoke1 LAN 192.168.101.0/24 (AS 65001)

Spoke2 LAN 192.168.102.0/24 (AS 65002)

HUB LAN 192.168.111.0/24 (AS 65000)

192.168.1.0/24 DMVPN subnet. 

 

A single (i)VRF - DMVPN exists on hub, only and is assigned only to DMVPN tunnel interface. 

 

Excuse a few hacks a had to use... default routed via default-originate for example :-)

 

 

 

 

 

 

Hub

R10-P#sh run int tu0
Building configuration...

Current configuration : 281 bytes
!
interface Tunnel0
 vrf forwarding DMVPN
 ip address 192.168.1.1 255.255.255.0
 no ip redirects
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip nhrp shortcut
 ip nhrp redirect
 tunnel source Loopback0
 tunnel mode gre multipoint
 tunnel protection ipsec profile PRO
end

R10-P#sh run | s r b 
router bgp 65000
 bgp log-neighbor-changes
 network 192.168.111.0
 redistribute static
 neighbor 10.112.112.1 remote-as 65001
 neighbor 10.112.112.1 route-map SPOKES_MPLS in
 default-information originate
 !
 address-family ipv4 vrf DMVPN
  neighbor 192.168.1.101 remote-as 65001
  neighbor 192.168.1.101 activate
  neighbor 192.168.1.102 remote-as 65002
  neighbor 192.168.1.102 activate
 exit-address-family
R10-P#sh run | s vrf defini
vrf definition DMVPN
 rd 1:1
 route-target export 100:1
 route-target import 100:1
 !
 address-family ipv4
  import ipv4 unicast map DEFAULT
  export ipv4 unicast map SPOKE_SUBNETS
  route-target export 100:1
  route-target import 100:1
 exit-address-family
 !
 address-family ipv6
  route-target export 100:1
  route-target import 100:1
 exit-address-family

 

 

Result on spoke

R1-PE#traceroute 192.168.102.1 source e2/0
Type escape sequence to abort.
Tracing the route to 192.168.102.1
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.1.1 [AS 65000] 5 msec 10 msec 2 msec
  2 192.168.1.102 [AS 65000] 4 msec *  5 msec
R1-PE#traceroute 192.168.102.1 source e2/0
Type escape sequence to abort.
Tracing the route to 192.168.102.1
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.1.102 [AS 65000] 6 msec *  6 msec

 

routing on hub 

(sanitized)

R10-P# sho ip route  
Gateway of last resort is 10.100.100.2 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 10.100.100.2
      10.0.0.0/8 is variably subnetted, 13 subnets, 2 masks
B     192.168.101.0/24 [20/0] via 10.112.112.1, 00:06:40
B     192.168.102.0/24 [20/0] via 192.168.1.102 (DMVPN), 00:00:03
      192.168.111.0/24 is variably subnetted, 2 subnets, 2 masks

R10-P# sho ip route vrf DMVPN
Routing Table: DMVPN

Gateway of last resort is 10.100.100.2 to network 0.0.0.0

B*    0.0.0.0/0 [20/0] via 10.100.100.2, 00:06:40
      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/24 is directly connected, Tunnel0
L        192.168.1.1/32 is directly connected, Tunnel0
B     192.168.101.0/24 [20/0] via 192.168.1.101, 00:06:40
B     192.168.102.0/24 [20/0] via 192.168.1.102, 00:06:25

Genius!!