Как определить доступность вычислительной системы по сети

Как определить доступность вычислительной системы по сети?

Как определить доступность вычислительной системы по сети?
За ранее спасибо!!

Голосование за лучший ответ

пропинговать

SN@KEПрофи (590) 11 лет назад

хотя не всегда определяет доступность иногда сервер может отправлять пакеты на на пинг запросы и при этом не давать доступ к данным т. е. будет отсутствовать доступность. Тут уже зависит от самой системы

внезапно, но бывает и строго наоборот (и гораздо чаще) удаленный сервер режет все icmp пакеты и принимает соединения исключительно на определенных портах

Похожие вопросы

5 Диагностика локальных сетей и Интернет

а. Администраторы сети, которые формируют сетевую среду (подавляющее меньшинство).
б. Пользователи сети, кто вынужден эту среду осваивать и в ней жить.

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

«Почему не работает электронная почта?» (хотя известно, что вторые сутки за неуплату обесточен весь вычислительный центр). Бывают и сложные: «Как уменьшить задержку отклика, если канал перегружен?»

Число компьютерных сетей увеличивается лавинообразно, растет число больших (>10 ЭВМ) и многопротокольных сетей (802.11, 802.16, 802.17 и т.д.). По мере увеличения сети усложняется ее обслуживание и диагностика, с чем сталкивается администратор при первом же отказе. Наиболее сложно диагностировать многосегментные сети, где ЭВМ разбросаны по большому числу помещений, далеко отстоящих друг от друга. По этой причине сетевой администратор должен начинать изучать особенности своей сети уже на фазе ее формирования и готовить себя и сеть к будущему ремонту. При возникновении нештатной ситуации администратор должен суметь ответить на ряд вопросов:

связана проблема с оборудованием или программным обеспечением;
отказ вызван повреждением программы, неверным выбором конфигурации или ошибочными действиями оператора.

Документирование сети

Начинать надо с исчерпывающего документирования аппаратной и программной части сети. Администратор всегда должен иметь под рукой схему сети, отвечающую реальному положению на текущий момент, и подробное описание конфигурации программного обеспечения с указанием всех параметров (физические и IP-адреса всех интерфейсов, маски, имена ЭВМ, маршрутизаторов, значения MTU, MSS, TTL и других системных переменных, типовые значения RTT и других параметров сети, измеренных в разных режимах.).

В пределах локальной сети поиск неисправности возможен с помощью временного деления ее на части. По мере интеграции сети в Интернет такие простые меры становятся недостаточными или недопустимыми. Но не следует пренебрегать такими простыми средствами, как проверка отсутствия обрыва или закоротки сетевого кабеля. Нужно помнить, что сопротивление сегмента толстого коаксиального кабеля не должно превышать 5 Ом, тонкого — 10 Ом, а скрученные пары не должны иметь сопротивление больше 11,8 Ом (22AWG) и соответственно 18,8 Ом (24AWG) из расчета на 100 м.

Ниже будет предполагаться, что сеть на физическом уровне использует стандарт Ethernet, а для межсетевой связи протокол TCP/IP (Интернет). Этим перечнем разнообразие сетевых сред не исчерпывается, но многие приемы и программные диагностические средства с успехом могут использоваться и в других случаях. Большинство из рассматриваемых программ работают в среде UNIX, но существуют их аналоги и для других ОС.

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

При переходе на стандарты передачи 1 и тем более 10Гбит/с возникают дополнительные проблемы. Обработка таких потоков с целью диагностики может существенно замедлить работу машины. Аналогичные проблемы возникают при построении IPS/IDS-систем, а также антивирусных программ. Впрочем эта проблема становится тяжелой также из-за фантастического роста числа сигнатур (миллионы) атак и вирусов. Одним из способов решения задачи является привлечение аппаратных средств, а также организация нескольких потоков обработки, что достаточно реально для машин с несколькими процессорами. Смотри также Monitoring 10 Gigabit Networks.

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

Программные средства диагностики

В Интернет имеется немало общедоступных специализированных диагностических программных продуктов: Etherfind, Tcpdump (lss:os2warez@merlin.itep.ru ftp.ee.lbl.gov/tcpdump.tar.Z, для 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. Существует довольно большое число модификаторов программы (опций). К сожалению для рядовых пользователей программа не доступна — требуются системные привилегии. Описание применения программы можно найти по указанному выше адресу, а также в [10]. Другой полезной служебной программой является 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.

Диагностические команды ОС

Для того чтобы диагностировать ситуацию в сети, необходимо представлять себе взаимодействие различных ее частей в рамках протоколов TCP/IP и иметь некоторое представление о работе Ethernet [4]. Сети, следующие рекомендациям Интернет, имеют локальный сервер имен (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

Протокол ICMP используется в наиболее популярной диагностической программе 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 демоны

Конфигурация inetd определяется содержимым файла /etc/inetd.conf. Для ознакомления с содержимым файла достаточно с клавиатуры ввести команду:

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:
#
# Ftp and telnet are standard Internet services.

ftp stream tcp nowait root /usr/etc/wrapper.3.9.4/tcpd /usr/local/etc/ftpd -lio

Строки, начинающиеся с символа #, являются комментариями. В данном примере представлена одна информативная строка (их может быть много больше), характеризующая файловый обмен. Каждая строка в этом файле начинается с имени ресурса (в приведенном примере 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). Конфигурация 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

Authoritative answers can be found from (официальные данные могут быть получены от):

set type=ANY (запрос всей информации)
.
Non-authoritative answer:

Authoritative answers can be found from:

(Параметр preference характеризует степень предпочтения почтового сервера, чем он ниже — тем выше предпочтение.)

Authoritative answers can be found from:

set type=SOA (запрос параметров, зоны сервера имен, см. RFC-1034-35)
.
Non-authoritative answer (см. документы RFC-1034-35):

Authoritative answers can be found from:

Рассмотренный пример показывает, что DNS-сервер весьма важный объект узла, от него зависит скорость обслуживания запросов и надежность системы в целом. Именно по этой причине помимо основного любой узел имеет несколько вторичных DNS-серверов.

Программа dig функционально является аналогом nslookup, но в прикладном плане имеет определенные отличия, она снабжена рядом полезных опций (таблица 5.3):

Таблица 5.3 Опции программы dig

Ниже приведен пример использования команды dig для сервера имен узла DESY (Гамбург):

dig @vxdesy.desy.de ns
; > DiG 2.0 > @vxdesy.desy.de ns
; (3 servers found)
;; res options: init recurs defnam dnsrch
;; ->>HEADER ;; flags: qr rd ra; Ques: 1, Ans: 9, Auth: 9, Addit: 9
;; QUESTIONS:
;;., type = NS,
;; ANSWERS:

;; FROM: ns.itep.ru to SERVER: vxdesy.desy.de 131.169.30.46
;; WHEN: Thu Jul 25 12:07:54 1996
;; MSG SIZE sent: 17 rcvd: 429

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

le0: flags=863
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). Она имеет несколько полезных опций (возможны вариации для разных реализаций и ОС):

Ниже приведен пример исполнения команды arp , которая печатает имя объекта, его IP- и физический адреса (следует иметь в виду, что содержимое ARP-таблиц изменяется со временем, время хранения записи задается администратором сети):

Указанием на наличие ошибки в ARP-таблице может служить сообщение о недоступности или неизвестности ЭВМ при выполнении команд типа FTP или telnet. Такие сообщения возможны, например, при использовании одного и того же IP-адреса двумя ЭВМ. Все зависит от того, какая из машин успела «прописаться» в ARP-таблице раньше. Просматривая таблицу, администратор может заметить, что одному и тому же IP-адресу временами соответствуют разные физические адреса. Легальность адреса может быть проверена с помощью содержимого файла /etc/ethers. Первые три байта физического адреса характеризуют производителя интерфейса (см. Assigned Numbers, RFC-1700), что может помочь найти «IP-двойника». Если анализ ARP-таблицы не помог, попробуйте войти в ЭВМ, соответствующую подозрительному адресу, с помощью команды telnet. Если ЭВМ допускает удаленный доступ, характер входного сообщения поможет разобраться, что это за машина.

Применение NETSTAT

Одной из наиболее информативных команд является netstat (за исчерпывающим описанием опций и методов применения отсылаю к документации на ваше сетевое программное обеспечение). Эта команда может вам дать информацию о состоянии интерфейсов на ЭВМ, где она исполнена:

Name — имя интерфейса, если в этом поле стоит *, это означает, что интерфейс в состоянии down; Net/Dest — показывает IP-адрес сети или ЭВМ, куда интерфейс осуществляет доступ; Address — IP-адрес интерфейса; Ipkt — число принятых пакетов; Ierr — число ошибок при приеме пакетов; Opkts — число отправленных пакетов через данный интерфейс, Oerrs — число ошибок при отправке; Collis — число столкновений в сегменте Ethernet, зафиксированных интерфейсом; Queue — длина очереди пакетов, ждущих отправки. Программа nrtstat позволяет ознакомиться и с маршрутной таблицей:

Колонка место назначения указывает на конечную точку маршрута, колонка маршрутизатор — имя маршрутизатора, через который достижим адресат. Флаг «U» (Up) свидетельствует о том, что канал в рабочем состоянии. Флаг «G» указывает на то, что маршрут проходит через маршрутизатор (gateway). При этом вторая колонка таблицы содержит имя этого маршрутизатора или его адрес. Если флаг «G» отсутствует, ЭВМ непосредственно связана с указанной сетью. Флаг «D» указывает на то, что маршрут был добавлен динамически. Если маршрут связан только с конкретной ЭВМ, а не с сетью, он помечается флагом «H» (host), при этом первая колонка таблицы содержит его IP-адрес. Флаг «M» указывает на то, что маршрут был изменен с помощью сообщения о переадресации. Флаг говорит о том, что адресат достижим непосредственно.

Возможности netstat не ограничиваются локальной сетью или автономной системой, с помощью ее можно получить некоторую информацию об удаленных ЭВМ или маршрутизаторах. Например:

netstat -r 194.85.112.34

Это может быть полезно при экспресс диагностике внешних каналов связи, когда простого ping или traceroute оказалось недостаточно. Если возникло подозрение относительно маршрутизации пакетов, можно сначала проверить работает ли программа gated, для этого выдайте команду :

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

Во второй колонке данной выдачи указано время жизни пакетов (TTL) в секундах. Значение TTL в первых строках соответствует суткам (24x60x60=86400). IN в следующей колонке указывает на принадлежность к классу Интернет. В четвертой колонке проставлены указатели типов запроса. В пятой колонке идут названия серверов, IP-адреса ЭВМ и коды предпочтения (15, 200 и 210). Более подробно о возможностях этой команды можно ознакомиться в [11].

В последнее время появилось несколько комплексных (общедоступных) пакетов диагностики (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-обменов между двумя узлами (ftp.sgi.com, каталог sgi/src/ttcp или vgr.brl.mil ftp/pub/ttcp.c).

Перечисленные режимы работают в рамках протокола TCP, для исследования процессов, требующих UDP, следует использовать опцию -u. Существует множество других опций, обеспечивающих реализацию самых разнообразных режимов работы (см. [10] и справочные руководства на вашей ЭВМ).

При переходе сетей в гигабитный диапазон скоростей, в частности на 10Гбит/с, возникают трудности мониторинга состояния сети. Полезную информацию по этой проблеме можно найти в Monitoring 10 Gigabit Networks.

Конфигурация сети и режимы ее работы определяются системными переменными, которые задаются администратором сети. Имена этих сетевых переменных для разных ЭВМ и программных пакетов варьируются. Ниже будут перечислены основные переменные, определяющие работу 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.

Для изменения значений этих переменных необходимо иметь системные привилегии.

Методы оценки загрузки вычислительных узлов распределенной вычислительной системы Текст научной статьи по специальности «Компьютерные и информационные науки»

Текст научной работы на тему «Методы оценки загрузки вычислительных узлов распределенной вычислительной системы»

МЕТОДЫ ОЦЕНКИ ЗАГРУЗКИ ВЫЧИСЛИТЕЛЬНЫХ УЗЛОВ РАСПРЕДЕЛЕННОЙ ВЫЧИСЛИТЕЛЬНОЙ СИСТЕМЫ

Балансировка нагрузки является на сегодняшний день одним из наиболее используемых приемов повышения производительности распределенных вычислительных систем за счет оптимального распределения заданий между узлами вычислительной системы. Под термином «система балансировки нагрузки» будем понимать инструментальное средство, предназначенное для перенаправления пользовательских запросов на наименее загруженный узел распределенной вычислительной системы. Для пользователя присутствие такой системы должно быть прозрачным. Задача системы балансировки нагрузки заключается в распределении запросов пользователей между наименее загруженными вычислительными узлами распределенной системы с целью наиболее полного использования всех имеющихся ресурсов. Для выполнения этой задачи могут использоваться различные методы оценки загрузки вычислительного узла. Система балансировки нагрузки должна оперировать данными, которые содержат информацию о состоянии вычислительных узлов распределенной системы, а также правилами, заданными администратором. На основании этих данных или правил и принимается решение о перенаправлении запроса наименее загруженному узлу.

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

Все алгоритмы балансировки нагрузки можно разделить на две большие группы: пассивные и активные. К группе пассивных алгоритмов балансировки нагрузки относят те, которые работают с таблицей, содержащей сведения об обслуживаемых узлах, такие как тактовая частота процессора, количество оперативной памяти, пропускная способность внутренней шины. Для распределения запросов пользователей пропорционально производительности вычислительного узла в таблицу могут быть добавлены весовые коэффициенты. Таблица формируется до начала работы системы балансировки и почти не меняется в течение ее работы. Эти алгоритмы, в свою очередь, делятся на две группы: статические и динамические. Статические алгоритмы основаны на распределении запросов пользователя между вычислительными узлами по определенному правилу, которое устанавливается заранее и не меняется в процессе работы выполнения алгоритма. Простейшим примером такого алгоритма является алгоритм с циклической выборкой (Round robin).

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

Основным недостатком всех рассмотренных выше алгоритмов является отсутствие возможности автокорректировки их работы в процессе функционирования системы

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

Активные алгоритмы распределения нагрузки характеризуются тем, что система балансировки нагрузки постоянно отслеживает уровень нагрузки и доступность вычислительных узлов, которые она контролирует, с тем, чтобы на основании имеющейся информации в любой момент передать задание пользователя наименее загруженному узлу [1, 2]. Здесь можно выделить два метода получения информации о текущем состоянии вычислительного узла. Первый метод — это так называемый внешний мониторинг состояния вычислительных узлов распределенной системы, второй метод — внутренний мониторинг. Системы балансировки нагрузки, основанные на внешнем мониторинге, как и все системы балансировки, основанные на алгоритмах, которые были рассмотрены выше, имеют централизованную структуру и располагаются на одном узле распределенной вычислительной системы. Система балансировки централизованно собирает данные о состоянии всех вычислительных узлов распределенной системы. При проведении внешнего мониторинга система балансировки нагрузки рассчитывает время отклика вычислительного узла, для чего направляет на него служебный запрос и замеряет время ответа. Самый простой вариант такого метода — это использование ping-тестов по протоколу управления сообщениями Internet Control Message Protocol (ICMP). Использование служебных запросов протокола ICMP позволяет системе убедиться в готовности вычислительного узла и определить, сколько времени необходимо для передачи данных на вычислительный узел от системы балансировки нагрузки и обратно. Если система балансировки не получает отклика от вычислительного узла после нескольких последовательных запросов, то данный узел считается недоступным и исключается из списка доступных. Если время ответа узла значительно увеличивается, то это означает, что соответствующий узел перегружен, и система балансировки не передает ему запросы пользователя. Однако задержка в получении ответа может не зависеть от загрузки вычислительного узла. Здесь задержки может вносить среда передачи данных. Если нагрузка на сеть в распределенной системе неравномерна, то данные о загрузке узлов, основанные на времени ответа узла, могут быть сильно искажены.

Следующий метод реализации внешнего мониторинга основан на отправке служебных пакетов подконтрольным узлам с целью получения более детальной информации о загрузке вычислительного узла. Метод, основанный на ping-тестах по протоколу ICMP, диагностирует только стек протоколов IP. Протоколы верхних уровней не затрагиваются простым ping-тестом, и для получения данных о функционировании протоколов верхних уровней необходимо использовать более сложные запросы. Примером реализации этого метода внешнего мониторинга является метод, при котором система балансировки нагрузки устанавливает соединение с вычислительным узлом по протоколу TCP, для чего требуется осуществить обмен служебными сообщениями, состоящий из трех этапов. После установления TCP соединения система балансировки немедленно разрывает его, чтобы не занимать дополнительные ресурсы вычислительного узла. Нагрузка на стек TCP вычислительного узла оценивается по общему времени, необходимому на установление соединения с узлом. При этом серьезную нагрузку испытывает среда передачи данных, так как количество служебной информации, передаваемой по сети, существенно возрастает.

Следующим методом оценки загрузки вычислительного узла с использованием внешнего мониторинга является подход, позволяющий обеспечивать мониторинг времени отклика и готовности как самого вычислительного узла, так и приложений, работающих на нем [2]. В данном случае время отклика приложения определяется как ин-

тервал времени между отправкой запроса на предоставление данных и до момента объявления о готовности к передаче.

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

Вывод, который можно сделать после анализа методов оценки загрузки вычислительных узлов с использованием внешнего мониторинга, следующий. Эти методы позволяют получить данные о загрузке узла, выраженные только во времени ответа на запрос системы балансировки. О таких существенных характеристиках вычислительного узла, как состояние процессора или процессоров, состояние памяти или подсистемы ввод/вывода, с помощью внешнего мониторинга нельзя получить каких-либо сведений. Кроме того, серьезным недостатком всех методов внешнего мониторинга является то, что загрузка вычислительного узла определяется по времени, которое необходимо для передачи и получения служебного пакета. Большое время ответа вычислительного узла может и не зависеть от загрузки самого узла, а быть таким из-за перегрузок в сети.

Для получения более детальной информации о состоянии вычислительного узла необходимо использовать методы второй группы.

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

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

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

Основным недостатком методов балансировки нагрузки, основанных на внутреннем мониторинге состояния вычислительного узла, является присутствие резидентной программы на каждом узле вычислительной системы. Служебные программы-агенты поглощают определенное количество ресурсов подконтрольного вычислительного узла. Объем требуемых ресурсов зависит от того, по скольким параметрам идет оценка загруженности вычислительного узла [3], идет ли обработка этих данных на самом узле или они передаются на центральную машину системы балансировки нагрузки.

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

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

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

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

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

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

Выбор одного из этих методов зависит от нескольких условий. Как отмечалось выше, распределенная система создается для решения определенного круга задач, поэтому заранее известно приблизительное время на обработку одного задания. Если задание ресурсоемкое, требует длительной обработки и интенсивного обмена между вычислительными узлами, то имеет смысл использовать метод, где данные о загрузке вычислительных узлов поступают по запросу центральной машины системы балансировки нагрузки. Если же задания пользователей выполняются за короткий промежуток времени, например, запросы пользователей к web-yзлy, то тогда предпочтительнее использовать метод внутреннего мониторинга с «активными» программами-агентами, которые сами периодически передают данные о загрузке своих вычислительных узлов на центральную машину-диспетчер.

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

ния наиболее загруженных сегментов. Это особенно важно для систем, в которых идет активное взаимодействие узлов друг с другом при обработке задания. Такой подход позволит регулировать нагрузку не только на вычислительных узлах, ной в сети.

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

Именно использование комплексного подхода к балансировке нагрузке позволит добиться наилучших показателей в увеличении производительности распределенной вычислительной системы.

1. Либман Л. Философия распределения нагрузки // Журнал сетевых решений LAN. 2000. №5.

2. Тао Чжоу Системы балансировки нагрузки Web серверов // Windows 2000 Magazine. 2000. № 3.

3. Воеводин В.В., Воеводин Вл.В. Параллельные вычисления. СПб: БХВ-Петербург, 2003.

Настройка сетевых протоколов.

2. Использование измерительных приборов (вольтметра, амперметра).

3. Файлы с каким расширением можно открыть с помощью опции Open?

4. Какие вкладки имеет окно свойств элемента и для чего они предназначены?

5. Для чего служит команда Copy as Bitmap?

ЛАБОРАТОРНАЯ РАБОТА №1,2

Установка и настройка сетевой карты.

Цель: научиться подключать компьютер в локальную сеть.

Оборудование:IBM-PC совместимый компьютер, сетевая карта.

Программное обеспечение: MS Windows.

Порядок выполнения работы:

Для подключения компьютера к локальной сети необходимо:

Установить сетевую карту (выполняется условно)

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

· Нажмите кнопку Пуск на панели задач. Выберете пункт Настройка -> Панель Управления. -> Сетевые подключения

· Вызовите свойства объекта Подключение по локальной сети

· Определите и исследуйте компоненты, используемые этим подключение. Заполните теблицу:

№ п/п	Вопрос	ответ
Какие компоненты используются подключением по локальной сети, назначение?
Выводится или нет значок, уведомляющий о подключении по локальной сети?
Где находится этот значок?
Как называется компонент, обеспечивающий управление сетевым трафиком, включая скорость передачи м службы приоритетов?
Какая сетевая карта установлена на компьютере?
Назовите дату выпуска драйвера сетевой карты?
Назовите версию драйвера?
Назовите поставщика драйвера?
Сетевая карат поддерживает управление электропитанием компьютера?
Что такое брандмауэр Windows?
Включен ли брандмауэр на вашем компьютере?
Напишите IP адрес вашего компьютера?
К какому классу сетей относится эта подсеть?
Напишите адрес шлюза?
Почему не указан DNS сервер?

Вопросы к защите:

Порядок установки и настройки сетевой карты.
Что такое: BNC-коннектор, UTP, RG-58, RJ-15, 10Base-T
Локальная сеть. Признаки классификации сетей.
Топология сетей. Физические среды передачи данных.
Какому уровню модели OSI соответствует: установка сетевой карты и подключение к ЛВС, драйвер сетевой карты.

ЛАБОРАТОРНАЯ РАБОТА №3,4

Настройка сетевых протоколов.

Цель: научиться настраивать сетевые протоколы для работы в локальной и глобальных сетях.

Оборудование:IBM-PC совместимый компьютер, сетевая карта.

Программное обеспечение: MS Windows.

Порядок выполнения работы:

Проверить подключение к сетевой карте сетевого кабеля. Проверить подключение другого конца кабеля к концентратору (витая пара) или сегменту сетевого кабеля (коаксиальный кабель).
Нажмите кнопку Пуск на панели задач. Выберете пункт Настройка -> Панель Управления. -> Сетевые подключения
Вызовите свойства объекта Подключение по локальной сети
Определите: какой протокол установлен по умолчанию на вашем компьютере (см компоненты, используемые подключением).

Настройка протокола:

Вызовите свойства Протокола Интернета (TCP/IP).
Заполните таблицу

IP адрес

Маска подсети

Основной шлюз

Предпочитаемый DNS-сервер

Альтернативный DNS-сервер

проверьте работу сетевого интерфейса командой ping IP-адрес и работу сервера DNS командой ping доменное_имя. Заполните таблицу

IP адрес соседа справа	Время отзыва:
IP адрес самой машины	Время отзыва:
IP адрес центральной машины в аудитории	Время отзыва:
Сколько пакетов было передано за одно пингование:
Запишите команду пингования DNS сервера

Проверьте работу маршрутизации командой tracert IP-адрес (tracert доменное_имя). Заполните таблицу:

Сетевая плата

Используемые протоколы

IP-адрес

Маска подсети

Доменное имя компьютера

DNS-сервер(ы)

Шлюз

Вопросы к защите:

1. Порядок настройки стека протоколов TCP/IP.

2. Что такое: IP-адрес, маска подсети, доменное имя, DNS-сервер, шлюз.

3. Маршрутизация. Принципы маршрутизации.

4. Назначение и принцип работы сервиса ARP.

5. Как определить доступность вычислительной системы по сети?

Как определить доступность вычислительной системы по сети