И так сойдёт
Но клей надо купить
Но клей надо купить
Подключил тариф 500мбит/с, но роутер выдает только около 250.
Поддержка утверждает что это из-за роутера
Роутер старенький но всё же.
Подскажите пожалуйста покупать новый роутер или иметь мозг поддержке ?
Все таки проблема похоже в роутере. Провод до роутера выдает 480, а после роутера уже 260 так же как и WiFi
Есть планшет lenovo xiaoxin 12.7 pro на нем периодически сваливается wifi на 2.4ггц и так и остаётся. Если зайти в список сетей сначала показывает 2.4 и потом сразу 5 и так и остаётся на какое то время, если в список сетей не заходить так и будет 2.4 и скорость не полная. Роутер keenetic ultra 1810 прошивка последняя, настроен стандартно.
Господа, дамы, здравствуйте!
Мы разобрались с видами устройств в IP, теперь нужно научиться как-то отличать один узел сети от другого, а для этого надо разобраться с IP-адресами, какими они обладают свойствами, как их записывать и другими вопросами. Вопросов много, разбираться будем по порядку.
Тему IP-адресов я разбил на три логические части: сперва идет немного теории, потом мы разбираемся с формами записи IP-адресов, пингуя всё на свете, кроме шила и гвоздя, а в третьей части мы соберем небольшую лабу в EVE-NG, чтобы разобраться как настраиваются основные и вторичные IP-адреса на интерфейсах роутеров.
Я не нашел как на Пикабу создать оглавление для поста в его начале(если кто-то что-то подскажет по этому поводу буду благодарен), а все три части вместе получились довольно объемными, поэтому тема будет разбита на два поста, ниже теория + пинги, отдельным постом поделаем настройки.
Давайте сперва поймем какие задачи решает IP-адрес, для себя я выделяю их две. Первая заключается в том, чтобы нумеровать узлы компьютерной сети(на самом деле не только узлы, но и сети, к которым узел относится), то есть IP-адрес выступает уникальным идентификатором узла в сети, вернее даже не узла, а его интерфейса. Вторая немаловажная задача IP-адресации заключается в том, что с помощью адресов мы можем построить маршрут из одной точки сети в другую, но об этом мы поговорим, когда речь пойдет о маршрутизации.
Идентифицировать устройства в небольших сетях проще было бы по названию, например, у вас дома есть компьютер, ноутбук, несколько мобильных телефонов, планшет и умный чайник, в такой ситуации проще дать имя каждому узлу и обращаться к нему по имени, а вот рассказать это имя всем остальным узлам в мире выглядит проблемой, да и гарантировать, что это имя не пересечется с другим тоже сложно. Поэтому узлы для сетевого взаимодействия мы нумеруем при помощи IP-адресов, да еще и не просто так, а по определенным правилам.
IP-адрес обладает большим количеством свойств, выделю пять основных (на мой взгляд):
Размер IP-адреса 32 бита или 4 байта, если хотите можно говорить октета. Это означает, что у нас примерно имеется 4 млрд адресов, более точно можете узнать, если возведете два в тридцать вторую степень (у нас для хранения IP-адреса выделено 32 бита, каждый бит может принимать значение либо ноль, либо единица).
IP-адрес назначается на канальный интерфейс устройства.
IP-адрес для нормальной работы сети должен быть уникальным в пределах всей сети, если на устройстве А и Б будут одинаковые адреса, то для одной части узлов сети будет доступно устройство А, а для другой части сети устройство Б, этим можно пользоваться для реализации anycast взаимодействия, так как штатно в IPv4 этот вид взаимодействия не реализован.
IP-адрес состоит из двух частей:
первая часть адреса является идентификатором канальной среды или номером сети (Network ID), номер сети будет одинаковым для всех узлов внутри одной канальной среды и разным у узлов из разных канальных сред;
вторая часть IP-адреса – это номер узла или идентификатор хоста (Host ID), номер узла должен быть разным для всех узлов внутри одной сети, но может повторяться, если узлы находятся в разных канальных средах.
На текущий момент границу между номером сети и номером узла проводит маска подсети. Если вы не знаете маску подсети, то не сможете сказать: где у IP-адреса номер хоста, а где номер сети.
IP-адрес на устройство назначается не его производителем, а человеком, который это устройство использует, скорее всего, сетевым администратором. При этом способ назначения не важен: адреса можно выдавать динамически при помощи DHCP, или же статически: своими собственными руками назначать каждому интерфейсу.
IP-адрес нумерует сразу две сущности: сам узел и сеть, в которой этот узел находится. Таким образом получается, что узлы, находящиеся в одной подсети, имеют одинаковый номер сети, но у них разные номера хостов. Если два или более узла находятся в одной подсети, то не будет ошибкой говорить, что они находятся в одной канальной среде.
Если два узла находятся в разных подсетях, то их номера узлов могут повторяться, а их номера сети будут разными. Узлы, находящиеся в одной канальной среде, могут обратиться к узлам другой подсети через маршрутизатор, основная задача роутера как раз и заключается в том, чтобы перекладывать кадры из одной канальной среды в другую.
Все вышесказанное продемонстрировано на этой картинке.
На ней изображено три сети: зеленая, оранжевая и синяя, номера сетей я указал римскими цифрами, номера узлов подписаны арабскими. Все три сети соединены одним роутером, для того чтобы этот роутер мог связать узлы этих трех сетей друг с другом, его интерфейсы должны находиться во всех трех сетях, то есть если мы хотим, чтобы зеленый узел мог пинговать оранжевый узел, то хотя бы один интерфейс роутера должен быть в зеленой сети и хотя бы один интерфейс роутера должен быть в оранжевой сети.
Операционные системы, а вернее прошивки некоторых простых устройств позволяют задать только один адрес, в некоторых случаях несколько IP-адресов, но спецификация IP нас не ограничивает в количестве адресов, которые можно присвоить одному узлу.
Если вспомним самое начало, то там речь была о том, что IP-адрес назначается на канальный интерфейс узла и тут можно подумать, что если у узла три канальных интерфейса, то ему можно назначить три адреса из разных подсетей, но это не так.
Если у узла три канальных интерфейса, то ему на каждый канальный интерфейс можно назначить один основной IP-адрес и сколько угодно вторичных. Важно чтобы на разных канальных интерфейсах были адреса из разных подсетей, при этом основной и вторичные IP-адреса на одном интерфейсе могут быть из одной подсети.
Разбираться будем с формами записи в десятичной системе счисления. Если вы выходите в интернет, то, наверное, видели IP-адреса, например, 192.168.0.1. Читатель может заметить и спросить, ну и чего тут рассказывать, вон на экране написано 192.168.0.1, это и есть форма записи IP-адреса, которая всем понятна и удобна. Я бы мог в свою очередь сказать, что это стандартная форма записи, но, насколько мне известно, в спецификации IP стандартная форма записи никак не описана.
В общем так, если вам достаточно что IP-адрес, это число размером 32 бита и записывается он как четыре числа по восемь бит разделенных точками, то дальше можно и не читать если этого недостаточно, то давайте начнем по порядку.
Для начала запишем форму записи для 192.168.0.1 в общем виде:
8bit.8bit.8bit.8bit
А теперь давайте запишем в этом виде самый маленький и самый большой адреса:
0.0.0.0
255.255.255.255
Переведем их в двоичный вид:
00000000|00000000|00000000|00000000
11111111|11111111|11111111|11111111
В двоичном виде вместо точки я использовал пайп. Самый маленький адрес в двоичном виде представляет собой тридцать два нуля, самый большой тридцать две единицы, комбинции нулей и единиц между двумя представленными выше крайностями это все остальные IP-адреса. Фактически IP-адрес это число 32 бита, оно же может быть и десятичным. Вопрос в том, как нам записать адрес в десятичном виде одним числом и можно ли это вообще делать?
Для примера давайте пропингуем Яндекс:
PS C:\> ping ya.ru
Обмен пакетами с ya.ru [5.255.255.242] с 32 байтами данных:
Ответ от 5.255.255.242: число байт=32 время=46мс TTL=54
Ответ от 5.255.255.242: число байт=32 время=46мс TTL=54
Ответ от 5.255.255.242: число байт=32 время=47мс TTL=54
Ответ от 5.255.255.242: число байт=32 время=46мс TTL=54
Статистика Ping для 5.255.255.242:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 46мсек, Максимальное = 47 мсек, Среднее = 46 мсек
PS C:\>
Яндекс доступен по адресу: 5.255.255.242. Давайте переведем адрес в двоичный вид, каждый октет по отдельности:
00000101|11111111|11111111|11110010
Про переводы чисел из одной системы счисления в другую я рассказывать не планирую, если не умеете переводить, пользуйтесь калькулятором в режиме "Программист", в десятичном режиме пишите свое число, в соответствующей строке видите его двоичное представление.
Перевод чисел из десятичной системы счисления в двоичную
Хотел бы обратить внимание на число 5. Калькулятор представляет его как четыре бита: 0101, а под одно число IP-адреса у нас выделено восемь бит. В таком случае мы должны вместо недостающих старших бит написать нули (чем старше бит, тем левее он стоит, аналогично и для байтов), так как они в данном случае ничего не значат и само восьми битное число никак не изменится (чего не скажешь о числе размером 32 бита, если октет будет в середине, а не как у нас крайним слева).
Но вернемся к IP-адресу. Чтобы представить его в виде обычного числа, нам нужно из двоичной формы убрать разделители:
00000101111111111111111111110010
Роутер или компьютер работают с адресами без разделителей для них это просто биты. Затем получившуюся битовую последовательность переводим в десятичную систему счисления.
Переводим число из двоичной системы в десятичную
Получилось число 100 663 282. Давайте его пропингуем.
Пингуем десятичное число, получаем IP-адрес
Видим, что винда привела этот номер в привычный нам вид, всё успешно пропинговалось. Здесь может возникнуть справедливый вопрос: почему это мы вместо того чтобы использовать простые и понятные числа, переводим их в двоичный вид, разрезаем одно большое число на четыре куска по восемь бит, потом преобразуем эти восьмибитные двоичные числа обратно в десятичные и только потом записываем IP-адреса? Если коротко, то в таком виде удобнее разрезать сети на подсети или же наоборот (человекам, а не комплюхтерам): объединять маленькие сеточки в одну большую, если более детально, то будет отдельная тема о масках подсети.
Я знаю еще две формы записи, которые, как я слышал, пришли из систем BSD. В общем виде их можно записать так:
8bit.8bit.16bit
8bit.24bit
Я ни разу не видел, чтобы их кто-то использовал в каких-то рабочих целях, но вдруг вы столкнетесь. Винда понимает эти формы, вот для примера пинг 8.8.8.8.
PS C:\Windows\system32> ping 8.8.2056
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=54ms TTL=112
Reply from 8.8.8.8: bytes=32 time=54ms TTL=112
Reply from 8.8.8.8: bytes=32 time=54ms TTL=112
Reply from 8.8.8.8: bytes=32 time=54ms TTL=112
Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 54ms, Maximum = 54ms, Average = 54ms
PS C:\Windows\system32> ping 8.526344
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=54ms TTL=112
Reply from 8.8.8.8: bytes=32 time=54ms TTL=112
Reply from 8.8.8.8: bytes=32 time=54ms TTL=112
Reply from 8.8.8.8: bytes=32 time=54ms TTL=112
Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 54ms, Maximum = 54ms, Average = 54ms
PS C:\Windows\system32>
Итого у нас имеется четыре формы записи IP-адреса:
8bit.8bit.8bit.8bit
8bit.8bit.16bit
8bit.24bit
32bit
Переводить из одной формы записи в другую удобнее всего в двоичном виде, в двоичном виде вы просто отсчитываете нужное количество бит и ставите точку, получившуюся последовательность переводите в десятичную систему.
Если байты IP-адреса нулевые и не крайние, то некоторые операционные системы разрешают их не указывать, пользоваться этой фичей не рекомендую, особенно, если вы настраиваете адрес на оборудование, а не пингуете его, ниже примеры пинга адреса 1.0.0.1.
C:\Users\user>ping 1.0.0.1
Pinging 1.0.0.1 with 32 bytes of data:
Reply from 1.0.0.1: bytes=32 time=39ms TTL=59
Reply from 1.0.0.1: bytes=32 time=46ms TTL=59
Reply from 1.0.0.1: bytes=32 time=40ms TTL=59
Reply from 1.0.0.1: bytes=32 time=39ms TTL=59
Ping statistics for 1.0.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 39ms, Maximum = 46ms, Average = 41ms
C:\Users\user>ping 1.0.1
Pinging 1.0.0.1 with 32 bytes of data:
Reply from 1.0.0.1: bytes=32 time=39ms TTL=59
Reply from 1.0.0.1: bytes=32 time=39ms TTL=59
Reply from 1.0.0.1: bytes=32 time=40ms TTL=59
Reply from 1.0.0.1: bytes=32 time=40ms TTL=59
Ping statistics for 1.0.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 39ms, Maximum = 40ms, Average = 39ms
C:\Users\user>ping 1.1
Pinging 1.0.0.1 with 32 bytes of data:
Reply from 1.0.0.1: bytes=32 time=39ms TTL=59
Request timed out.
Reply from 1.0.0.1: bytes=32 time=47ms TTL=59
Reply from 1.0.0.1: bytes=32 time=39ms TTL=59
Ping statistics for 1.0.0.1:
Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
Minimum = 39ms, Maximum = 47ms, Average = 41ms
А на этом всё, здесь появится ссылка на вторую часть после ее публикации.
Оставлю комментарий для ответов, если захотите отвечать на вопросы, то лучше делать под этим комментарием, чтобы не спойлерить другим.
Какое число больше 8.234.255.12 или 9.0.0.0?
Зачем IP-адресу точки?
Почему если средние октеты адреса нулевые их допускается не печатать, а крайние октеты мы печатать должны?
Какой байт пропущен для адреса 1.1.1 (слева от центральной единицы или справа)?
У нас есть локальная сеть(не интернет), в сети есть узлы, кто этим узлам выдает IP-адреса?
Нужен ли роутер для взаимодействия между узлами одной подсети?
Схема: к Wi-Fi роутеру подключено два ноутбука по Wi-Fi, все три устройства в одной подсети, пингуем с первого ноутбука второй. Вопрос: как физически будут передаваться данные, напрямую между двумя ноутбуками или через роутер и почему?
Видео версия
Тем, кому лучше смотреть, чем читать.
Теоретическая теория здесь
Про формы записи адресов и пинги тут:
Всем привет!
Современные роутеры, продающиеся в сетях (Asus/D-Link/Tp-Link/Keenetic (они же ЗУХЕЛЬ)) не предполагают слежения за трафиком. Максимум можно ограничить трафик по разным критериям. Так же есть различные Microtik/Tenda, которые имеют более широкие возможности.
А есть ли роутеры с записью посещенных сайтов? Или есть ли устойчиво работающие сервисы, которые можно было бы прикрутить к роутеру таким образом, что бы знать, какие были запросы с конкретного устройства из подключенных к сети?
Господа, дамы, здравствуйте!
Продолжение поста о видах устройств в IP, если вы не смотрели первую часть, то рекомендую сперва перейти туда, а затем уже читать здесь. Вопросы, замечания, дополнения и уточнения только приветствуются.
В этой части мы посмотрим на то, как отправители и получатели будут взаимодействовать друг с другом в том случае, когда между ними стоят роутеры, т.е. в тех случаях, когда узлы находятся в разных канальных средах или другими словами в разных подсетях.
Далее мы будем работать с верхней частью схемы.
Пинг c PC0 к PC1 в режиме реального времени
Не будем рассматривать детально, что делают отправители и получатели, а также не будем рассматривать, что делают все транзитные узлы, кроме RO2, на нем и остановимся детально. Плюс, как видите, я изначально в режиме реального времени выполнил пинг, сделано это было, чтобы не смотреть на работу протокола ARP, который в данном случае должен отработать между каждым линком каждого устройства, представленного на схеме.
Сделаю небольшое пояснение, на рисунке выше показано, что я планирую пинговать с узла PC0 узел PC1, но по факту я пинговал адрес 10.2.2.1, который настроен на роутере RO3 на интерфейсе в сторону PC1, надеюсь, никто за это не осудит.
Понятно, что сперва отправитель PC0 должен будет сформировать IP-пакет в сторону получателя, здесь мы также сильно не мудрим и используем команду ping. Вся разница с первым случаем в том, что PC0 направит пакет не сразу к получателю (по факту это RO3), а в сторону транзитного узла RO1, т.е. PC0 должен будет изучить мак-адрес RO1 и выбрать тот интерфейс, который ведет к RO1, различия сетевого уровня у отправителя при отправке пакета сразу получателю и для случая, когда пакет посылается транзитному узлу представлены ниже.
Сетевой уровень узла отправителя для случая, когда получатель в другой подсети
Запускается процесс Ping.
Создается сообщение ICMP Echo Request и отправляется нижележащему процессу.
При пинге не была задан явно IP-адрес источника, поэтому узел выбрал наиболее оптимальный адрес с его точки зрения.
И вот здесь начинается разница. Узел видит, что адрес, который надо пинговать, находится в другой подсети, а это означает, что надо прибегнуть к помощи роутера.
Благо, что адрес роутера, который может помочь доставить пакет в пункт назначения, по мнение узла PC0, задан в качестве шлюза по умолчанию(defalut gateway или DG).
Маршрут по умолчанию, шлюз по умолчанию, DG. Пока по-простому... Это инструкция для узла: если у тебя нет точной информации куда направить пакет, направляй его узлу, который у тебя задан шлюзом по умолчанию.
Описание происходящего на канальном и физическом уровнях узла PC0 мы пропускаем, как и полностью пропускаем действия RO1. В итоге нам важно, что RO1 получил пакет от PC0 и передал его RO2.
На маршрутизаторе RO2 физические порта подключены так:
FastEthernet8/0 к RO1
FastEthernet7/0 к RO3
FastEthernet9/0 к коммутатору
На физическом уровне RO2 просто принимает битовую последовательность в порт Fa8/0 и формирует из нее кадр, который передается на L2.
Что делает RO2 на канальном уровне при приеме пакета
RO2 убеждается, что мак-адрес назначения в кадре принадлежит ему.
А это значит, что кадр можно вскрыть, посмотреть что внутри и как-то эти внутренности обработать.
После вскрытия на канальном уровне внутри обнаруживается IP-пакет и в дело вступает сетевой.
Что делает RO2 на сетевом уровне при приеме пакета
В CPT описание скромное, немного дополню: транзитный роутер не снимает IP-заголовок пакета, в данном случае он лишь смотрит на поле, в котором хранится IP-адрес назначения, запоминает адрес назначение и начинает проверять: а есть ли этот адрес в его таблице маршрутизации. В ходе этой проверки может возникнуть разные ситуации, например:
Этот адрес настроен на его интерфейсе, тогда заголовок будет снят для дальнейшего анализа.
Этот адрес будет принадлежать соседу, который подключен к одному из интерфейсов роутера, тогда роутер пошлет пакет непосредственно ему.
Этот адрес будет доступен через другой транзитный узел, тогда адрес будет послан непосредственно ему.
У роутера может не быть никакой информации о сети, в которой находится данный адрес, такой пакет будет уничтожен.
Подумайте: какой из пунктов описывает данную ситуацию?
В итоге RO2 понял, что IP-адрес ему не принадлежит и нужно понять, куда отправлять пакет, для этого он смотрит в таблицу маршрутизации. Нам сейчас не важно как роутер это делает, важно только то, что из таблицы маршрутизации роутер может достать информации об интерфейсе, в который надо направить пакет, либо IP-адрес соседа по канальной среде, в сторону которого пакет нужно направить.
Что делает RO2 на сетевом уровне при отправке пакета следующему узлу
Здесь нам поясняется:
RO2 нашел по таблице маршрутизации какой маршрут соответствует IP-адресу назначения, а также был установлен IP-адрес соседа, в сторону которого следует направить пакет.
И изменил значения поля TTL (TTL это число, которое задает узел отправитель, RO2 отнял от него единицу).
Пакет был передан канальному уровню.
Что делает RO2 на канальном уровне при отправке пакета следующему узлу
На канальном уровне:
Роутер начинает понимать, что IP-адрес соседа (next-hop IP), которому нужно направить пакет, является юникастовый, а значит надо запустить ARP (next-hop IP это не IP-адрес назначения, а именно адрес соседа, которому пакет будет передан).
Протокол ARP в своей таблице нашел соответствие между IP-адресом и мак-адресом соседа.
Пакет запаковался в Ethernet кадр.
Кадр спускается на физический уровень. Здесь определяется интерфейс (Fa7/0), через который пакет будет послан следующему транзитному узлу, а кадр превращается в последовательность нулей и единиц.
Как помните, я совершил ошибку и начал пинговать узел RO3. На самом деле это даже неплохо, так как появилось несколько моментов, которые я бы обязательно упустил.
RO2 при передачи пакета в сторону RO3 считает, RO3 следующим транзитным узлом, а не конечным получателем. Вопрос: почему он так считает? На самостоятельный разбор.
RO3 является конечным получателем, но пакет к нему приходит на один интерфейс (который направлен на RO2), а PC0 пингует интерфейс RO3, которым RO3 соединяется с PC1. Давайте посмотрим, что происходит на RO3.
У RO3 интерфейсы распределены так:
Fa6/0 в сторону RO2
Fa7/0 в сторону компьютера
Канальный и физический уровни RO3 смотреть смысла нет, там ничего нового, смотрим сразу в сетевой:
Сетевой уровень при приеме пакета на RO3
Роутер понимает, что IP-адрес назначения, указанный в принятом пакете, настроен на одном из его интерфейсов, поэтому надо вскрыть пакет, понять какому процессу его передать и сделать это (в смысле передать).
Вскрытие показало ICMP вложение, значит данные надо передать процессу ICMP.
Процесс ICMP понимает, что это сообщение Echo Request.
А значит надо понять чего и как отвечать, смотрим сетевой Out Layers.
Сетевой уровень RO3 при ответе на запрос
Процесс ICMP понимает, что отвечать надо сообщением Echo Reply.
ICMP процесс его и генерирует.
IP подхватывает данный Reply и накрывает своим заголовком.
В пакете есть IP-адрес назначения, это адрес узла PC0, роутеру надо по таблице маршрутизации найти маршрут для этого адреса, чтобы понять куда слать пакет.
Когда маршрут найден, пакет передается канальному уровню, также канальному уровню передается информация о IP-адресе соседа транзитного узла, которому пакет нужно направить.
Все дальнейшие действия были описаны уже не раз. Посмотрим лишь на результат: когда пакет дошел до PC0.
PC0 получил ICMP ответ
Ниже представлены результаты первого пинга, который был сделан в режиме реального времени и второго пинга, который мы рассматривали в симуляции.
C:\>ping 10.2.2.1
Pinging 10.2.2.1 with 32 bytes of data:
Request timed out.
Request timed out.
Reply from 10.2.2.1: bytes=32 time=4ms TTL=253
Reply from 10.2.2.1: bytes=32 time<1ms TTL=253
Ping statistics for 10.2.2.1:
Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 4ms, Average = 2ms
C:\>ping 10.2.2.1
Pinging 10.2.2.1 with 32 bytes of data:
Reply from 10.2.2.1: bytes=32 time=6ms TTL=253
Reply from 10.2.2.1: bytes=32 time=3ms TTL=253
Reply from 10.2.2.1: bytes=32 time<1ms TTL=253
Reply from 10.2.2.1: bytes=32 time<1ms TTL=253
Ping statistics for 10.2.2.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 6ms, Average = 2ms
C:\>
Если решите по отвечать на представленные ниже вопросы, предлагаю давать их под комментарием, который я оставлю под этим постом для ответа на вопросы.
Как мак-адрес РС2 оказался в ARP таблице PC3, если PC3 не делал ARP запрос чтобы узнать мак-адрес РС2 (вопрос по первой части)?
Куда потерялись пакеты при первом пинге от PC0 до RO3.
Как узлы в примерах понимают, что из полученных битов нужно слепить Ethernet кадры а не кадры какого-то другого протокола?
Какой порт слушает узел получатель для приема ICMP?
За счет чего ARP запрос получают все соседи по канальной среде?
Нужен ли будет ARP, если на канальном уровне будет не Ethernet, а какой-то другой протокол?