Validate if imcp redirects are working

[databus23]

pinging the pod cider of another nodes yields this:

kubernikus-m34-medium-kgn51 ~ # ping 10.180.129.1
PING 10.180.129.1 (10.180.129.1) 56(84) bytes of data.
From 10.180.0.1: icmp_seq=1 Redirect Host(New nexthop: 10.180.0.155)
64 bytes from 10.180.129.1: icmp_seq=1 ttl=64 time=1.47 ms
From 10.180.0.1: icmp_seq=2 Redirect Host(New nexthop: 10.180.0.155)
64 bytes from 10.180.129.1: icmp_seq=2 ttl=64 time=1.07 ms
From 10.180.0.1: icmp_seq=3 Redirect Host(New nexthop: 10.180.0.155)
64 bytes from 10.180.129.1: icmp_seq=3 ttl=64 time=1.15 ms
...

So the router sends icmp redirects.
I would expect that these redirects stop as the ping packets gets routed to the next hop directly but they don't. So it looks to me like redirects are not accepted by the node executing the ping.

Redirects are enabled and should be working:

kubernikus-m34-medium-kgn51 ~ # cat /proc/sys/net/ipv4/conf/ens32/accept_redirects
1
kubernikus-m34-medium-kgn51 ~ # cat /proc/sys/net/ipv4/conf/ens32/secure_redirects
1

I even tried disabling secure_redirects which didn't change anything.

I would like to have redirects working to avoid sending in-cluster communication through the router unnecessary. We should validate if it is working or make it so otherwise.

[SchwarzM]

i think you have problems with the netmask of the interface but lets do a quick call to find out.

[SchwarzM]

got it running not only the respective device has to be set to accept_redirects also the all configuration.

sysctl -w net.ipv4.conf.all.accept_redirects=1

after that the respective route cannot be easily found due to it's transient nature but

ip route get 10.180.129.1

should show the right hop.

[databus23]

thats a bit odd. Why the setting per interface then? Any clues?

[SchwarzM]

if linux was easy ....

https://unix.stackexchange.com/questions/90443/sysctl-proc-sys-net-ipv46-conf-whats-the-difference-between-all-defau

[SchwarzM]

naturally it is different per setting ... only obtainable in source code ....

[databus23]

ok thanks for digging this up

[databus23]

ok but we could enable it for all and disable it for cbr0 maybe.

[databus23]

I'm just thinking about preventing route manipulations from a pod

[databus23]

maybe secure_redirects already kind of protects from that

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[databus23]

@SchwarzM Do we have sysctl -w net.ipv4.conf.all.accept_redirects=1 in the ignition template by now?

[SchwarzM]

no not yet because i am unsure how to package that right if we want to update it at some point later we might need to use a daemonset or something more tangible then a systemd unit file