Балансировка+резервирование IPOE (Juniper MX80)

[][-RaY 387]

Ребята, а кто как резервирует и балансирует нагрузку IPOE подключений? 

 

В моем случае схема vlan на дом, клиенты по option82, получают реальные адреса из пула динамически, BRASит их Juniper mx80. Так как они иногда не прочь помереть или побутаться(что как бы 20 минут), решили доставить еще 1 для резерва, с pppoe все просто, воткнул что угодно рядом(софт тазик, se100) и pppoe себе расползается, а вот с IPOE как то сложнее, что то пока не могу придумать ничего, как сделать это максимально прозрачно и автоматически, что бы в случае падения одного, все конектились на второй(третий, n-нный). 

 

Пока есть идея, какая то топорная, раскидать вланы (чет нечет например) и половину вланов запустить через первый, вторую половину вланов через второй, но вланы завести все на каждый, просто активны будут только "свои", а в случае падения, поднимаются все вланы, но это время реагирования 5-15 минут+обновление адресов по dhcp 1-15 минут, пролежит все так эдак пол часа и более, как то не очень выглядит... 

 

У джуна когда то они обещали сделать ipoe балансировку и резервирование, но что с ходу не нашел, может кто пнет меня в нужную сторону?

Відредаговано 2015-01-28 23:47:37 ][-RaY

[John_Doe 301]

иметь два идентично настроенных мх. со стороны биллинга чекать что насы живые и как только вдруг один помирает прибивать все сессии поднятые с него. Ну а лиза в 5-15 минут дает вам переключение с наса на нас от нескольких секунд до 5-15 минут грубо.в максимуме у некоторых клиентов простой будет равен времени лизы.

Соответственно лиза 2-5 минут будет давать вполне приемлемое время переключения

[Sergek 123]

В теории изящней будет, если влан на пользователя ака qnq.

Svlanы будут на обеих брасах кто первый затерменировал пациента тот и папа, аля пппое. С опт82 мне кажеться изящества не получиться.

Но это теория, практика пока в процессе.

[Гайджин 574]

  " сказав:

В моем случае схема vlan на дом, клиенты по option82, получают реальные адреса из пула динамически, BRASит их Juniper mx80. Так как они иногда не прочь помереть или побутаться(что как бы 20 минут), решили доставить еще 1 для резерва, с pppoe все просто, воткнул что угодно рядом(софт тазик, se100) и pppoe себе расползается, а вот с IPOE как то сложнее, что то пока не могу придумать ничего, как сделать это максимально прозрачно и автоматически, что бы в случае падения одного, все конектились на второй(третий, n-нный).

Ну первое что приходит в голову это завести все домовые вланы на обе коробки, на каждой коробке интерфейс в домовом влане, поверх этого vrrp в шахматном порядке. Управление выдачей адресов вынести на радиус/дшцп отдельностоящий и вносить рандомные задержки в ответы на радиус/дшцп.

Если реализовывать через s-vlan|c-vlan то вррп как бы и не нужно.

[rsst 406]

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

[kha0s 112]

Тьфу-тьфу. Но никто не застрахован. Ракеты (те что в космос а не...) вона падают, а цена их...

[adeep 212]

  В 29.01.2015 в 07:10, rsst сказав:

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

чем больше шкаф, тем громче падает...

[martin 170]

если включить все вланы в оба МХ - все рассосется само, юзера примет тот МХ который быстрее ответит. Нужно только выдавать ИП из базы по хитрому, чтобы не зависли одни и теже ИП на двух Брасах

[Гайджин 574]

  В 29.01.2015 в 09:16, martin сказав:

если включить все вланы в оба МХ - все рассосется само, юзера примет тот МХ который быстрее ответит. Нужно только выдавать ИП из базы по хитрому, чтобы не зависли одни и теже ИП на двух Брасах

Только в случае вывода в регламент одного из них Ты получиш временную неработоспособность клиентов на нем сидящих на время равное 0.75 лиз-тайм.

С вррп все пройдет гладко.

Відредаговано 2015-01-29 09:48:03 Гайджин

[John_Doe 301]

  В 29.01.2015 в 09:47, Гайджин сказав:

С вррп все пройдет гладко.

Не пройдет.Смотрим,влан на юзера,есно QinQ, динамические профили создают эти вланы при авторизации по дшсп запросу.

И тут один мх упал. Куда пойдет пакет от клиента? да никуда потому что на втором мх нет этих интерфейсов и они не поднимутся без дшсп запроса

И самое правильное в этой ситуации, это прибивать сессии по базе, открытые на том который ушел в регламент и лизу по меньше

 

Упс, у ТС влан на дом, но сути это не меняет. Если домов 5-10 то держать статические интерфейсы можно тогда и vrrp отлично подойдет. Если их сотни то статически прибивать их смысла нет и получается все тоже что и для QinQ

Відредаговано 2015-01-29 10:45:54 John_Doe

[Sergek 123]

Если это регламент можно и оба потушить в специально оговоренное время.

[Гайджин 574]

  В 29.01.2015 в 10:29, John_Doe сказав:

Не пройдет.Смотрим,влан на юзера,есно QinQ, динамические профили создают эти вланы при авторизации по дшсп запросу.

Смотреть нужно в условие задачи, а не во "влан пер морда". - ИксРей сказал что влан на дом.

Про то как оно там демуксится и что там динамически создается - ни слова.

 

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

  В 29.01.2015 в 10:29, John_Doe сказав:

И тут один мх упал. Куда пойдет пакет от клиента? да никуда потому что на втором мх нет этих интерфейсов и они не поднимутся без дшсп запроса

И самое правильное в этой ситуации, это прибивать сессии по базе, открытые на том который ушел в регламент и лизу по меньше

Вы что такое вррп достаточно понимаете? - Один погаснет, дефолт гейтвей переедет на второй моментально.

 

  В 29.01.2015 в 10:43, Sergek сказав:

Если это регламент можно и оба потушить в специально оговоренное время.

Можно, но можно второй и не тушить если схема и время позволяет проехать на одном.

[dir1212 9]

В целом идеи с VRRP, временем lease и т.п. конечно не плохи, но если важна критичность, то я бы смотрел в сторону virtual chassis - но там нужно хотя-бы МХ240.

Более 16к подписчиков все равно на МХ80 не рекомендуется + процессор не дает быстро набирать подписчиков в случае DHCP/ARP штормов.

 

ИМХО платформа больше под агрегацию - но никак не BNG.

[kha0s 112]

 

 

  В 29.01.2015 в 10:56, dir1212 сказав:

В целом идеи с VRRP, временем lease и т.п. конечно не плохи, но если важна критичность, то я бы смотрел в сторону virtual chassis - но там нужно хотя-бы МХ240.

 

Это понятно но по условиям задачи уже имеется пара мх80 и именно из нее надо соорудить максимально возможный failover 

[Гайджин 574]

  В 29.01.2015 в 10:59, kha0s сказав:

 

  В 29.01.2015 в 10:56, dir1212 сказав:

В целом идеи с VRRP, временем lease и т.п. конечно не плохи, но если важна критичность, то я бы смотрел в сторону virtual chassis - но там нужно хотя-бы МХ240.

Это понятно но по условиям задачи уже имеется пара мх80 и именно из нее надо соорудить максимально возможный failover

 

По условиям задачи второго мх80 еще нет.

Да и мх240 в задачу явно не лезет (финансово) если задумались о втором мх80.

[loki 86]

Извращения в виде  VRRP+ PBR + SLA

Відредаговано 2015-01-29 11:47:38 loki

[kha0s 112]

 

 

  В 29.01.2015 в 11:15, Гайджин сказав:

По условиям задачи второго мх80 еще нет.

 

 

 

  Цитата

[-RaY' timestamp=1422486871' post='714862] BRASит их Juniper mx80. Так как они иногда не прочь помереть или побутаться(что как бы 20 минут), решили доставить еще 1 для резерва

 

oops, "решили доставить" я прочитал как "доставили".

[John_Doe 301]

  В 29.01.2015 в 10:49, Гайджин сказав:

 

  В 29.01.2015 в 10:29, John_Doe сказав:

Не пройдет.Смотрим,влан на юзера,есно QinQ, динамические профили создают эти вланы при авторизации по дшсп запросу.

Смотреть нужно в условие задачи, а не во "влан пер морда". - ИксРей сказал что влан на дом.

Про то как оно там демуксится и что там динамически создается - ни слова.

 

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

 

Про то что они там созданы статически тоже не говорится кстати.Так что мы оба предположили каждый о своем, и каждый предложил свое решение

 

PS.Создать статически вланы на 100500 домов трудно назвать простым вариантом 

Відредаговано 2015-01-29 18:08:05 John_Doe

[Sergek 123]

Может показаться странным, но мы будем резервировать тазиками с акселем.

Опыт во время войны уже был. Вполне рабочий вариант!

[][-RaY 387]

У меня так pppoe зарезервленно тазик и se100 Переезжать что ли с влан на дом на влан на юзера...

[Abram 98]

vlan на юзера (qinq) - самое оно. И балансируется, и резервируется легко.

[Sergek 123]

  В 29.01.2015 в 21:14, Abram сказав:

vlan на юзера (qinq) - самое оно. И балансируется, и резервируется легко.

У вас резервирование и балансировка на акселях?

Аля pppoe?

[NEP 217]

  В 28.01.2015 в 23:14, ][-RaY сказав:

 

Ребята, а кто как резервирует и балансирует нагрузку IPOE подключений? 

 

В моем случае схема vlan на дом, клиенты по option82, получают реальные адреса из пула динамически, BRASит их Juniper mx80. Так как они иногда не прочь помереть или побутаться(что как бы 20 минут), решили доставить еще 1 для резерва, с pppoe все просто, воткнул что угодно рядом(софт тазик, se100) и pppoe себе расползается, а вот с IPOE как то сложнее, что то пока не могу придумать ничего, как сделать это максимально прозрачно и автоматически, что бы в случае падения одного, все конектились на второй(третий, n-нный). 

 

Пока есть идея, какая то топорная, раскидать вланы (чет нечет например) и половину вланов запустить через первый, вторую половину вланов через второй, но вланы завести все на каждый, просто активны будут только "свои", а в случае падения, поднимаются все вланы, но это время реагирования 5-15 минут+обновление адресов по dhcp 1-15 минут, пролежит все так эдак пол часа и более, как то не очень выглядит... 

 

У джуна когда то они обещали сделать ipoe балансировку и резервирование, но что с ходу не нашел, может кто пнет меня в нужную сторону?

 

 

 

Все проще

 

 

1. перенаправляешь DHCP relay на LVS/IPVS кластер перед двумя MX80

2. ставишь в кластер 2хLinux с LVS/IPVS балансером UDP (тех самых DHCP запросов авторизации) - выбираешь на нем любой алгоритм например round-robin и перенаправляешь поочередно на 2хMX80

3. 2хMX80 и LVS/IPVS кластер и все коммутаторы для которых задан этот адрес Relay должны быть ВСЕ  в одно мвлане (ну естественно кроме шнурка, которые соединяет у тебя 2 Linux в кластере)

4. На кластере любой контроль доступности MX80, который в случае недоступности убирает/добавляет любой из брасов в конфигурацию балансера. 

 

Чтобы схема работала на интерфейсы MX80 куда включен балансер алиасом вешаешь адрес Relay сервера с маской /32 (ну это все расписано в мануалах по LVS)

 

 

схема работает от 1 до N x MX80

 

Кстати точно также можно балансировать DNS, HTTP, FTP....

Відредаговано 2015-01-30 08:57:13 NEP

[][-RaY 387]

Спасиб, почитаю что там и как.

[kha0s 112]

Нагрузка какая? мх я так подозреваю не на гигосик покупался? линуксам плохо не станет гбит на сорок?