When a firewall filter is configured on the loopback interface of a Juniper router that is running Junos, the show ntp status and show ntp association commands may not produce the expected output, even though the NTP daemon is running and the address of the configured NTP server is allowed by the loopback filter.
show
ntp
status
association
To execute the NTP show commands, the router will query itself by sending traffic on the loopback interface. If this traffic is not allowed by the loopback filter, the show commands fail. To resolve this issue, the filter configuration must be modified.
When you use the NTP show commands, the Command Line Interface (CLI) prints localhost: timed out, nothing received . This occurs when a firewall filter is applied on the loopback interface. As soon as the firewall filter is de-activated, this behavior is no longer observed.
localhost:
timed
out,
nothing
received
Consider the following configuration:
user@ulm# show system ntp server 172.17.27.46; source-address 10.0.20.100; user@ulm# show interfaces lo0 unit 0 { family inet { filter { input Loopback-Firewall-Filter; } address 127.0.0.1/32; address 10.0.10.100/32; address 10.0.20.100/32 { primary; } address 10.0.30.100/32; } } user@ulm# show firewall family inet filter Loopback-Firewall-Filter term Allow-SSH { from { protocol tcp; port ssh; } then accept; } term Allow-NTP { from { source-address { 172.17.27.46/32; } protocol udp; port ntp; } then accept; } term Deny-Anything-Else { then { reject; } }
When this configuration is committed, the NTP show commands produce the following output:
user@ulm> show ntp status localhost: timed out, nothing received ***Request timed out user@ulm> show ntp associations localhost: timed out, nothing received ***Request timed out
The NTP process is still up and running:
user@ulm> start shell % ps aux | grep ntp root 4283 0.0 0.0 1336 688 ?? S Mon03PM 0:00.19 /usr/sbin/tnp.sntpd -Nroot 4301 0.0 0.1 1976 2000 ?? S Mon03PM 0:10.85 /usr/sbin/xntpd -j -N -g (ntpd) remote 25485 0.0 0.0 408 288 p1 R+ 3:46PM 0:00.00 grep ntp
To execute the NTP show commands, the router will query itself by sending traffic on the default loopback interface. If this traffic is not allowed by the loopback filter, the show commands fail. To resolve this issue, the filter configuration must be modified.Monitoring of the traffic shows that a local NTP request is sent via the lo0 interface. The reply, which is also local, is rejected by the input firewall filter on lo0. This happens each time an NTP show command is entered. The source and destination addresses of the NTP request are both equal to the source-address (10.0.20.100), which is specified in the NTP configuration.
lo0
user@ulm> monitor traffic interface lo0 no-resolve verbose output suppressed, use <detail> or <extensive> for full protocol decode Address resolution is OFF. Listening on lo0, capture size 96 bytes 16:19:06.206759 In IP 10.0.20.100.54729 > 10.0.20.100.123: NTPv2, Reserved, length 12 16:19:06.206825 In IP 10.0.20.100 > 10.0.20.100: ICMP host 10.0.20.100 unreachable - admin prohibited filter, length 36 16:19:11.207405 In IP 10.0.20.100.54729 > 10.0.20.100.123: NTPv2, Reserved, length 12 16:19:11.207448 In IP 10.0.20.100 > 10.0.20.100: ICMP host 10.0.20.100 unreachable - admin prohibited filter, length 36
When the firewall filter is changed to explicitly allow the NTP source-address, this behavior is no longer observed:
user@ulm# show firewall family inet filter Loopback-Firewall-Filter term Allow-SSH { from { protocol tcp; port ssh; } then accept; } term Allow-NTP { from { source-address { 172.17.27.46/32; 10.0.20.100/32; } protocol udp; port ntp; } then accept; } term Deny-Anything-Else { then { reject; } }
In this case, monitoring of the traffic shows that with each NTP show command being entered, NTP traffic is being sent (and received) via the lo0 interface:
user@ulm> monitor traffic interface lo0 no-resolve verbose output suppressed, use <detail> or <extensive> for full protocol decode Address resolution is OFF. Listening on lo0, capture size 96 bytes 16:24:35.953912 In IP 10.0.20.100.56892 > 10.0.20.100.123: NTPv2, Reserved, length 12 16:24:35.954212 In IP 10.0.20.100.123 > 10.0.20.100.56892: NTPv2, Reserved, length 348
The show ntp status command produces the expected output:
user@ulm> show ntp status status=0644 leap_none, sync_ntp, 4 events, event_peer/strat_chg, version="ntpd 4.2.0-a Thu Feb 14 03:06:23 UTC 2008 (1)", processor="i386", system="JUNOS9.0R1.10", leap=00, stratum=2, precision=-20, rootdelay=170.961, rootdispersion=21.583, peer=46724, refid=172.17.27.46, reftime=cbc2b0d7.b5d026c0 Wed, Apr 30 2008 10:48:23.710, poll=6, clock=cbc2b0ef.b402b32b Wed, Apr 30 2008 10:48:47.703, state=4, offset=18.736, frequency=58.615, jitter=1.425, stability=0.080 user@ulm>
The show ntp associations command might take a long time to produce the expected output. This is especially true in this example, because DNS traffic is not allowed by the firewall filter. This is a separate issue, the discussion of which is outside the scope of this article.
associations
user@ulm# run show ntp associations no-resolve ***Can't find host localhost remote refid st t when poll reach delay offset jitter ============================================================================== *172.17.27.46 .GPS. 1 u 47 64 17 170.125 0.934 1.228
If no source-address is configured for NTP and the router is running Junos OS 8.0 or later, the primary address of the loopback interface is used by the router to query itself. This is the address that should be allowed in by the firewall filter. If the IP address on the loopback is configured as 127.0.0.1, it must be allowed in the firewall filter. If the loopback interface does not have an IP address, NTP will use the address of the interface that reaches the NTP server. Prior to Junos OS 8.0, the router used the numerically lowest address configured on the loopback interface insteadNote: For platforms that do not support matching on "port" in the firewall filter term: - These platforms will support matching on "source-port" and "destination port". In this case, two filter terms are needed: one that matches on destination-port for the traffic sent, and one matching on source-port for the return traffic.
term allow-ntp-out { from { source-address { <source_ip_used_by_ntp/32>; } protocol udp; destination-port ntp; } } term allow-ntp-in { from { source-address { <source_ip_used_by_ntp/32>; } protocol udp; source-port ntp; } } Use Case: In certain scenarios, customer may be using lo0.1 for NTP communication but not allowing lo0.0 (default) IP address in RE-PROTECT filter, won't sync to NTP with timed-out error for the following commands: > show ntp status > show ntp associations R1> show configuration | display set | match "lo0" set interfaces lo0 unit 0 family inet filter input RE-PROTECT set interfaces lo0 unit 0 family inet address x.x.x.x/32 set interfaces lo0 unit 1 family inet filter input NTP-FILTER set interfaces lo0 unit 1 family inet address a.a.a.a/32 NTP config: set system ntp server y.y.y.y prefer set system ntp server y.y.y.y routing-instance mgmt_junos set system ntp server z.z.z.z routing-instance mgmt_junos set system ntp source-address a.a.a.a routing-instance mgmt_junos RE-PROTECT fitler: set firewall family inet filter RE-PROTECT term UDP from protocol udp set firewall family inet filter RE-PROTECT term UDP from port ntp set firewall family inet filter RE-PROTECT term UDP from port snmp set firewall family inet filter RE-PROTECT term UDP from port snmptrap set firewall family inet filter RE-PROTECT term UDP then discard NTP-FILTER filter: set firewall family inet filter NTP-FILTER term NTP from source-address a.a.0.0/15 set firewall family inet filter NTP-FILTER term NTP from protocol udp set firewall family inet filter NTP-FILTER term NTP from port ntp set firewall family inet filter NTP-FILTER term NTP then accept Modified RE-PROTECT filter to allow lo0.0 (default) which fixed the issue. R1# insert firewall family inet filter RE-PROTECT term NTP before term UDP Sep 11 11:03:47 {master}[edit] R1# show | compare Sep 11 11:03:50 [edit firewall family inet filter RE-PROTECT] term Telnet { ... } + term NTP { + from { + source-address { + a.a.0.0/15; + } + protocol udp; + port ntp; + } + then accept; + } term UDP { ... } R1> show ntp status Sep 11 11:06:04 status=0644 leap_none, sync_ntp, 4 events, event_peer/strat_chg, version="ntpd 4.2.0-a Wed Dec 22 21:32:46 2021 (1)", processor="amd64", system="FreeBSDJNPR-11.0-20211117.c779bdc_buil", leap=00, stratum=3, precision=-22, rootdelay=3.190, rootdispersion=77.019, peer=42940, refid=y.y.y.y, reftime=ea8bccd6.da3c53ee Wed, Sep 11 2024 11:01:26.852, poll=10, clock=ea8bcdec.e3d67dae Wed, Sep 11 2024 11:06:04.889, state=4, offset=-0.677, frequency=32.128, jitter=0.947, stability=0.081 {master} R1> show ntp associations Sep 11 11:06:10 remote refid st t when poll reach delay offset jitter =============================================================================== *y.y.y.y b.b.b.b 2 - 284 1024 377 2.473 -0.677 0.497
2021-05-25: Artice Article reviewed for accuracy. No changes made. Article is correct and complete2019-11-23: Added note on QFX5100 supporting "source-port".2018-04-27: Minor grammar corrections and added clarification about the loopback interface in the solution section.2023-10-22: Modified "Note" in solution section to include detail about platform that don't support "port"