feat: Option to disable overlay tunnel device binding

[nextsux]

Hello folks,

I was having issues with binding overlay ipip tunnels to specific device. I would like to see option to disable this behavior.

My usecase is that I have many nodes on one L2 network but few (1 at this time) i have "off-site", connected with a wireguard VPN. When kube-router builds ipip tunnel it is confused and binds tunnel to interface BELOW the VPN so instead of running ip-ip through VPN it tries to run it through default VPN but with VPN local/remote addresses. Which fails obviously.

OTOH I'm not really sure why the binding is there - is there any reason for it? Maybe better solution would be to just remove it?

Thanks for your opinion

[aauren]

@nextsux sorry that it took so long to come around to this PR.

It was something that I wanted to spend time digging into a bit and I was a bit busy with the v2.X release of kube-router.

Unfortunately, this change came in with the very beginning of the tunnel implementation near the start of the project and I wasn't around at that time, so I'm not sure why the IPIP tunnel was bound to a specific device.

However, I think that it should work fine without being bound to a specific device. In this case, the Linux kernel should choose a device based upon its routing table. I'm leaning towards removing the device, but figured that I would reach out to see if anyone has any thoughts before recommending that you make that change.

@tamihiro - I know that in the past you made an exemption for not binding to the localhost interface when the IP was found on the localhost IP. I think it was to achieve something similar to what the OP is trying to do. Do you know if removing the device completely would affect your use-case?

@murali-reddy - Do you remember why we initially bound the tunnel to the node's primary interface?

[tamihiro]

@tamihiro - I know that in the past you made an exemption for not binding to the localhost interface when the IP was found on the localhost IP. I think it was to achieve something similar to what the OP is trying to do. Do you know if removing the device completely would affect your use-case?

haven't got around to testing it myself yet, but removing the device should not affect my use-case.
Thanks for checking in!

[aauren]

I have tried the code in a small test environment and I don't see any problems when I remove the device binding for the IPIP tunnels.

That's far from conclusive that it won't cause any edge cases to appear, but I've noticed that there are plenty of other places that we don't do this binding when creating devices in the code bases. Additionally, we've already had to exempt lo from the device list to allow from another use-case.

While I reserve the right to maybe put it back later if there is a public out-cry, I'm not expecting one and I think it should be safe enough to do. Additionally, I also hate adding flag as the more flags we add the more confusing the interface to kube-rotuer gets.

Given all of that, @nextsux if you're still interested in getting this in, can you rebase your branch and change the code to remove the binding unilaterally rather than by parameter?

[nextsux]

Thanks @aauren. We really appreciate it.

I'll make the changes and send the revised PR over the weekend.

[nextsux]

I've reworked patch just to remove device binding and rebased to current upstream @aauren

[aauren]

Thanks!