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 мы можем радикально влиять на процесс трассировки, самостоятельно задавая следующие параметры: номер порта получателя, адрес отправителя, "насильственная" маршрутизация от источника, выставление различных значений флагов "Тип сервиса" (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 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 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