Netgear GSM7224 switch playing dumb

My request on the netgear forums wasnt getting much attention, so I will try here. I recently found out I have a Netgear GSM7224 24 point gigabit switch. Upon visual inspection, I immediately noticed the synchronously flashing lights on the netgear. Sure enough, plugging ethereal on my lap top (no ip configured) into the switch, I received tons of frames destined for end devices on the switch. Its like the switch is playing dumb and forwarding all frames to all ports. As far as I can tell the switch is in its default configuration. All ports are set to Untagged and Included in VLAN 1 (the default vlan). LACP has been disabled on all ports. I am not doing anything crazy on this thing, but it would rather be a hub/repeater than a switch. I upgraded code to the latest release this morning - still no go. Anyone else out there have this problem with netgear? Or have a suggestion as to the why behind this behavior? Thanks in advance.

Here is an example packet that is supposed to go from port 6 to port 21 on the switch - but all ports are getting it. The MAC addresses for each of these locations are in the MAC-addr-table (the only macs on their respective ports). Here is the header on an ethereal capture:

Frame 5453 (1366 bytes on wire, 1366 bytes captured) Arrival Time: Oct 31, 2005 12:18:28.856193000 Time delta from previous packet: 0.000112000 seconds Time since reference or first frame: 33.368478000 seconds Frame Number: 5453 Packet Length: 1366 bytes Capture Length: 1366 bytes Protocols in frame: eth:ip:tcp:nbss:smb Ethernet II, Src: 10.1.252.7 (00:06:5b:f1:79:cc), Dst: 10.1.252.56 (02:bf:0a:01:fc:1e) Destination: 10.1.252.56 (02:bf:0a:01:fc:1e) Source: 10.1.252.7 (00:06:5b:f1:79:cc) Type: IP (0x0800) Internet Protocol, Src: 10.1.252.7 (10.1.252.7), Dst: 10.1.252.56 (10.1.252.56)

Reply to
jere
Loading thread data ...

Looking at the packet dump, it looks like, for the destination node at least, you are using locally administered MAC addresses and encoding the IP address in the MAC address. (Reminds me of my DECnet days...) For the destination node we have:

Destination: 10.1.252.56 (02:bf:0a:01:fc:1e)

The last four bytes of this MAC address, written in dotted decimal notation, is 10.1.252.30. I would look for the node with IP address

10.1.252.30 and see if it is using the same MAC address. Duplicate MAC addresses can caused a variety of problems.

NM

Reply to
News Me

we are having the exact same issue. been looking at it for (2) days now but can not seem to locate the problem.

snipped-for-privacy@cassidyweb.com wrote:

Reply to
scott

Thank you very much. One thing I tried to do (in desperation really) was to move all the ports except 1 (so management still worked) to a different VLAN. This mostly fixed the problem! -- except i was still getting a few conversations between machines with those 02.bf addresses. Those software, or locally administered, mac-addresses you point out are in some way related to MS NLB load balancing. I just found out that its legitamate traffic I need to support. There are some accounts of that software hosing switches (i understand microsoft themselves recommend using a hub instead of a switch for the load balanced ports).

Im also not sure why the switch acted more poorly on the default vlan than on the one i created though.

Thanks again.

Reply to
jere

During peak time - it was apparent that the switch was NOT acting more poorly the default vlan. An news group article as well as several microsoft knowledge base articles helped explain MS NLB and why its doing what it is doing. It affected even server-to-server communication - the traffic being spammed out was not just clients of the cluster.

For all those that find this thread searching for a similar problem that might be clustering/MS NLB related, a great resource for this info was

formatting link

Reply to
jere

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.