PPPoE接続用dialerポートの受信パケットロスの原因について

Question

FLETS回線を利用するCiscoルータのPPPoE接続用dialerポートでのみ受信パケットにdropsが発生しており原因を調べています。
しかし、これ以上はパケットキャプチャしない限り調査が難しいのではないかと考えていますが、その他の原因調査の観点や、もし一般的な事例や原因をご存知でしたらご教示頂けないでしょうか。

　※PPPoE接続をするルータの設定等をCisco社のページやネットワークエンジニアとしてのサイトなどを参照しながら確認したところ、特段誤った設定が入っていることは確認できませんでした。

簡易的なイメージ図は下記であり、dialerポートでのdropsの出力状況は吹き出しに記載した状況となります。

![]

よろしくお願い申し上げます。

Answer 1

一つ気になったことがありましたので記載します。

RouterBも確認していたところ、RouterBでもDiscards INのパケットロスがdialer1で発生していました。

また、RouterB側でshow intを確認するとdialerに「Queueing strategy：weighted fair」の表示があり

と記載があるようにshow interfaceの結果ではWFQが有効になっていることが分かります。
他の方の回答もあるため、上記出力は無視されていますが実際にWFQが有効になっているということは
dialerインタフェースの帯域が2Mbps以下なのではないかと推察します。

そこで、show interfaceの内容からBW(帯域 Bandwidth)がいくつになっているか確認して
いただけますでしょうか。BWが細くなっていればinterfaceコマンドモードからbandwidthコマンドで
帯域を契約帯域にて設定してください。

Comments

[togari]

追加の確認観点のコメントいただきありがとうございます。
BWの値をよく見ていなかったので確認してみるようにいたします。

Answer 2

考えられる想定原因です。
①回線の速度差
上位拠点と末端拠点の回線の速度差などはないでしょうか。
⇒上位拠点が1Gbps回線、末端拠点が100Mbpsの場合などの場合、RouterAでパケットドロップ発生もありえるのかな…と。（実際のパケットドロップは回線速度さが発生しているフレッツ網内で起きるような気もしますが…。）

　②RouterAのスペック
①と似ていますが、両拠点とも1Gbps回線など高速の場合、ルータのスペックによっては処理しきれずにパケットドロップもありえるかと。
⇒その場合、通信中にRouterAでshow processes cpuでルータの負荷状態を見れると思います。

　③MTUサイズが不適切
拠点間の接続にはフレッツ網も用いているようですが、VPNで暗号化していますか。
その場合、パケットのヘッダに情報が付加されるため、MTU（およびMSS）のサイズ調整が必要です。
サイズ調整しないと、パケットの分割送信が大量に発生し、パケットドロップの要因になるかもしれません。

Comments

[togari]

想定原因をご教示いただきありがとうございます。
①回線の速度差
　回線速度の差異はあります。末端拠点と上位拠点間はFLETS VPNワイドですが、上位拠点間を繋ぐVPNはArcstarUniversalOneを使用しています。

②RouterAのスペック
　ありがとうございます。Discardsのエラーだけ確認していたので、RouterAとRouterB双方にCPUの監視も設定してDiscards発生時のリソースと相関があるか確認してみたいと思います。なお、Discards発生を考慮せず、RouterAのCPUをコマンドで確認したところ2%でした。

③MTUサイズが不適切
　FLETS VPNワイドのため暗号化しています。URL掲示で恐れ入りますが、下記の文書の仕様に合った設定値が入っていることを確認しています。
　＜URL：https://flets.com/pdf/ip-int-3.pdf＞
　各拠点のWindows端末のMTU値はデフォルト1500の状態ですが、Windows Vista以降ではMTUの自動調節機能が搭載されているとの情報を散見しており、ルーター側で適切に処理されるため端末側の設定は不要かと認識しています。

＜追加の確認状況＞
RouterBも確認していたところ、RouterBでもDiscards INのパケットロスがdialer1で発生していました。
また、RouterB側でshow intを確認するとdialerに「Queueing strategy：weighted fair」の表示があり、一方でコンフィグには明示的にWFQを制御する設定は無いようでした。「ネットワークエンジニアとして」のページ（https://www.infraexpert.com/study/qos6.htm）によれば、「WFQのコンフィグ設定は、2Mbps以下の速度のインターフェースでデフォルトで有効化されています。」とあり、これを逆に捉えて「インターフェース速度が2Mbps以下になった場合、自動的に有効化される設定でもある」ならば①が実質的な原因になるのではないかと想像しています。
加えて、RouterBは合計10拠点近い末端拠点とのFLETS網間（dialerは共通でdialer1のみ、dialerと紐づくTunnel設定が末端拠点数分有）を接続しており、こちらがボトルネックになっている可能性はありえるのではないかと考えています。

少なくとも引き続き、②の確認を進めてみたいと思います。

[taichi_0807]

やはりパケットキャプチャが有効そうですね。
しかし、WAN側I/Fで発生している事象なので、WAN側、LAN側の2か所でキャプチャして、その差分を見る感じですかね。

（既設（？）L2）━（RouterA）━【追加SW】━（ONU）
　┗【LAN側キャプチャ用PC】　　　　┗【WAN側キャプチャ用PC】

①回線の速度差
　上位拠点はArcstarUniversalOne（UNO）を使っていて、回線の速度差があるということですね。

②RouterAのスペック
　事象発生時のトラフィック量によってCPUの負荷は変動するので、確認してみるべきかと思います。

③MTUサイズが不適切
　両拠点のルータに設定するMTUの値は、FLETS VPNワイド、UNOどちらの仕様も確認し、より小さいほうの値に合わせてあげる必要性がありそうですね。
　（パケットドロップと直接的な因果関係は薄いと思いますが。）
　また、Win端末側へのMTU設定が不要であることは、認識同様です。

＜追加の確認状況＞
RouterBのダイアラI/Fでもパケットドロップが発生しているのですね。
記載頂いたRouterBが多拠点と接続していることがパケットドロップの原因となっている推測について、
あり得るかもしれないですね。

なお、記載頂いた“2Mbps以下のI/Fに対して自動的にWFQが有効化される”というのは無視でいいと思います。
10Mbps未満のI/Fといえば、シリアルI/Fとかの話なので。
　⇒RouterBのONUとがLANケーブルで繋がっていれば少なくとも10Mbps（10BASE-T）以上です。
　⇒ONUと接続している物理I/Fのshow intでリンク速度が見れると思います。

[togari]

ご返信が遅くなり大変失礼いたしました。

0.パケットキャプチャについて
　対向の上位拠点側のルータ確認に注意が向いていましたが、アドバイスの通りLAN側のパケットを確認してみたいと思います。ただし、遠隔拠点のためPCでキャプチャしにいくことが現状困難なため、情報によるとルータ本体でEmbedded Packet Captureの設定でパケットキャプチャができるとの情報を確認しており、負荷の問題がありますが最悪こちらによる方法を考えています。

②RouterAのスペック
　現在こちら引き続き確認しております。

④WFQの設定
　2Mbps以下～の件、ご教示いただきありがとうございます。リンク速度はFULL duplex 100Mbpsでしたのでご指摘の通り関係ないことを確認しました。
　仕組みの理解も不十分で恐縮ですが、明示的な設定をせずにWFQが表示されている場合であっても、「congestive-discard-threshold」がデフォルト値：64で制限されるとしたら、多量のキューというべきかセッションが発生した場合、PPPパケットのヘッダー処理でパケットドロップが起こるりうるのか気になっています。