Курс по основам компьютерных сетей на базе оборудования Cisco. Этот курс поможет вам подготовиться к экзаменам CCENT/CCNA, так как за его основу взят курс Cisco ICND1.

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей, напомню, что эти записи основаны на программе Cisco ICND1 и помогут вам подготовиться к экзаменам CCENT/CCNA. Эта запись подводит итоги трем предыдущим, в которых мы знакомились с назначением, хабов (сетевых концентраторов), коммутаторов (свитчей) и роутеров (маршрутизаторов).

Как известно, повторение — мать учения, нам придется немного повториться, чтобы закрепить полученную ранее информацию о сетевых устройствах, которые занимаются передачей данных по сети.

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

1.20.1 Введение

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

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

Для задачи объединения двух сетей используется маршрутизатор или роутер – это устройство сетевого уровня модели TCP/IP, которое работает с IP-пакетами а дает нам возможность передать данные из одной подсети в другую.

1.20.2 Хабы и Ethernet с общей шиной

Начнем мы с физического уровня модели OSI, ведь именно к этому уровню относятся хабы, сетевые концентраторы и коаксиальный Ethernet кабель, который используется в компьютерных сетях с общей шиной. Хабы и сетевые концентраторы – это одно и то же, у этих устройств очень простая логика, они даже не умеют работать с Ethernet-кадрами, для них все данные представлены в виде последовательности бит. Работает хаб очень просто: данные приходящие ему на один из портов копируются и отправляются во все порты, кроме того, из которого эти самые данные пришли, давайте посмотрим на принцип его работы. Откроем Cisco Packet Tracer и соберем схему как показано на рисунке ниже, не забудьте переключиться в режим симуляции и настроить фильтр.

Рисунок 1.20.1 Схема для демонстрации работы сетевого концентратора

В фильтрах я оставил только ICMP пакеты, давайте запустим пинг от первого узла до третьего (см. последний октет IP-адреса).

Рисунок 1.20.2 Компьютер сформировал ICMP пакет

Первый узел сформировал ICMP пакет, который в дальнейшем будет направлен в сторону сетевого концентратора.

Рисунок 1.20.3 ICMP запрос дошел до хаба

Узел направил ICMP запрос в сторону хаба, но дело в том, что сетевой концентратор ничего не знает про кадры и пакеты, для него это просто последовательность логических нулей и единиц, то есть электрических сигналов, не более.

Рисунок 1.20.4 Хаб скопировал пришедшую последовательность бит и разослал ее во все порты

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

Рисунок 1.20.5 Третий узел послал ICMP ответ в сторону хаба

Поэтому, он формирует ICMP-ответ, запаковывает его в Ethernet-кадр и отправляет в сторону хаба. При этом хаб не запомнил, где находился узел, который посылал ICMP-запрос, просто потому, что хаб этого делать не умеет.

Рисунок 1.20.6 Хаб повторно разослал ICMP-ответ во все порты

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

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

Компьютерную сеть с хабами очень быстро ложиться под воздействием широковещательного шторма и у вас не будет других механизмов его погасить, кроме как прийти физически к этому хабу и отключить его, а затем начнется еще более мучительный процесс по выявлению узла, который этот шторм начал. Также стоит отметить, что порты хаба работают в режиме half duplex и у них нет входящих и выходящих буферов, вся логика хаба описывается тремя глаголами: получил, скопировал, разослал.

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

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

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

1.20.3 Основные отличия хабов от коммутаторов

С хабами и общей шиной все понятно, а если непонятно, то просто запомните, что их не нужно использовать. Перейдем лучше к коммутаторам, эти, как и сетевые концентраторы, позволяют объединять узлы в единую сеть, но при этом коммутаторы лишены многих недостатков, которые есть у хабов. Классический L2 коммутатор – это устройство канального уровня модели OSI 7, которое умеет работать с Ethernet кадрами, а это означает, что у него уже есть логика, современный управляемый коммутатор можно представить как компьютер без видеокарты и монитора, у этого компьютера есть своя операционная система, которая заточена под решение определенных задач, как и модули этого компьютера: у коммутатора есть процессор, есть оперативная память, есть энергонезависимая память и многое другое, что присуще обычным настольным ПК, но все эти модули реализованы немного иначе, чем в настольных ПК, так как у коммутатора иные задачи.

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

Давайте теперь посмотрим, какие преимущества нам даст коммутатор перед хабом, для этого соберем аналогичную схему, но вместо хаба мы будем использовать коммутатор, схема показана на Рисунке 1.20.7. Я не рассказываю, как настроить узлы, поскольку есть отдельная публикация, в которой это все подробно описано можете к ней обратиться и сделать по аналогии (сетевое взаимодействие двух компьютеров)

Рисунок 1.20.7 Схема для демонстрации работы управляемого коммутатора Cisco

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

Давайте теперь попробуем пропинговать третий узел с первого узла и посмотрим, что получится, переключим в режим симуляции Cisco Packet Tracer, а в фильтре оставим ICMP и ARP, именно эти данные нам будут интересны. Но прежде, чем мы начнем симуляцию, давайте зайдем в интерфейс командной строки коммутатора и посмотрим на таблицу, в которой есть соответствие между портами коммутатора и мак-адресами устройств, которые за этими портами находятся.

Рисунок 1.20.8 Таблица мак-адресов коммутатора

Обратите внимание: сейчас эта таблица пуста, посмотреть мы ее смогли при помощи команды «show mac address-table», эта таблица пуста, поскольку ни одно устройство еще не передавало данные через наш коммутатор. Посмотрим, как эта таблица будет изменяться. На рисунке ниже показано, что первый узел сформировал два Ethernet кадра, в одном, который выделен зеленым, находится ARP-запрос, этот кадр будет направлен первым, так как первый узел не знает мак-адреса третьего узла, но знает его IP-адрес, а при помощи протокола ARP и известного IP-адреса можно выяснить мак-адрес удаленной стороны.

Рисунок 1.20.9 Ноутбук сформировал два Ethernet кадра

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

Рисунок 1.20.10 Таблица мак-адресов коммутатора после того, как он обработал первый Ethernet кадр

Теперь в таблице появилась первая запись, по которой коммутатор понимает, что за первым портом находится мак-адрес ноутбука. А теперь посмотрим, что будет дальше, Рисунок 1.20.11.

Рисунок 1.20.11 Коммутатор разослал всем устройствам канальной среды широковещательный Ethernet кадр

Пояснения к этому рисунку я давал ранее, но обратите внимание: третий узел понял, что этот ARP-запрос для него и только он будет на него отвечать. Процесс передачи ARP-ответа с третьего узла на коммутатор понятен, но давайте посмотрим, как изменилась таблица мак-адресов коммутатора, когда тот получил ARP-ответ от третьего узла, Рисунок 1.20.12.

Рисунок 1.20.12 Теперь коммутатор знает, кто находится за первым портом, а кто за вторым

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

Также стоит отметить, что записи в таблицы мак-адресов не вечны, их можно удалить вручную, но, если от узла не будет активности долгое время, коммутатор решит, что за портом все умерли и сотрет запись (время хранение записи на управляемых коммутаторах можно изменять). Давайте посмотрим, что сделает коммутатор с полученным ARP-ответом, Рисунок 1.20.13.

Рисунок 1.20.13 ARP-ответ будет направлен только первому узлу, так как у коммутатора уже есть запись в таблице

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

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

[php]
C:\>arp -a
Internet Address Physical Address Type
192.168.1.1 00e0.f773.3db8 dynamic
C:\>

[/php]

У первого узла есть аналогичная запись, но в ней хранится информация о третьем узле, давайте смоделируем ситуацию небольшого сбоя на коммутаторе, при котором произошла очистка его таблицы мак-адресов, но при этом у конечных узлов останется информация в таблице ARP, то есть узлы не будут делать широковещательные ARP-запросы. Чтобы очистить таблицу маков на коммутаторе Cisco воспользуемся командой «clear mac address-table», а затем убедимся, что она пустая, Рисунок 1.20.14.

Рисунок 1.20.14 Очистим таблицу мак-адресов на коммутаторе

А теперь давайте повторно пропигуем третий узел с первого, ведь именно у них есть информация друг о друге в ARP, поэтому при общении они не будут формировать ARP-запросы.

Рисунок 1.20.15 Ethernet кадр с ICMP вложением пришел на коммутатор

Кадр с ICMP пришел на коммутатор, Cisco Packet Tracer показывает тип кадра или пакета, если на него навести курсор мыши и немного подержать, мы видим, что никаких других кадров, кроме ICMP нет, мы пока этого не видим, но поверьте, содержимое этого кадра довольно таки конкретное и оно говорит коммутатору о том, что этот кадр идет из узла с мак-адресом 00E0.F773.3DB8 на узел с вот таким мак-адресом: 00D0.58B4.6D34. Но дело все в том, что в данный момент таблица маков у коммутатора пуста, он не знает куда посылать этот кадр, при этом нужно учесть, что коммутатор не умеет формировать широковещательные запросы, зато он прекрасно умеет флудить, имитируя поведения хаба с той лишь разницей, что кадр с неизвестным мак-адресом назначения будет отправлен не во все порты, а только в те порты, на которых прописан тот же VLAN, что и на порту, в который этот кадр пришел (я понимаю, что сейчас это непонятно, но в дальнейшем все встанет на свои места). В нашем случае это три других порта.

Рисунок 1.20.16 Коммутатор флудит и рассылает полученный ICMP запрос всем устройствам в канальной среде

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

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

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

Еще одним плюсом коммутаторов является то, что порт коммутатора может работать в нескольких режимах: full duplex или half duplex, а также на порту коммутатора можно регулировать скорость передачи данных, например, модель коммутатора Cisco 2960, реализованная в Packet Tracer, имеет два порта, способных передавать данные на скорости до 1 Гбит/c и 24 порта на скорости до 100 Мбит/c. При этом гигабитные порты можно перевести в режим на 100 Мбит/c или 10 Мбит/c, для портов 100 Мбит/c аналогично.

Стоит отметить, что режим half duplex в современных коммутаторах сохранен в основном для совместимости с древними устройствами, но и он может быть иногда полезен в тех случаях, когда вы используете двухпарную медную линию, в ситуациях, когда одна из пар повредилась передача данных в режиме 100 Мбит/c full duplex будет невозможна, тогда нужно будет попробовать переключить порт в режим 10 Мбит/c full duplex, а если и это не поможет, то стоит попробовать настроить устройства, связанные частично поврежденным кабелем в режим работы 10half, таким образом вы сможете сохранить связь до тех пор, пока обрыв не будет устранен.

Я не зря упоминал про режимы работы порта коммутатора, именно благодаря тому, что порт коммутатора может работать в режиме работы full duplex, узлы, подключенные к коммутатору, могут одновременно и передавать, и принимать данные, но не только благодаря этому, у портов коммутатора есть еще входные и выходные буферы, в которых находятся кадры, ждущие своей участи. Две этих особенности практически полностью устраняют домен коллизий в сетях, построенных на коммутаторах. Практически, потому, что по причинам различных сбоев может произойти ситуация, в которой случается рассинхронизация режимов работы порта коммутатора и порта устройства, подключенного к этому коммутатору, при этом домен коллизий ограничен портом коммутатора, то есть столкновение кадров может произойти только в канале между коммутатором и устройством, с которым произошла рассинхронизация.

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

1.20.4 Коммутаторы коммутируют, а маршрутизаторы маршрутизируют

При собеседовании на начальные позиции сетевых инженеров часто задают вопрос: чем отличается коммутатор от маршрутизатора. Можно, конечно, пошутить и сказать, что коммутаторы коммутируют, а маршрутизаторы маршрутизируют, но шутку могут не оценить. Поэтому, если нужен короткий и ясный ответ, то можно сказать так: коммутаторы используются для объединения компьютеров в одну сеть, а маршрутизаторы нужны для объединения сетей.

Действительно, коммутаторы L2, да и L2+ практически не умеют работать с IP-адресами, их задача заключается в том, чтобы организовать взаимодействие узлов, находящихся в одной канальной среде, то есть в одной подсети, для решения этой задачи коммутаторам хватает мак-адресов. Но что если вам нужно наладить связь между двумя подсетями, как тут быть? Здесь два выхода: переконфигурировать узлы так, чтобы они находились в одной подсети и получить неэффективную сеть, в которой будет очень много широковещательного трафика, который не только занимает канал связи, но еще и создает дополнительную нагрузку на коммутаторы или воспользоваться маршрутизатором/роутером, который способен перенаправлять пакеты из одной подсети в другую.

Схема, с которой мы будем работать показана на Рисунке 1.20.17, здесь показано две подсети, условно будем их называть левая и правая, а в центре этой схемы находится маршрутизатор. Стоит обратить внимание на то, что порты маршрутизатора по умолчанию выключены и их нужно включать, на рисунке все уже настроено, поэтому линки горят зеленым, при сборке схемы у вас изначально они будут красными.

Рисунок 1.20.17 Компьютерная сеть с маршрутизатором

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

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

1. enable – входим в привилегированный режим.
2. configure terminal – переходим в режим конфигурации.
3. interface gi0/0 – переходим в режим конфигурации порта gi0/0.
4. no shutdown – включаем порт gi0/0.
5. ip address 192.168.1.1 255.255.255.0 – задаем ip-адрес и маску на порт gi0/0.
6. gi0/1 – переключаемся на конфигурации порта gi0/1.
7. no shutdown – включаем порт gi0/1.
8. ip address 45.10.10.1 255.255.255.0 – задаем ip-адрес и маску на порт gi0/1.
9. end – выходим из режима конфигурации.
10. write – сохраняем настройки.

Если в нашем случае настройки не сохранить, то после перезагрузки устройства произойдет откат до заводского состояния. Обратите внимание: у узлов теперь появился шлюз или gateway (default gateway или шлюз по умолчанию). Узлам мы задаем в качестве шлюза IP-адрес того интерфейса маршрутизатора, который находится в одной подсети с этими узлами, то есть для левой подсети это 192.168.1.1, а для правой подсети 45.10.10.1.

Основной шлюз, вернее IP-адрес шлюза, для узла является указанием: если узел, к которому ты хочешь обратиться, находится не в твоей подсети, посылай IP-пакет мне, я попробую разобраться. В теме, где мы знакомились с роутером, мы смотрели таблицу маршрутов на компьютере и видели, как это правило выглядит. А также мы видели, что у компьютеров есть ARP-таблица, такая же таблица есть и у маршрутизатора, посмотреть ее можно командой «show ip arp». Так выглядит таблица нашего маршрутизатора сразу после того, как мы его настроили:

[php]

Router#show ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 45.10.10.1 — 0010.1111.1702 ARPA GigabitEthernet0/1
Internet 192.168.1.1 — 0010.1111.1701 ARPA GigabitEthernet0/0

[/php]

Здесь пока есть информация только о интерфейсах роутера, так как через наш маршрутизатор еще не прошел ни один IP-пакет, по мере обращения узлов к маршрутизатору, таблица будет заполняться, у каждой записи в этой таблице есть время жизни, а также она не бесконечна. Но давайте попробуем сделать Ping и посмотреть, что происходит. Пинг будем делать с узла 192.168.1.2 до узла 45.10.10.2.

Рисунок 1.20.18 Пингуем узел второй подсети из первой

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

Рисунок 1.20.19 Роутер получил Ethernet кадр с ARP-запросом

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

Рисунок 1.20.20 Кадр с ARP-запросом пришел на маршрутизатор

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

Ранее мы пытались пропинговать узел из другой подсети без маршрутизатора и тогда мы не задавали узлам IP-адрес шлюза по умолчанию, поэтому наш узел в качестве IP-адреса назначения использовал нулевой адрес (0.0.0.0), просто потому, что он не знал кому направлять запрос, теперь у узла такая информация есть.

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

Арп-ответ на рисунке справа нам не так интересен, здесь роутер просто сообщает узлу, сделавшему запрос, свой мак-адрес. Этот кадр уйдет обратно на узел 192.168.1.2 и после этого наш узел достанет из буфера ICMP-запрос и отправит его, давайте посмотрим на содержимое. Но перед этим посмотрим таблицу ARP у нашего роутера.

[php]
Router#sh ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 45.10.10.1 — 0010.1111.1702 ARPA GigabitEthernet0/1
Internet 192.168.1.1 — 0010.1111.1701 ARPA GigabitEthernet0/0
Internet 192.168.1.2 0 0005.5E5B.1CE6 ARPA GigabitEthernet0/0

[/php]

В нее добавилась еще одна запись, теперь роутер знает, какой мак-адрес у узла 192.168.1.2, но роутер пока не знает, что этот узел хочет обратиться к узлу 45.10.10.2, он это узнает только после того, как получит пакет ICMP-запросом от узла из левой подсети, так как только там будет указан этот адрес. Давайте на это посмотрим. Рисунок 1.20.21.

Рисунок 1.20.21 Кадр с ARP-запросом пришел на маршрутизатор

Обратите внимание: на рисунке показан ICMP-запрос, который направил узел 192.168.1.2 на узел 45.10.10.2, при этом, как мы видим, для его отправки уже используется IP-пакет, в левой части, которая подписана In Layers, мы это видим, так как там появились записи для Layer 3, в которой указан IP-адрес узла отправителя и IP-адрес узла получателя, получается, что для связи двух подсетей, нам уже не достаточно просто Ethernet-кадров, нам уже нужны IP-пакеты, которые помещаются внутрь кадров. Таким образом, пока данные идут внутри подсети, никому не интересно, что находится внутри кадра, передача ведется при помощи мак-адресов, но как только эти данные попадают на границу двух канальных сред, маршрутиазтор снимает Ethernet-заголовок, который сформировал узел-отправитель и смотрит на заголовок IP-пакета, чтобы понять, что нужно сделать дальше (тут будет полезно вспомнить о декомпозиции задачи сетевого взаимодействия и принципе инкапсуляции данных).

В нашем случае маршрутизатор видит, что получателем является узел 45.10.10.2, маршрутизатор понимает, что этот получатель находится в одной канальной среде с интерфейсом, которому мы задали IP-адрес 45.10.10.1, но, к сожалению, маршрутизатор не знает мак-адреса получателя, потому что он еще ни разу не передавал ему данные, а мак-адрес получателя ему нужен, так как роутер понимает, что получатель находится в одной канальной среде с его интерфейсом gi0/1, а связь внутри канальной среды осуществляется по мак-адресам. Роутеру ничего не остается, кроме как откинуть первый ICMP-запрос узла отправителя и сформировать арп-запрос, чтобы выяснить мак-адрес получателя (на рисунке темный пакет – это ICMP-запрос узла 192.168.1.2, а светлый – это ARP-запрос, который формирует роутер, чтобы узнать мак-адрес узла 45.10.10.2). Чтобы убедиться в том, что роутер не знает мак-адрес получателя, можно посмотреть на его ARP-таблицу.

[php]

Router#sh ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 45.10.10.2 — Incomplete ARPA GigabitEthernet0/1
Internet 45.10.10.1 — 0010.1111.1702 ARPA GigabitEthernet0/1
Internet 192.168.1.1 — 0010.1111.1701 ARPA GigabitEthernet0/0
Internet 192.168.1.2 0 0005.5E5B.1CE6 ARPA GigabitEthernet0/0
Router#

[/php]
Надпись Incomplete свидетельствует о том, что для IP 45.10.10.2 нет соответствия по мак-адресу. Смотреть как роутер делает ARP-запрос не имеет смысла, эта процедура ничем не отличается от узла, давайте лишь посмотрим, что таблица ARP действительно изменилась после того, как ответ узла 45.10.10.2 дойдет до роутера, она показана на Рисунке 1.20.22.

Рисунок 1.20.22 ARP-таблица роутера

Когда вы используете утилиту Ping, вернее, когда узел посылает ICMP-запрос, он понимает, что не имеет смысла ждать ответа до бесконечности, поэтому, если через какое-то, заранее определенное время, узел не получает ответ он вам выдаст сообщение в командной строке: Request time out, и сформирует новый ICMP-запос.

Рисунок 1.20.23 Не дождавшись ответа, узел сформировал второй ICMP-запрос, а мы увидели сообщение Request time out

Давайте посмотрим, что случится с вторым ICMP-запросом на роутере. Для наглядности пришлось немного растянуть схему, показано на Рисунке 1.20.24.

Рисунок 1.20.24 Второй ICMP-запрос пришел на роутер

Нас интересует информация, которую мы видим в окне по центру: в разделе In Layers показано, что пришло на интерфейс роутера Gi0/0, этот интерфейс смотрит в сторону узла 192.168.1.2, в разделе Out Layers показано как роутер изменил данные, чтобы они дошли до узла 45.10.10.2.

Уровень Layer 3 на не интересен, здесь ничего не поменялось: что на входе, что на выходе мы имеем IP-адрес источника 192.168.1.2 и IP-адрес получателя 45.10.10.2. Самое интересное роутер делает на втором уровне. Итак, смотрим на Layer 2 в разделе In Layers: в качестве мак-адреса отправителя здесь указан мак-адрес узла 192.168.1.2 (0005.5e5b.1ce6), в качестве мак-адреса получателя указан мак-адрес интерфейса роутера gi0/0 (0010.1111.1701). Все логично, этот узел и этот интерфейс роутера находятся в одной канальной среде, узел отправитель знает, что добраться до другой подсети он может через основной шлюз, поэтому на канальном уровне он обращается к нему, но на сетевом уровне он сообщает роутеру: этот пакет не тебе, а узлу с IP-адресом 45.10.10.2, переправь, пожалуйста эти данные ему.

Когда роутер получил ICMP-запрос, в виде последовательности бит, он собирает из этой последовательности Ethernet-кадр, анализирует заголовок, видит, что Ethernet-кадр вроде как для него, но ведь роутер — это устройство третьего уровня, он понимает, что внутри кадра есть еще IP-пакет, поэтому он удаляет заголовок кадра и видит заголовок IP-пакета, в котором видит IP-адрес назначения (45.10.10.2), проанализировав этот адрес, роутер понимает, что этот IP-адрес находится в одной подсети с интерфейсом gi0/1, на который мы повесили IP 45.10.10.1, роутер смотрит в ARP-таблицу, видит, что для IP-адреса 45.10.10.2 есть соответствующий мак-адрес и тут начинается самое интересное.

Это самое интересное показано в разделе Out Layers. Ранее роутер убрал Ethernet-заголовок, чтобы прочитать IP-пакет, теперь роутеру нужно вернуть Ethernet-заголовок, чтобы данные могли быть отправлены узлу, находящемуся в правой канальной среде, ведь для передачи данных в подсети нужны мак-адреса. Роутеру нужно не просто отправить данные, а сделать так, чтобы узел 45.10.10.2 не растерялся и понял, куда ему слать ответы, если вдруг что, поэтому роутер вместо мак-адреса узла 192.168.1.2, который был указан в качестве мак-адреса отправителя, подставляет мак-адрес своего интерфейса gi0/1 (0010.1111.1702), который находится в канальной среде с узлом 45.10.10.2, узел 45.10.10.2 уже знает этот мак, так как при первом ICMP-запросе, который не прошел, роутер и этот узел обменялись арп-запросом и арп-ответом, поэтому сможет ответить.

Итак, первое, что сделал роутер: поменял мак-адрес узла 192.168.1.2 на свой мак-адрес. Второе действие, которое совершил роутер, формируя новый Ethernet-кадр – заменил мак-адрес получателя, когда ICMP-запрос пришел на роутер в качестве получателя был указан мак-адрес интерфейса gi0/0, таким образом была обеспечена доставка данных по канальной среде, в которой находится узел 192.168.1.2, теперь же данные должны перейти в канальную среду (или подсеть), в которой находится узел 45.10.10.2, поэтому и мак-адрес назначения должен быть изменен на мак-адрес узла 45.10.10.2 (0001.4278.450D).

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

Рисунок 1.20.25 ICMP-запрос пришел на второй узел

Обратите внимание на Рисунок 1.20.25, здесь что происходит, когда ICMP-запрос пришел на второй узел, тут история повторяется, узел обработал запрос и сформировал ответ, но в качестве IP-адреса получателя он указывает 192.168.1.2, так как ответ именно для этого узла, но этот узел в другой канальной среде, до которой можно добраться через роутер, поэтому в качестве мак-адреса получателя используется мак-адрес роутера, а если конкретнее, то интерфейса gi0/1, так как именно он находится в одной подсети с узлом 45.10.10.2.

Когда этот ответ попадет на роутер, роутер заменит мак-адрес отправителя на свой, а мак-адрес получателя на мак-адрес узла 192.168.1.2. Окончательно убедиться в том, что узлы 192.168.1.2 и 45.10.10.2 ничего не знают друг о друге, можно просто взглянув на их арп-таблицы после того, как пройдет пинг. Сначала посмотрим на arp-таблицу первого узла.

Рисунок 1.20.26 ARP-таблица первого узла

Тут также показан результат пинга, при отправке первого запроса он потерялся, так как роутер не знал мак-адреса узла 45.10.10.2 и просто откинул первый запрос, а последующих три запроса успешно прошли, если повторить пинг, то мы получим четыре ответа, так как в арпе у роутера уже есть нужные записи. А что касается арп-таблицы узла из первой подсети: тут нет упоминаний о узле 45.10.10.2, есть лишь информация о роутере и его интерфейсе gi0/0. Теперь посмотрим на арп второго узла.

Рисунок 1.20.27 ARP-таблица второго узла

У него в арпе нет информация о узле 192.168.1.2, есть только про роутер и интерфейс gi0/1. Этих два узла общались между собой, но арп-записей друг для друга не создали по одной простой причине: роутер при передачи данных из одной подсети в другую менял мак-адреса на свои, поэтому узел 192.168.1.2 не имеет представления о том, какой мак-адрес у узла 45.10.10.2 и наоборот, зато оба узла знают как добраться до роутера, который затем разберется.

Давайте подведем промежуточный итог разговору о роутерах, для этого исключим все лишнее из схемы и представим себе следующее: у нас есть компьютер А, который мы задали IP-адрес 192.168.10.2 с маской 255.255.255.0, этот компьютер напрямую включен в порт роутера, на котором мы задали вот такие настройки: IP-адрес 192.168.10.1, маска 255.255.255.0, пусть это будет первый порт роутера, следовательно, в качестве шлюза по умолчанию мы задали этому компьютеру адрес 192.168.10.1. Также у нас есть компьютер Б, которому мы задали IP-адрес 10.10.10.2 с маской 255.255.255.0 и основной шлюз 10.10.10.1, этот компьютер подключен ко второму порту роутера, на котором заданы вот такие настройки: IP-адрес 10.10.10.1 и маска 255.255.255.0, пусть это будет второй порт маршрутизатора. Схема показана на Рисунке 1.20.28.

Рисунок 1.20.28 Схема для демонстрации работы роутера

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

Итак, когда мы написали в командной строке компьютера А команду ping 10.10.10.2, он сделал четыре вещи в следующем порядке:

1. Сформировал ICMP-запрос.
2. Упаковал этот запрос в IP-пакет, в котором в качестве адреса назначения указал 10.10.10.2, а в качестве источника – свой IP-адрес.
3. Компьютер А не совсем дурачок, он понимает, что IP-адрес 10.10.10.2 находится в другой подсети, поэтому он до него не доберется, даже если будет знать его мак-адрес, но у компьютера А есть основной шлюз, который может знать, как добраться до нужного узла, поэтому IP-пакет, созданный ранее, наш компьютер помещает внутрь Ethernet-кадра, в котором в качестве мак-адреса назначения он указывает мак-адрес первого порта роутера, а в качестве мак-адреса источника указывал свой мак-адрес.
4. На четвертом шаге компьютер перемолол полученную конструкцию в последовательность нулей и единиц (в биты) и отправил эту последовательность по проводу, который соединяет его и маршрутизатор.

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

Рисунок 1.20.29 Компьютер А готовит данные к отправке

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

1. Получает последовательность бит и формирует из нее Ethernet-кадр.
2. Сформировав кадр, роутер видит, что мак-адрес назначения его, а это значит, что нужно заглянуть внутрь этого кадра, чтобы понять, что с ним делать, поэтому он убирает Ethernet-заголовок.
3. Убрав Ethernet-заголовок, роутер проверяет заголовок IP-пакета и видит, что IP-адрес источника принадлежит компьютеру А, а IP-адрес назначения компьютеру Б, роутер понимает, что IP-пакет предназначен не ему и роутеру нужно передать его дальше. Собственно, по IP-адресу назначения маршрутизатор понимает, что эти данные нужно отправлять во второй порт.
4. Не забывайте, что на данном этапе роутер убрал Ethernet-заголовок, который сформировал компьютер А, а, чтобы отправить данные в канальную среду, в которой находится компьютер Б, нужно указать мак-адреса, а, следовательно, и восстановить заголовок Ethernet-кадра. Но тут роутер идет на хитрость: в поле мак-адрес источника он заменяет мак-адрес компьютера А на мак-адрес своего второго порта, а мак-адрес назначения он меняет на мак-адрес компьютера Б. Роутер понимает, что в канальной среде связь осуществляется по мак-адресам и компьютер Б просто откинет полученные данные, если оставить старые мак-адреса.
5. Получившаяся конструкция перемалывается в последовательность бит и отправляется в провод, подключенный ко второму порту.

Эти шаги показаны на Рисунке 1.20.30.

Рисунок 1.20.30 Роутер обрабатывает данные при передаче между канальными средами

Далее последовательность бит придет компьютеру Б и он тоже выполнит несколько простых шагов:

1. Сначала компьютер Б объединяет полученные биты в Ethernet-кадр, по мак-адресу назначения он понимает, что этот Ethernet-кадр принадлежит ему.
2. Раз кадр принадлежит ему, значит надо убрать заголовок канального уровня и посмотреть, что там внутри.
3. Внутри Ethernet кадра находится IP-пакет по IP-адресу источника узел Б понимает, кому нужно будет ответить, а по IP-адресу назначения узел понимает, что пакет принадлежит именно ему.
4. А это означает, что нужно распаковать IP-пакет, сняв заголовок сетевого уровня, роутер видит внутри него ICMP-запрос, который предназначен для него (тут стоит отметить, что у каждого компьютера есть политики безопасности и правила, опираясь на которые, узлы принимают решения: кому отвечать на ICMP-запросы, а кому не стоит).
5. Допустим в нашем случае узел Б решил ответить на ICMP-запрос.

Описанные действия показаны на Рисунке 1.20.31.

Рисунок 1.20.31 Компьютер Б получает ICMP-запрос от компьютера А

Чтобы ответить, узлу Б придется уже формировать данные заново и опять действия будут выполняться по шагам:

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

Эта последовательность действий показана на Рисунке 1.20.32. Что будет дальше понятно, роутер получит данные с ответом, выполнит операцию по подмене маков и компьютер А получит ICMP-ответ.

Рисунок 1.20.32 Компьютер Б формирует ICMP-ответ для компьютера А

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

1.20.5 Выводы

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

Коммутаторы, в отличие от хабов, это уже устройства второго уровня модели OSI, у них уже есть программная логика и они прекрасно умеют работать с Ethernet-кадрами, также коммутаторы могут запоминать информацию об устройстве сети и на основе этого принимать дальнейшие решения по обработке и передачи данных. Коммутаторы, как и хабы, используются для объединения устройств в единую сеть, но благодаря программной логики, коммутаторы лишены многих недостатков, присущих сетевым концентраторам. Коммутаторы L2 могут объединять узлы в сеть, но коммутаторы не способны объединить две или более сети, эту задачу уже решают маршрутизаторы, устройства сетевого уровня модели TCP/IP.

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