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

Таинственное регулирование WAN-соединения

Настроить

2x Cisco ASA 5520

ASA 8.3 (1), ASDM 6.3 (1)

Настройки шифрования IPSec:

ESP-3DES-SHA, двунаправленный, группа секретности идеальной пересылки 1, время жизни 8 HR или 4 608 000 килобайт, включен NAT-T

Сеть A, Чикаго 10.110.1.0/24 100 Мбит / с Устойчивое соединение

Сеть B, Денвер 10.110.2.0/24 В оптоволоконную сеть центра обработки данных со скоростью 60 Мбит / с

Проблема

Любой трафик между Чикаго и Девнером (IPSec, HTTP, FTP и т. Д.) Сталкивается с препятствием на скорости 7 Мбит / с Денвер -> Чикаго и 1,5 Мбит / с Чикаго -> Денвер.

Тесты

  1. Обновления Microsoft загружаются со скоростью 60+ МБ / с из любой сети, поэтому я знаю, что соединение WAN на любом конце быстрое.
  2. Перезагрузил оба брандмауэра на всякий случай.
  3. Передачи из Чикагского ASA в другой Чикагский ASA выполнялись со скоростью 45-50 МБ / с. Так что не похоже, что мой ASA будет ограничивать скорость или у IPSec проблемы со сквозным выводом. ЦП сидит на 3-4% в течение дня и 10% во время передачи 7 / 1,5 Мбит / с.
  4. Traceroute между Чикаго и Денвером составляет 16 переходов, ни один переход не превышает 60 мс.
  5. Передали файлы через туннель IPSec в Windows, за пределы туннеля IPSec как трафик HTTP или FTP, и все еще видите ограничения 7 / 1,5 МБ / с.
  6. Подключили настольный компьютер к нашему коммутатору Cogent в Чикаго, назначили IP-адрес WAN, передали трафик HTTP и FTP и все еще видите ограничение 7 / 1,5 МБ / с.
  7. Посмотрел размер окна TCP при передаче, когда я видел ограничение между Чикаго и Денвером, и при загрузке файла. Оба были по 65 535.
  8. Попросили центр обработки данных посмотреть на строку, чтобы увидеть, есть ли какие-либо потерянные пакеты, ошибки CRC и т. Д. Они ничего не видели.
  9. 24-часовой пинг показывает отсутствие потери пакетов и среднее время ответа 85 мс.
  10. Дважды проверьте настройку Cisco ASA, чтобы убедиться, что не было выдано никаких команд "вывода полиции". Наш ASA довольно ванильный, поскольку у нас есть несколько NAT, ACL для доступа и IPSec VPN в Чикаго.

Вопросы

  1. Я не могу понять, с каким уровнем OSI обращаться при устранении неполадок.
  2. Могу ли я связаться с интернет-провайдерами и рассказать им о своих проблемах? На кого я должен указывать пальцем?

мои мысли по этому поводу были бы сначала попытаться запустить несколько одновременных подключений, чтобы увидеть, достигли ли вы назначенных скоростей через несколько одновременных подключений, тогда вы в значительной степени исключили любые трудности уровня 1, 2 или 3

возможно, попробуйте проверить пропускную способность UDP, если вы можете отправлять 70 Мбит / с в трафике UDP, но вы ограничены 7 Мбит / с пропускной способностью TCP, тогда я бы сильно склонялся к тому, что это была своего рода проблема с скользящим окном TCP

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

надеюсь это поможет

Похоже, пора запустить wirehark на обоих концах. Думаю, это поможет вам найти трафик, который вызывает проблему. У нас недавно было подобное (из-за этого наш iscsi san не синхронизировался), он оказался плохим коммутатором центра обработки данных. Я использовал журналы WireShark, чтобы показать им проблему, и они заменили переключатель.