Reset Search
 

 

Article

How to Configure NTP Support over VIP of VRRP

« Go Back

Information

 
TitleHow to Configure NTP Support over VIP of VRRP
Objective
To Configure NTP Support over VIP of VRRP. NTP Support over Virtual IP of VRRP is a new feature as of EXOS 15.3. This feature request adds the ability for SNTP clients to use VRRP’s Virtual IP address to obtain time information. The NTP server, when configured on the VRRP master, will listen on the physical and virtual IP address for SNTP clients on the network.
 
Environment
EXOS 15.3 and greater
Procedure
Accept-mode is off by default. When turned on, traffic other than ping packets, neighbor solicitations and advertisements are exchanged between VRRP members. This will allow time information to be collected from the Virtual IP.

In the following example, we have two switches participating in VRRP and a separate switch as an SNTP client.

For this feature to work accordingly, the VRRP accept-mode will need to be turned on.
 
configure vrrp vlan <vlan_name> vrid <vridval> accept-mode [on | off]
NTP over VIP of VRRP
The VRRP master and backup switches are configured with the VIP of 11.11.11.11 and have accept-mode turned on. The NTP XMOD is installed and servers are configured for external timeservers.
 
* (Software Update Required) SW1.158 # sh vrrp detail
VLAN:  npi      VRID:  1        VRRP:  Enabled  State:  MASTER
Virtual Router:  VR-Default
Priority:  100(backup)  Advertisement Interval:  1 sec
Version: v3-v2  Preempt:  Yes   Preempt Delay: 0 sec
Virtual IP Addresses:
11.11.11.11
Accept mode:  On
Tracking mode:  ALL
Tracked Pings:  -
Tracked IP Routes:  -
Tracked VLANs:  -
 
* (Software Update Required) sw1.156 # sh ntp server
Name                      IP Address    Type      Flags  Key Index
==================================================
0.us.pool.ntp.org         66.225.61.66         Server    -      -
1.us.pool.ntp.org         209.114.111.1        Server    -      -
2.us.pool.ntp.org         149.20.68.17         Server    -      -
3.us.pool.ntp.org          96.44.142.5          Server    -      -
 
* (Software Update Required) SW1.159 # sh ntp
NTP                 : Enabled
Authentication      : Disabled
Broadcast-Client    : Disabled

The SNTP client is enabled and configured to obtain time information through the Virtual IP address. The following output shows valid results.
(Software Update Required) Client.180 # sh sntp
SNTP client is enabled
SNTP time is valid
Primary server:11.11.11.11  VR-Default
Secondary server:
Broadcasts: VR-Mgmt
Query interval:64
Last valid SNTP update: From server:11.11.11.11, on Fri Nov 9 12:37:06 2012

If we turn off accept mode, the time information will not be available to the SNTP client through the Virtual IP address. The following shows those results.
 
(Software Update Required) Client.183 # sh sntp
SNTP client is enabled
SNTP time is not valid
Primary server:11.11.11.11  VR-Default
Secondary server:
Broadcasts: VR-Mgmt
Query interval:64
Last valid SNTP update: From server:11.11.11.11, on Fri Nov 9 14:43:30 2012
 
SNTPC Statistics:
Packets transmitted:
  to primary server:            2828
  to secondary server:          0
Packets received with valid time:
  from Primary server:          2634
  from Secondary server:        0
  from Broadcast server:        0
Packets received without valid time:
  from Primary server:          13
  from Secondary server:        0
  from Broadcast server:        0
Replies not received to requests:
  from Primary server:          181
  from Secondary server:        0
 
We will also see the ‘Replies not received to requests’ counter increase since the time information cannot be found on the Virtual IP address.
The above provides redundancy for NTP if either VRRP member was to fail. We also have the additional multiple NTP server redundancy and the option to listen on a secondary server for the SNTP clients on the network.
 
  • The Accept-mode syntax is available as of EXOS 12.7.
  • The NTP XMOD is required for the switch to act as an NTP server. This feature was available as of EXOS 12.7.
  • The problem may be more acute if we have a node connected to VRRP peers using MLAG and VRRP is in active-active mode. In this case, there is a theoretical possibility that every other packet can be sent to a different switch due to LAG hashing at the remote node.  NTP sequencing is important and can lead to non-validation when servers are not synchronized or if the delay is asymmetric.
  • An NTP Server and SNTP client is not recommended to be configured on the same switch.
Additional notes
Please view the following article for general NTP configuration:
How to Configure NTP on EXOS switch?



 

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255