Many small-to-medium businesses still operate legacy 100Mb unmanaged switches (like the 3COM models mentioned) daisy-chained to a central gigabit switch. During my consulting work, I've measured up to 300ms latency spikes during peak hours in such configurations. The fundamental issue? Every inter-switch hop adds layer-2 processing latency and halves available bandwidth at each 100Mb link.

The attempted star topology collapse suggests either:
1. MAC address table overflow (common with older 3COM switches limited to 1K entries)
2. Broadcast storm from ARP/DHCP traffic saturation

// Diagnostic snippet to check for MAC flooding
tcpdump -i eth0 -nn -v port 67 or port 68 | head -100
// Look for repeating DHCP requests from unexpected hosts

Here's how I successfully migrated similar networks:

1. Segregate Server Traffic: Keep servers on the gigabit switch ONLY
2. Implement VLAN Hopping: Even unmanaged switches can benefit from physical separation:

   # Legacy switch port mapping example
   Gigabit Switch Ports 1-12: Servers
   Ports 13-16: Uplinks to 100Mb switches (1 per switch)
   Ports 17-24: Empty (future expansion)

3. Cable Verification: Always use TIA-568B standard on both ends for consistency

If budget allows, replacing just the gigabit switch with a managed model enables:
- STP (Spanning Tree Protocol) to prevent loops
- Port mirroring for traffic analysis
- QoS prioritization for critical services

// Sample managed switch config snippet
interface GigabitEthernet1/0/24
 switchport mode trunk
 switchport trunk allowed vlan 10,20
 spanning-tree portfast trunk

When dealing with multiple unmanaged switches, daisy-chaining creates a traffic bottleneck that compounds with each hop. In your current setup with four 100Mb switches connected in series:

Switch1 → Switch2 → Switch3 → Switch4 → GigabitSwitch(Servers)

Any traffic between Switch1 and servers must traverse three intermediate switches, each limited to 100Mb full-duplex. The effective bandwidth between endpoints becomes:

// Theoretical bandwidth calculation
const hops = 3;
const linkSpeed = 100; // Mbps
const effectiveBandwidth = linkSpeed / (hops + 1); 
// Result: 25Mbps theoretical maximum

Your attempted star topology should work in theory, but several technical factors could cause failure:

• Auto-MDI/MDIX negotiation failures between different switch models
• Broadcast storm detection falsely triggering
• Cable quality issues (Cat5e minimum required for gigabit)
• Switch port configuration mismatches (duplex/speed settings)

Use these commands to verify switch connections (Linux example):

# Check link negotiation
ethtool enp0s25

# Monitor network traffic
iftop -i enp0s25 -n -P

# Check for errors
cat /proc/net/dev | grep -i error

For your specific 3COM switches, try this physical sequence:

1. Power down all switches
2. Connect each 100Mb switch directly to gigabit switch using ports 1-4
3. Use known-good Cat5e/Cat6 cables
4. Power up gigabit switch first, wait 30 seconds
5. Power up remaining switches sequentially

If star topology persists failing, consider these options:

// Pseudocode for hybrid solution
if (starTopologyFails) {
    implementPartialMesh();
    enableQoS();
    monitorTraffic();
} else if (budgetAvailable) {
    replaceLegacySwitches();
    implementVLANs();
}

For temporary mitigation, you could implement a partial mesh with two connections between switches to reduce hop count while maintaining redundancy.

Expected latency improvements (measured in lab environment):