高度なネットワーキング

手順

1. ハードウェア MTU の設定を準備します。

   • ハードウェア MTU が DHCP で指定されている場合は、次の dnsmasq 設定などで DHCP 設定を更新します。

     dhcp-option-force=26,<mtu>

     ここでは、以下のようになります。

     <mtu>

     DHCP サーバーがアドバタイズするハードウェア MTU を指定します。

   • ハードウェア MTU が PXE を使用したカーネルコマンドラインで指定されている場合は、それに応じてその設定を更新します。

   • ハードウェア MTU が NetworkManager 接続設定で指定されている場合は、以下のステップを実行します。OpenShift Container Platform では、これは、DHCP、カーネルコマンドラインなどの方法でネットワーク設定を明示的に指定していない場合のデフォルトのアプローチです。変更なしで次の手順を機能させるには、全クラスターノードで、同じ基盤となるネットワーク設定を使用する必要があります。

     1. 次のコマンドを入力して、プライマリーネットワークインターフェイスを見つけます。

        $ oc debug node/<node_name> -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0

        ここでは、以下のようになります。

        <node_name>

        クラスター内のノードの名前を指定します。

     2. <interface>-mtu.conf ファイルに次の NetworkManager 設定を作成します。

        [connection-<interface>-mtu]
        match-device=interface-name:<interface>
        ethernet.mtu=<mtu>

        ここでは、以下のようになります。

        <interface>

        プライマリーネットワークインターフェイス名を指定します。

        <mtu>

        新しいハードウェア MTU 値を指定します。

手順

1. 1 つはコントロールプレーンノード用、もう 1 つはクラスター内のワーカーノード用に、2 つの MachineConfig オブジェクトを作成します。

   1. control-plane-interface.bu ファイルに次の Butane 設定を作成します。

      注記

      設定ファイルで指定する Butane のバージョン は、OpenShift Container Platform のバージョンと同じである必要があり、末尾は常に 0 です。たとえば、4.20.0 などです。Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。

      variant: openshift
      version: 4.20.0
      metadata:
        name: 01-control-plane-interface
        labels:
          machineconfiguration.openshift.io/role: master
      storage:
        files:
          - path: /etc/NetworkManager/conf.d/99-<interface>-mtu.conf
            contents:
              local: <interface>-mtu.conf
            mode: 0600

      ここでは、以下のようになります。

      ストレージファイルパス

      プライマリーネットワークインターフェイスの NetworkManager 接続名を指定します。

      ストレージ.ファイル.ローカル

      前のステップで更新された NetworkManager 設定ファイルのローカルファイル名を指定します。

   2. worker-interface.bu ファイルに次の Butane 設定を作成します。

      注記

      設定ファイルで指定する Butane のバージョン は、OpenShift Container Platform のバージョンと同じである必要があり、末尾は常に 0 です。たとえば、4.20.0 などです。Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。

      variant: openshift
      version: 4.20.0
      metadata:
        name: 01-worker-interface
        labels:
          machineconfiguration.openshift.io/role: worker
      storage:
        files:
          - path: /etc/NetworkManager/conf.d/99-<interface>-mtu.conf
            contents:
              local: <interface>-mtu.conf
            mode: 0600

      ここでは、以下のようになります。

      ストレージファイルパス

      プライマリーネットワークインターフェイスの NetworkManager 接続名を指定します。

      ストレージ.ファイル.ローカル

      前のステップで更新された NetworkManager 設定ファイルのローカルファイル名を指定します。

2. 次のコマンドを実行して、Butane 設定から MachineConfig オブジェクトを作成します。

   $ for manifest in control-plane-interface worker-interface; do
       butane --files-dir . $manifest.bu > $manifest.yaml
     done

   警告

   これらのマシン設定は、後で明示的に指示されるまで適用しないでください。これらのマシン設定を適用すると、クラスターの安定性が失われます。

手順

1. MTU の移行を開始するには、次のコマンドを入力して移行設定を指定します。Machine Config Operator は、MTU の変更に備えて、クラスター内のノードをローリングリブートします。

   $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
     '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'

   ここでは、以下のようになります。

   <overlay_from>

   現在のクラスターネットワークの MTU 値を指定します。

   <overlay_to>

   クラスターネットワークのターゲット MTU を指定します。この値は、<machine_to> の値を基準にして設定します。OVN-Kubernetes の場合、この値は <machine_to> の値から 100 を引いた値である必要があります。

   <machine_to>

   基盤となるホストネットワークのプライマリーネットワークインターフェイスの MTU を指定します。

   $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
     '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'

2. Machine Config Operator は、各マシン設定プール内のマシンを更新するときに、各ノードを 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。

   $ oc get machineconfigpools

   正常に更新されたノードには、UPDATED=true、UPDATING=false、DEGRADED=false のステータスがあります。

   注記

   Machine Config Operator は、デフォルトでプールごとに 1 つずつマシンを更新するため、クラスターのサイズに応じて移行にかかる合計時間が増加します。

手順

1. 基盤となるネットワークインターフェイスの MTU 値を更新します。

   • NetworkManager 接続設定で新しい MTU を指定する場合は、次のコマンドを入力します。MachineConfig Operator は、クラスター内のノードのローリングリブートを自動的に実行します。

     $ for manifest in control-plane-interface worker-interface; do
         oc create -f $manifest.yaml
       done

   • DHCP サーバーオプションまたはカーネルコマンドラインと PXE を使用して新しい MTU を指定する場合は、インフラストラクチャーに必要な変更を加えます。

2. Machine Config Operator は、各マシン設定プール内のマシンを更新するときに、各ノードを 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。

   $ oc get machineconfigpools

   正常に更新されたノードには、UPDATED=true、UPDATING=false、DEGRADED=false のステータスがあります。

   注記

   Machine Config Operator は、デフォルトでプールごとに 1 つずつマシンを更新するため、クラスターのサイズに応じて移行にかかる合計時間が増加します。

3. ホスト上の新規マシン設定のステータスを確認します。

   1. マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。

      $ oc describe node | egrep "hostname|machineconfig"

      出力例

      kubernetes.io/hostname=master-0
      machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/reason:
      machineconfiguration.openshift.io/state: Done

      以下のステートメントが true であることを確認します。

      • machineconfiguration.openshift.io/state フィールドの値は Done です。
      • machineconfiguration.openshift.io/currentConfig フィールドの値は、machineconfiguration.openshift.io/desiredConfig フィールドの値と等しくなります。

   2. マシン設定が正しいことを確認するには、以下のコマンドを入力します。

      $ oc get machineconfig <config_name> -o yaml | grep path:

      ここでは、以下のようになります。

      <config_name>

      machineconfiguration.openshift.io/currentConfig フィールドからマシン設定の名前を指定します。

      マシン設定が正常にデプロイされた場合、前の出力には /etc/NetworkManager/conf.d/99-<interface>-mtu.conf ファイルパスと ExecStart=/usr/local/bin/mtu-migration.sh 行が含まれます。

手順

1. MTU の移行を完了するために、OVN-Kubernetes ネットワークプラグインに対して次のコマンドを入力します。

   $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
     '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'

   ここでは、以下のようになります。

   <mtu>

   <overlay_to> で指定した新しいクラスターネットワーク MTU を指定します。

2. MTU の移行が完了すると、各マシン設定プールノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。

   $ oc get machineconfigpools

   正常に更新されたノードには、UPDATED=true、UPDATING=false、DEGRADED=false のステータスがあります。

検証

1. クラスターネットワークの現在の MTU を取得するには、次のコマンドを入力します。

   $ oc describe network.config cluster

2. ノードのプライマリーネットワークインターフェイスの現在の MTU を取得します。

   1. クラスター内のノードをリスト表示するには、次のコマンドを入力します。

      $ oc get nodes

   2. ノードのプライマリーネットワークインターフェイスの現在の MTU 設定を取得するには、次のコマンドを入力します。

      $ oc adm node-logs <node> -u ovs-configuration | grep configure-ovs.sh | grep mtu | grep <interface> | head -1

      ここでは、以下のようになります。

      <node>

      前のステップの出力をもとに、ノードを指定します。

      <interface>

      ノードのプライマリーネットワークインターフェイス名を指定します。

      出力例

      ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051

手順

1. クラスター内に存在するベアメタルホストごとに、クラスターの install-config.yaml ファイルで、次の例のように networkConfig セクションを定義します。

   # ...
   networkConfig:
     interfaces:
       - name: enp1s0
         type: ethernet
         state: up
         ipv4:
           dhcp: true
           enabled: true
         ipv6:
           enabled: false
       - name: enp2s0
         type: ethernet
         state: up
         mtu: 1500
         ipv4:
           dhcp: true
           enabled: true
         ipv6:
           dhcp: true
           enabled: true
       - name: enp3s0
         type: ethernet
         state: up
         mtu: 1500
         ipv4:
           enabled: false
         ipv6:
           enabled: false
   # ...

   ここでは、以下のようになります。

   enp1s0

   プロビジョニングされるネットワークインターフェイスコントローラー (NIC) のインターフェイス。

   enp2s0

   ボンディングインターフェイス用の Ignition 設定ファイルを取り込む最初のボンディングされたインターフェイス。

   mtu

   ボンディングポートの br-ex 最大伝送単位 (MTU) を手動で設定します。

   enp3s0

   2 つ目のボンディングされたインターフェイスは、クラスターのインストール中に Ignition を実行する最小設定の一部です。

2. NMState 設定ファイルで各ネットワークインターフェイスを定義します。

   多数のネットワークインターフェイスを定義する NMState 設定ファイルの例

   ovn:
     bridge-mappings:
       - localnet: localnet-network
         bridge: br-ex
         state: present
   interfaces:
     - name: br-ex
       type: ovs-bridge
       state: up
       bridge:
         allow-extra-patch-ports: true
         port:
           - name: br-ex
           - name: patch-ex-to-phy
       ovs-db:
         external_ids:
           bridge-uplink: "patch-ex-to-phy"
     - name: br-ex
       type: ovs-interface
       state: up
       mtu: 1500
       ipv4:
         enabled: true
         dhcp: true
         auto-route-metric: 48
       ipv6:
         enabled: false
         dhcp: false
         auto-route-metric: 48
     - name: br-phy
       type: ovs-bridge
       state: up
       bridge:
         allow-extra-patch-ports: true
         port:
           - name: patch-phy-to-ex
           - name: ovs-bond
             link-aggregation:
               mode: balance-slb
               port:
                 - name: enp2s0
                 - name: enp3s0
     - name: patch-ex-to-phy
       type: ovs-interface
       state: up
       patch:
         peer: patch-phy-to-ex
     - name: patch-phy-to-ex
       type: ovs-interface
       state: up
       patch:
         peer: patch-ex-to-phy
     - name: enp1s0
       type: ethernet
       state: up
       ipv4:
         dhcp: true
         enabled: true
       ipv6:
         enabled: false
     - name: enp2s0
       type: ethernet
       state: up
       mtu: 1500
       ipv4:
         enabled: false
       ipv6:
         enabled: false
     - name: enp3s0
       type: ethernet
       state: up
       mtu: 1500
       ipv4:
         enabled: false
       ipv6:
         enabled: false
   # ...

   ここでは、以下のようになります。

   mtu

   ボンディングポートの br-ex MTU を手動で設定します。

3. base64 コマンドを使用して、NMState 設定ファイルのインターフェイスコンテンツをエンコードします。

   $ base64 -w0  <nmstate_configuration>.yml

   <nmstate_configuration>: -w0 オプションは、base64 エンコード操作中の行折り返しを防止します。

4. master ロールと worker ロールの MachineConfig マニフェストファイルを作成します。前のコマンドからの base64 エンコード文字列を各 MachineConfig マニフェストファイルに必ず埋め込んでください。次のマニフェストファイルの例では、クラスター内に存在するすべてのノードに対して master ロールを設定します。ノード固有の master ロールと worker ロールのマニフェストファイルを作成することもできます。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 10-br-ex-master
   spec:
     config:
       ignition:
         version: 3.2.0
       storage:
         files:
         - contents:
             source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration>
           mode: 0644
           overwrite: true
           path: /etc/nmstate/openshift/cluster.yml

   ここでは、以下のようになります。

   name

   ポリシーの名前。

   source

   エンコードされた base64 情報を指定されたパスに書き込みます。

   path

   cluster.yml ファイルへのパスを指定します。クラスター内の各ノードに対して、<node_short_hostname>.yml など、ノードへの短いホスト名パスを指定できます。

5. 各 MachineConfig マニフェストファイルを ./<installation_directory>/manifests ディレクトリーに保存します。<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーです。

   Machine Config Operator (MCO) が各マニフェストファイルからコンテンツを取得し、ローリング更新中に選択されたすべてのノードにそのコンテンツを一貫して適用します。

1. openshift-frr-k8s namespace を作成するには、次のコマンドを入力します。

   $ oc create namespace openshift-frr-k8s

2. 移行を自動化するには、次の内容のシェルスクリプトを migrate.sh という名前で作成します。

   #!/bin/bash
   OLD_NAMESPACE="metallb-system"
   NEW_NAMESPACE="openshift-frr-k8s"
   FILTER_OUT="metallb-"
   oc get frrconfigurations.frrk8s.metallb.io -n "${OLD_NAMESPACE}" -o json |\
     jq -r '.items[] | select(.metadata.name | test("'"${FILTER_OUT}"'") | not)' |\
     jq -r '.metadata.namespace = "'"${NEW_NAMESPACE}"'"' |\
     oc create -f -

3. 移行を実行するには、次のコマンドを実行します。

   $ bash migrate.sh

手順

1. 次のコマンドを実行して、RouteAdvertisements フィーチャーゲートが有効になっていることを確認します。

   $ oc get featuregate -oyaml | grep -i routeadvertisement

   出力例

         - name: RouteAdvertisements

2. 次のコマンドを実行して、Cluster Network Operator (CNO) を設定します。

   $ oc patch Network.operator.openshift.io cluster --type=merge \
     -p='
       {"spec":{
         "additionalRoutingCapabilities": {
           "providers": ["FRR"]},
           "defaultNetwork":{"ovnKubernetesConfig"{
             "routeAdvertisements":"Enabled"
             }}}}'

   CNO がすべてのノードを再起動するために数分かかる場合があります。

3. 次のコマンドを実行して、ノードの IP アドレスを取得します。

   $ oc get node -owide

   出力例

   NAME                                       STATUS   ROLES                  AGE   VERSION   INTERNAL-IP      EXTERNAL-IP   OS-IMAGE                                                KERNEL-VERSION                 CONTAINER-RUNTIME
   master-0                                   Ready    control-plane,master   27h   v1.31.3   192.168.111.20   <none>        Red Hat Enterprise Linux CoreOS 418.94.202501062026-0   5.14.0-427.50.1.el9_4.x86_64   cri-o://1.31.4-2.rhaos4.18.git33d7598.el9
   master-1                                   Ready    control-plane,master   27h   v1.31.3   192.168.111.21   <none>        Red Hat Enterprise Linux CoreOS 418.94.202501062026-0   5.14.0-427.50.1.el9_4.x86_64   cri-o://1.31.4-2.rhaos4.18.git33d7598.el9
   master-2                                   Ready    control-plane,master   27h   v1.31.3   192.168.111.22   <none>        Red Hat Enterprise Linux CoreOS 418.94.202501062026-0   5.14.0-427.50.1.el9_4.x86_64   cri-o://1.31.4-2.rhaos4.18.git33d7598.el9
   worker-0                                   Ready    worker                 27h   v1.31.3   192.168.111.23   <none>        Red Hat Enterprise Linux CoreOS 418.94.202501062026-0   5.14.0-427.50.1.el9_4.x86_64   cri-o://1.31.4-2.rhaos4.18.git33d7598.el9
   worker-1                                   Ready    worker                 27h   v1.31.3   192.168.111.24   <none>        Red Hat Enterprise Linux CoreOS 418.94.202501062026-0   5.14.0-427.50.1.el9_4.x86_64   cri-o://1.31.4-2.rhaos4.18.git33d7598.el9
   worker-2                                   Ready    worker                 27h   v1.31.3   192.168.111.25   <none>        Red Hat Enterprise Linux CoreOS 418.94.202501062026-0   5.14.0-427.50.1.el9_4.x86_64   cri-o://1.31.4-2.rhaos4.18.git33d7598.el9

4. 次のコマンドを実行して、各ノードのデフォルトの Pod ネットワークを取得します。

   $ oc get node <node_name> -o=jsonpath={.metadata.annotations.k8s\\.ovn\\.org/node-subnets}

   出力例

   {"default":["10.129.0.0/23"],"ns1.udn-network-primary-layer3":["10.150.6.0/24"]}

5. 次のコマンドを実行して、ベアメタルハイパーバイザーで、使用する外部 FRR コンテナーの IP アドレスを取得します。

   $ ip -j -d route get <a cluster node's IP> | jq -r '.[] | .dev' | xargs ip -d -j address show | jq -r '.[] | .addr_info[0].local'

6. 次の例に示すように、各ノードの IP アドレスが含まれる FRR 用の frr.conf ファイルを作成します。

   frr.conf 設定ファイルの例

   router bgp 64512
    no bgp default ipv4-unicast
    no bgp default ipv6-unicast
    no bgp network import-check
    neighbor 192.168.111.20 remote-as 64512
    neighbor 192.168.111.20 route-reflector-client
    neighbor 192.168.111.21 remote-as 64512
    neighbor 192.168.111.21 route-reflector-client
    neighbor 192.168.111.22 remote-as 64512
    neighbor 192.168.111.22 route-reflector-client
    neighbor 192.168.111.40 remote-as 64512
    neighbor 192.168.111.40 route-reflector-client
    neighbor 192.168.111.47 remote-as 64512
    neighbor 192.168.111.47 route-reflector-client
    neighbor 192.168.111.23 remote-as 64512
    neighbor 192.168.111.23 route-reflector-client
    neighbor 192.168.111.24 remote-as 64512
    neighbor 192.168.111.24 route-reflector-client
    neighbor 192.168.111.25 remote-as 64512
    neighbor 192.168.111.25 route-reflector-client
    address-family ipv4 unicast
     network 192.168.1.0/24
     network 192.169.1.1/32
    exit-address-family
    address-family ipv4 unicast
     neighbor 192.168.111.20 activate
     neighbor 192.168.111.20 next-hop-self
     neighbor 192.168.111.21 activate
     neighbor 192.168.111.21 next-hop-self
     neighbor 192.168.111.22 activate
     neighbor 192.168.111.22 next-hop-self
     neighbor 192.168.111.40 activate
     neighbor 192.168.111.40 next-hop-self
     neighbor 192.168.111.47 activate
     neighbor 192.168.111.47 next-hop-self
     neighbor 192.168.111.23 activate
     neighbor 192.168.111.23 next-hop-self
     neighbor 192.168.111.24 activate
     neighbor 192.168.111.24 next-hop-self
     neighbor 192.168.111.25 activate
     neighbor 192.168.111.25 next-hop-self
    exit-address-family
    neighbor  remote-as 64512
    neighbor  route-reflector-client
    address-family ipv6 unicast
     network 2001:db8::/128
    exit-address-family
    address-family ipv6 unicast
     neighbor  activate
     neighbor  next-hop-self
    exit-address-family

7. 次の内容が含まれるファイルを、daemons という名前で作成します。

   daemons 設定ファイルの例

   # This file tells the frr package which daemons to start.
   #
   # Sample configurations for these daemons can be found in
   # /usr/share/doc/frr/examples/.
   #
   # ATTENTION:
   #
   # When activating a daemon for the first time, a config file, even if it is
   # empty, has to be present *and* be owned by the user and group "frr", else
   # the daemon will not be started by /etc/init.d/frr. The permissions should
   # be u=rw,g=r,o=.
   # When using "vtysh" such a config file is also needed. It should be owned by
   # group "frrvty" and set to ug=rw,o= though. Check /etc/pam.d/frr, too.
   #
   # The watchfrr and zebra daemons are always started.
   #
   bgpd=yes
   ospfd=no
   ospf6d=no
   ripd=no
   ripngd=no
   isisd=no
   pimd=no
   ldpd=no
   nhrpd=no
   eigrpd=no
   babeld=no
   sharpd=no
   pbrd=no
   bfdd=yes
   fabricd=no
   vrrpd=no
   
   #
   # If this option is set the /etc/init.d/frr script automatically loads
   # the config via "vtysh -b" when the servers are started.
   # Check /etc/pam.d/frr if you intend to use "vtysh"!
   #
   vtysh_enable=yes
   zebra_options="  -A 127.0.0.1 -s 90000000"
   bgpd_options="   -A 127.0.0.1"
   ospfd_options="  -A 127.0.0.1"
   ospf6d_options=" -A ::1"
   ripd_options="   -A 127.0.0.1"
   ripngd_options=" -A ::1"
   isisd_options="  -A 127.0.0.1"
   pimd_options="   -A 127.0.0.1"
   ldpd_options="   -A 127.0.0.1"
   nhrpd_options="  -A 127.0.0.1"
   eigrpd_options=" -A 127.0.0.1"
   babeld_options=" -A 127.0.0.1"
   sharpd_options=" -A 127.0.0.1"
   pbrd_options="   -A 127.0.0.1"
   staticd_options="-A 127.0.0.1"
   bfdd_options="   -A 127.0.0.1"
   fabricd_options="-A 127.0.0.1"
   vrrpd_options="  -A 127.0.0.1"
   
   # configuration profile
   #
   #frr_profile="traditional"
   #frr_profile="datacenter"
   
   #
   # This is the maximum number of FD's that will be available.
   # Upon startup this is read by the control files and ulimit
   # is called. Uncomment and use a reasonable value for your
   # setup if you are expecting a large number of peers in
   # say BGP.
   #MAX_FDS=1024
   
   # The list of daemons to watch is automatically generated by the init script.
   #watchfrr_options=""
   
   # for debugging purposes, you can specify a "wrap" command to start instead
   # of starting the daemon directly, e.g. to use valgrind on ospfd:
   #   ospfd_wrap="/usr/bin/valgrind"
   # or you can use "all_wrap" for all daemons, e.g. to use perf record:
   #   all_wrap="/usr/bin/perf record --call-graph -"
   # the normal daemon command is added to this at the end.

8. frr.conf ファイルと daemons ファイルの両方を、同じディレクトリー (例: /tmp/frr) に保存します。

9. 次のコマンドを実行して、外部 FRR コンテナーを作成します。

   $ sudo podman run -d --privileged --network host --rm --ulimit core=-1 --name frr --volume /tmp/frr:/etc/frr quay.io/frrouting/frr:9.1.0

10. 次の FRRConfiguration 設定および RouteAdvertisements 設定を作成します。

    1. 次の内容で receive_all.yaml ファイルを作成します。

       receive_all.yaml 設定ファイルの例

       apiVersion: frrk8s.metallb.io/v1beta1
       kind: FRRConfiguration
       metadata:
         name: receive-all
         namespace: openshift-frr-k8s
       spec:
         bgp:
           routers:
           - asn: 64512
             neighbors:
             - address: 192.168.111.1
               asn: 64512
               toReceive:
                 allowed:
                   mode: all

    2. 次の内容で ra.yaml ファイルを作成します。

       ra.yaml 設定ファイルの例

       apiVersion: k8s.ovn.org/v1
       kind: RouteAdvertisements
       metadata:
         name: default
       spec:
         nodeSelector: {}
         frrConfigurationSelector: {}
         networkSelectors:
         - networkSelectionType: DefaultNetwork
         advertisements:
         - "PodNetwork"
         - "EgressIP"

11. 次のコマンドを実行して、receive_all.yaml ファイルと ra.yaml ファイルを適用します。

    $ for f in receive_all.yaml ra.yaml; do oc apply -f $f; done

検証

1. 設定が適用されたか検証します。

   1. 次のコマンドを実行して、FRRConfiguration 設定が作成されたか検証します。

      $ oc get frrconfiguration -A

      出力例

      NAMESPACE           NAME                   AGE
      openshift-frr-k8s   ovnk-generated-6lmfb   4h47m
      openshift-frr-k8s   ovnk-generated-bhmnm   4h47m
      openshift-frr-k8s   ovnk-generated-d2rf5   4h47m
      openshift-frr-k8s   ovnk-generated-f958l   4h47m
      openshift-frr-k8s   ovnk-generated-gmsmw   4h47m
      openshift-frr-k8s   ovnk-generated-kmnqg   4h47m
      openshift-frr-k8s   ovnk-generated-wpvgb   4h47m
      openshift-frr-k8s   ovnk-generated-xq7v6   4h47m
      openshift-frr-k8s   receive-all            4h47m

   2. 次のコマンドを実行して、RouteAdvertisements 設定が作成されたか検証します。

      $ oc get ra -A

      出力例

      NAME      STATUS
      default   Accepted

2. 次のコマンドを実行して、外部 FRR コンテナー ID を取得します。

   $ sudo podman ps | grep frr

   出力例

   22cfc713890e  quay.io/frrouting/frr:9.1.0              /usr/lib/frr/dock...  5 hours ago   Up 5 hours ago               frr

3. 前のステップで取得したコンテナー ID を使用して、外部 FRR コンテナーの vtysh セッションで近隣の BGP とルートを確認します。以下のコマンドを実行します。

   $ sudo podman exec -it <container_id> vtysh -c "show ip bgp"

   出力例

   BGP table version is 10, local router ID is 192.168.111.1, vrf id 0
   Default local pref 100, local AS 64512
   Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
                  i internal, r RIB-failure, S Stale, R Removed
   Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
   Origin codes:  i - IGP, e - EGP, ? - incomplete
   RPKI validation codes: V valid, I invalid, N Not found
   
       Network          Next Hop            Metric LocPrf Weight Path
    *>i10.128.0.0/23    192.168.111.22           0    100      0 i
    *>i10.128.2.0/23    192.168.111.23           0    100      0 i
    *>i10.129.0.0/23    192.168.111.20           0    100      0 i
    *>i10.129.2.0/23    192.168.111.24           0    100      0 i
    *>i10.130.0.0/23    192.168.111.21           0    100      0 i
    *>i10.130.2.0/23    192.168.111.40           0    100      0 i
    *>i10.131.0.0/23    192.168.111.25           0    100      0 i
    *>i10.131.2.0/23    192.168.111.47           0    100      0 i
    *> 192.168.1.0/24   0.0.0.0                  0         32768 i
    *> 192.169.1.1/32   0.0.0.0                  0         32768 i

4. 次のコマンドを実行して、各クラスターノードの frr-k8s Pod を見つけます。

   $ oc -n openshift-frr-k8s get pod -owide

   出力例

   NAME                                      READY   STATUS    RESTARTS   AGE   IP               NODE                                       NOMINATED NODE   READINESS GATES
   frr-k8s-86wmq                             6/6     Running   0          25h   192.168.111.20   master-0                                   <none>           <none>
   frr-k8s-h2wl6                             6/6     Running   0          25h   192.168.111.21   master-1                                   <none>           <none>
   frr-k8s-jlbgs                             6/6     Running   0          25h   192.168.111.40   node1.example.com   <none>           <none>
   frr-k8s-qc6l5                             6/6     Running   0          25h   192.168.111.25   worker-2                                   <none>           <none>
   frr-k8s-qtxdc                             6/6     Running   0          25h   192.168.111.47   node2.example.com   <none>           <none>
   frr-k8s-s5bxh                             6/6     Running   0          25h   192.168.111.24   worker-1                                   <none>           <none>
   frr-k8s-szgj9                             6/6     Running   0          25h   192.168.111.22   master-2                                   <none>           <none>
   frr-k8s-webhook-server-6cd8b8d769-kmctw   1/1     Running   0          25h   10.131.2.9       node3.example.com   <none>           <none>
   frr-k8s-zwmgh                             6/6     Running   0          25h   192.168.111.23   worker-0                                   <none>           <none>

5. 次のコマンドを実行して、OpenShift Container Platform クラスターから、FRR コンテナー内にあるクラスターノードの frr-k8s Pod 上の BGP ルートを確認します。

   $ oc -n openshift-frr-k8s -c frr rsh frr-k8s-86wmq

6. 次のコマンドを実行して、クラスターノードからの IP ルートを確認します。

   sh-5.1# vtysh

   出力例

   Hello, this is FRRouting (version 8.5.3).
   Copyright 1996-2005 Kunihiro Ishiguro, et al.

7. 次のコマンドを実行して、IP ルートを確認します。

   worker-2# show ip bgp

   出力例

   BGP table version is 10, local router ID is 192.168.111.25, vrf id 0
   Default local pref 100, local AS 64512
   Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
                  i internal, r RIB-failure, S Stale, R Removed
   Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
   Origin codes:  i - IGP, e - EGP, ? - incomplete
   RPKI validation codes: V valid, I invalid, N Not found
   
       Network          Next Hop            Metric LocPrf Weight Path
    *>i10.128.0.0/23    192.168.111.22           0    100      0 i
    *>i10.128.2.0/23    192.168.111.23           0    100      0 i
    *>i10.129.0.0/23    192.168.111.20           0    100      0 i
    *>i10.129.2.0/23    192.168.111.24           0    100      0 i
    *>i10.130.0.0/23    192.168.111.21           0    100      0 i
    *>i10.130.2.0/23    192.168.111.40           0    100      0 i
    *> 10.131.0.0/23    0.0.0.0                  0         32768 i
    *>i10.131.2.0/23    192.168.111.47           0    100      0 i
    *>i192.168.1.0/24   192.168.111.1            0    100      0 i
    *>i192.169.1.1/32   192.168.111.1            0    100      0 i
   
   Displayed  10 routes and 10 total paths

8. 次のコマンドを実行して、OpenShift Container Platform クラスターからノードをデバッグします。

   $ oc debug node/<node_name>

   出力例

   Temporary namespace openshift-debug-lbtgh is created for debugging node...
   Starting pod/worker-2-debug-zrg4v ...
   To use host binaries, run `chroot /host`
   Pod IP: 192.168.111.25
   If you don't see a command prompt, try pressing enter.

9. 次のコマンドを実行して、BGP ルートがアドバタイズされていることを確認します。

   sh-5.1# ip route show | grep bgp

   出力例

   10.128.0.0/23 nhid 268 via 192.168.111.22 dev br-ex proto bgp metric 20
   10.128.2.0/23 nhid 259 via 192.168.111.23 dev br-ex proto bgp metric 20
   10.129.0.0/23 nhid 260 via 192.168.111.20 dev br-ex proto bgp metric 20
   10.129.2.0/23 nhid 261 via 192.168.111.24 dev br-ex proto bgp metric 20
   10.130.0.0/23 nhid 266 via 192.168.111.21 dev br-ex proto bgp metric 20
   10.130.2.0/23 nhid 262 via 192.168.111.40 dev br-ex proto bgp metric 20
   10.131.2.0/23 nhid 263 via 192.168.111.47 dev br-ex proto bgp metric 20
   192.168.1.0/24 nhid 264 via 192.168.111.1 dev br-ex proto bgp metric 20
   192.169.1.1 nhid 264 via 192.168.111.1 dev br-ex proto bgp metric 20

手順

1. PTP Operator の namespace を作成します。

   1. 次の YAML を ptp-namespace.yaml ファイルに保存します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-ptp
        annotations:
          workload.openshift.io/allowed: management
        labels:
          name: openshift-ptp
          openshift.io/cluster-monitoring: "true"

   2. Namespace CR を作成します。

      $ oc create -f ptp-namespace.yaml

2. PTP Operator の Operator グループを作成します。

   1. 次の YAML を ptp-operatorgroup.yaml ファイルに保存します。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: ptp-operators
        namespace: openshift-ptp
      spec:
        targetNamespaces:
        - openshift-ptp

   2. OperatorGroup CR を作成します。

      $ oc create -f ptp-operatorgroup.yaml

3. PTP Operator にサブスクライブします。

   1. 次の YAML を ptp-sub.yaml ファイルに保存します。

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: ptp-operator-subscription
        namespace: openshift-ptp
      spec:
        channel: "stable"
        name: ptp-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace

   2. Subscription CR を作成します。

      $ oc create -f ptp-sub.yaml

4. Operator がインストールされていることを確認するには、以下のコマンドを入力します。

   $ oc get csv -n openshift-ptp -o custom-columns=Name:.metadata.name,Phase:.status.phase

   出力例

   Name                         Phase
   4.20.0-202301261535          Succeeded

手順

1. OpenShift Container Platform Web コンソールを使用して PTP Operator をインストールします。

   1. OpenShift Container Platform Web コンソールで、Ecosystem → Software Catalog をクリックします。
   2. 利用可能な Operator のリストから PTP Operator を選択してから Install をクリックします。
   3. Install Operator ページの A specific namespace on the cluster の下で openshift-ptp を選択します。次に、Install をクリックします。

2. オプション: PTP Operator が正常にインストールされていることを確認します。

   1. Ecosystem → Installed Operators ページに切り替えます。

   2. PTP Operator が Status が InstallSucceeded の状態で openshift-ptp プロジェクトにリスト表示されていることを確認します。

      注記

      インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。

      Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。

      • Ecosystem → Installed Operators ページに移動し、Operator Subscriptions および Install Plans タブで Status にエラーがあるかどうかを検査します。
      • Workloads → Pods ページに移動し、openshift-ptp プロジェクトで Pod のログを確認します。

手順

1. PtpConfig CR を作成します。以下に例を示します。

   1. 要件に応じて、デプロイメントに次の T-GM 設定のいずれかを使用します。YAML を grandmaster-clock-ptp-config.yaml ファイルに保存します。

      apiVersion: ptp.openshift.io/v1
      kind: PtpConfig
      metadata:
        name: grandmaster
        namespace: openshift-ptp
        annotations: {}
      spec:
        profile:
          - name: "grandmaster"
            ptp4lOpts: "-2 --summary_interval -4"
            phc2sysOpts: -r -u 0 -m -N 8 -R 16 -s $iface_master -n 24
            ptpSchedulingPolicy: SCHED_FIFO
            ptpSchedulingPriority: 10
            ptpSettings:
              logReduce: "true"
            plugins:
              e810:
                enableDefaultConfig: false
                settings:
                  LocalMaxHoldoverOffSet: 1500
                  LocalHoldoverTimeout: 14400
                  MaxInSpecOffset: 1500
                pins: $e810_pins
                #  "$iface_master":
                #    "U.FL2": "0 2"
                #    "U.FL1": "0 1"
                #    "SMA2": "0 2"
                #    "SMA1": "0 1"
                ublxCmds:
                  - args: #ubxtool -P 29.20 -z CFG-HW-ANT_CFG_VOLTCTRL,1
                      - "-P"
                      - "29.20"
                      - "-z"
                      - "CFG-HW-ANT_CFG_VOLTCTRL,1"
                    reportOutput: false
                  - args: #ubxtool -P 29.20 -e GPS
                      - "-P"
                      - "29.20"
                      - "-e"
                      - "GPS"
                    reportOutput: false
                  - args: #ubxtool -P 29.20 -d Galileo
                      - "-P"
                      - "29.20"
                      - "-d"
                      - "Galileo"
                    reportOutput: false
                  - args: #ubxtool -P 29.20 -d GLONASS
                      - "-P"
                      - "29.20"
                      - "-d"
                      - "GLONASS"
                    reportOutput: false
                  - args: #ubxtool -P 29.20 -d BeiDou
                      - "-P"
                      - "29.20"
                      - "-d"
                      - "BeiDou"
                    reportOutput: false
                  - args: #ubxtool -P 29.20 -d SBAS
                      - "-P"
                      - "29.20"
                      - "-d"
                      - "SBAS"
                    reportOutput: false
                  - args: #ubxtool -P 29.20 -t -w 5 -v 1 -e SURVEYIN,600,50000
                      - "-P"
                      - "29.20"
                      - "-t"
                      - "-w"
                      - "5"
                      - "-v"
                      - "1"
                      - "-e"
                      - "SURVEYIN,600,50000"
                    reportOutput: true
                  - args: #ubxtool -P 29.20 -p MON-HW
                      - "-P"
                      - "29.20"
                      - "-p"
                      - "MON-HW"
                    reportOutput: true
                  - args: #ubxtool -P 29.20 -p CFG-MSG,1,38,248
                      - "-P"
                      - "29.20"
                      - "-p"
                      - "CFG-MSG,1,38,248"
                    reportOutput: true
            ts2phcOpts: " "
            ts2phcConf: |
              [nmea]
              ts2phc.master 1
              [global]
              use_syslog  0
              verbose 1
              logging_level 7
              ts2phc.pulsewidth 100000000
              #cat /dev/GNSS to find available serial port
              #example value of gnss_serialport is /dev/ttyGNSS_1700_0
              ts2phc.nmea_serialport $gnss_serialport
              [$iface_master]
              ts2phc.extts_polarity rising
              ts2phc.extts_correction 0
            ptp4lConf: |
              [$iface_master]
              masterOnly 1
              [$iface_master_1]
              masterOnly 1
              [$iface_master_2]
              masterOnly 1
              [$iface_master_3]
              masterOnly 1
              [global]
              #
              # Default Data Set
              #
              twoStepFlag 1
              priority1 128
              priority2 128
              domainNumber 24
              #utc_offset 37
              clockClass 6
              clockAccuracy 0x27
              offsetScaledLogVariance 0xFFFF
              free_running 0
              freq_est_interval 1
              dscp_event 0
              dscp_general 0
              dataset_comparison G.8275.x
              G.8275.defaultDS.localPriority 128
              #
              # Port Data Set
              #
              logAnnounceInterval -3
              logSyncInterval -4
              logMinDelayReqInterval -4
              logMinPdelayReqInterval 0
              announceReceiptTimeout 3
              syncReceiptTimeout 0
              delayAsymmetry 0
              fault_reset_interval -4
              neighborPropDelayThresh 20000000
              masterOnly 0
              G.8275.portDS.localPriority 128
              #
              # Run time options
              #
              assume_two_step 0
              logging_level 6
              path_trace_enabled 0
              follow_up_info 0
              hybrid_e2e 0
              inhibit_multicast_service 0
              net_sync_monitor 0
              tc_spanning_tree 0
              tx_timestamp_timeout 50
              unicast_listen 0
              unicast_master_table 0
              unicast_req_duration 3600
              use_syslog 1
              verbose 0
              summary_interval -4
              kernel_leap 1
              check_fup_sync 0
              clock_class_threshold 7
              #
              # Servo Options
              #
              pi_proportional_const 0.0
              pi_integral_const 0.0
              pi_proportional_scale 0.0
              pi_proportional_exponent -0.3
              pi_proportional_norm_max 0.7
              pi_integral_scale 0.0
              pi_integral_exponent 0.4
              pi_integral_norm_max 0.3
              step_threshold 2.0
              first_step_threshold 0.00002
              clock_servo pi
              sanity_freq_limit  200000000
              ntpshm_segment 0
              #
              # Transport options
              #
              transportSpecific 0x0
              ptp_dst_mac 01:1B:19:00:00:00
              p2p_dst_mac 01:80:C2:00:00:0E
              udp_ttl 1
              udp6_scope 0x0E
              uds_address /var/run/ptp4l
              #
              # Default interface options
              #
              clock_type BC
              network_transport L2
              delay_mechanism E2E
              time_stamping hardware
              tsproc_mode filter
              delay_filter moving_median
              delay_filter_length 10
              egressLatency 0
              ingressLatency 0
              boundary_clock_jbod 0
              #
              # Clock description
              #
              productDescription ;;
              revisionData ;;
              manufacturerIdentity 00:00:00
              userDescription ;
              timeSource 0x20
        recommend:
          - profile: "grandmaster"
            priority: 4
            match:
              - nodeLabel: "node-role.kubernetes.io/$mcp"

      注記

      E810 Westport Channel NIC の場合は、ts2phc.nmea_serialport の値を /dev/gnss0 に設定します。

   2. 以下のコマンドを実行して CR を作成します。

      $ oc create -f grandmaster-clock-ptp-config.yaml

検証

1. PtpConfig プロファイルがノードに適用されていることを確認します。

   1. 以下のコマンドを実行して、openshift-ptp namespace の Pod の一覧を取得します。

      $ oc get pods -n openshift-ptp -o wide

      出力例

      NAME                          READY   STATUS    RESTARTS   AGE     IP             NODE
      linuxptp-daemon-74m2g         3/3     Running   3          4d15h   10.16.230.7    compute-1.example.com
      ptp-operator-5f4f48d7c-x7zkf  1/1     Running   1          4d15h   10.128.1.145   compute-1.example.com

   2. プロファイルが正しいことを確認します。PtpConfig プロファイルで指定したノードに対応する linuxptp デーモンのログを検査します。以下のコマンドを実行します。

      $ oc logs linuxptp-daemon-74m2g -n openshift-ptp -c linuxptp-daemon-container

      出力例

      ts2phc[94980.334]: [ts2phc.0.config] nmea delay: 98690975 ns
      ts2phc[94980.334]: [ts2phc.0.config] ens3f0 extts index 0 at 1676577329.999999999 corr 0 src 1676577330.901342528 diff -1
      ts2phc[94980.334]: [ts2phc.0.config] ens3f0 master offset         -1 s2 freq      -1
      ts2phc[94980.441]: [ts2phc.0.config] nmea sentence: GNRMC,195453.00,A,4233.24427,N,07126.64420,W,0.008,,160223,,,A,V
      phc2sys[94980.450]: [ptp4l.0.config] CLOCK_REALTIME phc offset       943 s2 freq  -89604 delay    504
      phc2sys[94980.512]: [ptp4l.0.config] CLOCK_REALTIME phc offset      1000 s2 freq  -89264 delay    474