Поиск неисправностей в сетях на оборудовании Juniper

Аннотация:

В статье представлены основы реализации модели поиска и устранения неисправностей, применительно к оборудованию Juniper.

Abstract:

The article presents the basics of the troubleshooting model, as applied to equipment Juniper.

Ключевые слова:

сети; поиск неисправностей; устранение неисправностей; Juniper

Keywords:

network; troubleshooting; Juniper

УДК 004.722

За последние десять лет потребность в сетевых ресурсах возросла во много раз и продолжает увеличиваться. На сегодняшний день от бесперебойной и корректной работы сетевых служб зависят как крупные компании, так и обычные пользователи, поэтому нарушения в работе сети зачастую непростительны. Поэтому задача поиска и устранения неисправностей в настоящий момент занимает целые направления на больших предприятиях.

Но увеличилась не только зависимость от успешного функционирования сетевых ресурсов, усложняется сама инфраструктура сети. В особенности, учитывая развитие современных сетевых и телекоммуникационных технологий, когда сложность и объем сетевого оборудования увеличивается с каждым годом, мониторинг таких сетей становится все более трудоемкой задачей. В особенности, когда в процессе функционирования сетевой инфраструктуры используются различные типы протоколов, передающих сред, а также неизвестные транзитные подсети ISP (Internet Service Provider).

В соответствии с приведенными аргументами, целесообразно сделать вывод: в разрастающихся сетевых структурах все сложнее и сложнее найти первопричину неисправности, поэтому встает вопрос об автоматизации алгоритма траблшутинга (troubleshooting – поиск и устранение неисправностей). Общая модель поиска неисправностей [1] представлена на рисунке 1. 

Рисунок 1. Модель поиска неисправностей

Задача стоит в конкретной реализации алгоритма на практике. Натурные испытания предлагается проводить на упрощенной модели сети, построенной на оборудовании Juniper (Рисунок 2)

Рисунок 2. Топология сети

Данная модель в упрощенном виде представляет типовую сеть ISP. На ней запущены протоколы: MPLS, LLDP, OSPF и BGP, осуществляющие корректную маршрутизацию и связность узлов сети. Все устройства активны и корректно осуществляют возложенные на них задачи.

Далее осуществляется имитация поломки, а именно физическое выключение одного из узловых устройств, например роутера R2. (рисунок 3) Пользователи подсети А окажутся отрезанными от связи с другими подсетями и доступа к сети Internet. 

Рисунок 3. Имитация неисправности

Получив жалобы пользователей на недоступность сервисов, доступа к Internet, ставится задача: выяснить причину неисправности. Следуя первому шагу заявленного алгоритма, необходимо проанализировать проблему. А именно, прежде всего узнать, коснулась возникшая проблема только подсеть А или же произошло глобальное нарушение функционирования сети. Следовательно, переходя к шагу 2 , осуществляется сбор статистики: проверка доступности сети Internet и соседних подсетей с ключевых роутеров, которыми являются в данном случае R1,R6 и R3. Удаленно заходим на каждый из них, осуществляя, прежде всего, тестирование их функционирования. Если они активны и есть возможность удаленно зайти на них, следовательно, проверяем доступность от них до маршрутизатора R4 командой  “ping 192.168.1.4 ” из операционного режима роутера(рисунок 4)

Рисунок 4. Пример выполнения команды “ping”

По итогам первичной проверки на шаге 2 выяснено: доступность сервисов от всех роутеров, кроме R1,  присутствует, следовательно, проблема заключена в ветке R1-R2-R4. Это означает переход к шагу 3 – локализации причины. Необходимо выяснить, какой именно роутер препятствует проходимости указанной ветки. 

Доступность роутера R1 уже проверена, значит, проверяем поочередно доступность каждого устройства в ветке от R1 до R4. В нашем случае присутствует всего один маршрутизатор R2, доступность которого можно проверить непосредственно. Но, учитывая, что модель сильно упрощена, в реальной ситуации ветка может быть сложена из целой серии узлов. Значит, команда “ping” непригодна. Вместо нее рекомендуется использовать команду “traceroute 192.168.1.4”, которая аналогично “ping” покажет доступность конечного устройства, при этом, отобразив дополнительно, точки прохождения пакетов на пути. (Рисунок 5) 

Рисунок 5. Результат выполнения команды “traceroute”

Полученные данные показывают, что передача пакетов прекращается сразу на интерфейсе em2 маршрутизатора R2. Это может означать либо недоступность интерфейса, либо недоступность самого роутера. Первоочередной проверкой считается тестирование доступности конкретно маршрутизатора. Осуществить это можно, проверив доступность сначала непосредственно loopback роутера, а затем его интерфейсов. (Рисунок 6)

Рисунок 6. Проверка доступности роутера R2

В результате становится ясно, что по всем пунктам причина неполадки заключается в роутере R2. Это означает, что проблема локализована и необходим переход к шагу 4 – устранению проблемы. В данном случае это физически отключенный узел сети. Причиной тому могли стать как простое отсутствие питания на нем, так и полный выход оборудования из строя.

Предположим, что роутер R2 все же доступен удаленно, но маршрутизация через него все же не осуществляется. В таком случае возможны несколько вариантов предполагаемых действий.

1. Неверные адреса интерфейсов
2. Нарушения в работе маршрутизации

 Остановимся на каждом пункте более подробно.

- Проблема с адресацией интерфейсов решается путем проверки конфигурации заданного маршрутизатора и сопоставления существующей адресации и логической. Применительно к оборудованию Juniper проверка осуществляется командой “show interfaces” из конфигурационного режима (приглашение “>” сменяется на “#”) (Рисунок 7)

Рисунок 7. Проверка адресации интерфейсов

- Нарушения в работе маршрутизации более тонкая проблема, решением которой является проверка, в первую очередь, таблицы маршрутизации командой “ show route”. (Рисунок 8)

Рисунок 8. Проверка таблицы маршрутизации.

Здесь первичной проверкой является присутствие в таблице маршрутизации конечных адресов роутера R4, а также проверка работы составных протоколов маршрутизации. [2]

В приведенных скриншотах функционирование не нарушено, поскольку маршрутизация была заведомо в норме.

Таким образом, процесс траблшутинга весьма трудоемок и велик даже для столь маленькой сети, рассмотренной в примере. При том, что далеко не все моменты были задеты в анализе, а также приведен не полный список запущенных сервисов. В итоге, нетрудно сделать вывод: с ростом объема и функционала сети процесс траблшутинга просто необходимо автоматизировать. Иначе, на процедуру поиска причины неисправности (которая будет далеко не столь банальной, как отключенный узел сети), будет уходить огромные трудозатраты и объемы времени, непозволительные для простоя компаний, всецело зависимых от сетевых ресурсов.

Решить эту проблему предлагается именно созданием автоматизированного алгоритма траблшутинга в виде модулей построения графа сети и автоматического поиска неисправностей, объединенных общим интерфейсом, которые бы в совокупности производили тщательный анализ размещенной сети путем подобных приведенным процедурам и запросам. Реализовано это может быть на любом языке программирования высокого уровня ( предполагается использовать Java) с дополнительным функционалом терминальных программ на подобие Secure CRT