Wotapakaudoin Опубликовано 4 апреля, 2011 (изменено) · Жалоба Дано: Клиентский VLAN агрегируются на нескольких железяках(AGR1, AGR2), которые делят адрес шлюза (например, по CARP или HSRP). Путь в ядро с железяк лежит через другую железяку (GW). Задача: с GW отправлять пакеты к клиентам через ту AGR, с которой был последний(?) пакет наружу. Изменено 4 апреля, 2011 пользователем Wotapakaudoin Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 4 апреля, 2011 · Жалоба Ни CARP, ни HSPR этим не занимаются. А в чём смысл сего начинания, если не секрет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dignity Опубликовано 4 апреля, 2011 (изменено) · Жалоба ARP proxy, если PPtP, PPPoE? иначе, можно NAT-ом победить, я думаю) Изменено 4 апреля, 2011 пользователем dignity Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wotapakaudoin Опубликовано 4 апреля, 2011 · Жалоба Ни CARP, ни HSPR этим не занимаются. А в чём смысл сего начинания, если не секрет? CARP и HSPR в схеме отвечают за то, чтобы балансировать трафик клиентов 10.0.0.0/8. С этим проблем нет - всё работает. Загвоздка только в том, что есть необходимость возвращать пакеты через "родную" коробку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 4 апреля, 2011 · Жалоба Ни CARP, ни HSPR этим не занимаются. А в чём смысл сего начинания, если не секрет? CARP и HSPR в схеме отвечают за то, чтобы балансировать трафик клиентов 10.0.0.0/8. С этим проблем нет - всё работает. Загвоздка только в том, что есть необходимость возвращать пакеты через "родную" коробку. ...вмешиваясь в работу CARP/HSPR сторонними средствами? Ничего хорошего не выйдет. Придётся самому допиливать нужный функционал. C/C++ в помощь. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wotapakaudoin Опубликовано 4 апреля, 2011 · Жалоба 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 передавать пакеты для клиентов большой подсети именно через ту коробку, через которую волшебным образом клиент посылает пакеты. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 4 апреля, 2011 (изменено) · Жалоба Запоминать что откуда пришло, причём запоминать надолго, т.к. ответ и через секунду может придти, да ещё и балансировать при этом - взаимоисключающие задачи. Без волшебства - никак. :) Изменено 4 апреля, 2011 пользователем Deac Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Valaskor Опубликовано 4 апреля, 2011 (изменено) · Жалоба Анонсировать динамикой разные блоки адресов с разных AGR, должно работать асимметрично и нормально балансироваться. Ну а дальше можно прикрутить мегакостыль, типа сливать netflow (каждый пакет анализировать смысла нет, пользователь будет отправлять все на один AGR), выгребать оттуда адреса, прописывать уже точные /32 маршруты, ну и удалять, соответственно, по таймату. Ужос в общем. Изменено 4 апреля, 2011 пользователем Valaskor Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 4 апреля, 2011 · Жалоба А как балансируется исход от клиента ? У меня часть вланов с большим приоритетом часть с меньшим на первом рутере, а на втором зеркально. Соотвественно при живых обоих трафик от 1 абонента ВСЕГДА идет через 1 а от другого через 2. Между gw и AGR на каждом AGR по 2 сарпа, с теми же весами, и на gw таблица маршрутизации все "волшебным" образом заворачивает взад (ну я же заранее знаю откуда у меня какие веса стояли). при падении одного все сходится на втором. Балансируется путем теории вероятности, что абонентов и их трафика получается +- поровну.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wotapakaudoin Опубликовано 4 апреля, 2011 · Жалоба Анонсировать динамикой разные блоки адресов с разных AGR, должно работать асимметрично и нормально балансироваться. Ну а дальше можно прикрутить мегакостыль, типа сливать netflow (каждый пакет анализировать смысла нет, пользователь будет отправлять все на один AGR), выгребать оттуда адреса, прописывать уже точные /32 маршруты, ну и удалять, соответственно, по таймату. Ужос в общем. да, это не торт Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wotapakaudoin Опубликовано 4 апреля, 2011 · Жалоба А как балансируется исход от клиента ? У меня часть вланов с большим приоритетом часть с меньшим на первом рутере, а на втором зеркально. Соотвественно при живых обоих трафик от 1 абонента ВСЕГДА идет через 1 а от другого через 2. Между gw и AGR на каждом AGR по 2 сарпа, с теми же весами, и на gw таблица маршрутизации все "волшебным" образом заворачивает взад (ну я же заранее знаю откуда у меня какие веса стояли). при падении одного все сходится на втором. Балансируется путем теории вероятности, что абонентов и их трафика получается +- поровну.. Тут беда в том, что VLAN агрегируется единственный. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
secandr Опубликовано 4 апреля, 2011 · Жалоба Автор делает что-то через попу, вот что именно понять не получается.... К примеру: а добавить связь между AGR1 и AGR2? Пусть они там сами разберутся кто куда. Да и какая вам разница через какой агрегатор вернётся трафик? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...