По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Давайте для начала разберемся, что же такое Composer. Представленное программное обеспечение является менеджером пакетных зависимостей, разработанный для облегчения загрузки, а также установки различных PHP библиотек для вашего проекта. К примеру, используя менеджер пакетов, вы можете с легкостью добавить различные библиотеки к вашему проекту, разработкой которого вы занимаетесь, а также очень легко выполнять развертывание иных проектов, каковые имеют при себе документ composer.json.
Composer.json является текстовым документов, который содержит библиотеки, каковые использует проект. Кроме того, Composer используется возможно использовать для установки различных фреймворков PHP, а также CMS.
Данный менеджер пакетов представляет собой типичный PHP-скрипт, то есть программный продукт, разработанный на языке PHP.
Главной целью данного программного продукта является предоставление удобного инструмента для веб-разработчиков, с помощью какового он с легкостью может выполнять загрузку, а также установку библиотек в проект, выполнять их обновление, и, при необходимости, деинсталляцию. С помощью менеджера пакетов можно выполнять все перечисленные выше действия с помощью нескольких команд.
Composer при скачивании библиотек выполняет не только установку, но также устанавливает зависимости, от которых они уже могут зависеть. Допустим, вы загрузили некий пакет, который имеет зависимость от нескольких пакетов, и так далее. Данный менеджер пакетов автоматически выполнит установку.
Представленный PHP-скрипт создает в корне проекта специальную папку Vendor, в которую уже и выполняется установку сторонних библиотек. Помимо этого, также создается документ autoload.php с помощью которого происходит интеграция пакетов в проект.
Помимо перечисленных выше документов, при установке сторонних пакетов, также создается дополнительный документ composer.lock. Если же вышеописанный файл composer.json выполняет роль описания и требований версий библиотек, тогда composer.lock содержит в себе сами версии библиотек, каковые установились юзером.
Основной целью документа composer.lock является оставить среду, в каковой был разработан и протестирован проект без каких-либо изменений.
Работать с менеджером пакетов возможно с помощью консоли либо терминала, используя некоторые команды.
Как установить менеджер пакетов на OpenServer (Windows)
OpenServer по умолчанию содержит в себе Composer. Это будет зависеть от версии PHP.
Для того, чтобы работать с данным менеджером пакетов, потребуется его собственная консоль, которую возможно открыть с помощью нажатия ПКМ на раздел Открыть сервер, и обнаружить пункт консольного меню в списке меню.
Чтобы убедиться в том, что Composer включен, достаточно ввести команду Composer, и для вас отобразиться информация о вашей версии.
Если же вы получите уведомление, что ваша версия уже устарела, вы можете обновить ее с помощью специальной команды composer self-update.
Как установить менеджер пакетов на хостинг?
Чтобы установить Composer на хостинг-сервис, просто скачайте эту программу и загрузите ее в корневой каталог проекта, например, по FTP.
Команды на удаленном сервере обычно выполняются через SSH. По умолчанию на виртуальном хостинге этот сетевой протокол отключен. Чтобы включить его, вам нужно найти соответствующий элемент на панели управления, открыть его и нажать на кнопку Включить SSH внутри него.
Если на вашем компьютере установлена операционная система Windows 10, тогда SSH-клиент автоматически будет добавлен в систему. А это может означать, что для использования команд над управлением удаленного сервера, вам не потребуется ничего устанавливать, так как можно использовать Windows PowerShell либо командную строку.
В этом материале расскажем, как можно фильтровать маршруты, анонсируемые протоколом динамической маршрутизации EIGRP. Данный материал предполагает, что у читателя есть начальные навыки работы с сетью или как минимум знания на уровне CCNA. Поэтому о том, что такое динамическая маршрутизация в этом материале не будет рассказано, так как тема достаточно большая и займет не одну страницу.
Теперь представим, что мы работаем в большой компании с сотнями серверов, десятками филиалов. Мы подняли сеть, настроили динамическую маршрутизацию и все счастливы. Пакеты ходят куда надо, как надо. Но в один прекрасный день, нам сказали, что на маршрутизаторах филиалов не должно быть маршрутов к сетям отдела производства. На рисунке ниже представлена упрощенная схема нашей вымышленной сети.
Конфигурацию всех устройств из этой статьи (для каждой ноды) можно скачать в архиве по ссылке ниже.
Скачать конфиги тестовой лаборатории
Мы конечно можем убрать из-под EIGRP указанные сети, но в этом случае из сетей в головном офисе тоже не будет доступа к сетям отдела производства. Именно для таких случаев была придумана такая возможность, как фильтрация маршрутов. В EIGRP это делается командой distribute-list в конфигурации EIGRP.
Принцип работы distribute-list (список распределения) прост: список распределения работает по спискам доступа (ACL), спискам префиксов (prefix-list) или карте маршрутов (route-map). Эти три инструмента определяют будут ли анонсироваться указанные сети в обновлениях EIGRP или нет. В команде distribute-list также можно указать направление обновлений: входящие или исходящие. Также можно указать конкретный интерфейс, где должны фильтроваться обновления. Полная команда может выглядеть так:
distribute-list acl [in | out][interface-type interface-number]
Фильтрация маршрутов с помощью списков доступа
Первым делом рассмотрим фильтрацию с помощью ACL. Фильтрация маршрутов EIGRP с помощью списков ACL основан на разрешающих и запрещающих действиях списков доступа. То есть, чтобы маршрут анонсировался, в списке доступа он должен быть указан с действием permit, а deny, соответственно, запрещает анонсирование маршрута. При фильтрации, EIGRP сравнивает адрес источника в списке доступа с номером подсети (префиксом) каждого маршрута и принимает решение на основе действий, указанных в ACL.
Чтобы лучше узнать принцип работы приведём примеры.
Для фильтрации маршрутов, указанных на рисунке выше нужно создать ACL, где каждый указанный маршрут сопровождается командой deny, а в конце следует прописать permit any, чтобы остальные маршруты могли анонсироваться:
access-list 2 deny 10.17.32.0 0.0.1.255
access-list 2 deny 10.17.34.0 0.0.0.255
access-list 2 deny 10.17.35.0 0.0.0.127
access-list 2 deny 10.17.35.128 0.0.0.127
access-list 2 deny 10.17.36.0 0.0.0.63
access-list 2 deny 10.17.36.64 0.0.0.63
access-list 2 permit any
А на интерфейсе настройки EGRP прописываем:
distribute-list 2 out s4/0
Проверим таблицу маршрутизации до и после применения указанных команд. Фильтрацию будем проводить на WAN маршрутизаторах.
Как видим все маршруты до сети отдела Производства видны в таблице маршрутизации филиала. Теперь применим указанные изменения:
И посмотрим таблицу маршрутов роутера филиала еще раз:
Все маршруты в отдел производства исчезли из таблицы маршрутизации. Правда, можно было обойтись и одной командой в списке доступа, но для наглядности решили прописать все адреса. А более короткую версию можете указать в комментариях к этому посту. Кстати, фильтрацию в данном примере мы применили на один интерфейс, но можно применить и на все интерфейсы, на которых включен EIGRP. Для этого команду distribute-list нужно ввести без указания конкретного интерфейса.
distribute-list 2 out
Следует отметить, что для правильной работы фильтрации в нашей топологии на маршрутизаторе WAN2 нужно прописать те же настройки, что и на WAN1.
Фильтрация маршрутов с помощью списка префиксов
В Cisco IOS есть еще один инструмент, который позволяет осуществлять фильтрацию маршрутов prefix-list-ы. Может возникнуть вполне логичный вопрос: а чем не угодили списки доступа? Дело в том, что изначально ACL был разработан для фильтрации пакетов, поэтому для фильтрации маршрутов он не совсем подходит по нескольким причинам:
списки IP-префиксов позволяют сопоставлять длину префикса, в то время как списки ACL, используемые командой EIGRP distribution-list, нет;
Использование расширенных ACL может оказаться громоздким для конфигурирования;
Невозможность определения совпадения маски маршрута при использовании стандартных ACL;
Работа ACL достаточно медленна, так как они последовательно применяется к каждой записи в маршрутном обновлении;
Для начала разберёмся в принципе работы списка префиксов. Списки IP префиксов позволяют сопоставлять два компонента маршрута:
адрес сети (номер сети);
длину префикса (маску сети);
Между списками доступа и списками префиксов есть общие черты. Как и нумерованные списки доступа, списки префиксов могу состоять из одной и более команд, которые вводятся в режиме глобальной конфигурации и нет отдельного режима конфигурации. Как и в именованных списках доступа, в списках префиксов можно указать номер строки. В целом команда выглядит так:
ip prefix-list list-name [ seq seq-value ] { deny | permit prefix / prefix-length } [ ge ge-value ] [ le le-value ]
Коротко работу списка префиксов можно описать так:
Адрес сети маршрута должен быть в пределах, указанных в команде ip prefix-list prefix/prefix-length.
Маска подсети маршрута должна соответствовать значениям, указанным в параметрах prefix-length, ge, le.
Первый шаг работает также как и списки доступа. Например, написав ip prefix-list TESTLIST 10.0.0.0/8 мы скажем маршрутизатору, что адрес сети должен начинаться с 10. Но списки префиксов всегда проверяют и на соответствие длины маски сети указанным значениям. Ниже приведено пояснение параметров списка IP-префиксов:
Параметр prefix-list-а
Значение
Не указан
10.0.0.0/8;
Маска сети должна быть равной длине, указанной в параметре prefix/prefix-length. Все маршруты, которые начинаются с 10.
ge и le (больше чем, меньше чем)
10.0.0.0/8 ge 16 le 24
Длина маски должна быть больше 16, но меньше 24. А первый байт должен быть равен 10-ти.
le меньше чем
10.0.0.0/8 le 24
Длина маски должна быть от восьми до 24-х включительно.
ge больше чем
10.0.0.0/8 ge 24
Длина маски должна быть равна или больше 24 и до 32-х включительно.
Учтите, что Cisco требует, чтобы параметры prefix-length, ge и le соответствовали следующему равенству: prefix-length <= ge-value <= le-value (8<=10<=24).
А теперь перейдем непосредственно к настройке фильтрации с помощью списка префиксов. Для этого в интерфейсе конфигурации EIGRP прописываем distribute-list prefix prefix-name.
Воспользуемся той же топологией и введём некоторые изменения в конфигурацию маршрутизатора WAN1, точно такую же конфигурацию нужно прописать и на WAN2. Итак, наша задача:
отфильтровать маршруты в сети 10.17.35.0 и 10.17.36.0;
отфильтровать маршруты сетей точка-точка так, чтобы маршрутизаторы в филиалах и на коммутаторах ядра (Core1 и Core2) не видели сети с длиной маски /30 бит. Так как трафик от пользователей в эти сети не идет, следовательно, нет необходимости анонсировать их в сторону пользователей.
Для этого создаем prefix-list с названием FILTER-EIGRP и добавим нужные сети:
ip prefix-list FILTER-EIGRP seq 5 deny 10.17.35.0/24 ge 25 le 25
ip prefix-list FILTER-EIGRP seq 10 deny 10.17.36.0/24 ge 26 le 26
ip prefix-list FILTER-EIGRP seq 15 deny 0.0.0.0/0 ge 30 le 30
ip prefix-list FILTER-EIGRP seq 20 permit 0.0.0.0/0 le 32
Удалим из конфигурации фильтрацию по спискам доступа и проверим таблицу маршрутизации:
А теперь применим наш фильтр и затем еще раз проверим таблицу маршрутизации:
Как видим из рисунка, маршрутов в сети 10.17.35.0, 10.17.36.0 и сети для соединений точка-точка между сетевыми устройствами в таблице уже нет. А теперь объясним что мы сказали маршрутизатору:
ip prefix-list FILTER-EIGRP seq 5 deny 10.17.35.0/24 ge 25 le 25
Все сети, которые начинаются на 10.17.35 и имеют длину 25 бит запретить. Под это условие попадают сети 10.17.35.0/25 и 10.17.35.128/25. Длине префикса /25 соответствует маска 255.255.255.128.
ip prefix-list FILTER-EIGRP seq 10 deny 10.17.36.0/24 ge 26 le 26
Все сети, которые начинаются на 10.17.36 и имеют длину 26 бит запретить. Под это условие попадают сети 10.17.36.0/26 и 10.17.36.64/26. Длине префикса /26 соответствует маска 255.255.255.192.
ip prefix-list FILTER-EIGRP seq 15 deny 0.0.0.0/0 ge 30 le 30
Все сети, длина префикса которых равна 30 бит - запретить. В нашей топологии под это условие попадают сети 10.1.1.0/30, 10.1.1.4/30, 10.1.2.0/30, 10.1.2.4/30 все сети которые начинаются на 10.9.2.
ip prefix-list FILTER-EIGRP seq 20 permit 0.0.0.0/0 le 32
Все сети, префикс которых имеет длину до 32-х бит разрешить. Под это условие попадают все остальные сети топологии.
Фильтрация маршрутов с помощью route-map
Далее пойдет речь о картах маршрутов или route-map-ах. В целом, в работе сети route-map-ы используются довольно часто. Этот достаточно гибкий инструмент дает возможность сетевому инженеру тонко настраивать маршрутизацию в корпоративной сети. Именно поэтому следует хорошо изучить принцип их работы, чем мы и займемся сейчас. А дальше покажем, как фильтровать маршруты с помощью этого инструмента.
Route-map применяет логику похожую на логику if, else, then в языках программирования. Один route-map может включать в себя несколько команд route-map и маршрутизатор выполняет эти команды поочередно согласно номеру строки, который система добавляет автоматически, если не был указан пользователем. После того как, система нашла соответствие маршрута условию и определила разрешить анонсирование или нет, маршрутизатор прекращает выполнение команды route-map для данного маршрута, даже если дальше указано другое условие. Каждый route-map включает в себя критерии соответствия, который задается командой match. Синтаксис route-map выглядит следующим образом:
route-map route-map-name {permit | deny} seq sequence-number
match (1st set of criteria)
Как и в случае с ACL или prefix-list, в route-map тоже можно указать порядковый номер строки для добавления или удаления соответствующего правила.
В команде match можно указать ACL или prefix-list. Но тут может возникнуть недоразумение. А связано оно с тем, как обрабатываются route-map Cisco IOS. Дело в том, что решение о запрете или допуске маршрута основано на команде deny или permit команды route-map. Другими словами, маршрут будет обработан route-map-ом если в ACL или prefix-list-е данный маршрут сопровождается командой permit. Иначе, route-map проигнорирует данную запись и перейдет к сравнению со следующим условием route-map. Поясним на примере:
access-list 101 permit 10.17.37.0 0.0.0.255
access-list 102 deny 10.17.35.0 0.0.0.127
route-map Test permit 5
match ip-address 101
route-map Test deny 10
match ip-address 102
В данном случае маршрут 10.17.37.0 будет обработан route-map 5, а маршрут 10.17.35.0 будет проигнорирован, так как в списке доступа под номером 102 он запрещён и не попадёт под критерий соответствия route-map.
Приведём ключевые пункты работы route-map при фильтрации маршрутов:
Команда route-map с опцией permit либо разрешит анонсирование маршрута, если он соответствует критерию, указанному в команде match, либо пропустит для обработки следующим пунктом.
Команда route-map с опцией deny либо запретит анонсирование маршрута, если он соответствует критерию, указанному в команде match, либо пропустит для обработки следующим пунктом.
Если команда match основывается на ACL или prefix-list-ы, а в ACL или prefix-list-ах указанный маршрут прописан с действием deny, то маршрут не будет отфильтрован. Это будет означать, что маршрут не соответствует критерию, указанному в команде match и его нужно пропустить для обработки следующим пунктом.
В конце каждого route-map существует явный запрет; чтобы пропустить все маршруты, которые не попали под критерии, нужно указать команду route-map с действием permit без опции match.
Для того чтобы задействовать route-map в фильтрации маршрутов используется та же команда distribute-list с опцией route-map route-map-name. Внесём некоторые изменения в конфигурацию маршрутизатора WAN1. Точно такие же изменения нужно будет сделать на WAN2. Используем те же префикс-листы, что и в предыдущем примере с незначительными редактированиями:
ip prefix-list MANUFACTURING seq 5 permit 10.17.35.0/24 ge 25 le 25
ip prefix-list MANUFACTURING seq 10 permit 10.17.36.0/24 ge 26 le 26
ip prefix-list POINT-TO-POINT seq 5 permit 0.0.0.0/0 ge 30 le 30
После внесения изменений маршрутов в сеть производства, а также в сети точка-точка таблице маршрутизации на роутерах филиалов не окажется. Также на Core1 не будет маршрута до сетей point-to-point:
Мы рассмотрели фильтрацию маршрутов в EIGRP тремя способами. Хорошим тоном считается использование списка префиксов, так как они заточены именно под эти цели. А использование карты маршрутизации или route-map-ов неэффективно из-за большего количества команд для конфигурации.
В следующем материале рассмотрим фильтрацию в домене OSPF.
Прежде чем перейти к более сложным темам, мы завершим эту серию статей об основах OSPF. Здесь мы рассмотрим типы LSA, типы областей и виртуальные ссылки (LSA types, area types, и virtual links). Протокол маршрутизации OSPF: LSA, области и виртуальные ссылки
OSPF LSA ТИПЫ
Link State Advertisements (LSA) — Объявления состояния канала — это основа работы сетей на OSPF. Наполнение этих обновлений позволяют сети OSPF создать карту сети. Это происходит с помощью алгоритма кратчайшего пути Дейкстры.
Не все LSA OSPF равны. Ниже представлен каждый их них:
Router (Type 1) LSA - мы начинаем с того, что многие называют «фундаментальным» или «строительным блоком» Link State Advertisements. Type 1 LSA (также известный как Router LSA) определен в пределах области. Он описывает интерфейсы локального маршрутизатора, которые участвуют в OSPF, и соседей, которых установил локальный спикер OSPF.
Network (Type 2) LSA - вспомните, как OSPF функционирует на (широковещательном) Ethernet сегменте. Он выбирает Designated Router (DR) and Backup Designated Router (BDR), чтобы уменьшить количество смежностей, которые должны быть сформированы, и хаос, который будет результатом пересечением этих отношений. Type 2 LSA отправляется назначенным маршрутизатором в локальную область. Этот LSA описывает все маршрутизаторы, которые подключены к этому сегменту.
Summary (Type 3) LSA – напоминаем вам, что Type 1 LSA и Type 2 LSA ретранслируются в пределах области. Мы называем их intra-area LSA. Теперь пришло время для первого из наших inter-area LSA. Summary (Type 3) LSA используется для объявления префиксов, полученных из Type 1 LSA и Type 2 LSA в другой области. Маршрутизатор границы области (ABR) — это устройство OSPF, которое разделяет области, и именно это устройство рекламирует Type 3 LSA.
Изучите топологию OSPF, показанную на рисунке 1 ниже.
Топология OSPF
Рис. 1: Пример многозональной топологии OSPF
Область 1 ABR будет посылать Type 3 LSA в область 0. ABR, соединяющий область 0 и область 2, отправил эти Type 3 LSA в область 2, чтобы обеспечить полную достижимость в домене OSPF. Type 3 LSA остаются Type 3 LSA во время этой пересылки.
ASBR Summary (Type4) LSA - есть особая роль маршрутизатора OSPF, который называется пограничный маршрутизатор автономной системы Autonomous System Boundary Router (ASBR). Задача этого маршрутизатора заключается в том, чтобы ввести внешнюю префиксную информацию из другого домена маршрутизации. Для того чтобы сообщить маршрутизаторам в различных областях о существовании этого специального маршрутизатора, используется Type 4 LSA. Эта Summary LSA предоставляет идентификатор маршрутизатора ASBR. Таким образом, еще раз, Area Border Router отвечает за пересылку этой информации в следующую область, и это есть еще один пример inter-area LSA.
External (Type 5) LSA - Таким образом, ASBR — это устройство, которое приносит префиксы из других доменов маршрутизации. Type 4 LSA описывает это устройство. Но какой LSA используется для реальных префиксов, поступающих из другого домена? Да, это Type 5 LSA. OSPF ASBR создает эти LSA, и они отправляются к Area Border Routers для пересылки в другие области.
NSSA External (Type 7) LSA - в OSPF есть специальный тип области, называемый Not So Stubby Area (NSSA). Эта область может выступать заглушкой, но она также может вводить внешние префиксы из ASBR. Эти префиксы передаются как Type 7 LSA. Когда ABR получает эти Type 7 LSA, он отправляет по одному в другие области, такие как Type 5 LSA. Таким образом, обозначение Type 7 предназначено только для этой специальной области NSSA.
Другие типы LSA. Существуют ли другие типы LSA? Да. Но мы не часто сталкиваемся с ними. Например, Type 6 LSA используется для многоадресной (Multicast) передачи OSPF, и эта технология не прижилась, позволяя Protocol Independent Multicast передаче победить. Для завершения ниже показан полный список всех возможных типов LSA:
LSA Type 1: Router LSA
LSA Type 2: Network LSA
LSA Type 3: Summary LSA
LSA Type 4: Summary ASBR LSA
LSA Type 5: Autonomous system external LSA
LSA Type 6: Multicast OSPF LSA
LSA Type 7: Not-so-stubby area LSA
LSA Type 8: External Attribute LSA for BGP
LSA Type 9, 10, 11: "Opaque" LSA типы, используемые для конкретных прикладных целей
OSPF ТИПЫ LSA И ТИПЫ AREA
Одна из причин, по которой вы должны освоить различные типы LSA, заключается в том, что это поможет вам полностью понять потенциальную важность multi-area, особенно такого, который может включать специальные области. Ключом к важности специальных типов областей в OSPF является тот факт, что они инициируют автоматическую фильтрацию определенных LSA из определенных областей.
Например, подумайте о области 1, присоединенной к основной области области 0. Type 1 LSA заполнил область 1. Если у нас есть широковещательные сегменты, мы также имеем Type 2 LSA, циркулирующие в этой области. Area Border Router посылает LSA Type 3 в магистраль для суммирования префиксной информации из области 1.
Этот ABR также принимает эту информацию от магистрали для других областей, которые могут существовать. Если где-то в домене есть ASBR, наша область 1 получит LSA Type 4 и LSA Type 5, чтобы узнать местоположение этого ASBR и префиксы, которыми он делится с нами. Обратите внимание, что это является потенциальной возможностью для обмена большим количеством информации между областями. Именно поэтому у нас есть специальные типы зон!
OSPF LSAS И STUB AREA (ЗАГЛУШКА)
Для чего предназначена Stub Area? Мы не хотим слышать о тех префиксах, которые являются внешними для нашего домена OSPF. Помните, у нас был такой случай? Конечно, это LSA Type 5. На самом деле, мы даже не хотим слышать о тех LSA Type 4, которые используются для вызова ASBR в сети. Таким образом, Stub Area заполнена LSA Type 1, Type 2 и Type 3. На самом деле, как эта область могла бы добраться до одного из этих внешних префиксов, если бы это было необходимо? Для этого мы обычно используем очень специальный LSA Type 3. Этот LSA представляет маршрут по умолчанию (0.0.0.0 / 0). Именно этот удобный маршрут позволяет устройствам в этой области добраться до всех этих внешних объектов. На самом деле именно этот маршрутизатор используется для получения любого префикса, специально не определенного в базе данных маршрутизации (RIB).
OSPF LSA И TOTALLY STUBBY AREA (ПОЛНОСТЬЮ КОРОТКАЯ ОБЛАСТЬ)
Использование этой области имеют малые перспективы LSA. Использование этой области имеет смысл тогда, когда мы хотим снова заблокировать Type 4 и 5, но в данном случае мы блокируем даже LSA Type 3, которые описывают информацию префикса из других областей в нашем домене OSPF. Однако здесь имеется одно большое исключение. Нам нужен LSA Type 3 для маршрута по умолчанию, чтобы мы действительно могли добраться до других префиксов в нашем домене.
OSPF LSAS И NOT SO STUBBY AREA И TOTALLY NOT SO STUBBY AREA
Запомните, что Not So Stubby Area должна иметь LSA Type 7. Эти LSA Type 7 допускают распространение тех внешних префиксов, которые входят в ваш домен OSPF благодаря этой созданной вами области NSSA. Очевидно, что эта область также имеет Type 1, Type 2 и Type 3 внутри нее. Type 4 и Type 5 будут заблокированы для входа в эту область, как и ожидалось. Вы также можете создать Totally Not So Stubby Area, ограничив Type 3 из этой области.
VIRTUAL LINKS
Вспомните из нашего более раннего обсуждения OSPF, что все области в автономной системе OSPF должны быть физически связаны с основной областью (область 0). Там, где это невозможно, вы можете использовать виртуальную связь (virtual link) для подключения к магистрали через область, не являющуюся магистралью.
Учтите следующие факты о virtual link:
Они никогда не должны рассматриваться в качестве цели проектирования в ваших сетях. Они являются временным "исправлением" нарушения работы OSPF.
Вы также можете использовать virtual link для соединения двух частей секционированной магистрали через область, не являющуюся магистралью.
Область, через которую вы настраиваете virtual link, называемую транзитной областью, должна иметь полную информацию о маршруте.
Транзитная зона не может быть stub area (заглушкой).
Вы создаете virtual link с помощью команды в режиме конфигурации OSPF:
area 1 virtual-link 3.3.3.3
Эта команда создает virtual link через область 1 с удаленным устройством OSPF с идентификатором маршрутизатора (Router ID) 3.3.3.3. Вы также настраиваете это удаленное устройство OSPF с помощью команды virtual-link. Например, если наше локальное устройство OSPF находится в Router ID 1.1.1.1, то соответствующая удаленная команда будет:
area 1 virtual-link 1.1.1.1
Примечание: virtual link — это всего лишь один из способов наладки нарушений в работе OSPF. Вы также можете использовать туннель GRE для исправления сбоев в работе OSPF.