NTP and NAT - NTP

This is a discussion on NTP and NAT - NTP ; Hello, I'm a newbie on NTP, and i would like to know if there is any problem in configuring more than one machine with the same NTP server on a LAN that connects to the internet through a NAT (with ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: NTP and NAT

  1. NTP and NAT

    Hello,



    I'm a newbie on NTP, and i would like to know if there is any problem in
    configuring more than one machine with the same NTP server on a LAN that
    connects to the internet through a NAT (with the same outgoing IP for
    everyone).



    Thank you very much.



    Daniel Guerrero Serrano

  2. Re: NTP and NAT

    >>> In article <5587B1EB0BF882418007350B60425C838E0CE9@techno1.int ranet.techno.com>, dguerrero@ttrends.es (Daniel Guerrero) writes:

    Daniel> Hello, I'm a newbie on NTP, and i would like to know if there is any
    Daniel> problem in configuring more than one machine with the same NTP
    Daniel> server on a LAN that connects to the internet through a NAT (with
    Daniel> the same outgoing IP for everyone).

    They won't be able to sync to you, but you will be able to sync to them.

    H

  3. Re: NTP and NAT

    "Daniel Guerrero" wrote in message
    news:5587B1EB0BF882418007350B60425C838E0CE9@techno 1.intranet.techno.com...
    [...]
    > I'm a newbie on NTP, and i would like to know if there is any problem in
    > configuring more than one machine with the same NTP server on a LAN that
    > connects to the internet through a NAT (with the same outgoing IP for
    > everyone).


    This is not so much an NTP question as a NAT question.

    The usual type of NAT works on UDP and TCP because they have source ports.
    The original source IP address and port are remembered along with the
    translated source IP address and port (on the gateway), and when traffic
    comes back to the translated source IP address and port, the gateway knows
    where the original packet came from, and forwards the return packet to
    that same place.

    So yes, it will work fine. But you can save a hop and all the translating
    by running NTP un-NATted on the gateway. (And the gateway was in fact the
    only place anyone ever questioned my logging timestamps.) Of course, if
    the gateway came out of a blister pack, this may not apply.

    Groetjes,
    Maarten Wiltink



  4. Re: NTP and NAT

    Daniel Guerrero wrote:
    > Hello,
    >
    >
    >
    > I'm a newbie on NTP, and i would like to know if there is any problem i

    n
    > configuring more than one machine with the same NTP server on a LAN tha

    t
    > connects to the internet through a NAT (with the same outgoing IP for
    > everyone).


    As has been answered by others on the list, this is more of a
    network/NAT question than an NTP one, but I'll give a shot at explaining
    anyways.

    You will face two problems, one that is easy to remedy, one that isn't.

    To start with the one that isn't: A lot of the public servers (those in
    the pool) have several kinds of rate limiting to reduce the chances of
    DoS (Denial of Service/Destroy our Sanity) attacks. Many of these can be
    translated to human as "for unknown IP's, allow only 1 sync session per
    given time period". The time period is usually set low enough to let a
    default-configured NTPd to sync normally, but two NTPds communicating
    from what (from the public servers point of view) is a single IP, gives
    you 2 sync sessions within the same period. Best case, one of the
    internal servers get to sync, the other don't. Worst case both of them
    is rejected. This isn't a good thing. The easiest way around this is to
    use two different external servers, or contact the operator of the
    server you want to use and get a special rule. Most server operators are
    rather easy to deal with, especially if you "ask first".

    The second thing, is that ntp through NAT would get a variable latency
    point (since NAT speed of most routers vary with router traffic load).

    This second one can somewhat be remedied, since most routers handle
    static NAT rules a little differently than dynamic ones, and static
    rules tend to not get the same latency addition as dynamic ones. If your
    router is a Cisco, your basic NAT rule may look something akin to the
    following:

    ip nat inside source list RFC1918Out interface FastEthernet1/0 overload

    What you want to add is something like the following:

    ip nat inside source static udp 123
    123 extendable

    This gives you a static route, but has the drawback of exposing your ntp
    server publicly.

    There is however a second option, but it requires a little more thinking.


    If you are running a cisco router with reasonably new IOS, the Cisco
    router itself runs a fairly decent ntp implementation.

    Thus you can set up the router itself to act as an NTPd, set the router
    to sync with your external NTP servers, and add your two internal boxes
    as NTP peers to the Cisco.

    You will have a higher stratum, but it will probably actually be more
    accurate than running it through the nat. (Since the router doesn't need
    to traverse the NAT rules when communicating with the external NTP
    servers, the NAT latency won't add to it), and it will reduce traffic
    overall.

    Just hope I didn't confuse the topic too much.

    //Svein

    --
    Svein Skogen | svein@d80.iso100.no
    Solberg ěstli 9 | PGP Key: 0xE5E76831
    2020 Skedsmokorset | svein@jernhuset.no
    Norway | PGP Key: 0xCE96CE13
    ------------------------+-----------------------------
    msn messenger: | Mobile Phone: +47 907 03 575
    svein@jernhuset.no | RIPE handle: SS16503-RIPE

  5. Re: NTP and NAT

    Svein Skogen wrote:
    > If you are running a cisco router with reasonably new IOS, the Cisco
    > router itself runs a fairly decent ntp implementation.


    This seems obvious, unfortunately it has tended to be wrong. (Things
    might have changed recently though?)

    >
    > Thus you can set up the router itself to act as an NTPd, set the router
    > to sync with your external NTP servers, and add your two internal boxes
    > as NTP peers to the Cisco.


    Cisco's NTP process have very low priority, so the timestamps it gets
    are quite bad, and the resulting NTP accuracy suffers.
    >
    > You will have a higher stratum, but it will probably actually be more
    > accurate than running it through the nat. (Since the router doesn't need
    > to traverse the NAT rules when communicating with the external NTP
    > servers, the NAT latency won't add to it), and it will reduce traffic
    > overall.


    Except that the NAT rule traversal is _much_ higher priority/faster than
    the loacl NTP timestamp. :-(

    Terje

    --
    -
    "almost all programming can be viewed as an exercise in caching"

  6. Re: NTP and NAT

    Terje Mathisen wrote:
    *snip*

    > Except that the NAT rule traversal is _much_ higher priority/faster tha

    n
    > the loacl NTP timestamp. :-(


    I agree that this tends to be the symptom, on routers that A) have a
    high cpu load, and B) have dedicated ASICs for forwarding packets. It's
    not a matter of core priorities, but a matter of the packet forwarding
    being run in what for all effects can be considered a co-processor. On
    smaller routers (which regularly are used in cases such as this with
    only one external IP), with software packet forwarding instead of ASICs,
    the NAT process adds a random delay. From what I've seen, what mostly
    compromises IOS's ntpd, is cheap interface cards. Adding a single
    channelized serial card usually solves the problem. (Don't ask me why,
    I'd rather be cleaning Versatec plotters than trying to explain this...)

    However, for all intents and purposes, I agree with the symptom of
    "packet forwarding having higher priority", since most decent Cisco kit
    offloads this to dedicated circuitry, and given Cisco's habit of
    underpowering their main cpu on any piece of kit that has dedicated
    ASICs, it seems that everything except shoveling packets takes the back
    seat.

    //Svein

    --
    Svein Skogen | svein@d80.iso100.no
    Solberg ěstli 9 | PGP Key: 0xE5E76831
    2020 Skedsmokorset | svein@jernhuset.no
    Norway | PGP Key: 0xCE96CE13
    ------------------------+-----------------------------
    msn messenger: | Mobile Phone: +47 907 03 575
    svein@jernhuset.no | RIPE handle: SS16503-RIPE

  7. Re: NTP and NAT

    Daniel Guerrero wrote:
    > Hello,
    >
    >
    >
    > I'm a newbie on NTP, and i would like to know if there is any problem in
    > configuring more than one machine with the same NTP server on a LAN that
    > connects to the internet through a NAT (with the same outgoing IP for
    > everyone).
    >



    I've done it. It works.

    Normally, you should not have more than one local client per outside
    server. If you need to synch several machines, make one the master that
    synchs to the outside server(s) and have the rest synch to your internal
    server. Many of the stratum one and two servers are staggering under
    the load caused by misconfigured clients, see; e.g.
    http://pages.cs.wisc.edu/~plonka/netgear-sntp/
    and that is by no means the only example. Some of the others can be
    found by googling for "Poul Henning Kamp D-Link" and "Tardis NTP".
    Remember: more than 40% of the population has subnormal intelligence. :-)

    If you are setting up a configuration that requires maximum robustness,
    you would use four internal servers synchronized from a set of seven or
    more external servers. Each internal server would use a different set
    of external servers. Not everyone needs this level of robustness!




  8. Re: NTP and NAT

    On 2007-11-08, Svein Skogen wrote:

    > Daniel Guerrero wrote:
    >
    >> I'm a newbie on NTP, and i would like to know if there is any problem
    >> in configuring more than one machine with the same NTP server on
    >> a LAN that connects to the internet through a NAT (with the same
    >> outgoing IP for everyone).

    >
    > To start with the one that isn't: A lot of the public servers (those in
    > the pool) have several kinds of rate limiting to reduce the chances of
    > DoS (Denial of Service/Destroy our Sanity) attacks. Many of these can be
    > translated to human as "for unknown IP's, allow only 1 sync session per
    > given time period".


    Which is why using a "local master" ntpd makes sense. As an alternative
    make sure that your ntpds are all polling different remote time servers.

    > The second thing, is that ntp through NAT would get a variable latency
    > point (since NAT speed of most routers vary with router traffic load).


    Although the point about variable latency may be technically true, in
    practice your router is unlikely to add significantly to the network
    latency between you and your chosen remote time servers. There is a
    point of diminishing returns ...

    If latency is an issue you really ought to have your own local
    ref-clock.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

+ Reply to Thread