трансляция в vPC

Reply to трансляция в vPC on Thu, 26 Feb 2026 21:59:18 GMT

MHM Cisco World — Thu, 26 Feb 2026 21:59:18 GMT

С точки зрения S1 и S2, когда они получают широковещательное сообщение, они рассылают его на все порты
, кроме
того, с которого они его получили. Таким образом, S1 и S2 имеют портовый канал и, получая широковещательную передачу от одного канала портового канала, не рассылают ее повторно по другому каналу в том же портовом канале. Это поведение является стандартным и не может быть изменено.

Reply to трансляция в vPC on Thu, 26 Feb 2026 21:59:17 GMT

Suprit Chinchodikar — Thu, 26 Feb 2026 21:59:17 GMT

@Dawei
,
значит, хеширование происходит на уровне сервера S1, верно? Можно ли вручную определить, по какому каналу должен проходить трафик? Также могут ли оба коммутатора 9k1 и 9k2 работать в режиме «активный-активный»? Если да, то каким может быть сценарий в данном случае? И как в этом случае будет работать широковещательная передача?

Reply to трансляция в vPC on Thu, 26 Feb 2026 21:59:16 GMT

Dawei — Thu, 26 Feb 2026 21:59:16 GMT

Привет, Суприт, 1. Трафик широковещания может иметь хэш 9k1 или 9k2, в зависимости от хэша S1.
1.1 Если широковещательный пакет имеет хэш 9k1, 9k1 будет передавать его в S2 и на соседний канал. 9k2 будет принимать широковещательный пакет, но не будет передавать его в S2 (механизм предотвращения петли vPC: когда vPC получает пакет с соседнего канала, он не отправляет его на порты членов vPC).
1.2 Если хэш широковещательного пакета равен 9k2, 9k2 будет рассылать его в S2 и на соседний канал. 9k1 будет получать широковещательный пакет, но не будет рассылать его в S2 (по той же причине).
1.3 Причина, по которой нам нужно затопить пакеты на peer-link, заключается в том, что на peer-switch могут быть некоторые осиротевшие порты, и нам нужно убедиться, что осиротевшие порты могут получить широковещательный пакет.
2. Трафик S2->S1 аналогичен трафику S1->S2. Трафик будет хешироваться в 9k1 или 9k2, и будет применяться тот же механизм.