vk_logo twitter_logo facebook_logo googleplus_logo youtube_logo telegram_logo telegram_logo

О чем расскажет traceroute 45

Дата публикации: 18.02.2011
Количество просмотров: 36055

В инструментарий первичной диагностики неполадок в сетях на базе стека протоколов TCP/IP, утилита traceroute вошла уже давно. Общая идея алгоритма осталась неизменной еще с 1987 года, когда она впервые была реализована программно Van Jacobson, сотрудником группы сетевых исследований (Network Research Group) в Национальной лаборатории Беркли (Lawrence Berkley National Laboratory). За более чем 20-ти летний период времени, этот простой в использовании инструмент стал обыденным и привычным, и мало уже кто задумывается о том, что получаемые результаты «трассировки» хорошо демонстрируют один из краеугольных принципов построения сетей связи. Речь идет об аспекте разграничения зон обслуживания, на котором в том числе тоже держится связь, и о котором сейчас часто забывают.

Он хорошо известен связистам «старой школы», когда требование работоспособности в пять девяток считалось не нонсенсом, как сейчас, а всего лишь заурядным показателем работы систем телефонной связи. Дома могло не быть света, - где-то оборвало электрический кабель, висящий на опорах. Воду могли отключить, - на водонапорной башне отключили электроэнергию, потому что «где-то оборвало кабель, висящий на опорах»… Вот только телефон, правда, у тех у кого он имелся в наличии, должен был работать. И даже сейчас, имея дома уже много лет обыкновенный кнопочный аппарат, я так и не смог вспомнить, когда последний раз обращался к своему оператору телефонной связи с какой-то жалобой на аварию. Понятно, я утрирую. Но все-таки, а Вы вспомните?

Совершенно другая ситуация наблюдается в сетях «нового» мира, мира пакетной передачи, ярким проявлением которого является уже такое обыденное явление как интернет. Ирония в том, что сам интернет, в своей первоначальной ипостаси вышел из проекта ARPANET, - как ответ министерства обороны США для надежной системы передачи информации на случай глобальной ядерной войны и тотальных разрушений. Так почему же сейчас, когда призрак ядерной войны ушел в небытие, а катаклизмы и разрушения в своей массе затрагивают нас очень редко - ситуация кардинально иная? Стоит взглянуть на ветку форума «XYZ упал:(» этого сайта. Топик существует чуть более года, а счетчик сообщений скоро перешагнет полторы тысячи. И это только по магистральным каналам связи, аварии на которых затрагивают значительные группы абонентов. В чем дело?

Прежде чем ответить на вопрос, надо вернуться к теме статьи, вынесенной в ее заголовок, утилите traceroute. Как оказалось, на сайте бывают и обыкновенные пользователи, хоть и продвинутые. Небольшой ликбез не помешает. Суть алгоритма утилиты очень проста: в IP-пакетах поле TTL (Time To Live) задает время жизни отправленной в сеть дейтаграммы. Каждый узел, который обрабатывает пакет и пересылает его дальше, уменьшает значение поля TTL на единицу. Когда TTL становится равным 1 или 0, пакет уничтожается, а отправителю отсылается сообщение ICMP «time exceeded» (время превышено). Нужно это для того, что бы дейтаграмма бесконечно не «гуляла» по сети, если не сможет дойти до адресата. Максимальное значение TTL ограниченно его разрядностью (8 бит) и составляет 255, реальные же значения TTL по умолчанию устанавливаются каждой системой по разному. Стоит отметить, что TTL также уменьшается каждую секунду нахождения его на узле, хотя для современных сетей это часто не принципиально, за исключением, наверное, «шейпера» трафика (bandwidth control, ограничение полосы) с достаточно жесткими параметрами.

Пример реализации traceroute

Именно механизм TTL задействован для определения пути следования пакета. Классическая реализация traceroute посылает серию из трех UDP-пакетов на произвольный порт (по умолчанию 33434) с TTL = 1. По поступлению ответов ICMP «time exceeded» определяется время прохождения и доменное имя узла. Затем процедура повторяется с TTL = TTL + 1 до тех пор, пока пакет не достигнет конечного узла, который ответит «port unreachable» (порт не доступен). В зависимости от реализации, вариации traceroute могут различаться. К примеру, консольная утилита tracert.exe в семействе Windows использует запросы ICMP «echo», которые обычно используются утилитой ping. В любом случае, результат работы утилиты будет включать в себя определенный набор информации: список узлов, через которые проходит пакет от адреса источника до адреса назначения и задержки при передаче пакетов. Последний важный аспект. Нельзя забывать, что пути пакетов в интернет неисповедимы. Уходя одним путем, ответ на запрос может возвращаться другим. Поэтому для анализа полной информации нужны результаты traceroute и с обратной стороны.

Пример результата работы traceroute. http://www.webtrace.info/traceroute/

Так вот, возвращаясь к поставленному ранее вопросу «в чем дело?» теперь можно и ответить. То есть указать всего лишь один из возможных вариантов ответа. Наверное, во всем виноваты программисты. Как говорит известная притча, «если бы они строили цивилизацию, то залетевшая внутрь птица развалила бы ее как карточный домик». Именно программисты внесли в связь, лет пятнадцать с лишком назад еще девственную и непорочную, свою культуру, взятую от утверждения, где «баг и не баг вообще, а просто фича». Да, да, - это шутка! И все-таки доля правды в ней есть. Телеком, стоя на острие инновационного развития, порожденного информационно-компьютерными технологиями, сам же и развивался за счет них. Хотите пример взаимной интеграции? Пожалуйста. Попробуйте навскидку определить, что делает нижеприведенный код:

int f1 (int a, int b) { if (sign(a) != sign(b)) return (a+b)/2; else return a+(b-a)/2; }

Угадали? А ведь все очень просто. Это функция для вычисления среднего значения двух аргументов. А теперь определите по приведенному ниже скану из форума, где находятся зоны ответственности операторов с точки зрения простого пользователя, грешным делом решившего запустить стандартную для Windows (>90% абонентов) версию tracert, чтобы попробовать понять, на чьей стороне проблема. Только, пожалуйста, без всяких там whois сервисов, о которых даже продвинутый пользователь имеет право не знать.

Скан сообщений (от 16.02.2010) из топика «XYZ упал:(» с форума NAG.ru

Не правда ли, очень гармонирует с примером функции вычисления среднего значения? И там и там страдает визуализация. В первом случае визуализация программного кода осложнена записью в одну строку. Во втором случае отсутствие имен узлов мешает пользователю отследить пути следования пакетов. Отметим, что эта беда не только российских компаний. Она международного характера. В приведенном выше примере traceroute через webtrace.info надо смотреть на AS7132 и AS7018. А ведь если проблема действительно находится за пределами сети оператора, здравые имена узлов позволяют снизить поток жалоб от абонентов в адрес оператора. Ведь оперировать к именам, имеющим значение, всегда проще, чем к каким-то там цифрам. Ясно, что таких клиентов, пытливый ум которых будет стремиться узнать, из-за кого провайдера «та сволочь в любимой онлайн - игре отстрелила ему башку», - очень мало. Насколько активны они в форумах, мне судить сложно.

Только есть еще и другая группа потребителей. Я говорю о корпоративных пользователях, тех, у кого есть или системные администраторы, или даже целые отделы ИТ. Корректно ли заставлять их «лезть» в ripe, чтобы определить стыки, а значит и зоны ответственности сетей, когда интернет не работает или «работает, но как-то не так»?! В ответ появляются такие решения, как «Улучшитель кармы трафика». Для тех, кто побогаче - аппаратное решение, а для тех, кто победней скоро планируется выпуск программного продукта. А если серьезно? Может ли видимое пренебрежение оператора к разграничению зон ответственности являться пренебрежением реальным? Вероятно, нет. Зная уровень технических специалистов ЮТК, попавшей в примеры к статье, - НЕТ с уверенностью в 99,999%. Знает ли об этом клиент?! Вероятно, ТОЖЕ нет. Поэтому в случае аварии tracert свою функцию выполнит и расскажет клиентам, и так изнывающим, о том, что якобы их провайдер не может даже имя узлов «сконфигурировать». О каком уж там разделении зон ответственности вести речь? Стоит ли этого мнения призрачная безопасность топологии сети, а может и просто нежелание немного «повозиться»? Пускай каждый провайдер решает для себя сам…

Дополнительные материалы: A Practical Guide to (Correctly) Traceroute with Troubleshooting.

От редакции: если у вас есть чем поделиться с коллегами по отрасли, приглашаем к сотрудничеству
Ссылка на материал, для размещения на сторонних ресурсах
/articles/article/20192/o-chem-rasskajet-traceroute.html

Комментарии:(45) комментировать

18 февраля 2011 - 18:41
Robot_NagNews:
#1

Материал:
В инструментарий первичной диагностики неполадок в сетях на базе стека протоколов TCP/IP, утилита traceroute вошла уже давно. Общая идея алгоритма осталась неизменной еще с 1987 года, когда она впервые была реализована программно Van Jacobson, сотрудником группы сетевых исследований (Network Research Group) в Национальной лаборатории Беркли (Lawrence Berkley National Laboratory). За более чем 20-ти летний период времени, этот простой в использовании инструмент стал обыденным и привычным, и мало уже кто задумывается о том, что получаемые результаты «трассировки» хорошо демонстрируют один из краеугольных принципов построения сетей связи. Речь идет об аспекте разграничения зон обслуживания, на котором в том числе тоже держится связь, и о котором сейчас часто забывают.

Полный текст


18 февраля 2011 - 18:41
Гость_Олег_:
#2

"Ирония в том..." ... "В чем дело?"

Вы когда-нибудь слышали имя Paul Baran?


18 февраля 2011 - 18:46
Valaskor:
#3

Пользователь, узнавший слово tracert, начинает воображать себя сетевым гуру, а на ноке у провайдера вообще для него ламера сидят.
А если он еще и в место ip в трассе будет имена с географической привязкой, он сможет часами рассказывать техподдержке как и что должно ехать. Естественно, про то, что такое протокол ip, ttl, rtt, джиттер, AS, ассиметричное прохождение трафика, icmp-лимиты, обработка icmp аппаратными коммутаторами, looking-glass и прочее он ничего знать не хочет.


18 февраля 2011 - 19:19
rm_:
#4

Картина будет неполной, без ссылки на тему Трейс в сети Мегафона.

Код
Host                                   Loss%   Snt   Last   Avg  Best  Wrst StDev
1. ???
2. 85.26.238.9                          0.0%     5    1.5   1.4   1.1   1.5   0.2
3. www.yandex.ru                        0.0%     5   46.0  46.1  45.8  46.3   0.2

Host                                   Loss%   Snt   Last   Avg  Best  Wrst StDev
1. ???
2. 85.26.238.9                          0.0%     3    1.1   1.2   1.1   1.4   0.2
3. ihome.nag.ru                         0.0%     2   46.1  46.2  46.1  46.3   0.1

Host               Loss%   Snt   Last   Avg  Best  Wrst StDev
1. ???
2. 85.26.238.9      0.0%     5    1.4  24.0   1.2 114.5  50.6
3. 195.10.39.115    0.0%     4  101.5 101.2 100.1 101.9   0.8 (www.amd.com)


Слов нету чтобы охарактеризовать такое издевательство над трейсом.
Подумываю вот сейчас написать Мегафону по всем публичным адресам письмо (возможно даже открытое :), чтобы устранили это безобразие.
Да, внутри своей сети он может делать всё что угодно, но скрывать на трейсе весь путь (в том числе все хопы и операторов ПОСЛЕ себя) никто права не давал.


18 февраля 2011 - 19:24
Tima:
#5

Просмотр сообщенияrm_ (18 февраля 2011 - 19:19) писал:

Подумываю вот сейчас написать Мегафону по всем публичным адресам письмо (возможно даже открытое :), чтобы устранили это безобразие.
Да, внутри своей сети он может делать всё что угодно, но скрывать на трейсе весь путь (в том числе все хопы и операторов ПОСЛЕ себя) никто права не давал.


Напишите, напишите, может вам мегафон объяснит, раз тут людям не удалось, судя по тому топику :)


18 февраля 2011 - 19:54
diper:
#6

Думаю будет проще дождаться "Улучшителя кармы трафика" в операторской версии )))


18 февраля 2011 - 19:54
Tosha:
#7

Просмотр сообщенияrm_ (18 февраля 2011 - 19:19) писал:

Слов нету чтобы охарактеризовать такое издевательство над трейсом.
Подумываю вот сейчас написать Мегафону по всем публичным адресам письмо (возможно даже открытое :), чтобы устранили это безобразие.

А почему Вы думаете, что там издеваются? Вполне может быть у них какая-нибудь SDH (или иной глобальный транспорт) сеть, которая для IP протокола лежит ниже 3 уровня и не видна поэтому. Как не видны в трейсе коммутаторы.


18 февраля 2011 - 20:05
st_re:
#8

Tosha ну да, и www.amd.com включен напрямую в SDH мегафона.... как, я так понимаю, и все остальные миллионы хостов в интернете..


18 февраля 2011 - 22:00
vIv:
#9

Цитата

я так и не смог вспомнить, когда последний раз обращался к своему оператору телефонной связи с какой-то жалобой на аварию. Понятно, я утрирую. Но все-таки, а Вы вспомните?

Конечно! И счастлив, что много лет уже не вспоминаю этих гоблинов, тёток а фуфайках, у которых "большое короткое", которые путают провода в своих же розетках, которые умеют 4 раза ходить включать линейную карту АТС, - и всё время промахиваться. Вообще сами эти подвисающие линейные карты - тот ещё прикол: телефон помирает молча и об этом кто-то может узнать только когда абонент попытается куда-то позвонить и услышит, что номер не набирается, хотя гудок и гудит.
В последние годы, когда этот медный артефакт дох, я уже даже не переживал, ибо и хрен с ним, - позвоним с мобилки. А потом появилась повременнАя оплата звонков, а мобилки дешевели... в общем, уже много лет не пользуюсь бабушкофоном чего и всем желаю 8-)


18 февраля 2011 - 23:06
nomo:
#10

Просмотр сообщенияvIv (18 февраля 2011 - 22:00) писал:

счастлив, что много лет уже не вспоминаю этих гоблинов, тёток а фуфайках, у которых "большое короткое"

Может "неплотное"? Причём на просьбу объяснить в чём заключается физический смысл фразы "у вас "неплотное" они очень злятся и объяснение их заключается в том, что стрелка на приборе измерительного стола находится в секторе "неплотное".


Обсудить на форуме

Оставлять комментарии могут только зарегистрированные пользователи

Зарегистрироваться