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

Devices not becoming managed sometimes

Linking RHIVOS CVEs to...Migration: Automation ...Sync from "Extern...XMLWordPrintable

    • NetworkManager-1.53.90-1.el10
    • No
    • Important
    • ZStream
    • rhel-net-mgmt
    • ssg_networking
    • 3
    • False
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • Approved Blocker
    • Hide

      Definition of Done:

      Please mark each item below with ( / ) if completed or ( x ) if incomplete:

      ( ) The acceptance criteria defined below are met.

      Given a VRF interface is created dynamically on a node and the VRF device is brought up,

      When NetworkManager detects the new VRF interface and re-evaluates its status,

      Then the VRF interface should consistently be marked as "connected externally" and not remain in an "unmanaged" state unless explicitly configured as such.

      ( ) Code changes are included in a downstream build attached to an errata.

      ( ) All required testing (manual and/or automated) passes successfully.

      Show
      Definition of Done: Please mark each item below with ( / ) if completed or ( x ) if incomplete: ( ) The acceptance criteria defined below are met. Given a VRF interface is created dynamically on a node and the VRF device is brought up, When NetworkManager detects the new VRF interface and re-evaluates its status, Then the VRF interface should consistently be marked as "connected externally" and not remain in an "unmanaged" state unless explicitly configured as such. ( ) Code changes are included in a downstream build attached to an errata. ( ) All required testing (manual and/or automated) passes successfully.
    • Pass
    • Automated
    • Unspecified
    • Unspecified
    • Unspecified
    • None

      OVNK creates VRF devices on all cluster nodes. On some nodes, these VRF devices become managed. On other nodes it does not. From OVNK perspective all nodes are configured equal so we don't understand the difference.

      Managed in some nodes

      [jcaamano@sdn-08 origin]$ ssh core@192.168.111.20 nmcli d | grep -E "^extranet"
extranet                                                                       vrf            connected (externally)  extranet

[jcaamano@sdn-08 origin]$ ssh core@192.168.111.20 nmcli -f GENERAL.REASON device show extranet
GENERAL.REASON:                         0 (No reason given)

[jcaamano@sdn-08 origin]$ ssh core@192.168.111.20 ip -d a show extranet
26: extranet: <NOARP,MASTER,UP,LOWER_UP> mtu 65575 qdisc noqueue state UP group default 
    link/ether 96:8d:bd:2b:a4:f0 brd ff:ff:ff:ff:ff:ff promiscuity 0 allmulti 0 minmtu 1280 maxmtu 65575 
    vrf table 1025 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 gso_ipv4_max_size 65536 gro_ipv4_max_size 65536

      Unmanaged in others

      [jcaamano@sdn-08 origin]$ ssh core@192.168.111.21 nmcli d | grep -E "^extranet"
extranet                                                                       vrf            unmanaged               --

[jcaamano@sdn-08 origin]$ ssh core@192.168.111.21 nmcli -f GENERAL.REASON device show extranet
GENERAL.REASON:                         70 (The device is unmanaged because it is an external device and is unconfigured (down or without addresses))

[jcaamano@sdn-08 origin]$ ssh core@192.168.111.21 ip -d a show extranet
54: extranet: <NOARP,MASTER,UP,LOWER_UP> mtu 65575 qdisc noqueue state UP group default 
    link/ether f2:b6:45:3e:36:6a brd ff:ff:ff:ff:ff:ff promiscuity 0 allmulti 0 minmtu 1280 maxmtu 65575 
    vrf table 1053 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 gso_ipv4_max_size 65536 gro_ipv4_max_size 65536

      Attached nm_trace.log for the case it does not become managed.

        1. nm_logs.tgz
          23.71 MB
          Jaime Caamaño Ruiz
        2. nm_trace.log
          11.13 MB
          Jaime Caamaño Ruiz
        3. nm_updown_trace.log
          615 kB
          Jaime Caamaño Ruiz
        4. RHEL-89914.sh
          0.8 kB
          Beniamino Galvani

              rhn-engineering-vbenes Vladimir Benes
              jcaamano@redhat.com Jaime Caamaño Ruiz
              Network Management Team Network Management Team
              Vladimir Benes Vladimir Benes
              Votes:
              0 Vote for this issue
              Watchers:
              11 Start watching this issue

                Created:
                Updated: