<lovesegfault>
the website just redirects to their github too
<andi->
lovesegfault: buy an mellanox SN2100
<andi->
as close as native linux software defined switch as you can get without broadcom blobs
<andi->
all you need is mainline linux and iproute2 / networkd
<andi->
if you want to go fancy you can do hardware offloaded tc flower rules etc..
<lovesegfault>
andi-: those look like they're SFP+?
<lovesegfault>
I need RJ45
<andi->
QSFP~
<andi->
QSFP+
<andi->
you can adapt that :D
<lovesegfault>
And I need more ports ideally
<lovesegfault>
context:
<lovesegfault>
We currently deploy a Juniper firewall, a Juniper Switch, and a supermicro management server. I want to get rid of the firewall, and have a single box be the mgmt server & switch
<andi->
sounds like the device you want
<andi->
aren't your servers 10G anyway and can't you upgrade them to proper NICs?
<andi->
I guess the video device are still legacy rj45?
* lovesegfault
ndos
<lovesegfault>
*nods
<andi->
anyway I think those are the best bang for the buck if you want a proper software stack.
<cransom>
i would just change the supermicro to do the routing and keep the juniper switch.
<lovesegfault>
ideally for small setups (~20 devices) we can just connect them straight to the mgmt server
<andi->
That also works if you already have all the installments and the power budget
<lovesegfault>
cransom: it's about deployment complexity, I want to get it down to a single physical box
<cransom>
20 ports is a large ask for a single platform.
<lovesegfault>
but I can't find that model on their website
<lovesegfault>
The nice thing about those supermicro ones is they have these PCIe-based cards that do PoE as well
<andi->
13 ports split across many nics..
<andi->
not sure how much fun that is going to be
<andi->
and switching is likely not in hardware on these for the most part. At least not across two nics.
* lovesegfault
nods
<lovesegfault>
I have no idea what the speed requirements are
<lovesegfault>
but the servers are cheap, apparently (~2k) so a misfire here isn't a tragedy
<lovesegfault>
my main constraint is w/e I come up with can't cost _too much_ more than the firewall/switch/server serup
<lovesegfault>
*setup
<andi->
you might want to have two devices. Or buy a bigger juniper
<lovesegfault>
I think part of the motivation is to stop using Juniper
<lovesegfault>
the hw team hates them
<cransom>
performance won't be awesome for switching, but depends on what you are actually doing with all of this.
<andi->
lovesegfault: those were the ex3300 right?
<cransom>
you could also pick a different switching vendor. i wouldn't discount any of the whiteboxes that run cumulus/something else just because it's not nix.
<lovesegfault>
cransom: bunch of cameras expose RTSP streams. We forward them to the cloud using some GCP thing I don't remember the name
<lovesegfault>
that's the gist of it
<lovesegfault>
Right, Nix isn't a requirement at all. If there's an easier non-nix solution I'm all for it
<cransom>
the use case doesn't sound all that complex. what does the hw team hate about juniper? if you know.
<lovesegfault>
I'm not sure, I think a complaint I've heard is that JuneOS can be a pain to deal with for them. There are things we'd like to easily expose to our SW, like PoE rebooting a device, that aren't super easy to do
<lovesegfault>
(according to them)
<lovesegfault>
s/JuneOS/Junos OS/
<cransom>
ah. i don't think they looked very hard if they haven't figured out how to bounce ports over an ssh session yet.
<lovesegfault>
They know how to do it over SSH, but when I asked them if I could provide them a static binary that would run on the switch and expose an HTTP endpoint so that the SW running on another server could hit it when needed they said "we don't know how"
<lovesegfault>
this was ~months ago
<cransom>
that part is harder, but why not let the management server run the http end point and then do the backend ssh bouncing?
<lovesegfault>
I'm not sure, I think they didn't want a service that would ssh into another box and do $stuff
<lovesegfault>
They're not always the most agreeable people as andi- knows :P
<cransom>
you can always frame it as 'speaking netconf protocol, just happens to be over an ssh socket. you like secure sockets, right?'
* lovesegfault
hires cransom as his company lawyer
<cransom>
but, i think unless you are strictly making money off of networking hardware, like being verizon or something, getting your own binary blobs on your juniper device is likely unworth it.
<lovesegfault>
Right
<lovesegfault>
I think I'm going to try chatting with Mellanox and see if they can build us something
<cransom>
how many deployments are you planning?
<lovesegfault>
I mean, we're a startup so who knows. The public number for this year is 100
<lovesegfault>
I think the goal for '22 will be some multiple of that
<cransom>
maybe you can get some rtx3090s on the side.
<lovesegfault>
we use T4's I think :D
<lovesegfault>
Well, whatever GCP has
<andi->
lovesegfault: i remember asking them while being in the SFO office if they considered using netconf instead of they manual scripting with ansible and imperative madness...
<andi->
they didn't
<cransom>
that's just madness. if you can template out an entire config and drive a box, and they didn't want to do that, i'm not sure how you could convince them that nixos is a good idea.
<cransom>
they can run puppet on their juniper too :) ah but not on an ex3300.
<andi->
yeah..
<andi->
I mean the hardware isn't bad for a PoE RJ45 switch if all you need is vlans + PoE and some management interface that isn't like cisco
<andi->
but they just didn't see the light. They did prefer manually switching all the config flags
<cransom>
condolences for a network team that would prefer to life in 1995