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.
node0----------------------------------------node1 | reth0 192.168.1.20 | reth0 ------------------------Switch---------------------- | ntp/syslog server 192.168.1.100
root@SRX1400-A# show system syslog host 192.168.1.100 { any warning; } root@SRX1400-A# show system ntp server 192.168.1.100;
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
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
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
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
node0 RE's ntpd--node0's PFE --Reth0, packet return path: Reth0--node0's PFE--node0's RE
node1 RE's ntpd--node1's PFE --fab--node0's PFE--Reth0, packet return path: Reth0--node0's PFE--node0's RE
node1 RE's rtlogd--node1's PFE--fab--node0's PFE--Reth, packet return path: there is no return packet
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.