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

Выбор между централизованным PPPoE и "VLAN на пользователя"

Здравствуйте, коллеги.

 

В продолжении историй описанных здесь, здесь и здесь

 

Решено рассмотреть проект по замене магистрального оборудования. Allied Telesyn убираем, ставим что-нибудь вроде 3560 кошек.

С точки зрения L2 в сети ничего не меняется, с физической топологией скорее всего будем делать "лепестки" от ядра сети, но несколько позже.

 

Sale-условия те же: платная локалка и платный Инет. В различных конфигурациях: только Инет, только локалка, все вместе.

И Инет и Локалка режется на BRAS'е. Плюс к этому - Инет еще управляется на граничной циске (PBR).

 

 

Встал перед дилемой:

1) Если оставлять вариант c централизованным BRAS'ом (или кластером из BRAS'ов, неважно какого вендора), то BRAS который сможет прожевать 1-2-5 гигабит локалки, как стало понятно из соседней темы, будет стоить от $20к. Разумно встает вопрос: есть ли другой вариант?

 

2) Железо на доступе все таки L2 умное, может быть стоит посмотреть в сторону VLAN на пользователя?

 

По второму варианту есть несколько вопросов. Итак, исходные условия таковы:

1) На доступе стоит Allied Telesyn AT-8524M, к которому напрямую подключены юзеры. Судя по даташиту:

http://www.alliedtelesis.com/media/datashe...0-family_ds.pdf Железка умеет DynamicVLAN Assignment через 802.1x, а также GVRP.

2) На магистраль можно попробовать убедить инвесторов поставить например 3560, на ядро 2х3750.

3) доступ к платной локалке и Инету давать только после 802.1x авторизации.

 

Собственно вопросы:

1) Допустим удалось настроить RADIUS и запихивать каждого юзера после авторизации в свой VLAN. Как ему выдать серый статический адрес? Если я не ошибаюсь, DHCP выдает динамику из пула, так? Как выдать статику?

2) Если все таки как-то удастся выдать через DHCP серую статику, что помешает юзеру выключить DHCP и прописать на адаптере все что заходчется и работать под эти адресом? Выдавать на каждый VLAN /30 подсеть?

3) Допустим что удалось выдавать через DHCP серую статику и как-то обеспечить вариант, что юзер левый адрес никак поставить не сможет, а может работать только с тем адресом, который ему выдали. Нужен ли в таком варианте отдельный BRAS для Инета или в этой схеме где есть однозначность приннадлежности определенного адреса юзеру, дополнительную авторизацию для Инета можно не использовать?

4) На чем терминировать VLAN (L3). На каком центральном свиче? Catalyst 6500? или можно использовать что попроще, может прямо на ядре из планируемых к установке 2х3750?

5) Между свичами доступа\магистрали\ядром информация о динамически создаваемых VLAN распространяется по GVRP. А на свиче(ах) которые все это терминируют как все организовано? Заранее нарезано 4к вланов, прикручен к каждому VLAN IP-интерфейс с /30 подсеткой. Или как?

 

Извиняюсь за глупые вопросы, но со схемой VLAN на пользователя не работал.

 

Заранее спасибо за ответы.

 

Share this post


Link to post
Share on other sites

1) а зачем вам 802.1x если у вас vlan на юзера?

2) зачем вам выдавать серые ip юзерам если у вас vlan на юзера?

3) на счет ваших пунктов 2,3,5. а почему бы не воспользоваться IP Unnumbered (http://forum.nag.ru/forum/index.php?showtopic=46246). выдадите каждому юзеру по 1 белому ip (не надо расточительной /30). доступ к вашей платной локалке/инету будете рулить с ядра.

Share this post


Link to post
Share on other sites

в VLAN per User можно выдавать целую серую сеть по динамическому dhcp

На бордере натить и шейпить всю юзеровскую подсеть, это никак не повлияет на настройки и производительснотсь (будет маска /24 или /28 вместо /32)

 

Терминировать их можно на 3550...3760 железках что позволит wirespeed для локалки.

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

 

Заводить VLAN нужно только локально, вниз можно динамическим протоколом, на циске ручками или простейшим скриптом. Если в биллинге есть возможность держать поле VID для юзера, то все модно автоматизировать.

 

4 узла в фулл-меш, это 3 Гбита локальной скорости обмена с ядром + N Гигабит обмена между даунлинками (если у вас свичи доступа цепляются по гигабиту). С моей точки зрения это намного более производительная и устойчивая схема чем затаскивание всех вланов на жирную железку в самом ядре, чем часто грешат эзернетчики.

Share this post


Link to post
Share on other sites
в VLAN per User можно выдавать целую серую сеть по динамическому dhcp

На бордере натить и шейпить всю юзеровскую подсеть, это никак не повлияет на настройки и производительснотсь (будет маска /24 или /28 вместо /32)

 

Терминировать их можно на 3550...3760 железках что позволит wirespeed для локалки.

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

 

Заводить VLAN нужно только локально, вниз можно динамическим протоколом, на циске ручками или простейшим скриптом. Если в биллинге есть возможность держать поле VID для юзера, то все модно автоматизировать.

 

4 узла в фулл-меш, это 3 Гбита локальной скорости обмена с ядром + N Гигабит обмена между даунлинками (если у вас свичи доступа цепляются по гигабиту). С моей точки зрения это намного более производительная и устойчивая схема чем затаскивание всех вланов на жирную железку в самом ядре, чем часто грешат эзернетчики.

и все таки зачем вообще ему нужны серые ip и nat? что мешает выдавать юзерам белые ip и, как вы и говорили, терминировать их на уровне дистрибьюции - это и будет их "локалка".

просто потом от него появится очередная тема на форуме "чем натить X-сотен мбит"..

Share this post


Link to post
Share on other sites
в VLAN per User можно выдавать целую серую сеть по динамическому dhcp

На бордере натить и шейпить всю юзеровскую подсеть, это никак не повлияет на настройки и производительснотсь (будет маска /24 или /28 вместо /32)

 

Терминировать их можно на 3550...3760 железках что позволит wirespeed для локалки.

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

 

Заводить VLAN нужно только локально, вниз можно динамическим протоколом, на циске ручками или простейшим скриптом. Если в биллинге есть возможность держать поле VID для юзера, то все модно автоматизировать.

 

4 узла в фулл-меш, это 3 Гбита локальной скорости обмена с ядром + N Гигабит обмена между даунлинками (если у вас свичи доступа цепляются по гигабиту). С моей точки зрения это намного более производительная и устойчивая схема чем затаскивание всех вланов на жирную железку в самом ядре, чем часто грешат эзернетчики.

и все таки зачем вообще ему нужны серые ip и nat? что мешает выдавать юзерам белые ip и, как вы и говорили, терминировать их на уровне дистрибьюции - это и будет их "локалка".

просто потом от него появится очередная тема на форуме "чем натить X-сотен мбит"..

а если выдавать всем подряд белые, появится тема "как и чем зарезать торренты" Так что уж по мне лучше пару сотен мбит отнатить.
Edited by Nafanya

Share this post


Link to post
Share on other sites
и все таки зачем вообще ему нужны серые ip и nat? что мешает выдавать юзерам белые ip и, как вы и говорили, терминировать их на уровне дистрибьюции - это и будет их "локалка".

просто потом от него появится очередная тема на форуме "чем натить X-сотен мбит"..

Не все пользователи хотят публичные адреса из-за вирусного трафика, идущего извне. По-моему, лучше уж натить, чем перманентно бороться с вирусным флудом в локалке.

Share this post


Link to post
Share on other sites

Первая и главная причина использования NAT в схеме VLAN per User это возможность давать пользователю подсети. Выдавать такое количество белых адресов накладно и расточительно. Не использовать большие сети и DHCP - глупо, ведь это конкурентное преимущество перед другими методами.

 

Вторая причина - защита. NAT дает дополнительную степень защиты от внешнего вредного трафика, при этом внутресетевые фильтры категорически упрощаются, поскольку вся локалка описывается двумя-тремя правилами.

 

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

 

Отсюда и четвертая причина - ренамберинг при смене провадера.

 

Аругмент про перегрузку НАТ сервера в этой схеме приводить смысла нет, поскольку нагрузка на нат сервера паралелица без единой заминки. С первого коммутатора дефолт на NAT1 со второго на NAT2 и все. И не будет на нем сотен мегабит, если так много пользователей то внутренний обмен на скоростях в сотни мегабит увеличит коэффициент мультиплексирования. Дайте пользователям в LAN 100 мбит и они сами побегут на внутренний DC++, человек ведь ищет где лучше.

Share this post


Link to post
Share on other sites
Не использовать большие сети и DHCP - глупо, ведь это конкурентное преимущество перед другими методами.
Не понял связи...Публичный адрес можно выдавать по DHCP.

И публичный адрес - конкурентное преимущество, так как под ним гарантировано будут работать все сервисы. А ведь именно за это абонент и платит деньги...

 

Дайте пользователям в LAN 100 мбит и они сами побегут на внутренний DC++, человек ведь ищет где лучше.
Дайте пользователям хороший безлимитный тариф и публичный адрес - и весь мир станет для них локальной сетью. И к вам потянутся, человек ведь ищет где лучше. ))

Share this post


Link to post
Share on other sites
в VLAN per User можно выдавать целую серую сеть по динамическому dhcp
Всё конечно зависит от размеров сети и сервисов в этой сети, но.. имхо в любом случае вот тут главная ошибка.

Самым ценным ресурсом в метроезере является размер мак таблицы, при таком подходе вы его израсходуете в два, а то и в три раза быстрее.

Выбор модели Vlan per User или Vlan per Service определяется скорее не вкусом, а умением железа на агрегации/дистрибьюции/ядре (размеры у всех разные, для кого то и агрегация ядро) делать selective q and q.

На бордере натить и шейпить всю юзеровскую подсеть, это никак не повлияет на настройки и производительснотсь (будет маска /24 или /28 вместо /32)

Терминировать их можно на 3550...3760 железках что позволит wirespeed для локалки.

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

Да да, и получить пионернет аля корбинка только для одного сервиса. Метроезер это всего лишь труба L2 точка-точка от пользователя до браса или до границы mpls сети с входом в eompls туннель. Будут железки умеющие совмещать в себе pe mpls сети и bras замечательно, но пока приходится держать выделенные brasы, не говоря уже про терминацию на коммутаторах.
Заводить VLAN нужно только локально, вниз можно динамическим протоколом, на циске ручками или простейшим скриптом. Если в биллинге есть возможность держать поле VID для юзера, то все модно автоматизировать.
В билинге можно держать dhcp opt-82, через него же делать AAA со всеми пользовательскими настройками порта, в случае vlan per user конечно заводить только локально, только потом q and q накрывать и на границе сети выборочно эти вланы доставать через selective q and q
4 узла в фулл-меш, это 3 Гбита локальной скорости обмена с ядром + N Гигабит обмена между даунлинками (если у вас свичи доступа цепляются по гигабиту). С моей точки зрения это намного более производительная и устойчивая схема чем затаскивание всех вланов на жирную железку в самом ядре, чем часто грешат эзернетчики.
Sonne, при всём моём уважении к вам и к этим достойным коммутаторам на которых вы собираетесь терминировать.. со всеми ихними acl, qos и т.д. Это строительство неуправляемой сети на доступе только для одного сервиса. Вернее для двух, но деньги вы будете брать за один, а второй просто на халяву съест весь бандвитч ресурс вашей сети.

 

Share this post


Link to post
Share on other sites
в VLAN per User можно выдавать целую серую сеть по динамическому dhcp
Всё конечно зависит от размеров сети и сервисов в этой сети, но.. имхо в любом случае вот тут главная ошибка.

В чем ошибка, если это главное преимущество?

 

Да да, и получить пионернет аля корбинка только для одного сервиса.

Мне бы такой пионернет чтоб за 200 миллионов купили.

 

 

В билинге можно держать dhcp opt-82, через него же делать AAA со всеми пользовательскими настройками порта, в случае vlan per user конечно заводить только локально, только потом q and q накрывать и на границе сети выборочно эти вланы доставать через selective q and q

Зачем q-in-q если на узле у меня меаксимум 200-300 VLAN ?

 

Share this post


Link to post
Share on other sites
в VLAN per User можно выдавать целую серую сеть по динамическому dhcp
Всё конечно зависит от размеров сети и сервисов в этой сети, но.. имхо в любом случае вот тут главная ошибка.

В чем ошибка, если это главное преимущество?

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

Да уж.. только сейчас тех кто купил, думаю больше заботит как бы побольше чистой прибыли с этой сети собрать, а не пресс релизы выпускать сколько новых пользователей и какая скорость в локале. Поздно пить боржоми до следующей перезагрузки, есть ещё желающие покупать по 500 зелёных за пользователя?
В билинге можно держать dhcp opt-82, через него же делать AAA со всеми пользовательскими настройками порта, в случае vlan per user конечно заводить только локально, только потом q and q накрывать и на границе сети выборочно эти вланы доставать через selective q and q
Зачем q-in-q если на узле у меня меаксимум 200-300 VLAN ?

Я там выше специально написал "Всё конечно зависит от размеров сети и сервисов в этой сети"

Sonne, ваша схема рабочая, но не масштабируемая. Если сеть будет расти, то с вероятностью 90% надо будет переделывать, причём переделывать изменяя схему предоставления сервисов, а значит затрагивая пользователей, либо вам, либо тому кто её купит. Если сеть расти не будет то зачем она такая нужна? Давайте называть вещи своими именами, практически любая сеть на продажу это балансирование на грани работоспособности сети, а не балансирование между качеством и ценой.

Edited by Cr_net

Share this post


Link to post
Share on other sites
в VLAN per User можно выдавать целую серую сеть по динамическому dhcp
Всё конечно зависит от размеров сети и сервисов в этой сети, но.. имхо в любом случае вот тут главная ошибка.

В чем ошибка, если это главное преимущество?

Это не масштабируемо.

Не понимаю.

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

У меня на одном коммутаторе останется 2500 свободных вланов, а я ведь, страшно сказать, могу и два коммутатора поставить.

 

Вобще VLAN терминируется и превращается в L3 сущность. Размер L3 сети ограничивается размером таблицы маршрутизаторов и все.

Чем ближе к юзеру затерминируется VLAN, тем более масштабируема будет сеть.

Share this post


Link to post
Share on other sites
в VLAN per User можно выдавать целую серую сеть по динамическому dhcp
Всё конечно зависит от размеров сети и сервисов в этой сети, но.. имхо в любом случае вот тут главная ошибка.

В чем ошибка, если это главное преимущество?

Это не масштабируемо.

Не понимаю.

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

У меня на одном коммутаторе останется 2500 свободных вланов, а я ведь, страшно сказать, могу и два коммутатора поставить.

Вобще VLAN терминируется и превращается в L3 сущность. Размер L3 сети ограничивается размером таблицы маршрутизаторов и все.

Чем ближе к юзеру затерминируется VLAN, тем более масштабируема будет сеть.

Так ведь недавно выясняли, если терминировать на 3xxx каталистах, то 1024 L3 SVI, при условии 3200 уникастовых мак адресов и 3200 коннектед роутов в теоретическом максимуме.

Пусть возьмем 20% проникновение. Выдавая /29 предполагается думаю в среднем 2,5-3 устройства у пользователя с учётом воип девайсов не у всех и без учёта маков юзеровских СPE свитчей. Итого примерно 4 мака это 1200 при 20% проникновения и 100% работоспособности всех. Да, думаю на 1500 хат в посёлке где практически нет юриков и тд, запас примерно два года. Про терминировать ближе тоже согласен, только вот коммутаторы это CAR с дропами, чтобы прогарантировать полосу другим сервисам. Если хат больше то смысл упираться в L3 терминацию на свитчах для одного сервиса, когда можно получить запас в 8000 маков и получить унифицированое решение на дистрибьюции для всех сервисов и без заморочек для пользователя - пропишите маршруты в локалку и тд. При этом для транзитных влан на маках можно ещё и поэкономить. Вообщем унифицированных советов не бывает, всё как всегда зависит от задачи.

Share this post


Link to post
Share on other sites
Первая и главная причина использования NAT в схеме VLAN per User это возможность давать пользователю подсети. Выдавать такое количество

[skip]

Вторая причина - защита. NAT дает дополнительную степень защиты от внешнего вредного трафика...

...а также P2P и прочих скайпов!

 

/me hates NAT!!

 

Дайте пользователям в LAN 100 мбит и они сами побегут на внутренний DC++, человек ведь ищет где лучше.

Да, Joost, например. И Скайп. И TPB. Вы хотите лишить пользователей Интернета?

 

а если выдавать всем подряд белые, появится тема "как и чем зарезать торренты"

Как написала одна девушка, "убью и зарою. потом откопаю обратно и ещё раз убью!"

 

Зачем вы хотите лишить своих пользователе Интернета?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

В топике становится жарко :)

 

Если позволите, вернусь все-таки к своим вопросам.

 

1) "зачем вам выдавать серые ip юзерам если у вас vlan на юзера?"

 

Белых адресов столько нет, купить их никто не даст, провайдеры с BGP есть, но хотят дополнительно немало денег за его поддержку. Вот такая вот суровая реальность. Так что вариант остается только такой. Внешний трафик небольшой: попросту нет нормальных провайдеров\каналов. Так что вопрос "чем натить 100-200 мбит\с" в ближайшую пятилетку не встанет :) Как встанет - думаю такие граничные роутеры будут стоить уже максимум $1к. Так что основной упор - локалка.

 

2) "а зачем вам 802.1x если у вас vlan на юзера?"

 

Как я уже сказал, опыта в таких решениях нет и как обеспечить отключение пользователя от сервиса (локалка, Инет) не выдергивая кабеля из порта без использования какой-либо авторизации, я пока не представляю. ACL'ами или блэкхолами на L3 терминаторе? Но это при условии что IP адрес(а) абонента заранее известен(ны) и он их сменить никак не может.

 

3) "в VLAN per User можно выдавать целую серую сеть по динамическому dhcp"

 

Где можно про это прочитать? Может быть кто-то поделится описанием проектного решения "Vlan-per-user" в личку? Просто вопросов больше чем ответов... Каким образом DHCP сервер решает какой адрес дать юзеру? Как он знает с какого VLAN пришел запрос? Нужен ли для этого какой-то особый функционал со стороны свичей доступа или все это настраивается на ближайшем L3 терминаторе и завит только от его функционала?

 

4) "Терминировать их можно на 3550...3760 железках что позволит wirespeed для локалки"

 

Ок, здесь понятно. Терминировать юзерские VLAN на ближайшем свиче агрегации, дальше все пойдет на L3.

 

5) "Заводить VLAN нужно только локально, вниз можно динамическим протоколом, на циске ручками или простейшим скриптом. Если в биллинге есть возможность держать поле VID для юзера, то все модно автоматизировать."

 

Заводить локалько на терминаторе? Ок, по GVRP все "вниз" на доступ передалось. А порт юзера как в этот VLAN поместить - скриптом\ручками?

Просто я так понял если использовать DynamicVLAN Assignment через 802.1x то порт в VLAN добавится автоматически. Передастся ли он "наверх" на дистрибьюцию - это надо проверять.

 

6) Все таки вопрос про терминацию: на L3 терминаторе юзерские VLAN'ы создаются заранее, L3 терминируются нужными /30 /29 и т.п. подсетями. Так?

 

7) Если п.6 "не так", и адреса выдаются юзерам из общего пула, то как обеспечивается защита выданного по DHCP серого адреса. Напомню, Allied Telesyn AT-8524 никаких DHCP Snooping или DHCP Option82 не умеет.

 

7) Если п.6 "так", то нужна ли дополнительная авторизация на Инет? Или если принять, что адрес=юзер всегда 100% гарантированное равенство, то юзера можно одназночно определять по выдаваемому адресу, и резать его только на граничном маршрутизаторе, и не использовать отдельной авторизации для Инета?

 

8) По поводу масштабируемости\немасштабируемости. Текущаяя систуация такова, что денег на жирный BRAS в центре которая сможет прожевать 1-2-5 гбит\с локалки никто не даст. Максимум - замена магистральных свичей на что-то другое с нужным функционалом. В данной ситуации, других вариантов нет. Необходимо обеспечить нормальные скорости в локалке, её контроль на уровне железа, чтобы юзер который её не оплатил отключался удаленно. Сейчас все это делается на центральном BRAS'е добавлением\удалением правил на локалку\инет, но скорости в локалке нормальной нет. Городить зверинец из PC - не хочется. Пределы масштабируемости при существующей плотности застройки таковы, что на отдельном узле агрегации собирается в перспективе порядка 600-1000 юзерских портов. Думаю, что на такие цифры 35хх каталистов должно хватить, или нет?

 

Заранее спасибо за ответы.

Edited by Sergey_Taurus

Share this post


Link to post
Share on other sites

Кстати, о денежках.

 

1) Если оставлять вариант c централизованным BRAS'ом (или кластером из BRAS'ов, неважно какого вендора), то BRAS который сможет прожевать 1-2-5 гигабит локалки, как стало понятно из соседней темы, будет стоить от $20к. Разумно встает вопрос: есть ли другой вариант?

А вы считали сколько получится денег за 6500 или 2x3750G + кучка 3560G?

 

PS. и еще, забейте уже на ваш 802.1x если не хотите кучу проблем с юзерами (настройки в разных ОСях, потенциальные проблемы с SOHO-рутерами и всякими там игровыми приставками).

Share this post


Link to post
Share on other sites
А вы считали сколько получится денег за 6500 или 2x3750G + кучка 3560G?
Очень примерно столько же, как не больше.

 

Но, дело в том что сейчас на телесинах криво работает даже схема с централизованным BRAS'ом.

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

 

Т.е. есть 3 варианта:

1) менять магистральное оборудование + брать нормальный BRAS

2) менять магистральное оборудование, но реализовывать схему без туннелей (как максимум - с L3 туннелями для авторизации в Инет)

3) все таки пытаться на телесинах реализовывать ту же схему без туннелей (как максимум - с L3 туннелями для авторизации в Инет)

 

 

PS. и еще, забейте уже на ваш 802.1x если не хотите кучу проблем с юзерами (настройки в разных ОСях, потенциальные проблемы с SOHO-рутерами и всякими там игровыми приставками).
Да, тоже подумал что идея неочень хорошая.

 

Т.е. пока сам себе придумал такой вариант (пока конкретного вендора не рассматриваем):

1) делаем VLAN на пользователя: предварительно нарезаем руками на доступе VLAN на каждый порт, передаем через 802.1q транки на дистрибьюцию, там же их L3 терминируем на руками созданных VLAN'ах и /30 (или другого размера) интерфейсах.

2) Делаем из каждого свича на дистрибьюции DHCP relay, вставляющий в Option82 то что надо для однозначной идентификации пользователя (например VID), на стороне пользователя делаем настройки DHCP, сервер обрабатывает запрос с учетом полученных в Option 82 параметров и выдает юзеру статический серый IP из /30 блока (или из блока побольше). Одновременно с адресом юзеру выдется дефолт, некоторые статические маршруты и т.п.

3) Юзерам не оплатившим доступ, на терминации либо ACL'ами либо блэкхолами, доступ к локалке закрывается. Если все таки доступ закрывать ACL'ами, то тарифы "только Инет" можно будет оставить.

4) Для Инета организовать какой-нибудь L3 PPTP концентратор (не особо жирную железку или PC), после авторизации на котором юзер может попасть в Инет. Все таки Инет штука платная и во избежание его безконтрольного расхода (юзер включил комп и все) и возможности включить\выключить со стороны пользователя, дополнительная авторизация я думаю необходима.

 

Я все правильно технически понял? Так делается доступ по схеме "VLAN на пользователя"? Или что-то не так?

 

Заранее спасибо за ответы.

Edited by Sergey_Taurus

Share this post


Link to post
Share on other sites

Если

нарезаем руками на доступе VLAN на каждый порт
и
L3 терминируем на руками созданных VLAN'ах и /29 (сетка на все девайсы юзера)
то и DHCP релей млжно сделать 1 на брасе где терминация вланов.

 

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

 

Share this post


Link to post
Share on other sites
4) Для Инета организовать какой-нибудь L3 PPTP концентратор (не особо жирную железку или PC), после авторизации на котором юзер может попасть в Инет. Все таки Инет штука платная и во избежание его безконтрольного расхода (юзер включил комп и все) и возможности включить\выключить со стороны пользователя, дополнительная авторизация я думаю необходима.

 

Я все правильно технически понял? Так делается доступ по схеме "VLAN на пользователя"? Или что-то не так?

 

Заранее спасибо за ответы.

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

Share this post


Link to post
Share on other sites
С интересом читаю ветку. У меня возник вопрос приверженцам присвоения юзерам серых адресов - а если появится такой абонент, которому кровь из носа нужер реальный адрес? В вашей схеме есть возможность удовлетворить потребности такой группы абонентов?

В любое мгновение любому желающему дается IP адрес через статический NAT, за отдельную денежку естественно.

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

Share this post


Link to post
Share on other sites

Sonne - такой метод не решает проблемы нерабочести многих приложений.

Особенно если коннект инициируется вашим клиентом, и клиент отправляет свой адрес в информации "туда", после чего - коннект снаружи идет на этот адрес.

 

Простейший пример (но этот пример решен, и еще пара немногих, хотя и не совсем ровно) - ftp. Если адрес серый, то клиент вышлет неверный(серый) адрес для инициации data канала в active режиме. Соответственно ничего работать не будет. Т.е. решение половинное.

Share this post


Link to post
Share on other sites
Я все правильно технически понял? Так делается доступ по схеме "VLAN на пользователя"? Или что-то не так?

Заранее спасибо за ответы.

Сергей, у вас слишком сложно все получается.

Сколько у вас планируется подключений? Если 100 штук в месяц, то в день это 3-5 пользователей, которые один админ прекрасно настроит ручками.

Даже 10 пользователей он настроит и не поморщится.

 

На доступе прописываем VLAN и порт это все равно придется делать вручную, ибо монтажники скажут куда воткнули, на L3 создаем IP интерфейс с заданной подсетью,

на DHCP эту подсеть помещаем в типовой конфиг, вносим данные в биллинг. DHCP сервер я бы вынес на отдельную машину и заводил ее в VLAN, заодно будет свой miniСОРМ интерфейс для борьбы с безобразниками. После того как это сделано никакой авторизации и аутентификации не нужно.

 

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

 

Если же планируется включать сотни абонентов и обслуживать тысячи, то стоит сразу подуматьб о брасе. 10-20$ на абонента это недорого.

 

Share this post


Link to post
Share on other sites
Сергей, у вас слишком сложно все получается.

Сколько у вас планируется подключений? Если 100 штук в месяц, то в день это 3-5 пользователей, которые один админ прекрасно настроит ручками.

Даже 10 пользователей он настроит и не поморщится.

 

На доступе прописываем VLAN и порт это все равно придется делать вручную, ибо монтажники скажут куда воткнули, на L3 создаем IP интерфейс с заданной подсетью,

на DHCP эту подсеть помещаем в типовой конфиг, вносим данные в биллинг. DHCP сервер я бы вынес на отдельную машину и заводил ее в VLAN, заодно будет свой miniСОРМ интерфейс для борьбы с безобразниками. После того как это сделано никакой авторизации и аутентификации не нужно.

 

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

 

Если же планируется включать сотни абонентов и обслуживать тысячи, то стоит сразу подуматьб о брасе. 10-20$ на абонента это недорого.

Подключений не много, 2-3 в день. Пока.

Т.е. руками настроить проблемы нет.

 

Подытожим:

 

1) Выделенного BRAS'а нет. Никаких PPPoE туннелей нет. Юзер делает одну единственную настройку - получить IP адрес автоматически. На доступе ничего кроме 802.1q в сторону агрегации не используется (никаких DHCP Snooping и Option 82). Каждый юзер в своем влане, который терминируется в L3 на первом же свиче агрегации в /30 (или /29). Свичи на агрегации работают в режиме DHCP Relay, вставляют в запросы Option 82 (в котором указан VID абонента) и передают запрос на отдельно стоящий центральный DHCP сервер, который выдает юзеру определенный серый IP адрес из диапазона /30 (/29 и т.д.) в зависимости от параметров переданных в Option 82. Так?

 

2) Локалка вкл\выкл ACL'ами на агрегации. Гарантией что ACL отключит кого надо и отключенный юзер не сможет взять чужой адрес, является сама по себе схема VLAN на пользователя и терминация VLAN'ов интерфейсами с /30 подсетями. Так?

 

3) Делать отдельную авторизацию на Инет лучше не стоит. Сейчас в принципе через личный кабинет абонента у нас уже реализована возможность включить\выключить инет. Эффектом являестся изменение правил на граничном Инет роутере. Так что для особо параноидальных пользователей возможность включить\выключить Интернет уже есть.

 

Теперь я все правильно понял?

Edited by Sergey_Taurus

Share this post


Link to post
Share on other sites

nuclearcat

С натом ip-ip, во всяком случае во фре, все замечательно работает и коннектится в обе стороны.

 

1 Option 82 ненужно, в запросе от релея к серверу передается ip интерфейс пулучивший первоначальный запрос, а он привязан к влану.

 

2 да

 

3 если бордер комп то стоит

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