8 May
2024
8 May
'24
5:10 a.m.
All,
I did some work on restoring my netflow collectors - and the first thing I noticed was the
NTP server ns.ardc.net is giving me an error. It seems that it does not allow queries from
our Gateway Public IPs as AMPRGW previously did. This provides a chicken-or-the-egg issue
on some of my configs if any time-based services are needed (i.e. if I only rely on
ns.ardc.net for time). This could be a serious issue if e.g. tunnels were switched to
Wireguard (i.e. needing time for encryption).
A SK (I will not name) frowned upon NTP via IPENCAP for obvious reasons (I hope the DNS
discussions make clear that a UDP NTP packet with latency or delays from 2 rounds trips is
BAD).
I'm looking into the implications for myself and possibly for others by not
considering this before the change was made. I'm now working on routes/rules to make
an exception for this IP; but it will require some testing as this would be on my main
(non-AMPRNet) routing table, which is BAD.
I haven't taken time to determine if this will cause issues for other use cases. I am
still run the Stratum 2 server for those who may realize that they are no longer syncing
only on AMRPNet's NTP services.
IP: 44.60.44.1Hostname: kb3vwg-001.ampr.orgAccess Policy: (123/udp open to 44net
and Public GW IPs)
73,
LynwoodKB3VWG
8 May
8 May
8:23 p.m.
Lynwood,
I don't consider it a problem that ARDC would not provide NTP services.
NTP is such an easily run service... we have too many NTP servers inside our 44.137/16
network to even mention them here. Every Linux host in the network runs either ntpd
or chrony to synchronize its own time, and allows queries from within net44.
So no problem at all to get synchronized using a couple of nearby servers.
As we run co-channel repeaters on the network, many of those NTP servers are stratum 1.
(synchronized by PPS from a GPSDO). I also have a LeoNTP at 44.137.41.102
At address 44.137.0.1 (internet address 145.220.78.2 or 2001:67c:6ec:6861:145:220:78:2)
we have an NTP server with about 20 sources, which is also used for monitoring.
And of course on the internet there is pool.ntp.org.
Rob
9:07 p.m.
Rob,
Yea, I also sync with multiple severs (I'm also Stratum 2). I sync with mostly atomic
servers of governments/universities, as well as mains power companies (I believe I
received approval from one). I have 1 or 2 GPS-based ISPs as well.
I will add other AMPRNet peers (Stratum 1, 2 or 3) as they note them to me.
I agree with your assessment (for IPENCAP GW's), as long as operators configure
accordingly.
This should be noted in the Wiki.
Justification: I actually began allowing this years ago as courtesy because I noted the
same failed NTP requests from some operators Public IPs in netflow. Doing route testing
yesterday I now see why. I think it may require a custom IPv4 rule to accommodate the
ns.ardc.net NTP Access Policy.
---
Mark,
I'm not able to successfully run the following command from my Public IP:
`ntpdate -q 44.64.24.123`
I do appreciate your consideration of the issue and thank you for your reply. The issue is
my my GW (i.e. possessing is own Main Routing Table to reach the Public Internet for
IPENCAP) - is the NTP server. This in layman's terms means this requires the GW to
have 3 split routing/DNS/etc. (not just 2 for Internet/AMPRNet). You present the same
issue for Gateways that the ns.ardc.net conversion causes (i.e. you need to first be on
the Mesh for Time Services, but you might need time first - the chicken-or-the-egg paradox
I noted).
Noting this in the Wiki may be helpful for others. - if that's gonna be the suggestion
for NTP as well - e.g. "just use one that works".
Thanks, appreciation and 73 to both,
- LynwoodKB3VWG
On Wednesday, May 8, 2024 at 09:23:24 AM EDT, Rob PE1CHL via 44net
<44net(a)mailman.ampr.org> wrote:
Lynwood,
I don't consider it a problem that ARDC would not provide NTP services.
NTP is such an easily run service... we have too many NTP servers inside our 44.137/16
network to even mention them here. Every Linux host in the network runs either ntpd
or chrony to synchronize its own time, and allows queries from within net44.
So no problem at all to get synchronized using a couple of nearby servers.
As we run co-channel repeaters on the network, many of those NTP servers are stratum 1.
(synchronized by PPS from a GPSDO). I also have a LeoNTP at 44.137.41.102
At address 44.137.0.1 (internet address 145.220.78.2 or 2001:67c:6ec:6861:145:220:78:2)
we have an NTP server with about 20 sources, which is also used for monitoring.
And of course on the internet there is pool.ntp.org.
Rob
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
10 May
10 May
2:29 p.m.
All,
So, I managed to make the working IP Rule for my gateway - but I am not receiving reply
traffic from ns.ardc.net. It confused me for a day or so. The same appears to be occurring
with DNS. I'm wondering if anyone else is experiencing it:
---
config rule
option dest '44.1.1.44/32'
option lookup '44'
option priority '21'
option in 'loopback'
---
root@OpenWrt:~# tcpdump -vvvn -i tunl0 udp and port 123 and host 44.1.1.44
tcpdump: listening on tunl0, link-type RAW (Raw IP), snapshot length 262144 bytes
07:07:41.623308 IP (tos 0x48, ttl 64, id 33889, offset 0, flags [DF], proto UDP (17),
length 76)
44.60.44.254.37651 > 44.1.1.44.123: [bad udp cksum 0x86b0 -> 0x977a!] NTPv4,
Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 4164246549.287667102 (2031-12-17T07:09:09Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 4164246549.287667102 (2031-12-17T07:09:09Z)
---
root@OpenWrt:~# ping 44.1.1.44 -I tunl0 -c 4
PING 44.1.1.44 (44.1.1.44): 56 data bytes
--- 44.1.1.44 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
---
root@OpenWrt:~# tcpdump -vvvn -i tunl0 host 44.1.1.44
tcpdump: listening on tunl0, link-type RAW (Raw IP), snapshot length 262144 bytes
07:19:43.277743 IP (tos 0x0, ttl 64, id 6493, offset 0, flags [DF], proto ICMP (1), length
84)
44.60.44.254 > 44.1.1.44: ICMP echo request, id 14603, seq 0, length 64
07:19:44.278254 IP (tos 0x0, ttl 64, id 6512, offset 0, flags [DF], proto ICMP (1), length
84)
44.60.44.254 > 44.1.1.44: ICMP echo request, id 14603, seq 1, length 64
07:19:45.278696 IP (tos 0x0, ttl 64, id 6558, offset 0, flags [DF], proto ICMP (1), length
84)
44.60.44.254 > 44.1.1.44: ICMP echo request, id 14603, seq 2, length 64
07:19:46.279205 IP (tos 0x0, ttl 64, id 6589, offset 0, flags [DF], proto ICMP (1), length
84)
44.60.44.254 > 44.1.1.44: ICMP echo request, id 14603, seq 3, length 64
---
DNS seems to also have an issue (note: the IP Rule didn't affect DNS-MDC traffic, as
the inbound interface != lo):
07:21:11.105609 IP (tos 0x0, ttl 63, id 21778, offset 0, flags [none], proto UDP (17),
length 65)
44.60.44.3.61466 > 44.1.1.44.53: [udp sum ok] 50184 SOA? 108.44.in-addr.arpa. (37)
07:21:13.949674 IP (tos 0x0, ttl 63, id 22073, offset 0, flags [none], proto UDP (17),
length 80)
44.60.44.3.61466 > 44.1.1.44.53: [udp sum ok] 61634 [1au] SOA? 114.44.in-addr.arpa.
ar: . OPT UDPsize=2048 [EXPIRE] (52)
07:21:24.369570 IP (tos 0x0, ttl 63, id 22677, offset 0, flags [none], proto UDP (17),
length 65)
44.60.44.3.61466 > 44.1.1.44.53: [udp sum ok] 64002 SOA? 168.44.in-addr.arpa. (37)
07:21:28.957619 IP (tos 0x0, ttl 63, id 23673, offset 0, flags [none], proto UDP (17),
length 65)
44.60.44.3.61466 > 44.1.1.44.53: [udp sum ok] 24199 SOA? 114.44.in-addr.arpa. (37)
- KB3VWG
4:14 p.m.
Disregard. I attribute this to a Public IP and domain change.
I've made the change in the Portal, as well as 22 tickets for "claims". It
also allows duplicates(?). Aside from that seeming somewhat bizarre, I will update the
time until I begin receiving IPENCAP packets again and discuss in the other chain on that
topic where people observed delayed tunnel update time.
As I noted before, I hope my Portal experience is good - it has been thus far.
- Lynwood
On Friday, May 10, 2024 at 03:30:18 AM EDT, lleachii--- via 44net
<44net(a)mailman.ampr.org> wrote:
All,
So, I managed to make the working IP Rule for my gateway - but I am not receiving reply
traffic from ns.ardc.net. It confused me for a day or so. The same appears to be occurring
with DNS. I'm wondering if anyone else is experiencing it:
---
config rule
option dest '44.1.1.44/32'
option lookup '44'
option priority '21'
option in 'loopback'
---
root@OpenWrt:~# tcpdump -vvvn -i tunl0 udp and port 123 and host 44.1.1.44
tcpdump: listening on tunl0, link-type RAW (Raw IP), snapshot length 262144 bytes
07:07:41.623308 IP (tos 0x48, ttl 64, id 33889, offset 0, flags [DF], proto UDP (17),
length 76)
44.60.44.254.37651 > 44.1.1.44.123: [bad udp cksum 0x86b0 -> 0x977a!] NTPv4,
Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 4164246549.287667102 (2031-12-17T07:09:09Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 4164246549.287667102 (2031-12-17T07:09:09Z)
---
root@OpenWrt:~# ping 44.1.1.44 -I tunl0 -c 4
PING 44.1.1.44 (44.1.1.44): 56 data bytes
--- 44.1.1.44 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
---
root@OpenWrt:~# tcpdump -vvvn -i tunl0 host 44.1.1.44
tcpdump: listening on tunl0, link-type RAW (Raw IP), snapshot length 262144 bytes
07:19:43.277743 IP (tos 0x0, ttl 64, id 6493, offset 0, flags [DF], proto ICMP (1), length
84)
44.60.44.254 > 44.1.1.44: ICMP echo request, id 14603, seq 0, length 64
07:19:44.278254 IP (tos 0x0, ttl 64, id 6512, offset 0, flags [DF], proto ICMP (1), length
84)
44.60.44.254 > 44.1.1.44: ICMP echo request, id 14603, seq 1, length 64
07:19:45.278696 IP (tos 0x0, ttl 64, id 6558, offset 0, flags [DF], proto ICMP (1), length
84)
44.60.44.254 > 44.1.1.44: ICMP echo request, id 14603, seq 2, length 64
07:19:46.279205 IP (tos 0x0, ttl 64, id 6589, offset 0, flags [DF], proto ICMP (1), length
84)
44.60.44.254 > 44.1.1.44: ICMP echo request, id 14603, seq 3, length 64
---
DNS seems to also have an issue (note: the IP Rule didn't affect DNS-MDC traffic, as
the inbound interface != lo):
07:21:11.105609 IP (tos 0x0, ttl 63, id 21778, offset 0, flags [none], proto UDP (17),
length 65)
44.60.44.3.61466 > 44.1.1.44.53: [udp sum ok] 50184 SOA? 108.44.in-addr.arpa. (37)
07:21:13.949674 IP (tos 0x0, ttl 63, id 22073, offset 0, flags [none], proto UDP (17),
length 80)
44.60.44.3.61466 > 44.1.1.44.53: [udp sum ok] 61634 [1au] SOA? 114.44.in-addr.arpa.
ar: . OPT UDPsize=2048 [EXPIRE] (52)
07:21:24.369570 IP (tos 0x0, ttl 63, id 22677, offset 0, flags [none], proto UDP (17),
length 65)
44.60.44.3.61466 > 44.1.1.44.53: [udp sum ok] 64002 SOA? 168.44.in-addr.arpa. (37)
07:21:28.957619 IP (tos 0x0, ttl 63, id 23673, offset 0, flags [none], proto UDP (17),
length 65)
44.60.44.3.61466 > 44.1.1.44.53: [udp sum ok] 24199 SOA? 114.44.in-addr.arpa. (37)
- KB3VWG
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
226
days inactive
229
days old
4 comments
2 participants
participants (2)
-
lleachii＠aol.com -
Rob PE1CHL