新一轮科技革命，正在重塑全球经济结构，全球正在进入以信息产业为主导的经济发展期。针对传统安全架构遇到的挑战，F5借助强大的全栈安全服务引擎，推出了SSLO即SSL可视化与智能编排解决方案。今天就来分享F5 SSLO的一些部署实践经验。
我们在部署SSLO的时候，L7安全设备池需要会话保持，来保证Client请求始终发送到同一台L7安全设备，以实现连接的完整性。但默认情况下，SSLO的图形向导配置中没有配置会话保持的地方，那我们应该怎么来实现SSLO的会话保持呢？这里就要运用到BIGIP的会话保持功能。
当我们在Service中添加两个WAF设备后，会自动创建4个以SSLOS_xxx命名的VS（分别负责TCP/UDP的收发流量），以及一个命名的SSLOS_xxx的Pool。
这时我们清空AWAF Pool的连接记录，在SSLO的Interception Rule模块中创建测试VS（192.168.21.42）然后在同一Client上进行反复链接测试VS，可以发现AWAF Pool中两台设备都会分配链接请求。
这里有一个要注意的点，在默认情况下，SSLO是没有配置安全池的会话保持；但是要修改SSLO相关配置，需要SSLO中打开配置更新限制。
但是当我们又会发现不管关联哪种类型的Persistence Profile，AWAF Pool的会话保持依旧没有生效。这又是为什么呢？这时候我们需要好好想一想是哪个环节有问题。我们需要先明白我们是要需要进行AWAF Pool的会话保持，而我们上面配置的却是后段Sever Pool的会话保持。当梳理清楚这个业务逻辑之后，就可以对症下药了；前面提到过SSLO添加service后会自动生成4个负责收发流量的VS，如果我们这时候进入发送流量的Internal类型的VS中，可以看到，在默认情况下，并没有关联persistence profile。
这时关联好我们需要的会话保持方式（VS必须先关联http profile，SSLO默认配置下不会关联）保存后，我们再次进行链接测试，观察AWAF Pool链接状态发现会话保持成功实现。
另外我们还要注意，UDP的转发VS也需要进行关联Persistence Profile，确保UDP的会话保持也能实现。
除此之外，在多有安全池的场景下，每个池自动生成VS都需要进行配置。