Jump to content

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


Recommended Posts

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

 

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

 

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

 

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

Edited by ][-RaY
Link to post
Share on other sites
  • Replies 52
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

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

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

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

Link to post
Share on other sites

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

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

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

Link to post
Share on other sites

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

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

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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

чем больше шкаф, тем громче падает...
Link to post
Share on other sites

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

Link to post
Share on other sites

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

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

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

Edited by Гайджин
Link to post
Share on other sites

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

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

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

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

 

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

Edited by John_Doe
Link to post
Share on other sites

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

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

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

 

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

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

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

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

 

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

Можно, но можно второй и не тушить если схема и время позволяет проехать на одном.
Link to post
Share on other sites

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

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

 

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

Link to post
Share on other sites

 

 

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

 

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

Link to post
Share on other sites

 

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

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

 

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

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

Link to post
Share on other sites

 

 

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

 

 

 

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

 

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

Link to post
Share on other sites

 

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

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

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

 

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

 

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

 

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

Edited by John_Doe
Link to post
Share on other sites

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

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

Link to post
Share on other sites

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

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

Аля pppoe?

Link to post
Share on other sites

 

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

Edited by NEP
Link to post
Share on other sites

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

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
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Sergik_
      Продам полностью рабочее железо (снято с продакшна в связи с апгрейдом)
      Juniper mx5-t (mx80) - 1000$
      Juniper ms-mic-16g - 800$
      Juniper mic-3d-2xge-xfp - 200$
       
      p.s. так же продаём Сisco Nexus 9372PX и эффективное и недорогое решение для NAT 20gb/s, без напряга.
       
      ps.s. при необходимости-поможем все подружить друг с другом
       
      https://t.me/sergik_od
      +380632640070
    • By kotqq
      Продам новий Juniper NFX250-S2, ціна 350$
       
      Характеристики:
      Характеристика
      Модель: Juniper NFX250-S2
      Процесор: Intel Xeon-D
      Оперативна пам’ять: 32 ГБ DDR4
      Накопичувач: 400 ГБ SSD
      Мережеві порти: 4 x 1GbE RJ-45, 2 x 10GbE SFP+
      Пропускна здатність: До 10 Гбіт/с
      Підтримка віртуалізації: Так (Juniper Contrail, OpenStack)
      Живлення: 2 блоки живлення (резервування)
      Енергоспоживання: ≈ 110 Вт (середнє)
      Форм-фактор: 1U
      Охолодження: Активне, вентилятори з гарячою заміною
       



    • By Інет.укр
      Продам 
      juniper mx5-t (mx80) - 950$
      Juniper ms-mic-16g - 800$
      Juniper mic-3d-2xge-xfp - 200$
      https://t.me/serjiomati
    • By kotqq
      Продам Juniper MX104 з платою MIC-3D-2XGE-XFP (плату можна окремо), гарний стан, ціна 3300$
       

    • By kotqq
      Продам Комутатор Juniper QFX5110-32Q-AFO (10/40/100GbE), дуже гарний стан, 2 пари вух, ціна 1000$
       
      Juniper QFX5110-32Q-AFO – це високопродуктивний 40/100 Gigabit Ethernet-комутатор, призначений для використання в сучасних центрах обробки даних та корпоративних мережах. Комутатор підтримує інноваційні технології, забезпечує надійність та гнучкість для побудови масштабованих мережевих рішень.

      Основні особливості:
      -Підтримка 32 портів 40GbE QSFP+ з можливістю поділу на 4x10GbE
      -Підтримка 6 портів 100GbE QSFP28
      -Висока пропускна здатність до 3,2 Тбіт/с
      -Компактний форм-фактор 1U для економії місця
      -Функціональність Layer 2 і Layer 3 з підтримкою BGP, OSPF та інших протоколів
      -Потік охолодження у передній частині (AFO) для ефективного управління теплом

      Характеристики:
      -Порти 32 x 40GbE QSFP+ (4x10GbE) і 6 x 100GbE QSFP28
      -Пропускна здатність 3,2 Тбіт/с
      -Буфер пам’яті 22 МБ
      -Форм-фактор 1U Rack
      -Підтримка протоколів BGP, OSPF, PIM, EVPN, VXLAN
      -Живлення Два резервних блоки живлення (AC)
      -Охолодження Передній потік повітря (AFO)
      -Габарити (ВхШхГ) 43,7 x 438 x 510 мм
      -Вага 9,6 кг
       




×
×
  • Create New...