83 IPExpert Supplemental Strategy Part 1

[Music] as you might know CCA routing and switching exam consists of two separate sections so we have two sections of the exam and I do apologize about my handwriting unfortunately you're going to be stuck with it because apparently I have not learned how to write properly in my school now the first section that we have is the dedicated troubleshooting section and after that is finished you're going to be faced with the configuration section now the characteristics of the troubleshooting section is that it is a maximum of two hours long in these two hours you will be faced with ten to twelve tickets and you need to solve at least 80% of the points assigned to the tickets now usually this is the official information from Cisco a little bit less official information from Cisco is that you are actually going to have ten tickets in your troubleshooting section now these tickets are going to be ranging even in point value between two and three points most likely layout of the troubleshooting section is going to be that you're going to have eight tickets that are two points and you're going to have two tickets that are three points giving you the total of twenty-two points now 80% of twenty-two is seventeen point six now if you want to pass the exam you need to get seventeen point six points now this is a little bit difficult because if you take a look at the layout of the points let's say that you have your ten tickets one two three four five six seven eight nine ten and let's say that the point value here for the tickets is let's say 3 2 3 2 2 2 2 2 2 in order to pass the exam if 17.6 is indeed the passing mark if you don't solve this 3 pointer and this 3 pointer here you cannot pass the test because you're going to be below the passing mark the same is true if for example you don't solve the 3 pointer and this 2 pointer you are going to be below 17.6 mark this is why the actual passing mark for the troubleshooting section is going to be 17 points so you need to get at least 17 points on the board solved correctly in order to pass the lab again this doesn't really make lab much easier because in this case if you get a three pointer and a true three pointer that you missed you will be passing the lab but if you miss two three pointers you are in trouble because with two three pointers you are below the passing mark for the troubleshooting section so the statistics are not on your side you have to solve at least one of the three pointers now thinking about it what do you think is the difference between the two pointers and the three pointers in the lab is it the level of difficulty or is it perhaps something else I am seeing the answers being typed so let's take a look at those answers Jim says is number of changes well number of changes or let's say I like to word it a little bit different differently it's the number of faults so for two pointers Cisco says it is going to be a single fault that you will be dealing with now for three pointers Cisco says it will be two or more faults now the definition of fault is somewhat vague what could default beat well in one case a single fault could be just let's say a mismatched password on one router in some cases in some case it could be a mismatched password or password authentication on multiple routers but it's still considered to be a single fault now when we talk about two or more faults that means that whatever was written in the ticket whatever is the technology that is having challenges whatever the problem is there is more than one thing related or unrelated that is preventing this from working now it could be something along the lines of let's say you have a couple of routers connected to the VLAN to the switch and somehow switch or the villain assignments there are misconfigured but then on top of that those routers are supposed to be running let's say er GRP and then e IG RP is misconfigured which in turn prevents let's say hosts 1 & 2 from communicating with each other so this would be an example of for example a 3-pointer ticket now please don't fall for the trap thinking that two pointers will be easier than three pointers that may or may not be true now usually this is the point where I'm going to give you an example so give me just one minute to prepare for the example I'm going to stop the video for that and I'm going to come back with an example I'm going to give you an example of a two-pointer ticket that in my opinion on a level of difficulty from one to ten is somewhere around 15 we're going to go through this one example where I'm going to show you a two-point ticket that in my opinion is rather difficult so here is the topology now the topology here consists of four routers we have r1 r2 r3 and r4 as you can see on the diagram r1 r2 and r3 are running OSPF in area 0 and r4 is somehow outside of this domain so I'm going to go here to my terminal and I'm going to connect to a router 1 going to connect to router 2 going to connect to router 3 and router for and the goal of this task is very simple what we want to do is we want to loop back of our 1 to be able to ping the looped back of our 4 in other words we want the communication between this loop back and this loop back here so let's go on r1 and take a look at what's going on so if I go to r1 and if I do show IP route I'm going to see that I actually do have the route for my loop back in the routing table if I try to ping this look back I'm getting destination unreachable so you can see here that I'm getting that unit without you ok fair enough can our for rich r1 so I'm going to go to our 4 and if I do show IP route I now see how our 4 is connected to the rest of the network I can see here that we have the gateway of last resort sent which means that we do have the default route we can see that this route here is a static route so this is how our 4 gets back so if I try to ping r1 when I try to ping I'm getting just the dots so I'm not even looking unreachable at this point so moving onwards with our looking at what the problem could be if I go to r2 and if I do show IP route I can see here in our twos routing table well actually I don't see it but there is no route for our force loop back on r1 I have it in the routing table on our - I don't have it in the routing table if I go to r3 and if I do show IP route I can see that I do have the route in the routing table it's a static route and from r3 if I try to ping our four it seems to be working so a natural assumption here would be to think is r3 that has a static route to a our four and I mean it's it's logical here we have our three it has a static route to reach our fours loop back because our four is obviously not running OSPF and our four has the default route back so we do have some reach ability there so it's a natural assumption to think okay is r3 actually distributing this route into OSPF so if I take a look at show run and router OSPF I can see the tie in with distributing static routes so why is it then not showing up on our - in routing table but it is right here in our ones routing table any thoughts anyone has an idea what the problem could be here if you do have an idea right in chat filter list on our - okay that's very good now filter lists would be configured in an OSPF process so here is the OSPF process it doesn't have any filter list configured and if I do show run include access list I'm getting nothing if I do show run include prefix list I'm getting nothing if I do for route laps or policy maps anything that can remotely do any filter on our tube nothing's there the tunnel Hey there are no tunnel interfaces configured because we would see them somewhere in the routing table and here we can see that there are no tunnels it's all serial interfaces at least on our one on our two again we are seeing just the serial interfaces and the loopback so there is really nothing of the sort now one thing that I noticed there is a comment that says LSA is propagated to r1 r2 is filtering the route from its own routing table very very good so LSA has made it all the way to r1 and here it is it is in the routing table of r1 but what could be preventing this LSA from going into the routing table of r2 this is as I said very very challenging problem it's it's going to go very deep and at this point I don't expect you to actually be able to solve it this is more of a warm-up exercise to you know get the brain going so let's see how far you actually get with it if you want me to run some command or if you want me to show you something please let me know if not I'm going to show you what the problem is or I'm going to continue troubleshooting it until until we fix it even though I'll have to pretend that I don't know what the problem is but I will follow the step so what I think is good troubleshooting which is incidentally something that I will be talking about next what is configured for OSPF on r2 well as you can see it's basically just the the network statement nothing nothing more than a network statement what is configure r23 so let's take a look at that well as you can see it's roger OSPF two network statements and redistribute static subnets to get that one static route into the OSPF some type of a null road problem well if it was some kind of a null road problem we would be seeing an out route somewhere in our routing tables and here is the routing table of r3 and again as I said your own interfaces that we see are serial and Ethernet interfaces here on r2 if I take a look at the routing table only cereal and loopback interfaces and here on r1 pretty much the same problem so let me troubleshoot this for you on our one we have the route in a routing table and as expected it is an external OSPF route on r2 we do not have the route in a routing table so my initial thinking here would be ok let's take a look at the OSPF database let's see what the OSPF database is going to tell us about it's rap so if I do show IP ospf database on our tube I'm going to see the LSA in the OSPF database now this is something that I expected to see because how else would r1 get this route if our two didn't flood this LSA to it but what is preventing this LSA on r2 from going into the routing table to answer that question I actually have to take a look a little bit deeper into this LSA so if I do show IP ospf database external this is the LSA that I'm seeing and one of the things that should kind of stick out is the forward address I do have the forward address here which says 192 168 34 4 which is nothing unusual because if I take a look at the diagram this is actually the IP address on our 4 here on this link so it kind of makes sense that this is the forwarding address but there is a problem with this because in OSPF the forward address is not always going to be installed so here is where this ticket becomes really difficult the OSPF forward address and mind you I will talk about this in much much much greater detail when I actually talked about OS beer from a technology standpoint here we are just looking at the the troubleshooting your example is it an example ticket of what you might encounter in the lab and what would I consider to be a very difficult layer very difficult to point ticket so from OSPF perspective the theoretical knowledge of OSPF the forward address is always going to be present in an external LSL in the case of the NSS a area now this is OSPF area 0 area 0 is not and cannot be a stub area or the NSS a area it is always a regular area which means Y is then the forward address installed this is where the difficult part begins the OSPF forward address will be installed on an external LSA in a non NSSA area if an outgoing interface for the redistributed external route is enabled for OSPF the next cop is known by OSPF and the interface is not passive and is non broadcast or broadcast network type okay a lot of things to remember but as I say I will go about this in detail when we talk about OSPF so let's take a look at this interface here this is our three it's our three who is actually redistributing the static route into the OSPF this is an internet interface which means by default it is broadcast network type now we can see here on the diagram that there is this blue thing around this interface which leads me to assume that OSPF might actually be enabled on that interface and if I go to r3 and I say show IP ospf interfaces breathe I can see that on Ethernet 0 0 OSPF is indeed enabled now mind you we have zero neighbors on this interface but that's irrelevant because OSPF is enabled on this interface and interface is not passive if I take a look at show run pipes action router OSPF I don't see any definition of the passive interface which means that this interface here is non passive now by virtue of OSP have been enabled on this interface if I take a look at the static route that actually injects this route it says 192 168 34 4 which is part of the sublet that is enabled for OSPF the next hop of the external route being redistributed is known by OSPF this tells me that the forward address will actually be installed on this LS l so this is the reason why r3 installs the forwarding address on this LSA now that we have actually understood this if we go to r2 and take a look at r2 why would this cause r2 not to install this route in the routing table all this LSA in the routing table when r1 here or SPF database external has the exact same information and this is one of one other thing with OSPF they are in the same area therefore their databases would be identical so here on our one I have the forward address and I do have the route in the routing table but not on our - well that must mean that something is wrong with a forwarding address on our to itself so if I do show IP route this take a look at this entry here it is here that route 182 168 34 4/32 is known as a static route so there appears to be a static route on r2 causing this route to be installed in a routing table and this will override RTC I don't have it in the history so even this would override this slash 24 route to reach the same led to reach the forward address now mind you this does not cause the route or the forward address to be unreachable I can still pin it there we go no problems this causes OSPF not to trust this route now this is another rule of OSPF if OSPF router receives an LSA an external LSA that has a non zero forward address this address in order to be used must be must be known by OSPF show IP route 182 168 34 4 on r2 shows us that there is a static route on r2 that makes the forward address reachable now as I said one of the rules for forwarding address is that in order for this LSA to be used when it has a forward address that is non-0 is that the forward address is known by OSPF in our case forward address is not known by OSPF in the routing table it is actually known as the static route when we have this situation the OSPF cannot trust that this route is loop-free therefore it cannot use this LSA for routing so this is what is causing this route not to go in the routing table on our - that's fine but how do we fix it well to fix it we have to go back to this list of things if this interface is broadcast the route or sorry the forward address will be installed but if it's not a broadcast interface or non broadcast it will not go in there so making this interface for example point-to-point will solve the problem so would be this turning of OSPF on the interface so would making it passive well next-hop known by OSPF is not something that we can actually change because that would actually involve changing or removing the static route for 4 4 4 4 on r3 there is another solution and that is taking this static route that we have on r2 and actually removing it from the routing table now one of the big things that I have with many of my students going to the CCRI lab is that they think that this would be a valid solution oh let's just remove the static route and be done with it or an alternative solution is oh ok so this static route is causing me the problem let me change the admin distance on it to be 255 effectively removing it from the routing table every time when you have this solution in mind oh let me remove something let me make something disappear you are probably on the wrong track as far as the exam goes because in the exam you need to correct the underlying issues without removing any of the configured features now one of the configured features in this situation is the static route on r2 that is our problem so we cannot remove that what can we remove well if we take a look at our diagram here our r4 is not running OSPF so anything that we change on this interface on r3 is not going to make any difference from the perspective of r4 so even though OSPF is turned on even though the interface is actually broadcast any of these changes would make no difference on our 4 because they will not alter behavior in any way as far as our forest concern so these features might be enabled but they are not actually operational the OSPF configured on this interface from our trees perspective is just sending hellos so one of the correct solutions that we can implement here is to actually go to our 3 say router OSPF 1 and say passive interface Ethernet 0 0 now if I go back to our 2 and if I take a look at the database now I will see that the forward address is installed in the route field sorry that the forward address is not present on the LSA which means that 1 R 2 4 4 4 0 oh wow 4 4 4 4 sorry / 32 I thought it was a slash 24 out is now in the routing table if I do show IP route I can see it here so this is an example of a difficult digit why is this difficult to get why do I consider this to be a difficult ticket well I consider it to be a difficult ticket because it requires this deep understanding and deep knowledge of OSPF to solve you cannot just stumble upon this solution you actually have to know what's happening in order to figure out what the problem is

Channel: CCIEORDIE.COM

Views: 861

Keywords:

Id: BmRg5ZqL0KM

Length: 25min 13sec (1513 seconds)

Published: Sat Feb 17 2018