一次菜鸟的多ADSL负载均衡尝试失败经历

独孤九贱

1、测试环境

1. 我的主机(192.168.0.68)-------(eth0:192.168.0.1)Linux(eth1:NULL)---------交换机
   
2. 交换机上同时接了以下两台机器：
   
3. --------PPPOE server(88.88.88.252)
   
4. --------Host(88.88.88.44)

复制代码

2、配置：
我的主机网关指向192.168.0.1
Linux上不手动设路由，做一条伪装，来源是任意地址，绑定在ppp+上边，如下：
Chain POSTROUTING (policy ACCEPT 47 packets, 8402 bytes)
pkts bytes target     prot opt in     out     source               destination
  819 49111 MASQUERADE  all  --  *      ppp+    0.0.0.0/0            0.0.0.0/0
  
PPPOE Server上不手动设路由
Host ：route add -net 192.168.100.0/24 88.88.88.252
这里指192.168.100.0这个网段，是因为我PPPOE Server上分配的远程地址段是这个段的。

2、开始测试
在Linux上ADSL拨号，拨四条，第一条将远程地址设为自己的默认网关，其它三条就不用了（设了也是白设），
如下：

1. # route -n
   
2. Kernel IP routing table
   
3. Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
   
4. 88.88.88.252    0.0.0.0         255.255.255.255 UH    0      0        0 ppp1
   
5. 88.88.88.252    0.0.0.0         255.255.255.255 UH    0      0        0 ppp2
   
6. 88.88.88.252    0.0.0.0         255.255.255.255 UH    0      0        0 ppp3
   
7. 88.88.88.252    0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
   
8. 192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
   
9. 127.0.0.0       0.0.0.0         255.255.255.0   U     0      0        0 lo
   
10. 0.0.0.0         88.88.88.252    0.0.0.0         UG    0      0        0 ppp0

复制代码

从路由表中可以看出，四条链路都拨号成功，且默认路由指向PPPOE Server，在ppp0上。

从192.168.0.68，开始ping 88.88.88.44
这样，数据包应该从19.168.0.68，经地址伪装至ppp0(192.168.100.2)，到默认网关PPPOE Server(88.88.88.252)，然后再交至
88.88.88.44，88.88.88.44查到刚才加的那条路由route add -net 192.168.100.0/24 88.88.88.252，把回去的包原路返回，事
实上，也的确如此，以下为192.168.0.68上的测试结果：

1. C:\Documents and Settings\Administrator.SKYNET-CV8KB035>ping 88.88.88.44 -t
   
2. 
   
3. Pinging 88.88.88.44 with 32 bytes of data:
   
4. 
   
5. Reply from 88.88.88.44: bytes=32 time=6ms TTL=62
   
6. Reply from 88.88.88.44: bytes=32 time=3ms TTL=62
   
7. Reply from 88.88.88.44: bytes=32 time=3ms TTL=62
   
8. Reply from 88.88.88.44: bytes=32 time=3ms TTL=62

复制代码

1. C:\Documents and Settings\Administrator.SKYNET-CV8KB035>tracert -d 88.88.88.44
   
2. 
   
3. Tracing route to 88.88.88.44 over a maximum of 30 hops
   
4. 
   
5.   1   <10 ms   <10 ms   <10 ms  192.168.0.1
   
6.   2     3 ms     3 ms     3 ms  88.88.88.252
   
7.   3     3 ms     4 ms     3 ms  88.88.88.44
   
8. 
   
9. Trace complete.

复制代码

然而，这样，根本不存在链种均衡，数据包全是从ppp0出去的，其它三条虽然拨了，但也等于白做，OK，继续：
删除Linux上的默认路由：
# route del -net default dev ppp0
因为没有路由，所以：

1. C:\Documents and Settings\Administrator.SKYNET-CV8KB035>ping 88.88.88.44 -t
   
2. 
   
3. Pinging 88.88.88.44 with 32 bytes of data:
   
4. 
   
5. Reply from 192.168.0.1: Destination net unreachable.

复制代码

OK，接下来开始尝试链路负载均衡了，
先做一条默认路由，试试我自己的路由表能否正常运行：

添加路由表：

1. # ip rule add from 192.168.0.0/24 iif eth0 table 100
   
2. # ip route flush cache table 100
   
3. # ip route add default scope global dev ppp0 table 100

复制代码

内核开始报怨：

1. # NET: 3 messages suppressed.
   
2. MASQUERADE: No route.
   
3. MASQUERADE: Route sent us somewhere else.
   
4. MASQUERADE: Route sent us somewhere else.
   
5. MASQUERADE: Route sent us somewhere else.
   
6. MASQUERADE: No route.
   
7. MASQUERADE: No route.
   
8. MASQUERADE: Route sent us somewhere else.

复制代码

err……网络不通，netfilter不断报错，一时没有想通为何会这样，按理说，这样和加在main表中是一样的……

那再试试多条呢？

1. # ip route dle default scope global dev ppp0 table 100
   
2. #ip route add default scope global table 100 nexthop dev ppp0 nexthop dev ppp1 nexthop dev ppp2 nexthop dev ppp3

复制代码

C:\Documents and Settings\Administrator.SKYNET-CV8KB035>ping 88.88.88.44

也是一样的不通：

1. Pinging 88.88.88.44 with 32 bytes of data:
   
2. 
   
3. Request timed out.
   
4. Request timed out.
   
5. Request timed out.
   
6. Request timed out.

复制代码

内核报怨：

1. # MASQUERADE: No route.
   
2. MASQUERADE: No route.
   
3. MASQUERADE: No route.
   
4. MASQUERADE: No route.

复制代码

这是我的路由表

1. # ip route show
   
2. 88.88.88.252 dev ppp0  proto kernel  scope link  src 192.168.100.2
   
3. 88.88.88.252 dev ppp1  proto kernel  scope link  src 192.168.100.4
   
4. 88.88.88.252 dev ppp2  proto kernel  scope link  src 192.168.100.3
   
5. 88.88.88.252 dev ppp3  proto kernel  scope link  src 192.168.100.1
   
6. 192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.1
   
7. 127.0.0.0/24 dev lo  scope link

复制代码

1. # ip route show table 100
   
2. default
   
3.         nexthop dev ppp0 weight 1
   
4.         nexthop dev ppp1 weight 1
   
5.         nexthop dev ppp2 weight 1
   
6.         nexthop dev ppp3 weight 1     

复制代码

继续尝试中……

platinum

如果判断没错的话，这是 2.4 内核的一个 BUG，我很早以前遇到过，并有过完美的解决，九贱可以看一下
http://bbs.chinaunix.net/viewthr ... ;highlight=platinum

独孤九贱

原帖由 platinum 于 2006-6-15 12:35 发表
如果判断没错的话，这是 2.4 内核的一个 BUG，我很早以前遇到过，并有过完美的解决，九贱可以看一下
http://bbs.chinaunix.net/viewthr ... ;highlight=platinum

谢谢白金兄，看了你show的图，羡慕啊羡慕……不过为了谨慎点，有个小问题请教一下：
你说的：
patch-o-matic-20041009.tar.bz2
这个补丁，我对netfilter 的补丁没有多少研究，我打的是：
patch-o-matic-ng-20060101.tar.bz2（当时为了支持更多的功能，打的这个补丁）
这个带ng和不带ng的补丁有什么区别呢？我再打你说的这个补丁，会影响我以前的那个么？

platinum

个人理解，ng 的是 extra patch，不带 ng 的是 base patch，一些内核的错误在 base patch 上解决
前后顺序无所谓，你 vi 一下那个文件手动改也可以

独孤九贱

原帖由 platinum 于 2006-6-15 13:28 发表
个人理解，ng 的是 extra patch，不带 ng 的是 base patch，一些内核的错误在 base patch 上解决
前后顺序无所谓，你 vi 一下那个文件手动改也可以

不是吧？两种补丁都有base 和extra区分的，我想ng可能是没有ng的升级版……

我怀疑是这样的，因为是MASQUERADE的BUG，但是当我打这个补丁的时候，因为我内核已经有这个功能了，所以，就略过没有打这个补丁，我现在想把源码直接覆盖，重新编译试一下，不过好像没有源码，只是diff……

那有没有办法，强行再只把MASQUERADE的补丁打上呢？

[ 本帖最后由 独孤九贱 于 2006-6-15 13:42 编辑 ]

platinum

我说的是相对的 base 和 extra，呵呵
你看一下 diff，手动根据里面的差异改一下就可以了，就几句话，很简单

独孤九贱

原帖由 platinum 于 2006-6-15 13:43 发表
我说的是相对的 base 和 extra，呵呵
你看一下 diff，手动根据里面的差异改一下就可以了，就几句话，很简单

我下了你说那个补丁：

1. ./runme pending
   
2. ……
   
3. Testing... 62_masquerade-oif.patch NOT APPLIED (1 rejects out of 1 hunks)
   
4. The pending/62_masquerade-oif patch:
   
5.    Author: Sven Strickroth <email@cs-ware.de>
   
6.    Status: Pending for kernel inclusion
   
7.    
   
8.    The 2.4.23 kernel introduced a bug that can cause routing problems with
   
9.    MASQUERADE.  This patch fixes those issues.
   
10. 
    
11. -----------------------------------------------------------------
    
12. Do you want to apply this patch [N/y/t/f/a/r/b/w/q/?] y
    
13. Testing patch pending/62_masquerade-oif.patch...
    
14.    Patch pending/62_masquerade-oif.patch applied cleanly.
    
15. Applying patch pending/62_masquerade-oif.patch...
    
16.    Patch pending/62_masquerade-oif.patch applied cleanly.
    
17. 
    
18. [Press enter to continue]

复制代码

从描述上来看，应该是它了，呵呵，编译中……

platinum

对，就是这个
patch 上以后重编内核再试一下，并告知结果
祝你成功！

独孤九贱

原帖由 platinum 于 2006-6-15 14:00 发表
对，就是这个
patch 上以后重编内核再试一下，并告知结果
祝你成功！

好的，谢谢你啦！
编译一半，又看到另一个东东：

1. Testing... 64_masquerade-sameip-noflush.patch NOT APPLIED (3 rejects out of 3 hunks)
   
2. The submitted/64_masquerade-sameip-noflush patch:
   
3.    Author: Rusty Russell <rusty@rustcorp.com.au>
   
4.    Status: Testing, already submitted to 2.6
   
5.    
   
6.    Herve Eychenne noted that many ADSL connections get the same
   
7.    address when the interface comes back up, so some users use SNAT
   
8.    instead of masquerade.  The answer is that MASQUERADE should only
   
9.    drop connections when the interface comes up, and then only if the
   
10.    interface address has actually changed.

复制代码

这是啥东东？？

独孤九贱

1、打了补丁，做了调整后，的确可以实现负载均衡，如下，这是从192.168.0.68 ping 88.88.88.44的结果，可以看到，因为我在Linux上不断地ip route flush cache，在88.88.88.44上看到的来源地址在两条ADSL链路中反复随机切换，我目前只用了两条：

1. [15:23:56] 发送到 192.168.100.1 的 ICMP 数据包，
   
2.            类型: 0 ， 代码: 0，
   
3.            该包允许通行。
   
4. 
   
5. [15:23:57] 192.168.100.1 尝试用Ping 来探测本机，
   
6.            该操作被允许。
   
7. 
   
8. [15:23:57] 发送到 192.168.100.1 的 ICMP 数据包，
   
9.            类型: 0 ， 代码: 0，
   
10.            该包允许通行。
    
11. 
    
12. [15:23:58] 192.168.100.3 尝试用Ping 来探测本机，
    
13.            该操作被允许。
    
14. 
    
15. [15:23:58] 发送到 192.168.100.3 的 ICMP 数据包，
    
16.            类型: 0 ， 代码: 0，
    
17.            该包允许通行。
    
18. 
    
19. [15:23:59] 192.168.100.3 尝试用Ping 来探测本机，
    
20.            该操作被允许。
    
21. 
    
22. [15:23:59] 发送到 192.168.100.3 的 ICMP 数据包，
    
23.            类型: 0 ， 代码: 0，
    
24.            该包允许通行。
    
25. 
    
26. [15:24:00] 192.168.100.3 尝试用Ping 来探测本机，
    
27.            该操作被允许。
    
28. 
    
29. [15:24:00] 发送到 192.168.100.3 的 ICMP 数据包，
    
30.            类型: 0 ， 代码: 0，
    
31.            该包允许通行。
    
32. 
    
33. [15:24:01] 192.168.100.1 尝试用Ping 来探测本机，
    
34.            该操作被允许。
    
35. 
    
36. [15:24:01] 发送到 192.168.100.1 的 ICMP 数据包，
    
37.            类型: 0 ， 代码: 0，
    
38.            该包允许通行。

复制代码

2、虽然能够这样通读，但是我反向测试，从88.88.88.44 ping 到192.168.100.X，却ping不通，百思不得其解，而且这肯定跟这条策略路由有关系的，因为我将其删除之，加上route add default gw 88.88.88.252 dev ppp0，就可以通，也就是说，我现在是单向通，真奇怪……
也就是说，如果是在internet上，Linux是不可以远程管理的，从iptables 中，可以看到，Linux是收到数据包了，是因为出去的路由出了问题，导致数据出来去，原因查找中

PS:原因找到了，低级错误，因为我加的策略路由表是：
ip rule add from 192.168.0.0/24 iif eth0 table 100

当然不会针对我外面的数据包了，所以对外面来的数据，还是没有路由，再加一条：
route add default gw 88.88.88.252 dev ppp0，
搞定，呵呵，不错啊，局域网测通了，晚上回去到家里头试试先，哈哈

不过，最后的疑问是：
很频繁的ip route flush cache ，在路由查找频繁的时候，会不会很影响效率？？？

[ 本帖最后由 独孤九贱 于 2006-6-15 15:45 编辑 ]