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@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