Не смотря на то, что в курсе CCNA по большей части рассматривается процесс настройки сети, внедрения каких-либо технологий, в реальной повседневной жизни администратора, большую часть времени занимает процесс поиска неисправностей. Для того чтобы этот процесс проходил максимально гладко, необходимо иметь под рукой документацию на сеть и руководствоваться определённой схемой поиска неисправности.
Общая схема поиска неисправностей состоит из трёх частей:
- Собрать симптомы проблемы. Это первая составляющая процесса. Часто поиск неисправности начинается со звонка от пользователя, в котором он сообщает: «У меня ничего не работает!». Этой информации недостаточно чтобы провести полноценный поиск. Необходимо уточнить, что конкретно не работает, когда работало в последний раз, может ли он повторить ошибку и задать другие наводящие вопросы. Затем начинается сборка симптомов на сетевом оборудовании. Например, если пользователь сообщил, что не открываются ресурсы из какой-то конкретной сети, то возможно, потребуется собрать какую-то дополнительную информацию на маршрутизаторе.
- Изолировать проблему. Необходимо четко определить границы проблемы. Примером такой изоляции может служить, например, проверка, работает ли искомый ресурс на соседнем компьютере. Или, например, подключит вместо компьютера пользователя свой ноутбук с теми же сетевыми настройками и понять, проблема в сети, или в компьютере пользователя.
- Устранить проблему. Это заключительная часть процесса поиска неисправностей. Практика показывает, что лёгкость исполнения третьего пункта напрямую зависит от качества выполнения предыдущих двух. Например, без грамотной сборки симптомов и изоляции неисправности, можно планомерно проверять устройство за устройством в сети в надежде, что проблема именно на нём. Как вы понимаете, это долгий и трудный путь.
После того, как все три пункта выполнены, надо убедиться, что проблема решена, что клиент доволен и если это не так – снова возвращаться к первому пункту.
Для сбора информации на устройстве используются уже известные нам команды: ping, traceroute, telnet, show ip interface brief, show ipv6 interface brief, show ip route, show ipv6 route, show cdp neighbors, show running-config, debug, show protocols и другие.
Рассмотрим подробнее процесс изоляции проблемы и поиска неисправностей. Для того чтобы не тыкаться бессистемно в одно устройство за другим, следует использовать единый подход к поиску неисправностей. Рекомендуется подход, основанный на эталонной модели OSI. Учитывая, что каждое устройство в сети функционирует на каком-то определённом уровне этой модели, можно успешно изолировать проблему от целого класса устройств, которые в принципе не могут её вызвать. Например, если проблема с физическим подключением и компьютер периодически пишет «Сетевой кабель не подключён», то нет смысла искать проблему на пограничном маршрутизаторе. Если проблема с маршрутизацией, то вряд ли её причиной будет хаб или коммутатор второго уровня.
Напомним, какие проблемы могут быть на каком уровне модели OSI:
- Хаб, кабели, провода, электропитание, физика
- Коммутатор второго уровня
- Маршрутизатор, коммутатор третьего уровня, файрвол
- Маршрутизатор, коммутатор третьего уровня и файрвол (при условии, что он занимается не только маршрутизацией, а, например, использует расширенные ACL)
Всё что выше четвёртого уровня – это, как правило, конечные устройства. Хотя из этого правила есть и исключения. Например, файрвол с технологией deep packet inspection (DPI) может фильтровать трафик основываясь на заголовках протокола 7-го уровня.
Учитывая вышесказанное, может существовать три подхода к поиску неисправностей: сверху-вниз по модели OSI, снизу-вверх и начиная с середины, когда мы, например, сначала проверяем проходят ли пинги на сетевом уровне, если да – то ищем проблему выше, если нет – то ниже.
Существует ещё два подхода, которые не такие систематизированные, как приведённые выше: поиск неисправностей исходя из опыта и интуиции – подходит только для опытных администраторов и подход, основанный на сравнении конфигов и версий ПО у работающего и неработающего оборудования. Понятно, что оба эти подхода применимы только в ограниченном ряде случаев.
В повседневной практике системному администратору приходится выбирать подход к решению каждой конкретной проблемы в зависимости от её особенностей и масштабов.
