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