СоХабр закрыт.

С 13.05.2019 изменения постов больше не отслеживаются, и новые посты не сохраняются.

Авария: отказал CEF на Cisco 6500 в черновиках Из песочницы

Разберём на будущее случай с аварией, когда отказал CEF на Cisco 6500



Пришла sms, что такой-то маршрутизатор (Cisco 6500) UP. Поясню, что система мониторинга просто пингует маршрутизатор и сообщает, если изменилось его состояние: DOWN/UP. Это очень опасная sms, т.к. каждый такой маршрутизатор — как микрорайон или его половина (дело происходит в сети интернет-провайдера). И даже то, что по sms маршрутизатор UP — не нормально.

Первая часть

Заходим мы с напарником на маршрутизатор — вроде доступен. Смотрим по логам: OSPF, LDP-соседство не рвал, это уже хорошо.
Предполагаем, что RP=Route Processor ушёл в 100% — так и есть.
show processes cpu sorted показывает, что-то вроде 95%/85% — т.к. цифры совпадают, то RP загружен не процессами, а прерываниями — т.е. много трафика обрабатывается CPU.

Делаем debug netdr — там очень много пакетов, помеченных VLAN 1044. Причём это multicast-пакеты, как те, которые идут в Global к маршрутизатору, так и те, которые в VRF идут от него к клиентам.

В логах мы видим кучу ошибок: Traceback, бла-бла-бла, ошибка памяти и т.п. Сразу некогда было подробно нагуглить, что это за ошибки.

VLAN 1044 на коммутаторе не ищется, только show vlan id 1044 internal usage показывает, что он выдан в интерфейс Po1, а вообще-то Po1 это L3-интерфейс! Почему так оказалось с VLAN 1044 я не знаю, разбираться не стали.

В общем, мы подумали, что проблема связана с передачей multicast. Стали пробовать гасить интерфейс Po1, через который заходит телевидение — но весь трафик пошёл через другой интерфейс, загрузка RP осталась 100%.

Про клиентские сервисы я решил, что точно страдает телевидение. При этом с самого маршрутизатора клиенты в VRF для «юриков» и в VRF для «физиков» пинговались — и я решил, что трафик интернета не страдает. При этом я видел сильную просадку трафика по графикам, но не до нуля. Вероятно, надо было тщательней выяснить момент про клиентские сервисы — пропинговать клиентов из мира, прикинуть, сколько трафика ушло, и сколько из него было телевидения.

Тут наша фантазия иссякла, уже 1 час прошёл, а мы аварию не устранили — эскалировали в отдел развития сети и уведомили начальника. Завели заявку самого высокого приоритета, описали симптомы, свои действия. Я написал в техподдержку, чтобы они учитывали эту аварию при звонках клиентов и сообщали голосом, если будут массовые жалобы клиентов, включенных с этого маршрутизатора.

На этом первая часть заканчивается.

Вторая часть

Итак, мы сдали проблему в отдел развития сети. Но мы оба с напарником не выключились из работы по заявке.

Всё осложнялось тем, что вечер, 21:00-22:00, ЧНН.
Пришлось отвлекаться на балансировку нагрузки во внешних каналах и заведение заявок по упавшим/поднявшимся коммутаторам, неработающим телеканалам и пр. Балансировку я сделал за 5 минут по опыту, и повезло, что крупных аварий не было, а мелкие я обработал или оставил на потом.

Напарник делал диагностику командами show на Cisco 6500, а я гуглил ошибки из сообщений в логах.
Добавлю, что с самого начала аварии Cisco 6500 тупила в консоли и иногда разрывала соединение.
Тут пришёл сигнал из техподдержки, что они не могут зайти на коммутаторы, которые включены от этого маршрутизатора, и что клиенты массово жалуются на торможение сайтов и пингуются с огромными потерями — тут стало понятно, что страдают все сервисы.

Я уже подумал по опыту, что отдел развития сети будет дебажить, а потом всё равно всё закончится перезагрузкой.:) Так что позвонил начальнику монтажников, чтобы он брал консоль с GSM-модемом и ехал на узел связи. Там он должен подключить консоль к Cisco 6500, мы через GSM зайдём на эту консоль и после этого перезагрузим Cisco 6500. Это нужно на тот случай, если после перезагрузки коммутатор не взлетит, и придётся его оживлять.
У начальника монтажников бойцов было мало, некоторым из них предстояли ночные работы, так что он поехал сам.

Ещё я всю информацию своевременно отражал в заявке, не ждал, что отпишусь после устранения аварии. И это правильно — все должны видеть, на какой стадии находится устранение аварии сейчас.

В общем, я нагуглил на cisco.com по сообщению об ошибке какой-то баг Cisco 7600, где сообщалось, что это «глюк», в результате которого коммутатор перестаёт добавлять в CEF новые маршруты. «Глюк» может возникнуть на ровном месте, т.е. не обязательно вызван какими-то обстоятельствами. Помочь должна перезагрузка маршрутизатора (ха-ха!).
Версия IOS у нас была не в точности та же, что в описании бага, но по цифрам такая же, только буквами отличалась.

Вот то сообщение в логах:
%MLSCEF-SP-2-FREEZE: hardware switching disabled on card
http://www.cisco.com/en/US/docs/ios/12_2sr/release/notes/122SRcavs5.html говорит, что это баг CSCsg40573.

И я заметил по графикам, что просело до нуля количество пакетов, обрабатываемых PFC. Я из этого сделал вывод, что страдают все сервисы. Я был взволнован крупной аварией и не очень хорошо владел темой, поэтому я не подумал спокойно: «А что же обрабатывает PFC?» — А PFC как раз продвигает пакеты CEF'ом.
На том маршрутизаторе нет DFC, поэтому всю коммутацию делает PFC.
Ещё меня смутило, что в в выводе команды show ip cef — маршруты были.
Мой напарник по результатам своей диагностики пришёл к выводу, что проблема с CEF.

В это время мне позвонил начальник и сказал, что они с отделом развития сети пришли к выводу, что CEF просто не коммутирует пакеты, и надо перезагружать маршрутизатор.

Они увидели это по команде
#show mls cef hardware

CEF TCAM v2: (FROZEN)
Size: 262144 entries
65536 rows/device, 4 device(s)
32 entries/mask-block
8192 total blocks (32b wide)
1212416 s/w table memory
Options:
sanity check: off
sanity interval: 301 seconds
consistency check: off
consistency interval: 31 seconds
redistribution: off
redistribution interval: 120 seconds
redistribution threshold: 10
compression: off
compression interval: 31 seconds
tcam/ssram shadowing: on
Operation Statistics:
Entries inserted: 0000000026486227
Entries deleted: 0000000026473952
Entries compressed: 0000000002044646
Blocks inserted: 0000000000476132
Blocks deleted: 0000000000475614
Blocks compressed: 0000000000311462
Blocks shuffled: 0000000000007388
Blocks deleted for exception: 0000000000000000
Direct h/w modifications(TCAM): 0000000000000000
Direct h/w modifications(SSRAM):0000000000000000

Background Task Statistics:
Consistency Check count: 0000000001845943
Consistency Errors: 0000000000000000
SSRAM Consistency Errors: 0000000000000000
Sanity Check count: 0000000000191853
Sanity Check Errors: 0000000000000001
Compression count: 0000000000263706

Exception Handling status: on
L3 Hardware switching status: off
Fatal Error Handling Status: Freeze
Fatal Errors: 0000000000000001

Fatal Error Recovery Count: 0000000000000000

SSRAM ECC error summary:
Uncorrectable ecc entries: 0
Correctable ecc entries: 0
Packets dropped: 0
Packets software switched: 0

FIB SSRAM Entry status
— Key: UC — Uncorrectable error, C — Correctable error
SSRAM banks: Bank0 Bank1
No ECC errors reported in FIB SSRAM.

ADJACENCY SSRAM Application errors:
— The logger for the ADJ sanity checker is disabled

Double Allocation Attempts :0
Double Freeing Attempts :0
Freeing Others' Entries Attempts :0
Writing Others' Entries Attempts :0
Writing To Un-Allocated Entries :0
Suspicious Application Calls :0


Надо обратить внимание на статус CEF — FROZEN и на то, что присутствует Fatal Error.

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

Прошло уже 2-3 дня, а в логах нет сообщений об ошибках.
Т.е. это был разовый программный сбой.

Для меня выводы

1. Нужно лучше учить матчасть: как работает CEF, какими командами смотреть его состояние. Тогда я бы раньше сделал вывод по графикам, что пропали пакеты с PFC, значит, маршрутизатор пакеты вообще не коммутирует!
На будущее мы сделали threshold на графике — когда количество пакетов на PFC упадёт ниже 5000 в течение 3 минут, придёт sms и e-mail.
2. Эскалацию до отдела развития сети можно было сделать раньше, а не через 1 час — всё-таки у многих клиентов страдали сервисы. На будущее, сделаю так: если я убедился, что массово страдает хотя бы один сервис, например, телевидение, и мы сами не можем починить через 30 минут — эскалируем в отдел развития сети и начальнику. Тут главное — чинить, как можно скорее.

комментарии (23)

+44
+45 –1
hitry ,  

Самая захватывающая история про то как ребутнули Циску!

0
RouterID ,  

Спасибо.:))

+4
JDima ,  
Нужно лучше учить матчасть: как работает CEF, какими командами смотреть его состояние.

Да-да.
Версия IOS у нас была не в точности та же, что в описании бага, но по цифрам такая же, только буквами отличалась.

Лет 10 подряд все версии IOS под 6500/7600 были одинаковыми по цифрам — 12.2(33) :) На самом деле, багов, способных вызвать схожую проблему и устраняемых перезагрузкой, немерено. А может, бага не было, просто какой-то бит в памяти перевернуло заряженной частицей.
VLAN 1044 на коммутаторе не ищется, только show vlan id 1044 internal usage показывает, что он выдан в интерфейс Po1, а вообще-то Po1 это L3-интерфейс! Почему так оказалось с VLAN 1044 я не знаю, разбираться не стали.

Все-таки работая с данной платформой, неплохо бы знать, что на ней всё является VLANом — любые логические и физические интерфейсы. Что периодически сильно раздражает (раздражало до Sup2T).
Ещё меня смутило, что в в выводе команды show ip cef — маршруты были.

Потому что «show ip cef» — это software cef, а не то, что программируется в FIB.

Все-таки при недостатке опыта работы с платформой имеет смысл оформить сервисный контракт, чтобы при подобной проблеме завести кейс 2-го приоритета и оперативно получить квалифицированную поддержку (вместо «час помучились и сдались» могло бы быть «за полчаса устранили проблему и получили некоторую гарантию ее неповторения»). А еще если виновато железо, то его поменяют.
0
JDima ,  
Тогда я бы раньше сделал вывод по графикам, что пропали пакеты с PFC, значит, маршрутизатор пакеты вообще не коммутирует!

Ну раз было много прерываний — вероятно, работал software CEF. У меня такое было как-то раз на том же шеститоннике, железка внезапно взяла и забыла, что у нее есть PFC, и лишь благодаря низкому трафику сервис особо не пострадал.

Возможная альтернатива — форвардинг вообще без CEF, но тогда RP был бы нагружен по процессам, и MPLS не работал бы вообще, это наверняка было бы заметно.
0
RouterID ,  

Спасибо за комментарий, почитаю про Software/Hardware CEF, и что «всё на Cisco 6500 есть VLAN».:)
А я был уверен, что CEF всегда делается аппаратно.

К сожалению, у нас поддержка SMARTnet не куплена, экономим. Так что наш Cisco TAC — Google.:)
Решение о целесообразности экономии не мне принимать, а руководство, наверное, учло много разных факторов.

0
mongolio ,  

Сервисный контракт конечно хорошо, и даёт массу плюсов. Но вот насчёт временных бенефитов, не пришлось столкнуться, к сожалению. Конечно кроме CON-SNT я ничего и не видал (поэтому подразумеваю его), но на время устранения аварии личная квалификация и быстрота принятия решений решает абсолютно всё. Вангую, что с TAC они бы по этой аварии работали бы от полу дня и больше. А уж если учесть, что

Всё осложнялось тем, что вечер, 21:00-22:00, ЧНН.

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

А так за час ребята вполне себе таймингово отработали, даже без наличия глубоких познаний платформы.
0
JDima ,  
но на время устранения аварии личная квалификация и быстрота принятия решений решает абсолютно всё

Безусловно.
Но если личной квалификации мало для оперативного устранения нетиповых проблем в data plane, то TAC может и помочь. У меня некоторые крэши решались за 20 минут. Я выслал информацию (логи, core dump или еще что в зависимости от платформы), мне в ответ номер бага и версию софта (это если повезло; если не повезло, то новый баг и рассмотрение в течение недель). В данном случае, думаю, инженер предложил бы пару-тройку clear команд, а дальше, если не помогло, перезагрузку.
и московский офис вежливо редиректит на европу

Да московский офис вообще не работает с P2 кейсами, так что запрос скорее всего сразу в США ушел бы. И с инженером соединили бы сразу же — LAN switching подразделение распространенное, людей много, и не забывайте — кейс заводится по телефону.
0
mongolio ,  
и не забывайте — кейс заводится по телефону.

Это я даже если постараюсь не забуду. У нас у операторов связи есть особенность — раз в пол часа рвётся сотовый/международный вызов. Так я как-то кейс с 3его раза завел/довел до Инженера (дай Шива ему здоровья). Зато не растеряв присутствия духа научился лихо насвистывать Шопена играющего в трубке
+1
eucariot ,  
" какой-то бит в памяти перевернуло заряженной частицей"

Такие проблемы немало доставляют с одной стороны, потому что очень сложно диагностировать. А с другой стороны её очень сложно объяснять заказчику, потому что звучит, как нелепая фантастическая отмазка. И приходится тогда просто говорить, что это дефект ПО даже в случае наличия достаточно веских аргументов.

У меня в одном из случаев после такого Soft Error начали избирательно портиться пакеты RRPP (Хуавэйский протокол-аналог STP для кольцевых топологий). В итоге кольцо сошлось — петля, а трафик продолжал ходить, естественно, начался шторм. По результатам анализа обнаружилось, что на одном из буферов чипа линейной платы одна ячейка была прошита заряженной частицей. Но заказчик не стал даже слушать.
А ведь с уменьшением размеров чипов проблема будет становиться всё более заметной.
0
JDima ,  
звучит, как нелепая фантастическая отмазка

«Свет с Венеры отразился от верхних слоёв атмосферы и вызвал взрыв болотного газа». Классика — нередко приходится произносить эту фразу в ответ на вопросы вроде «почему однократно грохнулся суп на свитче, у которого аптайм был 6 лет и к которому никто не прикасался 4 года?».
0
RootDm ,  

Кейс в Cisco TAC заводили? Если да, то какие были рекомендации для Вашего случая?
Никто не завтрахован найти баг первым. Повезло, что удалось нагуглить ответ.

0
RouterID ,  

К сожалению, у нас поддержка SMARTnet не куплена, экономим. Так что наш Cisco TAC — Google.:)
Решение о целесообразности экономии не мне принимать, а руководство, наверное, учло много разных факторов.

0
AccessForbidden ,  

Я б на вашем месте еще нашел бы замену карте и запустил бы тест этой. Мы в свое время увлекались б/у картами для 65й и пару раз натыкались на какие то странные разовые глюки, которые выливались со временем в глобальные.

0
RouterID ,  

Может быть, и стоило бы заменить — но это ещё расходы, простой. И не факт, что проблема в аппаратном сбое SUP. По истории у этого узла это был первый такой случай, так что оставили так.

0
sluge ,  

А firmware обновили?

0
RouterID ,  

Нет, так оставили. У нас ведь не было чётких рекомендаций с cisco.com обновить IOS, а просто так обновляться на другую версию опасно: может, там свои «баги», может, там не будут работать нормально некоторые нужные функции. В любом случае, новую версию IOS сначала нужно тестировать.

0
JDima ,  

А сейчас какая версия, если не секрет, и какой суп?

0
RouterID ,  

WS-SUP32-GE-3B и s3223_rp Software (s3223_rp-ADVENTERPRISEK9_WAN-M), Version 12.2(33)SXJ. У нас не везде SUP-32.:)

+1
JDima ,  

Первая версия софта из мажорного релиза, не славящегося совсем уж стабильной работой. В бесстрашии вам не откажешь. Я только после выхода SXJ4 рискнул посмотреть на него в лабе.

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

www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/release/notes/ol_14271/caveats_SXJ.html, ctrl+f, «crash». За полученные от этого ночные кошмары не благодарите.

0
RouterID ,  

Мда, есть, о чём подумать.:)

0
nakamura ,  

А рисовать ероры и пакетлосы на графиках не помогает в данной ситуации?

0
RouterID ,  

В смысле — на интерфейсах Errors/Discards? Они рисуются, но как они помогут в данном случае? Пакеты ведь не на интерфейсах погибали, а где-то внутри SUP.

0
PTPtupit ,  

ЕКБ? Саша?