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.
Kun ________________________________ 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.orgmailto:44net@mailman.ampr.org> wrote: On Thu, May 2, 2024 at 2:23 PM Barry Bahrami via 44net <44net@mailman.ampr.orgmailto: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.orgmailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.orgmailto:44net-leave@mailman.ampr.org