監視能力

可視化

NorthStar は、MPLS アンダーレイと選択型オーバーレイコントローラを備えています。発端は、トラフィックのポリシーと制御の集中化の増加をルートとしています。Illusory の単一画面ではなく、適切に定義されたトラフィックエンジニアリング機能を実装することで、接地された状態を維持します。

この章では、NorthStar の管理は行いませんが、既存の導入によって SR ネットワークに価値を付加することを目的としています。

さらに、私たちは接地したままにしています。まず、これ’までに構築したネットワークを可視化したいと思います。新しい BGP アドレスファミリー– link-state–は、エリア境界ルーター (ABR) と NorthStar’s Junos VM の間で有効になります。これにより、各 area –ノード、リンク、リンク属性、およびプレフィックスのトポロジがエクスポートされます。Junos と NorthStar はどちらも拡張され、SRGB 範囲、ノード、ナチュラル Sid など、SR 固有の機能のエクスポートをサポートするようになりました。

以下の構成をニューヨークとワシントン– p1 の両方の abr に適用します。 nyc、p2 nyc、p1、iad、p2、ルーター固有の値を適宜置き換えます。これにより、領域内のすべての Abr を構成してエリア固有のトポロジをエクスポートすることで、冗長性を実現できます。また、次のようにマルチレベルのネットワーク全体を網羅しています。

Nyc’がどちらのエリアからエクスポートしているのかについて詳しく見てみましょう。’各ノード、リンク、およびプレフィックスから1つの例を確認し、SR 属性によってその情報がどのように拡充されているかについて説明します。

Control plane: p1.nyc exporting pe2.nyc as a node, as well as its SR attributes

Control Plane: p1.nyc exporting the link between itself and pe1.nyc, and its local adjacency SID

Control plane: p1.nyc exporting pe2.iad’s prefix and associated SID index

NorthStar では、BGP-LS exchange の合計を使用して、とFigure 1Figure 2に示されているようにネットワークのグラフを構築できます。

Figure 1: デバイス構成の解析後に ASNs が検出されたトポロジの表示

Figure 2: NorthStar デバイスコレクション

NorthStar は、非マーシャリングの‘BGP-LS ルートだけでなく、netconf を介してデバイス設定を収集して解析することができます。’これを実行するには、’右上の [管理 > タスクスケジューラを使用して > > デバイスコレクションを追加します。非 root ユーザー’の認証情報を指定していることを確認してください。

デバイス構成の収集は必須ではありませんが、ユーザーエクスペリエンスが向上します。たとえば、ネットワークが接続されている ASNs が UI に表示されるようになります。レイヤー 3 VPN VRFs を掘り下げて、それぞれの PEs、接続回線、ルーティングターゲットを見つけることができます。これらは’BGP-LS によってエクスポートされているわけではありません。構成解析では、ネットワークの複数の側面を活用して運用を行います。

しかし、これはセグメントルーティングに関するガイドです。NorthStar は、いくつかの重要な SR 固有の可視化を実現しています。各リンクは、IP アドレスだけでなく、ローカルに割り当てられた隣接する SID も表示できます。これを選択するには、ワークスペースの歯車アイコンをクリックします (「+/- Figure 3ズーム」ボタンの下)。ここから、リンク > Show Label > IP、SID A:: Z のいずれかを選択します。

Figure 3: ナチュラル Sid が選択された Northstar のトポロジの表示

Outstandingly のもう1つの便利な機能は、ルーターを右クリックして選択したノードからノード sidを選択することです。他のルーターのラベルは、そのホスト名とともにノード SID を表示するように変更されています。これは、各ノード’s (現時点では IPv4 のみ) を、ルーター’の近隣のアドバタイズされた SRGB に追加することで発生します。

最適な方法として、SRGB ベースとサイズはネットワーク内で一貫したものに保たれています。この’ようなネットワークでは、この’機能だけではなく、lifesaver を使用することもできます。

NorthStar’の探索を、可視化ツールとして一時停止しました。’トラフィックエンジニアリングコントローラとして day job に戻りましょう。その時点で、’sr TE ポリシー (Sr TE lsp の適切な名前) を計算してプロビジョニングすることで、この視点のみの練習を行います。

Figure 4: Northstar は、単一ルーター’の視点をベースにしたノード Sid を示しています。

テレメトリ

この特質を実現するために’ 、Junos SR 実装では、SNMP を介して統計をエクスポートします。時代遅れは非常に知られていますが、SNMP は、より多くの機能を搭載したプロトコルとフレームワークによって情報を整理しています。

プロトコル正面、gRPC obsoletes SNMP。次のような HTTP/2 のメリットを継承しています。

• バイナリ: テキストの場合とは異なり、バイナリプロトコルのシリアライズと逆シリアル化により、空白の処理などの面での効率性とコンパクト性が向上し、エラーが発生しにくくなります。gRPC は、プロトコルバッファーを使用してデータのエンコードとデコードを行います。SNMP は ASN. 1 を使用します。

• 多重化: これにより、1つの TCP 接続で複数の未処理の要求を許可しながら、並列処理にも対応できます。実際には、SNMP は UDP ベースであり、保証されていない性質を継承しています。

• 双方向: このような場合、HTTP/2 を使用すると、サーバーは明示的に要求することなく、クライアントに潜在的に有用なデータをプッシュできます。

gRPC では、相互証明書ベースの認証をサポートしています。めったに使用されない SNMPv3 は、共有キー認証のみをサポートしています。また、gRPC は、イベント駆動型および定期的な公開/サブスクライブ方式の両方を提供します。これは、SNMP’s の統計のポーリングと同様に、要請されていないトラップに依存して状態の変化を伝えることに似ています。GRPC がより強力になっているのは、クライアントが状態情報ツリーのサブセットに関心を持つことができるという点です。その状態が変化すると、サーバーは更新をクライアント–に公開します。’これには、ルーターの ARP または ND テーブル、LSP 状態、et al が含まれることがあります。

この優れたトランスポートによって、ベンダーに依存しない方法でネットワークをモデリングするという、OpenConfig が採用されています。これは、SNMP’が情報–を整理するための方法 (MIB) –を改善しようとしているため、ベンダー中立のサポートが疎になる管理情報ベースです。構成と運用のデータモデルはどちらも、最も広く使用されている機能– (SR) の BGP、LLDP など、openconfig によって定義しています。他の人は works に残っています。

強力なトランスポートプロトコルと直観的なデータモデルの表現により、現代のテレメトリが事業者にとってより容易になります。

たとえば、インターフェース’s の運用ステータスの SNMP ポーリングは従来と同様に行われています。まず、インターフェイス’s ifIndex を発見する必要がありました。これは、デバイスによってインターフェイスに割り当てられた任意の整数値です。インターフェイス固有の状態とカウンターはすべて、そのインデックスを使用してキーが付けられます。長期にわたる環境では、ifIndex がキャッシュされ、再割り当てが必要になり、その結果、デバイスのリブートに relearned があります。そのインターフェイスに関連付けられた状態とカウンターをポーリングする必要があります。

IF-MIB::ifDescr1.3.6.1.2.1.2 の基礎となる OID –のわかりやすい略語です。MIB のすべての支社が、人間にわかりやすい表現を持っているわけではありません。それとは対照的に、OpenConfig とともに対応するサブツリーパスは /interfaces/interface[name=’ge-0/0/0’]/state/oper-status/。’この X パス構文において、演算子が初めて見慣れない場合でも、論理を考慮してインテントを理解することはできません。

GRPC トランスポートで OpenConfig を有効にしています

テストを目的として、gRPC トランスポートを有効にすることは容易ではありません。実稼働に備えた overwhelmingly は、証明書ベースの認証を意味しています。結果として、機能している公開鍵インフラ (PKI)、特に証明機関 (CA) を使用して、デジタル証明書を発行できなければなりません。

GRPC を有効にして保護するには、以下の6つのステップが必要です。

1. ルート CA をインスタンス化します。これは x86 ホスト上で実行する必要があります。次の例では、OpenSSL を使用してプライベートキー (key 拡張子) と自己署名証明書 (.crt 拡張子) を作成しています。

2. 次に、秘密鍵と証明書署名要求 (CSR、 .csr拡張) ができませんでした。この例では、jtimon は gRPC クライアントです。X86 ホストは、相互認証のためにその id を gRPC サーバー (ルーター) に提供するニーズに対して実行されます。以前に作成した CA が CSR でサインオフできるため、jtimon on で使用するための証明書が生成されます。

3. 各ルーターは、秘密鍵と CSR を生成する必要があります。CA は、前の手順と同様に各 CSR を fulfil して、それぞれのルーターの証明書を生成します。証明書と秘密鍵の両方がまとめられています (.pem内線番号) です。次の例は、pe1 を対象としています。 nyc:

4. ルート– CA’s および jtimon host’s 証明書と、ルーター’の所有するバンドル–を、3つの識別情報すべてにコピーする必要があります。 /var/tmp各ルーター上の位置。例として、pe1 では次のような結果が得られます。 nyc:

5. その後、証明書を構成によってアクティブ化する必要があります。次の例は、pe1 を対象としています。 nyc:

6. 最後に、gRPC はセキュアポートをリッスンして相互認証を必要とするように設定できます。ユーザーが jtimon –さんに提供しなければならないのは、[system login]ルーターの構成階層:

厳密にはテストの目的で、gRPC insecurely を使用してもかまいません。そのためには、自分の責任においてラボ環境の外部で行う必要があります。上記の手順1-5 をスキップし、ステップ6でスタンザと交換するには、以下を実行します。

SR テレメトリ

この背景について’は、どの SR 統計をストリーミングできるかを見てみましょう。最も基本的なことは、インターフェイスをはセグメントにルーティングされたトラフィックのボリュームです。このセンサーは、他の MPLS トランスポートプロトコルからの移行中に、転送プレーンの一部を SR からどの程度まで移動するかを区別することができます。

これは次のように設定できます。

これにより、SR の次ホップを持つ各インタフェースにセンサーがインストールされます。

Management plane: Verify the OpenConfig sensors have been installed

これで、これらの統計 (/mpls/signaling-protocols/segment-routing/interfaces/) をエクスポートする OpenConfig パスを購読できるようになりました。以下のようなファイルを使用して jtimon を構成します。必要に応じて、認証資格情報と証明書を秘密鍵および証書に置き換えます。

この構成について説明します。ルーターは、SR インターフェイス統計を10秒ごとに公開するよう要求されています。Jtimon を起動して、pe1 の nyc レポートを確認してください。

受信 PE としては、CEs からの着信 IP トラフィックが、nyc に接続されたインターフェイスを経由して SR ラベル付きで送信されることがわかります。’トラフィックの宛先は、その設定されたラベルを伝え’ないため、説明されません。カウンター名 (oc-84) は任意の番号を使用します。使用中のラベルには関係ありません。

Jtimon p1 on を指す nyc は双方向のトラフィックフローを示しています。パケットの受信/送信、0/0/2、および ge-0/0/3 –これらのインターフェイスは、それぞれ pe1 に nyc と pe2 に接続します。

最後のステップとして、nyc をインストルメントすると、SR トラフィック egressing ge-0/0/1 が表示さ’れます。これは pe2 です。 nyc s ローカルインターフェイス p1. nyc:

Eagle-eyed は、nyc が単一ノード SID 派生 MPLS ラベルの配置を確認する PE ルーター –よりも、平均パケットサイズが4バイト以上であることを示しています。

これは適切に開始されているため、より詳細な情報を得ることができます。SID 単位の統計 (特に、ドメイン全体の固定された SRGB) では、トラフィックマトリックスの計算に非常に役立ちます。これを実現するための設定は以下のとおりです。

Management plane: Verify additional OpenConfig sensors have been installed per-SID

追加センサーの配列が作成されました。受信した SID 別のセンサー名は、IPv4 および IPv6 ノードと、それに隣接する Sid に対応しています。送信方向では、基盤となるプロトコルとアドバタイズされたプレフィックス SID に基づいた名前が付いています。

次に、jtimon サブスクリプションのパスを以下のように変更します。 /mpls/signaling-protocols/segment-routing/aggregate-sid-counters/。Pe1 の詳細は、nyc、p1. nyc、pe2. nyc から SID ごとのトラフィックボリュームを含むようにしています。

Management plane: Per-SID statistics at pe1.nyc

Management plane: Per-SID statistics at p1.nyc

Management plane: Per-SID statistics at pe2.nyc

この点については、pe1 から pe2 に向かうトラフィック量を unerringly に示しています。nyc、その逆もあります。P1 を監視し’ています。 nyc s カウンターは、pe1 に送信されているトラフィックの量を示します。 nyc または pe2. 他の PEs から nyc。ユニバーサル SRGB では、各ルーターがノード SID に関連付けられたラベルに共通の理解を共有します。同じ MPLS ラベルに関連付けられたカウンターを合計することで、通信事業者は、各ルーターを通してノード SID の発信元に送信されているトラフィックの量を確認できます。プレフィックス SID に関連付けられたカウンターの累積数は、リモートルーターに送信されるトラフィックの量を示しています。これにより、トラフィックマトリックスの構築が大幅に簡素化されます。

SR TE テレメトリ

セグメントルーティングトラフィックエンジニアリング (SR TE) よりもテレメトリは重要ではありません。から有用の SR TE ポリシー –に指定されたトラフィックの量を大まかに把握するために– 、sr TE LSP はフィードバックループを開始します。これは、帯域幅のニーズと可用性に基づいて LSP を再ルートできる集中制御メカニズムによって使用できます。

テレメトリに焦点を当てた pe2 LSP は TE、nyc と pe1 の間に作成されています。これはカラーの LSP であるため、任意のローカルの重要な数値が割り当てられていることを意味します。サービスルートが BGP によって学習され、対応する値を持つ拡張カラーコミュニティを伝達する’と、そのルートのプロトコルのネクストホップは、この SR TE LSP に自動的に示されます。

カラーの LSP で解決するサービスルートに送信されるトラフィックは、SR TE 統計として計上しています。前に説明したように、SR TE テレメトリは次の方法で具体的に設定できます。

色分けされた SR TE LSP 構成は、次のような効果があります。

Management plane: confirm sensor is attached to SR-TE LSP

Control plane: confirm service route points at SR-TE LSP

デフォルトでは、SR TE LSP には2つのセンサーがアタッチされています。受信センサーは、ポリシーに対して送信される IP トラフィックの量を測定し、転送センサーは、ラベル付きトラフィックの similary を測定してポリシーに送信します。伝送センサーは、バインド SID (bsid)、さらにはローカルで重要なものであり、さらには、SR-TE ポリシーに関連付けられている場合は、MPLS ラベル付きトラフィックを LSP に誘導するために使用されます。

すべてのセグメントルーティングセンサーと同様に、ゼロ以外の統計が累積するまで、何もエクスポートされません。色付きのサービスルートと一致する IP トラフィックが到着すると同時に、カウンターは、gRPC クライアントによって要求された頻度で増加し、その後に公開されます。

Management plane: SR-TE IP statistics

IP ポリシー名は非常に直感的ですが、LSP のエンドポイントとその色が含まれています。バインド SID を使用して、この LSP にラベル付きトラフィック MPLS 転送された場合、ポリシー名には bSID 識別子がさらに含まれます。また、inarguable は’、IPV6 を SR として、スタック–全体にわたるファーストクラスの市民としています。これは、ipv6 エンドポイントに対して色付きの sr TE ポリシーを作成して、IPV6 トラフィックをその LSP に送信することから、その取り組みのためにテレメトリを受信することによって実現しました。

SR EPE テレメトリ

SR テレメトリの最後の適用は、送信ピアエンジニアリング(epe) を使用しています。大まかに言うと、自律システム境界ルーター (ASBR) は、ラベルを BGP ピア、特定の BGP ピアへのリンク、または BGP ピアセットに関連付けることができます。このラベルは、その ASBR’の転送プレーンにのみインストールされ、EPE SID として BGP-LS を介してコントローラにエクスポートします。コントローラは、特定の ASBR を越えて個別のピア、1つのピアへの一意のリンク、またはピアの集合体に至る、SR TE ポリシーを策定できます。

前述のように、SR TE LSP は nyc に pe1 の特定の BGP ピアにインストールされています。そのためには、pe1 ポリシーのセグメント TE リストの最下部に、iad に設定された EPE ラベルが存在する必要があります。SR-EPE テレメトリを明示的に有効にする必要があるのは、以下のようなことです。

Control plane: confirm sensor is installed for the EPE SID

Traffic matching the colored service route is transmitted, resulting in pe1.iad emitting telemetry for the EPE SID:

OAM (運用、管理、保守)

確かに、OAM は多くの場合、ネットワークエンジニアを対象にしています。’制御プレーンパスの活性だけではなく、データプレーンの検疫を検証するツールについては、実稼働環境で重要な点がある場合に限られます。

これは、パスシグナリングをなくすことで、SR TE にとってさらに重要になります。その代わりに、これを sBFD (シームレスな双方向転送検知) に委任しています。BFD は、データパスの障害を検知するための workhorse として使用されています。ポイントツーポイントの関係にある各ノードは、もう一方の’識別子、bfd のノードおよびアプリケーション識別子を学習することから始まります。この検出に続くと、BFD セッションが確立され、接続のチェックを行います。

sBFD は、discriminators の学習に必要なハンドシェークを排除することで、BFD を簡素化します。代わりに、少なくとも1つのローカル識別子がネットワークの各ノードに割り当てられます。SR TE パスの sBFD を確立するために、ヘッドエンドはリモートノード’の識別子で構成されています。

ヘッドエンドはイニシエーターとして動作し、SR TE パス’s ラベルを活性チェックパケットにプッシュし、パケットがユーザートラフィックと同じパスを通過することを確認します。SR TE ポリシーの宛先は、sBFD のパケットに応答します。SBFD セッションが受信ルーターで稼働している限り、SR TE パスは実行可能です。

ネットワーク内の各ノードに弁別子を追加することで、sBFD を構成できます。SBFD’の活性チェックを、pe2 から pe1 に定義した IPv4 SR TE パスに追加してみましょう。 iad:

この設定を追加した後は、sBFD 転送が2つのルーター間に同じラベルスタックを使用して存在している限り、SR TE パスは維持されます。

Control plane: Verify pe2.nyc’s sBFD session to pe1.iad is Up

Control plane: Verify pe2.nyc’s SR-TE policy has a valid path

最初のホップでは、隣接関係の SID を p1. nyc (21) に使用しています。Pe2 nyc と p1. nyc falters の間に隣接関係がある場合、この SR TE ポリシーはダウンします。

Control plane: Verify the SR-TE policy goes Down if the label stack is rendered unusable

ポリシーを利用するための代替 SID リスト (パスとも呼ばれる) はありません。ユーザートラフィックは、利用可能な場合、SR 以外の TE パスで解決されます。それとは対照的に、sBFD を活用して’いない静的に構成された SR TE のパスは、misleadingly アップしたままです。

Debuggability

テレメトリは、監視の1つの部分です。ネットワークのパフォーマンスと可用性のトラブルシューティングは、基盤となるプロトコルの明瞭さと利用可能な実装の診断とロギングに依存します。

SR’社がルーターの状態を最小化し、均一の SRGB を使用することで、人間がノード SID ラベルの転送アクション–を簡単に解析できるようになりました。 grok は少なくなっています。Junos は、人為的なエラーを検知する充実したログ機能により、このシンプルさを実現しています。

SRMS セクションでは、正しく設定されていないノード Sid がどのようにフラグになったかを示しています。SR によって異なる2種類の競合があります。

1. SID の競合: これは、同じプレフィックスに異なる Sid が割り当てられた場合にキャッチされます。

2. プレフィックスの競合: これは、異なるプリフィックスに同じ SID が割り当てられている場合に発生します。

前述の例では、SID の競合が示されていました。まず’、プレフィックスの競合を一時的に強制し、grpc を使用してイベントとしてストリーム配信します。従来の syslog はもちろん利用できますが、gRPC によってテレメトリ用の SNMP が成功するのと同じように、gRPC 上でもイベントを送信できるようになりました。

Jtimon を設定してサブスクリプションを構成しましょう’ /junos/events/。プレフィックスの競合を引き起こすには、pe1 が p1 に実際に所属する追加のループバックアドレスを使用して一時的に構成されます。 iad (128.49.106.9/32) これは、これらのアドレスを使用して共通のエニーキャスト Sid を生成した場合には問題ありません。Pe1 では、その代わりに、異なるプレフィックスインデックス (99) を p1 よりも誤ってアドバタイズしています。 IS-IS エクスポートポリシーを使用します。 iad (9)

Control plane: pe1.iad misconfiguration to cause a prefix conflict

Management plane: streamed system event about the prefix conflict

注意事項は beckoned であり、間違った構成が取り込まれています。SR は、人的介入が発生するまでの間、競合に対処するための拘束ルールをいくつか指定します。ルールが進化しています。この時点で、以下のことが実行されます。

1. IPv4 上で IPv6 エントリを優先

2. 最長プレフィックス長を優先

3. 最下位のプレフィックスアドレスを優先する

4. 数値の最も低いセグメントインデックスを好む

プレフィックスの競合は最初に解決されます。未解決のエントリーには、SID 競合の解決が続いています。それ’では、監視に注目して、optimizability に進んでください。