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

rc5 - ARP отправляется на неправильных интерфейсах! Multihomed

rc5 - ARP отправляется на неправильных интерфейсах! Multihomed, RouterOS

changeip

Guest

20.06.2005 04:17:00

Вот пост, в котором я описал, что, как я думаю, вызвано этой ошибкой: http://forum.mikrotik.com//viewtopic.php?t=3456&highlight= У меня была похожая ситуация, но я думаю, что она связана. Я подключил два физических интерфейса к кабельному провайдеру на 4-портовой сетевой карте. MAC-адреса для каждого интерфейса, очевидно, разные. Если коротко - Cox Cable видит оба MAC-адреса на своем роутере, связанные с неправильными интерфейсами. MT транслирует НЕПРАВИЛЬНЫЙ MAC для второго интерфейса. Cox затем отправляет мне весь трафик обратно через один интерфейс, потому что MT рекламировал обе сети на одном кабельном модеме. Поскольку это кабель, им все равно и они отправят его обратно - я предполагаю, что если у вас было бы 2 разных провайдера, как у других авторов сообщений, у вас были бы прерванные сессии. У меня были проблемы с правилами брандмауэра, блокирующими весь трафик, потому что он поступал с неправильного интерфейса. Флаги: X - отключено, R - работает ИМЯ MTU MAC-ADDRESS ARP 0 R onboard-inside 1500 00:40:CA:1D:C8:7C enabled 1 R 1-coxBiz 1500 00:20:FC:1E:D1:C0 enabled 2 R 2-sony 1500 00:20:FC:1E:D1:C1 enabled 3 R 3-coxRes 1500 00:20:FC:1E:D1:C2 enabled 4 R 4-hotty 1500 00:20:FC:1E:D1:C3 enabled 7 address=68.15.19.50/27 network=68.15.19.32 broadcast=68.15.19.63 interface=1-coxBiz actual-interface=1-coxBiz 9 D address=68.8.25.137/23 network=68.8.24.0 broadcast=68.8.25.255 interface=3-coxRes actual-interface=3-coxRes coxBiz и CoxRes – подключения к кабельному модему. У каждого свой интерфейс, подключенный напрямую. D1:C0 и D1:C2 Один интерфейс с фиксированным IP, другой получает IP по DHCP (бизнес и домашний кабельный модем). Многоадресная маршрутизация таким образом работала отлично на 2.8 в течение года. (Что за параметр ‘actual-interface’?) Снимок экрана показывает, что он отправляет MAC-адреса через неправильные порты. IP-адреса находятся на совершенно разных физических интерфейсах и НИКОГДА не должны пересекаться. MT сообщает одному подключению к вышестоящей сети IP-адрес другого подключения. Этот снимок экрана Ethereal это подтверждает. Пожалуйста, посмотрите на это и исправьте то, что не так, пожалуйста : ) Я не смогу перевести наши производственные роутеры на 2.9, пока это не произойдет. Я знаю, что это бета-версия, и надеюсь увидеть это исправлено до релиза. Сообщение в службу поддержки уже отправлено. Спасибо, Сэм

changeip

Guest

20.06.2005 04:30:00

P.S. Если посмотреть на выделенную строку в этом эфирном снимке, то видно, что метка времени роутера не включается в перехват пакетов. Время на роутере отображается корректно, просто иногда оно записывается в pcap с древними датами и временем. Сэм.

roland

Guest

22.06.2005 16:12:00

Сэм, твой пост (и связанные с ним проблемы с несколькими шлюзами/NAT) похоже, именно с тем я столкнусь, если не найду обходной путь. Во-первых, хочу сказать, что я ошибся форумом (использую v2.8.26). У меня есть 2 отдельные среды: одна с несколькими DG, где оба требуют NAT, а другая - один шлюз нуждается в NAT, а другой - прямой, без NAT. Я работаю над этим (для случая 1): добавление `src-address=0.0.0/0 out-interface=ethnet1 action=nat to-src-address=10.11.1.1` и `src-address=0.0.0/0 out-interface=ethnet2 action=nat to-src-address=10.22.1.1` и отключение второго фильтра для моего случая 2. Что думаешь? Какие идеи? (Я пока не закончил тестирование) спасибо/RS

kjagus

Guest

22.06.2005 18:15:00

Привет всем. Раз никто из MT не может прийти к согласию по этому форуму по поводу этой ошибки или сказать, когда ошибка будет исправлена, я выкладываю информацию, которую получил из MT: Здравствуйте. Это работает именно так. Если ваши данные отправляются через один шлюз, а затем снова через другой, ваша система чата не понимает, как может быть, что информация от одного человека приходит из разных мест, и она не знает, куда отправлять ответ, поэтому останавливается. Вам следует использовать маршрутизацию по политике, там у вас будет больше контроля. ECMP может создавать проблемы с программами для чата, онлайн-играми и подобными приложениями. Искренне ваш, Нормундс.

Хм… Я понимаю такое поведение, однако я думал, что ECMP учитывает ориентацию на сессию (сохраняет сессию на одном шлюзе). Если нет – где функциональность этой функции? Ну, я спросил снова и получил: Здравствуйте, есть два решения: либо вы используете маршрутизацию по политике, либо избегаете использования маскирования. Когда вы используете маскирование, ECMP может вызывать проблемы, подобные тем, что вы описываете. Искренне ваш, Нормундс.

Я не гуру маршрутизации и я действительно не понимаю, когда я могу использовать ECMP, если не могу использовать маскирование? Вся моя сеть – 300 хостов – работает с маскированием, и я понятия не имею, что мне делать, чтобы использовать ECMP без маскирования? Маршрутизация по политике работает хорошо – но это уже другая игра – и это не окончательное решение для меня – она требует слишком много внимания и не так точна, как ECMP (ECMP действительно тонкий баланс загрузки – и это основная цель при балансировке ADSL). Я все еще жду работающий ECMP – думаю, они об этом не позаботятся сейчас – пока не появится действительно стабильный и официальный релиз 2.9. С другой стороны – я слышал, что подобная ошибка ECMP есть и в Linux-дистрибутивах тоже… Это один и тот же модуль в MT, без модификаций?

С уважением, kj

changeip

Guest

22.06.2005 18:23:00

ECMP становится "липким" просто потому, что ты работаешь с двумя шлюзами, и каждый пакет имеет возможность использовать любой из них. Это не обязательно проблема локальной сети, это проблема IM шлюзов — они не любят, когда ты переключаешь IP адреса каждые несколько минут. В политической маршрутизации я указываю ТОЧНО, какие пакеты куда должны идти, но правила не соблюдаются. Насколько я в курсе, в коде rc6 все еще есть небольшая ошибка, из-за которой ARPs транслируются на неправильный интерфейс. Я отправил поддержку описанное выше несколько дней назад и ответа не получил… Уверен, они думают, что это проблема конфигурации, или знают, что это баг, просто хотелось бы, чтобы они сообщили нам об этом. Интересно, не путается ли головной блок провайдера кабельного телевидения (Cisco 7200) с MT — ведь оба шлюза (на разных подсетях) показывают один и тот же MAC у них, может, MT видит это и игнорирует подсеть, просто используя первый найденный шлюз, который может до него достучаться. Это баг, и нам нужно его решить, прежде чем переносить что-либо. Рад предоставить больше тестов и что угодно еще, что нужно MT, чтобы исправить это — просто скажите, что вам нужно. Sam

roland

Guest

22.06.2005 19:03:00

Сэм, глянь на мой пост выше. А я тем временем протестировал (оба варианта) – работает. Попробуй добавить src-nat (NAT, а не masquerade): add src-address=0.0.0/0 out-interface=ethnet1 action=nat to-src-address=10.11.1.1 add src-address=0.0.0/0 out-interface=ethnet2 action=nat to-src-address=10.22.1.1 PS: если установить disable-running-check=no на ethernet, то даже появляется некоторая отказоустойчивость (для сбоев интерфейса, а не маршрутизации). Я запускаю это на беспроводном репитере. У него своя SDSL backbone (eth/NAT) и, если она отключится, он маршрутизирует без NAT в WDS на другой AP.

changeip

Guest

22.06.2005 19:14:00

Нельзя использовать src-nat, потому что у одного из кабельных модемов есть адрес dhcp, соответственно, его нельзя настроить статически. MASQ должно работать нормально, если маршрутизация основана на интерфейсе, через который он выходит; это всегда работало так же в 2.8. Вот для чего нужен masq. Попробуйте маршрутизировать определенный трафик через один интерфейс, а другой – через другой. В манипулировании (mangling) видно, что метки маршрутов добавляются, но в нужный момент они не выбирают правильный маршрут. Скриншот выше это прекрасно показывает… нет причин, по которым MT должен рекламировать неверную комбинацию IP/ARP. Все просто. Сэм.

roland

Guest

22.06.2005 19:27:00

Если один шлюз — DHCP-модем, ну что ж, ты не сможешь заменить masq на src-nat. По крайней мере, в моей ситуации (оба шлюза с публичным/статическим IP), я обнаружил, что два src-nat с установленным out-interface, заменяющие masq, — это обходной путь для путаницы с IP/ARP (который явно является багом, но MT игнорируют уже долго). RS

changeip Guest	#9 0 22.06.2005 19:34:00 Давай попробую настроить NAT вместо MASQ на 10 минут и посмотрю, не продолжит ли оно вылетать. Мой DHCP-адрес обычно стабилен хотя бы день-два. А ещё у нас всё ещё проблема с политиками маршрутизации. Сэм.

lastguru Guest	#10 0 27.06.2005 10:55:00 Смена IP означает разрыв соединения, это все очень просто, ведь любое соединение работает только с одного IP на другой, а не с двух IP на один (ну, кроме некоторых случаев multicast и broadcast, возможно). НО ECMP не (или не должен…) случайным образом переключать IP, иначе это просто не будет работать! ECMP определяет путь на основе пары IP (src-dst) и поддерживает эту связь в течение неопределенного периода времени (я думаю, это не связь, а скорее функция хеширования). Если что-то не работает, значит, вовлечено другое соединение с другого IP, которое не может найти обратный путь к хосту-источнику, или что-то в этом роде. Я не эксперт в каких-либо играх, IM и P2P протоколах, поэтому я не знаю, почему это не работает, но одно я знаю наверняка - это фундаментальный недостаток в этих протоколах, который не позволяет им работать, а не ошибка в RouterOS. Если ECMP работает с TCP и UDP, то он работает, потому что для решения о маршрутизации разницы между IP протоколами нет.

Читают тему

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