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

Sennheiser HD 439, моддинг.

Оффтопик.

Что мы делаем на работе помимо всего прочего? :) Слушаем музыку конечно. Так вот, у наушников Sennheiser HD 439 есть существенный недостаток. Они очень специфично отрабатывают бас, его по ощущениям мало и всё такое. Однако, для исправления ситуации есть довольно просто мод найденный на просторах Head-Fi.

Достаточно разобрать наушники сняв амбушюры и вытащив драйвер:

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

После модификации не происходит изменений в воспроизведении средний и высоких частот. Только баса становится ровно как надо. Например трек "Speak To Me" знаменитый своими низкими частотами, звучит теперь как надо .

vPC и динамическая маршрутизация.

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

Подобная проблема возникает при попытке организации OSPF пиринга поверх vPC. Как и с остальными MLAG решениями это довольно нетривиально. Самое главное, надо запомнить следующее правило:

VPC peers are expected to forward a frame received on a member link out any other member link that needs to be used. Only if they cannot do so due to a link failure, is forwarding across the VPC  peer link and then out a member link allowed, and even then, the cross-peer-link traffic can only go out the member link that is paired with the member link that is down.

Из него не следует вывод, что нельзя организовывать L3 связность поверх vPC peer-link. Это с определенными ограничениями возможно. Данное правило один из элементов построения безпетлевой топологии. Оно же и ограничивает возможное множество решений.

Взаимодействие 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.