акадо конфликт ip

23AG_Oves> Ну так запрос ARP рассылается хостом после получения ip от DHCP, т.е. всё равно для правильной работы он должен сделать запрос по всему ip сегменту, и модем должен этот запрос пропустить.

ARP запрос будет рассылаться и в том случае, если ты ручками поставишь IP адрес. ARP не работает дальше "локалки" (скажем, бриджованные локалки можно рассматривать как просто локалки). Если есть такой же адрес в другом сегменте (другой локалке), то никаких сообщений о конфликтах не будет. Всё будет определяться таблицами маршрутизации. Это одна из причин, по которой ты, выбрав IP адрес yandex.ru, не станешь этим самым yandex.ru.

ARP, на данный момент, единственный способ разрешить связку IP-MAC в локальной сети. И ARP запросос ты всегда найдёшь кучу (ввиду процесса состАривания кэша) в сети, где нет DHCP сервера вообще.

23AG_Oves> Выяснение связки идёт внутри одного сенмента, так что тут противоречий нет.

Тут не противоречие. Я просто говорю, что не надо ARP привязывать к DHCP. Разные они. И работают независимо.

23AG_Oves> Согласен. Причём эта работа согласованна, и нужна для того, чтобы адреса выдавались правильно

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


23AG_Oves> Адрес был из диапазона 10.х.х.х, правда 2 октет был отличный от адреса хоста. Маску не помню, то ли 11, то ли 12 бит, поэтому насчёт сегментов точно сказать нельзя. На тот момент такой задачи и не было.

Тут надо различать логические подсети (это IP с масками) и физические сегменты — это, собственно, локалка. Логические подсети могут существовать внутри одного физического сегмента. Т.е. на одной локалке ты можешь организовать кучу IP подсетей у себя дома. У меня существуют по крайней мере три таковых на моём гигабитном свитче дома.

Ну и тебе кое-что интересное с моей работы

Ethernet adapter Local Area Connection:

       Connection-specific DNS Suffix  . : ca.com
       Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection
       Physical Address. . . . . . . . . : 00-0D-56-EF-E2-1F
       Dhcp Enabled. . . . . . . . . . . : Yes
       Autoconfiguration Enabled . . . . : Yes
       IP Address. . . . . . . . . . . . : 138.42.153.105
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . :
       DHCP Server . . . . . . . . . . . : 141.202.205.131
       DNS Servers . . . . . . . . . . . : 141.202.1.108
                                           130.200.10.108
                                           141.202.27.108
       Primary WINS Server . . . . . . . : 141.202.109.5
       Secondary WINS Server . . . . . . : 141.202.109.24
                                           130.200.17.116
       Lease Obtained. . . . . . . . . . : Tuesday, March 11, 2008 7:55:18 AM
       Lease Expires . . . . . . . . . . : Wednesday, March 12, 2008 7:55:18 AM



E:\t\t01>tracert 141.202.205.131

Tracing route to usildh01.ca.com [141.202.205.131]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  rtp001270rts.ca.com [138.42.153.1]
  2    <1 ms    <1 ms    1 ms  rtp001417rts.ca.com [138.42.180.137]
  3    1 ms    2 ms    1 ms  138.42.200.49
  4    17 ms    17 ms    16 ms  usilgr48-pos-3-0-0-100.ca.com [130.200.200.194]
  5    17 ms    23 ms    16 ms  usilgr64-g1-5-rb01-l00.ca.com [141.202.254.217]
  6    17 ms    17 ms    17 ms  usilgr47-g6-10.ca.com [141.202.254.142]
  7    17 ms    16 ms    17 ms  usildh01.ca.com [141.202.205.131]

Trace complete.






И это при том, что между 3 и 4 шагами там MPLS облако. Т.е. мой DHCP сервер не только не локальный, а позади кучи раутеров. И мне до него физически около 500 км.

Mishka> Кстати, кто мне объяснит — при чём тут ARP?
В смысле, MAC-авторизация самого модема (который бридж) как происходит, если DHCP-запросы хост посылает? Не через ARP, разве?

Mishka> ARP запрос будет рассылаться и в том случае, если ты ручками поставишь IP адрес.
Не только. ARP используется при процедуре release/renew по истечении срока аренды. При первоначальном подключении - когда адрес 0.0.0.0 - он конечно не нужен.

Mishka>ARP не работает дальше "локалки" (скажем, бриджованные локалки можно рассматривать как просто Mishka>локалки). Если есть такой же адрес в другом сегменте (другой локалке), то никаких сообщений о Mishka>конфликтах не будет. Всё будет определяться таблицами маршрутизации. Это одна из причин, по которой Mishka>ты, выбрав IP адрес yandex.ru, не станешь этим самым yandex.ru.

Так я вроде тоже самое писал.

Mishka> ARP, на данный момент, единственный способ разрешить связку IP-MAC в локальной сети. И ARP запросос ты всегда найдёшь кучу (ввиду процесса состАривания кэша) в сети, где нет DHCP сервера вообще.

Это тоже понятно, я и не говорил что ARP зависит от DHCP. Протокол сетевого уровня не может зависеть от прикладного, только наоборот.

23AG_Oves>> Выяснение связки идёт внутри одного сенмента, так что тут противоречий нет.
Mishka> Тут не противоречие. Я просто говорю, что не надо ARP привязывать к DHCP. Разные они. И работают независимо.

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

23AG_Oves>> Согласен. Причём эта работа согласованна, и нужна для того, чтобы адреса выдавались правильно
Mishka> Не совсем. Ну сделай дома сетку со статическими адресами и назначь одному хосту адрес как у другого. И ты получишь ровно те же сообщения, только без отказа от адреса. Т.е. хост хочет проверить — а не занят ли адрес. Но хост делает это всегда, даже для статического адреса. И, если адрес занят, то в статическом случае ты получешь сообщение об конфликте, а в динамическом, кроме сообщение, хост выдаст еще и release на адрес. Но это потому, что DHCP говорит, что, если адрес не нужен, то он должен быть "вёрнут взад". Как хост узнаёт, что адрес не нужен — его дело. Иногда, когда доступно несколько DHCP
Mishka> серверов, происходит такая штука — оба сервера дают адреса (разные), хост берёт один, а на второй не отвечает. В этом случае там есть специальный таймаут, по истечении которого, сервер, не получив подтверждение на своё предложение, считает предложение не принятым и возвращает предложенный адрес в пул свободных адресов.
Ну в принципе согласен. Причём как правило берёт из того пула, из которого не нужно.
23AG_Oves>> Адрес был из диапазона 10.х.х.х, правда 2 октет был отличный от адреса хоста. Маску не помню, то ли 11, то ли 12 бит, поэтому насчёт сегментов точно сказать нельзя. На тот момент такой задачи и не было.
Mishka> Тут надо различать логические подсети (это IP с масками) и физические сегменты — это, собственно, локалка. Логические подсети могут существовать внутри одного физического сегмента. Т.е. на одной локалке ты можешь организовать кучу IP подсетей у себя дома. У меня существуют по крайней мере три таковых на моём гигабитном свитче дома.

Я имел ввиду ip-сегменты. Т.е. не помню - в каком ip-сегменте DHCP сервер. А насчёт локалки - это понятие размытое. В районных сетях под локалкой понимают большую сеть даже из нескольких ip-сегментов.

Mishka> Ну и тебе кое-что интересное с моей работы
Mishka>
Mishka> Ethernet adapter Local Area Connection:
Mishka>        Connection-specific DNS Suffix  . : ca.com
Mishka>        Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection
Mishka>        Physical Address. . . . . . . . . : 00-0D-56-EF-E2-1F
Mishka>        Dhcp Enabled. . . . . . . . . . . : Yes
Mishka>        Autoconfiguration Enabled . . . . : Yes
Mishka>        IP Address. . . . . . . . . . . . : 138.42.153.105
Mishka>        Subnet Mask . . . . . . . . . . . : 255.255.255.0
Mishka>        Default Gateway . . . . . . . . . :
Mishka>        DHCP Server . . . . . . . . . . . : 141.202.205.131
Mishka>        DNS Servers . . . . . . . . . . . : 141.202.1.108
Mishka>                                            130.200.10.108
Mishka>                                            141.202.27.108
Mishka>        Primary WINS Server . . . . . . . : 141.202.109.5
Mishka>        Secondary WINS Server . . . . . . : 141.202.109.24
Mishka>                                            130.200.17.116
Mishka>        Lease Obtained. . . . . . . . . . : Tuesday, March 11, 2008 7:55:18 AM
Mishka>        Lease Expires . . . . . . . . . . : Wednesday, March 12, 2008 7:55:18 AM
 E:\t\t01>>tracert 141.202.205.131
Mishka> Tracing route to usildh01.ca.com [141.202.205.131]
Mishka> over a maximum of 30 hops:
Mishka>  1    <1 ms    <1 ms    <1 ms  rtp001270rts.ca.com [138.42.153.1]
Mishka>  2    <1 ms    <1 ms    1 ms  rtp001417rts.ca.com [138.42.180.137]
Mishka>  3    1 ms    2 ms    1 ms  138.42.200.49
Mishka>  4    17 ms    17 ms    16 ms  usilgr48-pos-3-0-0-100.ca.com [130.200.200.194]
Mishka>  5    17 ms    23 ms    16 ms  usilgr64-g1-5-rb01-l00.ca.com [141.202.254.217]
Mishka>  6    17 ms    17 ms    17 ms  usilgr47-g6-10.ca.com [141.202.254.142]
Mishka>  7    17 ms    16 ms    17 ms  usildh01.ca.com [141.202.205.131]
Mishka> Trace complete.
Mishka>

Mishka> И это при том, что между 3 и 4 шагами там MPLS облако. Т.е. мой DHCP сервер не только не локальный, а позади кучи раутеров. И мне до него физически около 500 км.

ну эт нормально (с)

Mishka>> Кстати, кто мне объяснит — при чём тут ARP?
Kernel3> В смысле, MAC-авторизация самого модема (который бридж) как происходит, если DHCP-запросы хост посылает? Не через ARP, разве?

Нет, MAC содержится в DHCP запросе в поле chaddr. Только модем, если он бридж - пропускает через себя DHCP запрос прозрачно.

23AG_Oves> Нет, MAC содержится в DHCP запросе в поле chaddr. Только модем, если он бридж - пропускает через себя DHCP запрос прозрачно.
Я в курсе. Именно поэтому я вопрос так и сформулировал

Kernel3> В смысле, MAC-авторизация самого модема (который бридж) как происходит, если DHCP-запросы хост посылает? Не через ARP, разве?

Там их две — поначалу, когда модем подключается, то он начинает получать соединение с оборудованием кабельного оператора. Сама сетка очень похожа на Token Ring. Там никаких коллизий. У сервера есть специальный маркер, который он передаёт кабельному модему. когда маркер получен — модем начинает вещать. Модем ждёт этого маркера определённое время — так называемый таймер T3. Если время кончилось, то модем начинает операцию по перезагрузки и инициации соединения. Маркер может просто потеряться, если сигнал слабый, а может быть сервер очень перегружен и он не успеет послать маркер. Это справедливо для 1.0 и 1.1 — в 2.0 и в 3.0 я уже со стандартами не разбирался. Это не обязательно ARP протокол — там своего много наворочено и это до выхода на IP уровень. Когда модем получит соединение и авторищзуется, тогда он начинает просить адрес из 10.0.0.0/8, получает его и далее происходит загрузка образа по SNMP протоколу — у них есть специальная поддержка SET операции на определённом ASN.1 OID-е. В частности, в этом образе есть некоторые данные по настройке модема, QoS и т.д.

После этого можно включать машину и она начнёт просить IP адрес (если сконфигурена получать динамический адрес). DHCP запрос уходит в сеть, модем его подхватывает и передает широковещательным образом дальше. И так, пока на дойдёт до DHCP сервера. В запросе DHCP серверу есть МАС адрес просителя. Попробуй поснифай сетку и выдели DHCP протокол — там многое понятным станет.

ARP ничего не авторизует — его задача узнать соответствие IP MAC адресу. Всё, вроде.

23AG_Oves> Не только. ARP используется при процедуре release/renew по истечении срока аренды. При первоначальном подключении - когда адрес 0.0.0.0 - он конечно не нужен.

Где? http://www.ietf.org/rfc/rfc2131.txt?number=2131 — описание протокола. Там есть требования к проверке переиспользованных адресов:

In some environments it will be necessary to reassign network
addresses due to exhaustion of available addresses. In such
environments, the allocation mechanism will reuse addresses whose
lease has expired. The server should use whatever information is
available in the configuration information repository to choose an
address to reuse. For example, the server may choose the least
recently assigned address. As a consistency check, the allocating
server SHOULD probe the reused address before allocating the address,
e.g., with an ICMP echo request, and the client SHOULD probe the
newly received address, e.g., with ARP.
...

5. The client receives the DHCPACK message with configuration
parameters. The client SHOULD perform a final check on the
parameters (e.g., ARP for allocated network address), and notes the
duration of the lease specified in the DHCPACK message. At this
point, the client is configured.

 

Но тут он идёт как пример.

The client SHOULD perform a
check on the suggested address to ensure that the address is not
already in use. For example, if the client is on a network that
supports ARP, the client may issue an ARP request for the suggested
request.

 

А тут прямо говорится, что, если клиент находится в сети, которая поддерживает ARP. Т.е. DHCP должен работать в сети, которая не поддерживает ARP. Но это понятно и так.

23AG_Oves> Это тоже понятно, я и не говорил что ARP зависит от DHCP. Протокол сетевого уровня не может зависеть от прикладного, только наоборот.

Дык и DHCP не зависит от ARP — он говорит, что должен сделать клиент или сервер. А уж ARP это или что-то другое — это как получится.

23AG_Oves> Да понятно что независимо, но правильная выдача адресов невозможна без ARP. Если бы бриджи-модемы не пропускали бы ARP - была бы куча конфликтов при смене адреса. Я, наверное, изначально непонятно писал - но да, ты прав, что для начальной инициализации процесса получения адреса ARP не нужен.

Да, конечно, возможна. Вот, начальная идея IP over ATM работала — там был специальный сервер по разрешению IP и ATM VPI/VCI.

А для DOCSIS-а — http://www.ietf.org/rfc/rfc3256.txt?number=3256 — описывает, как всё релеется.

23AG_Oves> Ну в принципе согласен. Причём как правило берёт из того пула, из которого не нужно.

Настраивай таймауты у сервера корректно, и будет тебе счастье.

Mishka> Попробуй поснифай сетку и выдели DHCP протокол — там многое понятным станет.
Меня именно интерфейс, доступный только со стороны провайдера, интересовал, спасибо за разъяснения
Mishka> ARP ничего не авторизует — его задача узнать соответствие IP MAC адресу.
А с этим я и не спорю