ネットワークの問題

この項では、アプライアンス・ネットワーキングのすべての側面に関連する既知の問題と回避策について説明します。これは、システム内部接続、データ・センターへの外部アップリンク、およびユーザーのコンピュート・インスタンスの仮想ネットワーキングです。

3.0.2-b1081557以上にアップグレードした後のBGPリンクへの影響の可能性

メッシュ構成でBGPを実行する場合、3.0.2-b1010555以降にアップグレードすると、BGPリンクにIDLE状態が表示されるか、接続されていない場合があります。 メッシュ構成でBGPを使用しており、現在3.0.2-b1010555より前のリリースを実行している場合は、Oracleサポートに連絡してください。Oracleサポートは、アップグレード前にアップリンク構成を更新および修正するのに役立ちます。 3.0.2-b1010555以降へのアップグレードがすでに実行されており、BGPリンクの状態がIDLEと表示されている場合は、アップグレード後に支援できるOracleサポートに連絡してください。

バグ: 36525352

バージョン: 3.0.2

DNSゾーン範囲を設定できません

DNSゾーンを作成または更新する場合、スコープを設定できません。 コマンドライン出力では、scopeプロパティの値はnullです。

バグ: 32998565

バージョン: 3.0.1

DNSレコードを更新するには、コマンドに既存の保護されたレコードを含める必要がある

DNSレコードを更新する場合、更新がこれらのレコードに影響を及ぼさない場合でも、既存のすべての保護レコードを更新コマンドに含める必要があります。 この要件は、既存の保護されたレコードが誤って削除されないようにすることを目的としています。 ただし、特定の更新の実現が困難なSOAレコードについては、チェックが非常に制限されています。

回避策: コマンドの一部としてSOAレコードを指定するか、SOAドメインを含まないようにドメインを設定することで、既存のレコードを更新できます。 実際には、ほとんどのレコード更新は上位レベルで行われ、これらの制限の影響を受けません。

バグ: 33089111

バージョン: 3.0.1

修正可能: 最新のパッチをシステムに適用してください。

混乱しているエラー・メッセージでルート表の作成に失敗

ルート表を作成し、ルート・ルール・パラメータに誤りがある場合、APIサーバーは誤解を招くエラー・メッセージを返すことがあります。 特定のメッセージが読み取る: 「ルート表ターゲットは、LPG、NATゲートウェイ、インターネット・ゲートウェイ、DRGアタッチメントまたはサービス・ゲートウェイのいずれかである必要があります。」可能なターゲットのリストで、DRGアタッチメントが正しくありません。 動的ルーティング・ゲートウェイ自体は、DRGアタッチメントではなくターゲットとして指定する必要があります。

回避策: 問題のエラー・メッセージは無視してください。 動的ルーティング・ゲートウェイを介してトラフィックを送信するようにルート・ルールを構成する場合は、DRGをターゲットとして指定します。

バグ: 33570320

バージョン: 3.0.1

リソース制限内でネットワーク・サービスが応答しない

ネットワーキング・リソースの構成制限は、アプライアンス・ソフトウェア・バージョン3.0.2-b1185392以前を実行する場合、ネットワーキング・サービス・アーキテクチャの機能を超える設定を許可します。 特に、それぞれ最大80個のVCNsと40個のサブネットの理論的な組合せによって、アンダー・レイ・ネットワークで管理できるデータ・フローが大幅に増加します。

したがって、構成がリソース制限の範囲内であっても、ネットワーキング・サービスには過剰な負荷の兆候が表示されることがあります。 そのサービス・ポッドはメモリー不足やクラッシュが発生し、リソースのリストをリクエストする場合でも、ネットワーク操作の実行時に内部サーバー・エラーが発生する可能性があります。

回避策: 内部サーバー・エラーは一時的であり、ネットワーキング・サービスは通常の操作を再開すると予想されます。 この問題が解決しない場合は、Oracleに問い合わせてください。

問題を回避するには、リリース・ノートの「サービス制限」章に記載されている更新されたリソース制限内にとどまります。 これらのより厳密な制限は、バージョン3.0.2-b1261765のアプライアンス・ソフトウェアによって強制されます。

バグ: 36906198

バージョン: 3.0.2

セキュリティ・ルールによってブロックされたファイル・ストレージ・トラフィック

ユーザーがインスタンスにファイル・システムをマウントできるようにするには、マウント・ターゲットとインスタンス間の必要なネットワーク・トラフィックを許可するために、デフォルト・セキュリティ・リスト内のものに加えてセキュリティ・ルールを構成する必要があります。 Oracle Private Cloud Applianceでのファイル・ストレージ・ポートおよびプロトコルの構成は、アンダー・レイ・ネットワーク・アーキテクチャによってさらに複雑になります。これは、セキュリティ・ルールのソースと宛先が特定の方法で設定されていないかぎり、ファイル・ストレージ・トラフィックを予期せずブロックできます。

「シナリオA」 - ファイル・システム・サービスを使用するマウント・ターゲットおよびインスタンスが同じサブネットに存在する場合は、デフォルト・セキュリティ・リストに加えて、セキュリティ・リストを作成してサブネットにアタッチします。 新しいセキュリティ・リストには、次のステートフル・ルールが含まれている必要があります。

+++ Ingress Rules ++++++++++++++++++++

Source            Protocol     Source Ports            Destination Ports
------            --------     ------------            -----------------
<subnet CIDR>     TCP          All                     111, 389, 445, 4045,
                                                       2048-2050, 20048
<subnet CIDR>     UDP          All                     111, 289, 445, 2048,
                                                       4045, 20048

+++ Egress Rules ++++++++++++++++++++

Destination       Protocol     Source Ports            Destination Ports
-----------       --------     ------------            -----------------
<subnet CIDR>     TCP          111, 389, 445, 4045,    All
                               2048-2050, 20048
<subnet CIDR>     TCP          All                     111, 389, 445, 4045,
                                                       2048-2050, 20048
<subnet CIDR>     UDP          111, 389, 445,          All
                               4045, 20048
<subnet CIDR>     UDP          All                     111, 389, 445,
                                                       4045, 20048

「シナリオB」 - ファイル・システム・サービスを使用するマウント・ターゲットおよびインスタンスが異なるサブネットに存在する場合は、サブネットごとに新しいセキュリティ・リストを作成し、デフォルト・セキュリティ・リストに加えて各サブネットにアタッチします。

マウント・ターゲットを含むサブネットの新しいセキュリティ・リストには、次のステートフル・ルールが含まれている必要があります:

+++ Ingress Rules ++++++++++++++++++++

Source                        Protocol     Source Ports            Destination Ports
------                        --------     ------------            -----------------
<instances subnet CIDR>       TCP          All                     111, 389, 445, 4045,
                                                                   2048-2050, 20048
<instances subnet CIDR>       UDP          All                     111, 289, 445, 2048,
                                                                   4045, 20048

+++ Egress Rules ++++++++++++++++++++

Destination                   Protocol     Source Ports            Destination Ports
-----------                   --------     ------------            -----------------
<instances subnet CIDR>       TCP          111, 389, 445, 4045,    All
                                           2048-2050, 20048
<instances subnet CIDR>       UDP          111, 389, 445,          All
                                           4045, 20048

ファイルシステム・サービスを使用したインスタンスを含むサブネットの新しいセキュリティ・リストには、次のステートフル・ルールが含まれている必要があります:

+++ Ingress Rules ++++++++++++++++++++

Source                        Protocol     Source Ports            Destination Ports
------                        --------     ------------            -----------------
<mount target subnet CIDR>    TCP          111, 389, 445, 4045,    All
                                           2048-2050, 20048
<mount target subnet CIDR>    UDP          111, 289, 445, 2048,    All
                                           4045, 20048

+++ Egress Rules ++++++++++++++++++++

Destination                   Protocol     Source Ports            Destination Ports
-----------                   --------     ------------            -----------------
<mount target subnet CIDR>    TCP          All                     111, 389, 445, 4045,
                                                                   2048-2050, 20048
<mount target subnet CIDR>    UDP          All                     111, 389, 445,
                                                                   4045, 20048

回避策: ここに示すガイドラインに従って、ファイル・システムのサービス・トラフィックを有効にするイングレスおよびエグレス・ルールを構成します。 未変更のデフォルト・セキュリティ・リストがすでに添付されている場合、提案されたエグレス・ルールを追加する必要はありません。これは、すべてのエグレス・トラフィック(宛先: 0.0.0.0/0、プロトコル: all)を許可するデフォルトのステートフル・セキュリティ・ルールがすでにあるためです。

バグ: 33680750

バージョン: 3.0.1

ステートフルおよびステートレス・セキュリティ・ルールは結合できません

アプライアンスでは、テナンシ内のステートフル・セキュリティ・ルールとステートレス・セキュリティ・ルールの組合せを構成できます。 これらのセキュリティ・ルールから生成されたアクセス制御リストは正しいですが、仮想アンダー・レイ・ネットワークで誤った解釈が発生する可能性があります。 その結果、特定のトラフィックがブロックされるか、誤って許可される可能性があります。 したがって、ステートフルまたはステートレスのセキュリティ・ルールを使用することをお薦めします。

回避策: この動作は予想されますが、バグとはみなされません。 可能な場合は常に、すべてのステートフルまたはすべてのステートレスのセキュリティ・ルールを作成します。

ノート:

特定のニーズがある場合は、ステートフル・ルールとステートレス・ルールを組み合せることができますが、ステートレス・ルールを使用する場合は対称である必要があります。つまり、ステートレス・エグレス・ルールと、同じフローにステートフル・イングレス・ルールを持つことはできません。

バグ: 33744232

バージョン: 3.0.1

システムの初期化中にCIDRとして構成されたパブリックIPでのルーティングの失敗

アプライアンスの初期設定ステップを完了すると(「Oracle Private Cloud Applianceインストレーション・ガイド」の章「Oracle Private Cloud Applianceの構成」「初期設定の完了」を参照)、最後のステップの1つは、クラウド・リソースにパブリックIPとして割り当てられるデータ・センターのIPアドレスを定義することです。 BGPベースの動的ルーティングを選択した場合、パブリックIPは1つ以上のCIDRとして定義されているときに正しく通知されないため、アプライアンスの外部から到達できないことがあります。

回避策: アプライアンスの外部からクラウド・リソースのパブリックIPに到達できるようにするには、 /32ネットマスクを使用してすべてのIPアドレスを個別に指定します。 たとえば、192.168.100.0/24,と入力するかわりに、カンマ区切りのリストを送信します: 192.168.100.1/32, 192.168.100.2/32, 192.168.100.3/32, 192.168.100.4/32,など。

バグ: 33765256

バージョン: 3.0.1

修正可能: 最新のパッチをシステムに適用してください。

管理ネットワークは「サービスWeb UI」アクセスに使用できません

(オプション)管理ネットワークの目的は、システム管理者に「サービスWeb UI」への個別のアクセスを提供することです。 管理ネットワークの現在の実装は不完全であり、正しいアクセスを提供できません。

回避策: 使用可能なものがありません。 この時点で、「いけない」は初期構成時に管理ネットワークを構成します。

バグ: 34087174, 34038203

バージョン: 3.0.1

初期インストール手順中にネットワーク構成が失敗

アプライアンス・ラックを物理的に設置したあと、使用できるようにするには、システムを初期化し、データセンター環境に統合する必要があります。 この手順は、「Oracle Private Cloud Applianceインストレーション・ガイド」Oracle Private Cloud Applianceの構成という章で説明されています。 この手順のネットワーク構成部分が失敗した場合 - たとえば、メッセージ・トランスポートまたはサービス・ポッドの問題、またはスイッチから戻されたエラーのため - 操作を再試行する前に手動でロールバックする必要があるロックが設定されています。

回避策: 使用可能なものがありません。 サポートが必要な場合は、Oracleに連絡してください。

可能な場合は、「サービスCLI」からネットワーク構成の状態を確認します。

PCA-ADMIN> show networkConfig                                                                                  
Data:
[...]
  Network Config Lifecycle State = FAILED

バグ: 34788596

バージョン: 3.0.2

外部証明書は許可されていません

現時点では、Oracle Private Cloud Applianceは外部CA署名証明書の使用を許可しません。

回避策: 回避策については、Oracleサポートに連絡してください。

バグ: 33025681

バージョン: 3.0.2

リリース3.0.2へのアップグレード後にOracle Linux 8インスタンスのDNSエントリが正しくない

アプライアンス・ソフトウェアをリリース3.0.2にアップグレードしても、コンピュート・インスタンスのオペレーティング・システムの名前解決設定は自動的に更新されません。 インスタンスDHCPリースが更新されると、最新のネットワーク・パラメータが取得されます。 それまでは、Oracle Linux 8がDNSサーバー・メッセージに応答する方法が原因で、FQDNを使用した問合せは成功しますが、短いホスト名を解決できません。 Oracle Linux 7インスタンスはこの問題の影響を受けません。

回避策: Oracle Linux 8インスタンスのコマンドラインでDHCPクライアント・サービス(dhclient)を再起動します。 インスタンスをリブートすると、問題が解決されます。

バグ: 34918899

バージョン: 3.0.2

ネットワーク・ロード・バランサが詳細なバックエンド・ヘルス・ステータスを報告しない

Oracle Cloud Infrastructureのユーザーは、ネットワーク・ロード・バランサのバックエンド・サーバーに提供される詳細なヘルス・ステータスに精通している場合があります。 バックエンド・サーバーが完全に正常でない場合、ヘルス・チェック・ステータスには、次のような問題が示されます: 接続の失敗、タイムアウト、正規表現の不一致、I/Oエラー、無効なステータス・コード。 Oracle Private Cloud Applianceの特定のロード・バランサ実装により、ネットワーク・ロード・バランサ・サービスは、バックエンド・サーバーが正常であるか(OK)、異常であるか(CRITICAL)のみをレポートできます。

回避策: 回避策はありません。 バックエンド・ヘルス・チェックでは、追加のステータス情報を提供できません。

バグ: 35993214

バージョン: 3.0.2

サポートされていない文字のためにロックされたロード・バランサ・バックエンドのヘルス・チェック構成

アプライアンス・ソフトウェア・バージョン3.0.2-b1325160以前を実行しているシステムでは、バックエンド・サーバーによって送信されたヘルス・ステータス・レスポンスの正規表現(regex)を解析するようにロード・バランサを構成できます。 response-body-regexパラメータの構成時に、スラッシュ('/')エスケープ文字を含めることができます。 ただし、この文字によって無効なjson構成ファイルが発生し、それ以降の構成変更や無効な文字の削除ができなくなります。

この問題は、アプライアンス・ソフトウェアのバージョン3.0.2-b1392231へのアップグレードもブロックします。

回避策: レスポンス本文の正規表現では、スラッシュ('/')エスケープ文字を使用しないでください。 それ以外の場合は、ロード・バランサ設定全体を削除する必要があります。

バグ: 37795379

バージョン: 3.0.2

アプライアンス・ソフトウェアのアップグレード後のロード・バランサの機能変更

Private Cloud Applianceソフトウェアのバージョン3.0.2-b1392231では、ロード・バランサは新しいバックグラウンド実装に移行されます。 その結果、いくつかの機能が異なるか、使用できなくなりました。 新しい実装でサポートされなくなった既存の構成は、アプライアンス・ソフトウェアのアップグレードに悪影響を及ぼす可能性があります。

レスポンス本文の正規表現解析

ヘルス・ステータス情報に対するバックエンド・レスポンスの正規表現(regex)解析を使用してロード・バランサが構成されている場合、アップグレード後に機能しなくなります。 ヘルス・ステータス・レポートは、レスポンス・コードに制限されます。

回避策: アプライアンス・ソフトウェアをバージョン3.0.2-b1392231にアップグレードする前に、バックエンド・サーバーからのレスポンスのオプションの正規表現設定(--response-body-regex)を構成解除します。

バグ: 37629014

暗号スイート

新しいロード・バランサ実装では、より弱い暗号スイートが削除されました。 今後、SSL/TLS接続は、次の暗号スイートで保護できます:

AES128-GCM-SHA256, AES256-GCM-SHA384, 
ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-ECDSA-AES256-GCM-SHA384, 
ECDHE-RSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-GCM-SHA384, 
AES128-SHA, AES256-SHA, DES-CBC3-SHA, 
ECDHE-ECDSA-AES128-SHA, ECDHE-ECDSA-AES256-SHA, 
ECDHE-RSA-AES128-SHA, ECDHE-RSA-AES256-SHA, 
PSK-AES128-CBC-SHA, PSK-AES256-CBC-SHA

回避策: アプライアンス・ソフトウェアをバージョン3.0.2-b1392231にアップグレードする前に、アップグレード後も使用可能な暗号スイートが使用されていることを確認します。 必要に応じて、既存のロード・バランサ構成を変更します。

バグ: 37461876

Cookieベースの永続性

既存のロード・バランサの場合、クライアントとバックエンド・サーバー間のセッション永続性を、アプリケーションcookieまたはロード・バランサcookieのいずれかを使用して有効にできます。 これらはアップグレード後にサポートされなくなりました。

回避策: アプライアンス・ソフトウェアをバージョン3.0.2-b1392231にアップグレードする前に、cookieベースのセッション永続性を構成解除します。 または、ロード・バランサcookieは、アップグレード前にロード・バランシング・ポリシーがIPハッシュに設定されている場合に保持できます。

バグ: 37473362

サーバー順序プリファレンス

クライアント暗号よりもサーバー暗号に優先順位を付けるためのSSLパラメータはサポートされていません。

アプライアンスのアップグレード後に失われたすべてのインスタンスへの接続

BGP (Border Gateway Protocol)とレイヤー3の仮想化を使用した大規模なマルチテナント・ネットワーク構成では、ルート・リークによって、仮想ルーティングと転送(VRF)を介して分離されたルーティング表間の制御された方法でルートを共有できます。 ただし、アプライアンス・ソフトウェア・バージョン3.0.2-b1261765にアップグレードすると、VRF間でリークできるルートの数は1000に制限されます。 アップグレード前の既存のルート・マップが大きい場合は、特定のルートが削除され、接続が失われます。 たとえば、必要なルートが使用できなくなったため、コンピュート・インスタンスとの間のトラフィックがブロックされる場合があります。

回避策: アプライアンス・ソフトウェアをバージョン3.0.2-b1261765にアップグレードする前に、あるVRFから別のVRFにインポートされたルートの数が1000を超えないようにしてください。 ルート・リストのプルーニングが不十分な場合は、デフォルト・ルートを構成できます。 必要に応じて、Oracleはこの特定のアップグレード・シナリオに関するガイダンスを提供できます。

バグ: 37628459

バージョン: 3.0.2

プロビジョニング状態の失敗でスタックしているルート表

Dynamic Routing Gateway (DRG)へのアタッチメントとして関連付けられているルート表を更新して、ローカル・ピアリング・ゲートウェイ(LPG)をターゲットとして持つ場合、この既知の問題により、ルート表がプロビジョニング状態のままになる可能性があります:

{
  "timestamp": "2023-06-28T15:30:58.635+0000",
  "rid":
"7FCCBAEBA62848878983FDA3098EE4DB/330fc100-b86f-4137-a1f9-2437a512b8e8/7b003c9
7-11c4-4e4a-8c9a-11861532db0d,
  "process": 1,
  "ocid": null,
  "levelname": "ERROR"
  "src_lineno": 481
  "src_pathname": "/usr/lib/python3.6/site-packages/pcanwctl/framework.py",
  "message::
  "Exception on function call: update_route_table, error: (404,
NotAuthorizedOrNotFound', 'No Subnet was found'), start exception rollback",
  "tag": "pca-nwctl.log"
}

回避策: 更新ルーチンでエラーが発生しないように、ルート表を削除して再作成します。

バグ: 35547644

バージョン: 3.0.2

DRGがアタッチされていないため、Terraformを使用したルート表の更新に失敗

Terraformを使用してネットワーク・リソースをデプロイすると、予想されるDynamic Routing Gateway (DRG)アタッチメントが存在しないように見えるため、ルート表を更新できない場合があります。 DRGはVCNにアタッチされていますが、ルート表を更新するコマンドが発行されると、操作は完全に完了しません。 Terraformを介してコマンドをすばやく連続させると、このタイミングの問題が明らかになりますが、人間のユーザー・アクションの結果として発生する可能性はほとんどありません。

回避策: ルート表更新の失敗がタイミングの問題の結果であると仮定すると、ルート表更新コマンドの繰返しは成功すると予想されます。 Terraform構成を再適用するか、ルート表を手動で更新します。

バグ: 36297777

バージョン: 3.0.2

プロビジョニング状態のルート表によるTerraform破棄の実行に失敗しました

terraform destroy操作を実行すると、ルート表オブジェクトが'available'ではなく'provisioning'状態のままであるため、失敗する可能性があります。 これは通常、ルート表に対して短時間で多数の更新が行われ、その結果、Terraformプロバイダが想定するよりもコマンドの完了に時間がかかる場合に発生します。 厳密に言えば、これはバグではなく、タイミングの問題です。

回避策: 失敗がタイミングの問題の結果であると仮定すると、ルート表またはその他のリソースが「プロビジョニング」状態で永続的にスタックすることはありません。 terraform destroyコマンドを繰り返すと、残りのオブジェクトが正常に削除されます。 必要に応じて、Terraform設定で特定のリソースの待機時間を増やします。

バグ: 36352218

バージョン: 3.0.2

BGP認証を構成する場合、パスワードは必須パラメータです

データ・センター・ネットワークへのアプライアンス・アップリンクが動的ルーティング用に構成されている場合、2つの自律型システム - つまり、アプライアンス側のスパイン・スイッチと、データ・センター側のToRスイッチ - BGP (Border Gateway Protocol)ピアとして設定されます。 BGPピア間のセッションは、パスワード・ベースの認証で保護できます。 BGP認証は、データ・ネットワークおよびオプションの個別の管理ネットワークに対して有効にできます。

BGPパスワードは、「サービスCLI」setDay0DynamicRoutingParametersコマンドを使用して設定できます。 ネットワークごとに2つのコマンド・パラメータを指定する必要があります。

  • データ・ネットワーク: bgpAuthentication=TrueおよびbgpPassword=<mypassword>

  • 管理ネットワーク: adminBgpAuthentication=TrueおよびadminBgpPassword=<mypassword>

ただし、パスワードを指定せずにBGP認証をtrueに設定すると、CLIコマンドを使用できます。 悪影響はありませんが、BGP認証は無効のままです。

回避策: データ・ネットワークでBGP認証を有効にし、管理ネットワークがある場合は、コマンド・パラメータの一部としてBGPパスワードも指定してください。

バグ: 35737959

バージョン: 3.0.2

VRRPメッシュ構成セット2番目のスイッチIPを誤ってアップリンク

VRRP (Virtual Router Redundancy Protocol)を使用してメッシュ・トポロジでアプライアンス・データおよび管理ネットワーク・アップリンクを構成しようとすると、CLIエラーになります。 スパイン・スイッチの2番目のIPアドレスが構成されていると、問題が発生: スイッチは、パラメータを重複するネットワーク設定として解釈し、拒否します。

次の例は、4ポート・メッシュ・アップリンク・トポロジを持つ管理ネットワークを示しています。 データ・ネットワーク・アップリンクにも同じ動作が適用されます。

PCA-ADMIN> edit networkConfig enableAdminNetwork=True adminportcount=4 admintopology=MESH adminportspeed=10 
adminspine1Ip=10.1.1.97,10.1.1.98 adminspine2Ip=10.1.1.101,10.1.1.102 adminSpineVip=10.1.1.105 [...]

PCA-ADMIN> show networkconfig
Data: 
  [...]
Error:
UpdateFirstBootHandler: {'http_status_code': 500, 'code': 'InternalServerError', 'message': 'SwitchCliError on 100.96.2.20: 
overlapping network for ipv4 address: 10.1.1.98/28 on po46, 10.1.1.97/28 already configured on po45\\n for cmd [...]

回避策: 回避策はありません。 この特定のアップリンク構成は現時点では適用できません。

バグ: 36063880

バージョン: 3.0.2

分離された管理ネットワークの無効化の失敗

アプライアンス・ソフトウェアを3.0.2-b1261765にアップグレードした後、別個の管理ネットワークを無効にすると、スパイン・スイッチ構成を更新できないため、エラーが発生します。 これは、スパイン・スイッチに送信される更新リクエストにパラメータがないことが原因です。

回避策: このエラーが発生したアプライアンスで分離された管理ネットワークを無効にする必要がある場合は、次に示すように、アプライアンス・ソフトウェアのアップグレード後、または別の管理ネットワークを有効にした後に、BGPトポロジ設定を変更します。

PCA-ADMIN> edit networkconfig adminBgpTopology=triangle

バグ: 37618380

バージョン: 3.0.2

スパイン・スイッチ設定を変更しないとラック・ネットワーク構成の編集に失敗

スイッチ構成の更新をトリガーするその他のパラメータなしでラック・ネットワーク構成を変更すると、内部コマンドに空のパラメータが含まれているため、失敗します。 ネットワークは完全に機能したままですが、構成の変更は適用されません。

回避策: 特定のネットワーク構成パラメータを更新するには - DNS設定、NTP設定、パブリックIPアドレスなど - ネットワーク構成の更新コマンドに別の変更を追加します。 更新が成功したら、追加の変更を元に戻します。 次の例では、DNS設定を更新するときにadminmtuパラメータの変更を含めてから、元の値に戻します。

PCA-ADMIN> edit networkconfig dnsip1=10.202.192.16 dnsip2=192.0.2.32 adminmtu=9200
  JobId: 1c9bbfca-7566-4e06-a6e3-8185c512cf92
  Data: created job for edit network

PCA-ADMIN> edit networkconfig adminmtu=9216

バグ: 37311414

バージョン: 3.0.2