-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
while analyzing the routing table on my Mikrotik router, I noticed
that there are 2 gateways for 44.136.0.0/21:
114.198.116.219
203.5.58.162
The encap file has both as well:
route addprivate 44.136/21 encap 203.5.58.162
route addprivate 44.136/21 encap 114.198.116.219
I have tried to create 2 routes for some of my networks via the
portal, but the portal complains with the words "The network overlaps
an existing entry".
I'm now interested to know, if these 2 routes are intended to
co-exist? If yes, how can one create those entries via the portal.
If no, which one is correct and why are there 2 entries?
73 de Marc, LX1DUC
- --
http://lx1duc.mcs.tel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSDJ/oAAoJEHFIN1T8ZA8v8EoP/0HHZn+S4SB0EiqJKjZR8gJG
GL7imNQ0sTZUBE6QMQzXs5+Dr6D++jEYyO36AlqgR0Z2SABs/HFhbuHYV+9Bvb+n
m01m8eKDFJam3uqXGQjsvV5gH/nC8nVJ0hgdsMolatu8B8WBUR02QQDkgq2u11pP
GLwffzANg4/FPLLShYZKk2IL6unh0GFqvW2bePQUZ+8OQv2X1UyDR2jWg4gi7sOO
6imU3CVfKfc53SfPox2De7nLGxsKZsk2O/RCxHEom0MKYCdWtNmoszOTDpxNmkPd
cVJfEZ7zOIBHW+ZYFtsCy1GfoanDlel0jOMm5zNe4WkxeCjPtvD/46vxpPOAh2xk
84lDA3oWY2LYKny6c6YD7zFEcHcX84gR+6gdFFvuaiKU99RizFK0XORJxdVqU4tT
TSBCCt+oW6sPCAJe2vuorA9TyqLMwc6RDg98ZdoEEAYQJke7/CgTBkP+A6EY/U15
HCWk6cXIvHsu2j33K4HoqoaJa74yZMctTnumMu+E4x2Kw+OtCFJfsNt3dTAqeWkr
uuKpeqnjWqPAnT6l3uQOTknwfara79Cw9zWfaG2nnRS8gcIki+Voe+gWAOdiObbF
m0dcmsCBqcyFaRtBHyR0N4BuQC/o5H6rQBgzNFDW54EKraRPLokuM9fW6PF1YJ1l
+TItkIm+J2u9xwlSJbXq
=invI
-----END PGP SIGNATURE-----
Your routes look correct.
Traffic will follow the most 'precise' given route.
For example, lets first use a made-up route to 44.2.12.75.
Since your table does not show a 'specific' subnet,
it will use your rule of "44.0.0.0 169.228.66.251 255.0.0.0"
But, if you use a route to 44.2.14.3, your tables show a more
precise route to that address, so your traffic will use your
route rule of "44.2.14.0 50.79.156.221 255.255.255.248"
The only thing I see in your route that may or may not be of
concern, is the third line. Not sure what your interface "rose0"
goes too, but I see a possible conflict with the route right above it.
You basically have two (2) routes listed for traffic to 44.0.0.0/8
Other than that, that looks good.
As everyone's setups are custom, I don't know what that interface "rose0"
does for your system.
Bill
At 03:32 PM 8/24/2013, you wrote:
>(Please trim inclusions from previous messages)
>_______________________________________________
>Hi all,
>
>My routing table after my AMPRnet GATEWAY has got all the routes via
>RIPv2 using rip44d, looks like this:
>-------------------------------------------------------------------------------------------------------
>Kernel IP routing table
>Destination Gateway Genmask Flags Metric Ref Use Iface
>0.0.0.0 192.168.15.1 0.0.0.0 UG 0 0 0 eth0
>44.0.0.0 169.228.66.251 255.0.0.0 UG 0 0 0 tunl0
>44.0.0.0 0.0.0.0 255.0.0.0 U 30 0 0 rose0
>44.0.0.1 169.228.66.251 255.255.255.255 UGH 0 0 0 tunl0
>44.2.1.32 76.14.161.185 255.255.255.248 UG 0 0 0 tunl0
>44.2.10.0 71.130.72.52 255.255.255.248 UG 0 0 0 tunl0
>44.2.11.1 71.130.72.52 255.255.255.255 UGH 0 0 0 tunl0
>44.2.14.0 50.79.156.221 255.255.255.248 UG 0 0 0 tunl0
>44.2.14.100 50.79.156.221 255.255.255.255 UGH 0 0 0 tunl0
>44.2.50.0 68.189.32.222 255.255.255.248 UG 0 0 0 tunl0
>44.2.50.0 208.74.106.137 255.255.255.0 UG 0 0 0 tunl0
>44.4.2.152 173.167.109.217 255.255.255.255 UGH 0 0 0 tunl0
>44.4.2.153 173.167.109.217 255.255.255.255 UGH 0 0 0 tunl0
>....
>More routes
>-------------------------------------------------------------------------------------------------------------
>
>Is this correct or am I dending all AMPRnet traffic through UCSD.EDU ?
>
>--
>73 de SV1UY
>Demetre Ch. Valaris
>e-mail: demetre.sv1uy(a)gmail.com
>Radio e-mail: sv1uy(a)winlink.org
>(to use my radio e-mail put //WL2K in the beginning of the subject line)
>http://www.qsl.net/sv1uy
>_________________________________________
>44Net mailing list
>44Net(a)hamradio.ucsd.edu
>http://hamradio.ucsd.edu/mailman/listinfo/44net
>http://www.ampr.org/donate.html
Marius,
172.31.255.254 is merely my tunl0 IP address, it's a Private IP in the Class B range, using a /32 (a single host on the network), nothing works using that IP address but ping from my 44LAN.
44.60.44.1 is the IP of my eth1 interface, everything is handled on my device via IP forwarding.
I have my tunnel isolated from my 44LAN and Local/WAN network for testing and troubleshooting purposes. This ensures that I'm in fact routing if a packet moves from one network to another. My eth0 is my public facing LAN - which has a 192.168 IP scheme, IP-in-IP is passed to that network from my Public IP address by my Router. eth1 is my 44LAN with the IP address of 44.60.44.1/24.
my setup script can be seen at http://44.60.44.13/startampr
73,
Lynwood
KB3VWG
> Subject:
> Re: [44net] Routing Tables
> From:
> Bob Tenty <bobtenty(a)gmail.com>
> Date:
> 08/26/2013 08:23 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> The default route to 169.228.66.251 is in most munge scripts I have seen.
> The motivation was that you are reachable in that way if a new gateway
> pops up and you don't refresh your ipip routes at a regular basis.
>
> 73,
>
> VE3TOK
I also need it for the return route to sources outside net 44.
That is why I have it as a default route in table 44.
When someone outside net 44 connects me, I need to return the packets encapsulated
to amprgw where they are decapsulated and returned to the internet.
(every responsible ISP has source address filtering these days)
Rob
> Subject:
> Re: [44net] (no subject)
> From:
> kb9mwr(a)gmail.com
> Date:
> 08/24/2013 10:06 PM
>
> To:
> "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu>
>
>
> The tunnel interface is a gateway to the rest of the class A network.
> You have to allow this by setting a netmask of netmask 255.0.0.0
>
> An your second ethernet interface to your radio LAN, you may set a
> smaller netmask.
>
> Steve
>
>
> Subject:
> Re: [44net] 44Net (no subject)
> From:
> "Marc, LX1DUC" <lx1duc(a)rlx.lu>
> Date:
> 08/24/2013 10:12 PM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
> Netmask surely has a relation to broadcast packets, but not multicast.
>
> Several user on this list use /32 (255.255.255.255) netmask on their
> tunl0 interface.
>
> 73 de Marc
It is not completely clear to me what the netmask on tunl0 really does.
I understand what it does on a local network, but not for tunl0.
For the routing, it does not appear to influence anything. And at least by setting
it this way, I avoid having that unclear route for 44.0.0.0/8 that is added when
tunl0 is created.
Maybe it breaks multicast, but I don't know how. The non-working multicast could
as well be the result of something else, e.g. the limited config included with the
Raspberry Pi that is not really intended to be a complex router (but quite capable of it).
With the -r option to ampr-ripd things appear to work OK.
I use the policy-routing configuration, not a flat routing table.
There is a main routing table with routes for the local network (at the datacenter),
and the default gateway. There is a separate route table 44, with the default route
to amprgw, the specific route for my subnet at home and the local running NET, and
the ampr-ripd also adds all the specific tunnel routes in that table.
There are policy routing rules that select this routing table when the source or the
destination of the packet is in network 44:
44: from 44.0.0.0/8 lookup 44
45: from all to 44.0.0.0/8 lookup 44
Rob
Can I request a feature for the portal ?
It would be nice for a co-ordinator to have the ability to add an IP
address allocation on the behalf of someone else.
I'm in the process of cleaning up the database for the US State of Iowa,
and some users are e-mailing me directly to keep their allocations rather
than registering it via the portal. I suspect that explaining how to
register through the portal might be confusing or they don't feel
comfortable registering on the portal.
Thanks.
-Neil
--
Neil Johnson -N0SFH
http://erudicon.com
Hi all,
My routing table after my AMPRnet GATEWAY has got all the routes via
RIPv2 using rip44d, looks like this:
-------------------------------------------------------------------------------------------------------
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.15.1 0.0.0.0 UG 0 0 0 eth0
44.0.0.0 169.228.66.251 255.0.0.0 UG 0 0 0 tunl0
44.0.0.0 0.0.0.0 255.0.0.0 U 30 0 0 rose0
44.0.0.1 169.228.66.251 255.255.255.255 UGH 0 0 0 tunl0
44.2.1.32 76.14.161.185 255.255.255.248 UG 0 0 0 tunl0
44.2.10.0 71.130.72.52 255.255.255.248 UG 0 0 0 tunl0
44.2.11.1 71.130.72.52 255.255.255.255 UGH 0 0 0 tunl0
44.2.14.0 50.79.156.221 255.255.255.248 UG 0 0 0 tunl0
44.2.14.100 50.79.156.221 255.255.255.255 UGH 0 0 0 tunl0
44.2.50.0 68.189.32.222 255.255.255.248 UG 0 0 0 tunl0
44.2.50.0 208.74.106.137 255.255.255.0 UG 0 0 0 tunl0
44.4.2.152 173.167.109.217 255.255.255.255 UGH 0 0 0 tunl0
44.4.2.153 173.167.109.217 255.255.255.255 UGH 0 0 0 tunl0
....
More routes
-------------------------------------------------------------------------------------------------------------
Is this correct or am I dending all AMPRnet traffic through UCSD.EDU ?
--
73 de SV1UY
Demetre Ch. Valaris
e-mail: demetre.sv1uy(a)gmail.com
Radio e-mail: sv1uy(a)winlink.org
(to use my radio e-mail put //WL2K in the beginning of the subject line)
http://www.qsl.net/sv1uy
Hi Guys,
Sorry about the RIP routes. After some work on my router the RIP was turned
on for all interfaces.
I have now rectified this and all should have stopped.
Apologies.
Best Regards,
Hugh G7UOD
) +44 7841 749345
* g7uod(a)onlineham.net
> Subject:
> [44net] (no subject)
> From:
> kb9mwr(a)gmail.com
> Date:
> 08/24/2013 02:59 AM
>
> To:
> "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu>
>
>
> --- Quote ---
>
> For some reason, I cannot get it to receive the 44.0.0.1 -> 224.0.0.9
> transmissions.
> The socket is listening on port 520, when I trace tunl0 I see the
> packets arriving
> every 5 minutes, but the rip44d (running with -v) remains absolutely silent.
> Any idea what that can be?
> ------
>
> The first thing that comes to mind is something wrong with the tunl0 netmask.
>
Ah is that the reason?
The netmask on tunl0 is 255.255.255.255. I have only a single address on my tunnel endpoint.
Is that not allowed? What should it be instead?
In the meantime I have solved it by using ampr-ripd instead of rip44d.
It has the -r option to use a raw socket to receive everything on tunl0 and picking out
the RIP datagrams itself. That works OK.
I have a Rasperry Pi that is located in a datacenter. It is directly on Internet.
Now I am running the net-44 tunnel stuff on it, it acts as my gateway for two single
addresses and a subnet. There is a local copy of NETCHL running there as well,
on 44.137.40.1. I can access the different amprnet systems from there. It is running
under "screen" so I can take over the console from where I like.
My subnet is routed to my home system via an IPsec tunnel, where I still run some
services that I want to move there. The default route for net-44 traffic at home is now
to my Pi.
It runs beautifully. Now my system at home is a lot less complicated, and I can more
easily upgrade to a newer Linux version without disturbing all the special networking
stuff.
Rob
In another thread, it was said:
>> everyone in the mesh ought to be running a dynamic routing protocol thus
>> increasing redundancy and reliability.
>This is a good idea. I'm not up on the latest RFCs concerning routing in
>tunneled (VPN, GRE, etc) networks. Do you have a recommendation?
I am not an expert to answer this question, but I have stumbled on an
emerging method for routing that has remarkable similarities to
threads here. Along with the connections/associations I list below, it
is experimental communications, and I believe we (Hams) have something
to contribute.
RFC 6830, LISP (Locator/ID Separation Protocol - see
[http://www.lisp4.net/] ) decouples Location from unique IDentifier in
IP addressing. I first saw the need for this concept with APRS
messaging, but that is for another group.
"LISP follows a network-based map-and-encapsulate scheme ... both
identifiers and locators can be IP addresses or arbitrary elements
like a set of GPS coordinates or a Mac address." {or call sign?}
The LISP Papers at [http://blog.pattincon.com/lisp-papers/] seems to
be a good place for me to start to understand the application of this
protocol.
It is implemented in recent versions of Cisco IOS/NX-OS (out of my
reach at this time) and LISPmob (Mobile Node) at [http://lispmob.org/]
runs on OpenWRT/Linux.
I am working on experimenting with something from here.
Peace, Jim A. KB3TBX
