Jump to content
Калькуляторы

3550-12G потери udp

Есть две диски - шеститонник (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 by megahertz0

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Edited by megahertz0

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.