7 May
2024
7 May
'24
11:31 a.m.
On Fri, 3 May 2024, Dan Cross via 44net wrote:
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. 1 hr does sound familiar, which is why I tried to
avoid rebooting the virtual server. I was using a full KVM
virtualized server, because it was required to load the IPIP module.
Then I connected a VPS using OpenVPN to the IPIP end-point I'd
established. Under OpenVPN, "none" is a valid cryptographic protocol,
however you need to be aware of replay attacks, etc. In my case, there
was still a lot of jitter on the VPN links due to the changing workloads
of the VPS(s).
Agreed. I was hoping someone who's actually
familiar with the
operation of amprgw would weigh in, but I took a stab at drafting
something on the wiki. I mentioned it in the FAQ as well as the page
about AMPRGW itself.
My challenge was getting traffic to move at all, which was first
amprripd, then DNS entries.
Policy Based Routing didn't make it much easier on Linux.
> In my opinion, that delay is neither obvious nor
intuitive and
> (along with, perhaps, annotating that the OH7LZB VPN is no longer
> working) is something that should be documented.
--
Kris Kirby, KE4AHR
Disinformation Architect, Systems Mangler, & Network Mismanager