Okay, now in this video we’ll discuss some of the multiple methods used by the administrator to monitor network activity. Because as an administrator, it’s important for you to monitor the network activity and ensure that the network is up and running. So if any device fails, you probably need to get some alerts and reports, and based on that, we can troubleshoot. So probably in this section we’ll talk about some of the multiple options that we’ll be using to do all these jobs and combinedly. We call them “telemetry methods” or “Cisco traffic telemetry methods.” It’s a word derived from the Greek roots where tele stands for remote and measure is nothing but monitoring or calculating. So it’s very important for the network administrator to detect what kind of traffic is actually moving into a network. If you find any unusual network traffic, like malicious traffic going on the network, you can monitor that and take appropriate action to prevent some kinds of attacks.
And also, if any kind of device fails, you need to get some alerts or you need to have some information about the device that fails, and you can actually fix it if you get the information that the device is powered up. So there are multiple methods we’ll be using here, like something called NTP. So NTP stands for network time protocol. It is primarily used for all networking devices to have a common synchronous time because, at certain times, accurate and synchronised time across all devices is required.
As a result, we’ll enable NTP, a common method of time synchronization between networking devices.And apart from that, we’ll be using something called SNMP or SNMP CAPs. Now probably the SNMP feature allows you to monitor the secretization of the device, the memory usage of the device, or maybe the interface bandwidth—multiple things. And these statistics can be filtered by the SNMP server, and based on that information, you can actually monitor the device status, the connectivity, and many other things. And also, we’ll be enabling something called logging.
So logging is a feature that allows us to keep track of the events and changes that occur in the network. We can specifically log, and we can tell the device to send some log messages if any of the traffic matching or incidents happen, just like the interface goes down or the EHRP neighbourhood goes down or something like that. So apart from that, we can also use some other features, like Netflix. Netflix is a method used to calculate network traffic statistics, and we can export selected traffic and export it to some traffic collector software, and based on that, it’s going to give some statistics in a graphical way. So all these options together refer to “traffic telemetry methods,” and using these methods we can ensure that the network operates and is always available.
2. Device- Network Events Logging
So network devices by default generate log messages, and these log messages can be used to keep track of the events or changes occurring in your network. For example, if I got the command line whenever you made any changes right now, I’d be in my device’s console screen. So this is my console screen, let’s say, and I’m this console screen. So whenever you make any changes, let’s say I’m trying to shut down one of the interfaces; by default, it is in upstate.
So whenever you shut down the interface immediately, you will see some messages appear here. This is an indication that this particular port has been shut down during this date and time. And whenever I bring the interface back up, it comes back again, and you see some messages here, so that you will see different types of messages in general on the console screen by default. Now these messages are typically referred to as “log messages,” and these log messages are automatically generated. By using these messages, we can keep track of the events occurring in your network. like some of the log messages that help us in general, such as device failure notifications For example, suppose you have a router and one of the interfaces fails or goes down, resulting in a log message; or suppose you’re connecting to a router and establishing an EHRP neighborship, and the neighborship fails, resulting in a log message. Or perhaps you’re connecting to a service portal network and have some BGP connections, and the neighbor ship fails. It generates a log message. In general. Or you can also use specific log messages.
For example, I can go to the router and configure the ACL to match a specific traffic pattern, and I can tell the router to generate log messages if any traffic matches that particular pattern, which can be used for auditing or even troubleshooting. Also, it is useful because, let’s say you have some issue with the router, maybe the neighbourhood goes down and maybe the neighbourhood is flapping or the VPN is not coming up, something is not working according to a requirement, and you just want to see what is happening in the back end. So we can enable the logging for the debug messages and then we can see the back end messages what is going on in the back end. So there’s also another reason for generating the log messages and keeping track of them, and of course we can also use it for foreign analysis, like for some kind of incident investigation. So let’s say something occurred in your network, maybe some kind of attack, and you want to see some of these previous log messages that are generated on this particular device where we can trace the victim and attacker to the point at which it actually occurred. So we do enable some logging messages. Of course, the device generates some log messages to some extent, and we need to keep track of those messages for multiple reasons. Now, we have different options for logic, like a console logging option (VDY), a local buffer, and an external log service.
Essentially, console logging occurs whenever you login to any device, such as Router One, using a console cable. Of course, I’m using Gen 3 to connect. But by default, when you open up the console, it’s almost like a console connection here. As an example, you could connect your router to a physical console port and access the router through the console port. And by default, logging is enabled on this particular port. And whatever changes occur in your network will be displayed by default on the console port. But by default, these messages are not saved in general. So, by default, console logging is enabled in all of your router switches, and log messages are sent to the console port, as previously discussed. And hence, only the users who are physically connected to the router console port can view these messages. So if I’m not using the console, I cannot see these messages. As a result, the console is currently accessible via router one. Now, by default, these messages are not saved. For example, even if you try to enable some kind of debug messages in the back end, you will see some kind of debug messages in which hello messages are sent every 5 seconds. So those messages will also be shown if you enable debugging messages by using debug EHRP packets. It is now recommended to disable console logging in production networks because a large amount of logging messages or outputs are actually sent to the console while using the debug process. As a result, the large number of log messages sent to the console while debugging will increase the unnecessary CPU load on the routers and may have an impact on the control plane. Also, because it can prevent routers from forwarding packets or establishing the control plane.
Or maybe it leads to some kind of neighborhood. Issues may arise if the router receives too many log messages. So that’s the reason it’s recommended to disable console logging because, mostly in production networks, consoles are something we don’t use much because most of the time we access the device via telnet or SSH via a remote device. And we only use console if there are any major issues, such as password reverting or being unable to log into the VTOne line, in which case you may need to troubleshoot connectivity and other issues. So most of the time we don’t use the console. So it’s recommended to disable the console messages by using the no-login console. So I can simply say “no logging console,” which is by default enabled. So once I disable this console, if I try to make some changes on the network, let’s say my interface goes down, and as you can see, I don’t see any log messages displayed here. In the console, we also have the option of using something called buffer logging. In the case of buffer logging, whatever the log message is that is generated, we can tell the router to save these messages in the local buffer memory or the local RAM. So this type of logging actually uses the router’s RAM for storing those log messages temporarily. And we can specify the buffer size—the number of bytes—as well as how many bytes should be used to store the log messages. So the buffer is nothing but the fixed size that we are going to allocate to generate the log messages, and the router is going to delete the old messages once it reaches the maximum size.
And let’s say the router is receiving the log messages; anything above this memory, which we allocated automatically, will start removing the older entries. Now, buffer logging is by default not enabled.We can enable this by using a command called “log buffer.” And if you want to verify the log messages, we can use something like the “Show logging option.” So let me just quickly enable this buffer logging here. So in the previous version, I disabled the console logging. So I’ll try to re-enable console logging because at this point in time I want to see the log messages here. So we’ll say “logging buffer,” and we can define “what is the buffer size you want to allocate.” Let’s say I’m using just 4096 bytes, and if you want to verify, I can try generating some messages, like trying to shut down the interface, and then I’ll say no shut down. And also try to shut down one more interface, let’s say S one by zero, because on router one’s S one by zero interface I’m connecting to router two, and I have preconfigured EHRP here. So most likely, if I shut down the S-1 by Zero interface, I should also see the interface go down here. I think I didn’t configure the EHRP. So I don’t have EHRP configured; I don’t have it here. So you probably see the following messages: interface change, shadow down, I’ll make a backup, and then if you want to verify these log messages, we can use the “Show Log” option.
3. Syslog – Terminal Logging
The next logging option is something like Syslog Server Logging. Now in this option, we are going to tell the router to send those log messages to the external server or the external computer or PC, which is going to run some application called Syslog Server Applications. So, of course, the log messages will be generated by the router. So whatever the case, the log messages will be exported to some external device. We’re going to run some kind of external software now. It’s going to show you all the long messages—where they are generated, date, and time. Of course, if you’re using some licence programs, you will have more options to log in again. So by default, this logging is not enabled. We need to enable this syslogging by using a command called Logging Host.
We need to go to Logging Host, and then we need to tell the IP address of that particular device. So you can also do the same thing on the router, but make sure that from the router, you have reachability to this particular device that is routing reachability. Of course, in the production networks, we do have routing configured to provide reachability between different networks. So I’ll show you this option here. In this setup, I’m using my physical computer, which is using some software called Dftbd.
It’s a free-source tool that I have downloaded from the Internet. So here we need to select the appropriate interface. The first step is to select the syslog server because I want to use the syslog server application here and connect to the correct interface, which is your GM history. So, in my case, I’m connecting this VM net-4 interface, which has the IP address 10 110. So once you select the correct interface here, I can go to my router and configure it to generate the log messages. So I’m going to say simply “logging host,” and I want all the log messages to be sent to the PC. So you can see that some messages are appearing right away. Whatever the message you see here—the same console message—it shows up here. And let’s say I’m going to make some changes here. So, let’s say I’m attempting to shut down this interface, and I should see the interface change straight to down, and then I’ll make the interface change back to up, and you can see automatically whatever the log message is generated here, the same message you normally see here in the production network.
You can use some kind of licence tool. With the licence tools, you will have more options to filter the log messages because in the production network, you have hundreds of devices, and maybe some of those devices send the log messages to a single server, so you can filter those messages and see those log messages when they occur. And also, you can filter based on the date and time to see the actual events happening on the network. So based on these messages, you can at least come to know that this interface has been changed by some administrator. So Syslog is commonly used in production network scenarios because you generally want all the log messages to be sent to the external server, where you have enough memory to save all those log messages. Now, the last option of the log messages is like terminal logging. Terminal logging is the equivalent of console logging. The only difference is that console logging is enabled by default, whereas terminal logging includes everything done from the VDP line. So let me give an example here. So I’m going to use Puti to initiate a tenant connection to the router. One from the PC, I’m going to open connection 100, one with Etlant on port number 23, and the password, I think the password is fine. So now I can see this is my VDP line and thescreen here, whatever you see here, this is my console output.
Now, so the above screen is like my console, the one that I’m using here, and this is my VDP line. So most of the production networks use VDP lines to log in. Let’s say I’m going to make some changes to the interface. Let’s say I’m trying to shut down. Of course, you can configure some EHRP and verify the neighborship and other things. And whenever I make any changes, you can see it generates a log message. Of course, this log message is shown on the console screen. You can also see it on the syslog server if you have enabled the syslogs, but you don’t see them on the PDMI because by default the logging is disabled here. So, in most production networks, we access the device remotely, and you always want them to see any changes you make. For example, if you are attempting to configure some EHRP, you would expect the neighbourhood to appear, or if you are making any changes to the interfaces or anything, you would generally prefer to see these messages, some basic informational messages. Now, for that, we need to enable the terminal monitor command. So once I give the terminal monitor command, if I make any changes—let’s say I’m going to set up the interface—I can see the messages are displayed exactly the same way as you see them on the console screen. So, in most production networks, it’s best to disable console logging with a no login console command because you don’t do much on the console because we mostly use the VTP line. And we can enable this logging, the default logging, which is disabled, by using the terminal vander command.
4. Network Time Protocol
So NTP stands for network time protocol. It’s a protocol that allows you to have a common, synchronised time between the networking devices. Because when you’re implementing a network, all the devices must have a common synchronous time. because there are some other services that are dependent on having a common time. For example, you must have an accurate crossing in order to log with an accurate time stance. In the previous sessions, we configured something like the Syslog service, and all the devices send log messages, whatever the log message is generated. As a result, these log messages can most likely be used to keep track of what is going on. It now displays the specifics of what event occurred and when it occurred from which device. Now if you don’t have a proper synchronised time, the problem is that you may not be able to see the correct details because you don’t have a proper synchronised time. So it will be difficult for the administrator to figure out those log messages and the events. Apart from that, you might be using something like ACLs. You might want to deny a specific type of traffic, say ATP traffic, from 9:00 a.m. to 5:00 p.m.
So, when traffic is passing through the router, you must ensure that this device has a common or proper time, and that time must also match the time of the other devices, because if your server or the user sending the traffic has a different time and the router has a different time. In that case, there is an ACO. may not work if you don’t have a proper time. Synchronization. Of course, if you’re using some kind of advanced-security VPN, like we use some kind of digital certificate validation, maybe for my web browsers or maybe for VPNs, if you don’t have a properly synchronised time, your digital certificates may not be validated. Other mechanisms, such as single sign-on mechanisms, which are a type of authentication used for multiple applications, require a common synchronous time to function properly. To maintain proper synchronization, an NTP network typically obtains its time from the source. will configure a device with an NDP server, and we expect all the devices to contact the NTP server. And whatever the time is on this particular device, we can tell the device to synchronise the time between these devices. So we can either use our own internal server, where they can select any router, any server, any PC, or any device as an NTP server, and synchronise the time from all the devices you can also contact. Or you can also configure some additional time sources on the internet as well.
So the NTP server usually gets the time from the authoritative time source. It’s just like a radio clock or an atomic clock attached to the time server. And then this server is responsible for distributing the time across the complete network, which we call NTP clients. Now, with NTP, there is something called a “startup value.” NTP servers can now be classified into two types. We can configure our device as a device to contact some external clocks on the internet, just as the NTP server can be a server on the internet. You can now find some external clocks on the internet, for example, if you go to Google and search for some external clocks, NTP time servers, or servers, you’ll probably find some different time servers. You can configure your device to contact this external clock service to synchronise the time. So it can be an external clock that always has a startup value of 0. That is actually the case in terms of being similar to Rap Hopkins, and we can configure my device. Let’s say I have a router here, and this is my NDP client, and this device is going to contact my external clock server and get the time synchronized, and then I can configure my internal devices. Assume I have some of the routers and PCs’ other devices, and they will make contact with this server. And for all these users, this is my NTP server, and these are my clients.
So we can still configure this device to contact the external server, but it’s practically not scalable because you don’t want each and every device to contact the external clock and synchronise the time as per the region. That’s the reason we can configure our own internal server, and we can either manually set the time on this particular server or I can configure this device to contact the external clock to synchronise the time from the external clock. So if I’m synchronising from an external clock, then this is going to be my client, this is going to be my server, and then this is going to be the server for all my internal clients. So, by default, an external clock will have a startup value of zero; that is, a time server on the internet; sorry, on all servers that should run NTP in general, it will always have the standard value of one. So we can configure a startup value of two, like this server’s external clock if it is sending a time to my server, which is my client; let’s say this is my client; if this startup value is one here, then it becomes two and it becomes a client for all the remaining devices. We’ve got some other clients who are synchronising the time from this device, and you can also configure this device to become a server for other clients, or the starting value will increment automatically. So the startup value actually tells you how many hops your actual time sources are available, and the default startup value will be one for all servers that don’t run NTV, such as internet time servers.
5. NTP Stratum Value
The next thing the NTP startup value defines is the accuracy of the time source. Even so, there is a gap between the networking device and the authority to time source. Now, in general, let’s take an example. The NTP server could be some kind of external clock, such as an internet-based external clock or an atomic clock. So I have an NDP server that provides time to some of my devices; perhaps one of them is here, which is known as an NTP client. Okay, so this device is going to contact an external clock or NTP server on the internet to get a synchronised time. And I have some multiple devices here, let’s say, so I can configure all of these devices to communicate with this NTP server on the external clock on the internet to obtain the synchronous time. Or I can configure this as an NTP server, which is probably my internal server probably. And this internal server is like a server for all the devices inside my network. Now this is my inside network, and I want all my inside devices to contact this device, this server, to get synchronised time. Now these devices are required as NTP clients. So by default, the external clock will have a startup value of either zero or one. Depends.
And let’s say the start of value is one here. Startup value defines the number of hops your actual sources are within, and once it sends the time to this device, it becomes two. And if it is a server sending a time to other devices, the startup value increments to three. So likewise, if this device is like an NTP server—maybe this is a contrasting NTP server for other devices—or maybe this is my branch office that is going to be the NTP server for my end devices, then the startup value will automatically increment to form the startup value, which defines how accurate the time is. Now let’s say this device is getting the time from some other device with the startup value of some other source, maybe the start value of two, and here they are receiving the startup value of four. It’s going to prep for this one just like Rap Hopkins.
So we generally call a startup value “accuracy,” which defines the accuracy of the time source. Less accuracy is better if you are getting the time from multiple services, and generally zero is for the atomic clock. So again, most of the network devices lack the proper hardware for an accurate time source with atomic clocks. So if you’re using some internal service, generally we start the shutdown value at two, and then when it sells to the next device, it becomes three. So, if we don’t define any shadow values by default, I believe it takes around seven seconds in iOS. So shutter value one is always for servers that do not run the NDP time servers on the internet, and shutter value two is generally. As previously stated, the server receives a time from the beginning with a value of 1. So from here, it goes through here, which is two. Then it continues, sending another client device—perhaps three. And if that is a server, for some of the devices, it becomes four like that.
6. NTP Configuration – LAB
So network devices by default generate log messages, and these log messages can be used to keep track of the events or changes occurring in your network. For example, if I go to the command line whenever you make any changes right now, I’m in my device’s console screen. So this is my console screen, let’s say, and I’m this console screen. So whenever you make any changes, let’s say I’m trying to shut down one of the interfaces; by default, it is in upstate. So whenever you shut down the interface immediately, you will see some messages appear here. This is an indication that this particular port has been shut down during this date and time.
And whenever I bring the interface back up, it comes back again, and you see some messages here, so that you will see different types of messages in general on the console screen by default. Now these messages are typically referred to as “log messages,” and these log messages are automatically generated. By using these messages, we can keep track of the events occurring in your network. like some of the log messages that help us in general, such as device failure notifications. For example, suppose you have a router and one of the interfaces fails or goes down, resulting in a log message; or suppose you’re connecting to a router and establishing an EHRP neighborship, and the neighborship fails, resulting in a log message. Or perhaps you’re connecting to a service portal network and have some BGP connections, and the neighborship fails. It generates a log message. In general.
Or you can also use specific log messages. For example, I can go to the router and configure the ACL to match a specific traffic pattern, and I can tell the router to generate log messages if any traffic matches that particular pattern, which can be used for auditing or even troubleshooting. Also, it is useful because, let’s say you have some issue with the router, maybe the neighbourhood goes down and maybe the neighbourhood is flapping or the VPN is not coming up, something is not working according to a requirement, and you just want to see what is happening in the back end. So we can enable the logging for the debug messages, and then we can see the back-end messages and what is going on in the back end. So there’s also another reason for generating the log messages and keeping track of them, and of course we can also use it for foreign analysis, like for some kind of incident investigation. So let’s say something occurred in your network, maybe some kind of attack, and you want to see some of these previous log messages that are generated on this particular device where we can trace the victim and attacker to the point at which it actually occurred. So we do enable some logging messages. Of course, the device generates some log messages to some extent, and we need to keep track of those messages for multiple reasons.
Now, we have different options for logic, like a console logging option (VDY), a local buffer, and an external log service. Essentially, console logging occurs whenever you login to any device, such as Router One, using a console cable.Of course, I’m using Gen 3 to connect. But by default, when you open up the console, it’s almost like a console connection here. As an example, you could connect your router to a physical console port and access the router through the console port. And by default, logging is enabled on this particular port. And whatever changes occur in your network will be displayed by default on the console port. But by default, these messages are not saved in general. So, by default, console logging is enabled in all of your router switches, and log messages are sent to the console port, as previously discussed.
And hence, only the users who are physically connected to the router console port can view these messages. So if I’m not using the console, I cannot see these messages. As a result, the console is currently accessible via router one. Now, by default, these messages are not saved. For example, even if you try to enable some kind of debug messages in the back end, you will see some kind of debug messages in which hello messages are sent every 5 seconds. So those messages will also be shown if you enable debugging messages by using debug EHRP packets. It is now recommended to disable console logging in production networks because a large amount of logging messages or outputs are actually sent to the console while using the debug process. As a result, the large number of log messages sent to the console while debugging will increase the unnecessary CPU load on the routers and may have an impact on the control plane. Also, because it can prevent routers from forwarding packets or establishing the control plane. Or maybe it leads to some kind of neighborhood. Issues may arise if the router receives too many log messages. So that’s the reason it’s recommended to disable console logging because, mostly in production networks, consoles are something we don’t use much because most of the time we access the device via telnet or SSH via a remote device. And we only use console if there are any major issues, such as password reverting or being unable to log into the VTOne line, in which case you may need to troubleshoot connectivity and other issues. So most of the time we don’t use the console. So it’s recommended to disable the console messages by using the no-login console.
So I can simply say “no logging console,” which is by default enabled. So once I disable this console, if I try to make some changes on the network, let’s say my interface goes down, and as you can see, I don’t see any log messages displayed here. The other option for the console is to use something known as buffer logging. In the case of buffer logging, whatever the log message is that is generated, we can tell the router to save these messages in the local buffer memory or the local RAM. So this type of logging actually uses the router’s RAM for storing those log messages temporarily. And we can specify the buffer size—the number of bytes—as well as how many bytes should be used to store the log messages. So the buffer is nothing but the fixed size that we are going to allocate to generate the log messages, and the router is going to delete the old messages once it reaches the maximum size. And let’s say the router is receiving the log messages; anything above this memory, which we allocated automatically, will start removing the older entries. Now, buffer logging is by default not enabled.
We can enable this by using a command called “log buffer.” And if you want to verify the log messages, we can use something like the “Show logging option.” So let me just quickly enable this buffer logging here. So in the previous version, I disabled the console logging. So I’ll try to re-enable console logging because at this point in time I want to see the log messages here. So we’ll say “logging buffer,” and we can define “what is the buffer size you want to allocate.” Let’s say I’m using just 4096 bytes, and if you want to verify, I can try generating some messages, like trying to shut down the interface, and then I’ll say no shut down. And also try to shut down one more interface, let’s say S one by zero, because on router one’s S one by zero interface I’m connecting to router two, and I have preconfigured EHRP here. So most likely, if I shut down the S-1 by Zero interface, I should also see the interface go down here. I think I didn’t configure the EHRP. So I don’t have EHRP configured; I don’t have it here. So you probably see the following messages: interface change, shadow down, I’ll make a backup, and then if you want to verify these log messages, we can use the “Show Log” option.
