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
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
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@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@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
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
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@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@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
-
lleachii＠aol.com -
Rob PE1CHL