キャンパスインフラストラクチャにおけるクロスドメイン可視性の実現

前提条件

運用シナリオ：アクセス層障害によるワイヤレスの低下

次の ITSI Glass Table は、キャンパスのヘルススコアが 50 で、つまり「低下している」ことを示しています。データセンター、支店、その他のセグメントはすべて正常です。そのため、対象範囲はすぐに確認されます。これはキャンパス特有の問題です。

運用ダッシュボード:影響の定量化

Splunk プラットフォームの運用コマンドセンターのメインダッシュボードには以下が表示されます。

• ヘルススコア:45%
• 36 件の重要課題から cisco:dnac:issue
• 100件以上の PSIRT アドバイザリーが提供しています cisco:dnac:securityadvisory
• レイヤー特有の影響

36 件の P1/P2 問題を掘り下げてみると、問題の量の急増ではなく、持続的な問題量の傾向がわかります。可用性と接続性のカテゴリが優勢です。

アクセスレイヤスイッチには、からの入出力エラーカウンタの上昇が表示されます cisco:dnac:devicehealth 。これにより、AP アップリンクが不安定になる物理的な根本原因が確認されました。

調査の背後にあるSPL

エンタープライズネットワークコマンドセンターに表示したい情報は、デバイスやトポロジによって異なります。含めたいと思われる検索例をいくつか示します。

目的 : AI ベースラインコンテキストを使用して Catalyst センターから P1/P2 の問題を明らかにする

`cisco_catalyst_app_index` sourcetype=cisco:dnac:issue cisco_catalyst_host="*" | search IssueSpecificCategory IN ("Availability", "Connectivity", "Security", "Wireless") 
| stats  
    latest(_time) AS last_seen,  
    latest(IssueName) AS issue_name,  
    latest(IssuePriority) AS priority,  
    latest(IssueStatus) AS status,  
    latest(IssueSpecificSummary) AS summary latest(IssueSpecificCategory) AS category 
     BY IssueID, DeviceName  
| convert ctime(last_seen) AS "Last Seen" 
| table "Last Seen", DeviceName, issue_name, priority, status, category ,summary 
| sort -last_seen 
| head 50 
| rename DeviceName AS "Device", issue_name AS "Issue", priority AS "Priority", status AS "Status", summary AS "Details" 

目的 : 受信した RSSI および SNR コンテキストでのワイヤレスクライアントのオンボーディング失敗

index=campus sourcetype="cisco:dnac:client" 
| where onboardingScore < 3 OR connectionStatus="failed" 
| stats count avg(rssi) AS avg_rssi avg(snr) AS avg_snr BY ssid apName site 
| where count > 5 
| eval signal_quality=case(avg_rssi > -65,"good", avg_rssi > -75,"marginal", true(),"poor") 
| sort -count 

目的 : AP 無線ヘルスからの高使用率と干渉を検知 cisco:dnac:devicehealth

`cisco_catalyst_app_index` sourcetype="cisco:dnac:devicehealth" (cisco_dnac_host="*" OR cisco_catalyst_host="*") DeviceFamily="Unified AP" 
| stats avg(UtilizationRadio0) AS u24, avg(UtilizationRadio1) AS u50,  
        avg(NoiseHealthRadio0) AS n24, avg(NoiseHealthRadio1) AS n50,  
        avg(InterferenceHealthRadio0) AS i24, avg(InterferenceHealthRadio1) AS i50,  
        dc(DeviceID) AS count 
| eval data="2.4 GHz,".u24.",".n24.",".i24.",".count."|5 GHz,".u50.",".n50.",".i50.",".count 
| makemv delim="|" data 
| mvexpand data 
| rex field=data "(?<Band>[^,]+),(?<avg_util>[^,]+),(?<avg_noise>[^,]+),(?<avg_interference>[^,]+),(?<ap_count>.+)" 
| eval avg_util=round(coalesce(avg_util,0),1),  
       avg_noise=round(coalesce(avg_noise,0),1),  
       avg_interference=round(coalesce(avg_interference,0),1), 
       ap_count=coalesce(ap_count, 0) 
| table Band avg_util avg_noise avg_interference ap_count 

目的 : アクセス層のデバイスインターフェイスエラー。物理的な根本原因を突き止めてください。

`cisco_catalyst_app_index` sourcetype="cisco:dnac:issue" cisco_catalyst_host="*"  
(IssueSpecificName="*interface*error*" OR IssueSpecificDescription="*interface*error*") 
| eval domain=case(match(DeviceFamily,"(?i)Unified AP|Wireless"), "Wireless",  
                   match(DeviceFamily,"(?i)Switches|Switch"), "Wired",  
                   match(DeviceFamily,"(?i)Routers"), "Routing",  
                   1=1, "Other") 
| search domain="*" 
| rex field=IssueSpecificDescription "interface\s+'(?<interface_name>[^']+)'" 
| stats latest(_time) AS last_seen,  
        latest(IssuePriority) AS priority,  
        latest(DeviceRole) AS role, 
        latest(IssueSpecificSummary) AS summary,  
        latest(DeviceName) AS device, 
        latest(SiteNameHierarchy) AS site 
        by IssueID, interface_name 
| table last_seen, device, role, interface_name, priority, summary, site 
| rename last_seen AS "Last Detected", device AS "Device Name", role AS "Role", interface_name AS "Interface", priority AS "Prio", summary AS "Error Description", site AS "Site Location" 
| convert ctime("Last Detected") 
| sort -priority, -"Last Detected" 

要約:事後対応型のチケットから事前対応型の保証まで

Catalyst Center の AI 保証エンジンは、キャンパスドメイン内の問題を検出するための面倒な作業の多くを行います。これらの問題を、WAN、データセンター、セキュリティドメインを含む企業全体のサービスへの影響と関連付けることはできません。また、学習した行動ベースラインに基づいて予測アラートを発行し、問題が P1 インシデントになる 30 分前に検出することもありません。

Splunkソフトウェアは豊富なテレメトリ機能を活用します cisco:dnac:issue 、 cisco:dnac:devicehealth 、および cisco:dnac:client それをサービスコンテキストに入れます。ITSI サービスツリーはレイヤー間の依存関係を明確にします。適応型閾値処理モデルは、特定のキャンパスの健全性を学習し、一般的な閾値を超えたときではなく、何かが逸脱したときに起動します。

目標は簡単です。ユーザーがWi-Fiチケットを送信する前に、アクセスレイヤーの切り替えインターフェイスを修正することです。Splunk ソフトウェアはそれを可能にします。

次のステップ

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

• クロスドメインネットワークの問題のトラブルシューティングを数分で完了
• Meraki ブランチネットワークを大規模に運用
• Splunk によるエンタープライズ WAN サービスの保証
• MPLS バックボーンインフラストラクチャのリアルタイム監視
• MPLSからSRv6への移行をリアルタイムで保証します。