Trema/MyRoutingSwitch(4), テスト関連メモ

study

引き続き routing switch 周りでいじってる。先週〜今週でいじったことのメモ。

Unknown Unicastの取り扱い

Trema/MyRoutingSwitch(2) にも書いたけど、L2スイッチとして動作する割には Unknown Unicast の動作をイレギュラーな形 (proxy arp) にしてありました。試してみたかったので。ただ、動作として標準的なものを作っておくかと思ったのと、単純な Unknown Unicast Flooding にした方が実装上シンプルになるので、いったん Flooding するように変更してみました。

テストコード

テストコードもらったので、それを元にいっくつかテストを入れています。

  • test with single switch
    • スイッチひとつだけ
    • トポロジ情報がない(他のスイッチとつながっていない、standalone な状況にあるスイッチ、もしくはsingle switch environment)のテスト
  • test with multiple switch
    • スイッチ6個の環境
    • 最短経路検索のテスト
    • フロー情報のチェック(dump_flows)は経路として確定できるところについてだけ書いています。
    • 等コストになる場合(選択可能な経路が複数ある場合)も、テストは作り込めそうだけどまだやれてない。

Unknown Unicastの取り扱いとphostの動作

'trema send_packets' で phost 間のパケット送受信を試しているのだけど、このとき

  • 送信 phost は直接 unicast ipv4 を送信する (ARP Request を生成しない)
  • 受信 phost は受信した unicast ipv4 についてリプライを返さない。(受信カウントする)
  • 受信 phost は arp request に対してリプライを返す。

という動作をしています。なので、テスト実行時の arp_table の学習の仕方が、unknown unicast の取り扱いによってちょっと変わる。それによってテストの作り方もちょっと変わる。

proxy arp で処理する場合
       ipv4 packet         arp request[flood]
 host1 ==========> switch1 ===========> host2
                           arp reply
                           <===========

controller の arp_table が空の状況で host1 が ipv4 packet を送信すると、コントローラ側は宛先がどのポートにいるか知らないのでそのままでは送れません(unknown unicast)。そのため、何かしらの flooding を行って、宛先からの返答を待ちます。返答によって宛先がどこに接続されているかを把握します。

proxy arp を使っている場合、unknown の packet を送ることはあきらめて宛先の位置の確認だけします*1。phost (host2) はコントローラが生成した arp request に応答してくれるので、初期状態で arp_table が空でも送信元・先がどのポートにつながっているかの情報を得られます。(ipv4 packet, arp reply がどのポートに入ったかを arp_table に記録する。)

phost が arp request については reply を返してくれるので片方向 (host1 → host2) のパケット送信で arp_table には送信元・先の情報が載ります。送信元・先の情報が arp_table に乗っている状態で、次に何らかのパケット (ipv4 unicast) が入ってくると、flow_mod してスイッチに flow entry を入れてやることができます。

floodingで処理する場合
       ipv4 packet         ipv4 packet[flood]
 host1 ==========> switch1 ===========> host2

Unknown unicast packet の flooding で処理するようすると、phost(host2) が ipv4 packet に対して応答返さない(受信はカウントする)ので、host2 がどこにいるのかをコントローラは把握できません。コントローラが送信元・先がどこにいるかを把握するには、host1/host2 双方が何らかのパケットを出してコントローラに位置を教える必要があります。

そのため、テストでは逆方向の send_packets も必要になります。

       ipv4 packet         ipv4 packet
 host1 <========== switch1 <========== host2

逆方向にパケットを送ると、送信先(host1)は arp_table に載っているので、host1 宛て (host1 へ outport する) flow entry が設定されます (floodではない)。

まとめ

  • テストを増やしました
    • 書き方は… trema apps にあったものとかを元に作っているのでコピペ成分多め。どう書くべきかというのがはっきりわかった上で書いているわけじゃないのが微妙…。その辺はもうちょっと勉強しないとなあ…
  • phost 周りの動作をまとめました
    • OVS/KVM 環境で実際にやるのと、trema test framework 上でやるのと、動作に違いがあるのでまとめておいた。基本的な話なんだけど、どうも頭が上手く切り替わらないので。
    • phost が arp なしで ipv4 unicast を生成するのはこれはこれで良い。
      • unknown unicast のテストとか一発でできる。
      • 片方向ずつ、動作テストができる。(OVS/KVMによるテスト環境だと、VM間パケット送信で自動的に reply が返ってしまうので、1パケット送信で 2 方向の処理が走って、これが結構面倒。multiple switch なテストでも行き/返り個別に処理を追いかけられる方やりやすい状況がある。)
    • あとは、明示的に phost から arp request を生成する、あるいは phost が ipv4 unicast に対して reply を返す、という動作が指定できるとやりやすいのかなあと思ったりした。

*1:host1/host2 が別なネットワークセグメントにいる場合はこういう処理がまわります。L2 でこういうのを作ったのは、Simple Router とか L3 処理のあるコントローラをいじったりしていたのでそれを引きずっています。