Обновился на днях до Ubuntu 14.04(amd64) и столкнулся со следующей проблемой.
Используется балансировка каналов на 2-х операторов.
За основу взят
http://help.ubuntu.ru/wiki/ip_balancing#%D1%81...
с незначительными изменениями. В принципе выдержка из LARTC.
Разница лишь в обработке события доступности каналов.
Однако на 12.04 проблем не наблюдалось.
Ну или почти не наблюдалось. Стоило обновить ядро выше того, что шло в изначальной поставке (3.2) и получал проблемы, описанные ниже.
Суть проблемы сводится к тому, что в skype наблюдается деградация звука(чихает, "пердит", "икает", "металлизированный голос", сайты открываются через раз (http трафик, вроде, ходит тоже нормально. Ну или мне так показалось. А вот с https уже проблемы).
Если сменить маршрут по умолчанию на какой либо из каналов по отдельности проблем нет.
Пинги ходят без проблем.
У кого какие могут быть соображения?
Гуглу вопрос задавал, но, видимо, не правильно его спрашивал. Ответа не нашел.
У тебя всё сделано аналогично, как и в статье по ссылке?И маршруты?
ip route
....
default
nexthop via 194.9.xx.xx dev eth0 weight 2
nexthop via 195.5.xx.xx dev ppp0 weight 1
Да? Ну и ССЗБ.
Не читай советскую прессу за обедом.Как решать проблему...
1) Думать, что делаешь и зачем. Отказаться от костыля. Например, балансировать по каким-то другим принципам, а не по "рандому".
2) Упереться рогами в костыль и пытаться превращать его в "решение" - например привязать через connmark установившееся соединение к конкретному маршруту (зафиксировать маршрут).
>[оверквотинг удален]
> nexthop via 194.9.xx.xx dev eth0 weight 2
> nexthop via 195.5.xx.xx dev ppp0 weight 1
> Да? Ну и ССЗБ.
> Не читай советскую прессу за обедом.
> Как решать проблему...
> 1) Думать, что делаешь и зачем. Отказаться от костыля. Например, балансировать по
> каким-то другим принципам, а не по "рандому".
> 2) Упереться рогами в костыль и пытаться превращать его в "решение" -
> например привязать через connmark установившееся соединение к конкретному маршруту (зафиксировать
> маршрут).Хорошо, а в чем принципиальная разница от?
http://www.opennet.me/docs/RUS/LARTC/LARTC-net.html.gz#x348_...
>[оверквотинг удален]
> nexthop via 194.9.xx.xx dev eth0 weight 2
> nexthop via 195.5.xx.xx dev ppp0 weight 1
> Да? Ну и ССЗБ.
> Не читай советскую прессу за обедом.
> Как решать проблему...
> 1) Думать, что делаешь и зачем. Отказаться от костыля. Например, балансировать по
> каким-то другим принципам, а не по "рандому".
> 2) Упереться рогами в костыль и пытаться превращать его в "решение" -
> например привязать через connmark установившееся соединение к конкретному маршруту (зафиксировать
> маршрут).Решение с использованием connmark нравится еще меньше в силу своего дополнительного нагромождения.
Ну и коли отвергаете данную реализацию было бы хорошим тоном предложить своё видение утилизации 2-х каналов.
1)>Итого имеем два шлюза, первый с весом 2 и второй с весом 1.
2)
> Тоесть через первый канал пойдет в два раза больше трафика, чем через второй.
Из (1) далеко не однозначно следует (2).
> 1)
>>Итого имеем два шлюза, первый с весом 2 и второй с весом 1.
> 2)
>> Тоесть через первый канал пойдет в два раза больше трафика, чем через второй.
> Из (1) далеко не однозначно следует (2).PavelR, я прекрасно понимаю все минусы данной реализации.
По сути большинство подобных реализаций основаны на LARTC, url на который я привел выше.
А вопрос мой том, что хотел узнать почему она перестала отрабатывать как раньше.
проблема с этим древним костылём следующая (сам нарывался):
после 3.4 выпилили route cache в том понимании в котором оно было.
при ядре <= 3.4 маршрут "кэшировался" - если скажем один пакет пошёл на yandex.ru через прова А то и остальные следовали за ним. А теперь нет. Тот же браузер может открыть 10++ коннектов и науке не будет известно каким путём товарищ пойдёт при каждом новом коннекте..
> проблема с этим древним костылём следующая (сам нарывался):
> после 3.4 выпилили route cache в том понимании в котором оно было.
> при ядре <= 3.4 маршрут "кэшировался" - если скажем один пакет пошёл
> на yandex.ru через прова А то и остальные следовали за ним.
> А теперь нет. Тот же браузер может открыть 10++ коннектов и
> науке не будет известно каким путём товарищ пойдёт при каждом новом
> коннекте..Забавно, вроде бы всегда читаю change log к свежим выпускам ядер.
Спасибо за ответ!
Какие есть предложения по утилизации 2-х каналов?
>> проблема с этим древним костылём следующая (сам нарывался):
>> после 3.4 выпилили route cache в том понимании в котором оно было.
>> при ядре <= 3.4 маршрут "кэшировался" - если скажем один пакет пошёл
>> на yandex.ru через прова А то и остальные следовали за ним.
>> А теперь нет. Тот же браузер может открыть 10++ коннектов и
>> науке не будет известно каким путём товарищ пойдёт при каждом новом
>> коннекте..
> Забавно, вроде бы всегда читаю change log к свежим выпускам ядер.
> Спасибо за ответ!
> Какие есть предложения по утилизации 2-х каналов?1) Думать, что делаешь и зачем.
1.1) Вернуться на то, что работает, и не е-ть (есть) мозг себе и окружающим.1.2) Как было сказано выше: "Отказаться от костыля. Например, балансировать по каким-то другим принципам, а не по "рандому"."
Таким принципом может быть привязка к каналу по SRC IP (предпочтительно) либо по DST IP (тот еще костыль). привязка делается не непосредственно по айпи, а по "четности" - четные туда - нечетные - туда. Нужна развесовка 1/3 + 2/3 - берем остаток от деления на три. )
1.3) Ищем общую точку снаружи, делаем туннели через "несущие каналы" к "общей точке", балансируем через веса как и сейчас.2) Учим матчасть и не спрашиваем про "предложения по утилизации". В куче статей всё описано, надо только прочитать.
>[оверквотинг удален]
> другим принципам, а не по "рандому"."
> Таким принципом может быть привязка к каналу по SRC IP (предпочтительно) либо
> по DST IP (тот еще костыль). привязка делается не непосредственно по
> айпи, а по "четности" - четные туда - нечетные - туда.
> Нужна развесовка 1/3 + 2/3 - берем остаток от деления
> на три. )
> 1.3) Ищем общую точку снаружи, делаем туннели через "несущие каналы" к "общей
> точке", балансируем через веса как и сейчас.
> 2) Учим матчасть и не спрашиваем про "предложения по утилизации". В куче
> статей всё описано, надо только прочитать.PavelR, не пробовали общаться на более спокойных тонах? Без комментариев про "кушать мозг себе и окружающим".
Тем не менее спасибо за п.1.2 и п.1.3
> Забавно, вроде бы всегда читаю change log к свежим выпускам ядер.
> Спасибо за ответ!
> Какие есть предложения по утилизации 2-х каналов?http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
>> Забавно, вроде бы всегда читаю change log к свежим выпускам ядер.
>> Спасибо за ответ!
>> Какие есть предложения по утилизации 2-х каналов?
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...Благодарю за пруф.