10 May
2024
10 May
'24
4:25 p.m.
It took approximately 27 minutes for me to begin receiving IPENCAP from AMPRGW after
manually changing the IP on the Portal from an invalid IP. Just FYI.
---73,
LynwoodKB3VWG
On Tuesday, May 7, 2024 at 05:48:23 PM EDT, Dan Cross via 44net
<44net(a)mailman.ampr.org> wrote:
[Trim Cc: list, add 44net(a)ardc.groups.io and G1FEF directly]
On Tue, May 7, 2024 at 12:31 AM Kris Kirby <kris(a)catonic.us> wrote:
On Fri, 3 May 2024, Dan Cross via 44net wrote:
I don't use Linux, or ampr-ripd, on my gateway, but I find this mildly
surprising.
The data I've observed suggests that if an upstream router returns
some kind of error for a gateway --- specifically, I've observed ICMP
Host Unreachable messages --- that induces AMPRGW to stop forwarding
for an endpoint for ~1 hour. I haven't looked at the internals of
`ampr-ripd` that closely, but it seems sort of strange that just
stopping it would induce that behavior. Perhaps it has to do with
tearing down tunnels and/or routes when `ampr-ripd` starts/stops.
Chris, do you have any insight into this behavior?
- Dan C.
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
On Fri, May 3, 2024 at 10:13 AM kc8qba via 44net
<44net(a)mailman.ampr.org> wrote:
> If there's a consensus that a 45-60 minute delay in passing traffic
> across the ucsd gateway is the expected behavior, I think we should
> update the wiki to reflect this fact.
IIRC is it something like 60 minutes depending on when your station
last flapped, and you will see RIP traffic distributed over the IPIP
tunnel. Note that as far as it is concerned, the flap is when amprripd
exits and restarts.