promSSe Posted May 31, 2012 Posted May 31, 2012 Доброго времени суток. Коллеги, ни стого ни сего наблюдаю потерю пакетов проходящих через стек коммутаторов 3750G. Топология простая, на стеке терминируются VLANы, к стеку подключены коммутаторы уровня доступа по средствам EtherChannel, таким же образом к стеку подключен маршрутизатор. Посути топологи простая звезда. Переодически в вечернее время когда нагрузка падает наблюдаю патерю пакетов проходящих через стек, ошибок на интерфейсах нет, загрузка минимальная, и влогах ничего нету. QoS не использую. Сталкивался ли кто с такой проблемой? Вставить ник Quote
nuclearcat Posted May 31, 2012 Posted May 31, 2012 Я сталкивался на 3560G. Терялось из-за нехватки буферов в ASIC. Проверьте не растут ли счетчики в: show platform port-asic stats drop Вставить ник Quote
promSSe Posted May 31, 2012 Author Posted May 31, 2012 Вот что у меня, счётчики далеки от нуля. Если советы по этому поводу? Port-asic Port Drop Statistics - Summary ======================================== RxQueue 0 Drop Stats: 0 RxQueue 1 Drop Stats: 0 RxQueue 2 Drop Stats: 0 RxQueue 3 Drop Stats: 0 Port 0 TxQueue Drop Stats: 1106005871 Port 1 TxQueue Drop Stats: 0 Port 2 TxQueue Drop Stats: 1105983217 Port 3 TxQueue Drop Stats: 676 Supervisor TxQueue Drop Statistics Queue 0: 0 Queue 1: 0 Queue 2: 0 Queue 3: 0 Queue 4: 0 Queue 5: 0 Queue 6: 0 Queue 7: 0 Queue 8: 0 Queue 9: 0 Queue 10: 0 Queue 11: 0 Queue 12: 0 Queue 13: 0 Queue 14: 0 Queue 15: 0 Port-asic Port Drop Statistics - Details ======================================== RxQueue Drop Statistics Queue 0 Weight 0 Frames: 0 Weight 1 Frames: 0 Weight 2 Frames: 0 Queue 1 Weight 0 Frames: 0 Weight 1 Frames: 0 Weight 2 Frames: 0 Queue 2 Weight 0 Frames: 0 Weight 1 Frames: 0 Weight 2 Frames: 0 Queue 3 Weight 0 Frames: 0 Weight 1 Frames: 0 Weight 2 Frames: 0 Port 0 TxQueue Drop Statistics Queue 0 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 Queue 1 Weight 0 Frames 745276173 Weight 1 Frames 105130 Weight 2 Frames 10064 Queue 2 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 Queue 3 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 360614504 Port 1 TxQueue Drop Statistics Queue 0 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 Queue 1 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 Queue 2 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 Queue 3 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 Port 2 TxQueue Drop Statistics Queue 0 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 Queue 1 Weight 0 Frames 745378725 Weight 1 Frames 105291 Weight 2 Frames 10192 Queue 2 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 Queue 3 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 360489009 Port 3 TxQueue Drop Statistics Queue 0 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 Queue 1 Weight 0 Frames 676 Weight 1 Frames 0 Weight 2 Frames 0 Queue 2 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 Queue 3 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 Supervisor TxQueue Drop Statistics Queue 0: 0 Queue 1: 0 Queue 2: 0 Queue 3: 0 Queue 4: 0 Queue 5: 0 Queue 6: 0 Queue 7: 0 Queue 8: 0 Queue 9: 0 Queue 10: 0 Queue 11: 0 Queue 12: 0 Queue 13: 0 Queue 14: 0 Queue 15: 0 Вставить ник Quote
nuclearcat Posted May 31, 2012 Posted May 31, 2012 Проверить - увеличиваются ли они Естественно сопоставить с общим количеством пакетов и темпы дропов Вставить ник Quote
promSSe Posted May 31, 2012 Author Posted May 31, 2012 Если увеличиваются то какой вердикт? Есть ещё подозрение на IOS c3750-ipservicesk9-mz.122-58.SE2.bin, в Интернете многи критики. Но к сожалению перезагрузить коммутаторы обновив IOS просто так не могу. Вставить ник Quote
promSSe Posted May 31, 2012 Author Posted May 31, 2012 Проверил, счётчики растут при минимальной нагрузки на интерфейсах. Замечу, QoS включен. При выключеном QoS ситуация не меняется. QoS is disabled QoS ip packet dscp rewrite is enabled Вставить ник Quote
nuclearcat Posted May 31, 2012 Posted May 31, 2012 Мне помогало: mls qos queue-set output 1 buffers 1 97 1 1 mls qos НО! У вас может не сработать или сделать намного хуже, непонятно почему другие queue выбираются по статистике. Вставить ник Quote
promSSe Posted May 31, 2012 Author Posted May 31, 2012 Сможет ли кто-нибудь объяснить причины такого поведения? При неизменном конфиге ситуация стала обострятся последние две недели. Вот ещё порекомендовали для увелечения порога для дропа. mls qos queue-set output 1 threshold 1 400 400 100 400 mls qos queue-set output 1 threshold 2 400 400 100 400 mls qos queue-set output 1 threshold 3 400 400 100 400 mls qos queue-set output 1 threshold 4 400 400 100 400 Вставить ник Quote
nuclearcat Posted May 31, 2012 Posted May 31, 2012 Может быть к примеру из-за резких всплесков на портах, и суммарных бурстах на аггрегирующем порту выше гигабита, которым не хватает буфера. Вставить ник Quote
promSSe Posted May 31, 2012 Author Posted May 31, 2012 Все порты в 1Gb/s, портов с большей скорость нет. Так же как сейчас нет скачаков трафика на портах, всё почти в ноль. Вставить ник Quote
nuclearcat Posted May 31, 2012 Posted May 31, 2012 Если у вас есть бурст траффика по нескольким портам и это идет с них в порт аплинка - туда может лететь в итоге больше гигабита, которым нужно буферизироваться. Для этого нужно хорошо представлять работу ethernet, пакетную передачу и т.п. Вставить ник Quote
promSSe Posted May 31, 2012 Author Posted May 31, 2012 Просветите юношу, что такое бурст? Вставить ник Quote
nuclearcat Posted May 31, 2012 Posted May 31, 2012 К примеру средняя нагрузка на порт идет 100Мбит, но данные идут неравномерно, и в какие-то моменты времени канальная скорость - гигабит (т.е. минимальное временное расстояние между фреймами). Вставить ник Quote
f13 Posted June 1, 2012 Posted June 1, 2012 я tcam хватает? sh platform tcam utilization загрузка проца какая? Вставить ник Quote
promSSe Posted June 1, 2012 Author Posted June 1, 2012 Загрука проца в среднем 8% как в период обострения потерь так и в обычное время. По tcam криминала не вижу. CAM Utilization for ASIC# 0 Max Used Masks/Values Masks/values Unicast mac addresses: 400/3200 83/575 IPv4 IGMP groups + multicast routes: 152/1216 8/32 IPv4 unicast directly-connected routes: 400/3200 83/575 IPv4 unicast indirectly-connected routes: 1048/8384 27/166 IPv4 policy based routing aces: 384/512 3/4 IPv4 qos aces: 768/768 388/388 IPv4 security aces: 1024/1024 173/173 Note: Allocation of TCAM entries per feature uses a complex algorithm. The above information is meant to provide an abstract view of the current TCAM utilization Вставить ник Quote
avalone Posted June 1, 2012 Posted June 1, 2012 Апну тему. Хмм, по слайдам циски, 3750G стек реплицирует весь трафик (т.е даже между 2мя соседними портами в одном коммутаторе) через стековый кабель, у вас 16 гигов в сумме не бывает? И второе, насчет мультикаста, в первой версии (не 3750Х) мультикаст также проходил по стековому кабелю, даже если подписчики были в одном комамутаторе с аплинком. Если хочется подробностей, то посмотрите презу по 3750Х, там указываются ограничения первого (не Х) стека. Ну и есть отдельная презентация по траблшутингу в стеке 3750 юни- и мультикаста. (на ciscolive365) Вставить ник Quote
promSSe Posted June 1, 2012 Author Posted June 1, 2012 у вас 16 гигов в сумме не бывает? Каким образом можно посмотреть? Вставить ник Quote
avalone Posted June 2, 2012 Posted June 2, 2012 у вас 16 гигов в сумме не бывает? Каким образом можно посмотреть? show controllers utilization Но судя по выводу show platform port-asic stats у вас проблемы с Engress Queue. Прочитайте все же: http://www.ciscoexpo.ru/expo2011/downloads/materials/routing_switching/kgrigori_v4.pdf и на английском найдите: Troubleshooting Cisco Catalyst 2960, 3560 and 3750 Series Switches (BRKCRS-3141) это как раз по траблшутингу проблем 3750, в том числе с Engress Queues и Catalyst 3750 & 3560 Architecture (BRKARC-3437) для понимания ограничений самой архитектуры (переподписка, какие ASIC за какие порты отвечают) и т.д. Вставить ник Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.