Posts from ‘System Management’
EEM – Revenge of the applets
In the earlier article titled EEM demystified, we took an introductory look at the basic format for EEM applets, and some basic samples for general operation, including some basic CLI command usage, getting input, and displaying output.
In this article, we are going to take a look at some of the additional actions available, specifically looking at variables, a few operators, and some general conditional structures.
Continue Reading
Tags: ccie, CCIE R&S, CCIE Security, network management
A discussion / introduction to EEM, and basic configurations.
Why EEM?
Embedded Event Manager (EEM) allows you to have event tracking and management functionality directly on the Cisco IOS device, rather than on an external device. By having the configuration locally, actions can still be taken, even if the connection to an external monitoring station is unavailable. Plus, it is a great topic that can be used to challenge (or torment) CCIE candidates.
Tags: ccie, CCIE R&S, CCIE Security, eem, System Management
Even more updates have been posted to the IP Services section of the CCIE Routing & Switching Lab Workbook Volume 1 Version 5.0. Yes, that’s right, two in two days 
The following topics are now available in System Management:
12.1 Exec Aliases
12.2 System Message Logging
12.3 Syslog Logging
12.4 Logging Counting and Timestamps
12.5 Logging to Flash Memory
12.6 Configuration Change Notification and Logging
12.7 Configuration Archive & Rollback
12.8 Logging with Access-Lists
12.9 TCP Keepalives
12.10 Generating Exception Core Dumps
12.11 Conditional Debugging
12.12 Telnet Service Options
12.13 Tuning Packet Buffers
12.14 Terminal Line Settings
12.15 SNMPv2c Server
12.16 SNMPv2c Access Control
12.17 SNMP Traps and Informs
12.18 CPU and Memory Thresholds
12.19 SNMPv3
12.20 SNMP MAC Address Notifications
12.21 SNMP Notifications of Syslog Messages
12.22 CDP
12.23 RMON Alarms
12.24 RMON Statistics Collection
12.25 HTTP Server and Client
12.26 FTP Server and Client
12.27 TFTP Server and Client
12.28 Remote Shell
12.29 NTP
12.30 NTP Authentication
12.31 NTP Access Control
12.32 Auto-Install over LAN Interfaces using DHCP
12.33 Auto-Install over Frame-Relay
12.34 Auto-Install over LAN Interfaces using RARP
12.35 IOS Menus
12.36 IOS Banners
12.37 KRON Command Schedule
Some minor changes were made today to the IP Services labs that were posted yesterday. So if you have the version from yesterday you should re-download the current version again.
The following topics are now 100% available:
1. Bridging & Switching
2. Frame Relay
3. IP Routing
4. RIP
5. EIGRP
12. System Management
13. IP Services
QoS will start getting posted this week as well incrementally. As always product access is available through the http://members.internetworkexpert.com site, and technical discussion should be held on www.IEOC.com.
Please keep your feedback coming in and let me know if there are any bugs with the material. Also if anyone has problems with the initial config files let me know, there were some corrupt files apparently when they were changed from DOS to UNIX formatting.
Happy Labbing!
NTP security goal is to prevent unauthorized time sources to affect time synchronization within a set of network devices. Cisco IOS offers two methods of securing NTP infrastructure:
1) NTP Access Control. Limit types of NTP access and NTP sources associating with out router.
2) NTP Authentication. Validate the identity of NTP sources.
Let’s see how access control works. It is convenient to classify NTP messages in two types:
1) Control messages. Documented in RFC 1305 Appendix B, serve the purpose, usually fulfilled by SNMP. Without digging into any details, let’s just say the control messages are for reading and writing internal NTP variables and obtaining NTP status information. Not to deal with time synchronization itself.
2) NTP request/update messages. Those are used for actual time synchronization. Request packet obviouly asks for synchronization information, and update packet contains synchronization information, and may change local clock.
IOS router defines the following four types of access for NTP:
1) Peer – permits router to respond to NTP requests and accept NTP updates. NTP control queries are also accepted. This is the only class which allows a router to be synchronized by other devices.
2) Serve – permits router to reply to NTP requests, but rejects NTP updates (e.g. replies from a server or update packets from a peer). Control queries are also permitted.
3) Serve-only – permits router to respond to NTP requests only. Rejects attempt to synchronize local system time, and does not access control queries.
4) Query-only – only accepts NTP control queries. No response to NTP requests are sent, and no local system time synchronization with remote system is permitted.
IOS router may associate an access-list with any of the above access-types, classifying NTP message sources by their types. Two rules are observed by IOS when an incoming NTP packet is matched against configured types of access:
1) All access-groups associated with access types are scanned in the ordrer presented above (from 1 to 4) – that is, following from most permissive to most restrictive. The first match is used to determine the message source access type.
2) If any of the access types has been defined with an ACL, all other access types are implicitly denied. Just by restricting some sources, you may effectively block all others as well
Now here is a catch. If your router is configured as NTP master, and you set up any access-control group, you must allow “peer” access type to a source with IP address “127.127.7.1”. This is because “127.127.7.1” is the internal server created by ntp master command, which the local router synchronizes to. If you forget to enable it peer access, your server will always be out of sync. Here are some examples. First one: configure R1 as NTP master and allow the server to be polled for NTP updates just by one client. Client should receive updates just from one source:
R1: access-list 1 permit 127.127.7.1 access-list 2 permit 150.1.2.2 ntp master ntp access-group peer 1 ntp access-group serve-only 2 R2: access-list 1 permit 150.1.1.1 ntp source Loopback0 ntp access-group peer 1 ntp server 150.1.1.1
A more complicated example. R1 and R3 are both NTP masters, peering via NTP. R2 is a client to both of them. Configure so that R1 and R3 only allow R2 to poll themselves for time updates, and allow synchronizing each other. Correspondingly, R2 should only accept NTP updates from R1 or R3.
R1: access-list 2 permit 150.1.2.2 access-list 3 permit 150.1.3.3 access-list 3 permit 127.127.7.1 ntp master ntp access-group serve-only 2 ntp access-group peer 3 ! ! The following is needed to poll our peer from ! a consistent source IP address ! ntp source Loopback0 ntp peer 150.1.3.3 R3: access-list 2 permit 150.1.2.2 access-list 1 permit 150.1.1.1 access-list 1 permit 127.127.7.1 ntp master ntp access-group serve-only 2 ntp access-group peer 1 ntp source Loopback0 ntp peer 150.1.1.1 R2: access-list 13 permit 150.1.1.1 access-list 13 permit 150.1.3.3 ntp source Loopback0 ntp access-group peer 13 ntp server 150.1.1.1 ntp server 150.1.3.3
Some show commands output for the last example:
Rack1R1#show ntp associations detail 150.1.3.3 configured, selected, sane, valid, stratum 8 ref ID 127.127.7.1, time D2AA2222.362546B9 (00:06:58.211 UTC Sun Jan 1 2012) our mode active, peer mode active, our poll intvl 64, peer poll intvl 64 root delay 0.00 msec, root disp 0.05, reach 377, sync dist 12.466 delay 24.70 msec, offset 0.0294 msec, dispersion 0.05 precision 2**18, version 3 org time D2AA2222.363128BC (00:06:58.211 UTC Sun Jan 1 2012) rcv time D2AA2222.395A8A9D (00:06:58.224 UTC Sun Jan 1 2012) xmt time D2AA221C.BA22B989 (00:06:52.727 UTC Sun Jan 1 2012) filtdelay = 24.77 24.70 24.69 24.69 24.81 24.78 25.16 24.60 filtoffset = 0.01 0.03 0.01 0.01 0.07 0.02 0.30 0.04 filterror = 0.02 0.03 0.05 0.06 0.08 0.09 0.11 0.12 127.127.7.1 configured, our_master, sane, valid, stratum 7 ref ID 127.127.7.1, time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012) our mode active, peer mode passive, our poll intvl 64, peer poll intvl 64 root delay 0.00 msec, root disp 0.00, reach 17, sync dist 0.015 delay 0.00 msec, offset 0.0000 msec, dispersion 0.02 precision 2**18, version 3 org time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012) rcv time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012) xmt time D2AA224F.BA09890A (00:07:43.726 UTC Sun Jan 1 2012) filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 filterror = 0.02 0.99 1.97 2.94 15995.3 15995.3 15995.3 15995.3 Reference clock status: Running normally Timecode: Rack1R3#show ntp associations detail 150.1.1.1 configured, selected, sane, valid, stratum 8 ref ID 127.127.7.1, time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012) our mode active, peer mode active, our poll intvl 64, peer poll intvl 64 root delay 0.00 msec, root disp 0.03, reach 376, sync dist 13.474 delay 24.70 msec, offset 0.0428 msec, dispersion 0.84 precision 2**16, version 3 org time D2AA2252.BA44EC9D (00:07:46.727 UTC Sun Jan 1 2012) rcv time D2AA2252.BD81F301 (00:07:46.740 UTC Sun Jan 1 2012) xmt time D2AA2262.362614E6 (00:08:02.211 UTC Sun Jan 1 2012) filtdelay = 24.99 24.70 24.69 25.02 24.70 24.67 24.67 24.66 filtoffset = -0.15 0.04 -0.06 0.16 -0.04 -0.04 0.03 -0.02 filterror = 0.75 0.76 0.78 0.79 0.81 0.82 0.84 0.85 127.127.7.1 configured, our_master, sane, valid, stratum 7 ref ID 127.127.7.1, time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 1 2012) our mode active, peer mode passive, our poll intvl 64, peer poll intvl 64 root delay 0.00 msec, root disp 0.00, reach 377, sync dist 0.015 delay 0.00 msec, offset 0.0000 msec, dispersion 0.02 precision 2**18, version 3 org time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 1 2012) rcv time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 1 2012) xmt time D2AA2263.36244305 (00:08:03.211 UTC Sun Jan 1 2012) filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 filterror = 0.02 0.99 1.01 1.02 1.04 1.05 1.07 1.08 Reference clock status: Running normally Timecode: Rack1R2#show ntp associations detail 150.1.1.1 configured, our_master, sane, valid, stratum 8 ref ID 127.127.7.1, time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012) our mode client, peer mode server, our poll intvl 64, peer poll intvl 64 root delay 0.00 msec, root disp 0.03, reach 17, sync dist 2924.316 delay 92.15 msec, offset -814906.4035 msec, dispersion 2877.85 precision 2**16, version 3 org time D2AA225B.921F769B (00:07:55.570 UTC Sun Jan 1 2012) rcv time D2AA258A.85F5230D (00:21:30.523 UTC Sun Jan 1 2012) xmt time D2AA258A.6E599935 (00:21:30.431 UTC Sun Jan 1 2012) filtdelay = 92.15 90.97 90.84 136.81 0.00 0.00 0.00 91.34 filtoffset = -814906 -814908 -814909 -814886 0.00 0.00 0.00 2.22 filterror = 0.02 0.99 1.97 2.94 16000.0 16000.0 16000.0 7.83 150.1.3.3 configured, selected, sane, valid, stratum 8 ref ID 127.127.7.1, time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 1 2012) our mode client, peer mode server, our poll intvl 64, peer poll intvl 64 root delay 0.00 msec, root disp 0.05, reach 377, sync dist 13.916 delay 24.57 msec, offset -814905.7885 msec, dispersion 1.59 precision 2**18, version 3 org time D2AA2273.89780E2F (00:08:19.536 UTC Sun Jan 1 2012) rcv time D2AA25A2.747F40E8 (00:21:54.455 UTC Sun Jan 1 2012) xmt time D2AA25A2.6E3030A3 (00:21:54.430 UTC Sun Jan 1 2012) filtdelay = 24.57 24.73 24.70 24.84 24.64 24.75 24.55 24.67 filtoffset = -814905 -814907 -814907 -814907 -814907 -814907 -814907 -814907 filterror = 0.02 0.99 1.01 1.02 1.04 1.05 1.07 1.08
Tags: access-control, ntp
The tutorial presented below is a small excerpt from the “System Management” section of beta IEWB-RS Vol I version 5.
SNMPv3 protocol a security model, defining new concepts to replace the old community-based pseudo-authentication and provide communication privacy by means of encryption. The new concepts are: user, group and security level. A group defines the access policy for a set of users. An access policy defines which SNMP objects can be accessed for reading and writing or which SNMP objects can generate notifications to the members of a group. Policy is defined by associating the respective read, write or notify view with a group. By using a notify view, a group determines the list of notifications its users can receive. A group also defines the security model and security level for its users.
Essentially, all groups form a table, which maps users to their read/write/notify views and security models. Note that if a group is defined without a read view than all objects are available to read. Contrary to that, if no write or notify view is defined, no write access is granted and no objects can send notifications to members of the group. The notify view is usually not configured manually. Rather, it’s added by the snmp-server host command automatically, when a users in a group is bound to a notification target host. Note that SNMP will use the username configured with snmp-server host along with the security model specified to authenticate and possibly encrypt the notifications. If the security model is set to «noauth» then a plain username is sent in a manner resembling the old community string.
The following security models exist: SNMPv1, SNMPv2, SNMPv3. The following security levels exits: “noAuthNoPriv” (no authentiation and no encryption – noauth keyword in CLI), “AuthNoPriv” (messages are authenticated but not encrypted – auth keyword in CLI), “AuthPriv” (messages are authenticated and encrypted – priv keyword in CLI). SNMPv1 and SNMPv2 models only support the “noAuthNoPriv” model since they use plain community string to match the incoming packets. The SNMPv3 implementations could be configured to use either of the models on per-group basis (in case if “noAuthNoPriv” is configured, username serves as a replacement for community string). All users sharing a group utilize the same security model, however, the specific model settings (password, encryption key) are sep per-user. Note that SNMPv3 does not send passwords in clear-text and uses hash-based authentication with either MD5 or SHA1 functions (HMAC authentication – the packet conted is hashed along with authentication key to produce the authentication string). For encryption, statically configured keys are used along with DES56 symmetric cipher (that mean the same key should be configured on NMS for the particular user).
Consider the example below. Three groups are created. Groups «NORMAL» and «RESTRICTED» are used to control remote users access and group «TRAP» is used to send notifications. Note that only read-view is specified for group “RESTRICTED” and it’s limited to IfEntry fields for a fixed interface index. The group «RESTRICTED» has an access-list applied to control the NMS stations the users can access from. Note that the groups have different security levels. Next, three users are created, one for each group respectively, with their authentication and encryption keys. Finally, SNMP link up and down notifications are enabled and SNMP trap destination host is configured. This operation automatically creates and assigns the «notify» view for the respective group (will appear in show commands output below).
! ! Access-List to control users in the RESTRICTED group. ! access-list 99 permit 155.1.146.0 0.0.0.255 ! ! Set ifIndexes persistent, for view definition is based on IfIndexes ! snmp-server ifindex persist ! ! The first view covers the “ISO” sub-branch and the second one covers ! all “lifEntry” fields for interface with IfIndex 3 (Serial 0/0). ! snmp-server view NORMAL iso included snmp-server view RESTRICTED ifEntry.*.3 included ! ! Define three groups. The first one allows to read and write ! into a large portion of the MIB tree. The second one allows reading ! just information specific to Serial 0/0 interface, and limits user ! access based on access-list ! ! The third group is for sending traps. A user belonging to this group ! will be utilized to send trap messages. Its name and password ! will be used to create authentication credentials in a trap message ! and the users privacy password will be used to encrypt the packet. ! Note that this group has NO notify view defined, which is done on ! on purpose. The notify view will be automatically populated when ! notification hosts are configured and bound to users ! snmp-server group NORMAL v3 priv read NORMAL write NORMAL snmp-server group RESTRICTED v3 auth read RESTRICTED access 99 snmp-server group TRAP v3 priv ! ! Users, their passwords and encryption keys are defined now ! snmp-server user NORMAL NORMAL v3 auth sha CISCO priv des56 CISCO snmp-server user RESTRICTED RESTRICTED v3 auth sha CISCO snmp-server user TRAP TRAP v3 auth sha CISCO priv des56 CISCO ! ! Allow sending traps and configure a destination host. Note that when ! a host is configured and bound to SNMPv3 username, the corresponding ! group notify view is populated based on traps allowed for this ! particular destination. This is why it’s not required to configure ! the notify view for a group. ! snmp-server enable traps snmp linkup linkdown snmp-server host 155.1.146.100 traps version 3 priv TRAP
Perform some basic verifications next using the show commands. Note that SNMPv3 users do not appear in the running configuration for security reason (different management channel) but you can see some information using show snmp users command. Also, pay attention to the automatic view assigned to the “TRAP” group.
Rack1R6#show snmp user User name: TRAP Engine ID: 80000009030000119221DA80 storage-type: nonvolatile active Authentication Protocol: SHA Privacy Protocol: DES Group-name: TRAP User name: NORMAL Engine ID: 80000009030000119221DA80 storage-type: nonvolatile active Authentication Protocol: SHA Privacy Protocol: DES Group-name: NORMAL User name: RESTRICTED Engine ID: 80000009030000119221DA80 storage-type: nonvolatile active Authentication Protocol: SHA Privacy Protocol: None Group-name: RESTRICTED Rack1R6#show snmp group groupname: ILMI security model:v1 readview : *ilmi writeview: *ilmi notifyview:row status: active groupname: ILMI security model:v2c readview : *ilmi writeview: *ilmi notifyview: row status: active groupname: TRAP security model:v3 noauth readview : writeview: notifyview: *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF0F row status: active groupname: TRAP security model:v3 priv readview : v1default writeview: notifyview: row status: active groupname: NORMAL security model:v3 priv readview : NORMAL writeview: NORMAL notifyview: row status: active groupname: RESTRICTED security model:v3 auth readview : RESTRICTED writeview: notifyview: row status: active access-list: 99 Rack1R6#show snmp view *ilmi system - included permanent active *ilmi atmForumUni - included permanent active NORMAL iso - included nonvolatile active v1default iso - included permanent active v1default internet.6.3.15 - excluded permanent active v1default internet.6.3.16 - excluded permanent active v1default internet.6.3.18 - excluded permanent active v1default ciscoMgmt.394 - excluded permanent active v1default ciscoMgmt.395 - excluded permanent active v1default ciscoMgmt.399 - excluded permanent active v1default ciscoMgmt.400 - excluded permanent active RESTRICTED ifEntry.0.3 FF:EF included nonvolatile active *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF0F iso.2.840.10036 - included volatile active *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF0F internet - included volatile active
Tags: authentication, community, iewb, notify, privacy, sample, snmp, v5, view
When you work with a remote rack by using an access-server (e.g. 25xx) with the async lines connected to the console ports of the pod’s routers, you effectively have only one terminal window opened. Using ctrl-Shift-6-x you can quickly switch between terminal lines; however, if you need to monitor “debug” command output on one terminal line, while performing some activity on the other you may face some difficulties.
For example, when you enable debug crypto isakmp on one router, and then switch to the other router, to generate packets with ping command, you may lose some of the debugging output, while switching back to the original router. Two obvious ways to resolve this issue exist: first one – open multiple terminal windows; next one – use logging buffered command to collect the debug logs into logging buffer. The third, not so well-known way to cope with the issue, is to use service telnet-zeroidle command on the access server.
What this command does, is announces TCP receive window with the value of zero for “idle” (currently non-active) connections. How does this work? When a TCP “server” is told that the other side’s TCP receive window is zero, the server starts buffering data to be send, until the other side “un-shrinks” the window again. Now, since all sessions from an access-server are effectively reverse-telnet connections to the access-server itself, by advertising TCP window value of zero, we make access-server buffer router’s console output (e.g. from debug commands), until the respective session becomes active again. In effect, with service telnet-zeroidle enabled, you may start, say, debug crypto isakmp on one router, switch to other, type ping x.x.x.x, then get back to the original router just to grab all the debug output at once – without any loss! Just make sure, your large debugging output runs fit into TCP xmit buffer, and don’t be scared by flood of output when you get back to an idle connection!
Tags: access-server, debug, telnet, zeroidle
Hi Brian,
How do I switch between devices when using a Cisco access server?
There are two ways to connect to devices attached to an access server, you can terminate your exec session on the access server itself (one terminal window for all sessions), or you can terminate your exec session on the device connected to the access server (one terminal window for each session). In the CCIE Lab Exam you will have the option to do either, so pick whichever method works best for you and stick with it during your preparation.
When you terminate your exec session on the access server you then “reverse telnet” to the individual devices connected to the access server. Normally to do this you first login to the access server and then issue the “show hosts” command to see the host mappings. Next, reverse telnet to them by typing the hostname and pressing enter. To get back to the access server issue the escape sequence CTRL-SHIFT-6-X. To do so hold ctrl and shift, hit 6, release all keys, then hit X. From the access server you can then open new connections or resume connections that you already have open.
When you terminate your exec session on the device connected to the access server, i.e. by telnetting to the access server at port 2001, you cannot issue the escape sequence to reconnect to the access server. In this situation you would open multiple terminal windows if you wanted to connect to multiple devices.
For more information watch this class-on-demand video on using an access server.
Hi Brian,I configured NTP on 2 Routers back-to-back with authentication (md5). So far everything works fine. I removed authentication on one of the Routers (no ntp authenticate) and they continue to sync. I even rebooted the router on which I had removed the authentication and they still sync. Any ideas why?
A common misconception about NTP authentication is the direction in which authentication occurs, however it makes perfect sense if you ask yourself this question: what is the purpose of using NTP authentication?
One clear answer is that authentication is used to prevent tampering with the timestamps on the logs generated by devices. To implement an attack on NTP, a hacker would make their rogue host appear to be a valid NTP server. NTP authentication is therefore used to authenticate the time source, not the client.
Take the following scenario:
R1–12.0.0.0/8–R2
R1 and R2 share the segment 12.0.0.0/8. R1 is the NTP master, and R2 is the client. To get a better understanding of how NTP authentication works, try the following possible configurations and see which of them work and which of them do not.
Case 1: No authentication
R1#sh run | in ntp ntp master 1 R2#sh run | in ntp server ntp server 12.0.0.1 R2#sh ntp status | in synch Clock is synchronized, stratum 2, reference is 12.0.0.1 R2#show ntp associations detail 12.0.0.1 configured, our_master, sane, valid, stratum 1
Case 2: Authentication on server, no authentication on client
R1#sh run | in ntp ntp authentication-key 1 md5 121A0C041104 7 ntp authenticate ntp master 1 R2#sh run | in ntp ntp clock-period 17179863 ntp server 12.0.0.1 R2#sh ntp status | in sync Clock is synchronized, stratum 2, reference is 12.0.0.1 R2#sh ntp assoc detail 12.0.0.1 configured, our_master, sane, valid, stratum 1
Case 3: No authentication on server, authentication on client
R1#sh run | in ntp ntp master 1 R2#sh run | in ntp ntp authentication-key 1 md5 08701E1F28492647465A5D547E 7 ntp authenticate ntp trusted-key 1 ntp clock-period 17179863 ntp server 12.0.0.1 key 1 R2#sh ntp status | in sync Clock is unsynchronized, stratum 16, no reference clock R2#sh ntp assoc detail 12.0.0.1 configured, insane, invalid, unsynced, stratum 16
Case 4: Authentication on server and client
R1#sh run | in ntp ntp authentication-key 1 md5 0822455D0A16 7 ntp authenticate ntp master 1 R2#sh run | in ntp ntp authentication-key 1 md5 060506324F41 7 ntp authenticate ntp trusted-key 1 ntp clock-period 17179865 ntp server 12.0.0.1 key 1 R2#sh ntp status | in sync Clock is synchronized, stratum 2, reference is 12.0.0.1 R2#sh ntp assoc detail 12.0.0.1 configured, authenticated, our_master, sane, valid, stratum 1
As shown by the above configuration, NTP authentication is used to authenticate the NTP source, not any associated clients.
Loading ...
