[44net] Re: Fw: Re: UCSD gateway not responding after router reboot?

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. 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. Best, -Steve ________________________________ From: Steve L &lt;kb9mwr(a)gmail.com&gt; Sent: Friday, May 3, 2024 2:59 AM To: Dan Cross &lt;crossd(a)gmail.com&gt; Cc: KUN LIN &lt;dnwk(a)linkun.info&gt;fo>; Barry Bahrami &lt;barrybahrami(a)gmail.com&gt;om>; kc8qba &lt;kc8qba(a)wildtky.com&gt;om>; kc8qba--- via 44net &lt;44net(a)mailman.ampr.org&gt; 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<http://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<mailto:crossd@gmail.com>> wrote: On Thu, May 2, 2024 at 5:12 PM KUN LIN <dnwk@linkun.info<mailto:dnwk@linkun.info>> wrote: 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)