hard1mpulse

Negator, SNMP выключено, мониторили всё ручками, через винбокс. Собственно,идея со стендом хорошая, только в любом случае если так тестить, то тест будет неполный, ибо на нем BGP Full View висит, на столе то бгп не поднимешь.

telecom,для того, чтобы затребовать у руководства новые более крутые железяки, мне нужно привести нормальные аргументы на тему того, почему наши текущие железяки не подходят. И если был бы значительный прирост абонентов, или траффика, я бы уже давно всё агрументировал и давно уже бы ковырялся в каком-нибудь новеньком хуавее или циске. Но: 1) Как я писал в теме, проблема не зависит от кол-ва нагрузки,днем, вечером, ночью, утром, не важно. Даже при одном абоненте, висящем на мтике, проблема сохраняется. 2) Прироста не было вообще.Ни по нагрузке, ни по траффику. Поэтому и агрументировать то, что мтик надо менять, у меня не получается. При этом я прекрасно понимаю, что замена мтика проблему решит.

Добрый день, коллеги! Требуется суперспец по микротикам,для решения проблемы, описанной в этой теме. Сразу скажу, проблема очень нестандартная,и уже с неё съехали и сертифицированный мтиковский спец, и даже саппорт мтика. Если кто-то готов рискнуть личным временем и разобраться, милости прошу в ЛС, или на почту pka@globallink.su

Разбивать необязательно, можно использовать Ip unnumbered,если конечно ваша киска поддерживает его.

Задача немного странная, ибо у Вас вланов много, а подсеть одна. А выдача белых айпишников принципиальна? Можно ведь на каждый влан свою подсеть локальную создать, а на 7301 статически натить и выпускать на вышестоящий маршрутизатор.

Дело такое. На самом деле у нас наклейку на машину сделали, окупилась уже через недельку. А по поводу пиратства: хз, у кого как,у нас получилось так-столбы принадлежат самому садоводству, садоводство само заинтересовано в том, чтоб у людей тырнет был. И выходит такой негласный договор-мы тянем тырнет, засчёт этого арендуем столбы. Хотя тут такое, всё зависит от правления садоводства,и от Вашего умения договариваться :)

Смотрите IP-Routes, все подсети должны быть в состоянии Acitve-Connected. Потом смотрите правила НАТа, и смотрите ФВ на мтике,нет ли каких-либо запрещающих правил.

Либо у Вас схема неточная,либо напутали именно при настройке: На мтике на доме у Вас дальние клиенты описаны подсетями 172.10.132.0/24 для vlan 1102 и 172.10.133.0/24 для vlan 1103,но при этом клиент в 1102 влане сидит с IP 172.10.131.3,а в 1103 с 172.10.132.5.При этом клиенты на доме в 1101 влане сидят но айпишники из вообще не описаной вами подсети: 172.10.135.0/24.Такой подсети вообще на мтике не создано. По логике они даже до своего гейтвея достучаться при таком раскладе не смогут.

Надо точно долбить прова. Ибо это с их свича льется мкаст. Попросите их вообще исключить ваш порт из снупинга, если у них активное оборудование. Если пассивное то они всё равно этого не сделают. А вообще, то что этот трафф вам льется, не значит, что он забивает вам канал в тырнет. Ведь врядли у вас 10мб линк до провайдера,правильно? Скорей всего линк у вас 100ка, и шейпится всё выше, не на свитче. Соответственно, вот вам и ответ, почему пров не видит этого траффика.

А как настроено переключение на INET_2? По умолчанию, если INET работает, то маршрут INET_2 отключен? Вообще, вам в любом случае сюда. Только, если переключение на INET_2 настроено скриптом,что скорей всего, то скрипт придётся переписывать

Ну у меня лично в арп таблице с нулевыми маками появляются айпишники, которые используются для NAT'а. Вы через этот айпишник натите локалку?

Понял,благодарю.А можно еще поподробнее про сертифицированные железки? Есть где-то реестр "кошерного" железа для телефонии?

Понял. Т.е. мы найдем оператора, готового продать нам номера,а соединение с ним обязательно через физику, или достаточно IP-связанности, и уже через SIP транки?

Лицензия на телефонию есть. Нужно только номера запросить у россвязи(я же правильно понял, у них запрашивать?), но прежде чем запрашивать хотелось бы понять дальнейший порядок действий.

Добрый день! У нашего скромного ISP неожиданно возникло острое желание предоставлять клиентам телефонию. Собсна, в связи с этим вопрос-что нужно для этого сделать. На просторах тырнетов нашел только эту тему Вообщем-то там всё понятно, но есть пару "но". Во-первых: там шел разговор про Москву, а мы базируемся в СПб,в пригороде. Во-вторых: там не написано про организацию стыка с этим самым "оператором связи", который нам "пропишет ёмкость". В-третьих: обязательно ли к использованию сертифицированное железо, или можно, к примеру,использовать обычный астериск? Есть желание просто прописать пачкой сиптранки на астериск и потом связывать их локальными сип-аккаунтами. Есть тут те, кто занимался когда-нибудь этим?

Если честно, "железную" проблему сразу отмели ибо первым делом решили заменить мтик, пробовали 2 аналогичных, и проблема осталась. Поэтому даже не рассматривали этот вариант. По всему видно, что проблема софтовая. Кстати, из саппорта мтика пришёл невнятный ответ а-ля: "Проблема есть, но вы там держитесь..." и т.д. Но при этом официально признавать это багом отказались. Уже вот хз чё делать, переходить на какое-то более крутое оборудование типа джунипера или киски бюджет не позволяет.

Допускаю, что мы переросли железку, однако она нам верой и правдой служила с делекого 2009го, с крошечного местячкового ISP с тремя сотнями абонентов,проблем не было и тогда, когда мы достигли 3х тыс. абонентов. Проблема с винбоксом вылезла, так сказать, из ниоткуда, просто вдруг неожиданно началась. И саппорт микротика меня обрадовал: "это так и должно быть, генерация большого кол-ва винбоксового траффика грузит девайс, поставьте лимит на траффик, будет чуть лучше, но на самом деле всё так и будет, смиритесь." Кстати, небольшой апдейт по симптомам: как я понимаю, наш роутер грузится из-за необходимости предоставления большого кол-ва инфы. Я выше писал что при подключении через SSH проблемы нет, но это не так. Оказалось, что, как и в винбоксе, при необходимости предоставления большого кол-ва инфы(/interface print stats,например) загрузка ЦПУ скачет

Ап темы. Проблему всё еще не решили. Общаюсь с техподдержкой микротика, их ответ примерно таков: 1) Это норма, что использование винбокса грузит ЦПУ, винбокс мол выгружает много инфы, и т.д. и т.п. 2) Предложили забавный костыль, с добавлением в Queue Tree специальной высокоприоритетной очереди для винбоксового траффика. Костыль был мною протестирован, траблы он не решил. Всё по прежнему-открываем Интерфейс лист или другие мноинформативные вкладки-начинает скакать загрузка ЦПУ и,соответственно, теряться пакеты и скакать пинги. Сегодня еще попробуем обновиться до тестовой RouterOS 6.37rc, но,боюсь, это не пофиксит проблему. Соответственно, вопрос к спецам по микротику: неужели реально генерация винбокс-траффика настолько сильно нагружает проц, сильнее чем 100к пакетов в секунду, которые он форвардит?Действительно ли это норма для ROS?

Дело в том что в отсутствии нагрузки проблема тоже наблюдалась, даже с 1 пользователем, подключеным в мтик. Да и собсна вот график загрузки cpu за год. На нем очевиден скачок. Тогда и началась проблема,сосбна говоря Количество PPS и до скачка и после было плюс-минус одинаковое. А загрузка CPU резко возросла.

Углубились мы в проблему,помониторили и заметили: Если кто-то в винбокс залогинен, но никаких вкладок не открывает, то загрузка ЦПУ стабильна. Если мы пытаемся открыть пустые вкладки(к примеру Interfaces-GRE Tunnel), то загрузка стабильна. Если мы открываем вкладки которые единовременно выгружают какую то инфу( т.е. инфа на этой вкладке не апдейтится часто, например АРП таблица),то возникает единовременный скачок в загрузке ЦПУ до x2 от средней. Если мы открываем постоянно обновляющуюся инфу, типа interfaces(а у нас их около 20),или допустим запускаем Torch аплинка до магистрального провайдера, то загрузка стабильно скачет с некой периодичностью до x2-x3 PPS в пики через наш мтик-около 100-150 к.И при нормальной работе,средняя загрузка в пики 30-35%. Вопрос-неужели выгрузка данных в винбокс настолько грузит проц? Это же не нормально.

Точно. Заметили сегодня с утра. Тестили весь день. Периодически одно из них может залипнуть до сотни,да. Но ведь разница в средней загрузке CPU с подключенным винбоксом и без очевидна, и это самое странное.Ну почему ж так грузит процы винбокс?Это ж не нормально Тестили и без нагрузки, то же самое.

Без винбокса С винбоксом

Столкнулись мы в нашем небольшом ISP с забавной проблемой. В качестве бордера у нас используется CCR1036-12g-4s.На нем же реализован шейпинг скорости, файрволл и проч. Потом неожиданно начались проблемы с пакетлоссами и скачущими пингами. У всех пользователей, вне зав-ти от L2 сегмента, пула IP и тд. Даже пинги с самого мтика скакали. Делали всё, что вообще возможно, отключали юзеров, кидали конфиг на другой(идентичный) мтик, проверяли аплинк.Не помогало. И вдруг заметили одну зависимость: проблема возникает ТОЛЬКО когда кто-то из нас залогинен через winbox на этот мтик. Т.е. для примера: Если никто не залогинен Если кто-то залогинен через винбокс Ну и соответственно, пакетлоссы могут выскочить, и до 600 пинги вырасти. При доступе через ssh такой траблы не возникает. ПОнятно что мониторинг через ssh это выход, но всё же проблему винбокса желательно бы решить. Кто нибудь сталкивался? P.S. менять прошивки на мтике пробовали, пересоздавать конфиги тоже.