Hi, I have two links on Same router having IP 22.214.171.124 & 126.96.36.199 in India. Both are connected to MPLS of same ISP. On the US, we have one router on the same ISP MPLS cloud having IP 10.10.10.10 & loopback is 188.8.131.52. I have configured BGP with MPLS P routers. I have getting all traffic on BGP on India end from US router. Everything is working fine.
Now my need to run GRE Tunnel from India both links to US router and have to run Eigrp. On India router, I have created Tunnel-1( Source-184.108.40.206& Destination-10.10.10.10).
I have created Tunnel-2 (Source 220.127.116.11 & destination-18.104.22.168 which is loopback of US router). I have made static route on India router for US loopback so that 22.214.171.124 can reach US n/w via its own BGP.
Now my problem is, whenever 126.96.36.199 interface is down, it effects 188.8.131.52 interface also & my all network stops responding. I am attaching the log file as below & help-
"Midchain parent maintenance for IP midchain out of Tunnel-2 6643C7A0 - looped chain attempting to stack."
I have a feeling that you have somewhere created a circular dependency of a tunnel endpoint pointing through the tunnel itself. Can you please verify very carefully how your routing table looks or theoretically looks like in the moment then the 184.108.40.206 interface goes down? Is it possible that a tunnel endpoint resolves through the tunnel itself? Note that this recursion may be several steps long until you come back to the tunnel interface.
Hi, As we have two links on India end and One link on US end on same ISP MPLS cloud. If I give public IP of US as the destination address on India side, it is talking any path of both link to reach US. As we have different EIGRP policies on EIGRP GRE, so our prime requirement is to reach US via respective links only. This the reason, I have created loopback on US end and Static route on India end, so that 220.127.116.11 can exit via its own link.
I am sorry but I am going to repeat myself. I suspect you have a routing problem whereby a tunnel endpoint points through the tunnel itself. Following is the quotation from the IOS 12.2SB System Message Guide at:
ADJ-5-PARENT : Midchain parent maintenance for [chars] - [chars]
Explanation: A midchain adjacency failed to stack onto output chain because a loop was detected. Traffic through the adjacency will be dropped until the adacencyj is restacked. This condition is typically transient and is rectified by the control plane driving stacking. For example, if an ip tunnel destination resolves through the tunnel transiently this message would appear. The situation would be rectified either by learning the tunnel destination through an inteface other than the tunnel itself or by bringing the tunnel down
Recommended Action: No action is required.
I believe that Peter is correct. While there are aspects of what Rupesh is doing and what the problem really is that I do not understand, I recently had an experience with Midchain parent maintenance that may shed some light on this.
In my case I was running GRE tunnels with IPSec and running EIGRP over the tunnels. I had a static route for the tunnel end point and was learning other routes over the tunnel. I had a couple of episodes of Midchain parent maintenance and opened a TAC case. We determined that something happened on the outbound interface and the static route to the endpoint was removed from the routing table. At that instant EIGRP had not converged and CEF determined that the tunnel end point was reachable via a route learned through the tunnel. This produces the recursive problem of attempting to reach the tunnel end point via the tunnel and triggers the Midchain parent maintenance. Since EIGRP will detect loss of the neighbor and quickly converge, the problem is very short lived.
I suspect that Rupesh is experiencing something very similar.
I am not sure that there is a good or easy answer to your question. This problem happens when the outbound physical interface goes down. So the way out of this problem would be to prevent the outbound physical interface from going down. (can we really do that?)
I would suggest that you consider this error message to be very similar to the Interface is down message that is generated when an interface goes down. Would you look for a way to prevent the interface is down message? Or do you just acknowledge that an event occurred? I think that you need to look at the midchain maintenance message in the same way.
I have another thought about this. Since the midchain maintenance error seems to be associated with CEF processing being so efficient, perhaps if you disable CEF then you could prevent the midchain maintenance error.
But I would advise not to disable CEF. The advantages of CEF are far greater than the benefit of not seeing the midchain maintenance error message.