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

RouterOs 6.25: как управлять двумя разными ADSL

RouterOs 6.25: как управлять двумя разными ADSL, RouterOS

Hyde

Guest

24.02.2015 14:27:00

Всем привет, это мой первый пост здесь, так что привет всем! Впервые использую RouterBox с RouterOs 6.25. Вот моя конфигурация: Порт 1: WAN с подключением по PPoE Порт 2: LAN с включённым DHCP Порт 3: второй WAN для ADSL (подключён к внешнему модему). Сейчас мой LAN использует порт 1 для интернета. Моя цель — настроить плату так, чтобы балансировать трафик между портами 1 и 3, чтобы улучшить производительность и чтобы в случае отключения одного из соединений второй продолжал работать. Честно говоря, я не знаю, с чего начать... Я, конечно, не хочу пошаговую инструкцию, мне просто нужны какие-то советы, чтобы начать. Заранее спасибо!

Hyde Guest	#2 0 10.03.2015 21:28:00 Кроме того, как устранять неполадки PCC?

Rudios

Guest

11.03.2015 08:00:00

Теоретически трафик будет разделён на две группы, отмеченные routing-mark. Эти routing-mark будут использоваться таблицей маршрутизации для передачи трафика через один из доступных ADSL-линий. У меня настроен PCC для трёх ADSL-линий, и есть 9 правил маршрутизации — по три на каждую линию, каждое с увеличивающейся метрикой (distance). Если используется check-gateway=ping, то правило маршрутизации будет неактивным, если шлюз недоступен; когда маршрут с меньшей метрикой станет неактивным, будет использовано следующее правило — через другой шлюз.

Hyde Guest	#4 0 11.03.2015 08:38:00 Можешь привести пример своих правил маршрутизации? Просто я следовал пошаговой инструкции с wiki-страницы PCC, но что-то не работает, и у меня нет доступа в интернет...

inquiery

Guest

11.03.2015 12:37:00

Здравствуйте, я изучал пример с PCC и, хотя понял основы и функционал, меня заинтересовала сложность правил. Во-первых, нельзя ли заменить все эти mangle-правила и сразу ставить метки маршрутизации прямо в правилах, связанных с PCC, вот так:

/ ip firewall mangle
add chain=prerouting dst-address=10.111.0.0/24 action=accept in-interface=LAN
add chain=prerouting dst-address=10.112.0.0/24 action=accept in-interface=LAN
add chain=prerouting in-interface=LAN per-connection-classifier=both-addresses:2/0 action=mark-routing new-routing-mark=to_ISP1
add chain=prerouting in-interface=LAN per-connection-classifier=both-addresses:2/1 action=mark-routing new-routing-mark=to_ISP2

Почему это не сработает? С другой стороны, учитывая настройки из примера, я не понимаю, зачем в цепочке output ставятся метки маршрутизации, если они уже применены в prerouting. Мне сложно разобраться с цепочками. Если кто-то сможет объяснить подробнее, это очень поможет мне лучше понять весь процесс. Объяснения в примере довольно общие. Всем заранее спасибо за вашу отличную работу, доброту и за то, что вы такие замечательные!

Rudios

Guest

13.03.2015 13:57:00

Маркировка каждого пакета непосредственно маршрутизирующей меткой, скорее всего, сработает, но потребует, чтобы все пакеты проходили через критерии отбора. Это занимает больше ресурсов, чем сначала пометить соединение, а затем, в зависимости от метки соединения, установить маршрутизирующую метку. С другой стороны, предполагаю, что это также помогает решить проблему, когда соединение (сессия) к определённому адресу идёт по двум разным маршрутам, что может вызывать проблемы с соединением.

Что касается правил в цепочке output, у меня такие же сомнения, как и у вас. У меня всё работает как надо, когда устройства подключены за RouterBoard, который управляет механизмом PCC, но я всё ещё не нашёл правильного способа обрабатывать соединения, идущие непосредственно с самого RouterBoard.

Странным мне показалось то, что если пакет создаётся на роутере, первым делом происходит решение о маршруте (согласно блок-схеме). Но если нет маршрутов без выбора по маршрутизирующей метке, то для этого пакета нет доступного маршрута, и он просто исчезает, потому что некуда его направлять. Мне кажется, что когда пакет создаётся на роутере, он сначала проходит через цепочку prerouting, где можно присвоить метку пакетам.

inquiery

Guest

13.03.2015 17:18:00

Хм, мне сложно понять этот поток трафика. Когда ты говоришь, что все пакеты должны проходить через критерии отбора, ты имеешь в виду, что им придется пройти через все правила в mangle? Разве это не так в примере с PCC на вики? Когда я смотрю на эту схему потока трафика, по какой-то причине у меня не получается уловить в этом логику. Похоже, мне стоит поискать больше материалов по этой теме в гугле. Ты знаешь какие-нибудь хорошие источники для изучения?

ZeroByte Guest	#8 0 13.03.2015 17:32:00 Я был на этой презентации еще в 2012 году, и там очень хорошо объясняли такие вещи. http://mum.mikrotik.com/presentations/US12/tomas.pdf

inquiery

Guest

13.03.2015 20:22:00

Спасибо, ZeroByte, это было полезно. Я еще поищу материалы, чтобы получше понять цепочки и разобраться с потоком трафика более логично. На самом деле, я собираюсь придумать другой сценарий по той же проблеме, но с двумя разными линиями — и на этот раз они будут использовать один и тот же удалённый IP-адрес.

Допустим, у меня есть два бриджевых модема, подключённых к routerboard: один на ether1, другой на ether2. Потом я создаю два pppoe клиентских интерфейса — по одному для каждого порта. После настройки pppoe клиентских интерфейсов и подключения кабелей к модемам оба подключатся к удалённому pppoe серверу, и создадутся два маршрута, по одному на каждый интерфейс. Проблема в том, что у обоих pppoe клиентов будет один и тот же удалённый IP-адрес.

Есть ли способ перенаправить трафик на выбранный pppoe клиентский интерфейс? Чтобы я мог распределять нагрузку по трафику так, как хочу?

Hyde

Guest

#10

13.03.2015 20:32:00

Всем привет! Я настроил ROS для использования PCC, как описано на странице вики PCC. Столкнулся с одной проблемой — это не работает с прозрачным прокси ROS, но на данный момент это не принципиально. Главное сейчас — понять, что я сделал. Я прочитал презентацию, ссылку на которую давали выше, и не настроил мониторинг трафика. Первый вопрос: он обязателен? Если я его не настраиваю, по какому правилу происходит переключение между двумя WAN? Второй вопрос касается failover. Я проверил его работу, отключив кабель одного из соединений, и оно работает. Но, читая pdf от ZeroByte, понимаю, что это не настоящий failover. То есть, если GW доступен, но интернет не работает, потому что сломано соединение между GW и интернетом, failover не сработает. Это так? Если да, стоит ли менять маршруты с пометками на внешний IP (например, google), а не на GW?

ZeroByte Guest	#11 0 16.03.2015 15:18:00 Это правда. Это означает, что шлюз доступен. Но это не значит, что шлюз изолирован от Интернета. Вместо того чтобы пинговать шлюз, сделайте так: настройте статический маршрут /32 к test_site_1 через дефолтный шлюз ISP1. Статический маршрут /32 к test_site_2 через дефолтный шлюз ISP2. Пинги к test_site_1 и test_site_2 теперь будут принудительно идти через ISP1 и ISP2 соответственно. В конфигурации резервирования указывайте в параметрах дефолтного шлюза адреса TEST_SITE_X, а не адреса дефолтных шлюзов. Убедитесь, что при отказе ISP1 до его восстановления пинговать test_site_1 НЕВОЗМОЖНО. Для этого можно в разных маршрутах с дефолтным шлюзом указать gateway=pppoe1 и gateway=pppoe2 (используйте имена интерфейсов). PPP-сессии — это не широковещательный канал, поэтому использовать их как следующий хоп вполне корректно.

Читают тему

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