05-02-2012 07:17 AM - edited 03-04-2019 04:13 PM
My organization has a two hub DMVPN with about 35 spokes. We are currently in the process of bringing up the second hub. Before we point all of the spokes at the second hub we want to test with just a few spokes. Hub2 needs to be our primary hub with hub1 being the backup.
The problem we are seeing is when we edit the delay on the tunnel interface, the delay change does not get to the spoke router. No matter what we change the delay to the spoke continues to report the same EIGRP topology. Any suggestions would be appreciated.
Hub1
interface Tunnel0
bandwidth 2000
ip address 10.200.201.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication xxxxx
ip nhrp map multicast dynamic
ip nhrp network-id 150001
ip nhrp holdtime 360
ip tcp adjust-mss 1360
no ip split-horizon eigrp 100
no ip split-horizon
delay 2000
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
tunnel key 150001
tunnel vrf primaries-out
tunnel protection ipsec profile Main
end
!
interface GigabitEthernet0/1
description primary-tunnels
bandwidth 10000
ip vrf forwarding primaries-out
ip address x.x.x.x 255.255.255.0
ip access-group 102 in
ip flow ingress
ip inspect PRIMARY out
ip virtual-reassembly in
delay 1000
duplex auto
speed auto
media-type rj45
end
!
router eigrp 100
network 10.0.0.0
network 172.16.0.0
redistribute static
passive-interface GigabitEthernet0/0
!
ip route 0.0.0.0 0.0.0.0 172.16.3.1
ip route vrf primaries-out 0.0.0.0 0.0.0.0 x.x.x.x
ip route vrf secondaries-out 0.0.0.0 0.0.0.0 x.x.x.x
Hub2
interface Tunnel0
bandwidth 2000
ip address 10.200.201.2 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication xxxxx
ip nhrp map multicast dynamic
ip nhrp network-id 150001
ip nhrp holdtime 360
ip tcp adjust-mss 1360
no ip split-horizon eigrp 100
no ip split-horizon
ip summary-address eigrp 100 0.0.0.0 0.0.0.0
delay 200
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
tunnel key 150001
tunnel vrf primaries-out
tunnel protection ipsec profile Main
end
!
interface GigabitEthernet0/1
description secondary-tunnels
ip vrf forwarding secondaries-out
ip address x.x.x.x 255.255.255.0
ip access-group 103 in
ip flow ingress
ip inspect SECONDARY out
ip virtual-reassembly
duplex full
speed 100
end
!
router eigrp 100
network 10.0.0.0
network 172.16.0.0
redistribute static
passive-interface GigabitEthernet0/2
!
ip route 0.0.0.0 0.0.0.0 172.16.3.200
ip route vrf primaries-out 0.0.0.0 0.0.0.0 x.x.x.x
ip route vrf secondaries-out 0.0.0.0 0.0.0.0 x.x.x.x
Spoke
interface Tunnel0
description Cable tunnels
bandwidth 2000
bandwidth receive 15000
ip address 10.200.201.11 255.255.255.0
no ip redirects
ip mtu 1400
ip hello-interval eigrp 100 1
ip hold-time eigrp 100 5
ip nhrp authentication xxxxxx
ip nhrp map multicast x.x.x.x.
ip nhrp map 10.200.201.1 x.x.x.x
ip nhrp map multicast x.x.x.x
ip nhrp map 10.200.201.2 x.x.x.x
ip nhrp network-id 150001
ip nhrp nhs 10.200.201.1
ip nhrp nhs 10.200.201.2
ip nhrp registration timeout 60
ip tcp adjust-mss 1360
delay 1000
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 150001
tunnel vrf vpn1-out
tunnel protection ipsec profile Main shared
end
!
Spoke#show ip ei top 0.0.0.0/0
IP-EIGRP (AS 100): Topology entry for 0.0.0.0/0
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1536256
Routing Descriptor Blocks:
10.200.201.1 (Tunnel0), from 10.200.201.1, Send flag is 0x0
Composite metric is (1536256/2816), Route is External
Vector metric:
Minimum bandwidth is 2000 Kbit
Total delay is 10010 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1400
Hop count is 1
External data:
Originating router is 172.16.3.6
AS number of route is 0
External protocol is Static, external metric is 0
Administrator tag is 0 (0x00000000)
Exterior flag is set
10.200.201.2 (Tunnel0), from 10.200.201.2, Send flag is 0x0
Composite metric is (1538560/28160), Route is External
Vector metric:
Minimum bandwidth is 2000 Kbit
Total delay is 10100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1400
Hop count is 1
External data:
Originating router is 172.16.3.202
AS number of route is 0
External protocol is Static, external metric is 0
Administrator tag is 0 (0x00000000)
Exterior flag is set
Solved! Go to Solution.
05-02-2012 09:35 AM
Hello Adam,
the tunnel interfaces are the interface towards the spoke routers. This is the reason why changing delay on them does not affect the way default route 0.0.0.0/0 is received on spoke routers. In other words they affect routes coming from spoke nodes from the point of view of the two hub routers.(the opposite)
Actually the delay that counts is the delay seen on spoke "side" for the default route 0.0.0.0 and this the same being the tunnel interface only one ( it is not a dual DMVPN cloud scenario).
The default route should be injected into EIGRP on hub routers via redistribution of a static route in the same VRF.
In this case the delay value that is placed on the EIGRP metric delay component in the EIGRP metric data structure should be taken from the outgoing interface where the static route next hop is reachable.
However, I would expect to see an address-family section for each VRF on each router eigrp process on HUB routers.
something like
router eigrp 100
address-family ipv4 vrf primaries-out
redistribute static metric 10000
you specify a set of values as seed metric and this is the point where you can differentiate how each hub router generates the default route (alternate way to acting on delay of interface)
I would suggest to try the option of using the seed metric as in the example above
Hope to help
Giuseppe
05-02-2012 09:35 AM
Hello Adam,
the tunnel interfaces are the interface towards the spoke routers. This is the reason why changing delay on them does not affect the way default route 0.0.0.0/0 is received on spoke routers. In other words they affect routes coming from spoke nodes from the point of view of the two hub routers.(the opposite)
Actually the delay that counts is the delay seen on spoke "side" for the default route 0.0.0.0 and this the same being the tunnel interface only one ( it is not a dual DMVPN cloud scenario).
The default route should be injected into EIGRP on hub routers via redistribution of a static route in the same VRF.
In this case the delay value that is placed on the EIGRP metric delay component in the EIGRP metric data structure should be taken from the outgoing interface where the static route next hop is reachable.
However, I would expect to see an address-family section for each VRF on each router eigrp process on HUB routers.
something like
router eigrp 100
address-family ipv4 vrf primaries-out
redistribute static metric 10000
you specify a set of values as seed metric and this is the point where you can differentiate how each hub router generates the default route (alternate way to acting on delay of interface)
I would suggest to try the option of using the seed metric as in the example above
Hope to help
Giuseppe
05-11-2012 10:14 AM
Thank you Giuseppe. Using the redistribute static metric command worked for us and the EIGRP topology now looks the way we want it to.
07-07-2015 08:48 PM
Hello Giuseppe,
I have a setup where we have two spokes and one hub. i need that only one spoke is used in DMVPN while other serve as backup in case primary spoke fails.
now the problem is even after changing delay on tunnel interface in spoke router, hub is still using both in routing table. basically this change in delay is not reflecting at hub site.
i changed delay using delay configuration at interface tunnel.
do you recommend something else? or shall i change the distance from secondary router.
Thanks,
Pulkit
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