Some of this info has been posted as a reply in an earlier question. My main concern is during a capture I am seeing packets not destined for my IP. I have no SPAN sessions configured and some packets are from other networks even. (Kurt) I am using a Cisco IronPort web security appliance that utilizes WCCP as well as a Catalyst 6500 which uses CEF. I am not very familiar with either of those technologies but will be doing some research. asked 31 May '12, 15:57  davj1 |
2 Answers:
It happens. You usually see one unicast frame every once in a while that is not for you. The reason is that the switch has removed the MAC address of the target from its internal table, and the next time a frame comes in it has to flood it to all ports because it doesn't know anymore where the target system is connected at. As soon as the answer comes back in it records the port of the MAC address and you'll see no more frames of that communication. Until the switch once again forgets the entry... answered 31 May '12, 17:10  Jasper ♦♦ |
If the addresses are neither broadcast nor multicast (please double check IP and MAC), then I would say its either a bug of the switch firmware or maybe a kind of overload situation, where the switch runs into "fail-open" mode to prevent network interruption. Check the switch logs.
Please check what @Jasper said.
If the SYN was initiated from the remote server, it's probably the problem that @Jasper mentioned. If so (and it's not the WCCP/CEF problem - see below), please mark his answer as the correct one. If the SYN was initiated from the local server, it's most certainly not the problem that @Jasper mentioned, as it would mean that the switch did not know the mac address of the router, which would be rather uncommon in a busy network.
In that case it could be a similar problem I discovered once with WCCP and CEF, if the IP addresses you see, would be forwarded via WCCP. Problem: Once in a while (maybe 1-4 times a week) a SQL "batch sync job" failed after one server was moved to a different data center. There was a Riverbed involved that used WCCP to get the traffic forwarded from the internal router (out of path deployment). I analyzed the problem and found a single SYN packet being forwarded by CEF to the wrong gateway (according to the routing table) instead of being forwarded by WCCP to the Riverbed. This misrouted packet, caused a problem due to asymmetric routing through the Riverbed, with the result, that the TCP connection could not be established. Unfortunately that software was dumb enough not to retry and thus it generated a severe problem with the SQL data sync !??! Don't ask, it was a (possibly) dumb OS (AS400) and (possibly) dumb software ;-) I never found a plausible explanation, but disabling CEF solved the problem. I did this, because I found some hints after running some commands on the cisco router (I believe "show wccp" and "show cef"). Unfortunately I cannot remember the details of what I saw/found. However, it was pretty easy to spot, as I'm not a Cisco specialist (just enough know-how to configure the basics+). WARNING: Disabling CEF led to a remarkable higher CPU load on the router (~ +10-15%), however that was tolerable as it fixed a tedious problem ;-) Just an idea.... Regards answered 31 May '12, 17:54  Kurt Knochner ♦ edited 31 May '12, 18:03 |
Thank you to both of you for the ideas. Jasper, I am fighting to like your answer. I think it's 100% right but it just seems so simple I hate to agree with it :) I am definitely only seeing sporadic packets make it to me and I have not yet verified that they did NOT make it to the intended device so I think I'll go with that.
Kurt - Hopefully I can keep that obscure knowledge in the back of my head. Your answer lead me to do some research and learning on CEF and WCCP. This being my first couple years as a CCNA, I always enjoy learning something new.
maybe it's better not to memorize that kind of things ;-))
did you check the direction of those SYN packets? Is the initiator (source ip) the internal endpoint or the external endpoint - see my explanation above.
If you can't decide between the answers, then mark Jaspers answer as the correct one, as he was first, and it's a very plausible explanation. If you want, you can also click on the "Like" button of my answer to award some points to me as well. Fair solution ;-))