数据中心中,随着大规模虚拟化和容器化,在最坏的情况下,TOR交换机理论上有可能需要学习全网VM的MAC或FIB表项。因此,如果一个POD内服务器数量较多,MAC或FIB表项有可能成为规格的瓶颈,需要通过合理规划租户虚拟机所在的物理位置,来避免出现超规格的现象。
而在园区中,没有这么大规模的用户接入,主要的限制是为无线漫游用户配置的AC口,以及为控制用户组之间访问需要配置的ACL。
昨天留下的两个问题:
框式交换机的实现,有集中式与分布式两种。
集中式的框式交换机,以Catalyst 9400,Catalyst 9600为代表,交换ASIC在主控引擎上,线卡只有phy芯片,所有转发都需要上主控ASIC引擎。如下图所示:
对于此种情况,框式交换机的VXLAN AC口数量也受到主控交换引擎ASIC的限制。
而以H3C为代表的主流交换机厂商使用分布式设计,架构如下图所示:
图中,Fabric Module可以集成在主控上,也可以通过独立交换网板的形式提供。由于每个线卡上均有以太网交换ASIC,有n个线卡的交换机理论上VXLAN资源数是每ASIC的n倍。
所以,严格地说,只有分布式转发的框式交换机,可以利用这一特点,承担较多的安全组+无线转发。
那么,如果对于没有条件或基于成本考虑,不使用成本较高的高端盒式交换机或框式交换机作为汇聚的情况呢?
我们还有最后一招——无线集中式转发。
回忆我们第19期的文章最后一张图:
如果我们采用集中式转发,是不是等同于将无线用户“乾坤大挪移”到了旁挂在核心的无线控制器上呢?
实际上,由于所有的无线用户无论如何漫游,我们只需要在核心交换机连接无线控制器的物理接口上,为无线用户所在的所有安全组配置VXLAN AC就可以了!也就是说,如果使用2个40G以太网物理口连接无线控制器,在80个安全组的情况下,我们只需要在核心交换机上消耗160个VXLAN AC资源就可以了!
接下来,我们需要解决的是ACL资源的问题。
我们知道,在园区网络实际部署中,绝大多数用户的业务是访问数据中心和园区内部服务器,而园区用户之间互访的业务是非常少的。
因此,我们可以在所有汇聚交换机上配置默认策略为deny any,只有允许互访的业务才在ACL中放行。由于园区用户之间互访业务很少,访问矩阵实际上是稀疏矩阵,这样可以大大节约ACL资源。
当然,这种规避措施,也是有代价的。集中转发会增加无线用户的时延,无线控制器的吞吐量也有可能限制所有无线用户的总带宽。但在绝大多数场景下可以满足客户的需求。
明天,我们将介绍局域网SDN技术的未来发展,敬请期待!