08-29-2012 10:30 AM - edited 03-04-2019 05:25 PM
Hi,
I am having a problem with a remote 871 router, periodically it goes down for some unknown reason. There is nobody on site with technical experience that can troubleshoot it once the site drops. Below is a section of the router log with entries from today and the sla lines from the config. Finding an adequate service provider in the area is probably not going to happen, so I'm hoping this issue can be resolved with a simple config change.
I do not think the fact that FA1 goes down is relevant because the tunnels are on FA4. I just turned on track debugging, so hopefully it will return something useful and not kill the router.
Thanks in advance,
Leonard
ip sla 10
icmp-echo 10.163.0.1
timeout 1000
frequency 3
ip sla schedule 10 life forever start-time now
ip sla 11
icmp-echo 10.163.8.1
timeout 1000
frequency 3
ip sla schedule 11 life forever start-time now
000092: Aug 29 01:52:10: %TRACKING-5-STATE: 11 rtr 11 reachability Up->Down
000093: Aug 29 01:52:15: %TRACKING-5-STATE: 11 rtr 11 reachability Down->Up
000094: Aug 29 06:09:27: %TRACKING-5-STATE: 10 rtr 10 reachability Up->Down
000095: Aug 29 06:09:27: %TRACKING-5-STATE: 11 rtr 11 reachability Up->Down
000096: Aug 29 06:09:34: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.163.8.1 (Tunnel3) is down: holding time expired
000097: .Aug 29 10:48:51: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet4, changed state to down
000098: .Aug 29 10:48:54: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel3, changed state to down
000099: .Aug 29 10:49:08: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet4, changed state to up
000100: .Aug 29 10:49:14: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel3, changed state to up
000101: .Aug 29 10:49:25: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.163.8.1 (Tunnel3) is up: new adjacency
000102: .Aug 29 10:49:29: %TRACKING-5-STATE: 10 rtr 10 reachability Down->Up
000103: .Aug 29 10:49:29: %TRACKING-5-STATE: 11 rtr 11 reachability Down->Up
000104: Aug 29 10:55:15: %LINK-3-UPDOWN: Interface FastEthernet1, changed state to up
000105: Aug 29 10:55:16: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1, changed state to up
000106: Aug 29 10:57:39: %TRACKING-5-STATE: 11 rtr 11 reachability Up->Down
000107: Aug 29 10:57:44: %TRACKING-5-STATE: 11 rtr 11 reachability Down->Up
000108: Aug 29 11:02:38: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1, changed state to down
000109: Aug 29 11:02:39: %LINK-3-UPDOWN: Interface FastEthernet1, changed state to down
000110: Aug 29 11:04:49: %TRACKING-5-STATE: 10 rtr 10 reachability Up->Down
000111: Aug 29 11:04:54: %TRACKING-5-STATE: 10 rtr 10 reachability Down->Up
000112: Aug 29 11:17:35: %TRACKING-5-STATE: 11 rtr 11 reachability Up->Down
000113: Aug 29 11:17:40: %TRACKING-5-STATE: 11 rtr 11 reachability Down->Up
000114: Aug 29 11:27:35: %TRACKING-5-STATE: 11 rtr 11 reachability Up->Down
000115: Aug 29 11:27:40: %TRACKING-5-STATE: 11 rtr 11 reachability Down->Up
000116: Aug 29 11:42:42: %LINK-3-UPDOWN: Interface FastEthernet1, changed state to down
000117: Aug 29 11:42:44: %LINK-3-UPDOWN: Interface FastEthernet1, changed state to up
000118: Aug 29 11:42:45: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1, changed state to up
000119: Aug 29 11:44:20: %TRACKING-5-STATE: 10 rtr 10 reachability Up->Down
000120: Aug 29 11:44:20: %TRACKING-5-STATE: 11 rtr 11 reachability Up->Down
000121: Aug 29 11:44:25: %TRACKING-5-STATE: 10 rtr 10 reachability Down->Up
000122: Aug 29 11:44:25: %TRACKING-5-STATE: 11 rtr 11 reachability Down->Up
000123: Aug 29 12:04:45: %TRACKING-5-STATE: 11 rtr 11 reachability Up->Down
000124: Aug 29 12:04:50: %TRACKING-5-STATE: 11 rtr 11 reachability Down->Up
000125: Aug 29 12:10:53: %SYS-5-CONFIG_I: Configured from console by vty0 (10.8.101.2)
08-29-2012 10:56 AM
Ok, so the debug didnt' provide any more information, it basically just gave me the same lines with the addition of another number.
Aug 29 12:51:21: Track: 11 Change #28 rtr 11, reachability Up->Down
Aug 29 12:51:21: %TRACKING-5-STATE: 11 rtr 11 reachability Up->Down
Aug 29 12:51:26: Track: 11 Change #29 rtr 11, reachability Down->Up
Aug 29 12:51:26: %TRACKING-5-STATE: 11 rtr 11 reachability Down->Up
Aug 29 12:53:01: Track: 11 Change #30 rtr 11, reachability Up->Down
Aug 29 12:53:01: %TRACKING-5-STATE: 11 rtr 11 reachability Up->Down
Aug 29 12:53:06: Track: 11 Change #31 rtr 11, reachability Down->Up
Aug 29 12:53:06: %TRACKING-5-STATE: 11 rtr 11 reachability Down->Up
08-29-2012 11:00 AM
Hello Leonard,
The tracking messages are, in my opinion, only a symptom of a different problem - that the reachability of the pinged addresses fluctuates strongly.
Can you perhaps provide us with complete configuration of that router? Also, can you be more specific about how this router is connected to the network - is it a DSL service or some other sort of connection? Try to be as descriptive as possible please. Thank you!
Best regards,
Peter
08-29-2012 11:19 AM
Hi Peter,
I just attached the config to the thread. This site is very remote and using a DSL connection. We do not have access to the modem for configuration or troubleshooting but I firmly believe this is a problem with the provider, but need to be sure so I can push them harder.
Thank you for your help,
Leonard
08-29-2012 11:38 AM
Hello Leonard,
I believe that the 871 does not have any built-in DSL modem - am I correct? In that case, there must be an external DSL modem/router installed at the remote site and connected to the Fa4 interface. Is this correct?
Can you perhaps post the output of the show interface Fa4 if that is accessible? Also, do you have any idea why the Fa4 interface flapped according to these log lines?
000097: .Aug 29 10:48:51: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet4, changed state to down
000098: .Aug 29 10:48:54: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel3, changed state to down
000099: .Aug 29 10:49:08: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet4, changed state to up
000100: .Aug 29 10:49:14: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel3, changed state to up
Best regards,
Peter
08-29-2012 12:01 PM
Hi Peter,
Correct, that DSL modem is external and provided by the ISP. I believe it flapped because we requested the local contact to temporarily disconnect the link, usually they just rebooted the router without calling us.
FastEthernet4 is up, line protocol is up
Hardware is PQUICC_FEC, address is 081f.f3e6.a79b (bia 081f.f3e6.a79b)
Internet address is 192.168.227.49/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:04, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/1/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 32000 bits/sec, 9 packets/sec
5 minute output rate 10000 bits/sec, 8 packets/sec
358869 packets input, 131210769 bytes
Received 3 broadcasts, 0 runts, 0 giants, 1 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog
0 input packets with dribble condition detected
376049 packets output, 74720952 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Thanks,
Leonard
08-29-2012 01:02 PM
Hello Leonard,
Thank you for this information. There is no indication for any obvious fault on the router. The issue, in my opinion, lies with the provider.
I suggest configuring a probe that simply verifies the reachability of your default gateway - assuming that whatever fault there is, it is located on the connection between your DSL modem and your default gateway:
ip sla 123
icmp-echo 192.168.227.1
timeout 500
frequency 1
ip sla schedule 123 life forever start-time now
Then use the show ip sla 123 statistics to gain basic statistics about how many pings were successful and unsuccessful. This test should be run over longer period of time - days or so - to gather statistically significant data. However, you can immediately watch whether the ratio of reported successful and unsuccessful probes is skewed towards unsuccessful results.
Best regards,
Peter
EDIT: You will also need to correct the ACL 101 to allow the return pings from 192.168.227.1.
08-29-2012 01:51 PM
Hi Peter,
I will make those changes and see what happens.
Thank you very much for your help,
Leonard
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