Sham link что это
Протоколы состояния канала и однозоновый OSPF (часть 2)
Продолжение перевода главы из книги Chris Bryant «CCNP Route Study Guide». Его сайт — thebryantadvantage.com. Книга доступна на amazon.
Из всех просмотренных видео, прочитанных книг для подготовки к CCNP ROUTE, материал из этой показался наиболее легким для усвоения. Позволяет разложить все по полочкам. Кроме теории мне также понравились практические примеры. В конце каждой главы есть ссылки на уроки на youtube.
Часть 1.
Типы сетей OSPF
Почему типы сетей OSPF важны
По умолчанию тип сети OSPF зависит от типа сегмента сети. Различные типы сетей OSPF имеют различные значения hello- и dead- таймеров, и это одни из значений, которые должны совпадать для установления соседства между двумя маршрутизаторами. Кроме того, некоторые типы сетей OSPF не имеют DR и BDR, а у других есть особые условия, которые необходимо соблюдать.
Кроме того, они все одинаковые, правильно? 🙂
Не беспокойтесь, мы рассмотрим каждый тип сети OSPF, необходимый для сдачи экзамена CСNP ROUTE!
Если не указано иное, сегмент сети находится в зоне 0 — основной зоне.
Адрес подсети широковещательной сети — 10.1.1.0/24. Последний октет каждого IP адреса будет номером маршрутизатора. Каждый маршрутизатор имеет петлевой интерфейс, с номером маршрутизатора в каждом октете. (Петлевой интерфейс для R1 — 1.1.1.1/32 и т.д.)
Широковещательная сеть OSPF
Конфигурация OSPF в сегменте Ethernet для широковещательной сети будет оставлена по-умолчанию, также будут выбраны DR и BDR, для влияния на выбор DR/BDR можно использовать команду ip ospf priority.
Для большого сегмента сети хорошая идея использовать мощные маршрутизаторы для выполнения этих ролей (DR/BDR), так как это влечет за собой нагрузку на CPU. Как всегда, все, что мы делаем на маршрутизаторе имеет свою цену.
Вывод команды show ip ospf interface ethernet0 на маршрутизаторе R1 показывает нам тип сети, а также много другой информации. Заметьте, значения по-умолчанию hello- и dead- таймеров широковещательной сети — 10 и 40 секунд соответственно. По-умолчанию dead time равен четырехкратному hello time.
Для широковещательного сегмента не обязательно делать определенный маршрутизатор DR или BDR, но для нашего следующего примера это не так.
Сеть OSPF NBMA
Сейчас мы добавим еще сегмент к существующей сети, на frame relay. Новый сегмент использует адрес 172.12.123.0/24. От R1 идет два канала PVC до R2 и R3; между «спицами»(spoke) PVC нет. Интерфейс Serial0 каждого маршрутизатора находится в зоне 0.
Последовательные интерфейсы в этом новом сегменте по-умолчанию будут нешироковещательными с множественным доступом (NBMA). Так как узлы сети не образуют полносвязную сеть, хаб-маршрутизатор R1 должен быть DR и здесь может не быть BDR.
Почему? У DR и любого потенциального BDR должна быть возможность получать мультикаст от всех остальных маршрутизаторов в сети. В топологии «звезда» у spoke-маршрутизатора нет возможности получать широковещательный или мультикаст трафик от другого spoke-маршрутизатора, так как весь трафик проходит через хаб — а маршрутизаторы не перенаправляют широковещательный или мультикаст трафик!
Перед настройкой любой OSPF конфигурации поверх frame relay, убедитесь, что опция broadcast у вас включена!
Иначе OSPF пакеты не будут передаваться через frame relay.
Недостаточно просто убедиться, что R1 стал DR — мы должны предотвратить возможность становления DR/BDR для R2 и R3! Для этого изменим приоритет со значения по-умолчанию (1) на 0.
Маршрутизатор с наибольшим значением приоритета интерфейса, на котором включен OSPF, становится DR. Если значения приоритета равны, то сравниваются идентификаторы маршрутизаторов (RID), выигрывает — наибольший.
Фактически, мы мошенничаем с выбором DR, не оставляя шансов для spoke-маршрутизаторов, даже при исчезновении хаба! Установка приоритета в 0 для spoke-маршрутизаторов не оставляет им возможности стать DR в случае перезагрузки хаб-маршрутизатора.
«NB» в слове NBMA означает «нешироковещательный», так что при конфигурировании хаб-маршрутизатора нужно вручную указывать соседей, как показано ниже. Для spoke-маршрутизаторов такое не требуется.
У вас может быть сеть NBMA c DR и BDR, но они оба должны быть хаб-маршрутизаторами. Сеть с двумя хабами может использовать один как DR, другой как BDR. Каждый DR или BDR должен иметь статически настроенных соседей; такая настройка не нужна на других маршрутизаторах. (Если у вас много хаб-маршрутизаторов, один из них может быть BDR).
Заметьте, hello- и dead- таймеры равны 30 и 120 соответственно. Dead-таймер снова в четыре раза больше, чем hello.
Последовательные интерфейсы по-умолчанию NBMA, но вы можете изменить тип сети OSPF интерфейса командой ip ospf network.
Типы сетей OSPF Point-To-Point и Point-To-Multipoint
Сейчас мы добавим прямое соединение между R1 и R3, но расположим его в зоне 13. Номер подсети 172.12.13.0/27. Интерфейсы Serial1 обоих маршрутизаторов находятся в этой зоне 13.
Все non-backbone зоны должны иметь маршрутизатор с логическим или физическим интерфейсом в основной зоне 0. В зоне 13 два таких маршрутизатора, так что конфигурация правильная.
show ip ospf interface serial1 покажет данный сегмент OSPF по-умолчанию для типа сети OSPF point-to-point. Этот вывод показывает также по-умолчанию hello- и dead- таймеры для данного типа сети — 10 и 40 секунд соответственно.
Заметьте, что в списке нет DR и BDR. В канале «точка-точка» только два маршрутизатора. Следовательно, нет необходимости даже иметь DR или BDR, и ни один маршрутизатор не будет выбран в качестве таковых.
show ip ospf neighbor показывает прочерки на месте, где обычно указана роль соседа. Процесс выбора DR/BDR опускается в point-to-point и point-to-multipoint сетях. Команда neighbor обычно не нужна в этих сетях. Ниже R3 видит R1 как DR в сети NBMA, тогда как он же без роли видим в сети point-to-point.
Прочерк после FULL/ показывает, что сосед не является ни DR, ни BDR, ни DROther, что означает, что процесса выбора DR/BDR не было. Вы увидите подобную ситуацию в OSPF сети point-to-multipoint, что OSPF воспринимает, как набор каналов point-to-point.
Например, мы можем вернуться и изменить конфигурацию OSPF сети frame relay как сети point-to-multipoint командой ip ospf network point-to-multipoint на последовательном интерфейсе маршрутизатора R1. DR/BDR выбраны не будут и команда neighbor не нужна.
Теперь сеть OSPF типа point-to-multipoint предлагает два варианта — широковещательная и нет.
Конфигурация широковещательной OSPF сети Point-To-Multipoint
Этот тип сети не требует команды neighbor, но вы можете определить стоимость для данного соседа.
Заметьте, что опция broadcast отсутствует, так как по-умолчанию сети типа point-to-multipoint — широковещательные.
Нешироковещательная OSPF сеть Point-To-Multipoint
С другой стороны, в нешироковещательной сети point-to-multipoint команда neighbor требуется. Вы можете добавить стоимость для соседа, но соседи должны быть статически определены для данного типа сети.
Запуск широковещательных OSPF сетей над топологией NBMA
То, что вы можете что-то сделать, не означает, что вы должны это делать!
Нам следует использовать команду ip ospf network broadcast на всех маршрутизаторах сети frame relay, и, так как сеть полносвязная, технически все должно работать и маршрутизаторы будут вести себя так, как если бы были в LAN сети.
В реальной жизни использование широковещательной OSPF сети в сегменте NBMA может привести к непредсказуемым результатам, и лично я не стал бы так делать.
Зачем тратить время на устранение проблем, когда можно придерживаться настроек по-умолчанию?
Виртуальный канал (virtual link) OSPF
Настройки OSFP сети, запущенной через frame relay, были восстановлены до значений по-умолчанию для сети типа NBMA и останутся таковыми до конца данного раздела.
Сейчас мы добавим маршрутизатор R4 в нашу сеть. R4 и R3 будут соседями через зону 34, у R4 будет петлевой интерфейс в зоне 4. Адрес подсети для сегмента между R3 и R4 — 172.12.34.0/24, сегмент ethernet.
Результат данной конфигурации — неполные таблицы маршрутизации, что приводит нас к еще одному типу сетей OSPF. С зоной 34 проблем нет — один из маршрутизаторов с интерфейсом в этой зоне, также имеет физический интерфейс в основной зоне (R3).
Но в зоне 4 нет ни одного маршрутизатора с интерфейсом в зоне 0. Значит нужно сконфигурировать логическое соединение с зоной 0 — virtual link.
Так как у маршрутизатора R3 есть интерфейс в зоне 0, запуск виртуального канала между R3 и R4 позволит достичь полной связности в сети. Проблема в том, что у R1 нет маршрута до петлевого интерфейса R4, несмотря на то, что этот интерфейс был включен в OSPF.
Зона, через которую проходит виртуальный канал называется транзитной (transit area), она не может быть stub-зоной любого типа (stub, total stub, nssa) (Если вас раздражают все эти названия — не беспокойтесь, в данном курсе впереди еще будет много информации по ним!).
Вот команды для создания виртуального канала:
Виртуальные каналы должны быть сконфигурированы на обоих концах транзитной зоны. Сейчас перейдем к R3 и завершим конфигурацию.
И еще несколько деталей…
—Команда virtual link использует RID удаленного устройства, не обязательно IP адрес интерфейса, находящегося в транзитной зоне. Следите за этим — это очень распространенная ошибка. Проверяйте RID!
—Также не беспокойтесь насчет сообщений об ошибках в выводе команд R3, это нормально, вы будете видеть такие сообщения пока не закончите настраивать виртуальный канал. А вот если сообщения об ошибках появляются после настройки — то у вас проблема.
Всегда проверяйте виртуальный канал командой show ip ospf virtual-link. Если все настроено правильно, то он должен подняться за секунды.
Виртуальные каналы просто настраивать, но по какой-то причине они пугают людей. По моему опыту, сообщение об ошибке, как для маршрутизатора R3, вызывает панику, но все, что значит такое сообщение — только то, что настройка виртуального канала не закончена.
Знания рассеивают страх и панику.
99% ошибок при настройке виртуального канала вызывают следующие действия:
—использование неправильного значения RID
—попытка использовать stub-зону в качестве транзитной
—ошибка при настройке аутентификации для виртуального канала, в случае, когда зона 0 использует аутентификацию.
Этот третий случай выделен специально. Последнее всегда забывается! Виртуальный канал — это расширение зоны 0, и если зона 0 использует аутентификацию, она должна быть настроена и для виртуального канала тоже.
В этом разделе мы рассмотрели много команд OSPF, но не забывайте вашего старого друга — show ip protocols. Безотносительно типа сети, эта команда покажет вам маршрутизируемые сети, информацию об аутентификации для канала, и многое другое. Это замечательная команда для начала устранения проблем для любого протокола маршрутизации.
Вопросы и ответы ССNP,CCVP,CCSP,CCIP
#61 BonchBruevich
#62 Megakazbek
#63 fantas1st0
#64 BonchBruevich
There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy.
#65 Ilya Z.
кто-то здесь что-то путает
настроить вообще не проблема
вот только это затрагивает маршруты которые получены через обычное MP-BGP взаимодействие, и если домен-ид различны двух РЕ, то маршруты будут считаться и объявляться как внешние (тип 5), а не как межзонные (тип 3)
это то что я смог найти в сети по этому вопросу, когда будет возможность, обязательно проверю, если конечно меня не опередят или аргументы не перестанут отличаться от найденой мной информации
#66 fantas1st0
#67 Ilya Z.
и вот, вопрос в догонку, почему же пока не была включена редистрибьюция между протоколами, ареа 0 была неактивна, хотя
в этой ареа есть как минимум 2 интерфейса плюс сам шам-линк
а вот еще забавная вещь
на интерфейсе включен ОСПФ, а его ip нету в ЛСДБ
что это? особенность работы к лупбек интерфейсами? косяк настройки? или я не туда смотрю?
#68 BonchBruevich
Все напрямую подключенные сети (точнее, интерфейсы в эти сети) объявляются внутри пакета Router-LSA. В базе данных ospf указывается только router-id отправителя.
Чтобы ареа была активной, апнутых интрефейсов недостаточно. Нужны пиры.
Пруфлинк: хэв фан виз Скотт Моррис
#69 Ilya Z.
это я в курсе, меня что-то переклинило, вижу «Link Count 2», вопрос возник из другого
Почему я не вижу здесь адреса лупбека? согласно правилу, когда включается редистрибьюция для протокола, то также происходит редистрибьюция всех connected сетей для которых включен данный протокол. для рип и еигрп это справедливо, а оспф думает по своему? уже всякого про него насмотрелся но все еще меня клинит на некоторых его нюансах
я читал эту ссылку, три раза перечитал коммент того перца, он как-то коряво выразил свою мысль, я его так и не понял
#70 BonchBruevich
Чтобы ospf редистрибуцировл лупбеки, нужно сказать, что это не лупбек, а, например, поинт-ту-поинт:
Что такое OSPF Sham Link и в чем его функция
Что такое OSPF Sham Link и в чем его функция
В многопротокольной Label Switching (MPLS) виртуальной частной сети (VPN) конфигурации, OSPF используется в качестве протокола маршрутизации между РЕ и ВЭ таким образом, чтобы сайты в VPN могут быть подключены через MPLS магистральной сети. Хотя соединение между OSPF ИМ и ВЭ обеспечивает связь между VPN-сайтами, связь внутри зоны между VPN-сайтами также должна быть рассмотрена. Для двух сайтов на том же самом месте, путь через линию внутри области всегда предпочтительнее, поскольку, в соответствии со спецификациями OSPF, канал для интра-зона всегда предпочтительнее на пути между области. Поэтому, когда связь внутри зоны, рассмотрите возможность управления маршрутами через политику.
Если ссылка внутри области используется для резервного копирования только, но не используется для предоставления VPN услуг, поток обработки по умолчанию будет неприемлемо. Для подключения необходимо восстановило между сайтами через магистральную область MPLS VPN, связь логическая внутри зон должна быть установлена между входным и выходными виртуальной маршрутизацией и экспедиторских интерфейсами (VRF) от соответствующих элементов программы. Эта функция обеспечивает решение о создании фиктивной ссылки OSPF между двумя сайтами как внутри зоной каналом таким образом, что два сайта общается друг с другом через MPLS магистральной область, в то время как ссылка внутри область используется для резервного копирования. Если связь внутри зоны не существует между двумя узлами, никакой связи притворство не требуется.
OSPF Sham links
OSPF Sham Links
На рисунке вы можете видеть использование OSPF sham links для избежания проблем создаваемых intra-area backdoor линком. Sham link это логический intra-area link между VRF B на PE 2 и PE 3. OSPF создает сходимость (соседство) и обменивается LSA через sham link. В результате, OSPF видит оба пути поверх backdoor линка и путь поверх backbone как intra-area пути. После этого OSPF выбирает кратчайший путь, основываясь на метрике этих линков и выбирает sham link путь, убедившись при этом, что backdoor link не используется.
Важно. Если стороны VPN соединения не подключены OSPF backdoor линко или стороны VPN соединения находятся в разных OSPF ариях, то проблемы, в сущности, не существует и нет необходимости в конфигурировании OSPF sham link.
Нужно использовать команду типа remote-neighbor, чтобы сконфигурировать OSPFsham link на обоих VRF (VPN-instance), делящих этот линк. Если BGP маршрут и OSPF маршрут к одному адресу назначения оба присутствуют в таблице маршрутизации, OSPF использует OSPF маршрут, потому что у него предпочтительный administrative distance по определению.
Если вы аннонсируете маршруты OSPF в BGP в каждый VRF, то вам не нужны, чтобы OSPF маршруты, проходящие через sham link редистрибутились в BGP. Если же они редистрибутились, то множественные BGP маршруты будут существовать для единственного OSPF маршрута: по одному BGP маршруту для каждой конечной точки sham link.
Можно использовать определенную команду, чтобы не допускать OSPF маршрутов из sham link в таблицу маршрутизации VRF, и, следовательно, не допускать их редистрибуцию в BGP. Пересылка пакетов при этом все равно работает, используя MP-iBGP маршрутов, полученных от удаленного PE роутера.
Использование этой команды позволяет избежать множества маршрутов BGP к одному и тому же префиксу, предотвращая перераспределение маршрутов OSPF, полученных через sham link, обратно в BGP, даже если вы настроили перераспределение маршрутов OSPF в BGP.
Если вы не настраиваете sham link между каждой парой маршрутизаторов PE, для которых существует backdoor link, вам необходимо редистрибутить маршруты BGP обратно в OSPF.
Настройка ложного канала (sham link) OSPF
Задачи предварительной настройки
Ложный канал между двумя устройствами PE (Provider Edge) в магистральной сети MPLS VPN считается маршрутом между зонами (areas) OSPF. Трафик VPN передается по маршруту через магистральную сеть (backbone network), а не через скрытые (backdoor) маршруты.
Перед настройкой ложного канала OSPF выполните следующие задачи:
● Настройте базовые функции BGP/MPLS IP VPN (OSPF между PE и CE (Customer Edge)).
● Настройте OSPF в сетях LAN, где расположены устройства CE.
Описание
Ложные каналы OSPF — это ненумерованные IP-соединения P2P (point-to-point) между двумя устройствами PE в магистральной сети MPLS VPN.
Как правило, BGP-пиры используют расширенные BGP атрибуты community для передачи маршрутизируемой информации по магистрали MPLS VPN. Протокол OSPF на устройстве PE может использовать информацию о маршрутизации для создания маршрутов между зонами от устройства PE к устройству CE.
Как показано на рис. 1, если межзонное соединение OSPF существует между сегментами сети локального и удаленного устройств CE, этот соединение OSPF называется скрытым каналом (backdoor link).
Рисунок 1. Ложный канал OSPF
Маршруты, которые проходят через скрытый канал — это маршруты между зонами и имеют более высокий приоритет,чем маршруты между зонами, которые проходят через магистральную сеть MPLS VPN. В результате VPN трафик всегда переадресовывается через скрытые маршруты, а не через магистральную сеть. Как правило, скрытые каналы используются только в качестве резервных.
Чтобы избежать такой проблемы, между устройствами PE можно создать ложный канал OSPF. Таким образом, маршруты, которые проходят через магистральную сеть MPLS VPN, становятся межзонными маршрутами OSPF и имеют более высокий приоритет, чем скрытые маршруты при передаче VPN трафика.
Настраивать ложный канал OSPF следует только при существовании скрытого канала между двумя сайтами в одной и той же зоне OSPF. Если в одной зоне между сайтами нет скрытого канала, настраивать ложный канал OSPF не требуется.