Взаимодействие OSPF и BGP.

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

R1

   |   \

             |     R3---

   |   /

R2

Маршрутизаторы R1 и R2 анонсируют несколько внешних префиксов в OSPF, а R3 редистрибьютит OSPF в BGP. При этом, наша задача отфильтровать маршруты полученные от R2, но нельзя использовать route-map на R3. Как это сделать?

Как оказалось, существует отдельный стандарт регламентирующий взаимодействие между OSPF и BGP, RFC 1364 (1992 год). Так вот, в нем указано следующее: 

      These are routes imported from routing protocols with complete
      path information and carry the AS path information as part of the
      routing information.

      The OSPF tag must be set to
                        a=1,c=1,pl=10,as=don't care

      These routes must not be exported into BGP because these routes
      are already imported from BGP into the OSPF RD. 

Таким образом, изменив route tag на роутере R2 на значение >= 3 758 096 384 (что в hex представлении равно 0xE0000000). Мы, согласно озвученному правилу, предотвратим дальнейшую редистрибьюцию подсетей в BGP.

E1 vs. E2

Этот вопрос отлично разжевал Брайан в своей статье "Understanding OSPF External Route Path Selection". Для себя попробую изложить её содержимое тезисно и кратко.

Первое, вне зависимости от метрик и AD, OSPF всегда выбирает маршруты в следующем порядке:

1. Intra-Area (O)
2. Inter-Area (O IA)
3. External Type 1 (E1)
4. External Type 2 (E2)
5. NSSA Type 1 (N1)
6. NSSA Type 2 (N2)

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

DPD и Split Tunneling.

Кстати, именно при работе с DPD мы столкнулись с новым циско багом. В нашей компании применялась следующая конфигурация EzVPN:

crypto ipsec client ezvpn PRIMARY
  connect auto
  group PRIMARY key <removed>
  local-address FastEthernet0/0
  mode network-extension
  peer A.A.A.A default
  peer B.B.B.B
  virtual-interface 1
  xauth userid mode interactive

Ключевое слово default после адреса VPN пира, активирует фичу под названием Reactivate Primary Peer. Из документации становится ясно, что данная настройка позволяет с помощью DPD обнаружить неактивный пир, переключиться на резерв, а после восстановления основного, вернутся на него. Красиво? Красиво! Но почему-то не работает в связке со split-tunneling'ом. Точнее переключение происходит, но статические маршруты образованные в результате работы split-tunneling'а пропадают.

Такая вот багофича.

DPD, Dead Peer Detection.

crypto isakmp keepalive

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

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

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

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

MAC-адреса и свитчи.

Для чего нужны mac-адреса свитчу? По мимо userspace адресов есть несколько типов необходимых для обеспечения функционирования L2 сегмента. Их можно выделить в несколько групп:

• Адреса портов, жестко привязаны каждый к своему порту и применяются только для передачи сontrol plane информации. Т.е. выступают в качестве source address для BPDU и CDP сообщений, и тому подобному.
• Адреса общего назначения, используются в более абстрактных штуках (BID для STP, MAC для SVI и т.д.). Количество их зависит от модели коммутатора.
• Специализированные адреса протоколов, например CDP, LLDP, 802.1x, OAM и различные версии STP. При получении фрейма с таким адресом в качестве назначения, свитч должен будет произвести его обработку направив в CPU.

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

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

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

Петли и MPLS

Думаю, что на вопрос о методах борьбы с петлями в MPLS окружении можно отвечать несколькими способами. Например вот так: 

• Построением loop-free окружения занимается лежащий в основе MPLS сети протокол динамической маршрутизации, например OSFP или IS-IS.

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

• Простейшее дополнение: MPLS заголовок имеет поле TTL значение которого копируется из оригинального IP заголовка (или не копируется в случае no mpls ip propagate-ttl). Это не спасет от появления петель, но позволит справиться с их последствиями.

• Сложное дополнение: может показаться надуманным, но существует способ избежать кратковременных петель возникающих после падения линка. Это механизм MPLS RSVP-TE. Ему можно посвятить отдельный раздел|книгу|религию.

• Архивные дополнения: давным-давно, во времена ATM и Frame-Relay, в MPLS успешно уживались и другие способы избавления от петель. К ним относятся Hop Count TLV, Path-Vector TLV и алгоритм Coroled Thread.