NSF/SSO
Какая, казалось бы, хорошая идея, сделать так, чтобы крэш роутера не прерывал трафик, идущий через него. Достоинств куча: упрощается сеть - не надо ставить вторую коробку; можно обойтись одним только link protection и забить на node protecion, если с питанием все хорошо; можно сэкономить немножко денег - опять же за счет дублирующей коробки, за счет rack space, за счет операционных расходов на конфигурацию и мониторинг второй коробки; можно улучшить доступность для single-homed подключений. В общем, это должно быть круто.
Собственно, этому ничего не мешает - у современного роутера control plane и forwarding plane раздельны. Поэтому, если control plane упал по софтверной ошибке или по отказу процессорного модуля, forwarding plane вполне может продолжать бег, как та курица с отрубленной головой. А тем временем запасной процессорный модуль, обнаружив такое безобразие, переговорит с соседними роутерами, восстановит состояние протоколов, возьмет контроль над безголовым forwarding plane и все продолжится в нормальном режиме. Такая конструкция называется NSF/SSO (Non-Stop Forwarding/Stateful Switchover) и graceful restart.
Все ли хорошо в этой схеме? Нет.
Весь этот NSF/SSO основан на трех предположениях:
Неужто нам никогда не будет счастья? Может быть и будет. Следующий кандидат - NSR, Non-Stop Routing. Идея в том, что оба RP, и активный, и запасной, всегда несут полное состояние. И при отказе одного, второй тут же подхватывает управление. Т.е. ситуации "курица, бегущая без головы" не возникает. Не рвутся и не восстанавливаются протокольные adjacency; запасной RP, став активным, может сразу проверить целостность FIB, а то и тупо-линейно сформировать его заново; не надо детектировать раздельные отказы - ящик либо сдох, либо жив во всех своих частях (наверное жив, тут тоже могут быть нюансы), не надо надеяться на безглючность реализации graceful restart соседом. Реализации NSR в природе существуют. Я, правда, еще их подробно не испытывал. Наверное, испытав, опять буду ругаться. Но есть хотя бы надежда.
А что делать сегодня? Ставить две коробки. Да, деньги. Да, rack space. Да, сложность сети. Но если действительно нужна отказоустойчивость, то другого выхода нет. Ну а можно сыграть в оптимиста и забить на недостатки NSF, только надо четко понимать, где здесь выигрыш, а где проигрыш.
Собственно, этому ничего не мешает - у современного роутера control plane и forwarding plane раздельны. Поэтому, если control plane упал по софтверной ошибке или по отказу процессорного модуля, forwarding plane вполне может продолжать бег, как та курица с отрубленной головой. А тем временем запасной процессорный модуль, обнаружив такое безобразие, переговорит с соседними роутерами, восстановит состояние протоколов, возьмет контроль над безголовым forwarding plane и все продолжится в нормальном режиме. Такая конструкция называется NSF/SSO (Non-Stop Forwarding/Stateful Switchover) и graceful restart.
Все ли хорошо в этой схеме? Нет.
Весь этот NSF/SSO основан на трех предположениях:
- При падении процессорного модуля forwarding plane остался в целости и сохранности.
- Соседи падающего роутера могут достоверно понять, что с ним случилось: отказал control plane, forwarding plane или весь ящик целиком?
- В процессе восстановления состояния протоколов по информации от соседей не произойдет временного разрушения forwarding.
- Целостность FIB. Если был железный отказ RP, кто сказал, что этот отказ произошел не во время FIB update? Если нам не повезло, и отказ случился именно в такой неудобный момент, то FIB может оказаться в неконсистентном состоянии. Масштаб этой неконсистентности зависит от организации FIB. Может быть, кривым останется один маршрут - это более вероятно при табличной организации FIB на основе TCAM, а может, от всего FIB'а остались одни ошметки - такое совсем не исключено, если для FIB используется какая-нибудь сложная структура данных.
Т.е. для надежной работы NSF необходимы транзакционные FIB updates. В принципе, это сделать можно, но довольно сложно. FIB оптимизируется в первую очередь под задачу быстрого lookup - это самое главное, во-вторых под компактность в случае non-TCAM-based FIB - быстрая память, в которой приходится держать FIB, дорога, в-третьих под быстрые updates - это тоже немаловажно. Требование транзакционности неизбежно вступит в противоречие с этими тремя целями.
Можно обеспечить более слабую версию транзакционности FIB update. Если на линейной карте есть свой управляющий процессор (а он таки есть), то можно проводить транзакцию FIB update с ним, а не непосредственно с FIB, а тот уже сам разберется. Т.е. получится гарантия целостности FIB относительно отказа RP, но не относительно отказа CPU линейной карты. Этого, в принципе, достаточно.
Если же это падение по софтверной ошибке, то тут all bets are off. Если дело дошло до какого-нибудь SIGSEGV в монолитном IOS'е, то кто в здравом рассудке поручится, что перед этим падающий RP не превратил FIB в кровавое месиво? Тут надо падать с грохотом, с погашением лазеров и загружаться из cold state. Да, перерыв будет долгим, но зато конечным. Товарищи вендоры, не допускайте падения своих продуктов по такой симптоматике! А ежели такое, недайбоже, случилось, плюйте на всякий NSF и уходите на жесткий ребут всей коробки целиком. - Отличение соседями сбоев forwarding plane от сбоев control plane. Вся логика работы NSF основана на том, что соседи падающего роутера знают заранее: не надо пугаться, если с соседом что случилось, он еще может воспрянуть к жизни, а пока можно слать ему трафик. Однако оптимальная реакция соседа на отказ роутера, конечно же, зависит от вида отказа. Например, если с той стороны в линк не светят, то нет никакого смысла слать туда пакеты, надо быстренько перекинуть трафик в другом направлении.
В общем случае логика должны быть такова: если у соседа отказал control plane, то ничего не предпринимаем, а когда тот начнет восстанавливать состояние, поможем, а если оказал forwarding plane, то разворачиваем трафик в другую сторону как можно быстрее. Другой способ действий чреват очень медленным восстановлением от сбоя. Проблема в том, что отличить отказ control plane от отказа forwarding plane бывает трудно.
Для детектирования отказа control plane существуют протокольные hello/keepalives. Они должны быть достаточно медленными в случае NSF - надо, чтобы восстанавливающийся роутер успел начать восстановление до развала adjacencies. Масштаб - секунды, десятки секунд. Это, очевидно, неприемлемо для случаев отказа forwarding элементов, ибо в этом случае надо действовать быстро.
Есть замечательное изобретение - протокол BFD, которое по идее должно обеспечить нам именно обнаружение сбоев в forwarding plane, причем обнаружение достаточно быстрое. Спасает ли наc BFD?
Для того, чтобы BFD мог детектировать сбои forwarding plane, он должен работать исключительно на этом самом forwarding plane независимо от control plane. Ок, я не буду произносить все те слова, которые у меня накопились в адрес бывшего энтерпрайзного свитча, которые злые и циничные люди попытались превратить в сервис-провайдеский роутер. Все и так всё знают и понимают. Настоящие же роутеры могут исполнить BFD прямо с линейной карты. Это хорошо, но не покрывает все нужные случаи. Речь о наложенных топологиях, которые не совпадают с физическими. Пусть у нас есть протокольное соседство по pseudowire. Этот PW может выходить из нашей коробки сейчас через интерфейс на одном модуле, а через секунду через интерфейс на другом. Или, что еще хуже, входить через один, в выходить через другой. Где именно должен исполняться BFD, контролирующий adjacency через этот PW? Или вот взять multihop BFD для контроля далекого iBGP'шного next-hop - та же самая ситуация.
Таким образом, общего решения задачи отличения сбоев forwarding plane от сбоев control plane не существует. - Непрекращение forwarding'а в процессе самого восстановления. Нас ведь интересует не просто восстановление чего-то там в сети. Нас интересует восстановление сервиса, за который клиент платит деньги. Возьмем, к примеру, какой-нибудь простецкий VPLS с autodiscovery. Что должно восстановиться, чтобы он продолжил функционировать? IS-IS (ну или OSPF), как IGP, раз. RSVP, как протокол сигнализации TE-туннелей, два. BGP, как средство autodiscovery, три. Targeted LDP, как средство сигнализации наших псевдопроводов, четыре. Совсем не мало.
Вся эта банда протоколов рестартует [почти] независимо, сходится в произвольном порядке, апдейтит forwarding'овые таблицы кто во что горазд, взаимодействует друг с другом - например малейшая неаккуратность в восстановлении BGP'шных VPLS autodiscovery префиксов совершенно очевидным образом разрушит LDP-сигнализацию pseudowires, которым повезло выжить при отказе активного RP. Вся эта конструкция процессе сходимости может находиться в самых интересных промежуточных состояниях и целостность forwarding'а в этих промежуточных состояниях ой как не гарантируется. Известно лишь одно: рано или поздно оно сойдется и все станет хорошо, но, для того, чтобы NSF был действительно Non-Stop, этой гарантии "рано или поздно" мало.
Роутер, стартующий из холодного состояния, тоже подвержен подобным проблемам, но для более или менее удовлетворительного решения этих проблем есть всякие механизмы типа LDP-IGP synch, overload bit при старте и т.д., суть которых сводится к заявлению "я еще не готов к работе, не надо слать через меня трафик". Очевидно, что это не годится для случая NSF.
Изменение такого положения вещей потребует, пожалуй, полной переработки механики работы протоколов с тем, чтобы они больше знали о внутреннем состоянии друг-друга и избегали странных промежуточных поз. Очень большая работа. И я совсем не уверен в том, что это вообще возможно.
Неужто нам никогда не будет счастья? Может быть и будет. Следующий кандидат - NSR, Non-Stop Routing. Идея в том, что оба RP, и активный, и запасной, всегда несут полное состояние. И при отказе одного, второй тут же подхватывает управление. Т.е. ситуации "курица, бегущая без головы" не возникает. Не рвутся и не восстанавливаются протокольные adjacency; запасной RP, став активным, может сразу проверить целостность FIB, а то и тупо-линейно сформировать его заново; не надо детектировать раздельные отказы - ящик либо сдох, либо жив во всех своих частях (наверное жив, тут тоже могут быть нюансы), не надо надеяться на безглючность реализации graceful restart соседом. Реализации NSR в природе существуют. Я, правда, еще их подробно не испытывал. Наверное, испытав, опять буду ругаться. Но есть хотя бы надежда.
А что делать сегодня? Ставить две коробки. Да, деньги. Да, rack space. Да, сложность сети. Но если действительно нужна отказоустойчивость, то другого выхода нет. Ну а можно сыграть в оптимиста и забить на недостатки NSF, только надо четко понимать, где здесь выигрыш, а где проигрыш.
0 TrackBacks
Listed below are links to blogs that reference this entry: NSF/SSO.
TrackBack URL for this entry: http://net-geek.org/cgi-bin/mt/mt-tb.cgi/258
Не-е-е-е.
Ну, начнем-с с того, что первый пункт фактически высосн из пальца. И так ведь понятно, что по сути НСФ/ССО призван спасти обывателя от хардовой смерти RP, которая сдохла, никого не прихватив с собой. Падение по сфотварной ошибке тут вообще не рассматривается, только лишь частные случаи, которые могут привести к успеху. Софт - штука хитрая. Дураку понятно что софтовая ошибка может ваще заключаться в том, что RP, например, начнет анонсить сети которых ваще нет на данном боксе. Возьмет и заанонсит, что 10.0.0.0/32 - это ее лупбак, а на саом деле - это лупбак какого нить Пэшного роутера. Коненчо, всему настанет писдец, и абсолютно похуй как мы страховались, NSF-ом или ставили 2 бокса, 3 бокса или 100 боксов для реданданси. Не, от софтового глюкалова нет пока спасения. А матмодель транзакционных апдейтов я, помнится, еще в махровые годы проходил.
Детектирование отказа, контрол или форвард плэйн... В принципе согласен, рискуем проебать траффик, если на самом деле отказал и форвардинг. Но, ты сам сказал про BFD. С наложенными технологиями что-то мысль не всосал. Особенно невсосал чем нам поможет 2 бокса. Если можно, то поподробней с примерчиком. :-)
Ну и тертий пункт... Вроде известные вендоры давно придумали механизмы всяческих задержек, которые позволяют как раз для подобных случаев не горячиться и подождать пока контрол-плэйн полностью востановится. Или я не прав? Чем это не годится для NSF? Все соседи в курсе NSF'а, они тоже горечиться не собираются. По-моему, никаких проблем. Вопрос же промежуточных состояний и их стабильности, как ты правильно заметил, должен базироваться на знании протоколов друг о друге, или на неком интерфейсе между ними. Мне давно еще попадался какой-то буржуйский грант, где хитровыебаные сети Петри юзались чепеастными ребятами именно в разрезе "роутинговых" протоколов, в кавычках потому что там и LDP может быть всякий и т.п. сигнализации. Букоф было очень много, я не понял почти нихуя, кроме главного, а главным мне показалось то, что инженер обслуживающий подобную систему, где протоколы существуют не сами по себе, а неким образом координируют свою работу, должен быть в курсе всех механизмов синхронизации и взаимодействия и прилагать мозговые усилия для настройки подобных систем. Но это проблема более общая, нежели чисто для NSF характерная.
В общем-то свой вывод сделаю: да, две коробки лучше чем два RP, но с точки зрения оправдывания средств - как-то слабова-то, а точнее никак.
Спасибо за развернутй комментарий.
По первому пункту.
> И так ведь понятно, что по сути НСФ/ССО призван спасти обывателя от хардовой смерти RP, которая сдохла, никого не прихватив с собой.
Да, конечно. Но само по себе предположение, что RP за собой никого не потянул - это оптимизм. Оптимизм зачастую неоправданный. Закладываться ли на такие варианты развития событий или нет - вопрос отдельный. Как я сказал, это может случиться как при софтверной ошибке, так и при "хардверном" отказе.
> А матмодель транзакционных апдейтов я, помнится, еще в махровые годы проходил.
Именно по отношению к FIB'ам в роутерах? Если такие вещи и делались, то что-то сомнительно, что это до сих пор применимо. С тех махровых лет структура FIB'ов сильно изменилась - очень много за последние годы было сделано новых алгоритмов и они в полный рост применяются. Нет, конечно, есть способ абсолютно простой и надежный - страничная организация: делаем две страницы FIB'а, на одной работаем, вторую заполнем, а потом атомарно перещелкиваем. Работать будет, но дорого обойдется.
> С наложенными технологиями что-то мысль не всосал.
Попробую подробней.
Вот, есть у нас что-то вроде такого.
На R1:
int lo0
ip addr 10.0.0.1 255.255.255.255
...
int vlan 666
ip addr 192.168.0.1 255.255.255.254
xconnect 10.0.0.2 666 encap mpls
router ospf 1
...
network 192.168.0.1 0.0.0.0 area 15
...
На R2 симметрично.
Т.е. у нас есть ospf adjacency через PW, а не через физический линк. Между R1 и R2 может быть несколько путей. Пусть для конкретики будет через Ten1/0/0 и Ten2/0/0, лучший путь через 1/0/0. Запустим BFD для контроля этого adjacency. Где этот BFD должен исполняться? На модуле 1? Так этот лучший путь изменится в любой момент, что должно произойти с BFD при этом? Перетащить его прозрачно и очень быстро на модуль 2? Или потерять и восстановить adjacency через PW? А если трафик от R1 на R2 течет через Ten1/0/0, а от R2 в R1 втекает через Ten2/0/0? Такое легко может быть. Тогда вообще распределенный BFD невозможен.
> Особенно невсосал чем нам поможет 2 бокса.
Есть два бокса - есть два пути. Как только мы обнаружили, что с соседом хоть что-то не так, сразу же уходим на второй путь. И нам по барабану, что у соседа стряслось: хоть триппер, хоть сифилис. Вот вылечится, тогда и будем гнать через него трафик. Нам не надо раздельно диагностировать forwarding и control. Тут детали реализации BFD имеют значение только для масштабируемости - когда можем, выполняем распределенно, когда не можем, централизованно.
> Вроде известные вендоры давно придумали механизмы всяческих задержек, которые позволяют как раз для подобных случаев не горячиться и подождать пока контрол-плэйн полностью востановится. Или я не прав? Чем это не годится для NSF?
Ну, вот возьмем к примеру set-overload-bit on-startup. Что он делает? Он всем говорит "через меня трафик не слать, я пока не прочухался, могу фигню спороть". Цель-то NSF как раз в обратном - трафик слать, хотя сосед еще не в себе.
Или речь о том, что сначала подождать сходимость IGP, скажем минуту, потом BGP, потом еще что-нибудь? Может быть и сработает в простых случаях. Но вернемся к примеру с наложенной топологией. Кто кого должен ждать: LDP OSPF или наоборот?
> Мне давно еще попадался какой-то буржуйский грант, где хитровыебаные сети Петри юзались чепеастными ребятами именно в разрезе "роутинговых" протоколов, в кавычках потому что там и LDP может быть всякий и т.п. сигнализации.
Если вдруг вспомнишь, где и что ты по этому видел, не сочти за труд, дай мне знать.
> но с точки зрения оправдывания средств - как-то слабова-то, а точнее никак.
Если чисто по железу, то добавляется только шасси, которое стоит денег совсем небольших по сравнению со всеми остальными потрохами. Ну, может быть модулей в некоторых (далеко не во всех) случаях. Но все равно это не в два раза дороже. Кто-то публиковал не так давно раскладку для их сети. Рассматривались два варианта: две нередундантных коробки vs. одна редундантная. Разница получилась процентов 25. Другое дело, rack space - это реально может быть проблемой.
>>Но само по себе предположение, что RP за собой никого не потянул - это оптимизм
Это понятно. я имею в виду, что в случае софтварной ошибки нам резервирование бокса сильно не поможет.
>>Именно по отношению к FIB'ам в роутерах?
Боже упаси, я тогда слово FIB не знал, тогда только было громкое слово АСУ.
>> Т.е. у нас есть ospf adjacency через PW, а не через физический линк.
И мы сейчас рассматриваем подыхалово RP на боксе которая далеко и доступна через PW, или подыхалово RP на соседнем боксе?
Ну, допустим на удаленом боксе. NSF нам говорит, что если я, удаленный бокс, умолк, ты не ссы, я просто переключаю RP'ы; ты все равно продолжай слать в PW траффик. Но мы не дураки, и думаем, ХЗ этот удаленный бокс, мертв он совсем и не может траффик форвордить или RP переключает. Как узнать? Просто! Натравливаем BFD на PW. Почему мы должны это делать на физических интерфейсах? Если PW жив, и нам об этом говорит BFD, то продолжаем форвордить и ждать пробуждения RP, если PW мертв и нам это сказало BFD, то переключаемся на резервное PW. Всякие там pwe3-vccv-bfd заспамили "pwe3 Digest" уже насмерть.
Ну, теперь, допустим, подыхалово на соседнем боксе. Соседний бокс имеет 2 линейных модуля, и 2 RP. Каждая PW идет через разные линейные модули. Что это меняет? Так же BFD натравливаем на PW. Как тлько forwarding plane загнется, так сразу переключим PW.
Если вопрос стоит в разрезе таком, что внутри PW BFD нету, и что надо средствами BFD на физических интерфейсах определить класть PW или не класть, то да, согласин, не канает.
По поводу сходимости после переключения... Как мне видется, и я могу ошибаться, во время NSF'а что делают соседние живые роутеры?
1. Не разрывают аджасенси. Зачем? Ну, типа RP захуевело, но ща полегчает, вот тогда и заработаем, щас же просто форвордим и не меняем таблицы.
2. Отправляет на ожившую RP все что есть у него в мозгах, то есть как RP ожил, устанавливаются все эджасенси, то есть востанавливаются, и все маршруты, например, отсылаются на ожившую RP.
3. Вот по этому пункту не уверен, поправьте если что не так. Получив информацию, например, LSA от ожившей RP, выдерживается ли пауза? По-моему, ДА. Потому что понятно, что ожившая RP могла не успеть получить все что было у ее родителя, и потом чего-нить еще дошлет.
4. В результате, если за полное время переключения (1-2 секунды) топология в сети касаемо NSF aware протоколов ни как не поменялась, то все встанет так как и было до аварии. И сетит оверлоад биты никакие не придется ни кому.
Хуево становиться, если, скажем, за время переключения между стэндбайной и активной RP случились какие-то изменения в сети. Тогда тупо всем соседям ждать когда все станет так же как и было до аварии нельзя (потому что все уже не так). Подождала секундочки 3, глядь, нихуя ситуация не сходится с той, что было до аварии, все, пора заново колбасить всякие протоколы.
В итоге надо весьма просто оценить статистически вероятность такого несчастия. Как часто RP выходит из строя? Как часто происходят изменения в NSF aware протоколах в сети и как они проходят. Получаем событие с вероятностью x1 временем y1 и событие с вероятностью x2 временем y2. Вспоминаем 10 класс сунца и считаем вероятность наступления обоих событий в конечном времени, или распределение высчитываем. Мне сложно такие вещи оценить, но, если честно, думаю, что пожалуй ты прав, вывод будет такой, что NSF с ненулевой вероятностью окажется нихуя не "нонстоп". :-)
>>Именно по отношению к FIB'ам в роутерах?
> Боже упаси, я тогда слово FIB не знал, тогда только было громкое слово АСУ.
Ну, проапдейтить некоторую специально приспособленную структуру данных, сохраняя ее целостность в любой точке времени, не фокус.
> И мы сейчас рассматриваем подыхалово RP на боксе которая далеко и доступна через PW
Пусть подыхает R1 из моего примера. R2 его лупит BFD в надежде определить, сдох он целиком или пока трафик через него можно слать.
Если на R1 BFD исполняется распределенно, то R2 может отличить кончину forwarding plane на R1 от кончины control plane. В первом случае обнаружение произойдет быстро и R2 перероутит трафик на запасной путь, во-втором кончина RP не затронет BFD и будет graceful-restart. Все отлично.
Если же BFD исполняется на R1 централизованно (читай на RP), то R2 нет никаких шансов определить, что там на самом деле случилось. Поэтому в этом случае выбор небольшой: либо всегда рероутиться, т.е. не использовать NSF, либо заниматься оптимизмом и всегда полагаться на NSF, что чревато длительной потерей трафика в случае отказа forwarding'а.
> Каждая PW идет через разные линейные модули.
Одна PW может идти через разные модули. Через один входить, через другой выходить. Поэтому исполнять BFD на PW распределенно нельзя. Что из этого получается см. выше. Конечно, в случае с PW есть шанс, что физические соседи R1 правильно отдетектируют отказ forwarding'а на R1 и сигнализируют об этом по сети либо по IGP, либо порвут LSP PathErr'ом. Тогда R2 поймет, что случилось, положит PW и все пройдет нормально. Но это долго и хуже того, недетерминистично.
> Если вопрос стоит в разрезе таком, что внутри PW BFD нету
Дело не в том, что нету. На PW (и вообще на наложенной топологии, не совпадающей с физической) он бесполезен для различения разных сценариев отказа.
> 2. Отправляет на ожившую RP все что есть у него в мозгах, то есть как RP ожил, устанавливаются все эджасенси, то есть востанавливаются, и все маршруты, например, отсылаются на ожившую RP.
Угу. Оживший RP глуп, и получая информацию от соседей начинает апдейтить свои форвардинговые таблицы. В процессе этого он еще не обладает полной информацией и есть ненулевые шансы, что наапдейтит он полной херни. Хуже того, он начинает решать по неполной сигнальной информации, что ему говорить соседям - те-то его тоже слушают. И опять же он может наговорить им херни. Сам наблюдал. Конечно, то, что я наблюдал, было багой, и я ее обязательно буду репортить, ибо это можно пофиксить, но в целом проблема более глубокая, чем отдельные баги.
Проблему можно было бы решить так: сначала полностью восстановить всю информацию, а только после этого браться за FIB и все остальное. К сожалению, так сделать нельзя. Поскольку сигнализация в IP-сетях in-band, то она зависит от правильного форвардинга на нашем data plane. Простой пример: для iBGP или T-LDP необходимы правильные маршруты IS-IS, причем правильные на настоящий момент времени, а не когда-то в прошлом. Поэтому, вся эта конструкция была и остается довольно шаткой.
> Хуево становиться, если, скажем, за время переключения между стэндбайной и активной RP случились какие-то изменения в сети.
Да. Но не только. Ноги у этой проблемы растут из того, что трафик прет через оживающий роутер, на котором информация еще неполна, а он уже чего-то там в своих таблицах шурует, да еще и соседям всякую фигню рассказывает.
> Вспоминаем 10 класс сунца
Кругом наши люди.
>>Да. Но не только. Ноги у этой проблемы растут из того, что трафик прет через оживающий роутер, на котором информация еще неполна, а он уже чего-то там в своих таблицах шурует, да еще и соседям всякую фигню рассказывает.
А разве для того, чтоб этого избежать не выдерживаются всякие таймеры? С другой стороны, если они и есть, то какие? Как бы это можно было определить RP'у, ждать сколько... Что-то я начал осозновать что в NSF я мало чего знаю... :)
Не-е-е-е.
Ну, начнем-с с того, что первый пункт фактически высосн из пальца. И так ведь понятно, что по сути НСФ/ССО призван спасти обывателя от хардовой смерти RP, которая сдохла, никого не прихватив с собой. Падение по сфотварной ошибке тут вообще не рассматривается, только лишь частные случаи, которые могут привести к успеху. Софт - штука хитрая. Дураку понятно что софтовая ошибка может ваще заключаться в том, что RP, например, начнет анонсить сети которых ваще нет на данном боксе. Возьмет и заанонсит, что 10.0.0.0/32 - это ее лупбак, а на саом деле - это лупбак какого нить Пэшного роутера. Коненчо, всему настанет писдец, и абсолютно похуй как мы страховались, NSF-ом или ставили 2 бокса, 3 бокса или 100 боксов для реданданси. Не, от софтового глюкалова нет пока спасения. А матмодель транзакционных апдейтов я, помнится, еще в махровые годы проходил.
Детектирование отказа, контрол или форвард плэйн... В принципе согласен, рискуем проебать траффик, если на самом деле отказал и форвардинг. Но, ты сам сказал про BFD. С наложенными технологиями что-то мысль не всосал. Особенно невсосал чем нам поможет 2 бокса. Если можно, то поподробней с примерчиком. :-)
Ну и тертий пункт... Вроде известные вендоры давно придумали механизмы всяческих задержек, которые позволяют как раз для подобных случаев не горячиться и подождать пока контрол-плэйн полностью востановится. Или я не прав? Чем это не годится для NSF? Все соседи в курсе NSF'а, они тоже горечиться не собираются. По-моему, никаких проблем. Вопрос же промежуточных состояний и их стабильности, как ты правильно заметил, должен базироваться на знании протоколов друг о друге, или на неком интерфейсе между ними. Мне давно еще попадался какой-то буржуйский грант, где хитровыебаные сети Петри юзались чепеастными ребятами именно в разрезе "роутинговых" протоколов, в кавычках потому что там и LDP может быть всякий и т.п. сигнализации. Букоф было очень много, я не понял почти нихуя, кроме главного, а главным мне показалось то, что инженер обслуживающий подобную систему, где протоколы существуют не сами по себе, а неким образом координируют свою работу, должен быть в курсе всех механизмов синхронизации и взаимодействия и прилагать мозговые усилия для настройки подобных систем. Но это проблема более общая, нежели чисто для NSF характерная.
В общем-то свой вывод сделаю: да, две коробки лучше чем два RP, но с точки зрения оправдывания средств - как-то слабова-то, а точнее никак.
Ребят, если не затруднит, поясните, пожалуйста, а что мешает синхронизировать и control plane между двумя процессорными модулями? Коллеги из Cisco всегда рассказывают, что это трудно и накладно, однако в чем состоит (да и есть ли вообще) такая уж принципиальная сложность я как не понимал так и не понимаю.
Жалуются, но делают. В IOS XR 3.6 NSR есть для BGP, LDP и OSFP, кажется. Наверняка будут делать и для других протоколов. Т.о. есть подозрение, что жалобы связаны именно с архитектурой IOS, а не с принципиальной невозможностью синхронизировать состояние.
Повторюсь, я не испытывал, насколько хорошо там NSR реализован. Но факт остается фактом - даже Cisco, которая всегда агитировала за graceful restart, движется в сторону NSR.
Что же касается обоснования позиции "graceful restart рулит", то она изложена в цископрессовской книжке "Fault-Tolerant IP and MPLS Networks", глава Design Strategies for Network Survivability. Признаюсь, эти аргументы никогда не казались мне очень убедительными.
Почитал на выходных, действительно аргументация у них несколько притянутая. Буду ждать, когда NSR заведут и на всех остальных платформах.
Спасибо за интересную статью и комментарии.
По пункту один.
Для апдейта FIB юзается IPC который более менее быстрый и умный для контроля целостности передаваемой информации. Кроме того запись в FIB не делается по аналогии с "записью в файл" и процесс контролируется FIB Manager'ом на LC. Даже если отвалитсо RP и в процессе полета попытается писать в FIB матюки, я очень сомневаюсь, что упомянутый выше манагер примет к рассмотрению наполовину принятые инструкции.
Следующие два пункта пока не осилил :) Отпишу как собирусь с мыслями.
Угу, я в курсе про IPC. Может быть, это спасает, а может быть и нет.
Если я правильно припоминаю структуру FIB, скажем, в цисковских роутерах, то там есть TCAM entry, который может показывать прямо на adjacency со всяким там rewrite info или может показывать на loadinfo. Насколько я понимаю, апдейт одного entry может проводить к нескольким командам IPC для манипуляции каждой из этих сущностей. Каков будет эффект, если процесс прервать посередине, я точно не знаю, но предполагаю, что ничего хорошего из этого не выйдет. Если я неправ и ничего страшного не будет, то это хорошо - буду спать спокойней :)