Встретился с удивительной проблемой.
При закачке файла с некоторых сайтов (одним из которых является download.microsoft.com) скорость скачивания сначала показывает порядка 400 КБ/с (что соответствует действительности), а затем закачка останавливается. Трафик идет через cisco 2851 с иосом с2800nm-advipservicesk9-mz.124-24.T4.bin, причем картина одинаковая, если трафик натится и если просто маршрутизится с белого ip адреса.
ума не приложу в чем дело и как можно диагностировать? Подскажите в чем может быть проблема?

Инспектирования не делаете?

Делаем. Работает ZBF. Но данная конфигурация на 2801 не вызывала проблем в работе.

На всех сайтах? И даже в сети твоего провайдера? Или только америка?

Сайты избранные. Причем выделить по какому-то признаку не могу (на текущий момент зафиксировал поблему с downlod.microsoft.com и mail.yandex.ru).
Провайдера менял проблема не исчезала.
Инспектирование трафика ZBF может так снизить скорость закачки?

Мониторинг CPU Memory на Cisco ведется?

Процессор больше 7 % не загружается. памяти достаточно (~200Mb из 512). Если я правильно понимаю, то если проблема заключалась в нехватке ресурсов, то проблемы были бы со всем трафиком, идущим через маршрутизатор. А у меня только с Http, ipsec например работает нормально.

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

Большие файлы качаются нормально, 4.5 Гб закачалось без проблем.

попробуйте убрать inspect http и inspect https

Есть возможность без изменения конфигурации понять, что задерживает испектирование протокола?

А что мешает менять конфу? Коннект не упадет.
Чтобы понять нужно весь механизм знать)

ИМХО, это косяк инспектирования.

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

Других способов, кроме как отключение инспектирования, нет?

да попробуйте же Вы! вдруг вопрос не в этом, а мы тут гадаем. У Вас же не HTTP-server, а клиент. для него инспектирование не критично, кмк.

Убирал инспектирование протоколов, политика работала на основе только acl - проблема не решилась.
Нашел подобную проблему на форуме viewtopic.php?f=2&t=706, там роблема решилась заменой действия с inspect на pass.
Есть какая то возможность определить, что не нравится брандмауэру и почему он снижает скорость закачки?

Не важно, как вы включите инспектирование. Важно - какого протокола.

Ключевое слово pass означает ничего не разбирать глубже 4 уровня. Только не забыть обратный трафик тоже pass ануть

А почему на 2801 такая настройка брандмауэра не приводила к подобным проблемам? У нее производительность ниже.

Другая машинка

Снова возвращаюсь к данной теме, т.к. все чаще стала мешать спокойной жизни.

Проанализировал tcp сессию. Очень много повторных передач - пакет приходит (я его вижу на интерфейсе маршрутизатора), но до получателя не доходит, отправитель повторяет и таких потеряных пакетов достаточно много, через какое то время передача пакетов отправителем останавливается вовсе (как я понимаю ждет подтверждения), т.е. получается, что задержка в основном возникает из-за того, что сбивается окно.

Не могу понять, не ужели проблема больше ни у кого не возникала, у меня типичная конфигурация, тем более отработанная на более младшей модели 2801?

Может это как то можно лечить уменьшением размера окна tcp сессии или может смена иоса поможет решить проблему?

99,7% это результат работы ZBF связанный с потерей/отбрасыванием пакетов, нарушением порядка следования или просто глюком (указано в поядке уменьшения вероятности).
Вы уверены, что у Вас действительно отключено инспектирование http?
Если да, снимите tcpdump до и после маршрутизатора для одной и той же сессии и сравните результат.

Инспектирование http когда анализировал tcp сессию было включено, но когда я убирал инспектирование http ситуация не изменялась.
Скажу, что отбрасывает пакеты циска, но вопрос почему? Это же нормальный пакет. Какая логика у ZBF, что отбрасываются пакеты?

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

Это касается не только HTTP, а Application Inspection вообще. Например, при включенной проверке SMTP с некоторых серверов могут перестать приходить письма, превышающие некоторый размер.

Что Вы подразумеваете под "убирал инспектирование http"? Нужно явно указать инспектировать http как tcp. Иначе ZBF будет использовать инспектор http автоматически.

Под отключение инспектирования http я понимал, что надо удалить строчку из class-map

class-map type inspect match-any cm-prot
match protocol icmp
match protocol pop3
....
match protocol http (удалил)
match protocol https (удалил)
match protocol tcp

Правильно?