On Thu, May 31, 2007 at 10:50:27AM +0400, Daniel Ginsburg wrote: [..skipped..]
И что при 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.
Это есть на не-7600 только для BGP?
Если нет - я бы хотел посмотреть как за 100ms можно вдуть restarting router-у всю таблицу.
Не, ты не понимаешь. Когда один супервизор помирает, подхватывает второй с готовым forwarding plane состоянием, но без правильного control plane состояния. И продолжает форвардить трафик. На этот подхват ему требуется 800-900ms или 100ms на новых шасси. Тем временем он устанавливает adjacency заново, соседи ему заливают всякий ISIS, BGP, LDP и прочие радости жизни, которые он должен знать. Т.е. полное восстановление происходит не за 100ms, а значительно дольше. За 100ms восстанавливается форвардинг по возможно протухшим таблицам.
:-)
Книжка есть, "Fault-Tolerant IP and MPLS Networks" называется. Она практически вся как раз про это несчастье.
Если интерестны подробности двухнедельного теста GR/GRES на JunOS 8.2 обращайтесь приватом.
И из той же оперы - а что будет если скажем IGP у нас ISIS и как раз во время restart-а случился topology change?
Ну что, он на этот topology change не прореагирует. Пока. Когда adjacency восстановятся, тогда он пересчитает SPF и трафик поедет как надо. Собственно, по этой и нескольким другим причинам весь этот SSO/NSF - штука весьма сомнительная.
Вот это вот "пока пересчитает" в зависимости от топологии, протоколов и прочего может быть 30sec и более. Если сильно неповезет все это время можно получить blackhole/routing loop. В нормальной сети вероятность поймать такую ситуацию (topology change + graceful restart) невелика, но она есть.
Вообще, у нас опыт с SSO/NSF на 7600 довольно паршивый. Я твердо убежден, что два ящика с нерезервированными супервизороми строго лучше одного ящика с двумя супервизорами. Но есть случаи когда да, два ящика нельзя.
Мне нравится, как это сделано у алкателя. Вот у них оба SF/CPM работают с полной синхронизацией состояния. И для failover'а им не надо никаких глупостей типа graceful restart.
А какая максимальная емкость по 10G портам у Alcatel-я который это умеет?
Сам пока не проверял, но у меня тут валяется отчетец о тестировании 7450, которое делал BT Exact. У них получилось 0.94us (это не опечатка: us, а не ms) на software induced switchover, т.е. по команде "admin redundancy force-switchover now". И 12.2ms на hardware induced switchover, т.е. по выдергиванию активного SF/CPM из шасси. По-моему, это отличный результат.
Можно на него глянуть?
-- dg
-- Regards, Volodymyr. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message