靜态路由實作負載均衡和高可用

該公司及其合作方現有網絡及筆者的設計如下所示：

分析：由于希望實作線路都正常時負載均衡，讀者的第一反應肯定是用HSRP來搞定，因為HSRP除了HA(高可用)功能之外，還有一個功能，就是負載均衡。但是，仔細再想想，HSRP的負載均衡功能在這裡可能并不好用，因為兩個客戶的網絡裡面都隻有一台機器（應用伺服器）用到HSRP，而HSRP的負載均衡需要在多組伺服器裡面/或多個VLAN裡面做（實際上就是讓多組伺服器使用多個路由器/多層交換機作為網關，進而實作負載在多個路由器/多層交換機分擔）。那怎麼辦呢？筆者選擇的是配置多條靜态路由來實作負載在兩條線路上分擔。具體配置下面會講。當然，還是會使用HSRP的，因為它的高可用（HA）嘛。

仔細看看圖，還會看到一個比較麻煩的問題，兩個網絡的内網位址範圍是一樣的，都是172.17.1.0/24，而且該公司不希望改變内網IP位址，因為有些程式綁定了IP，如果換IP的話，牽涉的變動比較多。筆者決定使用NAT來克服這個困難。

下面将具體的配置：

首先，筆者打算在不使用NAT的情況下，配置并調試好HSRP,負載均衡和容錯。

為此，筆者在R1和R3上各配置了一個loopback，來模拟客戶A和客戶B的應用伺服器。

由于HSRP的配置比較簡單，下面列出各個路由器上HSRP的配置，請注意其中的HSRP

接口track功能。

R1#sh run int f1/0

interface FastEthernet1/0

 ip address 172.17.1.2 255.255.255.0

 standby 10 ip 172.17.1.1

 standby 10 preempt

 standby 10 track Serial0/0 20  <--- 如果S0/0 down了，該HSRP執行個體的優先級會降低20，

                                                         由于R1和R3使用默優先級（100），而R2，R4配置的優先

                                                         級為90。是以，一旦線路一down了，HSRP活動路由器自

                                                          動會切換到R2和R4。

end

R2#sh run int f1/0

 ip address 172.17.1.3 255.255.255.0

 standby 10 priority 90

 standby 10 track Serial0/0 20

R3#sh run int f1/0

 standby 20 ip 172.17.1.1

 standby 20 preempt

 standby 20 track Serial0/0 20

R4#sh run int f1/0

 standby 20 priority 90

驗證HSRP的指令：show standby。該指令的輸出，就不列出來了。

配好了HSRP，接着就改配loopback和靜态路由了。筆者選擇用靜态路由來實作負載分擔。可能讀者會想，為什麼不用動态協定來實作負載均衡呢，比如用EIGRP就可以實作啊。确實可以用諸如EIGRP之類的路由協定來實作。不過可能需要調整某些接口的bandwidth，delay和variance 變量值。還是靜态路由比較簡單吧。分析一下網絡就可以發現，隻需要在R1上配置到達172.17.252.0/24子網的下一跳路由器為R3和R1，在R2上配置到達172.17.252.0/24子網的下一跳路由器為R4，在R3上配置到達172.17.251.0/24子網的下一跳路由器為R1和R4，在R4上配置到達172.17.252.0/24子網的下一跳路由器為R2，并且每條靜态路由設定同樣的metric，比如用預設值，就實作了兩條線路負載分擔。（讀者請想想，為什麼在R2和R4上不需要配置為相應的目标子網配置兩個下一跳路由器？）

下面是兩條線路都正常時，各個路由器上的接口和路由：

R1#sh ip int bri

Interface                      IP-Address      OK?   Method   Status                Proocol

Serial0/0                      10.0.0.1           YES    manual     up                     up

FastEthernet1/0          172.17.1.2        YES   manual     up                     up

Loopback0                  172.17.251.1    YES   manual     up                     up

R1#sh ip route

......

     172.17.0.0/24 is subnetted, 3 subnets

S       172.17.252.0 [1/0] via 172.17.1.3  <-- next hop R2

                               [1/0] via 10.0.0.2     <--  next hop R3

C       172.17.251.0 is directly connected, Loopback0

C       172.17.1.0 is directly connected, FastEthernet1/0

     10.0.0.0/30 is subnetted, 1 subnets

C       10.0.0.0 is directly connected, Serial0/0

R2#sh ip route

S       172.17.252.0 [1/0] via 10.0.1.2

S       172.17.251.0 [1/0] via 172.17.1.2

C       10.0.1.0 is directly connected, Serial0/0

R3#sh ip route

C       172.17.252.0 is directly connected, Loopback0

S       172.17.251.0 [1/0] via 172.17.1.3   <-- next hop R4

                              [1/0] via 10.0.0.1        <-- next hop R1

R4#sh ip int bri

Interface                  IP-Address      OK? Method Status                Protocol

Serial0/0                  10.0.1.2        YES manual up                    up

FastEthernet1/0            172.17.1.3      YES manual up                    up

R4#sh ip route

S       172.17.252.0 [1/0] via 172.17.1.2

S       172.17.251.0 [1/0] via 10.0.1.1

配置好了，我們來驗證一下。我們在R1上使用擴充ping，并且記錄路由：

R1#ping

Protocol [ip]:

Target IP address: 172.17.252.1

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: 172.17.251.1

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]: R

Number of hops [ 9 ]:

Loose, Strict, Record, Timestamp, Verbose[RV]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Record route:

   (172.17.1.2)

   (10.0.1.1)

   (172.17.1.3)

   (172.17.252.1)

   (10.0.1.2)

   (172.17.251.1) <*>

   (0.0.0.0)

 End of list

Reply to request 1 (56 ms).  Received packet has options

 Total option bytes= 40, padded length=40

 Record route:

   (10.0.0.1)

   (10.0.0.2)

Reply to request 2 (208 ms).  Received packet has options

可以看出，兩條線路都正常時，負載跑在兩條線路上。

下面我們看看線路一失效後各個路由器上的接口和路由：

Serial0/0                  10.0.0.1        YES manual administratively down down

FastEthernet1/0            172.17.1.2      YES manual up                    up

Loopback0                  172.17.251.1    YES manual up                    up

S       172.17.252.0 [1/0] via 172.17.1.3

R3#sh ip int bri

Serial0/0                  10.0.0.2        YES manual up                    down

Loopback0                  172.17.252.1    YES manual up                    up

S       172.17.251.0 [1/0] via 172.17.1.3

我們再次在R1上執行擴充ping，并且記錄路由：

Reply to request 0 (172 ms).

Reply to request 1 (208 ms).  

Reply to request 2 (128 ms).  

Success rate is 100 percent (3/3), round-trip min/avg/max = 128/169/208 ms

R1#

可以看出，一條線路失敗後，所有負載都跑在正常的線路上。

至此，我們已經搞定了在不使用NAT情況下的高可用性，負載分擔和容錯。

接下來，我們配置NAT。

NAT的配置比較簡單，我們把客戶A的網絡NAT為172.17.251.0/24位址，客戶B的網絡NAT為172.17.252.0/24位址，且假定客戶A和客戶B的應用伺服器的IP都是172.17.1.100，配置如下所示：

R1#sh run

interface Serial0/0

 ip address 10.0.0.1 255.255.255.252

 ip nat outside

!

 ip nat inside

ip nat inside source static 172.17.1.100 172.17.251.100

R2#sh run

 ip address 10.0.1.1 255.255.255.252

R3#sh run

 ip address 10.0.0.2 255.255.255.252

ip nat inside source static 172.17.1.100 172.17.252.100

R4#sh run

 ip address 10.0.1.2 255.255.255.252

然後，在客戶A的應用伺服器上（筆者在設計階段，用的是模拟器，故用模拟的路由器代替客戶A和B的應用伺服器）執行擴充ping，并記錄路由：

ClientA#ping

Target IP address: 172.17.252.100

Source address or interface:

Loose, Strict, Record, Timestamp, Verbose[none]:

Reply to request 0 (292 ms). 

   (172.17.1.100)

   <*>

Reply to request 1 (224 ms). 

   (172.17.1.100) <*>

Reply to request 2 (240 ms).  Received packet has

可以看出，我們在路由器上配置了NAT後，兩條線路都正常時，負載跑在兩條線路上。

至于一條線路失效後的情況，也跟前面未配置NAT時的情況一樣，跟我們預期的一緻。

筆者配置了NAT後，在測試的時候，先用了traceroute指令，執行了很多次，每次都跑的同一條線路，筆者還以為加入NAT後，靜态路由負載均衡不起作用了。後來，用擴充ping的時候，才得到預期的效果。

關于NAT，筆者不打算說什麼，cisco的網站上有很經典的配置文檔。附件就是一份比較不錯的文檔。

還需要指出的一點是，由于該設計到兩個公司的網絡，在幾個路由器上都配置了嚴格的ACL，具體配置，就不列出來了。

筆者沒有仔細區分“負載均衡”和“負載分擔”，總覺得有的時候用負載分擔比用負載均衡準确。

<a href="http://down.51cto.com/data/2349171" target="_blank">附件：http://down.51cto.com/data/2349171</a>

本文轉自zkjian517 51CTO部落格，原文連結:http://blog.51cto.com/zoukejian/57610