Проблема воспроизводится на следующих коммутаторах:

TL-SG3452X 1.0 (1.0.6 Build 20230702 Rel.70603)
TL-SG3428 2.0 (2.0.11 Build 20230602 Rel.76586)
TL-SG3210 3.0 (3.0.8 Build 20230602 Rel.73473)
SG2218 1.20 (1.20.0 Build 20230818 Rel.72032)

  @sla0nru 

Добрый день.
Уточните, о каком устройстве идет речь в данном примере?
И опишите более подробно о том, как запрашивается один мак в разных вланах ?

  @Ame_ru 

Конкретно 74:ac:b9:96:db:3b в данном примере - это точка доступа ubiquiti с гостевым wifi в отдельном vlan'е. Особенность этих точек такова, что за какой-то набодностью они обращаются к dhcp и в гостевом vlan тоже, что на коммутаторах tp-link приводит к периодической недоступности основного управляющего ip и разрыву связи точки с контроллером unifi.

Сегодня утром я воспроизводил проблему более контролируемым образом с использованием PC под управлением linux и нескольких моделей коммутаторов tp-link, что оказались под рукой. Поднял в linux'е на интерфейсе два vlan и попеременно запрашивал ip по dhcp то на одном, то на другом. Каждый раз при этом запись в IMPB для mac была только одна. Обращение к dhcp в одном vlan'е замещало запись в IMPB от другого vlan'а. Таком образом, получается, что механизм IMPB игнорирует значение VID и оперирует только MAC и PORT. Не совсем то, что написано в User Guide 1910013560 REV5.0.0: "... IPv4 IMPB (IP-MAC-Port Binding) is used to bind the IP address, MAC address, VLAN ID and the connected port number of the specified host. ..."

Могу предоставить подробную методику тестирования и конфигурацию коммутаторов.
 

Проблема не в самом IMPB, а в том как с ним работает dhcp snooping. Это dhcp snooping игнорирует VID и производит замену записи в IMPB на основании лишь IP-MAC-Port. Статически добавленные записи IP-MAC-VID-Port сосуществуют и обеспечивают работу должным образом.

 

TL-SG3210#sh ip so binding                                                     
U Host                 IP-Addr         MAC-Addr          VID  Port      ACL    SOURCE          LEASE
- ----                 -------         --------          ---  ----      ---    ------          -----
1 test7                10.4.7.73       ac:1f:6b:e1:b7:ed 7    Gi1/0/7   Both   Manual          
1 test9                192.168.9.180   ac:1f:6b:e1:b7:ed 9    Gi1/0/7   Both   Manual          

Notice:
1.Here, 'ARP-D' for 'ARP-Detection',and'IP-V-S' for 'IP-Verify-Source'.

  @sla0nru Мы пообщались с разработчиками, и они считают это слишком специфичным сценариев. Это больше похоже на порт в режиме аплинка/даунлинка на котором обычно не рекомендуют включать dhcp snooping. Мы ещё продолждаем с ними общение, поэтому есть несколько вопросов:

1. Вот есть у вас гостевая сеть. Для чего вы включаете в этом влане arp inspection/source guard? Это ведь гостевая сеть у вас. Там можно изоляцию клиентов на уровне unifi включить и т.д. Как авторизация клиентов устроена? Расскажите тут поподробнее.

2. Зачем вам dhcp snooping в управляющем влане? В этом влане есть клиенты другие, кроме точек доступа? Если есть, то может быть выделить отдельный менеджмент влан под точки?

3. Есть понимание, для чего unifi в гостевом влане запрашивает IP? Насколько это нормально? Точка является каким-то прокси? С нашей стороны кажется, что это на баг похоже.

  @Mitya спасибо за отклик.

1. Используются точки доступа трёх брэндов и вникать во все нюансы каждого не хотелось. Изолировать клиентов в гостевой сети наверное желательно, а в не гостевой, вроде бы и не нужно, а все ли точки умеют избирательно включать изоляцию на отдельных сетях и насколько корректно это делают - нужно разбираться. Проще было задействовать возможности коммутаторов.
2. Отдельный management vlan мы используем не везде. В данном случае его нет. Точка своим управляющим интерфейсом находится в локальной сети вместе с пользователями рабочего wifi, и теми, что подключены проводами. Эта сеть требует защиты.
3. У нас используются AP-AC-Lite и AP-AC-LR - обе модели обращаются к dhcp и в основном и в гостевом vlan. Какой в этом смысл непонятно, как используется полученный адрес в гостевом vlan не изучал. В интерфейсе контроллера на этот счёт не нашёл никаких настроек.

Возможно сценарий экзотический, однако, некорректным его назвать нельзя. К слову, пока мы использовали cisco sf300 и sf350 проблем с такой конфигурацией не возникало. Как быть с unifi и на какой из сетей отключать dhcp snooping я решу. И буду надеяться, что данную проблему в работе dhcp snoopping tp-linlk'ов когда-нибудь устранят, потому что это точно баг.