kev Опубликовано 28 февраля, 2018 · Жалоба Здравствуйте коллеги. Изменилась схема сети. Раньше домовые коммутаторы были подключены в Cisco 6509 по оптике 1G 6509 циску поменяли на C4948E + SNR-2990-24FX куда подключили домовые коммутаторы. После замены коммутатора Cisco 6509 SUP720 на Cisco C4948E возникли проблемы в виде output drops на коммутаторе 3550 на сети справа Так же output drops были на правой 6509 в сторону 4948. После того как 2Гбит/с поменяли на 10G дропы на этом линке исчезли. Причем все эти дропы ощущаются абонентами в виде потери пакетов, которые подключены к левой стороне сети где заменили оборудование . У Тех абонентов которые справа потерь пакетов нет. 3550#sh int Po2 Port-channel2 is up, line protocol is up (connected) Hardware is EtherChannel, address is 0017.e035.d483 (bia 0017.e035.d483) MTU 1500 bytes, BW 2000000 Kbit, DLY 10 usec, reliability 255/255, txload 177/255, rxload 35/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is 1000BaseLX input flow-control is off, output flow-control is on Members in this channel: Gi0/3 Gi0/4 ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output 00:00:00, output hang never Last clearing of "show interface" counters 05:27:25 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/0 (size/max) 5 minute input rate 278868000 bits/sec, 88839 packets/sec 5 minute output rate 1388392000 bits/sec, 142156 packets/sec 1282873162 packets input, 2060179784 bytes, 0 no buffer Received 2293 broadcasts (0 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 1441 multicast, 0 pause input 0 input packets with dribble condition detected 2268995540 packets output, 994889212 bytes, 6925295 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 6925295 output buffer failures, 0 output buffers swapped out Пакеты дропаются выборочно только для абонентов трафик которых маршрутизируется на Cisco 4948E. Такое ощущение что для для этих абонентов трафик летит в их сторону с большей скоростью и переполняется выходной буфер на 3550. Такое возможно? У кого нибудь есть мысли о причине подобного поведения. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
v_r Опубликовано 2 марта, 2018 · Жалоба В 2/28/2018 в 10:29, kev сказал: input flow-control is off, output flow-control is on Выключите flow control, возможно в этом проблема. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Telesis Опубликовано 2 марта, 2018 · Жалоба On 28.02.2018 at 6:29 PM, kev said: 6925295 underruns Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kev Опубликовано 5 марта, 2018 · Жалоба В 02.03.2018 в 03:36, v_r сказал: Выключите flow control, возможно в этом проблема. flow control выключен. Проблема не в нем Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
passer Опубликовано 5 марта, 2018 · Жалоба input flow-control is off, output flow-control is on совсем выключен, ага Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kev Опубликовано 5 марта, 2018 · Жалоба В 02.03.2018 в 11:12, Telesis сказал: проблему с переполнением output buffer получилось решить путем устранения etherchannel и распределения нагрузки путем PBR по получившимся в итоге отдельным гигабитным линкам. но дропы всё равно есть. 42 минуты назад, passer сказал: input flow-control is off, output flow-control is on совсем выключен, ага Да вы правы. Мы его выключали, потом снова включали. На примере он включен. Но на underruns и output buffer errors он никак не влиял. К тому же счетчики RxPause TxPause не росли. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
applx Опубликовано 5 марта, 2018 · Жалоба так они и будут, у вас разные скорости с обоих сторон... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kev Опубликовано 5 марта, 2018 · Жалоба 37 минут назад, applx сказал: так они и будут, у вас разные скорости с обоих сторон... все линки подключены на одинаковых скоростях. 1G к 1G 10G к 10G Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 5 марта, 2018 · Жалоба Тут речь про переходы между. Между бордером и 3550 сколько линк? И загрузка какая? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kev Опубликовано 5 марта, 2018 · Жалоба 2 минуты назад, zhenya` сказал: Тут речь про переходы между. Между бордером и 3550 сколько линк? И загрузка какая? сейчас два линка по 1G. Загрузка в пике чуть больше 90%. Но на 3550 уже нет ошибок после того как разбили etherchannel. За несколько суток накопилась статистика на 4948E на 10G портах которые смотрят на SNR-2990-24FX Tx-Drops-Queue-8 Te1/49 0 0 0 25309 Te1/50 0 0 0 27654 но сейчас счетчик не растет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 5 марта, 2018 · Жалоба Добавьте пару линков ещё и стрельнете больше 2 гиг или около того. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kev Опубликовано 5 марта, 2018 (изменено) · Жалоба 30 минут назад, zhenya` сказал: Добавьте пару линков ещё и стрельнете больше 2 гиг или около того. так то оно так. Но это не объясняет потери внутри сети. Даже при минимальной загрузке канала. На 500 пингов 4-5 потерь. Не понятно только где идут потери. Все счетчики ошибок на транзитном оборудовании по нулям а потери есть. PS: когда стоял 6509 таких проблем не было. Поставили 4948. Появились Изменено 5 марта, 2018 пользователем kev Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Telesis Опубликовано 6 марта, 2018 · Жалоба 15 hours ago, kev said: PS: когда стоял 6509 таких проблем не было. Поставили 4948. Появились Так и линк стал 10Г, соответственно бёрст стал чаще и больше. На 3550 буфера захлебнулись. Можно попробовать поиграться с QoS на 3550, но все равно это не на долго. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Butch3r Опубликовано 6 марта, 2018 · Жалоба 17 часов назад, kev сказал: Загрузка в пике чуть больше 90%. Это очень плохо, расширяйте емкость Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
applx Опубликовано 6 марта, 2018 · Жалоба 22 hours ago, kev said: все линки подключены на одинаковых скоростях. 1G к 1G 10G к 10G посчитайте с какой скоростью 10Г порт опустошит свой буфер и с какой 1Г? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kev Опубликовано 6 марта, 2018 · Жалоба 5 часов назад, Telesis сказал: Так и линк стал 10Г, соответственно бёрст стал чаще и больше. На 3550 буфера захлебнулись. Можно попробовать поиграться с QoS на 3550, но все равно это не на долго. Как я уже писал ранее ошибок переполнения буфера на 3550 не наблюдается. Путем тестирования выяснилось что потери идут на 4948. Причем только пакеты которые на ней маршрутизируются. Ошибок на интерфейсах 4948 тоже не наблюдается. Команда ниже показывает увеличивающиеся счетчики дропающихся пакетов. Но как диагностировать причину этих дропов не понятно. 4948#sh platform software drop-port Drop Port Software State Dequeue Enabled : True DropQueue Water mark Reg : 0x8000600038001D4C DropQueue Water mark Reg : 0x7FE32010 (Empty, PreEmpty, Head:0x1AD3, Tail:0x1AD3) DropActivityCount : 29673685024 DropOverrunCount : 0 Drop Event Reason Packets Dropped ----------------- --------------- SptDrop 231585735 InpL2AclDrop 1176372947 InpL3AclDrop 800703 UcastRpfDrop 165 BridgeToRxPortDrop 631980916575 rplErrDrop 49282223801 OutL3AclDrop 2941 OutPolicerDrop 239182969 TxQueFullDrop 71430653 DblDrop 5780140 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Telesis Опубликовано 6 марта, 2018 (изменено) · Жалоба 22 hours ago, kev said: Tx-Drops-Queue-8 Spoiler Queue 8 is the default queue with no QoS Configured Reduce tx-queue size OR Modify default queue size 23 minutes ago, kev said: 4948#sh platform software drop-port Spoiler BridgeToRxPortDrop - received in a vlan with no other ports, replicated to a floodset/entry where ingress port was a memberDblDrop - packets dropped by DBL (including DBL on CPU ports)rplErrDrop - broadcast/multicast packets dropped while being replicated, many normal reasons to increment, including: rpf failure, floodset containing drop port, packets replicated to the CPU but also bridged to a floodset/entry containing the CPUSptDrop - spanning-tree drop; packets dropped because a port is not in a forwarding stateSrcHitDrop - dropped at source learning stage; example: static MAC drop entryTxQueFullDrop - a tx port is oversubscribed Изменено 6 марта, 2018 пользователем Telesis Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kev Опубликовано 6 марта, 2018 · Жалоба 16 минут назад, Telesis сказал: Queue 8 is the default queue with no QoS Configured Скрыть содержимое BridgeToRxPortDrop - received in a vlan with no other ports, replicated to a floodset/entry where ingress port was a memberDblDrop - packets dropped by DBL (including DBL on CPU ports)rplErrDrop - broadcast/multicast packets dropped while being replicated, many normal reasons to increment, including: rpf failure, floodset containing drop port, packets replicated to the CPU but also bridged to a floodset/entry containing the CPUSptDrop - spanning-tree drop; packets dropped because a port is not in a forwarding stateSrcHitDrop - dropped at source learning stage; example: static MAC drop entryTxQueFullDrop - a tx port is oversubscribed А где нибудь можно ещё увидеть эти дропы. Может есть мануал по выяснению причин их возникновения. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Telesis Опубликовано 6 марта, 2018 · Жалоба Spoiler https://yadi.sk/i/j72AX9EV3T5XHe Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kev Опубликовано 6 марта, 2018 · Жалоба Быстро растут encapsulation failed. Может в этом проблема? 4948#sh ip traffic IP statistics: Rcvd: 70543 total, 38976 local destination 0 format errors, 0 checksum errors, 6140 bad hop count 0 unknown protocol, 0 not a gateway 0 security failures, 0 bad options, 26508 with options Opts: 0 end, 0 nop, 0 basic security, 0 loose source route 0 timestamp, 0 extended security, 0 record route 0 stream ID, 0 strict source route, 26508 alert, 0 cipso, 0 ump 0 other Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble 0 fragmented, 0 couldn't fragment Bcast: 2484 received, 785 sent Mcast: 23482 received, 8296 sent Sent: 28907 generated, 753 forwarded Drop: 23902 encapsulation failed, 0 unresolved, 0 no adjacency 0 no route, 0 unicast RPF, 0 forced drop 0 options denied, 0 source IP address zero Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 15 марта, 2018 · Жалоба Имхо загрузка 90% очень высока. Снижайте до 80%. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...