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

Using the EX Switch as an NTP Time source with VRRP enabled

0

0

Article ID: KB16274 KB Last Updated: 15 Dec 2010Version: 2.0
Summary:
This article addresses the issue with EX switches as the NTP time source for other networking devices on Layer 3 interfaces where VRRP is enabled.
Symptoms:



Solution:
VRRP enables hosts on a LAN to make use of redundant routing platforms on that LAN without requiring more than the static configuration of a single default route on the hosts. The VRRP routing platforms share the IP address corresponding to the default route configured on the hosts. At any time, one of the VRRP routing platforms is the master (active) and the others are backups. If the master routing platform fails, one of the backup routing platforms becomes the new master, providing a virtual default routing platform and enabling traffic on the LAN to be routed without relying on a single routing platform. Using VRRP, a backup EX-series switch can take over a failed default switch within few seconds. This is done with minimum VRRP traffic and without any interaction with the hosts.

When NTP is configured on a VRRP enabled interface, the NTP requests from the clients are replied with the real physical ip address of the interface. As the reply contains the source address as the physical IP of the interface, the clients rejects the reply since they were expecting a reply from the VRRP address which is configured as the NTP server. Because of this the clients never gets the NTP offset and is never able to syncronize to the correct time.

The packet capture below, taken on the EX switch, shows that the client 10.0.1.2 is sending its request to the VRRP address 10.0.0.1 but the VRRP master's physical IP, in this case 10.0.0.3 responds to the client's request. The client rejects this response.

14:44:28.378050 In IP truncated-ip - 20 bytes missing! 10.0.1.2.ntp > 10.0.0.1.ntp: NTPv4, Client, length 48

14:44:28.378266 Out IP truncated-ip - 20 bytes missing! 10.0.0.3.ntp > 10.0.1.2.ntp: NTPv4, Server, length 48

The VRRP address should not be used as an NTP source or destination for accurate time. The phase locked loops used by NTP to elimnate the jitter due to normal network latency may not work properly if the time delay due to the vrrp master address is asymmetric as to delay with regards to the time to return to the peer. In a non-stable network, where the VRRP master election is performed many number of times at a given period, the NTP association is actually being bounced between different physical routers with potentially different ideas as to the current time for NTP.

Due to this the NTP server is not supported for VRRP Virtual IP addresses



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