先回答上一期的遗留问题：
交换机的TCAM资源是有限的， 一般在500K以内。我们刚才提到，实现微分段需要在TCAM内查找，这会不会大量消耗交换机的TCAM资源，影响其他业务呢？
那么，我们需要理解一下，在分布式任意播网关模式下，TCAM的使用方式：
让我们回顾这篇：《局域网SDN硬核技术内幕 20 亢龙有悔——规格与限制(上)》。这篇专题中有一个重要的结论是：
TOR交换机在做分布式任意播网关的情况下，需要学习该交换机配置的租户内，所有的虚拟机的FIB表项。
由于在虚拟化/容器化环境中，VM或容器的位置是分散的，因此，实际上大部分FIB表项的key，并不是CIDR，而是具有完整的目的IP的主机路由。(IPv4下为32位主机路由)。我们只需要为其增加微分段的Group ID值，就可以在不消耗额外的TCAM资源的前提下，实现从IP地址查找其Group ID的功能。
好了，在前几期专题中，我们提到了，微分段能让SDN网络“知微，知彰”，但我们也发现，基于微分段的访问控制，是刚性的访问控制，是无状态的。
而我们期望的访问控制却是能跟踪传输层连接状态的柔性控制——
如图，frontend向db发起TCP SYN，三次握手后，连接能够正常建立，双向数据包都可以放通。
反之，db向frontend发起TCP SYN，这种行为将被访问控制阻断：
显然，交换机的ACL是难以实现这一功能的，即使通过可编程的转发平面实现所谓的“自反ACL”，交换机也无法跟踪TCP的状态机，与基于状态的防火墙安全性相差甚远。
因此，我们需要将状态防火墙与微分段结合，才能让容器网络除了“知微，知彰”之外，还可以“知柔，知刚”。
让我们回顾一下上期提到的基于group的访问矩阵：
以传统的web-app-db三层架构为例，我们期望的互访关系如下表：
但如果以TCP的发起/响应关系论，实际上，我们期望的是下表：
如图，红字部分体现了从App向Web的发起访问，从db向app的发起访问均将被拒绝。
显然，我们要区分从App向Web返回的回程流量，和App向Web发起访问的请求，就必须将Web和App之间的流量重新定向到防火墙——
我们的访问矩阵应该改成这样：
这样一来，交换机可以将匹配微分段的数据包重新定向到状态检测防火墙上。状态检测防火墙跟踪Web-App，App-DB之间的TCP状态机，判定是否放行数据包。以Web与App为例，当连接没有建立的时候，任何数据包都会被丢弃，除了web向app发起的TCP SYN以外。
当防火墙完成对三次握手的跟踪，会话进入session established状态，回程数据包才被放通。
显然，对于容器网络，这种柔性控制，才是我们最需要的符合NetworkPolicy定义的实现。
我们小结一下：
在硬件交换机作为容器网络的Overlay网关时，通过微分段实现不同标签的pod隔离，通过微分段重定向到防火墙进行pod之间有状态的访问控制，就能够让容器SDN网络 “知微，知彰，知柔，知刚”。
