Skip to content

cilium L2 not responding to ARP requests in VLAN iface... but sends gratuitous ARP...? #37959

Closed as not planned

Description

@morpig

Is there an existing issue for this?

  • I have searched the existing issues

Version

equal or higher than v1.17.1 and lower than v1.18.0

What happened?

Hi,

Running a k3s cluster in a bare metal environment - currently trying out L2Announcement.
cilium 1.17.1 + k8s v1.31.4+k3s1

Cilium wont respond to ARP requests from our gateway router, and there're no errors or abnormalities in our setup based on troubleshooting steps on docs.cilium

Our bare metal network is setup with trunked VLAN, so vlan interface is defined on each metals.

I've confirmed that the cilium pod retrieved ARP requests based on tcpdump run on it. Let me know on how to debug further on this issue.

Network setup as follows (IP is modified for example):

iface vlan.1881
vlan id: 1881
Address: 1.0.0.52/29
Gateway: 1.0.0.49
# kubectl -n kube-system get lease | grep "cilium-l2announce"
cilium-l2announce-kong-prod-kong-gateway-proxy-2   bm2-metal                                                               22m

# kubectl -n kube-system exec pod/cilium-l9wwv -- cilium-dbg shell -- db/show l2-announce
IP             NetworkInterface
1.0.0.56   vlan.1881

# kubectl -n kube-system exec pod/cilium-l9wwv -- cilium-dbg shell -- db/show devices    
Name              Index   Selected   Type     MTU     HWAddr              Flags                       Addresses
lo                1       false      device   65536                       up|loopback                 127.0.0.1, ::1
ens16             2       false      device   1500    aa:77:34:5b:ec:f9   up|broadcast|multicast      fe80::a877:34ff:fe5b:ecf9
vlan.1881         3       true       vlan     1500    aa:77:34:5b:ec:f9   up|broadcast|multicast      1.0.0.52, fe80::a877:34ff:fe5b:ecf9
tailscale0        4       false      tuntap   1280                        up|pointtopoint|multicast   100.125.160.99, fd7a:115c:a1e0::1e01:a063, fe80::2ccf:e9f7:df00:6f93
cilium_net        5       false      veth     1500    9a:f7:07:ee:53:29   up|broadcast|multicast      fe80::98f7:7ff:feee:5329
cilium_host       6       false      veth     1500    52:2a:04:06:11:6a   up|broadcast|multicast      10.42.2.169, fe80::502a:4ff:fe06:116a
cilium_vxlan      7       false      vxlan    1500    12:c5:ad:74:1c:10   up|broadcast|multicast      fe80::10c5:adff:fe74:1c10
lxc8db2bffa7ef5   11      false      veth     1500    de:28:bb:d7:57:05   up|broadcast|multicast      fe80::dc28:bbff:fed7:5705
lxc84d84293d6ef   183     false      veth     1500    2a:19:48:0c:0f:cf   up|broadcast|multicast      fe80::2819:48ff:fe0c:fcf
lxc_health        371     false      veth     1500    a6:b8:43:2a:de:d4   up|broadcast|multicast      fe80::a4b8:43ff:fe2a:ded4
lxc2abfdded438c   373     false      veth     1500    d2:f2:54:99:77:b2   up|broadcast|multicast      fe80::d0f2:54ff:fe99:77b2

Changing policy/IPAM will trigger cilium to send gratuitous ARP to the VLAN iface (however, our upstream's provider router does not accept this)

13:00:52.258145 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1.0.0.56 tell 1.0.0.49, length 42
13:00:54.357723 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1.0.0.56 tell 1.0.0.49, length 42
13:00:55.068209 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1.0.0.56 tell 1.0.0.49, length 42
13:00:55.767885 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1.0.0.56 tell 1.0.0.49, length 42
13:00:56.468304 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1.0.0.56 tell 1.0.0.49, length 42
13:00:57.268271 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1.0.0.56 tell 1.0.0.49, length 42
13:00:57.968840 ARP, Ethernet (len 6), IPv4 (len 4), Reply 1.0.0.56 is-at aa:77:34:5b:ec:f9, length 46 (gratuitous ARP)

dumping bpftool confirms that cilium does not send any replies

# kubectl -n kube-system exec pod/cilium-l9wwv -- bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_l2_responder_v4
[{
        "key": {
            "ip4": 939625613,
            "ifindex": 3
        },
        "value": {
            "responses_sent": 0
        }
    }
]
apiVersion: "cilium.io/v2alpha1"
kind: CiliumLoadBalancerIPPool
metadata:
  name: "bm2-pool"
spec:
  blocks:
    - start: "1.0.0.56"
      stop: "1.0.0.58"
  serviceSelector:
    matchLabels:
      ipam: bm2-pool
apiVersion: "cilium.io/v2alpha1"
kind: CiliumL2AnnouncementPolicy
metadata:
  name: bm2-lbpolicy
  namespace: kube-system
spec:
  serviceSelector:
    matchExpressions:
      - {key: ipam, operator: In, values: [bm2-pool]}
  nodeSelector:
    matchExpressions:
    - key: node-role.kubernetes.io/control-plane
      operator: DoesNotExist
    matchLabels:
      kubernetes.io/hostname: bm2-metal
  interfaces:
    - vlan.1881
  externalIPs: true
  loadBalancerIPs: true

How can we reproduce the issue?

k8s + cilium setup in a trunked vlan config with allocated /24 IP address

Cilium Version

cilium 1.17.1

Kernel Version

5.15.0-131-generic #141-Ubuntu SMP Fri Jan 10 21:18:28 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Kubernetes Version

k8s v1.31.4+k3s1

Regression

No response

Sysdump

No response

Relevant log output

Anything else?

No response

Cilium Users Document

  • Are you a user of Cilium? Please add yourself to the Users doc

Code of Conduct

  • I agree to follow this project's Code of Conduct

Activity

  1. added
    kind/bugThis is a bug in the Cilium logic.
    kind/community-reportThis was reported by a user in the Cilium community, eg via Slack.
    needs/triageThis issue requires triaging to establish severity and affected area.
    on Mar 3, 2025
  2. morpig commented on Mar 3, 2025

    @morpig
    Author

    dumping cilium logs from the node does not show anything concerning(?)

    # kubectl logs -f cilium-l9wwv -n kube-system | grep "l2"
    time="2025-03-03T12:34:26.81157676Z" level=info msg="  --enable-l2-announcements='true'" subsys=daemon
    time="2025-03-03T12:34:26.811585721Z" level=info msg="  --enable-l2-neigh-discovery='true'" subsys=daemon
    time="2025-03-03T12:34:26.811595204Z" level=info msg="  --enable-l2-pod-announcements='false'" subsys=daemon
    time="2025-03-03T12:34:26.813856838Z" level=info msg="  --l2-announcements-lease-duration='15s'" subsys=daemon
    time="2025-03-03T12:34:26.813874009Z" level=info msg="  --l2-announcements-renew-deadline='5s'" subsys=daemon
    time="2025-03-03T12:34:26.81388832Z" level=info msg="  --l2-announcements-retry-period='2s'" subsys=daemon
    time="2025-03-03T12:34:26.813903161Z" level=info msg="  --l2-pod-announcements-interface=''" subsys=daemon
    time="2025-03-03T12:34:27.454143275Z" level=info msg="attempting to acquire leader lease kube-system/cilium-l2announce-kong-prod-kong-gateway-proxy-2..." subsys=klog
    time="2025-03-03T12:34:27.460506596Z" level=info msg="successfully acquired lease kube-system/cilium-l2announce-kong-prod-kong-gateway-proxy-2" subsys=klog
    time=2025-03-03T13:00:57Z level=error msg="failed to upsert ok health status" module=health error="reporting for \"agent.controlplane.l2-announcer.leader-election.job-leader-election-kong-prod-kong-gateway-proxy-2\" has been stopped"
    time="2025-03-03T13:00:57.961924227Z" level=info msg="attempting to acquire leader lease kube-system/cilium-l2announce-kong-prod-kong-gateway-proxy-2..." subsys=klog
    time="2025-03-03T13:00:57.968020336Z" level=info msg="successfully acquired lease kube-system/cilium-l2announce-kong-prod-kong-gateway-proxy-2" subsys=klog
    
  3. dylandreimerink commented on Mar 4, 2025

    @dylandreimerink
    Member

    It might be worth double checking that you are indeed running in KPR mode, which is required to load the BPF programs that normally do the ARP responding.

    Assuming that is the case, it sounds very similar to #36829. While that seems to come down to specific kernel changes in that case. I do think its similar in the sense that in certain cases the kernel does the ARP handling before the TC program, where it will drop the request since the kernel is unaware of the services.

    If I had to guess, the ARP processing happens in the kernel after the packet is received on the physical interface and before the VLAN decap and forwarding to the vlan virtual interface happens.

    We will likely have to place our BPF based ARP reply logic easier. I am thinking at the XDP layer of the physical interface (even in this setup). And we would have to make the logic VLAN aware, so it can respond to tagged traffic.

  4. github-actions commented on May 7, 2025

    @github-actions

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

  5. added
    staleThe stale bot thinks this issue is old. Add "pinned" label to prevent this from becoming stale.
    on May 7, 2025
  6. github-actions commented on May 21, 2025

    @github-actions

    This issue has not seen any activity since it was marked stale.
    Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/datapathImpacts bpf/ or low-level forwarding details, including map management and monitor messages.feature/l2-announcementkind/bugThis is a bug in the Cilium logic.kind/community-reportThis was reported by a user in the Cilium community, eg via Slack.needs/triageThis issue requires triaging to establish severity and affected area.staleThe stale bot thinks this issue is old. Add "pinned" label to prevent this from becoming stale.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions