69586

ICMP сетевой администратор

Практическая работа

Информатика, кибернетика и программирование

Проверить возможность обмениваться пакетами произвольной длины между своим узлом и любым узлом составной сети с помощью сообщений типа 0 и 8 (Echo и Echo Reply Message). Проверить время отклика стека на станции с помощью сообщений типа 13 и 14 (Timestamp и Timestamp Reply).

Русский

2014-10-07

2.56 MB

0 чел.

Урок 10

На предыдущем уроке мы познакомились с протоколом ICMP, применяемым как инструмент диагностики IP сети. С помощью ICMP сетевой администратор может осуществлять следующие действия:

  •  Проверить возможность обмениваться пакетами произвольной длины между своим узлом и любым узлом составной сети с помощью сообщений типа 0 и 8 (Echo и Echo Reply Message).
  •  Проверить время отклика стека на станции с помощью сообщений типа 13 и 14 (Timestamp и Timestamp Reply). Хотя, данный метод на практике не применяется так как современные компьютеры имеют столь высокое быстродействие, что временной штамп прихода запроса и генерации ответа совпадают и не представляют интереса с точки зрения диагностики взаимодействия. Так же эти сообщения могут использоваться для решения задачи связанной с выяснением возможности обмена пакетами между узлами, если по каким либо причинам использовать сообщения типа 0 и 8 нельзя. Но, в этом случае длина пакета фиксирована и невелика всего 12 байт данных.
  •  Выяснить IP адреса портов промежуточных маршрутизаторов при передаче пакетов некоторому узлу с помощью сообщений типа 11 (Time Exceeded), хотя, и сам протокол IP имеет для этого некоторые встроенные средства.
  •  Исследовать MTU транзитных сетей с помощью сообщения типа 3 с кодом 4 (Destination Unreachable - Fragmentation needed and DF set).
  •  Выяснить причины недостижимости узлов в сети благодаря сообщениям типа 3 с кодами 1 и 2 (Destination Unreachable - Host Unreachable и Protocol Unreachable).
  •  Выяснить, что на узлах не используются те или иные протоколы (тип 3 код 2)
  •  Выяснить, что на узлах не используются те или иные приложения UDP (тип 3 код 2)

Помимо администратора, преимущества от использования ICMP так же получают и приложения. Например, в адрес приложения приходят сообщения об ошибках типа 3 со всеми кодами (Destination Unreachable), типа 11 или типа 12 (Time Exceeded и Parameter Problem), при этом приложение оперативно информирует об этом пользователя, сокращая тем самым лишний трафик, который мог бы быть отправлен и время ожидания пользователя.

Кроме того, ICMP сообщения позволяют получить преимущества для самой сети:

  •  Сообщения типа 5 (ICMP Redirect) могут уменьшить трафик путем более разумной маршрутизации некоторых пакетов
  •  Сообщения типа 4 (ICMP Source Quench) позволяют избежать перегрузок в сети и предотвратить перегрузки в сети и как следствие, потери пакетов (уже устарело, напомнить – почему и какой протокол этим сейчас занимается)

Так же сообщения типов 9 и 10 (Router Advertisement и Router Solicitation) позволяют администратору организовать для пользователей динамическое взаимодействие с маршрутизаторами, увеличивая тем самым надежность функционирования сети.

Тем не менее, по усмотрению разработчиков, протокол типа ICMP, вообще говоря, может быть, и не реализован в стеке протоколов операционной системы. В истории развития компьютерных сетей существуют относительно полноценные стеки протоколов, например, IPX/SPX, в которых реализованы функции от сетевого уровня модели OSI и выше. Но при этом никакого аналога ICMP такие стеки не содержат, что значительно затрудняет диагностику неисправностей в составных сетях, базирующихся на указанных стеках протоколов. В конечном счете, такое положение вещей делает подобные стеки протоколов менее пригодными для построения больших составных сетей.

Таким образом, к этому моменту нами рассмотрены следующие базовые темы курса:

  •  Причины, приводящие к необходимости использования сетевого уровня модели OSI
  •  Методы работы сетевого уровня
  •  Адресацию с использованием протокола IPv4
  •  Принципы маршрутизации в IP сетях
  •  Протокол IPv4
  •  Протокол ICMP

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

- способ подключения станции к одной сети двумя интерфейсами

- резервирования связей между маршрутизаторами

- нестандартная маршрутизация и т.д.

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

Проведем анализ.

К одному коммутатору подключено 6 станций, у трех из них адреса назначены из адресного пространства 10.0.0.0/8, у трех других из адресного пространства 192.168.0.0/24. Пока положим, что на станциях не указан адрес шлюза по умолчанию, так как маршрутизатора, отдельно в сети и нет! Сможет ли станция 10.0.0.2 обмениваться пакетами со станцией 10.0.0.3? Для ответа на данный вопрос применим изученный ранее материал – знания о логики работы узлов в составной сети. Проведем анализ поведения станции 10.0.0.2 при отправке пакетов для станции 10.0.0.3 с использованием всем известного алгоритма, который, разумеется, не меняется волшебным образом оттого, что в сети есть странности с адресацией и вообще никогда не меняется. В подобных внештатных на первый взгляд ситуациях действуют абсолютно те же правила, которые были изучены на предыдущих уроках, и для того, чтобы понять как поведет себя система, организованная «странно» необходимо и достаточно просто применять к поведению узлов этой системы, рассмотренные ранее правила.

 Итак, станция 10.0.0.2 хочет отправить пакет для станции 10.0.0.3. Станция 10.0.0.2 принимает решение на основании анализа своего IP адреса и IP адреса получателя, в одной ли канальной сети находятся эти станции (на самом деле, станция может сделать вывод о том, в одной ли она канальной сети с другой станцией только косвенно, на основании  анализа IP адресов). Так как номера сетей отправителя и получателя совпадают (10.0.0.0), станция  10.0.0.2 понимает, что находится в одной канальной сети со станцией 10.0.0.3 и посылает ей ARP запрос, который, разумеется, достигнет адресата. Далее будет получен ответ и взаимодействие произойдет так, как и произошло бы, не будь в этой же канальной сети станций с адресами из диапазона 192.168.0.0/24. Так же очевидно, что станции с адресами из диапазона 192.168.0.0/24 будут без проблем обмениваться пакетами друг с другом, так как тоже находятся в одной канальной сети.

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

Разумеется, наибольший интерес представляет вопрос о возможности обмена данными между станциями, принадлежащими к разным диапазонам IP адресов. Итак, пусть станция 10.0.0.2 хочет отправить пакет для станции 192.168.0.2. Как это будет происходить? И для ответа на этот вопрос никаких новых знаний, опять таки, не нужно. Достаточно использовать уже имеющиеся знания: станция 10.0.0.2 сравнивает свой номер сети (10.0.0.0) с номером сети получателя (192.168.0.0) и делает вывод, что эти номера отличаются. Станция 10.0.0.2 делает вывод, что находится со станцией 192.168.0.2 в различных канальных сетях, что неверно на самом деле, но так работает протокол IP! Следовательно, станция 10.0.0.2 должна передать пакет для станции 192.168.0.2 в кадре канального уровня порту маршрутизатора, но так как станция 10.0.0.2 не имеет указанного в настройках адреса маршрутизатора по умолчанию (в сети вообще нет никакого маршрутизатора), то пакет для станции 192.168.0.2 отбрасывается и обмен пакетами невозможен. Если бы станция 10.0.0.2 могла бы знать, что станция 192.168.0.2 все же находится с ней в одной канальной сети, она могла бы просто послать ей ARP запрос и дальнейшем обмениваться с ней кадрами канального уровня. Но так в настройках IP пока нет адреса шлюза, взаимодействие не  происходит и не может происходить – так работает протокол IP.

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

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

- в офисе должно быть две независимые сети, никак не взаимодействующие друг с другом.

При этом нет необходимости строить две канальных сети, приобретать два коммутатора, достаточно просто настроить станциям адреса из различных диапазонов IP адресов. Разумеется, данное решение не является единственным. Еще одним примером решения подобной задачи является использование нескольких VLAN. Однако, решение на основе двух диапазонов IP адресов одной канальной сети простое и бесплатное, в то время как далеко не каждый дешевый коммутатор поддерживает VLAN. Впрочем, решение на базе VLAN и более функционально, так как изолирует весь трафик виртуальных сетей, в то время как в нашем случае весь трафик является общим. 

Рассмотрим следующие варианты взаимодействия узлов с адресами из разных диапазонов в рассматриваемой сети.

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

Если присвоить маршрутизатору адрес, например, 10.0.0.1 и настроить  узлы сети 10.0.0.0/8 на использование этого маршрутизатора как шлюза по умолчанию, то узлы сети 10.0.0.0/8 будет отправлять пакеты в сеть 192.168.0.0/24 на маршрутизатор. Но этот маршрутизатор будет иметь только одну подключенную сеть 10.0.0.0/8, и не будет иметь маршрута в подключенную сеть 192.168.0.0/24. Так, что передавать пакеты в сеть 192.168.0.0/24 он не сможет, а даже если бы и смог, узлы диапазона 192.168.0.0/24 НЕ будут иметь адреса шлюза по умолчанию и не смогут отправлять пакеты в сеть 10.0.0.0/8 - так что взаимодействие в любом случае будет невозможно. 

Очевидно, для нормального взаимодействия узлов - настройки для сетей 10.0.0.0/8 и 192.168.0.0/24 должны быть симметричны. Для этого, вероятно, необходимо подключить маршрутизатор к данной канальной сети ДВУМЯ интерфейсами, ведь фактически в одной канальной сети существуют эффективно две сети и каждая должна быть подключена к маршрутизатору соответствующим интерфейсом, с соответствующим адресом. Рассмотрим такую схему:

При этом, таблица маршрутизации маршрутизатора будет иметь вид:

Сеть получателя  Следующий шлюз   Выходной порт

10.0.0.0/8   10.0.0.1    eth0

192.168.0.0/24   192.168.0.1   eth1

Рассмотрим, как узел 10.0.0.2 отправляет пакет узлу 192.168.0.2. Для начала, как и ранее, узел 10.0.0.2 выясняет, что получатель находится с ним в различных IP сетях и, следовательно, в разных канальных сетях (хотя последнее и неверно). Далее, станция 10.0.0.2 принимает решение отправлять пакеты для станции 192.168.0.2 на маршрутизатор. Станция 10.0.0.2 имеет настроенный адрес шлюза по умолчанию 10.0.0.1 и посылает ему ARP запрос. Как уже отмечалось ранее, данный ARP запрос достигнет адресата, будет сформирован ARP ответ и станция 10.0.0.2 передаст пакет для станции 192.168.0.2 в кадре канального уровня порту маршрутизатора 10.0.0.1.  На маршрутизатор с указанной выше таблицей маршрутизации поступает пакет для 192.168.0.2 и обрабатывается обычным образом. Затем, маршрутизатором принимается решение о продвижении его через порт 192.168.0.1, причем сеть получателя подключена к этому порту, следовательно - через интерфейс маршрутизатора в ТУ ЖЕ канальную сеть (хотя маршрутизатор и не знает этого!) будет отправлен ARP запрос в поисках МАС адреса станции 192.168.0.2. Как уже говорилось, такой запрос достигнет получателя и будет получен ответ, после чего кадр с пакетом от 10.0.0.2 к 192.168.0.2 будет передан на МАС адрес станции 192.168.0.2 и безусловно достигнет адресата. Таким образом, взаимодействие все же возможно! Обратите внимание - все это происходит так, как будто IP сети 10.0.0.2 и 192.168.0.2 принадлежат разным канальным сетям, т.е. мы получили самую обычную маршрутизируемую среду. Ни маршрутизатор, ни станции в обеих IP сетях не представляют себе, что на самом деле станции из разных IP сетей принадлежат одной канальной сети.

Однако, в данном случае, никак не использовали тот факт, что станции сети 10.0.0.0 и 192.168.0.0 расположены в одной канальной сети - подключив маршрутизатор двумя портами к одной канальной сети, мы избыточно расходуем его ресурсы – порты. А нельзя ли обойтись в этой сети использованием лишь одного порта маршрутизатора? По идее - одного порта в канальной сети предостаточно, чтобы отправлять в эту канальную сеть любые кадры! Подобное решение предлагалось ранее – вопрос упирался в то, какой адрес присвоить этому порту. Ведь если в каждой из IP сетей не будет использоваться шлюз по умолчанию из этой IP сети, то узлы-участники этой сети не смогут передавать пакеты в другие сети. Т.е. - при подключении лишь одного порта маршрутизатора к данной канальной сети схема имеет только один недостаток: адрес этого порта будет принадлежать либо одной, либо другой IP сети. Решение заключается в присвоении порту маршрутизатора ДВУХ IP адресов(!) 10.0.0.1 и 192.168.0.1.

Рассмотрим пример:

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

Сеть получателя  Следующий шлюз   Выходной порт

10.0.0.0/8   10.0.0.1    eth0

192.168.0.0/24   192.168.0.1   eth0

Из этой таблицы следует, что пакеты в сеть 10.0.0.0 и 192.168.0.0 будут отправлены через один физический порт,  при этом логика работы маршрутизатора не изменяется. Рассмотрим взаимодействия аналогичные рассмотренным ранее схемам.

Пусть, как и в предыдущих примерах, станция 10.0.0.2 хочет передать пакет для станции 192.168.0.2. Станция 10.0.0.2 понимает, что 192.168.0.2 с ней в разных IP сетях (это верно) и как следствие в разных канальных сетях (что в данном случае неверно, но не помешает взаимодействию). Следовательно, станция 10.0.0.2 отправляет ARP запрос на маршрутизатор 10.0.0.2 и соответствующий пакет поступает на все порты данной канальной сети, в частности и на порт маршрутизатора, который имеет адрес 10.0.0.1 и отвечает на данный запрос. Станция 10.0.0.2 передает кадр на МАС адрес порта маршрутизатора eth0, в котором пакет для станции 192.168.0.2. Этот пакет поступает на маршрутизатор и обрабатывается приведенной выше таблицей маршрутизации. Очевидно, пакет отправляется по маршруту, указанному во второй строке таблицы маршрутизации, т.е. должен поступить на следующий маршрутизатор 192.168.0.1. Так как данный порт принадлежит самому маршрутизатору, то это значит, что сеть получателя подключена, и необходимо передать ARP запрос узлу 192.168.0.2. Через какой порт? Ответ на этот вопрос тоже содержится в таблице маршрутизации – через порт eth0 (!). Этот ARP запрос отсылается, и поступает на все узлы нашей канальной сети, в частности на узел 192.168.0.2, который на него отвечает, после чего маршрутизатор через порт eth0 передает кадр для станции 192.168.0.2 с пакетом от станции 10.0.0.2. Взаимодействие возможно и с подключением одного порта маршрутизатора к канальной сети, но при условии присвоения этому порту двух (или более, если IP сетей в данной канальной сети больше) IP адресов.  

Рассмотрим описанную ситуацию на примере, используя в качестве маршрутизатора Windows Server:

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

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

Пример присвоения IP адресов одному интерфейсу:

При этом, станции 10.0.0.2 и 10.0.0.3 могут обмениваться пакетами с портом 10.0.0.1, а станции 192.168.0.2 и 192.168.0.3 – с узлом 192.168.0.1. Но пока обмен данными между разными сетями невозможен, так как еще не включена маршрутизация. После включения маршрутизации в оснастке «Маршрутизация и удаленный доступ» (Пуск – Настройка – Панель управления – Администрирование – Маршрутизация и удаленный доступ) обмен данными возможен между любыми узлами данной «составной» сети!

Фрагмент трафика сетевого взаимодействия (файл 2IP.cap):

Обратите внимание на характер взаимодействие: сначала станция 10.0.0.2 ищет МАС адрес своего шлюза по умолчанию (1-ый пакет) и получает ответ (2-ой пакет). После чего станция 10.0.0.2 отправляет кадр на свой маршрутизатор, в котором пакет для 192.168.0.2. Затем маршрутизатор от имени того же самого МАС адреса (так как порт тот же самый) отправляет ARP запрос в поисках МАС адреса станции 192.168.0.2 (пакет 3) и получает ответ (пакет 4). После чего маршрутизатор перенаправляет пакет узлу 192.168.0.2, при чем, так как все это происходит в одной канальной сети, КАЖДЫЙ IP пакет отображается дважды – в кадре от отправителя к маршрутизатору и в кадре от маршрутизатора получателю. Рассмотренная техника называется «локальная маршрутизация».

Где же используется подобная технология? Рассмотрим, зачем вообще может понадобиться подключать станции к одной канальной сети с различными номерами IP сетей, ведь никакой изоляции трафика, причем не только широковещательного, но и вообще никакого не происходит. Однако, маршрутизировать пакеты между узлами может быть более выгодно с точки зрения фильтрации трафика: коммутатор может позволить администратору указывать некоторые правила о том, кто с кем может обмениваться пакетами только на основании МАС адресов, в маршрутизаторах, обычно, фильтрация пакетов может выполняться гораздо более функционально.

Рассмотрим примеры использования локальной маршрутизации на практике:

  •  При росте сети предприятия появилась необходимость создать новую подсеть, однако аппаратных портов маршрутизатору не хватает. Пока будет приобретен новый маршрутизатор, задачу можно решить, применив локальную маршрутизацию.
  •  Маршрутизатор, используемый на предприятии вышел  из строя и должен быть заменен поставщиком через некоторое время, пока можно использовать имеющийся в наличии маршрутизатор с меньшим числом портов. Альтернативой могла бы стать частичная переадресация сети и переподключение станций с целью уменьшения количества подсетей, что, конечно, крайне нежелательно делать ради работы в течение нескольких дней пока не будет установлен новый маршрутизатор, так как это сопряжено с большим объемом работы, которую затем придется делать еще раз, после установки нового маршрутизатора.
  •  Необходимость разделения сети на подсети с целью фильтрации трафика в случае, когда приобретение нового коммуникационного оборудования (коммутатора) невозможно или затруднено. В таком случае, один из узлов сети можно снабдить двумя IP адресами и заставить маршрутизировать трафик между «подсетями». Ясно, что это имеет смысл только в очень небольших сетях и, каких то экстренных случаях.

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

  •  В одной канальной сети МОЖЕТ быть назначено несколько номеров IP сетей
  •  Порт маршрутизатора (и узла, кстати) может иметь более одного IP адреса
  •  Маршрутизатор может быть и однопортовым (хотя физический порт один, логически портов может быть столько, сколько IP адресов назначено физическому порту маршрутизатора)

Рассмотрим следующую ситуацию: подключение одной станции ДВУМЯ интерфейсами к одной сети (ситуация похожа на предыдущий пример, но тогда интерфейсы имели IP адреса из разных подсетей, а теперь адреса обоих интерфейсов принадлежат одной подсети). Для чего это может быть нужно? Очевидно, подобное подключение организуется с целью резервирования подключения к сети - если откажет один интерфейс, будет работать второй. Проанализируем эту ситуацию, привлекая уже известную логику работы IP узлов. Рассмотрим пример:

Станция А подключена к сети двумя интерфейсами: 192.168.0.13 и 192.168.0.14. Сможет ли эта станция работать более отказоустойчиво, нежели ее соседи, подключенные к сети одним интерфейсом? Для начала рассмотрим взаимодействия, инициированные от станции А к прочим станциям, а затем взаимодействия, инициированные от прочих станций к станции А.

Итак, пусть станция А хочет передать пакет станции 192.168.0.12. Очевидно, она может сделать это через два интерфейса, через какой же интерфейс она это сделает? Таблица маршрутизации узла имеет вид:

C:\>route print

===========================================================================

Активные маршруты:

Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика

       127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1

     192.168.0.0    255.255.255.0     192.168.0.13    192.168.0.13       20

     192.168.0.0    255.255.255.0     192.168.0.14    192.168.0.14       30

    192.168.0.13  255.255.255.255        127.0.0.1       127.0.0.1       20

    192.168.0.14  255.255.255.255        127.0.0.1       127.0.0.1       30

   192.168.0.255  255.255.255.255     192.168.0.13    192.168.0.13       20

   192.168.0.255  255.255.255.255     192.168.0.14    192.168.0.14       30

       224.0.0.0        240.0.0.0     192.168.0.13    192.168.0.13       20

       224.0.0.0        240.0.0.0     192.168.0.14    192.168.0.14       30

 255.255.255.255  255.255.255.255     192.168.0.13    192.168.0.13       1

 255.255.255.255  255.255.255.255     192.168.0.14    192.168.0.14       1

===========================================================================

Постоянные маршруты:

Из таблицы следует, что при необходимости отправить пакет станцией А в свою сеть 192.168.0.0/24 может быть использовано, как и ожидалось, два маршрута – строки 2 и 3 таблицы маршрутизации. Однако эти маршруты имеют различные метрики: маршрут через интерфейс 192.168.0.13 имеет метрику 20, а маршрут через интерфейс 192.168.0.13 имеет метрику 30. Т.е. пакет будет отправлен по маршруту с наименьшей метрикой (через интерфейс 192.168.0.13), но откуда возникли эти различные метрики?

Рассмотрим настройку метрики интерфейса в Windows:

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

C:\>route print

===========================================================================

Активные маршруты:

Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика

       127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1

     192.168.0.0    255.255.255.0     192.168.0.13    192.168.0.13       2

     192.168.0.0    255.255.255.0     192.168.0.14    192.168.0.14       1

    192.168.0.13  255.255.255.255        127.0.0.1       127.0.0.1       2

    192.168.0.14  255.255.255.255        127.0.0.1       127.0.0.1       1

   192.168.0.255  255.255.255.255     192.168.0.13    192.168.0.13       2

   192.168.0.255  255.255.255.255     192.168.0.14    192.168.0.14       1

       224.0.0.0        240.0.0.0     192.168.0.13    192.168.0.13       2

       224.0.0.0        240.0.0.0     192.168.0.14    192.168.0.14       1

 255.255.255.255  255.255.255.255     192.168.0.13    192.168.0.13       1

 255.255.255.255  255.255.255.255     192.168.0.14    192.168.0.14       1

===========================================================================

Постоянные маршруты:

 Internet Address      Physical Address      Type

 192.168.0.13          00-0e-a6-33-52-92     dynamic

 192.168.0.14          00-02-44-7e-5b-28     dynamic

Итак, через какой интерфейс станция А будет по умолчанию передавать пакеты в сеть 192.168.0.0/24 уже ясно – через тот, метрика которого меньше. При выполнении на станции А команды:

c:\ping 192.168.0.12 –t

происходит обмен пакетами. При этом обмен происходит между адресами 192.168.0.14 и 192.168.0.12.

Сымитируем отказ интерфейса извлечением сетевого кабеля из адаптера с адресом 192.168.0.14 - обмен пакетами продолжается (!) то есть, цель получить отказоустойчивость - достигнута.

Вернем кабель адаптера с адресом 192.168.0.14 в исходное – подключенное положение.

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

C:\>route print

===========================================================================

Активные маршруты:

Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика

       127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1

     192.168.0.0    255.255.255.0     192.168.0.13    192.168.0.13       2

    192.168.0.13  255.255.255.255        127.0.0.1       127.0.0.1       2

   192.168.0.255  255.255.255.255     192.168.0.13    192.168.0.13       2

       224.0.0.0        240.0.0.0     192.168.0.13    192.168.0.13       2

 255.255.255.255  255.255.255.255     192.168.0.13    192.168.0.13       1

===========================================================================

Постоянные маршруты:

 Сетевой адрес            Маска    Адрес шлюза      Метрика

        

Как видно в таблице остался только один маршрут в сеть 192.168.0.0/24, через интерфейс 192.168.0.13 с метрикой 2, но так как маршрутов с меньшей метрикой в эту сеть нет (и вообще больше никаких маршрутов в эту сеть больше нет), то именно этот маршрут и используется. Т.е. очередной эхо запрос станция А отправляет не от адреса 192.168.0.14, а от адреса 192.168.0.13. А станции 192.168.0.12 в целом все равно на чьи запросы отвечать – были запросы от 192.168.0.14 – она отвечала, стали приходить запросы от 192.168.0.13 – тоже отвечает.

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

Продолжим эксперименты – вместо простого тестирования соединения со станции А эхо запросами, попробуем обратиться со станции А к какой ни будь службе, размещенной на станции 192.168.0.12, например, к файловой службе. Будет ли снова наблюдаться отказоустойчивость в случае выхода из строя работающего интерфейса?

 Вернем схему в исходное рабочее состояние по умолчанию.

Теперь обращение к узлу  к узлу 192.168.0.12 осуществляется следующим образом:

\\192.168.0.12

Для проверки взаимодействия скопируем длинный файл с узла 192.168.0.12 на узел А.

В ходе копирования файла, происходит отказ сетевого адаптера (отключение кабеля от адаптера 192.168.0.14).

Через некоторое время оказывается, что передача файла прервалась. Отказоустойчивости нет! Почему?

Все дело в том, что при работе сетевых служб, отправляющих не единичные пакеты, а длительные потоки данных в стеке TCP/IP используется протокол TCP, выполняющий, в частности, сеансовые функции. Перед передачей данных между приложениями на узлах устанавливается TCP соединение, и важнейшими характеристиками этого соединения являются IP адреса тех узлов, которые его установили. Таким образом, когда соединение установлено между адресами 192.168.0.12 и 192.168.0.14, никакое наличие у станции А еще одного работающего интерфейса в этой же сети не поможет ей продолжить передачу данных в рамках установленного TCP соединения. При этом, если после сообщения об ошибке мы снова попытаемся скачать тот же файл, то у нас это получится, так как будет установлено новое соединение между адресами 192.168.0.12 и 192.168.0.13.

 Таким образом, в случае если взаимодействие  начинает станция с несколькими интерфейсами в одной канальной и IP сети, отказоустойчивость достигается только для тех приложений, которые отправляют единичные пакеты и получают на них ответы. В этом случае - максимум будет потерян один такой пакет. А в случае с приложениями, оперирующими потоками данных отказоустойчивости в случае сбоя в полном смысле слова не достигается, так как текущий обмен данными обязательно будет прерван, но после этого станция А может продолжать работать с другими станциями. Фактически теряется текущий сеанс работы, только в случае работы утилиты ping.exe или аналогичного приложения, отправляющего единичные пакеты сеанс – это и есть один пакет, но в случае приложений, оперирующих потоками данных и опирающихся на TCP, сеанс – это порой весьма большой объем потерянных данных. Так что говорить о серьезной отказоустойчивости в этом случае не приходится. Также в подобных «отказоустойчивых» схемах диагностика с помощью ICMP эхо может оказаться не такой уж и эффективной: если посмотреть только на работу программы ping.exe, могло бы показаться, что отказоустойчивость присутствует.

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

При этом если интерфейс 192.168.0.13 в момент обращения станции 192.168.0.12 не работает, очевидно, станция 192.168.0.12 не сможет на основании чего либо сделать вывод, что к станции А можно обратится по адресу 192.168.0.14 и поэтому взаимодействие не будет осуществлено. Очевидно, это справедливо и про интерфейс 192.168.0.14.

А что если 192.168.0.12 и 192.168.0.13 обменивались пакетами, и в процессе этого обмена интерфейс 192.168.0.13 отказал? Станция 192.168.0.12 будет продолжать передавать пакеты для адреса 192.168.0.13 и никаких оснований у интерфейса 192.168.0.14 отвечать на такие пакеты - нет. Таким образом, для взаимодействий, инициированных от прочих станций к станции с двумя интерфейсами в одной канальной и IP сети, отказоустойчивость не достигается вовсе.

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

Проанализируем следующую ситуацию – можно ли добиться отказоустойчивости при соединении маршрутизаторов несколькими линиями связи?

В этом примере два маршрутизатора соединены двумя сетями: 172.16.0.0/16 и 172.17.0.0/16. Можно ли в таком случае добиться отказоустойчивости взаимодействия сетей 10.0.0.0/8 и 192.168.0.0/24 в случае выхода из строя одной из сетей, связывающих маршрутизаторы?

Рассмотрим таблицы маршрутизации маршрутизаторов (без учета подключенных сетей):

Левый маршрутизатор:

Сеть получателя  Следующий шлюз   

10.0.0.0/8    172.16.0.2

10.0.0.0/8    172.17.0.2

Правый маршрутизатор:

Сеть получателя  Следующий шлюз   

192.168.0.0/24   172.16.0.1

192.168.0.0/24   172.17.0.1

Каждый маршрутизатор может попасть в удаленную от него сеть двумя путями, вероятно у этих двух маршрутов есть метрики, определяющие, какой из маршрутов предпочтителен, но это сейчас не играет роли. Положим, что левый маршрутизатор пакеты в сеть 10.0.0.0/8, а правый – в сеть 192.168.0.0/24 передают по умолчанию с помощью первой строки своих таблиц маршрутизации (например, потому, что сеть 172.16.0.0/16 быстрее сети 192.17.0.0/16). Что случится, если сеть 172.16.0.0/16 откажет? В этом случае, у обоих маршрутизаторов откажут интерфейсы в этой сети и таблицы маршрутизации этих маршрутизаторов примут вид:

Левый маршрутизатор:

Сеть получателя  Следующий шлюз   

10.0.0.0/8    172.17.0.2

Правый маршрутизатор:

Сеть получателя  Следующий шлюз   

192.168.0.0/24   172.17.0.1

Видно, что и в этом случае, передача пакетов между сетями 192.168.0.0/24 и 10.0.0.0/8 продолжится. Причем, в этой ситуации не будет наблюдаться того эффекта, который был в прошлом примере - так как IP адреса портов маршрутизаторов не отражаются в пакетах данных, которые они передают. Узлам вообще все равно, через какой маршрут они получили пакеты. Таким образом, при данной схеме подключения работа приложений, устанавливающих TCP соединения, продолжится так же, как и работа приложений, передающих единичные пакеты данных.

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

Рассмотрим пример:

Правый маршрутизатор R2 отправляет пакеты в левую тупиковую сеть через нижний интерфейс eth0 , так как верхний eth1 отказал. Но левый маршрутизатор R1 не знает, что у маршрутизатора R2 отказал интерфейс eth1 в верхней сети и продолжает слать пакеты в правую тупиковую сеть именно на него. Отказоустойчивости нет! Таким образом – для повышения отказоустойчивости важно соединять маршрутизаторы сетями типа точка-точка. Для этого хорошо подойдут кроссовые соединения в локальных сетях или глобальные сети с коммутацией каналов, или глобальные сети на базе выделенных каналов, в которых присутствует процедура установки.  

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

Рассмотрим следующий пример, иллюстрирующий особенности использования маршрутизации. Как отмечалось ранее, в одной канальной сети можно назначить узлам IP адреса из различных IP сетей и при этом узлы, принадлежащие к одному и тому же диапазону IP адресов, смогут взаимодействовать друг с другом, в то время как узлы из различных диапазонов IP адресов могут взаимодействовать только с помощью маршрутизатора. Предлагаемый пример, связан с назначением узлам одной канальной сети IP адресов из различных сетей. Пусть в канальной сети подключены три узла с адресами 1.0.0.1/8, 2.0.0.1/8 и 3.0.0.1/8. Эти узлы не могут обмениваться друг с другом пакетами без помощи маршрутизатора. При изменении настройки узлов, и указании в качестве шлюза по умолчанию на каждом ЕГО СОБСТВЕННЫЙ IP адрес получим следующую сеть:

Итак, пусть станция имеет настройки 1.0.0.1/8, шлюз по умолчанию – 1.0.0.1. Пусть эта станция собирается передать пакет станции 2.0.0.1. Спрогнозируем поведение отправителя используя логику IP узлов. Станция 1.0.0.1/8 имеет номер сети 1.0.0.0, накладывает свою маску на адрес получателя получается 2.0.0.0 – результатом является вывод: получатель расположен НЕ в одной сети с отправителем и необходимо передать пакет маршрутизатору по умолчанию. На самом же деле когда мы говорим, что  узел передает пакет маршрутизатору по умолчанию - мы упрощаем поведение узла. У каждого узла есть своя собственная таблица маршрутизации и в соответствии с ней происходит отправка пакетов. В данном случае при таких настройках шлюза по умолчанию в таблице маршрутизации узла будет присутствовать следующая запись:

Сеть получателя  Следующий шлюз   

0.0.0.0/0    1.0.0.1   

Что значит эта запись? Если в качестве адреса следующего маршрутизатора указан свой собственный порт, то это значит … что, сеть получателя подключена, и пакет необходимо отправлять непосредственно узлу получателю! А, раз сеть получателя подключена к порту 1.0.0.1, и пакет необходимо передавать получателю непосредственно, то станция 1.0.0.1 пошлет в сеть ARP запрос в поисках МАС адреса станции 2.0.0.1. В нашей сети, данный ARP запрос, отправленный широковещательно на канальном, как раз и достигнет получателя, т.е. станции 2.0.0.1 – которая, в свою очередь, пошлет ARP ответ и после этого станция 1.0.0.1 пошлет в кадре канального уровня в свою канальную сеть пакет для станции 2.0.0.1. Логика работы станции 2.0.0.1 аналогична – маска подсказывает ей, что станция 1.0.0.1 находится с ней в разных сетях, но указанный шлюз по умолчанию заставляет станцию 2.0.0.1 отправлять пакеты в адрес станции 1.0.0.1 тоже непосредственно в кадрах канального уровня в своей канальной сети, и таким образом обмен пакетами возможен.

Рассмотрим захват в анализаторе протоколов (файл addrgate.cap):

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

Анализ настройки станции может показаться противоречивым:

- маска показывает, какие узлы находятся с в одной канальной сети и косвенно показывает, что  все остальные узлы находятся с нами НЕ в одной канальной сети, в то время как настройки шлюза по умолчанию показывают станции, что ВСЕ узлы находятся с ней в одной канальной сети.

Если анализировать это противоречие абстрактно, не привязываясь к логике работы узлов, то решение не ясно, но так как логика работы узлов и маршрутизаторов известна – последовательно анализируем еще раз:

- Как себя ведет узел? Сначала с помощью маски убеждается, что получатель с нами не в одной сети. Затем находит строку таблицы маршрутизации, которая будет обрабатывает пакет, и применяем эту строку в соответствии с формальными правилами. Но адрес шлюза совпадает с адресом интерфейса и их МАС адреса известны, значит широковещательно нужно разрешать МАС адрес получателя IP пакета.

Рассмотрим примеры конфигурации оборудования Cisco с использованием эмуляторов.

Схема № 1

Host A 10.0.0.2 mask 255.0.0.0 gateway 10.0.0.1

Host B 10.0.0.3 mask 255.0.0.0 gateway 10.0.0.1

Host C 11.0.0.2 mask 255.0.0.0 gateway 11.0.0.1

Host D 11.0.0.3 mask 255.0.0.0 gateway 11.0.0.1

Router 10.0.0.1 & 11.0.0.1

Конфигурация маршрутизатора

Проверка взаимодействия со стороны узлов

И со стороны маршрутизатора

Схема № 2

Host A 10.0.0.2 mask 255.0.0.0 gateway 10.0.0.1

Host B 11.0.0.2 mask 255.0.0.0 gateway 11.0.0.1

Router a 10.0.0.1/8 ; 12.0.0.1/30; 13.0.0.1/30

Router b 11.0.0.1/8 ; 12.0.0.2/30; 13.0.0.2/30

Конфигурация RouterA

Конфигурация RouterB

Проверка взаимодействия маршрутизаторов

Проверка подключенных узлов

Настройка маршрутизации на RouterA

Аналогично для RouterB

Проверяем взаимодействие Host AHost B

После отключения интерфейса s0 на RouterA взаимодействие продолжается

Практическое задание.

1. Используя RouterSim CCNASim настроить маршрутизацию между хостами лежащих в разных IP сетях но подключенных в одну канальную сеть. В схему включить минимум один маршрутизатор.

2. Используя RouterSim CCNASim  разработать и настроить несколько отказоустойчивых схем взаимодействия с использованием двух и трех маршрутизаторов.


 

А также другие работы, которые могут Вас заинтересовать

43919. Модернизация учебной лабораторной установки для лаборатории гидравлики и теплотехники кафедры 34, МГИУ 3.17 MB
  По мере прикрытия дросселя общий уровень давления в вихревой трубе повышается, и расход холодного потока через отверстие диафрагмы увеличивается при соответствующем уменьшении расхода горячего потока. При этом температуры холодного и горячего потоков также изменяются.
43920. Проект разработки средств мокрой очистки технологических газов и мероприятий по охране труда в условиях мартеновского цеха ОАО «Запорожсталь» 927.5 KB
  В разделе КИП и А разработаны системы автоматического контроля и регулирования газоочистной установки мартеновской печи №7 ОАО Запорожсталь. Технология выплавки стали в мартеновских печах Устройство мартеновской печи Современная мартеновская печь представляет собой сложное техническое сооружение и состоит из двух основных частей: верхнего строения включающего рабочее пространство и головки печи и нижнего строения состоящего из шлаковиков боровов регулирующих устройств регенераторов и газопроводов.1...
43921. Использование сети Интернет в системе маркетинговых коммуникаций: состояние и перспективы развития на примере ОАО «Брестский райагросервис» 12.07 MB
  Как совокупность средств это комплекс содержания, носителей и способов передачи маркетинговой информации, позволяющий осуществлять информационные связи, контакты в виде рекламы, отношений с общественностью, прямого маркетинга (включая личные контакты) и смешанных видов (включая выставки, ярмарки и другие формы содействия продажам, сбыту).
43922. Использование ресурсов сети Интернет при изучении тем раздела «Социальная информатика» на базовом уровне 25.76 MB
  Под телематикой ученым понимается обработка информации на расстоянии. За этим стоит простая и глубокая мысль: развитие каналов связи отражает и уровень компьютеризации и объем накопленной информации и объективную потребность общества во всех видах информационного обмена и другие проявления информатизации. В последние полвека в развитых странах мира пропускная способность коммуникационных сетей передачи информации возрастала в среднем примерно в 10 раз за десятилетие. Развитие средств хранения передачи и обработки информации в...
43923. Разработка рекомендаций, направленных на совершенствование организации бухгалтерского учета и повышение эффективности использования денежных средств в ОАО «РЖД» 762.5 KB
  Денежные средства характеризуют начальную и конечную стадии кругооборота хозяйственных средств скорость движения которых во многом определяет эффективность всей деятельности организации. В условиях рыночной экономики следует исходить из принципа что умелое использование денежных средств может приносить организации дополнительный доход так как временно...
43924. Театралізовані ігри як засіб розвитку творчих здібностей першокласників на уроках музики 353.5 KB
  Театралізована гра як засіб розвитку творчих здібностей першокласників Загальна характеристика театралізованих ігор як методу розвитку творчих здібностей молодших школярів Методика розвитку творчих здібностей учнів 6річного віку в процесі використання театралізованих ігор на уроках музики Мистецтво з його унікальними можливостями цілісного впливу на особистість виступає не тільки джерелом естетичного виховання а й універсальним засобом творчого розвитку дитини.
43925. Системы налогообложения физических лиц в России на примере общества с ограниченной ответственность (ООО) «САПР ГРУПП» 961.5 KB
  В частности для обеспечения выполнения своих функций – защита внешних границ поддержание порядка внутри государства строительство содержание государственного аппарата и так далее – государству приходится облагать в том числе доходы и имущество граждан. Повышение налогов с населения увеличивает доходы бюджета только на один налоговый период так как уже в следующем база для их уплаты может резко сократиться. С другой стороны налог на доходы и имущество физических лиц имеет большое значение для формирования бюджета государства и его...
43926. Оптимизация производительности сети с использованием средств моделирования 12.06 MB
  Оптимизация производительности сети. В чем состоит планирование сети Использование моделирования для оптимизации производительности сети Влияние топологии связей и производительности коммуникационных устройств на пропускную способность сети