%ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of Tunnel0

[rmishra22]

%ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of Tunnel0, addr 10.158.167.12 - looped chain attempting to stack

I have no problem making a test spoke work, but as soon i migrate a production spoke into dmvpn cloud i get this error message on HUB router , along with this error the OSPF keeps bouncing. The description says , its a Transite error and no action is required.

Can someone plz explain why HUB sees this and what could be causing it?

many thanks

10.158.167.12 => Is loopback ip of remote spoke.

[wzhang]

Hi,

This error is typically caused by tunnel recursion, ie., the hub learning the spoke's tunnel source NBMA address over the tunnel once OSPF adjacency is established over tunnel0. Are you advertising the tunnel source network on the spoke to the hub? If you disable OSPF on the spoke, do you see the same problem?

Thanks,

Wen

[rmishra22]

Thanks for your response. I understand thats the possible reason.

To give you some background. As long as the tunnel network is advertised in the ospf, there are no problems, as soon as i "redistribute connected subnets", I see this error and ospf starts to bounce of. Spoke wan is a dialer interface. Hub has a default route pointing to its WAN gateway.

If redistribution advertising WAN ip of spoke over tunnel to hub, is that what is causing this ?

If yes then tuening off ospf on dialter interface should be the solution. But I find it little odd for HUB not to be able to handle spoke wan ip correctly.

Are there any debugs which can clearly show that happeneing?

[wzhang]

Hi,

Yes it looks like redistributing the WAN ip of the spoke over OSPF is the problem here, and since you have a default on the hub, it's really something you don't need. With point to point tunnels, there is a tunnel line state code that checks for tunnel resursion. But with mGRE tunnels, there is no single tunnel destination, so the same check doesn't apply, instead you'd see this ADJ-5-PARENT error when recursion is detected in the tunnel adjacency. To confirm this, you can probably run "debug ip routing", and chances are as soon as OSPF establishes, you'd see the network to the spoke's WAN ip installed (probably as a /32) into the routing table, and that'd cause this error. In any event, there is really no need for you to advertise this network, so removing it should help resolve this.

Thanks,

Wen

[rmishra22]

I am going to do that keep the dialer passive, but before that i do have a question. You can probably guess why i have a default on the HUB towards wan, so that everytime i add a new spoke, i don't have to touch HUB router config. Is there a alternate to default route ( and not adding a specific route for each spoke wan ip ) ?

In the meantime, I am going to try this on GNS first as the change managment is going to take a while before i try again.

[jamesbond]

THANK YOU Wen .. This Helped !!

[Raushan Kumar Yadav]

It occur due to advertising your public network in routing protocol.

[mustafa83]

Thanks, that fixed my issue

[Alex Pfeil]

I had an issue and wzhang is exactly right.  The other side of the tunnels source IP is being learned through the tunnel. I had an issue where the tunnel would establish and it was being learned through the tunnel with a lower AD.  This really helped me to understand the issue. Thank you!