DMVPN recursive routing issue

[sergeyrar]

Hi all,

I have the following topology - view attachment.


All routers have EIGRP AS 100 configured for network 0.0.0.0 + no auto-summary.

Additionally I have configured EIGRP AS 101 and specified the tunnel and loopback addresses specifically - which should have preference over the 0.0.0.0 of EIGRP AS 100 and advertise these networks into EIGRP AS 101 ( or am I wrong ? )

Code Select Expand

R1#sho run | sec router ei
router eigrp 100
network 0.0.0.0
no auto-summary
router eigrp 101
network 1.1.1.1 0.0.0.0
network 10.0.0.0
no auto-summary


Anyhow , the end result is that I still have recursive routing and the tunnel won't form.


Any Ideas?


Thanks,

[wintermute000]

Use a front vrf or exclude the wan from dynamic routing. Do a debug but I would be surprised if eigrp 101 is stopping eigrp 100. You've diagnosed it yourself (recursive routing)
Maybe removing r5 from 100 would be sufficient but FVRF is by far the best method

[sergeyrar]

Hi Winter, thanks for the reply.

I guess I was wrong by assuming a more specific network statement in one process would prevent this network from being advertised into another processes.
Maybe this behavior is relevant to other protocols? maybe OSPF ?

R2#sho ip eigrp topology 100
IP-EIGRP Topology Table for AS(100)/ID(2.2.2.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 10.0.0.0/24, 1 successors, FD is 297244416
        via Connected, Tunnel0

R2#sho ip eigrp topology 101
IP-EIGRP Topology Table for AS(101)/ID(2.2.2.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 10.0.0.0/24, 1 successors, FD is 297244416
        via Connected, Tunnel0

[wintermute000]

Never heard of this to be honest, let me know if you find otherwise. In real life a different process would usually be in a vrf lol but I guys technically you could run two in same instance

[sergeyrar]

I think I referred to this behavior in OSPF... where more specific network statements have precedence over less specific when mapping different interfaces to different areas in the same process , things kind of mixed up in my brain lol..

Code Select Expand


R6(config)#do sh ip int brief | e una
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            116.1.100.6     YES manual up                    up
FastEthernet0/1            116.1.99.6      YES manual up                    up
Loopback0                  99.99.6.6       YES manual up                    up

R6(config)#router ospf 1
R6(config-router)#network 0.0.0.0 0.0.0.0 area 20
R6(config-router)#network 116.1.0.0 0.0.255.255 area 10
R6(config-router)#network 116.1.99.6 0.0.0.0 area 0

R6#sh run | sec router ospf
router ospf 1
log-adjacency-changes
network 116.1.99.6 0.0.0.0 area 0
network 116.1.0.0 0.0.255.255 area 10
network 0.0.0.0 255.255.255.255 area 20

R6#sh ip ospf int | i is up|Area
FastEthernet0/1 is up, line protocol is up
Internet Address 116.1.99.6/24, Area 0
FastEthernet0/0 is up, line protocol is up
Internet Address 116.1.100.6/24, Area 10
Loopback0 is up, line protocol is up
Internet Address 99.99.6.6/24, Area 20

[wintermute000]

yes but that's in the same process, you're referring to a statement in one process over-riding another?

good reminder re: that feature in OSPF. I guess this is why they are moving away from network statements.

[sergeyrar]

yes but that's in the same process, you're referring to a statement in one process over-riding another?

Yeah, I ,for some reason, thought that this logic is also applied between different processes of the same protocol and not only between areas (OSPF) in the same process.

[deanwebb]

Off topic, but I love the avatar, Sergeyrar.

[sergeyrar]

Thanks Dean,
Al Bundy rules