Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[SRX] node1 keeps sending the 'xntpd[1125]: NTP Server Unreachable' log to the syslog server

0

0

Article ID: KB23743 KB Last Updated: 01 Apr 2013Version: 2.0
Summary:
This article describes the issue of SRX1400's node1 (backup node) sending 'xntpd[1125]: NTP Server Unreachable to syslog server; even through node1 can reach the NTP server.
Symptoms:
Network topology:
node0----------------------------------------node1
 | reth0 192.168.1.20                        | reth0
 ------------------------Switch----------------------
       |                                  
 ntp/syslog server                   
 192.168.1.100
             

Here are the key SRX configurations:
root@SRX1400-A# show system syslog
host 192.168.1.100 {
any warning;
}

root@SRX1400-A# show system ntp
server 192.168.1.100;

When a NTP request is sent to the NTP server, node0 was found to be successful and node1 failed.
root@SRX1400-A> set date ntp
node0:
--------------------------------------------------------------------------
27 Apr 06:43:13 ntpdate[16376]: step time server 192.168.1.100 offset 0.784711 sec

node1:
--------------------------------------------------------------------------
27 Apr 06:46:17 ntpdate[16683]: no server suitable for synchronization found

It seems that node1 cannot reach the NTP server (192.168.1.100); however, you can see that node1's syslog packets reach the syslog server (same physical server):
root@LINUX-a:~# tcpdump -i eth1 port 514
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
14:16:54.162852 IP 192.168.1.20.syslog > LINUX-a.local.syslog: SYSLOG ntp.error, length: 99
14:17:10.669011 IP 192.168.1.20.syslog > LINUX-a.local.syslog: SYSLOG ntp.error, length: 65
14:17:13.211478 IP 192.168.1.20.syslog > LINUX-a.local.syslog: SYSLOG ntp.error, length: 65
14:17:14.669431 IP 192.168.1.20.syslog > LINUX-a.local.syslog: SYSLOG ntp.error, length: 65

Packet capture for NTP in the NTP server:
root@LINUX-a:~# tcpdump -i eth1 port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
14:47:20.892578 IP 192.168.1.20.60816 > LINUX-a.local.ntp: NTPv4, Client, length 48
14:47:20.892689 IP LINUX-a.local.ntp > 192.168.1.20.60816: NTPv4, Server, length 48
14:47:20.895516 IP 192.168.1.20.54090 > LINUX-a.local.ntp: NTPv4, Client, length 48
14:47:20.895586 IP LINUX-a.local.ntp > 192.168.1.20.54090: NTPv4, Server, length 48
14:47:20.897936 IP 192.168.1.20.54090 > LINUX-a.local.ntp: NTPv4, Client, length 48
14:47:20.897968 IP LINUX-a.local.ntp > 192.168.1.20.54090: NTPv4, Server, length 48
14:47:20.928317 IP 192.168.1.20.54090 > LINUX-a.local.ntp: NTPv4, Client, length 48
14:47:20.928414 IP LINUX-a.local.ntp > 192.168.1.20.54090: NTPv4, Server, length 48
14:47:20.930319 IP 192.168.1.20.54090 > LINUX-a.local.ntp: NTPv4, Client, length 48
14:47:20.930356 IP LINUX-a.local.ntp > 192.168.1.20.54090: NTPv4, Server, length 48
14:47:21.892006 IP 192.168.1.20.60816 > LINUX-a.local.ntp: NTPv4, Client, length 48
14:47:21.892114 IP LINUX-a.local.ntp > 192.168.1.20.60816: NTPv4, Server, length 48

NTP server works fine. Why does node1's NTP packet reach NTP server; but NTP update failed?



Cause:
When the revenue port is used as the output interface, node1's RE is not active; the NTP reply packet's destination is 192.168.1.20 (which is node1 NTP request's source interface). This packet will come to node0's RE and not node1.

Refer to the following data path:
  node0                   node1
Active RE                inactive RE
PFE in SPC-------fab-----PFE in SPC
Reth0
  • For node0's NTP packet path: node0 RE's ntpd--node0's PFE --Reth0, packet return path: Reth0--node0's PFE--node0's RE

  • For node1's NTP packet path: node1 RE's ntpd--node1's PFE --fab--node0's PFE--Reth0, packet return path: Reth0--node0's PFE--node0's RE

  • For node1's syslog packet path: node1 RE's rtlogd--node1's PFE--fab--node0's PFE--Reth, packet return path: there is no return packet

From the node1's NTP packet path, you can find that the NTP reply packets come to node0's RE, as node1 uses reth0's IP as the NTP request's source address. Node1 will never receive the NTP reply packets. The same result occurs for ICMP and other services. However, for the syslog packet, there is no need to receive reply packets; so It works fine.
Solution:
This is by design. When there is no FXP interface, node1 will send packets according to the forwarding-table, which is synced from node0 .So, node1 will use node0's interface as the source interface to access the server; whether reth or physical interfaces. The solution is to configure node0/node1's FXP interfaces and backup router. 
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search