cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1612
Views
0
Helpful
9
Replies

Two GRE tunnel on the router & Eigrp issue

Rupesh Kashyap
Level 1
Level 1

Hi, I have two links on Same router having IP 1.1.1.1 & 2.2.2.2 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 20.20.20.20. 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-1.1.1.1& Destination-10.10.10.10).

I have created Tunnel-2 (Source 2.2.2.2 & destination-20.20.20.20 which is loopback of US router). I have made static route on India router for US loopback so that 2.2.2.2 can reach US n/w via its own BGP.

Now my problem is, whenever 2.2.2.2 interface is down, it effects 1.1.1.1 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."

9 Replies 9

Peter Paluch
Cisco Employee
Cisco Employee

Hello Rupesh,

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 2.2.2.2 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.

Best regards,

Peter

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 2.2.2.2 can exit via its own link.

Champs , pls help.

Rupesh,

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:

http://www.cisco.com/en/US/docs/ios/12_2sb/system/messages/sm2sb01.html#wp1012766

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.

Best regards,

Peter

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.

HTH

Rick

HTH

Rick

Yes, you are 100% currect. What is the best wayout of this problem?

Rupesh

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.

HTH

Rick

HTH

Rick

Rupesh

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.

HTH

Rick

HTH

Rick

thanks Rick for your precious time.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: