Перейти до

Cisco ASR1001-X IPoE BRAS


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

По поводу 2-х уровневой системы. Будет вносить дополнительные задержки в rtt, что часто (но не всегда) совершенно не смертельно, но не есть гут. Пока одно корыто справляется с терминацией, полисингом, натом, лучше держать это на одном тазу.

Задержку лишний маршрутизатор добавит абсолютно неощутимую и неизмеримую, микросекунды. Сами процесс шейпинга и NATа же в любом случае дадут задержку в десятки раз больше, и пофиг, на 1 машине оно делается или на разных.

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

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

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

динамические виланы упрощают конфигурацию брасов. Но никак не решают проблему горячего резерва. Абонент не заработает до переинициализации сессии.   

А! Вот в чем твоя беда... Да, такое только для тазика, для серьезных поломаек \то еще 100 штук зелени за чих, если почешуцца - жди мессию!

Слушай, неблагодарная скотина - что ты делаешь на сборище бедных и убогих? Ведь в жизни все просто - МХ80 стоит от 6 тысяч.   На пишу тут я не тебе, а нормальным думающим людям и сегодня я изложил

У нас работает АСР1006+RP2+esp20

НАТ + ПППОЕ для клиентов

вместо джуна мх80

пропускает он 20 гиг или 10 фул дуплекса всего

но нам хватает

потом можно поставить esp40

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

 

По поводу 2-х уровневой системы. Будет вносить дополнительные задержки в rtt, что часто (но не всегда) совершенно не смертельно, но не есть гут. Пока одно корыто справляется с терминацией, полисингом, натом, лучше держать это на одном тазу.

Задержку лишний маршрутизатор добавит абсолютно неощутимую и неизмеримую, микросекунды. Сами процесс шейпинга и NATа же в любом случае дадут задержку в десятки раз больше, и пофиг, на 1 машине оно делается или на разных.

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

 

Может конфиги проще получаются, а не схема? Любая схема, при добавлении в нее элементов, всегда только усложняется.

И зачем, пока один таз в одну свою харю может все сжевать, что-то масштабировать? Если есть пара тазов, каждый из которых справляется с задачами в одиночку, то имхо, логичнее не поставить их в цепочку брас---нат, а залить идентичный софт/конфиги и срезервировать или по-гарячему, или вообще резервный держать в shutdown для экономии немного искричества. А вот когда ресурсов одного таза хватать перестанет - тогда и разносить задачи и масштабировать.

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

У нас работает АСР1006+RP2+esp20

НАТ + ПППОЕ для клиентов

вместо джуна мх80

пропускает он 20 гиг или 10 фул дуплекса всего

но нам хватает

потом можно поставить esp40

чей-то маловато 10 фул для есп20. у меня проц 20-го есп при 7 гиг фула загружен всего на 22%.

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

 

 

По поводу 2-х уровневой системы. Будет вносить дополнительные задержки в rtt, что часто (но не всегда) совершенно не смертельно, но не есть гут. Пока одно корыто справляется с терминацией, полисингом, натом, лучше держать это на одном тазу.

Задержку лишний маршрутизатор добавит абсолютно неощутимую и неизмеримую, микросекунды. Сами процесс шейпинга и NATа же в любом случае дадут задержку в десятки раз больше, и пофиг, на 1 машине оно делается или на разных.

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

Может конфиги проще получаются, а не схема? Любая схема, при добавлении в нее элементов, всегда только усложняется.

И зачем, пока один таз в одну свою харю может все сжевать, что-то масштабировать? Если есть пара тазов, каждый из которых справляется с задачами в одиночку, то имхо, логичнее не поставить их в цепочку брас---нат, а залить идентичный софт/конфиги и срезервировать или по-гарячему, или вообще резервный держать в shutdown для экономии немного искричества. А вот когда ресурсов одного таза хватать перестанет - тогда и разносить задачи и масштабировать.

В том то и дело. На тазиках при отдельном NAT-сервере BRAS-часть получается проще, меньше заморочек.

Плюс, тазик-терминатор+тазик-NAT пропустят больше трафика, чем 2 универсальных тазика работающих параллельно. Накладных расходов из-за conntrack-table и костылей BRASа меньше.

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

 

И зачем, пока один таз в одну свою харю может все сжевать, что-то масштабировать? Если есть пара тазов, каждый из которых справляется с задачами в одиночку, то имхо, логичнее не поставить их в цепочку брас---нат, а залить идентичный софт/конфиги и срезервировать или по-гарячему, или вообще резервный держать в shutdown для экономии немного искричества. А вот когда ресурсов одного таза хватать перестанет - тогда и разносить задачи и масштабировать.

 

Ну попробуйте зарезервируйте "по-гарячему" BRASы для IPoE и НАТы ))) 

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

 

 

И зачем, пока один таз в одну свою харю может все сжевать, что-то масштабировать? Если есть пара тазов, каждый из которых справляется с задачами в одиночку, то имхо, логичнее не поставить их в цепочку брас---нат, а залить идентичный софт/конфиги и срезервировать или по-гарячему, или вообще резервный держать в shutdown для экономии немного искричества. А вот когда ресурсов одного таза хватать перестанет - тогда и разносить задачи и масштабировать.

 

Ну попробуйте зарезервируйте "по-гарячему" BRASы для IPoE и НАТы ))) 

 

вы только что ответили в прошлый год, путешественник во времени детекдет!

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

Ну попробуйте зарезервируйте "по-гарячему" BRASы для IPoE и НАТы )))

Нормальные IPOE-БРАСы умеют масштабироваться/резервироваться by design. Умер один - в течении минимального времени клиенты перетекли на соседний, никакой разницы с pppoe.

NAT-боксы резервируются стандартными средствами ОС, vrrp или вообще какой-нить ospf поднять между NASами и NATами. Ничего сложного.

Ссылка на сообщение
Поделиться на других сайтах
А вот разделять терминацию и NAT - идеалогически правильно, схема получается проще и лучше масштабируемой.

 

 

Как по мне это вообще единственный правильный вариант когда с трафиком работаешь в плотную. qos, шейпинг, nat и т.д. не реально сделать на одной тачке адекватными способами, приходится изощряться разными способами imq,ifb, маркировки, патчинги и т.д. а это уже костыли. А когда это разделено как минимум на 2 тачки, архитектура управления трафиком становится прозрачней и понятней в разы.

На железные решения пока смотрю косо т.к. голый Linux удовлетворяет почти полностью и в принципе стабилен, бывают конечно и приколы, например месяц назад NAT на 4.9 начал выпадать в кернел паник проработавши месяц, обновил на 4.14 стабилизировался.

 

Есть так же accel на 4.14 по стабильности пока не скажу только неделю ввел в эксплуатацию, на 3.18 работал хорошо.

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

 

Ну попробуйте зарезервируйте "по-гарячему" BRASы для IPoE и НАТы )))

Нормальные IPOE-БРАСы умеют масштабироваться/резервироваться by design. 

 

Можно пример такого IPoE-браса? )) 

 

 

 

И зачем, пока один таз в одну свою харю может все сжевать, что-то масштабировать? Если есть пара тазов, каждый из которых справляется с задачами в одиночку, то имхо, логичнее не поставить их в цепочку брас---нат, а залить идентичный софт/конфиги и срезервировать или по-гарячему, или вообще резервный держать в shutdown для экономии немного искричества. А вот когда ресурсов одного таза хватать перестанет - тогда и разносить задачи и масштабировать.

 

Ну попробуйте зарезервируйте "по-гарячему" BRASы для IPoE и НАТы ))) 

 

вы только что ответили в прошлый год, путешественник во времени детекдет!

 

Ну вот прикиньте, вкладка год уже открыта )

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

 

Можно пример такого IPoE-браса? )) 

cisco asr, juniper mx

внезапно, да? 

 

Ничего внезапного. Например сабж темы - не умеет. За mx тоже не уверен.

Ссылка на сообщение
Поделиться на других сайтах
Можно пример такого IPoE-браса? )) 

cisco asr, juniper mx

внезапно, да?

Ничего внезапного. Например сабж темы - не умеет. За mx тоже не уверен.

Кто то ждет мессию, а кто то давно закрыл вопрос построив то что ему нужно.

А каждому нужно свое, потому что каждый находится на своей ступеньки эволюции понимания.

 

Биндинг мака на порт, который практикуют некоторый крупные провы это пик маразма.

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

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

В качестве масштабирования - CARP всему голова, просто добавь воды.

 

Безусловно можно ждать мессию cisco super asr+++, megajuniper++++, но он не придет, от слова никогда.

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

 

Ответ на все вопросы которые подняты в данной теме, крутятся вокруг весьма ограниченных проблем, которые может решать билинг в штатном порядке.

Поднялся порт, запускается скрипт который причесывает событие.

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

Сложно это сделать?

С какого это перепугу?

Все перечисленные выше решения требуют железа не первой свежести, так почему составляет проблему сработка какого-то скрипта?

 

А если на мыльницах, то мивина ваше все.

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

 

Можно пример такого IPoE-браса? )) 

cisco asr, juniper mx

внезапно, да?

Ничего внезапного. Например сабж темы - не умеет. За mx тоже не уверен.

Кто то ждет мессию, а кто то давно закрыл вопрос построив то что ему нужно.

А каждому нужно свое, потому что каждый находится на своей ступеньки эволюции понимания.

 

Биндинг мака на порт, который практикуют некоторый крупные провы это пик маразма.

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

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

В качестве масштабирования - CARP всему голова, просто добавь воды.

 

Безусловно можно ждать мессию cisco super asr+++, megajuniper++++, но он не придет, от слова никогда.

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

 

Ответ на все вопросы которые подняты в данной теме, крутятся вокруг весьма ограниченных проблем, которые может решать билинг в штатном порядке.

Поднялся порт, запускается скрипт который причесывает событие.

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

Сложно это сделать?

С какого это перепугу?

Все перечисленные выше решения требуют железа не первой свежести, так почему составляет проблему сработка какого-то скрипта?

 

А если на мыльницах, то мивина ваше все.

 

Вопрос был по горячему резервированию/масштабированию IPoE-браса. Причем тут биллинги, опции82 и пр? 

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

Вопрос был по горячему резервированию/масштабированию IPoE-браса. Причем тут биллинги, опции82 и пр?

А дядя Вова всегда какую-то длинную ересь с кучей крутых слов пишет, если не понимает о чем речь :)

 

SE, MX и accel умеют балансировать клиентов. Про asr не в курсе, никогда им не интересовался.

У меня на soft-BRASах с accel это работает, активные сессии равномерно балансируются автоматом, при падении сервера клиенты в течении максимум 5 минут(dhcp lease time) поднимаются на соседнем.

Не вижу проблем реализовать это же на любом аппаратном BRASе.

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

Вопрос был по горячему резервированию/масштабированию IPoE-браса. Причем тут биллинги, опции82 и пр?

Всем доброго времени.

Кто что может сказать про сей девайс? Насколько он хорош как IPoE BRAS? Есть ли какие-то неприятные моменты? Хотелось бы, чтоб отозвались те, у кого есть опыт эксплуатации, либо те, кто по каким-то тем или иным причинам отказались в пользу другого решения.

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

 

Вопрос был по горячему резервированию/масштабированию IPoE-браса. Причем тут биллинги, опции82 и пр?

А дядя Вова всегда какую-то длинную ересь с кучей крутых слов пишет, если не понимает о чем речь :)

 

SE, MX и accel умеют балансировать клиентов. Про asr не в курсе, никогда им не интересовался.

У меня на soft-BRASах с accel это работает, активные сессии равномерно балансируются автоматом, при падении сервера клиенты в течении максимум 5 минут(dhcp lease time) поднимаются на соседнем.

Не вижу проблем реализовать это же на любом аппаратном BRASе.

 

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

Более того у меня в городе три площадки, на который находится не один джунипер, а несколько софтовых роутеров.

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

В связи с этим там стоит упса с двумя автомобильными акумами по 55ач и работы хватает на пару суток без электропитания.

Теперь расскажи мне сказку про Киевстар, мега сиську, два контейнера с акумами и дизель генератором... патаму что...

 

Идеология резервирования/масштабирования построена на карпе.

Сектор может обслуживается от одного до любого количества роутеров.

 

Поэтому с помощью карпа я решаю не только горячее резервирование/масштабирование IPoE-браса а и вопрос бесперебойного питания.

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

 

Вопрос был по горячему резервированию/масштабированию IPoE-браса. Причем тут биллинги, опции82 и пр?

А дядя Вова всегда какую-то длинную ересь с кучей крутых слов пишет, если не понимает о чем речь :)

 

SE, MX и accel умеют балансировать клиентов. Про asr не в курсе, никогда им не интересовался.

У меня на soft-BRASах с accel это работает, активные сессии равномерно балансируются автоматом, при падении сервера клиенты в течении максимум 5 минут(dhcp lease time) поднимаются на соседнем.

Не вижу проблем реализовать это же на любом аппаратном BRASе.

 

5 минут это уже далеко не горячий резерв. Если IPoE-брасов >1, то на каждом должны быть свои виланы, которые не должны пересекаться с соседним брасом, поэтому если один из брасов лёг, его виланы должны каким-то скриптом переехать на рабочие брасы. Кто должен отслеживать работоспособность браса и по каким критериям?

В общем костыли все это.

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

Переход осуществляется мгновенно.

Вот тебе пример состояние интерфейсов на трех брасах на каждой из площадок

vlan132: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: Pavlabor
        options=303<RXCSUM,TXCSUM,TSO4,TSO6>
        ether 00:1b:21:b3:2a:94
        inet 194.146.181.129 netmask 0xffffff80 broadcast 194.146.181.255 vhid 129
        inet 194.146.181.130 netmask 0xffffffff broadcast 194.146.181.130 vhid 130
        inet 194.146.180.245 netmask 0xfffffffc broadcast 194.146.180.247 vhid 245
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        vlan: 132 parent interface: igb0
        carp: MASTER vhid 129 advbase 1 advskew 50
        carp: BACKUP vhid 130 advbase 1 advskew 150
        carp: BACKUP vhid 245 advbase 1 advskew 150

 

 

vlan132: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: Pavlabor
        options=303<RXCSUM,TXCSUM,TSO4,TSO6>
        ether 00:1b:21:66:92:d4
        inet 194.146.181.130 netmask 0xffffff80 broadcast 194.146.181.255 vhid 130
        inet 194.146.181.129 netmask 0xffffffff broadcast 194.146.181.129 vhid 129
        inet 194.146.180.245 netmask 0xfffffffc broadcast 194.146.180.247 vhid 245
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        vlan: 132 parent interface: igb0
        carp: MASTER vhid 130 advbase 1 advskew 50
        carp: BACKUP vhid 129 advbase 1 advskew 150
        carp: MASTER vhid 245 advbase 1 advskew 50

Пока два для простоты понимания, потому что третий брас выключенный нет нагрузки, автоматически включится в шесть часов вечера. Специально включать влом.

Висят два ип

  inet 194.146.181.129 netmask 0xffffff80 broadcast 194.146.181.255 vhid 129

и

  inet 194.146.181.130 netmask 0xffffff80 broadcast 194.146.181.255 vhid 130

Состяние на активном 194.146.181.129

 carp: MASTER vhid 129 advbase 1 advskew 50

на резерве

carp: BACKUP vhid 129 advbase 1 advskew 150

Балансировка идет путем выдачи в качестве дефаулта соответствующего IP.

В связи с чем часть абонов обслуживается одним брасом, часть другим, часть третьим.

 

я тупо выключаю первый брас без предупреждения пользователей

и состяние на втором брассе с

carp: BACKUP vhid 129 advbase 1 advskew 150

переходит в состяние

carp: MASTER vhid 129 advbase 1 advskew 150

 

carp генерит собственный мак для связки

поэтому потоки переруливаются практически мгновенно.

Клиенты смены даже не замечают, даже игровые сессии не разваливаются.

 

Время опроса можно выставлять на свое усмотрение, но 5 минут наверно нельзя... а может и можно. Не пробовал.

 

Это горячее резервирование/масштабирование именно IPoE-браса, на остальные печеньки можете не обращать внимания.

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

Переход осуществляется мгновенно.

Вот тебе пример состояние интерфейсов на трех брасах на каждой из площадок

vlan132: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

        description: Pavlabor

        options=303<RXCSUM,TXCSUM,TSO4,TSO6>

        ether 00:1b:21:b3:2a:94

        inet 194.146.181.129 netmask 0xffffff80 broadcast 194.146.181.255 vhid 129

        inet 194.146.181.130 netmask 0xffffffff broadcast 194.146.181.130 vhid 130

        inet 194.146.180.245 netmask 0xfffffffc broadcast 194.146.180.247 vhid 245

        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

        media: Ethernet autoselect (1000baseT <full-duplex>)

        status: active

        vlan: 132 parent interface: igb0

        carp: MASTER vhid 129 advbase 1 advskew 50

        carp: BACKUP vhid 130 advbase 1 advskew 150

        carp: BACKUP vhid 245 advbase 1 advskew 150

 

 

vlan132: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

        description: Pavlabor

        options=303<RXCSUM,TXCSUM,TSO4,TSO6>

        ether 00:1b:21:66:92:d4

        inet 194.146.181.130 netmask 0xffffff80 broadcast 194.146.181.255 vhid 130

        inet 194.146.181.129 netmask 0xffffffff broadcast 194.146.181.129 vhid 129

        inet 194.146.180.245 netmask 0xfffffffc broadcast 194.146.180.247 vhid 245

        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

        media: Ethernet autoselect (1000baseT <full-duplex>)

        status: active

        vlan: 132 parent interface: igb0

        carp: MASTER vhid 130 advbase 1 advskew 50

        carp: BACKUP vhid 129 advbase 1 advskew 150

        carp: MASTER vhid 245 advbase 1 advskew 50

Пока два для простоты понимания, потому что третий брас выключенный нет нагрузки, автоматически включится в шесть часов вечера. Специально включать влом.

Висят два ип

  inet 194.146.181.129 netmask 0xffffff80 broadcast 194.146.181.255 vhid 129

и

  inet 194.146.181.130 netmask 0xffffff80 broadcast 194.146.181.255 vhid 130

Состяние на активном 194.146.181.129

 carp: MASTER vhid 129 advbase 1 advskew 50

на резерве

carp: BACKUP vhid 129 advbase 1 advskew 150

Балансировка идет путем выдачи в качестве дефаулта соответствующего IP.

В связи с чем часть абонов обслуживается одним брасом, часть другим, часть третьим.

 

я тупо выключаю первый брас без предупреждения пользователей

и состяние на втором брассе с

carp: BACKUP vhid 129 advbase 1 advskew 150

переходит в состяние

carp: MASTER vhid 129 advbase 1 advskew 150

 

carp генерит собственный мак для связки

поэтому потоки переруливаются практически мгновенно.

Клиенты смены даже не замечают, даже игровые сессии не разваливаются.

 

Время опроса можно выставлять на свое усмотрение, но 5 минут наверно нельзя... а может и можно. Не пробовал.

 

Это горячее резервирование/масштабирование именно IPoE-браса, на остальные печеньки можете не обращать внимания.

 

Вы не путаете BRASы c обычными роутерами? Для браса должно быть понятие сессии с абонентом, там где хранится сессия - это и есть брас.

Вы каким образом на IPoE поднимаете сессию с абонентом?

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

5 минут это уже далеко не горячий резерв.

Если IPoE-брасов >1, то на каждом должны быть свои виланы, которые не должны пересекаться с соседним брасом, поэтому если один из брасов лёг, его виланы должны каким-то скриптом переехать на рабочие брасы.

Кто должен отслеживать работоспособность браса и по каким критериям? В общем костыли все это.

"До 5 минут" это очень даже горячий резерв.

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

Уверен что и балансировка субскрайберов на том же ASR есть из коробки, лень рыть документацию.

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

 

5 минут это уже далеко не горячий резерв.

Если IPoE-брасов >1, то на каждом должны быть свои виланы, которые не должны пересекаться с соседним брасом, поэтому если один из брасов лёг, его виланы должны каким-то скриптом переехать на рабочие брасы.

Кто должен отслеживать работоспособность браса и по каким критериям? В общем костыли все это.

"До 5 минут" это очень даже горячий резерв.

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

Уверен что и балансировка субскрайберов на том же ASR есть из коробки, лень рыть документацию.

 

горячий резерв - это без разрыва абонентской сессии и потери пакетов.

Динамическое создание виланов это про линукс с аксель ппп? Я имел в виду аппаратные брасы. В asr1k нет никакой балансировки субскрайберов в принципе.

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

 

 

5 минут это уже далеко не горячий резерв.

Если IPoE-брасов >1, то на каждом должны быть свои виланы, которые не должны пересекаться с соседним брасом, поэтому если один из брасов лёг, его виланы должны каким-то скриптом переехать на рабочие брасы.

Кто должен отслеживать работоспособность браса и по каким критериям? В общем костыли все это.

"До 5 минут" это очень даже горячий резерв.

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

Уверен что и балансировка субскрайберов на том же ASR есть из коробки, лень рыть документацию.

горячий резерв - это без разрыва абонентской сессии и потери пакетов.

Динамическое создание виланов это про линукс с аксель ппп? Я имел в виду аппаратные брасы. В asr1k нет никакой балансировки субскрайберов в принципе.

SE и MX создают vlan-интерфейсы динамически, так же как и accel.

Резервирование без обрыва сессии между БРАСами это уже сильно крутая хотелка, зачем оно для ISP?

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

Вы не путаете BRASы c обычными роутерами? Для браса должно быть понятие сессии с абонентом, там где хранится сессия - это и есть брас.

Вы каким образом на IPoE поднимаете сессию с абонентом?

Возможно я смогу ответить на вопрос если вы уточните что в вашем понимании означает сессия в IPoE.

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

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

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

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

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

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

Вхід

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

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

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


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