Marius;
On Sat, 2015-01-10 at 12:01 +0200, Marius Petrescu wrote:
44.24.221.1 is not announced in the RIP broadcast, so
it goes implicitely to
default (and NATed to the local public IP) if the system is correctly
configured.
Remember this is a four fold process:
1) Rip server uses a flag for announcement - you propose that flag as
0.0.0.0. The flag itself is irrelivant.
2) The subnet is either ignored getting entered into the local amprnet
table
3) The subnet has a rule included by the rip listener daemon to either
route that subnet using a special non-encap table list (ie: table 2,
table bgp, table isp....) and a rule to set routing to that subnet via
that matching table via one's internet interface (thus sourcing you as a
non-44/non-encapsulated IP)
Contact me off-list Marius if you'd like more specifics.
In this case the tunnel endpoints are correctly
defined, and 44.24.240/24 is
sent via IPIP from the local public IP to 44.24.221.1, which, being BGP
annonced, is directly reachable on regular internet.
The only condition for this to work is NOT to have a default route to
44.0.0.0/8 via tunnel.
The problem with 44.140 is that the gateway is in its own subnet.
So we need to instate a higher priroity route for the gateway, to avoid the
tunnel, on the local system or on a potential connected router which gets
RIP forwarding.
And we need a way to differentiate between a misconfigured situation and a
legitimate setup.
That is why I proposed the GW 0.0.0.0 approach, meaning no gateway.
This will solve the local routing issue on the gateway, but will not work on
RIP forwarding, and a manual intervention is still required on any connected
router.
Because receiving the RIP route for the gateway will cause a routing loop,
dropping it will also create another routing loop, since standard RIP sets
the gateway for a route to the interface on which it received the routing
info. But it could be a first step.
Or just drop the route alltogether, and rely on the fact that the whole
subnet is BGP announced, as it happens on ampr-ripd 1.13. This leads to a
correct working setup, the only limitation being that the destination system
can not differentiate between ampr/non-ampr traffic, since NAT to a public
IP is needed.
I think modifying ampr-gw to accept forwarding to such host is out of the
question, since it would increase the load on that system. If acceptable,
the default route via tunnel for 44.0.0.0/8 destinations would cover this
situation, provided that ampr-gw accepts forwarding to BGPed 44net
destinations..
Marius, YO2LOJ
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
[mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Jann
Traschewski
Sent: Saturday, January 10, 2015 11:17
To: AMPRNet working group
Subject: Re: [44net] 44 Network behind BGPed 44 Address
(
...
Good idea! There is a another gateway which could be fixed this way:
44.24.221.1/32 via 0.0.0.0
44.24.240.0/20 via 44.24.221.1
Currently I need to setup this type of gateway manually on my system...
...
73,
Jann
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
--
If Microsoft intended Windows to be for ham usage,
they would have incorporated our protocols into their kernel.
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web:
http://www.n1uro.net/
Ampr1:
http://n1uro.ampr.org/
Ampr2:
http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.