1 00:00:00,000 --> 00:00:03,792 [AUDIO LOGO] 2 00:00:03,792 --> 00:00:08,060 3 00:00:08,060 --> 00:00:10,700 So the first thing we want to do is take a look 4 00:00:10,700 --> 00:00:16,010 at controlling OSPF route types in our layer 3 MPLS VPN 5 00:00:16,010 --> 00:00:17,060 environment. 6 00:00:17,060 --> 00:00:20,040 But what exactly does that mean? 7 00:00:20,040 --> 00:00:21,830 Well, in our current environment, 8 00:00:21,830 --> 00:00:24,980 the way it's configured, which we will be reviewing in just 9 00:00:24,980 --> 00:00:30,230 a moment, the OSPF routes going between the headquarters 10 00:00:30,230 --> 00:00:32,900 and the remote sites for the customers 11 00:00:32,900 --> 00:00:37,100 are coming in as OSPF external routes. 12 00:00:37,100 --> 00:00:39,320 Now, obviously, that's not going to be 13 00:00:39,320 --> 00:00:41,540 very ideal for the customer. 14 00:00:41,540 --> 00:00:44,120 From the customer's perspective, these 15 00:00:44,120 --> 00:00:48,350 should be internal routes, certainly not external. 16 00:00:48,350 --> 00:00:51,260 However, they're coming in as external routes 17 00:00:51,260 --> 00:00:53,960 because, of course, they're passing through BGP 18 00:00:53,960 --> 00:00:56,700 redistribution in the middle. 19 00:00:56,700 --> 00:01:01,560 Now, if we configure our service provider environment correctly, 20 00:01:01,560 --> 00:01:04,760 then we can have their routes come through as internal. 21 00:01:04,760 --> 00:01:06,290 And that's exactly what we're going 22 00:01:06,290 --> 00:01:08,820 to be exploring in this video. 23 00:01:08,820 --> 00:01:12,500 So let's start off by taking a look at the current situation 24 00:01:12,500 --> 00:01:13,970 on our topology. 25 00:01:13,970 --> 00:01:16,470 Then we'll talk about what we're trying to accomplish. 26 00:01:16,470 --> 00:01:19,130 And then of course, we'll jump into the command line 27 00:01:19,130 --> 00:01:22,890 and see all of this in action. 28 00:01:22,890 --> 00:01:26,990 So for this video, we'll be using MPLS Topology 3. 29 00:01:26,990 --> 00:01:30,980 And let's talk about what we currently have configured. 30 00:01:30,980 --> 00:01:33,900 First, we know that our core network is, of course, 31 00:01:33,900 --> 00:01:37,790 running OSPF and BGP. 32 00:01:37,790 --> 00:01:41,000 The important aspect of our BGP configuration 33 00:01:41,000 --> 00:01:45,020 is we have neighborships between the route reflector 34 00:01:45,020 --> 00:01:49,580 and routers 1, 2, and 5. 35 00:01:49,580 --> 00:01:53,330 So multiprotocol BGP is already configured. 36 00:01:53,330 --> 00:01:57,890 There is a VRF for customer A created on router 1. 37 00:01:57,890 --> 00:02:03,770 There are actually two VRFs for customer A created on router 5. 38 00:02:03,770 --> 00:02:06,110 Router 1 and router 5 are configured 39 00:02:06,110 --> 00:02:11,930 to do mutual redistribution between OSPF and BGP. 40 00:02:11,930 --> 00:02:16,010 And probably the most important thing for this particular video 41 00:02:16,010 --> 00:02:21,260 is that customer A is also configured to run OSPF. 42 00:02:21,260 --> 00:02:25,160 And their devices are all in area 0. 43 00:02:25,160 --> 00:02:28,130 So we can already begin to see why the routes are 44 00:02:28,130 --> 00:02:30,200 coming through as external. 45 00:02:30,200 --> 00:02:35,270 Router 6, for example, sends an update to router 1. 46 00:02:35,270 --> 00:02:40,190 Router 1 does it's redistribution into BGP. 47 00:02:40,190 --> 00:02:43,010 That then gets sent up to the route reflector. 48 00:02:43,010 --> 00:02:46,640 The route reflector reflects it back down to router 5-- 49 00:02:46,640 --> 00:02:47,820 router 2 as well. 50 00:02:47,820 --> 00:02:50,210 But that's not part of our current discussion. 51 00:02:50,210 --> 00:02:54,860 And then of course, router 5 does its redistribution back 52 00:02:54,860 --> 00:02:59,450 into OSPF and sends it back out to the customer sites. 53 00:02:59,450 --> 00:03:04,100 The problem is that from an OSPF perspective, that 54 00:03:04,100 --> 00:03:09,350 makes these updates right here, by default, E2s, 55 00:03:09,350 --> 00:03:11,900 or external type twos. 56 00:03:11,900 --> 00:03:15,380 And of course, the problem is this is the same customer. 57 00:03:15,380 --> 00:03:18,740 It's customer A at all three of these locations. 58 00:03:18,740 --> 00:03:21,980 Their routes should be internal. 59 00:03:21,980 --> 00:03:26,420 Remember, the fundamental principle of layer 3 VPN 60 00:03:26,420 --> 00:03:29,060 is we're supposed to be acting as a WAN 61 00:03:29,060 --> 00:03:31,260 service for the customer. 62 00:03:31,260 --> 00:03:33,860 So in theory, we should sort of be 63 00:03:33,860 --> 00:03:37,440 invisible in this environment as the service provider. 64 00:03:37,440 --> 00:03:41,240 Now, we can't completely do that with OSPF. 65 00:03:41,240 --> 00:03:43,760 We'll see that as we go through this video. 66 00:03:43,760 --> 00:03:47,330 Yes, we can get the routes to show up as internal. 67 00:03:47,330 --> 00:03:51,080 But without a whole lot of work, which we'll also discuss, 68 00:03:51,080 --> 00:03:54,110 we can't have them actually show up as if they're 69 00:03:54,110 --> 00:03:56,070 coming from the same area. 70 00:03:56,070 --> 00:03:59,420 So as we proceed, keep in mind that these 71 00:03:59,420 --> 00:04:01,250 are in the same area. 72 00:04:01,250 --> 00:04:04,010 But the routes are still going to come through as 73 00:04:04,010 --> 00:04:05,840 if they're in different areas. 74 00:04:05,840 --> 00:04:08,300 But at least we can make them internal. 75 00:04:08,300 --> 00:04:10,680 And that's what we're going to be shooting to do. 76 00:04:10,680 --> 00:04:13,070 So let's first jump into the command line 77 00:04:13,070 --> 00:04:15,680 and take a look at what the current problem is 78 00:04:15,680 --> 00:04:18,209 and why they're not showing up that way. 79 00:04:18,209 --> 00:04:22,350 And then, of course, we'll make that happen. 80 00:04:22,350 --> 00:04:26,630 So we can start here on router 6 just by doing a show ip route. 81 00:04:26,630 --> 00:04:30,230 And we can see that we have OSPF routes 82 00:04:30,230 --> 00:04:33,540 for all the networks on the other side-- in other words, 83 00:04:33,540 --> 00:04:34,830 the remote sites. 84 00:04:34,830 --> 00:04:38,240 However, we can also see that all of the OSPF routes 85 00:04:38,240 --> 00:04:41,780 are in fact showing up as external type twos, 86 00:04:41,780 --> 00:04:43,820 just as we said they would. 87 00:04:43,820 --> 00:04:46,220 And from our discussion, hopefully, we now 88 00:04:46,220 --> 00:04:48,770 understand why, because they are being 89 00:04:48,770 --> 00:04:50,840 redistributed through BGP. 90 00:04:50,840 --> 00:04:53,820 And our environment is working perfectly fine. 91 00:04:53,820 --> 00:04:56,570 If we were to trace to, say, router 8's loopback 92 00:04:56,570 --> 00:04:59,330 and source it from our loopback, we 93 00:04:59,330 --> 00:05:02,280 can see that this works perfectly fine. 94 00:05:02,280 --> 00:05:04,190 Now, even though this is working, 95 00:05:04,190 --> 00:05:07,260 it's really not ideal for the customer. 96 00:05:07,260 --> 00:05:10,130 The customer doesn't want their OSPF routes 97 00:05:10,130 --> 00:05:11,990 showing up as external. 98 00:05:11,990 --> 00:05:15,170 If for no other reason, keep in mind 99 00:05:15,170 --> 00:05:18,980 that part of the OSPF route selection process 100 00:05:18,980 --> 00:05:23,610 is to choose internal routes over external routes. 101 00:05:23,610 --> 00:05:27,320 So if they had other links to these remote sites, 102 00:05:27,320 --> 00:05:29,960 such as maybe a backup link, this 103 00:05:29,960 --> 00:05:31,890 is going to really create a problem. 104 00:05:31,890 --> 00:05:35,570 Now, that is a problem we will be addressing in an upcoming 105 00:05:35,570 --> 00:05:37,230 video in this skill. 106 00:05:37,230 --> 00:05:38,810 So we're going to get there. 107 00:05:38,810 --> 00:05:42,410 But overall, we really don't want customer routes 108 00:05:42,410 --> 00:05:45,050 to show up for the customer as external. 109 00:05:45,050 --> 00:05:47,720 So let's take a look at why this is happening 110 00:05:47,720 --> 00:05:49,650 and what we can do to fix it. 111 00:05:49,650 --> 00:05:52,790 So to do that, let's jump over to router 1. 112 00:05:52,790 --> 00:05:54,770 And let's take a look at what these routes look 113 00:05:54,770 --> 00:05:58,100 like right now in BGP. 114 00:05:58,100 --> 00:06:04,520 So let's start by doing a show bgp vpnv4 unicast for the vrf 115 00:06:04,520 --> 00:06:08,360 Customer A. And let's look specifically at that prefix 116 00:06:08,360 --> 00:06:12,680 that we were just focusing on, the 10.8.8.8. 117 00:06:12,680 --> 00:06:16,040 So we can see here that we have two different paths coming 118 00:06:16,040 --> 00:06:17,720 from router 5. 119 00:06:17,720 --> 00:06:20,300 One of those would be from router 8. 120 00:06:20,300 --> 00:06:24,780 One of them would be from router 9 on the other side. 121 00:06:24,780 --> 00:06:27,350 Now, the way that we're going to get these routes to come 122 00:06:27,350 --> 00:06:33,590 through as OSPF internal is for these OSPF extended community 123 00:06:33,590 --> 00:06:37,890 attributes to actually match on both sides. 124 00:06:37,890 --> 00:06:40,220 Now, something like the router ID 125 00:06:40,220 --> 00:06:41,730 that it's learned from, of course, 126 00:06:41,730 --> 00:06:44,900 won't match, just like in normal OSPF. 127 00:06:44,900 --> 00:06:50,300 But the domain ID and the route type are going to be critical. 128 00:06:50,300 --> 00:06:54,290 Our main focus is going to be on the domain ID. 129 00:06:54,290 --> 00:06:57,830 If we focus on the domain ID, notice that it 130 00:06:57,830 --> 00:07:01,520 starts with a 0x5 colon. 131 00:07:01,520 --> 00:07:04,820 That is actually the domain ID type. 132 00:07:04,820 --> 00:07:07,250 This is then followed by the domain ID 133 00:07:07,250 --> 00:07:10,970 itself, which are the next 4 bytes, which 134 00:07:10,970 --> 00:07:13,560 is this section of the number right here. 135 00:07:13,560 --> 00:07:16,200 This is then followed by two more bytes, 136 00:07:16,200 --> 00:07:19,730 which are actually unused. 137 00:07:19,730 --> 00:07:23,030 If we take a look here at this knowledge base article, 138 00:07:23,030 --> 00:07:26,960 talking specifically about the OSPF domain identifier, 139 00:07:26,960 --> 00:07:31,280 we can actually see how it's split up between the domain ID 140 00:07:31,280 --> 00:07:34,560 type and the actual value. 141 00:07:34,560 --> 00:07:37,940 If we go down here a little bit further, focusing in on point 1 142 00:07:37,940 --> 00:07:43,460 here, the OSPF domain ID, which is a total of 8 bytes, 143 00:07:43,460 --> 00:07:46,160 this says, on Cisco IOS-- 144 00:07:46,160 --> 00:07:50,462 and they mean specifically IOS XE. 145 00:07:50,462 --> 00:07:51,920 We're going to see in just a moment 146 00:07:51,920 --> 00:07:56,250 that IOS XR does not do exactly the same thing here. 147 00:07:56,250 --> 00:07:58,460 However, what they are saying is that it's 148 00:07:58,460 --> 00:08:04,160 set to the OSPF process ID by default. 149 00:08:04,160 --> 00:08:06,210 And this is what we're going to want to change. 150 00:08:06,210 --> 00:08:08,400 We'll see why in just a moment. 151 00:08:08,400 --> 00:08:13,310 So like we said, it starts off with that 2-byte Type field. 152 00:08:13,310 --> 00:08:19,100 And for Cisco, it actually defaults to 0005. 153 00:08:19,100 --> 00:08:22,680 Now, we really have no good reason to change that. 154 00:08:22,680 --> 00:08:25,070 But there are a few other ones available-- 155 00:08:25,070 --> 00:08:29,840 0105 and 0205. 156 00:08:29,840 --> 00:08:31,680 But again, we're not going to do that. 157 00:08:31,680 --> 00:08:34,470 We're just going to go with the Cisco default. 158 00:08:34,470 --> 00:08:37,130 We have no good reason to change the type. 159 00:08:37,130 --> 00:08:38,900 We don't even really have to understand 160 00:08:38,900 --> 00:08:41,520 what the different types are, although, of course, 161 00:08:41,520 --> 00:08:43,610 they are documented out there. 162 00:08:43,610 --> 00:08:46,520 What we're going to care about is the actual domain 163 00:08:46,520 --> 00:08:50,100 identification section, as we pointed that out. 164 00:08:50,100 --> 00:08:52,290 So now that we have a little more information here, 165 00:08:52,290 --> 00:08:57,670 let's go ahead and jump back and take a look at our domain ID. 166 00:08:57,670 --> 00:09:01,660 So now that we understand all of that about our domain ID, 167 00:09:01,660 --> 00:09:06,490 we can see here that this path has a domain ID of 65. 168 00:09:06,490 --> 00:09:09,730 And this one is 66. 169 00:09:09,730 --> 00:09:16,360 Those are the hex equivalents of the process ID on router 5. 170 00:09:16,360 --> 00:09:20,440 If we look here on router 5, when we do a show ip ospf, 171 00:09:20,440 --> 00:09:23,690 remember that we have this routing process right here, 172 00:09:23,690 --> 00:09:30,810 which is OSPF 101 and this process that's OSPF 102-- 173 00:09:30,810 --> 00:09:35,640 again, the equivalence of 65 and 66. 174 00:09:35,640 --> 00:09:38,550 But if we go back over to router 1, 175 00:09:38,550 --> 00:09:41,190 and instead of looking at that loopback, what if we look 176 00:09:41,190 --> 00:09:44,160 at the one coming from IOS XR coming 177 00:09:44,160 --> 00:09:46,410 from customer headquarters? 178 00:09:46,410 --> 00:09:50,730 Notice that IOS XR is just a bit different here. 179 00:09:50,730 --> 00:09:52,620 Now, we still have the entry. 180 00:09:52,620 --> 00:09:55,680 And notice we still have extended communities, where 181 00:09:55,680 --> 00:09:59,730 we have the OSPF route type, the OSPF router ID, the route 182 00:09:59,730 --> 00:10:01,240 target, and so on. 183 00:10:01,240 --> 00:10:05,820 But notice what's missing is the domain ID. 184 00:10:05,820 --> 00:10:09,420 IOS XR running here on router 1, which 185 00:10:09,420 --> 00:10:12,300 is what's responsible for originating this path, 186 00:10:12,300 --> 00:10:17,610 is not setting the domain ID to the OSPF process ID by default. 187 00:10:17,610 --> 00:10:21,940 Instead, it sets it to a null value. 188 00:10:21,940 --> 00:10:24,240 So here's the fundamental problem. 189 00:10:24,240 --> 00:10:28,620 When OSPF redistributes these BGP routes, 190 00:10:28,620 --> 00:10:32,340 it looks at these values, and not just the domain 191 00:10:32,340 --> 00:10:35,290 ID but the route type as well. 192 00:10:35,290 --> 00:10:39,610 But it looks at these values and sees if they match. 193 00:10:39,610 --> 00:10:44,670 If they match, it will send it into OSPF as an internal route. 194 00:10:44,670 --> 00:10:48,520 If they don't match, well, we've seen the result. 195 00:10:48,520 --> 00:10:51,810 It will come in as an OSPF external route. 196 00:10:51,810 --> 00:10:54,300 So the easiest way to make these routes 197 00:10:54,300 --> 00:10:57,390 show up as internal is simply this. 198 00:10:57,390 --> 00:11:02,520 We just have to make the domain ID match on all of the VRFs 199 00:11:02,520 --> 00:11:05,110 for a particular customer. 200 00:11:05,110 --> 00:11:09,300 So usually, there would be like a customer ID associated 201 00:11:09,300 --> 00:11:10,470 with each customer. 202 00:11:10,470 --> 00:11:13,110 And we would probably just set their domain ID 203 00:11:13,110 --> 00:11:14,850 to match that value. 204 00:11:14,850 --> 00:11:18,330 In this case, we've been using 100 205 00:11:18,330 --> 00:11:22,230 to be customer A, just based on our route targets 206 00:11:22,230 --> 00:11:23,410 and things like that. 207 00:11:23,410 --> 00:11:25,510 So let's just go ahead and stick with that. 208 00:11:25,510 --> 00:11:29,340 And let's set our domain ID to 100, or ultimately, 209 00:11:29,340 --> 00:11:33,000 what's going to be 64, once it gets converted into hex. 210 00:11:33,000 --> 00:11:37,710 So let's take a look at how to do that on IOS XR and IOS XE, 211 00:11:37,710 --> 00:11:40,630 because they are, of course, just a little bit different. 212 00:11:40,630 --> 00:11:43,860 So let's start on IOS XR since we're already here. 213 00:11:43,860 --> 00:11:47,590 All we have to do is go into the router ospf process. 214 00:11:47,590 --> 00:11:49,470 We'll go into our vrf. 215 00:11:49,470 --> 00:11:51,990 And we'll start by setting the domain-id. 216 00:11:51,990 --> 00:11:54,405 The first thing it wants is type. 217 00:11:54,405 --> 00:11:55,780 And you can see here, by the way, 218 00:11:55,780 --> 00:11:58,350 we can also set a secondary domain ID. 219 00:11:58,350 --> 00:12:01,650 So we could do this if we had a need to have more than one. 220 00:12:01,650 --> 00:12:03,610 But we really don't, in this case, 221 00:12:03,610 --> 00:12:05,650 since it's not setting one at all. 222 00:12:05,650 --> 00:12:07,470 So we'll set the type. 223 00:12:07,470 --> 00:12:09,360 And here we can see those different types 224 00:12:09,360 --> 00:12:10,770 that we said were available. 225 00:12:10,770 --> 00:12:13,710 And again, we'll just stick with Cisco's default 226 00:12:13,710 --> 00:12:15,600 since we already know that that's 227 00:12:15,600 --> 00:12:17,970 what IOS XE is setting anyway. 228 00:12:17,970 --> 00:12:21,210 So we'll just do 0005. 229 00:12:21,210 --> 00:12:24,570 The next thing it's going to want is the value. 230 00:12:24,570 --> 00:12:28,020 And here we have to put the whole thing in, in hex. 231 00:12:28,020 --> 00:12:30,990 It wants all six octets. 232 00:12:30,990 --> 00:12:35,190 So we'll put in six zeros for the first three octets. 233 00:12:35,190 --> 00:12:37,590 Then we'll put in our 64. 234 00:12:37,590 --> 00:12:41,010 And again, even though they're not technically used, 235 00:12:41,010 --> 00:12:43,890 Cisco does set these to 0200. 236 00:12:43,890 --> 00:12:45,330 So we just need to make sure it's 237 00:12:45,330 --> 00:12:48,330 going to match what's coming from IOS XE. 238 00:12:48,330 --> 00:12:52,620 And if we look back up above, notice right here, 239 00:12:52,620 --> 00:12:57,040 it's putting that 0200 after the domain ID. 240 00:12:57,040 --> 00:13:00,453 So we're going to do the same thing so that they match. 241 00:13:00,453 --> 00:13:01,620 So that's all we have to do. 242 00:13:01,620 --> 00:13:03,420 We'll just hit Enter. 243 00:13:03,420 --> 00:13:05,320 Commit the change. 244 00:13:05,320 --> 00:13:07,870 And we'll exit configuration mode. 245 00:13:07,870 --> 00:13:12,400 Now, remember, router 5 is still using the OSPF process ID. 246 00:13:12,400 --> 00:13:15,630 So we have to go change router 5 as well. 247 00:13:15,630 --> 00:13:18,390 So we simply go into configuration mode. 248 00:13:18,390 --> 00:13:21,770 We'll start with router ospf 101. 249 00:13:21,770 --> 00:13:23,540 We'll set the domain-id. 250 00:13:23,540 --> 00:13:26,690 And in IOS XE, there's actually a few different ways 251 00:13:26,690 --> 00:13:27,930 we could do this. 252 00:13:27,930 --> 00:13:30,860 We could, if we wanted to, do the whole type thing, 253 00:13:30,860 --> 00:13:33,530 put in those same type values. 254 00:13:33,530 --> 00:13:36,660 And then we could, again, put in the value. 255 00:13:36,660 --> 00:13:39,170 So again, could we do this the same way? 256 00:13:39,170 --> 00:13:42,540 Yes, we absolutely could, if we wanted to. 257 00:13:42,540 --> 00:13:46,520 But on IOS XE, there's actually an easier way here. 258 00:13:46,520 --> 00:13:50,190 We can literally just put it in, in IP format. 259 00:13:50,190 --> 00:13:56,420 So we can say 0.0.0.100 to set this to 64. 260 00:13:56,420 --> 00:13:58,910 Really, whichever way works better for you, 261 00:13:58,910 --> 00:14:02,600 you can, of course, do it either way here on IOS XE. 262 00:14:02,600 --> 00:14:04,730 So we'll do it like this just to show you 263 00:14:04,730 --> 00:14:07,950 that they do in fact work together just fine. 264 00:14:07,950 --> 00:14:11,330 We'll do the exact same thing in router ospf 102, 265 00:14:11,330 --> 00:14:15,110 again setting it to the exact same domain ID. 266 00:14:15,110 --> 00:14:16,485 We'll exit configuration. 267 00:14:16,485 --> 00:14:18,110 And then of course, we're going to have 268 00:14:18,110 --> 00:14:20,450 to force BGP to reconverge. 269 00:14:20,450 --> 00:14:22,280 Don't ever do what I'm about to do. 270 00:14:22,280 --> 00:14:24,485 This is only because it's in a lab. 271 00:14:24,485 --> 00:14:26,360 Hopefully, all of this would have been set up 272 00:14:26,360 --> 00:14:28,820 from the very beginning in your environment anyway, 273 00:14:28,820 --> 00:14:32,540 and you wouldn't be adding this sometime down the road. 274 00:14:32,540 --> 00:14:36,918 We're going to clear all of our BGP VPNv4 sessions. 275 00:14:36,918 --> 00:14:38,960 So this is going to force the neighborships to go 276 00:14:38,960 --> 00:14:40,950 down and back up, of course. 277 00:14:40,950 --> 00:14:44,120 Then we'll give BGP just a few moments to converge. 278 00:14:44,120 --> 00:14:46,910 Meanwhile, we'll hop back over to router 1 and get 279 00:14:46,910 --> 00:14:48,720 ready to do our testing. 280 00:14:48,720 --> 00:14:50,010 So it's been a few seconds. 281 00:14:50,010 --> 00:14:52,580 Let's go ahead and take a look at that update 282 00:14:52,580 --> 00:14:54,440 coming from router 6 now. 283 00:14:54,440 --> 00:14:56,300 We see that the update from router 6 284 00:14:56,300 --> 00:14:58,250 now has the domain ID set. 285 00:14:58,250 --> 00:14:59,840 It's the type 5. 286 00:14:59,840 --> 00:15:02,060 It has the value of 64. 287 00:15:02,060 --> 00:15:04,940 And it's got that 0200 on the end. 288 00:15:04,940 --> 00:15:09,780 That should match the update coming from router 8 now. 289 00:15:09,780 --> 00:15:11,460 And we see that it does. 290 00:15:11,460 --> 00:15:13,440 Once again, the domain ID on this one 291 00:15:13,440 --> 00:15:17,200 is now 64 for both paths. 292 00:15:17,200 --> 00:15:21,570 So now these routes should be coming through as internal. 293 00:15:21,570 --> 00:15:24,850 Let's go over and check on the customer router. 294 00:15:24,850 --> 00:15:27,660 So remember, of course, before, we had all these routes coming 295 00:15:27,660 --> 00:15:30,060 through as E2s. 296 00:15:30,060 --> 00:15:32,350 If we do our show ip route again, 297 00:15:32,350 --> 00:15:38,080 they are now showing up as O IA, or Interarea routes. 298 00:15:38,080 --> 00:15:40,590 So are they showing up as internal? 299 00:15:40,590 --> 00:15:41,670 Yes. 300 00:15:41,670 --> 00:15:44,940 Are they showing up as coming from the same area? 301 00:15:44,940 --> 00:15:45,840 No. 302 00:15:45,840 --> 00:15:48,090 Now, can that be done? 303 00:15:48,090 --> 00:15:49,200 Yes, it can. 304 00:15:49,200 --> 00:15:52,420 And we'll get to that coming up here in just a few videos. 305 00:15:52,420 --> 00:15:54,558 But it's not an easy thing to do. 306 00:15:54,558 --> 00:15:56,850 And it's not something the service provider is normally 307 00:15:56,850 --> 00:15:57,750 going to do. 308 00:15:57,750 --> 00:16:03,180 This is how we would normally run OSPF as a CE-PE protocol 309 00:16:03,180 --> 00:16:05,970 from the perspective of the route type. 310 00:16:05,970 --> 00:16:09,310 We would get it to an O IA for the customer. 311 00:16:09,310 --> 00:16:12,640 And that's probably about as far as we would normally go. 312 00:16:12,640 --> 00:16:16,710 But there is one other thing we could do if we really had to. 313 00:16:16,710 --> 00:16:19,500 Again, we'll get to that in just a minute. 314 00:16:19,500 --> 00:16:21,030 Just for verification, let's make 315 00:16:21,030 --> 00:16:23,340 sure they're showing up correctly on router 8 and 9 316 00:16:23,340 --> 00:16:24,730 as well. 317 00:16:24,730 --> 00:16:26,130 So we do a show ip route. 318 00:16:26,130 --> 00:16:29,400 We see that our OSPF routes are internal here. 319 00:16:29,400 --> 00:16:33,130 And on router 9, we see the exact same thing. 320 00:16:33,130 --> 00:16:35,830 So this is functioning correctly. 321 00:16:35,830 --> 00:16:38,370 So if we want, we can actually see this being 322 00:16:38,370 --> 00:16:40,980 carried in the BGP updates. 323 00:16:40,980 --> 00:16:45,000 Let's start a Wireshark capture and then clear our BGP updates 324 00:16:45,000 --> 00:16:49,920 again and see the domain ID inside the BGP update. 325 00:16:49,920 --> 00:16:51,870 So I started the packet capture. 326 00:16:51,870 --> 00:16:54,330 And then I jumped in here under the route reflector. 327 00:16:54,330 --> 00:16:58,020 And we're just going to do that clear bgp vpnv4 unicast 328 00:16:58,020 --> 00:17:00,690 for everybody, just to make sure we're clearing out 329 00:17:00,690 --> 00:17:03,660 the entire environment, all routers, to make 330 00:17:03,660 --> 00:17:05,280 sure we're forcing that update. 331 00:17:05,280 --> 00:17:08,220 That way, we make sure we capture it as the updates are 332 00:17:08,220 --> 00:17:10,319 being sent to router 1. 333 00:17:10,319 --> 00:17:12,780 So we see our neighborships coming back up. 334 00:17:12,780 --> 00:17:15,000 Let's go ahead and jump back into Wireshark 335 00:17:15,000 --> 00:17:17,079 and take a look at our capture. 336 00:17:17,079 --> 00:17:19,560 So what we want to look for here in Wireshark 337 00:17:19,560 --> 00:17:23,970 is this rather large update message going from the route 338 00:17:23,970 --> 00:17:25,650 reflector, router 12-- 339 00:17:25,650 --> 00:17:32,580 so the 10.12.12.12-- going to router 1, 10.1.1.1. 340 00:17:32,580 --> 00:17:35,160 And if we open this up, we see that there's 341 00:17:35,160 --> 00:17:41,310 a lot of update messages here under Border Gateway protocol. 342 00:17:41,310 --> 00:17:43,610 So if we open up one of these updates, 343 00:17:43,610 --> 00:17:48,020 then we open Path attributes, EXTENDED_COMMUNITIES, 344 00:17:48,020 --> 00:17:53,450 Carried extended communities, OSPF Domain Identifier, 345 00:17:53,450 --> 00:17:55,790 then if we highlight the Subtype, 346 00:17:55,790 --> 00:17:58,970 we can actually see that it's set to 0x5. 347 00:17:58,970 --> 00:18:03,060 And we can see that down here in the packet decoder window. 348 00:18:03,060 --> 00:18:05,420 We see that it's 05. 349 00:18:05,420 --> 00:18:08,480 Now, if we look at the 4-Octet AN, 350 00:18:08,480 --> 00:18:14,120 that might not look correct at first, because it says 6554112. 351 00:18:14,120 --> 00:18:18,440 However, if we actually highlight that and we look 352 00:18:18,440 --> 00:18:21,920 at it in the packet decoder, it's because it's getting that 353 00:18:21,920 --> 00:18:25,220 00640200. 354 00:18:25,220 --> 00:18:30,920 And as we said, the 0200 is just not used. 355 00:18:30,920 --> 00:18:34,400 The part we're looking for is the 0064. 356 00:18:34,400 --> 00:18:37,940 And we can see that is how we had set our domain ID. 357 00:18:37,940 --> 00:18:41,150 So we see this information is being carried 358 00:18:41,150 --> 00:18:46,350 in the VPNv4 update for BGP. 359 00:18:46,350 --> 00:18:51,620 So in this video, we took a look at how to set the OSPF domain 360 00:18:51,620 --> 00:18:56,420 ID on the PEs to ensure that the customer routes 361 00:18:56,420 --> 00:19:00,650 coming through our layer 3 VPN environment come through 362 00:19:00,650 --> 00:19:03,530 as at least OSPF internal. 363 00:19:03,530 --> 00:19:05,660 Now, again, at this point, they're 364 00:19:05,660 --> 00:19:09,270 coming through as O IA, indicating, of course, 365 00:19:09,270 --> 00:19:11,420 that they're coming from a different area, 366 00:19:11,420 --> 00:19:14,690 even though we actually know that the customer has all 367 00:19:14,690 --> 00:19:17,660 of these routers in area zero. 368 00:19:17,660 --> 00:19:20,070 Again, there's a way we can deal with that. 369 00:19:20,070 --> 00:19:22,250 It's not exactly easy or something 370 00:19:22,250 --> 00:19:24,090 that we usually do at scale. 371 00:19:24,090 --> 00:19:26,460 However, it can be handled. 372 00:19:26,460 --> 00:19:29,490 We'll get to that in an upcoming video. 373 00:19:29,490 --> 00:19:32,120 However, before we get to that, we also 374 00:19:32,120 --> 00:19:36,140 want to address OSPF loop prevention in our MPLS 375 00:19:36,140 --> 00:19:37,050 environment. 376 00:19:37,050 --> 00:19:40,650 And that's what we're actually going to do in our next video. 377 00:19:40,650 --> 00:19:44,000 Until then, I hope this has been informative for you, 378 00:19:44,000 --> 00:19:47,140 and I'd like to thank you for viewing. 379 00:19:47,140 --> 00:19:50,000