3550-12G потери udp

[megahertz0]

Есть две диски - шеститонник (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 мегабит нормально. Загадка, в общем....

Edited January 31, 2014 by megahertz0

[DVM-Avgoor]

Ну а какие-то проявления этого есть? Ну там жалобы игроков, например.

iperf мимо цисок таких потерь не дает между 1Г - 100мбит?

[megahertz0]

Там игроков нет, там мультикаст с камер ходит. Собственно проявляется в том, что картинка сыпется. Да, волокно промерили - с затуханием все в порядке.

[stranger2904]

А порты есть возможность поменять ?

[megahertz0]

Порты и трансиверы меняли. В общем, есть подозрение на кривой софт у клиента. Ну и кривых измерителей с иперфом. Поставил буфер приема в 64к, влил 90 мбит трафика - потерь нет вообще. Т.е. мультикаст до них доходит, но при этом происходит переполнение буфера приема, а потому и дропы.

Edited February 2, 2014 by megahertz0

[zurz]

а у этого клиента камеры никакими D-Link-ами не агрегируются? проблемы с хэшами и мультикастом у которых?

[SMSI]

Что за камеры и что за софт у клиента?

[megahertz0]

Что за камеры и что за софт у клиента?

ХЗ что у них там, мы просто забираем мультикаст по l2 и прогоняем до узла клиента. Но учитывая тот факт, что на узлах у заказчика стоит windows server, думаю, что там все как-то печально.

а у этого клиента камеры никакими D-Link-ами не агрегируются? проблемы с хэшами и мультикастом у которых?

Нет, они мультикаст забирают с объектов прямо в свои софтовые тазики. Терминируется все на каталисте 4506 по-моему. Мегабит 150 в сумме.

 

К стати, как выяснилось в личной беседе, софт для стриминга у них устроен очень интересным образом. Если обычно мультикаст вещается ровным потоком с некоторыми всплесками ну в 10-15% от сумарного битрейта, то эти ребята буферизируют принятый мультикаст, а затем пачками его сливают раз в несколько секунд. Зачем - неизвестно. Поэтому получаются нехилые всплески трафика, которые зачастую в приемный буфер свитча могут не попасть. Короче супердизайн софта или криворукие разработчики. По-хорошему после каждого такого стримера надо ставить шейпер, который бы выравнивал всплески за счет могучего буфер приема/передачи... В общем, умом Россию не понять.

[Ivan_83]

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

Про нюансы л2 ребята не в курсе, так бы на тцп ушли.