1 00:00:00,000 --> 00:00:03,416 [AUDIO LOGO] 2 00:00:03,416 --> 00:00:12,710 3 00:00:12,710 --> 00:00:16,400 Moving right along, we're on trouble ticket 5 now. 4 00:00:16,400 --> 00:00:21,440 We are still on MPLS topology 3, and we have yet sort 5 00:00:21,440 --> 00:00:23,810 of another easy ticket. 6 00:00:23,810 --> 00:00:29,000 Router 9, which is our customer A remote site 2 over here, 7 00:00:29,000 --> 00:00:34,160 is not receiving the routes from customer A headquarters. 8 00:00:34,160 --> 00:00:37,650 So we've had previous tickets similar to this, of course, 9 00:00:37,650 --> 00:00:41,270 on router 8, and now it seems that it's router 9's turn 10 00:00:41,270 --> 00:00:42,780 not to have the routes. 11 00:00:42,780 --> 00:00:45,530 So let's, of course, jump over to router 9 12 00:00:45,530 --> 00:00:49,860 and see if we can figure out what the issue is. 13 00:00:49,860 --> 00:00:52,380 As always, let's start with verifying the ticket. 14 00:00:52,380 --> 00:00:55,890 We'll just do a show IP route here on router 9. 15 00:00:55,890 --> 00:00:59,580 And we see that we are, in fact, not getting the routes 16 00:00:59,580 --> 00:01:01,350 from the headquarters. 17 00:01:01,350 --> 00:01:03,510 In fact, we don't have any routes 18 00:01:03,510 --> 00:01:08,460 at all, which in and of itself is incredibly suspicious. 19 00:01:08,460 --> 00:01:11,070 The reason it's suspicious is we don't even 20 00:01:11,070 --> 00:01:13,680 have any connected or local routes. 21 00:01:13,680 --> 00:01:15,880 We have no routes at all. 22 00:01:15,880 --> 00:01:17,910 Let's do a show IP interface brief 23 00:01:17,910 --> 00:01:20,730 and see if our interfaces are even configured. 24 00:01:20,730 --> 00:01:24,870 So we can see here that gigabit 1 and gigabit 2 25 00:01:24,870 --> 00:01:28,020 are properly configured with their IP addresses 26 00:01:28,020 --> 00:01:30,950 as they should be. 27 00:01:30,950 --> 00:01:34,700 Having interfaces configured with IP addresses 28 00:01:34,700 --> 00:01:37,160 and those interfaces being up up, 29 00:01:37,160 --> 00:01:39,890 yet not having local or connected routes 30 00:01:39,890 --> 00:01:43,160 in our routing table really sort of screams 31 00:01:43,160 --> 00:01:46,260 that these must be in a VRF. 32 00:01:46,260 --> 00:01:49,580 So let's take a look at this from the perspective of maybe 33 00:01:49,580 --> 00:01:53,050 there's a VRF here on router 9. 34 00:01:53,050 --> 00:01:56,920 So let's do a show VRF, and yep, here we 35 00:01:56,920 --> 00:02:02,200 see we have a VRF named WAN, and in that VRF are the loopback 36 00:02:02,200 --> 00:02:06,770 0, loopback 100, the gigabit 1, and the gigabit 2 interfaces. 37 00:02:06,770 --> 00:02:10,850 So now let's take a look at this from the VRF. 38 00:02:10,850 --> 00:02:15,400 So let's do a show IP route VRF WAN. 39 00:02:15,400 --> 00:02:17,680 Now, once again, we're not going to care too much 40 00:02:17,680 --> 00:02:20,080 about the local and connected, so let's go ahead 41 00:02:20,080 --> 00:02:23,620 and filter this out and just focus on the OSPF routes. 42 00:02:23,620 --> 00:02:26,800 We do have some OSPF routes here as we can see, 43 00:02:26,800 --> 00:02:30,190 but notice that they're all from router 8. 44 00:02:30,190 --> 00:02:34,240 So it means we're getting local OSPF routes 45 00:02:34,240 --> 00:02:38,440 into our VRF, but not the ones from headquarters, 46 00:02:38,440 --> 00:02:41,110 which of course, is what the ticket said. 47 00:02:41,110 --> 00:02:44,740 So now we have sort of a better validation 48 00:02:44,740 --> 00:02:46,690 that the ticket is correct. 49 00:02:46,690 --> 00:02:50,140 We have OSPF routes from the local site, 50 00:02:50,140 --> 00:02:52,390 but not from headquarters. 51 00:02:52,390 --> 00:02:54,920 So let's find out if they're in the database. 52 00:02:54,920 --> 00:02:59,110 Let's do a show IP OSPF database, 53 00:02:59,110 --> 00:03:03,490 these would be coming in as type 3 LSAs or summaries, 54 00:03:03,490 --> 00:03:06,550 and we know that there should at least be 10.6.6.6, 55 00:03:06,550 --> 00:03:08,810 which is router 6's loopback. 56 00:03:08,810 --> 00:03:12,250 So let's pick on something we know should be in the database 57 00:03:12,250 --> 00:03:14,410 here on router 9. 58 00:03:14,410 --> 00:03:17,020 So we see that we are, in fact, getting these entries 59 00:03:17,020 --> 00:03:21,040 into the database, but if we do a show IP OSPF RIB, 60 00:03:21,040 --> 00:03:24,100 let's see if they're being entered into the routing table. 61 00:03:24,100 --> 00:03:27,550 Notice that some of these are installed into the global RIB, 62 00:03:27,550 --> 00:03:29,360 but some of them are not. 63 00:03:29,360 --> 00:03:32,710 And notice that the entries from the other side, 64 00:03:32,710 --> 00:03:36,760 again, are not even listed here. 65 00:03:36,760 --> 00:03:38,370 So not only are they not making it 66 00:03:38,370 --> 00:03:40,590 into the global routing table, they're 67 00:03:40,590 --> 00:03:45,060 not even making it into the OSPF RIB, or Routing Information 68 00:03:45,060 --> 00:03:45,720 Base. 69 00:03:45,720 --> 00:03:50,040 So maybe we should take a closer look at those database entries. 70 00:03:50,040 --> 00:03:52,800 We can scroll up or we could just repeat that last command 71 00:03:52,800 --> 00:03:56,010 there and looking over these entries, 72 00:03:56,010 --> 00:04:01,490 we see something here that hopefully would jump out at us. 73 00:04:01,490 --> 00:04:07,190 We now know that router 9 is running OSPF in a VRF. 74 00:04:07,190 --> 00:04:10,160 And if we look at these database entries, 75 00:04:10,160 --> 00:04:15,260 we should see that the downward bit flag is set. 76 00:04:15,260 --> 00:04:20,209 And we know that if OSPF is running in a VRF 77 00:04:20,209 --> 00:04:24,990 on a Cisco router, that it implements PE loop prevention. 78 00:04:24,990 --> 00:04:27,290 So let's look at this a little bit closer 79 00:04:27,290 --> 00:04:30,260 and see if that's what's actually going on here. 80 00:04:30,260 --> 00:04:34,430 If we do show IP OSPF, another sort of giveaway 81 00:04:34,430 --> 00:04:38,150 here as to whether we're doing PE loop prevention 82 00:04:38,150 --> 00:04:43,100 is notice right here where it says that it is an area border 83 00:04:43,100 --> 00:04:44,090 router. 84 00:04:44,090 --> 00:04:47,300 This router thinks it's an ABR. 85 00:04:47,300 --> 00:04:51,140 Now, if we were to say show IP OSPF interface brief, 86 00:04:51,140 --> 00:04:54,650 all of its interfaces are in area 0. 87 00:04:54,650 --> 00:04:59,330 So realistically, it shouldn't think that it's an ABR. 88 00:04:59,330 --> 00:05:02,930 However, notice this statement right here. 89 00:05:02,930 --> 00:05:08,750 It says that it's connected to MPLS VPN Superbackbone 90 00:05:08,750 --> 00:05:11,300 through the VRF WAN. 91 00:05:11,300 --> 00:05:15,170 So yes, it thinks it's a PE, it thinks 92 00:05:15,170 --> 00:05:19,500 it's connected to the MPLS VPN Superbackbone, which of course, 93 00:05:19,500 --> 00:05:24,030 it's not, because router 9 is not even running MPLS. 94 00:05:24,030 --> 00:05:25,520 So not only does it think that it's 95 00:05:25,520 --> 00:05:28,310 connected to the superbackbone, but that also 96 00:05:28,310 --> 00:05:32,090 would make it an ABR, and therefore it's 97 00:05:32,090 --> 00:05:37,010 enforcing loop prevention based on the downward bit. 98 00:05:37,010 --> 00:05:39,230 Now, we know we have a fix for this. 99 00:05:39,230 --> 00:05:44,600 In order to get a router to not enforce PE loop prevention when 100 00:05:44,600 --> 00:05:47,870 it's running OSPF in a VRF, we need 101 00:05:47,870 --> 00:05:50,870 to use the capability VRF Lite. 102 00:05:50,870 --> 00:05:53,570 So let's turn that on here on router 9 103 00:05:53,570 --> 00:05:56,200 and see if it fixes our issue. 104 00:05:56,200 --> 00:06:01,660 We simply go into configuration mode into router ospf 1, 105 00:06:01,660 --> 00:06:05,110 and it's simply capability vrf-lite. 106 00:06:05,110 --> 00:06:07,400 We'll end our configuration. 107 00:06:07,400 --> 00:06:09,160 Now, we see here that it does bounce 108 00:06:09,160 --> 00:06:10,450 all of its neighborships. 109 00:06:10,450 --> 00:06:13,210 So you could make the argument that you should do this 110 00:06:13,210 --> 00:06:16,240 during a maintenance window, but the flip side of that 111 00:06:16,240 --> 00:06:18,610 is this wasn't working anyway, that's 112 00:06:18,610 --> 00:06:20,630 why we're here troubleshooting the router. 113 00:06:20,630 --> 00:06:22,510 So doing it right in the middle of the day 114 00:06:22,510 --> 00:06:26,240 might not be a problem if we're actually fixing a problem. 115 00:06:26,240 --> 00:06:29,650 So now that it's reset all of its neighborships, let's 116 00:06:29,650 --> 00:06:31,340 see what's changed. 117 00:06:31,340 --> 00:06:34,900 Let's go ahead and start with that show IP OSPF. 118 00:06:34,900 --> 00:06:38,560 Now, unfortunately, I can't highlight on our screen 119 00:06:38,560 --> 00:06:41,090 something that's not here. 120 00:06:41,090 --> 00:06:43,120 But if you look over this and maybe 121 00:06:43,120 --> 00:06:46,780 if you rewind a little bit and look at the previous output 122 00:06:46,780 --> 00:06:50,710 to see where it's supposed to be, you might notice, A, 123 00:06:50,710 --> 00:06:54,100 that this no longer says that it's connected to the MPLS 124 00:06:54,100 --> 00:06:58,930 Superbackbone, neither does it say that it's an ABR. 125 00:06:58,930 --> 00:07:02,440 So that's one good indicator that it no longer 126 00:07:02,440 --> 00:07:04,600 thinks that it's a PE. 127 00:07:04,600 --> 00:07:08,410 Of course, another good one would be show IP OSPF RIB, 128 00:07:08,410 --> 00:07:10,340 and we see now that we do, in fact, 129 00:07:10,340 --> 00:07:13,630 have the entries from router 6-- there are two of them here-- 130 00:07:13,630 --> 00:07:15,670 not counting the transit link, which we're not 131 00:07:15,670 --> 00:07:17,710 concerned with right now. 132 00:07:17,710 --> 00:07:24,520 But we have the 10.6.6.6/32 and the 10.100.1.6/32, 133 00:07:24,520 --> 00:07:27,430 which are both routes over at headquarters. 134 00:07:27,430 --> 00:07:34,150 And if we do a show IP route VRF WAN and we filter for OSPF, 135 00:07:34,150 --> 00:07:37,090 we see that now we are getting those O IA 136 00:07:37,090 --> 00:07:40,450 routes coming from router 6, those entries 137 00:07:40,450 --> 00:07:42,530 that we were just discussing. 138 00:07:42,530 --> 00:07:47,590 So capability VRF Lite did in fact fix our issue. 139 00:07:47,590 --> 00:07:50,670 So in this video, we saw an example 140 00:07:50,670 --> 00:07:54,750 of a customer using a VRF, in this case 141 00:07:54,750 --> 00:07:59,970 called WAN, to run their OSPF instance for their VPN 142 00:07:59,970 --> 00:08:01,360 connections. 143 00:08:01,360 --> 00:08:03,030 Now, there's nothing wrong with this 144 00:08:03,030 --> 00:08:04,980 and a customer may choose to do this 145 00:08:04,980 --> 00:08:07,420 for a variety of different reasons. 146 00:08:07,420 --> 00:08:09,930 However, we did see a side effect here. 147 00:08:09,930 --> 00:08:12,900 First, it means that it's going to implement PE loop 148 00:08:12,900 --> 00:08:14,940 prevention, which means it's going 149 00:08:14,940 --> 00:08:19,680 to be looking at that downward bit set in the OSPF LSAs. 150 00:08:19,680 --> 00:08:22,710 And if the downward bit is set on the route, 151 00:08:22,710 --> 00:08:24,790 we will not use it. 152 00:08:24,790 --> 00:08:27,000 Now, it, of course, is still in the database-- 153 00:08:27,000 --> 00:08:28,360 and we saw that-- 154 00:08:28,360 --> 00:08:31,440 but it doesn't get eligibility for entry 155 00:08:31,440 --> 00:08:35,820 into either the OSPF RIB or the global RIB. 156 00:08:35,820 --> 00:08:38,250 The router also thinks that it's connected 157 00:08:38,250 --> 00:08:44,039 to the MPLS Superbackbone, and therefore is an ABR. 158 00:08:44,039 --> 00:08:47,670 Now, to fix this, of course, since the customer does, 159 00:08:47,670 --> 00:08:50,550 in fact, want to use a VRF, but they are not, 160 00:08:50,550 --> 00:08:53,080 in fact, going to be running MPLS, 161 00:08:53,080 --> 00:08:57,160 this is where the capability VRF Lite comes into play. 162 00:08:57,160 --> 00:08:59,070 It essentially says to the router, 163 00:08:59,070 --> 00:09:03,450 yes, you are running OSPF and yes, it's in a VRF, 164 00:09:03,450 --> 00:09:07,350 but that doesn't automatically make you a PE. 165 00:09:07,350 --> 00:09:11,400 So don't be PE, you are not connected to the MPLS 166 00:09:11,400 --> 00:09:15,640 Superbackbone, you're not going to have to do loop prevention, 167 00:09:15,640 --> 00:09:19,680 looking at the downward bit, and you're not an ABR. 168 00:09:19,680 --> 00:09:22,290 And that's of course, it actually was an ABR, 169 00:09:22,290 --> 00:09:25,260 but in this case, it wasn't because all of its interfaces 170 00:09:25,260 --> 00:09:27,060 were in area 0. 171 00:09:27,060 --> 00:09:31,320 So at the end of all of this, we just have to remember to sum 172 00:09:31,320 --> 00:09:37,770 this up that if you're going to use OSPF with a VRF on any 173 00:09:37,770 --> 00:09:40,050 router really-- but it would commonly be 174 00:09:40,050 --> 00:09:41,820 on the customer's router-- 175 00:09:41,820 --> 00:09:44,580 that we have to do capability VRF Lite, 176 00:09:44,580 --> 00:09:47,160 or else that router is going to think 177 00:09:47,160 --> 00:09:51,670 that it's a service provider PE router and act accordingly. 178 00:09:51,670 --> 00:09:54,690 So this definitely fixed our problem and everything 179 00:09:54,690 --> 00:09:58,080 is working just fine now on router 9. 180 00:09:58,080 --> 00:10:00,270 I hope this has been informative for you, 181 00:10:00,270 --> 00:10:03,350 and I'd like to thank you for viewing. 182 00:10:03,350 --> 00:10:07,000