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,


Lynwood
KB3VWG


On Tuesday, May 7, 2024 at 05:48:23 PM EDT, Dan Cross via 44net <44net@mailman.ampr.org> wrote:


[Trim Cc: list, add 44net@ardc.groups.io and G1FEF directly]

On Tue, May 7, 2024 at 12:31 AM Kris Kirby <kris@catonic.us> wrote:
> On Fri, 3 May 2024, Dan Cross via 44net wrote:
> > On Fri, May 3, 2024 at 10:13 AM kc8qba via 44net
> > <44net@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.

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@mailman.ampr.org
To unsubscribe send an email to 44net-leave@mailman.ampr.org