WEBVTT 1 00:00.000 --> 00:05.280 Object tracking is something that we should consider with every single FHRP 2 00:05.280 --> 00:06.360 deployment. 3 00:06.360 --> 00:10.910 If we don't look at least at object tracking, we're going to probably run into 4 00:10.910 --> 00:11.560 situations 5 00:11.560 --> 00:16.610 where there's a reality that our traffic is either getting black hold or is 6 00:16.610 --> 00:17.640 getting bumped 7 00:17.640 --> 00:21.480 around and bounced around in a way that is very inefficient. 8 00:21.480 --> 00:25.200 So again, the scenario is typically we lose a link like this. 9 00:25.200 --> 00:29.200 I continue to send traffic up to the active. The question is whether we 10 00:29.200 --> 00:30.240 actually have a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 10 00:29.200 --> 00:30.240 actually have a 11 00:30.240 --> 00:35.040 routed layer 3 relationship this way or not. Because if we do, then at least 12 00:35.040 --> 00:35.560 the active 13 00:35.560 --> 00:39.760 can route it and send it out towards the other distribution switch. 14 00:39.760 --> 00:43.020 But if we don't have a routed relationship, because we're trying to optimize 15 00:43.020 --> 00:43.760 our layer 16 00:43.760 --> 00:47.760 3, then it truly can't do anything and it will drop the traffic. 17 00:47.760 --> 00:50.690 So that's why I always say it's either going to get bounced around or possibly 18 00:50.690 --> 00:52.360 even dropped. 19 00:52.360 --> 00:58.960 So what we are wanting to do is recognize that because of a network failure 20 00:58.960 --> 00:59.760 that isn't 21 00:59.760 --> 01:06.090 directly this device going down, that we still want to fail over to the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 21 00:59.760 --> 01:06.090 directly this device going down, that we still want to fail over to the 22 01:06.090 --> 01:07.280 secondary or 23 01:07.280 --> 01:12.190 the standby backup. In our case, where it's an HSRP version too, so it would be 24 01:12.190 --> 01:12.680 the standby 25 01:12.680 --> 01:17.160 device. So we need to decide what we're going to track. What is our object? 26 01:17.160 --> 01:17.360 What we have 27 01:17.360 --> 01:22.060 lots of options here. I can track the line protocol of the link to see if it 28 01:22.060 --> 01:23.280 goes down. I can 29 01:23.280 --> 01:28.660 track a route in my own routing table and I can even track reachability by 30 01:28.660 --> 01:29.240 performing 31 01:29.240 --> 01:34.880 pings essentially up here. And lastly, I could use Cisco's IPS LA. So let's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 31 01:29.240 --> 01:34.880 pings essentially up here. And lastly, I could use Cisco's IPS LA. So let's 32 01:34.880 --> 01:35.480 just say we want 33 01:35.480 --> 01:40.070 to use the line protocol. And by the way, if you chose something else, 34 01:40.070 --> 01:41.160 perfectly fine, 35 01:41.160 --> 01:44.550 it's just recognizing what our options are. So I'm going to say we're going to 36 01:44.550 --> 01:44.720 track 37 01:44.720 --> 01:47.820 the line protocol. And from here, we need to make sure we have our 38 01:47.820 --> 01:49.840 configurations in place. 39 01:49.840 --> 01:54.030 Well, there's two primary aspects to this. First of all, we do need to make 40 01:54.030 --> 01:54.720 sure that we 41 01:54.720 --> 02:02.310 have preemption enabled on our secondary. And ideally, we enable it on the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 41 01:54.720 --> 02:02.310 have preemption enabled on our secondary. And ideally, we enable it on the 42 02:02.310 --> 02:02.800 primary as 43 02:02.800 --> 02:07.510 well, not strictly required because as long as we can fail over one way, we're 44 02:07.510 --> 02:08.120 usually 45 02:08.120 --> 02:13.380 in good shape. But naturally, if this link comes online and then this link goes 46 02:13.380 --> 02:14.000 down while 47 02:14.000 --> 02:17.600 we're still the second of the primary, we'll have the same problem in reverse. 48 02:17.600 --> 02:17.920 So it really 49 02:17.920 --> 02:23.240 should be enabled on both sides. Next, that's number one is preemption. Number 50 02:23.240 --> 02:23.720 two is our 51 02:23.720 --> 02:28.310 priority design. So we're going to want to make sure that we have a priority 52 02:28.310 --> 02:29.000 value. Like 53 02:29.000 --> 02:36.360 let's just say 120 on the left and maybe 110 on the right. And we need to have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 53 02:29.000 --> 02:36.360 let's just say 120 on the left and maybe 110 on the right. And we need to have 54 02:36.360 --> 02:37.440 a decrement 55 02:37.440 --> 02:43.380 design in place. So if this line protocol goes down, I want to decrement by, 56 02:43.380 --> 02:45.440 let's say, 20. 57 02:45.440 --> 02:51.330 So at this point, I'm tracking the object. I start with a priority of 120. If 58 02:51.330 --> 02:51.840 this line 59 02:51.840 --> 02:57.380 protocol goes down, I am reduced to 100 because I decrement the 20. And now 60 02:57.380 --> 02:58.200 because I have 61 02:58.200 --> 03:01.940 a higher priority on my standby and because I have preemption enabled, I will WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 61 02:58.200 --> 03:01.940 a higher priority on my standby and because I have preemption enabled, I will 62 03:01.940 --> 03:02.720 take over 63 03:02.720 --> 03:08.070 as the FHRP active. Now, notice that the spanning tree blocking isn't going to 64 03:08.070 --> 03:09.240 change. I'm still 65 03:09.240 --> 03:13.590 going to send traffic up here and it will get hop over this way, but at least 66 03:13.590 --> 03:14.760 even independent 67 03:14.760 --> 03:20.610 of layer three issues, we can get routed upstream. And depending on the 68 03:20.610 --> 03:21.520 situation, maybe we 69 03:21.520 --> 03:25.700 do look at shutting down this link or whatever the situation is, but ultimately 70 03:25.700 --> 03:26.400 what we care 71 03:26.400 --> 03:31.840 about within FHRP object tracking is ensuring that our network stays online and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 71 03:26.400 --> 03:31.840 about within FHRP object tracking is ensuring that our network stays online and 72 03:31.840 --> 03:32.720 functional 73 03:32.720 --> 03:37.240 when network failures occur that don't directly take the active node down.