WEBVTT 1 00:00.000 --> 00:07.280 So now we're going to jump into some trouble tickets involving BGP. 2 00:07.280 --> 00:13.430 So keep your BGP tools, your show commands and your debug's handy as we jump in 3 00:13.430 --> 00:13.720 . 4 00:13.720 --> 00:17.520 Also note that below this video are the files you need to introduce the 5 00:17.520 --> 00:19.120 problems into your 6 00:19.120 --> 00:20.120 environment. 7 00:20.120 --> 00:24.020 Now, try to load these configurations into your environment without looking at 8 00:24.020 --> 00:24.480 them too 9 00:24.480 --> 00:29.520 closely because of course the problems are right there in the config. 10 00:29.520 --> 00:33.090 So what we want to do is just load the configurations up and then jump into the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 10 00:29.520 --> 00:33.090 So what we want to do is just load the configurations up and then jump into the 11 00:33.090 --> 00:34.140 equipment and start 12 00:34.140 --> 00:35.720 going through our tickets. 13 00:35.720 --> 00:40.000 Let's jump in and get started with our first ticket. 14 00:40.000 --> 00:48.220 So ticket one says that R2 should have the routes for the links to R3 and R7 in 15 00:48.220 --> 00:48.880 its routing 16 00:48.880 --> 00:52.480 table from BGP, but it does not. 17 00:52.480 --> 00:57.840 Well, let's take a look at our diagram and see exactly what this is talking 18 00:57.840 --> 00:58.160 about. 19 00:58.160 --> 01:02.920 So looking at our diagram, we're talking about looking at router two, which is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 19 00:58.160 --> 01:02.920 So looking at our diagram, we're talking about looking at router two, which is 20 01:02.920 --> 01:03.720 missing some 21 01:03.720 --> 01:10.480 routes and the route that's missing the links out to routers three and seven. 22 01:10.480 --> 01:21.040 So we're going to be looking for the 204.186.13.0/24 and the 204.186.17.0/24. 23 01:21.040 --> 01:24.340 So let's go ahead and jump into router two and see if we can figure out what's 24 01:24.340 --> 01:24.720 going 25 01:24.720 --> 01:25.880 on. 26 01:25.880 --> 01:31.630 So as we connect in here to router two, I would really love to say that this is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 26 01:25.880 --> 01:31.630 So as we connect in here to router two, I would really love to say that this is 27 01:31.630 --> 01:32.240 going to be 28 01:32.240 --> 01:36.490 a difficult ticket to troubleshoot and oh my goodness, what are we going to be 29 01:36.490 --> 01:37.040 looking 30 01:37.040 --> 01:38.040 at? 31 01:38.040 --> 01:43.650 However, we can see right here that we are already getting console messages 32 01:43.650 --> 01:44.280 yelling at 33 01:44.280 --> 01:45.280 us. 34 01:45.280 --> 01:50.560 Well, quite aggressively that there is a problem with BGP. 35 01:50.560 --> 01:52.840 We see that we're getting a passive reset. 36 01:52.840 --> 01:57.610 We see we're getting an active down because BGP notifications were received and 37 01:57.610 --> 01:58.040 remember 38 01:58.040 --> 02:00.680 what we said about notifications. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 38 01:58.040 --> 02:00.680 what we said about notifications. 39 02:00.680 --> 02:04.640 This is literally telling us that there's a problem on the connection and we're 40 02:04.640 --> 02:05.240 resetting 41 02:05.240 --> 02:06.760 the neighborship. 42 02:06.760 --> 02:10.200 And what's happening is it's trying over and over again. 43 02:10.200 --> 02:14.280 But if we look at the notification message itself, it is literally flat out 44 02:14.280 --> 02:14.920 telling us 45 02:14.920 --> 02:16.280 the problem. 46 02:16.280 --> 02:19.400 It says the peer is in the wrong AS. 47 02:19.400 --> 02:24.420 Now, the fact of the matter is the peers in the wrong AS from this router's 48 02:24.420 --> 02:25.640 perspective. 49 02:25.640 --> 02:29.420 If we were to go look at router one, which as we can see, that's the neighbor 50 02:29.420 --> 02:30.040 is yelling WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 50 02:29.420 --> 02:30.040 is yelling 51 02:30.040 --> 02:31.840 about. 52 02:31.840 --> 02:36.370 Notice that router one is getting the same message and it's also saying the 53 02:36.370 --> 02:37.120 peer is in 54 02:37.120 --> 02:38.800 the wrong AS. 55 02:38.800 --> 02:44.020 So the fact of the matter is somebody is configured for the wrong AS number, 56 02:44.020 --> 02:44.680 but we don't really 57 02:44.680 --> 02:50.120 know which router it is until we take a look at the configuration. 58 02:50.120 --> 02:54.160 So we'll do a show of run section BGP here on router one. 59 02:54.160 --> 02:59.760 And we can see that router two here is configured with the wrong remote AS. 60 02:59.760 --> 03:05.060 It's set to three two two two two when it should in fact be three two two two WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 60 02:59.760 --> 03:05.060 It's set to three two two two two when it should in fact be three two two two 61 03:05.060 --> 03:05.440 one. 62 03:05.440 --> 03:09.280 So easiest thing to do is simply fix that. 63 03:09.280 --> 03:14.490 So we'll simply go into configuration mode, go into router BGP, put in our 64 03:14.490 --> 03:16.240 neighbor statement, 65 03:16.240 --> 03:19.280 but make it three two two two one. 66 03:19.280 --> 03:24.880 Now the next time it attempts, we see here that the neighbor ship now comes up. 67 03:24.880 --> 03:28.800 Now, assuming that that was the problem, let's go ahead and go back over to 68 03:28.800 --> 03:29.740 router two to 69 03:29.740 --> 03:32.200 verify the original ticket. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 69 03:29.740 --> 03:32.200 verify the original ticket. 70 03:32.200 --> 03:35.340 So we see here the neighbor is up, but remember the original ticket was not 71 03:35.340 --> 03:36.160 being able to see 72 03:36.160 --> 03:37.400 the routes. 73 03:37.400 --> 03:41.320 So let's do a show IP route BGP. 74 03:41.320 --> 03:44.990 And what we see right here is we now have the routes for two, oh four dot one 75 03:44.990 --> 03:45.840 eight six 76 03:45.840 --> 03:52.120 dot 13 dot zero and two four dot one eight six dot seventeen dot zero. 77 03:52.120 --> 03:54.440 So so far, this is looking good. 78 03:54.440 --> 03:58.080 I would say that this completes ticket one again. 79 03:58.080 --> 04:02.350 This is going to yell quite a bit and keep in mind that if you don't have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 79 03:58.080 --> 04:02.350 This is going to yell quite a bit and keep in mind that if you don't have 80 04:02.350 --> 04:03.400 console messages, 81 04:03.400 --> 04:08.160 displaying or anything like that, you can also do a show log. 82 04:08.160 --> 04:11.840 You can see that this has been yelling about this for quite some time, probably 83 04:11.840 --> 04:12.280 since I 84 04:12.280 --> 04:15.200 can figure these routers with the problem. 85 04:15.200 --> 04:19.150 So even if you're not getting console messages, you can see these things to 86 04:19.150 --> 04:20.120 show log, which 87 04:20.120 --> 04:24.340 when you're troubleshooting, always a good place to go fairly early on, maybe 88 04:24.340 --> 04:24.880 not your 89 04:24.880 --> 04:29.480 first stop, but fairly early on, this is not a bad place to go to see what 90 04:29.480 --> 04:30.400 might be causing WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 90 04:29.480 --> 04:30.400 might be causing 91 04:30.400 --> 04:34.350 the problem on the router, because you may very well be getting messages about 92 04:34.350 --> 04:34.800 it like 93 04:34.800 --> 04:36.440 we did here. 94 04:36.440 --> 04:39.480 So let's take a look now at ticket to. 95 04:39.480 --> 04:45.800 So for ticket to, we're saying that our eight is not learning any BGP routes. 96 04:45.800 --> 04:48.480 Well, that's a fairly simple ticket. 97 04:48.480 --> 04:50.960 So let's jump over to our diagram. 98 04:50.960 --> 04:55.040 So in our diagram here, we're talking about router eight down here. 99 04:55.040 --> 04:57.880 And it's saying it's not getting any BGP routes. 100 04:57.880 --> 05:00.760 So let's go ahead and jump into router eight. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 100 04:57.880 --> 05:00.760 So let's go ahead and jump into router eight. 101 05:00.760 --> 05:05.340 We could be suspicious here of filtering or maybe a neighborhood ship or maybe 102 05:05.340 --> 05:05.800 even our 103 05:05.800 --> 05:07.320 interface is enough. 104 05:07.320 --> 05:10.840 So let's go ahead and jump into router eight and see what's going on. 105 05:10.840 --> 05:15.440 So we didn't do this last time since the error was sort of, well, right in our 106 05:15.440 --> 05:16.400 face displaying 107 05:16.400 --> 05:18.000 right on the screen. 108 05:18.000 --> 05:21.560 But what we should always do is verify the original ticket. 109 05:21.560 --> 05:24.920 So let's do a show IP route BGP. 110 05:24.920 --> 05:29.060 And as the ticket said, we are not getting any routes through BGP. 111 05:29.060 --> 05:32.480 So let's do our good old show IP interface brief. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 111 05:29.060 --> 05:32.480 So let's do our good old show IP interface brief. 112 05:32.480 --> 05:36.920 And we see here that our gigabit one interface is actually up. 113 05:36.920 --> 05:41.470 Now if you look down at our tunnels, the tunnels are currently down, but that 114 05:41.470 --> 05:42.460 would make sense 115 05:42.460 --> 05:47.420 because our tunnels need to know the BGP routes in order to know how to get to 116 05:47.420 --> 05:48.200 the tunnel 117 05:48.200 --> 05:49.200 endpoints. 118 05:49.200 --> 05:51.840 So I'm not worried about the tunnels just yet. 119 05:51.840 --> 05:54.320 We need to get BGP up and running. 120 05:54.320 --> 05:58.360 So let's go ahead and do a show IP BGP summary. 121 05:58.360 --> 06:02.400 Now we get a message that BGP is not active. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 121 05:58.360 --> 06:02.400 Now we get a message that BGP is not active. 122 06:02.400 --> 06:04.800 So that's interesting. 123 06:04.800 --> 06:07.880 How about a show run section BGP? 124 06:07.880 --> 06:12.840 Looking to me like router eight doesn't have BGP configured at all. 125 06:12.840 --> 06:18.160 We can verify that even further by doing a show TCP brief all. 126 06:18.160 --> 06:20.960 Now this command does take just a second to finish. 127 06:20.960 --> 06:24.320 So when you type it, give it that second, let it finish. 128 06:24.320 --> 06:28.340 But what we see here is it's listening to a couple of things on some various 129 06:28.340 --> 06:28.880 ports for 130 06:28.880 --> 06:32.120 probably things like call home. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 130 06:28.880 --> 06:32.120 probably things like call home. 131 06:32.120 --> 06:34.360 And of course, port 22 is SSH. 132 06:34.360 --> 06:41.000 In fact, this session right here is us right now actually SSH into this device. 133 06:41.000 --> 06:45.330 So we can see that this is showing us our current TCP connections, but it's not 134 06:45.330 --> 06:46.000 listening 135 06:46.000 --> 06:48.760 on TCP port 179. 136 06:48.760 --> 06:51.600 So clearly we do not have BGP configured. 137 06:51.600 --> 06:54.120 So let's go into configuration mode. 138 06:54.120 --> 06:58.430 Now if we're not completely sure how BGP is supposed to be configured, it's 139 06:58.430 --> 06:59.000 probably 140 06:59.000 --> 07:04.240 not a bad idea to look at another router that we know is configured similarly, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 140 06:59.000 --> 07:04.240 not a bad idea to look at another router that we know is configured similarly, 141 07:04.240 --> 07:05.120 or of course 142 07:05.120 --> 07:10.120 on a production network, hopefully you have documentation or previously saved 143 07:10.120 --> 07:11.360 configurations. 144 07:11.360 --> 07:14.000 In our case, we know that router seven is working. 145 07:14.000 --> 07:17.760 So let's go over to router seven and take a look at its configuration. 146 07:17.760 --> 07:20.480 So let's do a show run section BGP. 147 07:20.480 --> 07:23.820 Now we don't really need to copy and paste this because the neighbor address, 148 07:23.820 --> 07:24.360 of course, 149 07:24.360 --> 07:25.720 is going to be different. 150 07:25.720 --> 07:29.340 We could of course copy this, throw it into notepad and change the neighbor 151 07:29.340 --> 07:29.960 address if 152 07:29.960 --> 07:33.840 we wanted to, but there's really not that much configuration here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 152 07:29.960 --> 07:33.840 we wanted to, but there's really not that much configuration here. 153 07:33.840 --> 07:38.100 But the one thing we want to note is it does have a prefix list called PL 154 07:38.100 --> 07:39.440 underscore Bogan 155 07:39.440 --> 07:40.840 in. 156 07:40.840 --> 07:44.630 So we should make sure that that's on router eight and that we apply it since 157 07:44.630 --> 07:45.200 that does 158 07:45.200 --> 07:47.400 seem to be our policy. 159 07:47.400 --> 07:49.640 So let's go back over to router eight. 160 07:49.640 --> 07:58.840 So first router BGP 65001 neighbors 204 dot 186 dot 28 dot two. 161 07:58.840 --> 08:02.120 It is in remote AS32221. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 161 07:58.840 --> 08:02.120 It is in remote AS32221. 162 08:02.120 --> 08:05.680 Have to make sure I don't leave my two out this time like I did during our 163 08:05.680 --> 08:06.760 presentation. 164 08:06.760 --> 08:08.480 We'll hit enter. 165 08:08.480 --> 08:10.960 Let's do a show IP prefix last. 166 08:10.960 --> 08:15.840 And we see here that we do in fact have that PL underscore Bogan prefix list. 167 08:15.840 --> 08:21.880 It looks like it's configured to deny a default route and then permit 168 08:21.880 --> 08:23.360 everything else. 169 08:23.360 --> 08:28.660 So essentially what this is doing is it's preventing us from using BGP for 170 08:28.660 --> 08:30.640 internet access, but WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 170 08:28.660 --> 08:30.640 internet access, but 171 08:30.640 --> 08:36.320 it allows us to use BGP for the underlay for our VPNs. 172 08:36.320 --> 08:38.440 So let's go ahead and apply this. 173 08:38.440 --> 08:41.600 So of course we simply put the neighbor in again. 174 08:41.600 --> 08:47.320 And then we say prefix list and put in the name and this is to be applied in 175 08:47.320 --> 08:47.640 bound. 176 08:47.640 --> 08:52.800 Let's go ahead and exit out and do our show IP BGP summary again. 177 08:52.800 --> 08:55.560 So here we see is we have our neighbor configured. 178 08:55.560 --> 08:57.640 We see it's a S number. 179 08:57.640 --> 09:04.440 However, on the up down it says never and under state it lists it as idle. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 179 08:57.640 --> 09:04.440 However, on the up down it says never and under state it lists it as idle. 180 09:04.440 --> 09:07.840 So let's give it just a second and see if that state changes. 181 09:07.840 --> 09:12.160 So we gave it just a few seconds and it's staying at idle. 182 09:12.160 --> 09:16.640 So since it's not moving past idle, that seems like it might be a problem with 183 09:16.640 --> 09:18.800 the TCP connection. 184 09:18.800 --> 09:21.120 So one thing we could do. 185 09:21.120 --> 09:24.480 Let's ping the neighbor's address and verify that it's working. 186 09:24.480 --> 09:27.320 It is so we do have reachability. 187 09:27.320 --> 09:33.680 So then let's try our show TCP brief all again. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 187 09:27.320 --> 09:33.680 So then let's try our show TCP brief all again. 188 09:33.680 --> 09:40.200 Notice that this time we are in fact listening on port 179. 189 09:40.200 --> 09:44.800 And you remember during our discussion we said that it does source address 190 09:44.800 --> 09:45.520 checking? 191 09:45.520 --> 09:50.850 Notice that on this line where it's listening for the 179, it's only listening 192 09:50.850 --> 09:51.520 to it from 193 09:51.520 --> 09:56.080 that specific neighbor 204 dot 186 dot 28 dot two. 194 09:56.080 --> 10:00.840 It's not just blindly listening to TCP port 179. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 194 09:56.080 --> 10:00.840 It's not just blindly listening to TCP port 179. 195 10:00.840 --> 10:05.110 So now that we see that we're properly listening, but we're not going to 196 10:05.110 --> 10:06.400 established, let's 197 10:06.400 --> 10:11.520 debug our TCP transactions and see if we can see what's going on. 198 10:11.520 --> 10:16.920 We'll go ahead and turn the debugging off right away because we already see a 199 10:16.920 --> 10:17.080 problem. 200 10:17.080 --> 10:22.090 Here we see where TCP picks a random local port and begins its outbound 201 10:22.090 --> 10:23.560 connection trying 202 10:23.560 --> 10:30.160 to connect to the 204 dot 186 dot 28 dot two port 179. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 202 10:23.560 --> 10:30.160 to connect to the 204 dot 186 dot 28 dot two port 179. 203 10:30.160 --> 10:34.150 This is it trying to make the connection, but then notice a little bit further 204 10:34.150 --> 10:34.760 down, 205 10:34.760 --> 10:37.280 we get a bad segment. 206 10:37.280 --> 10:42.000 It closes the connection and here's the critical message. 207 10:42.000 --> 10:48.160 Connection closed remote sent a reset or an RST. 208 10:48.160 --> 10:49.720 Remember what we said. 209 10:49.720 --> 10:54.520 If we get a reset from the other side, it basically means that we're either 210 10:54.520 --> 10:55.680 sourcing it from the 211 10:55.680 --> 11:00.720 wrong address or they have their neighbor statement wrong. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 211 10:55.680 --> 11:00.720 wrong address or they have their neighbor statement wrong. 212 11:00.720 --> 11:04.000 One side is incorrect about the IP address. 213 11:04.000 --> 11:08.570 Now for this example, we're supposed to be sourcing it from our egress 214 11:08.570 --> 11:09.640 interface. 215 11:09.640 --> 11:11.760 So router aid is correct. 216 11:11.760 --> 11:14.440 Let's go take a look at router two. 217 11:14.440 --> 11:18.740 So let's do our show TCP brief all here on router two and a couple very 218 11:18.740 --> 11:20.000 important things 219 11:20.000 --> 11:21.840 to note here. 220 11:21.840 --> 11:28.080 First with these two entries, we see that we have two established connections. 221 11:28.080 --> 11:31.620 One is from router two to router one and the other one is from router two to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 221 11:28.080 --> 11:31.620 One is from router two to router one and the other one is from router two to 222 11:31.620 --> 11:32.880 router four. 223 11:32.880 --> 11:38.480 Now you might know here that one side is a random port and one side is the port 224 11:38.480 --> 11:39.720 179. 225 11:39.720 --> 11:45.390 This is a whole big complicated discussion, but the short version is BGP will 226 11:45.390 --> 11:46.120 create two 227 11:46.120 --> 11:50.120 sessions between each device and then tear one down. 228 11:50.120 --> 11:54.640 So you end up with one TCP session between the devices. 229 11:54.640 --> 12:01.410 Then we have down here where it's listening on port 179, but only routers four WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 229 11:54.640 --> 12:01.410 Then we have down here where it's listening on port 179, but only routers four 230 12:01.410 --> 12:02.440 and one. 231 12:02.440 --> 12:04.720 Router eight is not here. 232 12:04.720 --> 12:08.200 So let's look at our running configuration here for BGP. 233 12:08.200 --> 12:12.920 And what we see is that router eight is not even listed here as a neighbor. 234 12:12.920 --> 12:16.990 Now of course router eight should be a neighbor and router eight should be 235 12:16.990 --> 12:18.760 configured the same 236 12:18.760 --> 12:20.520 as router four. 237 12:20.520 --> 12:26.200 So what we can do here is we can go into configuration mode, go into BGP. 238 12:26.200 --> 12:30.890 And what I did real quick is I took those lines for router four, copied them WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 238 12:26.200 --> 12:30.890 And what I did real quick is I took those lines for router four, copied them 239 12:30.890 --> 12:32.200 into notepad, 240 12:32.200 --> 12:36.010 changed the neighbor statement to be router eight and then just pasted the 241 12:36.010 --> 12:36.640 lines back 242 12:36.640 --> 12:37.640 in. 243 12:37.640 --> 12:43.360 That way everything is configured and we see that router eight just came up. 244 12:43.360 --> 12:48.640 If we do a show TCP brief all, we now see right here where we have our 245 12:48.640 --> 12:50.360 established TCP 246 12:50.360 --> 12:53.280 session to router eight. 247 12:53.280 --> 12:59.110 And we can see right here where it's now listening to TCP port 179 traffic from 248 12:59.110 --> 12:59.640 router 249 12:59.640 --> 13:00.880 eight. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 249 12:59.640 --> 13:00.880 eight. 250 13:00.880 --> 13:04.210 So now let's go back over to router eight because again, we always want to 251 13:04.210 --> 13:04.760 verify the 252 13:04.760 --> 13:06.720 original ticket. 253 13:06.720 --> 13:09.760 Pretty good indicator that it's already working is noticed that our tunnels 254 13:09.760 --> 13:10.520 have already come 255 13:10.520 --> 13:11.520 up. 256 13:11.520 --> 13:18.360 Now that we have the BGP updates, but just to verify show IP route BGP. 257 13:18.360 --> 13:23.360 And as you can see here, yes, we do in fact have our BGP updates. 258 13:23.360 --> 13:26.710 And by the way, just since we haven't looked at them a lot, let's also look at 259 13:26.710 --> 13:27.200 the show 260 13:27.200 --> 13:29.720 IP BGP summary here. 261 13:29.720 --> 13:33.640 This is of course what it should look like when it's all up and working. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 261 13:29.720 --> 13:33.640 This is of course what it should look like when it's all up and working. 262 13:33.640 --> 13:37.860 We see that under our state and prefixes, we have a number indicating that it's 263 13:37.860 --> 13:38.640 established 264 13:38.640 --> 13:41.520 and how many prefixes we've received. 265 13:41.520 --> 13:44.480 And of course, never forget the show IP BGP. 266 13:44.480 --> 13:47.570 We haven't really needed this one yet in our troubleshooting, but this one will 267 13:47.570 --> 13:47.840 show 268 13:47.840 --> 13:49.840 the BGP table. 269 13:49.840 --> 13:54.660 Most importantly, it shows at the very first column, an asterisk indicating 270 13:54.660 --> 13:56.560 that it's valid. 271 13:56.560 --> 14:01.040 We do have this one R here indicating that this is a rib failure. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 271 13:56.560 --> 14:01.040 We do have this one R here indicating that this is a rib failure. 272 14:01.040 --> 14:02.720 That's perfectly fine. 273 14:02.720 --> 14:08.800 It means that we learned this 204 dot 186 dot 28 dot zero through BGP. 274 14:08.800 --> 14:12.360 However, that is a directly connected interface. 275 14:12.360 --> 14:19.640 Therefore, directly connected one, the administrative distance battle over BGP. 276 14:19.640 --> 14:23.650 And therefore, BGP has selected that route as the best, but it's not in the 277 14:23.650 --> 14:25.080 routing table 278 14:25.080 --> 14:29.040 because it's in the routing table as a local route. 279 14:29.040 --> 14:32.440 Then of course, we have the marker here indicating that it's best. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 279 14:29.040 --> 14:32.440 Then of course, we have the marker here indicating that it's best. 280 14:32.440 --> 14:35.240 We see the network, the next hop. 281 14:35.240 --> 14:40.290 We see the metric, the local pref and the weight attributes followed by the 282 14:40.290 --> 14:40.920 path. 283 14:40.920 --> 14:44.000 This of course is the AS path column. 284 14:44.000 --> 14:48.840 And then at the end of the AS path are the origin codes. 285 14:48.840 --> 14:53.000 This is where it'll either be an I, an E or a question mark. 286 14:53.000 --> 14:56.540 But even though we looked at a few extra show commands here, this does in fact 287 14:56.540 --> 14:57.080 complete 288 14:57.080 --> 14:58.400 ticket to. 289 14:58.400 --> 15:01.520 So now let's go back and look at ticket three. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 289 14:58.400 --> 15:01.520 So now let's go back and look at ticket three. 290 15:01.520 --> 15:08.960 So for ticket three, router one is supposed to be injecting the 207 dot 45 dot 291 15:08.960 --> 15:10.080 145 dot 292 15:10.080 --> 15:15.600 64 network into BGP, but it is not. 293 15:15.600 --> 15:18.920 Now we might want to write down that address just to keep it handy. 294 15:18.920 --> 15:23.490 But let's also jump over to our diagram, although honestly, in this case, it's 295 15:23.490 --> 15:24.040 not going to 296 15:24.040 --> 15:26.360 do a whole lot of good. 297 15:26.360 --> 15:31.440 So here in the diagram, we're talking about router one, not injecting a route WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 297 15:26.360 --> 15:31.440 So here in the diagram, we're talking about router one, not injecting a route 298 15:31.440 --> 15:32.160 that it's 299 15:32.160 --> 15:33.880 supposed to. 300 15:33.880 --> 15:38.430 The diagram doesn't really help here because what you can't see on the diagram 301 15:38.430 --> 15:38.920 is that 302 15:38.920 --> 15:44.000 that is an address on a loopback interface on router one. 303 15:44.000 --> 15:48.620 Now router one is supposed to be injecting that into BGP and it's not, but we 304 15:48.620 --> 15:49.280 're going 305 15:49.280 --> 15:54.240 to have to just go and look at router one to see what's going on. 306 15:54.240 --> 15:58.560 But we are going to do this ticket just a little bit differently. 307 15:58.560 --> 16:02.170 Since we've already been through some troubleshooting together, we're going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 307 15:58.560 --> 16:02.170 Since we've already been through some troubleshooting together, we're going to 308 16:02.170 --> 16:03.160 use this ticket as 309 16:03.160 --> 16:04.680 our challenge. 310 16:04.680 --> 16:09.740 So you jump in, look at router one and see if we can figure out why it's not 311 16:09.740 --> 16:10.640 injecting 312 16:10.640 --> 16:13.800 that network into BGP. 313 16:13.800 --> 16:19.230 Give that a shot as our challenge and I'll see you in the solution video on the 314 16:19.230 --> 16:19.720 other 315 16:19.720 --> 16:20.200 side. 316 16:20.200 --> 16:30.160 [BLANK_AUDIO]