pkg/node: Skip setting MTU on local node routes

[aditighag]

Previously, we were setting mtu on local node routes, which takes effect in
routing in recent kernels. This could lead to drops for jumbo packets when the
"Don't fragment" bit is set. Regardless of the kernel routing, we shouldn't
restrict mtu on the host local routes.

This fix avoids setting an mtu on local node routes (i.e., when
enable-local-node flag is enabled).

Testing notes are in the commit description. Integration tests will be added as a follow-up.

Release note

Fix a route MTU issue where pods cannot receive large packets from outside the cluster 
when the sender sets the "don't fragment" (DF) bit. 

[joestringer]

Minor nit on one of the godocs, but otherwise LGTM.

[joestringer]

I would probably describe the release note as something like "Fix MTU issue where pods cannot receive large packets from outside the cluster", since that's the most likely scenario for this to occur (including the environment of the user that reported this issue).

[aditighag]

I would probably describe the release note as something like "Fix MTU issue where pods cannot receive large packets from outside the cluster", since that's the most likely scenario for this to occur (including the environment of the user that reported this issue).

Done. Made the note more explicit by mentioning about the Don't fragment bit.

[aditighag]

test-me-please

[aditighag]

retest-gke

[aditighag]

I'm unable to reproduce the smoke-test-ipv6 test failure on a local kind cluster. I followed all the steps from the yaml.

ks get pods -A
NAME                                             READY   STATUS    RESTARTS   AGE
echo-a-dc9bcfd8f-wcw7s                           1/1     Running   0          3m18s
echo-b-5884b7dc69-ggp6r                          1/1     Running   0          3m18s
echo-b-host-cfdd57978-gvf85                      1/1     Running   0          3m18s
host-to-b-multi-node-clusterip-c4ff7ff64-mrrc5   1/1     Running   0          3m17s
host-to-b-multi-node-headless-84d8f6f4c4-jgbzx   1/1     Running   1          3m17s
pod-to-a-5cdfd4754d-p6mmb                        1/1     Running   0          3m18s
pod-to-a-allowed-cnp-7d7c8f9f9b-l9c2s            1/1     Running   0          3m17s
pod-to-a-denied-cnp-75cb89dfd-rk7dr              1/1     Running   0          3m17s
pod-to-b-intra-node-nodeport-99b499f7d-d7vd4     1/1     Running   1          3m15s
pod-to-b-multi-node-clusterip-cd4d764b6-wm9sh    1/1     Running   0          3m17s
pod-to-b-multi-node-headless-6696c5f8cd-txrv7    1/1     Running   1          3m17s
pod-to-b-multi-node-nodeport-7ff5595558-w9pg9    1/1     Running   1          3m17s

[qmonnet]

retest-gke

[joestringer]

I see that there were two re-runs of the GKE tests. In an ideal world, this would be zero. I get the impression that the GKE tests passed on the 3rd try, but what were the first two failures? Were they infrastructure issues? Some known flake (which issue #?) Or code issue that got fixed?

[qmonnet]

what were the first two failures?

Haven't seen the first one, but the second was infrastructure-related. GKE failed to find a cluster with nodepools.

[aditighag]

what were the first two failures?

Haven't seen the first one, but the second was infrastructure-related. GKE failed to find a cluster with nodepools.

I posted the failure in the testing channel on Slack. The first one was identical to this. I saw the same failure on other PRs too - https://jenkins.cilium.io/job/Cilium-PR-K8s-GKE/4049/

[joestringer]

OK, thanks for the info, so otherwise we have basically had all tests pass at least once; 2x GKE infra issues, 1x Travis infra issues. Code is reviewed and I think we're good to ship this. Merging.