OSPF PE-CE Protocol, part II

Это даже скорее не часть два, а небольшое дополнение касающееся работы loop prevention механизмов, написано по горячим граблям так сказать

Раньше, Cisco действительно довольно своеобразно реализовывала RFC4576, просто не выставляя DN-бит для всех LSA кроме summary. Однако, это поведение было исправлено и в современных софтах она таки блюдет RFC. Что приводит иногда к странным ситуациям, например топология успешно работающая на IOS 12.2(33), может совсем не заработать в 15.x или NX-OS. 

А всё дело в волшебных пузырьках! То есть, в функции capability vrf-lite, если она действительно помогала вам ранее в Cisco IOS, то в NX-OS её уже нет. Возникла ситуация, что мы хотим получать маршруты из MPLS-облака как прежде, но capability vrf-lite здесь нет. Да, есть опция down-bit ignore, но работает она по другому. Она просто отключает проверку DN-бита, но не отключает проверку domain-tag как прежде делала capability vrf-lite превращая наш PE роутер в CE.

Всё получается несколько сумбурно. Главное для меня не забывать о тонкостях редистрибьюции в OSPF. В нашем случае мы в итоге обошли loop prevention механизм в NX-OS, вручную управляя domain-tag, что приводило к порой очень внезапным последствиям.

DPD, Dead Peer Detection.

crypto isakmp keepalive

Итак, DPD или Dead Peer Detection, что же это такое? Как видно из названия, это механизм обнаружения неработающего пира в рамках IKE и IPSec. Но механизм признаться чудной.

DPD был призван решить проблему периодических keepalive, которые при значительном числе spoke роутеров могут вызвать проблемы на центральных VPN-хабах. Да и вообще, это как-то не комильфо и требует внимания к интервалам keepalive запросов.

Стандартизированный в RFC 3706 протокол обнаружения "залипших" пиров, избавлен от этого недостатка и в сути своей непериодичен и асинхронен. А всё потому, что главным критерием определения нерабочего пира является собственно простой установленной IPSec сессии.

Но как это работает?

Что делает qos pre-classify?

Иногда встречаются недопонимания этой команды. По сути, pre-classify позволяет использовать данные из оригинального IP заголовка для обеспечения QoS в IPSec VPN окружении. Под данными здесь подразумевается не просто значение ToS байта, которое по умолчанию будет скопировано в IPSec, а остальные заголовки оригинального пакета. По сути, эта информация извлекается и передается в исходящий интерфейс параллельно с уже зашифрованным пакетом. Что соответственно позволяет использовать её для service policy.

Стоит учитывать, что pre-classify используется только на spoke роутерах и эффективно ограничивает лишь исходящий трафик. Со стороны же центрального vpn-концентратора, традиционно советуют реализовывать per-tunnel qos policy.

Быть или не быть, succesor или feasible succesor?

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

Если маршрут через successor становится недействительным (изменилась топология) или у соседа изменилась метрика, DUAL проверяет, есть ли для данного маршрута feasible successor.
Если feasible successor есть, DUAL использует его в качестве successor-а, что позволяет избежать перерасчет маршрута.
Если feasible successor-а для маршрута нет, производится перерасчет маршрута. Хотя перерасчет не сильно загружает процессор, он занимает определенное время, поэтому желательно избегать ненужных перерасчетов.

На первый взгляд всё так и есть. Но если попытаться разобраться в том, как работает DUAL, станет понятно, что данное описание неполно. Рассмотрим следующую топологию в качестве примера:

Cisco и таблица маршрутизации.

sh ip route

Известная всем команда выводит текущение содержимое таблицы маршрутизации. Но стоит задуматься, откуда там появляются маршруты? Как они удаляются оттуда? Что вообще черт побери происходит? Рассмотрим ответы на эти вопросы далее.

Познакомимся поближе с virtual-link

Virtual-link?

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

Рассмотрим следующую топологию:

LSA четвертого типа в OSPF. Откуда?

Откуда же берутся LSA 4 в OSPF? Их назначение известно хорошо, т.к. LSA 5 проникают сразу во все области нашего OSPF, требуется как-то находить источник внешних маршрутов. Довольно часто встречается ошибочное мнение (например в статьях на хабре), что ASBR генерирует LSA 4 прямо совместно с LSA 5. Что есть совсем неправда. Рассмотрим простую топологию:

MPLS VPN, OSPF PE-CE Protocol

Введение.

Рассмотрим несколько особенностей OSPFv2 как PE-CE протокола в MPLS VPN окружении. Для этого нам понадобится горсть различных роутеров да немного энтузиазма.

Итак, зачем же нам именно MPLS VPN? Почему просто не экспортировать маршруты в обычный BGP бэкбон? Это действительно можно сделать, но проблема в том, что BGP не сохранит значение route type, что в конечном итоге приведет к экспорту нашего маршрута в целевой OSPF с типом «внешний». Казалось бы, что в этом плохого? А вот целый список минусов такого подхода: