ICNDv3 #8 — Способы отправки и доставки информации.
Broadcast — Отправка информации от одного клиента всем получателям в той же или в другой сети. Отправка широковещательных запросов более глобального уровня не бывает (поскольку все служебные сообщения вида «остановить сеть, дайте спросить»), они возможны только в пределах одного сегмента сети. В IPv6 уже нет мультикаста, как такового, и нельзя рассылать сообщения на всю сеть (только определенным группам).
Direct Broadcast — Адресован конкретной сети (в нашем примере — это 10.3.0.0/24, а там Destination Address 10.3.0.255).
При условии, что Direct Broadcast разрешены (на интерфейсах свитча или роутера не стоит no ip directed-broadcast). И при отправке ping на 10.3.0.255, на этот запрос ответят поочередно все хосты из подсети 10.3.0.0/24.
- Limited Broadcast — Хост с адресом 10.0.1.2 посылает информацию всем получателям в этой же сети 10.0.1.0. Все 32 бита будут единицой. 11111111.11111111.11111111.11111111 = 255.255.255.255
Source Address = 10.0.1.2
Destination Address = 255.255.255.255 - Direct Broadcast — Хост с адресом 10.0.1.2 посылает информацию всем получателям, но в другой сети 10.3.0.0 (с маской /24).
Source Address = 10.0.1.2
Destination Address = 10.3.0.255
- Multicast — Отправка информации от одного клиента на группу получателей.
Пример: Есть сеть на 100 клиентов, 5 клиентов из этого сегмента смотрят видеотрансляцию. Есть несколько вариантов доставки информации до них:
1. Broadcast — Разослать на всю сеть информацию, из которой 95 клиентов дропнут эти пакеты, а примут только 5. Загадить всю сеть трафиком, чтобы маленькая группа получила данные — плохая идея
2. Unicast — Разослать каждому клиенту одну и ту же информацию, т.е. переслать 5 дублей трафика. А если это 5000 клиентов, то даже, при потоке видое в 1 мегабит, нужна будет пропускная способность 5 гигабит одинаковых данных. Тоже плохая идея.
3. Multicast — Это специальный подвид адресов, которые не индивидуальные, а являются признаком принадлежности к группе. Т.е. если вы хотите получать эти рассылки данных, то роутеру передается инфомация по протоколу IGMP (Internet Group Management Protocol), что «клиент хочет получать данную рассылку, он сидит за таким-то интерфейсом». И когда этот видеопоток будет отправляться, то адрес получателя будет техническим адресом этой группы.
Source Address = 10.0.1.2
Destination Address = 224.0.0.1
Simplex, Duplex, Half-Duplex.
Терминами Simplex и Duplex обозначаются направленности потоков данных.
Simplex — Если в канале возможна передача данных только в одну сторону.
Пример: Телевышка (умеет передавать изображение, но не умеет получать) и телеприемник (умеет показывать изображение, но не умеет отправлять).
Duplex — 2 разнонаправленных разделенных Simplex’a.
Half-Duplex — Когда количество абонентов достаточно большое, и из них единовременно может передавать только один. Отличный пример: классический Ethernet.
What is directed broadcast in IPv4 and how directed broadcast works
Directed broadcast is another type of IPv4 broadcast. In IPv4 directed broadcast, the IPv4 packet for broadcast is sent as unicast from one network and later that packet become broadcast in another network.
We have learned about limited broadcast in previous lesson. In limited broadcast, the router of the Local Area Network (LAN) does not forward the broadcasted packet to any of its other connected network segments. Thus, the broadcast is limited within the Local Area Network (LAN) or the broadcast domain. But in directed broadcast, the broadcast is sent from one network to another network as unicast IPv4 datagram packet. When the directed broadcast packet sent as unicast from one network reaches the destination network, it will be broadcasted at the destination network.
Before continuing further, I strongly suggest you to visit and learn following lessons.
To understand the concept of directed broadcast, refer below image.
Consider Computer-1 with IPv4 address 172.16.0.100 want to send a broadcast to 172.17.0.0 network. Limited broadcast will not work here, because Router-1 will not forward the limited broadcast to another network segment. Directed broadcast is used in similar situation. IPv4 directed broadcast datagram packets are sent over the network to its destination Local Area Network (LAN) in the same way as the unicast IPv4 packets, until IPv4 directed broadcast datagram packets reach the destination netwok. Destination network’s router then encapsulates the directed broadcast IPv4 packet inside Ethernet frames with destination MAC address as broadcast MAC address ff:ff:ff:ff:ff:ff and then forward to its Local Area Network (LAN).
Following images explain how directed broadcast works. Consider the situation where a computer with IPv4 address 172.16.0.100 wants to send an IPv4 directed broadcast to 172.17.0.0 network. Please note that 172.16.0.0 and 172.17.0.0 are different networks, separated by routers.
Computer prepares an IPv4 datagram packet with destination IPv4 address as the directed broadcast address of 172.17.0.0 network. The directed broadcast IPv4 address of 172.17.0.0 network is 172.17.255.255. Since the destination IPv4 address is not on Computer’s own network, the IPv4 directed broadcast packet will be encapsulated with Ethernet frame with the MAC address of the default gateway (router’s LAN interface). Please refer below image.
The switch will fordard the received Ethernet frame to the default gateway (router’s local interface), since the destination MAC address of the Ethernet frame is the MAC address of default gateway. Please refer below image.
The router "Router 1" (of network 172.16.0.0), will now forward the IPv4 directed broadcast datagram packet to "Router 2" (the router of 172.17.0.0 netork) as unicast. Please refer below image.
When the forwarded IPv4 directed broadcast datagram packets reaches the destination network, the router at the destination network ("Router 2") encapsulates the received IPv4 directed broadcast datagram packets with an Ethernet frame with broadcast MAC address ff:ff:ff:ff:ff:ff as Frame’s destination MAC address. "Router 2" then forwards the encapsulated IPv4 directed broadcast datagram packet to 172.17.0.0 network. Please refer below image.
When the switch at destination network (in this case 172.17.0.0 network) finds the destination MAC address as broadcast MAC address ff:ff:ff:ff:ff:ff, switch will flood (broadcast) the packet to all its connected ports. All the connected interfaces in the destination network will receive a copy of the broadcasted packet. Please refer below image.
When the directed broadcast Ethernet frame is received and processed at the datalink layer of the computers inside the destination network (172.17.0.0), the datalink layer identifies the destination MAC address as broadcast MAC address ff:ff:ff:ff:ff:ff. Since the destination MAC address is broadcast MAC ff:ff:ff:ff:ff:ff, all the computers in the Local Area Network (LAN) need to accept and process the broadcasted Ethernet frame. Why? What is the reason ? Because the broadcasted Ethernet frame may contain information relevant for every device in that Local Area Network (LAN) or broadcast domain .
Каверзные сетевые вопросы
Давно была идея собрать воедино интересные вопросы, касающиеся сетей.
Объединяет их то, что все они довольно простые, но мы подчас о них не задумываемся (я во всяком случае о них не задумывался).
В общем я их собрал, подбил, нашёл ответы.
Итак, блиц опрос:
Начнём с самых низких уровней и с самых простых вопросов
В1. Почему для витой пары выбран такой странный порядок: синяя пара на 4-5, разрывая зелёную, которая на 3, 6?
О1: Сделано это в угоду двухконтактному телефонному разъёму. Таким образом, например, в патч-панель можно вставить как телефонный кабель, так и витую пару.
Можно даже через один кабель вывести и сеть и телефонию, но я вам этого не говорил!
В2. В стандарте Ethernet между кадрами всегда имеется промежуток, называемый IFG (Inter Frame Gap) длиною 12 байтов. Для чего он нужен, и почему он присутствует в современных стандартах?
О2: IFG использовался активно во времена расцвета CSMA/CD. Это пауза, которую должно делать передающее устройство перед отправкой фрейма, чтобы избежать коллизий.
Дело в том, что в когда несколько хостов подключены в хаб, высока вероятность того, что они начнут отправлять данные в одно время, и возникнет коллизия или одна станция оккупирует монопольно канал.
При использовании IFG пока один хост ждёт, другой, может отправлять.
Вообще говоря, IFG измеряется в микросекундах. Его длительность для Fast Ethernet составляет 0,96 микросекунды.
Уже в гигабите CSMA/CD есть только условно, а в 10G его нет вовсе. Это потому, что домен коллизий современных коммутаторов ограничен одним интерфейсом/кабелем, плюс работают в полнодуплексном режиме.
Так для чего же мы до сих пор теряем драгоценные 12 байтов?
Просто никто не хочет менять стандарт.
В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.
В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 Мб/с? Почему так?
В6. Всем известно, что комитет 802 занимается стандартами по ЛВС. Также, общеизвестно, что Ethernet — это 802.3
С другой стороны сейчас общепринят стандарт Ethernet II.
В чём же отличие кадров Ethernet II от кадров 802.3 и почему он вообще II?
Немного повыше поднимаемся
В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 внёс поправки в этот вопрос:
Ещё выше
В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.
Т.е. у нас есть два компа и локальные маршруты «непосредственно» друг до друга, хоть оно и в разных подсетях. Конечно, будет пинговаться.
В9. В чём разница между Directed Broadcast (192.168.0.255) и Limited broadcast (255.255.255.255)
В10: Может ли адрес 10.0.1.0 быть использован для адреса хоста?
В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
Коротко:
На хардварных платформах отправка отклика 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
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.
Michelle Cotton
Manager, IANA Services
ICANN
В общем-то исчерпывающий ответ. Больше искать правду негде.
Неотвеченными остался только один интересный, но, возможно, надуманный вопрос. Как я его ни крутил, как ни гуглил, но его тайна пока не раскрыта.
Для чего нужен адрес сети? Почему его нельзя назначить хосту?
Логичный первый вариант — он определяет сеть. Ну а что, так уж нужен для этого отдельный адрес? 192.168.1.110/24 определяет сеть точно так же хорошо, как и 192.168.1.0/24. Да и это всё равно не мешает назначать этот адрес хосту.
Вторая идея — так прописываются маршруты на роутерах. Это же не более, чем условность, ведь по сути см. первый вариант.
Встречал я также описание того, что некоторые вендоры преобразуют пинг на адрес сети в широковещательный кадр, но какой в этом смысл?
Если вы мне скажете, что так просто решили формализовать сеть, то я, видимо, обречённо приму.
Симметричный вопрос:
Или для чего нужен широковещательный адрес? Можно было бы использовать для него адрес сети.
UPD На данный вопрос приблизительный ответ дал один из читателей:
Local Broadcast vs Directed Broadcast
Two types of Broadcast IP addresses exist: the Local Broadcast IP address and the Directed Broadcast IP address. In the current networking world, they mostly serve the same function. But one of them contains an additionally piece of functionality. In this article we’ll clearly illustrate both concepts, and show you their functionality.
We’re going to use this topology to talk through these concepts:
To start, we must define the term “Broadcast.” A Broadcast is any frame or packet that is meant to be delivered to everyone on the local network.
A broadcast is roughly the opposite of a Unicast message. Which would be a communication from one host to another single host. Unicast is sometimes referred to as one-to-one communication, whereas Broadcast could be considered one-to-all communication.
The definition of a Broadcast mentioned frame and packet — this is because there are Layer 2 and Layer 3 aspects to the term Broadcast.
Layer 2 Broadcasts
A Layer 2 Broadcast is any frame with a Destination MAC address of FFFF.FFFF.FFFF .
This is a MAC address specifically reserved for Broadcast Frames. It is also sometimes displayed as ff:ff:ff:ff:ff:ff or ff-ff-ff-ff-ff-ff — these are all identical ways of displaying the “all F’s” MAC address.
Any node on any network can simply create a L2 header with this destination MAC address in order to send a frame to everyone on the local network.
Switches know that if they see this destination MAC address they should automatically flood the frame out all interfaces (except the one it was received on).
Keep in mind, it is the sender of the frame that sets the Destination MAC address. Therefore, it is the sender of the frame that determines whether a particular frame will be delivered to everyone on the local network or to a single node on the network.
Layer 3 Broadcasts
Similar to a L2 broadcast, a Layer 3 broadcast is simply a special IP address set as the Destination IP address for a particular packet.
Unlike L2 broadcasts, however, there are two different options for what you use as the Destination IP address for a Layer 3 Broadcast.
Those two options are the Local Broadcast and the Directed Broadcast (which is also sometimes called the Targeted Broadcast).
Local Broadcast
The Local Broadcast IP address is 255.255.255.255 .
Whatever IP network a particular host is on, that host can always use this IP address to send a packet to every node on the Local Network.
In our topology, Host 1 could send a message to the IP address 255.255.255.255 to speak to everyone else on it’s own local network.
Notice this also includes the Router. Since the R1 has an IP address in the 10.1.1.0/24 network, it is a member of Host 1’s local network.
Host 1 sent a ping to 255.255.255.255 and received responses from itself ( 10.1.1.11 ), Host 3 ( 10.1.1.33 ), and Host 2 ( 10.1.1.22 ), and the Router ( 10.1.1.1 ).
This is what the packets looked like on the wire:
Notice the Destination IP address is 255.255.255.255 . Notice also the Destination MAC address is ff:ff:ff:ff:ff:ff . Which makes this packet both a L2 broadcast and a L3 broadcast.
In the packet capture window, we can see the responses from Host 3, Host 2, and the Router. But we don’t see the response form Host 1 — that packet was simply sent internally and never actually reached the wire.
Moreover, notice Wireshark correctly labeled that packet as a broadcast packet — again, anything sent to 255.255.255.255 is a Broadcast.
For the sake of comparison, here is a packet capture of a Unicast ping between Host 1 and Host 3:
Notice the L2 source and destination are the MAC addresses which belong to Host 1 ( ee:ee:ee:11:11:11 ) and Host 3 ( ee:ee:ee:33:33:33 ). And of course the L3 source and destination are the IP addresses which belong to Host 1 ( 10.1.1.11 ) and Host 3 ( 10.1.1.33 ).
Directed Broadcast
The Directed Broadcast IP address is what is known as the Broadcast IP for each Subnet. To find this IP address, you will have to do a little subnetting.
Much like the Local Broadcast described above, the Directed Broadcast IP can be used by any host to speak to every host on it’s own local network.
Host 1 has the IP address 10.1.1.11 on the 10.1.1.0/24 network. The Broadcast IP address of this IP subnet is therefore 10.1.1.255 .
Host 1 can use this IP address to send a message to everyone else on it’s own local network — just like it did with the Local Broadcast above:
Host 1 sent a ping to 10.1.1.255 and received responses from itself ( 10.1.1.11 ), Host 3 ( 10.1.1.33 ), Host 2 ( 10.1.1.22 ), and the Router ( 10.1.1.1 ).
This is what the packets looked like on the wire:
Notice the destination IP address is 10.1.1.255 , and the Destination MAC address is ff:ff:ff:ff:ff:ff .
Wireshark’s analysis of these packets reveal two interesting details:
First, you and I both know that 10.1.1.255 is the Broadcast IP for the 10.1.1.0/24 network. But Wireshark failed to mark it as such as it did for the Local Broadcast in the prior example.
The reason is that Wireshark doesn’t know that this capture is from a network with a /24 mask. Therefore, Wireshark cannot infer that 10.1.1.255 is a Broadcast IP. If the mask were /22 , the Broadcast IP would be 10.1.3.255 , and the IP 10.1.1.255 would be a perfectly valid host address.
Second, notice the yellow background on the ICMP header. This is Wireshark indicating the “expert info” issued a warning because no response was found for the ICMP echo request.
Wireshark saw an echo request sent to 10.1.1.255 , and was therefore looking for a response from 10.1.1.255 . Which you and I both know is not an actual host that could have responded.
At this point we’ve proven that a host can use either the Local Boadcast IP or the Directed Broadcast IP to speak to every node on it’s local network.
Which begs the question. If both of these types of broadcast perform the same function, why do we have two different types of L3 broadcasts?
The answer: The Directed Broadcast can do something that the Local Broadcast cannot. The Directed Broadcast can be used to speak to every node on a foreign network.
Directed Broadcast to a Foreign Network
Every IP network has its own Broadcast IP. Therefore, Hosts can use the broadcast IP address of a foreign network to direct a broadcast to every node in that foreign network. Hence, the term directed broadcast (or sometimes targeted broadcast).
In our topology, Host 1 can use the IP address 10.3.3.127 to speak to every host in the 10.3.3.0/25 network:
For comparison purposes, I want to first show you a Unicast ping from Host 1 to Host 6.
On the wire, this is what was captured between Hub1 and R1:
The Source IP is 10.1.1.11 (Host 1) and the Destination IP is 10.3.3.66 (Host 6). This is the L3 header, and for the most part will remain unchanged throughout the entire trip.
The L2 header as it leaves Host 1 has the Source MAC address of ee:ee:ee:11:11:11 (Host 1) and a Destination MAC address of ee:ee:10:11:11:11 (R1). This L2 header will be discarded and regenerated every hop along the path.
This same packet captured between R3 and SW2 looks like this:
Notice the L3 header is unchanged. But the L2 header now includes a Source MAC of ee:ee:10:33:33:33 (R3) and a Destination MAC of ee:ee:ee:66:66:66 (Host 6).
Now let’s test the Directed Broadcast to a foreign network. We’ll have Host 1 ping the IP address 10.3.3.127 . Remember there are four nodes on the 10.3.3.0/25 network and we should expect a response from each of them.
As expected, we received four responses to our ping: Router 3 ( 10.2.3.3 ), Host 6 ( 10.3.3.66 ), Host 5 ( 10.3.3.55 ), and Host 4 ( 10.3.3.44 ).
Oddly, R3 responded from the IP address 10.2.3.3 — R3’s IP address on the link between R2 and R3. I would have expected this response to come from the IP address 10.3.3.3 . I am unsure if it’s a bug or intended behavior or merely Cisco’s implementation of responding to Directed Broadcasts. Either way, this response is indeed from R3.
The packets on the wire reveal some interesting details. Here is the capture on the link between Hub1 and R1:
The most significant fact to point out is this packet is a unicast packet. Notice the L2 and L3 headers are constructed identical to the unicast ping between Host1 and Host6 (except the destination IP address, of course).
This highlights an important fact: Host 1 does not know it is speaking to a directed broadcast IP address. You and I know, because we can see the topology map; but from Host 1’s perspective, 10.3.3.127 is merely an IP address on a foreign network. Host 1 is simply following all the regular rules for speaking to an IP on a foreign network.
In fact, the packet travels from Host1 to R1, and from R1 to R2, and from R2 to R3 as a regular unicast packet. The only Router that knows that the IP address 10.3.3.127 is the broadcast IP for the destination subnet is R3. And the capture on the other side of R3 reveals what R3 does with the unicast packet it received:
Notice the destination MAC address is ff:ff:ff:ff:ff:ff , and the Destination IP address is 255.255.255.255 . This is now a L2 and L3 Broadcast.
R3, knowing that this packet was sent to a Directed Broadcast IP address, translated the unicast packet it received into a broadcast packet. This is how the single Unicast packet sent by Host 1 was delivered to everyone on the 10.3.3.0/25 network.
Security
While the functionality of sending a packet to every host on a foreign network seems pretty neat. In practice, this is generally regarded as a security risk.
Directed broadcasts were invented at the dawn of computer networking, when the Internet was a much friendlier place. Back then it was simple enough to simply trust the other users on the Internet not to abuse the Directed broadcast.
However, as the Internet grew, that inherit trust of the other users went away. Currently nearly every modern operating system and router software ignore directed broadcasts.
In order to build the lab we used in this article, I had to explicitly enable responding to and processing Directed Broadcasts on the Router and the Linux hosts.
On a Cisco Router, that involved this command:
On a Linux host, that involved changing the value of this file from 1 to 0 :
I say all this because inevitably after reading this article some of you will try to ping a foreign network’s broadcast IP, and it will likely fail.
Which makes sense if you put yourself in the Network Administrator’s shoes. You wouldn’t want some random user on the Internet to be able to send a ping to every host on your network.
Summary
In this article we discussed the ideas of a Layer 2 Broadcast and a Layer 3 broadcast. We further unpacked the L3 broadcast as we dove into the concepts of the Local Broadcast and the Directed Broadcast (also called the Targeted Broadcast). To summarize those definitions:
- Local Broadcast IP – 255.255.255.255
- Can be used to speak to everyone on the Local network
- Can be used to speak to everyone on the Local network
- Can be used to speak to everyone on a Foreign network
Throughout this article we showed you screen shots from the packet captures from testing the Local Broadcast and the Directed Broadcast. If you’d like to download the capture files and study them yourself, you can do so here:
Moreover, if you prefer learning this content via videos, I present two Youtube video options for you:
This video is a quicker run through of just the concepts and tests from this article. In this video we’ll define Local and Directed broadcasts, then do some ping tests to prove they work as described.
This video covers the same concepts but is a bit more thorough and digs into the packet captures. We’ll define Local and Directed broadcasts, then run some ping tests to prove their operation. But we’ll also look at the Packets on the wire and talk through what is going (much like we did in this article).