[Iskatel_S]

Всем привет! Есть у меня подозрение, что я неправильно понимаю один из базовых сетевых принципов потому, что когда-то неверно понял прочитанное. Вот есть стек протоколов TCP/IP, в нём есть протоколы: TCP, UDP, ICMP  и т. д., и есть ARP - протокол 3 уровня, необходимый для сопоставления MAC-адреса IP-адресу, мне казалось, что должен существовать аналогичный протокол 2 уровня, необходимый для сопоставления MAC-адресов портам управляемого свитча, ну то есть, любое сетевое устройство, даже если оно не обменивается в настоящее время ни с кем сетевым трафиком обязано отправлять в сеть через какие-то промежутки времени пакеты, содержащие информацию "я - жив", потому что иначе его MAC-адрес исчезнет из сети, правильно?

Вот мне хочется понять как это работает не в общем, а в конкретном понимании. Вот есть формат кадра "Ethernet II", содержащий MAC источника, MAC адресата, тег IEEE 802.1Q (если есть), сигнатуру, вложенный пакет 3 уровня и код типа этого самого пакета (EtherType), лезем в статью https://en.wikipedia.org/wiki/EtherType#Values и смотрим какие EtherType бывают: ARP, RARP, IPv4, IPv6, PPPoE, MPLS, ещё есть протоколы обнаружения от Cisco, MikroTik и прочих производителей, но я так понимаю, что если устройство у нас - самое обычное, например китайская IP-камера, не использующая IPv6 то источать она будет только 2 вида трафика из всего этого многообразия: ARP и IPv4. Так собственно вопрос, в рамках какого протокола будут отправляться пакеты, содержащие информацию "я - жив", ARP?
Или вот пример. С коммутаторами D-Link все работали наверное, сталкивались наверное с ситуацией когда к коммутатору подключено что-нибудь, другой коммутатор, например, на котором вообще нет трафика, и мак этого коммутатора в "show fdb" будет не виден до тех пор пока ты этот коммутатор не начнёшь пинговать. Чем это объясняется?

[StSphinx]

> мне казалось, что должен существовать аналогичный протокол 2 уровня, необходимый для сопоставления MAC-адресов портам управляемого свитча

 

Нет. Сопоставление "MAC-Порт" это лишь функция оборудования в рамках самой технологии коммутации.

 

> содержащие информацию "я - жив"

 

Нет никакого "я жив" в Ethernet. Устройство может быть подключенным к сети, молчать и при этом нормально работать тогда, когда это нужно.

 

>С коммутаторами D-Link все работали наверное, сталкивались наверное с ситуацией когда к коммутатору подключено что-нибудь, другой коммутатор, например, на котором вообще нет трафика, и мак этого коммутатора в "show fdb" будет не виден до тех пор пока ты этот коммутатор не начнёшь пинговать. Чем это объясняется?

 

Тем, что есть время жизни MAC адреса в FDB.

Вам прямо серьезно надо заняться теорией, без обид. Возьмите хороший учебник. Хоть того же Олиферова. Или книжку для подготовки к треку CCNA.

[jffulcrum]

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

когда к коммутатору подключено что-нибудь, другой коммутатор, например, на котором вообще нет трафика, и мак этого коммутатора в "show fdb" будет не виден до тех пор пока ты этот коммутатор не начнёшь пинговать. Чем это объясняется?

Потому как MAC-адрес - он НЕ у коммутатора, он у УПРАВЛЯЮЩЕГО ИНТЕРФЕЙСА коммутатора (обычно виртуального vlan1, но может быть и физического management port), и пока вы конкретно к этому интерфейсу не обратитесь, пакетов от него особого резона ожидать нет. Исключения составляют работа протоколов вроде STP или IGMP, когда коммутатору воленс-ноленс придется создать виртуальный мост и слать от него пакеты, хотя mac-адрес моста обычно генерится рандомно, а не берется с управляющего интерфейса. 

[UglyAdmin]

2 hours ago, Iskatel_S said:

в рамках какого протокола будут отправляться пакеты, содержащие информацию "я - жив", ARP?

Некоторые устройства так и делают, раз во сколько-то секунд отправляют ARP-пакет "кто здесь <IP>, спрашивает <IP>". Не знаю, зачем, в стандартах такого нет.

 

2 hours ago, Iskatel_S said:

содержащие информацию "я - жив", потому что иначе его MAC-адрес исчезнет из сети, правильно

Ну исчезнет и исчезнет, что в этом такого?

MAC есть в ARP-кэше устройства, которое с ним обменивается (маршрутизатора, например), да и всегда его можно заново запросить.

[azhur]

36 минут назад, UglyAdmin сказал:

Некоторые устройства так и делают, раз во сколько-то секунд отправляют ARP-пакет "кто здесь <IP>, спрашивает <IP>". Не знаю, зачем, в стандартах такого нет.

https://wiki.wireshark.org/Gratuitous_ARP.md Может оно?

[Iskatel_S]

Цитата

Некоторые устройства так и делают, раз во сколько-то секунд отправляют ARP-пакет "кто здесь <IP>, спрашивает <IP>". Не знаю, зачем, в стандартах такого нет.

Это кстати удобно, когда тебе принесли несброшенный девайс, который работал в чужой сети, ты открываешь Wireshark и узнаёшь IP девайса. Я почему и думал, что это стандарт.

[UglyAdmin]

3 hours ago, azhur said:

Может оно?

Эвон оно чё, Михалыч... А когда флудят ARP-ответами, это как называется?.

[Ivan_83]

5 hours ago, UglyAdmin said:

Некоторые устройства так и делают, раз во сколько-то секунд отправляют ARP-пакет "кто здесь <IP>, спрашивает <IP>". Не знаю, зачем, в стандартах такого нет.

Это обычный ARP запрос.

Странные у вас стандарты :)

 

4 hours ago, azhur said:

https://wiki.wireshark.org/Gratuitous_ARP.md Может оно?

Это обычный ARP ответ только отправляемый на броадкаст мак и без запроса.

 

 

7 hours ago, Iskatel_S said:

мне казалось, что должен существовать аналогичный протокол 2 уровня, необходимый для сопоставления MAC-адресов портам управляемого свитча, ну то есть, любое сетевое устройство, даже если оно не обменивается в настоящее время ни с кем сетевым трафиком обязано отправлять в сеть через какие-то промежутки времени пакеты, содержащие информацию "я - жив", потому что иначе его MAC-адрес исчезнет из сети, правильно?

Нет.

 

Изначально такой проблемы не было, тк везде были хабы или всякие другие штуки типа коаксиала где домен коллизий (считай среда передачи) была общей.

Когда отрасль развилась стали делать коммутаторы, где домен коллизий (среду передачи) сделали индивидуальной - per port, тогда внутри свич чипа потребовалось поддерживать таблицу соответствия мак-порт.

Сделали очень просто: если в таблице ничего не нашлось - шлём на все порты. При этом все src MAC от входящих пакетов должны как раз в эту таблицу попадать. И там обычно есть "сборка мусора" - те удаление старых записей по таймауту.

 

Параллельно с этим, опять же аттавизм можно сказать прошлых лет, это встроенный в сетевой адаптер MAC фильтр, который обычно включён по умолчанию и отбрасывает все пакеты кроме широковещательных (броадкаст) и пакетов чей MAC в фильтр таблице сетевухи.

Всякие tcpdump переводят карту в promisc режим - те отключают этот фильтр чтобы ловить все пакеты.

Мультикаст оно тоже отбрасывает пока ОС не подпишется на нужную группу и тогда мак добавляется в фильтр. Когда мультикаст групп становится больше чем драйвер/железка может аппаратно то драйвер обычно по тихому переводит карту в promisc.

Раньше это сильно помогало снизить нагрузку на проц, потому что во времена 486-п1 работа с сетью даже на 10м была задачей затратной, и учитывая что при передачи файла с одного компа на другой все компы в локалке ловили все пакеты - это могло и становилось проблемой.

Сейчас по сути свитч фильтрует почти все лишние пакеты, да производительности столько что даже без аппаратных оффлоадов переварить 5г не большая проблема, у меня браузер поди больше жрёт чем ОС потребуется чтобы отправить в /dev/null столько трафика :)

 

Во времена п2-п3 сетевушки 3ком рулили потому что аппаратно оффлоадили все контрольные суммы, что позволяло все 100м юзать не сильно нагружая проц, а вот всякие реалтек (8139* в те времена) с программной обработкой заметно так грузили проц, на п2 производительности проца не хватало чтобы утилизировать 100м линк.

 

 

Можно даже посмотреть программную реализацию свича эзернет во FreeBSD: https://github.com/freebsd/freebsd-src/blob/main/sys/netgraph/ng_bridge.c

[UglyAdmin]

18 hours ago, Ivan_83 said:

Это обычный ARP запрос.

Да, только IP адрес одинаковый, и запрашиваемый, и запрашивающий.

[jffulcrum]

21 час назад, Ivan_83 сказал:

Во времена п2-п3 сетевушки 3ком рулили потому что аппаратно оффлоадили все контрольные суммы, что позволяло все 100м юзать не сильно нагружая проц, а вот всякие реалтек (8139* в те времена) с программной обработкой заметно так грузили проц, на п2 производительности проца не хватало чтобы утилизировать 100м линк.

Не совсем так. Оффлоадинг контрольных сумм помогал только в голом DOS или на совсем дохлом железе, в 32-разрядном режиме он только мешал, т.к. уже первые пеньки обсчитывали со скоростью большей, чем потроха сетевухи. Козырь 3Com был в другом - bus-master и DMA, пакеты помещались непосредственно в ОЗУ, откуда можно было их забирать напрямую. Конкретно у 8139 же были свои проблемы, из-за которых он тупил: пакеты он помещал не в конечные буферы, а в промежуточные, следующим ходом драйвер делал выравнивание, и лишь на третий заход драйвер перекладывал в общедоступные буферы, откуда данные мог забирать уже хост. Из-за этого даже P2 не вытаскивали с них полной полосы, потому что даже при благоприятных условиях требовалось втрое больше циклов, чем с нормальными сетевушками. Dec21041, к примеру, никаких offload не имел, он был просто bus-master и сразу клал в память, потому уже какой-нибудь P166 вытаскивал полный 100Мбит/с без предельного напряга (но не в дуплексе, конечно). 

 

P.S. У 3Com был еще один скрытый плюс, благодаря которому он в тогдашних тестах всех и нагибал - читерство с IPG, точнее его ужимание. В 3Com разумно предположили, что настоящих идиотов, сделающих сеть 500 метров одним широковещательным сегментом - не будет, у всех будет меньше, а значит и IPG можно сделать меньше, пулять кадры быстрее. Но в ситуации, когда в сети были компы с картами других производителей, которых жизнь к такому не готовила, получалось, что хосты с 3Com оккупировали большую часть времени сети, а остальные сосали. С приходом коммутаторов все это работать в большей части перестало, хотя друг к другу 3Com все еще могли пользоваться преимуществами сниженного IPG, и вытаскивать побольше.

[pppoetest]

В 13.05.2023 в 22:15, jffulcrum сказал:

P.S. У 3Com был еще один скрытый плюс, благодаря которому он в тогдашних тестах всех и нагибал - читерство с IPG, точнее его ужимание.

Интересно. Можно поподробнее, гугель ничего внятного на этот счёт не выдаёт.

[jffulcrum]

@pppoetest Это все было еще в догугельные времена, подробности наверное остались в эхах фидо. Лет эдак двадцать назад я видел у Cisco на портале уведомление об этой особенности, в статье о совместимости сетевух и свитчей того времени, можно попробовать порыться в доках на цисковские свитчи тех далеких лет, типа каких-нибудь прости хоспади Catalyst 1900 (хотя, я смотрю сейчас, даже материалы по 2950 некоторые до сих пор анально огорожены, неужто кто-то до сих пор подписки смартнета на них оплачивает?)

[Ivan_83]

https://www.quora.com/The-Ethernet-frame-offers-a-minimum-packet-size-of-512-bits-How-do-the-other-versions-of-Ethernet-meet-this-requirement-What-is-the-reason-behind-this-minimum-limit

но это общая теория, видимо они подкрутили таймер CD.

[Iskatel_S]

Так, вывод, любое устройство в Ethernet может молчать и его MAC-адрес будет при этом пропадать сиз mac-таблиц коммутаторов, но тем не менее к устройству можно будет обратиться, так как оно обязано ответить на броадкаст. Тогда вопрос, каким инструментом можно воспользоваться (желательно под Windows), чтобы отправить броадкаст и выловить трафик в Wireshark?

[dr Tr0jan]

@Iskatel_S pierf или nemesis

[Ivan_83]

53 minutes ago, Iskatel_S said:

устройство в Ethernet может молчать и его MAC-адрес будет при этом пропадать сиз mac-таблиц коммутаторов, но тем не менее к устройству можно будет обратиться, так как оно обязано ответить на броадкаст.

1. Есть конфигурации static arp - когда сам арп протокол отключён а нужные соответствия забиты в конфиги руками.

2. Иногда встречаются извращенцы которые и это фильтруют приближаясь к п1, но обычно у дураков не хватает знаний на такое )

3. IPv6 only девайсы не используют броадкаст и ARP, у них ND через multicast.

 

57 minutes ago, Iskatel_S said:

желательно под Windows

Венда с сетями кое как в стандартных юзкейсах работает, хорошо хоть после 98 перестала требовать перезагрузки после изменения IP адреса.

[Iskatel_S]

Нашёл типичное молчачее устройство - древний VoIP-шлюз Linksys SPA2102, на ethernet-порту у него по умолчанию 192.168.0.1, если стоит какой-то другой ip и это не знать - то вычислить его при помощи wireshark невозможно, от железки не будет приходит ничего.

 

Цитата

pierf или nemesis

Вообще не понял как с этим работать

[Ivan_83]

Это не совсем так.

Обычно такие шлюзы настроены сами куда то подключатся, к тому же сип серверу, а для этого им надо по арп отрезолвить адреса, а это автоматом броадкаст запросы.

 

Но если ждать лень - arp-scan в помощь.

[edo]

В 12.05.2023 в 14:10, Iskatel_S сказал:

мне казалось, что должен существовать аналогичный протокол 2 уровня, необходимый для сопоставления MAC-адресов портам управляемого свитча, ну то есть, любое сетевое устройство, даже если оно не обменивается в настоящее время ни с кем сетевым трафиком обязано отправлять в сеть через какие-то промежутки времени пакеты, содержащие информацию "я - жив", потому что иначе его MAC-адрес исчезнет из сети, правильно?

вроде бы на это не ответили.

свитч пакеты, адресованные на неизвестные mac-адреса, рассылает по всем портам.

впрочем, это неважно, так как если говорить по ipv4, то перед обменом будет arp-запрос (который и так броадкастится)

[ice638879]

Because the MAC address is NOT at the switch, it is at the MANAGEMENT INTERFACE of the switch (usually virtual vlan1, but it can also be a physical management port), and until you specifically address this interface, there is no particular reason to expect packets from it. The exceptions are the work of protocols like STP or IGMP, when the volens-nolens switch will have to create a virtual bridge and send packets from it, although the mac-address of the bridge is usually generated randomly, and not taken from the control interface. Remini

Изменено 12 августа, 2023 пользователем ice638879

[Ivan_83]

On 7/21/2023 at 10:10 PM, edo said:

впрочем, это неважно, так как если говорить по ipv4, то перед обменом будет arp-запрос (который и так броадкастится)

Может и не быть никакого запроса:

1. статик арп

2. время жизни арп кеша может превышать время жизни кеша мак в коммутаторе

3. у коммутатора может вымыть кеш и там опять же ничего не найдётся

4. у коммутатора может быть отключено обучение вообще

[karpa13a]

Цитата

 А когда флудят ARP-ответами, это как называется?

говнософт)

особенно это доставляет проблем кривонастроенному вайфаю

намедни наблюдал картину общения dhcp:

клиент: бродкастом: а дайте ипе?

сервер дхцп: вот твой ипе и прочие настройки

клиент: это точно мои настройки?

сервер: неа, это не твои настройки

 

ну и повторялось это несколькими клиентами, бродкастами на скорости сколько могли выдать устройства-сеть)