bokl Опубликовано 27 июля, 2011 · Жалоба Добрый день! Такая задача: 2 RB SE600 должны резервировать друг друга по PADO Delay. Причем IP не достаточно чтобы выделить каждому брасу пул на всех абонентов. Поэтому пул планировалось побить пополам и анонсить в OSPF от каждого всю сеть и свою половинку. В случае выубания одного редбака все должно пройти норм. абоны авторизуются на втором брасе и вся сеть будет анонсится от имени этого браса. Но вот незадача: если выйдет из строя карточка смотрящая в сторону субскрайберов(10G 1 port) то абоны авторизуются на втором брасе, а сеть будет все еще анонсироваться первым. И абоны будут сосать. планировали сделать портченел из 2-х 10G портов. но в RB нельзя в одном порту сделать и ppp и pvc для OSPF backbone(может я ошибся?). вопрос такой: как выходить из такой ситуации? кто что подскажет? пс: анонсить /32 не предлагать :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostil Опубликовано 27 июля, 2011 · Жалоба У RB подобное резервирование делается с помощью VRRP. Если упадет один из портов, то абоненты перекинутся на резервный брас вместе с пулами адресов. У нас используется такое резервирование только на SE100, но думаю что с SE600 проблем тоже быть не должно. Пулы реальников мы пока не используем, как в вашем случае, но инженеры Ericsson сказали что с этим проблем нет :) Если это интерестно могу помочь с кофигурацией ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 27 июля, 2011 · Жалоба Да точно , резерв делается через vrrp, в мануале на Redback есть описание и примеры. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bokl Опубликовано 27 июля, 2011 (изменено) · Жалоба бэкбон можно резервировать с помощью vrrp, а субскрайберский интерфейс? тоесть когда субскрайберы авторизуются на другом брасе(субскрайберский интерфейс вырубился), а бэкбон то активен и в апе Изменено 27 июля, 2011 пользователем bokl Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostil Опубликовано 27 июля, 2011 (изменено) · Жалоба Нет, не верно. Делаются дополнительные интерфейсы, влан которых проходит вместе с вланами сабскрайберов. У RB есть механизм который позволяет опираясь на vrrp делать вланы активным или неактивным для PPPoE. Изменено 27 июля, 2011 пользователем kostil Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bokl Опубликовано 27 июля, 2011 · Жалоба можно поподробней? или где почитать Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostil Опубликовано 27 июля, 2011 (изменено) · Жалоба На мой взгляд пример лучше всего:) bras-01 context local ... interface VRRP-81 description master ip address 192.168.7.1/29 vrrp 81 backup virtual-address 192.168.7.6 priority 200 log-state-change ! interface VRRP-82 description backup ip address 192.168.7.9/29 vrrp 82 backup virtual-address 192.168.7.14 priority 50 log-state-change .... port ethernet 2/2 description subscr no shutdown medium-type copper encapsulation dot1q ! вланы для работы VRRP dot1q pvc 81 bind interface VRRP-81 local dot1q pvc 82 bind interface VRRP-82 local ! пользовательские вланы dot1q pvc 280 encapsulation pppoe track vrrp 81 VRRP-81 local bind authentication chap context local maximum 300 dot1q pvc 281 encapsulation pppoe track vrrp 81 VRRP-81 local bind authentication chap context local maximum 300 dot1q pvc 282 encapsulation pppoe track vrrp 82 VRRP-82 local bind authentication chap context local maximum 300 dot1q pvc 283 encapsulation pppoe track vrrp 82 VRRP-82 local bind authentication chap context local maximum 300 bras-02 context local ... interface VRRP-81 description backup ip address 192.168.7.2/29 vrrp 81 backup virtual-address 192.168.7.6 priority 50 log-state-change ! interface VRRP-82 description master ip address 192.168.7.10/29 vrrp 82 backup virtual-address 192.168.7.14 priority 200 log-state-change ... port ethernet 2/2 description subscr no shutdown medium-type copper encapsulation dot1q dot1q pvc 81 bind interface VRRP-81 local dot1q pvc 82 bind interface VRRP-82 local dot1q pvc 280 encapsulation pppoe track vrrp 81 VRRP-81 local bind authentication chap context local maximum 300 dot1q pvc 281 encapsulation pppoe track vrrp 81 VRRP-81 local bind authentication chap context local maximum 300 dot1q pvc 282 encapsulation pppoe track vrrp 82 VRRP-82 local bind authentication chap context local maximum 300 dot1q pvc 283 encapsulation pppoe track vrrp 82 VRRP-82 local bind authentication chap context local maximum 300 Получаем что вланы 280 и 281 активны на bras-01 и неактивны на bras-02, а вланы 282 и 283 наоборот, что обеспечивает балансировку нагрузки. Если отваливается один из брасов, отрабатывает vrrp и на оставшемся брасе поднимаются пользовательские вланы, которые были не активны. P.S. Как сюда прикрутить пулы адресов я думаю подскажут инженеры Ericsson, т.к. я этого еще не делал у себя. Изменено 27 июля, 2011 пользователем kostil Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
macharius Опубликовано 27 июля, 2011 (изменено) · Жалоба можно сделать например так, SE1 - в нем два контекста Ctx_A и Ctx_B под рррое. Тоже самое для SE2 - в нем также два контекста Ctx_A и Ctx_B под рррое. Далее вы делаете vrrp партиции, общую идею описал kostil выше. SE1: вланы в Ctx_A - активны с точки зрения vrrp, и соответственно пассивны в Ctx_B SE2: все наоборот - активны в Ctx_B и пассивны в Ctx_A Пулы в Ctx_A на SE1 и SE2 одинаковы, также они одинаковы в Ctx_B на SE1 и SE2. таким образом, на выхлопе получится то что вы хотите. Изменено 27 июля, 2011 пользователем macharius Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bokl Опубликовано 27 июля, 2011 · Жалоба а как с точки зрения маршрутизации? контексты активны оба? если да, то получается что два девайса одновременно одинаковые пулы анонсят в сеть Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
macharius Опубликовано 27 июля, 2011 · Жалоба а как с точки зрения маршрутизации? контексты активны оба? если да, то получается что два девайса одновременно одинаковые пулы анонсят в сеть нет, у вас стоит в ospf - redistribute connected. Для multibind интерфейсов (т.е. пулов) это будет означать, что анонс префикса multibind (т.е. пула) происходит только тогда, когда есть хотя бы один абонент под ним. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bokl Опубликовано 27 июля, 2011 · Жалоба нужно подумать. пока я проще решить проблему пытаюсь: 1. на обоих физ портах завести и бекбон и ппп (одновременно нельзя только в портченеле). 2. поднять 2 ospf линка(должно баланситься). 3. на обоих есть ппп и тоже должно баланситься. тоесть пока оба физических интерфеса не упадут железка худо бедно будет работать хотябы на 1-ом интерфейсе(теоретически нам хватит в притык но можно потерпеть, авария как никак). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mr.anatoly Опубликовано 27 июля, 2011 (изменено) · Жалоба можно сделать например так, SE1 - в нем два контекста Ctx_A и Ctx_B под рррое. Тоже самое для SE2 - в нем также два контекста Ctx_A и Ctx_B под рррое. Далее вы делаете vrrp партиции, общую идею описал kostil выше. SE1: вланы в Ctx_A - активны с точки зрения vrrp, и соответственно пассивны в Ctx_B SE2: все наоборот - активны в Ctx_B и пассивны в Ctx_A Пулы в Ctx_A на SE1 и SE2 одинаковы, также они одинаковы в Ctx_B на SE1 и SE2. таким образом, на выхлопе получится то что вы хотите. Как поступить с разрастающейся, благодаря менеджерам-продажникам, коллекцией RSE ? Дублировать все RSE в контексты Ctx_A и Ctx_B, или есть возможность описать весь набор RSE в одном месте и ссылаться на него из каждого контекста? Еще вопрос по OSPF и пулу адресов: в релизе 6.2 столкнулся с ограничением в 15 secondary address на multibind-интерфейсе (какое ограничение в релизе 6.5 пока не знаю), поэтому, по вашему совету, использую multibind lastresort и summary-address в OSPF для анонса блоков адресов (их больше 15). Так вот, если под pppoe создавать 2 контекста, создать два интерфейса multibind lastresort не получится. Что делать? Кроме как пересмотра пулов адресов в сторону уменьшения их кол-ва, в голову ничего не приходит. Изменено 27 июля, 2011 пользователем mr.anatoly Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mr.anatoly Опубликовано 27 июля, 2011 · Жалоба kostil, с QinQ VRRP отработает? навскидку, из анализа вашего примера, должно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
macharius Опубликовано 27 июля, 2011 · Жалоба Анатолий, на счет RSE - да, в таком сценарии, дублировать. как альтернатива, можете посмотреть в сторону /32 меджду двумя брасами only, если есть свободные порты для такого взаимодействия. vrrp с qinq работает Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
laled Опубликовано 2 августа, 2011 · Жалоба Здравствуйте. Хочу уточнить, если проблемы с адресами нет, можно ли на обоих SE600 завести одинаковые вланы и подать их на обе коробки, будут ли они автоматически балансироваться как кошки? Cisco 10008 PRE3 работают сейчас аж в количестве 6 штук, все терминируют одни и те же вланы и самобалансируются в зависимости от нагрузки, как только одна нацепляла, начинает отвечать чуть медленнее, соотв. другая быстрее отвечает. Будет ли такой механизм работать на SE600? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostil Опубликовано 2 августа, 2011 · Жалоба Работать будет ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
garryfisher Опубликовано 20 ноября, 2014 · Жалоба Здравствуйте! Можно ли сделать резервирование context с помощью двух SE100? Имеем следующую схему. Абоненты подключаются по PPPoE. Есть два SE100, на каждом поднимается BGP сессия. На первом SE100#1 активен context A, на втором SE100#2 активен context B. В случае падения одного SE100 второй подхватывает его context, поднимает сессию и все ок. Либо лучше делать резервирование по VLAN как писалось выше? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nik0n Опубликовано 28 ноября, 2014 · Жалоба Можно ли сделать резервирование context с помощью двух SE100? Непроверенная идея: В конфигурации BGP для neighbor использовать update-source Сам IP на интерфейсе зарезервировать через VRRP на разных SE100 Вопрос: а не будет ли SE100 сыпать в логи ошибки из context backup на неактивном интерфейсе? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
