절차

1. stack 사용자로 언더클라우드에 로그인합니다.

2. 템플릿 파일 /home/stack/templates/containers-prepare-parameter.yaml 에서 ovn 대신 neutron_driver 매개 변수 값으로 ovs 을 사용합니다.

   parameter_defaults:
     ContainerImagePrepare:
     - set:
         ...
         neutron_driver: ovs

3. 환경 파일에서 /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml 에서 NeutronNetworkType 매개변수에 original ve 대신 ScanSetting 또는 gre 가 포함되어 있는지 확인합니다.

   예제

   parameter_defaults:
     ...
     NeutronNetworkType: 'vxlan'

4. openstack overcloud deploy 명령을 실행하고 수정한 코어 heat 템플릿, 환경 파일 및 파일을 포함합니다.

   중요

   후속 환경 파일에 정의된 매개 변수와 리소스가 우선하기 때문에 환경 파일의 순서가 중요합니다.

   $ openstack overcloud deploy --templates \
   -e <your_environment_files> \
   -e /usr/share/openstack-tripleo-heat-templates/environments/services/ \
   neutron-ovs.yaml \
   -e /home/stack/templates/containers-prepare-parameter.yaml \

절차

1. 언더클라우드 호스트에 stack 사용자로 로그인하고 stackrc 파일을 소싱합니다.

   $ source stackrc

2. 배포에 적합한 사용자 지정 역할 파일을 선택합니다. 필요에 따라 배포 명령에 직접 사용합니다. 또는 다른 사용자 지정 역할 파일을 결합하는 사용자 지정 역할 파일을 생성할 수 있습니다.

   Deployment	Role	역할 파일
   Networker 역할	Networker	Networker.yaml
   SR-IOV를 통한 Networker 역할	NetworkerSriov	NetworkerSriov.yaml
   SR-IOV를 사용한 공동 배치 제어 및 네트워크	ControllerSriov	ControllerSriov.yaml

3. [선택 사항] 이러한 사용자 지정 역할 파일 중 하나를 다른 사용자 지정 역할 파일과 결합하는 새 사용자 지정 역할 데이터 파일을 생성합니다. Advanced Overcloud Customization 가이드의 roles_data 파일 생성에 있는 지침을 따르십시오. 배포에 따라 적절한 소스 역할 파일을 포함합니다.
4. [선택 사항] 역할의 특정 노드를 식별하기 위해 특정 하드웨어 플레이버를 생성하고 특정 노드에 플레이버를 할당할 수 있습니다. 그런 다음 환경 파일을 사용하여 역할의 플레이버를 정의하고 노드 수를 지정합니다. 자세한 내용은 Advanced Overcloud Customization 가이드의 새 역할 생성 예제를 참조하십시오.

5. 배포에 적합한 환경 파일을 만듭니다.

   Deployment	샘플 환경 파일
   Networker 역할	neutron-ovn-dvr-ha.yaml
   SR-IOV를 통한 Networker 역할	ovn-sriov.yaml

6. 배포에 적합한 다음 설정을 포함합니다.

   Deployment	설정
   Networker 역할	ControllerParameters: OVNCMSOptions: "" ControllerSriovParameters: OVNCMSOptions: "" NetworkerParameters: OVNCMSOptions: "enable-chassis-as-gw" NetworkerSriovParameters: OVNCMSOptions: ""
   SR-IOV를 통한 Networker 역할	OS::TripleO::Services::NeutronDhcpAgent: OS::Heat::None ControllerParameters: OVNCMSOptions: "" ControllerSriovParameters: OVNCMSOptions: "" NetworkerParameters: OVNCMSOptions: "" NetworkerSriovParameters: OVNCMSOptions: "enable-chassis-as-gw"
   SR-IOV를 사용한 공동 배치 제어 및 네트워크	OS::TripleO::Services::NeutronDhcpAgent: OS::Heat::None ControllerParameters: OVNCMSOptions: "" ControllerSriovParameters: OVNCMSOptions: "enable-chassis-as-gw" NetworkerParameters: OVNCMSOptions: "" NetworkerSriovParameters: OVNCMSOptions: ""

7. 오버클라우드를 배포합니다. -e 옵션을 사용하여 배포 명령에 환경 파일을 포함합니다. r 옵션을 사용하여 배포 명령에 사용자 지정 역할 데이터 파일을 포함합니다. 예: -r Networker.yaml 또는 -r mycustomrolesfile.yaml.

검증 단계 - OVN 배포

1. 기본적으로 heat-admin 인 오버클라우드 SSH 사용자로 컨트롤러 또는 네트워크 노드에 로그인합니다.

   예제

   ssh heat-admin@controller-0

2. Controller 및 Networker 노드에서 ovn_metadata_agent 가 실행 중인지 확인합니다.

   $ sudo podman ps | grep ovn_metadata

   샘플 출력

   a65125d9588d  undercloud-0.ctlplane.localdomain:8787/rh-osbs/rhosp16-openstack-neutron-metadata-agent-ovn:16.2_20200813.1  kolla_start           23 hours ago  Up 21 hours ago         ovn_metadata_agent

3. OVN 서비스 또는 전용 네트워크 노드가 있는 컨트롤러 노드가 OVS의 게이트웨이로 구성되어 있는지 확인합니다.

   $ sudo ovs-vsctl get Open_Vswitch . external_ids:ovn-cms-options

   샘플 출력

   ...
       enable-chassis-as-gw
   ...

검증 단계 - SR-IOV 배포

1. 기본적으로 heat-admin 인 오버클라우드 SSH 사용자로 컴퓨팅 노드에 로그인합니다.

   예제

   ssh heat-admin@compute-0

2. neutron_sriov_agent 가 컴퓨팅 노드에서 실행 중인지 확인합니다.

   $ sudo podman ps | grep neutron_sriov_agent

   샘플 출력

   f54cbbf4523a  undercloud-0.ctlplane.localdomain:8787/rh-osbs/rhosp16-openstack-neutron-sriov-agent:16.2_20200813.1
   kolla_start  23 hours ago  Up 21 hours ago         neutron_sriov_agent

3. 네트워크 사용 SR-IOV NIC가 성공적으로 감지되었는지 확인합니다.

   $ sudo podman exec -uroot galera-bundle-podman-0 mysql nova -e 'select hypervisor_hostname,pci_stats from compute_nodes;'

   샘플 출력

   computesriov-1.localdomain	{... {"dev_type": "type-PF", "physical_network": "datacentre", "trusted": "true"}, "count": 1}, ... {"dev_type": "type-VF", "physical_network": "datacentre", "trusted": "true", "parent_ifname": "enp7s0f3"}, "count": 5}, ...}
   computesriov-0.localdomain	{... {"dev_type": "type-PF", "physical_network": "datacentre", "trusted": "true"}, "count": 1}, ... {"dev_type": "type-VF", "physical_network": "datacentre", "trusted": "true", "parent_ifname": "enp7s0f3"}, "count": 5}, ...}

1. 대시보드에서 프로젝트 > 네트워크 > 라우터 를 선택합니다.

2. Routers (라우터) 목록에서 가상 라우터 이름을 선택하고 Add Interface(인터페이스 추가 )를 클릭합니다.

   Subnet(서브넷) 목록에서 새 서브넷의 이름을 선택합니다. 이 필드의 인터페이스에 대한 IP 주소를 선택적으로 지정할 수 있습니다.

3. Add Interface (인터페이스 추가)를 클릭합니다.

   이제 네트워크의 인스턴스가 서브넷 외부의 시스템과 통신할 수 있습니다.

1. 대시보드에서 프로젝트 > 네트워크 > 네트워크를 선택합니다.

2. +Create Network (+네트워크 만들기)를 클릭하고 다음 값을 지정합니다.

   필드	설명
   네트워크 이름	네트워크에서 수행할 역할에 따라 설명적인 이름입니다. 네트워크를 외부 VLAN과 통합하는 경우 VLAN ID 번호를 이름에 추가하는 것이 좋습니다. 예를 들어, webservers_122 에서 이 서브넷에서 HTTP 웹 서버를 호스팅하는 경우 VLAN 태그가 122 입니다. 또는 네트워크 트래픽을 비공개로 유지하고 네트워크를 외부 네트워크와 통합하지 않으려는 경우 internal 전용을 사용할 수 있습니다.
   관리 상태	네트워크를 즉시 사용할 수 있는지 여부를 제어합니다. 이 필드를 사용하여 논리적으로 존재하지만 비활성 상태인 Down 상태의 네트워크를 생성합니다. 이 기능은 네트워크를 즉시 프로덕션에 입력하려는 경우 유용합니다.
   서브넷 만들기	서브넷을 만들지 여부를 결정합니다. 예를 들어 이 네트워크를 네트워크 연결 없이 자리 표시자로 유지하려는 경우 서브넷을 생성하지 않을 수 있습니다.

3. Next 단추를 클릭하고 Subnet( 서브넷) 탭에서 다음 값을 지정합니다.

   필드	설명
   서브넷 이름	서브넷의 설명이 포함된 이름을 입력합니다.
   네트워크 주소	IP 주소 범위와 서브넷 마스크가 포함된 CIDR 형식으로 주소를 하나의 값으로 입력합니다. 주소를 확인하려면 서브넷 마스크에 마스킹된 비트 수를 계산하고 해당 값을 IP 주소 범위에 추가합니다. 예를 들어 서브넷 마스크 255.255.255.0에는 24개의 마스킹된 비트가 있습니다. IPv4 주소 범위 192.168.122.0으로 이 마스크를 사용하려면 주소 192.168.122.0/24를 지정합니다.
   IP 버전	유효한 유형이 IPv4 또는 IPv6인 인터넷 프로토콜 버전을 지정합니다. Network Address(네트워크 주소) 필드의 IP 주소 범위는 선택한 모든 버전과 일치해야 합니다.
   게이트웨이 IP	기본 게이트웨이에 대한 라우터 인터페이스의 IP 주소입니다. 이 주소는 외부 위치로 향하는 트래픽을 라우팅하기 위한 다음 홉이며, 네트워크 주소 필드에 지정하는 범위 내에 있어야 합니다. 예를 들어 CIDR 네트워크 주소가 192.168.122.0/24인 경우 기본 게이트웨이는 192.168.122.1일 수 있습니다.
   게이트웨이 비활성화	는 전달을 비활성화하고 서브넷을 격리합니다.

4. 다음을 클릭하여 DHCP 옵션을 지정합니다.

   • DHCP 활성화 - 이 서브넷에 DHCP 서비스를 활성화합니다. DHCP를 사용하여 인스턴스에 대한 IP 설정을 자동으로 배포할 수 있습니다.

   • IPv6 주소 - 구성 모드. IPv6 네트워크를 생성하는 경우 IPv6 주소 및 추가 정보를 할당하는 방법을 지정해야 합니다.

     • 지정된 옵션 없음 - IP 주소를 수동으로 설정하거나 주소 할당에 OpenStack을 인식하지 않는 방법을 사용하려면 이 옵션을 선택합니다.
     • SLAAC(상태 비저장 주소 자동 구성) - 인스턴스에서 OpenStack Networking 라우터에서 보낸 R(라우터 알림) 메시지를 기반으로 IPv6 주소를 생성합니다. 이 구성을 사용하여 ra_mode가 slaac로 설정된 OpenStack Networking 서브넷을 만들고 address_mode를 slaac로 설정합니다.
     • DHCPv6 상태 저장 - 인스턴스에서 IPv6 주소 및 OpenStack Networking DHCPv6 서비스에서 추가 옵션(예: DNS)을 수신합니다. 이 구성을 사용하여 ra_mode가 dhcpv6-stateful로 설정되어 있고 address_mode가 dhcpv6-stateful로 설정된 서브넷을 생성합니다.
     • DHCPv6 상태 비저장 - 인스턴스에서 OpenStack Networking 라우터에서 전송된 라우터 알림(RA) 메시지를 기반으로 IPv6 주소를 생성합니다. 추가 옵션(예: DNS)은 OpenStack Networking DHCPv6 서비스에서 할당됩니다. 이 구성을 사용하여 ra_mode가 dhcpv6-stateless로 설정된 서브넷을 만들고 address_mode를 dhcpv6-stateless로 설정합니다.
   • 할당 풀 - DHCP가 할당할 IP 주소 범위입니다. 예를 들어 192.168.22.100,192.168.22.150 값은 해당 범위의 모든 주소를 할당에 사용할 수 있는 것으로 간주합니다.

   • DNS 이름 서버 - 네트워크에서 사용할 수 있는 DNS 서버의 IP 주소입니다. DHCP는 이름 확인을 위해 이러한 주소를 인스턴스에 배포합니다.

     중요

     DNS와 같은 전략적 서비스의 경우 클라우드에 호스팅하지 않는 것이 좋습니다. 예를 들어, 클라우드 호스트 DNS와 클라우드가 작동할 수 없게 되면 DNS를 사용할 수 없으며 클라우드 구성 요소는 서로 조회를 수행할 수 없습니다.

   • 호스트 경로 - 정적 호스트 경로. 먼저 CIDR 형식의 대상 네트워크를 지정한 다음 라우팅에 사용할 다음 홉을 지정합니다(예: 192.168.23.0/24, 10.1.31.1). 정적 경로를 인스턴스에 배포해야 하는 경우 이 값을 제공합니다.

5. 생성을 클릭합니다.

   Networks(네트워크 ) 탭에서 전체 네트워크를 볼 수 있습니다. 필요에 따라 Edit(편집 )를 클릭하여 옵션을 변경할 수도 있습니다. 인스턴스를 만들 때 서브넷을 사용하도록 이제 구성할 수 있으며 지정된 DHCP 옵션이 제공됩니다.

1. 대시보드에서 Project > Network > Networks(네트워크 > 네트워크 ) 를 선택하고 Networks( 네트워크 ) 보기에서 네트워크 이름을 클릭합니다.

2. Create Subnet(서브넷 만들기) 을 클릭하고 다음 값을 지정합니다.

   필드	설명
   서브넷 이름	설명이 포함된 서브넷 이름.
   네트워크 주소	IP 주소 범위와 서브넷 마스크를 하나의 값으로 포함하는 CIDR 형식의 주소입니다. CIDR 주소를 확인하려면 서브넷 마스크에 마스킹된 비트 수를 계산하고 해당 값을 IP 주소 범위에 추가합니다. 예를 들어 서브넷 마스크 255.255.255.0에는 24개의 마스킹된 비트가 있습니다. IPv4 주소 범위 192.168.122.0으로 이 마스크를 사용하려면 주소 192.168.122.0/24를 지정합니다.
   IP 버전	인터넷 프로토콜 버전입니다. 여기서 유효한 유형은 IPv4 또는 IPv6입니다. Network Address(네트워크 주소) 필드의 IP 주소 범위는 선택한 모든 프로토콜 버전과 일치해야 합니다.
   게이트웨이 IP	기본 게이트웨이에 대한 라우터 인터페이스의 IP 주소입니다. 이 주소는 외부 위치로 향하는 트래픽을 라우팅하기 위한 다음 홉이며, 네트워크 주소 필드에 지정하는 범위 내에 있어야 합니다. 예를 들어 CIDR 네트워크 주소가 192.168.122.0/24인 경우 기본 게이트웨이는 192.168.122.1일 수 있습니다.
   게이트웨이 비활성화	는 전달을 비활성화하고 서브넷을 격리합니다.

3. 다음을 클릭하여 DHCP 옵션을 지정합니다.

   • DHCP 활성화 - 이 서브넷에 DHCP 서비스를 활성화합니다. DHCP를 사용하여 인스턴스에 대한 IP 설정을 자동으로 배포할 수 있습니다.

   • IPv6 주소 - 구성 모드. IPv6 네트워크를 생성하는 경우 IPv6 주소 및 추가 정보를 할당하는 방법을 지정해야 합니다.

     • 지정된 옵션 없음 - IP 주소를 수동으로 설정하거나 주소 할당에 OpenStack을 인식하지 않는 방법을 사용하려면 이 옵션을 선택합니다.
     • SLAAC(상태 비저장 주소 자동 구성) - 인스턴스에서 OpenStack Networking 라우터에서 보낸 R(라우터 알림) 메시지를 기반으로 IPv6 주소를 생성합니다. 이 구성을 사용하여 ra_mode가 slaac로 설정된 OpenStack Networking 서브넷을 만들고 address_mode를 slaac로 설정합니다.
     • DHCPv6 상태 저장 - 인스턴스에서 IPv6 주소 및 OpenStack Networking DHCPv6 서비스에서 추가 옵션(예: DNS)을 수신합니다. 이 구성을 사용하여 ra_mode가 dhcpv6-stateful로 설정되어 있고 address_mode가 dhcpv6-stateful로 설정된 서브넷을 생성합니다.
     • DHCPv6 상태 비저장 - 인스턴스에서 OpenStack Networking 라우터에서 전송된 라우터 알림(RA) 메시지를 기반으로 IPv6 주소를 생성합니다. 추가 옵션(예: DNS)은 OpenStack Networking DHCPv6 서비스에서 할당됩니다. 이 구성을 사용하여 ra_mode가 dhcpv6-stateless로 설정된 서브넷을 만들고 address_mode를 dhcpv6-stateless로 설정합니다.
   • 할당 풀 - DHCP가 할당할 IP 주소 범위입니다. 예를 들어 192.168.22.100,192.168.22.150 값은 해당 범위의 모든 주소를 할당에 사용할 수 있는 것으로 간주합니다.
   • DNS 이름 서버 - 네트워크에서 사용할 수 있는 DNS 서버의 IP 주소입니다. DHCP는 이름 확인을 위해 이러한 주소를 인스턴스에 배포합니다.
   • 호스트 경로 - 정적 호스트 경로. 먼저 CIDR 형식의 대상 네트워크를 지정한 다음 라우팅에 사용할 다음 홉을 지정합니다(예: 192.168.23.0/24, 10.1.31.1). 정적 경로를 인스턴스에 배포해야 하는 경우 이 값을 제공합니다.

4. 생성을 클릭합니다.

   Subnets(서브넷) 목록에서 서브넷을 볼 수 있습니다. 필요에 따라 Edit(편집 )를 클릭하여 옵션을 변경할 수도 있습니다. 인스턴스를 만들 때 서브넷을 사용하도록 이제 구성할 수 있으며 지정된 DHCP 옵션이 제공됩니다.

1. 대시보드에서 프로젝트 > 네트워크 > 라우터를 선택하고 Create Router(라우터 만들기 )를 클릭합니다.
2. 새 라우터의 설명이 포함된 이름을 입력하고 Create router(라우터 만들기 )를 클릭합니다.
3. Routers (라우터) 목록에서 새 라우터의 항목 옆에 있는 Set Gateway (게이트웨이 설정)를 클릭합니다.
4. External Network (외부 네트워크) 목록에서 외부 위치로 향하는 트래픽을 수신하려는 네트워크를 지정합니다.

5. Set Gateway (게이트웨이 설정)를 클릭합니다.

   라우터를 추가한 후 이 라우터를 사용하여 트래픽을 보내도록 만든 서브넷을 구성해야 합니다. 서브넷과 라우터 간에 인터페이스를 만들어 이 작업을 수행합니다.

1. 대시보드에서 프로젝트 > 네트워크 > 라우터 를 선택하고 삭제하려는 라우터 이름을 클릭합니다.
2. 내부 인터페이스 유형의 인터페이스를 선택하고 Delete Interfaces(인터페이스 삭제 )를 클릭합니다.
3. Routers(라우터) 목록에서 대상 라우터를 선택하고 Delete Routers(라우터 삭제 )를 클릭합니다.

1. 대시보드에서 프로젝트 > 네트워크 > 네트워크를 선택합니다.
2. 네트워크 이름을 클릭합니다.
3. 대상 서브넷을 선택하고 Delete Subnets(서브넷 삭제 )를 클릭합니다.

1. 대시보드에서 프로젝트 > 네트워크 > 네트워크를 선택합니다.

   대상 네트워크 서브넷과 연결된 모든 라우터 인터페이스를 제거합니다.

   인터페이스를 제거하려면 Networks (네트워크) 목록에서 대상 네트워크를 클릭하고 ID 필드를 확인하여 삭제할 네트워크의 ID 번호를 찾습니다. 네트워크와 연결된 모든 서브넷은 네트워크 ID 필드에서 이 값을 공유합니다.

2. Project(프로젝트) > Network > Routers (네트워크 > 라우터) 로 이동하여 Routers (라우터) 목록에서 가상 라우터 이름을 클릭하고 삭제하려는 서브넷에 연결된 인터페이스를 찾습니다.

   게이트웨이 IP로 제공되는 IP 주소로 이 서브넷을 다른 서브넷과 구분할 수 있습니다. 인터페이스의 네트워크 ID가 이전 단계에서 기록한 ID와 일치하는지 확인하여 차이점을 추가로 확인할 수 있습니다.

3. 삭제할 인터페이스에 대해 Delete Interface (인터페이스 삭제) 단추를 클릭합니다.
4. 프로젝트 > 네트워크 > 네트워크를 선택하고 네트워크 이름을 클릭합니다.

5. 삭제할 서브넷의 Delete Subnet(서브넷 삭제) 단추를 클릭합니다.

   참고

   이때 서브넷을 제거할 수 없는 경우 인스턴스에서 서브넷을 아직 사용하지 않는지 확인합니다.

6. 프로젝트 > 네트워크 > 네트워크를 선택하고 삭제하려는 네트워크를 선택합니다.
7. Delete Networks(네트워크 삭제)를 클릭합니다.

절차

1. Undercloud 호스트에서 stack 사용자로 로그인한 사용자 지정 YAML 환경 파일을 만듭니다.

   예제

   $ vi /home/stack/templates/my-modules-environment.yaml

   작은 정보

   Red Hat OpenStack Platform Orchestration 서비스(heat)는 templates 라는 플랜 세트를 사용하여 환경을 설치하고 구성합니다. 오케스트레이션 템플릿에 대한 사용자 지정을 제공하는 특수 유형의 템플릿 파일인 사용자 지정 환경 파일을 사용하여 오버클라우드의 특정 부분을 사용자 지정할 수 있습니다.

2. parameters _defaults 의 YAML 환경 파일에서 NeutronBridgeMappings 를 사용하여 외부 네트워크에 액세스하는 데 사용할 OVS 브리지를 지정합니다.

   예제

   parameter_defaults:
     NeutronBridgeMappings: 'physnet1:br-net1,physnet2:br-net2'

3. 컨트롤러 및 컴퓨팅 노드의 사용자 지정 NIC 구성 템플릿에서 연결된 인터페이스를 사용하여 브리지를 구성합니다.

   예제

   ...
                 - type: ovs_bridge
                   name: br-net1
                   mtu: 1500
                   use_dhcp: false
                   members:
                   - type: interface
                     name: eth0
                     mtu: 1500
                     use_dhcp: false
                     primary: true
                 - type: ovs_bridge
                   name: br-net2
                   mtu: 1500
                   use_dhcp: false
                   members:
                   - type: interface
                     name: eth1
                     mtu: 1500
                     use_dhcp: false
                     primary: true
   ...

4. openstack overcloud deploy 명령을 실행하고 수정된 이 사용자 지정 NIC 템플릿과 새 환경 파일을 포함하여 템플릿과 환경 파일을 포함합니다.

   중요

   후속 환경 파일에 정의된 매개 변수와 리소스가 우선하기 때문에 환경 파일의 순서가 중요합니다.

   예제

   $ openstack overcloud deploy --templates \
   -e [your-environment-files] \
   -e /usr/share/openstack-tripleo-heat-templates/environments/services/my-neutron-environment.yaml

검증

1. 외부 네트워크(public1)를 플랫 네트워크로만들어 구성된 물리적 네트워크(physnet1)와 연결합니다.

   다른 사용자가 외부 네트워크에 직접 연결하는 VM 인스턴스를 생성하도록 공유 네트워크( --share사용)로 구성합니다.

   예제

   # openstack network create --share --provider-network-type flat --provider-physical-network physnet1 --external public01

2. openstack subnet create 명령을 사용하여 서브넷(public_subnet)을 만듭니다.

   예제

   # openstack subnet create --no-dhcp --allocation-pool start=192.168.100.20,end=192.168.100.100 --gateway 192.168.100.1 --network public01 public_subnet

3. VM 인스턴스를 만들고 새로 생성된 외부 네트워크에 직접 연결합니다.

   예제

   $ openstack server create --image rhel --flavor my_flavor --network public01 my_instance

1. 패킷은 인스턴스의 eth0 인터페이스를 종료하고 Linux 브리지 qbr-xx 에 도착합니다.
2. 브리지 qbr-xx 는 veth 쌍 qvb -xx <-> qvo-xxx를 사용하여 br- int 에 연결됩니다. 이는 브리지가 보안 그룹에서 정의한 인바운드/아웃바운드 방화벽 규칙을 적용하는 데 사용되기 때문입니다.
3. qvb-xx 인터페이스는 qbr-xx linux 브리지에 연결되고 qvoxx 는 br-int Open vSwitch(OVS) 브리지에 연결됩니다.

1. 들어오는 트래픽은 물리적 노드의 eth1 에 도착합니다.
2. 패킷이 br-ex 브리지에 전달됩니다.
3. 패킷은 patch-peer phy -br-ex <--> int-br-ex를 통해 br-int 로 이동합니다.

br-int에서 트래픽 흐름 관찰

1. 패킷이 int-br-ex에 도착하면 br-int 브리지 내의 OVS 흐름 규칙이 패킷을 수정하여 내부 VLAN 태그를 추가합니다 . actions=mod_vlan_vid:5 에 대한 항목을 참조하십시오.

    # ovs-ofctl dump-flows br-int
   NXST_FLOW reply (xid=0x4):
    cookie=0x0, duration=5351.536s, table=0, n_packets=12118, n_bytes=510456, idle_age=0, priority=1 actions=NORMAL
    cookie=0x0, duration=4537.553s, table=0, n_packets=3489, n_bytes=321696, idle_age=0, priority=3,in_port=15,vlan_tci=0x0000 actions=mod_vlan_vid:5,NORMAL
    cookie=0x0, duration=5350.365s, table=0, n_packets=628, n_bytes=57892, idle_age=4538, priority=2,in_port=15 actions=drop
    cookie=0x0, duration=5351.432s, table=23, n_packets=0, n_bytes=0, idle_age=5351, priority=0 actions=drop

2. 두 번째 규칙은 VLAN 태그(vlan_tci=0x0000)가 없는 int-br-ex(in_port=15)에 도착하는 패킷을 관리합니다. 이 규칙은 패킷(actions=mod_vlan_vid:5,NORMAL)에 VLAN 태그 5를 추가하고 qvoxxx 로 전달합니다.
3. qvo XXX는 VLAN 태그를 제거한 후 패킷을 수락하고 qvbxx 로 전달합니다.
4. 그런 다음 패킷이 인스턴스에 도달합니다.

절차

1. bridge_mappings 를 검토합니다.

   사용하는 물리적 네트워크 이름이 bridge_mapping 구성의 내용과 일치하는지 확인합니다.

   예제

   이 예에서 물리적 네트워크 이름은 physnet1 입니다.

   $ openstack network show provider-flat

   샘플 출력

   ...
   | provider:physical_network | physnet1
   ...

   예제

   이 예에서 bridge_mapping 구성의 콘텐츠도 physnet1 입니다.

   $ grep bridge_mapping /etc/neutron/plugins/ml2/openvswitch_agent.ini

   샘플 출력

   bridge_mappings = physnet1:br-ex

2. 네트워크 구성을 검토합니다.

   네트워크가 외부로 생성되고 flat 유형을 사용하는지 확인합니다.

   예제

   이 예에서는 provider-flat 네트워크에 대한 세부 정보를 쿼리합니다.

   $ openstack network show provider-flat

   샘플 출력

   ...
   | provider:network_type     | flat                                 |
   | router:external           | True                                 |
   ...

3. patch-peer를 검토합니다.

   br-int 및 br-ex 가 patch-peer int-br-ex <--> phy-br-ex 를 사용하여 연결되어 있는지 확인합니다.

   $ ovs-vsctl show

   샘플 출력

     Bridge br-int
         fail_mode: secure
        Port int-br-ex
             Interface int-br-ex
                 type: patch
                 options: {peer=phy-br-ex}

   샘플 출력

   br-ex 에서 patch-peer의 구성:

       Bridge br-ex
           Port phy-br-ex
               Interface phy-br-ex
                   type: patch
                   options: {peer=int-br-ex}
           Port br-ex
               Interface br-ex
                   type: internal

   이 연결은 bridge_mapping이 /etc/neutron/plugins/ml2/ openvswitch_ agent.ini에 올바르게 구성된 경우 neutron- openvswitch-agent 서비스를 다시 시작할 때 생성됩니다.

   서비스를 다시 시작한 후 연결이 생성되지 않은 경우 bridge_mapping 설정을 다시 확인합니다.

4. 네트워크 흐름을 검토합니다.

   ovs-ofctl dump-flows br-ex 및 ovs-ofctl dump-flows br-int s br-ofctl dump-flows br-int를 실행하고, 흐름이 나가는 패킷의 내부 VLAN ID를 제거하고 들어오는 패킷의 VLAN ID를 추가하는지 검토합니다. 이 흐름은 먼저 특정 컴퓨팅 노드에서 이 네트워크에 인스턴스를 생성할 때 추가됩니다.

   1. 인스턴스를 생성한 후에 이 흐름을 생성하지 않으면 네트워크가 flat, external, physical _network 이름이 올바른지 확인합니다. 또한 bridge_mapping 설정을 검토합니다.

   2. 마지막으로 ifcfg-br-ex 및 ifcfg-ethx 구성을 검토합니다. ethX 가 br-ex 내의 포트로 추가되고 ifcfg- br-ex 및 ifcfg- ethx 에 ip a 의 출력에 UP 플래그가 있는지 확인합니다.

      샘플 출력

      다음 출력은 eth1 이 br-ex 의 포트임을 보여줍니다.

          Bridge br-ex
              Port phy-br-ex
                  Interface phy-br-ex
                      type: patch
                      options: {peer=int-br-ex}
              Port "eth1"
                  Interface "eth1"

      예제

      다음 예제에서는 eth1 이 OVS 포트로 구성되어 있고 커널이 인터페이스에서 모든 패킷을 전송하고 OVS 브리지 br-ex 로 전송한다는 것을 보여줍니다. 이는 마스터 ovs-system 항목에서 확인할 수 있습니다.

      $ ip a
      5: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP qlen 1000

절차

1. Undercloud 호스트에서 stack 사용자로 로그인한 사용자 지정 YAML 환경 파일을 만듭니다.

   예제

   $ vi /home/stack/templates/my-modules-environment.yaml

   작은 정보

   Red Hat OpenStack Platform Orchestration 서비스(heat)는 templates 라는 플랜 세트를 사용하여 환경을 설치하고 구성합니다. 오케스트레이션 템플릿에 대한 사용자 지정을 제공하는 특수 유형의 템플릿 파일인 사용자 지정 환경 파일을 사용하여 오버클라우드의 특정 부분을 사용자 지정할 수 있습니다.

2. parameter_defaults 의 YAML 환경 파일에서 NeutronTypeDrivers 를 사용하여 네트워크 유형 드라이버를 지정합니다.

   예제

   parameter_defaults:
     NeutronTypeDrivers: vxlan,flat,vlan

3. 사용 중인 물리적 네트워크 및 VLAN 범위를 반영하도록 NeutronNetworkVLANRanges 설정을 구성합니다.

   예제

   parameter_defaults:
     NeutronTypeDrivers: 'vxlan,flat,vlan'
     NeutronNetworkVLANRanges: 'physnet1:171:172'

4. 외부 네트워크 브리지(br-ex)를 만들고 포트(eth1)를연결합니다.

   이 예제에서는 br-ex 를 사용하도록 eth1 을 구성합니다.

   예제

   parameter_defaults:
     NeutronTypeDrivers: 'vxlan,flat,vlan'
     NeutronNetworkVLANRanges: 'physnet1:171:172'
     NeutronBridgeMappings: 'datacentre:br-ex,tenant:br-int'

5. openstack overcloud deploy 명령을 실행하고 이 새 환경 파일을 포함하여 코어 템플릿과 환경 파일을 포함합니다.

   중요

   후속 환경 파일에 정의된 매개 변수와 리소스가 우선하기 때문에 환경 파일의 순서가 중요합니다.

   예제

   $ openstack overcloud deploy --templates \
   -e [your-environment-files] \
   -e /usr/share/openstack-tripleo-heat-templates/environments/services/my-neutron-environment.yaml

검증

1. 외부 네트워크를 vlan 유형으로 만들어 구성된 physical_network 와 연결합니다.

   다음 예제 명령을 실행하여 두 개의 네트워크를 생성합니다. 하나는 VLAN 171용이고 다른 하나는 VLAN 172에 사용됩니다.

   예제

   $ openstack network create \
   			--provider-network-type vlan \
   			--provider-physical-network physnet1 \
   			--provider-segment 171 \
   			provider-vlan171
   
   $ openstack network create \
   			--provider-network-type vlan \
   			--provider-physical-network physnet1 \
   			--provider-segment 172 \
   			provider-vlan172

2. 여러 서브넷을 만들고 외부 네트워크를 사용하도록 구성합니다.

   openstack subnet create 또는 대시보드를 사용하여 이러한 서브넷을 만들 수 있습니다. 네트워크 관리자가 수신한 외부 서브넷 세부 정보가 각 VLAN에 올바르게 연결되어 있는지 확인합니다.

   이 예에서 VLAN 171은 서브넷 10.65.217.0/24 를 사용하고 VLAN 172에서는 10.65.218.0/24 를 사용합니다.

   예제

   $ openstack subnet create \
   			--network provider-171 \
   			--subnet-range 10.65.217.0/24 \
   			--dhcp \
   			--gateway 10.65.217.254 \
   			subnet-provider-171
   
   $ openstack subnet create \
   			--network provider-172 \
   			--subnet-range 10.65.218.0/24 \
   			--dhcp \
   			--gateway 10.65.218.254 \
   			subnet-provider-172

1. 인스턴스의 eth0 인터페이스를 나가는 패킷은 인스턴스에 연결된 Linux 브리지 qbr-xx 에 도착합니다.
2. qbr-xx 는 veth 쌍 qvbxx <✓ qvoxxx 를 사용하여 br-int 에 연결됩니다.
3. qvbxx 는 Linux 브리지 qbr-xx 에 연결되어 있으며 qvoxx 는 Open vSwitch 브리지 br-int 에 연결됩니다.

절차

1. bridge_mapping 구성에 사용된 물리적 네트워크 이름이 물리적 네트워크 이름과 일치하는지 확인합니다.

   예제

   $ openstack network show provider-vlan171

   샘플 출력

   ...
   | provider:physical_network | physnet1
   ...

   예제

   $ grep bridge_mapping /etc/neutron/plugins/ml2/openvswitch_agent.ini

   샘플 출력

   이 샘플 출력에서 물리적 네트워크 이름 physnet1 은 bridge_mapping 구성에 사용되는 이름과 일치합니다.

   bridge_mappings = physnet1:br-ex

2. 네트워크가 외부로 생성되었고 vlan 을 입력하고 올바른 segmentation_id 값을 사용하는지 확인합니다.

   예제

   $ openstack network show provider-vlan171

   샘플 출력

   ...
   | provider:network_type     | vlan                                 |
   | provider:physical_network | physnet1                             |
   | provider:segmentation_id  | 171                                  |
   ...

3. patch-peer를 검토합니다.

   br-int 및 br-ex 가 patch-peer int-br-ex <--> phy-br-ex 를 사용하여 연결되어 있는지 확인합니다.

   $ ovs-vsctl show

   neutron-openvswitch-agent 를 다시 시작하는 동안 bridge_mapping 이 /etc/neutron/plugins/ml2/openvswitch_agent.ini 에 올바르게 구성되어 있는 경우 이 연결이 생성됩니다.

   서비스를 다시 시작한 후에도 이 설정이 생성되지 않은 경우 bridge_mapping 설정을 다시 확인합니다.

4. 네트워크 흐름을 검토합니다.

   1. 발신 패킷의 흐름을 검토하려면 ovs-ofctl dump-flows br-ex 및 ovs-ofctl dump-flows br-int s br-ofctl dump-flows br-int를 실행하고, 흐름이 내부 VLAN ID(segmentation_id)에 매핑되는지 확인합니다.

   2. 들어오는 패킷의 경우 외부 VLAN ID를 내부 VLAN ID에 매핑합니다.

      이 흐름은 이 네트워크에 인스턴스를 처음 생성할 때 neutron OVS 에이전트에서 추가합니다.

   3. 인스턴스를 생성한 후 이 흐름이 생성되지 않은 경우 네트워크를 vlan 으로 만들고, external 이고 physical_network 이름이 올바른지 확인합니다. 또한 bridge_mapping 설정을 다시 확인합니다.

   4. 마지막으로 ifcfg-br-ex 및 ifcfg-ethx 구성을 다시 확인합니다.

      br-ex 에 ethX 포트가 포함되어 있고 ifcfg-br-ex 및 ifcfg-ethx 둘 다 ip a 명령의 출력에 UP 플래그가 있는지 확인합니다.

      예제

      $ ovs-vsctl show

      이 샘플 출력에서 eth1 은 br-ex 의 포트입니다.

          Bridge br-ex
              Port phy-br-ex
                  Interface phy-br-ex
                      type: patch
                      options: {peer=int-br-ex}
              Port "eth1"
                  Interface "eth1"

      예제

      $ ip a

      샘플 출력

      이 샘플 출력에서 eth1 이 포트로 추가되었으며 커널이 인터페이스에서 OVS 브리지 br-ex 로 모든 패킷을 이동하도록 구성되어 있습니다. 이는 마스터 ovs-system 항목에 의해 입증됩니다.

      5: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP qlen 1000

절차

1. Undercloud 호스트에서 stack 사용자로 로그인한 사용자 지정 YAML 환경 파일을 만듭니다.

   예제

   $ vi /home/stack/templates/my-ovs-environment.yaml

   작은 정보

   오케스트레이션 서비스(heat)는 templates라는 플랜 집합을 사용하여 환경을 설치하고 구성합니다. heat 템플릿에 대한 사용자 지정을 제공하는 특수 유형의 템플릿 파일인 사용자 지정 환경 파일을 사용하여 오버클라우드의 특정 부분을 사용자 지정할 수 있습니다.

2. parameter_defaults 의 YAML 환경 파일에서 NeutronEnableIgmpSnooping 을 true로 설정합니다.

   parameter_defaults:
       NeutronEnableIgmpSnooping: true
       ...

   중요

   콜론(:)과 true 사이에 공백 문자를 추가해야 합니다.

3. openstack overcloud deploy 명령을 실행하고 코어 heat 템플릿, 환경 파일 및 이 새 사용자 지정 환경 파일을 포함합니다.

   중요

   후속 환경 파일에 정의된 매개 변수와 리소스가 우선하므로 환경 파일의 순서가 중요합니다.

   예제

   $ openstack overcloud deploy --templates \
   -e [your-environment-files] \
   -e /usr/share/openstack-tripleo-heat-templates/environments/services/my-ovs-environment.yaml

절차

1. 적절한 VM 인스턴스에 대한 멀티캐스트 트래픽을 허용하도록 보안을 구성합니다. 예를 들어 IGMP 쿼리에서 IGMP 트래픽이 VM 인스턴스를 입력하고 종료하는 데 사용할 수 있는 보안 그룹 규칙과 멀티캐스트 트래픽을 허용하는 세 번째 규칙을 만듭니다.

   예제

   보안 그룹 mySG 를 사용하면 IGMP 트래픽이 VM 인스턴스를 입력하고 종료할 수 있습니다.

    openstack security group rule create --protocol igmp --ingress mySG
   
    openstack security group rule create --protocol igmp --egress mySG

   또 다른 규칙을 사용하면 멀티캐스트 트래픽이 VM 인스턴스에 도달할 수 있습니다.

   openstack security group rule create  --protocol udp mySG

   보안 그룹 규칙을 설정하는 대신 일부 운영자는 네트워크에서 포트 보안을 선택적으로 비활성화하도록 선택합니다. 포트 보안을 비활성화하려면 관련 보안 위험을 고려하고 계획하십시오.

2. heat 매개변수를 설정합니다. NeutronEnableIgmpSnooping: True 언더클라우드 노드의 환경 파일에 있습니다. 예를 들어 다음 행을 ovn-extras.yaml에 추가합니다.

   예제

   parameter_defaults:
           NeutronEnableIgmpSnooping: True

3. 해당 환경과 관련된 기타 환경 파일과 함께 openstack overcloud deploy 명령에 환경 파일을 포함하고 오버클라우드를 배포합니다.

   $ openstack overcloud deploy \
   --templates \
   …
   -e <other_overcloud_environment_files> \
   
   -e ovn-extras.yaml \
   …

   <other_overcloud_environment_files> 를 기존 배포에 포함된 환경 파일 목록으로 바꿉니다.

검증

1. 멀티 캐스트 스누핑이 활성화되었는지 확인합니다. northbound 데이터베이스 Logical_Switch 테이블을 나열합니다.

   $ ovn-nbctl list Logical_Switch

   샘플 출력

   _uuid         : d6a2fbcd-aaa4-4b9e-8274-184238d66a15
   other_config  : {mcast_flood_unregistered="false", mcast_snoop="true"}
   ...

   Networking 서비스(neutron) igmp_snooping_enable 구성은 OVN Northbound 데이터베이스의 Logical_Switch 테이블의 other_config 열에 설정된 mcast_snoop 옵션으로 변환됩니다. mcast_flood_unregistered는 항상 "false"입니다.

2. IGMP 그룹을 표시합니다.

   $ ovn-sbctl list IGMP_group

   샘플 출력

   _uuid    : 2d6cae4c-bd82-4b31-9c63-2d17cbeadc4e
   address  : "225.0.0.120"
   chassis  : 34e25681-f73f-43ac-a3a4-7da2a710ecd3
   datapath : eaf0f5cc-a2c8-4c30-8def-2bc1ec9dcabc
   ports    : [5eaf9dd5-eae5-4749-ac60-4c1451901c56, 8a69efc5-38c5-48fb-bbab-30f2bf9b8d45]
   ...

절차

1. 대시보드에서 Admin > Networks > Create Network > Project 를 선택합니다.
2. Project(프로젝트) 드롭다운 목록에서 새 네트워크를 호스팅할 프로젝트를 선택합니다.

3. Provider Network Type 의 옵션을 검토합니다.

   • local - 트래픽은 로컬 계산 호스트에 유지되며 외부 네트워크와 효과적으로 격리됩니다.
   • 플랫 - 트래픽은 단일 네트워크에 유지되며 호스트와 공유할 수도 있습니다. VLAN 태그 지정 또는 기타 네트워크 분리가 수행되지 않습니다.
   • VLAN - 실제 네트워크에 있는 VLAN에 해당하는 VLAN ID를 사용하여 네트워크를 만듭니다. 이 옵션을 사용하면 인스턴스가 동일한 계층 2 VLAN에서 시스템과 통신할 수 있습니다.
   • GRE - 여러 노드에 걸쳐 있는 네트워크 오버레이를 사용하여 인스턴스 간 개별 통신을 수행합니다. 오버레이를 송신하는 트래픽의 경로가 지정되어야 합니다.
   • VXLAN - GRE와 유사하며 네트워크 오버레이를 사용하여 인스턴스 간 개인 통신에 여러 노드를 확장합니다. 오버레이를 송신하는 트래픽의 경로가 지정되어야 합니다.

4. Create Network(네트워크 만들기)를 클릭합니다.

   Project Network Topology(프로젝트 네트워크 토폴로지)를 검토하여 네트워크가 성공적으로 생성되었는지 확인합니다.

절차

1. 다음 명령을 입력하여 풀에서 유동 IP 주소를 할당합니다. 이 예에서 네트워크의 이름은 public 입니다.

   예제

   $ openstack floating ip create public

   샘플 출력

   다음 예에서 새로 할당된 유동 IP는 192.0.2.200 입니다. 인스턴스에 할당할 수 있습니다.

   +---------------------+--------------------------------------------------+
   | Field               | Value                                            |
   +---------------------+--------------------------------------------------+
   | fixed_ip_address    | None                                             |
   | floating_ip_address | 192.0.2.200                                      |
   | floating_network_id | f0dcc603-f693-4258-a940-0a31fd4b80d9             |
   | id                  | 6352284c-c5df-4792-b168-e6f6348e2620             |
   | port_id             | None                                             |
   | router_id           | None                                             |
   | status              | ACTIVE                                           |
   +---------------------+--------------------------------------------------+

2. 다음 명령을 입력하여 인스턴스를 찾습니다.

   $ openstack server list

   샘플 출력

   +-------------+-------------+--------+-------------+-------+-------------+
   | ID          | Name        | Status | Networks    | Image | Flavor      |
   +-------------+-------------+--------+-------------+-------+-------------+
   | aef3ca09-88 | prod-serv1  | ACTIVE | public=198. | rhel8 | review-     |
   | 7d-4d20-872 |             |        | 51.100.56   |       | ephemeral   |
   | d-1d1b49081 |             |        |             |       |             |
   | 958         |             |        |             |       |             |
   |             |             |        |             |       |             |
   +-------------+-------------+--------+-------------+-------+-------------+

3. 인스턴스 이름 또는 ID를 유동 IP에 연결합니다.

   예제

   $ openstack server add floating ip prod-serv1 192.0.2.200

절차

1. 텍스트 편집기에서 /etc/sysconfig/network-scripts/ifcfg-eth0 을 열고 사이트의 네트워크에 적합한 값으로 다음 매개변수를 업데이트합니다.

   • IPADDR
   • 넷마스크 게이트웨이

   • DNS1 (이름 서버)

     예를 들면 다음과 같습니다.

     # vi /etc/sysconfig/network-scripts/ifcfg-eth0
     DEVICE=eth0
     TYPE=OVSPort
     DEVICETYPE=ovs
     OVS_BRIDGE=br-ex
     ONBOOT=yes

2. 텍스트 편집기에서 /etc/sysconfig/network-scripts/ifcfg-br-ex 를 열고 이전에 eth0에 할당된 IP 주소 값으로 가상 브리지 매개변수를 업데이트합니다.

   # vi /etc/sysconfig/network-scripts/ifcfg-br-ex
   DEVICE=br-ex
   DEVICETYPE=ovs
   TYPE=OVSBridge
   BOOTPROTO=static
   IPADDR=192.168.120.10
   NETMASK=255.255.255.0
   GATEWAY=192.168.120.1
   DNS1=192.168.120.1
   ONBOOT=yes

   이제 인스턴스에 유동 IP 주소를 할당하고 실제 네트워크에서 사용할 수 있도록 설정할 수 있습니다.

1. 대시보드에서 프로젝트 > 네트워크 > 네트워크 토폴로지 를 선택합니다.
2. 관리할 라우터를 찾아 마우스 커서를 올려 놓은 다음 Add Interface(인터페이스 추가 )를 클릭합니다.

3. 라우터에 연결할 서브넷을 지정합니다.

   IP 주소도 지정할 수 있습니다. 이 인터페이스에 대한 ping은 트래픽이 예상대로 라우팅되고 있음을 나타내므로 주소가 테스트 및 문제 해결에 유용합니다.

4. Add interface (인터페이스 추가)를 클릭합니다.

   네트워크 토폴로지 다이어그램은 라우터와 서브넷 간의 새 인터페이스 연결을 반영하도록 자동으로 업데이트됩니다.

1. 대시보드에서 프로젝트 > 네트워크 > 라우터 를 선택합니다.
2. 삭제할 인터페이스를 호스팅하는 라우터 이름을 클릭합니다.
3. 인터페이스 유형(내부 인터페이스)을 선택하고 Delete Interfaces(인터페이스 삭제 )를 클릭합니다.

1. 인터넷 - 일반적인 첫 번째 단계는 www.example.com과 같은 인터넷 위치에 ping 테스트를 보내는 것입니다.

   • 성공: 이 테스트는 시스템과 인터넷 사이의 모든 다양한 네트워크 지점이 올바르게 작동하고 있음을 나타냅니다. 여기에는 가상 및 물리적 네트워크 인프라가 포함됩니다.
   • 실패: 오래된 인터넷 위치에 대한 ping 테스트가 실패할 수 있는 여러 가지 방법이 있습니다. 네트워크의 다른 시스템이 인터넷을 ping할 수 있으면 인터넷 연결이 작동 중임을 증명하고 로컬 시스템 구성 내에서 문제가 발생할 수 있습니다.

2. 물리적 라우터 - 네트워크 관리자가 트래픽을 외부 대상으로 전달하도록 지정하는 라우터 인터페이스입니다.

   • 성공: 물리적 라우터로 Ping 테스트를 수행하면 로컬 네트워크 및 기본 스위치가 작동하는지 확인할 수 있습니다. 이러한 패킷은 라우터를 통과하지 않으므로 기본 게이트웨이에 라우팅 문제가 있는지를 증명하지 않습니다.
   • 실패: 이는 VM1과 기본 게이트웨이 사이에 문제가 있음을 나타냅니다. 라우터/하위가 꺼져 있거나 잘못된 기본 게이트웨이를 사용 중일 수 있습니다. 사용자가 알고 있는 다른 서버에서 구성을 올바르게 작동하고 있는 구성과 비교합니다. 로컬 네트워크에서 다른 서버를 ping합니다.

3. Neutron 라우터 - Red Hat OpenStack Platform이 가상 머신의 트래픽을 보내는 데 사용하는 가상 SDN(소프트웨어 정의 네트워킹) 라우터입니다.

   • 성공: 방화벽은 ICMP 트래픽을 허용하며 네트워킹 노드는 온라인 상태입니다.
   • 실패: 인스턴스의 보안 그룹에 ICMP 트래픽이 허용되는지 확인합니다. Networking 노드가 온라인 상태인지 확인하고 모든 필수 서비스가 실행 중인지 확인하고 L3 에이전트 로그(/var/log/neutron/l3-agent.log)를 검토합니다.

4. 물리적 스위치 - 물리적 스위치는 동일한 물리적 네트워크에 있는 노드 간 트래픽을 관리합니다.

   • 성공: VM에서 물리적 스위치로 전송되는 트래픽은 이 세그먼트가 올바르게 작동함을 나타내는 가상 네트워크 인프라를 통과해야 합니다.
   • 실패: 물리적 스위치 포트가 필요한 VLAN을 트렁크하도록 구성되어 있는지 확인합니다.

5. VM2 - 동일한 컴퓨팅 노드에서 동일한 서브넷에서 VM을 ping합니다.

   • 성공: VM1의 NIC 드라이버 및 기본 IP 구성이 작동합니다.
   • 실패: VM1의 네트워크 구성을 확인합니다. 또는 VM2의 방화벽은 단순히 ping 트래픽을 차단하는 것일 수 있습니다. 또한 가상 전환 구성을 확인하고 Open vSwitch 로그 파일을 검토합니다.

절차

1. r1 라우터에 연결된 모든 포트를 보려면 다음 명령을 실행합니다.

   #  openstack port list --router r1

   샘플 출력

   +--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+
   | id                                   | name | mac_address       | fixed_ips                                                                            |
   +--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+
   | b58d26f0-cc03-43c1-ab23-ccdb1018252a |      | fa:16:3e:94:a7:df | {"subnet_id": "a592fdba-babd-48e0-96e8-2dd9117614d3", "ip_address": "192.168.200.1"} |
   | c45e998d-98a1-4b23-bb41-5d24797a12a4 |      | fa:16:3e:ee:6a:f7 | {"subnet_id": "43f8f625-c773-4f18-a691-fd4ebfb3be54", "ip_address": "172.24.4.225"}  |
   +--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+

2. 각 포트의 세부 정보를 보려면 다음 명령을 실행합니다. 보려는 포트의 포트 ID를 포함합니다. 결과적으로 다음 예에 ACTIVE 상태가 있는 것으로 표시된 포트 상태가 포함됩니다.

   # openstack port show b58d26f0-cc03-43c1-ab23-ccdb1018252a

   샘플 출력

   +-----------------------+--------------------------------------------------------------------------------------+
   | Field                 | Value                                                                                |
   +-----------------------+--------------------------------------------------------------------------------------+
   | admin_state_up        | True                                                                                 |
   | allowed_address_pairs |                                                                                      |
   | binding:host_id       | node.example.com                                                      |
   | binding:profile       | {}                                                                                   |
   | binding:vif_details   | {"port_filter": true, "ovs_hybrid_plug": true}                                       |
   | binding:vif_type      | ovs                                                                                  |
   | binding:vnic_type     | normal                                                                               |
   | device_id             | 49c6ebdc-0e62-49ad-a9ca-58cea464472f                                                 |
   | device_owner          | network:router_interface                                                             |
   | extra_dhcp_opts       |                                                                                      |
   | fixed_ips             | {"subnet_id": "a592fdba-babd-48e0-96e8-2dd9117614d3", "ip_address": "192.168.200.1"} |
   | id                    | b58d26f0-cc03-43c1-ab23-ccdb1018252a                                                 |
   | mac_address           | fa:16:3e:94:a7:df                                                                    |
   | name                  |                                                                                      |
   | network_id            | 63c24160-47ac-4140-903d-8f9a670b0ca4                                                 |
   | security_groups       |                                                                                      |
   | status                | ACTIVE                                                                               |
   | tenant_id             | d588d1112e0f496fb6cac22f9be45d49                                                     |
   +-----------------------+--------------------------------------------------------------------------------------+

3. 각 포트에 대해 2단계를 수행하여 상태를 확인합니다.

절차

1. ping <gateway-IP-address> 를 사용하여 게이트웨이를 ping합니다.

   다음 명령을 사용하여 네트워크를 생성하는 이 예제를 고려하십시오.

   # openstack network create --provider-network-type vlan --provider-physical-network phy-eno1 --provider-segment 120 provider
   # openstack subnet create --no-dhcp --allocation-pool start=192.168.120.1,end=192.168.120.153 --gateway 192.168.120.254 --network  provider public_subnet

   이 예에서 게이트웨이 IP 주소는 192.168.120.254 입니다.

   $ ping 192.168.120.254

2. ping이 실패하면 다음을 수행합니다.

   1. 연결된 VLAN의 네트워크 흐름이 있는지 확인합니다.

      VLAN ID가 설정되지 않았을 수 있습니다. 이 예에서 OpenStack Networking은 VLAN 120을 프로바이더 네트워크로 트렁크하도록 구성되어 있습니다. (1단계 예제의 --provider:segmentation_id=120 참조)

   2. ovs-ofctl dump-flows <bridge-name> 명령을 사용하여 브리지 인터페이스에서 VLAN 흐름을 확인합니다.

      이 예에서는 브리지의 이름은 br-ex:

      # ovs-ofctl dump-flows br-ex
      
       NXST_FLOW reply (xid=0x4):
        cookie=0x0, duration=987.521s, table=0, n_packets=67897, n_bytes=14065247, idle_age=0, priority=1 actions=NORMAL
        cookie=0x0, duration=986.979s, table=0, n_packets=8, n_bytes=648, idle_age=977, priority=2,in_port=12 actions=drop

절차

1. openstack network agent list 명령을 사용하여 RHOSP Networking 서비스 에이전트가 올바른 호스트 이름에 등록되어 있는지 확인합니다.

   (overcloud)[stack@undercloud~]$ openstack network agent list
   +--------------------------------------+--------------------+-----------------------+-------+----------------+
   | id                                   | agent_type         | host                  | alive | admin_state_up |
   +--------------------------------------+--------------------+-----------------------+-------+----------------+
   | a08397a8-6600-437d-9013-b2c5b3730c0c | Metadata agent     | rhelosp.example.com   | :-)   | True           |
   | a5153cd2-5881-4fc8-b0ad-be0c97734e6a | L3 agent           | rhelosp.example.com   | :-)   | True           |
   | b54f0be7-c555-43da-ad19-5593a075ddf0 | DHCP agent         | rhelosp.example.com   | :-)   | True           |
   | d2be3cb0-4010-4458-b459-c5eb0d4d354b | Open vSwitch agent | rhelosp.example.com   | :-)   | True           |
   +--------------------------------------+--------------------+-----------------------+-------+----------------+

2. /var/log/containers/neutron/openvswitch-agent.log 를 검토합니다. 생성 프로세스에서 ovs-ofctl 명령을 사용하여 VLAN 트렁핑을 구성했는지 확인합니다.
3. /etc/neutron/l3 _agent.ini 파일에서 external_network_ bridge 를 확인합니다. external_network_bridge 매개변수에 하드 코딩된 값이 있는 경우 L3-agent와 함께 프로바이더 네트워크를 사용할 수 없으며 필요한 흐름을 생성할 수 없습니다. external_network_bridge 값은 'external_network_bridge = "" ' 형식이어야 합니다.
4. /etc/neutron/plugin.ini 파일에서 network_vlan_ranges 값을 확인합니다. 공급자 네트워크의 경우 숫자 VLAN ID를 지정하지 마십시오. VLAN 분리 프로젝트 네트워크를 사용하는 경우에만 ID를 지정합니다.
5. OVS 에이전트 구성 파일 브리지 매핑 을 확인하여 phy-eno1에 매핑되고 eno1 에 올바르게 연결되어 있는지 확인합니다.

절차

1. Red Hat OpenStack Platform 인증 정보를 사용하여 오버클라우드에 로그인합니다.
2. openstack server list 명령을 실행하여 VM 인스턴스의 이름을 가져옵니다.

3. openstack server show 명령을 실행하여 인스턴스가 실행 중인 컴퓨팅 노드를 확인합니다.

   예제

   $ openstack server show my_instance -c OS-EXT-SRV-ATTR:host \
   -c addresses

   샘플 출력

   +----------------------+-------------------------------------------------+
   | Field                | Value                                           |
   +----------------------+-------------------------------------------------+
   | OS-EXT-SRV-ATTR:host | compute0.overcloud.example.com                  |
   | addresses            | finance-network1=192.0.2.2; provider-           |
   |                      | storage=198.51.100.13                           |
   +----------------------+-------------------------------------------------+

4. 컴퓨팅 노드 호스트에 로그인합니다.

   예제

   $ ssh heat-admin@compute0.example.com

5. ip netns list 명령을 실행하여 OVN 메타데이터 네임스페이스를 확인합니다.

   샘플 출력

   ovnmeta-07384836-6ab1-4539-b23a-c581cf072011 (id: 1)
   ovnmeta-df9c28ea-c93a-4a60-b913-1e611d6f15aa (id: 0)

6. metadata 네임스페이스를 사용하면 ip netns exec 명령을 실행하여 연결된 네트워크를 ping합니다.

   예제

   $ sudo ip netns exec ovnmeta-df9c28ea-c93a-4a60-b913-1e611d6f15aa \
   ping 192.0.2.2

   샘플 출력

   PING 192.0.2.2 (192.0.2.2) 56(84) bytes of data.
   64 bytes from 192.0.2.2: icmp_seq=1 ttl=64 time=0.470 ms
   64 bytes from 192.0.2.2: icmp_seq=2 ttl=64 time=0.483 ms
   64 bytes from 192.0.2.2: icmp_seq=3 ttl=64 time=0.183 ms
   64 bytes from 192.0.2.2: icmp_seq=4 ttl=64 time=0.296 ms
   64 bytes from 192.0.2.2: icmp_seq=5 ttl=64 time=0.307 ms
   ^C
   --- 192.0.2.2 ping statistics ---
   5 packets transmitted, 5 received, 0% packet loss, time 122ms
   rtt min/avg/max/mdev = 0.183/0.347/0.483/0.116 ms

절차

1. openstack network list 명령을 사용하여 모든 프로젝트 네트워크를 나열하여 네트워크가 포함된 네트워크 네임스페이스를 결정합니다.

   $ openstack network list

   이 출력에서 web-servers 네트워크(9cb32fe0-d7fb-432c-b116-f483c6497b08 )의 ID입니다. 명령은 네트워크 ID를 네트워크 네임스페이스에 추가하여 다음 단계에서 네임스페이스를 식별할 수 있습니다.

   샘플 출력

   +--------------------------------------+-------------+-------------------------------------------------------+
   | id                                   | name        | subnets                                               |
   +--------------------------------------+-------------+-------------------------------------------------------+
   | 9cb32fe0-d7fb-432c-b116-f483c6497b08 | web-servers | 453d6769-fcde-4796-a205-66ee01680bba 192.168.212.0/24 |
   | a0cc8cdd-575f-4788-a3e3-5df8c6d0dd81 | private     | c1e58160-707f-44a7-bf94-8694f29e74d3 10.0.0.0/24      |
   | baadd774-87e9-4e97-a055-326bb422b29b | private     | 340c58e1-7fe7-4cf2-96a7-96a0a4ff3231 192.168.200.0/24 |
   | 24ba3a36-5645-4f46-be47-f6af2a7d8af2 | public      | 35f3d2cb-6e4b-4527-a932-952a395c4bb3 172.24.4.224/28  |
   +--------------------------------------+-------------+-------------------------------------------------------+

2. ip netns list 명령을 사용하여 모든 네트워크 네임스페이스를 나열합니다.

   # ip netns list

   출력에는 web-servers 네트워크 ID와 일치하는 네임스페이스가 포함됩니다.

   이 출력에서 네임스페이스는 qdhcp -9cb32fe0-d7fb-432c-b116-f483c6497b08 입니다.

   샘플 출력

   qdhcp-9cb32fe0-d7fb-432c-b116-f483c6497b08
   qrouter-31680a1c-9b3e-4906-bd69-cb39ed5faa01
   qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b
   qdhcp-a0cc8cdd-575f-4788-a3e3-5df8c6d0dd81
   qrouter-e9281608-52a6-4576-86a6-92955df46f56

3. 네임스페이스 내에서 명령을 실행하고 문제 해결 명령에 ip netns exec <namespace> 접두사를 지정하여 web-servers 네트워크의 구성을 검사합니다.

   이 예에서는 route -n 명령이 사용됩니다.

   예제

   # ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b route -n

   샘플 출력

   Kernel IP routing table
   Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
   0.0.0.0         172.24.4.225    0.0.0.0         UG    0      0        0 qg-8d128f89-87
   172.24.4.224    0.0.0.0         255.255.255.240 U     0      0        0 qg-8d128f89-87
   192.168.200.0   0.0.0.0         255.255.255.0   U     0      0        0 qr-8efd6357-96

절차

1. tcpdump 명령을 사용하여 ICMP 트래픽을 캡처합니다.

   예제

   # ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b tcpdump -qnntpi any icmp

2. 별도의 명령줄 창에서 외부 네트워크에 대한 ping 테스트를 수행합니다.

   예제

   # ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b ping www.example.com

3. tcpdump 세션을 실행하는 터미널에서 ping 테스트의 자세한 결과를 관찰합니다.

   샘플 출력

   tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
   IP (tos 0xc0, ttl 64, id 55447, offset 0, flags [none], proto ICMP (1), length 88)
       172.24.4.228 > 172.24.4.228: ICMP host 192.168.200.20 unreachable, length 68
   	IP (tos 0x0, ttl 64, id 22976, offset 0, flags [DF], proto UDP (17), length 60)
       172.24.4.228.40278 > 192.168.200.21: [bad udp cksum 0xfa7b -> 0xe235!] UDP, length 32

절차

1. OVN 컨테이너에 액세스하는 데 필요한 권한이 있는 사용자로 컨트롤러 호스트에 로그인합니다.

   예제

   $ ssh heat-admin@controller-0.ctlplane

2. 실행하려는 ovn 명령이 포함된 쉘 스크립트 파일을 생성합니다.

   예제

   vi ~/bin/ovn-alias.sh

3. ovn 명령을 추가하고 스크립트 파일을 저장합니다.

   예제

   이 예제에서는 ovn-sbctl,ovn-nbctl, ovn-trace 명령이 별칭 파일에 추가되었습니다.

   EXTERNAL_ID=\
   $(sudo ovs-vsctl get open . external_ids:ovn-remote | awk -F: '{print $2}')
   export NBDB=tcp:${EXTERNAL_ID}:6641
   export SBDB=tcp:${EXTERNAL_ID}:6642
   
   alias ovn-sbctl="sudo podman exec ovn_controller ovn-sbctl --db=$SBDB"
   alias ovn-nbctl="sudo podman exec ovn_controller ovn-nbctl --db=$NBDB"
   alias ovn-trace="sudo podman exec ovn_controller ovn-trace --db=$SBDB"

4. Compute 호스트에서 이 절차의 단계를 반복합니다.

검증

1. 스크립트 파일을 소싱합니다.

   예제

   # source ovn-alias.sh

2. 명령을 실행하여 스크립트 파일이 제대로 작동하는지 확인합니다.

   예제

   # ovn-nbctl show

   샘플 출력

   switch 26ce22db-1795-41bd-b561-9827cbd81778 (neutron-f8e79863-6c58-43d0-8f7d-8ec4a423e13b) (aka internal_network)
   	port 1913c3ae-8475-4b60-a479-df7bcce8d9c8
       	addresses: ["fa:16:3e:33:c1:fc 192.168.254.76"]
   	port 1aabaee3-b944-4da2-bf0a-573215d3f3d9
       	addresses: ["fa:16:3e:16:cb:ce 192.168.254.74"]
   	port 7e000980-59f9-4a0f-b76a-4fdf4e86f27b
       	type: localport
       	addresses: ["fa:16:3e:c9:30:ed 192.168.254.2"]

절차

1. OVN 컨테이너에 액세스하는 데 필요한 권한이 있는 사용자로 컨트롤러 호스트에 로그인합니다.

   예제

   $ ssh heat-admin@controller-0.ctlplane

2. OVN 데이터베이스 명령의 별칭 파일을 가져옵니다.

   자세한 내용은 6.8절. “OVN 문제 해결 명령에 대한 별칭 생성”의 내용을 참조하십시오.

   예제

   source ~/ovn-alias.sh

3. 논리 흐름 보기:

   $ ovn-sbctl lflow-list

4. 출력을 검사합니다.

   샘플 출력

   Datapath: "sw0" (d7bf4a7b-e915-4502-8f9d-5995d33f5d10)  Pipeline: ingress
     table=0 (ls_in_port_sec_l2  ), priority=100  , match=(eth.src[40]), action=(drop;)
     table=0 (ls_in_port_sec_l2  ), priority=100  , match=(vlan.present), action=(drop;)
     table=0 (ls_in_port_sec_l2  ), priority=50   , match=(inport == "sw0-port1" && eth.src == {00:00:00:00:00:01}), action=(next;)
     table=0 (ls_in_port_sec_l2  ), priority=50   , match=(inport == "sw0-port2" && eth.src == {00:00:00:00:00:02}), action=(next;)
     table=1 (ls_in_port_sec_ip  ), priority=0    , match=(1), action=(next;)
     table=2 (ls_in_port_sec_nd  ), priority=90   , match=(inport == "sw0-port1" && eth.src == 00:00:00:00:00:01 && arp.sha == 00:00:00:00:00:01), action=(next;)
     table=2 (ls_in_port_sec_nd  ), priority=90   , match=(inport == "sw0-port1" && eth.src == 00:00:00:00:00:01 && ip6 && nd && ((nd.sll == 00:00:00:00:00:00 || nd.sll == 00:00:00:00:00:01) || ((nd.tll == 00:00:00:00:00:00 || nd.tll == 00:00:00:00:00:01)))), action=(next;)
     table=2 (ls_in_port_sec_nd  ), priority=90   , match=(inport == "sw0-port2" && eth.src == 00:00:00:00:00:02 && arp.sha == 00:00:00:00:00:02), action=(next;)
     table=2 (ls_in_port_sec_nd  ), priority=90   , match=(inport == "sw0-port2" && eth.src == 00:00:00:00:00:02 && ip6 && nd && ((nd.sll == 00:00:00:00:00:00 || nd.sll == 00:00:00:00:00:02) || ((nd.tll == 00:00:00:00:00:00 || nd.tll == 00:00:00:00:00:02)))), action=(next;)
     table=2 (ls_in_port_sec_nd  ), priority=80   , match=(inport == "sw0-port1" && (arp || nd)), action=(drop;)
     table=2 (ls_in_port_sec_nd  ), priority=80   , match=(inport == "sw0-port2" && (arp || nd)), action=(drop;)
     table=2 (ls_in_port_sec_nd  ), priority=0    , match=(1), action=(next;)
     table=3 (ls_in_pre_acl      ), priority=0, match=(1), action=(next;)
     table=4 (ls_in_pre_lb       ), priority=0    , match=(1), action=(next;)
     table=5 (ls_in_pre_stateful ), priority=100  , match=(reg0[0] == 1), action=(ct_next;)
     table=5 (ls_in_pre_stateful ), priority=0    , match=(1), action=(next;)
     table=6 (ls_in_acl          ), priority=0    , match=(1), action=(next;)
     table=7 (ls_in_qos_mark     ), priority=0    , match=(1), action=(next;)
     table=8 (ls_in_lb           ), priority=0    , match=(1), action=(next;)
     table=9 (ls_in_stateful     ), priority=100  , match=(reg0[1] == 1), action=(ct_commit(ct_label=0/1); next;)
     table=9 (ls_in_stateful     ), priority=100  , match=(reg0[2] == 1), action=(ct_lb;)
     table=9 (ls_in_stateful     ), priority=0    , match=(1), action=(next;)
     table=10(ls_in_arp_rsp      ), priority=0    , match=(1), action=(next;)
     table=11(ls_in_dhcp_options ), priority=0    , match=(1), action=(next;)
     table=12(ls_in_dhcp_response), priority=0    , match=(1), action=(next;)
     table=13(ls_in_l2_lkup      ), priority=100  , match=(eth.mcast), action=(outport = "_MC_flood"; output;)
     table=13(ls_in_l2_lkup      ), priority=50   , match=(eth.dst == 00:00:00:00:00:01), action=(outport = "sw0-port1"; output;)
     table=13(ls_in_l2_lkup      ), priority=50   , match=(eth.dst == 00:00:00:00:00:02), action=(outport = "sw0-port2"; output;)
   Datapath: "sw0" (d7bf4a7b-e915-4502-8f9d-5995d33f5d10)  Pipeline: egress
     table=0 (ls_out_pre_lb      ), priority=0    , match=(1), action=(next;)
     table=1 (ls_out_pre_acl     ), priority=0    , match=(1), action=(next;)
     table=2 (ls_out_pre_stateful), priority=100  , match=(reg0[0] == 1), action=(ct_next;)
     table=2 (ls_out_pre_stateful), priority=0    , match=(1), action=(next;)
     table=3 (ls_out_lb          ), priority=0    , match=(1), action=(next;)
     table=4 (ls_out_acl         ), priority=0    , match=(1), action=(next;)
     table=5 (ls_out_qos_mark    ), priority=0    , match=(1), action=(next;)
     table=6 (ls_out_stateful    ), priority=100  , match=(reg0[1] == 1), action=(ct_commit(ct_label=0/1); next;)
     table=6 (ls_out_stateful    ), priority=100  , match=(reg0[2] == 1), action=(ct_lb;)
     table=6 (ls_out_stateful    ), priority=0    , match=(1), action=(next;)
     table=7 (ls_out_port_sec_ip ), priority=0    , match=(1), action=(next;)
     table=8 (ls_out_port_sec_l2 ), priority=100  , match=(eth.mcast), action=(output;)
     table=8 (ls_out_port_sec_l2 ), priority=50   , match=(outport == "sw0-port1" && eth.dst == {00:00:00:00:00:01}), action=(output;)
     table=8 (ls_out_port_sec_l2 ), priority=50   , match=(outport == "sw0-port2" && eth.dst == {00:00:00:00:00:02}), action=(output;)

   OVN과 OpenFlow의 주요 차이점은 다음과 같습니다.

   • OVN 포트는 단일 스위치의 물리적 포트가 아닌 네트워크에 있는 논리적 엔티티입니다.
   • OVN은 파이프라인의 각 테이블에 해당 번호 외에 이름을 제공합니다. 이름은 파이프라인에서 해당 단계의 목적을 설명합니다.
   • OVN 일치 구문은 복잡한 부울 표현식을 지원합니다.
   • OVN 논리 흐름에서 지원되는 작업은 OpenFlow를 초과하여 확장합니다. OVN 논리 흐름 구문에서 DHCP와 같은 고급 기능을 구현할 수 있습니다.

5. OVN 추적을 실행합니다.

   ovn-trace 명령은 패킷이 OVN 논리 흐름을 통해 이동하는 방식을 시뮬레이션하거나 패킷이 삭제되는 이유를 확인할 수 있습니다. 다음 매개변수를 사용하여 ovn-trace 명령을 제공합니다.

   DATAPATH

   시뮬레이션된 패킷이 시작되는 논리 스위치 또는 논리 라우터입니다.

   MICROFLOW

   ovn-sb 데이터베이스에서 사용하는 구문에서 시뮬레이션된 패킷.

   예제

   이 예에서는 시뮬레이션된 패킷의 --minimal 출력 옵션을 표시하고 패킷이 대상에 도달했음을 보여줍니다.

   $ ovn-trace --minimal sw0 'inport == "sw0-port1" && eth.src == 00:00:00:00:00:01 && eth.dst == 00:00:00:00:00:02'

   샘플 출력

   #  reg14=0x1,vlan_tci=0x0000,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,dl_type=0x0000
       output("sw0-port2");

   예제

   보다 상세하게는, 이 동일한 시뮬레이션된 패킷에 대한 --summary 출력은 전체 실행 파이프라인을 보여줍니다.

   $ ovn-trace --summary sw0 'inport == "sw0-port1" && eth.src == 00:00:00:00:00:01 && eth.dst == 00:00:00:00:00:02'

   샘플 출력

   샘플 출력에는 다음이 표시됩니다.

   • 패킷은 sw 0-port1 포트에서 sw 0 네트워크에 들어가고 Ingress 파이프라인을 실행합니다.
   • outport 변수는 이 패킷의 의도한 대상이 sw0-port2 임을 나타내는 sw0-port2 로 설정됩니다.
   • 패킷이 수신 파이프라인의 출력이며, outport 변수가 sw0-port2 로 설정된 상태에서 sw0 의 송신 파이프라인으로 가져옵니다.

   • 출력 작업은 출력 파이프라인에서 실행되며, 이 파이프라인은 패킷을 sw0-port2 인 outport 변수의 현재 값으로 출력합니다.

     #  reg14=0x1,vlan_tci=0x0000,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,dl_type=0x0000
     ingress(dp="sw0", inport="sw0-port1") {
         outport = "sw0-port2";
         output;
         egress(dp="sw0", inport="sw0-port1", outport="sw0-port2") {
             output;
             /* output to "sw0-port2", type "" */;
         };
     };

절차

1. OVN 컨테이너에 액세스하는 데 필요한 권한이 있는 사용자로 컨트롤러 호스트에 로그인합니다.

   예제

   $ ssh heat-admin@controller-0.ctlplane

2. ovs-ofctl dump-flows 명령을 실행합니다.

   예제

   $ sudo ovs-ofctl dump-flows br-int

3. 다음 출력과 유사한 출력을 검사합니다.

   샘플 출력

   $ ovs-ofctl dump-flows br-int
   NXST_FLOW reply (xid=0x4):
    cookie=0x0, duration=72.132s, table=0, n_packets=0, n_bytes=0, idle_age=72, priority=10,in_port=1,dl_src=00:00:00:00:00:01 actions=resubmit(,1)
    cookie=0x0, duration=60.565s, table=0, n_packets=0, n_bytes=0, idle_age=60, priority=10,in_port=2,dl_src=00:00:00:00:00:02 actions=resubmit(,1)
    cookie=0x0, duration=28.127s, table=0, n_packets=0, n_bytes=0, idle_age=28, priority=0 actions=drop
    cookie=0x0, duration=13.887s, table=1, n_packets=0, n_bytes=0, idle_age=13, priority=0,in_port=1 actions=output:2
    cookie=0x0, duration=4.023s, table=1, n_packets=0, n_bytes=0, idle_age=4, priority=0,in_port=2 actions=output:1

절차

1. 테스트 네트워크 및 서브넷을 만듭니다.

   NETWORK_ID=\
   $(openstack network create internal_network | awk '/\| id/ {print $4}')
   
   openstack subnet create internal_subnet \
   --network $NETWORK_ID \
   --dns-nameserver 8.8.8.8 \
   --subnet-range 192.168.254.0/24

   오류가 발생하면 다음 단계를 수행하십시오.

2. 관련 컨테이너가 컨트롤러 호스트에서 실행되고 있는지 확인합니다.

   1. OVN 컨테이너에 액세스하는 데 필요한 권한이 있는 사용자로 컨트롤러 호스트에 로그인합니다.

      예제

      $ ssh heat-admin@controller-0.ctlplane

   2. 다음 명령을 실행합니다.

      sudo podman ps -a --format="{{.Names}}"|grep ovn

      다음 샘플에 표시된 대로 출력에 OVN 컨테이너가 나열되어야 합니다.

      샘플 출력

      ovn-dbs-bundle-podman-0
      ovn_dbs_init_bundle
      ovn_controller

3. 관련 컨테이너가 Compute 호스트에서 실행 중인지 확인합니다.

   1. OVN 컨테이너에 액세스하는 데 필요한 권한이 있는 사용자로 Compute 호스트에 로그인합니다.

      예제

      $ ssh heat-admin@compute-0.ctlplane

   2. 다음 명령을 실행합니다.

      $ sudo podman ps -a --format="{{.Names}}"|grep ovn

      다음 샘플에 표시된 대로 출력에 OVN 컨테이너가 나열되어야 합니다.

      샘플 출력

      ovn_controller
      ovn_metadata_agent
      neutron-haproxy-ovnmeta-26f493a7-1141-416a-9288-f08ff45fccac
      neutron-haproxy-ovnmeta-b81bd1f1-0ff4-4142-8706-0f295db3c3af

4. 로그 파일에서 오류 메시지를 검사합니다.

    grep -r ERR /var/log/containers/openvswitch/ /var/log/containers/neutron/

5. 별칭 파일을 가져와 OVN 데이터베이스 명령을 실행합니다.

   자세한 내용은 6.8절. “OVN 문제 해결 명령에 대한 별칭 생성”의 내용을 참조하십시오.

   예제

   $ source ~/ovn-alias.sh

6. northbound 및 southbound 데이터베이스를 쿼리하여 응답성을 확인합니다.

   예제

   # ovn-nbctl show
   # ovn-sbctl show

7. 동일한 계층 2 네트워크에 있는 OVN 메타데이터 인터페이스에서 인스턴스를 ping합니다.

   자세한 내용은 6.5절. “ML2/OVN 네임스페이스에서 기본 ICMP 테스트 수행”의 내용을 참조하십시오.

8. 지원을 받기 위해 Red Hat에 문의해야 하는 경우 이 Red Hat 솔루션에 설명된 단계를 수행하십시오. Red Hat 지원에 필요한 모든 로그를 수집하여 OpenStack 문제를 조사합니다.

절차

1. OVN 컨테이너에 액세스하는 데 필요한 권한이 있는 사용자로 로깅 모드를 설정하려는 컨트롤러 또는 컴퓨팅 노드에 로그인합니다.

   예제

   $ ssh heat-admin@controller-0.ctlplane

2. ML2/OVN 로깅 모드를 설정합니다.

   디버그 로깅 모드

   $ sudo podman exec -it ovn_controller ovn-appctl -t ovn-controller vlog/set dbg

   정보 로깅 모드

   $ sudo podman exec -it ovn_controller ovn-appctl -t ovn-controller vlog/set info

절차

1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.

2. 언더클라우드 인증 정보 파일을 소싱합니다.

   $ source ~/stackrc

3. qos 서비스 플러그인이 아직 로드되지 않았는지 확인합니다.

   $ openstack network qos policy list

   qos 서비스 플러그인이 로드되지 않은 경우 ResourceNotFound 오류가 발생합니다. 오류가 표시되지 않으면 플러그인이 로드되고 이 항목의 단계를 수행할 필요가 없습니다.

4. YAML 사용자 지정 환경 파일을 생성합니다.

   예제

   $ vi /home/stack/templates/my-neutron-environment.yaml

5. 환경 파일에는 parameter_defaults 키워드가 포함되어야 합니다. 아래 새 행에서 parameter_defaults 는 NeutronServicePlugins 매개변수에 qos 를 추가합니다.

   parameter_defaults:
      NeutronServicePlugins: "qos"

6. ML2/OVS 및 ML2/SR-IOV 메커니즘 드라이버를 사용하는 경우 NeutronAgentExtensions 또는 NeutronSriovAgentExtensions 변수를 각각 사용하여 에이전트에 qos 확장을 로드해야 합니다.

   • ML2/OVS

     parameter_defaults:
       NeutronServicePlugins: "qos"
       NeutronAgentExtensions: "qos"

   • ML2/SR-IOV

     parameter_defaults:
       NeutronServicePlugins: "qos"
       NeutronSriovAgentExtensions: "qos"

7. 최소 대역폭 QoS 정책을 사용하여 VM 인스턴스를 예약하려면 다음을 수행해야 합니다.

   1. 플러그인 목록에 배치를 추가하고 목록에 qos:도 포함되어 있는지 확인하십시오.

      parameter_defaults:
         NeutronServicePlugins: "qos,placement"

   2. 하이퍼바이저 이름이 Compute 서비스(nova)에서 사용하는 표준 하이퍼바이저 이름과 일치하는 경우 7.iii 단계로 건너뜁니다.

      하이퍼바이저 이름이 Compute 서비스에서 사용하는 표준 하이퍼바이저 이름과 일치하지 않는 경우 resource_provider_default_hypervisor 를 사용하여 대체 하이퍼바이저 이름을 지정합니다.

      • ML2/OVS

        parameter_defaults:
          NeutronServicePlugins: "qos,placement"
          ExtraConfig:
            Neutron::agents::ml2::ovs::resource_provider_default_hypervisor: %{hiera('fqdn_canonical')}

      • ML2/SR-IOV

        parameter_defaults:
          NeutronServicePlugins: "qos,placement"
          ExtraConfig:
            Neutron::agents::ml2::sriov::resource_provider_default_hypervisor: %{hiera('fqdn_canonical')}

        중요

        대체 하이퍼바이저 이름을 설정하는 또 다른 방법은 resource_provider_hypervisor 를 사용하는 것입니다.

        • ML2/OVS

          parameter_defaults:
            ExtraConfig:
               Neutron::agents::ml2::ovs::resource_provider_hypervisors:"ens5:%{hiera('fqdn_canonical')},ens6:%{hiera('fqdn_canonical')}"

        • ML2/SR-IOV

          parameter_defaults:
            ExtraConfig:
               Neutron::agents::ml2::sriov::resource_provider_hypervisors:
               "ens5:%{hiera('fqdn_canonical')},ens6:%{hiera('fqdn_canonical')}"

   3. 최소 대역폭을 제공해야 하는 각 컴퓨팅 노드에서 관련 에이전트에 대한 리소스 공급자 수신 및 송신 대역폭을 구성합니다.

      다음 형식을 사용하여 송신, 수신 또는 둘 다를 구성할 수 있습니다.

      • kbps에서 송신 대역폭만 구성합니다.

        NeutronOvsResourceProviderBandwidths: <bridge0>:<egress_kbps>:,<bridge1>:<egress_kbps>:,...,<bridgeN>:<egress_kbps>:

      • kbps에서 수신 대역폭만 구성합니다.

        NeutronOvsResourceProviderBandwidths: <bridge0>::<ingress_kbps>,<bridge1>::<ingress_kbps>,...,<bridgeN>::<ingress_kbps>

      • kbps에서 송신 및 수신 대역폭을 둘 다 구성합니다.

        NeutronOvsResourceProviderBandwidths: <bridge0>:<egress_kbps>:<ingress_kbps>,<bridge1>:<egress_kbps>:<ingress_kbps>,...,<bridgeN>:<egress_kbps>:<ingress_kbps>

        예 - OVS 에이전트

        OVS 에이전트에 대한 리소스 공급자 수신 및 송신 대역폭을 구성하려면 네트워크 환경 파일에 다음 구성을 추가합니다.

        parameter_defaults:
          ...
          NeutronBridgeMappings: physnet0:br-physnet0
          NeutronOvsResourceProviderBandwidths: br-physnet0:10000000:10000000

        예 - SRIOV 에이전트

        SRIOV 에이전트에 대한 리소스 공급자 수신 및 송신 대역폭을 구성하려면 네트워크 환경 파일에 다음 구성을 추가합니다.

        parameter_defaults:
          ...
          NeutronML2PhysicalNetworkMtus: physnet0:1500,physnet1:1500
          NeutronSriovResourceProviderBandwidths: ens5:40000000:40000000,ens6:40000000:40000000

   4. 선택 사항: 배치 서비스에서 여러 ML2 메커니즘 드라이버가 이를 지원하고 여러 에이전트가 추적되는 경우 vnic_types 를 지원하지 않는 것으로 표시하려면 다음 설정도 환경 파일에 추가합니다.

      예 - OVS 에이전트

      parameter_defaults:
        ...
        NeutronOvsVnicTypeBlacklist: direct

      예 - SRIOV 에이전트

      parameter_defaults:
        ...
        NeutronSriovVnicTypeBlacklist: direct

8. DSCP 표시 정책을 생성하고 터널링 프로토콜(VXLAN 또는 GRE)을 사용하여 ML2/OVS를 사용하려는 경우 NeutronAgentExtensions 에서 다음 행을 추가합니다.

   parameter_defaults:
     ...
     ControllerExtraConfig:
       neutron::config::server_config:
           agent/dscp_inherit:
               value: true

   dscp_inherit 이 true 인 경우 Networking 서비스는 내부 헤더의 DSCP 값을 외부 헤더에 복사합니다.

9. 배포 명령을 실행하고 코어 heat 템플릿, 기타 환경 파일 및 이 새로운 사용자 지정 환경 파일을 포함합니다.

   중요

   후속 환경 파일에 정의된 매개 변수와 리소스가 우선하기 때문에 환경 파일의 순서가 중요합니다.

   예제

   $ openstack overcloud deploy --templates \
   -e <other_environment_files> \
   -e /home/stack/templates/my-neutron-environment.yaml

절차

1. 자격 증명 파일을 가져옵니다.

   예제

   $ source ~/overcloudrc

2. qos 서비스 플러그인이 Networking 서비스에 로드되었는지 확인합니다.

   $ openstack network qos policy list

   qos 서비스 플러그인이 로드되지 않은 경우 ResourceNotFound 오류가 발생하고 qos 서비스 플러그인을 로드해야 합니다. 자세한 내용은 9.2절. “QoS 정책을 위한 네트워킹 서비스 구성”의 내용을 참조하십시오.

3. QoS 정책을 생성할 프로젝트의 ID를 확인합니다.

   $ openstack project list

   샘플 출력

   +----------------------------------+----------+
   | ID                               | Name     |
   +----------------------------------+----------+
   | 4b0b98f8c6c040f38ba4f7146e8680f5 | auditors |
   | 519e6344f82e4c079c8e2eabb690023b | services |
   | 80bf5732752a41128e612fe615c886c6 | demo     |
   | 98a2f53c20ce4d50a40dac4a38016c69 | admin    |
   +----------------------------------+----------+

4. 이전 단계의 프로젝트 ID를 사용하여 프로젝트에 대한 QoS 정책을 생성합니다.

   예제

   이 예에서는 admin 프로젝트에 대해 bw-limiter 라는 QoS 정책이 생성됩니다.

   $ openstack network qos policy create --share --project 98a2f53c20ce4d50a40dac4a38016c69 bw-limiter

5. 정책에 대한 규칙을 구성합니다.

   참고

   각 규칙의 유형 또는 방향이 다른 한 개 이상의 규칙을 정책에 추가할 수 있습니다. 예를 들어 송신과 수신 방향을 사용하여 대역폭 제한 규칙을 두 개 지정할 수 있습니다.

   예제

   이 예에서는 대역폭 제한이 50000 kbps이고 최대 버스트 크기인 bw-limiter 라는 정책에 대해 QoS 수신 및 송신 규칙이 생성됩니다.

   $ openstack network qos rule create --type bandwidth-limit \
       --max-kbps 50000 --max-burst-kbits 50000 --ingress bw-limiter
   
   $ openstack network qos rule create --type bandwidth-limit \
       --max-kbps 50000 --max-burst-kbits 50000 --egress bw-limiter

6. 정책이 연결된 포트를 생성하거나 정책을 기존 포트에 연결할 수 있습니다.

   예 - 정책이 연결된 포트 생성

   이 예에서 정책 bw-limiter 는 포트 port2 와 연결되어 있습니다.

   $ openstack port create --qos-policy bw-limiter --network private port2

   샘플 출력

   +-----------------------+--------------------------------------------------+
   | Field                 | Value                                            |
   +-----------------------+--------------------------------------------------+
   | admin_state_up        | UP                                               |
   | allowed_address_pairs |                                                  |
   | binding_host_id       |                                                  |
   | binding_profile       |                                                  |
   | binding_vif_details   |                                                  |
   | binding_vif_type      | unbound                                          |
   | binding_vnic_type     | normal                                           |
   | created_at            | 2022-07-04T19:20:24Z                             |
   | data_plane_status     | None                                             |
   | description           |                                                  |
   | device_id             |                                                  |
   | device_owner          |                                                  |
   | dns_assignment        | None                                             |
   | dns_name              | None                                             |
   | extra_dhcp_opts       |                                                  |
   | fixed_ips             | ip_address='192.0.2.210', subnet_id='292f8c-...' |
   | id                    | f51562ee-da8d-42de-9578-f6f5cb248226             |
   | ip_address            | None                                             |
   | mac_address           | fa:16:3e:d9:f2:ba                                |
   | name                  | port2                                            |
   | network_id            | 55dc2f70-0f92-4002-b343-ca34277b0234             |
   | option_name           | None                                             |
   | option_value          | None                                             |
   | port_security_enabled | False                                            |
   | project_id            | 98a2f53c20ce4d50a40dac4a38016c69                 |
   | qos_policy_id         | 8491547e-add1-4c6c-a50e-42121237256c             |
   | revision_number       | 6                                                |
   | security_group_ids    | 0531cc1a-19d1-4cc7-ada5-49f8b08245be             |
   | status                | DOWN                                             |
   | subnet_id             | None                                             |
   | tags                  | []                                               |
   | trunk_details         | None                                             |
   | updated_at            | 2022-07-04T19:23:00Z                             |
   +-----------------------+--------------------------------------------------+

   예 - 기존 포트에 정책 연결

   이 예에서 정책 bw-limiter 는 port1 과 연결됩니다.

   $ openstack port set --qos-policy bw-limiter port1

절차

1. 자격 증명 파일을 가져옵니다.

   예제

   $ source ~/overcloudrc

2. qos 서비스 플러그인이 Networking 서비스에 로드되었는지 확인합니다.

   $ openstack network qos policy list

   qos 서비스 플러그인이 로드되지 않은 경우 ResourceNotFound 오류가 발생하고, 계속 진행하기 전에 네트워킹 서비스를 구성해야 합니다. 자세한 내용은 9.2절. “QoS 정책을 위한 네트워킹 서비스 구성”의 내용을 참조하십시오.

3. QoS 정책을 생성할 프로젝트의 ID를 확인합니다.

   $ openstack project list

   샘플 출력

   +----------------------------------+----------+
   | ID                               | Name     |
   +----------------------------------+----------+
   | 4b0b98f8c6c040f38ba4f7146e8680f5 | auditors |
   | 519e6344f82e4c079c8e2eabb690023b | services |
   | 80bf5732752a41128e612fe615c886c6 | demo     |
   | 98a2f53c20ce4d50a40dac4a38016c69 | admin    |
   +----------------------------------+----------+

4. 이전 단계의 프로젝트 ID를 사용하여 프로젝트에 대한 QoS 정책을 생성합니다.

   예제

   이 예에서는 admin 프로젝트에 대해 qos-web-servers 라는 QoS 정책이 생성됩니다.

   openstack network qos policy create --project 98a2f53c20ce4d50a40dac4a38016c69 qos-web-servers

5. DSCP 규칙을 생성하고 정책에 적용합니다.

   예제

   이 예에서 DSCP 규칙은 DSCP 마크 18 을 사용하여 생성되며 qos-web-servers 정책에 적용됩니다.

   openstack network qos rule create --type dscp-marking --dscp-mark 18 qos-web-servers

   샘플 출력

   Created a new dscp_marking_rule:
   +-----------+--------------------------------------+
   | Field     | Value                                |
   +-----------+--------------------------------------+
   | dscp_mark | 18                                   |
   | id        | d7f976ec-7fab-4e60-af70-f59bf88198e6 |
   +-----------+--------------------------------------+

6. 규칙에 할당된 DSCP 값을 변경할 수 있습니다.

   예제

   이 예에서, qos-web-servers 정책에서 DSCP 마크 값이 규칙 d7f976ec-7fab-4e60-af70-f59bf88198e6 에서 22로 변경됩니다.

   $ openstack network qos rule set --dscp-mark 22 qos-web-servers d7f976ec-7fab-4e60-af70-f59bf88198e6

7. DSCP 규칙을 삭제할 수 있습니다.

   예제

   이 예에서는 qos-web -servers 정책에서 DSCP 규칙 d7f976ec-7fab-4e60-f59bf88198e6 이 삭제됩니다.

   $ openstack network qos rule delete qos-web-servers d7f976ec-7fab-4e60-af70-f59bf88198e6

절차

1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.

2. 언더클라우드 인증 정보 파일을 소싱합니다.

   $ source ~/stackrc

3. 사용자 지정 YAML 환경 파일을 만듭니다.

   예제

   $ vi /home/stack/templates/my_bridge_mappings.yaml

4. 환경 파일에는 parameter_defaults 키워드가 포함되어야 합니다. parameter_defaults 키워드 다음에 해당 사이트에 적합한 값을 사용하여 NeutronBridgeMappings heat 매개변수를 추가합니다.

   예제

   이 예에서 NeutronBridgeMappings 매개변수는 물리적 이름, datacentre 및 테넌트, 브리지 br-ex 및 br-tenant 를 각각 연결합니다.

   parameter_defaults:
     NeutronBridgeMappings: "datacentre:br-ex,tenant:br-tenant"

   참고

   NeutronBridgeMappings 매개변수를 사용하지 않는 경우 기본값은 호스트(br-ex)의 외부 브리지를 물리적 이름(datacentre)에 매핑합니다.

5. flat 네트워크를 사용하는 경우 NeutronFlatNetworks 매개변수를 사용하여 해당 이름을 추가합니다.

   예제

   이 예에서 매개 변수는 물리적 이름 datacentre 를 br-ex 브리지와 연결하고 물리 이름 테넌트 를 br-tenant와 연결합니다.

   parameter_defaults:
     NeutronBridgeMappings: "datacentre:br-ex,tenant:br-tenant"
     NeutronFlatNetworks: "my_flat_network"

   참고

   NeutronFlatNetworks 매개변수를 사용하지 않으면 기본값은 datacentre 입니다.

6. VLAN 네트워크를 사용하는 경우 NeutronNetworkVLANRanges 매개변수를 사용하여 액세스하는 VLAN 범위와 함께 네트워크 이름을 지정합니다.

   예제

   이 예에서 NeutronNetworkVLANRanges 매개변수는 테넌트 네트워크에 대해 1~1000의 VLAN 범위를 지정합니다.

   parameter_defaults:
    NeutronBridgeMappings: "datacentre:br-ex,tenant:br-tenant"
    NeutronNetworkVLANRanges: "tenant:1:1000"

7. 배포 명령을 실행하고 코어 heat 템플릿, 환경 파일 및 이 새 사용자 지정 환경 파일을 포함합니다.

   $ openstack overcloud deploy --templates \
     -e <your_environment_files> \
     -e /home/stack/templates/my_bridge_mappings.yaml

8. 다음 단계를 수행합니다.

   1. 네트워크 VLAN 범위를 사용하여 해당 외부 네트워크를 나타내는 프로바이더 네트워크를 만듭니다. ( neutron 프로바이더 네트워크 또는 유동 IP 네트워크를 만들 때 물리적 이름을 사용합니다.)
   2. 라우터 인터페이스를 사용하여 프로젝트 네트워크에 외부 네트워크를 연결합니다.

절차

1. 언더클라우드 노드의 환경 파일에서 EnableVLANTransparency 매개변수를 True 로 설정합니다. 예를 들어 다음 행을 ovn-extras.yaml에 추가합니다.

   parameter_defaults:
       EnableVLANTransparency: True

2. 해당 환경과 관련된 기타 환경 파일과 함께 openstack overcloud deploy 명령에 환경 파일을 포함하고 오버클라우드를 배포합니다.

   $ openstack overcloud deploy \
   --templates \
   …
   -e <other_overcloud_environment_files> \
   
   -e ovn-extras.yaml \
   …

   <other_overcloud_environment_files> 를 기존 배포에 포함된 환경 파일 목록으로 바꿉니다.

3. 네트워크를 만듭니다. 다음 예와 같이 --transparent-vlan 인수를 사용합니다.

   예제

   $ openstack network create network-name --transparent-vlan

4. 참여하는 각 VM에 VLAN 인터페이스를 설정합니다. VLAN 투명성에 필요한 추가 태그 지정을 수용하려면 인터페이스 MTU를 underlay 네트워크의 MTU보다 4바이트 미만으로 설정합니다. 예를 들어, underlay 네트워크 MTU가 1500인 경우 인터페이스 MTU를 1496로 설정합니다.

   다음 예제 명령은 eth0에 MTU가 1496인 VLAN 인터페이스를 추가합니다. VLAN은 50이고 인터페이스 이름은 vlan50입니다.

   예제

   ip link add link eth0 name vlan50 type vlan id 50 mtu 1496
   ip link set vlan50 up
   ip addr add 192.128.111.3/24 dev vlan50

검증

1. vlan50 IP 주소를 사용하여 VLAN에서 두 VM 간에 ping합니다.
2. eth0에서 tcpdump를 사용하여 패킷이 VLAN 태그가 그대로 도착하는지 확인합니다.

1. 트렁크된 VLAN에 액세스해야 하는 인스턴스가 포함된 네트워크를 식별합니다. 이 예제에서는 공용 네트워크입니다.

   openstack network list
   +--------------------------------------+---------+--------------------------------------+
   | ID                                   | Name    | Subnets                              |
   +--------------------------------------+---------+--------------------------------------+
   | 82845092-4701-4004-add7-838837837621 | private | 434c7982-cd96-4c41-a8c9-b93adbdcb197 |
   | 8d8bc6d6-5b28-4e00-b99e-157516ff0050 | public  | 3fd811b4-c104-44b5-8ff8-7a86af5e332c |
   +--------------------------------------+---------+--------------------------------------+

2. 상위 트렁크 포트를 만들어 인스턴스가 연결되는 네트워크에 연결합니다. 이 예에서는 공용 네트워크에 parent-trunk-port라는 neutron 포트를 만듭니다. 이 트렁크는 상위 포트입니다. 이를 사용하여 하위 포트를 생성할 수 있습니다.

   openstack port create --network public parent-trunk-port
   +-----------------------+-----------------------------------------------------------------------------+
   | Field                 | Value                                                                       |
   +-----------------------+-----------------------------------------------------------------------------+
   | admin_state_up        | UP                                                                          |
   | allowed_address_pairs |                                                                             |
   | binding_host_id       |                                                                             |
   | binding_profile       |                                                                             |
   | binding_vif_details   |                                                                             |
   | binding_vif_type      | unbound                                                                     |
   | binding_vnic_type     | normal                                                                      |
   | created_at            | 2016-10-20T02:02:33Z                                                        |
   | description           |                                                                             |
   | device_id             |                                                                             |
   | device_owner          |                                                                             |
   | extra_dhcp_opts       |                                                                             |
   | fixed_ips             | ip_address='172.24.4.230', subnet_id='dc608964-9af3-4fed-9f06-6d3844fb9b9b' |
   | headers               |                                                                             |
   | id                    | 20b6fdf8-0d43-475a-a0f1-ec8f757a4a39                                        |
   | mac_address           | fa:16:3e:33:c4:75                                                           |
   | name                  | parent-trunk-port                                                           |
   | network_id            | 871a6bd8-4193-45d7-a300-dcb2420e7cc3                                        |
   | project_id            | 745d33000ac74d30a77539f8920555e7                                            |
   | project_id            | 745d33000ac74d30a77539f8920555e7                                            |
   | revision_number       | 4                                                                           |
   | security_groups       | 59e2af18-93c6-4201-861b-19a8a8b79b23                                        |
   | status                | DOWN                                                                        |
   | updated_at            | 2016-10-20T02:02:33Z                                                        |
   +-----------------------+-----------------------------------------------------------------------------+

3. 2단계에서 생성한 포트를 사용하여 트렁크를 생성합니다. 이 예에서 트렁크의 이름은 parent-trunk 입니다.

   openstack network trunk create --parent-port parent-trunk-port parent-trunk
   +-----------------+--------------------------------------+
   | Field           | Value                                |
   +-----------------+--------------------------------------+
   | admin_state_up  | UP                                   |
   | created_at      | 2016-10-20T02:05:17Z                 |
   | description     |                                      |
   | id              | 0e4263e2-5761-4cf6-ab6d-b22884a0fa88 |
   | name            | parent-trunk                         |
   | port_id         | 20b6fdf8-0d43-475a-a0f1-ec8f757a4a39 |
   | revision_number | 1                                    |
   | status          | DOWN                                 |
   | sub_ports       |                                      |
   | tenant_id       | 745d33000ac74d30a77539f8920555e7     |
   | updated_at      | 2016-10-20T02:05:17Z                 |
   +-----------------+--------------------------------------+

4. 트렁크 연결을 확인합니다.

   openstack network trunk list
   +--------------------------------------+--------------+--------------------------------------+-------------+
   | ID                                   | Name         | Parent Port                          | Description |
   +--------------------------------------+--------------+--------------------------------------+-------------+
   | 0e4263e2-5761-4cf6-ab6d-b22884a0fa88 | parent-trunk | 20b6fdf8-0d43-475a-a0f1-ec8f757a4a39 |             |
   +--------------------------------------+--------------+--------------------------------------+-------------+

5. 트렁크 연결 세부 정보를 확인합니다.

   openstack network trunk show parent-trunk
   +-----------------+--------------------------------------+
   | Field           | Value                                |
   +-----------------+--------------------------------------+
   | admin_state_up  | UP                                   |
   | created_at      | 2016-10-20T02:05:17Z                 |
   | description     |                                      |
   | id              | 0e4263e2-5761-4cf6-ab6d-b22884a0fa88 |
   | name            | parent-trunk                         |
   | port_id         | 20b6fdf8-0d43-475a-a0f1-ec8f757a4a39 |
   | revision_number | 1                                    |
   | status          | DOWN                                 |
   | sub_ports       |                                      |
   | tenant_id       | 745d33000ac74d30a77539f8920555e7     |
   | updated_at      | 2016-10-20T02:05:17Z                 |
   +-----------------+--------------------------------------+

1. neutron 포트를 만듭니다.

   이 포트는 트렁크에 대한 하위 포트 연결입니다. 또한 상위 포트에 할당한 MAC 주소를 지정해야 합니다.

   openstack port create --network private --mac-address fa:16:3e:33:c4:75 subport-trunk-port
   +-----------------------+--------------------------------------------------------------------------+
   | Field                 | Value                                                                    |
   +-----------------------+--------------------------------------------------------------------------+
   | admin_state_up        | UP                                                                       |
   | allowed_address_pairs |                                                                          |
   | binding_host_id       |                                                                          |
   | binding_profile       |                                                                          |
   | binding_vif_details   |                                                                          |
   | binding_vif_type      | unbound                                                                  |
   | binding_vnic_type     | normal                                                                   |
   | created_at            | 2016-10-20T02:08:14Z                                                     |
   | description           |                                                                          |
   | device_id             |                                                                          |
   | device_owner          |                                                                          |
   | extra_dhcp_opts       |                                                                          |
   | fixed_ips             | ip_address='10.0.0.11', subnet_id='1a299780-56df-4c0b-a4c0-c5a612cef2e8' |
   | headers               |                                                                          |
   | id                    | 479d742e-dd00-4c24-8dd6-b7297fab3ee9                                     |
   | mac_address           | fa:16:3e:33:c4:75                                                        |
   | name                  | subport-trunk-port                                                       |
   | network_id            | 3fe6b758-8613-4b17-901e-9ba30a7c4b51                                     |
   | project_id            | 745d33000ac74d30a77539f8920555e7                                         |
   | project_id            | 745d33000ac74d30a77539f8920555e7                                         |
   | revision_number       | 4                                                                        |
   | security_groups       | 59e2af18-93c6-4201-861b-19a8a8b79b23                                     |
   | status                | DOWN                                                                     |
   | updated_at            | 2016-10-20T02:08:15Z                                                     |
   +-----------------------+--------------------------------------------------------------------------+

   참고

   오류가 발생하면 HttpException: conflict, 다른 네트워크에서 상위 트렁크 포트가 있는 포트에 하위 포트를 생성 중인지 확인합니다. 이 예에서는 상위 트렁크 포트에 공용 네트워크를 사용하고 하위 포트에 private 네트워크를 사용합니다.

2. 포트를 trunk(parent-trunk)과 연결하고 VLAN ID(55)를 지정합니다.

   openstack network trunk set --subport port=subport-trunk-port,segmentation-type=vlan,segmentation-id=55 parent-trunk

절차

1. 네트워크 트렁크 명령을 사용하여 네트워크 트렁크의 구성을 검토합니다.

   예제

   $ openstack network trunk list

   샘플 출력

   +---------------------+--------------+---------------------+-------------+
   | ID                  | Name         | Parent Port         | Description |
   +---------------------+--------------+---------------------+-------------+
   | 0e4263e2-5761-4cf6- | parent-trunk | 20b6fdf8-0d43-475a- |             |
   | ab6d-b22884a0fa88   |              | a0f1-ec8f757a4a39   |             |
   +---------------------+--------------+---------------------+-------------+

   예제

   $ openstack network trunk show parent-trunk

   샘플 출력

   +-----------------+------------------------------------------------------+
   | Field           | Value                                                |
   +-----------------+------------------------------------------------------+
   | admin_state_up  | UP                                                   |
   | created_at      | 2021-10-20T02:05:17Z                                 |
   | description     |                                                      |
   | id              | 0e4263e2-5761-4cf6-ab6d-b22884a0fa88                 |
   | name            | parent-trunk                                         |
   | port_id         | 20b6fdf8-0d43-475a-a0f1-ec8f757a4a39                 |
   | revision_number | 2                                                    |
   | status          | DOWN                                                 |
   | sub_ports       | port_id='479d742e-dd00-4c24-8dd6-b7297fab3ee9', segm |
   |                 | entation_id='55', segmentation_type='vlan'           |
   | tenant_id       | 745d33000ac74d30a77539f8920555e7                     |
   | updated_at      | 2021-08-20T02:10:06Z                                 |
   +-----------------+------------------------------------------------------+

2. 상위 port-id 를 vNIC로 사용하는 인스턴스를 생성합니다.

   예제

   openstack server create --image cirros --flavor m1.tiny --security-group default --key-name sshaccess --nic port-id=20b6fdf8-0d43-475a-a0f1-ec8f757a4a39 testInstance

   샘플 출력

   +--------------------------------------+---------------------------------+
   | Property                             | Value                           |
   +--------------------------------------+---------------------------------+
   | OS-DCF:diskConfig                    | MANUAL                          |
   | OS-EXT-AZ:availability_zone          |                                 |
   | OS-EXT-SRV-ATTR:host                 | -                               |
   | OS-EXT-SRV-ATTR:hostname             | testinstance                    |
   | OS-EXT-SRV-ATTR:hypervisor_hostname  | -                               |
   | OS-EXT-SRV-ATTR:instance_name        |                                 |
   | OS-EXT-SRV-ATTR:kernel_id            |                                 |
   | OS-EXT-SRV-ATTR:launch_index         | 0                               |
   | OS-EXT-SRV-ATTR:ramdisk_id           |                                 |
   | OS-EXT-SRV-ATTR:reservation_id       | r-juqco0el                      |
   | OS-EXT-SRV-ATTR:root_device_name     | -                               |
   | OS-EXT-SRV-ATTR:user_data            | -                               |
   | OS-EXT-STS:power_state               | 0                               |
   | OS-EXT-STS:task_state                | scheduling                      |
   | OS-EXT-STS:vm_state                  | building                        |
   | OS-SRV-USG:launched_at               | -                               |
   | OS-SRV-USG:terminated_at             | -                               |
   | accessIPv4                           |                                 |
   | accessIPv6                           |                                 |
   | adminPass                            | uMyL8PnZRBwQ                    |
   | config_drive                         |                                 |
   | created                              | 2021-08-20T03:02:51Z            |
   | description                          | -                               |
   | flavor                               | m1.tiny (1)                     |
   | hostId                               |                                 |
   | host_status                          |                                 |
   | id                                   | 88b7aede-1305-4d91-a180-67e7eac |
   |                                      | 8b70d                           |
   | image                                | cirros (568372f7-15df-4e61-a05f |
   |                                      | -10954f79a3c4)                  |
   | key_name                             | sshaccess                       |
   | locked                               | False                           |
   | metadata                             | {}                              |
   | name                                 | testInstance                    |
   | os-extended-volumes:volumes_attached | []                              |
   | progress                             | 0                               |
   | security_groups                      | default                         |
   | status                               | BUILD                           |
   | tags                                 | []                              |
   | tenant_id                            | 745d33000ac74d30a77539f8920555e |
   |                                      | 7                               |
   | updated                              | 2021-08-20T03:02:51Z            |
   | user_id                              | 8c4aea738d774967b4ef388eb41fef5 |
   |                                      | e                               |
   +--------------------------------------+---------------------------------+

절차

1. Undercloud 호스트에서 stack 사용자로 로그인한 사용자 지정 YAML 환경 파일을 만듭니다.

   예제

   $ vi /home/stack/templates/my-modules-environment.yaml

   작은 정보

   RHOSP Orchestration 서비스(heat)에서는 템플릿 이라는 플랜 세트를 사용하여 환경을 설치하고 구성합니다. heat 템플릿에 대한 사용자 지정을 제공하는 특수 유형의 템플릿 파일인 사용자 지정 환경 파일을 사용하여 오버클라우드의 특정 부분을 사용자 지정할 수 있습니다.

2. ExtraConfig 의 YAML 환경 파일에서 rpc_response_timeout 에 적절한 값(초)을 설정합니다. (기본값은 60초입니다.)

   예제

   parameter_defaults:
     ExtraConfig:
       neutron::rpc_response_timeout: 120

   참고

   RHOSP Orchestration 서비스(heat)는 사용자 정의 환경 파일에 설정한 값으로 모든 RHOSP 노드를 업데이트하지만 이 값은 RHOSP 네트워킹 구성 요소에만 영향을 미칩니다.

3. openstack overcloud deploy 명령을 실행하고 코어 heat 템플릿, 환경 파일 및 이 새 사용자 지정 환경 파일을 포함합니다.

   중요

   후속 환경 파일에 정의된 매개 변수와 리소스가 우선하므로 환경 파일의 순서가 중요합니다.

   예제

   $ openstack overcloud deploy --templates \
   -e [your-environment-files] \
   -e /usr/share/openstack-tripleo-heat-templates/environments/services/my-modules-environment.yaml

1. 사용 가능한 네트워크 목록을 확인합니다.

   # openstack network list
   +--------------------------------------+-------------+-------------------------------------------------------+
   | id                                   | name        | subnets                                               |
   +--------------------------------------+-------------+-------------------------------------------------------+
   | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 | web-servers | 20512ffe-ad56-4bb4-b064-2cb18fecc923 192.168.200.0/24 |
   | bcc16b34-e33e-445b-9fde-dd491817a48a | private     | 7fe4a05a-4b81-4a59-8c47-82c965b0e050 10.0.0.0/24      |
   | 9b2f4feb-fee8-43da-bb99-032e4aaf3f85 | public      | 2318dc3b-cff0-43fc-9489-7d4cf48aaab9 172.24.4.224/28  |
   +--------------------------------------+-------------+-------------------------------------------------------+

2. 프로젝트 목록을 확인합니다.

   # openstack project list
   +----------------------------------+----------+
   | ID                               | Name     |
   +----------------------------------+----------+
   | 4b0b98f8c6c040f38ba4f7146e8680f5 | auditors |
   | 519e6344f82e4c079c8e2eabb690023b | services |
   | 80bf5732752a41128e612fe615c886c6 | demo     |
   | 98a2f53c20ce4d50a40dac4a38016c69 | admin    |
   +----------------------------------+----------+

3. auditors 프로젝트 (4b0b98f8c040f38ba4f7146e8680f5)에 대한 액세스 권한을 부여하는 web-servers 네트워크에 대한 RBAC 항목을 생성합니다.

   # openstack network rbac create --type network --target-project 4b0b98f8c6c040f38ba4f7146e8680f5 --action access_as_shared web-servers
   Created a new rbac_policy:
   +----------------+--------------------------------------+
   | Field          | Value                                |
   +----------------+--------------------------------------+
   | action         | access_as_shared                     |
   | id             | 314004d0-2261-4d5e-bda7-0181fcf40709 |
   | object_id      | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 |
   | object_type    | network                              |
   | target_project | 4b0b98f8c6c040f38ba4f7146e8680f5     |
   | project_id     | 98a2f53c20ce4d50a40dac4a38016c69     |
   +----------------+--------------------------------------+

1. openstack network rbac list 명령을 실행하여 기존 역할 기반 액세스 제어(RBAC) 정책의 ID를 검색합니다.

   # openstack network rbac list
   +--------------------------------------+-------------+--------------------------------------+
   | id                                   | object_type | object_id                            |
   +--------------------------------------+-------------+--------------------------------------+
   | 314004d0-2261-4d5e-bda7-0181fcf40709 | network     | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 |
   | bbab1cf9-edc5-47f9-aee3-a413bd582c0a | network     | 9b2f4feb-fee8-43da-bb99-032e4aaf3f85 |
   +--------------------------------------+-------------+--------------------------------------+

2. openstack network rbac-show 명령을 실행하여 특정 RBAC 항목의 세부 정보를 확인합니다.

   # openstack network rbac show 314004d0-2261-4d5e-bda7-0181fcf40709
   +----------------+--------------------------------------+
   | Field          | Value                                |
   +----------------+--------------------------------------+
   | action         | access_as_shared                     |
   | id             | 314004d0-2261-4d5e-bda7-0181fcf40709 |
   | object_id      | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 |
   | object_type    | network                              |
   | target_project | 4b0b98f8c6c040f38ba4f7146e8680f5     |
   | project_id     | 98a2f53c20ce4d50a40dac4a38016c69     |
   +----------------+--------------------------------------+

1. openstack network rbac list 명령을 실행하여 기존 역할 기반 액세스 제어(RBAC) 정책의 ID를 검색합니다.

   # openstack network rbac list
   +--------------------------------------+-------------+--------------------------------------+
   | id                                   | object_type | object_id                            |
   +--------------------------------------+-------------+--------------------------------------+
   | 314004d0-2261-4d5e-bda7-0181fcf40709 | network     | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 |
   | bbab1cf9-edc5-47f9-aee3-a413bd582c0a | network     | 9b2f4feb-fee8-43da-bb99-032e4aaf3f85 |
   +--------------------------------------+-------------+--------------------------------------+

2. 삭제하려는 RBAC의 ID를 사용하여 openstack network rbac delete 명령을 실행하여 RBAC를 삭제합니다.

   # openstack network rbac delete 314004d0-2261-4d5e-bda7-0181fcf40709
   Deleted rbac_policy: 314004d0-2261-4d5e-bda7-0181fcf40709

절차

1. OS::TripleO::Compute::Net::SoftwareConfig 의 값이 파일 overcloud-resource-registry.yaml 또는 배포 명령에 포함된 환경 파일의 OS::TripleO::Controller::Net::SoftwareConfig 값과 일치하는지 확인합니다.

   이 값은 net_config_bridge.yaml 과 같은 파일의 이름을 지정합니다. 명명된 파일은 외부 네트워크 컴퓨팅 노드 L2 에이전트에 대한 Neutron 브리지 매핑을 구성합니다. 브리지는 DVR 배포의 컴퓨팅 노드에 호스팅된 유동 IP 주소의 트래픽을 라우팅합니다. 일반적으로 이 파일 이름 값은 environments/net-multiple-nics.yaml 과 같이 오버클라우드를 배포할 때 사용하는 네트워크 환경 파일에서 찾을 수 있습니다.

   참고

   컴퓨팅 노드의 네트워크 구성을 사용자 지정하는 경우 대신 사용자 지정 파일에 적절한 구성을 추가해야 할 수 있습니다.

2. 계산 노드에 외부 브리지가 있는지 확인합니다.

   1. openstack-tripleo-heat-templates 디렉터리의 로컬 복사본을 만듭니다.
   2. $ cd <local_copy_of_templates_directory.

   3. process-templates 스크립트를 실행하여 템플릿을 임시 출력 디렉터리에 렌더링합니다.

      $ ./tools/process-templates.py -r <roles_data.yaml> \
        -n <network_data.yaml> -o <temporary_output_directory>

   4. <temporary_output_directory>/network/config 에서 역할 파일을 확인합니다.
3. 필요한 경우 컨트롤러 노드와 일치하는 외부 브리지를 포함하도록 계산 템플릿을 사용자 지정하고 환경 파일의 OS::TripleO::Compute::Net::SoftwareConfig 에 사용자 지정 파일 경로 이름을 지정합니다.

4. 오버클라우드를 배포할 때 배포 명령에 environments/services/neutron-ovs-dvr.yaml 파일을 포함합니다.

   $ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs-dvr.yaml

5. L3 HA가 비활성화되었는지 확인합니다.

   참고

   L3 에이전트의 외부 브리지 구성은 Red Hat OpenStack Platform 13에서 더 이상 사용되지 않으며 Red Hat OpenStack Platform 15에서 제거되었습니다.

절차

1. 배포를 업그레이드하고 올바르게 작동하는지 확인합니다.
2. director 스택 업데이트를 실행하여 DVR을 구성합니다.
3. 기존 라우터를 통해 라우팅이 올바르게 작동하는지 확인합니다.

4. L3 HA 라우터를 직접 배포 하도록 전환할 수 없습니다. 대신 각 라우터에 대해 L3 HA 옵션을 비활성화한 다음 분산 옵션을 활성화합니다.

   1. 라우터를 비활성화합니다.

      예제

      $ openstack router set --disable router1

   2. 고가용성 지우기:

      예제

      $ openstack router set --no-ha router1

   3. DVR을 사용하도록 라우터를 구성합니다.

      예제

      $ openstack router set --distributed router1

   4. 라우터를 활성화합니다.

      예제

      $ openstack router set --enable router1

   5. 분산 라우팅이 올바르게 작동하는지 확인합니다.

절차

1. 사용자 지정 환경 파일을 생성하고 다음 구성을 추가합니다.

   parameter_defaults:
     NeutronEnableDVR: false

2. 이 구성을 적용하려면 오버클라우드를 배포하고 사용자 지정 환경 파일을 다른 환경 파일과 함께 스택에 추가합니다. 예를 들면 다음과 같습니다.

   (undercloud) $ openstack overcloud deploy --templates \
     -e [your environment files]
     -e /home/stack/templates/<custom-environment-file>.yaml

절차

1. IPv6 서브넷을 만들 프로젝트의 프로젝트 ID를 검색합니다. 이러한 값은 OpenStack 배포 간에 고유하므로 이 예제의 값과 값이 다릅니다.

   # openstack project list
   +----------------------------------+----------+
   | ID                               | Name     |
   +----------------------------------+----------+
   | 25837c567ed5458fbb441d39862e1399 |    QA    |
   | f59f631a77264a8eb0defc898cb836af |  admin   |
   | 4e2e1951e70643b5af7ed52f3ff36539 |   demo   |
   | 8561dff8310e4cd8be4b6fd03dc8acf5 | services |
   +----------------------------------+----------+

2. OpenStack Networking(neutron)에 있는 모든 네트워크 목록을 검색하고 IPv6 서브넷을 호스팅하려는 네트워크의 이름을 확인합니다.

   # openstack network list
   +--------------------------------------+------------------+-------------------------------------------------------------+
   | id                                   | name             | subnets                                                     |
   +--------------------------------------+------------------+-------------------------------------------------------------+
   | 8357062a-0dc2-4146-8a7f-d2575165e363 | private          | c17f74c4-db41-4538-af40-48670069af70 10.0.0.0/24            |
   | 31d61f7d-287e-4ada-ac29-ed7017a54542 | public           | 303ced03-6019-4e79-a21c-1942a460b920 172.24.4.224/28        |
   | 6aff6826-4278-4a35-b74d-b0ca0cbba340 | database-servers |                                                             |
   +--------------------------------------+------------------+-------------------------------------------------------------+

3. openstack subnet create 명령에 프로젝트 ID, 네트워크 이름 및 ipv6 주소 모드를 포함합니다.

   # openstack subnet create --ip-version 6 --ipv6-address-mode dhcpv6-stateful --project 25837c567ed5458fbb441d39862e1399 --network database-servers --subnet-range fdf8:f53b:82e4::53/125 subnet_name
   
   Created a new subnet:
   +-------------------+--------------------------------------------------------------+
   | Field             | Value                                                        |
   +-------------------+--------------------------------------------------------------+
   | allocation_pools  | {"start": "fdf8:f53b:82e4::52", "end": "fdf8:f53b:82e4::56"} |
   | cidr              | fdf8:f53b:82e4::53/125                                       |
   | dns_nameservers   |                                                              |
   | enable_dhcp       | True                                                         |
   | gateway_ip        | fdf8:f53b:82e4::51                                           |
   | host_routes       |                                                              |
   | id                | cdfc3398-997b-46eb-9db1-ebbd88f7de05                         |
   | ip_version        | 6                                                            |
   | ipv6_address_mode | dhcpv6-stateful                                              |
   | ipv6_ra_mode      |                                                              |
   | name              |                                                              |
   | network_id        | 6aff6826-4278-4a35-b74d-b0ca0cbba340                         |
   | tenant_id         | 25837c567ed5458fbb441d39862e1399                             |
   +-------------------+--------------------------------------------------------------+

검증 단계

1. 네트워크 목록을 검토하여 이 구성을 확인합니다. database-servers 에 대한 항목은 이제 새로 생성된 IPv6 서브넷을 반영합니다.

   # openstack network list
   +--------------------------------------+------------------+-------------------------------------------------------------+
   | id                                   | name             | subnets                                                     |
   +--------------------------------------+------------------+-------------------------------------------------------------+
   | 6aff6826-4278-4a35-b74d-b0ca0cbba340 | database-servers | cdfc3398-997b-46eb-9db1-ebbd88f7de05 fdf8:f53b:82e4::50/125 |
   | 8357062a-0dc2-4146-8a7f-d2575165e363 | private          | c17f74c4-db41-4538-af40-48670069af70 10.0.0.0/24            |
   | 31d61f7d-287e-4ada-ac29-ed7017a54542 | public           | 303ced03-6019-4e79-a21c-1942a460b920 172.24.4.224/28        |
   +--------------------------------------+------------------+-------------------------------------------------------------+

   결과

   이 구성의 결과로 QA 프로젝트에서 생성하는 인스턴스에서 database-servers 서브넷에 추가할 때 DHCP IPv6 주소를 수신할 수 있습니다.

   # openstack server list
   +--------------------------------------+------------+--------+------------+-------------+-------------------------------------+
   | ID                                   | Name       | Status | Task State | Power State | Networks                            |
   +--------------------------------------+------------+--------+------------+-------------+-------------------------------------+
   | fad04b7a-75b5-4f96-aed9-b40654b56e03 | corp-vm-01 | ACTIVE | -          | Running     | database-servers=fdf8:f53b:82e4::52 |
   +--------------------------------------+------------+--------+------------+-------------+-------------------------------------+

절차

1. 네트워크 내에서 각 세그먼트에 대해 고유한 실제 네트워크 이름을 사용합니다. 그러면 서브넷 간에 동일한 분할 세부 정보를 재사용할 수 있습니다.

   예를 들어 특정 프로바이더 네트워크의 모든 세그먼트에서 동일한 VLAN ID를 사용합니다.

2. 세그먼트 간 라우팅 구현.

   세그먼트의 각 서브넷에는 해당 서브넷에 있는 라우터 인터페이스의 게이트웨이 주소가 포함되어야 합니다.

   표 16.1. 라우팅의 샘플 세그먼트

   세그먼트	버전	주소	gateway
   segment1	4	203.0.113.0/24	203.0.113.1
   segment1	6	fd00:203:0:113::/64	fd00:203:0:113::1
   segment2	4	198.51.100.0/24	198.51.100.1
   segment2	6	fd00:198:51:100::/64	fd00:198:51:100::1

3. 세그먼트를 컴퓨팅 노드에 매핑합니다.

   RPN은 컴퓨팅 노드가 여러 세그먼트에 있다는 것을 의미합니다. RPN의 모든 Compute 호스트가 해당 세그먼트 중 하나에 직접 연결되어 있는지 확인합니다.

   표 16.2. 컴퓨팅 노드 매핑의 샘플 세그먼트

   호스트	랙	물리적 네트워크
   compute0001	랙 1	세그먼트 1
   compute0002	랙 1	세그먼트 1
   …	…	…
   compute0101	랙 2	세그먼트 2
   compute0102	랙 2	세그먼트 2
   compute0102	랙 2	세그먼트 2
   …	…	…

4. Open vSwitch 메커니즘 드라이버(ML2/OVS)를 사용하여 모듈 계층 2 플러그인을 사용하여 배포하는 경우 세그먼트당 하나 이상의 DHCP 에이전트를 배포해야 합니다.

   기존 프로바이더 네트워크와 달리 DHCP 에이전트는 네트워크 내에서 둘 이상의 세그먼트를 지원할 수 없습니다. 노드 수를 줄이기 위해 네트워크 노드가 아닌 세그먼트가 포함된 컴퓨팅 노드에 DHCP 에이전트를 배포합니다.

   표 16.3. 세그먼트당 DHCP 에이전트 샘플

   호스트	랙	물리적 네트워크
   network0001	랙 1	세그먼트 1
   network0002	랙 1	세그먼트 1
   …	…	…

   사용자 지정 역할 파일을 사용하여 컴퓨팅 노드에 DHCP 에이전트 및 RHOSP Networking 서비스(neutron) 메타데이터 에이전트를 배포합니다.

   예를 들면 다음과 같습니다.

   ###############################################################################
   # Role: ComputeSriov                                                          #
   ###############################################################################
   - name: ComputeSriov
     description: |
       Compute SR-IOV Role
     CountDefault: 1
     networks:
       External:
         subnet: external_subnet
       InternalApi:
         subnet: internal_api_subnet
       Tenant:
         subnet: tenant_subnet
       Storage:
         subnet: storage_subnet
     RoleParametersDefault:
       TunedProfileName: "cpu-partitioning"
     update_serial: 25
     ServicesDefault:
       - OS::TripleO::Services::Aide
       - OS::TripleO::Services::AuditD
       - OS::TripleO::Services::BootParams
       - OS::TripleO::Services::CACerts
   ...
       - OS::TripleO::Services::NeutronDhcpAgent
       - OS::TripleO::Services::NeutronMetadataAgent
   ...

   사용자 지정 환경 파일에서 다음 키-값 쌍을 추가합니다.

   parameter_defaults:
       ....
       NeutronEnableIsolatedMetadata: 'True'
       ....

절차

1. 기본 세그먼트를 포함하는 VLAN 프로바이더 네트워크를 생성합니다.

   이 예제에서 VLAN 프로바이더 네트워크의 이름은 multisegment1 이며 provider1 이라는 실제 네트워크와 ID가 128 인 VLAN을 사용합니다.

   예제

   $ openstack network create --share --provider-physical-network provider1 \
     --provider-network-type vlan --provider-segment 128 multisegment1

   샘플 출력

   +---------------------------+--------------------------------------+
   | Field                     | Value                                |
   +---------------------------+--------------------------------------+
   | admin_state_up            | UP                                   |
   | id                        | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9 |
   | ipv4_address_scope        | None                                 |
   | ipv6_address_scope        | None                                 |
   | l2_adjacency              | True                                 |
   | mtu                       | 1500                                 |
   | name                      | multisegment1                        |
   | port_security_enabled     | True                                 |
   | provider:network_type     | vlan                                 |
   | provider:physical_network | provider1                            |
   | provider:segmentation_id  | 128                                  |
   | revision_number           | 1                                    |
   | router:external           | Internal                             |
   | shared                    | True                                 |
   | status                    | ACTIVE                               |
   | subnets                   |                                      |
   | tags                      | []                                   |
   +---------------------------+--------------------------------------+

2. 기본 네트워크 세그먼트의 이름을 segment1 로 바꿉니다.

   1. 세그먼트 ID를 가져옵니다.

      $ openstack network segment list --network multisegment1

      샘플 출력

      +--------------------------------------+----------+--------------------------------------+--------------+---------+
      | ID                                   | Name     | Network                              | Network Type | Segment |
      +--------------------------------------+----------+--------------------------------------+--------------+---------+
      | 43e16869-ad31-48e4-87ce-acf756709e18 | None     | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9 | vlan         | 128     |
      +--------------------------------------+----------+--------------------------------------+--------------+---------+

   2. 세그먼트 ID를 사용하여 네트워크 세그먼트의 이름을 segment1 로 바꿉니다 :

      $ openstack network segment set --name segment1 43e16869-ad31-48e4-87ce-acf756709e18

3. 프로바이더 네트워크에 두 번째 세그먼트를 만듭니다.

   이 예에서 네트워크 세그먼트는 provider2 라는 물리적 네트워크와 ID가 129 인 VLAN을 사용합니다.

   예제

   $ openstack network segment create --physical-network provider2 \
     --network-type vlan --segment 129 --network multisegment1 segment2

   샘플 출력

   +------------------+--------------------------------------+
   | Field            | Value                                |
   +------------------+--------------------------------------+
   | description      | None                                 |
   | headers          |                                      |
   | id               | 053b7925-9a89-4489-9992-e164c8cc8763 |
   | name             | segment2                             |
   | network_id       | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9 |
   | network_type     | vlan                                 |
   | physical_network | provider2                            |
   | revision_number  | 1                                    |
   | segmentation_id  | 129                                  |
   | tags             | []                                   |
   +------------------+--------------------------------------+

4. 네트워크에 segment 1 및 segment 2 세그먼트 가 포함되어 있는지 확인합니다.

   $ openstack network segment list --network multisegment1

   샘플 출력

   +--------------------------------------+----------+--------------------------------------+--------------+---------+
   | ID                                   | Name     | Network                              | Network Type | Segment |
   +--------------------------------------+----------+--------------------------------------+--------------+---------+
   | 053b7925-9a89-4489-9992-e164c8cc8763 | segment2 | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9 | vlan         | 129     |
   | 43e16869-ad31-48e4-87ce-acf756709e18 | segment1 | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9 | vlan         | 128     |
   +--------------------------------------+----------+--------------------------------------+--------------+---------+

5. segment1 세그먼트에 하나의 IPv4 서브넷과 IPv6 서브넷 1개를 만듭니다.

   이 예에서 IPv4 서브넷은 203.0.113.0/24 를 사용합니다.

   예제

   $ openstack subnet create \
     --network multisegment1 --network-segment segment1 \
     --ip-version 4 --subnet-range 203.0.113.0/24 \
     multisegment1-segment1-v4

   샘플 출력

   +-------------------+--------------------------------------+
   | Field             | Value                                |
   +-------------------+--------------------------------------+
   | allocation_pools  | 203.0.113.2-203.0.113.254            |
   | cidr              | 203.0.113.0/24                       |
   | enable_dhcp       | True                                 |
   | gateway_ip        | 203.0.113.1                          |
   | id                | c428797a-6f8e-4cb1-b394-c404318a2762 |
   | ip_version        | 4                                    |
   | name              | multisegment1-segment1-v4            |
   | network_id        | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9 |
   | revision_number   | 1                                    |
   | segment_id        | 43e16869-ad31-48e4-87ce-acf756709e18 |
   | tags              | []                                   |
   +-------------------+--------------------------------------+

   이 예에서 IPv6 서브넷은 fd00:203:0:113::/64 를 사용합니다.

   예제

   $ openstack subnet create \
     --network multisegment1 --network-segment segment1 \
     --ip-version 6 --subnet-range fd00:203:0:113::/64 \
     --ipv6-address-mode slaac multisegment1-segment1-v6

   샘플 출력

   +-------------------+------------------------------------------------------+
   | Field             | Value                                                |
   +-------------------+------------------------------------------------------+
   | allocation_pools  | fd00:203:0:113::2-fd00:203:0:113:ffff:ffff:ffff:ffff |
   | cidr              | fd00:203:0:113::/64                                  |
   | enable_dhcp       | True                                                 |
   | gateway_ip        | fd00:203:0:113::1                                    |
   | id                | e41cb069-9902-4c01-9e1c-268c8252256a                 |
   | ip_version        | 6                                                    |
   | ipv6_address_mode | slaac                                                |
   | ipv6_ra_mode      | None                                                 |
   | name              | multisegment1-segment1-v6                            |
   | network_id        | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9                 |
   | revision_number   | 1                                    |
   | segment_id        | 43e16869-ad31-48e4-87ce-acf756709e18                 |
   | tags              | []                                                   |
   +-------------------+------------------------------------------------------+

   참고

   기본적으로 공급자 네트워크의 IPv6 서브넷은 상태 비저장 주소 자동 구성(SLAAC) 및 라우터 알림을 위해 물리적 네트워크 인프라를 사용합니다.

6. segment2 세그먼트에 하나의 IPv4 서브넷과 IPv6 서브넷 1개를 만듭니다.

   이 예에서 IPv4 서브넷은 198.51.100.0/24 를 사용합니다.

   예제

   $ openstack subnet create \
     --network multisegment1 --network-segment segment2 \
     --ip-version 4 --subnet-range 198.51.100.0/24 \
     multisegment1-segment2-v4

   샘플 출력

   +-------------------+--------------------------------------+
   | Field             | Value                                |
   +-------------------+--------------------------------------+
   | allocation_pools  | 198.51.100.2-198.51.100.254          |
   | cidr              | 198.51.100.0/24                      |
   | enable_dhcp       | True                                 |
   | gateway_ip        | 198.51.100.1                         |
   | id                | 242755c2-f5fd-4e7d-bd7a-342ca95e50b2 |
   | ip_version        | 4                                    |
   | name              | multisegment1-segment2-v4            |
   | network_id        | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9 |
   | revision_number   | 1                                    |
   | segment_id        | 053b7925-9a89-4489-9992-e164c8cc8763 |
   | tags              | []                                   |
   +-------------------+--------------------------------------+

   이 예에서 IPv6 서브넷은 fd00:198:51:100::/64 를 사용합니다.

   예제

   $ openstack subnet create \
     --network multisegment1 --network-segment segment2 \
     --ip-version 6 --subnet-range fd00:198:51:100::/64 \
     --ipv6-address-mode slaac multisegment1-segment2-v6

   샘플 출력

   +-------------------+--------------------------------------------------------+
   | Field             | Value                                                  |
   +-------------------+--------------------------------------------------------+
   | allocation_pools  | fd00:198:51:100::2-fd00:198:51:100:ffff:ffff:ffff:ffff |
   | cidr              | fd00:198:51:100::/64                                   |
   | enable_dhcp       | True                                                   |
   | gateway_ip        | fd00:198:51:100::1                                     |
   | id                | b884c40e-9cfe-4d1b-a085-0a15488e9441                   |
   | ip_version        | 6                                                      |
   | ipv6_address_mode | slaac                                                  |
   | ipv6_ra_mode      | None                                                   |
   | name              | multisegment1-segment2-v6                              |
   | network_id        | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9                   |
   | revision_number   | 1                                                      |
   | segment_id        | 053b7925-9a89-4489-9992-e164c8cc8763                   |
   | tags              | []                                                     |
   +-------------------+--------------------------------------------------------+

검증

1. 각 IPv4 서브넷이 하나 이상의 DHCP 에이전트와 연결되는지 확인합니다.

   $ openstack network agent list --agent-type dhcp --network multisegment1

   샘플 출력

   +--------------------------------------+------------+-------------+-------------------+-------+-------+--------------------+
   | ID                                   | Agent Type | Host        | Availability Zone | Alive | State | Binary             |
   +--------------------------------------+------------+-------------+-------------------+-------+-------+--------------------+
   | c904ed10-922c-4c1a-84fd-d928abaf8f55 | DHCP agent | compute0001 | nova              | :-)   | UP    | neutron-dhcp-agent |
   | e0b22cc0-d2a6-4f1c-b17c-27558e20b454 | DHCP agent | compute0101 | nova              | :-)   | UP    | neutron-dhcp-agent |
   +--------------------------------------+------------+-------------+-------------------+-------+-------+--------------------+

2. 계산 서비스 배치 API의 각 세그먼트 IPv4 서브넷에 대한 인벤토리가 생성되었는지 확인합니다.

   모든 세그먼트 ID에 대해 이 명령을 실행합니다.

   $ SEGMENT_ID=053b7925-9a89-4489-9992-e164c8cc8763
   $ openstack resource provider inventory list $SEGMENT_ID

   샘플 출력

   이 샘플 출력에서는 세그먼트 중 하나만 표시됩니다.

   +----------------+------------------+----------+----------+-----------+----------+-------+
   | resource_class | allocation_ratio | max_unit | reserved | step_size | min_unit | total |
   +----------------+------------------+----------+----------+-----------+----------+-------+
   | IPV4_ADDRESS   |              1.0 |        1 |        2 |         1 |        1 |    30 |
   +----------------+------------------+----------+----------+-----------+----------+-------+

3. Compute 서비스의 각 세그먼트에 대한 호스트 집계가 생성되었는지 확인합니다.

   $ openstack aggregate list

   샘플 출력

   이 예에서는 세그먼트 중 하나만 표시됩니다.

   +----+---------------------------------------------------------+-------------------+
   | Id | Name                                                    | Availability Zone |
   +----+---------------------------------------------------------+-------------------+
   | 10 | Neutron segment id 053b7925-9a89-4489-9992-e164c8cc8763 | None              |
   +----+---------------------------------------------------------+-------------------+

4. 하나 이상의 인스턴스를 시작합니다. 각 인스턴스는 특정 계산 노드에서 사용하는 세그먼트에 따라 IP 주소를 가져옵니다.

   참고

   포트 생성 요청에서 사용자가 고정 IP를 지정하면 해당 특정 IP가 포트에 즉시 할당됩니다. 그러나 포트를 만들어 인스턴스에 전달하면 기존 네트워크와 다른 동작이 생성됩니다. port create 요청에 고정 IP가 지정되지 않은 경우 Networking 서비스는 특정 계산 노드가 명확하게 표시될 때까지 포트에 IP 주소를 디스퍼스 할당합니다. 예를 들어 이 명령을 실행하는 경우 다음을 수행합니다.

   $ openstack port create --network multisegment1 port1

   샘플 출력

   +-----------------------+--------------------------------------+
   | Field                 | Value                                |
   +-----------------------+--------------------------------------+
   | admin_state_up        | UP                                   |
   | binding_vnic_type     | normal                               |
   | id                    | 6181fb47-7a74-4add-9b6b-f9837c1c90c4 |
   | ip_allocation         | deferred                             |
   | mac_address           | fa:16:3e:34:de:9b                    |
   | name                  | port1                                |
   | network_id            | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9 |
   | port_security_enabled | True                                 |
   | revision_number       | 1                                    |
   | security_groups       | e4fcef0d-e2c5-40c3-a385-9c33ac9289c5 |
   | status                | DOWN                                 |
   | tags                  | []                                   |
   +-----------------------+--------------------------------------+

절차

1. 마이그레이션 중인 네트워크의 경우 현재 네트워크 세그먼트의 ID를 가져옵니다.

   예제

   $ openstack network segment list --network my_network

   샘플 출력

   +--------------------------------------+------+--------------------------------------+--------------+---------+
   | ID                                   | Name | Network                              | Network Type | Segment |
   +--------------------------------------+------+--------------------------------------+--------------+---------+
   | 81e5453d-4c9f-43a5-8ddf-feaf3937e8c7 | None | 45e84575-2918-471c-95c0-018b961a2984 | flat         | None    |
   +--------------------------------------+------+--------------------------------------+--------------+---------+

2. 마이그레이션 중인 네트워크의 경우 현재 서브넷의 ID를 가져옵니다.

   예제

   $ openstack network segment list --network my_network

   샘플 출력

   +--------------------------------------+-----------+--------------------------------------+---------------+
   | ID                                   | Name      | Network                              | Subnet        |
   +--------------------------------------+-----------+--------------------------------------+---------------+
   | 71d931d2-0328-46ae-93bc-126caf794307 | my_subnet | 45e84575-2918-471c-95c0-018b961a2984 | 172.24.4.0/24 |
   +--------------------------------------+-----------+--------------------------------------+---------------+

3. 서브넷의 현재 segment_id 값이 None 인지 확인합니다.

   예제

   $ openstack subnet show my_subnet --c segment_id

   샘플 출력

   +------------+-------+
   | Field      | Value |
   +------------+-------+
   | segment_id | None  |
   +------------+-------+

4. subnet _id 서브넷 값을 네트워크 세그먼트 ID로 변경합니다.

   예를 들면 다음과 같습니다.

   $ openstack subnet set --network-segment 81e5453d-4c9f-43a5-8ddf-feaf3937e8c7 my_subnet