nur16

Выжмете примерно 1мегабит на 1 абонента. То есть 60Мбит. FR -да, работает. Но нужно иметь 4секторные сайты.

У нас как раз 1100Н2х. То же самое что АН2х, только 1г оперативки. Кроме терминации пппое нет ничего, только ibgp с бордерами. 150 сессий - предел, при котором коннект абонов происходит не с первого раза, подвисания сессий, лаги с задержками, скорость проседает и прочая. Держим 100-120 сессий as max

Мы так переводили абонентов с циско на микротик. Биллинг один. Подцепили в те же виланы два rb110a2x, на микротиках абонов практически не появлялось. Более производительный пппое сервер циско забирал всех абонов. Потушили циску-все сразу нормализовалось, все абоны авторизовались на микротиках. И, да, как тут уже сказали, на 1100 микротик около 100 абонов пппое, не больше! Дальше начнутся глюки.

Мы использовали для пппое роутеры RB1100AHx2, и заметили что разные глюки с пппое начинаются при загрузе процов уже на уровне 30%. Не стали разбираться, и тупо поставили еще роутеров. Проблемы исчезли. Для серии 2011 загруз проца в 75% - это уже просто беспредел. Для сохо еще годится, но для сервисного обслуживания - никак. Поставьте в параллель еще микротиков, посмотрите. Да, надеюсь всякие там программные сжатия, кодирования отключены?

лучше прямо на абонентах фильтровать, чтобы до базы даже не долетало. Как? -) Тем же включением опций Reliable Multicast и IGMP Fast на STA абонентов ?

Попробовали фильтрами на роутерах придушить все iGMP, попаданий в фильтры ноль. Мультикаста нет в ethernet портах базовых станций. Думается все летит от сре и крутится где-то внутри БС. Если это вообще igmp. Вот как igmp душить внутри БС? Там же вроде L3 что-то такое есть. Кто-то пробовал?

спасибо! а ничего полезного не накроется? )

В общем нашли некую корреляцию. Включение на базе опций Reliable multicast и igmpv2 fast дало результат в виде незначительного, но уверенного снижения всплесков загрузки цпу. Мы тв практически не даем, а если и даем, то только юникастом. Как убить мультикаст на базе под ноль? Что нужно делать? Все базы воткнуты в роутеры микротик. Спасибо

Вот для примера график загруза цпу STA Connectorized non gps, работающей в режиме точка-точка в eptp mode. Трафик через линк прет предельный, упирается в ethernet порт. Но, как вы видите, загруз цпу нормален и хорошо видна зависимость от обьема трафика. Так почему же нет таких периодических подвешиваний точки? Трафик через нее прет гораздо более высокий. А у баз gps sync, питающихся через этот линк, вовсю наблюдаются скачки загруза цпу? При этом, везде говорится, что якобы у gps sync гораздо более сильный процессор, чем у non gps. Отличие только в типе оборудования и режиме его работы: gps sync и синхронизация от спутников.

А как глянуть? Куда смотреть? Где отключить/прижать? Видел такое поведение проц. в мониторинге, пока плюнул. Что касательно GPS - на одной базе беспричинно отваливается. Один раз пропустили момент, база бросила клиентов, клиенты завоняли, - помог только ребут по питанию. В другой раз заметил когда сутки еще не истекли, передатчик базы работал, отключил GPS синхронизацию, ну и разумеется переместился на др. частоту. Пока списываю на грозу, вроде в обоих случаях была, но почему тогда с ортодоксальной базой все в порядке - ??? А у вас таймаут по GPS какой установлен? У нас стандартные 86400, сре не отваливаются при отвале GPS.

Syslog ничего криминального не кажет. Корелляции с трафиком никакой нет. Загруз цпу не зависит напрямую от количества абонентов на базе, от расстояний, модуляций, географических координат, ни от чего. в SSH консоли нет никаких инструментов, чтобы посмотреть что грузит процессор. Пробовали ограничивать бродкасты на базе/сре, не влияет. На уровне подсознания, заметили, что процессор грузится тогда, когда резко меняется количество видимых спутников от GPS приемника. У нас все базы работают в режиме синхронизации от GPS с реюзингом частот. Пока происходит перетрубация со спутниками, процессор подвешивается. Но это пока не точно выверенная инфа, у нас просто закончились другие предположения.

Запарились искать причину периодической высокой загрузки CPU баз AP GPS Sync. Че тока не делали. Подскажите куда копать? Кто сталкивался?

классно значит бэк дор есть в прошивке.... Проблема видна только в массовом применении. Баг проявляется не в каждом STA, а выборочно. Примерно в одном случае из 10. Ребут по питанию, и STA начинает светить свой белый IP в инет, 80 порт открыт. При этом у устройства есть отдельный менеджемент влан и серый IP для управления. Можно открыть как по белому, так и по серому IP. Ребут из www интерфейса - и все, баг пропадает. Накатили массово на всю сеть прошивку 2.6.2.1 - проверили всех, вроде баг исчез.

Нет, не удалось. Но, выяснилось что в прошивке 2.6.1 был баг, который светил белый айпи устройства в интернет, даже если был назначены отдельные влан и серый айпи управления.

А на каком протоколе / платах был построен линк до установки плат АС?

Если это имеет значение, то сбросились STA разных типов - integrated, форсы 180, и даже пару форсов с чашками которые (110?). То есть аппаратной зависимости какой-то нет. Базы работают в стандартной для нас схеме ABCD с реюзингом частот, полоса 20МГц. Софт везде 2.6.1, и на базах тоже.

На редкость прохладное лето выдалось в этом году. Сейчас за окном +26. Много дождей. Да, все роутеры сбросились. По крайней мере, на данный момент имеем такие данные. Обнаружили также, что оказца на роутер можно было зайти по белому адресу гейта... Ни разу не догадались проверить. Думали раз есть серый адрес, то всё прикрыто.

Конечно! Привезем пару штук к нам оттуда, и выполним ваши инструкции. К понедельнику привезут. Спасибо большое Да, разные. Но все эти сети входят в один большой блок, принадлежащий нам.

В логах DHCP нет ничего странного. DHCP выдавал адреса обоим типам STA - серые адреса /32 роутерам, белые адреса /32 nat устройствам. Для устройств с роутингом была выделена одна белая /22 сеть и разбивалась на подсети размером /30. Для устройств с nat также была выделена одна белая /22 сеть и разбивалась, соответственно на /32. Всем рулит один ядровый маршрутизатор, все на нем. Трансмиссия тоже приходит прямо в него. Весь трафик оттуда прилетает уже в центральное ядро. Вся схема сети совершенно повторяет сети других городов. Единственное отличие - в этом городе у нас нет ни одного сектора микротик и, соответственно, ни одного сре микротик ) только камбиумы. Нет ни одного конкурента, только наш нацоператор с его древним adsl от coreccess. Мы решили так - закрыли файрволлом все гейты всех /30 роутеров, по совету rdc. Все nat устройства решили посадить на серый менеджемент с отдельным виланом управления, как и STA роутеры. В общем, сделаем так, чтобы по белым адресам до STA достучаться извне было невозможно. Привлекли также знакомых ментов, сейчас занимаются проработкой вопроса. Но злой умысел это последняя очередь подозрений. Работаем 17 лет, такое впервые, никого не обижали. Если и после этого повторится или будет продолжаться, то тут явно с камбиумом что-то не так. Если у кого идеи есть, будем благодарны.

Ситуация абсолютно загадочная, пока не знаю, чем помочь или даже в какую сторону копать. Я не представляю, как без вмешательства пользователя, как-то можно сбросить конфиг. 1. Вы пользуетесь cnMaestro? 2. С часа X еще были случаи сброса? 3. Ничего не менялось в сети? софт какой-нибудь? Маршрутизация? Не мог мониторинг пошалить? PS в любом случае выключите "Factory Reset Via Power Reset Sequence" в разделе "Tools->Backup/Restore" 1. Нет, мы не пользуемся cnMaestro. Есть установленный CNS сервер, который мониторит всю сеть камбиумов. Он, конечно же, на сером адресе. Он может так глюкнуть? 2. Точно не могу ответить, но с часа Х мы просто обнаруживаем все новые сбросившиеся STA, которых не заметили сразу в этой сутолоке. 3. Единственное, что отличает сеть этого города от всех остальных городов - это то, что адреса выдаются через DHCP, как серые для STA с /30, так и белые адреса для STA с NAT. Сейчас отдана команда прибивать адреса вручную статически в момент восстановления STA от сброса. Мы тоже предполагаем, что наши учетки поломали, но учетки одинаковы для всех STA, так почему сбросились только STA в режиме Router и только в одном городе? Теоретически и практически, конечно же, это могут быть проделки обиженных админов или злых конкоров, не исключено. Прорабатываем и этот вариант, конечно. P.S. Резет через питание был отключен у большинства сбросившихся STA, мы отключаем сейчас этот параметр у всех подряд.

Все STA запитаны от родных, исключительно родных блоков питания. Часть сбросившихся STA запитаны через UPS абонентов, так как подсети /30 обычно запрашивают абоненты корпорейта, и у них есть своя сетевая инфраструктура. Также, по докладам монтажников, STA сбросились по разному. Примерно 60% сбросились в полный дефолт. А остальные - у них всего лишь слетел wireless IP адрес с маской и гейтом. Все остальные настройки у STA остались на месте как были. Посмотрите на картинку в первом посте - этот адрес серый, и через него происходит маршрутизация белой /30 подсети. Абоненты при этом могли пинговать свой белый гейт на STA с интерфейса ethernet. Такие STA коннектились на базы, но база их отпинывала, так как они все ломились с одинаковым дефолтным адресом 192.168.0.2. Помогите

Конечно каждый STA по snmp имеет отдельно прописанный коммунити и на чтение и на запись. тогда еще глупый вопрос: installer и прочие юзеры имеют не дефолтные пароли? installer - нет. другие логины задизаблены. сейчас, анализируя сетевые логи коммутаторов в этой сети, обнаружили, что примерно в то же самое время был аномальный трафик пакетов IGMP. Коммутаторы реагировали на них повышением загрузки цпу: логи при этом вот такие: 08.07.2016 6:43:54 DGS-3100-24TG 172.16.20.27 %IGMPHOST-D-IP: IGMP Packet with unknown source IP не можем понять, куда копать и что делать

Конечно каждый STA по snmp имеет отдельно прописанный коммунити и на чтение и на запись.

По вашему совету на ядровом роутере этого города прикрыли все гейты всех /30 подсетей этих STA роутеров. Попаданий в правило файрволла практически нет.

Статистика такая - 270 штук STA в режиме NAT, и все живые, и 65 штук STA в режиме Router, и все сбросились. Все территориально в одном городе, схема вилан на базу. В других городах сотни STA, никаких проблем, все работает нормально. Что это, люди? По факту, все сбросились в промежутке примерно одного часа.