Идеальная балансировка входящего трафика
Модераторы: Trinity admin`s, Free-lance moderator`s
Идеальная балансировка входящего трафика
Добрый день!
Есть своя автономная система и блок провайдеро-независимых ip адресов /24. Есть два подключения к магистральным провайдерам, дающим full-view. Есть маршрутизатор с BGP (cisco 2921 с 2.5 ГБ памяти). Один канал n мегабит, второй - 3*n мегабит.
Вопрос: Как отбалансировать входящий трафик таким образом, чтобы загрузка каналов была максимально равномерной?
Есть своя автономная система и блок провайдеро-независимых ip адресов /24. Есть два подключения к магистральным провайдерам, дающим full-view. Есть маршрутизатор с BGP (cisco 2921 с 2.5 ГБ памяти). Один канал n мегабит, второй - 3*n мегабит.
Вопрос: Как отбалансировать входящий трафик таким образом, чтобы загрузка каналов была максимально равномерной?
-
- Advanced member
- Сообщения: 507
- Зарегистрирован: 17 апр 2009, 00:49
- Откуда: Yerevan
Re: Идеальная балансировка входящего трафика
Я в этом почти ничего не смыслю , но идея решения должна быть в том, чтобы создать три логических соединения для скоростного канала и потом уже делать балансировку.
В общем, придет and3008 и расскажет.
В общем, придет and3008 и расскажет.
Re: Идеальная балансировка входящего трафика
Наверное, это все-таки из другой оперы
-
- Advanced member
- Сообщения: 507
- Зарегистрирован: 17 апр 2009, 00:49
- Откуда: Yerevan
Re: Идеальная балансировка входящего трафика
Я лучше пока помолчу, вдруг есть рацзерно в сказанном.
А мысль эта возникла из того, что в аналогичной ситуации с VPN тоннелями до филиалов на мой эквивалентный вопрос экперты советовали сделать 3 тоннеля по широкому каналу. Правда, там был OSPF, который сам не могёт...
Черт, вспомнил! Они как раз писали, что BGP (нет, всё-таки EIGRP!?) такое может сам, а в моей ситуации надо делать три тоннеля. Вот отсюда и ноги растут.
А мысль эта возникла из того, что в аналогичной ситуации с VPN тоннелями до филиалов на мой эквивалентный вопрос экперты советовали сделать 3 тоннеля по широкому каналу. Правда, там был OSPF, который сам не могёт...
Черт, вспомнил! Они как раз писали, что BGP (нет, всё-таки EIGRP!?) такое может сам, а в моей ситуации надо делать три тоннеля. Вот отсюда и ноги растут.
Re: Идеальная балансировка входящего трафика
Вы не можете непосредственно влиять на входящий трафик. Можете влиять только косвенно. В BGP есть несколько атрибутов, которые косвенно влияют на "длину пути" к автономной системе. Атрибуты эти опциональные и могут не рассматриваться другими роутерами при выборе маршрута. Про OSPF забудьте. Провайдеры только по BGP будут с вами работать.
Full View вам не сделает погоды, т.к. он вам позволит только более эффективно передать исходящий трафик, т.е. по более короткому маршруту. Короткому в терминах и единицах расстояния протокола BGP, а не по географическому принципу.
Входящим трафиком можно попробовать косвенно рулить методом отправки исходящих пакетов по разным каналам. Но тут опять свои подводные камни. VoIP и всякое TV не любит такую асимметрию. Могут вылезти и другие косяки.
Некоторое время назад мне попадалась какая-то статья, где человек как-то это побеждал и добивался определенных успехов. Попробую найти... Там по моему на NAT это было завязано + балансировка исходящего трафика в разные каналы. Да, да... Именно так.
Идея была в том, чтобы через разные каналы к провайдеру анонсить свои диапазоны сетей. Типа /25 на одного, /25 на другого. Исходящий трафик кидать в процентом соотношении к пропускной способности. Типа первый запрос в один канал, второй - пятый в другой, шестой опять в первый и так по кругу.
Благодаря тому, что исходящий трафик пройдет через NAT, а поскольку на каждого провайдера анонсится свой диапазон, то ответ на исходящий трафик вернется по этому же каналу. Это не спасет от ситуации "хочу скачать по FTP" со скоростью n*мбит+m*мбит. Качаться будет со скоростью либо n*мбит, либо m*мбит. Но при достаточно большом числе клиентов нагрузить каналы более-менее равномерно вполне себе получится. Особенно для торрент-качателей должно быть неплохо.
Идея ясна? В той статье, что я говорил это было сделано на Линуксе + iptables + некие фичи к нему. Как сделать это на Цисках я пока не знаю, но идея интересная...
Добавка: такое прокатит только для TCP-соединений. UDP можно сделать только если анализировать трафик на более высоком уровне. С TCP все просто, установилась TCP-сессия, создали под нее контекст и только при проходе трафика ее статус обновляй, да при превышении тайм-аута (более 5 минут отсутствия трафика) удаляй. А вот с UDP требуется анализ "шо цэ такэ, а где начало, где конец и будет ли чего по середине". И если характер UDP-шного трафика неизвестный, то лихой финт ушами сделать не получится, придется пускать по одному маршруту. Про торренты я видимо наврал получается...
Full View вам не сделает погоды, т.к. он вам позволит только более эффективно передать исходящий трафик, т.е. по более короткому маршруту. Короткому в терминах и единицах расстояния протокола BGP, а не по географическому принципу.
Входящим трафиком можно попробовать косвенно рулить методом отправки исходящих пакетов по разным каналам. Но тут опять свои подводные камни. VoIP и всякое TV не любит такую асимметрию. Могут вылезти и другие косяки.
Некоторое время назад мне попадалась какая-то статья, где человек как-то это побеждал и добивался определенных успехов. Попробую найти... Там по моему на NAT это было завязано + балансировка исходящего трафика в разные каналы. Да, да... Именно так.
Идея была в том, чтобы через разные каналы к провайдеру анонсить свои диапазоны сетей. Типа /25 на одного, /25 на другого. Исходящий трафик кидать в процентом соотношении к пропускной способности. Типа первый запрос в один канал, второй - пятый в другой, шестой опять в первый и так по кругу.
Благодаря тому, что исходящий трафик пройдет через NAT, а поскольку на каждого провайдера анонсится свой диапазон, то ответ на исходящий трафик вернется по этому же каналу. Это не спасет от ситуации "хочу скачать по FTP" со скоростью n*мбит+m*мбит. Качаться будет со скоростью либо n*мбит, либо m*мбит. Но при достаточно большом числе клиентов нагрузить каналы более-менее равномерно вполне себе получится. Особенно для торрент-качателей должно быть неплохо.
Идея ясна? В той статье, что я говорил это было сделано на Линуксе + iptables + некие фичи к нему. Как сделать это на Цисках я пока не знаю, но идея интересная...
Добавка: такое прокатит только для TCP-соединений. UDP можно сделать только если анализировать трафик на более высоком уровне. С TCP все просто, установилась TCP-сессия, создали под нее контекст и только при проходе трафика ее статус обновляй, да при превышении тайм-аута (более 5 минут отсутствия трафика) удаляй. А вот с UDP требуется анализ "шо цэ такэ, а где начало, где конец и будет ли чего по середине". И если характер UDP-шного трафика неизвестный, то лихой финт ушами сделать не получится, придется пускать по одному маршруту. Про торренты я видимо наврал получается...
Re: Идеальная балансировка входящего трафика
В общем виде проблему мы решили. Все суровее на самом деле. Анонсы route objects мельче, чем /24 провайдеры игнорируют, чтобы размер full-view был меньше. Пути входящего трафика и исходящего ни как между собой не связаны.
Есть три способа влияния на путь входящего трафика:
1. Фильтрация. Если я на одном из интерфейсов зафильтрую какие-то сети, то трафик пойдет через другой, т.к. доступность является самым главным критерием при выборе маршрута. Например: фильтруя по маске 127.255.255.255 на одном из интерфейсов я могу заставить входящий трафик с половины адресов пилить через другой канал. Это единственный способ прямого влияния на входящий трафик.
2. Добавление AS-prepend. Добавляя "виртуальные" автономные системы на одном из линков мы искусственно удлиняем путь до нас через одного из провайдеров, что перекашивает трафик в сторону второго.
3. Используя community, предоставляемые провайдерами. Механизм тот же, что и в п.2, но несколько более гибок, т.к. в community обычно прописаны самые "мясные" ресурсы (вконтактег, youtube и т.п.). Благодаря этому механизму можно удлиннять, либо вообще блокировать путь до "мясных" автономок через провайдеров.
Изначально нам не повезло: наш основной провайдер гнал трафик через нашего второго провайдера ) Поэтому делать балансировку препендами было бесполезно: +1/-1 препенд поворачивал 99% трафика в сторону одного или другого провайдера. Затем мы заменили основного провайдера на еще одного магистральщика, благодаря чему даже без каких-то приседаний трафик разползался более-менее равномерно, и тупо добавляя препенды мы смогли добиться балансировки в примерно нужном соотношении.
Так что в общем виде задача уже была решена к моменту, когда я задавал вопрос Интересовало же меня в большей степени другое: меня интересовало, используют ли провайдеры какие-то умные системы, которые анализируют источники\назначения входящего и исходящего трафика, сверяют с full-view и генерируют препенды\фильтры\комьюнити для той самой "идеальной" балансировки. Разговаривали с местными провайдерами - ни кто не признался Предлагали подбирать препенды для комьюнити чуть ли не перебором
Есть три способа влияния на путь входящего трафика:
1. Фильтрация. Если я на одном из интерфейсов зафильтрую какие-то сети, то трафик пойдет через другой, т.к. доступность является самым главным критерием при выборе маршрута. Например: фильтруя по маске 127.255.255.255 на одном из интерфейсов я могу заставить входящий трафик с половины адресов пилить через другой канал. Это единственный способ прямого влияния на входящий трафик.
2. Добавление AS-prepend. Добавляя "виртуальные" автономные системы на одном из линков мы искусственно удлиняем путь до нас через одного из провайдеров, что перекашивает трафик в сторону второго.
3. Используя community, предоставляемые провайдерами. Механизм тот же, что и в п.2, но несколько более гибок, т.к. в community обычно прописаны самые "мясные" ресурсы (вконтактег, youtube и т.п.). Благодаря этому механизму можно удлиннять, либо вообще блокировать путь до "мясных" автономок через провайдеров.
Изначально нам не повезло: наш основной провайдер гнал трафик через нашего второго провайдера ) Поэтому делать балансировку препендами было бесполезно: +1/-1 препенд поворачивал 99% трафика в сторону одного или другого провайдера. Затем мы заменили основного провайдера на еще одного магистральщика, благодаря чему даже без каких-то приседаний трафик разползался более-менее равномерно, и тупо добавляя препенды мы смогли добиться балансировки в примерно нужном соотношении.
Так что в общем виде задача уже была решена к моменту, когда я задавал вопрос Интересовало же меня в большей степени другое: меня интересовало, используют ли провайдеры какие-то умные системы, которые анализируют источники\назначения входящего и исходящего трафика, сверяют с full-view и генерируют препенды\фильтры\комьюнити для той самой "идеальной" балансировки. Разговаривали с местными провайдерами - ни кто не признался Предлагали подбирать препенды для комьюнити чуть ли не перебором
Re: Идеальная балансировка входящего трафика
2diz
К сожалению, указанный способ не будет оказывать влияние на входящий поток, таким способом можно управлять исходящим трафиком при условии получения FullView от провайдеров.1. Фильтрация. Если я на одном из интерфейсов зафильтрую какие-то сети, то трафик пойдет через другой, т.к. доступность является самым главным критерием при выборе маршрута. Например: фильтруя по маске 127.255.255.255 на одном из интерфейсов я могу заставить входящий трафик с половины адресов пилить через другой канал. Это единственный способ прямого влияния на входящий трафик.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 14 гостей