WEBVTT 00:00:00.000 --> 00:00:11.000 Our on-course syslog discussion, folks, is not much different than CCNA. That's why we 00:00:11.000 --> 00:00:16.680 decided to have it as a recorded video here. So, we're going to go through a lot of the 00:00:16.680 --> 00:00:23.760 same things you learned in CCNA and be ready for questions on the exam pertaining to syslog 00:00:23.760 --> 00:00:29.980 at a pretty high level, meaning a pretty fundamental level when it comes to syslog configuration 00:00:29.980 --> 00:00:35.980 and verification. So, what is syslog all about? Syslog is used for monitoring and auditing 00:00:35.980 --> 00:00:44.380 purposes. Think of your device and the fact that there are going to be times when events happen. 00:00:44.380 --> 00:00:48.820 What do I mean by an event? Well, an event is a change of state. So, like an interface going up, 00:00:48.820 --> 00:00:55.860 an interface going down, that is a change of state. And when that change of state happens, 00:00:55.980 --> 00:01:03.540 there could be other events that occur, changes of state as well. And it is imperative that we 00:01:03.540 --> 00:01:09.980 get notified about those changes of state, about those events. So, for example, in this case, 00:01:09.980 --> 00:01:15.260 interface gigabit ethernet 1 slash 0 has been shut down. So, that's a change of state. We've 00:01:15.260 --> 00:01:21.500 gone from up to down. And you'll see just based on that, we've had three syslog messages generated. 00:01:21.500 --> 00:01:28.900 We had one message generated from EIGRP that has indicated that we've lost our neighbor adjacency 00:01:28.900 --> 00:01:35.660 because the interface to reach that neighbor is now down. And if we look at these two bottom 00:01:35.660 --> 00:01:40.940 messages, it says that gig 1 0 has been changed to administratively down because somebody typed 00:01:40.940 --> 00:01:47.100 the shutdown command. And then line protocol has now been changed to state down as well. So, 00:01:47.180 --> 00:01:52.220 our interface is now down, down. And we've lost our EIGRP neighbor adjacency. So, 00:01:52.220 --> 00:01:59.740 that's what syslog does for us. It gives us the opportunity to get notified about those changes 00:01:59.740 --> 00:02:05.740 of states, about those events. And who deems what the events are? Well, that is Cisco on Cisco iOS. 00:02:05.740 --> 00:02:09.020 Now, there are devices out there, some Cisco products out there where you could actually 00:02:09.020 --> 00:02:14.100 change syslog messages. You could change severity levels about them. You can manipulate them. But 00:02:14.100 --> 00:02:20.940 Cisco iOS doesn't allow you to do that. So, what Cisco gives you is what you get when it's all said 00:02:20.940 --> 00:02:27.060 and done. Now, when you cover EEM and vetted event manager, you'll see that you can create some of 00:02:27.060 --> 00:02:32.820 your own custom syslog messages for specific events. So, that is where you can actually do 00:02:32.820 --> 00:02:37.780 that. But you can't just change the syslog messages right on the device. You would have 00:02:37.780 --> 00:02:44.660 to use EEM for that instead and create your own custom syslog messages. So, syslog is enabled by 00:02:44.660 --> 00:02:50.340 default on all of our Cisco products. And syslog messages by default will go to the console port 00:02:50.340 --> 00:02:57.380 to go to the VTY lines. And they'll even be sent to RAM. Now, the problem with all three of those 00:02:57.380 --> 00:03:02.500 options is that they are temporary in nature. That's right. So, for the console port, you have 00:03:02.500 --> 00:03:06.820 to be connected to the console port when that message is generated to see it or you will not 00:03:06.820 --> 00:03:12.500 see it. Likewise, with the VTY lines, you have to be connected to the VTY lines when that syslog 00:03:12.500 --> 00:03:18.980 message is generated or you are not going to see it. With RAM, well, it's only so large. There's 00:03:18.980 --> 00:03:22.660 only so much memory available for it. Now, you could adjust the size of the memory. But don't 00:03:22.660 --> 00:03:27.700 forget, if you adjust the size of the memory of RAM, then what you are taking away RAM from other 00:03:27.700 --> 00:03:34.420 resources on the device or other services that need that RAM on the device. So, the recommendation 00:03:34.420 --> 00:03:39.540 and the best practice is to what? Have a server set up in your environment somewhere. 00:03:39.540 --> 00:03:45.860 And that server would be what? A syslog server. And what you're going to do is you're going to 00:03:45.860 --> 00:03:51.940 set up your device to send syslog messages to that syslog server. So, that way there, 00:03:51.940 --> 00:03:58.500 it can amalgamate all those messages central on that particular server. So, a syslog server is 00:03:58.500 --> 00:04:05.620 a centralized repository that will gather and collect or collect and gather all of those syslog 00:04:05.620 --> 00:04:10.980 messages from all the different devices that you have. Also, severity levels, which you're going 00:04:10.980 --> 00:04:14.740 to have to memorize for the certification exam. So, if you memorize them for CCNA and you forgot 00:04:14.740 --> 00:04:20.020 what they are, you're going to have to memorize them again for Encore. So, let's talk about how 00:04:20.020 --> 00:04:26.820 we read our syslog messages. So, when we read our syslog messages, we start off here with our date 00:04:26.820 --> 00:04:31.540 and time. Now, if you're not seeing the date and time, it's because you don't have it turned on 00:04:31.540 --> 00:04:39.620 for your particular device. So, for example, in R1 right now, if I type in configure terminal and we 00:04:39.620 --> 00:04:45.060 exit out, there's a syslog message generated anytime you go back to privilege exec mode. 00:04:45.060 --> 00:04:51.140 You'll see that there's a date and time stamp there. So, that is showing up because I have 00:04:51.460 --> 00:04:58.980 timestamps enabled for my log messages. So, let me type in here no service dash timestamps. No 00:04:58.980 --> 00:05:04.980 service space timestamps. Okay. Now, you'll see when we exit back out, there is nothing showing 00:05:04.980 --> 00:05:10.660 up there. So, if that is what you got and you want to see your timestamps and your log messages, 00:05:10.660 --> 00:05:17.700 then you would type in service timestamps and then you would specify for what. So, I want to 00:05:17.700 --> 00:05:24.020 set it up for my log messages and I want it based on what? Based on my date, based on my time 00:05:24.580 --> 00:05:30.020 instead of my what? My uptime. So, the last time the device rebooted, that's what uptime would be. 00:05:30.020 --> 00:05:35.780 Right now, when we exit out, you're going to see we have our timestamp there. One thing I want you 00:05:35.780 --> 00:05:43.860 to realize is that the timestamps on our devices are going to be based on what? Based on UTC 00:05:44.660 --> 00:05:50.420 time. Okay. UTC time, not local time. So, if I type in show clock right now, 00:05:50.420 --> 00:05:58.180 right, this is UTC time. So, let's go ahead and configure, like we did in our NTP discussion, 00:05:59.540 --> 00:06:05.700 our time zone command. So, if I type in clock time zone and then we'll say minus four zero. Oops. 00:06:06.500 --> 00:06:11.460 Let's put Atlantic Standard Time four zero. Right. And I'm not going to do the summertime option 00:06:11.460 --> 00:06:15.860 right now. I don't care about that because I just want to show you now. If I type in show clock 00:06:18.660 --> 00:06:26.260 and you compare the clock to the syslog messages, notice that the syslog messages are still in UTC 00:06:26.260 --> 00:06:32.900 time. Whereas the clock is now in Atlantic Standard Time, as an example. So, what we want 00:06:33.460 --> 00:06:40.660 to do is, if you want to, if you want to, if you want these syslog messages to show the local time, 00:06:40.660 --> 00:06:48.900 then you need to put this command in. So, service timestamps log date time, but then type in at the 00:06:48.900 --> 00:06:56.020 end local time. When you type in local time, you'll see that the syslog messages now use the 00:06:56.100 --> 00:07:08.180 local clock's time, not UTC time. Just something to keep in mind. So, if you're looking at messages 00:07:08.180 --> 00:07:11.940 and the times don't match or you're looking at a scenario and the times don't match, 00:07:12.500 --> 00:07:17.700 why are my syslog messages, why don't they match my actual clock? Well, it's because your clock's 00:07:17.700 --> 00:07:27.620 UTC or your clock is, I should say, set to use your local time as opposed to UTC time and your 00:07:27.620 --> 00:07:31.940 syslog messages default to using UTC time. So, if you want local time for the syslog messages as 00:07:31.940 --> 00:07:44.660 well, you have to add the local time command to your service timestamp. Notice how we have a star 00:07:44.660 --> 00:07:52.340 here with these syslog messages. Notice how in my case, I have a period with these syslog messages. 00:07:52.340 --> 00:07:57.300 What does the star mean? What does the period mean? All right. Well, the star symbol means 00:07:58.020 --> 00:08:05.300 time is not authoritative. Time is not authoritative. It means that the software 00:08:05.300 --> 00:08:14.260 clock is not in sync or has never been set. It's not in sync or it has never been set. So, 00:08:14.260 --> 00:08:19.940 the star, the asterisk before the local time indicates that the time may be incorrect 00:08:20.740 --> 00:08:26.100 because the system clock has not synchronized to a reliable time source. That's what a star means. 00:08:26.100 --> 00:08:31.620 Okay. But what does the period mean that we see? So, the period means that the time is authoritative. 00:08:32.340 --> 00:08:39.300 Time is authoritative, but NTP is not synchronized. That's right. The period means time is authoritative, 00:08:39.300 --> 00:08:48.820 but NTP is not synchronized. So, the software clock was in sync, but has since lost contact 00:08:48.820 --> 00:08:56.180 with all configured NTP servers. That's right. So, if you see the period, it means that 00:08:56.820 --> 00:09:04.660 it's authoritative, but NTP is no longer synchronized. That's what the period means. Period. 00:09:04.660 --> 00:09:10.580 And so, I made this happen on purpose so I could show you this because in our NTP discussion, 00:09:10.580 --> 00:09:15.060 previously, we synchronized everything up. Well, I forced it to unsync so I could show 00:09:15.060 --> 00:09:24.340 you this particular period. What if you don't see a period? What if you don't see a star? 00:09:24.340 --> 00:09:29.620 What if you see nothing? What does that mean? Let's see if I have that example of that here. 00:09:30.580 --> 00:09:36.020 No. All right. If you don't see anything, no period, no star, what does that mean? 00:09:36.660 --> 00:09:43.060 It means that time is authoritative and the software clock is in sync. 00:09:44.180 --> 00:09:48.180 Is in sync. Or it's been manually set with the clock set command. 00:09:48.420 --> 00:09:55.060 Back to reading this. So, you have your time. What's next? Next, you have your facility 00:09:55.060 --> 00:09:58.900 and there's going to be a new facility that you're going to install. 00:09:58.900 --> 00:10:05.620 So, what information do you have, especially what's going to happen when you install a new facility? 00:10:05.620 --> 00:10:11.700 What is located where? It's what's located on what's going to happen when you're installing 00:10:11.700 --> 00:10:15.940 a new facility? This is a video on how to install a new facility, 00:10:15.940 --> 00:10:23.620 your facility. So, this is our facility. This is our facility. This is our facility. 00:10:24.420 --> 00:10:30.180 The facility is the service or the function that triggered the message. So, the source of 00:10:30.180 --> 00:10:34.900 the message. So, dual in this case is EIGRP triggered it. Link is layer one. Line protocol 00:10:34.900 --> 00:10:48.020 is layer two. You then have your severity levels. You then have your severity levels. 00:10:49.940 --> 00:10:55.460 So, five is a notification. Six is informational. Seven is debug. Four is warning. Three is errors. 00:10:55.460 --> 00:11:00.180 Two is critical. One is alert. Zero is emergency. It doesn't hurt to memorize that for the exam, 00:11:00.580 --> 00:11:12.340 even at the CCNP level. Every awesome Cisco engineer will need ice cream daily. That helps. 00:11:12.340 --> 00:11:17.620 Great. If not, don't worry about it. Every awesome Cisco engineer will need ice cream daily. 00:11:17.620 --> 00:11:19.140 Zero, one, two, three, four, five, six, seven. 00:11:22.260 --> 00:11:28.500 Next, we have what is called a mnemonic. This is our mnemonic. Mnemonic. 00:11:28.500 --> 00:11:35.380 Mnemonic. Mnemonic. Mnemonic. And essentially, what it is, is a device-specific code that 00:11:35.380 --> 00:11:40.900 uniquely identifies the message. So, a neighbor change or a change or up, down. It really depends 00:11:40.900 --> 00:11:46.500 on the scenario and situation which shows up there. And then lastly, you have your description, 00:11:46.500 --> 00:11:53.060 your message. So, in this case, it says EIGRP for IPv4 autonomous system number 100 has a neighbor 00:11:53.060 --> 00:11:58.420 of 10.0.12.2, a gigabit Ethernet one size zero, and it is down. Why? Because the interface is down. 00:11:58.980 --> 00:12:03.300 This particular message says interface gigabit Ethernet one size zero has changed state to 00:12:03.300 --> 00:12:07.780 administratively down. Why does an interface go administratively down? Because somebody typed the 00:12:07.780 --> 00:12:12.820 site down command. And then lastly, this one is lying protocol on interface gig one zero changed 00:12:12.820 --> 00:12:19.700 state to down. So, we're down at layer two, down at layer two, down at layer one, and EIGRP is now 00:12:19.700 --> 00:12:27.540 down as well on that interface. All right. So, when we look at our messages in our console, 00:12:29.140 --> 00:12:36.420 I'm just going to type in right now debug IP OSPF hello, just so we can see our debug messages. 00:12:37.140 --> 00:12:41.700 All right. This is the console. I'm connected to the console right now, folks. And by default, 00:12:41.700 --> 00:12:48.260 those messages appear on our console. Notice I have no timestamps for debug because when I typed 00:12:48.260 --> 00:12:55.620 in timestamp log, log does not include debugs. If I wanted debugs and my log messages, I would 00:12:55.620 --> 00:13:01.380 have to type in service timestamps. Debug means all of them, daytime local. So, let me do that 00:13:01.380 --> 00:13:06.340 right now just to show you. So, configure terminal. Just in case you were wondering, hey, why is there 00:13:06.340 --> 00:13:11.220 no timestamps on the debugs? Because we did not type in debug. Instead, we just typed in log. 00:13:11.940 --> 00:13:17.460 Debug. Let's do that again. Debug. And you'll see that the timestamps are going to start showing up 00:13:17.460 --> 00:13:21.780 now. There you go. That's the only reason why they weren't. All right. So, with that in mind 00:13:21.780 --> 00:13:26.340 now, this is the console port. We're seeing what's happening at the console port. Pretty 00:13:26.340 --> 00:13:40.020 straightforward. Now, let's go to DSW1 and let's telnet over to R1. So, I'm connected to R1 right 00:13:40.020 --> 00:13:48.500 now from DSW1 via telnet. Notice how those debugs are not showing up. They're still here 00:13:48.500 --> 00:13:54.340 on the console of R1, but they're not showing up in my terminal telnet session, or they would not 00:13:54.340 --> 00:14:00.100 be showing up in my SSH session. Why is that? Why is that? It's because of this right here. 00:14:01.940 --> 00:14:08.580 You need to commit a terminal monitor to view any syslog messages if you've telneted or SSHed 00:14:09.140 --> 00:14:14.980 into a device. Very, very important. So, over on R1, if I type in terminal now 00:14:14.980 --> 00:14:18.420 monitor, you're going to see the syslog messages show up. 00:14:20.340 --> 00:14:25.300 So, that's a command that you're going to need to remember. If you want to see syslog messages 00:14:26.660 --> 00:14:34.420 or tel – when you are telneted or SSHed into a device, you are going to have to type in terminal 00:14:34.420 --> 00:14:52.820 monitor. And how do you shut it off? The command is terminal new monitor. Terminal new monitor, 00:14:52.820 --> 00:15:00.020 not new terminal monitor. Terminal new monitor. There we go. And now you're going to see they're 00:15:00.020 --> 00:15:05.700 no longer appearing here. But look, they're still appearing on R1 because it's a console port. 00:15:07.220 --> 00:15:10.900 So, there's a difference there. All right. Let's take a peek at where we can see what's 00:15:10.900 --> 00:15:16.980 happening in RAM. I'm going to type in you all or do you all to shut off the debugs here. 00:15:17.540 --> 00:15:24.740 All right. So, now what I want to do is I want to type in show logging. And if we scroll down, 00:15:24.740 --> 00:15:31.060 you're going to see console logging. That means the console port. So, debugging through emergencies. 00:15:31.060 --> 00:15:35.380 That's what that means. Debugging all the way down to emergencies, every single one. 00:15:35.380 --> 00:15:40.820 Monitor, that's the VTY line. So, telnet and SSH connections, all of them. Buffer logging, 00:15:41.380 --> 00:15:47.860 that means to RAM, all of them. And so, where is RAM? If I just keep hitting enter, it's all here. 00:15:48.740 --> 00:15:54.980 It's all here. Right. The thing is, is that I ran out of space. So, I keep overwriting, 00:15:54.980 --> 00:16:00.020 overwriting, overwriting, overwriting. So, you'll see that most of these messages are just from 00:16:01.060 --> 00:16:06.900 our example we were just doing. And that's it. So, we scroll back up. These are all the debugs 00:16:07.780 --> 00:16:12.820 that we just produced in our moments ago. And there's the ones without the timestamps. 00:16:13.780 --> 00:16:21.060 And here's some additional information that was collected earlier on October 19th. So, 00:16:21.060 --> 00:16:27.380 that's still today. And October 18th, that's yesterday. So, with that information there, 00:16:27.380 --> 00:16:30.980 you can see it's not very big. We're just going to keep overwriting, overwriting. 00:16:31.620 --> 00:16:37.060 So, if I go ahead and keep running my debug, then all of this would be gone within moments, 00:16:37.060 --> 00:16:41.060 because we pretty much maxed it out already. There's 8,192 bytes. It's not big. 00:16:41.780 --> 00:16:46.500 So, for long-term storage, this is not a great option. So, that's why a syslog server is so 00:16:46.500 --> 00:16:52.740 important. So, if you ever want to shut off logging to the console, you just type in no 00:16:52.740 --> 00:16:58.660 logging console, and it would shut it off. So, now if we type in do show logging, you'll see that 00:16:58.660 --> 00:17:04.340 it's disabled. You want to turn it back on, you type in logging console. So, the same thing is 00:17:04.340 --> 00:17:08.980 true for the VTY lines. You don't want to log it all to the VTY lines, type in no logging monitor. 00:17:08.980 --> 00:17:11.380 You don't want to log it all to the buffer, no logging buffer. 00:17:14.660 --> 00:17:20.180 So, now that we've turned it back on for console, you'll see it defaults to using debugging. So, 00:17:20.180 --> 00:17:24.740 if you ever wanted to change the level, then you would type in logging console, 00:17:24.740 --> 00:17:29.140 and then you specify your severity level. So, what is the severity level here that we want 00:17:29.140 --> 00:17:33.620 to specify? Well, whichever one we want, let's say four, just for fun. So, if I type, oops, 00:17:33.620 --> 00:17:39.220 logging console four, and now if we take a look at do show logging, we're going to see in our 00:17:39.220 --> 00:17:43.540 output that we're level warnings. That means warnings, errors, critical alerts, and emergencies. 00:17:44.740 --> 00:17:48.100 That's what that means. So, it's not just warnings, it's that and everything lower. 00:17:49.220 --> 00:17:52.660 And so, the same thing would be true with our VTY lines. You can modify that one as well. 00:17:55.140 --> 00:17:59.540 And your buffer. So, just by typing in logging monitor, and then the severity level, 00:17:59.540 --> 00:18:03.860 or logging buffer, and the severity level. In addition for the buffer, you can type in logging 00:18:04.900 --> 00:18:17.460 buffered. And then you could change even your buffer size if you want to. Again, you change 00:18:17.460 --> 00:18:22.340 the buffer size, you take away RAM that could be used for other things. So, be mindful of that. 00:18:22.340 --> 00:18:28.660 So, how do we go ahead and set up our 00:18:32.340 --> 00:18:38.100 connection to a syslog server? So, I don't have a syslog server in my possession. 00:18:40.900 --> 00:18:48.500 That's okay, but we'll fake it. So, these are the commands we would need to have. So, first of all, 00:18:48.500 --> 00:18:54.180 the command logging host. So, if I type in logging host, that's going to allow me to specify the IP 00:18:54.180 --> 00:18:59.620 address of my syslog service. So, it could be an IPv4 address or an IPv6 address. So, let's just 00:18:59.620 --> 00:19:06.420 go ahead and fake it today. We're going to say 10.0.3.8 for fun. And then, if you want to set 00:19:06.420 --> 00:19:12.260 the severity level, you can set it with the logging trap command. But what is the default 00:19:12.260 --> 00:19:17.860 severity level? Let's check it out. We'll type in do show logging. So, the default severity level 00:19:18.820 --> 00:19:25.380 is going to be informational. So, that's everything but debugging. So, you're not 00:19:25.380 --> 00:19:28.500 going to send the debugs to the syslog server by default, but you'll send everything else 00:19:28.500 --> 00:19:34.500 to the syslog server. So, you can change that if you want to. So, logging trap. So, logging. 00:19:38.100 --> 00:19:41.700 And you can change the severity level. So, if you want debugs, then put in seven. 00:19:41.700 --> 00:19:47.620 And there'll be seven and everything lower. If you want warnings and lower, then four, 00:19:47.620 --> 00:19:54.580 as an example. So, whatever you want to set up is up to you in your environment or a scenario 00:19:54.580 --> 00:20:00.820 on a certification exam. So, trap logging level warnings. You'll see the IP addresses listed there 00:20:00.820 --> 00:20:05.380 and then the UDP port number. So, by default, it's UDP port 514. But what I want to point out to you 00:20:05.380 --> 00:20:10.260 is that you have the ability to use something like TCP instead if you want to. That's right. 00:20:10.260 --> 00:20:15.540 You don't have to use UDP. So, if we wanted to use TCP instead, logging host 00:20:15.540 --> 00:20:22.980 10.0.3.8, we can change that to by typing in transport and then you can specify, for example, 00:20:22.980 --> 00:20:28.660 TCP. And then we can hit enter. And now, if we go back and take a look at show logging, 00:20:28.660 --> 00:20:38.420 we'll see here that we're using TCP port 601 for our logging to that particular server. 00:20:39.380 --> 00:20:43.700 So, I've set it up twice. I'd have to delete the other config, the other one. So, every time you 00:20:43.700 --> 00:20:47.300 type in logging whatever and you add, it's a different command, different command, different 00:20:47.300 --> 00:20:53.780 command. So, I'd have to go and delete the other one. In addition, you can set up the source 00:20:53.780 --> 00:20:58.260 interface you want the log messages sent from the syslog server. So, this is important. It's the 00:20:58.260 --> 00:21:03.700 same thing with NTP. It's the same thing with NetFlow. It'd be the same thing even with SNMP. 00:21:04.020 --> 00:21:07.780 What is the source IP address we want to use to talk to that particular device? 00:21:07.780 --> 00:21:11.700 So, that way there, we can set up a filter, for example, on our syslog server that says 00:21:11.700 --> 00:21:17.140 only accept syslog messages from these IP addresses. So, in this case, for example, logging. 00:21:21.220 --> 00:21:23.300 Logging. Oh, my gosh. What is the command? 00:21:24.660 --> 00:21:28.260 Logging. In this case, it's just source interface. All right. Source interface. 00:21:28.820 --> 00:21:30.900 And then, let's say loopback 00:21:33.860 --> 00:21:39.540 192 as an example. So, now if I type in do show logging, you're going to see that the 00:21:39.540 --> 00:21:50.740 source interface is listed there. All right. Now, in addition, what I want you to realize 00:21:50.740 --> 00:21:57.940 is that we can also do VRS as well. What do we mean by VRS? Well, virtual routing and forwarding. 00:21:58.020 --> 00:22:05.940 So, if, for example, we had a management VRF and we wanted to ensure that the syslog messages were 00:22:05.940 --> 00:22:13.620 being sent from that source interface in that VRF as an example, well, then our command instead would 00:22:13.620 --> 00:22:26.500 be logging host and then put in the IP address, for example, 10.0.3.8. And then the VRF is next. 00:22:26.500 --> 00:22:33.300 And then the VRF name. So, whatever the VRF name is, let's just call it Encore VRF. And then, 00:22:34.660 --> 00:22:38.900 again, what is the transport? So, if it's TCP you're using, then you can put transport. You 00:22:38.900 --> 00:22:44.420 can put TCP. You can put UDP and so on and so forth. So, whatever other options you want to add. 00:22:45.540 --> 00:22:51.300 In this case, I don't have VRF Encore specified. So, let's just create a VRF ENC Core. 00:22:56.980 --> 00:23:02.580 I'll just use the IP VRF in this case. Right now, we're going to go ahead and retype in that command. 00:23:04.260 --> 00:23:10.180 All right. Do show logging. All right. It's getting messy here because I just keep adding 00:23:10.180 --> 00:23:16.500 command after command after command, folks, right? I didn't take my command. It's not happy 00:23:16.980 --> 00:23:21.380 with the command, is it? Nope. There it is. 00:23:25.780 --> 00:23:30.260 All right. So, that one's been added to Encore VRF, but the source interface is not part of 00:23:30.260 --> 00:23:35.620 that VRF. So, it's becoming a mess here because we got to add that interface to the VRF and so 00:23:35.620 --> 00:23:40.340 on and so forth. So, we'd have to take, for example, interface loopback 192, 00:23:40.980 --> 00:23:51.700 IP VRF forwarding, Encore VRF, and then I got to put IP address. It's going to mess 00:23:51.700 --> 00:24:01.620 everything up now. .255.1, 255, 255, 255, 255. All right. So, let's see if that worked for us. 00:24:11.300 --> 00:24:13.620 I got way too many commands now. 00:24:24.980 --> 00:24:27.620 So, let's take out 00:24:40.340 --> 00:24:49.620 .255.1. Okay. So, it destroyed it all. Let's paste that one back in. 00:24:58.420 --> 00:25:08.660 Okay. So, logging, use its source interface, loopback, 192, VRF, 00:25:10.500 --> 00:25:19.860 Encore VRF. There we go. Beautiful now. There we go. That's what we wanted. 00:25:20.420 --> 00:25:26.100 So, you can see we're logging to 10.0.3.8 in the Encore VRF using TCP port 601 in this case, 00:25:26.100 --> 00:25:28.660 and you can change the TCP port number when you're setting up that command. 00:25:29.300 --> 00:25:35.860 Then there's our loopback 192 that's part of Encore VRF. So, just some examples of configurations, 00:25:35.860 --> 00:25:41.620 folks, that you might need to remember or recall in your future if they ever come up. 00:25:41.620 --> 00:25:45.860 All right. Now, one final thing I want to take a peek at, and that is 00:25:50.100 --> 00:25:57.940 discrimination. Don't take that the wrong way. All right. So, with logging, we can discriminate, 00:25:57.940 --> 00:26:04.500 and what does that mean? It means that we have the opportunity to control what is actually shown 00:26:04.500 --> 00:26:12.820 to us. So, by default, if we did this, we typed in show or debug. I want to type in debug IP OSPF 00:26:15.140 --> 00:26:22.100 hello. All right. So, debug IP OSPF hello. This is going to show me everything in regards to 00:26:22.100 --> 00:26:29.140 debugging. So, for IP OSPF on this device for hellos. So, notice that we've got gig 00, gig 01. 00:26:29.140 --> 00:26:34.260 We've got send hello messages, receive hello messages. We've got NV0 messages, right? So, 00:26:34.260 --> 00:26:39.940 there's all these different options. What if I wanted to set up a filter, a discriminator, 00:26:39.940 --> 00:26:47.140 it's called? So, that way there, it only shows me specific output. So, this is a great feature 00:26:47.700 --> 00:26:53.620 for controlling which syslog messages are returned to you. So, instead of getting all of this, 00:26:53.620 --> 00:26:58.340 I just want certain things with certain buzzwords, certain keywords as an example. 00:26:59.140 --> 00:27:05.300 So, let's shut this off. And what I'm going to type now is in global configuration mode, 00:27:05.300 --> 00:27:15.940 we're going to type in logging discriminator. And then it says, what do you want us to 00:27:17.220 --> 00:27:20.660 match? Oh, no, the name. Sorry. This is the name of the discriminator first. Let's just call this 00:27:20.660 --> 00:27:25.300 one send hello. Because that's what we're going to match. I only want these ones. That's what I 00:27:25.300 --> 00:27:31.060 want. Send hello. So, logging discriminator, I'm going to call it send hello. And then these 00:27:31.060 --> 00:27:35.460 are the options I have. I could discriminate based on a facility. I could discriminate 00:27:35.460 --> 00:27:44.340 based on mnemonic. So, for example, there's the facility. There's the mnemonic that we have. 00:27:47.140 --> 00:27:51.380 Right? We could do the message body. We could do the severity level. 00:27:51.380 --> 00:27:57.060 So, I'm going to go with the message body today. So, message body. So, in my message body now, 00:27:57.060 --> 00:28:04.100 I only want the ones that are send hellos. Send hellos. So, I also need the word here includes. 00:28:04.100 --> 00:28:13.540 So, includes send hello. All right. Now, what we do is we type in logging 00:28:14.500 --> 00:28:32.340 console discriminator. Yes. Discriminator. Discriminate. What am I missing here? 00:28:33.300 --> 00:28:42.740 Am I spelling discriminator wrong? I think I was. Yes. I put D-E-S. Oh, my gosh. Silly me. D-I-S, 00:28:42.740 --> 00:28:48.340 discriminator. And then what was the name of that discriminator we created? We created the 00:28:48.340 --> 00:28:54.100 send hello discriminator. That's what we did. All right. So, now that I've done that, 00:28:54.900 --> 00:29:00.180 let's go ahead and create a new one. So, I'm going to go ahead and create a new one. 00:29:00.180 --> 00:29:09.220 So, now that I've done that, let's go ahead and type in debug IP OSPF hellos. And let's see if 00:29:09.220 --> 00:29:17.620 they show me all those hellos or just the ones that have send hello in them. There's an example 00:29:17.620 --> 00:29:22.580 of setting up a discriminator. So, like we said, we could discriminate based on the message body, 00:29:22.580 --> 00:29:29.620 the facility, the mnemonic, the severity level. And this was an example of using what? Using 00:29:29.620 --> 00:29:43.940 the message body information. So, the command was logging discriminator to create the 00:29:43.940 --> 00:29:47.940 discriminator. And then we attached the discriminator to the logging console command. 00:29:47.940 --> 00:29:54.180 So, you can also do this with a buffer, with the VTY lines, even to your what? Your syslog server. 00:29:54.180 --> 00:29:58.660 So, if you need to discriminate and only send certain messages to the syslog server, 00:29:58.660 --> 00:30:07.460 then you can do that as well. All right. So, that, folks, is our coverage of syslog to get 00:30:07.460 --> 00:30:11.540 you ready for the – oh, no. One final thing. One final thing. Oh, my goodness. 00:30:15.460 --> 00:30:20.500 So, I've shown you how you can use TCP for syslog, but you can also use certificates 00:30:21.220 --> 00:30:29.460 with syslog to secure your communication. You can. So, in that case, you'd be using TLS. 00:30:30.420 --> 00:30:35.620 So, we use TLS to secure communication between our client and our service, so our Cisco device 00:30:35.620 --> 00:30:39.220 and our syslog server. So, the syslog server would have to support this as well. All right. 00:30:39.220 --> 00:30:44.100 So, we're going to use SSL TLS certificates to accomplish this, number one. And the default 00:30:44.100 --> 00:30:52.020 port is TCP port 6514. So, here's an example of setting up your device. Logging host 10.0.3.8. 00:30:52.660 --> 00:30:56.820 Your VRF, if you've got your VRF. So, whatever. Let's say we're using a management VRF. 00:30:57.940 --> 00:31:03.780 And then transport TCP port 6514. Now, you would have to have the certificates installed on the 00:31:03.780 --> 00:31:10.660 device as well, but this is what you would use for the actual syslog command in order to support 00:31:11.380 --> 00:31:21.700 using TCP port 6514 for secure syslog communication. All right. And now, that is 00:31:21.700 --> 00:31:27.620 our coverage, the end of our coverage for syslog, folks. So, go back and review that. Make sure you 00:31:27.620 --> 00:31:32.500 know your severity levels for the exam, as we talked about. Make sure you can read that output 00:31:32.500 --> 00:31:36.980 of show logging and just understand what's going on. Because if you've got a simple question like, 00:31:36.980 --> 00:31:43.940 what is the severity levels that are supported right now on the VTY lines? So, in the output of 00:31:43.940 --> 00:31:49.140 show logging, you look at the monitor, and if it said warnings, well, it's not just warnings. 00:31:49.140 --> 00:31:53.940 Remember, it's warnings and everything lower. So, it could be as simple as that. Or what port 00:31:53.940 --> 00:31:59.300 number is currently being used to communicate with the syslog server or the IP address of the 00:31:59.300 --> 00:32:03.300 syslog server? So, being able to just find that information, there might be something you have to 00:32:03.300 --> 00:32:07.860 do. Or the question could be as simple as, what is the severity level, the number associated with 00:32:07.860 --> 00:32:13.220 emergency or alert? So, just by memorizing that chart, you'd have the answer to those. 00:32:14.580 --> 00:32:16.900 All right. So, syslog. 00:32:18.660 --> 00:32:22.740 Seems like not something you'd have to review for the exam, but I encourage you to do it.