Subnets.ru

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

Код: Выделить всё: FastEthernet0/1 is up, line protocol is up (connected) Hardware is Fast Ethernet, address is 0014.1c9e.4381 (bia 0014.1c9e.4381) Description: Dom 120 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 12/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s, media type is 100BaseFX input flow-control is off, output flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:01, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 199000 bits/sec, 158 packets/sec 5 minute output rate 4838000 bits/sec, 1212 packets/sec 771039 packets input, 114090718 bytes, 0 no buffer Received 23994 broadcasts (0 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 23387 multicast, 0 pause input 0 input packets with dribble condition detected 57423552 packets output, 754008856 bytes, 3845 underruns 0 output errors, 0 collisions, 1 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 3845 [b]output buffer failures[/b], 0 output buffers swapped out

На данном порту значение равно 3845, на некоторых устройствах достигает порядка 200К - 400К.
Решил копать далее, накопал на https://www.cisco.com/c/ru_ru/support/d ... 20-41.html - объяснение, что куда и почему тюнить. В общем начал я тюнить:

Код: Выделить всё: buffers small permanent 175 buffers small max-free 250 buffers small min-free 50 buffers small initial 350 buffers big permanent 256 buffers big max-free 2048 buffers big min-free 1024 buffers big initial 512

Это на 3550-24fx. Вроде бы нормально, но такая же история обнаружилась на уровне доступа клиентов - catalyst-2950. Естественно по глупости вбиваю эти же параметры, все сохраняется, перезапускаю устройство и оно не заводится с формулировкой

Код: Выделить всё: SYSTEM INIT: INSUFFICIENT MEMORY(640 BYTES) TO BOOT THE IMAGE! Local Memory Free = 1824 Total = 3885024 Used = 3883200 IO Memory Free = 0 Total = 2179840 Used = 2179840 8017F944 SYSTEM INIT: INSUFFICIENT MEMORY(640 BYTES) TO BOOT THE IMAGE! Local Memory Free = 1748 Total = 3885024 Used = 3883276 IO Memory Free = 0 Total = 2179840 Used = 2179840 8017F944 8017F944

Ясное дело - не хватило памяти.

К чему я это всё? Может ли "output buffer failures" послужить причиной низкого качества оказываемых услуг? Если да, то как с этим бороться?

Кстати, когда я это все сделал на 3550, то при проверке в

Код: Выделить всё: show buffers failures

у меня стало пусто, но подобные сообщения на портах по прежнему остаются.
Спасибо.

Никогда не понимал и видимо никогда не пойму смысла произносить подобные фразы:

Андрей писал(а):причиной низкого качества оказываемых услуг?

Как и "у меня не работает!" эта фраза не несет в себе никакой смысловой нагрузки для технаря. Ибо сразу рождает пачку вопросов:

и т.д. и т.п.

Могу сказать, что за 10-ть лет моей практики использования Cisco ещё ни разу не видел девайса где бы были buffer failures.
Видимо потому, что мы с тобой по разному проектируем и строим сети. Скажу прямо - скорее всего именно тебе стоит пересмотреть свою схему построения сети. Да, да, да - всей сети, т.к. явно, что она спроектирована и настроена не оч.хор.

Buffer failures occur due to overflow of data being buffered in physical memory of routers. ONLY way to free the buffers is to reload the router (which of course implies downtime, so please plan accordingly).
Also, the underruns could be caused by layer 1/2 issues, like bad cabling/patch panels , mismatch of speed/duplex settings on the switch.

Андрей писал(а):57423552 packets output, 754008856 bytes, 3845 underruns

output buffer failures
Description: Cisco IOS sh interfaces counter. The number of failed buffers and the number of buffers swapped out.
Common Causes:
As an example, consider a scenario where a 1gig multicast stream is being forwarded to 24 100 Mbps ports. If an egress interface is over-subscribed, it would be normal to see output buffer failures incrementing along with Out-Discards.

Underruns
Description: The number of times that the transmitter has been running faster than the switch can handle.
Common Causes: This can occur in a high throughput situation where an interface is being hit with a high volume of bursty traffic from many other interfaces all at once.

Interface resets may be occurring along with the underruns.
To find out whether it is actually caused by over subscription, we can do the following:
Investigate the devices connected to interface
1.Clear the counter then set loading interval to 30 sec and issue the sh interface on ingress port and egress port and see the average traffic going through the links.
2.Use SNMP station to keep polling the ingress and egress interfaces every 5 secs to check the traffic load on ingress and egress ports.

Вообщем с ходу проблему не решить и ИМХО тюнинг нужно заменить на траблшут и разбор полетов "а что вообще происходит?". Тюнить можно, НО только после того как будет найдена причина и будет понятно, а что же тюнить. Попытка тюнить все подряд БЕЗ понимания источника проблемы - 100% фиаско, т.к. проблема 100% будет появляться снова и снова или усугубляться со временем.
В силу того что вопрос траблшута подобных проблем огромен и мне слабо представляется как этот вопрос решать в рамках форума, то писать трактаты я не буду.
Ограничусь общими советами того, что я бы сделал для начала.

sh ip traffic

sh interfaces counter

sh int counters errors

root писал(а):Никогда не понимал и видимо никогда не пойму смысла произносить подобные фразы:
Андрей писал(а):причиной низкого качества оказываемых услуг?

Как и "у меня не работает!" эта фраза не несет в себе никакой смысловой нагрузки для технаря. Ибо сразу рождает пачку вопросов:
- каких услуг ?
- что есть "низкое кач-во" ?
- потери ?
- повышение времени отклика ?
- откуда ?
- куда ?
и т.д. и т.п.

Вот в том и проблема, что если бы были ошибки, то они бы отразились на интерфейсе в соответствующем поле, если бы были потери - тот же пинг бы указал об этом. Опять же, со слов клиентов - "что-то оно тормозит/лагает". Банальный тест iperf/netperf или тот же speedtest показывают, что все в норме и по выделяемой скорости для клиента и по отсутствию потерь. В целом - да, можно предположить повышение времени отклика.

root писал(а):Видимо потому, что мы с тобой по разному проектируем и строим сети. Скажу прямо - скорее всего именно тебе стоит пересмотреть свою схему построения сети. Да, да, да - всей сети, т.к. явно, что она спроектирована и настроена не оч.хор.

А что там может быть не так спроектировано? Обычное дерево с vlan'ом на дом: уровень доступа Каталисты 2950, 3548; уровень агрегации - Каталисты 3550-24FX (24 100 мегабитных оптический порта на уровень доступа + гигабитный gbic-аплинк); ядро - Foundry BigIron; уровень серверов - стандартный набор + pptp-сервера на FreeBSD. Дерево даже без избыточных связей.

root писал(а):Могу сказать, что за 10-ть лет моей практики использования Cisco ещё ни разу не видел девайса где бы были buffer failures.

Есть предположение, что данная проблема возникает, в моем случае, только благодаря включению mvr, у меня он включается в dynamic режиме.

root писал(а):Тюнить можно, НО только после того как будет найдена причина и будет понятно, а что же тюнить.

Тюнить я пытаюсь по выводу

Код: Выделить всё: show buffers failures

. там оно показывает где чего и как свалилось, равно как и в

Код: Выделить всё: show buffers

Проблема в том, что ряд выдачи гугла, в т.ч. и форум одной из организаций по продаже оборудования говорит о том, что это проблема:
1. Скорее всего самого IOS
2. это проблема нехватки буферов (собственно я по этой причине тюнить начал)
3. якобы это проблема не того и не другого и дефолтных параметров вполне достататочно, а проблема эта в том, что порты у меня 100 мегабитные и включены сразу за гигабитным О_о о как.

Чтобы разбираться в проблеме надо сначала точно осознать в чем она, а для этого надо не предполагать, а располагать инфой.

Андрей писал(а):А что там может быть не так спроектировано?

Я так понимаю это риторический вопрос ? Без аудита сети на этот вопрос не дать ответа.
Что-то явно не так раз сталкиваешься с подобными проблемами. Проектирование сети это не только физика, но и логика.

Ок. Тогда такой вопрос. Чисто пальцем в небо, но мало ли. В сети запущен mvr в режиме dynamic. При этом график нагрузки на интерфейсы (уровень агрегации) странным образом почти на всех портах похож. Так же не бывает? Или бывает?
Нагрузка на процы у железа агрегации около 5%.
Я могу предположить, что это кольцо, но те кольца с которыми я сталкивался, как правило валили сеть сразу, единственное что помогало - физическое отключение интерфейса, а тут нагрузка, но, какая-то "одинаковая" - трафик пользователей + что-то еще. Вариант, конечно дойти до узла и заснифать трафик, если теория подтвердится.

Без понимания схемы сети и изучения этой сети можно пальцем в небо так - чудес не бывает. Это для тебя подписи над графиками что-то значат, а для нас это просто буквы.
Если графики одинаковые, то значит либо ошибка в их формировании (конфиг мртг) или это что-то течет откуда куда то.
Что течет и зачем течет ? Это основные вопросы в твоем случае и на которые тебе надо ответить.

Subnets.ru

cisco. output buffer failures

cisco. output buffer failures

Re: cisco. output buffer failures

Re: cisco. output buffer failures

Re: cisco. output buffer failures

Re: cisco. output buffer failures

Re: cisco. output buffer failures