I am entertaining the idea of overhauling my network setup a bit. I want to move my main router (OpenWRT 192.168.111.1) from the basement to the first floor. But keep the cable modem (Arris SB6120 192.168.100.1) and the switch (Zyxel gs1900-16 - to be provisioned) in the basement. There's already a cable between the basement and 1st floor locations.
Currently the modem is connected to the WAN on the router (standard setup). But the above would necessitate the following wiring:
router --[VLAN trunk] -- switch -- modem
A few devices are connected to the switch - computers, APs.
(1) Can that work at all? Is it advisable to wire things like that?
(2) Will there be any perceivable performance degradation, and how much? Bytes will be going through the switch twice now to "get out", right? And by "how much" I mean in the ballpark of 50% or more.
Advisable -- that's a different story and you may get a few differing opinions. Personally, I think it is fine as long as the Zyxel switch is either running OpenWrt or has a good vendor fimrware implementation. More on that in a minute.
Maybe... it depends.
You didn't mention your router and your current ISP speed, and you didn't describe if you have VLANs and any significant inter-VLAN routing.
I think at worst you'd be capped to 1Gbps total throughput (up+down, instantaneously measured).
Regarding the Zyxel switch... two risks come to mind:
Does it allow you to specify the management VLAN? Some low end managed switches (like the TP-Link TL-SG1xxE series and the equivalent from Netgear) do not, and they could possibly end up claiming your DHCP lease from the cable modem. Partial solution is to use a static IP for the switch, but it would still potentially be vulnerable to attack from the internet (although unlikely given that your management VLAN would put it on an RFC1918 address which is not routable on the public internet.
Does the bootloader keep the switch ports disabled until the main firmware fully loads and brings up the ports? The issue here is that some bootloaders may bring up all ports in a unmanaged/bridged configuration during early boot. If it does this, it will - temporarily - connect the cable modem to the lan side of your network. Although this is a short timeframe, another device that requests a DHCP lease could snag it from the cable modem, which would then refuse to issue the IP to your router once everything was finished booting. And for that super brief period, whatever device could grab the DHCP lease would also be completely unprotected and connected to the internet without any router/firewall in front of it.
IIRC, the Zyxel devices are much better than the lowest end TP-Link and Netgear switches, so the above are probably not a high risk here. But it will be critical to confirm that these things won't be an issue for both functional and security reasons.
I had such a setup for quite a while until I finally pulled a second cable. The reason is simple: If the Arris crashes (mine crashes about once a week), OpenWrt has no reliable way to determine that the link is down. Since the DHCP lease by my ISP is several days long, it takes a considerable amount of time until OpenWrt would request a new IP.
@andyboeh,
Very good points. No substitute for experience - thank you. I have not experienced crashes or other issues with my Arris. My ISP drops the connection once in a while for a few seconds.
I am capped all right. I pay for the 0.1Gbps tier. Feel free to enjoy a hearty laugh...
Main router is Asus RT-AC68U on OpenWRT.
I have VLANs - two. No significant inter-VLAN traffic.
The documentation does mention ability to set a Management VLAN. I have to read what that is. Is it a standard? Or some popular VLAN setup by convention?
I normally have static IPs on network devices.
Don't know about the ports' state during boot. Nothing in the doc. Will try to contact support and ask, or test on the switch after it comes. And I have to figure out how to test it. Hook to the serial?...
The management VLAN setting on the switch will ensure that the switch's admin interfaces will only listen and respond to requests that are coming from hosts on that VLAN. You'll also set an address on that VLAN's subnet (or set it for DHCP, in which case it will request a lease on that VLAN only).
Usually, the default for managed switches has the management network on VLAN 1 (and all ports are untagged VLAN 1, no other VLANs configured by default). You'll be able to configure all of this once you're in the admin interface of the switch.
IMO, the best way to test this would be:
configure two ports on different VLANs (say VLAN IDs 10 and 20, respectively, untagged + PVID).
Connect a computer to each of these ports
Set static IP addresses on both computers in the same subnet (say 10.0.10.1 and 10.0.10.2, respectively, both using subnet mask 255.255.255.0 (or /24).
Setup a persistent ping from one to the other (optionally do the other direction, too)
reboot the switch.
If any pings ever get through, the bootloader may indeed be bringing up all ports as unmanaged before the VLAN configuration is loaded, and therefore may be risky to use with a wan connection.
(1) Yes, there's a way to set a Management VLAN ID.
(2) Ran the ping test. Had to coerce the machines to stay on the interface and keep pinging. They wanted to switch to another interface when the link/power shut down.
I ran the ping test a few times, and neither machine could ping the other. Looks good. The LEDs for the connected ports come on quite some time (minute maybe) after the switch is turned on, and the SYS LED stops blinking. It matches with your idea of the ports being disabled until firmware boots completely.
The funny thing is the two machines reacted differently when the ports were off:
Linux Mint 20: ping: sendmsg: Network is unreachable
Linux Mint 21: Hangs, no output.
You can easily flash it with OpenWrt, the GS1900 series is one of the best supported switch series. A few features do not work (like LAG, IIRC), but it's more than sufficient for daily use.
Thank you for that reference. Hmm... Should I take that and create a device page in the wiki? Add additional info I gather along the way? It's obscured being in a git commit message.
As a general rule, the commit messages are the safest option. There is a techdata page for the device that links to the git commit - this is how I found it.
