Если у Вас стояла прошивка до и включительно R2.51 и Вы приняли решение обновить прошивку, то лучше советоваться с нами, Вам ни кто бы не посоветовал ставаить R2.52 или R.2.55, т.е. минимум версию 2.80.В35. Но сначала я бы уточнил причины. Это бы сэкономило время и нервы.



Более старшиве - это какие?

P.S.: И, пожалуйста, меньше эмоций и больше конкретики.

_________________
С уважением,
Бигаров Руслан.

у нас тоже всплыла проблема с arp, но при включении ф-й igmp_snooping и pim
viewtopic.php?f=2&t=138663&p=734648#p734648

В сети стоят несколько 3627G.
В последнее время частенько проявляется проблема с пропаданием ARP записей на коммутаторе.
Количество записей в fdb таблице чуть более тысячи. Коммутаторы у нас стоят в каждом микрорайоне, и почти на всех возникает данная проблема. Апгрейд прошивки ничего не дает. В данный момент стоят: Boot PROM Version Build 1.10-B09, Firmware Version Build 2.52.B45.
Один коммутатор проапргрейдили до Firmware Version Build 2.84.B11, но ситуация не изменилась.
Помогает простой Ping до абонента запущеный с самого коммутатора, но это не решение проблемы.
Как я понял, подобное не только у нас, но еще у многих других обладателей этого устройства.

Подскажите, есть какое либо решение этой проблемы? Что ещё можно предпринять?

Safeguard Engine = disabled
ACL есть только запрещающиее доступ к некоторым ip.
Dhcp не используется
Количество vlan = 40
Количество интерфейсов = 40
Каких либо особых настроек нет.

Неделю назад заменили один из DGS-3627G на DGS-3620-28SC - никаких улучшений. Ситуация с потерей записей в АРП таблице так же и осталась. В момент возникновения проблемы show fdb показывает боле 1300 записей, sh arpentry - менее тысячи. Запись в arp таблице появляется только после того как с коммутатора пустят пинг на абонента.

Около трех месяцев назад так же заменили один из DGS-3627G на Cisco Catalyst 3750-E, а к нему как L2 подключили существующий 3627G. Все настройки интерфейсов естественно перекинули на Циску. После чего данная проблема полностью исчезла. Всё работает отлично.

Отсюда вопрос к техподдержке Д-линка- Есть ли какое либо другое решение данной проблемы кроме как перейти на другого производителя?

Уважаемые, коллеги.

Вы случайно не замечали на свои сетях (c использованием DGS-3650/DGS-3527G) "гуляющий" TCP трафик, который явно не предназначался для хоста на котором запущен сниффер. То есть, если поймать пакет, и посмотреть IP SA и IP DA, так же MAC SA, MAC DA, то явно видно что это абонетский обмен не с вашим хостом (не броадкаст).

Случайно выловили, когда заметили что до 10mb/s трафика поступило на порт, где был выключенный хост, но с поднятым линком на сетевой плате.
При активном снифинге, зафиксировали трафик, из разрадя обмена TCP HTTP.

Когда, начали разбирать проблему, поставили фильтры в снифере, который показывал только пакеты паразитного TCP (не броадкастового) и выполнили clear fdb all, в снифере зафиксировали что паразитный TCP трафик приниматся перестал.

В момент проблемы на устройстве было:
- FDB: 4125;
- ARPENTRY: 1200;
- Firmware: 2.82.B20
- disable cpu_rx_rate_control все три уровня
- ARP AGING: 20

Есть такое. Бывает снифается трафик, который ну никак не должнен быть на прослушиваемом линке

Подтверждаю наличие такой же проблемы точь в точь 100% те же самые глюки с DGS-3620-28TC. Стояли три DES-3828, в которых использовались только гигабитные линки. Заменили на 3620, ругались нехорошими словами.

Субъективно стало еще хуже чем на DGS-3627, валится уже на 1000 записей в fdb. Теряет клиентов, теряет сервера, стоящие за ним, не пропускает пакеты и т.п. Совершенно не предсказуемый аппарат.

Хотим вернуть по гарантии или взять аппарат другого производителя. За два года утомили глюки 36-й серии. До сих пор вынуждены работать на 3828, которые реально работают.

А кто нибудь тестировал 3627 на коллизии маков. Очень похоже что это происходит.

_________________
D-Link User: DGS-3120-24, DGS-3324SR, DGS-3627G, DGS-3612G, DGS-3312SR, DGS-3100-24TG, DGS-3200-10, DES-3200-26, DES-3200-28, DES-3200-18, DES-3528, DES-3526, DES-3028, DES-1228, DES-2108, DES-2110, DES-3326SR, DMC-920, DMC-810.

И как вы это заметили? Насколько я помню, теоретическая возможность появления колизии в нём составляет 0,000125%.

По поводу ARP на 3627: его можно использовать как L3, но только в том случае, если таблица ARP будет маленькая, до 500 записей, например при роутинге брасов. Он отлично будет работать и не будет сбоить, и RIP, и OSPF, и PIM, и будет маршрутить на скоростях портов и даже не пукнет.
В случае же, если вы будете на нём терминировать абонентский L3 - он сдохнет 100%, это подтверждают очень многие.

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

Так что на больших L3 агрегациях юзаем кошечек, на малых можно и длинк. Не забывайте, что 3627 прекрасный свич как L2, вы врят-ли сможете найти что-то лучше.

Подписываюсь под каждым словом. Мы юзаем 3120-24SC набивая на все порты гигабитные оптики с домов, потом по 10 Гб/с портам 3 штуки 3120 сливаем в один 3627 по трем 10 Гб/с медным соединениям, а уже собрав в себя 3627, работающий как L2 и спокойно переваривающий в таком режиме 4000-6000 абонов онлайн раскладывает нагрузку между подлюченными к нему несколькими L3 и ядром сети.

Короче ситуация опять сводится к тому что 3620 - это тоже L2, который иногда можно применять как L3 (по опыту до 1300-1500 записей в arp таблице).

Мы понадеялись что в 3620 детские болезни гигабитного L3 от Dlink будут исправлены, а зря, но ничего. Мы поюзаем его как L2 ... у нас он не залежится, но слегка жалко выброшенных денег, зато SFP+ порты на 10 Гбит/с прогрузим в связках с DGS-3420 и районами.

Вердикт по гигабитным L3:

3627 - слабоват
3620 - еще слабее

Вердикт по гигабитным L3:

3627 - слабоват
3620 - еще слабее

+1
согласен, только знать бы это пред покупкой.
Чтобы не тратить кучу времени на борьбу с "ветряными мельницами" и выслушивания фраз типа: "что вы говорите, это только у вас проблема, никто больше не обращался"

Господа из D-link, вы что-то не очень комментируете ситуацию.
Не спорю цена не "циска", но все-таки немного честности в отношениях не повредит. Поэтому прошу, если не исправить описание характеристик оборудования, то хотя бы "прикрутить" тему в топ соответственно переименовав. А то, лично я, нашел ее слишком поздно.. ((

У меня была аналогичная проблема DGS-3620, полная загрузка процессора. После переноса л3 задач (а именно шлюза для сегмента итд) на 3610 (аплинк 10г) загрузка процессора 30%. То есть тот же трафик, но л2 пропускает без проблем.

Вы предлагаете комментировать голословные посты? Я не вижу конкретики. Где схема, конфиги, выводы отображающие проблему? На базе какой информации мы должны анализировать и исправлять проблему?!



У коммутатора DGS-3620 полно функций для защиты CPU, но L3 коммутаторы нужно защищать с помощью фильтрации клиентского трафика ещё на доступе используя ACL, IMPB, Traffic Control, QoS и т.д. и т.п. Только высокая загрузка CPU - это другая проблема.



Чтобы что-то признать, сначала нужно иметь конкретную информацию на руках, на базе которой можно сделать анализ и выводы. Когда мы получаем такую информацию, мы делаем всё, чтобы исправить проблему.

На моей практике был подобный случай с DGS-3627G, но там аппаратная проблема была, и как только исправили аппаратную проблему, проблема с потерей клиентов ушла сама собой. Также я рассматривал несколько случаев, когда с помощью L3 коммутаторов хотели решить недостаточность функционала на коммутаторах доступа.

P.S.: Не индусы нам пишут прошивки.

_________________
С уважением,
Бигаров Руслан.

Есть вопросы по теме.
Имеем подсеть, созданную между софтроутером (Debian) и 3627.
Все просто. Создан ВЛАН, в нем поднят интерфейс. Все работает.... до перезагрузки софтроутера.
Смотрим таблицу АРП
ARP Aging Time : 20

Interface IP Address MAC Address Type
------------- --------------- ----------------- ------------------
tgw 1.1.1.12 FF-FF-FF-FF-FF-FF Local /Broadcast
tgw 1.1.1.13 00-1E-58-D4-99-56 Local
tgw 1.1.1.14 00-1B-21-05-01-9D Dynamic
tgw 1.1.1.15 FF-FF-FF-FF-FF-FF Local /Broadcast

вроде все на месте, но не работает. Удаляем
delete arpentry 1.1.1.14
И все снова работает.
Другой момент.
Есть подсеть (ВЛАН) с устройствами MOXA. В подсеть просто идет пинг. Не могу сказать по какой причине, но происходит следующее: внутри подсети через 3627, на котором и создан интерфейс в этот ВЛАН, устройство пингуется, а с другой подсети - нет. Удаляем арпэнтри устройства и все снова работает. Как локализовать проблему? Вот я перепробовал уже все варианты. Остановился пока на том, что задрал arp_aging time до предела (второй случай).
Есть еще более смешной случай. Сменил адаптер на серваке и после этого только на одном из 3627 из 9ти штук никак не появляется запись сервера в арпэнтри. Т.е. клиенты, котрые сидят за этим 3627 не видят сервак. Спасает только статика. Сомневаюсь, что это нормально.
Что нужно посмотреть и какие данные предоставить, чтобы решить эти проблемы?

tgw 1.1.1.14 00-1B-21-05-01-9D Dynamic - это чья ARP запись? И как выглядит ARP таблица, когда всё нормально работает?



Как обычно:
1. Подробная схема с портами и ипами
2. Конфигурационные файлы
3. Описание с выводами отображающими проблему и если есть решение, то и описание решения.

_________________
С уважением,
Бигаров Руслан.

tgw 1.1.1.14 00-1B-21-05-01-9D Dynamic
это интерфейс софтроутера, который смотрит во влане в сторону интерфейса 3627. там больше нет никого.
В том -то и дело, что арп-таблица так же и выглядит. Это и ставит в тупик...