間違いだらけのネットワーク作り(170) 2001/03/17
「Is L2VPN Scalable?」

明日、18日から25日まで久しぶりのアメリカ出張です。 ロサンゼルスで行われるOptical Fiber Communicaton2001の視察とロス、サンフランシスコ周辺企業の訪問が目的です。 2年ぶりにCISCO本社を訪問したかったのですが、アポが取れませんでした。(当然?)  かわりにCISCOのことをCISCO以上に知っている、かもしれないJuniper社にアポイントを貰うことが出来ました。 これは情報化研究会のコアメンバーである渡部さんの仲介のおかげです。 

出張のため来週の「間違いだらけ」は1日遅れの25日に掲載します。 PCを持っていってアメリカから記事をFTPするのもカッコいいのですが、ビデオ以外の機械は持っていかないので。

Is L2VPN Scalable?

今週の掲示板はCWCの広域LANの話題で盛り上がりました。 皆さんの関心がどんどん高まるのはいいことだと思います。 メールでの質問も届きました。 メールの主は約80拠点のVoIPを広域LANで実現するとのこと。

さて、盛り上がりのきっかけを作った2つの質問と、それに対する最も適切と思われる回答を引用させて頂きます。 引用だけでは無責任なので私のコメントは例によって*に続けて書いておきます。 文学的理解に基づいたコメントなので、厳密さに欠ける点はご容赦。

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
TCPのフロー制御について  Follow: 288 / No: 280 [返信][削除]

 投稿者:yota  01/03/12 Mon 13:02:53
松田さま、いつもHP拝見させていただいています。
こちらのHPは技術レベルが高いのでいつも勉強になります。
今回の「間違いだらけのネットワーク作り(169)」にちょっと気になる記述
があり、質問したいので投稿します。

以下の部分
>*理由は簡単でデータ系がTCP主体である限り、TCPのフロー制御が機能
>するので低速側のスループットに合ったデータ転送が行われるからです。

なのですが、確かにTCPコネクションが確立した後、送信側はスロースタートに
よって緩やかにウィンドウサイズを増加させていくので、低速側のスループットに
合った安定した通信が可能なのですが、APレベルでの応答を待って次の送信データ
を送るようなAPの場合は、ウィンドウサイズ増加後は一気にウィンドウサイズ分の
TCPパケットをネットワークに送出してしまって送信bufferでオーバーフローが
発生する可能性が高いと思うのですがいかがでしょうか?

実は私は中国で衛星データ通信ネットワークの構築作業に関ったことがあるので
すが、このとき衛星通信なのでウィンドウサイズを十分大きく取る必要があるのに
センター拠点のFR交換機が上記のような理由で周期的にパケット破棄を発生して
しまい十分なスループットが得られずに苦労した経験がありました。
このときはルータでのシェーピングが効果的な解決策でした。

広域LANサービスをTCP通信で利用するにあたって、帯域制御装置が必要か否かは
とても興味深いテーマですので、回答いただければ幸いです。
 

Re: TCPのフロー制御について  Prev: 280 / No: 288 [返信][削除]

 投稿者:はた  01/03/14 Wed 12:59:43
確かにTCPコネクションが確立した後、送信側はスロースタートに
> よって緩やかにウィンドウサイズを増加させていくので、低速側のスループットに
> 合った安定した通信が可能なのですが、APレベルでの応答を待って次の送信データ
> を送るようなAPの場合は、ウィンドウサイズ増加後は一気にウィンドウサイズ分の

スロースタートで使われる輻輳ウィンドウが大きくなっても、
TCPのピア側の受信バッファウィンドウサイズで頭打ちされるので、
送信側はACKをまたなければなりません。TCPの受信ウィンドウサイズは
所詮8Kとか16Kなので、TCPの実装がそれを無視してバースト的に
ネットワークにパケットを流せば、それはバグです。TCPの再送バッファも
所詮8K,16Kで、それを超えて書き込もうとされたら、sendシステムコールは
ブロックしてAP(上位アプリケーション)に制御を返さないでしょう。
このためAPは再送バッファが掃けるのを待たされます。
このメカニズムが、AP-TCP間の一種のシェーピング機能に相当します。
toyaさんがルータにシェーピングをかけられたのとsendシステムコールが
制御を返さないのは、再送バッファをオーバフローさせないというところで
同じ意味でしょう。
 

> 実は私は中国で衛星データ通信ネットワークの構築作業に関ったことがあるので
> すが、このとき衛星通信なのでウィンドウサイズを十分大きく取る必要があるのに
> センター拠点のFR交換機が上記のような理由で周期的にパケット破棄を発生して
> しまい十分なスループットが得られずに苦労した経験がありました。
> このときはルータでのシェーピングが効果的な解決策でした。
>

遅延が1秒あるリンクで速度が2Mbpsと仮定すれば、そのリンクの回線使用率を
100%確保するためには最低約4Mbitの再送バッファサイズに相当する
ウィンドウが必要ですね。宇宙空間上に2M、相手は受信確認
しているがACKの遅延のため、送信側で開放できないものが2M
(相手先が、最初の1ビットを受信しただけで
ACKを送信するという前提でなのですが)。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
*はたさんも情報化研究会のコアメンバーです。 TCPのウィンドウサイズが所詮8Kとか16Kしかない、というのがミソなのですね。

*はたさんの理論に対して、私は事実を書きましょう。 広域LANを実際に使った評価テストをCWCさんやL3SWメーカーであるアライドテレシスさん、さらには帯域制御装置のベンダーさん2社にも協力いただいて実施しました。 1.5Mと128Kという10倍以上の速度ギャップのある拠点間で負荷をかけてVoIPを実験したのです。

*結果。 TCPでいくら負荷をかけても低速へのL2SWポートでのパケットロスはなかなか起きないのです。 もちろん帯域制御装置を付けてない状態の時です。 UDPで負荷をかけるとわりと簡単にパケットロスが出るようです。 また、佐藤さんの言うようにTCPのコネクション数を増やせばTCPでもパケットロスが起きやすくなるかもしれませんが、しょせん128Kで使うような拠点はコネクションは多くないでしょう。 VoIPについても興味深い結果が出ましたが、これは実験参加社だけの秘密ということでここには書きません。 結論は「行ける」ということです。

*次に実験ではなく実ユーザ。 約30拠点を速度の異なる回線を交えて使っている例がありますが、ここでも帯域制御装置は使われておらず、あろうことかVoIPも堂々と使っています。 音声も試聴させていただきました。 OKです。 

*広域LANを使う上で帯域制御装置が必要なケースは多いと思います。 しかし、データだけの場合は無くて済ませられることが多い、と事実にもとづいて確信しています。
 

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Is L2WAN service scalable ?  Follow: 283 / No: 281 [返信][削除]

 投稿者:佐藤正和  01/03/12 Mon 14:11:49
最近,アカウントを取得した佐藤です.研究会の方には一回だけ顔を出したこ
とがありますが,よろしくおねがいします.

松田さんは,CWC が提供している広域 LAN サービス(広域 LAN という言い方
には抵抗を感じるので ^^; L2 WAN と書かせて頂きました)を非常に高く評価
されていますが,どうも引っ掛かる点があるので書かせて頂きました.私はそ
れほど実務経験があるわけではないのですが,大規模ネットワークデザインの
基本要項として,ブロードキャストドメインの分割が重要になることは,周知
の事実だと思います.L2WAN は論理的には単一サブネットですから,ARP や
RIP などのブロードキャストトラフィックはすべてのアクセス線へ流れること
になります.たしかに,2拠点,3拠点なら問題は少ないと思いますが,100 拠
点となったらどうでしょう? 128K ぐらいの細いアクセス線では,すぐに食い
潰されそうです.

ブロードキャストを WAN 側に流さない構成も可能とは思いますが,それはそ
れで,ルーティングテーブル等の管理が大変になるので,やりたくないですよ
ね?

また,今後アクセスポイントが増えていったときに,網内の L2SW の数も増え
ていくと思いますが,その場合スイッチ間のルーティングはどうするのでしょ
う? まさかスパニングツリープロトコルでしょうか?

つまり,L2WAN はスケールしない範囲ではうまく動くサービスで,だから US
ではやってない,だと思うのですが,いかがでしょうか?
 
 
 
 

Re: Is L2WAN service scalable ?  Prev: 281 / No: 291 [返信][削除]

 投稿者:TNB  01/03/15 Thu 13:23:36
仕事では大雑把な視点でネットワーク設計をしています。
興味の湧く投稿だったので質問させたいただきたいと思います。

> 大規模ネットワークデザインの
> 基本要項として,ブロードキャストドメインの分割が重要になることは,周知
> の事実だと思います.L2WAN は論理的には単一サブネットですから,ARP や
> RIP などのブロードキャストトラフィックはすべてのアクセス線へ流れること
> になります.たしかに,2拠点,3拠点なら問題は少ないと思いますが,100 拠
> 点となったらどうでしょう? 128K ぐらいの細いアクセス線では,すぐに食い
> 潰されそうです.

ブロードキャストドメインの話はよく聞くのですが、100拠点がルータを設置した
場合には佐藤さんもおっしゃているようにOSPFで運用すると思いますので、問題
になりそうなブロードキャストはルータ間のARPだと思います。
しかしながら例えばルータのMACテーブルのリフレッシュが5分おきだと仮定して
ざっくり平均値を計算すると300÷100で3秒毎にARPが飛ぶことになります。
ARPを46Byte(368bit)だとすると3秒おきに368bitのEtherフレームが飛ぶことが
そんなに問題でしょうか。スイッチのppsに影響が出るとしてもそれほどの影響が
ないように思えるのですが、この考え方は勘違いでしょうか。

また、広域LANで拠点を接続する場合にはセンタ局のスイッチを中心に各スイッチ
がスター上に接続されるイメージかと思うのですが、この場合ループがないので
スパニングツリーは動かないと思うのですが。
それとも佐藤さんのおっしゃっていることはバックアップ回線として本社などが
2回線借りる場合を想定してらっしゃるのでしょうか。

以上。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
*結論から。 Is L2VPN scalable? Yes, scalable enough for corporate networks.

*L3SWやルータで各拠点内は別セグメントにしてもWAN側は1セグメントになるのはそのとおりですね。
しかし、拠点数が数100という規模になったらWAN側のセグメントを分割すればそれでOKな話ではないでしょうか?

*問題は何拠点程度までWAN側が1セグメントでいけるか。 これは知りたいですね。

*これもウダウダした議論より、事実の方が説得力がありますね。 既に100拠点規模の広域LANがWAN側1セグメントで動いています。
回線は半分以上が128Kで、残りは1.5M以上、VoIP一部あり、というのがおおまかな構成です。

*WAN側でブリッジは通さず。 ルーティングはOSPF。 WAN側のオーバヘッドとしてOSPFのHELLOパケットがありますが、
HELLOパケットは48バイト、送出間隔は最大値の30秒に設定。 30秒間で48バイトのパケットが100個=1.28kb/s。 128Kの回線でも
何ら問題にならない負荷です。

*つまり、100拠点程度で回線速度が低速の拠点が多くても実用上問題ないということです。 これはほとんどの企業ネットワークでは問題にならない、Scalable enough for corporate networksと言えるのではないでしょうか。 リンクステートのやりとりは負荷がHELLOより重いそうですが、Designated Routerでリンスステート自体を削減できるので問題になりません。 ただ、OSPFで流される経路数が多い場合はDRの負荷に注意を払う必要があります。

*さらに数100拠点ならどうするか。 セグメントを分けるのも一つの手段でしょう。

*さて、私が設計中のネットワークの一つで広域LANを使う予定です。 しかし、広域LANで接続するのはバックボーンの数箇所のみ。 残りの100ヶ所あまりは当たり前のフレームリレー網です。 要はネットワークの要件によって広域LANであれ、IP−VPNであれ、FRであれ、適材適所で使い分けたり、組み合わせればいいのです。

*脳みそに「広域LAN命」とか、「IP−VPN命」と刺青を彫りこんで、石頭な設計をする気はさらさらありません。
 
 
 

ホームページへ