Что произойдет, если на мосту будет неверная запись Mac?

Допустим, есть хост H1, H2, коммутатор S1, S2 и S3, мост B1, B2.

Это связано так:

H1 - S1 - B1 - S2 - B2 - S3，
                |
               H2

H2 отправляет кадры на H1.

Затем мы внезапно подключаем H1 к S3. Подобно:

S1 - B1 - S2 - B2 - S3 - H1，
           |
          H2

Затем S2 все еще отправляет кадры в B1, потому что он не знает, что H1 отключен, и B1 тоже этого не знает, он все еще пересылает кадры в S1, S1 получает недопустимый целевой Mac-кадр и заливает его другим порты, а не порт, подключенный к B1.

Итак, означает ли это, что H1 никогда не получит фреймы, отправленные ему, если он не будет активно посылать фреймы, и фрейм по крайней мере должен достигнуть S2?

Спасибо

Источник

3 ответа

@Nevin Уильямс ответ правильный, и вы должны подтвердить / принять этот. Я просто хотел бы добавить пару заметок, которые не помещались в поле для комментариев:

  1. Современные хосты обычно отправляют большое количество трафика (ARP, запросы DHCP, трафик обнаружения услуг / рекламный трафик и т. Д.) При первом подключении, поэтому оказывается, что проблемное состояние обычно вообще не длится долго.

  2. Проблема хостов, перемещающихся много раз и приводящих к тому, что таблицы фильтров сетевых коммутаторов (таблицы CAM) находятся в неправильном состоянии, может быть особенно острой в сетях 802.11 (Wi-Fi), где каждая точка доступа является мостом (коммутатором), и они, как правило, связаны с проводными коммутаторами. Точки доступа Wi-Fi корпоративного класса часто делают небольшие уловки, чтобы быстро устранить плохое состояние, например отправку того, что IEEE 802.11F (протокол точки доступа) называет "кадром обновления уровня 2", который является кадром широковещания, подделанным новая точка доступа выглядит так, как будто она пришла от MAC-адреса только что связанного беспроводного клиента. Это гарантирует, что остальные мосты / коммутаторы в сети видят, что MAC-адрес клиента теперь подключен к новой точке доступа, так что все таблицы фильтров обновляются правильно, даже если беспроводной клиент не отправил многоадресную рассылку. / широковещательный трафик для себя.

Источник

Я считаю, что ваше описание сценария верно во всех аспектах, кроме времени. Запись в таблице CAM для H1 на S2 истечет, если она не получит никаких кадров от H1 в течение сконфигурированного промежутка времени, после чего она будет транслировать эти кадры на все свои порты.

Однако, как только H1 отправляет кадр через S3, либо в H2, либо в ffff.ffff.ffff, таблицы CAM обновятся, чтобы отразить изменение топологии.

Когда уровень PHY падает на старый порт H1s на S1, S1 удалит все записи таблицы CAM, связанные с этим портом, гарантируя, что последующие кадры, адресованные H1, будут соответствующим образом транслироваться, так что другие хосты, подключенные к S1, смогут получать трафик к Новый переключатель H1.

Источник

Есть разные вещи, которые могут случиться, чтобы восстановить связь

  1. Записи в таблицах мостов / коммутаторов могут истечь.
  2. Записи в таблицах ARP (или ND) могут истечь. Когда это произойдет, H1 отправит новую трансляцию, на которую H2 ответит
  3. H1 отправляет пакет по какой-то другой причине.

На практике с ПК это, как правило, не проблема, они достаточно "болтливы", чтобы таблицы переключения быстро обновлялись. Однако у меня была проблема с тестовым оборудованием с поддержкой Ethernet.

Источник
Другие вопросы по тегам