OT: IP network traffic that doesn't belong

[monkeyhead]

It makes sense that the Access Point radiomodem acts as a network bridge and sent these packets out onto the radio side when they arrived on the Ethernet side. Likewise, the Client radio modem received them on the radio side and sent them out the Ethernet side. They didn't know any better because they didn't have the destination MACID in their address tables, so they treated it the same way they'd treat a broadcast.

But it should not have arrived on the Ethernet side. These packets are clearly part of a TCP stream, so the switches involved have to know where the endpoints are.

If it's purely a Layer 2 device, it's not going to care that there is part of TCP stream stored inside the Ethernet frame. It's just trying to get the frame to the proper host regardless of what's inside.

Higher end managed switches may be able to filter based on the contents of the frame since many of them wander over into Layer 3 capabilities, but if it's acting as a layer two bridge, forwarding and filtering are all based of the MAC address and the internal address table only.

 

[monkeyhead]

including telling me which port I was connected to.

Here's a little screencast that explains how Wireshark can do a little of the same, by watching for packets of the Cisco Discovery Protocol (as long as the switches support that).

This is a great trick. My company has a lot of Linux hosts and I've got a script that does the same thing. Sadly it hadn't dawned on me to use wireshark... There's my duh moment for today.

 

[SteveMaves]

Thanks for posting that capture file, Ken. Also, appreciate the info. about the dual comm device, the least expensive "tap" that I'd found so far was a Linksys RVS4000, at about $100 used.

 

[Ken Roach]

As a followup: I now have two captures from the wired network and none of them show the "out of place" TCP traffic.

During troubleshooting using a Fluke cable tester, the onsite engineer found one of the Ethernet cables from a power monitor had induced voltage on the cable, so it's a new hypothesis that this might have affected one of the switches.

I'm going to have him use a capture filter in Wireshark (for "tcp" only) and run for an hour at a time on the wired ports. Curiouser and curiouser.

 

[Ken Roach]

Update: we narrowed down the out-of-place traffic to one Cisco WS-2950-24 switch and can repeatably capture "bursts" of a dozen packets or so that get misdirected every several minutes.

We substituted an N-Tron 508TX for the lightly-loaded Cisco WS-2950-24 and have not yet captured any "out of place" frames.

Cycling power to the Cisco switch also led to "locking up" of all the SLC controllers connected directly to that switch, ceasing communications until they were all power cycled. Curious... I want to capture the Cisco unit in my lab to figure out if this is a failing switch or a configuration problem.

 

[monkeyhead]

Thanks for the update Ken. That's very curious. I've never seen an SLC's ethernet comms lock up in that manner in a switched environment.

We used to have an old hub that was a horrific collision domain with a couple SLC 5/05's on it, and it every once in a while with heavy network traffic, the collision light on the hub would flicker non-stop and one or more of the controllers might get 'locked up' in that manner.

Since it's Cisco, you may be able to update or reload the IOS on the switch and be back in business.