Saturday, August 08, 2015

Using a juniper SRX router as ntp proxy

I am in a Juniper router mood since last week, so we will talk about another quick and easy project: ntp proxy. I know that before I have said a given article would be fast and easy and it ended up longer than planned, but I feel lucky today!

Just to let you know, this post is really not about how to do the deed, but why.

The reason we want to use the router, uranus, as ntp proxy is that the vlans we care about for this discussion have to go through it to get somewhere else. So, if they have to see uranus every day, they might as well do something with it. Why not tell them their ntp server is the router as seen in their network, letting then the router talk to the actual ntp server?

The Steps

  1. Get the name of the ntp servers you want to use. We'll be lazy and use pool.ntp.org as primary server for now. Before you ask, yes we could have used an internal ntp server by just providing its hostname or IP.
  2. Set them
    set time-zone America/New_York
    set system ntp server pool.ntp.org version 4 prefer
    set system ntp boot-server pool.ntp.org
    

    boot-server is the default ntp server to use when the router is booted. server is one of the other ntp servers to pick if the boot-server does not like us anymore; we can have more than one here.

    We should end up with something like this

    system {
        ntp {
            boot-server 198.55.111.50;
            server 198.110.48.12 version 4;
        }
    }
    Note that even though we enter pool.ntp.org for both boot-server and server, the IPs used are different. All that means is that, as the name hints at, pool.ntp.org is a pool of machines. Every time the router resolves pool.ntp.org it might get a different IP.
  3. Check. We could see how off we are
    janitor@uranus# run show system uptime | match current
    Current time: 2015-08-06 12:33:56 EDT
    janitor@uranus#
    
    Or be a bit more blunt:
    janitor@uranus> show ntp associations
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    *time01.muskegon 204.9.54.119     2 -  706 1024  377   60.728   -4.806   2.384
    
    janitor@uranus>
    I don't know about you but that sure reminds me of the output of ntpq -p. If we need more verbose, we could say
    janitor@uranus> show ntp status
    status=06c4 leap_none, sync_ntp, 12 events, event_peer/strat_chg,
    version="ntpd 4.2.0-a Wed Apr 23 21:04:45 UTC 2014 (1)",
    processor="octeon", system="JUNOS12.1X45-D25.1", leap=00, stratum=3,
    precision=-17, rootdelay=70.394, rootdispersion=85.850, peer=10620,
    refid=198.110.48.12,
    reftime=d96e9a76.c04e615d  Thu, Aug  6 2015 22:46:14.751, poll=10,
    clock=d96ea14a.a9c6ff3a  Thu, Aug  6 2015 23:15:22.663, state=4,
    offset=-2.422, frequency=17.545, jitter=1.532, stability=0.115
    
    janitor@uranus>

Well, we got it running, but what about the ntp server choice we made? Ideally we might want to run our own ntp server, ntp.example.com, which then can be configured in the router, say

set system ntp server pool.ntp.org version 4 prefer
set system ntp server pool.ntp.org version 4 prefer
set system ntp boot-server ntp.example.com
Which would make ntp.example.com as the primary and would pick two servers off pool.ntp.org as failovers. However, what counts int he end of the day is that we are using uranus to abstract ntp to the ntp clients. As a result, they will be in sync so Kerberos and derivatives will be happy. So to show I am not lying, here is what my desktop thinks the ntp server is:
raub@desktop:~$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*uranus.example. 198.110.48.12    3 u  950 1024  377    3.519    0.043   1.605
raub@desktop:~$
As you can see, it does like uranus. Since it is so easy to change it (you can even push the changes using ansible) without having to reconfigure the ntp clients (they only have to reach uranus, why not just setup the ntp proxy thingie on uranus against an external source to get your network up and running and then worry about having a ntp.example.com later on? Pick your battles!

References

No comments: