static arp CRS125-24G

[SLB]

Доброго дня, уважаемые гуру. Помогите советом.

есть сеть типа звезда
есть некая железка на луче звезды (на примере CRS125-24G-1S), сконфигурирована в режиме бриджа (все порты объединены в один бридж).
с остальной сетью эта железка связана через свой 24ый порт (т.е. за этим 24ым портом много-много других хостов),
а, например, в 1-23 порты - клиентские, один порт - один клиент, настройки ip у которых - статические.
нужно сделать, чтобы на портах 1-23 существовала строгая привязка IP+MAC источника, а всё остальное просто дропалось.

вроде все должно быть просто:
в Interface выбираем порт (например ether3) и ставим ARP relpy-only, занося попутно в IP >> ARP List IP IP-адреса и мас клиента. указывая порт (ether3) к которому клиент подключен?
но фиг, такую запись микротик считает invalid. все эти действия микроту пофиг. на прохождения трафика это совсем никак не влияет.

ок. начинаем разбираться и пляшем уже от бриджа, т.е. заношу в ARP List - IP и MAC клиента но указываю теперь порт bridge, а не ether3
после этого, если включить ARP reply-only на интерфейсе ether3 - логично ничего не происходит
а если включить reply-only на интерфейсе bridge - благополучно должно отвалится и все что на 24ом порту ( входящий линк в микрот, где много-много хостов. их-то я руками не внес в статику)

что я делаю не так, как на выборочных портах активировать static arp?

[gmx]

ТС: что-то не так вы вносите в ARP походу дела.

Предложение следующее: просто сделать ARP enable, дождаться пока она заполнится. Затем сделать записи статическими (правой кнопкой). После этого переключить на соответствующем интерфейсе (его видно в ARP таблице) ARP в режим reply-only и... перезагрузить микротик. Почему-то у меня без перезагрузки reply-only никогда не запускается.

[Erik_U]

А как работает ограничение при помощи reply one?
Это режим, в котором порт только отвечает на АРП-запросы. Это значит, что микротик не будет в своей АРП-таблице накапливать записи о хостах за этим портом. Но это никак не ограничивает работу.
Хостам же никто не запрещает арп-запросы и собственные таблицы.

Чтобы сделать ограничение по ARP-IP, по-моему нужно или настраивать фильтры на порту, или мудрить с адрес-листами и фаерволом.

[gmx]

А как работает ограничение при помощи reply one?
Это режим, в котором порт только отвечает на АРП-запросы. Это значит, что микротик не будет в своей АРП-таблице накапливать записи о хостах за этим портом. Но это никак не ограничивает работу.
Хостам же никто не запрещает арп-запросы и собственные таблицы.

Чтобы сделать ограничение по ARP-IP, по-моему нужно или настраивать фильтры на порту, или мудрить с адрес-листами и фаерволом.

Как это не будет накапливать? Будет. Все, что не за чужим NAT будет вписано в ARP.
Посмотрите у меня на скрине, на разных интерфейсах куча устройств, при этом bridge1 - это вообще capsman и там 14 точек и всех клиентов видно, дальше vlan пошли и клиенты в эти vlan попадают по разному: и напрямую, и через куча других коммутаторов....
Все, что увидит шлюз по L1/L2 - должно быть добавлено в ARP иначе на кой она тогда вообще нужна? Более того, присмотритесь к скрину. Часть записей ARP добавлено сервером DHCP, а часть получено шлюзом динамически (vlan30mng), но при этом эти устройства не все напрямую включены, многие прошли через два, а то и три коммутатора 2 уровня.
Другое дело, если клиенты спрятаны за нат в другом устройстве, тогда конечно в арп будет только mac встречного роутера, но на этом роутере будет своя таблица arp...
Ну разве не прелесть?

Вот я и предлагаю ТС: включите ARP enable на нужном интерфейсе и посмотрите как заполняется таблица и все станет ясно.

[Erik_U]

Как это не будет накапливать? Будет. Все, что не за чужим NAT будет вписано в ARP.

У микротика в вики написано, что если порт в режиме ARP - Reply One, то он не записывает в таблицу то, что прилетает с этого порта, в этот порт только отвечает на запросы.

[gmx]

Как это не будет накапливать? Будет. Все, что не за чужим NAT будет вписано в ARP.

У микротика в вики написано, что если порт в режиме ARP - Reply One, то он не записывает в таблицу то, что прилетает с этого порта, в этот порт только отвечает на запросы.

Я как-то наверное не правильно понял, что вы имеете в виду. Понятно, что если reply-only микротик ничего уже не записывает, все должно быть уже записано заранее. ТС пишет, что он заносит записи в ARP, но оно не работает. Я пытаюсь подсказать, как быть в этой ситуации.

Мое предложение простое: ARP enable и посмотреть, что именно появляется в ARP, а уже от этого исходить дальше...

[SLB]

ТС: что-то не так вы вносите в ARP походу дела.

Предложение следующее: просто сделать ARP enable, дождаться пока она заполнится. Затем сделать записи статическими (правой кнопкой). После этого переключить на соответствующем интерфейсе (его видно в ARP таблице) ARP в режим reply-only и... перезагрузить микротик. Почему-то у меня без перезагрузки reply-only никогда не запускается.

разницы никакой нет и быть не может. записи "наполняются" для интерфейса bridge. (Вы же понимаете, что бридж это ни разу не коммутируемая "функция"? в этом корявый смысл микрота от рождения. костыли ставшие фичей.) если его (bridge) и перевести потом в reply-onlу, то, я так понимаю, он и всё с входящего порта на коммутатор "узнавать" перестанет. верно?

[Erik_U]

нужно сделать, чтобы на портах 1-23 существовала строгая привязка IP+MAC источника, а всё остальное просто дропалось.

Бридж - фильтр.
Добавьте для нужного порта фильтр форвард, в нем укажите мак-адрес источника с "!", IP адрес источника с "!", и действие - дроп.

Все пакеты, приходящие на этот порт не от указанного мак с указанным IP будут дропаться.

АРП-таблица не поможет решить эту адачу.

Еще, наверно, нужно выключить для этого порта "Hardware Offload". Чтобы пакеты обрабатывались ROS, а не чипом свича.

[gmx]

А.... так у вас ситуация сложнее, есть коммутатор uplink????

Тут все от задачи зависит. Все-таки, арп наиболее удобна, когда трафик четко разделен, то есть арп задействуется на маршрутизаторе с нат. Тогда все просто, все, что ниже мы контролируем и соответственно допускаем к шлюзу или нет.
Если же в вашем случае нужны ограничения на уровне коммутации, то arp будет не удобна. Используйте возможно bridge filters. Как вам и подсказали выше.

Для чего, чаще всего используется arp??
У меня в 100% случаев это следующая комбинация: пользователи могут быть: проводными, wifi, проводными в разных VLAN, или проводные и беспроводные одно и тоже устройство в зависимости от ситуации.
Все она получают IP адреса через DHCP, в разной ситуации эти IP разные. В DHCP серверах для всех устройств созданы статические записи. Но некоторые умники, додумались, что можно IP адрес устройству задать вручную. Вот тут-то и приходит на помощь арп. Мы заставляем DHCP заносить записи в арп, дальше - reply-only....

[SLB]

нужно сделать, чтобы на портах 1-23 существовала строгая привязка IP+MAC источника, а всё остальное просто дропалось.

Бридж - фильтр.
Добавьте для нужного порта фильтр форвард, в нем укажите мак-адрес источника с "!", IP адрес источника с "!", и действие - дроп.

Все пакеты, приходящие на этот порт не от указанного мак с указанным IP будут дропаться.

АРП-таблица не поможет решить эту адачу.

Еще, наверно, нужно выключить для этого порта "Hardware Offload". Чтобы пакеты обрабатывались ROS, а не чипом свича.

может что-то не правильно делаю, конечно:
Добавляю для нужного порта (например ether3) в Bridge >> Filters фильтр "forward", в нем указываю In.Interface - ether3 и заведомо неверный Src.MAC Address мак-адрес источника с "!" (с IP потом разберемся). ничего не происходит, счетчик фильтра стоит на 0. отключаю HW Offload для порта ether3 - ничего не происходит, кроме того, что из FDB switch'а пропадает запись для порта. ну т.е. трафик пошел мимо свитч-чипа... но и только. на срабатывание фильтра - никак не влияет...