My name is, Darren Forwell. I'm, chief evangelist for for IP Fabric, who, I don't know if you've realized, are Diamond Sponsors at this year's Cisco Live EMEA. If you want to come and see us later over on Booth Bios. So I had to get that in marketing as that over here. So, joined by one of our customers, is Julien Monto.

Do you want to introduce yourself for me? I will introduce myself. So Julien Monto. I'm a connectivity solution architect in a large of unique manufacturer located in Europe. So it limits a little bit.

And we have been working with ApiFabrique since 4 years. And this session just to introduce the journey we had, so use case, and how we have used the product in the whole automation approach we have in the competitive. Thank you. So, obviously, as as Julian says, we've been working with, Airbus for a while. What, there was a kind of a program of work that, Airbus were were progressing on, and, they had some initial requirements and everything that they wanted to from the data.

So we'll talk through some of that, shortly, and then what we want to do is is explain to you what the network assurance does for, for, Julian and his team, And then talk about how that, implementation has matured over time and the the sorts of develops that developments they're wanting to use that network data for. So that's the the plan for the discussion today. So, Julian, do you wanna start with really what your requirements were for the network data you were looking for? Yeah. So like I said some 4 or 5 years ago, we went to have a network automation program in the company.

So starting from there, we take the approach as what is a framework we need to really have all the use case we wanted to do to be done. We say, okay, we need to have a GitHub, GitLab way of storing codes. We did IWA principle. We said okay we need an API to expose the service to our customers or have a single point of executing things. And in the discovery, we realized that we lacked the standardized way of getting the data out of the network.

When I say standardized, because we were already getting the data in one way or another. But at each use cases, more or less, there was a new way of getting the data. The engineer were redoing the things that perhaps another one did 2 or 3 months before. And this is why we have looked at the market, tried to say, okay, can we have a tool instead of doing our own that can get the same things as the standard guys of we. And also, it's a business use case I would say.

We were having some internal customers that use the hosted data. And for example, we have the facility management team. They use this internally to determine how full the building are or the hosting team because they use that to cross check their CMDB and data with the network information. And starting from there, we just we have 2 or 3, I would say, vendors we were testing in. Yeah.

And then we choose a IP fabric. So, I mean, it's it's interesting you talk about that that sort of, that need for the structured and and data that represents the whole network. Right? That was that was the important part to it. I think one of the things that our our cofounders, realized very early on was that that this sort of data source is very rare to have access to documentation of the network that's accurate, up to date, automated, in in such a way that you can then access it and spread that data out, across the organization, was key.

So I just briefly wanted to touch on the things that IP Fabric does here and the sorts of data that's involved that we're talking about just to give you a flavor of that. What what the product does is starts by discovering your network. So it crawls out through the network, collecting and gathering, the information you see in blue here, the inventory of the devices, the configuration, the state in order to understand what what the network actually looks like at a point in time. And then from having that data extracting topology information, understanding how those devices are interacting to deliver network service. This now gives you a measurable view of what the network looks like end to end, because you understand all of the elements in the path from one point to another.

And you can because it's normalized data, you can compare across vendors, across different parts of the network and understand. Right? Is the network doing the things that I need it to? And the other aspect to it is this is done over time. So this isn't just a one hit thing.

IP fabric will capture snapshots of the network as often as you, require of it in order to to see how the network is changing over time. And I think some of these this normalization aspect and and having this this end to end holistic view of the network was key, I think, to some of the the the work that you had to do then after that. Right? So sorry. I'm just just this slide, we're just gonna talk through a little about, the journey, I suppose, with IP fabric and what it's meant to, to to yourselves and your team in order to, to use that data, I suppose, make the best use of that data.

Yeah. So, of course, the first thing we did, this is initial setup. So put the appliance and something like one day you have something visible because the first discovery takes the seed. The standardize pipe of the network is quite easy to discover. And quite quickly, you can have some data.

You realize that all things are not the way we are thinking they were. But as long as you are doing this, there is also some life cycle things to be done saying, okay, I'm saying that all those things are not discovered. Why? Oh, they are not using the standard potential. Okay.

We update them. Oh, this network is not discovered. Why? Fire flow are not open and standardized. So there is while you expand the discovery, there is a whole approach of your network when you realize that 80% was right, correct, but you still have a lot of small discrepancies that you have to correct.

And this was the first initial setup. And at the same time we had some real use cases for projects that needed concrete data that more or less directly started to use it before reconstruction. And then we have something we have called ongoing adoption. So we talk something like 3 years ago to 2 years ago period, 2 year periods, where we really leverage IP fabric to help us in the, I would say, day to day operation and standardization. Some use case, like, for example, is that BGP clearing of configuration.

Yeah. For historical reason, not everything was cleared. In epi fabric, you can have a clear inventory. Those all those stations are active. Why is it active?

Perhaps I should check something has been removed, and we should do do it. Then we had all the access switches that should follow template that were not always followed or an architecture that was not always followed. It was already done in the past with playbooks, manually, and so on. But now it's directly done in IP fabric. At the same time, there was a big benefit for us.

Like I explained at the beginning, the team sometime were redoing their own to getting the data. So they were losing time in operation Yeah. To try to solve an operational issue or an improvement requested to just get the data out of the network and then act on it. We have a large environment. We are talking about 6,000 switches, 8,000 access points, things like that.

So for us, the way to scale is important. And one of the main benefits of IP fabric is from there it started to be kind of hub. Now the operation team knows that they have to go at IP Fabric to get the data they need to help them in the operation. OS upgrades, as I said before, is one of the example. When you are doing campaign upgrades, always there is some that are missed for whatever reason.

All later on, there is a new species come back from the inventory or replaced that are still in the older version and are not put correctly. And this comes to my next point that we did also in the time, this is the intent pull. One of the feature which is very nice, I would say, as a customer in IP Fabric is I can leverage filter rules on the different tables to say this is the way I want things to be done. And then from the central dashboard, you can check. So this was really the, I would say, expansion ongoing things.

At the same time, we use it for what it was supposed to be done at the beginning, automation use cases. Okay. So some example, I can give the hosting decommissioning. When the hosting team want to automate the DNS decommissioning, we ensure that it's not present in the table, the cam table, and switches. So it helps us to automate, but with a qualification before trusting what they are requesting to us.

Things like that. So you mentioned, automation. I guess key part to any automation ecosystem is that source of truth. Right? I'm guessing there was a use case there.

So indeed, a little bit for us more as the end. One of the thing we did also with IP Fabric is to help us to compare our surface and IP Fabric as a state database. Meaning that for us, IP fabric is not the inventory, it's just a way to correct the inventory. This is the way we approach the standard change in a greenfield environment. If we were, I would say normally in a perfect world, you should not have these direct changes at the end.

Normally, all people should go to standard or automated changes. Anyway, this is life. And when there is prices and so on, people can modify the system, which is a network in our case. And where we leverage IP fabric for that is, IP fabric is discovering the network and storing that in a system. And we have done internal development to help us to compare the source of truth.

Today, we use NetBox but can be not a bot. That's in COT, give us 42, whatever you want to compare what we have in source of truth and what we have in state database. And I say to compare or to update, it depends. We have a logic saying for example an asset, a CI should start to come from in the source of truth. I will not create a device because I've seen it in the state database.

I will pull up in a report saying, hey. This is wrong. You should create it. But adding a device in the source of truth is a human decision. But for example, what we get out of epifabric is updating the serial, updating the version of the devices.

This is not variable action for human. There we have Rapid Fabric to update the information into the source of truth. Yeah. I guess we talk about, different types of truth, I suppose, in the network when we're talking to customers. And I think, what we like to think of is IP fabric is that observed truth, that state of the network as it actually is.

Whereas the NetBox in the automation process is that state of statement of intended truth. It's what you want the network to look like. So what what I guess you've done here is you've used IP fabric to measure the distance between how you intend the network to be and how it actually is. And then, well, I suppose have a feedback loop almost into the automation. Yes.

That's it. So thank you for the insight because I think that's a really interesting point that that can be missed in the in the path. And I guess that that fact that IP Fabric is is doing that discovery, doing that collection for you means that you've not got to code it yourself, and spend the time on on looking after that side of things. Yep. That's awesome.

Thank you. So I guess from there, Julien, they've been everything's done. Right? Your network's fully automated. You're doing everything.

You you have no more need for the data. Is that right? No. What we did afterward is what we call scope expansion. So this year started last year and this year, we discovered the what we call the roof, the west of the world.

The way we are structured we have a main IT part in Europe and we have independent companies across the world. Those independent companies they manage their own IT. They should be follow the enterprise governance standard, impractical, that do not do it. So we have used that prefabric for us to get a continuous way of getting the information of those environment to compare to what it should be. Does it follow the right version of the grade?

Does it follow does it have dot one exactly access everywhere? It's supposed to, but then we can do that in a structured and consistent way. Of course, we are already doing that in an audit base. So it meaning that time, you do an audit every 2 years because this takes time. Then things are drifting.

And then you correct things that are drifting and then see you later in 2 years. What we are leveraging in IP Fabric now is trying to do it in a consistent and honest I was gonna say so so often that that sort of problem will be highlighted in an audit process. Yeah. That might happen once a year. But what you're able to do, I suppose, with because the system's doing this for you, it's doing it daily.

So you're able to see that drift almost before it happens or as it happens. And when I see scope expansion, I talk about geographical Mhmm. But also functional. Okay. For example, we have done a large migration to a new monitoring system.

So it would call Zabbix. And we use IP fabric as a way to structure and then create the map. So it's saying that we structure, we create the map in IP fabric. And this representation, instead of manually doing it to the BICS with XML and so on, we directly take it out and import it into Zabbix. Same, we have to play with the API on both sides, IP fabric and Zabbix.

But it's quite nice because when a new device come in, we can clearly put it on the map. ApiFabric is doing the designing for us. We have to help it. Of course. Like all graph based discovery system, there is some intelligence at the beginning, but you have to adapt it to what you want.

But it was another scope expansion with it. Yeah. It's a good it's a good point that that, obviously, we we're talking a lot about the data that's in IP Fabric and and how you can use that in other systems. We have a a very, thorough API, very thorough REST API in order to allow you to pull that data through. There's also a UI, that sits on top of this and does a lot of the visualization for you.

So things like the topology mapping and everything, which is derived from the relationships that we pull through from the devices themselves. We're creating that that constantly updated view so that you don't have to. The network engineer doesn't have to sit down and draw video diagrams of the network that they've already got because we'll do that for you. And I guess being able to lift those diagrams out and that visualization out of the platform and use it in other ways allows you to enrich, I suppose, the the the wider tooling. Yeah.

And what we call what we try to move forward is really a data centric network. The way to really get the leverage of the data and use it in the business process. One of the main example I can explain, this is something we call SONNET Automation and Group Attribute, SAGA project, where the logic is The way IPAM is managed in large enterprise is mainly manual. There is some intent to tags the subnet to say okay we know where the subnet is a compass subnet, this is a data center subnet, this is a user subnet, but this rely a lot of time with manual process, people tagging it manually. What we are trying to leverage is as long as we standardize the network architecture, I know the role for my data center distribution.

I know the role for my campus distribution. And we have Pfabric that can easily see the routing table of the device and the directly connected route on those devices. So if a subnet is directly connected in a Compass distribution, by nature, this is a Compass subnet. If it's directly connected on a data center distribution, this is a data center subnet. And the same for user based on other logic, the site the same.

When we see the device, the subnet in a site as directly connected, I'm almost sure that this subnet is linked to a particular site. So what we have done with IP Fabric help and inbox information as well is help us to enrich our IPAM information. For a while, for a simple use case that people using firewalls will know that when a new network arrives into the environment there is some processes to say, hey, a new network is arriving, please add it into the right firewall groups. But a lot of the time, the request is not starting from there but from a user incident saying, hey, I should access from this environment to this tool and it's not the case. So once we have the logic of tagging all the subnet, we are automating the firewall creation the firewall group's creation that is being used in the firewall rule afterward.

We're just combination saying for the administration of the access point saying okay, all the access point are no work. The specific network, this network is tagged that way. I will open the firewall for the controller to access all the access point with 1 unit group. And if a new site is deployed, a new building is deployed, it will be tagged automatically and added automatically afterward. I guess from a from a tooling point of view, and I'm just thinking how how those all those things are interrelated because what you're saying here is that you've got various elements of tooling that you're using in your in your more more business facing processes.

Things like the IPAM, things like the monitoring and the, and the firewall management. As things, initially, those things have to be updated accurately so they have to be updated accurately to reflect what's actually in the network because IP fabric is is gathering that information for you in the snapshots. I guess you're able to do that comparison to say what's changed day to day and then use that information to make sure that those tools are also updated, educating the whole process. So you you know what IP addresses are in network. You know where they're rooted and so on.

What is important to understand is hyperfabric, like you said, is you get the data. But hyperfabric doesn't have the knowledge of your network in a kind of business knowledge. So this is a great tool to help you to get this technical data. Yeah. But what we have to do afterward is try to ingest your knowledge of your environment and to combine both of them so that you can get value of it.

Yeah. And it comes back to what we were talking at the beginning at having that that full view. What you're doing is you're you're augmenting the the tooling that the network practitioner needs to use. So you're not you're not replacing anything. What you're doing is helping everybody be more consistent, be more efficient, and have that that consistent view of the whole network.

Yeah. And something we have done, I've mentioned that we have external businesses using our data and what we've done also, we have done an API exposing not directly IP fabric because the API pass changes. Sometimes we do also we do expose all the type of data. So the business now have an API gateway to be able to get the information out of FAP fabric and they use it afterwards in the environment. One of the example we have, we have a large product in term of enterprise security threat modeling, whereas they model in a great database, the business processes, different CV, the asset, to be able to link, I would say, the different once there is a threat or an issue.

Yeah. What business process, what IT asset will be impacted. And we have helped them and we have used IP Fabric for helping them to model the network in this Right. Large enterprise modeling. So I guess, again, what you're able to then do is take an application and say an application talks from here to here.

What is the infrastructure that sits underneath the application in order to make those associations, and then it can feed into all of the processes around? And if this application is broken down for whatever reason, what business process is implied behind? What part of the company will be impacted with this kind of issue? So this is a we are just a small piece of the coin, I would say in this, but it's helped a lot because this is the network is a group, I would say, helping linking things together. Yeah.

Yeah. This is where we do we do our part. And, of course, can be super useful for all of those other, IT teams around who who need access to to that network data. You mentioned something that was interesting to me as well. This idea of taking the data and presenting it in a different form for people to consume without actually having to log in to the platform at all or even though the platform's there because it's gathering that data and and publishing it in effect.

And in terms of also extracting I would say data, what we have and what we are rebuilding with IP Fabric is what we call the NetDB. The businesses, some part of them are not interesting in the internal of the network that we leverage that a lot as technical people using IP fabric network people and security people. But at the end people are investing on point whether it be user, server connected on the edge of the network. And we have an homegrown tool for that where we collect all the users information where they are, did they move, and we expose that to our business with a web application. And we are right now, for example, re leveraging the discovery we are doing before with IP fabric data fully.

And at the same time, we augment it with ice information. Right. So for those aware of BigGrid where you can in real time get decision out of the tool. So it's help us to have IP fabric discovery, but which are snapshot appointed time. And then between snapshot, we will leverage ice base grid for the dining meet part of the campus Sure.

To have more or less real time information. Not for everything that IP fabric is discovering, but just the host, which is a key part where people are interested. That's it. Being able to track where people are because otherwise you'd be trying to just constantly discover the network to track trace people through the network. Right?

And and I guess ICE is giving you the visibility of wired people, wireless people, whoever is connected to that, we're using that authentication to to connect. And not only this is also why we have we want to leverage, I would say, tools, but we also have to do on my development. For example, we have a cellular core, so we have private 4 g and Apryfabric is not able to discover private 4 gs. This is a specific technology and we use this information to get the client connected to private 4 gs and to get that. So you're combining information sources basically to give that complete view of all the aspects in the network and beyond.

Yeah. But this is not only limited to IP Fabric. When you have a large network often, the solutions have been offered are not fitting all the gap. So you may have to combine some of the things by yourself to get a real solution adapted to your needs. But what we try to do is as much as we can, reusing tooling.

And sometime, like we have done with the fabric, when you have homemade tooling before, when there is a business maintain solution, we use it instead of keeping doing your own. Excellent. So data, I guess I guess to some extent, it turns turns you into data scientists. Right? Because you're you're you're make bringing data together, combining it, manipulating it to present a service out to your customer effectively.

This is I will not say that as a test because I know them fine. They are still much forward. When you know the domain, as long as you progress, you realize there is still more things behind. But the way, clearly, is to have a more data centric approach. Leverage what you have.

And what I really appreciate in IP Fabric is a lot of time. Now I'm not spending time to getting the data Right. And spending time on analyzing them. Right. So I think which is also important to mention in the way we have changed the way we work.

I've noticed that often when I'm troubleshooting, before you were launching 6, 10 different SSH session on the different devices where you have the issue to try to troubleshoot them. Yep. Now the first thing I'm doing is going to IP Fabric, then I get the basic data, the graph, and so on. And I open the session to do the advanced troubleshooting Yeah. But only we have it.

I don't have anymore to follow a MAC address across the port channel, the shell, and so on. And we're doing that and we you troubleshoot at the end device directly instead of trying to get the information. Yeah. Yeah. I've yeah.

I I feel your pain on that one. That's for sure. So it's a it's good to know that that's not a part of your day to day activity anymore. Julian, do you have any sort of last things you want to share with us before we close or are you happy that? No, we have shared a lot.

Globally speaking, AgfaVic is a nice tool. It was not a perfect tool. We have worked a lot together to create feature request, bug face, But it's already, I would say, a key part of our 2 chain today, and we are, I would say, happy with it. I think the important point here is that, as a strategic partner, you're able to work very closely with the engineering teams and with the product teams to to help make sure, I suppose, that this is continuing to function the way you need it to to to develop all these new capabilities. Right?

One of the example we can say is, for example, since a long time, 1 year and a half, 2 years, we said also discovery time is too long for us. Yeah. It was something like 5 hour and a half, 6 hours sometime depending. And now with the latest release, we are now down to 3 hours, 2 hours 40. And do to the jobs that we have done together to say okay, how can we scale in a large environment?

How can we improve? And I know that you are working on even further improvement. Yeah. I think that's an that's an important point for the product team in particular. I get, a lot from working very closely with yourselves and with with our other strategic customers as well.

So it's a key part of that relationship. Well, listen, I think we're gonna wrap up there, but thank you very much for your time. Really do appreciate it. If anyone's interested in finding out more about IP Fabric, we, as I mentioned before, are on b 3 over in World of Solutions, opportunities to look at demonstrations and talk through some of the things that, that Julian shared with us today. Just wanna thank you for your time and hope you enjoy the rest of Cisco Live.