このページの目次
スイッチアクション
概要 [アクション] ダッシュボードを使用して、スイッチに影響する問題を解決します。
[アクション] ダッシュボードの [切り替え] ボタンをクリックすると、使用可能なすべてのアクションのリストが表示されます。その後、アクションをクリックしてさらに調査できます。使用可能なアクションについては、このトピックの後半で説明します。
サブスクリプションによって、[アクション] ダッシュボードに表示されるアクションが決まります。詳細については、「 Marvis Actionsのサブスクリプション要件」を参照してください。
VLANの欠落
VLANが見つからないアクションは、VLANがAPには設定されているが、スイッチポートには設定されていないことを示しています。その結果、クライアントは特定の VLAN で通信できず、DHCP サーバーから IP アドレスを取得することもできません。Marvisは、APトラフィック上のVLANとスイッチポートトラフィック上のVLANを比較し、VLAN設定がないデバイスを特定します。
次の例では、Marvisは、VLAN設定がないために着信トラフィックが見えない2つのAPを識別します。また、Marvisは、VLAN設定が欠落している特定のスイッチを特定し、ポート情報を提供することで、この問題を簡単に軽減することができます。
さらに情報が必要な場合は、左側のメニューを使用して[スイッチ]ページに移動することもできます。そこで、スイッチをクリックして、VLANを含む各ポートの情報を表示します。
ネットワーク内の問題を修正した後、Mist AIがスイッチを一定期間監視し、欠落しているVLANの問題が実際に解決されていることを確認します。そのため、[VLAN不足]アクションが自動的に解決され、[最新の更新]セクションに表示されるまでに最大30分かかる場合があります。
VLANが見つからないアクションの詳細については、次のビデオをご覧ください。
Missing VLANs is a two-decade-old networking problem. It sounds so simple, but in a large enterprise it can become the ghost in the machine, as users complain their calls always drop in a certain area and conventional wisdom is, well, there must be interference or Wi-Fi issues over there. In many cases when Mist support helped troubleshoot, we found a user VLAN was indeed not provisioned on the network switch.
Hence, the user had no place to roam and the call dropped. For customers with tens of thousands of APs, this truly becomes the needle in the haystack problem. At Mist, we wanted to use AI to solve this problem, but first let's take a look at how you might start out today.
You can manually take a look, but I only have two VLANs. Or you can programmably take a look, but this makes my brain hurt. If an AP is connected to a switch port, but the user can't get an IP address or pass any traffic, then the VLAN probably isn't configured on the port or it's black holed.
The traditional way to measure a missing VLAN is to monitor traffic on the VLAN and if one VLAN continuously lacks traffic, then there's a high chance that the VLAN is missing on the switch port. The problem of this approach is false positives. Here you can see during a 24-hour window, we detected more than 33,000 APs missing one or more VLANs because they had little or no traffic, but this was not accurate as we learned that every VLAN is not created equal.
There are at least two types of special purpose VLANs that can cause detection problems. One is the black hole VLAN. Folks can create a black hole VLAN on all unconfigured ports or as a quarantine VLAN for users until they are fully authorized. This VLAN is supposed to be provisioned on the switch in case a quarantined user shows up on the AP. The second example is the over-provisioned VLAN. Larger customers use special VLANs for special sites.
For example, legacy devices might only be present at certain sites, so special VLAN should only be applicable to those sites, but because people do use automation, they want to keep their configurations consistent so they provision that VLAN across all the sites. In this case, you would expect low traffic or no traffic. Those VLANs shouldn't be flagged as missing because they were intentionally over-provisioned.
So the key for reducing false positives is to really identify the purpose of each VLAN. We could ask the customer for their own internal list, perhaps in the form of a spreadsheet, but that's very error prone. MIST developed an unsupervised machine learning model to automatically discover the purpose of each VLAN by learning from the traffic patterns on the VLANs.
In this graph, each dot represents all of the VLANs across the MIST customer base. So for each VLAN, we collect several features. How many APs lack traffic on that VLAN? How many sites lack traffic? How busy is that VLAN minute by minute from all the APs? Then we use another technique called principal component analysis to combine all of these features and map them into this two-dimensional space.
The interesting thing here is the different VLAN types, high traffic, low traffic, black hole, and over-provisioned are separated really well, even across different customers, because it turns out VLAN behavior is very similar across different customers. The beauty of this is instead of developing per customer anomaly detection tools, we actually built one model for everybody. So for any new customers, we don't have to ask them anything.
We can determine the purpose of their VLANs very quickly after they deploy. This is really the power of this multi-tenant infrastructure design. Every customer can benefit from the knowledge learned from our extended customer base.
By precisely identifying each VLAN's purpose, we reduced our initial detection rate from 33,000 plus to specifically 607 VLANs, which we believed were actually missing from the AP switch ports. For MIST, this was the moment of truth. When we were confident in the model, we contacted the customers with these 607 detected missing VLANs, and when we finally heard back, we had an astonishing 100% hit rate, no false positives.
For MIST, this was simply awesome, as there are so many mundane problems we can apply this technique to going forward. So right now, this is shown in Marvis Actions, and with a supported Juniper switch, we can provide the user specific CLI commands that we suggest they add to their config to get these missing VLANs going, with a goal to automatically doing this from the cloud as we gain their trust. And for non-Juniper switches, we give detailed info like which switch, which port, and which VLAN ID to guide them how to solve the problem that they probably didn't even know they had.
This is all built on open protocols like OpenConfig and NetConf. And lessons learned by the MIST data science team, AI solutions should first start by solving real problems, rather than deploying models and hoping for the best. Some AI vendors treat AI as a hammer in search of a nail, and this isn't going to work.
The Marvis AI engine was designed starting with human expertise and then learning over time. At MIST, each support ticket is first run through Marvis to both measure its efficacy and continue to train the model to solve the most important customer issues.
ネゴシエーションの不一致
ネゴシエーション不一致アクションは、ネゴシエーションが不完全なスイッチポート上のインスタンスを検出します。この問題は、自動ネゴシエーションで正しい二重モードの設定に失敗し、Marvisがデバイス間のデュプレックスの不一致を検出した場合に発生する可能性があります。Marvisは、影響を受けるポートの詳細を提供します。ポートと接続されているデバイスの構成を確認して、問題を解決できます。
次の例は、ネゴシエーション不一致アクションの詳細を示しています。Marvisに、ネゴシエーションの不一致が発生したスイッチとポートが表示されます。
ネットワークの問題を修正すると、[ネゴシエーションの不一致] アクションが自動的に解決され、1 時間以内に [最新の更新プログラム] セクションに表示されます。
ループが検出されました
「ループ検出(Loop Detected)」アクションは、ネットワークにループが発生し、その結果、スイッチが送信したのと同じパケットを受信するようになったことを示します。ループは、デバイス間に複数のリンクが存在する場合に発生します。冗長リンクは、L2 ループの一般的な原因です。冗長リンクは、プライマリ リンクのバックアップ リンクとして機能します。両方のリンクが同時にアクティブで、STP(スパニング ツリー プロトコル)などのプロトコルが適切に導入されていない場合、スイッチング ループが発生します。
Marvisは、トラフィックループが発生しているサイト内の正確な場所を特定し、影響を受けたスイッチを表示します。次に例を示します。
ポートフラップ
ポートフラップアクションは、短時間に持続的にバウンスするポートを識別し、ポートまたはクライアントに問題があることを示します。ポートのフラッピングは、信頼性の低い接続、ポートに接続されたデバイスの継続的な再起動、またはデュプレックス設定の誤りが原因で発生する可能性があります。以下の例は、Marvis Actionsがポートフラップアクションに対して提供する詳細を示しています。
永続的にフラッピングしているポートは、[Marvis Actions]ページから直接無効にできます。[ポート フラップ アクション] セクションで、ポートを無効にするスイッチを選択し、[ DISABLE PORT ] ボタンをクリックします。
[ポートの無効化] ページが表示され、無効にできるポートが一覧表示されます。ポートがすでに無効になっている場合(以前は[アクション]ページで、または[スイッチの詳細]ページから手動で)ポートを選択することはできません。
ポートを無効にすると、選択したポートのポート設定が無効に変わり、ポートがダウンします。問題を修正した後、[Switch Details](スイッチの詳細)ページでポート設定を編集して、これらのポートを再度有効にすることができます。ポートを再度有効にした後、デバイスをポートに再接続できます。
ネットワークの問題を解決すると、1 時間以内にポート フラップ アクションが自動的に解決され、[最新の更新プログラム] セクションに表示されます。
Looking at the switch, in this case, specifically the Juniper switch, we've introduced the action of a port flapping continuously. In this case, we do take into account a simple port down and up, which usually happens when a device connects, and this is currently reflecting a case where the port is continuously flapping, thereby not only causing a poor experience for the device which is connected on the other end, but also having high resource consumption for the switch which can be detrimental to other devices connected on the switch. Here too, we show all the required information in terms of the port, the client which is connected, and the VLAN, if in case it did communicate and we know the VLAN ID.
高 CPU
Marvisは、常にCPU使用率が高いスイッチを検出します。CPU 使用率が高くなる原因は、マルチキャスト トラフィック、ネットワーク ループ、ハードウェアの問題、デバイスの温度など、さまざまな要因です。[高 CPU] アクションには、スイッチ、スイッチで実行されているプロセス、CPU 使用率、および高使用率の理由が一覧表示されます。次の例では、fxpc プロセスの CPU 使用率が高く、使用率が高い原因はスイッチでの非認定光インターフェイスの使用であることがわかります。
ポートスタック
Port Stuck アクションは、パケットが送受信されていないなど、スイッチ ポートのトラフィック パターンの違いを検出し、ポートに接続されているクライアントが正常に動作していないことを示します。次の例では、Marvis Actionsがポートをバウンスし、クライアントが正常に動作し始めるかどうかを確認することを推奨していることがわかります。Marvisには、ポート番号に加えて、ポートおよび関連するVLANに接続されているクライアント(この場合はカメラ)もリスト表示されます。
トラフィック異常
Marvisは、スイッチ上でブロードキャストおよびマルチキャストトラフィックの異常な減少または増加を検出します。また、異常に高い送信または受信エラーも検出します。接続障害の異常検出ビューと同様に、詳細ビューには、タイムライン、異常の説明、および影響を受けるポートの詳細が表示されます。問題がサイト全体に影響する場合、Marvisは影響を受ける各スイッチの詳細とポートの詳細を表示します。
Marvis, our AI-powered virtual network assistant, employs an actions framework to automatically identify network problems and anomalies that are likely impacting user experience. This helps you to significantly reduce mean time to resolution. Marvis can detect switched traffic anomalies, such as traffic storms or abnormal high TxRx count, with respect to broadcast, unknown, unicast, or multicast traffic.
It uses our third generation of algorithms, including long short-term memory, or LSTM for short, to boost efficacy and eliminate false positives. Visit the link below to learn more.