Таблица маршрутизации: статическая и динамическая на примере RIP, OSPF и EIGRP / Хабр

Таблица маршрутизации в Quagga / Хабр

По роду своей деятельности я занимаюсь проектированием сетей и настройкой сетевого оборудования. В какой-то момент времени мне захотелось узнать как-же устроены сетевые устройства, которые всегда представляли для меня черные ящики, магически реализующие сетевые протоколы. Поскольку устройства от вендоров типа Cisco или Juniper закрыты и не доступны для какого-либо изучения, то мой выбор пал на программу Quagga – маршрутизатор с открытыми исходными кодами, который достаточно широко используется в реальной жизни и довольно успешно справляется с протоколами OSPF и BGP. Вооружившись исходниками Quagga я приступил к исследованию. В данной статье я хочу рассказать как устроена таблица маршрутизации в Quagga, какие структуры и алгоритмы используются для ее реализации.

Архитектура Quagga

Для начала несколько слов об общей архитектуре Quagga. Quagga состоит из нескольких отдельных программ, или демонов, каждый из которых выполняет определенную функцию. Например, демон ospfd реализует протокол OSPF, а bgpd – протокол BGP. Центральную роль в Quagga выполняет демон zebra. Одна из основных его ролей заключается в получении маршрутной информации от демонов, реализующих конкретные протоколы и отборе лучших маршрутов, полученных из различных источников. После этого лучшие маршруты передаются в ядро Linux, которое собственно передает пользовательский трафик (считаем, что Quagga установлена на Linux). Таким образом реализуется классическое разделение «интеллекта» маршрутизатора (Control Plane) и передачи пользовательского трафика (Data Plane). В нашем случае в качестве Control Plane выступает Quagga, а в качестве Data Plane – ядро Linux. Таблица маршрутизации Quagga при этом находится внутри демона zebra.

Хранение маршрутной информации

Каждый отдельный маршрут в таблице маршрутизации можно представить как префикс (обычно обозначается как ip-адрес и длина префикса, например 192.168.0.0/24), с которыми связана различная маршрутная информация: next-hop, административная дистанция, метрика, протокол который сообщил о маршруте и т.д. Таблица маршрутизации представляет собой просто множество таких префиксов со связанной с ними дополнительной информацией. Демон zebra хранит все маршруты, которые ей были переданы или были настроены в самой zebra. Например, если был настроен статический маршрут 192.168.0.0/24 с next-hop 1.1.1.1, а также был получен маршрут с тем же префиксом из демона ospfd и с next-hop 2.2.2.2, то zebra будет хранить оба этих маршрута и покажет их в выводе команды show ip route. Хранение всех маршрутов позволяет быстро выбрать новый лучший маршрут, если по каким-либо причинам текущий лучший маршрут перестал существовать. Например, в нашем примере, после удаления статического маршрута, zebra сразу выберет в качестве лучшего маршрут OSPF без какого-либо обращения к демону ospfd. Маршруты для конкретного префикса хранятся в виде связного списка, как показано на рисунке (в данном случае для префикса 192.168.0.0/24). Зеленым помечен лучший маршрут.

При получении очередного маршрута его маршрутная информация добавляется в начало связного списка, после чего запускается процедура последовательного просмотра всех маршрутов для данного префикса и выбора наилучшего. Наилучшим маршрутом (при условии валидности next-hop) является маршрут с наименьшей административной дистанцией. Поскольку по-умолчанию у маршрутов от разных протоколов разная административная дистанция (например, у OSPF – 110, у статического маршрута – 1), то именно административная дистанция и является определяющим критерием для выбора наилучшего маршрута. В случае, если настройки таковы, что у разных маршрутов настроена одинаковая административная дистанция, то лучшим является маршрут с наименьшей метрикой. Если же у маршрутов совпадают и административная дистанция и метрика, то лучшим будет маршрут, который находится ближе к концу списка, т.е. тот, который был добавлен раньше.

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

После выбора наилучшего маршрута, информация о нем передается в ядро Linux.

Хранение префиксов

Как правило, маршрутов для одного префикса немного и просмотреть их все для выбора наилучшего много времени не занимает. Гораздо более сложная задача – при добавлении или удалении маршрута найти сам префикс. Различных префиксов в таблице маршрутизации может быть очень много – тысячи и десятки тысяч, и простой последовательный перебор всех префиксов для нахождения нужного будет крайне неэффективным. Для более быстрого и эффективного поиска все префиксы в таблице маршрутизации хранятся в виде структуры, называемой compact trie или сжатым бинарным префиксным деревом.

В дальнейшем префиксы будет более удобно представлять в двоичном виде, указывая при этом только первые биты, в количестве равном длине префикса. Остальные биты префикса равны 0 и не важны для поиска. Например, префикс 10.0.0.0/8 в двоичном виде будет выглядеть как 00001010, префикс 128.0.0.0/1 будет выглядеть как 1, 128.0.0.0/2 как 10 и т.д.

Что такое trie или префиксное дерево и как оно работает можно почитать, например, здесь. Для наших целей проще всего его понять на примере. Например, у нас есть префиксы 1, 111, 010, 0110000. Данные префиксы будут организованны в виде следующего префиксного дерева:

Белые узлы соответствуют интересующим нас префиксами. Желтые узлы являются промежуточными и служат для правильной организации структуры дерева. Верхний узел является корнем дерева и соответствует префиксу 0.0.0.0/0. Поиск нужного префикса выполняется следующим образом. Начинается поиск с корня дерева. Затем проверяется первый бит искомого префикса. Если первый бит равен 0, то спускаемся к левому дочернему элементу. Если первый бит равен 1, то к правому дочернему элементу. Затем повторяем данную процедуру для второго бита искомого префикса, затем для третьего и т.д. до тех пор, пока не дойдем до искомого префикса либо убедимся что его нет. При отсутствии нужного префикса он добавляется в дерево в соответствующее место. Видно, что число обращений к дереву равно длине искомого префикса и для самого длинного префикса IPv4 равно 32. Строго говоря в каждом узле дерева необязательно хранить сам префикс, поскольку он однозначно определяется местоположением узла, но я указал его для наглядности. Кроме того, в реальной структуре Quagga префикс действительно хранится в каждом узле дерева.

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

Теперь при поиске префикса в текущем узле проверяем, совпадают ли первые n бит искомого префикса с битами префикса в узле, где n – длина префикса в узле. Если биты совпадают, то смотрим в искомом префиксе n+1’й бит и в зависимости от того, равен он 0 или 1 спускаемся к левому или правому дочернему элементу.

Например, поиск префикса 011000 будет производиться следующим образом. Начинаем как обычно с корня дерева. Корень в нашем случае содержит префикс длины 0, поэтому проверяем первый бит искомого префикса. Поскольку он равен 0, то спускаемся к левому дочернему элементу и попадаем на узел с префиксом 01. Здесь мы сверяем искомый префикс с префиксом в текущем узле, т.е. совпадают ли первые 2 бита у префикса 011000 с префиксом 01. Поскольку биты совпадают, то двигаемся дальше и проверяем 3-й бит искомого префикса. Третий бит равен 1, поэтому спускаемся к правому дочернему элементу и попадаем в нужный нам префикс 011000. Для нахождения префикса понадобилось три обращения к дереву вместо семи в случае несжатого дерева. Если на каком-то этапе оказалось, что первые n бит префикса в узле не совпадают с битами искомого префикса, то это означает, что искомого префикса нет и он добавляется в дерево.

В Quagga префикс хранится в виде ip-адреса и длины префикса. При этом значение имеют только первые n-бит, где n-длина префикса, а остальные равны 0 и не участвуют в поиске нужного префикса. Например, префикс 192.168.1.0/24 выглядит как:

Для наглядности я отображу его следующим образом:

Здесь вверху я указываю привычный вид префикса в десятичном виде, а внизу – его двоичное представление, причем красным отмечено количество бит равное длине префикса. В таких обозначениях таблица маршрутизации, состоящая из префиксов 0.0.0.0/0, 10.0.0.0/8, 172.16.0.0/16, 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24 будет выглядеть так:

Для примера, при поиске префикса 192.168.1.0/24 последовательно проверяются его 1-й, 2-й, 23-й и 24-й биты для нахождения его местоположения в дереве. Каждый из наших префиксов указывает также и на соответствующую ему маршрутную информацию. Префиксы выделенные желтым являются промежуточными и для них маршрутная информация отсутствует.

Обход префиксного дерева

В заключение мне хотелось бы рассказать каким образов выводятся маршруты при наборе команды show ip route. Для вывода маршрутов необходимо каким-либо образом перебрать все префиксы в дереве. Данная процедура называется обходом дерева и может реализовываться различными способами. В Quagga используется метод обхода под названием pre-ordered и который проще всего определить рекурсивно:

• Сначала берем вершину дерева.
• Затем обходим левое поддерево.
• Затем обходим правое поддерево.

Для обхода поддеревьев используются те же самые правила. Для построенной нами выше таблицы маршрутизации обход префиксов будет выглядеть следующим образом. Сначала берем вершину дерева, т.е. префикс 0.0.0.0/0. Затем обходим левое поддерево. Оно у нас состоит из единственного префикса 10.0.0.0/8. Затем обходим правое поддерево, которое отобразим на рисунке:

Для его обхода применяем те же правила: сначала берем его корень, т.е. префикс 128.0.0.0/1, затем обходим его левое поддерево, т.е. префикс 172.16.0.0/16, затем правое поддерево, изображенное на рисунке:

Далее берем вершину данного поддерева, т.е. префикс 192.168.0.0/22, обходим его левое поддерево, получая префиксы 192.168.0.0/23, 192.168.0.0/24 и 192.168.1.0/24, и его правое поддерево, состоящее из префикса 192.168.2.0/24.

Таким образом, мы получим префиксы в следующем порядке: 0.0.0.0/0, 10.0.0.0/8, 128.0.0.0/1, 172.16.0.0/16, 192.168.0.0/22, 192.168.0.0/23, 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24. Префиксы 128.0.0.0/1, 192.168.0.0/22 и 192.168.0.0/23 являются служебными и не показываются при выводе таблицы маршрутизации. Оставшиеся префиксы отобразятся в порядке: 0.0.0.0/0, 10.0.0.0/8, 172.16.0.0/16, 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24.

Заключение

В заключение привожу список исходных файлов Quagga где реализованы вышеописанные структуры и алгоритмы:

Исходники Quagga можно скачать отсюда: download.savannah.gnu.org/releases/quagga. Я брал версию 0.99.24.

Структуры и функции для работы с префиксами находятся в файле lib/prefix.c.

Структуры и функции для работы с префиксным деревом находятся в файле lib/table.c

Структуры и функции для работы с маршрутной информацией находятся в файле zebra/zebra_rib.c

Таблица маршрутизации — Routing table

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

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

Обзор

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

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

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

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

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

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

Сложности

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

Содержание

Таблица маршрутизации состоит как минимум из трех информационных полей:

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

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

1. качество обслуживания, связанного с маршрутом. Например, флаг U указывает, что IP-маршрут установлен.
2. критерии фильтрации : списки контроля доступа, связанные с маршрутом
3. интерфейс : например, eth0 для первой карты Ethernet, eth2 для второй карты Ethernet и т. д.

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

• Столбцы Назначение сети и Маска сети вместе описывают идентификатор сети, как упоминалось ранее. Например, адрес назначения 192.168.0.0 и маска сети 255.255.255.0 могут быть записаны как 192.168.0.0/24 .
• Шлюз столбец содержит ту же самую информацию, что и следующего узла , т.е. он указывает на шлюз , через который сеть может быть достигнута.
• Интерфейс указывает на то , что локально доступный интерфейс отвечает за достижение шлюза. В этом примере к шлюзу 192.168.0.1 (интернет-маршрутизатор) можно получить доступ через локальную сетевую карту с адресом 192.168.0.100 .
• Наконец, Метрика указывает связанные с этим затраты на использование указанного маршрута. Это полезно для определения эффективности определенного маршрута из двух точек в сети. В этом примере более эффективно взаимодействовать с самим компьютером, используя адрес 127.0.0.1 (называемый «localhost»), чем через 192.168.0.100 (IP-адрес локальной сетевой карты).

Таблица пересылки

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

Эта архитектура маршрутизатора отделяет функцию плоскости управления таблицы маршрутизации от функции плоскости пересылки таблицы пересылки. Такое разделение управления и пересылки обеспечивает бесперебойную работу.

Смотрите также

Ссылки

внешние ссылки

Заполнение таблицы маршрутизации. Сетевые средства Linux

Заполнение таблицы маршрутизации

Таблица маршрутизации выполняет две задачи. Во-первых, она сообщает системе, на какой из интерфейсов следует передавать информационные пакеты. На первый взгляд может показаться, что если на компьютере установлен лишь один сетевой интерфейс, то ответ на этот вопрос очевиден. На самом деле это не так. Дело в том, что на каждом из компьютеров, работающих под управлением системы Linux, поддерживается интерфейс обратной петли. Этот интерфейс соответствует сети 127.0.0.0/8, но реально при работе с ним используется лишь один IP-адрес 127.0.0.1. Поскольку этот интерфейс присутствует на всех компьютерах, многие программы используют его для взаимодействия с другими локальными программами. При этом обеспечивается более высокая скорость обмена, чем при использовании традиционных сетевых интерфейсов. Для того чтобы распределять трафик между интерфейсом локальной петли и обычными сетевыми интерфейсами, существуют специальные правила. Вторая задача, которую выполняет таблица маршрутизации, состоит в управлении трафиком, предназначенным для компьютеров в локальной сети. Для маршрутизации в локальной сети используется протокол ARP (Address Resolution Protocol — протокол преобразования адресов). Пакеты, предназначенные узлам локальной сети, непосредственно передаются соответствующим компьютерам, а пакеты, адресованные удаленным узлам, передаются посредством маршрутизатора, или шлюза. В большинстве случаев в таблице маршрутизации Linux указывается лишь один шлюз, но встречаются также более сложные конфигурации с несколькими шлюзами. Для заполнения таблицы маршрутизации используется команда route.

На заметку

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

Структура таблицы маршрутизации

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

Для чтобы лучше понять, как используется таблица маршрутизации, рассмотрим пример такой таблицы. На рис. 2.2 показана таблица маршрутизации, которая отображается в результате выполнения команды route -n (более подробно команда route будет рассмотрена в следующем разделе). Записи таблицы, изображенной на рисунке, упорядочены так, что в начале расположены записи, определяющие наиболее конкретные правила обработки, а в конце таблицы находятся наиболее универсальные правила. В первой записи указан адрес назначения 255.255.255.255, т. е. широковещательный адрес. Широковещательные пакеты передаются через интерфейс eth0, при этом шлюз не используется. В последующих двух записях содержатся адреса назначения 10.92.68.0 и 192.168.1.0, которые представляют собой адреса локальных сетей; им соответствует маска подсети 255.255.255.0, которая указана в столбце Genmask. Эти две записи направляют трафик соответственно через интерфейсы eth2 и eth0. Если компьютер содержит только один сетевой интерфейс, в таблице маршрутизации будет указана лишь одна подобная запись. Четвертая запись соответствует интерфейсу обратной петли (в некоторых разновидностях Linux, например в системе Debian, при выводе таблицы маршрутизации этот маршрут не отображается, но он учитывается при обработке пакетов). Обратите внимание, что этот интерфейс имеет имя lo (оно содержится в столбце Ifасе таблицы). Последняя запись, в которой указан адрес назначения 0.0.0.0, определяет маршрут по умолчанию. Этот адрес вместе с маской подсети 0.0.0.0 соответствует любому адресу, при сравнении которого с адресами, указанными в предыдущих правилах, был получен отрицательный результат. В этом случае трафик направляется через интерфейс eth2. Маршрут по умолчанию — единственный маршрут в таблице, для которого был указан шлюз (в данном случае 10.92.68.1).

Рис. 2.2. Для того чтобы определить маршрут пакета, надо сравнить его адрес назначения с адресом, указанным в столбце Destination, и учесть при этом маску подсети, значение которой отображается в столбце Genmask

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

Использование route

Если утилита route вызывается без параметров, она отображает текущее содержимое таблицы маршрутизации. Такой же результат будет получен при указании некоторых опций (например, опции -n, которая указывает на то, что при выводе содержимого таблицы вместо доменных имен должны отображаться числовые IP-адреса). Однако в основном route предназначена для добавления, удаления и изменения записей о маршрутах. Синтаксис route имеет следующий вид:

route add|del [-net|-host] target [netmask nm] [gateway gw] [metric m] [mss m] [window W] [[dev] interface]

Ниже перечислены опции данной утилиты и описано их назначение.

• add|del. Опция add задается тогда, когда необходимо добавить в таблицу запись о новом маршруте, а опция del позволяет удалить существующую запись. При добавлении нового маршрута необходимо задать дополнительную информацию. При удалении можно ограничиться указанием адреса назначения.

• [-net|-host]. В качестве адреса назначения вы можете задать либо адрес сети (-net), либо адрес конкретного компьютера (-host). В большинстве случаев route способна самостоятельно отличить адрес сети от адреса узла, но иногда необходимо явно указать тип адреса. Чаще всего данную опцию приходится задавать, определяя маршрут к небольшой сети, подключенной с помощью отдельного шлюза.

• адрес_назначения. Адрес назначения принадлежит сети или отдельному компьютеру, которому маршрутизатор должен передать пакет. Для маршрута по умолчанию используется адрес 0.0.0.0 либо эквивалентное ему ключевое слово default. Этот параметр необходимо указывать при добавлении или удалении маршрута.

• [netmask nm]. Если адреса сети, которой должны быть переданы пакеты, соответствуют традиционной схеме распределения адресов, утилита route, пользуясь сетевыми средствами Linux, сама определит значение маски подсети. В противном случае вам необходимо явно задать маску подсети, указав при вызове route параметр netmask nm. (Вместо использования данного параметра вы можете указать число бит, выделяемых для представления адреса сети, в составе адреса назначения.)

• [gateway gw]. Если вы определяете маршрут, который не проходит через шлюз, можете не указывать этот параметр. Если же целевой узел подключен через шлюз, необходимо задать адрес этого шлюза, указав при вызове route gateway gw. В частности, данный параметр используется при определении маршрута по умолчанию.

• [metric m]. На рис. 2.2 среди прочих изображен столбец Metric. В нем отображается метрика маршрута, т.е. «стоимость» передачи пакета. Чаще всего за «стоимость» принимается время передачи пакета. Таким образом, маршрутам, на которых встречаются линии с низким быстродействием, соответствуют высокие значения метрики, а «быстрым» маршрутам — низкие значения метрики. Параметр metric m используется только в том случае, если компьютер выполняет роль маршрутизатора. Подробно вопросы настройки маршрутизаторов будут рассмотрены в главе 24.

• [mss m]. Параметр mss m задает максимальный размер сегмента (MSS — Maximum Segment Size). Подобно metric m, данный параметр используется в основном в маршрутизаторах.

• [window W]. Размер окна (TCP Window Size) — это объем данных, которые могут быть переданы передающим узлом, не дожидаясь получения подтверждения с принимающего узла. Если задано небольшое значение данного параметра, скорость обмена данными уменьшится, так как передающий компьютер будет простаивать, ожидая подтверждения приема пакета. Если указать слишком большой размер окна, повышается вероятность того, что вследствие возникновения ошибки передающему узлу придется повторять передачу большого объема информации. Поэтому наилучшее решение — использовать размер окна по умолчанию (в системе Linux он составляет 64 Кбайт). Если данные по линии передаются быстро, но с большой задержкой (например, если используется спутниковая связь), то целесообразно увеличить размер окна до 128 Кбайт.

• [[dev] имя_интерфейса]. Как правило, система Linux по IP-адресу самостоятельно определяет используемый интерфейс. Однако в некоторых случаях необходимо указать интерфейс явно, задавая при вызове route параметр [dev] имя_интерфейса. (Ключевое слово dev указывать не обязательно, достаточно задать имя интерфейса, например eth0 или tr1.)

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

# route add 0.0.0.0 gw 10.92.68.1

Адрес 0.0.0.0 можно заменить ключевым словом default; результат выполнения команды от этого не изменится. Несколько реже при вызове route приходится указывать имя устройства, опцию -net и некоторые другие опции.

Использование нескольких интерфейсов и одного шлюза

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

• Вызов ifconfig для каждого из интерфейсов компьютера.

• Одиночный вызов route для добавления в таблицу маршрутизации маршрута по умолчанию.

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

# echo "1" > /proc/sys/net/ipv4/ip_forward

На заметку

Если компьютер содержит два сетевых интерфейса (т.е. одновременно принадлежит двум сетям), но не должен выполнять функции маршрутизатора, не следует разрешать перенаправление IP-пакетов.

На заметку

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

Если провайдер выделил для вашего компьютера лишь один IP-адрес, но вы хотите организовать доступ к Internet с нескольких компьютеров, подключенных к локальной сети, вам необходимо использовать специальный тип маршрутизатора, в котором используется технология NAT (Network Address Translation — преобразование сетевых адресов). Эта технология подробно описана в главе 25. Настройка системы NAT выполняется подобно настройке обычного маршрутизатора, кроме того, в этом случае приходится выполнять дополнительные команды, разрешающие преобразование адресов. В результате такого преобразования вся локальная сеть выглядит извне как один компьютер.

Использование нескольких интерфейсов и шлюзов

Если компьютер с несколькими интерфейсами должен передавать пакеты на различные шлюзы, его настройка несколько усложняется. Большинство систем работает с одним шлюзом, через который проходит маршрут по умолчанию. Такой шлюз соединяет локальную сеть с другой сетью, и в большинстве случаев посредством этого же шлюза осуществляется взаимодействие с Internet. Однако возможны и другие варианты конфигурации сети. Рассмотрим локальные сети, представленные на рис. 2.3. Как видно на рисунке, две локальные сети, принадлежащие различным подразделениям одной организации, соединены с помощью маршрутизаторов. Конфигурация обычных компьютеров, принадлежащих этим сетям, очень проста; в маршруте по умолчанию в качестве адреса шлюза указан адрес маршрутизатора, через который локальная сеть подключена к другой сети. Несмотря на то что маршрутизатор сети Office 2 имеет два интерфейса, в маршруте по умолчанию, заданном в его таблице маршрутизации, роль шлюза играет маршрутизатор сети Office Маршрутизатор сети Office 1 имеет более сложную конфигурацию. Его маршрут по умолчанию обеспечивает обмен пакетами с Internet, кроме того, трафик, предназначенный для сети 172.20.0.0/16, должен передаваться на маршрутизатор Office 2. Чтобы такая передача пакетов могла выполняться, необходимо вызвать следующую команду:

# route add -net 172.20.0.0 netmask 255.255.0.0 gw 172.21.1.1

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

На заметку

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

В данном случае предполагается, что маршрутизатор Office 2 использует для соединения с маршрутизатором Office 1 сетевой интерфейс с адресом 172.21.1.1. Заметьте, что этот адрес не принадлежит сети Office 2 (все компьютеры сети Office 2 соединены с маршрутизатором Office 2 через один интерфейс, а маршрутизатор Office 1 подключен к нему через другой интерфейс). Если кроме приведенной выше команды для маршрутизатора Office 1 также задать с помощью утилиты route маршрут по умолчанию, то в результате в таблице маршрутизации будут определены два шлюза: один в качестве маршрута по умолчанию, а другой — для управления трафиком, предназначенным для сети Office 2. Заметьте, что остальные компьютеры в сети Office 1 не обязаны знать об особенностях настройки маршрутизатора, в них должна содержаться лишь информация о маршруте по умолчанию, в котором роль шлюза выполняет маршрутизатор этой сети.

Подобная конфигурация маршрутизатора может потребоваться и в других случаях. Предположим, что в сети Office 1 присутствует второй маршрутизатор, посредством которого локальная сеть подключается к Internet. При этом для каждого компьютера сети Office 1 должны быть определены два шлюза: шлюз по умолчанию, т.е. компьютер, посредством которого осуществляется соединение сети с Internet, и второй шлюз, через который походит маршрут к компьютерам сети Office 2. (Компьютеры сети Office 1 могут быть сконфигурированы и по-другому, для них может быть определен только шлюз по умолчанию, который, в свою очередь, будет передавать пакеты на второй шлюз. Как нетрудно заметить, использование такой конфигурации увеличивает трафик локальной сети.) Поскольку использование двух маршрутизаторов затрудняет настройку компьютеров, желательно использовать в сети один маршрутизатор.

Поделитесь на страничке

Следующая глава >

Таблица маршрутизации в сетях IP | Журнал сетевых решений/LAN

Представление информации о маршрутах в таблицах маршрутизации.

Структура таблицы маршрутизации стека TCP/IP, соответствуя общим принципам построения таблиц маршрутизации (см. предыдущий выпуск рубрики), зависит от конкретной реализации стека TCP/IP. В качестве примера рассмотрим несколько вариантов таблицы маршрутизации, с которыми мог бы работать маршрутизатор М1 в сети, представленной на Рисунке 1.

Если в качестве маршрутизатора М1 в данной сети применяется программный маршрутизатор MPR операционной системы Microsoft Windows NT, то его таблица маршрутизации могла бы иметь такой же вид, как в Таблице 1. Если на месте маршрутизатора М1 установить аппаратный маршрутизатор NetBuil-der II компании 3Com, то его таблица маршрутизации для этой же сети может выглядеть так, как показано в Таблице 2. В Таблице 3 помещена таблица маршрутизации для маршрутизатора М1, реализованного в виде программного маршрутизатора одной из версий операционной системы UNIX.

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

ОСНОВНЫЕ ПАРАМЕТРЫ ТАБЛИЦ МАРШРУТИЗАЦИИ

Несмотря на достаточно заметные внешние различия, во всех трех таблицах присутствуют все ключевые параметры, необходимые для работы маршрутизатора, которые мы рассмотрели ранее при обсуждении концепции маршрутизации. К таким параметрам, безусловно, относятся адрес сети назначения (столбцы Destination в маршрутизаторах NetBuilder и UNIX или Network Address в маршрутизаторе MPR) и адрес следующего маршрутизатора (столбцы Gateway в маршрутизаторах NetBuilder и UNIX или Gateway Address в маршрутизаторе MPR). Третий ключевой параметр — адрес порта, на который нужно направить пакет, в одних таблицах указывается прямо (поле Interface в таблице Windows NT), а в других — косвенно. Так, в таблице UNIX-маршрутизатора вместо адреса порта задается его условное наименование — le0 для порта с адресом 198.21.17.5, le1 для порта с адресом 213.34.12.3 и lo0 для внутреннего порта с адресом 127.0.0.1.

В маршрутизаторе NetBuilder II поле, указывающее выходной порт в какой-либо форме, вообще отсутствует. Это объясняется тем, что адрес выходного порта всегда можно косвенно определить по адресу следующего маршрутизатора. Например, попробуем определить по Таблице 2 адрес выходного порта для сети 56.0.0.0. Из таблицы видно, что следующим маршрутизатором для этой сети будет маршрутизатор с адресом 213.34.12.4. Адрес следующего маршрутизатора должен принадлежать одной из непосредственно присоединенных к маршрутизатору сетей, и в данном случае это сеть 213.34.12.0. Один из портов маршрутизатора подключен к этой сети, а его адрес 213.34.12.3 мы находим в поле Gateway второй строки таблицы маршрутизации, где указывается непосредственно присоединенная сеть 213.34.12.0. Для таких сетей адресом следующего маршрутизатора всегда будет адрес собственного порта маршрутизатора. Таким образом, адрес выходного порта для сети 56.0.0 — это 213.34.12.3.

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

Наличие или отсутствие поля маски в таблице говорит о том, насколько современен данный маршрутизатор. Стандартным решением сегодня является использование поля маски в каждой записи таблицы, как это сделано в таблицах маршрутизаторов MPR Windows NT (поле Netmask) и NetBuilder (поле Mask). Отсутствие поля маски говорит о том, что либо маршрутизатор рассчитан на работу только с тремя стандартными классами адресов, либо он использует для всех записей одну и ту же маску, а это снижает гибкость маршрутизации.

Как видно из примера таблицы Unix-маршрутизатора, метрика относится к необязательным параметрам. В остальных двух таблицах это поле имеется, однако оно используется только в качестве признака непосредственно подключенной сети. Действительно, если в таблице маршрутизации каждая сеть назначения упомянута только один раз, то поле метрики не будет приниматься во внимание при выборе маршрута, так как выбор отсутствует. А вот признак непосредственно подключенной сети маршрутизатору нужен, потому что пакет для этой сети обрабатывается особым способом — он не передается следующему маршрутизатору, а отправляется узлу назначения. Поэтому метрика 0 для маршрутизатора NetBuilder или 1 для маршрутизатора MPR сообщает, что эта сеть непосредственно подключена к конкретному порту. Другое значение метрики соответствует удаленной сети. Выбор значения метрики для непосредственно подключенной сети является достаточно произвольным, главное, чтобы метрика удаленной сети отсчитывалась с учетом этого выбранного начального значения. В UNIX-маршрутизаторе используется поле признаков, где флаг G отмечает удаленную сеть, а его отсутствие — непосредственно подключенную.

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

Флаги записей присутствуют только в таблице UNIX-маршрутизатора. Они описывают характеристики записи:

U показывает, что маршрут активен и работоспособен. Аналогичный смысл имеет поле Status в маршрутизаторе NetBuilder;

H — признак специфического маршрута к определенному хосту. Маршрут ко всей сети, к которой принадлежит данный хост, может отличаться от данного маршрута;

G означает, что маршрут пакета проходит через промежуточный маршрутизатор (gateway). Отсутствие этого флага указывает на непосредственно подключенную сеть;

D означает, что маршрут получен из сообщения Redirect (перенаправление) протокола ICMP. Такой признак может присутствовать только в таблице маршрутизации конечного узла. Он означает, что конечный узел при какой-то предыдущей передаче пакета выбрал не самый рациональный следующий маршрутизатор на пути к данной сети, и этот маршрутизатор с помощью протокола ICMP сообщил, что все последующие пакеты в данную сеть нужно отправлять через другой соседний маршрутизатор. Протокол ICMP может посылать сообщения только узлу-отправителю, поэтому на промежуточном маршрутизаторе этот признак встретиться не может. Признак никак не влияет на процесс маршрутизации, он только указывает администратору источник появления записи.

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

В таблице маршрутизатора NetBuil-der также имеются два справочных поля. Поле времени жизни TTL (Time To Live) имеет смысл для динамических записей, с ограниченным сроком жизни. Текущее значение поля показывает оставшийся срок жизни записи в секундах. Поле Source отражает источник появления записи в таблице маршрутизации. Хотя это поле присутствует не во всех таблицах маршрутизаторов, но практически для всех маршрутизаторов существует три основных источника появления записи в таблице.

ИСТОЧНИКИ И ТИПЫ ЗАПИСЕЙ В ТАБЛИЦЕ МАРШРУТИЗАЦИИ

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

Во-первых, это записи о непосредственно подключенных сетях и маршрутизаторах по умолчанию, информация о которых появляется в стеке при ручном конфигурировании интерфейсов компьютера или маршрутизатора. В приведенных примерах к ним относятся записи о сетях 213.34.12.0 и 198.21.17.0, а также о маршрутизаторе по умолчанию — default в UNIX-маршрутизаторе и 0.0.0.0 в маршрутизаторе MPR Windows NT. В рассматриваемой таблице для маршрутизатора NetBuilder маршрутизатор по умолчанию не используется, следовательно, при поступлении пакета с адресом назначения, отсутствующим в таблице, этот пакет будет отброшен.

Во-вторых, программное обеспечение автоматически заносит в таблицу маршрутизации записи об адресах особого назначения. В таблице маршрутизатора MPR Windows NT содержится наиболее полный набор записей такого рода. Несколько записей связаны с особым адресом 127.0.0.0 (loopback), который используется для локального тестирования стека TCP/IP. Пакеты, направленные в сеть с номером 127.0.0.0, не передаются протоколом IP на канальный уровень для последующего направления в сеть, а возвращаются в источник — локальный модуль IP. Записи с адресом 224.0.0.0 предназначены для обработки групповых адресов (multicast address). Кроме того, в таблицу могут быть занесены адреса для широковещательных рассылок (например, записи 8 и 11 содержат адрес отправки широковещательного сообщения в соответствующих подсетях, а последняя запись в таблице — адрес ограниченной широковещательной рассылки сообщения). Заметим, что в некоторых таблицах записи об особых адресах вообще отсутствуют.

Вторым источником появления записи в таблице является администратор, непосредственно формирующий ее с помощью некоторой системной утилиты, например программы route, имеющейся в операционных системах UNIX и Windows NT. В аппаратных маршрутизаторах также всегда поддерживается команда для ручного задания записей таблицы маршрутизации. Заданные вручную записи всегда являются статическими, т. е. не имеют срока истечения жизни. Они могут быть как постоянными, т. е. сохраняющимися при перезагрузке маршрутизатора, так и временными, хранящимися в таблице только до выключения устройства. Часто администратор вручную заносит запись default о маршрутизаторе по умолчанию. Таким же образом в таблицу маршрутизации может быть внесена запись о специфичном для узла маршруте, где вместо номера сети содержится полный IP-адрес, т. е. адрес, имеющий ненулевую информацию не только в поле номера сети, но и в поле номера узла. Для такого конечного узла маршрут должен выбираться не так, как для всех остальных узлов сети, к которой он относится. В случае, когда в таблице есть разные записи о продвижении пакетов для всей сети и ее отдельного узла, при поступлении пакета, адресованного узлу, маршрутизатор отдаст предпочтение записи с полным адресом узла.

И, наконец, третьим источником записей могут быть протоколы маршрутизации, такие, как RIP или OSPF. Данные записи всегда являются динамическими, т. е. имеют ограниченный срок жизни. Программные маршрутизаторы Windows NT и UNIX не показывают источник появления той или иной записи в таблице, а маршрутизатор NetBuilder использует для этой цели поле Source. В приведенном в Таблице 2 примере первые две записи созданы программным обеспечением стека на основании данных о конфигурации портов маршрутизатора — это показывает признак Connected. Следующие две записи обозначены как Static, что указывает на то, что их ввел вручную администратор. Последняя запись появилась в результате работы протокола RIP, поэтому в ее поле TTL имеется значение 160.

Наталья Олифер — ответственный редактор LAN. С ней можно связаться по адресу: [email protected].

Поделитесь материалом с коллегами и друзьями

НОУ ИНТУИТ | Лекция | Статическая маршрутизация

Аннотация: Рассмотрены основы функционирования и конфигурирования статической маршрутизации сетей IPv4, IPv6, а также маршрутизации по умолчанию. Приведены примеры конфигурирования маршрутизаторов. Проанализированы таблицы маршрутизации, методы отладки сети.

2.1. Основы статической маршрутизации

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

Статические маршруты полностью определены администратором, поэтому они более безопасны, требуют меньше вычислительных ресурсов и более узкую полосу пропускания по сравнению с динамическими маршрутами. Однако сети, использующие статическую маршрутизацию, плохо масштабируемы, при изменении топологии требуется внесение изменений администратором в конфигурацию, что может приводить к ошибкам. Поэтому статическая маршрутизация используется либо в малых сетях, либо в комбинации с протоколами динамической маршрутизации на отдельных участках сети. Статические маршруты, по сравнению с динамическими, характеризуются более высоким приоритетом, поскольку административное расстояние AD = 1 (см. табл. 1.1).

Статическая маршрутизация часто используется в тупиковых сетях, обмен данными с которыми реализуется через маршрутизатор, который подключен к одному соседнему маршрутизатору. При рассмотрении статической маршрутизации используется составная сеть, структурная схема которой приведена на
рис.
2.1. В приведенной схеме сети тупиковой является Сеть 1, а тупиковым маршрутизатором — R-А, поскольку он соединен только с маршрутизатором R-В. Все пакета из Сети 1 могут быть отправлены только через маршрутизатор R-А по стандартному статическому маршруту в маршрутизатор R-В.

Статическая маршрутизация используется также при создании маршрута по умолчанию, который указывает путь к сетям, не имеющим соответствующих входов в таблице маршрутизации. В схеме сети
рис.
2.1 пакеты с неизвестными адресами сетей назначения из маршрутизатора R-С можно направлять в Интернет, т.е. в сеть провайдера ISP. Адрес маршрута по умолчанию 0.0.0.0/0 означает любые адреса сетей с любыми масками.

Рис.
2.1.
Пример составной сети

Статическая маршрутизация также используется при формировании суммарных(объединенных) маршрутов, что сокращает количество записей в таблице маршрутизации (см. курс «Основы построения сетей пакетной коммутации»).

Кроме того, для создания резервных путей конфигурируются плавающие статические маршруты. Когда основной маршрут «падает», включается резервный, для чего администратор вручную задает резервному пути более высокое значение административного расстояния AD. Так если основной маршрут имеет административное расстояние 1, то резервному статическому пути следует задать AD> 1,например, AD = 5.

2.2. Конфигурирование статической маршрутизации

Чтобы сконфигурировать статическую маршрутизацию администратор должен задать маршруты ко всем возможным сетям назначения, которые не присоединены непосредственно к данному маршрутизатору. Например, из маршрутизатора R-A (
рис.
2.1), к которому прямо присоединены две сети (Сеть 1, Сеть 4), необходимо проложить маршруты к четырем оставшимся сетям (из шести представленных на схеме). К маршрутизатору R-Bпрямо присоединены 3 сети (Сеть 2, Сеть 4, Сеть 5), поэтому из него следует проложить 3 маршрута к оставшимся сетям.

Для конфигурирования статической маршрутизации используется команда ip route, которая содержит три параметра:

• адрес сети назначения,
• сетевую маску,
• адрес входного интерфейса следующего маршрутизатора на пути к адресату (next hop) или идентификатор выходного интерфейса.

Адрес входного интерфейса следующего маршрутизатора (следующего перехода) на пути к адресату иногда называют шлюзом. Например, для пакетов, попавших в маршрутизатор R-В, шлюзами будут:

1. Интерфейс s1/1 маршрутизатора R-A с адресом 200.4.4.11,
2. Интерфейс s1/2 маршрутизатора R-С с адресом 200.5.5.12.

Ниже приведен пример конфигурирования статической маршрутизации для Cisco-маршрутизатора R-В, когда используется адрес следующего перехода. Маршрутизатор R-В непосредственно связан с сетями 192.168.20.0, 200.4.4.0 и 200.5.5.0, поэтому статические маршруты нужно создать для остальных трех сетей, которые прямо не присоединены к R-В.

Router#config t
Router(config)#hostname R-B
R-B(config)#ip route 192.168.10.0 255.255.255.0 200.4.4.11
R-B(config)#ip route 192.168.30.0 255.255.255.0 200.5.5.12
R-B(config)#ip route 200.6.6.0 255.255.255.0 200.5.5.12
R-B(config)#exit
R-B#copy run start
  

Аналогично конфигурируются остальные маршрутизаторы.

Верификация статической конфигурации производится по командам show ip route и show running-config. Например, по команде show ip route отображается таблица маршрутизации:

R-B#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
	D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
	N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
	E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
	i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2,
	* - candidate default, U - per-user static route, o - ODR
	P - periodic downloaded static route

Gateway of last resort is not set

S	192.168.10.0/24 [1/0] via 200.4.4.11
C	192.168.20.0/24 is directly connected. FastEthernet0/0
S	192.168.30.0/24 [1/0] via 200.5.5.12 
C	200.4.4.0/24 is directly connected. Serial1/2
C	200.5.5.0/24 is directly connected. Serial1/1
S	200.6.6.0/24 [1/0] via 200.5.5.12  
R-B#
  

Символами С в таблице маршрутизации помечены непосредственно присоединенные к маршрутизатору R-В сети, а символом S — созданные администратором статические маршруты к удаленным сетям. Так статический маршрут к сети 192.168.10.0 проложен через интерфейс s1/1 маршрутизатора R-A с адресом 200.4.4.11, маршруты к двум другим сетям проложены через шлюз 200.5.5.12.Приведенные в распечатке значения [1/0] представляют собой административное расстояние AD = 1 и метрику = 0.

При получении маршрутизатором R-В пакета, адресованного, например, узлу в сети 192.168.30.0, производится обращение к таблице маршрутизации, где есть строка S 192.168.30.0/24 [1/0] via 200.5.5.12, в которой указано, что адресом следующего перехода будет 200.5.5.12. Однако в этой строке таблицы не указан выходной интерфейс, на который следует скоммутировать поступивший пакет. Поэтому определяется сеть адреса следующего перехода (200.5.5.0) и производится второе обращение к таблице маршрутизации, что называется рекурсией. Из таблицы следует, что сеть 200.5.5.0 присоединена к интерфейсу Serial1/1. Таким образом, при создании маршрутов следующего перехода производится рекурсивная обработка маршрута, т.е. два обращения к таблице, что замедляет процесс обработки маршрута.

Для ускорения процесса маршрутизации вместо адреса следующего перехода (next hop) можно задать идентификатор выходного интерфейса маршрутизатора и тем самым избежать рекурсивной обработки маршрута. При этом формируется прямо присоединенный статический маршрут. В процессе конфигурирования предварительно нужно удалить все ранее созданные статические маршруты по команде no ip route:

R-B(config)#no ip route 200.6.6.0 255.255.255.0 200.5.5.12
  

Ниже приведен пример конфигурирования маршрутизатора R-B (
рис.
2.1) с использованием выходного интерфейса:

R-B(config)#ip route 192.168.10.0 255.255.255.0 S1/2
R-B(config)#ip route 192.168.30.0 255.255.255.0 S1/1
R-B(config)#ip route 200.6.6.0 255.255.255.0 S1/1
  

В этом случае таблица маршрутизации выглядит следующим образом:

R-B#show ip route
...
Gateway of last resort is not set

S  192.168.10.0/24 is directly connected, Serial1/2
C  192.168.20.0/24 is directly connected, FastEthernet0/0
S  192.168.30.0/24 is directly connected, Serial1/1
C  200.4.4.0/24 is directly connected, Serial1/2
C  200.5.5.0/24 is directly connected, Serial1/1
S  200.6.6.0/24 is directly connected, Serial1/1
R-B#
  

Когда необходимо посмотреть только статические маршруты можно использовать команду show ip route static.

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

Созданные статические маршруты можно посмотреть не только по команде show ip route, когда в таблице маршрутизации отображаются адреса сетей назначения, но также с помощью команды show running-config (сокращенно sh run), часть распечатки которой приведена ниже:

R-B#show run
Building configuration...
...
interface FastEthernet0/0
 ip address 192.168.20.1 255.255.255.0
 duplex auto
 speed auto
!
interface Serial1/1
 ip address 200.5.5.11 255.255.255.0
 clock rate 64000
!
interface Serial1/2
 ip address 200.4.4.12 255.255.255.0
!
ip classless
ip route 192.168.30.0 255.255.255.0 Serial1/1 
ip route 192.168.10.0 255.255.255.0 Serial1/2 
ip route 200.6.6.0 255.255.255.0 Serial1/1 
!
R-B#
  

Однако использование прямо присоединенных (подключенных) статических маршрутов не всегда возможно. Например, если в сети
рис.
2.2 задать прямо присоединенный маршрут из R-A в сеть 192.168.30.0

R-А(config)#ip route 192.168.30.0 255.255.255.0 g0/1
  

то он не будет определен, поскольку из коммутатора Sw2, соединяющего интерфейс G0/1 маршрутизатора R-A и G0/0 маршрутизатора R-B, возможны и другие пути.

Рис.
2.2.
Пример соединения GigabitEthernet

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

R-А(config)#ip route 192.168.30.0 255.255.255.0 g0/1 192.168.20.2
  

В этом случае реализуется полностью заданный статический маршрут.

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

Маршруты удаляются из таблицы маршрутизации, если выходной интерфейс маршрутизатора прекращает функционирование. Поэтому при отладке сети необходимо проверять не только таблицу маршрутизации, но и состояние интерфейсов. Совокупность команд ping, show ip route, show running-config и show ip interface brief позволяет в большинстве случаев отладить сеть и устранить неполадки.

Маршрутизация — что это такое и как работает

23 ноября, 2019

Автор: Maksim

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

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

Итак, вы уже знаете, что такое UDP протокол и зачем он нужен, сейчас же мы разберем не менее интересную тему о том, как строятся пути для передачи информации в IP сетях.

Что такое маршрутизация

Маршрутизация (Routing) — это процесс по определению/вычислению лучшего маршрута движения для данных в сетях связи. Есть еще второе определение — это передача пакетов данных от отправителя к получателю.

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

Функцию роутинга могут выполнять:

• Аппаратные средства — маршрутизаторы. Самый оптимальный вариант, позволяющий обрабатывать большие потоки данных и работает он быстрее.
• Настроенные компьютеры с несколькими сетевыми интерфейсами и установленным на них специализированным и настроенным ПО. Обычно используется если конфигурация будет не слишком сложная.

Таблица маршрутизации

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

Таблица содержит:

• Адрес сети или узла
• Маску подсети назначения
• Сетевой шлюз или по-другому, адрес маршрутизатора на который будут направлены данные
• Интерфейс, с которого можно достучаться до шлюза
• Метрика (не всегда), т.е. показатель, который задает предпочтительность пути.

Может заполняться как вручную, так и автоматически.

Протокол маршрутизации

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

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

Маршрутизация в IP сетях

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

Информация на роутер поступает от других таких-же роутеров или от администратора. Составляется таблица — вручную или динамически. И, соответственно, пакеты данных отправляются.

Виды

Статическая маршрутизация

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

При задании такого маршрута назначается:

• Адрес и маска сети
• Адрес шлюза/узла
• Иногда указывается метрика и интерфейс, на который пойдет трафик

Плюсы:

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

Минусы:

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

Динамическая маршрутизация

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

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

В заключение

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

Маршрутизация трафика виртуальной сети Azure

• 26.10.2017
• На чтение 24 минуты

В этой статье

Узнайте, как Azure маршрутизирует трафик между Azure, локальными ресурсами и Интернет-ресурсами. Azure автоматически создает таблицу маршрутов для каждой подсети в виртуальной сети Azure и добавляет в таблицу системные маршруты по умолчанию.Чтобы узнать больше о виртуальных сетях и подсетях, см. Обзор виртуальной сети. Вы можете переопределить некоторые системные маршруты Azure с помощью настраиваемых маршрутов и добавить дополнительные настраиваемые маршруты в таблицы маршрутов. Azure направляет исходящий трафик из подсети на основе маршрутов в таблице маршрутов подсети.

Системные маршруты

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

По умолчанию

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

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

• Виртуальная сеть : Маршрутизирует трафик между диапазонами адресов в адресном пространстве виртуальной сети.Azure создает маршрут с префиксом адреса, который соответствует каждому диапазону адресов, определенному в адресном пространстве виртуальной сети. Если в адресном пространстве виртуальной сети определено несколько диапазонов адресов, Azure создает отдельный маршрут для каждого диапазона адресов. Azure автоматически направляет трафик между подсетями, используя маршруты, созданные для каждого диапазона адресов. Вам не нужно определять шлюзы для Azure для маршрутизации трафика между подсетями. Хотя виртуальная сеть содержит подсети, и каждая подсеть имеет определенный диапазон адресов, в Azure не , а не создают маршруты по умолчанию для диапазонов адресов подсети, поскольку каждый диапазон адресов подсети находится в пределах диапазона адресов адресного пространства виртуальной сети.

• Интернет : Маршрутизация трафика, указанного префиксом адреса, в Интернет. В системном маршруте по умолчанию указан префикс адреса 0.0.0.0/0. Если вы не переопределяете маршруты Azure по умолчанию, Azure направляет трафик для любого адреса, не указанного в диапазоне адресов в виртуальной сети, в Интернет, за одним исключением. Если адрес назначения предназначен для одной из служб Azure, Azure направляет трафик непосредственно в службу через магистральную сеть Azure, а не направляет трафик в Интернет.Трафик между службами Azure не проходит через Интернет, независимо от того, в каком регионе Azure существует виртуальная сеть или в каком регионе Azure развернут экземпляр службы Azure. Вы можете переопределить системный маршрут Azure по умолчанию для адреса 0.0.0.0/0. префикс с настраиваемым маршрутом.

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

  • 10.0.0.0 / 8 и 192.168.0.0/16 : зарезервировано для частного использования в RFC 1918.
  • 100.64.0.0/10 : Зарезервировано в RFC 6598.

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

Дополнительные маршруты по умолчанию

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

• Пиринг виртуальной сети (VNet) : при создании пиринга виртуальной сети между двумя виртуальными сетями добавляется маршрут для каждого диапазона адресов в адресном пространстве каждой виртуальной сети, для которой создается пиринг.Узнайте больше о пиринге виртуальных сетей.

• Шлюз виртуальной сети : Один или несколько маршрутов с Шлюз виртуальной сети , указанный как следующий тип перехода, добавляются при добавлении шлюза виртуальной сети в виртуальную сеть. Источником также является шлюз виртуальной сети , поскольку шлюз добавляет маршруты в подсеть. Если ваш локальный сетевой шлюз обменивается маршрутами протокола пограничного шлюза (BGP) со шлюзом виртуальной сети Azure, маршрут добавляется для каждого маршрута, распространяемого из локального сетевого шлюза.Рекомендуется суммировать локальные маршруты до максимально возможных диапазонов адресов, чтобы наименьшее количество маршрутов передавалось на шлюз виртуальной сети Azure. Существуют ограничения на количество маршрутов, которые можно распространить на шлюз виртуальной сети Azure. Дополнительные сведения см. В разделе ограничения Azure.

• VirtualNetworkServiceEndpoint : общедоступные IP-адреса для определенных служб добавляются в таблицу маршрутов с помощью Azure при включении конечной точки службы для службы.Конечные точки службы включены для отдельных подсетей в виртуальной сети, поэтому маршрут добавляется только в таблицу маршрутов подсети, для которой включена конечная точка службы. Общедоступные IP-адреса служб Azure периодически меняются. Azure автоматически управляет адресами в таблице маршрутов при изменении адресов. Узнайте больше о конечных точках служб виртуальной сети и службах, для которых вы можете создавать конечные точки служб.

  Примечание

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

Пользовательские маршруты

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

Определяется пользователем

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

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

• Виртуальное устройство : Виртуальное устройство — это виртуальная машина, которая обычно запускает сетевое приложение, например межсетевой экран. Чтобы узнать о различных предварительно настроенных сетевых виртуальных устройствах, которые можно развернуть в виртуальной сети, см. Azure Marketplace. При создании маршрута с типом перехода виртуального устройства вы также указываете IP-адрес следующего перехода.IP-адрес может быть:

  • Частный IP-адрес сетевого интерфейса, подключенного к виртуальной машине. Для любого сетевого интерфейса, подключенного к виртуальной машине, которая перенаправляет сетевой трафик на адрес, отличный от ее собственного, должен быть включен параметр «Включить пересылку IP » в Azure . Этот параметр отключает проверку Azure источника и назначения для сетевого интерфейса. Узнайте больше о том, как включить переадресацию IP для сетевого интерфейса. Хотя Включить переадресацию IP — это параметр Azure, вам также может потребоваться включить переадресацию IP в операционной системе виртуальной машины, чтобы устройство могло пересылать трафик между частными IP-адресами, назначенными сетевым интерфейсам Azure.Если устройство должно направлять трафик на общедоступный IP-адрес, оно должно либо проксировать трафик, либо сетевой адрес преобразовывать частный IP-адрес частного IP-адреса источника в свой собственный частный IP-адрес, который затем сетевой адрес Azure преобразует в общедоступный IP-адрес. адрес, перед отправкой трафика в Интернет. Чтобы определить необходимые параметры виртуальной машины, см. Документацию к вашей операционной системе или сетевому приложению. Чтобы понять исходящие подключения в Azure, см. Общие сведения об исходящих подключениях.

    Примечание

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

  • Частный IP-адрес внутренней подсистемы балансировки нагрузки Azure. Балансировщик нагрузки часто используется как часть стратегии высокой доступности для сетевых виртуальных устройств.

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

• Шлюз виртуальной сети : укажите, когда вы хотите, чтобы трафик, предназначенный для определенных адресных префиксов, направлялся на шлюз виртуальной сети.Шлюз виртуальной сети должен быть создан с типом VPN . Вы не можете указать шлюз виртуальной сети, созданный как тип ExpressRoute в определяемом пользователем маршруте, потому что с ExpressRoute вы должны использовать BGP для настраиваемых маршрутов. Вы можете определить маршрут, который направляет трафик, предназначенный для префикса адреса 0.0.0.0/0, на шлюз виртуальной сети на основе маршрута. У вас может быть устройство, которое проверяет трафик и определяет, следует ли перенаправить или сбросить трафик. Если вы намереваетесь создать определяемый пользователем маршрут для 0.Префикс адреса 0.0.0 / 0, сначала прочтите префикс адреса 0.0.0.0/0. Вместо настройки определяемого пользователем маршрута для префикса адреса 0.0.0.0/0 вы можете объявить маршрут с префиксом 0.0.0.0/0 через BGP, если вы включили BGP для шлюза виртуальной сети VPN.

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

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

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

Нельзя указать пиринг виртуальной сети или VirtualNetworkServiceEndpoint в качестве типа следующего прыжка в определяемых пользователем маршрутах.Маршруты с пирингом виртуальной сети или VirtualNetworkServiceEndpoint Типы следующего перехода создаются только в Azure, когда вы настраиваете пиринг виртуальной сети или конечную точку службы.

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

Протокол пограничного шлюза

Локальный сетевой шлюз может обмениваться маршрутами со шлюзом виртуальной сети Azure, используя протокол пограничного шлюза (BGP).Использование BGP со шлюзом виртуальной сети Azure зависит от типа, выбранного при создании шлюза. Если вы выбрали тип:

• ExpressRoute : необходимо использовать BGP для объявления локальных маршрутов к маршрутизатору Microsoft Edge. Вы не можете создать определяемые пользователем маршруты для принудительного прохождения трафика на шлюз виртуальной сети ExpressRoute, если развернете шлюз виртуальной сети, развернутый как тип: ExpressRoute. Вы можете использовать определяемые пользователем маршруты для принудительного направления трафика от экспресс-маршрута к, например, сетевому виртуальному устройству.
• VPN : при желании можно использовать BGP. Дополнительные сведения см. В разделе BGP с VPN-подключениями типа «сеть-сеть».

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

ER и распространение маршрута VPN-шлюза можно отключить в подсети с помощью свойства в таблице маршрутов.При обмене маршрутами с Azure с помощью BGP маршруты не добавляются в таблицу маршрутов всех подсетей с отключенным распространением маршрута через шлюз виртуальной сети. Связь с VPN-подключениями достигается с помощью настраиваемых маршрутов с типом следующего перехода Шлюз виртуальной сети . Распространение маршрута не должно быть отключено в GatewaySubnet. Шлюз не будет работать, если этот параметр отключен. Дополнительные сведения см. В разделе Как отключить распространение маршрута через шлюз виртуальной сети.

Как Azure выбирает маршрут

Когда исходящий трафик отправляется из подсети, Azure выбирает маршрут на основе IP-адреса назначения, используя алгоритм сопоставления самого длинного префикса.Например, в таблице маршрутов есть два маршрута: один маршрут указывает префикс адреса 10.0.0.0/24, а другой маршрут указывает префикс адреса 10.0.0.0/16. Azure направляет трафик, предназначенный для 10.0.0.5, на следующий тип прыжка, указанный в маршруте с префиксом адреса 10.0.0.0/24, поскольку 10.0.0.0/24 является более длинным префиксом, чем 10.0.0.0/16, хотя 10.0.0.5 находится внутри обоих адресных префиксов. Azure направляет трафик, предназначенный для 10.0.1.5, на следующий тип прыжка, указанный в маршруте с префиксом адреса 10.0.0.0/16, поскольку 10.0.1.5 не входит в префикс адреса 10.0.0.0/24, поэтому маршрут с префиксом адреса 10.0.0.0/16 является самым длинным совпадающим префиксом.

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

1. Пользовательский маршрут
2. Маршрут BGP
3. Системный маршрут

Примечание

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

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

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

См. Пример маршрутизации для получения исчерпывающей таблицы маршрутизации с пояснениями маршрутов в таблице.

0.0.0.0/0 префикс адреса

Маршрут с префиксом адреса 0.0.0.0/0 указывает Azure, как маршрутизировать трафик, предназначенный для IP-адреса, который не входит в префикс адреса любого другого маршрута в таблице маршрутов подсети. При создании подсети Azure создает маршрут по умолчанию для префикса адреса 0.0.0.0/0 с типом следующего прыжка Internet . Если вы не переопределите этот маршрут, Azure направит весь трафик, предназначенный для IP-адресов, не включенных в префикс адреса любого другого маршрута, в Интернет.Исключением является то, что трафик на общедоступные IP-адреса служб Azure остается в магистральной сети Azure и не направляется в Интернет. Если вы переопределите этот маршрут с помощью настраиваемого маршрута, трафик, предназначенный для адресов, не входящих в префиксы адресов любого другого маршрута в таблице маршрутов, отправляется на сетевое виртуальное устройство или шлюз виртуальной сети, в зависимости от того, что вы указали в настраиваемом маршруте.

Когда вы переопределяете префикс адреса 0.0.0.0/0, помимо исходящего трафика из подсети, проходящего через шлюз виртуальной сети или виртуальное устройство, в маршрутизации по умолчанию Azure происходят следующие изменения:

• Azure отправляет весь трафик на следующий тип прыжка, указанный в маршруте, включая трафик, предназначенный для общедоступных IP-адресов служб Azure.Когда типом следующего прыжка для маршрута с префиксом адреса 0.0.0.0/0 является Internet , трафик из подсети, предназначенный для общедоступных IP-адресов служб Azure, никогда не покидает магистральную сеть Azure, независимо от региона Azure, виртуальной сети или Ресурс службы Azure существует в. При создании определяемого пользователем маршрута или маршрута BGP с шлюзом виртуальной сети или Виртуальное устройство типа следующего перехода, однако, весь трафик, включая трафик, отправленный на общедоступные IP-адреса служб Azure, у вас нет Включенные конечные точки службы для, отправляются на следующий тип прыжка, указанный в маршруте.Если вы включили конечную точку службы для службы, трафик к службе не направляется на следующий тип прыжка в маршруте с префиксом адреса 0.0.0.0/0, поскольку префиксы адресов для службы указаны в маршруте, который Azure создается, когда вы включаете конечную точку службы, а префиксы адресов для службы длиннее 0.0.0.0/0.

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

  • Виртуальное устройство : Устройство должно:

    • Быть доступным из Интернета
    • Присвойте ему публичный IP-адрес,
    • Нет связанного с ним правила группы безопасности сети, которое предотвращает обмен данными с устройством
    • Не отказывать в связи
    • Уметь транслировать и пересылать сетевой адрес или проксировать трафик на целевой ресурс в подсети и возвращать трафик обратно в Интернет.

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

Если ваша виртуальная сеть подключена к VPN-шлюзу Azure, не связывайте таблицу маршрутов с подсетью шлюза, которая включает маршрут с местом назначения 0.0,0.0 / 0. Это может помешать правильной работе шлюза. Для получения дополнительной информации см. Почему на моем VPN-шлюзе открываются определенные порты? Вопрос в FAQ по VPN-шлюзу.

См. DMZ между Azure и вашим локальным центром обработки данных для получения подробной информации о реализации при использовании виртуальных сетевых шлюзов между Интернетом и Azure.

Пример маршрута

Чтобы проиллюстрировать концепции, изложенные в этой статье, в следующих разделах описывается:

• Сценарий с требованиями
• Пользовательские маршруты, необходимые для выполнения требований
• Таблица маршрутов, существующая для одной подсети, которая включает стандартные и настраиваемые маршруты, необходимые для удовлетворения требований

Примечание

Этот пример не предназначен для использования в качестве рекомендуемой или передовой практики.Скорее, он предоставляется только для иллюстрации концепций в этой статье.

Требования

1. Реализуйте две виртуальные сети в одном регионе Azure и включите ресурсы для обмена данными между виртуальными сетями.

2. Обеспечьте безопасную связь локальной сети с обеими виртуальными сетями через VPN-туннель через Интернет. В качестве альтернативы можно использовать соединение ExpressRoute, но в этом примере используется соединение VPN.

3. Для одной подсети в одной виртуальной сети:

   • Заставить весь исходящий трафик из подсети, за исключением хранилища Azure и внутри подсети, проходить через сетевое виртуальное устройство для проверки и ведения журнала.
   • Не проверять трафик между частными IP-адресами внутри подсети; разрешить трафику течь напрямую между всеми ресурсами.
   • Отбросьте весь исходящий трафик, предназначенный для другой виртуальной сети.
   • Включите исходящий трафик в хранилище Azure, чтобы он передавался непосредственно в хранилище, не заставляя его проходить через сетевое виртуальное устройство.

4. Разрешить весь трафик между всеми другими подсетями и виртуальными сетями.

Реализация

На следующем рисунке показана реализация модели развертывания с помощью Azure Resource Manager, которая отвечает предыдущим требованиям:

Стрелки показывают движение транспорта.

Маршрутные столы

Подсеть1

Таблица маршрутов для Subnet1 на рисунке содержит следующие маршруты:

Ниже приводится объяснение каждого идентификатора маршрута:

1. Azure автоматически добавила этот маршрут для всех подсетей в Virtual-network-1 , потому что 10.0.0.0/16 — единственный диапазон адресов, определенный в адресном пространстве для виртуальной сети. Если пользовательский маршрут в маршруте ID2 не был создан, трафик, отправленный на любой адрес между 10.0.0.1 и 10.0.255.254, будет маршрутизироваться в виртуальной сети, поскольку префикс длиннее 0.0.0.0 / 0, а не в адресных префиксах любого из других маршрутов. Azure автоматически изменила состояние с Active на Invalid , когда был добавлен ID2, определяемый пользователем маршрут, поскольку он имеет тот же префикс, что и маршрут по умолчанию, а определяемые пользователем маршруты переопределяют маршруты по умолчанию. Состояние этого маршрута по-прежнему Активный для Подсети2 , поскольку таблица маршрутов, в которой находится пользовательский маршрут, ID2, не связана с Подсети2 .
2. Azure добавил этот маршрут, когда пользовательский маршрут для 10.Префикс адреса 0.0.0 / 16 был связан с подсетью Subnet1 в виртуальной сети Virtual-network-1 . Определяемый пользователем маршрут указывает 10.0.100.4 в качестве IP-адреса виртуального устройства, так как этот адрес является частным IP-адресом, назначенным виртуальной машине виртуального устройства. Таблица маршрутов, в которой существует этот маршрут, не связана с Subnet2 , поэтому не отображается в таблице маршрутов для Subnet2 . Этот маршрут переопределяет маршрут по умолчанию для 10.Префикс 0.0.0 / 16 (ID1), который автоматически перенаправляет трафик, адресованный 10.0.0.1 и 10.0.255.254 в виртуальной сети через тип следующего перехода виртуальной сети. Этот маршрут существует для удовлетворения требования 3, чтобы направить весь исходящий трафик через виртуальное устройство.
3. Azure добавила этот маршрут, когда определяемый пользователем маршрут для префикса адреса 10.0.0.0/24 был связан с подсетью Subnet1 . Трафик, предназначенный для адресов между 10.0.0.1 и 10.0.0.254, остается внутри подсети, а не направляется на виртуальное устройство, указанное в предыдущем правиле (ID2), поскольку оно имеет более длинный префикс, чем маршрут ID2.Этот маршрут не был связан с Subnet2 , поэтому маршрут не отображается в таблице маршрутов для Subnet2 . Этот маршрут эффективно заменяет маршрут ID2 для трафика в пределах Подсети 1 . Этот маршрут существует для удовлетворения требования 3.
4. Azure автоматически добавлял маршруты в идентификаторы 4 и 5 для всех подсетей в Virtual-network-1 , когда виртуальная сеть была подключена к Virtual-network-2. Virtual-network-2 имеет два диапазона адресов в адресном пространстве: 10.1.0.0 / 16 и 10.2.0.0/16, поэтому Azure добавила маршрут для каждого диапазона. Если пользовательские маршруты в идентификаторах маршрутов 6 и 7 не были созданы, трафик, отправленный на любой адрес между 10.1.0.1-10.1.255.254 и 10.2.0.1-10.2.255.254, будет перенаправлен в пиринговую виртуальную сеть, потому что префикс длиннее 0.0.0.0/0 и не входит в адресные префиксы любого из других маршрутов. Azure автоматически изменила состояние с Активный на Недействительный при добавлении маршрутов с идентификаторами 6 и 7, поскольку они имеют те же префиксы, что и маршруты с идентификаторами 4 и 5, а пользовательские маршруты переопределяют маршруты по умолчанию.Состояние маршрутов в ID 4 и 5 по-прежнему Active для Subnet2 , поскольку таблица маршрутов, в которой находятся определяемые пользователем маршруты в ID 6 и 7, не связана с Subnet2 . Пиринг виртуальной сети был создан для удовлетворения требования 1.
5. То же объяснение, что и ID4.
6. Azure добавила этот маршрут и маршрут в ID7, когда определенные пользователем маршруты для префиксов адресов 10.1.0.0/16 и 10.2.0.0/16 были связаны с подсетью Subnet1 .Трафик, предназначенный для адресов между 10.1.0.1-10.1.255.254 и 10.2.0.1-10.2.255.254, отбрасывается Azure, а не направляется в пиринговую виртуальную сеть, поскольку определяемые пользователем маршруты переопределяют маршруты по умолчанию. Маршруты не связаны с Subnet2 , поэтому маршруты не отображаются в таблице маршрутов для Subnet2 . Маршруты переопределяют маршруты ID4 и ID5 для трафика, выходящего из подсети и . Маршруты ID6 и ID7 существуют для удовлетворения требования 3 для отбрасывания трафика, предназначенного для другой виртуальной сети.
7. То же объяснение, что и ID6.
8. Azure автоматически добавила этот маршрут для всех подсетей в Virtual-network-1 при

4.8. Таблицы маршрутизации

Ядро Linux 2.2 и 2.4 поддерживает несколько таблиц маршрутизации
.
Помимо двух обычно используемых таблиц маршрутизации
(местные и
основные таблицы маршрутизации),
ядро поддерживает до 252 дополнительных таблиц маршрутизации.

Система с несколькими таблицами маршрутизации обеспечивает гибкую инфраструктуру на
верхняя часть которого для реализации политики маршрутизации.Допуская несколько
традиционные таблицы маршрутизации (привязанные в основном к адресу назначения)
быть объединенным с
база данных политик маршрутизации (RPDB)
(с ключом в первую очередь к исходному адресу),
ядро поддерживает хорошо известный и понятный интерфейс, а
одновременно расширяя и расширяя свои возможности маршрутизации.
Каждая таблица маршрутизации по-прежнему работает в традиционном и ожидаемом
мода. Linux просто позволяет вам выбирать из
количество таблиц маршрутизации, а также для просмотра таблиц маршрутизации в
определяемая пользователем последовательность, пока не будет найден соответствующий маршрут.

Любая заданная таблица маршрутизации может содержать произвольное количество записей,
каждая из которых основана на следующих характеристиках (см.
Таблица 4.1, «Ключи, используемые для поиска в хэш-таблице при выборе маршрута»)

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

Ядра, поддерживающие несколько таблиц маршрутизации, относятся к таблицам маршрутизации по
уникальные целочисленные слоты от 0 до 255
.Обычно используются две таблицы маршрутизации:
таблица 255,
локальная таблица маршрутизации и
таблица 254,
основная таблица маршрутизации . За
примеры использования нескольких таблиц маршрутизации см.
Chapter9, Advanced IP Management , в частности,
Пример10.1, «Множественные исходящие Интернет-ссылки, часть I;
ip route »,
Пример10.3, «Множественные исходящие Интернет-ссылки, часть III;
ip rule »и
Example10.4, «Множественные интернет-ссылки, входящий трафик; с помощью
только iproute2

».Также будь уверен
читать
Раздел 10.3, «Использование базы данных политик маршрутизации и множественной маршрутизации
Таблицы »и
Раздел 4.9, «База данных политик маршрутизации (RPDB)».

Команды ip route и ip rule
встроили поддержку специальных таблиц main и local .
На любые другие таблицы маршрутизации можно ссылаться по номеру или
файл отображения, обслуживаемый администратором,
/ и т.д. / iproute2 / rt_tables .

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

Пример 4.6. Типичное содержание
/ etc / iproute2 / rt_tables

Таблица маршрутизации, управляемая обычным
маршрут команда
это основная таблица маршрутизации .Кроме того, использование обоих
IP-адрес и
ifconfig
заставит ядро ​​изменить локальную таблицу маршрутизации (и обычно
основная таблица маршрутизации). Для получения дополнительной документации о том, как манипулировать
другие таблицы маршрутизации, см. описание команды
ip маршрут .

4.8.1. Записи в таблице маршрутизации (маршруты)

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

Каждый из следующих типов маршрутов доступен для использования с
команда ip route . Каждый тип маршрута вызывает
особый вид поведения, который определяется в текстовом
описание. Сравните типы маршрутов, описанные ниже, с
доступные типы правил
для использования в RPDB.

одноадресная

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

Пример 4.7. Типы одноадресных маршрутов

ip route добавить одноадресную рассылку 192.168.0.0/24 через 192.168.100.5 ip route добавить значение по умолчанию через 193.7.255.1 ip route добавить одноадресную рассылку по умолчанию через 206.59.29.193 ip route добавить 10.40.0.0/16 через 10.72.75.254

трансляция

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

и обычно обрабатывается ядром.

Пример 4.8. Типы маршрутов широковещательной передачи

ip route add table local broadcast 10.10.20.255 dev eth0 proto kernel scope link src 10.10.20.67 ip route add table local broadcast 192.168.43.31 dev eth5 proto kernel scope link src 192.168.43.14

местный

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

Пример 4. 9. локальные типы маршрутов

ip route add table local local 10.10.20.64 dev eth0 proto kernel scope host src 10.10.20.67 ip route add table local local 192.168.43.12 dev eth5 proto kernel scope host src 192.168.43.14

нац

Эта запись маршрута добавляется ядром в локальную маршрутизацию.
таблица, когда пользователь пытается настроить NAT без сохранения состояния.Увидеть
Раздел 5.3, «NAT без сохранения состояния с iproute2 » для более полного обсуждения
трансляция сетевых адресов в целом.
.

Пример 4.10. Типы маршрутов nat

ip route добавить nat 193.7.255.184 через 172.16.82.184 ip route добавить нат 10.40.0.0/16 через 172.40.0.0

недоступен

Когда запрос на решение о маршрутизации возвращает пункт назначения
с недостижимым типом маршрута недоступен ICMP
генерируется и возвращается на исходный адрес.

Пример 4.11. Типы недоступных маршрутов

ip route добавить недоступный 172.16.82.184 ip route добавить недоступный 192.168.14.0/26 ip route добавить недоступен 209.10.26.51

запретить

Когда запрос решения о маршрутизации возвращает пункт назначения с
запрещенный тип маршрута, ядро ​​генерирует запрещенный ICMP
вернуться к исходному адресу.

Пример 4.12. Типы запрета маршрута

ip route добавить запретить 10.21.82.157 ip route добавить запретить 172.28.113.0/28 ip route добавить запретить 209.10.26.51

черная дыра

Пакет, соответствующий маршруту с типом маршрута blackhole,
отброшен. ICMP не отправляется и пакеты не пересылаются.

Пример 4.13. Типы маршрута черной скважины

ip route добавить blackhole по умолчанию ip route добавить blackhole 202.143.170.0/24 ip route добавить черную дыру 64.65.64.0/18

выброс

Тип маршрута throw — это удобный тип маршрута, который вызывает
поиск маршрута в таблице маршрутизации потерпел неудачу, возвращая
выбор маршрута
процесс в RPDB.Это полезно, когда есть
дополнительные таблицы маршрутизации. Обратите внимание, что есть неявный бросок
если в таблице маршрутизации нет маршрута по умолчанию, поэтому маршрут
созданный первой командой в примере является лишним,
хотя законно.

Пример 4.14. Типы маршрута заброса

ip route добавить бросить по умолчанию ip route добавить бросок 10.79.0.0/16 ip route добавить бросок 172.16.0.0 / 12

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

4.8.2. Таблица локальной маршрутизации

Локальная таблица маршрутизации поддерживается ядром.Обычно
локальная таблица маршрутизации не должна изменяться,
но он доступен для просмотра. В
ПримерD.12, «Просмотр локальной таблицы маршрутизации с помощью ip route show
table local »вы увидите два
распространенное использование локальной таблицы маршрутизации. Первое распространенное использование — это
спецификация широковещательного адреса, необходимая только для канальных уровней
которые поддерживают широковещательную адресацию. Второй распространенный тип входа
в локальной таблице маршрутизации — это маршрут к локально размещенному IP.

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

Если у аппарата несколько IP-адресов на одном интерфейсе Ethernet,
будет маршрут к каждому локально размещенному IP-адресу в локальной маршрутизации
Таблица. Это нормально
побочный эффект
поднять IP-адрес на интерфейсе под Linux.Ведение широковещательных и локальных маршрутов в локальной маршрутизации
table может быть выполнено только ядром.

Пример 4.15. Обслуживание ядра локальной таблицы маршрутизации

  [root @ real-server] #    ip-адрес показать dev eth2  
  6: eth2:  mtu 1500 qdisc pfifo_fast qlen 100
   ссылка / эфир 00: 80: c8: e8: 1e: fc brd ff: ff: ff: ff: ff: ff
   инет 10.10.20.89 / 24 brd 10.10.20.255 сфера применения global eth2 
  [root @ real-server] #    ip route show dev eth2  
  10.10.20.0/24 ссылка на область видимости ядра прото src 10.10.20.89 
  [root @ real-server] #    ip route show dev eth2 table local  
  трансляция 10.10.20.0 ссылка на область видимости прото ядра src 10.10.20.89
широковещательная передача 10.10.20.255 ссылка на область видимости ядра src 10.10.20.89
локальный 10.10.20.89 прото-ядро область видимости хост src 10.10.20.89 
  [root @ real-server] #    IP-адрес добавить 192.168.254.254 / 24 brd + dev eth2  
  [root @ real-server] #    ip-адрес показать dev eth2  
  6: eth2:  mtu 1500 qdisc pfifo_fast qlen 100
   ссылка / эфир 00: 80: c8: e8: 1e: fc brd ff: ff: ff: ff: ff: ff
   inet 10.10.20.89/24 brd 10.10.20.255 область действия global eth2
   inet 192.168.254.254/24 brd 192.168.254.255 область действия глобальная eth2 
  [root @ real-server] #    ip route show dev eth2  
  10.10.20.0/24 ссылка на область видимости ядра прото src 10.20.10.89
192.168.254.0/24 ссылка на область видимости ядра прото src 192.168.254.254 
  [root @ real-server] #    ip route show dev eth2 table local  
  трансляция 10.10.20.0 ссылка на область видимости прото ядра src 10.10.20.89
широковещательная передача 192.168.254.0 прото-ядро ссылка src 192.168.254.254
широковещательная передача 10.10.20.255 ссылка на область видимости ядра src 10.10.20.89
локальный 192.168.254.254 прото-область ядра хоста src 192.168.254.254
местный 10.10.20.89 proto kernel scope host src 10.10.20.89
широковещательная передача 192.168.254.255 прото-ядро ссылка src 192.168.254.254 
         

Примечание в
Пример 4.15, «Ядро, обслуживающее локальную таблицу маршрутизации », которое ядро ​​добавляет
не только маршрут для локальной сети в основной
таблица маршрутизации, а также три требуемых специальных адреса в
локальная таблица маршрутизации .Любые IP-адреса, локально размещенные на
коробка будет иметь локальных записей в локальной таблице . В
сеть
адрес и
трансляция
оба адреса вводятся как широковещательный тип
адреса на интерфейсе, к которому они были привязаны.
С концептуальной точки зрения различие между
сетевой и широковещательный адрес, но практически они лечатся
аналогично другим сетевым оборудованием, а также ядром Linux.

Есть еще один тип маршрута, который обычно заканчивается в местном
таблица маршрутизации. При использовании iproute2 NAT будет
быть записями в локальной таблице маршрутизации для каждого сетевого адреса
перевод. Ссылаться на
ExampleD.21, «Создание NAT-маршрута для одного IP-адреса с добавлением IP-маршрута.
нац »и
ПримерD.22, «Создание маршрута NAT для всей сети с IP
route add nat », например вывод.

4.8.3. Основная таблица маршрутизации

Основная таблица маршрутизации — это таблица маршрутизации, о которой думает большинство людей, когда
учитывая таблицу маршрутизации Linux. Когда таблица не указана для
ip route , ядро ​​предполагает основной
таблица маршрутизации. Команда route только манипулирует
основная таблица маршрутизации .

Как и в локальной таблице , заполняется основная таблица
автоматически ядром при создании новых интерфейсов
с IP-адресами.Проконсультируйтесь с основной таблицей маршрутизации до и после
ip-адрес добавить 192.168.254.254/24 brd + dev eth2
в
Пример 4.15, «Обслуживание ядра локальной таблицы маршрутизации » для конкретного примера.
этого поведения ядра. Также посетите
это резюме
побочные эффекты определения интерфейса и активации с
ifconfig или ip-адрес .

Таблица маршрутизации

В компьютерных сетях таблица маршрутизации или база маршрутной информации (RIB) — это таблица данных, хранящаяся в маршрутизаторе или сетевом компьютере, в которой перечислены маршруты к определенным сетевым пунктам назначения, а в некоторых случаях , метрики (расстояния), связанные с этими маршрутами.Таблица маршрутизации содержит информацию о топологии сети непосредственно вокруг нее. Построение таблиц маршрутизации — основная цель протоколов маршрутизации. Статические маршруты — это записи, внесенные в таблицу маршрутизации неавтоматическими средствами и фиксированные, а не являющиеся результатом какой-либо процедуры «обнаружения» сетевой топологии.

Основы

В таблице маршрутизации используется та же идея, что и при использовании карты при доставке пакетов. Когда узлу нужно отправить данные другому узлу в сети, он должен знать , где , чтобы отправить их в первую очередь.Если узел не может напрямую подключиться к узлу назначения, он должен отправить его через другие узлы по правильному маршруту к узлу назначения. Большинство узлов не пытаются выяснить, какой маршрут (ы) может работать; вместо этого узел отправит IP-пакет на шлюз в локальной сети, который затем решает, как направить «пакет» данных в правильное место назначения. Каждый шлюз должен будет отслеживать способ доставки различных пакетов данных, и для этого он использует таблицу маршрутизации. Таблица маршрутизации — это база данных, которая отслеживает пути, как карта, и позволяет шлюзу предоставлять эту информацию узлу, запрашивающему информацию.

При поэтапной маршрутизации каждая таблица маршрутизации перечисляет для всех доступных пунктов назначения адрес следующего устройства на пути к этому пункту назначения: следующий переход . Предполагая, что таблицы маршрутизации согласованы, простого алгоритма ретрансляции пакетов к следующему переходу их пункта назначения, таким образом, достаточно для доставки данных в любую точку сети. Последовательность шагов — это фундаментальная характеристика межсетевого уровня IP ^[1] и сетевого уровня OSI.

Проблемы с таблицами маршрутизации

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

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

Содержание таблиц маршрутизации

Таблица маршрутизации состоит как минимум из трех информационных полей:

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

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

1. качество обслуживания , связанное с маршрутом.Например, флаг U указывает, что IP-маршрут установлен.
2. ссылки на критерии фильтрации / списки доступа, связанные с маршрутом
3. интерфейс : например, eth0 для первой карты Ethernet, eth2 для второй карты Ethernet и т. Д.

Таблицы маршрутизации также являются ключевым аспектом некоторых операций безопасности, таких как пересылка одноадресного обратного пути (uRPF). ^[2] В этом методе, который имеет несколько вариантов, маршрутизатор также ищет в таблице маршрутизации адрес источника пакета.Если обратного маршрута к исходному адресу не существует, пакет считается искаженным или вовлеченным в сетевую атаку и отбрасывается.

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

• Столбцы Сетевое назначение и Сетевая маска вместе описывают идентификатор сети , как упоминалось ранее. Например, назначение 192.168.0.0 и маска сети 255.255.255.0 могут быть записаны как идентификатор сети 192.168.0.0/24 .
• Столбец Gateway содержит ту же информацию, что и столбец Next hop , т.е.е. он указывает на шлюз, через который можно выйти в сеть.
• Интерфейс указывает, какой локально доступный интерфейс отвечает за доступ к шлюзу. В этом примере к шлюзу 192.168.0.1 (интернет-маршрутизатор) можно получить доступ через локальную сетевую карту с адресом 192.168.0.100 .
• Наконец, метрика указывает соответствующую стоимость использования указанного маршрута. Это полезно для определения эффективности определенного маршрута из двух точек в сети.В этом примере более эффективно взаимодействовать с самим компьютером, используя адрес 127.0.0.1 (называемый «localhost»), чем через 192.168.0.100 (IP-адрес локальной сетевой карты). .

Стол экспедиторский

Основная статья: Таблица пересылки

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

Эта архитектура маршрутизатора отделяет функцию плоскости управления таблицы маршрутизации от функции плоскости пересылки таблицы пересылки. ^[3] Такое разделение управления и пересылки обеспечивает непрерывную пересылку в производственных средах наряду с повышенной производительностью.

См. Также

Список литературы

Внешние ссылки

Таблица маршрутизации

— Сетевая энциклопедия

Определение таблицы маршрутизации в сетевой энциклопедии.

Что такое таблица маршрутизации?

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

Таблица маршрутизации

Платформы Microsoft Windows автоматически создают свои собственные таблицы маршрутизации, которые используются для определения того, следует ли пересылать определенные пакеты на:

• Сегмент локальной сети
• Интерфейс ближнего маршрутизатора
• Шлюз по умолчанию для сегмента

Для просмотра внутренней таблицы маршрутизации TCP / IP на компьютере под управлением Windows 2000, Windows NT, Windows 98 или Windows 95 введите в командной строке route print .

Типичная таблица маршрутизации выглядит следующим образом:

 Активные маршруты: 
 Сетевой адрес Маска сети Адрес шлюза Метрика интерфейса 
 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 
 172.16.8.0 255.255.255.0 172.16.8.50 172.16.8.50 1 
 172.16.8.50 255.255.255.255 127.0.0.1 127.0.0.1 1 
 172.16.255.255 255.255.255.255 172.16.8.50 172.16.8.50 1 
 224.0.0.0 224.0.0.0 172.16.8.50 172.16.8.50 1 
 255.255.255.255 255.255.255.255 172.16.8.50 172.16.8.50 1 

Этот компьютер имеет одну сетевую карту (NIC) с адресом 172.16.8.50. Столбцы этой таблицы следующие:

• Сетевой адрес: Сетевой адрес назначения в сети
• Сетевая маска: Часть сетевого адреса, которая должна совпадать, чтобы этот маршрут использовался
• Адрес шлюза: Куда должен быть отправлен пакет перенаправлено (локальная сетевая карта или интерфейс локального маршрутизатора)
• Интерфейс: Адрес сетевой карты, через которую должен быть отправлен пакет
• Метрика: Количество переходов к сети назначения

Таблица пересылки

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

Эта архитектура маршрутизатора отделяет функцию плоскости управления таблицы маршрутизации от функции плоскости пересылки таблицы пересылки. Такое разделение управления и пересылки обеспечивает бесперебойную работу.

Статическая маршрутизация

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

Динамическая маршрутизация

Динамическая маршрутизация — это механизм маршрутизации, управляемый протоколом маршрутизации, таким как протокол информации о маршрутизации (RIP) или протокол определения кратчайшего пути (OSPF), который динамически обменивается информацией маршрутизации между маршрутизаторами в объединенной сети.Маршрутизаторы, использующие этот метод, называются динамическими маршрутизаторами.

Таблица маршрутизации в Microsoft Exchange

В Microsoft Exchange Server таблица маршрутизации — это внутренняя таблица, которая определяет, как сообщения могут быть перенаправлены на другие сайты в организации Exchange и во внешние почтовые системы через установленные соединители и шлюзы. Эта таблица маршрутизации обычно известна как таблица маршрутизации адресов шлюза (GWART).

См. Также:

Таблица маршрутизации, объясненная в видео

Статическая маршрутизация | Блог CCNA

Обзор

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

Маршрутизаторы в наших сетях обнаруживают удаленные сети одним из двух способов;

1. Статически настроенные маршруты
2. Протоколы динамической маршрутизации

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

Введение

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

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

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

Сетевой администратор также настроил последовательные интерфейсы R1 и R3 как DCE, и все остальные конфигурации верны.

В этом сценарии R1 может пинговать HOST A, R1 может пинговать интерфейс R2 s0 / 0/0, но не интерфейс s0 / 0/1.

R3 может пинговать HOST B, R3 может пинговать ТОЛЬКО интерфейс s0 / 0/1 R2. HOST A и HOST B не могут общаться. Как показано на выставке ниже.

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

СОХРАНИТЕ ДАННУЮ ТОПОЛОГИЮ В УМАХ, ТАК КАК ОНА БУДЕТ ИСПОЛЬЗОВАТЬСЯ В ЭТОЙ ГЛАВЕ.

Сети прямого подключения

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

Вывод команды «show ip route» на маршрутизаторе показывает маршруты, по которым может достичь конкретный маршрутизатор. По умолчанию маршрутизатор знает только маршруты, подключенные напрямую.

Маршруты с прямым подключением в нашем сценарии с точки зрения R1 — это сеть, подключенная к HOST A, и сеть между R1 и R2.

Поскольку на этих маршрутизаторах не выполнялась никакая другая конфигурация, R2 и R3 должны иметь только напрямую подключенные маршруты.

Непосредственно подключенные сети — единственные сети, к которым может получить доступ конкретный маршрутизатор.В нашем сценарии это означает, что;

• Хост A может пинговать R1

• R1 может пинговать интерфейс s0 / 0/0 R2, но не интерфейс s0 / 0/1

• R2 может пинговать интерфейс s0 / 0/0 маршрутизатора R1, но не интерфейс fa0 / 0 или HOST A

• R2 может пинговать интерфейс s0 / 0/0 маршрутизатора R3, но не интерфейс fa0 / 0 или HOST B

• R3 может пинговать интерфейс s0 / 0/1 R2, но не интерфейс s0 / 0/0

• HOST B может пинговать R3.

• Ни один из хостов не может пинговать друг друга

• R1 и R3 не могут пинговать друг друга.

На рисунке ниже показаны все напрямую подключенные сети.

Статическая трассировка

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

тупиковые сети — это сети , к которым можно получить доступ только через одну точку или один интерфейс.

В приведенном выше сценарии сети 192.168.1.0/24 и 192.168.4.0/24 являются тупиковыми. Это означает, что у хостов в этих сегментах сети есть только один способ связи с другими хостами, а именно R1 и R3 для сетей 192.168.1.0/24 и 192.168.4.0/24 соответственно.

Понимание тупиковых сетей имеет решающее значение для понимания статической маршрутизации.

Команда, необходимая для настройки статического маршрута, показана ниже.

Маршрутизатор (конфигурация) # ip route (сетевой адрес) (маска подсети) (IP-адрес следующего перехода / интерфейс выхода)

В таблице ниже поясняется значение каждого параметра в команде ip route, а также приводится пример команды, которая будет использоваться на маршрутизаторе R1 для настройки статического маршрута к локальной сети маршрутизатора R3 (192.168.4.0 / 24).

См. Выставку.Поэтому для настройки статического маршрута на маршрутизаторе R1 для сети 192.168.4.0/24 необходимо выполнить команду на маршрутизаторе R1:

R1 (конфигурация) # IP-маршрут 192.168.3.0 255.255.255.0 192.168.2.4

R1 (конфигурация) # IP-маршрут 192.168.4.0 255.255.255.0 192.168.2.4

ИЛИ

R1 (конфигурация) # ip route 192.168.3.0 255.255.255.0 s0 / 0/0

R1 (конфигурация) # ip route 192.168.4.0 255.255.255.0 s0 / 0/0

ПРИМЕЧАНИЕ: При настройке статических маршрутов
следует использовать только интерфейс выхода или IP-адрес следующего перехода, но не оба сразу.Это будет объяснено позже.

ИЗУЧИТЕ ТАБЛИЦУ МАРШРУТА НА R1:

Выделено
красным в нижней части вывода show ip route на R1, это статический маршрут, который мы только что добавили. «S» в начале означает, что таблица маршрутизации получила этот маршрут в результате статической конфигурации маршрута.

В фигурных скобках «1» — административное расстояние для статических маршрутов, а «0» — метрика.

Исходя из этого, мы можем предположить, что эхо-запросы от HOST A до HOST B должны работать. Правильно?

Давайте попробуем выполнить эхо-запрос от HOST A TO HOST B и посмотрим, что произойдет.

Как видно из приведенного выше рисунка, все четыре эхо-запроса к HOST B показаны как истекло время ожидания запроса . Далее, выделено красным цветом
внизу, HOST B не получил пакетов. это означает, что они не могут связаться.

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

Принципы таблицы маршрутизации

Существуют три принципа таблицы маршрутизации, которые определяют способ связи маршрутизаторов.

Принцип 1:

«Маршрутизаторы пересылают пакеты ТОЛЬКО на основе информации, содержащейся в их таблицах маршрутизации».

R1 имеет 2 маршрута 192.168.3.0/24, который является соединением между R2 и R3, и 192.168.4.0 / 24 — сеть, в которой расположен HOST B. Следовательно, исходя из первого принципа, R1 будет принимать решения о пересылке только на основе этой информации. Он не будет обращаться к R2 или R3 и не знает, есть ли у этих маршрутизаторов маршруты к другим сетям. Как сетевой администратор, вы обязаны убедиться, что все маршрутизаторы в сети знают об удаленных сетях.

Принцип 2:

”Информация о маршрутизации на одном маршрутизаторе не означает, что другие маршрутизаторы в домене имеют такую ​​же информацию.”

R1 не знает информации в таблице маршрутизации R2. То же можно сказать о R2 и R3. Следовательно, тот факт, что R1 имеет путь к сетям, подключенным к R2 и R3, не означает, что R2 и R3 имеют одинаковую информацию.

Например, можно подключиться к сети 192.168.4.0/24 на R3 через R2. R1 не знает, может ли R2 подключиться к сети, подключенной к R3. Следовательно, нам нужно настроить маршруты от R2 до LAN, подключенной к R3.

Используя принцип 2 , нам все еще необходимо настроить правильную маршрутизацию на других маршрутизаторах (R2 и R3), чтобы убедиться, что у них есть маршруты к этим трем сетям.

Принцип 3:

«Маршруты на маршрутизаторе к удаленной сети не означают, что удаленный маршрутизатор имеет обратные пути».

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

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

В нашем сценарии это означает, что когда мы настраиваем маршрут к сети 192.168.4.0/24 на R1, нам нужно настроить маршрут на удаленных маршрутизаторах, который ведет к локальным сетям, подключенным к R1.

Используя принцип 3 в качестве руководства, мы настроим правильные статические маршруты на других маршрутизаторах, чтобы убедиться, что у них есть маршруты обратно в сеть 192.16.1.0/24.

Применение принципов:

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

Принцип 1

R1 знает, как попасть в сеть 192.168.3.0/24 и сеть 192.168.4.0/24, однако R2 и R3 не знают, как туда попасть. Следовательно, нам необходимо настроить статический маршрут на R2, чтобы он знал, как добраться до 192.168.4.0/24.

Принцип 2

Мы настроили статический маршрут на R1, однако это не означает, что R2 знает путь к 192.168.4.0 / 24 сеть. Следовательно, этот маршрутизатор должен знать об этой сети.

Принцип 3

Несмотря на то, что R1 и R2 имеют маршрут к сети 192.168.4.0, эхо-запрос все равно завершится ошибкой, потому что оба R2 и R3 не будут знать, как добраться до R1. Следовательно, нам необходимо настроить маршрут, который возвращается в сеть 192.168.1.0/24 на R1. В этом случае мы используем IP-адрес следующего перехода как на R2, так и на R3.

Отсюда. Теперь мы можем выполнить необходимые настройки на всех маршрутизаторах, чтобы сделать возможной связь между HOST A и HOST B.

На маршрутизаторе R2:

R2 (конфигурация) # IP-маршрут 192.168.1.0 255.255.255.0 192.168.2.3

R2 (конфигурация) # ip route 192.168.4.0 255.255.255.0 192.168.3.3

На маршрутизаторе R3:

R3 (конфигурация) # ip-маршрут 192.168.1.0 255.255.255.0 192.168.3.4

R3 (конфигурация) # IP-маршрут 192.168.4.0 255.255.255.0 192.168.3.4

После выполнения всех настроек на всех трех маршрутизаторах связь между ХОСТОМ A и ХОСТОМ B должна быть возможна.На рисунке ниже показаны таблицы маршрутизации всех трех маршрутизаторов, статические маршруты выделены красным цветом .

R1:

R2:

R3:

В результате этого вывода. Мы должны иметь возможность пинговать от ХОСТА А к ХОСТУ B. Выходные данные ниже показывают результаты эхо-запроса от ХОСТА А к ХОСТУ B.

Выходные данные показывают, что есть ответы, поступающие от HOST B, который имеет IP-адрес 192.168.4.2, выделенный красный раздел показывает, что 4 пакета были отправлены, и все 4 были получены HOST B с 0% потерями.

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

Определение IP-адреса следующего перехода

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

См. Выходные данные команды show ip route на R2 ниже.

Когда маршрутизатор хочет отправить пакет в сеть 192.168.1.0, он просматривает таблицу маршрутизации.

Есть маршрут к этой сети через 192.168.2.3. Затем маршрутизатор проверяет, есть ли у него интерфейс с сетью 192.168.2.3. В этом сценарии это будет сеть, выделенная синим цветом. Интерфейс выхода — серийный 0/0/0.

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

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

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

Рекомендуется, чтобы статические маршруты имели интерфейс выхода, а не IP-адрес следующего перехода.

Сводка и маршруты по умолчанию

Предположим, к маршрутизатору подключено более 1 LAN.Было бы более практично использовать адрес, охватывающий все LANS, и настроить 1 статический маршрут. Возьмем этот сценарий, к R1 подключено 5 локальных сетей;

• 192.168.1.0/24

• 192.168.2.0/24

• 192.168.3.0/24

• 192.168.4.0/24

• 192.168.5.0/24

Обобщение этих маршрутов показано в таблице ниже.

Первые 2 октета и первые 5 бит слева в третьем октете.

Следовательно, новый суммарный сетевой адрес и маска подсети для 5 сетей будут: 192.168.0.0/21 с маской подсети 255.255.248.0.

При настройке статического маршрута к итоговому сетевому выходу serial0 / 0/0 на R2 команда будет иметь вид;

R2 (конфигурация) # ip route 192.168.0.0 255.255.248.0 s0 / 0/0

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

В Интернете много IP-адресов, и настройка одного статического маршрута к определенной сети не работает.Следовательно, необходим маршрут по умолчанию.

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

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

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

Синтаксис для настройки статического маршрута по умолчанию:

Маршрутизатор (конфигурация) # ip route 0.0.0.0 0.0.0.0 [IP-адрес следующего перехода / интерфейс выхода]

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

В этом сценарии для настройки статического маршрута по умолчанию используется последовательность команд на маршрутизаторе R1.

R1 (config) # ip route 0.0.0.0 0.0.0.0 12.145.3.2

или

R1 (config) # ip route 0.0.0.0 0.0.0.0 s0 / 0/0

Сводка

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

В следующей главе мы познакомимся с миром протоколов динамической маршрутизации.

Выбор маршрута в маршрутизаторах Cisco

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

Требования

Нет никаких особых предпосылок для этого документа.

Используемые компоненты

Этот документ не ограничивается конкретными версиями программного и аппаратного обеспечения.

Условные обозначения

Дополнительные сведения об условных обозначениях в документах см. В разделе «Условные обозначения технических советов Cisco».

В построении и обслуживании таблицы маршрутизации в маршрутизаторе Cisco участвуют три процесса:

• Различные процессы маршрутизации, которые фактически запускают протокол сети (или маршрутизации), такие как протокол расширенной внутренней маршрутизации шлюза (EIGRP), протокол пограничного шлюза (BGP), промежуточная система-промежуточная система (IS-IS) и Сначала откройте кратчайший путь (OSPF).

• Сама таблица маршрутизации, которая принимает информацию от процессов маршрутизации, а также отвечает на запросы информации от процесса пересылки.

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

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

Основные соображения при построении таблицы маршрутизации:

• Административная дистанция — это мера надежности источника маршрута.Если маршрутизатор узнает о пункте назначения из более чем одного протокола маршрутизации, административное расстояние сравнивается, и предпочтение отдается маршрутам с меньшим административным расстоянием. Другими словами, это достоверность источника маршрута.

• Метрика — это мера, используемая протоколом маршрутизации для вычисления наилучшего пути к заданному пункту назначения, если он изучает несколько путей к одному и тому же пункту назначения. Каждый протокол маршрутизации использует разные метрики.

• Длина префикса

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

Маршрутизатор решает, устанавливать или нет маршруты, представленные процессами маршрутизации, на основе административного расстояния рассматриваемого маршрута.Если этот путь имеет наименьшее административное расстояние до этого пункта назначения (по сравнению с другими маршрутами в таблице), он устанавливается в таблице маршрутизации. Если этот маршрут не является маршрутом с наилучшим административным расстоянием, он отклоняется.

Чтобы лучше понять это, давайте рассмотрим пример. Предположим, что на маршрутизаторе запущено четыре процесса маршрутизации: EIGRP, OSPF, RIP и IGRP. Теперь все четыре процесса узнали о различных маршрутах к сети 192.168.24.0/24, и каждый выбрал свой лучший путь к этой сети с помощью своих внутренних показателей и процессов.

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

Поскольку внутренний маршрут EIGRP имеет лучшее административное расстояние (чем меньше административное расстояние, тем выше предпочтение), он устанавливается в таблице маршрутизации.

Резервные маршруты

Что делают другие протоколы, RIP, IGRP и OSPF, с маршрутами, которые не были установлены? Что делать, если наиболее предпочтительный маршрут, полученный из EIGRP, не работает? Программное обеспечение Cisco IOS® использует два подхода для решения этой проблемы. Первый — это то, что каждый процесс маршрутизации периодически пытается установить свои лучшие маршруты. Если наиболее предпочтительный маршрут не работает, следующий лучший маршрут (в соответствии с административным расстоянием) будет успешным при следующей попытке. Другое решение — для протокола маршрутизации, которому не удалось установить свой маршрут в таблице, чтобы он оставался на маршруте и сообщал процессу таблицы маршрутизации, чтобы он сообщал, если лучший путь терпит неудачу.

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

Для протоколов, у которых есть собственная база данных с информацией о маршрутизации, таких как EIGRP, IS-IS, OSPF, BGP и RIP, резервный маршрут регистрируется при неудачной первоначальной попытке установить маршрут.Если маршрут, установленный в таблице маршрутизации, по какой-либо причине не работает, процесс обслуживания таблицы маршрутизации вызывает каждый процесс протокола маршрутизации, который зарегистрировал резервный маршрут, и просит их переустановить маршрут в таблице маршрутизации. Если существует несколько протоколов с зарегистрированными резервными маршрутами, предпочтительный маршрут выбирается на основе административного расстояния.

Регулировка административного расстояния

Административное расстояние по умолчанию может не всегда подходить для вашей сети; вы можете настроить их так, чтобы, например, маршруты RIP были предпочтительнее маршрутов IGRP.Прежде чем объяснять, как отрегулировать административное расстояние, нам необходимо рассмотреть последствия изменения административного расстояния.

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

Для целых протоколов изменить расстояние относительно легко; просто настройте расстояние с помощью команды distance в режиме субконфигурации процесса маршрутизации. Вы также можете изменить расстояние для маршрутов, полученных из одного источника, только в некоторых протоколах, и вы можете изменить расстояние только для некоторых маршрутов. Для получения дополнительной информации обратитесь к Настройте административное расстояние для выбора маршрута в примере конфигурации маршрутизаторов Cisco IOS .

Для статических маршрутов вы можете изменить расстояние каждого маршрута, введя расстояние после команды ip route :

ip route network маска подсети расстояние следующего перехода

Вы не можете изменить административное расстояние для всех статических маршрутов сразу.

Как метрики определяют процесс выбора маршрута

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

Длина префикса

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

Какой из этих маршрутов будет установлен в таблице маршрутизации? Поскольку внутренние маршруты EIGRP имеют наилучшее административное расстояние, возникает соблазн предположить, что будет установлен первый из них. Однако, поскольку каждый из этих маршрутов имеет разную длину префикса (маску подсети), они считаются разными пунктами назначения, и все они будут установлены в таблице маршрутизации.

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

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

 маршрутизатор #  показать IP-маршрут 
     ....
     D 192.168.32.0/26 [90/25789217] через 10.1.1.1
     R 192.168.32.0/24 [120/4] через 10.1.1.2
     O 192.168.32.0/19 [110/229840] через 10.1.1.3
     ....
 

Если пакет прибывает на интерфейс маршрутизатора, предназначенный для 192.168.32.1, какой маршрут выберет маршрутизатор? Это зависит от длины префикса или количества битов, установленных в маске подсети.При пересылке пакета более длинные префиксы всегда предпочтительнее более коротких.

В этом случае пакет, предназначенный для 192.168.32.1, направлен на 10.1.1.1, поскольку 192.168.32.1 попадает в сеть 192.168.32.0/26 (от 192.168.32.0 до 192.168.32.63). Он также относится к двум другим доступным маршрутам, но 192.168.32.0/26 имеет самый длинный префикс в таблице маршрутизации (26 битов против 24 или 19 битов).

Аналогичным образом, если пакет, предназначенный для 192.168.32.100, поступает на один из интерфейсов маршрутизатора, он пересылается на 10.1.1.2, потому что 192.168.32.100 не попадает в диапазон 192.168.32.0/26 (от 192.168.32.0 до 192.168.32.63), но попадает в целевой диапазон 192.168.32.0/24 (от 192.168.32.0 до 192.168.32.255). Опять же, он также попадает в диапазон 192.168.32.0/19, но 192.168.32.0/24 имеет большую длину префикса.

IP бесклассовый

Когда команда настройки ip classless попадает в процессы маршрутизации и пересылки, часто возникает путаница. На самом деле бесклассовый IP влияет только на работу процессов пересылки в IOS; это не влияет на способ построения таблицы маршрутизации.Если IP classless не настроен (с помощью команды no ip classless ), маршрутизатор не будет пересылать пакеты в суперсети. В качестве примера давайте снова поместим три маршрута в таблицу маршрутизации и направим пакеты через маршрутизатор.

Примечание: Если суперсеть или маршрут по умолчанию изучен через IS-IS или OSPF, команда настройки no ip classless игнорируется. В этом случае режим коммутации пакетов работает так, как если бы был настроен ip classless .

 маршрутизатор #  показать IP-маршрут 
....
     172.30.0.0/16 имеет переменные подсети, 2 подсети, 2 маски
D 172.30.32.0/20 [90/4879540] через 10.1.1.2
D 172.30.32.0/24 [90/25789217] через 10.1.1.1
S * 0.0.0.0/0 [1/0] через 10.1.1.3 

Помня, что сеть 172.30.32.0/24 включает адреса с 172.30.32.0 по 172.30.32.255, а сеть 172.30.32.0/20 включает адреса с 172.30.32.0 по 172.30.47.255, мы можем попробовать переключить три пакета с помощью этой маршрутизации. таблицу и посмотрите, каковы результаты.

• Пакет, предназначенный для 172.30.32.1, пересылается на 10.1.1.1, поскольку это самое длинное совпадение префикса.

• Пакет, предназначенный для 172.30.33.1, пересылается на 10.1.1.2, поскольку это самое длинное совпадение префикса.

• Пакет, предназначенный для 192.168.10.1, пересылается на 10.1.1.3; поскольку эта сеть не существует в таблице маршрутизации, этот пакет пересылается по маршруту по умолчанию.

• Пакет, предназначенный для 172.30.254.1 сброшен.

Удивительный ответ из этих четырех — последний отброшенный пакет. Он отброшен, потому что его пункт назначения, 172.30.254.1, находится в известной основной сети 172.30.0.0/16, но маршрутизатор не знает об этой конкретной подсети в этой основной сети.

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

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

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

Маршрутизатор удаленного сайта настроен следующим образом:

 интерфейс Последовательный 0
     IP-адрес 10.1.2.2 255.255.255.0
   !
   интерфейс Ethernet 0
     IP-адрес 10.1.1.1 255.255.255.0
   !
   IP-маршрут 0.0.0.0 0.0.0.0 10.1.2.1
   !
   нет IP без класса
 

При такой конфигурации узлы на удаленном сайте могут достигать адресатов в Интернете (через облако 10.x.x.x), но не адресатов в облаке 10.x.x.x, которое является корпоративной сетью. Поскольку удаленный маршрутизатор знает о некоторой части сети 10.0.0.0/8, двух напрямую подключенных подсетях и никакой другой подсети 10.x.x.x, он предполагает, что эти другие подсети не существуют, и отбрасывает все пакеты, предназначенные для них. Однако трафик, направляемый в Интернет, никогда не имеет пункта назначения в диапазоне адресов 10.x.x.x и поэтому правильно маршрутизируется по маршруту по умолчанию.

Настройка ip classless на удаленном маршрутизаторе решает эту проблему, позволяя маршрутизатору игнорировать классовые границы сетей в своей таблице маршрутизации и просто маршрутизировать к самому длинному совпадению префикса, которое он может найти.

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

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