Trema/MyRoutingSwitch(5), Topology Change and Re-route(5)

study

はじめに

これまで、リンクダウンによるトポロジ変化に対して、フローテーブルの修正をして追従して動いてくれることが見えたと思います。今回は、もうちょっと複雑なパターンと特徴的な挙動、トポロジ変化に伴うフロー操作のその他の課題について取り上げます。

リンクダウンに伴うスイッチバック動作

ネットワーク構成とトポロジ変化時の操作
  • Step.1
    • 初期状態はこんな感じで。host1-host3 の間で hop 数を変えながら3つのルートがあります。
    • host1 と host2-6 間で通信を行っているときのフローテーブルを各スイッチにつけてあります。


  • Step.2
    • sw2-sw3 間のリンクを落とします。
    • このときの経路切り替えの動作がちょっとトリッキーです。


送信元側にさかのぼってフローを修正する場合

Step.2 で sw2-sw3 間のリンクが切れたときの host1 → host3 のフローに注目します。

  • [1] host1 は host3 に対してパケットを送る。
    • sw1 はマッチするフローを既に持っているのでそれに従って sw2 にパケットを送る。
  • [2] sw2 はリンクダウンによってマッチするフローが消えている。ここで packet-in が発生する。
  • [3] Controller は packet-in がスイッチ間接続リンクのポートから上がったことがわかるので arp table は変更しない。
  • [4] Controller は host1(sw1)-host3(sw3) の経路を再計算する。
  • [5] Controller は計算した経路の中間スイッチにフローエントリを送信する。
    • sw3 は [2]で packet-in したパケットを host3 へ送出(packet-out)する。
    • この時点で sw1 にあった host1→host3 のパケットを sw1→sw2 へ振っていたエントリが書き換えられます。
  • [6] host1 は host3 へパケットを送信する。再計算した経路にマッチするフローがあるので、sw1-sw4-sw5-sw3 の経路で host3 までパケットが中継される。

リンクダウンしたポイント(sw2)が直接の代替経路を持っているわけではなくて、もっと送信元側にさかのぼらなければ(上の例では sw1 までさかのぼらなければ)代替経路が見つからないケースも当然あります。この場合、

  • パケットがいったん袋小路のほうに入ってきてから packet-in が発生し
  • end-to-end で経路の再計算とフローの書換

という処理が行われます。行き止まりに入ってしまうのでコントローラに預けていったんバック(経路の再計算)してからやり直す、という感じ。これも arp table の情報が endpoint で固定されてていないと上手く動かないケースになります。あと、このケースの場合、袋小路側(sw2) には使わないフロー (host3→host1) が残ってしまいます。フローエントリが age out するようになっていれば気にしないですが、そうでない場合は注意が必要でしょう。

その他の課題

とりあえずリンクダウン発生によってどうフローを制御してやれば良いのか、というのを考えてみました。実際にはまだ問題があると思います。

  • arp table のクリアをしなければいけない場合?
    • 特にスイッチダウンの場合はそうだけど、併せて arp table 内の情報を書き換えなければいけない場合があるはず。スイッチ自体のダウンについてはまだちゃんとテストやれていない…
      • それと、OVS によるテスト環境だと、セキュアチャネル障害のテストが今は難しい。
    • あと、arp entry のエイジアウト時間などとの兼ね合いがある? 手元のテストだけだとこの辺ははっきり見えてないです。
  • リンクが増えることに対する変化。リカバリができていないこと。
    • リンク減ると特定のパスにフローが集中しちゃうのですが、ダウンしたリンクが復旧したあとにフローを元に戻すという処理がないので、トポロジ変化(リンクダウン・リンクアップ)がいろいろあると、結果としてキャパシティが減ってしまう可能性があります。リンクアップ(パスの増加)に対して再計算させる仕掛けとか、うまいことバランシングさせる仕組みが欲しいな…
  • cookie応用?
    • …ここまでさんざんフロー操作の話を見てきて思ったけど、cookie って何か上手いこと使ったらこの辺もうちょっときれいにやれるんじゃないのかと後で気づきました。フローエントリの cookie の使い方が見えていない。
  • プロアクティブ方式と send_flow_mod(:emerg) 応用?
    • エンドポイントに応じてリアクティブにコントロールやる方法はやっぱり処理がめんどい。スケールしにくそう。フローエントリ設定をプロアクティブにやる方式だとこういうのどう考えるんだろう?
    • :emerg オプションとか使うともうちょっと上手いやり方があったりする?

あとは @ttsubo さんからコメントもらった

というところとか。L2/L3 で回そうとする以上 arp なり何なりで場所の把握をしなければいけないのだけど、それとネットワーク内のトポロジ管理や経路制御の話は分けてしまった方が考えやすいというのはあると思う。エンドの管理はエッジに、エッジ間は別途回す。そうなると L2/L3 以外の情報でネットワーク内の経路管理をしてやる(プロアクティブにわかる情報以外の物で回す)ことになるので OpenFlow1.0 の範囲だと難しい。やっぱりそろそろ 1.3 か…。

まとめ

リンクダウン対応についてはいったんこのあたりで終わり。同じようなことをテスト結果を含めて長々と書いてみました。単純にリンク落とすだけなんだけど、それでもいろいろ厄介なことがあって難しいな…。