MPLSのQoSの帯域制御とキューイング（policer / shaper / priority）

MPLSのQoSの帯域制御とキューイング（policer / shaper / priority）

MPLS網で流量を抑える方法は2つあります。policerは超えた分をその場で捨て、shaperはいったん貯めて送り出す時間を延ばします。捨てるか遅らせるかの違いは、実際にパケットを流すと損失と遅延の差になって出ます。さらに、クラスごとにキューを分ければ、優先するトラフィックだけ遅延を小さく保てます。この記事ではIOS XRでの書き方を解説し、XRv9000のラボで損失と遅延を測ります。

ラベルのTCと出口PEの3モードはMPLSのQoS（TCとuniform / pipe / short-pipe）で解説しています。

policerとshaper

policerはconform（範囲内）とexceed（超過）でカウンタが分かれ、超えた分は既定で捨てられます。shaperは超えた分をキューに入れるため、キューの深さを超えない限り捨てません。

クラスごとにキューを分ける

親でshapeして全体の上限を決め、子でクラスを分けると、限られた帯域の中での優先度を決められます。

コア側の出力ではパケットにラベルが付いているので、クラス分けはmatch dscpではなくmatch mpls experimental topmostで行います。IPヘッダーはラベルの内側にあるためで、実際にコア側の出力でmatch dscpのクラスを作ったときは一致が0件でした。

検証構成

CE1 - PE1 - P1 - PE2 - CE2の5台で、コアはOSPF + LDP、PE間はiBGP vpnv4です。PE1 / P1 / PE2はXRv9000、CE1 / CE2はXRdを使います。

負荷はCE1からCE2へのpingで、1パケット1400バイト、10ミリ秒間隔です。XRdを挟む区間では1500バイトを超えるパケットが通らないため、この大きさにしています。

検証の全体像

policerで捨てる（STEP 7）

PE1の顧客側の入力にpolice rate 100 kbpsを当て、1400バイトを500発流しました。334発が通り、166発が捨てられました。

Class class-default
  Classification statistics          (packets/bytes)     (rate - kbps)
    Matched             :                 500/709000               30
    Transmitted         : N/A 
    Total Dropped       :                 166/235388               10
    Policed(conform)    :                 334/473612               20
    Policed(exceed)     :                 166/235388               10

Matchedが500でconformが334、exceedが166です。pingの結果も334/500（66パーセント）で一致します。RTTは7/14/47ミリ秒で、通った分の遅延は増えていません。

shaperで遅らせる（STEP 8）

policerを外し、コア側の出力に2段構成のshape average 200 kbpsを当てました（親のclass-defaultで整形し、子はclass-defaultにbandwidth remaining percent 100を置いた形です）。同じ負荷で500発すべてが通り、RTTの平均は56ミリ秒（設定前は13ミリ秒程度）です。

Class class-default
  Classification statistics          (packets/bytes)     (rate - kbps)
    Matched             :                 500/713000               114
    Transmitted         :                 500/713000               114
    Total Dropped       :                   0/0                    0
  Policy PE1-CORE-SHAPE-CHILD Class class-default
    Classification statistics          (packets/bytes)     (rate - kbps)
      Matched             :                 500/713000               114
      Queue(conform)      :                 500/713000               114

Total Droppedは0で、Taildroppedも0でした。捨てずに送り切っています。policerが損失として現れるのに対し、shaperは遅延として現れます。

クラスごとにキューを分ける（STEP 9）

コア側の出力を、親shape average 300 kbpsと子policyの組に替えました。子はTC 5をpriority level 1とpolice rate 100 kbps、TC 4をbandwidth remaining percent 20、残りをclass-defaultにしています。CE1からDSCP 46（TC 5）、DSCP 34（TC 4）、DSCP 0の3種類を4秒ずらして各1000発流しました。

Class class-default
  Classification statistics          (packets/bytes)     (rate - kbps)
    Matched             :                3000/4278000              31
    Transmitted         :                2667/3803142              21
    Total Dropped       :                 333/474858               10
  Policy PE1-CORE-QUEUE-CHILD Class TC5
    Classification statistics          (packets/bytes)     (rate - kbps)
      Matched             :                1000/1426000              31
      Transmitted         :                 667/951142               21
      Policed(exceed)     :                 333/474858               10
  Policy PE1-CORE-QUEUE-CHILD Class TC4
    Classification statistics          (packets/bytes)     (rate - kbps)
      Matched             :                1000/1426000              0
      Transmitted         :                1000/1426000              0

優先キューに入れたクラスだけ、遅延が設定前と同じ水準に収まります。他の2クラスは親のshaperのキューで待たされ、平均70ミリ秒になりました。優先キューに付けたpolice rate 100 kbpsが超過分333発を捨てているため、EFは667/1000です。上限を付けないと、優先キューが帯域を占有して他のクラスが流れなくなります。

設計上の注意

• コア側の出力でmatch dscpのクラスを作っても一致しませんでした（ラベルが付いているため）。TCで分けるか、入力でqos-groupに写して出力で使います
• priorityのクラスには上限（police）を付けます。付けないと他のクラスが送れなくなります
• policerは損失、shaperは遅延として出ます。遅延に敏感なトラフィックをshaperの後ろに置くと、損失が無くても品質が落ちます

検証Configおよびshow結果

各STEPで5台から、次の種類をルータごとに分けて取得しています。検証Configはこの..._run.txtです（最終状態は最後のSTEPのもの）。カウンタはクリアしてからpingを流し、その後にshowを取っているので、各STEPの数値はそのSTEPだけの結果です。

STEP 7：入口PEの入力にpolicerを当てる

負荷はload、負荷後のカウンタはpmapです。

STEP 8：コア側の出力に2段構成のshaperを当てる

負荷はload、負荷後のカウンタはpmapです。

STEP 9：親shaperと子policyでクラスを分ける

負荷はEF / AF41 / ToS 0、負荷後のカウンタはpmapです。

STEP 10：QoSの設定をすべて外す（最終状態）

パケットキャプチャーはSTEPごとに4リンクで取得しています。

参考

関連記事

• MPLSとは
• MPLSラベルとラベルスタック
• MPLSのラベル操作（push / swap / pop）とPHP
• MPLSのTTL処理とMTU
• LDPとは
• LDPのラベル配布モードとラベルスペース
• LDP-IGPシンクロナイゼーションとLDPセッション保護
• LDPのラベル広告制御（フィルタリング）
• LDPのセッション認証（TCP MD5）
• MPLSのOAM（LSP Ping / LSP Traceroute）
• MPLS TE（RSVP-TE）とは
• MPLS TEのCSPFと経路の制約（帯域 / affinity / TEメトリック）
• MPLS TEトンネルへのトラフィック誘導
• MPLS TEのFRR（リンク保護とノード保護）
• MPLS TEのFRR（auto-tunnel backupとSRLG）
• MPLSのQoS（TCとuniform / pipe / short-pipe）
• MPLSのQoSの帯域制御とキューイング（policer / shaper / priority）