.> That is correct - there are plenty of gateways in the portal that have no subnets attached to them, but they are filtered out of the encap list.
Ok, then apparently these "rogue gateways" (they happen to be all from Poland) are using some method to use the encap file to load tunnel interfaces and static routes.
I had expected them to use the script that Marius wrote for MikroTik, but in that case they would not receive the RIP broadcasts and so would not be able to build all those tunnels (and send MikroTik neighbor discovery on them).
I suspect there has been some "how to setup an AMPRnet gateway" doc going around in Poland... Tom SP2L is already looking at it.
Maybe you can just remove all gateways that have had no subnets for some time. Although that will likely not fix anything...
Rob
Rob,
I think the explanation is far less sinister. Poland has been reconfiguring gateways and deleting subnets for the last month or more, and I'll bet what you're seeing is just the result of old data not yet expired out of Marius' program or the script that drives the Mikrotiks. They may just have old encap files.
See if they go away by themselves in a few days. - Brian
On Sun, Mar 25, 2018 at 07:08:13PM +0200, Rob Janssen wrote:
.> That is correct - there are plenty of gateways in the portal that have no subnets attached to them, but they are filtered out of the encap list.
Ok, then apparently these "rogue gateways" (they happen to be all from Poland) are using some method to use the encap file to load tunnel interfaces and static routes.
I had expected them to use the script that Marius wrote for MikroTik, but in that case they would not receive the RIP broadcasts and so would not be able to build all those tunnels (and send MikroTik neighbor discovery on them).
I suspect there has been some "how to setup an AMPRnet gateway" doc going around in Poland... Tom SP2L is already looking at it.
Maybe you can just remove all gateways that have had no subnets for some time. Although that will likely not fix anything...
Rob _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hi,
The script expires the routes and tunnels after 30 minutes.
It also disables neighbor discovery on the tunnel interfaces it creates.
The only issue I see is that it could be a 6.41.x firmware running an older script version.
In these firmwares, the ND disabling method has changed, so the script will fail if not updated to the last version (3.2).
The failing of the script will also prevent the timeout of obsolete routes and tunnels.
Maybe this helps.
Marius, YO2LOJ
On 25.03.2018 21:12, Brian Kantor wrote:
Rob,
I think the explanation is far less sinister. Poland has been reconfiguring gateways and deleting subnets for the last month or more, and I'll bet what you're seeing is just the result of old data not yet expired out of Marius' program or the script that drives the Mikrotiks. They may just have old encap files.
See if they go away by themselves in a few days.
- Brian
On Sun, Mar 25, 2018 at 07:08:13PM +0200, Rob Janssen wrote:
.> That is correct - there are plenty of gateways in the portal that have no subnets attached to them, but they are filtered out of the encap list.
Ok, then apparently these "rogue gateways" (they happen to be all from Poland) are using some method to use the encap file to load tunnel interfaces and static routes.
I had expected them to use the script that Marius wrote for MikroTik, but in that case they would not receive the RIP broadcasts and so would not be able to build all those tunnels (and send MikroTik neighbor discovery on them).
I suspect there has been some "how to setup an AMPRnet gateway" doc going around in Poland... Tom SP2L is already looking at it.
Maybe you can just remove all gateways that have had no subnets for some time. Although that will likely not fix anything...
Rob _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
An addendum:
The sending of ND packets also happen if there is a latest version (3.2) script running on a pre-6.41 firmware.
So DO NOT UPDATE to script version 3.2 for ROS firmwares prior to 6.41.
I think this is the case here.
On 26.03.2018 00:39, Marius Petrescu wrote:
Hi,
The script expires the routes and tunnels after 30 minutes.
It also disables neighbor discovery on the tunnel interfaces it creates.
The only issue I see is that it could be a 6.41.x firmware running an older script version.
In these firmwares, the ND disabling method has changed, so the script will fail if not updated to the last version (3.2).
The failing of the script will also prevent the timeout of obsolete routes and tunnels.
Maybe this helps.
Marius, YO2LOJ
On 25.03.2018 21:12, Brian Kantor wrote:
Rob,
I think the explanation is far less sinister. Poland has been reconfiguring gateways and deleting subnets for the last month or more, and I'll bet what you're seeing is just the result of old data not yet expired out of Marius' program or the script that drives the Mikrotiks. They may just have old encap files.
See if they go away by themselves in a few days. - Brian
On Sun, Mar 25, 2018 at 07:08:13PM +0200, Rob Janssen wrote:
.> That is correct - there are plenty of gateways in the portal that have no subnets attached to them, but they are filtered out of the encap list.
Ok, then apparently these "rogue gateways" (they happen to be all from Poland) are using some method to use the encap file to load tunnel interfaces and static routes.
I had expected them to use the script that Marius wrote for MikroTik, but in that case they would not receive the RIP broadcasts and so would not be able to build all those tunnels (and send MikroTik neighbor discovery on them).
I suspect there has been some "how to setup an AMPRnet gateway" doc going around in Poland... Tom SP2L is already looking at it.
Maybe you can just remove all gateways that have had no subnets for some time. Although that will likely not fix anything...
Rob _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net