3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

昔々、モバイル閉域網を利用した足回りネットワークを設計・構築する機会がありました。

有線WAN回線(光回線)が新規敷設されるまでの間、山奥の新設営業所と事務所(開発拠点)間をつなぐため、暫定的に利用できるもの……という、いわゆる「現場の土管が開通するまでの繋ぎ」としてのコンセプトです。

image_closed_mobile_NW.JPG
(変えておりますが、おおよそこんなイメージ。)
 
 
この時に困ったのが、予期せぬ大容量トラフィックによる閉域モバイル回線の「パケ死(速度制限や超過料金)」です。確かsimあたり月間5GByteまでとかそんな契約だったかと。

現場からは「リモデが繋がらないと仕事にならない」と言われるものの、帯域を開放しすぎれば一晩でパケ死する。そこで、泣く泣く以下のような帯域制御(shape)なconfigを投入したのを覚えています。

↓当時、パケ死対策で組んだコンフィグ(加工・マスク済)

ip lan1 address ***.***.***.***/**
ip lan1 nat descriptor ***
・・・
description wan1 MOBILE
speed wan1 5m
queue wan1 type shaping
queue wan1 class filter list 1 2
queue wan1 class property 1 bandwidth=1m
queue wan1 class property 2 bandwidth=512k
ip wan1 address dhcp
ip wan1 secure filter out ****** ******
wan1 bind usb1
wan1 always-on on 60
wan1 auth myname ***@******** ******
wan1 auto connect on
wan1 disconnect time off
wan1 disconnect input time off
wan1 disconnect output time off
wan1 access-point name ********
wan1 access limit length off
wan1 access limit time off
・・・
queue class filter 1 1 ip * * tcp * 3389
queue class filter 1 2 ip * * * * *
・・・
mobile use usb1 on
mobile signal-strength on syslog=on interval=600

#まぁ、それでも画面がカクカクするだの何だの言われたんですよね・・。
嫌なら切ったろか?:scissors:という気持ちをぐっ!とこらえて。(大人の工事屋ですからね。)

ただ当時はモバイル網による構築だったこともあり、簡易的な確認にとどまっていました。

そこで今回は、有線LANポート(イーサネット)をWAN側に見立て、RTX1210を2台並べたシンプルな試験系を改めて構築。「出力方向にて帯域制御がどのように行われるのか」、そして上り・下りでの挙動の違いをそれっぽく確かめてみました。

何年ぶりのリベンジだ?という感じですが、当時のモヤモヤを技術検証で白黒つけにいってみようと思います。


ヤマハルーターにおける「上り/下り」帯域制御の基本概念

有線LANポートをWAN側として使用する場合、ルーターが高度なQoS(シェーピング等)をハンドリングできるのは、原則として 「ルーターから出ていくトラフィック(上り)」 のみになります。

1. 上り(送信/Outbound)の制御:シェーピング

ルーター内部からインターフェースを通って外へ送り出されるパケットに対して、キュー(待ち行列)を作って送出速度をコントロールします。これにより、パケットをきれいに指定速度に「シェーピング(平滑化)」して送り出すことができます。

2. 下り(受信/Inbound)の制御

外からルーターへ入ってくるパケットは、すでに回線(土管)を通って届いてしまっているため、ルーター側で綺麗に交通整理をして速度を絞る(シェーピングする)ことができません。
ルーター側で下りを制限しようとすると、上限を超えて入ってきたパケットをその場で「ドロップ(破棄)」する制御(ポリシング)にならざるを得ず、TCPの再送制御が走るため通信がギクシャクしてしまいます。


今回構築した有線LAN(実機2台)の試験環境

検証用に組んだネットワークトポロジーは以下の通りです。

image_test_topology_001.JPG

  • RTX1210-1 lan2(wan):192.168.200.10 / lan1:10.10.10.254
  • RTX1210-2 lan2(wan):192.168.200.20 / lan1:10.20.20.254
  • 2台のルーター間を lan2192.168.200.0/24)の有線リンクで対向接続。

まずはQoS設定を何も入れていない初期状態(デフォルト)で、物理的な限界速度を測定しておきます。

1. 初期状態での下り(Download)速度

RTX1210-2側からRTX1210-1側へデータを引っ張った際の通信フローと測定結果です。

image_test_topology_003(Download).JPG
001_base_default_DL_145Mbps.JPG
初期状態では、下り方向でおよそ 145Mbps のスループットが出ていることが確認できます。

2. 初期状態での上り(Upload)速度

続いて、RTX1210-1側からRTX1210-2側へデータを流した際の通信フローと測定結果です。

image_test_topology_002(Upload).JPG
002_base_default_UP_141Mbps.JPG
こちらも同様に、上り方向でおよそ 141Mbps の速度を記録しました。この限界値をベースに、帯域制御を仕掛けていきます。


帯域制御の投入と実証検証

ここで、QoSの本質を確かめるために RTX1210-1lan2 インターフェースに対して、以下のシンプルなシェーピング設定(上限:10Mbps)を投入します。

# RTX1210-1 lan2 QoS設定
queue lan2 type shaping
speed lan2 10M

この状態で、上り方向(送信)と下り方向の双方から大容量トラフィックを発生させ、挙動がどう変化するかを確かめました。

【検証1】上り方向(RTX1210-1 から出ていく通信)の挙動

RTX1210-1 側から対向の RTX1210-2 側に向けて大量のデータ転送(Upload)を行いました。

003_shape_10M.JPG
[Uploadシェーピング測定結果(9.2Mbps)]

  • 結果: トラフィックは完璧に 10Mbps(測定値:平均9.2Mbps)で頭打ち になり、綺麗にシェーピング(上限制御)されていることを確認しました。ルーター自身が出力キューの送出速度をハンドリングしているため、パケットロスを抑えた滑らかな制限がかかります。

image_test_topology_004(Upload_shape_test_10Mbps).JPG
[こんなimageですね。shaperかけている個所。]
 
 
 
 

【検証2】下り方向(RTX1210-1 が受信する通信)の挙動

今度は前述のアップロードトラフィックに加えて、対向の RTX1210-2 側から、RTX1210-1 に向けて大容量データも全力でダウンロード(Download)させ、lan2 に負荷をかけました。

  • 疑問: RTX1210-1 で受信するトラフィックも、設定した10Mbpsを上限として制限されるのでしょうか?

004_shape_UP_10M(DL_135M).JPG
[Download測定結果(135Mbpsで突き抜け)]

  • 結果: 制限されず、10Mbpsを遥かに超える 135Mbps のトラフィックがそのままルーター内部へ流入しました。(画面下部の送信グラフは10Mbpsに張り付いていますが、受信グラフは135Mbpsまで突き抜けています)

ヤマハルーターの queuespeed コマンドは、物理仕様として「送信(出力)方向」にしか作用しません。入ってくるパケットはすでに物理線を流れてルーターに到達してしまっているため、自機の送信キューを通過せず、そのままの速度で突き抜けて入ってきます。

この実験からも、 「自機で100%コントロールできるのは、あくまで出ていく波(送信)だけである」 という原則が綺麗に目視で証明されました。思ったよりも教科書通りというか、ぐうの音も出ないほど綺麗な結果になって検証中ニヤリとしてしまいました。今夜もウメッシュが旨い。


まとめ:WAN側の帯域制御を設計する際のポイント

過去にモバイル閉域網でスッタモンダあった帯域制御ですが、有線LANのシンプルな実機検証環境で改めて試験を行い、データを可視化することで、以下の基本ポイントを再確認できました。

  • 制御できるのは「出ていく波」だけ
    ダウンロード方向(下り)の通信品質まで担保したい場合、自分のルーターで受信を無理やり絞る(ポリシングで強制ドロップする)のではなく、通信を押し出してくる「対向側(送信元)のルーター」にシェーピングを仕込むという、ネットワーク全体での設計アプローチが不可欠です。
  • 検証環境を組んで確かめる大切さ
    実際に試験系を組んで「上り・下りのどちらに効いているのか」をパケットの挙動やモニタから追うことの大切さを改めて実感しました。

実際の検証データに基づいたこの結果が、WAN側帯域制御を設計する際の参考になれば幸いです。

参考(Sources)

3
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?