06-28-2017 09:42 PM - edited 03-05-2019 08:46 AM
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
Solved! Go to Solution.
07-11-2017 01:30 AM
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.
07-05-2017 01:50 PM
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?
07-05-2017 05:16 PM
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
07-05-2017 11:18 PM
CSCvf12977
07-10-2017 05:02 PM
Thanks,
I have not enough permission to see CSCvf12977.
Please let me know about detail of CSCvf12977 and workaround?
Best regards,
Yasuhiro
07-11-2017 01:30 AM
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.
07-11-2017 01:00 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide