macharius

Это очень важный момент, который требует дополнительного разъяснения. Когда в SE создается абонент, то он привязывается к определенному порту. Абонент имеет какой-то IP адрес. Для случая IPoE (dynamic или static clips) весь приходящий на абонентские порты SE трафик демультиплексируется по признаку Source IP. Т.е. если абоненту А был назначен IP_A, то все пакеты, которые с таким то source IP_A, ассоциируются с абонентской сессией А. Сложность (а зачастую невозможность) организации резервирования заключается в том, что абонентская сессия рождается в конкретном GE порту/влане. Иллюстрация на базе примера, предположим, если есть схема <DHCP_Clinet>---<Relay>----<L3_Switch>---+---<GE1_SE> | +---<GE2_SE> Как понять, куда попадет клиент, на GE1_SE или GE2_SE? Тут все зависит от того, кого из них выберет Relay. И это обычно прибивается гвоздями. Т.е. вы говорите релею, что мол адрес DHCP сервера это GE2_SE, например. И все, отбалансирвоать тут никак. Более того, от L3_Switch в дальнейшем может потребоваться специальная настройка маршрутизации (зависит от того, как замыкается локальный трафик/пиринг на нем).

В этом топике предлагается обсуждать SE100. По ссылке подробные How To (пока только CLIPS и Policy). http://www.nag.ru/projects/setup/brand/22259/ Общая характеристика устройства. 6 GE трафик портов, BRAS/BGP/NAT/NetFlow. 7+7 Mpps (in+out), 1M RIB/FIB, Виртуализация, Модульная ОС с хорошей гранулярностью по процессам. SE100 прежде всего представляет интерес с точки зрения BRAS или Subscriber Management функциональности. Т.е. это управление (включение/отключение/изменение) через процесс ААА: абонентскими адресами, ACL, скоростями, квотами, сервисами, PBR, NAT-функциями и проч. Доступ: PPPoE, L2TP LAC/LNS, CLIPS (DHCP), Static IP. Важно: MS-CHAP не поддерживается. Scaling. Обычно первым в SE100 заканчиваются uplink порты. Т.к. всего 6 портов, то 3 под абонентов и 3 под аплинки. Учитывая современные тарифы и скорости, это порядка 5-8тыс абонентов онлайн. При упоре в «полку» по портам c 5-8тыс абонентами, для типовой конфигурации рррое/clips с абонентскими acl, rate-limit, acct-alive 10-15min, квотами, и иногда NATом нагрузка на CPU не превышает 5-20%. Отдельно следует сказать про L2TP доступ, пока не видел случая, где было бы больше 4тыс абонентов онлайн, при этом нагрузка на CPU в районе 5-10%. Т.е. можно легко запустить на него больше, лишь бы хватило аплинков. NAT. Есть поддержка NAPT, поддерживается 1М трансляций. Текущая реализация NAPT понимает только ICMP, UDP, TCP, есть функции admission контроля и настройки таймреов. NAT в SE (последняя глава) расписан очень подробно, там же приведены ограничения и особенности: http://www.nag.ru/projects/setup/67855/ Т.к. NAT это функция Data Plane, то он не влияет на CPU вообще. С точки зрения NAT-scaling, то все зависит от доступной памяти ASIC-ов (1М трансляций, это штатно). Важный момент: NAT не работает в случае с L2TP доступом. SE100 поддерживает по-сервисный accountintg. В SE эта функциональность называется RSE (RADIUS Service Engine). RSE, также как и NAT, не работает для L2TP доступа. Но по-сервисная скорость как таковая работает для любого типа доступа. LACP. В SE есть два типа LAG. Для аплинков и для портов с абонентами. В первом случае все стандартно, бланасировка по Src/Dst IP (по умолчанию), либо по 5-tuple (Src/Dst IP/Port Protocol). Во-втором случае балансировка circuit-based, т.е. грубо говоря по Src MAC, соответственно данный LAG ориентирован на L2 доступ. Важный момент: Поверх абонентского LAG не работают NAT и RSE. NetFlow. Есть поддержка NetFlow v5 (IPFIX), а также sampling. В SE функциональность NetFlow включается либо на аплинках, либо при помощи ААА индивидуально на абонентских сессиях (PPPoE, CLIPS). NetFlow нельзя включать индивидуально на сессиях L2TP (только на аплинках). Защита от DoS. Для PPPoE доступны следующие механизмы. Rate-limit пакетов PADI и PADR на коробоку целиком. Per MAC throttling для PADI и PADR. Для CLIPS есть rate-limit DHCP пакетов на коробку целиком. Также как и для PPPoE есть DHCP throttling: “per-mac” или “per-mac-and-relay” Из самого основного, пожалуй, все. Содержание будет обновляться. Появился закрытый раздел на форуме для обладателей Ericsson Smartedge. Заявки на добавление в группу можете отправлять на адрес smartedge@nag.ru

Я не сторонник копи/паста из datasheet. Могу лишь сказать по существу на тему SE100. За последнее время накопился опыт работы этой коробки в наших российских условиях в различных задачах. Scaling. SE100 даст фору любому «однокласснику». С точки зрения кол-ва абонентов, то раньше закончатся аплинки (которые можно собрать в LAG). Сколько поместится пользователей в 3 Гига на аплинках зависит от тарифов. Неважно, сколько их будет 6к или 10к и какой там будет pps – это почти не сказывается на CPU. Сложные функции без доп сервисных модулей. Есть случаи, когда SE100 используют под L2TP доступ. Из реальных примеров видел, как используют SE100 под нагрузкой в 4к l2tp абонентов. Нагрузка на CPU – в районе 5%, т.е. можно 8к l2tp и больше, сколько аплинков хватит. L2TP доступ ничем не отличается от pppoe/clips с точки зрения дополнительного load на CPU и без просаживания по pps, которых у него более чем достаточно. А ведь здесь речь идет о достаточно большом количестве туннелей. При этом SE100 не является soft- маршрутизатором. Тут также как в больших коробках Control и Data Plane полностью разделены друг от друга. Спросите у НАГа какой ценник на эту коробку сегодня, а еще лучше возьмите у них ее на тест, и многие вопросы/сомнения отпадут сами собой. Я могу продолжать и дальше. Но предлагаю создать отдельную тему по SE100. Т.к. в этом топике народ вроде cisco хотел пообсуждать.

Добрый день, с точки зрения цены в перерасчете на 1 абонента, то лицензия на 32 тыс выгоднее чем скажем на 8 тыс. Вы можете апгрейдить лицензии, т.е. добавлять ключи к уже введенным. Скажем был ключ на 16 тыс., если нужно расширить до 24 тыс, до добавляется ключ на 8 тыс к тому, что уже есть. Итого будет 24 тыс. На счет цен - спросите у реселлера/интегратора.

Ключевое слово тут Subscriber Managament, т.е. можно сказать, что ваше устройство умеет выполнять функции BRAS.

термину BRAS уже достаточно много лет, это Broadband Remote Access Server. Сегодня есть и другие новые названия, такие как BNG (Broadband Network Gateway) и проч., суть таже. Под этими терминами подразумевают промышленный маршрутизатор, выполняющий функции Subscriber Management. Т.е. это не просто терминация абонента, а совпровождающая эту терминацию комплиментарня функциональность - шейп, списки досутпа, статистика, сервисы и проч. PPTP это всего лишь способ доступа абонента, BRAS обычно поддерживает большой список инкапсуляций: PPP/PPPoX, IPoE, DHCP, L2TP LAC, LNS, LTS. К слову о PPTP - то с точки зрения технологии это тупик, если говорить о промышелнных коробках без привязки к какому-либо вендору.

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

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

Правильно ли понимаю, что каждая из 8-ми очередей в шедулере имеет свой cir и pir, а над ними сидит общий шедулер со своим cir и/или pir, т.е. это иерархичный qos ? К шедулеру можно вместо очередей привязать полисеры, правильно ? там есть только rate и размер буфера в байтах. Это иерархический шедулер (до 5 уровней). Можно одновременно использовать policer и sheduler. Сегодня PPA3 может 32к для v4 и 16k dual-stak с включенным шедулером. Без шедулера на PPA3 будет 48к v4 в ближайшее время. Шедулер в отличие от полисера является как бы stack agnostic, он оперирует только понятием subscriber, полями QoS и WRED. Т.е. ему не важно сколько стэков и каких вы задействовали в subscriber-е.

Каким образом slave ставший master-ом, при отвале последнего, сможет повлиять на абонента у которого не истекла dhcp сессия ? Правильно ли понимаю, что абоненты не будут работать до истечения сессии или пока не переткнут кабель вручную ? Чтобы slave ставший master мог повлиять на абонента должна пройти половина lease time (renew). Получив renew новый master отвечает на него NAK, и клиент скатывается в DISCOVER автоматически. Если lease time был 10мин, то через 5мин в худшем случае абонент будет переподключен. Соответственно, пока не пришел очередной renew абонент не работает.

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

Для какого чипа цифры 32k->16k, PPA2 (1x10GE) или PPA3 (4x10GE overbook 2:1), или пока для обоих типов ? Пока одинаково для PPA2/PPA3, для PPA3 будет увеличение, для PPA2 - нет. Да, для dual-stack, и только на PPA3. Не знаю откуда взята цифра в 512к для XCRP4, для него всегда было 256к. Сократилось все в четыре раза, поскольку data structure кода под IPv6 увеличились в 2-4 раза (сам адрес v6 длиннее v4 и проч.) есть обычный token backet полисер (rate-limit), ограничен - 8 классами на полисер, кол-во полисеров может быть столько сколько абонентов, на производительность не влияет.

Да, умеют. Пока что для PPPoE, весной для L2TP LNS, потом для CLIPS. Кол-во абонентов dual-stack на модуль сокращается с 32к до 16к. На систему с XCRP4 ограничение сверху в 64к. Для чистого IPv6 абонента лимиты такие же. Однако, будет увлеичение кол-ва IPv6 на платах поколения РРА3 в течении года. В ближайшей преспективе нет. Сегодня соотношение реальная производительность / функциональная насыщенность более чем оптимальна. В скором времени (год, два) появится XCRP5 для увеличения производительности control plane. Платформа находится в данный момент в активной фазе разработке, и будет находится в ней еще очень очень долго.

+1 Для этого у правильных вендоров есть такие штуки как MAC-address move loop detection, когда после определенного кол-ва перемещений MAC-адреса за заданный промежуток времени трибутарный интерфейс блокируется. Хрена лысого он блокируется ) Таблица портится от единственного пролета, и все встает колом. А все эти алгоритмы придуманы на несколько переизучений, и рассчитаны на исправление ситуации у двуногих клиентов, а не на сохранение таблицы в коре. Сорри, я не совсем уловил. MAC move detection задумывался для защиты от backdoor линков между двумя СЕ подключенных каждый к своему РЕ. В коре обычно split-horizon включен, там петли не может образоваться. Вы судя по всему какой-то конкретный дизайн подразумеваете и какого-то конкретного вендора.

+1 Для этого у правильных вендоров есть такие штуки как MAC-address move loop detection, когда после определенного кол-ва перемещений MAC-адреса за заданный промежуток времени трибутарный интерфейс блокируется.

имхо тут от возможностей оборудования все зависит, изолировать бродкаст штормы полностью вряд ли удастся, но вот такие вещи как rate-limit для - Broadcast traffic - Multicast traffic - Traffic with unknown destination frames на трибутарных интерфейсах ваших РЕ могут реально помочь.

"Не дороже" - это не аргумент. Перепозлать с cisco на нового вендора хотелось бы аргументировано. Это вопрос очень общий и у всех всегда собственный взгляд на сеть и способ ее построения. В целом сравнение можно охарактеризовать так: ASR платформа с централизованной архитектурой, SE с полностью распределенной. Возможности самого современного ESP40 равны возможностям одного слота в SE. Соответственно, при сравнимом функционале ASR и SE, вы можете наращивать pps и кол-во абонентов в SE в рамках одного шасси, в ASR - нет.

Добрый день, отличие заключается в следующем, 1. LACP обычный - организация LAG для скажем аплинков или core facing интерфейсов с инкапсуляцией dot1 например. Балансирование при этом L3-based (Src./Dst. IP) либо L4-based (IP 5-tuples). 2. LACP access - это возможность собирать LAG на так называемых subscriber facing интерфейсах. При этом LACP используется как средство защиты и данный режим актуален только для модульных SE. Общий смыл такой, что вы собираете LAG-группу используя интерфейсы с двух линейных модулей. Балансирование при этом circuit-based, т.е. по-сессионно (PPPoE/IPoE). Если выходит из строя один модуль LAG-группы, то все те сессии которые на нем жили подхватываются вторым модулем , без обрыва абонентских сессии и без перерыва трафика - схема защиты 1:1. 3. LACP access economical - это тоже самое что и Access LAG, но только с поддержкой схем N:1. Т.е. в LAG-группу собираются интерфейсы с нескольких модулей, один из модулей является backup-ом на случай вылета одного из основных. Балансирование при этом circuit-based, т.е. по-сессионно (PPPoE/IPoE). Если выходит из строя активный модуль LAG-группы, то все те сессии которые на нем жили подхватываются backup-ным модулем, без обрыва абонентских сессии но с небольшим перерывом трафика. Данный режим возможно использовать и в одно-модульном устройстве SE100 из расчета того, что никакого backup-а нет. P.S. Укажите явно maximum-links X в link-группе - должно взлететь.

Учитывая внутрисетевую 100 Мбитную халяву прелесть сомнительная.Сомнительна как раз стомегабитная внутрисетевая халява как конкурентное преимущество.Как уже неоднократно говорилось, при 4-8 мегабит анлимитной внешки - локалка становится не нужна. Нет, гики и фрики всегда найдутся, но "ан масс" - не нужна. Например? Например 6500 с ES-20+ или SIP-400 - чем не коммутатор? 1. это не коммутатор 2. сколько стоит коробка с модулями ES20+?? доумощнить брас дополнительным модулем получается дешевле. вот и вся логика.

имхо это уже не коммутаторы... это должен быть полноценный router, т.к. основная проблема "коммутаторов" в этой роли - это размер arp cache.

У нас в России есть несколько работающих по такой схеме сетей с абонентской базой порядка 15тыс. По миру полно кто использует (один из самы крупных операторов Korea Telecom - там юзеров миллионы).

to Гость_гость_* Скажу честно, сходу не знаю. Обычно используют для этих целей tacacs+… SE генерит событие по умолчанию в сислог когда кто-то заходит и выходит. Давая команду show config, выдается инормация о том, кто его последний раз менял и когда.

to Гость_гость_* да совершенно верно, а вообще в kernel не так уж и много кому позволено обращаться в принципе - snmp, telnet, ssh, ftp, tftp, bgp.

to Гость_гость_* Идеологически правильно зарыть доступ через admin-acl, например вот так ! ip access-list admin-acl-snmp seq 10 permit ip 172.16.1.0 0.0.0.15 seq 200 deny udp any any eq snmp seq 210 deny udp any any eq snmptrap seq 230 permit ip any any ! admin-access-group admin-acl-snmp in ! это фильтр на обращения в kernel операционной системы, т.е. безотносительно к адресу управления 192.168.100.1

to Гость_eugeny_* Эта команда задокументирована - она есть в стандартной документации. На счет 900. Я читаю цитату и не вижу противоречий. Там написано, что это значение ни при каких обстоятельствах не должно быть меньше 60 и желательно, чтобы оно не было меньше 600. Так вот 900 больше 600 и больше 60. А вообще, речь идет о посервисном аккаунтинге, он не описан ни в одном RFC, и каждый вендор решает сам как его реализовывать. Для всей сессии вы можете выставить это значение в 600 например. Ваша цитата как раз таки наоборот предупреждает о том, что иметь малые значения этого параметра очень опасно. Скажите в связи с чем вызвано желание иметь супер короткий интерим?