Iskatel_S Опубликовано 7 сентября, 2016 (изменено) · Жалоба Коллеги выручайте, месяц уже бьюсь с проблемой, а она всё запутаннее и запутанее. Вобщем есть сеть провайдерская, абонентов на 1200 и я эту сеть админю, опыта в таком деле ранее не было. Примерную схему сети выкладываю, всё практически построено на управляемых коммутаторах D-Link: Месяц назад была обнаружена проблема, что время от времени лагает сеть, абоненты жалуются на падения скорости и что тормозит воспроизведение мультимедиа-контента причём наблюдается такое в основном по вечерам. Ищу причину. Логика рассуждений следующая: проблемы могут быть на всех участках по которым трафик идёт от серверов Интернета к абонентам: на серверах, на канале с вышестоящим провайдером, на микротике, на длинках, в оптике и у самого абонента. Сервера и оборудование абонента отметаются потому как тестировалась связь и на другом провайдере и с заведомо-исправным оборудованием. Оптика тоже отметается, несмотря на том что присутсвуют ошибки на оптических портах длинков, потому как тестирование производилось также в офисе, где подключение чисто по меди. При проверке скорости при помощи сервиса speedtest.net на тестовой учётной записи для которой установлены параметры шейпирования входящего и исходящего трафика - 100 Мбит/с показывает входящую скорость 15-20 Мбит/с, исходящую 85-88 Мбит/с. При этом кривая, которую выдаёт шейпер микротика получается заборчикообразная, тоже выкладываю: Долгое время я грешил на сеть. Всего длинков 265, системы централизованного управления нет, вполне возможно что где-то кривые настройки или перегруз. Однако смотрел загрузку cpu коммутаторов в вечернее время на домах с которых идут заявки - показывает 20%, на опорных коммутаторах - то же самое. Потом было подозрение на то, что по сети гуляет слишком много мусорного трафика, порождённого например широковещательным штормом или неправильно настроенным IGMP snooping. Ходил в вечернее время на один из проблемных домов, подключал к коммутатору ноутбук, воспроизводил на на нём мультимедиа-контент, при этом снимал дамп в wireshark. Анализ дампа показал, что мусора нет, большинство трафика - это tcp-трафик. Кривую из wireshark выкладываю, она тоже заборчикообразная. ПРиоретизации трафика кстати в сети нет. А вот HP A5500-24G-SFP EI - единственное устройство, на котором я показания не снимал, потому что просто не знаю как это делается. Но по нему есть отдельная тема от меня http://forum.nag.ru/forum/index.php?showtopic=120438. Получается, что проблема либо в Микротике, либо в канале с вышестоящим провайдером, который кстати утверждает что проблем нет, либо всё-таки что-то в сети, но выводы мои были неверными. Изменено 7 сентября, 2016 пользователем Iskatel_S Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Butch3r Опубликовано 7 сентября, 2016 · Жалоба Микротик 146% главный подозреваемый Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wildmoon Опубликовано 7 сентября, 2016 · Жалоба Микротик 146% главный подозреваемый Хейторы микротика набигают:) А если серьезно, то микротик стоит подозревать. Он на определенных нагрузках чудить начинает. А какой микротик то? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Butch3r Опубликовано 7 сентября, 2016 · Жалоба Микротик 146% главный подозреваемый Хейторы микротика набигают:) А если серьезно, то микротик стоит подозревать. Он на определенных нагрузках чудить начинает. А какой микротик то? а почему нет. Судя по схеме - нормальная звезда, 3200, 3120, 5500 точно не под вопросом Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 7 сентября, 2016 · Жалоба Проблема может быть где угодно. Сходу можно назвать с десяток возможных проблем. Настройте на длинках trafic_segmentation везде, порежьте acl всякий мусор. Настройте loop_detect И собирайте логи с коммутаторов централизованно. Мультикаст тоже стоит ограничить/порезать. Это по минимуму. Сеть вообще сегментирована? Побита на вланы? Далее берем ноутбук и начинаем тестить отключая поочередно узлы и дома на время теста(просто гасим порты пока проблема не уйдет). Находим источник проблемы. Возможно и микротик, но все остальное стоит отсечь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 7 сентября, 2016 · Жалоба IMHO Negator прав. И модель микротика в студию !? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EShirokiy Опубликовано 7 сентября, 2016 · Жалоба Авторизация какая? Авторизуются на микротике? На микроте так же и BGP? Соглашусь с Negator. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nphs Опубликовано 7 сентября, 2016 · Жалоба длинки здохли имхо Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 7 сентября, 2016 · Жалоба Когда дохнут D-Link, то это не заметить сложно, штормит сильно. Нужно проверить/настроить сегментацию, фильтрацию мусора, логгирование. Включить регулярный или постоянный пинг на все коммутаторы и смотреть в динамике за потерями и rtt. Еще хорошо бы рисовать графики (счетчики пакетов, дропов, ошибок), хотя бы с магистральных портов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pingz Опубликовано 7 сентября, 2016 · Жалоба На правах рекламы: "Нужно больше микротиков" По сабжу 1. Сколько и какие микротики? Версия микротика. 2. Сколько правил фаервола(конфиг бы не помешал)? Я начу маскарадингом + одно правило фаервола на запрет всего трафика кроме интерфейса в интернет. Для заблокированных даем 32кб/с. 3. Как отдаёт вам оператор канал? Тип подключения. Суточный график входящего трафика. 4. Тип авторизации абонентов? 5. Обещаная скорость? 6. Загрузка цп в час пик не висит ли 1 процессор в 100% 7. В сорм сливаете трафик? Если да в час пик попробуйте отключить. 8. Отключить snmp на агригации. Что нужно сделать: Сегментировать сеть по виланам желательно влан на дом, можно на р-н будет проще искать проблемный кусок сети. Настроить асл на доступ и на агрегацию особенно на порт микротика, чтобы избавить сеть от мусора и не давать абоненту расшарить свой интернет. Как писали выше трафик сигментейшен на доступ. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 7 сентября, 2016 · Жалоба Как я люблю такие топики. Давайте я угадаю. У топикстартера вся сеть в одном влане. Ну может быть mgmt и data разделены, т.е. в 2ух. Дальше можно не обсуждать Про traffic_segmentaion не воспринимайте всерьёз, это лишь временное решение, чтоб вздохнуть, пока пилите сеть на вланы Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myth Опубликовано 7 сентября, 2016 · Жалоба Про traffic_segmentaion не воспринимайте всерьёз, это лишь временное решение, чтоб вздохнуть, пока пилите сеть на вланы +1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EShirokiy Опубликовано 7 сентября, 2016 · Жалоба traffic_segmentaion не воспринимайте всерьёз Обычно используется traffic_segmentation + vlan на дом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 7 сентября, 2016 · Жалоба EShirokiy технически тогда уж vlan на свитч. на дом - это надо конфигурить сегментацию по портам вниз, следить чтоб аплинки и даунлики не были перепутаны, когда у вас больше одного свитча на дому. "обычно используется" - не очень хороший термин. для pppoe это нормально, для IPoE - нет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sergsa Опубликовано 7 сентября, 2016 · Жалоба а что с пигами происходит, ну а если все в одном влане то вообще все работает на честном слове Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EShirokiy Опубликовано 7 сентября, 2016 · Жалоба s.lobanov, совсем не сложно отследить аплинки и даунлинки, особенно если взять за правило подключать аплинки и даунлинки в определенные порты, например в 25 и 26 соответственно. Вилан на порт интереснее конечно, но не всегда это можно применить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 7 сентября, 2016 (изменено) · Жалоба EShirokiy технически тогда уж vlan на свитч. на дом - это надо конфигурить сегментацию по портам вниз, следить чтоб аплинки и даунлики не были перепутаны, когда у вас больше одного свитча на дому. "обычно используется" - не очень хороший термин. для pppoe это нормально, для IPoE - нет А при vlan на свитч разьве не нужно конфигурить тоже самое, если на доме больше 1 свитча? По сабжу, убедиться в отсутствии неуправляемых коммутаторов - раз сеть досталась в наследство как я понимаю и можно скинуть сюда конфиги D-Link, A5500 Изменено 7 сентября, 2016 пользователем hsvt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 7 сентября, 2016 · Жалоба А при vlan на свитч разьве не нужно конфигурить тоже самое, если на доме больше 1 свитча? Нет, закидываете на "магистральные" порты всю пачку вланов, а на абонентские - те, что относятся к свитчу, таким образом конфиг портов 25-28(на 24 портовых свитчах) - одинаковые. И рукожопые монтёры, которые придут инсталлить или что-нибудь делать не перепутают аплинки и даунлинки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pingz Опубликовано 7 сентября, 2016 · Жалоба У нас есть правило приходящий линк всегда в последний порт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 8 сентября, 2016 · Жалоба s.lobanov, совсем не сложно отследить аплинки и даунлинки, особенно если взять за правило подключать аплинки и даунлинки в определенные порты, например в 25 и 26 соответственно. У нас есть правило приходящий линк всегда в последний порт. Порты имеют свойство гореть, мы тоже первые пару лет жестко фиксировали аплинки/даунлинки, до первых гроз на 3028 ))) Оказалось проще написать скрипт, который по таблице коммутации строит карту портов up/down линков ))) Нет, закидываете на "магистральные" порты всю пачку вланов, а на абонентские - те, что относятся к свитчу, таким образом конфиг портов 25-28(на 24 портовых свитчах) - одинаковые. И рукожопые монтёры, которые придут инсталлить или что-нибудь делать не перепутают аплинки и даунлинки. После пары лет эксплуатации сети пришёл к такому же выводу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sergsa Опубликовано 8 сентября, 2016 · Жалоба У нас есть правило приходящий линк всегда в последний порт. обычно пару последних медных и, если есть, все оптические или модульные, а то всякое бывает второй всегда нужен для проверки первого хотя бы Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Iskatel_S Опубликовано 8 сентября, 2016 · Жалоба Настройте на длинках trafic_segmentation везде, порежьте acl всякий мусор. Настройте loop_detect И собирайте логи с коммутаторов централизованно. Мультикаст тоже стоит ограничить/порезать. По настройкам коммутаторов я как раз ломал голову весь этот месяц. Коммутаторы действительно настроены "кто в лес кто по дрова". Составил политику настройки коммутаторов которая как раз описывает, что должен быть зарезан межабонентский трафик, должны быть включены trafic_segmentation и loop_detect и правилами acl должны блокироваться: левые dhcp-сервера, samba-трафик и ipv6-трафик. Проблема в том, что у нас отсутствует программное обеспечение, которым можно было бы массово опросить все коммутаторы с целью проверить наличие некоторых настроек, собираюсь в будущем внедрить NOC project или D-view, а так всего у нас длинков - 265, заходить телнетом на каждый затрахаешься. И ещё. Я же написал, что снимал дамп программой wireshark в одном из проблемных домов в вечернее время. Если допустим где-то не включён loopdetect и там как раз образована петля, я бы wireshark-ом увидел наличие широковещательного шторма. А тут я вижу, что у меня 99% трафика - tcp-трафик, граф в первом посте приложен. Возможно конечно, что я как-то не так меряю, я же сказал что у меня пока опыта мало. И модель микротика в студию !? CCR-1036 Авторизация какая? Самая тупая. По MAC-адресу. Давайте я угадаю. У топикстартера вся сеть в одном влане. Не угадал. Часть сети разделена влан на дом, часть сети - влан на квартал, есть сегменты где влан на 3-5 кварталов. Всего абонентских подсетей - 68. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 8 сентября, 2016 · Жалоба Не надо никакое по на 256 коммутаторов- пару скриптов на шелле достаточно. Или вообще напишите генератор конфига и залейте все вручную. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Butch3r Опубликовано 8 сентября, 2016 · Жалоба Я уже написал что делать. Проверьте для начало это. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Iskatel_S Опубликовано 8 сентября, 2016 · Жалоба Я уже написал что делать. Проверьте для начало это. Вы написали только кто микротик главный подозреваемый. Что в нём смотреть надо? Процессоры загружены на 5-10%, в логе ничего подозрительного нет. Что ещё смотреть? Не надо никакое по на 256 коммутаторов- пару скриптов на шелле достаточно. Или вообще напишите генератор конфига и залейте все вручную. Эти пару скриптов заколебёшся писать. Я пока застопорился на том как в bash-скрипте реализовать вход по телнету, нужно через секундрую паузу передать пароль ведь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
