We have Cisco 7206vxr Router installed at the Customer site and facing issue as described below and our Observation during the Network gets unreachable.
1. Remote VSATs are up and next IP (Fa0/1) also reachable from DC-1 Router.snap shot attached 2. Local (DC router) Tunnels is up and pinging but branches tunnels is not pinging from DC router, ALL GRE tunnel was found down during this period 3. No bandwidth Utilization on WAN Interface (Gi0/2) 4. All branches LAN IP is unreachable and trace route dropped at DC-1 LAN IP address 5. After WAN interface Gig0/2 Shutdown & No shut, network comes to normal .
Debug tunnel output:-
Feb 2 23:18:40.689: Tunnel234: GRE/IP encapsulated 220.127.116.11->18.104.22.168 (link type=7, len=48) Feb 2 23:18:40.689: Tunnel234 count tx, adding 24 encap bytes
Also All the respective logs attached here and need further suggestion on this case if some bug impact or some Hardware impact.
Current IOS image: c7200p-advsecurityk9-mz.124-24.T8.bin
your "sh tech" is showing that G0/2 is in admin down state, so all the other information is not interesting.
Could you please provide "sh tech" right after the issue occures (before you troubleshoot it), then try to shut/no shut interface (if it helps) and provide the log (you might need to increase log size, as 50K is not enough for 1K tunnels).
Could you please provide tunnel configuration from any site?
Is it possible to capture traffic on G0/2 during the issue (SPAN)? If capture is not possible, could you try:
ip access-l ext 199
permit ip host 22.214.171.124 host 126.96.36.199
permit ip host 188.8.131.52 host 184.108.40.206
debug ip pack 199
try pinging 220.127.116.11, pingning 18.104.22.168 and capture debug output for 60 seconds.
(please add "show ip route" as weel)
Try to clear counters on int g0/2 and check what's happening on the interface (CRC, runts, whatever).
Do you have any CoPP or service-policy applied to filter/rate limit any traffic on G0/2 ?
Was 10.113.117.202 reachable and did you had NLRI between the source and destination tunnel addresses prior to you restarting gig0/2 manually?
I can see an acl relating to icmp but it seems it not alowing return traffic, Is this acl applied anywhere? I cannot see that it is or had it been?
Looking at you show tech readout, the interface counts have never been cleared so the history stats could be showing old values and the gig0.2 interface is in admin shutdown -Also a alot of static routing going on
At first glance of this, I suspect that a possible l issue on this gig0/2 link caused a lost of reacability to your branches thus dropping the tunnels which are only shown going down due you having keepalives applied.
The question is, if it was a issue with the line or the port and then why did you experience that issue,
Have you checked with your ISP for possible disuption to this link and it realting ports ( if applicable)
Have you checked the physical ports/cabling on this router?
Please don't forget to rate any posts that have been helpful.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...