Имеется несколько коммутаторов 3627 и 3627G, стоящих в центре в конфигурации "звезда", вокруг общего ядра, к которому уже подключаются сервера и т.п.

Прошивка на всех 2.52.B45. Более старшие прошивки пробовали, но проблема осталась.

В портах 3627G стоят модули, а от них оптических линии уходят в районы на группы домов. На доме на другом конце оптики стоит 3052, а к нему подключены клиенты и еще пара домов, на которых 3028 и 1210-28 тоже все подключены по оптике, но уже с гигабитных портов 3052. Схема простейшая и я думаю без рисунка все ее и так себе четко представляют.
Проблема заключается в следующем.
Периодически клиенты домов, где стоят 3028 и 1210-28 теряют шлюз (он их не видит и они его), но друг друга в доме видят успешно. Шлюз соотвественно поднят на порту 3627G, стоящего в центре.

Берем оптический модуль из 3627G и переставляем его в стоящий рядом коммутатор DGS-3100-24TG, пропуская через его порты весь трафик с проблемного участка. Далее по меди отдаем на 3627G. Проблема с потерей клиентов или исчезает совсем или почти не беспокоит и те, кто жаловался, работают успешно.

В таблице MAC на 3627G в часы пик около 1800 адресов. В ARP чуть меньше (около 1650). На каждом коммутаторе 3627 периодически возникают такие проблемы. В основном на оптических портах, но бывает и на медных. Нагрузка на CPU коммутатора менее 15% даже в пиковые моменты. Загрузка портов 10Гбит/с в ядро около 12-15%.

Периодически теряются не только клиенты, но и подключенные к ядру сервера перестают быть видимыми для клиентов. Периодичность отвала совпадает по времени с временем жизни arp и maс на 3627 и 3627G. Пробовали разные значения этих параметров и увеличивали и уменьшали - толку ноль. Время отвала точно повторяет значения этих параметров. У клиентов в это время отлетают pptp туннели от серверов и по анализу лога вышли на совпадение времени жизни в таблице 3627 и длины сессии клиента.

Ощущение такое, что для 3627 и 3627G по 1800-2000 MAC на устройство уже неподъемная нагрузка и они не умеют с ней справляться.

Что делать? Увеличивать кол-во 3627 в центре исходя из расчета 1500-2000 абонентов на устройство или надо ставить другие коммутаторы?

И вопрос вдогонку. Почему коммутатор DGS-3100-24TG исправляет ситуацию, если просто ставится в разрыв линии между домовым 3052 и центральным 3627?

Потому что в момент перетыкания тырчика из 3627 в 3100, IP интерфейс 3627 переходит в состояние down и высвобождает ARP таблицу, и она внось свеженькая заполняется со стороны 3100. Т.к. она уже имеет не такой размер, как изначальная, а меньше, всё у людей работает как надо. Вы втыкаете всё назад в 3627 и ожидаете следующего переполнения таблички. Как вариант вместо перетыкая попробуйте очистить ARP таблицу, либо положить/поднять зависший IP интерфейс.



1) обновите до последней запрошенной версии прошивку
2) сделайте CPU фильтрацию (cre cpu access prof) входящих пакетов со стороны абонентского влана, запретите абонентам посылать пакетики с IP ихнего шлюза. Должно помочь.
3) переходите на PPPoE, он по всем параметрам лучше PPTP и не зависит от качества работы ARP протокола на агрегирующих коммутаторах + у вас снизится нагрузка на PPP шлюзах в виду более простой реализации PPPoE.
4) в случае нереальности решить проблему пунктами 1-3, смотрите в сторону кошек 35 или 37 серий

3627 как L3 слабый, как L2 - один из самых лучших на рынке

Я говорил не о сиюминутном исправленнии, а о том, что после включения 3100 все долгие дни работает без сбоев, по крайней мере уже несколько дней. Про обнуление таблицы я в курсе, но здесь речь идет о долговременном эффекте.



1 и 2 пункты выполнены давно. Эффекта нет.
Пункт 3 ставлю под сомнение как вариант решения, потому что проблемы начинаются еще до попадания пакета в шлюз, а уже тем более в сервер авторизации PPTP, который стоит еще дальше за шлюзом подсети клиента и значит от клиента он находится на другой стороне L3 3627. Т.е. клиент не может достучаться даже до порта L3 коммутатора, который является его шлюзом.

Собственно сомнения возникают как раз в способности 3627 работать с большим числом ARP записей.

В сторону кошек я посмотрю, потому что в линейке D_Link видимо нет девайса за разумные деньги способного работать как L3 и качественно обслуживать 20-30 подсетей шлюзами на своих интерфейсах и тянуть на себе 3000 и более клиентов.

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

Т.е. даже в таблице FDB клиент не присутствует?

3627 не делает ничего кроме маршрутизации IPv4. ACL на самом 3627 нет, на подключенных к нему абонентских L2 стандартный набор: блокировка netbios, запрет от подмены IP и MAC шлюза (т.е. защита порта L3 для 3627) и запрет нелегальных DHCP и DNS. Таким образом все что не нужно отсеивается до попадания в 3627.

MAC клиента не долетает до 3627 или если и долетает, то вскоре при истечении времени жизни mac или arp пропадает и снова не появляется. Бывает так что при обновлении счетчика времени клиента на какое-то время выкидывает из таблиц 3627, а спустя несколько секунд связь с ним снова восстанавливается, хотя это приводит к разрыву соединения.

Сами 3627 стоят в центре сходящихся к ним оптических линков от клиентских L2 коммутаторов, стоящих в районе или от центральных L2 3100-24TG и 3200-28F, агрегирующих оптические линки с района в медные транки к 3627. Топология - классическая звезда без всяких излишеств. В общей сложности на каждом 3627 поднято примерно по 25 шлюзов подсетей класса C. К центру 3627 подключены по 10 Гб/с линкам.

Единственная версия пока лишь такая, что 3627 не справляется с количеством клиентов, хотя нагрузка на нем по CPU совсем не большая и порты нагружены не очень сильно.

Прошивку из самых последних бет 2.82 будем пробовать еще, но на нее надежды нет.

Как именно это в вашем случае реализовано на моделях DES-3028/52, 3526, 3200 ?
Фильтруются ли Broadcast пакеты на абонентских свичах? если фильтруются, то как именно?

1. На доступе запрещен 0x806 в случае, если на клиентских портах обнаружится ip = ip шлюза. Правила подобной защиты для серий 30xx, 35xx реализованные через PCF можно без проблем найти тут на форуме.

2. По поводу броадкаста ограничения стоят только в traffic control. А как вы предлагаете его фильтровать и стоит ли его фильтровать если его либо нет, либо этот трафик ничтожно мал?

1. А если я пошлю со стороны абонентского влана пакет с ip = ip шлюза, но не 0x806?
2. А если п.1 будет широковещательный? ну допустим 0x800? Не получим ли в результате то, что получаете вы?

dgs-3610 чем не подходит, он будет тянуть в разы больше и вообще более заточен на L3 чем 3627
останетесь на длинке и получите аля кошку ... у них даже консоль и консольный кабель одинаковые -)

1. Тогда как лучше закрывать шлюз и от чего вообще мы его пытаемся закрывать? Мне не думается, что проблема в совпадении ip = ip шлюза. Это было бы слишком банально и не наблюдалось бы в разных подсетях.

Мне кажется проблема в другом. Сейчас для теста перевели несколько подсетей на старый проверенный DES-3828 и посмотрим будет отвал или нет. В общей сложности перебросили на него около 700 абонов.

По поводу DGS-3610-26 посмотрим, но если проблема кроется в другом, а не в 3627, то от замены коммутатора ничего не произойдет. Пока попробуем решить тем способом, который возможен.

Запретите такие пакеты, но не только для 0x806, а для всего трафика
Брудкасты после этого оставляйте только нужные, PPPoE, ARP, DHCP и т.д. остальные убейте.

+1 - да и наверное оптимальны по цене.
3627 может быть использован как L3 , но на практике проверенно что на него лучше не вешать более 1200-1500 устройств , при 1800 его просто начинает потихоньку плющить , При этом L2 трафик переваривает полностью и без проблем.
Проблему с ARP имел долго , частично удалось решить viewtopic.php?f=2&t=134345 , но окачательно походу проблема решилась с переходом на L3 железку другова производителя (совсем не дешового), а 3627 так и останется трудится как L2 + пару интерфейсов L3 - т.е уже не в качестве ядра всей локалки.

Отсюда вывод хотите в качестве ядра , используйте 3627 до 1000 абонентов на устройство , иначе смотрите на дргие железки.
И почему Dlink до сих пор не выпускают многопортовую 10Г железку , её столько народу ждут походу ...

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

Я тоже пока избрал такой или похожий путь решения. У меня валяется штук 10 старых DES-3828, которые стояли до 3627 и мы частично разгружаем коммутаторы 3627 и немного перестраиваем топологию, чтобы сделать некоторые вещи более логичными и близкими к классической звезде, но пока оттянув около 700 абонентов на 3828 с самого проблемного 3627G нам удалось разгрузить его и тем самым стабилизировать работу в этой части подсетей. За два дня после работ жалоб на отвалы пока не было.

Затем мы его полностью освободим от обязанностей и будем вокруг него как вокруг L2 перестраивать ядро с тремя 10 Гб/с линками для подключения двух 3627 и одного 3450 с серверами. Оптические порты 3627G будут заполнены несколькими 3828, которые придется ставить в центрах групп домов в качестве L3. Возни будет много, но стабильность важнее. Лучше за пару ночей все перетряхнуть, чем полгода страдать. Абоненты тем временем прибывают и каждый месяц нагрузка увеличивается. Еще полгода назад никакого намека на проблему не было, хотя уже ощущалось по наблюдениям некоторая тупиковость и проблема постепенно росла месяц за месяцем, а после НГ 2011 выстрелила резко еще возможно из-за ввода новых тарифов и увеличения ширины внешнего аплинка в 2 раза. Людей в сети прибавилось сразу же и это дало по коммутаторам.

На 90% уверен что дело не в программном решении, не в "злом" трафике от клиентов, не в кривых ACL, не в броадкасте, а просто в том, что возможности 3627 в качестве L3 ограничены и наш расчет в примерно 3000 абонентов на устройство оказался не верен. Таким образом мы уперлись в потолок аппарата.

Чтобы не тратить сейчас средства решим проблему тем что имеем в виде запаса 3828, а затем посмотрим на 3610-26 или на что-то еще, например на Кошки.

Даже если будет 10k записей коммутатор не вспотеет.



Увеличивать кол-во коммутаторов не нужно. Сколько в эксплуатации данные коммутаторы?



Вы анализировали логи и ошибки на портах? Я имею ввиду: порт работает нормально или постоянно Link Down/Up?! Если смотреть с помощью команды sh error ports ... какие-нибудь счётчики ошибок растут?

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

Однако вспотевает, дуреет и глючит непредсказуемо теряя абонентов. Коммутаторы в эксплуатации около 1 года, а может чуть больше. Версии прошивок указывал выше.
Мы просто перенесли несколько сетей класса С с каждого DGS-3627 на несколько запасных DES-3828, которые достали со склада, слегка при этом изменив маршрутизацию в сети увеличив кол-во лучей в звезде L3 вокруг центра из-за добавления нескольких DES-3828 в качестве L3 и проблема исчезла полностью. Грубо говоря скинули часть абонентов на DES-3828, чтобы нагрузка упала.
Чего мы только не пытались делать до этого, но ничто не помогало никак. Любые танцы с бубнами не спасали положение или только усугубляли его.
Стоило нагрузке упасть ниже планки 1300 mac и примерно столько же arp на один коммутатор типа 3627 как все стабилизировалось и о проблеме не слышно уже более месяца.
Поскольку коммутаторов 3627 у нас несколько и проблема наблюдалась на всех одинаковая, а решение в виде разгрузки через запасные DES-3828 помогло все 36-м без исключения, то делаю вывод о том, что 3627 не справляется в режиме L3 с 1800-2000 записями arp и mac.

Я не знаю как теперь верить данным, указанным в характеристиках коммутаторов, но попадалово с DGS-3627 застало нас врасплох.

В этой теме выше другие люди тоже сталкивались с подобными проблемами с ARP на нагрузке около 2000 и даже меньше записей в таблице. Мы подтверждаем что такая проблема есть.
Это доказано практикой эксплуатации нескольких DGS-3627 коммутаторов в нашей сети и практическим опытом решения возникшей проблемы.