I have made several switches on old PCs and they could all outperform Cisco and Ubiquiti enterprise grade switches, even when they also ran as a transparent firewall with STP failover.
That’s your subjective and erroneous opinion. If you were right, enterprises would just use cheap PC’s instead of investing in multi-thousand-dollar core network equipment.
2 Likes
You did not understand my posts at all.
You still think this is about equal price of the gear.
It is exactly not!!!
If you take your PC and compare it with your switch then your PC will win, but your PC will most likely also be ,maybe even several, times more expensive.
Both parts is readily available to you though.
Your switch does not need the power of a fast computer CPU, so it is scaled down to something that can just manage to do the job and thereby reducing costs, both in production (=sales price) and in TCO (less wasted electricity and so on).
If a company need a switch then they would most likely buy a dedicated switch, due to cost of purchasing it and the running costs.
In the case here there is a PC available with the possibility to work as a switch, so the cost to purchase is not there on the PC ,but it will be on the switch.
The switches, firewalls and routers I have made with old PCs have done the job on proof of concept setup with load testing and maybe an initial live running, but the TCO with power usage, missing integration in our current monitoring software, firmware/software management and so on just makes it too complicated to stay on that solution.
It might be that home-brewed setups were scrapped for production usage, but sometimes with got what was essential normal PCs anyway, like load balancers with switches built-in. The difference was that the providers of those load balancers were providing the firmware and making sure that it integrated into the rest of our production setup.
As a former Cisco employee, I can definitely say that the engineers who design the switches would all agree that fabric throughput is everything.
They’re so obsessive about it that their marketing team would get frustrated and beg them for other performance metrics to share with customers, lol.
Anyway, I think that if OP solves their layer 2 issue, there will be no need to muck around with layer 3 inside haOS in an unmaintainable way.
1 Like
Clearly about any PC that you could put together will get the job of a switch done. Where you go wrong is in saying that a PC will do switching faster that a switch itself. If you put qualifiers around that, sure, everything is possible. But you have have been presenting it as a general statement of fact, and as such, it couldn’t be more wrong.
1 Like
Yeah, Cisco emphasizes capabilities to process in dedicated hardware and recommends using software-based functionalities as little as practically possible.
True, but it is cost/performance they try to optimize.
No need to use a formula one car for pizza delivery, when a Ford Escort might do it well enough.
In this case the OP have scrapped the Ford Escort already and bought a the formula one car.
And throughput is usually the one parameter that counts, but with 40K+ devices online simultaneous then other factors become more important, like size of arp tables and handling of those.
You’re confusing yourself. OP isn’t talking about a switch, he’s talking about a pc with direct connections to devices. The devices will not be communicating with one another through the pc. Arp whois? That will be stored in the local Arp table, there won’t be any Arp broadcasts.
As to @cornellrwilliams - I LITERALLY said it would work if you modify the route table to reflect that - very magnanimous of you to simply snip that line from your quoting me, and pretend to introduce “new” information that contradicts me, when I already said that. Lol thanks.
I declare shenanigans. Unposaible. You have done no such thing. I don’t care what you did to a pc, there is no way you built anything in your basement that outperforms even a 65xx with a sup720 and fabric-enabled line cards - and that gear is dated!
For something a little more modern, you can’t build something in your basement out of spare parts that would perform even remotely as well as something like a 93180YC. Nevermind if we start getting into more specialized gear like UCS fabric interconnects.
2 Likes
I think I’ve found part of the problem with your argument.
The above is no more real than Santa Claus or the Easter bunny, and anyone who tells you different is trying to sell you something - literally.
1 Like
I created that “mess” in the screendump intentionally on a VM instance at home. Just to show how little HAOS cares about it’s configuration. Normally even a single duplicate IP will cause havoc. Not here. Everything keeps working, no complains 
. Routing each camera to its own network appeared in my mind for a second or two. The point is a classic chicken and egg problem: I cannot reconfigure the camera’s as I cannot reach them. (And I cannot ask the current user of the vehicle to unscrew the tamper proof camera’s to factory reset them.)
BTW, this mini PC in same size as two stacked standard 8 port home switches. And with a I5 cpu not anything like a formula one vehicle. (it won’t stand the heat of any more power without a fan). As I said, this is alle due to space availability (better: lack of it)…
Yes, you can absolutely communicate with them to reconfigure them… Come on now…
Please explain @exx,
If you know a way, please tell me. You might have found an answer for my ‘problem’.
I know if i’m locally present at my HA I can put each camera in the working lan port and reconfigure. But that means I have to travel half the continent to Portugal (living in Holland).
Depending on what IPs the cameras and gateway have you might be able to cheat a bit and play with the subnet mask and routing table.
I do actually not know if you can configure the routing table manually on HAOS, but if not then the sequence in which you set up the networks might do the trick.
It can be a bit risky if though, because one wrong move and the internet gateway might be inaccessible from HA. A Lille failsafe mechanism to this problem could be an automation that resets the network setup to a known good configuration.
OP was talking about a virtual switch.
It seems the issue is that each camera is already configured to a 192.168.1.x network and the gateway also.
On top of that the administration have to be done remotely.
And with an broadcast storm based on a looping arp whois it is actually not the arp whois request that is the issue. It will just be that single arp whois that goes around and around and around. The storm actually occur when the reply occurs, because each time it goes around it will get another reply that goes around and around and around.
And yes storm control on manageable switches will stop this with ease, but unmanageable ones will generally not.
The question is how HAOS or proxmox or many of the other software switches are configured.
No, he’s not talking about a virtual switch. I’m aware what he titled this thread as, and what he thinks he needs, but if you haven’t figured out yet what the technical aspects are of what he is actually trying to do, then you’re just a troll - and one who likes to spout nonsense, to boot.
You really should quit while you’re ahead.
That is exactly how.
The fact that you are half a continent away has no relevance to the technical solution, it is simply an inconvenience.
I agree, it ís an inconveance. It will be for about 3 month before they are back and in the mean time those camera’s are not working. As I said, I will use a switch when they are back. It is not a matter of life or death!
I started this thread because I thought there should be a way to fix this remotely. I’m just frustrated that a PC with that may RJ45 slots is not able to get them all in the one network. That’s all. And I am gratefull for all the reply’s and sugestions I got. Learned a lot. Most important lesson was “don’t assume anything in hardwareland” (which I did when I bougth this pc in a hurry to replace an Rpi and a switch
Thank again!
To clearify this: That example using the virtual switch was on a VM at home to show you HAOS’es behavior. I tell you, on the real PC with all it’s Nic’s it behaved exactly the same. No packet storm that congested my lan or drove the CPU to 100%.
Maybe I’ll examine this one later on, when it is safe to do so.
I knew there wouldn’t be any packet storm or other nonsense, that was that other guy.
I am surprised you were able to assign the same ip to all the nics, but honestly, nobody who knows about networking would ever attempt that, so maybe the developers just never thought to include a check for that since it never occurred to them that someone who do that? Lol
I did think of a way you could remotely get at all the cameras - but it’s still predicated on you having the correct cables, again, assuming the nics are not auto mdi/mdix. And it sounds like replacing cables is also a bridge too far, so…