I have a problem accessing some devices remotely...
I have established connectivity to the devices but after an hour or 2 I will not be able to access those devices. The workaround that I have been using is clar the arp table on our 2611 router, establishing connectivity (icmp) then I can reach the devices- but only for about an hour or so before I start the process again. I have updated both IOS versions on the switch and router to what TAC recommended- I actually replaced the router , which narrows it down to the switch...
Has anyone experienced similar problems with their devices? If so, What is the recommended fix?
The fact that clearing the ARP cache fixes it, would lean me toward garbage in the router arp cache. perhaps even a duplicate IP situation from a device that does not talk all that often. When it does, a new entry is added, and your telnet sessions terminate on a device that doesn't answer.
More common is a device that speakes less frequently that the arp cache timeout. As such, it disappears until it speaks again. A clear sign of this is when a ping (or anything else) out of the lost device restores remote connectivity.
I understand your view, however I have IDS devices on that link that are continually capturing traffic and reporting it back to a console here at my HQ.
I also staticly entered the IP to MAC addresses of those IDS devices into the router arp table... Also in viewing the arp table there were no duplicate matches + there are only 5 devices on the remote network out of a class C subnet.
I'm having the exact same problem with 2 WIN2000 Servers. They are both connected to the same switch, and the only people using the servers are also connected to the switch. In fact, some users are able to ping the servers and others time out...at the exact same time. If I check the arp table on my 3640, they both have entries. I have not been able to find any duplicate MAC addresses or IP's. I'm going to be working more on this, and I'll let you know.
It works when I clear the arp table on the router- . I can then establish icmp & telnet to the IDS boxes that I need to pull logs from. So its not as if it doesnt work sometimes- It does, other times it won't.
And what I have seen in the past 2 days of this forum is that there are a couple of other cases involving 3500 series switches that are having very similar probems.
I figured out what my problem was, and here's the low-down: My servers are on the internal network with static NAT translations on my PIX firewall. I had alias commands on my PIX in order for internal hosts to be able to view the server using the same web site that users on the internet are using.
Start a sniffer application and start capturing packets. Clear the arp in your router and on a local PC ("arp -d" and "arp -a" allows you to view your local arp table). Ping the server by name or by IP address...it doesn't matter. With the alias command on my PIX520 running v. 6.1.1, I get two arp replies. I get one from the server with the correct MAC address, and shortly after, I receive a second arp reply with the PIX's MAC address. Remove the alias command, and the only arp reply will be the one from the server itself.
The reason some people see the server sometimes, and others see it all the time has to do with network congestion and latency. If you don't have a PIX, check your DNS server for any misconfigurations. Just a thought.
Thanks Tim, that is good to know. I do have a PIX on that network but it is not filtering trafic at the moment . we previously used it for VPN stuff but know it just has a leg into the remote network. The only way (theoretically) it will see any traffic is if the router has any unknown route paths it will forward everything to its default gateway (PIX). i also have Cisco IDS on that network which are causing some question...
Other than that , there hasnt really been any progress in my issue. I will sniff the traffic again to see if our issues could be related.
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...