4.2トラフィック可視化と計測（NetFlow・SPAN・IP SLA）

「遅い」「たまに切れる」という曖昧な申告を、再現可能な数値に変えるのが可視化と計測の役割です。ここで重要なのは3つの手段が答えられる問いの種類が違うという点です。NetFlowは「どのホスト対がどれだけ帯域を使ったか」という集計を答えますがパケットの中身は見せません。SPAN/ERSPANは「そのパケットのDSCPやTCPフラグは実際どうなっているか」というパケット単位の事実を見せますが、常時流すと帯域を食います。IP SLAは「利用者がいない時間帯も含めて、この経路の遅延/ジッタ/到達性は継続的にどうか」を能動的に測り、しきい値超過を経路切替というアクションに結びつけられます。障害の問いに対して手段を取り違えないことが、この節の核心です。

4.2.1Flexible NetFlow の3部品

• flow record＝何をフローの識別子（キー）にし、何を集計値（非キー）にするかの定義。match ipv4 source address・match ipv4 destination address・match transport destination-portなどのmatchがキー、collect counter bytes・collect counter packets・collect interface outputなどのcollectが集計値。同じmatch値を持つパケットが1フローにまとめられるため、matchの粒度がそのまま分析の粒度になる（DSCP別に見たいならmatch ipv4 dscpが要る）。
• flow exporter＝集めたフローをどこへ送るかの定義。destination 10.50.0.20・transport udp 2055・source Loopback0・export-protocol netflow-v9（またはIPFIX）を指定する。exporterを定義しても単体では何も起きない点に注意。
• flow monitor＝recordとexporterを束ね、キャッシュを持つ実体。flow monitor MONの下でrecord REC・exporter EXP・cache timeout active 60を指定する。最後にインターフェイスへ適用して初めて計測が始まる＝interface GigabitEthernet0/1でip flow monitor MON input（必要ならoutputも）。「設定したのにキャッシュが空」の原因はこの適用漏れが圧倒的に多い。確認はshow flow monitor MON cacheとshow flow exporter statistics。

4.2.2SPAN / RSPAN / ERSPAN の適用範囲

• SPAN（ローカルSPAN）＝同一機器内で、監視元ポート/VLANのフレームを監視先ポートへ複製する。monitor session 1 source interface GigabitEthernet0/1 both＋monitor session 1 destination interface GigabitEthernet0/24。監視先ポートは通常のスイッチポートとしては機能しなくなる（既定で受信フレームを破棄し、STPにも参加しない）ため、アナライザ専用ポートを空けておく必要がある。
• RSPAN＝監視元と監視先が別スイッチの場合に、専用のRSPAN VLAN（vlan 900＋remote-span）にミラーを載せて運ぶ。経路上の全スイッチとトランクでそのRSPAN VLANが許可・伝搬されている必要がある＝あくまでL2の到達範囲内でしか使えない。ルータを挟むL3越えには使えない。
• ERSPAN＝ミラーしたフレームをGREでカプセル化して送るため、ルーテッドネットワーク（L3）を越えて遠隔のアナライザへ届けられる。monitor session 1 type erspan-source配下でsource interface ...・destinationにerspan-id 101・ip address 10.50.0.30・origin ip address 10.10.0.1を設定し、受信側はtype erspan-destinationで同じERSPAN IDを合わせる。ID不一致や経路上のMTU不足（GREヘッダ分）が典型的な不成立要因。

4.2.3IP SLA と トラック連動

• IP SLA＝機器自身が合成（synthetic）トラフィックを生成して、到達性・遅延・ジッタ・パケットロスを能動的に測る仕組み。ip sla 1／icmp-echo 203.0.113.10 source-interface GigabitEthernet0/0／frequency 10／ip sla schedule 1 life forever start-time nowが最小構成。結果はshow ip sla statisticsで確認する。
• 測定種別（operation）で答えられる問いが変わる：icmp-echo＝到達性/往復遅延、udp-jitter＝ジッタと片道遅延（VoIP品質の評価に用い、対向でip sla responderが必要）、http／dns＝アプリ層の応答時間、tcp-connect＝特定ポートの接続可否。VoIPのジッタを問われているのにicmp-echoを選ぶのは手段の取り違え。
• トラック（track）連動＝track 1 ip sla 1 reachabilityで測定結果をオブジェクト化し、ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 1のように静的経路に紐づけると、リンクは物理的にUPのままでも先で到達不能になった時点で経路が撤去され、バックアップ経路へ切り替わる。HSRPのstandby 1 track 1 decrement 30で優先度を下げてアクティブを移す使い方も定番。「リンクUPのままブラックホール化する」障害への正攻法。

支店のVoIP品質が平日の10時〜11時だけ劣化するという申告があり、支店ルータと本社のアナライザはWAN（L3ルーテッド）で隔てられています。ここで3つの問いを分けて考えるのが要点です。第一に「本当に品質が落ちているのか、どの程度か」を客観化する必要があり、これはIP SLAのudp-jitterオペレーションを支店ルータで常時走らせ（対向にip sla responderを置く）、show ip sla statisticsでジッタと片道遅延を時系列に取るのが正攻法です。icmp-echoでは往復遅延しか取れずジッタ評価に足りません。第二に「その時間帯に誰が帯域を食っているのか」を知る必要があり、これはFlexible NetFlowの仕事です。match ipv4 source address／match ipv4 destination address／match transport destination-portをキーにしたflow record、コレクタ宛のflow exporter、両者を束ねたflow monitorを作り、WAN側インターフェイスにip flow monitor MON inputで適用します（この適用を忘れるとshow flow monitor MON cacheが空のままで、「NetFlowが動かない」と誤解する典型パターンです）。第三に「音声パケットのDSCPが途中で書き換えられていないか」というパケット単位の事実確認が残り、これは集計であるNetFlowでは答えられず、パケットを複製する手段が要ります。ここでRSPANを選ぶのは誤りで、RSPANはRSPAN VLANのL2到達性を前提とするためWANを越えられません。ERSPANならミラーをGREでカプセル化してL3を越え、本社アナライザへ届けられます（erspan-idの一致とGREヘッダ分のMTU余裕が前提）。そして仮に原因が「10時台のバックアップ転送がWANを飽和させ、QoS未整備で音声が落ちている」と確定したなら、恒久策はQoSの是正ですが、暫定策としてtrackとip slaを連動させ、品質劣化時にセカンダリ回線へ切り替える構成も選択肢になります。問いごとに手段を選び分ける——これが計測設計の本質です。

4.2.4この節のまとめ

• Flexible NetFlowはflow record（matchがキー/collectが集計値）・flow exporter（送出先）・flow monitor（束ねてキャッシュ保持）の3部品で、インターフェイスへの適用で初めて計測が始まる。答えられるのは集計であってペイロードではない
• パケットそのものを見るならSPAN（同一機器）／RSPAN（RSPAN VLAN経由でL2到達範囲）／ERSPAN（GREでL3越え）を距離で選ぶ。SPAN監視先ポートは通常のスイッチポートとしては使えない
• IP SLAは合成トラフィックで到達性/遅延/ジッタを能動計測し（ジッタはudp-jitter＋レスポンダ）、trackと静的経路/HSRPを連動させればリンクUPのままのブラックホールでも自動的に迂回できる