Hello,
I think we have an route update/setup issue in our network that may need some attention.
First of all, I don't see the root cause so maybe we should investigate a little.
As you may have noticed, a technical bulldozer issue forced me to move the yo2tm server to a VPS cloud machine, which is not a bad move by itself.
I put a gw with amprd on it and added a new new portal entry, 44.182.21.1 via 89.33.44.100. The route appeared in the RIP broadcasts a few minute later and everything seems to be working as expected. Ping was ok, connecting also.
So at the moment there are 2 overlapping subnets, 44.182.21.1/32 at the new gw, and 44.182.21.0/24 at the old one.
Since I moved the call home map to the new location, too, I was expecting that all nodes would show up in the new map, since all notifications go to 44.182.21.1.
Normally, for routing purposes, the more precise route (/32) should take precedence over the old one, and everything should be fine.
On the maps, there where some nodes appearing promptly via the new gateway, like N1URO and some related radio nodes, but that was it. So after 2 days, only 8 nodes switched to the new route, all others sending their notification to the old address, WHICH SHOULD NOT HAPPEN.
The gateway was certainly updated as the internet pings hitting it moved to the new target (some 20 public IPs). Also, my netrom partners also followed after setting up the end axip endpoints on the new machine.
I can not find an explanation for this, other than that there is some route caching involved.
Maybe some of you have ideas/explanation on this behavior, and how to fix it.
Marius, YO2LOJ
On Sun, Oct 14, 2018 at 12:43:05PM +0300, Marius Petrescu wrote:
I can not find an explanation for this, other than that there is some route caching involved.
Maybe some of you have ideas/explanation on this behavior, and how to fix it.
Marius, YO2LOJ
The first thing that occurs to me is possibly that instead of using the pseudo-RIP transmissions, many people are still using the downloaded encap file and simply haven't downloaded a new one yet.
At this late date, that shouldn't be the case, but it explains what you're seeing, doesn't it?
As an experiment, you could remove the encap entry for the enclosing route from the portal and see if more people switch to the proper address. That might indicate that there is a problem with overlapping routing entries, although what would cause that without being a much bigger problem is a puzzle to me. - Brian
No response from here , despite sending to the correct destination gateway address also tested ear;ier same result today
14:05:44.045967 IP ###.###.###.### > 89.33.44.100: IP 44.131.244.1 > 44.182.21.1: ICMP echo request, id 26770, seq 3, length 64 (ipip-proto-4) 14:06:44.050572 IP ###.###.###.### > 89.33.44.100: IP 44.131.244.1 > 44.182.21.1: ICMP echo request, id 26770, seq 4, length 64 (ipip-proto-4) 14:07:26.031589 IP ###.###.###.### > 89.33.44.100: IP 44.131.244.1.35796
44.182.21.1.59001: Flags [S], seq 269803896, win 9440, options [mss
472,sackOK,TS val 517290616 ecr 0,nop,wscale 7], length 0 (ipip-proto-4) 14:07:26.040969 IP ###.###.###.### > 89.33.44.100: IP 44.131.244.1.35797
44.182.21.1.59001: Flags [S], seq 2420208604, win 9440, options [mss
472,sackOK,TS val 517290618 ecr 0,nop,wscale 7], length 0 (ipip-proto-4) 14:07:26.291767 IP ###.###.###.### > 89.33.44.100: IP 44.131.244.1.35798
44.182.21.1.59001: Flags [S], seq 2780115569, win 9440, options [mss
472,sackOK,TS val 517290681 ecr 0,nop,wscale 7], length 0 (ipip-proto-4) 14:07:27.029992 IP ###.###.###.### > 89.33.44.100: IP 44.131.244.1.35796
44.182.21.1.59001: Flags [S], seq 269803896, win 9440, options [mss
472,sackOK,TS val 517290866 ecr 0,nop,wscale 7], length 0 (ipip-proto-4) 14:07:27.037992 IP ###.###.###.### > 89.33.44.100: IP 44.131.244.1.35797
44.182.21.1.59001: Flags [S], seq 2420208604, win 9440, options [mss
472,sackOK,TS val 517290868 ecr 0,nop,wscale 7], length 0 (ipip-proto-4) 14:07:27.289956 IP ###.###.###.### > 89.33.44.100: IP 44.131.244.1.35798
44.182.21.1.59001: Flags [S], seq 2780115569, win 9440, options [mss
472,sackOK,TS val 517290931 ecr 0,nop,wscale 7], length 0 (ipip-proto-4) 14:07:29.033974 IP ###.###.###.### > 89.33.44.100: IP 44.131.244.1.35796
44.182.21.1.59001: Flags [
Paul On 14/10/2018 13:38, Brian Kantor wrote:
On Sun, Oct 14, 2018 at 12:43:05PM +0300, Marius Petrescu wrote:
I can not find an explanation for this, other than that there is some route caching involved.
Maybe some of you have ideas/explanation on this behavior, and how to fix it.
This email has been scanned by Netintelligence http://www.netintelligence.com/email
Tnx Paul.
I can ping your IP ampr successfully from 44.182.21.1.
This tends to be strange.
On 14.10.2018 16:11, Paul wrote:
No response from here , despite sending to the correct destination gateway address also tested ear;ier same result today
14:05:44.045967 IP ###.###.###.### > 89.33.44.100: IP 44.131.244.1 > 44.182.21.1: ICMP echo request, id 26770, seq 3, length 64 (ipip-proto-4) 14:06:44.050572 IP ###.###.###.### > 89.33.44.100: IP 44.131.244.1 > 44.182.21.1: ICMP echo request, id 26770, seq 4, length 64 (ipip-proto-4) 14:07:26.031589 IP ###.###.###.### > 89.33.44.100: IP 44.131.244.1.35796 > 44.182.21.1.59001: Flags [S], seq 269803896, win 9440, options [mss 472,sackOK,TS val 517290616 ecr 0,nop,wscale 7], length 0 (ipip-proto-4) 14:07:26.040969 IP ###.###.###.### > 89.33.44.100: IP 44.131.244.1.35797 > 44.182.21.1.59001: Flags [S], seq 2420208604, win 9440, options [mss 472,sackOK,TS val 517290618 ecr 0,nop,wscale 7], length 0 (ipip-proto-4) 14:07:26.291767 IP ###.###.###.### > 89.33.44.100: IP 44.131.244.1.35798 > 44.182.21.1.59001: Flags [S], seq 2780115569, win 9440, options [mss 472,sackOK,TS val 517290681 ecr 0,nop,wscale 7], length 0 (ipip-proto-4) 14:07:27.029992 IP ###.###.###.### > 89.33.44.100: IP 44.131.244.1.35796 > 44.182.21.1.59001: Flags [S], seq 269803896, win 9440, options [mss 472,sackOK,TS val 517290866 ecr 0,nop,wscale 7], length 0 (ipip-proto-4) 14:07:27.037992 IP ###.###.###.### > 89.33.44.100: IP 44.131.244.1.35797 > 44.182.21.1.59001: Flags [S], seq 2420208604, win 9440, options [mss 472,sackOK,TS val 517290868 ecr 0,nop,wscale 7], length 0 (ipip-proto-4) 14:07:27.289956 IP ###.###.###.### > 89.33.44.100: IP 44.131.244.1.35798 > 44.182.21.1.59001: Flags [S], seq 2780115569, win 9440, options [mss 472,sackOK,TS val 517290931 ecr 0,nop,wscale 7], length 0 (ipip-proto-4) 14:07:29.033974 IP ###.###.###.### > 89.33.44.100: IP 44.131.244.1.35796 > 44.182.21.1.59001: Flags [
Paul On 14/10/2018 13:38, Brian Kantor wrote:
On Sun, Oct 14, 2018 at 12:43:05PM +0300, Marius Petrescu wrote:
I can not find an explanation for this, other than that there is some route caching involved.
Maybe some of you have ideas/explanation on this behavior, and how to fix it.
This email has been scanned by Netintelligence http://www.netintelligence.com/email
Marius.
I concur with Paul:
- Can not access yo2tm.ampr.org/ampr-map/ - Can not ping 44.182.21.0 and 44.182.21.1 from ANY host - traceroute from 44-net host shows empty lines - traceroute from _NOT_ 44-net aware host shows:
root@deb95:~# traceroute 44.182.21.0 traceroute to 44.182.21.0 (44.182.21.0), 30 hops max, 60 byte packets 1 192.168.0.1 (192.168.0.1) 0.241 ms 0.193 ms 0.211 ms 2 10.149.64.1 (10.149.64.1) 6.705 ms 11.505 ms 11.507 ms 3 172.17.173.1 (172.17.173.1) 12.529 ms 12.540 ms 12.547 ms 4 172.17.28.186 (172.17.28.186) 17.896 ms 17.809 ms 17.739 ms 5 172.17.28.186 (172.17.28.186) 17.601 ms 172.17.28.182 (172.17.28.182) 17.841 ms 172.17.28.186 (172.17.28.186) 17.504 ms 6 limelight.plix.pl (195.182.218.35) 46.231 ms 42.044 ms 46.104 ms 7 p1-1.fr3.fra1.llnw.net (178.79.240.9) 45.995 ms 42.190 ms 46.559 ms 8 lag30.fr3.ord.llnw.net (68.142.88.54) 146.093 ms 145.876 ms 146.017 ms 9 lag41.fr3.sjc.llnw.net (68.142.88.145) 205.344 ms 201.166 ms 201.073 ms 10 ve5.fr4.sjc.llnw.net (69.28.171.210) 201.395 ms 201.062 ms 201.376 ms 11 ve8.fr4.snv1.llnw.net (69.28.172.189) 211.613 ms 202.386 ms 202.239 ms 12 198.32.251.193 (198.32.251.193) 202.452 ms 202.814 ms 202.347 ms 13 137.164.11.31 (137.164.11.31) 209.173 ms 137.164.11.29 (137.164.11.29) 204.497 ms 137.164.11.31 (137.164.11.31) 207.854 ms 14 dc-lax-agg8--svl-agg8-100ge-1.cenic.net (137.164.11.0) 209.836 ms 209.481 ms 137.164.11.20 (137.164.11.20) 208.743 ms 15 137.164.11.34 (137.164.11.34) 217.694 ms 217.635 ms 213.343 ms 16 137.164.11.23 (137.164.11.23) 211.544 ms 137.164.11.25 (137.164.11.25) 211.528 ms 137.164.11.23 (137.164.11.23) 222.184 ms 17 137.164.11.11 (137.164.11.11) 228.489 ms dc-sdg-agg4--tus-agg3-100ge.cenic.net (137.164.11.9) 231.826 ms 137.164.11.11 (137.164.11.11) 228.481 ms 18 dc-ucsd-1--sdg-agg4.cenic.net (137.164.23.54) 233.578 ms 216.487 ms 221.165 ms 19 nodem-core-6807-vlan2767-gw.ucsd.edu (132.239.254.61) 217.537 ms 217.411 ms 217.424 ms 20 sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu (132.239.255.50) 218.893 ms 218.832 ms 218.783 ms 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * root@deb95:~#
But, two days back all was O.K.
Best regards.
Marius.
In addition...
# Current version: 62.021 2018/10/14 05:10:01 encap.txt file - saved by ampr-ripd (UTC) Sun Oct 14 11:20:31 2018
Both files contain only one entry: route addprivate 44.182.21.1/32 encap 89.33.44.100
Best regards.
Hmm,
There should be a 44.182.21.1/32 encap 89.33.44.100, 44.182.20/24 encap 89.122.215.236 and 44.182.21/24 encap 89.122.215.236
I'll check further...
On 14.10.2018 17:43, SP2L wrote:
Marius.
In addition...
# Current version: 62.021 2018/10/14 05:10:01 encap.txt file - saved by ampr-ripd (UTC) Sun Oct 14 11:20:31 2018
Both files contain only one entry: route addprivate 44.182.21.1/32 encap 89.33.44.100
Best regards.
Marius.
I meant ONLY 44.182.21.0 and 44.182.21.1 44.182.20/24 is preset!
Best regards.
Brian and Marius.
My bad... Overlooked??? route addprivate 44.182.20/24 encap 89.122.215.236 route addprivate 44.182.21/24 encap 89.122.215.236 route addprivate 44.182.21.1/32 encap 89.33.44.100
BTW, encap.txt file from portal I have ONLY for comparison purposes and this one is not involved in routing settings.
Best regards.
The relevant routes currently being advertised by the pseudo-RIP sender and used by amprgw are:
root@amprgw:/var/ipip # l routes 14285814 24 -rw-r--r-- 1 root wheel 22433 Oct 14 04:15 routes
root@amprgw:/var/ipip # egrep 44.182 routes 44.182.20.0/24 89.122.215.236 44.182.21.0/24 89.122.215.236 44.182.21.1/32 89.33.44.100 44.182.24.0/24 79.114.61.169 44.182.60.0/29 78.97.200.160 44.182.61.0/24 89.122.215.236 44.182.62.0/24 5.15.22.166 44.182.69.0/24 5.9.41.21 44.182.83.0/24 31.5.225.135
Note that timestamp "Oct 14 04:15" is Pacific time, about four hours ago. - Brian
On Sun, Oct 14, 2018 at 05:49:12PM +0300, Marius Petrescu wrote:
Hmm,
There should be a 44.182.21.1/32 encap 89.33.44.100, 44.182.20/24 encap 89.122.215.236 and 44.182.21/24 encap 89.122.215.236
I'll check further...
On 14.10.2018 17:43, SP2L wrote:
Marius.
In addition...
# Current version: 62.021 2018/10/14 05:10:01 encap.txt file - saved by ampr-ripd (UTC) Sun Oct 14 11:20:31 2018
Both files contain only one entry: route addprivate 44.182.21.1/32 encap 89.33.44.100
Best regards.
Tom, it appears you have an older version of the encap file.
# Current version: 62.028 2018/10/14 12:10:01
contains
route addprivate 44.182.69/24 encap 5.9.41.21 route addprivate 44.182.83/24 encap 31.5.225.135 route addprivate 44.182.20/24 encap 89.122.215.236 route addprivate 44.182.21/24 encap 89.122.215.236 route addprivate 44.182.60/29 encap 78.97.200.160 route addprivate 44.182.62/24 encap 5.15.22.166 route addprivate 44.182.24/24 encap 79.114.61.169 route addprivate 44.182.61/24 encap 89.122.215.236 route addprivate 44.182.21.1/32 encap 89.33.44.100
- Brian
Marius...works from here
C:>tracert 44.182.21.1
Tracing route to yo2tm.ampr.org [44.182.21.1] over a maximum of 30 hops:
1 4 ms <1 ms <1 ms t30.wa4zlw.homedns.org [10.195.10.3] 2 1 ms 1 ms 1 ms core100.wa4zlw.ampr.org [44.56.53.1] 3 156 ms 157 ms 157 ms yo2tm.ampr.org [44.182.21.1]
Trace complete.
C:>
On 10/14/2018 10:43 AM, SP2L wrote:
Marius.
In addition...
# Current version: 62.021 2018/10/14 05:10:01 encap.txt file - saved by ampr-ripd (UTC) Sun Oct 14 11:20:31 2018
Both files contain only one entry: route addprivate 44.182.21.1/32 encap 89.33.44.100
Best regards.
--- This email has been checked for viruses by AVG. https://www.avg.com
On 10/14/2018 2:17 PM, Leon Zetekoff wrote:
Marius...works from here
C:>tracert 44.182.21.1
Tracing route to yo2tm.ampr.org [44.182.21.1] over a maximum of 30 hops:
1 4 ms <1 ms <1 ms t30.wa4zlw.homedns.org [10.195.10.3] 2 1 ms 1 ms 1 ms core100.wa4zlw.ampr.org [44.56.53.1] 3 156 ms 157 ms 157 ms yo2tm.ampr.org [44.182.21.1]
Trace complete.
C:>
On 10/14/2018 10:43 AM, SP2L wrote:
Marius.
In addition...
# Current version: 62.021 2018/10/14 05:10:01 encap.txt file - saved by ampr-ripd (UTC) Sun Oct 14 11:20:31 2018
Both files contain only one entry: route addprivate 44.182.21.1/32 encap 89.33.44.100
Best regards.
This email has been checked for viruses by AVG. https://www.avg.com
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Marius,
From a regular internet address, I'm getting connection timeouts to
http://yo2tm.ampr.org/ampr-map. I haven't checked the map in a few months, so I don't know how new this problem is.
I still use the encap file and update every few hours.
$ ip route get 44.182.21.1 44.182.21.1 via 89.33.44.100 dev tunl0 src 44.4.50.10 cache expires 415sec mtu 1480
But when I try to ping 44.182.21.1 from either amprnet or a regular internet host, I get no response.
Also, I don't see anywhere on the wiki where the map is mentioned. I would have expected it here: http://wiki.ampr.org/wiki/Services
Michael N6MEF
Marius et al.
I can access right now: http://yo2tm.ampr.org/ampr-map. Can ping 44.182.21.1 from 44-host too.
Best regards.
OK, I was the idiotic part in this issue.
I used 'encap' insetad of 'ipencap' in allowing access for ipip.
encap refers to potocol 98, ipencap to protocol 4 which we are using.
And of course, I accept 'established, related'. So after a ping or something, the pinged partner worked...
Tnx for the help.
Marius, YO2LOJ
On 14.10.2018 12:43, Marius Petrescu wrote:
Hello,
I think we have an route update/setup issue in our network that may need some attention.
First of all, I don't see the root cause so maybe we should investigate a little.
As you may have noticed, a technical bulldozer issue forced me to move the yo2tm server to a VPS cloud machine, which is not a bad move by itself.
I put a gw with amprd on it and added a new new portal entry, 44.182.21.1 via 89.33.44.100. The route appeared in the RIP broadcasts a few minute later and everything seems to be working as expected. Ping was ok, connecting also.
So at the moment there are 2 overlapping subnets, 44.182.21.1/32 at the new gw, and 44.182.21.0/24 at the old one.
Since I moved the call home map to the new location, too, I was expecting that all nodes would show up in the new map, since all notifications go to 44.182.21.1.
Normally, for routing purposes, the more precise route (/32) should take precedence over the old one, and everything should be fine.
On the maps, there where some nodes appearing promptly via the new gateway, like N1URO and some related radio nodes, but that was it. So after 2 days, only 8 nodes switched to the new route, all others sending their notification to the old address, WHICH SHOULD NOT HAPPEN.
The gateway was certainly updated as the internet pings hitting it moved to the new target (some 20 public IPs). Also, my netrom partners also followed after setting up the end axip endpoints on the new machine.
I can not find an explanation for this, other than that there is some route caching involved.
Maybe some of you have ideas/explanation on this behavior, and how to fix it.
Marius, YO2LOJ
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Yup. Works now.
Marius,
Do you have the ability to allow a little more zoom on the map? Take a look at California and/or N6MEF.
Michael
-----Original Message----- OK, I was the idiotic part in this issue.
I used 'encap' insetad of 'ipencap' in allowing access for ipip.
encap refers to potocol 98, ipencap to protocol 4 which we are using.
And of course, I accept 'established, related'. So after a ping or something, the pinged partner worked...
Tnx for the help.
Marius, YO2LOJ
Unfortunately no. At least I need to check. AFAIK, the vectormap I use is at its maximum settings.
On 14.10.2018 20:58, n6mef@mefox.org wrote:
Yup. Works now.
Marius,
Do you have the ability to allow a little more zoom on the map? Take a look at California and/or N6MEF.
Michael
-----Original Message----- OK, I was the idiotic part in this issue.
I used 'encap' insetad of 'ipencap' in allowing access for ipip.
encap refers to potocol 98, ipencap to protocol 4 which we are using.
And of course, I accept 'established, related'. So after a ping or something, the pinged partner worked...
Tnx for the help.
Marius, YO2LOJ
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
OK Thanks.
-----Original Message----- From: 44Net 44net-bounces+n6mef=mefox.org@mailman.ampr.org On Behalf Of Marius Petrescu
Unfortunately no. At least I need to check. AFAIK, the vectormap I use is at its maximum settings.
-
Brian Kantor -
Leon Zetekoff -
Marius Petrescu -
Michael Fox - N6MEF -
n6mef＠mefox.org
-
Paul -
SP2L