Skip to content 
Do you remember when you started your car today? Did you think if the ignition was working or whether the fuel pump was sending gas to the engine or were the pistons cranking, etc? No, you didn’t. Then, why the networking teams are dealing with thousands of operations, across hundred of vendors in a manual fashion, to support business intent?
Mike Lechner from F5 networks, faced a similar challenge when he had to scale their Silverline DDoS private cloud deployment. Mike evaluated multiple network orchestration solutions including Anuta NCX, NSO (from a big name vendor), Ansible and Puppet to solve this problem. Mike chose Anuta NCX because of its flexibility, multi-vendor coverage, scalability as well as excellent support from Anuta team.
Listen to Mike as he shares his journey of introducing network orchestration.
Podcast Transcript
Introduction
00:01 Welcome to packet pushes the data networking podcast that repeatedly, predictably and reliably arrives in your podcatcher every week. In spite of the fact that it is hand cranked and artisanally crafted and manually published. The topic of infrastructure automation and orchestration is the toughest topic to discuss. And for every single company that’s out there, the whole process of introducing automation and getting to the orchestration process is just different. There are so many people, there are so many areas that can be improved. It’s just a tough place to start. In today’s sponsored show we are talking with Mike Lechner from F5 Networks about his experience of Anuta networks NCX and how that’s been helping them to deploy network services. Now Mike is the manager of product development at F5 Networks and is part of a team that operates the cloud services that offer DDoS protection and web application firewall. And that’s become just a massive area of interest for enterprises for securing their internet gateways as the rise of security has made us all think. So let’s get straight into it. First of all, Mike welcome to the show on the Packet Pushers, thanks so much for giving us your time today.
01:01 Mike: Thanks, great to be here.
Intro to Silverline DDoS Cloud Infrastructure
So what don’t we kick it off very briefly. Why don’t you summarize what is this DDoS and WAF service that you are putting together for F5’s customers.
Mike: Sure, as you are aware and most of your listeners are aware. F5 traditionally has the BIG IP’s the load-balancer. And our focus is a little bit different on the security and cloud aspect. Our team, or department silver line. We offer the silver line DDoS protection and the silver line web application firewall. And the main thing with the silver line DDoS protection as taking that bad or dirty traffic for our customers and scrubbing it and returning it as a clean traffic to them.
01:42 So that means you’ve got a whole bunch of instances all around the world sucking in that DDoS traffic and doing the whole bunch of detection; that’s the scale we are talking about.
Mike: That is correct. Data centers distributed around the globe and advertise any casted out to get as much performance we can for our customers.
What role does Anuta NCX play?
02:02 And Mike you are working with Anuta NCX to continue to roll out this product.
Mike: Yeah, correct. So we have a service that is out there today and what we are doing is bringing Anuta in to centralize and help us orchestrate the service for our internal applications and pieces for customer portal and other internal applications to configure the service and the pieces that are required for our customers to; as we onboard and make changes.
02:32 Alright so we’ve had Anuta on the show and it has been on the show a few times over the years. We’ve talked to them about their platform. And mainly we focused on NCX as a tool that configures networking devices using the model based architecture. Is that what your primary purposes or is there more to it than that?
Mike: Well, the first phase of it is to abstract the business logic and the actual device like which device needs to be configured for a particular service. So we went down and took different work flows for different features and functions that we need to orchestrate our environment. And we put that into Anuta and used Anuta as the source of truth for that configuration data and augmenting services. So it’s like an API layer for us in our internal applications.
03:24 So it sounds to me like it’s almost like the core of your platform. You’ve put some portals on top of it and you ‘ve done some development around it but it’s almost like it’s a key part of that whole platform for you?
Mike: Yes, I mean as far as the network configuration, yes it is getting more and more there. And because what it is allowing us to do is take that kind of core functionality and logistics out of each of the applications. An example has been -which switches do need to be updated, which router configuration, which area. we can abstract that out and put that smarts inside Anuta NCX and then our outside application just have to say, hey, we need to deploy in the DC area. And then application doesn’t have to care what devices or switches or routers and things that are there.
Multi-Vendor Coverage:
04:21 Now Anuta NCX is a multi-vendor platform. Is that something that is useful to you? Are you really configuring lots of different devices out there?
04:27 Mike: Well multi-vendor is definitely something you look for in a product like this. As we are building out our infrastructure and as we built out our infrastructure, you still kind of focusing on some key players there. But they aren’t always the same vendor for every piece. Like you know our routers are not necessarily the same as our switch vendor. And who knows in the future, with new technologies and things of that nature if you need put a different vendor back there. It’s nice to know that you don’t have to code for that particular vendor.
Multi-Tenancy and Scale:
05:01 So you’ve got this situation where you’ve got a pretty substantial infrastructure, you are talking about taking a lot of load. Not only you talked about multiple-vendors but you also talk about multiple-regions. Now, two areas of real concern to me, which is multi-tenancy and also scaling quickly. Now those things that you’ve been able to look into and satisfy yourself with how that’s going to go?
05:22 Mike: Yes, so just to clarify one point. The service we have today is up and running. We are just bringing Anuta into help us gear up for the future. And putting Anuta in place; what we see is that because you take some of the current applications and let’s say, they are currently doing the device configuration. But say you have more than one application, so now who really owns that configuration. Like are they both caching the information? As far as configuration; so the immediate impacts we could see is if we use Anuta as a source of truth and we can roll out agents to each of the data centers to talk to the devices. It’s a lot more quickly, right because they are local. But then instead of each application having to go to get that status because everyone is making changes and doing things. We can just query Anuta and get that status right from there.
Why Buy from Anuta?
06:21 So then it really becomes like a key App. It becomes like a backend system, I imagine you got back some other systems like it. This is a fairly big and complicated system. So you probably have a few different things in there, some of which are self-developed and some of what NCX is doing for you. So why would you buy NCX considering alternatives. I mean what other alternatives did you consider and why buy NCX at the end of the day?
Mike: Well, I mean that’s a great question and the first two pieces are, you know do we actually need to by a third party vendor . Could we just build this ourselves? And that evaluation happened, but orchestration is tricky. And so for us we look at our department and decide if it’s the best use of our time. And it was determined that it wasn’t. So then we go out and look for vendors. And our initial choice was actually a different platform from one of those other big vendors out there. And by the time we prioritize projects and the project got funding and everything else for that, we found three other competitors to that product. So it was really in our best interest to re-evaluate at that point. We were able to rule out the first two very quickly. But Anuta was different and it kind of bubbled up on a radar. So then we really did some good analysis and thought that this was a solution to go. Now obviously being a little risky, right because they are not as big and not as well-established there. But basically what the product was and the way that it’s built and the way that it fits in our organization was great.
08:01 So when you went through the process you would’ve also gone through I’m sure the consideration of build or buy, right. Still how much development are you doing yourself and how much development have you saved by going straight to a pre-built platform like Anuta NCX?
Mike: So you are right, we still have to do some development. And actually that’s another thing, we had to outweigh the cost. We could have gone to Anuta and said, hey professional services, here is we are going to build and go and do it. But we decided a different approach. We really wanted to scale up on the product and learn how it works so that we can kind of control our own destiny. So that required a little more on the front-end but was definitely worth the risk.
On Yang Modelling
08:41 That leads down to the discussion where; one of the big things we are talking about in Modern Network Orchestration tools is this concept of model-driven architecture. So you have a model, where you create it and then the Yang models that tool chain that you use to be able to handle the devices. One of the questions I always like to ask people. Did you have people problems introducing this model-driven type orchestration system?
09:04 Mike: No and actually Yang modelling was new to me was new to the team. But really when you start looking at it, it’s not that tricky. Very similar to XML and some of the other mark-up languages and what I really liked about Anuta was they provide this NDK/SDK piece. And while it is an appliance and kind of a black box. The NDK really exposes you to lot of like existing models. So it’s really easy to kind of investigate and look on how things are modelled; whether it’s different, service types or different objects. And so the learning curve was pretty easy with that. And then using the development kit and putting in models was easy to kind of test those things out and go. But we definitely spent a lot of time on focusing and trying to get our modelling right to begin with. Because going back to the development piece, if you can get the Yang models really good, a lot of the SDK can generate a lot of the code templates and the module templates for you that just allows you to focus on the business logic piece. So it definitely eases in development.
10:16 Does that shift from device-centric networking or packets through the devices or network itself to standing back and doing the model? Has that transition been really powerful for you? Has it been simple enough to achieve? Would you give anybody some advice about how to approach that model-driven architecture and how to start thinking about that?
Mike: Sure, I mean the approach that I took was more of the service type model, right. What are we trying to provide? And again we were balancing it out of; do we want to build like 1000 different models and then have the application piece apart together? Do we want to build this one big monolithic model that handles all of our configuration? We kind of settled on the middle which was what really defines our service. Like if you are creating a customer or you are adding a customer endpoint or things of that nature. So abstracting the actual device stuff out and just providing like these API calls and then the way that you put them on dependencies and you actually hook service models to each to make sure that their dependents for your applications don’t have to worry. You can tell them here is the order but if they choose not to do it, we can still check it and slide service model pieces there. And so that’s the approach that we took. But more of what service are we providing and we look at all of our internal teams as customers. And so it’s like what is going to make it easy for them? How can we sell it to them to use this product? So we try to make it as easy as possible.
Why not Puppet/Ansible?
11:54 So a lot of people have talked to us about using Puppet and Ansible to do their configuration and to do their automation of the network configuration. But it sounds to me from the way you are looking at it, you are saying, I’m configuring an entire service. And if you had actually gotten down into this writing code like python for Pupper/Ansible of getting this device, you might not have actually gotten to your service problem like; from the way you are talking, you just focused on the business aspect.
Mike: Correct, so you are right. You could spend a lot of time in doing this but you are still; it’s like someone has to do that business logic. Whether it’s the outside application or where we chose to put it inside the Anuta piece there. So again to make it easy and friendly to use for these other applications. It is really extracting as much of the topology in the network as possible. You know using like a puppet or Ansible sure you can configure the device but you still have to be aware of the devices and all the things that go along or which steps to take. And that’s where we kind of try to abstract that out in this orchestration. Because to me Puppet and Ansible are more of, how do I configure this switch or server or something like that. It just stops the repetitive task. Or orchestration – I’m saying hey, I want to add widget A. Who needs to know anything about widget A, and that’s where like Anuta comes in for us.
Organizational Challenges?
13:14 So when you are building out these models, is this a kind of a cross-organizational effort, or is it just – I need the networking group for this and then the application group for that? Does everybody gets at the table the first time around and say, let’s talk this whole thing through?
Mike: So my approach was again looking at all the different teams as customers. And some customers in this case are a little more I guess priority than others. So I really looked at the networking team as being priority A customers. Because they are the devices, they are the ones who are getting called in the middle of the night if there are problems and those types of pieces. So I really focus on them first. And it was good because I’m not a network engineer by trade but I do know enough to be dangerous. So in talking with our networking engineering team, so what I had to do was kind of get a feel for; you know they have what needs to be configured and why. But I have a unique perspective because I’m not a networking engineer. So in working with the networking team I had a different perspective where you know I’m not sure how all the pieces fit together. So I ask different questions and things to look at it from that service way and build it out and try to map out dependencies and stuff. And that’s what was really key for us and how we determine what service models to build. Because you know you are looking at things like, well, if I delete this piece, I want to make sure I don’t delete other core pieces that things are responsible for, right. That are hooked into other models. So we kind of look at all those dependencies and things like that and kind of really craft it out; this is a service and that’s a service and it’s really easy to look at this service model here for a dependency if that makes sense.
The Car Analogy
14:57 Yeah I think so, I think that what you are saying, if I turn that into nerd speak if I can have a go at it, you kind of got the NCX platform. And it’s got all of these models and it’s got Northbound API’s and it’s Southbound API’s. And you’ve got all the models and the pieces in there. And because it sees everything as YANG and just basically you are saying, go and do this to that device. It goes off and does it for you. So all of a sudden you are not sitting there and thinking to yourself, if I get in that car I’m going to turn the engine on and then the Pistons have to work, and then the fuel line has to pump and blah-blah-blah and all that. And that’s pretty much what you are doing when you use manual automation like Ansible and Puppet. You’ve got to think about an awful lot of those steps yourself. But Anuta, kind of takes that away from you because you just have to say, oh, I’ve got a cisco device or juniper device or an F5 device, whatever it is in the network, there is an YANG model for it. If I want to do this to it, it just self-generates the code for you and goes off and does that. And kind of that leaves you free to start thinking about, well, if I did this and put this in, then I can run this service flow. Am I reading that right?
15:59 Yeah, absolutely because the focus is not on what commands do I have to run on the device. It’s like what are my rules for actually doing this configuration? So example, is like you go to add a customer, what’s the first step? Well, the VLAN for a customer needs to be populated on all of the devices in the network; all the edge let’s say. And so if our portal application has a new customer, it says add customer XYZ and then it doesn’t know what devices, it doesn’t know what data centers, it just knows at that point the VLAN is everywhere where it needs to be, and every other step. But then from my layer in using the SDK I can say, well, here are all the devices that we do configuration. It’s a layer 3 interface and we add this VLAN on and by magic, the VLAN gets added in all the right places.
17:02 This to me is the shift, right. This is the shift away from doing something in CLI where the human had to translate the business intent into arcane mystic code that came out of their fingers into some command line, to moving towards the first step of automation which is ansible and puppet, which is actually all a lot of people can actually manage to achieve. Because you can only make small incremental changes. But if you can start to imagine an orchestration system like NCX which has the portals and the models and does a lot of that work for you. It seems to me like you just automatically stand right the way back from the actual network itself and you are really focused on just getting the regions setup. The tenancies are already configured. This thing happens, that thing happens, you can do the configuration checks and validations and dependencies check to make sure that things; because that’s all taken care of in the NCX platform.
17:55 Mike: Yes, and it’s actually making the network and the devices like another application right and it’s putting that API there that other people can go with that doesn’t have to worry about, do I SSH and CLI these commands. VLAN add, it just add it – and it’s all abstracted.
Role Based Access and IPAM:
18:17 It’s all abstracted. I wanted to just ask some questions about the Anuta solution itself. As we were chatting before we came online, we talked a little bit about the role-based access control model and the IPAM. Was there something about NCX that really caught your eye or your attention there?
Mike: Yes, so one of the things with the Role Based Access, obviously you can set up users and permissions for the UI itself. But the access controls are very flexible. And so when you are designing your API’s and exposing them, you can apply the same model to those API’s as well. So you know making a set of read only calls or read and write calls and those things based off of the service models that we’ve developed ourselves. It’s super configurable in that way. Everything from the product itself is basically like a layer of API’s and you are able to control any portions of the roles and access and stuff and any portion of the product.
19:16 So I think that’s important because you are building a multi-tenant system that is going to be administered by a central party. You really need to know that, that system right out. It’s going to be integrated into other pieces in your particular situation. And it’s going to be flexible enough. What about your IP address, are you managing that from NCX too?
Mike: So today we are not. So the first phase that we worked on is putting this [for a lack of a better term] I’ll put the abstraction layer. Building NCX is for the applications. But you are right, at that point, if we have one application here that’s managing our IP Addresses or even our VLAN pools for there. It’s like why do that? And so our second phase is to abstract that away from our customer too. So if our portals says we are going create this customer and that requires a unique VLAN, why do they have to send it in. We’ll just do it for them. So those pieces with IPAM, VLAN pools and those pieces, again put those in control of Anuta so the applications don’t have to worry.
Lessons Learned:
20:18 We are getting toward the end here, so I want to sort of wrap this up a little bit. Now if you are talking to somebody who is going to take on an NCX platform and an orchestration project along the lines of what you just talked about here. Have you got some lesson that you’ve learned that maybe you would like to pass on to somebody who is getting into this space?
Mike: Sure, I mean the very first lesson is, the network orchestration is not easy. So if you choose to go out on your own, be prepared. Then after that, really focus on take the time to really look at what you are really trying to build and design. Again we took the service model approach and what we are providing as a service. So it really takes a lot to take that time upfront. And defining your Yang models for your services. Breaking out like what your services are and the dependencies and once you have a clear vision there, it makes development much more quickly. But that’s almost like any project you are going to undertake, right. Initial planning really saves a lot in the long run.
21:23 Well, I think the challenge with the orchestration is that there are too many choices. In the sense that you could take it in many different directions. You could model services in different ways, and then a lot of these modelling systems allow you to do things that you’ve never done before. All of a sudden you start thinking, well, I could do this and I could do this. There is too much flexibility and suddenly you get lost into what was I trying to achieve, rather than actually, this is what I’m doing sort of thing.
21:48 Mike: Sure, and that’s why your goals in advance of what are we trying to solve here? What we are trying to solve, just definitely keep the focus on that. We try to do it in an iterative approach, solve the problems and all this would be cool to investigate right. And so can we do this, can we do this other feature? And so definitely add it but stay focused on your core.
On working with Anuta team:
22:16 So the thing I find interesting about your NCX deployment is that it is very distributed. You’ve got multiple data centers, multiple sites, very customized in the sense that you are scanning across lots of different hardware devices in the southbound. But the services you are building at the top are reasonably diverse as well. How have you found working with Anuta, Because this could be a really difficult thing? There is an awful lot of elasticity in there. And when you’ve got a vendor who is like, here is the product, let’s you on you alone. That’s not what you need.
22:49 Mike: Again when we looked we knew we had two things. If we just wanted a product and we wanted something to work tomorrow, we know that and working with Anuta, we could utilize professional’s services and we could get what we wanted. But that doesn’t work in an on call arena where I’m getting calls at 3 A.M. and I’m not sure how it works. So it’s like, oh, wait I’ve got to call my vendor. So we made the choice of taking the investment and learning the platform. Now the thing that I loved about the platform is, even though it’s an appliance delivered in a VM in somewhat of a black box. It’s still really open especially with the SDK; the NDK they call it. And so with that, not only, it’s pretty much an open book at that point as far as configuration and how things work. But you still have the ability to expand on devices. Let’s say, maybe a fully featured command set was not fully supported right now at this moment, I can go ahead and fix that and I can expand it myself on top of the product that’s delivered. And then if it is something really useful I can feed it back to Anuta and they can include it for everyone. Or if there is not a device, say we have our own device and it’s not supported by Anuta, I can actually write the templates and things to support that device as well. So we’ve got a lot of flexibility there. And spending the time and learning the platform and the product will really reap benefits for moving forward and the things we want to do. We don’t have to rely on anyone else to move our agenda forward.
Wrap Up:
24:31 Well, Mike I think that’s just about it for today. I don’t think I’ve got any more questions to ask you. So thanks very much for your time and I really appreciate it. Have you got anywhere on the internet where people can find you? Do you blog?
Mike: Well outside of Twitter and LinkedIn, you can find me LechnerMike on Twitter and on LinkedIn but not anything with blogs or anything like that.
24:56 Well Mike thanks very much for joining us today and thanks to Anuta networks for sponsoring today’s show. I’m talking a little bit with customers about what they are doing on the NCX platform. Now you can find this and many more fine free technical podcast along with that community blog at packetpushers.net. You can follow the packet pushers on Twitter @packet pushers. Find us on LinkedIn, like us on Facebook, write us on iTunes and a range of other fine activities. And last but not least, remember that too much technology would never be enough.
