Just wondering If anyone could give me pointers on NTP configuration. What I want to do is have two routers at our central site pointing to ntp servers on the web. I then want most other routers and switches on the wan getting there time from one of the routers at the central site. This seems to work ok with the
"ntp peer" statement on the routers at the central site to the ntp servers on the web and the
"ntp server" statement on the routers across the wan that need to retreive the time from the routers at the central site.
Is this the right way to go about this or is there a better way. There is an exception to what i have said and this is where it falls down a little, one of the remote sites is a bit of a hub with spokes and I need this to retreive the time from the routers at the central site but also act as an ntp server for the spoke sites.
You have the right idea using a hierarchy to distribute time information around your network. It's a good idea to reduce load on your links to the Internet and to reduce load on the public NTP servers, which are shared community resources.
I would suggest using 'ntp server' to the public NTP servers. Pick two stratum 2 public NTP servers (you don't need to use stratum 1 servers, and they're already heavily loaded). Set one router to use one as a server, and set your other router to use the other. If they're high-end platforms (7200, 7500, etc) with battery-backed calendars, configure 'ntp update-calendar'. If they have calendars, it might also be appropriate to set 'ntp master 3' to enforce that the router will always provide stratum 3 NTP services even if they lose sync with the clocks on the public Internet.
Configure 'ntp peer' between your two central site routers. This allows them to synchronize with each other, increasing their mutual stability and helping to work out jitter that creeps in from one source or another. Don't use 'ntp peer' unless the relationship is truly a peer one, versus a master/slave relationship that you'll be using for the rest of your network.
Now you have two central routers providing a solid and stable stratum 3 time source (see the URL provided in this thread to explain the stratum concept if you're not clear on how it works). Configure the remainder of your WAN sites with two NTP server statements, pointing to both of the central routers. This provides them redundancy and stability should one of them be unavailable.
You mention you have another downstream hub site. You can configure another level of hierarchy into the network by having its downstreams use it for an NTP server, and having the downstream hub itself use the central routers as NTP servers. However, unless you are severely constrained for bandwidth and have more than 3 or 5 sites hanging off that hub, this is likely an increase in complexity for little benefit. I would advise you to have all sites on your network sync from the central routers unless your network is quite large.
はじめに確認方法Version による Application name の変更について備考参考情報 はじめに本ドキュメントでは Cisco SD-WAN における Policy 上で設定可能な Application を確認する方法について記載しています。 確認方法サポートされている Application name についてはご使用されている vManage へ API を呼び出して確認することが可能です。https://<IP or FQDN>/...
DMVPN (Dynamic Multipoint VPN) Introduced by Cisco in late 2000 is a routing technology you can use to build a VPN network with multiple sites (spokes) without having to statically configure all devices. It’s a “hub and spoke” network, where the spok...
On 24th August 2021, Cisco announced the latest IOS XE release - Cisco IOS XE Bengaluru 17.6.1a
IOS XE 17.6.1a unlocks various routing features and enhancements comprehensively covering different technology segments such as voice, security,...
DMVPN (Dynamic Multipoint VPN) Introduced by Cisco in late 2000 is a routing technology you can use to build a VPN network with multiple sites (spokes) without having to statically configure all devices. It’s a “hub and spoke” network, where th...
SummaryRequirementsConfiguration StepsVerificationFAQTroubleshootingReferences & Tools
In the past when IOS 12.x was hot stuff we used MD5 to authenticate OSPF neighbors. This worked great on ethernet networks because OSPF is a m...