Jump to content
Калькуляторы

Проблема маршрутизации в схеме с резервированием легче сразу показать схему, чем объяснять словами

Дано: Клиентский VLAN агрегируются на нескольких железяках(AGR1, AGR2), которые делят адрес шлюза (например, по CARP или HSRP). Путь в ядро с железяк лежит через другую железяку (GW).

 

Задача: с GW отправлять пакеты к клиентам через ту AGR, с которой был последний(?) пакет наружу.

post-69700-061743300 1301916206_thumb.png

Edited by Wotapakaudoin

Share this post


Link to post
Share on other sites

Ни CARP, ни HSPR этим не занимаются.

А в чём смысл сего начинания, если не секрет?

Share this post


Link to post
Share on other sites

ARP proxy, если PPtP, PPPoE?

иначе, можно NAT-ом победить, я думаю)

Edited by dignity

Share this post


Link to post
Share on other sites

Ни CARP, ни HSPR этим не занимаются.

А в чём смысл сего начинания, если не секрет?

 

CARP и HSPR в схеме отвечают за то, чтобы балансировать трафик клиентов 10.0.0.0/8.

С этим проблем нет - всё работает.

Загвоздка только в том, что есть необходимость возвращать пакеты через "родную" коробку.

Share this post


Link to post
Share on other sites

Ни CARP, ни HSPR этим не занимаются.

А в чём смысл сего начинания, если не секрет?

 

CARP и HSPR в схеме отвечают за то, чтобы балансировать трафик клиентов 10.0.0.0/8.

С этим проблем нет - всё работает.

Загвоздка только в том, что есть необходимость возвращать пакеты через "родную" коробку.

 

...вмешиваясь в работу CARP/HSPR сторонними средствами?

Ничего хорошего не выйдет.

Придётся самому допиливать нужный функционал.

C/C++ в помощь. :)

Share this post


Link to post
Share on other sites

ARP proxy, если PPtP, PPPoE?

да, забыл написать - агрегируем dot1q

 

иначе, можно NAT-ом победить, я думаю)

имеется ввиду поднять NAT на коробках AGR, чтобы до GW клиенты доходили отначенные с разных внутренних адресов?

в принципе, это выход - но совсем не входит в роль AGR.

 

Ни CARP, ни HSPR этим не занимаются.

А в чём смысл сего начинания, если не секрет?

 

CARP и HSPR в схеме отвечают за то, чтобы балансировать трафик клиентов 10.0.0.0/8.

С этим проблем нет - всё работает.

Загвоздка только в том, что есть необходимость возвращать пакеты через "родную" коробку.

 

...вмешиваясь в работу CARP/HSPR сторонними средствами?

Ничего хорошего не выйдет.

Придётся самому допиливать нужный функционал.

C/C++ в помощь. :)

 

уже жалею, что написал эти латинские буковки ;))

 

лучше написать так: волшебным образом пакеты от клиентов одной большой подсети идут либо через коробку AGR1, либо через коробку AGR2. Есть ли какой-то прекрасный волшебный способ научить третью коробку GW передавать пакеты для клиентов большой подсети именно через ту коробку, через которую волшебным образом клиент посылает пакеты.

Share this post


Link to post
Share on other sites

Запоминать что откуда пришло, причём запоминать надолго, т.к. ответ и через секунду может придти, да ещё и балансировать при этом - взаимоисключающие задачи.

Без волшебства - никак. :)

Edited by Deac

Share this post


Link to post
Share on other sites

Анонсировать динамикой разные блоки адресов с разных AGR, должно работать асимметрично и нормально балансироваться.

Ну а дальше можно прикрутить мегакостыль, типа сливать netflow (каждый пакет анализировать смысла нет, пользователь будет отправлять все на один AGR), выгребать оттуда адреса, прописывать уже точные /32 маршруты, ну и удалять, соответственно, по таймату. Ужос в общем.

Edited by Valaskor

Share this post


Link to post
Share on other sites

А как балансируется исход от клиента ? У меня часть вланов с большим приоритетом часть с меньшим на первом рутере, а на втором зеркально. Соотвественно при живых обоих трафик от 1 абонента ВСЕГДА идет через 1 а от другого через 2. Между gw и AGR на каждом AGR по 2 сарпа, с теми же весами, и на gw таблица маршрутизации все "волшебным" образом заворачивает взад (ну я же заранее знаю откуда у меня какие веса стояли). при падении одного все сходится на втором.

 

Балансируется путем теории вероятности, что абонентов и их трафика получается +- поровну..

Share this post


Link to post
Share on other sites

Анонсировать динамикой разные блоки адресов с разных AGR, должно работать асимметрично и нормально балансироваться.

Ну а дальше можно прикрутить мегакостыль, типа сливать netflow (каждый пакет анализировать смысла нет, пользователь будет отправлять все на один AGR), выгребать оттуда адреса, прописывать уже точные /32 маршруты, ну и удалять, соответственно, по таймату. Ужос в общем.

да, это не торт

Share this post


Link to post
Share on other sites

А как балансируется исход от клиента ? У меня часть вланов с большим приоритетом часть с меньшим на первом рутере, а на втором зеркально. Соотвественно при живых обоих трафик от 1 абонента ВСЕГДА идет через 1 а от другого через 2. Между gw и AGR на каждом AGR по 2 сарпа, с теми же весами, и на gw таблица маршрутизации все "волшебным" образом заворачивает взад (ну я же заранее знаю откуда у меня какие веса стояли). при падении одного все сходится на втором.

 

Балансируется путем теории вероятности, что абонентов и их трафика получается +- поровну..

 

Тут беда в том, что VLAN агрегируется единственный.

Share this post


Link to post
Share on other sites

Автор делает что-то через попу, вот что именно понять не получается....

К примеру: а добавить связь между AGR1 и AGR2? Пусть они там сами разберутся кто куда. Да и какая вам разница через какой агрегатор вернётся трафик?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this