WEBVTT 0:00:02.820000 --> 0:00:08.460000 Hello and welcome to this video titled the Network Time Protocol NTP. 0:00:08.460000 --> 0:00:13.100000 In this video I'm going to answer the question, why do we keep track of 0:00:13.100000 --> 0:00:16.540000 time? Which is something my wife asked me all the time. 0:00:16.540000 --> 0:00:20.420000 We're going to talk about where do we get the clock, specifically for 0:00:20.420000 --> 0:00:24.040000 networks, sources of network time. 0:00:24.040000 --> 0:00:27.380000 I'm going to give you an overview of what NTP does and we'll talk about 0:00:27.380000 --> 0:00:31.260000 NTP clients and servers and then real briefly because it's only a couple 0:00:31.260000 --> 0:00:34.960000 of commands. I'll show you how to configure Cisco iOS devices for the 0:00:34.960000 --> 0:00:36.760000 network time protocol. 0:00:36.760000 --> 0:00:40.900000 Alright, so why do we need to keep track of time? 0:00:40.900000 --> 0:00:44.140000 I'm not talking about from a personal perspective, I'm talking about networking 0:00:44.140000 --> 0:00:46.100000 devices. Why is this? 0:00:46.100000 --> 0:00:48.820000 Well, Cisco devices and everything else. 0:00:48.820000 --> 0:00:53.060000 It doesn't matter if it's Cisco or Juniper or a Viya or whatever it is, 0:00:53.060000 --> 0:00:58.920000 networking devices in general and servers utilize time and keeping track 0:00:58.920000 --> 0:01:02.500000 of time for a lot of different devices, for a lot of different reasons. 0:01:02.500000 --> 0:01:04.640000 Let's just focus on Cisco devices for a second. 0:01:04.640000 --> 0:01:06.280000 Logging output, right? 0:01:06.280000 --> 0:01:08.860000 There's all sorts of sys logs and messages that can be logged, that can 0:01:08.860000 --> 0:01:12.660000 tell you when something happened or when an event or notification happened 0:01:12.660000 --> 0:01:16.940000 and a lot of times those things have some sort of timestamp on them. 0:01:16.940000 --> 0:01:20.720000 We want that timestamp to be accurate or else that message is kind of 0:01:20.720000 --> 0:01:24.980000 pointless if we weren't dropped up. 0:01:24.980000 --> 0:01:27.260000 Debugging output, same thing. 0:01:27.260000 --> 0:01:30.800000 When we turn on some sort of debugging command, many of them have a timestamp 0:01:30.800000 --> 0:01:32.260000 associated with it. 0:01:32.260000 --> 0:01:35.520000 It's a lot more useful to try to figure out a troubleshooting if that 0:01:35.520000 --> 0:01:38.200000 timestamp is accurate. 0:01:38.200000 --> 0:01:43.560000 User show commands in Cisco devices when you issue a show command to monitor 0:01:43.560000 --> 0:01:47.980000 something, many times there's a timestamp associated with that that would 0:01:47.980000 --> 0:01:51.220000 be much more useful if it was an accurate timestamp. 0:01:51.220000 --> 0:01:55.360000 And certainly network management and reporting tools need to have accurate 0:01:55.360000 --> 0:02:00.300000 timestamps. If all of our devices are routers, switches, firewalls, load 0:02:00.300000 --> 0:02:03.660000 balancers, everything else, if they all have their own independent clocks 0:02:03.660000 --> 0:02:06.960000 that are not synchronized are all over the place and yet we're trying 0:02:06.960000 --> 0:02:11.700000 to monitor them from some central place like a DNA center appliance or 0:02:11.700000 --> 0:02:15.620000 something like that, well monitoring them becomes very problematic if 0:02:15.620000 --> 0:02:18.620000 the time they're reporting to us is all over the map. 0:02:18.620000 --> 0:02:22.000000 We need everything to be synchronized. 0:02:22.000000 --> 0:02:27.060000 So having an accurate timestamp on the above features can be critical. 0:02:27.060000 --> 0:02:29.380000 So where do we get that accurate clock? 0:02:29.380000 --> 0:02:33.740000 Well, all routers and switches and most firewalls and everything else 0:02:33.740000 --> 0:02:38.620000 have some sort of internal system clock, just like your laptop, just like 0:02:38.620000 --> 0:02:40.280000 your tablet, your smartphone. 0:02:40.280000 --> 0:02:42.800000 They all come with some sort of clock built into them. 0:02:42.800000 --> 0:02:47.220000 Now the question is, is that clock just a local clock that's not paying 0:02:47.220000 --> 0:02:52.000000 attention to anything around it or is it synchronized with something else? 0:02:52.000000 --> 0:02:55.940000 Well, by default Cisco routers and switches and firewalls, they have an 0:02:55.940000 --> 0:03:00.400000 internal clock, it's a battery driven clock, but it's not synchronized 0:03:00.400000 --> 0:03:04.580000 to anything. What's actually kind of funny is that if you set a router 0:03:04.580000 --> 0:03:09.480000 switch back to factory defaults, if you completely destroy its configuration, 0:03:09.480000 --> 0:03:13.920000 power cycle and have it come back up, its default clock will say something 0:03:13.920000 --> 0:03:19.540000 like 1993. It's not even close to being accurate. 0:03:19.540000 --> 0:03:25.180000 So we need to synchronize these devices to a common time and date, and 0:03:25.180000 --> 0:03:29.700000 that is what the network time protocol was designed to do. 0:03:29.700000 --> 0:03:34.480000 All right, so the network time protocol can pull time and date information 0:03:34.480000 --> 0:03:37.100000 from a clock source. 0:03:37.100000 --> 0:03:39.780000 But where is that clock source going to come from? 0:03:39.780000 --> 0:03:44.440000 Where is that common clock that everybody is synchronizing to? 0:03:44.440000 --> 0:03:47.460000 Well, we could do it via manual configuration. 0:03:47.460000 --> 0:03:50.140000 There's nothing stopping me from logging into every single router switch, 0:03:50.140000 --> 0:03:54.340000 looking at my watch, and real quickly doing the clock set command and 0:03:54.340000 --> 0:03:57.700000 setting it. And in that case, they'll be pretty close, right? 0:03:57.700000 --> 0:04:00.720000 They're all synchronized off my watch and they'll be within a few seconds 0:04:00.720000 --> 0:04:04.160000 of each other, but we might want to use something a little bit more accurate 0:04:04.160000 --> 0:04:06.680000 than that like the network time protocol. 0:04:06.680000 --> 0:04:10.900000 There's also the simple network time protocol and vines. 0:04:10.900000 --> 0:04:16.240000 Not going to talk about those two, but NTP, SNTP and vines are three protocols 0:04:16.240000 --> 0:04:20.520000 that were developed to pull time and date information from a central place 0:04:20.520000 --> 0:04:25.420000 and propagate that across multiple devices so that they can all be synchronized. 0:04:25.420000 --> 0:04:30.280000 All right, so let's talk a little bit more about NTP specifically, the 0:04:30.280000 --> 0:04:31.680000 network time protocol. 0:04:31.680000 --> 0:04:34.420000 This is an IETF standard, so it's not proprietary. 0:04:34.420000 --> 0:04:38.380000 You can see here the RFCs if you want to dig into this and find out a 0:04:38.380000 --> 0:04:41.500000 lot more details of how they work because this video is just an introduction 0:04:41.500000 --> 0:04:43.300000 to this protocol. 0:04:43.300000 --> 0:04:47.220000 It does use UDP and uses UDP port 123. 0:04:47.220000 --> 0:04:51.040000 This one's kind of interesting in that, you know, most protocols when 0:04:51.040000 --> 0:04:56.820000 I say, oh, this protocol uses TCP port 23 or UDP port 5 or TCP port 17, 0:04:56.820000 --> 0:05:01.020000 well, usually when we say that, what that really means is that the client 0:05:01.020000 --> 0:05:05.980000 who's initiating a message will use some random ephemeral port number 0:05:05.980000 --> 0:05:09.720000 that you can't predict, and the destination port number of the server 0:05:09.720000 --> 0:05:14.580000 is trying to reach, that will be the well-known port number. 0:05:14.580000 --> 0:05:19.240000 But with NTP, it's interesting that port number 123 is used as both the 0:05:19.240000 --> 0:05:22.180000 source and the destination port. 0:05:22.180000 --> 0:05:25.900000 Not too many protocols that you see that type of behavior. 0:05:25.900000 --> 0:05:30.380000 So NTP nodes can obtain their time from an authoritative source. 0:05:30.380000 --> 0:05:31.580000 What is that source? 0:05:31.580000 --> 0:05:37.100000 Well, the absolute hands-down, most accurate type of clock is something 0:05:37.100000 --> 0:05:39.140000 called an atomic clock. 0:05:39.140000 --> 0:05:41.580000 Now, I am not a physicist. 0:05:41.580000 --> 0:05:45.260000 A long time ago, I tried to Google this and figured out how it works, 0:05:45.260000 --> 0:05:47.220000 and this was sort of my takeaway from it. 0:05:47.220000 --> 0:05:50.240000 So all you physicists who are watching me out there don't blame me if 0:05:50.240000 --> 0:05:51.200000 I get this wrong. 0:05:51.200000 --> 0:05:56.600000 But what I gathered was that an atomic clock actually uses certain types 0:05:56.600000 --> 0:06:02.820000 of crystals, and these crystals vibrate at a certain rate, like when you 0:06:02.820000 --> 0:06:06.220000 expose them to energy or electricity or something, that they vibrate at 0:06:06.220000 --> 0:06:10.340000 a certain rate that's constant, that never changes, that never shifts. 0:06:10.340000 --> 0:06:14.060000 And because these crystals are so predictable in their vibrations, we 0:06:14.060000 --> 0:06:17.680000 can lock onto that and use that as a clock source. 0:06:17.680000 --> 0:06:19.900000 That just blew my mind when I read that. 0:06:19.900000 --> 0:06:24.040000 In case you're curious, here's some pictures of what an atomic clock looks 0:06:24.040000 --> 0:06:27.400000 like. So if you're in the market for one, you got an extra $2.7 million 0:06:27.400000 --> 0:06:30.680000 city, and you're sitting around, I would prefer that you send it to me, 0:06:30.680000 --> 0:06:33.380000 but if you don't want to do that, you can buy one of these atomic clocks 0:06:33.380000 --> 0:06:36.160000 here and use that as your clock source. 0:06:36.160000 --> 0:06:38.300000 But that's not the only place, right? 0:06:38.300000 --> 0:06:42.880000 So you can also get your clocking from GPS, you can get it from a radio 0:06:42.880000 --> 0:06:48.780000 clock, or one network device could serve up its time and date to another 0:06:48.780000 --> 0:06:50.580000 networking device. 0:06:50.580000 --> 0:06:53.540000 So there's all sorts of ways that you can do that. 0:06:53.540000 --> 0:06:58.100000 So in NTP, we basically have two different types of roles. 0:06:58.100000 --> 0:06:59.880000 We've got the NTP client. 0:06:59.880000 --> 0:07:02.660000 So that would typically be your router, your switch, your firewall that's 0:07:02.660000 --> 0:07:05.480000 polling the NTP server. 0:07:05.480000 --> 0:07:08.440000 So the client says, hey, I need your time and date information, I need 0:07:08.440000 --> 0:07:09.840000 to synchronize with you. 0:07:09.840000 --> 0:07:13.980000 And then the NTP server will respond back and give that information. 0:07:13.980000 --> 0:07:18.180000 So this is one critical piece here, is that the NTP server does not need 0:07:18.180000 --> 0:07:22.720000 to know in advance the IP address of the clients. 0:07:22.720000 --> 0:07:26.680000 It's just sitting there waiting for the clients to ask it for information. 0:07:26.680000 --> 0:07:29.680000 Now there are, going above and beyond the basics of what I'm going to 0:07:29.680000 --> 0:07:33.220000 talk about here, there are ways that you can configure the NTP server 0:07:33.220000 --> 0:07:36.440000 in advance to know what clients to talk to. 0:07:36.440000 --> 0:07:39.500000 There's even NTP passwords that you can use. 0:07:39.500000 --> 0:07:44.060000 But at a real simple level, on the server, you just configure one command 0:07:44.060000 --> 0:07:46.040000 saying, hey, you're a server. 0:07:46.040000 --> 0:07:49.040000 You don't tell him who he's going to talk to, you just say, you're going 0:07:49.040000 --> 0:07:53.520000 to do this job. And on the clients, you point to the IP address of the 0:07:53.520000 --> 0:07:55.280000 server, and that's it. 0:07:55.280000 --> 0:07:58.420000 And then you start periodically polling about once a minute or so to talk 0:07:58.420000 --> 0:08:04.420000 to that server. Now from an NTP perspective, this server is considered 0:08:04.420000 --> 0:08:09.540000 an authoritative source of time based on its stratum level. 0:08:09.540000 --> 0:08:10.880000 What is a stratum level? 0:08:10.880000 --> 0:08:14.860000 Well, the idea behind a stratum level is that the lower the stratum number, 0:08:14.860000 --> 0:08:17.100000 the more accurate that clock. 0:08:17.100000 --> 0:08:21.760000 So for example, a stratum one device would be like a GPS clock. 0:08:21.760000 --> 0:08:26.760000 That would be the absolute most accurate clock you could ever possibly 0:08:26.760000 --> 0:08:31.780000 find. And then as you go up from there, that indicates how far away you 0:08:31.780000 --> 0:08:34.020000 are from that device. 0:08:34.020000 --> 0:08:37.700000 So for example, if I'm advertising myself to you, if I'm an NTP server 0:08:37.700000 --> 0:08:41.520000 and I say, hey, I'm a stratum two device, that means the clock is not 0:08:41.520000 --> 0:08:45.980000 actually coming from me, I'm getting it from somebody behind me. 0:08:45.980000 --> 0:08:48.380000 And this is also something that NTP could do. 0:08:48.380000 --> 0:08:53.380000 You could have cascading NTP, where one router is an NTP client and he 0:08:53.380000 --> 0:08:55.580000 queries the time and date from another router. 0:08:55.580000 --> 0:08:58.700000 That guy in turn is a client who queries it from another router who in 0:08:58.700000 --> 0:09:00.940000 turn queries it from a GPS clock. 0:09:00.940000 --> 0:09:03.000000 So you could do all sorts of things like that. 0:09:03.000000 --> 0:09:07.720000 Now let's just finish up here real quickly with basic configuration of 0:09:07.720000 --> 0:09:11.160000 NTP on Cisco iOS devices. 0:09:11.160000 --> 0:09:14.900000 So on the person who's going to be serving up the time and date, the router 0:09:14.900000 --> 0:09:17.300000 switch is going to be the NTP server. 0:09:17.300000 --> 0:09:20.500000 Number one, well, you want to set his clock, so you'll have to set it 0:09:20.500000 --> 0:09:22.080000 manually on that one. 0:09:22.080000 --> 0:09:24.100000 So there's your clock set command. 0:09:24.100000 --> 0:09:25.740000 And then there's just one command. 0:09:25.740000 --> 0:09:29.900000 At global configuration, you just type NTP master. 0:09:29.900000 --> 0:09:34.780000 And now if an NTP request comes in, he's capable of replying to that. 0:09:34.780000 --> 0:09:40.420000 By default, he will advertise himself as a stratum 8 device, but you can 0:09:40.420000 --> 0:09:45.660000 change that here by typing NTP master 2 or NTP master 3, something like 0:09:45.660000 --> 0:09:47.440000 that, if you wish to do that. 0:09:47.440000 --> 0:09:52.620000 On the client side, all you have to do is point the client to any of the 0:09:52.620000 --> 0:09:55.380000 available IP addresses on that server. 0:09:55.380000 --> 0:10:00.460000 So if that NTP server was a router that has 15 or 20 IP addresses, as 0:10:00.460000 --> 0:10:04.420000 long as your client can reach the IP address, you just type NTP server 0:10:04.420000 --> 0:10:08.180000 and then put in the IP address of that master. 0:10:08.180000 --> 0:10:10.480000 And then that's it, you're done. 0:10:10.480000 --> 0:10:13.560000 Now, how do you verify that this is actually working? 0:10:13.560000 --> 0:10:19.080000 Well, on either device, you can type show NTP status, but this is more 0:10:19.080000 --> 0:10:22.280000 applicable on the NTP client devices. 0:10:22.280000 --> 0:10:26.280000 And eventually, it should say clock is synchronized. 0:10:26.280000 --> 0:10:29.160000 Or you can do show NTP associations. 0:10:29.160000 --> 0:10:32.100000 And it'll show you the IP address of the master. 0:10:32.100000 --> 0:10:35.780000 And the main thing I want to point out your attention to right here is 0:10:35.780000 --> 0:10:39.400000 the asterisk right there. 0:10:39.400000 --> 0:10:44.080000 All right, so the little till day character means that is configured. 0:10:44.080000 --> 0:10:47.840000 I've manually configured it to be, so that is my NTP master. 0:10:47.840000 --> 0:10:51.620000 But until you see the asterisk, that means he's actually synchronized 0:10:51.620000 --> 0:10:54.300000 with that master. 0:10:54.300000 --> 0:10:57.240000 Now, before I bring this video to a close, it's one other thing I want 0:10:57.240000 --> 0:11:00.680000 to point out. I don't have a reason for this. 0:11:00.680000 --> 0:11:02.440000 I'm sure there is a reason. 0:11:02.440000 --> 0:11:07.380000 But I have seen in like a lab environment, two routers or router and a 0:11:07.380000 --> 0:11:10.800000 switch that are physically connected right next to each other. 0:11:10.800000 --> 0:11:15.080000 One is the NTP master, the other is the NTP client. 0:11:15.080000 --> 0:11:18.660000 I've done a sniffer trace and I've seen the NTP messages going back and 0:11:18.660000 --> 0:11:20.680000 forth every minute, so I know it's working. 0:11:20.680000 --> 0:11:28.140000 And yet, the NTP client can sometimes take five minutes or more to synchronize 0:11:28.140000 --> 0:11:30.000000 to the NTP master. 0:11:30.000000 --> 0:11:32.700000 I don't know why it takes that long, but it does. 0:11:32.700000 --> 0:11:35.380000 So I just want to give that to you as a word of warning that if you're 0:11:35.380000 --> 0:11:39.820000 going to practice NTP in a lab environment, don't be surprised if you 0:11:39.820000 --> 0:11:44.180000 have to wait several minutes before the master and the client actually 0:11:44.180000 --> 0:11:46.040000 become synchronized with each other. 0:11:46.040000 --> 0:11:49.240000 Something's happening in the background that I don't understand internally 0:11:49.240000 --> 0:11:52.880000 that takes a long time for that to happen. 0:11:52.880000 --> 0:11:58.400000 So that concludes this video on an introduction to NTP. 0:11:58.400000 --> 0:11:59.300000 Thank you for watching.