Daniel Ginsburg ([info]dbg) wrote,
@ 2008-02-21 10:26:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
NSF/SSO
Какая, казалось бы, хорошая идея, сделать так, чтобы крэш роутера не прерывал трафик, идущий через него. Достоинств куча: упрощается сеть - не надо ставить вторую коробку; можно обойтись одним только link protection и забить на node protecion, если с питанием все хорошо; можно сэкономить немножко денег - опять же за счет дублирующей коробки, за счет rack space, за счет операционных расходов на конфигурацию и мониторинг второй коробки; можно улучшить доступность для single-homed подключений. В общем, это должно быть круто. Continue Reading »

(Post a new comment)

На нетгике че-то все мрачно глючит и не каментится
[info]sv_doctor
2008-02-21 09:13 am UTC (link)
Не-е-е-е.

Ну, начнем-с с того, что первый пункт фактически высосн из пальца. И так ведь понятно, что по сути НСФ/ССО призван спасти обывателя от хардовой смерти RP, которая сдохла, никого не прихватив с собой. Падение по сфотварной ошибке тут вообще не рассматривается, только лишь частные случаи, которые могут привести к успеху. Софт - штука хитрая. Дураку понятно что софтовая ошибка может ваще заключаться в том, что RP, например, начнет анонсить сети которых ваще нет на данном боксе. Возьмет и заанонсит, что 10.0.0.0/32 - это ее лупбак, а на саом деле - это лупбак какого нить Пэшного роутера. Коненчо, всему настанет писдец, и абсолютно похуй как мы страховались, NSF-ом или ставили 2 бокса, 3 бокса или 100 боксов для реданданси. Не, от софтового глюкалова нет пока спасения. А матмодель транзакционных апдейтов я, помнится, еще в махровые годы проходил.

Детектирование отказа, контрол или форвард плэйн... В принципе согласен, рискуем проебать траффик, если на самом деле отказал и форвардинг. Но, ты сам сказал про BFD. С наложенными технологиями что-то мысль не всосал. Особенно невсосал чем нам поможет 2 бокса. Если можно, то поподробней с примерчиком. :-)

Ну и тертий пункт... Вроде известные вендоры давно придумали механизмы всяческих задержек, которые позволяют как раз для подобных случаев не горячиться и подождать пока контрол-плэйн полностью востановится. Или я не прав? Чем это не годится для NSF? Все соседи в курсе NSF'а, они тоже горечиться не собираются. По-моему, никаких проблем. Вопрос же промежуточных состояний и их стабильности, как ты правильно заметил, должен базироваться на знании протоколов друг о друге, или на неком интерфейсе между ними. Мне давно еще попадался какой-то буржуйский грант, где хитровыебаные сети Петри юзались чепеастными ребятами именно в разрезе "роутинговых" протоколов, в кавычках потому что там и LDP может быть всякий и т.п. сигнализации. Букоф было очень много, я не понял почти нихуя, кроме главного, а главным мне показалось то, что инженер обслуживающий подобную систему, где протоколы существуют не сами по себе, а неким образом координируют свою работу, должен быть в курсе всех механизмов синхронизации и взаимодействия и прилагать мозговые усилия для настройки подобных систем. Но это проблема более общая, нежели чисто для NSF характерная.

В общем-то свой вывод сделаю: да, две коробки лучше чем два RP, но с точки зрения оправдывания средств - как-то слабова-то, а точнее никак.

(Reply to this) (Thread)
Re: На нетгике че-то все мрачно глючит и не каментится
[info]dbg
2008-02-21 09:18 am UTC (link)
Все комментится, аж два раза :)

Уже пишу ответ.

(Reply to this) (Parent)(Thread)
Re: На нетгике че-то все мрачно глючит и не каментится
[info]sv_doctor
2008-02-21 09:21 am UTC (link)
Пардоне муа...
Наверное каментиться-то каментиццо, но не отображается.
:-))))
Сотри лишку там.

(Reply to this) (Parent)

[info]sv_doctor
2008-02-21 09:19 am UTC (link)
Не-е-е-е.

Ну, начнем-с с того, что первый пункт фактически высосн из пальца. И так ведь понятно, что по сути НСФ/ССО призван спасти обывателя от хардовой смерти RP, которая сдохла, никого не прихватив с собой. Падение по сфотварной ошибке тут вообще не рассматривается, только лишь частные случаи, которые могут привести к успеху. Софт - штука хитрая. Дураку понятно что софтовая ошибка может ваще заключаться в том, что RP, например, начнет анонсить сети которых ваще нет на данном боксе. Возьмет и заанонсит, что 10.0.0.0/32 - это ее лупбак, а на саом деле - это лупбак какого нить Пэшного роутера. Коненчо, всему настанет писдец, и абсолютно похуй как мы страховались, NSF-ом или ставили 2 бокса, 3 бокса или 100 боксов для реданданси. Не, от софтового глюкалова нет пока спасения. А матмодель транзакционных апдейтов я, помнится, еще в махровые годы проходил.

Детектирование отказа, контрол или форвард плэйн... В принципе согласен, рискуем проебать траффик, если на самом деле отказал и форвардинг. Но, ты сам сказал про BFD. С наложенными технологиями что-то мысль не всосал. Особенно невсосал чем нам поможет 2 бокса. Если можно, то поподробней с примерчиком. :-)

Ну и тертий пункт... Вроде известные вендоры давно придумали механизмы всяческих задержек, которые позволяют как раз для подобных случаев не горячиться и подождать пока контрол-плэйн полностью востановится. Или я не прав? Чем это не годится для NSF? Все соседи в курсе NSF'а, они тоже горечиться не собираются. По-моему, никаких проблем. Вопрос же промежуточных состояний и их стабильности, как ты правильно заметил, должен базироваться на знании протоколов друг о друге, или на неком интерфейсе между ними. Мне давно еще попадался какой-то буржуйский грант, где хитровыебаные сети Петри юзались чепеастными ребятами именно в разрезе "роутинговых" протоколов, в кавычках потому что там и LDP может быть всякий и т.п. сигнализации. Букоф было очень много, я не понял почти нихуя, кроме главного, а главным мне показалось то, что инженер обслуживающий подобную систему, где протоколы существуют не сами по себе, а неким образом координируют свою работу, должен быть в курсе всех механизмов синхронизации и взаимодействия и прилагать мозговые усилия для настройки подобных систем. Но это проблема более общая, нежели чисто для NSF характерная.

В общем-то свой вывод сделаю: да, две коробки лучше чем два RP, но с точки зрения оправдывания средств - как-то слабова-то, а точнее никак.

(Reply to this)


[info]nealar
2008-02-21 03:35 pm UTC (link)
Понра.
Доктор, а что вы скажете за DHT?

(Reply to this) (Thread)

[info]dbg
2008-02-21 04:17 pm UTC (link)
Distributed Hash Tables? Ничего умного не скажу. Я читал пару статей, идея понравилась, но тут я, натурально, не эксперт.

(Reply to this) (Parent)(Thread)

[info]nealar
2008-02-21 09:56 pm UTC (link)
Я о них знаю буквально столько же. Мне кажется, в этой идее есть какая-то фундаментальная подстава, но обосновать не могу.

(Reply to this) (Parent)

(Anonymous)
2008-02-22 01:31 pm UTC (link)
А у Cisco ITP (маршрутизатор ОКС7 на базе обычного IOS) на платформе 7600 есть режим Non-Stop Operation, когда резервный SUP подхватывает управление меньше чем за секунду. Правда там почти вся работа сосредоточена на FlexWAN'ах. Падения само-собой бывают разные.

Две коробки рулят по жизни, персонально я всегда предпочту две простых коробки чем одну многоголовую, многошинную и со многими блоками питания.

--
mtve

(Reply to this)


[info]netch
2008-03-01 10:11 am UTC (link)
А то, что "сигнализация в IP-сетях in-band" - оно ведь в какой-то:) мере исправимо?

(Reply to this) (Thread)

[info]dbg
2008-03-01 10:29 am UTC (link)
Наверное, исправимо - в какой-то мере. Но не очень понятны выгоды от такого решения.

(Reply to this) (Parent)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…