Что происходит с первым эхо-запросом, когда маршрутизатор отвечает на запрос arp

Обновлено: 06.07.2024

Сетевые и системные администраторы хорошо разбираются в использовании утилиты ping для устранения неполадок, но куда обращаться, если ping не помогает?

Пинг хоста обычно является первым шагом в определении того, правильно ли хост подключен к сети. Если хост не отвечает на запрос проверки связи, обычно предполагается, что хост находится в автономном режиме.

Сегодня почти каждая организация использует брандмауэры для повышения безопасности. Брандмауэры могут быть настроены таким образом, что запросы протокола ICMP (Internet Control Message Protocol) блокируются, что означает, что традиционные эхо-запросы не работают. Настройка брандмауэра для блокировки ICMP-запросов основана на теории, что если потенциальный хакер не может «увидеть» цель, он не может атаковать хост.

Это усложняет администрирование системы и сети. Неудачный пинг больше не является действительным тестом — пользователь мог включить брандмауэр, который блокирует пинг, но хост все еще может работать. Прежде чем сетевой администратор сможет точно определить, не работает ли хост, пользователю необходимо отключить все приложения брандмауэра или, по крайней мере, отключить все правила, блокирующие ICMP, что, вероятно, потребует от обычного пользователя слишком многого.

ICMP и ARP

Если традиционные эхо-запросы на основе ICMP больше не надежны, если вы заранее не знаете, что брандмауэр не блокирует эхо-запросы ICMP, какие еще существуют варианты? Одним из вариантов является проверка связи на основе протокола разрешения адресов (ARP) с использованием утилиты arping.

Чтобы понять, почему эхо-запросы ARP практически гарантированно работают, а эхо-запросы ICMP — нет, нужно понять важность ARP в сети. ARP используется хостами в сети для преобразования IP-адресов в адреса управления доступом к среде (MAC), которые можно интерпретировать как уникальный серийный номер сетевого интерфейса. Хосты в сети Ethernet используют для связи MAC-адреса, а не IP-адреса.

Когда узел пытается установить соединение с другим узлом (в той же подсети), ему сначала необходимо получить MAC-адрес второго узла. В этом процессе узел A отправляет запрос ARP на широковещательный адрес подсети, к которой он подключен. Каждый хост в подсети получает эту широковещательную рассылку, а хост с рассматриваемым IP-адресом отправляет ответ ARP обратно на хост A со своим MAC-адресом. После получения ответа ARP от узла Б узел А может подключиться к узлу Б.

ARP необходим для правильной работы сети Ethernet, поэтому обычно он не блокируется брандмауэром. Если бы запросы ARP были заблокированы, ни один хост не смог бы «найти» компьютер в сети и подключиться к нему. Во всех смыслах система будет отключена от сети.

(Действительно существуют инструменты для фильтрации ARP. Проект ebtables предоставляет эти инструменты. Ebtables похож по функциональности и синтаксису на iptables, но в то время как iptables работает с протоколами TCP и UDP, ebtables работает с ARP.)

Одним из возможных недостатков этой системы использования ARP для проверки связи с хостом является то, что протокол ARP не является протоколом маршрутизации. Если вы не находитесь в той же подсети, что и хост, к которому вы пытаетесь подключиться, то этот метод не будет работать без предварительного присоединения к этой подсети, что может быть физически возможно, а может и нет. Таким образом, отправляя запрос ARP, а не эхо ICMP, вы практически гарантированно получите ответ.

Давайте рассмотрим наиболее удобные способы получения ответов ARP.

ARP-таблица

При попытке пропинговать IP-адрес одновременно отправляется запрос ARP. Ваш брандмауэр может блокировать эхо ICMP, но есть вероятность, что компьютер получит ответ ARP. Таблица ARP вашего компьютера будет содержать IP-адрес и MAC-адрес хоста, к которому вы пытаетесь подключиться.

Давайте рассмотрим некоторые способы просмотра таблиц ARP. Первый вариант — использовать команду ip Neighbor:


gerard@garion:~$ ip сосед | grep 192.168.1.100
192.168.1.100 dev eth0 lladdr 00:40:05:01:fc:1e nud доступен

Используемая здесь утилита ip является частью относительно нового пакета iproute2, предназначенного для замены традиционных утилит, таких как ifconfig , route и arp . Если в вашей системе Linux не установлен iproute2, вы можете использовать arp вместо ip Neighbor.

В этом примере IP-адрес имеет MAC-адрес (lladdr) и обнаружение недоступности соседей (nud) в ARP-таблице. Это означает, что хост, принадлежащий IP-адресу 192.168.1.100, находится в сети и активен, но явно блокирует эхо-запросы ICMP.

Если бы этот хост действительно был в автономном режиме, выходные данные команды ip Neighbor были бы примерно такими:


gerard@garion:~$ ip сосед | grep 192.168.1.101
192.168.1.101 dev eth0 nud не удалось

Отсутствие ошибки означает отсутствие ответа ARP после отправки запроса ARP для поиска этого хоста.

Эфириал и tcpdump

Другой подход заключается в использовании утилит tcpdump и Ethereal для просмотра сетевого трафика в реальном времени, включая запросы и ответы ARP.

Если вы используете обычную команду ping для IP-адреса 192.168.1.100 и запускаете команду tcpdump -n или Ethereal, вы увидите примерно такой результат:


12:28:59.632396 arp who-has 192.168.1.100 Tell 192.168.1.1
12:28:59.632592 arp ответ 192.168.1.100 is-at 00:40:05:01:fc: 1е

Первая строка показывает, что 192.168.1.1 пытается найти 192.168.1.100. Вторая строка показывает, что хост отвечает своим MAC-адресом. Этот хост определенно находится в сети, даже несмотря на то, что он блокирует эхо-сообщения ICMP.

Одновременный запуск двух таких программ может быть немного громоздким. Здесь на помощь приходит программа arping.

арпинг

Программа Arping работает как традиционная команда ping. Вы даете ему IP-адрес для проверки связи, и arping отправляет правильный запрос ARP. Затем Arping прослушивает ответы ARP и распечатывает их (если есть), включая время ответа ping:

Этот инструмент позволяет быстро и легко пинговать хосты. Вам больше не нужно запускать дополнительные инструменты для просмотра таблицы ARP или других ответов ARP.

Еще одно полезное применение arping — возможность определить, настроено ли несколько хостов на использование одного и того же IP-адреса:

Здесь две машины отвечают на запросы одного и того же IP-адреса, что может привести к самым разным проблемам.

Эхо-запрос ARP может быть полезной заменой эхо-запроса ICMP в сетях Ethernet. С его помощью вы можете с уверенностью исключить брандмауэры из уравнения и знать, что неудачный пинг ARP указывает на реальную проблему, которую необходимо изучить.

Эта статья является частью серии статей о протоколе разрешения адресов (ARP). Используйте поля навигации для просмотра остальных статей.

Как мы узнали ранее, протокол разрешения адресов (ARP) — это процесс, посредством которого известный адрес L3 сопоставляется с неизвестным адресом L2. Целью создания такого сопоставления является правильное заполнение заголовка пакета L2 для доставки пакета к следующему сетевому адаптеру на пути между двумя конечными точками.

«Следующая сетевая карта» в пути станет целью запроса ARP.

Если хост взаимодействует с другим хостом в той же IP-сети, целью запроса ARP является IP-адрес другого хоста. Если хост взаимодействует с другим хостом в другой IP-сети, целью запроса ARP будет IP-адрес шлюза по умолчанию.

Точно так же, если маршрутизатор доставляет пакет на узел назначения, целевым ARP-адресом маршрутизатора будет IP-адрес узла. Если маршрутизатор доставляет пакет следующему маршрутизатору на пути к хосту, целью ARP будет IP-адрес интерфейса другого маршрутизатора, как указано соответствующей записью в таблице маршрутизации.

Процесс ARP

Само разрешение адреса представляет собой двухэтапный процесс: запрос и ответ.

Все начинается с того, что инициатор отправляет запрос ARP в виде широковещательного кадра по всей сети. Этот запрос должен быть широковещательным, поскольку в этот момент инициатор не знает MAC-адрес цели и, следовательно, не может отправить одноадресный кадр цели.

Поскольку это была широковещательная рассылка, все узлы в сети получат запрос ARP. Все узлы рассмотрят содержимое запроса ARP, чтобы определить, являются ли они предполагаемой целью. Узлы, которые не являются предполагаемой целью, будут молча отбрасывать пакет.

Узел, который является целью запроса ARP, затем отправит ответ ARP исходному отправителю. Поскольку цель знает, кто отправил первоначальный ARP-запрос, она может отправить одноадресную рассылку ARP-ответа непосредственно обратно инициатору.

Весь процесс показан на этой анимации:

Обратите внимание, что запрос ARP включает MAC-адрес отправителя. Именно это позволяет цели (в данном случае хосту B) напрямую отвечать инициатору (хосту A).

Теперь, когда вы понимаете общий процесс, давайте более подробно рассмотрим содержимое пакетов ARP Request и ARP Response между узлами A и узлами B.

ARP-запрос

Запрос ARP — это полезная нагрузка ARP, передаваемая в соответствующем кадре L2 для используемого носителя. В большинстве случаев это будет Ethernet, который также будет средой L2, которую мы будем рассматривать в наших примерах.

Заголовок Ethernet будет содержать три поля: MAC-адрес назначения, MAC-адрес источника и EtherType.

 Pracnet.net — запрос ARP — заголовок Ethernet» width=

Обратите внимание, что пунктом назначения уровня 2 является ffff.ffff.ffff , это специальный зарезервированный MAC-адрес, указывающий на широковещательный кадр. Это делает запрос ARP широковещательным.Если бы узел A решил отправить этот кадр, используя MAC-адрес определенного узла в пункте назначения, то запрос ARP был бы одноадресным.

MAC-адрес источника, что неудивительно, является MAC-адресом нашего отправителя — хоста A.

EtherType содержит шестнадцатеричное значение 0x0806, которое является зарезервированным EtherType для пакетов разрешения адресов.

Этот конкретный заголовок Ethernet также содержит некоторые дополнения. Размер полей Destination/Source/Type составляет 14 байтов, размер последующей полезной нагрузки ARP (изображенной ниже) составляет 28 байтов, а размер завершающей FCS (не изображенной) составляет 4 байта. Это означает, что необходимо добавить дополнительные 18 байтов заполнения, чтобы гарантировать, что этот фрейм достигает минимально допустимой длины 64 байта.

Сама полезная нагрузка ARP имеет несколько полей, которые стоит обсудить.

Pracnet. net - ARP-запрос - ARP-пакет

Поля «Тип оборудования» и «Тип протокола» указывают, какой тип адресов сопоставляется друг с другом. В этом случае мы сопоставляем адрес Ethernet (MAC-адрес) с адресом IPv4.

Размер оборудования и размер протокола относятся к количеству байтов в каждом из вышеупомянутых типов адресов: MAC-адрес составляет 6 байтов (или 48 бит), а адрес IPv4 — 4 байта (или 32 бита).< /p>

Код операции указывает, какой это тип пакета ARP. На самом деле вы увидите только два значения. Значение 1 указывает, что этот ARP-пакет является запросом, а значение 2 указывает, что этот ARP-пакет является ответом (см. следующий раздел).

И наконец, есть два набора MAC-адресов и IP-адресов, которые составляют основу полезной нагрузки ARP.

MAC-адрес отправителя и IP-адрес отправителя, что неудивительно, являются MAC-адресом и IP-адресом инициатора запроса ARP. В данном случае это адреса для хоста А. Поскольку запрос включает MAC-адрес хоста А, ответ может быть отправлен непосредственно обратно на хост А без необходимости широковещательной рассылки.

Целевой MAC-адрес и целевой IP-адрес относятся к предполагаемой цели запроса ARP — в данном случае к узлу B. Обратите внимание, что целевой IP-адрес заполнен ( 10.0.0.22 ), но целевой MAC-адрес полностью равен нулю. Поскольку хост А не знает MAC-адрес хоста Б, хост А может только заполнить поле IP-адрес и оставить поле MAC-адрес, по существу, пустым.

Обратите внимание, что хост B называется целью, а не назначением. Это важное различие.

Назначением запроса ARP был широковещательный MAC-адрес ( ffff.ffff.ffff ). Запрос ARP существовал с целью разрешения MAC-адреса хоста Б, поэтому целью является хост Б.

Считайте, что цель означает тему диалога ARP. Это облегчит понимание того, что происходит, когда мы будем обсуждать Proxy ARP и Gratuitous ARP в следующих статьях этой серии.

ARP-ответ

Ответ ARP имеет очень похожую структуру пакета. Мы снова рассмотрим сначала заголовок Ethernet, а затем полезную нагрузку ARP.

 Pracnet.net - Ответ ARP - Заголовок Ethernet

Заголовок Ethernet состоит из тех же трех частей: MAC-адреса назначения, MAC-адреса источника и EtherType.

MAC-адрес назначения — это хост A — первоначальный запросчик, а MAC-адрес источника — это хост B — первоначальная цель. Обратите внимание, что фрейм адресован непосредственно хосту А — это то, что делает ответ одноадресным.

EtherType снова содержит шестнадцатеричное значение 0x0806, указывающее на пакет ARP. Кроме того, такое же количество дополнений включено в ответ ARP, так как размер кадра Ethernet и ответа ARP такой же, как и у запроса ARP.

Полезная нагрузка ответа ARP содержит те же поля, что и запрос выше.

Pracnet. net - ответ ARP - пакет ARP

Тип оборудования и размер оборудования указывают на адрес Ethernet (или MAC), который составляет 6 байт (48 бит).

Тип протокола и размер протокола указывают на адрес IPv4 размером 4 байта (32 бита).

Основное различие между запросом и ответом заключается в поле кода операции. В ответе ARP это поле содержит значение 2 .

MAC-адрес отправителя и IP-адрес отправителя включают в себя адреса для узла B, который ожидается, если узел B отправил ответ ARP.

Целевой MAC-адрес и целевой IP-адрес включают адреса для узла А, так как он является целью ответа ARP.

Здесь можно загрузить перехваченный пакет ARP-диалога выше. Его можно изучить с помощью Wireshark.

Время ARP

По завершении процесса ARP полученная информация сохраняется в таблице ARP или в кэше ARP. Каждое устройство, имеющее IP-адрес, ведет такую ​​таблицу. Срок действия записей в этой таблице истекает через определенное время.

Обычно для клиентов и конечных узлов время ожидания ARP будет довольно коротким — обычно 60 секунд или меньше. Причина этого находится на уровне клиента, происходит много мобильности и перемещений, и вы не хотите кэшировать запись ARP в течение очень долгого времени.

В то время как для устройств сетевой инфраструктуры (маршрутизаторы, брандмауэры и т. д.) время ожидания ARP очень велико — обычно 2–4 часа. Причина этого находится на уровне инфраструктуры, узлы, присоединяющиеся к сети и покидающие ее, должны оставаться довольно согласованными. Маршрутизатор добавляется в сеть при ее первоначальном построении, а затем иногда по мере масштабирования сети. В то время как хосты будут добавляться и удаляться из вашей сети каждый день.

Конечно, маршрутизатор не может узнать, является ли запись в его ARP-кэше хостом или другим устройством инфраструктуры. Вместо этого, чтобы не отставать от мобильности клиентов, кэш маршрутизатора обновляется всякий раз, когда он получает запрос ARP.

Иными словами, если хост обновляет сопоставление ARP своего шлюза по умолчанию каждые 30~ секунд из-за более короткого времени ARP хоста, сопоставление ARP шлюза по умолчанию того же хоста также будет обновляться каждые 30 секунд.

Существуют и другие стратегии, которые служат для поддержания соответствия ARP в актуальном состоянии. Мы рассмотрим их в следующих статьях этой серии.

Введение

В этом лабораторном задании вы будете писать простой маршрутизатор со статической таблицей маршрутизации. Вам будут переданы необработанные кадры Ethernet и предоставлена ​​функция, которая может отправлять необработанные кадры Ethernet. Вам решать, как придумать логику пересылки между получением кадра и потенциальной отправкой его через другой интерфейс.


Если маршрутизатор работает правильно, все следующие операции должны работать:

Дополнительные требования изложены в разделе «Требования».

Система виртуальной сети

Это задание выполняется поверх виртуальной сетевой системы, созданной в Стэнфорде. VNS позволяет создавать виртуальные сетевые топологии, состоящие из узлов, работающих с реальными кадрами Ethernet. Вот почему ваш узел маршрутизатора может обрабатывать и отправлять настоящие кадры Ethernet и отправлять их по сети, как настоящий маршрутизатор.

Для выполнения этого задания вам не обязательно знать, как работает VNS, но дополнительную информацию о VNS (если вам интересно) можно найти здесь.

Начало работы

Создание топологии

Первое, что вам нужно сделать, это получить топологию тестирования, подобную той, что показана на схеме. Мы предоставили вам тестовые топологии, доступные из /usr/class/cs144/lab3_10au/student_auths/ /auth_key

Скопируйте ключ auth_key в каталог назначения и следуйте инструкциям в ИНСТРУКЦИЯХ, чтобы настроить файл таблицы маршрутизации, rtable.vrhost. Примечание. Вы должны указать rtable.vrhost в первый раз, чтобы получить файл таблицы маршрутизации для вашей топологии. Вы можете указать другие файлы таблицы маршрутизации, если хотите, чтобы ваш маршрутизатор использовал настроенный файл таблицы маршрутизации.

Скачивание стартового кода

Загрузить и разархивировать пакет заданий

У вас должна быть возможность собрать маршрутизатор из коробки.

Знакомство с файлом таблицы маршрутизации

Вы заметите, что после запуска начального кода у вас будет простой файл таблицы маршрутизации, rtable.vrhost. Файл rtable имеет формат:

префикс интерфейса сетевой маски next_hop

В базовом файле rtable указан только маршрут по умолчанию к брандмауэру. Например, таблица маршрутизации для маршрутизатора в образце топологии во введении выглядит следующим образом:

0.0.0.0 172.24.74.11 0.0.0.0.0 eth0
192.168.128.204 192.168.128.204 192.168.128.204 255.255.2552.255 ETH1
192.168.128.206 192.168.128.206 255.255.255.255 ETH2

Создание и запуск

Теперь у вас должны быть все компоненты, необходимые для сборки и запуска маршрутизатора:

  • Ваш ключ_auth_key для доступа к вашей топологии VNS.
  • Файл таблицы маршрутизации, соответствующий таблице маршрутизации для узла маршрутизатора в этой топологии, который мы назовем rtable.vrhost
  • .
  • Стартовый код

Затем вы можете собрать и запустить начальный код:

Примечание. В настоящее время вы можете запускать двоичный файл sr только на мифических машинах. Если вы попытаетесь запустить sr на pod, вы не сможете подключиться к серверам VNS. Кроме того, вам придется выполнять ping и traceroute со станфордских машин. Вы можете сделать это, просто подключившись к мифу по ssh и запустив команду ping или traceroute с одной из этих машин.

С другого терминала или другого мифа попробуйте пропинговать один из интерфейсов маршрутизатора. В настоящее время все, что делает начальный код, — это вывод пакета в командную строку.

Например, при запуске начального кода в топологии и проверке связи интерфейса на маршрутизаторе с другого терминала мы получаем следующий вывод:

> ./sr -u bmistree -T '1-маршрутизатор 2-сервер' -s vns-2.stanford.edu -r rtable.vrhost
Использование кода заглушки VNS sr пересмотрено в 2009-10 -14 (rev 0.20)
Клиент bmistree подключается к серверу vns-2.stanford.edu:3250
Запрашивает шаблон топологии 1-маршрутизатор 2-сервер
успешно аутентифицирован как bmistree
подключен к новому экземпляру шаблона топологии 1-маршрутизатор 2-сервер
Загрузка таблицы маршрутизации
--------------------------- ------------------
Маска шлюза назначения Iface
0.0.0.0 172.24.74.11 0.0.0.0 eth0
192.168.128.204 192.168.128.204 255.255.255.255 eth1
192.168.128.206 192.168.128.206 255.255.255.255 eth2
------------------------------------------- ------------------
Интерфейсы маршрутизатора:
eth0 HWaddr70:00:17:db:00:02
inet addr 192.168.128.203 < br />eth1 HWaddr70:00:17:db:00:04
inet addr 192.168.128.205
eth2 HWaddr70:00:17:db:00:06
inet addr 192.168.128.207 < бр />

*** -> Принят пакет длиной 42
*** -> Принят пакет длиной 42
*** -> Принят пакет длиной 42
.
.
.

Запись пакетов

Вы найдете весьма полезным для отладки ошибок использовать инструмент проверки пакетов, такой как Wireshark, tcpdump или JEthereal. Вы можете сохранять пакеты в файл журнала пакетов, используя параметр -l:

Wireshark

Оттуда вы можете использовать Wireshark, графический инструмент проверки пакетов, чтобы открыть файл журнала. Мы постараемся установить для вас двоичный файл Wireshark (на рассмотрении).

Кроме того, вы можете установить Wireshark локально и запустить его на своем компьютере, чтобы просмотреть журнал пакетов.

Эфирный

tcpdump

Вы также можете использовать tcpdump из командной строки для проверки журнала пакетов:

Переключатель -r указывает tcpdump, где искать файл журнала. -e указывает tcpdump печатать заголовки пакетов, а не только их полезную нагрузку. -vvv делает вывод очень подробным, а -x помещает пакеты в шестнадцатеричный формат, который обычно легче читать, чем ASCII. Вы можете указать параметр -xx вместо -x, чтобы также распечатать заголовок уровня канала (Ethernet) в шестнадцатеричном формате.

Общая логика переадресации

Для начала следует краткое описание логики переадресации для маршрутизатора, хотя оно не содержит всех подробностей. Это задание состоит из двух основных частей: обработка ARP и IP-переадресации

.

Переадресация IP

Учитывая необработанный кадр Ethernet, если кадр содержит IP-пакет, который не предназначен для одного из наших интерфейсов:

  1. Проверьте правильность пакета (соответствует минимальной длине и имеет правильную контрольную сумму).
  2. Уменьшите TTL на 1 и пересчитайте контрольную сумму пакета по измененному заголовку.
  3. Узнайте, какая запись в таблице маршрутизации имеет самый длинный префикс, совпадающий с IP-адресом назначения.
  4. Проверьте кэш ARP на наличие MAC-адреса следующего перехода, соответствующего IP-адресу следующего перехода. Если есть, пришлите. В противном случае отправьте запрос ARP для IP-адреса следующего перехода (если он не был отправлен в течение последней секунды) и добавьте пакет в очередь пакетов, ожидающих этого запроса ARP.

Очевидно, что это очень упрощенная версия процесса переадресации, за которой следуют низкоуровневые детали. Например, если на каком-либо из вышеперечисленных шагов возникает ошибка, вам придется отправить обратно отправителю ICMP-сообщение, уведомляющее его об ошибке. Вы также можете получить запрос или ответ ARP, который должен корректно взаимодействовать с кэшем ARP.

Протоколы для понимания

Интернет

Вам предоставляется необработанный кадр Ethernet, и вы должны отправить необработанные кадры Ethernet. Вы должны понимать MAC-адреса источника и получателя и идею о том, что мы пересылаем пакет через один переход, изменяя MAC-адрес назначения пересылаемого пакета на MAC-адрес входящего интерфейса следующего перехода.

Интернет-протокол

Перед операцией с IP-пакетом необходимо проверить его контрольную сумму и убедиться, что она соответствует минимальной длине IP-пакета. Вы должны понимать, как найти самое длинное совпадение префикса IP-адреса назначения в таблице маршрутизации, как описано в разделе 2. Если вы определили, что дейтаграмма должна быть перенаправлена, вы должны правильно уменьшить поле TTL заголовка и пересчитать контрольную сумму. над измененным заголовком, прежде чем пересылать его на следующий переход.

Протокол контрольных сообщений Интернета

ICMP – это простой протокол, который может отправлять управляющую информацию на хост. В этом задании ваш маршрутизатор будет использовать ICMP для отправки сообщений обратно на отправляющий хост.Вам потребуется правильно сгенерировать следующие сообщения ICMP (включая контрольную сумму заголовка ICMP) в ответ на отправляющий хост при следующих условиях:

  • Эхо-ответ (тип 0)
    Отправляется в ответ на эхо-запрос (ping) на один из интерфейсов маршрутизатора. (Это только для эхо-запросов к любому из IP-адресов маршрутизатора. Эхо-запрос, отправленный в другое место, должен быть перенаправлен на адрес следующего перехода, как обычно.)
  • Пункт назначения недоступен (тип 3, код 0)
    Отправляется, если существует несуществующий маршрут к IP-адресу назначения (нет соответствующей записи в таблице маршрутизации при пересылке IP-пакета).
  • Хост назначения недоступен (тип 3, код 1)
    Отправляется, если пять запросов ARP были отправлены на IP-адрес следующего перехода без ответа.
  • Порт недоступен (тип 3, код 3)
    Отправляется, если IP-пакет, содержащий полезные данные UDP или TCP, отправляется на один из интерфейсов маршрутизатора. Это необходимо для работы traceroute.
  • Превышено время (тип 11, код 0)
    Отправляется, если IP-пакет отбрасывается во время обработки, так как поле TTL равно 0. Это также необходимо для работы traceroute.

Адрес источника сообщения ICMP может быть адресом источника любого из входящих интерфейсов, как указано в RFC 792.

Как упоминалось выше, единственное входящее сообщение ICMP, предназначенное для IP-адресов маршрутизатора, которое вы должны явно обрабатывать, — это эхо-запросы ICMP.

Возможно, вы захотите создать дополнительные структуры для сообщений ICMP для удобства, но не забудьте использовать упакованный атрибут, чтобы компилятор не пытался выровнять поля в структуре по границам слов:

Протокол разрешения адресов

ARP необходим для определения MAC-адреса следующего перехода, который соответствует IP-адресу следующего перехода, хранящемуся в таблице маршрутизации. Без возможности генерировать запрос ARP и обрабатывать ответы ARP ваш маршрутизатор не сможет заполнить поле MAC-адреса назначения в необработанном кадре Ethernet, который вы отправляете через исходящий интерфейс. Аналогично, без возможности обрабатывать запросы ARP и генерировать ответы ARP ни один другой маршрутизатор не может отправлять кадры Ethernet вашего маршрутизатора. Поэтому ваш маршрутизатор должен генерировать и обрабатывать запросы и ответы ARP.

Чтобы уменьшить количество отправляемых запросов ARP, необходимо кэшировать ответы ARP. Записи кэша должны истечь через 15 секунд, чтобы свести к минимуму устаревание. Предоставленный класс кэша ARP уже определяет время записи для вас.

При пересылке пакета на IP-адрес следующего перехода маршрутизатор должен сначала проверить кэш ARP на наличие соответствующего MAC-адреса перед отправкой запроса ARP. В случае промаха кеша запрос ARP должен отправляться на целевой IP-адрес примерно раз в секунду, пока не придет ответ. Если запрос ARP отправляется пять раз без ответа, узел назначения ICMP недоступен исходный IP-адрес, как указано выше. Предоставленная очередь запросов ARP поможет вам управлять очередью запросов.

В случае запроса ARP вы должны отправлять ответ ARP только в том случае, если целевой IP-адрес является одним из IP-адресов вашего маршрутизатора. В случае ответа ARP вы должны кэшировать запись только в том случае, если целевой IP-адрес является одним из IP-адресов вашего маршрутизатора.

Обратите внимание, что запросы ARP отправляются на широковещательный MAC-адрес (ff-ff-ff-ff-ff-ff). Ответы ARP отправляются непосредственно на MAC-адрес отправителя запроса.

Назначения IP-пакетов

Входящий IP-пакет может быть направлен на один из IP-адресов вашего маршрутизатора или на другой адрес. Если он отправляется на один из IP-адресов вашего маршрутизатора, вам следует предпринять следующие действия в соответствии с разделом о протоколах выше:

  • Если пакет представляет собой эхо-запрос ICMP и его контрольная сумма верна, отправьте эхо-ответ ICMP на хост-отправитель.
  • Если пакет содержит полезную нагрузку TCP или UDP, отправьте ICMP-порт, недоступный отправляющему хосту.
  • В противном случае пакет игнорируется.

Пакеты, отправленные в другое место, должны пересылаться с использованием обычной логики пересылки.

Обзор кода

Основные функции

void sr_handlepacket(struct sr_instance* sr, uint8_t * package, unsigned int len, char* interface)

Этот метод, расположенный в sr_router.c, вызывается маршрутизатором каждый раз при получении пакета. Аргумент «пакет» указывает на буфер пакетов, который содержит полный пакет, включая заголовок Ethernet. Имя принимающего интерфейса также передается в метод.

int sr_send_packet(struct sr_instance* sr, uint8_t* buf, unsigned int len, const char* iface)

Этот метод, расположенный в sr_vns_comm.c, отправит произвольный пакет длины len в сеть через интерфейс, указанный в iface.

Вы не должны освобождать буфер, предоставленный вам в sr_handlepacket (поэтому в комментариях буфер помечен как "предоставленный вам").Вы несете ответственность за правильное управление памятью для буферов, которые sr_send_packet заимствует у вас (то есть sr_send_packet не будет вызывать free для буферов, которые вы ему передаете).

void sr_arpcache_sweepreqs(struct sr_instance *sr)

Назначение требует, чтобы вы отправляли запрос ARP примерно раз в секунду, пока не придет ответ или мы не отправим пять запросов. Эта функция определена в sr_arpcache.c и вызывается каждую секунду, и вы должны добавить код, который перебирает очередь запросов ARP и повторно отправляет все невыполненные запросы ARP, которые не были отправлены в последнюю секунду. Если запрос ARP был отправлен 5 раз без ответа, недостижимый узел назначения должен вернуться ко всем отправителям пакетов, которые ожидали ответа на этот запрос ARP.

Структуры данных

Маршрутизатор (sr_router.h):

Полный контекст маршрутизатора содержится в структуре sr_instance (sr_router.h). sr_instance содержит информацию о топологии, для которой маршрутизируется маршрутизатор, а также таблицу маршрутизации и список интерфейсов.

Интерфейсы (sr_if.c/h):

После подключения сервер отправит клиенту информацию об оборудовании для этого хоста. Код-заглушка использует это для создания связанного списка интерфейсов в экземпляре маршрутизатора в элементе if_list. Утилиты для обработки списка интерфейсов можно найти по адресу sr_if.c/h.

Таблица маршрутизации (sr_rt.c/h):

Таблица маршрутизации в коде-заглушке считывается из файла (имя файла по умолчанию "rtable", можно задать с помощью параметра командной строки -r ) и сохраняется в связанном списке записей маршрутизации в текущем экземпляре маршрутизации (элемент routing_table ).

Кэш ARP и очередь запросов ARP (sr_arpcache.c/h):

Вам потребуется добавить запросы ARP и пакеты, ожидающие ответов на эти запросы ARP, в очередь запросов ARP. Когда приходит ответ ARP, вам придется удалить запрос ARP из очереди и поместить его в кэш ARP, перенаправляя все пакеты, которые ожидали этого запроса ARP. Псевдокод для этих операций указан в sr_arpcache.h.

Базовый код уже создает поток, который истечет время ожидания записей кэша ARP через 15 секунд после их добавления для вас.

Вы должны заполнить функцию sr_arpcache_sweepreqs в sr_arpcache.c, которая вызывается каждую секунду для итерации по очереди запросов ARP и повторной отправки запросов ARP, если это необходимо. Псевдокод для этого предоставлен в sr_arpcache.h.

Заголовки протокола (sr_protocol.h)

В структуре маршрутизатора вы будете иметь дело непосредственно с необработанными пакетами Ethernet. Сам код-заглушка предоставляет некоторые структуры данных в sr_protocols.h, которые вы можете использовать для простого управления заголовками.

Существует ряд ресурсов, подробно описывающих заголовки протоколов. Справочник RFC от Network Sorcery содержит краткий справочник форматов пакетов, с которыми вам предстоит иметь дело:

Что касается фактических спецификаций, существуют также RFC для ARP (RFC826), IP (RFC791) и ICMP (RFC792).

Функции отладки

Мы предоставили вам некоторые основные функции отладки в файлах sr_utils.h, sr_utils.c. Не стесняйтесь использовать их для распечатки информации заголовка сети из ваших пакетов.

Ниже приведены некоторые функции, которые могут оказаться полезными:

  • printAllHeaders(uint8_t *buf, uint32_t length) — распечатывает все возможные заголовки, начиная с заголовка Ethernet в пакете
  • printIPFromInt(uint32_t ip) — выводит отформатированный IP-адрес из uint32_t. Убедитесь, что вы передаете IP-адрес в правильном порядке байтов.

Пожалуйста, ознакомьтесь с часто задаваемыми вопросами, прежде чем задавать вопрос в группе новостей.

Продолжительность назначения

Это задание значительно сложнее первых двух лабораторных работ, поэтому приступайте к работе заранее.

В наше эталонное решение мы добавили 520 строк C, включая пробелы и комментарии:

Конечно, для вашего решения может потребоваться меньше или больше строк кода, но это дает вам приблизительное представление о размере задания в первом приближении.

Исходный двоичный файл

Вот пример запуска эталонного маршрутизатора в топологии, использующей файл таблицы маршрутизации "rtable.vrhost" в текущем рабочем каталоге:

/usr/class/cs144/bin/sr_ref -u bmistree -T '1-маршрутизатор 2-сервер' -s vns-2.stanford.edu -r rtable.vrhost

Замените правильные значения для своего идентификатора SUNET при запуске эталонного маршрутизатора. Вы можете запустить его, чтобы помочь вам:

  • Проверьте свои таблицы маршрутизации
  • Узнайте, как параметры командной строки sr работают с VNS.
  • Понимание необходимых функций

Необходимая функциональность

  • Маршрутизатор может успешно маршрутизировать пакеты между брандмауэром и серверами приложений.
  • Маршрутизатор правильно обрабатывает запросы и ответы ARP.
  • Маршрутизатор правильно обрабатывает маршруты трассировки через себя (где он не является конечным хостом) и к нему (где он является конечным хостом).
  • Маршрутизатор правильно отвечает на эхо-запросы ICMP.
  • Маршрутизатор обрабатывает пакеты TCP/UDP, отправленные на один из его интерфейсов. В этом случае маршрутизатор должен ответить, что порт ICMP недоступен.
  • Маршрутизатор поддерживает кэш ARP, записи которого становятся недействительными по истечении времени ожидания (время ожидания должно быть порядка 15 секунд).
  • Маршрутизатор ставит в очередь все пакеты, ожидающие ответа ARP. Если узел не отвечает на 5 запросов ARP, поставленный в очередь пакет отбрасывается, а обратно источнику поставленного в очередь пакета отправляется сообщение ICMP о недоступности узла.
  • Маршрутизатор не отбрасывает пакеты без необходимости (например, при ожидании ответа ARP)
  • Маршрутизатор применяет гарантии в отношении тайм-аутов, т. е. если на запрос ARP не поступает ответ в течение фиксированного периода времени, генерируется сообщение ICMP о недоступности хоста, даже если на маршрутизатор больше не поступают пакеты. Вы можете гарантировать это, правильно реализовав функцию sr_arpcache_sweepreqs в sr_arpcache.c.

Отправка

Создайте файл README, указав свой идентификатор SUNET (сетевой логин) и любое описание/обзор вашей реализации, которое вы считаете уместным.

Чтобы отправить, запустите из каталога вашего проекта и отправьте полученный архив на странице отправки.

Правила сотрудничества

Вы должны написать весь код, который вы передаете для заданий по программированию, за исключением кода, который мы даем вам как часть задания. Вам не разрешено смотреть чужое решение (и вам не разрешено смотреть решения прошлых лет). Вы можете обсуждать задания с другими учащимися, но не можете просматривать или копировать код друг друга.

В этом лабораторном задании вы напишете простой маршрутизатор со статической таблицей маршрутизации. Мы будем вводить необработанные кадры Ethernet в ваш код, и вы можете вызывать существующие функции для отправки кадров Ethernet; однако ваша задача — реализовать логику пересылки между получением кадра и его отправкой через другой интерфейс.


Рисунок 1: пример топологии

  • Эхо-запрос на любой из интерфейсов маршрутизатора
  • Эхо-запрос на любой из серверов приложений
  • Загрузка файла по протоколу HTTP с одного из серверов приложений. Файл должен содержать «Веб-сайт сервера приложений VNS», если вы пытаетесь подключиться либо к app1, либо к app2. На этой странице также есть несколько тестовых примеров. Ваш веб-браузер должен показывать эту страницу, если все работает.

Это лабораторное занятие выполняется поверх Стэнфордской виртуальной сетевой системы. VNS позволяет создавать виртуальные сетевые топологии, состоящие из узлов, работающих с реальными кадрами Ethernet. Вам не обязательно знать, как работает VNS, чтобы выполнить это задание.

Начало работы

Вы должны быть в состоянии выполнить задание на любом компьютере в Linux-кластере отдела: linux.cs.duke.edu. Если вы предпочитаете выполнять задание на своем компьютере, вы можете загрузить и установить Ubuntu. Вы можете запустить Ubuntu на виртуальной машине, такой как бесплатная VirtualBox. Мы не поддерживаем MAC или Windows. Извините.

Прежде всего, подключитесь по ssh к своему домашнему каталогу на исследовательском компьютере, используя назначенное имя пользователя и свой пароль.

Вы найдете маршрутизатор каталогов. Он содержит все файлы, необходимые для этой лабораторной работы. Постарайтесь сделать резервную копию этого каталога, чтобы в следующий раз вам не пришлось копировать все с веб-сайта курса. Вы можете использовать scp здесь.

Обратите внимание, что вы можете запускать свой код маршрутизатора на любом текущем компьютере с Linux. В следующих примерах мы будем использовать linux21; за исключением особых случаев, требующих доступа к pcap, мы будем использовать cps114.nicl.

Вот пример файла rtable для топологии на рис. 1. Базовый файл rtable имеет только маршрут по умолчанию к брандмауэру.

Затем вы можете создать и запустить код назначения (TOPOLOGY_ID находится в файле topology):

С другого терминала или другой машины попробуйте пропинговать один из интерфейсов маршрутизатора. В настоящее время все, что делает код присваивания, — это вывод пакета в командную строку.

Понимание кода

Структура данных

sr_router.[h|c]: полный контекст маршрутизатора содержится в структуре sr_instance (sr_router.h). sr_instance содержит информацию о топологии, для которой маршрутизируется маршрутизатор, а также таблицу маршрутизации и список интерфейсов.

sr_if.[h|c]: после подключения сервер отправит клиенту информацию об оборудовании для этого хоста. Код назначения использует это для создания связанного списка интерфейсов в экземпляре маршрутизатора в элементе if_list. Утилиты для обработки списка интерфейсов можно найти по адресу sr_if.[h|c].

sr_rt.[h|c]: таблица маршрутизации в коде-заглушке считывается из файла (имя файла по умолчанию «rtable», можно задать с помощью параметра командной строки -r) и сохраняется в связанном списке записей маршрутизации в текущем экземпляре маршрутизации. .

sr_arpcache.[h|c]: вам потребуется добавить запросы ARP и пакеты, ожидающие ответов на эти запросы ARP, в очередь запросов ARP. Когда приходит ответ ARP, вам придется удалить запрос ARP из очереди и поместить его в кэш ARP, перенаправляя все пакеты, которые ожидали этого запроса ARP. Псевдокод для этих операций указан в sr_arpcache.h. Базовый код уже создает поток, который истечет время ожидания записей кэша ARP через 15 секунд после того, как они будут добавлены для вас. Вы должны заполнить функцию sr_arpcache_sweepreqs в файле sr_arpcache.c, которая вызывается каждую секунду для перебора очереди запросов ARP и повторной отправки запросов ARP, если это необходимо. Псевдокод для этого предоставлен в sr_arpcache.h.

sr_protocol.h: В структуре маршрутизатора вы будете иметь дело непосредственно с необработанными пакетами Ethernet. Сам код-заглушка предоставляет некоторые структуры данных в sr_protocols.h, которые вы МОЖЕТЕ использовать для простого управления заголовками. sr_utils.[c]: предоставляет полезные функции, которые выводят различные заголовки для целей отладки.

Важные функции

void sr_handlepacket(struct sr_instance* sr, uint8_t * package, unsigned int len, char* interface)

Эта функция получает необработанный кадр Ethernet и отправляет необработанные кадры Ethernet при отправке ответа отправляющему хосту или пересылке кадра на следующий переход. Этот метод, расположенный в sr_router.c, вызывается маршрутизатором каждый раз при получении пакета. Аргумент «пакет» указывает на буфер пакетов, который содержит полный пакет, включая заголовок Ethernet. Имя принимающего интерфейса также передается в метод.

int sr_send_packet(struct sr_instance* sr, uint8_t* buf, unsigned int len, const char* iface)

Этот метод, расположенный в sr_vns_comm.c, отправит произвольный пакет длины len в сеть через интерфейс, указанный в iface.

void sr_arpcache_sweepreqs(struct sr_instance *sr)

Назначение требует, чтобы вы отправляли запрос ARP примерно раз в секунду, пока не придет ответ или мы не отправим пять запросов. Эта функция определена в sr_arpcache.c и вызывается каждую секунду, и вы должны добавить код, который перебирает очередь запросов ARP и повторно отправляет все невыполненные запросы ARP, которые не были отправлены в последнюю секунду. Если запрос ARP был отправлен 5 раз без ответа, недостижимый узел назначения должен вернуться ко всем отправителям пакетов, которые ожидали ответа на этот запрос ARP.

Требования

  • Маршрутизатор может успешно маршрутизировать пакеты между брандмауэром и серверами приложений.
  • Маршрутизатор правильно обрабатывает запросы и ответы ARP.
  • Маршрутизатор правильно отвечает на эхо-запросы ICMP.
  • Маршрутизатор поддерживает кэш ARP, записи которого становятся недействительными по истечении времени ожидания (время ожидания должно быть порядка 15 секунд).
  • Маршрутизатор ставит в очередь все пакеты, ожидающие ответа ARP. Если узел не отвечает на 5 запросов ARP, поставленный в очередь пакет отбрасывается, а обратно источнику поставленного в очередь пакета отправляется сообщение ICMP о недоступности узла.
  • Маршрутизатор применяет гарантии тайм-аутов, то есть, если на запрос ARP не поступает ответ в течение фиксированного периода времени, генерируется сообщение ICMP о недоступности узла, даже если на маршрутизатор больше не поступают пакеты.

Функции и структуры данных, которые необходимо реализовать

Нет конкретных требований, какую функцию вы можете или не можете изменить. Чтобы простой маршрутизатор работал, вам необходимо правильно обрабатывать 4 типа пакетов: Ethernet, IP, ICMP и ARP. Для фактических спецификаций также существуют RFC для ARP (RFC826), IP (RFC791) и ICMP (RFC792).

В нашей эталонной реализации мы разработали sr_ip.[h|c], sr_icmp.[h|c] (эти исходные файлы необходимо добавить в Makefile). Мы также изменили sr_router.[h|c], protocol.h и sr_arpcache.[h|c]. Общая рабочая нагрузка составляет около 550 строк кода на C.

Понимание протоколов

Ethernet

Вам предоставляется необработанный кадр Ethernet, и вы должны отправить необработанные кадры Ethernet. Вы должны понимать MAC-адреса источника и получателя и идею о том, что мы пересылаем пакет через один переход, изменяя MAC-адрес назначения пересылаемого пакета на MAC-адрес входящего интерфейса следующего перехода.

Интернет-протокол

Вы должны понимать, как найти самое длинное совпадение префикса IP-адреса назначения в таблице маршрутизации. Если вы определили, что дейтаграмма должна быть перенаправлена, вы должны правильно уменьшить значение поля TTL заголовка и повторно вычислить контрольную сумму по измененному заголовку, прежде чем пересылать ее на следующий переход.

Протокол контрольных сообщений Интернета

ICMP используется для отправки управляющей информации обратно на отправляющий хост. Вам потребуется правильно сгенерировать следующие сообщения ICMP (включая контрольную сумму заголовка ICMP) в ответ на отправляющий хост при следующих условиях:

  • Эхо-ответ (тип 0): отправляется в ответ на эхо-запрос (ping) на один из интерфейсов маршрутизатора. (Это только для эхо-запросов к любому из IP-адресов маршрутизатора. Эхо-запрос, отправленный в другое место, должен быть перенаправлен на адрес следующего перехода.)
  • Пункт назначения недоступен (тип 3, код 0): отправляется, если существует несуществующий маршрут к IP-адресу назначения (нет соответствующей записи в таблице маршрутизации при пересылке IP-пакета).
  • Хост назначения недоступен (тип 3, код 1): отправляется, если пять запросов ARP были отправлены на IP-адрес следующего перехода без ответа.
  • Протокол недоступен (тип 3, код 2): отправляется, если IP-пакет, содержащий полезные данные UDP или TCP, отправляется на один из интерфейсов маршрутизатора. Это необходимо для работы traceroute.
  • Превышено время (тип 11, код 0): отправляется, если IP-пакет отбрасывается во время обработки, поскольку поле TTL равно 0. Это также необходимо для работы traceroute.

Протокол разрешения адресов

ARP необходим для определения MAC-адреса следующего перехода, который соответствует IP-адресу следующего перехода, хранящемуся в таблице маршрутизации. Без возможности генерировать запрос ARP и обрабатывать ответы ARP ваш маршрутизатор не сможет заполнить поле MAC-адреса назначения в необработанном кадре Ethernet, который вы отправляете через исходящий интерфейс. Аналогично, без возможности обрабатывать запросы ARP и генерировать ответы ARP ни один другой маршрутизатор не может отправлять кадры Ethernet вашего маршрутизатора. Следовательно, ваш маршрутизатор должен генерировать и обрабатывать запросы и ответы ARP. Чтобы уменьшить количество отправляемых запросов ARP, вам необходимо кэшировать ответы ARP. Записи кэша должны истечь через 15 секунд, чтобы свести к минимуму устаревание. Предоставленный класс кэша ARP уже определяет время записи для вас.

При пересылке пакета на IP-адрес следующего перехода маршрутизатор должен сначала проверить кэш ARP на наличие соответствующего MAC-адреса перед отправкой запроса ARP. В случае промаха кеша запрос ARP должен отправляться на целевой IP-адрес примерно раз в секунду, пока не придет ответ. Если запрос ARP отправляется пять раз без ответа, узел назначения ICMP недоступен исходный IP-адрес, как указано выше. Предоставленная очередь запросов ARP поможет вам управлять очередью запросов.

В случае запроса ARP вы должны отправлять ответ ARP только в том случае, если целевой IP-адрес является одним из IP-адресов вашего маршрутизатора. В случае ответа ARP вы должны кэшировать запись только в том случае, если целевой IP-адрес является одним из IP-адресов вашего маршрутизатора. Обратите внимание, что запросы ARP отправляются на широковещательный MAC-адрес (ff-ff-ff-ff-ff-ff). Ответы ARP отправляются непосредственно на MAC-адрес отправителя запроса.

Тестирование и отладка

В целях тестирования вы можете скачать тестовый сценарий здесь. Скопируйте тестовый скрипт в каталог назначения и измените значения eth[0|1|2]ip, app[1|2]ip, topology< /i> номер и имя пользователя в соответствии с вашей информацией о топологии. Запустите тестовый скрипт следующим образом:

Вышеприведенный тестовый пример не включает тесты Недоступность целевого узла, Недоступность целевого узла и Недоступность протокола. Чтобы выполнить эти три теста, вы можете использовать test4 по адресу cps114.nicl.cs.duke.edu. Прежде чем приступить к этим тестам, вам необходимо перенастроить файл router/rtable. Возьмем в качестве примера рисунок 1.

Предположим, что ваша топология показана на рис. 1, выделенный блок IP-адресов — 171.67.243.176/29 (8 IP-адресов). Пакеты, направляющиеся на этот IP-блок, будут направляться на ваш маршрутизатор. Этот IP-блок состоит из 4/31 блоков. Это 171.67.243.176/31 (подключены к eth0), 171.67.243.178/31, 171.67.243.180/31 (подключены к eth1) и 171.67.243.182/31 (подключены к eth2). 171.67.243.178/31 не подключен ни к одному интерфейсу.

Для теста Узел назначения недоступен, если вы добавите запись маршрута

в вашу таблицу маршрутизации, как только ваш маршрутизатор получит пакет с адресом 171.67.243.179, он отправит запрос ARP для адреса 171.67.243.178 через eth1. Ответа не будет, так как 171.67.243.178 вообще не существует. После 5 запросов ARP без ответа ваш маршрутизатор сгенерирует ICMP-пакет Destination Host Unreachable. На этом этапе ваш route/rtable должен выглядеть так:

Для теста Destination Unreachable мы вносим следующие изменения в приведенную выше таблицу маршрутизации. Во-первых, мы удаляем маршрут по умолчанию. Во-вторых, мы удаляем запись таблицы маршрутизации для 171.67.243.179. В-третьих, мы добавляем запись для любого компьютера на рисунке 1. Например, если любой компьютер — это cps114.nicl.cs.duke.edu , мы добавляем запись для его IP-адреса (152.3.144.45) в таблицу маршрутизации. После этих трех изменений ваша таблица маршрутизации должна выглядеть так.

Прямо сейчас ваш маршрутизатор/rtable готов к тесту Destination Unreachable. Вы можете просто отправить пакет UDP с заголовком 171.67.243.179 из cps114.nicl.cs.duke.edu(152.3.144.45). Ваш маршрутизатор должен иметь возможность генерировать ICMP-пакет Destination Unreachable и отправлять его на cps114.nicl.cs.duke.edu. На этом этапе вы можете подумать о том, почему мы делаем три вышеупомянутые модификации. Старайтесь не удалять маршрут по умолчанию, что вы обнаружите?

Для теста Protocol Unreachable вы можете просто отправить один UDP-пакет на любой из ваших интерфейсов маршрутизатора. Ваш маршрутизатор должен иметь возможность генерировать пакет недоступности протокола и отправлять его вам.

Для тестов Destination Host Unreachable, Destination Unreachable и Protocol Unreachable вы можете войти в cps114.nicl. .cs.duke.edu с вашей учетной записью cs appartment и используйте test4 для отправки пакетов UDP и получения отзывов ICMP. Вам необходимо создать и изменить config.xml. обозначает адрес назначения вашего UDP-пакета, является IP-адресом интерфейса вашего маршрутизатора. Затем запустите тестовый пример следующим образом. Этот тест4 отправляет 3 пакета UDP на указанный вами IP-адрес, захватывает полученные пакеты ICMP и проверяет исходные адреса этих пакетов, тип ICMP и поля кода.

Отправка

  • Выполните команду make submit, это должно создать файл с именем router.tar.gz.
  • Загрузите router.tar.gz в задание lab2 на Blackboard.

Правила сотрудничества

Вы можете обсуждать с кем угодно, но вы не должны смотреть код друг друга или копировать код других.

Благодарность

Эта лабораторная работа использует VNS и является одним из заданий VNS. Подробнее о том, как работает VNS, можно прочитать здесь. Последнее обновление: 02/2010

Читайте также: