ѕодпишитесь на наш Telegram-канал Ѕудьте в курсе последних новостей 👇 😉 ѕодписатьс€
ѕоддержим в трудное врем€ —пециальное предложение на техническую поддержку вашей »“ - инфраструктуры силами наших экспертов ѕодобрать тариф
ѕоставка оборудовани€ √аранти€ и помощь с настройкой. —кидка дл€ наших читателей по промокоду WIKIMERIONET  упить
»нтерфейс статистики Merion Mertics показывает ключевые диаграммы и графики по звонкам, а также историю звонков в формате, который легко поймет менеджер ѕопробовать бесплатно
¬недрение
офисной телефонии
Ўаг на пути к созданию доступных унифицированных коммуникаций в вашей компании ¬недрить
»нтеграци€ с CRM ѕомогаем навести пор€док с данными
и хранить их в единой экосистеме
ѕодключить
»“ Ѕезопасность ”мна€ информационна€ безопасность дл€ вашего бизнеса «аказать
ћерион Ќетворкс

10 минут чтени€

¬ этой первой части статьи мы сначала рассмотрим некоторые методы обслуживани€ сетей. —уществуют различные модели, которые помогут вам поддерживать ваши сети и сделать вашу жизнь проще. ¬о второй части статьи мы рассмотрим некоторые теоретические модели, которые помогут вам в устранении неполадок.

ќбслуживание и траблшутинг сетей

Ќу что давайте начнем рассматривать техническое обслуживании сети! ќбслуживание сети в основном означает, что вы должны делать все необходимое дл€ поддержани€ сети в рабочем состо€нии, и это включает в себ€ р€д задач:

  • ”странение неполадок в сети;
  • ”становка и настройка аппаратного и программного обеспечени€;
  • ћониторинг и повышение производительности сети;
  • ѕланирование будущего расширени€ сети;
  • —оздание сетевой документации и поддержание ее в актуальном состо€нии;
  • ќбеспечение соблюдени€ политики компании;
  • ќбеспечение соблюдени€ правовых норм;
  • ќбеспечение безопасности сети от всех видов угроз.

 онечно, этот список может отличатьс€ дл€ каждой сети, в которой вы работаете. ¬се эти задачи можно выполнить следующим образом:

  • —труктурированные задачи;
  • Interrupt-driven задачи.

—труктурированный означает, что у вас есть заранее определенный план обслуживани€ сети, который гарантирует, что проблемы будут решены до того, как они возникнут.  ак системному администратору, это сделает жизнь намного проще. ”правл€емый прерыванием означает, что вы просто ждете возникновени€ проблемы, а затем исправл€ете ее так быстро, как только можете. ”правл€емый прерыванием подход больше похож на подход "пожарного" ...вы ждете, когда случитс€ беда, а затем пытаетесь решить проблему так быстро, как только можете. —труктурированный подход, при котором у вас есть стратеги€ и план обслуживани€ сети, сокращает врем€ просто€ и €вл€етс€ более экономичным.

 онечно, вы никогда не сможете полностью избавитьс€ от Interrupt-driven, потому что иногда все "просто идет не так", но с хорошим планом мы можем точно сократить количество задач, управл€емых прерывани€ми.

¬ам не нужно думать о модели обслуживани€ сети самосто€тельно. ≈сть р€д хорошо известных моделей обслуживани€ сети, которые используютс€ сетевыми администраторами. Ћучше всего использовать одну из моделей, котора€ лучше всего подходит дл€ вашей организации и подкорректировать, если это необходимо.

¬от некоторые из известных моделей обслуживани€ сети:

  • FCAPS:
  • ”правление неисправност€ми.
  • ”правление конфигурацией.
  • ”правление аккаунтингом.
  • ”правление производительностью.
  • ”правление безопасностью.

ћодель обслуживани€ сети FCAPS была создана ISO (ћеждународной организацией стандартизации).

  • ITIL: библиотека »“-инфраструктуры - это набор практик дл€ управлени€ »“-услугами, который фокусируетс€ на приведении »“-услуг в соответствие с потребност€ми бизнеса.
  • TMN: сеть управлени€ телекоммуникаци€ми - это еще одна модель технического обслуживани€, созданна€ ITU-T (сектор стандартизации телекоммуникаций) и €вл€юща€с€ вариацией модели FCAPS. TMN нацелена на управление телекоммуникационными сет€ми.
  • Cisco Lifecycle Services: конечно, Cisco имеет свою собственную модель обслуживани€ сети, котора€ определ€ет различные фазы в жизни сети Cisco:
    • ѕодготовка
    • ѕланирование
    • ѕроектирование
    • ¬недрение
    • «апуск
    • ќптимизаци€

¬ыбор модели обслуживани€ сети, которую вы будете использовать, зависит от вашей сети и бизнеса. ¬ы также можете использовать их в качестве шаблона дл€ создани€ собственной модели обслуживани€ сети.

„тобы дать вам представление о том, что такое модель обслуживани€ сети и как она выгл€дит, ниже приведен пример дл€ FCAPS:

  • ”правление неисправност€ми: мы будем настраивать наши сетевые устройства (маршрутизаторы, коммутаторы, брандмауэры, серверы и т. д.) дл€ захвата сообщений журнала и отправки их на внешний сервер. ¬с€кий раз, когда интерфейс выходит из стро€ или нагрузка процессора превышает 80%, мы хотим получить сообщение о том, чтобы узнать, что происходит.
  • ”правление конфигурацией: любые изменени€, внесенные в сеть, должны регистрироватьс€ в журнале. „аще всего используют управление изменени€ми, чтобы соответствующий персонал был уведомлен о планируемых изменени€х в сети. »зменени€ в сетевых устройствах должны быть зарегистрированы и утверждены до того, как они будут реализованы.
  • ”правление аккаунтингом: ћы будем взимать плату с (гостевых) пользователей за использование беспроводной сети, чтобы они платили за каждые 100 ћЅ данных или что-то в этом роде. ќн также обычно используетс€ дл€ взимани€ платы с людей за междугородние VoIP-звонки.
  • ”правление производительностью: производительность сети будет контролироватьс€ на всех каналах LAN и WAN, чтобы мы знали, когда что-то пойдет не так. QoS (качество обслуживани€) будет настроено на соответствующих интерфейсах.
  • ”правление безопасностью: мы создадим политику безопасности и реализуем ее с помощью брандмауэров, VPN, систем предотвращени€ вторжений и используем AAA (Authorization, Authentication and Accounting) дл€ проверки учетных данных пользователей. —етевые нарушени€ должны регистрироватьс€, и должны быть прин€ты соответствующие меропри€ти€.

 ак вы видите, что FCAPS - это не просто "теоретический" метод, но он действительно описывает "что", "как" и "когда" мы будем делать.

 акую бы модель обслуживани€ сети вы ни решили использовать, всегда есть р€д рутинных задач обслуживани€, которые должны иметь перечисленные процедуры, вот несколько примеров:

  • »зменени€ конфигурации: бизнес никогда не стоит на месте, он посто€нно мен€етс€. »ногда вам нужно внести изменени€ в сеть, чтобы разрешить доступ дл€ гостевых пользователей, обычные пользователи могут перемещатьс€ из одного офиса в другой, и дл€ облегчени€ этой процедуры вам придетс€ вносить изменени€ в сеть.
  • «амена оборудовани€: старое оборудование должно быть заменено более современным оборудованием, и также возможна ситуаци€, когда производственное оборудование выйдет из стро€, и нам придетс€ немедленно заменить его.
  • –езервные копии: если мы хотим восстановитьс€ после сетевых проблем, таких как отказавшие коммутаторы или маршрутизаторы, то нам нужно убедитьс€, что у нас есть последние резервные копии конфигураций. ќбычно вы используете запланированные резервные копии, поэтому вы будете сохран€ть текущую конфигурацию каждый день, неделю, мес€ц или в другое удобное дл€ вас врем€.
  • ќбновлени€ программного обеспечени€: мы должны поддерживать ваши сетевые устройства и операционные системы в актуальном состо€нии. ќбновлени€ позвол€ют исправл€ть ошибки ѕќ. “акже обновление проводитс€ дл€ того, чтобы убедитьс€, что у нас нет устройств, на которых работает старое программное обеспечение, имеющее у€звимости в системе безопасности.
  • ћониторинг: нам необходимо собирать и понимать статистику трафика и использовани€ полосы пропускани€, чтобы мы могли определить (будущие) проблемы сети, но также и планировать будущее расширение сети.

ќбычно вы создаете список задач, которые должны быть выполнены дл€ вашей сети. Ётим задачам можно присвоить определенный приоритет. ≈сли определенный коммутатор уровн€ доступа выходит из стро€, то вы, веро€тно, захотите заменить его так быстро, как только сможете, но нерабочее устройство распределени€ или основного уровн€ будет иметь гораздо более высокий приоритет, поскольку оно вли€ет на большее число пользователей —ети.

ƒругие задачи, такие как резервное копирование и обновление программного обеспечени€, могут быть запланированы. ¬ы, веро€тно, захотите установить обновлени€ программного обеспечени€ вне рабочего времени, а резервное копирование можно запланировать на каждый день после полуночи. ѕреимущество планировани€ определенных задач заключаетс€ в том, что сетевые инженеры с меньше всего забудут их выполнить.

¬несение изменений в вашу сеть иногда вли€ет на производительность пользователей, которые полагаютс€ на доступность сети. Ќекоторые изменени€ будут очень важны, изменени€ в брандмауэрах или правилах списка доступа могут повли€ть на большее количество пользователей, чем вы бы хотели. Ќапример, вы можете установить новый брандмауэр и запланировать определенный результат защиты сети. —лучайно вы забыли об определенном приложении, использующем случайные номера портов, и в конечном итоге устран€ете эту проблему. ћежду тем некоторые пользователи не получат доступ к этому приложению (и возмущаютс€, пока вы пытаетесь его исправить...).

Ѕолее крупные компании могут иметь более одного »“-отдела, и каждый отдел отвечает за различные сетевые услуги. ≈сли вы планируете заменить определенный маршрутизатор завтра в 2 часа ночи, то вы можете предупредить парней из отдела "»“-отдел-2", о том, что их серверы будут недоступны. ƒл€ этого можно использовать управление изменени€ми.  огда вы планируете внести определенные изменени€ в сеть, то другие отделы будут проинформированы, и они могут возразить, если возникнет конфликт с их планированием.

ѕеред внедрением управлени€ изменени€ми необходимо подумать о следующем:

  •  то будет отвечать за авторизацию изменений в сети?
  •  акие задачи будут выполн€тьс€ во врем€ планового технического обслуживани€ windows, linux, unix?
  •  акие процедуры необходимо соблюдать, прежде чем вносить изменени€? (например: выполнение "copy run start" перед внесением изменений в коммутатор).
  •  ак вы будете измер€ть успех или неудачу сетевых изменений? (например: если вы планируете изменить несколько IP-адресов, вы запланируете врем€, необходимое дл€ этого изменени€. ≈сли дл€ перенастройки IP-адресов требуетс€ 5 минут, а вы в конечном итоге устран€ете неполадки за 2 часа, так как еще не настроили. »з-за этого вы можете "откатитьс€" к предыдущей конфигурации. —колько времени вы отводите на устранение неполадок? 5 минут? 10 минут? 1 час?
  •  ак, когда и кто добавит сетевое изменение в сетевую документацию?
  •  аким образом вы создадите план отката, чтобы в случае непредвиденных проблем восстановить конфигурацию к предыдущей конфигурации?
  •  акие обсто€тельства позвол€т отменить политику управлени€ изменени€ми?

≈ще одна задача, которую мы должны сделать - это создать и обновить вашу сетевую документацию. ¬с€кий раз, когда разрабатываетс€ и создаетс€ нова€ сеть, она должна быть задокументирована. Ѕолее сложна€ часть состоит в том, чтобы поддерживать ее в актуальном состо€нии. —уществует р€д элементов, которые вы должны найти в любой сетевой документации:

  • ‘изическа€ топологическа€ схема (физическа€ карта сети): здесь должны быть показаны все сетевые устройства и то, как они физически св€заны друг с другом.
  • Ћогическа€ топологическа€ схема (логическа€ карта сети): здесь необходимо отобразить логические св€зи между устройствами, то есть как все св€зано друг с другом. ѕоказать используемые протоколы, информаци€ о VLAN и т. д.
  • ѕодключени€: полезно иметь диаграмму, котора€ показывает, какие интерфейсы одного сетевого устройства подключены к интерфейсу другого сетевого устройства.
  • »нвентаризаци€: вы должны провести инвентаризацию всего сетевого оборудовани€, списков поставщиков, номера продуктов, версии программного обеспечени€, информацию о лицензии на программное обеспечение, а также каждое сетевое устройство должно иметь инвентарный номер.
  • IP-адреса: у вас должна быть схема, котора€ охватывает все IP-адреса, используемые в сети, и на каких интерфейсах они настроены.
  • ”правление конфигурацией: перед изменением конфигурации мы должны сохранить текущую запущенную конфигурацию, чтобы ее можно было легко восстановить в предыдущую (рабочую) версию. ≈ще лучше хранить архив старых конфигураций дл€ дальнейшего использовани€.
  • ѕроектна€ документаци€: документы, которые были созданы во врем€ первоначального проектировани€ сети, должны хранитьс€, чтобы вы всегда могли проверить, почему были прин€ты те или иные проектные решени€.

Ёто хороша€ иде€, чтобы работать с пошаговыми рекомендаци€ми по устранению неполадок или использовать шаблоны дл€ определенных конфигураций, которые все сетевые администраторы согласны использовать.

Ќиже показаны примеры, чтобы вы понимали, о чем идет речь:

interface FastEthernet0/1
description AccessPoint
switchport access vlan 2
switchport mode access
spanning-tree portfast

¬от пример интерфейсов доступа, подключенных к беспроводным точкам доступа. Portfast должен быть включен дл€ св€зующего дерева, точки доступа должны быть в VLAN 2, а порт коммутатора должен быть изменен на "доступ" вручную.

interface FastEthernet0/2
description VOIP
interface FastEthernet0/2
description ClientComputer
switchport access vlan 6
switchport mode access
switchport port-security
switchport port-security violation shutdown
switchport port-security maximum 1
spanning-tree portfast
spanning-tree bpduguard enable

¬от шаблон дл€ интерфейсов, которые подключаютс€ к клиентским компьютерам. »нтерфейс должен быть настроен на режиме "доступа" вручную. Ѕезопасность портов должна быть включена, поэтому допускаетс€ только 1 MAC-адрес (компьютер). »нтерфейс должен немедленно перейти в режим переадресации, поэтому мы настраиваем spanning-tree portfast, и, если мы получаем BPDU, интерфейс должен перейти в err-disabled. –абота с предопределенными шаблонами, подобными этим, уменьшит количество ошибок, потому что все согласны с одной и той же конфигурацией. ≈сли вы дадите каждому сетевому администратору инструкции по ""защите интерфейса", вы, веро€тно, получите 10 различных конфигураций

interface GigabitEthernet0/1
description TRUNK
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk nonegotiate

¬от еще один пример дл€ магистральных соединений. ≈сли вы скажете 2 сетевым администраторам "настроить магистраль", вы можете в конечном итоге получить один интерфейс, настроенный дл€ инкапсул€ции 802.1Q, а другой-дл€ инкапсул€ции ISL. ≈сли один сетевой администратор отключил DTP, а другой настроил интерфейс как "dynamic desirable", то он также не будет работать. ≈сли вы дадите задание им настроить магистраль в соответствии с шаблоном, то у нас будет одинакова€ конфигураци€ с обеих сторон.