[Wotapakaudoin]

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

 

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

Изменено 4 апреля, 2011 пользователем Wotapakaudoin

[Deac]

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

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

[dignity]

ARP proxy, если PPtP, PPPoE?

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

Изменено 4 апреля, 2011 пользователем dignity

[Wotapakaudoin]

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

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

 

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

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

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

[Deac]

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

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

 

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

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

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

 

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

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

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

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

[Wotapakaudoin]

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 передавать пакеты для клиентов большой подсети именно через ту коробку, через которую волшебным образом клиент посылает пакеты.

[Deac]

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

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

Изменено 4 апреля, 2011 пользователем Deac

[Valaskor]

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

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

Изменено 4 апреля, 2011 пользователем Valaskor

[st_re]

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

 

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

[Wotapakaudoin]

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

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

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

[Wotapakaudoin]

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

 

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

 

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

[secandr]

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

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