deputat Опубликовано 23 октября, 2017 · Жалоба На свич приходит пакет. Свич смотрит в свою таблицу mac-адресов и видит, что mac-адрес назначения(unicast) находится в том же порту из которого пакет пришел. Как поступит свич с этим пакетом? Отбросит или отправит обратно в тот же порт? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TheUser Опубликовано 23 октября, 2017 · Жалоба 58 минут назад, deputat сказал: Отбросит или отправит обратно в тот же порт? Не отправит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rz3dwy Опубликовано 23 октября, 2017 (изменено) · Жалоба 1 час назад, TheUser сказал: Не отправит. Пакет пришел, коммутатор добавил source-mac в таблицу коммутации. Затем коммутатор смотрит на dest-mac. Если такой адрес есть в таблице, то коммутатор отправит этот пакет в нужный порт кроме источника; если нету, то во все порты в данном vlan кроме источника. Так что никак он отправить его назад не должен, да. Изменено 23 октября, 2017 пользователем rz3dwy Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 23 октября, 2017 · Жалоба Вообще-то лупбак на порту коммутатора. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 23 октября, 2017 · Жалоба Не факт, что петля. Спуфинг может. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 23 октября, 2017 · Жалоба Не отправит, только если это не пон порт элтекса, где включен бриджинг сам на себя. Там отправляет. Попытки объяснить, что так работать не должно, вкупе с ссылками на цискосайты и базовые принципы коммуникации не помогли)) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
deputat Опубликовано 23 октября, 2017 · Жалоба Понял. Спасибо большое. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
astotal Опубликовано 24 октября, 2017 · Жалоба 8 часов назад, vurd сказал: Не отправит, только если это не пон порт элтекса, где включен бриджинг сам на себя. Там отправляет. Попытки объяснить, что так работать не должно, вкупе с ссылками на цискосайты и базовые принципы коммуникации не помогли)) А как ONT между собой должны по вашему общаться, если они подключены к одному порту - внутри сплиттера коммутироваться? Покажите ссылку на ваши цискосайты, где это написано ж) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 24 октября, 2017 · Жалоба А что, PON порт это езернет? Мне казалось там отдельные ОНУ за порты считаются. Ну так логичнее по крайней мере. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
astotal Опубликовано 24 октября, 2017 · Жалоба Вы правы, ShyLion , так и есть, но видимо такая архитектура, что с чипа уходит на свич и там уже обрабатывается со своими особенностями. Главное, что оно работает и у нас на сети в корпоративном сегменте с этим не было проблем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dignity Опубликовано 24 октября, 2017 · Жалоба Вроде у некоторых вендоров есть расширения для виртуализации, когда порт может отправлять пакет, если dst mac в том же порту, обратно. У extreme точно что-то было... Это только для целей виртуализации, когда виртуальный бридж в коммутатор переносится. Надеюсь, мне это не приснилось )) у extreme вроде было. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Butch3r Опубликовано 24 октября, 2017 · Жалоба Мы делали на 7606 заворот, чтоб через SCE прогнать. Был svi 10 access с одной стороны, svi 18 access с другой. Пока мы жестно на SVI не приколотили разные мак адреса кошка нивкакую не хотела слать трафик в этот заворот. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdc Опубликовано 24 октября, 2017 · Жалоба 22 часа назад, deputat сказал: На свич приходит пакет. Свич смотрит в свою таблицу mac-адресов и видит, что mac-адрес назначения(unicast) находится в том же порту из которого пакет пришел. Как поступит свич с этим пакетом? Отбросит или отправит обратно в тот же порт? Обратно никогда не отправит. По умолчанию отбросит. Есть два способа сделать так, чтобы этот пакет прошёл дальше - отключение learning либо настройка rspan vlan. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mystray Опубликовано 25 октября, 2017 · Жалоба В 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...