uso8000k.net

晴れてOpenFlowで遊べる環境というものが出来ましたが、何が出来るのか、とか何を基本に考えるかがまだ分からない。ということで、以下を参考に暫くは使い方なりコンポーネントを触って出来ることを確認。その上でコードを読むスタンスで行きましょう。ggr:"POX"+”書き方” とかしてもへぇ・・・だけで終わってしまう。

何気にWebインターフェイスを持っていたり。

追伸: 前回のPOX試した時にやたらとあがっていたDHCPのパケットはLinuxMicroのOpenvSwitchにて発射されていたしてたみたいで・・・どうも気を効かせてDHCPが全インターフェイス有効になっていた模様。即pkill。

実はOpenFlowについてはちゃんとした本を読んでいなかったり、出来ることをつまみつまみ見ていたのでまだ理解をしていない。そもそもOpenvSwitchとOpenFlowの関係であったりもイマイチ掴めていない。後からOpenFlowに対応したっぽくはある。てとりあえず、OpenFlowコントローラの制御下にあるとOpenvSwitchの設定よりそちらが優先される挙動は間違いなさそうです。

OpenFlow をまだ心で理解できていないので、手近なOpenvSwitchだけを少し触ってみる。

//初期化
# ovs-vsctl init
//仮想ブリッジ作成
# ovs-vsctl add-br   br0
//ポート割り当て
# ovs-vsctl add-port br0 eth0
# ovs-vsctl add-port br0 eth1
# ovs-vsctl add-port br0 eth2
# ovs-vsctl add-port br0 eth4
//vlan ID=100 (PVID) をつくてみる
# ovs-vsctl del-port br0 eth2
# ovs-vsctl del-port br0 eth4
# ovs-vsctl add-port br0 eth2 tag=100
# ovs-vsctl add-port br0 eth4 tag=100

//vlan ID100 のTrunk
# ovs-vsctl add-port br0 eth4
# ovs-vsctl add-port br0 eth4 trunk=100

なんとなく簡単に何か設定する分には直感的でやりやすい印象でした。

openflow と OpenFlow は違うのね・・・ 言われてみればそうだ

コマンド復唱と挙動の確認に昨日のL2フォワードを少し弄ってみる。

root@box:~# ovs-vsctl show
a66779ff-0224-40ef-89f1-0deb21b939db
    Bridge "br0"
        Controller "tcp:192.168.254.100"
        Port "br0"
            Interface "br0"
                type: internal
        Port "eth0"
            Interface "eth0"
        Port "eth1"
            Interface "eth1"
        Port "eth2"
            Interface "eth2"

こんな感じのものを3つほど用意。コントローラ無しでもPingが通ります。

さて今回はコントローラでL3のフォワーディングを実行。これも通ります。

# ./pox.py forwarding.l3_learning
POX 0.1.0 (betta) / Copyright 2011-2013 James McCauley, et al.
INFO:core:POX 0.1.0 (betta) is up.
INFO:openflow.of_01:[00-00-ab-f3-41-02 1] connected
INFO:openflow.of_01:[00-ab-05-d3-88-00 2] connected
INFO:openflow.of_01:[00-00-ab-05-5d-02 3] connected
INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
INFO:forwarding.l3_learning:2884845826 2 RE-learned 0.0.0.0
INFO:forwarding.l3_learning:2869255426 2 RE-learned 192.168.0.10
INFO:forwarding.l3_learning:2884845826 2 RE-learned 192.168.0.30
....
...
..
.
^CINFO:core:Going down...
INFO:openflow.of_01:[00-00-ab-f3-41-02 1] disconnected
INFO:openflow.of_01:[00-ab-05-d3-88-00 2] disconnected
INFO:openflow.of_01:[00-00-ab-05-5d-02 3] disconnected
INFO:core:Down.

ところでこれはハブ/スイッチっぽい動作ですが、今日実行したものはL3フォワードによる疎通。ひょっとしてループ状にしてもブロードキャストストーム的な事が起こらないのではないだろうか？ということで以下のようなトポロジにしてみます。

ifconfig eth0 down; ifconfig eth1 down; ifconfig eth2 down;
ovs-vsctl init
ovs-vsctl add-br br0
ovs-vsctl add-port br0 eth0
ovs-vsctl add-port br0 eth1
ovs-vsctl add-port br0 eth2
ovs-vsctl set-controller br0 tcp:192.168.254.100

//3台整ったら
ifconfig eth0 up; ifconfig eth1 up; ifconfig eth2 up;

同じIPを何度も学習してPOXが落ちました。

ERROR:core:Exception while handling OpenFlowNexus!PacketIn...
Traceback (most recent call last):
  File "/root/pox/pox/lib/revent/revent.py", line 234, in raiseEventNoErrors
    return self.raiseEvent(event, *args, **kw)
  File "/root/pox/pox/lib/revent/revent.py", line 281, in raiseEvent
    rv = event._invoke(handler, *args, **kw)
  File "/root/pox/pox/lib/revent/revent.py", line 159, in _invoke
    return handler(self, *args, **kw)
  File "/root/pox/pox/forwarding/l3_learning.py", line 201, in _handle_PacketIn
    "input port" % (dpid, inport, str(dstaddr)))
TypeError: not all arguments converted during string formatting

うーん、いい考えと思ったのですが駄目みたいですね。インターフェイスを落とさないとループしましたし、PC1とPC2 (タイミングによる) だけ応答が出来る等不安定でしたし・・・まだサンプル動かして喜んでる程度では奇抜な事は出来なさそうです。

前回のGNS3の癖を掴んだので分かり易い導入記録を参考にして試してみます。(参考:OpenBlocks AX3でOpenFlowを試してみる) 構成は OpenvSwitch とPython製OpenflowコントローラのPOXにて。NOX (C実装)、Trema (Ruby実装) 等他にも色々ありますが、いずれ自分でも書くことにもなると思いますので、多少慣れているPython実装のPOXを選択。

最初の一歩目。イーサネットブリッジを作ります。

それぞれ適切なインターフェイスにIPアドレスを割り当て、openvswitchにてブリッジを構成。

Openvswitch にて

# 初期化
tc@box:~$ sudo ovs-vsctl init
# ブリッジ仮想インターフェイス作成
tc@box:~$ sudo ovs-vsctl add-br br0
# ブリッジに各イーサネットインターフェイスを割り当て
tc@box:~$ sudo ovs-vsctl add-port br0 eth0
tc@box:~$ sudo ovs-vsctl add-port br0 eth1

実はこれだけでブリッジが作成でき、SoftwareDefinedNetwork的な動きをします。裏で疎通確認用の端末がpingを送っていれば、add-port 以降疎通の確認が可能です。Openvswitchの設定だけでそれなりに高機能なスイッチとして動かせます。

続いてOpenflowコントローラを追加して、POXの制御下に居る事を確認します。

Openvswitchにて

//コントローラ追加
tc@box:~$ sudo ovs-vsctl set-controller br0 tcp:192.168.254.100
//設定はこのような感じになります。
tc@box:~$ sudo ovs-vsctl show
a66779ff-0224-40ef-89f1-0deb21b939db
    Bridge "br0"
        Controller "tcp:192.168.254.100"
            is_connected: true
        Port "br0"
            Interface "br0"
                type: internal
        Port "eth1"
            Interface "eth1"
        Port "eth0"
            Interface "eth0"

Openflowコントローラ用端末にて(FreeBSD8.4)

// githubよりPOXを取得
# git clone http://github.com/noxrepo/pox.git
# cd pox
// poxの実行　L2学習とフォワードのサンプルを使用
// (pox/forwarding/l2_learning.py)
# ./pox.py forwarding.l2_learning
POX 0.1.0 (betta) / Copyright 2011-2013 James McCauley, et al.
INFO:core:POX 0.1.0 (betta) is up.
INFO:openflow.of_01:[00-ab-5e-70-a5-00 1] connected
INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
...

POXの実行をすると、openvswitchにて設定したホストからのコントロール接続を受け付ける。その後、転送を行うサンプルプログラムを実行する。何やらDHCPらしいパケットが常に飛んでいるようですが・・・pingは正常に動作していました。

POXコントローラを止めるとOpenvswitchのみの動作となり、これはこれでブリッジ的な動作を設定しているので、疎通確認のpingは一時的な切断が発生後、正常に通信ができます。さて、そんな中POXにて全く別なプログラムを読み込ませるとどうなるのか・・・読み込ませて疎通が出来なくなれば、POXにてスイッチ端末の挙動が変わったと考えて良いでしょう。

// テキトウにデバッグ用のをコントローラに読み込ませてみる
# ./pox.py debug-pox
POX 0.1.0 (betta) / Copyright 2011-2013 James McCauley, et al.
// ここまで疎通を確認
INFO:core:POX 0.1.0 (betta) is up.
// ここから挙動が変化
INFO:openflow.of_01:[00-ab-5e-70-a5-00 1] connected
...

・・・ping 止まりました ∩（ ・ω・）∩ 。

この「おおっ」って感じはやってみないと分からないかもしれません。

先日のGNS3でSDNごっこをしようとしていたらどうにもうまく繋がらない。OpenflowのPOXコントローラがどうしても認識されなかったり。GNS3に登録した各Qemu用OpenvSwitchアプライアンスのイメージ自体は同じで、各設定の狂いは生じることは余程の事がないと起こらない。自分のコントローラが駄目という説もあるが、自分のコントローラが駄目な時は、他のアプライアンスも駄目であったりする。1対1とか個別だと問題は無いはずなのですが・・・そういえばインターフェイスの若い方がつながらないってことは出ていない。ということで、

とかやってみる事にする。

$ sudo ifconfig eth0 inet 192.168.0.254/24
$ sudo ifconfig eth1 inet 192.168.1.254/24
$ sudo ifconfig eth2 inet 192.168.2.254/24
$ sudo ifconfig eth3 inet 192.168.3.254/24
$ sudo ifconfig eth4 inet 192.168.4.254/24
$ sudo ifconfig eth5 inet 192.168.5.254/24

$ ping 192.168.0.10
3 packets transmitted, 3 packets received, 0% packet loss
$ ping 192.168.1.10
3 packets transmitted, 3 packets received, 0% packet loss
$ ping 192.168.2.10
3 packets transmitted, 3 packets received, 0% packet loss
$ ping 192.168.3.10
13 packets transmitted, 0 packets received, 100% packet loss
$ ping 192.168.4.10
3 packets transmitted, 3 packets received, 0% packet loss
$ ping 192.168.5.10
10 packets transmitted, 0 packets received, 100% packet loss

・・・どうも、このようなことが起こるようで。思えば律儀にコントローラは末尾の5番を使ってました。さて、アプライアンスの設定が原因かQemuの動作が怪しいのか。動作の怪しさで言えばシリアルコンソールのログオン画面が時と場合により、自動ログインされなかったりとか挙動が若干マチマチではありました・・・こうなるとどれも怪しく感じてしまう。とりあえずGNS3用QemuのNIC数デフォルト値は少なめの方が良さそうですね・・・時間をとられすぎました。

GNS3のQemuマシンは電源を切らないとLANケーブルの再配線ができないのが辛い。

20130718時点のGNS3用アプライアンスのお約束

■ Vyatta 6.6R1
User: vyatta
Pass: vyatta

■ LiSA 2.0.1
User: root
Pass: password

■ Openvswitch 1.2.2 installed on Microcore 4.0
User: tc
Pass:

お察しくださいなパスワードを一応記載

最近、ネットワーク的な事をしたく四苦八苦。良い機械は個人では用意もできないし、周りもどうぞと用意はしてくれない。風の噂で聞くPacketTracerもCisco専用であったり、そもそもCiscoアカデミーに所属しないと頂けない代物で個人でもつのはなかなか難しい。他に仮想的にネットワークを組んで設定等を試せるシミュレータはないものかと探してみたところ、GNS3 (Graphical Network Simulator) なるシミュレータがある模様で・・・早速導入。（実際のところ存在は知ってはいましたが、ネットワーク製品の試験だと結局ios等が必要になるって事でずっと保留していたり）

• GNS3 v0.8.x all-in-one をダウンロード
• Appliances -> Vyatta 6.x Qemu image をダウンロード
• Appliances -> Openvswitch 1.2.x installed on Microcore 4.0 をダウンロード(Qemu用)
• GNS3をインストール(一緒にWireshark/SuperPutty/Qemu等が入る)
• GNS3のQemu仮想マシン設定にダウンロードしたVyattaとOpenvSwitchを読み込ませる

(参照:GNS3+VirtualBox+Vyattaでネットワークのシミュレーション)

なんと、簡単に高機能なソフトウェアルータとSDN環境のシミュレータが簡単に出来上がってしまった・・・これはありがたい。実のところSDN検証用等で自分の家の仮想環境にある程度の大きさのLinuxを複製複製しては役割設定を毎回していたので非効率極まりない+そもそも環境を作るとどこかで躓いていたので非常に助かるところでした。ネットワークインターフェイスを用意してシミュレーション環境を実運用に組み込むことは出来ないけれど、いろいろ試すには十分。凄い時代になったものです。暫くはこちらをメインに色々遊んでみようと思います。

ところでVyattaをCisc○ライクと呼ぶのはどうなのだろう・・・触った感じあまり似ていないと思うのですが。CLIの操作がそれっぽいだけで、構文の雰囲気も、こうかな？って操作も効かないし、どうにも。

emerge: there are no ebuilds built with USE flags to satisfy
 ">=app-admin/eselect-php-0.7.0[apache2?,fpm?]".

 !!! One of the following packages is required to complete your request:
 - app-admin/eselect-php-0.7.1::gentoo (Change USE: +apache2)
 - dev-lang/php-5.4.17::gentoo (Change USE: -apache2)

どないせいと・・・

# USE=apache2 emerge eselect-php
Calculating dependencies... done!
[ebuild     U  ] app-admin/eselect-php-0.7.1 [0.6.2] USE="apache2% -fpm%"
[blocks B      ] <dev-lang/php-5.4.13-r1:5.4 
("<dev-lang/php-5.4.13-r1:5.4" is blocking app-admin/eselect-php-0.7.1)

('A`)ｳﾜｧ...

急ぎメールをお送りします、っと (ｶﾀｶﾀ、ｯﾀｰﾝ

Pstfix/smtpd[11577]: 
NOQUEUE: reject: 
RCPT from xxx.ocn.ne.jp[www.xxx.yyy.zzz]: 
554 5.7.1: 
Relay access denied; from= to= proto=ESMTP helo=<[aaa.bbb.ccc.ddd]>

ファッ！？いつの間にか送信できなくなっていました。いつもローカル配送ばかりでしたので・・・どうやらRecipientアドレスが拒否されたから配送できていないっぽいのですが、SMTP認証を通せば配送できるようには対応していた・・・筈。しかしできなくなっていました。調べてみると設定は問題なく、このような事案 ([SOLVED] relay access denied after postfix 2.10 upgrade) が発生していた模様。微妙に仕様が変わったのだろうか。

変更前：

smtpd_recipient_restrictions = 
permit_mynetworks,
permit_sasl_authenticated,
(略)
reject_unauth_destination

変更後:

smtpd_relay_restrictions = 
permit_mynetworks,
permit_sasl_authenticated,
(略)
reject_unauth_destination

あぁ、Hardenedプロファイルを使用していたため遅かったですが、4月位にアップデートしましたね・・・2.10に。その影響で、どうやらRCPT TO をチェックするsmtpd_recipient_restructions が smtpd_relay_restructions に置き換わった模様。唐突でした…大方、パッケージ更新した時のメッセージ見逃したのでしょう。