很多年之前部门很多人调去做ovs,领导让我匆忙接手vxlan三层分布式网关项目,当时还没有evpn,对isis做修改同步mac和ip,我做isis的修改,对转发流程稀里糊涂,和杭州的一位大姐姐联调,大姐姐觉得我问题太多了,最后叹了口气对我说你去问一下你们组的老大,我感觉她认为我无可救药了,我一直忘不了这事,从此立志一定要搞明白vxlan的转发流程。
openstack neutron组件也用到了vxlan,还有dvr,在云计算环境到底分布式网关好还是集中式网关好,vxlan对称还是非对称转发好,什么样的控制平面好,要对这些问题得出结论不管怎样先得深刻理解vxlan转发流程。
三层转发就是查路由表转发,云计算环境下一个租户一个vpn,一个vpn对应一个vrf,一个租户很多vxlan,同一vxlan内二层转发,vxlan之间三层转发,而且还有一些vxlan要出公网,分布式网关中有一个网关作为boarder,把云上路由发布出去或者引进外部路由,这个boader主备或者主主多活负载分担。
一个租户一个vpn,简化一下一个租户在openstack neutron上有一个router,这个router就是图中的一个VRF。一个vxlan就是neutron中一个network,有一个vni,一个network只有一个子网,这样跨vxlan转发就是跨了网转发,一个vxlan就是一BD(bridge domain),BD里有MAC转发表,根据MAC做二层转发,BD上有一个bdif接口连接到IP VRF上,流量到这个上去就查路由做三层转发,从其它bdif口出去,就到其它vxlan的BD上了。同时一个BD上还有vxlan tunnel口和vlan口,BD做vlan和vxlan互相转换,一个BD只能有一个vlan id和一个vxlan id,vlan id是本地id,不同节点相同BD上的vxlan id必须相同,vlan id可以不一样。vxlan tunnel是full mesh的,单播报文在BD查MAC找到出口tunnel,tunnel上有源和目的IP,做vxlan encap,然后default vrf出去,vxlan报文来了,解析出vxlan id,根据vxlan id找到BD,在BD里添加vlan tag,然后查MAC转发给本地。对于BUM报文,就是报文目的MAC上BD上没有或者目的MAC比较特殊,vxlan有头端复制或者核心复制,头端复制,由BD复制在所有vxlan tunnel口发一份,vxlan encap的目的IP是远端IP,核心复制就是BD不复制,vxlan encap的目的IP是一个组播IP,由underlay路由器进行复制,underlay得支持组播协议,三层组播协议太复杂了。
VRF中需要路由,BD上需要MAC,假如路由静态配置或者自动生成直连路由,BD上MAC由flooad-learn生成,再加头端复制,vxlan就可以玩转了。但还有个问题,tunnel是怎么建立的,远端IP怎么得来的,图上我把tunnel简化了,而且画在BD上,其实不是这样的,tunnel是所有BD共享的,而且未必需要full-mesh,两个计算节点上的虚拟机没有相同的vni,而且是不同租户的没有三层互通的需求,那么这两台计算节点没必要建立tunnel,BD是共享tunnel的,一个BD一个vni,其实就是vni和tunnel的绑定关系,如果有控制面帮助自动建立tunnel,搞定tunnel和vni的绑定关系,再同步MAC和IP,那么就完美了,下次再写。
左和中间是计算节点,右是网络计算,所有节点都有vxlan encap/decap能力,是VTEP。图中有两个租户,每个租户有两个vxlan,第一个vxlan对应的IP段是192.168.1.0/24,网关是192.168.1.1,子网里有几个虚拟机,第二vxlan对应的IP段是192.168.2.0/24,网关是192.168.2.1。流量跨不跨节点,流量跨不跨vxlan,组合起来就是四种场景,再加流量出外网就是五种场景了。
图中蓝色的线,本节点BD二层转发。
不存在,要跨vxlan一定得有三层转发,三层在网络节点上,那么一定跨节点了。
图中绿色的线,左和中间BD都进行二层转发。
画中黄色的线,左和中间BD二层转发,右三层转发。
画中紫色的线,中间二层转发,右三层转发。
集中式网关的问题就是网关压力太大,所有跨vxlan和出外网的流量都要走网关节点,即使是同一计算节点上两个虚拟机跨vxlan互通流量也要出本计算节点在网关节点上绕了一圈。把网关复制很多份,每个计算节点也放置一份,网关配置一模一样的IP和MAC,网关只对本节点的ARP做应答,对网关的ARP请求不允许从vxlan tunnel口出去,这样同一计算节点跨vxlan就在本计算节点就能搞定了。此时网络节点只保留出外网的功能,网络节点不能再配置网关的MAC和IP,得另外配置一个子网的IP,出外网的流量在计算节点网关做策略重定向到网络节点,这就是neutron vxlan dvr模式。
图中蓝色的线,BD二层转发。
画中红色的线,本节点两个BD二层转发,VRF三层转发。
图中绿色的线,左和中间BD二层转发。
画中黄色的线,2.3和1.5通信,流量从2.3出来,BD2进行二层转发,左节点VRF进行三层转发,到了左BD1,encap BD1的vni转发到中间BD1,再到1.5,流量从1.5回来时,BD1进行二层转发,中间节点VRF进行三层转发,到了中间BD2,encap BD2的vni转发到左BD2,再到2.3。路径不对称,来回encap的vni也不一样。
画中紫色的线,2.5到8.8,出去时2.5到自己的网关进行VRF进行三层转发,路由重定向到网络节点,还从进来的bdif出,再回到的BD2进行vxlan encap,到了网络节点的BD2,再到网络节点VRF进行三层转发,再做NAT出去了,回来了在网络节点做NAT,VRF转发到BD2,BD2到中间节点的BD2,再到2.5,路径不对称,来回encapR vni一样,路由有点复杂。
非对称转发跨节点跨vxlan时流量路径不对称,不对称导致有状态的防火墙会把正常流量丢了,流量统计和QOS等功能不好找地方落地,还有一个问题是vni不对称,流量用的vni是目的vxlan的vni,流量去时和回来时vni不一样,所以出现了l3 vni,每个租户一个l3 vni,跨节点跨vxlan转发用l3 vni,走l3 vni的BD,IP VRF中虚拟机的IP用32位精确匹配,用路由控制去l2 bd还是l3 bd,这下把路径和vni不对称问题都解决了。
图中蓝色的线,BD二层转发。
画中红色的线,本节点两个BD二层转发,VRF三层转发。
图中绿色的线,左和中间BD二层转发。
画中黄色的线,2.3和1.5通信,流量从2.3出来,BD2进行二层转发,左节点VRF进行三层转发,走l3 vni的BD,encap l3 vni转发到中间l3 vni BD,再到VRF进行三层转发,中间BD1进行二层转发到1.5,回来相反,每个节点进行了二层和三层转发,相比非对称转发多了一次三层转发。
画中紫色的线,2.5到8.8,出去时2.5到自己的网关进行VRF进行三层转发,从l3 vni出到网络节点,网络节点VRF进行三层转发,再做NAT出去了,回来了在网络节点做NAT,VRF转发从l3 vni出,到了中间节点的VRF转发回来,路径是对称。
非对称方案VRF中路由不需要32位精确匹配,只要bdif上网关IP配置上就能自动生成路由,再额外一条defaul路由把出外网流量导引到网络节点上去,网络节点上有所有vxlan的BD,还得有vxlan中一个IP地址,和网关不同。问题是BD上MAC超级多,要有本vxlan中所有虚拟机的MAC。左和中间两个BD是二层互通的,两个BD上都有网关,网关IP和MAC一样的,那么BD上学习到的网关MAC到底在bdif上还是tunnel口呢,网关MAC出本节点BD时源mac必须替换掉成本vtep的router mac,目的MAC保持虚拟机的MAC,BD上的网关MAC就在bdif口上,对网关arp请求也不能从tunnel口出去。
对称转发需要配置l3 vni,每个节点上VRF连接l3 vni的bdif口配置的IP和MAC都不相同,这个MAC就是system mac或者说是router mac,每个vtep不同,l3 vni转发时内层mac就用这个mac,ip其实可有可没有,有好理解,一个router mac对应一个IP,路由通告时下一跳就是这个mac,l3 vni转发时是这个IP,目的MAC是这个IP对应的router mac,源MAC是本vtep的router MAC。对称转发要求VRF中要有所有虚拟机的路由,VTEP之间一定要能同步IP,还有一条出外网路由到网络节点。网络节点只要有l3 vni就可以。既然VRF中所有路由都有了,那么跨节点不跨vxlan能不能用l3 vni转发呢,其实可以的,网关开启arp代答,本节点IP不代答,tunnel口抑制arp出去,把所有跨节点流量吸引到网关上去,网关做三层转发,这样BD上MAC表就很小了,只要有网关和本BD上虚拟机MAC就行了。