はじめに
仮想ブリッジを試してみたので、メモ。
構成
実験1
namespaceを新たに2つ作り、initネームスペースにあるbridgeを利用して双方向通信(ping)を行う。
# bridgeの用意
ip link add name br0 type bridge
ip addr add 192.168.2.254/24 dev br0
ip link set br0 up
# ns0の用意
ip netns add ns0
ip link add name veth0a type veth peer veth0b netns ns0
ip link set veth0a up
ip netns exec ns0 ip link set veth0b up
ip netns exec ns0 ip addr add 192.168.2.1/24 dev veth0b
ip link set veth0a master br0
# ns1の用意
ip netns add ns1
ip link add name veth1a type veth peer veth1b netns ns0
ip link set veth1a up
ip netns exec ns1 ip link set veth1b up
ip netns exec ns0 ip addr add 192.168.2.3/24 dev veth1b
ip link set veth1a master br0
# ns1に入る
ip netns exec ns1 bash
# ns0のveth0bへ通信
ping -c 1 192.168.2.1 -I veth1b
# 上記のpingの前に、tcpdump -iを5箇所(br0, veth{0,1}{a,b})で走らせておくと、全てで見られる。私の場合は、5個のターミナルウィンドウを開いて確認した。
# ex: tcpdump -i veth0a -n 'arp or icmp'
なお、理由は理解していないが、今だとbr0からns0やns1へはアクセスできない。
実験2
割り当てられたマシンが存在しないIPアドレス(ただし、サブネット内のアドレス)を指定してns0からpingを行い、arpリクエストがveth1bへと伝播する様子を確認する
# ns0にて
ping 192.168.2.3 -I veth0b
これにより、veth1bにまで、arpが届いた。
tcpdumpの出力
ARP, Request who-has 192.168.2.3 tell 192.168.2.1, length 28
wiresharkの出力
なお、このL2ヘッダの送信元のMACアドレスはveth0bのMACアドレス(自動で生成されたもののはず)
2: veth0b@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 42:0e:2b:ed:71:58 brd ff:ff:ff:ff:ff:ff link-netnsid 0
忘れていたが、arpリクエストのボディには、SenderのMACアドレスとIPアドレス(これはどうして必要なんだろうか)、TargetのMACアドレス(これが0以外に設定されるときはいつなんだろうか)とIPアドレスが含まれる。