明日、18日から25日まで久しぶりのアメリカ出張です。Communicaton2001の視察とロス、サンフランシスコ周辺企業の訪問が目的です。2年ぶりにCISCO本社を訪問したかったのですが、アポが取れませんでした。かわりにCISCOのことをCISCO以上に知っている、かもしれないJuniper社にアポイントを貰うことが出来ました。これは情報化研究会のコアメンバーである渡部さんの仲介のおかげです。出張のため来週の「間違いだらけ」は1日遅れの25日に掲載します。PCを持っていってアメリカから記事をFTPするのもカッコいいのですが、ビデオ以外の機械は持っていかないので。Scalable?今週の掲示板はCWCの広域LANの話題で盛り上がりました。皆さんの関心がどんどん高まるのはいいことだと思います。メールでの質問も届きました。メールの主は約80拠点のVoIPを広域LANで実現するとのこと。盛り上がりのきっかけを作った2つの質問と、それに対する最も適切と思われる回答を引用させて頂きます。引用だけでは無責任なので私のコメントは例によって*に続けて書いておきます。文学的理解に基づいたコメントなので、厳密さに欠ける点はご容赦。13:02:53松田さま、いつもHP拝見させていただいています。こちらのHPは技術レベルが高いのでいつも勉強になります。今回の「間違いだらけのネットワーク作り(169)」にちょっと気になる記述があり、質問したいので投稿します。以下の部分>*理由は簡単でデータ系がTCP主体である限り、TCPのフロー制御が機能>するので低速側のスループットに合ったデータ転送が行われるからです。確かにTCPコネクションが確立した後、送信側はスロースタートによって緩やかにウィンドウサイズを増加させていくので、低速側のスループットに合った安定した通信が可能なのですが、APレベルでの応答を待って次の送信データを送るようなAPの場合は、ウィンドウサイズ増加後は一気にウィンドウサイズ分のTCPパケットをネットワークに送出してしまって送信bufferでオーバーフローが発生する可能性が高いと思うのですがいかがでしょうか?実は私は中国で衛星データ通信ネットワークの構築作業に関ったことがあるのですが、このとき衛星通信なのでウィンドウサイズを十分大きく取る必要があるのにセンター拠点のFR交換機が上記のような理由で周期的にパケット破棄を発生してしまい十分なスループットが得られずに苦労した経験がありました。このときはルータでのシェーピングが効果的な解決策でした。広域LANサービスをTCP通信で利用するにあたって、帯域制御装置が必要か否かはとても興味深いテーマですので、回答いただければ幸いです。送信側はACKをまたなければなりません。TCPの受信ウィンドウサイズは所詮8Kとか16Kなので、TCPの実装がそれを無視してバースト的にネットワークにパケットを流せば、それはバグです。TCPの再送バッファも所詮8K,16Kで、それを超えて書き込もうとされたら、sendシステムコールはブロックしてAP(上位アプリケーション)に制御を返さないでしょう。このためAPは再送バッファが掃けるのを待たされます。このメカニズムが、AP-TCP間の一種のシェーピング機能に相当します。toyaさんがルータにシェーピングをかけられたのとsendシステムコールが制御を返さないのは、再送バッファをオーバフローさせないというところで同じ意味でしょう。しまい十分なスループットが得られずに苦労した経験がありました。このときはルータでのシェーピングが効果的な解決策でした。>遅延が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も堂々と使っています。音声も試聴させていただきました。*広域LANを使う上で帯域制御装置が必要なケースは多いと思います。データだけの場合は無くて済ませられることが多い、と事実にもとづいて確信しています。13:23:36仕事では大雑把な視点でネットワーク設計をしています。興味の湧く投稿だったので質問させたいただきたいと思います。潰されそうです.ブロードキャストドメインの話はよく聞くのですが、100拠点がルータを設置した場合には佐藤さんもおっしゃているようにOSPFで運用すると思いますので、問題になりそうなブロードキャストはルータ間のARPだと思います。ルータのMACテーブルのリフレッシュが5分おきだと仮定してざっくり平均値を計算すると300÷100で3秒毎にARPが飛ぶことになります。ARPを46Byte(368bit)だとすると3秒おきに368bitのEtherフレームが飛ぶことがそんなに問題でしょうか。スイッチのppsに影響が出るとしてもそれほどの影響がないように思えるのですが、この考え方は勘違いでしょうか。広域LANで拠点を接続する場合にはセンタ局のスイッチを中心に各スイッチがスター上に接続されるイメージかと思うのですが、この場合ループがないのでスパニングツリーは動かないと思うのですが。それとも佐藤さんのおっしゃっていることはバックアップ回線として本社などが2回線借りる場合を想定してらっしゃるのでしょうか。−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−*結論から。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拠点程度で回線速度が低速の拠点が多くても実用上問題ないということです。networksと言えるのではないでしょうか。Routerでリンスステート自体を削減できるので問題になりません。OSPFで流される経路数が多い場合はDRの負荷に注意を払う必要があります。*さらに数100拠点ならどうするか。セグメントを分けるのも一つの手段でしょう。*さて、私が設計中のネットワークの一つで広域LANを使う予定です。広域LANで接続するのはバックボーンの数箇所のみ。残りの100ヶ所あまりは当たり前のフレームリレー網です。要はネットワークの要件によって広域LANであれ、IP−VPNであれ、FRであれ、適材適所で使い分けたり、組み合わせればいいのです。*脳みそに「広域LAN命」とか、「IP−VPN命」と刺青を彫りこんで、石頭な設計をする気はさらさらありません。