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.
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.
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
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.
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.
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.
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.
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.
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.
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).
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.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...