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

299
dspjm

Допустим, есть хост 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?

Спасибо

0
Разве он не «проактивно отправляет кадры», когда он выполняет обнаружение DHCP при подключении к S3? deed02392 10 лет назад 0
"... H1 получает недопустимый фрейм Mac назначения" ... Что? Steven K 10 лет назад 0
@StevenKath Извините, H1 должен быть S1, исправлено. dspjm 10 лет назад 0

3 ответа на вопрос

2
Nevin Williams

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

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

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

2
Spiff

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

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

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

+1, и ARP в значительной степени решает проблему до тех пор, пока ARP H1 не кэшируется соответствующими сторонами. Однако, когда люди отсоединяют кабели, единственное, что может привести к быстрому схождению топологии, - это STP TCN, но это маловероятно, когда почти все используют portfast по умолчанию в наши дни. Mike Pennington 10 лет назад 0
0
plugwash

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

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

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

Похожие вопросы