Как стать автором
Обновить

Комментарии 209

Очень интересно, ждем ответы на вышеуказанные вопросы
В тексте статьи уже присутствует ссылка на ответы.
Хотелось бы на самом хабрахабре в виде статьи :)
Вот тоже согласен, ищешь ответы, а тут одни вопросы.
На вопрос, похожий на B10 (Может ли адрес 10.0.1.0 быть использован для адреса хоста?) мне на собеседованиях не ответил никто.

А вот всю жизнь мечтал узнать: сколько вольт в витой паре Ethernet? Я подозреваю, что 1-2.
А я думаю, что 5 :)
Идём в гугл?
Думаете 5 потому что TTL?

А ничего, что там разностный сигнал используется, а 5В через сто метров может стать чем угодно, учитывая частоту модуляции? А, кстати, на расстоянии 100 м — 5 в относительно чего мерить будем? Земля у каждого может быть своя.

В общем, трансиверы в карточках не просто так стоят, и на проводах там не TTL-напряжения.
Какая земля? В стандарте нет земли и в этом его прелесть. А напряжение мерится относительно провода в оболочке такого же цвета.
Строго говоря, напряжение в самом «проводе» не измеряется. С обоих сторон кабеля — трансформаторы.
Глянул осциллографом, на двух верхних картинках 200 мВ на клетку, на последней 1 В на клетку, Ethernet PHY Micrel KSZ8001LI:

До трансформатора (идет обмен):
image

После трансформатора (идет обмен):
image

Линковые импульсы до трансформатора (линк не поднят, нет обмена):
image
дифференциальным щупом смотрели?
У моего осцилла нет диф. входа. и соответствующего щупа. Просто землю щупа подключил к -TX, а сам щуп к +TX. До, и после трансформатора. Длина тут маленькая, так, что даже не на диф. щуп ни каких особых помех ловиться не должно. Осцилл работал от батареек, это для некоторых измерений тоже важно, особенно на дешевых осциллографах с дурацким блоком питания :-)
оффтоп конечно, но дело тут больше не во внешних помехах, а в индуктивности земляного провода осциллографа. Вообще совет — если ВЧ какие то сигналы мерите — снимайте этот провод и подцепляйте землю прямо к контактной площадке на самом щупе — это позволяет увеличить макс измеряемую частоту в 2-4 раза
На вопрос, похожий на B10 (Может ли адрес 10.0.1.0 быть использован для адреса хоста?) мне на собеседованиях не ответил никто.

Может. Банальный пример сеть 10.0.0.0/23
Круть.
Напомнило историю, которую мне знакомый рассказал.
Его друг звонит провайдеру.
— Девушка, у меня ADSL модем не работает — не выдает сигнал.
— Ой а вы его в розетку включили? А прокси у вас не настроен? А пинг можете сделать? А антивирус недавно не ставили? и т.д.
— ДА Я ГОВОРЮ: МОДЕМ НЕ РАБОТАЕТ — Я К НЕМУ ОСЦИЛЛОГРАФ ПОДКЛЮЧИЛ
В8. Смогут ли пинговать друг друга два компьютера в таких условиях

Я не согласен с вашим ответом. Как вы вообще собираетесь назначить компьютеру шлюз 192.168.0.1, если у компьютера адрес в сети 192.168.1.0/24?
НЛО прилетело и опубликовало эту надпись здесь
Стандарты этого не запрещают, вернее, не требуют, чтобы шлюз был в той же сети.

Основное требование, чтобы он был _доступен_.

И я видел такие сети. Работает.

И попробуйте — и Windows, и Linux дают назначить такие шлюзы. Windows, правда, ругнётся.
Линукс не даст. Например, ip route add a via b не добавит маршрут, если b не доступен непосредственно (т.е. не находится в любой из сетей, в которых находится локальная станция). Что логично.

Если на то пошло, то можно сделать подобное, сделав ip route add 192.168.0.1/32 dev eth0 и потом уже ip route add default via 192.168.0.1 — но это будет работать именно потому, что мы сначала добавили первый из этих маршрутов. Я не удивлюсь, если винда именно так и делает «под капотом». Проверьте таблицу маршрутизации.

Если будете спорить, сначала ответьте на вопрос: зачем нужно задавать маску подсети, и на что вообще она влияет?
Маршрут добавить не даст, а дефолтным шлюзом поставить даст. Попробуйте же.
> Если будете спорить, сначала ответьте на вопрос: зачем нужно задавать маску подсети, и на что вообще она влияет?
Ответ: чтобы понять, какие пакеты напрямую отправлять, а какие через шлюз )

Но опять же нет требования, чтобы шлюз был в той же сети )
Так а на что влияет-то маска? Где можно её потом увидеть?

Спрошу по-другому: как компьютер с помощью маски определяет, какие отправлять локально, а какие через шлюз?

А требование вообще-то есть. Требование звучит «шлюз должен быть доступен непосредственно в локальной сети (link-local)». Кстати, это же правило допускает использование при маршрутизации указание link-local адреса шлюза в качестве умолчания. Т.е. на локальном интерфейсе его вообще не обязательно иметь «белый».
Да, но нет требования, чтобы он был в той же сети логически.

Если у вас в ОДИН свич воткнут ваш хост и шлюз, но хост 192.168.1.1/24, а у шлюза адрес 192.168.2.1 (с любой маской), то они «видят» друг друга непосредственно. Попробуйте )

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

Т.е. может быть так, что 192.168.1.1/24 — ваш хост, а 192.168.2.1/16 — шлюз. И тогда будут ходить пинги туда-обратно.

Я серьёзно говорю, попробуйте на виртуалках.

В своё время я тоже удивился такой схеме, но она реально работает.
Я собственно попробовал, ниже посмотрите внимательно. Система не даёт добавить такой маршрут по умолчанию (=указать шлюз).

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

То есть, перед тем, как указывать шлюз, мы должны непременно иметь маршрут до шлюза.

Винда действительно втихую добавляет сначала маршрут до шлюза, а уже потом маршрут по умолчанию через шлюз, поэтому в ней работает. Линукс ничего втихую не делает, но если в нём вручную сделать так же, тоже будет работать.
Попробуйте на виртуалках, посмотрите на таблицы маршрутизации, убедитесь ;) Только смотреть на все — в линуксе их как минимум три (не забудьте ip route show table local)
НЛО прилетело и опубликовало эту надпись здесь
Про p2p вы совершенно правы. Но у нас сеть /24, как бы, это не похоже на p2p.

Чтоб адреса не терять, можно использовать маски /32. Собственно, /32 адрес можно назначить нескольким интерфейсам сразу, потому, что он не тянет за собой никаких автоматических маршрутов. Так в линуксе и делается «ip unnumbered».

Так что можно не терять, да: ставим 192.0.2.0/32 на первом, 192.0.2.1/32 на втором, маршруты друг на друга через интерфейс (любго типа, можно и eth) — и вуаля, связь есть. Затратили ровно два адреса.

Вот ещё пример: habrahabr.ru/post/189268/#comment_6572820
НЛО прилетело и опубликовало эту надпись здесь
А кто вам запрещает ethernet использовать для двух хостов?

Пример: два компа соединили шнурком.
НЛО прилетело и опубликовало эту надпись здесь
только не «link-local», а «connected» по-моему
Это вот терминология различается в разных системах. В циске «connected», да. Возможно я не на месте сказал, уже не помню, почему именно такой термин применил.
НЛО прилетело и опубликовало эту надпись здесь
Да я знаю, вероятно, я как-то по-другому формулировал мысль, а это осталось оттуда.
stalker merlin # ip route
127.0.0.0/8 via 127.0.0.1 dev lo
192.168.100.0/24 dev virbr0 proto kernel scope link src 192.168.100.1
192.168.168.0/24 dev br0 proto kernel scope link src 192.168.168.4
stalker merlin # ip route add default via 192.168.55.22
RTNETLINK answers: Network is unreachable

Нельзя, как видим.
А если у меня 10 сетевых карт? Он из каждой ARP-запрос в поисках шлюза сделает?
Согласен, по идее хост обнаружив что адрес находится в другой сети, должен переслать пакет шлюзу, и ARP запрос делается к шлюзу, а не к адресу из другой сети
Приглядитесь к адресации на схеме. Они друг у друга шлюзами назначены.
был невнимателен. тогда, действительно могут пинговаться, хотя забавно получается.
Как компьютер ПК1 должен добираться до 192.168.0.1?

1. Смотрим, не локальный ли адрес это. Нет, не локальный.
2. Смотрим, нет находится ли он в любой из локальных сетей (здесь 192.168.1.0/24). Нет, не находится.
3. Ищем шлюз и делаем ARP-запрос к нему. А через какой интерфейс? Оп-па. Где искать 192.168.0.1? Мы не знаем.

Скажете, что «раз указали в настройках сетевухи 1, значит через неё и искать». Хорошо. Это эквивалентно маршруту «192.168.0.1/32 via сетевуха1», что, собственно, и сделает винда.

Т.е. приведённая в примере конфиуграция, на самом деле, устроена так:
ПК1: 192.168.1.1/32, 192.168.0.1/32 via e0,
ПК2: 192.168.0.1/32, 192.168.1.1/32 via e0.

Т.е. у нас есть два компа и локальные маршруты «непосредственно» друг до друга, хоть оно и в разных подсетях. Конечно, будет пинговаться.
Взял я два ноутбука с дефолтной w7, настроил адреса-шлюзы как сказано (к слову, шлюзы дает настроить, просто спрашивает — вы уверены?), отключил Windows Firewall. Компы сами себя пингают, друг друга — нет. На всякий случай включил через свитч, взял третий ноут и стал давать ему адрес сначала 192.168.1.2, потом 192.168.0.2. В своей подсети все друг друга пингают, через границу подсети — нет. Дорогие ученые, что я делаю не так? (к слову, изначально считал что пингать не будут).
Таблицы маршрутизации покажите
рраз:

C:\Users\IPA_user>route print
===========================================================================
Interface List
 14...00 21 86 c9 8a 68 ......Bluetooth Device (Personal Area Network)
 11...00 23 7d 97 37 a1 ......Intel(R) 82567LM Gigabit Network Connection
  1...........................Software Loopback Interface 1
 18...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
 15...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
 17...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.0.1      192.168.1.1    266
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.1.0    255.255.255.0         On-link       192.168.1.1    266
      192.168.1.1  255.255.255.255         On-link       192.168.1.1    266
    192.168.1.255  255.255.255.255         On-link       192.168.1.1    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link       192.168.1.1    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link       192.168.1.1    266
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
          0.0.0.0          0.0.0.0      192.168.0.1  Default
===========================================================================

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
  1    306 ::1/128                  On-link
  1    306 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

C:\Users\IPA_user>ipconfig

Windows IP Configuration


Ethernet adapter Bluetooth Network Connection:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   IPv4 Address. . . . . . . . . . . : 192.168.1.1
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.0.1

Tunnel adapter isatap.{78B030C5-2A81-468F-AD8B-9EB09BD2B7BF}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Tunnel adapter Teredo Tunneling Pseudo-Interface:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Tunnel adapter isatap.{B97B1C3A-CBDC-446C-8BF5-C37A12FC954C}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
два:
C:\Users\nkuznetsov>route print
===========================================================================
Список интерфейсов
 14...08 3e 8e 98 b2 d2 ......Bluetooth Personal Area Network
 11...10 60 4b 4a fa 7c ......Intel(R) 82579V Gigabit Network Connection
  1...........................Software Loopback Interface 1
 18...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
 20...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP #2
===========================================================================

IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0      192.168.1.1      192.168.0.1    266
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.0.0    255.255.255.0         On-link       192.168.0.1    266
      192.168.0.1  255.255.255.255         On-link       192.168.0.1    266
    192.168.0.255  255.255.255.255         On-link       192.168.0.1    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link       192.168.0.1    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link       192.168.0.1    266
===========================================================================
Постоянные маршруты:
  Сетевой адрес            Маска    Адрес шлюза      Метрика
          0.0.0.0          0.0.0.0      192.168.1.1  По умолчанию
===========================================================================

IPv6 таблица маршрута
===========================================================================
Активные маршруты:
 Метрика   Сетевой адрес            Шлюз
  1    306 ::1/128                  On-link
  1    306 ff00::/8                 On-link
===========================================================================
Постоянные маршруты:
  Отсутствует

C:\Users\nkuznetsov>ipconfig

Настройка протокола IP для Windows


Ethernet adapter Подключение по локальной сети 2:

   Состояние среды. . . . . . . . : Среда передачи недоступна.
   DNS-суффикс подключения . . . . . :

Ethernet adapter Подключение по локальной сети:

   DNS-суффикс подключения . . . . . :
   IPv4-адрес. . . . . . . . . . . . : 192.168.0.1
   Маска подсети . . . . . . . . . . : 255.255.255.0
   Основной шлюз. . . . . . . . . : 192.168.1.1

Туннельный адаптер Teredo Tunneling Pseudo-Interface:

   Состояние среды. . . . . . . . : Среда передачи недоступна.
   DNS-суффикс подключения . . . . . :

Туннельный адаптер isatap.{DB3EB7F0-3F16-4AF2-B4CD-DB4E75948DAF}:

   Состояние среды. . . . . . . . : Среда передачи недоступна.
   DNS-суффикс подключения . . . . . :

ну что тут сказать. /32 маршруты не образовались. Видимо, винда поумнела и перестала втихую делать всякую хрень :)

Попробуйте их сделать сами: на первом добавить
route add 192.168.0.1 mask 255.255.255.255 192.168.1.1

а на втором
route add 192.168.1.1 mask 255.255.255.255 192.168.0.1
это уже расширяет scope изначального вопроса ;)
arp -a еще до кучи
в arp-е mac-адреса друг-друга видно.
пришлось превозмочь лень и сделать две виртуалки на win7, тема работает
а у меня — нет. где правда?
а маршруты-то у вас есть? Мне теперь тоже интересно, не делать же виртуалки, а то вдруг не заработает
маршрутов нет, да они и не нужны, логика следующая: система(192,168,1,1) видит, что нужно пингануть удаленный адрес (192,168,0,1), ищет шлюз с помощью arp запроса, находит, и посылает пакет в шлюз (192,168,0,1), шлюз(192,168,0,1) и по своместительству адресат, видит пакет и понимает что пакет адресован именно ему, собирается ответить, но так как ответ нужно отправить удаленному адресу (192,168,1,1), отсылает пакет шлюзу(192,168,1,1), который по совместительству является получателем пакета…
вы всё-таки покажите таблицы маршрутизации-то
Список интерфейсов
 15...00 15 5d a7 ea 35 ......Адаптер магистральной сети виртуальной машины (Май
крософт) #3
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP
 14...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================

IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0      192.168.0.1      192.168.1.1    261
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.1.0    255.255.255.0         On-link       192.168.1.1    261
      192.168.1.1  255.255.255.255         On-link       192.168.1.1    261
    192.168.1.255  255.255.255.255         On-link       192.168.1.1    261
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link       192.168.1.1    261
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link       192.168.1.1    261
===========================================================================
Постоянные маршруты:
  Сетевой адрес            Маска    Адрес шлюза      Метрика
          0.0.0.0          0.0.0.0      192.168.0.1  По умолчанию
===========================================================================

IPv6 таблица маршрута
===========================================================================
Активные маршруты:
 Метрика   Сетевой адрес            Шлюз
  1    306 ::1/128                  On-link
 15    261 fe80::/64                On-link
 15    261 fe80::1986:d248:1d9a:a469/128
                                    On-link
  1    306 ff00::/8                 On-link
 15    261 ff00::/8                 On-link
===========================================================================
Постоянные маршруты:
  Отсутствует

и

Список интерфейсов
 11...00 15 5d a7 ea 39 ......Адаптер магистральной сети виртуальной машины (Май
крософт)
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP
 13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================

IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0      192.168.1.1      192.168.0.1    261
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.0.0    255.255.255.0         On-link       192.168.0.1    261
      192.168.0.1  255.255.255.255         On-link       192.168.0.1    261
    192.168.0.255  255.255.255.255         On-link       192.168.0.1    261
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link       192.168.0.1    261
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link       192.168.0.1    261
===========================================================================
Постоянные маршруты:
  Сетевой адрес            Маска    Адрес шлюза      Метрика
          0.0.0.0          0.0.0.0      192.168.1.1  По умолчанию
===========================================================================

IPv6 таблица маршрута
===========================================================================
Активные маршруты:
 Метрика   Сетевой адрес            Шлюз
  1    306 ::1/128                  On-link
  1    306 ff00::/8                 On-link
===========================================================================
Постоянные маршруты:
  Отсутствует

Логика не такая. Если видно, что шлюз не в одной подсети с интерфейсом (не в connected-сети, в терминологии cisco) то будет выполнен recursive route lookup — то есть будут искать в таблице маршрутизации маршрут для достижения шлюза. и только на том шаге где будет найен next hop (именно ip-next-hop) в пределах одной подсети с интерфейсом — только тогда будет отправлен arp на разрешение адреса именно next-hop, а не шлюза. у меня изначально была претензия к вашей и автора логике.
а если такого ip-next-hop в таблице нет, как в приведенном примере? а есть только шлюз?
ну вот в реальности данной мне в ощущениях в виде двух ноутов у меня на столе оно и не пингует.
однако маки зарезолвило, может с фаиром что то нето? я фаир не выключал, у меня ICMP разрешен
когда маршруты /32 добавляю руками — работает.
ч т. д.
Да легко, гуглите по слову unnumbered. Шлюз не обязан быть в той же подсети что и адрес, есть исключения.
Шлюз не должен быть в той же подсети. Там вообще может не быть подсети. Но вот маршрут до шлюза должен быть до того, как мы назначим шлюз.
Маршрут само собой, но вопрос стоит смогут ли — да смогут.
IP адрес шлюза нужен ровно по одной причине: чтобы знать, куда слать arp запрос в поисках нужного мака. Технически, адрес шлюза может быть совершенно произвольным.
Ага. Но в терминах настройки протокола IP — третьего уровня — негде указывать MACи. Их вообще может не быть, мало ли, какой там канальный уровень. Может mGRE, тогда L2-адресами для этого интерфейса тоже будут IP-адреса :)

Поэтому нужен именно адрес шлюза третьего уровня, ip.
Ну в случае mGRE, положим, про винду вообще забываем :)

В случае ethernet можно было бы и мак указывать вместо IP адреса. И оно бы работало. Но с кучей недостатков от «сложнее запомнить, легче ошибиться» до «смена железки, играющей роль шлюза, превращается в адскую работу по перенастройке всего и вся».
Не, не соглашусь

То, что для маршрутизации достаточно l2-адреса шлюза, согласен. А вот что его можно было бы указывать — нет. Мы же ip настраиваем, должны оставаться в терминах l3.
В рамках имеющегося диалогового окна «свойства IPv4» — само собой так делать нельзя. Да и в статических маршрутах — тоже было бы неправильно. Но условно: в свойствах IPv4 галка «использовать как основной шлюз» (по аналогии с p2p интерфейсами), а где-то отдельно в настройках интерфейса мак соседа, через которого идти. Но да, это был бы ужас.
Шлюз в принципе может находится и в другой подсети, inarp запрос в таком случае ничего не отрезолвит. Продолжая Вашу аналогию — зачем указывать и мак адрес узла приема? Можно просто ссыпать пакеты в point-to-point интерфейс, сосед сам разберется куда пакет отправлять дальше.
$ ip route

default dev ppp1 scope link metric 2000


Собственно, так и есть, указан интерфейс, а сосед сам разберётся ;)
Можно просто ссыпать пакеты в point-to-point интерфейс

Для point-to-point интерфейсов так и происходит.
Но ethernet категорически не является point-to-point интерфейсом. Даже если он соединяет два хоста.

Но технически можно слать пакеты на FF:FF:FF:FF:FF:FF. Суть не изменится, обработка произойдет. В случае ровно двух хостов на сегмент особой разницы не будет. Просто есть некоторые стандарты, которые лучше соблюдать.
прикольная идея, что-то я как-то не задумывался об испоьзовании ethernet broadcast в такой ситуации
point-to-point — имеется в виду «Ethernet соединение между хостами работающие в полнодуплексном режиме.»

IP адрес шлюза нужен ровно по одной причине: чтобы знать, куда слать arp запрос в поисках нужного мака.

В случае двух хостов можно и не указывать dg. Но звучит эта фраза не про сегмент из двух компов.
Хабов не существует, это — миф, и полудуплекса тоже нет :)
Но на топологии шины он по-прежнему умеет работать.
C:\>ipconfig

Настройка протокола IP для Windows

Подключение по локальной сети — Ethernet адаптер:

DNS-суффикс этого подключения..:…
IP-адрес............: 10.16.1.217
Маска подсети..........: 255.255.255.224
Основной шлюз..........: 10.16.1.193

10:40:05.344028 arp who-has 10.16.1.217 (00:0c:29:a0:99:f8) tell 10.16.2.1
10:40:05.344043 arp reply 10.16.1.217 is-at 00:0c:29:a0:99:f8

Линукс

10:47:42.340969 ARP, Request who-has 192.168.10.1 (00:0c:29:90:4d:6a) tell 10.16.2.1, length 28
10:47:42.352337 ARP, Reply 192.168.10.1 is-at 00:0c:29:90:4d:6a, length 46

Арп запрос в одном л2 сегменте, но для разных л3 сегментов нормально обрабатывается и виндой и никсом.
Ну в защиту автора — речь шла об абстрактных компьютерах, а не каких-то определённых системах. Если написать свой сетевой стек — смогут и вроде бы не нарушат никаких стандартов (тут не уверен). Признаюсь, однажды я так и сделал — работало.
Хотя, почитав комментарии, склонен согласиться — любая альтерантивная реализация будет просто скрывать факт существования дополнительного маршрута до сетевого интерфейса. Это существенный момент.
Можно поиграть с маской, и получить шлюз _кажущийся_ из другой подсети.
Задавать эти вопросы сисадминам на собеседовании?

(я, конечно, не сисадмин, но ответил только на вопрос B8)
В11 про обратные маски — я ИНТУИТИВНО когда-то просёк фишку и использовал её (маску с дыркой), но думал, что работает из-за особенностей реализации, а вообще-то не должно было.
Помню, мы лет 10 назад с друзьями выставляли в Win98 маску 255.255.255.100 для дворовой сети, потому что кто-то сказал, что для 100 мегабит последний октет должен быть 100. Вполне проглатывала и оно даже работало.
Потому что, насколько я помню, на какой-то момент времени к маске сети не было требования непрерывности битов. И циски когда-то такое поддерживали. Ну и если задуматься — никаких особых проблем тут нет. Ну кроме проблемы подвешивания за яйца того, кто начнет использовать прерывистые маски в продакшне, так как сопровождать это будет решительно невозможно.
это кстати тоже хороший каверзный вопрос: чем отличается задание маски в виде битов и cidr? хотя он эквивалентен заданному в топике.
Ну положим CIDR — это скорее название когда-то диковинной концепции, а формат маски — частность.
я к тому, что в формате cidr никак не задашь «маску с дырками».
Вы про "/24" и тому подобное? Ага. Но это просто формат записи, появившийся далеко не сразу, и такой формат для IPv4 поддерживается вовсе не везде.
Что-то вроде access-list 100 permit tcp any 10.23.45.67 0.0.122.0
да-да, что-то вроде этого

в 2006 году я маленький и глупый, не знал, как работает интернет, а ещё я подключил ADSL-интернет от провайдера «ВоронежСвязьИнформ», когда он ещё не был куплен центртелекомом, который был потом куплен ростелекомом. Так вот, у них был вебинтерфейс для задания правил фильтрации ip ДО попадания на пользовательское оборудование; если я правильно помнимаю, правила применялись на BRASе. Беспрецендентная штука, на самом деле. BRASы были циски, правила были практически в чистом виде их ACL.

Так вот, безлимитного интернета тогда не было, интернет был дорогой (порядка 1.8р/мегабайт) а вот локальные ресурсы у них были безлимитные. В тех подсетях, трафик из которых был бесплатный, однако, были хосты-исключения с платным трафиком. И наоборот, в интернете была пара адресов, трафик с которых был бесплатным.

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

И тут грянул гром. Всё начало глючить. Например, мне как-то насчиталось 2.5 Гб из интернета, хотя я физически не был способен столько накачать за такое время (adsl-канал не позволял). Ну, ясное дело, левый трафик обнуляли. Расследование показало, что на BRASах от безумного количества правил в фильтрах банально кончалась ОЗУ и им срывало башку. Фильтры переделали — теперь стало можно сделать фильтр из не более, чем шести правил.

Я горд тем, что я был именно тем человеком, который тогда уложился в эти шесть правил, полностью сохранил доступ ко всем беспланым ресурсам и запретил все платные. Говорят, даже техподдержка ссылалась на мою домашнюю страничку, где я расписал эти правила, как и почему. (Там были подробные объяснения к каждому правилу… где-то есть резервная копия той странички.)

В одном из этих шести правил была обратная маска вида 0.0.0.8 чтоб захватить два платных хоста — 80.82.32.19 и .27, т.е. с дыркой (в другом была обратная маска 0.0.0.1 — платными были два соседних хоста, 80.82.32.10 и .11). Несколько сотрудников провайдера говорили мне, что такая маска — неправильная, вроде как и работать не должно, однако им было крыть нечем — оно работало. Объяснение на моей странице таким и было — мол, маска неправильная, но работает видимо вследствие особенностей реализации обратных масок в маршрутизаторах Cisco.

(Если я не ошибаюсь, OlegD имеет ко всему этому некоторое отношение. Тогда он, возможно, уточнит моменты, в которых я ошибаюсь.)

Собственно, до сих пор я и не знаю, почему работало, однако объяснение из статьи вполне меня удовлетворяет ;)
Ну, вообще я с уверенностью не могу сказать чем маска подсети отличается от обратной маски (кроме инверсии). Из того, что точно знаю — маска подсети никогда не может иметь разрывов, а wildcard mask — может, так еще Одом писал. НО! В обратной маске на последних иосах в ACL можно делать разрывы и все работает, но при записи разорванной маски в протокол маршрутизации иос ругается и отвергает команду.

То есть access-list 100 permit tcp any 10.23.45.67 0.0.122.0 сработает, а
router o 1
net 10.23.45.67 0.0.122.0 a 1 уже не заработает.

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

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

Есть, кстати, охренительно элегантный способ считать близкие к идеальным инверсные маски для заданных диапазонов адресов с целью минимизации числа правил.
blog.ine.com/2010/11/25/performing-access-list-computation-route-summarization-acl-manager/
НЛО прилетело и опубликовало эту надпись здесь
Маска сети определяет сеть. Инверсная маска определяет хост

Вот две команды.
router o 1
net 10.23.45.67 255.255.0.0 a 1

ip route 10.23.45.67 0.0.255.255 192.168.45.1

Какая из команд определяет хост?
>ip route 10.23.45.67 0.0.255.255 192.168.45.1

И что, вот прям такая команда отработает? Мне что-то кажется, что вас пошлют.
Конечно не отработает, они обе наоборот написаны.
Как же вы такого не знаете? :)

В OSPF используется инверсная маска вообще-то. Она определяет один конкретный адрес — адрес интерфейса, который будем анонсировать. Можете при случае поиграться с маской, поймете.
Вот в BGP сеть задается командой network 10.23.0.0 mask 255.255.0.0. Это — именно префикс, а не хост. Он не обязан принадлежать локальному интерфейсу.

В ip route тоже определяется сеть, потому маска прямая.
НЛО прилетело и опубликовало эту надпись здесь
В1 — Некоторые товарищи не загоняются на чередование пар — обжимают подряд.
А пытливые просто читают стандарт TIA/EIA-568B
На коротких расстояниях оно даже будет работать. Но потом наводки быстро убивают сигнал.
Да ладно? У нас больше 15 тысяч клиентов на двухпарнике подключены, несколько тысяч на многопарнике, никакие наводки ничего не убивают на расстояниях до 100м, а все потому, что по витой паре идет дифференциальный сигнал по каждой из паре.
Мой комментарий был про обжимку с произвольным чередованием цветов, без разделения, что 1 и 2 — один цвет, а 3 и 6 — другой.
Можно же воткнуть провода, что 3 и 4 будут зелёные, а 5 и 6 — синие, и обжать. И на коротких расстояниях оно будет работать.
Все 8 проводов в витой паре используются, если мне не изменяет память, начиная с 10G. А 100М и 1G работают на 2 парах, так и должно быть.
1G по всем четырём работает. В случае с 100M две лишних пары тоже можно задействовать, под PoE.
интересно то что и при обжатие подряд дешевая сетевая карта работала практически на 100 метрах, а 3COM не работал.
Кстати говоря все 4 пары задействованы в уже наверно умершем 100VG-AnyLan
Разные пары имеют разный шаг скрутки. Никогда не путайте пары. Особенно это сказывается на стандартах, оканчивающихся на T. Вроде, 100 Base-T, 1000 Base-T. На практике сам сталкивался, когда и линки обрывались, и сигнал шёл как черепаха и вообще коннекта не было.
В стандартах, оканчивающихся на T, эта буква означает twisted — витая пара.
В стандартах, не оканчивающихся на T, сложно перепутать пары — там совсем другой тип кабеля)
TX-в стандартах виопарных кабелей, означает что данные передаются в обоих направлениях по РАЗНЫМ парам.
пары между собой путать можно, нет общего стандарта по выбору пар для многопарников, важно лишь то, чтобы TX жилы скурчены вместе, и RX между собой тоже вместе.
ну так если «подряд обжимать», то как раз они будут разделены
Вы что не знаете. что производителя для улучшения частотных характеристик и межпарных наводок испоьзуют разный шаг скрутки пар.
используя не те пары вы ухучшаете данные характеристики и отсюда соответствующие проблемы. вплоть до обрыва линка. И поверьте, всё проверено практикой, особенно касающиеся кабелей noname.
Правда? А если концы кабеля местами поменять, что, будут обрывы линка?

А в стандарте 1000base-T все четыре пары используются совершенно одинаково — дуплекс на 250mbit/s каждая, с подавлением эха. Т.е. им по идее хорошо бы иметь идентичные электрические характеристики. А тут разный шаг скрутки, понимаешь.

Шаг различается — но нужно это только для того, чтобы crosstalk между парами был меньше. Всё. В остальном пары (должны быть) идентичны и без разницы, какую куда. Важно только, чтобы пары не разделялись.
это вы сейчас про многопарник или про витую пару 6ой категории? Не путайте одно округлое с другим продолговатым.
Это касается любой пары. Более того, чем выше несущая, тем более усугубляется проблемы дорастая до того, что 6 категорию рядом с пятой лучше не класть(появляются уже межкабельные наводки).
www.ecolan.ru/imp_info/introduction/mnav/
не вижу катастрофы, дифференциальный метод передачи сигнала решает проблемы с этими маломощными наводками.
Это снижает отношение сигнал\шум.
нет проблем в выделении этого шума и его ликвидации при восстановлении сигнала, шум будет всегда, поэтому никто не заметит разницы для 100Base-T, а для 1000Base уже используется другая категория кабеля.Так что это не более чем позолоченные разъемы у HiFi акустики с обедненной медью.
Не. Вы не правы. Шумит всё-даже квантовые усилители при температуре в 4 кельвина. Соответственно, вы никогда не сможете улучшуть соотношения сигнал\шум больше того значения, в котором виноваты шумы усилителя.
Для 1000 Base-T пойдёт и категория 5.e сертифицированная по стандарту ANSI/TIA/EIA-568-B.2.
Для шестой категории применяют уже 1000-base-tx. Для 5.e 1000-base-t.
Было в моей практике и такое, когда из-за неправильного обжатия линк черепашкой становился.

А про обеднённую медь-это только для сверхвысококачественного сигнала, которого в быту почти не получить.
в моей практике в двух провайдерах на протяжении более 6 лет подключали по многопарнику как Бог на душу положит, брали любые две пары, в итоге никакого криминала, у всех все работает, расстояния были до 100м + использовался кросс. Да и в глаза не видел от производителя вообще каких либо рекомендаций по многопарникам.
Обородывание-обородыванию рознь.
Кабель-кабелю рознь.
Производитель-производителю рознь.
Стандарт-стандарту рознь.
И какие рекомендации могут быть, если чёрным по белому написан стандарт, в КОТОРОМ чётко и ясно указана расцветовка и т.п. А также указан гост по СКС. Всё расчитано по ним. А всё что выходит из пределов стандартов и гостов, тут как говорится «как получится».
Я уже не мало набегался по кабинетам, из-за зависаний свичей, которые между собой были соеденены без кросу.
На 10Mb/s у меня как-то завелась сеть, в которой мотнажник обжал в коннекторе по порядку сперва все цветные жилы, потом — все полосатые, потому что ну так красивее же :)

Вообще Ethernet-classic поразительно живучая штука.
В B12 ping не работал бы даже если в левом сегменте были бы адреса не 169.254.X.X, т.к. на 10.0.0.2 в соответствии со схемой не настроено ни шлюза, ни каких-то маршрутов вовне.
Ответил лишь на 7 вопросов.
В9 — стоит добавить, что directed broadcast запрещён чуть менее чем везде.

В12 — а как вам вот такой трейс:

image

В14 — на спутниковых линках это заметно совсем хорошо, если вдруг попадается нод с наземным аплинком delay падает на сотни мс.
Как такое возможно? Я про адреса 169.254 в конце.
Скажу по секрету — я тоже иногда использую link local адресацию под point-to-point линки. Почему бы и нет? Роутиться эти префиксы не должны даже внутри компании.
Да легко. Это пакет с адресом назначения или источника 169.254 сам маршрутизироваться не может. А вот использовать эти адреса в качестве адресов маршрутизаторов, так же, как и приватные — можно. Выше мы тут обсуждали, фактически этот адрес шлюза (next hop) нужен, чтобы сделать arp-запрос (или что там за технология в вашем канальном уровне) и узнать канальный адрес next hop. После этого пакеты шлются туда, адреса-то у них при этом не меняются.

Ну то есть, на хопе 8 есть правило: 193.104.119.210 доступен через 169.254.254.38. Ну он узнаёт его MAC адрес и пересылает туда пакет, а в пакете адреса остались как были — от 212.199.17.111 до 193.104.119.210.

Когда пакет идёт обратно, у хопа 9 срабатывает правило, что 212.199.17.111 доступен через 169.254.255.6. Он узнаёт его MAC-адрес и шлёт туда пакет от 193.104.119.210 до 212.199.17.111.

Как видите, link-local адреса используются исключительно для ARP-запросов при получении физического адреса следующей системы, не более того. Они в этом отношении ничем не хуже любых других.
Как видите, link-local адреса используются исключительно для ARP-запросов при получении физического адреса следующей системы, не более того.

Не. В данном случае они однозначно используются в качестве L3 адресов для обмена протоколов маршрутизации. Но сути это не меняет
:) я не стал уточнять, откуда «на хопе 8 есть правило: 193.104.119.210 доступен через 169.254.254.38» и почему «у хопа 9 срабатывает правило, что 212.199.17.111 доступен через 169.254.255.6».

Из трейса мы точно знаем, что такие правила там ЕСТЬ (как минимум на восьмом хопе). А вот про динамическую маршрутизацию в трейсе ничего не написано. Может, там садомазо-админ всё настроил статически, откуда вы знаете?
Может, там садомазо-админ всё настроил статически, откуда вы знаете?

Я высказал наиболее вероятную версию :)
APIPA в данном случаем стоит на двух концах GRE-тоннеля. Есть у нас в Израиле один провайдер, который очень любит их использовать именно для этого.
Маленький педант внутри меня поправляет: APIPA — технология самоназначения адреса, а не блок адресов. Ни разу не слышал о поддержке APIPA на сетевом железе.
Как преподаватель очень хорошо вас понимаю :)
Кстати, по поводу В12 и IPv6. В IPv6 link-local на интерфейсе есть всегда (ну или почти всегда), и иногда это очень удобно, т.к. через него можно маршрутизировать. Например, выдал вам провайдер /64 IPv6, причем только одну, а вы ну очень не хотите использовать бридж, то можно спокойно маршрутизировать прямо через link-local адреса. У меня сейчас вот так:

valdikss@valaptop:~ % ip -6 a s wlan0
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2002:5c2a:1f7f:2000:ddf9:895c:f491:9369/64 scope global temporary dynamic 
       valid_lft 27sec preferred_lft 17sec
    inet6 2002:5c2a:1f7f:2000:223:15ff:fe5b:240c/64 scope global dynamic 
       valid_lft 27sec preferred_lft 17sec
    inet6 fe80::223:15ff:fe5b:240c/64 scope link 
       valid_lft forever preferred_lft forever

valdikss@valaptop:~ % ip -6 r
fe80::/64 dev eth0  proto kernel  metric 256 
fe80::/64 dev wlan0  proto kernel  metric 256 
default via fe80::2e0:4cff:fe86:7001 dev wlan0  proto static  metric 1 
default via fe80::2e0:4cff:fe86:7001 dev wlan0  proto ra  metric 1024  expires 29sec

valdikss@valaptop:~ % traceroute -6 ipv6.google.com
traceroute to ipv6.google.com (2a00:1450:4010:c04::68), 30 hops max, 80 byte packets
 1  2002:5c2a:1f7f:2000::1 (2002:5c2a:1f7f:2000::1)  8.667 ms  8.605 ms  8.580 ms
 2  * * *
 3  KHOUSE-TR2.TCINET.RU (2001:6d0:ffd1:301::1)  21.487 ms  21.448 ms  21.413 ms
 4  msk-ix-gw2.google.com (2001:7f8:20:102::246:232)  21.306 ms  21.299 ms  21.265 ms
 5  2001:4860::1:0:2aae (2001:4860::1:0:2aae)  58.533 ms 2001:4860::1:0:2ab1 (2001:4860::1:0:2ab1)  58.440 ms  58.406 ms
 6  2001:4860::8:0:26e5 (2001:4860::8:0:26e5)  58.391 ms  75.739 ms 2001:4860::8:0:26e6 (2001:4860::8:0:26e6)  54.824 ms
 7  2001:4860::2:0:2ab0 (2001:4860::2:0:2ab0)  54.693 ms 2001:4860::2:0:2aaf (2001:4860::2:0:2aaf)  54.726 ms  56.224 ms
 8  lb-in-x68.1e100.net (2a00:1450:4010:c04::68)  55.811 ms  54.698 ms  55.805 ms

valdikss@valaptop:~ % ip -6 r g 2a00:1450:4010:c04::68
2a00:1450:4010:c04::68 from :: via fe80::2e0:4cff:fe86:7001 dev wlan0  src 2002:5c2a:1f7f:2000:ddf9:895c:f491:9369  metric 0 
    cache
Больше того, если у вас в сети работает radvd, на компах и будет в маршруте по умолчанию указан link-local адрес шлюза. Т.е. каждый может легко столнкнуться с машрутизацией белых адресов через link-local-адреса.
Не совсем понял пример с тем, как можно избежать бриджа.

Допустим у нас /64 на внешнем интерфейсе машины А, и link-local на внутреннем, к которому подцеплена машина Б. В принципе, машина Б может использовать link-local адрес машины А с внутреннего интерфейса, но назад то как? Внешний маршрутизатор по ND будет искать машину Б, машина А об этом не в курсе, ND-пакеты не маршрутизируются, никто никого не видит.

Собственно, почему и возникает необходимось в линухах делать proxy_ndp.
Хм, у меня proxy_ndp не включен ни на одном интерфейсе.
Получается так, что для связи между маршрутизатором и клиентом используются link-local адреса, и, в то же время, и у клиента, и у роутера настроены обычные ipv6 global адреса. Клиент отправляет пакет с source-адресом из global через роутер, который доступен по link-local, ну и ответ ему так же приходит.
Интересно. Давайте копнем детальнее. Конкретный пример – это hetzner, который отдает на машины один /64. Проблема – сделать IPv6 внутри KVM-виртуалок на этой машине.

Допустим на хосте у нас есть конкретный IPv6 адрес: 2a01:fad:120:6f3a::2/64, и мы хотим заиметь виртуалку с адресом 2a01:fad:120:6f3a::10. У меня возникает следующая проблема:

Шлем «из мира» пакет на 2a01:fad:120:6f3a::10.
Пакет падает на маршрутизатор хецнера, который начинает у всех спрашивать, а не видел ли кто тут 2a01:fad:120:6f3a::10? (эти пакеты видно на внешнем интерфейсе хоста).
Поскольку хост непосредственно про этот адрес ничего не знает, то он ND успешно игнорирует, роутер шлет пакет назад – не, нету тут такого.

proxy_ndp «лечит» эту ситуацию тем, что хост среди ND запросов начинает обращать внимание на запросы с IP 2a01:fad:120:6f3a::10 (отвечая – шли сюда). Когда конкретный пакет падает на интерфейс правила маршрутизации позволяют перекинуть его с eth0 на vnet0 к гостю и все работает.

Минусы – надо поштучно добавлять все нужные IPv6 адреса в proxy_ndp.

ЧЯДНТ?
Вы, похоже, правы. Я себя не могу пинговать извне, как будто за NAT сижу, только в IPv6. Это, конечно, может быть из-за моего 6to4 шлюза (я замечал проблемы соединения с ним), но, похоже, это именно из-за того, что вы описали. Спасибо, что открыли мне глаза, я бы даже не понял, почему я недоступен из интернета.
Правильно всё вы делаете.
Жаль, я все надеюсь что это костыли и их можно как-то исправить :-) в данном случае правильное решение было бы отдавать хосту бóльшую подсеть, чтобы он мог внутри себя уже раздавать мелкие куски по /64 на другие интерфейсы или бриджить eth0 с vnetXX, чтобы ND-пакеты добирались до гостей.
Правильное решение было бы дать хосту адрес в другой сети, а эту /64 на него маршрутизировать…

Кстати, начиная с 3.8 линукс умеет ipv6 nat. Можно использовать внутри любые адреса, а на шлюзе транслировать в выданную вам /64. Сам не пробовал
хорошие вопросы для собеседования, если надо показательно завалить кандидата. спасибо, добавил в избранное :)
забавно будет, если кандидат, так же решит, показательно блеснуть знаниями которые прочитал здесь
тогда, возможно, этого кандидата валить не нужно, он подходит?
ну можно задать другие вопросы, не менее каверзные, которых здесь не прозвучало. Например задать сеть в духе «мы взяли 10 линков на 100м, соединили их пятипортовыми 100 мегабитными свитчами, и получили таким образом 1км 100mbit ethernet». И попросить описать проблемы, с которыми могут встретиться пользователи такой сети :)
НЛО прилетело и опубликовало эту надпись здесь
ага, и что будет при этом на p2p-линках :)
НЛО прилетело и опубликовало эту надпись здесь
По поводу 15. Сколько угодно примеров, когда сканы идут с приватных адресов, dns-запросы, да мало ли что еще.
Такое ощущение, что их не фильтрует никто на выход. Прикольный побочный эффект у тех, кто этого не учитывает — ответы на такие запросы летят внутрь ЛВС. Когда это не просто ЛВС, а большая межрегиональная приватная сетка крупной конторы на базе L3 VPN (например), такие ответы часто находят свою цель. Иногда это выглядит для владельца приватного диапазона, совпавшего с таким левым src как скан или даже подобие дос-а.

Еще у одного провайдера, который используем как резерв, обнаружилась интересная особенность — он из своей сети выпускает без проблем пакеты с белыми-не-своими src. Забавная получалась ассиметрия. Можно юзать для затруднения анализа трафика со стороны провайдера :)
И да, если брать ответ автора на 15 — то не столько важно понять, откуда эти адреса берутся на интерконнетах маршрутизаторов, сколько то, что немаршрутизируемость — это значит на такой адрес нельзя доставить пакет, а вот адерс источинка может быть любым, в том числе и немаршрутизируемым в инетах. Еще бывает обратная ситуевина. Клиент, делая трейс до локального ресурса провайдера недоумевает — почему с серыми адресами в перемешку белые?
В17. При пинге с маршрутизатора cisco теряется первый пакет. Почему это происходит?
Во-первых, первый пакет теряется только если нет такой записи в arp таблице. Я слышал такое объяснение от инженеров cisco — IOS обращается к arp таблице, не находит там нужной записи. После этого отправляет arp-запрос и дропает ICMP пакет чтобы не хранить в памяти пакет для неизвестного канального адреса. А на следующий пинг запись в arp таблице уже есть. Дроп оправдывают одним из ранних rfc.
А древняя RFC допускала дроп или же обязывала?
Дополнение к вопросу В1 — почему используется зеленая пара, а не симметричная синей коричневая?

Вопрос скорее Винту Серфу — почему в IPv4 не стали использовать динамическую длину адреса, используя Internet Header Length > 5 и поле Options для расширения длины адреса (как расширяется телефонный номер при добавлении кода города, страны)? Это бы решило проблему количества IPv4 адресов не нарушая стандарта и без потери совместимости со старым оборудованием и софтом.
У ipv4 много фич для хорошей работы в арпанете. Сам по себе протокол хороший, но создавался он не для высокоскоростных сетей с низким уровнем ошибок, поэтому проще было разработать новый протокол а не допиливать старый. А по трудоемкости переходы на ipv6, ipv5 и расширение адресации ipv4 одинаковые.
Пардон, запутался, синяя пара нипричем.

Спрошу иначе — почему разводка такая «кривобокая», а не симметричная? Можно ведь использовать по два крайних контакта в 8p8с. 1 и 2 для одной пары, 7 и 8 для другой.
В11. Чем принципиально отличается обратная маска от обычной?

Тем, что первая оперирует хостами, а вторая — сетями. Всегда. Они используются для разных задач.
В14. На одном из хопов по всем трём результатам трассировки величина задержки выше, чем на следующем

Коротко:
На хардварных платформах отправка отклика time exceeded реализована на совершенно других чипах, нежели передача транзитных пакетов.

Длинно:
Возьмем к примеру мой любимый Cat6500. Его «мозги» (то, что отзывается на пинги, обменивается маршрутами, принимает ssh соединения и т.д.) сосредоточены на супервизоре в MSFC. MSFC отвечает за программирование PFC (ну и DFC при их наличии), в котором и осуществляется обработка и передача пакетов. По хорошему, ни один транзитный пакет не должен попадать в MSFC.
Пакет с TTL 0 не может быть обработан PFC, так как тут требуется более интеллектуальная обработка, чем та, на которую он способен (требуется сгенерить time exceeded и отправить его назад отправителю (или вперед получателю в случае MPLS, да не суть)). Потому такой пакет переадресуется MSFC. А тот может в данный момент быть нагружен, ICMP на нем не в приоритете, потому он может на несколько миллисекунд отложить отправку ответа, пока не закончит с более важными делами.
Но да, причиной может быть и возврат time exceedeed другим маршрутом.
В16. Чем обусловлены такие задержки при трассировке?

При трассировке по MPLS пакеты отскакивают от PE, а не от CE — PE уже знает, как вернуть пакет обратно. Разумеется, пакет с истекшим TTL не может быть передан CE.
В17. При пинге с маршрутизатора cisco теряется первый пакет. Почему это происходит?

Кстати — обычно сгенерированный локально пакет как раз будет не отброшен, а задержан. И для первого пакета будет высокий RTT.
Автор, оформите ответы тегом «спойлер» после каждого вопроса, это удобно.
Для чего нужен адрес сети? Почему его нельзя назначить хосту?

Для того чтобы быстро определить принадлежность IP данной сети: ipaddr & netmask == netaddr
Чем проще метод определения принадлежности — тем проще (и быстрее) маршрутизация
В общем-то это не даёт ответ на вопрос, почему нельзя использовать адрес .0 для хоста. То есть понятно, что нам это непривычно, но теоретических препятствий этому не вижу. Впрочем возможный ответ уже дали, я его добавил в топик.
Отсылка в книгу не совсем верная. Цитата из книги:
Unfortunately, an early release of TCP/IP code that accompanied Berkeley UNIX incorrectly used all zeroes for broadcast. Because the error stil survives, TCP/IP software often includes an option that allows a site to use all zeroes for directed broadcast.

И все это относится к этапу classful addressing scheme — когда нельзя было задать маску /23 или /9, а были только фиксированные /8, /16 и /24. На том этапе не нужна была и маска сети как таковая, так как класс сети (и маску соотв.) можно было определить по первым битам адреса (0... - /8, 10... - /16, 110... - /24). В том случае броадкастом и адресом сети могло быть что угодно, но согласованное между всеми заинтересованными лицами.

Но когда появилась идея CIDR, т.е. возможность «резать» адресное пространство в практически произвольных пропорциях — появилась необходимость в маске и правильном броадкасте. Поэтому уже сделать маску сети с единицами, а броадкаст нулями не выйдет из-за того что броадкаст будет одинаковым для нескольких сетей.

В принципе, этой же цитатой можно объяснить и почему хосту нельзя назначить адрес сети — так как существовали бажные реализации, которые могли интерпретировать такой адрес как броадкаст и пакет был бы отправлен не одному адресату, а всей сети.
Или для чего нужен широковещательный адрес?

Все из-за той же простоты и скорости. Если пришел пакет с dstip, то проверить предназначен ли он нам достаточно следующего условия: dstip & myip == myip
Это условие будет правдой и в случае если dstip == myip и если dstip будет броадкаст адресом.

Можно было бы использовать для него адрес сети.

Пока сети были classfull — да, вполне можно было попробовать. Но вы попробуйте отличить сеть 192.168.1.0/24 и 192.168.1.0/25 — адрес сети у них будет одинаковый, а в IP заголовке передается только один адрес (без маски). Поэтому используется броадкаст — так как он различается в случае classless сетей :)
Да, согласен, протупил. Нельзя с утра без кофе :) Пока не могу придумать изящного алгоритма, а без него — все равно два сравнения и тогда все равно, похоже, какой адрес будет броадкастом. А единицы взяты из езернет наследия.
В5. Знаете ли вы, что реальная битовая скорость Fast Ethernet 125 Мб/с? Почему так?

На этот вопрос лет 10-12 назад на одном семинаре бородатый дед из НИИ Дальсвязи отвечал так: «потому, что „без темной сущности физики“ для технологии 100Base-T рабочая частота 125 МГц, а для 10Base-T около 10 МГц.»
Следовал вопрос :«а как же 1000Base-T, ведь у кабеля типа „витая пара“ пропускная способность не выше 350МГц?»
«Как-как, а гармоники на что?!»
:)

Вопрос 7 — ваш ответ неправильный.
LACP прекрасно определяет unidirectional links. Тайм-аут либо 1, либо 30 секунд — есть два механизма в lacp, fast и slow transmission.
UDLD/BFD нужны только для уменьшения времени реакции. Более того, в свое время пришлось выпустить отдельный RFC по BFD поверх LACP, т.к. BFD изначально протокол L3 и воспринимает весь PortChannel как один агрегированный линк и может определить только падение всего линка.
B. 14 Кроме вашего ответа, есть еще другая ситуация: когда ЦПУ маршрутизированного устройства загружено, а маршрутный процессор нет, то пакет маршрутизируется без задержек, когда как ответ от ЦПУ маршрутизатора на всякие icmp запросы может вызвать задержку.
Б. 17 — это дела вендора, у каждого вендора есть свои закидоны на эту тему и от железки к железке внутри вендора тоже.
По поводу идентификатора сети. Хосту вообще запрещается назначать адрес идентификатора его же сети, по правилам распределения адресов нельзя указывать идентификатор хоста, состоящий только из нулей или только из единиц. Почему? Думаю уже мало кто вспомнит, возможно из-за аппаратного обеспечения, чтобы хосты нумеровались с единицы и так далее, а не с нуля. А почему не с нуля — это надо глубоко лезть в аппаратное обеспечение, наверняка там найдется ответ у какого-нибудь вендора.
Возможный ответ уже дали, я добавил его в статью.
В1 — предполагаю что так удобно для подсоединения к встроенным в разъем трансформаторам, потому что с точки зрения удобства трассировки плат — только гемор лишний, с точки зрения кабеля — фиолетово вообще тоже — остается только какое то удобство в подключении внутри разъема трансформаторов
Мерзкая картинка для привлечения внимания:(
Ответ: потому. что солнце не белое, посылает мало фиолетового, и у нас зрение отстой, плохо видит фиолетовый. Если бы там были такие лучи и мы бы могли их видеть нормально, было бы фиолетовое.
есть там фиолетовое и ультрафиолетовое — тут вопрос чувствительности глаза — он более чувствителен к зеленому, поэтому воспринимаемый нами цвет смещается от фиолетового к голубому
вообще-то да, есть, всё зависит от глаз
Ещё один вопрос, который любят на задавать на интервью — почему когда в трейсе, в котором последний девайс — циска, второй реплай вылетает, и как это починить.
Никогда если честно такого не видел :). И какой же ответ?
Там стоит ограничение на частоту отправки реплаев, чтобы этим не перегрузить процессор.
Решается командой ip icmp rate-limit unreachable [ms]. По умолчанию стоит не более 1 unreachable в 500мс.
А почему тогда это может не работать? Ограничение стоит, но реплаи не теряются.
Могу только предположить, что вы укладываетесь в таймаут. Попробуйте засечь время. Посмотрите show ip icmp rate-limit.

R2(config)#ip icmp rate-limit unreachable 500

R1#traceroute 192.168.12.2
1 192.168.12.2 84 msec * 60 msec

Должно быть как-то так.
Все работает, это я тупой.
Windows делает трейс по ICMP, оказывается, соотвественно port unreachable просто не генерится.
В10: Может ли адрес 10.0.1.0 быть использован для адреса хоста?

Вроде ещё может быть в случае соединения точка-точка и длине маски сети 31. Хотя не факт, что это есть в стандарте и, говорят, не все железки могут поддерживать.
P.S. Беглым просмотром результатов поиска в яндексе нашёл ссылку на RFC 3021, которое вроде как разрешает 255.255.255.254. Сам ещё не читал, не успею отредактировать запись иначе.
Зачем так сложно? Запихните его в сеть /8 и хосты смогут иметь любые адреса от 10.0.0.1 до 10.255.255.254.
Я просто предложил ещё один вариант.
Все верно можно использовать маску /31 для соединений точка точка согласно RFC 3021. Версия операционки маршрутизатора (если это Cisco) должна быть не ниже 12.2T.
У вас ошибка, вместо 240.0.0.0/4 нужно 224.0.0.0/4.
Адрес сети в виде адреса хоста можно использовать, как уже написали выше, согласно RFC 3021.
С какой стати вы вычеркиваете мультикаст? Он хороший, не надо его трогать (хотя под него действительно многовато адресного пространство выделили).
Указанный автором префикс — 240.0.0.0-255.255.255.255. Ошибки нет. Этот блок не задействован.
Да, уже обнаружил. Надо было ложится спать, а не на хабр лезть. :)
По поводу пауз между посылками сразу вспомнился Serial Experiments Lain. Эти паузы оставшиеся в «наследство» использовались для скрытой активности. Сказка, сказкой да в ней намек…
Уточните, пожалуйста, В10.
Разве может быть крайний байт для адреса хоста быть нулем (в примере 10.0.1.0)? Мне всегда казалось, что это только для масок сетей.
В ряде случаев может
Домашнему роутеру можно прописать 192.168.0.0 (нет возможности проверить в данный момент)? AFAIK, нет.
Запросто можно прописать 192.168.0.0 с маской 255.0.0.0 например, другое дело что смысла в этом мало. Но можно.
192.168.1.0/23 пропишите.
Даже интерессно как.
руками. 192.168.1.0 маска 255.255.254.0. или вы о чем?
Я видимо контексты беседы перепутал (сейчас не вспомню). Прошу прощения.
До этого обсуждали сети и маршруты и натация медя сбила с толку. Сеть такой быть не может, а IPшник устройства конечно может.
А как вы обычно это делаете?
См. выше.
Да, может, в двух случаях:
1) Использование специальной конфигурации маршрутизатора, позволяющей назначать адрес сети и широковещательный хостам. Например нередко используют маску /31 для р2р линков
2) Например для сети 10.0.0.0.23 диапазон адресов будет 10.0.0.1-10.0.1.254 и абсолютно все адреса можно использовать.
НЛО прилетело и опубликовало эту надпись здесь
Мы используем /31, всё пучком.
Больше того, один провайдер в Воронеже (СуммаТелеком), когда мы попросили белый адрес, заставил оплачивать сеть из четырёх адресов — и сделал её /30. Такого безобразия я вообще нигде больше не видел.
> Ethernet совмещает в себе функции канального и физического уровня модели OSI

Не упоминайте ISO всуе.
Идеи заложенные в OSI противоречат реализованным в Ethernet. Не может одно описываться другим, совмещать и прочий бред. ISO это не семь прямоугольничков, а толстый подробный документ. Все эти соответствия появились в результате фантазий об универсальном стеке (реализации) в ОС и железках.
Да ладно вам… Стек TCP/IP в целом неплохо накладывается на модель OSI (те самые прямоугольники). И мне референсная модель OSI нравится больше, чем модель TCP/IP:
1) Не надо было сплющивать канальный и физический уровни в один.
2) L5 в самом TCP/IP все-таки иногда существует (хотя не так явно, как у ISO). К примеру, может определяться куками в случае HTTP. И даже для сетевика L5 существует, это довольно важный вопрос при работе с балансировщиками. L6 у TCP/IP тоже есть хотя бы в виде SSL. А в модели TCP/IP ни одного из них нет.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории