On Tue, 10 Feb 2009, Andrey Zarechansky wrote:

On Tue, Feb 10, 2009 at 09:40:11PM +0200, Anton Turygin wrote:

Привет,

Привет

1) Аппаратная проблема 2) Проблемная конфигурация 3) Проблемное окружение

По описанию похоже на композит 2 и 3. Снимаешь CPU load? Есть DFC на 6704?

Да. WS-F6700-DFC3CXL. CPU в порядке. Увеличу дискретность съема, может есть всплеск на момент начала проблемы (но это обычно дело пары секунд).

Заземлена ли коробка? Развязана галванически с незаземленными элементами?

С этим проблема. Железка в ДЦ в штатах. Само шасси уже меняли. Может таки отправить их менять RSP? Забыл только один факт упомянуть. Если через нее зароутить трафик только с некоторых сетей (получается ~30% от общего и только исходящий) - стоит как вкопаная и никаких проблем.

Я бы начанал копать сначала CPU load на RP/SP в сторону: - unknown unicast flood - arp flood - l2 loop

Она как-то и в кольце не участвует. Один интерфейс - внутрь с SVI. Второй интерфейс - no switchport в аплинка. Может убить нафиг SVI?

- агрессивные таймера старения/хелло

На OSPF timers throttle spf 20 100 3000 timers throttle lsa 50 100 3000 timers lsa arrival 20 int XXX ip ospf dead-interval minimal hello-multiplier 4 но всего один интерфейс участвует. И в датабазе только лупбек нейбора да интерфейс.

- влияние других устройств на агрессивное проливание rib'а в fib/lfib

Например что может влиять?

- pbr? - nat?

Не-не. Никаких.

Попробуй посмотреть не встречается ли в момент проблем трафик не отрабатоный cef'ом.

Дык в момент проблем вообще трафика нет ;-) Железка выводится из ступора только hard reload-ом. Но таки да. Статистику посмотрю, куда оно изначально начинает трафик швырять.

Если озвученный танцы не помогут, гаси коробку, доставай пылесос и перебирай память и тщательно защелкивай разъемы.

Если и это не поможет, открывай case и смотри как с тобой будет бороться инженер TAC'а.

Да уж собираюсь. Только опять же сложно с разницей во времени. И держать ее долго в таком состоянии не могу (забиваются интерфейсы на другой железке). Потому сюда сначала пришел ;-)

...

Привет. Господа, может кто умное чего посоветует. Бо я уже шишку набил ;-(

Имеется: 7606 RSP720-10GE + WS-X6704-10GE + WS-X6748-SFP

Трафика ~9 гигабит. Весь трафик, собственно, крутится на WS-X6704-10GE (в один порт пришел, в другой ушел).

Из всякого исполняет на себе HSRP, spanning tree. 2 BGP нейбора. Немного OSPF.

Так вот, раза два-три в день она зависает. Причем зависает не намертво (консолью попасть можно). Дропает HSRP, BGP и роутинг, как таковой. Причем на обеих платах. Интерфейсные пинги не ходят.

В этот момент она отлично видит MAC-и на своих портах. Но вот на железках, подключеных к ней, MAC-ов на соответствующих портах нет. Если попытаться запихнуть в нее трафик, который надо свичевать - нормально свичует.

В логах пусто (кроме, собственно, падения HSRP, BGP и OSPF).

show platform hardware capacity странностей не показывают.

IOS-ы пробовал 122-33.SRC1 и 122-33.SRD. Везде одна картина.

Вот и что с такой бедой посоветуете делать? ;-(

-- RAZ-UANIC RAZ-RIPE

On Tue, Feb 10, 2009 at 09:40:11PM +0200, Anton Turygin wrote:

Привет. Господа, может кто умное чего посоветует. Бо я уже шишку набил ;-(

Имеется: 7606 RSP720-10GE + WS-X6704-10GE + WS-X6748-SFP

Трафика ~9 гигабит. Весь трафик, собственно, крутится на WS-X6704-10GE (в один порт пришел, в другой ушел).

Загрузка DFC ? remote command show proc cpu ? netflow включен ? Отключать не пробовали (глобально, no mls netflow) ? Зачем спрашиваю - это довольно сильно грузит DFC, и, по крайней мере когда-то давно днатыкался я на похожую багу - при невозможности экспорта netflow по причине перегруза CPU (причем не RP, который по обычному show proc cpu показывается, а Switch Processor) наблюдались похожие симптомы...

Из всякого исполняет на себе HSRP, spanning tree. 2 BGP нейбора. Немного OSPF.

Так вот, раза два-три в день она зависает. Причем зависает не намертво (консолью попасть можно). Дропает HSRP, BGP и роутинг, как таковой. Причем на обеих платах. Интерфейсные пинги не ходят.

В этот момент она отлично видит MAC-и на своих портах. Но вот на железках, подключеных к ней, MAC-ов на соответствующих портах нет. Если попытаться запихнуть в нее трафик, который надо свичевать - нормально свичует.

В логах пусто (кроме, собственно, падения HSRP, BGP и OSPF).

show platform hardware capacity странностей не показывают.

IOS-ы пробовал 122-33.SRC1 и 122-33.SRD. Везде одна картина.

Вот и что с такой бедой посоветуете делать? ;-(

-- RAZ-UANIC RAZ-RIPE

On Wed, 11 Feb 2009, Alexandre Snarskii wrote:

On Tue, Feb 10, 2009 at 09:40:11PM +0200, Anton Turygin wrote:

...

Привет. Господа, может кто умное чего посоветует. Бо я уже шишку набил ;-(

Имеется: 7606 RSP720-10GE + WS-X6704-10GE + WS-X6748-SFP

Трафика ~9 гигабит. Весь трафик, собственно, крутится на WS-X6704-10GE (в один порт пришел, в другой ушел).

Загрузка DFC ? remote command show proc cpu ?

netflow включен ? Отключать не пробовали (глобально, no mls netflow) ? Зачем спрашиваю - это довольно сильно грузит DFC, и, по крайней мере когда-то давно днатыкался я на похожую багу - при невозможности экспорта netflow по причине перегруза CPU (причем не RP, который по обычному show proc cpu показывается, а Switch Processor) наблюдались похожие симптомы...

Спасибо за совет. Отключил глобально. Наблюдаю. Я правильно понимаю, что remote command show proc cpu показывает то же самое, что и sh platform hardware capacity cpu на модуле? И отлично снимаема по SNMP 1.3.6.1.4.1.9.9.109.1.1.1.1.4 ?

...

Из всякого исполняет на себе HSRP, spanning tree. 2 BGP нейбора. Немного OSPF.

Так вот, раза два-три в день она зависает. Причем зависает не намертво (консолью попасть можно). Дропает HSRP, BGP и роутинг, как таковой. Причем на обеих платах. Интерфейсные пинги не ходят.

В этот момент она отлично видит MAC-и на своих портах. Но вот на железках, подключеных к ней, MAC-ов на соответствующих портах нет. Если попытаться запихнуть в нее трафик, который надо свичевать - нормально свичует.

В логах пусто (кроме, собственно, падения HSRP, BGP и OSPF).

show platform hardware capacity странностей не показывают.

IOS-ы пробовал 122-33.SRC1 и 122-33.SRD. Везде одна картина.

Вот и что с такой бедой посоветуете делать? ;-(

-- RAZ-UANIC RAZ-RIPE

-- RAZ-UANIC RAZ-RIPE Technological Systems CJSC Senior Network Engineer

On Wed, 11 Feb 2009, Dmitry Kiselev wrote:

Привет!

On Wed, Feb 11, 2009 at 02:01:38PM +0200, Anton Turygin wrote:

...

...

...

Привет. Господа, может кто умное чего посоветует. Бо я уже шишку набил ;-(

Имеется: 7606 RSP720-10GE + WS-X6704-10GE + WS-X6748-SFP

Трафика ~9 гигабит. Весь трафик, собственно, крутится на WS-X6704-10GE (в один порт пришел, в другой ушел).

Загрузка DFC ? remote command show proc cpu ?

netflow включен ? Отключать не пробовали (глобально, no mls netflow) ? Зачем спрашиваю - это довольно сильно грузит DFC, и, по крайней мере когда-то давно днатыкался я на похожую багу - при невозможности экспорта netflow по причине перегруза CPU (причем не RP, который по обычному show proc cpu показывается, а Switch Processor) наблюдались похожие симптомы...

Спасибо за совет. Отключил глобально. Наблюдаю.

Я правильно понимаю, что remote command show proc cpu показывает то же самое, что и sh platform hardware capacity cpu на модуле? И отлично снимаема по SNMP 1.3.6.1.4.1.9.9.109.1.1.1.1.4 ?

Да, это оно же.

То о чем говорил Снар наблюдалось на Sup720. RSP720 имея на борту более мощный SP CPU этому уже не подвержены: и SP и DFC CPU справляются с NDE полностью забитого и затюненого насмерть XL netflow TCAM без проблем.

По бумажке или в реалии? ;-) Я вот просто уже не первый раз слышу, что именно RSP720-10GE у людей липнет. Кто-то решил перезаливкой IOS-а. А у кого-то само устаканилось. Вобщем IOS перезалил, netflow на всяк случай глобально отключил. RP/SP/DFC мониторю. Посмотрим, что будет... -- RAZ-UANIC RAZ-RIPE

Добрый день! On Wed, Feb 11, 2009 at 03:43:53PM +0300, Alexandre Snarskii wrote:

...

То о чем говорил Снар наблюдалось на Sup720. RSP720 имея на борту более мощный SP CPU этому уже не подвержены: и SP и DFC CPU справляются с NDE полностью забитого и затюненого насмерть XL netflow TCAM без проблем.

Не верю! (с) Станиславский. :)

Я конечно имел ввиду generic internet traffic :) Хотя, мне кажется, что TCAM overflow случится раньше чем NDE упрется в нехватку CPU. И народ вроде на такие проблемы нигде не жаловался...

i.e., возможно, на вашем паттерне траффика оно и справляется, но на нашем - прогнется. Один из клиентов - одна из крупнейших баннерных сетей, очень много мелких потоков (~десять пакетов/flow). Так что в два раза более мощный процессор - не панацея, они за год afair раза в четыре ускорились...

Интересно было бы поставить эксперемент :) -- Dmitry Kiselev

On Thu, 12 Feb 2009, Anton Turygin wrote:

On Wed, 11 Feb 2009, Alexandre Snarskii wrote:

...

On Wed, Feb 11, 2009 at 02:13:15PM +0200, Dmitry Kiselev wrote:

...

...

...

...

Привет. Господа, может кто умное чего посоветует. Бо я уже шишку набил ;-(

Имеется: 7606 RSP720-10GE + WS-X6704-10GE + WS-X6748-SFP

Трафика ~9 гигабит. Весь трафик, собственно, крутится на WS-X6704-10GE (в один порт пришел, в другой ушел).

Загрузка DFC ? remote command show proc cpu ?

netflow включен ? Отключать не пробовали (глобально, no mls netflow) ? Зачем спрашиваю - это довольно сильно грузит DFC, и, по крайней мере когда-то давно днатыкался я на похожую багу - при невозможности экспорта netflow по причине перегруза CPU (причем не RP, который по обычному show proc cpu показывается, а Switch Processor) наблюдались похожие симптомы...

Спасибо за совет. Отключил глобально. Наблюдаю.

Я правильно понимаю, что remote command show proc cpu показывает то же самое, что и sh platform hardware capacity cpu на модуле? И отлично снимаема по SNMP 1.3.6.1.4.1.9.9.109.1.1.1.1.4 ?

Да, это оно же.

То о чем говорил Снар наблюдалось на Sup720. RSP720 имея на борту более мощный SP CPU этому уже не подвержены: и SP и DFC CPU справляются с NDE полностью забитого и затюненого насмерть XL netflow TCAM без проблем.

Не верю! (с) Станиславский. :)

i.e., возможно, на вашем паттерне траффика оно и справляется, но на нашем - прогнется. Один из клиентов - одна из крупнейших баннерных сетей, очень много мелких потоков (~десять пакетов/flow). Так что в два раза более мощный процессор - не панацея, они за год afair раза в четыре ускорились...

Я, конечно, еще не уверен, не совпадение ли, но таки после no mls netflow железка уже больше суток работает нормально... Наверное подержу ее так, а потом контрольно включу обратно netflow и посмотрю, что будет ;-)

Но, ИМХО, это бред полнейший, если она так себя ведет.

Интересная ситуация получается. Позавчера включил mls netflow. Два дня простояла без залипов. Что бы это могло значить... -- RAZ-UANIC RAZ-RIPE

Доброго времени суток, On Wed, Feb 18, 2009 at 01:31:05PM +0200, Вы написали ...:

Доброго времени суток,

...

С этим проблема. Железка в ДЦ в штатах.

забыл добавить что тестируемые адреса в directly connected сетях на указаных интерфейсах.

они только в украине нормально работают :)

дано: Cisco 7606-s RSP720-10G-3CXL IOS: 12.2.33SRD, advipservicesk9-mz (на SRC1 тот же баг был)

задача: "залипло" несколько SVI интерфейсов если попасть с консоли на кошку - то:

cisco#ping 80.xxx.xxx.105 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 80.xxx.xxx.105, timeout is 2 seconds: .!..! Success rate is 40 percent (2/5), round-trip min/avg/max = 1/1/1 ms cisco#

cisco#ping vrf Management 10.xxx.xxx.2 Sending 5, 100-byte ICMP Echos to 10.xxx.xxx.2, timeout is 2 seconds: ....! Success rate is 40 percent (1/5), round-trip min/avg/max = 272/272/272 ms cisco#

решение: делаем пустой route-map, прибиваем его как PBR мап на SVI, и вуаля...

cisco#conf ter Enter configuration commands, one per line. End with CNTL/Z. cisco(config)#route-map 1 p 10 cisco(config-route-map)#int vlan10X cisco(config-if)#ip policy route-map 1 cisco(config-if)#do ping 80.xxx.xxx.105

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 80.xxx.xxx.105, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms cisco(config)#int vlan2X cisco(config-if)#ip policy route-map 1 cisco(config-if)#do ping vrf Management 10.xxx.xxx.2

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.xxx.xxx.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms cisco(config-if)#end cisco#

идеи ? :)

...

Само шасси уже меняли. Может таки отправить их менять RSP? Забыл только один факт упомянуть. Если через нее зароутить трафик только с некоторых сетей (получается ~30% от общего и только исходящий) - стоит как вкопаная и никаких проблем.

-- INTR-RIPE

-- INTR-RIPE

On Wed, 18 Feb 2009, Vladimir Litovka wrote:

Это может означать только одно - надо обращаться в TAC. Потому что RSP720-10G пока-что находится в статусе "ограниченная продажа" и потому эта самая продажа возможна только после согласований с соответствующими службами внутри Cisco. Понятное дело, с согласованиями конфигураций, в которых он работает. Широко доступен этот процессор станет через некоторое время, когда софт для него будет доделан.

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

Приобретен-то легально... Намек понят, мы подопытные крысы ;-) 2009/2/18 Anton Turygin :

Интересная ситуация получается. Позавчера включил mls netflow. Два дня простояла без залипов.

Что бы это могло значить...

-- RAZ-UANIC RAZ-RIPE

-- /doka -- RAZ-UANIC RAZ-RIPE Technological Systems CJSC Senior Network Engineer

On Wed, 18 Feb 2009, Vladimir Litovka wrote:

2009/2/18 Anton Turygin :

...

Это может означать только одно - надо обращаться в TAC. Потому что RSP720-10G пока-что находится в статусе "ограниченная продажа" и потому эта самая продажа возможна только после согласований с соответствующими службами внутри Cisco. Понятное дело, с согласованиями конфигураций, в которых он работает. Широко доступен этот процессор станет через некоторое время, когда софт для него будет доделан.

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

Приобретен-то легально... Намек понят, мы подопытные крысы ;-)

так если легально - долбите TAC :) может быть даже поможет ;-) А кто мне скажет, в чем принципиальное отличие 3CXL и 3CXL-10G? Кроме десяток набортных и переработаных очередей? -- RAZ-UANIC RAZ-RIPE