Канал связи с изменяющимися состояниями
Как было указано выше, канал характеризуется условными распределениями З2, задающими вероятности тех или иных искажений посылаемого сигнала х1. Несколько изменим схему канала связи, считая, что имеется некоторое множество Z возможных состояний z канала связи, причем если канал находится в некотором состоянии z и на входе возникает сигнал x1, то независимо от других предшествующих обстоятельств канал переходит в другое состояние z1. Этот переход подвержен случайностям и описывается условными распределениями P(C|x1, z) (P(C|x1, z) - вероятность того, что новое состояние z1 будет входить в множество C М Z). При этом уже считается, что выходной сигнал х2 однозначно определяется состоянием канала z1, т.е. существует некоторая функция j = j (z) на пространстве z возможных состояний канала такая, что х2= j (z1). Эта более общая схема позволяет учитывать те изменения, которые в принципе могут возникать в канале по мере его работы.
Рассмотрим стационарный режим работы канала связи. Предположим, что последовательно передаваемые сигналы
…., x 1(-1), x 1(0), x 1(1),…, соответствующие состояниям канала …, z (-1), z (0), z (1),…, и определяемые ими сигналы
…, x 2(-1), x 2(0), x 2(1),…, на выходе образуют стационарные и стационарно связанные случайные последовательности. Величина С=supI(x 1,x 2), где I(x 1,x 2), означает скорость передачи информации о стационарной последовательности {x1(n)} последовательностью {x 2(n)} и верхняя грань берется по всем допустимым распределениям вероятностей входной последовательности {x1(n)}, называется пропускной способностью канала связи.
Предположим, что поступающие на вход канала связи сообщения {x 0(n)}, n =…, -1, 0, 1 ,…, образуют случайную последовательность. Будем считать правило кодирования заданным, если при всех k, m и k1,…, km і k определены условные вероятности
P{x 1(k1) О B1,…, x 1 (km)О Bm|x 0(-Ґ ,k)}
Того, что при поступлении последовательности сообщений
x 0(-Ґ ,k) = …, x 0(k-1), x 0(k)
на соответствующих местах будут переданы сигналы x 1(k1),…, x 1(km), входящие в указанные множества B1, …, Bm.
Эти вероятности считаются стационарными в том смысле, что они не меняются при одновременной замене индексов k и k1,…,km на k+l и k1+l,…,km+l при любом целом l. Аналогичными вероятностями p{ x 3(k1) О D1,…, x 3(km) О Dm|x 2(-Ґ ,k)} задается правило декодирования.
Определим величину H формулой H = inf I( x 0,x 3), где I(x 0, x 3) - скорость передачи информации о стационарной последовательности {x0(n)} последовательностью {x3(n)}, n = …, -1, 0, 1,… (эти последовательности предполагаются стационарно связанными), и нижняя грань берется по всем допустимым распределениям вероятностей, удовлетворяющим требованиям точности передачи {x0(n)} ® { x3(n)}.
Неравенство H Ј C является необходимым условием возможности передачи
{x 0(n)} ® {x 1(n)} ® {x 2(n)} ® {x 3(n)}.
Напомним, что каждое сообщение x0(n) представляет собой некоторый элемент х0 из совокупности Х0. Можно интерпретировать Х0 как некоторый алфавит, состоящий из символов х0. Предположим, что этот алфавит Х0 является конечным и требование точности передачи состоит в безошибочном воспроизведении передаваемых символов:
P{x 3(k) = x 3(k)} =1 для любого целого k.
Предположим также, что имеется лишь конечное число входных сигналов х1 и состояний канала z. Обозначим состояния канала целыми числами 1, 2, …, N, и пусть p(k, x1,j) - соответствующие вероятности перехода из состояния k в состояние j при входном сигнале x1:
p(k,x1,j) = P{z (x+1) = j|z (n)=k, x 1(n+1)=x1}.
Дополнительно предположим, что любые произведения вида
p(k0,x1(1),k1)p(k1,x1(2),k2)… p(kn-1,x1(n),kn)
являются стохастическими матрицами, задающими эргодические цепи Маркова. Это условие будет выполнено, если, например, каждая из переходных матриц {p(k,x1,j)} имеет положительный коэффициент эргодичности. Тогда при выполнении неравенства H<C и соблюдении условия эргодичности стационарной последовательности {x 0(n)} сообщений на входе передача возможна с точностью до любого e >0, т.е. при соответствующих способах кодирования и декодирования принимаемая последовательность сообщений {x 3(n)} будет обладать тем свойством, что p{x3(k) № x 0(k)} < e для любого целого k.
Пусть x 1 = {x (t), t О T1} и x 2= {x (t), t О T2} - два семейства случайных величин, имеющих совместное гауссово распределение вероятностей, и пусть H1 и H2 - замкнутые линейные оболочки величин x (t), t О T1, и x (t), t О T2, в гильбертовом пространстве L2 (W). Обозначим буквами P1 и P2 операторы проектирования на пространства H1 и H2 и положим P(1) = P1P2P1, P(2) = P2P1P2. Количество информации I(x1,x 2) о семействе величин x1, содержащееся в семействе x2, конечно тогда и только тогда, когда один из операторов P(1) или P(2) представляет собой ядерный оператор, т.е. последовательность l 1, l 2,… его собственных значений (все они неотрицательны) удовлетворяет условию
В случае, когда x 1 и x 2 образованы конечным числом гауссовых величин:
x1={x (1),…, x (m)}, x 2 = {x (m+1),…, x (m+n)}, причем корреляционная матрица B общей совокупности x (1),…, x (m+n) является невырожденной, количество информации I(x 1, x 2) может быть выражено следующей формулой:
где B1 и B2 - корреляционные матрицы соответствующих совокупностей x 1 и x 2.
Гауссовы распределения обладают следующим экстремальным свойством. Для произвольных распределений вероятностей величин
x 1 = {x (1), …, x (m)} и x 2 = {x (m+1), …, x (m+n)}
с соответствующими корреляционными матрицами B1, B2 и B количество информации I(x 1, x 2) удовлетворяет неравенству
Пусть x = (x 1,…,x n) и h = (h 1,…,hn) - векторные случайные величины в n-мерном евклидовом пространстве X и r(x,y) - некоторая неотрицательная функция, определяющая условие близости величин x и h, которое выражается следующим соотношением:
Mr(x ,h ) Ј e .
Величину H=He, определенную как He = inf I(x, h), обычно называют e-энтропией случайной величины x (нижняя грань берется по всем случайным величинам h, удовлетворяющим указанному условию e-близости случайной величине x).
Пусть r(x,y) = r(|x-y|) и существует производная r’(0), 0< r’(0)<Ґ. Тогда при e ® 0 имеет место асимптотическая формула, в которой логарифмы берутся по основанию e:
где g() - гамма функция и h(x) - дифференциальная энтропия случайной величины x:
(px(x) - плотность распределения вероятностей, удовлетворяющая весьма широким условиям, которые выполняются, например, если плотность px(x) ограничена и h(x ) > -Ґ ).
Пусть
Тогда
В частности, при a =2, b =1 имеет место асимптотическая формула
Пусть пара случайных процессов (x 1(t), x 2(t)) образует стационарный в узком смысле процесс, x [u,v] - совокупность значений x (t), u Ј t Ј v, и пусть
Фигурирующая здесь величина I(x1, x2) называется средней скоростью передачи информации стационарным процессом x2 о стационарном процессе x1 или просто - скоростью передачи информации.
Скорость передачи информации I(x1,x2) обладает рядом свойств, аналогичных свойствам количества информации. Но она имеет и специфические свойства. Так для всякого сингулярного случайного процесса x 2, т.е. такого процесса, все значения x 2(t) которого являются функциями от совокупности величин
Для всякого регулярного случайного процесса x 2 равенство I(x1,x2)=0 справедливо лишь тогда, когда случайный процесс x 1 не зависит от процесса x2 (это говорит о том, что в некоторых случаях I(x1,x2) № I(x 2,x 1) ).
При дополнительных условиях типа регулярности скорость передачи информации I(x 1,x 2) совпадает с пределом
где
0< c Ј l 2nf(l ) Ј c < Ґ
Пусть стационарный процесс x = x (t) представляет собой последовательность величин, каждая из которых принимает значения из некоторого алфавита x, состоящего из конечного числа символов x1, x2,…,xn. Предположим, что вероятность появления на фиксированном месте определенного символа xi есть pi, а вероятность появиться за ним символу xj не зависит от предшествующих xi значений и есть pij:
P{x (t) = xi} = pi, P{x(t+1) = xi xi|x(t) = xi, x(t-1),…, } = pij
Другими словами x = x (t) - стационарная цепь Маркова с переходными вероятностями {pij} и стационарным распределением {pi}. Тогда скорость передачи информации стационарным процессом x(t) будет
I(x,x) = -
В частности, если x = x(t) - последовательность независимых величин (в случае pij = pj), то
I(x,x) = -
Пусть x1 = x1(t) и x2 = x2(t) - стационарные гауссовы процессы со спектральными плотностями f11(l), f22(l) и взаимной спектральной плотностью f12(l) причем процесс x2 = x2(t) является регулярным. Тогда
I(x1, x2) = -
Рассмотрим следующее условие близости гауссовых стационарных процессов x1(t) и x2(t):
M|x1(t) - x2(t)|2 Јd2
Наименьшая скорость передачи информации
H = infI(x1,x2), совместимая с указанным условием “d-точности”, выражается следующей формулой:
а параметр q2 определяется из равенства
Эта формула показывает, какого типа спектральная плотность f22(l) должна быть у регулярного стационарного процесса x 2(t), который несет минимальную информацию I (x1,x 2) » H о процессе x1(t). В случае дискретного времени, когда f11(l ) і q 2 при всех l , -p Ј l Ј p, нижняя грань H скорости передачи достигается для такого процесса x 2 (t) (со спектральной плотностью f22(l), задаваемой приведенной выше формулой), который связан с процессом x 1(t) формулой
x 2(t) = x 1(t) + z(t), где z(t) - стационарный гауссов шум, не зависящий от процесса x 2(t); в общем случае формула f22(l) задает предельный вид соответствующей спектральной плотности регулярного процесса x 2(t).
В случае, когда спектральная плотность f11(l) приближенно выражается формулой
соответствующая минимальная скорость передачи информации H может быть вычислена по приближенной формуле
2.10.3. Симметричный канал без памяти
Рассмотрим симметричный канал передачи данных без памяти c конечным числом входных сигналов х1, когда передаваемый сигнал х1 с вероятностью 1-p правильно принимается на выходе канала связи, а с вероятностью p искажается, причем все возможные искажения равновероятны: вероятность того, что на выходе будет сигнал х2, равна
c = supI( x1,x2) достигается в случае, когда на вход поступает последовательность независимых и равномерно распределенных сигналов …, x 1(-1), x 1(0), x 1(1),…; эта пропускная способность выражается формулой
Рассмотрим канал связи, на входе которого сигналы образуют стационарный процесс x 1 = x1(t), M[x 1(t)]2 < Ґ.
Пусть при прохождении сигнала x 1 = x 1(t) он подвергается линейному преобразованию Aj со спектральной характеристикой j (l) и, кроме того, на него накладывается аддитивный стационарный гауссов шум z =z (t), так что на выходе канала имеется случайный процесс x 2(t) вида x 2(t) = aj x 1(t) + z (t).
Предположим также, что ограничения на входной процесс состоит в том, что M[x 1(t)]2 Ј D 2 (постоянная D2 ограничивает среднюю энергию входного сигнала). Пропускная способность такого канала может быть вычислена по формуле
(в последнем выражении интегрирование ведется в пределах -p Ј l Ј p для дискретного времени t и в пределах -Ґ <l <Ґ для непрерывного t), где fz z (l) - спектральная плотность гауссова процесса z (t), функция f(l) имеет вид
а параметр q2 определяется из равенства
Нужно сказать, что если функция f(l) представляет собой спектральную плотность регулярного стационарного гауссова процесса x 1(t), то этот процесс, рассматриваемый как входной сигнал, обеспечивает максимальную скорость передачи информации: I(x 1,x 2) = C. Однако в наиболее интересных случаях, когда время t меняется непрерывно, функция f(l) обращается в нуль на тех интервалах частот l, где уровень шума сравнительно высок (отличные от нуля значения f(l) сосредоточены в основном на тех интервалах частот l, где уровень шума сравнительно мал), и поэтому не может служить спектральной плотностью регулярного процесса.
Более того, если в качестве входного сигнала выбрать процесс x 1(t) с спектральной плотностью f(l), то этот сигнал будет сингулярным и соответствующая скорость передачи информации I(x 1,x2) будет равна нулю, а не максимально возможному значению C, указанному выше.
Тем не менее, приведенные выражения полезны, так как позволяют приблизительно представить вид спектральной плотности f(l) регулярного входного сигнала x 1(t), обеспечивающей скорость передачи I(x1, x2), близкую к максимальному значению C. С практической точки зрения наиболее интересен случай, когда канал связи имеет ограниченную полосу w пропускаемых частот, т.е. когда спектральная характеристика выражается формулой
а проходящий через канал шум имеет равномерный спектр:
В этом случае пропускная способность может быть вычислена по приближенной формуле
При этом входной сигнал x1(t), обеспечивающий скорость передачи информации I(x1, x2), близкую к максимальной, является гауссовым стационарным процессом со спектральной плотностью f(l) вида
так что параметры D2 и s2 имеют следующий физический смысл:
Преобразование, кодировка и передача информации
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Для передачи информации на большие расстояния в настоящее время используются исключительно электромагнитные волны (акустические волны пригодны лишь для ограниченных расстояний). При этом пересылка может осуществляться по медным проводам, оптоволоконному кабелю или непосредственно, по схеме передатчик-приемник. В последнем случае используются антенны. Для того чтобы антенна была эффективна, ее размеры должны быть сравнимы с длиной передаваемой волны. Чем шире динамический диапазон передаваемых частот, тем труднее сделать антенну, пригодную для решения этой задачи. Именно по этой причине для передачи используются частоты, начиная с многих сотен килогерц и выше (длина волн сотни метров и меньше). Передача сигнала непосредственно по лучу лазера ограничена расстояниями 100-3000м и становится неустойчивой при наличии осадков даже для инфракрасных длин волн. Между тем человек воспринимает акустические колебания в диапазоне 20-12000 Гц и для целей пересылки звука (например, телефония) требуется именно этот диапазон частот. Динамический диапазон частот в этом случае равен 600, а для высококачественного воспроизведения звука он в два раза шире. При решении этой проблемы используется преобразование частот и различные методы модуляции. Так тот же частотный диапазон, лежащий в пределах (100 - 100,012) Мгц, соответствует динамическому диапазону 0,012%, что позволяет сделать компактную антенну и упростить частотное выделение сигнала.
Для преобразования частот используется перемножение сигналов. Пусть мы имеем два синусоидальных сигнала: A1*sin(w1 t) и A2*sin( w2t). Из тригонометрии известно, что:
A1*sin( w1t)*A2*sin( w2 t)=1/2*A1*A2*[sin( w1+w2)t + sin( w1-w2)t]. [1.1]
Это означает, что в результате перемножения вместо двух частот f1=w1/2p и f2= w2/2p мы имеем две новые частоты (w1+w2)/2p и (w1-w2)/2p с амплитудой 1/2*A1*A2. Если входной сигнал имеет полосу 0 - fм, то после перемножения с сигналом, имеющим частоту fн (несущая частота), получим сигнал с полосой в интервале от (fн - fм) до (fн+ fм).
Это преобразование проиллюстрировано на рис. 2.1. (по вертикальной оси отложена спектральная плотность сигнала f(jw )). На практике это преобразование выполняется с помощью смесителей или гетеродинов, частота fн называется сигналом гетеродина или несущей.
Рис. 2.1. Частотное преобразование
Получение исходного сигнала из преобразованного достигается путем обратного преобразования, которое сводится к умножению полученного сигнала на sin(wнt), где wн = 2 p*fн. При таком обратном преобразовании мы получим сигнал с исходным частотным диапазоном. Помимо этого будет получен сигнал с полосой от (2fн - fм) до (2fн+ fм). Так как fн обычно много больше fм, серьезных проблем это не вызывает - достаточно воспользоваться соответствующим фильтром. Этому методу обратного преобразования присущи некоторые недостатки. Если сигнал fн имеет фазовый сдвиг q по отношению к тому, что имел сигнал, использованный при прямом преобразовании, то амплитуда выходного сигнала будет пропорциональна cosq. Понятно, что при вариации фазы амплитуда будет меняться, а при q=p/2 станет нулевой. По этой причине должны быть предприняты специальные меры для синхронизации этих сигналов (fн. передатчика и fн приемника).
Соотношение [1.1] используется при реализации амплитудной, частотной или фазовой модуляции. Так в случае амплитудной модуляции при временной вариации A1 (=Авх) будет изменяться и амплитуда выходного сигнала (А2=Aн - амплитуда несущей частоты при этом остается постоянной; w1=w н при этом может также варьироваться). Форма сигнала на выходе такого преобразователя имеет вид: Авых = Ан[1+Авх(t)] sin wнt. Для получения формы исходного сигнала на принимающей стороне используется схема детектора (например, диодного), на выходе которого получается сигнал, пропорциональный модулю огибающей функции входного сигнала. Существуют и другие методы демодуляции амплитудно-модулированного сигнала. Главным недостатком метода амплитудной модуляции является возможность нелинейных искажений из-за перемодуляции (когда амплитуда модулирующего сигнала слишком велика).
При частотной и фазовой модуляции амплитуда передаваемого сигнала остается почти постоянной, что исключает нелинейные искажения, связанные с широким динамическим амплитудным диапазоном. Выходной сигнал для этого вида модуляции имеет вид: Авых = Ан sin[wнt + q(t)], где q(t) зависит от формы преобразуемого входного сигнала. Часто используется комбинация амплитудной и фазовой модуляции, которая носит название квадратурной модуляции.
Системы передачи данных с амплитудной или частотной модуляцией являются аналоговыми системами и по этой причине весьма чувствительны к шумам на входе приемника. Применение цифровых методов пересылки информации увеличивает вероятность корректной доставки. Если для аналоговой передачи требуется отношение сигнал/шум на уровне 40-60 дБ, то при цифровой передаче достаточно 10-12 дБ. Выбор типа модуляции зависит от стоящей задачи и от характеристик канала (полосы пропускания, ослабления сигнала и т.д.). Частотная модуляция менее чувствительна к амплитудным флуктуациям сигнала. Ослабление сигнала может варьироваться во времени из-за изменений в транспортной среде, это довольно типично для коммутируемых телефонных сетей. В сетях, использующих выделенные каналы, это также возможно благодаря применению динамических протоколов маршрутизации, когда длина пути может изменяться в пределах одного сеанса связи. В любом случае на передающей стороне необходим модулятор, а на принимающей демодулятор. Так как обмен обычно двунаправлен, эти устройства объединяются в одном приборе, который называется модемом (см. также раздел “4.3.7. ").
В модемах применимы несколько видов модуляции:
| FSK | (Frequency Shift Keying) - ступенчатое переключение частоты синусоидального сигнала от f1 к f2 при неизменной амплитуде, частоте f1 ставится в соответствие логический нуль, а f2 - логическая единица. |
| BPSK | (Binary Phase-Shift Keying) - скачкообразное переключение фазы синусоидального сигнала на p при неизменной амплитуде, при этом фазе 0 ставится в соответствие логический нуль, а p- логическая единица. |
| DPSK | (Differential Phase Shift Keying) - метод, при котором изменяется фаза несущей частоты при постоянной амплитуде и частоте. Разновидность PSK, при которой кодируется лишь изменение сигнала. |
| QAM | (Quadrature Amplitude Modulation) - комбинация амплитудной и фазовой модуляции, позволяет осуществить кодирование 8 бит на бод. |
| QPSK | (Quadrature Phase-Shift Keying) - квадратурная фазовая модуляция. Использует 4 фиксированных значения фазы 0, p/2, p и 3p/2. Требует в два раза более узкую полосу, чем PSK, и по этой причине весьма популярна. |
TCM | (Trellis Coded Modulation) - метод предполагает использование избыточности, каждый бод несет дополнительный бит, который позволяет более точно восстановить информационную битовую последовательность. При кодировании сигнала используется метод QAM. Метод реализован в современных высокоскоростных модемах и позволяет снизить требования к отношению сигнал/шум на 4-5 дБ. |
Рис. 2.2. QAM-модуляция с 3 битами на бод (слева) и 4 битами на бод (справа)
Статистическая теория каналов связи
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Данная статья имеет целью познакомить с терминологией и математическими основами статистической теории передачи данных. Именно на этой математической основе зиждятся приведенные выше теоремы Шеннона и Найквиста. Статья является компиляцией из нескольких источников (Ю.В.Прохоров, Ю.А.Розанов "Теория вероятностей. Основные понятия, предельные теоремы, случайные процессы" Наука, М. 1967; Л.Ф. Куликовский, В.В.Мотов, "Теоретические основы информационных процессов", Высшая школа, 1987; Р. Галлагер "Теория информации и надежная связь" Советское радио, 1974 и др.). Материалы, предлагаемые здесь не могут считаться исчерпывающими и призваны быть поводом для более углубленного изучения по существующим монографиям.
Канал связи предназначен для транспортировки сообщений. Математическая модель канала связи описывается некоторой совокупностью Х1 элементов х1 (X1 = {x11, x12,, …x1j}), называемых сигналами на входе канала, совокупностью Х2 элементов х2 (x2 = {x21, x22,, …x2k}), называемых выходными сигналами, и условными распределениями вероятностей p2=p2(a2 |x1) в пространстве x2 выходных сигналов x2. Если посланный сигнал (сигнал на входе) есть х1, то с вероятностью P2=P2(A2|x1) на выходе канала будет принят сигнал х2 из некоторого множества A2 М Х2 (распределения задают вероятности того или иного искажения посланного сигнала х1). Совокупность всех возможных сообщений обозначим символом x0. Предполагается, что каждое из сообщений x0О X0 может поступать с определенной вероятностью. То есть, в пространстве X0 имеется определенное распределение вероятностей P0=P0(A0 ).
Сообщения х0 не могут быть переданы по каналу связи непосредственно, для их пересылки используются сигналы x1О X1. Кодирование сообщений х0 в сигналы х1 описывается при помощи условного распределения вероятностей P1=P1(A1 |x0). Если поступает сообщение х0, то с вероятностью P1=P1(A1|x0) будет послан один из сигналов х1, входящих в множество A1 М Х1 (условные распределения P1(A1|x0) учитывают возможные искажения при кодировании сообщений).
Аналогичным образом описывается декодирование принимаемых сигналов х2 в сообщения x3. Оно задается условным распределением вероятностей P3=P3(A3|x2) на пространстве Х3 сообщений х3, принимаемых на выходе канала связи.
На вход канала связи поступает случайное сообщение x0 с заданным распределением вероятностей P0=P0(A0). При его поступлении передается сигнал x1, распределение вероятностей которого задается правилом кодирования P1=P1(A1|x0):
P{x2 О A2|x0, x1} = P2(A2|x1)
Принятый сигнал x2 декодируется, в результате чего получается сообщение x3:
P{x3 О A3|x0, x1, x2} = P3(A3| x2)
Последовательность x0 ® x1 ® x 2 ® x3 является марковской. При любых правилах кодирования и декодирования описанного типа имеет место неравенство:
I(x0,x3) Ј I(x1, x2),
где I(x0, x3) - количество информации о x0 в принятом сообщении x3, I(x1, x2) - количество информации о x1 в принятом сигнале x2.
Предположим, что распределение вероятности входного сигнала x1 не может быть произвольным и ограничено определенными требованиями, например, оно должно принадлежать классу W. Величина C = sup I(( x1 , x2) , где верхняя грань берется по всем возможным распределениям P1 О W, называется емкостью канала и характеризует максимальное количество информации, которое может быть передано по данному каналу связи (теорема Шеннона).
Предположим далее, что передача сообщений x0 ® x3 должна удовлетворять определенным требованиям точности, например, совместное распределение вероятностей Px0 x1 передаваемого и принимаемого сообщений x0 и x3 должно принадлежать некоторому классу V. Величина H= inf I( x0 x3), где нижняя грань берется по всем возможным распределениям Px0 x3 О V, характеризует минимальное количество информации, которое должно заключать в себе принимаемое сообщение x3 о x0, чтобы было выполнено условие точности передачи. Величина H называется энтропией источника сообщений.
Если возможна передача x0 ® x1 ® x2 ® x3 с соблюдением требований V и W, то есть существуют соответствующие способы кодирования и декодирования (существуют условные распределения P1, P2 и P3), то H Ј С.
Для выполнения этого неравенства передача является возможной, т.е. возможна передача последовательно поступающих сообщений
Предположим, что совокупность Х0 всех возможных сообщений х0 является дискретной (имеется не более чем счетное число различных сообщений x0, поступающих с соответствующими вероятностями P0(x0), x0 О X0) и условие точности передачи v состоит в том, что принимаемое сообщение x3 должно просто совпадать с переданным сообщением x3 = x0 с вероятностью 1. Тогда
Предположим далее, что имеется лишь конечное число N различных входных сигналов х1 и нет никаких ограничений на вероятности P{ x1 = x1}, x1 О X1. Кроме того, предположим, что передаваемые сигналы принимаются без искажений, то есть с вероятностью 1 x2= x1. Тогда емкость канала выражается формулой C = log2N, т.е. передаваемое количество информации I(x1, x 2 ) будет максимальным в том случае, когда сигналы x1 О X1 равновероятны.
Если сообщения
Пусть H<C, положим также d=(1/2)(C-H). Согласно закону больших чисел, примененному к последовательности независимых и одинаково распределенных случайных величин
с математическим ожиданием
для любого e >0 найдется такое n(e), что при всех n і n(e )
P{-H-d Ј (1/n)logP( x 0n) Ј H+d } і 1-e, где
Полученное неравенство говорит о том, что все группы сообщений х0n можно разбить на два класса. К первому классу
Mn Ј 2n(H+d )
Ко второму классу
Каждую группу высоковероятных сообщений х0n можно в принципе передать, закодировав ее соответствующей комбинацией сигналов
При выполнении неравенства H < C оказывается возможной передача достаточно длинных сообщений
Количество информации I(x0, x3) для абстрактных случайных величин x0 и x3 со значениями в пространствах Х0 и Х3 может быть записано в виде:
I(x0, x 3) = Mi(x0, x3), где
- информационная плотность. Последовательность пар (x0n, x3n) называется информационно устойчивой, если при n ® Ґ
I(x0, x3) ® Ґ и
(по вероятности)
Рассмотренная выше последовательность (x0n, x3n), x3n= x0n поступающих сообщений x 0n =(
x1n® x 2n, Hn - минимальное количество информации, необходимое для соблюдения требуемой точности передачи x0n ® x 3n, причем
(при n ® Ґ ),
и существуют информационно устойчивые последовательности пар (x0n, x3n) и (x1n, x2n), для которых одновременно
то при весьма широких предположениях для любого наперед заданного e >0 существует такое n(e), что по всем каналам связи с параметром n і n(e) возможна передача с точностью до e.
Диагностика локальных сетей и Интернет
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Читатели неизбежно делятся на две категории:
а. Администраторы сети, которые формируют сетевую среду (подавляющее меньшинство).
б. Пользователи сети, кто вынужден эту среду осваивать и в ней жить.
Вторая категория, в силу своего численного превосходства, способна задать столько вопросов, на которые первая, даже будучи столь же многочисленной, не смогла бы ответить. Вопросы бывают простые, например:
"Почему не работает электронная почта?" (хотя известно, что вторые сутки за неуплату обесточен весь вычислительный центр). Бывают и сложные: "Как уменьшить задержку отклика, если канал перегружен?"
Число компьютерных сетей увеличивается лавинообразно, растет число больших (>10 ЭВМ) и многопротокольных сетей (Novell, DECnet, TCP/IP, AppleTalk и т.д.). По мере увеличения сети усложняется ее обслуживание и диагностика, с чем сталкивается администратор при первом же отказе. Наиболее сложно диагностировать многосегментные сети, где ЭВМ разбросаны по большому числу помещений, далеко отстоящих друг от друга. По этой причине сетевой администратор должен начинать изучать особенности своей сети уже на фазе ее формирования и готовить себя и сеть к будущему ремонту. При возникновении нештатной ситуации администратор должен суметь ответить на ряд вопросов:
связана проблема с оборудованием или программным обеспечением;
отказ вызван повреждением программы, неверным выбором конфигурации или ошибочными действиями оператора.
Начинать надо с исчерпывающего документирования аппаратной и программной части сети. Администратор всегда должен иметь под рукой схему сети, отвечающую реальному положению на текущий момент, и подробное описание конфигурации программного обеспечения с указанием всех параметров (физические и IP-адреса всех интерфейсов, маски, имена ЭВМ, маршрутизаторов, значения MTU, MSS, TTL и других системных переменных, типовые значения RTT и других параметров сети, измеренных в разных режимах.).
В пределах локальной сети поиск неисправности возможен с помощью временного деления ее на части.
По мере интеграции сети в Интернет такие простые меры становятся недостаточными или недопустимыми. Но не следует пренебрегать такими простыми средствами, как отсутствие обрыва или закоротки сетевого кабеля. Нужно помнить, что сопротивление сегмента толстого коаксиального кабеля не должно превышать 5 Ом, тонкого - 10 Ом, а скрученные пары не должны иметь сопротивление больше 11,8 Ом (22AWG) и соответственно 18,8 Ом (24AWG) из расчета на 100 м.
Следует помнить, что сетевая диагностика является основой сетевой безопасности. Только администратор, знающий все о том, что происходит в сети, может быть уверен в ее безопасности.
Ниже будет предполагаться, что сеть на физическом уровне использует стандарт Ethernet, а для межсетевой связи протокол TCP/IP (Интернет). Этим перечнем разнообразие сетевых сред не исчерпывается, но многие приемы и программные диагностические средства с успехом могут использоваться и в других случаях. Большинство из рассматриваемых программ работают в среде UNIX, но существуют их аналоги и для других ОС. Сложные (дорогостоящие, но весьма эффективные) аппаратно-программные диагностические комплексы здесь не рассматриваются. Проблемы маршрутизации и конфигурирования системы также выходят за рамки данного рассмотрения.
В Интернет имеется немало общедоступных специализированных диагностических программных продуктов: Etherfind, Tcpdump ( , для SUN или BSD 4.4; ftp.ee.lbl.gov.libpcap.tar.Z), netwatch (windom.ucar.edu), snmpman (http://www.smart.is/pub/mirror-indstate/snmp), netguard (oslo-nntp.eunet.no/pub/msdos/winsock/apps), ws_watch (bwl.bwl.th-harmstadt.de /windows/util). Программа tcpdump создана в университете Калифорнии и доступна по адресу ftp.ee.lbl.gov. Эта программа переводит интерфейс ЭВМ в режим приема всех пакетов, пересылаемых по данному сетевому сегменту. Такой режим доступен и для многих интерфейсов IBM/PC (например, популярный NE2000 Eagle, mode=6), но tcpdump на этих машинах не работает. Tcpdump написана на СИ, она отбирает и отображает на экране пакеты, посылаемые и получаемые данным интерфейсом.
Критерии отбора могут варьироваться, что позволяет проанализировать выполнение различных сетевых процедур. В качестве параметров при обращении к программе могут использоваться наименования протоколов, номера портов и т.д., например, tcpdump TCP port 25. Существует довольно большое число модификаторов программы (опций). К сожалению для рядовых пользователей программа не доступна - требуются системные привилегии. Описание применения программы можно найти по указанному выше адресу, а также в . Другой полезной служебной программой является sock (socket или sockio). Эта программа способна посылать TCP и UDP пакеты, она может работать в четырех режимах.
Программа устанавливает канал клиент-сервер и переадресует стандартный ввод серверу, а все полученные пакеты от сервера переправляет на стандартный вывод. Пользователь должен специфицировать имя сервера или его адрес и наименование операции или номер порта, ей соответствующий.
Работа в режиме диалогового сервера (опция -s). В этом режиме параметром операции является ее имя или номер порта (или комбинация IP-адреса и номера порта), например: sock -s 100. После установления связи с клиентом программа переадресовывает весь стандартный ввод клиенту, а все что посылается клиентом, отправляет на стандартный вывод.
Режим клиента-отправителя (опция -i). Программа выдает в сеть заданное число раз (по умолчанию 1024) содержимое буфера с объемом в 1024 байта. Опции -n и -w позволяют изменить число и размер посылок.
Режим приема и игнорирования данных из сети (опция -i и -s).
Такие средства входят также и в комплекты поставки большинства стандартных сетевых пакетов для ОС MS-DOS, UNIX, Windows NT, VMS и других: ping, tracetoute, netstat, arp, snmpi, dig (venera.isi.edu /pub), hosts, nslookup, ifconfig, ripquery. Перечисленные выше диагностические программы являются необходимым инструментом для отладки программ, передающих и принимающих пакеты. Сводный перечень конфигурационных и диагностических команд набора протоколов TCP/IP представлен в таблице 5.1.
Таблица 5.1.
| Название команды | Назначение |
| arp | Отображает или модифицирует таблицу протокола ARP (преобразование IP в MAC-адреса) |
| chnamsv | Служит для изменения конфигурации службы имен на ЭВМ (для TCP/IP) |
| chprtsv | Изменяет конфигурацию службы печати на ЭВМ-клиенте или сервере |
| gettable | Получает таблицы ЭВМ в формате NIC |
| hostent | Непосредственно манипулирует записями адресного соответствия ЭВМ в конфигурационной базе данных системы |
| hostid | Устанавливает или отображает идентификатор данной ЭВМ |
| hostname | Устанавливает или отображает имя данной ЭВМ |
| htable | Преобразует файлы ЭВМ в формат, используемый программами сетевой библиотеки |
| ifconfig | Конфигурирует или отображает параметры сетевых интерфейсов ЭВМ (для протоколов TCP/IP) |
| ipreport | Генерирует сообщение о маршруте пакета на основе специфицированного маршрутного файла |
| iptrace | Обеспечивает отслеживание маршрута движения пакетов на интерфейсном уровне для протоколов Интернет |
| lsnamsv | Отображает информацию базы данных DNS |
| lsprtsv | Отображает информацию из базы данных сетевой службы печати |
| mkhost | Создает файл таблицы ЭВМ |
| mknamsv | Конфигурирует службу имен клиента (для TCP/IP) |
| mkprtsv | Конфигурирует службу печати ЭВМ (для TCP/IP) |
| mktcpip | Устанавливает требуемые величины для запуска TCP/IP на ЭВМ |
| namerslv | Непосредственно манипулирует записями сервера имен для локальной программы DNS в базе данных конфигурирования системы |
| netstat | Отображает состояние сети |
| no | Конфигурирует сетевые опции |
| rmnamsv | Удаляет TCP/IP службу имен из ЭВМ |
| rmprtsv | Удаляет службу печати на машине клиента или сервере |
| route | Служит для ручного манипулирования маршрутными таблицами |
| ruptime | Отображает состояние каждой ЭВМ в сети |
| ruser | Непосредственно манипулирует записями в трех отдельных системных базах данных, которые регулируют доступом внешних ЭВМ к программам |
| securetcpip | Активизирует сетевую безопасность |
| setclock | Устанавливает время и дату для ЭВМ в сети |
| slattach | Подключает последовательные каналы в качестве сетевых интерфейсов |
| timedc | Присылает информацию о демоне timed |
| trpt | Выполняет отслеживание реализации протокола для TCP-сокетов |
Для того чтобы диагностировать ситуацию в сети, необходимо представлять себе взаимодействие различных ее частей в рамках протоколов TCP/IP и иметь некоторое представление о работе Ethernet . Сети, следующие рекомендациям Интернет, имеют локальный сервер имен (DNS, RFC-1912, -1886, -1713, -1706, -1611-12, -1536-37, -1183, -1101, -1034-35; цифры, напечатанные полужирным шрифтом, соответствуют кодам документов, содержащим описания стандартов), служащий для преобразования символьного имени сетевого объекта в его IP-адрес. Обычно эта машина базируется на ОС UNIX. DNS-сервер обслуживает соответствующую базу данных, которая хранит много другой полезной информации. Многие ЭВМ имеют SNMP-резиденты (RFC-1901-7, -1446-5, -1418-20, -1353, -1270, -1157, -1098), обслуживающие управляющую базу данных MIB (RFC-1792, -1748-49, -1743, -1697, -1573, -1565-66, -1513-14, -1230, -1227, -1212-13), содержимое которой поможет также узнать много интересного о состоянии вашей сети. Сама идеология Интернет предполагает богатую диагностику (протокол ICMP, RFC-1256, 1885, -1788, -792).
Протокол ICMP используется в наиболее популярной диагностической программе ping входит в поставку практически всех сетевых пакетов). Возможная форма вызова этой программы имеет вид:
ping <имя или адрес ЭВМ или другого объекта> [размер пакета] [число посылок]
размер пакета задается в байтах (по умолчанию равно 56). Процедура выполнения ping может быть прервана нажатием клавиш ctrl-C. В различных реализациях программа ping имеет много различных опций, которые позволяют измерять статистические характеристики канала (например, потери), определение задержки в канале (RTT), отображение посылаемых пакетов и получаемых откликов, а также определение маршрута до интересующего объекта. Ping используется для определения доступности сервис-провайдера и т.д. Иногда ping является составной частью более мощной диагностической программы (например, netwatch). Ниже приведен пример использования команды tracetoute, которая во многом эквивалентна ping (но базируется непосредственно на IP, используя соответствующие опции):
traceroute kirk.Bond.edu.au (посмотрим, как идут пакеты до этого сервера в Австралии)
(IP-адрес=131.244.1.1 узнан, зондирование начинается, допустимо не более 30 шагов)
traceroute to kirk.Bond.edu.au (131.244.1.1) 30 hops max, 40 byte packets
1 ITEP-FDDI-BBone (193.124.224.50) 2 ms 2 ms 2 ms
2 MSU-Tower-2.Moscow.RU.Radio-MSU.net (194.67.80.65) 3 ms 3 ms 3 ms
3 NPI-MSU.Moscow.RU.Radio-MSU.net (194.67.80.5) 4 ms 3 ms 3 ms
4 NPI-P.Moscow.RU.Radio-MSU.net (194.67.80.18) 4 ms 5 ms 4 ms
5 DESY-P.Hamburg.DE.Radio-MSU.net (194.67.80.14) 317 ms 310 ms 329 ms
6 DESY.Hamburg.DE.Radio-MSU.net (194.67.82.17) 312ms 320ms 312ms (маршрут через Германию)
7 188.1.56.5 (188.1.56.5) 321 ms 357 ms 327 ms
8 188.1.56.10 (188.1.56.10) 347 ms 467 ms 356 ms
9 DE-f0-0.eurocore.bt.net (194.72.24.193) 331 ms 337 ms 331 ms
10 NL-s1-1.eurocore.bt.net (194.72.24.202) 355 ms 435 ms 343 ms
11 NL-f0.dante.bt.net (194.72.24.2) 367 ms 353 ms 573 ms
12 New-York2.dante.net (194.72.26.10) 497ms 493ms 489ms (пересекли Атлантический океан)
13 f1-0.t32-0.New-York.t3.ans.net (204.149.4.9) 546 ms 501 ms 490 ms
14 h5-0.t36-1.New-York2.t3.ans.net (140.223.33.10) 540 ms 506 ms 571 ms
15 * f2.t36-0.New-York2.t3.ans.net (140.223.36.221) 503 ms 505 ms
16 h13.t40-0.Cleveland.t3.ans.net (140.223.37.10) 802 ms 795 ms 523 ms
17 h14.t24-0.Chicago.t3.ans.net (140.223.25.9) 537 ms 509 ms 526 ms
18 h13.t96-0.Denver.t3.ans.net (140.223.25.18) 545 ms 531 ms 545 ms
19 h12.t8-0.San-Francisco.t3.ans.net (140.223.9.17) 853 ms 584 ms 592 ms
20 border2-fddi1-0.SanFrancisco.mci.net (206.157.77.1) 563 ms 591 ms 753 ms
21 telstra-ds3.SanFrancisco.mci.net (204.70.33.10) 691 ms * 691 ms
22 telstra.SanFrancisco.mci.net (204.70.204.6) 759 ms 815 ms 753 ms (достигли Тихого океана)
23 Fddi0-0.pad-core2.Sydney.telstra.net (139.130.249.227) 766 ms 1054 ms 837 ms (океан позади - Австралия!)
24 Serial4-4.cha-core1.Brisbane.telstra.net (139.130.249.202) 781 ms 776 ms 810 ms
25 qld-new.gw.au (139.130.247.227) 836 ms 917 ms 806 ms
26 139.130.5.2 (139.130.5.2) 816 ms 796 ms 811 ms
27 203.22.86.241 (203.22.86.241) 800 ms 787 ms 838 ms
28 203.22.86.194 (203.22.86.194) 850 ms 790 ms 768 ms
29 kirk.Bond.edu.au (131.244.1.1) 781 ms (ttl=226!) 918 ms (ttl=226!) 799 ms (ttl=226!)
Цель достигнута за 29 шагов! (Путь бывает и длиннее, но редко).
Программа traceroute посылает по три пакета с нарастающими значениями TTL, если отклик на пакет не получен печатается символ *. Большие задержки (RTT) в приведенном примере определяются спутниковыми каналами связи (время распространения сигнала до спутника!).
Для того чтобы правильно реагировать на нештатные ситуации, надо хорошо представлять себе, как сеть должна работать в нормальных условиях. Для этого надо изучить сеть, ее топологию, внешние связи, конфигурацию программного обеспечения центральных серверов и периферийных ЭВМ. Следует иметь в виду, что изменение конфигурации является обычно привилегией системного администратора и в любых сомнительных случаях нужно обращаться к нему. Неквалифицированные действия при реконфигурировании системы могут иметь катастрофические последствия.
Сетевое оборудование, имеющееся в BSD UNIX-системе, описано в документации intro(4), которая доступна через справочную систему man, например:
man - 4 intro | grep Ether (Выделенная строка представляет собой команду, введенную с клавиатуры, следующий за ней текст - отклик ЭВМ на эту команду)
a network interface for the 10-Megabit Ethernet, along with
SunOS supports the 10-Megabit Ethernet as its primary net-
ie ie(4S) Intel 10 Mb/s Ethernet interface
le le(4S) LANCE 10Mb/s Ethernet interface
Для того чтобы получить дополнительную информацию об этих интерфейсах, можно выдать команду dmesg (или просмотреть файл /usr/adm/messages):
dmesg | grep le0
le0 at SBus slot f 0xc00000 pri 6 (onboard)
le0: AUI Ethernet
Работа сетевого обеспечения базируется на нескольких резидентных программах (демонах): routed и gated (маршрутизация), named (сервер имен), inetd (Интернет услуги). Перечень демонов базовых услуг представлен в таблице 5.2.
Таблица 5.2. Основные TCP/IP демоны
| Название демона | Назначение |
| fingerd | Предоставляет информацию об удаленном пользователе |
| ftpd | Реализует функции сервера передачи файлов (протокол FTP) |
| gated | Реализует функции маршрутизации шлюза для протоколов RIP, HELLO, EGP, BGP и SNMP |
| inetd | Реализует управление сетевыми услугами Интернет |
| named | Реализует услуги сервера имен (DNS) |
| rexecd | Реализует серверные функции для команд rexec (удаленное исполнение) |
| rlogind | Реализует серверные функции для команд rlogin (авторизация) |
| routed | Управляет сетевыми маршрутными таблицами |
| rshd | Реализует серверные функции для команд удаленного исполнения |
| rwhod | Реализует серверные функции для команд rwho и ruptime |
| syslogd | Читает и записывает в журнал сообщения |
| talkd | Реализует серверные функции для команд talk |
| telnetd | Реализует серверные функции для протокола TELNET |
| tftpd | Реализует серверные функции для протокола TFTP |
| timed | При загрузке системы устанавливает демон timeserver |
head -16 /etc/inetd.conf
# @(#)inetd.conf 1.24 92/04/14 SMI
# Configuration file for inetd(8). See inetd.conf(5).
# To re-configure the running inetd process, edit this file, then
# send the inetd process a SIGHUP.
# Internet services syntax:
# <service_name> <socket_type> <proto> <flags> <user> <server_pathname> <args>
# Ftp and telnet are standard Internet services.
| #ftp | stream | tcp | nowait | root | /usr/etc/in.ftpd | in.ftpd |
| #ftp | stream | tcp | nowait | root | /usr/etc/wrapper.3.9.4/tcpd | in.ftpd -dl |
Строки, начинающиеся с символа #, являются комментариями. В данном примере представлена одна информативная строка (их может быть много больше), характеризующая файловый обмен. Каждая строка в этом файле начинается с имени ресурса (в приведенном примере ftp). Далее следует поле типа соединителя (socket): stream (TCP поток байтов); dgram - передача данных в виде UDP-дейтограмм.
Следующее поле характеризует протокол, используемый данным видом сервиса (TCP или UDP). За ним идет поле, которое описывает способ реализации процедуры (wait/nowait; для поточных серверов nowait). Следующее поле представляет собой идентификатор пользователя (UID), но обычно пользователем является системный администратор - root. Встречается два исключения. Процедура finger выполняется с UID=nobody или daemon, а uucp использует реальное имя пользователя. За полем uid следует поле сервера (в примере /usr/etc/wrapper.3.9.4/tcpd /usr/local/etc/ftpd). В это поле заносится полное описание пути к программе-серверу, запускаемой inetd. Завершающим полем является поле аргументы, куда записывается строка, передаваемая программе-серверу. Содержимое файла inetd.conf должно быть предметом особой заботы администратора, так как от содержимого этого файла зависит эффективная работа сети и ее безопасность.
Как уже отмечалось выше, одним из важнейших частей любого узла Интернет является сервер имен (DNS). Конфигурация DNS-сервера определяется тремя файлами: named.boot, named.ca и named.local. Зонная информация содержится в файле named.rev, а данные о локальном домене в файле named.hosts. Отладка, контроль и диагностика DNS-сервера осуществляется с использованием программ nslookup (или dig). Рассмотрим пример использования процедуры nslookup (здесь выполнены запросы по серверам имен, по почтовым серверам и по параметрам зоны ответственности):
Nslookup (запуск сервера)
Default Server: ns.itep.ru
Address: 193.124.224.35
set type=NS (запрос данных о серверах имен)
> > Server: ns.itep.ru
Address: 193.124.224.35
| eunet.fi | (определяем имя запрашиваемого узла) |
| eunet.fi | nameserver = ns1.EUNET.FI |
| eunet.fi | nameserver = ns2.EUNET.FI |
| eunet.fi | nameserver = ns3.eunet.fi |
| eunet.fi | nameserver = ns.eu.net |
| eunet.fi | nameserver = ns0.EUNET.FI |
| eunet.fi | nameserver = ns1.EUNET.FI |
..........................................
Non-authoritative answer:
| eunet.fi | nameserver = ns1.EUNET.FI |
| eunet.fi | nameserver = ns2.EUNET.FI |
| eunet.fi | nameserver = ns3.eunet.fi |
| eunet.fi | nameserver = ns.eu.net |
| origin = ns1.eunet.fi | |
| mail addr = hostmaster.eunet.fi | |
| serial = 199607235 | |
| refresh = 28800 (8 hours) | |
| retry = 7200 (2 hours) | |
| expire = 604800 (7 days) | |
| minimum ttl = 86400 (1 day) | |
| eunet.fi | preference = 10, mail exchanger = pim.eunet.fi (Основной почтовый сервер) |
| eunet.fi | preference = 50, mail exchanger = mail.eunet.fi |
| eunet.fi | nameserver = ns0.EUNET.FI |
| eunet.fi | nameserver = ns1.EUNET.FI |
| eunet.fi | nameserver = ns2.EUNET.FI |
| eunet.fi | nameserver = ns3.eunet.fi |
| eunet.fi | nameserver = ns.eu.net |
| eunet.fi | nameserver = ns0.EUNET.FI |
| ns1.EUNET.FI | internet address = 192.26.119.7 |
| ns2.EUNET.FI | internet address = 192.26.119.4 |
| ns3.eunet.fi | internet address = 192.26.119.4 |
| ns.eu.net | internet address = 192.16.202.11 |
| pim.eunet.fi | internet address = 193.66.4.30 |
| mail.eunet.fi | internet address = 192.26.119.7 |
| ns0.EUNET.FI | internet address = 192.26.119.1 |
| set type=MX | (запрос информации о почтовых серверах) |
Non-authoritative answer:
| eunet.fi | preference = 50, mail exchanger = mail.eunet.fi | (имена почтовых серверов) |
| eunet.fi | preference = 10, mail exchanger = pim.eunet.fi |
Authoritative answers can be found from:
| eunet.fi | nameserver = ns1.EUNET.FI |
| eunet.fi | nameserver = ns2.EUNET.FI |
| eunet.fi | nameserver = ns3.eunet.fi |
| eunet.fi | nameserver = ns.eu.net |
| eunet.fi | nameserver = ns0.EUNET.FI |
| mail.eunet.fi | internet address = 192.26.119.7 |
| pim.eunet.fi | internet address = 193.66.4.30 |
| ns1.EUNET.FI | internet address = 192.26.119.7 |
| ns2.EUNET.FI | internet address = 192.26.119.4 |
| ns3.eunet.fi | internet address = 192.26.119.4 |
| ns.eu.net | internet address = 192.16.202.11 |
| ns0.EUNET.FI | internet address = 192.26.119.1 |
RFC-1034-35)
.......................................
Non-authoritative answer (см. документы RFC-1034-35):
| origin = ns1.eunet.fi | |
| mail addr = hostmaster.eunet.fi | |
| serial = 199607235 | |
| refresh = 28800 (8 часов) | |
| retry = 7200 (2 часа) | |
| expire = 604800 (7 дней) | |
| minimum ttl = 86400 (1 день) |
| eunet.fi | nameserver = ns1.EUNET.FI |
| eunet.fi | nameserver = ns2.EUNET.FI |
| eunet.fi | nameserver = ns3.eunet.fi |
| eunet.fi | nameserver = ns.eu.net |
| eunet.fi | nameserver = ns0.EUNET.FI |
| ns1.EUNET.FI | internet address = 192.26.119.7 |
| ns2.EUNET.FI | internet address = 192.26.119.4 |
| ns3.eunet.fi | internet address = 192.26.119.4 |
| ns.eu.net | internet address = 192.16.202.11 |
| ns0.EUNET.FI | internet address = 192.26.119.1 |
| >exit | (команда выхода из nslookup) |
Программа dig функционально является аналогом nslookup, но в прикладном плане имеет определенные отличия, она снабжена рядом полезных опций (таблица 5.3):
Таблица 5.3 Опции программы dig
| Тип запроса | Запись DNS-сервера |
| a | Адресная запись |
| any | Любой тип записи |
| axfr | Все записи, относящиеся к зоне |
| hinfo | Записи, характеризующие ЭВМ |
| mx | Записи, определяющие почтовый обмен |
| ns | Записи сервера имен |
| soa | Начало записей для зоны ответственности DNS-сервера |
| txt | Текстовые записи |
dig @vxdesy.desy.de ns
; <<>> DiG 2.0 <<>> @vxdesy.desy.de ns
; (3 servers found)
;; res options: init recurs defnam dnsrch
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr rd ra; Ques: 1, Ans: 9, Auth: 9, Addit: 9
;; QUESTIONS:
;;., type = NS, class = IN
;; ANSWERS:
| . | 185470 | NS | A.ROOT-SERVERS.NET. |
| . | 185470 | NS | H.ROOT-SERVERS.NET. |
| . | 185470 | NS | B.ROOT-SERVERS.NET. |
| . | 185470 | NS | C.ROOT-SERVERS.NET. |
| . | 185470 | NS | D.ROOT-SERVERS.NET. |
| . | 185470 | NS | E.ROOT-SERVERS.NET. |
| . | 185470 | NS | I.ROOT-SERVERS.NET. |
| . | 185470 | NS | F.ROOT-SERVERS.NET. |
| . | 185470 | NS | G.ROOT-SERVERS.NET. |
;; AUTHORITY RECORDS:
| . | 185470 | NS | A.ROOT-SERVERS.NET. |
| . | 185470 | NS | H.ROOT-SERVERS.NET. |
| . | 185470 | NS | B.ROOT-SERVERS.NET. |
| . | 185470 | NS | |
| . | 185470 | NS | D.ROOT-SERVERS.NET. |
| . | 185470 | NS | E.ROOT-SERVERS.NET. |
| . | 185470 | NS | I.ROOT-SERVERS.NET. |
| . | 185470 | NS | F.ROOT-SERVERS.NET. |
| . | 185470 | NS | G.ROOT-SERVERS.NET. |
| A.ROOT-SERVERS.NET. | 531366 | A | 198.41.0.4 |
| H.ROOT-SERVERS.NET | 531366 | A | 128.63.2.53 |
| B.ROOT-SERVERS.NET. | 531366 | A | 128.9.0.107 |
| C.ROOT-SERVERS.NET. | 578733 | A | 192.33.4.12 |
| D.ROOT-SERVERS.NET. | 578733 | A | 128.8.10.90 |
| E.ROOT-SERVERS.NET. | 547664 | A | 192.203.230.10 |
| I.ROOT-SERVERS.NET. | 578733 | A | 192.36.148.17 |
| F.ROOT-SERVERS.NET. | 531366 | A | 192.5.5.241 |
| G.ROOT-SERVERS.NET. | 531366 | A | 192.112.36.4 |
;; WHEN: Thu Jul 25 12:07:54 1996
;; MSG SIZE sent: 17 rcvd: 429
Программа ifconfig служит для контроля состояния сетевых интерфейсов, их конфигурирования и проверки. С помощью этой команды интерфейсу присваивается IP-адрес, субсетевая маска и широковещательный адрес. Примером использования ifconfig для получения информации об интерфейсе может служить:
ifconfig le0
le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST>
inet 193.124.224.35 netmask ffffffe0 broadcast 193.124.224.32
Флаг UP означает, что интерфейс готов к использованию, DOWN указывает на необходимость перевода интерфейса в состояние UP с помощью команды ifconfig le0 up. Если эта команда не проходит, следует проверить соединительный кабель или сам интерфейс. Флаг RUNNING говорит о том, что интерфейс работает. При отсутствии этого флага следует проверить правильность инсталляции. Флаг BROADCAST указывает на то, что интерфейс поддерживает широковещательный режим адресации (MULTICAST - допускает многоадресное обращение). Флаг NOTRAILERS - показывает, что интерфейс не поддерживает trailer-инкапсуляцию (Ethernet). Вторая строка отклика на команду начинается с ключевого слова inet (Интернет) и содержит IP-адрес, маску субсети и широковещательный адрес. На ошибку в задании маски субсети указывает факт доступности удаленных ЭВМ и машин локальной субсети при недоступности ЭВМ соседних субсетей.
При неверном задании IP- адреса возможны самые разные ошибки. При неверной сетевой части адреса команда Ping будет вызывать ошибку типа "no answer". Ошибка же в части адреса, характеризующей ЭВМ, может быть не замечена в течение длительного времени, если носителем ошибочного адреса является персональная ЭВМ, обращений к которой извне не происходит. Определенное время можно использовать и чужой IP-адрес. Такого рода ошибки не могут быть выявлены с помощью ifconfig, здесь хорошую службу может оказать программа arp (см. описание протокола в RFC-826). Эта программа позволяет анализировать преобразование IP-адресов в физические (Ethernet). Она имеет несколько полезных опций (возможны вариации для разных реализаций и ОС):
| -a | отображает содержимое всей ARP-таблицы |
| -d <имя ЭВМ> | удаляет запись из ARP-таблицы |
| -s <имя ЭВМ> <Ethernet-адрес> | добавляет новую запись в таблицу |
arp -a
| itepgw.itep.ru | (193.124.224.33) at 0:0:c:2:3a:49 |
| ITEP-FDDI-BBone.ITEP.RU | (193.124.224.50) at 0:0:c:2:fb:c5 |
| RosNET-Gw.ITEP.Ru | (193.124.224.37) at 0:c0:14:10:1:cd |
| nb.itep.ru | (193.124.224.60) at 0:80:ad:2:24:b7 |
Если анализ ARP- таблицы не помог, попробуйте войти в ЭВМ, соответствующую подозрительному адресу, с помощью команды telnet. Если ЭВМ допускает удаленный доступ, характер входного сообщения поможет разобраться, что это за машина.
Одной из наиболее информативных команд является netstat (за исчерпывающим описанием опций и методов применения отсылаю к документации на ваше сетевое программное обеспечение). Эта команда может вам дать информацию о состоянии интерфейсов на ЭВМ, где она исполнена:
netstat -i
| Name | Mtu | Net/Dest | Address | Ipkts | Ierrs | Opkts | Oerrs | Collis | Queue |
| le0 | 1500 | 193.124.224.32 | ns | 966204 | 0 | 584033 | 0 | 846 | 0 |
| lo0 | 1536 | 127.0.0.0 | 127.0.0.1 | 4191 | 0 | 4191 | 0 | 0 | 0 |
netstat -nr
Маршрутная таблица
| Место назначения | Маршрутизатор | Флаги | Refcnt | Use | Интерфейс |
| 192.148.166.185 | 193.124.224.33 | UGHD | 0 | 0 | le0 |
| 192.148.166.161 | 193.124.224.33 | UGHD | 0 | 0 | le0 |
| 192.148.166.97 | 193.124.224.33 | UGHD | 0 | 0 | le0 |
| 192.148.166.177 | 193.124.224.33 | UGHD | 0 | 0 | le0 |
| 192.148.166.129 | 193.124.224.33 | UGHD | 1 | 192 | le0 |
| 192.148.166.145 | 193.124.224.33 | UGHD | 0 | 72 | le0 |
| 192.148.166.170 | 193.124.224.33 | UGHD | 0 | 4 | le0 |
| 192.148.166.26 | 193.124.224.60 | UGHD | 0 | 19 | le0 |
| 192.148.166.131 | 193.124.224.33 | UGHD | 0 | 0 | le0 |
| 192.148.166.140 | 193.124.224.33 | UGHD | 0 | 0 | le0 |
| 192.148.166.173 | 193.124.224.33 | UGHD | 0 | 2 | le0 |
| 192.148.166.182 | 193.124.224.33 | UGHD | 0 | 20 | le0 |
| 192.148.166.142 | 193.124.224.33 | UGHD | 0 | 300 | le0 |
Флаг "U" (Up) свидетельствует о том, что канал в рабочем состоянии. Флаг "G" указывает на то, что маршрут проходит через маршрутизатор (gateway). При этом вторая колонка таблицы содержит имя этого маршрутизатора или его адрес. Если флаг "G" отсутствует, ЭВМ непосредственно связана с указанной сетью. Флаг "D" указывает на то, что маршрут был добавлен динамически. Если маршрут связан только с конкретной ЭВМ, а не с сетью, он помечается флагом "H" (host), при этом первая колонка таблицы содержит его IP-адрес. Флаг "M" указывает на то, что маршрут был изменен с помощью сообщения о переадресации. Флаг <null> говорит о том, что адресат достижим непосредственно.
Возможности netstat не ограничиваются локальной сетью или автономной системой, с помощью ее можно получить некоторую информацию об удаленных ЭВМ или маршрутизаторах. Например:
netstat -r 194.85.112.34
| input packets | (le0) errs | output packets | errs | colls | input packets | Total errs | Output packets | errs | colls |
| 7636610 | 0 | 4578719 | 0 | 5918 | 7674851 | 0 | 4616960 | 0 | 5918 |
ps 'cat /etc/gated.pid'
после чего обратитесь к системному администратору :-).
Если нужно получить информацию о смонтированных файловых системах, вы можете воспользоваться командой:
showmount -e ns (ns - имя ЭВМ)
export list for ns.itep.ru:
/u1/SunITEP saturn.itep.ru,suncom.itep.ru
Крайне полезна для контроля конфигурации системы команда host, она имеет много опций и с ее помощью можно узнать о доступных типах услуг, об именах и IP-адресах почтовых серверов и серверов имен, о кодах их предпочтения и т.д..
host -a vitep5
Trying domain "itep.ru"
rcode = 3 (Non-existent domain), ancount=0
Trying null domain
rcode = 0 (Success), ancount=6
| vitep5.itep.ru | 86400 | IN | WKS | 192.148.166.198 tcp ftp telnet | |
| vitep5.itep.ru | 86400 | IN | HINFO | VAX-8530 | VMS 5.3 |
| vitep5.itep.ru | 86400 | IN | MX | 15 | mx.itep.ru |
| vitep5.itep.ru | 86400 | IN | MX | 200 | relay1.kiae.su |
| vitep5.itep.ru | 86400 | IN | MX | 210 | relay2.kiae.su |
| vitep5.itep.ru | 86400 | IN | A | 192.148.166.198 |
Additional information:
| relay1.kiae.su | 18938 IN | A | 193.125.152.6 |
| relay1.kiae.su | 18938 IN | A | 193.125.152.1 |
| relay2.kiae.su | 18938 IN | A | 193.125.152.1 |
В последнее время появилось несколько комплексных (общедоступных) пакетов диагностики (NetWatch, WS_watch, SNMPMAN, Netguard и др.). Некоторые из этих пакетов позволяют построить графическую модель тестируемой сети, выделяя цветом или с помощью вариации картинок работающие ЭВМ. Программы, использующие протокол SNMP, проверяют наличие посредством специального запроса доступность SNMP-демона, с помощью ICMP-протокола определяют работоспособность ЭВМ, после чего отображают переменные и массивы данных из управляющей базы данных MIB (если эта база имеет уровень доступа public). Это может делаться автоматически или по запросу оператора. SNMP-протокол позволяет мониторировать вариации загрузки отдельных сегментов сети пакетами UDP, TCP, ICMP и т.д., регистрируя количество ошибок по каждому из активных интерфейсов. Для решения этой задачи можно использовать соответствующую программу, которая регулярно опрашивает MIB интересующих вас ЭВМ, а полученные числа заносятся в соответствующий банк данных. При возникновении нештатной ситуации администратор сети может просмотреть вариации потоков в сегментах сети и выявить время и причину сбоя в системе. Аналогичные данные можно получить с помощью программы, переводящей интерфейс Ethernet в режим приема всех пакетов (mode=6). Такая программа допускает получение данных по всем типам пакетов, циркулирующих в данном кабельном сегменте. Введя в программу определенные фильтры (отбор по IP-адресам отправителей, получателей, по широковещательным запросам или определенным протоколам) можно узнать много полезного о своей сети.
К сожалению, этот метод пригоден только в отношении логического сегмента, к которому подключена ваша ЭВМ. Такие программы могут использоваться для контроля сетевых ресурсов, если ЭВМ размещена на соответствующем сегменте, что может оказаться актуально в связи с коммерциализацией сетевых услуг. По этой причине метод диагностики через SNMP-резидентов более универсален. Упомянутые в начале программы Tcpdump и Etherfind крайне полезны для отладки программ, работающих с сетевыми пакетами. Они позволяют отображать все входящие и посылаемые пакеты. Следует иметь в виду, что эти программы потенциально опасны с точки зрения несанкционированного доступа и, поэтому их применение часто возможно только для привилегированных пользователей. Работа интерфейса в режиме перехвата всех пакетов также представляет угрозу безопасности сети (возможность получения чужих паролей). С учетом этого обстоятельства должно приветствоваться использование программного обеспечения, где содержимое пакетов терминального обмена подвергается шифрованию-дешифрованию.
Определенный интерес может представлять диагностическая программа ttcp, которая позволяет измерять некоторые характеристики TCP- или UDP-обменов между двумя узлами (, каталог sgi/src/ttcp или vgr.brl.mil ftp/pub/ttcp.c).
Перечисленные режимы работают в рамках протокола TCP, для исследования процессов, требующих UDP, следует использовать опцию -u. Существует множество других опций, обеспечивающих реализацию самых разнообразных режимов работы (см. и справочные руководства на вашей ЭВМ).
Конфигурация сети и режимы ее работы определяются системными переменными, которые задаются администратором сети. Имена этих сетевых переменных для разных ЭВМ и программных пакетов варьируются. Ниже будут перечислены основные переменные, определяющие работу TCP/IP протоколов для SunOS 4.1.3.
IPFORWARDING - значение этой константы инициализирует системную переменную ip_forwarding. Если она равна -1, IP-дейтограммы никогда не переадресуются, а переменная уже никогда не меняется.
Если же она равна 0 (значение по умолчанию), IP- дейтограммы не переадресуются. Переменная принимает значение 1, когда доступны несколько интерфейсов. При значении константы, равном 1, переадресация всегда разрешена.
SUBNETSARELOCAL - константа, определяющая начальное значение переменной ip_subnetsarelocal. Если она равна 1 (по умолчанию), то IP-адрес места назначения с идентификатором сети, идентичным с тем, что имеет ЭВМ- отправитель, считается локальным вне зависимости от идентификатора субсети. Если константа равна нулю, то локальным будет считаться только адрес, принадлежащий данной субсети (при совпадении идентификаторов сети и субсети).
IPSENDREDIRECTS - константа, используемая для определения стартового значения переменной ip_sendredirects. Если константа равна 1, (по умолчанию) ЭВМ при выполнении процедуры forward посылает ICMP-сообщения о переадресации. При равенстве нулю ICMP-сообщения не посылаются.
DIRECTED_BROADCAST - константа, определяющая начальное значение переменной ip_dirbroadcast. Если константа равна 1 (по умолчанию), получаемые дейтограммы, адрес места назначения которых является широковещательным адресом интерфейса, переадресуются на канальный широковещательный уровень. При равенстве нулю такие дейтограммы ничтожаются.
Ряд системных переменных содержится в файле in_proto каталога /usr/kvm/sys/netinet. При изменении этих переменных система должна быть перезагружена.
tcp_default_mss значение MSS протокола TCP для нелокальных адресатов, по умолчанию равна 512.
tcp_keepidle определяет число 500 мс тактов между посылками запросов о работоспособности. По умолчанию равна 14400 (2 час.).
tcp_keepintvl определяет число 500 мс тактов между посылками запросов о работоспособности, когда не получено никакого отклика. По умолчанию эта переменная равна 150 (75сек).
tcp_keeplen используется для обеспечения совместимости с ранними версиями (4.2BSD), должна равняться 1.
tcp_nodelack при неравенстве нулю требует отправки немедленного отклика (ACK), по умолчанию равна нулю.
tcp_recvspace определяет размер входного TCP-буфера и влияет на величину окна. По умолчанию эта переменная равна 4096.
tcp_sendspace определяет размер выходного TCP-буфера, по умолчанию равна 4096.
tcp_ttl задает значение поля TTL в TCP-сегменте, по умолчанию имеет значение 60.
udp_cksum при неравенстве нулю требует вычисления контрольной суммы для отправляемых UDP-дейтограмм и проверки контрольных сумм для получаемых UDP-дейтограмм, если поле контрольной суммы не равно нулю. По умолчанию переменная равна нулю.
udp_recvspace определяет размер входного UDP-буфера, по умолчанию равна 18000, что соответствует двум 9000-байтным дейтограммам.
udp_sendspace задает объем выходного UDP-буфера, ограничивая предельную длину посылаемой дейтограммы. По умолчанию переменная равна 9000.
udp_ttl определяет значение поля TTL для UDP-дейтограмм, значение по умолчанию - 60.
Для изменения значений этих переменных необходимо иметь системные привилегии.
Диагностика на базе ICMP
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Безусловно SNMP предоставляет наиболее мощные и универсальные возможности диагностики. Но этот протокол не дает решить все проблемы. Не все объекты в Интернет имею активные SNMP-агенты. Как было описано в разделе Ping, протокол ICMP позволяет проверить доступность пути от машины оператора до любой ЭВМ, включенной в Интернет. При этом может быть измерено время пакета в пути и вероятность потери пакета. Проводя такое зондирование периодически и сравнивая результаты для разных моментов времени и разных путей, можно получить важную диагностическую информацию. Время пакета в пути может стать важным параметром для тестирования внешних каналов, ведь задержка может расти из-за потерь пакетов на некоторых этапах.
Потеря пакета может произойти как по пути туда, так и по пути обратно. Кроме того, отсутствие отклика может произойти из-за перегрузки буфера или процессора ЭВМ-адресата. В локальных сетях при нормальных условиях потеря может случиться только из-за переполнения буферов в переключателях или ЭВМ (объекты mac-уровня). Если сеть правильно сконфигурирована, реализуются только так называемые "короткие" столкновения, когда столкновение происходит не позднее, чем при передаче 64-го байта. Но если при построении сети допущены ошибки, возможны более поздние столкновения, что становится дополнительной причиной потери пакетов. Тогда может проявиться зависимость вероятности столкновения от длины пакета.
Следует учитывать, что если столкновение зафиксировано передающей стороной до завершения посылки пакета, то потери пакета не произойдет, так как передача будет повторена на физическом уровне. Потеря из-за столкновения может произойти только для короткого пакета при слишком больших задержках в логическом сегменте.
Понятно, что вероятность столкновений пропорциональна плотности вероятности потока запросов от активных узлов логического сегмента (зоны столкновений). По этой причине, зондируя определенный удаленный логический сегмент можно оценить вариации загрузки.
Более информативным может стать сочетание зондирования с помощью пакетов ICMP и контроль втекающих и вытекающих потоков сегмента посредством SNMP-протокола.
При использовании процедуры ping (с необходимыми опциями) для зондирования внешних каналов можно выявить как циклы пакетов, так и осцилляции маршрутов.
Протокол ICMP при круглосуточном мониторинге позволяет контролировать активность всех узлов локальной сети. Кроме того, такая программа в случае выхода из строя какого-то сегмента позволяет оперативно локализовать неисправный сетевой элемент (см. рис. 5.2.1). Сканирующая программа должна использовать в качестве исходной информации базу данных всех узлов локальной сети, куда должны быть помещены IP- и MAC-адреса всех сетевых узлов, их имена, географическое положение, фамилия хозяина и другая необходимая информация, например, суммарная задержка от какой-то точки в сети до данной рабочей станции. Результаты работы этой диагностической программы заносится в файлы, доступные для диагностического WWW-сервера. Такие данные упрощают поиск причины в случае аварии, так как позволяют проконтролировать активность в сети накануне появления отказа. Если такая программа одновременно измеряет все основные информационные потоки, она поможет выявить самые слабые участки в сети, выявить источники слишком частых широковещательных запросов. Теоретически это позволяет даже динамически реконфигурировать потоки в локальной сети, устраняя узкие места.
Рис. 5.2.1. Схема, поясняющая диагностические возможности протокола ICMP
Пусть диагностическая ЭВМ занимает положение в сети, помеченное буквой D. Сканирующая программа, позволяя проверить доступность любой из ЭВМ, может выявить неисправный вход/выход любого из повторителей, хотя сами эти приборы пассивны и на пакеты ICMP откликов не присылают. Это определяется по наличию или отсутствию отклика от хотя бы одной ЭВМ, подключенной к исследуемому входу/выходу. Так, если ни одна ЭВМ сегмента Б не откликается, то можно сделать вывод, что выход 3 повторителя 2 не исправен (предполагается, что хотя бы одна машина сегмента Б включена).
Аналогичным образом можно проверить выходы повторителя 1. Если же не откликаются ЭВМ сегментов А и Б, то весьма вероятен отказ моста. Если же ни одна из ЭВМ, показанных на рисунке, не присылает отклика, а известно, что они включены, то не исправен повторитель 1. Конечно, эту задачу можно решить и с помощью стандартной программы PING, но это займет много больше времени. Администраторы, обслуживающие многомашинные сети, размещенные во многих зданиям, безусловно оценят преимущества сканирующей программы.
Сканируя всю сеть периодически в течение суток и регистрируя процент потерь пакетов в сети, можно выявить и неисправные сетевые интерфейсы. Такой интерфейс при включении может портить условия распространения пакетов по сегменту. Обнаружив корреляцию между повышением вероятности потерь пакетов и включением определенной ЭВМ, можно сделать именно такой вывод и позднее независимо исследовать именно этот сетевой интерфейс.
Протокол ICMP можно использовать и для измерения размера зоны столкновений, что крайне важно для успешной работы локальной сети, ведь превышение предельного размера зоны приводит к резкому росту числа столкновений. Вычислить размер зоны бывает затруднительно, так как для повторителей и концентраторов довольно часто время задержки не указывается. Разумеется, что оно должно быть меньше предельно допустимого, разрешенного документом 802.3, но кто может дать гарантию? Для решения поставленной задачи следует использовать ICMP пакеты минимальной длины. Программа посылает пакеты ICMP и воспринимает отклики, регистрируя долю потерянных пакетов. Для зондирования выбирается самая удаленная рабочая станция или сервер (см. рис. 5.2.2). Программа должна уметь посылать ICMP-пакеты, не дожидаясь отклика. Пакеты посылаются парами с зазором между ними t. Далее варьируем t и добиваемся максимума вероятности потери пакетов. Зазор t, при котором будет достигнут максимум потерь, соответствует реальному значению задержки, характеризующей зону столкновений для данного логического сегмента сети.
Периодическая посылка пакетов слишком сильно перегрузит сеть, именно по этой причине следует периодически посылать пары пакетов. При этом период посылки таких пар должен быть достаточно велик, чтобы исключить влияние процессов восстановления после столкновения (> 1сек).
Рис. 5.2.2. Схема зондирования
RTT в данном случае равно 2Т+t, где t - время задержки отклика в зондируемой ЭВМ. Зазор между пакетами t должен быть больше t. Если t больше Т, то точность измерения будет невелика. Можно подумать, что при t Ј t вероятность столкновения будет равна 100%, но это не так. В этом случае столкновения не будет, ведь интерфейс обнаружит несущую у себя на входе и передачу не начнет. Передача отклика может начаться не ранее 9,6 мксек после завершения первого пакета-зонда (IPG). Если t < 9,6 мксек, передача отклика начнется через 9,6 мксек, если же больше, то через t. На практике 100% потери за счет столкновений будут реализовываться при t < t < Т+t (при t > 9,6 мксек). При t > t+t столкновения не будет, так как до измерительной машины дойдет пакет от исследуемой ЭВМ и передача не начнется из-за обнаружения интерфейсом несущей в кабельном сегменте. Следует иметь в виду, что при детектировании столкновения обе ЭВМ попытаются через некоторое время повторить попытку. Эта попытка вероятнее всего увенчается успехом, ведь они начнут ее не одновременно. Для извлечения нужных данных надо считывать содержимое регистра интерфейса, где записывается число случаев столкновений. Определив диапазон временных зазоров между пакетами-зондами, при которых происходят столкновения со 100% вероятностью, мы получим значение Т. Здесь требуются достаточно точные часы с разрешающей способностью лучше 10 мксек. Если таких часов нет, можно использовать время исполнения команд, предварительно прокалибровав это время при достаточно большом числе их исполнения.
Ниже на рисунке 5.2.3 показан результат круглосуточного мониторинга в сети ГНЦ ИТЭФ. Программа позволяет не только отображать такого рода диаграммы но и измеряет относительные потери для различных сегментов сети (написана Сергеем Тимохиным).Предусмотрена возможность вывода списка машин активных в любой заданный интервал времени. По горизонтали отложено время суток 0-24 часа, а по вертикали - число ЭВМ, присылающих отклики на icmp-запросы. Нетрудно видеть, что днем активных ЭВМ больше, чем ночью. :-)
Рис. 5.2.3. Пример круглосуточного мониторинга активности в сети с использованием ICMP-зондирования
Другим примером такого мониторинга могут служить программы, контроля внешних каналов ИТЭФ и связей в пределах локальной сети. Смотри страницы: http://saturn.itep.ru/trace/intern/start.htm и http://saturn.itep.ru/trace/extern/start_trace.htm
Конфигурирование сетевых систем
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
От корректности конфигурации сети зависит ее эффективная работа, надежность и безопасность. К сожалению набор параметров, определяющих конфигурацию, сильно зависит от используемой операционной системы и конкретного сетевого программного обеспечения. Большинство локальных сетей сегодня строятся вокруг серверов, которые работают под ОС UNIX (если не считать одноранговых сетей MS Windows). По этой причине ниже будут описаны конфигурационные файлы именно этой ОС. Название конфигурационных файлов и их назначения приведены в таблице 5.5.1.
Таблица 5.5.1. Конфигурационные файлы
| Название файла | Назначение |
| /etc/hosts | База данных имен ЭВМ и их IP-адресов (ею пользуются такие утилиты, как ping и ifconfig) |
| /etc/networks | База данных имен ЭВМ и их MAC-адресов (адресов сетевых карт) |
| /etc/ethers | Опционный файл, который содержит имена субсетей, их сетевые маски или сетевые адреса доменов |
| /etc/protocols | Конфигурационный файл, где содержится перечень имен поддерживаемых протоколов и их кодов. Первое поле содержит официальное название протокола, далее следует код протокола, третье поле содержит псевдоним протокола. |
| /etc/services | Файл, определяющий взаимодействие в системе клиент-сервер. Первое поле содержит название процесса (Echo, tcpmux, systat, netstat, chargen, TFTP, NNTP, POP-3, login, talk и т.д.), второе поле хранит номер порта и имя протокола. |
| /etc/syslog | Определяет типы сообщений и проход к log-файлу |
| /etc/inetd.conf | Содержит последовательность записей, определяющих работу протоколов Интернет: имя услуги (из файла /etc/services); тип сокета (stream, dgram, raw или rdm); протокол (из файла /etc/protocols); статус ожидания (wait-status); пользователь; проход к серверу. |
| /etc/routed | Используется при загрузке системы, определяет взаимодействие с другими машинами |
| /etc/passwd | Содержит информация для идентификации пользователей и их паролей |
| /etc/hosts.equiv | Содержит имена машин и пользователей, что позволяет авторизованному пользователю входить в другие машины, не вводя пароль. |
| /etc/bootptab | Определяет адреса и загрузочные файлы |
| /etc/snmp.conf | Определяет содержимое поля community и допустимые адреса |
| /etc/resolv.conf | Служба имен. Определяет имя локального домена и следующего вышестоящего сервера имен. |
| /etc/named.boot | Определяет положение баз данных, других серверов имен и доменов, обслуживаемых named. |
| /usr/local/domain/named.fwd | База данных имен для обычных запросов. Проход может быть и иным, он указывается в named.boot. |
| /usr/local/domain/named.rev | База данных сервера имен для запросов в IN-ADDR.ARPA. Замечание о проходе в предшествующем пункте справедливо и здесь. |
| /usr/local/domain/named.ca | База данных сервера имен для инициализации кэша. Замечание о проходе для named.fwd справедливо и здесь. Смотри также документ RFC-1033. Содержимое файла можно прочитать с помощью процедуры . |
Файл /etc/passwd содержит записи аутентификационных параметров пользователей. Каждая запись содержит 7 полей. В первом поле записано имя пользователя (LOGIN ID) в представлении ASCII. Второе поле содержит зашифрованный пароль пользователя. Шифрование осуществляется с добавлением символов, что делает обратную дешифровку невозможной. Причем одно и то же слово при таком методе может быть зашифровано различным способом. Третье поле является числовым номером пользователя (UID). В четвертом поле записывается код группы пользователей, к который принадлежит данный клиент. Пятое поле содержит комментарий администратора. В шестом поле хранится имя базового каталога пользователя. В заключительном поле записывается имя командного интерпретатора, который будет использоваться по умолчанию. В новейших версиях UNIX файл /etc/passwd содержит только "x" во втором поле записи для каждого пользователя, что указывает на использование файла /etc/shadow, где в зашифрованном виде содержатся пароли пользователей. Доступ к этому файлу имеет только администратор. Информация о членах групп пользователей хранится в файле /etc/group/.
Файл /usr/lib/aliases используется для создания почтовых ящиков, которым не соответствуют какие-либо аккоунты. Здесь прописываются псевдонимы, которым система пересылает поступающие почтовые сообщения. Строка переадресации в этом файле имеет форму:
alias: имя_пользователя или
alias: имя_пользователя_1, имя_пользователя_2, ..., имя_пользователя_N.
В первом случае вся почта приходящая alias переадресуется пользователя с указанным именем. Во втором - всем пользователям, имена которых представлены в списке. Если список не умещается в одной строке, перед вводом "возврата каретки" следует напечатать символ "/". В качестве аккоунтов могут использоваться как локальные так и стандартные почтовые адреса. Для особо длинных списков можно ввести специальную строку в файл /usr/lib/aliases:
authors:":include:/usr/local/lib/authors.list", где authors - псевдоним, а authors.list - файл, содержащий список адресатов, кому следует переслать сообщение.
Наиболее мощной и по этой причине наиболее опасной возможностью файла псевдонимов является переадресация входной почты программе, указанной в псевдониме. Когда первым символом имени аккоунта в псевдониме является вертикальная черта (|), то управление будет передано программе, чье имя следует за этим символом, а входные почтовые сообщения будут передаваться этой программе, например строка:
listserv: "|/usr/local/bin/listserv -l"
обеспечит пересылку почты программе listserv, как если бы исполнялась команда cat mailfile|listserv -l. Эта техника используется для интерпретации содержимого поля subject или тела сообщения в качестве команд управления подписными листами.
Файл named.boot, который служит для инициализации сервера имен, имеет следующую структуру. Строки, начинающиеся с точки с запятой являются комментариями. Строка sortlist определяет порядок, в котором выдаются адреса сервером, если их число в отклике превышает 1. Запись directory, описывает положение информационных файлов (имя проход/каталога). Строка cashe, служит для инициализации кэша сервера имен с использованием файла named.ca. Этот также как и другие файлы должны находиться в каталоге, указанном в записи directory. Записи primary указывают, в каких файлах размещена информация таблиц соответствия имен и IP-адресов. Последняя запись primary содержит информацию для локальной ЭВМ. В записях secondary специфицируется данные, которые должны считываться с первичного сервера и из локальных файлов.
В файле named.local содержится локальный интерфейс обратной связи сервера имен. Файл включает в себя только одну запись SOA (Start of Authority) и две ресурсных записи. Запись SOA определяет начало зоны. Символ @ в начале первого поля записи задает имя зоны. Четвертое поле этой записи содержит имя первичного сервера имен данного субдомена, а следующее поле хранит имя администратора, ответственного за данный субдомен (его почтовый адрес). Запись SOA включает в себя список из 5 чисел, заключенный в скобки.
Версия или серийный номер. Первое число в списке увеличивается каждый раз при актуализации файла. Вторичные серверы имен проверяют и сравнивают номер версии файла первичного сервера с имеющимся у них кодом, для того чтобы определить, следует ли копировать базу данных DNS.
Время обновления (refresh time). Определяет время в секундах, задающее период запросов вторичного DNS к первичному.
Время повторной попытки. Задает время в секундах, когда вторичный сервер имен может повторить запрос в случае неудачи предыдущего.
Время истечения пригодности (expiration time). Верхний предел временного интервала в секундах по истечении которого база данных вторичного DNS считается устаревшей без проведения актуализации.
Минимум. Значение по умолчанию для таймера TTL для экспортируемых ресурсных записей.
Файл /etc/hosts.equiv позволяет составить список ЭВМ, объединенных в группу. Пользователь, находящийся в одной из ЭВМ этой группы, может установить связь с другой, не вводя своего пароля. Понятно, что применение этого метода входа, предоставляя некоторые удобства, создает и определенные угрозы с точки зрения сетевой безопасности.
Файл .rhosts, который размещается в корневом каталоге пользователя, позволяет ему описать список ЭВМ, куда он имеет доступ. При этом появляется возможность войти из данной ЭВМ в любую из названных машин без ввода пароля. Замечания об использовании файла hosts.equiv в полном объеме справедливы и в данном случае.
Если к ЭВМ подключены модемы, необходимо применение так называемого dialup-пароля. Удаленный пользователь помимо своего ID и пароля должен ввести еще и dialup-пароль, который является общим для всех работающих на данной ЭВМ. Если все три параметра аутентификации корректны, доступ будет разрешен. При ошибке в любом из трех компонентов ЭВМ попросит повторить их ввод, не указывая, где совершена ошибка. Файл /etc/dpasswd является исполняемым и может реализовать ряд опций.
a [список] характеризует список терминалов, который добавляется к /etc/dialups.Пользователь при входе с такого терминала должен будет ввести пароль dialup. Элементы в списке заключаются в кавычки и разделяются пробелами или запятыми.
d [список] определяет список терминалов, которые должны быть удалены из /etc/dialups и пользователю будет не нужно в будущем вводить пароль dialup при входе с этих терминалов.
r [список] меняет login shell на /bin/sh для каждого из пользователей, перечисленных в списке.
s [shell] модифицирует запись в файле /etc/d_passwd или добавляет новую запись.
u [список] создает новое ядро (shell) для имен, указанных в списке. Добавляются записи в etc/d_passwd для нового ядра, а пароль работает для всех пользователей из списка, если не оговорено обратного.
x [shell] удаляет shell и пароль из файла /etc/d_passwd
Причины циклов пакетов и осцилляции маршрутов
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Для рядового пользователя информация данного раздела не может представлять никакого интереса. Некоторые продвинутые пользователи иногда могут обратить внимание на то, что программа traceroute начинает (вместо нормального отображения пути до цели) выдавать попеременно имена двух соседних узлов. Это может позабавить, если конечно не влияет на решение пользователем его текущих задач. Но в любом случае вмешаться и исправить что-либо он не в силах. О причинах такого поведения сети можно прочесть в разделах, посвященных вопросам маршрутизации.
Начнем с локальных сетей. В разделе о мостах , там где говорилось об алгоритме “расширяющееся дерево” отмечалась недопустимость того, чтобы две ЭВМ в локальной сети могли соединяться друг с другом различными путями. Здесь подразумевается соединение через систему мостов, повторителей/концентраторов и переключателей. Такого рода соединение через маршрутизаторы допустимо, но и там следует к этому относиться с определенной осторожностью. Рассмотрим фрагмент сети, изображенный на рис. 5.4.1.
Рис. 5.4.1. Пример ошибочной топологии локальной сети
Пакеты от машины 1 через концентратор 1 и 2 попадут в концентратор 2, эти же пакеты попадут туда через мост. В результате возникнет встречное кольцевое движение идентичных пакетов. Кроме того, переключатели и мост попытаются разобраться с этим безобразием и начнут посылать широковешательные пакеты, чтобы выяснить с каким из портов на самом деле связаны эти ЭВМ. Они от рождения убеждены, что одна и та же ЭВМ может быть доступна только через один порт. Таким образом, всплески загрузки сети, особенно широковещательной, должны привлекать внимание администратора. В данном примере, если система переключателей и мостов не поддерживает алгоритма “расширяющееся дерево”, администратор сам должен разорвать эту кольцевую структуру.
Зацикливание пакетов возможно также при использовании внутреннего протокола маршрутизации IGRP, где некорректный выбор параметра вариация приводит к тому, что система при распределении потоков по нескольким направлениям воспринимает путь “назад”, как вполне приемлемый.
Еще один вариант циклов пакетов возникает при использовании маршрутов по умолчанию (более детально это описано в разделе, посвященном маршрутизации ). Так при наличии канала между сетями А и Б внешние маршрутизаторы этих сетей сконфигурированы так, что в сети А пакет адресованный не А, направляется в Б, а в сети Б все пакеты с местом назначения не Б, направляются сети А. Такая конфигурация возможна и она будет работать нормально до тех пор, пока в одной из сетей не появится пакет с ошибочным адресом, не соответствующем ни сети А, ни Б. Такой пакет будет двигаться между сетями А и Б до тех пор пока не выработает свой ресурс по TTL.
Похожие проблемы возникают при реализации, например, протокола маршрутизации RIP (см. раздел ), что сильно замедляет там процедуру установления равновесного маршрута.
Протоколы маршрутизации работают с системами, где имеют место огромные задержки. И как всякая система управления с задержанной обратной связью такие системы склонны к осцилляциям. Допустим некоторый узел, оценив метрику нескольких маршрутов, принял решение перейти на новый маршрут. Если он это сделает, об этом окружающие маршрутизаторы узнают с заметной задержкой и соответствующим образом изменят свои оценки метрик фрагментов пути. Когда (снова с задержкой) исходный маршрутизатор получит информацию об этих оценкам, может случится, что старый маршрут окажется предпочтительнее нового, и все начнется сначала.
Рассмотренные в данном разделе относительно экзотические явления (кроме примера из локальных сетей, здесь имеет место не экзотика, а стихийное бедствие) встречаются не так часто, но администратор сети должен принимать в расчет и такие возможности. Любой из упомянутых эффектов может сильно ухудшить эксплуатационные параметры сети, а то и вовсе вывести ее из строя.
Применение го режима сетевого адаптера для целей диагностики
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Использование 6-го режима работы сетевого интерфейса предоставляет необычные возможности администратору и таит в себе немалые угрозы в случае использования его хакером. Как известно практически любая сетевая карта имеет 6 режимов работы. Обычно она работает в 3-ем режиме, воспринимая все пакеты адресованные ей, а также широковещательные и мультикастинг пакеты. В 6-ом же режиме карта пытается принять все пакеты, следующие по сегменту, вне зависимости от адреса места назначения. Если позволяет загрузка и быстродействие сетевого интерфейса, будут восприняты и обработаны все пакеты, следующие по сегменту, к которому подключена ЭВМ, работающая в 6-ом режиме. Именно по этой причине желательно при осуществлении авторизации использовать шифрованный обмен. В противном случае хакер, чья ЭВМ подключена к сетевому сегменту, может получить все пароли, в том числе и привилегированных пользователей. Если шифрование обмена при авторизации недоступно, привилегированные (root) пользователи должны ограничиться работой через консоль. Выполнение привилегированных операций с удаленной ЭВМ не желательно, так как может привести к раскрытию системного пароля.
6-ой режим позволяет проанализировать распределение пакетов по коду протокола, по адресам отправителей или получателей. Определить парциальные значения трафиков отдельного пользователя для различных видов услуг. Некоторые виды из перечисленных данных можно получить из MIB маршрутизатора (например, Accounting database в случае маршрутизаторов CISCO), но 6-й режим предоставляет большую гибкость и возможности.
6-ой режим позволяет проанализировать распределение пакетов по коду протокола, по адресам отправителей или получателей. Определить парциальные значения трафиков отдельного пользователя для различных видов услуг. Некоторые виды из перечисленных данных можно получить из MIB маршрутизатора (например, accounting database в случае маршрутизаторов Cisco), но 6-й режим предоставляет большую гибкость и возможности.
К сожалению, данная методика применима лишь к пакетам, проходящим через сегмент, к которому подключена ЭВМ, работающая в 6-ом режиме (см. рис. 5.3.1).
Рис. 5.3.1.
Выделенная ЭВМ может полностью отслеживать трафик из зоны сети “C” и лишь транзитный поток пакетов для зон “A” “B” и “D” (например, из зоны А в зону D). Пакеты внутреннего трафика для зон А, В и D не доступны.
Сетевая диагностика с применением протокола SNMP
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Обслуживание и диагностирование больших многосегментных, многопротокольных сетей, размещенных на большой территории, а в некоторых случаях и в нескольких городах (например, корпоративные сети типа Интранет), представляет собой тяжелую проблему.
Так как сеть может быть построена с использованием различных физических сред и протоколов, наиболее привлекательным, если не единственным, средством диагностики представляется протокол snmp, который служит для целей управления в ISDN, X.25, FDDI, ATM, TCP/IP и других сетях. Протокол SNMP (std15, RFC-1448, -1592, -1901, 1902-1907, 1908-1910) использует управляющую базу данных mib (RFC-1213, -1158, -1792, -1042; std16, std17), доступ к которой определяется администратором локальной сети или конкретной ЭВМ (ссылки, выделенные полужирным шрифтом, являются стандартами Интернет). Для того чтобы база данных была доступна, необходимо наличие snmp-демона с режимом свободного доступа (поле community = public). Рассмотрим сеть, изображенную на рис. 4.1.1.
Рис. 4.1.1. Пример диагностируемой сети
Для диагностики сегмента, непосредственно связанного с ЭВМ-тестером, можно использовать режим 6 Ethernet-интерфейса ЭВМ-тестера. Этот режим, при котором принимаются все пакеты, следующие по сегменту, позволяет регистрировать распределение пакетов по адресам отправителя и получателя, протоколам, длинам пакетов и т.д.. Запуская определенные программы на ЭВМ 1 или 2 (сегмент С-1), можно получить исчерпывающую информацию о состоянии сегмента. Этот способ диагностики не пригоден для сегментов, к которым подключены ЭВМ 3 (сегмент С-2), 4 и 5 (сегмент С-3). В случае, если все ЭВМ сети поддерживают протокол tcp/ip, возможно применение для целей диагностики протокола icmp (RFC-1256, -1788, -1885, -792). Этот протокол также как и snmp пригоден для диагностики не только локальной сети но и каналов Интернет. Если использовать icmp не только для трассировки маршрутов, но и для измерения процента испорченных пакетов, можно получить весьма полезную информацию, а при длинных сегментах зарегистрировать ухудшение качества сегмента при подключении слишком большого числа ЭВМ.
Такая техника может прогнозировать ухудшение пропускной способности канала при подключении дополнительных ЭВМ. Но применение icmp ограничено ЭВМ, поддерживающими протоколы Интернет, да и получаемые данные весьма ограничены.
Следует иметь в виду, что в многопротокольных средах структуры MIB могут заметно отличаться, варьируется несколько и формат SNMP-пакетов. В настоящее время существует достаточно большой выбор коммерческих программ сетевой SNMP-диагностики (их цены лежат в диапазоне 5-45 тыс. дол.). Особую ценность представляют аппаратно-программные комплексы (15-55 тыс. дол.), которые способны диагностировать состояние оборудования и кабельных сегментов. К сожалению, для отечественных пользователей они по причине цены практически недоступны.
Сеть ИТЭФ, которая была зарегистрирована одной из первых в качестве узла Интернет в 1991 году, в настоящее время содержит более 400 ЭВМ при суммарной длине кабельных сегментов около 10 км и обслуживается 6 сотрудниками. В сети используются протоколы TCP/IP, Novell, Arcnet и др.. Проблема диагностики такой сети достаточно актуальна. Мы сначала использовали традиционные программные средства типа ping, traceroute, netstat, arp, snmpi, dig (venera.isi.edu/pub), hosts, nslookup, ifconfig, ripquery, поставляемые со многими сетевыми пакетами. Позднее пытались адаптировать общедоступные диагностические средства типа: netwatch (windom.ucar.edu), snmpman (http:// www.smart.is/pub/mirror-indstate/snmp), netguard (oslo-nntp,eunet.no/pub/msdos/winsock/apps), ws_watch (bwl.bwl.th-harmstadt.de/windows/util). Среди наиболее часто встречающихся проблем: разрывы кабельных сегментов, несанкционированное использование IP-адресов, некачественное питание сетевого оборудования, отказы тех или иных устройств.
Не все ЭВМ имеют активные SNMP-резиденты, это происходит по причине экономии оперативной памяти или по соображениям безопасности. Еще меньше snmp-агентов, доступных в режиме public (поле SNMP-пакета community; формат пакетов описан, например, в книге Семенова Ю.А. "Протоколы и ресурсы Интернет", Москва, "Радио и связь", 1996).
Но для контроля ситуации достаточно иметь по одному активному SNMP-резиденту на каждом из кабельных сегментов. При этом не обязательно ставить их в общедоступный режим, можно использовать для получения диагностической информации и пароль.
При написании диагностической программы не нужно пытаться считывать все переменные и таблицы MIB. База данных весьма велика и для целей диагностики не все ее записи представляют интерес. При написании нашей диагностической программы были отобраны 35 переменных (ниже приводится сокращенный список):
| interface.iftable.ifentry.ifinucastpkts | Число полученных обычных пакетов; |
| interface.iftable.ifentry.ifinnucastpkts | Число полученных широковещательных и мультикаст-пакетов; |
| interface.iftable.ifentry.ifinerrors | Число ошибок при приеме пакетов; |
| interface.iftable.ifentry.ifoutucastpkts | Число посланных обычных пакетов; |
| interface.iftable.ifentry.ifinnucastpkts | Число посланных широковещательных и мультикаст-пакетов; |
| interface.iftable.ifentry.ifinunknownprotos | Число полученных пакетов с неизвестным кодом протокола; |
| ip.ipinreceives | Полное число ip-дейтограмм, включая полученные с ошибкой; |
| ip.ipinhdrerrors | Число входных ip-дейтограмм с ошибками в заголовке пакета, включая ошибки контрольной суммы, ttl и т.д. |
| ip.ipinaddrerrors | Число полученных пакетов с ошибкой в адресе; |
| ip.ipinunknownprotos | Число входных ip-дейтограмм, с кодами протоколов, которые не поддерживаются данной системой; |
| ip.ipreasmreqds | Число полученных фрагментов, которые требуют сборки; |
| ip.ipindelivers | Число ip-дейтограмм, принятых без ошибок (включая icmp); |
| icmp.icmpinmsgs | Число полученных icmp-пакетов;(другие 10 контролируемых переменных icmp-группы из соображений экономии места из списка исключены); |
| udp.udpindatagrams | Число принятых udp-дейтограмм; |
| udp.udpoutdatagrams | Число отправленных udp-дейтограмм; |
| udp.udpnoports | Полное число udp-дейтограмм, для которых не существует приложения для указанного номера порта; |
| udp.udpinerrors | Число udp-дейтограмм, которые не могут быть доставлены не по причине отсутствия приложения по указанному порту; |
| tcp.tcpinsegs | Число принятых tcp-сегментов; |
| tcp.tcpoutsegs | Число отправленных TCP-сегментов; |
| tcp.tcpretranssegs | Число tcp-сегментов с повторной пересылкой; |
| tcp.tcpoutrsts | Число сегментов с флагом rst=1; |
| tcp.tcpinerror | Число tcp-сегментов, полученных с ошибкой. |
Выбор определялся тем, что именно эти переменные варьируются динамически в течение суток. Ставилась задача исследования временных вариаций потоков в заданном сегменте и выработки критериев для диагностики потенциально опасных ситуаций. Измерения проводились каждые полчаса в течение недели.
Многие переменные базы MIB не меняются или меняются незначительно, но определяют режим работы и состояние ЭВМ-сервера. Так переменная snmpinbadcommunityuses {snmp 5} может сообщить о попытках несанкционированного доступа к базе mib. Переменные snmpintoobigs {snmp 8}, snmpingenerrs {snmp 12} или ifadminstatus {ifentry 7} и многие другие характеризуют текущее состояние системы и длительное их отслеживание чаще всего не дает полезной информации. Другие переменные, например, ipnettomedianetaddress {ip 22}, ipnettomediaentry или iproutedest и т.д. полезно контролировать при серьезных сбоях и сравнивать их с эталонными значениями. Некоторые переменные важны при анализе эффективности системы, например, ipfragcreate {ip 19} или ipfragfails {ip 18}, последняя переменная говорит о том, сколько встретилось пакетов с флагом, запрещающим фрагментацию, в условиях, когда она необходима, что может свидетельствовать, если ipfragfails велико, о неверном выборе MTU.
Рассмотрим средние значения некоторых переменных за сутки. Так переменные ip.ipinreceives=1379552, ifentryifinucastpkts=1278232, ifentry.ifinnunicastpkts=5083 характеризуют средний поток пакетов на входе сетевого интерфейса. Видно, что широковещательные и мультикастинг-пакеты составляют малую долю потока, что и следует ожидать. Большой поток пакетов типа nonunicast обычно говорит о неисправности в сети. Величины ifentry.ifoutunicastpkts=1369809 и ifentry.ifoutnunicastpkts=90 характеризуют выходной поток пакетов, соотношение обычных и nonunicast-пакетов и здесь нормально. Сравнимое их значение говорило бы о неисправности сетевого интерфейса данной ЭВМ или о порче сетевого программного драйвера. Блок переменных ip.ipinhdrerrors=8, icmp.icmpouterrors=45, icmp.icmpoutdestunreachs=22 и ifentry.ifinunknownprotos=81 указывает на число сбоев в сети, если соотнести эти цифры с входным и выходным потоками пакетов можно сделать вывод о благополучии в данном кабельном сегменте, во всяком случае на протяжении данных суток.
Такие ошибки возможны из- за всплеска шумов или наводок (например, по сети переменного тока). Определенное беспокойство может вызвать значение icmpoutdestunreachs, но это может быть результат работы программы ping или traceroute для недоступного узла или опечатка в IP-адресе. Переменная icmp.icmpinsrcquenchs=19 весьма важна, так как она отмечает случаи перегрузки. В данном случае таких ситуаций за сутки случилось мало. Отслеживая эту переменную для разных ЭВМ, можно выявить слабые элементы в сети и скорректировать их параметры (например, увеличить буферную память). Переменные tcp.tcpinsegs=762696, tcp.tcpoutsegs=803676 и tcp.tcpretranssegs=3554 говорят о потоках tcp-пакетов (главного транспортного средства Интернет). Число tcpretranssegs характеризует надежность и правильность настойки параметров сети, чем меньше это число, тем лучше. udp.udpindatagrams=378119, udp.udpoutdatagrams=59429 указывают на входной и выходной потоки UDP-дейтограмм (сравните с потоками TCP-сегментов). Запись в MIB udp.udpnoports является важным диагностическим показателем. Переменные, регистрирующие число тех или иных ошибок, неупомянутые в этом абзаце, оказались равными нулю. Количество пакетов snmp в точности совпадает с их числом, посланным и полученным данной программой-тестером, что говорит об отсутствии какой-либо другой SNMP-активности. Контролировать это время от времени также полезно из соображений сетевой безопасности.
Рис. 4.1.2. Вариации tcpinsegs и udpindatagrams в течение недели
Для защищенных систем доступ к snmp-резиденту в пакетах должно использоваться поле community = паролю. Но даже эта мера не может блокировать вторжение со стороны LAN, так как в результате перехвата snmp-пакетов пароль может быть открыт. При написании таких программ нужно учитывать версии MIB, используемые анализируемыми узлами, а также тот факт, что snmp-отклики могут иметь для разных операционных сред. Рассмотрим, как варьируются некоторые из перечисленных переменных в течении суток и недели.
На рис. 4.1. 2 видны спады сетевой активности в ночное время и в выходные дни. Левый край диаграммы соответствует понедельнику 9 сентября (ночь), правый - понедельнику, но уже следующей недели. На рис. 4.1.3 приведена диаграмма вариации некоторых переменных за сутки. Сетевая активность захватывает период от 10 часов утра и спадает почти до нуля к 9-10 вечера, хотя бывают и исключения. Для эффективной интерпретации временных зависимостей можно использовать программу мониторинга last (или любой ее эквивалент), которая позволяет отслеживать появление новых пользователей или процессов (например, ftp). Фрагмент распечатки, выданной программой last на ЭВМ, snmp-резидентом которой пользовалась наша программа, приведен ниже.
| ms977 | pts/0 | vitep5.itep.ru | tue sep 10 23:49 - 00:16 (00:27) |
| ms977 | pts/2 | vitep5.itep.ru | tue sep 10 22:20 - 23:46 (01:26) |
| ostrouh | pts/0 | athene.itep.ru | tue sep 10 18:30 - 18:43 (00:13) |
| titovich | pts/0 | athene.itep.ru | tue sep 10 18:30 - 18:30 (00:00) |
| vita | pts/3 | athene.itep.ru | tue sep 10 14:55 - 15:56 (01:00) |
| checho | pts/12 | itep05.itep.ru | tue sep 10 13:35 - 13:37 (00:01) |
| fomin | pts/10 | hydra.ifh.de | tue sep 10 13:16 - 13:22 (00:06) |
| checho | pts/7 | itep05.itep.ru | tue sep 10 13:09 13:16 (00:07) |
| illarion | pts/7 | xt07.itep.ru | tue sep 10 12:45 12:45 (00:00) |
| vita | pts/9 | athene.itep.ru | tue sep 10 11:55 13:03 (01:07) |
| bely | pts/12 | pcx01.itep.ru | tue sep 10 11:49 12:02 (00:13) |
| vita | pts/13 | athene.itep.ru | tue sep 10 11:49 11:52 (00:03) |
| efre | pts/4 | pcx10.itep.ru | tue sep 10 10:05 10:24 (00:18) |
| checho | pts/0 | 169-151-147.ipt. | tue sep 10 05:07 05:09 (00:01) |
| ssemen | ftp | clotho.itep.ru | mon sep 09 20:14 20:15 (00:01) |
| ssemen | ftp | clotho.itep.ru | mon sep 09 19:34 19:35 (00:00) |
| ostrouh | pts/3 | athene.itep.ru | mon sep 09 19:20 19:40 (00:20) |
| ozero | pts/0 | athene.itep.ru | mon sep 09 19:13 22:44 (03:30) |
| ozero | pts/5 | itep05.itep.ru | mon sep 09 18:05 18:32 (00:27) |
| olyalin | pts/6 | itep05.itep.ru | mon sep 09 16:19 16:27 (00:08) |
| efre | ftp | pcx10.itep.ru | mon sep 09 16:14 16:15 (00:00) |
| mara | pts/1 | hpl3pur2.cern.ch | mon sep 09 16:02 16:27 (00:24) |
| mara | pts/1 | hpl3pur2.cern.ch | mon sep 09 15:50 15:54 (00:04) |
| itep977 | pts/2 | 1mars.itep.ru | mon sep 09 15:22 15:23 (00:00) |
| ozero | pts/20 | aix0.itep.ru | mon sep 09 15:06 15:36 (00:29) |
| ozero | pts/12 | itep05.itep.ru | mon sep 09 14:56 14:56 (00:00) |
| galy | pts/16 | athene.itep.ru | mon sep 09 14:27 14:31 (00:03) |
| bely | pts/15 | vitep5.itep.ru | mon sep 09 14:09 10:36 (20:27) |
| sed | pts/5 | pcx11.itep.ru | mon sep 09 14:01 14:01 (00:00) |
| kisel | pts/1 | vxitep.itep.ru | mon sep 09 13:59 15:22 (01:22) |
| ozero | pts/12 | itep05.itep.ru | mon sep 09 13:53 14:55 (01:02) |
| ozero | pts/2 | 193.148.166.214 | mon sep 09 13:40 13:41 (00:00) |
| ozero | pts/8 | 193.148.166.214 | mon sep 09 13:32 13:37 (00:04) |
| vita | pts/9 | aix0.itep.ru | mon sep 09 13:32 13:32 (00:00) |
| vita | pts/2 | vitep5.itep.ru | mon sep 09 13:32 13:32 (00:00) |
| checho | pts/3 | itep05.itep.ru | mon sep 09 13:11 13:12 (00:00) |
| efre | pts/3 | pcx10.itep.ru | mon sep 09 12:12 12:23 (00:10) |
| kisel | pts/2 | vxitep.itep.ru | mon sep 09 12:11 12:43 (00:32) |
| checho | pts/6 | itep05.itep.ru | mon sep 09 12:02 12:03 (00:00) |
| kisel | ftp | pcx11.itep.ru | mon sep 09 11:42 11:43 (00:00) |
| kisel | ftp | ion04.cern.ch | mon sep 09 10:59 11:06 (00:06) |
| galy | pts/1 | athene.itep.ru | mon sep 09 10:57 10:58 (00:00) |
| titovich | pts/4 | athene.itep.ru | mon sep 09 10:20 10:21 (00:01) |
| korol | pts/0 | 193.124.225.174 | mon sep 09 05:20 05:57 (00:37) |
Первая колонка содержит имена пользователей, вторая - тип задачи (PTS/n - удаленный доступ с терминала с номером n), далее следует имя узла или его IP-адрес, с которого осуществлен доступ, дата, время работы и длительность сессии. Как правило, сессии типа FTP или NFS дают большую сетевую загрузку. Нужно учитывать возможность запуска FTP-сессии или другой информационно-емкой процедуры после входа в систему с помощью telnet (PTS). Рассматривая эту распечатку совместно с временными зависимостями переменных базы данных MIB, можно интерпретировать результаты, определить, какая из сессий загружает данный сегмент сети более других. Рассмотрев, например, результаты работы программы last и рис. 5.1.3а, можно видеть, что максимум в период с 18 до 20 часов связан с активностью пользователей ozero, ostrouh и ssemen. Но даже в отсутствии сессий, зафиксированных last, можно наблюдать заметную сетевую активность. Это может быть доставка почтовых сообщений или зондирование сервера пакетами-роботами со стороны удаленных www-клиентов.
Рис. 5.1.3(а, б). Временная зависимость ifinucastpkts, ifoutucastpkts и ifinnucastpkts
По горизонтальной оси отложено время от начала суток. Кривая, отмеченная треугольниками, соответствует правой шкале диаграммы, это справедливо для всех последующих рисунков. Входной и выходной потоки через данный интерфейс практически равны. На рис. 5.1.4(а,б) показана вариация со временем входных потоков IP-дейтограмм (ipinreceives, ipinreasmreqd и ipindelivers). Пик в правой части рис. 5.1.4а (19:00 - 20:00) показывает, что поток ipinreceives превосходит поток ipindelivers почти в два раза. Можно было бы предположить, что разница определяется числом ошибок, но так как по времени это совпадает с пиком в диаграмме ipinreasmreqd, различие следует интерпретировать, как необходимость сборки сообщений. Сопоставление значений ipinreceives, ipinreasmreqd и ipindelivers подтверждает такое предположение. Если такого рода ситуация в сети повторяется часто, нужно просмотреть корректность выбора mtu для объектов, участвующих в данном обмене.
Для областей вне указанного пика значения ipinreceives и ipindelivers почти совпадают, что говорит о низком уровне ошибок (это подтверждается и значением потока icmpouterrors, icmpoutdestunreachs и ifinunknownprotos.
На рис. 5.1.5(а и б) показаны суточные вариации потоков udp-дейтограмм, а на рис. 5.1.6(а и б) представлены аналогичные временные зависимости для TCP-сегментов. Если входные и выходные потоки UDP-дейтограмм отличаются друг от друга временами в несколько раз (что вполне естественно), то входные и выходные потоки TCP-сегментов почти не отличаются (ведь каждому посланному пакету в этом протоколе должен соответствовать пакет-подтверждение).
Рис. 5.1.4(а,б). Временные зависимости входных потоков IP-дейтограмм (ipinreceives, ipinreasmreqd и ipindelivers)
Рис. 5.1.5(а,б). Суточные вариации потоков UDP-дейтограмм.
Рис. 5.1.6(а, б). Суточные вариации потоков TCP-сегментов
