WEBVTT 1 00:00.000 --> 00:07.220 So now it's time to actually jump into the command line, take a look at a few O 2 00:07.220 --> 00:09.000 SPF problems 3 00:09.000 --> 00:14.760 and use our tools to solve those problems and get our network functional again. 4 00:14.760 --> 00:18.620 Now the way we're going to format this is we're going to attack three separate 5 00:18.620 --> 00:18.840 trouble 6 00:18.840 --> 00:22.560 tickets in our OSPF environment. 7 00:22.560 --> 00:27.610 If you want to follow along, the configurations for this are below this video, 8 00:27.610 --> 00:28.200 but keep in 9 00:28.200 --> 00:32.470 mind that as you're putting the configurations on your equipment, try not to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 9 00:28.200 --> 00:32.470 mind that as you're putting the configurations on your equipment, try not to 10 00:32.470 --> 00:33.200 look at them 11 00:33.200 --> 00:37.290 too closely because of course the problems are going to be in those 12 00:37.290 --> 00:38.600 configurations. 13 00:38.600 --> 00:42.070 So let's go ahead and jump into the command line and get started with our first 14 00:42.070 --> 00:42.520 trouble 15 00:42.520 --> 00:45.400 ticket. 16 00:45.400 --> 00:49.740 So as we jump into our troubleshooting tickets, I would encourage you to keep a 17 00:49.740 --> 00:50.360 copy of our 18 00:50.360 --> 00:55.120 network diagram handy as we work our way through these tickets. 19 00:55.120 --> 00:57.680 So let's take a look at our first ticket here. 20 00:57.680 --> 01:03.460 For ticket one, we say that router seven cannot reach workstation one from its WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 20 00:57.680 --> 01:03.460 For ticket one, we say that router seven cannot reach workstation one from its 21 01:03.460 --> 01:04.680 gigabit two 22 01:04.680 --> 01:06.080 interface. 23 01:06.080 --> 01:09.560 So let's begin by taking a look at our diagram. 24 01:09.560 --> 01:14.240 So for this ticket, our focus is going to be over here on router seven and we 25 01:14.240 --> 01:15.080 're talking 26 01:15.080 --> 01:20.900 about the gigabit two interface here coming from the 10.100.10 network being 27 01:20.900 --> 01:21.840 able to reach 28 01:21.840 --> 01:25.920 workstation one over here off of router five. 29 01:25.920 --> 01:31.210 So specifically, we're going to be going to the 10.10.10.10 interface on work WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 29 01:25.920 --> 01:31.210 So specifically, we're going to be going to the 10.10.10.10 interface on work 30 01:31.210 --> 01:32.840 station one. 31 01:32.840 --> 01:38.040 So let's go ahead and jump into our command line and see what's going on on 32 01:38.040 --> 01:39.320 router seven. 33 01:39.320 --> 01:43.870 So I always like to start a troubleshooting ticket by first verifying the 34 01:43.870 --> 01:44.800 problem to make 35 01:44.800 --> 01:49.760 sure the information provided is accurate and that the problem still exists. 36 01:49.760 --> 01:55.560 So let's try to ping our 10 10 10 10 and we'll source that from gigabit two. 37 01:55.560 --> 01:57.120 We see here that it's not working. 38 01:57.120 --> 02:01.080 So clearly the ticket is accurate and still in effect. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 38 01:57.120 --> 02:01.080 So clearly the ticket is accurate and still in effect. 39 02:01.080 --> 02:03.680 So now let's start with some basic troubleshooting. 40 02:03.680 --> 02:06.680 Let's start with a show IP interface brief. 41 02:06.680 --> 02:12.730 We see here that the relevant interfaces gigabit one gigabit two tunnel one one 42 02:12.730 --> 02:13.160 and tunnel 43 02:13.160 --> 02:18.450 one oh two are in the up up status, which means that they appear to be 44 02:18.450 --> 02:19.840 operational. 45 02:19.840 --> 02:23.120 So now let's take a look at our routing table. 46 02:23.120 --> 02:28.930 Let's just do a show IP route for OSPF and we see here that we have no OSPF 47 02:28.930 --> 02:29.720 routes, which 48 02:29.720 --> 02:34.090 probably could have been predicted given that this is an OSPF troubleshooting WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 48 02:29.720 --> 02:34.090 probably could have been predicted given that this is an OSPF troubleshooting 49 02:34.090 --> 02:34.400 lab. 50 02:34.400 --> 02:36.960 So clearly we have no routes from OSPF. 51 02:36.960 --> 02:41.880 Well, let's next see if we're running OSPF on the correct interfaces. 52 02:41.880 --> 02:45.560 We'll do this with a show IP OSPF interface brief. 53 02:45.560 --> 02:49.840 If we take a look at this, we see that in fact we are running OSPF on the 54 02:49.840 --> 02:51.360 correct interfaces. 55 02:51.360 --> 02:55.680 Group back zero isn't all that imperative, but it's running OSPF. 56 02:55.680 --> 03:00.120 But the gigabit two, the tunnel one oh two and the tunnel one oh one are in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 56 02:55.680 --> 03:00.120 But the gigabit two, the tunnel one oh two and the tunnel one oh one are in 57 03:00.120 --> 03:01.160 fact all running 58 03:01.160 --> 03:02.800 OSPF. 59 03:02.800 --> 03:08.080 We see that all of these interfaces are in area one hundred as they should be. 60 03:08.080 --> 03:12.640 However, notice that on the tunnel one oh one and the tunnel one oh two, we 61 03:12.640 --> 03:13.640 actually don't 62 03:13.640 --> 03:15.360 have any neighbors. 63 03:15.360 --> 03:18.600 So that's definitely going to be a concern. 64 03:18.600 --> 03:21.560 Let's take a look at more detail on our neighbors. 65 03:21.560 --> 03:24.240 Let's do a show IP OSPF neighbor. 66 03:24.240 --> 03:30.160 And what's interesting about this output is even though the state is down, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 66 03:24.240 --> 03:30.160 And what's interesting about this output is even though the state is down, 67 03:30.160 --> 03:30.960 notice that 68 03:30.960 --> 03:34.200 our seven knows that they exist. 69 03:34.200 --> 03:39.970 This generally indicates that we are in fact receiving hellos from those 70 03:39.970 --> 03:41.160 neighbors. 71 03:41.160 --> 03:45.100 That means that there's something else OSPF doesn't like about this 72 03:45.100 --> 03:46.200 neighborhood. 73 03:46.200 --> 03:49.240 Now we'll still verify that we have connectivity. 74 03:49.240 --> 03:52.120 In fact, that's probably a good thing to do next. 75 03:52.120 --> 03:56.730 So we can just ping two twenty four dot zero dot zero dot five, the multi cast 76 03:56.730 --> 03:57.600 address for 77 03:57.600 --> 03:58.600 OSPF. 78 03:58.600 --> 04:00.000 Hello's. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 79 04:00.000 --> 04:04.660 And what we see here is yes, we're getting some replies from our own interfaces 80 04:04.660 --> 04:05.120 , but 81 04:05.120 --> 04:09.870 the ones we really care about are the ones here coming across the tunnels from 82 04:09.870 --> 04:10.440 routers 83 04:10.440 --> 04:11.920 three and four. 84 04:11.920 --> 04:18.340 So we are getting pings through indicating that those devices are running OSPF 85 04:18.340 --> 04:19.320 correctly 86 04:19.320 --> 04:23.200 and that the multi cast packets are getting through our tunnel. 87 04:23.200 --> 04:27.680 So at this point, it's probably pertinent to start looking at some debug. 88 04:27.680 --> 04:31.240 So let's start with a debug IP OSPF packet. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 88 04:27.680 --> 04:31.240 So let's start with a debug IP OSPF packet. 89 04:31.240 --> 04:35.020 Now this is one that you do want to be careful with in production, but here in 90 04:35.020 --> 04:35.560 the lab, it's 91 04:35.560 --> 04:37.680 going to be fine. 92 04:37.680 --> 04:42.440 As you can see, we're getting packets in and out our tunnel interfaces. 93 04:42.440 --> 04:46.560 So we'll just take a look at a couple of these packets and then we'll just turn 94 04:46.560 --> 04:46.840 off all of 95 04:46.840 --> 04:48.360 the debugging. 96 04:48.360 --> 04:50.840 So just a quick look over these packets. 97 04:50.840 --> 04:54.840 We see that packets are coming in and out both of the interfaces. 98 04:54.840 --> 04:58.770 They're going to that two twenty four dot zero dot zero dot five multi cast 99 04:58.770 --> 04:59.520 address. 100 04:59.520 --> 05:03.530 We see some of them are coming from us, which is the ten dot seven dot seven WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 100 04:59.520 --> 05:03.530 We see some of them are coming from us, which is the ten dot seven dot seven 101 05:03.530 --> 05:04.280 dot seven. 102 05:04.280 --> 05:08.160 And of course, some of these, the inbound one specifically are coming from 103 05:08.160 --> 05:08.800 either router 104 05:08.800 --> 05:10.280 three or four. 105 05:10.280 --> 05:14.930 So OSPF packets are coming in and out the tunnel correctly and they're not 106 05:14.930 --> 05:15.840 being thrown 107 05:15.840 --> 05:19.800 away for something like authentication. 108 05:19.800 --> 05:23.520 Another good command is debug IP OSPF adjacency. 109 05:23.520 --> 05:28.480 Now as I mentioned during our OSPF overview, this doesn't always show the 110 05:28.480 --> 05:29.520 problem. 111 05:29.520 --> 05:32.920 If you note, we're not getting output from this debug. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 111 05:29.520 --> 05:32.920 If you note, we're not getting output from this debug. 112 05:32.920 --> 05:35.280 So we can actually just go ahead and turn it off. 113 05:35.280 --> 05:39.170 We can let it sit here and run a little bit longer just to make sure, but it's 114 05:39.170 --> 05:39.640 not going 115 05:39.640 --> 05:41.960 to give us any output. 116 05:41.960 --> 05:47.510 Remember that if that command doesn't show you what you want, debug IP OSPF 117 05:47.510 --> 05:47.760 hello is 118 05:47.760 --> 05:50.400 often a good place to follow up. 119 05:50.400 --> 05:53.000 So let's turn on our hello debugging. 120 05:53.000 --> 05:55.970 We let that run just a second and we can turn it right back off because we're 121 05:55.970 --> 05:56.800 already seeing 122 05:56.800 --> 05:59.480 the issue right here. 123 05:59.480 --> 06:04.050 We're seeing a packet coming in from router four and it's saying that it has a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 123 05:59.480 --> 06:04.050 We're seeing a packet coming in from router four and it's saying that it has a 124 06:04.050 --> 06:04.880 mismatched 125 06:04.880 --> 06:09.040 stub or transit area option bit set. 126 06:09.040 --> 06:12.600 And we're seeing the same thing here from router three. 127 06:12.600 --> 06:18.230 So this means that routers three and four do not agree with router seven as far 128 06:18.230 --> 06:19.160 as whether 129 06:19.160 --> 06:23.600 the stub flag is set for area 100. 130 06:23.600 --> 06:25.240 So let's check router seven here. 131 06:25.240 --> 06:29.660 We can see this very easily by doing a show IP OSPF and then we can pipe it 132 06:29.660 --> 06:30.360 through the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 132 06:29.660 --> 06:30.360 through the 133 06:30.360 --> 06:34.880 section and look for area 100. 134 06:34.880 --> 06:40.940 Notice on this output, there is no indicator that this is a stub area. 135 06:40.940 --> 06:46.390 If we run this same command on say router three, notice here on router three, 136 06:46.390 --> 06:47.400 it's clearly 137 06:47.400 --> 06:50.800 saying it is a stub area. 138 06:50.800 --> 06:55.160 So this tells us that router three and since we saw in the debug, we're getting 139 06:55.160 --> 06:55.760 that same 140 06:55.760 --> 07:00.020 message from router four, we see that router three and four are configured WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 140 06:55.760 --> 07:00.020 message from router four, we see that router three and four are configured 141 07:00.020 --> 07:00.840 correctly, but 142 07:00.840 --> 07:05.280 router seven doesn't think that area 100 is a stub. 143 07:05.280 --> 07:09.640 And of course, the stub flag has to match for our neighborships to come up. 144 07:09.640 --> 07:14.340 So more than likely that's our problem or at least one of our problems. 145 07:14.340 --> 07:17.320 So let's switch back over here to router seven. 146 07:17.320 --> 07:24.320 We're going to configuration mode for router OSPF one and change area 100 to a 147 07:24.320 --> 07:24.940 stub. 148 07:24.940 --> 07:28.990 We see here that our tunnels are automatically reset and then they come right 149 07:28.990 --> 07:29.640 back up and 150 07:29.640 --> 07:31.840 they go from loading to full. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 150 07:29.640 --> 07:31.840 they go from loading to full. 151 07:31.840 --> 07:33.520 So this looks promising. 152 07:33.520 --> 07:39.740 If we do our show IP OSPF neighbor again, we see that now they are full. 153 07:39.740 --> 07:46.780 If we do our show IP route OSPF, we now have plenty of OSPF routes here. 154 07:46.780 --> 07:50.860 And of course, we want to verify the original ticket again. 155 07:50.860 --> 07:56.600 So once again, we'll ping the 10 dot 10 dot 10 dot 10 sourcing it from gigabit 156 07:56.600 --> 07:56.820 to we see 157 07:56.820 --> 07:58.740 here that it's successful. 158 07:58.740 --> 08:01.980 So that means that we have completed ticket one. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 158 07:58.740 --> 08:01.980 So that means that we have completed ticket one. 159 08:01.980 --> 08:09.460 So now let's jump back over and take a look at ticket to ticket to is almost 160 08:09.460 --> 08:09.720 the same 161 08:09.720 --> 08:13.300 except this time it's router eight. 162 08:13.300 --> 08:18.060 So just to keep it fresh in our minds, let's take a look at our diagram again. 163 08:18.060 --> 08:22.440 So this time, of course, our focus is going to be down here on router eight. 164 08:22.440 --> 08:26.100 Once again, we're talking about its gigabit to interface. 165 08:26.100 --> 08:30.080 And once again, we're talking about it not being able to reach workstation one WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 165 08:26.100 --> 08:30.080 And once again, we're talking about it not being able to reach workstation one 166 08:30.080 --> 08:30.560 up here 167 08:30.560 --> 08:32.420 off of router five. 168 08:32.420 --> 08:35.530 So again, let's jump into router eight and see if we can figure out what's 169 08:35.530 --> 08:36.500 going on here 170 08:36.500 --> 08:38.300 on router eight. 171 08:38.300 --> 08:41.960 So once again, let's start with verifying our ticket. 172 08:41.960 --> 08:44.180 And again, we see it's not working. 173 08:44.180 --> 08:46.600 So let's go ahead and go through our troubleshooting now. 174 08:46.600 --> 08:49.660 We'll go a little bit quicker here since we've been through most of this 175 08:49.660 --> 08:50.280 already. 176 08:50.280 --> 08:53.640 So let's start with our show IP interface brief. 177 08:53.640 --> 08:58.730 Once again, we see that our gigabit one gigabit to tunnel 111 and tunnel 112, 178 08:58.730 --> 08:59.360 which are the 179 08:59.360 --> 09:03.360 important interfaces are currently up up. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 179 08:59.360 --> 09:03.360 important interfaces are currently up up. 180 09:03.360 --> 09:06.240 We'll do a show IP route OSPF. 181 09:06.240 --> 09:08.540 Once again, we have no OSPF routes. 182 09:08.540 --> 09:11.400 So that's going to definitely indicate a problem. 183 09:11.400 --> 09:16.180 So we should probably verify that the correct interfaces are running OSPF next. 184 09:16.180 --> 09:19.640 So once again, we'll just do a show IP OSPF interface brief. 185 09:19.640 --> 09:24.540 And we see that in fact, the correct interfaces are running OSPF. 186 09:24.540 --> 09:27.100 They are in area 110. 187 09:27.100 --> 09:32.000 And notice that our tunnel 112 and our tunnel 111 actually are showing WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 187 09:27.100 --> 09:32.000 And notice that our tunnel 112 and our tunnel 111 actually are showing 188 09:32.000 --> 09:33.180 neighbors here. 189 09:33.180 --> 09:37.440 And if we do a show IP OSPF neighbor, what we're going to see is they're 190 09:37.440 --> 09:38.340 actually in 191 09:38.340 --> 09:42.780 a state of full and they are BDRs. 192 09:42.780 --> 09:49.180 Now if the neighbors are BDRs, that's going to mean that router eight here is 193 09:49.180 --> 09:49.940 the DR because 194 09:49.940 --> 09:54.340 those are the only devices on each of those tunnel segments. 195 09:54.340 --> 09:58.380 So we want to keep that in mind as we look at the rest of our show commands. 196 09:58.380 --> 10:03.330 Technically, at this point, we could probably skip doing our multicast ping, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 196 09:58.380 --> 10:03.330 Technically, at this point, we could probably skip doing our multicast ping, 197 10:03.330 --> 10:03.740 but we'll do 198 10:03.740 --> 10:07.760 it just to make sure we could probably skip this because we're not having 199 10:07.760 --> 10:08.460 trouble with 200 10:08.460 --> 10:13.140 the actual neighborship it doesn't look like because the neighbors are full. 201 10:13.140 --> 10:16.630 But as you can see, we are in fact getting our pings from routers three and 202 10:16.630 --> 10:17.220 four, which 203 10:17.220 --> 10:19.140 are the key neighbors here. 204 10:19.140 --> 10:21.620 So of course, the connectivity is okay. 205 10:21.620 --> 10:25.900 So at this point, we should probably take a look at some of our debug. 206 10:25.900 --> 10:28.700 We'll do our debug IP SPF packet. 207 10:28.700 --> 10:32.480 We'll go ahead and turn that off because we do see packets coming in and out of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 207 10:28.700 --> 10:32.480 We'll go ahead and turn that off because we do see packets coming in and out of 208 10:32.480 --> 10:32.780 both 209 10:32.780 --> 10:36.380 tunnels and we're not getting any kind of errors on them. 210 10:36.380 --> 10:39.260 So this looks like it's okay. 211 10:39.260 --> 10:44.330 Once again, we could probably skip the debug IP OSPF adjacency here because we 212 10:44.330 --> 10:44.780 saw the 213 10:44.780 --> 10:47.300 adjacency is in fact already up. 214 10:47.300 --> 10:50.820 So as you can see, this isn't actually showing us anything. 215 10:50.820 --> 10:52.780 We'll just turn this back off. 216 10:52.780 --> 10:56.990 And sort of the same thing with the debug IP OSPF hello, of course, the hellos 217 10:56.990 --> 10:57.540 are still 218 10:57.540 --> 10:58.900 going on. 219 10:58.900 --> 11:02.800 But notice as these hellos are being sent and received, we're not getting any WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 219 10:58.900 --> 11:02.800 But notice as these hellos are being sent and received, we're not getting any 220 11:02.800 --> 11:03.260 kind of 221 11:03.260 --> 11:05.060 errors on them or anything. 222 11:05.060 --> 11:08.500 So once again, the hellos look okay. 223 11:08.500 --> 11:11.460 So this is sort of an interesting scenario. 224 11:11.460 --> 11:14.220 We have our OSPF neighbors are up. 225 11:14.220 --> 11:19.590 Their adjacency state is full yet when I do a show IP route for OSPF, there's 226 11:19.590 --> 11:20.220 no OSPF 227 11:20.220 --> 11:22.580 routes in the routing table. 228 11:22.580 --> 11:27.660 So the next logical question then would be, do we have them in our database? 229 11:27.660 --> 11:30.980 So let's do a show IP OSPF database. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 229 11:27.660 --> 11:30.980 So let's do a show IP OSPF database. 230 11:30.980 --> 11:35.910 And what this does if you just say database by itself is it gives us a summary 231 11:35.910 --> 11:36.260 of the 232 11:36.260 --> 11:38.420 LSA's on this router. 233 11:38.420 --> 11:44.880 So notice that we have three type one LSA's one from each router, ourselves 234 11:44.880 --> 11:46.060 router eight 235 11:46.060 --> 11:49.580 of course, and routers three and four. 236 11:49.580 --> 11:57.190 We also have two type two LSA's one for each of the segments on the tunnels and 237 11:57.190 --> 11:57.700 notice 238 11:57.700 --> 12:03.230 that the advertising router is 10 dot eight dot eight dot eight, which is this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 238 11:57.700 --> 12:03.230 that the advertising router is 10 dot eight dot eight dot eight, which is this 239 12:03.230 --> 12:03.900 router. 240 12:03.900 --> 12:09.040 Now remember the type two LSA's are generated by the DR and we said earlier 241 12:09.040 --> 12:09.980 that router 242 12:09.980 --> 12:14.860 eight was in fact the DR and we can see here that that's the case. 243 12:14.860 --> 12:20.180 Then we have a bunch of type three LSA's coming from the other areas. 244 12:20.180 --> 12:24.280 And if we scroll down here a little bit, we see that we are in fact getting a 245 12:24.280 --> 12:24.900 type three 246 12:24.900 --> 12:30.660 LSA for our target network, the 10 dot 10 dot 10 dot zero. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 246 12:24.900 --> 12:30.660 LSA for our target network, the 10 dot 10 dot 10 dot zero. 247 12:30.660 --> 12:33.700 So this brings up an interesting question then. 248 12:33.700 --> 12:40.370 If I have all the routes in my OSPF database, why are they not in the routing 249 12:40.370 --> 12:40.940 table? 250 12:40.940 --> 12:46.070 That's going to indicate that for some reason OSPF is not happy about these 251 12:46.070 --> 12:46.940 networks and 252 12:46.940 --> 12:52.240 it's not setting what's called the routing bit, meaning it's not setting it as 253 12:52.240 --> 12:52.980 eligible 254 12:52.980 --> 12:55.580 for entry into the routing table. 255 12:55.580 --> 13:01.510 The way we can see that is if we repeat the command for show IP OSPF database, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 255 12:55.580 --> 13:01.510 The way we can see that is if we repeat the command for show IP OSPF database, 256 13:01.510 --> 13:01.820 we add 257 13:01.820 --> 13:07.040 the word summary to look at type three LSA's and then we can be even more 258 13:07.040 --> 13:08.140 specific and 259 13:08.140 --> 13:11.260 look for our destination network. 260 13:11.260 --> 13:14.300 If we look at this entry and we'll just look at the top entry here that we're 261 13:14.300 --> 13:14.700 getting 262 13:14.700 --> 13:18.900 from router three, this is missing something. 263 13:18.900 --> 13:22.140 But you can't tell on this output. 264 13:22.140 --> 13:25.020 We need actually a little bit more detail. 265 13:25.020 --> 13:30.960 So let's quit out of this, repeat the command, but add the keyword internal to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 265 13:25.020 --> 13:30.960 So let's quit out of this, repeat the command, but add the keyword internal to 266 13:30.960 --> 13:31.740 the end of 267 13:31.740 --> 13:32.740 it. 268 13:32.740 --> 13:33.740 We'll hit enter. 269 13:33.740 --> 13:38.920 Notice we're getting a little bit more information here, but more importantly, 270 13:38.920 --> 13:40.180 we're still missing 271 13:40.180 --> 13:41.180 something. 272 13:41.180 --> 13:45.900 Now, if you've never seen this output before, you may not be able to tell from 273 13:45.900 --> 13:46.740 this output 274 13:46.740 --> 13:48.380 that something's missing. 275 13:48.380 --> 13:51.190 So what we're going to do is we're going to go look at a router that we know is 276 13:51.190 --> 13:51.820 functioning 277 13:51.820 --> 13:53.300 correctly. 278 13:53.300 --> 13:57.660 We just fixed router seven in the previous ticket. 279 13:57.660 --> 14:01.620 So let's do this same command on router seven. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 279 13:57.660 --> 14:01.620 So let's do this same command on router seven. 280 14:01.620 --> 14:05.980 So here on router seven, we'll put in the exact same command and this is the 281 14:05.980 --> 14:06.660 line that 282 14:06.660 --> 14:08.500 we were looking for. 283 14:08.500 --> 14:17.220 Intepology base with multi-topology ID zero, route reference count is one. 284 14:17.220 --> 14:24.380 This indicates that the routing bit is set on this database entry and therefore 285 14:24.380 --> 14:25.020 this entry 286 14:25.020 --> 14:28.140 is going to be put into the routing table. 287 14:28.140 --> 14:34.860 Notice on router eight, this same entry is missing that statement. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 287 14:28.140 --> 14:34.860 Notice on router eight, this same entry is missing that statement. 288 14:34.860 --> 14:38.890 That means that the routing bit is not set and therefore this is not being 289 14:38.890 --> 14:39.500 marked as 290 14:39.500 --> 14:42.620 eligible for the routing table. 291 14:42.620 --> 14:47.850 So we see here that the routing bit is clearly not set on this entry, but that 292 14:47.850 --> 14:49.380 begs the question 293 14:49.380 --> 14:50.860 why not. 294 14:50.860 --> 14:55.380 And the answer is there's a database error here. 295 14:55.380 --> 15:01.130 Router eight believes that the links going out to routers three and four are WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 295 14:55.380 --> 15:01.130 Router eight believes that the links going out to routers three and four are 296 15:01.130 --> 15:01.940 broadcast 297 15:01.940 --> 15:03.700 network types. 298 15:03.700 --> 15:04.700 How do we know? 299 15:04.700 --> 15:10.110 Well, because we've already seen that it elected itself as the DR and it's 300 15:10.110 --> 15:10.940 generated 301 15:10.940 --> 15:15.340 type two LSAs for those tunnels. 302 15:15.340 --> 15:20.800 On the other hand, those are point to point links and the default OSPF network 303 15:20.800 --> 15:21.420 type is 304 15:21.420 --> 15:22.900 point to point. 305 15:22.900 --> 15:27.460 Now we can of course go over to routers three and four and verify this theory 306 15:27.460 --> 15:28.220 and we will 307 15:28.220 --> 15:30.060 do that in just a second. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 307 15:28.220 --> 15:30.060 do that in just a second. 308 15:30.060 --> 15:34.220 But the point is this can be sort of tricky to troubleshoot. 309 15:34.220 --> 15:39.500 You can't have one side thinking that there's a DR and the other side thinking 310 15:39.500 --> 15:40.140 that there 311 15:40.140 --> 15:41.460 is not. 312 15:41.460 --> 15:46.500 We mentioned this previously that you can have neighborhoods between point to 313 15:46.500 --> 15:47.420 point and 314 15:47.420 --> 15:52.710 point to multi point, but you cannot have a proper neighborhood between point 315 15:52.710 --> 15:53.380 to point 316 15:53.380 --> 15:55.420 and broadcast. 317 15:55.420 --> 15:59.880 Now again, this can be a little bit tricky to see, but here's the evidence that 318 15:59.880 --> 16:00.500 it doesn't WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 318 15:59.880 --> 16:00.500 it doesn't 319 16:00.500 --> 16:01.500 work. 320 16:01.500 --> 16:02.860 The neighborhoods come up. 321 16:02.860 --> 16:06.700 They even go to a full state as far as the adjacency. 322 16:06.700 --> 16:12.180 But there's a database error and that error prevents these entries in the 323 16:12.180 --> 16:13.300 database from 324 16:13.300 --> 16:14.620 being used. 325 16:14.620 --> 16:19.420 So let's go ahead and verify our theory and then fix the issue. 326 16:19.420 --> 16:24.760 So we can verify here on router eight by simply doing a show IP OSPF interface 327 16:24.760 --> 16:25.260 for tunnel 328 16:25.260 --> 16:26.540 one eleven. 329 16:26.540 --> 16:31.500 And what we see here is that the network type is definitely set to broadcast. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 329 16:26.540 --> 16:31.500 And what we see here is that the network type is definitely set to broadcast. 330 16:31.500 --> 16:35.960 If we look a little further down, here's the proof that it thinks that router 331 16:35.960 --> 16:37.260 eight itself 332 16:37.260 --> 16:43.240 is the DR and it thinks that router three is the backup designated router or 333 16:43.240 --> 16:43.980 the BDR. 334 16:43.980 --> 16:49.020 So we see here clearly that router eight is running this as a broadcast network 335 16:49.020 --> 16:49.180 . 336 16:49.180 --> 16:51.340 Let's go over to router three. 337 16:51.340 --> 16:55.890 Now on router three, notice we actually have a console message here that's 338 16:55.890 --> 16:56.860 already telling 339 16:56.860 --> 17:01.660 us that it sees a potential network type mismatch. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 339 16:56.860 --> 17:01.660 us that it sees a potential network type mismatch. 340 17:01.660 --> 17:08.920 Now the reason it knows this is because it sees a proposed DR in the hello and 341 17:08.920 --> 17:09.860 it looks 342 17:09.860 --> 17:13.850 at its network type and says, wait a minute, we shouldn't have a DR here at all 343 17:13.850 --> 17:13.900 . 344 17:13.900 --> 17:16.660 Why are you proposing yourself to be the DR? 345 17:16.660 --> 17:19.380 So router three actually already solved this issue. 346 17:19.380 --> 17:23.790 However, we can of course verify it by looking at the show IP OSPF interface 347 17:23.790 --> 17:24.580 for tunnel one 348 17:24.580 --> 17:25.580 eleven. 349 17:25.580 --> 17:29.820 And we see that in fact the network type here is point to point. 350 17:29.820 --> 17:33.220 And I can't exactly highlight something that's not here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 350 17:29.820 --> 17:33.220 And I can't exactly highlight something that's not here. 351 17:33.220 --> 17:38.660 But notice that there's no information here about a DR or a BDR because router 352 17:38.660 --> 17:39.500 three doesn't 353 17:39.500 --> 17:41.260 believe there should be one. 354 17:41.260 --> 17:46.250 So clearly our problem is we have a network type mismatch between routers three 355 17:46.250 --> 17:46.860 and four 356 17:46.860 --> 17:48.340 and router eight. 357 17:48.340 --> 17:51.820 So let's go ahead over to router eight and fix that issue. 358 17:51.820 --> 17:55.220 So here on router eight, we'll simply go into configuration mode. 359 17:55.220 --> 17:59.060 Now you don't have to do this, but you can use the interface range command and 360 17:59.060 --> 17:59.380 we can 361 17:59.380 --> 18:05.460 actually fix tunnel one eleven and one twelve at the same time. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 361 17:59.380 --> 18:05.460 actually fix tunnel one eleven and one twelve at the same time. 362 18:05.460 --> 18:10.780 And all we have to do is say IP OSPF network type point to point. 363 18:10.780 --> 18:13.740 Just almost before we could even exit out of here. 364 18:13.740 --> 18:18.900 We already see those neighbor adjacencies resetting coming right back up. 365 18:18.900 --> 18:22.850 Now we don't necessarily have to go peck and re look at everything again 366 18:22.850 --> 18:23.580 because again, 367 18:23.580 --> 18:25.780 our neighborhoods and such were already up. 368 18:25.780 --> 18:31.000 However, if we do a show IP OSPF neighbor, notice that the state is full, but WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 368 18:25.780 --> 18:31.000 However, if we do a show IP OSPF neighbor, notice that the state is full, but 369 18:31.000 --> 18:31.820 it doesn't 370 18:31.820 --> 18:36.710 say DR or BDR anymore because now router eight understands that it's a point to 371 18:36.710 --> 18:38.620 point link. 372 18:38.620 --> 18:44.940 Just for verification, let's look at our database entry again and notice now it 373 18:44.940 --> 18:45.380 's in 374 18:45.380 --> 18:49.460 topology base with multiprotocol ID zero. 375 18:49.460 --> 18:54.260 Well reference count is one, which means the routing bit is set. 376 18:54.260 --> 18:59.570 By the way, just a quick side note here, the MT ID or the multi topology ID is 377 18:59.570 --> 19:00.260 because WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 377 18:59.570 --> 19:00.260 because 378 19:00.260 --> 19:04.620 OSPF on this platform supports multiple topologies. 379 19:04.620 --> 19:08.660 That is a topic that's clearly beyond our scope for this course. 380 19:08.660 --> 19:13.510 Since we're running a single topology, it will always be multi topology ID zero 381 19:13.510 --> 19:13.540 . 382 19:13.540 --> 19:17.420 So just be aware that that's why that's there, but it's not irrelevant. 383 19:17.420 --> 19:21.850 Importance, what we're really looking for is that the route reference count is 384 19:21.850 --> 19:22.340 in fact 385 19:22.340 --> 19:23.660 one. 386 19:23.660 --> 19:27.820 Of course, the next follow up would be a show IP route OSPF. 387 19:27.820 --> 19:30.620 We see that we now have OSPF entries. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 387 19:27.820 --> 19:30.620 We see that we now have OSPF entries. 388 19:30.620 --> 19:35.300 And of course, last but not least, verify the original ticket. 389 19:35.300 --> 19:40.340 We see that it's working and therefore we have completed ticket to. 390 19:40.340 --> 19:45.060 So now let's jump back over and take a look at ticket three. 391 19:45.060 --> 19:49.500 So for ticket three, we see here that this is very, very different. 392 19:49.500 --> 19:51.820 Okay, maybe not so much. 393 19:51.820 --> 19:56.630 It's the same basic ticket, but now it's router six and it cannot reach work 394 19:56.630 --> 19:58.100 station one from 395 19:58.100 --> 20:00.500 its gigabit three interface. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 395 19:58.100 --> 20:00.500 its gigabit three interface. 396 20:00.500 --> 20:03.740 So once again, let's take a look at our diagram. 397 20:03.740 --> 20:07.940 So now of course, our focus is down here on router six. 398 20:07.940 --> 20:15.670 The focus is on the gigabit three interface and still trying to get to work 399 20:15.670 --> 20:16.140 station one. 400 20:16.140 --> 20:21.140 So for this skill, we're going to do our challenge just a little bit different. 401 20:21.140 --> 20:26.330 I've been through two troubleshooting tickets with you so far for OSPF and we 402 20:26.330 --> 20:27.220 've gotten our 403 20:27.220 --> 20:30.340 introduction here to the third ticket. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 403 20:27.220 --> 20:30.340 introduction here to the third ticket. 404 20:30.340 --> 20:35.450 For our challenge, I want you to go through and try to solve ticket three on 405 20:35.450 --> 20:36.500 your own using 406 20:36.500 --> 20:41.190 the tools and troubleshooting debuggs that we've looked at throughout this 407 20:41.190 --> 20:41.860 skill. 408 20:41.860 --> 20:46.660 So go ahead and give that a try and I'll see you in the solution video on the 409 20:46.660 --> 20:47.460 other side. 410 20:47.460 --> 20:57.460 [BLANK_AUDIO]