Вопрос: Для чего нужны адреса 169.254.0.0/16 (автонастройка ARIPA в Windows и nonzeroconf в unix)?
Ответ:
Сеть 169.254.0.0/16 была изначально задумана как сеть Link-Local.
Суть её заключается в том, что, если хост не имеет статического IP-адреса и не может получить его автоматически, например, от DHCP-сервера, то он сам себе назначает адрес из диапазона 169.254.0.1-169.254.255.254. После этого он сможет общаться с другими хостами в этой сети, имеющими такие же адреса.
Адрес выбирается случайным образом благодаря генератору случайных чисел так, чтобы он не совпал с уже существующим адресом (проверяется ARP-запросом).
Примером применения может быть какая-нибудь Ad-Hoc сеть, где у станций задача — общаться между собой.
Но ключевая особенность такой сети в том, что взаимоотношения возможны только между станциями, находящимися в этом сегменте, отсюда и фраза Link-local в определении. Пакеты не могут передаваться дальше маршрутизатора. Более того, даже если у хостов будет указан адрес шлюза, по стандарту он не должен на него передавать пакеты ни при каких условиях.
Этим и объясняется то, что пинг, как на рисунке не работает. Всё согласно RFC.
Вопрос:
А знаете ли сколько всего адресов пропадает, кроме известных всем приватных и 127/8?
Ответ:
На самом деле мы теряем:
Одну сеть класса А: 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 адресов.
Вот такие мы расточительные.
Вопрос:
Почему во время трассировка могут возникать ситуации когда промежуточный хоп с высокой задержкой, а конечный нет?
[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 Ответ:
Если такая задержка единичная, то, скорее всего, это вопрос буфферизации/приоритезации. Например, временная перегрузка на линии.
Пользователь 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 обратно он идёт тем же путём и задержка нормализуется.