Jump to content
Калькуляторы

Iskatel_S

Пользователи
  • Content Count

    20
  • Joined

  • Last visited

About Iskatel_S

  • Rank
    Абитуриент
  1. Да, и у меня появилась ещё одна версия. Прочитал недавно статью как правильно нужно настраивать шейпинг на микротике https://habrahabr.ru/post/188718/ Вобщем у нас всё не так как в статье: дерева очередей в Queue tree нет, наличествуют очереди в Simple Queue и всё, причём очереди типа SFQ.
  2. Ну все сисадмины когда-то были практикантами. По пингам с ноутбука... то есть вы хотите сказать, что простой пинг - более подходящий инструмент для тестирования чем ресурс speedtest.net и btest? И какой пинг в идеале должен быть? Я конечно да, подозреваю что я как раз неправильно средствами измерения пользуюсь. Опять про возможно-неправильное пользование средствами измерения. Логика такая: Петли порождают broadcast-шторм, так? broadcast-трафик - это в основном ARP-запросы и DHCP-запросы, так? DHCP работает по UDP-протоколу, ARP работает по ARP-протоколу, а TCP-протокол изначально чист от broadcast-трафика. create access_profile ip tcp dst_port_mask 0xFFFF profile_id 1 config access_profile profile_id 1 add access_id 1 ip tcp dst_port 135 port 1-9 deny config access_profile profile_id 1 add access_id 2 ip tcp dst_port 137 port 1-9 deny config access_profile profile_id 1 add access_id 3 ip tcp dst_port 138 port 1-9 deny config access_profile profile_id 1 add access_id 4 ip tcp dst_port 139 port 1-9 deny config access_profile profile_id 1 add access_id 5 ip tcp dst_port 445 port 1-9 deny create access_profile ip udp dst_port_mask 0xFFFF profile_id 2 config access_profile profile_id 2 add access_id 1 ip udp dst_port 135 port 1-9 deny config access_profile profile_id 2 add access_id 2 ip udp dst_port 137 port 1-9 deny config access_profile profile_id 2 add access_id 3 ip udp dst_port 138 port 1-9 deny config access_profile profile_id 2 add access_id 4 ip udp dst_port 139 port 1-9 deny config access_profile profile_id 2 add access_id 5 ip udp dst_port 445 port 1-9 deny create access_profile ip udp src_port_mask 0xffff profile_id 3 config access_profile profile_id 3 add access_id 1 ip udp src_port 67 port 1-9 deny create access_profile ethernet ethernet_type profile_id 4 config access_profile profile_id 4 add access_id 1 ethernet ethernet_type 0x86DD port 1-9 deny Мой предшественик делал так: create cpu_access_profile ip udp src_port_mask 0xffff profile_id 1 config cpu_access_profile profile_id 1 add access_id auto_assign ip udp src_port 67 port 1-9 deny
  3. Я уже слышал это мнение и сам прекрасно понимаю, что 1влан-1пользователь - это идеальная схема. Но вы же понимаете, что перейти на эту схему просто так нельзя, нужно приобретать различное ПО: во-первых нужно ПО для автоматического управления свитчами, во-вторых нужна интеграция этого ПО с биллингом, чтобы как только оператор заводит/изменяет в биллинге пользователя - для него сразу же прописывался влан. Вполне может быть так, что систему биллинга вообще придётся менять, а это значит - перенос абонентов в другой биллинг, заказ ПО, стоимость такой модернизации может быть до полумиллиона рублей.
  4. Вы написали только кто микротик главный подозреваемый. Что в нём смотреть надо? Процессоры загружены на 5-10%, в логе ничего подозрительного нет. Что ещё смотреть? Эти пару скриптов заколебёшся писать. Я пока застопорился на том как в bash-скрипте реализовать вход по телнету, нужно через секундрую паузу передать пароль ведь.
  5. По настройкам коммутаторов я как раз ломал голову весь этот месяц. Коммутаторы действительно настроены "кто в лес кто по дрова". Составил политику настройки коммутаторов которая как раз описывает, что должен быть зарезан межабонентский трафик, должны быть включены trafic_segmentation и loop_detect и правилами acl должны блокироваться: левые dhcp-сервера, samba-трафик и ipv6-трафик. Проблема в том, что у нас отсутствует программное обеспечение, которым можно было бы массово опросить все коммутаторы с целью проверить наличие некоторых настроек, собираюсь в будущем внедрить NOC project или D-view, а так всего у нас длинков - 265, заходить телнетом на каждый затрахаешься. И ещё. Я же написал, что снимал дамп программой wireshark в одном из проблемных домов в вечернее время. Если допустим где-то не включён loopdetect и там как раз образована петля, я бы wireshark-ом увидел наличие широковещательного шторма. А тут я вижу, что у меня 99% трафика - tcp-трафик, граф в первом посте приложен. Возможно конечно, что я как-то не так меряю, я же сказал что у меня пока опыта мало. CCR-1036 Самая тупая. По MAC-адресу. Не угадал. Часть сети разделена влан на дом, часть сети - влан на квартал, есть сегменты где влан на 3-5 кварталов. Всего абонентских подсетей - 68.
  6. Коллеги выручайте, месяц уже бьюсь с проблемой, а она всё запутаннее и запутанее. Вобщем есть сеть провайдерская, абонентов на 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. В том-то и дело, что ни чем, но давно уже ломаю себе голову чем можно мониторить нагрузку.
  8. Нужно было прописать влан, но я сделал это через web-интерфейс, потому что не дождался ответа. И вообще спрашивать каждый раз на форумах как что сделать это наверное неправильно, поэтому надо бы посмотреть/почитать какие-нибудь руководства. Для начала хотя бы понять основы, почитав/посмотрев чего-нибудь на русском языке, чтобы уверенно себя чувствовать в "Cisco like CLI", а уже потом, освоившись, штудировать англоязычную документацию. Может кто даст ссылки на видеоуроки по "Cisco like CLI"? Кстати ссылки на этом форуме не работают. А текущая задача есть. На данный момент она следующая: поступают жалобы от абонентов на тормозящий Интернет в вечернее время, причину ситуации вижу в том, что по сети ходит много лишнего трафика. Не заблокирован трафик между абонентами, опытным путём выяснили что кто-то кому-то вечно шлёт какие-то левые пакеты: то это broadcast, то samba, то кто-то кого-то сканирует. На домовых коммутаторах (D-Link) я решаю эту проблему, используя технологии Trafic Segmentation и ACL. Сейчас нужно то же сделать на HP A5500-24G-SFP EI.
  9. "port link-mode" вроде нет такой команды "port link-type" есть
  10. А если это combo-порт? 17/25, 17 - оптика, 25 - медь, подключаюсь по меди, нужно добавить vlan 302.
  11. kapydan А в HP ведь команды не такие как в Cisco? Но там "цисковский стиль командной строки", не помню как он правильно называется, где вложенная система режимов. Я с этим никогда не работал.
  12. Здравствуйте! Есть железка HP A5500-24G-SFP EI Нигде не могу найти внятное руководство по её командам. Может кто ссылку кинет? Если будет ссылка на видеоуроки на русском - это будет ещё лучше.
  13. Какой? 8.8.8.8 или DNS провайдера-аплинка? Есть ещё Яндекс - 77.88.8.8
  14. В реальной жизни клиент обращается сначала к a.root-servers.net, потом к a.dns.ripn.net, потом к ns1.nag.ru и только после этого он будет знать ip ресурса nag.ru, поправьте если не так. Допустим я делаю DNAT для всех запросов, идущих в 53 UDP порт и перенаправляю их на провайдерский сервер. Стоит это делать или нет? С одной стороны клиенты больше не будут обращаться к серверам, расположеным в Америке, запрос к которым будет идти долго - стало быть скорость DNS-запросов должна увеличиться. С другой стороны нужно вычислить сколько запросов в секунду будет в результате обрабатывать сервер и справится ли он. Число абонентов - 1000. Опять же откуда будет брать сервер записи для предоставления клиентам: из собственного кэша или перенаправлять запросы на корневые сервера? Вот вы говорите, что нужны разные политики для запросов к популярным и непопулярным ресурсам. Как их делить, что считать популярным, что нет? У популярных ресурсов IP никогда не меняется, зато у популярных высоконагруженных ресурсов может быть балансировка DNS Round Robin. У непопулярных ресурсов IP может меняться и из-за этого высокий TTL может стать причиной того, что в какой-то момент времени ресурсы могут быть недоступными для наших абонентов. Все эти нюансы мне хотелось бы решить прежде чем начать ставить новый DNS-сервер. Настройки unbound пока не смотрел, выше написали, что что лучше умолчальный конфиг сильно не трогать. Что в умолчальном конфиге нужно поменять?