Ericsson SmartEdge

[rus-p]

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

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

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

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

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

Edited January 25, 2011 by rus-p

[macharius]

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

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

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

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

 

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

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

 

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

Edited January 25, 2011 by macharius

[rus-p]

Кол-во абонентов 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 January 26, 2011 by rus-p

[macharius]

Кол-во абонентов 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 классами на полисер, кол-во полисеров может быть столько сколько абонентов, на производительность не влияет.

 

[rus-p]

Кол-во абонентов 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 сессий на две коробки ?

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

 

 

[macharius]

Ок. Спасибо.

 

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

 

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

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

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

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

 

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

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

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

Edited January 26, 2011 by macharius

[rus-p]

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

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

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

 

[rus-p]

В 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 January 26, 2011 by rus-p

[macharius]

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

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

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

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

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

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

[macharius]

В 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-е.

 

[rus-p]

Чтобы 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 пакетов проводились ?

 

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

 

[rus-p]

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

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

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

Edited January 26, 2011 by rus-p

[macharius]

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

 

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

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

 

Не за что. %)

[macharius]

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

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

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

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