Jason, It is difficult to define "right way" because there always is someone with a setup that breaks when you do it in some way. Who is wrong and who is right is difficult to tell in such cases. We have a BGP-announced /16 for the Netherlands and we also announce the same /16 on the IPIP tunnel network. Subnets from this are routed internally (using BGP as well, but not related to the internet BGP, we use private AS numbers) and also some people have IPIP tunnels with subnets or addresses that are within the /16. We use ampr-ripd to get the IPIP routes. This works OK.  People communicating to others that are on IPIP as well use the IPIP tunnel, when they want to talk to others they send it via IPIP to our gateway (i.e. our gateway is the default gw on the 44-net routing table, instead of amprgw as in the examples) and we decapsulate it and forward the internal IP packet to our internal systems or to internet. To have it working this way it is important that all routes are in the same routing table.  You can use different metrics to avoid collisions between BGP routes and IPIP routes for the same subnet, but it is not a good idea to use different routing tables for BGP and IPIP routes and then use ip rules to lookup in those tables until a route is found.  This is because a more specific route should always be preferred, independent from the routing protocol. So when a packet is to be routed, it is looked up in the table and either a route via the IPIP mesh or some other route is used to forward it.  A destination on IPIP can be within the BGP routed subnet without problem, and vice-versa. It will work fine when the remotes on IPIP correctly route back to you via IPIP as well.  But some stations use clever hacks to work around certain problems and the result can be that they are unreachable for people using this solution. Who is right and who is wrong is difficult to determine, as has been shown in earlier discussions on the list. Rob