Между двумя роутерами (2811 и 1841) настроены VTI IPSEC - туннели по которым бегает EIGRP.
Всего на роутеры заведено 3 канала по 10М из которых 2 делаю активных (посредством maximum-path 2), также включен cef (ip cef), и на туннельных интерфейсах указан ip load-sharing per-packet.
Всё работает с первого взгядя нормально. Туннели подняты, маршрутизация работает, балансировка работает. Начинаю проверять под нагрузкой. Поставил 2 тачки с центосью по разным сторонам роутеров, поднял на них httpd и стал гонять трафик по http wget'ом. Загрузка 16Mbps и затыкается проц, ну думаю ладно, во всяком случае это объяснимо, далее ставлю с одной стороны виндовую тачку и пытаюсь качнуть тот же файл IE, и получаю скорость в разы меньше при небольшой загрузке процов на роутерах, по CIFS ситуация аналогичная. Причём когда ставлю параллельно несколько закачек, то суммарная скорость растёт и опять упирается в производительность процов на роутерах. Подумал, что это за счёт ограничения количества одновременно открытых TCP-сессий в винде, поменял с 10 (по умолчанию) на 100, ситуация улучшилась, но не сильно. Не могу понять, как решить проблемму... Помогите плиз вариантами...
>[оверквотинг удален]
> разным сторонам роутеров, поднял на них httpd и стал гонять трафик
> по http wget'ом. Загрузка 16Mbps и затыкается проц, ну думаю ладно,
> во всяком случае это объяснимо, далее ставлю с одной стороны виндовую
> тачку и пытаюсь качнуть тот же файл IE, и получаю скорость
> в разы меньше при небольшой загрузке процов на роутерах, по CIFS
> ситуация аналогичная. Причём когда ставлю параллельно несколько закачек, то суммарная
> скорость растёт и опять упирается в производительность процов на роутерах. Подумал,
> что это за счёт ограничения количества одновременно открытых TCP-сессий в винде,
> поменял с 10 (по умолчанию) на 100, ситуация улучшилась, но не
> сильно. Не могу понять, как решить проблемму... Помогите плиз вариантами...Винду выкинуть???
>[оверквотинг удален]
>> по http wget'ом. Загрузка 16Mbps и затыкается проц, ну думаю ладно,
>> во всяком случае это объяснимо, далее ставлю с одной стороны виндовую
>> тачку и пытаюсь качнуть тот же файл IE, и получаю скорость
>> в разы меньше при небольшой загрузке процов на роутерах, по CIFS
>> ситуация аналогичная. Причём когда ставлю параллельно несколько закачек, то суммарная
>> скорость растёт и опять упирается в производительность процов на роутерах. Подумал,
>> что это за счёт ограничения количества одновременно открытых TCP-сессий в винде,
>> поменял с 10 (по умолчанию) на 100, ситуация улучшилась, но не
>> сильно. Не могу понять, как решить проблемму... Помогите плиз вариантами...
> Винду выкинуть???Ну это совсем не серьёзно...
>[оверквотинг удален]
>>> во всяком случае это объяснимо, далее ставлю с одной стороны виндовую
>>> тачку и пытаюсь качнуть тот же файл IE, и получаю скорость
>>> в разы меньше при небольшой загрузке процов на роутерах, по CIFS
>>> ситуация аналогичная. Причём когда ставлю параллельно несколько закачек, то суммарная
>>> скорость растёт и опять упирается в производительность процов на роутерах. Подумал,
>>> что это за счёт ограничения количества одновременно открытых TCP-сессий в винде,
>>> поменял с 10 (по умолчанию) на 100, ситуация улучшилась, но не
>>> сильно. Не могу понять, как решить проблемму... Помогите плиз вариантами...
>> Винду выкинуть???
> Ну это совсем не серьёзно...Я правильно понимаю, скорость нормальная когда проверяешь на unix, а проверяешь с виндой маленькая?
>[оверквотинг удален]
>>>> в разы меньше при небольшой загрузке процов на роутерах, по CIFS
>>>> ситуация аналогичная. Причём когда ставлю параллельно несколько закачек, то суммарная
>>>> скорость растёт и опять упирается в производительность процов на роутерах. Подумал,
>>>> что это за счёт ограничения количества одновременно открытых TCP-сессий в винде,
>>>> поменял с 10 (по умолчанию) на 100, ситуация улучшилась, но не
>>>> сильно. Не могу понять, как решить проблемму... Помогите плиз вариантами...
>>> Винду выкинуть???
>> Ну это совсем не серьёзно...
> Я правильно понимаю, скорость нормальная когда проверяешь на unix, а проверяешь с
> виндой маленькая?Не совсем, в несколько потоков (TCP-сессий) я скорость и на винде получаю нормальную, проблема только в том, что я так понимаю, при копировании файлов проводником по CIFS используется одна TCP - сессия на процесс, и вот эта сессия не может выжать максимум... Как только я запускаю несколько потоков/сессий всё получается более-менее нормально, но очень хотелось-бы, чтобы качало и один файл с максимальной скоростью. Перед этим пробовал GRE-туннели с 3DES шифрованием и тюнингом ip mtu 1400 + ip tcp adjust-mss 1360, чтобы избавиться от фрагментации TCP-сегментов, но делу это ровным счётом не помогло.
>[оверквотинг удален]
>> виндой маленькая?
> Не совсем, в несколько потоков (TCP-сессий) я скорость и на винде получаю
> нормальную, проблема только в том, что я так понимаю, при копировании
> файлов проводником по CIFS используется одна TCP - сессия на процесс,
> и вот эта сессия не может выжать максимум... Как только я
> запускаю несколько потоков/сессий всё получается более-менее нормально, но очень хотелось-бы,
> чтобы качало и один файл с максимальной скоростью. Перед этим пробовал
> GRE-туннели с 3DES шифрованием и тюнингом ip mtu 1400 + ip
> tcp adjust-mss 1360, чтобы избавиться от фрагментации TCP-сегментов, но делу это
> ровным счётом не помогло.Хотя должно и так все работать нормально(у большинства же нормально пашет), но ради интереса, в виндовом регистре уменьши mtu
Я бы проверил 2 вещи на винде:отключение path mtu discovery, по умолчанию включено, не знаю, конечно, как у вас
отключение или иные игры с параметром, отвечающим за это :) tcp delayed ack
> Я бы проверил 2 вещи на винде:
> отключение path mtu discovery, по умолчанию включено, не знаю, конечно, как у
> вас
> отключение или иные игры с параметром, отвечающим за это :) tcp delayed
> ackПопробуйте на винду но по ftp например слить, думаю скорее всего там грабли не непосредственно в tcp, а в именно в виндовом протоколе поверх tcp.
Еще можно снифером посмотреть как идет процесс передачи... если удасться выщемить моменты типа изменения окна в 0 и потом обратно в нормальное значение - то скорее всего это вообще врядли тюнингуется...
>[оверквотинг удален]
>> отключение path mtu discovery, по умолчанию включено, не знаю, конечно, как у
>> вас
>> отключение или иные игры с параметром, отвечающим за это :) tcp delayed
>> ack
> Попробуйте на винду но по ftp например слить, думаю скорее всего там
> грабли не непосредственно в tcp, а в именно в виндовом протоколе
> поверх tcp.
> Еще можно снифером посмотреть как идет процесс передачи... если удасться выщемить моменты
> типа изменения окна в 0 и потом обратно в нормальное значение
> - то скорее всего это вообще врядли тюнингуется...Поставил на винду wget и попробовал покачать файлик по http - скорость сразу возросла до максимально возможной. Т.е. грабли не в виндовом tcp. Также поставил на линух самба-клиента и попробовал по самбе прокачать файлик. Скорость как и на винде низкая... Хрень в общем какая-то. Поставил wireshark чтобы посмотреть tcpstream, но то-ли я чего-то не понимаю, но ничего подозрительного пока не заметил...
>[оверквотинг удален]
>> поверх tcp.
>> Еще можно снифером посмотреть как идет процесс передачи... если удасться выщемить моменты
>> типа изменения окна в 0 и потом обратно в нормальное значение
>> - то скорее всего это вообще врядли тюнингуется...
> Поставил на винду wget и попробовал покачать файлик по http - скорость
> сразу возросла до максимально возможной. Т.е. грабли не в виндовом tcp.
> Также поставил на линух самба-клиента и попробовал по самбе прокачать файлик.
> Скорость как и на винде низкая... Хрень в общем какая-то. Поставил
> wireshark чтобы посмотреть tcpstream, но то-ли я чего-то не понимаю, но
> ничего подозрительного пока не заметил...В общем при анализе TCPStream увидел очень много TCP Retransmision и TCP DupACK
Проблемма аналогичная http://blogs.technet.com/b/networking/archive/2011/05/16/tcp...Но пока не решил...
В догонку на циске тоже было обсуждение: https://supportforums.cisco.com/thread/201894
>[оверквотинг удален]
>> сразу возросла до максимально возможной. Т.е. грабли не в виндовом tcp.
>> Также поставил на линух самба-клиента и попробовал по самбе прокачать файлик.
>> Скорость как и на винде низкая... Хрень в общем какая-то. Поставил
>> wireshark чтобы посмотреть tcpstream, но то-ли я чего-то не понимаю, но
>> ничего подозрительного пока не заметил...
> В общем при анализе TCPStream увидел очень много TCP Retransmision и TCP
> DupACK
> Проблемма аналогичная http://blogs.technet.com/b/networking/archive/2011/05/16/tcp...
> Но пока не решил...
> В догонку на циске тоже было обсуждение: https://supportforums.cisco.com/thread/201894Следующий этап - прогнать с линуха на линух по самбе :)
и если там все будет нормально - таки есть плешь микрософту....
>[оверквотинг удален]
>>> Скорость как и на винде низкая... Хрень в общем какая-то. Поставил
>>> wireshark чтобы посмотреть tcpstream, но то-ли я чего-то не понимаю, но
>>> ничего подозрительного пока не заметил...
>> В общем при анализе TCPStream увидел очень много TCP Retransmision и TCP
>> DupACK
>> Проблемма аналогичная http://blogs.technet.com/b/networking/archive/2011/05/16/tcp...
>> Но пока не решил...
>> В догонку на циске тоже было обсуждение: https://supportforums.cisco.com/thread/201894
> Следующий этап - прогнать с линуха на линух по самбе :)
> и если там все будет нормально - таки есть плешь микрософту....С линуха на линух по самбе тоже самое (низкая скорость)
>[оверквотинг удален]
>>>> wireshark чтобы посмотреть tcpstream, но то-ли я чего-то не понимаю, но
>>>> ничего подозрительного пока не заметил...
>>> В общем при анализе TCPStream увидел очень много TCP Retransmision и TCP
>>> DupACK
>>> Проблемма аналогичная http://blogs.technet.com/b/networking/archive/2011/05/16/tcp...
>>> Но пока не решил...
>>> В догонку на циске тоже было обсуждение: https://supportforums.cisco.com/thread/201894
>> Следующий этап - прогнать с линуха на линух по самбе :)
>> и если там все будет нормально - таки есть плешь микрософту....
> С линуха на линух по самбе тоже самое (низкая скорость)Тада можно списать на архитектурные недостатки самого протокола....
>[оверквотинг удален]
>>>>> ничего подозрительного пока не заметил...
>>>> В общем при анализе TCPStream увидел очень много TCP Retransmision и TCP
>>>> DupACK
>>>> Проблемма аналогичная http://blogs.technet.com/b/networking/archive/2011/05/16/tcp...
>>>> Но пока не решил...
>>>> В догонку на циске тоже было обсуждение: https://supportforums.cisco.com/thread/201894
>>> Следующий этап - прогнать с линуха на линух по самбе :)
>>> и если там все будет нормально - таки есть плешь микрософту....
>> С линуха на линух по самбе тоже самое (низкая скорость)
> Тада можно списать на архитектурные недостатки самого протокола....Сегодня попробую ещё на семёрке погонять. Вообще, нормальные реализации tcp-стека должны уметь делать reordering сегментов...
>>>> Следующий этап - прогнать с линуха на линух по самбе :)
>>>> и если там все будет нормально - таки есть плешь микрософту....
>>> С линуха на линух по самбе тоже самое (низкая скорость)
>> Тада можно списать на архитектурные недостатки самого протокола....
> Сегодня попробую ещё на семёрке погонять. Вообще, нормальные реализации tcp-стека должны
> уметь делать reordering сегментов...На 7-ке производительность выросла в 2 раза.