Pull to refresh

36 этапов процесса маршрутизации

Reading time6 min
Views6.5K
Original author: Todd Lammle
Казалось бы, что может быть сложного в работе простой утилиты ping. Однако каждый раз, обнаружив,
что интернет по какой-то причине не работает, мы часто используем проверенный метод — пингуем какой-нибудь ресурс, например так:
ping mit.edu

Что же просходит в этот момент? В этом посте описан процесс, происходящий при попытке пропинговать узел, находящийся в другой сети, за маршрутизатором/маршрутизаторами.

image

Схема соединений:
ПК №1 Host_A (172.16.10.2/24) --> порт E0 (172.16.10.1) маршрутизатора Lab_A (2600 Router)
ПК №2 Host_B (172.16.20.2/24) --> порт E1 (172.16.20.1) маршрутизатора Lab_A (2600 Router)

В данном примере пользователь на Host_A используя утилиту ping проверяет на доступность
IP адрес компьютера Host_B.

1. На ПК №1 протокол ICMP создаёт echo запрос (алфавит в поле данных пакета).
2. ICMP передаёт запрос протоколу IP, который создаёт пакет. Минимально, в пакете содержится информация:
— IP адрес источника
— IP адрес получателя
— поле протокола 0x01
Вся эта информация говорит получателю куда он должен отправить ответ в случае удачного запроса-
в этом примере, ICMP.
3. Когда создан пакет, IP определяет находится ли хост с указанным IP адресом в локальной сети,
или в удалённой.
4. Определив, что адрес находится в удалённой сети, пакет должен быть отправлен на шлюз по умолчанию,
чтобы он мог достичь удалённой сети.
Происходит поиск в реестре сконфигурированного шлюза по умолчанию.
5. Шлюз по умолчанию для хоста Host_A(172.16.10.2) указан как 172.16.10.1.
Чтобы пакет был отправлен на шлюз по умолчанию, аппаратный адрес соответствующего порта маршрутизатора (Eth0 = 172.16.10.1) должен быть известен.
Зачем? Чтобы пакет мог быть передан далее, канальному уровню, вложен в фрейм,
и затем послан на интерфейс маршрутизатора, соединённый с сетью 172.16.10.0.
По причине, что компьютеры в локальной сети общаются только по аппаратным адресам,
необходимо установить, что для хоста Host_A для взаимодействия с Host_B, первый должен слать пакеты
по MAC адресу шлюза по умолчанию для своей локальной сети.
MAC адреса всегда используются локально в сети и НИКОГДА не передаются через маршрутизатор.
6. Следующим шагом, ARP кэш хоста проверяется, не была ли уже установлена связь между IP адресом и MAC адресом шлюза по умолчанию. Если соотвествие было найдено, пакет может передаваться далее на канальный уровень для упаковки во фрейм
(аппаратный адрес назначения также передаётся вместе с пакетом).
Для просмотра ARP кэша используйте команду: C:\>arp -a
Если аппаратный адрес отсутствует в ARP кэше, широковещательный ARP запрос выполняется в локальной сети с целью нахождения аппаратного адреса для 172.16.10.1.
Маршрутизатор отвечает на запрос и сообщает MAC адрес своего порта E0.
Затем ПК №1 сохраняет этот адрес в своём ARP кэше.
7. Когда аппаратные адреса источника пакета и назначения доставлены на канальный уровень, драйвер LAN используется, чтобы обеспечить доступ к среде передачи данных, используемой в конкретной технологии
(в примере, Ethernet).
Затем генерируется фрейм, инкапсулируя пакет, включая в него контрольную информацию.
Во фрейме содержатся: оба аппаратных адреса, плюс в данном примере поле Ether-Type,
которое описывает протокол сетевого уровня, который передал пакет на канальный уровень- в нашем случае, IP.
В конце фрейма содержится поле FCS (Frame Check Sequence),
которое содержит код CRC. Ниже приведена структура фрейма.

image

Обратите внимание! Фрейм не содержит MAC адрес Host_B.
8. После генерации фрейма, он будет отправлен далее, на физический уровень, для отправки по каналу передачи данных, например по витой паре, последовательно, бит за битом.
9. Каждое устройство в домене коллизии получает биты, восстанавливает фрейм.
Затем проверяет CRC, сравнивает ответ с полем FCS. Если ответ не совпадает, фрейм отбрасывается.
Если всё в порядке, то проверяется аппаратный адрес назначения (в нашем примере, порта E0 маршрутизатора).
Если и он совпадает, то проверяется поле Ether-Type для определения протокола сетевого уровня.
10. Пакет извлекается из фрейма, то что осталось от фрейма отбрасывается. Пакет передаётся протоколу, указанному в поле Ether-Type- в нашем случае IP.
11. IP получает пакет и проверяет IP адрес получателя. Так как IP адрес получателя не совпадает ни с одним из IP адресов сконфигурированных на маршрутизаторе интерфейсов, то маршрутизатор ищет IP адрес
сети назначения в своей таблице маршрутизации.
12. Таблица маршрутизации должна иметь запись для сети 172.16.20.0 иначе пакет будет немедленно отброшен, и ICMP сообщение "Destination network unreachable" будет отправлено устройству-
отправителю запроса.
13. Если соответствующая запись найдена в таблице маршрутизации, пакет перенаправляется на выходной интерфейс (E1).
Не требуются никакие протоколы маршрутизации, так как обе сети соединены напрямую.
Чтобы просмотреть таблицу
маршрутизации, введите в коммандной строке маршрутизатора команду show ip route
14. Маршрутизатор направляет пакет в буфер порта E1.
15. Буфер порта E1 должен знать аппаратный MAC адрес сетевой карты ПК №2 (Host_B) и сначала проверяет ARP кэш. Если MAC адрес известен, и содержится в ARP кэше, тогда пакет и аппаратный адрес передаются на канальный уровень для упаковки во фрейм. Для просмотра ARP кэша используйте команду show ip arp
Если аппаратный адрес отсутствует в ARP кэше, широковещательный ARP запрос выполняется в локальной сети с целью нахождения аппаратного адреса для 172.16.20.2. Host_B отвечает на запрос и сообщает свой MAC адрес. Затем маршрутизатор сохраняет этот адрес в своём ARP кэше, а пакет с адресом передаются на канальный уровень для упаковки во фрейм.
16. На канальном уровне создаётся фрейм с аппаратными адресами источника (E1) и получателя, полем Ether-Type и FCS.
После генерации фрейма, он будет отправлен далее, на физический уровень, для отправки по каналу передачи данных, например по витой паре, последовательно, бит за битом.
17. Host_B получает фрейм, запускает CRC. Если результат совпадает с FCS, проверяется MAC адрес получателя. Если проверка успешна, просматривается поле Ether-Type для определения протокола сетевого уровня, которому предназначен пакет, в нашем случае, IP.
18. На сетевом уровне: IP получает пакет и проверяет IP адрес получателя. Если найдено совпадение, просматривает поле Protocol для определения протокола- получателя запроса.
19. Запрос перенаправляется ICMP, ICMP «понимает» что это echo запрос, и отвечает на него немедленно, отбрасывая пакет и генерируя echo ответ.
20. Генерируется пакет, включающий в себя адреса источника и приёмника, поле Protocol и информационную часть. Получатель теперь- Host_A.
21. Когда создан пакет, IP определяет находится ли хост с указанным IP адресом в локальной сети, или в удалённой. Определив, что адрес находится в удалённой сети, пакет должен быть отправлен на шлюз по умолчанию, чтобы он мог достичь удалённой сети.
22. IP адрес шлюза по умолчанию берётся из базы ОС, затем просматривается ARP кэш на наличие соответствия между IP и аппаратным адресом.
23. Когда аппаратный адрес шлюза по умолчанию найден, аппаратные адреса источника и получателя (E1) передаются вместе с пакетом на канальный уровень для упаковки во фрейм.
24. На канальном уровне формируется фрейм со следующей информацией в заголовке: MAC адреса источника и получателя, поле Ether-Type (0x0800 (IP)), поле FCS с результатом CRC.
25. После генерации фрейма, он будет отправлен далее, на физический уровень, для отправки по каналу передачи данных, например по витой паре, последовательно, бит за битом.
26. Информация, последовательно, бит за битом, поступает на интерфейс E1 маршрутизатора. Затем восстанавливается фрейм. Запускается CRC, результат сравнивается с полем FCS.
27. В случае успешной проверки CRC проверяется аппаратный адрес приёмника. В случае совпадения пакет извлекается из фрейма, просматривается поле Ether-Type для определения какому протоколу сетевого уровня предназначался пакет.
28. Пакет предназначен для IP. IP проверяет заголовок на наличие ошибок, затем просматривает IP адрес получателя.
29. В нашем случае маршрутизатор «знает» путь к сети 172.16.10.0 — интерфейс E0, так что пакет перенаправляется на E0.
30. Маршрутизатор просматривает ARP кэш на наличие аппаратного адреса для 172.16.10.2.
31. Аппаратный адрес уже известен, он был выяснен во время отправки запроса по прямому каналу, таким образом аппаратные адреса и пакет передаются на канальный уровень.
32. На канальном уровне генерируется фрейм с аппаратными адресами источника и получателя, IP в поле Ether-Type и результатом CRC в FCS.
33. После генерации фрейма, он будет отправлен далее, на физический уровень, для отправки по каналу передачи данных, например по витой паре, последовательно, бит за битом.
34. ПК №1 получает фрейм, запускает CRC, проверяет аппаратный адрес получателя, просматривает поле Ether-Type для определения протокола- получателя пакета.
35. Получатель- IP. IP проверяет поле Protocol, находит инструкцию- передать информационное сообщение ICMP, он, в свою очередь определяет, что это- ответ на echo запрос (echo reply).
36. ICMP сигнализирует о получении ответа путём отправки знака ! в консоль.
Затем ICMP генерирует ещё 4 запроса.
С каждым новым маршрутизатором на пути прохождения пакета этапы повторяются, логика же остается неизменной.

Материал взят из самоучителя для подготовки к экзамену CCNA
Спасибо за внимание.

Tags:
Hubs:
+17
Comments14

Articles