Функционирование маршрутизаторов. Что делать с потерей пакетов, как выяснять причину? Создание нового тестового пакета

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

Инструкция

1. В ОС Windows имеется стандартное приложение ping с помощью его можно проверить качество сетевого соединения, опираясь на количество передаваемых пакетов данных, проверка происходит при помощи TCP/IP-протокола. При тестировании, эта утилита посылает определенное количество тестовых пакетов и подсчитывает количество ответов от узла, путь к которому вы укажете самостоятельно. Также она фиксирует время, которое будет затрачено на эту операцию.
2. Для доступа к этой утилите нужно загрузить командную строку, сделать это можно двумя следующими способами:

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

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

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

Не удалось решить данную проблему? — , заказав услугу обслуживание компьютеров. Услуга будет актуально для юридических лиц Москвы и Московской области.

Видео: Команда Ping или проверка работоспособности сети

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

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

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

Для обеспечения телекоммуникаций помимо сетевых (routed) протоколов применяются маршрутизирующие ( routing ), которые также являются протоколами сетевого уровня. Они создают и поддерживают таблицы маршрутизации. Обновления ( update ) таблиц протоколами маршрутизации реализуются путем связи и обмена данными между маршрутизаторами. Следовательно, протоколы маршрутизации создают и поддерживают таблицы маршрутизации , а сетевые протоколы используют эти таблицы для продвижения пакетов.

Протоколы сетевого уровня, к которым относится и IP , должны обеспечивать номера ( адреса) сетей и номера (адреса) хостов. Некоторым протоколам, например Novell Internetwork Packet Exchange (IPX ), требуется только сетевой адрес , поскольку они используют MAC-адрес устройства в качестве адреса хоста. Протоколу IP требуется адрес , содержащий как сетевую, так и узловую (хостовую) части. Для того чтобы можно было выделить адрес сети и адрес хоста, необходима маска сети или подсети (см. лекцию 7). Протоколы IP, IPX/SPX и AppleTalk обеспечивают поддержку Уровня 3 модели OSI .

Основным сетевым (routed) протоколом всемирной сети Интернет является Internet Protocol (IP ). Формат сообщения сетевого уровня представляет собой пакет , известный также как дейтаграмма ( datagram ). Это означает, что в процессе организации связи не используются схемы коммутации цепей, поскольку все соединения выполнены заранее и нужно лишь выбрать наилучший путь к адресату назначения на основе метрики протокола маршрутизации. Термины ненадежный ( unreliable ) и доставка по возможности , доставка с наибольшими возможными усилиями (besteffort delivery ) означают, что проверка ( верификация ) правильности полученных данных на сетевом уровне не производится. Для такой проверки при необходимости используется протокол транспортного уровня TCP .

Формат пакета сетевого протокола IP ( рис. 8.5) включает заголовок, состоящий из 12 полей общей длиной в 160 бит (5 слов по 4 байта, т. е. 20 байт ), поле опций переменной длины и поле данных.

Рис. 8.5.

1. Первое 4-разрядное поле ( Vers ) задает номер версии протокола. В настоящее время действует версия 4 – IPv4 , согласно которой длина адреса источника (Source IP address ) и адреса назначения ( Destination IP address ) равна 32 разрядам (4 байтам). В распечатках поля заголовка обычно представляются в десятичной и шестнадцатеричной системах. Например, действующая в настоящее время версия 4 выглядит следующим образом: Version = 4 (0x4). В поле заголовка номер версии будет задан в двоичной системе – 0100.
2. Длина заголовка – количество 32-разрядных слов в заголовке – задается вторым полем HLEN. Например, код в этом поле – 0101, и запись Header Length = 20 (0x14) означает, что заголовок содержит 5 слов по 32 разряда или 20 байт.
3. Поле типа сервиса (Type of Service – ToS ) длиной 8 бит включает четыре идентификатора: трехразрядный идентификатор PR и одноразрядные D, T и R. Идентификаторы определяют требования к метрике при прокладке маршрута. Идентификатор PR определяет тип пакета (нормальный, управляющий и др.) и в соответствие с этим задает приоритет. Установка 1 в разряде D означает требование минимизации задержки при передаче пакета; единица в разряде Т означает требование максимальной пропускной способности; установка 1 в разряде R требует максимальной надежности.
4. Поле Total Length задает общую длину пакета, включая заголовок и поле данных. 16 разрядов поля позволяют задавать максимальную длину 64 Кбайт. Поскольку максимальная длина кадра в большинстве технологий локальных сетей меньше 64 Кбайт (например, в Ethernet она составляет 1500 байт), большие пакеты разбивают на фрагменты. При фрагментации пакета используется информация 5-го, 6-го и 7-го полей, все фрагменты должны иметь: одинаковый идентификационный номер пакета; номер, определяющий порядок следования фрагмента при сборке пакета; дополнительную информацию.
5. Пятое поле заголовка содержит идентификационный номер пакета . При фрагментации пакета идентификационный номер будет единым для всех фрагментов.
6. Трехразрядное поле Flags содержит два одноразрядных флага фрагментации. Установка 1 в разряде DF запрещает маршрутизатору производить фрагментацию данного пакета. Единичка в разряде MF указывает, что данный пакет не является последним.
7. 13-разрядное поле смещения данных Fragment Offset помогает собрать фрагменты в единый пакет. Оно задает смещение в байтах поля данных этого пакета от начала общего поля данных исходного нефрагментированного пакета.
8. Из заданного значения Time to Live – время жизни (255 – максимум) при прохождении каждого маршрутизатора или каждую секунду вычитается 1. Таким образом, число узлов, через которые может пройти пакет, ограничено.
9. Поле Protocol указывает протокол верхнего уровня (TCP, UDP , OSPF и др.), которому будет передан принятый пакет после завершения IP-процесса.
10. Поле контрольной суммы заголовка Header Checksum . Поскольку при прохождении маршрутизатора значения некоторых полей заголовка изменяются (например, время жизни), расчет контрольной суммы производится в каждом маршрутизаторе заново.
11. Source IP address – адрес источника информации, длина – 4 байта (32 разряда).
12. Destination IP address – адрес приемника информации, длина – 4 байта (32 разряда).
13. Поле IP option позволяет поддерживать различные опции, например, опцию защиты информации. Поскольку это поле может иметь разную длину, оно дополняется нулями до 32 разрядов.
14. Поле данных Data имеет длину более 64 разрядов.

Краткие итоги

1. Основным протоколом автоматического назначения IP-адресов устройств является протокол динамического конфигурирования узлов DHCP .
2. При передаче данных через составную сеть IP-адреса узла назначения и узла источника остаются неизменными.
3. При передаче данных через составную сеть МАС-адреса назначения и источника меняются при прохождении каждого маршрутизатора.
4. При формировании кадра вычисляется контрольная сумма , которая записывается в поле FCS -трейлера кадра. При приеме кадра на каждом входном интерфейсе вновь вычисляется контрольная сумма , которая сравнивается с принятой.
5. Правильность принятых данных проверяется с использованием циклического кода CRC .
6. При передаче данных через соединения "точка-точка" заголовок кадра может быть существенно упрощен.
7. Сетью с доставкой данных без предварительного соединения отправителя и получателя сообщения является Internet, где передаются пакеты ( дейтаграммы ) с использованием протокола IP .
8. Правила телекоммуникаций узлов между собой при обмене данными через сети устанавливают протоколы. Протоколы описывают формат сообщения, путь (маршрут) обмена сообщениями и другие правила.
9. Основным сетевым протоколом всемирной сети Интернет является Internet Protocol (IP).
10. Сетевые (routed) протоколы определяют

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

Система
core i5 3570K
ASUS P8 z77V LX, вздутых конденсаторов нет
GIGABYTE NVIDIA GEFORCE 760, версия драйвера 361.43
Kingston KHX1600C9D3P1K2/8G - 4gb, 4 планки, итого 16
Винт WDC WD10EZEX-60ZF5A0 + SSD ... какой то, не системный, для хлама.
Блок питания Thermaltake TR2 Bronze 650W, около 2 лет
Звуковая карта Sound Blaster Z
Microsoft Windows 7 Максимальная (64 bit)
Версия 6.1.7601 Service Pack 1 Сборка 7601

Примерно 3 или 4 дня назад ни с того ни с чего начались жуткие потери пакетов. Стабильно 5-8%, чаще 20-25, иногда подпрыгивает до 40-50%.
Сопровождается это все жуткими фризами в сетевых играх, остановки на пол-одну секунду, затем все уже где то на других местах, твой же персонаж не сдвинулся или дёрнулся. Причем пинг остается стабильный на уровне до 70ms.
По ping"у получить процент потерь трудновато, так что как "методику" определния использую TeamSpeak 3 с подключение с различным серверам в разных странах. Экспериментально установлено что показания pocket loss"a прям пропорциональны интенсивности фризов в играх и задержками при работе в Skype"e, так что их можно считать достоверными, см пример.
Пример , слева зарубежный сервер, справа российский.

На момент написания поста показывает цифру в 20% на трех разных серверах, т.е потери не зависят от географического положения сервера.
Причину установиться не удаеться до сих пор.

Структура сети примерно следующая - Сервер в универе, Сервер в гостиннице, дальше большая сеть роутеров (по 2 на этаж), дальше я. Ни у кого кроме меня, даже у тех кто сидит на том же роутере, таких проблем не наблюдаеться. Авторизация на сервере гостинницы идет по mac-адресу, по нему же dhcp выдает внутрисетевой ip.

Что делалось:
-1. проверка антивирусом CureIt! на предмет всяких ботнетов и прочего говна. отрицательно.
0. попытки найти приложение которые спамит в сеть, или блокирует её, аля брандмауэр, центр обновления, и т.д.
1. обновление драйвера сетевой карты, не помогло
2. тесты сети (методом teamspeak"a) из безопасного режима, не помогло, значит это не какая то левая софтина (скорее всего)
3. подключение к другому роутеру, с другим кабелем, не помогло
4. изменение mac-адерса сетевой карты у себя (подмена) и на сервере гостинницы, было подозрение что где то стоит комп с таким же mac-ом, и происходит шум и конфликт в сети. не помогло
5. установка новой сетевой карты (подозрения что встроенная Realtek вышла из строя), не помогло
6. полная переустановка windows, сброс BIOS, обновление BIOS до актуальной версии, не помогло
7. подключение к другому роутеру, с другим кабелем, не помогло
8. Система запускалась на совершенной иной конфиругации, винчестер был подключен с другому компу. Потерь нет.

Очень прошу помочь, уже руки опускаются.

Applies To: Forefront Client Security

You can configure the following parameters of flood protection:

Indicates whether Client Security automatically approves computers that are on the Pending Computers list. When this parameter is set to true, Client Security checks the Pending Computers list once an hour and approves the computers on the list; however, when a "Flooding Detected" alert is triggered, Client Security changes the value of this parameter to false to prevent a flooding computer from being automatically approved. The default setting is true, which automatically approves pending computers.

When you have resolved a "Flooding Detected" alert parameter, you must manually reset this parameter to true if you want Client Security to resume automatically approving pending computers.

Disconnect clients -Indicates whether a client exceeding the maximum number of events should be moved into the Pending Computers list, which disconnects the client from the MOM server. The default setting is to disconnect flooding computers.

Controls the maximum number of parameters that an event message can contain before triggering the flood protection alert. This protects the MOM server from event messages maliciously designed to be too large. The default value for this parameter is 40 parameters per event.

Controls the number of event messages from a single client (within the past four days) that will trigger the flood protection alert. The default value for this parameter is 5,000 events per computer.

It is recommended that you use the default parameters for disconnecting clients, maximum parameters per event, and maximum events per computer; however, consider changing the default parameters when:

Computers generate more events than allowed by the maximum events per computer parameter. This is unlikely but can occur in some organizations.

You do not want the console to disconnect computers automatically. Disabling the disconnection of clients that exceed the maximum permitted number of events does not stop DoS attacks. Instead, Client Security will only generate alerts about the possible attack, which may jeopardize the server.

Using the MOM Administrator console, you can configure the parameters for flood detection.

To change "Flooding Detected" alert parameters

On the collection server, open the MOM Administrator console and expand the Microsoft Operations Manager tree, click Management Packs , click Rule Groups , click Microsoft Forefront Client Security , click Server Behaviors , and then click Event Rules .

Double-click Run Flood Protection .

In the Event Rules Properties dialog box, click the Responses tab.

Select the flood protection script and click Edit .

In the Launch a Script dialog box, under Script parameters , select the parameter you want to change and click Edit Parameter .

In the Edit Script Parameter dialog box, enter the new parameter value in the Value box. Valid values depend on which parameter you chose to edit. For details, see the following list:

• Auto-approve pending computers -To enable automatic approval of pending computers, type true . To disable automatic approval of pending computers, type false . The default value is true.

  Disconnect clients -To enable disconnection of flooding computers, type 1 . To disable disconnection of flooding computers, type 0 . The default value is 1.

  Maximum allowed parameters per event -Type a whole number. The default value is 40.

  Maximum events per computer in OPDB -Type a whole number. The default value is 5,000.

Click OK three times, and then right-click the Management Packs node and click Commit Configuration Change . MOM implements the changes you made.