Lauren Malhoit: Welcome, everyone, and thanks for joining us. Today’s session is all about the new ecosystem partner we have between IP Fabric and Infoblox, which we're all very excited about. Like we promised, it will be a mostly demo-heavy webinar. 

But we're going to provide a bit of context here in the beginning. With NetMRI approaching end of life, we think it's the right moment to rethink what your technology stack can do. We're thinking here about how you can modernize your entire infrastructure using solutions that your friends in DevOps, platform engineering, cloud, and security may already be using, so we can have more consistency throughout the entire infrastructure. 

We'll be talking about how Infoblox and IP Fabric are partnering to help you move beyond a one-to-one replacement of NetMRI and toward a more powerful integrated solution for visibility, compliance, and things like automation readiness. But before we jump in, I'd love to have my co-presenters introduce themselves. 

Ken, let’s go ahead and start with you as our guest from Infoblox. 

Ken Lancaster: Yeah, thanks Lauren. I'm Ken Lancaster and I’m in charge of the ecosystem program we have with technology integrations, if you will, with our networking products like NIOS. 

Lauren M.: Awesome. Thank you, Ken. And Seb, go ahead. 

Sebastien d'Argoeuves: Good afternoon everyone—or good morning, depending on where you are. I'm a Solution Architect for IP Fabric. I've been working here for four years and have worked with a number of integrations, helping customers use the platform. 

Lauren M.: Now I want to encourage everyone to ask questions in the Q&A panel. We do have another one of our brilliant engineers answering questions live for you all. So if you have any questions throughout, please just go ahead and ask. 

Zach, do you want to do a quick introduction?

Zachary Brown: Good morning, everyone. My name is Zach, and I'm a Solution Architect here on the IP Fabric team in the Americas. I'm relatively new to the team, rounding out my second month, but really excited to be a part of it, learning this technology and platform, and excited to be with you today. Thank you for your time and thank you for joining. 

Lauren M.: Thanks, Zach. Okay, so I say we just dive in—that way we get to the demo a little bit faster. But first of all, Ken, I think we promised everyone we’d jump into more details from Infoblox about the end-of-life information and also the exciting things you all have planned. So I think we better just start there, if you'll kindly take it away. 

Ken L.: So for those of you that don't know Infoblox, we've been in this space we call DDI—which is DNS, DHCP, and IP address management (IPAM)—which is critical for any network. Infoblox has been doing this for about 25 years now, so we're a pretty large player in the DDI space. 

We're finding that DDI is becoming really critical in the security posture of an enterprise network. We're actually looking at everything that's touching your network, and we have great visibility into domain names, IP addresses, and things of that nature. It’s an area where cyber attacks can begin, so it's becoming critical to leverage what we do in our DNS/DDI area to improve the security posture of our enterprise and government customers. 

Last year we launched a new product called Universal Asset Insights. What that does is focus on multi-cloud visibility—the ability to see everything touching your network, whether it’s on-prem or in public cloud A, B, or C. It includes automatic discovery of every asset touching your network, which is critical to improving your security posture. It also identifies zombie assets—things that haven't been used in months, weeks, or years—to help you save costs. But mostly, it's about improving the visibility of your network. 

This product has been very popular since launching last year. With that focus on integrations—bi-directional integrations with security partners like firewalls, SIEM, SOAR, and XDR—we’ve moved away from configuration management or what you may call NCCM. Hence, we've announced the end of life for NetMRI. But not to leave anyone hanging—we've gone out, validated, tested, and certified alternatives such as IP Fabric. They’ve done a lot of work integrating into NIOS to make it almost seamless for you to get the same functionality you’ve been used to, with a platform that does much more than traditional NCCM. And that’s why we’re here today—to go into a demo of just a few of the things it does. With that, I’ll hand it back over to Lauren. 

Lauren M.: Thank you so much, Ken. It's been great working with you over the past several months, and we really are so excited about this partnership with Infoblox. We know you're the market leader in DDI—DNS, DHCP, and IPAM, for those who aren't DDI engineers. I spent my last four years in DDI, so it's near and dear to my heart. 

What I love about DDI is that it's really foundational not only for the network but also for the revenue-generating applications that run on top of the network. This is something we have in common—focusing on the foundation, making sure it’s running correctly. Because we all know about that "garbage in, garbage out" problem—especially in networking, and especially as we talk more about NetDevOps, networking automation, and AI. Had to get that buzzword in at some point during the webinar. 

So IP Fabric, just to level set for everyone, is a network assurance tool. We map and model your entire multi-vendor network in the cloud and on-prem—regardless of data center, campus, or branch. It truly is end-to-end. We're an appliance you deploy on your network, and we don’t require any agents to do our discovery. We discover your network the same way a network engineer would—but faster and more comprehensively. We let the machines talk to the machines. 

Now I want to stop here and take a quick poll. We want to know: how many of you actually trust your current network source of truth? This includes CMDB, Visio diagrams, documentation. We won’t be able to see who you are, so feel free to answer honestly. I’d love to see what you all are thinking. 

Right now, it’s showing exactly what I expected. It’s about what I thought—no one trusts it fully. We’re seeing a lot of “it’s good enough,” and a few that are “pretty outdated.” 

So to tell you more about IP Fabric and how we do our discovery: we provide full-picture snapshots after running a uniquely accurate and quick discovery that doesn’t rely on protocols like SNMP. We know SNMP is riddled with problems. In fact, the reason I knew the poll would turn out the way it did is because in 80% of our proof of concepts, we find things like missing devices or incorrect info in CMDBs and other sources of truth—due to inaccurate protocols that weren’t meant for discovery in the first place. 

Our discovery also doesn’t have to run overnight like some of our competitors. You can take incremental snapshots, too—if you’re just looking at a troublesome network segment, for example. Those can happen in seconds. So while it is a point-in-time snapshot, most full discoveries take maybe 45 minutes, and incremental ones just a few seconds. 

We build tables using our proprietary parsers—that’s the real magic behind what we do. These give you information on every point in your network—not just devices, but what’s happening between them. What protocols are we using between routers, switches, and firewalls? You get all that behavioral information too. 

From those tables, we create a network simulation and use over 160 built-in intent checks to ensure your network, cloud, and security environments are running as they should. This is all out-of-the-box—no extra licensing, no additional seats. We want your entire IT organization to have the same views—within reason, of course. We still provide role-based access control and all that good stuff. 

We also offer the ability to create your own custom intent checks. Again—no extra licensing or seats required. These just use logic to create; you don’t need to learn code, a new query language, or some pseudo low-code/no-code platform that’s just as complex as coding. 

Regarding the technology integration, this is a real integration—not just what’s possible through APIs. We can sync with Infoblox NIOS, their IPAM solution, and ensure the accuracy of network, cloud, and security devices and how they’re expected to behave. 

We’re not a monitoring solution. We’ve taken it a step further. With Infoblox, we allow the capability to do a dry run—you can see what’s about to happen before you sync with production. A “what if” scenario. And Seb’s going to show you all of this in just a few seconds. Seb, I think people are ready to see it in action. Can you start by showing us what’s possible with the new integration?  

Sebastien D.: Yeah, absolutely. You should now see my screen. I’m showing the interface of Infoblox. 

So to start with what we’re about to do, I’m going to begin with IP Fabric. As we explained, IP Fabric is going to discover the network, extract the information, and represent it in a table format—the topology. We’ll look at some of those later. 

Now, related to the Infoblox integration, the key thing we want to extract from the network and compare—then diff—to update Infoblox, is what we’re going to see in that table: the managed IPs. The idea is that you’ve got a number of networks configured on those network devices. That’s what you’re seeing here, where we have a summary with a number of sites and the networks we’ve seen within them. You can actually drill down to find more information about specific subnets—where the devices are, which interfaces fall within that subnet. 

This is what we’re seeing in this IP Fabric snapshot—a picture of the network at a specific moment in time. 

Now, in this scenario, what we want to show is this: we’ve got two snapshots. One is the state before a big change. In that situation, we’re adding new devices after a maintenance window. The idea is to use the integration so that after the change, we can make sure whatever is now on the network is reflected in Infoblox. 

I’m not going to go much deeper into IP Fabric itself right now. The idea is—how do we configure the integration, how does it work, and how do we synchronize? 

In IP Fabric, we’ve recently added the capability to create extensions. This is what we’re using now for the integration. Once you start the synchronization tool, you only need to configure it. The config file is documented, but you can use the default one we provide. Then, you just need to enter your IP Fabric token so that we can talk to the API—same on the Infoblox side. 

Next, we’ll do a dry run mode, where we just want to compare: what’s in the network according to IP Fabric, and is anything missing in Infoblox? 

Once you start the process, what happens behind the scenes is we extract that managed IP table (and some other information), and we compare it with Infoblox. 

You can see I’ve got different menus here. The first one shows the networks we want to create. These are subnets that were added after the change—new devices, new subnets—which were not present in Infoblox. That’s the first thing. We want to make sure this gets updated. 

From a logging perspective, there’s also a lot more information—what we already have, what’s already present. I won’t spend too much time on that. And then we have the full logs, which show the details of the diff: is something already in Infoblox or not? 

For example, here’s one from the settings we configured—we decided to ignore /32 subnets and only look at /31 or smaller. 

That’s the dry run. Now, I want to go ahead and enable the sync, because those subnets that were seen but not yet present in Infoblox—I want to add them. So I’ll start the process. Once it’s running, I can see everything is in motion, which is good. 

The sync happens in two phases. The first is to add the networks. That normally happens pretty quickly. I think if I start typing now, I might already see them—yes, there we go. These subnets were present in IP Fabric but not in Infoblox. So they’ve now been added. 

The second phase takes a few more minutes—this is when we sync the metadata. That part is important. Right now I’m just showing the subnet—it’s been added to Infoblox, which is good. But I also want more information: what’s behind that subnet? Which device contains the IP? 

So if I click on this one—this was one of the examples I wanted to show—you can now see the metadata is starting to appear. I think that was subnet 38, for example. We’ll also show in IP Fabric how it looks. 

Now you can see this is based on the snapshot time when we ran the discovery, and the device where we found that IP configured. All of that information, taken from IP Fabric, is now available in Infoblox. You’ve got an up-to-date source of truth from an IPAM perspective.

Lauren M.: Yeah, that’s awesome, Seb. So basically, we just saw you do the dry run and then the production run, if you will. 

And we did have a question that asked about what actually enables it to be in production. That was when you clicked on “Enable Sync,” right? And the “Enable Logging” tick box is literally just so we can see the logging—what’s failed and what hasn’t. 

Sebastien D.: Yeah, absolutely. The logging—you can run as many as you want. We’re only going to diff between the latest snapshot of IP Fabric, because that’s the one I’ve used, and what you currently have in Infoblox. The moment you’re happy with what you’ve seen, you enable the sync. This is where we take the data you’ve previously seen in the network to create and add those subnet devices into Infoblox, including the information we’ve got, which is used for the metadata—the one I was just showing. 

Lauren M.: Yeah, that’s fantastic. And that metadata is so helpful too—when you’re trying to search for things, make sure they’re up to date, and get the right context. 

So after we know things have changed—things got added to Infoblox—tell us more about where IP Fabric actually gets this data. How do we know there’s new information? 
Yeah, I’ll show that now. 

Sebastien D.: Let’s look back, and I’m going to start from a diagram. People love a diagram—it helps. Sometimes a picture is worth a thousand words. 

Okay, so I’m going to start with a network diagram that IP Fabric built from the month after the change. Now I’ve got network information showing me the state of the network—how the devices are connected. But what I want to do first is compare this with the state I had previously. I can say, “Okay, that’s my latest snapshot, and I want to compare with the previous one.” 

Everything I see in red are things that were present before and have been removed—or actually, I said it the wrong way around. The red shows things that are in the latest snapshot but were not in the previous one. So I can see these devices weren’t present before—they were added as part of the change. 

Now if I remove the comparison and focus on just this snapshot, this is the state of the network after the change. And I can easily compare that with the state before. So from a topology perspective, I can quickly understand what’s changed—meaning if I’m an engineer troubleshooting a problem, I don’t have to rely on outdated documentation. I may not know what’s changed in the network in the past 24 hours. And sometimes, networks change a lot—you go on holiday for a week and come back with no idea what’s up to date or not. 

Lauren M.: Yeah, I mean, that’s the first question we always ask when something goes wrong: “What was most recently changed?” We usually find our answer there. 

So if there's a change in IPAM, and things get updated, and we sync with Infoblox—can we tell if traffic has been impacted? And whether it’s impacted negatively or positively? Can we see if everything is running as it should? 

Sebastien D.: Yeah, that’s the next question. From a topology perspective, I can see. The example I’m going to use is between Site 1 and Site 2. I’m adding devices there to build new services, and I want users in Site 1 to access those services. 

We can use the path lookup tool. I’m going to simulate enabling an SSH application—the service we’re deploying. Before the change, I’m not able to reach the destination. There are two reasons: first, I’m hitting a firewall that’s dropping the specific flow. If I disable the security visualization, I can see what’s behind that firewall. Then I reach another firewall, but this one doesn’t have any routing to go to the destination—the network isn’t ready on that side. 

Now, after the change—this is the part I want to look at. I come in the next day, and what I’m seeing is I’m able to reach the destination, but from a firewall perspective, security is still blocking it. So if my goal was to enable that service, I’ve failed because I don’t have full connectivity from source to destination. 

This gives us visibility into what’s going on—maybe my colleague is able to access the same service. You can see for that specific source, both firewalls are green. So now maybe the issue isn’t with the network itself, but with the individual user’s machine. It helps the person troubleshooting determine whether it’s a network-wide issue or a local one. 

Lauren M.: Yeah, that’s a very diplomatic way of putting it. I love the end-to-end path lookup. It’s so important. Not to mention, we have the ability to integrate with ServiceNow—you can automatically enrich your tickets with this information. So let’s say you’re the network engineer and want to send this to your security person who handles the firewall rules or ACLs—you can easily give them that info. 

We know things get forgotten. We’ve seen changes happen where routes shift, etc. How do we know what else is falling out of configuration using IP Fabric? 

Sebastien D.: Yeah, the famous compliance question: “Is my network behaving the way it should?” Here’s one example—compliance from a flow perspective. Say I want to ensure that none of my users in a specific subnet can access anything on port 80. From an ACL perspective, we can check not just between IPs, but between whole subnets. If anything is allowed by that firewall, you’ll see it in the analysis. If it fails, it raises a compliance warning in the dashboard. 

Let me show the dashboard. I’ll just change the snapshot to one with more data. Once you’ve captured the network, you can quickly see what’s potentially wrong from a compliance standpoint. 

A simple example: say you set a rule to disable Telnet everywhere. One day, you check and confirm it’s off—but six months later, who knows? Has it stayed that way? You need a regular check to ensure compliance. There are dashboards you can configure to show when a new device with Telnet enabled appears. Then you can take action and fix it. 

Lauren M.: Tell us more about this extra dashboard—it looks like you can customize it for whatever purpose you want.  

Sebastien D.: Yeah, absolutely. This is a fairly new feature we added. We wanted to bring a more flexible view. The initial dashboard contains all the intent rules we have, but depending on the team using it, they might not care about the same data.  

If you’re higher-level, maybe you just want to see whether things like AAA or Telnet compliance checks are passing. You can create a tailored dashboard for your own unique needs. You might not want the more network-focused view that shows trunk mismatches, MTU issues—you can strip that out if it’s not relevant to your role. 

Lauren M.: That’s awesome, Seb. I think we showed IP Fabric and Infoblox in the context of not just replacing NetMRI, but going a step further. 

I do want to move into Q&A—we have quite a few in the panel. One thing we should definitely cover, Seb, is whether IP Fabric pushes configuration changes. Want to take that? 

Sebastien D.: Yeah—so, no. IP Fabric is a read-only platform. We don’t push configuration. But we help you collect the information you need to know what should be pushed. 

Sometimes I like to say: pushing the config isn’t the hard part. Knowing what to push, and where, is. 

Lauren M.: Exactly. I want to let everyone know—we offer a free trial. One reason folks are hesitant to try trials is because config gets pushed. But since we don’t push anything, it’s a very safe solution to run. 

Also, while we don’t push configs in the way a traditional NCCM might, we think it’s more important to use tools already in your stack—bring them to full potential. Why buy a dedicated network config push tool if you’re already using Ansible, Terraform, or others? 

Sebastien D.: Yeah, exactly. The data we provide is easily accessible through the API. So if you’ve built automations with Ansible, for example, you can just change your approach—use IP Fabric to provide the network data, know what needs to change, then use your existing Ansible playbook to make that change. Then IP Fabric performs a new discovery and updates the state, so you can validate whether your change worked or not. 

Lauren M.: Yeah, that’s a great point—being able to validate changes and close the loop. Workflows aren’t just about networking anymore—they include security, compute, storage, and more. 

We didn’t get to every question, but we’ll reach out if that’s okay with you—or you can reach out to us. You can reach us at [email protected], or try our free trial on our website.  

The free trial is the full product, 30 days, up to 100 devices. We’ve scoped it a bit for the trial, but of course we support large, complex networks—generally 1,000+ devices. 

Thank you so much, everyone, for joining. Huge thanks to Seb, Ken, and Zach for running everything. Please reach out if you have questions.