Сетевые протоколы и т.п.

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

Не должны, если не было поднята PNAT/NATP/NAT — ARP/RARP начинает конфликтовать и проблемы с кэшами ARP на свитчях начинают возникать. Нормальный свитч/шлюз/раутер тут же должен отрапортовать по ICMP, если приходят один и тот же IP и/или МАС на разные порты по запросу ARP/RARP.

Mishka> Нормальный свитч...
Предположу, что в задаче выше в реальности не свитч, а хаб. С ним такой прикол вполне возможен.

Mishka> Не должны, если не было поднята PNAT/NATP/NAT — ARP/RARP начинает конфликтовать и проблемы с кэшами ARP на свитчях начинают возникать. Нормальный свитч/шлюз/раутер тут же должен отрапортовать по ICMP, если приходят один и тот же IP и/или МАС на разные порты по запросу ARP/RARP.
Коммутатору вообще до фонаря IP, а для внешнего маршрутизатора порт один, - тот который является выходом коммутатора к которому подключены два одинаковых IP с разными MAC.
Допустим, ближайший роутер обнаружил такую ситуацию, что, кстати, маловероятно, - это не его дело, что там происходит в чужом оборудовании, и что он должен сделать?
Как я понял, он просто меняет соответствие в ARP по ходу поступления новых пакетов и всё. TCP при этом работает, а вот VoIP портится.

Mishka>> Нормальный свитч...
Полл> Предположу, что в задаче выше в реальности не свитч, а хаб. С ним такой прикол вполне возможен.
Нет, это не хаб, что свичу, что хабу абсолютно до фонаря что содержится внутри фрейма.
Свич только что знает за каким портом какие маки находятся.

Lamort> Как я понял, он просто меняет соответствие в ARP по ходу поступления новых пакетов и всё. TCP при этом работает, а вот VoIP портится.
Что-то я не понимаю.
Вот у нас пришел свитчу пакет для IP ххх.zzz.yyy.www - никто не будет утверждать, я надеюсь, что пакеты имеют в заголовке MAC-адрес получателя.
Что далее делает свитч? Свитч лезет в свою таблицу соответствия своих портов IP-адресам и... Получает коллизию.
Поскольку свитч должен знать не только за каким портом у него не MAC-адреса, но и за каким портом у него IP-адреса, поскольку в заголовках IP-пакетов именно они.
Мы еще не дошли до канального уровня, где используются MAC-адреса.

Полл> Что-то я не понимаю.
Полл> Вот у нас пришел свитчу пакет для IP ххх.zzz.yyy.www - никто не будет утверждать, я надеюсь, что пакеты имеют в заголовке MAC-адрес получателя.
Вы это в порядке юмора?

Свитч ничего не знает про пакеты, он обрабатывает фреймы Ethernet.

Полл> Что далее делает свитч? Свитч лезет в свою таблицу соответствия своих портов IP-адресам и... Получает коллизию.

Это называется таблица ARP, только она не в свиче, а в роутере, к которому подсоединена подсеть с данным IP. Если приходит пакет с другим маком, он просто меняет запись в таблице ARP.

Полл> Поскольку свитч должен знать не только за каким портом у него не MAC-адреса, но и за каким портом у него IP-адреса, поскольку в заголовках IP-пакетов именно они.
Полл> Мы еще не дошли до канального уровня, где используются MAC-адреса.

Вы не ту штуковину называете "свитчом", только и всего. Свич или, по-русски говоря, коммутатор, это устройство канального уровня модели TCP/IP.

Lamort> Вы не ту штуковину называете "свитчом", только и всего. Свич или, по-русски говоря, коммутатор, это устройство канального уровня модели TCP/IP.
Ты прав, я не об том свитче говорю:
http://ru.wikipedia.org/wiki/...
Более сложные коммутаторы позволяют управлять коммутацией на сетевом (третьем) уровне модели OSI. Обычно их именуют соответственно, например «Layer 3 Switch» или сокращенно «L3 Switch».
________________________________________________________
Был не прав, прошу прощения. Может быть, у тебя свитч с гибридной коммутацией - у него разные правила для пакетов разного размера?

Lamort>> Вы не ту штуковину называете "свитчом", только и всего. Свич или, по-русски говоря, коммутатор, это устройство канального уровня модели TCP/IP.
Полл> Ты прав, я не об том свитче говорю:
Да, есть такое, "маршрутизатор и коммутатор" в одной железке, - не люблю такие устройства, поскольку часто возникает задача, "взять и отделить коммутатор для работы в другом месте".

Полл> Был не прав, прошу прощения. Может быть, у тебя свитч с гибридной коммутацией - у него разные правила для пакетов разного размера?
Это самый обычный тупорылый DES-1008 на 8 портов.

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

Lamort> Собственно говоря, юмор в том состоит, что ARP не следит за тем, что делается с положением IP, - какая ему разница, меняется там MAC или не меняется.
Собственного говоря, он и задуман так, чтобы работать при физическом изменении положения MAC-адресов.
У тебя получилось так, что два адреса работали "попеременно", и ничто не подняло шухер по этому поводу.
Забавно.

Полл> Что далее делает свитч? Свитч лезет в свою таблицу соответствия своих портов IP-адресам и... Получает коллизию.
Почему же? Если свитч не обнаружил MAC в ARP, то он посылает широковещательный запрос по IP, а получив ответ, переписывает соответствия порта-IP-MAC. Ему то не по рангу знать, что DHCP творит, резервирует адреса или на шару раздает. Его задача отослать пакеты на MAC с заданным IP.

Полл> Предположу, что в задаче выше в реальности не свитч, а хаб. С ним такой прикол вполне возможен.
Не должен, т.к. запросы просто везде транслируются и все машинки получают ответы. Нормальный стек, как только получил сообщение, что у кого-то другого тот же IP, должен засандалить ICMP мессагу и выдать в логи/юзверю сообщение об ошибке (печально знаменитое сообщение от той же винды, что другое устройство в сети поимело тот же адрес).

Собственно, отравление кэша для переназначения DNS запросов и использует такой метод атаки в сегментированных (свитчевых сетях). Специально создали (Дуг С. — студент Беркли универа, когда был аспирантом — где-то у меня валялись его работы и код) для того, чтобы показать, что сегментированные сети защищены не лучше хабовых, хотя прослушки всего трафика нет.

Lamort> Коммутатору вообще до фонаря IP,
Если IP у него есть, то не до фонаря.

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

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

Lamort> Допустим, ближайший роутер обнаружил такую ситуацию, что, кстати, маловероятно, - это не его дело, что там происходит в чужом оборудовании, и что он должен сделать?

Это его дело. По архитектуре TCP/IP должен быть уникальный IP адрес (про приватные адреса не говорим — они локально уникальные, а наружу их не выпускают). Поэтому стек TCP/IP отслеживает. На уровне стека, если такая фигня случается, то идут ошибки. В зависимости от политики по обновлению ARP кэша, какое-то время может прожить с адресом, потом адрес уходит к другому устройству (с точки зрения ARP/RARP и свитчей). Вот так они и борются и какают друг другу. Неявно, побеждает более медленное устройство, т.к. на запросы ARP/RARP отвечает последним, перебивая кэши MAC адресов.

Lamort> Как я понял, он просто меняет соответствие в ARP по ходу поступления новых пакетов и всё. TCP при этом работает, а вот VoIP портится.

С точки зрения IP — VoIP не лучше и не хуже TCP, UDP, SCTP — это протоколы верхнего уровня. Ты можешь поменять маршрутизацию с учётом протокола верхнего уровня, QoS и прочего, но на нижнем уровне фигня одна.

Полл> Вот у нас пришел свитчу пакет для IP ххх.zzz.yyy.www - никто не будет утверждать, я надеюсь, что пакеты имеют в заголовке MAC-адрес получателя.

Только MAC — это чисто локальное. И от типа сети сильно зависит. Тот же померший токенринг MAC имел назначаемые администратором. Ну и размер был другой, нежели у эзера. Поэтому можно говорить, что может быть не в заголовке, а в хвосте, а в заголовке длина пэйлоада (видел такую архитектуру, да ). Но суть одна, эти адреса доступны.

Полл> Что далее делает свитч? Свитч лезет в свою таблицу соответствия своих портов IP-адресам и... Получает коллизию.
Нет там коллизии. Либо находит, либо нет. Находит — использует. Не находит — начинается сеанс запроса по ARP/RARP в том числе. Ну или пробегает чужой запрос, а свитч обновляет таблицу. Если это не свитч уровня 3 (а это маркетинговое обзначение раутеров фактически), то IP адрес вообще пофигу. Там только MAC

Полл> Поскольку свитч должен знать не только за каким портом у него не MAC-адреса, но и за каким портом у него IP-адреса, поскольку в заголовках IP-пакетов именно они.

Нет, свитчу (истинному свитчу) IP пофигу.

Полл> Мы еще не дошли до канального уровня, где используются MAC-адреса.
Здрасьте. Свитч — это устройство уровня 2.

Lamort> Свитч ничего не знает про пакеты, он обрабатывает фреймы Ethernet.

Фреймы тоже пакеты. Просто обычно противопоставляют пакеты и поток.

Lamort> Это называется таблица ARP, только она не в свиче, а в роутере, к которому подсоединена подсеть с данным IP. Если приходит пакет с другим маком, он просто меняет запись в таблице ARP.

Таблица в любом стеке. В той же винде можно набрать команду arp.

Lamort> Вы не ту штуковину называете "свитчом", только и всего. Свич или, по-русски говоря, коммутатор, это устройство канального уровня модели TCP/IP.

Скорее OSI. TCP/IP ложиться на неё с очень сильной доработкой напильником.

Lamort>> Коммутатору вообще до фонаря IP,
Mishka> Если IP у него есть, то не до фонаря.
Я имел в виду IP тех, кто ему что-то передаёт, тем более, что он может передавать и данные других протоколов верхнего уровня.

Lamort>> а для внешнего маршрутизатора порт один, - тот который является выходом коммутатора к которому подключены два одинаковых IP с разными MAC.
Mishka> И это уже нарушение протокола, если только не специальный случай балансировки нагрузки. Но в последнем случае принимают специальные меры (на уровне нижних протоколов), чтобы не драбаданить сеть. Поэтому для этого дела даже специальные карточки делают, а не просто пару вставляют.

Очень интересно, - у меня на этом объекте стоит DES-1008, в с которым соединены телефонный шлюз, однин "левый" компьютер и от точка доступа за которой несколько компьютеров.
Ещё в DES-1008 приходит линк от тамошнего провайдера с 29-й подсеткой.

Какой же это протокол таким образом нарушается?

Lamort>> Допустим, ближайший роутер обнаружил такую ситуацию, что, кстати, маловероятно, - это не его дело, что там происходит в чужом оборудовании, и что он должен сделать?
Mishka> Это его дело. По архитектуре TCP/IP должен быть уникальный IP адрес (про приватные адреса не говорим — они локально уникальные, а наружу их не выпускают). Поэтому стек TCP/IP отслеживает. На уровне стека, если такая фигня случается, то идут ошибки. В зависимости от политики по обновлению ARP кэша, какое-то время может прожить с адресом, потом адрес уходит к другому устройству (с точки зрения ARP/RARP и свитчей). Вот так они и борются и какают друг другу. Неявно, побеждает более медленное устройство, т.к. на запросы ARP/RARP отвечает последним, перебивая кэши MAC адресов.

В архитектуре TCP/IP может и должен быть уникальный IP, только с какой стати за этим фактом должен следить роутер провайдера? С его точки зрения ничего "криминального" вообще не происходит, - он периодически получает одинаковый IP с разными MAC, и, скажем так, "не его дело" почему так происходит.
Если бы обмен данными шел вообще только в одну сторону, - от данного IP к внешним адресам, то всё было бы совершенно нормально, фреймы принимались, менялась запись ARP и пакеты уходили бы себе в сеть.
Вот когда приходит ответ, то да, очередной пакет будет периодически улетать не тому адресату.

Lamort>> Как я понял, он просто меняет соответствие в ARP по ходу поступления новых пакетов и всё. TCP при этом работает, а вот VoIP портится.
Mishka> С точки зрения IP — VoIP не лучше и не хуже TCP, UDP, SCTP — это протоколы верхнего уровня. Ты можешь поменять маршрутизацию с учётом протокола верхнего уровня, QoS и прочего, но на нижнем уровне фигня одна.

В данном случае VoIP не будет работать потому, что передача голоса реализована с помощью UDP и не допускает потери большого количества пакетов.
При этом дозвон организован с помощью TCP и он работал.

Lamort>> Свитч ничего не знает про пакеты, он обрабатывает фреймы Ethernet.
Mishka> Фреймы тоже пакеты. Просто обычно противопоставляют пакеты и поток.

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

Lamort>> Это называется таблица ARP, только она не в свиче, а в роутере, к которому подсоединена подсеть с данным IP. Если приходит пакет с другим маком, он просто меняет запись в таблице ARP.
Mishka> Таблица в любом стеке. В той же винде можно набрать команду arp.

Естественно, и она наверняка покажет только MAC шлюза компьютера и его IP.
В коммутаторе нет ничего кроме таблицы маков за каким-то портом, а в роутере таблица соответствия IP подсетей за данным интерфейсом и маков.

В принципе роутер можно заставить следить за процессом смены MAC у IP, только зачем это делать в относительно простом роутере?

Lamort>> Вы не ту штуковину называете "свитчом", только и всего. Свич или, по-русски говоря, коммутатор, это устройство канального уровня модели TCP/IP.
Mishka> Скорее OSI. TCP/IP ложиться на неё с очень сильной доработкой напильником.
В TCP/IP "канальный уровень" это два нижних уровня OSI, - канальный и физический, по крайней мере я встречал такую классификацию.

Lamort> Я имел в виду IP тех, кто ему что-то передаёт, тем более, что он может передавать и данные других протоколов верхнего уровня.

Как они ему могут быть до фонаря, если он этими адресами заполняет заголовок IP пакета, а MAC ставит ближащей точки?

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

Ну, в твоём случае один. В общем случае нет. Раутер соединяет разные сети. В том числе разных топлогий и разных физических уровней. На уровне IP они работают примерно одинаково. Т.е. различие в уме есть, но базовые вещи одинаковые (MPLS пока не трогаем).


Lamort> Очень интересно, - у меня на этом объекте стоит DES-1008, в с которым соединены телефонный шлюз, однин "левый" компьютер и от точка доступа за которой несколько компьютеров.

Дык, они подсоединены по эзеру (локальная технология), а работают по IP.

Lamort> Ещё в DES-1008 приходит линк от тамошнего провайдера с 29-й подсеткой.
И к чему это? IP от подсетки не зависит.

Lamort> Какой же это протокол таким образом нарушается?

IP семейство и архитектура расчитаны на то, что IP уникальны. Именно поэтому пришлось городить огород с NATP и серыми адресами, когда стало IP не хватать. Private Addresses появились вовсе не сразу. Ну и критика есть этого дела. Я на Базе уже кидал ссылки на бывшего президента IETF. Вот IP архитектуру и нарушает. И детектирование ситуации, когда IP не уникален встроено в стек ещё в далёких 60-х годах. Вначале просто постулировали, а потом, когда в сети появилось более 100 (или 1000? точно уже не помню) компов, то вручную стало тяжко координировать. Встроили автоматизацию. История в общих чертах очень старндартная. Тот же Пастель был IANA-ой чуть ли не до конца 80-х, начала 90-х. Т.е., если надо было включить протокол, порт, сервис, etc в соответствующий список (зарезервировать имя и номер), писал письмо Джону с обоснованием и на сайте IETF появлялся новый файл с новыми номерами. Он добавлял.

Lamort> В архитектуре TCP/IP может и должен быть уникальный IP, только с какой стати за этим фактом должен следить роутер провайдера? С его точки зрения ничего "криминального" вообще не происходит, - он периодически получает одинаковый IP с разными MAC, и, скажем так, "не его дело" почему так происходит.

Может надо поучить матчасть? Там всё на этом основано.

Lamort> Если бы обмен данными шел вообще только в одну сторону, - от данного IP к внешним адресам, то всё было бы совершенно нормально, фреймы принимались, менялась запись ARP и пакеты уходили бы себе в сеть.

Ты забываешь, что данные идут по IP адресу не только от тебя.

Lamort> В данном случае VoIP не будет работать потому, что передача голоса реализована с помощью UDP и не допускает потери большого количества пакетов.

Блин, UDP с точки зрения IP ничем не отличается от TCP или SCTP. Демальплексация происходит на хосте. А TCP, как раз надёжный протокол, а UDP не надёжный. И UDP допускает полную потерю трафика, и приложениям приходится самим за этим следить. А вот за TCP следит стек (все эти знаеменитые хэндшейки, автомат состояний, окна подтверждения, алгоритмы увеличения сегментов и прочее), т.е. с точки зрения пользователя и приложения ОС отвечает за наддёжность.

Lamort> Я использую следующую терминологию, - данные транспортного уровня это "сегменты", данные сетевого уровня это "пакеты", данные канального уровня это "фреймы" или "кадры".

Сегменты зарезервировано для другого в сетевом мире. Фреймы будет лучше.

Lamort> Естественно, и она наверняка покажет только MAC шлюза компьютера и его IP.

Она покажет все MAC, с которыми комп общался. Скажем, все компы в подсети. Только он (кэш) живёт не очень долго. Вот выдай команду arp, а потом пропингуй комп со всех других и опять выдай команду. Потом подожди минут 5 и опять выдай. Увидишь разницу.

Lamort> В коммутаторе нет ничего кроме таблицы маков за каким-то портом, а в роутере таблица соответствия IP подсетей за данным интерфейсом и маков.

Если свитч управляемый, но не уровня 3, то есть. ARP — это необходимый атрибут IP стека. Без него не работает.

Lamort> В принципе роутер можно заставить следить за процессом смены MAC у IP, только зачем это делать в относительно простом роутере?

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

Lamort> В TCP/IP "канальный уровень" это два нижних уровня OSI, - канальный и физический, по крайней мере я встречал такую классификацию.

TCP/IP — 60-е. OSI — 80-е. И не ложился TCP/IP стек чётко на OSI модель. Всё-таки последняя чисто reference model. Кстати, в 90-е физический уровень разбили на два, а потом плюнули. Особенно, как IETF стала разрабатывать всякие дополнения к IP семейсвту: IP-over-IP, оптику через IP, PPP over IP и кучу другого. В общем, на данный момент IP ходит через всё, что хочешь, да и большинстов канальных вещей ходят через IP. Т.е. IP честно стал рекурсивным.

Lamort>> Я имел в виду IP тех, кто ему что-то передаёт, тем более, что он может передавать и данные других протоколов верхнего уровня.
Mishka> Как они ему могут быть до фонаря, если он этими адресами заполняет заголовок IP пакета, а MAC ставит ближащей точки?
Коммутатор как-то заполняет заголовок IP-пакета?
Какое именно устройство вы имеете в виду, как оно называется?

Lamort>> Ещё в DES-1008 приходит линк от тамошнего провайдера с 29-й подсеткой.
Mishka> И к чему это? IP от подсетки не зависит.
Как это "не зависит", - как пакет от источника попадёт в нужное место сети, если где-то не будет прописана эта подсеть?

Lamort>> Какой же это протокол таким образом нарушается?
Mishka> IP семейство и архитектура расчитаны на то, что IP уникальны. Именно поэтому пришлось городить огород с NATP и серыми адресами, когда стало IP не хватать. Private Addresses появились вовсе не сразу. Ну и критика есть этого дела. Я на Базе уже кидал ссылки на бывшего президента IETF. Вот IP архитектуру и нарушает. И детектирование ситуации, когда IP не уникален встроено в стек ещё в далёких 60-х годах. Вначале просто постулировали, а потом, когда в сети появилось более 100 (или 1000? точно уже не помню) компов, то вручную стало тяжко координировать. Встроили автоматизацию. История в общих чертах очень старндартная. Тот же Пастель был IANA-ой чуть ли не до конца 80-х, начала 90-х. Т.е., если надо было включить протокол, порт, сервис, etc в соответствующий список (зарезервировать имя и номер), писал письмо Джону с обоснованием и на сайте IETF появлялся новый файл с новыми номерами. Он добавлял.
Всё это очень здорово, но что именно контролирует тот факт, что два разных устройства имеют один и тот же IP и каким образом она должна это делать?

Я могу описать ситуацию, когда будут появляться пакеты с одинаковым IP и разными MAC при совершенно нормальной работе, а не при дублировании IP разными сетевыми источниками.
Допустим, между роутером и хостом стоит какая-то дублированная линия передачи, которая по каким-то причинам периодически переключается с одного канала на другой, - какие-нибудь два модема или что-то подобное.
Они передают дальше пакет каждый со своим MAC но с IP источника, таким образом до роутера доходит информация от одного источника с одним IP, но с двумя разными МАС.

Lamort>> В архитектуре TCP/IP может и должен быть уникальный IP, только с какой стати за этим фактом должен следить роутер провайдера? С его точки зрения ничего "криминального" вообще не происходит, - он периодически получает одинаковый IP с разными MAC, и, скажем так, "не его дело" почему так происходит.
Mishka> Может надо поучить матчасть? Там всё на этом основано.
Где это "там основано", я вам описываю совершенно реальную ситуацию, когда два устройства с одним и тем же IP работали в одном Ethernet-сегменте, при этом по работе локальной сети за точкой доступа вообще ничего не было заметно, все распрекрасно работали с Инетом и ничего не замечали.

Lamort>> Если бы обмен данными шел вообще только в одну сторону, - от данного IP к внешним адресам, то всё было бы совершенно нормально, фреймы принимались, менялась запись ARP и пакеты уходили бы себе в сеть.
Mishka> Ты забываешь, что данные идут по IP адресу не только от тебя.
Ну и что? Они идут каждый к своему адресату, так что проблемы начинаются только когда необходимо получить ответ.

Lamort>> В данном случае VoIP не будет работать потому, что передача голоса реализована с помощью UDP и не допускает потери большого количества пакетов.
Mishka> Блин, UDP с точки зрения IP ничем не отличается от TCP или SCTP. Демальплексация происходит на хосте. А TCP, как раз надёжный протокол, а UDP не надёжный. И UDP допускает полную потерю трафика, и приложениям приходится самим за этим следить. А вот за TCP следит стек (все эти знаеменитые хэндшейки, автомат состояний, окна подтверждения, алгоритмы увеличения сегментов и прочее), т.е. с точки зрения пользователя и приложения ОС отвечает за наддёжность.
А я что говорю? TCP благодаря повторной передаче устраняет потери когда пакеты улетают не тому адресату, а голос, который передаётся с помощью UDP не получается передать таким образом, - по этой причине шлюз дозванивался, но голос не передавался.
TCP это тот случай, когда верхний уровень компенсирует проблемы при работе нижних уровней.

Lamort>> Естественно, и она наверняка покажет только MAC шлюза компьютера и его IP.
Mishka> Она покажет все MAC, с которыми комп общался. Скажем, все компы в подсети. Только он (кэш) живёт не очень долго. Вот выдай команду arp, а потом пропингуй комп со всех других и опять выдай команду. Потом подожди минут 5 и опять выдай. Увидишь разницу.
Как правило у пользователя открыт только браузер, потому в ARP будет только шлюз, или вообще ничего не будет, если браузер не открыт.

Lamort>> В коммутаторе нет ничего кроме таблицы маков за каким-то портом, а в роутере таблица соответствия IP подсетей за данным интерфейсом и маков.
Mishka> Если свитч управляемый, но не уровня 3, то есть. ARP — это необходимый атрибут IP стека. Без него не работает.
В управляемом свитче, разумеется есть, но "управляющая часть свитча" это не "свитч собственно говоря", а некая надстройка.
Неуправляемый свитч может не иметь даже собственного MAC.

Lamort>> В принципе роутер можно заставить следить за процессом смены MAC у IP, только зачем это делать в относительно простом роутере?
Mishka> Потому, что стек без этого не работает. И раутером не надо быть. Как только стек появился, так появился кэш.
В данном случае интересна именно работа роутера, у которого стек оканчивается уровнем IP, всё остальное не его дело, кроме, разумеется, общения роутеров друг с другом.
Я вам более того скажу, роутеру, как правило, наплевать и на IP источника, - его интересует IP адресата, чтобы знать что делать с пакетом, а откуда он взялся такой, это не его дело.

Mishka> TCP/IP — 60-е. OSI — 80-е. И не ложился TCP/IP стек чётко на OSI модель. Всё-таки последняя чисто reference model. Кстати, в 90-е физический уровень разбили на два, а потом плюнули. Особенно, как IETF стала разрабатывать всякие дополнения к IP семейсвту: IP-over-IP, оптику через IP, PPP over IP и кучу другого. В общем, на данный момент IP ходит через всё, что хочешь, да и большинстов канальных вещей ходят через IP. Т.е. IP честно стал рекурсивным.
Да, совершенно верно, у меня есть линия Ethernet поверх IP, которая сделана для того, чтобы не разбираться с номерами виланов в сети оператора и нашей, а уже в ней наши пакеты с нашими IP.
Самое замечательное, что это сейчас делают две копеечные мыльницы, а за этот сервис с нас даже ничего не берут, - мы попросили выделенные номера виланов, так вместо этого сделали такое вот соединение.

Lamort> Коммутатор как-то заполняет заголовок IP-пакета?

Чистый уровня 2 нет. Твой DES-1008 — да. Он раутер.

Lamort> Как это "не зависит", - как пакет от источника попадёт в нужное место сети, если где-то не будет прописана эта подсеть?
Маршрутизация зависит от подсети. Но и там нет уже давно понятия подсети "в общем". Случилось это после того, как ввели аггрегацию подсетей для уменьшения таблиц маршрутизации на бэкбоне. А возможность появилась с введением CIDR.

Lamort> Всё это очень здорово, но что именно контролирует тот факт, что два разных устройства имеют один и тот же IP и каким образом она должна это делать?

На уровне локалки — ARP/RARP и частично DHCP (ранее BOOTP). Стеки отслеживают ситуацию. Чуть выше неявно идёт обмен через протоколы маршрутизации (это уже где маска подсети начинает играть роль существенную).

Lamort> Я могу описать ситуацию, когда будут появляться пакеты с одинаковым IP и разными MAC при совершенно нормальной работе, а не при дублировании IP разными сетевыми источниками.

Да запросто. Напимер, default gateway именно такой случай. Но это не означает, что они принадлежат одному IP в смыле ARP/RARP. А вот для адресации в локалке (бо раутинг здесь имеено на основе ARP/RARP, т.е. прямой доступ) — такого не бывает. И для раутера, когда он воткнут в другой шлюз своим WAN портом (это для домашних такая терминология) ситуация аналогична. На этом уровне это для него локалка.

Lamort> Допустим, между роутером и хостом стоит какая-то дублированная линия передачи, которая по каким-то причинам периодически переключается с одного канала на другой, - какие-нибудь два модема или что-то подобное.

Это проход через обычный раутер. И там будет несколько локалок. IP в этом случае в каждой локалке имеет свои кэши ARP и они живут ничего друг о друге не зная. Этот случай не подходит. Модемы можно с успехом заменить любой другой технологией соответстующего уровня. В этот момент, если технология "расширяет" текущую локальную сеть, то будут те же проблемы с единственностью IP в сети. По это причине провайдеры для модемных соединений и выдавали самии всегда IP — статический или динамический. Да собственно, текущие DSL, Cable и прочие домашние штучки примерно так же работают. Более того, если ты VPN прокинешь и соединишь не подсети, а узел, то проблемы те же.

Lamort> Они передают дальше пакет каждый со своим MAC но с IP источника, таким образом до роутера доходит информация от одного источника с одним IP, но с двумя разными МАС.
Эти каналы не работают одновременно. Только по очереди. Я тебе не даром предложил помониторить ARP кэш. Не живут там долго входы. Поэтому единственность вполне соблюдается.


Lamort> Где это "там основано", я вам описываю совершенно реальную ситуацию, когда два устройства с одним и тем же IP работали в одном Ethernet-сегменте, при этом по работе локальной сети за точкой доступа вообще ничего не было заметно, все распрекрасно работали с Инетом и ничего не замечали.

В архитектуре IP. А работало — ты отследил что и как по ARP/RARP сети ходило? Ты отследил обновление кэшей? Ты отследил сколько и куда пакетов уходило? Без этого бесмысленно говорить, что работало. У TCP есть перепосылка недошедшего пакета (точнее целого окна). Вот на это, небось и вылезало. И получалось, что "работало". А у UDP такой поддержки на уровне стека нет, поэтому что потерялось, то потерялось навсегда. Если хочется: поддерки, как у UDP; отказа от потока (доставка пакетом на уровне протокола 4), как у TCP; прибытие пакетов in order — пользуйся SCTP. Последний, кстати, позволяет открыть несколько подсессий в одной сессии и затребовать разные маршруты для подсессий.

Lamort> Ну и что? Они идут каждый к своему адресату, так что проблемы начинаются только когда необходимо получить ответ.

А то, что маршрутизация классическая работает по destination address. А в локалке только по соответсвтвию IP MAC-м. Если хочешь, то я могу подробно расписать процес, чтобы было понятно.

Lamort> А я что говорю? TCP благодаря повторной передаче устраняет потери когда пакеты улетают не тому адресату, а голос, который передаётся с помощью UDP не получается передать таким образом, - по этой причине шлюз дозванивался, но голос не передавался.

Это не означает, что всё работает. И стек должен было пожаловаться на то, что два девайса отвечают на ARP запрос одновременно.

Lamort> TCP это тот случай, когда верхний уровень компенсирует проблемы при работе нижних уровней.

Он пытается. Но не всегда работает. Я же говорю, что более медленное устройство побеждает. Что не означает, что всё работает.

Lamort> Как правило у пользователя открыт только браузер, потому в ARP будет только шлюз, или вообще ничего не будет, если браузер не открыт.

Не правильно. БО винда много чего по сети гонять может. Netstat тебе в помощь. Скажем, если у тебя служба computer browser поднята, то ты увидишь достаточно много. Если папки расшарены, то тоже много увидишь.

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

Lamort> В данном случае интересна именно работа роутера, у которого стек оканчивается уровнем IP, всё остальное не его дело, кроме, разумеется, общения роутеров друг с другом.

Так раутеры общаются друг с другом тоже по уровню 2 — без этого не бывает. Другое дело, что им приходиться фреймы переделывать, да иногда некоторые битики в заголовке менять. Ну ещё всякие PNAT адреса, а иногда и порты меняют.

Lamort> Я вам более того скажу, роутеру, как правило, наплевать и на IP источника, - его интересует IP адресата, чтобы знать что делать с пакетом, а откуда он взялся такой, это не его дело.

В классическом случае маршрутизации — да. В MPLS уже по другому. В случае раутинга multicasting-а — источник всегда важен. В случае, когда раутинг идёт с поддержкой QoS (DS или RSVP), то источник почти всегда важен кроме простого случая в DS, когда отображают в приоритеты только.

Lamort> Самое замечательное, что это сейчас делают две копеечные мыльницы, а за этот сервис с нас даже ничего не берут, - мы попросили выделенные номера виланов, так вместо этого сделали такое вот соединение.
А какая разница? Ну была бы поддержка ATM.

Lamort>> Коммутатор как-то заполняет заголовок IP-пакета?
Mishka> Чистый уровня 2 нет. Твой DES-1008 — да. Он раутер.

D-Link DES-1008D является неуправляемым коммутатором 10/100 Мбит/с предназначенным для повышения производительности работы малой группы пользователей, обеспечивая при этом высокий уровень гибкости. Мощный и одновременно с этим простой в использовании, DES-1008D позволяет пользователям без труда подключить к любому порту сетевое оборудование, работающее на скоростях 10 Мбит/с или 100 Мбит/с, понизить время отклика и удовлетворить потребности в большой пропускной способности сети.

 

Mishka> На уровне локалки — ARP/RARP и частично DHCP (ранее BOOTP). Стеки отслеживают ситуацию. Чуть выше неявно идёт обмен через протоколы маршрутизации (это уже где маска подсети начинает играть роль существенную).

ARP без дополнительных примочек это не контролирует никак.

Mishka> В архитектуре IP. А работало — ты отследил что и как по ARP/RARP сети ходило? Ты отследил обновление кэшей? Ты отследил сколько и куда пакетов уходило? Без этого бесмысленно говорить, что работало.

Вы всегда это делаете, когда настраиваете клиентскую сеть? А просто посмотреть пашет Инет или нет, этого недостаточно?
Типа "Инет пашет", но всё не работает.

Mishka> А какая разница? Ну была бы поддержка ATM.
Может в вашей дикой Америке где-то ещё и есть ATM, но в России его встретить практически невозможно.
Тем более, что у нас здесь можно купить гигабитный канал примерно за 5000 рублей в месяц. А может и за 3000, - точно не помню.

Lamort> D-Link DES-1008D
А, пардон, перепутал с более умным домашним. У которого можно прошивку менять.

Lamort> ARP без дополнительных примочек это не контролирует никак.

ARP контролирует сбросом кэша. По архитектуре IP уникален. Поэтому PNAT пришлось изобретать, чтобы разрешить выход в сеть с private address ranges.

Lamort> Вы всегда это делаете, когда настраиваете клиентскую сеть? А просто посмотреть пашет Инет или нет, этого недостаточно?
Ну, проверяю часто. Особенно, если есть траблы в сети.

Lamort> Типа "Инет пашет", но всё не работает.

Ну, если дома делаю, скажем, то проверяю всё, что было. А дома у меня много чего. Чисто девайсов на базе IP штук 40, 3 точки доступа для беспроводки (по одной на этаж — надо переходить на чего-нибудь энтрепрайзное, чтобы автоматом менять точку в зависимости от качества сигнала), пара нормальных раутеров хренова туча свитчей.

Lamort> Может в вашей дикой Америке где-то ещё и есть ATM, но в России его встретить практически невозможно.
Lamort> Тем более, что у нас здесь можно купить гигабитный канал примерно за 5000 рублей в месяц. А может и за 3000, - точно не помню.
Поддержка не означает наличие. Посмотри внутрь домашних раутеров — VCI всякие там от ATM.

Lamort>> ARP без дополнительных примочек это не контролирует никак.
Mishka> ARP контролирует сбросом кэша. По архитектуре IP уникален. Поэтому PNAT пришлось изобретать, чтобы разрешить выход в сеть с private address ranges.
Это по сути не контроль, вот Windows действительно осуществляет контроль следующим образом, - во время присвоения IP адреса, безразлично какого, посылается аж целых 3 раза ARP-запрос для поиска такого же IP.
Если никто не ответил, то IP присваивается, если нет, вылезает ошибка, причём и на другом компьютере тоже.

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

Lamort>> Вы всегда это делаете, когда настраиваете клиентскую сеть? А просто посмотреть пашет Инет или нет, этого недостаточно?
Mishka> Ну, проверяю часто. Особенно, если есть траблы в сети.

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

Lamort>> Типа "Инет пашет", но всё не работает.
Mishka> Ну, если дома делаю, скажем, то проверяю всё, что было. А дома у меня много чего. Чисто девайсов на базе IP штук 40, 3 точки доступа для беспроводки (по одной на этаж — надо переходить на чего-нибудь энтрепрайзное, чтобы автоматом менять точку в зависимости от качества сигнала), пара нормальных раутеров хренова туча свитчей.
Интересная задача, я недавно её решал в одной трёхэтажной небольшой гостинице и решили мы её крайне плохо.
Обнаружилась интересная вещь, - наличие повторителей сигнала ухудшает, а не улучшает работу, они вешают шлюзы.

Добиваться правильной со всех точек зрения работы сети хорошо, когда за эту отдельную работу платят и её оценивают, обычно оценка бинарная такая, - "Инет пашет/Инет не пашет".

Mishka> Поддержка не означает наличие. Посмотри внутрь домашних раутеров — VCI всякие там от ATM.
На практике мне ATM встретилась только при возне с DSL-ным коммутатором, там весьма навороченная внутренняя логическая структура, которая ещё и вся выведена на интерфейс управления, что крайне неудобно когда у тебя стоит простенькая задача.