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

SNR-S2985G-8T ошибки у клиента при QinQ

Здравствуйте!

 

Включен QinQ на клиентском порту.

Гоняется телевидение

Клиент жалуется на ошибки.

Но на портах своего коммутатора мы ошибок не наблюдаем, единственное растет счетчик: " 8490 pause frame " на этом порту.

Вот пишет нам клиент:   " Это не ошибки которые вы можете зафиксировать на порту(Типа CRC, undersize, length error и тд), у клиента проблема наблюдается с ошибками по его транспортному потоку, так называемые СС Error(часть пакетов в mpeg стриме пропадает)."

 

В какую сторону покопать?

 

SNR-S2985G-8T#sh ver
  SNR-S2985G-8T Device, Compiled on May 16 10:56:37 2019
  sysLocation Building 57/2,Predelnaya st, Ekaterinburg, Russia
  CPU Mac f8:f0:82:77:db:95
  Vlan MAC f8:f0:82:77:db:94
  SoftWare Version 7.0.3.5(R0241.0308)
  BootRom Version 7.2.40
  HardWare Version 1.1.2
  CPLD Version N/A
  Serial No.:SW070911I105001289
  Copyright (C) 2019 NAG LLC
  All rights reserved
  Last reboot is warm reset.
  Uptime is 0 weeks, 0 days, 18 hours, 10 minutes
SNR-S2985G-8T#sh run
!
no service password-encryption
!
hostname SNR-S2985G-8T
sysLocation Building 57/2,Predelnaya st, Ekaterinburg, Russia
sysContact support@nag.ru
!
!
!
!
!
!
!
!
!
!
!
mtu 1600
!
!
vlan 1
!
vlan 90
 name MANAGEMENT
!
vlan 1013
 name RTPC
!
vlan 1714
 name RTPC-2
!
Interface Ethernet1/0/1
 description FSB
 switchport access vlan 1714
!
Interface Ethernet1/0/2
!
Interface Ethernet1/0/3
!
Interface Ethernet1/0/4
!
Interface Ethernet1/0/5
!
Interface Ethernet1/0/6
!
Interface Ethernet1/0/7
!
Interface Ethernet1/0/8
 description MANAGEMENT
 switchport access vlan 90
!
Interface Ethernet1/0/9
 description RTPC
 dot1q-tunnel enable
 switchport access vlan 1013
!
Interface Ethernet1/0/10
 description UpLink
 switchport mode trunk
 switchport trunk allowed vlan 90;1013;1714
!
interface Vlan90
 ip address 172.16.3.102 255.255.255.0
!
!
no login
!
captive-portal
!
end

 

на этом порту они сидят:

Interface brief:
  Ethernet1/0/9 is up, line protocol is up
  Ethernet1/0/9 is layer 2 port, alias name is RTPC, index is 9
  Hardware is SFP,  address is f8-f0-82-77-db-95
  PVID is 1013
  MTU 1600 bytes, BW 1000000 Kbit
  Time since last status change: 0w-0d-0h-21m-2s   (1262 seconds)
  Encapsulation ARPA, Loopback  not set
  Auto-duplex :  Negotiation  full-duplex,  Auto-speed :  Negotiation  1G bits
  FlowControl is off,  MDI type is auto
Statistics:
  5 minute input rate 10175769 bits/sec, 865 packets/sec
  5 minute output rate 150984727 bits/sec, 14573 packets/sec
  The last 5 second input rate 10178570 bits/sec, 854 packets/sec
  The last 5 second output rate 150785854 bits/sec, 14735 packets/sec
  Input packets statistics:
    54375499 input packets, 82006581890 bytes, 8490 no buffer
    54305696 unicast packets, 46610 multicast packets, 23193 broadcast packets
    0 input errors, 0 CRC, 0 frame alignment, 0 overrun, 0 ignored,
    0 abort, 0 length error, 0 undersize 0 jabber, 0 fragments , 8490 pause frame
  Output packets statistics:
    936817212 output packets, 1216483000109 bytes, 0 underruns
    27682487 unicast packets, 897690470 multicast packets, 11444255 broadcast packets
    0 output errors, 0 collisions, 0 late collisions , 0 pause frame
  Input and output packets by length:
(64)        bytes:  27684494, (65~127)    bytes:  12306873, 
(128~255)   bytes:   2562876,  (256~511)   bytes:   8155084, 
(512~1023)  bytes:    106742, (1024~1518) bytes: 886511513 
  Output packets dropped because of no buffer: 0

 

 

Share this post


Link to post
Share on other sites
14 минут назад, maverick5 сказал:

растет счетчик: " 8490 pause frame " на этом порту. 

Судя по этому, со стороны клиента на порту включен и срабатывает FlowControl.

Сам с трансляцией видео дела не имел, но КМК это может вызывать задержки в передаче потока, а может и переполнение буфера во время "паузы в передаче".

Share this post


Link to post
Share on other sites
В 22.05.2019 в 09:32, azhur сказал:

Судя по этому, со стороны клиента на порту включен и срабатывает FlowControl.

Сам с трансляцией видео дела не имел, но КМК это может вызывать задержки в передаче потока, а может и переполнение буфера во время "паузы в передаче".

Да, так и было. Выключили FC. Счетчик pause frame  - по нулям стал.

Будут тестировать канал, может и потери пакетов в стриме пропадут

Share this post


Link to post
Share on other sites

@maverick5 
В случае, если у Вас на порте FC отключен, коммутатор должен игнорировать полученные pause frame, поэтому отключение FC со стороны клиента вряд ли решит проблему. Но отправка клиентом pause frame само по себе является симптомом, нужно понять, по какой причине клиент шлет данные пакеты.

Share this post


Link to post
Share on other sites
10 часов назад, Aleksey Sonkin сказал:

@maverick5 
В случае, если у Вас на порте FC отключен, коммутатор должен игнорировать полученные pause frame, поэтому отключение FC со стороны клиента вряд ли решит проблему. Но отправка клиентом pause frame само по себе является симптомом, нужно понять, по какой причине клиент шлет данные пакеты.

Сегодня-завтра потестируют канал - ответят. Может еще и не в этом причина...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this