Назад | Перейти на главную страницу

Внутренний межсайтовый VPN через проблемы со скоростью MPLS?

Как мне устранить проблемы с низкой производительностью VPN-туннеля между сайтами по каналу MPLS? Какие соответствующие отчеты / статистические данные мне следует просмотреть?

Задний план: Я поддерживаю один конец VPN-соединения между сайтами, который используется для соединения двух концов сети управления процессами (PCN). PCN отделена от корпоративной / бизнес-сети межсетевыми экранами Juniper SRX / SSG, которые также предоставляют конечные точки VPN.

Первоначально бизнес-сеть между сайтами была связана с соединением AT&T GigaMAN, которое, как я понимаю, является торговой маркой Metro Ethernet Service. Один сайт был подсайтом основного сайта (моего), и любой трафик, который должен был перейти на другой сайт компании, кроме моего, с подсайта проходил через основной сайт перед маршрутизацией на другие сайты в компании.

Отчасти из-за стоимости и отчасти из-за дополнительной надежности Metro Ethernet был заменен каналом T3, подключенным к MPLS компании на участке. Главный сайт уже был на MPLS вместе с остальной частью компании. Одно из применений VPN - это запланированная передача файлов между сайтами, и после перехода на MPLS на подсайте у нас будут периодические тайм-ауты для передач.

Я не контролирую LAN или WAN компании, только PCN, поэтому мне приходится работать с другой группой, чтобы найти основную причину, но я не знаю, какие вопросы задавать.

На что я бы посоветовал посмотреть:

  • Вытащите журналы событий из ящиков Juniper, особенно ищите капли в туннеле.
  • Запустите журналы отладки на ящиках Juniper, особенно если проблемы достаточно последовательны, чтобы вы могли сделать это, не беспокоясь о переносе журнала или проблемах с производительностью во время отладки.
  • Получите любые отчеты MPLS, которые покажут потерю подключения, использование полосы пропускания и т. Д. Как можно более детально по временным рамкам.
  • Сделайте нормальные тесты. Тестируйте различные конечные точки, размеры файлов, размеры MTU, тесты QCheck и т. Д. В разное время дня. Еще лучше, если вы можете запускать их во время периодических проблем.
  • Если его можно воспроизвести даже на ежедневной основе, попробуйте запустить конечные точки с ведением журнала WireShark, а затем проанализируйте эти журналы.
  • Попробуйте разные протоколы передачи файлов. Посмотрите, не проблема ли в самом протоколе. SMB довольно плохо работает с VPN-туннелем. Вместо этого попробуйте FTP. Тестируйте и собирайте результаты.

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

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

Выполните несколько тестов ping с определенными размерами пакетов, в частности, используйте размер MTU и что-то вроде MTU + 5. Также рассчитайте накладные расходы инкапсуляции (OVH) и используйте MTU - OVH и MTU - OVH + 5.

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