6.7. OVS 하드웨어 오프로드 문제 해결

사전 요구 사항

  • Linux Kernel 4.13 이상
  • OVS 2.8 이상
  • RHOSP 12 이상
  • iproute 4.12 이상
  • Mellanox NIC 펌웨어 (예: FW ConnectX-5 16.21.0338 이상)

지원되는 사전 요구 사항에 대한 자세한 내용은 Red Hat Knowledgebase 솔루션 Network Adapter Fast Datapath 기능 지원 매트릭스 를 참조하십시오.

OVS HW 오프로드 배포에서 네트워크 구성

HW 오프로드 배포에서는 요구 사항에 따라 다음 시나리오 중 하나를 선택할 수 있습니다.

  • 본딩에 연결된 동일한 인터페이스 집합 또는 각 유형에 대해 다른 NIC 세트를 사용하여 VXLAN 및 VLAN에 게스트 VM을 기반으로 할 수 있습니다.
  • Linux 본딩을 사용하여 Mellanox NIC의 두 포트를 본딩할 수 있습니다.
  • Mellanox Linux 본딩의 VLAN 인터페이스에서 테넌트 VXLAN 네트워크를 호스팅할 수 있습니다.

개별 NIC 및 본딩이 ovs-bridge의 구성원인지 확인합니다.

아래 네트워크 구성 예제를 참조하십시오.

             - type: ovs_bridge
                name: br-offload
                mtu: 9000
                use_dhcp: false
                members:
                - type: linux_bond
                  name: bond-pf
                  bonding_options: "mode=active-backup miimon=100"
                  members:
                  - type: sriov_pf
                    name: p5p1
                    numvfs: 3
                    primary: true
                    promisc: true
                    use_dhcp: false
                    defroute: false
                    link_mode: switchdev
                  - type: sriov_pf
                    name: p5p2
                    numvfs: 3
                    promisc: true
                    use_dhcp: false
                    defroute: false
                    link_mode: switchdev

              - type: vlan
                vlan_id:
                  get_param: TenantNetworkVlanID
                device: bond-pf
                addresses:
                - ip_netmask:
                    get_param: TenantIpSubnet

다음과 같은 검증된 본딩 구성을 참조하십시오.

  • active-backup - mode=1
  • active-active 또는 balance-xor - mode=2
  • 802.3ad (LACP) - mode=4

인터페이스 구성 확인

다음 절차에 따라 인터페이스 구성을 확인합니다.

절차

  1. 배포하는 동안 호스트 네트워크 구성 도구 os-net-config 를 사용하여 hw-tc-offload 를 활성화합니다.
  2. 컴퓨팅 노드를 재부팅할 때마다 sriov_config 서비스에서 hw-tc-offload 를 활성화합니다.
  3. 본딩에 연결된 NIC 에 대해 hw-tc-offload 매개변수를 on 으로 설정합니다.

    [root@overcloud-computesriov-0 ~]# ethtool -k ens1f0 | grep tc-offload
    hw-tc-offload: on

인터페이스 모드 확인

다음 절차에 따라 인터페이스 모드를 확인합니다.

절차

  1. HW 오프로드에 사용하는 인터페이스에 대해 eswitch 모드를 switchdev 로 설정합니다.
  2. 호스트 네트워크 구성 도구 os-net-config 를 사용하여 배포 중에 eswitch 를 활성화합니다.
  3. 컴퓨팅 노드를 재부팅할 때마다 sriov_config 서비스에서 eswitch 를 활성화합니다.

    [root@overcloud-computesriov-0 ~]# devlink dev eswitch show pci/$(ethtool -i ens1f0 | grep bus-info | cut -d ':' -f 2,3,4 | awk '{$1=$1};1')
참고

PF 인터페이스의 드라이버는 e-switch uplink 포트의 대표임을 표시하기 위해 "\\x5e_rep" 로 설정됩니다. 이는 기능에 영향을 미치지 않습니다.

OVS에서 오프로드 상태 확인

다음 절차를 사용하여 OVS에서 오프로드 상태를 확인합니다.

  • 컴퓨팅 노드에서 OVS에서 하드웨어 오프로드를 활성화합니다.

    [root@overcloud-computesriov-0 ~]# ovs-vsctl get Open_vSwitch . other_config:hw-offload
    "true"

VF 대표 포트의 이름 확인

VF 표현자 포트의 일관된 이름을 확인하기 위해 os-net-config 는 udev 규칙을 사용하여 <PF-name>_<VF_id> 형식의 포트 이름을 변경합니다.

절차

  • 배포 후 VF 대표 포트의 이름이 올바르게 지정되었는지 확인합니다.

    root@overcloud-computesriov-0 ~]# cat /etc/udev/rules.d/80-persistent-os-net-config.rules
    # This file is autogenerated by os-net-config
    
    SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}!="", ATTR{phys_port_name}=="pf*vf*", ENV{NM_UNMANAGED}="1"
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", KERNELS=="0000:65:00.0", NAME="ens1f0"
    SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}=="98039b7f9e48", ATTR{phys_port_name}=="pf0vf*", IMPORT{program}="/etc/udev/rep-link-name.sh $attr{phys_port_name}", NAME="ens1f0_$env{NUMBER}"
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", KERNELS=="0000:65:00.1", NAME="ens1f1"
    SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}=="98039b7f9e49", ATTR{phys_port_name}=="pf1vf*", IMPORT{program}="/etc/udev/rep-link-name.sh $attr{phys_port_name}", NAME="ens1f1_$env{NUMBER}"

네트워크 트래픽 흐름 검사

HW 오프로드된 네트워크 흐름 기능은 애플리케이션별 ASIC(통합 회로) 칩을 사용하는 물리적 스위치 또는 라우터와 유사한 방식으로 작동합니다. 스위치 또는 라우터의 ASIC 쉘에 액세스하여 라우팅 테이블과 다른 디버깅을 검사할 수 있습니다. 다음 절차에서는 Cumuls Linux 스위치의 Broadcom 칩셋을 예로 사용합니다. 환경에 적합한 값을 바꿉니다.

절차

  1. Broadcom 칩 테이블 콘텐츠를 얻으려면 bcmcmd 명령을 사용합니다.

    root@dni-7448-26:~# cl-bcmcmd l2 show
    
    mac=00:02:00:00:00:08 vlan=2000 GPORT=0x2 modid=0 port=2/xe1
    mac=00:02:00:00:00:09 vlan=2000 GPORT=0x2 modid=0 port=2/xe1 Hit
  2. TC(트래픽 제어) 계층을 검사합니다.

    # tc -s filter show dev p5p1_1 ingress
    …
    filter block 94 protocol ip pref 3 flower chain 5
    filter block 94 protocol ip pref 3 flower chain 5 handle 0x2
      eth_type ipv4
      src_ip 172.0.0.1
      ip_flags nofrag
      in_hw in_hw_count 1
            action order 1: mirred (Egress Redirect to device eth4) stolen
            index 3 ref 1 bind 1 installed 364 sec used 0 sec
            Action statistics:
            Sent 253991716224 bytes 169534118 pkt (dropped 0, overlimits 0 requeues 0)
            Sent software 43711874200 bytes 30161170 pkt
            Sent hardware 210279842024 bytes 139372948 pkt
            backlog 0b 0p requeues 0
            cookie 8beddad9a0430f0457e7e78db6e0af48
            no_percpu
  3. 이 출력의 in_hw 플래그와 통계를 검사합니다. 하드웨어 라는 단어는 하드웨어에서 네트워크 트래픽을 처리함을 나타냅니다. usetc -policy=none 인 경우 하드웨어나 소프트웨어가 패킷을 처리할 때 조사할 이 출력 또는 tcpdump를 확인할 수 있습니다. 드라이버가 패킷을 오프로드할 수 없는 경우 dmesg 또는 ovs-vswitch.log 에서 해당 로그 메시지를 확인할 수 있습니다.
  4. 예를 들어 Mellanox의 경우 로그 항목은 dmesg 의 메시지와 유사합니다.

    [13232.860484] mlx5_core 0000:3b:00.0: mlx5_cmd_check:756:(pid 131368): SET_FLOW_TABLE_ENTRY(0x936) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0x6b1266)

    이 예제에서 오류 코드 (0x6b1266)는 다음 동작을 나타냅니다.

    0x6B1266 |  set_flow_table_entry: pop vlan and forward to uplink is not allowed

시스템 검증

다음 절차에 따라 시스템을 검증합니다.

절차

  1. SR-IOV 및 VT-d가 시스템에서 활성화되었는지 확인합니다.
  2. 커널 매개 변수에 intel_iommu=on 을 추가하여 Linux에서 IOMMU를 활성화합니다(예: GRUB 사용).

제한

OVS 2.11의 오프로드 경로에서 흐름의 연결 추적 속성을 지원하지 않으므로 HW 오프로드와 함께 OVS 방화벽 드라이버를 사용할 수 없습니다.