Traceroute в терии и на практике
Итак, что же такое traceroute? Если задать этот вопрос десятку-другому Интернет-специалистов и пользователей, можно, в зависимости от квалификации, получить широкий спектр ответов: утилита, команда UNIX, команда Интернет, протокол, технология, техника... Одно очевидно хотя бы из названия — это такая штука, предназначенная для отслеживания пути прохождения пакетов по IP-сети из пункта А в пункт Б. Дословно: trace — прослеживать, route — маршрут.
В общем случае результатом работы traceroute будет список всех промежуточных узлов, находящихся между А и Б. В частности же в большинстве реализаций мы можем также получить время задержки до каждого промежуточного узла, то бишь время прохождения пакета туда и обратно.
а смысл?
"Для чего же нам сие ценное знание нужно?" — спросят новички. Ну, по крайней мере вот для чего:
1. troubleshooting. Всегда в жизни наступает тот дивный момент, когда вы не можете "достучатсья" до какого-то зловредного хоста. Трассировка маршрута — это, пожалуй, одно из первых действий, которое вам следует предпринять. Результат работы traceroute даст вам понять, в какой точке Интернет (в общем случае — IP-сети;) произошел "затык" — то ли упал именно этот хост, то ли его провайдер, то ли что-то в середине пути, то ли ваш провайдер, то ли у вас вообще с IP-соединением туго (бывает и такое — трассировка "благополучно" завершается, не показав ни одного промежуточного узла или с налету выдав ошибку). По-моему, это есть хороший тон — сначала хотя бы приблизительно локализовать проблему, а уже потом терроризировать "вышестоящую" организацию — системного администратора, техническую службу провайдера. Другое дело, если возможность трассировки маршрутов вам по тем или иным причинам недоступна... Но об этом чуть позже.
2. страсть к исследованиям. Исследования эти бывают, так сказать, разного масштаба и практического значения. Классика жанра — открыть для себя истинную топологию IP-сети своего провайдера (провайдеры, почему-то не любят делиться такой информацией с пользователями;(Как остроумно заметил в своей статье про traceroute Jeffery Carl, "пожалуй, наиболее интригующим в использовании traceroute является то, что юзер как бы получает доступ к совершенно секретному миру неразглашаемых частных соглашений о пиринге (обмене трафиком и маршрутной информацией) между провайдерами. Однако "настоящей наукой" это называть нельзя — как исползование вилкообразной палочки для обнаружения подземных источников воды, traceroute представляет собой “imprecise art”, который может дать правильные результаты, а может и не дать".
В более глобальном случае, с помощью traceroute вы можете иследовать саму "великую и ужасную" сеть Интернет, применяя на парктике полученные теоретические знания — о маршрутизации, системе имен DNS, опорных сетях (backbone), да мало ли о чем еще...;)
Возвращаясь к началу статьи, замечу, что, пожалуй, наиболее правильный ответ на вопрос — что такое traceroute? — будет содержать ключевое слово "утилита". Первая ее реализация, давшая название всем последующим версиям и вариациям на эту тему, датируется годом 1989 и разработана Группой Сетевых Исследований (Network Research Group, NRG) Подразделения Информатики и Компьютерной Науки (Information and Computing Sciences Division, ICSD) Национальной Лаборатории имени Лоренса Беркли (Lawrence Berkeley National Laboratory, LBNL). Несложно догадаться, что эта первая реализация была под операционную систему UNIX, вот почему многие скажут, что traceroute — это UNIX-команда. Впоследствии аналогичные утилиты были написаны и для других ОС. В Windows встроенная консольная утилита аналогичного назначения называется tracert. Поскольку в "просторечье" консольные утилиты иногда называют "командами", некоторые люди (в том числе и авторы умных книг) называют traceroute "командой Интернет". Кроме стандартной tracert под Windows было написано штук 20-30 различных пакетов для упрощения сетевого управления и диагностики, в которые входит та или иная разновидность traceroute. "Разновидность? — спросите вы, — а чем же они друг от друга отличаются?". Чтобы объяснить отличия и тонкости работы различных реализаций, есть смысл объяснить механизм, по которому работают утилиты traceroute.
технология и реализации: от общего к частному
Traceroute использует поле заголовка IP-пакета под названием "Время жизни" (Time To Live, TTL), которое задает время пребывания пакета в сети в секундах или в шагах, где шаг (hop, прыжок) — прохождение пакета до следующего маршрутизатора. Каждый маршрутизатор, на который попадает пакет, выполняет операцию TTL=TTL-1. При TTL=0 пакет из системы удаляется, а отправителю посылается в ответ ICMP-сообщение "Время жизни пакета истекло" (TIME_EXCEEDED).
Эту возможность IP-протокола и решили использовать для вычисления количества шагов до заданного хоста и определения адресов/имен узлов (маршрутизаторов), через которые пакет проходит. Утилита посылает в направлении заданного хоста пакет с TTL=1, и ждет, от кого вернется ответ TIME_EXCEEDED. Отвечающий записывается как первый хоп (результат первого шага на пути к цели). Затем посылаются последовательно пакеты с TTL=2, 3 и т.д. по порядку, пока при некотором значении TTL пакет благополучно не достигнет цели и получит от нее какой-то ответ. Почему "какой-то"? А вот тут-то и начинаются различия между реализациями traceroute.
*NIX-like traceroute посылает в сторону заданного хоста UDP-датаграммы на какой-то произвольный порт, обычно — на "высокий", скорее всего не занятый другим сервисом (например 12500, 30678) или на зарезервированный (например 0), в свежих версиях порт по умолчанию — 33434. Сначала посылается серия из 3-х таких пакетов с TTL=1, по приходу ответов замеряется время прохождения и (если иное не указано в опциях) определяется доменное имя транзитного узла. Затем, как сказано выше, посылаются очередные серии пакетов (здесь и далее под "серией" понимаем набор пакетов с одинаковым TTL, предназначенных для выявления одного и того же хопа). В конце мы получаем от конечного хоста отклик "Порт недоступен" (PORT_UNREACHABLE), что означает завершение трассировки. Результаты операции представляются в следующем виде:
traceroute to router7500.belpak.by (193.232.248.117), 30 hops max, 40 byte packets 1 iad1-core4-pos1-0.atlas.icix.net (165.117.52.186) 0 msec 4 msec 0 msec 2 dca1-core13-posX-X.atlas.icix.net (165.117.52.205) 0 msec dca1-core13-pos1-2.atlas.icix.net (165.117.53.33) 4 msec dca1-core13-posX-X.atlas.icix.net (165.117.52.205) 0 msec 3 dca1-core11-g2-0.atlas.icix.net (165.117.17.20) 4 msec 0 msec 4 msec 4 dca1-core10-pos6-0.atlas.icix.net (165.117.48.197) 0 msec 4 msec 0 msec 5 intermedia.cw.net (165.117.59.26) 4 msec 4 msec 0 msec 6 corerouter2.WestOrange.cw.net (204.70.9.139) [AS 3561] 40 msec 40 msec 40 msec 7 acr2-loopback.NewYorknyr.cw.net (206.24.194.62) [AS 3561] 40 msec 40 msec 40 msec 8 bcr2-so-1-0-0.London.cw.net (166.63.163.58) [AS 3561] 116 msec 120 msec 116 msec 9 har1.London.cw.net (166.63.162.2) [AS 3561] 120 msec 116 msec 120 msec 10 beltelecom.London.cw.net (166.63.164.170) [AS 3561] 156 msec * 164 msec
В современных версиях юниксового traceroute мы можем радикально влиять на процесс трассировки, самостоятельно задавая следующие параметры: номер порта получателя, адрес отправителя, "насильственная" маршрутизация от источника, выставление различных значений флагов "Тип сервиса" (TOS) и бита фрагментации (Don't fragment bit) и многое другое. Самое важное в относительно новых версиях traceroute — возможность посылки вместо UDP-датаграмм пакетов ICMP echo (которые обычно используются утилитой PING).
Windows tracert — это консольная (вызываемая из командной строки) утилита, появляющаяся в Windows с момента установки TCP/IP стека (поддержки TCP/IP для любого интерфейса, будь то диалап или сетевая карта). Делает то же самое, что и юниксовый, но в отличае от последнего посылает только ICMP echo-request-пакеты. Соответсвенно, конечный узел отвечает не PORT_UNREACHABLE, а ICMP echo-reply. И опций у виндозного аналога куда меньше :(.
Интересная, я бы даже сказала — революционная, техника используется в утилите Necrosoft Quick Traceroute (см. рис. 1), входящей в диагностический пакет под Windows 95/98/NT4/2000 — NScan. Суть нововведения в том, что серия UDP пакетов с разными TTL посылаются одновременно и по мере возвращения ответов заполняется таблица с перечнем транзитных узлов и значений задержки на каждом хопе. Причем сначала "проясняется" маршрут в виде цифровых IP-адресов, затем маршрут уточняется и выясняется его длина и, наконец, в последнюю очередь осуществляется определение DNS-имен транзитных хостов. В результате весь маршрут отслеживается в среднем за две секунды. Из-за принципа его работы (быстрое отслеживание всех узлов одновременно) точность значения задержки прямо пропорциональна скорости связи. А как же мы узнаем сколько серий пакетов посылать, если мы не знаем, сколько хопов до конечного хоста? — спросит внимательный читатель. Резонный вопрос:) Делается все просто: вы можете произвольно устанавливать значение для предполагаемого количества хопов и для количества перепроверок ненайденных узлов (по истечении заданного, опять же, времени ожидания ответа). После окончания циклов перепроверки перечень ответов на каждом хопе будет сокращен до реальной длины маршрута. Больше опций у программы пока нет, хотя в планах и замышляется кое-что интересненькое;)
И, наконец, пары слов заслуживает знаменитая программа Visual Route компании FORTEL. Это первая, и как мне кажется, единственная графическая утилита traceroute, наносящая путь прохождения пакетов на карту мира. Кроме этого, в таблице результатов вы найдете массу полезной дополнительной информации по каждому хопу, в частности, о местерасположения маршрутизатора и сети, к которой он принадлежит. За основу берутся данные, полученные от баз данных Whois. В новых версиях, в частности в 5.0, VisualRoute также дополняет трассировку комментариями, объясняющими происходящее на простом английской мязыке. Написана утилита на Java и требует для своей работы следующих реализаций Java: для Windows 95/98/NT4/ 2000 — Microsoft's Java VM начиная от билда 5.00.3167 или Sun's JRE (Java Runtime Environment) начинаа с версии 1.1; для Sun Solaris 2.5 или старше — Sun's JRE начиная от 1.1.6; для Linux kernel 2.2.5-15 — JVM с www.blackdown.org. JRE/JDK начиная с версии 1.1.7; для FreeBSD kernel 3.4-Release — JVM с www.freebsd.com/java 1.1.8 JVM.
Однако Visual Route может работать не только как локальная программа, установленная у вас на машине, но и как Java-applet, загружаемый с так называемого VisualRoute-сервера (см. рис. 2). Внимание: трассировка маршрута в таком случае осуществляется от того хоста, на котором установлен сервер. Вы также можете превратить вашу инсталляцию Visual-Route в сервер, на что, правда, требуется дополнительная лицензия. Публичные сервера расположены в Китае, Нидерландах, Польше, Великобритании (3 штуки) и США (3 штуки).
И тут мы плавно переходим к еще одной важной проблеме — удаленное использование traceroute. Для чего нам это может понадобиться? Вот вам навскидку несколько вариантов:
1. Есть ситуации, когда политика безопасности (например корпоративной сети) не позволяет вам использовать traceroute (например, запрещен входящий и/или исходящий ICMP- и/или UDP-трафик). Если выкрутиться, выбрав утилиту, способную работать в ваших "нелетных условиях", не удается, крайняя мера — трассировать маршруты от хоста, расположенного где-либо поблизости — например, с маршрутизатора провайдера, к которому подключена ваша сеть. Формально говоря, картинка будет, конечно, неполной, но фактически — вы ведь по идее можете узнать маршрут до этого хоста, и если выход в Интернет у вашей организации только один, то первые N хопов всегда будут неизменными.
Hint! Параноидальным администраторам, предпочитающим блокировать чуть ли не весь ICMP-трафик для предотвращения DoS-атак, рекомендую следующее: от большинства распространенных атак вы защититесь, фильтруя лишь входящие ICMP-сообщения, особенно echo-request и echo-reply. Оставив в покое исходящий ICMP-трафик, вы дадите возможность своим пользователям работать с traceroute — в полном объеме для UNIX-like (UDP) версий, и в виде трассировки маршрута до предпоследнего хопа — для Windows-like (ICMP) версий.
2. Случается такое, что маршрутные политики у разных провайдеров и сетей, через которые могут проходить ваши пакеты, устроены таким хитронавороченным образом, что пути пакета "туда" и "обратно" могут оказаться не идентичными.В таком случае более полную картину вам даст трассировка "от вас туда" и затем "оттуда до вас".
3. Если у вас, допустим, работает публичный веб-сервер, может случиться такое, что кто-то вас не видит, но при этом ваше сетевое соединение в порядке, возможно даже вы можете почти беспроблемно оттрассировать маршрут до этого невидящего хоста (потому что см. пункт 2.;) Придется трассировать "от него до вас" либо — если попросить "его" об этом невозможно, стараться подобраться как можно ближе к его сети и искать проблему там.
4. Наконец, иногда может быть любопытно трассировать маршруты между хостами, не имеющими к вам и вашей сети никакого отношения. Практический смысл? Пожалуйста: вам интересно, как "далеко" будет расположен от, скажем, необходимой вам немецкой аудитории веб-хостинг, который вы хотите приобрести. Протрассируйте его из "всей Германии" и проанализируйте результаты — нужен вам такой хостинг или нет.
Однако далеко не каждый из нас может похвастаться списком из десятков (а лучше сотен;) учетных записей на доступ к исполнению программ на удаленных серверах (на нормальном языке это звучит как shell account;). И не очень многие могут напрягать дюжину-другую друзей и знакомых по всему миру, прося оттрассировать что-то или, скажем, установить VisualRoute Server. Поэтому существуют веб-сайты, предоставляющие эту услугу, причем, обычно, задаром. Чаще всего они принадлежат крупным провайдерам и другим могучим узлам Интернета, например, так называемым "Точкам обмена Интернет-трафиком" (Internet eXchange, IX) или MAE (Metropoliten Area Exchange), что по сути почти то же самое. И чаще всего услуга traceroute (trace) прилагается к другим, вынесенным для свободного использования через веб, диагностическим утилитам и системам просмотра статистики по трафику и маршрутной информации этих самых IX. Такие веб-интерфейсы называются Looking Glass, то бишь "увеличительное стекло".
Список "увеличительных стекл" и просто веб-интерфейсов traceroute вы можете найти, например, наwww.traceroute.org или по адресуhttp://www.boardwatch.com/Find_Backbone.htm. А вот еще одна приятная штука, которую мне лично очень нравится использовать. Ребята написали очень простой скрипт, позволяющий с одной страницы запусткать трассировку сразу с кучи таких веб-интерфейсов. Результаты выводятся в отдельном окне браузера, разделенном по горизонтали на столь частей, от скольких серверов вы производите трассировку. Расположено это чудо по адресуhttp://www.tracert.com/cgi-bin/trace.pl. У проекта есть только один существенный недостаток — никто не отслеживает текущее состояние тех 200 с лишним веб-интерфейсов, с которых можно трейсить. Поэтому дабы вы, уважаемые читатели, не нервировались лишний раз ошибками, выползающими в браузере, я протестировала все эти сервера и результаты (положительные) помещаю во врезку к этой статье.
the art of tracerouting
Как счиатет автор упомянутой в начале моего повествования статьи, трассировка маршрутов сродни некому виду околонаучного поиска, вобщем — алхимия. Получить "путевой листок" похождения пакета — это раз плюнуть, а вот расшифровать и сделать верные выводы — целое искусство. Проиллюстрирую эту мысль на нескольких примерах.
Сделаем перекрестный (туда и обратно) трейс между одним английским хостом (217.14.129.2) и компьютером, подключенным к беспарольному доступу Beltelecom (194.158.212.69). Чтобы вам было удобнее его разглядывать, добавим условный "нулевой хоп" — собственно машина-отправитель (См. ссылка 1.).
Для начала посмотрим на названия хостов, через которые "пролетают" наши пакеты. DNS-имена, хоть и являются по сути своей условными (никто не мешает мне назвать свой маршрутизатор, скажем, vjuen. viet-nam.da.ru;), но все же исторически сложилось, что солидные конторы придерживаются в именовании машин некоторых традиционных устоев и закономерностей. Поэтому из DNS-имен мы можем сделать приблизительные выводы о местонахождении маршрутизаторов (NewYork, London — который в америке, прошу заметить;), о принадлежности к фирме-провайдеру (beltelecom, Teleglobe, sprintlink), о типе оборудования (AS5300, router7500), о скорости канала, его "важности" и других параметрах, "намекающих" нам о чем-то (if-2-3.core1, ebone, gigabitethernet7-0, serial2-3).
Затем каждый адрес можно проверить через базу данных Whois, получив сведения о компании, во владении которой находятся эти адреса.
Теперь посмотрим на сами маршруты и тут же обнаружим по крайней мере одну забавную вещь: количество хопов туда и обратно — одинаковое, но маршруты принципиально разные: туда мы идем через Teleglobe, а назад возвращаемся через Cable & Wireless. Причем не надо быть "супернавороченным хакером", чтобы сделать предположение, что beltele-com. London.cw.net и router7500.belpak.by — это одно лицо. И вправду оно так или нам лишь показалось — история умалчивает;)
Еще забавное наблюдение (см. маршрут Минск-Англия) — между 8 и 14 хопами мы видим явную неравномерность по времени задержки. Как же это получилось, что до 14-го хопа мы доскакали за 360 миллисекунд, а до предыдущего тащились ажно целую секунду? Незначительный перекос можно, конечно, списать на взрывной трафик, неожиданно возникающий на участке сети, но не троекратную же разницу в задержке! Единственное, что приходит на ум — это то, что некоторые маршрутизаторы слишком долго копаются с реакцией на пакет с TTL=0 — формированием и отсылкой TIME_EXCEEDED-сообщения. В таком случае напрашивается резонный вывод, что измерение времени задержки прохождения пакетов с помощью traceroute — дурное занятие. Да и, вообще-то, для этого PING существует...;)
А вот вам для разнообразия еще один перекрестный трейс, на сей раз участники эксперимента — все тот же диалапщик (194.158.212.69) и хост, расположенный в Германии (193.141.98.37) (См. ссылка 2.).
Здесь, помимо прочих, аналогичных прошлому примеру, "открытий", мы наблюдаем разницу по количеству хопов, но меньшую асиметричность маршрутизации. Хотя различия в путях туда и обратно, конечно, есть. В частности, по дороге в Германию мы больше времени, чем на обратном пути, проводим в сетях qwest/kpnqwest. Дорога из Германии примечательна тем, что мы на один хоп больше времени проводим в Ганновере (хотя, повторюсь, все предположения, основанные на именах, достаточно условны), быстро пробегаем qwest/kpnqwest и начинаем блуждать по Teleglobe'овским базовым маршрутизаторам. Заметили странную "возню" на 16 хопе? А не наш ли это, случайно, старый знакомый — router 7500?
Очень может быть...
путь из Минска в Англию:
0---194.158.212.69 (194.158.212.69) 1230 ms220 ms211 ms194.226.125.106 2211 ms210 ms210 msrouter7500.belpak.by [193.232.248.117] 3380 ms361 ms330 msif-10-0-2.bb2.PennantPoint.Teleglobe.net [207.45.215.69] 4340 ms361 ms410 msif-2-3.core1.PennantPoint.Teleglobe.net [207.45.222.125] 5461 ms390 ms461 msif-1-2.core1.NewYork.Teleglobe.net [207.45.222.74] 6421 ms*321 msif-10-0.bb8.NewYork.Teleglobe.net [207.45.223.110] 7391 ms491 ms420 mssl-gw9-nyc-7-0.sprintlink.net [144.232.173.129] 8661 ms741 ms641 mssl-level3-5-0.sprintlink.net [144.232.173.74] 9721 ms721 ms641 msso-4-1-0.mp1.NewYork1.level3.net [209.247.10.37] 10340 ms361 ms320 ms212.187.128.137 11330 ms341 ms350 msloopback0.hsipaccess1.London1.Level3.net [212.113.2.67] 12350 ms351 ms340 ms212.113.14.22 131001 ms1002 ms1031 mslon-edge-1.router.inweb.net.uk [212.38.64.22] 14360 ms351 ms360 ms212.38.84.65 15951 ms1022 ms1121 ms217.14.129.2а вот путь из Англии в Минск:
0217.14.129.2(217.14.129.2)--- 1212.84.184.1(212.84.184.1)1.068 ms0.91 ms0.932 ms 2212.38.84.66(212.38.84.66)3.154 ms3.265 ms3.397 ms 3lon-edge-2.router.inweb.net.uk(212.38.64.2)3.584 ms3.297 ms3.58 ms 4serial2-3.hsa1.lon1.Level3.net(212.113.14.21)4.475 ms4.715 ms4.598 ms 5loopback0.mp1.lon1.l3.net(212.113.2.11)26.864 ms13.733 ms23.605 ms 6gigabitethernet7-0.ipcolo2.London1.L3.net(212.113.0.113)52.721 ms4.046 ms7.245 ms 7gblon303-tc-p10-0.ebone.net(192.121.154.9)4.343 ms5.047 ms6.09 ms 8195.10.35.89(195.10.35.89)4.592 ms4.733 ms4.371 ms 9tantale-1-193.pandemonium.fr(195.10.7.193)5.498 ms5.4 ms4.686 ms 10bcr2-so-2-0-0.Thamesside.cw.net(166.63.209.197)4.997 ms4.769 ms4.565 ms 11bcr2-so-0-2-0.London.cw.net(166.63.209.150)4.872 ms4.725 ms4.624 ms 12har1.London.cw.net(166.63.162.2)5.245 ms4.768 ms5.363 ms 13beltelecom.London.cw.net(166.63.164.170)126.909 ms118.673 ms135.283 ms 14AS5300-1.belpak.by(193.232.248.106)145.933 ms149.773 ms140.442 ms 15194.158.212.69(194.158.212.69)1554.71 ms344.525 ms847.411 ms
идем в Германию:
0———193.141.98.37 [193.141.98.37] 1230 ms221 ms240 ms194.226.125.106 2241 ms220 ms210 msrouter7500.belpak.by [193.232.248.117] 3711 ms381 ms381 msif-11-0-2.bb2.PennantPoint.Teleglobe.net [207.45.215.65] 4471 ms360 ms401 msif-3-0.core1.PennantPoint.Teleglobe.net [207.45.222.69] 5361 ms420 ms371 msif-1-2.core1.NewYork.Teleglobe.net [207.45.222.74] 6371 ms360 ms331 msix-1-8.core1.NewYork.Teleglobe.net [207.45.196.138] 7401 ms450 ms331 msjfk-core-03.inet.qwest.net [205.171.30.13] 8360 ms351 ms360 msjfk-core-01.inet.qwest.net [205.171.30.9] 9401 ms380 ms341 mswdc-core-02.inet.qwest.net [205.171.5.235] 10411 ms481 ms510 mswdc-core-01.inet.qwest.net [205.171.24.1] 11370 ms401 ms370 mswdc-brdr-03.inet.qwest.net [205.171.24.38] 12460 ms381 ms481 msWash-cr01.DC.US.kpnqwest.net [205.171.24.114] 13531 ms501 ms541 msObl-cr01.NL.kpnqwest.net [134.222.228.25] 14550 ms511 ms501 msFfm-nr04.DE.kpnqwest.net [134.222.229.242] 15540 ms541 ms541 msCORE1.frankfurt.xlink.net [134.222.19.6] 16521 ms511 ms501 msr2-erp1.f.de.KPNQwest.net [194.122.243.50] 17551 ms451 ms500 msr1-p1.h.de.KPNQwest.net [194.122.232.222] 18471 ms491 ms500 mspopcore.pop-hannover.net [193.141.162.130] 19471 ms511 ms500 mspop9.pop-hannover.de [193.98.1.212] 20431 ms491 ms490 mscishelios2.helios.de [193.141.98.1] 21601 ms491 ms481 msproxy.helios.de [193.141.98.37]а теперь из Германии:
0proxy.helios.de(193.141.98.37)——— 1cishelios2.helios.de(193.141.98.1)4 ms2 ms2 ms 2pop9.pop-hannover.de(193.98.1.212)5 ms5 ms5 ms 3popcore.pop-hannover.de(193.98.1.213)4 ms4 ms4 ms 4hannover1.core.xlink.net(193.141.162.131)11 ms20 ms4 ms 5r2-erp1.f.de.KPNQwest.net(194.122.232.221)8 ms8 ms8 ms 6Ffm-nr03.DE.kpnqwest.net(134.222.19.13)10 ms10 ms10 ms 7Obl-cr01.NL.kpnqwest.net(134.222.228.229)17 ms15 ms16 ms 8Wash-cr01.DC.US.kpnqwest.net(134.222.228.34)98 ms99 ms98 ms 9wdc-brdr-03.inet.qwest.net(205.171.24.113)99 ms98 ms98 ms 10205.171.1.102(205.171.1.102)100 ms99 ms99 ms 11if-0-1.core2.NewYork.Teleglobe.net(207.45.223.169)105 ms104 ms104 ms 12if-3-0.core1.NewYork.Teleglobe.net(207.45.223.177)103 ms103 ms103 ms 13if-7-1.core1.Montreal.Teleglobe.net(64.86.80.29)112 ms113 ms113 ms 14if-2-2.core1.PennantPoint.Teleglobe.net(207.45.222.82)123 ms123 ms123 ms 15if-8-0-0.bb2.PennantPoint.Teleglobe.net(207.45.222.70)123 ms123 ms124 ms 16ix-0-0-1-0.bb2.PennantPoint.Teleglobe.net(207.45.215.90)213 ms ix-10-0-2.bb2.PennantPoint.Teleglobe.net(207.45.215.70)332 ms ix-0-0-1-0.bb2.PennantPoint.Teleglobe.net(207.45.215.90)320 ms 17AS5300-1.belpak.by(193.232.248.106)308 ms307 ms267 ms 18194.158.212.69(194.158.212.69)464 ms447 ms563 ms
На самом деле, чтобы построить хотя бы очень приблизительную топологию сети какого-то провайдера, а особенно выявить все его так называемые peering'и (обмен трафиком и маршрутной информацией, проще говоря — связи;), нужно сделать огромное количество traceroute-исследований: из разных точек внутри исследуемой сети и из множества точек за пределами сети. Чем больше "замеров" — тем точнее результат:) А затем сравнивать, анализировать, запрашивать уточняющую информацию... Но все это — уже совсем другая история. Пример с выявлением сетевой топологии — лишь небольшая часть задач, для которых применима traceroute, но он, IMHO, дает наиболее интригующие и забавные результаты, иллюстрируя исключительную полезность описанной утилиты:) Удачи вам на виртуальных дорогах;)
результаты проверки на работоспособность веб-интерфейсов к traceroute, доступных сwww.tracert.com
обсуждение статьи
Все это — рабочие системы.
Australia,,
Australia,, Satori
Australia, Australian Capital Territory, Canberra, Telstra
Australia, Mid North Coast, Midcoast.com
Australia, New South Wales, Sydney, Aussie NET — ISP (via Telstra)
Australia, New South Wales, Sydney, Connect — Backbone — Proxy 1 (via Ausbone)
Australia, New South Wales, Sydney, Connect — Backbone — Proxy 2 (via Ausbone)
Australia, Queensland, Brisbane, BIT — Brisbane Internet Technology — ISP (via
Ausbone — Connect.Com.au)
Australia, South Australia, Adelaide, SE NET — ISP
Australia, Victoria, Ballarat, CBL — Cyberlink Access Systems — ISP
Australia, Victoria, Melbourne, World Wire Pty. (via Ausbone)
Belgium, Brussels, Belgian Research Network (via BELNET)
Brazil,, Rede Internet Minas — CGO Online
Canada, Alberta, Edmonton,
Canada, British Columbia, Prince George, Mag-Net Internet
Canada, British Columbia, Vancouver, National Meson Research Facility (via CANET/MCI)
Canada, Toronto, Interlog
Czech Republic,, PVT.NET ISP (via MCI-AlterNet)
Denmark, Еrhus, Tele Danmark Internet
Estonia, Tallin, Estonia-Wide Web
Estonia, Tallinn, ASO
Estonia, Tallinn, Estpak Data
Finland, Espoo, CSC — Center for Scientific Computing
France, Paris, EU.org (via Global One)
France, Rocquencourt, AFNIC
Greece, Athens, NTUA — National Technical University of Athens
Hungary, Budapest, KFKI-RMKI — Research Institute for Particle and Nuclear Physics
Italy,, INFN — Istituto Nazionale di Fisica Nucleare
Italy, Pisa, CS Informatica S.r.L (AS 8911)
Italy, Torino, Gruppo IH — ISP
Korea, Seoul, Dongguk University
Latvia,, Parks — ISP
Luxembourg,, Restena
Netherland, Amsterdam, Support Net
Netherland, Hoofddorp, AT&T-Unisource — ISP
Russia, Moscow, Parkline
Russia, Novosibirsk, Rinet
Russia, Yaroslavl, Yaroslavl Computer Networks
South Africa,, Wasp International
South Africa, Claremont, NIS — Network Internet Services
Spain,, Sistema Ocйano
Spain, Madrid, Wisper Madrid
Switzerland,, Fastnet
Switzerland,, SWITCH — Swiss Academic & Research Network (via TEN34-SWITCH)
Switzerland, Bubikon, Active-Net AG — ISP (via Alter Net)
Switzerland, F.Buntschu, LCSI Global-IP — Global One
Switzerland, Geneva, University of Geneva (via TEN34-Switch)
Thailand,, AuNet NOC — Assumption University
UK,, UKIP (Internet Consltants) Limited
UK, Bolton, Shellnet — The North West's Premier Busines Internet Provider
Ukraine,, AistNet
Ukraine,, Infocom
USA?,, Petersen Net
USA,, Global One
USA,, Godlike (via Digex)
USA,, Northwes Nexus
USA,, Willamette Valley Internet
USA,, Yahoo
USA, AZ, Phoenix, GetNet — ISP (via MCI CAIS)
USA, CA, Alameda, Alameda Networks (via Level3.net)
USA, CA, Berkeley, ESnet — Energy Sciences Network
USA, CA, El Segundo, InterWorld Communications (via LN.net, Concentric, Epoch, MAE-LA, AGIS)
USA, CA, Los Alamitos, California State University
USA, CA, Sacramento, CalWeb Internet Services
USA, CA, San Diego, SDSC — San Diego Supercomputer Center
USA, CA, San Jose, AboveNet
USA, CA, San Jose, Bungi
USA, CA, Stanford, SLAC — Stanford Linear Accelerator Center (via ESNet)
USA, Dallas, Internet Global Services (via MCI-SPRINT)
USA, Erie, Erie Net
USA, FL, Fort Lauderdale, DialtoneInternet.Net
USA, GA, Atlanta, Lyceum Internet (via AlterNet/NetRail)
USA, Grand Rapids, MI, Iserv Co.
USA, HI, Honolulu, LavaNet
USA, MA, Cambridge, MIT
USA, Maine, Bar Harbor, AcadiaNet
USA, Maryland, Rockville, Capital PC User Group
USA, MD, Rockville, Heller Information Services (via MCI-CAIS)
USA, NJ, Mt. Holly, Pics On-line
USA, NJ, Princeton, CIT Network Systems, Princeton University
USA, NY, Buffalo, Blue Moon — ISP
USA, NY, New York City, Stealth Communications, Inc.
USA, Ohio, Columbus, Franklin University, Computer Sciences Online
USA, Salt Lake City, UT, (Utah), Verio Web Hosting (via Sprint — MCI)
USA, TX, Austin, Illuminati Online
USA, TX, Leander, FMP Computer Services
USA, VA, Falls-Church, Pubnix Access Systems (via UUNET)
USA, WA, Vancouver,, Orion Digital Systems
Alice D. Saemon
обсуждение статьи
Сетевые решения. Статья была опубликована в номере 02 за 2001 год в рубрике RFC
