ScreenOS的多链路负载均衡功能

network

ScreenOS的多链路负载均衡功能

随着互联网的不断发展，现代企业越来越多的依靠互联网来部署自己的关键业务；不管是为了保证企业互联网业务的可靠性还是为了进一步扩展企业的互联网接入带宽，很多企业都采用了租用多条互联网接入链路的方式。那么如何将流量在多条链路上进行负载均衡呢？Juniper防火墙的ScreenOS系统提供几种不同的手段来完成这种功能。

ECMP

ScreenOS支持ECMP (Equal Cost Multi-Path /等值多路径) 功能，即支持将流量在多条等cost值的路径上进行负载分担。

假如用户有两条链路接入互联网，则可设置两条静态默认路由 (ScreenO中静态路由cost值默认都为1) 分别指向两个不同的下一跳地址，并打开ECMP功能，同时指定需要负载均衡的链路条数；另外可在防火墙连接两条链路的接口上都打开NAT功能，这样所有流量都会在两条链路上进行负载分担并转换成公网IP去往互联网。

或通过命令行 ” set max-ecmp-routes 2 ” 来启用ECMP功能，由于ScreenOS最多支持四条链路的负载均衡，因此还可使用” set max-ecmp-routes 3 ” 或” set max-ecmp-routes 4 ”。

由于防火墙是状态检测设备，因此流量会基于会话以轮询的方式进行负载均衡；举个例子，假如共有10000个会话，如果在两条链路上打开ECMP功能的话，则其中约5000个会话从链路一出去，约5000个会话会从链路二出去；ECMP功能的好处是配置简单，但其缺点也是显而异见的，即它不能智能地依据路由远近去分配流量，而是绝对平均地以轮询的方式分配所有会话到不同链路，这样有可能导致某些流量不能从最佳路由出去；比如用户同时租用了电信和网通的两条链路，ECMP打开的后果可能会导致去往电信区域的数据从网通链路出去，而去往网通区域的数据从电信链路出去。因此ECMP功能最适用于租用同一个运营商若干条链路的用户，或租用若干个互联互通情况较好的运营商链路的用户。

另外ECMP还有一个缺点是跟某些应用不兼容；比如某些多连接的应用，且该应用还要求每个连接都来自同一个IP地址，而打开ECMP的情况下，很可能同一个用户发起的两个连接中的一个从链路一出去，第二个连接从链路儿出去，导致这些应用运行不正常，最常见的例子是工商银行的网上银行业务，中国移动网上营业厅以及联众的网络游戏系统。解决方案是打开ScreenOS的nat stick功能“set dip sticky”，即保证来自同一个源IP的不同会话始终被翻译成同一个IP地址,这样就可解决应用兼容性问题。

基于目标地址的路由

为了使流量能够选择最佳路由，最直接的手段就是通过基于目标地址路由的选路方式，比如将所有去往某运营商域内的流量手工的指到到通往该运营商的下一跳路由器上，再另外用一条默认路由将其余流量指向到另外一条链路；如果是电信和网通的两条链路我习惯将具体路由指向网通路由器，默认路由指向电信路由器，原因是因为网通的路由条目较少而电信的资源较多。

比较常见的基于目标地址路由来实现负载均衡的场合是大学的校园网，由于大学校园网一般都有若干条链路接入internet，比如一条连接电信，一条连接网通，一条连接教育科研网(Cernet)，而这三个网络之间的互联互通做得并不好，比如从电信链路出去访问Cernet的资源，会发现延时很大，速度很慢。这时使用基于目标地址的路由可以最大程度保证流量选择最佳路由出去。

基于源地址的路由 (PBR)

实现流量复杂均衡还有一个手段就是采用源地址路由的方式。一般的三层转发设备都是通过查询路由表 (存放基于目标地址的路由) 来实现路由选路，而源地址路由(PBR)方式提供了另外一个手段，即防火墙会先查询某预先定义的特殊路由表(PBR 路由表)来进行路由查询，当PBR路由表中没有命中的路由条目时再去查询默认的路由表；也就是说，PBR路由表的优先级比默认路由表高。

而PBR路由表中存放的路由都不是按照目标地址来进行选路的，而是基于别的一些因素；比如源地址，源端口，目标地址，目标端口以及IP包头的COS字段这5者的任意组合。因此用户可以利用该特性按照内网用户的源地址属性进行选录。

举个例子，加入用户租用了两条链路，一条带宽为2M，另一条带宽为10M，则可把内网的用户划分为12个网段，通过PBR将2个网段从2M链路送出去，另外10个网段从10M链路送出去以实现静态的负载均衡。

入方向的负载均衡

前面讲的三种方式其实都是出方向的负载均衡，即连接由内向外发起，适合大多数企业的环境；但可能有的用户，比如提供互联网服务的企业，需要同时实现入方向的负载均衡，即要求当互联网用户发起请求内网的服务器数据的连接时，选择就近的链路接入。

熟悉运营商路由策略的人都了解，每个运营商都只发布自己的域内路由；因此当用户连接的目标地址属于运营商A的地址范围的时候，该连接一定会进入运营商A的路由域并传输到达最终目的地址。

因此对于入方向的流量，其实并没有什么好的负载均衡手段，除非你有自己的独立于运营商的地址范围(自己的AS域)并通过BGP路由协议将自己的地址通告给所有的peer运管商，但这种条件很难达成。

幸好互联网的寻址系统还包括有一个DNS协议，如果DNS服务器能够将某服务器的域名解析成若干个分别对应不同运营商的地址，则连接就可以在连接这些运营商的链路上平均分摊以实现负载均衡；这个功能实现起来很简单，只需在DNS服务器上添加多条A记录即可(www.163.com就是这么做的)；但由于DNS服务器不会检查链路故障，因此当某条链路断掉后，DNS服务器依然会将域名随机的解析到该链路所属运营商的地址上，因此可能导致这部分流量服务不可用。

商业化的负载均衡设备(比如F5的Linkcontroller和Radware的LinkProof)都内置一个小DNS服务器，该DNS服务器可监控链路状态的变化，当发现某条链路故障时，就不会将域名解析到该链路所属运营商的地址，以实现服务的高可用性。当然，这类设备的价格要比防火墙贵很多很多。