[ntp:questions] NTP over redundant peer links, undetected loops
Hi! We are trying to implement a NTP installation over a redundant network, connecting the stratum 2 servers to the stratum 3 clients. The precise situation is the following (compare with http://1stein.org/download/network.png): 3 networks, 192.168.3.0, 192.168.4.0, 192.168.5.0 ATOM1, ATOM2 - stratum 1 servers in network 3 GW1, GW2 - stratum 2 servers in all networks, i.e. 3, 4, 5 CLIENT1...CLIENTn - stratum 3 clients in network 4 and 5 Our goal is that GW1 and GW2 are always synchronized, even - if network 3 goes down, - or if one of networks 4 or 5 goes down, - or if the worst case happens that network 3 and 4 (or 5) go down and only one link is left between GW1, GW2 and the clients. We have configured the hosts in the following way: GW1 - with two IPs GW1_4, GW1_5 server 127.127.1.0 fudge stratum 5 server ATOM1 server ATOM2 peer GW2_4 peer GW2_5 GW2 - with two IPs GW2_4, GW2_5 server 127.127.1.0 fudge stratum 10 server ATOM1 server ATOM2 peer GW1_4 peer GW1_5 CLIENT1 ... CLIENTn server GW1 server GW2 The problem: If network 3 goes down, GW1 and GW2 select each other as their reference clock, one over network 4, one over network 5. The loop detection does not work here. The stratum of both references goes up poll by poll, until it reaches 16. Then one of GW1/GW2, say GW1, switches to the LOCAL(0) source. After the new stratum of GW1 propages to GW2 and back to GW1 (as stratum 7), GW1 switches back to GW2, even though the local clock's stratum is smaller. Then the game starts again that the stratum goes up by propagation. Solution 1: By removing one peer connection, we are able to remove the possible loop and it starts working, obviously by loosing some of the redundancy in network 4 and 5 which we do not want. Solution 2: We can also remove all peer statements and put "server GW1_4" and "server GW1_5" in GW2's config. But then we are lost if ATOM1 and ATOM2 are out of sync, because then it can happen that GW1 syncs to ATOM1 and GW2 to ATOM2, such that GW1 and GW2 are out of sync. But the latter _must not_ happen. Is there a way to tell xntpd to identify the IPs GW1_4, GW1_5 and GW2_4, GW2_5 such that the loop detection works? Can one force to use a common refid instead of the IP? Regards Stefan Schimanski ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
Stefan Schimanski wrote: > Hi! > > We are trying to implement a NTP installation over a redundant > network, connecting the stratum 2 servers to the stratum 3 clients. > The precise situation is the following (compare with > http://1stein.org/download/network.png): > > 3 networks, 192.168.3.0, 192.168.4.0, 192.168.5.0 > ATOM1, ATOM2 - stratum 1 servers in network 3 > GW1, GW2 - stratum 2 servers in all networks, i.e. 3, 4, 5 > CLIENT1...CLIENTn - stratum 3 clients in network 4 and 5 I did quite a bit of work while setting up a big corporate network, with dual servers, one of which had a Motorola Oncore UT+, in each of three geographically distributed locations. I had similar plans like you, wanting to setup two or three layers of servers, but then I realized that this was totally superfluous! We had less than 40K server and client machines worldwide, so even if every single one of them configured all 6 primary servers, the resulting load would be negligible, the timing results would be optimal, and so would the redundancy level. The icing on the cake is that I don't need to consider where a client machine is located, I simply tell everyone to use exactly the same configuration file, with one exception: The core/root DNS servers (as well as DHCP servers and some other network gear) use the same six servers, but they use the IP addresses directly instead of the DNS names. Terje -- - "almost all programming can be viewed as an exercise in caching" ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
Stefan Schimanski wrote: > > Is there a way to tell xntpd to identify the IPs GW1_4, GW1_5 and > GW2_4, GW2_5 such that the loop detection works? Can one force to use > a common refid instead of the IP? > I've had only my list of things to do to use only one refid per system rather than based on the IP based being used. I've encountered resistance in two directions, from users who want to have the refid tell them who the parent is, and on the other side Dave who doesn't want to make a change. Danny > Regards > Stefan Schimanski ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
On Feb 13, 2:50 am, ma...@ntp.org (Danny Mayer) wrote: > > I've had only my list of things to do to use only one refid per system > rather than based on the IP based being used. This certainly seems like a winning idea in terms of loop detection. If you do something like this, it would be nice if without extra configuration RFC1918 addresses would tend to not be used as refids (like unless the only unicast IPv4 address available is RFC1918. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
Dave Hart wrote: > On Feb 13, 2:50 am, ma...@ntp.org (Danny Mayer) wrote: >> I've had only my list of things to do to use only one refid per system >> rather than based on the IP based being used. > > This certainly seems like a winning idea in terms of loop detection. > If you do something like this, it would be nice if without extra > configuration RFC1918 addresses would tend to not be used as refids > (like unless the only unicast IPv4 address available is RFC1918. I fail to see what RFC1918 addresses have to do with it. There's always likely to be a mixture of public/private addresses in an ntp configuration and I see no point in preferring one over the other. In addition this ignores the IPv6 addresses and it is intended to tackle that issue as well. It would be better if these were just a generated 32-bit random number created at startup which is kept for the lifetime of the server. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
On Feb 15, 4:13 pm, ma...@ntp.org (Danny Mayer) wrote: > Dave Hart wrote: > > On Feb 13, 2:50 am, ma...@ntp.org (Danny Mayer) wrote: > >> I've had only my list of things to do to use only one refid per system > >> rather than based on the IP based being used. > > > This certainly seems like a winning idea in terms of loop detection. > > If you do something like this, it would be nice if without extra > > configuration RFC1918 addresses would tend to not be used as refids > > (like unless the only unicast IPv4 address available is RFC1918. > > I fail to see what RFC1918 addresses have to do with it. There's always > likely to be a mixture of public/private addresses in an ntp > configuration and I see no point in preferring one over the other. RFC1918 addresses are of course not globally unique, so are particularly ill-suited to a reference ID used for loop detection. > In > addition this ignores the IPv6 addresses and it is intended to tackle > that issue as well. It would be better if these were just a generated > 32-bit random number created at startup which is kept for the lifetime > of the server. Why play roulette if you have a globally unique IPv4 address to use as a refid? Since IPv6 addresses are hashed down to 32 bits if used as a refid, again, IPv4 global addresses if available are better unique identifiers. Cheers, Dave hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
Dave Hart wrote: > On Feb 15, 4:13 pm, ma...@ntp.org (Danny Mayer) wrote: >> Dave Hart wrote: >>> On Feb 13, 2:50 am, ma...@ntp.org (Danny Mayer) wrote: I've had only my list of things to do to use only one refid per system rather than based on the IP based being used. >>> This certainly seems like a winning idea in terms of loop detection. >>> If you do something like this, it would be nice if without extra >>> configuration RFC1918 addresses would tend to not be used as refids >>> (like unless the only unicast IPv4 address available is RFC1918. >> I fail to see what RFC1918 addresses have to do with it. There's always >> likely to be a mixture of public/private addresses in an ntp >> configuration and I see no point in preferring one over the other. > > RFC1918 addresses are of course not globally unique, so are > particularly ill-suited to a reference ID used for loop detection. > >> In >> addition this ignores the IPv6 addresses and it is intended to tackle >> that issue as well. It would be better if these were just a generated >> 32-bit random number created at startup which is kept for the lifetime >> of the server. > > Why play roulette if you have a globally unique IPv4 address to use as > a refid? Since IPv6 addresses are hashed down to 32 bits if used as a > refid, again, IPv4 global addresses if available are better unique > identifiers. > Because I want to get away from the notion that these are meant to be IP addresses. In addition in an IPv6-only environment that wouldn't work either. Why create work when it's unnecessary just to find a valid IP address? In addition with anycast addresses are not globally unique. The chances that you will create a non-unique random number within a network is extremely low. Danny > Cheers, > Dave hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
On Sun, Feb 15, 2009 at 12:23 PM, Danny Mayer wrote: > > Because I want to get away from the notion that these are meant to be IP > addresses. In addition in an IPv6-only environment that wouldn't work > either. Why create work when it's unnecessary just to find a valid IP > address? In addition with anycast addresses are not globally unique. The > chances that you will create a non-unique random number within a network > is extremely low. It depends on the size of the network. The chances of a duplicate 32-bit number on a network including 65000 hosts is about 40%. The NTP Pool network, which comprises at least 10^6 hosts, for example, would have collision probability very close to 1. -- RPM ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
On Feb 15, 6:23 pm, ma...@ntp.org (Danny Mayer) wrote: > Dave Hart wrote: > > Why play roulette if you have a globally unique IPv4 address to use as > > a refid? Since IPv6 addresses are hashed down to 32 bits if used as a > > refid, again, IPv4 global addresses if available are better unique > > identifiers. > > Because I want to get away from the notion that these are meant to be IP > addresses. Well, hash it. As long as your hash is good, it the result should be as unique as the non-rfc1918, non-multicast, non-loopback IPv4 address. It breaks ntptrace and yes I know ntptrace is broken for IPv6 as well. Looking at the loop detection functionality, a hashed unique IPv4 address is good as is the unmangled address. Since there's a small installed base using IPv4 addresses now (and hashed IPv6), it might not be a good idea to change horses midstream. > In addition in an IPv6-only environment that wouldn't work > either. I have no idea why preferring any non-RFC1918 IPv4 address over any RFC1918 IPv4 address when selecting a refid would have any impact whatsoever in an IPv6-only environment, where today and presumably tomorrow your 32-bit refid would derive from one of your more unique IPv6 addresses. > Why create work when it's unnecessary just to find a valid IP > address? Maybe it's not worth doing anything special about widely-shared private IPv4 addresses. If loop detection is all that matters, who cares about a few false positives? Nowhere near as harmful as false negatives. > In addition with anycast addresses are not globally unique. Anycast is worse than useless for NTP. Non-issue. > The > chances that you will create a non-unique random number within a network > is extremely low. nodes in network times one in two billion, or one in four billion, assuming a perfect PRNG. But why gamble? Global IPv4 addresses work today and are more than unique enough. Same with IPv6 addresses using a consistent hash. RFC1918 addresses, as I said, at worst lead to false positive loop detection and therefore reduce the server choice for the victim, not exactly the kind of thing that causes riots either way. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
In article <5d7f07420902151105m48a5e210s72e8e168e67d1...@mail.gmail.com>, malay...@gmail.com (Ryan Malayter) wrote: > On Sun, Feb 15, 2009 at 12:23 PM, Danny Mayer wrote: > > > > Because I want to get away from the notion that these are meant to be IP > > addresses. In addition in an IPv6-only environment that wouldn't work > > either. Why create work when it's unnecessary just to find a valid IP > > address? In addition with anycast addresses are not globally unique. The > > chances that you will create a non-unique random number within a network > > is extremely low. > > It depends on the size of the network. The chances of a duplicate > 32-bit number on a network including 65000 hosts is about 40%. The NTP > Pool network, which comprises at least 10^6 hosts, for example, would > have collision probability very close to 1. How did you compute that? Given that 2^32= ~4*10^9, it's hard to see how 10^6 hosts spread at random in a 10^9 codespace could achieve 100% collision probability. Joe Gwinn ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
Joseph Gwinn wrote: >> It depends on the size of the network. The chances of a duplicate >> 32-bit number on a network including 65000 hosts is about 40%. The NTP >> Pool network, which comprises at least 10^6 hosts, for example, would >> have collision probability very close to 1. > > How did you compute that? Given that 2^32= ~4*10^9, it's hard to see > how 10^6 hosts spread at random in a 10^9 codespace could achieve 100% > collision probability. The Birthday Paradox. Google it! As soon as you have approx sqrt(N) samples out of universe of N values, the chance of at least one collision breaks 50%. As soon as you get significantly past that sqrt(N) number, i.e. 64K IP addresses, you pass that 50% chance. With 1e6 random 32-bit numbers the odds are so close to 100% as makes no difference at all. Terje -- - "almost all programming can be viewed as an exercise in caching" ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
>> How did you compute that? Given that 2^32= ~4*10^9, it's hard to see >> how 10^6 hosts spread at random in a 10^9 codespace could achieve 100% >> collision probability. > >The Birthday Paradox. Google it! > >As soon as you have approx sqrt(N) samples out of universe of N values, >the chance of at least one collision breaks 50%. > >As soon as you get significantly past that sqrt(N) number, i.e. 64K IP >addresses, you pass that 50% chance. > >With 1e6 random 32-bit numbers the odds are so close to 100% as makes no >difference at all. That assumes all machines are talking to all others. It the pool context, we have nowhere near that much connectivity. With a million machines, the birthday game would have 1M*1M/2 connections. ntp/pool has 1M*3 connections. They differ by a factor of ballpark 100K. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
Ryan Malayter wrote: > On Sun, Feb 15, 2009 at 12:23 PM, Danny Mayer wrote: >> Because I want to get away from the notion that these are meant to be IP >> addresses. In addition in an IPv6-only environment that wouldn't work >> either. Why create work when it's unnecessary just to find a valid IP >> address? In addition with anycast addresses are not globally unique. The >> chances that you will create a non-unique random number within a network >> is extremely low. > > It depends on the size of the network. The chances of a duplicate > 32-bit number on a network including 65000 hosts is about 40%. The NTP > Pool network, which comprises at least 10^6 hosts, for example, would > have collision probability very close to 1. > You need to understand what loop prevention is. In any case I very much doubt that there are a million hosts in the pool. Loop prevention won't be affected by choosing no more than say 10 hosts in the pool. That's the maximum number that the pool configuration option selects. In a network of 65000 hosts you will not have more than three or four selected at the same stratum level. If they are not at the same level then you don't have to worry about loop detection. You are reading far too much into the statistics of something where they don't really apply. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
Dave Hart wrote: > On Feb 15, 6:23 pm, ma...@ntp.org (Danny Mayer) wrote: >> Dave Hart wrote: >>> Why play roulette if you have a globally unique IPv4 address to use as >>> a refid? Since IPv6 addresses are hashed down to 32 bits if used as a >>> refid, again, IPv4 global addresses if available are better unique >>> identifiers. >> Because I want to get away from the notion that these are meant to be IP >> addresses. > > Well, hash it. As long as your hash is good, it the result should be > as unique as the non-rfc1918, non-multicast, non-loopback IPv4 > address. It breaks ntptrace and yes I know ntptrace is broken for > IPv6 as well. Looking at the loop detection functionality, a hashed > unique IPv4 address is good as is the unmangled address. Since > there's a small installed base using IPv4 addresses now (and hashed > IPv6), it might not be a good idea to change horses midstream. > No, generating a random RefID is sufficient. There's no work on figuring out IP addresses or anything else. ntptrace it turns out is fundamentally broken since it is using the refid to do its work and that's wrong. I took at look at both John Hay's code and Jeff Mogul's code and they are both wrong. I would have expected Jeff's code at least to be correct. I assume that Glenn also got it wrong since Jeff got the idea from Glenn. >> In addition in an IPv6-only environment that wouldn't work >> either. > > I have no idea why preferring any non-RFC1918 IPv4 address over any > RFC1918 IPv4 address when selecting a refid would have any impact > whatsoever in an IPv6-only environment, where today and presumably > tomorrow your 32-bit refid would derive from one of your more unique > IPv6 addresses. > >> Why create work when it's unnecessary just to find a valid IP >> address? > > Maybe it's not worth doing anything special about widely-shared > private IPv4 addresses. If loop detection is all that matters, who > cares about a few false positives? Nowhere near as harmful as false > negatives. Exactly. That's why bothering with all that extra work that you are suggesting isn't worth the effort. > >> In addition with anycast addresses are not globally unique. > > Anycast is worse than useless for NTP. Non-issue. > All Anycast nodes that I know of (mainly DNS root servers) all run ntp but I have always strongly emphasised that getting NTP time from any of them is a really bad idea. >> The >> chances that you will create a non-unique random number within a network >> is extremely low. > > nodes in network times one in two billion, or one in four billion, > assuming a perfect PRNG. But why gamble? Global IPv4 addresses work > today and are more than unique enough. Same with IPv6 addresses using > a consistent hash. RFC1918 addresses, as I said, at worst lead to > false positive loop detection and therefore reduce the server choice > for the victim, not exactly the kind of thing that causes riots either > way. > No. Don't bother with all the extra work. There's no benefit to doing so. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
Joseph Gwinn wrote: > In article > <5d7f07420902151105m48a5e210s72e8e168e67d1...@mail.gmail.com>, > malay...@gmail.com (Ryan Malayter) wrote: > >> On Sun, Feb 15, 2009 at 12:23 PM, Danny Mayer wrote: >>> Because I want to get away from the notion that these are meant to be IP >>> addresses. In addition in an IPv6-only environment that wouldn't work >>> either. Why create work when it's unnecessary just to find a valid IP >>> address? In addition with anycast addresses are not globally unique. The >>> chances that you will create a non-unique random number within a network >>> is extremely low. >> It depends on the size of the network. The chances of a duplicate >> 32-bit number on a network including 65000 hosts is about 40%. The NTP >> Pool network, which comprises at least 10^6 hosts, for example, would >> have collision probability very close to 1. > > How did you compute that? Given that 2^32= ~4*10^9, it's hard to see > how 10^6 hosts spread at random in a 10^9 codespace could achieve 100% > collision probability. > > Joe Gwinn Lying with statistics is very easy especially given that you are going to use no more than about 10 servers for your own server and they all need to be at the same stratum. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
"Dave Hart" wrote in message news:3a359156-5610-4c6c-8d4f-6f7fbab96...@x11g2000pro.googlegroups.com... > RFC1918 addresses are of course not globally unique, so are > particularly ill-suited to a reference ID used for loop detection. [...] > Why play roulette if you have a globally unique IPv4 address to use > as a refid? ... You do? Lucky you. RFC1918 addresses are all I have[0], except for the one address on the outside of my modem, which of them all is the _least_ suitable because it's the one place in my network where I don't have, nor currently want, NTP service[1]. RFC1918 addresses may not be globally unique, but they are also not routeable, so within any given network they _will_ be unique. While multi-homed hosts may seem to be a counter-example, living as they do on several networks at the same time, I think they still need unambiguous network addresses around them. Groetjes, Maarten Wiltink [0] Well, except for 127.0.0.1, but I'm not suggesting we use that. [1] I do think that the Pool is a great idea, though. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
On Feb 16, 8:56 am, "Maarten Wiltink" wrote: > "Dave Hart" wrote in message > > > RFC1918 addresses are of course not globally unique, so are > > particularly ill-suited to a reference ID used for loop detection. > [...] > > Why play roulette if you have a globally unique IPv4 address to use > > as a refid? ... > > You do? Lucky you. RFC1918 addresses are all I have[0], except for > the one address on the outside of my modem, which of them all is the > _least_ suitable because it's the one place in my network where I > don't have, nor currently want, NTP service[1]. I said if. My original comment was if you're going to use a single refid for the NTP host instead of using its interface address as refid (meaning same server has different refid depending on which of its interfaces you approach it via), prefer apparent unicast global IPv4 addresses over RFC1918 when selecting from several IPv4 addresses which to use as refid. Which got Danny going again on his ntptrace breaking spree saying refids are not IPv4 addresses and picking a random number at startup is the wise way forward. > RFC1918 addresses may not be globally unique, but they are also not > routeable, so within any given network they _will_ be unique. It is good to have a bit of lighthearted humor in these technical discussions. > While > multi-homed hosts may seem to be a counter-example, living as they > do on several networks at the same time, I think they still need > unambiguous network addresses around them. Sounds like a fine goal. Multi-homed hosts are more than a counter- example, they were the very reason I suggested preferring non-RFC1918 when choosing a machine-wide ntpd refid, assuming as I was that one of several IPv4 addresses would be used. Many servers, for example, have a management network separate from their service access network. No problem today running ntpd, but if you change ntpd to use the same refid across all interfaces, choosing a likely-to-collide RFC1918 address isn't helping anyone. On the nonroutability of RFC1918 addresses, have you ever seen someone try to VPN back to their home network from a hotel network and fail miserably because the hotel network and the home network have conflicting ideas of how to route RFC1918 addresses? Personally, I'm nearly irrational in my hatred for things that break end-to-end communication, determined to avoid, disable, tame, or tunnel around any packet manglers I'm saddled with. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
Dave Hart wrote: > On Feb 16, 8:56 am, "Maarten Wiltink" > wrote: >> "Dave Hart" wrote in message >> >>> RFC1918 addresses are of course not globally unique, so are >>> particularly ill-suited to a reference ID used for loop detection. >> [...] >>> Why play roulette if you have a globally unique IPv4 address to use >>> as a refid? ... >> You do? Lucky you. RFC1918 addresses are all I have[0], except for >> the one address on the outside of my modem, which of them all is the >> _least_ suitable because it's the one place in my network where I >> don't have, nor currently want, NTP service[1]. > > I said if. My original comment was if you're going to use a single > refid for the NTP host instead of using its interface address as refid > (meaning same server has different refid depending on which of its > interfaces you approach it via), prefer apparent unicast global IPv4 > addresses over RFC1918 when selecting from several IPv4 addresses > which to use as refid. Which got Danny going again on his ntptrace > breaking spree saying refids are not IPv4 addresses and picking a > random number at startup is the wise way forward. > >> RFC1918 addresses may not be globally unique, but they are also not >> routeable, so within any given network they _will_ be unique. > > It is good to have a bit of lighthearted humor in these technical > discussions. > >> While >> multi-homed hosts may seem to be a counter-example, living as they >> do on several networks at the same time, I think they still need >> unambiguous network addresses around them. > > Sounds like a fine goal. Multi-homed hosts are more than a counter- > example, they were the very reason I suggested preferring non-RFC1918 > when choosing a machine-wide ntpd refid, assuming as I was that one of > several IPv4 addresses would be used. Many servers, for example, have > a management network separate from their service access network. No > problem today running ntpd, but if you change ntpd to use the same > refid across all interfaces, choosing a likely-to-collide RFC1918 > address isn't helping anyone. > > On the nonroutability of RFC1918 addresses, have you ever seen someone > try to VPN back to their home network from a hotel network and fail > miserably because the hotel network and the home network have > conflicting ideas of how to route RFC1918 addresses? RFC-1918 address are non-routeable by definition! They are intended for PRIVATE networks where the nodes need not be accessible from outside. Generally, any link with the outside must be initiated from inside. (Don't call us, we'll call you!) You can reach your home system from your hotel by addressing the external address of your router and selecting a port that the router will map to something you can talk to and can talk to you. This requires some setup on your router before you leave home! It's necessarily a security hole; if you can get in that way, anyone else can. Passwords and whatnot make it more difficult but not impossible. > Personally, I'm > nearly irrational in my hatred for things that break end-to-end > communication, determined to avoid, disable, tame, or tunnel around > any packet manglers I'm saddled with. > Cling to rationality! It will save you unnecessary trips to the laughing academy! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
On Feb 16, 8:57 pm, "Richard B. Gilbert" wrote: > Dave Hart wrote: > > On the nonroutability of RFC1918 addresses, have you ever seen someone > > try to VPN back to their home network from a hotel network and fail > > miserably because the hotel network and the home network have > > conflicting ideas of how to route RFC1918 addresses? > > RFC-1918 address are non-routeable by definition! They are intended for > PRIVATE networks where the nodes need not be accessible from outside. > Generally, any link with the outside must be initiated from inside. > (Don't call us, we'll call you!) Give me a half-ounce of credit, please. Yes, they are not routable on the global internet. To suggest they are therefore never used by machines with internet routes or never seen except in disconnected islands is a vision from the past in need of a serious reality check. > You can reach your home system from your hotel by addressing the > external address of your router and selecting a port that the router > will map to something you can talk to and can talk to you. This > requires some setup on your router before you leave home! The problem is on the client side of the VPN. I am in hotel NAT cesspool 192.168.1.x, say 192.168.1.101 gateway 192.168.1.1. Now I want to connect up a an IPSEC or PPTP tunnel to my home network, sure I target the single public IP on my router for the VPN connection, but when it comes up my local IP stack has a problem. You see, my network at home is also in the ever-popular 192.168.1.x subnet. Every time I try to send a packet to my desktop machine at 192.168.1.10, my IP stack tries to deliver it to some other hotel NAT cesspool customer, and the packet never makes it to the VPN. There are a million variations possible. Build a B2B link between two companies whose network architects didn't plan in advance for that scenario. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
Dave Hart wrote: > On Feb 16, 8:57 pm, "Richard B. Gilbert" > wrote: >> Dave Hart wrote: >>> On the nonroutability of RFC1918 addresses, have you ever seen someone >>> try to VPN back to their home network from a hotel network and fail >>> miserably because the hotel network and the home network have >>> conflicting ideas of how to route RFC1918 addresses? >> RFC-1918 address are non-routeable by definition! They are intended for >> PRIVATE networks where the nodes need not be accessible from outside. >> Generally, any link with the outside must be initiated from inside. >> (Don't call us, we'll call you!) > > Give me a half-ounce of credit, please. Yes, they are not routable on > the global internet. To suggest they are therefore never used by > machines with internet routes or never seen except in disconnected > islands is a vision from the past in need of a serious reality check. > >> You can reach your home system from your hotel by addressing the >> external address of your router and selecting a port that the router >> will map to something you can talk to and can talk to you. This >> requires some setup on your router before you leave home! > > The problem is on the client side of the VPN. I am in hotel NAT > cesspool 192.168.1.x, say 192.168.1.101 gateway 192.168.1.1. Now I > want to connect up a an IPSEC or PPTP tunnel to my home network, sure > I target the single public IP on my router for the VPN connection, but > when it comes up my local IP stack has a problem. You see, my network > at home is also in the ever-popular 192.168.1.x subnet. Every time I > try to send a packet to my desktop machine at 192.168.1.10, my IP > stack tries to deliver it to some other hotel NAT cesspool customer, > and the packet never makes it to the VPN. There are a million > variations possible. Build a B2B link between two companies whose > network architects didn't plan in advance for that scenario. > I think your problem is that you are trying to use an RFC-1918 address to access your desk top. You must address the packet to your home router's external IP address. Your home router must be configured to map some port on the router to the RFC-1918 address of your desktop. Pick an arbitrary port number greater than 1024 and less than 65536. Configure your router to send all traffic addressed to that port to the RFC-1918 address of your desktop. Let's assume that your router has been configured to send incoming traffic addressed to port 2009 to your desktop. When you connect from outside, you simply send to port 2009 at your external IP address and your router should hand it to your desktop. If the manufacturer of your router offers technical support you may be able to call an 800 number and speak with a technician who can walk you through the process. Be prepared to wait 30 to 60 minutes to talk to a human being who will probably speak accented English. If you are extremely lucky, he will speak with a British accent. Those who learned English in India are more difficult to understand. You may have better luck at the vendor's web site if they have one. Linksys does. Linksys provides a great deal of information on their web site. I have a Linksys router and so have never had occasion to check out the competition. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
On Mon, Feb 16, 2009 at 4:13 PM, Dave Hart wrote: > when it comes up my local IP stack has a problem. You see, my network > at home is also in the ever-popular 192.168.1.x subnet. Every time I > try to send a packet to my desktop machine at 192.168.1.10, my IP > stack tries to deliver it to some other hotel NAT cesspool customer, > and the packet never makes it to the VPN. There are a million > variations possible. Build a B2B link between two companies whose > network architects didn't plan in advance for that scenario. We generally use randomly selected 10.X.X.X subnets for private addresses, which tend to avoid such issues. In fact, we've never had a user or partner with conflicting IP space issues on a VPN since we switched to that scheme almost ten years ago. Everyone seems to use something in the 192.168.0.0/16 space, so we just don't ;-). -- RPM ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
Ryan Malayter wrote: > On Mon, Feb 16, 2009 at 4:13 PM, Dave Hart wrote: > >> when it comes up my local IP stack has a problem. You see, my network >> at home is also in the ever-popular 192.168.1.x subnet. Every time I >> try to send a packet to my desktop machine at 192.168.1.10, my IP >> stack tries to deliver it to some other hotel NAT cesspool customer, >> and the packet never makes it to the VPN. There are a million >> variations possible. Build a B2B link between two companies whose >> network architects didn't plan in advance for that scenario. > > We generally use randomly selected 10.X.X.X subnets for private > addresses, which tend to avoid such issues. In fact, we've never had a > user or partner with conflicting IP space issues on a VPN since we > switched to that scheme almost ten years ago. Everyone seems to use > something in the 192.168.0.0/16 space, so we just don't ;-). This won't solve the OP's problem as I understand it. RFC-1918 prescribes three address families for private networks: 192.168.1.X 172.16.X.Y 10.X.Y.Z The problem is essentially the same for any of the three families. These address families are not routeable. Thousands of private networks can use the same set of addresses BECAUSE they are not routeable. A N.A.T (Network Address Translation) capable router lets RFC-1918 addresses access the Internet by mapping to a valid IP address and port. The router has ONE external address and 65535 ports available. The router can map non-routeable adresses and ports to routeable addresses and ports. My little home network has three PC's running W/2k or W/XP, one PC running Linux, two DEC Alphastations running OpenVMS, three Sun Ultra 10 workstations running Solaris, a small Cisco 1548M eight port switch and a LinkSys BEFSR81 router and eight port switch. All this stuff uses 192.168.1.x. This gives me, potentially, 254 usable but non routable addresses. The ONE routeable address belongs to the internet facing port of my router. All of this stuff can access the outside world if I need it to. The router maps each inside address and port to a port on the one and only routeable address. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
On Feb 16, 10:34 pm, "Richard B. Gilbert" wrote: > Dave Hart wrote: > > The problem is on the client side of the VPN. I am in hotel NAT > > cesspool 192.168.1.x, say 192.168.1.101 gateway 192.168.1.1. Now I > > want to connect up a an IPSEC or PPTP tunnel to my home network, sure > > I target the single public IP on my router for the VPN connection, but > > when it comes up my local IP stack has a problem. You see, my network > > at home is also in the ever-popular 192.168.1.x subnet. Every time I > > try to send a packet to my desktop machine at 192.168.1.10, my IP > > stack tries to deliver it to some other hotel NAT cesspool customer, > > and the packet never makes it to the VPN. There are a million > > variations possible. Build a B2B link between two companies whose > > network architects didn't plan in advance for that scenario. > > I think your problem is that you are trying to use an RFC-1918 address > to access your desk top. You must address the packet to your home > router's external IP address. Your home router must be configured to > map some port on the router to the RFC-1918 address of your desktop. > Pick an arbitrary port number greater than 1024 and less than 65536. > Configure your router to send all traffic addressed to that port to the > RFC-1918 address of your desktop. Let's assume that your router has > been configured to send incoming traffic addressed to port 2009 to your > desktop. When you connect from outside, you simply send to port 2009 at > your external IP address and your router should hand it to your desktop. VPN means Virtual Private Network and it means using one network (usually the internet) as an underlying transport to connect parts of another. The problem I describe is a conflict between the IPs used on the private network I'm connecting to via VPN from my laptop, and the private network addresses used by the, ahem, internet provider. Even though those IPs are not publicly routable, it isn't hard to come up with real-world scenarios where devices see private addresses as well as public and communicate with both. Given the ambiguity of a widely- shared RFC1918 address as a refid, I suggested and still suggest that if ntpd is changed to using a single refid across all interfaces RFC1918 should only be used as last choice. Cheers, Dave Hart Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
"Richard B. Gilbert" wrote in message news:zbsdneivucyrrafunz2dnuvz_oodn...@giganews.com... [...] > This won't solve the OP's problem as I understand it. But this time, that's not the OP's or his problem's fault. > RFC-1918 prescribes three address families for private networks: > 192.168.1.X > 172.16.X.Y > 10.X.Y.Z It does not. Please stop treating Dave Hart as an idiot and spend some productive time rereading RFC1918. While you're at it, find out about CIDR and see if you can figure out that the three ranges are really 192.168.W.X (not just .1.X), 172.16-31.X.Y (not just 172.16), and 10.X.Y.Z. At least you got that last one right. Randomising which subrange you use _does_ solve these routing problems most of the time, just like generating a random host id does solve the undetected loop problem _most of the time_. My home network is on 192.168.27/24. I took the number from my street address. My brother (independently!) picked 53 for his network, by the same mechanism[0]. We have an OpenVPN tunnel between those networks. We have no routing problems. Groetjes, Maarten Wiltink [0] And when they renumbered his house, he renumbered his network. Okay, I wouldn't have done that. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
On Feb 17, 9:01 am, "Maarten Wiltink" wrote: > My home network is on 192.168.27/24. I took the number from my > street address. My brother (independently!) picked 53 for his > network, by the same mechanism[0]. We have an OpenVPN tunnel > between those networks. We have no routing problems. > > [0] And when they renumbered his house, he renumbered his > network. Okay, I wouldn't have done that. I've taken the same approach a couple of times at different addresses with 192.168.address.0/24. I also have a VPN going with my brother. Sadly, his employer requires security software that requires he use 192.168.1.0/24 for his home network to be able to VPN in to work. As a workaround, I've sometimes subnetted a hotel 192.168.1.0/24 hotel address, claiming 192.168.1.2 and using netmask 192.168.1.252, so that when I VPN all but the first few addresses of my brother's network are visible. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
On Mon, Feb 16, 2009 at 9:38 PM, Richard B. Gilbert wrote: > RFC-1918 prescribes three address families for private networks: > 192.168.1.X > 172.16.X.Y > 10.X.Y.Z A quibble, but that is incorrect information. The actual RFC 1918 address spaces are larger: 10.0.0.0- 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) -- RPM ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
"Dave Hart" wrote in message news:03463add-146a-457d-9869-9caddf6f8...@i18g2000prf.googlegroups.com... > On Feb 17, 9:01 am, "Maarten Wiltink" > wrote: >> My home network is on 192.168.27/24. I took the number from my >> street address. My brother (independently!) picked 53 for his >> network, by the same mechanism[0]. We have an OpenVPN tunnel >> between those networks. We have no routing problems. >> >> [0] And when they renumbered his house, he renumbered his >> network. Okay, I wouldn't have done that. > > I've taken the same approach a couple of times at different > addresses with 192.168.address.0/24. I also have a VPN going with > my brother. Sadly, his employer requires security software that > requires he use 192.168.1.0/24 for his home network to be able to > VPN in to work. As a workaround, I've sometimes subnetted a hotel > 192.168.1.0/24 hotel address, claiming 192.168.1.2 and using netmask > 192.168.1.252, so that when I VPN all but the first few addresses of > my brother's network are visible. Scary. You _are_ me. (-: (Actually, it was my employer, not his, that had a spurious 192.168.0/24 requirement somewhere, so I guess that introduces a cross in the connection somewhere.) Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
Maarten Wiltink wrote: > "Dave Hart" wrote in message > news:03463add-146a-457d-9869-9caddf6f8...@i18g2000prf.googlegroups.com... >> On Feb 17, 9:01 am, "Maarten Wiltink" >> wrote: > >>> My home network is on 192.168.27/24. I took the number from my >>> street address. My brother (independently!) picked 53 for his >>> network, by the same mechanism[0]. We have an OpenVPN tunnel >>> between those networks. We have no routing problems. >>> >>> [0] And when they renumbered his house, he renumbered his >>> network. Okay, I wouldn't have done that. >> I've taken the same approach a couple of times at different >> addresses with 192.168.address.0/24. I also have a VPN going with >> my brother. Sadly, his employer requires security software that >> requires he use 192.168.1.0/24 for his home network to be able to >> VPN in to work. As a workaround, I've sometimes subnetted a hotel >> 192.168.1.0/24 hotel address, claiming 192.168.1.2 and using netmask >> 192.168.1.252, so that when I VPN all but the first few addresses of >> my brother's network are visible. > > Scary. You _are_ me. (-: > > (Actually, it was my employer, not his, that had a spurious > 192.168.0/24 requirement somewhere, so I guess that introduces > a cross in the connection somewhere.) > This is why I avoid the 192.168.*.* addresses everywhere. Everyone wants to use them. Only my DMZ uses them. Danny > Groetjes, > Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
