Хорошо, я представил 32 стартов :)

Обычно, 32к всасывается не менеьше 5 минут

у тебя хуевая статистика

у ебя поднимается больше 100 сессий в секунду?

на прошлой галере л3 коннектед сабскрайберы 12 тыщь залетали за пару секунд

Можно посмотреть на ЦПУ во время поднятия сессий после ребута?

среди бела дня брас ебнулся

абоны даже не замечали

график по кол-ву сессий есть?

когда они уходили на другой

а потом назад

пишу же прошлая галера :)

и там сейчас ваще оракл целиком на ссд

ну тут остался вопрос с сессиями.. вилимо, они не меняются... а подхватываются

иначе бы все встряло бы

акаунтинг будет

ну скоро будут 9001ые

у одних ребят. они как раз на срг смотрят

запросов на авторизацию вагон думаю не будет в обоих режимах

но задержка какая-то будет

не сможет оно столько мигом запрограммировать в нпу

That is hot and warm standby. Hot-Standby Mode (default) Sessions provisioned on slave in sync with setup on master Since the sessions are actively programmed on the standby, this will consume hardware resources on slave. Proper planning is necessary here, since if we have BNG node X and Y both serving 50k sessions each, the slave node needs to be able to support 100k sessions when they are actively programmed! Minimal action on switchover; data plane is already setup for sub-second traffic impact, this is the highest level of redundancy you can achieve. And especially useful in deployments requiring high and tight SLA Warm-Standby Mode (for over-subscription) Sessions data kept in “shadow” database on slave in sync with setup on master Only consumes some additional memory in control plane for the shadow copy – no provisioning in hardware Upon failover trigger, sessions are setup at rapid pace from shadow copy This allows for over provisioning on backup for subscribers. While it still provides for a high level of redundancy, and the "outage" or forwarding loss is determined by the time it takes to hw program the sessions served by the SRG, the failover will result in some session loss (if the SRG serves high number of sessions that take longer to program then the keepalive/timeout of the session).

не представляю что в этой каше с адресами происходит...

а что не так то ?

это же для л2 коннектед ;-)

у тебя железки с одинаковым конфигом

просто половина конфига в стендбае

чем-то похоже на vrrp (на хуа кстати есть эта же фича и там это прям vrrp)

вот есть лупбэк с сетью 10.0.0.1/24 и абонов пачка. активная железка наверх анонсит этот блок.

вторая начнет анонсить когда первая ебнется

That is hot and warm standby. Hot-Standby Mode (default) Sessions provisioned on slave in sync with setup on master Since the sessions are actively programmed on the standby, this will consume hardware resources on slave. Proper planning is necessary here, since if we have BNG node X and Y both serving 50k sessions each, the slave node needs to be able to support 100k sessions when they are actively programmed! Minimal action on switchover; data plane is already setup for sub-second traffic impact, this is the highest level of redundancy you can achieve. And especially useful in deployments requiring high and tight SLA Warm-Standby Mode (for over-subscription) Sessions data kept in “shadow” database on slave in sync with setup on master Only consumes some additional memory in control plane for the shadow copy – no provisioning in hardware Upon failover trigger, sessions are setup at rapid pace from shadow copy This allows for over provisioning on backup for subscribers. While it still provides for a high level of redundancy, and the "outage" or forwarding loss is determined by the time it takes to hw program the sessions served by the SRG, the failover will result in some session loss (if the SRG serves high number of sessions that take longer to program then the keepalive/timeout of the session).

хорошо описано, сеньк

вторая начнет анонсить когда первая ебнется

Клеарли!

вон кстати пишут

Radius Interaction some important notes regarding radius accounting and authorization information Authentication/Authorization done only from the Master and all profile information is syncd to Slave. Slave does not reach out to radius and relies on the session information received from the active node. On Failover, Accounting Stop message is sent from old Master and Accounting Start from New Master. NOTE: Accounting Stop from old master sent on best effort basis and ordering is not guaranteed between it and the Accounting Start sent by the new master. A failover session should be handled as two separate sessions by Radius Radius (Accounting) messages from BNG are paced with jitter (especially around switchover) to avoid load on the server

Ну то есть нет резерва. Это я говорю об экономической составляющей. х2 мощностей не пропустят :))) Не, я себе может и куплю когда-нибюуь ворую железку для резерва, но галера не купит ))

почему нет то ?

откуда х2

https://image.slidesharecdn.com/16-170427104747/95/bng-asr9000-50-638.jpg?cb=1493290254

https://supportforums.cisco.com/legacyfs/online/attachments/document/screen_shot_2016-04-18_at_8.32.25_am.png

ты на свой размер кошелька просто ориентируешься

Radius Interaction some important notes regarding radius accounting and authorization information Authentication/Authorization done only from the Master and all profile information is syncd to Slave. Slave does not reach out to radius and relies on the session information received from the active node. On Failover, Accounting Stop message is sent from old Master and Accounting Start from New Master. NOTE: Accounting Stop from old master sent on best effort basis and ordering is not guaranteed between it and the Accounting Start sent by the new master. A failover session should be handled as two separate sessions by Radius Radius (Accounting) messages from BNG are paced with jitter (especially around switchover) to avoid load on the server

ага, пздц радиусу ?

если реально будешь держать по 32к сессий и больно будет

тогда 2 млн на коробку найти не проблема..

Ну из прочитанного я понимаю, что надо державть все в хот режиме, то есть сессий будет в 2 раза больше (ресурсы будут хавать), то есть брасов надо в 2 раза больше, если 1 брас полностью забит нагрузкой

написано 2 режима

во втором память будет жрать на рсп

тогда 2 млн на коробку найти не проблема..

проблема :)

но железо будет ок

во втором память будет жрать на рсп

второй сдуется, его сразу лучше не юзать

Сча, скажу иначе про сдуается:

блять

по твоей логике второй режим с полным программингом

вообще не живой

но они это продают

При 64к на железку нагрузка такова, что при перетекании полюбому есть риск чему-то пойти не так. А при активном влитии инфы в хардваре - подавно. Да, второй не живой, предвижу креш через раз.

фи

началось блять

у них старшие шасси можно набить 512к!!!!!!!!!!!!

на железку

пол млн сабскрайберов

при залитии фулвью тоже чет может пойти не так

прикинь считать бестпасы

инсталить их в фиб

и это делать ажно 600 тыщь раз

но они это продают

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

блабла

:)

ERROR: S client not available

тестируют это все на иксиях

в томтеле исг уже почти 10 лет

а ты тут рассказываешь

как все хуево

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

но было починено

за пару месяцев _

ттк пару лет назад очень активно закупал аср9к

шасси и карты -SE

явно под брас

я сходу залез посчитал кол-во цепочек с участием cisco-technical-support@cisco.com, 191 из них 10% смело - это новые баги, решение которых мы ждали в новом софте, по факту получали, тестили, всплывало новое, а решалось все с 3-5 попытки

блабла

ваще если хочется прям стойкое решение, то тут уже цены другие. но имхо когда 32 тыщи абонентов на коробку и носят по ~400р это больше 10 млн per month

не показатель

сце контролбас чинили давая СОФТ

чувак давал скачать софт который сам собирал

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

тогда смысл говорить о резерве вообще ?

переноси руками

:)

привози железку из другого города

это выбор твоих ребят

Зачем, между городами MPLS

ну тащи руками значит

Ну да, как-то так.

и твой выбор писюк )

Временно в другой город приземление, а тем временем организуется доставка коробки

твой мплс шланг выдержит 32к абонентов ?

и твой выбор писюк )

Это что же за писюк такой тянет 64к?

это порядка 30-35 гбит в пике где-то должно быть ;-)

в сторону абонентов

твой мплс шланг выдержит 32к абонентов ?

в пределах 40г