Does anyone know why I must reset my network switches every so often to enable data traffic to move? This problem started recently after months of trouble-free operation.

Please don't bury me in "drop wire, use wifi" comments and suggestions. Wifi is great, but much slower than giga-bit wire for interactions internal to the home-office. It also offers better streaming from the gateway-DVR to the various set-top-boxes.

We usually learn that we have a problem because the set-top-boxes refuse to connect with the gateway. Power-on causes a DHCP request that times out when the switches are not working. Since the gateway also delivers wifi, laptops, tablets and phones typically don't notice the outage because they avoid the switches.

My house is pre-wired with CAT-6 everywhere. The distribution center uses Netgear GS-108E giga-bit switches. These are so-called "managed" switches. I have to reset these to get traffic flow to wake up. They operate as factory default so I'm not using any of the "managed" features because it requires admin software that only runs on win-dose. (Also, I don't understand many of the config options so I leave them alone.)

The from-house switches connect to another giga-bit switch near the ISP Motorola gateway. This switch provides wire-net to various entertainment components, the set-top-box, and an all-in-one printer.
This switch keeps working and does not need reset.

The network serves as internet for my small-home-office and family. The data network offers file and print services for win-dose, Mac and Linux workstations or laptops as well as iPad, iPhone along with Android tablets and phones. In addition, it distributes AT&T UVerse video through the home.

Thanks in advance,
~~~ 0;-Dan

Sounds like your switch is simply broken and needs to be replaced. I've seen a few D-Link switches die over the last 2-3 years, and the symptoms matched what you're describing.

A working switch should never have to be reset or power-cycled.
You may be missing out on Spanning-Tree and IGMP snooping, but as long as there are no loops in your network and you're not using IPv4 multicasts (which I'm pretty sure you're not), an unconfigured switch should work just fine.

Note: I've never come across a switch that required Windows-only software for management. On D-Link, Asus and Linksys switches, the Windows software is only used to change the default IP address of the switch.

I agree with Ser Olmy, it sounds like the switch is borked. Basic consumer-level gigabit switches tend to last about 3-5 years in my experience before they either fail altogether or start dropping ports or causing other problems.

The Netgear® GS108E(echo) switch is managed but does not have a built-in web, telnet, SSH or similar administrative interface. As a result, you need their "setup utility" which is win-dose only.

It's cousin, the GS108T(tango) has a web-page interface.

(blush,grin) This likely explains why I found the 108E switches at a clearance price.

Cheers,
~~~ 0;-Dan

I have tested each of the ports on the bench between two laptops. I could never get any one port to stop talking to any one other port. Of course I couldn't drive all of the ports at once.

Also, My switches are connected to surge protected power, but the CAT6 runs without any protections. Wire runs make good antennae for RFI/EMI and other pulse energy surges (motors, lightning, etc). I'd expect that sort of failure to be hard and not affected by factory-default reset.

Thanks,
~~~ 0;-Dan

I'm still learning about "managed switches" -- because I own them not because I need them -- so can someone tell me this?

Let to factory-defaults, will these switches learn about the traffic and make decisions that somehow close off paths? The factory-default reset would then clear those decisions ... until next time.

Curiously frustrated,
~~~ 0;-/ Dan

Corrections are highlighted.

Follow-up:
The network is a simple tree:

Code:

GW --> {all things wifi}
   --> SWx -+->  SWy --> {house part A} --> STB-2
           -+->  SWz --> {house part B} --> server
           -+->  printer
           -+->  DVR-STB
(Key:  GW=gateway, SW=switch, STB=set-top-box)

The tell-tale failure involves STB-2 loss of connection to the mothership.
The server cannot communicate with house part B workstations.
At the same time, wifi users lose connections to the server but keep connections with the printer. STB-1 continues to operate correctly.
Reset-to-factory for SWy and SWz clears all troubles.

I've exchanged SWy with SWz without any change in failure symptom.

I've replaced SWx without problem resolution.

That's how all switches/bridges work.

When you power them up, they know nothing about the network and will forward a frame received on one port to all other ports. However, each time it does this, it makes a note of the source MAC address of the frame, and creates an entry in its MAC address table, associating the address with the port the frame was received on.

As traffic flows, the switch will eventually know which MAC addresses can be reached via each port, and will forward frames only to the relevant port. The only frames that get "flooded" to every port are broadcast frames and frames with an unknown destination MAC address.
You're basically saying that both SWy and SWz appear to stop forwarding frames at the exact same time. That's beyond strange, but there are several possible explanations:

1. A firmware bug on SWy and SWz (assuming these switches are the same make/model) could cause a lock-up under certain circumstances (seeing a certain multicast MAC address, a counter overflowing, etc), requiring a reset/power cycling of the switches.
2. a firmware bug on SWx may cause it to stop forwarding frames to SWy and SWy under certain circumstances, requiring the ports to be reset (which happens when you cycle the power on SWy and SWz).
3. A broken NIC may be generating invalid frames, causing one or more switches or ports to enter blocking mode (I'd still call that a firmware bug in a switch)

Next time it happens, try this:

• Rather than power cycling SWy and SWz, try momentarily unplugging the cables connecting these switches to SWx.
• See if two hosts connected to SWy/SWz can still communicate when intra-switch communication is lost.
• If the above does not work, try power-cycling only one of the switches. For instance, according to your diagram, there's no way a locked-up SWz should be able to stop STB-2 from communicating with STB-1. If SWy is the problem, power-cycling that switch alone should resolve the issue.
• Try power-cycling SWx instead of SWy and SWz.

And by all means give your managed switches some IP addresses, so that you can read the logs and see uptime and interface statistics. That may be all you need to figure out what's really going on here.

1 members found this post helpful.

I've done this. Part of my quandry lies with my poor understanding of what any of the output detail means and what it implies that I need to do in response.

Another part of the quandry lies with the GS108E(echo) requirement of a win-dose-based application to connect with the switches. The cousin switch, GS108T(tango), has a web-page interface. I'll upgrade as the check-book permits.

ASIDE -- I'm having troubles finding detailed reading about how a managed switch works internally and how each of the available parameters might be used to steer network operation and performance. I welcome any suggested readings my LQ colleagues might offer.

NOTE -- I would love to find good, detailed readings about how switches, managed and otherwise, work within a twisted-pair LAN.
It follows from this description that:

• power-cycle -- clear tables of network and traffic knowledge but remember current IP address, node name and similar settings
• reset -- forget everything and restore factory-default IP etc.

I clearly want to power-cycle.
I expect to see:

• STB <==> GW "video" and "entertainment" traffic
• in-house-node <==> GW "internet" traffic of all sorts dependent on the nature of "node" (server, phone, desktop, etc)
• in-house-node <==> in-house-node data traffic of all sorts dependent on the nature of "node" (server, phone, desktop, etc)

Can you foresee anything about this sort of traffic that might result in the switches deciding to close things off or otherwise partition the LAN?
To be clear, it is the trio: SWx--SWy--SWz that "stop talking" while SWx and continues to talk with GW, and GWwire and GWwifi continues to talk with the internet.
How would a NIC problem show itself while looking at log reports? Would there be high "error" counts or similar?

• What is the goal? Do I want to stop SWy and SWz from talking with each other? talking with SWx, itself? other?
  
  Quote:

  Originally Posted by Ser Olmy See if two hosts connected to SWy/SWz can still communicate when intra-switch communication is lost.

  To clarify, "Can {host-on-SWy} communicate with {host-on-SWz}?"
  
  Quote:

  Originally Posted by Ser Olmy If the above does not work, try power-cycling only one of the switches. For instance, according to your diagram, there's no way a locked-up SWz should be able to stop STB-2 from communicating with STB-1. If SWy is the problem, power-cycling that switch alone should resolve the issue. Try power-cycling SWx instead of SWy and SWz.

To clarify, a set-top-box as STB-1, -2, etc usually will only talk with the in-house DVR (which is also a set-top-box) and the GW for video distribution. All wifi interaction with a set-top-box starts at the GW which is also the LAN access point. If one uses the "interactive" features of a set-top-box, I believe these are traditional web services like NetFlix™ or similar and the STB is then just like any other host on the LAN.

OOPS!! I just realized that STB-1, in my diagram, is the DVR-box.
The DVR-box supplies recording services to the entire LAN as well as serves as a STB in its on right.

Regards,
~~~ 0;-Dan

I just spent some time clicking on every link in the first three pages of search results returned by the Google search "how does an ethernet switch work". It was slightly depressing, as the explanations were either:

• way too short and simplistic ("they connect multiple PCs" - thanks, Cisco)
• somewhat confusing (typically mixing unrelated terms like switching and routing)
• ridiculously complex (going into details about what the ASICs inside a switch does)

For instance, this document does a good job of explaining how a switch differs from the older hubs, but doesn't really explain the switching process. This article has a bit more detail, but not a lot. At the other extreme we find the Wikipedia article on network switches, which assumes you're already intimately familiar with the OSI model and various network technologies.

One of the better explanations I've seen is in the Cisco CCNA/ICND1 book by Wendell Odom. Switches are really quite simple beasts, and explaining how they work shouldn't require a 10000-word article. If I ever come across a really good web page explaining Ethernet switching, I'll let you know.
No. Under absolutely no circumstances should a switch stop forwarding frames unless the actual topology of the network has changed.

I'm trying to get to the bottom of exactly where the communication stops. One switch cannot affect the forwarding decisions of another switch, so it stands to reason that the problem must be related to either a specific switch or a specific link.

If either SWy or SWz (or both) have ceased functioning, no ports on those switches will work and two hosts connected to the same switch (either SWy or SWz) should not be able to communicate. If on the other hand the problem is related to a link between two switches, traffic between ports on the same switch will still flow.

Exactly.

Unplugging a cable causes the link on the ports to go down, and the switch (or both switches for an uplink between two switches) will remove all entries in the MAC address table related to that port. Also, if the link is unstable, unplugging and reconnecting the cable will force a renegotiation of the link.

Your setup is really quite straightforward. The puzzling part is that equipment connected to two separate switches seem to drop off the network simultaneously. That would be understandable if the switches were daisy-chained, as equipment at the end would depend on the middle switch, but your topology is a star with SWx in the middle.

Either there's something about SWy and SWz that causes them to fail at the exact same time, or the problem is related to SWx.

1 members found this post helpful.

As a business and technical writer, I see an opportunity for publication -- articles, eBook(s), etc. However, the CATCH-22 that is a serious weakness of the open-source world, lies in finding subject expertise and knowledge to use as the base of one's writings. (blush) If it were easy, I guess they would use some word other than "work."

Thanks for the dialog,
~~~ 0;-Dan