On Fri, May 3, 2024 at 10:13 AM kc8qba via 44net 44net@mailman.ampr.org wrote:
If there's a consensus that a 45-60 minute delay in passing traffic across the ucsd gateway is the expected behavior, I think we should update the wiki to reflect this fact.
Agreed. I was hoping someone who's actually familiar with the operation of amprgw would weigh in, but I took a stab at drafting something on the wiki. I mentioned it in the FAQ as well as the page about AMPRGW itself.
As someone who was recently brand new to this entire space, I distinctly remember a cycle of (a) tinkering with and documenting settings until things started to work, (b) rebooting to test if boot-time configurations were being properly applied, followed by (c) disappointment and frustration.
In my opinion, that delay is neither obvious nor intuitive and (along with, perhaps, annotating that the OH7LZB VPN is no longer working) is something that should be documented.
I put a disclaimer at the top of this page.
- Dan C.
Best, -Steve
From: Steve L kb9mwr@gmail.com Sent: Friday, May 3, 2024 2:59 AM To: Dan Cross crossd@gmail.com Cc: KUN LIN dnwk@linkun.info; Barry Bahrami barrybahrami@gmail.com; kc8qba kc8qba@wildtky.com; kc8qba--- via 44net 44net@mailman.ampr.org Subject: Re: [44net] Re: Fw: Re: UCSD gateway not responding after router reboot?
I'd say what you are experiencing is normal. It's been a while since I've done much with my gateway, but I do recall waiting almost an hour for things to return to normal after bringing mine back up.
I assume there is likely some cron job on the UCSD gateway that rebuilds the list of active gateways for ingress/ egress purposes. The ampr gw stats page might provide clues when your not able to pass traffic.
gw.ampr.org/private
It was one of the last things Brian added to the UCSD gw.
On Thu, May 2, 2024, 5:40 PM Dan Cross crossd@gmail.com wrote:
On Thu, May 2, 2024 at 5:12 PM KUN LIN dnwk@linkun.info wrote:
I did not witness this delay when rebooting the server previous when I use Debian. I recently switch to Ubuntu and noticed this issue where gateway will stop sending traffic after a reboot. When I was using Debian, reboot wasn't an issue. But I guess maybe it has to do with how long the reboot take. With Debian, reboot only takes a few seconds while Ubuntu takes much longer. Maybe the longer reboot time triggered something on the gateway side.
A longer timeout implies more opportunity for an intermediate router to generate e.g. host unreachable messages and send them to the UCSD gateway. IP is, by design, an unreliable protocol so some number of datagrams are "expected" to be lost in the normal course of things; a router will only consider a host unreachable if there's a repeated pattern of unreachability. If a reboot only takes a short time, there's less of an opportunity; if a reboot takes much longer, a greater opportunity. And indeed, I see ARP requests on my external network all the time; I suspect that's how the upstream router determines whether I'm reachable or not.
To test this, I did an experiment: I set up another machine on the same ethernet segment that connects my AMPRNet gateway to my ISP's router, and configured that machine to provide proxy ARP for the AMPRNet gateway machine. I then rebooted the AMPRNet gateway and repeatedly ran `traceroute` to it from another machine elsewhere on the Internet while it rebooted. I never saw an ICMP Host Unreachable message come back, while I did when the ARP proxy was not in place; running `tcpdump` on the machine running proxy ARP, I _did_ see it answer for the AMPR gateway's external IP address. Once the router came back online, I was able to connect to and from my subnet normally, with no additional delay.
What I believe this shows is that configuring proxy ARP for the AMPRNet gateway was enough to convince my ISP's router that the AMPRNet gateway remained up, which in turn was sufficient to prevent it from returning errors to the UCSD gateway.
At this point, the proposed explanation for all of this -- that ICMP Host Unreachable messages sent to the UCSD gateway cause the gateway to throttle traffic to the affected tunnel endpoint for ~1 hour -- match the observed phenomena sufficiently well that I feel comfortable calling it a hypothesis. RIP packet delivery seems to ignore these throttles, though (presumably it's unnecessary, given the way that IP multicast works). So far, experimental evidence appears to support this hypothesis. Regardless, it would be nice to get some confirmation if this is, in fact, what's actually going on. If it's confirmed, I'd be happy to document it on the Wiki.
- Dan C. (KZ2X)From: Steve L via 44net 44net@mailman.ampr.org Sent: Thursday, May 2, 2024 12:52 To: Dan Cross crossd@gmail.com Cc: Barry Bahrami barrybahrami@gmail.com; kc8qba kc8qba@wildtky.com; kc8qba--- via 44net 44net@mailman.ampr.org Subject: [44net] Re: Fw: Re: UCSD gateway not responding after router reboot?
If I recall Brian set up the rip announcements to be less frequent to a host if it has previously returned an unreachable code.
Else if ones public IP changes, it seems like unfriendly ddos traffic from UCSD to now, some non hams IP address.
A lot of the UCSD gw was documented in a flowchart image. I'd have to look to see if I still have that.
On Thu, May 2, 2024, 2:18 PM Dan Cross via 44net 44net@mailman.ampr.org wrote:
On Thu, May 2, 2024 at 2:23 PM Barry Bahrami via 44net 44net@mailman.ampr.org wrote:
This is common to prevent flapping interfaces from causing problems with the routing table through constant updates. Although an hour is a bit high. I wonder if there is a typo in the config. Just a thought
That's reasonable. I wonder how it's implemented? As far as I know, creation or tear-down of an IPENCAP tunnel does not, by itself, generate any traffic: an interface could conceivably flap and nothing on the distant end would notice. I suppose if the interface flaps, an upstream router could send an ICMP host unreachable message to the UCSD router for anything being sent through the tunnel regularly? I could see that triggering some kind of quenching logic, though an hour-ish timeout seems excessive.
- Dan C.
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org