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

Проблема RipV2

Проблема RipV2, RouterOS

docmarius

Guest

24.11.2011 20:51:00

У меня ситуация, которую я реально не понимаю — может, тут есть более опытные люди, которые смогут мне просветить. У меня есть IPIP-туннель, который даёт доступ к домену ampr (44.0.0.0/8). Этот туннель переадресует поддомен на свой конечный пункт (у меня это 44.182.21.0/24) и при этом распространяет маршруты для всего домена 44 через мультикасты RIPv2. В элементах маршрутизации есть пара IP/маска и шлюз, который находится вне домена 44, но доступен через туннель. RIP-мультикасты идут с 44.0.0.1 на 224.0.0.9 (это RIPv2 multicast). Теперь есть две проблемы.

Во-первых, слушатель RIP должен иметь интерфейс с маской /8 (например, 44.182.21.1/8), иначе он не будет обрабатывать маршруты. Значит, у меня всегда будет напрямую подключённый маршрут с меньшей метрикой, чем те, что предоставляет RIP (у них метрика 120). Так RIP-маршруты всё равно имеют приоритет или нет?

И вторая проблема связана с тем, как маршруты принимаются маршрутизатором. RIP-маршруты имеют установленный шлюз:

[admin@MikroTik] /routing rip route> print
# DST-ADDRESS GATEWAY FROM METRIC
0 R 44.0.0.0/8 1
1 R 44.2.1.32/29 76.14.161.185 44.0.0.1 2
2 R 44.2.8.180/30 192.147.172.252 44.0.0.1 2
3 R 44.2.10.208/29 71.130.72.53 44.0.0.1 2
4 R 44.2.14.0/29 98.238.147.85 44.0.0.1 2
5 R 44.2.14.100/32 98.238.147.85 44.0.0.1 2
6 R 44.2.50.0/24 208.74.106.137 44.0.0.1 2

Но в таблице маршрутизации они отображаются неправильно:

[admin@MikroTik] /ip route> print
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
8 ADC 44.0.0.0/8 44.182.21.1 AMPR-IPIP 0
9 ADr 44.2.1.32/29 44.0.0.1 120
10 ADr 44.2.8.180/30 44.0.0.1 120
11 ADr 44.2.10.208/29 44.0.0.1 120
12 ADr 44.2.14.0/29 44.0.0.1 120
13 ADr 44.2.14.100/32 44.0.0.1 120
14 ADr 44.2.50.0/24

И не учитывают шлюз, который указал RIP. Кто-нибудь может подсказать, как это можно обойти, или с этим придётся смириться? Спасибо. Мариус

neticted Guest	#2 0 23.07.2013 16:32:00 Я столкнулся с той же проблемой, и разочаровывает то, что на самом деле невозможно использовать Mikrotik для AMPRNet. Тебе удалось решить это как-то иначе? Как с тобой связаться за помощью?

rekholm

Guest

20.08.2013 06:24:00

С вами обоими согласен. Должен же быть какой-то более простой способ. Я хочу использовать AMPR для подключения, но меня сводят к тому, что приходится запускать Linux-сервер. Совсем не то, что мне нужно как HE-роутеру в моей сети. Сегодня вечером я написал на форуме 44net, что хочу простое соединение. Что-то, что не требует какого-то специфического сервиса, нагрузки или демона. Считаю это довольно абсурдным, что они так делают. В общем, дайте знать, если хотите поэкспериментировать или что-то протестировать. А пока я поставлю свои резервации 44/8 на паузу, пока вся эта сеть не перестроится.

neticted

Guest

20.08.2013 07:57:00

Насколько я понял, нужно создать IPIP-туннель для каждой активной подсети в 44/8 и затем настроить маршрут к этой подсети через соответствующий IPIP-туннель. Пример настроек маршрутизации я так и не нашёл, чтобы попробовать повторить на Mikrotik. Есть и другой вариант: можно связаться с админом какой-нибудь подсети из 44/8, он может предоставить PPTP или другой VPN, и тогда ты сможешь маршрутизировать трафик через его сеть, используя всего один маршрут. Есть надежда, что они когда-нибудь решат начать использовать iBGP или что-то подобное для маршрутизации в 44/8.

rekholm

Guest

22.08.2013 03:22:00

Neticted, я согласен с твоим более поздним решением. Один-два туннеля к кому-то ещё, и пусть они занимаются всей маршрутизацией. Если они всё-таки решат использовать BGP, боюсь, на это уйдёт несколько лет, чтобы всё заработало. Если только несколько радиолюбителей, которые, возможно, также являются (W)ISP, не подключатся и не предложат colo — тогда дело может пойти быстрее. Я слышал, что в ближайший год-два планируются какие-то изменения, но что именно — не знаю. Надеюсь, это поможет тем из нас, кто выбирает не использовать Linux-решение. Лично я строю свой HamNet самостоятельно. Для некоторых внешних соединений, исходящих из остальной сети, буду использовать своего провайдера, но не для обычного трафика на порт 80 (веб-трафик, если проще). В основном это BBS, радиолюбительские FTP, а также надеюсь, улучшенные сервисы вроде голосового чата mumble, SMS... То, что по обычному «пакетному» соединению было слишком медленно. Планирую также предоставлять доступ к Telnet-узлам и RF Packet-узлам через эту систему. Такой себе универсальный магазин. HamWan.org из Сиэтла этим занимается, но они интегрируют это ещё и в 44/8, и, как я понимаю, предлагают больше услуг WISP. Я пока толком не понял, что именно они предлагают. Возможно, есть и другие похожие системы, просто я о них пока не слышал.

neticted

Guest

22.08.2013 08:53:00

Проблема при маршрутизации через кого-то другого в том, что весь трафик должен проходить через его каналы, тратя его ресурсы. Думаю, именно поэтому такой способ маршрутизации не получил широкого распространения в сети 44/8 — люди не могут себе позволить делиться ресурсами. Посмотрите на итальянские и немецкие hamnet'ы. Они используют BGP для публичного анонсирования своих подсетей. Проблема в том, что закон запрещает не лицензированным пользователям использовать ресурсы радиолюбителей, поэтому большинство hamnet'ов выбирают простое решение — не быть публичными, а если сети не публичные, то без прямых VPN их сложно маршрутизировать.

docmarius Guest	#7 0 24.07.2013 05:47:00 Простого решения тут нет. Как я уже говорил, инкапсуляция ipip в RouterOS предполагает точка-точка (PtP) IPIP-соединение с одним исходным и одним конечным IP, тогда как Linux-реализация IPIP поддерживает и точку-многоточку. В Linux эти множественные назначения настраиваются добавлением маршрутов с разными шлюзами через этот интерфейс, причем маршруты динамически получает rip44d, который «переваривает» RIPv2-сообщения, полученные от 44.0.0.1, и добавляет их в таблицу маршрутизации. Стандартные реализации RIP (как в Mikrotik) добавляют такие маршруты, используя отправителя RIP в качестве шлюза, что и вызывает описанное поведение. Поэтому этот вариант нам не подходит. Рабочий вариант — получить маршруты через encap.txt и с помощью какого-то скрипта добавить их в RouterOS, создавая PtP IPIP-интерфейс для каждой записи в файле encap, что приведет к появлению 389 интерфейсов (именно столько их сейчас, когда я пишу). Скрипт для этого предоставил Tom Hayward KD7LXL в группе 44net. Второй подход, который я использую у себя, — это завести сервер инкапсуляции на Linux (например, Raspberry Pi), который будет организовывать локальную точку IPIP-туннеля и одновременно пересылать пакеты RIPv2 через модифицированный скрипт rip44d так, чтобы RouterOS мог их правильно обрабатывать (этот сервер инкапсуляции будет выступать в роли шлюза). Лично я отдаю предпочтение второму решению — оно позволяет организовать динамическую настройку.

Читают тему

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