Автор: © Jon Meek
- American Home Products Corporation -

Перевод: © Владимир Меренков

Введение

В этой статье мы расскажем о системе для записи и анализа "сырых" пакетов данных сетей Frame Relay и каналов точка-точка T-1. Данные собраны "подслушиванием" протокола HDLC (High-level Data Link Control Procedure) на линиях приема и передачи между маршрутизатором и CSU/DSU (устройства для подключения маршрутизатора к выделенной цифровой линии). Анализ данных с канала фиксирует информацию о загруженности канала или интенсивности использования приложения за период времени от 1 секунды и меньше. Управление системой и получение отчетов (как стандартных, так и специальных) доступно через Web интерфейс, который обеспечивает наша система. Полученная Информация из пакетов данных может быть использована для отладки приложений точно так же, как и при использовании обычной системой для перехвата пакетов данных.

Зачем нам понадобилась эта система

Сложные сети Frame Relay зачастую организовываются по принципу колеса: центр (ступица) и спицы (``hub and spoke''). Множество хабов ("центров") могут соединять подчиненные оффисы с очень широкой географией как показано на рис.1. Затем хабы соединяются между собой соединителями с высокой пропускной способностью. 

Рисунок 1: Архитектура сети Frame Relay - принцип колеса.

Отлаживая проблемы сети Frame Relay и в части управления пропускной способностью, и в части интенсивности использования приложений, мы использовали tcpdump для записи сетевых пакетов на Ethernet интерфейсе маршрутизатора. Однако часто нам хотелось бы посмотреть какие именно данные проходят по линии доступа T-1/E-1. Это особенно актуально для Frame Relay hub sites, где много пакетов проходят через роутер, но никогда не появляются на стороне Ethernet-сегмента, потому что их место назначения - другая часть нашей сети. Вдобавок нужная информация из заголовков Frame Relay теряется при конвертации фреймов в пакеты Ethernet.

Рисунок 1 иллюстрирует проблему. Из трех типов трафика, показанных на рисунке, только ERP (Enterprise Resource Planning) трафик достигает ``UK Data Center''. Пакеты для двух других приложений, LAN mail и Internet, не появляются в Ethernet сегменте, но могут поглощать большую долю полосы пропускания, доступную на линии последовательного доступа к этому хабу.

После того как накопился большой массив эмпирических данных в результате отладки массы приложений и анализа трафика, стало ясно, что нам нужна система для записи "сырых" кадров вне маршрутизатора, непосредственно с соединительных линий. Тогда мы смогли бы проверить любую информацию в заголовке Frame Relay и такое количество данных, какое захотели бы записать, включая IP заголовки и информацию в пакете.

Были рассмотрены различные коммерческие системы, но не было найдено ни одной, которая отвечала бы требованию записи пакетов Frame Relay за время большее, чем несколько минут. Наша компания уже использовала два брэнда ``WAN Probes'', но они в основном предназначены для диагностики в реальном масштабе времени, а также хронологического анализа данных типа RMON (Remote Network MonitoringManagement Information Base). В качестве одной из альтернатив мы рассмотривали использование Network Flight Recorder [Ranu97], но он не позволяет производить запись данных из соединительных линий глобальной сети.

Тогда как большинство роутеров Frame Relay считают биты уведомления о перегрузке (FECN and BECN, Forward and Backward Explicit Congestion Notification), они не считают биты DE (помеченный к удалению). Подсчет битов FECN и BECN, которые мы записывали в течение 5-ти минут через SNMP (Siple Network Managment Protocol) не дает решения проблемы ассоциации их появления с определенным моментом времени или с определенным пакетом. Отладка взаимодействия приложения с сетью без "сырых" данных - это очень трудная задача.

В этой статье мы сначала рассмотрим требования, предъявляемые к аппаратному и программному обеспечению для сбора пакетов. Потом, обсудим программное обеспечение для анализа трафика, рассмотрев реальные примеры анализа, включая "Переполнение и планирование емкости канала", "Использование данных необработанных ("сырых") пакетов" и "Профилирование приложений". Два коротких раздела объясняют расширение системы для канала точка-точка T1 и использование tcpdump для выполнения похожего анализа, когда интересующие пакеты доступны в локальной сети. И, наконец, закончим представлением нескольких идей о дальнейшем использовании изложенной в статье информации.

Аппаратное обеспечение

Сбор данных, идущих в двух направлениях, требует использования двух приемных линий и сигнала синхронизации на карте Sangoma. Передающие линии к карте не подключаются. Тогда как мы успешно подсоединили каналы T-1/E-1, используя короткие кабели, напрямую подключенные к линиям связи, все же рекомендуется использование активного ответвителя ``Multi-Interface Tap''. Эти ответвители имеют высокое сопротивление сигнальным линиям и позволяют использовать длинные кабели между ответвлением и компьютером. Стоимость системы мониторинга одной линии T-1/E-1, включая PC, плату связи и WAN ответвления - около US$2000. Вторая линия T-1/E-1 может контролироваться на том же самом PC за дополнительные US$800.

Сбор и анализ

Такая модель обеспечивает значительную простоту при 15-ти минутной задержке по сравнению с системами реального времени. Она также дает удобное представление сумраного результата и метод для определения данных в пакете, когда требуется более глубокий анализ. Требования к аппаратуре в такой постпроцессорной системе более низкие; все, что необходимо для процесса обработки - это завершить работу менее чем за 15 минут, чтобы не потерять пакеты.

Программное обеспечение для сбора

Драйверы Sangoma были установлены в конфигурации для CHDLC (Cisco HDLC). Программа перехвата пакетов - frpcap, записывает файлы в формате, похожем на формат tcpdump. Наиболее значимым отличием является то, что вместо заголовка Ethernet записывается заголовок Frame Relay. Первые 150 байт каждого пакета сохраняются для предоставления контекстной информации во время анализа приложения.

Процесс сбора пакетов управляется Perl-скриптом frcap_run, который запускается каждые 15 минут. Frcap_run останавливает текущие frcap процессы (один для каждого направления данных) и немедленно запускает другую пару. Потом запускается программа обработки трафика fr-decode для двух файлов пакетов. Затем файлы с информацией сжимаются и все файлы старше предустановленной даты удаляются, чтобы сохранить место на диске. Для довольно загруженных каналов Frame Relay на одной линии доступа T-1, данные за 8 дней займут 3-6 Гбайт дискового пространства.

Программное обеспечение для анализа

Суммарный отчет о работе канала Frame Relay (Филадельфия)
Исходящие из Филадельфии данные
Время сбора информации: Четверг Февраль 10 11:00:00 2000 - Четверг Февраль 10 11:15:01 2000 GMT

Суммарный отчет PVC (Исходящие из Филадельфии данные)
 DLCI   Packets       Bytes    %    FECNs       BECNs       DEs DE  No DE
  460   79,648   12,422,725  30.2 %   0  0.0 %    0  0.0 %   0   0    328  London
  490  119,404   28,677,448  69.8 %   0  0.0 %    0  0.0 %   0   0  1,321  Paris
  All  199,052   41,100,173

Подсчеты по протоколу (Исходящие из Филадельфии данные)
DLCI   Protocol           Packets        Bytes  % of PVC     TCP ReTransmits
460 London
       0800 06 IP TCP      40,291    9,068,685  ( 73.0%)       328 (  0.8%)
       8137    IPX         34,675    2,805,741  ( 22.6%)
       0800 11 IP UDP       1,671      316,118  (  2.5%)
       0800 01 IP ICMP      2,593      197,600  (  1.6%)
       809b    ATALK          203       15,000  (  0.1%)
       0800 58 IP IGRP        200       14,616  (  0.1%)
490 Paris
       0800 06 IP TCP      70,203   21,871,361  ( 76.3%)      1321 (  1.9%)
       8137    IPX         46,048    6,228,881  ( 21.7%)
       0800 11 IP UDP       2,051      498,644  (  1.7%)
       0800 01 IP ICMP        882       58,936  (  0.2%)
       0800 58 IP IGRP        205       14,886  (  0.1%)

Секунды максимальной загрузки линии доступа (Исходящие из Филадельфии данные)
      Time          Bytes        kbps
    11:08:11      125,513      1,004.1
    11:08:09      118,855        950.8
    11:08:13      116,336        930.7
    11:02:53      108,926        871.4
    11:08:14      104,754        838.0

Секунды максимальной загрузки непрерывного виртуального канала (Исходящие из Филадельфии данные)
460 London
    11:02:53       77,873        623.0
    11:02:52       76,221        609.8
    11:02:54       47,667        381.3
    11:02:56       46,748        374.0
    11:00:07       44,487        355.9
490 Paris
    11:08:11      112,854        902.8
    11:08:13      105,761        846.1
    11:08:09       95,425        763.4
    11:08:14       92,765        742.1
    11:08:10       85,951        687.6

Секунды минимальной загрузки линии доступа (Исходящие из Филадельфии данные)
    11:12:53       11,366         90.9
    11:12:52       14,118        112.9
    11:12:54       15,371        123.0
    11:12:55       22,993        183.9
    11:11:48       23,544        188.4

Секунды минимальной загрузки непрерывного виртуального канала (Исходящие из Филадельфии данные)

460 London
    11:05:14        3,640         29.1
    11:04:55        3,859         30.9
    11:05:33        4,068         32.5
    11:07:48        4,118         32.9
    11:06:20        4,170         33.4

490 Paris
    11:12:53        3,460         27.7
    11:12:54        6,613         52.9
    11:12:52        8,187         65.5
    11:13:18       14,021        112.2
    11:12:55       14,065        112.5

Top Sources (Out-Bound from Philadelphia)
                                    Bytes  % of Total
   1 TCP 155.94.114.164  1867    4,673,580  11.0   Philadelphia GroupWise
   2 TCP 10.2.71.201     1494    2,644,817   6.2
   3 TCP 155.94.155.23   1521    1,671,696   3.9   ra01u04 - Philadelphia DCG
   4 TCP 192.233.80.5    80      1,272,224   3.0
   5 TCP 209.58.93.100   1494      931,341   2.2   MARTE WinFrame 1

Главные получатели данных (Исходящие из Филадельфии данные)
                                    Bytes  % of Total
   1 TCP 10.248.107.217  7100    4,742,966  11.2
   2 TCP 10.247.113.201  4498    1,272,224   3.0
   3 IPX 0451 01000105 1         1,138,074   2.7   NCP
   4 TCP 10.248.89.1     7100      952,921   2.2
   5 TCP 10.247.66.76    1073      931,341   2.2

Суммарный отчет по интенсивности использования приложений (Все PVC, исходящие из Филадельфии данные)
                              New TCP    Total TCP
 Application                 Sessions     Sessions      Packets        Bytes
 Internet TCP                   4,684        4,817       41,455    13,128,752
 IPX                                                     90,631     9,785,697
 Unknown TCP                    1,016        1,167       41,305     7,141,942
 GroupWise TCP                     98          138       12,106     6,722,084
 DCG TCP                          138          150        7,370     1,824,223
 MARTE WinFrame TCP                 2            5        4,428     1,041,713
 IP Protocol  0b NVP-II                                   3,894       839,902
 EDMS TCP                          13           20        3,075       775,923
 MARTE Oracle TCP                   1            3        1,882       472,541
 MLIMS TCP                         38           22          850       255,473
 Internet ICMP                                            3,255       214,690
 Unknown ICMP                                               780        78,666
 ProbMan TCP                        0            4          181        48,826
 IP Protocol 3a IPv6-ICMP                                   598        43,012
 Unknown ATALK                                              203        15,000
 ASTROS TCP                         2            6           62         9,963

TCP SYNs (connection requests): 5996         Total TCP Re-Transmissions: 1662

Отчет состоит из пяти главных секций. Первая секция - краткая информация о PVC, показывает DLCI (номер канала), номера пакетов и байтов, процентное содержание байтов на канал по отношению ко всем каналам в линии доступа, счетчики сообщений о переполнении, счетчики битов DE и счетчики TCP ретрансляций. Поскольку роутер не устанавливает никакой информации о переполнении (это в дальнейшем делает Frame Relay) или битах DE, все счетчики нулевые для исходящего направления. Некоторые наши маршрутизаторы делают установку DE для интернет трафика, чтобы дать ему пониженный приоритет (установка DE говорит о том, что трафик может быть "брошен", если произойдет переполнение сети, взамен соединение не считает некоторые пакеты в указанных предедах). Счетчики TCP ретрансляций разделены для пакетов с битами DE и без них, так что мы можем определить как влияет установленный бит DE на потерю пакетов в сети Frame Relay.

Счетчики протоколов 2-го и 3-го уровней собраны во второй секции. Для каждого протокола наблюдался тип поля Ethernet/802.2, тип IP по номеру (если протокол IP), имя протокола, число пакетов и байтов, и процент использования для PVC. Для TCP/IP показан счетчик ретрансляций пакетов.

В третьей секции мы показали в какую секунду была наибольшая и наименьшая нагрузка для всей линии доступа и для каждого виртуального канала в отдельности. Генерация и использование этих данных объяснены далее в части "Переполнение и планирование емкости канала".

В четвертой секции показан топ-лист источников и приемников данных. В нем показаны протокол, IP адрес, номер порта, число байтов и процент использования от всего трафика на линии доступа. Если известно имя сервера, то оно так же показано, вместе с кратким описанием приложения.

Пятая секция отчета - список, показывающий использование линии доступа приложениями. Где возможно, мы идентифицировали приложения IP адресом сервера. Хотя имеет смысл в дальнейшем определять приложение номером порта, многие наши серверы запущены как одно приложение. Фактически, часто мы имеем два сервера запускающих одно и то же приложение, в этом случае пакеты с IP адресами и того и другого сервера будут отнесены на счет этого приложения. Серверы баз данных часто запускают несколько приложений с одной и той же парой значений IP-адрес/порт, так что добавление номера порта все же не будет однозначно определять приложение. В будущем мы надеемся поощрять использование назначения виртуального адреса приложению, это обеспечит более простую процедуру подсчета. "New TCP Sessions" показывает, как много новых TCP сессий было инициировано за пятнадцатитиминутный период, а "Total TCP Sessions" считает как новые так и продолжающиеся сессии.

Два последних пункта в отчете это счетчик инициаций TCP SYNC, который может быть использован для обнаружения вторжений из вне, и счетчик TCP ретрансляций для всех непрерывных виртуальных каналов.

Рисунок 3 показывает начало отчета для входящего направления. Учтите, что мы имеем различную информацию о FECN, BECN и DE связанную с пакетами приходящими с этого направления. Биты FECN и BECN предоставляют информацию об уровне перегрузки на транспортах сети Frame Relay. Оставшаяся часть отчета содержит ту же самую информацию, как и на рисунке 2.

Входящие в Филадельфию данные
Время сбора информации: Четверг Февраль 10 11:00:00 2000 - Четверг Февраль 10 11:15:01 2000 GMT
Суммарный отчет PVC (Входящие в Филадельфию данные)

DLCI  Packets      Bytes    %    FECNs         BECNs          DEs DE No DE
 460  62,915   6,453,502  36.9 %  515  0.8 %     31  0.0 % 2,211   6  111 London
 490 109,900  11,024,584  63.1 %   39  0.0 % 11,800 10.7 %     0   0  656 Paris
 All 172,815  17,478,086

Доступно несколько настраиваемых отчетов, использующих итоговые данные, собранные за 15 минут. Через Web форму можно выбрать информацию только об одном приложении и сформировать "Итоговые данные по приложению". Это бывает очень полезно для определения пропускной способности, необходимой для работы приложения и числа пользователей этого приложения. Так, нам часто говорят: ``400 пользователей будут из Европы работать с приложением размещенном в Филадельфии'', мы можем использовать инструментарий, чтобы судить, как много пользователей подключено одновременно и отслеживать рост интенсивности использования. Другая программа, суммируя данные за заданное время, будет генерировать ежедневный или ежемесячный отчет "Итоговая информация о приложении".

Данные вышеупомянутого примера приведены для одной из наших наиболее занятых линий, но данный пример далеко не самый сложный из тех, с которыми мы сталкиваемся. Один Европейский Frame Relay хаб имеет 13 постоянных виртуальных каналов на одной линии доступа. Часть трафика - критически важный для бизнеса телнет трафик между подчиненными подразделениями и AS/400 на хабе. Однако большая часть трафика - интранет почта или данные интернет, которые приходят по одному PVC и потом направляются в другой PVC в направлении США. Без мониторинга сети Frame Relay было бы очень трудно определить, какое приложение или какие протоколы нагружают PVC и полосу пропускания линии доступа. В некоторых случаях бывает необходимо добыть итоговую информацию о приложении для одного PVC, чтобы определить что происходит на определенном канале. Мы не делаем отчета по использованию для каждого канала, чтобы оставить размер и полноту отчета в разумных пределах.

Переполнение и планирование емкости канала

Наш монитор стремится измерить самые большие пики нагрузки в пятнадцати-минутном периоде, cуммируя число байтов для каждого односекундного интервала. Итоговая программа сообщает о десяти самых занятых секундах для каждой линии доступа и каждого канала. На рисунке 4 красным цветом показаны наиболее нагруженные десятисекундные интервалы. Промежутки времени, характеризующиеся большим разбросом значений (дисперсией), привлекательны с той точки зрения, что они демонстрируют большую дисперсию в пиковые по интенсивности загрузки 10 секунд, и, соответственно, вероятность того, что в 15-минутный интервал, наблюдались те самые 10 секунд максимальной загрузки канала - существенно снижается. Отсутствие пиковой секундной нагрузки ниже полной скорости канала T-1 (1536 кбит/с), начиная с 12:45 GMT показывает существенную длительную перегрузку. Имеются несколько секунд c нагрузкой выше строки 1536 кбит/с, вероятно, из-за пакетов, продержанных в буферах. Мы надеемся снизить задержки, вызванные перерывами в обслуживании, располагая по приоритетам процесс сбора данных. Секунды c низким трафиком тоже указывают на проблему. Если обычно занятый канал имеет секунды с нулевой или низкой нагрузкой, то это может указывать проблему в маршрутизаторе или канале. 

Figure 4 : График для линии доступа T-1 с 11 PVC. Синим цветом показаны данные о средней за 5 минут нагрузке, полученные из запросов SNMP. Красным цветом показаны десятисекундные интервалы с наибольшей нагрузкой в течение 15 минутных периодов. Тогда как измерение средней за 5 минут нагрузки - широко доступный стандартный метод, он скрывает пики нагрузки которые можно исследовать при посекундном измерении трафика.

У нас была одна проблема, когда в течение дня имелось большое количество секунд с низкой нагрузкой. Поскольку имелись так же и жалобы пользователей, был проведен детальный анализ данных в сетевых пакетах. Он показал, что весь IP трафик периодически останавливался примерно на 8 секунд, тогда как IPX трафик проходил нормально. Корни случившегося мы нашли в проблеме IP маршрутизации. Без IPX трафика проблему было бы просто заметить, поскольку на обычно занятом канале были бы периоды приблизительно по восемь секунд с нулевым трафиком.

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

Figure 5: Посекундный трафик на линии доступа (красный) и 11 постоянных виртуальных каналов Frame Relay за 15 минут. В центре графика линия доступа полностью заполнена в течение 25 секунд.

Использование данных о "сырых" пакетах

У нас есть программа для анализа трассировки пакетов, первоначально написанная для файлов формата tcpdump, которая может дополнительно читать уже упомянутый файл с информацией о заголовках пакетов Frame Relay и cоставлять список DLCI (ID канала), FECN, BECN, и DE битов для каждого пакета. Используя эту особенность, мы обнаружили, что некоторые приложения работали по асимметричным маршрутам. В дополнение к нашим собственным программам анализа, файл формата tcpdump может быть исследован, другими программами: как непосредственно tcpdump, так и ethereal [Ether00]. Поскольку ethereal в паре с editcap, может экспортировать данные в другие форматы, они могут быть проанализированы популярными коммерческими продуктами. Когда сеанс обработки должен проводиться через время кратное пятнадцати-минутным интервалам, мы используем простую программу, чтобы cоединить несколько tcpdump файлов.

В предыдущеq статье [Meek98] мы обсуждали интересные проблемы, которые у нас возникли с нашими продавцами услуг передачи данных. Наши жалобы на медленный канал иногда могли вызвать ответ похожий на: "Заказчик превышает CIR на 160%", что значило, что использование канала с превышенной согласованной скоростью передачи продолжилось чрезмерно долго. Имея информацию о пакетах, можно вычислить использование пропускной способности посекундно и использовать тот же самый алгоритм как в оборудовании передачи данных, чтобы проверить, когда и на сколько, CIR был превышен. Рисунок 6 показывает посекундное использование пропускной способности канала в течение тридцати-минутного периода и процент от входящих пакетов с установленным битом BECN, чтобы указать перегрузку на исходящем канале. BECNS посланы транспортными переключателями, чтобы указать, что в нашем исходящем направлении есть перегрузка и что наше использование пропускной способности будет регулироваться, если мы превышаем CIR и находимся вне данных нам возможностей канала. В будущем мы надеемся использовать эти данные, чтобы точно определить, когда мы в самом деле превышаем нашу оговоренную пропускную способность и как мы могли бы реализовать качество обслуживания, распределив трафик по приоритетам и управляя превышениями пропускной способности. 

Figure 6: Мгновенное значение используемой пропускной способности (в масштабе 1 сек.) и управляющая информация сети Frame Relay о переполнении (процент входящих пакетов с установленным битом BECN).

Потеря пакета - важный параметр в любой сети передачи данных. Один из показателей, по которому можно судить о потерянных пакетах - процентное содержание пакетов TCP, которые должны ретранслироваться. Рисунок 7 иллюстрирует количество повторно переданных пакетов TCP на одном из наших каналов за несколько месяцев. Часы с меньшим чем 10,000 количеством TCP пакетов не показываются. Так как этот канал питает множество каналов Frame Relay, и много сегментов LAN, потеря пакета могла происходить в нескольких местах. В конца июля у нас были проблемы с интерфейсом T-1, который вызвал существенную часть повторных передач в течение того периода. Дальнейший анализ необработанных пакетных данных может определить какие IP адреса назначения вызывали повторные передачи. Недавно мы прибавили новый раздел к стандартному отчету (Рисунок 2) который перечисляет первую десятку адресатов ретранслируемых пакетов, чтобы идентифицировать хосты или подсети с проблемами. Ретранслируемые пакеты подсчитаны последовательным суммированием количества пакетов за TCP-сеанс (при этом не считались чисто формальные пакеты, не несущие достаточного объема данных). 

Figure 7: Процентное содержание TCP пакетов, требующих ретрансляции за каждый час.

Профилирование приложения

Одно преимущество использования системы перехвата пакетов в WAN состоит в том, что тестируемое приложение может быть исследовано в реальных условиях, когда в сети по каналу идут данные других приложений. Так как мы обычно фиксируем весь трафик на проверяемых каналах, никакой специальной подготовки не требуется для большинства тестов профилируемых приложений. Мы нашли, однако, что при испытании интерактивного приложения полезно во время тестирования делать паузы от 15 до 30 секунд, когда пользователь не трогает аппаратуру. Паузы используются, чтобы разделить фазы приложения и определить, "разговаривают" ли клиент и сервер во время простоя.

Недостатком используемой системы перехвата пакетов WAN для этих тестов является то, что мы захватываем только 150 байтов заголовка информации. В то время как это небольшое число байтов полезной нагрузки часто достаточно, чтобы определить контекст приложения (особенно, когда включены данные ASCII или EBCDIC), этого может быть недостаточно, чтобы достаточно уверенно решить, что в пределах сеанса передается множество пакетов с идентичным содержанием (определяется, вычисляя MD5 контрольные суммы полезного содержания пакета [Meek98]).

Результат профилирования двух приложений в форме графиков приведен на 8 и 9. Профилируемое приложение на Рисунке 8 - широко используемая система ERP (Управление ресурсами Предприятия), которая использует странично-ориентированные терминалы как интерфейс пользователя. Пользователь взаимодействует с системой, заполняя текстовые формы и затем передавая экранную страницу на сервер. Этот метод, подобный современным приложениям Web, является эффективным способом осуществить интерактивные приложения на WAN поскольку за один раз передается порция данных разумного размера, по сравнению с передачей нажатий клавиш. 

Figure 8: Данные об IP пакетах для одной сессии, извлеченные из серии файлов, перехваченных пакетов сети Frame Relay.

Чтобы определить какую часть пропускной способности канала потребляет отдельный пользователь, мы рассматриваем количество пакетов для индивидуальных сеансов как функцию от времени. Верхний график показывает распределение размеров пакета для каждого направления, в то время как нижний график показывает пропускную способность, используемую в секунду. Детальное рассмотрение показывает, что 143,473 байта в 400 пакетах были посланы от клиента серверу, и 112,560 байтов в 348 пакетах были посланы от сервера к клиенту. Внимательно проверяя данные, используя для анализа интерактивный инструмент [Grace00] мы находим, что типичная транзакция заканчивается за одну или две секунды. Максимальная используемая пропускная способность была 43kbps от клиента на сервер и 22kbps в другом направлении.

Данные для этого анализа были извлечены из сырых пакетов собранных за 30 минут с линии доступа Frame Relay с 13-ю постоянными виртуальными каналами. Первым шагом было скомбинировать входящие и исходящие потоки пакетов в один файл формата tcpdump. Затем tcpdump файлы для двух 15-минутных периодов времени, требуемых, чтобы охватить сеанс были соединены. Наконец, объединенный файл был обработан с tcpdump, действующим как пре-фильтр, чтобы выбрать сеанс, представляющий интерес, и передать это на наше собственное программное обеспечение, которое подвело итог сеанса и подготовило данные о пропускной способности для составления графика.

На рисунке рисунке 9 -результат профилирования "тонкого клиента". Фактически, приложение выполняется на сервере и отображается на клиенте, очень похоже на X Windows, но с использованием более эффективного протокола. Трафик между клиентом и сервером состоит из передачи данных от клавиатуры и от мыши, регенерации изображения, и, в некоторых случаях, передачи файла. В этом примере передача файла была начата в сессии примерно на 2100 секунде. 

Figure 9: Данные об IP пакетах для одной сессии, извлеченные из серии файлов перехваченных пакетов сети Frame Relay.

Инструменты, представленные здесь, полностью выполняют работу по определению количества фактической пропускной способности, используемой приложением в масштабе времени за 1-2 секунды и показывают основные отличия требований к пропускной способности для различных типов приложений (критерий "burstiness", используется ли пропускная способность равномерно между двумя направлениями или нет). Инструментальные средства, однако, не могут использоваться для имитации масштабируемости приложения. Возможно, наши данные могли использоваться как ввод для модели сети, чтобы выполнить моделирование масштабирования в направлении увеличения пользователей. Наши инструментальные средства могут, однако, выбирать любой срез фактического записанного сетевого трафика, выбранного по источнику, адресату, номере порта, и т.д. и определять полное использование пропускной способности для приложений, затронутых в этом срезе. Кроме того, важно рассмотреть воздейстие латентности сети на приложении. [Meek98]

Чтобы определять, как изменяется использование приложений во времени мы можем рассмотреть некий параметр, представляющий использование. На Рисунке 10 мы показываем число сеансов в неделю для одного приложения. Использование этого специфического приложения изменяется в зависимости от деловых циклов и расписания праздников. Другие параметры используемые как мера использования приложения - это количество переданных байтов или пакетов. Подсчет байтов или пакетов особенно полезен для Web приложений, или других, не сеансовых приложений. 

Figure 10: Примерный график использования одного приложения. Получен подсчетом числа сессий в неделю.

Расширение к каналам точка-точка типа T-1

Связанные методы

Работа на будущее

Некоторые из параметров, измеренных системой, будут, вероятно, использоваться, чтобы генерировать сигнал тревоги, когда они превышают некоторые пороговые значения. Количество ретрансляций TCP и количество "тихих" / занятых секунд - вероятные кандидаты. Frame Relay предоставляет информацию о каналах, используя пакеты LMI (Local Managment Interface) - локального интерфейса управления. В настоящее время мы не декодируем их, но планируем добавить такую возможность в будущем.

Мы хотели бы измерить эффективность QoS (Qualiti-of-Service) схемы измерением времени задержки для пакетов с различным классом обслуживания, проходящих через маршрутизатор. Это было бы, вероятно, сделано, используя tcpdump на стороне Ethernet и сбором пакетов на стороне маршрутизатора, подключенной к WAN. Гистограммы задержек пакетов в течение периодов использования должны показать, что более высокоприоритетеный трафик проходит быстрее чем менее приоритетный. Результаты могли бы использоваться, чтобы настроить параметры QoS.

Заключение

Дополнительная информация

Благодарности

Ссылки

[Blac95] Uyless Black, Frame Relay Networks: Specifications and Implementations, McGraw-Hill 1995.

[Cisc00] Cisco Systems, WAN Group, private communication.

[Ether00] Ethereal, A network protocol analyzer, http://ethereal.zing.org/, 2000.

[Grace00] ``Grace, a WYSIWYG 2D plotting tool for the X Window System and M*tif'', http://plasma-gate.weizmann.ac.il/Grace/, 2000.

[McCa97] Steve McCanne, Craig Leres, Van Jacobson, ``TCPDUMP 3.4'', Lawrence Berkeley National Laboratory Network Research Group, 1997.

[Meek98] Jon T. Meek, Edwin S. Eichert, Kim Takayama, ``Wide Area Network Ecology,'' Proceedings of the Twelfth Systems Administration Conference (LISA '98), USENIX, Boston, 1998.

[Ranu97] Marcus J. Ranum, Kent Landfield, Mike Stolarchuk, Mark Sienkiewicz, Andrew Lambeth, and Eric Wall. ``Implementing a Generalized Tool for Network Monitoring,'' 11th Systems Administration Conference (LISA), 1997. 

``Originally published by the USENIX Association in the Proceedings of the 14th Systems Administration Conference (LISA 2000), December 3-8, 2000.'' (www.usenix.org/events/) This article is modified from the original.