9. 自动维护的fdb/arp表

控制中心方案

多播最大的问题是他需要在整个多播组里到处去问, 这很烦, 所以我们想要维护一个控制中心, 这个控制中心负责去回答: 对端mac/宿主机ip的问题

手动维护fdb表

• arp表则负责回答, 如果知道对方的私有ip, 回答对方真实mac地址的问题

• fdb表负责回答, 如果知道对方的mac地址, 回答对方宿主机ip的问题

• 因此实际发生的顺序是先arp拿到对方mac, 接着fdb拿到宿主机ip, 就可以发消息了

bridge fdb append:
00:00:00:00:00:00 dev vxlan0 dst 192.168.8.101  // *
00:00:00:00:00:00 dev vxlan0 dst 192.168.8.102  // *
52:5e:55:00:00:00 dev vxlan0 dst 192.168.8.101
d6:d9:cd:00:00:00 dev vxlan0 dst 192.168.8.102

按照上面的写法里, 如果知道了对方的mac地址, 那么vtep搜索这张表就可以知道对方宿主机ip了, 两个要素都齐了这时候就可以顺利发消息了, 但是你可以看到我们留了两行00:00:00这是一个默认选项, 我们只给出了两个宿主机的ip, 如果有新的ip则还要去第一行第二行的位置去问.

手动维护arp表

fdb表还好说, 因为毕竟一台机器上也才一个vtep需要查表, 但是我们在说arp表的时候可是容器维度的, 每个容器都需要一个arp表, 每个容器都插入一个arp表吗不现实.

Linux提供一种方法, 是让vtep同时负责回答arp响应. 这时候vtep就是我们所说的"控制中心了"所有的arp请求, 你无非是想知道这个私有ip对应的mac地址是什么, 我vtep就可以告诉你. 你不用把你的arp问答搞得到处都是了

动态更新fdb/arp表

以上两种方法仍然存在一定问题, 以vtep代答arp请求来说, 你vtep是怎么知道答案的, 也许你会说, 我可以通过一些自动化工具去维护这张arp脚本, 但说到底这种实现方式并不优雅, 你维护了100个容器的mac地址, 但实际上能用到的最多一两个, 在容器数量很大的情况下, 这种做法也欠妥

Linux提供了另一套办法, 使内核能动态的通知节点要与那个容器通信, 然后你这边的应用程序订阅这些事件. 现在假设内核突然发现某个arp活fdb不存在了, 就会发送事件给程序, 然后程序去内核哪里更新所需要的信息, 这两个事件分别叫l2miss与l3miss, 分别代表:

• l2: 已知mac, 查不到宿主机ip (fdb表失职)

• l3: 已知容器ip, 查不到容器mac (arp表失职)

啥玩意儿啊写的, 没看懂!!

ip monitor all dev vxlan0
[nsid current] miss 10.20.1.3 STALE  <- l3miss

我们举个🌰来说,现在容器A想要ping容器B, 此时因为不知道mac地址因此产生l3miss事件, 这个时候我们需要手动的去添加arp记录了:

ip neigh replace 10.20.1.3 \
   lladddr b2:ee:aa:42:8b:0b \
   dev vxlan0 \
   nud reachable

现在arp已经加上了, 此时因为不知道对方宿主机的ip, 产生了l2miss事件:

[nsid current] miss lladdr b2:ee:aa

然后老样子, 你去手动添加上fdb的记录