https://slinkov.ru/openforum/vsluhforumID1/95572.html Обновился на днях до Ubuntu 14.04(amd64) и столкнулся со следующей проблемой.<br>Используется балансировка каналов на 2-х операторов.<br>За основу взят <br>http://help.ubuntu.ru/wiki/ip_balancing#%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1_2<br>с незначительными изменениями. В принципе выдержка из LARTC.<br>Разница лишь в обработке события доступности каналов.<br>Однако на 12.04 проблем не наблюдалось.<br>Ну или почти не наблюдалось. Стоило обновить ядро выше того, что шло в изначальной поставке (3.2) и получал проблемы, описанные ниже.<br>Суть проблемы сводится к тому, что в skype наблюдается деградация звука(чихает, "пердит", "икает", "металлизированный голос", сайты открываются через раз (http трафик, вроде, ходит тоже нормально. Ну или мне так показалось. А вот с https уже проблемы).<br>Если сменить маршрут по умолчанию на какой либо из каналов по отдельности проблем нет.<br>Пинги ходят без проблем.<br>У кого какие могут быть соображения?<br>Гуглу вопрос задавал, но, видимо, не правильно его спрашивал. Ответа не нашел.<br> https://slinkov.ru/openforum/vsluhforumID1/95572.html#11 Mon, 21 Apr 2014 13:27:56 GMT &gt;&gt; Забавно, вроде бы всегда читаю change log к свежим выпускам ядер.<br>&gt;&gt; Спасибо за ответ!<br>&gt;&gt; Какие есть предложения по утилизации 2-х каналов?<br>&gt; http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=89aef8921bfbac22f00e04f8450f6e447db13e42 <br><br>Благодарю за пруф.<br> https://slinkov.ru/openforum/vsluhforumID1/95572.html#10 Mon, 21 Apr 2014 11:31:35 GMT &gt; Забавно, вроде бы всегда читаю change log к свежим выпускам ядер.<br>&gt; Спасибо за ответ!<br>&gt; Какие есть предложения по утилизации 2-х каналов?<br><br>http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=89aef8921bfbac22f00e04f8450f6e447db13e42<br><br> https://slinkov.ru/openforum/vsluhforumID1/95572.html#9 Mon, 21 Apr 2014 05:53:55 GMT &gt;[оверквотинг удален]<br>&gt; другим принципам, а не по "рандому"." <br>&gt; Таким принципом может быть привязка к каналу по SRC IP (предпочтительно) либо <br>&gt; по DST IP (тот еще костыль). привязка делается не непосредственно по <br>&gt; айпи, а по "четности" - четные туда - нечетные - туда. <br>&gt; Нужна развесовка 1/3 + 2/3 - берем остаток от деления <br>&gt; на три. ) <br>&gt; 1.3) Ищем общую точку снаружи, делаем туннели через "несущие каналы" к "общей <br>&gt; точке", балансируем через веса как и сейчас.<br>&gt; 2) Учим матчасть и не спрашиваем про "предложения по утилизации". В куче <br>&gt; статей всё описано, надо только прочитать.<br><br>PavelR, не пробовали общаться на более спокойных тонах? Без комментариев про "кушать мозг себе и окружающим".<br>Тем не менее спасибо за п.1.2 и п.1.3<br><br> https://slinkov.ru/openforum/vsluhforumID1/95572.html#8 Mon, 21 Apr 2014 05:25:38 GMT &gt;&gt; проблема с этим древним костылём следующая (сам нарывался): <br>&gt;&gt; после 3.4 выпилили route cache в том понимании в котором оно было.<br>&gt;&gt; при ядре &lt;= 3.4 маршрут "кэшировался" - если скажем один пакет пошёл <br>&gt;&gt; на yandex.ru через прова А то и остальные следовали за ним.<br>&gt;&gt; А теперь нет. Тот же браузер может открыть 10++ коннектов и <br>&gt;&gt; науке не будет известно каким путём товарищ пойдёт при каждом новом <br>&gt;&gt; коннекте..<br>&gt; Забавно, вроде бы всегда читаю change log к свежим выпускам ядер.<br>&gt; Спасибо за ответ!<br>&gt; Какие есть предложения по утилизации 2-х каналов?<br><br>1) Думать, что делаешь и зачем. <br><br><br>1.1) Вернуться на то, что работает, и не е-ть (есть) мозг себе и окружающим.<br><br>1.2) Как было сказано выше: "Отказаться от костыля. Например, балансировать по каким-то другим принципам, а не по "рандому"."<br><br>Таким принципом может быть привязка к каналу по SRC IP (предпочтительно) либо по DST IP (тот еще костыль). привязка делается не непосредственно по айпи, а по "четности" - четные туда - нечетные - туда. Нужн https://slinkov.ru/openforum/vsluhforumID1/95572.html#7 Mon, 21 Apr 2014 04:11:53 GMT &gt;[оверквотинг удален]<br>&gt; nexthop via 194.9.xx.xx dev eth0 weight 2 <br>&gt; nexthop via 195.5.xx.xx dev ppp0 weight 1 <br>&gt; Да? Ну и ССЗБ.<br>&gt; Не читай советскую прессу за обедом.<br>&gt; Как решать проблему...<br>&gt; 1) Думать, что делаешь и зачем. Отказаться от костыля. Например, балансировать по <br>&gt; каким-то другим принципам, а не по "рандому".<br>&gt; 2) Упереться рогами в костыль и пытаться превращать его в "решение" - <br>&gt; например привязать через connmark установившееся соединение к конкретному маршруту (зафиксировать <br>&gt; маршрут).<br><br>Решение с использованием connmark нравится еще меньше в силу своего дополнительного нагромождения.<br>Ну и коли отвергаете данную реализацию было бы хорошим тоном предложить своё видение утилизации 2-х каналов.<br><br><br><br> https://slinkov.ru/openforum/vsluhforumID1/95572.html#6 Mon, 21 Apr 2014 04:01:15 GMT &gt; 1) <br>&gt;&gt;Итого имеем два шлюза, первый с весом 2 и второй с весом 1.<br>&gt; 2) <br>&gt;&gt; Тоесть через первый канал пойдет в два раза больше трафика, чем через второй.<br>&gt; Из (1) далеко не однозначно следует (2).<br><br>PavelR, я прекрасно понимаю все минусы данной реализации.<br>По сути большинство подобных реализаций основаны на LARTC, url на который я привел выше.<br>А вопрос мой том, что хотел узнать почему она перестала отрабатывать как раньше.<br><br> https://slinkov.ru/openforum/vsluhforumID1/95572.html#5 Mon, 21 Apr 2014 02:57:04 GMT &gt; проблема с этим древним костылём следующая (сам нарывался): <br>&gt; после 3.4 выпилили route cache в том понимании в котором оно было. <br>&gt; при ядре &lt;= 3.4 маршрут "кэшировался" - если скажем один пакет пошёл <br>&gt; на yandex.ru через прова А то и остальные следовали за ним. <br>&gt; А теперь нет. Тот же браузер может открыть 10++ коннектов и <br>&gt; науке не будет известно каким путём товарищ пойдёт при каждом новом <br>&gt; коннекте..<br><br>Забавно, вроде бы всегда читаю change log к свежим выпускам ядер.<br>Спасибо за ответ!<br>Какие есть предложения по утилизации 2-х каналов?<br> https://slinkov.ru/openforum/vsluhforumID1/95572.html#4 Mon, 21 Apr 2014 02:55:49 GMT &gt;[оверквотинг удален]<br>&gt; nexthop via 194.9.xx.xx dev eth0 weight 2 <br>&gt; nexthop via 195.5.xx.xx dev ppp0 weight 1 <br>&gt; Да? Ну и ССЗБ.<br>&gt; Не читай советскую прессу за обедом.<br>&gt; Как решать проблему...<br>&gt; 1) Думать, что делаешь и зачем. Отказаться от костыля. Например, балансировать по <br>&gt; каким-то другим принципам, а не по "рандому".<br>&gt; 2) Упереться рогами в костыль и пытаться превращать его в "решение" - <br>&gt; например привязать через connmark установившееся соединение к конкретному маршруту (зафиксировать <br>&gt; маршрут).<br><br>Хорошо, а в чем принципиальная разница от?<br>http://www.opennet.ru/docs/RUS/LARTC/LARTC-net.html.gz#x348_html<br> https://slinkov.ru/openforum/vsluhforumID1/95572.html#3 Sun, 20 Apr 2014 22:00:03 GMT проблема с этим древним костылём следующая (сам нарывался):<br>после 3.4 выпилили route cache в том понимании в котором оно было.<br>при ядре &lt;= 3.4 маршрут "кэшировался" - если скажем один пакет пошёл на yandex.ru через прова А то и остальные следовали за ним. А теперь нет. Тот же браузер может открыть 10++ коннектов и науке не будет известно каким путём товарищ пойдёт при каждом новом коннекте..<br><br><br><br>