2 May
2024
2 May
'24
5:12 p.m.
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(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@mailman.ampr.org<mailto:44net@mailman.ampr.org>> wrote:
On Thu, May 2, 2024 at 2:23 PM Barry Bahrami via 44net
<44net@mailman.ampr.org<mailto: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<mailto:44net@mailman.ampr.org>
To unsubscribe send an email to
44net-leave@mailman.ampr.org<mailto:44net-leave@mailman.ampr.org>