[macharius]

В этом топике предлагается обсуждать 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

[X-RaY™]

Да, тема интересная. Рассматриваю, как вариант взять пару(резерв, балансировка нагрузки) в роли брасов на ипое , доступ свитч-влан, опция 82, агрегация циски 3750(для аннамберед, выдаю реальные ип адреса),шейпер на фре и радиус дхцп сервер. Как я понимаю, SE в данном варианте, заменит шейпер и станет дхцп сервером(или достаточно релеить через него?), циску с агрегации л3 ни как не убрать, в таком варианте, на Se нету аннамбеерд?

[D^2]

Как я понимаю, SE в данном варианте, заменит шейпер

если говорить именно о шейпере - такое возможно в направлении out. до 8 очередей на абонента.

если говорить о полисинге (а при нынешних безлимитных скоростях этого достаточно), то нет ограничений

и станет дхцп сервером(или достаточно релеить через него?)

SE может выступать в роли DHCP сервера, может выступать в роли DHCP Proxy. во втором случае точно так же как и в первом с точки зрения абонента SE будет выглядеть как DHCP сервер.

циску с агрегации л3 ни как не убрать, в таком варианте, на Se нету аннамбеерд

ip unnumbered там есть, но если задача каждому абоненту давать /32, то там и без этого это работает. вернее только так и работает в случае ipoe.

в случае ipoeodot1q можно выдать подсеть больше, чем /32

Edited April 4, 2011 by D^2

[silitra]

Заказали железку, скоро должна приехать. Планирую заменить бордер, шейпер и нат.

[X-RaY™]

Спасибо за ответы. А какие варианты резервации и балансировки иопе есть, между SE ?

[macharius]

Спасибо за ответы. А какие варианты резервации и балансировки иопе есть, между SE ?

 

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

 

Когда в 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 в дальнейшем может потребоваться специальная настройка маршрутизации (зависит от того, как замыкается локальный трафик/пиринг на нем).

Edited April 6, 2011 by macharius

[John_obn]

Можно ли в SE сделать так, чтобы абонент идентифицировался подсетью, либо набором ip, на которые вешался бы один сервис (в терминологии ISG), т.е. он разделялся бы по ним, а не на каждый ip был свой сервис?

[D^2]

Можно ли в SE сделать так, чтобы абонент идентифицировался подсетью, либо набором ip, на которые вешался бы один сервис (в терминологии ISG), т.е. он разделялся бы по ним, а не на каждый ip был свой сервис?

для clips только в случае IPoEo802.1q

[John_obn]

Можно ли в SE сделать так, чтобы абонент идентифицировался подсетью, либо набором ip, на которые вешался бы один сервис (в терминологии ISG), т.е. он разделялся бы по ним, а не на каждый ip был свой сервис?

для clips только в случае IPoEo802.1q

Имеете в виду, что такую группу ip (или подсеть) необходимо выносить в отдельный vlan? Т.е. будет сервис на влан?

[macharius]

Можно ли в SE сделать так, чтобы абонент идентифицировался подсетью, либо набором ip, на которые вешался бы один сервис (в терминологии ISG), т.е. он разделялся бы по ним, а не на каждый ip был свой сервис?

для clips только в случае IPoEo802.1q

Имеете в виду, что такую группу ip (или подсеть) необходимо выносить в отдельный vlan? Т.е. будет сервис на влан?

 

Да, это будет "dot1q Subscriber". Т.е. этот влан нужно тянуть на SE, тогда можно выдать группу адресов и отполисить ее как единого абонента.

Тут есть также нюанс, что session initiation для non-DHCP абонентов как бы отсутствует, т.е. как только вы такого абонента прописали в влане на SE, он сразу принимает состояние UP, т.е. пытается себя авторизовать через процесс ААА.

[John_obn]

Да, не всегда удобно это. Получается более неудобно, чем в ASR. Неужели нет какого то простого решения данной задачи на маршрутизаторах такого уровня?

[macharius]

Да, не всегда удобно это. Получается более неудобно, чем в ASR. Неужели нет какого то простого решения данной задачи на маршрутизаторах такого уровня?

 

Ну что есть, то есть. На самом деле неудобство тут одно, то что такого абонента нужно держать в конфиге устройства. Но ведь в любом случае завязывать юр.лиц на аутентификацию в радиусе идеологически не очень правильно. А вот управлять ими по CoA и собирать по ним radius acct имхо самое то.

Если неудобство, это то что нет session initiation по arp или unknown siource ip, то тут все от платформы и идеологии зависит. Просто делать punt по каждому unknown source ip в kernel наша разработка считает косяком.

Так сказать it doesn't scale.

[ingress]

махариус, предлагаю выложить в открытый доступ видео и материалы с семинаров НАГа, семинар был _бесплатный_.

в чём ценность информации, пускай и из материалов учебных центров, которая была бесплатно передана неопределённому кругу лиц?

вы на трекер любой зайдите, там все курсы циски можно скачать(от na до ie), это не значит что у этих центров клиентов нет.

[macharius]

ingress, вашу идею я понял, попробую провентилировать данный вопрос через локальный эрик.

[slan]

И получается, что вланы абонентов (в случае если используется архитектура влан на абонента и каждому абоненту выдается подсеть) нужно тянуть до SE100, со всем ихним локальным трафиком ;-( Не много же тогда этот брас прожует! Вообщем, для такой архитектуры эта железка не подходит вообще! Не понятно только, что мешало разработчикам реализовать возможность каждому Subscriber присваивать подсеть?

Edited April 5, 2011 by slan

[D^2]

Не много же тогда этот брас прожует!

пока не кончитя bandwidth

Вообщем, для такой архитектуры эта железка не подходит вообще!

в чем проблема абоненту поставить CPE? 1 абонент = 1 адрес /32 = 1CPE

[slan]

Не много же тогда этот брас прожует!

пока не кончитя bandwidth

Вообщем, для такой архитектуры эта железка не подходит вообще!

в чем проблема абоненту поставить CPE? 1 абонент = 1 адрес /32 = 1CPE

 

См. внимательно мой пост - "в случае если используется архитектура влан на абонента и каждому абоненту выдается подсеть"

То есть, сеть отличная от /32 (например /29)

Найдите пожалуйста решение конфигурации для SE100, при котором на нем можно приземлить подсети абонентов (отличные от /32 ;-), при том, что бы это было без извращений (не забываем для чего нужен брас - нат, ограничение по полосе, управление сервисами), и что бы не пришлось тянуть на него вланы абонентов и гонять через него весь локальный трафик.

Edited April 5, 2011 by slan

[Senokos]

Важный момент: Поверх абонентского LAG не работают NAT и RSE.

 

Вопрос решается поднятием OSPF сессии в сторону ядра на 2-3 линка и балансировкой между ними. Не самый удобный вариант, но работает.

[macharius]

Не много же тогда этот брас прожует!

пока не кончитя bandwidth

Вообщем, для такой архитектуры эта железка не подходит вообще!

в чем проблема абоненту поставить CPE? 1 абонент = 1 адрес /32 = 1CPE

 

См. внимательно мой пост - "в случае если используется архитектура влан на абонента и каждому абоненту выдается подсеть"

То есть, сеть отличная от /32 (например /29)

Найдите пожалуйста решение конфигурации для SE100, при котором на нем можно приземлить подсети абонентов (отличные от /32 ;-), при том, что бы это было без извращений (не забываем для чего нужен брас - нат, ограничение по полосе, управление сервисами), и что бы не пришлось тянуть на него вланы абонентов и гонять через него весь локальный трафик.

 

 

Никто и не позиционирует SE100 как лекарство на все случаи жизни. В каждое оборудование вкладывается определенная концепция построения сети в том числе и сети доступа, и SE тут не исключение.

Грубо говоря,

1. Для физ.лиц предлагается к использованию концепция /32 на абонента.

2. Для юр.лиц можно использовать не только /24, /28 но также и разнобой IP адресов. При этом предполагается иметь dot1q pvc выделенный на такого абонента. Более того этот абонент может быть например, подключен к bridge группе в самом SE, и запустить в ней вообще не IP протокол. При этом вы управляете этими подключениями и сервисами по CoA и собираете по ним radius acct, как вариант.

 

Говоря о юр.лицах вообще, и их трафике, который требовал бы смыкаться на уровне браса, то они имхо обычно генерят очень мало.

Edited April 5, 2011 by macharius

[ingress]

почему нет нормального внешнего управления? допустим по rcp/rsh или передача строчки конфига через аттрибуты VSA?

дёргать каждый раз файл по тфтп через снмп запрос не кошерно. а если мне надо менять конфиг на каждый конект пользователя? хочу создавать индивидуальную предварительно не сконфигурированую нат полиси для каждого.

 

можно ли сделать поведенческий иерархический QoS без платы DPI?

допустим резать полосу конкретной услуги/ограничение количества соединений конкретной услуги(общее колво tcp,udp,icmp и др. сессий) в зависимости от скаченных мегабайт в совокупности с зависимостью от времени?

[macharius]

почему нет нормального внешнего управления? допустим по rcp/rsh или передача строчки конфига через аттрибуты VSA?

дёргать каждый раз файл по тфтп через снмп запрос не кошерно. а если мне надо менять конфиг на каждый конект пользователя? хочу создавать индивидуальную предварительно не сконфигурированую нат полиси для каждого.

 

На счет rcp/rsh вопрос понятен. судя по всему ранее не было потребности. В целом, на сколько я понял, вы про static nat записи? Сечас эту тему раскруичваем в реальной сети. есть нюансы, резултаты будут добавлены в топик позже.

 

можно ли сделать поведенческий иерархический QoS без платы DPI?

допустим резать полосу конкретной услуги/ограничение количества соединений конкретной услуги(общее колво tcp,udp,icmp и др. сессий) в зависимости от скаченных мегабайт в совокупности с зависимостью от времени?

все что можно сделать в этом направлении без платы DPI, то это повесить на абонентский circuit так называемый flow admission control profile. Который повзоляет ограничить абонента по кол-ву flow сверху, а также задать скорость прироста новых flow в секунду.

[caz]

немного о DPI:

- DPI ориентирован только на multimedia и peer-to-peer, таких вещей как всевозможные mail протоколы или url-filtering как в SCE в нем нет и не предвидится.(возможно все же когда-то предвидится?)

- DPI заточен только под BRASовые приложениях, т.е. грубо говоря приаттачить dpi policy к не абонентской circuit не получится

 

по SE100, если уж кто будет делать NAT на SE в помощь команда - show card 2 nat translation context xxxx source any, если число сессий уйдет за 1М, то возможен сюрприз в виде ребута железки, а еще лучше настроить Flow Admission Control профиль, где задать ограничение в 950к сессий.

 

p.s.

выложите IP Services and Security Configuration Guide и минимум 50-60% вопросов у большинства исчезнет.

 

p.s.s

кто-то может сказать что NAT на текущей версии OS полностью работает корректно? когда-то пытался завести, вроде как все получилось, но начали жаловаться абоненты, что в некоторые игры стало невозможно играть + перестали работать какие-то приложения..

Edited April 5, 2011 by caz

[shefys]

немного о DPI:

- DPI ориентирован только на multimedia и peer-to-peer, таких вещей как всевозможные mail протоколы или url-filtering как в SCE в нем нет и не предвидится.(возможно все же когда-то предвидится?)

Что под подразумевается под поддержкой mail-протоколов?

URL Filtering - вопрос кратчайшего будущего.

DPI ориентирован на жрущие трафик приложения - что в случае с MSER вполне себе актуально. Пользователь любит качать (p2p, file-sharing), играть (gaming), говорить (voip) и смотреть видео (streaming). Использование ASE совместно с BRAS даёт вам возможность приоритезировать, классифицировать и резать трафик для каждого из пользователей по отдельности + собирать статистику по типу трафика.

 

[local]Ericsson#show dpi traffic-management category 
all
file-transfer
gaming
instant-messaging
p2p
social-networks
streaming
transport
voip

 

- DPI заточен только под BRASовые приложениях, т.е. грубо говоря приаттачить dpi policy к не абонентской circuit не получится

Это написано в документации :)

 

по SE100, если уж кто будет делать NAT на SE в помощь команда - show card 2 nat translation context xxxx source any, если число сессий уйдет за 1М, то возможен сюрприз в виде ребута железки, а еще лучше настроить Flow Admission Control профиль, где задать ограничение в 950к сессий.

Про ограничение в 1М трансляций на модуль: при нехватке ОЗУ может перегрузится только линейный модуль (PPA) - control plane (XCRP) перезагружаться не будет. В случае с SE100 это перезагрузка всех интерфейсов кроме управления, т.к. в нём один встроенный "модуль".

[caz]

Что под подразумевается под поддержкой mail-протоколов?

 

возможно ли детектить спам, как в той же SCE?

 

URL Filtering - вопрос кратчайшего будущего.

 

через сколько, месяц, год?

 

Про ограничение в 1М трансляций на модуль: при нехватке ОЗУ может перегрузится только линейный модуль (PPA) - control plane (XCRP) перезагружаться не будет. В случае с SE100 это перезагрузка всех интерфейсов кроме управления, т.к. в нём один встроенный "модуль".

 

да, вы правы, посмотрел тут crash log..

[shefys]

Что под подразумевается под поддержкой mail-протоколов?

 

возможно ли детектить спам, как в той же SCE?

 

URL Filtering - вопрос кратчайшего будущего.

 

через сколько, месяц, год?

 

Про ограничение в 1М трансляций на модуль: при нехватке ОЗУ может перегрузится только линейный модуль (PPA) - control plane (XCRP) перезагружаться не будет. В случае с SE100 это перезагрузка всех интерфейсов кроме управления, т.к. в нём один встроенный "модуль".

 

да, вы правы, посмотрел тут crash log..

 

1. Если вы говорите про вот это определение спама с помощью SCE, то задача SCE здесь просто слать логи по определению новых flow's от абонента в Интернет tcp/25. Тоже самое можно делать и на ASE. Логи вы эти можете получать в сислог и обрабатывать любым способом, по результатам обработки вы можете отправить RADIUS CoA на больного абонента и применить к нему какую-нибудь политику:

1. http redirect на страницу о том, что у хомячка вирус
   
2. повесить обычный acl, зарезающий smtp
   
3. применив политику dpi, зарезающую smtp
   
4. больше ничего не пришло сходу на ум :)
   

 

2. Ну, я не могу говорить за разработчиков. Я скажу в следующем основном релизе.

3. Может быть вам стоит добавить ещё один SE100? :)