WEBVTT 1 00:00.000 --> 00:05.600 So now that we've seen what our current convergence looks like, let's come back 2 00:05.600 --> 00:07.000 over here to router one, 3 00:07.000 --> 00:12.280 and let's see if we can speed this up by using bidirectional forwarding 4 00:12.280 --> 00:13.000 detection. 5 00:13.000 --> 00:18.700 Now, as mentioned during the introduction, routers three and four on the cloud 6 00:18.700 --> 00:21.000 side are already configured. 7 00:21.000 --> 00:24.000 So all we have to do here is configure router one and two. 8 00:24.000 --> 00:29.380 So for this, we'll go under the WAN interface and we have to begin by config 9 00:29.380 --> 00:33.000 uring our BFD timers or our BFD interval. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 9 00:29.380 --> 00:33.000 uring our BFD timers or our BFD interval. 10 00:33.000 --> 00:38.790 This first number, of course, is how often we're going to be sending the BFD 11 00:38.790 --> 00:41.000 echoes to the other side. 12 00:41.000 --> 00:47.650 Now, one of our concerns with using BFD on the WAN would be that the WAN may 13 00:47.650 --> 00:52.000 actually have some inherent latency that we have to work with. 14 00:52.000 --> 00:57.340 So normally, we may not be able to take this all the way down to say the 50 15 00:57.340 --> 01:01.000 milliseconds here, which is the minimal timer. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 15 00:57.340 --> 01:01.000 milliseconds here, which is the minimal timer. 16 01:01.000 --> 01:05.900 Now, since we're in a lab environment and these devices are pretty much 17 01:05.900 --> 01:09.000 connected directly with this WAN emulator, 18 01:09.000 --> 01:13.090 we can get away with doing the minimal timers so we can see how fast this 19 01:13.090 --> 01:14.000 really is. 20 01:14.000 --> 01:19.260 But just keep in mind again, for the real world, you may have to adjust these 21 01:19.260 --> 01:24.000 timers so that they're appropriate for your actual WAN circuit. 22 01:24.000 --> 01:29.240 But we'll just put in 50, then you have to say what the minimum receive 23 01:29.240 --> 01:31.000 interval is going to be. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 23 01:29.240 --> 01:31.000 interval is going to be. 24 01:31.000 --> 01:34.000 This is what we expect the other side to do. 25 01:34.000 --> 01:37.680 Since we're configuring both sides, we'll just set this to 50 as well, and then 26 01:37.680 --> 01:40.000 we'll set the multiplier. 27 01:40.000 --> 01:46.000 This is simply saying after how many failures we expect to declare this down. 28 01:46.000 --> 01:50.000 The lowest we can set this one is to three. 29 01:50.000 --> 01:54.170 So if you look at all these numbers together, if we're going to send every 50 30 01:54.170 --> 01:59.000 milliseconds and declare the neighbor dead after it misses three, 31 01:59.000 --> 02:05.000 that means that we will detect this failure in only 150 milliseconds. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 31 01:59.000 --> 02:05.000 that means that we will detect this failure in only 150 milliseconds. 32 02:05.000 --> 02:10.850 So let's go ahead and do that. Again, that may not work for your actual WAN 33 02:10.850 --> 02:12.000 environment. 34 02:12.000 --> 02:15.000 However, it should work fine here in the lab. 35 02:15.000 --> 02:21.250 Now, the other thing we have to do is enable our routing protocol to actually 36 02:21.250 --> 02:23.000 watch the BFD process. 37 02:23.000 --> 02:29.980 So we'll go into router OSPF one, and we simply say BFD, and then there's only 38 02:29.980 --> 02:31.000 one command for this. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 38 02:29.980 --> 02:31.000 one command for this. 39 02:31.000 --> 02:35.000 You simply say to turn it on on all the interfaces. 40 02:35.000 --> 02:40.660 Now, that's only going to include interfaces that you have actually configured 41 02:40.660 --> 02:42.000 an interval on. 42 02:42.000 --> 02:47.040 So all interfaces is a little bit misleading because again, it's only the 43 02:47.040 --> 02:50.000 interfaces that have BFD enabled. 44 02:50.000 --> 02:56.000 Notice that almost immediately the BFD session with router three comes up. 45 02:56.000 --> 03:02.150 This is because now we have an interval set, we have a process set to use BFD, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 45 02:56.000 --> 03:02.150 This is because now we have an interval set, we have a process set to use BFD, 46 03:02.150 --> 03:05.000 and router three was already configured. 47 03:05.000 --> 03:10.570 If we go ahead and exit out of configuration, we can verify this with a show B 48 03:10.570 --> 03:12.000 FD neighbors. 49 03:12.000 --> 03:16.900 This will show us that we are in fact up with router three out our gigabit to 50 03:16.900 --> 03:18.000 interface. 51 03:18.000 --> 03:23.000 This is good if you just want a quick snapshot to see if the neighbors are up. 52 03:23.000 --> 03:27.200 If you want more detail, well, you can literally add the word details to the 53 03:27.200 --> 03:30.000 end of this, hit enter again, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 54 03:30.000 --> 03:37.000 and clearly this gives us a ton more information about the actual session. 55 03:37.000 --> 03:43.130 Some of the important things to note here is it says the session state is up, 56 03:43.130 --> 03:49.000 and it's using the echo function with that 50 millisecond interval. 57 03:49.000 --> 03:53.370 If we look down here a little bit further, we see that the multiplier is 58 03:53.370 --> 03:55.000 actually set to three. 59 03:55.000 --> 04:00.000 Also, you might note that these intervals are not set to 50. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 60 04:00.000 --> 04:03.000 This is because we are running in echo mode. 61 04:03.000 --> 04:08.540 If we were to turn off echo mode, these intervals would then drop the 50 62 04:08.540 --> 04:10.000 milliseconds. 63 04:10.000 --> 04:16.060 But what it really means is we're sending BFD control messages based on these 64 04:16.060 --> 04:21.770 intervals, but the actual echo testing the state of the other side is using the 65 04:21.770 --> 04:24.000 50 millisecond interval. 66 04:24.000 --> 04:27.880 So while we're in echo mode, there's actually going to be two different 67 04:27.880 --> 04:29.000 intervals here. 68 04:29.000 --> 04:33.180 A little further down, of course, we can see how many packets have been sent WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 68 04:29.000 --> 04:33.180 A little further down, of course, we can see how many packets have been sent 69 04:33.180 --> 04:39.000 and received, and we can see the min, max, and average milliseconds 70 04:39.000 --> 04:42.000 that these packets are taking on our WAN. 71 04:42.000 --> 04:48.000 As you can see here, we're actually dangerously close to that 50 milliseconds 72 04:48.000 --> 04:53.000 because of those WAN emulators in our WAN circuits. 73 04:53.000 --> 04:58.000 However, we see the state is not going down, so we're doing okay for now. 74 04:58.000 --> 05:05.140 Also notice that it tells us down here that OSPF and the CEPF process itself WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 74 04:58.000 --> 05:05.140 Also notice that it tells us down here that OSPF and the CEPF process itself 75 05:05.140 --> 05:07.000 are using BFD. 76 05:07.000 --> 05:11.100 Now clearly as we witnessed, CEPF using BFD is not enough to cause 77 05:11.100 --> 05:13.000 neighborhoods to come up. 78 05:13.000 --> 05:16.000 It has to be something like OSPF. 79 05:16.000 --> 05:21.000 So now that we see how to configure BFD, let's configure router two. 80 05:21.000 --> 05:26.640 So again, we'll simply go into configuration mode, interface gigabit two, set 81 05:26.640 --> 05:34.000 the BFD interval to 50, the min receive to 50, and the multiplier to three. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 81 05:26.640 --> 05:34.000 the BFD interval to 50, the min receive to 50, and the multiplier to three. 82 05:34.000 --> 05:37.000 That's actually all you have to put in for the command. 83 05:37.000 --> 05:43.000 We'll go into router OSPF one and say BFD for all interfaces. 84 05:43.000 --> 05:45.000 We'll exit configuration. 85 05:45.000 --> 05:49.450 We'll do a show BFD neighbor, and we see that we are in fact up with router 86 05:49.450 --> 05:50.000 four. 87 05:50.000 --> 05:54.000 So now BFD is functional on both of our WAN links. 88 05:54.000 --> 05:57.000 Let's go ahead and test our failover again. 89 05:57.000 --> 05:59.000 So first we'll get everything staged. 90 05:59.000 --> 06:03.000 So we have router three, standing by to shut the interface. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 90 05:59.000 --> 06:03.000 So we have router three, standing by to shut the interface. 91 06:03.000 --> 06:07.000 Workstation two is ready to repeat its ping. 92 06:07.000 --> 06:13.100 Now workstation one, before we just do the ping, let's do our trace route again 93 06:13.100 --> 06:16.000 , just to verify that we are in fact following the correct path. 94 06:16.000 --> 06:20.000 So we see that we are in fact going back through router one. 95 06:20.000 --> 06:22.000 Now let's get our ping ready. 96 06:22.000 --> 06:28.220 We'll start our two pings, shut down the interface, and then come back and stop 97 06:28.220 --> 06:29.000 them. 98 06:29.000 --> 06:34.000 So this time we see on workstation two that it only dropped a single ping. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 98 06:29.000 --> 06:34.000 So this time we see on workstation two that it only dropped a single ping. 99 06:34.000 --> 06:40.350 And if we look back at workstation one, we can see right here that this time it 100 06:40.350 --> 06:45.000 literally only missed two sequence numbers during the failover. 101 06:45.000 --> 06:49.000 So this is happening considerably faster. 102 06:49.000 --> 06:54.800 However, it does still have one issue, which as we can see everything's working 103 06:54.800 --> 06:57.000 , but it's still not the best. 104 06:57.000 --> 07:04.000 Here on the workstation, if we repeat our trace again, notice what's happening. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 104 06:57.000 --> 07:04.000 Here on the workstation, if we repeat our trace again, notice what's happening. 105 07:04.000 --> 07:11.540 Now we're still going to router one, because router one is still the active VR 106 07:11.540 --> 07:13.000 RP process. 107 07:13.000 --> 07:20.000 However, we're then forwarding the traffic because of OSPF over to router two. 108 07:20.000 --> 07:25.570 Then router two sends it across its WAN link and it ultimately gets to the 109 07:25.570 --> 07:27.000 destination. 110 07:27.000 --> 07:32.000 So at the end of the day, this isn't a huge deal because of course it's working WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 110 07:27.000 --> 07:32.000 So at the end of the day, this isn't a huge deal because of course it's working 111 07:32.000 --> 07:39.720 , but it would be far better if VRRP would also fail over when the WAN link 112 07:39.720 --> 07:41.000 fails. 113 07:41.000 --> 07:46.680 So in this video, we took a look at how to configure BFD to make our 114 07:46.680 --> 07:54.000 convergence even faster than what we had with just using faster OSPF timers. 115 07:54.000 --> 07:59.170 Now, although this is all good, we mentioned that it would be best if VRRP or 116 07:59.170 --> 08:05.000 whatever first hop redundancy protocol we're using were to fail over as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 116 07:59.170 --> 08:05.000 whatever first hop redundancy protocol we're using were to fail over as well. 117 08:05.000 --> 08:09.700 Well, before we can really do that, we're going to need some more advanced ways 118 08:09.700 --> 08:11.000 to monitor this link. 119 08:11.000 --> 08:16.600 And that's exactly what we're going to take a look at next using IP SLA or 120 08:16.600 --> 08:19.000 service level agreement.