There seems to be a bit of confusion as to how linux routes via policy routing. The tool which appears to be the most flexible is "ip" found in the iproute2 package.
The two key switches are "route" and "rule", and they do exactly what they sound like; one manages routes and route-tables, while the other manages the ruleset in which these routes/tables are called upon. Linux begins with a main route table and a default ruleset in which that table is used. Typically you don't even notice this as it's created with the configuration of the standard network devices upon boot. Two rules will be applied for this main route table: 1) main 2) default The rules are such that the priority to these tables is so low almost any other rule will take priority over it. That's what makes amprnet routing for linux quite simple.
The rule you want to make for amprnet is such that any inbound OR outbound routing sourced as 44-net uses it's own route table, with a priority higher than the main table rule. As long as the routes are in this matched table, the kernel will act as an amprnet router just fine even to entities such as xNOS, Xnet, etc. So if you want proper packet flow make sure all paths and rules match for the source you wish to route - in our case it's 44/8:
A sample standard path would look like:
commercial to commercial/nat inet/0 <----> linux-nat or com IP table main
commercial to your ampr inet/0 <----> ucsd/bgp host ucsd/bgp host <---> linux 44-tunl0 via rule 1/table 1 <---> node/bbs/dxc
ampr to ampr (tunnel only shown) 44/8-tunl0 <---> linux tunl0/rule 1/table 1 <---> node/bbs/dxc
ampr to ampr to xNOS/Xnet (tunnel only shown) 44/8-tunl0 <---> linux tunl0/rule 1/table 1 <---> tun0/tap0-xNOS/Xnet
This shows that the Xnet or xNOS tun/tap interfaces need to be included within the ruleset that matches table 1 or else it will become unroutable. Also you need to insure ip_forwarding is enabled, and your firewalling permits ip protocol 4 (ipencap), and ip protocol 93 (AX.25)
A simple script which can do this for you is found at http://n1uro.ampr.org/linuxconf/dotun.html
# --- dotun.sh --- #! /bin/bash
# dotun.sh script written by N1URO # June, 2013 # enter in your information below, these are used for creating a # gateway and linking to the amprnet:
AMPRIP='x.x.x.x' IPMASK='x.x.x.x' COMMIP='x.x.x.x' NOSIP='x.x.x.x'
case "$1" in start) # Load your ipencap module in the kernel: modprobe ipip
# Allow ip forwarding from amprnet to your ethernet interface echo "1" > /proc/sys/net/ipv4/ip_forward
# load RIPv2 routing using the ampr-ripd daemon /usr/local/sbin/ampr-ripd -t 1 -a $COMMIP -p <password> -i tunl0 -v -s -r
# Configure your ipencap tunnel interface - required for the amprnet ifconfig tunl0 $AMPRIP netmask $IPMASK up
# Allow traceroutes to work on the amprnet: ip tunnel change tunl0 mode ipip ttl 64 tunl0 pmtudisc
# If you run xNOS, configure a tun/tap interface: ifconfig tun0 $AMPRIP pointopoint $NOSIP up
# configure your rointing accordingly: ip route add $NOSIP dev tun0 onlink table 1 src $AMPRIP ip route add default via 169.228.66.251 dev tunl0 src $AMPRIP onlink table 1
# configure policy routing so that frames from/to your 44-net IP # know how to route accordingly: ip rule add from 44/8 pref 1 table 1 ip rule add to 44/8 pref 1 table 1
# script is done, exit as a clean flush. exit 0 ;;
stop) # Unload what we loaded above: ip rule del to 44/8 pref 1 table 1 ip rule del from 44/8 pref 1 table 1 ifconfig tunl0 down ifconfig tun0 down killall -TERM ampr-ripd modprobe -r ipip exit 0 ;;
restart) dotun stop sleep 3 dotun start exit 0 ;; *) echo "Usage: dotun {start|stop|restart}" exit 0 ;;
esac exit 0 --- EOF ---
And as an addendum to Brian's exclelent tutorial:
If you need to use other routing protocols internally in your network (OSPF, BGP, RIP), take notice that the routes created by tools like quagga reside in the main table. In that case, the ampr routes have to go into table main IF YOU NEED them to interact with each other (you can use the parameter -m to change their metric to fit your needs).
Marius, YO2LOJ
Now we are into the New year 2015
I am again looking at encouraging and supporting UK Sysop UK connectivity to the amprnet as I did in 2013 and 2014.
Amprnet Connectivity 28 November 2015 GB7CIP currently act as gateways for 44.131.161 via GB7IPF SouthBucks these UDP connected down stream 44.131.168 via M1DUO Cambs amprnet IP connections. 44.131.182 via GBINE SW Essex 44.131.210 via GB7COW N Devon You can test if these are connected by pinging 44.131.161.228 44.131.168.129 44.131.182.2 44.131.210.1 44.131.244.1 they should also respond to a telnet connection Due to changes at http://portal.ampr.net these subnets appear to be currently cut of from the main world amprnet.
G4APL is waiting for the portal amprnet team to advise what the new procedure will be. when the updated software has been corrected. (Had previously email the subnet affected).
Still not working as at 4 January 2015. Tested a series of known gateways from the 161 182 210 subnets. Monitored outgoing pings via through the various in/out interfaces .
Confirmed all downstream and up stream addresses can all be reached from gb7cip(44.131.244.1)
Has the 'Tree swing been replaced' ? The simple plank, two ropes tied to the branch. Worked well before.
I would appreciated feedback of your ping tests and telnet connects. I will use this feedback to attempt ping, telnet back from the remote downsteam hosts. When I retest connectivity and see how bad this problem is.
73 de Paul G4APL SysOP GB7CIP
Hi Paul,
G4APL is waiting for the portal amprnet team to advise what the new procedure will be. when the updated software has been corrected. (Had previously email the subnet affected).
As I have said to you in previous emails, if you need me to add anything manually as an interim measure you just need to drop me an email with the details!
Regards, Chris
Hello Paul,
I checked a little and there are a lot of issues. - gb7cip is listed in the encap data, but is not responding. Gateway is reachable. - 44.131.161.0/24 has no entry in the encap list (needs to be registered with the same gw as gb7cip) - 44.131.182.0/24 - the same - 44.131.210.0/24 - the same
Now regarding 44.131.161.0/24: There are 2 subnets entries in the encap data: 44.131.161.56/29 - no ping response from any host, gateway is reachable 44.131.161.100/30 - no ping response from any host, gateway not responding to ping
So, unless subnets 161, 182 and 210 are not in the encap data with a corect gateway, and the gateway and subiacent chain doesn't forward the needed traffic, they are not reachable from the mesh network.
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Paul Lewis Sent: Sunday, January 04, 2015 16:48 To: AMPRNet working group Subject: [44net] GB7CIP Amprnet Connectivity
(Please trim inclusions from previous messages) _______________________________________________ ...
Amprnet Connectivity 28 November 2015 GB7CIP currently act as gateways for 44.131.161 via GB7IPF SouthBucks these UDP connected down stream 44.131.168 via M1DUO Cambs amprnet IP connections. 44.131.182 via GBINE SW Essex 44.131.210 via GB7COW N Devon You can test if these are connected by pinging 44.131.161.228 44.131.168.129 44.131.182.2 44.131.210.1 44.131.244.1
...
On 05/01/15 03:48, Paul Lewis wrote:
(Please trim inclusions from previous messages) _______________________________________________ Now we are into the New year 2015
I am again looking at encouraging and supporting UK Sysop UK connectivity to the amprnet as I did in 2013 and 2014.
Hi Paul,
Some test results from here in NZL.
44.131.161.228 Ping Reply OK - No Telnet
44.131.168.129 No Ping - No Telnet
44.131.182.2 No Ping - No Telnet
44.131.210.1 Ping Reply OK - No Telnet
44.131.244.1 Ping Reply OK - No Telnet
Regards ..... Peter ZL2BAU (44.147.210.26)
Hello Peter
Many thanks for the feedback Chris added in the required subnets for me this evening.
I have seen inbound pings and replies to 182.2 earlier this evening coming from 'outside' via the ipipencap tunnel.
I agree I am not getting a response locally at this moment from 182.2 Arh it's back. pinged your address. G4APL de SWESX:GB7INE-1> pi 44.147.210.26 {SWESX:GB7INE-1} Pinging 44.147.210.26... Type <RETURN> to abort {SWESX:GB7INE-1} 44.147.210.26 rtt: 856ms (ttl=63) G4APL de SWESX:GB7INE-1>
re 168.129 his system s pinging 244.1. Looks like the sysop there need to add the default net44/8 back after his changes there.
I forgot to mention telnet port either 23 or 6301 are used down this way.
This is good news. 73 de Paul G4APL GB7CIP In message 54A9CBF6.4080506@gmail.com, Peter Mallett peter.zl2bau@gmail.com writes
Hi Paul,
Some test results from here in NZL.44.131.161.228 Ping Reply OK - No Telnet
44.131.168.129 No Ping - No Telnet
44.131.182.2 No Ping - No Telnet
44.131.210.1 Ping Reply OK - No Telnet
44.131.244.1 Ping Reply OK - No Telnet
Regards ..... Peter ZL2BAU (44.147.210.26)