Большую часть своей работы мы выполняем на размещенных в одном месте серверах в центре обработки данных по SSH. Это означает, что мы подключены к ящикам почти весь день, 5 дней в неделю. Время от времени мы будем видеть задержку между набором текста на клавиатуре и возвратом содержимого к нам в оболочке. Я начал копать, и у меня возникли проблемы с пониманием результатов; Я также ищу следующие шаги, чтобы посмотреть. Раньше я проводил трассировку wirehark против tcp.dstport == 22, где, кажется, у нас больше всего проблем. Я заметил большие пакеты (10-20 из нескольких тысяч), которые были повторной передачей TCP. Я предполагаю, что это связано с проблемой задержки, которую мы наблюдаем.
1) mtr на удаленный хост
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.100.254 76.6% 454 0.5 0.5 0.3 4.7 0.4
2. 10.113.128.1 80.6% 454 17.3 130.8 5.7 6030. 726.7
3. 74.128.19.209 79.5% 454 9.7 25.8 6.7 1270. 133.2
4. 74.128.8.233 80.6% 454 8.5 31.9 6.6 1369. 150.6
5. 4.71.250.1 79.2% 454 1547. 50.5 14.7 1547. 194.1
6. 4.69.138.158 80.4% 454 20.1 29.7 15.4 1003. 104.5
7. 4.69.140.189 74.2% 454 16.2 28.6 15.0 920.0 85.5
8. 4.69.138.4 72.6% 454 17.0 41.2 15.5 821.6 81.7
9. ???
10. 216.26.190.9 79.4% 453 45.2 105.8 24.4 3008. 406.7
11. 216.26.162.162 90.7% 453 28.3 40.2 24.1 556.3 81.7
2) mtr до 192.168.100.254 (происходит одновременно с mtr выше)
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.100.254 0.0% 591 0.8 0.4 0.3 6.9 0.5
Первый вопрос: почему верхний mtr предлагает потерю пакетов на 192.168.100.254, а нижний - нет?
Второй вопрос: как мне лучше определить, что может быть причиной этого?
РЕДАКТИРОВАТЬ:
mtr на первый хост за пределами нашей сети:
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. edge.networldalliance.local 18.1% 393 0.5 0.5 0.4 1.8 0.2
2. 10.113.128.1 0.0% 393 10.0 10.1 5.5 744.3 37.4
отдельный mtr для второго хоста в прыжке:
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. edge.networldalliance.local 87.9% 424 0.8 0.7 0.5 1.2 0.1
2. 10.113.128.1 0.0% 424 9.5 9.5 5.2 577.8 27.8
3. 74-128-19-209.dhcp.insightbb.com 0.0% 423 6.5 10.4 6.2 243.9 12.8
разделите (снова) mtr на третий хост в переходе:
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. edge.networldalliance.local 87.2% 440 0.6 0.7 0.4 2.2 0.3
2. 10.113.128.1 0.0% 439 6.4 10.9 5.6 991.8 47.2
3. 74-128-19-209.dhcp.insightbb.com 0.0% 439 8.5 13.3 6.5 744.3 35.6
4. 74.128.8.233 0.0% 439 7.9 23.6 6.3 493.8 47.2
Любые предложения, основанные на этих новых данных? Я собираюсь заняться заменой маршрутизатора / брандмауэра.
Прямые ответы
Первый вопрос: почему верхний mtr предлагает потерю пакетов на 192.168.100.254, а нижний - нет?
mtr отправляет эхо-запросы (эхо-ответ ICMP) с увеличивающимся сроком жизни IP до тех пор, пока не получит ответ. 192.168.100.254 реагирует по-разному при ответе на условия истечения TTL (низкий успех) и эхо-ответ ICMP (высокий успех)
Второй вопрос: как мне лучше определить, что может быть причиной этого?
Когда вы говорите «вызывая это», я предполагаю, что вы имеете в виду ваши медленные сеансы ssh, а не странные результаты mtr ... верно? Пару мыслей ...
Бегать mtr непосредственно на каждый хост на пути с 11 переходами и посмотрите, сможете ли вы найти какой-нибудь интересный симптом, начиная с одного из переходов; на основе вашего первого mtr, это может быть не намного продуктивнее, но попробовать стоит. Также поговорите с администратором 192.168.100.254, чтобы узнать, можете ли вы, ребята, понять, почему ответы ICMP с истекшим сроком действия TTL становятся рассыпанными.
Разные мысли
Существует три основных причины сетевых проблем: потеря пакетов, задержка пакетов (постановка в очередь) или переупорядочение пакетов. Однако давайте также помнить, что иногда проблемы на уровне хоста усугубляют вашу проблему.1.
Предположим на время, что 192.168.100.x vlan не там, где ваша проблема, и ваша топология выглядит так:
HOST_A----------------------HOST_B
192.168.100.x 216.26.162.162
Если вы еще не используете ssh-соединение с Windows-машины на HOST_A, Сделай так2. Теперь запишите свой рабочий стол Windows3. Когда проблема возникает снова, записанное видео является очень хорошим контрольным журналом для того, где могут быть ваши проблемы (например, в сети, на хостах или в комбинации обоих). Если вы как-то можете увидеть ntp раз в этом видео, тем лучше ... это дает вам возможность вернуться к анализу через syslog также.
HOST_A и HOST_B, другой для сеанса обнюхивания на HOST_A, последние два должны быть запущены top или vmstat 5 на HOST_A и HOST_B. На ваш второй вопрос: возможно, вы можете позволить ping работать в течение нескольких часов для каждого из обнаруженных вами прыжков. Перенаправьте вывод в файлы журнала. Затем извлеките время пинга с помощью grep, awk и т.д. и нанесите его на график (Excel, OO Calc и т.д.). Вы должны увидеть, на каких переходах начинается задержка.
Какое у вас подключение к Интернету? Часто насыщение загрузки вызывает подозрение, когда вы имеете дело с большой задержкой. Настройте свой маршрутизатор (или новый маршрутизатор) на передачу со скоростью 85% -90% от максимальной скорости соединения и настройте на нем справедливую очередь, чтобы избежать попадания пакетов ssh в конец очереди.