On 31.05.2007 4:36 Volodymyr Yakovenko wrote:
Говорят, около 100ms. Что-то там в старых шасси у них не срасталось с быстрой синхронизацией фабрики.
Говорят или ктото реально в lab-е тестировал?
Циска говорит. Ко мне S шасси только приедут. Тогда и я поиграюсь. Про 800-900ms на не-S тестировал сам.
И что при failover-е происходит с внутренним состоянияем ISIS/RSVP/BGP процессов?
Как что? Graceful restart, будь он неладен. При этом состояние forwarding plane типа сохраняется, но ящик все равно замирает на некоторое время - примерно на 100ms с -S шасси и примерно на 800-900ms с обычными.
Мнее, так внутрення репликация структур данных между, например, BGP процессами есть или нет?
Нет. Control plane состояние на супервизорах разное. Одинаковое forwarding plane состояние. Ну и на DFC forwarding plane состояние тоже типа выживает. В принципе, именно для BGP есть так называемый nonstop routing (не путать с nonstop forwarding). Там да, полное состояние BGP сохраняется, включая состояние TCP-сессий. Но это не на 7600.
Если нет - я бы хотел посмотреть как за 100ms можно вдуть restarting router-у всю таблицу.
Не, ты не понимаешь. Когда один супервизор помирает, подхватывает второй с готовым forwarding plane состоянием, но без правильного control plane состояния. И продолжает форвардить трафик. На этот подхват ему требуется 800-900ms или 100ms на новых шасси. Тем временем он устанавливает adjacency заново, соседи ему заливают всякий ISIS, BGP, LDP и прочие радости жизни, которые он должен знать. Т.е. полное восстановление происходит не за 100ms, а значительно дольше. За 100ms восстанавливается форвардинг по возможно протухшим таблицам. Книжка есть, "Fault-Tolerant IP and MPLS Networks" называется. Она практически вся как раз про это несчастье.
И из той же оперы - а что будет если скажем IGP у нас ISIS и как раз во время restart-а случился topology change?
Ну что, он на этот topology change не прореагирует. Пока. Когда adjacency восстановятся, тогда он пересчитает SPF и трафик поедет как надо. Собственно, по этой и нескольким другим причинам весь этот SSO/NSF - штука весьма сомнительная. Вообще, у нас опыт с SSO/NSF на 7600 довольно паршивый. Я твердо убежден, что два ящика с нерезервированными супервизороми строго лучше одного ящика с двумя супервизорами. Но есть случаи когда да, два ящика нельзя. Мне нравится, как это сделано у алкателя. Вот у них оба SF/CPM работают с полной синхронизацией состояния. И для failover'а им не надо никаких глупостей типа graceful restart. Сам пока не проверял, но у меня тут валяется отчетец о тестировании 7450, которое делал BT Exact. У них получилось 0.94us (это не опечатка: us, а не ms) на software induced switchover, т.е. по команде "admin redundancy force-switchover now". И 12.2ms на hardware induced switchover, т.е. по выдергиванию активного SF/CPM из шасси. По-моему, это отличный результат. -- dg =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message