По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Беспроводные решения вендора MikroTik для сегмента SOHO (Small Office, Home Office) - являются крайне универсальными, и, кроме того, они крайне гибки в плане настроек беспроводных интерфейсов в “простом” режиме.
SOHO продукты - продукты для маленького и/или домашнего офиса
Однако, присутствует также “продвинутый” режим, в котором можно произвести более качественную настройку многих фич. Во многих SOHO моделях, к примеру - RB-750 и RB-951 уже установлены приемлемые заводские настройки, но если произвести несколько изменений - качество подключения может сильно возрасти и, более того, позволить одновременное подключение большего количества пользователей.
Это может сыграть роль, если вы используете SOHO оборудование в небольшом филиале, в котором более десяти пользователей. Особенно учитывая тот факт, что все они используют смартфоны, планшеты и ноутбуки - нагрузка на сеть растет, и, если беспроводная инфраструктура настроена некорректно, все признаки плохого подключения будут видны невооруженным взглядом.
Что делать?
Следующие параметры могут сильно улучшить качество подключения:
frequency-mode=regulatory-domain country=russia
frequency=auto
channel-width=20mhz
wireless-protocol=802.11
distance=indoors
Для того чтобы применить эти настройки, просто скопируйте и вставьте команду ниже:
Данная команда предназначена для маршрутизаторов RB751/951
/interface wireless set wlan1 mode=ap-bridge wireless-protocol=802.11 frequency=auto band=2ghz-b/g/n channel-width=20mhz distance=indoors frequency-mode=regulatory-domain country="russia"
Очевидно, что первый параметр отвечает за регион - в нашем случае, это Россия. Кроме того, в настоящий момент некоторые из этих опций являются стандартными в последней версии RouterOS, однако, почему-то не всегда они установлены корректно.
Также, детальную информацию о данных настройках не всегда можно найти в документации MikroTik, но, по опыту, эти настройки действительно улучшают производительность беспроводной сети. Проверить производительность вашей сети можно проверить на вкладке “Status” информации о беспроводном интерфейсе, вам нужно поле Overall Tx CCQ (Client Connection Quality).
Ниже пример на одном из RB-951 - обратите внимание на очень высокий показатель 97%:
Однако, при установке более новых моделей RB-951 со стоковыми настройками, чаще всего был замечен показатель в районе CCQ < 60%, и это явный знак того, что есть куда двигаться в плане качества подключения.
Заключение
Мы рекомендуем мониторить CCQ в течение нескольких часов на загруженной беспроводной сети, чтобы определить средний уровень, и, затем, применить рекомендованные настройки по очереди, чтобы понять, как они влияют на показатель. Не все из этих настроек универсальны для всех инсталляций, но если вы заметите улучшение CCQ на 10-20% - пользователи обязательно это оценят.
Если вам захотелось автоматизировать рутинные задачи по управлению сетью - присмотритесь к Puppet
Почему и зачем?
В последние десятилетия развитие компьютерных сетей достигает небывалых масштабов. Рост крупных корпораций приводит к тому, что в отдельные сети объединяются сотни и тысячи машин, и это не считая глобальной сети. Темпы этого развития ускоряются с появлением новых программных продуктов, которые позволяют в разы ускорить процессы развертывания и обслуживания сети. Десятки тысяч операций, которые раньше выполнялись вручную, сейчас выполняются за считанные минуты в автоматическом режиме. Одним из таких программных решений стал продукт Puppet. В этой статье мы постараемся подробно осветить плюсы и минусы этой программы.
Что же такое Puppet? Как говорит нам Википедия, это кроссплатформенная система управления и конфигурирования операционных систем, построенная на основе клиент-серверной архитектуры. Если говорить проще - это и есть та самая программа, которая позволяет конфигурировать операционные системы для развертывания, управления и обновления компьютерных сетей на десятках, сотнях и тысячах удаленных машин. Под кроссплатформенностью в данном случае понимается то, что клиентская часть программы полностью совместима и корректно работает на широком спектре самых распространенных операционных систем, что позволяет объединять в единую сеть рабочие станции под Windows, CentOS и Debian. А теперь давайте рассмотрим плюсы и минусы Puppet - ведь не может же все быть прекрасно и красиво.
Кратко о светлых и положительных сторонах решения
Автоматизация: как и говорилось выше Puppet позволяет автоматически конфигурировать операционные системы на удаленных машинах, что избавляет системного инженера десятки раз вручную одинаковым образом настраивать машины, выезжая на места. Можно возразить "а что мешает доверить эту работу нескольким специалистам?" Такой вариант тоже возможен, но это повлечет за собой дополнительные расходы, да и общая надежность системы сильно упадет, поскольку каждый специалист пишет код по-своему, из-за этого может пострадать совместимость.
Скорость развертывания: автоматизация передачи и применения настроек не только экономит ресурсы пользователя, а еще и ускоряет процесс развертывания и обновления сети в десятки раз. Та работа, на которую ранее уходили дни и недели работы, сейчас выполняется за считанные минуты. Это позволяет разгрузить занятость сетевого инженера и высвободить его время для решения других задач - например, для разработки программного обеспечение или работы с клиентами.
Кроссплатформенность: однозначным плюсом этого решения является поддержка различных операционных систем. На заре становления компьютерных сетей невозможность взаимодействия из-за конфликтов кода вынуждало корпорации применять одни и те же операционные системы на всех рабочих станциях компании, что снижало эффективность за счет узкой специализации ОС. Сейчас Puppet позволяет включать в общую сеть компьютеры под различными операционными системами, и обеспечивать их эффективное взаимодействие. Это позволяет увеличить общую эффективность деятельности компании в несколько раз
Поддержка: программа достаточно проста в использовании. Однако, иногда возникают проблемы. Puppet имеет техническую поддержку, специалисты которой фиксируют обращения пользователей и работают над исправлением проблем. Продукт развивается непрерывно, поэтому каждая следующая версия работает все более эффективно.
Общая безопасность системы: поскольку Puppet обновляет конфигурацию множества узлов системы параллельно, не составляет особых сложностей применить в конфигурировании клиентских операционных систем гибкие настройки безопасности. Это обеспечивает достаточно эффективную защиту данных от внешних угроз.
Вы спросите неужели всё так идеально? Добавим в описание ложку дегтя разберем минусы Puppet
Квалификация администратора: обслуживание сети с помощью Puppet рекламируется как довольно простое. Однако, обслуживание крупных сетей всегда требует от администратора высокой квалификации и предельной внимательности. Если при составлении файла конфигурации допустить ошибку, и затем не проверить этот файл должным образом, можно одним махом "положить" несколько сотен серверов. Конечно, откат системы к предыдущей конфигурации настроек восстановит ее работу, но в современном бизнесе любая потеря времени чревата крупными убытками компании. Поэтому сетевой специалист должен быть ответственным и внимательным.
Несовместимость с некоторыми версиями ОС: так себе минус, скажете вы. Ну кому сейчас потребуется совместимость с ранними версиями Windows NT? Однако, как показывает практика, кое-где такие сервера до сих пор успешно применяются. В основном, это актуально для небольших компаний с невысокой нагрузкой на сеть. Однако, принцип "работает и ладно" неприменим для современного бизнеса, в котором, чтобы оставаться на плаву, нужно непрерывно улучшать свой продукт.
Уязвимость сервера Puppet: централизованное управление сетью может легко породить такую проблему. Безопасность сервера должна стоять превыше всего. Если злоумышленник получит доступ к серверу Puppet, то может сконфигурировать клиентские операционные системы так, как ему заблагорассудится. Например, отдать команды на шифрование данных, или же на их удаление. В этом случае убытки компании-пользователя не поддадутся исчислению. Эта проблема решается установкой современных механизмов защиты сервера от внешних угроз. Но, как известно, стоимость защиты информации не должна превышать стоимость самой информации, а значит здесь нужно руководствоваться в первую очередь здравым смыслом и пониманием базовых принципов информационной безопасности.
Очевидно, что плюсов больше, чем минусов - но решать всегда только вам. Опять же, Puppet - не единственный игрок подобного класса решений, и всегда имеет смысл посмотреть и попробовать все, что доступно на рынке - ведь вы никогда не ошибетесь, если поступите правильно :)
В многоуровневой и/или модульной системе должен быть какой-то способ связать услуги или объекты на одном уровне с услугами и объектами на другом. Рисунок 1 иллюстрирует проблему.
На рисунке 1
Как A, D и E могут определить IP-адрес, который они должны использовать для своих интерфейсов?
Как D может обнаружить Media Access Control адрес (MAC), физический адрес или адрес протокола нижнего уровня, который он должен использовать для отправки пакетов на E?
Как может client1.example, работающий на D, обнаружить IP-адрес, который он должен использовать для доступа к www.service1.example?
Как D и E могут узнать, на какой адрес они должны отправлять трафик, если они не на одном и том же канале или в одном и том же сегменте?
Каждая из этих проблем представляет собой отдельную часть interlayer discovery. Хотя эти проблемы могут показаться не связанными друг с другом, на самом деле они представляют собой один и тот же набор проблем с узким набором доступных решений на разных уровнях сети или стеках протоколов. В лекции будет рассмотрен ряд возможных решений этих проблем, включая примеры каждого решения.
Основная причина, по которой проблемное пространство interlayer discovery кажется большим набором не связанных между собой проблем, а не одной проблемой, состоит в том, что оно распределено по множеству различных уровней; каждый набор уровней в стеке сетевых протоколов должен иметь возможность обнаруживать, какая услуга или объект на «этом» уровне относится к какой услуге или объекту на каком-либо более низком уровне. Другой способ описать этот набор проблем - это возможность сопоставить идентификатор на одном уровне с идентификатором на другом уровне - сопоставление идентификаторов. Поскольку в наиболее широко применяемых стеках протоколов есть по крайней мере три пары протоколов , необходимо развернуть широкий спектр решений для решения одного и того же набора проблем межуровневого обнаружения в разных местах. Два определения будут полезны для понимания диапазона решений и фактически развернутых протоколов и систем в этой области:
Идентификатор - это набор цифр или букв (например, строка), которые однозначно идентифицируют объект.
Устройство, реальное или виртуальное, которое с точки зрения сети кажется единым местом назначения, будет называться объектом при рассмотрении общих проблем и решений, а также хостами или услугами при рассмотрении конкретных решений.
Есть четыре различных способа решить проблемы обнаружения interlayer discovery и адресации:
Использование известных и/или настроенных вручную идентификаторов
Хранение информации в базе данных сопоставления, к которой службы могут получить доступ для сопоставления различных типов идентификаторов.
Объявление сопоставления между двумя идентификаторами в протоколе
Вычисление одного вида идентификатора из другого
Эти решения относятся не только к обнаружению, но и к присвоению идентификатора. Когда хост подключается к сети или служба запускается, он должен каким-то образом определить, как он должен идентифицировать себя - например, какой адрес Интернет-протокола версии 6 (IPv6) он должен использовать при подключении к локальной сети. Доступные решения этой проблемы - это те же четыре решения.
Хорошо известные и/или настраиваемые вручную идентификаторы
Выбор решения часто зависит от объема идентификаторов, количества идентификаторов, которые необходимо назначить, и скорости изменения идентификаторов. Если:
Идентификаторы широко используются, особенно в реализациях протоколов, и сеть просто не будет работать без согласования межуровневых сопоставлений и ...
Количество сопоставлений между идентификаторами относительно невелико, и ...
Идентификаторы, как правило, стабильны - в частности, они никогда не изменяются таким образом, чтобы существующие развернутые реализации были изменены, чтобы сеть могла продолжать функционировать, а затем ...
Самым простым решением является ведение какой-либо таблицы сопоставления вручную.
Например, протокол управления передачей (TCP) поддерживает ряд транспортных протоколов более высокого уровня. Проблема соотнесения отдельных переносимых протоколов с номерами портов является глобальной проблемой межуровневого обнаружения: каждая реализация TCP, развернутая в реальной сети, должна иметь возможность согласовать, какие службы доступны на определенных номерах портов, чтобы сеть могла «работать». Однако диапазон межуровневых сопоставлений очень невелик, несколько тысяч номеров портов необходимо сопоставить службам, и довольно статичен (новые протоколы или службы добавляются не часто). Таким образом, эту конкретную проблему легко решить с помощью таблицы сопоставления, управляемой вручную.
Таблица сопоставления для номеров портов TCP поддерживается Internet Assigned Numbers Authority (IANA) по указанию Engineering Task Force (IETF); Часть этой таблицы показана на рисунке 2. На рисунке 2 службе echo назначен порт 7; эта служба используется для обеспечения функциональности ping.
База данных и протокол сопоставления
Если число записей в таблице становится достаточно большим, число людей, участвующих в обслуживании таблицы, становится достаточно большим или информация достаточно динамична, чтобы ее нужно было изучать во время сопоставления, а не при развертывании программного обеспечения, имеет смысл создавать и распространять базу данных динамически. Такая система должна включать протоколы синхронизации разделов базы данных для представления согласованного представления внешним запросам, а также протоколы, которые хосты и службы могут использовать для запроса базы данных с одним идентификатором, чтобы обнаружить соответствующий идентификатор из другого уровня сети.
Базы данных динамического сопоставления могут принимать входные данные с помощью ручной настройки или автоматизированных процессов (таких как процесс обнаружения, который собирает информацию о состоянии сети и сохраняет полученную информацию в динамической базе данных). Они также могут быть распределенными, что означает, что копии или части базы данных хранятся на нескольких различных хостах или серверах, или централизованными, что означает, что база данных хранится на небольшом количестве хостов или серверов.
Система доменных имен (DNS) описывается как пример службы сопоставления идентификаторов, основанной на динамической распределенной базе данных. Протокол динамической конфигурации хоста (DHCP) описан в качестве примера аналогичной системы, используемой в основном для назначения адресов.
Сопоставления идентификаторов объявления в протоколе
Если объем проблемы сопоставления может быть ограничен, но количество пар идентификаторов велико или может быстро меняться, то создание единого протокола, который позволяет объектам запрашивать информацию сопоставления напрямую от устройства, может быть оптимальным решением. Например, на рисунке 1 D может напрямую спросить E, какой у него локальный MAC-адрес (или физический).
Интернет протокол IPv4 Address Resolution Protocol (ARP) является хорошим примером такого рода решений, как и протокол IPv6 Neighbor Discovery (ND).
Вычисление одного идентификатора из другого
В некоторых случаях можно вычислить адрес или идентификатор на одном уровне из адреса или идентификатора на другом уровне. Немногие системы используют этот метод для сопоставления адресов; большинство систем, использующих этот метод, делают это для того, чтобы назначить адрес. Одним из примеров такого типа систем является Stateless Address Autoconfiguration (SLAAC), протокол IPv6, который хосты могут использовать для определения того, какой IPv6-адрес должен быть назначен интерфейсу.
Другим примером использования адреса нижнего уровня для вычисления адреса верхнего уровня является формирование адресов конечных систем в наборе протоколов International Organization for Standardization (ISO), таких как Intermediate System to Intermediate System (IS-IS).