Alright, let's walk through how to tackle this replacement properly—since you're flying blind with no existing documentation or device passwords, we need a methodical, low-downtime approach that fixes the flaws of the current daisy-chained setup.

1. Pre-Recon: Map the Existing Network (No Device Access Needed) #

Before touching any hardware, get a clear picture of what you're working with:

• Physical topology audit: Walk the park, note every switch's location, label which ports connect to which tenants (quickly check in with tenants if you're unsure—most will know which wall jack is theirs), and document the internet entry point's link to the first switch (fiber? Cat6? Note the cable type for reference).
• Tenant bandwidth needs: Chat with each tenant to understand their usage—do they run video conferences, transfer large files, or just basic web traffic? This will help you allocate resources fairly in the new setup.
• Baseline internet speed: Grab a laptop, plug into a free port (or ask a tenant for 5 minutes of access), run speedtest-cli (for Linux/macOS) or a web-based speed test to get current down/up bandwidth—this is your benchmark for the new network.

2. Gain Control of Existing Switches (Reset or Recover) #

Since you have no passwords, two paths here—reset is usually the most efficient:

• Factory reset (preferred): Most small-business switches (Cisco SG, TP-Link, HPE OfficeConnect) have a physical reset button. Power off the switch, hold the reset button, power back on, and wait for the status lights to flash to confirm reset. Note: This wipes all configs, so schedule this during off-hours (weekend late nights) and warn tenants of brief downtime. Since the current setup is daisy-chained, it's almost certainly plain layer 2, so resetting won't break anything beyond temporary connectivity.
• Password recovery (only if you need old configs): Some enterprise switches have recovery workflows (e.g., Cisco ROMmon mode), but this requires model-specific steps and takes way more time. Since you have no docs, the old config is likely unreadable anyway—stick to resetting.

3. Design a Stable Replacement Topology #

The current daisy-chain is a disaster waiting to happen—single points of failure and bandwidth bottlenecks. Replace it with a core-access star topology:

• Core switch: Deploy a layer 3 core switch at the internet entry point. It should support VLANs, QoS, and bandwidth shaping. This will act as the central hub for all traffic.
• Access switches: Place access switches in each tenant zone, run dedicated links (fiber or Cat6) from each access switch directly to the core. No more daisy-chaining—this eliminates single points of failure and removes bandwidth bottlenecks.
• Tenant isolation: Assign a unique VLAN to each tenant. Configure the core switch to block inter-VLAN traffic (so tenants can't access each other's networks) and set per-VLAN bandwidth limits to prevent one tenant from hogging the entire internet pipe.
• Redundancy (if budget allows): For critical uptime, use two core switches in a stack/VRRP setup, and run dual links from each access switch to the core. This ensures a single link or switch failure won't take down the whole park.

4. Implementation: Minimize Downtime #

Roll out the new network in stages to avoid mass outages:

1. Pre-configure the core: Set up the core switch with internet routing, VLANs, QoS rules, and bandwidth limits during off-hours. Test internet connectivity from a test device plugged into the core to confirm it works.
2. Replace access switches one zone at a time:
   • Label every port on the old switch (which port goes to which tenant) before powering it down.
   • Swap in the new access switch, configure the correct VLANs for each port, plug back in the tenant cables, and verify the tenant's network works before moving on.
3. Remove daisy-chain links: Once all access switches are connected to the core, yank out the old daisy-chain cables—they're no longer needed.
4. Full park validation: Run speed tests for each tenant, verify inter-VLAN isolation (ping from one tenant's device to another—should fail), and confirm all services are working as expected.

5. Post-Replacement: Lock in Reliability #

Don't repeat the original setup's mistakes:

• Document everything: Create a topology diagram, save all switch configs, maintain a tenant-VLAN mapping table, and store all device passwords in an encrypted password manager.
• Schedule regular checks: Monthly, log into switches to check port status, bandwidth usage, and update firmware if needed.
• Establish tenant communication: Share a contact for network issues, and send advance notice before any planned maintenance.

内容的提问来源于stack exchange，提问作者Count Flannigan