/isp/ кривые ручки и мелкие кошки

[netch]

В качестве переклички с http://dbg.livejournal.com/45329.html:

Жил-был на edge раутере (с BGP fullview) redistribute map BGP->OSPF, прикрытый redistribute list'ом с deny any. В один сильно не прекрасный момент один из нокеров решил устранить лишнюю сущность в виде list'а.:) Тот из закрытого превратился в пустой и потому открытый.

Дежурный удивлённо наблюдал как NAS'ы (которые были от 2511 до 5300) по очереди пропадали из видимости.:) Половина кошек просто перезагрузилась. Другая половина осталась в ROMMON'е, и канальщикам до конца дня была работа ездить по площадкам дёргать anykey.

Comments

[amazi.livejournal.com]

У старших 6500-й же можно засунуть 2 супервизора, они что, держали один запасной на 2 шасси?:)
И 6500-я--еще тот кусок счастья--с одним набором модулей ей требуется катос на супервизоре и иос на MSFC, с другим--везде иос.

[netch]

А чего меня спрашиваешь? Я разве что 6000-й видел, и то ему модули не строил.
6000-й у нас полностью IOS'изированный.

[dbg.livejournal.com]

Это вполне естественно иметь ЗиП не в отношении 1:1. Что касается усовывания двух супервизоров в один ящик, то это отдельный набор граблей. Как-нибудь соберусь написать.

[furry.livejournal.com]

Мое личное мнение, что резервировать надо коробками на L3 (ну или на L2), а 2 модуля в одно шасси - только в случае невозможности нормального резервирования (типа на access'e).

[dbg.livejournal.com]

Абсолютно полностью на сто процентов согласен.

[furry.livejournal.com]

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

[netch]

А мне обоснуйте.:) В принципе всё должно зависеть от двух вещей:
- относительная частота выхода из строя супервизора и шасси
- убивает ли вышедший из строя супервизор нормальную активность на шасси

Если супервизор выходит из строя чаще и не парализует шасси - ставить два супервизора вполне осмысленно. Если реже или парализует - надо ставить две разные железки.

Логично? Или я чего-то не учёл?

[furry.livejournal.com]

Ну если говорить о конкретном вендоре ;) - то выход из строя супервизора парализует шасси. Поэтому я и говорю о двух железках. Ну, разумеется, все изначально зависит даже не от поведения шасси, а от требований к сети - если, как было у одного заказчика - "4 часа простоя - ничего страшного" - то можно и не заморачиваться двумя устройствами..
Кроме того, два супа в одном шасси не спасают нас от сбоев софта. Поскольку - опять-таки, говоря о конкретном вендоре A B C. - супервизор часто оказывается наиболее дорогой железкой в комплекте - то вариант 2-х устройств по цене отличается несильно, а стабильность его значительно выше.

[iskatel.livejournal.com]

Так-то оно так.. но пойди объясни это тем, кто решает, что и как покупать. ТАм нечасто понимают, что 2 76-х - это лучше, чем 2 720-х на одном шасси. Хотя бы потому, что 2 шасси можно разнести в 2 шкафа.

[dbg.livejournal.com]

Есть несколько факторов.

Single box redundancy в случае, например, SSO/NSF делает несколько не слишком очевидных предположений: 1) FIB остался жив и цел, поэтому соседи могут продолжать форвардить трафик на нас 2) второй супервизор (RPR, RSP, ну в общем то, что исполняет control plane) находится в достаточном здравии, чтобы отработать восстановление. Если что-то пошло не так, то будет потеря трафика через сбойный ящик составит минуты, пока соседи не отчаются и не плюнут на полусбойный роутер.

SSO/NSF не совместим с быстрыми таймерами. Надо чтобы второй супервизор обнаружил сбой первого и начал восстановление быстрее, чем это сделают соседи.

Да и вообще, весь этот graceful restart дело не самое быстрое. Плюс для каких-то протоколов этот graceful restart есть, а для каких-то нет, что тоже может приводить к неочевидным взаимодействиям.

Ну и к этом надо добавить, что взаимодействие двух control plane модулей в рамках одного ящика сложно, что само по себе повышает вероятность проблем.

В случае multiple box redundancy, мы хорошо понимаем, как именно будет происходить восстановление: как будет обнаружен сбой, как отреагирует на него протокол маршрутизации, в какой момент посыплются LSA, как будет пересчитан SPF, что будет происходить с FIB и т.д.

На сегодня, multiple box redundancy позволяет добиться лучшего времени сходимости, он хорошо понят сетевыми инженерам, его проще отлаживать. Есть, конечно, случаи, когда multiple box redundacy невозможен - например, это access. Вот там железкам с резервированным control plane и место.

[furry.livejournal.com]

А, ну и еще очень важный момент забыла - L3 сходится в общем случае быстрее и предсказуемее. Миллисекундная сходимость вполне достигаема. Перерыв в обслуживании при резервировании внутри коробки - штука хитрая и не столь очевидная

[dbg.livejournal.com]

"Любая сложная проблема имеет простое, понятное и неправильное решение". :)

Мол засунем два супервизора, и наш ящик будет жить вечно - что может быть проще?

[furry.livejournal.com]

О да! Full view отдать в OSPF - это такие, я бы сказала, культовые грабли. У меня в личном top-листе стоят рядом с "настроили IP accounting и не снимаем его с кошки"

[netch]

Это само по себе ещё можно было быстро исправить, не вопрос. Но вот чтобы NAS'ы остались в ROMMON'е - я ещё никогда до того и после того не видел.

[furry.livejournal.com]

Вот именно в тот раз, когда в компании X отдали на бедный NAS full view по OSPF - железка _снесла_ себе часть конфига, ушла на перезагрузку и осталась в ROMMON'e. Дело было в 99-м, я подробностей уже и не помню - но, видимо, это характерное поведение было.

[ximaera.livejournal.com]

как показала практика, культовые грабли, ага :-)

[dbg.livejournal.com]

О, редистрибуция из BGP в OSPF - это поистине неисчерпаемый источник факапов :)

Пусть у нас есть конфиг вида
router ospf 1
redistribute bgp 1 subnets route-map bgp2ospf

Что делает человек, который желает убрать редистрибуцию? Правильно, берет всю строчку redistribute, приписывает ей в начало no, и аккуратно пейстит ее в роутеру. Сети становится очень плохо. Почему? А потому, что в конфиге остается следующее:

router ospf 1
redistribute bgp 1

Конечно, в этом случае в OSPF прилетают только сети с natural mask, но и этого хватает, чтобы испортить настроение.

Причем, это не баг, это фича. Правильный способ убирать редистрибуцию - это писать просто no redistribute bgp 1.

[mt6561.livejournal.com]

Дядьки! А скажите мне, зачем вообще может понадобиться делать redistributing BGP routes to OSPF?