[j-nsp] [c-nsp] NTP Sources placement in MPLS network

Jared Mauch jared at puck.nether.net
Tue Nov 19 19:32:05 EST 2013


On Nov 19, 2013, at 6:01 PM, Yham <yhameed81 at gmail.com> wrote:

> Hi Mark, Jared,
> 
> Do you really think enabling NTP service on routers can burdening them. I mean in hierarchical way where RR and directly connected with ntp sources and then all PEs use RR as ntp master and CEs further down use PEs as NTP master?

Everything you ask a router to do burdens it, including adding new prefixes, increasing traffic through natural growth and other things.

The actual impact will clearly depend on the platforms involved.  As both Cisco & Juniper-NSP are copied, it's hard to give you an accurate statement as each vendor does something different.

> 
> Jared,
> 
> Quick question, why you think anycast IP on NTP servers is better then configuring multiple individual servers on devices. One advantage of anycast i can think is since (i believe) device choose ntp that has better stratum and if its same it choose ntp who respond first if multiple ntp servers are configured so if anycast ip is used, device will reach only to closest device.

There's many reasons why.  I didn't say it was better, I said what we were doing. :)

but here's a list of reasons:

1) If you're not already doing centralized control of devices/configs, using the same IP address will minimize the impact should the host change.

2) Most places don't do #1, infact they often find devices they have no access to, must password recover it, don't have SNMP stats, netflow, CPU usage, or any other useful data.

> I try to read about ntp with anycast ip and found a doc that talk about some risk that i couldn't understand. below is the snippet and source. can you please comment on this please?
> 
> "NTP will also normally work with Anycast. A small risk with NTP is that it generally requires 
> at least two packets from both server and client to get a proper synchronization. If the server 
> fails after the first packet, it will take an extra packet to synchronize with the next available NTP 
> server. The Simple Network Time Protocol (SNTP) does not have this problem."

Sure, this depends on how you operate your network.  If you do per-packet load balancing this may happen if you don't have an ECMP path.  The same is true if you improperly use a load balancer or other devices.  Many technology can be used well, often it's used until it "just works".  I'm sure everyone on-list has a story of getting things to the point of "just working" then leave it alone without truly understanding what they fixed, or what was truly different.

Perhaps you're perfect and using perfect software and didn't see anything like that, but I see it all the time.  You just optimize based on what is deployable and feasible.  If you have every device fully under your control, in configuration management and proper tools to audit and template then you can deploy something else.

Whenever possible: Template, Automate and use existing tools to audit.

- Jared

> 
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.116.6367&rep=rep1&type=pdf
> page-8
> 
> Regards
> 
> Regards
> 
> 
> On Tue, Nov 19, 2013 at 10:31 AM, Mark Tinka <mark.tinka at seacom.mu> wrote:
> On Tuesday, November 19, 2013 02:02:43 PM Jared Mauch wrote:
> 
> > We have servers in each location with NTP synced to local
> > stratum 1 or 2 clocks. Customers are given an anycast ip
> > that points to these for time sources. We configure
> > routers to point at these local sources.
> 
> Agree - better to put that on servers running than burdening
> routers with NTP functionality in addition to other daily
> tasks.
> 
> Mark.
> 




More information about the juniper-nsp mailing list