+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Балансировка нагрузки T1/Трафик.

Балансировка нагрузки T1/Трафик., RouterOS

hci

Guest

25.04.2006 23:01:00

У меня есть 3 T1 и скоро будет 4, и я хочу равномерно распределить трафик между ними. ACC неплохо справляется со своей задачей и равномерно распределяет пакеты между моими 3 T1, чтобы я мог скачивать 4.5 мб/с по одной линии. Сейчас я использую 3 шлюза, перечисленные в одном маршруте, но это только на уровне сессии и не позволяет одной загрузке превышать 1.5 мб/с. Поэтому я пытаюсь настроить маршрутную маркировку. Вот что я сделал пока:
/ ip firewall mangle add chain=prerouting in-interface=local action=mark-routing new-routing-mark=cyclades1 passthrough=yes comment=“” disabled=no
add chain=prerouting in-interface=local random=50 action=mark-routing new-routing-mark=cyclades2 passthrough=yes comment=“” disabled=no
add chain=prerouting in-interface=local random=33 action=mark-routing new-routing-mark=cyclades3 passthrough=yes comment=“” disabled=no
add chain=output action=mark-routing new-routing-mark=cyclades1 passthrough=yes comment=“” disabled=no
add chain=output random=50 action=mark-routing new-routing-mark=cyclades2 passthrough=yes comment=“” disabled=no
add chain=output random=33 action=mark-routing new-routing-mark=cyclades3 passthrough=yes comment=“” disabled=no
В теории я должен маркировать все пакеты примерно на 33% как "cyclades1", "cyclades2" или "cyclades3". Не так ли?
/ ip route add dst-address=10.0.0.0/16 pref-src=0.0.0.0 gateway=12.4.3.3 distance=1 scope=255 target-scope=10 comment=“” disabled=no
add dst-address=0.0.0.0/0 gateway=12.12.18.157 distance=1 scope=255 target-scope=10 routing-mark=cyclades1 comment=“” disabled=no
add dst-address=0.0.0.0/0 gateway=12.12.18.161 distance=1 scope=255 target-scope=10 routing-mark=cyclades2 comment=“” disabled=no
add dst-address=0.0.0.0/0 gateway=12.12.18.165 distance=1 scope=255 target-scope=10 routing-mark=cyclades3 comment=“” disabled=no
Теперь я должен отправлять трафик, основываясь на маршрутной маркировке, что должно равномерно распределять его между всеми T1. Каждый раз, когда я включаю все 3 маршрута, я больше не могу пинговать ничего в интернете. Почему это не работает? Что у меня не так? Было бы здорово, если бы у Mikrotik была опция в маршруте с несколькими шлюзами для выбора между "на каждый пакет" или "на каждую сессию" балансировкой нагрузки. Тогда бы мне не пришлось этим заниматься. Так работает маршрутизатор Cisco, насколько я понимаю. Спасибо.
Мэтью

hci Guest	#2 0 26.04.2006 22:31:00 Наверное, я единственный, кто до сих пор использует T1-каналы или что-то вроде того. В Cisco это просто добавьте "ip load-sharing per-packet" в конфигурацию T1, чтобы равномерно распределять трафик по каналам T1. Мэттью.

eflanery

Guest

27.04.2006 00:37:00

На самом деле, я думаю, что дело в том, что PPLB — это огромный клубок проблем, с которым никто (включая меня) не хочет связываться. Часто он не работает так, как ожидается, и усложняет поиск и устранение неисправностей. Потенциальные осложнения и проблемы многочисленны и могут превратиться в огромные «пожиратели времени». Даже в Cisco, это редко делают (по крайней мере, на интерфейсах такого типа), из-за сопутствующих проблем. Единственный способ объединить T-1 таким образом, чтобы один поток использовал все их и при этом давал стабильные и желаемые результаты — это IMA (что, очевидно, невозможно с MT на текущий момент). Даже с ML-PPP (которая, если я правильно помню, должна появиться в 2.10), лучше держать отдельные потоки на одной ссылке. Кроме того, большинство опций в драйверах объединения, похожих на Ethernet, не пытаются использовать PPLB, а те, что это делают, неизменно оказываются самыми проблемными. Попытка сделать это с использованием системы политического маршрутирования — это просто приглашение к неприятностям, по моему мнению. Если же вы настаиваете, то начните с определения того, как вы ожидаете, чтобы входящий PPLB работал, то есть как ваш провайдер будет распределять нагрузку между вашими ссылками? Работайте с ними, чтобы определить, как вам следует действовать. Также убедитесь, что вы не пытаетесь выполнять отслеживание соединения или NAT на устройстве, выполняющем балансировку, это наверняка разрушит любой план PPLB. Удачи, она вам понадобится, — Eric.

hci

Guest

27.04.2006 05:16:00

Понял я так, что распределение нагрузки на уровне пакетов менее затратно по CPU, чем распределение нагрузки на уровне соединения. В случае с пакетами отслеживать соединения вообще не нужно, используется простой счетчик, чтобы отправлять пакеты поочередно на разные порты. Года три назад я говорил одному технаре из AT&T, который настраивал канал, что слышал (на самом деле на рассылке Mikrotik) о том, что CEF или распределение нагрузки на уровне пакетов может вызвать проблемы. Он сказал, что они настраивают роутеры по всему миру таким образом и у них проблем нет. Вообще, единственное место, где я видел, что это даёт сбой, - это VoIP, и в этом случае просто нужно увеличить размер буфера джиттера, чтобы обрабатывать случайные пакеты, приходящие не по порядку. Кстати, с ML-PPP я не думаю, что можно удержать один поток на одной линии, так как каждый пакет разбивается между ссылками. Matthew

changeip

Guest

27.04.2006 06:04:00

Наверное, работает в большинстве случаев, потому что с обеих сторон Cisco, и они просто справляются с этим, верно? Если бы с обеих сторон был Mikrotik, можно было бы использовать bonding для того же, я думаю… хотя не на 100%. Sam

eflanery

Guest

27.04.2006 19:31:00

Если создавать EoIP туннели, которые проходят через каждый T1, и связывать их с помощью rr планировщика, то да, должно работать. Поскольку у T1 обычно большие MTU, можно избежать фрагментации и сопутствующего снижения производительности. Но я бы с этим связываться не стал. Поэтому убедитесь, что отслеживание соединений отключено, как и всё, что от него зависит. Дело не столько в нагрузке на ЦП (особенно на Cisco, где часть можно переложить на ASIC), если у вас приличный девайс. Важно, чтобы у него был хороший запас мощности, чтобы пакет, выходящий через один интерфейс, не задерживался на 3 мс, а пакет, выходящий через другой интерфейс, — только на 1 мс. Большинство проблем с PPLB связаны с доставкой пакетов не по порядку, если найти способ этого избежать, то всё будет хорошо работать. Моё понимание ML-PPP может быть немного устаревшим (очень большие фрейм-релейные MTU), но если я правильно помню, пакеты полностью инкапсулируются внутри одного PPP-кадра. Несколько пакетов внутри потока, безусловно, могут быть распределены по нескольким каналам. Однако с IMA, скорее всего, один пакет распределяется по нескольким интерфейсам из-за 50-байтового нативного сотового MTU. –Эрик

butche

Guest

27.04.2006 19:38:00

Это верно (в некотором роде). Mikrotik в данный момент не имеет поддержки балансировки нагрузки на уровне пакетов в "стандартном" виде. MLPPP – это ваш лучший вариант, но он пока недоступен. Если у вас Mikrotik с обеих сторон, вы можете использовать bonder и получить желаемый результат. Год назад я говорил технику AT&T, настраивающему канал, что слышал (на самом деле, на рассылке Mikrotik) что CEF или балансировка нагрузки на уровне пакетов может вызвать проблемы. Он сказал, что они настраивают маршрутизаторы по всему миру именно так и без проблем. Фактически, единственная область, где я видел, что это вызывает проблемы, – это VoIP, и в этом случае нужно просто увеличить буфер джиттера, чтобы справиться с периодически приходящими пакетами в неправильном порядке. CEF – это не решение для всех. Как и многие другие решения "обходных путей", оно не идеально и может вызвать потенциальные проблемы. Но, тем не менее, это лучше, чем ничего. Вам нужен тип протокола, который "стандартизирован", чтобы вы могли получить выгоду от полной пропускной способности вверх и вниз. Лучший способ сделать это СЕГОДНЯ — поставить Cisco с достаточным количеством портов T1 и позволить Cisco обрабатывать агрегацию. В качестве альтернативы можно поставить IMAGESTREAM (лучший выбор, на мой взгляд) и позволить ему общаться с Cisco на другом конце. Единственный другой вариант, который я вижу, — это поставить MT с обеих сторон интерфейсов T1 и использовать bonder. Этот последний вариант маловероятен, но вот так. Кстати, с ML-PPP, я не думаю, что возможно сохранить один поток на одной линии, поскольку каждый пакет разделяется между линиями. MLPPP будет использовать отдельные каналы, как будто это один канал. Есть небольшие накладные расходы на это, но MLPPP — это стандартный протокол, и вы сможете использовать его с Mikrotik, разговаривающего с Cisco. Не тот ответ, который вы хотели услышать, но если я чего-то не упустил, это единственный ответ, который вы получите.

csickles Guest	#8 0 27.04.2006 22:45:00 Посмотри это… http://forum.mikrotik.com/viewtopic.php?t=4300&start=0&postdays=0&postorder=asc&highlight=sbe+t1. Просто экспериментировал… Вот что заставляет задуматься… Крейг.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры