IX2015ではtraffic-shapeコマンドとpolicy-mapを使ったQoS
を同時にかけられるけどCisco 1812Jの15.1(4)Mではtraffic-shape
(GTS)コマンドがヘルプでは出てこなくなっていてもう使うなと言わん
ばかりでした。MQCとの同時利用もできませんでしたが、
MQCを使ってネスト構造とすることにより同じ機能は再現できました。
というかやはりCiscoのほうが細かいことができます。IX2015だと
細かい部分の処理の流れなどがドキュメントに載ってなかったりして
実際にパケットを流してどうなるか調べないと使えない状態になりました。
たとえばtraffic-shapeとpriorityコマンドはどのように作用するか
とか、パケットは遅延するのかそれとも割り込む形になるのか・・・
ドキュメントをもう少し充実させてもらえるとなお良いです。
Ciscoのほうはネスト構造を使ってコテコテに記述もできるし
使い込めばやれるだけやれる感じです。
priorityとshapeコマンドの振る舞いの記述もありました。
IX2015のシンプルな考えもわからなくも無いですが・・・
IX2015も1812Jも5000円位で買えるようになってきてるので
あれですが両方あると細かいところに手が届いて面白いです
コマンド自体もさほど変わらないしいろいろいじるんだったら
IOSのほうが自由度がある感じはしますがTinyな感じが味わい
たいときはIX2015のほうが面白いです。
IX2015はバグが少なく設定後なんかおかしくなってreload
と言うパターンはほとんど無いです。IOSは・・・バグによく
遭遇します(自由度が高い分しょうがない気はしますが)
大概おかしな設定をした(通ってしまうのが怖い)可能性が高い
です。そういう時はセーブしないでreloadしましょう。
少し前のTトレインIOSはエラーログ残して吹っ飛んだことが
1回ありました。
そのほかは設定が反映されなくなったりとかnoコマンド
で解除できないバグにも遭遇しました。
最近はMラインでずいぶん安定したと思います。
2011年3月29日火曜日
2011年3月26日土曜日
QoSの設定その3
QoSを煮詰めているとどうもACLが複雑になるばかりで
良くないことが判明。
それで思いついたのがIX2015のQoSでIP precedenceをカラーリング
してからCisco 1812JでCBWFQ+LLQの二段構成でやってみることにした。
IP precedenceを使うことには多少抵抗があったが使ってみると
これが非常に快適でACLの複雑性から開放された。
IX2015のカラーリングはclass分けするのでFIFOで動作する
パケットは入力順にカラーリングされて出力される。カラーリングしながら
PQは使えない。あくまでFIFO動作だ。
うちの環境はADSLなので上り帯域は3Mbps弱なので1812Jでclass-default
にshape average ~としてシェーピングを掛けている。
ファイルサーバーはshape averageとbandwidthを両方かけてある。
ファイルサーバーは輻輳時帯域を128kbpsまで絞ってしまう設定にした。
シェーピングを掛けたほうが上りの帯域は安定する。
ミッションクリティカルなip precedenceはLLQとしてpriorityコマンドで
かけている。
ためしにネットワークを使ってみるとファイルサーバ転送時でも
httpで上り3Mbps確保できることを確認した。
ファイルサーバー転送時でもLLQパケットのレイテンシ
は低いままだった。ネットゲームのラグも無く非常に快適だ。
今日、1812JのIOSをバージョンアップしたTトレインでは無くM
(メインライントレイン)に変更した。
15.1(3)T→15.1(4)Mに変更した。
1812JではこれからはTトレインは発表されなくなってくるのかな
結構なバグが取れているらしく、新しい機能も組み込まれた。
IOSのファイルサイズが若干大きくなった。
良くないことが判明。
それで思いついたのがIX2015のQoSでIP precedenceをカラーリング
してからCisco 1812JでCBWFQ+LLQの二段構成でやってみることにした。
IP precedenceを使うことには多少抵抗があったが使ってみると
これが非常に快適でACLの複雑性から開放された。
IX2015のカラーリングはclass分けするのでFIFOで動作する
パケットは入力順にカラーリングされて出力される。カラーリングしながら
PQは使えない。あくまでFIFO動作だ。
うちの環境はADSLなので上り帯域は3Mbps弱なので1812Jでclass-default
にshape average ~としてシェーピングを掛けている。
ファイルサーバーはshape averageとbandwidthを両方かけてある。
ファイルサーバーは輻輳時帯域を128kbpsまで絞ってしまう設定にした。
シェーピングを掛けたほうが上りの帯域は安定する。
ミッションクリティカルなip precedenceはLLQとしてpriorityコマンドで
かけている。
ためしにネットワークを使ってみるとファイルサーバ転送時でも
httpで上り3Mbps確保できることを確認した。
ファイルサーバー転送時でもLLQパケットのレイテンシ
は低いままだった。ネットゲームのラグも無く非常に快適だ。
今日、1812JのIOSをバージョンアップしたTトレインでは無くM
(メインライントレイン)に変更した。
15.1(3)T→15.1(4)Mに変更した。
1812JではこれからはTトレインは発表されなくなってくるのかな
結構なバグが取れているらしく、新しい機能も組み込まれた。
IOSのファイルサイズが若干大きくなった。
2011年3月23日水曜日
QoSの設定その2
cisco 1812jの方には前記したようにCBWFQ+LLQでQoSを掛けてあるが
ネットワークの途中にあるIX2015には掛けてなかったのでQoSの設定を
してみることにした。
IX2015のQoSはCiscoほど自由度が無くとりあえずPQで掛けて
みることにした。
とりあえずネットゲーのパケットはHigh queueにそれ以外はNormal
ファイルサーバーはLowに分類することにした。
IX2015のプライオリティーキューイングはクラス内のパケットの優先順位
ということでクラスが変わると無効になってしまうらしい。
ここでひとつ落とし穴、最初1つのクラスにするのではなく複数のクラスに
分けて記述してpriorityコマンドとbandwidthコマンドで制御しようとしたが
priorityコマンドはCiscoと違って輻輳の有る無しにかかわらず指定したレート
を上回るパケットはドロップする仕様らしい。なのでCiscoのLLQとは
ちょっと違った動作をするのであった。
なので使えないのでまずクラスを1つにしてbandwidthを設定して
queue-limit 8 32 64 96としてqueueの深さを設定してHigh queue をあまり
バッファーしないように設定する。
それとpolicy-map ~とするとclass-defaultが勝手に出来てしまうので
match any Normalとして明示的にほかのパケットはNormalと宣言して
やらないと未指定のパケットがclass-defaultにヒットしてPQがうまく掛からない
現象が発生する。つまりIX2015のPQはクラス内のPQなので少し面倒だ。
IX2015でPQを使う場合あくまでクラスは1つしか使えないということだ。
設定を完了してしばらくネットワークを使ったあとsh policy-map interface
で確認を取ってみると、High queueがpeakで4 queueバッファしてることが
わかったマージンは倍あるのでよしとしよう。
あまりバッファーしても遅延してしまうので要注意だ。
ネットワークの途中にあるIX2015には掛けてなかったのでQoSの設定を
してみることにした。
IX2015のQoSはCiscoほど自由度が無くとりあえずPQで掛けて
みることにした。
とりあえずネットゲーのパケットはHigh queueにそれ以外はNormal
ファイルサーバーはLowに分類することにした。
IX2015のプライオリティーキューイングはクラス内のパケットの優先順位
ということでクラスが変わると無効になってしまうらしい。
ここでひとつ落とし穴、最初1つのクラスにするのではなく複数のクラスに
分けて記述してpriorityコマンドとbandwidthコマンドで制御しようとしたが
priorityコマンドはCiscoと違って輻輳の有る無しにかかわらず指定したレート
を上回るパケットはドロップする仕様らしい。なのでCiscoのLLQとは
ちょっと違った動作をするのであった。
なので使えないのでまずクラスを1つにしてbandwidthを設定して
queue-limit 8 32 64 96としてqueueの深さを設定してHigh queue をあまり
バッファーしないように設定する。
それとpolicy-map ~とするとclass-defaultが勝手に出来てしまうので
match any Normalとして明示的にほかのパケットはNormalと宣言して
やらないと未指定のパケットがclass-defaultにヒットしてPQがうまく掛からない
現象が発生する。つまりIX2015のPQはクラス内のPQなので少し面倒だ。
IX2015でPQを使う場合あくまでクラスは1つしか使えないということだ。
設定を完了してしばらくネットワークを使ったあとsh policy-map interface
で確認を取ってみると、High queueがpeakで4 queueバッファしてることが
わかったマージンは倍あるのでよしとしよう。
あまりバッファーしても遅延してしまうので要注意だ。
2011年3月21日月曜日
QoSの設定
1812JだがQoSでPQ(プライオリティーキューイング)を使うと設定はできても
実際動いているのかどうかわからない。確認コマンドが無いので
いろいろWEBで調べてみるとCiscoのホームページの1812Jのカタログ
のQoSの欄にPQの文字が無い。これは動かないのかもしれない。
富士通のほうの1812JのカタログにはPQできると書いてあるが
どうも動いてないっぽい。
いや動いていたとしてもいまさらPQなんか使わないというか
PQって1Mbit/sec以下のときに有効に作用するらしい、
うちのアップリンクは2.70Mbit/secくらい出てるのでPQではなく
CBWFQ+LLQで再構築してみることにしました。WFQ自体は
2Mbit/sec以下で有効に作用するとありますが、FIFOでも
特に問題が無いのかもしれませんがとりあえずclass-defaultには
fair-queueの一文を追加しておくことにしました。
ネットゲームのレイテンシを落とさないためにpriorityコマンドで
LLQの設定をしてみましたpriorityコマンド自体は最大帯域を制限する
コマンドではなく輻輳時の最小帯域幅保証なので設定したレートを
超えることが可能です。
ちょっとわき道にそれてpoliceコマンドとshapeコマンドで遊んでみました
ちゃんと帯域制限はかかるみたいです。1Mbit/secで制限すると
shapeコマンドのほうはばっちり1Mbit/secでした。policeコマンドは
バッファーしないでドロップさせるのでTCPの輻輳の関係上若干レートは
落ちましたがレイテンシ(ジッタ)はこっちのほうがいいのかもしれません。
fair-queueのオプションの意味がわからなかったがほとんどの場合変更する
必要は無いらしい・・・
ということであっさり動いてしまった。
実際動いているのかどうかわからない。確認コマンドが無いので
いろいろWEBで調べてみるとCiscoのホームページの1812Jのカタログ
のQoSの欄にPQの文字が無い。これは動かないのかもしれない。
富士通のほうの1812JのカタログにはPQできると書いてあるが
どうも動いてないっぽい。
いや動いていたとしてもいまさらPQなんか使わないというか
PQって1Mbit/sec以下のときに有効に作用するらしい、
うちのアップリンクは2.70Mbit/secくらい出てるのでPQではなく
CBWFQ+LLQで再構築してみることにしました。WFQ自体は
2Mbit/sec以下で有効に作用するとありますが、FIFOでも
特に問題が無いのかもしれませんがとりあえずclass-defaultには
fair-queueの一文を追加しておくことにしました。
ネットゲームのレイテンシを落とさないためにpriorityコマンドで
LLQの設定をしてみましたpriorityコマンド自体は最大帯域を制限する
コマンドではなく輻輳時の最小帯域幅保証なので設定したレートを
超えることが可能です。
ちょっとわき道にそれてpoliceコマンドとshapeコマンドで遊んでみました
ちゃんと帯域制限はかかるみたいです。1Mbit/secで制限すると
shapeコマンドのほうはばっちり1Mbit/secでした。policeコマンドは
バッファーしないでドロップさせるのでTCPの輻輳の関係上若干レートは
落ちましたがレイテンシ(ジッタ)はこっちのほうがいいのかもしれません。
fair-queueのオプションの意味がわからなかったがほとんどの場合変更する
必要は無いらしい・・・
ということであっさり動いてしまった。
2011年3月19日土曜日
EHアンテナVシリーズ
EHアンテナのVシリーズが発売になるようだ。
シリンダーは無くなりエレメントらしきものに取って代わった。
ラジアルが無いことからノンラジアルタイプと思われる。
これだと超短縮ノンラジアル垂直型アンテナに思えてきた。
このサイズの垂直アンテナと比較したデータがほしい。
電流と電圧を90°位相差で給電するだけで
本当に2.15dBiのアンテナができるとは思えないので
何かが間違ってると思うのだが・・・
自作EHアンテナは3mmのエナメル線を使ってなるべく低損失
にして約-20dBd位のアンテナしか出来なかった。
あれ以上ゲインを稼ぐにはどうすればよいのか?
リンクコイルで給電するようにして強制バランを使うのが今まで試した中で
一番ゲインが取れた。
それ以上にするとなるとシリンダーを長くするとかコイルの直径を
大きくするとかインピーダンス変換回路を作ってリンクコイルを
蜜結合として整合を取るかだろう。
リンクコイルの結合を疎にしてはいけないのかもしれない
前者はサイズ的に良くないので後者で3号機で試してみることにする。
4:1バランは作るのが面倒なんだよな・・・
でもそれで2.15dBiのゲインが出るとは考えにくいが
実際買って使ってみるというのも手だ・・・
それで性能が出なきゃ以下略。
シリンダーは無くなりエレメントらしきものに取って代わった。
ラジアルが無いことからノンラジアルタイプと思われる。
これだと超短縮ノンラジアル垂直型アンテナに思えてきた。
このサイズの垂直アンテナと比較したデータがほしい。
電流と電圧を90°位相差で給電するだけで
本当に2.15dBiのアンテナができるとは思えないので
何かが間違ってると思うのだが・・・
自作EHアンテナは3mmのエナメル線を使ってなるべく低損失
にして約-20dBd位のアンテナしか出来なかった。
あれ以上ゲインを稼ぐにはどうすればよいのか?
リンクコイルで給電するようにして強制バランを使うのが今まで試した中で
一番ゲインが取れた。
それ以上にするとなるとシリンダーを長くするとかコイルの直径を
大きくするとかインピーダンス変換回路を作ってリンクコイルを
蜜結合として整合を取るかだろう。
リンクコイルの結合を疎にしてはいけないのかもしれない
前者はサイズ的に良くないので後者で3号機で試してみることにする。
4:1バランは作るのが面倒なんだよな・・・
でもそれで2.15dBiのゲインが出るとは考えにくいが
実際買って使ってみるというのも手だ・・・
それで性能が出なきゃ以下略。
2011年3月18日金曜日
2011年3月15日火曜日
地震後の7MHzとPHS
地震後の7MHzのコンディションはまずまずで
例のバタバタノイズは聞こえない。
非常通信が7.030MHzと7.043MHzで行われていた。
インターネットは調子がよく地震直後から問題ない。
willcomのPHSだがPHS同士の通話は地震直後でも
繋がった。PHSとアナログ電話との通信は発信規制がかかった。
PHSは意外に障害に強かった。
例のバタバタノイズは聞こえない。
非常通信が7.030MHzと7.043MHzで行われていた。
インターネットは調子がよく地震直後から問題ない。
willcomのPHSだがPHS同士の通話は地震直後でも
繋がった。PHSとアナログ電話との通信は発信規制がかかった。
PHSは意外に障害に強かった。
登録:
投稿 (Atom)