[nnm]

#1 нужно делать динамически, те не маркировка и роутинг пакета, а мне надо L3 железку с поддержкой BGP.

#2 видимо покурить BGP и понять делается ли это его средствами и надо будет прописать правила роутинга

 

Резюмируя, эти две задачи решаются L3 железкой с необходимым количеством интерфейсов и поддержкой BGP и иже с ним (e.g. RIP).

 

1. BGP не умеет мониторить загрузку каналов.

2. Протокол маршрутизации принимает решение о том, куда направлять пакет для того адреса, которой стоит в поле Destination IP и это решение в общем случае одинаково для ВСЕХ пакетов направленных к этому адресу (т.е. пакетов от всех клиентов).

 

Мне кажется, что единственный реалистичный способ реализации, это рисовать собственный скрипт который будет мониторить загрузку каналов и динамически подкручивать конфигурации PBR-а для того, чтобы перекинуть часть трафика между каналами. И таки да, нужно быть морально готовым к тому, что после того, как абонента перебрасывают в канал другого провайдера, у него внезапно меняется внешний IP -> он может быть несчастлив.

[nio_jt]

Протокол маршрутизации принимает решение о том, куда направлять пакет для того адреса

 

Почитал про них вообщем, решение куда направить пакет принимается основываясь на кратчайшем маршруте в той или иной мере, а не load balancing. Те. даже объединив несколько внешних линков провайдеров по BGP, трафик как ходил по 1му (кратчайшему) провайдеру так и будет это делать в 90% случаях...

 

Видится мне это не совсем dynamic load balancing... А для него надо писать кучу правил (скриптец) самому проверяя загрузку внешних каналов и меняя маршрутизацию, которая например предопределена статическими блоками (ISP1, ISP2, etc) типа: если канал ISP1 забит, а ты статически прописан ходить в мир через него, то твоя маршрутизация теперь такая (ISP2), а не стандартная (ISP1), а потом менять все в зад (или не менять). И калибровать например раз в пол-часа, час. И будет каждый час корректировка нагрузки на каналы. Те получается скажем таблица маршрутизации, и скриптец по расписанию скажем раз в час, эту статическую таблицу правит, делая в ней изменения, основываясь на загрузке каналов, и она почти в любой момент времени адекватна. Будет работать?

 

Аппаратно будет выглядить как-то так:

- аплинки ISP заводим в любой роутер с натом, который жует 100мбит, таких в достатке, электричество не экономим, его задача принять инет и отдать его дальше...

- далее с этих роутов заводим линки все в один L3 свич, запрещаем трафик между портами свича (разными ISP)

- в этот же L3 свич втыкаем клиентов (L2 свич с клиентами) на L3 прописываем себе статическую маршрутизацию по портам разных ISP. Первую сотню в ISP1, вторую в ISP2 и тд

- далее в L3 вешаем скриптец, который будет смотреть нагрузну на порту ISPX, и если надо менять для клиентов маршрутизацию, обвновляя скриптом свою таблицу маршрутизации, не трогая маршрутизацю уже поключенных клиентов. Те в момент подключения клиента ему присваеватся маршрутизация и проблема нагрузки + резервации решена, и BGP вообще курить не надо.

 

Так?

Изменено 11 апреля, 2014 пользователем nio_jt

[nnm]

А для него надо писать кучу правил (скриптец) самому проверяя загрузку внешних каналов и меняя маршрутизацию, которая например предопределена статическими блоками (ISP1, ISP2, etc) типа: если канал ISP1 забит, а ты статически прописан ходить в мир через него, то твоя маршрутизация теперь такая (ISP2), а не стандартная (ISP1), а потом менять все в зад (или не менять). И калибровать например раз в пол-часа, час. И будет каждый час корректировка нагрузки на каналы. Те получается скажем таблица маршрутизации, и скриптец по расписанию скажем раз в час, эту статическую таблицу правит, делая в ней изменения, основываясь на загрузке каналов, и она почти в любой момент времени адекватна. Будет работать?

 

Да, только менять нужно будет не таблицу маршрутизации, а конфигурацию policy-based routing. Потому, что в таблице маршрутизации лукапится Destination address, а не source.

И каждый раз, когда Вы будете эту конфигурацию менять, у абонента, который был переправлен в другого ISP, будут рваться активные сессии, скорее всего он будет вылетать из online-игр и т.п. Оно Вам точно надо?

[nio_jt]

И каждый раз, когда Вы будете эту конфигурацию менять, у абонента, который был переправлен в другого ISP, будут рваться активные сессии, скорее всего он будет вылетать из online-игр и т.п. Оно Вам точно надо?

 

Это да, планируется менять конфигурацию только для свеже-подключенных абонентов, те в момент выхода в сеть, решается куда его направить и до момента его ухода из сети его конфигурация не меняется. Надеюсь изменения можно делать без ребута и разрыва существующих сессий, а то ребутить каждый раз - убивает всю идею. И понятно что в случае предоставления внешнего IP и есо смены будет лажа, но у меня все за натом. Погуглю PBR.

 

UP: Нагуглил много по PBR 2 ISP mikrotik. Вроде то что надо, буду курить. Спасибо.

Изменено 11 апреля, 2014 пользователем nio_jt

[mightyscv]

Странно, что никто не вспомнил Cisco BGP link bandwidth.

Но мне кажется это всё оверкилл. Есть же простейший ECMP, и никакого BGP не надо. Управления он, правда, не даёт, но выборочно можно управлять и через PBR(FBF), а при большом количестве потоков(клиентов) ECMP разделит нагрузку близко к идеалу.

[pppoetest]

Надеюсь изменения можно делать без ребута и разрыва существующих сессий, а то ребутить каждый раз - убивает всю идею. И понятно что в случае предоставления внешнего IP и есо смены будет лажа, но у меня все за натом. Погуглю PBR.

Я такое когда-то костылил на ip ru add/del from, +/- было примерно поровну. )))

[nnm]

Странно, что никто не вспомнил Cisco BGP link bandwidth.

Но мне кажется это всё оверкилл. Есть же простейший ECMP, и никакого BGP не надо. Управления он, правда, не даёт, но выборочно можно управлять и через PBR(FBF), а при большом количестве потоков(клиентов) ECMP разделит нагрузку близко к идеалу.

У cisco на программных платформах в ключ балансировки входит Destination IP. Кажется это не выключается. Это значит, что трафик одного абонента, адресованный на разные сервера может пойти через разных ISP. А это значит, что в одном случае его будут натить в пул адресов ISP1 а в другом в ISP2. Это не очень хорошо т.к. какие-то протоколы могут поломаться.

[Negator]

У меня сложилось впечатление что автору не хватает знаний по маршрутизации вообще и о работе bgp. Настраивать его никто не требует, но знание базовых основ не помешает. В общем это обычный опыт. Сильно сомневаюсь что автору необходимо балансировать каналы как он описывает. Наверняка достаточно настроить бгп и несколько аплинков . Далее препендами разрулить трафик как надо. Понятно что рулить можно только исходящим, но влиять на входящий тоже можно. Никаких хитрых скриптов не нужно. Смотрим на загрузки каналов и ковыряем.

[dIMbI4]

Если автор хочет ***ить интернет у провайдера включившись кучей максимальных клиентских тарифов- это печатьно. Если ему отдают кучей потоков честный аплинк- то это печально, но уже не на столько. Думайте с аплинком что делать, бжп, можно по л3 оспф, можно мплс. Тут надо знать все нюансы.

[vlad11]

Если автор хочет ***ить интернет у провайдера включившись кучей максимальных клиентских тарифов- это печатьно.

Это режется кол-вом сессий, ttl=1, размером (или слишком маленьким или большим) окна кадра.

[nio_jt]

У меня сложилось впечатление что автору не хватает знаний по маршрутизации вообще и о работе bgp.

 

Так и есть) Вот изучаю в свободное от работы и не очень время, хобби так сказать) Вот тут по простому и с обилием букв расписано как поделить трафик между провайдерами, статично с переключением между провайдерами http://habrahabr.ru/post/186284/

 

офтоп: зачем ****ить* интернет? На нем можно заработать?) Имхо инет стоит так мало (если ты не в каком-нить ноунейм город, где даилап), что не то что перепродать, а продать его проблема и конкуренция такая что... Что-то мутить стоит если тебе кто-то продал базу жаждущих абонентов на пару так тысяч клиентов. Оборудование, налоги, зарплата и пр, всякие ооо... И самое важное каждый день сидишь боишься, что придет крупный оператор и съест всех твоих абонентов. Лучше уж автомойку) Не?