Всем доброго времени суток!
На сегодняшний день в непростой эпидемиологической ситуации система высшего образования и науки переживает трансформацию. Формируется гибридное обучающее пространство, позволяющее гармонично сочетать форматы дистанционного и очного обучения. Специфика работы большинства IT-специалистов позволяет без труда перейти на удаленный формат. Однако, не каждому человеку удается при этом сохранить продуктивность и позитивный настрой на длительной дистанции. Чтобы внести разнообразие в процесс обучения студентов, было принято решение о записи видеоконсилиумов – небольших обзорных и прикладных лекций в виде дискуссии с ведущими экспертами определенной предметной области.
Ключевые темы обсуждений посвящены информационно-коммуникационным технологиям: от системного и сетевого администрирования до кибербезопасности и программирования. Не обойдем стороной и юридические аспекты работы в IT, становление бизнеса в нашей индустрии и привлечение инвестиций (в том числе грантов и субсидий). Дополнительно рассмотрим материал о системе высшего образования и науки, в том числе возможности бесплатного обучения за границей.
Итак, один из первых консилиумов мы решили посвятить теме «Базовая настройка управляемого сетевого оборудования» и пригласили на него одного из ведущих мировых лидеров и производителей сетевых решений корпоративного класса, а также профессионального телекоммуникационного оборудования – компанию D-Link.
Представим, что перед нами стоит задача базовой настройки управляемого сетевого оборудования (от коммутатора и маршрутизатора до комплексного межсетевого экрана). Стоит отметить, что каждое устройство функционирует на определенных уровнях стека протоколов TCP/IP и выполняет соответствующий функционал. Рассматривать последовательность настройки мы будем от коммутаторов, постепенно переходя к более сложным функциям и технологиям, которые присущи маршрутизаторам и межсетевым экранам. При этом базовые этапы и рекомендации будут оставаться полезными.
Управляемые сетевые устройства можно конфигурировать посредством следующих инструментов и технологий:
Рассмотрим базовый алгоритм настройки управляемого сетевого оборудования после подключения к нему
Безусловно, без внимания остались и другие не менее интересные технологии, но не все сразу.
Подробнее с темой Вы можете ознакомиться в видеоконсилиуме.
Надеюсь, материал был интересен и полезен. Если подобный формат понравится студентам и сообществу Хабра, то постараемся и дальше записывать интересные консилиумы.
Время на прочтение
Хотим поделиться с вами вольным переводом статьи с сайта Packet Pushers о сложностях конфигурирования мультивендорных сетей. В первую очередь, с ними сталкиваются операторы связи. По мере того, как провайдер развивается (в т. ч. поглощая других операторов), его сеть растет и превращается в сложную экосистему различного оборудования. В небольших сетях эта проблема, как правило, стоит не так остро. Что, впрочем, обусловлено ею же — компании стараются без веских на то причин не закупать в свою сеть железо разных производителей. Сложности настройки здесь заставляют тяготеть к моновендорности.
Одна из проблем автоматизации сетей состоит в том, что у нас нет стандартизованных интерфейсов для настройки сетевого оборудования различных производителей. Другими словами, сложно сконфигурировать многовендорную сеть с помощью программных средств, когда на каждом устройстве этот процесс отличается.
При управлении через командную строку (Command Line Interface — CLI), сетевые операторы сталкиваются со значительными отличиями в её синтаксисе на оборудовании разных производителей. Например, команды, которыми протокол BGP настраивается на устройстве Cisco под управлением операционной системы IOS, не подойдут для выполнения той же задачи на устройстве Juniper под управлением JUNOS. Переход с командной строки на конфигурирование оборудования через интерфейсы прикладного программирования (API) не решает проблему. Интерфейсы, предлагаемые производителями сетевого оборудования, по реализации и функциональности отличаются друг от друга не меньше CLI. Отчасти это обусловлено спецификой сетевых операционных систем. Не во все сетевые ОС закладывалась возможность использовать API, и производителям бывает непросто встроить их поддержку в свои продукты.
Один из вариантов реализации программной настройки сетевого оборудования – конфигурационные модели. Модель данных определяет структуру, синтаксис и семантику данных, которые мы загружаем на сетевое оборудование. При их передаче, в связке с моделью данных действует протокол, который определяет их кодирование и сам механизм передачи на устройство. Другими словами, модель определяет правила, с помощью которых мы задаем параметры конфигурации сетевого оборудования. А транспортный протокол передаёт эти данные на оборудование. Конфигурационную модель можно сравнить с протоколом SNMP, который изначально был разработан для управления сетевыми устройствами, но в силу ряда причин используется в основном для мониторинга. — прим. ред.
Для нас, привыкших рассматривать всякое сетевое устройство, исходя из интерфейса его командной строки, «модель» представляется в виде строк конфигурации. К примеру, «interface gigabitethernet 0/1» или «router bgp 65432» открывает пользователю Cisco IOS режим конфигурации Ethernet-интерфейса или процесса BGP-маршрутизации. А транспортом в этом случае выступает протокол SSH.
Многие понимают, что будущее конфигурирования сетевых устройств остаётся за интерфейсами прикладного программирования. Но отойдя от командной строки, мы не ушли от главной проблемы: унификация настройки оборудования теперь затрудняется не синтаксисом командной строки, а моделями данных для протоколов вроде NETCONF, созданными на базе описательных языков моделирования. Эти модели часто пишут на базе языка YANG и они, как и синтаксис командной строки, сильно разнятся от производителя к производителю. В результате, пользователи остаются всё с той же проблемой: на разном железе процесс выполнения одной и той же задачи по-прежнему отличается.
Разнообразие — совсем не изюминка
Индустрия сталкивается с проблемой: мы хотим автоматизировать процесс конфигурирования сети, но не можем предугадать, какие модели и интерфейсы для этого понадобятся. Звучит очень знакомо. Вспомним о протоколе SNMP. S NMP — общепринятый стандарт. Все сетевые устройства поддерживают те или иные элементы баз MIB. Тем не менее, наиболее важные параметры уникальны для каждого производителя оборудования и требуют использования специфичных баз MIB.
Сможем ли мы облегчить этот конфигурационный кошмар, перейдя с CLI и SNMP на NETCONF (или любой другой способ передачи конфигурации) с YANG-моделями?
Производители, естественно, будут отстаивать уникальность своих решений, а также абсолютную необходимость использования моделей, которые соответствуют их конкретным возможностям. И их можно понять. Было бы несправедливо критиковать производителей за их стремление отличаться от конкурентов.
В свою очередь, сетевые операторы имеют такое же право отстаивать идею, что сети есть сети. B GP это BGP, ISIS это ISIS, OSPF это OSPF, а интерфейс Ethernet (по большей части) это интерфейс Ethernet, и т.д. И какая разница, конфигурируем мы железку Cisco, Juniper, Brocade или что-то ещё. Если на каждой из них нужно настроить одну и ту же функцию, несложно догадаться, что хотелось бы, чтобы она везде настраивалась одинаково! Как можно автоматизировать конфигурирование сети, когда, стоит нам только отвернуться, как где-то уже нужно подправить скрипт, добавить модуль, подождать, пока инструмент автоматизации получит патч от производителя, или потребуются ещё какие-нибудь пляски с бубном?
OpenConfig и IETF приходят к стандартным сетевым моделям
Сложившаяся ситуация беспокоит не только автора. У IETF есть несколько проектов разной степени завершенности, направленных на разработку стандартных сетевых моделей на базе YANG. К примеру: модель для управления сетевыми интерфейсами RFC7223, модель для инвентаризации и управления RFC7317, модель для настройки протокола SNMP RFC7407, а также модель для настройки протокола OSPF. Но для кого-то работа IETF продвигается слишком медленно, а кому-то просто не подходят модели, которые они предлагают.
В связи с этим, несколько крупных компаний решили приблизить переход на стандартные сетевые модели, организовав проект OpenConfig. На главной странице OpenConfig пишет о себе так:
«OpenConfig — это неформальная рабочая группа операторов сетей, объединенных общей целью — перевести сети на более динамичную программируемую инфраструктуру путем внедрения принципов программно-определяемых сетей, таких как декларативная конфигурация и управление на основе моделей. Основное направление нашей работы — разработка единых моделей данных для конфигурации и управления, поддержка которых изначально встроена в программные и аппаратные платформы различных производителей оборудования»
На заре своей деятельности «неформальная рабочая группа» OpenConfig весьма продуктивно работала, создавая модели для BGP, MPLS и управления интерфейсами. Сейчас в доступе есть разные модели (например, модель для сетевой телеметрии). Все они опубликованы на Github, и быстро эволюционируют, ведь именно для быстрой эволюции OpenConfig и создавался. На странице FAQ OpenConfig пишут: «На данный момент формального руководства у проекта нет. Мы полагаемся на то, что у участников здесь общие цели и видение, их действия прозрачны и по общим вопросам они стараются поддерживать согласие».
Конечно, если начинать размышлять о проекте вроде OpenConfig, обнаружатся два главных повода для беспокойства:
Рассмотрим первый — поддержку производителями. Для производителей сетевого оборудования главный вопрос здесь состоит в том, насколько сложно им будет приспособить существующие сетевые ОС к работе на основе моделей. Например, для компании Juniper поддержка моделей IETF и OpenConfig не составит труда. J UNOS и так, по сути своей, управляется моделями. К тому же, Juniper намекает (к сожалению, ссылок на эти намеки автор не дает — прим. ред.), что поддержка OpenConfig будет в ближайших версиях JUNOS (возможно даже в 16.1). Компания Cisco анонсировала поддержку OpenConfig для IOS-XR (NCS, ASR, CRS, XR) ещё в ноябре 2015 (уже доступна поддержка двух моделей OpenConfig — BGP и Route Policy — прим. ред.).
Добавят ли другие производители поддержку моделей OpenConfig? Время покажет. Но есть сильные подозрения, что так и будет. Вспомните, кто стоит за этой инициативой. Деньги в сетевой индустрии имеют право голоса. Потребитель, который может заплатить, как правило, получает, чего хочет.
Как же IETF? OpenConfig идёт своей дорогой? И да, и нет. Всё несколько сложнее. Проект OpenConfig начинался отчасти как реакция на слабо упорядоченную и неспешную работу IETF. Тем не менее, OpenConfig сотрудничает с IETF, помогая им развивать различные стандарты. На странице годового отчета OpenConfig за 2015 внизу перечислены проекты, созданные рабочей группой OpenConfig для IETF. Так что, хоть OpenConfig и не желает ждать, пока IETF разберется со своими моделями, он признаёт важность IETF и даже привносит собственный вклад в их дело.
Что может дать OpenConfig?
Основная идея в том, что OpenConfig ориентируется только на модели, уделяя меньшее внимание законченным API, включающим в себя как модель, так и транспорт (подробнее вопрос раскрывается в статье Джейсона Эделмана). Ведь наша главная цель — достичь целостности и предсказуемости модели на всех сетевых устройствах. Инструменты (транспорт), которыми мы загружаем модели на оборудование, важны, но в их случае проблема выбора и унификации стоит не так остро, как с представлением и моделированием данных. По большому счёту, нам всё равно, как данные были загружены. Но очень важно, чтобы они были представлены в нужном нам формате — чтобы мы могли их понять, то есть, чтобы наши инструменты легко могли их проанализировать и работать с ними.
Когда стандартные сетевые модели станут встречаться повсеместно, мир откроется для разработки инструментария, платформ оркестровки, ПО для мониторинга и SDN контроллеров, и на рынке появятся прекрасные инструменты для конфигурирования и отчетности. Производителям ПО больше не нужно будет ориентироваться на самых распространенных вендоров, решая, чьё оборудование поддерживать, ведь рынком для них будет весь мир сетей.
Ethan Banks, январь 2016
Вопрос наличия стандартных подходов для конфигурирования сетевого оборудования разных производителей возник давным-давно. Тот же протокол SNMP был одной из попыток его решить. Он оставался нерешённым так долго, что к ситуации все вроде как даже привыкли. Появление программно-определяемых сетей подняло его на поверхность в очередной раз. Идея подключения к контроллеру любого сетевого оборудования предполагает наличие стандартных средств общения между контроллером и устройством. Параллельно с этим возникла необходимость в средствах обеспечения автоматизации конфигурирования сетей — их программируемости. Если раньше для настройки сетевого оборудования чаще всего использовались командная строка и Web-интерфейс, то сейчас многие производители активно добавляют поддержку различных интерфейсов прикладного программирования (OpenFlow, OpenStack, JSON, XML, NETCONF/YANG и пр.). Причём даже в рамках одного вендора нам предлагают целый букет таких средств. В связи с этим, идея OpenConfig вполне здравая и уместная в плане времени появления.
Статья получилась, на наш взгляд, чуточку утопической в силу огромного стремления производителей сетевого оборудования быть уникальными. Согласившись на полноценную стандартизацию, они рискуют превратить свои устройства в безликие коробки. Скорее всего, поддержка OpenConfig ограничится программированием определённых функций. Как обычно, время всё расставит на свои места.
Примерно 80% из нас, кто заканчивает университет с какой-либо IT-специальностью, в итоге не становится программистом. Многие устраиваются в техническую поддержку, системными администраторами, мастерами по наладке компьютерных устройств, консультантами-продавцами цифровой техники, менеджерами в it-сферу и так далее.
Эта статья как раз для таких 80%, кто только закончил университет с какой-либо IT-специальностью и уже начал мониторить вакансии, например, на должность системного администратора или его помощника, либо выездного инженера в аутсорсинговую фирму, либо в техническую поддержку 1-й/2-й линии.
А также для самостоятельного изучения или для обучения новых сотрудников.
За время своей трудовой деятельности в сфере IT я столкнулся с такой проблемой, что в университетах не дают самую основную базу касательно сетей. С этим я столкнулся сначала сам, когда, после окончания университета, ходил по собеседованиям в 2016 году и не мог ответить на простые (как мне сейчас кажется) вопросы. Тогда мне конечно показалось, что это я прохалтурил и не доучил в университете. Но как оказалось дело в образовательной программе. Так как сейчас, я также сталкиваюсь с данным пробелом знаний, когда обучаю новых сотрудников.
И что тогда, мне пришлось изучить множество статей в интернете, прежде чем я понял базовые моменты, и что сейчас, задавая молодым специалистам темы для изучения, они с трудом находят и усваивают необходимое. Это происходит по причине того, что в Интернете огромное количество статей и все они разрозненны по темам, либо написаны слишком сложным языком. Плюс большинство информации в начале своих статей содержат в основном просто научные определения, а дальше сразу сложные технологии использования. В итоге получается много того, что для начинающего пока совсем непонятно.
Именно поэтому я решил собрать основные темы в одну статью и объяснить их как можно проще «на пальцах».
Сразу предупреждаю, что никакой углубленной информации в статье не будет, только исключительно самая база и самое основное.
Темы, которые рассмотрены:
Глобальные и Локальные сети
Вся интернет сеть подразделяется на глобальную (WAN) и локальную (LAN).
Все пользовательские устройства в рамках одной квартиры или офиса или даже здания (компьютеры, смартфоны, принтеры/МФУ, телевизоры и т.д.) подключаются к роутеру, который объединяет их в локальную сеть.
Выход в глобальную сеть обеспечивает интернет провайдер, за что мы и платим ему абонентскую плату. Провайдер устанавливает на своих роутерах уровень скорости для каждого подключения в соответствии с тарифом. Провайдер прокидывает нам витую пару или оптику до нашего роутера (нашей локальной сети) и после этого любое устройства нашей локальной сети может выходить в глобальную сеть.
Для аналогии, сети, можно сравнить с дорогами.
Например, дороги вашего города N это локальная сеть. Эти дороги соединяют вас с магазинами, учреждениями, парками и другими местами вашего города.
Чтобы попасть в другой город N вам необходимо выехать на федеральную трассу и проехать некоторое количество километров. То есть выйти в глобальную сеть.
Для более наглядного представления, что такое глобальная и локальная сеть я нарисовал схематичный рисунок.
Белые и серые IP-адреса
Так вот это локальный адрес вашего устройства.
Существуют разрешенные диапазоны локальных сетей:
Думаю из представленной таблицы сразу становится понятно почему самый распространенный диапазон это 192.168. X. X
NAT
NAT работает на всех роутерах и позволяет нам из локальной сети выходить в глобальную.
Для лучшего понимания разберем два примера:
То есть, в этом случае получается, что ваши устройства находятся за двойным NAT’ом.
Такая схема имеет более высокую степень безопасности ваших устройств, но также и имеет ряд больших минусов. Например, нестабильная sip-регистрация VoIP оборудования или односторонняя слышимость при звонках по ip-телефонии.
Более подробно о работе механизма NAT, о его плюсах и минусах, о выделении портов, о сокетах и о видах NAT я напишу отдельную статью.
DHCP — сервер и подсети
Можно настроить несколько DHCP-серверов на одном роутере. Тогда локальная сеть разделится на подсети.
Например, компьютеры подключим к нулевой подсети в диапазон 192.168.0.2-192.168.0.255, принтеры к первой подсети в диапазон 192.168.1.2-192.168.1.255, а Wi-Fi будем раздавать на пятую подсеть с диапазоном 192.168.5.2-192.168.5.255 (см. схему ниже)
Обычно, разграничение по подсетям производить нет необходимости. Это делают, когда в компании большое количество устройств, подключаемых к сети и при настройке сетевой безопасности.
Но такая схема в компаниях встречается довольно часто.
Поэтому обязательно нужно знать очень важный момент.
Внимание!
Если вам необходимо с ПК зайти на web-интерфейс, например, принтера или ip-телефона и при этом ваш ПК находится в другой подсети, то подключиться не получится.
Для понимания разберем пример:
Также и к МФУ (172.17.17.10) вы сможете подключиться только с ПК4 (172.17.17.12).
Устройства маршрутизации сети (маршрутизатор, коммутатор, свитч, хаб)
Как ни странно, но есть такой факт, что новички в IT (иногда и уже действующие сис.админы) не знают или путают такие понятия как маршрутизатор, коммутатор, свитч, сетевой шлюз и хаб.
Я думаю, причина такой путаницы возникла из-за того, что наплодили синонимов и жаргонизмов в названиях сетевого оборудования и это теперь вводит в заблуждение многих начинающих инженеров.
а) Роутер, маршрутизатор и сетевой шлюз
Все знают что такое роутер. Что это именно то устройство, которое раздает в помещении интернет, подключенный от интернет провайдера.
Так вот маршрутизатор и сетевой шлюз это и есть роутер.
Данное оборудование является основным устройством в организации сети. В инженерной среде наиболее используемое название это “маршрутизатор”.
Кстати маршрутизатором может быть не только приставка, но и системный блок компьютера, если установить туда еще одну сетевую карту и накатить, например, RouterOS Mikrotik. Далее разрулить сеть на множество устройств с помощью свитча.
б) Что такое Свитч и чем он отличается от Коммутатора и Хаба
Свитч и Коммутатор это тоже синонимы. А вот хаб немного другое устройство. О нем в следующем пункте (в).
Коммутатор (свитч) служит для разветвления локальной сети. Как тройник или сетевой фильтр, куда мы подключаем свои устройства, чтобы запитать их электричеством от одной розетки.
У стандартного маршрутизатора обычно 4-5 портов для подключения устройств. Соответственно, если ваши устройства подключаются проводами и их больше чем портов на роутере, то вам необходим свитч. Можно к одному порту роутера подключить свитч на 24 порта и спокойно организовать локальную сеть на 24 устройства.
А если у вас завалялся еще один роутер, то можно в его web-интерфейсе включить режим коммутатора и тоже использовать как свитч.
Хаб выполняет те же функции, что и коммутатор. Но его технология распределения сильно деревянная и уже устарела.
Хаб раздает приходящие от роутера пакеты всем подключенным устройствам без разбора, а устройства уже сами должны разбираться их это пакет или нет.
А коммутатор имеет MAC таблицу и поэтому распределяет приходящие пакеты на одно конкретное устройство, которое и запрашивало этот пакет. Следовательно передача данных коммутатором быстрее и эффективнее.
В настоящее время уже редко где встретишь использование хаба, но всё таки они попадаются, нужно быть к этому готовым и обязательно рекомендовать пользователю замену хаба на свитч.
Основные команды для анализа сети
а) Команда Ping
Здесь мы “пинганули” dns сервер google и, как видим, сервер активен (отклик на пинги есть и равен 83 мс).
То есть ответа на пинги не получаем.
Но Ping намного полезней использовать с ключами:
-t -”пинговать” непрерывно (для остановки нажимаем комбинацию Ctrl+С)
-а -отображать имя “пингуемого” узла (сайта/устройства/сервера)
Соответственно ключ “-а” нам показал, что имя пингуемого узла “dns.google”.
А благодаря ключу “-t” ping шел без остановки, я остановил его, нажав Ctrl+C.
При непрерывном пинге можно увидеть адекватно ли ведет себя пингуемый узел и примерное качество работы интернет канала.
Как видим из скриншота, периодически возникают задержки приема пакета аж до 418 мс, это довольно критичное значение, так как скачок с 83 мс до 418 мс отразился бы на видеосвязи торможением/зависанием изображения или в ip-телефонии деградацией качества голоса.
В моем случае, скорей всего штормит мой домашний Интернет.
Но чтобы более детально установить причину, это нужно запускать dump. А это тема для целой статьи.
Внимание! Иногда на роутерах отключена отправка ICMP пакетов (кто-то отключает специально, а где-то не включена по умолчанию), в таком случае на “пинги” такой узел отвечать не будет, хотя сам будет активен и нормально функционировать в сети.
Иногда очень важно увидеть каким путем идет пакет до определенного устройства.
Возможно где-то есть пробоина и пакет не доходит до адресата. Так вот утилита трассировки помогает определить на каком этапе этот пакет застревает.
Здесь мы увидели через какие узлы проходит наш запрос, прежде чем дойдет до сервера ya.ru
На ОС Linux эта утилита вызывается командой traceroute.
Утилитой трассировки также и обладают некоторые устройства, маршрутизаторы или голосовые VoIP шлюзы.
в) Утилита whois
Я пользуюсь ей только на Linux. Утилита качается и устанавливается легко из стандартного репозитория операционной системы.
Но также читал, что и на Windows есть подобное решение.
Транспортные протоколы TCP и UDP
Все передачи запросов и прием ответов между устройствами в сети осуществляются с помощью транспортных протоколов TCP и UDP.
TCP протокол гарантированно осуществляет доставку запроса и целостность его передачи. Он заранее проверяет доступность узла перед отправкой пакета. А если по пути целостность пакета будет нарушена, то TCP дополнит недостающие составляющие.
В общем, это протокол, который сделает все, чтобы ваш запрос корректно дошел до адресата.
Поэтому TCP самый распространенный транспортный протокол. Он используется когда пользователь серфит интернет, лазает по сайтам, сервисам, соц. сетям и т.д.
UDP протокол не имеет такой гарантированной передачи данных, как TCP. Он не проверяет доступность конечного узла перед отправкой и не восполняет пакет в случае его деградации. Если какой-то пакет или несколько пакетов по пути утеряны, то сообщение дойдет до адресата в таком неполном виде.
Зачем тогда нужен UDP?
Дело в том, что данный транспортный протокол имеет огромное преимущество перед TCP в скорости передачи данных. Поэтому UDP широко используется для пересылки голосовых и видео пакетов в реальном времени. А именно, в ip-телефонии и видео звонках.
К примеру, любой звонок через WhatsApp или Viber использует транспортный протокол UDP. Также и при видео звонках, например, через Skype или те же мессенджеры WhatsApp и Viber.
Именно потому что UDP не гарантирует абсолютную передачу данных и целостность передаваемого пакета, зачастую возникают проблемы при звонках через интернет.
Это прерывание голоса, запаздывание, эхо или робоголос.
Данная проблема возникает из-за нагруженного интернет канала, двойного NATа или радиоканала.
Хорошо бы конечно в таких случаях использовать TCP, но увы, для передачи голоса необходима мгновенная передача целостных пакетов, а для этой задачи идеально подходит UDP.
Чтобы не возникало проблем с использованием UDP протокола, нужно просто организовать качественный интернет канал. А также настроить на роутере выделенную полосу для UDP, чтобы нагрузка с других устройств, которые используют TCP не мешала работе транспортного протокола UDP.
На этом всё.
Я не стал нагромождать статью и копипастить сюда научные определения всех используемых терминов, кому это необходимо, просто загуглите.
Я постарался собрать воедино 7 самых важных, на мой взгляд, моментов, знание которых, помогут юному “айтишнику” пройти первые этапы собеседования на “айтишные” должности или хотя бы просто дать понять работодателю, что вы явно знаете больше, чем рядовой юзер.
Изучайте, конспектируйте. Надеюсь, что статья многим принесет пользу.
Первый этап — подбор оборудования
Настройка начинается с выбора подходящего сетевого компонента. Вариантов несколько — свитч (switch), роутер (router) или беспроводная точка доступа. Причем они могут комбинироваться, если вы планируете создание не только локальной сети, но и подключение к глобальной. В чем разница между этими устройствами?
Для самой простой связи домашних компьютеров в одну систему подойдет относительно дешевый свитч. Дороже обойдутся роутеры и беспроводные точки. Выбирайте подходящие компоненты, исходя из своих потребностей и финансовых возможностей. На рынке они представлены в большом количестве.
Настройка сетевого оборудования
Чтобы сеть в доме, офисе или на предприятии работала результативно, нужно сделать качественную настройку сетевого оборудования.
Настройка оборудования сети – последняя стадия настройки сети. Чем запутанее система и чем больше количество компьютеров и прочих приспособлений она объединяет, тем сложнее ее настроить.
Для наладки работы локальной сети нужны профессиональная подготовка и знание дела. Настройка оборудования обычно отнимает больше времени, чем установка самой системы.
От того, насколько качественно будут оптимизированы параметры каждого оборудования на работу в общей сетевой системе, будет зависеть производительность сети. Следственно, эффективность и согласованность работы персонала офиса или конторы.
Не раз при помощи сети пересылаются разные виды трафика, и при этом нужно реализовать отладку приложений различных видов и содействие пользователям различных классов. Когда настройка оборудования сети производится некорректно, то качество обслуживания обычно оставляет желать лучшего.
Компания CompHelp осуществляет такие виды работ по обслуживанию и починке оборудования сети в Киеве.
В процессе настройки оборудования сетевой системы профессионалам компании CompHelp выполняется анализ трафика и мониторинг сети, диагностика путей, установка программного обеспечения, отладка управления.
Настройка и оптимизация эффективной работы и слаженности всех составляющих сети позволяет использовать ресурсы сетевой системы с максимальной продуктивностью. Что, безусловно, хорошо отобразится на продуктивности работы на предприятии.
Часто за работу по отладке оборудования сетевой системы берутся дилетанты. Некорректная настройка не только не откроет доступ ко всем возможностям системы, но может причинить сбои в работе составляющих сети.
Персонал компании CompHelp обладает глубокой базой в отношении IT-технологий и большим опытом по прокладке сетевых систем и оптимизации оборудования сети.
В короткое время наши специалисты оптимизируют и настроят качественную и как можно больше продуктивную работу системы. На весь сервис компании CompHelp распространяются гарантийные обязательства.
CC-BY-CA Анатольев А. Г., 19.09.2012
Как создать и настроить локальную сеть LAN
Компьютерные локальные сети, в отличие от глобальной, обеспечивают связь между компьютерами в пределах одного помещения, причем независимо от его размеров. Это может быть одна квартира или большой торговый центр. Существуют также гетерогенные (смешанные) сети, когда между собой связаны компьютеры или другие устройства с различными операционными системами или с разными протоколами передачи данных. В пределах одной локальной сети можно подключать не только компьютеры и ноутбуки, но и другие мультимедийные устройства (телевизоры, игровые приставки, музыкальные центры и т.д.) Грамотно создав такую систему, вы сможете просматривать фильмы или слушать музыку, которая находится на компьютерных носителях, на экране телевизора или с помощью аудиосистемы, быстро обмениваться файлами и т.д.
В данной статье мы рассмотрим пример настройки локальной сети для домашнего пользования. Справиться с этим делом сможет даже обычный пользователь. Рассматриваем вариант, когда на всех компьютерах установлена привычная для российских пользователей система Windows 7 (процедура почти ничем не отличается для настройки домашней сети под Windows 8 или Vista).
Второй этап — настройка локальной сети (через свитч)
В случае выбора вами простого свитча и подключения к нему компьютеров с помощью кабеля, мы сразу переходим к этапу настройки параметров для каждого компьютера или устройства.
В системе Windows 7 нам необходимо зайти в меню Пуск, выбрать Панель управления и открыть вкладку Центр управления сетями.
Теперь настраиваем сетевые карты. В Центре управления сетями нажимаем пункт Подключение по локальной сети.
Количество компьютеров обычно обуславливается числом выходов на хабе, которое варьируется от 8-16 или ещё больше. Такой способ подключения при определённых настройках о которой мы поговорим немного позже, позволяет объединить все компьютеры единой локальной сетью. Помимо этого такое подключение позволяет компьютерам находиться в сети независимо друг от друга. Даже если один из компьютеров отключится от сети, остальные буду продолжать работу. Для того чтобы реализовать сеть посредством хаба нам понадобится специальный сетевой кабель который будет связывать каждый компьютер с сетью. Этот кабель так же известен под названием «витая пара».
Шаг третий — проверка сетевых настроек
Теперь можно проверить корректность создания локальной сети. Для этого в меню Пуск в поиске набираем cmd и жмем Enter, в появившемся окне набираем слово ping и через пробел адрес требуемого компьютера, например, ping 192.168.0.3. если все было сделано верно, то появится сообщение об успешном обмене пакетами и время отклика. Если же настройки не были сделаны корректно, то вы увидите сообщения о превышении интервала ожидания для запроса.
Второй этап — настройка локальной сетки (для роутера)
Если у вас возникли сложности, то мастера компании «Админ Сервис» всегда готовы помочь вам с проектированием, прокладкой и настройкой локальной компьютерной сети.
