Для многих наших клиентов критерием выбора серверных услуг является сетевая связность. Под сетевой связностью понимается степень взаимодействия сети одного оператора с сетями других операторов и, как следствие, количество маршрутов и количество промежуточных узлов для интернет-трафика.
Проверку сетевой связности удобно осуществлять с помощью сервисов, называемых «Looking Glass» (в переводе с английского — зеркало). Они позволяют проверять маршрутизацию из удаленной сети. Такие сервисы есть у многих организаций (с информацией обо всех Looking Glass мира можно ознакомиться, например, здесь).
Свой сервис «Looking Glass» есть и у нашей компании. Он расположен по адресу: http://lg.selectel.ru. Диагностика с помощью «Looking Glass» позволяет конкретизировать возникшую неисправность и выдвинуть обоснованное предположение о ее причине. О диагностических процедурах, которые можно осуществить с помощью этого сервиса, пойдет речь ниже.
Интерфейс нашего «Looking Glass» предельно прост:
Все команды выполняются с двух маршрутизаторов, расположенных в Санкт-Петербурге и в Москве (выбрать маршрутизатор можно, установив флажок в поле Router; можно осуществлять проверку с двух маршрутизаторов одновременно).
Наш сервис «Looking Glass» выполняет следующие команды (выбор команды осуществляется в выпадающем меню «Operation»):
- ping — позволяет определить наличие связи с заданным узлом, а также проверить время отклика;
- traceroute — позволяет отследить путь прохождения пакетов по IP-сети от маршрутизатора до заданного ресурса;
- bgp route detail — позволяет получить подробную информацию о BGP-маршрутах до указанного узла. Результатом запроса будет таблица маршрутизации;
- bgp route terse — позволяет получить краткую информацию о BGP-маршрутах до указанного узла, а также о маршруте, активном на данный момент;
- bgp summary — позволяет просмотреть информацию обо всех BGP-сессиях на выбранном маршрутизаторе.
Выбрав команду, нужно указать в поле «Host» адрес хоста назначения (можно ввести как IP-адрес, так и DNS-имя) и нажать на кнопку «Do it». Рассмотрим более подробно, как работает каждая из этих команд и как следует интерпретировать их результаты.
Команда ping
С помощью этой команды можно проверить доступность указанного узла используя специальный протокол ICMP. Принцип ее работы заключается в следующем: получив команду ping, маршрутизатор отправляет запросы к указанному узлу, который, в свою очередь, отправляет его обратно (по тому адресу, откуда он пришел). Из результатов запроса ping можно узнать, (1) вернулись ли отправленные пакеты обратно и (2) сколько времени (в миллисекундах) потребовалось для движения пакетов туда и обратно.
Результаты команды ping могут выглядеть, например, так:
PING 217.69.139.201 (217.69.139.201): 56 data bytes 64 bytes from 217.69.139.201: icmp_seq=0 ttl=62 time=8.776 ms 64 bytes from 217.69.139.201: icmp_seq=1 ttl=62 time=8.676 ms 64 bytes from 217.69.139.201: icmp_seq=2 ttl=62 time=10.024 ms --- 217.69.139.201 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 8.676/9.159/10.024/0.613 ms
Из этого примера видно, что узел назначения исправно отвечает на запросы, потерь пакетов нет. Рассмотрим еще один пример:
PING www.jnto.go.jp (210.165.34.236): 56 data bytes 64 bytes from 210.165.34.236: icmp_seq=0 ttl=241 time=325.734 ms 64 bytes from 210.165.34.236: icmp_seq=1 ttl=241 time=325.894 ms 64 bytes from 210.165.34.236: icmp_seq=2 ttl=241 time=334.896 ms --- www.jnto.go.jp ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 325.734/328.841/334.896/4.282 ms
В данном случае из результатов видно, что узел назначения доступен, потери пакетов нет, но время ответа несколько увеличено по причине географической удаленности: узел назначения находится в Японии, а запросы отправлялись из Санкт-Петербурга.
Иногда может иметь место и такая ситуация:
PING 89.108.112.69 (89.108.112.69): 56 data bytes --- 89.108.112.69 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss
Результаты работы команды в данном случае показывают, что ни один из пакетов не дошел до цели и что узел, скорее всего, недоступен, или не отвечает на ICMP-запросы.
Таким образом, с помощью запроса ping можно проверить соединение с удаленным узлом. Сам факт успешного возвращения запросов дает основания предполагать, что все устройства на пути от маршрутизатора к указанному узлу работают нормально. Следует отметить, что потеря пакетов может иметь место даже при отсутствии неисправностей: она может быть обусловлена, например, перегруженностью сети. Часто бывает и так, что маршрутизаторы дают диагностирующим пакетам низкий приоритет. Но если хотя бы один из отправленных пакетов возвращается, то это уже свидетельствует о наличии соединения и доступности узла.
На основании результатов запроса ping однозначного вывода о наличии неисправности сделать невозможно. Можно лишь выдвинуть предположение, которое нуждается в дополнительной проверке с помощью других инструментов.
Команда traceroute
Проблемы с доступностью веб-сервисов могут также быть обусловлены техническими проблемами на промежуточных узлах, через которые проходят пакеты на пути к хосту назначения. Выявить эти проблемы можно с помощью команды traceroute.
Как работает эта команда? Одной из характеристик пересылаемых по сети пакетов является время жизни (англ. time to live, сокращенно TTL) — число хопов (англ. hop — прыжок, т.е. переход пакета от одного маршрутизатора — к другому) или время в миллисекундах, в течение которого пакет может находиться в сети. Каждый маршрутизатор, обрабатывающий пакет, уменьшает значение TTL на единицу. Когда TTL становится равным нулю, пакет уничтожается, а отправителю высылается IMCP-сообщение time exceeded (время истекло). Изначально этот механизм использовался для предотвращения бесконечного копирования сетевых пакетов при ошибочном закольцевании сети.
Получив команду traceroute, маршрутизатор отправляет в направлении хоста назначения пакет с TTL=1. Узел, с которого приходит ответ time exceeded, определяется как первый хоп (т.е. первый шаг на пути к цели). Затем поочередно отправляются пакеты с TTL=2,3,4,5 и так далее — до тех пор, пока один из пакетов не достигнет узла назначения и не получит от него ответ.
В результате на экран выводится список всех промежуточных узлов на пути пакета от маршрутизатора к узлу назначения. Он может, выглядеть, например, так:
traceroute to 89.108.112.69 (89.108.112.69), 30 hops max, 40 byte packets 1 sap-b2-link.telia.net (213.248.86.117) 6.278 ms 62.572 ms 9.668 ms 2 hls-b2-link.telia.net (213.155.131.128) 9.812 ms hls-b2-link.telia.net (80.91.245.172) 12.487 ms hls-b2-link.telia.net (80.91.245.170) 12.088 ms 3 hls-b1-link.telia.net (213.155.133.132) 15.486 ms 12.360 ms s-bb2-link.telia.net (213.155.133.74) 90.086 ms 4 s-b2-link.telia.net (213.155.131.33) 22.196 ms s-b2-link.telia.net (213.155.133.143) 22.272 ms s-b2-link.telia.net (80.91.246.235) 21.197 ms 5 s-b2-link.telia.net (213.155.133.137) 21.807 ms s-b2-link.telia.net (80.91.247.217) 22.231 ms vimpelcom-ic-152423-s-b2.c.telia.net (213.155.129.118) 21.936 ms 6 * * * 7 * 81.211.13.162 (81.211.13.162) 58.058 ms 152.715 ms 8 te6-1.rt1.dc5.agava.net (89.108.112.242) 40.044 ms 32.834 ms 39.235 ms 9 te6-1.rt1.dc5.agava.net (89.108.112.242) 40.780 ms 43.640 ms * 10 * * * 11 * * *
Что видно из представленного результата?
В девятом переходе вместо одного из значений времени ответа отображается звездочка. Это означает, что на какой-то из отправленных пакетов не было получено ответа. Это может быть вызвано, например, перегрузкой сети. Или тем, что многие маршрутизаторы отбрасывают низкоприоритетные ICMP-пакеты. Появление таких звездочек в выводе traceroute — вполне типичная ситуация, которая не является причиной для беспокойства.
Если для одного из промежуточных маршрутизаторов отображается три звездочки, то это значит, что от него не было получено ни одного ответа. Но не следует делать вывода о наличии неисправности на основании одних лишь этих звездочек. Их появление может быть обусловлено самыми разными причинами. Например, маршрутизаторы нередко конфигурируют таким образом, чтобы они “молча” отбрасывали устаревшие пакеты. В этом случае пакеты благополучно переходят на следующий маршрутизатор.
Причина может заключаться и в том, что ответные пакеты от этого маршрутизатора идут слишком долго, и Looking Glass перестает ждать их прибытия. Если же три звездочки отображаются для узлов в конце маршрута (как в приведенном примере), то это, скорее всего, свидетельствует о том, что пакеты до узла назначения не дошли.
Интерпретация выводов traceroute представляет собой более сложную и тонкую задачу, чем это может показаться на первый взгляд; более подробно об этом можно прочитать здесь и здесь (на английском языке).
Команды для диагностики BGP
BGP (англ. Board Gateway Protocol, протокол граничного шлюза) — это основной протокол динамической маршрутизации в Интернете. Он предназначен для обмена информацией не между отдельными маршрутизаторами, а между автономными системами. Автономной системой, согласно определению, данному в RFC1930, называется система IP-сетей и маршрутизаторов, управляемых одним или несколькими операторами и имеющими отдельную политику маршрутизации с Интернетом. Собственно, Интернет можно рассматривать как набор связанных друг с другом автономных систем.
С помощью BGP-протокола автономные системы сообщают друг другу: (1) о факте своего существования и (2) о том, какие сети могут быть получены через них. Они также собирают информацию о том, как добраться до других сетей в Интернете. Получая информацию о маршрутах до цели назначения, они определяют из них наилучший (на основе правил сети, а не технических метрик) и добавляют в свои таблицы маршрутизации. Именно поэтому BGP-протокол иногда называют клеем, связующим весь Интернет.
Протокол BGP был создан во времена, когда в Интернете не существовало многих проблем и опасностей, которые существуют сегодня, и он характеризуется повышенной уязвимостью. Ошибки в работе протокола, которые могут быть вызваны как техническими проблемами конкретной автономной системы, так и намеренными действиями злоумышленников, могут приводить к очень серьезным последствиям (более подробно об этом можно прочитать, например, здесь). В результате этих ошибок трафик перенаправляется и/или отбрасывается, не доходя до сети назначения — из-за этого возникают проблемы с сетевой доступностью.
Проверить работу BGP-протокола можно при помощи команд bgp route detail, bgp route terse и bgp summary. Результатом работы команды bgp route detail является таблица маршрутизации c перечнем всех автономных станций на пути движения пакетов. Команда bgp terse выводит на экран сокращенный вариант таблицы маршрутизации. Команда bgp summary выводит список всех автономных систем, с которыми есть связность у наших маршрутизаторов.
Заключение
В этой статье мы привели лишь краткое описание возможностей нашего сервиса «Looking Glass». Диагностика сетевых проблем представляет собой тему, которую невозможно охватить в рамках одной публикации. Если у вас возникли вопросы по работе нашего «Looking Glass» — добро пожаловать в комментарии. Будем также рады конструктивным замечаниям и предложениям по работе сервиса.
Для тех кто не может комментировать посты на Хабре, приглашаем к нам в блог.
Автор: AndreiYemelianov
