※以下の記事は、Cisco.com/jp 整理に伴って、 テクノロジー解説特集記事（2011年）を転載したものです。機能的に古い記載もありますが、2017 年現在でも有効である内容が多く、さらに進化を続けています。
前回は、主に EEM を利用した活用法についてご紹介しましたが、Flexible NetFlow（FNF）や IP SLA による測定結果を EEM のイベント検出機能（イベント ディテクタ）に連携させ、ネットワークの状態に基づいて EEM でアクションを実行させることも可能です。今回は、FNF や IP SLA と EEM を連携させた利用法を中心に紹介します。
1. ネットワーク サービス レベルに対応した自動処理
IP SLA オペレーションで監視するサービス レベルに一定の閾値を設け、ネットワーク サービス品質の状態に応じて EEM のアクションを起動します。
ip sla 101 |
IP SLA で各種プロトコルに応じたネットワーク サービス レベルの性能の測定を行います。
IP SLA 対応の商用アプリケーションを使用し、測定結果のレポーティングやグラフ化を行うこともできますが、ここでは IOS の設定により IP SLA の測定値に閾値を設け、非同期に SNMP Trap で SNMP マネージャに通知させています（IPSLA reaction-configuration）。
さらに、IPSLA reaction-configuration の通知を EEM のアクションに繋げる方法も紹介しています（IP SLA イベント検出）。Event ipsla を使うことで、IP SLA の非同期通知が行われた際の値を、IOS がシステム変数として提供できるようになります。$_ipsla_measured_threshold_value や $_ipsla_threshold_rising を比較したり分岐したりすることで、状況に応じたアクションを EEM により実行できます。
もちろん、action 3.0 や 5.0 の中身はメール通知に変えたり、コマンドを発行したりするなど、自由に設定できます。
2. TTL の短いフローの監視と通知
TTL（Time To Live） が短いフローは DOS 攻撃を受けるリスクが高まるため、FNF を用いて、TTL に焦点を当てた監視を行います。ここでは、EEM が TTL 5 未満のフローを検出すると、送信元 IP アドレス情報とともに Syslog で通知します。
flow record <my-record>event manager applet my-ttl-applet＊ EEM NetFlowイベント検出によるアクション |
FNF を使用すると、フロー キーやノン キーをフレキシブルに設定できます。EEM の NetFlow イベント検出を使えば、FNF により蓄積されたフロー キャッシュをさまざまな条件で監視し、条件にマッチするフローが検出された場合に EEM のアクションに結びつけることができます。
この例では、IPv4フィールドのTTL値が5未満のフローが検出された場合にアクションが起動されます。アクションは、一例として検出されたフローの送信元アドレスをSyslogで出力するようになっていますが、もちろん様々なアクションが設定できます。
FNF だけでも幅広い応用が考えられますが、このようにEEM と組み合わせることでさらに利用シーンが広がります。
3. アプリケーション フローの監視
2. のバリエーションです。アプリケーションごとに、どの IP アドレス ペアで、どのくらいの流量で通信が行われたかを、FNF で監視します。
|
＊ NBARアプリケーション＋IPアドレスペアごとのカウンタ、NetFlow出力（version 9）
IOS 15.0 から、NBAR によるアプリケーション識別を FNF によるフロー キーの 1 つとして利用できるようになりました。NBAR (Network Based Application Recognition)とは、IOS が提供する DPI（Deep Packet Inspection）機能の 1 つで、NetFlow がレイヤ 2〜4 までを扱うのに対し、NBAR はレイヤ 7 まで含めてステートフルに扱うことができ、アプリケーションの識別が可能です。
このため、広く活用されている NetFlow のメカニズムの中に NBAR を統合することで、より詳細なトラフィック監視・計画が可能となります。
4. パケット数が少ないフローの監視
パケット数の少ないフローは、正常なトラフィックである場合もありますが、TCP Syn 攻撃などの特殊なフローである可能性が考えられます。FNF で監視し、パケット数の少ないトラフィックを検出すると、EEM によって管理者にメールで通知し、怪しいトラフィックを遮断します。
たとえば、ネットワーク アドレス 10.10.10.0/24 宛に検出されたフローで、1 パケットまたは 2 パケットしかないトラフィックを監視するとします。
Router# show flow monitor <monitor> cache filter ipv4 destination address 10.10.10.0/24 counter packet regex[1-2] aggregate ipv4 source address ipv4 destination address sort highest flow top 100 |
この例では show コマンドでの確認のみを示していますが、EEM のアクションに結びつけることで、上の図で示したように、管理者に通知したり、自動的に対処したりすることができます。また、他にも TCP のフラグのバリエーションやフラグメント、パケット長、ルーティング情報（VRF やネクスト ホップなど）など、さまざまな項目に特化したモニタリングが可能です。
5. 高度な MIB のトラブルシューティング
不定期にある特定のカウンタが増加して障害が発生するという問題を抱えているとします。ログを取得して根本原因を特定する必要がありますが、不定期に発生するため、カウンタ アップ時にエンジニアが手動でログを取得するのは、現実的には困難です。
そこで、EEM の SNMP イベント検出を使って特定の OID を定期的に監視し、カウンタが増加した場合に一度だけイベントを発行し、あらかじめ設定したログを取得します。
ここでは、BRI の overrun のカウンタアップ時の障害解析を例に取り挙げます。この場合、 show interfaces コマンドで確認すると次のようになっています。
c3825a#show int bri 0/0/0＊ overrun のカウンタアップ |
overrun のカウンタは OLD-CISCO-INTERFACES-MIB の 1.3.6.1.4.1.9.2.2.1.1.14（オブジェクト locIfInOverrun）で取得可能なため、この増分を EEM で監視し、カウンタアップ時にアクションを実行させます。
また、ここでは監視対象のルータに BRI ポートが 2 つ存在するものとし、両方のインターフェイスを同時に監視しています（サンプル コマンドでは両方のインターフェイスを 1 つのポリシーでまとめています）。
event manager applet Overrun_ISDN＊increment、exit-typeの活用trigger
action 1.0 snmp-trap strdata “Overrun detected by OID: $_snmp_oid” ＊＊$_snmp_oidは組込変数 action 3.0 cli command “enable” snmp-server enable traps event-manager |
SNMP イベント検出は EEM でよく使われるイベント検出の 1 つです。IOS が自身に対して定期的に SNMP のポーリングを行い、特定の条件にマッチした場合のみイベントを発行します。
SNMP イベント検出は定期的に実行されます。Entry 条件では、1 以上の増分をマッチさせています。Exit 条件では、0 以上の増分をマッチ、つまり、まったく増分がない場合のマッチになります。これにより、増分が検出した場合にイベントが発行され（Entry）、増分が検出されない場合にイベントが停止します（Exit）。
EEM は基本的には 1 つのイベントに対してアクションを起動しますが、複数のイベントを関連付けて 1 つのイベントを発行することもできます（マルチプル イベント コリレーション）。この例では、2 つの異なるインターフェイスのどちらかでもエラー カウンタの増分が検出されたら、アクションが呼び出されます。他にも、MIB のチェックとインターフェイス カウンタの組み合わせや、オブジェクト トラッキングのステータスとインターフェイスの状態など、さまざまな条件を設定することができます。
Authors
