Automating & Validating OSPF Neighbors using Ansible

all right everyone we're back now with another demo using ansible for Network automation in the past I've talked a lot about ansible used for automation of configuration data and you know for a lot of folks out there this could be a bit scary to use any platform for automation right to make dynamic configuration changes across a data center campus branch what have you so in this in this video we're gonna look at leveraging an open platform like ansible to assist with automating configuration validation as well as automated troubleshooting so the scenario is as pretty straightforward we have two routers router one router two in this Ethernet segment of a network and you know so what we can do is if we were to the show IP ospf neighbor we see neighbors state is full and that looks like there is a BDR on that segment which is 10 10 20 120 which just happens to be router 2 now poor do show IP ospf neighbor we also see using the full state neighbor 10 10 20 110 that's router 1 you'll notice something a little bit off here where there's a BDR here and then nothing no drbg our other in the states so this is done purposefully and we'll look at this in just a second on what's really going on here you know as we troubleshoot this network so if we dive right in let's get to a batch prompts what we're gonna do is launch this ansible playbook which is going to you know assist in troubleshooting OSPF neighbor adjacencies so this play book called OSPF ops was pre created so I'll do now is execute this playbook well hit enter here so what we're doing is going to collect those PF data right so this first task in this play is to get OSPF acts this is is neighbor IP addresses and cue information timer network types everything we really need to diagnose a possible OSPF issue so we saw a lot of data come out here let's go back to the top real quick so we can see here we started the PlayBook up here we've seen the first name of the play collecting OSPF data the first task we've got our facts okay both router to router one and these happen in parallel so you know as number of devices increase it's still gonna take approximately the same amount of time to connect all the devices which is pretty great in a pretty sweet so if it's anywhere from 12 15 seconds to connect per device it's actually the same amount of time to connect to 10 or 20 devices as well so if we look at interface IP addresses used for OSPF peering here we see for router 1 the IP address on gig 0 0 router 2 IP address on gig 0 0 so right away we see ok they're in the same subnet that's definitely a plus is always PF active on interface yes so we validated there's there's some OSPF config on the interface process ID check what I'm doing here is just validating that at least the one process is running on the router so in a given requirement that this was a lot of production network you could do a query for a particular process ID that should be configured excuse me the next thing here is empty use so we see here both empty use are currently configured for 1600 so we have a match here network type ok look at this this is interesting so once configured as broadcast and one has point to point so this makes sense given what you know about OSPF network types where broadcast networks have dr SPDRs where point the point networks do not and same goes for timers which is in the next section here OSPF timers excuse me no SPF timers show as 10 seconds for the hello and dead timer is 40 seconds on router 1 and router 2 has no timers because it is a point-to-point connection interface status if we go back to gig 0 0 on each router this is the interface being looked at each one is up and up and display neighbors and state so here again we can see both are full and then you know we see router 1 trying to and trying to send hellos out there trying to form the our media relationships so we're going to do here is go to router to go back on the interface oh s PF network broadcast right we'll save that real quick you know give that time to your converged or what we'll do is just do a clear IP ospf process force this gonna give that give that a second look pretty good and what we're going to do now is come back up and we will rerun the playbook so again same the same process all the time right first step is always to get the OSPF x and as you can see real quick already as expected both network types are broadcast now timers match once the dr ones the b dr and and we're all good so the next the next phase is well you know how do we you know how do we help diagnose and fix problems automatically so what we can do is you know we could come back to router one we know the MT use are already set to 1600 so what we can do here is just come back here come to gig 0 0 set the MTU to 1500 so we're just gonna set that for now clear the screen rerun the playbook another time give this a few seconds to room as this runs you know we can think about what we're expecting to see and it's pretty straightforward not on what we're expecting but if we just scroll up you know we do see two MT use that are mismatched so we're displaying this data so in theory we displayed both MT use somebody could overlook that you know even looking at these debug messages so what we can do is is take the next step and take a second it to play add it to the bottom of our playbook to help diagnose the issue so I'll come back to this playbook and in just a second so we'll come back here we're gonna run this playbook again so this is a full automated workflow right now and you know going through in this playbook so the right now there's two plays the first play is the same play we've been running which is collecting the data and gathering the facts and displaying the facts about the device through debug messages the second play that was just added down here does something else the task is regards its name wanted variable shown in there but again we're validating em to use again down here we're saying router 1 m2 is 1500 router 2 is 1600 he were explicitly stating m2 mismatch and we're skipping a task called MTU batch because they don't match self-explanatory there but this last task and we could have stopped right here just after displaying m2 mismatch but I want to take it to the next level saying okay now we have to m2 use that are mismatched one is higher than the other so in the situation we're assuming we're gonna be deploying some sort of overlay technology over the wide area network over these routers right or just over this router in data in a data center right this is a theoretical you know a concept that we're talking about but the new MTU should be 1600 that's set so what i'm doing here is doing the auto reconfig of to you by increasing the lower MTU to be equal to the higher MTU value and it succeeded this is okay so if we go back to router 1 we previously made this 1500 if we do show IP interface gig 0/0 pipe include m2 u we see now this automatically changed back or change to the 1600 which is great right and if we were running playbook one more time this would actually be this would be skipped and this would show green saying they match all right so this so this really sums it up from an actual deployment perspective on on how an open platform that can be customized to any enterprise or any customers requirements how it can be done right so and this is the benefit of these newer types of platforms and tools out there that have off-the-shelf modules you know from ansible as an example and that just as easy custom modules can be built and reused over and over again without diving into actual code so if we look at the playbook we'll just take you know taking mini here to review it but this is the first play up top and the first play as we saw a few times already this is collecting OSPF data from routers there's two routers in this group a router one and router two and we're gathering OSPF acts from each device and this is the host name of the device taken from the host file and then in the host file there's also an interface specified which we should focus in on to make sure that it's in the proper States and to use and whatnot so we were specifying the device and interface per router and what happens when this module is run there's data that gets returned back to you know via via the playbook run and what I'm doing is storing that data and the registry got data in a variable called OSPF data so as you can see I highlighted OSPF underscore data and you can see every other place that we're using OSPF data so this is a variable you know it's a you know it's a hash or Python dictionary and the valuable that I returned from the PlayBook is actually called effects or OSPF acts for sure so it's PF data dot you know my dictionary dot the actual variable that we want to pull so the outgoing interface IP address outgoing meaning the outgoing OSPF interface then we look at is OSPF active on the interface does the process exist so we see these different iterations here and these are just things that I've built you know in this ansible fax I'm sorry in this OSPF fax module but the user who develops the module could could modify this one or it could add more data as mentioned earlier in terms of maybe looking for specific OSPF process versus just making sure at least the one is configured so the first play is really just a matter of gathering facts and then displaying you know a bunch of debug messages down here and the second play what's going on here is we're defining some valuables to use you know route is you know router one so we have to compare it to compare data from matter to again something and that's gonna be router one here and ultimately it really got the tasks what we're doing is you know we go back to if we go back to the run you know we saw this message here 10111 10 M T equals 1500 and again our two MTU 1600 that here is just the statement you know so these curly braces here just have variable names inside we're going to display MTU mismatch only when our one MTU does not equal our to them to you and we're gonna deploy into use match if they do match again straightforward and the last task down here is executing the automated change that was done for example to bring our one and you back up to 1600 so we're doing is using another to cuss the module called MTU and we're sending we're sending this module a variety of variables you know in order to you know figure out you know where do you configure the MTU and what settings to actually use but also we're gonna be using this module only when or one MSU does not equal our two in few so that's that's the high level of of this playbook and the overall idea to leverage automation platforms in general right now it doesn't it doesn't have to be ansible but this is just you know a bit you know it's fairly straightforward to get going but again just to show the concept of leveraging automation platforms for automated validation and potentially reconfiguration right so this is the tip of the iceberg in terms of you know we could have automated OSPF Network types and hollow timers and you know dead timers and things like that right if they were if they didn't compare or didn't have the same values so just automating the change of MTU is just to show the example on what can be done so that's that's all we have for you we'll have for you today using ansible for Network automation and validation hope you enjoyed it feel free to comments on the blog post associated to this video all right talk to you guys soon thanks

Channel: Jason Edelman

Views: 8,740

Rating: 4.9459457 out of 5

Keywords: ansible, automation, cisco, onepk

Id: RYFcpuCYBKk

Length: 15min 20sec (920 seconds)

Published: Sun Jun 08 2014