Обнаружен странный эффект, про который не знаю, что и думать. На ПК реализован UDP клиент и установлены две сетевые карты, условно назовем интерфейс А и интерфейс Б. IP и маски для карт установлены вручную так, что обе карты принадлежат одной подсети. Легально ли так назначать настройки карт?

Если легально, то наблюдаем следующий глюк. При запуске клиента, ARP запрос посылается, как и положено, в оба интерфейса А и Б. Ответ, тоже как и положено, приходит только из одного интерфейса, предположим Б, туда подсоединен сервер. И после этих событий, винды вдруг начинают слать UDP пакеты совсем в другой интерфейс А, совсем не в тот, откуда был получен ARP ответ сервера.

Как интерпретировать эту ситуацию? Если нельзя назначать два интерфейса в одну подсеть, то почему Винды не ругаются на эту ошибку? А если можно, то откуда берется наблюдаемая в Виндах путаница с интерфейсами и как с ней бороться?

Разумеется нет. Две разных подсети и никаких проблем. Если нужно, что-бы подсети видели друг-друга, то поднять роутинг.

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


В-общем случае - назначать можно, но тогда и физически эти интерфейсы должны "смотреть" в одну подсеть, а у Вас, как я понял, это не так.


Если там просто разная физика и хочется одну подсеть, то есть более простой вариант - бридж.

Для UDP (да и для любого IP-трафика) лучше маршрутизировать на уровне L3. Меньше мусора летать будет. Мост - это L2, и применять его стоит только в специальных случаях (например, raw-ethernet).

Это да, но с любой маршрутизацией админского труда больше. Впрочем, говорить пока не о чем - топикстартер про свою ситуацию больше просветит, тогда можно будет и совет более подходящий дать.

Не стоит route add выдавать за сакральное одминское знание, доступное только избранным



Ну можем пофлудить ))

Любопытно, у меня сейчас гигабитный проводной сегмент подключен к WiFi через мост (в не очень быстрый инет оно так ходит + доступ к сетевому принтеру), я в WiFi только ARP и прочий немногочисленный broadcast вижу - все остальное встроенный в мост гигабитный свитч фильтрует, так что объем мусора при удачной топологии - минимальный. Возможно, правильнее было бы вместо моста поставить роутер и сделать "через L3", но я и так уже запарился свою домашнюю сетку с десятком хостов админить - разбивать ее еще и на подсети? - не, нафиг, нафиг.



Будете смеятся но я таким знанием не владею . В свой сетевой стек встроил все "концы" для возможной разработки марштуризатора, но "route" ни разу не набирал

Да с удовольствием

Свичи L2 вообще ничего не фильтруют. Если не глючат

Вот если там в сетке еще какое IPTV полетит, мало не покажется

А что под L2 подразумевается? Канальный уровень? Так свичи сейчас умные пошли (да вроде бы, по определению, в отличие от хабов, всегда такими и были) знают что такое MAC-адрес и с чем его кушать.

Так это и есть L2. L3 - это уже IP.

Угу, так свитч именно по L2 и фильтрует - смотрит на MAC-адрес и передает адресный (не широковещательный) пакет только на нужный порт, где, по мнению свича, подключен получатель. А на остальные порты этот пакет не попадает - разве это не фильтр?

Фильтр. Но броадкаст-то он транслирует напрямик всем.

Плюс возможные переполнения таблиц по MAC-адресам.

Дык, пока лично в моей сетки того бродкаста - кот наплакал. IPTV - в перспективе, но оно ж вроде как multicast использует?

Интересно, реально бывает? Сейчас недорогим 8-портовым свичом с CAM в 4K MAC-адресов никого не удивить.

В Вашей - возможно, а вот что у топикстартера?



Лехко Например, от вирусни.

Ну,это понятно, умеючи-то... что хошь... сломать можно . И, скорее всего, при наличии вирусни проблема переполнения таблиц свича будет не самой главной.
По-ходу напугали мы топикстартера флудом - нету от него никакой новой информации