Какие то странные 2 варианта выхода в инет:

inet 192.168.5.31/24

inet 10.10.10.105/24

И да, мне весьма интересно, как работает этот nexthop.

Вот tcpdump (с выводом ethernet-заголовков) запустите и посмотрите, какие пакеты от вас идут при пинге и при http-запросах.

В итоге коннектится очень долго и с трудом, а то и обрывается по таймауту, хотя пинги проходят нормально.

Кто куда конектицо? М.б. MTU?

Раз уж у тебя разные ширины каналов, то и weight нужно делать пропорционально ширине. И в твоём случае балансировку делать нелья, т.к. вероятно будут разные внешние IP адреса у каждого из каналов.

Можно только вешать приложения на разные интерфейсы.

И да, nexthop балансирует маршруты, а не трафик или соединения, см. соответствующую часть в LARTC

Нашел интересную статью

http://www.ssi.bg/~ja/dgd-usage.txt 

И в твоём случае балансировку делать нелья, т.к. вероятно будут разные внешние IP адреса у каждого из каналов.

Можно, но осторожно. Главное чтоб были одинаковые IP (ходили через один и тот же канал) все «порождённые» соединения и, например, ответные ICMP пакеты.
Пример: если управляющее FTP соединение создано через один и каналов, то и соединения данных должны быть созданы тоже через него. А так же ICMP ответы типа «Host Unreachable» и т.п. должны уходить через тот же канал, через который пришёл пакет, вызвавший отсылку ICMP.
Достичь этого можно с помощью маркировки соединений (iptables -j CONNMARK) на основе MAC адреса отправителя (маршрутизатора, с которого пришёл пакет - iptables -m mac) и последующей маршрутизации на основе маркировок соединений (iptables -j CONNMARK --restore-mark и ip rule add ... fwmark xxx table ...).

Но ! Если у вас это не сервер и не маршрутизатор, а обычная рабочая станция, то преобладающими (если вообще не полностью всеми) соединениями будут исходящие соединения. Соответственно маршрут на удалённый IP будет выбираться изначально и будет висеть в кеше маршрутов, поэтому все пакеты (разных соединений) на заданный IP будут ходить по одному и тому же маршруту - всё должно будет работать.

Только вот с торрентами трудно сказать: если подключившись к серверу, вы сказали «я качающий с таким-то IP», и клиенты, с которых качаете, будут ждать такой же IP, тогда засада. Однозначно определить что будет работать и как можно только точно зная особенности работы того или иного протокола.

Статья помогла. Хотя там речь шла о старом ядре и необходимости его патчить, этого не потребовалось сейчас.

Вот коротко как я все сделал (могут быть опечатки)

 $ ip addr list dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:13:46:64:42:d0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.5.31/24 brd 192.168.5.255 scope global eth0
    inet 10.10.10.105/24 scope global eth0

$ ip rule list
0:	from all lookup local 
10:	from all lookup main 
20:	from 192.168.5.0/24 lookup 20 
30:	from 10.10.10.0/24 lookup 30 
100:	from all lookup 100 
32767:	from all lookup default

$ ip route list table main
192.168.5.0/24 dev eth0  proto kernel  scope link  src 192.168.5.31  metric 202 
10.10.10.0/24 dev eth0  proto kernel  scope link  src 10.10.10.105

$ ip route list table 20
default via 192.168.5.1 dev eth0  src 192.168.5.31

$ ip route list table 30
default via 10.10.10.1 dev eth0  src 10.10.10.105 

$ ip route list table 100
default 
	nexthop via 192.168.5.1  dev eth0 weight 6
	nexthop via 10.10.10.1  dev eth0 weight 15 

Этот вариант еще придется подпилить, но в общем пока-что работает. Торренты качаются со скоростю 2мб =)

А если ещё default выбросить в соответствующую встроенную табличку...

Первая фаза iproute2 заключается в выборе старой-доброй таблички маршрутизации по-получателю.
Эта фаза называется «выбор правила» (rule selection).
Основной момент здесь в том, что правила выбираются последовательно с учётом приоритета (он есть число слева):

0: from all lookup local

10: from all lookup main

20: from 192.168.5.0/24 lookup 20

30: from 10.10.10.0/24 lookup 30

100: from all lookup 100

32767: from all lookup default