1921 Router intermitently stops routing for 1 machine

[jpatterson1357]

This is happening every couple of days. It's always with the same machine and reloading the router is the only way to fix it. When it happens the machine can ping the router and the router can ping the machine traceroute from the machine to the outside stops at the router.  Below is a sanitized config the problem is always with the 192.168.0.72 machine. Any help in troubleshooting this is appreciated.

hostname R1
!
boot-start-marker
boot-end-marker
!
enable secret 5
!
no aaa new-model
!
ip domain name example.com
ip cef
no ipv6 cef
multilink bundle-name authenticated
!
cts logging verbose
!
license udi pid CISCO1921/K9 sn
!
username admin privilege 15 secret 5
!
redundancy
!
interface Embedded-Service-Engine0/0
 no ip address
 shutdown
!
interface GigabitEthernet0/0
 ip address xxx.xx.xx.242 255.255.255.240
 ip access-group 115 in
 ip nat outside
 ip virtual-reassembly in
 duplex auto
 speed auto
 no mop enabled
!
interface GigabitEthernet0/1
 ip address 192.168.0.11 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 duplex auto
 speed auto
 no mop enabled
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
ip nat pool ovrld xxx.xx.xx.250 xxx.xx.xx.254 prefix-length 24
ip nat inside source list 7 pool ovrld overload
ip nat inside source static tcp 192.168.0.30 80 xxx.xx.xx.243 80 extendable
ip nat inside source static tcp 192.168.0.30 443 xxx.xx.xx.243 443 extendable
ip nat inside source static 192.168.0.72 xxx.xx.xx.244
ip nat inside source static 192.168.0.73 xxx.xx.xx.245
ip nat inside source static tcp 192.168.0.61 80 xxx.xx.xx.246 80 extendable
ip nat inside source static tcp 192.168.0.61 443 xxx.xx.xx.246 443 extendable
ip nat inside source static tcp 192.168.0.61 943 xxx.xx.xx.246 943 extendable
ip nat inside source static udp 192.168.0.61 1194 xxx.xx.xx.246 1194 extendable
ip route 0.0.0.0 0.0.0.0 xxx.xx.xx.241
!
dialer-list 1 protocol ip permit
!
access-list 7 permit 192.168.0.0 0.0.0.255
access-list 115 deny   udp any any eq tftp
access-list 115 deny   tcp any any eq 22
access-list 115 deny   udp any any eq 22
access-list 115 deny   tcp any any eq sunrpc
access-list 115 deny   udp any any eq sunrpc
access-list 115 deny   tcp any any eq 135
access-list 115 deny   udp any any eq 135
access-list 115 deny   udp any any eq netbios-ns
access-list 115 deny   udp any any eq netbios-dgm
access-list 115 deny   tcp any any eq 139
access-list 115 deny   udp any any eq netbios-ss
access-list 115 deny   tcp any any eq 445
access-list 115 deny   tcp any any eq 593
access-list 115 deny   tcp any any eq 32775
access-list 115 deny   udp any any eq 32775
access-list 115 deny   tcp any any eq 32777
access-list 115 deny   udp any any eq 32777
access-list 115 deny   tcp any any eq 4444
access-list 115 permit ip any any
!
control-plane
!
line con 0
line aux 0
line 2
 no activation-character
 no exec
 transport preferred none
 transport output pad telnet rlogin lapb-ta mop udptn v120 ssh
 stopbits 1
line vty 0 4
 privilege level 15
 login local
 transport input ssh
!
scheduler allocate 20000 1000
!
end

R1#exit

[Richard Burts]

There are a couple of possibilities to investigate to explain this issue.

- first I would check the logs and see if there is any log message involving 192.168.0.72.

- and while you are checking syslogs look for any log message about unusual system events.

- there is a static nat for the 192.168.0.72. So I would suggest checking to make sure that the translation is still working. In normal operation check the translation table and document what a normal entry looks like. Then when the problem is experienced check the translation table and see if the entry for 192.168.0.72 has changed.

- I wonder if there is any possibility of an issue with the ARP table. So I would suggest that in a period of normal operation that you show arp and document what the normal entry is. Then during a period when the problem is experienced check the table and see if the entry has changed.

HTH

Rick 

[jpatterson1357]

It has happened twice today and I can't see anything in the log, NAT or ARP tables that would suggest a problem. Attached is an example of it working and not working

[Richard Burts]

Thanks for posting these files with the output. I am puzzled that I do not find any entries for 192.168.0.72 in either of the files.

HTH

Rick

[jpatterson1357]

Sorry about that. Forgot I had changed the internal IP's. This is the current static nat rules for what was .72 and .73 in the original config

ip nat inside source static 192.168.0.70 xxx.xx.xx.244
ip nat inside source static 192.168.0.71 xxx.xx.xx.245

[Richard Bradfield]

Have you tried upgrading to the latest IOS 15.4(3)M4 which is ED or 15.3(3)M6 which is an MD release. In the past when I have had these type of funnies Cisco advise upgrade to latest IOS.

[Richard Burts]

Thanks for the clarification about changing addresses. Is it correct to understand that 192.168.0.71/245 always works and that 192.168.0.70/244 sometimes works but occasionally fails? And that when there is a problem the router and the host can still access each other but that the host has no connectivity beyond the router?

HTH

Rick 

[jpatterson1357]

That is correct.

Jim