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

DMVPN spoke to spoke routing question

Glenn R
Level 1
Level 1

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
Cisco Employee
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

Hi Jon,

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

Hmm - quite the contrary. I hope it wasn't me who gave off that impression. You can run any routing protocol inside a DMVPN and that protocol does not need any specific support for DMVPN to provide for basic routing. The DMVPN itself provides a fully meshed NBMA environment for all its member routers; the routing protocol then merely runs over it, much similar to a fully-meshed Frame Relay or ATM network. Surely, with an added support for DMVPN, the chosen routing protocol can be implemented more efficiently, or you can tweak it better, but as far as basic routing is concerned, BGP or even RIP would run just fine.

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.

Aaah, yes, I see. Well, you could run your DMVPN with BGP as well, avoiding these issues. Or you can use the cost community attribute in the MPLS - have BGP carry the original redistributed EIGRP component metrics in extended community attributes, and reconstitute the original EIGRP metric after the BGP-to-EIGRP redistribution at the other site of the MPLS VPN.

Best regards,

Peter

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Jon, I just wanted to note, I've setup BGP across MPLS VPN and used BGP on backup DMVPN; each location its own private AS.

One thing you need to watch for when you do that, often the MPLS VPN has one or more AS s between your sites.  By default, BGP may consider DMVPN the better path because the sites don't have any vendor transit AS(s).

Hi Peter,

thank you for you reponse this is the orut ewe will be trying. We run a lrage estate with EIGRP and only make use of BGP to suppliers and 3rd parties and would not like to introduce iBGP internally. I will let you know how I get on.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: