6 Oct
2018
6 Oct
'18
5:34 p.m.
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