Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Настройка
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Форум
    RouterOS
    Балансировка нагрузки за 2.28 секунды, всего 3 строки.

    Балансировка нагрузки за 2.28 секунды, всего 3 строки.

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Балансировка нагрузки за 2.28 секунды, всего 3 строки., RouterOS
     
    galaxynet
    Guest
    #1
    0
    19.07.2005 03:53:00
    У меня есть 3 линии T-1. Каждая с классом /27 (30 IP-адресов) на каждой. У меня есть адрес шлюза для каждой линии T-1. Все 90 IP-адресов могут быть маршрутизированы через любую из 3 линий T-1. Все шлюзы имеют разные IP-адреса. В моем случае все три шлюза имеют один и тот же MAC-адрес. Все три линии T-1 проходят через маршрутизаторы Cisco 2600, затем через коммутатор Cisco, затем к маршрутизатору MT. У MT есть две платы интерфейсов, одна для внутренней локальной сети и одна для интернет-пространства IP. На стороне интернета сетевая карта NIC имеет три публичных IP-адреса, которые указывают на три линии T-1. Внутренняя NIC (LAN) имеет один IP-адрес. Работает хорошо — все серверы, которые NAT’ированы (как источник, так и назначение), не испытывают трудностей при подключении к Интернету, пользователям нет проблем при подключении к серверам из Интернета... Masq или только src NAT — именно здесь эта конфигурация сталкивается с проблемами. У меня есть Masq'ed (в прошлом) и теперь src NAT'ированы около 50 рабочих станций за MT и src NAT'ированы в блок из 10 IP-адресов, т.е. xxx.xxx.xxx.10 - xxx.xxx.xxx.20. Это будет работать до тех пор, пока нагрузка на трех линиях T-1 относительно невысока (30% или меньше), при более высокой, скажем, 40% мощности, src NAT'ированные только рабочие станции, кажется, зависают или очень долго загружают веб-страницы... Я могу перейти к любой из полностью NAT'ированных станций, и этого не происходит — хотя иногда я получаю кратковременную "зависание", очень кратковременную, как секунда или две, и только при нагрузке на линии T-1 выше 75% (мне приходится заставлять линии проталкивать столько данных, используя тестер полосы пропускания), и затем она не "зависает" снова — это я ожидаю, что это от того, что DNS тратит некоторое время, чтобы получить запрос и ответ, прежде чем фактически перейти к IP-адресу из-за нагрузки на все линии T-1... ЦП — 2,4 ГГц, 512 МБ памяти, 40 ГБ жесткого диска. Я вижу загрузку ЦП MT максимум 25%, обычно MT "ездит" на 3% с пиками от 6-8% время от времени. Я запустил внешнюю программу mtr (Linux Multi Trace Route) и получил менее 1% потерь пакетов при ЛЮБОМ соотношении нагрузки на линии T-1 и на трех адресах в Интернет-NIC маршрутизатора MT. Итак — у вас, умных ребят, есть какие-нибудь идеи, потому что я в тупике... Thom
     
     
     
    jober
    Guest
    #2
    0
    19.07.2005 20:27:00
    Все линии T1 у одного провайдера? Если да, то вы уже говорили с ними о связывании линий T1, чтобы вам приходилось заниматься только регулировкой пропускной способности на MT?
     
     
     
    changeip
    Guest
    #3
    0
    19.07.2005 20:33:00
    Как насчёт того, чтобы обойти эти Cisco и сразу подключать T1 к MT? Может, и не решение, но точно сделает всё более компактным и быстрым. 2600-е как патока, на мой взгляд. Сэм.
     
     
     
    galaxynet
    Guest
    #4
    0
    19.07.2005 21:05:00
    Я забыл добавить для вас придирчивых, которые сверяются с инструкцией… У меня есть RTFM. Я использую MT уже около двух лет, и только недавно перешел на три линии (апрель 2005), которые на первый взгляд работали очень хорошо… Все T-1 от одной компании… Соединение сейчас не вариант для этих линий. К тому же, я не думаю, что обрыв линий в MT решит проблему – конечно, в серверной будет "почище". Я использовал правила маршрутизации и управление полосой пропускания, чтобы хоть как-то упорядочить маршруты, но это лишь временное решение и не позволяет использовать всю доступную полосу пропускания. Я видел упоминания о том, что у других это работает, но никогда не видел четкого, окончательного ответа – только "я решил" или "благодаря "КОМУ-ТО" у меня получилось". Так что, если кто-то действительно знает ответ, пожалуйста, опубликуйте его или отправьте мне на почту – thom@airwhidbey.com
     
     
     
    changeip
    Guest
    #5
    0
    19.07.2005 21:22:00
    Если тебе нужны советы по очистке правил брандмауэра и настройке очередей трафика для повышения эффективности, выложи конфигурации для анализа. Без понимания того, как у тебя все настроено, попытки определить причину проблемы – это как стрелять в темноте. "У меня был Source Masq’d (в прошлом), а сейчас src NAT для примерно 50 станций стоит за MT и я настроил src NAT для них на блок из 10 IP-адресов, например, xxx.xxx.xxx.10 - xxx.xxx.xxx.20." ← у тебя 1-1 NAT или что-то другое? Если у тебя только 10 IP-адресов, а 50 пользователей пытаются получить 1-1, это может быть частью проблемы. Сэм
     
     
     
    galaxynet
    Guest
    #6
    0
    20.07.2005 00:52:00
    Нет, это не 1-в-1 NAT. Это строго SRC NAT с диапазоном из 10 IP-адресов на выбор. У меня та же проблема, когда они маскируются. Как я уже говорил, эта конфигурация отлично работала с двумя линиями, но с третьей линией, ‘round-robin’ внешний шлюз вызывает проблемы с загрузкой, причем больше на одной линии, чем на остальных. То есть, мои исходящие запросы, кажется, теряются, или возвращающиеся соединения не могут ‘найти’ начальное соединение… Конфигурация простая: внутренняя сеть 192.168.0.0/16, Интернет – один NIC - xxx.xxx.146.98/24, шлюз xxx.xxx.146.1, xxx.xxx.94.18/30, шлюз xxx.xxx.94.17, xxx.xxx.80.110/30, шлюз xxx.xxx.80.109, NAT – у меня несколько 1-в-1 NAT (как SRC, так и DST) для серверов за MT – там вроде бы проблем нет… SRC NAT только (или маскированный) 192.168.2.XXX на xxx.xxx.80.20 - .30. Здесь и возникает проблема… Брандмауэр – простая настройка, только несколько заблокированных IP-адресов и портов – те же, что я использовал уже два года… Могу выложить конфиг, если вышеприведённого недостаточно… Thom
     
     
     
    mp3turbo2
    Guest
    #7
    0
    20.07.2005 05:45:00
    Galaxynet, думаю, что policy routing вам особо не поможет, потому что придется очень тщательно разделять разные типы трафика и прогонять их через три линии. Я не представляю, как можно идеально и безупречно оценить трафик и использовать все три линии на максимум, не перегрузив при этом хотя бы одну из них или не недогрузив. Вопрос: пробовали использовать несколько шлюзов по умолчанию (ECMP)? Я лично никогда не пробовал, но время идет. Если делать что-то вроде /ip route, добавлять gateway=first-gateway,second-gateway,third-gateway, Mikrotik должен отправлять трафик по этим линиям по кругу, равномерно распределяя нагрузку. Я не знаю, насколько это хорошо для вас, но хотя бы можете попробовать. И, пожалуйста, потом напишите нам, спасибо, mp3turbo.
     
     
     
    sten
    Guest
    #8
    0
    20.07.2005 09:29:00
    Если вам нужна "идеальная" балансировка пакетов, возможно, стоит заменить 2600 на более мощное устройство с тремя картами последовательных интерфейсов (предположительно) и пусть Cisco занимается балансировкой нагрузки, а формирование/NAT оставляете RouterOS. RouterOS базируется на Linux, насколько я знаю, форвардинг и фастфорвардинг в Linux – это одно и то же, из-за чего при балансировке по маршрутам вы не получите гранулярность пакетов. И помните, что ваша задержка никогда не будет лучше, чем у одного T1, в то время как у настоящего соединения на 4,5 Мбит скорость задержки соответствует скорости этого соединения на 4,5 Мбит. Что, вероятно, сделает достижение эффективности выше 75% (особенно на фастфорвардинговом соединении!) крайне сложным.
     
     
     
    galaxynet
    Guest
    #9
    0
    20.07.2005 10:59:00
    Ребята, спасибо - я понял, что “туда не добраться отсюда”, так что придется работать с провайдером связи, чтобы изменить маршрутизацию данных внутрь и наружу. Будет больно… Я понимаю про задержки - с тем темпом, с которым мы растём, через 6 месяцев дойдем до T-3, и это, вероятно, решит проблему с отдельными каналами всё равно - но сначала нужно до этого дойти!
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры