Multiple default gateway from tinc node

Lars Kruse lists at sumpfralle.de
Tue May 2 16:22:37 CEST 2017


Hi,


Am Tue, 2 May 2017 21:53:15 +0800
schrieb Bright Zhao <startryst at gmail.com>:

> [..]
> The key point to understand here is how the route happens for traffic head
> for 8.8.8.8, earlier I thought it can ONLY send to 10.0.0.3 where
> aly_hk(10.0.0.3) delivery to 8.8.8.8 locally(because aly_hk has the default
> route for 8.8.8.8, no need to forward to other tinc nodes), but now, I found
> A will learn multiple 8.8.8.8 subnets from aly_hk, and for example, if I set
> B’s Subnet =8.8.8.8#9, then A ping 8.8.8.8 will send to aly_hk, and aly_hk
> will foward to B for final delivery.

I think, we are getting closer to the source of misunderstanding.
Each node (i.e. specifically tinc and the connected scripts - nobody else)
learns which subnets are availabe via other nodes. The kernel (or whoever
manages routing decisions) is unaware of tinc's concept of subnets.
Thus routing tables, handling of conflicting routes (via aly_hk, A or ...) are
up to you (handled via subnet-up scripts).
Thus if A thinks, it should send packets for 8.8.8.8 to aly_hk, but aly_hk
thinks, that B would be a better target, then you will need to adjust your
scripts to prevent this situation.
Maybe you want to add the "metric" attribute to you routes based on the
"weight" of each subnet? Maybe you want to use a routing daemon (e.g. olsrd)
for handling different routes (this would be a completely different approach,
but still usable with tinc). Or maybe you just ignore subnets from other nodes,
if the local nodes announces the same subnets?

Think of tinc as something that transports traffic and maybe filters some
packets (nodes only accept traffic for IPs within their own subnet definition).
Routing is outside of the scope of tinc - this is up to you via your subnet-up
scripts.
At least this is my understanding.

Cheers,
Lars


More information about the tinc mailing list