Solved: Tunnel over internet was down due to recursive routing during the DHCP renewing

Yasuhiro Ujihara · ‎06-28-2017

Hi,

I encountered contituously Tunnel interface down symptom during DHCP renewing.

Could you please help me to avoid Tunnel down symptom?

Condition:

-----------------------------------

Hardware: CISCO892-K9

Software: IOS 15.3(3)M1

Topology

-----------------------------------

<YYY.YYY.YYY.YYY> <YYY.YYY.YYY.ZZZ> <XXX.XXX.XXX.XXX>

[CISCO892](GE0)-----(CATV modem)------(CATV)-------[CATV gateway router]----(internet)--------[ASR1002-X]

| | |

| [CATV DHCP server] |

| |

|<--------------------------------------------------IPSec GRE Tunnel--------------------------------->|

IPSEC GRE tunnel is established between CISCO892 and ASR1002-X

The default gateway of CISCO892 is learedn from CATV DHCP server.

A part of configuration on CISCO892:

--------------------------------------------------------------------------------------------------

ip cef

ip route 0.0.0.0 0.0.0.0 dhcp

interface Tunnel20

ip address 10.1.1.2 255.255.255.252

tunnel source GigabitEthernet0

tunnel mode ipsec ipv4

tunnel destination XXX.XXX.XXX.XXX (ip address of ASR1002-X)

interface GigabitEthernet0

ip address dhcp

----------------------------------------------------------------------------------------------------

ERROR log:

----------------------------------------------------------------------------------------------------

From syslog, such aMidchain parent maintenance error message is recorded every DHCP renewal：

%ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of Tunnl 20 - looped chain attempting to stack

And once every five DHCP renewal times, Tunnel interface is down with the following error messages:

%TUN-5-RECURDOWN: Tunnel20 temporarity disabled due to recursive routing

%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel20, changed state to down

----------------------------------------------------------------------------------------------------

a part of CEF table:

----------------------------------------------------------------------------------------------------

From show ip cef GigabitEthernet0 detail:

0.0.0.0/0, epoch 0, flags cover dependants, default route

Covered dependant prefixes: 2

notify cover updated: 2

recursive via YYY.YYY.YYY.ZZZ (ip address of CATV gateway router)

attached to GigabitEthernet0

XXX.XXX.XXX.XXX/32, epoch 0, flags default route (ip address of ASR1002-X)

1 RR source [active source]

Dependant covered prefix type rr, cover 0.0.0.0/0

recursive via 0.0.0.0/0

recursive via YYY.YYY.YYY.ZZZ (ip address of CATV gateway router)

attached to GigabitEthernet0

----------------------------------------------------------------------------------------------------

Then I found a solution of this symptom:

Adding a static route to XXX.XXX.XXX.XXX/32: ip route XXX.XXX.XXX.XXX 255.255.255.255 GigabitEthernet0 dhcp

I've tried this solution for about 1 week (DHCP release time is 4 hour), I've never seen such error messages.

Is this solution correct?

And could you please tell me the reason why this solution works?

------------------------------------------------------------------------------------------------

From show ip cef GigabitEthernet0 detail after adding the static route

0.0.0.0/0, epoch 0, flags cover dependants, default route

Covered dependant prefixes: 2

notify cover updated: 2

recursive via YYY.YYY.YYY.ZZZ (ip address of CATV gateway router)

attached to GigabitEthernet0

XXX.XXX.XXX.XXX/32, epoch 0, flags default route (ip address of ASR1002-X)

1 RR source [no flags]

nexthop YYY.YYY.YYY.ZZZ GigabitEthernet0

vamikhai · ‎07-11-2017

Hello.

There are not much details. I submitted the bug report based on the information you provided and repro I successfully did.

Basically your workaround looks valid, as DHCP-based routes are bounced not in parallel but one by one, so as far as you have two DHCP-based prefixes (0/0 and /32) covering the next-hop - you are safe with the tunnel state.

View solution in original post

Vasilii Mikhailovskii · ‎07-05-2017

Hello.

The issue looks interesting.

I tested 15.6(3)M2 and have seen the issue under certain conditions.

Could you please clarify what routing protocol do you have over the Tunnel and if you see 0.00.0.0/0 in protocol table?

Yasuhiro Ujihara · ‎07-05-2017

Thanks.

BGP is the routing protocol over the tunnel between CISCO892 and ASR1002-X.

BGP on ASR1002-X is advertising 0.0.0.0/0 through the tunnel.

ASR1002-X is a HUB of IPSEC tunnel and CISCO892 is on a branch office (a spoke).

Best regards,

Yasuhiro

Vasilii Mikhailovskii · ‎07-05-2017

CSCvf12977

Yasuhiro Ujihara · ‎07-10-2017

Thanks,

I have not enough permission to see CSCvf12977.

Please let me know about detail of CSCvf12977 and workaround?

Best regards,

Yasuhiro

vamikhai · ‎07-11-2017

Hello.

There are not much details. I submitted the bug report based on the information you provided and repro I successfully did.

Basically your workaround looks valid, as DHCP-based routes are bounced not in parallel but one by one, so as far as you have two DHCP-based prefixes (0/0 and /32) covering the next-hop - you are safe with the tunnel state.

paul driver · ‎07-11-2017

Hello

You have recursing routing due to the tunnels destination being learned over the tunnel itself.

So you need to make sure the tunnel source/destination addressing is not advertised over the tunnel and adding that static does rectify it.

res
Paul

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul