No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

CX11x, CX31x, CX710 (Earlier Than V6.03), and CX91x Series Switch Modules V100R001C10 Configuration Guide 12

The documents describe the configuration of various services supported by the CX11x&CX31x&CX91x series switch modules The description covers configuration examples and function configurations.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Principles

Principles

This section describes the implementation of NTP.

Operating Principle

Figure 3-11 shows NTP implementation:

Switch ModuleA and Switch ModuleB are connected through a wide area network (WAN). Each of them has its own system clock, which is synchronized automatically through NTP.

Presuming that:

  • Before the clocks of Switch ModuleA and Switch ModuleB are synchronized, the clock of Switch ModuleA is 10:00:00 a.m. and the clock of Switch ModuleB is 11:00:00 a.m.

  • Switch ModuleB acts as an NTP time server, and Switch ModuleA must synchronize its clock with that of Switch ModuleB.

  • It takes one second to unidirectionally transmit an NTP message between Switch ModuleA and Switch ModuleB.

  • Both Switch ModuleA and Switch ModuleB take one second to process an NTP message.

Figure 3-11 Diagram of NTP implementation

The process of synchronizing the system clock is as follows:

  1. Switch ModuleA sends an NTP message to Switch ModuleB. The message carries an initial timestamp, 10:00:00 a.m. (T1), indicating the time when it leaves Switch ModuleA.

  2. When the NTP message reaches Switch ModuleB, Switch ModuleB adds the timestamp 11: 00:01 a.m. (T2) to the NTP message, indicting the time when Switch ModuleB receives the message.

  3. When the NTP message leaves Switch ModuleB, Switch ModuleB adds the transmit timestamp 11:00:02 a.m. (T3) to the NTP message, indicating the time when the message leaves Switch ModuleB.

  4. When Switch ModuleA receives this response message, it adds a new receive timestamp, 10:00:03 a.m. (T4).

    Switch ModuleA uses the information in the received message to calculate the following two important parameters:

    • Roundtrip delay of the NTP message: Delay = (T4 - T1) - (T3 - T2)

    • Clock offset of Switch ModuleA by taking Switch ModuleB as a reference: Offset = ((T2 - T1) + (T3 - T4))/2

  5. After the calculation, Switch ModuleA knows that the roundtrip delay is 2 seconds and the clock offset of Switch ModuleA is 1 hour. Switch ModuleA sets its own clock based on these two parameters to synchronize its clock with that of Switch ModuleB.

NOTE:

The preceding example is only a brief description of the operating principle of NTP. In fact, NTP uses the standard algorithms in RFC 1305 to ensure the precision of clock synchronization.

Network Architecture

The NTP network architecture involves the following concepts:
  • Synchronization subnet consists of the primary time server, secondary time servers, PC clients, and interconnecting transmission paths, as shown in Figure 3-12.
  • Primary time server directly synchronizes its clock with a standard reference clock using a cable or radio. The standard reference clock is usually a radio clock or the Global Positioning System (GPS).
  • Secondary time server synchronizes its clock with the primary time server or other secondary time servers on the network. A secondary time server transmits the time information to other hosts on a LAN through NTP.
  • Stratum is a hierarchical standard for clock synchronization. It represents precision of a clock. The value of a stratum ranges from 1 to 16. A smaller value indicates higher precision. The value 1 indicates the highest clock precision, and 16 indicates that the clock is not synchronized.
Figure 3-12 NTP network architecture

Under normal circumstances, the primary time server and the secondary time servers in a synchronization subnet are arranged in a hierarchical-master-slave structure. In this structure, the primary time server is located at the root, and the secondary time servers are arranged close to leaf nodes. As their strata increase, the precision decreases accordingly. The extent to which the precision of the secondary time servers decreases depends on stability of network paths and the local clock.

NOTE:

When the synchronization subnet has multiple primary time servers, the optimal server can be selected using an algorithm.

Such a design ensures that:
  • When faults occur in one or more primary/secondary time servers or network paths interconnecting them, the synchronization subnet will automatically be reconstructed into another hierarchical-master-slave structure to obtain the most precise and reliable time.
  • When all primary time servers in the synchronization subnet become invalid, a standby primary time server runs.
When all primary time servers in the synchronization subnet become invalid, other secondary time servers are synchronized among themselves. These secondary time servers become independent of the synchronization subnet and automatically run at the last determined time and frequency. When a switch modules with a stable oscillator becomes independent of the synchronization subnet for an extended period of time, its timing error can be kept less than several milliseconds in a day because of highly precise calculations.

Operating Mode

A device may use multiple NTP operating modes to perform time synchronization. You can select an appropriate operating mode as required.
Unicast Server/Client Mode

The unicast server/client mode runs on a higher stratum on a synchronous subnet. In this mode, devices need to obtain the IP address of the server in advance.

  • Client: A host running in client mode (client for short) periodically sends packets to the server. The Mode field in the packets is set to 3, indicating that the packets are coming from a client. After receiving a reply packet, the client filters and selects clock signals, and synchronizes its clock with the server that provides the optimal clock. A client does not check the reachability and stratum of the server. Usually, a host running in this mode is a workstation on a network. It synchronizes its clock with the clock of a server but does not change the clock of the server.

  • Server: A host running in server mode (server for short) receives the packets from clients and responds to the packets received. The Mode field in reply packets is set to 4, indicating that the packets are coming from a server. Usually, the host running in server mode is a clock server on a network. It provides synchronization information for clients but does not change its own clock.

Figure 3-13 Unicast Client/Server Mode

During and after the restart, the host operating in client mode periodically sends NTP request messages to the host operating in server mode. After receiving the NTP request message, the server swaps the position of destination IP address and source IP address, and the source port number and destination port number, fills in the necessary information, and sends the message to the client. The server does not need to retain state information when the client sends the request message. The client freely adjusts the interval for sending NTP request messages according to the local conditions.

Peer Mode

The peer mode runs on a lower stratum on a synchronous subnet. In this mode, a active peer and a passive peer can synchronize with each other. The peer with a higher stratum (a lower level) synchronizes with a peer with a lower stratum (a higher level).

In peer mode, the active peer initiates an NTP packet with the Mode field set to 3 (the client mode), and the passive peer responds with an NTP packet with the Mode field set to 4 (the server mode). This interaction creates a network delay so that devices at both ends enter the peer mode.

  • Active peer: A host that functions as a active peer sends packets periodically. The value of the Mode field in a packet is set to 1. This indicates that the packet is sent by a active peer, without considering whether its peer is reachable and which stratum its peer is on. The active peer can provide time information about the local clock for its peer, or synchronize the time information about the local clock based on that of the peer clock.

  • Passive peer: A host that functions as a passive peer receives packets from the active peer and sends reply packets. The value of the Mode field in a reply packet is set to 2. This indicates that the packer is sent by a passive peer. The passive peer can provide time information about the local clock for its peer, or synchronize the time information about the local clock based on that of the peer clock.

Figure 3-14 Peer mode

NOTE:

The passive peer does not need to be configured. A host sets up a connection and sets relevant state variables only when it receives an NTP packet.

Broadcast Mode

The broadcast mode is applied to the high speed network that has multiple workstations and does not require high accuracy. In a typical scenario, one or more clock servers on the network periodically send broadcast packets to the workstations. The delay of packet transmission in a LAN is at the milliseconds level.

  • Broadcast server: A host that runs in broadcast mode sends clock synchronization packets to the broadcast address 255.255.255.255 periodically. The value of the Mode field in a packet is set to 5. This indicates that the packet is sent by a host that runs in broadcast mode, without considering whether its peer is reachable and which stratum its peer is on. The host running in broadcast mode is usually a clock server running high-speed broadcast media on the network, which provides synchronization information for all of its peers but does not alter the clock of its own.

  • Broadcast client: The client listens to the clock synchronization packets sent from the server. When the client receives the first clock synchronization packet, the client and server exchange NTP packets whose values of Mode fields are 3 (sent by the client) and the NTP packets whose values of Mode fields are 4 (sent by the server). In this process, the client enables the server/client mode for a short time to exchange information with the remote server. This allows the client to obtain the network delay between the client and the server. Then, the client returns the broadcast mode, and continues to sense the incoming clock synchronization packets to synchronize the local clock.

Figure 3-15 Broadcast mode

Multicast Mode

Multicast mode is useful when there are large numbers of clients distributed in a network. This normally results in large number of NTP packets in the network. In the multicast mode, a single NTP multicast packet can potentially reach all the clients on the network and reduce the control traffic on the network.

  • Multicast server: A server running in multicast mode sends clock synchronization packets to a multicast address periodically. The value of the Mode field in a packet is set to 5. This indicates that the packet is sent by a host that runs in multicast mode. The host running in multicast mode is usually a clock server running high-speed broadcast media on the network, which provides synchronization information for all of its peers but does not alter the clock of its own.

  • Multicast client: The client listens to the multicast packets from the server. When the client receives the first broadcast packet, the client and server exchange NTP packets whose values of Mode fields are 3 (sent by the client) and the NTP packets whose values of Mode fields are 4 (sent by the server). In this process, the client enables the server/client mode for a short time to exchange information with the remote server. This allows the client to obtain the network delay between the client and the server. Then, the client returns the multicast mode, and continues to sense the incoming multicast packets to synchronize the local clock.

Figure 3-16 Multicast mode

Manycast Mode

Manycast mode is applied to a small set of servers scattered over the network. Clients can discover and synchronize to the closest manycast server. Manycast can especially be used where the identity of the server is not fixed and a change of server does not require reconfiguration of all the clients in the network.

  • Manycast client: The client in manycast mode periodically sends request packets (the Mode field is set to 3) to an IPv4/IPv6 multicast address. After receiving a reply packet, the client filters and selects clock signals, and synchronizes its clock with the server that provides the optimal clock.

  • Manycast server: The manycast server continuously listens to the packets. If a server can be synchronized, the server returns a packet (the Mode field is set to 4) by using the unicast address of the client as the destination address.

To prevent the client from constantly sending NTP request packets to the manycast server and reduce the load of the server, the NTP protocol defines a minimum number of connections. In manycast mode, the client records the number of connections established every time it synchronizes clock with the server. The minimum number of connections is the minimum number of connections called during a synchronization process. If the number of connections called by the client reaches the minimum number during subsequent synchronization processes and the synchronization is completed, the client considers that the synchronization is completed. After that, the client sends a packet every time a timeout period expires to maintain the connection. The NTP protocol uses the time to live (TTL) mechanism to ensure that the client can successfully synchronize with the server. Every time the client sends an NTP packet, the TTL of the packet increases (the initial value as 1) until the minimum number of connections is reached or the TTL value reaches the upper limit. If the TTL reaches the upper limit or the number of connections called by the client reaches the minimum number, but connections called by the client still cannot complete the synchronizing process, the client stops data transmission in a timeout period to eliminate all connections. Then the client repeats the preceding process.

NOTE:

In NTP implementation, a peer structure is established for each synchronization source, and these peer structures are stored in a chain in a Hash form. Each peer structure is corresponding to a connection.

Figure 3-17 Manycast mode

NTP Access Control

When a time server on a synchronization subnet is faulty or encounters a malicious attack, timekeeping on other clock servers on the subnet should not be affected. To meet this requirement, NTP provides the following security mechanisms to ensure network security: access authority, Kiss-o'-Death (KOD) and NTP authentication.

Access Authority

A device provides access authority, which is simpler and more secure, to protect a local clock.

NTP access control is implemented based on an access control list (ACL). NTP supports five levels of access authority, and a corresponding ACL rule can be specified for each level. If an NTP access request hits the ACL rule for a level of access authority, they are successfully matched and the access request enjoys the access authority at this level.

When an NTP access request reaches the local end, the access request is successively matched with the access authority from the maximum one to the minimum one. The first successfully matched access authority takes effect. The matching order is as follows:
  1. peer: indicates that a time request may be made for the local clock and a control query may be performed on the local clock. The local clock can also be synchronized to a remote server.

  2. server: indicates that a time request may be made for the local clock and a control query may be performed on the local clock, but the local clock cannot be synchronized with the clock of the remote server.

  3. synchronization: indicates that only a time request can be made for the local clock.

  4. query: indicates that only a control query can be performed on the local clock.

  5. limited: When the rate of NTP packets exceeds the upper limit, the incoming NTP packets are discarded, and a Kiss code is sent if the KOD function is enabled.

KOD

When a server receives a large number of client access packets within a specified period of time and cannot bear the load, the KOD function can be enabled on the server to perform access control. KOD is a brand new access control technology that is put forward in NTPv4, and it is used by the server to provide information, such as a status report and access control, for the client.

A KOD packet is a special NTP packet. When the Stratum field in an NTP packet is 0, the packet is called a KOD packet and the ASCII message it conveys is called kiss code and represents access control information. Currently, only two types of kiss codes are supported: DENY and RATE.

After the KOD function is enabled on the server, the server sends kiss code DENY or RATE to the client based on the configuration.

NOTE:

After the KOD function is enabled, the corresponding ACL rule needs to be configured. When the ACL rule is configured as deny, the server sends the kiss code DENY. When the ACL rule is configured as permit and the rate of NTP packets received reaches the configured upper limit, the server sends the kiss code RATE.

  • When the client receives kiss code DENY, the client terminates all connections to the server and stops sending packets to the server.
  • When the client receives kiss code RATE, the client immediately reduces its polling interval to the server and continues to reduce the interval each time it receives a RATE kiss code.
Authentication

The NTP authentication function can be enabled on networks demanding high security. Different keys may be configured in different operating modes.

When a user enables the NTP authentication function in a certain NTP operating mode, the system records the key ID in this operating mode.

  • Sending process

    The system determines whether authentication is required in this operating mode. If authentication is not required, the system directly sends a packet. If authentication is required, the system encrypts the packet using the key ID and an encryption algorithm and sends it.

  • Receiving process

    After receiving a packet, the system determines whether the packet needs to be authenticated. If the packet does not need to be authenticated, the system directly performs subsequent processing on the packet. If the packet needs to be authenticated, the system authenticates the packet using the key ID and a decryption algorithm. If the authentication fails, the system directly discards the packet. If the authentication succeeds, the system processes the received packet.

Translation
Download
Updated: 2019-08-09

Document ID: EDOC1000041694

Views: 58699

Downloads: 3621

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Share
Previous Next