Есть 3627 (Build 2.82.B16)
1 сервер и 2 клиента
Ситуация такая оба клиента подключены к серверу по PPTP, один клиент постоянно активен (пользование торентами и пр.), второй пассивный.
Так вот у того, который, пассивный каждые 10 минут происходит дисконект РРТР.

Вопрос может ли это быть связано с ARP aging time ? В данный момент значения по умолчанию.

P.S. схематика приведена очень кратко

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

В момент отвала клиента что говорит sh arpentry ?

Если идет постоянный пинг, разрыва соединения не происходит.

Как будут данные по arpentry сразу сообщу.

отвал клиентов возможен из-за ARP aging time
по умолчанию там вроде 20 минут , но у меня оно когда-то стояло и 5 минут и нормально работало , но на старой прошивке были и другие глюки с ARP .
Выяснилось это жкперементальным путём проб и ошибок и разным временем для ARP aging time.
Может Dlink когданить исправят подобное поведения комуторов , а может уже никогда

вот задачка для проверки что происходит с железкой и абонентами :
Имеем dgs-3627G на нём поднято порядка 40ipif и на нём обитает порядка 1500 абонентов , ARP aging time 20
к вечеру когда arp таблица подходит к 1000 или более начинают потихоньку выпадать абоненты примерно на 40 секунд , а загрузка комутатора потихоньку поднимается. , эксперементальным путём обнаружилось что время совпадает с выставленым ARP aging time , т.е если там 15 минут то клиент примерно через этот промежуток времени и выпадает , а значит приходится увиличивать это время . На текущий момент выставленно ARP aging time 240 , но оно за собой вываливает и другие проблемы , например при резком изменении у клиента компьютера на другой но со статическим IP клиент остаётся без сети т.к в ARP хранится старая запись и котороя может перезаписатся или останется старой достаточно долго. И это далеко не все проблемы с увеличиным ARP aging time .
если зайти на коммутатор и очистить ARP таблицу , то мы теряем весь L3 примерно на 30 - 80 секунд пока не запонится вся ARP таблица новыми значениями. Вот и получается что ARP aging time вычищает таблицу разом , а не попорядку , или просто не успивает пополнять и очищать
Данные проблемы не только у 3627 подобное было и у 3324 , но там очистка ARP помогала .

Вот мне так и хочется что-бы хоть что-то работало адекватно , чтобы запись ARP хранилась и удалялась с таблици по одной и именно по выставленому ARP aging time , а не все сразу.
На старой прошивке это вроде работало , но не доконца , там банально старый МАС мог не удалятся очень долго хоть и стояло маленькое время ARP aging time , ну и были еще другие мелочи .

И из-за подобных вещей начинаеш думать о смене на совсем другие железки и других производителей , но я как-то даже привык ко всем железкам и глюкам Длинка , но основное ядро L3 похоже придётся всёже менять , т.к обещаных в описании 12к МАС он не вытянит , т.к глюки начанаются уже от 1к .

_________________
Люблю писать с ошибками.....
D-Link User: DGS-3627G, DGS-3324SR, DES-3526, DES-1024D, DES-1016D, DWL-2100AP, DEM-310GT,DEM-330, DCS-950.

хм... show gratuitous_arp - вроде "оно" должно решать такие проблемы

_________________
Это текст, который можно добавлять к размещаемым вами сообщениям. Длина его ограничена 255 символами.

Gratuitous ARP по умолчанию 0 , и оно вроде отвечает на отсыл АРП именно комутатором , т.е еслиб запись не обновллась у клиента , т.к коммутатор переодически отсылал бы arp.
А тут наобород получается что проблемы с запоминанием у коммутатора .

вот и вопрос в чём разница у DGS-36xx_2.52-B44 в нём было config arp_aging time 5 , при этом всё работало кроме нескольких глюков (я тут даже отдельно тему создавал по обсуждению этих прошивок), а проблема была только с непонятными трасировками и обращениями на комутатор , в новых прошивках появилась cpu_rx_rate_control которая устранила эту проблему.
А также с переодическим невычищением arp таблиц которая решалась clear arp переодически.
после на прошивке DGS-36xx_2.80-B35 arp_aging time пришлось увеличить до 240 , т.к был переодический отвал у клиентов , коммутатор просто их arp неуспевал запоминать сразу , от чего и были отвалы по пол минуте .
Сейчас стоит DGS-36xx_2.82-B19 недавно поставленая , конфиг остался неизменый по настройкам (System reset делался) , клиенты начинаются заловатся о задержках , в частности в играх...

неужели придётся вобще откатится на 2.52-B45 имея старые проблемы но не такие как сейчас .

_________________
Люблю писать с ошибками.....
D-Link User: DGS-3627G, DGS-3324SR, DES-3526, DES-1024D, DES-1016D, DWL-2100AP, DEM-310GT,DEM-330, DCS-950.

вот про запоминание (а, точнее, изучение нового мака для старого адреса) именно эта строчка:

_________________
Это текст, который можно добавлять к размещаемым вами сообщениям. Длина его ограничена 255 символами.

спс. не знал про это , но от проблемы это всеравно не спасло.

почему комутатор упорно забывает маки клиентов ?
aging time 30 , и на форуме уже даже видео появляется от абонентов что рочно через 30 минут после включения сети у него она перестаёт работать , делают откл. и вкл. и опять пол часа работает .
т.е получается что в момент включения коммутатор изучает мак , а через установленое время забывает про него , и переодических отсыл arp от клиента не сдвигает данное время.

интересно вобще какой алгоритм работы ARP в данных комутаторах. Запоминает ли коммутатор время каждого изученого мак адреса или как-то подругому, и на что влияет aging time - точнее как таблица вычищается , вся сразу или кадый мак по отдельности итд.

по работе как на DGS 3324 так и на 3627 выяснилось только что если ARP таблица намного больше таблици FDB то через некоторое время комутатору сносит крышу и загрузка CPU медленно ползёт вверх , именно это еще одна причина выставить aging time намного меньше , насколько это позволит сделать. Второй момент это по таблице ARP мониторить кол-во активных устройств в сети и вовремя реагировать в случаи чего.

_________________
Люблю писать с ошибками.....
D-Link User: DGS-3627G, DGS-3324SR, DES-3526, DES-1024D, DES-1016D, DWL-2100AP, DEM-310GT,DEM-330, DCS-950.

Записи из arp таблицы удаляются по одной, т.е. на каждую запись свой счётчик.
Какова у Вас загрузка CPU когда начинают отваливаться клиенты? Каковы настройки safeguard engine?

У нас сейчас на ядре стоит des 3828, с прошивкой 3.00.B57, пробовали заливать другие прошивки (нужны были некоторые функции), но появлялся глюк: некоторые пакеты приходили не некорректной контрольной суммой. Сейчас переходим на гигабит, меняем коммутатор на dgs 3627, прошивка 2.82.B20. Поэтому хотелось бы знать в какой прошивке проблема с arp устранена?

поднятие до 60 минут тоже не помогло , клиент точно заметил отваливание через 61минуту дважды
после arp -d на стороне клиента связь появляется через несколько минут. (поднял время опять до 240 )
safeguard_engine state disable
на одном комутаторе загрузка cpu 8-10% на втором 12-16%.
походу не будет нормальной жизни ARP у L3 Dlink

_________________
Люблю писать с ошибками.....
D-Link User: DGS-3627G, DGS-3324SR, DES-3526, DES-1024D, DES-1016D, DWL-2100AP, DEM-310GT,DEM-330, DCS-950.

cpu_interface_filtering используется?

_________________
Это текст, который можно добавлять к размещаемым вами сообщениям. Длина его ограничена 255 символами.

да , только там нечего особеного нету

_________________
Люблю писать с ошибками.....
D-Link User: DGS-3627G, DGS-3324SR, DES-3526, DES-1024D, DES-1016D, DWL-2100AP, DEM-310GT,DEM-330, DCS-950.

А Вы пробовали отключать CIF? Проблема с ARP-ами также остаётся?!

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

у меня была похожая проблема - есть сервер который самостоятельно никуда не обращается (сервер статистики) и регулярно юзеры на него попросту не могли попасть вылечилось только запуском по крону скрипта который регулярно пингует пару соседей чтобы свич не забывал, а если забыл - вспоминал его (сервера), а заодно и их (соседей) МАС-и ... да, тупо и в лоб, но зато работает как часы

_________________
с уважением, БП