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>

Reminder

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

upgrade
MENU

The Default Operation Is Permit When NTP Uses ACL for Packet Restriction

Publication Date:  2013-09-30 Views:  6 Downloads:  0
Issue Description

For equipment using VRP, such as NE5000E/NE40E/CX600, if the deny operation was not configured on the ACL rule on the NTP server, the permit operation was performed by default.

The configuration on the NTP server was as follows:

interface LoopBack0

 ip address 1.1.1.1 255.255.255.255    

 

ntp-service access peer 2000         ----------Restriction on the received NTP packets

acl number 2000

 rule 5 permit source 3.3.3.3 0      ----------No rule configured with the deny operation

 

The configuration on the NTP client was as follows:

interface LoopBack0

 ip address 2.2.2.2 255.255.255.255

ntp-service unicast-server 1.1.1.1

 

The NTP client could synchronize with the NTP server.

[Quidway]display  ntp status

 clock status: synchronized

 clock stratum: 3

 reference clock ID: 2.2.2.2

 nominal frequency: 63.9992 Hz

 actual frequency: 63.9992 Hz

 clock precision: 2^11

 clock offset: 0.0000 ms

 root delay: 42.97 ms

 root dispersion: 0.05 ms

 peer dispersion: 12.39 ms

 reference time: 08:10:08.013 UTC Apr 23 2013(D520C060.038F9B13)       
Handling Process

For nodes on which the permit operation was not matched, most ACL-using functions performed the deny operation.

Note:

According to rules on equipment, the deny operation was performed on flows by default. Therefore, if a rule was configured for existing flows and if the flows configured later needed to pass, the permit operation must be performed on the flows configured later.

However, for the NTP protocol, the default operation in the initial version was permit. To prevent an NTP failure caused by version difference, the permit operation was performed on the nodes that no ACL rule was matched.
Root Cause

For nodes on which the permit operation was not matched, most ACL-using functions performed the deny operation.

Note:

According to rules on equipment, the deny operation was performed on flows by default. Therefore, if a rule was configured for existing flows and if the flows configured later needed to pass, the permit operation must be performed on the flows configured later.

However, for the NTP protocol, the default operation in the initial version was permit. To prevent an NTP failure caused by version difference, the permit operation was performed on the nodes that no ACL rule was matched.
Solution

A rule with the deny operation was configured in the ACL view so that packet sources not in the permit list were rejected.

acl number 2000

 rule 5 permit source 3.3.3.3 0

 rule 10 deny          -----------Adds the command.

 

The NTP client 2.2.2.2 could not synchronize with the NTP server.

<Quidway>display  ntp status

 clock status: unsynchronized

 clock stratum: 16

 reference clock ID: none

 nominal frequency: 63.9992 Hz

 actual frequency: 63.9992 Hz

 clock precision: 2^11

 clock offset: 0.0000 ms

 root delay: 22.47 ms

 root dispersion: 12.66 ms

 peer dispersion: 0.00 ms

 reference time: 08:17:44.100 UTC Apr 23 2013(D520C228.19A98676) 
Suggestions
The operation configured in the default ACL rule for NTP is different from that for most other protocols. The deny operation needs to be configured for the ACL rule for NTP so that NTP is consistent with most other protocols in the operation configuration.

END