Перейти до

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


Рекомендованные сообщения

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

 

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

 

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

 

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

Відредаговано ][-RaY
Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 52
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

А зачем в этой схеме MX80 вообще? Он должен был по идее стоять вместо  ExtreameX480. MX80 либо бордером либо брасом ставить а в вашей схеме всё это уже есть.

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

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

чем больше шкаф, тем громче падает...
Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Відредаговано Гайджин
Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

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

Відредаговано John_Doe
Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

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

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

 

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

Можно, но можно второй и не тушить если схема и время позволяет проехать на одном.
Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Ссылка на сообщение
Поделиться на других сайтах

 

 

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

 

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

Ссылка на сообщение
Поделиться на других сайтах

 

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

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

 

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

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

Ссылка на сообщение
Поделиться на других сайтах

 

 

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

 

 

 

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

 

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

Ссылка на сообщение
Поделиться на других сайтах

 

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

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

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

 

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

 

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

 

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

Відредаговано John_Doe
Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

Аля pppoe?

Ссылка на сообщение
Поделиться на других сайтах

 

Ребята, а кто как резервирует и балансирует нагрузку 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....

Відредаговано NEP
Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від xserver
      Продам полностью рабочий маршрутизатор Juniper MX80.
      2 модуля MIC-3D-20GE-SFP (20 портов 1Гбит/с SFP)
      2 блока питания
       
      Сброшен до заводских настроек.
       
      Цена — $1000.
       


    • Від neom
      Продам Juniper MX104-AC
      Активированы все максимальные лицензии, все порты.
      Эксплуатировался в идеальных условиях.
       
      цена 4500$
      можно по безналу от ФОП на едином налоге.

    • Від Інет.укр
      Продам Juniper mx5-t 
      Ціна 3к $ за mx5-t з ліцензією mx80, та картою nat ms-mic-16g
      Гарантія
      Рахунок від ФОП / готівка / usd-t
      Licenses Licenses Licenses Expiry Feature name used installed needed subscriber-accounting 1 1 0 permanent subscriber-authentication 1 1 0 permanent subscriber-address-assignment 1 1 0 permanent subscriber-vlan 0 1 0 permanent subscriber-ip 0 1 0 permanent service-dc 0 1 0 permanent service-accounting 0 1 0 permanent service-qos 0 1 0 permanent service-ancp 0 1 0 permanent service-cbsp 0 1 0 permanent scale-subscriber 1 16000 0 permanent scale-l2tp 0 1000 0 permanent mx5-to-mx10-upgrade 0 1 0 permanent mx10-to-mx40-upgrade 0 1 0 permanent mx40-to-mx80-upgrade 0 1 0 permanent  
      Hardware inventory: Item Version Part number Serial number Description Chassis H3600 MX5-T Midplane REV 11 711-038215 CACY6546 MX5-T PEM 0 Rev 05 740-028288 XA01811 AC Power Entry Module Routing Engine BUILTIN BUILTIN Routing Engine TFEB 0 BUILTIN BUILTIN Forwarding Engine Processor QXM 0 REV 07 711-028408 CACY5268 MPC QXM FPC 0 BUILTIN BUILTIN MPC BUILTIN MIC 0 BUILTIN BUILTIN 4x 10GE XFP PIC 0 BUILTIN BUILTIN 4x 10GE XFP Xcvr 1 qL+m NON-JNPR XA97100143 XFP-10G-LR MIC 1 REV 18 750-043688 CAEE3819 MS-MIC-16G PIC 2 BUILTIN BUILTIN MS-MIC-16G FPC 1 BUILTIN BUILTIN MPC BUILTIN Fan Tray Fan Tray  
       
    • Від kotqq
      Продам Juniper mx5, с платой на 20сфп, апнут до мх80, 64к сабов, цена 1700$


    • Від all_we_crazy
      juniper mx960
      4x блоки живлення ac200-240V 4.1kW
      2x плати керування RE-S-1800x4
      3x switch control board Enhanced
      1x MPC Type 2 3D EQ з двома MIC слотами
      1x Аплінк плата MIC 4x10GE XFP
      1x аплінк плата MPC 3D 16x 10GE
      1x MS-MPC (до 50 гігів можна натити)
      2x Fan Tray
       — ціна 9к за все разом
       
      є ще таке саме, але замість MIC 4x10GE XFP плата MPC 3D 16x 10GE
      — ціна 10к
      Також роздяну варіант продажу плати для нату окремо від корзини

×
×
  • Створити нове...