NTP¶

Network Time Protocol (NTP) is a networking protocol for clock synchronization. Basically the required parameters are the peer(s) with which you accept to exchange information, and the frequency of updates.

Client¶

Only one NTP client can be enabled at a time.

Here is an example on querying one NTP server with the parameter iburst set to enable burst synchronization:

vsr running config# / vrf main ntp time-sources server ntp.6wind.com iburst true

To check the state:

vsr> show state / vrf main ntp
ntp
    enabled true
    time-sources
        makestep
            threshold 1000
            limit 3
            ..
        server ntp.6wind.com
            version 4
            association-type SERVER
            iburst true
            prefer false
            stratum 2
            root-delay 4
            root-dispersion 7
            offset 3
            poll-interval 64
            synchronized true
            state system-peer
            ..
        ..
    ..

To show the state in a human readable way:

vsr> show ntp vrf main
NTP synchronized with ntp.6wind.com at stratum 2.
   time correct within 3 ms.

The same configuration can be made using this NETCONF XML configuration:

vsr> show config xml absolute / vrf main ntp
<config xmlns="urn:6wind:vrouter">
  <vrf>
    <name>main</name>
    <ntp xmlns="urn:6wind:vrouter/ntp">
      <enabled>true</enabled>
      <time-sources>
        <makestep>
          <threshold>1000</threshold>
          <limit>3</limit>
        </makestep>
        <server>
          <address>ntp.6wind.com</address>
          <version>4</version>
          <association-type>SERVER</association-type>
          <iburst>true</iburst>
          <prefer>false</prefer>
        </server>
      </time-sources>
    </ntp>
  </vrf>
</config>

Server¶

Here is an example where Virtual Service Router will act as a server. It will answer to all synchronization requests except from the subnet 192.168.2.0/24:

vsr running config# vrf main
vsr running vrf main# ntp
vsr running ntp# server-subnet 0 allow all
vsr running ntp# server-subnet 3 deny 192.168.2.0/24
vsr running ntp# commit

Note

The server can also act as an NTP client.

To check for state:

vsr running config# show state vrf main ntp
ntp
    server-subnet 0 allow all
    server-subnet 3 deny 192.168.2.0/24
    ..

The same configuration can be made using this NETCONF XML configuration:

vsr running config# show config xml absolute vrf main ntp
<config xmlns="urn:6wind:vrouter">
  <vrf>
    <name>main</name>
    <ntp xmlns="urn:6wind:vrouter/ntp">
      <enabled>true</enabled>
      <server-subnet>
        <num>0</num>
        <allow>all</allow>
      </server-subnet>
      <server-subnet>
        <num>3</num>
        <deny>192.168.2.0/24</deny>
      </server-subnet>
    </ntp>
  </vrf>
</config>

To show the NTP clients synchronized with Virtual Service Router:

vsr running config# show ntp clients
Host            NTP recv pkts NTP drop pkts NTP last pkt (s) Cmd recv pkts Cmd drop pkts Cmd last pkt (s)
=============== ============= ============= ================ ============= ============= ================
192.168.1.100   17            0             5                2             0             15
10.45.1.50      125           0             12               0             0             -

Authentication¶

NTP messages can be authenticated by way of a MAC generated using a key. An authenticated NTP message carries an integer identifier for the key alongside the MAC of the message. The recipient can verify the authentication by computing its own MAC using the key it associates with the provided identifier and ensuring that it matches the one in the message.

See also

The original specification for the NTP MAC in RFC 5905#section-7.3 and the updated method of computing the MAC in RFC 8573.

Authentication keys can be configured in the auth-key list, they are identified by the key identifier used in NTP messaging. The key itself is configured via the secret field:

vsr running config# / vrf main ntp auth-key 123 secret ThisIsAnExampleKey

A MAC algorithm may be specified via the cryptographic-algorithm field. For compatibility reasons the default MAC algorithm is MD5 (as specified by RFC 5905). More recently, RFC 8573 deprecates MD5 and recommends using AES128-CMAC instead:

vsr running config# / vrf main ntp auth-key 456 secret Example128BitKey cryptographic-algorithm aes128-cmac

A randomly generated key is unlikely to be printable. Non-printable keys can be entered in hexadecimal form using the secret-hex parameter. This is particularly useful to reach the full security benefits of algorithms that impose strict restrictions on the key length, like AES128-CMAC:

vsr running config# / vrf main ntp auth-key 789 secret-hex 00010203040506070809aAbBcCdDeEfF cryptographic-algorithm aes128-cmac

To check the state:

vsr> show state / vrf main ntp auth-key
auth-key 123
    secret ThisIsAnExampleKey
    cryptographic-algorithm md5
    ..
auth-key 456
    secret Example128BitKey
    cryptographic-algorithm aes128-cmac
    ..
auth-key 789
    secret-hex 00010203040506070809aAbBcCdDeEfF
    cryptographic-algorithm aes128-cmac
    ..

The same configuration can be made using this NETCONF XML configuration:

vsr> show config xml absolute / vrf main ntp auth-key
<config xmlns="urn:6wind:vrouter">
  <vrf>
    <name>main</name>
    <ntp xmlns="urn:6wind:vrouter/ntp">
      <auth-key>
        <key-id>123</key-id>
        <secret>ThisIsAnExampleKey</secret>
        <cryptographic-algorithm>md5</cryptographic-algorithm>
      </auth-key>
      <auth-key>
        <key-id>456</key-id>
        <secret>Example128BitKey</secret>
        <cryptographic-algorithm>aes128-cmac</cryptographic-algorithm>
      </auth-key>
      <auth-key>
        <key-id>789</key-id>
        <secret-hex>00010203040506070809aAbBcCdDeEfF</secret-hex>
        <cryptographic-algorithm>aes128-cmac</cryptographic-algorithm>
      </auth-key>
    </ntp>
  </vrf>
</config>