心急的同学可以直接在已经多拨的路由上运行:
或加入开机自动启动脚本中即可。
欲知细节的同学请继续往下读
建立多个PPPOE链路后,进行负载均衡与带宽合并的方法一般是利用内核中提供的equal cost multipath功能,添加一条特殊的默认路由表项。此表项带有多个下一跳(nexthop)目标,并带有各自的权重。在匹配到这一表项后,内核根据权重随机挑选一条nexthop目标,将数据包路由出去。
这个看上去很完美的方案在实际使用中常常会遇到这样的问题:在访问同一目标地址时负载均衡效果不明显。比如用多线程从单一地址下载一个文件,会发现传输速率大致只相当于一条线路的带宽。(如下图,10Mbit/s LAN * 10拨)
其原因在于路由缓存(routing cache)。使用 ip route show cache命令能查看系统中的路由缓存,看上去像是大量这样的表项: 在对数据包进行路由判定(routing decision)时,为了效率,内核会先查看路由缓存,然后才是真正的路由表。这也是我们在修改路由表项后一般会运行一下ip route flush cache的原因。也正是因为这个原因,在向同一目标地址发起多个连接时,只会用到一条线路,就是routing cache中的那条线路。
解决这一问题的方法是显然的:禁用掉路由缓存。但你会惊奇地发现,内核中居没有一个直接的选项作为路由缓存的开关。在google了N次之后,我终于发现这一个神一般的内核参数: 内核官方文档像这样解释这一参数: 大致意思是说,routing cache是以带bucket的散列表的形式来存放的。当bucket大长,散列冲突太多,超过这一限定值时,为了效率就进行一次rebuild。当这种情况发生许多次时,内核会认为routing cache没有起到应有的作用,于是禁用掉routing cache。禁用掉routing cache!看到没,这不正是我们想要的吗?
解决方法是简单地将这一参数设置成-1,这样任何长度的bucket都会触发rebuild,进而禁用掉routing cache: 之后再从同一源地址多线程下载文件,便能看到质的变化:
大家会问,禁用掉routing cache会不会影响路由的转发性能呢?
事实上是这样,由于一般家用路由的路由表项极少,禁用掉routing cache对性能的影响非常小。在我个人的实际使用过程中完全感觉不到。反倒是多线程下载的速度明显提升了。
欲知细节的同学请继续往下读
建立多个PPPOE链路后,进行负载均衡与带宽合并的方法一般是利用内核中提供的equal cost multipath功能,添加一条特殊的默认路由表项。此表项带有多个下一跳(nexthop)目标,并带有各自的权重。在匹配到这一表项后,内核根据权重随机挑选一条nexthop目标,将数据包路由出去。
这个看上去很完美的方案在实际使用中常常会遇到这样的问题:在访问同一目标地址时负载均衡效果不明显。比如用多线程从单一地址下载一个文件,会发现传输速率大致只相当于一条线路的带宽。(如下图,10Mbit/s LAN * 10拨)
其原因在于路由缓存(routing cache)。使用 ip route show cache命令能查看系统中的路由缓存,看上去像是大量这样的表项: 在对数据包进行路由判定(routing decision)时,为了效率,内核会先查看路由缓存,然后才是真正的路由表。这也是我们在修改路由表项后一般会运行一下ip route flush cache的原因。也正是因为这个原因,在向同一目标地址发起多个连接时,只会用到一条线路,就是routing cache中的那条线路。
解决这一问题的方法是显然的:禁用掉路由缓存。但你会惊奇地发现,内核中居没有一个直接的选项作为路由缓存的开关。在google了N次之后,我终于发现这一个神一般的内核参数: 内核官方文档像这样解释这一参数: 大致意思是说,routing cache是以带bucket的散列表的形式来存放的。当bucket大长,散列冲突太多,超过这一限定值时,为了效率就进行一次rebuild。当这种情况发生许多次时,内核会认为routing cache没有起到应有的作用,于是禁用掉routing cache。禁用掉routing cache!看到没,这不正是我们想要的吗?
解决方法是简单地将这一参数设置成-1,这样任何长度的bucket都会触发rebuild,进而禁用掉routing cache: 之后再从同一源地址多线程下载文件,便能看到质的变化:
大家会问,禁用掉routing cache会不会影响路由的转发性能呢?
事实上是这样,由于一般家用路由的路由表项极少,禁用掉routing cache对性能的影响非常小。在我个人的实际使用过程中完全感觉不到。反倒是多线程下载的速度明显提升了。