Sorry to push this, but I think we really need an agreed solution for this
topic.
I wish to emphasize some use cases so we can find a common approach
(assuming that he 44/8 route via ampr-gw is gone).
All descriptions are from the point of view of the "regular" tunneled
gateway.
1. 44 subnet, BGP announced, with a public IP available for tunneling
This doesn't pose any problems. Has to be published in the encap file,
regular route handling is OK.
If direct non-tunneling access is desired, the entry has to be ignored in
the encap/RIP data.
Can be implemented by adding a higher priority (lower metric) route to
that subnet via default gw, or add the GW address to the rip daemon ignore
option.
Drawback on direct access would be that ham traffic can not be identified
as such (because of NAT), except when originating on other BGP announced
44 subnets.
Using src-address filtering with gw data from the encap can increase
security.
2. 44 subnet, BGP announced, with a public 44 tunnel gateway address, not
present in the encap/RIP data
This should also work without problems, as long as there is no default
44/8 route.
The same issues as in (1) apply.
3. 44 subnet, BGP announced, with 44 public tunnel gateway address in the
same subnet.
In this case, tunnel access is prevented by a routing loop.
There are solutions for this, but none of them automaticaly (for the moment).
a. A specific route can be defined for the tunnel gateway via default
gateway. This will allow the gateway to be direct reachable, and all the
traffic for the subnet will be tunneled to it.
One major drawback is the fact that the gateway itself will not be
reachable via that tunnel.
b. Outgoing proto 4 (ipip) traffic can be marked and handled by a separate
routing table, so that it can be directed to that specific gw host.
c. The route can be ignored in encap/RIP, and accessed directly, of course
ham traffic from non-BGP announced hosts will not be distinguishable from
regular traffic, except if src-address filtered based on encap data.
4. Single 44 host, BGP announced, accepting tunnel connections to it.
Here, the only option would be to policy route the outgoing ipip traffic
to the default system gateway, as described in (3).
Conclusion:
The universal solution would actually be that outgoing proto 4 (ipip)
traffic should be marked and handled by a separate routing table and NATed
to the system's gateway address.
This should not affect any routes except when using private ipip tunnels
to other gateways, in which case specific routes have to be added to that
routing table.
This could be implemented in the ampr-ripd daemon and done automatically
using a secondary routing table, for all RIP routes which have a 44
gateway address.
I assume this could also be done in xNOS systems.
Have a nice day,
Marius, YO2LOJ