Hi Brian,
With your system I have a different issue... when I ping n1uro.ampr.org from 44.137.40.2 which has an IPIP tunnel on 89.18.172.156 I can ping you without problem, but when I ping from other addresses like 44.137.0.1 or 44.137.41.97 I get no reply. Those addresses are supposed to be handled via the tunnel for 44.137.0.0/16 which has external address 213.222.29.194 and is also registered in the portal. They are also reachable on the internet directly (BGP announced)
What can be the problem? Did you add some handling of BGP routed subnets that now fails because of the dual connectivity we have? Or is it the issue that I hunted some time ago (and never really tracked down) where there appears to be systematic packet loss in RIP announcements that makes certain subnets disappear completely or make them flapping? (I tried to suppress that by increasing EXPTIME to 7200 in ampr-ripd.c)
I have a BGP feed and the IPIP mesh (loaded from API).
These are the relevant routing entries for 44.137.40.2.
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 ADb 0.0.0.0/0 46.29.abc.xyz 250 1 A S 44.137.0.0/16 ampr-213.222.de... 210 2 Db 44.137.0.0/16 46.29.abc.xyz 250 3 A S 44.137.40.2/32 ampr-89.18.def.ghi 210
Rule #0 and #2 are BGP routes, rule #1 and #3 are static rules added via script parsing API output.
As you can see I prefer IPIP routes over BGP.
Traceroute looks fine:
marconi:~# traceroute -I 44.137.40.2 traceroute to 44.137.40.2 (44.137.40.2), 30 hops max, 60 byte packets 1 lx0bgp-18.ampr.org (44.161.204.1) 0.390 ms 0.493 ms 0.652 ms 2 tunnels.lx0bgp.ampr.org (44.161.230.255) 7.681 ms 7.743 ms 7.878 ms 3 sys2.pe1chl.ampr.org (44.137.40.2) 24.655 ms 24.666 ms 25.041 ms
73 de Marc, LX1DUC