Устранение неполадок потери пакетов на сайте Socket

Проблема

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

Возможные причины

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

• Проблемы пиринга ISP
• Конгестия связи
• Ошибочная конфигурация (настройки полосы пропускания или скорость и дуплекс сетевой карты)
• Отказы аппаратного обеспечения
• Высокая загрузка ЦП на сетевом устройстве
• Обработка микро-всплесков

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

Хороший способ выявить потерю пакетов в Cato — использовать экран аналитики в Приложении Управления Cato. Графики Потери пакетов и Отброшено показывают потерю пакетов с течением времени и позволяют сосредоточиться на конкретных временных интервалах. Эти графики полезны для выявления, происходит ли потеря пакетов и когда она произошла в прошлом. Кроме того, вы можете определить тип потери пакетов: потеря со стороны провайдера или отброшено Cato.

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

1. Потеря со стороны провайдера

Это пример потери пакетов между Socket и PoP. Хотя большинство потерь пакетов со стороны провайдера вызвано проблемами с сетевой связью в последней миле, находящейся вне зоны контроля Cato, это не обязательно исключает проблемы, связанные с Cato.

Как Cato измеряет потерю со стороны провайдера 

Потеря со стороны провайдера измеряется путем сравнения того, сколько пакетов отправлено и сколько пакетов получено на заданной связи как на Socket, так и на PoP.

• Потеря пакетов входящего трафика — это разница между числом пакетов, отправленных PoP, и числом пакетов, полученных Socket, выраженная в процентах.

Формула:

• Потеря пакетов исходящего трафика — это разница между числом пакетов, отправленных Socket, и числом пакетов, полученных PoP, выраженная в процентах.

Формула:

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

2. Пакеты, отброшенные Cato

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

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

Аналитика обеспечивает широкий обзор потери пакетов. Однако, если вы не имеете дело с потерей пакетов, отброшенных Cato, одна аналитика не может сообщить вам, что вызывает потерю пакетов или где она происходит. 

Как устранить потерю пакетов

1. Определение области потери пакетов

Когда вы начинаете, очень важно выяснить, кто или что испытывает потерю пакетов. Каждый ли пользователь испытывает потерю пакетов на сайте, или это ограничено одним конечным устройством? Потеря пакетов происходит в Интернет или через WAN? Несколько сайтов страдают от потери пакетов, или только один? Весь ли трафик затронут, или это касается только одного определенного приложения? Потеря пакетов постоянная, или она происходит только время от времени?

Знание ответов на вышеперечисленные вопросы может помочь вам определить связанные события CMA и сэкономить время в процессе устранения неполадок. Чем больше деталей вы знаете заранее, тем более целенаправленным может быть ваш процесс устранения неполадок.

2. Проверка аналитики сайта - график потери пакетов

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

Нет потери пакетов

Возможно наличие потери пакетов без отображения потерянных пакетов на экране аналитики. Может быть проблема в локальной сети, или это может быть проблема, связанная с PoP. Использование сетевого инструмента UI для отправки пинга IP-адреса на стороне LAN от Socket может быть хорошим способом выявления коренной причины.

Потеря пакетов

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

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

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

3. Проверка аналитики сайта - график отброшенных пакетов

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

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

На экране Анализатор приоритетов в Аналитика показывается потеря пакетов в направлении Передача и Прием для каждого приоритета QoS.

4. (По желанию) Мониторинг пользовательского опыта последней мили

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

5. Проверка аналитики сайта - Потеря пакетов на последней миле

Чтобы оценить, испытывает ли ISP проблемы, используйте вкладку Последняя миля в экране Аналитики, чтобы проверить любые изменения задержки или потерю пакетов, которые появляются на WAN-канале. В отличие от потерь пакетов у провайдера, данные последней мили основаны на ICMP тестах на популярных веб-сайтах. В качестве рекомендации, дополнительные IP-адреса сервисов, которые можно пинговать, могут быть добавлены на страницу Мониторинга последней мили. Например, если есть проблемы, связанные с VoIP, IP-адрес SIP-сервера может быть задан как один из адресов.

Если подозревается потеря пакетов, связанная с ISP, спросите у вашего провайдера следующие вопросы:

1. Вы применяете QoS на UDP/443 или UDP/1337 (DTLS) трафик?
2. Вы применяете какую-либо защиту от DoS на UDP-трафик, которая может вызвать потерю пакетов на PoP IP?
3. Есть ли перегрузка или высокое использование ЦП вашего маршрутизатора на пути к IP PoP?
4. Вы позволяете разбивку выше подписанной скорости линии?

6. Проверка конфигурации полосы пропускания

Потеря пакетов может быть вызвана перегрузкой канала, поэтому важно, чтобы полоса пропускания для каждого WAN-канала была правильно настроена в Приложении Управления Cato. Убедитесь, что настроенная полоса пропускания соответствует тому, что предоставляет ISP в настройках сайта. Настройте параметр полосы пропускания интерфейса Socket WAN в соответствии с условиями лицензии сайта Cato.

Среды Azure/AWS не имеют традиционных ограничений на полосу пропускания. Вместо этого настроенная полоса пропускания сайта никогда не должна превышать поддерживаемую полосу пропускания для vSocket. Для Azure, начиная с версии 21, размер виртуальной машины Standard_D8ls_v5 поддерживает до 2Gbps. В AWS размер экземпляра c5n.xlarge предоставляет полосу пропускания, превышающую 2Gbps. Важно убедиться, что настроенная полоса пропускания сайта остаётся в пределах поддерживаемых ограничений для оптимальной производительности.

Если настроенная полоса пропускания ниже, чем та, которую предоставляет ISP, движок QoS Cato может начать отбрасывать пакеты, когда установленный предел превышается. Если это так, наблюдается плоская линия на графике пропускной способности Аналитики сайта, равная настроенной полосе пропускания сайта вместе с отброшенными пакетами Cato.

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

Если настроенная полоса пропускания выше, чем предоставляет ISP, движок QoS Cato не активируется, когда предел пропускной способности ISP превышается, и поэтому провайдер может начать случайно отбрасывать пакеты. Если это так, видна плоская линия на графике пропускной способности Аналитики сайта ниже уровня настроенной полосы пропускания вместе с потерей пакетов у провайдера.

Информация о пропускной способности и ёмкости Socket для каждой модели Socket доступна в спецификации Socket, см. эту статью: Руководства по сокетам X1700, X1600 & X1500.

7. Проверить производительность ЦП Socket

Из веб-интерфейса сокета выберите вкладку Статус HW. Это покажет текущее процентное использование ЦП для каждого ядра. Постоянное использование ЦП выше 90% будет напрямую влиять на производительность сокета и вызывать потерю пакетов и высокую задержку. Если наблюдается постоянная высокая нагрузка на ЦП при возникновении потери пакетов в сети, пожалуйста, Свяжитесь со службой поддержки. 

8. Исключение повторного подключения сайта

Повторные подключения сайта к облаку Cato являются источником потери пакетов. Проверьте Домашняя > События, чтобы увидеть, корреспондирует ли потеря пакетов с событиями повторного подключения. Отфильтруйте события как подтип = 'переподключено'.

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

9. Обход Cato

Для устранения потери пакетов в Интернете настройте обход источника или назначения, чтобы быстро исключить проблему с облаком Cato. Самый простой способ сделать это - настроить обход источника для одного IP-адреса пользователя в конфигурации сайта и посмотреть, продолжается ли потеря пакетов. Если потеря пакетов продолжается, проблема может быть в ЛВС, Сокете или ISP, но проблема не будет связана с PoP.

10. Запуск тестов Ping

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

Интерфейс Сокета также позволяет выполнять ping по имени хоста или IP с помощью инструмента ping. Вы можете выбрать интерфейс, через который хотите отправить ping, либо через Cato, либо напрямую через WAN-канал. Ищите любые несоответствия в результатах пинга, такие как потеря пакетов или высокая задержка. Если потеря пакетов наблюдается с Cato и без него, это может указывать на проблемы с ISP. Кроме того, если один из каналов 4G/LTE, нужно помнить, что эти каналы более чувствительны к потере пакетов.

Интерфейс отправляет только 10 пинг-запросов, поэтому если нужно больше, нажмите кнопку Ping снова. 

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

11. Запуск тестов Трассировки маршрута

Трассировка маршрута используется для идентификации маршрутизаторов (переходов) между источником и пунктом назначения. Она отображает потерю пакетов и задержку для каждого из переходов.

Трассировку маршрута можно выполнить из веб-интерфейса сокета с помощью инструмента Трассировки маршрута. Выполните трассировку маршрута, чтобы выявить потерю пакетов или неожиданно высокую задержку на любом из переходов по WAN-каналу между Сокетом и Пунктом назначения. Интерфейс отправляет только один пакет для каждого перехода и показывает потерю пакетов для каждого перехода. Поскольку отправляется только один пакет, вы увидите либо 0% потери, либо 100%.

Анализ результатов Трассировки маршрута

Помните, что потеря пакетов на любом отдельном переходе не обязательно означает проблему. Один переход может показать 100% потери пакетов, просто потому что ICMP не включен на маршрутизаторе. Переход также может показать менее 100% потери пакетов без проблемы из-за ограничения скорости ICMP. Если вы видите некоторую потерю пакетов на одном переходе и 0% потери пакетов на следующем переходе, вероятно, вы сталкиваетесь с ограничением скорости ICMP.

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

12. Генерация высокой нагрузки для выявления потерь пакетов

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

Ожидается, что результаты Speedtest со Сокета через Cato будут близки к пропускной способности, настроенной для канала в Приложении Управления Cato. Обратите внимание, что накладные расходы туннеля DTLS (117 байт) могут незначительно уменьшить пропускную способность. 

Тест будет насыщать связь и показать любую потерю пакетов, связанную с ISP, на экране Сетевой аналитики. Отброшенные пакеты ожидаются при выполнении теста, если настроенная пропускная способность связи меньше, чем предоставленная провайдером.

Прямой Speedtest 

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

13. Тестирование связи с помощью iPerf

Веб-интерфейс сокета позволяет использовать инструмент iPerf для устранения проблем производительности в последней миле между сокетом и подключенным PoP в Cato Cloud. Сокет, который запускает клиент iPerf, проводит тест против iPerf-сервера, работающего на подключенном PoP.

Запустите тест iPerf через CATO и напрямую по WAN с страницы инструментов интерфейса сокета. Выберите UDP в качестве протокола (чтобы исключить управление потоком TCP), установите направление (восходящее или нисходящее) и целевую скорость как настроенную пропускную способность. Этот инструмент может лучше подтвердить, что пропускная способность через CATO и через WAN соответствует ожиданиям. Имейте в виду, что накладные расходы на туннель DTLS (117 байт) могут слегка снизить пропускную способность. 

В приведенном ниже примере мы устанавливаем 45 Мбит/с в качестве целевой скорости (что соответствует той же полосе пропускания, настроенной в Приложении управления Cato), и полученная скорость ниже ожидаемой с потерей пакетов 3,7%

14. Проверка связей агрегации каналов (LAG)

Потеря пакетов и высокая задержка могут быть вызваны неправильной настройкой агрегации каналов (LAG) между сокетом и внутренним коммутатором. Эту особую проблему невозможно обнаружить в сетевой аналитике; она требует устранения неполадок в рамках ЛВС. Cato поддерживает только статическую LAG, и LAG -пир должен поддерживать тот же режим. Несоответствия в конфигурации LAG приведут к потере пакетов.

Для получения дополнительной информации о устранении неполадок смотрите Link Aggregation (LAG) Link: высокая задержка и потеря пакетов

15. Проверка Скорости Связи Сокета

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

Также убедитесь, что скорости связей WAN и LAN равны или превышают пропускную способность, настроенную для сайта. Скорость связи может быть ограничивающим фактором для пропускной способности. Например, если настроенная пропускная способность сайта составляет 200 Мбит/с, но связь LAN договорена только на 100 Мбит/с в полнодуплексном режиме, компьютер, подключенный к сокету, не сможет достичь более 100 Мбит/с.

Чтобы проверить состояние связи, войдите в интерфейс сокета и посмотрите статус связи на странице Мониторинга. Ниже приведен пример отображения связи WAN1 на 100 Мбит/с в полудуплексном режиме.

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

Если настройки порта на другом устройстве верны, возможно, Ethernet-кабель поврежден. Замените кабель на известный исправный и проверьте, изменятся ли дуплекс или скорость. Если это не сработает, подключите ноутбук или другое устройство к порту сокета и проверьте статус связи. Сделайте то же самое на другом устройстве. Если соединение сокета установлено на ожидаемой скорости и в полнодуплексном режиме, но соединение другого устройства – нет, проблема будет в другом устройстве.

16. Проверка на дублирующиеся IP-адреса

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

Дублирование IP может не быть обнаружено, когда статический IP-адрес настроен на WAN-интерфейсе, так как Socket только пассивно мониторит IP-конфликт. Он обнаружит IP-конфликт только если Socket получит ARP от устройства с конфликтующим IP.

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

17. Проверка на микро-всплески

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

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

В приведенном выше примере значение уровня бурстинга было изменено с значения по умолчанию 0,2 на 0,01, что означает, что Socket и PoP применяют более агрессивное управление трафиком, таким образом, решая проблему потери пакетов.  

Настройка уровней бурстинга для смягчения потери пакетов

Значение бурстинга по умолчанию, применяемое для направлений входящего и исходящего трафика, составляет 0,2. С этим значением Socket и PoP сериализуют пакеты в медиа как можно быстрее, позволяя отправлять больше байтов в первые микросекунды временного интервала. Эта настройка оптимизирует производительность, уменьшая задержку сериализации и общую задержку. 

Как часть этого этапа устранения неполадок, вам нужно постепенно уменьшать уровень бурстинга, пока потеря пакетов не будет устранена. По мере уменьшения значения уровня бурстинга Socket и PoP применяют более агрессивное управление трафиком, смягчая тем самым микро-всплески. Самое низкое значение, которое вы можете настроить, это 0,001.

Для настройки уровня бурстинга лучшей практикой является постепенное уменьшение значения (например, с 0,2 до 0,18).  После уменьшения значения наблюдайте за воздействием, анализируя потерю пакетов на экранах «Мониторинг сайта в реальном времени» или «Сетевая аналитика». Имейте в виду, что метрики сайта обычно обновляются в течение нескольких минут. Продолжайте снижать значение бурстинга, пока потеря пакетов не будет устранена. 

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

Изменение уровня бурстинга

Уровень бурстинга можно настроить в направлении входящего и исходящего трафика. Эта настройка влияет на все WAN-связи сайта. 

Конфигурация применяется на уровне сайта или на уровне учетной записи. Конфигурация на уровне сайта имеет приоритет над уровнем учетной записи.

Чтобы настроить уровень бурстинга:

1. В меню навигации выберите Ресурсы > Расширенная конфигурация для настройки на уровне учетной записи или Настройки Сайта > Расширенная конфигурация для настройки на уровне сайта.
   
2. Выберите Значение бурстинга входящего трафика или Значение бурстинга исходящего трафика.
3. Включите настройку и отрегулируйте значение в диапазоне от 0,001 до 0,2.
   
4. Нажмите Применить
5. Нажмите Сохранить

Примечание: 

• Если burstiness ранее был отрегулирован Поддержкой Cato, будет показано отрегулированное значение вместо значения по умолчанию 0,2
• Параметры burstiness могут быть отрегулированы только для Сайт Socket
• Самый маленький Bucket данных в Приложении Управления Cato составляет 5 секунд, микро-всплески нормализуются в пределах самых маленьких Bucket данных и, как правило, трудно идентифицируются.