Для каких объектов маршрутизатор выбирает маршрут

Обновлено: 05.07.2024

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

Предварительные требования:	Прочитайте введение в Express/Node. Ознакомиться с предыдущими разделами руководства (включая часть 3 экспресс-учебника: Использование базы данных (с Mongoose)).
Цель:	Понять как создавать простые маршруты. Чтобы настроить все наши конечные точки URL.

Обзор

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

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

• «Маршруты» для пересылки поддерживаемых запросов (и любой информации, закодированной в URL-адресах запросов) соответствующим функциям контроллера.
• Функции контроллера позволяют получать запрошенные данные из моделей, создавать HTML-страницу, отображающую данные, и возвращать ее пользователю для просмотра в браузере.
• Представления (шаблоны), используемые контроллерами для отображения данных.

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

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

Учебник по маршрутам

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

Примечание. Мы кратко обсуждали маршруты приложений Express в разделе Экспресс-введение > Создание обработчиков маршрутов. Помимо лучшей поддержки модуляризации (как описано в первом подразделе ниже), использование Router очень похоже на определение маршрутов непосредственно в объекте приложения Express.

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

Определение и использование отдельных модулей маршрута

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

Сначала мы создаем маршруты для вики в модуле с именем wiki.js. Код сначала импортирует объект приложения Express, использует его для получения объекта Router, а затем добавляет к нему пару маршрутов с помощью метода get(). В последнюю очередь модуль экспортирует объект Router.

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

Чтобы использовать модуль маршрутизатора в нашем основном файле приложения, мы сначала требуем() модуль маршрута (wiki.js). Затем мы вызываем use() в приложении Express, чтобы добавить Router в путь обработки промежуточного программного обеспечения, указав URL-путь 'wiki'.

Два маршрута, определенные в нашем модуле вики-маршрута, затем доступны из /wiki/ и /wiki/about/ .

Функции маршрута

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

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

Здесь функция обратного вызова вызывает send() в ответе, чтобы вернуть строку «Об этой вики», когда мы получаем запрос GET с путем ('/about'). Существует ряд других методов ответа для завершения цикла запроса/ответа. Например, вы можете вызвать res.json() для отправки ответа JSON или res.sendFile() для отправки файла. Методом ответа, который мы будем использовать чаще всего при создании библиотеки, является render(), который создает и возвращает HTML-файлы с использованием шаблонов и данных — мы поговорим об этом подробнее в следующей статье!

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

Пути маршрутов определяют конечные точки, в которых могут выполняться запросы. Примеры, которые мы видели до сих пор, были просто строками и использовались точно так, как написано: '/', '/about', '/book', '/any-random.path'.

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

<ли>? : конечная точка должна иметь 0 или 1 предшествующего символа (или группы), например. путь маршрута '/ab?cd' будет соответствовать конечным точкам acd или abcd .
• + : конечная точка должна иметь 1 или более предшествующих символов (или групп), например. путь маршрута '/ab+cd' будет соответствовать конечным точкам abcd , abbcd , abbbcd и т. д.
• * : конечная точка может иметь произвольную строку, в которую помещается символ *. Например. путь маршрута '/ab*cd' будет соответствовать конечным точкам abcd , abXcd , abSOMErandomTEXTcd и т. д.
• () : Групповое совпадение набора символов для выполнения другой операции, например. '/ab(cd)?e' выполнит? -match в группе (cd) — будет соответствовать abe и abcde .

Пути маршрута также могут быть регулярными выражениями JavaScript. Например, путь маршрута ниже будет соответствовать catfish и dogfish , но не catflap , catfishhead и так далее. Обратите внимание, что путь для регулярного выражения использует синтаксис регулярного выражения (это не строка в кавычках, как в предыдущих случаях).

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

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

Параметры маршрута — это именованные сегменты URL, используемые для захвата значений в определенных позициях в URL. Именованные сегменты начинаются с двоеточия, а затем имени (например, /:your_parameter_name/ . Захваченные значения хранятся в объекте req.params с использованием имен параметров в качестве ключей (например, req.params.your_parameter_name ).

Имена параметров маршрута должны состоять из «словесных символов» (A–Z, a–z, 0–9 и _).

Примечание. URL-адресу /book/create будет соответствовать маршрут, такой как /book/:bookId (который будет извлекать значение «bookId» для ' create '). Будет использоваться первый маршрут, соответствующий входящему URL-адресу, поэтому, если вы хотите обрабатывать URL-адреса /book/create отдельно, их обработчик маршрута должен быть определен до вашего маршрута /book/:bookId.

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

Маршруты, необходимые для LocalLibrary

URL-адреса, которые нам в конечном итоге понадобятся для наших страниц, перечислены ниже, где объект заменен названием каждой из наших моделей (книга, экземпляр книги, жанр, автор), < em>objects — это множественное число слова object, а id — это уникальное поле экземпляра ( _id ), которое по умолчанию присваивается каждому экземпляру модели Mongoose.

• catalog/ — главная/главная страница.
• catalog/ / — список всех книг, экземпляров книг, жанров или авторов (например, / catalog/books/ , / catalog/genres/ и т. д.)
• catalog/ / — страница сведений об определенной книге, экземпляре книги, жанре или авторе с заданным значением поля _id (например, /catalog/book/584493c1f4887f06c0e67d37).
• catalog/ /create — форма для создания новой книги, экземпляра книги, жанра или автора (например, /catalog/book/create).
• catalog/ / /update — форма для обновления определенной книги, экземпляра книги, жанра или автора с заданным значением поля _id (например, /catalog/book/584493c1f4887f06c0e67d37/update).
• catalog/ / /delete — форма для удаления определенной книги, экземпляра книги, жанра, автора с заданным значением поля _id (например, /catalog/book/584493c1f4887f06c0e67d37/delete).

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

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

Примечание. Express позволяет создавать URL-адреса любым удобным для вас способом — вы можете кодировать информацию в теле URL-адреса, как показано выше, или использовать параметры URL-адреса GET (например, /book/?id=6 ). Какой бы подход вы ни использовали, URL-адреса должны быть чистыми, логичными и удобочитаемыми (ознакомьтесь с советом W3C здесь).

Затем мы создаем функции обратного вызова обработчика маршрута и код маршрута для всех указанных выше URL-адресов.

Создайте функции обратного вызова обработчика маршрута

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

Начните с создания папки для наших контроллеров в корне проекта (/controllers), а затем создайте отдельные файлы/модули контроллера для работы с каждой из моделей:

Контроллер автора

Откройте файл /controllers/authorController.js и введите следующий код:

Модулю сначала требуется модель, которую мы позже будем использовать для доступа и обновления наших данных. Затем он экспортирует функции для каждого из URL-адресов, которые мы хотим обработать (операции создания, обновления и удаления используют формы и, следовательно, также имеют дополнительные методы для обработки запросов на публикацию формы — мы обсудим эти методы в «статье о формах» позже). ).

Все функции имеют стандартную форму функции ПО промежуточного слоя Express с аргументами для запроса и ответа. Мы также могли бы включить следующую функцию, которая будет вызываться, если метод не завершает цикл запроса, но во всех этих случаях это происходит, поэтому мы опустили ее. Методы возвращают строку, указывающую, что соответствующая страница еще не создана. Если ожидается, что функция контроллера получит параметры пути, они выводятся в строке сообщения (см. req.params.id выше).

Контроллер BookInstance

Откройте файл /controllers/bookinstanceController.js и скопируйте в него следующий код (этот шаблон аналогичен модулю контроллера Author):

Контроллер жанра

Откройте файл /controllers/genreController.js и скопируйте в него следующий текст (это делается по тому же шаблону, что и файлы Author и BookInstance):

Контроллер книг

Откройте файл /controllers/bookController.js и скопируйте в него следующий код. Он следует той же схеме, что и другие модули контроллера, но дополнительно имеет функцию index() для отображения приветственной страницы сайта:

Создайте модуль маршрута каталога

Затем мы создаем маршруты для всех URL-адресов, необходимых веб-сайту LocalLibrary, которые будут вызывать функции контроллера, определенные в предыдущем разделе.

В скелете уже есть папка ./routes, содержащая маршруты для индекса и пользователей. Создайте еще один файл маршрута — catalog.js — внутри этой папки, как показано на рисунке.

Откройте /routes/catalog.js и скопируйте приведенный ниже код:

Модулю требуется Express, а затем он используется для создания объекта Router. Все маршруты настроены на маршрутизаторе, который затем экспортируется.

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

Все функции обработчика импортированы из модулей контроллера, которые мы создали в предыдущем разделе.

Обновите модуль маршрута индекса

Мы настроили все наши новые маршруты, но у нас все еще есть маршрут к исходной странице. Вместо этого давайте перенаправим это на новую индексную страницу, которую мы создали по пути '/catalog'.

Откройте /routes/index.js и замените существующий маршрут приведенной ниже функцией.

Примечание. Это наше первое использование метода ответа redirect(). Это перенаправляет на указанную страницу, по умолчанию отправляя код состояния HTTP «302 Found». При необходимости вы можете изменить возвращаемый код состояния и указать абсолютные или относительные пути.

Обновить app.js

Последний шаг — добавить маршруты в цепочку ПО промежуточного слоя. Мы делаем это в app.js.

Откройте app.js и укажите маршрут каталога ниже других маршрутов (добавьте третью строку, показанную ниже, под двумя другими):

Затем добавьте маршрут каталога в стек промежуточного ПО под другими маршрутами (добавьте третью строку, показанную ниже, под двумя другими):

Примечание. Мы добавили наш модуль каталога по пути «/catalog». Это добавлено ко всем путям, определенным в модуле каталога. Так, например, для доступа к списку книг URL-адрес будет следующим: /catalog/books/ .

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

Тестирование маршрутов

Чтобы протестировать маршруты, сначала запустите веб-сайт обычным способом

Метод по умолчанию

Обзор

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

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

Один из интригующих аспектов маршрутизаторов 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. Прежде чем объяснять, как корректировать административную дистанцию, нужно рассмотреть последствия изменения административной дистанции.

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

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

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

IP-маршрут сеть маска подсети расстояние следующего перехода

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

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

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

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

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

EIGRP (внутренний): 192.168.32.0/26

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

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

Принятие решений о переадресации

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

Если на интерфейс маршрутизатора, предназначенный для адреса 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.

Помня, что сеть 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, но маршрутизатор не знает об этой конкретной подсети в этой основной сети.

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

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

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

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

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

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

Сводка

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

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

ns-3 предназначен для поддержки традиционных подходов и протоколов маршрутизации, поддержки портов реализаций маршрутизации с открытым исходным кодом и облегчения исследования нетрадиционных методов маршрутизации. Общая архитектура маршрутизации описана ниже в разделе Архитектура маршрутизации. Пользователи, которые хотят просто прочитать о том, как настроить глобальную маршрутизацию для проводных топологий, могут прочитать Глобальная централизованная маршрутизация. Протоколы одноадресной маршрутизации описаны в разделе «Одноадресная маршрутизация». Многоадресная маршрутизация описана в разделе Многоадресная маршрутизация .

Архитектура маршрутизации¶

Обзор маршрутизации

Обзор маршрутизации показывает общую архитектуру маршрутизации для IPv4. Ключевыми объектами являются Ipv4L3Protocol, Ipv4RoutingProtocol(s) (класс, которому вся маршрутизация/пересылка делегирована из Ipv4L3Protocol) и Ipv4Route(s).

В Ipv4L3Protocol должен быть добавлен хотя бы один протокол Ipv4RoutingProtocol во время настройки моделирования. Это делается явно вызовом Ipv4::SetRoutingProtocol().

Абстрактный базовый класс Ipv4RoutingProtocol() объявляет минимальный интерфейс, состоящий из двух методов: RouteOutput() и RouteInput(). Для исходящих пакетов от хоста транспортный протокол будет запрашивать у Ipv4 интерфейс объекта Ipv4RoutingProtocol и запрашивать маршрут через Ipv4RoutingProtocol::RouteOutput(). Возвращается объект Ptr to Ipv4Route. Это аналогично записи dst_cache в Linux. Маршрут Ipv4Route переносится в протокол Ipv4L3, чтобы избежать повторного поиска в нем. Однако в некоторых случаях (например, необработанные сокеты IPv4) потребуется вызов RouteOutput() непосредственно из Ipv4L3Protocol.

Для входящих пакетов, полученных для пересылки или доставки, выполняются следующие действия. Ipv4L3Protocol::Receive() вызывает Ipv4RoutingProtocol::RouteInput(). Это передает право собственности на пакет объекту Ipv4RoutingProtocol. С этим вызовом связаны четыре обратных вызова:

• Местная доставка
• Одноадресная передача
• Многоадресная переадресация
• Ошибка

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

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

Специализация Ipv4Routing. иллюстрирует, как несколько протоколов маршрутизации происходят от этого базового класса. Класс Ipv4ListRouting (класс реализации Ipv4ListRoutingImpl) обеспечивает существующий подход к маршрутизации списка в ns-3. Его API такой же, как у базового класса Ipv4Routing, за исключением возможности добавления нескольких протоколов маршрутизации с приоритетом (Ipv4ListRouting::AddRoutingProtocol(), Ipv4ListRouting::GetRoutingProtocol()).

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

Одноадресная маршрутизация¶

Для IPv4 и IPv6 определены следующие протоколы одноадресной маршрутизации:

• классы Ipv4ListRouting и Ipv6ListRouting (используются для хранения приоритетного списка протоколов маршрутизации)
• классы Ipv4StaticRouting и Ipv6StaticRouting (охватывающие как одноадресную, так и многоадресную рассылку)
• класс Ipv4GlobalRouting (используется для хранения маршрутов, рассчитанных глобальным диспетчером маршрутов, если он используется)
• класс Ipv4NixVectorRouting (более эффективная версия глобальной маршрутизации, которая сохраняет исходные маршруты в поле заголовка пакета)
• класс Rip — протокол IPv4 RIPv2 (RFC 2453)
• класс RipNg — протокол IPv6 RIPng (RFC 2080)
• IPv4 Optimized Link State Routing (OLSR) (протокол MANET, определенный в RFC 3626)
• IPv4 Ad Hoc On Demand Distance Vector (AODV) (протокол MANET, определенный в RFC 3561)
• IPv4 Destination Sequenced Distance Vector (DSDV) (протокол MANET)
• Динамическая маршрутизация источника IPv4 (DSR) (протокол MANET)

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

IPv[4,6]ListRouting¶

В этом разделе описывается текущий протокол ns-3 Ipv[4,6]RoutingProtocol по умолчанию. Как правило, несколько протоколов маршрутизации поддерживаются в пользовательском пространстве и координируются для записи одной таблицы переадресации в ядре.В настоящее время в ns-3 реализация вместо этого позволяет нескольким протоколам маршрутизации создавать/сохранять собственное состояние маршрутизации, а реализация IP будет запрашивать каждый из этих протоколов маршрутизации (в порядке, определяемом симуляцией). автора), пока маршрут не будет найден.

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

IPv[4,6]ListRouting::AddRoutingProtocol¶

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

Эти методы реализованы соответственно классом Ipv4ListRoutingImpl и классом Ipv6ListRoutingImpl в интернет-модуле.

Переменная приоритета выше определяет приоритет, с которым вставляются протоколы маршрутизации. Обратите внимание, что это подписанный int. По умолчанию в ns-3 вспомогательные классы создают экземпляр объекта Ipv[4,6]ListRoutingImpl и добавляют к нему объект Ipv[4,6]StaticRoutingImpl с нулевым приоритетом. Внутри хранится список Ipv[4,6]RoutingProtocols, и с каждым протоколом маршрутизации обращаются в порядке убывания приоритета, чтобы увидеть, найдено ли совпадение. Поэтому, если вы хотите, чтобы ваш Ipv4RoutingProtocol имел приоритет ниже статической маршрутизации, вставьте его с приоритетом меньше 0; например:

При вызовах RouteOutput() или RouteInput() объект маршрутизации списка будет искать список протоколов маршрутизации в порядке приоритета, пока не будет найден маршрут. Такой протокол маршрутизации вызовет соответствующий обратный вызов, и дальнейший поиск протоколов маршрутизации выполняться не будет.

Глобальная централизованная маршрутизация¶

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

• Только для проводных сетей. Не предназначен для использования в беспроводных сетях.
• Только одноадресная рассылка. Многоадресная рассылка не выполняется.
• Масштабируемость: некоторые пользователи больших топологий (например, 1000 узлов) заметили, что текущая реализация не очень масштабируема. В будущем глобальная централизованная маршрутизация будет изменена, чтобы сократить объем вычислений и производительность во время выполнения.

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

По умолчанию при использовании вспомогательного API ns-3 и InternetStackHelper по умолчанию к узлу будет добавлена ​​возможность глобальной маршрутизации, и глобальная маршрутизация будет вставлена ​​как протокол маршрутизации с более низким приоритетом, чем статические маршруты (т. е. пользователи могут вставлять маршруты через Ipv4StaticRouting API, и они будут иметь приоритет над маршрутами, найденными с помощью глобальной маршрутизации).

API глобальной одноадресной маршрутизации¶

Общедоступный API очень минимален. Пользовательские сценарии включают следующее:

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

Примечание. Напоминание о том, что Wi-Fi NetDevice будет работать, но без учета эффектов беспроводной связи. Для беспроводной сети мы рекомендуем динамическую маршрутизацию OLSR, описанную ниже.

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

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

Например, этот вызов планирования вызовет перестроение таблиц через 5 секунд:

Поведением управляют два атрибута. Первый — это Ipv4GlobalRouting::RandomEcmpRouting. Если установлено значение true, пакеты маршрутизируются случайным образом по многопутевым маршрутам с равной стоимостью. Если установлено значение false (по умолчанию), постоянно используется только один маршрут. Второй — Ipv4GlobalRouting::RespondToInterfaceEvents. Если установлено значение true, динамически пересчитываются глобальные маршруты при событиях уведомления интерфейса (вверх/вниз или добавление/удаление адреса). Если установлено значение false (по умолчанию), маршрутизация может прерваться, если пользователь вручную не вызовет RecomputeRoutingTables() после таких событий. По умолчанию установлено значение false, чтобы сохранить устаревшее поведение программы ns-3.

Реализация глобальной маршрутизации¶

Этот раздел предназначен для тех читателей, которым небезразлично, как это реализовано. Одноэлементный объект (GlobalRouteManager) отвечает за заполнение статических маршрутов на каждом узле с использованием общедоступного API Ipv4 этого узла.Он запрашивает у каждого узла в топологии интерфейс «globalRouter». Если он найден, он использует API этого интерфейса для получения «объявления о состоянии канала (LSA)» для маршрутизатора. Объявления о состоянии канала используются в маршрутизации OSPF, и мы следуем их форматированию.

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

GlobalRouteManager заполняет базу данных состояния канала LSA, собранными из всей топологии. Затем для каждого маршрутизатора в топологии GlobalRouteManager выполняет вычисление кратчайшего пути OSPF (SPF) в базе данных и заполняет таблицы маршрутизации на каждом узле.

• точка-точка (последовательные ссылки)
• точка-многоточка (Frame Relay, одноранговая беспроводная сеть)
• нешироковещательный множественный доступ (ATM)
• трансляция (Ethernet)

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

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

GlobalRouteManager сначала просматривает список узлов и агрегирует интерфейс GlobalRouter для каждого из них следующим образом:

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

RIP и RIPng¶

Протокол RIPv2 для IPv4 описан в RFC 2453 и объединяет ряд улучшений по сравнению с базовым протоколом, определенным в RFC 1058.

Этот протокол маршрутизации IPv6 (RFC 2080) является развитием известного протокола маршрутизации RIPv1 (см. RFC 1058 и RFC 1723) для IPv4.

Протоколы очень просты и обычно подходят для плоских, простых сетевых топологий.

RIPv1, RIPv2 и RIPng имеют одинаковые цели и ограничения. В частности, RIP считает недостижимым любой маршрут с метрикой, равной или превышающей 16. Как следствие, максимальное количество переходов в сети должно быть меньше 15 (количество маршрутизаторов не задано). Пользователям рекомендуется прочитать RFC 2080 и RFC 1058, чтобы полностью понять поведение и ограничения RIP.

Конвергенция маршрутов¶

RIP использует алгоритм вектора расстояния, а маршруты обновляются в соответствии с алгоритмом Беллмана-Форда (иногда известным как алгоритм Форда-Фалкерсона). Алгоритм имеет время сходимости O(|V|*|E|), где |V| и |Е| количество вершин (маршрутизаторов) и ребер (ссылок) соответственно. Следует подчеркнуть, что время сходимости — это количество шагов в алгоритме, и каждый шаг запускается сообщением. Поскольку триггерные обновления (т. е. когда изменяется маршрут) имеют время восстановления от 1 до 5 секунд, для стабилизации топологии может потребоваться некоторое время.

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

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

В примерах examples/routing/ripng-simple-network.cc и examples/routing/rip-simple-network.cc показаны этапы настройки и восстановления сети.

Разделение по горизонтали¶

Split Horizon – это стратегия предотвращения нестабильности маршрутизации. Возможны три варианта:

• Нет разделения горизонта
• Разделить горизонт
• Реверс яда

В первом случае маршруты объявляются на всех интерфейсах маршрутизатора. Во втором случае маршрутизаторы не будут объявлять маршрут на интерфейсе, с которого он был получен. Poison Reverse объявит маршрут на интерфейсе, из которого он был получен, но с метрикой 16 (бесконечность). Полный анализ трех методов см. в RFC 1058, раздел 2.2.

Примеры основаны на топологии сети, описанной в RFC, но не демонстрируют описанный там эффект.

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

Однако в сложных топологиях все еще возможны явления нестабильности маршрута, подобные описанным в RFC, после отказа канала. Как следствие, все соображения по поводу Split Horizon остаются в силе.

Маршруты по умолчанию¶

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

Чтобы обойти это ограничение, пользователям следует либо установить маршрут по умолчанию вручную (например, прибегнув к Ipv4StaticRouting или Ipv6StaticRouting), либо с помощью RADVd (в случае IPv6). RADVd доступен в ns-3 в модуле "Приложения" и настоятельно рекомендуется.

Параметры и опции протокола¶

Реализации RIP ns-3 позволяют изменять все таймеры, связанные с обновлениями маршрутов и временем жизни маршрутов.

Кроме того, пользователи могут изменять показатели интерфейса для каждого узла отдельно.

Тип разделения горизонта (чтобы избежать обратного распространения маршрутов) можно выбрать для каждого узла отдельно, с вариантами выбора: «без разделения горизонта», «разделение горизонта» и «обратное отравление». См. RFC 2080 для получения дополнительной информации и RFC 1058 для полного обсуждения стратегий разделения горизонта.

Кроме того, можно использовать нестандартное значение Link Down Value (т. е. значение, после которого ссылка считается отключенной). Значение по умолчанию равно 16.

Ограничения¶

Параметр Next Hop не поддерживается ( RFC 2080, раздел 2.1.1). Параметр «Следующий переход» полезен, когда RIP не выполняется на всех маршрутизаторах в сети. Поддержка этого параметра может быть рассмотрена в будущем.

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

Другие протоколы маршрутизации¶

Документацию по другим протоколам маршрутизации можно найти в соответствующих разделах модулей, например:

Многоадресная маршрутизация¶

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

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

Обычно существует два основных типа многоадресных маршрутов:

• Маршруты, используемые во время переадресации, и
• Маршруты, используемые в исходном узле.

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

Во втором случае маршрут эквивалентен индивидуальному маршруту и ​​должен быть добавлен через Ipv4StaticRouting::AddHostRouteTo .

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

Это многоадресный эквивалент одноадресной версии SetDefaultRoute. Мы сообщаем системе маршрутизации, что делать в случае, если не найден конкретный маршрут к целевой группе многоадресной рассылки. Система пересылает пакеты через указанный интерфейс в надежде, что «что-то там» лучше знает, как направить пакет. Этот метод используется только при первоначальной отправке пакетов с хоста. Маршрут многоадресной рассылки по умолчанию не учитывается во время переадресации — в этом случае точные маршруты должны быть указаны с помощью AddMulticastRoute.

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

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

Командлет New-NetRoute создает IP-маршрут в таблице IP-маршрутизации. Укажите префикс назначения и укажите интерфейс, используя псевдоним интерфейса или индекс интерфейса.

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

Дополнительную информацию о маршрутизации см. в главе 5 "IP-маршрутизация" в библиотеке TechNet.

Примеры

Пример 1. Добавление IP-маршрута в таблицу маршрутизации

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

Первая команда создает маршрут для префикса назначения 10.0.0.0/24 для интерфейса с индексом 12. В качестве следующего перехода команда указывает 192.168.0.1.

Вторая команда использует командлет Get-NetRoute для получения всех маршрутов для компьютера, а затем передает их командлету Format-List с помощью оператора конвейера. Командлет Format-List может отображать все свойства объекта. Для получения дополнительной информации введите Get-Help Format-List .

Параметры

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

Тип:	AddressFamily
Допустимые значения:	IPv4, IPv6< /td>
Позиция:	Имя
Значение по умолчанию:	Нет
Принимать ввод конвейера:	False
Допускать подстановочные знаки:	False

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

Тип:	SwitchParameter
Позиция:	Именованный
Значение по умолчанию:	Нет
Принять ввод конвейера:	False
Допускать подстановочные знаки:	False

Запускает командлет в удаленном сеансе или на удаленном компьютере. Введите имя компьютера или объект сеанса, например выходные данные командлета New-CimSession или Get-CimSession. По умолчанию используется текущий сеанс на локальном компьютере.

Тип:	CimSession [ ]
Псевдонимы:	Сессия
Позиция:	Имя
Значение по умолчанию:	Нет
Принимать ввод конвейера:	False
Допускать подстановочные знаки:	False< /td>

Запрашивает подтверждение перед запуском командлета.

< /tr>

Указывает префикс назначения IP-маршрута. Префикс назначения состоит из префикса IP-адреса и длины префикса, разделенных косой чертой (/). Значение 0.0.0.0/0 для IPv4 или ::/0 для IPv6 указывает, что значение параметра NextHop является шлюзом по умолчанию. Длина префикса локального хоста должна соответствовать префиксу, указанному в этом параметре, а все остальные поля адреса должны быть равны нулю.

Тип:	SwitchParameter
Псевдонимы:	cf
Позиция:	Имя
Значение по умолчанию:	False
Принимать ввод конвейера:	False
Допускать подстановочные знаки:	False

Тип:	Строка
Позиция:	0
Значение по умолчанию:	Нет
Принять ввод конвейера:	False
Допускать подстановочные знаки:	False

Указывает псевдоним сетевого интерфейса. Командлет добавляет маршрут для интерфейса с указанным вами псевдонимом.

< /tr>

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

Тип:	String
Псевдонимы:	ifAlias
Позиция:	Имя
Значение по умолчанию:	Нет
Принимать ввод конвейера:	Истина
Допускать подстановочные знаки:	Ложь

< /tr>

Указывает следующий переход для IP-маршрута. Командлет назначает указанный вами следующий прыжок для IP-маршрута. Значение 0.0.0.0 для IPv4 или :: для IPv6 указывает, что маршрут находится в локальной подсети.

Тип:	UInt32
Псевдонимы:	ifIndex
Позиция:	Имя
Значение по умолчанию:	Нет
Принимать ввод конвейера:	Истина
Допускать подстановочные знаки:	Ложь

Тип:	Строка
Позиция:	Именованный
Значение по умолчанию:	Нет
Принять ввод конвейера:	False
Допускать подстановочные знаки:	False

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

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

Тип:	Строка
Позиция:	Именованный
Значение по умолчанию:	Нет
Принять ввод конвейера:	False
Допускать подстановочные знаки:	False

Указывает предпочтительное время жизни IP-маршрута в виде объекта TimeSpan. Командлет назначает время жизни, указанное вами для IP-маршрута. Чтобы получить объект TimeSpan, используйте командлет New-TimeSpan. Для получения дополнительных сведений введите Get-Help New-TimeSpan . Значение по умолчанию для времени жизни равно бесконечности.

Тип:	TimeSpan
Позиция:	Имя
Значение по умолчанию:	Нет
Принять ввод конвейера:	False
Допускать подстановочные знаки:	False

Значение по умолчанию — NetMgmt.

Тип:	Протокол
Допустимые значения:	Другой, Локальный, NetMgmt, Icmp, Egp, Ggp, Hello, Rip, IsIs, EsIs, Igrp, Bbn, Ospf, Bgp, Idpr, Eigrp, Dvmrp, Rpl, Dhcp
Позиция:< /td>	Именованный
Значение по умолчанию:	Нет
Принять ввод конвейера:	False
Допускать подстановочные знаки:	False

• Нет. Не публикуйте и не рекламируйте информацию об IP-маршрутах в объявлениях маршрутизаторов.
• Да. Публикуйте и рекламируйте информацию об IP-маршрутах с бесконечным сроком действия в объявлениях маршрутизаторов.
• Возраст. Публикуйте и рекламируйте информацию об IP-маршрутах с ограниченным сроком действия в объявлениях маршрутизаторов. Укажите допустимое время жизни с помощью параметра ValidLifetime.

Значение по умолчанию — Нет.

Тип:	Опубликовать
Допустимые значения:	Нет, Возраст, Да
Позиция:	Имя
Значение по умолчанию:	Нет
Принимать ввод конвейера:	False
Допускать подстановочные знаки:	Неверно

Указывает целочисленную метрику маршрута для IP-маршрута. Командлет назначает указанную вами метрику IP-маршруту. Значение по умолчанию — 256. Чтобы выбрать один из нескольких маршрутов, компьютер добавляет это значение. Компьютер выбирает маршрут с наименьшим комбинированным значением. Чтобы изменить метрику интерфейса, используйте командлет Set-NetIPInterface.

Тип:	UInt16
Позиция:	Именованный
Значение по умолчанию:	Нет
Принять ввод конвейера:	False
Допускать подстановочные знаки:	False

Указывает максимальное количество одновременных операций, которое может быть установлено для запуска командлета. Если этот параметр опущен или введено значение 0, Windows PowerShell® вычисляет оптимальный предел ограничения для командлета на основе количества командлетов CIM, запущенных на компьютере. Предел регулирования применяется только к текущему командлету, а не к сеансу или компьютеру.

Тип:	Int32
Позиция:	Именованный
Значение по умолчанию:	Нет
Принять ввод конвейера:	False
Допускать подстановочные знаки:	False

Указывает допустимое время жизни в виде объекта TimeSpan для IP-маршрута. Командлет присваивает указанный вами параметр времени жизни IP-маршруту. Чтобы получить объект TimeSpan, используйте командлет New-TimeSpan. Значение по умолчанию — бесконечность.

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

  
• Как узнать, поддерживает ли роутер частоту 5 ГГц
  
• Какой роутер xiaomi выбрать
  
• Какие интерфейсы маршрутизатора используют DHCP
  
• Как подключить роутер altel 4g к компьютеру
  
• Инициализация Bluetooth, что это такое