Depending on your interests, intentions and experience, managed switches can be useful.

You generally don't want to give vintage stuff full internet access, but you might want to be able to communicate with new machines (so you can download stuff on them, unpack files and generally store stuff). That screams 'VLANs', and for VLANs you need managed switches (and a router that understands them).

Basically the idea would be to have at least two VLANs in your network, one for the vintage stuff without internet access, one for new machines. You would then make a trunk (connection with all VLANs on it in tagged form) between router and switch(es) and then assign remaining ports to one VLAN or the other (untagged), so your clients (new or old) don't have to be aware or support anything related to VLANs but you can assign each to the correct one. Then you need to configure IP scopes for both in you router, and assign some ACL/routing rules (like: "allow vintage VLAN traffic to/from regular VLAN, deny vintage VLAN traffic to/from internet")

While none of this is wrong, this is such an overkill. The simplest way to address you scenario dionb is as said before, just set the default gateway on your retro machines to their own IP address and you're done...they can reach all your local resources (in a single VLAN obviously), but can't escape that VLAN, so no internet. And setting the gateway to own IP is a documented feature and best practice, that will immediately timeout with no delay whatsoever, compared to for example a different bogus IP address.

I'm all for people to teach themselves more networking, but to start properly with these requirements this is literally a 10 dollars, 10 minutes solution:

- ISP router is DHCP+DNS
- Connect ISP router to flat switch (managed or not does not matter)
- Connect all your other network resources to the same switch
- On machines you don't want on internet, set their default gateway to their own IP.

And you're done. All devices will be able to talk on the local network, and machines you've set with the fixed gateway to themselves will be stuck in local network.

Boohyaka wrote on 2023-04-23, 12:32:

While none of this is wrong, this is such an overkill. The simplest way to address you scenario dionb is as said before, just se […]
Show full quote

While none of this is wrong, this is such an overkill. The simplest way to address you scenario dionb is as said before, just set the default gateway on your retro machines to their own IP address and you're done...they can reach all your local resources (in a single VLAN obviously), but can't escape that VLAN, so no internet. And setting the gateway to own IP is a documented feature and best practice, that will immediately timeout with no delay whatsoever, compared to for example a different bogus IP address.

I'm all for people to teach themselves more networking, but to start properly with these requirements this is literally a 10 dollars, 10 minutes solution:

- ISP router is DHCP+DNS
- Connect ISP router to flat switch (managed or not does not matter)
- Connect all your other network resources to the same switch
- On machines you don't want on internet, set their default gateway to their own IP.

And you're done. All devices will be able to talk on the local network, and machines you've set with the fixed gateway to themselves will be stuck in local network.

Very nice answer, I totally agree.
As a last step if you really want to maximize separation, connect all retro machines and resources to their own switch to limit internal traffic/bandwidth to it and that switch to the router (or main switch if you have one)

Boohyaka wrote on 2023-04-23, 12:32:

While none of this is wrong, this is such an overkill. The simplest way to address you scenario dionb is as said before, just se […]
Show full quote

While none of this is wrong, this is such an overkill. The simplest way to address you scenario dionb is as said before, just set the default gateway on your retro machines to their own IP address and you're done...they can reach all your local resources (in a single VLAN obviously), but can't escape that VLAN, so no internet. And setting the gateway to own IP is a documented feature and best practice, that will immediately timeout with no delay whatsoever, compared to for example a different bogus IP address.

I'm all for people to teach themselves more networking, but to start properly with these requirements this is literally a 10 dollars, 10 minutes solution:

- ISP router is DHCP+DNS
- Connect ISP router to flat switch (managed or not does not matter)
- Connect all your other network resources to the same switch
- On machines you don't want on internet, set their default gateway to their own IP.

And you're done. All devices will be able to talk on the local network, and machines you've set with the fixed gateway to themselves will be stuck in local network.

If one is manually adding gateways, the purpose of DHCP is offset, so why bother with it? If he had 100 machines, maybe, but I'd go with reservations, instead.

In keeping with simplification theme:

If only a handful of machines are used (and if only a 5-port switch is used, only a handful of machines are being used), skip DHCP; it's unnecessary. You wouldn't use it for Printers, Servers, Storage, or anything else which is not a client, anyway (an argument could be made for printers with reservations, but I digress).

Since the dawn of TCP/IP you can set DHCP and still manually set DNS and/or Gateway manually. I assume he has less retro machines that modern devices (including kids/wife/relatives/visitors iphones/tablets/computers/consoles/IoT devices or whatever), so DHCP is perfect for all of the modern use. Now adding a few retro machines in the mix, manually setting their gateway is a pretty manageable 10 seconds per machine. In the big picture, it's absolutely peanuts time.

If only a handful of machines are used (and if only a 5-port switch is used, only a handful of machines are being used), skip DHCP; it's unnecessary.

I wholeheartedly, completely disagree with this sentiment. It would actually be the opposite: unless you're in a corporate environment with an on-prem infrastructure, never bother with static IP, you're just making your life more complicated. As you mention it, even in a corporate environment, current best practices tend to have only core network + servers as static to insure flawless accessibility even if DHCP service is down, and literally everything else (including distribution and access switches, AP's, printers, you name it) as DHCP reservations, which gives you massive management QoL. But now I digress, that's another topic.

Boohyaka wrote on 2023-04-23, 15:49:

Since the dawn of TCP/IP you can set DHCP and still manually set DNS and/or Gateway manually. I assume he has less retro machines that modern devices (including kids/wife/relatives/visitors iphones/tablets/computers/consoles/IoT devices or whatever), so DHCP is perfect for all of the modern use. Now adding a few retro machines in the mix, manually setting their gateway is a pretty manageable 10 seconds per machine. In the big picture, it's absolutely peanuts time.

If only a handful of machines are used (and if only a 5-port switch is used, only a handful of machines are being used), skip DHCP; it's unnecessary.

I wholeheartedly, completely disagree with this sentiment. It would actually be the opposite: unless you're in a corporate environment with an on-prem infrastructure, never bother with static IP, you're just making your life more complicated. As you mention it, even in a corporate environment, current best practices tend to have only core network + servers as static to insure flawless accessibility even if DHCP service is down, and literally everything else (including distribution and access switches, AP's, printers, you name it) as DHCP reservations, which gives you massive management QoL. But now I digress, that's another topic.

If he's trying to setup a network for the home mixed with retro, OK - my understanding. I would never allow such a thing on my network(s). I am fully aware of manually adding settings to offset DHCP, but again - If you're physically at the machine, why not set the whole thing and be done. Consistency is the name of the game for me, but different strokes.

Switches and APs with DHCP? I will see your wholeheartedly disagreement and raise my disagreement to vehemently 😁, but I'm sure we could come to some kind of compromise on an effective network infrastructure. 😀

Don't know what trade you're in, but on my end this is literally 1st hand account of what's currently happening in the corporate world 😀 static IP's are only used for core switches, routers and hypervisors, literally everything else is DHCP reservation. You just need a very robust and redundant DHCP infrastructure and decently long lease times. You're vulnerable to a rogue DHCP, but if you have proper NAC this is a non-issue, and if you don't that shouldn't be too hard or too long to figure out. This makes things so easy to manage as your whole network map (minus the few static IP's obviously) is centrally documented by design. And it makes all kind of IP changes easy as pie, it enables all benefits of DHCP options, and you never have to wonder if your device is wrongly configured and never afraid of IP conflicts.

Boohyaka wrote on 2023-04-23, 16:57:

Don't know what trade you're in, but on my end this is literally 1st hand account of what's currently happening in the corporate world 😀 static IP's are only used for core switches, routers and hypervisors, literally everything else is DHCP reservation. You just need a very robust and redundant DHCP infrastructure and decently long lease times. You're vulnerable to a rogue DHCP, but if you have proper NAC this is a non-issue, and if you don't that shouldn't be too hard or too long to figure out. This makes things so easy to manage as your whole network map (minus the few static IP's obviously) is centrally documented by design. And it makes all kind of IP changes easy as pie, it enables all benefits of DHCP options, and you never have to wonder if your device is wrongly configured and never afraid of IP conflicts.

My accounts are also of firsthand.

I don't think it's helpful to continue this discussion for the original poster. I'm sure the right solution will be found from all of the numerous ideas presented.

I would actually start with the router first.
If you have a old router with 4 ports you are kind of getting a basic managed switch of sorts anyway.
If you leave the router unconfigured it'll behave exactly the same as a 4 port switch.
And if you have ever logged into a router and seen the DHCP setup section you know what to expect when you want to configure this on your retro network.

When it comes to buying a switch you would definitely want a unmanaged one. You would simply plug a network cable from the router to the switch and DHCP would continue to work over both devices.

Or as others have said some managed switches include a DHCP server which means you don't need ever to worry about the router. Just check the manual first as I cant see any proof that the TP-Link TL-SG105E in your list has a DHCP server -about the only part of the "managed" that you'll actually need 🙁

Personally I'd just get a cheap 2nd hand 8 port switch (as these are more common then 5 port) My retro network is still using 10/100 as I'm too cheap to upgrade the switch but for retro stuff its enough IMHO and makes any of the issues dionb a non issue.

I don't have a spare router; only the one provided by the ISP, and I don't want to use that for a variety of reasons including security and locked firmware. That's why I thought of getting a switch now, and if needed I can get a router later on.

I know how to configure a static IP in most OSes, including a default gateway, and as was mentioned it takes little time and I currently have only 3 devices that will be connected to this switch, so not a big deal. And I don't plan to add more devices for a long time.

I decided to go with the TP-Link TL-SG105E and see how that goes. I'll try its default configuration and ask for help if something's not right.
If it happens to be crap, I'll see about returning it and give the Cisco a try.

Thank you everyone! I don't feel as lost now 😀

Rest assured that the TP-Link can handle 3 old machines and you definitely don't need a Cisco for that. Enjoy tinkering with it!

cyclone3d wrote on 2023-04-21, 19:37:

Netgear GS105N or GS108N (5 and 8 port respectively).

I have deployed dozens upon dozens of these switches over the past decade or so and have only ever had 2-3 develop issues.

Same here. The GS series were the first reasonably priced compact Gbit switches that didn't generate lots of heat I found. Bought a bunch of them 15 years or so ago, installed them in my home network, and forgot about them. They're still working perfectly, never gave me any trouble whatsoever.

pool7 wrote on 2023-04-25, 00:50:

I don't have a spare router; only the one provided by the ISP, and I don't want to use that for a variety of reasons including s […]
Show full quote

I don't have a spare router; only the one provided by the ISP, and I don't want to use that for a variety of reasons including security and locked firmware. That's why I thought of getting a switch now, and if needed I can get a router later on.

I know how to configure a static IP in most OSes, including a default gateway, and as was mentioned it takes little time and I currently have only 3 devices that will be connected to this switch, so not a big deal. And I don't plan to add more devices for a long time.

I decided to go with the TP-Link TL-SG105E and see how that goes. I'll try its default configuration and ask for help if something's not right.
If it happens to be crap, I'll see about returning it and give the Cisco a try.

Thank you everyone! I don't feel as lost now 😀

The TP-Link TL-SG10*E switches are very similar to the Netgear GS switches discussed above. Installed a few of them at work a couple of years ago. With the reservation that someone else might have handled possible trouble - working at sea, not onboard all the time - I've never noticed anything negative about them. They seem to "just work" too.

One thing to bear in mind with TP-Link is that they keep using the same model numbers for extreme lengths of time, despite fundamentally changing the hardware multiple times. The SG10*E switches are a case in point. Currently the SG108E is in its 10th (!) hardware revision (v6.6, just to confuse). Basic Gigabit Ethernet switching has of course been a common feature, but over the years decent multicast (IGMP snooping) and IEEE1905.1 (mesh support) have been added, and VLAN and QoS options have been expanded considerably. Problem is, I have no idea exactly what was added when. So I can recommend the current model, but not mixing and matching 2nd hand units from different revisions.