В ядре стоят 3610
на доступе 3526 и 3028
схема влан на дом

в разных частах сети, у абонентов возникает такая проблема:
связь прерывается (никаких закономерностей не могу найти) случаным образом
на пинге это выглядит как 2-6 потерь подряд (в среднем 3-4)

есть подозрение вот на что:
на коммутаторе по пути к абоненту я обнулил счетчики ошибок, путем перезагрузки коммутаторов (заодно прошил их все до последней версии, указанной в подписи)

цепочка до тестируемого абонента такая:
3610 - 3028 - (1)3526 - (2)3526 - (3)3526 - (4)3526 - (5)3526 - (6)3526 - абонент

на некоторых коммутаторах 3526 по цепочке, были обнаружены ошибки на модульных (сфп) портах (спустя пол часа, после перезагрузки):

(1)3526: Drop Pkts 1362 (в сторону (2)3526)

(2)3526: нет ошибок

(3)3526: Drop Pkts 1271 (со стороны (2)3526) и Jabber 132 (в сторону (4)3526)

(4)3526: нет ошибок

(5)3526: нет ошибок

(6)3526: нет ошибок (на порту абонента, тоже нет)

Я незнаю, связанны ли это дропы с потерями на абонента, но хотелось-бы узнать, изза чего растет этот счетсик?

safeguard - отключен
трафик контроль на 25-26 (сфп) портах - отключен (включен только на абонентский броадкаст+мультикаст 10ппс дроп, но пробывали отключать, никаких изменений)

п.с. когда у абонента идут потери, то мак шлюза (3610) не записан у него в таблице арп.
Подозреваю, что идет запрос на мак шлюза и он дропается коммутатором по пути...

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

п.с. когда у абонента идет "Обрыв", на коммутаторы потерь нету в этот момент.

где копать?

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

ой блин а длиннее нельзя цепочку было сделать


а на шлюзе в этот момент есть мак абонента в arp таблице???
вообще в момент проблемы по всем свичам мак адрес абонента видно/? (так понимаю влан до абонента идет от 3610 где есть интерфейс в этом влане )
флов контроль и трафик контроль везде выключен?? (по крайней мере на магистральных портах)
на порту абонента включен ип мак билдинг??
какие есть АСЛ правила на порту абонента?

_________________
Умная книжка по теории сетей и настройкам свичей:
ftp://ftp.dlink.ru/pub/Trainings/Switch_D-Link_newest_Basic.pdf

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


На всех портах выключен везде.


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



вот ацльки стоящие на 3526 по ветке (включая коммутатор абонента)

http://www.vladivostokcity.ru/acl.txt

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

Сколько времени проходит с момента возникновения проблемы до её самоустранения?


Причем здесь флоу-контроль, когда вопрос идёт об изучении маков шлюзом или клиентским свичем?


Вы абонента определяете по порту свича или мак-адресу?


Каким образом вы её наблюдали?


Аклы то тут причём?

Drop Pkts 1362 - это пакеты, попавшие в deny профили acl


А что они делают и зачем они нужны?

а вы список правил видели/??


учитывая что эт длинк

mcdemon05
удалите
create access_profile ethernet vlan source_mac 00-00-00-00-00-00 profile_id 4
на всех свичах
и посмотрите исчезнет проблема или нет

_________________
Умная книжка по теории сетей и настройкам свичей:
ftp://ftp.dlink.ru/pub/Trainings/Switch_D-Link_newest_Basic.pdf

2 mcdemon05
Ключевые слова из всего текста:

arp дропается...
если мы хотим что-то отправить на шлюз нам нужно знать его mac,
mac адрес шлюза запрашивается с помощью arp, т.е. идут потери либо arp запрососв либо arp ответов.... задача понять где они теряются, т.к. проблема плавающая, то причины могу быть самы разные...у меня подозрение, что теряется именно arp ответ, в силу того, что arp запросов в сети становится очень много и шлюз не успевает их обрабатывать... причины большого количества arp запросов могут быть самые разные, тема неоднократно обсуждалась на форуме.
Есть вероятность что на промежуточных коммутаторах включен broadcast storm (traffic control) и они тоже вносят свою "лепту" в потери при росте широковещательного трафика.


можно увидеть настройки 3610? и логику подключения клиента узнать, т.е. в каком он vlan...

2 mukca
можно узнать логику ваших советов?
кроме этой

А crc ошибки не растут?

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

конфиг выслал на мыло
абонент находится на interface GigabitEthernet 0/9
supervlan 4093
subvlan 24

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

нет, я бы обязательно сообщил

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

этож длинк (чур не обижатся)


был похожий случай на 3526 b36.
первый порт изучал мак адрес, но не передавал его дальше.
то есть все работает отлично все замечательно, потом бац на порту мак адресс есть, а дальше по цепочки свичей (DGS3100) нету.
появилось после месяца нормальной работы причем проявлялась проблема каждый день 2-3 раза.
не каких ошибок на свиче нету, в логах тоже нечего нету.
при очистке fbd таблицы при выключении включении порта нечего не не изменялось (линк поднимался на ура мак на порту было видно сразу).
начинало все работать только после ребута свича.
пробовали другие мак адреса (даже ставили свой dir-100) проблема все равно появлялась, пробовали разные версии прошивок (от b23 до b48.)
если этот же провод воткнуть во второй порт (или любой другой) проблемы не появлялось.
сняли свич посчитали что порт сгорел (ну мало ли бывает). принесли в офис поставили проблема повторилась.
сбросили настроили - проблема исчезла.
решили поставить в офис, неделю стоял проблемы нет. вернули тихо обратно туда откуда сняли. уже прошло 2 недели проблема больше не разу не повторилась.
все свичи у нас перед установкой в обязательном порядке прошиваются B28 перезагружаются и сбрасываются. после чего заливается типичный конфиг.
и как это обьяснить??
и еще спрашиваете где тут логика

_________________
Умная книжка по теории сетей и настройкам свичей:
ftp://ftp.dlink.ru/pub/Trainings/Switch_D-Link_newest_Basic.pdf

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

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

у меня была такая проблема с 3610. Если терминировать на нем клиентские вланы, то при определенном количестве абонентов такое ощущение, что он иногда перестает отдавать арп-ответы. Загрузка его процессора при этом 10-15%. Поставили вместо него 3627 и проблема ушла. А его оставили только на локальный пиринг из-за BGP.

при всем уважении, просто не надо предвзятости.


никогда не слышал о том, чтобы коммутаторы передавали выученные ими мак адреса....

а проблема которую вы расскзали почти на 99% описывает вариант mac collision, такое случается (1% я оставляю на баги и магнитные бури...т.д.).
и да при всем уважении, то что касается работы, то логика есть во всем...

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