Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-5886

Network Manager DHCP is not working when the ovs-bridge.datapath-type is netdev

    • NetworkManager-1.45.6-1.el9
    • 1
    • sst_network_management
    • ssg_networking
    • 11
    • 5
    • False
    • Hide

      None

      Show
      None
    • No
    • Red Hat Enterprise Linux
    • NMT - RHEL 8.10/9.4 DTM 08
    • Hide

      Given a system administrator running a system with NetworkManager, 
      When they configure an OVS bridge with `datapath-type` set to `netdev` and initiate a DHCP request, 
      Then the DHCP process should complete successfully without errors, and an IP address should be allocated to the interface and the OVS bridge should be correctly set up and functional with the given `datapath-type`.

      Definition of Done

      • The implementation meets the acceptance criteria
      • The unit test and integration tests are written and passed
      • The code is part of a build attached to an errata
      Show
      Given a system administrator running a system with NetworkManager,  When they configure an OVS bridge with `datapath-type` set to `netdev` and initiate a DHCP request,  Then the DHCP process should complete successfully without errors, and an IP address should be allocated to the interface and the OVS bridge should be correctly set up and functional with the given `datapath-type`. Definition of Done The implementation meets the acceptance criteria The unit test and integration tests are written and passed The code is part of a build attached to an errata
    • Pass
    • Automated
    • None

      The DHCP process is not following trough when the interface is an ovs-interface attached to an ovs-bridge of ovs-bridge.datapath-type netdev. The following log message is seen:

      Sep 21 13:04:04 wsfd-advnetlab224.anl.lab.eng.bos.redhat.com NetworkManager[1863]: <warn>  [1695294244.8222] device (br-ex): set-hw-addr: new MAC address 52:54:F8:DA:C3:04 not successfully set-cloned (52:54:F8:DA:C3:04)
      Sep 21 13:04:04 wsfd-advnetlab224.anl.lab.eng.bos.redhat.com NetworkManager[1863]: <info>  [1695294244.8226] device (br-ex): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
      Sep 21 13:04:04 wsfd-advnetlab224.anl.lab.eng.bos.redhat.com NetworkManager[1863]: <info>  [1695294244.8229] device (br-ex): detaching ovs interface br-ex
      Sep 21 13:04:04 wsfd-advnetlab224.anl.lab.eng.bos.redhat.com NetworkManager[1863]: <info>  [1695294244.8231] device (br-ex): released from master device br-ex
      Sep 21 13:04:04 wsfd-advnetlab224.anl.lab.eng.bos.redhat.com NetworkManager[1863]: <warn>  [1695294244.8233] device (br-ex): Activation: failed for connection 'ovs-if-br-ex'
      Sep 21 13:04:04 wsfd-advnetlab224.anl.lab.eng.bos.redhat.com NetworkManager[1863]: <info>  [1695294244.8239] device (br-ex): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
      Sep 21 13:04:04 wsfd-advnetlab224.anl.lab.eng.bos.redhat.com NetworkManager[1863]: <info>  [1695294244.8280] dhcp4 (br-ex): canceled DHCP transaction
      Sep 21 13:04:04 wsfd-advnetlab224.anl.lab.eng.bos.redhat.com NetworkManager[1863]: <info>  [1695294244.8280] dhcp4 (br-ex): state changed no lease
      Sep 21 13:04:04 wsfd-advnetlab224.anl.lab.eng.bos.redhat.com NetworkManager[1863]: <debug> [1695294244.8286] global-tracker: sync routing-rule
      Sep 21 13:04:04 wsfd-advnetlab224.anl.lab.eng.bos.redhat.com NetworkManager[1863]: file src/core/devices/nm-device.c: line 16944 (<dropped>): should not be reached

       

      This can simply be replicated with the following:

       

      # Wipe OVS configuration, and set it up for OVS-DPDK:
        systemctl stop openvswitch
        rm -f /etc/openvswitch/conf.db
        systemctl restart openvswitch
        ovs-vsctl set Open_vSwitch . other_config:dpdk-init=true
        systemctl restart openvswitch
        # Configure NM
        for conn in $(nmcli -g NAME c | grep br-ex); do nmcli c del "$conn"; done
        for conn in $(nmcli -g NAME c | grep ovs-); do nmcli c del "$conn"; done
        # journalctl -f -u NetworkManager | tee networkmanager.log
        nmcli general logging level trace
        nmcli c add type ovs-bridge con-name br-ex conn.interface br-ex 802-3-ethernet.mtu 1500 connection.autoconnect-slaves 1 ovs-bridge.datapath-type netdev connection.autoconnect no
        nmcli c add type ovs-port conn.interface ens2f1np1 master br-ex con-name ovs-port-phys0 connection.autoconnect-slaves 1 connection.autoconnect no
        nmcli c add type ovs-port conn.interface br-ex master br-ex con-name ovs-port-br-ex connection.autoconnect no
        nmcli c add type 802-3-ethernet conn.interface ens2f1np1 master ovs-port-phys0 con-name ovs-if-phys0 connection.autoconnect-priority 100 connection.autoconnect-slaves 1 802-3-ethernet.mtu 1500 802-3-ethernet.cloned-mac-address 52:54:f8:da:c3:04 connection.autoconnect no
        nmcli c add type ovs-interface slave-type ovs-port conn.interface br-ex master ovs-port-br-ex con-name ovs-if-br-ex 802-3-ethernet.mtu 1500 802-3-ethernet.cloned-mac-address 52:54:f8:da:c3:04 ipv4.method auto ipv4.route-metric 48 ipv6.method disabled ipv4.may-fail no connection.autoconnect no
        nmcli c up br-ex
        nmcli c mod br-ex connection.autoconnect yes
        nmcli c mod ovs-if-phys0 connection.autoconnect yes
        nmcli c up ovs-if-br-ex
      

       
      The Networkmanager log is attached.

      $ rpm -qa | grep NetworkManager
      NetworkManager-libnm-1.42.2-8.el9_2.x86_64
      NetworkManager-1.42.2-8.el9_2.x86_64
      NetworkManager-wwan-1.42.2-8.el9_2.x86_64
      NetworkManager-bluetooth-1.42.2-8.el9_2.x86_64
      NetworkManager-ovs-1.42.2-8.el9_2.x86_64
      NetworkManager-adsl-1.42.2-8.el9_2.x86_64
      NetworkManager-team-1.42.2-8.el9_2.x86_64
      NetworkManager-tui-1.42.2-8.el9_2.x86_64
      NetworkManager-wifi-1.42.2-8.el9_2.x86_64
      NetworkManager-config-server-1.42.2-8.el9_2.noarch

            bgalvani@redhat.com Beniamino Galvani
            echaudro@redhat.com Eelco Chaudron
            Network Management Team Network Management Team
            Filip Pokrývka Filip Pokrývka
            Votes:
            0 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: