Так!

Дело вот в чем. Есть один очень противный сценарий отказа. Редкий, но очень плохой. Бывает так, что роутер попадает в такую позу, что пакетики к нему самому, т.е. к егойному control plane'у, идут, а вот насквозь - фигушки. И лежит такой роутер, как живой, будто и не помирал вовсе, и даже не пахнет от него - все adjacencies на месте, bgp-сессии стоят как почетный караул, но в баскетбол играть пакетики через него не пролезают. Трижды за свою жизнь такое видел и самолично траблшутил. Понятно, что всякими обычными стандартными средствами этот отказ не обнаруживается, а раз не обнаруживается, то и сеть от такого отказа не восстанавливается, пока бедную железяку из этой позы руками насильственно не выведут.

В принципе, есть решение прямое и дубовое - end-to-end monitoring, благо, LSP ping изобрели уже давно. Знай себе фигачь из конца в конец, а ежели фигачить перестало, кричи громким голосом и переходи на запасной путь, например, врубай path protection. Надо побыстрее и с меньшим оверхедом? BFD multihop в помощь. Одна беда - это не масштабируется: N^2 мониторинговых сессий - это очень тяжело, а в большой сети практически невозможно.

Так вот, драфтик, про который я начал рассказывать, обещает нам неземное счастье прямо сейчас. Он вводит довольно остроумную схему самотестирования forwarding plane. Я прямо картику из драфта передеру:

                 +-------+       +-------+       +-------+
                 |     ,-|-------|<DPVRq |       |       |
                 |     `-|-------|-------|-------|->     |
                 |       |       |       |       |       |
                 |       |       |     <-|-------|<DPVRp |
                 +-------+       +-------+       +-------+
                   LSR-U           LSR-T           LSR-D

               DPVRq: MPLS Data Plane Verification Request
               DPVRp: MPLS Data Plane Verification Reply

                    Figure 1: Self Test Message Flow

Сначала роутер посылает request, предназначенный для downstream'ного роутера, но посылает он его вверх, upsteam'ному роутеру. Тот этот request заворачивает, request пролетает через forwarding plane самотестирующегося роутера, долетает до downstream'а, а тот отвечает "так точно, все хорошо". Здорово, правда? Для организации этого фокуса употребляется довольно нехитрая механика, про которую желающие могут прочитать в драфте. Масштабируется это вполне разумно - количество тестов зависит от числа непосредственных соседей, а не от общего числа роутеров в сети.

Если такое самотестирование обламывается несколько раз, роутер может сказать "всем привет" и положить свои adjacencies, чтобы соседи трафик через него не слали. Очень часто тестировать такое не обязательно - отказ действительно редкий. Главное, чтобы сеть могла от такого отказа самостоятельно восстановиться и сделать это за какое-то детерминированное время.

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

This entry was originally posted in my livejournal