Так!
Коллега подогнал драфтик. Не знаю, как я его прощелкал - седьмая версия драфтика все-таки, к тому же выходит в WG, список рассылки я, хоть и по остаточному принципу, но читаю. Оказывается, оно уже выдвигалось на proposed standard в 6-й версии, но решили немного доточить и на днях вышла новая, 7-я версия.
Это очень, очень хороший драфтик. Не то, что мне на самом деле нравится решение, но это шаг в очень правильном направлении. Я давно ждал чего-то на эту тему.
Дело вот в чем. Есть один очень противный сценарий отказа. Редкий, но очень плохой. Бывает так, что роутер попадает в такую позу, что пакетики к нему самому, т.е. к егойному control plane'у, идут, а вот насквозь - фигушки. И лежит такой роутер, как живой, будто и не помирал вовсе, и даже не пахнет от него - все adjacencies на месте, bgp-сессии стоят как почетный караул, но в баскетбол играть пакетики через него не пролезают. Трижды за свою жизнь такое видел и самолично траблшутил. Понятно, что всякими обычными стандартными средствами этот отказ не обнаруживается, а раз не обнаруживается, то и сеть от такого отказа не восстанавливается, пока бедную железяку из этой позы руками насильственно не выведут.
В принципе, есть решение прямое и дубовое - end-to-end monitoring, благо, LSP ping изобрели уже давно. Знай себе фигачь из конца в конец, а ежели фигачить перестало, кричи громким голосом и переходи на запасной путь, например, врубай path protection. Надо побыстрее и с меньшим оверхедом? BFD multihop в помощь. Одна беда - это не масштабируется: N^2 мониторинговых сессий - это очень тяжело, а в большой сети практически невозможно.
Так вот, драфтик, про который я начал рассказывать, обещает нам неземное счастье прямо сейчас. Он вводит довольно остроумную схему самотестирования forwarding plane. Я прямо картику из драфта передеру:
+-------+ +-------+ +-------+
| ,-|-------| |
| | | | | |
| | | <-|-------|
Сначала роутер посылает request, предназначенный для downstream'ного роутера, но посылает он его вверх, upsteam'ному роутеру. Тот этот request заворачивает, request пролетает через forwarding plane самотестирующегося роутера, долетает до downstream'а, а тот отвечает "так точно, все хорошо". Здорово, правда? Для организации этого фокуса употребляется довольно нехитрая механика, про которую желающие могут прочитать в драфте. Масштабируется это вполне разумно - количество тестов зависит от числа непосредственных соседей, а не от общего числа роутеров в сети.
Если такое самотестирование обламывается несколько раз, роутер может сказать "всем привет" и положить свои adjacencies, чтобы соседи трафик через него не слали. Очень часто тестировать такое не обязательно - отказ действительно редкий. Главное, чтобы сеть могла от такого отказа самостоятельно восстановиться и сделать это за какое-то детерминированное время.
Проблема решена? Нет, к сожалению. Кроме пути mpls2mpls, есть еще ip2mpls и mpls2ip. И их тоже по уму надо бы тестировать, но нынешнее решение этого не позволяет. Но все равно, от того, что этой проблемой, наконец, занялись, мне очень радостно.
Это очень, очень хороший драфтик. Не то, что мне на самом деле нравится решение, но это шаг в очень правильном направлении. Я давно ждал чего-то на эту тему.
Дело вот в чем. Есть один очень противный сценарий отказа. Редкий, но очень плохой. Бывает так, что роутер попадает в такую позу, что пакетики к нему самому, т.е. к егойному control plane'у, идут, а вот насквозь - фигушки. И лежит такой роутер, как живой, будто и не помирал вовсе, и даже не пахнет от него - все adjacencies на месте, bgp-сессии стоят как почетный караул, но в баскетбол играть пакетики через него не пролезают. Трижды за свою жизнь такое видел и самолично траблшутил. Понятно, что всякими обычными стандартными средствами этот отказ не обнаруживается, а раз не обнаруживается, то и сеть от такого отказа не восстанавливается, пока бедную железяку из этой позы руками насильственно не выведут.
В принципе, есть решение прямое и дубовое - end-to-end monitoring, благо, LSP ping изобрели уже давно. Знай себе фигачь из конца в конец, а ежели фигачить перестало, кричи громким голосом и переходи на запасной путь, например, врубай path protection. Надо побыстрее и с меньшим оверхедом? BFD multihop в помощь. Одна беда - это не масштабируется: N^2 мониторинговых сессий - это очень тяжело, а в большой сети практически невозможно.
Так вот, драфтик, про который я начал рассказывать, обещает нам неземное счастье прямо сейчас. Он вводит довольно остроумную схему самотестирования forwarding plane. Я прямо картику из драфта передеру:
+-------+ +-------+ +-------+
| ,-|-------| |
| | | | | |
| | | <-|-------|
Сначала роутер посылает request, предназначенный для downstream'ного роутера, но посылает он его вверх, upsteam'ному роутеру. Тот этот request заворачивает, request пролетает через forwarding plane самотестирующегося роутера, долетает до downstream'а, а тот отвечает "так точно, все хорошо". Здорово, правда? Для организации этого фокуса употребляется довольно нехитрая механика, про которую желающие могут прочитать в драфте. Масштабируется это вполне разумно - количество тестов зависит от числа непосредственных соседей, а не от общего числа роутеров в сети.
Если такое самотестирование обламывается несколько раз, роутер может сказать "всем привет" и положить свои adjacencies, чтобы соседи трафик через него не слали. Очень часто тестировать такое не обязательно - отказ действительно редкий. Главное, чтобы сеть могла от такого отказа самостоятельно восстановиться и сделать это за какое-то детерминированное время.
Проблема решена? Нет, к сожалению. Кроме пути mpls2mpls, есть еще ip2mpls и mpls2ip. И их тоже по уму надо бы тестировать, но нынешнее решение этого не позволяет. Но все равно, от того, что этой проблемой, наконец, занялись, мне очень радостно.