A question that we get, especially when people who learn that we’ve done our own switch, is:
What network switch operating system do you run?
And it’s a bit of a long answer because in a traditional switch, which this is very much not, but in a traditional switch you have the switching silicon, and then you have this other microprocessor, often x86, often Intel x86. That microprocessor runs its own operating system.
We absolutely did not want that, for a bunch of reasons. One, if you’re familiar with Oxide, you know we’ve done all this work to have a true root of trust, to have true attestation of workloads. We didn’t wanna have some other random x86 part on there that we couldn’t attest to, that would be running an operating system that we didn’t control. That was not acceptable to us.
So what we did is we took a different model. This switch is actually connected via an external PCIE cable to an adjacent compute sled. And the compute element that controls the switch is not a computer on here, although there’s a traditional service processor. We have our service processor on here. But the actual compute element that drives the switch is sitting on that adjacent sled.
On that sled, what do we run for our network operating system? We run our own system. We run our own software there, so we’re not running SONiC, or you may see these other kind of available network switch operating systems. We’re not doing that. We’ve effectively done our own system, but that system is using all the same mechanism for the root of trust, service processor, attestation, and so on.
So you’re able to get the power of having our own switch without the peril of having software we don’t control.
Thanks, and see you next time.