17 May
2017
17 May
'17
5:46 p.m.
Yes, outbound non-44 destinations from db0fhn are routed to the Internet
via my other "non source route filtered" gateway. It will reduce the RTT
to European destinations by almost 200ms, however traffic is non-symmetric.
As of today you shouldn't have seen any packets from db0fhn in your
statistics due to the fact that ampr-ripd ignored the 44.0.0.1/32 route
in the RIP broadcasts.
It seems the bidirectional communication from db0fhn to 44.0.0.1 didn't
work due to non-symmetric traffic for a long time now (firewall on your
end?). The route to 44.0.0.1 hasn't been announced to the HAMNET up to
today.
Since you implemented some interesting services, I just set a manual
route until Marius will change the ampr-ripd (maybe the upcoming
weekend). I successfully tested access to gw.ampr.org from the HAMNET,
however it would be nice if that would even work from hosts without
valid DNS entries or do you think DNS entries should be a requirement
even within the IPIP mesh?
73,
Jann
Thomas, thank you for your reply. So outbound non-44
destinations from
44.130.0.0/16 are routed out onto the internet at db0fhn instead of
being sent to amprgw? But the return path has to go through amprgw.
This is non-symmetric routing and I wasn't expecting it. (It's not
a problem.)
I have noted in the past that the link was often busy, and I expected
it would be busy in both directions. If it's not used for outbound
from 44.130.0.0/16, that would explain what I'm seeing for that
gateway.
I was worried that something had gone wrong somewhere because the overall
inbound encap traffic dropped by 90% or more suddenly at 19:00-19:15 on
Tuesday. Whatever happened did so quickly. I thought it was the db0fhn
gateway that malfunctioned but I could be wrong. I'll have to look
elsewhere.
You can see this sudden drop in the graph at 19:00 May 16 on
https://gw.ampr.org/router/encapinpkt.svg
- Brian
