Openflowを語ろう
■ このスレッドは過去ログ倉庫に格納されています
ネットワークのしょうもないバッドノウハウを減らしてくれそうな期待はあるけど、
シスコ的にはあんまり嬉しくないよね？こういうの というか、日経よねw
シスコもブロケードも名前連ねてはいるけど動きないしなぁ。 正直、よくわからん。一見、シンプルなようにもみえるけど、
運用する側から見れば、なんか複雑な感じはする。 通信できなくなるよ。コントロールプレーンがなくなるから。
なのでコントローラは冗長化する。
冗長コントローラの切り替わりはコントローラごとに実装ちゃうのかな。 コントローラーって高くない？
あと処理能力ってどうなの？ Open vSwitchを入れるいいベアボーンないかな。
組んだら普通のSwitchみたいになるのがいいな。
GbEが4〜8portくらいで。 OpenFlow対応の安いSW無いかな？
実機でどの程度の性能なのか検証したいんだよなぁ。 >>14
procurve 3500シリーズで実験中。でもIP4だけとか制約かなりあるんだよなあ。 うちの現場は、いまクラウド（AmazonAWSとか）に夢中でＮＷ機器には興味が無いようだよ、とほほ・・・。
検証やりたいなぁ。 >>16
うっそ今時v4だけなんだ。
まあ鋭意開発中なんだろうけどね。 >>17
この前3500yl-24-PoEが３万程度でオクに出てたけどね。
>>18
本来的には「パケット内バイト位置」「マスクパターン」「その値」でヒットすべきで、プロトコルなんてかけらも関係ないはずなんだけどね。
もともとopenflowでもプロトコルを意識した作りになっているし、なかなかそういう「超汎用」にはできないみたい。
3500に積まれてるprovision asicの制約だろうね。
asicで処理できないパケットはスイッチのcpuで処理することになるんだけど、そうなると下手なopen vswitchより遅くなりそーな。
これはopenflowをターゲットにしてasic起こさない限り解決しないと思うんで、今使えてるスイッチにファームだけで対応しますよー、
みたいなのは結局実験レベルのお遊びかと。 > 本来的には「パケット内バイト位置」「マスクパターン」「その値」でヒットすべきで、プロトコルなんてかけらも関係ないはずなんだけどね。
プロトコルが関係ないわけ無いだろう。
バイト位置なんて、オプションヘッダや拡張ヘッダとかつかってたら
余裕で変わるじゃないか。
プロトコルとして解析する必要があるに決まってる。 最たる例はフラグメントパケットだな。
IPv4ですら先頭しか制御できないアフォSW多すぎ。 >バイト位置なんて、オプションヘッダや拡張ヘッダとかつかってたら
だったら「そういうのでずれる」のを意図して複数書くとか、「そういうのでずれる」のをif文で書けるようにするとか。
いずれにせよ素の段階ではプロトコル意識しないはずなんだよね。でもそういう例外規定がいっぱいあると
テーブル爆発しちゃうから、結局プロトコル毎の作り込みになってる、と。
＞IPv4ですら先頭しか制御できないアフォSW多すぎ。
パケット間の連携をどう取るかはまたちょっと異なる話かと。
今の安めのスイッチの作りだと先頭パケットはCPU処理(=コントローラ処理)、
残りはASIC処理なんで後ろのパケットに関して高度な処理はできないと思われ。 ■ このスレッドは過去ログ倉庫に格納されています
