Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-36735

[4.16.z]pod mac address of arp table from source pod did not be updated when destination pod mac is changed but with same ip

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done-Errata
    • Icon: Normal Normal
    • None
    • 4.13.z, 4.12.z, 4.14.z, 4.15.z, 4.16.0
    • Networking / SR-IOV
    • None
    • Important
    • Yes
    • 3
    • False
    • Hide

      None

      Show
      None
    • Hide
      * Previously, an interface created inside a new pod would remain inactive and the Gratuitous Address Resolution Protocol (GARP) notification would be generated. The notification did not reach the cluster and this prevented ARP tables of other pods inside the cluster from updating the MAC address of the new pod. This situation caused cluster traffic to stall until ARP table entries expired. With this release, a GARP notification is now sent after the interface inside a pod is active so that the GARP notification reaches the cluster. As a result, surrounding pods can identify the new pod earlier than they could with the previous behavior. (link:https://issues.redhat.com/browse/OCPBUGS-36735[*OCPBUGS-36735*])
      Show
      * Previously, an interface created inside a new pod would remain inactive and the Gratuitous Address Resolution Protocol (GARP) notification would be generated. The notification did not reach the cluster and this prevented ARP tables of other pods inside the cluster from updating the MAC address of the new pod. This situation caused cluster traffic to stall until ARP table entries expired. With this release, a GARP notification is now sent after the interface inside a pod is active so that the GARP notification reaches the cluster. As a result, surrounding pods can identify the new pod earlier than they could with the previous behavior. (link: https://issues.redhat.com/browse/OCPBUGS-36735 [* OCPBUGS-36735 *])
    • Bug Fix
    • Done

      Description of problem:

      arp table do not be updated from source pod when destination pod mac is changed but with same ip

      Version-Release number of selected component (if applicable):

          4.16.0-0.nightly-2024-03-06-073110
          sriov-network-operator.v4.16.0-202403050942

      How reproducible:

          always

      Steps to Reproduce:

          1. setup sriov operator
          2. Create 4 VF by creating snnp 
      
      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetworkNodePolicy
      metadata:
        name: e810c1
        namespace: openshift-sriov-network-operator
      spec:
        deviceType: netdevice
        nicSelector:
          deviceID: "1593"
          pfNames:
            - ens2f2
          vendor: '8086'
        nodeSelector:
          feature.node.kubernetes.io/sriov-capable: 'true'
        numVfs: 4
        priority: 99
        resourceName: e810c
              
          3. create namespace z1 and sriovnetwork cr which only have 2 ips can be used. 
      
      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetwork
      metadata:
        name: sriovnetwork
        namespace: openshift-sriov-network-operator
      spec:
        ipam: |
          {
            "type": "whereabouts",
            "range":"10.30.0.0/30"
          }
        capabilities: |
          {
            "mac": true,
            "ips": true
          }
        spoofChk: "off"
        trust: "on"
        resourceName: e810c
        networkNamespace: z1
      
      4. Check the NAD on z1
      # oc get net-attach-def -n z1
      NAME           AGE
      sriovnetwork   61m
      
      5. Create 2 test pods with the following, there will be 2 pods running
      
      apiVersion: v1
      kind: Pod
      metadata:
        generateName: testpod1
        namespace: z1
        labels:
          env: test
        annotations:
          k8s.v1.cni.cncf.io/networks: sriovnetwork
      spec:
        securityContext:
          runAsNonRoot: true
          seccompProfile:
            type: RuntimeDefault
        containers:
        - name: test-pod
          image: quay.io/openshifttest/hello-sdn@sha256:c89445416459e7adea9a5a416b3365ed3d74f2491beb904d61dc8d1eb89a72a4
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: [ALL]
        automountServiceAccountToken: false
           
      
      5. Create another test pod again. the pod will be in ContainerCreating since no ip can be used
      
      6. ssh into one pod and ping another running pod and then check the arp table 
      
       # oc rsh -n z1 testpod1mjq7w
      ~ $ arp -a
      ? (10.131.2.1) at 0a:58:0a:83:02:01 [ether] on eth0
      ? (10.30.0.1) at ce:56:74:32:f6:d1 [ether] on net1
      
      7. Delete the pod with ip 10.30.0.1, then a new pod running with ip 10.30.0.1 but mac address is changed
      
      # oc exec -n z1 testpod186fxn ip a s net1
      kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
      45: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
          link/ether 82:bc:7e:ca:92:bd brd ff:ff:ff:ff:ff:ff
          altname enp97s0f2v0
          inet 10.30.0.1/30 brd 10.30.0.3 scope global net1
             valid_lft forever preferred_lft forever
          inet6 fe80::80bc:7eff:feca:92bd/64 scope link 
             valid_lft forever preferred_lft forever
      
      8. Check the arp again of step 6, the mac address still old. 
      
      # oc rsh -n z1 testpod1mjq7w
      ~ $ arp -a
      ? (10.131.2.1) at 0a:58:0a:83:02:01 [ether] on eth0
      ? (10.30.0.1) at ce:56:74:32:f6:d1 [ether] on net1

      Actual results:

      arp table mac address still old pod mac    
      
      (10.30.0.1) at ce:56:74:32:f6:d1 [ether] on net1

      Expected results:

       arp table mac address should be updated to
         
       (10.30.0.1) at 82:bc:7e:ca:92:bd [ether] on net1

      Additional info:

          

              thaller@redhat.com Thomas Haller
              zzhao1@redhat.com Zhanqi Zhao
              Zhanqi Zhao Zhanqi Zhao
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: