ルーターの保護：QoS

QoSは大きなトピックです。 設定の微妙さやトラフィック処理ルールの適用に対するさまざまなアプローチについて説明する前に、QoSを思い出してください。



Quality of Service（QoS）は、さまざまなクラスのトラフィックにさまざまなサービス優先順位を提供するためのテクノロジーです。



まず、優先順位付けは、サービスキューが発生したときにのみ意味があることを理解するのは簡単です。 それはそこにあります、あなたはあなたの権利を使用して、最初に「滑る」ことができます。

キューは狭い場所に形成されます（通常、このような場所は「ボトルネック」、ボトルネックと呼ばれます）。 典型的な「ネック」は、少なくとも100 Mbit / sの速度でネットワークに接続されたコンピューターがすべてプロバイダーへのチャネルを使用するインターネットオフィスへのアクセスであり、100 Mbit / sを超えることはめったになく、多くの場合マイナス1-2-10 Mbit / sになります。 まったく。



第二に、QoSは万能薬ではありません。「ネック」が狭すぎると、インターフェイスの物理バッファがいっぱいになることが多く、このインターフェイスを介して終了するすべてのパッケージが配置されます。 そして、新しく到着したパッケージは、使いすぎても破棄されます。 そのため、インターフェイス上のキューが平均してその最大サイズの20％を超える場合（Ciscoルーターでは、最大キューサイズは通常128-256パケットです）、ネットワークの設計を慎重に検討し、追加のルートを配置するか、プロバイダーに帯域を拡張する必要があります。



技術の構成要素を取り扱ってみましょう



（さらにカットの下、たくさん）



マーキング。 さまざまなネットワークプロトコル（イーサネット、IP、ATM、MPLSなど）のヘッダーフィールドには、トラフィックのマーキング専用の特別なフィールドがあります。 キュー内の後続のより単純な処理のためにトラフィックをマークする必要があります。



イーサネット サービスクラス（CoS）フィールドは3ビットです。 トラフィックを異なるマーキングの8つのフローに分割できます



IP 2つの標準があります：古いものと新しいものです。 古いものには、ToSフィールド（8ビット）があり、そこから3ビットがIP Precedenceと呼ばれていました。 このフィールドはCoSイーサネットヘッダーフィールドにコピーされました。

後に新しい標準が定義されました。 ToSフィールドはDiffServに名前が変更され、Differencial Service Code Point（DSCP）フィールドに追加の6ビットが割り当てられました。このフィールドでは、このタイプのトラフィックに必要なパラメーターを送信できます。



データのラベル付けは、そのデータのソースに最も近いものにします。 このため、ほとんどのIP電話は、音声パケット自体のIPヘッダーにDSCP = EFまたはCS5フィールドを追加します。 多くのアプリケーションは、パッケージが最初に処理されることを期待して、独自にトラフィックをマークします。 たとえば、ピアツーピアネットワークはこれを「罪」にします。



キュー



優先順位付けテクノロジーを使用しなくても、これはキューがないことを意味しません。 ボトルネックでは、どのような場合でもキューが発生し、標準のFIFO（先入れ先出し）メカニズムが提供されます。 このようなキューは、明らかに、パケットをすぐに破棄せずにバッファに送信する前にパケットを保存することを許可しますが、音声トラフィックなどの設定を提供しません。



選択したクラスに絶対優先度を指定する場合（つまり、このクラスからのパケットが常に最初に処理される）、このテクノロジーは優先度キューイングと呼ばれます。 インターフェイスの物理発信バッファにあるすべてのパケットは2つの論理キューに分割され、特権キューからのパケットは空になるまで送信されます。 その場合にのみ、2行目のパケットが送信され始めます。 この技術は単純で、かなり粗雑です。 非優先トラフィック処理は常に停止します。 Ciscoルータでは、作成できます

優先順位の異なる4行。 これらは厳密な階層に従います。優先度の低いキューからのパケットは、優先度の高いキューがすべて空になるまで処理されません。



フェアキューイング 。 トラフィックの各クラスが同じ権利を提供できるようにする技術。 通常は使用されません サービスの質の改善という点ではほとんど成果がありません。



均等化キューイング（WFQ ）。 さまざまなクラスのトラフィックにさまざまな権利を付与する技術（さまざまなキューの「重み」は異なると言えます）が、同時にすべてのキューにサービスを提供します。 「指で」は次のようになります。すべてのパケットは、inを使用して論理キューに分割されます。

基準として、IP Precedenceフィールド。 同じフィールドが優先度を設定します（より良い）。 さらに、ルーターは、どのキューからどのパケットを送信するのが「速い」かを計算して送信します。







彼はこれを式で考えます：



dT =（t（i）-t（0））/（1 + IPP）



IPP-IP Precedenceフィールド値

t（i）-インターフェイスによるパケットの実際の送信に必要な時間。 L /速度として計算できます。ここで、Lはパケット長、Speedはインターフェース転送速度です。



このキューは、ポイントツーポイントインターフェイス（HDLCまたはPPPカプセル化）を除くすべてのCiscoルータインターフェイスでデフォルトで有効になっています。



WFQにはいくつかの欠点があります。そのようなキューイングは、以前にタグ付けされたパケットを使用し、トラフィッククラスと割り当てられた帯域を個別に決定することはできません。 さらに、原則として、誰もIP Precedenceフィールドにマークを付けていないため、パケットはマークされません。 すべてが1つのキューに分類されます。



WFQの開発は、 クラスベースの均等化キューイング（CBWFQ ）でした。 このキューでは、管理者がさまざまな基準に従ってトラフィッククラスを自分で設定します。たとえば、ACLをテンプレートとして使用したり、プロトコルヘッダーを分析したりします（NBARを参照）。 次に、これらのクラスについて

「重み」が決定され、キューのパケットは重みに比例して処理されます（より多くの重み-このキューからのパケットは単位時間あたりより多くなります）



ただし、このようなキューは、最も重要なパケット（通常は音声または他の対話型アプリケーションのパケット）の厳密な送信を提供しません。 したがって、優先度とクラスベースの均等化キューイングのハイブリッド-PQ-CBWFQは 、 低遅延キューイング（LLQ）としても知られています 。 このテクノロジーでは、最大4つの優先度キューを設定し、CBWFQメカニズムに従って残りのクラスを処理できます。



LLQは、最も便利で柔軟性があり、頻繁に使用されるメカニズムです。 ただし、インターフェイスでのクラス設定、ポリシー設定、およびポリシー施行が必要です。



設定については後で詳しく説明します。



したがって、サービス品質を提供するプロセスは2つの段階に分けることができます。

マーキング 。 ソースに近い。

パケット処理 。 それらをインターフェース上の物理キューに入れ、それらを論理キューに分割し、これらの論理キューにさまざまな論理リソースを提供します。



QoSテクノロジーはリソースを大量に消費し、プロセッサーに非常に大きな負荷をかけます。 そして、ロードするほど、ヘッダーを深く調べてパッケージを分類する必要があります。 比較のために：ルーターがほとんどアプリケーションレベルにストリームをスピンするのではなく、IPパケットヘッダーを調べてそこの3 IPPビットを分析する方がはるかに簡単で、どの種類のプロトコルが入っているかを判断します（NBARテクノロジー）



トラフィックの以降の処理を簡素化し、QoSに関連するすべてのヘッダーを信じるいわゆる「信頼境界」を作成するために、次のことができます。

1.アクセスレベル（クライアントマシンに近い）のスイッチとルーターでパケットをキャッチし、クラスに分散する

2.ポリシーで、アクションとして、ヘッダーを独自の方法で再描画するか、より高いレベルのQoSヘッダーの値をより低いヘッダーに転送します。



たとえば、ルーターでは、ゲストWiFiドメインからのすべてのパケットをキャッチし（非標準のQoSヘッダーを使用できるコンピューターやソフトウェアが制御されていない可能性があると想定）、IPヘッダーをデフォルトのものに変更し、レベル3ヘッダー（DSCP）をチャネルヘッダーにマッピングしますレベル（CoS）、

さらに、スイッチはリンク層ラベルのみを使用してトラフィックを効果的に優先順位付けできます。



LLQセットアップ



キューを設定するには、クラスを構成し、これらのクラスに対して帯域幅パラメーターを決定し、作成された構造全体をインターフェイスに適用する必要があります。



クラスの作成：



クラスマップNAME

マッチ？



アクセスグループアクセスグループ

任意のパケット

クラスマップクラスマップ

cos IEEE 802.1Q / ISLサービスクラス/ユーザープライオリティ値

宛先アドレス宛先アドレス

廃棄クラスの廃棄動作識別子

IP（v4）およびIPv6パケットのdscp Match DSCP

フローフローベースのQoSパラメーター

fr-deフレームリレーDEビットの一致

fr-dlci fr-dlciでの一致

input-interface照合する入力インターフェイスを選択します

ip IP固有の値

MPLSマルチプロトコルラベルスイッチング固有の値

この試合結果を否定しない

パケットレイヤー3パケット長

IP（v4）およびIPv6パケットでの優先一致優先順位

プロトコル protocol

qos-group Qos-group

送信元アドレス送信元アドレス

一致するVLAN VLAN







クラス内のパケットは、さまざまな属性で並べ替えることができます。たとえば、ACLをテンプレートとして指定したり、DSCPフィールドで指定したり、特定のプロトコルを強調表示したりできます（NBARテクノロジーが有効）



ポリシーの作成：



ポリシーマップポリシー

クラスNAME1

？



帯域幅

圧縮を有効にする

すべてのパケットをドロップします

log IPv4およびARPパケットをログに記録します

netflow-sampler NetFlowアクション

警察警察

このクラスの厳格なスケジューリング優先度

テールドロップのキュー制限キュー最大しきい値

random-detectドロップポリシーとしてRandom Early Detectionを有効にする

サービスポリシーの設定フロー

QoS値を設定します

シェーピングトラフィックシェーピング





政治のクラスごとに、ストリップの優先部分を選択できます。



ポリシーマップポリシー

クラスNAME1

優先？



[8-2000000]キロビット /秒

総帯域幅のパーセント





そして、このクラスのパッケージは、少なくともこの部分を常に信頼できます。



または、このクラスがCBWFQ内で持つ「重み」を説明します



ポリシーマップポリシー

クラスNAME1

帯域幅？



[8-2000000]キロビット /秒

総帯域幅のパーセント

残りの帯域幅の残りの ％





どちらの場合も、使用可能な帯域全体の絶対値と割合の両方を指定できます



合理的な疑問が生じます。ルーターはどのようにして帯域全体を知るのですか？ 答えは平凡です：インターフェイスの帯域幅パラメータから。 明示的に構成されていない場合でも、何らかの値が必要です。 sh intコマンドで確認できます。



また、デフォルトではレーン全体を管理するのではなく、75％のみを管理することに注意する必要があります。 他のクラスに明示的に分類されないパッケージは、class-defaultに分類されます。 この設定は、デフォルトクラスに対して明示的に設定できます。



ポリシーマップポリシー

クラスclass-default

帯域幅パーセント10

（UPD、OlegDに感謝）

インターフェイス上のコマンドにより、使用可能な最大帯域をデフォルトの75％から変更できます。



最大予約帯域幅[パーセント]



ルーターは、管理者が誤って現在よりも多くのレーンを割り当てないことを熱心に監視し、そのような試みを誓います。



政治は、書かれている以上のことをクラスに与えないようです。 ただし、この状況は、すべての行がいっぱいの場合にのみ発生します。 いずれかが空の場合、それに割り当てられた塗りつぶされた行は、その「重量」に比例して分割されます。



この構造全体は次のように機能します。



パケットが優先度のあるクラスから来る場合、ルーターはこれらのパケットの転送に焦点を合わせます。 また、 そのような優先度キューは複数存在する場合があり、それらの間で帯域は指定された割合に比例して分割されます。



すべての優先パケットが終了するとすぐに、CBWFQキューが開始されます。 カウントダウンごとに、このクラスの設定で指定されたパケットの割合が各キューから「スクープ」されます。 キューの一部が空の場合、それらの帯域はロードされたキュー間のクラスの「重み」に比例して分割されます。



インターフェイス上のアプリケーション：



int s0 / 0

サービスポリシー[入力|出力]ポリシー





しかし、許容速度を超えるクラスからパッケージを厳密にカットする必要がある場合はどうしますか？ 結局、帯域幅を指定すると、キューがロードされるときにクラス間で帯域が分配されるだけです。



この問題を解決するために、トラフィックのポリシークラスにテクノロジーがあります



ポリス[速度] [バースト]適合アクション[アクション]超過アクション[アクション]



これにより、希望の平均速度（速度）、最大「サージ」、すなわち 単位時間あたりに送信されるデータの量。 「排出」が大きいほど、実際の伝送速度が望ましい平均から大きく逸脱する可能性があります。 また示されています：通常のトラフィックのアクションが超えない

平均速度を超えるトラフィックに対して指定された速度とアクション。 アクションは次のようになります



警察100000 8000適合アクション？



ドロップパケットをドロップ

レートが適合範囲内である場合の超過アクションアクション

適合+超過バースト

set-clp-transmit atm clpを設定して送信します

set-discard-class-transmit set discard-classおよび送信

set-dscp-transmit dscpを設定して送信する

set-frde-transmit FR DEを設定して送信する

set-mpls-exp-imposition-transmitタグ設定でexpを設定して送信します

set-mpls-exp-topmost-transmit最上位ラベルにexpを設定して送信します

set-prec-transmit書き換えパケットの優先順位と送信

set-qos-transmit qos-groupを設定して送信する

送信パケット









多くの場合、別の問題もあります。 遅いチャネルを持つ近隣へのフローを制限するとします。







どのパケットがネイバーに到達し、「低速」側のチャネルの輻輳により破棄されるパケットを正確に予測するには、「高速」側で事前にキューを処理し、冗長パケットを破棄するポリシーを作成する必要があります。



そして、ここで非常に重要なことが1つあります。この問題を解決するには、「遅い」チャネルをエミュレートする必要があります。 このエミュレーションでは、パケットを順番に分散させるだけでは不十分であり、「低速」インターフェイスの物理バッファをエミュレートする必要もあります。 各インターフェイスにはパケットレートがあります。 つまり インターフェイスユニットごとに、各インターフェイスはN個を超えるパケットを送信できません。 通常、物理インターフェイスバッファは、複数のユニットのインターフェイスに対してインターフェイスの「自律的な」動作を保証するように計算されます。 したがって、GigabitEthernetなどの物理バッファーは、シリアルインターフェイスよりも数十倍大きくなります。



たくさん覚えることの何が問題になっていますか？ 高速送信側のバッファが受信バッファよりも大幅に大きい場合に何が起こるかを詳しく見てみましょう。



簡単にするために1ターンあります。 「高速」側では、低ビットレートをエミュレートします。 これは、ポリシーパッケージに該当するものがキューに蓄積され始めることを意味します。 なぜなら 物理バッファが大きい場合、論理キューは印象的です。 一部のアプリケーション（TCPを介して動作する）は、一部のパケットが受信されていないという通知を遅れて受信し、長いウィンドウサイズを長時間保持し、受信側をロードします。 これは、伝送速度が受信速度以下の理想的な場合に起こります。 ただし、ホストインターフェースは他のパッケージとともにロードすることもできます。

また、受信側の小さなキューでは、センターから送信されたすべてのパケットを収容できません。 追加の送信を伴う損失が始まりますが、送信バッファーには、以前に蓄積された「アイドル」送信されるパケットの「尾」がまだ残っています。 受信側では、以前のパッケージを待たなかったため、後のパッケージは単に無視されます。



したがって、低速の近隣への伝送速度を低下させる問題を正しく解決するために、物理バッファーも制限する必要があります。



これはチームによって行われます



形状平均[速度]



さて、今最も興味深いのは、物理バッファーをエミュレートすることに加えて、その中に論理キューを作成する必要がある場合はどうでしょうか？ たとえば、音声に優先順位を付けますか？



このために、いわゆるネストされたポリシーが作成されます。これは、メインポリシーの内部に適用され、親から取得したものを論理キューに分割します。



上記の写真に基づいて、いたずらな例を作る時が来ました。



COとリモートの間で、インターネットを介して持続可能な音声チャネルを作成する計画を立てましょう。 簡単にするために、リモートネットワーク（172.16.1.0/24）にCO（10.0.0.0/8）との接続のみを設定します。 リモートのインターフェース速度は1 Mb / sであり、この速度の25％が音声トラフィックに割り当てられます。



次に、最初に両側で優先トラフィッククラスを選択し、このクラスのポリシーを作成する必要があります。 COでは、オフィス間のトラフィックを記述するクラスをさらに作成します



COで：



クラスマップRTP

一致プロトコルrtp



ポリシーマップRTP

クラスRTP

優先度25



ip access-list extended CO_REMOTE

permit ip 10.0.0.0 0.255.255.255 172.16.1.0 0.0.0.255



クラスマップCO_REMOTE

一致するアクセスリストCO_REMOTE





リモートでは、別の方法で行います。たとえ鉄が枯渇したためにNBARを使用できないとしても、RTPのポートを明示的に記述する必要があるだけです。



ip access-list拡張RTP

許可udp 172.16.1.0 0.0.0.255範囲16384 32768 10.0.0.0 0.255.255.255範囲16384 32768



クラスマップRTP

一致するアクセスリストRTP



ポリシーマップQoS

クラスRTP

優先度25







次に、COで、低速インターフェイスをシミュレートし、ネストされたポリシーを適用して音声パケットに優先順位を付ける必要があります



ポリシーマップQoS

クラスCO_REMOTE

形状平均1,000,000

サービスポリシーRTP





インターフェースにポリシーを適用します



int g0 / 0

サービスポリシー出力QoS





リモートでは、インターフェース速度に応じて帯域幅パラメーター（kbit / s）を設定します。 25％が考慮されるのはこのパラメーターからであることを思い出させてください。 そして、ポリシーを適用します。



int s0 / 0

帯域幅1000

サービスポリシー出力QoS





スイッチの機能をカバーしなければ、話は完全ではありません。 純粋なL2スイッチは、パケットを深く調べて、同じ基準に従ってクラスに分類できないことは明らかです。



ルーティング可能なインターフェイス上のよりスマートなL2 / 3スイッチ（つまり、インターフェイスVLAN上、またはno switchportコマンドを使用してポートが第2レベルから削除された場合）で、ルーターで機能する同じ設計が適用され、ポートまたはスイッチ全体が機能する場合L2モード（2950/60モデルに当てはまる）では、トラフィッククラスのポリシング表示のみを使用でき、優先度または帯域幅は使用できません。



純粋に保護の観点から見ると、QoSの基本を理解することで、ワームによって引き起こされるボトルネックをすばやく防ぐことができます。 ご存じのように、ワーム自体は伝播段階で非常に攻撃的であり、大量の偽のトラフィックを作成します。 実際、サービス拒否（DoS）攻撃。



さらに、ワームは多くの場合、操作に必要なポート（TCP / 135,445.80など）に広がります。ルーターのこれらのポートを単純に閉じるのは無謀です。したがって、これを行うのはより人道的です。



1.ネットワークトラフィックに関する統計を収集します。 NetFlow、NBAR、またはSNMP。



2.通常のトラフィックのプロファイルを特定します。つまり、 統計によると、平均して、HTTPプロトコルは70％以下、ICMP-5％以下などを取ります。 このようなプロファイルは、手動で作成するか、NBARによって蓄積された統計を適用して作成できます。さらに、autoqos

コマンドを使用して、クラス、ポリシーを自動的に作成し、インターフェイスに適用することもできます:) 3.次に、非典型的なネットワークトラフィックの帯域を制限できます。非標準ポートによる感染を突然キャッチした場合、ゲートウェイに大きな問題は発生しません。ロードされたインターフェースでは、感染は割り当てられた部分を超えることはありません。4.コンストラクト（class-map-policy-map-service-policy）を作成することで、トラフィックのクラスを手動で作成し、このクラスの帯域幅を大幅に制限することにより、トラフィックの非定型バーストの出現にすばやく対応できます。セルゲイ・フェドロフ