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

ICMP - перенаправление хоста (5:1)

ICMP - перенаправление хоста (5:1), RouterOS

conchalnet

Guest

27.01.2010 21:01:00

Всем привет! Я заменил свой FreeBSD-шлюз на RB1000 (он отличный). После замены я иногда стал получать странное сообщение в ответе на ping, когда «пингую» клиента через свою ТД (AP), а не напрямую с RB1000.

Моя структура выглядит так:
интернет — RB1000 (GW) — RB433H (AP) — клиенты.

Немного о моей структуре:
Клиенты находятся в сети 200.X.X.0/24.
Административная сеть — 192.168.1.0/24 (все RB, которые работают как AP, находятся здесь).
RB1000 работает как шлюз моей сети, и у него 2 сетевых интерфейса (eth1 и eth2).
На ETH2 у RB1000 настроены IP 192.168.1.1 (шлюз для RB) и 200.x.x.1 (шлюз для клиентов).
ETH1 RB1000 подключён к интернету.
RB433 работает как AP и настроен в режиме BRIDGE. На RB433 стоит одна беспроводная карта, к которой подключены клиенты.
У RB433 IP 192.168.1.2, а шлюз — 192.168.1.1.
Я могу пинговать клиентов с RB433.

Но иногда от шлюза приходит вот такое сообщение:
192.168.1.1 92 byte redirect host (5:1) time=4 ms

Когда шлюзом была FreeBSD, таких сообщений я никогда не получал. Проблема началась после замены FreeBSD на RB1000. Кто-нибудь знает, что происходит? Почему я получаю ICMP redirect?

Заранее спасибо!

NetworkPro

Guest

11.02.2010 16:36:00

О БОЖЕ, ЧЕРТОВСКИЙ БРЕД!! mrz, ты ведь осознаёшь, что эти ICMP-сообщения — это серьёзная проблема, да? Я проверял, и это точно проблема в случаях маршрутизации на одном и том же интерфейсе. Роутер с двумя сетями на одном интерфейсе, маршрутизация с одной в другую. Проверял на версиях v3.30 и v4.5 — проблема присутствует. Суть в том, что из-за этого замедляется работа или сервис вообще не доходит, когда клиент из одной подсети пытается обратиться к серверу из другой. Потому что роутер отправляет клиенту эти ICMP redirect-сообщения, а клиент, понятное дело, их плохо воспринимает. БОЖЕ МОЙ, СКОЛЬКО ПРОБЛЕМ ИЗ-ЗА ЭТОГО БЫЛО!!! ТОННЫ ПРОБЛЕМ И БЕСПОЛЕЗНО ПОТРАЧЕННОГО ВРЕМЕНИ!!! БОЖЕ!!!

changeip

Guest

11.02.2010 16:48:00

Это обычные сетевые маршрутизирующие вещи... даже 15 лет назад я видел, как Cisco-устройства так работают. Если маршрутизируешь что-то обратно тем же интерфейсом, с которого пришло, то ICMP-редиректы должны отправляться. Зачем нагружать маршрутизатор, если всё происходит в одной и той же сети? Сейчас многие клиенты игнорируют такие редиректы из соображений безопасности. С другой стороны, я заметил серьёзные утечки памяти в Mikrotik именно из-за этого (когда устройство выступает в роли клиента для таких сообщений). Но точную причину я пока не выяснил.

NetworkPro

Guest

11.02.2010 18:42:00

Утечки памяти? Похоже, ты устраиваешься на разработчика. Как ты заметил это? Зачем обращаться к роутеру, если все на одном кабеле? Пример с разными подсетями — клиенты с публичными IP и клиенты с приватными IP.

variable

Guest

25.11.2011 23:09:00

У меня есть сеть: (10.1.1.0/24)----[10.1.1.1=ROUTER-A=10.1.2.125]-----(10.1.2,3,4.0/24)[.1=ROUTER-B=]. Где Router A настроен так, что его шлюз — Router B. Если хост из 10.1.1.0/24 пингует хост из 10.1.3.0/24, первый пинг проходит и получает ответ, а все последующие — нет. При более детальном исследовании выяснилось, что после первого пинга ROUTER-B отправляет icmp redirect сообщение хосту из 10.1.3.0/24, но, насколько я понимаю, это противоречит RFC (см. ниже). http://www.networksorcery.com/enp/protocol/icmp/msg5.htm http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094702.shtml Ведь ICMP redirect сообщения должны отправляться только если хост и следующий переход находятся В ОДНОЙ подсети, а здесь это не так. Просмотрев форумы, нашёл, что правило для сброса redirect-ов решает проблему — и правда решает, но при этом, похоже, это не соответствует RFC? /ip firewall filter add action=drop chain=output disabled=no icmp-options=5:0-255 out-interface=bridge1 protocol=icmp Это баг в mt?

NetworkPro Guest	#6 0 25.11.2011 23:44:00 О, не волнуйся. Ядро Linux делает это и многое другое. Недавно я обнаружил «зомби»-кадры IGMP, выходящие из роутеров, когда их провоцируют другими кадрами IGMP. Просто сбрасывай их, если они мешают.

psycoclan1 Guest	#7 0 15.01.2016 02:35:00 Я получаю похожее сообщение от ICMP. Можешь объяснить, что значит это сообщение? 0 xxx.yyy.zzz.sss 84 64 53мс redirect host 0 xxx.yyy.zzz.sss 84 64 115мс redirect host 0 xxx.yyy.zzz.eee 56 255 125мс TTL exceeded 1 xxx.yyy.zzz.sss 84 64 0мс redirect host 1 xxx.yyy.zzz.eee 56 255 4мс TTL exceeded 2 xxx.yyy.zzz.sss 84 64 0мс redirect host 2 xxx.yyy.zzz.eee 56 255 4мс TTL exceeded 3 xxx.yyy.zzz.sss 84 64 0мс redirect host 3 xxx.yyy.zzz.eee 56 255 4мс TTL exceeded 4 xxx.yyy.zzz.sss 84 64 0мс redirect host 4 xxx.yyy.zzz.eee 56 255 4мс TTL exceeded 5 xxx.yyy.zzz.eee 56 255 135мс TTL exceeded 6 xxx.yyy.zzz.sss 84 64 0мс redirect host 6 xxx.yyy.zzz.eee 56 255 4мс TTL exceeded Где: xxx.yyy.zzz.eee — IP провайдера xxx.yyy.zzz.sss — IP ядрового маршрутизатора Целевой IP — это IP внутри публичного диапазона, допустим, диапазон rrr.www.qqq.0/24, и целевой IP — rrr.www.qqq.ttt.

Читают тему

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