SecBlade LB V5 做outbound LLB时，对于没有被ACL匹配的流量如何处理？

那也就是说，我即使是配置了ACL，只是限制了这部分流量必须走这条链路，不影响转发其他没有匹配到的流量对吧？

是的。acl可以理解为只是一种对流量的“优先要求”。对于不匹配的，在没有其他别的配置外，就默认按照调度算法来“一视同仁”。不会因为不匹配acl而丢弃。因此有些链路即使绑定acl，还是会参与那些不匹配acl的流量调度。

还有comware v5和v7的处理思路完全不同。v7的做法是完全是按照LB policy来实现，可以更灵活地对流量进行控制。可以做到不匹配ACL的，丢弃之。

那么问题来了，我一条链路配置的有ACL，当这条链路断开之后，流量没有切换导致中断了，在逻辑链路故障处理中选择的是“断开已有连接”，是不是主动建立新的连接是么？是必须要选择“重定向已有连接”么？

保持已有连接：实服务或者逻辑链路的状态变迁不影响已有会话表项的状态，会话表项将根据老化时间或客户端/服务器的拆链报文而正常删除。 断开已有连接：实服务故障后，对于TCP连接，客户端后续发来的报文将被LB丢弃，并触发LB主动回复RST报文拆链，随后LB会将该会话表项立即清除。对于UDP连接，若LB必须使能ip unreachable enable，则会向客户端发送ICMP目的不可达报文，若LB持续收到客户端继续发来的报文，则LB会持续丢弃这些报文并回复ICMP目的不可达报文，即如果一直有客户端后续报文命中该条UDP会话，则其老化时间将被一直刷新，无法老化。对于ICMP连接，来自客户端的后续报文同样会被LB丢弃，LB也会回应一个ICMP目的不可达报文，并将该会话表项的状态切换至加速老化状态（默认老化时间至10S），如果客户端持续发送后续报文至LB，则该条会话表项永远不老化（常见于客户端设置连续ping场景）。 重定向已有连接：原有实服务故障后，LB将重新调度一个健康的实服务并挂接到该会话中，一旦有后续报文命中该会话，则会被直接重定向至新的实服务处理。如果新的实服务也出现故障，则LB会再次调度一个健康的实服务挂接到该会话中。如果最初调度的实服务恢复，LB将继续根据会话当前所挂接的实服务转发报文。由此可见，重定向已有连接方式不会产生新的会话表项。当后续报文命中表项时，也会正常刷新会话表项的老化时间。 在链路负载均衡和防火墙负载均衡场景中，服务器响应的反向报文是可以命中原有会话的。但如果LB除了负载分担外还执行了NAT操作，由于原有出接口的NAT相关信息与重定向后出接口的NAT信息不一致，所以仍会导致NAT模块检查失败、报文被丢弃、会话被删除。