On Thu, May 2, 2024 at 11:00 PM Steve L kb9mwr@gmail.com wrote:
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.
To quibble just a bit, I'd say that while it may be expected, it's not something I'd consider normal. 45 minutes to an hour is a good chunk of time.
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.
It took a while to hunt down the credentials to see this, but I can see this being very useful. Thanks for posting!
- Dan C.
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