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