» Одинаковые Мак- и IP-адреса на 2х машинах в пределах подсети

Собственно сабж. Есть 2 компьютера, подключённых к одному свитчу, имеют 2 одинаковых мак-адреса (например, 11:22:33:44:55:66), получили одинаковые IP-адреса (например, 192.168.119.115) по DHCP (либо прописали вручную, неважно). Винда абсолютно никак на сие безобразие не реагирует и даже не заикается На обоих машинах прекрасно работает команда ping, сканируются машины по 137-139 портам, коннект к хабам DC++ без проблем и т.д. Словом, всё прекрасно работает (разве что эти две машины друг друга в упор не видят). Спрашивается, каким образом всё это работает?

Вот например, один из этих компьютеров ставит на пинг какую-то машину (например, 192.168.119.1). Посылаем "ARP WHOHAS" броадкаст, чтобы узнать мак-адрес машины с IP 192.168.119.1. Узнали, посылаем echo-request. Затем компьютер с IP 192.168.119.1 шлёт echo-reply. Какая из двух машин его получит?

И ещё интересует, как можно с таким бороться? Первое, что приходит в голову- написать небольшую программку, которая будет такое дело отслеживать. Или такие уже есть?

Geneus
вряд ли. Только хардварно.
Обсуждалось в подземке.
http://forum.ru-board.com/topic.cgi?forum=55&topic=7355#1
+
filter

Цитата:

(например, 11:22:33:44:55:66),

Ну еще бы...
Присвоил двум сетевым картам широковещательный MAC-адрес и ждет нормальной работы...

Geneus
Легко. Работает по принципу "кто первый встал - того и тапки".

Geneus
У меня такое было, чинил. Проблема была у сетевых карт, встроенных в мамку и у них были одинаковые маки. Решилась проблема перешивкой БИОСа мамки на свежую версию.

bredonosec
Прочитал указанный топик, там нет нужного ответа на вопрос. Ну и насчёт хардварно. Указанный выше свитч- неуправляемый, управляемые пока не трогаем

Andy_user
Насколько я знаю, обычно броадкаст выглядит как FF:FF:FF:FF:FF:FF. Если всё же не нравится этот мак, можно взять какой-нибудь Риалтек, например 00:50:FC:F0:C5:7F.

Sadok
Такого объяснения мне мало Мне интересно, почему не возникает коллизий, никаких конфликтов, как конктретно всё это работает и почему вообще возможна работа? Вот я пробовал делать одинаковые мак + IP только на двух машинах. А если 3,4 и более (надо будет попробовать )? Вот что мне интересно.

Sadok
У меня такой проблемы нет, потому что я прописываю одинаковые маки софтварно, из-под винды.

Подкину немного информации для размышления. Вот что я нашёл по этому поводу http://www.linuxsa.org.au/pipermail/linuxsa/1999-April/006005.html

Здесь утверждается, что такая схема потенциально может работать, если между двумя компьютерами с одним маком + IP находится роутер. Но не даётся ответ на вопрос, а что же будет, если эти компьютеры находятся на одном сегменте.

Цитата:

Насколько я знаю, обычно броадкаст выглядит как FF:FF:FF:FF:FF:FF.

Признаком бродкаста MAC-адреса является наличие "1" в первом бите первого октета адреса.

Цитата:

утверждается, что такая схема потенциально может работать, если между двумя компьютерами с одним маком + IP находится роутер.

Как Вы себе представляете наличие одного и того же IP-адреса в разных подсетях по обеим сторонам роутера ?

Цитата:

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

Нормальной работы не будет потому, что на один посланный IP-пакет (который получат обе машины) придут 2 IP-пакета от каждой из этих машин. И несмотря на то, что на уровне IP вроде бы все гладко, на более высоких уровнях модели OSI (начиная с TCP) будет хаос.

Geneus

Цитата:

Работает по принципу "кто первый встал - того и тапки".
Такого объяснения мне мало Мне интересно, почему не возникает коллизий, никаких конфликтов, как конктретно всё это работает и почему вообще возможна работа?

Коллизии возникают. Месседж в выни может появиться только ежели обе интересующие системы могут через нетбиос общаться. Ежели хоть на одной отрублено - ни она никому ничего не пошлет (на второй месседжа не будет) ни сама не примет (на первой не будет)
А работа именно, как Sadok указал. Постучавшаяся машина передает пакет, соответственно, ответ идет по той же цепочке обратно. Если вставляется в диалог вторая - начинается путаница, машина 1 начинает получать часть пакетов, предназначенных для машины 2, и наоборот. (что с ними делают в общем случае - без понятия, в случае стены они просто дропятся). Если машиа 1 интенсивно качает (происходит интенсивный обмен данными), то всунуться машине 2 весьма трудно. Фигурально выражаясь, тапки отобрать не успевает =)

ЗЫ, когда-то, пару лет тому, проверялось на практике.

В случае 3,4, 5, ... машин, думаю, ничего принципиально не изменится.

Добавлено:
Andy_user

Цитата:

Нормальной работы не будет

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

В коммутаторе есть таблица соответствия MAC-адреса подключенного к порту устройства - номер этого порта коммутатора. При поступлении Ethernet-фрейма на порт от подключенного устройства в таблицу заносится соответствующая запись. Интересно, как ведет себя коммутатор при наличии в одном сегменте сети нескольких устройств с одним MAC-адресом? В таблице могут быть несколько записей с одинаковыми номерами портов коммутатора и разными MAC-адресами - на этом основана атака "MAC flooding". А могут ли быть в таблице коммутатора несколько записей с одинаковым MAC-адресом, но разными номерами портов коммутатора? Или запись одна, но она будет все время изменяться при поступлении на разные порты фреймов с одинаковыми MAC-адресами источника?

Цитата:

Или запись одна, но она будет все время изменяться при поступлении на разные порты фреймов с одинаковыми MAC-адресами источника?

по внешнему эффекту более похоже на это.

Andy_user

Цитата:

Признаком бродкаста MAC-адреса является наличие "1" в первом бите первого октета адреса.

А откуда Вы это взяли? Дайте хотя бы какую-н ссылку. В свою очередь кидаю линк на документ RFC 922 "BROADCASTING INTERNET DATAGRAMS IN THE PRESENCE OF SUBNETS", часть 7 "Broadcast IP Addressing - Conventions"
http://www.faqs.org/rfcs/rfc922.html


Цитата:

Как Вы себе представляете наличие одного и того же IP-адреса в разных подсетях по обеим сторонам роутера?

Прочтите приведённую мною выше ссылку, там написано. Другое дело, что я не пробовал так делать

Geneus


Цитата:

А откуда Вы это взяли? Дайте хотя бы какую-н ссылку.

MAC address. Если в школе учил немецкий MAC-адрес. Ты ж приводишь ссылки на описание IP-адресации. Мы этажом ниже. Посмотри RFC, описывающий MAC-адрес.

Geneus
Я не прав, посыпаю голову пеплом...
"1" в первом бите первого октета MAC-адреса конечно же является признаком не бродкаста, а мультикаста. Несмотря на это, устанавливать эту "единичку" не желательно.

Цитата:

MAC address. Если в школе учил немецкий MAC-адрес. Ты ж приводишь ссылки на описание IP-адресации. Мы этажом ниже. Посмотри RFC, описывающий MAC-адрес.

С английским всё ок, спасибо Что такое МАК-адрес - знаю, это первое. Второе. Всё-таки, в рамках рассматриваемой проблемы (как образуется броадкаст) ссылку я привёл правильно. Читаем:


Цитата:

For simplicity, it should be one not likely to be assigned to a real host. The number whose bits are all ones has this property; this assignment was first proposed in [6]. In the few cases where a host has been assigned an address with a host-number part of all ones.

т.е. все биты должны иметь значение 1. И неважно, IP-адрес это или Ethernet-адрес, т.к.
FF:FF:FF:FF:FF:FF == 11111111:11111111:11111111:11111111:11111111:11111111 == 255.255.255.255.

А RFC я уже и так начитался

PS. Тему, наверное, можно закрывать. Всем спасибо за ответы.

bredonosec

Цитата:

Цитата: Или запись одна, но она будет все время изменяться при поступлении на разные порты фреймов с одинаковыми MAC-адресами источника?

по внешнему эффекту более похоже на это.

Цитата:

А могут ли быть в таблице коммутатора несколько записей с одинаковым MAC-адресом, но разными номерами портов коммутатора?

Могут. Если на всех портах - то из коммутатора (свитча) получится концентратор (хаб).
Проводились эксперименты с целью посниферить в сетке на свитчах.
Хотя, может, наверное и зависнуть...

Цитата:

FF:FF:FF:FF:FF:FF == 11111111:11111111:11111111:11111111:11111111:11111111 == 255.255.255.255.

Последнее равенство "хромает"...

NightSpamer

Цитата:

Могут. Если на всех портах - то из коммутатора (свитча) получится концентратор (хаб).

Хочешь сказать, что коммутатор копирует фреймы в порты с одинаковыми MAC-адресами? Но это противоречит результатам проведенного мной эксперимента (см. выше).

Цитата:

Проводились эксперименты с целью посниферить в сетке на свитчах.

Сеть на машинах с одинаковыми MAC-адресами и интенсивным обменом не сбоила? Модель коммутатора в студию! У меня HP ProCurve 2650.

Подниму старую тему.

А что будет если на двух интерфейсах разные IP, но одинаковый MAC?
Будут ли пакеты доходить каждому по назначению?

Nikkolo Если эти интерфейсы смотрят в разные сетевые
сегменты, почему нет?

Цитата:

Nikkolo Если эти интерфейсы смотрят в разные сетевые
сегменты, почему нет?

А если в одной подсети с одним шлюзом?
Вроде бы работает. Хоть это и неправильно.

Nikkolo
Цитата:

А если в одной подсети с одним шлюзом?

Собственно, несколько айпи на одном МАКе - не криминал.
Пример - айпи алиасы, прокси арп...
А вот одинаковые айпи на разных МАКах - это безобразие.
Поскольку нарушается обмен данными на канальном уровне.

Цитата:

Nikkolo
Цитата:
А если в одной подсети с одним шлюзом?  
Собственно, несколько айпи на одном МАКе - не криминал.
Пример - айпи алиасы, прокси арп...
А вот одинаковые айпи на разных МАКах - это безобразие.
Поскольку нарушается обмен данными на канальном уровне.

Т.е. даже на разных интерфейсах можно прописать один MAC?
К примеру когда на моем сервере в дата-центре один IP у хостовой ОС, а другой IP - виртуальной ОС (при одном физическом внешнем сетевом адаптере), - можно сделать у этих виртуальных интерфейсов один MAC?.

UPD
Попробовал - не вышло.
Как только запускаю виртуалку - отваливается хост. Выключаю виртуалку - хост возвращается в сеть.
Хотя люди пишут что у них получалось.
Ок, вопрос снят. Спасибо

Nikkolo
Цитата:

Т.е. даже на разных интерфейсах можно прописать один MAC?

Тут уже многое зависит от сетевых драйверов
канального уровня конкретной системы.
Тонкостей реализации которых мы не знаем.

Цитата:

Тут уже многое зависит от сетевых драйверов  
канального уровня конкретной системы.
Тонкостей реализации которых мы не знаем.

Немного уже в сторону от темы - посоветуйте пожалуйста, что можно сделать в моем случае - можно ли обойтись без NAT?
Читал в учебниках про "уполномоченного агента ARP" - получится ли здесь так сделать?

Nikkolo
Цитата:

можно ли обойтись без NAT?

Кажется, начинаю понимать конечную цель.
У сервера в датацентре один айпи, хочется и на виртуалке тоже иметь "белый".
Боюсь, без НАТ ничего не выйдет.
Цитата:

Читал в учебниках про "уполномоченного агента ARP"

Если имеется в виду proxy arp, то здесь это не при делах.
Его применяют тогда, когда хотят связать через роутер или VPN
компы так, чтобы они выглядели как в одном сегменте сети.
Скажем, есть сеть 10.1.1.0, подключился извне клиент по VPN, сервер выдал ему адрес 10.1.1.200.
Клиент пингует, допустим, ПК с адресом 10.1.1.25. Пакет уходит на сервер, потом на ПК.
ПК видит, что обратный адрес в этой же сети, поэтому отправляет арп запрос,
"у кого адрес 10.1.1.200, пришли мне свой МАК". Но клиент запроса увидеть
не может, бродкасты через впн не ходят. Запрос зато видит сервер, и он
отправляет ПК свой МАК. ПК отправляет по нему ответный пакет,
а сервер отправляет его клиенту.
Допустим, к серверу подключились десяток клиентов, с 10.1.1.200 по 10.1.1.209.
И все общаются с ПК. У ПК в арп таблице будет 11 записей с одним МАК,
но разными айпи (сервера и 10 клиентов)

Вроде бы ситуация похожа на мою.
У меня два белых IP на одном MAC, и у провайдера шлюз - общий для всей подсети в котором в т.ч. не только я.
Выходит у провайдера уже прописаны два моих IP на один MAC.
Имеет ли смысл использовать у себя proxy-arp (спасибо за правильный термин - теперь легче будет искать) , чтобы "спрятать" за ним два моих виртуальных интерфейса?

Nikkolo
Цитата:

У меня два белых IP на одном MAC

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

Цитата:

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

Они на одном кабеле и MAC жестко привязан.

Nikkolo
Цитата:

Они на одном кабеле и MAC жестко привязан.

То, что они на одном кабеле - понятно.
А вот к какому МАК они привязаны, по-моему,
предмет разговора с администрацией датацентра или провайдера,
я не в курсе организационной структуры площадки и вашего договора.