On 04/10/2014 02:26 PM, lleachii(a)aol.com wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Bart,
That realization you posit is INCORRECT:
AMPR IPs packets do one of 2 things at a 44GW:
1.) if a valid DST 44 address, go to a destination via IPIP to another 44GW
2.) all others use default gateway - go via IPIP to the AMPRGW
~~~
the request proposes an ***INVALID*** or STATIC option
3.) - ***if a 44 address, go to the 44 address via IPIP to the AMPRGW***
you asked:
"Why did your router choose tunl0 as the
next-hop when ***we don't
announce any special route for 44.24.221.0/24?***
Because within AMPR,
44.24.221.0/24 is an invalid IP subnet and is choosing the default route, which is also
invalid at AMPRGW.
Your router seems to have made a routing mistake
here.
It should have chosen the default route (0.0.0.0/0)
to send the packet since it has no special information about
44.24.221.0/24."
Not accurate, it made a CORRECT routing decision, it
selected the ***Default AMPR Route***
As I noted:
- the gateways using the KB3VWG Linux script (and most devices using rip44) are set to
use a custom routing table if the SRC and/or DST address is 44.0.0.0/8
- the default route for AMPR host to reach the Internet is:
ip route add default dev tunl0 via 169.228.66.251 onlink table 44
The problem is the "SRC == 44/8 || DST == 44/8" routing table
selection. Consider the following alternative architecture:
1) Create an "ampr" routing table with all the announced 44nets and
their gateways
2) Add 1 static route to the "ampr" routing table: default via
169.228.66.251 dev tunl0
3) Define a mangle rule (RouterOS format - still Netfilter-based
architecture):
/ip firewall mangle add chain=prerouting action=mark-routing
new-routing-mark=ampr src-address=<your 44net>
4) Define a routing rule (RouterOS format - still Netfilter-based
architecture):
/ip route rule add routing-mark=ampr action=lookup table=ampr
The above should handle the following cases:
1) Your normal Internet traffic from non-AMPR IPs goes out using your
main table and ISP's default gateway. You can also add NAT here, but
let's not get into that in this email.
2) Traffic from the Internet (non-44.0.0.0/8) to your AMPR IPs gets
encapsulated by amprgw and is delivered to your router's IPIP endpoint
IP. src-IP=169.228.66.251, dst-IP=<your IPIP endpoint IP>, and is
unencapsulated by your IPIP interface. The unencapsulated packets
src-IP=!44.0.0.0/8 dst-IP=<your 44net> get routed according to your main
routing table.
3) Traffic from your 44net to the Internet has src-IP=<your 44net>
dst-IP=<any, except valid 44nets>. It hits the ampr routing-mark mangle
rule which in turn forces routing to lookup the ampr table. After
missing all the valid 44nets, it hits the default route in the ampr
table and is encapsulated with src-IP=<your IPIP endpoint IP>,
dst-IP=169.228.66.251. This packet then hits your main routing table
and uses your ISP default gateway.
4) Traffic from another AMPR GW to your AMPR GW gets IPIP encapsulated
by the remote gateway and arrives as src-IP=<any, including 44.0.0.0/8>
dst-IP=<your IPIP endpoint IP>. After your IPIP interface unencapsulates
the packet, the src-IP=44.0.0.0/8 dst-IP=<your 44net>, and follows your
main routing table for delivery.
5) Traffic from your 44net to another AMPR GW has src-IP=<your 44net>
dst-IP=<one of the valid 44.0.0.0/8 nets> matches the mangle rule which
forces it to use the ampr table. It then finds a 44net route in the
ampr table and gets encapsulated before hitting the default route. The
encapsulated packet has src-IP=<your IPIP endpoint IP> and dst-IP=<any,
including 44.0.0.0/8>. It hits your main routing table and uses your
ISP default gateway.
I believe the above scenarios fully work through every conceivable
routing permutation here, and demonstrate correct functionality. The
actual change required is minimal, since you've already got the ampr
table defined by your software. It's simply the removal of the
dst==44/8 clause and the replacing of the src==44/8 clause with
src==<your 44net>.
Having said all that, I haven't actually implemented/tested this design
since my AMPR allocation is announced via BGP. Please do let me know if
it works out for you! It should retain present functionality and make
you 44net-anycast compatible going forward.
--Bart
> I don't want to belabor the group on this, as I had to discover this by trial and
error when developing the script; your only options are to:
>
> - develop an Amateur Radio custom Linux kernel and IP command; or
> - have every station add a static route for you (which should only be used for
subnets local to the GW)
>
>
> 73,
>
>
> Lynwood
> KB3VWG
>
>