項目一覧
構成のチュートリアル
このウォークスルーでは、Juniper Apstra JVDを使用して3ステージファブリックを構成するために必要な手順を説明します。詳細な設定情報については、『 Juniper Apstraユーザーガイド』を参照してください。このチュートリアルの追加ガイダンスは、メモの形式で提供されます。
このウォークスルーでは、ジュニパーのデータセンター検証テストラボでの検証時に使用されるベースライン設計の構成について詳しく説明します。ベースライン設計は、スパインの役割のQFX5220-32CDスイッチ、境界リーフの役割のQFX5130-32CDスイッチ、サーバーリーフの役割のQFX5120-48Yスイッチで構成されています。JVDの目的は、サポートされるデバイスと位置づけの 表1で説明したように、これらのスイッチプラットフォームのいずれかを、その役割に合った検証済みのスイッチプラットフォームに置き換えることができるようなオプションを提供することです。このウォークスルーを扱いやすい長さにするために、このドキュメントではベースライン設計プラットフォームのみを使用します。
Apstra: Apstra Server と Apstra ZTP Server を構成する
このドキュメントでは、Apstraのインストールについては説明しません。インストールの詳細については、『 Juniper Apstraユーザーガイド』を参照してください。
最初のステップは、Apstraサーバーの設定です。設定ウィザードは、ApstraサーバーVMに初めて接続すると起動します。この時点で、Apstraサーバー、Apstra UI、およびネットワーク設定のパスワードを設定できます。
Apstra:Junos OSデバイスの管理
ジュニパーデバイスをApstraに追加するには、手動とZTPを使用した一括の2つの方法があります。
デバイスを手動で追加するには(推奨):
Apstra UIで、[ Devices > Agents ]>[ Create Offbox Agents]に移動します。
これには、デバイスで設定するrootパスワードと管理IPの最小設定が必要です。
ZTP を使用してデバイスを追加するには:
Apstra ZTPサーバーからデバイスを追加するには、JuniperデバイスのZTPの詳細については、 Juniper Apstraユーザーガイド を参照してください。
この設定では、デバイスをApstraに追加する前に、すべてのスイッチでrootパスワードと管理IPがすでに設定されています。Apstraにスイッチを追加するには、まずApstra Web UIにログインし、上記のとおりデバイス追加方法を選択し、それらのデバイスに事前設定された適切なユーザー名とパスワードを入力します。
Apstraは、プリスティン設定と呼ばれる設定をジュニパーのデバイスから取得します。Junos設定の「グループ」スタンザは、元の設定をインポートする際に無視され、Apstraは継承モデルにリストされているグループ設定を検証しません。「設定グループを使用してデバイスを迅速に設定する」を参照してください。ただし、ループバック、インターフェイス(管理インターフェイスを除く)、ルーティングインスタンス(管理インスタンスを除く)の設定は避けるのがベストプラクティスです。デバイスが正常に確認されると、ApstraはプロトコルLLDPとRSTPを設定します。
Apstra Web UI: エージェントプロファイルの作成
このJVDラボでは、rootユーザーとパスワードはすべてのデバイスで同じです。したがって、エージェントプロファイルは次のように作成されます。これにより、パスワードが不明瞭になり、パスワードが安全に保たれることに注意してください。
- [デバイス] > [エージェント プロファイル] に移動します。
- 「 エージェント・プロファイルの作成」をクリックします。
でのエージェントプロファイルの作成
Apstra Web UI:デバイスを一括検出するには、IP アドレス範囲またはIP アドレス範囲を入力
IPアドレス範囲を指定することで、デバイスをApstraに一括追加できます。
- [デバイス] > [エージェント] に移動します。
- 「 オフボックスエージェントの作成」をクリックします。
の作成
Apstra Web UI: 初期状態の設定を追加してJunos OSをアップグレードする
[デバイス>管理対象デバイス]から、デバイスから収集するか、Apstraからプッシュして、元の設定を追加します。初期設定の一部として適用される設定は、基本設定、またはユーザー、管理スイッチへの静的ルートなどを追加してデバイスに到達するために必要な最小限の設定である必要があります。これにより、Apstraに基本設定のバックアップが作成され、問題が発生した場合にデバイスを元の設定に戻すことができます。
の追加
上記の 図3 に示すように、Apstraを使用して初期状態の設定を更新した場合は、必ず 「Revert to Pristine」を実行してください。重要: アップグレードは中断を招く可能性があるため、デバイスのアップグレードを実行するにはメンテナンスウィンドウが必要です。アップグレードのベストプラクティス推奨事項:Apstraは現在、基本的なアップグレードチェックのみを実行しているため、 Junos OSソフトウェアのインストールおよびアップグレードガイドとJunos OSバージョンのリリースノートに記載されているJunos OS CLIを使用してデバイスのアップグレードします。ただし、このJVDには、Apstraをアップグレードに使用する場合のアップグレード手順がまとめられています。デバイスがブループリントに追加された場合は、デバイスを「アンデプロイ」に設定し、ブループリントからシリアル番号の割り当てを解除して変更をコミットすると、元の設定に戻ります。次に、アップグレードに進みます。アップグレードが完了したら、デバイスをブループリントに追加し直します。
Apstraでは、デバイスのアップグレードが可能です。ただし、Apstraは基本的なチェックを実行し、upgradeコマンドを発行します。Apstraからデバイスをアップグレードするには、次の図を参照してください。
からのデバイスのアップグレード
ApstraにJunos OSイメージを登録するには、すべてのOSイメージが保存されているリポジトリへのリンクを提供するか、以下に示すようにOSイメージをアップロードします。Apstra UIで、[ Devices > OS Images ]に移動し、[ Register OS Images]をクリックします。
の提供イメージのURL
Apstraファブリックプロビジョニング
検出されたデバイスを確認し、デバイスを確認します。
デバイス>管理対象デバイス
オフボックスエージェントが追加され、デバイス情報が収集されたら、チェックボックスインターフェイスをクリックしてすべてのデバイスを選択し、[確認]をクリックします。これにより、スイッチはApstraサーバーの管理下に置かれます。
最後に、ApstraがLLDPとRSTPの設定を追加する際に、元の設定が再度収集されることを確認します。
で管理するデバイスの確認
スイッチが承認されると、「確認済み?」テーブルヘッダーの下のステータスアイコンが赤色のXから緑色のチェックマークに変わります。すべてのスイッチについて、この変更を確認します。変更がない場合は、手順を繰り返してスイッチを再度確認します。
デバイスをApstraで管理した後は、すべてのデバイス構成の変更をApstraを使用して実行する必要があります。Apstra以外のデバイスでは設定変更を行わないでください。Apstraによって変更が取り消される可能性があるためです。
Apstra Web UI:論理デバイス、デバイスプロファイルを使用したインターフェイスマップを識別して作成
次の手順では、Juniper Apstraのベースラインアーキテクチャとデバイスを使用して、3ステージファブリックを定義します。ブループリントをプロビジョニングする前に、トポロジーのレプリカが作成されます。次の手順では、ERB データ センターのリファレンス アーキテクチャとデバイスを定義します。
- これには、スパイン、リーフ、および境界リーフスイッチの論理デバイスの選択が含まれます。論理デバイスは、物理デバイスを抽象化したもので、ポートの量、速度、役割などの一般的なデバイスフォームファクターを指定します。ベンダー固有の情報は含まれていないため、ベンダーとハードウェアデバイスモデルを選択する前にネットワーク定義を構築できます。Apstraソフトウェアのインストールには、論理デバイスの任意のバリエーションを作成するために使用できる、多くの定義済み論理デバイスが含まれています。
- 次に、インターフェイスマップを使用して、論理デバイスをデバイスプロファイルにマッピングします。インターフェイスマップにマッピングされたポートは、デバイスプロファイルと物理デバイス接続と一致します。繰り返しになりますが、Apstraソフトウェアのインストールには、多くの定義済みインターフェイスマップとデバイスプロファイルが含まれています。
- 最後に、設定された論理デバイスとデバイス プロファイルを使用してラックとテンプレートを定義し、ブループリントの作成に使用します。
『Juniper Apstraユーザーガイド』では、Apstraの設計図とデバイスを使用する際に理解しておく必要のあるデバイスのライフサイクルについて説明しています。
3段階の設計プロビジョニング手順では、Apstraデータセンターのリファレンスデザインを使用します。
[ Design > Logical Devices]に移動し、ポート数とポート速度に基づいてリストされているデバイスを確認します。追加するデバイスに最も近いデバイスを選択し、論理デバイスのクローンを作成します。
システム追加またはデフォルトの論理デバイスは変更できません。
以下の表は、このドキュメントの「Juniper Apstra JVDを使用した3ステージファブリック」ラボ用に作成されたデバイスの役割、論理デバイスタイプ、ポート、および接続を示しています。[Port Groups] 列は、このラボに必要な最小接続を示しています。これは、これらのスイッチが提供できる実際のポートグループとは異なります。
| デバイスの役割 | ポートグループ接続1 | ポートグループ2 | 接続先 |
|---|---|---|---|
| 背骨 | スーパースパイン/スパイン/リーフ/アクセス/ジェネリック | 5 x 100 Gbps(各スパイン) | ボーダーリーフスイッチ x 2 サーバーリーフスイッチ x 3 |
| サーバーリーフ(シングル) | スーパースパイン/スパイン/リーフ/アクセス/ジェネリック | 2 x 100Gbps 5 x 10Gbps |
2 スパイン 2 サーバー (汎用) |
| サーバーリーフスイッチ(2 ESIリーフスイッチ) | スーパースパイン/スパイン/リーフ/アクセス/ジェネリック | 4 x 100 Gbps(両方のリーフスイッチ) 5 x 10Gbps |
2 スパイン 4 サーバー (汎用) |
| ボーダーリーフスイッチ | スーパースパイン/スパイン/リーフ/アクセス/ジェネリック | 6 x 10Gbps 4 x 100 Gbps(両方のリーフスイッチ) |
6 サーバー 2 スパイン |
1 ポート グループ接続の場合、これらは接続されるロールとデバイスによって異なる場合があります。
2ポートグループの場合、ポート数は接続と速度によって異なります。
デバイスプロファイル
本書で取り上げているすべてのデバイスについて、デバイスプロファイル(Apstraの 「デバイス」>「デバイスプロファイル」で定義)は、 Apstraにデバイスを追加する際に、Apstraによって完全に一致Junos OS。サポートされているデバイスの検証中に、たとえば、QFX5700など、デバイスのラインカード設定に合わせてデバイスプロファイルをカスタム化する必要がありました。デバイスプロファイルの詳細については、 デバイスプロファイルに関するApstraユーザーガイドを参照してください。
にリンクされたQFX5700デバイス プロファイル
にリンクされたQFX5700デバイス プロファイル
スパイン論理デバイスと対応するインターフェイス マップ
スパイン論理デバイスは、QFX5220-32CD(Junos OS)に基づいています。このソリューションでは、7つの100Gリンクを使用してリーフスイッチに接続します。 図11 に示すように、5つのスパイン/リーフ接続には100Gbpsのポートが12個あれば十分です。
スパイン論理デバイスポートは、以下に示すように、インターフェイスマップを使用してデバイスプロファイルにマッピングされます。インターフェイスマップにマッピングされたポートは、デバイスプロファイルと物理デバイス接続と一致します。
サーバー リーフ スイッチの論理デバイスとインターフェイス マップ
このJVDでは、3つのQFX5120-48Yサーバリーフスイッチがあります。そのうちの2つはESIサポートスイッチで、1つは非ESI LAGスイッチです。3 つのサーバー リーフ スイッチはすべて 100 GB インターフェイスを使用して各スパインに接続され、10 GB インターフェイスは汎用サーバーに接続します。
単一(非冗長)リーフ スイッチの場合、ESI は使用されず、LACP(アクティブ)のみが設定されます。
ESI(冗長)リーフスイッチでは、マルチホーミングにESI Lagが使用されます。ESI LAG は、[ Design ] > [Rack Types] の [Rack] の下に設定します。
サーバーリーフ論理デバイスは、以下のようにデバイスプロファイルにマッピングされます。
この場合、シングルリーフとESIサーバーのリーフペアはどちらも同じデバイスプロファイルを持っていますが、スイッチ上の物理ポートがサーバーとスパインに接続される方法が異なるため、2つの異なる論理デバイスが設計されました。
境界リーフ スイッチの論理デバイスとインターフェイス マップ
ボーダーリーフ論理デバイスは、この設計で使用されるQFX5130-32CDスイッチを表現したものです。物理的なケーブル接続によって、インターフェイスマップに割り当てられるポートが決まります。
残りの論理デバイスについては、以下で説明します。インターフェイスマップはオプションであり、省略できます。
汎用サーバー論理デバイス
汎用サーバーは、リーフ スイッチ(境界および単一)に接続されたサーバーからのネットワーク インターフェイス接続を定義します。
使用するサーバーの論理デバイスは、Apstra内ですでに定義されています。同様の汎用システムを DCI に使用できます。ただし、DCIについては、別のJVD拡張ドキュメントで説明します。
外部ルーター
外部ルータは境界リーフ スイッチに接続されます。
Apstraは、MXシリーズデバイスなどの外部ルーターを管理しません。そのため、MXシリーズルーターは、関連するポートと速度設定を持つ外部汎用サーバーとして分類されます。
ブループリントの作成後、汎用外部システムがブループリントに追加されます。汎用サーバーや外部ルーターにインターフェイスマップは必要ありません。外部ルータの接続と機能は、このドキュメントの範囲外です。
Apstra Web UI:ラック、テンプレート、ブループリント - ラックの作成
論理デバイスとインターフェイスマップを定義したら、次のステップは、論理デバイスをラック形式で配置するためのラックを作成することです。このソリューションのデフォルト設計は、2 つのスパイン、5 つのサーバ リーフ スイッチ、および 2 つの境界リーフ スイッチです。ラックの設計は、スパインスイッチに十分なポートがあれば、何度でも作成して使用できます。
Apstraの[ Design > Rack Types]でラックを作成します。このソリューションには、4つのラックがあります。ボーダーリーフスイッチ用ラックが1ラック、サーバーリーフスイッチ用ラックが3ラック。ラックの作成の詳細については、『 Juniper Apstraユーザーガイド』を参照してください。
この設計の場合、L3 Closラックの構造は次のとおりです。
サーバーリーフスイッチ(シングルリーフ)
なしのシングルリーフラック
サーバーリーフスイッチ(2リーフスイッチ)
用のESIラグを備えたサーバーリーフスイッチ
ボーダーリーフスイッチ
設計図が作成されて機能するようになった後、ラックに変更を加える必要がある場合は、ナレッジベースの記事「 https://supportportal.juniper.net/s/article/Juniper-Apstra-How-to-change-Leaf-Access-Switch-of-existing-rack-after-Day2-operations?language=en_US」に従ってください。検証中に、 表 5 にリストされているすべてのデバイスを検証するようにボーダー リーフ ラックが変更されました。
テンプレートの作成
テンプレートは、ネットワークの構造とインテントを定義します。ラックを作成したら、スパインリンクを各ラックに接続する必要があります。この設計では、ラックベースのテンプレートを使用して、トップオブラック(ToR)スイッチ(またはToRスイッチのペア)として接続するラックを定義します。
スパイン論理デバイスのセクションで説明したように、各サーバーリーフとボーダーリーフには100Gリンクが割り当てられています。スパイン論理デバイスはテンプレートで割り当てられます。このデザインにはスーパースパインがないので、テンプレートから除外されています。テンプレートの詳細については、『 Juniper Apstraユーザーガイド』を参照してください。
テンプレートは、次のセクションで説明するブループリントを作成するためのベースとして使用されます。テンプレートは、ブループリントの有効期間中に一度だけ使用されます。したがって、テンプレートを変更しても、ブループリントは変更されません。
が記載された DC ラックベースのテンプレート
青写真
各ブループリントはデータセンターを表しています。テンプレートは [設計>テンプレート ] セクションで作成され、ブループリントのグローバル カタログで使用できるようになります。テンプレートを定義したら、それを使用してデータセンターのブループリントを作成できます。
ブループリントを作成するには、[ Blueprints (ブループリント)] > [Create Blueprint (ブループリントの作成)] をクリックします。ブループリントの作成に関する詳細については、『 Juniper Apstraユーザーガイド』を参照してください。
を使用したブループリントの作成
[ Blueprint > Staged] に移動します。表示されるトポロジを展開すると、すべての接続を表示できます。ここから、ブループリントを [Staged] (ステージング) でプロビジョニングできます。
上記のように、ブループリントは作成されますが、プロビジョニングはされません。トポロジーに不一致がないか検査し、不一致がある場合は、テンプレートまたはラックを修正した後に設計図を再作成できます。または、 Staged > Racks に移動し、 この記事に記載されている手順に従ってラックを編集します。
Apstra Web UI:ネットワークのプロビジョニングと定義
ブループリントが作成されると、ブループリントをステージングする準備が整ったことを意味します。作成されたブループリントの下のタブを確認します。
プロビジョニングを開始するには、 [Physical](物理) > [Staged](ステージング済み) タブ をクリックし、右側のパネルから [Build](ビルド) をクリックします。詳細については、 Juniper Apstraユーザーガイドを参照してください。
] の下の [Assign Resources] (リソースの割り当て)
リソースの割り当て
最初のステップは、この リソース セクションで作成したIPを割り当てることです。この設計では、使用されるリソース値を以下に示します。
- [ Staged > Physical > Build > Resources ] をクリックし、以下のように更新します。
- DC1 ASN—スパインおよびリーフ スイッチ: 64512 - 64999
- ループバック IP—スパインおよびリーフ スイッチ:192.168.255.0/24
- リンク IP—スパイン<>リーフ スイッチ: MUST-FABRIC-Interface-IPs DC1-10.0.1.0/24
スイッチへのインターフェイスマップの割り当て
設計図から [Staged > Physical > Build > Device Profiles] に移動します。
次に、このドキュメントの「 Apstra Web UI:論理デバイスの識別と作成」、「デバイスプロファイルを使用したインターフェイスマップ 」セクションで作成したインターフェイスマップにデバイスを割り当てます。
] の [Device Profiles] でのインターフェイス マップの割り当て
汎用システムまたは汎用サーバーへのインターフェイスマップの割り当てはオプションです。これらのパラメータのステータスは赤でマークされ、オプションとしてもマークされます。
システム ID と正しい管理 IP を割り当てる
ブループリントから [Staged > Physical > Build > Devices ] に移動し、[Assigned System IDs] をクリックします。システム ID は、デバイスのシリアル番号です。
でステージングされたブループリントのシステム ID の割り当て
ノードまたはデバイスごとにデバイスのホスト名と(Apstra上の)表示名が異なる場合、これらはApstraによって管理され Apstra.No ないため、汎用サーバーと外部ルーターにシステムIDが割り当てられることで変更できます。
システムID(デバイスのシリアル番号)を割り当てる前に、Apstraの [デバイス > 管理対象デバイス ]ですべてのデバイスが追加されていることを確認してください。
ケーブル配線の見直し
Apstraは、物理的なケーブル配線とは異なる可能性のあるデバイスのケーブルポートを自動的に割り当てます。ただし、Apstraによって割り当てられたケーブル接続は上書き可能で、実際のケーブル配線が示すように変更できます。これを行うには、設計図にアクセスし、[ Staged > Physical > Links]に移動して[ Edit Cabling Map ]ボタンをクリックします。詳細については、 Juniper Apstraユーザーガイドを参照してください。
の確認と編集
汎用サーバーを含むスイッチ名を確認して、名前に一貫性があることを確認するのがベスト プラクティスです。デバイスの名前を確認および変更するには、[ Staged > Physical > Nodes ] に移動し、リストされているデバイスの名前をクリックすると、トポロジとデバイスへの接続、およびデバイスのプロパティやタグなどを表示する右側のパネルが表示されます( 図 33 を参照 )。
の確認
コンフィグレットとプロパティセット
コンフィグレットは、グローバル カタログの [デザイン] > [コンフィグレット] で定義される構成テンプレートです。コンフィグレットはApstraのインテントベースの機能では管理されないため、手動で管理します。コンフィグレットを使用しない場合の詳細については、 Juniper Apstraユーザーガイドを参照してください。コンフィグレットは、リファレンスデザインの設定を置き換えるために使用しないでください。コンフィグレットは、Junos設定JSONスタイルやJunosセットベース設定など、設定スニペットのJinjaテンプレートとして宣言できます。コンフィグレットの設計の詳細については、『 Apstraコンフィグレットユーザーガイド』を参照してください。
コンフィグレットが正しく設定されていない場合、警告や制限が発生しない場合があります。コンフィグレットは、別の専用サービスでテストおよび検証して、コンフィグレットが意図したとおりに動作することを確認することをお勧めします。パスワードやその他の秘密鍵は、コンフィグレットでは暗号化されません。
プロパティ セットは、デバイスのプロパティを定義するデータ セットです。これらは、コンフィグレットおよび分析プローブと連携して機能します。プロパティ セットは、グローバル カタログの Design > Property Sets で定義されます。
フリーフォーム・ブループリントの構成テンプレートでもプロパティ・セットが使用されますが、デザイン・カタログのプロパティ・セットとは関係ありません。
グローバルカタログで定義されたコンフィグレットとプロパティセットは、必要なブループリントにインポートする必要があり、コンフィグレットが変更された場合は、プロパティセットの場合と同様に、同じものをブループリントに再インポートする必要があります。次の図は、ブループリントにあるコンフィグレットとプロパティセットを示しています。
にインポートする
にインポートする
3段階の検証では、セットアップと管理の目的で、一般的な設定の一部としていくつかのコンフィグレット(ネームサーバー、NTPなど)が適用されました。
ファブリックセッティング
ファブリックポリシー
このオプションでは、MTU、IPv6アプリケーションサポート、ルートオプションなど、さまざまなパラメーターをファブリック全体で設定できます。このJVDでは、次のパラメータが使用されました。 ブループリント内でこれらの設定を表示および変更します Apstra UI内の 「ステージングされた>ファブリック設定」>ファブリックポリシー 。
- データセンターで中程度のトラフィックをシミュレートするために、トラフィックスケールテストを実行しました 詳細については、 表6 を参照してください。スケールテストはQFX5120-48Yスイッチで実施しました。
Junos EVPNネクストホップとインターフェイス数の最大値の設定も有効になったため、Apstraは関連する設定を適用して、リーフスイッチで許可されるEVPNオーバーレイネクストホップと物理インターフェイスの最大数をデータセンターファブリックの適切な数に最適化できます。これに加えて、コンフィグレットは、図 37 に示すように、レイヤー 2 とレイヤー 3 のエントリーにバランスの取れたメモリ割り当てを設定するためにも使用されます。
これらの機能の詳細については、以下を参照してください。
- https://www.juniper.net/documentation/us/en/software/junos/multicast-l2/topics/topic-map/layer-2-forwarding-tables.html
- https://www.juniper.net/documentation/us/en/software/junos/evpn-vxlan/Other/interface-num-edit-forwarding-options.html
- https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/next-hop-edit-forwarding-options-vxlan-routing.html
QFX5120リーフスイッチ設定の場合:
{master:0} root@dc1-esi-001-leaf1> show configuration forwarding-options | display set set forwarding-options vxlan-routing next-hop 45056 set forwarding-options vxlan-routing interface-num 8192 set forwarding-options vxlan-routing overlay-ecmp {master:0} root@dc1-esi-001-leaf1> show configuration chassis forwarding-options | display set set chassis forwarding-options l2-profile-three図 37:バランスの取れたメモリ
のためのリーフスイッチのコンフィグレット
- 非EVOリーフスイッチでは、 Junos EVPNルーティング インスタンスモード 設定も有効になりました。これは、ApstraがApstra 4.2からのすべての新しいブループリントに適用されるデフォルト設定だからです。Apstra 4.2より前に作成されたブループリントでは、非EVOスイッチのデフォルトスイッチのApstraアップグレード後に許可されています。ただし、Junos OSとJunos OS Evolvedが混在する設定では、MAC-VRFが設定を正規化することを推奨します。MAC-VRF用のVLAN対応ルーティング インスタンス「evpn-1」は、非EVO Junosデバイスに対してのみ作成されます。Junos OS EvolvedはMAC-VRFのみをサポートでき、同じことがデフォルトですでに実装されているため、このオプションはJunos OS Evolvedデバイスに影響しません。
ブループリントが実稼働環境で稼働している場合、メンテナンス期間中に上記の設定変更をMAC-VRFルーティング インスタンスモードに変更することを推奨します。これは中断を伴い、非EVO Junosリーフスイッチ(この場合はQFX5120s)の「再起動」が必要になるためです。
QFX5120リーフスイッチ設定の場合:
{master:0}
root@dc1-esi-001-leaf1> show configuration forwarding-options | display set
set forwarding-options evpn-vxlan shared-tunnels
{master:0}
root@dc1-esi-001-leaf1> show configuration routing-instances evpn-1 | display set
set routing-instances evpn-1 instance-type mac-vrf
set routing-instances evpn-1 protocols evpn encapsulation vxlan
set routing-instances evpn-1 protocols evpn default-gateway do-not-advertise
set routing-instances evpn-1 protocols evpn duplicate-mac-detection auto-recovery-time 9
set routing-instances evpn-1 protocols evpn extended-vni-list all
set routing-instances evpn-1 protocols evpn vni-options vni 10050 vrf-target target:10050:1
set routing-instances evpn-1 protocols evpn vni-options vni 10108 vrf-target target:10108:1
set routing-instances evpn-1 protocols evpn vni-options vni 10400 vrf-target target:10400:1
MAC-VRF ルーティング インスタンス モードが有効になっている場合、非 EVO リーフ スイッチで「デバイスの再起動が必要」の異常が発生します。これらの異常を修正するには、CLIから上記の変更の影響を受けるリーフスイッチを再起動します。
図:MAC-VRFへの変更後にQFX5120デバイスを再起動するためにApstraで発生した異常
設定をコミット
ケーブル配線が確認されると、ファブリックをコミットする準備が整います。これは、コントロールプレーンが設定され、すべてのリーフスイッチがBGPを介してルートをアドバタイズできることを意味します。変更を確認し、ブループリントから Blueprint > <Blueprint-name> Uncommitted に移動してコミットします。
Apstra 4.2では、コミット前にコミットチェックを実行する新機能が導入されました。これは、特にコンフィグレットが関係している場合に、セマンティックエラーや脱落をチェックするために導入されました。
ビルドエラーがある場合は、それらを修正する必要があることに注意してください。それ以外の場合、Apstraはエラーが解決されるまで変更をコミットしません。
詳細については、 Juniper Apstraユーザーガイドを参照してください。
Apstraファブリック構成の検証
変更内容を確認し、デバイスにコミットしたら、機能するファブリックを作成します。
データセンターの設計図には、異常がないことを示し、すべてが機能していることを示す必要があります。ブループリントの展開に関する異常を表示するには、 ブループリント> <ブループリント名>> アクティブ ]に移動して、BGP、ケーブル、インターフェイスダウンイベント、ルート欠落などに関して発生した異常を表示します。詳細については、 Apstraユーザーガイドを参照してください。
ファブリックが機能し、変更が設定されていることを確認するには、各スパインスイッチのコンソールまたはCLIにログインします。各スパイン スイッチのシェルから、次の Junos OS CLI コマンドを入力します。
show bgp summary | no-more
このコマンドの出力は、次の出力のようになります。これは、ループバックおよびファブリックリンクIPに対して、各スパインから7つのリーフスイッチのそれぞれにBGPが確立されていることを示しています。
スパイン1:
root@dc1-spine1> show bgp summary | no-more
Warning: License key missing; requires 'bgp' license
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 14 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
49 42 0 0 0 0
bgp.evpn.0
8263 8263 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.0.1.5 64520 100256 98745 0 12 4w3d 15:44:08 Establ
inet.0: 2/3/3/0
10.0.1.7 64518 100736 99371 0 31 4w3d 19:24:11 Establ
inet.0: 2/3/3/0
10.0.1.9 64514 17957 17900 0 73 5d 18:19:16 Establ
inet.0: 16/17/17/0
10.0.1.11 64515 17943 17889 0 34 5d 18:13:02 Establ
inet.0: 16/17/17/0
10.0.1.13 64516 100735 99370 0 30 4w3d 19:23:45 Establ
inet.0: 2/3/3/0
10.0.1.15 64517 100736 99373 0 34 4w3d 19:24:21 Establ
inet.0: 2/3/3/0
10.0.1.27 64519 100255 98745 0 18 4w3d 15:44:09 Establ
inet.0: 2/3/3/0
192.168.255.2 64514 21707 40706 0 92 5d 18:18:25 Establ
bgp.evpn.0: 1149/1149/1149/0
192.168.255.3 64515 18907 43483 0 31 5d 18:12:36 Establ
bgp.evpn.0: 1147/1147/1147/0
192.168.255.4 64516 124001 244758 0 30 4w3d 19:23:43 Establ
bgp.evpn.0: 1216/1216/1216/0
192.168.255.5 64517 238893 138433 0 34 4w3d 19:24:20 Establ
bgp.evpn.0: 1216/1216/1216/0
192.168.255.6 64518 102398 265528 0 31 4w3d 19:23:58 Establ
bgp.evpn.0: 1137/1137/1137/0
192.168.255.7 64519 101447 217804 0 16 4w3d 15:43:55 Establ
bgp.evpn.0: 1199/1199/1199/0
192.168.255.8 64520 101419 217814 0 12 4w3d 15:44:00 Establ
bgp.evpn.0: 1199/1199/1199/0
スパイン2:
root@dc1-spine2> show bgp summary | no-more
Warning: License key missing; requires 'bgp' license
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 3 Peers: 14 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
49 42 0 0 0 0
bgp.evpn.0
8263 8263 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.0.1.1 64520 100269 98778 0 15 4w3d 15:49:41 Establ
inet.0: 2/3/3/0
10.0.1.3 64519 100267 98778 0 20 4w3d 15:49:40 Establ
inet.0: 2/3/3/0
10.0.1.17 64518 100749 99375 0 35 4w3d 19:29:47 Establ
inet.0: 2/3/3/0
10.0.1.19 64514 17968 17915 0 92 5d 18:24:04 Establ
inet.0: 16/17/17/0
10.0.1.21 64515 17953 17903 0 36 5d 18:17:34 Establ
inet.0: 16/17/17/0
10.0.1.23 64516 100748 99374 0 36 4w3d 19:29:25 Establ
inet.0: 2/3/3/0
10.0.1.25 64517 100749 99378 0 40 4w3d 19:29:58 Establ
inet.0: 2/3/3/0
192.168.255.2 64514 21711 40714 0 93 5d 18:23:41 Establ
bgp.evpn.0: 1149/1149/1149/0
192.168.255.3 64515 18902 43498 0 28 5d 18:16:29 Establ
bgp.evpn.0: 1147/1147/1147/0
192.168.255.4 64516 124014 243943 0 35 4w3d 19:29:20 Establ
bgp.evpn.0: 1216/1216/1216/0
192.168.255.5 64517 238899 137577 0 39 4w3d 19:29:53 Establ
bgp.evpn.0: 1216/1216/1216/0
192.168.255.6 64518 102416 264691 0 34 4w3d 19:29:44 Establ
bgp.evpn.0: 1137/1137/1137/0
192.168.255.7 64519 101454 217761 0 21 4w3d 15:49:28 Establ
bgp.evpn.0: 1199/1199/1199/0
192.168.255.8 64520 101424 217769 0 13 4w3d 15:49:32 Establ
bgp.evpn.0: 1199/1199/1199/0
show bgp summary | no-moreコマンドの出力が上のスクリーンショットのようになると、必要最低限のネットワークファブリックが完成しています。ただし、VRF、VLAN、VNIによるオーバーレイネットワークはまだ適用する必要があるため、実稼働で使用する準備はまだ整っていません。
show bgp summary | no-moreコマンドの出力がスクリーンショットと異なる場合は、先に進む前に設定エラーを修正することが不可欠です。
オーバーレイネットワークの設定
red と blue のテナントのルーティング ゾーン(VRF)を設定し、仮想ネットワーク識別子(VNI)を指定します
- 設計図から>ステージングされた仮想>ルーティングゾーン>。
- [ルーティング ゾーンの作成(Create Routing Zone)] をクリックし、次の情報を入力します。
- VRF名:青
- VLAN ID: 3
- VNI:20002
- ルーティング ポリシー: デフォルト不変
- 次の情報で別のルーティング ゾーンを作成します。
- VRF名:赤
- VLAN ID:2
- VNI:20001
- ルーティング ポリシー: デフォルト不変
EVPNループバックをルーティングに割り当てる
ルーティング ゾーンを作成したら、以下の EVPN ループバックを赤と青の両方のルーティング ゾーンに割り当てます。 [Blueprint > Staged > Routing Zone ]に移動し、右側のパネルからリソースを割り当てます。
| リソース | 範囲 |
|---|---|
| MUST-EVPN-ループバック-DC1 | 192.168.11.0/24 |
図:赤と青のループバックの割り当て
赤と青のルーティングゾーンに仮想ネットワークを作成する
仮想ネットワークは、ルーティング ゾーン(VRF)に関連付ける必要があります。仮想ネットワーク(VNI)を作成し、これらの仮想ネットワークを先ほど作成したルーティング ゾーン(VRF)に関連付けます。必要に応じて、個々の要件に基づいて、実稼働環境に追加のルーティングゾーンと仮想ネットワークを作成します。
以下は、ファブリックで作成され、適切なリーフスイッチに割り当てられたネットワークを示しています。入力フィールドは次のとおりです。
Blue Networkの場合:
- [ 仮想ネットワークの作成] をクリックします。
- ネットワーク VXLAN のタイプを設定します。
- 名前を指定します: dc1_vn1_blue と dc1_vn2_blue。
- 両方のネットワークの 青色の セキュリティ ゾーンを選択します。
- VNIを提供します。
- dc1_vn1_blueの場合は12001。
- dc1_vn2_blueの場合は12002。
- IPv4 接続 – 有効に設定します。
- 接続テンプレートの作成対象: タグ付き。
- IPv4 サブネットと仮想 IP ゲートウェイを指定します。
- dc1_vn1_blue 10.12.1.0/24、10.12.1.1
- dc1_vn2_blue 10.12.2.0/24、10.12.2.1
- リーフスイッチに割り当てます。
レッドネットワークの場合:
- [ 仮想ネットワークの作成] をクリックします。
- ネットワーク VXLAN のタイプを設定します。
- 名前を指定します: dc1_vn1_red と dc1_vn2_red。
- 両方のネットワークの 赤色の セキュリティ ゾーンを選択します。
- VNIを提供します。
- dc1_vn1_red の場合は 11001
- dc1_vn2_red の場合は 11002
- IPv4 接続 – 有効に設定します。
- 接続テンプレートの作成対象: タグ付き。
- IPv4 サブネットと仮想 IP ゲートウェイを指定します。
- dc1_vn1_red 10.11.1.0/24、10.11.1.1
- dc1_vn2_red 10.11.2.0/24、10.11.2.1
- リーフスイッチに割り当てます。
作成された仮想ネットワーク
図 45 に示すように、IRB ネットワークが作成され、接続テンプレートが追加されてリーフ スイッチに割り当てられます。接続テンプレートの詳細については、Juniper Apstraユーザーガイドを参照してください。
仮想ネットワークの作成中に、接続テンプレートの作成が上記のタグとして選択されている場合、Apstraは接続テンプレートを作成し、仮想ネットワーク用に自動的に生成します。
[ブループリント > ステージングされた>接続テンプレート(Blueprint Staged Connectivity Templates)] に移動してテンプレートを表示し、リーフ スイッチに割り当てます。リーフスイッチに割り当てると、タグ付き集合型イーサネットインターフェイスが作成され、サーバーが接続されます。
に割り当てる
次に、[ Blueprint > Uncommitted ] に移動して、コミットされていない変更を確認し、オーバーレイ設定をコミットします。または、物理 >ノード>>ステージングされたブループリント に移動して、オーバーレイネットワークが作成される各リーフスイッチに対して生成された設定を確認し、設定を確認します。
青と赤のネットワークのオーバーレイ接続の確認
Apstra UIで変更をコミットすると、その変更がスイッチに適用されます。
ファブリックの設定の検証を開始するには、各リーフスイッチのコンソールにログインします。
リーフ スイッチの CLI から、以下のコマンドを入力します。
! //begin QFX leaf switch commands// show interfaces irb terse show vlans instance evpn-1 vn1101 show vlans instance evpn-1 vn1102 show vlans instance evpn-1 vn1201 show vlans instance evpn-1 vn1202 !
この出力は、複数の IRB インターフェイスと、青と赤のネットワークに設定されたルーティング インスタンスを表示します。
赤色 リーフ スイッチの 1 つのネットワーク IRB:
{master:0}
root@dc1-esi-001-leaf1> show interfaces irb terse | match 10.11.*.1/24
irb.1101 up up inet 10.11.1.1/24
irb.1102 up up inet 10.11.2.1/24
ブルー ネットワーク リーフ スイッチの 1 つの IRB:
{master:0}
root@dc1-esi-001-leaf1> show interfaces irb terse | match 10.12.*.1/24
irb.1201 up up inet 10.12.1.1/24
irb.1202 up up inet 10.12.2.1/24
現在、ApstraはデフォルトでMAC-VRFルーティングモードを使用しているため、red と blue のすべてのネットワークVLANについて、以下のコマンド出力から同じことがわかります。
{master:0}
root@dc1-esi-001-leaf1> show vlans instance evpn-1 vn1101
Routing instance VLAN name Tag Interfaces
evpn-1 vn1101 1101
vtep-15.32772*
xe-0/0/50:0.0*
{master:0}
root@dc1-esi-001-leaf1> show vlans instance evpn-1 vn1102
Routing instance VLAN name Tag Interfaces
evpn-1 vn1102 1102
vtep-15.32772*
{master:0}
root@dc1-esi-001-leaf1> show vlans instance evpn-1 vn1201
Routing instance VLAN name Tag Interfaces
evpn-1 vn1201 1201
ae1.0
ae3.0*
et-0/0/52.0*
et-0/0/53.0*
vtep-15.32771*
vtep-15.32772*
vtep-15.32776*
vtep-15.32777*
xe-0/0/50:0.0*
{master:0}
root@dc1-esi-001-leaf1> show vlans instance evpn-1 vn1202
Routing instance VLAN name Tag Interfaces
evpn-1 vn1202 1202
ae2.0*
et-0/0/52.0*
et-0/0/53.0*
vtep-15.32771*
vtep-15.32772*
vtep-15.32776*
vtep-15.32777*
リーフスイッチに ERB が設定されていることを確認する
リーフスイッチの CLI 内で、以下のコマンドを入力します。
! //begin QFX CLI commands// show evpn database | match irb.110 show evpn database | match irb.120 !
このコマンドの出力には、すべてのスイッチ上の分散ゲートウェイが表示されます。
ゲートウェイは、赤のネットワークには 10.11.1.1、10.11.2.1、青のネットワークには 10.12.1.1、10.12.2.1 を表示します。これらの IRB 設定は、接続テンプレートで割り当てられたデバイスにのみ適用されます。他のファブリック スイッチには、接続テンプレートを介して割り当てられない限り、この IRB は設定されません。
{master:0}
root@dc1-esi-001-leaf1> show evpn database | match irb.110
11001 00:1c:73:00:00:01 irb.1101 Feb 28 11:33:36 10.11.1.1
11002 00:1c:73:00:00:01 irb.1102 Feb 28 11:33:36 10.11.2.1
{master:0}
root@dc1-esi-001-leaf1> show evpn database | match irb.120
12001 00:1c:73:00:00:01 irb.1201 Feb 28 11:33:22 10.12.1.1
12002 00:1c:73:00:00:01 irb.1202 Feb 28 11:33:22 10.12.2.1
リーフスイッチルーティングテーブルの確認
リーフスイッチの CLI 内で、以下のコマンドを入力します。
! //begin QFX CLI commands// show route table red.inet.0 10.11.1.0/24 show route table red.inet.0 10.11.2.0/24 show route table blue.inet.0 10.12.1.0/24 show route table blue.inet.0 10.12.2.0/24 !
このコマンドの出力には、リーフ スイッチの 1 つの VRF Red ネットワークのルートが表示されます。
{master:0}
root@dc1-esi-001-leaf1> show route table red.inet.0 10.11.1.0/24
red.inet.0: 1811 destinations, 3372 routes (1811 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
10.11.1.0/24 *[Direct/0] 06:21:33
> via irb.1101
[EVPN/170] 06:14:27
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 00:15:18
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 00:17:59
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
10.11.1.1/32 *[Local/0] 06:21:33
Local via irb.1101
{master:0}
root@dc1-esi-001-leaf1> show route table red.inet.0 10.11.2.0/24
red.inet.0: 3061 destinations, 4622 routes (3061 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
10.11.2.0/24 *[Direct/0] 06:23:38
> via irb.1102
[EVPN/170] 06:16:32
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 00:17:43
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 00:19:44
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
10.11.2.1/32 *[Local/0] 06:23:38
Local via irb.1102
このコマンドの出力には、リーフ スイッチの 1 つの VRF ブルー ネットワークのルートが表示されます。
{master:0}
root@dc1-esi-001-leaf1> show route table blue.inet.0 10.12.1.0/24
blue.inet.0: 3087 destinations, 4650 routes (3087 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
10.12.1.0/24 *[Direct/0] 06:26:21
> via irb.1201
[EVPN/170] 06:26:02
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 06:26:04
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 06:19:10
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 05:58:16
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 00:19:51
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 00:22:32
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
10.12.1.1/32 *[Local/0] 06:26:21
Local via irb.1201
{master:0}
root@dc1-esi-001-leaf1> show route table blue.inet.0 10.12.2.0/24
blue.inet.0: 3087 destinations, 4650 routes (3087 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
10.12.2.0/24 *[Direct/0] 06:26:26
> via irb.1202
[EVPN/170] 06:26:07
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 06:26:09
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 06:19:15
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 06:20:38
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 00:20:16
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 00:22:17
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
10.12.2.1/32 *[Local/0] 06:26:26
Local via irb.1202
以下のコマンドは、ESI リーフ スイッチのオーバーレイを示しています。これは、リモート リーフ VNI が ESI リーフ スイッチ間で交換されていることを示しています。
{master:0}
root@dc1-esi-001-leaf1> show ethernet-switching vxlan-tunnel-end-point remote
Logical System Name Id SVTEP-IP IFL L3-Idx SVTEP-Mode ELP-SVTEP-IP
<default> 0 192.168.255.4 lo0.0 0
RVTEP-IP L2-RTT IFL-Idx Interface NH-Id RVTEP-Mode ELP-IP Flags
192.168.255.5 evpn-1 671088642 vtep-15.32772 7000 RNVE
VNID MC-Group-IP
11001 0.0.0.0
11002 0.0.0.0
12001 0.0.0.0
12002 0.0.0.0
{master:0}
root@dc1-esi-001-leaf2> show ethernet-switching vxlan-tunnel-end-point remote
Logical System Name Id SVTEP-IP IFL L3-Idx SVTEP-Mode ELP-SVTEP-IP
<default> 0 192.168.255.5 lo0.0 0
RVTEP-IP IFL-Idx Interface NH-Id RVTEP-Mode ELP-IP Flags
192.168.254.2 1388 vtep.32771 4989 RNVE
192.168.255.2 1391 vtep.32774 4995 RNVE
192.168.254.3 1389 vtep.32772 4991 RNVE
192.168.255.3 1390 vtep.32773 4994 RNVE
192.168.255.4 1393 vtep.32776 5392 RNVE
192.168.255.6 1392 vtep.32775 4996 RNVE
192.168.255.7 1381 vtep.32777 5811 RNVE
192.168.255.8 1394 vtep.32770 5845 RNVE
L2-RTT IFL-Idx Interface NH-Id RVTEP-Mode ELP-IP Flags
192.168.255.4 evpn-1 671088646 vtep-15.32776 5392 RNVE
VNID MC-Group-IP
12002 0.0.0.0
11002 0.0.0.0
11001 0.0.0.0
12001 0.0.0.0
外部ルーターと VRF 間ルーティングの設定
このJVDでは、MX204ルーターを外部ルーターとして使用し、外部ルーティングを実行し、RedネットワークとBlueネットワーク間のVRF間ルート漏洩にも使用します。外部ルーターの設定は、汎用サーバーの追加と似ています。MX204ルーターは、データセンターファブリックへの外部ゲートウェイとして機能する境界リーフスイッチに接続されています。
MXルーターを外部ルーターとして追加するには、Apstra UIの [Blueprint > Staged > Topology ]に移動し、境界リーフスイッチをクリックして、外部汎用システムと外部汎用システムへの接続を追加します(図 50を参照)。
次の図で、ボーダーリーフ1のインターフェイスとMX204デバイスとそのインターフェイスを選択し、[ リンクの追加]をクリックします。
としての MX204 の追加
次に、[ Stage > Policies] > [Routing Policies ]に移動し、外部ルーターにルートをエクスポートするための外部ルーティングポリシーを作成します。次に、このポリシーを接続テンプレートに適用して、次の手順で説明するように、赤と青のネットワーク ルートをエクスポートできるようにします。
次に、ブループリント上の接続テンプレートに移動し、以下の接続テンプレートを追加して、IPリンク、BGPピアリング、MX204(外部ルーター)でのルーティングポリシーを追加します。このJVDの場合、赤と青のネットワークはMX204にルーティングされ、そこでVRF間ルーティングが実行されます。VLAN 299 は赤のネットワークに使用され、VLAN 399 は青のネットワークに使用されます。
図:赤と青のVRFのIPリンク
図:赤と青のVRF向けMXへのBGPピアリング
図:赤と青のVRFのルーティングポリシー
次に、[ Staged > Virtual > Routing Zone ] に移動し、[ Red VRF Network ] をクリックして下にスクロールし、両方の境界リーフ スイッチからの IP インターフェイス リンクを追加します。同じことが青色VRFネットワークに対しても実行されます。
の IP インターフェイス リンクの追加
の IP インターフェイス リンクの追加
ブループリントをコミットして、2 つの境界リーフスイッチに設定をプッシュします。ApstraはMX204を管理しないため、外部ルーターは手動で設定する必要があります。MX204ルーターの設定では、インターフェイスは上記の 図48 と 図56で使用したIPを使用して設定されます。
red と blue ネットワーク用の MX204 設定スニペット:
xe-0/0/2:0 {
vlan-tagging;
unit 0 {
vlan-id 0;
family inet;
}
unit 299 {
vlan-id 299;
family inet {
address 10.200.0.5/31;
}
family inet6 {
address 2001:db8:dc1:10:200::5/127;
}
}
unit 399 {
vlan-id 399;
family inet {
address 10.200.0.9/31;
}
family inet6 {
address 2001:db8:dc1:10:200::9/127;
}
}
}
xe-0/0/2:1 {
vlan-tagging;
unit 0 {
vlan-id 0;
family inet;
}
unit 299 {
vlan-id 299;
family inet {
address 10.200.0.7/31;
}
family inet6 {
address 2001:db8:dc1:10:200::7/127;
}
}
unit 399 {
vlan-id 399;
family inet {
address 10.200.0.11/31;
}
family inet6 {
address 2001:db8:dc1:10:200::b/127;
}
}
}
VRF 間ルーティングでは、Red と Blue の VRF ネットワーク間で VRF 間ルーティングを有効にするために、以下のように MX でポリシーが設定されます。両方のVRFは、MX204(外部ルーター)とのBGPピアへの境界リーフスイッチで設定されます。MX204は、BGPルーティングポリシーを使用してVRF間ルートを交換します。
Apstraでは、外部ルーターを必要とせずに、RedネットワークとBlueネットワーク間のVRF間ルーティングを設定することもできます。詳細については、 Apstraガイド を参照してください。設定に加えられた変更は、徹底的にテストすることをお勧めします。このJVDでは、「Route Target Overlaps Allow internal route-target policies」設定は使用されませんでした。この設定を「警告なし」に設定すると、赤や青などの各ルーティングゾーンを変更して、Apstra内のインポートおよびエクスポートルートターゲットポリシーを使用してルートターゲットを交換できます。
VRF 間の MX204 設定スニペット:
root@must-mx204-1> show configuration policy-options policy-statement RoutesToFabric
term 1 {
from interface lo0.0;
then accept;
}
term 2 {
from {
protocol [ static bgp ];
route-filter 0.0.0.0/0 exact;
}
then accept;
}
term 3 {
from {
protocol [ static bgp ];
rib inet6.0;
route-filter::/0 exact;
}
then accept;
}
term 4 {
then reject;
}
root@must-mx204-1> show configuration protocols bgp
group fabric {
type external;
multihop {
ttl 1;
}
multipath {
multiple-as;
}
neighbor 10.200.0.4 {
export RoutesToFabric;
peer-as 64514;
}
neighbor 2001:db8:dc1:10:200::4 {
export RoutesToFabric;
peer-as 64514;
}
neighbor 10.200.0.8 {
export RoutesToFabric;
peer-as 64514;
}
neighbor 2001:db8:dc1:10:200::8 {
export RoutesToFabric;
peer-as 64514;
}
neighbor 10.200.0.6 {
export RoutesToFabric;
peer-as 64515;
}
neighbor 2001:db8:dc1:10:200::6 {
export RoutesToFabric;
peer-as 64515;
}
neighbor 10.200.0.10 {
export RoutesToFabric;
peer-as 64515;
}
neighbor 2001:db8:dc1:10:200::a {
export RoutesToFabric;
peer-as 64515;
}
}
Apstra UI: 設計図ダッシュボード、分析、プローブ、異常
マネージドスイッチは、スイッチの健全性とネットワークの健全性に関する膨大な量のデータを生成します。これらをデータセンターネットワークに関して分析するために、Apstraは、グラフ1 からのインテントとスイッチが生成したデータを組み合わせたインテントベース分析を使用し、Apstraダッシュボードを使用してデータセンターネットワークビューを提供します。
Apstraでは、グラフモデルを使用してデータセンターのインフラストラクチャやポリシーなどを表現します。ネットワークに関するすべての情報は、ノードおよびノード間の関係としてモデル化されます。グラフモデルは、データを照会し、分析と自動化に使用できます。Apstraグラフモデルとクエリの詳細については、 Apstraユーザーガイドを参照してください。
分析ダッシュボード、異常、プローブ、レポート
Apstraには、デバイスからデータを収集する定義済みのダッシュボードも用意されています。Apstraは、IBAプローブを使用して、インテントとデータを組み合わせ、ネットワークに関するリアルタイムのインサイトを提供します。インサイトは、Apstra GUIまたはRest APIを使用して検査できます。IBAプローブは、しきい値に基づいて異常を発生させるように設定できます。プローブによって生成されたデータ量を分析して、Apstraサーバーのディスク容量がIBA操作に対応できることを確認することが推奨されています。ログローテーションの設定を調整することで、ディスク使用量を減らすことができます。
Apstraでは、カスタムダッシュボードを作成できます。詳細については、 Apstraユーザーガイド を参照してください。ブループリントから [Analytics > Dashboards ] に移動して、分析ダッシュボードを表示します。
分析ダッシュボードには、すべてのデバイスの正常性ステータスのステータスが表示されます。異常が発生した場合は、[異常]タブをクリックして異常を表示します。[ブループリントの異常]タブには、IBAプローブで異常が検出されなかった場合に、「異常はありません!」というメッセージが表示されます。詳細については、 Apstraユーザーガイドを参照してください。
構成されたプローブを表示するには、[ Blueprint > Analytics > Probes] に移動します。ここでは、プローブを編集、複製、または削除するアクションを実行できます。例えば、プローブの異常を抑制する必要がある場合、プローブを編集することで同じことを行うことができます。
異常を発生または抑制するには、[ 異常発生(Raise Anomaly )] チェックボックスをオンまたはオフにします。
図:プローブ異常の設定
レポートを生成するには、[ Blueprints > Analytics > Reports] に移動します。ここでは、レポートをダウンロードして、状態やデバイスのトラフィックなどを分析できます。
の生成
Root Causes Identification (RCI)(根本原因の特定)は、Apstraソフトウェアに組み込まれている技術で、複雑なネットワークの問題を自動的に特定します。RCIは、リアルタイムネットワークステータス用のApstraデータストアを利用し、自動的にテレメトリを各ブループリントインテントと関連付けます。根本的原因のユースケースとしては、リンクのダウン、リンクのケーブルミス、インターフェイスのダウン、リンクの切断などが挙げられます。
の有効化
の根本原因