SYSTEM ADMINISTRATOR GUIDE     34/1543-CRA 119 1170/1-V1 Uen B    

Configuring NTP

Copyright

© Ericsson AB 2010. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List

SmartEdge is a registered trademark of Telefonaktiebolaget LM Ericsson.

Contents

1Overview

2
Configuration and Operations Tasks
2.1Configure an NTP Server in a Context
2.2Configure an NTP Peer in a Context
2.3Configure slowsync for NTP
2.4Operations Tasks

3
Configuration Examples

1   Overview

This document provides an overview of the Network Time Protocol (NTP) features supported by the SmartEdge® router and describes the tasks performed to configure, monitor, and administer NTP. This document also provides NTP configuration examples.

The SmartEdge router supports NTP as described in RFC 1305, Network Time Protocol. Although the default version is version 3, the SmartEdge router also supports NTP versions 1 and 2. NTP exchanges timekeeping information between servers and clients and among peers to synchronize clocks. NTP makes estimates based on several variables, including network delay, dispersion of packet exchanges, and clock offset. Extremely reliable sources, such as atomic or radio clocks and Global Positioning System (GPS) satellite timing receivers, act as primary servers. Company or campus servers can act as secondary time servers. To reduce overhead, secondary servers distribute time to attached local hosts.

On the SmartEdge® router, you configure NTP at the context level. You can configure multiple contexts as NTP servers and multiple peers and clients in each context, but there is a single NTP process on each router that synchronizes the system clock with the authoritative time source. You can configure each NTP server to broadcast NTP messages on the same subnet as the configured NTP broadcast interface.

Because SmartEdge OS uses the time synchronized by NTP to set the log file timestamp, NTP poses a security risk. By falsifying NTP information, an attacker could alter timestamp information to obscure evidence of an attack. To protect the NTP server, use IP access control lists (ACLs) applied with an administrative ACL in each context serving as an NTP server or peer .

2   Configuration and Operations Tasks

Note:  
In this section, the command syntax in the task tables displays only the root command; for the complete command syntax, see Command List.


To configure NTP, perform the tasks described in the following sections.

2.1   Configure an NTP Server in a Context

To configure an NTP server in a context, perform the tasks described in Table 1.

Table 1    Configure an NTP Server in a Context

Task

Root Command

Notes

Access the context and context configuration mode.

context

Enter this command in global configuration mode.

Access NTP server configuration mode.

ntp-mode

Enter this command in context configuration mode.

Enable the NTP server in a context

server-mode

Add this command in any context that will use NTP as a server.


Use the no form of the command to disable the NTP server in the context.

Configure the time source for the NTP server.

server

You can identify the time source and NTP version.

Configure the server to broadcast time updates to peers, which must be on a subnet of the server.

ntp-broadcast

Enter this command in interface configuration mode in the interface connected to the subnet for the peers.

For server security, configure an ACL.

ip access-list

Set up rules to limit the NTP servers that can synchronize local NTP peers.

Apply the IP ACL to the context with an administrative access-group.

admin-access-group

Add the ACL for NTP at the beginning of any list of ACL rules so it will run first. For more information, see Configuring ACLs.


2.2   Configure an NTP Peer in a Context

To configure an NTP peer in a context, perform the tasks in Table 2.

Table 2    Configure an NTP Peer in a Context

Task

Root Command

Notes

Configure an NTP peer in a context.

peer

Enter this command in NTP server configuration mode; see Table 1 for the commands to access this mode.

2.3   Configure slowsync for NTP

To configure an NTP server to gradually adjust to changes in the time source, perform the steps in Table 3.

Table 3    Configure an NTP Server to Gradually Adjust to Time Changes

Task

Root Command

Notes

Configure the NTP server to gradually adjust to time changes.

slowsync

Use this command to set NTP to slowly adjust to changes in the time source.


Enter this command in NTP server configuration mode.

2.4   Operations Tasks

To monitor, troubleshoot, and administer NTP features, perform the operations tasks described in Table 4. Enter the debug command in exec mode; enter the show commands in any mode.

Table 4    NTP Operations Tasks

Task

Command

Notes

Enable the generation of NTP debug messages.

debug ntp

You can generate debugging logs of all NTP messages, NTP general, NTP packet, or NTP update messages.

Display the current NTP configuration.

show configuration ntp

  

Display current associations with remote NTP servers and list daemon statistics for those servers.

show ntp associations

For more comprehensive information, use the detail keyword.


For information about NTP in all contexts, use the all-contexts keyword.

Display current NTP parameter settings and synchronization status.

show ntp status

  

3   Configuration Examples

The following example shows how to configure the NTP server and peers in the isp202 context.

[local]Redback(config)#context isp202
[local]Redback(config-ctx)#ntp-mode
[local]Redback(config-ntp-server)#server-mode
[local]Redback(config-ntp-server)#server 1.1.1.2 prefer source ntp
[local]Redback(config-ntp-server)#peer 1.1.1.7 source ntp
[local]Redback(config-ntp-server)#peer 1.1.1.5 source ntp
[local]Redback(config-ntp-server)#peer 1.1.1.6 source ntp
[local]Redback(config-ntp-server)#exit
[local]Redback(config-ctx)#ip access-list ntp
[local]Redback(config-access-list)#seq 20 permit udp 1.1.1.0 0.0.0.255 host 1.1.1.2 eq ntp
[local]Redback(config-access-list)#seq 30 permit udp 1.1.2.0 0.0.0.255 host 1.1.1.2 eq ntp
[local]Redback(config-access-list)#seq 40 permit udp 1.1.3.0 0.0.0.255 host 1.1.1.2 eq ntp
[local]Redback(config-access-list)#seq 50 deny udp any any eq ntp
[local]Redback(config-access-list)#exit
[local]Redback(config-ctx)#interface ntp
[local]Redback(config-if)#ip address 1.1.1.2/24
 [local]Redback(config-if)#ntp-broadcast

The following example shows detailed information about NTP associations for a server and its peers:

[local]Redback#show ntp association detail
remote 155.53.12.12, local 10.192.17.246
hmode client, pmode unspec, stratum 4, precision -18
leap 00, refid [130.100.199.242], rootdistance 0.20607, rootdispersion 0.09840
ppoll 6, hpoll 6, keyid 0, version 3, association 1508
valid 7, reach 377, unreach 0, flash 0x0000, boffset 0.00000, ttl/mode 0
timer 0s, flags system_peer, config, bclient
reference time:      cf15e293.0af6a289  Thu, Feb  4 2010 16:19:31.042
originate timestamp: cf15e8eb.30cf72d9  Thu, Feb  4 2010 16:46:35.190
receive timestamp:   cf15e8ea.2e3065f9  Thu, Feb  4 2010 16:46:34.180
transmit timestamp:  cf15e8e9.c66f2e8c  Thu, Feb  4 2010 16:46:33.775
filter delay:  0.40527  0.33043  0.10486  0.11139
               0.17230  0.12062  0.16760  0.15277
filter offset: 1.212877 1.044107 1.050654 0.985800
               0.714899 0.650443 0.531281 0.360664
filter order:  2        3        5        7
               6        4        1        0
offset 1.050654, delay 0.10486, error bound 0.05133, filter error 0.36215
context id: 0x40080001