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!
"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, b
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
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
"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
>
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 th
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
>> sta
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 som
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 h
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 id
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
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
> >
"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 ad
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
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 ar
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
>> 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
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
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
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
> >
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 w
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
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 winni
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 t
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
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
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, 19
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 - str
28 matches
Mail list logo
