Виды устройств в IP (хосты и роутеры). Часть 2
Господа, дамы, здравствуйте!
Продолжение поста о видах устройств в 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, а какой-то другой протокол?