[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(a)gmail.com> wrote: > > On Thu, May 2, 2024 at 5:12 PM KUN LIN <dnwk(a)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(a)mailman.ampr.org> > > Sent: Thursday, May 2, 2024 12:52 > > To: Dan Cross <crossd(a)gmail.com> > > Cc: Barry Bahrami <barrybahrami(a)gmail.com>om>; kc8qba <kc8qba(a)wildtky.com>om>; kc8qba--- via 44net <44net(a)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(a)mailman.ampr.org> wrote: > > > > On Thu, May 2, 2024 at 2:23 PM Barry Bahrami via 44net > > <44net(a)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(a)mailman.ampr.org > > To unsubscribe send an email to 44net-leave(a)mailman.ampr.org