F5 BIG-IP网络概述
TMOS是一个全代理的体系结构
Ø 流量必须穿越BIG-IP设备以获得TMOS的优化效果
部署方式
路由模式
Ø 也被称作串联模式
Ø 真实服务器放在BIG-IP之后的一个内部网络
Ø 真实服务器的网关需要指向（或者最终通过）BIG-IP
Ø Virtual Server需在发布在外网网段，客户端才能通过BIG-IP访问到后台服务器
路由模式的优势
Ø 网络拓扑简单明了
Ø 易于排错
Ø BIG-IP可以为网络提供安全防护
a) 可以起到防火墙的功能
b) 可以使用Packet Filter做细致的访问控制
路由模式的不足
Ø 可能需要在网络中创建一个新的VLAN
Ø 可能需要修改服务器的默认网关
Ø 可能需要在BIG-IP上做额外的设置才能直接访问后台服务器
SNAT（安全网络地址转换）模式
Ø 也被称做单臂模式
Ø 可以让BIG-IP设备加入到一个已经部署好的网络中，而不需要改变该网络的网络
结构和地址规划
Ø BIG-IP替换客户的源IP为BIG-IP设备的接口IP
SNAT将客户端的地址转换成BIG-IP上的接口地址
SNAT模式的优势
Ø 不用修改网络和服务器配置
Ø 便于进行简单的测试
Ø 需要直接访问服务器时，不需要对BIG-IP进行额外的配置
SNAT模式的不足
Ø 服务器上看到的源地址都是BIG-IP的地址
• 排错的难度相对较高
Ø 外部网段可以直接访问到服务器，降低了安全性
BIG-IP可以将客户端的源地址写到HTTP包头里，以便后台服务器读取：
Ø 插入一个 x-forward 字段在HTTP包头里(RFC 标准格式)
Ø 客户通过iRules定义的HTTP包头字段
SNAT AutoMap
SNAT AutoMap功能按照以下优先顺序从可用的self IP地址中选择转换地址：
l 出口VLAN上的Floating self IP
l 其他VLAN上的Floating self IP
l 出口VLAN上的Non-floating self IP
l 其他VLAN上的Non-floating self IP
------F5 BIG-IP LTM负载均衡----------
1.1 LTM VS工作模式
F5 BIG-IP LTM的内部对于数据包的处理方式，即是VS的工作类型，存在有四种工作模式,分别针对四层数据处理和七层数据处理；
四层处理模式有：Forwarding(IP)
Performance(Layer 4)
七层处理模式有：Standard
performance（HTTP）
1.1.1 Standard
（首先与client建立连接，再与Pool member建立连接）
·默认工作工作在全代理模式，客户端和服务器端的TCP连接完全独立，BIG-IP维持两个不同的连接。
·在三次握手结束后，BIG-IP按照负载均衡算法选择Pool Member
·客户端和服务器端的TCP参数由TMOS和双方分别协商；
·默认情况下，以客户端源IP与后台建立连接；在打开SNAT的情况下用SNAT地址和后台建立连接。
·Standard vs的端口永远对外开放，无论后台是否有服务器在工作。
TCP Profile
HTTP Profile
1.1.2 性能HTTP
·（首先与Pool member建立连接，再与客户端建立）
· performance HTTP VS仅用于HTTP协议，使用Fast http profile，这是一个TCP、HTTP和oneconnect profile的组合，主要用于加快Http连接速度和减少后台Http server的连接数；
· 只缓存用于分析包头的数据，没有会话保持功能，不能处理SSL，HTTPS；
· BIG-IP通过到Pool Member的TCP连接建立一个空闲的服务器端Flow；
· 当有client请求来时，通过负载均衡算法选择了此服务器，如果发现服务器端Flow是空闲的，则BIG-IP标识其为占用，并发送客户端请求到选定的服务器；
• 如发现服务器端Flow非空闲 的，则BIGIP与选定的服务器建立一个新的TCP连接，并发送客户端请求到选定的服务器。这样做的目的是为了高效利用现有TCP连接，减少和后台服务器之间的连接数；
• 默认开启SNAT AutoMap，在服务器端收到的TCP连接请求都是来自于LTM
1.1.3 Performance L4模式
· Performance L4 VS基于包到包处理连接，只负责客户端连接的分配和转发，默认不改变TCP连接中的任何参数。
· 客户端和服务器自行协商TCP传输参数。
· Perforamce Layer 4 VS上只有4层的iRules可以使用（意思是这模式下，iRules只能改TCP，改不了http、https等）
· 默认状态下，TCP新建连接的第一个包必须是SYN包，如果是其他的数据报比如ACK、RST等如果不在连接表中，则全部丢弃。
· 利用epva（enhance Packet velocity Acceleration）硬件加速模式，所以叫性能L4模式
Performance VS Type使用限制
1.1.4 Forwarding（IP）=路由模式
·只能使用Fast L4 Profile，translate-address 和translate-port翻译默认为Disable；
· 按照连接处理，类似路由器，但不完全一样，在Fast L4 Profile中开启Loose Initial和Loose Close之后更为接近路由工作模式；
· 所有穿过forwarding YS的连接都将产生连接表
· 没有Pool Member，转发根据目标地址查找本地路由表完成
· 可以使用基于4层的iRules，比如做SNAT
· 无法利用ePVA
Virtual Server 执行优先级（从高到低）
指定IP地址和指定端口
10.0.33.199:80
指定IP地址和全端口
10.0.33.199:*
IP网段和指定端口
10.0.33.0:433 netmask 255.255.255.0
IP网段和全端口
10.0.33.0:* netmask 255.255.255.0
全零网段和指定端口
0.0.0.0:80 netmask 0.0.0.0
全零网段和全端口
0.0.0.0:* netmask 0.0.0.0
数据包处理优先级（从高到低）
连接表中存在的连接
Packet filter 规则
Virtual server
SNAT
NAT
Self-IP
丢弃
SYN Flood攻击防护
• Standard VS模式具有天然的防攻击能力
• 在遇到SYN Flood攻击时，会导致系统连接表过大
• BIGIP提供SYN Check功能，通过设置System-SYN Check Activation Threshold作为 全局阈值，BIGIP会监控所有TCP open-half连接数量，在其达到设定阈值时，系统会启用全局的SYN Cookie防护，避免建立过多连接
• 由于全代理架构的原因，大部分的网络层 攻击都无法通过Standard模式的VS
SYN Cookie
• 正常情况下客户端连接和服务器端连接是1:1的关系
• TMM在第一次收到客户端Syn包时，并不建立连接表
• TMM的Syn Ack回应通过算法回应给客 户端Syn，并期待客户端回应的值
• TMM对客户端ACK进行计算，确认是真 实客户端，再和后台服务器建立连接
• 在高端平台可以实现硬件的Syn Cookie计算，低端平台都是通过软件实现SynCookie计算
• Syn Cookie工作模式下，只有成功建立连接TCP请求才转发到后台
1.2 负载均衡策略
BIG-IP LTM进行四层负载均衡的最小元素为TCP连接，所有分配策略均以TCP连接为最小单位，而在七层负载均衡中，最小的元素为每一个完整的交易数据报包，如一个HTTP请求，因此以交易为最小单位进行分配。
负载分配策略主要包含以下几种：
·静态负载均衡算法：轮询，比率，优先权
·动态负载均衡算法：最少连接数，最快响应速度，观察方法，预测法，动态性能分配。
·可编程控制的负载均衡策略：通过编程控制应用流量的导向。
1.2.1.a 静态负载均衡算法;轮询
轮询算法下，以每个客户端新建连接为单位，客户端连接轮流分配到后台的服务器上。
1.2.1.b 比率算法：比率算法
比率算法下，以每个客户端新建连接为单位，将客户端请求按照比率分配到后台的服务器上
1.2.1.c 优先权算法
在正常情况下，所有的客户端请求全部发送到属于高优先级组的member上；当最高优先级群组中的健康的服务器数量小于预定值时，BIG-IP LTM才将请求发送给次优先级的服务器组。
1.2.2.a 动态负载均衡算法：最少连接数
最小连接数为最常用的负载均衡算法之一，在后台服务器处理能力均等的情况下，使用最小的连接数可以得到最为平衡的负载均衡效果。（但是BIG-IP 要维护一张并发表，上面有各个服务器的并发参数）
1.2.2.b 动态负载均衡算法：动态性能分配
前提；BIG-IP知道服务器的CPU使用率（通过健康检查）
动态性能分配通常用于一些服务器资源敏感应用，如集中计算、视频点播等。动态算法是通过BIG-IP上的健康检查来检测服务器的资源占用率，新的请求被分配到资源占用最少的服务器。
1.3 如何选择合适的负载均衡策略
在大部分的应用场景中，都采用最小连接算法。如果系统的每秒新建连接数非常高，如果还是采用最小连接数，由于算法在计算时候不可能实时的统计后台服务器的连接数，且是有时间间隔的去进行统计。在这种情况下，可能采用轮询算法可以更为有效的实现负载均衡。
------F5 BIG-IP LTM会话保持----------
连接和会话的区别：
会话的概念要广泛一些，简单的说，一个用户登录后，则产生一个session。而这个会话是由多次连接完成。BIG-IP LTM将一个会话里的多次连接认为是同一个用户发起的，是为同一个用户服务的。
BIG-IP LTM的概念中，一个session通常就是会话保持表中的一条记录对应的所有连接。每个命中到这条记录的连接都是属于同一个session的。
2.1 为什么需要会话保持
会话保持是负载均衡设备的一种机制，用于识别客户端与服务器之间交互过程的关连性，在进行负载均衡对的同时还保证一系列相关联的访问请求会保持分配到同一台服务器上。
针对不同的业务场景需要不同的会话保持配置，并不是所有业务系统都需要会话保持性。以HTTP电子商务应用为例，
在在线应用系统中需要进行用户身份，一个客户与服务器经常经过好几次的交互过程才能完成一比较交易。由于这几次交互过程是密切相关的，服务器在进行这些交互过程才能完成一笔交易。由于这几次交互过程是密切相关的，服务器在进行这些交互过程的某一个交互步骤时，往往需要了解上一次交互过程的处理结果，或者上几步的交互过程结果。这就要求所有这些相关的交互过程由一台服务器完成，而不能被负载均衡器分散到不同的服务器上，此时需要响应的会话保持策略来保证相关的请求始终被负载到后端的一台服务器上。
2.2 常见的会话保持
<1>源地址会话保持（source persistence）
<2>Cookie会话保持
HTTP Cookie insert（插入）
HTTP Cookie passive（被动）
HTTP Cookie Rewrite（重写）
Cookie Hash
<3>SSL ID会话保持
<4>可编程控制的会话保持
将会话保持的特性的提取
将特征与后台服务器相对应
2.2.1 源地址会话保持
将一个源地址认为是一个用户，凡是同一个源地址发过来的连接，则认为是同一个用户发起的多个请求。根据会话保持策略，将这些连接/请求都转发到同一个服务器上。（BIG-IP LTM会维护一张“源地址会话保持表”）
在一般TCP应用中，会选择按目标地址的会话保持。
name：命名规范source_addr_超时时间
match across services：当多个vs需要共享会话保持表时需要勾选
timeout：超时时间默认为180s，按需配置即可
mask：可以配置针对一个网段的地址执行源地址会话保持，默认为单个地址
override connection limit：勾选后当该业务配置了连接上限时，到达上限后会话保持表内的客户端仍能新建连接。
2.2.2 Cookie会话保持
关于HTTP Cookie和Session ID，以下面一个典型的HTTP请求流程
Cookie有效的改进了HTTP协议的无状态性，使原本无状态的HTTP协议变成有状态的应用协议。
Cookie的内容包括：名字，值，过期时间，路径和域。
Expiration：cookie分为session cookie和永久cookie。如为session cookie，客户关闭浏览器后，cookie失效。如为永久cookie,可以对cookie定义失效时间。
系统默认勾选Session Cookie。
若设置了过期时间，浏览器就会把cookie保存到硬盘上。
Cookie Name:可以自己定义cookie 名称，如未定义，则默认为BIGipServer+POOLname。
2.2.2.a HTTP Cookie insert（插入）
（服务器端并不写入Cookie，HTTP响应不带有cookie，所有cookie信息只存在负载均衡设备上）
2.2.2.b TTP Cookie passive（被动）
（服务器写入cookie，HTTP响应里将带有更新的会话保持cookie）
2.2.2.c HTTP Cookie Rewrite（重写）
（进入服务器，服务器创建空白cookie，HTTP回复《带有空白cookie》返回BIG-IP应用负载设备）
2.2.3 SSL ID会话保持（冷门）
在用户基于SSL访问系统环境里，当SSL对话首次建立时，用户与服务器进行首次信息交换：
·交换机安全证书
·商议加密和压缩方法
·为每条对话建立session ID
1
2
3
4
------F5 BIG-IP LTM健康检查----------
3.健康检查
定义：一个健康检查（Monitor）就是一个测试（test）
·特定的应用程序
·一个预期的回复
·在一定时间内
所有BIG-IP 共同特点：
·间隔：每个检查的时间间隔
·超时时间；这个时间在BIG-IP 标记Node不可用之前返回成功的健康检查结果。
F5 BIG-IP LTM可以使用符合Monitors，所以可使用多重健康检查：
·可以使用全部或部分的健康检查结果来标记成员的状态
3.1.健康检查有以下项目
BIGIP预置的Monitor类型可分为以下三大类：
1、Simple Monitor：发送一个特定协议包，等待回应。如：Gateway ICMP和TCP Half Open。
2、ECV：Extended Content Verification，使用特定协议向检查对象发送一段查询内容，等待从检查对象返回的内容，如果检查到正确的返回内容，则健康检查成功，否则失败。如：Http、Https、TCP。
3、EAV：External Application Verification ，通过访问指定的应用确认检查对象的健康状况。如接收到正确的回应则健康检查成功。如：FTP、IMAP、LDAP、MSSWL、MySQL、NNTP、Oracle、POP3、RADIUS、Real Server等。
用户还可以自定义EAV Monitor。
《1》基于icmp的健康检查；
《2》基于TCP端口的健康检查；
《3》基于UDP端口的健康检查；
《4》基于应用协议的健康健康；
1
2
3
4
3.1.1 基于icmp的健康检查
原理：简单的使用ping去探测，只要服务器有回应，则认为服务器正常工作；
（基于icmp的健康检查属于最基本的健康检查方式）
1
2
3.1.2 基于TCP端口的健康检查
原理：TCP健康检查直接向member的服务器端口发起TCP连接建立请求，连接建立成功即表示服务器的服务在正常工作。
在频繁检查的情况下，健康检查的流量可能导致一些比较“脆弱”的应用系统产生故障。采用TCP half open的方式，或者采用基于代理的健康检查；
1
2
3.1.3 基于UDP端口的健康检查
原理：大多数的udp应用特点是在是收到错误的请求时，没有任何响应。但UDP协议还是设计了在端口未开放时，默认系统将会回应一个Icmp unreachable数据包，以通知客户端连接错误。（只能检查端口情况，并不能代表真实的业务情况）
1
3.1.4 基于应用协议的健康健康
以HTPP协议为例，基于HTTP协议的健康检查过程如下：（负荷较大，几乎浮现业务）
《1》BIG-IP LTM发起一个HTTP请求到服务器，请求特定资源
《2》服务器进行回应；
《3》BIG-IP LTM在返回的内容中查找一个关键字，如果存在该关键字，则认为Web服务器正常工作。
1
2
3
4
3.2 关联健康检查
在真实的应用中，经常还可能存在有关连性应用。比如应用A是否能正常对外提供服务，还取决于它的下级服务应用B是否能给A提供需要的数据，而此时应用B不是在负载均衡的控制范围之内。
3.3 Monitor状态报告
·状态基于健康检查响应及对象层次结构
虚拟服务virtural server 状态受POOL状态影响
pool状态受pool members的状态影响
一个pool的member受这个node的服务状态的影响
·当健康检查失败会发生什么？
·如果没有得到检查结果，超时时间未到
-开始怀疑这个成员member
-没有新连接到这个成员member
-现有连接被维持
·在达到了超时时间前有一个成功的检查结果
新连接发送到member
·如果达到超时时间健康检查失败
从pool中移除member
现有连接清除
1
2
3
4
5
6
7
8
9
10
11
12
13
14
3.4 Pool失败机制
Fallback Host -- 最后备份的server（适用于HTTP和HTTPS profile应用）
·当pool members 成员低于活动成员设定（？？？？回HTTP 重定向(http 302) 到客户端）？？？）
·Fallback host server设置是没有健康监控的（备份server）
Priority Group Activation激活低优先组
1
2
3
4
5
------F5 BIG-IP LTM应用优化----------
4.BIG-IP LTM应用负载优化技术
主要用于提高和优化下面以下三种流量：
《1》TCP应用
《2》UDP应用
《3》HTTP应用（HTTP由于广泛应用，单独设置为一分支）
4.1 TCP应用：（列出常用profile）
TCP Clinet-side profile
目标：提高用户体验
TCP Server-Side profile
目标：服务器压力卸载
F5已经内置了LAN、WAN和CELL优化的TCP profile配置。通过调整TCP profile多达70个选项；
通常情况下建议：
Clinet side：推荐mptcp-mobile-optimized profile 配置模板
Server side：优先推荐tcp-wan-optimized profile
除非特别了解TCP的工作原理，否则不要调整idle timeout以外的任何参数
默认tcp profile所设置idle timeout值为300秒
TCP 优化配置
• 优先使用 v11.6 及以上版本
• 客户端侧优先使用继承 mptcp-mobile-optimized profile 模板
• 服务器端侧优先使用继承 tcp-wan-optimized profile 模板
• Buffer Size 不适应过大或过小，依网络参数基于某基准线再微调
• 开启 Delay Window Control
• 关闭 TCP Segmentation Offloading (TSO)
• 关闭 TCP Progressive Buffer Management (Auto-Tuning)
• Initial Receive Window Size 和 Initial Congestion Window Size 设置为 16
4.1.1 HTTP 压缩
F5 BIG-IP LTM采用业界标准gzip、deflate压缩算法
高端平台内置有硬件压缩芯片，可达到Gbps级的实时数据压缩处理
通常情况下对文本型内容可实现80%以上的压缩率
Compress还需要后端server 关闭Compress功能
4.1.2 RAM Cache
Web Acceleration
4.1.3 oneconnect --TCP连接复用
实现连接聚合以降低服务器的TCP的连接总数，减少建立和关闭连接的消耗和延迟。
工作范围：
《1》前提使用VS Standard模式；
《2》oneconnect profile不是必须和HTTP Profile共用，也可以用于其他应用协议；
《3》但应用其他应用协议时须使用iRules编程来调用oneconnect
1
2
3
4
4.2 Fast L4 Profile
在需要BIGIP高转发性能的TCP应用场景中，可建立Fastl4 profile，用于Performance L4type的VS。
name：命名规范fastl4_超时时间
idle timeout：超时时间默认为300s，按需配置即可
PVA Offload Dynamic： PVA加速开关，默认开启，f5会启用PVA芯片处理流量，提高传输效率。但这部分流量不进入tmm进程，会导致在故障排错时tcpdump抓包不全，建议在故障排错时关闭。
Loose Initiation和Close：默认关闭，f5接收某个客户端的第一个tcp数据包必须是syn包，否则拒绝，当出现非syn包需要经过f5时请同时开启这两个选项（比如当服务器网关指到f5，f5需要针对服务器直连管理流量开启此策略）
压缩，缓存，连接复用开启关闭的场景
前提是使用VS Standard模式
压缩：一般情况下无需开启，但如果客户端和数据中心之间距离远，延迟大的业务开启压缩。而且可以根据客户端的RTT，开启不同级别压缩。某些情况下，后端服务器开启压缩，导致无法重写response内容，F5要利用脚本关闭服务器端压缩。
缓存：一般情况下无需开启，但如果站点的图片为动态内容，会严重影响APP及DB的性能，导致页面打开速度慢时，我们开启RAM Cache。注意如果站点存在动态登录验证码，我们建议关闭特定URL的RAM Cache功能。
连接复用：一般情况下无需开启，但如果该站点前端部署了CDN或连接复用的代理设备。
这个时候建议开启OneConnect Mask 255.255.255.255，否则会产生登陆时提示校验码失败、需要反复登陆的情况。
------F5 BIG-IP iRules介绍----------
5.1什么是iRules：
集成到TMOS架构的编程语言；
基于工业标准的Tool Command；
拦截、检查，修改，引导及跟踪进站和出站的应用流量；
1
2
3
5.2 VS和iRules关系
iRules的处理必须依赖于VS对流量的接收；
通过事件触发机制，iRules可以控制流量在VS内部处理的整个过程
1
2
F5 BIG-IP outbound配置
------outbound Traffic链路负载分析----------
1.1 传统出口ISP选路思路：
等价路由——>选网关——>使用对应公网IP做SNAT
1.2 注意事项：
《1》掌握运营商线路状况及IP和网关；
《2》了解希望想要的outbound策略：
a 用户访问公网ISP1资源时，选择ISP1出口
b 用户访问公网ISP2资源时，选择ISP2出口
c 用户访问公网非ISP1-ISP2资源时，随机选择出口
d 两条出口链路间互为冗余备份
e 是否有邮件服务器或其他需要单独绑定出口或NAT ip的客户端
《3》基于目的地址做链路选择的话，则前提需要有全球Geolocation地址库。
a F5与第三方地址库 neustar（Quova）合作，定期更新地址库信息，需要手动进行地址库更新；
b BIG-IP设备不支持自动更新库，需要到官网登录账号后，选择BIG-IP后下载；
c 演示在LTM如何更新Geolocation地址库及查询：
（1）将官网下载的ip-geolocation-v2-2.0.0-20201005.468.0.zip传入LTM内（这里以/tmp目录为例）
（2）解压文件：#unzip ip-geolocation-v2-2.0.0-20201005.468.0.zip
（3）安装rpm包以便更新：#geoip_update_date -f + 解压后的三个文件名，轮流安装；
V12版本后安装后的目录在/shared/GeoIP/v2，V12版本前的在/shared/GeoIP
（4）查询IP：
#cd
#cd /share/Geoip/v2，目录下 #geoip_lookup -f /shared/GeoIP/v2/F5GeoIPOrg.dat +要查询的IP
F5 Outbound配置步骤
• 1、创建出向负载池
出向负载池中的Pool Member为ISP提供的网关地址。我们将为不同的ISP创建不同的Pool。
Local TrafficàPool中创建一个新的池，该pool中，电信出口为主用，联通出口为备用。
Name：pool_ct
Health Monitor：gateway_icmp
Priority Group Activation：选择Less Than，
Available Members填写1，意思为少于1个可用成员时，启用备用组member
New Members中，填写电信与联通网关地址，service Port为*All Services
电信网关priority设置为10，联通网关priority设置为5，Priority高的优先；
由于此Pool中电信网关优先级较高，流量命中此Pool时会优先选择电信网关；当电信网关故障，主用成员数量少于1，启用备用成员，即联通网关，保证出向流量的连续性。
同理，创建pool_cnc，该pool中，联通网关优先级为10，为主用网关；电信网关优先级为5，为备用网关。
• 2、Gateway Pool Monitor优化
在outbound场景中，建议使用transparent monitor去探测远端站点，比默认的gateway icmp
monitor更能精确探测链路的可用性。
Type：选择继承gateway_icmp
Transparent：选择yes
Alias Address：填写公网的可ping地址将monitor关联到网关pool中，健康检查的方式
为通过网关pool中的member作为下一跳，去探测alias address的可用性。alias address建议选用稳定的公网地址，如运营商网关、DNS地址、有公信力的网站IP等。由于频繁的ICMP包可能会被拦截，也可选用类似于TCP Half Open的探测方式。
建议创建多个可探测的网站地址的transparent monitor，同时关联出口pool，并设置可用性需求为最少一个monitor探测成功。
• 3、创建出向选路策略iRule
Local TrafficàiRule中创建一个新的iRule，此iRule将绑定在
出向VS上。
when CLIENT_ACCEPTED {
#当有流量到达时，命中该事件
switch -glob [whereis [IP::local_addr] isp] {
#使用geo ip数据库判断数据包的目的地址所属运营商
“chinanet” -
“china telecom” {
#如果为电信，则分配到电信池中
pool pool_ct
}
“unicom” -
“china united” {
#如果为联通，则分配到联通池中
pool pool_cnc
}
default { pool pool_default_gateway }
#没有匹配电信或联通的流量分配到默认出口池中
}
}
• 4、创建出向SNAT pool
基于目的地址的出向选路iRule完成后，我们需要在选择不同ISP时将出向流量的源地址NAT为相应ISP上的公网IP地址。因此配置出向SNAT Pool，分别建立电信snat pool与联通snat pool，在Member List中添加此ISP的公网IP地址，当用户公网IP地址较少时，一般建议使用浮动地址（Floating IP）作为出向公网IP地址，如用户公网IP地址充足时，可使用多个公网IP作为NAT地址。
• 5、创建出向SNAT策略iRule
SNAT Pool创建完毕后，通过iRules来指明选择不同ISP时，对应不同的SNAT Pool。
when LB_SELECTED {
#当发生负载选择时，命中该事件
if { [IP::addr [LB::server addr] equals “58.17.128.1”] } {
#如果选择的member为联通网关，使用snat_cnc池中地址做nat
snatpool snat_cnc
} elseif { [IP::addr [LB::server addr] equals “219.149.192.1”] } {
#如果选择的member为电信网关，使用snat_ct池中地址做nat
snatpool snat_ct
} else {
#如果选择的member为非电信联通网关，使用自动匹配地址做nat
snat automap
}
}
• 6、创建出向virtual server
F5默认为All Deny的策略，需为出向流量创建一个可接受所有流量的全0 VS。
Local TrafficàVirtual Servers中创建一个新的Virtual Server。
Name：填写vs名称
Type：选择Performance Layer4，
Destination：选择类型为network，
Address与Mask均填写0.0.0.0
Service Port：选择* All Ports
Protocol：选择*All Protocols
Vlan and Tunnel Traffic：选择为
enable on 内部vlan
*Vlan and Tunnel Traffic如非特殊情况
请务必选择enable在内网vlan中，不
要enable all vlan。
如选择enable all vlan有可能导致外部
访问进来的流量造成环路。
在创建VS时，将之前创建的两个irule关联到VS上。
点击Finish完成出方向负载均衡virtual server配置
互联网业务发布
• 安装前信息收集
使用VS进行业务发布：
Step 1 创建pool
Health Monitor：选择业务对应的健康检查方式
Load Balancing Method：选择业务适用的负载均衡方式
New Members：添加内网服务器ip与端口，如内网已有LTM，则此处为LTM上发布的VS地址。
F5部署时一般建议应用交付流量不要穿越防火墙设备（逻辑安全区域）。
Step 2 创建Virtual Server
Type：出口区域业务发布如果不需要7层策略，一般选用Performance Layer4
Destination：业务发布地址
Service Port：业务发布端口
Protocol：选择业务的4层协议
VLAN and Tunnel Traffic：选择允许访问业务流量vlan，如只允许公网来源访问，选用外
网vlan；如允许所有vlan访问，保持默认Source Address Translation：在链路出口区域
部署的F5在业务发布时，一般不需要进行原地转换，视实际情况选用。
Default Pool：选择刚刚创建的内网业务pool
Default Persistence Profile：选用合适的会话保持方式
使用NAT进行业务发布：创建NAT(optional)
NAT Address：外网地址
Origin Address：内网地址
Traffic Group：如果有多个流量组，可选择对应的流量组，如果没有保持默认即可
VLAN/Tunnel Traffic：选择可访问NAT Address的来源VLAN
————————————————
版权声明：本文为CSDN博主「Clearyat」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_43445237/article/details/128197827
