Roland,
I guess the best way to answer this is, what Network Operating System are you using?
- Windows - unknown (I last attempted in 2012) - *nix - only one tunnel need to be enumerated - Cisco - multiple tunnels are needed
You can see this from the relevant Wikis.
73,
- Lynwood KB3VWG
Rob,
Nashville...
What is a scenario we could re-route (swiftly) if such a region's router sat there?
What technology for end operators (I'm now partial to Wireguard, lol)?
(Mind you, in our current scenario, only the direct users would be offline.)
- KB3VWG
---
It is all a bit outdated. I hope the community sometime soon decides to migrateto a somewhat more modern setup that does not mandate a full mesh tunnel networkwhen users do not desire to have it.(i.e. establish a number of routers in datacenters around the world so one canconnect to one or a few routers instead of to all individual end users, manyof whom are not even operational) Rob
Multiple endpoints. Have more than one router per region or the possibility to announce the subnet through another region and tunnel back to there. If region A goes down, region B takes over and tunnels to region A will have to be (auto would be my preference) rebuild to region B
Ruben - ON3RVH
On 28 Dec 2020, at 21:53, lleachii--- via 44Net 44net@mailman.ampr.org wrote:
Rob,
Nashville...
What is a scenario we could re-route (swiftly) if such a region's router sat there?
What technology for end operators (I'm now partial to Wireguard, lol)?
(Mind you, in our current scenario, only the direct users would be offline.)
- KB3VWG
It is all a bit outdated. I hope the community sometime soon decides to migrateto a somewhat more modern setup that does not mandate a full mesh tunnel networkwhen users do not desire to have it.(i.e. establish a number of routers in datacenters around the world so one canconnect to one or a few routers instead of to all individual end users, manyof whom are not even operational) Rob _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
If we replaced the IPIP mesh with a collection of geographically distributed VPN servers (OpenVPN?) which advertised routes for /24 (or larger) subnets, and dual homed each subnet to two or more VPN servers we would have pretty good redundancy and could end the distribution of IPIP endpoints and just let the Internet route between subnets.
------------------------------ John D. Hays - K7VE Kingston, WA http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays
Sorry for my previous unreadable post, I forgot to deactivate encryption :-(
Hi Lynwood, tnx for coming back,
On 28.12.20 at 21:41 wrote lleachii@aol.com:
I guess the best way to answer this is, what Network Operating System are you using?
...
- *nix - only one tunnel need to be enumerated
I am running Debian stock 4.19.160-2 kernel.
And it seems that indeed on this system the required tunnels indeed seem to be created on-demand.
So since my post I've managed to set up my machine finally, by careful trying the different solutions documented in the various scripts available in the wiki and by learning about linux tunnels.
But as I was trying to setup my machine the "debian way" I first had to overcome some hurdles. Specifically I was trying to set up the tunnel by using the "tunnel" stanza in /etc/network/interfaces and that requires explicit IP addresses for the endpoints. While I was experimenting with this I found out that always, even after successful ifdown of my tunnel, a single tunnel device remained. This device could not be removed by any means, once there. Further investigation leads me to believe that this is "the" device that is able to create tunnels "on the fly". (So far I have not started to read the source of the ipip driver, which I believe will be the only place where I can hope to get a definitive answer.)
However then the debian way to set up things is not so straight forward any more. At least I was able to come up with a solution (somewhat of a hack, but not worse than the other scripts) by ifup-ing my net by specifying the setup using the "manual" stanza.
...
You can see this from the relevant Wikis.
Unfortunately I was not able to find some explicit information on the issue within the wikis. Would you pls be so kind and point me to the relevant article?
In either case, if you are interested, here is my setup of /etc/network/interfaces:
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface auto lo iface lo inet loopback
# The primary network interface allow-hotplug enp1s0 iface enp1s0 inet dhcp
auto enp2s0 iface enp2s0 inet static address <replace this with your ISP's IP> netmask <replace this with your ISP's netmask> gateway <replace this with your ISP's gateway> dns-nameservers <replace this with your ISP's name servers>
auto tunl0 iface tunl0 inet manual mtu 1440 up ip addr add <your 44net assignement/32> dev $IFACE up ip tunnel change ttl 64 mode ipip $IFACE up ip link set dev $IFACE up up ip rule add to 44.0.0.0/9 table 44 priority 44 up ip rule add to 44.128.0.0/10 table 44 priority 44 up ip rule add <your 44net assignement/32> table 44 priority 45 up ip route add default dev $IFACE via 169.228.34.84 onlink table 44 up /usr/sbin/ampr-ripd -s -r -i tunl0 -t 44 -L "OE1RSA@JN88DF" down killall ampr-ripd down ip route flush table 44 down ip rule del <your 44net assignement/32> down ip rule del to 44.128.0.0/10 down ip rule del to 44.0.0.0/9 --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
vy 73 de Roland, oe1rsa
Roland, Am I to understand you're bothered that the Kernel shows the tunl0 interface?
* You simply have to reboot the machine with the script removed OR run 'modprobe -r ipip'.
* These routes are invalid: up ip rule add to 44.0.0.0/9 table 44 priority 44 up ip rule add to 44.128.0.0/10 table 44 priority 44
* Do you have ampr-ripd or rip44d running?
- https://wiki.ampr.org/wiki/Setting_up_a_gateway_on_Linux
- https://wiki.ampr.org/wiki/Ubuntu_Linux_Gateway_Example
- https://wiki.ampr.org/wiki/Startampr#Script
- KB3VWG
The BGP via 2+n tunnels to data centers sounds like it could work. I sent Chris an email. I'd definitely help out where I can.
- KB3VWG
Rob,
* FYI - Wireguard has a Windows client; but I get your point about being OS/NOS agnostic * I honestly understand there to exist 2 common paradigms: 1.) those who route IPs to others/clients/hosts; and 2.) those who only tunnel the AMPR IPs to a single device. Your statement primarilly covers the latter use case. * I know of no embedded "Windows routers" (well there are small x86_64 machines) * IP Protocol No. 4 (IPENCAP) is possible on Windows (specifics unclear)...but there was never much support to ensure ampr-ripd/rip44d/something was tested/working, at least when I was attempting in 2012 * I found out even if I got a Windows machine working, if I wanted to do DNS (which I noted to late Brian that I would for the MDC Section), I leaned the Windows dns.exe executable will crash attempting to load our Public Forward and Reverse Zones - so I still need a *nix server/router
- KB3VWG
---
I think we should avoid running into traps like "let us choose that new wireguard as thestandard protocol to be used by everything" as we would again exclude everything outside of Linux and OpenWRTand end up in the same situation as we now are with IPIP mesh: always requiring the user to install a Linux box.
Roland,
I should have more clearly asked: is ampr-ripd running as expected?
But I can see you appear on the AMPR Map and I can ping that IP from my AMPR-only address. So this means your GW a route to mine on its table.
Kudos!
http://www.yo2loj.ro/ampr-map/
- KB3VWG
-----Original Message----- From: lleachii@aol.com To: 44net@mailman.ampr.org 44net@mailman.ampr.org; roland.schwarz@blackspace.at roland.schwarz@blackspace.at Sent: Tue, Dec 29, 2020 7:28 am Subject: Re: ipencap routing question
* Do you have ampr-ripd or rip44d running?
Lynwood,
On 29.12.20 at 13:28 wrote lleachii@aol.com:
Am I to understand you're bothered that the Kernel shows the tunl0 interface?
:-) I was, but not more
- You simply have to reboot the machine with the script removed OR run
'modprobe -r ipip'.
The modules is available by default in stock debian.
- These routes are invalid:
up ip rule add to 44.0.0.0/9 table 44 priority 44
up ip rule add to 44.128.0.0/10 table 44 priority 44
Ok, why do you think so? These are not my invention, I copied them from templates in the ampr wiki. AFAIK they refelct the fact of the sold upper quater of the addresses, no?
- Do you have ampr-ripd or rip44d running?
No, I am using ampr-ripd.
vy 73 Roland, oe1rsa
- Do you have ampr-ripd or rip44d running?
No, I am using ampr-ripd.
Should have been: Yes, I am using ampr-ripd. Of course ;-)
Roland,
* I tested on a Ubuntu system, so the 'sudo modprobe -r ipip' command worked as tested. I gleaned to use it '-r' from the Startampr wiki (I developed the script with PE1CHL and others on the mailing group here). Therefore, I cannot speak specifically to why Debian automatically pre-loads the Kernel module. Can you explain the issue this presents for you? Could a firewall rule fix it? You only have a single /32 IP - this shouldn't cause a major issue to your setup.
* Can you show the Wiki URL you're referencing that tells you to make a route for 44.0.0.0/9 and 44.128.0.0/10 - so it may be corrected? I know the routes to be invalid; because they do not specify where those subnets in the /9 and /10 are exactly located (e.g. your IP 86.5x.x.42 to reach 44.130.240.3/32). That's what ampr-ripd or rip44d does. You should now be able to see valid routes by running the command 'ip route show table 44'
* You noted you're running ampr-ripd...but answered no....that confused me, but nonetheless I see it's running successfully; perhaps it was semantics or a language barrier.
- KB3VWG
Am I to understand you're bothered that the Kernel shows the tunl0 interface?
:-) I was, but not more
- You simply have to reboot the machine with the script removed OR run
'modprobe -r ipip'.
The modules is available by default in stock debian.
- These routes are invalid:
up ip rule add to 44.0.0.0/9 table 44 priority 44
up ip rule add to 44.128.0.0/10 table 44 priority 44
Ok, why do you think so? These are not my invention, I copied them from templates in the ampr wiki. AFAIK they refelct the fact of the sold upper quater of the addresses, no?
- Do you have ampr-ripd or rip44d running?
No, I am using ampr-ripd.
Lynwood,
On 29.12.20 at 14:20 wrote lleachii@aol.com:
- I tested on a Ubuntu system, so the 'sudo modprobe -r ipip' command
worked as tested. I gleaned to use it '-r' from the Startampr wiki (I developed the script with PE1CHL and others on the mailing group here). Therefore, I cannot speak specifically to why Debian automatically pre-loads the Kernel module. Can you explain the issue this presents for you?
It doesn't present any issues at all. I just didn't understand and I was curious. Many of the scripts on the wiki unfortunately are only recipes without much help if you want to learn "cooking". I just wanted to understand. So if I ask: why does it say: tunl0@NONE I wanted an answer for this, but what I got (another list) was something like: this is ok, don't bother. I don't think that this is what an interested student should be satisfied with.
Could a firewall rule fix it? You only have a single /32 IP - this shouldn't cause a major issue to your setup.
Yes I have a single host now, but I hope to get a larger space to extend my learning.
- Can you show the Wiki URL you're referencing that tells you to make a
route for 44.0.0.0/9 and 44.128.0.0/10 - so it may be corrected?
Sure, but since you wrote that you are a coauthor of this script, I possibly didn't yet understand its meaning in full:
https://www.qsl.net/kb9mwr/wapr/tcpip/startampr via https://www.qsl.net/k/kb9mwr//wapr/tcpip/ampr-ripd.html via https://wiki.ampr.org/wiki/Setting_up_a_gateway_on_Linux#Example_Gateway_Con...
Oh, ah! Now if I try to recap: Can it be the case that you read "route" where I wrote "rule"?
I know the routes to be invalid; because they do not specify where those subnets in the /9 and /10 are exactly located (e.g. your IP 86.5x.x.42 to reach 44.130.240.3/32).
Of course, because it is rules, not routes.
That's what ampr-ripd or rip44d does. You should now be able to see valid routes by running the command 'ip route show table 44'
Works like a charm.
- You noted you're running ampr-ripd...but answered no....that confused
me, but nonetheless I see it's running successfully; perhaps it was semantics or a language barrier.
I've corrected the issue. Sorry, I read only the last part ripd44 and said no. After I hit the send button I have seen what I wrote :-(
btw: mni tnx for the script!
73 de roland, oe1rsa
Roland,
My apologies, those being IP RULES and not ROUTEs....you are correct. Thanks for the clarity.
Be mindful though, some routes will use your Ethernet and will therefore need to be masqueraded. I was going to provide an example of such an an IP - but as someone else said, those routes appears down or at least un-pingable. You can see these routes on your device by running the command 'ip route show table 44 | grep enp2s0'
- KB3VWG
Am 29.12.20 um 15:32 schrieb lleachii@aol.com:
My apologies, those being IP RULES and not ROUTEs....you are correct. Thanks for the clarity.
No problem.
Be mindful though, some routes will use your Ethernet and will therefore need to be masqueraded. I was going to provide an example of such an an IP - but as someone else said, those routes appears down or at least un-pingable. You can see these routes on your device by running the command 'ip route show table 44 | grep enp2s0'
Thank you for pointing this out. I can see two IPS, the first I have no idea, the second is in the german database: I will try to ask Jann DG8NGN about its purpose. The german database shows:
https://hamnetdb.net/?q=44.130.104.0/21
test SNMP monitoring
73
Let me explain those rules a little, since the wiki just puts them there without a "why" explanation...
In that specific setup mode, we have some routing tables (table 44 an 45 could actually have any number as long as the configuration is modified accordingly):
- the main table (32767), holding our regular routes, like default gateway, subnets and other static stuff. Usually it is something like:
192.168.0.0/24 via eth1
default via eth1
- table default (32767), usually empty, holds the default routes if the main table does not specify a default route
- table 44 will hold all routes created by the ampr-ripd daemon. They are in a format like
<subnet> via <gateway> dev <tunnel> onlink
Note that there is usually no default gateway in this table
- optional table 45, holding the return route for connections initiated from the internet to your 44net machine Usually this holds a single route default via 169.228.34.84 dev <tunnel> onlink
Now let's come to the rules:
They tell the system, that routes to those subnets (44.0.0.0/9 and 44.128.0.0/10) should be looked up in table 44 first. If found, those routes will be used (ipip encap to the proper gateway, as defined in that 'via'). If the route is not found, the system will fall back to the main table, do the lookup there and in the end will use the default gateway as defined. If there is a default gateway defined in table 44, it will use that one (this will burden the ampr gateway but you will have an outgoing 44 address - do not use it for ALL of your internet access).
Table 45, just to complete the description, has the role of replying to internet connection requests from the via the tunnel. For this, you need to mark incoming requests with a connection mark, 45, and all those marked with connection mark 45 with a routing mark of 45.
So a minimal gateway start script would look like this, assuming that the tunnel interface name is tun44 and it is configured properly before starting this script, e.g. in 'interfaces':
#!/bin/sh
MY_IP=`ip addr list dev tun44 | grep inet | awk '{print $2}'`
# wait for tunnel interface while [ "$MY_IP" == "" ]; do sleep 1 MY_IP=`ip addr list dev tun44 | grep inet | awk '{print $2}'` done
# AMPR routes go to table 44 # ip rule add from $MY_IP table 44 ip rule add to 44.0.0.0/9 table 44 ip rule add to 44.128.0.0/10 table 44
# default AMPR reply route is in table 45 # ip route add default via 169.228.34.84 dev tun44 table 45 onlink
# mark incoming and route replies via table 45 # ip rule add fwmark 45 table 45 iptables -t mangle -A PREROUTING -i tun44 ! -s 44.0.0.0/8 -j CONNMARK --set-mark 45 iptables -t mangle -A PREROUTING ! -i tun44 -m connmark --mark 45 -j CONNMARK --restore-mark iptables -t mangle -A OUTPUT -m connmark --mark 45 -j CONNMARK --restore-mark
# start ampr-ripd (add your -a parameter if needed) ampr-ripd -s -t 44 -i tun44 -m 90
Of course, this can be migrated to 'interfaces' as 'up' steps (so please adapt as 44.128.x.y and 192.x.y.z are not valid, note the rmmod at the end to clear that tunnel0)
iface ampr0 inet static address 44.128.x.y netmask 255.255.255.255 metric 100 pre-up ip tun add ampr0 mode ipip ttl 64 local 192.x.y.z dev eth0 # uncomment for bgp 44 routing via ampr-gw # up ip route add 44.0.0.0/9 via 169.228.34.84 dev ampr0 onlink table 44 onlink # up ip route add 44.128.0.0/10 via 169.228.34.84 dev ampr0 onlink table 44 onlink up ip route add default via 169.228.34.84 dev ampr0 onlink table 45 onlink up ip rule add from 44.128.x.y table 44 up ip rule add to 44.0.0.0/9 table 44 up ip rule add to 44.128.0.0/10 table 44 up ip rule add fwmark 45 table 45 up ampr-ripd -s -t 44 -i ampr0 -m 90 -L n0call@aa00aa post-down killall ampr-ripd post-down ip rule del fwmark 45 table 45 post-down ip rule del to 44.128.0.0/10 table 44 post-down ip rule del to 44.0.0.0/9 table 44 post-down ip rule del from 44.128.x.y table 44 post-down ip tunnel del ampr0 post-down rmmod ipip
So there it is, and maybe it helps.
Feel free to add some of it to the Wiki if it seems useful (I don't like modifying things written by others...).
Marius, YO2LOJ
On 29.12.2020 14:28, lleachii--- via 44Net wrote:
Roland, Am I to understand you're bothered that the Kernel shows the tunl0 interface?
You simply have to reboot the machine with the script removed OR run 'modprobe -r ipip'.
These routes are invalid:
up ip rule add to 44.0.0.0/9 table 44 priority 44 up ip rule add to 44.128.0.0/10 table 44 priority 44
- Do you have ampr-ripd or rip44d running?
- https://wiki.ampr.org/wiki/Startampr#Script
- KB3VWG
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
I forgot to state this..
If doing the 'interfaces' thing, you still need to run the thing below somewhere after startup. in your firewall setup..
On 29.12.2020 18:13, Marius Petrescu via 44Net wrote:
# mark incoming and route replies via table 45 # ip rule add fwmark 45 table 45 iptables -t mangle -A PREROUTING -i tun44 ! -s 44.0.0.0/8 -j CONNMARK --set-mark 45 iptables -t mangle -A PREROUTING ! -i tun44 -m connmark --mark 45 -j CONNMARK --restore-mark iptables -t mangle -A OUTPUT -m connmark --mark 45 -j CONNMARK --restore-mark