Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Webcast-Catalyst9k
New Member

EIGRP DMVPN delay problems

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

Everyone's tags (3)
1 ACCEPTED SOLUTION

Accepted Solutions
Hall of Fame Super Silver

Re: EIGRP DMVPN delay problems

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 255 1 1500

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

3 REPLIES
Hall of Fame Super Silver

Re: EIGRP DMVPN delay problems

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 255 1 1500

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

New Member

EIGRP DMVPN delay problems

Thank you Giuseppe. Using the redistribute static metric command worked for us and the EIGRP topology now looks the way we want it to.

New Member

Hello Giuseppe, I have a

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

3046
Views
5
Helpful
3
Replies
CreatePlease to create content