Jump to content
Калькуляторы

Теоретический вопрос про коммутацию

На свич приходит пакет. Свич смотрит в свою таблицу mac-адресов и видит, что mac-адрес назначения(unicast) находится в том же порту из которого пакет пришел. Как поступит свич с этим пакетом? Отбросит или отправит обратно в тот же порт?

Share this post


Link to post
Share on other sites

1 час назад, TheUser сказал:

Не отправит.

Пакет пришел, коммутатор добавил source-mac в таблицу коммутации. Затем коммутатор смотрит на dest-mac. Если такой адрес есть в таблице, то коммутатор отправит этот пакет в нужный порт кроме источника; если нету, то во все порты в данном vlan кроме источника. Так что никак он отправить его назад не должен, да.

Edited by rz3dwy

Share this post


Link to post
Share on other sites

Не отправит, только если это не пон порт элтекса, где включен бриджинг сам на себя. Там отправляет. Попытки объяснить, что так работать не должно, вкупе с ссылками на цискосайты и базовые принципы коммуникации не помогли))

Share this post


Link to post
Share on other sites

8 часов назад, vurd сказал:

Не отправит, только если это не пон порт элтекса, где включен бриджинг сам на себя. Там отправляет. Попытки объяснить, что так работать не должно, вкупе с ссылками на цискосайты и базовые принципы коммуникации не помогли))

А как ONT между собой должны по вашему общаться, если они подключены к одному порту - внутри сплиттера коммутироваться? Покажите ссылку на ваши цискосайты, где это написано ж)

Share this post


Link to post
Share on other sites

А что, PON порт это езернет? Мне казалось там отдельные ОНУ за порты считаются. Ну так логичнее по крайней мере.

Share this post


Link to post
Share on other sites

Вы правы, ShyLion , так и есть, но видимо такая архитектура, что с чипа уходит на свич и там уже обрабатывается со своими особенностями. Главное, что оно работает и у нас на сети в корпоративном сегменте с этим не было проблем.

Share this post


Link to post
Share on other sites

Вроде у некоторых вендоров есть расширения для виртуализации, когда порт может отправлять пакет, если dst mac в том же порту, обратно. У extreme точно что-то было... Это только для целей виртуализации, когда виртуальный бридж в коммутатор переносится. Надеюсь, мне это не приснилось )) у extreme вроде было.

Share this post


Link to post
Share on other sites

Мы делали на 7606 заворот, чтоб через SCE прогнать. Был svi 10 access с одной стороны, svi 18 access с другой. Пока мы жестно на SVI не приколотили разные мак адреса кошка нивкакую не хотела слать трафик в этот заворот.

Share this post


Link to post
Share on other sites

22 часа назад, deputat сказал:

На свич приходит пакет. Свич смотрит в свою таблицу mac-адресов и видит, что mac-адрес назначения(unicast) находится в том же порту из которого пакет пришел. Как поступит свич с этим пакетом? Отбросит или отправит обратно в тот же порт?

Обратно никогда не отправит. По умолчанию отбросит.

Есть два способа сделать так, чтобы этот пакет прошёл дальше - отключение learning либо настройка rspan vlan.

Share this post


Link to post
Share on other sites

В 24.10.2017 в 12:27, dignity сказал:

Вроде у некоторых вендоров есть расширения для виртуализации, когда порт может отправлять пакет, если dst mac в том же порту, обратно. У extreme точно что-то было... Это только для целей виртуализации, когда виртуальный бридж в коммутатор переносится. Надеюсь, мне это не приснилось )) у extreme вроде было.

"hairpin" mode. У джунов есть местами:

https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/bridging-reflective-relay-qfx-series-els.html

Полагаю, под кейс, когда сетевая карта пробрасывается в несколько виртуалок посредством SR-IOV: бриджевать такое на хосте уже не получится.

 

простое отключение learning не завернет фрейм обратно, по крайней мере на современных коммутаторах.

 

 

А само поведение описано еще в IEEE 802.1D 7.7.1 c):

7.7.1 Active topology enforcement
Each Port is selected as a potential transmission Port if, and only if
a) The Port on which the frame was received was in the Forwarding State (7.4), and
b) The Port considered for transmission is in the Forwarding State, and
c) The Port considered for transmission is not the Port on which the frame was received, and
d) The size of the mac_service_data_unit conveyed by the frame does not exceed the maximum size of
mac_service_data_unit supported by the LAN attached to the Port considered for transmission.
For each Port not selected as a potential transmission Port, the frame shall be discarded

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.