25 Aug
2013
25 Aug
'13
3:30 p.m.
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