Перейти к содержимому
Калькуляторы

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

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

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

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

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

Вопросы:

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

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

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

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

 

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

Маршруты:

Было:

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

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

 

Поменяли на

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

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

 

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

 

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

 

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

Изменено пользователем yuriy.ufa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

Маршруты:

Было:

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

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

 

Поменяли на

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

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

 

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

 

 

 

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

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

 

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

Изменено пользователем yuriy.ufa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Изменено пользователем yuriy.ufa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

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

Изменено пользователем 7net7

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

NAT-в нет.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Изменено пользователем Tosha

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Cisco 7604

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

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

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.