Unknown option "--icmp-type"

k6av commented 3 months ago

What happened?

Kube-router fails to start after trying to run an invalid ip6tables command.

What did you expect to happen?

Kube-router starts.

How can we reproduce the behavior you experienced?

Steps to reproduce the behavior:

Start kube-router

System Information (please complete the following information)

Kube-Router Version (kube-router --version): v2.2.0
Kube-Router Parameters: --enable-cni=true --run-router=true --run-firewall=true --run-service-proxy=true --run-loadbalancer=true --bgp-graceful-restart=true --kubeconfig=/var/lib/kube-router/kubeconfig --enable-ipv4=false --enable-ipv6=true --router-id=generate --service-cluster-ip-range=fdcd:5f23:4ab4:11::/112 --loadbalancer-ip-range=fdcd:5f23:4ab4:12::/112
Kubernetes Version (kubectl version) : v1.30.1
Cloud Type: on premise
Kubernetes Deployment Type: manual
Kube-Router Deployment Type: DaemonSet
Cluster Size: single node (1)

Host ip6tables version: v1.8.10

Logs, other output, metrics

Kube-router output

``` I0806 17:54:39.903306 865788 network_services_controller.go:241] Starting network serv ices controller F0806 17:54:39.960735 865788 network_services_controller.go:311] error setting up ipvs firewall: %!s(MISSING)failed to run iptables command: running [/sbin/ip6tables -t filter -C KUBE-R OUTER-SERVICES -m comment --comment allow icmp echo requests -p icmp --icmp-type echo-request -j AC CEPT --wait]: exit status 2: ip6tables v1.8.9 (nf_tables): unknown option "--icmp-type" Try `ip6tables -h' or 'ip6tables --help' for more information. ```

Additional context

The issue occurs even after rebuilding the kube-router image to have ip6tables v1.8.10 (matching host version).

k6av commented 3 months ago

According to the iptables(8) and ip6tables(8) manpages, ip6tables does not have an icmp-type option but instead has icmpv6-type (and extension icmpv6 instead of icmp). Possibly kube-router is missing a check for selecting the correct option name?

k6av commented 3 months ago

Looking at the code it seems the error is originated from network_service_controller.go:486-494, where PR #1710 reworked the logic for deciding icmp vs icmpv6.

aauren commented 3 months ago

Sorry for the mixup on this @k6av and thanks for fixing up the code @qbnit!

I was refactoring that part of the code several times before I eventually committed it. At some point along the way I lost the difference in the types :facepalm:.

cloudnativelabs / kube-router