Hands-On Challenge: OSPF Troubleshooting

[Music] hey everybody this is kevin and in this week's video we're going to try something a little bit different specifically i want you to get actively involved in troubleshooting an ospf topology now how do we do that well do you remember last week's video i showed you how to get free access to cisco modeling labs or cml out in the cisco devnet sandbox or maybe like me you've got your own copy of cml running on your machine however you get to cml it doesn't matter what i have for you in this video in the description specifically i've got a zip file and i want you to download that zip file and extract it inside you'll find an ospf troubleshooting dot yaml file that file can be imported into your copy of cml or the cml that you're using for free out at the cisco devnet sandbox and we're going to show you a video from our anarchy course where we're doing some ospf troubleshooting and you're going to see a topology and it's not working none of the routers have formed ospf adjacencies and we haven't learned any routes and your mission should you choose to accept it is to fix it where every router has full reachability across the network and you're going to pause the video do it on your own resume the video and then i'll walk you through the complete solution where we troubleshoot everything and we get everything working perfectly now let's go out to cisco modeling labs just for a moment and let me remind you how you can import this file we talked about this a bit in our video last week and i'll leave a link for that up in the corner of this video if you missed it but in cisco modeling labs you're going to go to import lab and you'll say browse and you'll be browsing your local machine and after you extract that zip file that i told you about again the link is in the description of this video you're going to find this ospf troubleshooting dot yaml file so we'll import that and we'll say upload topology and then we'll go to lab and here is that topology so you'll just go to simulate you'll start the lab and when it boots up it's going to have configurations in place and each router has an ospf configuration but there are issues nobody is forming neighborships and i'll show you the topology in this upcoming video that we're going to attach and you're going to go out and fix it on your own and if you enjoy this please let me know it's the first time we've tried something like this where you're getting actively involved if you enjoy it please leave a comment down below and as always please do me a favor and if you enjoyed the video click like and subscribe so you don't miss any of our weekly content now let's go check out this ospf troubleshooting lab from our anarchy course good luck in this lab you're going to be troubleshooting an ospf topology we've got three routers we've got a couple of areas you see that router r2 that's our abr and currently none of our routers are learning any ospf routes so your challenge is to visit each of these routers take a look at the existing ospf configuration and make any corrections necessary so that each router has full visibility to all the different networks and at this point you might want to pause the video and if you've not already done so you want to upload the yaml file for ospf troubleshooting into your copy of cisco modeling labs or into cisco modeling labs available on the cisco devnet sandbox once you get that up and going then you can go to each of these three routers and troubleshoot the configuration then you can resume the video and we'll walk through the solution together let's take a look at the configuration for each of our routers let's verify first of all that we don't have any knowledge of routes learned via ospf i'll do a show iprout and it looks like we've not learned anything from any routing protocol let's do a show ip protocols command let's verify that ospf is indeed configured yes indeed we've got ospf process id one let's take a look at our running configuration in fact let's just zoom down to the ospf area here we see that gigabit zero slash one is a passive interface is that okay yes if you take a look at the topology gigabit zero slash one it points out to switch sw-1 there's no need to send ospf messages out of that interface or receive ospf messages on that interface because there are no ospf neighbors off of that interface we've only got one network statement is that a problem not necessarily this one network statement is causing a gigabit zero slash one to participate in this ospf writing process but if we take a look at the other interface we've gone directly into that interface and said hey we want you to participate in ospf process id 1 as a member of area 0. so it looks like both interfaces are participating and if we jump over to router r2 and do a show ip protocols command something you might have noticed is that instead of saying ospf 1 here it says ospf2 is that a problem no unlike eigrp this is not an autonomous system number this is a locally significant process id they do not have to match between routers so that is okay and something you might have noticed on r3 if we do a show run pipe to section router ospf you might have noticed that we had this network statement that didn't really seem to specify a specific network connected to r3 but remember what the network statement is doing the network statement is saying here is an ip address space and any interface whose ip address lives in that address space we want that interface to participate in ospf and what that means is we want to advertise that interfaces network along with that interface's subnet mask so here we've got a network statement that encompasses all possible ipv4 addresses so yes both of our interfaces have ip addresses that fall within this address space of all possible addresses and that's going to cause both interfaces to participate those are some things you might have noticed now let's see what is not correct about this configuration in fact right here i think we see a problem area if we look at the topology we see that we do indeed have an opportunity to have a passive interface but it would be off of gigabit zero slash two on r3 it looks like this has been mistyped we have a passive interface off of gigabit zero slash one that's going to prevent a neighborship from forming between r2 and r3 let's fix that let's go into router configuration mode for ospf process id 1 and i'm going to negate this passive interface command and let's put in a different passive interface command i'll say passive hyphen interface gigabit zero slash two and we might have an adjacency come up with router r2 unless something else is going on which is totally possible in fact let's take a closer look at the entire configuration and make sure nothing looks suspicious we've got interface gigabit zero slash one all that looks good gigabit zero size two all that looks good our passive interface is gigabit zero size two that's looking good as well let's go over to router r2 in fact let's see if we're in the process of forming a neighborship let's do a show ip ospf neighbor command nope no neighbor yet can i see my neighbor let's try that show cdp neighbor i see both neighbors so i've got physical visibility or physical connectivity to those neighbors so that's good what else might be going on let's take a look at our interfaces let's do a show ipospf interface gigabit is zero slash one and we see its network type we see its timers anything suspicious here i think there is i think the default timer for a broadcast network type is 10 seconds i think we're set to a non-default value here oh and also notice that we're a member of area zero here and if we look at gigabit zero slash two we're a member of area one ah so if we look at our topology we see that r3's interfaces should be a member of area one i think they were set to area zero i think that's another issue so let's fix both of those issues we've got a timer issue and we've got a mismatched area issue first let's go back to r3 and sure enough look at this i'm saying that that network statement is putting interfaces in area 0. while the 0.0.0.0 hall that's fine the area's wrong so let's get rid of that i'll say router ospf 1 and i'll negate that network statement let's do a copy paste and let's put it in specifying area 1 network 0.0.0.0 with a wildcard mask of all 255s this time we'll say area one and hopefully we'll have an adjacency come up and while we're waiting on that to happen let's go over to router r2 and fix that timer issue on that interface pointing over to r1 let's go back to r2 let's just confirm that we do have a non-default timer configured and we do it says ipo spf hello interval 20. let's set that back to the default which is 10 seconds and if i'm unsure of the default i could say default ip ospf hello interval and that should put it back to 10 seconds let's see if it did let's do a show ipospf interface gigabit zero slash one and when we put it back to the default it did indeed go back to 10 seconds let's see if we're trying to form any neighbor ships now let's do a show ip ospf neighbor command it looks like we're working on it looks like we have formed a neighborship with r3 and it looks like we're working on one with r1 let's do a show iprout have i learned anything yes i have learned about the 172.16.1.0 network that's the network hanging off of r3 going over to switch sw2 so we've resolved that issue but it seems like we still don't have a connection with r1 and notice the state that we seem to be stuck in is this x start state often times when you see that x start state let's see if we still have that we do we're not transitioning through it we're kind of stuck there eventually it'll probably time out and just say we're down but if we're stuck in that extart state that often indicates an mtu mismatch so let's check out our mtu configuration for gigabit zero slash one i can say show ip interface gigabit zero slash one that'll tell me the mtu it says the mtu is the default of 1500 bytes what about r1 what about the other end of this link let's go to r01 and we'll do a show ip interface gigabit zero slash two and it has i'll look at this it has a non-default mtu and we got a hint that this is what might be going on by having our neighborship stuck for a period of time in that x-start state so let's take a look at our config and what caused this let's do a show run let's take a look at gigabit zero slash two yeah it looks like we've set a non-default mtu so let's fix that let's go into interface gigabit zero slash two and i could either say ipmtu 1500 or i could say default ip mtu either one would work so let's set this back to the appropriate mtu value and see if we have an adjacency come up here in a moment let's do a show ipospf neighbor and it looks like we have a neighborship that is great news in fact let's go back over to r2 and make sure it knows about two neighbors let's do a show ipospf neighbor command ah great news we do have two neighbors this is r1 this is r3 and we have fully established an adjacency so let's go back to where we started let's go back to r1 and make sure that i have full visibility throughout the network i should have learned about two routes via ospf i should have learned about the 203.0.113.0 30 network between r2 and r3 and i should have learned about the 172.16.1.0624 network off of r3 going over to sw2 let's confirm that let's do a show iprout great news we have indeed learned about those two networks and we see the ia code that indicates that they live in a different area that's because we're currently in area zero while those two networks they live in area one now let's sum up some of the issues that we ran into one thing is we specified an incorrect area so if you have a multi-area network we need to be really careful that we're specifying the appropriate area as part of the network command or as part of the ipo spf command in interface configuration mode we also had a non-default timer and we have to have matching timers with ospf we had a passive interface applied to an incorrect interface we had it applied to an interface off of which we did want to establish a neighborship and finally we had a mismatched mtu and we were stuck in that x-start state in our neighbor formation for a period of time and oftentimes that does indicate an mtu mismatch and that's a look at a troubleshooting scenario for ospf [Music] you

Channel: Kevin Wallace Training, LLC

Views: 10,425

Keywords: cisco, CCNP, CCNA, CCIE, ospf, ospf troubleshooting, troubleshooting ospf, cisco modeling labs, cml 2.0, cml, 200-301, 350-401, 300-410, #kwtrain

Id: uniK3_OtXCE

Length: 14min 18sec (858 seconds)

Published: Tue Jun 30 2020