ジッタ/パケット損失によるチャネル状態監視
こんにちは、同僚。
私の考えを集めて、私は自分に生まれた解決策を適切に作成することにしました。
だから、 問題の声明 ：
ポイントAとBの間に2つのチャネルがあり、ほとんどの場合、異なるプロバイダーからのものです。 つまり、これらのチャネルのサービス品質のアカウンティングを保証する必要があります。
1.チャネルの損失が0.5％を超える場合、チャネルを使用しないでください。
2.ジッタが10ミリ秒を超える場合、チャネルを使用しないでください。
この問題は私の仕事で発生しました。なぜなら、2つの都市は2つのチャネルで接続されており、このチャネルを介して多数の音声が流れるからです。 誰も気にしない-あなたは猫の下で歓迎されています。
元の決定 。
最初は、2つの不格好なオプションさえありました。 最初は、tsiskaでpingovalkaを上げることで、チャンネルの存続可能性を確認し、その死を切り替えました。 このソリューションは、損失がなくジッターに問題が生じるまで解決しました。
2番目の解決策は、G729コーデックを模倣するudpパケットに基づいてモニターを作成することでした。 モニターは損失とジッターを示しました。通信の問題が発生した場合、管理者は猫に登り、ジッターと損失の現在の値を監視し、状況に応じてチャネルを無効にする決定を行いました。 もちろんうまくいきました。 しかし、これはある種の半自動システムでした。 したがって、私は自分自身をまとめ、この状況を最終的な解決策にしました。
現在のソリューション 。
したがって、2番目のケースのように、G729aコーデックを模倣するチャネル品質udpモニター（いわゆるSLAモニター）を作成します。
このモニターは、宛先のポート49333に毎分間隔で1000パケットを送信し、tos = 70 = 0x46 = EFをマークします。 宛先を有効にする必要があります
次に、安定したトラックを作成します（アプレットを使用して制御し、SLAモニターにしっかりと結び付けないように特別に作成します）。
ここでのタスクは、SLAモニターから結果を削除し、その値に応じて、トラック20をUP状態のままにするか、それを配置することです。 これは、たとえば、Cisco EEM（Embedded Event Manager）を使用して実行できます。これにより、ハードウェアの現在の状態を監視し、特定のアクションを実行できます。
これを行うには、2つのアプレットを作成します。 少なくとも1つのパラメーター（ジッターまたは損失数）が私たちに合わない場合、トラックをDown状態にします。 両方のパラメーターが正常な場合、2番目はそれを元に戻します。
構成
1.最初のアプレットを作成します。
RTTのSNMP OIDとSLAモニターからのジッターに基づいて2つのイベントを作成します。
ここで、SNMP OIDの最後の数字33はSLAインスタンス番号です。 10-ジッターのしきい値（ミリ秒単位）、994-送信された1000のうち返されるパケットの最小許容数（1000-packet_loss）。 poll-interval-猫が値の状態をポーリングする間隔。 ここに4秒。
アプレットはどのイベントでも動作することを示しています。 論理ORが使用されます。
さらなるアクション：
つまり トラックはDownに設定されています。
2番目のアプレットも同様です。
アプレットのみがイベント間の論理ANDによってトリガーされます。 そして、トラックが充電されます。
調査は4秒間隔で行われ、トラックの現在の状態は考慮されていないことがわかります。 ギャングウェイは4秒ごとに絶えず発射されます。 トラック自体の状態の監視を強化しようとしましたが、非常にバグが多く、常に機能するとは限りませんでした。 それで私は数パーセントを寄付し、そのように残しました。
さらに、チャネルの問題とその消失について通知するアプレットがさらにあります。
そして
変数$ _cli_resultには、最後のコマンドの出力結果、つまり この例では、ip sla stat 33を表示します。
言い換えると、私たちは自分自身に手紙を送っています。その本文は、実際にトラックの切り替えを引き起こしたSLAモニターの最後の起動の結果です。
それで、今実際にこれを考慮に入れる方法 。 次の2つの方法があります。
1.ルートマップの行（実際には機能しますが、トリッキーなスキームがあります）
2.フォームのルートがある場合の統計の追跡
チャネルで損失またはジッターが発生した場合、このルートは単にルーティングテーブルから削除され、トラフィックは代替パスを通過します。
不器用かもしれませんが、何も起こらなかったよりも一週間苦しみました。 彼らが言うように、豊かなもの。
PS私は読者がCiscoコンソールの基本に少し精通していることを意味します
PPS ip slaコマンドの構文は12.4Tと12.4によって異なりますが、意味は同じです。
PPS複数行の境界を超えない説明が必要な場合-書き込み、追加します。
よろしく
ポドクパエフイリヤ
_________
UPD ：CPUについて。 一般に、アプレットのない負荷の下で、アプレットを使用すると、ルータの負荷（ISR 3845）が平均で約42％になります（43-44）。
私の考えを集めて、私は自分に生まれた解決策を適切に作成することにしました。
だから、 問題の声明 ：
ポイントAとBの間に2つのチャネルがあり、ほとんどの場合、異なるプロバイダーからのものです。 つまり、これらのチャネルのサービス品質のアカウンティングを保証する必要があります。
1.チャネルの損失が0.5％を超える場合、チャネルを使用しないでください。
2.ジッタが10ミリ秒を超える場合、チャネルを使用しないでください。
この問題は私の仕事で発生しました。なぜなら、2つの都市は2つのチャネルで接続されており、このチャネルを介して多数の音声が流れるからです。 誰も気にしない-あなたは猫の下で歓迎されています。
元の決定 。
最初は、2つの不格好なオプションさえありました。 最初は、tsiskaでpingovalkaを上げることで、チャンネルの存続可能性を確認し、その死を切り替えました。 このソリューションは、損失がなくジッターに問題が生じるまで解決しました。
2番目の解決策は、G729コーデックを模倣するudpパケットに基づいてモニターを作成することでした。 モニターは損失とジッターを示しました。通信の問題が発生した場合、管理者は猫に登り、ジッターと損失の現在の値を監視し、状況に応じてチャネルを無効にする決定を行いました。 もちろんうまくいきました。 しかし、これはある種の半自動システムでした。 したがって、私は自分自身をまとめ、この状況を最終的な解決策にしました。
現在のソリューション 。
したがって、2番目のケースのように、G729aコーデックを模倣するチャネル品質udpモニター（いわゆるSLAモニター）を作成します。
ip sla 33
udp-jitter 172.16.1.66 49333 source-ip 172.16.1.65 codec g729a codec-size 20
tos 70
threshold 10
このモニターは、宛先のポート49333に毎分間隔で1000パケットを送信し、tos = 70 = 0x46 = EFをマークします。 宛先を有効にする必要があります
ip sla responder
次に、安定したトラックを作成します（アプレットを使用して制御し、SLAモニターにしっかりと結び付けないように特別に作成します）。
track 20 stub-object
default-state up
ここでのタスクは、SLAモニターから結果を削除し、その値に応じて、トラック20をUP状態のままにするか、それを配置することです。 これは、たとえば、Cisco EEM（Embedded Event Manager）を使用して実行できます。これにより、ハードウェアの現在の状態を監視し、特定のアクションを実行できます。
これを行うには、2つのアプレットを作成します。 少なくとも1つのパラメーター（ジッターまたは損失数）が私たちに合わない場合、トラックをDown状態にします。 両方のパラメーターが正常な場合、2番目はそれを元に戻します。
構成
1.最初のアプレットを作成します。
event manager applet LB trap
RTTのSNMP OIDとSLAモニターからのジッターに基づいて2つのイベントを作成します。
event tag jitter snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.46.33 get-type exact entry-op ge entry-val "10" entry-type value poll-interval 4
event tag loss snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.1.33 get-type exact entry-op le entry-val "994" entry-type value poll-interval 4
ここで、SNMP OIDの最後の数字33はSLAインスタンス番号です。 10-ジッターのしきい値（ミリ秒単位）、994-送信された1000のうち返されるパケットの最小許容数（1000-packet_loss）。 poll-interval-猫が値の状態をポーリングする間隔。 ここに4秒。
アプレットはどのイベントでも動作することを示しています。 論理ORが使用されます。
trigger
correlate event loss or event jitter
さらなるアクション：
action 20 track set 20 state down
つまり トラックはDownに設定されています。
2番目のアプレットも同様です。
event manager applet LB2 trap
event tag jitter snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.46.33 get-type exact entry-op lt entry-val "10" entry-type value poll-interval 4
event tag loss snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.1.33 get-type exact entry-op gt entry-val "994" entry-type value poll-interval 4
trigger
correlate event loss and event jitter
action 20 track set 20 state up
アプレットのみがイベント間の論理ANDによってトリガーされます。 そして、トラックが充電されます。
調査は4秒間隔で行われ、トラックの現在の状態は考慮されていないことがわかります。 ギャングウェイは4秒ごとに絶えず発射されます。 トラック自体の状態の監視を強化しようとしましたが、非常にバグが多く、常に機能するとは限りませんでした。 それで私は数パーセントを寄付し、そのように残しました。
さらに、チャネルの問題とその消失について通知するアプレットがさらにあります。
event manager applet LB_info
event syslog pattern "20 stub Up->Down"
action 10 syslog msg "applet works!"
action 11 cli command "enable"
action 12 cli command "show ip sla stat 33"
action 13 mail server "192.168.6.20" to "ilya@tut_domen.ru" from "alert@tut_domen.ru" subject "Frame loss or high jitter on NiS channel" body "$_cli_result"
そして
変数$ _cli_resultには、最後のコマンドの出力結果、つまり この例では、ip sla stat 33を表示します。
event manager applet LB2_info
event syslog pattern "20 stub Down->Up"
action 10 syslog msg "applet 2 works!"
action 11 cli command "enable"
action 12 cli command "show ip sla stat 33"
action 13 mail server "192.168.6.20" to "ilya@tut_domen.ru" from "alert@tut_domen.ru" subject "NiS channel is correct" body "$_cli_result"
言い換えると、私たちは自分自身に手紙を送っています。その本文は、実際にトラックの切り替えを引き起こしたSLAモニターの最後の起動の結果です。
それで、今実際にこれを考慮に入れる方法 。 次の2つの方法があります。
1.ルートマップの行（実際には機能しますが、トリッキーなスキームがあります）
set ip next-hop verify-availability 172.16.1.66 1 track 20
2.フォームのルートがある場合の統計の追跡
ip route 172.16.0.0 255.255.255.0 192.168.1.1 track 20
チャネルで損失またはジッターが発生した場合、このルートは単にルーティングテーブルから削除され、トラフィックは代替パスを通過します。
不器用かもしれませんが、何も起こらなかったよりも一週間苦しみました。 彼らが言うように、豊かなもの。
PS私は読者がCiscoコンソールの基本に少し精通していることを意味します
PPS ip slaコマンドの構文は12.4Tと12.4によって異なりますが、意味は同じです。
PPS複数行の境界を超えない説明が必要な場合-書き込み、追加します。
よろしく
ポドクパエフイリヤ
_________
UPD ：CPUについて。 一般に、アプレットのない負荷の下で、アプレットを使用すると、ルータの負荷（ISR 3845）が平均で約42％になります（43-44）。
All Articles