Разные маршруты в разные стороны - проблемы HTTP

[yuriy.ufa]

Мы являемся организацией, обслуживающей корпоративную сеть Заказчика. Сеть построена "темных" волокнах, арендованных у оператора связи. Есть маршрутизаторы L3.

Так же у Заказчика другая компания внедряет программный продукт. Этот софт представляет из себя web-сервер, к которому через браузеры цепляются клиенты.

В один прекрасный день софт начал глючить - иногда при загрузке страницы браузер писал "соединение было сброшено". Скорость с рабочих станций до сервера под 100 мбит, все необходимые порты открыты, файрволлы убраны и т.п. Ошибка осталась.

Тогда компания-внедренец софта трейсроутом выяснила, что в сторону сервера пакеты ходят по одному пути, а обратно - по другому. Было предложено перемаршрутизировать так, что бы ходили по одному маршруту. По словам компании-внедренца это помогло.

Вопросы:

Как может влиять "одним или разными маршрутами ходят пакеты" на HTTP-трафик (и вообще на пользовательский трафик) ?

Подозревая, что на первый вопрос будет ответ "никак не должно", хотелось бы спросить

1) Где-нибудь в RFC есть запрет или разрешение на разные маршруты (требования к симметричной маршрутизации)?

2) Если все таки смена маршрутов действительно помогла, то в чем могут быть проблемы?

 

Тоннелей нет. Чистая маршрутизация.

Маршруты:

Было:

В одну сторону: Сервер - ХостА - ХостВ - Клиент

В другую сторону: Клиент - ХостВ - ХостБ - ХостА - Сервер

 

Поменяли на

В одну сторону: Сервер - ХостА - ХостБ - ХостВ - Клиент

В другую сторону: Клиент - ХостВ - ХостБ - ХостА - Сервер

 

ХостА, ХостБ и ХостВ находятся в одном широковещательном домене.

 

Исходная ситуация была связана с тем, что в Хосте В не было прямого маршрута на А и трафик ходил через маршрутизатор Б

 

Весь остальной трафик (интернет, СУБД на базе MS SQL, Lync, почта и т.п.) ходит нормально. Проблема с софтом Компании-внедренца непостоянна. Т.е. один раз из десяти связи нет.

Edited August 1, 2012 by yuriy.ufa

[darkagent]

Первое что лезет в голову - разное мту на трассах (может один из путей через какие-нибудь ip-ip/ip-gre туннели ходит).

[Ivan_83]

В случае л2 сегмента хосты общаются напрямую, и главное чтобы мак получателя не менялся.

В случае л3 хост шлёт пакеты роутеры и получает ответы от через него, либо от другого роутера. В общем особой разницы нет, ли бы дст мак и ип адреса были такими как ожидается.

В линуксах всякие rp фильтры могут трепать нервы дропая такие "неожиданные" пакеты, как ведёт себя винда не знаю, фря переваривает нормально.

 

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

[yuriy.ufa]

Первое что лезет в голову - разное мту на трассах (может один из путей через какие-нибудь ip-ip/ip-gre туннели ходит).

Тоннелей нет. Чистая маршрутизация.

Маршруты отличаются следующим.

 

Маршруты:

Было:

В одну сторону: Сервер - ХостА - ХостВ - Клиент

В другую сторону: Клиент - ХостВ - ХостБ - ХостА - Сервер

 

Поменяли на

В одну сторону: Сервер - ХостА - ХостБ - ХостВ - Клиент

В другую сторону: Клиент - ХостВ - ХостБ - ХостА - Сервер

 

Исходная ситуация была связана с тем, что в Хосте В не было прямого маршрута на А и трафик ходил через маршрутизатор Б

 

 

 

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

Конечные хостып получают пакеты на уровне L2 с единственного адреса.

 

Весь остальной трафик (интернет, СУБД на базе MS SQL, Lync, почта и т.п.) ходит нормально.

Edited August 1, 2012 by yuriy.ufa

[EDA_SPB]

1. Чисто логически такого документа быть не должно. Как в диком интернете обеспечить симметричную маршрутизацию?

[yuriy.ufa]

1. Чисто логически такого документа быть не должно. Как в диком интернете обеспечить симметричную маршрутизацию?

 

Корректно ли требование от Компании-внедренца - "Наличие симметричной маршрутизаци" ?

Edited August 1, 2012 by yuriy.ufa

[7net7]

ХостА, ХостБ и ХостВ находятся в одном широковещательном домене.

 

для чего тогда маршрутизация?

 

Исходная ситуация была связана с тем, что в Хосте В не было прямого маршрута на А и трафик ходил через маршрутизатор Б

 

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

а если все время по одному,имхо, маловероятны.

Edited August 1, 2012 by 7net7

[7net7]

В случае л2 сегмента хосты общаются напрямую, и главное чтобы мак получателя не менялся.

 

если имеют место игры с масками сетей, то проблемы может создавать маршрутизатор X с включенным proxy arp.

[EDA_SPB]

Корректно ли требование от Компании-внедренца - "Наличие симметричной маршрутизаци" ?

 

В общем случае, я думаю, да.

Тех. условия для внедрения компания вправе ставить любые.

Другое дело, соглашаться Вам с ними или нет.

Сферический веб сервер в вакууме работает с ассиметрией нормально, а точнее вообще о ней ничего не знает.

Но кто же знает что у вас установлено...

[Tosha]

Если компания применяет FWSM или его аналоги, например, для NAT и на нем включены инспекции, то tcp сессия не установится, если эта железка не увидит оба SYN пакета.

 

И если подобная железка стоит на "ХостБ" то это все объясняет.

[yuriy.ufa]

Если компания применяет FWSM или его аналоги, например, для NAT и на нем включены инспекции, то tcp сессия не установится, если эта железка не увидит оба SYN пакета.

 

И если подобная железка стоит на "ХостБ" то это все объясняет.

NAT-в нет.

Хосты A Б и В - маршрутизаторы.

[Tosha]

А какой именно маршрутизатор "ХостБ"?

 

Просто 76xx с FWSM это как бы тоже маршрутизатор... Просто с дополнительными функциями обеспечения безопасности.

 

В общем там весьма необычный маршрутизатор. Обычный маршрутизатор не заставишь проверить что обратный поток данных идет в обход.

Edited August 2, 2012 by Tosha

[yuriy.ufa]

А какой именно маршрутизатор "ХостБ"?

Cisco 7604

[Tosha]

Ну значит на нем стоит таки какой-то модуль повышения безопасности.

Либо обходить этот хост стороной либо просить чтобы для Вас делали исключения инспекций или вообще в обход контроля.