クロスドメインネットワークの問題を数分でトラブルシューティング

前提条件

運用シナリオ:ACI ブリッジドメインの撤回

次のステップは、カスタムビルドのネットワークモニターアプリのさまざまなダッシュボードと、各ダッシュボードに含まれるデータが、冒頭のシナリオで説明した Acme ネットワークの問題のトラブルシューティングにチームがどのように役立つかを示しています。これらのダッシュボードは以下に基づいて構築されています。 上記の KPI また、SPL は次の一部のダッシュボードパネルに提供されています。 以下の SPL セクション 。

調査の背後にあるSPL

ダッシュボード : BGP > アップストリーム

パネル : プレフィックスロス

目的 : シスコモデル駆動型テレメトリパイプラインからの正確な YANG パスを使用した BGP プレフィックス撤回検出

| mstats max("Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/vrfs/vrf/afs/af/neighbor-af-table/neighbor.af_data/prefixes_accepted") AS prefixes_accepted WHERE index="cisco_metrics" AND af_name="ipv4-unicast" span=1m BY neighbor_address, source
| search source=* neighbor_address=* 
| fields _time, source, neighbor_address, prefixes_accepted 
| search prefixes_accepted<4.000000

ダッシュボード : シスコ ACI

パネル : ブリッジドメイン非アクティブ

目的 : ACI 障害検出 — RCA コンテキストによるサーフェスブリッジドメインのオフラインイベント

| inputlookup bdlist.csv 
| fields "Bridge Domain Name" 
| eval key=trim('Bridge Domain Name') 
 
| join type=left key [ 
    search eventtype=cisco_dc_aci_health component=fvBD dn="uni/*" apic_host=apic-inb.maple.ciscolabs.com 
    | rex field=dn "tn-(?<TenantName>[^/]+)" 
    | search TenantName=Maple 
    | eval key=trim(name) 
    | stats latest(cur) AS cur BY key 
] 
 
| where isnull(cur) 
| rename key AS "Bridge Domain Name" 
| table "Bridge Domain Name" 

ダッシュボード : サウザンド・アイズ

パネル : ネットワークパケットロス

目的 : ThousandEyes のアベイラビリティとパケットロスを単一のタイムラインで相関させる

| tstats `summariesonly` avg(Test_Metrics.metric_name:network.loss) as avg_loss  FROM datamodel="Cisco_ThousandEyes.Test_Metrics" WHERE * * * * * (* OR NOT Test_Metrics.server.address="*") Test_Metrics.metric_name:network.loss="*" Test_Metrics.thousandeyes.test.type IN ("agent-to-server", "agent-to-agent") BY _time | timechart avg(avg_loss) AS avg_loss
| append [| tstats `summariesonly` avg(Test_Metrics.metric_name:network.loss) AS avg_loss  FROM datamodel="Cisco_ThousandEyes.Test_Metrics" WHERE * * * * * (* OR NOT Test_Metrics.server.address="*") Test_Metrics.metric_name:network.loss="*" Test_Metrics.thousandeyes.test.type IN ("agent-to-server", "agent-to-agent") ] 

ダッシュボード : ヴイエムウェアセックス

パネル :

目的 : VMware ネットワークドロップチェックにより、ESX が停止の原因になっていないことを確認する

index=vmware-perf sourcetype=vmware:perf:net instance=aggregated 
| stats sum(p_summation_net_droppedRx_number) AS dropped_rx, 
        sum(p_summation_net_droppedTx_number) AS dropped_tx, 
        sum(p_summation_net_errorsRx_number) AS errors_rx, 
        sum(p_summation_net_errorsTx_number) AS errors_tx 
         BY moid 
| where dropped_rx > 0 OR dropped_tx > 0 OR errors_rx > 0 OR errors_tx > 0 
| sort -dropped_rx 

ドメイン間の相関関係が MTTR を変える理由

これらのクエリはそれぞれ、タイムラインを共有する 1 つの Splunk インデックスに対して実行されます。ThousandEyes の可用性が BGP と同じタイミングでゼロになった場合 prefixes_accepted 相関関係がゼロになると、必要なのはクエリーだけで、45 分間の争議の余地はありません。

Splunk ITSI (ITSI) を使うと、生成される6,000件以上の未処理アラートを1つの構造化されたエピソードに圧縮できるため、さらに効果的です。以前は 6 つのチームが必要だったことを、1 人のエンジニアが数分で解決できます。

この ITSI サービスアナライザーは、ACME サービスが低下し、ACI ブリッジドメインの KPI がクリティカルとマークされ、ThousandEyes とアップストリーム KPI が低下したことを示しています。複合スコアは、寄与しているドメインごとに分類されています。

このダッシュボードには、6,000 件以上の未処理のアラートが 1 つのエピソードに圧縮されて表示されます。重要度タイムライン、寄与しているKPI、根本原因のコンテキストはすべて 1 つの構造化されたインシデントにまとめられています。

要約:業務上のシフト

従来のモデルでは、各チームに異なるツールが用意されていました。各ツールはそれぞれ独自の領域について正しく設定されており、それ以外の領域には見えません。ほとんどの場合がそうであるように、障害がドメインの境界を越える場合、調査は技術的な問題であると同時に調整上の問題にもなります。

Splunk ITSIは、共通データレイヤーとしてドメインツールよりも上位に位置します。Cisco DC ネットワーク TA、ThousandEyes アドオン、eStreamer、VMware アドオンはすべて、タイムラインを共有した共有インデックスにフィードされます。ACI ブリッジドメインの撤回と ThousandEyes のアベイラビリティ障害との関係は、誰も手作業で把握できるものではありません。どちらのイベントも ITSI では共通のサービスコンテキストを共有しているため、ダッシュボードに表示されます。

数分間のダウンタイムが収益への影響、SLAクレジット、顧客の信頼に直接つながるネットワークでは、Splunk ITSIはクロスドメイン保証を実現するための運用層であり、将来のロードマップ項目ではありません。

次のステップ

組織におけるネットワークアシュアランスの提供について詳しく知る準備はできていますか？このシリーズの他の記事もご覧ください。

• Meraki ブランチネットワークの大規模な運用
• Splunk によるエンタープライズ WAN サービスの保証
• キャンパスインフラストラクチャにおけるクロスドメイン可視性の実現
• MPLS バックボーンインフラストラクチャのリアルタイム監視
• MPLSからSRv6への移行をリアルタイムで保証します。