Насколько я понимаю принцип работы таков:

Если на порту включено отслеживание привязок то
из фреймов извлекаются mac-ip и сравниваются с заданными на свитче. Если совпадают - фрейм пропускается.

Вопрос: как себя будет вести коммутатор если не совпадают?
Вопрос2 а если привязок вообще не указано?
Вопрос3: а если ни этого ip ни этого mac в привязках нет вообще?


Насколько я понимаю из экспериментов - mac-адрес (именно mac) попадает в список блокированных и далее фреймы от этого MAC не пропускаются пока не будет обнаружен фрейм с правильной связкой (происходит авторазблокировка). Я верно понимаю?

Далее неясно как это работает если на интерфейсе машины прописано более одного ip. Соответственно mac один. Нужно прописывать привязку обоих адресов? Или если прописать только одну привязку то только она и будет проходить? Или как только пойдет фрейм от второго ip, mac попадёт в BlockByAddrBind и перестанут пропускаться вообще все фреймы с этим mac в качестве источника?

1. Блокировать мак источника
2. Если не указано, но IMB на порту включен - будет блокировать все маки
3.блокируется мак


Обоих, иначе мак заблокируется

да

В итоге:

Опробовано на DES-3026 A1
Boot PROM Version : Build 1.01.007
Firmware Version : Build 4.00.018

1. если для порта включен биндинг (config address_binding ip_mac ports Х state enable) но не указано ни одной связки mac-ip то все mac, изученные на этом порту становятся BlockByAddrBind. Аналогично для всех mac, не указанных в привязках.

2. если указана связка mac-ip и приходит фрейм с неверной связкой то src mac в fdb помечается как BlockByAddrBind и заносится запись в лог если включено. Далее фреймы с этим src mac блокируются. Как минимум unicast-фреймы.

Блокировка не снимается даже в случаях
а) когда начинают идти фреймы, соответствующие привязке;
б) по истечению fdb aging_time;
в) по команде clear fdb;
Что вообще говоря вызывает вопрос почему? Ну вариант "а" еще понятен, но вот б и в??

Блокировка снимается только после комбинации
config ports 2 state disable
config ports 2 state enable
что весьма неудобно когда к порту подлючен не единичный хост.

Я выслал Вам на e-mail последнюю версию прошивки.

_________________
С уважением,
Бигаров Руслан.

config address_binding ageing_interval задающий Auto Recovery Interval - неплохо. Но в данной версии прошивки он работает так:

1. в четырех из пяти случаев свитч не успевает заблокировать mac и успевает пройти трафик вида
после чего блокировка срабатывает
задамплено прямо с интерфейса машины с которой в соседнем окне запускается пинг. Конфиг интерфейса машины
inet 192.168.5.10 netmask 0xffffff00 broadcast 192.168.5.255
inet 10.10.20.30 netmask 0xff000000 broadcast 10.255.255.255
Включена в порт 3 свитча
В привязках

IP Address MAC Address Ports
--------------- ----------------- -------------
192.168.5.10 00-D0-B7-06-E2-E7 3

В 7-й порт включена машина с конфигом
inet 192.168.5.21 netmask 0xffffff00 broadcast 192.168.5.255
inet 10.10.20.40 netmask 0xff000000 broadcast 10.255.255.255


поскольку трафик успевает пройти, машина получает искомый mac-адрес и кладёт его себе в кэш. Естесственно после этого слать arp-запросы ей незачем и повторно этот мак в блокировки не попадает.

2.
если mac успевает блокироваться и получает статус BlockByAddrBind, то по истечении Auto Recovery Interval запись о этом mac вообще удаляется из fdb. Далее пробовал порядка десяти раз предварительно очищая fdb свитча и arp-кэш машины - очевидно происходит описанное в п.1 (успевает пройти трафик), после чего опять-же машине arp-запросы слать незачем и поскольку это arp-mode MIB а не acl-mode, трафик спокойно начинает проходить через свитч. Поскольку трафик ходит - время жизни arp-записи в кэше машины обновляется и трафик продолжает ходить сколько угодно времени.

Кстати тот-же трафик успевал проходить и на 4.00.018-й прошивке. Пункты а,б,в аналогичны. В общем в отношении address_binding всё тоже самое. Хотя по большому счёту смысла в применении этой функции в arp-mode лично я не вижу

Распаковал 3526, засел читать мануал )))

Это и есть ограничения ARP режима на этой модели. Т.е. каждый первый ARP запрос проходит. Если хотите другого поведения то лучше посмотреть в сторону DES-35XX.

А по моему 3526 себя ведёт точно также. т.е. Пропускает первый запрос АРП а затем блокирует. Или я не прав???

Если при настройке IMP на порту включить режим strict то будет блокировать и первый ARP пакет.

Хочу задать вопрос:
По какому принципу происходит сравнение MAC-IP пары?

Поясню:
В IP пакетах и ARP пакетах source_ip и sender_ip лежат в разных местах, равно , как и МАС адреса.

Далее:
Если address_binding прописать на базе acl , то в правилах идет сравнение MAC-IP только в ip пакетах
, согласно протоколу 800

Ну вот и сравнивается source_ip и source_mac, в ARP пакете или IP, зависит от режима работы IMB


В всех пакетах протоколов IP

Практика показала обратное,
В режиме arp, arp пакеты не блокируются.

А Вы при настройке функции на порту режим strict включали?

Нет.
Если можно, по подробнее, как работает этот режим при просмотре пакета?

Он как раз блокирует каждый первый ARP пакет.

Буду проверить.

Но хотелось бы знать механику работы этой фичи...