[alibek]

Некоторое время назад вдруг массово начались какие-то проблемы с коммутаторами SNR-S2960-48G.

ПО на них с 6 ветки (например 6.2.138.121).

Конфигурация такая:

!
loopback-detection interval-time 60 5
loopback-detection control-recovery timeout 60
loopback-detection trap enable
!
vlan 1;300-499;800-999 
!
vlan 10
 name MGMT
!
vlan 1000
 name STUB
!
vlan 60
 name IPTV
 multicast-vlan
 multicast-vlan association 400-499
!
firewall enable
!
access-list 6010 permit ip any-source 224.0.0.0 0.0.0.255
access-list 6010 permit ip any-source 239.0.0.0 0.0.255.255
access-list 6010 permit ip any-source 239.1.0.0 0.0.255.255
access-list 6010 permit ip any-source 239.195.0.0 0.0.255.255
access-list 6010 permit ip any-source 239.250.0.0 0.0.255.255
access-list 6010 deny ip any-source any-destination
!
mac-access-list extended pppoe
  permit any-source-mac 00-30-88-1c-00-00 00-00-00-00-ff-ff untagged-eth2 ethertype 34915
  permit any-source-mac 00-30-88-1c-00-00 00-00-00-00-ff-ff untagged-eth2 ethertype 34916
  permit any-source-mac 01-00-5e-00-00-00 00-00-00-ff-ff-ff
  permit 01-00-5e-00-00-00 00-00-00-ff-ff-ff any-destination-mac
  deny any-source-mac any-destination-mac
  exit
!
multicast destination-control
pppoe intermediate-agent
pppoe intermediate-agent format circuit-id ascii
pppoe intermediate-agent format remote-id ascii
mls qos
!
Interface Ethernet0/0/1-48
 ip multicast destination-control access-group 6010
 switchport access vlan 4xx
 switchport association multicast-vlan 60
 mac access-group pppoe in
 pppoe intermediate-agent
 pppoe intermediate-agent vendor-tag strip
 loopback-detection specified-vlan 400-499
 loopback-detection control block
 igmp snooping drop query
!
Interface Ethernet0/0/49-52
 ip multicast destination-control access-group 6010
 switchport mode trunk
 switchport trunk allowed vlan 10;60;300-499;800-999 
 pppoe intermediate-agent
 pppoe intermediate-agent trust
!
ip igmp snooping
ip igmp snooping vlan 60
ip igmp snooping vlan 60 immediately-leave
ip igmp snooping vlan 60 query-interval 60
!
isolate-port group ACCESS switchport interface ethernet0/0/1-48
isolate-port group ACCESS switchport interface ethernet0/0/50-52

Аплинк в порту 49, предоставляется PPPoE (VLAN 4xx) и IPTV (мультикаст-vlan 60).

Бывают жалобы на скорость, на проблемы с подключением (не с первого раза или долго), на разрывы.

Жалобы не постоянные, но и не разовые.

При этом жалобы в основном при случаях прямого подключения (непосредственно с ПК или ноутбука).

Если подключение производится через роутер, то обычно все подключается сразу.

 

Вчера ТП снимала тестовые дампы процесса подключения, абонент был подключен в порт 1, ноутбук ТП с Wireshark в порт 48.

ТП уверяет, что зеркало трафика было настроено правильно (source на порту 1, destination на порту 48) и проверялось командой show monitor.

Однако в дампе трафика абонентских пакетов менее 1%. Зато куча всего, что могло быть только на магистральном порту (трафик транзитных VLAN).

 

FDB-таблица выглядит так:

#sh mac-address-table count  
Compute the number of mac address....
Max entries can be created in the largest capacity card:
Total     Filter Entry Number is: 8192
Static    Filter Entry Number is: 8192
Unicast   Filter Entry Number is: 8192
Multicast Filter Entry Number is: 255

Current entries have been created in the system:
Total     Filter Entry Number is: 2120
Individual    Filter Entry Number is: 2120
Static    Filter Entry Number is: 405
Dynamic   Filter Entry Number is: 1715
Multicast(Insert) Filter Entry Number is: 1
Multicast(Wait) Filter Entry Number is: 0

Может быть так, что на коммутаторе сломалась собственно коммутация и он флудит во все порты?

Как это проверить?

[Victor Tkachenko]

@alibek, не исключаю на 100% подобного поведения, но архитектурно такое маловероятно и подобных случаев ранее не фиксировалось.

Обращаю внимание, что порт назначения зеркала не отключается от коммутации, возможно туда прилетал избыточный трафик не из зеркала.

[alibek]

Как туда мог прилететь обычный не широковещательный трафик?

Я в дампе видел трафик из VLAN 8xx; это выделенные линии для ЮЛ, на них статикой прописаны публичные IP-адреса. Они никак не могут случайно попасть на обычный абонентский порт.

[Victor Tkachenko]

@alibek, в зависимости от настроек туда мог прилететь BUM-трафик.

Рекомендую повторить эксперимент с зеркалом, поместив destination в отдельный vlan и убедившись что source выбран корректно. Если ситуация воспроизведется, соберите дамп без зеркала, настроив порт аналогично клиентскому, либо включившись непосредственно в клиентский порт.

 

С более подробным описанием проблемы затем стоит обратиться в support.nag.ru.