Я новый системный и сетевой администратор. Мой опыт касался аппаратного и программного обеспечения систем и серверов, сетевая часть для меня довольно нова. Я знаком с включением чисел в сетевые конфигурации, но если вы спросите меня о подсетях или отбрасывании пакетов (;), вы увидите, что это действительно потерянное выражение мелькнет на моем лице. Я учусь.
Вот моя проблема:
Примерно за два месяца до того, как взять бразды правления здесь, предыдущий администратор сети сообщил, что у них были проблемы с загрузкой больших файлов. Ну, на самом деле не только большие файлы, просто большие. Теперь, когда я загружаю все (от случайных драйверов до последних дистрибутивов и SP, от нашей подписки Technet и лицензионного соглашения до многогигабайтных пакетов инженерного программного обеспечения для наших различных отделов), мне нужно «нянчиться» загрузки, приковавшими меня к столу часами.
Загрузки начнутся нормально и дойдут до некоторой случайной точки в диапазоне от нескольких K до пары G, прежде чем загрузка остановится и завершится ошибкой, если я не приостановлю и не перезапущу загрузку до ее сбоя. Иногда пауза / перезапуск срабатывает сразу, загрузка набирает скорость и немного прогрессирует, прежде чем цикл повторяется. Иногда мне нужно пройти несколько циклов паузы / перезапуска, прежде чем загрузка действительно начнется снова.
Информация о сети и интернет-провайдере:
Впервые проблема была отмечена примерно в сентябре, и в то время с нашей стороны не было никаких изменений, которые мы можем объяснить.
Что я должен тестировать, проверять и т. Д., Чтобы определить, на нашей стороне проблема или у интернет-провайдеров?
Обновить:
Я наблюдаю, как канал wirehark фильтруется для TCP-потока большой загрузки, с которой у меня были проблемы уже несколько дней. Большинство кадров трафика помечены ...
Продолжение или не-HTTP-трафик
... что я предполагаю, это всего лишь последующие пакеты, составляющие загрузку. Однако относительно часто (каждые 3-20 секунд) и почти точно соответствуют любым провалам скорости загрузки, о которых сообщает Firefox, большие участки фреймов помечены ...
[TCP Retransmission] Продолжение или не HTTP-трафик
Есть также несколько случайных кадров, обычно разбросанных вокруг пакетов повторной передачи по несколько десятков кадров с каждой стороны, помеченных ...
[TCP Предыдущий сегмент потерян] Продолжение или не HTTP-трафик
... и что ж, загрузка не удалась примерно на середине файла размером 3,2 ГБ. Последний кадр - это кадр потери предыдущего сегмента TCP. Это произошло сразу после того, как мне пришлось приостановить загрузку и попытаться перезапустить ее: немедленный сбой очереди.
Заключительные кадры в загрузке были http [ACK] с последующим http [FIN, ACK], что, как мне кажется, указывает на "изящное" закрытие TCP-соединения.
Больше ничего, указывающего на прерывание посредником, я не увидел.
Обновление 2
Проблема наблюдается во всех браузерах и приложениях, которые загружаются, а функция паузы / перезапуска работает 99% времени во всех приложениях, которые позволяют приостанавливать / перезапускать. Конкретные приложения и браузеры, которые я могу легко воспроизвести в: Firefox (текущие версии), IE (9), iTunes (загрузка приложений и обновлений для устройств iOS). Я не уверен, что все они используют одну и ту же функциональность для функции паузы / возобновления загрузки.
iTunes загружается с серверов, которые все разрешают перезапуск (кроме файлов обновления iOS), поэтому не имеет значения, на сколько я приостанавливаю загрузку. Большинство сайтов, с которых я загружаю большие файлы (MS, PTC, Solidworks, AutoDesk), не поддерживают возобновление остановленных / отмененных загрузок (MS делает, но только с помощью диспетчера загрузок на основе java), поэтому я могу приостановить только около 15 секунд max перед загрузкой не удастся сразу после попытки возобновления.
Обновление 3
Используя mturoute (спасибо Tom H), я обнаружил, что согласованный максимальный MTU маршрута составляет 1500 байт до фрагментации, а путь несут полезные данные ICMP с фрагментацией 10000 байт от конца до конца без особых проблем, включая переходы через устройства моих интернет-провайдеров. Таким образом, проблема не в фрагментации или несовместимых настройках MTU.
ICMP также не блокируется моим интернет-провайдером, как и BitTorrent, хотя я не использую BT для загрузки этих файлов.
ОБНОВЛЕНИЕ 4
Итак, судя по журналам WireShark, мне нужно изучить, как определить причину потери кадров повторной передачи и предыдущего сегмента. Как мне определить возможный их источник?
Некоторые интернет-провайдеры принимают странное решение блокировать все пакеты ICMP на своих коммутаторах или межсетевых экранах. Это блокирует вычисление MTU пути, что означает, что вы получаете больше фрагментированных пакетов, когда они проходят по маршрутам с более низкими MTU. Может быть, вы видите результат этого.
Фрагментированные пакеты необходимо собирать заново, что может быть проблемой, если у вас также есть потеря пакетов! Если вы пытаетесь загрузить большие файлы, фрагментация и потеря пакетов будут более серьезной проблемой. Обнаружение MTU пути предназначено для уменьшения фрагментации.
Так как же узнать, сделал ли это ваш провайдер? Вы можете спросить их - однако, по моему опыту, интернет-провайдеры предпочтут отправить вас с устранением основных неисправностей на несколько дней / недель, а не признать, что они, возможно, сделали что-то не так. И, конечно, иногда они правы!
Вам следует собрать информацию, чтобы показать им, что вы видите. Захваты пакетов, как вы это делали в Wireshark или собирали на брандмауэре, полезны, поскольку они часто показывают уровень фрагментации. Вы можете проверить, работает ли обнаружение MTU пути, используя tracepath (* nix) или mturoute (Windows).
Если вы обнаружите, что pMTU не работает, это может быть ваш интернет-провайдер или интернет-провайдер сайта, с которого вы пытаетесь выполнить загрузку. Если вы видите проблему с загрузкой с нескольких сайтов, скорее всего, это ваш интернет-провайдер.
И, конечно же, это может быть еще много чего :-) Удачи!
Обычно вы можете работать, чтобы изолировать и решить проблему, систематически проверяя работоспособность различных частей сети. Это процесс уверенности в том, что я знать это работает при использовании соответствующих инструментов для исследования, и по частям вы придете к какому-то заключительному фрагменту мозаики и скажете: «Я знать это проблема, потому что в остальном все хорошо!
Если вы можете воспроизвести проблему в устройствах, подключенных к обе Ethernet И беспроводная связь, которая изолирует проблему в конечном канале между сетью <=> Cisco 1811W <=> DSL Fiber <=> ISP <=> и Интернетом.
Если вы видите проблему только в проводной сети ИЛИ беспроводных устройств, то вы можете настроить проводную сеть Ethernet или беспроводную конфигурацию на Cisco 1811W. Затем вы можете просмотреть общие настройки проблемного сегмента в качестве следующего шага.
Обычно повторно подключайте любой обычно соединенный кабель Ethernet и попробуйте поменять местами кабели DSL, если они есть, при тестировании какого-либо устройства.
Проверьте настройки MTU и автосогласования на маршрутизаторе, которые установлены для DSL, просмотрите файл журнала маршрутизатора из IOS.
Маршрутизатор будет работать под управлением IOS 12 или что-то в этом роде, у которого будет несколько хороших инструментов командной строки, доступных через ssh для проверки согласованных настроек.
Использовать show interfaces команда для просмотра статистики ошибок, например повторной отправки и отброшенных пакетов. У него может даже быть веб-интерфейс (но я не работаю с устройствами cisco IOS в данный момент, поэтому это не проверено только на основе некоторых заметок, которые я сделал по устранению неполадок в сети cisco)
Однако у вас должна быть возможность открыть таблицу статистики ошибок порта из консоли cisco, используя
# show interfaces status
# show interfaces counter errors
и для конкретного порта, например
# show interface GigabitEthernet 5/28 status
# show interface GigabitEthernet 0/24 switchport
Редактировать: вот небольшое видео какого-то парня, показывающего, как использовать ios «показать ошибки счетчиков интерфейсов» для устранения проблем. На самом деле это действительно здорово, но, вероятно, слишком глубоко, но оно дает вам информацию, необходимую для обнаружения несоответствия дуплексного режима или настроек автосогласования.
p.s. вы можете проверить маршрутизаторную часть соединения, подключив альтернативный DSL-маршрутизатор к оптоволоконному соединению. Если загрузки работают, найдите их, вы знаете, что проблема в этой стороне, а не в стороне провайдера.
просто любопытно, это все машины с Windows 7? У меня была аналогичная проблема, которая затрагивала только машины Win 7. Маловероятное решение сработало, и я никогда в жизни не был так счастлив.
Хотя изначально мой вопрос касался электронной почты, вскоре я понял, что проблема широко распространена практически на все, что связано с сетью. Исправление Microsoft было простым и легким, и сейчас я настраиваю его для всех компьютеров W7 перед развертыванием. С тех пор у меня не было никаких проблем.
Вот вопрос: Исходный вопрос
Вы используете BitTorrent для загрузки этих больших файлов? Многие интернет-провайдеры установили специальное оборудование для обнаружения и ограничения трафика злоумышленников.
Я бы позвонил вашему интернет-провайдеру, чтобы узнать, какой у вас тарифный план и знают ли они о формировании или ограничении трафика.
Вот что использует мой интернет-провайдер:
Я оставлю это в качестве упражнения ОП, чтобы определить, как обойти любое такое аппаратное / программное обеспечение, ограничивающее скорость, если оно существует.
Проблема устранена!
Эту проблему было чрезвычайно трудно диагностировать, потому что это происходило нерегулярно, и, хотя и не редко, но и не часто (да, это противоречие, я буду жить с этим).
В конце концов, проблема, казалось, усугублялась и влияла на другие аспекты нашего соединения, и я смог уловить ее в сброшенных пингах и т.п., и мне стало ясно, что проблема не в нашей сети.
Наш интернет-провайдер (в то время) был перепроданным соединением AT&T, и поэтому я поговорил с реселлером, сначала он представил им собранную мной информацию (это по памяти, проблема была решена около 6 месяцев назад, так что технических деталей мало. , извините), что доказывает, что проблема не была внутренней для нашей сети. Они обнаружили, что у одного из их собственных коммутаторов возникла проблема, и заменили его, но это не устранило проблему, поэтому они провели тестирование и обнаружили проблемы в восходящем направлении с AT&T, и AT&T смогла подтвердить и решить проблемы.
Я не совсем уверен, что проблема была только в AT&T. Исходя из того, как обострились симптомы, я бы сказал, что эскалация была вызвана проблемами на стороне AT&T, но исходная проблема была с нашим собственным локальным интернет-провайдером, и поэтому у нас была проблема с доверием.
Мы сменили интернет-провайдера, оставив местного реселлера по этой причине, и перешли в ... AT&T. Я знаю, из сковороды в огонь. Но теперь мы платим гораздо меньше за гарантированно больше, и как только AT&T увидела их проблему, они исправили ее, что в нашей книге нормально.