как роутер реагирует на то что на другом конце провода на порту выключена автонегоциация

Если local forwarding, то при переходе с точки на точку записи в свичах же не сразу меняются, я с этим связывал. Но потом, с очередной итерацией настроек и очередным обновлением, этот спецэффект исчез

У коммутаторов реализующих Ethernet протокол, даже за 300 рублей, есть mac-forwarding table, она необходима для осуществления функций relay/filter между MAC сегментами.

Запись в этой таблице имеет в самом просто случае следующий вид, Port | MAC Address | Time.

((я бы сказал, она нужна только для фильтрации, как это написано в стандарте, но допустим, ок))

При получение кадра коммутатор осуществляет функцию learning, если source MAC адрес отсутствует в mac-address table, при добавлении в таблицу записи, у неё появляется aging time, время которое она будет находится в таблице. Получение кадра с данным MAC адрес через порт на котором он был изучен ранее, будет обновлять aging timer, получение через другой порт будет её инвалидировать.

я это в общих чертах представляю, но мне не очень понятно, как это влияет на «сеть без доступа к интереету»

Минутку пожалуйста, я не успеваю так быстро писать

Когда в CAPsMAN трафик терминуется локально на каждой AP, для какой-то SSID, при этом существует некая сетевая структура, в которой AP подключены к разным коммутаторам, которые сообщаются друг с другом, напрямую или другие коммутаторы. Может возникнуть ситуация, когда клиент выполняе деассоциацию с одной AP и подключается к другой AP, даже в рамках одного ESS. С точки зрения коммутаторов, у которых на текущий момент времени сложилась устоявшаяся таблица коммутации.

Это нидимое событие, то есть клиент подключившись к другой AP, продолжает слать unicast frames в адрес шлюза по умолчанию, тем самым не приводя к выполнению операции flooding данного кадра через все порты, кроме тех на которых они были получены. Что приводит к образованию black hole в коммутации, когда часть коммутаторов направляет трафик исходя из своей таблицы коммутации через порты, на которых клиент уже более не доступен.

Но, до выполнения очередного ARP request, который будет направлен в виде broadcast frame или же gratuitous ARP, коммутаторы не будут знать о том, что клиент изменил своё физическое местоположение, либо пока не истечёт aging time в mac address table.

все так, но есть нюанс

Актуально ли это для всех топологий? Нет конечно, не актуально, но рекомендуют ли производители делать local forwarding, нет, Wi-Fi клиент не обязан при переассоциации направлять gratuitous ARP кому-либо.

при деассоциации от одной точки и переассоциации к другой клиент должен переполучить адрес

соответственно, dhcp discover  идет бродкастом

соответственно, такой бродкаст флудится по всей сети, обновляя fdb на коммутатораз

Если используется DHCP, к тому же, сам DHCP discover может и не выполнятся, клиент может выполнить DHCP renew а он будет unicast

А вот и не всегда это происходит

да, если не используется - почти все современные ОС выполняют ACD

уведомляют всех арпом о взятии адреса

это тоже идет бродкастом, естественно

что именно «это»?

не должен в ситуации полной переинициализации интерфейса быть renew