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

DMVPN spoke to spoke routing question

Glenn R
Beginner
Beginner

Hi,

I am looking for information to help me improve on our current design as we have found some shortfalls that needs improving on. So any advice would be most apreciated.

We have a DUAL headend spoke-to-spoke DMVPN for around 15 sites connecting to 2 Primary Data Centres. We uses EIGRP as the routing protocol over the DMVPN whcih works well. We have however needed to change routing so that remote sites route to a certain DC over the other and currently cannot think what the best way would be to achieve this. The DC have resilient P-2-P connections so even if we need to change the preferred route via DC-B and the users need to get to a service in DC-A we still have connectivity over the P-2-P links.

Setup:

The DC's each have a single 39xx router with remotes having 2 x 29xx routers. Each spoke site (remote) has one tunnel interface configured for both headends.

e.g.

interface Tunnel0

ip address 192.168.0.5 255.255.255.0

ip nhrp authentication xxxx

ip nhrp map 192.168.0.1 192.168.10.1

ip nhrp map 192.168.0.5 192.168.10.5

ip nhrp map multicast 192.168.10.5

ip nhrp map multicast 192.168.10.1

ip nhrp network-id 1

ip nhrp holdtime 360

ip nhrp nhs 192.168.20.1

ip nhrp nhs 192.168.20.5

ip nhrp registration no-unique

ip tcp adjust-mss 1380

delay 10

qos pre-classify

keepalive 2 2

tunnel source GigabitEthernet0/0

tunnel mode gre multipoint

tunnel key 1

tunnel protection ipsec profile DMVPN_PROFILE

So each spoke site has 4 tunnels to the DC's between the 2 (2900) devices. (just for reference there are also more tunnels between the spokes)

The problem I am having is to work out the best way to influence routing to choose DC-B over DC-A even if DC-A is teh best path. Since there is only a sinlge tunnle I cannot add delay on the remote (spoke) sites devices and adding delay does not seem to change the routing from the DC side either.

My current train of thought is to add a second tunnel and have Tun0 configured for DC-A and Tun1 configured for DC-B which would allow me to change the interface parameters to influence routing. Would this work or is there a better way to achieve what I am after.

5 Replies 5

Peter Paluch
Hall of Fame Cisco Employee Hall of Fame Cisco Employee
Hall of Fame Cisco Employee

Hi Glenn,

Without adding additional tunnels, I believe that your requirement could be accomplished by using an EIGRP offset-list on DC-A to artifically increase the metric (specifically, the delay component) of routes advertised from DC-A to spoke routers, assuming both DC-A and DC-B advertise the same set of networks. For example:

DC-A(config)# router eigrp 64512

DC-A(config-router)# offset-list 0 out 1000000 Tunnel0

This configuration would increase the delay component of all routes advertised from DC-A via Tunnel0 interface by an amount of 1000000. If DC-B advertises the same routes with the lower total metric, it will become preferred.

I recall a presentation given during Cisco Live in London by an engineer  from TAC Brussels, Mr. Frederic Detienne, that issues like these call  for the use of BGP instead of EIGRP in DMVPNs, as BGP has much more  flexible set of features to allow for arbitrary path selection. I have to say that it was a word of wisdom indeed.

Best regards,

Peter

Peter

A question if you don't mind -

like these call  for the use of BGP instead of EIGRP in DMVPNs,

I have never used DMVPN but the above suggests that the actual routing protocol needs some sort of support for DMVPNs to be able to use it. Is this the case ie. you can't use BGP because there is no BGP support for DMVPNs ?

I have to say it would indeed be useful as there have been a number of issues in these forums where there is an MPLS connection using BGP (and redistribution from BGP into EIGRP) and a backup link using DMVPN with EIGRP. The problem being that the routes received on the core switch from the BGP redistribution are EIGRP external and the routes received from the DMVPN tunnel are EIGRP internal and the DMVPN tunnel is therefore the preferred route. There are ways around it, especially if you can summarise, but they always feel a bit messy.

Jon