[alibek]

Есть такой коммутатор:

  SNR-S2960-48G Device, Compiled on Jan 06 10:04:51 2013
  SoftWare Version 6.2.139.142
  BootRom Version 4.10.4
  HardWare Version R01

Конфигурация, в общих чертах, следующая:

!
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 407
!
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
access-list 6011 permit ip any-source 224.0.0.0 0.0.0.255
access-list 6011 permit ip any-source 239.0.0.0 0.255.255.255
access-list 6011 deny ip any-source any-destination
!
ip access-list standard ACCESS_ADMIN
  permit 10.1.100.0 0.0.0.255
  permit 10.1.128.0 0.0.0.255
  permit 10.1.144.0 0.0.0.255
  deny any-source
  exit
!
multicast destination-control
pppoe intermediate-agent
pppoe intermediate-agent format circuit-id ascii
pppoe intermediate-agent format remote-id ascii
mls qos
!
int eth0/0/1-48
 ip multicast destination-control access-group 6010
 sw access vlan 407
 sw association multicast-vlan 60
 pppoe intermediate-agent
 pppoe intermediate-agent vendor-tag strip
 loopback-detection specified-vlan 400-499
 loopback-detection control block
 igmp snooping drop query
!
...
!
int eth0/0/49
 flow control
 ip multicast destination-control access-group 6011
 sw mode trunk
 sw trunk allowed vlan 10;60;300-499;800-999
 pppoe intermediate-agent
 pppoe intermediate-agent trust
!
...
!
int Vlan10
 ip address 10.1.12.204 255.255.255.0
!
ip igmp snooping
ip igmp snooping vlan 60
ip igmp snooping vlan 60 immediately-leave
ip igmp snooping vlan 60 query-interval 60
!
ip default-gateway 10.1.12.250
!
sntp server 10.1.128.11
!
no login
!
isolate-port group ACCESS sw int eth0/0/1-48
isolate-port group ACCESS sw int eth0/0/50-52

На коммутаторе существенные проблемы с IPTV по мультикасту.

Вчера сняли дамп зеркала с абонентского порта и я в дампе увидел кучу постороннего трафика:

- STP, BPDU (ну это еще ладно)

- ARP-пакеты с VLAN 10

- ARP-пакеты с VLAN 902

- часть TCP-трафика с VLAN 902 (retransmit)

- DHCP с чьего-то абонентского роутера (ну это тоже ладно, тут я знаю, что искать)

 

Откуда в абонентском порту может взяться посторонний ARP?

Даже если изоляция портов по каким-то причинам не сработала (например где-то по ветке ее забыли настроить на транзитных коммутаторах), то VLAN 407 и VLAN 902 никак и нигде не пересекаются.

[ShyLion]

ПО оооооочень древнее у вас. Ну просто совсем мамонт. Щас придет саппорт и первым делом отправит на data.nag.ru

[alibek]

На data.nag.ru сайте для S2960-48G особо свежих прошивок и нет.

[Victor Tkachenko]

alibek, хоть последняя доступная версия ПО для SNR-S2960-48G уже довольная старая, обновить все же стоит.

 

23 часа назад, alibek сказал:

 

Откуда в абонентском порту может взяться посторонний ARP?

Нужно видеть сам дамп, понимать как он собирался и иметь схему всей сети.

У кадра в дампе было поле 802.1Q с указанными тегами или такой вывод сделан по искомому ARP-запросом IP-адресу?

 

23 часа назад, alibek сказал:

На коммутаторе существенные проблемы с IPTV по мультикасту.

Мультикаст выделен в приоритетную очередь?

[alibek]

1 час назад, Victor Tkachenko сказал:

У кадра в дампе было поле 802.1Q с указанными тегами или такой вывод сделан по искомому ARP-запросом IP-адресу?

По содержимому.

Порт access, тэгов в дампе нет.

В порт 23 был подключен абонентский маршрутизатор с IPTV-приставкой, в порт 24 был подключен ноутбук со сниффером, на коммутаторе было настроено зеркало с порта 23 в порт 24.

В моменты, когда на приставке были проблемы с IPTV, в дампе очень много ARP-запросов. Исходя из содержимого этих запросов (IP-адресов) это запросы устройств в VLAN 902.

Но VLAN 902 транзитом проходит до ядра и нигде не соединяется с абонентской сетью, это изолированный VLAN, в котором работают IP-камеры.

 

1 час назад, Victor Tkachenko сказал:

Мультикаст выделен в приоритетную очередь?

Где-то да, где-то нет.

Но утилизация аплинков не доходит даже до 50%.

[Victor Tkachenko]

1 час назад, alibek сказал:

В моменты, когда на приставке были проблемы с IPTV, в дампе очень много ARP-запросов. Исходя из содержимого этих запросов (IP-адресов) это запросы устройств в VLAN 902.

Но VLAN 902 транзитом проходит до ядра и нигде не соединяется с абонентской сетью, это изолированный VLAN, в котором работают IP-камеры.

Уверены, что эти ARP-запросы прилетали именно в клиентский порт 23, а не прямо в 24 порт анализатора? Как он был настроен?

Если на вышестоящем коммутаторе используется QinQ, то не исключено, что так и было.

Так или иначе трафик не мог просто просочиться из одного vlan в другой.

 

9 минут назад, alibek сказал:

Где-то да, где-то нет.

Но утилизация аплинков не доходит даже до 50%.

Повышенная утилизация может быть очень кратковременна и незаметна на графиках.

Затрагивали это в другой теме недавно.

[alibek]

1 час назад, Victor Tkachenko сказал:

Уверены, что эти ARP-запросы прилетали именно в клиентский порт 23, а не прямо в 24 порт анализатора?

Да.

1 час назад, Victor Tkachenko сказал:

Как он был настроен?

monitor session source, monitor session destination

1 час назад, Victor Tkachenko сказал:

Так или иначе трафик не мог просто просочиться из одного vlan в другой.

Поэтому я очень удивился, увидев эти пакеты в зеркале абонентского порта.

1 час назад, Victor Tkachenko сказал:

Повышенная утилизация может быть очень кратковременна и незаметна на графиках.

Проблемы с IPTV постоянные, а не разовые, на графиках это бы проявилось.

[Victor Tkachenko]

alibek, имелся конфиг непосредственно порта 24. Даже если он указан как monitor session destination, это еще не значит, что он не участвует во всем остальном.

Но несмотря на то, в какой порт именно пришли эти ARP-запросы, остается факт, что если бы они пришли в другом vlan, то они не могли бы попасть в порт 23. То есть скорее всего они попали в клиентский vlan (или vlan, в котором был порт 24) в другой точки коммутатора/сети.

 

15 минут назад, alibek сказал:

Проблемы с IPTV постоянные, а не разовые, на графиках это бы проявилось.

На картинке вы увидите усредненный показатель (скорее всего за минуту). Если возникают регулярные микровсплески продолжительностью менее секунды, на графике это никак не отразится, так как объемы данных за секунду/минуту/час суммарно передаются те же.

Если мультикаст здесь не выделен в приоритетную очередь, стоит начать именно с этого.

[alibek]

4 минуты назад, Victor Tkachenko сказал:

Даже если он указан как monitor session destination, это еще не значит, что он не участвует во всем остальном.

Обычно назначение monitor destination полностью отключает любые настройки интерфейса, во всяком случае это справедливо для Cisco и Extreme.

То есть нужно полностью убирать конфигурацию с порта перед снятием зеркала?

 

5 минут назад, Victor Tkachenko сказал:

То есть скорее всего они попали в клиентский vlan (или vlan, в котором был порт 24) в другой точки коммутатора/сети.

Это более объяснимо. Но разве я бы в этом случае не обнаружил MAC-адреса в абонентском VLAN?

Например в аттаче дамп одного из таких пакетов.

Если бы где-то была неверная коммутация, разве я бы не обнаружил MAC-адрес 00:25:c3:6e:3e:c7 просто в абонентском VLAN по команде sh mac-address-table vlan 407?

 

 

13 минут назад, Victor Tkachenko сказал:

Если мультикаст здесь не выделен в приоритетную очередь, стоит начать именно с этого.

Ок.

[Victor Tkachenko]

38 минут назад, alibek сказал:

Но разве я бы в этом случае не обнаружил MAC-адреса в абонентском VLAN?

MAC-адрес должен был появиться в FDB. Возможно он все же прилетал не в этот vlan, а в тот, в котором находился порт 24.

[alibek]

Порт 24 настроен точно так же, как порт 23, согласно конфигурации в первом сообщении.

[agach]

приятно осозновать, что вовремя ушли от мультикаста. много тратилось времени админов и техподдержки на отлавливание всевозможных глюков и вообще на переваривание мультикаста в сети. 

[alibek]

А какое отношение имеет мультикаст к описанной проблеме?