IP SLAの基本
IP SLA（Service Level Agreement）は、Cisco IOSに標準で備わっている監視機能で、ネットワークの性能を実際に測定する仕組みです。ルータが自ら測定用パケットを生成して送信し、応答を解析することで、遅延、ジッタ（揺らぎ）、パケットロスといった重要な情報を取得できます。PINGが単純に往復時間を測るのに対し、IP SLAはVoIPやアプリケーション通信に近い形で実際の品質を計測できる点が特徴です。
例えば、音声通話に例えると、相手の声が遅れて聞こえたり、途切れたりすることがあります。これはネットワーク遅延やジッタの影響であり、IP SLAを利用することでこうした品質低下の原因を可視化できます。
IP SLAのアーキテクチャ
IP SLAを実行して測定パケットを送信する機器を「IP SLA Sender」と呼びます。受信側となる機器は「Receiver」となり、測定内容によって要件が異なります。たとえば、ICMPエコー（PING相当）を使う場合は通常のネットワーク機器やサーバでもReceiverになれます。しかし、UDPジッタのように一方向の測定が必要な場合は、測定結果をSenderへ返す必要があるため、Receiverには「ip sla responder」機能を持つCisco IOS機器が必須です。
1つのCiscoルータがSenderとResponderの両方を担うことも可能で、拠点間の測定では多用されます。特にVoIPアプリケーションの品質測定にはResponderの設定が欠かせません。
IP SLAは動作フェーズが2段階に分かれています。最初の「コントロールフェーズ」でSenderとResponder間の通信が確立され、その後「プロービングフェーズ」で実際に測定パケットが送受信されます。この流れを理解しておくと、トラブルシューティングのときに役立ちます。
IP SLAとSNMPトラップ
IP SLAの測定結果はSNMPと連携させることができます。例えば「遅延が一定値を超えたらSNMPトラップを発生させる」といったしきい値の設定が可能です。コマンドで snmp-server enable traps rtr を有効化すると、RTT遅延やジッタ、MOS値などがしきい値を超えた場合に通知を送ることができます。これにより、監視サーバと連携した自動アラートの仕組みが作れます。
MOS値について
音声品質を測る指標として「MOS（Mean Opinion Score）」があります。これは本来、人が音声を聞いて1～5段階で評価する方法ですが、Cisco IOSはudp-jitter測定の結果から独自にMOS値を計算して表示します。
MOS値はおおまかに以下のように解釈されます。
| MOS値 | 音声品質 | コーデックとの関係 |
|---|---|---|
| 5 | 非常に良い | – |
| 4 | 良い | G.711では4.1以上が望ましい |
| 3 | 普通 | G.729では3.92以上が望ましい |
| 2 | 悪い | – |
| 1 | 非常に悪い | – |
MOSは絶対値ではなく、環境ごとに基準を持つことが重要です。つまり「社内のVoIP通話はMOSが4.0を下回ったら品質低下とみなす」といった基準を運用側が決める必要があります。
IP SLAで利用できるプロトコル
IP SLAは単なるPINGの拡張にとどまらず、多様なプロトコルを使った測定が可能です。例えばVoIP用のUDPジッタ測定では、実際の音声コーデック（G.711やG.729）をエミュレートして品質を評価できます。一方で、アプリケーション性能測定ではHTTPやFTPリクエストを送信し、応答時間を直接測定できます。
代表的な測定内容は以下のとおりです。
- UDPジッタ：片方向遅延、ジッタ、パケットロスを測定。VoIPバックボーンで使用。
- TCP Connect：サーバへの接続時間を測定。アプリ応答速度の評価に有効。
- DNS / DHCP / FTP / HTTP：各サービスの応答時間を測定。サーバ性能監視に利用。
- ICMPエコー / パスエコー / パスジッタ：ネットワーク全体の遅延や経路品質を把握。
こうした多様な測定により、IP SLAはネットワークとアプリケーションの両面で性能を監視できる強力なツールとなっています。
IP SLAを実行するルータの役割
IP SLAはアクティブモニタリングを行う機能なので、測定パケットを実際に生成・送出する「Sender」の負荷は決して軽くありません。特にVoIP品質を測るUDPジッタやMOSの算出などでは多くのパケットを処理するため、運用環境によってはユーザトラフィックを処理しているルータに余計な負担を与えてしまいます。
そのため、十分な予算がある場合には「測定専用のルータ」を用意し、これをIP SLA Senderとして利用するのが推奨されます。このような役割のルータは「シャドウルータ」と呼ばれます。一方、障害検知やフェイルオーバー制御に利用されるObject Tracking機能と組み合わせる場合は、実際にWANを接続している本番ルータをSenderとするのが一般的です。
IP SLAの設定例：UDPジッタ測定
IP SLAを使ったVoIP品質監視の典型的な例がUDPジッタ測定です。以下はその設定例です。
Cisco(config)# ip sla 1
Cisco(config-ip-sla)# udp-jitter 172.16.0.1 16384 codec g711ulaw
Cisco(config-ip-sla-jitter)# tos 160
Cisco(config)# ip sla schedule 1 life forever start-time nowこの例では、宛先IPを 172.16.0.1、宛先ポートを 16384、コーデックを G.711u-law と指定しています。これにより、VoIP通話に近い形式のパケットを自動生成して送出します。さらにToS値を160と指定しており、これはDSCP値40（IP Precedence 5）に対応します。音声パケットはQoSで優先されることが多いため、ToSを明示することで実際の通話品質に近い測定が可能になります。
コーデックごとの生成パケット
UDPジッタ測定では、コーデックに応じて送出するパケットサイズや本数が変わります。代表的なコーデックの例は以下の通りです。
| コーデック | codec-interval | codec-numpackets | Payloadサイズ |
|---|---|---|---|
| G.711a-law | 20ms | 1000パケット | 172バイト（160+12） |
| G.711u-law | 20ms | 1000パケット | 172バイト（160+12） |
| G.729a | 20ms | 1000パケット | 32バイト（20+12） |
ここで「+12」はRTPヘッダにあたります。これにより、実際の音声通話で発生するデータフローに近い状況をシミュレートできます。
ToS値の対応表
IP SLAで設定するToS値は、IP Precedence値やDSCP値に対応しています。代表的な変換は以下の通りです。
| IP SLA ToS値 (10進) | IP Precedence | DSCP値 |
|---|---|---|
| 224 | 7 | 56 |
| 192 | 6 | 48 |
| 160 | 5 | 40 |
| 128 | 4 | 32 |
| 96 | 3 | 24 |
| 64 | 2 | 16 |
| 32 | 1 | 8 |
| 0 | 0 | 0 |
SNMPトラップとの連携例
IP SLAの測定結果をSNMPトラップとして通知する設定も可能です。以下はMOS値がしきい値を下回ったときにトラップを送信する例です。
Cisco(config)# snmp-server host 172.1.1.10 public
Cisco(config)# snmp-server enable traps rtr
Cisco(config)# ip sla reaction-configuration 1 react mos threshold-value 500 300 threshold-type immediate action-type trapOnlyここではMOS値が3.00（コマンド上では300）を下回ると、即時にトラップが送信されます。MOSは1〜500で指定し、MOS=5が500に相当します。これにより、音声品質が低下した瞬間に監視サーバへ通知できます。
Responder側の設定
UDPジッタ測定のように、受信側から測定結果を返す必要がある場合は、Responderの設定が必須です。設定は非常にシンプルで、次の1行を入力すれば有効になります。
Cisco(config)# ip sla responderResponderを有効にしたCisco IOS機器は、Senderから送られる測定用パケットに応答して結果を返します。これにより一方向遅延やMOS値の算出が可能となります。
測定結果の確認
実際の測定状況や統計値は、次のコマンドで確認します。
Router# show ip sla statisticsここで遅延、ジッタ、パケットロス、MOS値などが表示され、VoIP品質を数値的に把握できます。ネットワークの健全性を定量的に評価する上で必ず活用するコマンドです。