wiki:TipAndDoc/network/macvlan

Version 10 (modified by mitty, 7 years ago) (diff)

--

  1. macvlan vs Linux Bridge
    1. bridging macvlan
  2. nesting macvlan

  • macvlan/macvtap
  • ​twitter:mittyorz/256673272354181121 前後から始まったやりとり 
    mittyorz: LXCは「lxc.network.type=macvlan lxc.network.macvlan.mode=bridge」のようにconfigに書くことで、linux bridgeをあらかじめ用意しなくてもブリッジ接続してくれるぞ。
mittyorz: 参考: http://www.linuxcertif.com/man/5/lxc.conf/ Linux Certif - Man lxc.conf(5) qemu/kvmも1.0からかな、macvlan/macvtap使えるようになったし、Linux bridgeと共存していくのかなぁ
mittyorz: ぐぐってたら @syuu1228 先生の資料が引っかかった http://www.nic.ad.jp/ja/materials/iw/2011/proceedings/s09/s09-02.pdf 仮想化環境における  パケットフォワーディング
_syuu1228: やぁやぁ RT @mittyorz: ぐぐってたら @syuu1228 先生の資料が引っかかった http://www.nic.ad.jp/ja/materials/iw/2011/proceedings/s09/s09-02.pdf 仮想化環境における  パケットフォワーディング
mittyorz: あー、ゲスト/ホスト間の通信が出来ないのか。地味に面倒だな…。これはkvmでの例だけど、lxcでも同じく出来ないようだ http://t.co/StS7TiGu macvtap でつないだ kvm ゲストとホスト間の通信 - TenForwardの日記
mittyorz: @_syuu1228 @syuu1228 どもども。macvlan/macvtapいまいち理解せずkvm/qemuで使ってたんですが、lxcでも使えないか？と思ってググってて、「結局macvlav/vtapってなんやねん」とさらにググってたらたどり着きましたー。
mittyorz: とはいえ、ここに書いてあることも理解できているのかと言われると、かなり怪しい…。というか他のも読まないと何とも、かなぁ
mittyorz: ホスト/ゲスト間が通信できなくなるのはどういう理由なんだろう
_syuu1228: @mittyorz @syuu1228 KVMで使おうとして後から機能追加（macvtap）してますけど、元々LXC向けの機能（macvlan）っすね
mittyorz: @_syuu1228 @syuu1228 ああー、そうなんですか。なるほど…。macvlanが先だったんですね。違いがよく分からずにいたので、今更ながら色々読んでます。
mittyorz: この辺が詳しそう？ http://virt.kernelnewbies.org/MacVTap MacVTap - Linux Virtualization Wiki
mittyorz: 何らかの方法でホスト/ゲスト間で通信できるように細工したような覚えが。どうやったんだっけかな
_syuu1228: @mittyorz 元々、カーネルの中で完結した機構で、1つのNICに複数のMACを振る仕組みをLXCの為に作ったのがmacvlan。KVMのvNICってそもそもユーザランドで動いてたからtap+bridge使ってたんやけど、vhostnetでカーネルで動くようにもなったので（続
_syuu1228: @mittyorz より短いパス（macvlanのように）でブリッジ出来るようにしようとしたんだけど、あくまでtapのインタフェースは維持したかったっぽくて（ユーザランドから設定とかする為？よくわからない）その為にmacvlanにtapのインタフェースくっつけたのがmacvtap
_syuu1228: @mittyorz ちなみにVEPAとか書いてあるのはスルーしていいと思います。僕らも調べてIW2011で解説したし、IW2012でも触れるかもしれないけど、現状まず使わないので
mittyorz: @_syuu1228 なるほど。わざわざ経緯の説明ありがとうございます！tapのインタフェースくっつけたのはやはり既存のユーザランドアプリケーションとかから状態を見たり設定変更したりしたかったからですかねぇ…。若干車輪の再発明っぽい感じではありますが、利便性を取ったのかな
_syuu1228: @mittyorz 「vhost-netもqemu-kvmも変えなくていい」というのは大きな動機になりそうですが、ずっと前からここは疑問に思ってます。
mittyorz: @_syuu1228 なるほど。(ハードウェア)switch側の対応が必要となるとちょっと使えなさそうですね。しかしデフォルトがVEPAになっているように書かれていますが、利用者側からすると混乱しそうな気もしますね…。
_syuu1228: @mittyorz あれー本当だてっきりbridgeだと思ってたんだけど…でもhairpin_modeが使えるってところだけが違いのはずなので（ちょっと自信なし）、これがデフォルトオフなのか、或いは対応スイッチの下でしかhairpinしないのか、って所なのではないかと妄想します
mittyorz: @_syuu1228 ふむー。そうなるとちょっと使ってみよう、という場合でもデフォルトのVEPAにしておいて大丈夫なのかな…。やってみるか……。
mittyorz: qemu/kvmでも書いてある通りホスト/ゲスト間で通信できなかった。ただ、 https://twitter.com/mittyorz/status/256674071159382018 で見落としていたけど、ホスト/ゲスト間用に、別にmacvlanを作ってしまえば問題ないようだ。でもそこまでするなら今までもbr0とかでもいい気もする。
mittyorz: あとは性能次第かなぁ
_syuu1228: @mittyorz すげー単純にいうと、同一ホスト間のブリッジングでも一旦スイッチへパケット送ってスイッチで転送先判断させようという仕組み＝VEPAなので（同一ホストならパケット戻ってくる＝ヘアピン）、もしデフォルトでヘアピンが実施されるなら普通のスイッチ下では通信エラーするはず
mittyorz: @_syuu1228 それは同じVMM上に無いノード間の通信は問題なく通信できるように見えて、同じVMM上に存在するVM同士で通信しようとするととたんにはまったりしないですかね…。問題への気付きにくさが増しているような。
mittyorz: VEPAモードにしてみたが、VMノードと、ハードウェア的に別のノードとの間の通信は問題なかった。もちろんホスト/ゲスト間は通信できない。
_syuu1228: @mittyorz そうなる気がするけど何が起きるか厳密に考えてみた事が無いので、もしかしたら予想と違う現象になるかも。でもまさかそういう設定に最初からなってるはずはないと思うんだけどねぇ…
_syuu1228: @mittyorz 多分このあたりは @m_asama せんせーも詳しいと思うので、と人に振ってみる
mittyorz: virt-managerでVM作る時に、NICをmacvtapにしてsource modeをdefaultにしたら作成に失敗する…ｗ いったんVEPAにしてから、後でDefaultにしようとしても、applyを押下した瞬間にVEPAに戻る。なんじゃこりゃ。
mittyorz: プルダウンの順番がDefault->VEPAだから、選択出来ないdefaultの代わりにVEPAになっている感がする。virsh editで 'default'ってしたらどうなるんだろう
mittyorz: 「error: internal error Unkown mode has been specified」ふむん…
mittyorz: lxcコンテナA,B間で、ホストとは通信できる必要がない通信をしたい時に、まず思い浮かんだのが、物理NICとは接続されてないbridgeを用意して、それに対してA,Bを接続すればいいや、と思ったのだけれど、macvlanがあるのを思い出して調べてたらだいぶ話が膨らんだなぁ
mittyorz: macvlan使う場合も、ホスト側は通信できる必要無い(IPアドレスとか付与しない)けど、ホスト側でmacvlanデバイスを作ってからLXCコンテナ側でそこに接続する必要があるのかな。外(ホスト側)にデバイスとして見えている必要は無い(むしろ見えない方が良い)のだけれど。
mittyorz: 外に見える、というのはifconfig -aとかすると見えてしまうアレ。
mittyorz: @_syuu1228 だめですが、かなりアドホックな回避策はあるようですね。アドホックすぎてちょっといやな感じですが。 ref: https://twitter.com/mittyorz/status/256680074403790848
m_asama: @_syuu1228 @mittyorz なんでデフォルト vepa なんでしょうね。ちょっとコード眺めたかんじでは bridge と比較してそんなに vepa が軽量になってるとは思えないし。あ、もしかしたら大量に VM ぶら下げた時に差が出てくるのかも。
mittyorz: @m_asama @_syuu1228 パケット送り先の判断をスイッチにオフロード出来るから、ということなのですかね…。対応しているスイッチが少ない状況ではあまり嬉しくないように思えますけれど。
syuu1228: @mittyorz @m_asama VEPAモードじゃなくてbridgeモードでもホストと通信できないんでしたっけ？
syuu1228: @mittyorz @m_asama なんとなくだけど、その状況ってVEPAモードで対応スイッチがあればヘアピンされて通信出来るような気がしなくもないのだけれど。どうなんだろ。
m_asama: @syuu1228 @mittyorz いや、 bridge ならいけると思ってましたけど、試してはないです。
syuu1228: @m_asama @mittyorz ちょっと理解し難いですね。むしろmacvtapの位置付けがVEPA対応用な感じなんだろうか？？
syuu1228: @m_asama @mittyorz あるいはアレかな、VEPAモードでヘアピンオフだとルータとはスイッチを経由して喋れるけど、同一ノードの別VMやホストとは通信出来ない状態になるとかで、それを意図してるのかな
m_asama: @syuu1228 @mittyorz macvlan/macvtap は zero copy のためのものなんじゃないですかね。 legacy bridge や Open vSwitch では zero copy 実現不可能とおもわれるので。
syuu1228: @m_asama @mittyorz だと思うんだけども、ならなんでこういうデフォルト値になってんだろなー…と
m_asama: @syuu1228 @mittyorz それは謎w たぶん最初は vepa しかなくて後から bridge 追加したので最初からあった vepa がデフォルトになってるとかそんな理由なのかも。
mittyorz: @m_asama @syuu1228 試した限りではbridgeでホスト/ゲスト間の通信は出来ませんねー。
m_asama: @mittyorz @syuu1228 まじですか…。なにが違うんでしょうね…。ちょうど今日 macvlan/macvtap 読もうと思ってたのでなんかわかったらご報告します。
m_asama: @mittyorz @syuu1228 あー、なんかゲスト間通信できるようにしたのを bridge と言ってるみたいすね。よく考えたら送信はそのまま NIC から出すし、受信はすぐさま rx_handler に奪われるんだからホストと通信できるわけ無かったですね…。すんません…。

macvlan vs Linux Bridge

  • macvlanとbridgeは両立出来ない
  1. root@Microknoppix:~# brctl addbr br0
  2. root@Microknoppix:~# brctl addif br0 eth0
  3. root@Microknoppix:~# ip link add dev macvlan0 link eth0 address 00:16:3e:xx:yy:zz type macvlan mode bridge 
    RTNETLINK answers: Device or resource busy
  1. root@Microknoppix:~# brctl delif br0 eth0
  2. root@Microknoppix:~# ip link add dev macvlan0 link eth0 address 00:16:3e:xx:yy:zz type macvlan mode bridge
  3. root@Microknoppix:~# brctl addif br0 eth0 
    device eth0 is already a member of a bridge; can't enslave it to bridge br0.
  4. root@Microknoppix:~# brctl show 
    bridge name     bridge id               STP enabled     interfaces
br0             8000.000000000000       no
  • root@Microknoppix:~# ip link 
    6: macvlan0@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
    link/ether 00:16:3e:xx:yy:zz brd ff:ff:ff:ff:ff:ff

bridging macvlan

  • macvlanをブリッジすることは可能
    • macvlan0 at eth0
    • macvlan1 at eth1
  • mitty@vlan-gw:~$ ifconfig | grep addr 
    br-gw     Link encap:Ethernet  HWaddr 00:16:3e:18:8b:a0
          inet6 addr: fe80::216:3eff:fe18:8ba0/64 Scope:Link
eth0      Link encap:Ethernet  HWaddr 00:16:3e:3d:4f:c9
          inet6 addr: fe80::216:3eff:fe3d:4fc9/64 Scope:Link
eth1      Link encap:Ethernet  HWaddr 00:16:3e:3d:4f:ca
          inet6 addr: fe80::216:3eff:fe3d:4fca/64 Scope:Link
macvlan0  Link encap:Ethernet  HWaddr 00:16:3e:18:8b:a0
          inet6 addr: fe80::216:3eff:fe18:8ba0/64 Scope:Link
macvlan1  Link encap:Ethernet  HWaddr 00:16:3e:32:30:c9
          inet6 addr: fe80::216:3eff:fe32:30c9/64 Scope:Link
  • mitty@vlan-gw:~$ brctl show 
    bridge name     bridge id               STP enabled     interfaces
br-gw           8000.00163e188ba0       no              macvlan0
                                                        macvlan1
  • ただし、このmacvlanのブリッジは期待通りには動かない(eth0<->eth1の、NICを超えての疎通不可)
  • ARP request/replyは上流側の物理デバイス(eth0)に対しては正しく送信・受信されているが、replyがmacvlan0に正しく届かないため下流側のmacvlan1まで回ってこない模様

nesting macvlan

  • macvlan/macvtapを用いてホストと接続したゲスト環境内において、Linux Bridgeあるいはmacvlanをさらに使用するとゲストの外からのパケットを受け取れない
    • 検証していないが、コンテナをmacvlan/macvtapでネストしても同じだと思われる
  • macvlan/macvtapは、Linux Bridgeとは異なり自身に設定されているMAC Address以外のイーサネットフレームを受け取ることができないのではないかと思われる

Attachments (1)

Download all attachments as: .zip