Китайская грамота

Итак, что предлагают нам китайские коммунисты?

Пусть у нас есть сеть:

Рис. 1.

Метрики линков - просто числа, а метки, распространяемые LDP, - числа со стрелочкой и буквой L. Стрелочки показывают направление анонсов меток и противоположны потоку трафика с этой меткой. Показаны метки для FEC R5. FEC = Forwarding Equivalence Class, в этом посте будем считать, что FEC - это совокупность всех пакетов, покидающих MPLS-домен через один и тот же узел.

В штатном состоянии роутеры видят R5 следующим образом:
R1 через R2
R2 через R5
R3 через R4
R4 через R5
а R5 - это он и есть.

Почему метки распространяются так, как нарисовано, я объясню ниже.

На R2 интерфейс, ведущий к R3, назначается запасным по отношению к интерфейсу, ведущему к R5. Как я понял из хуавейской статьи, это назначение делается вручную.

Что происходит, когда линк R2-R5 падает? Ну, во-первых, R2 это обнаруживает. Каким способом обнаруживает - сейчас не очень важно. Обнаружив, что линк R2-R5 лежит, R2 берет и переключает трафик, который должен был идти по лежащему линку, на запасной, подставляя соответсвующие метки. В статье от хуавея написано про то, что в LFIB программируются сразу две метки: основная и запасная, но сейчас нам это тоже не очень важно, нас интересует общая логика работы.

В нашем случае трафик R1 пойдет, как показано на рисунке:

Рис. 2.

После этого начнется нормальная сходимость нашего протокола маршрутизации. Когда IGP сойдется, R1 переключится на R3 и потоки трафика оптимизируются. Но это все произойдет миллисекунд через 300-400, если сеть не такая маленькая, как у нас. А пока трафик течет пусть и неоптимально, но вполне успешно.

Круто? Круто. А теперь давайте посмотрим повнимательней.

Посмотрим на ту же самую сеть, но с немножко другими метриками линков (я пометил измененные метрики синенькими кружочками):

Рис. 3.

Теперь пути к R5 немного другие:
R1 через R2
R2 через R5
R3 через R2
R4 через R5

Метки LDP распространяет так же как и раньше.

Что теперь? R2, как и раньше, обнаруживает падение линка R2-R5 и разворачивает трафик, идущий к R5, на линк R2-R3. Но в этот момент R3 еще не знает о том, что линк R2-R5 упал, и что теперь лучший путь к R5 лежит через R4. И R3 отдает трафик обратно на R2. Ну и что мы получили? Взамен быстрого восстановления мы получили петлю R2-R3-R2. Очень плохо. После того, как IGP сойдется, эта петля, конечно, рассосется.

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

Хуавей пишет в своей статье про то, что его замечательное изобретение работает, если LDP работает в режиме downstream unsolicited advertisement + liberal retention (хуавей называет это libertarian hold - наверное, это дефект двойного перевода английский-китайский-английский, а может, в этом есть политическая подоплека :) ) + ordered control. Важными на самом деле являются liberal retention и ordered control, а downstream unsolicited они упомянули просто для полноты - на самом деле liberal retention работает только в комплекте с downstream unsolicited.

Что такое label retention mode и какие они бывают?

Когда узел анонсирует некоторую метку своим соседям, у этих соседей есть выбор, что делать с теми метками, которые они сейчас не используют: сосед может либо забыть лишнюю метку, либо заныкать на будущее. Первое называется conservative retention, второе - liberal retention.

Достоинства и недостатки понятны. Conservative retention позволяет сэкономить немного памяти, но когда метка понадобится, ее придется попросить у соседа снова. С liberal retention все наоборот: неиспользуемые метки надо где-то хранить, но, когда изменится best path, меточка тут как тут - ее можно брать и немедленно использовать. Очевидно, для работы LDP FRR необходим liberal retention, поскольку LDP FRR предполагает немедленную готовность запасной метки.

Что такое label distribution control и какие здесь варианты?

Узел может просто брать и назначать метку для некоторого FEC, как только он узнал о существовании этого FEC. Это называется independent control.

Узел может назначать метку для некоторого FEC, только 1) если он сам является точкой назначения для этого FEC либо 2) если он получил метку для этого FEC от узла, который является следующим в пути к этому FEC. Такой порядок действий называется ordered control.

По rfc3036 в обоих режимах узел распростаняет метку во всех направлениях. Что и приводит к двуххоповой петле, которую я описал выше. А вот новый draft-ietf-mpls-rfc3036bis позволяет в случае ordered control делать так называемый split horizon: если мы получили метку от next hop узла, то мы можем посылать метку всем, кроме этого самого next hop узла. Это устранит петлю, про которую я говорил. Проиллюстрирую:

Рис. 4.

Судя по тому, что хуавей настаивает на ordered control, они реализуют split horizon в стиле rfc3036bis.

Теперь R2 в случае сбоя линка R2-R5 не сможет развернуть трафик на линк R2-R3, т.к. R3 не анонсировал метку для FEC R5 узлу R2. В этом случае мы не получили быстрого восстановления, но зато избежали образования петли.

Обратите внимание, что в сети, показанной на рис. 4, линк R2-R5 вообще нельзя защитить. Здесь R2 - next hop и для пути R1->R5, и для R2->R5. R2 распространяет метки для FEC R5, и, соответственно, не получает никаких запасных меток для этого FEC.

А устраняет ли ordered control split horizon все возможные петли? Нет. Опять проиллюстрирую:

Рис. 5.

Теперь пути к R5 такие:
R1 через R3
R2 через R5
R3 через R2
R4 через R5

Пусть защищаемый линк - R2-R5, защищающий - R2-R1. Что произойдет в случае сбоя защищаемого линка? R2 перенаправит трафик на R1, благо метка соотвествующая есть, R1, еще не зная о случившемся, продолжит передавать трафик на R3, а R3 на R2. Вуаля, петля из трех хопов, не смотря ни на какой split horizon.

Итак, как показано, стоит ошибиться с выбором защищающего интерфейса, то мы не только можем не получить никакой защиты, но и в ряде случаев можем значительно ухудшить ситуацию.

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

Так что же, LDP FRR никуда не годится, и применить это чудо инженерной мысли никак нельзя? Можно, на самом деле. Достаточно безопасно использовать LDP FRR на узлах, которые не несут транзитного трафика в MPLS-домене.

Вот в такой сети мы можем использовать комбинацию MPLS TE FRR и LDP FRR:

Рис. 6.

Здесь D-узлы выполняют только граничные функции - они не несут никакого транзитного MPLS-трафика. Внутри ядра у нас full mesh защищенных MPLS TE туннелей. А внутри POP можно использовать LDP FRR: на узле D_i линк D_i-C1 защищает линк D_i-C2 и наоборот. А на C-узлах линк C_j-D_i защищен линком C1-C2. Линк C1-C2 защищается MPLS TE FRR.

Что хорошего в таком дизайне? Все защищено, но число MPLS TE туннелей сильно сокращено по сравнению с full mesh между D-узлами. Соответственно, меньше forwarding state в ядре, компактней RSVP-сигнализация.

Резюме. Наши коммунистические братья пудрят нам мозг, утверждая, что LDP FRR - альтернатива MPLS TE FRR. Это не так. LDP FRR не пригоден для общей защиты трафика в сети. Его применение ограничено только отдельными участками сети при соблюдении довольно жестких условий. Но если его применить с умом, то выгоды есть.

Есть ли подход к решению задачи защиты трафика без MPLS TE FRR? Есть. Я упоминал и в этом, и в одном из предыдущих постов технологию IP FRR. Вот презентация о том, как это делается правильно: http://www.apricot2006.net/slides/conf/thursday/Stefano_Previdi_IPFRR-Apricot.pdf

This entry was originally posted in my livejournal