Перейти к содержимому
Калькуляторы

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

58 минут назад, deputat сказал:

Отбросит или отправит обратно в тот же порт?

Не отправит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Не отправит.

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

Изменено пользователем rz3dwy

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 Вообще-то лупбак на порту коммутатора.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.