Пятница
29.03.2024, 02:00
serj129.ucoz.ru
| RSS
Главная Статьи
Меню сайта

Категории каталога
Разное [11]
Подборка различных статей, когда-либо привлекших внимание и вызвавших желание, чтобы их кто-нибудь прочел.
Юмор [0]
GNU/Linux [3]
Экономика [1]

Главная » Статьи » Разное

Traceroute в теории и на практике
Traceroute в теории и на практике

Компьютерная газета

Сегодня мне бы хотелось поговорить о такой простой, знакомой "с детства" каждому работающему с IP-сетями специалисту вещи, как 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)

1 230 ms 220 ms 211 ms
194.226.125.106

2 211 ms 210 ms 210 ms
router7500.belpak.by [193.232.248.117]

3 380 ms 361 ms 330 ms
if-10-0-2.bb2.PennantPoint.Teleglobe.net [207.45.215.69]

4 340 ms 361 ms 410 ms
if-2-3.core1.PennantPoint.Teleglobe.net [207.45.222.125]

5 461 ms 390 ms 461 ms
if-1-2.core1.NewYork.Teleglobe.net [207.45.222.74]

6 421 ms * 321 ms
if-10-0.bb8.NewYork.Teleglobe.net [207.45.223.110]

7 391 ms 491 ms 420 ms
sl-gw9-nyc-7-0.sprintlink.net [144.232.173.129]

8 661 ms 741 ms 641 ms
sl-level3-5-0.sprintlink.net [144.232.173.74]

9 721 ms 721 ms 641 ms
so-4-1-0.mp1.NewYork1.level3.net [209.247.10.37]

10 340 ms 361 ms 320 ms
212.187.128.137

11 330 ms 341 ms 350 ms
loopback0.hsipaccess1.London1.Level3.net [212.113.2.67]

12 350 ms 351 ms 340 ms
212.113.14.22

13 1001 ms 1002 ms 1031 ms
lon-edge-1.router.inweb.net.uk [212.38.64.22]

14 360 ms 351 ms 360 ms
212.38.84.65

15 951 ms 1022 ms 1121 ms
217.14.129.2

а вот путь из Англии в Минск:

0 217.14.129.2 (217.14.129.2) - - -

1 212.84.184.1 (212.84.184.1)
1.068 ms 0.91 ms 0.932 ms

2 212.38.84.66 (212.38.84.66)
3.154 ms 3.265 ms 3.397 ms

3 lon-edge-2.router.inweb.net.uk (212.38.64.2)
3.584 ms 3.297 ms 3.58 ms

4 serial2-3.hsa1.lon1.Level3.net (212.113.14.21)
4.475 ms 4.715 ms 4.598 ms

5 loopback0.mp1.lon1.l3.net (212.113.2.11)
26.864 ms 13.733 ms 23.605 ms

6 gigabitethernet7-0.ipcolo2.London1.L3.net (212.113.0.113)
52.721 ms 4.046 ms 7.245 ms

7 gblon303-tc-p10-0.ebone.net (192.121.154.9)
4.343 ms 5.047 ms 6.09 ms

8 195.10.35.89 (195.10.35.89)
4.592 ms 4.733 ms 4.371 ms

9 tantale-1-193.pandemonium.fr (195.10.7.193)
5.498 ms 5.4 ms 4.686 ms

10 bcr2-so-2-0-0.Thamesside.cw.net (166.63.209.197)
4.997 ms 4.769 ms 4.565 ms

11 bcr2-so-0-2-0.London.cw.net (166.63.209.150)
4.872 ms 4.725 ms 4.624 ms

12 har1.London.cw.net (166.63.162.2)
5.245 ms 4.768 ms 5.363 ms

13 beltelecom.London.cw.net (166.63.164.170)
126.909 ms 118.673 ms 135.283 ms

14 AS5300-1.belpak.by (193.232.248.106)
145.933 ms 149.773 ms 140.442 ms

15 194.158.212.69 (194.158.212.69)
1554.71 ms 344.525 ms 847.411 ms

идем в Германию:

0 — — —
193.141.98.37 [193.141.98.37]

1 230 ms 221 ms 240 ms
194.226.125.106

2 241 ms 220 ms 210 ms
router7500.belpak.by [193.232.248.117]

3 711 ms 381 ms 381 ms
if-11-0-2.bb2.PennantPoint.Teleglobe.net [207.45.215.65]

4 471 ms 360 ms 401 ms
if-3-0.core1.PennantPoint.Teleglobe.net [207.45.222.69]

5 361 ms 420 ms 371 ms
if-1-2.core1.NewYork.Teleglobe.net [207.45.222.74]

6 371 ms 360 ms 331 ms
ix-1-8.core1.NewYork.Teleglobe.net [207.45.196.138]

7 401 ms 450 ms 331 ms
jfk-core-03.inet.qwest.net [205.171.30.13]

8 360 ms 351 ms 360 ms
jfk-core-01.inet.qwest.net [205.171.30.9]

9 401 ms 380 ms 341 ms
wdc-core-02.inet.qwest.net [205.171.5.235]

10 411 ms 481 ms 510 ms
wdc-core-01.inet.qwest.net [205.171.24.1]

11 370 ms 401 ms 370 ms
wdc-brdr-03.inet.qwest.net [205.171.24.38]

12 460 ms 381 ms 481 ms
Wash-cr01.DC.US.kpnqwest.net [205.171.24.114]

13 531 ms 501 ms 541 ms
Obl-cr01.NL.kpnqwest.net [134.222.228.25]

14 550 ms 511 ms 501 ms
Ffm-nr04.DE.kpnqwest.net [134.222.229.242]

15 540 ms 541 ms 541 ms
CORE1.frankfurt.xlink.net [134.222.19.6]

16 521 ms 511 ms 501 ms
r2-erp1.f.de.KPNQwest.net [194.122.243.50]

17 551 ms 451 ms 500 ms
r1-p1.h.de.KPNQwest.net [194.122.232.222]

18 471 ms 491 ms 500 ms
popcore.pop-hannover.net [193.141.162.130]

19 471 ms 511 ms 500 ms
pop9.pop-hannover.de [193.98.1.212]

20 431 ms 491 ms 490 ms
cishelios2.helios.de [193.141.98.1]

21 601 ms 491 ms 481 ms
proxy.helios.de [193.141.98.37]

а теперь из Германии:

0 proxy.helios.de (193.141.98.37)
— — —

1 cishelios2.helios.de (193.141.98.1)
4 ms 2 ms 2 ms

2 pop9.pop-hannover.de (193.98.1.212)
5 ms 5 ms 5 ms

3 popcore.pop-hannover.de (193.98.1.213)
4 ms 4 ms 4 ms

4 hannover1.core.xlink.net (193.141.162.131)
11 ms 20 ms 4 ms

5 r2-erp1.f.de.KPNQwest.net (194.122.232.221)
8 ms 8 ms 8 ms

6 Ffm-nr03.DE.kpnqwest.net (134.222.19.13)
10 ms 10 ms 10 ms

7 Obl-cr01.NL.kpnqwest.net (134.222.228.229)
17 ms 15 ms 16 ms

8 Wash-cr01.DC.US.kpnqwest.net (134.222.228.34)
98 ms 99 ms 98 ms

9 wdc-brdr-03.inet.qwest.net (205.171.24.113)
99 ms 98 ms 98 ms

10 205.171.1.102 (205.171.1.102)
100 ms 99 ms 99 ms

11 if-0-1.core2.NewYork.Teleglobe.net (207.45.223.169)
105 ms 104 ms 104 ms

12 if-3-0.core1.NewYork.Teleglobe.net (207.45.223.177)
103 ms 103 ms 103 ms

13 if-7-1.core1.Montreal.Teleglobe.net (64.86.80.29)
112 ms 113 ms 113 ms

14 if-2-2.core1.PennantPoint.Teleglobe.net (207.45.222.82)
123 ms 123 ms 123 ms

15 if-8-0-0.bb2.PennantPoint.Teleglobe.net (207.45.222.70)
123 ms 123 ms 124 ms

16 ix-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

17 AS5300-1.belpak.by (193.232.248.106)
308 ms 307 ms 267 ms

18 194.158.212.69 (194.158.212.69)
464 ms 447 ms 563 ms

На самом деле, чтобы построить хотя бы очень приблизительную топологию сети какого-то провайдера, а особенно выявить все его так называемые peering'и (обмен трафиком и маршрутной информацией, проще говоря — связи;), нужно сделать огромное количество traceroute-исследований: из разных точек внутри исследуемой сети и из множества точек за пределами сети. Чем больше "замеров" — тем точнее результат:) А затем сравнивать, анализировать, запрашивать уточняющую информацию... Но все это — уже совсем другая история. Пример с выявлением сетевой топологии — лишь небольшая часть задач, для которых применима traceroute, но он, IMHO, дает наиболее интригующие и забавные результаты, иллюстрируя исключительную полезность описанной утилиты:) Удачи вам на виртуальных дорогах;)

Alice D. Saemon

результаты проверки на работоспособность веб-интерфейсов к 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

Источник: http://www.sdteam.com/?tid=80

Категория: Разное | Добавил: Serj129 (04.08.2010)
Просмотров: 1478 | Рейтинг: 0.0/0 |
Поиск

Друзья сайта

Статистика


Copyright Serj129 © 2024