Since yesterday, or maybe earlier, we do not receive the full RIP table anymore and our route table for IPIP routes has almost emptied.
A trace of UDP port 520 shows only 2 RIP packets per cycle.
Has something changed? Or does this have to be some rate-limiting on the path to here?
Rob
Rob,
I just took a look at the tcpdump of packets leaving AMPRGW and they appear to be the usual full RIP table. I am not aware of any rate limiting at this end; of course, there could be some further downstream.
In a recent 5 minute cycle, the rip sender logged Apr 2 04:35:01 <local0.info> amprgw ripsend[64800]: 706 routes, 29 + 11/25 packets sent to 524 distinct gateways
and indeed, 30 packets were sent to one of the NL gateways, 82.94.240.92; 29 of them were length 532 containing 25 routes, and the last of length 252, containing 11.
Pings to 82.94.240.92 were a consistent 163 ms and there was 0% packet loss in 100 consecutive pings.
I am not aware of any changes to the rip sender nor to the OS, and all appears to be operating normally.
If there's anything else I can test from this end, let me know. - Brian
On Tue, Apr 02, 2019 at 01:19:27PM +0200, Rob Janssen wrote:
Since yesterday, or maybe earlier, we do not receive the full RIP table anymore and our route table for IPIP routes has almost emptied.
A trace of UDP port 520 shows only 2 RIP packets per cycle.
Has something changed? Or does this have to be some rate-limiting on the path to here?
Rob _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
It just occured to me to try a flood ping to that same gateway; in flood mode (ping -f -c 100 82.94.240.92), there was 45% packet loss, so there may indeed be something limiting packet rates between San Diego and NL. What that would be I don't know. - Brian
Hi,
I still have 524 IP tunnels and 704 RIP routes on my Mikrotik router.
73,
Ruben - ON3RVH
-----Original Message----- From: 44Net 44net-bounces+on3rvh=on3rvh.be@mailman.ampr.org On Behalf Of Brian Kantor Sent: dinsdag 2 april 2019 14:00 To: AMPRNet working group 44net@mailman.ampr.org Subject: Re: [44net] RIP problems?
It just occured to me to try a flood ping to that same gateway; in flood mode (ping -f -c 100 82.94.240.92), there was 45% packet loss, so there may indeed be something limiting packet rates between San Diego and NL. What that would be I don't know. - Brian _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hmm. A traceroute from my home network (not involving AMPRNet) from San Diego to the main NL gateway 213.222.29.194 gives a fairly clean 15 hop path with less than 200 ms delay.
traceroute to 213.222.29.194 (213.222.29.194), 30 hops max, 60 byte packets 1 192.168.1.1 0.333 ms 0.369 ms 0.414 ms 2 142.254.184.25 11.739 ms 12.744 ms 12.677 ms 3 76.167.17.129 31.024 ms 31.962 ms 32.003 ms 4 72.129.3.58 15.552 ms 16.508 ms 23.692 ms 5 * * * 6 * * * 7 * 66.109.6.6 24.977 ms 22.664 ms 8 66.109.6.141 20.489 ms 23.461 ms 66.109.6.137 23.351 ms 9 134.222.248.37 21.239 ms 20.207 ms 25.972 ms 10 134.222.49.16 175.477 ms 173.982 ms 171.936 ms 11 134.222.48.91 169.607 ms 175.150 ms 173.144 ms 12 134.222.48.223 172.708 ms 173.069 ms 171.491 ms 13 * 134.222.93.145 191.036 ms 190.947 ms 14 194.109.5.58 195.652 ms 194.109.5.78 185.633 ms 184.671 ms 15 213.222.29.194 179.788 ms 174.224 ms 168.986 ms
A traceroute from UCSD to the same gateway gets some very strange routing:
traceroute to 213.222.29.194 (213.222.29.194), 64 hops max, 40 byte packets 1 169.228.34.82 0.622 ms 0.583 ms 0.535 ms 2 132.239.255.49 0.238 ms 0.202 ms 0.203 ms 3 132.239.254.162 3.549 ms 1.461 ms 0.231 ms 4 137.164.23.176 0.459 ms 0.607 ms 1.000 ms 5 137.164.11.8 2.223 ms 137.164.11.10 2.038 ms 137.164.11.8 2.095 ms 6 137.164.11.22 2.947 ms 137.164.11.24 2.876 ms 137.164.11.22 2.925 ms 7 137.164.11.27 3.644 ms 137.164.11.35 3.479 ms 137.164.11.7 4.481 ms 8 64.57.20.82 2.847 ms 3.703 ms 2.900 ms 9 162.252.70.25 12.336 ms 12.178 ms 12.221 ms 10 162.252.70.23 14.607 ms 14.675 ms 14.669 ms 11 162.252.70.20 19.928 ms 19.837 ms 19.953 ms 12 162.252.70.15 34.874 ms 35.096 ms 35.076 ms 13 162.252.70.17 35.398 ms 39.148 ms 35.305 ms 14 64.57.20.114 39.820 ms 39.911 ms 39.877 ms 15 206.223.118.75 42.654 ms 39.976 ms 39.988 ms 16 134.222.48.21 159.063 ms 159.275 ms 159.233 ms 17 134.222.48.32 158.824 ms 159.724 ms 158.765 ms 18 134.222.48.0 163.547 ms 170.078 ms 163.569 ms 19 134.222.48.15 158.977 ms 162.456 ms 158.940 ms 20 134.222.94.217 158.773 ms 162.472 ms 162.756 ms 21 194.109.5.4 158.986 ms 194.109.5.6 162.698 ms 158.975 ms 22 194.109.5.58 165.177 ms 194.109.5.118 159.376 ms 194.109.5.78 159.058 ms 23 * * * 24 * * * 25 * * *
and in fact never resolves.
A traceroute to 213.222.29.194 from a data center in Texas shows some confusion inside a network 134.222.48.x, which appears to be titled 'eurorings', and a further several hops inside xs4all.net:
traceroute to 213.222.29.194 (213.222.29.194), 64 hops max, 40 byte packets 1 199.249.230.254 0.444 ms 0.307 ms 0.267 ms 2 184.105.25.105 0.364 ms 0.282 ms 0.307 ms 3 206.223.118.75 0.338 ms 0.333 ms 0.398 ms 4 134.222.48.21 125.646 ms 125.439 ms 125.700 ms 5 134.222.48.32 125.426 ms 125.801 ms 127.761 ms 6 134.222.48.2 129.981 ms 134.222.49.98 126.027 ms 134.222.48.0 130.044 ms 7 134.222.48.15 128.921 ms 125.288 ms 125.650 ms 8 * * * 9 194.109.5.6 125.795 ms 125.626 ms 194.109.5.4 125.878 ms 10 194.109.5.78 129.396 ms 126.613 ms 194.109.5.58 125.455 ms 11 213.222.29.194 129.366 ms 129.264 ms 130.198 ms
My first impression is that something is not quite right on the other side of the Atlantic. - Brian
My impressions would also be on NL side.
From my home network the NL host responds just fine, before last hop is also XS4ALL IP 194.109.5.118
-- |------------------------------------------------------------------------------------------| | WinMTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|------|------|------|------| | - 0 | 3 | 3 | 0 | 0 | 0 | 0 | | 81.82.192.1 - 0 | 3 | 3 | 7 | 23 | 53 | 53 | | 213.224.202.17 - 0 | 3 | 3 | 8 | 9 | 11 | 9 | | Request timed out. - 100 | 1 | 0 | 0 | 0 | 0 | 0 | | Request timed out. - 100 | 1 | 0 | 0 | 0 | 0 | 0 | | 213.46.183.101 - 0 | 3 | 3 | 13 | 14 | 16 | 16 | | Request timed out. - 100 | 1 | 0 | 0 | 0 | 0 | 0 | | 84.116.134.54 - 0 | 3 | 3 | 13 | 14 | 16 | 13 | | 194.109.7.209 - 0 | 3 | 3 | 13 | 13 | 14 | 14 | | 194.109.5.6 - 0 | 3 | 3 | 13 | 13 | 14 | 13 | | 194.109.5.118 - 0 | 3 | 3 | 14 | 14 | 15 | 14 | | 213.222.29.194 - 0 | 3 | 3 | 13 | 14 | 15 | 14 | |________________________________________________|______|______|______|______|______|______| --
From a VM in France and the UK it also works.
Maybe some filtering or a wrong route on your side Rob?
73,
Ruben - ON3RVH
-----Original Message----- From: 44Net 44net-bounces+on3rvh=on3rvh.be@mailman.ampr.org On Behalf Of Brian Kantor Sent: dinsdag 2 april 2019 14:23 To: AMPRNet working group 44net@mailman.ampr.org Subject: Re: [44net] RIP problems?
Hmm. A traceroute from my home network (not involving AMPRNet) from San Diego to the main NL gateway 213.222.29.194 gives a fairly clean 15 hop path with less than 200 ms delay.
traceroute to 213.222.29.194 (213.222.29.194), 30 hops max, 60 byte packets 1 192.168.1.1 0.333 ms 0.369 ms 0.414 ms 2 142.254.184.25 11.739 ms 12.744 ms 12.677 ms 3 76.167.17.129 31.024 ms 31.962 ms 32.003 ms 4 72.129.3.58 15.552 ms 16.508 ms 23.692 ms 5 * * * 6 * * * 7 * 66.109.6.6 24.977 ms 22.664 ms 8 66.109.6.141 20.489 ms 23.461 ms 66.109.6.137 23.351 ms 9 134.222.248.37 21.239 ms 20.207 ms 25.972 ms 10 134.222.49.16 175.477 ms 173.982 ms 171.936 ms 11 134.222.48.91 169.607 ms 175.150 ms 173.144 ms 12 134.222.48.223 172.708 ms 173.069 ms 171.491 ms 13 * 134.222.93.145 191.036 ms 190.947 ms 14 194.109.5.58 195.652 ms 194.109.5.78 185.633 ms 184.671 ms 15 213.222.29.194 179.788 ms 174.224 ms 168.986 ms
A traceroute from UCSD to the same gateway gets some very strange routing:
traceroute to 213.222.29.194 (213.222.29.194), 64 hops max, 40 byte packets 1 169.228.34.82 0.622 ms 0.583 ms 0.535 ms 2 132.239.255.49 0.238 ms 0.202 ms 0.203 ms 3 132.239.254.162 3.549 ms 1.461 ms 0.231 ms 4 137.164.23.176 0.459 ms 0.607 ms 1.000 ms 5 137.164.11.8 2.223 ms 137.164.11.10 2.038 ms 137.164.11.8 2.095 ms 6 137.164.11.22 2.947 ms 137.164.11.24 2.876 ms 137.164.11.22 2.925 ms 7 137.164.11.27 3.644 ms 137.164.11.35 3.479 ms 137.164.11.7 4.481 ms 8 64.57.20.82 2.847 ms 3.703 ms 2.900 ms 9 162.252.70.25 12.336 ms 12.178 ms 12.221 ms 10 162.252.70.23 14.607 ms 14.675 ms 14.669 ms 11 162.252.70.20 19.928 ms 19.837 ms 19.953 ms 12 162.252.70.15 34.874 ms 35.096 ms 35.076 ms 13 162.252.70.17 35.398 ms 39.148 ms 35.305 ms 14 64.57.20.114 39.820 ms 39.911 ms 39.877 ms 15 206.223.118.75 42.654 ms 39.976 ms 39.988 ms 16 134.222.48.21 159.063 ms 159.275 ms 159.233 ms 17 134.222.48.32 158.824 ms 159.724 ms 158.765 ms 18 134.222.48.0 163.547 ms 170.078 ms 163.569 ms 19 134.222.48.15 158.977 ms 162.456 ms 158.940 ms 20 134.222.94.217 158.773 ms 162.472 ms 162.756 ms 21 194.109.5.4 158.986 ms 194.109.5.6 162.698 ms 158.975 ms 22 194.109.5.58 165.177 ms 194.109.5.118 159.376 ms 194.109.5.78 159.058 ms 23 * * * 24 * * * 25 * * *
and in fact never resolves.
A traceroute to 213.222.29.194 from a data center in Texas shows some confusion inside a network 134.222.48.x, which appears to be titled 'eurorings', and a further several hops inside xs4all.net:
traceroute to 213.222.29.194 (213.222.29.194), 64 hops max, 40 byte packets 1 199.249.230.254 0.444 ms 0.307 ms 0.267 ms 2 184.105.25.105 0.364 ms 0.282 ms 0.307 ms 3 206.223.118.75 0.338 ms 0.333 ms 0.398 ms 4 134.222.48.21 125.646 ms 125.439 ms 125.700 ms 5 134.222.48.32 125.426 ms 125.801 ms 127.761 ms 6 134.222.48.2 129.981 ms 134.222.49.98 126.027 ms 134.222.48.0 130.044 ms 7 134.222.48.15 128.921 ms 125.288 ms 125.650 ms 8 * * * 9 194.109.5.6 125.795 ms 125.626 ms 194.109.5.4 125.878 ms 10 194.109.5.78 129.396 ms 126.613 ms 194.109.5.58 125.455 ms 11 213.222.29.194 129.366 ms 129.264 ms 130.198 ms
My first impression is that something is not quite right on the other side of the Atlantic. - Brian _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
My first impression is that something is not quite right on the other side of the Atlantic. - Brian
Aint that a recuring problem? Talking historicaly wise not network wise ;-)
Sorry I had to say it.
Pierre VE2PF
-
Brian Kantor -
pete M -
Rob Janssen -
Ruben ON3RVH -
SP2L＠wp.pl