Пользователь
37,7
рейтинг
7 августа 2013 в 11:07

Администрирование → Каверзные сетевые вопросы

Давно была идея собрать воедино интересные вопросы, касающиеся сетей.

Объединяет их то, что все они довольно простые, но мы подчас о них не задумываемся (я во всяком случае о них не задумывался).
В общем я их собрал, подбил, нашёл ответы.
Итак, блиц опрос:

Начнём с самых низких уровней и с самых простых вопросов



В1. Почему для витой пары выбран такой странный порядок: синяя пара на 4-5, разрывая зелёную, которая на 3, 6?




Ответ
О1: Сделано это в угоду двухконтактному телефонному разъёму. Таким образом, например, в патч-панель можно вставить как телефонный кабель, так и витую пару.
Можно даже через один кабель вывести и сеть и телефонию, но я вам этого не говорил!

habrahabr.ru/post/158177.


В2. В стандарте Ethernet между кадрами всегда имеется промежуток, называемый IFG (Inter Frame Gap) длиною 12 байтов. Для чего он нужен, и почему он присутствует в современных стандартах?


Ответ
О2: IFG использовался активно во времена расцвета CSMA/CD. Это пауза, которую должно делать передающее устройство перед отправкой фрейма, чтобы избежать коллизий.
Дело в том, что в когда несклько хостов подключены в хаб, высока вероятность того, что они начнут отправлять данные в одно время, и возникнет коллизия или одна станция оккупирует монопольно канал.
При использовании IFG пока один хост ждёт, другой, может отправлять.
Вообще говоря, IFG измеряется в микросекундах. Его длительность для Fast Ethernet составляет 0,96 микросекунды.

Уже в гигабите CSMA/CD есть только условно, а в 10G его нет вовсе. Это потому, что домен коллизий современных коммутаторов ограничен одним интерфейсом/кабелем, плюс работают в полнодуплексном режиме.
Так для чего же мы до сих пор теряем драгоценные 12 байтов?
Просто никто не хочет менять стандарт.

Красочное описание Искать по словам «Now what is not shown»


В3. Чем вызвано ограничение на длину сегмента Ethernet и минимальный размер кадра?

Ответ
О3: Обычно объясняют этот факт тем, что в кабеле на большИх длинах возникают затухания и

Истинная причина кроется всё в том же механизме CSMA/CD.
Чтобы коллизия в линии была успешно обнаружена, в тот момент, когда на удалённой стороне будет принят первый бит, станция ещё не должна закончить передачу текущей порции данных.
Объясню на пальцах. Берём полудуплексную сеть. Допустим станция 1 начинает передачу данных. Следом за ней, что-то пытается передать станция 2. До неё ещё не дошёл сигнал от Станции 1 и поэтому ей можно. Сигнал от станции 2 досигнет станции 1 ещё до того, как она закончит передачу своих данных. Обе станции обнаруживают коллизию и прекращают передачу. Всё отлично. Данные не потеряны и в следующий раз у них обязательно получится.

Теперь предположим другую ситуаицию. Станция 1 передала порцию данных и готовится к следующей. Но до станции 2 сигнал ещё не дошёл, она понимает, что можно передавать.
Ага, где-то посередине они пересеклись. Станция 2 это поняла и прекратила передачу, а Станция 1 получила искорёженные данные, при этом продолжая думать, что свою задачу по передаче сигнала выполнила, и потому берётся за следующую порцию.
В итоге потерян кадр, потому что на обратной стороне его собрать не сумели — не всё получили. Да, вышестоящие протоколы это смогут детектировать, перезапросить их повторно, но сколько напрасных миллисекунд на это будет затрачено?

Такая ситуация исключена, если выполняется условие, озвученное в начале: когда принят первый бит в конце сегмента, отправитель ещё не передал последний бит. Тогда ничто не будет потеряно.

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

Осталось определиться с размером этого блока данных.
Минимальная порция данных для стандарта Fast Ethernet составляет 512 бит или 64 байта — это так называемый Slot time. Ничего эта цифра не напоминает? Минимальный размер Ethernet-кадра, возможно? (Для Gigabit Ethernet это значениу увелично до 512 байтов).
Вот именно эти 64 байта и должны растянуться на всю длину сегмента.

Я попытался подробнее разобраться в этой теме и подготовил отдельный материал, чтобы вам было проще разобраться: 100 метров Ethernet.

www.ixbt.com/comm/tech-fast-ethernet.shtml#_Toc91050385


В4. Как вычисляется Ethernet Overhead

Согласно стандарту 802.3, мы имеем:



Почему при расчёте overhead размер служебных данных Ethernet берётся 14 байтов, а не 38 или 18 (Dest+Source+Legth+FCS).

Ответ
О4: Легко понять, почему в расчёт не идут Преамбула и IFG. Как вам известно Ethernet совмещает в себе функции канального и физического уровня модели OSI. И в то время, как MAC DST, MAC SRC, Type и FCS — являются атрибутами канального уровня, преамбула и IFG — физического. Логично, что при обработке кадра устройство ориентируется только на его полезную длину, без служебных байтов физического уровня.
При этом заметьте, что при расчёте пропускной способоности, всё-таки учитывается полная длина: 38 байтов + полезная нагрузка.

Хорошо, но как быть с FCS? Ведь его чаще всего не учитывают при вычислении накладных расходов (overhead) и к длине полезной нагрузки добавляют только 14 байтов (MAC DST+MAC SRC+Type).
Тут дьявол в мелочах и чтобы найти ответ, нужно обратиться к самой сути FCS — Frame Check Sequence. IP не имеет встроенных средств контроля целостности исходной информации, поэтому эти функции берут на себя TCP (общий контроль — все ли данные доставлены корректно) и Ethernet. Последний проверяет на повреждения каждый конкретный кадр, высчитывай контрольную сумму. То есть он берёт весь полностью кадр за исключением поля FCS, обрабатыавет его и сравнивает полученнй результат с исходным значением контрольной суммы, если не совпадает — отбрасывает. Если совпадает, сначала поле FCS снимается, затем оставшийся кадр передаётся вышестоящим инстанциям. Фактически эта обработка происходит в железе на самом раннем этапе и те процессы, которые занимаются собственно кадром и вычисляют его размер, получают на самом деле только 14 избыточных байтов заголовка.
Такая интересная арифметика.
forum.nil.com/viewtopic.php?f=12&p=582


В5. Знаете ли вы, что реальная битовая скорость Fast Ethernet 125 Мб/с? Почему так?


Ответ
О5: Ethernet заимствует у FDDI метод кодирования 4B/5B, когда любые четыре бита MAC-подуровня представляются пятью физическими битами с чередующимися нулями и единицами. Для чего это делается — уже глубокая физика.
При этом исходные данные должны передаваться со скоростью 100 Мб/с согласно стандарту Ethernet. Из-за этого избыточного бита действительная скорость на 25% больше (5 больше 4 на 25%), что составляет, разумеется, 125 Мб/c.
citforum.ru/nets/lvs/glava_5.shtml


В6. Всем известно, что комитет 802 занимается стандартами по ЛВС. Также, общеизвестно, что Ethernet — это 802.3

С другой стороны сейчас общепринят стандарт Ethernet II.



В чём же отличие кадров Ethernet II от кадров 802.3 и почему он вообще II?

Ответ
О6: Кадры формата 802.3 содержат поле Length вместо привычного нам Type (EtherType). Исторически сложилось, что существует несколько стандартов для кадров Ethernet (помимо перечисленных).
Потом DEC, Intel и Xerox доработали их до универсального красивого решения Ethernet II (Ethernet DIX по первым буквам компаний), которое стало экстремально популярным — IP работает именно поверх него.
Поле Length прежде говорило о общем размере полезной нагрузки, что было в общем-то мало информативно и тем более такой кадр мог нести только один тип вышестоящего протокола. Значения Length могут быть до 1500 (0x05dc).
В кадре Ethernet II отказались от поля Length и осовобившиеся 2 байта использовали под поле Type (EtherType), которое определяет тип вышестоящего протокола. Чтобы чётко отличать их от 802.3 берутся значения, выше 1536 (0x0600).
Так например, если кадр несёт IPv4, то тип будет 0х0800, ARP — 0x0806, VLAN (802.1q) — 0x8100, IPv6 — 0x86DD, QinQ — 0x9100 итд.
pascal.tsu.ru/other/frames.html#as-h4-2325214


Немного повыше поднимаемся



В7. LACP применяется для управления интерфейсами в LAG. Сможет ли он отследить вот такую ситуацию


Здесь коммутаторы подключены двумя оптическими интерфейсами, объединёнными в LAG. В качестве среды используется два оптических кабеля — один для приёма, другой для передачи. Что произойдёт после обрыва одного кабеля?

Ответ
О7: Вообще говоря LACP — примтивнейший протокол. Он принимает решение о том добавить или удалить интерфейс из LAG практически лишь на основе того какое состояние у интерфейса — Up или Down.
В случае обрыва только одного кабеля прекратится передача в одном направлении — исчезнет сигнал лазера. Как правило коммутатор, как только перестаёт видеть сигнал удалённой стороны, переводит интерфейс в сотояние Down. В ситуации, как на рисунке, SW2 сигнал видеть перестаёт, потому что кабель повреждён, и переводит интерфейс Gi0/0/1 в Down. В то же время SW1 сигнал видит и его интерфейс Gi0/0/1 в Up'е.

На SW2 LACP удаляет Gi0/0/1 из LAG, а на SW1 нет. Таким образом получается проблема с передачей данных.
Для избежания таких ситуаций необходимо воспользоваться одним из протоколов UDLD (UniDirectional Link Detection), например BFD или EFM OAM.
UPD: Пользователь Karroplan внёс поправки в этот вопрос:
LACP прекрасно определяет unidirectional links. Тайм-аут либо 1, либо 30 секунд — есть два механизма в lacp, fast и slow transmission.
UDLD/BFD нужны только для уменьшения времени реакции. Более того, в свое время пришлось выпустить отдельный RFC по BFD поверх LACP, т.к. BFD изначально протокол L3 и воспринимает весь PortChannel как один агрегированный линк и может определить только падение всего линка.



Ещё выше



В8. Смогут ли пинговать друг друга два компьютера в таких условиях



Ответ
О8: Да смогут. Несмотря на то, что шлюз по умолчанию находится в другой подсети, ARP-запросы будут отправляться в его поисках.
То есть ПК1 отправляет шиоковещательный ARP запрос «Кто тут 192.168.0.1?». ПК2 его получает и, естественно, отвечает, что это он и есть. ПК1 получает ARP-ответ и вносит его МАС-адрес и IP-адрес в свою таблицу. Далее ничего не препятствует им обмениваться данными.
UPD: Пользователь merlin-vrn дал более верный исчерпывающий ответ на этот вопрос:

Как компьютер ПК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.

Т.е. у нас есть два компа и локальные маршруты «непосредственно» друг до друга, хоть оно и в разных подсетях. Конечно, будет пинговаться.

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


В9. В чём разница между Directed Broadcast (192.168.0.255) и Limited broadcast (255.255.255.255)


Ответ
О9: Пакет, отправленный на адрес 255.255.255.255 ограничен лишь той сетью, где он зародился — МАС-адрес выставляется в ffff-ffff-ffff. Если пакет отправляется на 192.168.0.255, то сначала согласно всем правилам маршрутизации пакет достигает сети назначения 192.168.0.0, а уже потом рассылается всем хостам в этой сети.


В10: Может ли адрес 10.0.1.0 быть использован для адреса хоста?


Ответ
О10: Да, конечно, может, если например, на интерфейсе у вас применена конфигурация 10.0.0.0/23. Тогда диапазон доступных адресов будет 10.0.0.1-10.0.1.254 и все они могут быть использованы. В том числе 10.0.0.255.
UPD: Второй пример — использование маски /31, когда адрес сети и широковещательный адрес можно назначать узлам.


В11. Чем принципиально отличается обратная маска от обычной?


Ответ
О11: Естественно, заметное отличие в инвертированности этой маски, то есть нулями обозначается та часть, которая должна быть неизменной. Но это не принципиально ведь.
Существенная разница в том, что здесь нули могут чередоваться с единицами. То есть если маска подсети не может содержать такой набор: 10110001, то обратная маска может.

Таким образом вы, например, сможете выделить во всех подсетях хосты с адресом 10.5.Х.123, например, и разрешить им доступ в Интернет. Или отделить все чётные адреса от нечётных и реализовать распределение трафика ровно пополам на основе адреса отправителя.

UPD: Отличие заключается также в том, что прямая маска оперирует сетями, а обратная — хостами.


В12. Для чего нужны адреса 169.254.0.0/16 (автонастройка APIPA в Windows и nonzeroconf в unix)

И почему такой пинг не работает:


Ответ
О12: Сеть 169.254.0.0/16 была изначально задумана как сеть Link-Local.
Суть её заключается в том, что, если хост не имеет статического IP-адреса и не может получить его автоматически, например, от DHCP-сервера, то он сам себе назначает адрес из диапазона 169.254.0.1-169.254.255.254. После этого он сможет общаться с другими хостами в этой сети, имеющими такие же адреса.
Адрес выбирается случайным образом благодаря генератору случайных чисел так, чтобы он не совпал с уже существующим адресом (проверяется ARP-запросом).
Примером применения может быть какая-нибудь Ad-Hoc сеть, где у станций задача — общаться между собой.

Но ключевая особенность такой сети в том, что взаимоотношения возможны только между станциями, находящимися в этом сегменте, отсюда и фраза Link-local в определении. Пакеты не могут передаваться дальше маршрутизатора. Более того, даже если у хостов будет указан адрес шлюза, по стандарту он не должен на него передавать пакеты ни при каких условиях.
Этим и объясняется то, что пинг, как на рисунке не работает. Всё согласно RFC.


В13. А знаете ли сколько всего адресов пропадает, кроме известных всем приватных и 127/8?


Ответ
О13: На самом деле мы теряем:
Одну сеть класса А: 127.0.0.0/8
Одну сеть Класса В: 169.254.0.0/16
Одну сеть /10: 100.64.0.0/10
Одну сеть /15: 198.18.0.0/15
Пять сетей класса C: 192.0.0.0/24, 192.0.2.0/24, 192.88.99.0/24, 198.51.100.0/24, 203.0.113.0/24.
И одну сеть /4: 240.0.0.0/4

Итого 285410560 адресов.

Вот такие мы расточительные.


Почему во время трассировки могут быть такие ситуации



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


[eucariot]$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets
...
6 vl545.mag02.lon01.atlas.cogentco.com (149.6.3.153) 11.464 ms 11.378 ms 11.347 ms
7 te0-7-0-5.ccr21.lon01.atlas.cogentco.com (154.54.74.109) 5.653 ms 4.725 ms 6.209 ms
8 te3-2.ccr01.lon18.atlas.cogentco.com (154.54.62.66) 4.951 ms te2-1.ccr01.lon18.atlas.cogentco.com (154.54.61.214) 5.050 ms te3-2.ccr01.lon18.atlas.cogentco.com (154.54.62.66) 5.086 ms

Ответ
О14: Если такая задержка единичная, то, скорее всего, это вопрос буфферизации/приоритезации. Например, временная перегрузка на линии.
UPD: Пользователь JDima внёс дополнения по этому вопросу:
Коротко:
На хардварных платформах отправка отклика time exceeded реализована на совершенно других чипах, нежели передача транзитных пакетов.

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


Гораздо интереснее ситуация, когда такие результаты повторяются. Мы прекрасно понимаем, что 3 пролёта, например, пакет не может проходить быстрее, чем 2. Так в чём же дело?
А дело в том, что трассировка показывает только прямой путь от нас до интересующего сервера. При этом мы ничего абсолютно не знаем об обратном пути. Как бы мы этого ни хотели, узнать обратный путь можно, только отправив трассировку в обратную сторону.
Но, несмотря на это, задержка по сути — это Round Trip Timer, то есть время пути пакета туда и обратно.



Таким образом при TTL=3 пакет попадает на R4 одним путём, а возвращается другим. А R3 — это слабенькая старенькая 26-ая циска, которая уже загибается и не может пропихнуть 90 Мб/с. В итоге там случается перегрузка и именно на обратном пути возрасает задержка.
Зато, когда traceroute посылает следующий тестовый пакет с TTL=4 обратно он идёт тем же путём и задержка нормализуется.





В15. Иногда в трассировке появляются серые адреса (в середине или как последний хоп). Как так, ведь они не маршрутизируются в Интернете?




Ответ
О15: Согласно RFC такие адреса действительно не маршрутизируется в глобальном интернете, но речь идёт о маршрутизации между AS.
При этом, если где-то в сети провайдера, один из маршрутизаторов будет подключен через приватные адреса, то такая ситуация становится возможной. Дело в том, что маршрутизатор должен в ответном сообщении TTL expired установить в качестве адреса отправителя адрес того интерфейса, на который пришло изначальное сообщение от traceroute.
Станция, с которой запускался трейс покажет именно этот адрес.



И в такой ситуации вы как раз увидите приватный адрес.


В16. Чем обусловлены такие задержки при трассировке?


1. te2-4 PAO2 bl (69 22 1 3 209) 1 160 1 060 1 029 4.ar5.PAO2.gblx.net (69.22.153.209) 1.160 ms 1.060 ms 1.029 ms
2. 192.205.34.245 (192.205.34.245) 3.984 ms 3.810 ms 3.786 ms
3. tbr1 sffca ip att net (12 123 12 25) 74 848 ms 74 859 ms 74 936 ms tbr1.sffca.ip.att.net (12.123.12.25) 74.848 ms 74.859 ms 74.936 ms
4. cr1.sffca.ip.att.net (12.122.19.1) 74.344 ms 74.612 ms 74.072 ms
5. cr1.cgp ( ) cil.ip.att.net (12.122.4.122) 74.827 ms 75.061 ms 74.640 ms
6. cr2.cgcil.ip.att.net (12.122.2.54) 75.279 ms 74.839 ms 75.238 ms
7. cr1.n54ny.ip.att.net (12.122.1.1) 74.667 ms 74.501 ms 77.266 ms
8. gbr7.n54ny.ip.att.net (12.122.4.133) 74.443 ms 74.357 ms 75.397 ms
9. ar3.n54ny.ip.att.net (12.123.0.77) 74.648 ms 74.369 ms 74.415 ms
10.12 126 0 29 (12 126 0 29) 76 104 76 283 76 174 12.126.0.29 (12.126.0.29) 76.104 ms 76.283 ms 76.174 ms
11.route-server.cbbtier3.att.net (12.0.1.28) 74.360 ms 74.303 ms 74.272 ms

Ответ
О16: Это явный указатель на то, что трассировка прошла сквозь MPLS-сеть.
В такой сети, когда используется коммутация на основе меток MPLS, а не IP-адресов, трассировка ведёт себя кардинально иначе.



Вот допустим с CE1 запускаем трассировку на CE2. Между PE1 и PE2 установлен LSP.
И вот CE1 отправляет пакет с TTL=2. Он доходит до маршрутизатора P с MPLS-меткой, например 2000. TTL к этому времени равен 1, P уменьшает его и понимает, что оригинальный пакет нужно выбросить, а вместо него отправить TTL-expired на адрес CE1. Он подготавливает ICMP-пакет, в качестве получателя ставит CE1, НО! согласно таблице меток MPLS метка 2000 должна быть заменена на 3000 и соответственно, пакет отправлен на интерфейс FE0/1. То есть в сторону обратную от получателя.
Пакет долетает до РE2, который раздевает его и отправляет на СЕ2 уже чистый IP.
СЕ2 благополучно согласно своей таблице маршрутизации отправляет этот пакет назад в MPLS сеть.



То есть несмотря на то, что пакет должен был пролететь 2 хопа и вернуться, он прошё весь путь от источника до получателя и назад.
Аналогично при TTL=3, после PE2 пакет сначала передаётся на СЕ2 вместо того, чтобы сразу вернуться на СЕ1 — снова проходит весь путь.



Именно поэтому на всех практически хопах задержки оказываются примерно одинаковыми — путь-то они прошли один.

UPD: На рисунке и в описании ошибка, «разворачивает» пакет TTL exceed уже РЕ2, до СЕ он не доходит.



В17. При пинге с маршрутизатора cisco теряется первый пакет. Почему это происходит?




Ответ
О17: Принято считать, что маршрутизатор отправляет ICMP-запрос и, не получив ICMP-ответ, рисует точку. А ICMP-ответа нет, мол потому, что удалённое устройство должно сначала изучить ARP.
Заблуждение! Его легко проверить включив дебаг или собрав дамп с интерфейса:


Как видите, на самом деле первый ICMP-запрос не отправляется вовсе. ARP улетел и прилетел, а ICMP отброшен. Это видно по тому, что всего 4 ICMP-запроса и 4 ответа.
blog.ipspace.net/2007/04/why-is-first-ping-lost.html


В18. Известно, что в качестве приватных подсетей были выбраны сети из разных классов: A, B, C. Но почему имено 10/8, 172.16/12, 192.168/16?

Ответ
О18: Я бы, наверно, так и не нашёл ответ на этот вопрос — тема совершенно не освещена ни в рунете, ни в большом Интернете. Но мой коллега подошёл к этому радикально. Он написала два письма в IANA.
Dear YYY,

Thanks for contacting us.

We do not have the answer to your question and suggest you contact the authors of «Address Allocation for Private Internets» (RFC 1597), the document first setting these ranges aside. You can find details about the document here: www.rfc-editor.org/info/rfc1597

Kind regards,


Но людям из 1597 он уже писал) там уже адреса не валидные.
А вот второе письмо оказалось более результативным:
Dear YYY,

Thank you for your inquiry.

For more information about the private use space, see www.rfc-editor.org/rfc/rfc1918.txt.

As to why those specific blocks were chosen, we believe 10/8 was chosen because sri-nic.arpa (10.0.0.51) was embedded in pretty much every unix and multics system as the hardcoded source of hosts.txt and various other files. For the others, the decision was made that since a class A was allocated, there should be blocks of class Bs and Cs too. It could just be that those blocks were available.

Hope that helps.

Best regards,

Michelle Cotton
Manager, IANA Services
ICANN


В общем-то исчерпывающий ответ. Больше искать правду негде.





Неотвеченными остался только один интересный, но, возможно, надуманный вопрос. Как я его ни крутил, как ни гуглил, но его тайна пока не раскрыта.

Для чего нужен адрес сети? Почему его нельзя назначить хосту?
Логичный первый вариант — он определяет сеть. Ну а что, так уж нужен для этого отдельный адрес? 192.168.1.110/24 определяет сеть точно так же хорошо, как и 192.168.1.0/24. Да и это всё равно не мешает назначать этот адрес хосту.
Вторая идея — так прописываются маршруты на роутерах. Это же не более, чем условность, ведь по сути см. первый вариант.
Встречал я также описание того, что некоторые вендоры преобразуют пинг на адрес сети в широковещательный кадр, но какой в этом смысл?

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

Симметричный вопрос:
Или для чего нужен широковещательный адрес? Можно было бы использовать для него адрес сети.

UPD На данный вопрос приблизительный ответ дал один из читателей:
По последнему вопросу, у Дугласа Комера в 4 издании «Interworking with TCP/IP» есть соответствующая глава. Нули в последнем октете не более чем соглашение, никакой технической подоплёки в этом нет. Там же указывается, что в раннем программном обеспечении протоколов в UNIX'ах пользовались инвентированным соглашением, т.е. для обозначения сети использовали единицы (192.168.1.255/24), а для широковещания — нули, но в последствии этот условный «баг» исправили.
По поводу маршрутизаторов. Они не хранят пути в табличном виде, а используют, например, дерево для эффективного поиска маршрута. Так зачем хранить ненужные листья, если они все равно не будут просматриваться? (Маршрутизатор будет продвигаться по дереву 192.168.1/24, а не по 192.168.1.110/24)

Спасибо.
Марат @eucariot
карма
568,0
рейтинг 37,7
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

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

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

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

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

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

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

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

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

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

    Я не согласен с вашим ответом. Как вы вообще собираетесь назначить компьютеру шлюз 192.168.0.1, если у компьютера адрес в сети 192.168.1.0/24?
    • +1
      Плюсую. Может, имелся в виду дефолт не на адрес, а на интерфейс? Реквестирую разъяснение :)
    • +2
      Стандарты этого не запрещают, вернее, не требуют, чтобы шлюз был в той же сети.

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

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

      И попробуйте — и Windows, и Linux дают назначить такие шлюзы. Windows, правда, ругнётся.
      • 0
        Линукс не даст. Например, 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 — но это будет работать именно потому, что мы сначала добавили первый из этих маршрутов. Я не удивлюсь, если винда именно так и делает «под капотом». Проверьте таблицу маршрутизации.

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

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

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

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

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

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

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

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

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

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

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

                    Винда действительно втихую добавляет сначала маршрут до шлюза, а уже потом маршрут по умолчанию через шлюз, поэтому в ней работает. Линукс ничего втихую не делает, но если в нём вручную сделать так же, тоже будет работать.
                    Попробуйте на виртуалках, посмотрите на таблицы маршрутизации, убедитесь ;) Только смотреть на все — в линуксе их как минимум три (не забудьте ip route show table local)
                    • 0
                      На point-to-point линках маршрут (в том числе и дефолт, т.е. шлюз) может указывать на интерфейс, на котором вообще может не быть ip адреса (ip unnumbered). А если такой маршрут прописать на ethernet, будет посылаться arp для каждого dst-ip.
                      Но, сталкиваясь с сетевой подсистемой в виндах, я ничему не удивлюсь.

                      Кстати, ещё вопрос из той же серии:
                      На point-to-point линках обычно ставят /30 сеть, таким образом, теряются 2 адреса (адрес сети и бродкаст). Что будет, если использовать /31? Сеть ethernet, т.е. бродкаст.
                      • 0
                        Про p2p вы совершенно правы. Но у нас сеть /24, как бы, это не похоже на p2p.

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

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

                        Вот ещё пример: habrahabr.ru/post/189268/#comment_6572820
                        • 0
                          Я имел в виду point-to-point L2 сеть, то есть, например, ppp, или какой-то тоннель. Ethernet — всегда бродкаст, даже если там всего 2 хоста. И с маршрутами через интерфейс в этом случае надо быть очень осторожным.
                          • 0
                            А кто вам запрещает ethernet использовать для двух хостов?

                            Пример: два компа соединили шнурком.
                            • 0
                              Прочитайте по ссылке.
                              Ничего не запрещает, это используется повсеместно. Но делать ip route 0.0.0.0 0.0.0.0 gi1/1 не стоит.
                • 0
                  только не «link-local», а «connected» по-моему
                  • 0
                    Это вот терминология различается в разных системах. В циске «connected», да. Возможно я не на месте сказал, уже не помню, почему именно такой термин применил.
                    • 0
                      link-local называются адреса диапазона 169.254.0.0/16 (о чём тут уже писали) и мультикаст 224.0.0.0/24, т.е., не маршрутизируемые за пределы локальной сети.
                      • 0
                        Да я знаю, вероятно, я как-то по-другому формулировал мысль, а это осталось оттуда.
          • +2
            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

            Нельзя, как видим.
      • +3
        А если у меня 10 сетевых карт? Он из каждой ARP-запрос в поисках шлюза сделает?
    • 0
      Согласен, по идее хост обнаружив что адрес находится в другой сети, должен переслать пакет шлюзу, и ARP запрос делается к шлюзу, а не к адресу из другой сети
      • 0
        Приглядитесь к адресации на схеме. Они друг у друга шлюзами назначены.
        • 0
          был невнимателен. тогда, действительно могут пинговаться, хотя забавно получается.
        • +4
          Как компьютер ПК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.

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

                • 0
                  ну что тут сказать. /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
                  • +4
                    это уже расширяет scope изначального вопроса ;)
            • 0
              arp -a еще до кучи
              • 0
                в arp-е mac-адреса друг-друга видно.
            • –1
              пришлось превозмочь лень и сделать две виртуалки на win7, тема работает
              • +1
                а у меня — нет. где правда?
              • 0
                а маршруты-то у вас есть? Мне теперь тоже интересно, не делать же виртуалки, а то вдруг не заработает
                • –1
                  маршрутов нет, да они и не нужны, логика следующая: система(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), который по совместительству является получателем пакета…
                  • 0
                    вы всё-таки покажите таблицы маршрутизации-то
                    • 0
                      Список интерфейсов
                       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
                      ===========================================================================
                      Постоянные маршруты:
                        Отсутствует
                      

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

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

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

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

                  default dev ppp1 scope link metric 2000


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

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

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

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

                    В случае двух хостов можно и не указывать dg. Но звучит эта фраза не про сегмент из двух компов.
                    • 0
                      Хабов не существует, это — миф, и полудуплекса тоже нет :)
                      • 0
                        Но на топологии шины он по-прежнему умеет работать.
                • 0
                  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 сегментов нормально обрабатывается и виндой и никсом.
    • 0
      Ну в защиту автора — речь шла об абстрактных компьютерах, а не каких-то определённых системах. Если написать свой сетевой стек — смогут и вроде бы не нарушат никаких стандартов (тут не уверен). Признаюсь, однажды я так и сделал — работало.
      • 0
        Хотя, почитав комментарии, склонен согласиться — любая альтерантивная реализация будет просто скрывать факт существования дополнительного маршрута до сетевого интерфейса. Это существенный момент.
    • 0
      Можно поиграть с маской, и получить шлюз _кажущийся_ из другой подсети.
  • 0
    Задавать эти вопросы сисадминам на собеседовании?

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

                    Собственно, до сих пор я и не знаю, почему работало, однако объяснение из статьи вполне меня удовлетворяет ;)
                    • 0
                      Ну, вообще я с уверенностью не могу сказать чем маска подсети отличается от обратной маски (кроме инверсии). Из того, что точно знаю — маска подсети никогда не может иметь разрывов, а 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 было ориентированно как раз на написание такой маски.
                      • +2
                        я с уверенностью не могу сказать чем маска подсети отличается от обратной маски

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

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

                          Это гениально :) я знал про WC маски, но такое использование как-то не приходило в голову. Спасибо!
                        • 0
                          Маска сети определяет сеть. Инверсная маска определяет хост

                          Вот две команды.
                          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

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

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

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

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

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

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

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

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

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

    image

    В14 — на спутниковых линках это заметно совсем хорошо, если вдруг попадается нод с наземным аплинком delay падает на сотни мс.
    • 0
      Как такое возможно? Я про адреса 169.254 в конце.
      • 0
        Скажу по секрету — я тоже иногда использую link local адресацию под point-to-point линки. Почему бы и нет? Роутиться эти префиксы не должны даже внутри компании.
      • 0
        Да легко. Это пакет с адресом назначения или источника 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-запросов при получении физического адреса следующей системы, не более того. Они в этом отношении ничем не хуже любых других.
        • 0
          Как видите, link-local адреса используются исключительно для ARP-запросов при получении физического адреса следующей системы, не более того.

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

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

              Я высказал наиболее вероятную версию :)
              • 0
                APIPA в данном случаем стоит на двух концах GRE-тоннеля. Есть у нас в Израиле один провайдер, который очень любит их использовать именно для этого.
                • +1
                  Маленький педант внутри меня поправляет: APIPA — технология самоназначения адреса, а не блок адресов. Ни разу не слышал о поддержке APIPA на сетевом железе.
                  • 0
                    Как преподаватель очень хорошо вас понимаю :)
  • +2
    Кстати, по поводу В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
    • +1
      Больше того, если у вас в сети работает radvd, на компах и будет в маршруте по умолчанию указан link-local адрес шлюза. Т.е. каждый может легко столнкнуться с машрутизацией белых адресов через link-local-адреса.
    • 0
      Не совсем понял пример с тем, как можно избежать бриджа.

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

      Собственно, почему и возникает необходимось в линухах делать proxy_ndp.
      • +1
        Хм, у меня proxy_ndp не включен ни на одном интерфейсе.
        Получается так, что для связи между маршрутизатором и клиентом используются link-local адреса, и, в то же время, и у клиента, и у роутера настроены обычные ipv6 global адреса. Клиент отправляет пакет с source-адресом из global через роутер, который доступен по link-local, ну и ответ ему так же приходит.
        • +1
          Интересно. Давайте копнем детальнее. Конкретный пример – это 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.

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

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

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

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

      Спрошу иначе — почему разводка такая «кривобокая», а не симметричная? Можно ведь использовать по два крайних контакта в 8p8с. 1 и 2 для одной пары, 7 и 8 для другой.
  • +1
    В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.
  • +3
    Автор, оформите ответы тегом «спойлер» после каждого вопроса, это удобно.
  • +1
    Для чего нужен адрес сети? Почему его нельзя назначить хосту?

    Для того чтобы быстро определить принадлежность IP данной сети: ipaddr & netmask == netaddr
    Чем проще метод определения принадлежности — тем проще (и быстрее) маршрутизация
    • 0
      В общем-то это не даёт ответ на вопрос, почему нельзя использовать адрес .0 для хоста. То есть понятно, что нам это непривычно, но теоретических препятствий этому не вижу. Впрочем возможный ответ уже дали, я его добавил в топик.
      • 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, т.е. возможность «резать» адресное пространство в практически произвольных пропорциях — появилась необходимость в маске и правильном броадкасте. Поэтому уже сделать маску сети с единицами, а броадкаст нулями не выйдет из-за того что броадкаст будет одинаковым для нескольких сетей.

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

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

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

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

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

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

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

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

        Такую маску можно использовать на ethernet линке, при этом будет работать всё, кроме directed broadcast'a (т.к. нет бродкаст адреса). Limited broadcast (255.255.255.255) работает, и конечно же, работает мультикаст и ethernet broadcast (ff:ff:ff:ff:ff:ff ) — ему вообще нет дела до IP. Работают все протоколы маршрутизации, даже RIPv1 (он шлёт пакеты на 255.255.255.255).
        DHCP relay по дефолту работает через unicast, но может быть настроен на directed broadcast. Разумеется, слать directed broadcast пакеты на сеть /31 нельзя (и нет смысла), а вот через неё такие пакеты проходят.

        Вообщем, я так и не нашёл причин, по которым /31 не стоит использовать на p2p линках. Но, по исторической традиции, все продолжают использовать /30.

        http://tools.ietf.org/html/rfc3021
        http://blog.ipexpert.com/2012/04/05/understanding-dhcp-relays/
        • 0
          Мы используем /31, всё пучком.
        • 0
          Больше того, один провайдер в Воронеже (СуммаТелеком), когда мы попросили белый адрес, заставил оплачивать сеть из четырёх адресов — и сделал её /30. Такого безобразия я вообще нигде больше не видел.
  • +1
    > Ethernet совмещает в себе функции канального и физического уровня модели OSI

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

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