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

Взяли на тест dlink 3620-28SC,
та же болезнь, что и у dgs-3627 о которой писалось в
viewtopic.php?f=2&t=150771

В режиме L2 на cpu попадает трафик с транзитных vlan, проц. умирает то ли от arp в них то ли ещё от чего.
То что это проблема существует реально, читайте вот это:
http://forum.nag.ru/forum/index.php?sho ... t&p=764148

Предложенный для DGS cpu_rx_rate_control - это не куда не годный костыль не решающий проблему.
Так как он срабатывает, ограничивая по скорости как вредные так и нормальные пакеты, которые должны обработаться на CPU.
Правильно чтобы CPU коммутатора не пытался обрабатывать трафик абсолютно ему не предназначенный.

Вопрос планирует ли DLINK решать данную проблему для новых 3620-28SC?

IGMP Snooping или DHCP relay случаем не включены?
просто никогда у себя не встречал такого, тоже давно юзаем 3627 и ему подобные

Да, всё выключено.

up.

как леер 3 - работает - чисто как гигабитный роутер L3 - проблем не было на последней прошивке
как L2 тоже пока устраивает
сейчас хотим поднять на нём PIM-SM и посмотреть как каналы будут переключаться

По поводу данной проблемы (обработка пакетов в транзитном влане) я уточнял у специалистов Длинк. Они эту проблему не подтверждают.
Сейчас взял на тест эту железку, могу протестить. Просьба описать схему при которой наблюдалась проблема.

Если бы её тут выложили....Тоже слышал о проблеме, но нету механизма как её повторить

Юзаем 3627 уже давно, подобной проблемы не наблюдаем.
Вообще беспроблемный свич, если используется как L2 (транзит), как L3 немного с ARP косячит, но терпимо.

Теряет АРП записи? Сколько нормально жует? Сколько VLAN терминирует? Сколько сетей поднято? Какая загрузка по другим задачам?

подобная проблема у меня была с 3120 - cpu умирал при использовании pppoe insertion на магистральном порту и если у клиента стояла новая голосвая железка с SFP портом - но это не из-за броадкаста

Нет, иногда у него из-за определённой фазы луны переполняется буфер ARP и он перестаёт маршрутизировать некоторые IP интерфейсы, а иногда и некоторые МАС-адреса, лечим clear arp.
Жует - в смысле? Если с АРП всё в порядке - жуёт на скорости порта.

Маленький L3: 3612G: IPIF: Total Entries : 13, ARP: Total Entries: 197, FDB Total Entries: 771
Вот с этим иногда возникают проблемы, походу дела из-за ARP спуфинга - перестаёт маршрутить какой-либо IP интерфейс, лечим всё так-же clear arp

Есть ещё агрегационный L2 3627G: 100 вланов, 4 ip интерфейса, ARP 45 шт, FDB Total Entries: 4307, igmp_s gr: Total Entries : 74

Ни тот, ни другой никогда не имели проблем с CPU 100%, никогда не видел такого на этой серии свичей.

3612G: IPIF - Total Entries : 151, ARP: Total Entries: 915; FDB: 1205

Не жалуемся

Создаём любую vlan, прописываем untaged'ом на любой порт ну например на 23.
Подключаем к порту 23, компьютер и запускаем вот такую программу на python'e,
она генерит ARP, Request who-has 192.168.43.12 tell 192.168.43.122, length 28, смотрим загрузку CPU.


#!/usr/bin/python -OO
# -*- coding: utf-8 -*-
# coding: utf-8

#http://stackoverflow.com/questions/3789954/software-to-generate-false-arp-requests

import socket
import struct

#ARP, Request who-has 192.168.43.12 tell 192.168.43.122, length 28
#Packet structure explanation:
#destmac = 0xff,0xff,0xff,0xff,0xff,0xff
#sourcemac = 0x00,0x11,0x22,0x33,0x44,0x55
#etherflags = 0x0806,0x0001,0x0800
#arpflags = 0x6,0x4,0x0001
#sourcemac = 0x00,0x11,0x22,0x33,0x44,0x55
#sourceip = 0xc0,0xa8,0x2b,0x7a
#targmac = 0x00,0x00,0x00,0x00,0x00,0x00
#targip = 0xc0,0xa8,0x2b,0x0c

interface='eth0'

packet = struct.pack('!12B3H2BH10B10B', 0xff,0xff,0xff,0xff,0xff,0xff, 0x00,0x11,0x22,0x33,0x44,0x55, 0x0806,0x0001,0x0800, 0x6,0x4,0x0001 ,0x00,0x11,0x22,0x33,0x44,0x55, 0xc0,0xa8,0x2b,0x7a, 0x00,0x00,0x00,0x00,0x00,0x00, 0xc0,0xa8,0x2b,0x0c)

sock = socket.socket(socket.PF_PACKET, socket.SOCK_RAW)
sock.bind((interface, 6)) # 6 its protocol number
while True:
sock.send(packet)
sock.close()

Протестил железку скриптом.
Switch#show version
System MAC Address: FC-75-16-B1-60-00
Unit ID Module Name Versions
------- ------------------ ---------------------
1 DGS-3620-28SC H/W:A1
Bootloader:1.00.016
Runtime:1.50.R028
Switch#show vlan 500
VLAN 500
Name : arp-vlan-test
Tagged Member Ports :
Untagged Member Ports : 1/0/24
Total Entries : 1
Switch#show cpu utilization
CPU Utilization
Five seconds - 8 % One minute - 9 % Five minutes - 9 %
Switch#

После запуска вышеприведенного теста на одном компе
Switch#show cpu utilization
CPU Utilization
Five seconds - 20 % One minute - 11 % Five minutes - 9 %
Switch#
При этом с интерфейса в сторону свича летит 268369 пакетов в сек. (смотрел по количеству отправленных с интерфейса пакетов за 30 сек)
Switch#show interfaces utilization
Port TX packets/sec RX packets/sec Utilization
------------- ----------------- ----------------- -----------
...
eth1/0/22 0 0 0
eth1/0/23 0 251076 8 <-------------------- arp_gen1
eth1/0/24 0 265478 9 <-------------------- arp_gen2

Загрузка свича увеличивалась на 10-11%.
Подключил второй комп, запустил генератор загрузка не увеличилась. Для проверки выключил первый оставил второй - загрузка CPU все таже 20%.
Свич при этом был нормально доступен по ip, консоль не тормозила.

Switch#debug show cpu port (пропускал строки с нулями)

Type PPS Total Drop
-------------------------------- ---------- ----------- -----------
Unknown-IPv4-IPMC 0 29 29
ARP 0 6 2
ICMP 0 15 0
Telnet 1 1952 0
UDP-Helper 0 5847 4

Switch#

Создал SVI c ID VLAN 500, поднял на нем IP. Запускаю генератор, CPU выше 20 % не поднимается

НО один баг обнаружен. Если на консоли свича ничего не делать - она отваливается. Проходит 5 или более минут. Далее Запускаю arp генератор с двух компов. То опа! Если попытаться зайти на свич - ping не работает, телнет тоже. Отключив ОБА генератора свич пустил телнетом,

Удалил SVI с 500 vlan. Повторил тесты, свич стал недоступен. Отключив ОДИН генератор свич пустил телнетом.

Такое ощущение что если на свиче не сидеть все время, то арп запись протухает для хоста с которого шло управление и после когда повалился arp dos 520 kpps arp запросы c компа с которого я заходил просто отбрасывались - возможно штром контрол свича его рубил. Хотя хост с которого заходил был в другом vlan, шторм шел в 500 и 501 влан. Но почему рубился arp трафик порта с которого я заходил а не портов в 500 и 501 вланах на которых работали arp генераторы - это вопрос к разработчикам.

Вопрос к d_a_nikulin Так должно быть ? Хотя такое количество арп ненормально для сети - широковещание надо резать на акцессе.
PS