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