Comments 27
UFO just landed and posted this here
Значит BGP демон не сможет с ним связаться и анонсировать ему наши сети. Следовательно, весь входящий пойдет по оставшемуся каналу.
Ну а для исходящих надо или мониторить эти 2 канала с автоматическим изменением default маршрута, или настраивать BGP так, чтобы он изменял свои локальные маршруты.
У меня используется 1й вариант — моя AS не пропускает транзитный трафик, достаточно обойтись статическими маршрутами.
В итоге, каждые 5 минут проверяется доступность 8.8.8.8 через оба канала (мониторить сами шлюзы смысла нет — проблема может быть дальше). Если оба доступны, то:
ip route change default scope global nexthop via [IP шлюза 1 пров] dev [eth 1 пров] weight 1 nexthop via [IP шлюза 2 пров] dev [eth 2 пров] weight 1
Если один, то:
ip route change default via [IP шлюза оставшегося прова] dev [eth оставшегося прова]
В результате, при пропадании одного из каналов, в течении 5 минут, происходит переключение исходящего маршрута на оставшийся канал. Входящий анонсируемый маршрут остается один — оставшегося канала.
N достигает минимума или максимума, таким и остается. Но на работу это уже не сказывается. Ну, натиться все будут одним диапазоном, и что?
Единственный минус — оставшийся канал оказывается перегружен. Ведет это к большим потерям. Но, это форс-мажор, авария… И обычно не так долго.
Такой мониторинг работает у меня давно (больше года). Время от времени пропадает то 1 канал, то другой. Все отрабатывает нормально, еще и сообщение на мыло присылает.
При восстановлении канала все быстро приходит в норму.
Ну а для исходящих надо или мониторить эти 2 канала с автоматическим изменением default маршрута, или настраивать BGP так, чтобы он изменял свои локальные маршруты.
У меня используется 1й вариант — моя AS не пропускает транзитный трафик, достаточно обойтись статическими маршрутами.
В итоге, каждые 5 минут проверяется доступность 8.8.8.8 через оба канала (мониторить сами шлюзы смысла нет — проблема может быть дальше). Если оба доступны, то:
ip route change default scope global nexthop via [IP шлюза 1 пров] dev [eth 1 пров] weight 1 nexthop via [IP шлюза 2 пров] dev [eth 2 пров] weight 1
Если один, то:
ip route change default via [IP шлюза оставшегося прова] dev [eth оставшегося прова]
В результате, при пропадании одного из каналов, в течении 5 минут, происходит переключение исходящего маршрута на оставшийся канал. Входящий анонсируемый маршрут остается один — оставшегося канала.
N достигает минимума или максимума, таким и остается. Но на работу это уже не сказывается. Ну, натиться все будут одним диапазоном, и что?
Единственный минус — оставшийся канал оказывается перегружен. Ведет это к большим потерям. Но, это форс-мажор, авария… И обычно не так долго.
Такой мониторинг работает у меня давно (больше года). Время от времени пропадает то 1 канал, то другой. Все отрабатывает нормально, еще и сообщение на мыло присылает.
При восстановлении канала все быстро приходит в норму.
при такой смене дефолт-роута может сложиться ситуация, что открытые соединения изза коннтрака пойдут по новому умолчательному маршруту, но будут снатиться по прежнему на старый адрес.
И бог с ними!
Главное, чтобы существовал анонс для этого «старого адреса» на «живой» маршрут. При этом, длина этого маршрута не имеет значения — он остался один.
Смотрите.
Клиент натится адресом ВнешнийАдресКлиента.
Пока живы оба канала, анонсируются два маршрута на этот ВнешнийАдресКлиента. Один чуть длиннее другого. Следовательно, трафик этому клиенту пойдет по короткому маршруту.
Если в живых остается один канал, то и анонсируется только один маршрут (на оставшийся канал). Следовательно, весь трафик этому клиенту пойдет только по живому каналу. При этом все остальное не имеет значения.
Это особенность работы BGP — автоматическое поддерживание «живых» маршрутов. И автоматическая очистка от «мертвых».
Главное, чтобы существовал анонс для этого «старого адреса» на «живой» маршрут. При этом, длина этого маршрута не имеет значения — он остался один.
Смотрите.
Клиент натится адресом ВнешнийАдресКлиента.
Пока живы оба канала, анонсируются два маршрута на этот ВнешнийАдресКлиента. Один чуть длиннее другого. Следовательно, трафик этому клиенту пойдет по короткому маршруту.
Если в живых остается один канал, то и анонсируется только один маршрут (на оставшийся канал). Следовательно, весь трафик этому клиенту пойдет только по живому каналу. При этом все остальное не имеет значения.
Это особенность работы BGP — автоматическое поддерживание «живых» маршрутов. И автоматическая очистка от «мертвых».
UP. Замечу, что хотя полное анонсирование своего маршрута на весь Интернет, — дело долгое (до 6 часов), информация до ближайших маршрутизаторов доходит быстро (по моим наблюдениям 5-10 минут). И это оказывает решающее значение. Даже если какой-то хост в далекой Америке (например) отправит пакет по уже «мертвому» маршруту, то где-то вблизи от меня этот пакет переправится по «живому» пути.
а если все тоже самое, но без бгп ?)
Хм… Чтобы принимать трафик на одни и те-же адреса через несколько каналов — это надо иметь автономную систему (AS). Т.е. независимые от провайдера адреса. Никакой провайдер не станет маршрутизировать свои адреса через другого.
Ну, а где AS, там и BGP.
ИМХО, балансировать входящий без равноправности адресов в разных каналах — это создавать большие проблемы клиентам. Придется постоянно менять внешний адрес клиента, что далеко не гуд.
Или менять «N» изредка. До получения AS так и делали, но это «N» менялось вручную по мере надобности. Подобрать оптимального просто не получалось. В результате в течении суток то один канал переполнялся, то другой. А это — потери. Опять «не гуд».
Ну, а где AS, там и BGP.
ИМХО, балансировать входящий без равноправности адресов в разных каналах — это создавать большие проблемы клиентам. Придется постоянно менять внешний адрес клиента, что далеко не гуд.
Или менять «N» изредка. До получения AS так и делали, но это «N» менялось вручную по мере надобности. Подобрать оптимального просто не получалось. В результате в течении суток то один канал переполнялся, то другой. А это — потери. Опять «не гуд».
не, я имел ввиду обычный фейловер на случай падения основного канала — как быть с открытыми соединениями. рвать принудительно через conntrack -D при смене маршрута по-умолчанию?
А зачем? Если ответа нет, то по тайм-ауту сами отвалятся. Только IP стек надо настроить — уменьшить этот тайм-аут до адекватных 30 минут (например). А лучше 5 минут. По-умолчанию там что-то около недели.
Но это уже другой разговор — оптимизация IP стека на шлюзе.
Но это уже другой разговор — оптимизация IP стека на шлюзе.
5 минут ?) а если цель — обеспечить воип с мин простоями?
Кратковременное прерывание все равно будет, от этого никак не уйти. Это если «оборвался» как раз канал, по которому идет основной трафик клиента. Иначе вообще никаких прерываний.
Чтобы уменьшить время прерывания — AS и BGP. Т.е. сохраняется внешний адрес клиента независимо от входящего/исходящего канала.
Другой вариант — bond на 2 провайдера. Но это не реально. Если 2 подключения к одному, это еще как-то возможно. А к разным… Им это надо?
Чтобы уменьшить время прерывания — AS и BGP. Т.е. сохраняется внешний адрес клиента независимо от входящего/исходящего канала.
Другой вариант — bond на 2 провайдера. Но это не реально. Если 2 подключения к одному, это еще как-то возможно. А к разным… Им это надо?
А чем это решение лучше/хуже настройки bond-интерфейса? И не получится ли так, что для одного и того же адресата исходящие пакеты отправляются по разным каналам в разные моменты времени?
у бонд-интерфейса 1 ип-адрес, нужна поддержка со стороны «другого конца проводов»
2 разных провайдера никогда не дадут создать такое подключение.
И не получится ли так, что для одного и того же адресата исходящие пакеты отправляются по разным каналам в разные моменты времени?
Более того, и исходящие от клиента, и входящие к клиенту, могут идти одновременно по обоим каналам (т.е. часть по одному, часть по другому). И это нормальное явление в Интернете.
Пусть себе отправляются — какая разница? :) Все равно в конечном итоге приедут куда надо.
никто не мешает дополнительно в BGP описать (т.е. анонсировать) 1.1.144.0/24, 1.1.145.0/24, 1.1.146.0/24 и 1.1.147.0/24
Вот Вы совсем не самурай. Самураи так не делают, т.к. это увеличивает и так раздутый full view и, как следствие, повышает энтропию вселенной, приближая тепловую смерть.
Правильно брать у обеих аплинков физику с запасом и канал по burstable billing.
К сожалению, нахожусь я недалеко от Тихого Океана, цены за трафик у нас не маленькие и всего два провайдера с достаточными мощностями.
Так что особо выбирать и кочевряжиться не получится. И переплачивать в два раза — тоже «не фонтан».
А про «full view» согласен… Но куда деваться? На сколько знаю, мелкие узлы его режут. Т.е. мои /24 просто проигнорируют.
Так что особо выбирать и кочевряжиться не получится. И переплачивать в два раза — тоже «не фонтан».
А про «full view» согласен… Но куда деваться? На сколько знаю, мелкие узлы его режут. Т.е. мои /24 просто проигнорируют.
UFO just landed and posted this here
Мне повезло на 50%. У одного провайдера сразу были возможны препенды, второй разрешил после недели переписки.
PS. И действительно, у вышестоящих провайдеров были разные local-pref от пиров. Пришлось выравнивать своими «set as-path prepend». Но получилось. ;)
Не зря писал
И с этим довольно долго помучился…
Не зря писал
Во-первых, надо настроить все «set as-path prepend» в bgp.conf.
Задача — чтобы если все натить исходящим 1.1.146.0/24 (это условно, конечно), то получить большой перекос в сторону РТК.
И наоборот, если все натить исходящим 1.1.147.0/24, то получить сильный перекос в сторону ТТК.
И с этим довольно долго помучился…
UFO just landed and posted this here
Если честно — не знаю. Работает, и не заморачиваюсь.
Основной трафик идет издалека, и он регулируется. Так что если от кого-то трафик будет идти только по одному каналу (как аплинк приказал, а такое скорее всего имеется), то основной массой трафика выравнивается.
Кстати, а и не всегда выравнивается! Ночью, когда трафика мало — диапазона регулировки часто не хватает. И между каналами идет перекос. Но это ночью, каналы почти пустуют, так что не страшно. Главная задача — не допустить переполнения каналов при эффективном их использовании, и задача эта успешно выполняется.
Хм… Вот и объяснение, почему ночью плохая балансировка (т.е. отклонение от заданного соотношения). А я все голову ломал…
Основной трафик идет издалека, и он регулируется. Так что если от кого-то трафик будет идти только по одному каналу (как аплинк приказал, а такое скорее всего имеется), то основной массой трафика выравнивается.
Кстати, а и не всегда выравнивается! Ночью, когда трафика мало — диапазона регулировки часто не хватает. И между каналами идет перекос. Но это ночью, каналы почти пустуют, так что не страшно. Главная задача — не допустить переполнения каналов при эффективном их использовании, и задача эта успешно выполняется.
Хм… Вот и объяснение, почему ночью плохая балансировка (т.е. отклонение от заданного соотношения). А я все голову ломал…
PS. Думаю, найдется много AS, чей трафик указанным методом не выровнять. Но общая масса, особенно «в час пик», — выравнивается. И это для меня главное.
А ещё можно почитать есть ли у провов public community list, проверить там с каким localpref у них сидят префиксы от клиентов, а с каким — от транзитников. И потом от себя задавать на разные префиксы разные community чтоб приоритизировать траффик у прова. Это, конечно, берёт время, но результат будет на лицо. Prepend-ы это далеко не наше всё. Но, хотя, если у вас так работает, то заморачиваться нет смысла.
Sign up to leave a comment.
Балансировка каналов — два провайдера, AS, BGP, NAT