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

Недействительные маршруты.

Недействительные маршруты., RouterOS

savage

Guest

18.01.2005 12:45:00

Случайно никто не знает, почему MT считает этот маршрут недействительным?? [admin@wsmd-core] > ip route add dst-address=196.0.0.0 netmask=255.0.0.0 gateway=165.146.240.231
[admin@wsmd-core] > ip route print
Flags: X - disabled, I - invalid, D - dynamic, J - rejected, C - connect, S - static, r - rip, o - ospf, b - bgp
DST-ADDRESS G GATEWAY DISTANCE INTERFACE
0 S 0.0.0.0/0 r 198.19.0.2 1 SERVER-CORE
1 IS 196.0.0.0/8 u 165.146.240.231 1 (unknown)
2 DC 198.19.1.0/24 r 0.0.0.0 0 WIRELESS-CORE
3 Ib 198.19.0.0/24 u 0.0.0.0 200 (unknown)
4 DC 198.19.0.0/24 r 0.0.0.0 0 SERVER-CORE
5 DC 192.168.1.0/24 r 0.0.0.0 0 INTERNAL-CORE
6 DC 165.146.192.1/32 r 0.0.0.0 0 National Gateway
[admin@wsmd-core] > The default route идет через ethernet интерфейс, а статический маршрут, который я пытаюсь добавить, идет через PPPoE соединение… Ну, должно же это работать!!!
Интерфейсы и адреса:
[admin@wsmd-core] > interface print
Flags: X - disabled, D - dynamic, R - running
NAME TYPE RX-RATE TX-RATE MTU
0 R SERVER-CORE ether 0 0 1500
1 R WIRELESS-CORE ether 0 0 1500
2 R INTERNAL-CORE ether 0 0 1500
3 R National Gateway pppoe-out 0 0 1380
[admin@wsmd-core] > ip address print
Flags: X - disabled, I - invalid, D - dynamic
ADDRESS NETWORK BROADCAST INTERFACE
0 192.168.1.1/24 192.168.1.0 192.168.1.255 INTERNAL-CORE
1 198.19.0.1/24 198.19.0.0 198.19.0.255 SERVER-CORE
2 198.19.1.1/24 198.19.1.0 198.19.1.255 WIRELESS-CORE
3 D 165.146.240.231/32 165.146.192.1 0.0.0.0 National Gateway

Eugene Guest	#2 0 18.01.2005 13:48:00 http://www.mikrotik.com/docs/ros/2.8/guide/aaa.content#13.4.8 смотри параметр routes. Евгений

savage

Guest

18.01.2005 13:55:00

Если бы это было входящее PPPoE-соединение, я бы посмотрел AAA Routes. К сожалению, это исходящее соединение (извините за неясность). Я уже решил эту проблему, но теперь у меня другая: маршруты не всегда удаляются, когда интерфейсу назначается новый IP-адрес (потому что используется один и тот же шлюз, который мне нужно использовать для маршрутизации). Не найдется ли у кого-нибудь какого-нибудь хитрого regex для perl, чтобы вытащить номер маршрута из MT? Я уже перепробовал много чего, но оказывается, MT не отправляет символы новой строки, поэтому очень сложно сопоставлять это в perl.

Eugene Guest	#4 0 18.01.2005 13:57:00 Я бы посоветовал использовать внутреннее скриптование.

savage

Guest

18.01.2005 14:03:00

К сожалению, это не вариант. Из-за того, что провайдеры в общем и целом не предлагают BPG клиентам, мне приходится вытаскивать довольно огромный список маршрутов (чтобы направлять локальный и международный трафик по разным каналам) из базы данных MySQL. Насколько я знаю, MT не умеет общаться с MySQL. Эти адреса также довольно часто меняются, так что использование чего-то вроде таблиц маршрутизации или пометка/манипулирование тоже не будет работать эффективно. Поэтому я сейчас настроил скрипт, который отправляет письмо на сервер, если адрес изменится на интерфейсе PPPoE (это работает). Как только письмо получено, сервер заходит в MT и требуется изменить таблицу маршрутизации, чтобы направлять локальный трафик к новому адресу шлюза интерфейса PPPoE.

Eugene Guest	#6 0 18.01.2005 14:21:00 Так, тебе нужно изменить адрес шлюза для одной или нескольких записей под /ip route, когда PPPoE интерфейс меняет свой адрес?

savage

Guest

18.01.2005 14:28:00

Да. В общем, если меняется [/ip address get [/ip address find interface="National Gateway"] network], мне нужно пройтись по таблице маршрутизации и обновить все маршруты, проходящие через этот PPPoE-интерфейс, чтобы убедиться, что они направляются к обновленному / не обновленному адресу сети. Затем мне все еще нужно удалить маршруты, которые могут больше не быть локальными, а также добавить новые маршруты, которые классифицируются как локальные. Но я успешно выгрузил таблицу маршрутизации в удобный perl Hash, так что это просто вопрос перебора хеша и сравнения… Не должно занять много времени.

savage

Guest

18.01.2005 16:16:00

Ладно. Скрипт готов, работает отлично, спасибо всем, кто помогал. Теперь переходим к более сложной и запутанной проблеме – которую, НАДЕЖНО, можно решить с помощью маршрутных таблиц (хотя я точно не уверен, как именно). Сейчас всё в текстовом виде, так что, пожалуйста, будьте терпеливы и постарайтесь понять схему:
/------ GW01–| | | MT |— Rest of the network
GW02–| | ------/

С помощью статических маршрутов я теперь направил локальный трафик через GW01, а GW02 — это маршрут по умолчанию (маршрутирующий остальной трафик).

Проблема в том, что если к нам приходит соединение, скажем, на веб-сервер за MT — маршрут не будет правильно возвращен.

Подробнее: 165.165/12 маршрутизируется через GW01 (на выход). Теперь у меня настроен dyndns адрес с адресом GW02. 165.165.1.1 подключается к MT через GW02, MT делает dst-nat, данные идут на сервер. Сервер отправляет данные обратно на MT, и MT СЕЙЧАС будет маршрутизировать данные на выход через GW01 (локальный адрес) — в результате, соединение с веб-сервером за MT будет не работать.

Возможные решения, о которых я думал: dst-nat всего, что приходит на GW01 и GW02, или использовать маршрутные таблицы так, чтобы адрес, приходящий на GW01, ВСЕГДА выходил через GW01, и то же самое для GW02, независимо от записей в основной маршрутной таблице.

Это всё еще неясно? И если да, то как лучше всего решать такие маршрутизационные аномалии? Cisco имеет что-то вроде ‘ip route same-interface’, если я не ошибаюсь…

savage Guest	#9 0 18.01.2005 16:26:00 Отвечаю на свой вопрос… Стоило бы протестировать больше, похоже, Mikrotik по умолчанию уже все решает… Извини за всю путаницу — для меня это такой процесс обучения.

Читают тему

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