1 00:00:00,000 --> 00:00:03,304 [AUDIO LOGO] 2 00:00:03,304 --> 00:00:08,029 3 00:00:08,029 --> 00:00:09,980 Now that we've talked about some of the things 4 00:00:09,980 --> 00:00:14,900 that we can modify in BGP to help improve its convergence, 5 00:00:14,900 --> 00:00:18,080 and at the same time, monitoring our routers 6 00:00:18,080 --> 00:00:20,960 to make sure they don't get overwhelmed, now let's 7 00:00:20,960 --> 00:00:24,410 talk about what we should actually set these things to. 8 00:00:24,410 --> 00:00:26,630 Plus, we're going to look at another feature 9 00:00:26,630 --> 00:00:30,770 we haven't really discussed yet, prefix independent convergence 10 00:00:30,770 --> 00:00:32,299 or PIC. 11 00:00:32,299 --> 00:00:36,140 This allows BGP to actually keep a backup route 12 00:00:36,140 --> 00:00:39,707 that we can use in the event that it detects a failure. 13 00:00:39,707 --> 00:00:42,290 And then, of course, we're going to jump onto the command line 14 00:00:42,290 --> 00:00:44,790 and see these things in action. 15 00:00:44,790 --> 00:00:49,290 So let's go ahead and get started with these details. 16 00:00:49,290 --> 00:00:52,230 Now that we know how to monitor our routers 17 00:00:52,230 --> 00:00:54,640 and make sure they don't get overloaded, 18 00:00:54,640 --> 00:00:57,960 what are some of the things that we can or should 19 00:00:57,960 --> 00:01:00,720 or may want to optimize? 20 00:01:00,720 --> 00:01:06,160 Well, the first is to configure a lower BGP scan time. 21 00:01:06,160 --> 00:01:08,430 Now, on a lot of hardware, it will yell at you 22 00:01:08,430 --> 00:01:10,410 if you try to go too low. 23 00:01:10,410 --> 00:01:15,330 But probably cutting it in half, drop it down to 30 seconds 24 00:01:15,330 --> 00:01:18,960 is probably going to be fine on almost all of today's equipment 25 00:01:18,960 --> 00:01:22,170 even with large BGP tables. 26 00:01:22,170 --> 00:01:25,900 We can also configure a lower advertisement interval. 27 00:01:25,900 --> 00:01:28,950 In fact, we may even want to drop this to zero, 28 00:01:28,950 --> 00:01:32,100 let BGP send its updates right away, 29 00:01:32,100 --> 00:01:34,440 particularly if we're doing other things 30 00:01:34,440 --> 00:01:39,180 to protect our devices such as BGP route dampening. 31 00:01:39,180 --> 00:01:44,460 So we may not need this buffer on the advertisement interval. 32 00:01:44,460 --> 00:01:48,360 And of course, we can also configure lower keepalive 33 00:01:48,360 --> 00:01:50,610 and hold timers. 34 00:01:50,610 --> 00:01:52,960 Keep in mind as we're discussing this, 35 00:01:52,960 --> 00:01:58,140 we really don't want BGP to converge as fast as our IGP. 36 00:01:58,140 --> 00:02:01,350 So we probably don't want to go down to really, really 37 00:02:01,350 --> 00:02:03,030 fast timers here. 38 00:02:03,030 --> 00:02:07,650 But maybe a keepalive every 5 seconds and the hold time being 39 00:02:07,650 --> 00:02:12,300 maybe 15 might be some good numbers at least to start with. 40 00:02:12,300 --> 00:02:15,450 Because, again, part of the idea is 41 00:02:15,450 --> 00:02:17,710 if there is a failure in our network, 42 00:02:17,710 --> 00:02:22,050 hopefully our IGP converges, finds another path 43 00:02:22,050 --> 00:02:26,670 to get to that BGP neighbor, and the BGP process never 44 00:02:26,670 --> 00:02:28,930 even knows the neighbor went down. 45 00:02:28,930 --> 00:02:31,290 Now that would, of course, be assuming 46 00:02:31,290 --> 00:02:34,290 we're talking about peering on something like loopbacks 47 00:02:34,290 --> 00:02:37,140 that there would be another path to get to. 48 00:02:37,140 --> 00:02:40,050 If you're peering on physical interfaces 49 00:02:40,050 --> 00:02:42,240 and there would be no other path, 50 00:02:42,240 --> 00:02:45,000 well, maybe you want to make these timers even lower 51 00:02:45,000 --> 00:02:45,630 than that. 52 00:02:45,630 --> 00:02:48,510 In that case, yes, maybe we want to go 53 00:02:48,510 --> 00:02:53,740 with even faster timers and maybe even something like BFD. 54 00:02:53,740 --> 00:02:55,810 And again, some of those things I just mentioned 55 00:02:55,810 --> 00:02:59,860 are right here that again, maybe we want to use BFD instead 56 00:02:59,860 --> 00:03:04,930 or maybe fast reroute or again the IGP itself. 57 00:03:04,930 --> 00:03:07,270 Tweaking the IGP to converge faster 58 00:03:07,270 --> 00:03:08,920 might be the better answer. 59 00:03:08,920 --> 00:03:11,140 Just keep these things in mind before we 60 00:03:11,140 --> 00:03:14,200 jump right in to saying, how can we make BGP faster? 61 00:03:14,200 --> 00:03:16,480 You may not want to. 62 00:03:16,480 --> 00:03:19,940 But faster than the default is probably not a bad idea. 63 00:03:19,940 --> 00:03:21,370 Now another really cool feature we 64 00:03:21,370 --> 00:03:24,640 have in BGP that will definitely help improve its performance 65 00:03:24,640 --> 00:03:31,270 is something called prefix independent convergence or PIC. 66 00:03:31,270 --> 00:03:37,240 This is actually very similar to like OSPF fast reroute 67 00:03:37,240 --> 00:03:42,700 or if you're familiar with it, the EIGRP feasible successor. 68 00:03:42,700 --> 00:03:44,860 This is a backup path. 69 00:03:44,860 --> 00:03:49,750 This backup path is stored in the BGP table, 70 00:03:49,750 --> 00:03:53,020 in the routing information base, and in the forwarding 71 00:03:53,020 --> 00:03:57,250 information base, so the RIB and the FIB. 72 00:03:57,250 --> 00:04:02,100 It's ready to go in the event that we detect a failure. 73 00:04:02,100 --> 00:04:04,970 So basically what this is doing is 74 00:04:04,970 --> 00:04:07,940 it's storing that back up in BGP. 75 00:04:07,940 --> 00:04:12,470 So BGP's already gone through the best path algorithm, 76 00:04:12,470 --> 00:04:16,910 it chose a best path, and it chose a backup. 77 00:04:16,910 --> 00:04:20,250 Now we are still going to have to detect the failure. 78 00:04:20,250 --> 00:04:23,060 So the stuff we just discussed above 79 00:04:23,060 --> 00:04:27,260 is still going to come into play because our backup path won't 80 00:04:27,260 --> 00:04:31,080 kick in until we've actually detected the failure. 81 00:04:31,080 --> 00:04:34,130 But once we do, this backup path is going 82 00:04:34,130 --> 00:04:36,300 to be already ready to go. 83 00:04:36,300 --> 00:04:38,270 So we're going to jump into the command line 84 00:04:38,270 --> 00:04:42,350 and tweak some of these timers and configure PIC. 85 00:04:42,350 --> 00:04:44,550 But let's look at our topology first. 86 00:04:44,550 --> 00:04:46,980 So we know what we're going to be configuring. 87 00:04:46,980 --> 00:04:48,720 So again, for this demonstration, 88 00:04:48,720 --> 00:04:51,170 we'll be using BGP topology 1. 89 00:04:51,170 --> 00:04:53,450 And we'll just look at the same routers 90 00:04:53,450 --> 00:04:55,560 that we looked at their performance on. 91 00:04:55,560 --> 00:04:59,540 So again, we'll see how this gets configured on R1, 92 00:04:59,540 --> 00:05:02,180 and we'll take a look at R7. 93 00:05:02,180 --> 00:05:07,280 This way, we get to see iOS XR and iOS XE. 94 00:05:07,280 --> 00:05:09,500 And we're going to be looking at devices 95 00:05:09,500 --> 00:05:12,200 that actually have multiple paths so they 96 00:05:12,200 --> 00:05:13,940 can have a backup. 97 00:05:13,940 --> 00:05:16,610 We're going to focus on a default 98 00:05:16,610 --> 00:05:22,250 route that's actually being injected into BGP on router 9. 99 00:05:22,250 --> 00:05:25,670 So both router 1 and router 7 should 100 00:05:25,670 --> 00:05:29,180 have multiple paths to get to this default. 101 00:05:29,180 --> 00:05:32,220 That's what we'll focus on when we're looking at our tables. 102 00:05:32,220 --> 00:05:33,990 So let's jump into the command line. 103 00:05:33,990 --> 00:05:36,490 We'll start on router 1. 104 00:05:36,490 --> 00:05:40,030 Let's start with creating a route policy. 105 00:05:40,030 --> 00:05:43,180 We'll simply call this RP_pick. 106 00:05:43,180 --> 00:05:46,180 We're going to use this to enable the feature. 107 00:05:46,180 --> 00:05:50,110 We're going to say set path-selection, 108 00:05:50,110 --> 00:05:54,340 configure it for a backup, and say to install it. 109 00:05:54,340 --> 00:05:56,990 We're just going to do this for the entire table. 110 00:05:56,990 --> 00:05:59,690 So we don't have to match or anything like that. 111 00:05:59,690 --> 00:06:02,000 We'll just end the policy. 112 00:06:02,000 --> 00:06:05,620 Next, we go into our BGP process for address family 113 00:06:05,620 --> 00:06:07,720 IPv4 unicast. 114 00:06:07,720 --> 00:06:10,720 And we're going to configure additional paths 115 00:06:10,720 --> 00:06:15,760 for the selection in our route policy RP_pick. 116 00:06:15,760 --> 00:06:17,590 So we're going to tell it to choose 117 00:06:17,590 --> 00:06:21,880 additional paths from the selection from our route 118 00:06:21,880 --> 00:06:23,050 policy. 119 00:06:23,050 --> 00:06:26,380 So that will enable PIC on the device. 120 00:06:26,380 --> 00:06:28,060 The next thing we want to do is tweak 121 00:06:28,060 --> 00:06:30,230 some of those timers we talked about. 122 00:06:30,230 --> 00:06:35,290 So for example, we could say BGP scan time, and notice 123 00:06:35,290 --> 00:06:39,730 we can set this from 5 to 3,600 seconds. 124 00:06:39,730 --> 00:06:42,370 We'll just go ahead and set it to 30. 125 00:06:42,370 --> 00:06:47,950 Then we'll configure our neighbor 50.1.167.7. 126 00:06:47,950 --> 00:06:50,320 And we're going to modify our timers. 127 00:06:50,320 --> 00:06:52,060 The first timer's the keepalive. 128 00:06:52,060 --> 00:06:54,070 We'll drop that down to 5 seconds. 129 00:06:54,070 --> 00:06:59,410 And then, of course, is the hold time we'll set it to 15. 130 00:06:59,410 --> 00:07:03,080 We'll also change our advertisement interval. 131 00:07:03,080 --> 00:07:05,410 And again, this can be from 0 to 600. 132 00:07:05,410 --> 00:07:07,130 We'll just turn it off. 133 00:07:07,130 --> 00:07:10,210 We'll say zero-- send the updates right away. 134 00:07:10,210 --> 00:07:14,330 We'll commit our changes and exit configuration. 135 00:07:14,330 --> 00:07:16,300 So again, those are some very common changes 136 00:07:16,300 --> 00:07:19,060 we would make on iOS XR. 137 00:07:19,060 --> 00:07:21,280 Let's take a look at iOS XE. 138 00:07:21,280 --> 00:07:23,780 So we'll make the same basic changes here. 139 00:07:23,780 --> 00:07:26,290 So we're going into configuration mode. 140 00:07:26,290 --> 00:07:29,620 And we don't have to be so fancy on iOS XE. 141 00:07:29,620 --> 00:07:33,400 We can just go right into router BGP and say, 142 00:07:33,400 --> 00:07:37,300 BGP additional-paths install. 143 00:07:37,300 --> 00:07:39,190 And that'll just turn on PIC. 144 00:07:39,190 --> 00:07:42,130 We can also do our BGP scan time. 145 00:07:42,130 --> 00:07:44,140 I believe this platform will yell at us 146 00:07:44,140 --> 00:07:46,460 if we try to set it too low. 147 00:07:46,460 --> 00:07:47,260 There we go. 148 00:07:47,260 --> 00:07:50,650 It's actually telling us that, hey, doing this 149 00:07:50,650 --> 00:07:54,730 below 15 seconds may not be the best plan. 150 00:07:54,730 --> 00:07:56,480 Well, it's sort of interesting by the way, 151 00:07:56,480 --> 00:07:58,510 is notice how it's a console message 152 00:07:58,510 --> 00:08:01,060 and not like an error on the command 153 00:08:01,060 --> 00:08:02,470 because it's not an error. 154 00:08:02,470 --> 00:08:04,390 I mean, you can do 5 seconds. 155 00:08:04,390 --> 00:08:07,720 It's just telling you that might not be the best plan. 156 00:08:07,720 --> 00:08:09,640 Well, we'll be consistent. 157 00:08:09,640 --> 00:08:12,010 We'll set it the same way we did iOS XR. 158 00:08:12,010 --> 00:08:14,230 So we'll set it to 30 seconds. 159 00:08:14,230 --> 00:08:16,940 And then, of course, we tweak our neighbor the same way. 160 00:08:16,940 --> 00:08:23,410 So 50.0.167.1 timers 5 and 15. 161 00:08:23,410 --> 00:08:25,900 Again, notice it also yells about this one. 162 00:08:25,900 --> 00:08:29,020 It doesn't like the hold time of less than 20 seconds. 163 00:08:29,020 --> 00:08:32,590 It says it increases the chance of peer flapping. 164 00:08:32,590 --> 00:08:34,549 It certainly does. 165 00:08:34,549 --> 00:08:37,030 But the flip side of that is I'm really 166 00:08:37,030 --> 00:08:41,770 hoping that our underlying IGP is going to converge faster 167 00:08:41,770 --> 00:08:43,159 than 15 seconds. 168 00:08:43,159 --> 00:08:46,270 So on most of today's networks, that really 169 00:08:46,270 --> 00:08:48,630 shouldn't be a problem. 170 00:08:48,630 --> 00:08:51,350 And then, of course, the other thing we want to change 171 00:08:51,350 --> 00:08:53,360 is the advertisement interval. 172 00:08:53,360 --> 00:08:55,160 Once again, same timers. 173 00:08:55,160 --> 00:08:58,220 We'll just say 0, and turn it off. 174 00:08:58,220 --> 00:09:00,510 And then we'll exit configuration. 175 00:09:00,510 --> 00:09:02,300 So now that we have everything set, 176 00:09:02,300 --> 00:09:03,575 let's do some verification. 177 00:09:03,575 --> 00:09:06,800 We might as well just start back on router 1. 178 00:09:06,800 --> 00:09:10,550 So first thing we'll look at is the show IP BGP neighbor 179 00:09:10,550 --> 00:09:14,240 for the 50.0.167.7. 180 00:09:14,240 --> 00:09:15,740 Big thing, of course, we want to see 181 00:09:15,740 --> 00:09:19,670 here is the configured hold time is set to 15 182 00:09:19,670 --> 00:09:22,370 and the keepalive is set to 5. 183 00:09:22,370 --> 00:09:24,680 So that's good. 184 00:09:24,680 --> 00:09:27,800 If we do a show BGP summary, we see 185 00:09:27,800 --> 00:09:29,690 we have nothing stuck in the input output 186 00:09:29,690 --> 00:09:32,570 queues, which again, in this environment, 187 00:09:32,570 --> 00:09:34,730 we wouldn't expect to. 188 00:09:34,730 --> 00:09:37,550 But now let's check to see if our PIC is working. 189 00:09:37,550 --> 00:09:39,770 Let's look at that default route. 190 00:09:39,770 --> 00:09:44,060 What we see is we have this path from router 2 191 00:09:44,060 --> 00:09:47,690 that is actually configured as a backup. 192 00:09:47,690 --> 00:09:53,120 If we do a show route IPv4 unicast for the prefix, 193 00:09:53,120 --> 00:09:56,930 we see here that it's also listing the route to router 2 194 00:09:56,930 --> 00:09:59,490 as a BGP backup path. 195 00:09:59,490 --> 00:10:02,640 So this is shown in the routing table as well. 196 00:10:02,640 --> 00:10:06,030 And if we do a show CEF for the default, 197 00:10:06,030 --> 00:10:07,790 it's showing us the host route because I 198 00:10:07,790 --> 00:10:09,710 didn't put the slash 0. 199 00:10:09,710 --> 00:10:12,290 So if we look at the actual default, 200 00:10:12,290 --> 00:10:16,040 we can see here that once again, it has that route 201 00:10:16,040 --> 00:10:21,190 through router 2 as a backup. 202 00:10:21,190 --> 00:10:25,920 So we're seeing that it's stored as a backup in the BGP table, 203 00:10:25,920 --> 00:10:28,320 in the RIB, and in the FIB. 204 00:10:28,320 --> 00:10:30,150 So it's gone through all three. 205 00:10:30,150 --> 00:10:35,270 So now let's go ahead and check out iOS XE. 206 00:10:35,270 --> 00:10:37,520 So we'll start with looking at our BGP neighborship 207 00:10:37,520 --> 00:10:39,140 to router 1. 208 00:10:39,140 --> 00:10:42,560 Once again, we see the hold time and the keepalive time 209 00:10:42,560 --> 00:10:45,540 are both set correctly. 210 00:10:45,540 --> 00:10:49,150 If we do a show IP BGP on this platform, 211 00:10:49,150 --> 00:10:52,770 it actually shows you that there are backup paths 212 00:10:52,770 --> 00:10:56,917 right in the status code in the BGP table. 213 00:10:56,917 --> 00:10:58,500 Now, of course, we can get more detail 214 00:10:58,500 --> 00:11:01,450 by asking for the actual route itself. 215 00:11:01,450 --> 00:11:03,370 And we can see that, in this case, 216 00:11:03,370 --> 00:11:06,400 it's actually using the route through router 3, 217 00:11:06,400 --> 00:11:09,690 and the route from router 1 is the one that's configured 218 00:11:09,690 --> 00:11:12,580 as a backup or repair path. 219 00:11:12,580 --> 00:11:16,260 Now, one interesting thing here, if I do a show IP 220 00:11:16,260 --> 00:11:21,780 route for the prefix, notice that the RIB here on iOS XE 221 00:11:21,780 --> 00:11:25,530 doesn't really indicate that there's a backup path. 222 00:11:25,530 --> 00:11:29,070 But what's interesting is even though the RIB doesn't show it, 223 00:11:29,070 --> 00:11:31,630 let's check out the FIB. 224 00:11:31,630 --> 00:11:34,190 And I just did the same thing again. 225 00:11:34,190 --> 00:11:38,800 But if we do the show IP SEF, notice that in the SEF table 226 00:11:38,800 --> 00:11:42,880 or in the forwarding table, it knows there's a repair path. 227 00:11:42,880 --> 00:11:46,810 So even though BGP not showing it in the RIB, 228 00:11:46,810 --> 00:11:50,290 it's clearly in the FIB, which is the important part when 229 00:11:50,290 --> 00:11:55,080 it comes to switching over in the event of a failure. 230 00:11:55,080 --> 00:11:58,020 In this video, we took a look at how 231 00:11:58,020 --> 00:12:02,980 to increase BGP's performance from a convergence standpoint. 232 00:12:02,980 --> 00:12:05,190 So don't forget that we can change things 233 00:12:05,190 --> 00:12:08,280 such as the scan time, our keepalives, 234 00:12:08,280 --> 00:12:12,720 our hold down timers, how often or how quickly it sends updates 235 00:12:12,720 --> 00:12:18,930 to eBGP peers, and we can turn on PIC so that we actually 236 00:12:18,930 --> 00:12:22,740 have backup paths ready to go in the event BGP 237 00:12:22,740 --> 00:12:26,490 does find or detect a failure. 238 00:12:26,490 --> 00:12:29,820 Just keep in mind while you're doing all of this 239 00:12:29,820 --> 00:12:34,180 to keep a very close eye on your router's performance 240 00:12:34,180 --> 00:12:36,700 so that we don't overwhelm our router 241 00:12:36,700 --> 00:12:41,730 and well, risk stability in BGP just because we're 242 00:12:41,730 --> 00:12:43,660 trying to make it faster. 243 00:12:43,660 --> 00:12:45,780 I hope this has been informative for you. 244 00:12:45,780 --> 00:12:48,860 And I'd like to thank you for viewing. 245 00:12:48,860 --> 00:12:52,000