Brian, Chris, thank you for your efforts.
I took a look at the latest sent encap info and I want to bring in discussion the way how some gateways are announced.
route addprivate 44.24.240/20 encap 44.24.221.1
Now this one is ok. The gateway (44.24.221.1) is BGP announced, but not in the encap file. Everything ok and working.
Now to the other two IMHO are wrong:
route addprivate 44.151.94.28/32 encap 44.151.94.28
So this host expects to get encapsulated traffic to a gateway which is the host itself. This leeds to a routing loop and is not possible with a regular setup. This encap entry is in fact plain and simple useless: It states 'you can reach me via me' which gives not much information.
route addprivate 44.140/16 encap 44.140.0.1
The same applies to the above, just that the whole subnet is routed to a gateway which is part of that subnet itself.
The idea is that a route can not point to a gateway for which the route is resolved by the route itself. It may be said that those are BGP routed subnets and the gateway is directly reacheable. But the routing is resolved by the route with the most specific netmask. In this case exactly the one which defines the host (or subnet) itself. Unless there is a mechanism available to mark those gateways and create a higher priority route to them so they can be reached directly, this is not functional.
Please comment on a possible sollution/approach on those setups.
73s de Marius, YO2LOJ