Nodes need reboot after ipvs->iptables->ebpf to work properly

[Whisper40]

We are trying to migrate from IPVS Mode to BPF mode.
We are using Calico 3.31.4, and the Tigera Operator Helm Chart 3.31.4.
We have updated the value as below to do the migration as specified here : https://docs.tigera.io/calico/latest/operations/ebpf/enabling-ebpf#enable-the-ebpf-data-plane-automatically-for-self-managed-clusters
We are using Ubuntu 24, and Kubernetes 1.34.5.

            installation:
              calicoNetwork:
                linuxDataplane: BPF
                bpfNetworkBootstrap: Enabled
                kubeProxyManagement: Enabled

Expected Behavior

We expect it to work as before

Current Behavior

Calico Operator trigger the calico rollout, and then disable kube-proxy.
After that (one second later the log that specify the update of kube-proxy), we lost all connectivity on nodes.
We lost SSH too.

We need to reboot all nodes of the cluster, and then everything come back. But as you can understand it is not acceptable for production cluster.

Possible Solution

Steps to Reproduce (for bugs)

Kubeproxy : "IPVS" mode
Calico : linuxDataplane: Iptables -> then we do the migration

Context

Your Environment

• Calico version : 3.31.4
• Calico dataplane (bpf, nftables, iptables, windows etc.) : Iptables
• Orchestrator version (e.g. kubernetes, openshift, etc.): 1.34.5
• Operating System and version: Ubuntu 24
• Link to your project (optional):

[lwr20]

There's a note on that page: "If you are running kube-proxy in IPVS mode, switch to iptables mode before disabling."

However, it does look like that note is connected to the MKE section above it, but its a warning that's applicable to all platforms. Tagging @ctauchen to update the docs.

[Whisper40]

I have try the following :
Migrate kube-proxy mode to "iptables". Rollout restart kube-proxy.
Then i have do this :

            installation:
              calicoNetwork:
                linuxDataplane: BPF
                bpfNetworkBootstrap: Enabled
                kubeProxyManagement: Enabled

And the same problem appears i have lost all connectivity.

[Whisper40]

Before migration

kube-proxy

    iptables:
      localhostNodePorts: null
      masqueradeAll: false
      masqueradeBit: null
      minSyncPeriod: 0s
      syncPeriod: 0s
mode: "iptables"

felix

apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
  annotations:
    meta.helm.sh/release-name: calico
    meta.helm.sh/release-namespace: tigera-operator
    operator.tigera.io/bpfEnabled: "false"
  creationTimestamp: "2026-04-15T13:20:57Z"
  generation: 4
  labels:
    app.kubernetes.io/managed-by: Helm
  name: default
  resourceVersion: "165340991"
  uid: 6066faeb-c83a-4d0d-8b92-1d6690e86eaa
spec:
  bpfConnectTimeLoadBalancing: TCP
  bpfEnabled: false
  bpfHostNetworkedNATWithoutCTLB: Enabled
  bpfLogLevel: ""
  floatingIPs: Disabled
  healthPort: 9099
  logSeverityScreen: Info
  nftablesMode: Disabled
  reportingInterval: 0s
  vxlanPort: 4789
  vxlanVNI: 4096

calico

  calicoNetwork:
    bgp: Enabled
    hostPorts: Enabled
    ipPools:
    - allowedUses:
      - Workload
      - Tunnel
      assignmentMode: Automatic
      blockSize: 25
      cidr: 172.20.0.0/16
      disableBGPExport: false
      disableNewAllocations: false
      encapsulation: VXLAN
      name: default-ipv4-ippool
      natOutgoing: Enabled
      nodeSelector: all()
    linuxDataplane: Iptables
    linuxPolicySetupTimeoutSeconds: 0
    mtu: 1450

[Whisper40]

I have try a new migration (with a reboot of nodes after applying iptables migration) and this time it works.
Will check again and reopen if needed.

{"level":"info","ts":"2026-04-15T13:30:06Z","msg":"Starting workers","controller":"goldmane-controller","worker count":1}
2026/04/15 13:30:08 [INFO] Detected operator service account "tigera-operator" from token review
{"level":"info","ts":"2026-04-15T13:30:09Z","logger":"controller_installation","msg":"waiting for calico-node to 8 replicas, ready at 4, up-to-date at 8, available at 4","Request.Namespace":"","Request.Name":"calico"}
{"level":"info","ts":"2026-04-15T13:30:14Z","logger":"controller_installation","msg":"waiting for calico-node to 8 replicas, ready at 4, up-to-date at 8, available at 4","Request.Namespace":"","Request.Name":"calico"}
{"level":"info","ts":"2026-04-15T13:30:18Z","msg":"Starting EventSource","controller":"tigera-windows-controller","source":"kind source: *v3.IPAMConfiguration"}
{"level":"info","ts":"2026-04-15T13:30:18Z","msg":"Starting EventSource","controller":"clusterconnection-controller","source":"kind source: *v3.ClusterInformation"}
{"level":"info","ts":"2026-04-15T13:30:19Z","logger":"controller_installation","msg":"waiting for calico-node to 8 replicas, ready at 6, up-to-date at 8, available at 6","Request.Namespace":"","Request.Name":"calico"}
{"level":"info","ts":"2026-04-15T13:30:24Z","logger":"controller_installation","msg":"waiting for calico-node to 8 replicas, ready at 7, up-to-date at 8, available at 7","Request.Namespace":"","Request.Name":"calico"}
{"level":"info","ts":"2026-04-15T13:30:29Z","logger":"controller_installation","msg":"waiting for calico-node to 8 replicas, ready at 7, up-to-date at 8, available at 7","Request.Namespace":"","Request.Name":"calico"}
{"level":"info","ts":"2026-04-15T13:30:34Z","logger":"controller_installation","msg":"waiting for calico-node to 8 replicas, ready at 7, up-to-date at 8, available at 7","Request.Namespace":"","Request.Name":"calico"}
{"level":"info","ts":"2026-04-15T13:30:39Z","logger":"controller_installation","msg":"waiting for calico-node to 8 replicas, ready at 7, up-to-date at 8, available at 7","Request.Namespace":"","Request.Name":"calico"}
{"level":"info","ts":"2026-04-15T13:30:44Z","logger":"controller_installation","msg":"waiting for calico-node to 8 replicas, ready at 7, up-to-date at 8, available at 7","Request.Namespace":"","Request.Name":"calico"}
{"level":"info","ts":"2026-04-15T13:30:49Z","logger":"controller_installation","msg":"waiting for calico-node to 8 replicas, ready at 7, up-to-date at 8, available at 7","Request.Namespace":"","Request.Name":"calico"}
{"level":"info","ts":"2026-04-15T13:30:54Z","logger":"controller_installation","msg":"waiting for calico-node to 8 replicas, ready at 7, up-to-date at 8, available at 7","Request.Namespace":"","Request.Name":"calico"}
{"level":"info","ts":"2026-04-15T13:35:32Z","logger":"controller_installation","msg":"Patching nftables mode","Request.Namespace":"","Request.Name":"default","nftablesMode":"Enabled"}
{"level":"info","ts":"2026-04-15T13:41:37Z","logger":"kubeproxy-controller","msg":"kube-proxy DaemonSet patched to disable kube-proxy, since kubeProxyManagement is Enabled and BPFEnabled is true.","Request.Namespace":"","Request.Name":"default"}

After a new try the issue persists. The problem seems to be related to ipvs -> iptables -> bpf
If a restart all nodes after iptables, the migration works.
Without this, migration fail while going to BPF.

[tomastigera]

yes, you must first switch to iptables before swithing to ebpf

[hengqiali]

@Whisper40 A great practice!

I think migrating from iptables (switched from ipvs) to bpf, will break long-live traffics, because all data path changes at migrating period.

BTW, could you please help to answer that you don't need to reboot the node after switching to iptables from ipvs to do bpf migrating, right?

[hengqiali]

hi @tomastigera @lwr20 so switching to iptables from ipvs is a prerequisite to bpf migration for all platforms not just MKE ? Thanks

[tomastigera]

yes, the docs look weird, we will fix it

[Whisper40]

@hengqiali "BTW, could you please help to answer that you don't need to reboot the node after switching to iptables from ipvs to do bpf migrating, right?"

I have try this 4 times at least, the reboot is mandatory.
(ipvs -> iptables) is OK
But (iptables -> bpf) without reboot is breaking everything. I need to reboot before bpf migration in my case

[Whisper40]

We are using Cluster API. After migrating to iptables and before migration to bpf, i have started a rollout of all nodes. And then i have do the bpf migration with success. Downtime was very fast ( 3 seconds on a 6 nodes clusters )