テクノロジー解説

Cisco IOS フル活用への道: 第 5 回 IOS 搭載機能の活用例(後編)

前回は、主に EEM を利用した活用法についてご紹介しましたが、Flexible NetFlow(FNF)IP SLA による測定結果を EEM のイベント検出機能(イベント ディテクタ)に連携させ、ネットワークの状態に基づいて EEM でアクションを実行させることも可能です。今回は、FNF や IP SLA と EEM を連携させた利用法を中心に紹介します。

1. ネットワーク サービス レベルに対応した自動処理

IP SLA オペレーションで監視するサービス レベルに一定の閾値を設け、ネットワーク サービス品質の状態に応じて EEM のアクションを起動します。

ip sla 101
 http get http://www.cisco.com
ip sla schedule 101 life forever start-time now

ip sla reaction-configuration 101 react rtt threshold-value 700 500 threshold-type immediate action-type trapOnly

ip sla enable reaction-alerts

event manager applet ipsla-101-react
 event ipsla operation-id 101 reaction-type rtt
 action 1.0 syslog msg "IPSLA reaction detected."
 action 2.0 if $_ipsla_measured_threshold_value gt $_ipsla_threshold_rising
 action 3.0  puts "Rising threshold"
 action 4.0 else
 action 5.0  puts "Falling threshold"
 action 6.0 end

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>
        match ipv4 ttl
        match ipv4 source address
        match ipv4 destination address
flow monitor <my-monitor>
        record <my-record>

event manager applet my-ttl-applet
        event nf monitor-name "my-ttl-monitor" event-type create event1 entry-value "5" field ipv4 ttl entry-op lt
action 1.0 syslog msg “Low-TTL flow from $_nf_source_address"

* EEM NetFlowイベント検出によるアクション


FNF を使用すると、フロー キーやノン キーをフレキシブルに設定できます。EEM の NetFlow イベント検出を使えば、FNF により蓄積されたフロー キャッシュをさまざまな条件で監視し、条件にマッチするフローが検出された場合に EEM のアクションに結びつけることができます。

この例では、IPv4フィールドのTTL値が5未満のフローが検出された場合にアクションが起動されます。アクションは、一例として検出されたフローの送信元アドレスをSyslogで出力するようになっていますが、もちろん様々なアクションが設定できます。

FNF だけでも幅広い応用が考えられますが、このようにEEM と組み合わせることでさらに利用シーンが広がります。

3. アプリケーション フローの監視

2. のバリエーションです。アプリケーションごとに、どの IP アドレス ペアで、どのくらいの流量で通信が行われたかを、FNF で監視します。

flow exporter <my-exporter>
        destination 10.10.10.1
:
flow record <my-record>
        match ipv4 source address
        match ipv4 destination address
        match application name

        collect counter bytes
:
flow monitor <my-monitor>
        record <my-record>
        exporter <my-exporter>
:
interface <my-interface>
        ip flow monitor <my-monitor> input
:

router# show flow monitor <my-monitor> cache
Cache type: Normal
Cache size: 4096
Current entries: 2
High Watermark: 9

Flows added: 4464
Flows aged: 4463
- Active timeout ( 1800 secs) 0
- Inactive timeout ( 15 secs) 4463
- Event aged 0
- Watermark aged 0
- Emergency aged 0

IPV4 SRC ADDR
===============
10.55.146.53
10.51.81.117
IPV4 DST ADDR
===============
10.51.89.177
10.51.89.177
APP NAME
==================
nbar ssh
nbar icmp
bytes
==========
10484
1000

* 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 によって管理者にメールで通知し、怪しいトラフィックを遮断します。

このページのコンテンツには、Adobe Flash Player の最新バージョンが必要です。

Adobe Flash Player を取得

たとえば、ネットワーク アドレス 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 を定期的に監視し、カウンタが増加した場合に一度だけイベントを発行し、あらかじめ設定したログを取得します。

このページのコンテンツには、Adobe Flash Player の最新バージョンが必要です。

Adobe Flash Player を取得

ここでは、BRI の overrun のカウンタアップ時の障害解析を例に取り挙げます。この場合、 show interfaces コマンドで確認すると次のようになっています。

c3825a#show int bri 0/0/0
BRI0/0/0 is down, line protocol is down
      :                   :
0 input errors, 0 CRC, 0 frame, 3 overrun, 0 ignored, 0 abort


* 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
 event tag BRI0 snmp oid 1.3.6.1.4.1.9.2.2.1.1.14.3 get-type exact entry-op ge entry-val 1 entry-type increment exit-op le exit-val 0 exit-type increment poll-interval 2
 event tag BRI1 snmp oid 1.3.6.1.4.1.9.2.2.1.1.14.4 get-type exact entry-op ge entry-val 1 entry-type increment exit-op le exit-val 0 exit-type increment poll-interval 2

*increment、exit-typeの活用


 trigger
  correlate event BRI0 or event BRI1

*マルチプルイベントコリレーション(相関)の活用


 action 1.0 snmp-trap strdata "Overrun detected by OID: $_snmp_oid"
 action 2.0 syslog msg "Overrun detected by OID: $_snmp_oid"

**$_snmp_oidは組込変数


 action 3.0 cli command "enable"
 action 3.1 cli command "show clock | append flash:/Overrun_ISDN.log"
 action 3.2 cli command "show interface bri 0/0/0 | append flash:/Overrun_ISDN.log"
 action 3.3 cli command "show interface bri 0/0/1 | append flash:/Overrun_ISDN.log"
 action 3.4 cli command "show isdn status | append flash:/Overrun_ISDN.log"

snmp-server enable traps event-manager


SNMP イベント検出は EEM でよく使われるイベント検出の 1 つです。IOS が自身に対して定期的に SNMP のポーリングを行い、特定の条件にマッチした場合のみイベントを発行します。

SNMP イベント検出は定期的に実行されます。Entry 条件では、1 以上の増分をマッチさせています。Exit 条件では、0 以上の増分をマッチ、つまり、まったく増分がない場合のマッチになります。これにより、増分が検出した場合にイベントが発行され(Entry)、増分が検出されない場合にイベントが停止します(Exit)。

EEM は基本的には 1 つのイベントに対してアクションを起動しますが、複数のイベントを関連付けて 1 つのイベントを発行することもできます(マルチプル イベント コリレーション)。この例では、2 つの異なるインターフェイスのどちらかでもエラー カウンタの増分が検出されたら、アクションが呼び出されます。他にも、MIB のチェックとインターフェイス カウンタの組み合わせや、オブジェクト トラッキングのステータスとインターフェイスの状態など、さまざまな条件を設定することができます。

お問い合わせ