Плюсую, у меня было точно также! мак на другом порту. петли 100% нет.
Но сейчас уже такого нет, кокразтаки мак в последнее время вижу на нужном порту, но траффик начинает ходить только после чистки таблицы.

_________________
2008-2015г. компания Экстрим Интернет. Технический директор/Главный системный администратор.
2015-по н.в. компания "Подряд". Инженер сети ШПД

у нас DGS-3100 через некоторое время аптайма (около 100 дней) от некоторых клиентов(маков) начинает воспринимать приходящий на себя трафик как unicast flood, соот-но ограничивая исходящий трафик от таких клиентов до уровня unicast storm. Лечим также - сlear fdb all

По поводу вышеописанной ситуации с маком очень похоже что где-то дальше, за DGS-3100, за портом где "появляется" мак шлюза, хотя его там быть не должно, стоит что-нибудь вроде мыльницы 3200 с битым портом, из-за которого часть трафика с source_mac шлюза, улетающего с порта 3100 , заворачивается обратно на 3100. Это еще удачно, что вам видно мак шлюза на этом порту, мака шлюза там может и не быть, а симптомы будут похожие. Боремся с такой проблемой выключением из проблемного влана портов по очереди, выясняя какой косячит.. потом далее по цепочке.. и так доходим до конечного порта клиента. Включите на всех клиентских портах 3200 loopdetect, не забудьте включить его глобально, может полегчать. А лучше берите заместо 3200 серии - 1210-28, за место 3100-24 серии - 3120 (сорри за рекламу)

Если найдете подгорелые порты на 3200 - помните их недостаточно просто выключить - не поможет, их надо исключить из вланов.

static fdb запись на шлюз в таблице коммутации 3100 не поможет особо, потому как (happy!) трафик с source_mac других абонентов других портов тоже уходит на проблемный порт - броадкасты там, и прочее, и 3100 с удовольствием выучит на loopback порту, где петля, эти самые маки - трафик от шлюза до таких клиентов пойдет "налево" в порт где петля.

Helios, очень точно подмечено насчет битого порта. Действительно, несколько часов назад такой порт был обнаружен на 3028 достаточно далеко от 3100. Обнаружен был случайно, в ходе работ по модернизации. В битом 24-м порту ничего не было вставлено, однако свич по lldp обнаруживал там сам себя. Удалил статические записи с 3100 - интерфейс пока не отваливается. Даже не знаю, радоваться этому или нет, учитывая такую мелочь, что левый порт, где появлялись маки шлюза (и другие) - НЕ тот порт, за которым была обнаружена петля.

_________________
D-Link Switches: Tips & Tricks

Извините, что пропал, на то были обстоятельства.
В тот злополучный вторник когда ломали головы и перепроверяли все подряд помогло еще выключение Flow Control, при этом dgs мигнул портами и все наладилось. Относительно битых портов - это относительно новый район и там вообще не наблюдается проблемы с выгоранием портов. Ну и у нас на самих 3200 и 3526 очень жестко прописаны acl, по маку и апишнику. Но я там не в курсе что было дальше - попал на больничный.
А из всех раз когда такое встречалось один был особо запомнившимся, какая-то сетевушка сошла сума и отвечала на все arp запросы,и вилан сходил сума, но в данном случае все было по другому, тем более что за проблемным dgsом абоненты пинговали друг дружку, но дальше dgsа трафик не уходил.

Аналогичная проблема на DGS-3100-24. Через сутки-двое после clear fdb all коммутатор перестает использовать fdb для некоторых MAC-адресов. Всего в сети около 1000 MAC адресов. Замечено на прошивках 3.50.ХХ, 3.60.ХХ, вероятно, было и на 2.ХХ.

Временное решение - очистка fdb с сервера каждый час:

cat /etc/cron.hourly/clear-fdb-all.cron
#!/usr/bin/expect
spawn telnet 192.168.111.111
expect "UserName:" { send "admin\n" }
expect "Password:" { send "hf7gsf6sdr6f24\n" }
expect "DGS-3100#" { send "clear fdb all\n" }

Длинк проблему не признает ( но она есть.

snmpset -v2c -c коммунити айпи коммутатора .1.3.6.1.4.1.171.10.94.89.89.1.2.0 i 7
так красивее

коммутатор маки в таблице fdb не теряет, кстати, но трафик ОТ таких маков передает как uncast flood. Потому абоненты начинают жаловаться на нормальную входящую скорость и 0.08 Мбайта исходящую. Чем больше аптайм коммутатора тем таких абонентов проблемных больше. Рекомендую всем у кого есть длинк 3100-24 с агрегацией и с загруженным аплинком на мбит 600-700 и аптаймом месяца два и более зайти на коммутатор в тот момент когда он реально прокачивает мбит 600-650 и сделать clear fdb. Если снимаются графики вы четко увидите, что после этого коммутатор на ровном месте начнет давить все 800-850 мбит.

>> .1.3.6.1.4.1.171.10.94.89.89.1.2.0 i 7

Где найти информацию по этим командам?

Проблема так и не решена .

С недавних пор вылезла трабла на 3100-24TG как в этом топике - выборочно не пропускает юзеров в порядке возрастания количества непропускаемых, пример - есть 3100-24TG из него волокна на дома, на концах DES 1210-28 , в большинстве Гбитной колбаской еще 1-3 DES 1210-28 . Так вот у клиента пропадает инет , прихожу к нему - пинга на роутер-биллинг(Нодени) - нет, пинга на оборудование в серверной - нет, на свичи на других оптических магистралях - тоже нет, есть только на 3100-24TG , на свич куда клиент воткнут и на свичи на текущей оптической магистрали.Айпи-МАК клиент не менял. Короче выходит ,что ТГшка изолирует его на одном порту. Включаюсь ноутом - все пингуеться. ... Но через время таких трабл в сети выплывает все больше и больше , до полного отвала ТГшки на все магистрали. Временно помогает reset настроек всего и вся на ТГшке . . Включение всяческих антиштормовых фич не помогло. В сети около 400 юзеров, на ВЛАНы не разбито.Авторизация айпи+МАК.Loopback detection включено на всех 1210-28. Прошивка 3100-24ТГ последняя v3.60.38 .

Помогает clear fdb all ... но ведь это не выход. Надо скрипт для телнет винды или FreeBSD для очистки fdb каждый час. Как я понимаю выше указанный скрипт для Линукса. Д-Линк прошу наконец то разобраться с проблемой. спасибо

Проблему как-то удалось решить, у нас изредко проявляется тоже самое.

Можно подробнее про решение? Столкнулись с аналогичной проблемой, помогает только clear fdb all.
Может сотрудники Д-Линк что-нибудь посоветуют или прошивку новую пришлют (сейчас на свиче 3.60.37)?

Желательно ,чтоб в прошивке была галочка аля очищаться FDB автоматически каждые 5-60мин, елси уж другого решения придумать нельзя. Проблема с переполнением таблицы коммутации так и не решена... Интиресно в 3120-24SC тот же пирог...

Вопрос к сотрудникам Д-Линк - вы подтверждаете наличие данной проблемы?
Планируем закупать железо, теперь стоим перед выбором. Если эта проблема есть, то будете ли вы её решать?

Суммируя все вышесказанное: уточните, пожалуйста, на каких прошивках проблема присутствует и на каких ее не было. Возникает ли проблема при достижении какого-либо определенного количества MAC адресов в FDB, в часы пиковой загрузки или проявляется при любой нагрузке. Есть ли способ воспроизвести проблему на стенде?
2 gen PSI general, serstor На серии DGS-3120 жалоб по такого рода проблемам не поступало.

Я уже упомянул ,что прошивка прошивка 3100-24ТГ последняя v3.60.38 , очень сомневаюсь,что на приведущих прошивках такого нет. Проблема вылазит в основном в часы пик, когда валит больше всего МАКов,грубо говоря. Способ на стенде - симитировать генерацию МАКов наверно.

2 gen PSI general: Попробуйте, пожалуйста, ситуацию с прошивкой, которую я Вам выслал. В случае если проблема останется пришлите мне на почту вывод команд "sh fdb", "sh arpentry", "sh tech" во время наличия проблемы и после очистки таблицы коммутации. Также схематично опишите топологию.