03-29-2015 06:38 AM - edited 02-21-2020 08:09 PM
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
03-29-2015 08:50 AM
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.
03-29-2015 03:34 PM
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
03-30-2015 12:11 AM
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.
03-30-2015 02:45 PM
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!
03-31-2015 04:08 AM
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
04-23-2016 10:45 AM
Genius!!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide