В прошлом видео мы разобрались со структурой IP-пакета в целом, но о некоторых полях стоит поговорить отдельно и посмотреть на них более пристально, одним из таких полей на мой взгляд является TTL, о котором далее.
Зачем нужно поле TTL?
Назначение поля TTL довольно простое: не допустить бесконечного хождения пакета по сети в том случае, если произошла петля маршрутизации. Особенность этого поля используется такими утилитами как tracert, mtr, winmtr. Рассматривать назначение этого поля будем на вот такой схеме:
Схема для изучения работы TTL
Но для начала коротко поясню как узлы работают с TTL. Представим, что пакет пришел на узел, он его получает и смотрит на значение поля TTL:
если значение равно единице, это значит, что пакет уже не будет передан следующему узлу: если пакет со значением 1 пришел на узел получатель, то он будет обработан и передан вышестоящему процессу, если же узел не конечный, то такой пакет будет уничтожен;
если значение поля TTL больше единицы, то пакет можно передать следующему узлу, если это требуется, либо если узел конечный, то он вскроет IP-заголовок и передаст содержимое пакета своему вышестоящему процессу;
если пакет нужно передать следующему узлу, то из значения TTL будет вычтена единица, произойдет пересчет контрольной суммы и пакет будет отправлен дальше.
Ничего сложного.
Топология сети и некоторые пояснения
Немного поясню по топологии сети: роутеры это образы Cisco 3725, хосты это образы Debian 10. На схеме показаны сети, которые настроены на линках между роутерами, для удобства нумерация была организована по следующему принципу:
1. Первый октет всегда равен десяти.
2. Второй октет это всегда меньший номер роутера.
3. Третий октет номер всегда номер большего роутера.
4. Четвертый октет равен номеру роутера.
5. Маска всегда /24.
Если бы у нас был линк R1 <-> R5. То на интерфейсе R1 был бы назначен адрес 10.1.5.1/24, на R5 такой: 10.1.5.5/24. Сети хостов назначил случайно и никакой системы в нумерации там нет.
Как работает Time to Live
Работает TTL на самом деле очень просто. Обратимся к нашей схеме. Узел Host_1 отправляет пакеты узлу Host_2, если значение TTL будет равно 4, то пакет будет уничтожен роутером R5, но если значение будет равно 5 или больше, то Host_2 получит пакет.
В этом легко убедиться, сделаем ping с Host_1. Для начала зададим TTL=4.
user@debian:~$ ping -t 4 192.168.2.12
PING 192.168.2.12 (192.168.2.12) 56(84) bytes of data.
Параметр t команды ping задает значение TTL. Трассировка подтверждает результаты пинга:
user@debian:~$ traceroute -m 4 192.168.2.12
traceroute to 192.168.2.12 (192.168.2.12), 4 hops max, 60 byte packets
1 192.168.1.155 (192.168.1.155) 1.836 ms 12.191 ms 22.688 ms
2 10.1.3.3 (10.1.3.3) 33.218 ms 43.708 ms 54.255 ms
3 10.3.4.4 (10.3.4.4) 64.698 ms 75.194 ms 85.180 ms
4 10.4.5.5 (10.4.5.5) 95.679 ms 106.314 ms 116.695 ms
Параметр m команде traceroute задает значение TTL, видим, что было пройдено четыре транзитных узла и пакет был уничтожен на четвертом (пятым узлом должен был быть Host_2). А теперь сделаем то же самое для TTL=5.
user@debian:~$ traceroute -m 5 192.168.2.12
traceroute to 192.168.2.12 (192.168.2.12), 5 hops max, 60 byte packets
1 192.168.1.155 (192.168.1.155) 4.686 ms 15.048 ms 25.488 ms
2 10.1.3.3 (10.1.3.3) 35.552 ms 46.068 ms 56.597 ms
3 10.3.4.4 (10.3.4.4) 67.063 ms 77.378 ms 87.591 ms
4 10.4.5.5 (10.4.5.5) 98.109 ms 108.930 ms 119.038 ms
5 192.168.2.12 (192.168.2.12) 129.545 ms 140.033 ms 150.561 ms
user@debian:~$
Успешный успех. Если мы попытаемся пропинговать адрес 192.168.2.17 с TTL=4, пинг у нас пройдет, т.к. этот адрес настроен на R5.
user@debian:~$ traceroute -t 4 192.168.2.17
traceroute to 192.168.2.17 (192.168.2.17), 30 hops max, 60 byte packets
1 192.168.1.155 (192.168.1.155) 3.694 ms 14.099 ms 24.630 ms
2 10.1.3.3 (10.1.3.3) 35.064 ms 45.116 ms 55.612 ms
3 10.3.4.4 (10.3.4.4) 66.078 ms 76.583 ms 87.074 ms
4 10.4.5.5 (10.4.5.5) 97.065 ms * *
user@debian:~$ ping -t 4 192.168.2.17
PING 192.168.2.17 (192.168.2.17) 56(84) bytes of data.
64 bytes from 192.168.2.17: icmp_seq=1 ttl=252 time=33.3 ms
64 bytes from 192.168.2.17: icmp_seq=2 ttl=252 time=34.0 ms
64 bytes from 192.168.2.17: icmp_seq=3 ttl=252 time=36.6 ms
64 bytes from 192.168.2.17: icmp_seq=4 ttl=252 time=49.1 ms
64 bytes from 192.168.2.17: icmp_seq=5 ttl=252 time=40.0 ms
^C
--- 192.168.2.17 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 10ms
rtt min/avg/max/mdev = 33.285/38.610/49.147/5.771 ms
user@debian:~$
Вопрос: почему четвертым хопом мы видим 10.4.5.5, а не 192.168.2.17? Ведь трассировку мы делаем до 192 адреса.
Создадим на сети петлю маршрутизации
Во всех этих примерах на сети не было петли маршрутизации, давайте ее создадим и посмотрим что будет. Петля маршрутизации была создана на линке R3 <-> R4, для этого со стороны R4 был добавлен вот такой статический маршрут в сторону R3:
ip route 192.168.2.12 255.255.255.255 10.3.4.3
Теперь пинг с первого хоста до второго не проходит:
user@debian:~$ ping 192.168.2.12
PING 192.168.2.12 (192.168.2.12) 56(84) bytes of data.
Вот трассировка, значение TTL по умолчанию для команды traceroute равно 30, так говорит man, петля подтверждает сведения, полученные из man:
user@debian:~$ traceroute 192.168.2.12
traceroute to 192.168.2.12 (192.168.2.12), 30 hops max, 60 byte packets
1 192.168.1.155 (192.168.1.155) 7.676 ms 17.985 ms 28.523 ms
2 10.1.3.3 (10.1.3.3) 38.995 ms 49.491 ms 59.979 ms
3 10.3.4.4 (10.3.4.4) 70.815 ms 80.969 ms 91.496 ms
4 10.3.4.3 (10.3.4.3) 101.949 ms 112.461 ms 122.974 ms
5 10.3.4.4 (10.3.4.4) 143.964 ms 154.418 ms 164.945 ms
6 10.3.4.3 (10.3.4.3) 175.578 ms 185.533 ms 142.816 ms
7 10.3.4.4 (10.3.4.4) 247.771 ms 258.300 ms 268.446 ms
8 10.3.4.3 (10.3.4.3) 278.805 ms 312.816 ms 323.311 ms
9 10.3.4.4 (10.3.4.4) 479.835 ms 626.355 ms 636.819 ms
10 10.3.4.3 (10.3.4.3) 556.593 ms 588.117 ms 598.524 ms
11 10.3.4.4 (10.3.4.4) 755.650 ms 797.647 ms 839.148 ms
12 10.3.4.3 (10.3.4.3) 849.913 ms 804.939 ms 805.743 ms
13 10.3.4.4 (10.3.4.4) 973.320 ms 1015.224 ms 962.095 ms
14 10.3.4.3 (10.3.4.3) 993.059 ms 952.398 ms 971.923 ms
15 10.3.4.4 (10.3.4.4) 1170.728 ms 1109.510 ms 1151.391 ms
16 10.3.4.3 (10.3.4.3) 1161.844 ms 1097.333 ms 1170.133 ms
17 10.3.4.4 (10.3.4.4) 1304.082 ms 1313.947 ms 1334.797 ms
18 10.3.4.3 (10.3.4.3) 1346.658 ms 1300.740 ms 1321.627 ms
19 10.3.4.4 (10.3.4.4) 1530.698 ms 1544.993 ms 1515.161 ms
20 10.3.4.3 (10.3.4.3) 1536.287 ms 1471.464 ms 1502.896 ms
21 10.3.4.4 (10.3.4.4) 1711.457 ms 1689.732 ms 1724.093 ms
22 10.3.4.3 (10.3.4.3) 1661.657 ms 1682.391 ms 1672.738 ms
23 10.3.4.4 (10.3.4.4) 1829.791 ms 1820.323 ms 1810.250 ms
24 10.3.4.3 (10.3.4.3) 1831.317 ms 1841.253 ms 1841.213 ms
25 10.3.4.4 (10.3.4.4) 1976.711 ms 1996.839 ms 2007.309 ms
26 10.3.4.3 (10.3.4.3) 1986.232 ms 1947.299 ms 1957.688 ms
27 10.3.4.4 (10.3.4.4) 2090.287 ms 2083.092 ms 2006.741 ms
28 10.3.4.3 (10.3.4.3) 2006.771 ms 1904.826 ms 1890.734 ms
29 10.3.4.4 (10.3.4.4) 1889.694 ms 1813.301 ms 1670.634 ms
30 10.3.4.3 (10.3.4.3) 1628.703 ms 1389.763 ms 1252.525 ms
user@debian:~$
В данном случае петля маршрутизации видна в трассировке, и по адресам мы можем сказать, что проблема на линке R3<->R4. Но при помощи трассировки не всегда можно локализовать проблему.
В дампе Wireshark петля будет выглядеть так:
Петля маршрутизации в дампе Wireshark
Для того, чтобы получить этот дамп, выполнялся вот такой пинг:
user@debian:~$ ping 192.168.2.12 -c 4 -t 12
PING 192.168.2.12 (192.168.2.12) 56(84) bytes of data.
В сторону Host_2 было направлено четыре пакета с TTL = 12. В дампе нас интересуют поля Source, Destination и TTL, дамп снимался с интерфейса R4 в сторону R3, по нему видно что на R4 пакет приходит с TTL равным 10, далее R4 этот пакет отправляет в сторону R3, а тот в свою очередь шлет пакет в R4 и так происходит до тех пор, пока TTL не станет равным 1. Если бы не было TTL, пакет на этом линке мог бы ходить до бесконечности.
Напоследок еще один вопрос, если я изменяю статический маршрут на R4, с помощью которого организуется петля, на такой (next-hop меняется на имя интерфейса в сторону R3):
ip route 192.168.2.12 255.255.255.255 fa0/0
Трассировка с первого хоста до второго становится такой:
user@debian:~$ traceroute 192.168.2.12
traceroute to 192.168.2.12 (192.168.2.12), 30 hops max, 60 byte packets
1 192.168.1.155 (192.168.1.155) 15.593 ms 26.071 ms 36.524 ms
2 10.1.3.3 (10.1.3.3) 47.051 ms 57.558 ms 78.591 ms
3 10.3.4.4 (10.3.4.4) 68.039 ms 89.026 ms 99.513 ms
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
user@debian:~$
По трассировке мы сейчас не можем сделать однозначный вывод о том, что произошла петля. Вопрос: почему трассировка стала такой?
Следующий пост будет без видео, в нем будет краткая инструкция о том, как подготовить данную лабу, делать краткую инструкцию how to в виде длинного видео не вижу особого смысла.
Видео версия
Для тех, кому проще смотреть, чем читать, есть видео версия.
Пока у нас в Новосибирске было не очень жарко, удалось написать пару постов и записать парочку видео для цикла про IPv4.
Напомню, что ранее мы разобрались с IP-адресами и, как мне кажется, разобрались. Теперь нужно поговорить о единицах измерения: массу мы измеряем в килограммах, длину в метрах, давления в паскалях, а вот фрагменты данных на сетевом уровне мы измеряем в пакетах, в общем случае фрагмент данных, передаваемый тем или иным протоколом, называется Protocol Data Unit или PDU, пакет это PDU в IP, пакет и будем разбирать.
Общая структура IP-пакета
Глобально IP-пакет состоит из двух частей: заголовка и поля данных, в которое помещается полезная для пользователей информация. В заголовке содержится вся необходимая служебная информация для обработки пакета узлами сети.
В поле данных помещаются данные, которые приходят с транспортного уровня, либо любого другого протокола, который хочет воспользоваться услугами IP. Список протоколов, который можно запихнуть внутрь пакета, легко найти (на вики, сайт IANA).
Ниже три структуры IP-пакета: первая устаревшая, вторая устаревшая, но переведена на рус-яз с ин-яза, третья актуальная.
Устаревшая структура IP-пакета
Актуальная структура заголовка в IP-пакете
Общего у них то, что пакет делится на ячейки, каждая ячейка имеет свой размер и свое имя, такая ячейка называется полем. Разница между представленными выше структурами в том, что в первых двух случаях есть поля Type of Service, но на самом деле это поле сейчас заменено на DSCP и ECN. Если говорить совсем просто, то поле ToS использовалось для того, чтобы узел мог отличить важный пакет от неважного и в первую очередь обрабатывать важные пакеты, а неважные уже по возможности. О DSCP и ECN поговорим ниже.
Важно понимать, что узлы ничего не знают ни о каких пакетах, пакет это лишь удобная абстракция для людей. Для компьютеров и роутеров это последовательность нулей и единиц. IP заголовок можно разбить на пять строк(если не считать опции, которые не обязательны) и длина каждой строки получится 32 бита или 4 байта, такая строка в RFC называется 32 битным словом. Поле заголовка не может начинаться на одном слове, а заканчиваться на другом.
Такой строгий подход к структуре заголовка не случаен, для себя я выделил две основные причины этого, которые в общем-то взаимосвязаны:
Сам IP размер пакетов считает не в битах или байтах, а в словах.
Процессоры сетевых узлов обрабатывают не байты или биты, а слова, если длина слова IP будет равна или кратна машинному слову процессора, то его будет проще обработать.
Кстати говоря, мы уже знаем размер типичного заголовка, он составляет 20 байт, т.к. у нас пять слов (если не считать поля с опциями) и каждое слово 4 байта.
Поля IP заголовка
Теперь разберемся с каждым полем в отдельности. Начнем с версии и размера заголовка.
Версия (Version)
Это версия протокола IP, под него выделено четыре бита, для протокола IPv4 здесь всегда неизменное значение – 4. Хочу заметить, что в IPv4 четверка не связана с количество октетов в IP-адресе, просто такое совпадение.
Размер заголовка (Internet Header Length)
Поле нужно, чтобы узел мог понять: где заканчивается заголовок и начинаются данные, т.к. поле опций не обязательное и их может быть больше чем одна. Под размер заголовка выделено четыре бита, значение данного поля это число, которое равно числу слов в заголовке. Понятно, что максимальное количество слов в заголовке равно пятнадцати.
DSCP и ECN
Под поле DSCP (Differentiated Services Code Point), выделено 6 бит, используется для разделения трафика на классы обслуживания.
Поле ECN (Explicit Congestion Notification) или указатель перегрузки имеет размер два бита. При помощи этого поля узлы могут сигнализировать о перегрузке. Не каждое устройство с этим полем умеет работать, сигнализация через ECN будет работать только в том случае, если узлы сети умеют его обрабатывать.
Размер пакета (Total Length)
Далее обсудим четыре поля, которые имеют отношение к размеру IP-пакета и его фрагментации, начнем с размера.
Это поле позволяет обрабатывающему устройству понять полный размер пакета, то есть заголовок + данные. Под поле выделено два байта, мы уже понимаем, что минимальный размер IP-пакета равен 20 байт, то есть это заголовок без опций и данных, а максимальный размер равен 65535 байт, это максимальное число, которое можно записать при помощи двух байт.
Идентификатор (Identification)
Чаще всего это поле используется в тех ситуация, когда пакет фрагментируется, чтобы принимающая сторона понимала, как из полученных кусочков правильно собрать пакет. У фрагментированных пакетов, которые являются частью одного целого, значение в этом поле должны быть одинаковыми.
Флаги (Flags)
Под флаги выделено три бита, используются для контроля над фрагментацией пакетов. Нумерация бит в поле начинается с нуля, крайний левый бит старший, а крайний правый – младший:
нулевой бит зарезервирован и должен быть всегда равен нулю;
если значение первого бита ноль, то допускается фрагментация пакетов, если единица (бит DF или Do not Fragment), то фрагментация запрещена и, если размер пакета при запрещенной фрагментации будет больше, чем разрешенный на канале, то такой пакет в канал отправлен не будет;
второй бит служит для того, чтобы конечные узлы понимали, где начинается последовательность фрагментированных пакетов, а где она заканчивается, если значение этого бита равно единице (MF More Fragments), то узел понимает, что этот пакет не последний и нужно ждать еще фрагментированные пакеты, чтобы собрать изначально разделенный пакет.
Поскольку тема фрагментации важная, то про нее будет отдельный пост и видео.
Смещение фрагмента (Fragment Offset)
Это поле используется в тех случаях, когда выполняется фрагментация пакетов, размер этого поля равен 13 бит. Об этом поле мы поговорим отдельно и детально, когда будем разбираться с фрагментацией пакетов.
Время жизни (Time to Live, TTL)
TTL имеет размер один байт или восемь бит, поле выполняет функцию защиты от петель маршрутизации. Благодаря TTL пакет не блуждает по сети до бесконечности в ситуациях, когда из-за неверной конфигурации роутеров произошла петля маршрутизации. TTL это число от 0 до 255, это число определяет максимально допустимое число узлов, через которое может пройти пакет, перед тем, как он будет уничтожен.
Время жизни для пакета задается узлом источником и изначально оно измерялось в секундах (то есть максимально возможное время жизни IP пакета раньше было 255 секунд), современные маршрутизаторы обрабатывают пакеты гораздо быстрее, чем за секунду, поэтому сейчас TTL – это значение, которое определяет число транзитных узлов, которые может пройти пакет, прежде чем он будет уничтожен.
Протокол (Protocol)
Под поле выделено 8 бит, поле использует узел получатель, чтобы понять какому процессу передать данные, когда IP-заголовок будет снят. В данное поле записывается код протокола, который был помещен отправителем в IP-пакет, коды регламентированы и их можно найти на сайте IANA.
Контрольная сумма заголовка (Header Checksum)
Под поле выделено два байта и как понятно из названия: протокол IP не имеет механизма проверки целостности данных, поскольку поле «контрольная сумма заголовка» не учитывает поле данных при проверке. Не забываем, что TTL меняется от узла к узлу, а это значит, что и контрольная сумма будет меняться от узла к узлу, то есть каждый транзитный маршрутизатор сперва принимает IP-пакет, вычисляет его контрольную сумму, сравнивает со значением, записанным в поле «контрольная сумма заголовка», затем изменяет поле TTL, вычисляет новую контрольную сумму и отправляет пакет следующему соседу.
Стоит отметить, что если значение контрольной суммы, которую посчитал узел, отличается от контрольной суммы, которая записана в пакете, то он просто уничтожается.
IP-адрес источника
Поле IP-адрес источника имеет размер 32 бита и не изменяется при передаче пакета по сети (если не рассматриваем ситуации с NAT), это поле важно для узла получателя, чтобы знать кому отвечать.
IP-адрес назначения
Данное поле имеет размер четыре байта, в него записывается IP-адрес узла, которому данный пакет предназначен, роутеры смотрят на этот поле при принятии решения о том куда направлять пакет.
Поле данных в IP-пакете
Поле данных в IP-пакете служит контейнером для других протоколов, которым IP оказывает услуги транспорта. Если учитывать, что максимально возможный размер IP-пакета 65535 байт, то максимально возможный размер поля данных 65515 байт.
Поле опций
С большой долей вероятности вы либо не будете использовать опции, либо будете пользоваться ими очень редко, поскольку для штатной передачи трафика опции обычно не используются, поэтому и останавливаться на них сейчас не буду, для самых любознательных дам ссылку.
Структура IP-пакета с опциями Record Route
Если кому интересно, то выше показана структура пакета с опциями Record Route.
Вопросы для ваших ответов
В конце каждого поста обычно стараюсь придумать несколько вопросов, но к данной теме как-то не очень получается, здесь в основном была справочная информация на запоминание.
Видео версия
А вот видео версия у нас есть в наличии, кому больше нравится смотреть - смотрите.
Меня зовут Илья Зеленчук, я веду курсы по компьютерным сетям на мат-мехе СПбГУ. Я понимаю, что онлайн курсов и уроков по компьютерным сетям очень много в сети и их не сложно найти. Что же нового решил сделать я?
Для лучшего обучения компьютерным сетям, я со студентами разрабатываю веб-эмулятор Miminet (https://miminet.ru/). Сервис, где можно нарисовать компьютерную сеть, задать её конфигурацию и посмотреть, как она будет работать.
Теперь можно не просто читать про компьютерные сети, а легко, прямо в вебе конфигурировать свою сеть и смотреть, как различные настройки влияют на ее работу.
Курс и эмулятор бесплатные, без рекламы и прочего.
Продолжаю серию публикаций про IP, этот пост продолжение предыдущего, ранее мы разобрались как записывать IP-адреса и что они собой представляют, здесь же предлагаю немного попрактиковаться и поработать с CLI Cisco и Huawei.
Настройка IP-адресов на роутере Cisco
Схема, на которой будем тренироваться, довольно простая. На ней подписаны роутеры и адреса с масками, которые нужно настроить на их интерфейсах, если адрес подчеркнут, то на интерфейсе он должен быть основным, остальные вторичные.
Схема для настройки IP-адресов
Лаба собрана в EVE-NG, если это важно. Начнем с настроек R1, на этом роутере нет конфига, поэтому при запуске IOS предлагает нам выполнить настройки в диалоговом режиме, мы естественно отказываемся:
--- System Configuration Dialog ---
Would you like to enter the initial configuration dialog? [yes/no]: Installed image archive
n
Press RETURN to get started!
*Mar 1 00:00:01.799: %LINEPROTO-5-UPDOWN: Line protocol on Interface VoIP-Null0, changed state to up
*Mar 1 00:00:02.123: %LINEPROTO-5-UPDOWN: Line protocol on Interface IPv6-mpls, changed state to up
*Mar 1 00:00:02.903: %LINK-3-UPDOWN: Interface FastEthernet1/0, changed state to up
*Mar 1 00:00:02.907: %LINK-3-UPDOWN: Interface FastEthernet2/0, changed state to up
*Mar 1 00:00:03.903: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to up
*Mar 1 00:00:03.907: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet2/0, changed state to up
*Mar 1 00:08:01.991: %SYS-5-RESTART: System restarted --
*Mar 1 00:08:01.995: %SNMP-5-COLDSTART: SNMP agent on host Router is undergoing a cold start
*Mar 1 00:08:01.999: %PCMCIAFS-5-DIBERR: PCMCIA disk 1 is formatted from a different router or PC. A format in this router is required before an image can be booted from this device
*Mar 1 00:08:02.015: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is OFF
*Mar 1 00:08:02.015: %CRYPTO-6-GDOI_ON_OFF: GDOI is OFF
*Mar 1 00:08:02.051: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively down
*Mar 1 00:08:02.175: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar 1 00:08:03.051: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
*Mar 1 00:08:03.175: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
*Mar 1 00:08:03.771: %LINK-5-CHANGED: Interface FastEthernet1/0, changed state to administratively down
*Mar 1 00:08:03.775: %LINK-5-CHANGED: Interface FastEthernet2/0, changed state to administratively down
*Mar 1 00:08:04.771: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to down
*Mar 1 00:08:04.775: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet2/0, changed state to down
Router>
После отказа роутер выполнил проверку своих интерфейсов и сообщил их статус, а также у нас появилось приглашение ко вводу Router>. Если есть приглашение, значит, мы можем вводить какие-то команды, если приглашение ко вводу заканчивается на знак больше, то значит, мы в EXEC режиме, в этом режиме нам доступно очень ограниченное число команд. Чтобы их все посмотреть, нужно написать знак вопроса и нажать Enter:
Router>?
Exec commands:
access-enable Create a temporary Access-List entry
access-profile Apply user-profile to interface
clear Reset functions
connect Open a terminal connection
credential load the credential info from file system
crypto Encryption related commands.
disable Turn off privileged commands
disconnect Disconnect an existing network connection
enable Turn on privileged commands
exit Exit from the EXEC
help Description of the interactive help system
lat Open a lat connection
lock Lock the terminal
login Log in as a particular user
logout Exit from the EXEC
modemui Start a modem-like user interface
mrinfo Request neighbor and version information from a
multicast router
mstat Show statistics after multiple multicast traceroutes
mtrace Trace reverse multicast path from destination to source
name-connection Name an existing network connection
pad Open a X.29 PAD connection
ping Send echo messages
ppp Start IETF Point-to-Point Protocol (PPP)
radius radius exec commands
release Release a resource
renew Renew a resource
resume Resume an active network connection
rlogin Open an rlogin connection
set Set system parameter (not config)
show Show running system information
slip Start Serial-line IP (SLIP)
ssh Open a secure shell client connection
systat Display information about terminal lines
tclquit Quit Tool Command Language shell
telnet Open a telnet connection
terminal Set terminal line parameters
tn3270 Open a tn3270 connection
traceroute Trace route to destination
tunnel Open a tunnel connection
udptn Open an udptn connection
vmi-dump Dump VMI debug info test command
vmi-neighbor-create Create VMI neighbor test command
vmi-neighbor-kill Create VMI neighbor test command
webvpn WebVPN exec command
where List active connections
x28 Become an X.28 PAD
x3 Set X.3 parameters on PAD
Router>
Но нам, чтобы выполнить какие-либо настройки, надо перейти сперва в привилегированный режим, а затем в режим конфигурации. Делается это так:
Router>enable
Router#
Router#
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#
Команда enable отвечает за перевод роутера в привилегированный режим, приглашение ко вводу изменилось на решетку, в этом режиме доступно большее количество команд, а вот какое именно зависит от привилегий конкретного пользователя, сейчас на роутере нет каких-либо специальных настроек и нам доступны все возможные команды.
Команда configure terminal переводит роутер в режим глобальной конфигурации, приглашение ко вводу снова изменилось. Сначала дадим роутеру имя, чтобы понимать, с каким именно узлом мы работаем (приглашение ко вводу изменится).
Router(config)#hostname R1
R1(config)#
У промышленных роутеров, как правило, конфигурации разделены на секции: есть глобальная секция, мы сейчас в ней, есть секция, в которой осуществляются настройки протоколов маршрутизации, например, OSPF или BGP, есть секции, в которых хранятся настройки различных префикс-листов и правил доступа, а есть секция настроек интерфейсов, она нас сейчас и интересует. Перейдем в режим конфигурации интерфейса, который направлен в сторону R2, приглашение ко вводу снова изменится.
Теперь зададим ему основной IP-адрес. При настройке IP-адреса на оборудование маску нужно указывать обязательно.
Примичание: назначать IP-адреса мы должны на канальные интерфейсы, в данном случае интерфейс FastEthernet0/1 представляет собой два уровня: канальный и физический, поэтому и адрес мы будем назначать на него. На роутерах есть возможность создавать на основе физических интерфейсов саб-интерфейсы, саб-интерфейсы относятся только к канальному уровню.
R1(config-if)#ip address 10.0.0.1 255.255.255.0
Интерфейс нужно включить. Как правило, роутеры Cisco из коробки идут с выключенными физическими интерфейсами, и их нужно включать, а порты их коммутаторов обычно сразу включены.
R1(config-if)#no shutdown
*Mar 1 00:34:51.475: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
*Mar 1 00:34:52.475: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
Роутер нам сообщит, что интерфейс включился. Команда shutdown выключает интерфейс, ключевое слово no инвертирует действие команды, например, удалить IP-адрес можно так:
no ip address 10.0.0.1 255.255.255.0
Посмотреть текущую настройку интерфейса fa0/1 можно так:
R1(config-if)#do sh run int fa0/1
Building configuration...
Current configuration : 112 bytes
!
interface FastEthernet0/1
description to_R2
ip address 10.0.0.1 255.255.255.0
duplex auto
speed auto
end
R1(config-if)#
Во-первых, можно использовать сокращения: fa=FastEthernet, sh=show, run=running-config, int=interface. Во-вторых, можно использовать кнопку Tab, если вы не помните, как правильно печатается команда, сработает автодополнение. И в-третьих, ключевое слово do следует использовать только в режиме конфигурации, без него в режиме конфигурации команды просмотра не работают. В EXEC и привилегированном режимах слово do писать перед show не надо.
Чтобы из режима конфигурации интерфейса выйти в режим глобальной конфигурации, нужно написать exit(поднимает на уровень выше), чтобы сразу перейти в привилегированный режим, нужно написать end(всегда выводит полностью из режима конфигурации, вместо end можно использовать сочетание клавиш ctrl+z).
О том, что он вторичный говорит ключевое слово secondary, вторичный адрес из той же сети, что и основной. Перейдем на интерфейс Fa0/0 и попробуем на нем настроить IP-адрес из этой же подсети:
R1(config-if)#int fa0/0
R1(config-if)#description to_R3
R1(config-if)#no shutdown
R1(config-if)#ip address 10.0.0.20 255.255.255.0
% 10.0.0.0 overlaps with FastEthernet0/1
Роутер нас предупреждает, что на Fa0/0 мы назначили адрес из подсети, которая настроена на Fa0/1. Если сперва назначить адрес, а потом попытаться включить интерфейс, то адрес будет назначен, но IOS не даст такой интерфейс включить. Вот такое предупреждение будет, если попытаться включить интерфейс с пересечением:
R1(config-if)#no sh
% 20.0.0.0 overlaps with FastEthernet0/0
FastEthernet1/0: incorrect IP address assignment
Если сперва включить интерфейс, как в примере, а затем попытаться настроить пересекающийся адрес, то адрес назначен на интерфейс не будет. Важно понимать что один конкретный роутер контролирует пересечение адресации только на своих интерфейсах пересечения с соседями роутером никак не контролируется.
Давайте на Fa0/0 настроим три адреса со схемы, вот его конфигурация:
R1#sh run int fa0/0
Building configuration...
Current configuration : 203 bytes
!
interface FastEthernet0/0
description to_R3
ip address 20.0.0.10 255.255.255.0 secondary
ip address 20.0.1.1 255.255.255.0 secondary
ip address 20.0.0.1 255.255.255.0
duplex auto
speed auto
end
Основной адрес и один из вторичных здесь из одной подсети второй вторичный адрес из другой подсети. Вот так выглядит итоговая конфигурация Fa0/1:
R1#sh run int fa0/1
Building configuration...
Current configuration : 203 bytes
!
interface FastEthernet0/1
description to_R2
ip address 10.0.0.10 255.255.255.0 secondary
ip address 10.0.1.1 255.255.255.0 secondary
ip address 10.0.0.1 255.255.255.0
duplex auto
speed auto
end
R1#
Некоторые полезные диагностические команды для роутеров Cisco
Ниже приведу несколько полезных команд для просмотра информации по настройкам интерфейсов на роутерах Cisco, это самые базовые команды, углублятся сейчас смысла не вижу, т.к. пишу не про Cisco, а про IP.
Посмотреть какие основные IP-адреса настроены на интерфейсах можно такой командной (br=brief).
R1#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 20.0.0.1 YES manual up up
FastEthernet0/1 10.0.0.1 YES manual up up
FastEthernet1/0 unassigned YES unset administratively down down
FastEthernet2/0 unassigned YES unset administratively down down
R1#
Можно посмотреть детальную информацию по IP параметрам на интерфейсе, в ней будут видны вторичные адреса:
FastEthernet0/0 is up, line protocol is up
Internet address is 20.0.0.1/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Secondary address 20.0.0.10/24
Secondary address 20.0.1.1/24
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is disabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF Fast switching turbo vector
IP multicast fast switching is enabled
IP multicast distributed fast switching is disabled
IP route-cache flags are Fast, CEF
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Policy routing is disabled
Network address translation is disabled
BGP Policy Mapping is disabled
WCCP Redirect outbound is disabled
WCCP Redirect inbound is disabled
WCCP Redirect exclude is disabled
R1#
Посмотреть как интерфейсы подписаны можно так (des=description).
R1#sh int des
Interface Status Protocol Description
Fa0/0 up up to_R3
Fa0/1 up up to_R2
Fa1/0 admin down down
Fa2/0 admin down down
Подробно про ARP мы не говорили, но на будущее уместно упомянуть, что роутер будет использовать один и тот же мак-адрес для всех IP-адресов, которые настроены на один канальный интерфейс, узнать это можно посмотрев ARP-таблицу роутера.
R1#sh ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.0.0.1 - c201.14a3.0001 ARPA FastEthernet0/1
Internet 10.0.0.10 - c201.14a3.0001 ARPA FastEthernet0/1
Internet 10.0.1.1 - c201.14a3.0001 ARPA FastEthernet0/1
Internet 20.0.0.1 - c201.14a3.0000 ARPA FastEthernet0/0
Internet 20.0.0.10 - c201.14a3.0000 ARPA FastEthernet0/0
Internet 20.0.1.1 - c201.14a3.0000 ARPA FastEthernet0/0
Посмотреть мак-адрес интерфейса можно вот такой командной, он будет во второй строке (также здесь есть другая мнформация о канальном уровне интерфейса).
R1# sh int fa0/1
FastEthernet0/1 is up, line protocol is up
Hardware is Gt96k FE, address is c201.14a3.0001 (bia c201.14a3.0001)
Description: to_R2
Internet address is 10.0.0.1/24
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 10Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:07, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 output buffer failures, 0 output buffers swapped out
Чтобы не смотреть такие длинные портянки, можно пользоваться регулярными выражениями. Например, вот так можно оставить только те строки, в которых встречается последовательность символово add:
R1# sh int fa0/0 | in add
Hardware is Gt96k FE, address is c201.14a3.0000 (bia c201.14a3.0000)
Internet address is 20.0.0.1/24
Если кто не знал, вертикальная черта перед in называется пайп, после пайпа возможны такие варианты:
R1# sh int fa0/0 | ?
append Append redirected output to URL (URLs supporting append operation
only)
begin Begin with the line that matches
exclude Exclude lines that match
include Include lines that match
redirect Redirect output to URL
section Filter a section of output
tee Copy output to URL
В данном случае использовался include, чтобы найти вхождение подстроки в строку. Смысла описывать настройку R2 не вижу, т.к. там меняются IP-адреса, а команды те же.
Настройка IP-адресов на роутере Huawei
Huawei нам не предлагает никаких диалогов, просто предлагает нажать любую кнопку, а затем ввести имя пользователя и пароль, в данном случае используется образ виртуального маршрутизатора AR1000V, логин и пароль по-умолчанию super. При первом входе роутер предложил сменить пароль, я согласился:
Press any key to get started
Login authentication
Username:super
Password:
Warning: The password is already expired.
The password needs to be changed. Change now? [Y/N]: y
Please enter old password:
Please enter new password:
Please confirm new password:
The password has been changed successfully.
<Huawei>
<Huawei>
У Huawei режим просмотра не делится на Exec и привилегированный, есть режим, в который вы попадаете сразу после подключения к устройству(не знаю как он по-умному называется и, если честно, не интересно, поэтому его я буду называть просто режимом просмотра) и есть режим system-view, в котором есть возможность конфигурирования, а также расширенные команды для диагностики.
Приглашение ко вводу в режиме просмотра обрамлено знаками меньше/больше. Режим system-view прямыми скобками.
<Huawei>system-view
Enter system view, return user view with Ctrl+Z.
[Huawei]
Tab и различного рода сокращения в Huawei работают тоже. Давайте настроим:
[Huawei]sysname R3
[R3]interface gi0/0/1
[R3-GigabitEthernet0/0/1]description to_R1
[R3-GigabitEthernet0/0/1]undo shutdown
Info: Interface GigabitEthernet0/0/1 is not shutdown.
Jan 11 2024 23:05:01+00:00 R3 %RM/4/ROUTERID_CHANGE(l)[0]:The router ID is 20.0.0.30. (InstanceID=0)
Jan 11 2024 23:05:01+00:00 R3 %IFNET/4/LINK_STATE(l)[1]:The line protocol IP on the interface GigabitEthernet0/0/1 has entered the UP state.
[R3-GigabitEthernet0/0/1]ip address 20.0.0.30 255.255.255.0 sub
[R3-GigabitEthernet0/0/1]ip address 20.0.0.3 255.255.255.0 sub
[R3-GigabitEthernet0/0/1]display current-configuration int gi0/0/1
[V300R019C00SPC300]
#
interface GigabitEthernet0/0/1
description to_R1
ip address 20.0.1.3 255.255.255.0
ip address 20.0.0.30 255.255.255.0 sub
ip address 20.0.0.3 255.255.255.0 sub
#
return
[R3-GigabitEthernet0/0/1]
Командной sysname мы дали имя R3, далее перешли в режим конфигурации интерфейса GigabitEthernet0/0/1, подписали его, затем попробовали включить (у HW логика та же, что и у Cisco, но вместо no используется undo), но роутер сообщил нам, что интерфейс уже включен, видимо, маркетологи Huawei еще не догадались зарабатывать на консольных кабелях, как Cisco.
Далее хочу обратить внимание, что мы настраиваем линк R1 <-> R3, со стороны R1 основной адрес был 10.0.0.1/24, а здесь настаивается 20.0.1.3/24, посмотрим, что из этого выйдет. Когда настраиваются вторичные адреса у Huawei, они отмечаются ключевым словом sub. На этом настройка закончена, в завершении приведена итоговая конфигурация интерфейса. В HW из режима конфигурации не надо использовать никаких ключевых слов для выполнения команд просмотра, вместо show здесь display.
В каком бы контексте конфигурации вы не находились сочетания ctrl+z вас вернет в режим просмотра, а команда quit вернет на уровень выше(аналог exit).
Давайте на роутере Huawei на интерфейсе Gi0/0/0 попробуем настроить адреса из тех же подсетей, что и адреса интерфейса Gi0/0/1.
Как видим основной адрес задать не удалось, только description. Ок, зададим основной адрес из другой подсети. А вторичные попробуем из тех же, что и на Gi0/0/1.
[R3-GigabitEthernet0/0/0]ip address 30.0.0.3 24
Jan 11 2024 23:23:23+00:00 R3 %IFNET/4/LINK_STATE(l)[0]:The line protocol IP on the interface GigabitEthernet0/0/0 has entered the UP state.
Во-первых, маску при назначении можно задавать одним числом, во-вторых, роутер не дал нам настроить вторичные адреса из тех же подсетей, что есть на интерфейсе Gi0/0/1 и это правильно. Вот корректные настройки:
Все настройки, которые были сделаны, нужно сохранить в энергонезависимую память, иначе после перезагрузки роутера он вернется к исходной конфигурации, так как сейчас они есть только в оперативной памяти. На Huawei это делается командой save, на Cisco есть два варианта: write или copy running-config startup-config.
Проверяем работу схемы
Нам осталось убедиться, что все работает, для этого давайте попускаем пинги от R1 к R3, будем явно указывать адрес из-под которого мы будем пинговать, и адрес, который мы будем пинговать.
Пингуем адрес 20.0.0.3 со всех трех адресов интерфейса Cisco, адрес источника назначается ключевым словом source.
R1# ping 20.0.0.3 source 20.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.3, timeout is 2 seconds:
Packet sent with a source address of 20.0.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/9/16 ms
R1# ping 20.0.0.3 source 20.0.0.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.3, timeout is 2 seconds:
Packet sent with a source address of 20.0.0.10
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/10/20 ms
R1# ping 20.0.0.3 source 20.0.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.3, timeout is 2 seconds:
Packet sent with a source address of 20.0.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/10/12 ms
Все три пинга успешны. Дабы не занимать время и место просто скажу, что остальные адреса, настроенные, на интерфейсе Huawei тоже пингуются со всех трех адресов роутера R1, которые настроены на интерфейсе в сторону R3.
Вопросы для ваших ответов
Оставлю комментарий для ответов, если захотите отвечать на вопросы, то лучше делать под этим комментарием, чтобы не спойлерить другим.
Предлагаю разобраться с тремя вопросами:
Какие адреса или адрес будет использовать роутер Cisco если пинговать ответные адреса Huawei без указания source IP?
Какие адреса или адрес будет использовать Huawei, если пинговать ответные адреса Cisco и не указывать source IP?
При текущих конфигурациях будут ли пинговаться адреса, настроенные на линке R2/R3 с роутера R1? Почему?
Видео версия
Для тех кому нравится больше смотреть, чем читать вот видео на тему поста:
Мы разобрались с видами устройств в IP, теперь нужно научиться как-то отличать один узел сети от другого, а для этого надо разобраться с IP-адресами, какими они обладают свойствами, как их записывать и другими вопросами. Вопросов много, разбираться будем по порядку.
Тему IP-адресов я разбил на три логические части: сперва идет немного теории, потом мы разбираемся с формами записи IP-адресов, пингуя всё на свете, кроме шила и гвоздя, а в третьей части мы соберем небольшую лабу в EVE-NG, чтобы разобраться как настраиваются основные и вторичные IP-адреса на интерфейсах роутеров.
Я не нашел как на Пикабу создать оглавление для поста в его начале(если кто-то что-то подскажет по этому поводу буду благодарен), а все три части вместе получились довольно объемными, поэтому тема будет разбита на два поста, ниже теория + пинги, отдельным постом поделаем настройки.
Задачи IP-адресов
Давайте сперва поймем какие задачи решает 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-адреса на одном интерфейсе могут быть из одной подсети.
Как записать 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 бита, оно же может быть и десятичным. Вопрос в том, как нам записать адрес в десятичном виде одним числом и можно ли это вообще делать?
Яндекс доступен по адресу: 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, все три устройства в одной подсети, пингуем с первого ноутбука второй. Вопрос: как физически будут передаваться данные, напрямую между двумя ноутбуками или через роутер и почему?
Всем доброго вечера. Господа помогите сделать выбор, планируется 10 м кабель от роутера до ps4 и тв приставки. И нужна какая нибудь коробушка, что бы это всё развести, подключить и забыть.
Продолжение поста о видах устройств в 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, а какой-то другой протокол?
Важно понимать, что IP это не только пакет и адрес, но и устройства, на которые эти самые адреса назначаются, чтобы затем генерировать, пересылать или же принимать пакеты, о устройствах и поговорим далее. На Пикабу есть ограничение: пост не может иметь больше 25 картинок, в ходе его подготовки это ограничение было немножечко превышено мной, поэтому он разделен на две части.
Первая часть содержит в себе теорию, плюс здесь мы посмотрим на взаимодействие двух оконечных IP узлов в тех случаях, когда им для этого взаимодействия роутер не требуется.
Для общего представления о работе IP теории будет достаточно, для того чтобы проникнуться лучше самостоятельно собрать и повторить лабу в Cisco Packet Tracert(далее для краткости CPT), внимательно посмотреть где и какие адреса меняются, подумать(с гуглом или яндексом) почему это происходит. Вопросы, замечания, дополнения и уточнения только приветствуются.
Виды устройств в IP
Устройства в IP делятся на два вида:
Конечные или терминальные узлы, для краткости я их буду называть хосты, они могут отправлять и получать пакеты, в некоторых случаях устройство может либо только получать, либо только отправлять пакеты. Хосты описаны в RFC1122.
Транзитные узлы или роутеры, как правило, к таким узлам мы не обращаемся напрямую, их задача направлять пакеты в ту или иную сторону.
Протокол IP – это протокол сетевого уровня, любые сетевые устройства должны быть соединены каналами, канальная среда может быть любой, но чаще всего на канальном уровне мы работаем с Ethernet.
Задачи узла отправителя
Начнем с хостов и с их возможности генерировать пакеты и направить их в сеть, вот что делает устройство для отправки пакета:
Пакет нужно сформировать, следует сказать, что IP-пакет состоит из двух частей: заголовка, в котором находится вся необходимая информация для обработки пакета узлами компьютерной сети и поля данных. Сам IP никаких данных не генерируют, процесс IP получает данные от вышестоящего процесса, если вышестоящим процессом является транспортный уровень, то обычно это такие протоколы как UDP, TCP, SCTP, но вышестоящим процессом может быть и протокол сетевого уровня, например, протокол ICMP, который используется когда мы хотим чего-нибудь попинговать. Кто бы ни был вышестоящим процессом его данные помещаются в соответствующее поле данных в пакете, а затем накрываются заголовком.
Вторым шагом отправитель должен решить какому соседу по канальной среде нужно передать пакет, чтобы он дошел до получателя. Если получатель в одной канальной среде с отправителем, то пакет будет передан непосредственно ему. Если же получатель находится в другой подсети, то пакет будут передан транзитному узлу, который дальше будет принимать решение о том что делать с пакетом.
Отправитель может иметь один или несколько интерфейсов, которыми он подключен к сети, поэтому ему нужно выбрать интерфейс, в который пакет будет направлен, выбор будет зависеть от результатов второго шага, а затем нужно определить канальный адрес соседа, которому пакет будет отправлен. Если получатель в одной канальной среде с отправителем, то определяется канальный адрес получателя, если получатель и отправитель в разных подсетях, то отправитель определяет канальный адрес транзитного узла, которому пакет будет передан. Если на канальном уровне Ethernet, то определяется мак-адрес, за узнавание мак-адресов соседей отвечает протокол ARP.
И наконец IP-пакет запаковывается в кадр канального протокола, далее кадр превращается в битовую последовательность, которая направляется в сеть через выбранный интерфейс.
Вроде бы никаких хитрых действий отправитель не совершает.
Задачи узла получателя
Задачи получателя несколько более простые:
Пакет нужно получить и убедиться в двух вещах:
Получатель должен убедиться, что именно он является получателем.
А также проверить корректность полученных данных.
Далее данные передаются вышестоящему процессу, который уже решит что с ними делать.
Если получатель сочтет нужным, то он в дальнейшем может послать ответ отправителю.
Задачи маршрутизатора (транзитного узла)
Роутеры самые сложные устройства с точки зрения IP, выполняющее самый большой объем работы. В их задачи входит:
Получить пакет (пакет может прийти как от непосредственно отправителя, так и от другого роутера, маршрутизатору это не важно, т.к. зачастую судьба пакета определяется только IP-адресом получателя, указанным в заголовке). Роутер должен убедиться в корректности полученных данных, а также в том, что он не является конечным получателем.
Далее требуется определить какому из соседей по канальной среде следует передавать пакет. Если роутер в одной канальной среде с получателем, то пакет будет передан непосредственно ему, если же нет, то следующему транзитному узлу.
Как и в случае с узлом отправителем, роутер определяет свой интерфейс, в который будет послан пакет, а также канальный адрес соседа.
Если требуется модификация пакета, то пакет модифицируется, а затем отправляется в выбранный интерфейс.
Для проверки корректности заголовка у пакета есть контрольная сумма, а чтобы понять, что ты не являешься конечным получателем достаточно сравнить IP-адрес назначения в пакете со своими IP-адресами и если они не совпадают, то направить пакет дальше.
Важно понимать, что описанные роли никак не ограничивают устройства, одно и то же устройство может быть: отправителем, получателем и транзитным узлом. Для примера возьмем ваш домашний роутер: когда вы выходите в интернет, это транзитный узел, когда вы подключаетесь к роутеру, чтобы его настроить, он становится хостом, который отправляет и принимает пакеты.
Обратное утверждение тоже справедливо: устройство не обязано реализовывать сразу все три функции, например, различного рода дешевые датчики мониторинга могут только посылать пакеты.
Топология и подготовка лабы
С теорией всё, давайте соберем простенькую лабу и посмотрим на IP устройства в эмуляторе. Для практики по данной теме буду использовать CPT. Пока мы ничего не будем настраивать, просто посмотрим, что эмулятор будет нам рассказывать о действиях узлов.
В целом я бы не рекомендовал для обучения использовать CPT, в данном случае я его использую для наглядности. Если производительность вашего ПК позволяет, присмотритесь к GNS3 или EVE-NG, второй эмулятор более предпочтительный. Есть еще pnetlab, говорят он даже по-лучше EVE-NG будет. Если нужен онлайн эмулятор, можно попробовать онлайн сервис СПбГУ: https://miminet.ru/
Схема, на которой будем тренироваться выглядит так:
Топология лабы. Если будете настраивать самостоятельно, то не забудьте отключить на роутерах CEF+настроить маршрутизацию.
Пояснения к схеме:
Оранжевым обведены хосты.
Зеленым роутеры.
Синим коммутатор, в данном случае мы его не рассматриваем как IP-устройство, сейчас можно представить, что это не коммутатор, а связка проводов, которая соединяет PC2, PC3 и RO2 вместе.
На топологии, обведенной фиолетовым, мы посмотрим как два хоста взаимодействуют напрямую, а на участке, обведенном серым, мы посмотрим на взаимодействие хостов через транзитные узлы. Начнем с прямого взаимодействия.
У CPT есть два режима работы: режим реального времени и режим симуляции, в котором можно отследить каждое действие и отследить каждый пакет. Заглянуть внутрь пакетов и получить описания действий узлов можно в режиме симуляции.
Лабу нужно перевести в режим симуляции, а затем настроить фильтр пакетов, которые мы хотим видеть, всё это можно сделать кнопками в правом нижнем углу программы.
Кнопка Simulation для перевода в режим симуляции, кнопка "Edit Filters" чтобы отключить лишние для нас пакеты. Оставляем только ICMP и ARP.
Кнопка Edit Filters отвечает за появление окна на скрине выше, на вкладках IPv6 и Misc тоже нужно отключить отображение всех прочих пакетов.
Я сознательно не останавливался на детальном описание интерфейса CPT, сам он нам не интересен, да и гайдов по его использованию в этих ваших интернетах тьма темная.
Взаимодействие отправителя и получателя
Начнем с более простого, то есть с той ситуации, когда отправитель и получатель находятся в одной канальной среде. На схеме между PC2 и PC3 есть коммутатор, но для IP он полностью прозрачный, можно считать что этих два устройства с точки зрения IP соединены напрямую проводом.
Выполним пинг с PC2 на PC3, нужно открыть командную строку PC2 сделать это можно так:
В топологии кликаем на иконку PC2.
Появится окно, в котором нужно будет выбрать вкладку Desktop.
На вкладке Desktop выбираем иконку Command Prompt.
Интерфейс компьютера в CPT
После этого у нас появится командная строка, в ней мы пишем: ping 192.168.0.1. В данном случае мы смотрим на прямое взаимодействие отправителя и получателя, они находятся в одной подсети, а значит и в одной канальной среде, а это всё означает, что таким узлам не нужны посредники в виде роутеров.
PC2 сформировал пакеты
После того, как мы ввели команду и нажали Enter, PC2 сформировал два пакета:
Синий, это как раз тот пакет, который нас интересует, то есть ICMP.
Зеленый, это кадр с ARP запросом, он нам не интересен, сейчас нам лишь важно понимать, что протокол ARP поможет PC2 узнать канальный адрес узла PC3, в данном случае это мак-адрес.
Посмотрим содержимое синего пакета, клацнув в него.
Содержимое ICMP пакет и описание того как его обрабатывает отправитель на сетевом уровне.
Появившееся окно имеет две вкладки: OSI Model и Outbound PDU Details. Нам интересна первая, вторую даже смотреть не будем, на ней представлена детальная информация о структуре кадров и пакетов, она нам сейчас не интересна.
На вкладке OSI можно по шагам посмотреть что делает тот или иной узел при приеме или отправке пакета. За прием отвечает In Layers, за передачу отвечает Out Layers. Как видите, каждая половина разбита на семь уровней, это семь уровней модели OSI, если шрифт уровня тускло серого цвета, значит на нем ничего не происходит, если шрифт черный, значит на этом уровне что-то происходит и он кликабельный, переключаться между уровнями можно еще и кнопками Previous Layer/Next Layer.
Сетевым инженерам обычно интересны уровни с транспортного и ниже, то есть Layer 1 - Layer 4, если мы смотрим на окно CPT. Ниже я приведу синонимы каждого Layer, которые обычно используются:
Layer 1 = L1 = Физический уровень
Layer 2 = L2 = Канальный уровень
Layer 3 = L3 = Сетевой уровень
Layer 4 = L4 = Транспортный уровень
На рисунке выше CPT нам показывает, что делает узел отправитель(PC2) на сетевом уровне :
PC2 запустил процесс Ping сразу после того, как мы выполнили команду ping.
Процесс Ping создает сообщение ICMP Echo Request и отправляет его нижележащему процессу. Здесь следует пояснить, что ICMP и IP это протоколы сетевого уровня, но для ICMP процесс IP это нижележащий процесс.
Отправитель должен подставлять в пакет свой IP-адрес, чтобы обратная сторона могла ответить, если она сочтет это нужным. При выполнении команды ping не был задан IP-адрес, поэтому устройство выбрало адрес само (оптимальный на взгляд устройства, хотя по факту он там настроен один).
PC2 установил, что IP-адрес узла получателя находится с ним в одной подсети, а также в пакет был добавлен IP-адрес узла получателя.
А вот что CPT нам может рассказать о канальном уровне.
Что происходит на канальном уровне
Важный момент: в примере на канальном уровне у нас работает Ethernet, за связку сетевого и канального уровня в случае IP/Ethernet используется протокол ARP.
На канальном уровне:
Узел PC2 определил, что IP адрес получателя юникастовый, а это значит, что узел должен знать или определить мак-адрес получателя. Чтобы определить канальный адрес соседа узел запустил процесс ARP.
Первым делом ARP проверил свою таблицу, чтобы найти: какой мак-адрес соответствует IP-адресу, который мы пингуем (192.168.0.1), но такого соответствия он не обнаружил, поэтому PC2 сформировал ARP-запрос и сохранил ICMP пакет в свой буфер(то есть на текущем шаге синий пакет отправлен никуда не будет).
На физическом уровне пока ничего не происходит, нам нужно перевести симуляцию на следующий шаг. Сделать это можно в правом нижнем углу экрана на соответствующей панели.
Управление симуляцией
Кнопка Play запустить симуляцию в автоматическом режиме, левая кнопка это шаг назад, правая кнопка шаг вперед. Автоматический режим нам не интересен, перейдем на следующий шаг. Следующих несколько шагов покажут нам как по сети гуляет ARP, сейчас мы не будем детально разбираться с тем, как работает ARP, для этого будет отдельная тема, сейчас нам важно понимать две вещи:
ARP-запрос PC2 использует, чтобы изучить канальный адрес соседа, в сторону которого должен быть отправлен пакет с ICMP.
ARP-запрос получат все соседи PC2 по канальной среде, но ответ даст только тот сосед, чей IP-адрес будет указан в ARP-запросе, все остальные проигнорируют этот ARP-запрос. И тут два момента: если соседей с таким IP нет, то никто и не ответит; если сосед с таким адресом есть, то он ответит, в ответе будет содержаться его мак-адрес.
Вот что по этому поводу нам показывает CPT:
Соседние узлы получили ARP-запрос
Узел RO2 получил запрос и проигнорировал его, это видно по красному крестику, а вот узел PC3 готов ответить на запрос. Что делает PC3 для отправки ARP мы пропустим, но в итоге мы приходим к той ситуации, что узел PC2 получил ARP ответ и изучил мак-адрес соседа, в сторону которого надо отправить пакет.
Зеленый пакет ниже это и есть ARP-ответ PC3, а синий пакет, это тот ICMP, который ранее был спрятан в буфер.
Узел PC2 получил ARP-ответ от узла PC3, тем самым изучил его канальный адрес
Давайте рассмотрим дальнейшие действия PC2, уже после того, как он изучил мак-адрес нужного соседа.
Узел PC2 изучил мак-адрес соседа и отправляет пакет
Напомню, что остановились на том, что у канального уровня не было мак-адреса соседа, в сторону которого надо было посылать пакет, теперь мы этот адрес знаем, поэтому:
ICMP пакет был извлечен из буфера для дальнейшей обработки.
PC2 инкапсулирует(помещает/запаковывает) IP пакет, внутри которого ICMP, внутрь Ethernet кадра.
И тут мы видим что физический уровень стал кликабельным.
Что происходит на физическом уровне
А на L1 мы видим, что отправитель выбрал свой интерфейс, через который он будет готов послать сообщение в сеть, на физическом уровне Ethernet кадр превращается в последовательность бит.
Пакет пройдет коммутатор и на нем мы не будем останавливаться, для нас там ничего интересного нет. Посмотрим на пакет, пришедший к получателю.
Пакет пришел к получателю
Здесь мы видим изменения:
1. На вкладке OSI появилось описание того, что происходит на приеме, т.е. теперь у нас информация по In Layers и Out Layers.
2. Вкладок PDU Details тоже стало две.
Сейчас мы не будем заходить на вкладку из пункта два. Что касается первого пункта: PC3 должен сперва принять пакет, т.е. выполнить действия получателя, они описаны под заголовком In Layers, а затем он должен будет дать ответ, т.е. PC3 становится отправителем, что он делает для ответа описано под заголовком Out Layers.
Также вы могли заметить что прием выполняется снизу вверх, а передача наоборот, сверху вниз. PC3 на физическом уровне получает битовую последовательность по порту FastEthernet0 и превращает ее в кадр Ethernet. Переходим на канальный уровень.
Действия узла на канальном уровне при приеме пакета
Здесь узел PC3 убеждается:
Что мак-адрес это мак-адрес, который присвоен одному из интерфейсов PC3, либо это широковещательный мак-адрес, любо это мак-адрес многоадресной рассылки, на который должен отвечать PC3. По факту в данном случае мак-адрес юникастовый и он принадлежит PC3.
Ввиду того, что мак-адрес назначения, указанный в кадре, принадлежит PC3, можно снять Ethernet заголовок и заглянуть и обнаружить под ним IP-пакет.
Переходим на сетевой уровень.
Сетевой уровень при приеме пакета
Здесь происходит следующее:
PC3 убеждается, что пакет направлен именно ему, а не кому-то другому, поскольку он видит что адрес назначения в пакете совпадает с тем, что настроен на его интерфейсе, либо широковещательный, либо из диапазона многоадресной рассылки в которой данный узел заинтересован. В нашем случае адрес назначения в пакете настроен непосредственно на PC3, а это значит, что можно снять заголовок IP и посмотреть что в пакете.
Внутри пакет обнаружилось ICMP вложение, которое надо передать процессу ICMP.
ICMP процесс установил что тип полученного сообщения это ICMP Echo Request, на который нужно дать ответ.
И вот мы на границе, когда один и тот же узел превращается из отправителя в получателя. Посмотрим, что делает PC3 для отправки ответа, ответ начинает формироваться на сетевом уровне и спускается вниз к физическому.
Узел PC3 готовит ICMP Reply, сетевой уровень
Действия узла такие:
ICMP процесс решает что на данный Request следует ответить сообщением типа ICMP Echo Reply.
Сообщение Echo Reply отправляется процессу IP.
Узел видит, что IP-адрес назначения находится в одной подсети с ним, а значит пакет можно отправлять непосредственно получателю.
ICMP вложение накрывается IP заголовком и передается на канальный уровень.
Действия PC3 на канальном уровне
PC3 установил что IP-адрес назначения юникастовый, а значит надо запустить ARP процесс для того, чтобы узнать канальный адрес соседа.
Мак-адрес соседа находится в ARP-таблице, поэтому в дальнейшем в Ethernet-кадр в поле мак-адрес назначения будет подставлен мак-адрес, соответствующий IP-адресу 192.168.0.2, взятый из ARP-таблицы.
IP-пакет накрывается Ethernet-заголовком, тем самым формируется Ethernet кадр.
На физическом уровне ничего интересного нет, PC3 для отправки выбрал интерфейс Fa0, превратил кадр в битовую последовательность, которая и была направлена в сеть. В итоге ответ PC3 дойдет до PC2 и когда PC2 получит этот ответ, произойдет изменение в командной строке, появится диагностическая информация о том, что узел PC3 доступен.
ICMP пришел на PC2
Исходный отправитель превратился в получателя. Получение пакета на канальном и физическом уровнях для PC2 ничем не будут отличаться от действий на PC3, поэтому оставляю этот момент без комментариев. Вот что происходит на сетевом уровне уровне:
Действия PC2 на сетевом уровне при получении пакета
Первым шагом PC3 видит, что пакет принадлежит ему, а значит, надо снять IP заголовок.
Под заголовком обнаруживается ICMP вложение, оно предается ICMP процессу.
ICMP процесс видит, что это Reply на Request, посланный ранее.
Процесс Ping получает от ICMP сообщение Echo Reply, в этом сообщение содержится диагностическая информация, которая затем отображается на экране командной строки.
По умолчанию в CPT хосты отсылают четыре пакета, чтобы не ждать симуляцию, я перевел лабораторную работу в режим реального времени и дождался когда команда завершит свою работу.
Пинг завершен
По итогу:
Мы более детально рассмотрели, как взаимодействуют отправители и получатели пакетов без участия транзитных узлов в случае, когда на канальном уровне работает Ethernet.
Поверхностно разобрались с тем, как связаны канальный и сетевой уровни.
И убедились, что функции отправителя и получателя может выполнять одно и то же устройство.
