Eric Kavanagh: Hello and welcome back once again to the longest running show up in the world about data. It's called DM Radio.

Yours truly, Eric Kavanagh here. And folks, I'm excited to dive into one of the more interesting domains of enterprise technology. It is the backbone in many ways and has been for years and a lot of people say it's magic. So you gotta try to figure out what's going on.

It's the network and networking and network topography and making sure the network is running smoothly. I've got Daren Fulwell with me from IP Fabric. He knows all about this stuff from way back in the days before there was even the interwebs.

Now I know he doesn't look that old, but that's what he told me. And, you know, Daren, I've always been fascinated by the network, for lots of different reasons because, first of all, it is the lifeblood flowing information.

And as soon as you set up a network in an office, well, the network is like the backbone of your operation. And I've studied this at various points over the last twenty years or so.

I mentioned before the call about ExtraHop, which I really was amazed by because they're able to siphon your network traffic off and create a digital twin of your entire environment. And that's what you folks are doing as well.

At IP Fabric you're looking at the network and then you're creating a digital twin of the environment such that companies can figure out what's going on, why is this going slow, why is it going fast. You can answer those questions if you have the right data and the right lens. And that’s what you guys are doing, right?

Daren Fulwell: That's exactly it. So as you've kindly pointed out, I'm older than I look. I’m a network old guy. I've been kicking around in the networking space since the 1990s when networks were pretty simple and pretty straightforward. They were there to get you access to a file server from your from your desktop PC or or allow you to share printers in an office.

I mean, that's literally what we would do. And then all of a sudden, this the World Wide Web comes along and people realize they can start distributing their applications. As soon as they realize that, we start getting data centers popping up everywhere. We start you having WAN connectivity, Internet connectivity into enterprises. The cloud comes along, and then we're putting these data centers that aren't even ours anymore. They're someone else's.

And so now we've got lots of complexity there that we just never had. And and I think a lot of the challenges that that we see day to day are because we haven't really adjusted our mindset a lot when we come to operate in these networks.

We still look at them as individual things, and we don't think of the network as a whole. So the biggest challenge—and you've mentioned the the the digital twin aspect—the idea here is that you can map the whole of your the network infrastructure and then understand how applications and those business-critical services are provided service by that network infrastructure.

You can map the dependencies through and understand the impact that the network has and the changes that go on on it have on those services. In a nutshell, that's what we're there to do.

Eric K.: That's impressive stuff because especially for a larger organization, the network becomes humongous. It's responsible for running all kinds of things. And, of course, there are networks in the cloud too. They have their own networks that they operate on. There's also software-defined networking, where you're trying to be dynamically adjusting to the needs. It's so fascinating for me to think about the story of how we got here.

You mentioned the 1990s. I remember Yahoo was one of the big players back then. And if you think about what they worked on, it really intently was being able to handle peak demand and then low demand. Like Black Friday, for example. That's a big deal. You have to scale out to field all the traffic and then ideally scale back down. That was the hard part. Right? You could scale up, you just couldn't scale down. Paying tons of money for nothing, and then you're getting hammered, basically.

Daren F.: And if and if you don't know how you're connecting to all that stuff, how how do you get any handle on it, especially when things start to go wrong?

For me, it's really interesting because as a practitioner, it so often falls onto your shoulders to work this stuff out. And not just you as an individual, because I might understand one technology really well, but then I need to talk to someone else and to someone else and to someone else in order to bring all of that together.

I might have a security specialist. I might have a data center specialist. I might have a campus specialist because it's not just about those services; it's about accessing those services as well. You need you need to make sure that people can get to them. So there's all of those pieces of the puzzle that need to be assembled, and and it's not an easy thing to to keep all of that information in one tiny brain, unfortunately. So along comes the data model to try and do that for us, and that's where where IP Fabric steps in.

Eric K.: So I mentioned to you before the call, I think a lot about IoT and systems, especially at scale. You got lots and lots and lots of objects out there.

How do you keep track of them? How do you even view that? How do you look at that kind of thing? It's not as easy a problem to solve as one might think. And the data model is always important because a data model represents the optimal flow of information around the network.

That's what you're trying to do when you persist the data model. You try to figure out ‘What do we really need to deliver in terms of information packets or functionality? How can we optimize the structure of our data persistence or our data lake, data warehouse, whatever, to facilitate that?’

And that's where you have come into play to figure out how to use a data model. And you mentioned you've got a relational database underneath, and a sort of graph-like structure, which is interesting because a lot of people would go with a graph. So maybe talk about that. Why do you have that approach?

Daren F.: What it comes down to is is use cases, from our our customer's perspective. The graph walking is really important, but it's very specialized. If you think of the data that comes from these network devices, it comes in three flavors.

One is the inventory data. I've got a node on the network. It's a Cisco router. It's got this configuration. It's got these interfaces. It's done this thing. It's just a lump of tin with with these properties.

You've got configuration data, which is all about ‘What state do I want this thing to be in when it when it first comes up? When I first power on, what do I want it to start doing?’ And what it literally starts to do is is exchange information with the things around it. So it's getting busy, it's starting to understand that.

Then I need to to worry about state data that's created in that device because it's all then about saying, ‘Well, what is that device now gonna do once it's settled into the network? How's it going to provide those services you were just talking about? When a packet arrives at it, how does it make the decision as to where it's gotta go?’ Well, it needs to listen to everything else.

But all of those things are pretty flat pieces of data that relate to to that one device. In that sense, it's straightforward.

So the bulk of the data that we're gathering is these kinds of this kind of normalized data because we we talk to lots of different vendors of device, and we bring it all in and and store it in the same form regardless of those vendors. But, ultimately, the anything more complex than that is based on our analysis of that flat data.

So then it becomes a question of right now we build a topology based on what we see rather than based on what we think is supposed to be there.

We don't look at documentation. We don't look at those things. We actually look at what's actually in the network. We build our graph out from that. So that's why then the graph is actually fairly lightweight layer on top, but it's basically created by our ‘special source,’ to your point before, as we were talking before the call.

Our customers, when we talk to them, they want all this detail about the about the devices. They want to be able to do compliance checks to make sure everything is configured properly. That’s facilitated really well by a fast, efficient, relational databse.

When we get to doing path analysis through the network, or we get to doing segmentation, which is always an interesting one, how how is that network divided up and secured from each other? That that kind of thing. That's when we can start getting into graph traversal, and that's a whole a whole different ball game.

Eric K.: To your point, there are multiple layers in the architecture, and they're doing different things. But the key is performance at the base foundation, which is the relational database and then the fairly light graph that's tracking everything.

And you talk about configuration. It's my understanding that a lot of hacks occur because of bad configuration. Because for someone forgot to configure something properly. And, you know, again, how how do you surface that data? How do you analyze that data? You wanna have a scan that looks for what the configuration is and compare it.

Daren F.: Compare before and after, exactly. And and the so the way that we approach that is on a snapshot basis.

So it's about not just grab all that information and then walk away. We grab that information, but we try and grab it within the whole of the network within a time window so that we can be sure that things are as current as possible when those when we understand the relationships.

Or if something changes, what we'll have is we'll have a snapshot from from before the change, we'll have a snapshot from after the change. We can compare not just the individual device, but the other ones that it might have impacted around it, and and understand how that ripple effect, which is essentially how the network knows where to send traffic.

Because everything's communicating with everything else, there's a ripple effect. One change in one place gets echoed through the whole network infrastructure.

This is how we can see the impact of a change. It's also how you can look to predict as well the potential for a change, which is something we're actively, experimenting with at the moment, which is is an interesting space.

Eric K.: So do you have sort of a playbook? In other words, does does your solution over time identify, ‘Here’s the problem, we solved that problem.' Now it has a record of that problem, and it knows the next time it sees this pattern of behavior, it's probably that problem. If it's not, then we'll try something else. But I'm guessing you've got a sort of repository of assessments that can be leveraged dynamically over time. Is that right?

Daren F.: I mean, that's absolutely possible. And here lies the challenge. Right? If you wanna be those kinds of capabilities are things that that are generally built on top of the the base platform.

And, yes, there's absolutely those kinds of capabilities becoming interesting and more and more practically possible as well as we go. One of the things that we've just enabled, in the last six months in the in the platform is an MCP server.

And all of a sudden, what that's allowed us to do is start using really strong LLM, models to give us really interesting insights, not just into the state of the network at a point in time, but trended over time.

You can you can start to see some really interesting patterns and dig deep into to what's caused them. I think that's it really helped people understand the benefit of having this this visibility is that not only can you sit in front of the product and click through a diagram and do some stuff, which is nice. Not only can you automate the thing because everything's API-first as as all software is these days. But now you can you can query it via natural language and and really dig deep into into the causes and and effects of change.

Eric K.: I'm glad you brought that up because I was gonna ask you that question, and it makes a lot of sense because you have to be careful how and where and when you use LLMs in any sort of enterprise workflow.

But as long as you respect that they are a stochastic engines, they are designed for discovery and explanation and ideas and not necessarily for deterministic enterprise workflows. As long as you understand that, I have to believe they are really very interesting because, when when the network is slow, I always joke, ‘Is it the network? Is it your your your database? DNS? Is it you?’ Like, it could be anything. There's the whole stack of things that could be going wrong, but you typically blame the network, or blame the storage.

I saw a guy at a conference just the other day. He said, they asked him what role doesn't exist in a company that you think should exist. He said the role of ‘Director Of Storage Is Not The Problem.’

Daren F.: That’s fascinating. You ask any network practitioner, and they will tell you the same story, but they will go around with the T shirts: ‘The network is not the problem.’

Eric K.: We swear it’s not us. But the the thing is the network touches everything. So that's that's the hard part. And being able to I mean, even, like, two or three levels, it's like a graph. Like, most graph databases can do two hops or three hops pretty easily, but seven hops, eight hops?

Daren F.: This is the real challenge, especially in the network space, especially when you've got multiple networks daisy-chained to get from one place to another. You've got different control planes in there, and you've got different forwarding mechanisms. And you have to have an understanding of how each of those work in order to get from one end to the other.

And that's where where, again, the special source piece in our software comes in because we have the database, which is great. Being able to retrieve the data and pull that into into that form, fantastic. We have this topology kind of approach that we're able to build out graph. Brilliant. Because it gives you something you didn't have in terms of diagrams and blah, blah, blah.

But then on top of that, again, we have this traversal knowledge and understanding that really can only come from network practitioners themselves. Two of our co-founders were expert networkers themselves. Our product is steeped in in that experience. And as a result, we're able to bring that experience to the product itself. So we're able to to show exactly what impact that sort of thing is gonna have, and how far and wide that impact can go.

Eric K.: We got about two minutes left here. How big an impact does new hardware have? I mean, I'm sure you guys are tracking the latest routers, switches, any old network devices, and, you know, things are changing rapidly.

Just in the processors on machines, they're changing so rapidly that one machine can do something. How do you stay on top of all the network of all the networking hardware changes?

Daren F.: This this really comes from our customers. We're lucky to have customers who are very collaborative and work very closely with us.

So if we know that there are new technologies coming that they're going to use, of course, we keep across it ourselves as best we can.

Of course, we partner with vendors. We have relationships with some of the major vendors. So we do know and hear about these things, and we keep up to date with them.

But in reality, unless you've actually got the hardware to discover against, we're never gonna be able to really model that in the way that we need to. So this is why we we collaborate with our customers who are adopting these new things or or with those those vendor partners as well.

On the whole, we managed to keep pace with it. But as you say, it's it's a never-ending battle. So, we do our best.

Eric K.: That's awesome. We’re coming up on time with Darren Fullwell at IP Fabric. I'm sure we'll hear more from these guys in the future.

This interview was originally broadcast on DM Radio. Listen to the full episode here.