megahertz0 Опубликовано 31 января, 2014 (изменено) · Жалоба Есть две диски - шеститонник (sup 720 + ws-x6748) и каталист 3550-12G. С шеститонника на 3550 смотрит gi1/6, на 3550 принимается на gi0/4 и отдается на gi0/11. Теряются пакеты udp между шеститонником 3550. На шеститоннике делаем порт акцесом, загоняем туда 50 мегабит udp iperf-ом, с другой стороны втыкаюсь ноутом в медный порт 3550-12G gi0/11 в том же влане (правда 100-мегабитной карточкой). В итоге процент потерь - 0,5-2%. Свитчи соединены 1G-линком. Линия километра 3. Патч-корды заменили, SFP и GBIC заменили. Разве что линию рефлюком не мерил т.к. надо делать перерыв связи. Весь QoS выключил на 3550 (no mls qos), на портах output drop и т.д. нет. Трафика кроме этого мегабит 30. Вот что sh int говорит на 3550: 3550.Acc#sh int gi0/4 GigabitEthernet0/4 is up, line protocol is up (connected) Hardware is Gigabit Ethernet, address is 000c.3039.3e84 (bia 000c.3039.3e84) Description: C6K-Msk20 MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 2/255, rxload 30/255 Encapsulation ARPA, loopback not set Keepalive not set Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseLX input flow-control is off, output flow-control is off ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, 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 121162000 bits/sec, 13378 packets/sec 5 minute output rate 8796000 bits/sec, 3343 packets/sec 67434099 packets input, 1360323889 bytes, 0 no buffer Received 50067790 broadcasts (0 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 49594222 multicast, 0 pause input 0 input packets with dribble condition detected 16918228 packets output, 3241445082 bytes, 0 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 0 output buffer failures, 0 output buffers swapped out 3550.Acc#sh int gi0/11 GigabitEthernet0/11 is up, line protocol is up (connected) Hardware is Gigabit Ethernet, address is 000c.3039.3e8b (bia 000c.3039.3e8b) Description: SNR.Access MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 29/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, link type is auto, media type is 10/100/1000BaseTX input flow-control is off, output flow-control is off ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, 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 5 minute input rate 527000 bits/sec, 798 packets/sec 5 minute output rate 114861000 bits/sec, 10861 packets/sec 2222015 packets input, 1001377693 bytes, 0 no buffer Received 50777 broadcasts (0 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 34408 multicast, 0 pause input 0 input packets with dribble condition detected 59669927 packets output, 1608235651 bytes, 0 underruns 0 output errors, 0 collisions, 2 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out И вот что на шеститоннике cgw130#sh int gi1/6 GigabitEthernet1/6 is up, line protocol is up (connected) Hardware is C6k 1000Mb 802.3, address is 0021.d874.3d75 (bia 0021.d874.3d75) Description: 3550.Trunova MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 34/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is LH input flow-control is off, output flow-control is off Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:47, output 00:00:14, output hang never Last clearing of "show interface" counters never Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 1 minute input rate 6712000 bits/sec, 3432 packets/sec 1 minute output rate 133379000 bits/sec, 14351 packets/sec 79711913 packets input, 26001745052 bytes, 0 no buffer Received 107273 broadcasts (58576 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 286326178 packets output, 316089691854 bytes, 0 underruns 0 output errors, 0 collisions, 3 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out cgw130# Самое интересное, что tcp iperfом разгоняется до 100 мегабит нормально. Загадка, в общем.... Изменено 31 января, 2014 пользователем megahertz0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 31 января, 2014 · Жалоба Ну а какие-то проявления этого есть? Ну там жалобы игроков, например. iperf мимо цисок таких потерь не дает между 1Г - 100мбит? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
megahertz0 Опубликовано 31 января, 2014 · Жалоба Там игроков нет, там мультикаст с камер ходит. Собственно проявляется в том, что картинка сыпется. Да, волокно промерили - с затуханием все в порядке. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stranger2904 Опубликовано 1 февраля, 2014 · Жалоба А порты есть возможность поменять ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
megahertz0 Опубликовано 2 февраля, 2014 (изменено) · Жалоба Порты и трансиверы меняли. В общем, есть подозрение на кривой софт у клиента. Ну и кривых измерителей с иперфом. Поставил буфер приема в 64к, влил 90 мбит трафика - потерь нет вообще. Т.е. мультикаст до них доходит, но при этом происходит переполнение буфера приема, а потому и дропы. Изменено 2 февраля, 2014 пользователем megahertz0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zurz Опубликовано 2 февраля, 2014 · Жалоба а у этого клиента камеры никакими D-Link-ами не агрегируются? проблемы с хэшами и мультикастом у которых? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SMSI Опубликовано 3 февраля, 2014 · Жалоба Что за камеры и что за софт у клиента? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
megahertz0 Опубликовано 3 февраля, 2014 · Жалоба Что за камеры и что за софт у клиента? ХЗ что у них там, мы просто забираем мультикаст по l2 и прогоняем до узла клиента. Но учитывая тот факт, что на узлах у заказчика стоит windows server, думаю, что там все как-то печально. а у этого клиента камеры никакими D-Link-ами не агрегируются? проблемы с хэшами и мультикастом у которых? Нет, они мультикаст забирают с объектов прямо в свои софтовые тазики. Терминируется все на каталисте 4506 по-моему. Мегабит 150 в сумме. К стати, как выяснилось в личной беседе, софт для стриминга у них устроен очень интересным образом. Если обычно мультикаст вещается ровным потоком с некоторыми всплесками ну в 10-15% от сумарного битрейта, то эти ребята буферизируют принятый мультикаст, а затем пачками его сливают раз в несколько секунд. Зачем - неизвестно. Поэтому получаются нехилые всплески трафика, которые зачастую в приемный буфер свитча могут не попасть. Короче супердизайн софта или криворукие разработчики. По-хорошему после каждого такого стримера надо ставить шейпер, который бы выравнивал всплески за счет могучего буфер приема/передачи... В общем, умом Россию не понять. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 3 февраля, 2014 · Жалоба Затем, чтобы проц не грузить ерундой, а тут просто по таймеру отправка. Про нюансы л2 ребята не в курсе, так бы на тцп ушли. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...