Join us as we gather around the hedge,
where we dig into technology, business, and culture
with the finest minds in computer networking.
Well, hello, Audrey.
Audrey joins us today from Austin, Texas.
Yeah. Audrey says hi. Audrey's the plant.
I actually Hey, Walter.
I I listened to,
a few days ago just to get oriented
to your,
your show and heard you talking about Audrey.
Okay. First came up talking about Little Shop
of Horrors or what's the name of that
plant? And I was, it's Audrey. It's Audrey.
Yes. Well, there you go.
Alright.
So
and that other voice you hear in the
background, how are you doing, Tom, before I
do that? I'm great, Russ. You're great. Awesome.
And that other voice you hear in the
background, you probably recognize it.
I probably don't need to even say,
it's Jeff Doyle.
Jeff is guys.
Jeff is so well known. He needs no
introduction.
Is that the way is that the way
it works? I'm not sure. I'm not sure
whether that's
how true that is, but,
it's it's really nice to actually be a
guest.
Russ, you've been the guest on our podcast.
Mine and Jeff Tensor is, between two nerds
podcast so many times
that,
it's it might be a little disoriented
to me because I'm used to asking you
questions and they just shut it out, shutting
up and letting you talk. So,
you know, you'll you'll have to kinda pull
me back into where I'm what I'm supposed
to be doing if if I start asking
you questions. And Oh, that's it's okay. That's
okay. Just ask just ask Tom and Audrey.
There you go. Tom.
Yes. Tom.
Audrey has Audrey has the answers here. Audrey
has the answers here. Alright. So today, we're
talking about Sonic. So maybe we start with
an introduction of what Sonic is. I'll start
by saying, it's not new. This is really,
really old.
I mean, I don't say in the IT
world. I mean, I've been around Sonic since
LinkedIn
or before LinkedIn, and I don't actually
remember what you said. Old,
in in, Internet development terms, that is. Right.
Yeah. That's right. Yeah. It it, came about
in 2016.
So
that's what, ten years ago. So that yeah.
That's pretty old. That's pretty old in Internet
terms. That's right. So
what is Sonic, Jeff? What are we what
are we trying to accomplish? What's our goal?
Yeah. Well, it's all about a hedgehog.
And,
I that's my standard little joke for for
anybody that wants to explore Sonic, you have
to be kind of careful when you Google
the word Sonic. Otherwise, you just,
get a bunch of responses about an online
game involving a hedgehog.
But, you have to say Sonic operating system.
But Sonic is,
is, software for open networking in the cloud.
That's the acronym.
And,
this was,
as
the name implies,
it's open software.
It's an open operating system
and it was developed
by Microsoft, just I'm a I'm a history
buff so I always have to go into
the history,
developed by Microsoft, specifically
their Azure team,
as I mentioned a while ago in 2016,
because
they were
they had these immensely complex,
data centers
and they were having a hard time managing
it, especially
for multi vendor and and such, you know,
having to manage,
with different operating systems and they wanted sort
of one operating system to rule them all.
And so
out came Sonic and and,
it it was pretty crude in the beginning.
And especially after it it was released into
the wild,
which happened in 2022,
I believe, if my memory is right. And
that's really the significant part of the history
of Sonic
was,
was Microsoft released it,
to the OCP,
open compute project.
And, and it's been
been, open software ever since then, open for
people to develop, open for people to download
and use.
But the
the major major concept
of Sonic
is
that it interfaces
with any hardware.
So you can, your
as is as you should be able to
do, your hardware infrastructure
should become an abstraction
to your operating system.
So, you know, there's there's
an agnostic,
view towards what hardware you're running in. And,
you know, Sonic will run on,
broad
all kinds of ASICs. Broadcom, Marvel,
Cavium,
for gosh. There's others.
So so the
yeah. You know, VM. Yeah. And originally Barefoot
as well because there was a p four
when Barefoot was around as a chipset.
Absolutely.
So but I think the thing that people
need to understand is this is not a
replacement for Linux.
This is something that lays on top of
Linux
that essentially
and this is gonna be rather, like,
extremely
oversimplified,
but it kind of plays the role of
DirectX
or a driver system
that allows you to communicate
to
the forwarding engine chipsets that you might put
in a router or a switch.
Yeah. Like, it's not it's not precisely a
driver. That's not what it is. But if
you wanna put it slot it in your
head someplace in the ecosystem,
you can think of it as something like
DirectX or something like that. There's like a
language, an API, an interface,
a set of software, and that software figures
out how to talk to the chipset that
you wanna talk to. Now you can fix
all that, Jeff.
Yeah.
Yeah. I mean,
what you say is true. I was sort
of
processing some of it as as you explained
it, you know, but absolutely. It's not a
replacement for for Linux.
In fact,
Sonic is built on it runs on top
of Linux, Debian Linux to be specific.
And, it's written in c,
c plus c plus plus, I believe.
Different parts are c and different parts of
c plus plus Yeah. Yeah.
Yeah. And,
and and maybe we'll get into that in
a bit.
But,
but yeah, it's it,
the real secret sauce,
in my opinion, of of Sonic. And I'm
sort of looking at it too late,
two directions,
both looking down to the hardware, to the
ASICs in particular, and then looking up to,
oh, what does it interface with? How do
you use it?
Looking down and the reason it is hardware
agnostic and runs in all these different chips
yet chip chipsets that I mentioned,
is a component,
called the sync d container,
within Sonic. And and oh, that's a piece
early on I should have mentioned.
A key part of the Sonic architecture
is that it's all built on Docker containers.
So it's it's it's highly modular.
Advantages there is, you know,
you've heard that song and dance for for
years on, you know, what's what's important about
containers
is you could take one out of service,
you know, or it could fail or whatever,
you know, whatever that functional container is, and
it doesn't bring the whole system down.
That's not a new concept at all. I
mean, we've been building modular operating systems for
routers for,
since the Well the nineties. Yeah.
But most of the commercial ones are not.
Most of the commercial ones at the time
Sonic came out,
the idea of a modular network operating system
was kind of
I mean, it wasn't new, but it wasn't
widely deployed. Like, you didn't have EVO. You
didn't have
you didn't have a lot of,
of
CRS operating system stuff
out there. It was Cisco iOS classic, which
is monolithic. It was Junos,
which was monolithic. It was a I I
I would disagree.
Junos, that was that was actually the I
mean, I was running around back at the
turn of the century,
when I was when I was with Juniper,
and Juniper was a start up,
kinda knocking,
Cisco IOS because they were very monolithic.
And, and Junos was was built,
with modularity in mind. And,
but,
you know, how much modularity
is open to question, and it was still
hardware specific.
Oh, and maybe a,
an interesting maybe sonic relevant piece that,
that's a bit of trivia,
early on because I was I there's still
a little, Junos,
Kool Aid floating around in my veins.
I actually,
was very vocal internally
at Juniper
when it was still a little small startup
that, you know, this this operating system is
great, we should be selling just the operating
system and adapt it to whatever
white box you want. And of course they
were very hardware
oriented at the time and, you know, decided
I was an idiot and, and,
that went nowhere. But,
but I thought it was a good idea,
and here we are talking about Sonic all
of a sudden.
But, anyway, getting back to,
to
the the whole idea of this sync d
container,
I sort of went off on a tangent
there, the secret sauce within that is an
API
called the set, software abstraction interface, s a
I.
And anytime you talk about Sonic, you you
have to talk about the s a s
a I. And that's what actually talks to,
the ASIC SDK
for whatever,
hardware you're
you're, talking to.
And, so that's your interface right there and
that becomes where the you get the hardware
abstraction,
coming from is is,
is with
that interface between the SAI
and the, ASIC
SDK.
But
that's at the lower end. At the upper
end,
the other piece to really be aware of
with Sonic is that it has a CLI.
You can manage
individual devices,
using a CLI, but it's not designed for
that. It's designed for automation.
And it's designed, you know, for your entire
infrastructure to be,
you know, anytime you start talking about automation,
you hear those buzzwords, you know, to to
be,
managed as a holistic
entity.
You know, so so you've got
a management container,
that has a rest server in it, and
you you
can manage Sonic,
through this rest server. You can you can
directly manage, the databases,
in,
in the
Redis server.
Kind of the brains of Sonic is is
a,
is a database container that's built around Redis.
And,
yeah, it's
built for automation.
It's built for highly complex,
data centers,
and,
and, it is something that there's more and
more interest coming out
about Sonic for enterprises, and I think there's
a lot of business opportunity there.
Yeah. It's interesting.
When I first started encountering Sonic, a lot
of the problems we had were around
the performance
of pulling
routes
out of the routing table and into
the into the the ASIC
via that,
via SciDB and all of the stuff that
goes on in there. It was a rather
complex process.
And I don't know. Has that changed a
lot, Tom?
Or Jeff, do you know? Have there been
has there been a lot of work in
that space?
I can't imagine there wouldn't be.
There's been some people have people have tried
to address it. I don't know
that Sonic is used anywhere.
Well, I shouldn't say I don't know that
Sonic is used,
on hardware in places where route count is
really a critical thing. Like, I don't I
don't personally know of any deployments where we're
putting Internet scale,
routes into a, into a sonic box. But,
but but I have noticed in the, in
the community, there have been a couple of
people talking about, hey. We gotta we gotta
do something about this. Okay. Yeah. It's interesting.
It's just interesting to me because that was
now another thing that we need to realize
about Sonic is it's not a routing stack.
There's no routing stack
in integral to Sonic.
You run BRS or you run FR routing.
And
interestingly enough,
because
from what I remember, Sonic is very user
space oriented,
they decided not to pull routes off of
NetLinks or off I'm sorry, off of the
kernel.
Is that still true? It's still pulled off
of
the FPM, like, for Zebra
or whatever you're using,
whether it's BERT or FR routing or whatever.
They're
like, it's a different
it's a different route pull than from the
kernel.
Yeah. It's, you know, if if you're running
BGP,
you know, there's a BGP container,
and and that's basically,
Zebra based.
You know? And you can manage there's there's
actually,
a,
different mode, two different modes you can run
Sonic in. You can run it in a
unified mode, which you really should be doing
in a production network,
and but you could also run it in,
split mode where you're managing all of your
routes via f r r,
and,
you know, you you somewhat defeat the purpose
of Sonic by doing that, but but there's
also,
some rash
some rationale behind it. There's there's, some,
if you're
running some complex features that are not
supported directly,
with
with Sonic yet, you know, there that you
that's in zebra.
You you know, you may need to run-in
split
mode. But, I I disagree I disagree with
that just a little bit. I think,
it's a configuration.
It's it's a con configuration is what's affected
there, not route download, not any data plan.
And so really, it's how do you wanna
configure it? Do you wanna do it with
sonic CLI commands or do you wanna do
it with an fr.com?
And like you mentioned, Jeff, it's kind of,
do you want access to features that are
newer in frr? Yeah. Or, you know, if
it's been in there a while and it's
a basic basic thing,
then it'll be it'll be there. But there's
but there's an integration cost. Right? They have
someone has to go into Sonic and and
add the FRR feature into the configuration
language of Sonic.
So Mhmm. I I I think there I
don't it doesn't there's no performance penalty. There's
no, it's just how, you know, how integrated
do you wanna be. And if you need
even one feature that FRR has that Sonic
hasn't yet integrated, then you actually are forced
into split mode.
But
yeah.
Yeah.
I I I agree with that, and,
I think
where I was coming from is is, you
know, the you see a lot of sonic
advocates saying, you know, you're sort of defeating
the purpose of,
of sonic by, you know, going into split
mode. But then
you get immediately into but, you know, if
you need these advanced features,
then you gotta Yeah. I could I could
see where people are coming from because you
then you have to manage two configuration files.
Right? That's what I was thinking. Right? You're
you're automating two things, and you gotta make
sure that you've
made those two things do the right thing
at the same time. Yeah. And you've got
to be very careful careful with your,
you know, you're going to want to be,
I I never know how to pronounce the
acronym.
VTY shell.
Yes. VTY shell. Yeah. And,
you know, you're doing that with FRR, and
and you've gotta be very careful that those
configurations are safe because
they could be lost on reboot and all
that sort of thing.
And yeah. Or v two or,
or
command d or the the the conf d
thing, management d, which is all new in
MR routing. Yeah. Which is a different way
of doing things. Yeah.
So,
yeah, I think that there is more complexity
in using split mode,
but I also understand, like, you're just not
gonna get. But this is something about Linux
networking that people like, when you disaggregate,
it's hard to remember sometimes that, like,
up until very recently,
if our routing, if you were in VTYSH,
you couldn't tell
VTYSH the ping command integrated into v VTYSH
to use a source interface.
Yeah. Because it's a separate piece of software.
It's like it's completely separate. Now there's a
PR out to fix that and make it
where it uses the native and just transmutes
the commands
from v two y s h and feeds
them into
the native ping command that's running on the
Linux. But you'll find this in many cases.
Like, you cannot configure
unicast RPF and FR routing.
Why? Because that is a forwarding plane thing
that has to be configured in the forwarding
plane
if the routing stack does not own the
forwarding plane. Yep. And so you've gotta drop
to the forwarding plane to do that configuration.
And so a lot of people get like
they're so used to the Cisco,
iOS,
Junos
paradigm
where everything is unified,
and you do everything in one place.
And then you get in this world where
the routing stack is a daemon.
The interface to the to the at forwarding
engine is a daemon. It's running in user
space.
And then the forwarding plane itself is in
a daemon. It's like or it's in it's
in kernel space, and you're like, oh, I've
gotta go configure my verfs in two different
places. Well,
you know, I I don't know what to
tell you. There's the routing side of the
verf,
and there's the forwarding plane side of the
verf.
And some of that stuff can be done
automatically, but
quite frankly, a lot of times, you don't
want it done automatically.
You you kinda want
there's a reason that you're doing it that
way.
So yeah. So I think this is a
paradigm shift for people who are thinking about
using Sonic. Yeah. And and and that's that's
one of
one of several,
I don't wanna say roadblocks, but considerations
if you're considering Sonic is is, you know,
that that that it really is a different
way of thinking
about the network. You know, for all of
the the advantages,
you know, the vendor independence
and, you know, it'd be you know, orientation
towards,
automation and all of that sort of thing.
You know, one of the challenges
is that it's kind of a kind of
learning curve and a different way of thinking
for your frontline,
frontline operations people.
Yeah.
Which, by the way, I think is healthy.
Personally
Yeah. I think it's healthy. I I think
it's a much better it's like the way
we should have always thought about network operating
system. Whether or not you particularly like Sonic's
implementation
or not is beyond
the question of operationally,
you should really be thinking about the forwarding
plane separate from
the routing daemon separate for like, these are
different things.
Absolutely.
They should be different in your head.
Right? And Yes. You know, and and like
I said early on, and the this is,
I talked about the Juno's,
Kool Aid still kind of flowing in my
veins. A lot of Apstra
Kool Aid is still, in my veins too.
And when I was with Apstra,
you know, we were,
talking very much about
abstracting
the infrastructure.
You know, the hardware layer should,
should there should be an abstraction of that
so that you don't really care what hardware
is running.
You know, it you should be able to
change these things out and and,
you know, still have your operating system run
it. And and,
now I lost my thought about what lost
my train of thought about why I was
even saying that,
but
But no. But but it's the way you
think about being in the in the in
your seventies.
So but but I mean, that's what I
think where you're getting with what you were
driving towards there, and correct me if I'm
wrong, but was that that is the way
Sonic thinks about things. Yeah. And that's the
shift you have to make
if you're going to use this kind of
thing. You is that that is what, you
know, that your infrastructure
is
a holistic entity.
You know? It's not a bunch of nodes,
which, you know, every CLI jockey in the
world, you'd kind of run it that way.
And, you know, and that's that was the
driving
reason for developing Sonic was was,
you know, you
as infrastructures become hugely complex,
you and Jeff have a whole book talking
about managing complexity.
You know, you can't think of it
on an individual node basis because every, you
know, every node affects every other node or
all that sort of thing. But,
but, yeah, it's it's,
you've so there there's that shift in thinking.
The other part I actually I should mention,
I've, I've been writing a blog. I was
hoping to have the blog finished so I
could shamelessly plug it on on your show,
but,
I haven't quite got it out yet. But,
but Well, when you get it out, send
me a link. We'll put it in the
show notes. Oh, thank you. I will. Yeah.
But, basically, it's just,
why you should learn Sonic,
as a network engineer. And the reasons are
actually maybe you'll you'll never run Sonic
in,
in your operational network.
But the things you need to know,
you know, you've got to know Linux, you
know, because you you've got to be able
to know the least Linux commands for operating
the thing. You've got to know Docker.
You've, you've got to know some programming languages
because it's it's,
automated. So, you know, you you wanna know
Python. You wanna know,
prop baby go,
Golang.
What else? You need to understand APIs, rest
APIs,
to interact with the system.
And all of those things extend out
to where all of networking is going, you
know. So whether you ever
actually use sonic or not, you know, you're
sort of forced to learn all those other
things that are gonna be valuable,
tools for you. No. I'd I'd add I'd
add a couple to that list too, Jeff.
I think, you know, understanding how the system
is put together,
is is is kind of difficult in closed
NASAs because there's not any way to really
to really look at it. In some in
some Nexus versions, you can get into the
Broadcom shell and but it's not really obvious
in most of them and very limited. But
in but in Sonic, it's pretty much pretty
much all open, not all of it.
Broadcom keeps their things close to their vest,
obviously. But one of the cool things about
Sonic, you if you wanna see how it
works, you can go look at the FRR
source code. You can go look and see
how FPM is implemented. You can go look
in Redis and see all the routes come
from from the kernel to here to and
then they get pushed out into,
into Redis. And then the whole the whole
architecture of a system database is definitely not
new in the industry. Definitely.
But but you can you can look at
Sonic's implementation. Oh, this is we have a
central state database for everything, and here's how
it gets published, and here's how it gets
consumed. Like, you can examine the whole the
whole system. And I don't know. I feel
like that leads to better thinking,
in terms of network architecture. Because once you
see how the system's built, you understand the
component of the individual nodes, but also you
can I think you can take that understanding
and overlay it on top of the the
physical topology with cables and and boxes and
stuff? And I don't know. For me, at
least, that's been quite the quite a quite
a benefit to me. It is, oh, here's
how the system works. Now I understand why
I can't just shove all the routes over
here because they're gonna be downstream effects, but
I wouldn't have had that understanding without knowing
how the system works. Yeah. Yeah. I absolutely
agree with that. Okay. So that's what Sonic
is. That's why we think you should use
it. So maybe let's talk a little bit
about where Sonic is right now,
like, where it is in development cycle.
Is it a big community? Is it
well run,
you know, meetings? Is it how how is
that working out right now?
It is a big
community.
I mentioned,
I've actually, I've I've got a note here
that I have to look at because I
can't remember statistics off the top of my
head, but,
I mentioned that, that it was released to
OCP in,
2022.
Did I say that? Yeah. 2022. Okay.
Within two years, I've read I just pulled
this off the internet somewhere,
it had the community had grown to 4,000
contributors
across 500 organizations.
And,
and it is,
being embraced
sorry. A little bit. I'll put my notes
down now or I start reading off the
notes. But,
pretty much all the major cloud providers are
embracing Sonic.
You know, they all see that as a
as a great idea. And,
so the community is growing. The the latest
that those latest statistics,
which was would be what circa 2024
or so. So a couple of years old.
And,
it's it's
very popular in,
in the cloud provider space, very popular,
in the AI space, AI data center space.
Company I was working for,
next hop.
You know, they they're
creating switches,
oriented specifically
for AI data centers,
and sonic is the operating system they use.
There's there's another,
another startup out there, ARIA Networks.
Same thing.
They're they're making switches for AI data centers
and Sonic is the operating system they're using.
They're not not even trying to develop their
own operating system.
There are consultancies
growing up, and I think this is a
huge opportunity, by the way,
that,
has not been exploited enough. But there are
consultancies
out there
just around,
helping,
people
engineer Sonic.
Because as as interest,
starts
filtering down from these big hyperscalers,
to
smaller enterprise networks that don't have the DevOps
teams to be dealing with Sonic.
You know, I think
there is,
an opportunity like there was with,
Linux,
for companies like Red Hat,
to say, you know, we can
we can sup we can become your support
team,
for your your,
your smaller engineering teams that maybe don't have
the DevOps expertise
to do this.
And
so that's that is that was kind of
my next question. You see, you mentioned a
couple of companies.
Can you go
to Cisco or Juniper or Nokia
and buy boxes that run Sonic?
You can now.
I think it's interesting. I was gonna mention
that that,
that,
Cisco and Juniper both,
are
adapting sonic on some of their boxes.
Nvidia,
is, they've got their,
spectrum line
is sonic capable.
Nokia,
you may know better than me. I was
actually at Nanog this week and was chatting
with some friends at Nokia, and they just
kind of casually mentioned that, yeah, we're doing
some work with Sonic.
But I We have an entire internal Sonic
team. Okay. So we have you know? Kind
of an understatement.
Yeah. We have an entire internal Sonic team.
And, like, yeah, we sell a lot of
Sonic, apparently. Okay. Yeah. That's
I'm
not deeply involved in that side of the
business right now.
I'm not deeply I mean, I've only been
there since November. So what am I deeply
involved in at the moment? But
but, anyway, that's just you know, it takes
a long time to find your way around
a company and figure out where you're so
You've been there since November. You're still learning
people's names?
Yes. Well, for me, it's even worse.
I used to I used to teach a
I used to teach a worldview philosophy class
and a theology class for high schoolers, and
I had the same kids for four years,
like, as they would go through high school.
I I still don't remember their names.
Well, I can be that way about my
grandkids.
Which one are you again?
Yeah. Exactly. Yeah. I I don't know. Names
are a hard thing for me. But at
any rate yeah.
So
yeah. So the so there is it is
out there. Now another question
I would ask before we move into the
future stuff and thinking about where Sonic is
going is,
can you get Sonic
in a container for something like Container Lab?
I've not looked, so this is just an
honest question that I don't know. Like, I
normally use FR routing
in a container or SR Linux, but or
SR whatever it is. Yeah. SR Linux.
Yes. You can. In fact, that's that's really
kind of the recommended way to do it.
Container Lab, because it's oriented to,
to,
to contain containers. To containers. Yes.
It's that that's the the the best matchup.
You can actually run,
Sonic on,
EVE NG or,
I I'm pretty sure you can do it
on g n s three. I haven't tried
it, but,
you know, the, you can run it on
NetBox.
There's a lot of a lot of,
virtualization
platforms that you can run sonic on, but
to get it really in its,
native environment,
I would highly recommend, Container Labs.
Okay. So if people wanna learn it, they
can just go grab Container Lab,
and then there's a a build, I suppose,
a nightly or weekly whatever build
sonic in a container,
and you specify that in Container Lab
and off you go, and you actually build
networks with it
and play with it. Yeah. Okay.
Cool. Pull pull it all off of, GitHub,
Which is something else, by the way,
going back to things that you will learn
if you're working with Sonic is you need
to be working with Git,
and,
which has all kinds of benefits for you.
Yes. I'm still not a Git expert. If
you're gonna build Sonic though,
buckle up. This is not a read the
read me and type in commands for an
hour type exercise.
Yeah. It's definitely doable, but yeah. I should
mention that is another
area
of, you know, for people that are always
looking to
looking for,
business opportunities. That's another area where there's huge
opportunities right now.
Most anybody that works with Sonic will tell
you their documentation
sucks.
It's, you know,
it's it's hard to follow, it's not linear,
you know, you'd
if you, you know, if you look you
go to, you know, Cisco,
Juniper, whoever,
and say I wanna learn that operating system,
you know, they'll they'll to some degree, their
documentation is set up so you can linear
linearly
learn it.
Sonic is not like that at all. It's
just, you know, here's here's a feature and
here's the document for that. Here's the other
feature. Here's a document for that. And and,
it may or may not be accurate.
It's one of the things that I've,
learned working with people that are working closely
with sonic and and, getting in in a
slab as, you know, well, sometimes things don't
work the way the document said said it
would.
All of that to say, there's a lot
of opportunity out there for people that are
doing training,
to to build sonic training courses.
It's opportunity for books. There's not any good
books on Sonic out there right now. And,
so yeah.
Interesting. Business opportunities.
So let's talk about the future of Sonic.
Yeah. Where we are is where we are.
What are the big what are the big
pushes
right now
in the Sonic community? What are people trying
to do
to make it
more suitable, more I don't know, more whatever
for
Well, two directions, I think. One is, simply
adapting it more,
you know, to what it was originally designed
for, which is hyperscale,
networks, you know,
hyperscale clouds, AI
AI data centers, that sort of thing, really
huge hugely complex
networks.
The other movement is trying to move sonic
down into the enterprise.
And so I I sort of threw out
a bunch of stuff about you know what
needs to happen
for that.
You know, there's a lot of challenges there.
I what's the statistic I read just a
while back that,
if you look at enterprise data centers, there's
only
something like 200,
and I don't know I can't even remember
how old the statistic is. I think it
was Garner,
from a couple of years ago, but say
you know, that there's something like 200 enterprise
data centers
that are running Sonic out of potentially a
100,000.
And so there's huge market there,
but, you know, those roadblocks
that we were talking about, you know,
steep learning curve,
you know, poor documentation,
poor training,
or lack of training, I shouldn't say poor
training,
is,
are become very significant for enterprises.
Okay.
Interesting.
What's your perspective, Tom? What do you see
going
on? There's a few things.
One of the things because there's enterprise data
center. That's one segment. But another segment is,
what some I don't know. People gonna they're
calling it enterprise edge or what what you
put in your campus or whatever.
They're so that that segment,
has been
sort of underserved because there's some critical things
not in Sonic PoE. Right?
You can put it in,
and we've done that. But,
the so the pens working group is is
is taking that that challenge on, and they're
actually starting to do some work. That's kind
of interesting because because if you wanted to
run if you wanted to run Sonic Lake
in your campus network, you would have to,
you'd have to figure out the poe yourself.
Right? You'd have to develop the and it's
not it's not that hard,
but but you do have to do that.
You have to integrate it with the rest
of the system.
And the other thing is the
the the, l two protocols
just this was built for data centers. Right?
So Yeah. The the there's a there's an
old spanning tree PR that's, like,
five or six years old or something that
was never merged that a lot of these
a lot of the other the people who
build, enterprise sonic distributions
either take that or start over and and
kind of put their own stuff into it.
And so but as far as community sonic,
there is starting to be some traction in
the pens working group for spanning tree as
well.
If that's a technology that you're needing to
use or interoperate with. You you don't. I'll
just tell you upfront. You don't need to
use spanning tree. Continue.
The evils of spanning tree.
Yeah. Well so,
Yeah. Anyway, that's so that's, that's something that
has been lacking for a long time, which
was kind of a dead stop for a
lot of customers. Like, if you can't do
PoE, then I can't use this for like
85%
of the ports in my business.
And so, I think that's a that's a
that's a big thing.
What about Tom? Tom, do you see,
do you see a lot of interest,
you know, of of Sonic moving out of
the data center and into into the enterprise
edge? There's there's select people using it.
Not everybody obviously is public about it. But
there are there are people that are that
are doing well. I know for sure there's,
several. But,
the thing is the people doing this
aren't necessarily talking about it. Like, they have
other things to do besides go to conferences
and give presentations. Right? And so you don't
you just don't hear about it. It doesn't
mean it's not happening.
You know, there there are people with scale
and stuff like that that are and and
you can have scale and not be a
hyperscaler is another thing that I would say.
But, but but I think it's
there it's a small number of people. It's
a small number of organizations, but, it is
working for those that are doing it.
So wouldn't that wrap back around, though, to
performance
to some degree? Like, I don't know. Seems
to me like in I know you said
earlier that we don't tend to deploy Sonic
in places where we need lots of routes,
but I still I don't know. There there
are areas, like, that concern me about Sonic
that I would like to see people work
on, basically. Yeah. Like what? Like that. So
route download's one thing. Yeah. Yeah. Yeah. Route
download's one thing. Like, you're talking about PoE.
Spanning tree, I actually prefer you just, like,
get just kick it out. I don't care.
Well well,
I will tell you that the that somebody
wants it because there are people,
yeah, working on that that are not my
organization.
So Yeah.
Yep.
So, anyway yeah. So I don't know. There
there seem to be a few things like
that that I would like to see the
sonic community working on. So now if you
wanted to get involved in the sonic community,
say you wanted to work on one of
these things.
I know there are weekly calls. I don't
go to them and not because I wouldn't
like to, but because they tend to overlap
with other things in my life
99.9%
of the time. And I'm like,
could you please
not make the FR routing weekly and the
sonic weekly overlap with one another? Like, that's
that's just
painful.
And then I I don't know. Even internal
to Nokia, we have a whole sonic community,
and it's like, your meetings are always at
noon
eastern.
Like,
some of us need to eat.
Don't you eat during the meetings?
So I don't know. You know? It's like
a thing.
But, anyway, so if you wanted to get
involved in Sonic and, And, Jeff, did you
have any other future stuff you wanted to
talk about before we move on?
And,
and I may not be the right, the
the best person to ask about getting involved
in Sonic either because I I I've sort
of just
been consuming,
you know, what other people have learned, and
I've I've not been very involved in the
in the sonic community myself as as far
as those meetings and that sort of thing.
Yeah. So I'll say, you know, you should
really start by just downloading C Lab and
getting it running with Sonic.
That's, like, the place to start if you
wanna learn it. And once you've learned it,
if you start finding problems and you'd like
to get involved, there are weekly meetings.
There are GitHub repositories.
There are maintainers. Right, Tom? There are people
who can push things. Yeah. And like like
Jeff mentioned, it's, it's in,
Linux found it. It's in Linux Foundation now.
It was originally Yep. OCP, and then they
moved it to Linux Foundation. But,
but all the
probably the biggest thing is is go anybody
can join the working groups. They're all they're
all in,
I think that l a Linux Foundation moved
them to different mailing lists. But, anyway, that's,
you know, it's this developer talk. Like, you're
not it's not a working group where you'll
go and someone will say what CLI command
do you type to configure an IP address
on a port or something? But Right.
But but it is really interesting and especially
from the point of view of, you know,
figuring out how the system works. And there's
tons of working groups, like lots of things
going on. And then there's the weekly community
meeting,
that is mostly,
mostly feature development focused. So you'll have because
that's where, you you have to make a
presentation
and answer questions in the community,
the weekly community meeting before your PR, will
be merged. And so, you'll see a lot
of the future development type stuff in there
and a big big huge group of people
with a few people speaking.
But those are the those are the ways
that I know of. Sounds a lot like
I IETF.
Yeah.
Yeah. Well, let's not talk about the ITF.
I would say that, yeah. I was kind
of opening that door to see where the
put the water come out. I've not
I've gotten very frustrated with the ITF recently,
so I don't know. We'll see where it
goes. It's it's kind of a thing. So
That
you know, the being involved in in the
developer community, I mean, that's that is yet
another
My brain always goes to, you know, young
engineers and, you know, people that are just
starting their career and
and, you know, if if you are a
network engineer
and you have interest in DevOps,
that's yet another way of driving that, you
know, it's it's,
you know,
is polish off your your
c plus plus skills and,
you know, and and, actually develop features. There's
there's always a need.
Yeah. I one one thing, so the other
thing so just one more thing I just
thought of. The SCI working group is really
interesting. The people working on switch abstraction interface.
And you will I I have learned a
lot. I haven't gone to those meetings in
a while, but I've learned a lot just
by listening to them talk about the issues
behind maintaining things.
You know, so size a pretty low level
construct and you know people will be talking
about, oh, we need to add this feature.
Oh, we're missing an enum in
in the structure over here. And if you
listen, it's like from an education perspective. If
you listen, you're like, what's that? What does
that mean? You can go, you know, ask
chat g p t. What does this mean?
And then you can start to piece together
how a lot of these things work and
you don't have to be a c developer
to gain a lot of value out of
this, in my opinion.
Yeah.
Yep. I agree.
Cool. Awesome. K.
The biggest thing, Russ, you said it yourself,
is just getting started is
is,
you know,
grab grab an old,
server from somewhere off of eBay. That's what
I do.
You know, build yourself,
container labs and run Sonic. I I know
we're audio here for video when we're talking
to each other, but kinda
right behind me there is,
is a an old,
server off of eBay that, that I'm running
container labs on. That's my that's my sonic
lab right there.
I have two minis forum boxes sitting up
on that shelf you can't see, But or
up on a shelf, you can't see over
there. And that's what I do is I
just go buy cheap minis for them boxes
Yeah.
And, you know, and just
throw Ubuntu on them and
get continue the lab up and running and
then use them for various things. And that's
kind of my
that kind of my lab is sitting over
there. I kinda like small fanless boxes just
because I don't like Yeah. Minor.
I I'm the other way. I've my lab
tends to be kinda noisy, but it keeps
it nice and warm in here.
I I I buy a I buy a
lot of Dell r series servers off eBay
because they're cheap and, you know, very flexible.
And
I've I've always loved,
not meaning to make a big Dell,
pitch here, but I've always loved Dell servers
just because, you know, everything
just pops out really easy for a lab
and and,
easy to, to work with.
Yep. Cool. Alright.
Okay. So I think we beat this topic
to death. Well, not death or to extinction
or whatever you wanna say. When the horse
is dead, dismount. Is that the
Yeah. Well, hopefully, we haven't, beat it to
death. Hopefully hopefully, we've, generated a little interest
Yeah. A little interest. Yeah. Among your, listeners
or people that maybe didn't know Sonny.
Yeah. I hope yeah. If you don't know
it, get out there and learn it. It's,
you know,
it's
like all other network operating systems. It's had
its trade offs. It's positives, really great positives,
and some things that you kinda look at
and go, yeah. I'm not sure I would
have done it that way. But Exactly.
Whatever.
I think the same thing about Cisco iOS
and Junos and Evo and
all of that. Right? You know? It's all
that way. So it's just Yeah. Well, I
I mentioned early on my old,
history with,
Juniper when it was a startup and
a lot of, Junos
was,
you know, we got good developers there primarily
poached out of Cisco
by saying, hey, here's an opportunity to take
everything you learned building IOS and go all
the way back to square one and try
again.
And of course, Junos is an old operating
system now, but, you know Yeah. There was
a there was a time twenty five years
ago when it was new and innovative.
That's right.
Alright. Cool.
Alright. Jeff, where can people find you if
they want to? You have a blog, obviously.
I have a blog.
It's on my,
website, which is, www.doyleassociates.net.
And, you can find some blogs there that
I contribute to every now and then. You
can also find,
our mutual buddy, Jeff Jeff Tansura and myself,
and you're you're one of our most popular
guests on that show because you're a friend
and we always have fun.
Tom, we invite we invite Russ. Sometimes we
don't even care what the topic is. It's
just we'll just get on there and just
start
making fun of each other or whatever and
and, and have an entertaining hour and hope
somebody else is listening too. But,
that's that is called between two nerds.
The two is,
hex o x two
nerds.
And,
and you can find that on YouTube.
And,
yeah.
That's where to find us.
Cool. And Tom?
LinkedIn.
Alright. And I'm on LinkedIn too. I I
never think to plug LinkedIn. Yeah. That's fine.
And I'm Russ Weichkoff. I'm here at the
hedge at rule eleven dot tech on rule
on LinkedIn
occasionally
on x,
making weird comments that people don't know what
to do with. But anyway,
we know that we live in an attention
driven economy. And so thank you for listening
all the way to the bitter end of
this episode of The Hedge, and we will
catch you next time.