Jump to content
Калькуляторы

Ericsson SmartEdge

Кто работает с этими железками, можете прокоментировать пару моментов.

Умеют ли устройства из данной линейки терминировать dual stack клиентов.

Если да, то как это отражается на лимитах. На сколько больше при этом потребляется очередей.

Есть ли шанс для этой платформы увеличить кол-во гигабит на слот.

Если да, то как пойдет развитие, с помощью все более быстрой электроники, сохраняя full-mesh между картами или все же случиться переход к фабрике.

Edited by rus-p

Share this post


Link to post
Share on other sites
Умеют ли устройства из данной линейки терминировать dual stack клиентов.

Если да, то как это отражается на лимитах. На сколько больше при этом потребляется очередей.

Да, умеют. Пока что для PPPoE, весной для L2TP LNS, потом для CLIPS.

Кол-во абонентов dual-stack на модуль сокращается с 32к до 16к. На систему с XCRP4 ограничение сверху в 64к. Для чистого IPv6 абонента лимиты такие же. Однако, будет увлеичение кол-ва IPv6 на платах поколения РРА3 в течении года.

 

Есть ли шанс для этой платформы увеличить кол-во гигабит на слот.

Если да, то как пойдет развитие, с помощью все более быстрой электроники, сохраняя full-mesh между картами или все же случиться переход к фабрике.

 

В ближайшей преспективе нет. Сегодня соотношение реальная производительность / функциональная насыщенность более чем оптимальна. В скором времени (год, два) появится XCRP5 для увеличения производительности control plane. Платформа находится в данный момент в активной фазе разработке, и будет находится в ней еще очень очень долго.

Edited by macharius

Share this post


Link to post
Share on other sites
Кол-во абонентов dual-stack на модуль сокращается с 32к до 16к. На систему с XCRP4 ограничение сверху в 64к. Для чистого IPv6 абонента лимиты такие же. Однако, будет увлеичение кол-ва IPv6 на платах поколения РРА3 в течении года.

Для какого чипа цифры 32k->16k, PPA2 (1x10GE) или PPA3 (4x10GE overbook 2:1), или пока для обоих типов ?

 

Планируется увеличение только для IPv6, или все же для dual stack ?

 

Почему так резко провалились лимиты для dual stack на XCRP4, ведь для чистого IPv4 было 512k (384 с очередями) ?

 

Есть ли на этой платформе механизм лимитирования полосы для каждого пользователя отличный от очереди, полисер, если да, какие с ним лимиты ?

 

 

Edited by rus-p

Share this post


Link to post
Share on other sites
Кол-во абонентов dual-stack на модуль сокращается с 32к до 16к. На систему с XCRP4 ограничение сверху в 64к. Для чистого IPv6 абонента лимиты такие же. Однако, будет увлеичение кол-ва IPv6 на платах поколения РРА3 в течении года.

Для какого чипа цифры 32k->16k, PPA2 (1x10GE) или PPA3 (4x10GE overbook 2:1), или пока для обоих типов ?

Пока одинаково для PPA2/PPA3, для PPA3 будет увеличение, для PPA2 - нет.

 

Планируется увеличение только для IPv6, или все же для dual stack ?
Да, для dual-stack, и только на PPA3.

 

Почему так резко провалились лимиты для dual stack на XCRP4, ведь для чистого IPv4 было 512k (384 с очередями) ?
Не знаю откуда взята цифра в 512к для XCRP4, для него всегда было 256к. Сократилось все в четыре раза, поскольку data structure кода под IPv6 увеличились в 2-4 раза (сам адрес v6 длиннее v4 и проч.)

 

Есть ли на этой платформе механизм лимитирования полосы для каждого пользователя отличный от очереди, полисер, если да, какие с ним лимиты ?
есть обычный token backet полисер (rate-limit), ограничен - 8 классами на полисер, кол-во полисеров может быть столько сколько абонентов, на производительность не влияет.

 

Share this post


Link to post
Share on other sites
Кол-во абонентов dual-stack на модуль сокращается с 32к до 16к. На систему с XCRP4 ограничение сверху в 64к. Для чистого IPv6 абонента лимиты такие же. Однако, будет увлеичение кол-ва IPv6 на платах поколения РРА3 в течении года.

Для какого чипа цифры 32k->16k, PPA2 (1x10GE) или PPA3 (4x10GE overbook 2:1), или пока для обоих типов ?

Пока одинаково для PPA2/PPA3, для PPA3 будет увеличение, для PPA2 - нет.

 

Планируется увеличение только для IPv6, или все же для dual stack ?
Да, для dual-stack, и только на PPA3.

 

Почему так резко провалились лимиты для dual stack на XCRP4, ведь для чистого IPv4 было 512k (384 с очередями) ?
Не знаю откуда взята цифра в 512к для XCRP4, для него всегда было 256к. Сократилось все в четыре раза, поскольку data structure кода под IPv6 увеличились в 2-4 раза (сам адрес v6 длиннее v4 и проч.)

 

Есть ли на этой платформе механизм лимитирования полосы для каждого пользователя отличный от очереди, полисер, если да, какие с ним лимиты ?
есть обычный token backet полисер (rate-limit), ограничен - 8 классами на полисер, кол-во полисеров может быть столько сколько абонентов, на производительность не влияет.

 

Ок. Спасибо.

 

Есть еще вопросы.

 

Когда увеличат кол-во сабскрайберов на PPA3, будет ли хватать очередей (по две очереди на сабскрайбера суммарно по ингресс плюс егресс) ?

А если по каждому направлению две очереди, т.е. суммарно 4 на сабскрайбера ?

Если не будет хватать, возможно ли смешанное применение полисеров и очередей ?

 

Есть ли резервирование/планируется ли для CLIPS сессий на две коробки ?

Если да, делятся ли лимиты в этом случае на два ?

 

 

Share this post


Link to post
Share on other sites
Ок. Спасибо.

 

Есть еще вопросы.

 

Когда увеличат кол-во сабскрайберов на PPA3, будет ли хватать очередей (по две очереди на сабскрайбера суммарно по ингресс плюс егресс) ?

А если по каждому направлению две очереди, т.е. суммарно 4 на сабскрайбера ?

Если не будет хватать, возможно ли смешанное применение полисеров и очередей ?

В SE есть две сущности - полисер (rate-limit) и шейпер (sheduler). Полисер не влияет на ресурсы. Шейпер влияет. Сейчас цифра 16тыс на модуль для dual-stack подразумевает, что шейпер может быть включен для каждого из 16тыс. В шейпере всегда доступны 8 очередей на абонента. Как повлияет увеличение кол-ва абонентов на модуле на возможности планировщика - пока сказать сложно. Но повторюсь, что для плоисера - это не принципиально. К слову следует сказать, что в современных условиях наиболее оправданным является использование именно полисера, т.к. скорости у абонентов давно выпрыгнули за 1Мбит/с.

 

Есть ли резервирование/планируется ли для CLIPS сессий на две коробки ?

Если да, делятся ли лимиты в этом случае на два ?

Для CLIPS есть механизм резервирования на базе VRRP, но он stateless, т.е. подразумевает реконнект (выдача NAK на новом брасе и последующий откат в discover на стороне клиента).

Edited by macharius

Share this post


Link to post
Share on other sites
Для CLIPS есть механизм резервирования на базе VRRP, но он stateless, т.е. подразумевает реконнект (выдача NAK на новом брасе и последующий откат в discover на стороне клиента).

Каким образом slave ставший master-ом, при отвале последнего, сможет повлиять на абонента у которого не истекла dhcp сессия ?

Правильно ли понимаю, что абоненты не будут работать до истечения сессии или пока не переткнут кабель вручную ?

 

Share this post


Link to post
Share on other sites
В SE есть две сущности - полисер (rate-limit) и шейпер (sheduler). Полисер не влияет на ресурсы. Шейпер влияет. Сейчас цифра 16тыс на модуль для dual-stack подразумевает, что шейпер может быть включен для каждого из 16тыс. В шейпере всегда доступны 8 очередей на абонента. Как повлияет увеличение кол-ва абонентов на модуле на возможности планировщика - пока сказать сложно. Но повторюсь, что для плоисера - это не принципиально. К слову следует сказать, что в современных условиях наиболее оправданным является использование именно полисера, т.к. скорости у абонентов давно выпрыгнули за 1Мбит/с.

Правильно ли понимаю, что каждая из 8-ми очередей в шедулере имеет свой cir и pir, а над ними сидит общий шедулер со своим cir и/или pir, т.е. это иерархичный qos ?

К шедулеру можно вместо очередей привязать полисеры, правильно ?

 

Почему в даташите на 4x10GE карту разговор идет о 32k queued сабскрайберах IPv4 only, а для dual-stack это число в 2 раза меньше (сейчас).

Означает ли это, что на dual-stack сабскрайбера расходуется два шедулера, т.е. отдельные ограничения на IPv4 и IPv6 трафик или уменьшение в два раза кол-ва сабскрайберов завязано на другие проблемы/лимиты ?

Edited by rus-p

Share this post


Link to post
Share on other sites
Для CLIPS есть механизм резервирования на базе VRRP, но он stateless, т.е. подразумевает реконнект (выдача NAK на новом брасе и последующий откат в discover на стороне клиента).

Каким образом slave ставший master-ом, при отвале последнего, сможет повлиять на абонента у которого не истекла dhcp сессия ?

Правильно ли понимаю, что абоненты не будут работать до истечения сессии или пока не переткнут кабель вручную ?

Чтобы slave ставший master мог повлиять на абонента должна пройти половина lease time (renew). Получив renew новый master отвечает на него NAK, и клиент скатывается в DISCOVER автоматически.

Если lease time был 10мин, то через 5мин в худшем случае абонент будет переподключен.

Соответственно, пока не пришел очередной renew абонент не работает.

Share this post


Link to post
Share on other sites
В SE есть две сущности - полисер (rate-limit) и шейпер (sheduler). Полисер не влияет на ресурсы. Шейпер влияет. Сейчас цифра 16тыс на модуль для dual-stack подразумевает, что шейпер может быть включен для каждого из 16тыс. В шейпере всегда доступны 8 очередей на абонента. Как повлияет увеличение кол-ва абонентов на модуле на возможности планировщика - пока сказать сложно. Но повторюсь, что для плоисера - это не принципиально. К слову следует сказать, что в современных условиях наиболее оправданным является использование именно полисера, т.к. скорости у абонентов давно выпрыгнули за 1Мбит/с.

Правильно ли понимаю, что каждая из 8-ми очередей в шедулере имеет свой cir и pir, а над ними сидит общий шедулер со своим cir и/или pir, т.е. это иерархичный qos ?

К шедулеру можно вместо очередей привязать полисеры, правильно ?

там есть только rate и размер буфера в байтах. Это иерархический шедулер (до 5 уровней). Можно одновременно использовать policer и sheduler.

 

Почему в даташите на 4x10GE карту разговор идет о 32k queued сабскрайберах IPv4 only, а для dual-stack это число в 2 раза меньше (сейчас).

Означает ли это, что на dual-stack сабскрайбера расходуется два шедулера, т.е. отдельные ограничения на IPv4 и IPv6 трафик или уменьшение в два раза кол-ва сабскрайберов завязано на другие проблемы/лимиты ?

Сегодня PPA3 может 32к для v4 и 16k dual-stak с включенным шедулером. Без шедулера на PPA3 будет 48к v4 в ближайшее время.

Шедулер в отличие от полисера является как бы stack agnostic, он оперирует только понятием subscriber, полями QoS и WRED. Т.е. ему не важно сколько стэков и каких вы задействовали в subscriber-е.

 

Share this post


Link to post
Share on other sites
Чтобы slave ставший master мог повлиять на абонента должна пройти половина lease time (renew). Получив renew новый master отвечает на него NAK, и клиент скатывается в DISCOVER автоматически.

Если lease time был 10мин, то через 5мин в худшем случае абонент будет переподключен.

Соответственно, пока не пришел очередной renew абонент не работает.

А нагрузочные тесты на процессор по обработке 300сек/256к IPv4 сабскрайберов ~ 1k dhcp перестроений сессий ~ (renew, nak, discover, offer, request, reply) ~6kpps dhcp пакетов проводились ?

 

Еще раз спасибо. Очень помогли.

 

Share this post


Link to post
Share on other sites
Шедулер в отличие от полисера является как бы stack agnostic, он оперирует только понятием subscriber, полями QoS и WRED. Т.е. ему не важно сколько стэков и каких вы задействовали в subscriber-е.

т.е. полисер все же не stack agnostic и две штуки используемые на IPv4 и IPv6 дают как бы две разных трубы для смешанного трафика ?

И, если не использовать общий шедулер, то dual-stack абоненту придется предоставить, в общем случае, удвоенную скорость тарифного плана, сколько-то мегабит на IPv4 и столько же на IPv6 ?

Edited by rus-p

Share this post


Link to post
Share on other sites
А нагрузочные тесты на процессор по обработке 300сек/256к IPv4 сабскрайберов ~ 1k dhcp перестроений сессий ~ (renew, nak, discover, offer, request, reply) ~6kpps dhcp пакетов проводились ?

 

Еще раз спасибо. Очень помогли.

Да, проводились, но об этом в ЛС или задайте вопрос интегратору :).

 

Не за что. %)

Share this post


Link to post
Share on other sites
т.е. полисер все же не stack agnostic и две штуки используемые на IPv4 и IPv6 дают как бы две разных трубы для смешанного трафика ?

И, если не использовать общий шедулер, то dual-stack абоненту придется предоставить, в общем случае, удвоенную скорость тарифного плана, сколько-то мегабит на IPv4 и столько же на IPv6 ?

Полсиер может работать и так и так. Т.е. либо как единая труба для всех stack-ов абонента, либо по каждому stack-у индивидуально.

Если возьмете сегодняшний последний maintanance release, то там только общая труба. Летом будет работать по каждому stack-у индивидуально.

Share this post


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
Sign in to follow this