OpenvSwitch这个东西实在是好,原因无须再表;但名字中带了Switch容易给人一种只能做Switch的误解,近来在做项目遗留了一个问题,这两天有空碰巧思考了一番,并结合之前交换芯片的实现,发现可以比较优雅的予以解决,而不用浪费两条流表,因而记录在此,虽则一个小点,但也足以窥见OpenvSwitch的灵活性。

我们知道,在如下这样流表的条件下:

in_port=1 actions=output:1

从端口1中收到的报文,实际上是不能转发回给1端口的,于是要用IN_PORT这个逻辑来处理,但如果在用OpenvSwitch仿真路由转发的场景中,比如同一个接口上存在多个vlan而采用纯流表仿真的话,比如用如下的流表配置:

table=0,in_port=1,dl_vlan=10,eth_dst=vlanif_10_vmac,actions=write_metadata(vrf 10),goto_table(routing_table 10)

table=10,metadata=10,ip_dst=1.1.1.1,actions=set_field:xx:xx:xx:xx:xx:xx->eth_dst,set_field:xx:xx:xx:xx:xx:xx->eth_src,goto_table(neigh_table 20)

table=20, eth_dst=xx:xx:xx:xx:xx:xx,actions=set_field:4106->vlan_vid,output:1

就会遇到从端口1上来的报文,无法进行跨vlan路由转发发回端口1的情况,并且这种情况下如果用端口1,就需要考虑如果不是从1端口经路由目的地址也是1.1.1.1的情况,这样如果单独为端口1这种做下特殊处理,就会额外增加一条流表,且显得较为怪异。

这时候如果从三层交换机的vlan if(华为系称法)或svi(思科系称法)的角度看,命令rif_mac的报文需要做路由,此时再进行路由转发时,可以认为端口来自于vlan if,因此,对上述pipeline仅需修改一条规则,在命中vlan if mac后,更改in_port_oxm这个字段,就可以很完美地解决这个问题。

table=0,in_port=1,dl_vlan=10,eth_dst=vlan_10_rif_vmac,actions=set_field:vlanif_10_vportid->in_port_oxm, write_metadata(vrf 10),goto_table(routing_table 10)

个人来看,这就是SDN所体现的灵活之处,当然这仅仅是转发侧的灵活性,控制平面也同样是大有可为:)


Comments

comments powered by Disqus