Здравствуйте!
Имеется VPN-сервер и Cisco 3750. К VPN-у ведут два маршрута, как сделать так что 3750 осуществлял балансировку раскидывая случайным образом трафик на инициализацию TCP-сессий, и при этом "запоминал" по какому маршруту было установлено TCP сессия и в дальнейшем установленные TCP сессии маршрутизировал по этим "запомненным" маршрутам?
>Здравствуйте!
>Имеется VPN-сервер и Cisco 3750. К VPN-у ведут два маршрута, как сделать
>так что 3750 осуществлял балансировку раскидывая случайным образом трафик на инициализацию
>TCP-сессий, и при этом "запоминал" по какому маршруту было установлено TCP
>сессия и в дальнейшем установленные TCP сессии маршрутизировал по этим "запомненным"
>маршрутам?
>Маршруты равновесные? Если да то
ip cef load-sharing algorithm include-ports source destinationЕсли нет, то нужно поднимать eigrp и в нем использовать variance.
>[оверквотинг удален]
>>так что 3750 осуществлял балансировку раскидывая случайным образом трафик на инициализацию
>>TCP-сессий, и при этом "запоминал" по какому маршруту было установлено TCP
>>сессия и в дальнейшем установленные TCP сессии маршрутизировал по этим "запомненным"
>>маршрутам?
>>
>
>Маршруты равновесные? Если да то
>ip cef load-sharing algorithm include-ports source destination
>
>Если нет, то нужно поднимать eigrp и в нем использовать variance.маршруты равновесные. на 3750 команды такой нет:
sw1-prom111(config)#ip cef load-sharing algorithm ?
original Original algorithm
tunnel Algorithm for use in tunnel only environments
universal Algorithm for use in most environmentsпосмотрел на Cisco 7206 команда "ip cef load-sharing algorithm include-ports source destination" есть. А что собственно она делает и как работает? неужто решение моей задачи ?
eigrp с VPN-сервером поднять нет возможности ибо VPN на базе FreeBSD... eigrp по-моему закрытый протокол и на FreeBSD его реализации нет...
>[оверквотинг удален]
> original Original algorithm
> tunnel Algorithm for use in tunnel
>only environments
> universal Algorithm for use in most environments
>
>посмотрел на Cisco 7206 команда "ip cef load-sharing algorithm include-ports source destination"
>есть. А что собственно она делает и как работает? неужто решение
>моей задачи ?
>eigrp с VPN-сервером поднять нет возможности ибо VPN на базе FreeBSD... eigrp
>по-моему закрытый протокол и на FreeBSD его реализации нет...закрытый, только панталон открытый панталон...
CEF уже может делать распредление нагрузки от источника при наличии равноправных маршутов в RIB
ip route a.a.a.a/a -> x.x.x.x1
ip route a.a.a.a/a -> x.x.x.x2вот только смысл в данной балансировки мало понятнет, хотя вам панталонам как я вижу самим всеровно что делать...
>[оверквотинг удален]
>
>закрытый, только панталон открытый панталон...
>
>CEF уже может делать распредление нагрузки от источника при наличии равноправных маршутов
>в RIB
>ip route a.a.a.a/a -> x.x.x.x1
>ip route a.a.a.a/a -> x.x.x.x2
>
>вот только смысл в данной балансировки мало понятнет, хотя вам панталонам как
>я вижу самим всеровно что делать...chesnok: оставьте свою параноидальную тему насчет панталонов))) если панталон существует значит это кому-то нужно, например мне и тысячам других людей). Давайте оставим это тему и поговорим о предмете этого трэда.
не уверен что я все правильно объяснил и потому, как мне кажется, вы мне ответили не то что нужно)
объясню еще раз более подробной что я хочу сделать:
есть Cisco 3750 и VPN сервер (pptp), VPN-сервер двумя сетевыми интерфейсами подключен к 3750 в 1-ый и 2-ой порт соответсвенно point-to-point адресами, на обоих сетевых интерфейсах в качестве secondary интерфейса записан одинаковый ip, этот ip адрес является адресом VPN-сервера по которому собственно все клиенты сети подключаются к нему(vpn-серверу).
Вот что я хочу от 3750: необходимо чтобы 3750 пакеты на инициализацию vpn-подключения балансировала между первым и вторым интерфейсом 3750, НО установленные vpn-подключения должны маршрутизироваться именно на тот интерфейс с которого было установлено соединение!
На FreeBSD у меня такое получилось сделать с помощью правил prob, checkstate/keepstate, как сделать такое на 3750 не представляю пока...
только через slb, но на 3750 его нет.
>только через slb, но на 3750 его нет.спасибо за ответ. slb прямо то что надо, жалко что его не поддерживает 3750. при slb маршрутизатор расбрасывающий запросы к серверам будет обрабатывать весь трафик, в том числе и после установки клиентом соединения с сервером ???
Я еще очень на надеюсь что мою задачу можно решить как-нибудь фичами и костылями на 3750 :)
после установки соединения маршрутизатор с slb будет его просто форвардидь в фастсвитчинг.
на 3750, думаю, этой задачи не решить.
>Вот что я хочу от 3750: необходимо чтобы 3750 пакеты на инициализацию
>vpn-подключения балансировала между первым и вторым интерфейсом 3750, НО установленные vpn-подключенияА может собрать обыкновенный "Port-channel" и "port-channel load-balance" разбрасываешь сессии. Для 3750 это вполне по силам :о)
>>Вот что я хочу от 3750: необходимо чтобы 3750 пакеты на инициализацию
>>vpn-подключения балансировала между первым и вторым интерфейсом 3750, НО установленные vpn-подключения
>
>А может собрать обыкновенный "Port-channel" и "port-channel load-balance" разбрасываешь сессии. Для
>3750 это вполне по силам :о)спасибо за идею) оригинальное, как мне кажется, решение, оно подходит к проблеме что я описал в своем первом посте, но я там несколько упростил схему для более легкого понимания форумчан что мне надо. На самом деле два линка идут каждый к своему серверу (а не одному как я описал вначале поста)... провести агрегацию физических интерфейсов на разных серверах наверно сделать нельзя... или можно ?
провести агрегацию физических интерфейсов на
>разных серверах наверно сделать нельзя... или можно ?Нет, на разные сервера агрегировать нельзя.
Нужно ещё подумать.
>На
>самом деле два линка идут каждый к своему серверу (а не
>одному как я описал вначале поста)...Наверное самый простой вариант в данном случае, будет всё-таки предложенный chesnokом. Создать два равноценных маршрута написать роутмапу, поделив ею сеть (допустим) на чётные и не чётные IP, и собственно всё :о) и балансировка обеспечена, и сессии всегда будут идти на одно устройство, и 3750 это умеет.
>>На
>>самом деле два линка идут каждый к своему серверу (а не
>>одному как я описал вначале поста)...
>
>Наверное самый простой вариант в данном случае, будет всё-таки предложенный chesnokом. Создать
>два равноценных маршрута написать роутмапу, поделив ею сеть (допустим) на чётные
>и не чётные IP, и собственно всё :о) и балансировка обеспечена,
>и сессии всегда будут идти на одно устройство, и 3750 это
>умеет.а как роут-мапом раскидать четные и нечетные ip ?
и несколько не понятно зачем писать равноценные маршруты если в роут-мапе явно можно указать ip следующего хопа. Мои два сервера имеют одинаковый secondary ip, к которому все пользователи собственно будут подключаться. В роут-мапе для четных next-hop установлю primary ip первого сервера, для нечетных primary ip второго сервера. Только как четные и нечетные ip получить ?
>а как роут-мапом раскидать четные и нечетные ip ?Чётные и не четные IP получаются с помощью обратной маски в ACL когда создаётся route-map.
А статические маршруты помогут в случае падения одного из интерфейов. Но с этим нужно разбираться. Тебя же интересовал концептуальный подход? :о)
>>а как роут-мапом раскидать четные и нечетные ip ?
>
>Чётные и не четные IP получаются с помощью обратной маски в
>ACL когда создаётся route-map.
>А статические маршруты помогут в случае падения одного из интерфейов. Но с
>этим нужно разбираться. Тебя же интересовал концептуальный подход? :о)а да точно, туплю, сообразил) в последнее время столько перечитал, только информации роится в голове (по больше части не нужной) что базовые вещи позабыл)))) вообще это не обратная маска, это wildcard (более широкое понятие), в нем нули могут прерывать ряд единиц а потому является обратной маской только в частных случаях :)
За концептуальнй подход спасибо, скорее всего так это и реализую... правда уже появляются новые вопросы. Почитал про роут-мапы пишут включение на интерфейсе роут-мапа автоматически отключает на интерфейсе fast switching какой тип коммутации включается не написано, но я догадываюсь что программная коммутация... от большого кол-ва трафика при программной коммутации свич умрет, но вроде бы и панацею расскопал ip route-cach policy кэширует маршрут и программной коммутации будет подвергаться только первый пакет, что на производителньости скажется не сильно (я так думаю)
а насчет падения интерфейсов решу вопрос динамической маршрутизацией (ospf)
Если трафик на столько большой что 3750 с ним не справится, тогда нужно покупать 65 каталист с сервайс модулями и slb доступно и трафика сколько угодно :о)
При ентом я на сколько помню чистый гигабит предоставляет как раз только 65, а во всех остальных каталистах он как бы делиться между 8ю портами. Так что серваки ещё нужно правильно подключать к интерфейсам… так сказать для лучшей производительности.
>Если трафик на столько большой что 3750 с ним не справится, тогда
>нужно покупать 65 каталист с сервайс модулями и slb доступно и
>трафика сколько угодно :о)
>При ентом я на сколько помню чистый гигабит предоставляет как раз только
>65, а во всех остальных каталистах он как бы делиться между
>8ю портами. Так что серваки ещё нужно правильно подключать к интерфейсам…
>так сказать для лучшей производительности.у него не блокируемая матрица