ovn multicast实现分析

ovn fdb实现分析

ovn的fdb实现主要作用于unkown的port,关于unknown port的含义,狭义的理解就是未配置安全策略的port。对应到neutron即没有配置port-security的端口:无安全的虚机port,localnet port等。

fdb学习阶段

报文从unknown的虚机port出来,进入交换机时,ovn会先通过lookup_fdb查询sb的fdb表,如果没有对应的记录,则通过put_fdb记录(逻辑流表):
ovn_put_fdb
port_key表示从哪个tunnel_key的port学习到mac,dp_key表示datapath的tunnel_key:

()[root@ovn-tool-0 /]# ovn-sbctl list fdb
_uuid : 58d385f1-a4a7-4c97-b557-5a5d80cd9b01
dp_key : 1
mac : "06:a7:c2:8a:00:4a"
port_key : 1

这里需要注意一点,从localnet port进入的报文,不会被学习mac地址并记录fdb信息:

commit dd94f1266ca4f3c750bc59c474ea342ef3ff9983 
Author: Numan Siddique
Date: 2021/1/31, 6:25
PM Path: ~/Documents/ezstack/ovn-ovs/ovn/northd/ovn-northd.c

northd: MAC learning: Add logical flows for fdb.
This patch adds the logical flows to do mac learning
for the logical ports whose port security is disabled
with 'unknown' addresses set.

Until now, OVN delivers the unknown destination packets to all
the logical ports with 'unknown' addresses set. With this
mac learning feature, such flooding of packets is avoided once
OVN has learnt the port-to-mac bindings.

Note that we don't learn macs seen on the localnet logical ports.

近期ovn新进patch,支持可以配置参数允许localnet port学习mac:Add option to enable MAC learning on localnet
开放localnet port学习mac,可能会导致网络问题,请谨慎使用。

fdb使用阶段

在ls_in_l2_lkup阶段,如果目的是普通port(有安全组的或者地址已知),根据目的mac它是能明确地outport到对应的port:
known_ports

但是对于目的地址unknown的报文,它会通过get_fdb查询mac对应的端口来确定outport:
ovn_get_fdb

如果没有查到说明fdb还没有学习到目的mac,则该报文会outport给本datapath的mc_unknown,也就会出现出现未知单播报文被多播。
mc_unknown解释:所有unknown ports的列表,mc即multicast缩写。

mc_unknown实现分析

northd处理

ovn-northd在组装逻辑流表的过程中,如果ls中存在unknown的port,则会将其添加进mc_unknown表项里:


mc_unknown的tunnel_key是32769,对应16进制0x8001:

sb数据库的Multicast_Group表可查:

()[root@ovn-tool-0 /]# ovn-sbctl list multicast_group
_uuid : 515d57c0-980b-46da-a7ff-acb95772cf17
datapath : d1fdf01e-e9a2-42a2-be19-76edaf6f00c7
name : _MC_unknown
ports : [464ac60d-5b00-43da-8363-873a3d2959c0, 5c6f0418-17f3-4766-adc7-dd6489f4af5e, 9c4f88fe-99a0-485c-a83c-4efe6bfec26d]
tunnel_key : 32769

ovn-controller处理

ovn-controller会监听Multicast_Group表的变化,并进行相应的处理:

openflow流表根据reg15=0x8001(进制转换32769)匹配mc_unknown,然后output给所有的mc_unknown ports,再进行resubmit:

mc_unknown问题修复

要解决未知单播报文被多播造成的网络问题,那么就是尽量减少mc_unknown里的port数目。
限制在vlan网络下只添加localnet port即可,这样未知单播报文默认也就从localnet port出去,且实际应用场景中单个chassis只会有一个localnet port。所以最终的效果就是,这种单播报文只会从单个localnet port出去,能够避免多播造成的影响。

- Added limited support for logical switches with multiple localnet ports.
The feature requires that no chassis has two or more physical networks
with localnet ports that belong to the same logical switch mapped. Routing
between the ports to be implemented by fabric.

本修改可能存在的问题:如果目的地址是unknown port的mac一直未在fdb里注册,那么就有可能导致该port收不到报文。

mc_flood实现分析

northd处理

该mc存在于内部网络switch中,所有的lsp都会加入mc_flood里。主要是用于处理ip组播,目的地址为组播mac的报文。

以太网定义的组播mac,第40bit为1:

ovn-controller处理

ovn-controller解析逻辑流表中的mcast方式如下,会将eth.mcast转换成eth.dst[40]为1表示组播

mc_flood_l2实现分析

存在于连接了路由器的switch中。区别于mc_flood,除了type是router的其它lsp都会加入mc_flood_l2里。

个人分析,欢迎指正,若转载请注明出处!