Responing to ARP request does not working on single-node cluster

[ldudzsim]

MetalLB Version

0.14.3

Deployment method

Manifests

Main CNI

flannel

Kubernetes Version

1.29.2

Cluster Distribution

bare-metal

Describe the bug

When I create a cluster with one single node with flannel and metallb, the speaker does not respond to ARP requests. When I add a additional node to cluster, it starts working. It only happens in 0.14.x version in 0.13.12 it works correctly.

To Reproduce

1. Init cluster

sudo kubeadm init --pod-network-cidr=10.244.0.0/16

2. Set env

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

3. Turn on flannel

kubectl apply -f https://github.com/flannel-io/flannel/releases/download/v0.24.2/kube-flannel.yml

4. Wait for flannel to boot up (all pods have to be in running state)

kubectl get pods --all-namespaces

5. Unblock node

kubectl taint nodes --all node-role.kubernetes.io/control-plane-

6. Enable metallb

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.3/config/manifests/metallb-native.yaml

7. Wait for metallb to boot up (all pods have to be in running state)

kubectl get pods --all-namespaces

8. Setup IP pool
   create metallb.yaml

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: first-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.24.80-192.168.24.90

---

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: example
  namespace: metallb-system

and apply it

kubectl apply -f metallb.yaml

9. Create a test LoadBalancer service

kind: Pod
apiVersion: v1
metadata:
  name: foo-app
  labels:
    app: foo
spec:
  containers:
    - name: foo-app
      image: 'kicbase/echo-server:1.0'
---
kind: Service
apiVersion: v1
metadata:
  name: foo-service
spec:
  type: LoadBalancer
  externalTrafficPolicy: Cluster
  selector:
    app: foo
  ports:
    - port: 80
      targetPort: 8080

10. Check IP address

kubectl get service -o wide

it should returns something like this

NAME            TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)        AGE   SELECTOR
foo-service     LoadBalancer   10.99.130.5   192.168.24.80   80:31202/TCP   31m   app=foo

11. On another machine in the same network (192.168.24.29) try to reach 192.168.24.80 and it is unreachable

arping 192.168.24.80
ARPING 192.168.24.80 from 192.168.24.29 enx34d0b8c09c71
^CSent 3 probes (3 broadcast(s))
Received 0 response(s)

the same ping

ping 192.168.24.80
PING 192.168.24.80 (192.168.24.80) 56(84) bytes of data.
From 192.168.24.29 icmp_seq=1 Destination Host Unreachable
From 192.168.24.29 icmp_seq=2 Destination Host Unreachable
From 192.168.24.29 icmp_seq=3 Destination Host Unreachable

and curl

curl http://192.168.24.80
curl: (7) Failed to connect to 192.168.24.80 port 80: No route to host

12. When I run tcpdump on cluster node I get info that ARP request going to the machine but there is not response

sudo tcpdump -n -i enp0s3 arp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:18:26.130288 ARP, Request who-has 192.168.24.80 (ff:ff:ff:ff:ff:ff) tell 192.168.24.29, length 46
15:18:27.130861 ARP, Request who-has 192.168.24.80 (ff:ff:ff:ff:ff:ff) tell 192.168.24.29, length 46
15:18:28.131373 ARP, Request who-has 192.168.24.80 (ff:ff:ff:ff:ff:ff) tell 192.168.24.29, length 46
15:18:29.131943 ARP, Request who-has 192.168.24.80 (ff:ff:ff:ff:ff:ff) tell 192.168.24.29, length 46

13. If I change metallb version in step 6. to 0.13.12

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.12/config/manifests/metallb-native.yaml

all works as expected (ARP response appears)
14. The same when I sit on version 0.14.3 and add additional node to cluster, everything starts working

kubeadm token generate
kubeadm token create <generated-token> --print-join-command --ttl=0
(on another machine)
kubeadm join 192.168.24.150:6443 --token blah-blah-blah --discovery-token-ca-cert-hash sha256:cf59af2af82c0f478affb68baf4bd30820385a9bc15fb54c16cf4fae33

Expected Behavior

MetalLB speaker should responses to ARP requests when there is single-node cluster

Additional Context

There is not additional context I guess

I've read and agree with the following

• I've checked all open and closed issues and my request is not there.
• I've checked all open and closed pull requests and my request is not there.

I've read and agree with the following

• I've checked all open and closed issues and my issue is not there.
• This bug is reproducible when deploying MetalLB from the main branch
• I have read the troubleshooting guide and I am still not able to make it work
• I checked the logs and MetalLB is not discarding the configuration as not valid
• I enabled the debug logs, collected the information required from the cluster using the collect script and will attach them to the issue
• I will provide the definition of my service and the related endpoint slices and attach them to this issue

[fedepaol]

Dupe of #2285 ?

[ldudzsim]

Sorry I didn't notice that issue, yep it is probably duplicated, you can close my issue

[fedepaol]

Sorry I didn't notice that issue, yep it is probably duplicated, you can close my issue

no problem, thanks for raising it!