10-09-2013 06:27 AM - edited 03-04-2019 09:15 PM
Morning,
We have this ongoing issue that happens now and again (for some routers, not others, but never the same ones) at our branch locations where after they lose their internet service and their GRE/IPSec tunnel goes down and comes back up, the router fails to learn the default route over EIGRP. If you clear the neighbors on the branch side, is then in the topology and routing table.
e.g:
EIGRP-IPv4 Topology Table for AS(1)/ID(202.14.135.34)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.5.17.0/24, 1 successors, FD is 28160
via Connected, Vlan1
via 10.5.217.130 (28416/2816), Vlan220
via 10.5.217.2 (28416/2816), Vlan200
P 172.19.17.0/24, 1 successors, FD is 21280000
via Connected, Tunnel0
P 10.5.217.128/25, 1 successors, FD is 28160
via Connected, Vlan220
via 10.5.217.2 (28416/2816), Vlan200
via 10.5.17.252 (28416/2816), Vlan1
P 172.30.217.0/24, 3 successors, FD is 11282688
via 10.5.17.252 (11282688/11280128), Vlan1
via 10.5.217.2 (11282688/11280128), Vlan200
via 10.5.217.130 (11282688/11280128), Vlan220
P 10.5.217.0/25, 1 successors, FD is 28160
via Connected, Vlan200
via 10.5.217.130 (28416/2816), Vlan220
via 10.5.17.252 (28416/2816), Vlan1
P 172.30.117.0/24, 3 successors, FD is 6282752
via 10.5.17.252 (6282752/6280192), Vlan1
via 10.5.217.2 (6282752/6280192), Vlan200
via 10.5.217.130 (6282752/6280192), Vlan220
Tunnel in question:
interface Tunnel0
bandwidth 128
ip address 172.19.17.2 255.255.255.0
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 chain1
ip hello-interval eigrp 1 10
ip hold-time eigrp 1 45
tunnel source 202.14.135.34
tunnel destination 199.69.11.1
tunnel path-mtu-discovery
eigrp:
router eigrp 1
network 10.5.17.0 0.0.0.255
network 10.5.217.0 0.0.0.255
network 172.19.17.0 0.0.0.255
passive-interface FastEthernet0/0
eigrp stub connected
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 6 subnets, 3 masks
C 10.5.17.0/24 is directly connected, Vlan1
L 10.5.17.251/32 is directly connected, Vlan1
C 10.5.217.0/25 is directly connected, Vlan200
L 10.5.217.3/32 is directly connected, Vlan200
C 10.5.217.128/25 is directly connected, Vlan220
L 10.5.217.131/32 is directly connected, Vlan220
172.19.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.19.17.0/24 is directly connected, Tunnel0
L 172.19.17.2/32 is directly connected, Tunnel0
172.30.0.0/24 is subnetted, 2 subnets
D 172.30.117.0 [90/6282752] via 10.5.217.130, 1d18h, Vlan220
[90/6282752] via 10.5.217.2, 1d18h, Vlan200
[90/6282752] via 10.5.17.252, 1d18h, Vlan1
D 172.30.217.0 [90/11282688] via 10.5.217.130, 20:32:30, Vlan220
[90/11282688] via 10.5.217.2, 20:32:30, Vlan200
[90/11282688] via 10.5.17.252, 20:32:30, Vlan1
199.69.11.0/32 is subnetted, 1 subnets
S 199.69.11.1 [1/0] via 202.14.135.1
202.14.135.0/24 is variably subnetted, 2 subnets, 2 masks
C 202.14.135.0/30 is directly connected, FastEthernet0/0
L 202.14.135.1/32 is directly connected, FastEthernet0/0
ip route 199.69.11.1 255.255.255.255 202.14.135.1
show ip eigrp nei
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.19.17.1 Tu0 41 06:33:06 52 1122 0 5931911
3 10.5.217.130 Vl220 14 1d18h 652 3912 0 1072
2 10.5.217.2 Vl200 13 1d18h 1 200 0 1070
1 10.5.17.252 Vl1 12 1d18h 652 3912 0 1071
any ideas? I can post more information if required, but nothing seems to point to anything i can think of. clearing the neighbors brings it all back and we're good..
10-09-2013 03:37 PM
Can you post the output of from this router and from 172.19.17.1 -
show ip eigrp topology | se 0.0.0.0/0
show ip eigrp topology all-links | se 0.0.0.0/0
show ip eigrp topology 0.0.0.0/0
10-10-2013 09:57 AM
Site router:
1861#show ip eigrp topology | se 0.0.0.0/0
1861#
1861#show ip eigrp topology all-links | se 0.0.0.0/0
1861#
1861#show ip eigrp topology 0.0.0.0/0
EIGRP-IPv4 Topology Entry for AS(1)/ID(207.148.135.34)
%Entry 0.0.0.0/0 not in topology table
From head router (we have a bunch of tunnels on this router, on seperate tunnel vrf)
HEAD_R#show ip eigrp vrf int_tunnel topology | se 0.0.0.0/0
P 0.0.0.0/0, 1 successors, FD is 2816
via Summary (2816/0), Null0
HEAD_R#
HEAD_R#$rp vrf int_tunnel topology all-links | se 0.0.0.0/0
P 0.0.0.0/0, 1 successors, FD is 2816, serno 280828
via Summary (2816/0), Null0
via 172.17.101.2 (22563072/6283008), Tunnel1001
via 172.17.122.2 (22560768/6280704), Tunnel1022
via 172.19.32.2 (22563072/6283008), Tunnel5032
via 172.17.102.2 (22560768/6280704), Tunnel1002
via 172.19.4.2 (22563072/6283008), Tunnel504
via 172.24.55.2 (22560512/6280448), Tunnel4055
via 172.19.14.2 (22563072/6283008), Tunnel5014
HEAD_R#
HEAD_R#show ip eigrp vrf int_tunnel topology 0.0.0.0/0
EIGRP-IPv4 Topology Entry for AS(1)/ID(172.84.7.1) VRF(int_tunnel)
EIGRP-IPv4(1): Topology base(0) entry for 0.0.0.0/0
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2816
Descriptor Blocks:
0.0.0.0 (Null0), from 0.0.0.0, Send flag is 0x0
Composite metric is (2816/0), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 10 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 0
Originating router is 172.84.7.1
Exterior flag is set
172.17.101.2 (Tunnel1001), from 172.17.101.2, Send flag is 0x0
Composite metric is (22563072/6283008), route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 100120 microseconds
Reliability is 255/255
Load is 28/255
Minimum MTU is 1396
Hop count is 3
Exterior flag is set
172.17.122.2 (Tunnel1022), from 172.17.122.2, Send flag is 0x0
Composite metric is (22560768/6280704), route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 100030 microseconds
Reliability is 255/255
Load is 2/255
Minimum MTU is 1396
Hop count is 3
Exterior flag is set
172.19.32.2 (Tunnel5032), from 172.19.32.2, Send flag is 0x0
Composite metric is (22563072/6283008), route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 100120 microseconds
Reliability is 255/255
Load is 15/255
Minimum MTU is 1396
Hop count is 3
Exterior flag is set
172.17.102.2 (Tunnel1002), from 172.17.102.2, Send flag is 0x0
Composite metric is (22560768/6280704), route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 100030 microseconds
Reliability is 255/255
Load is 255/255
Minimum MTU is 1396
Hop count is 3
Exterior flag is set
172.19.4.2 (Tunnel504), from 172.19.4.2, Send flag is 0x0
Composite metric is (22563072/6283008), route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 100120 microseconds
Reliability is 255/255
Load is 110/255
Minimum MTU is 1396
Hop count is 3
Exterior flag is set
172.24.55.2 (Tunnel4055), from 172.24.55.2, Send flag is 0x0
Composite metric is (22560512/6280448), route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 100020 microseconds
Reliability is 255/255
Load is 25/255
Minimum MTU is 1396
Hop count is 2
Exterior flag is set
172.19.14.2 (Tunnel5014), from 172.19.14.2, Send flag is 0x0
Composite metric is (22563072/6283008), route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 100120 microseconds
Reliability is 255/255
Load is 255/255
Minimum MTU is 1396
Hop count is 3
Exterior flag is set
HEAD_R#
10-10-2013 03:56 PM
This is not normal, HEAD_R has 0.0.0.0 in the topology and should have in the routing table as well.
And if the neighborship with 1861 is up the route should be propogated to the it. But it's not.
Please check if it is for the 0.0.0.0 only or is 1861 not receiving any route from 172.19.17.1(HEAD_R)
Also, check if you are reciving any routes advertised by 1861 on HEAD_R.
If not a single route is advertised, I would suggest you to open a TAC case, might be a BUG or something.
Post the show version of HEAD_R and 1861 as well, I'll check as well.
-Vishesh
10-11-2013 06:25 AM
on the 1861 there are no routes learned from HEAR_ (although the 1861 is a stub, so default route is all that it's getting under normal operation).
on the HEAD_R router, it is learning connected routes from 1861 (10.5.17.0/24 is local subnet off of 1861):
HEAD_R#$rp vrf backhaul topology | section 10.5.17.0/24
P 10.5.17.0/24, 1 successors, FD is 6280704
via 10.13.13.242 (6280704/6280448), GigabitEthernet0/0 <- (path to a second backup router which uses a different service/circuit)
via 172.19.17.2 (21282560/28160), Tunnel5017 <-tunnel to 1861
2951 is 'HEAD_R' running 151-3.T2 with base/security/UC license.
1861 is '1861' running 151-3.T2 (Advanced IP Services)
thanks,
10-11-2013 08:20 AM
The router will only advertise routes that are in its routing table. So if the route is in the topology table but not in the routing table, then router won't advertise it to its peers.
Another thing is that more than one office has experienced this. If so, you might want to look more at the config of the hub, which in this case is the head router. It would be helpful if you could post the config of one of the spokes(branch router) and that of the hub so we can take a look.
Sent from Cisco Technical Support Android App
10-11-2013 12:54 PM
Hello
Until you resolve your connectivity issue ,You can manipulate the eigrp timers to back off convergence and possible SIA for successors
This will result in your routes still being valid for a longer period
Ip hello-interval eigrp x 60
Ip hold-time eigrp x 180
Timers active-time xx
R&S
Paul
Sent from Cisco Technical Support iPad App
10-11-2013 01:00 PM
thanks for the replies.
The HEAD_R router does have a default route in it's routing table:
HEAD_R#show ip route vrf backhaul | sec 0.0.0.0/0
S* 0.0.0.0/0 [1/0] via 10.13.13.250
10.0.0.0/8 is variably subnetted, 426 subnets, 6 masks
i'll work on cleaning up the configs and get them posted.
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: