[vIv]

+ CVLAN надо добавить, причём VLAN пространство должно быть своёё на каждой плате. См. как сделаны ZTE ZXUAS

CVLAN - это само сабой. У каждого интерфейса свое пространство. ZTE ZXUAS - большая железка, полстойки займет, а если в той точке нужно до 8 1G интерфейсов собрать, то это как из пушки по воробьям. Нужно компактное решение 1-2U, способное переварить 10G. И сервисные платы у этого ZXUAS стоят наверно $20К как минимум. Дорого.

Какой ты оптимист! там под две сотни за карточку 8-( Плюс не забываем, это ZTE - ещё софт и лицензии.

Правда есть "как-бы двухслотовый" (2 + 2 слота горизонтально + БП) вариант, юнитов в 5-6, но они ОЧЕНЬ не хотят его продавать. Но бОльшая часть функций там таки на линейных картах. МОСК только рулит общим состоянием, политиками сервисов и динамической маршрутизацией для всего шасси.

 

// извинения за ачипятки, ноутбук, простите

[nnm]

$10К за шасси 12слотовое шасси с роутпроцессором и 2х10G аплинками и по $5K за 2х1G даунлинк модули.

Вот это выглядит как ненаучная фантастика... :)

[Saper]

Скорее всего придется менять все магистральные L3 свичи, делать пока VLAN на пользователя с DHCP и /29 сетками и c ACL на агрегации. Инет без авторизации, но с возможностью для каждого абонента его вкл\выкл через личный кабинет, доступ в Инет будем резать на граничной циске.

А коммутаторы доступа у вас какие ? Насколько я понял вы с них можете получить только влан, но не Option82. Хотя это и не важно вобщем то, главное что теоретически этой информации достаточно для идентификации абонента. Важнее другое - вы уже нашли решения DHCP которое может выдать то что нужно исходя из VID и Relay ? По моему таких просто нет.

Изменено 18 января, 2009 пользователем Saper

[Bambuk]

Ну почему же нет. http://dhcpd-j.org/ допиливается напильником до нужной кондиции :)

[Sergey_Taurus]

Скорее всего придется менять все магистральные L3 свичи, делать пока VLAN на пользователя с DHCP и /29 сетками и c ACL на агрегации. Инет без авторизации, но с возможностью для каждого абонента его вкл\выкл через личный кабинет, доступ в Инет будем резать на граничной циске.

А коммутаторы доступа у вас какие ? Насколько я понял вы с них можете получить только влан, но не Option82. Хотя это и не важно вобщем то, главное что теоретически этой информации достаточно для идентификации абонента. Важнее другое - вы уже нашли решения DHCP которое может выдать то что нужно исходя из VID и Relay ? По моему таких просто нет.

Как выясилось в этом топике, если VLAN-интерфейсы терминировать на L3 свиче, то DHCP можно настроить выдавать адреса из пула в зависимости от оригинальной IP-подсети, из которой пришел первоначальный запрос. Таким образом, не то что Option 82, даже VID и Relay ID знать не обязательно.

 

[Saper]

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

 

1) DHCP сервер с жирным конфигом из тысяч подсетей

2) Куча интерфейсов на L3, одном или нескольких, которые надо править, добавлять/удалять и держать постоянно актуальными.

3) Выход из строя или замена коммутатора доступа ещё не такая большая работа в плане переконфигурации, а вот если что то навернётся на L3, даже если их будет несколько и вы их будете ставить ближе к абоненту - это уже будет авария надолго.

 

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

[jurs]

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

 

1) DHCP сервер с жирным конфигом из тысяч подсетей

2) Куча интерфейсов на L3, одном или нескольких, которые надо править, добавлять/удалять и держать постоянно актуальными.

3) Выход из строя или замена коммутатора доступа ещё не такая большая работа в плане переконфигурации, а вот если что то навернётся на L3, даже если их будет несколько и вы их будете ставить ближе к абоненту - это уже будет авария надолго.

 

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

DHCP-сервера можно ставить разные и на разных L3 писать dhcp-relay разный в нужных комбинациях. Да хоть даже на разные вланы :). Кроме того, к примеру ISC DHCPD умеет файловер.

А в схеме с брасом большим если он накроется, то тоже будет полный превед.

Конфиги со свичей сливать ежедневно, в запасе держать свитч. Конфиг залить, свич вкрутить - не так уж и долго выходит.

[nnm]

Чего-то я сомневаюсь в существовании относительно дешевых коммутаторов, на которых можно терминировать много C-VLAN. :(

[cmhungry]

Чего-то я сомневаюсь в существовании относительно дешевых коммутаторов, на которых можно терминировать много C-VLAN. :(

3550-48 на наге

 

[nnm]

А есть понимание сколько C-VLAN можно затерминировать на 3550, чтобы не напороться на ограничения TCAM?

[Sergey_Taurus]

А есть понимание сколько C-VLAN можно затерминировать на 3550, чтобы не напороться на ограничения TCAM?

Тут в соседней теме подкинули ссылку

[RifleMan]

тогда скорее стоит подумать о распределенных BRASах, кстати из последних вестей с фронта Cisco тоже подумает об ентом.

И тогда на агрегации ставить одну коробку, которая и BRAS и MPLS PE и всё всё всё в одном флаконе...

А железка получается что то типа Redback SE-400 ;))

 

 

[UglyAdmin]

Сергей, Вы выбираете не между PPPoE и "вилан на юзера", а между централизованным и распределённым терминированием юзеров.

Распределённое терминирование PPPoE тоже может быть и может быть дешевым, для этого достаточно терминировать на писюках...

[nessat]

Распределённое терминирование PPPoE тоже может быть и может быть дешевым, для этого достаточно терминировать на писюках...

Можно поинтересоваться как в текущем моменте обстоят дела у MPD(pppoe) с проблемами MTU?

 

Пролетали то тут то там всякие сообщения о невнятных проблемах, когда толи венда ставит не то MTU, которое хочет MPD... как-то так. Ну вобщем смысл сводился к тому, что возникают "подземные стуки", типа "сайты смотрятся, ФТП не работает, или еле работает", или "включаю винамп - скорость скачивания падает/растёт". И тому подобные.

 

А также нужно прикинуть что будет, когда через PCюк, через его сетевуху пойдёт ВЕСЬ трафик сети. Ну даже 2, 3 сетевухи. И по пропускной способности, и по возможности PCка прожевать этот трафик (прерывания, роутинг, и плюс его надо из/в pppoe).

Взять всего 100 или немного более юзеров, и если стремиться дать около 10 Мбит на клиента (100Мбит на дом, делим на клиентов 10 -> 10Мбит на нос, клиентов больше -> "дадим" ещё меньше), они уже могут нагенерить 1Гбит. А если 200-300 юзеров - то вот они ваши 2-3Гбита, то есть 2-3 Гбитных сетевухи в PCке.

Я конечно взял теоретический максимум, но 50-70% от него может быть вполне.

 

Насколько бюджетным будет PCюк на 100 юзеров (т.е. способный переварить 1Гбит/с)? Насколько бюджетным будет на 300?

Имейте ввиду, что PCки вам понадобятся не абыкакой самосбор, а имеющие сертификат ССС на "передачу пакетов" (как-то так, ну роутинг короче). Самый дешёвый, на Celeron'чике, я так понимаю около 10 тыр стоит.

[Sergey_Taurus]

Сергей, Вы выбираете не между PPPoE и "вилан на юзера", а между централизованным и распределённым терминированием юзеров.

Распределённое терминирование PPPoE тоже может быть и может быть дешевым, для этого достаточно терминировать на писюках...

Вот чего-чего, а вот этого бы не хотелось...

Геморроя - не меньше чем от VLAN на пользователя, если не больше. Да и нет места в уже смонтированных шкафах под писюки.

 

Выбираю да, между централизованной и распределенной терминацией. Распределенная пока видится не иначе как VLAN на пользователя.

 

Пока заставил задуматься этот вопрос. По поводу размера TCAM на 3560 вопрос отпадает - не будет там столько MAC'ов, даже в самом клиническом случае. Главный вопрос: (возьмем текущую потребность*2) не станет ли плохо каталисту C3560-24TS-S от 600 SVI с подключнным к ним общим ACL'ом в около 600 правил? В мануалах написано, что все ACL hardware processed, если влезают в TCAM. Так ли?

 

[masterovoj]

Распределённое терминирование PPPoE тоже может быть и может быть дешевым, для этого достаточно терминировать на писюках

Геморроя - не меньше чем от VLAN на пользователя, если не больше.

А какой извините "геморрой" с "VLAN на пользователя"?

 

Вот насчёт pppoe "геморрой" уже указан:

как ... обстоят дела у MPD(pppoe) с проблемами MTU?

...

Насколько бюджетным будет PCюк на 100 юзеров (т.е. способный переварить 1Гбит/с)? Насколько бюджетным будет на 300?

[Sergey_Taurus]

Распределённое терминирование PPPoE тоже может быть и может быть дешевым, для этого достаточно терминировать на писюках

Геморроя - не меньше чем от VLAN на пользователя, если не больше.

А какой извините "геморрой" с "VLAN на пользователя"?

По сравнению с PPPoE терминаторами на "писюках" - минимальный. Только на первоначальном этапе настройки свичей доступа и агрегации, а также конфига DHCP сервера. В требуемом варианте, поддерживать несколько десятков(!) "писюков" на фре\линуксе для PPPoE агрегации - мне кажется куда более хлопотнее. Да и как уже было озвучено - непонятно, какой кинфигруации должны быть эти сервера чтобы переварить хотя бы 1-2 гбит\с локалки, куда их ставить (при отсутствии наличия свободных 3-4U в шкафах) и сколько они будут стоить.

 

PS: Вопрос как себя ведет С3560 c кучей SVI и навешанным на них внушительным общим ACL, в силе...

Изменено 20 января, 2009 пользователем Sergey_Taurus

[jab]

В требуемом варианте, поддерживать несколько десятков(!) "писюков" на фре\линуксе для PPPoE агрегации - мне кажется куда более хлопотнее. Да и как уже было озвучено - непонятно, какой кинфигруации должны быть эти сервера чтобы переварить хотя бы 1-2 гбит\с локалки, куда их ставить (при отсутствии наличия свободных 3-4U в шкафах) и сколько они будут стоить.

Чего там их поддерживать ? Поставил в стойку, через два года проапгрейдил. Всего делов. 2U писюк стоит 800$. Расчетный показатель - один писюк на 1000 юзеров.

Итого, на 10000 юзеров, 8000$ на писюки + стойка 30U, + L2 GE switch, плюс пара UPS + 2 кондиционера.

[masterovoj]

какой кинфигруации должны быть эти сервера чтобы переварить хотя бы 1-2 гбит\с локалки

2U писюк стоит 800$.

Не поделитесь ли ссылочкой на указанный писюк? Одна тока сетевуха типа интел 1000ПРО стоит под 300$...

Ессно такой, чтобы узел/сеть можно быть сдать РСНу, т.е., судя по всему, сервак нужен имеющий ССС.

 

Расчетный показатель - один писюк на 1000 юзеров.

Имеется ввиду "1000 активных юзеров" или "всего 1000 юзеров, их которых активных... сколько-то там".

 

Какая общая пропускная способность на эти 1000 юзеров предполагается? То есть сколько по вашему он должен перемолотить, обеспечивая норм работу 1000 юзеров.

Имеем ввиду, что юзера активно используют DC/torrent/emule -подобный софт в (по идее бесплатной) локалке.

[UglyAdmin]

PS: Вопрос как себя ведет С3560 c кучей SVI и навешанным на них внушительным общим ACL, в силе...

Зачем "общий" ACL? Нет, персональных тоже не надо, но ACL должно быть как минимум два - "доступ разрешен" и "доступ запрещен". В этом случае ACL будет ну никак не "внушительный", а очень даже компактным.

А вот с шейпингами/полисингами в этой схеме жопа - не умеют их свитчи нормально. Стало быть локалка будет у всех 100 мегабит, либо задаваться скоростью порта, что тоже даёт всего 2 варианта.

[mikevlz]

mpd - один писюк на активную тыщу.

Со скоростью порта - 5 вариантов скоростей:

0Мбит/с

10М/полудуплекс

10М/полный дуплекс

100М/полудуплекс

100М/полный дуплекс.

 

[masterovoj]

mpd - один писюк на активную тыщу

Проблем нету? Ну там, всякие странности с MTU, которые нужно на вендах руками прописывать и т.п.? Поставил MPD и забыл?

[jab]

Одна тока сетевуха типа интел 1000ПРО стоит под 300$...

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

 

Ессно такой, чтобы узел/сеть можно быть сдать РСНу, т.е., судя по всему, сервак нужен имеющий ССС.

Чтобы сдать сеть, достаточно иметь _один_ сервак с ССС. Я сдавал с Inpro Archer два раза.

 

Какая общая пропускная способность на эти 1000 юзеров предполагается? То есть сколько по вашему он должен перемолотить, обеспечивая норм работу 1000 юзеров.

Имеем ввиду, что юзера активно используют DC/torrent/emule -подобный софт в (по идее бесплатной) локалке.

Пропускная способность - гигабит. 1000 юзеров - хоть списочных, хоть активных, это уже от конкретики зависит.

 

mpd - один писюк на активную тыщу

Проблем нету? Ну там, всякие странности с MTU, которые нужно на вендах руками прописывать и т.п.? Поставил MPD и забыл?

last pid: 63112; load averages: 1.44, 1.38, 1.33 up 397+01:53:33 15:13:51

24 processes: 2 running, 22 sleeping

CPU states: 1.3% user, 0.0% nice, 54.4% system, 3.4% interrupt, 40.9% idle

Mem: 50M Active, 6868K Inact, 77M Wired, 44M Buf, 363M Free

Swap:

 

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND

36419 root 3 20 0 42356K 32784K kserel 1 572.5H 0.00% mpd4

800 root 1 96 0 5236K 4816K select 1 820:56 0.00% ospfd

794 root 1 96 0 4140K 3748K select 0 431:56 0.00% zebra

961 root 1 96 0 10724K 10468K select 1 219:28 0.00% bsnmpd

849 root 1 96 0 1360K 1028K select 0 78:47 0.00% syslogd

 

[Sergey_Taurus]

PS: Вопрос как себя ведет С3560 c кучей SVI и навешанным на них внушительным общим ACL, в силе...

Зачем "общий" ACL? Нет, персональных тоже не надо, но ACL должно быть как минимум два - "доступ разрешен" и "доступ запрещен". В этом случае ACL будет ну никак не "внушительный", а очень даже компактным.

Этот момент никак не пойму... Как я себе это представляю, имеем допустим 500 SVI, в такой примерной конфигурации:

 

int vlan 1xxx

ip address 10.1.x.y 255.255.255.252

ip access-group 101 in

 

Router ACL 101 - общий акцесс, в котором описана вся логика. Общий, потому что так его проще на билинге генерить и через TFTP+SNMP изменять.

 

Листинг ACL 101 примерно такой:

 

access-list 101 permit ip any host X.X.X.X - пропустить всех в личный кабинет

access-list 101 permti ip any 10.100.0.0 0.0.0.255 - пропустить всех на подсеть с бесплатными и доступными всегда локальными серверами

access-list 101 permit ip <ip1> 10.0.0.0 0.255.255.255 - пропустить юзера с <ip1> в локалку 10.0.0.0/8

...

access-list 101 permit ip <ipN> 10.0.0.0 0.255.255.255 - пропустить юзера с <ipN> в локалку 10.0.0.0/8

access-list 101 deny ip any 10.0.0.0 0.255.255.255 - запретить локалку 10.0.0.0/8 всем остальным, кто её не оплатил

access-list 101 permit ip any any - пропустить всех в Инет (доступ в Инет контроллируется на граничном маршрутизаторе)

 

Вот такой вот у меня получается акцесс. Один, общий для всех SVI. По объему - в теоретическом максимуме количество строк стремится к количеству SVI + 3 штуки.

 

Как "скомпилировать" этот большой ACL в два ультра-компактных - ума не приложу. Ткните носом, плз. Заранее спасибо.

 

А вот с шейпингами/полисингами в этой схеме жопа - не умеют их свитчи нормально. Стало быть локалка будет у всех 100 мегабит, либо задаваться скоростью порта, что тоже даёт всего 2 варианта.

Это не сильно надо. Максимум что надо - делать QoS для того чтобы трафик локалки на магистралях и аплинках не забивал Инет и голос.

 

[UglyAdmin]

Листинг ACL 101 примерно такой:

 

access-list 101 permit ip any host X.X.X.X - пропустить всех в личный кабинет

access-list 101 permti ip any 10.100.0.0 0.0.0.255 - пропустить всех на подсеть с бесплатными и доступными всегда локальными серверами

access-list 101 permit ip <ip1> 10.0.0.0 0.255.255.255 - пропустить юзера с <ip1> в локалку 10.0.0.0/8

...

access-list 101 permit ip <ipN> 10.0.0.0 0.255.255.255 - пропустить юзера с <ipN> в локалку 10.0.0.0/8

access-list 101 deny ip any 10.0.0.0 0.255.255.255 - запретить локалку 10.0.0.0/8 всем остальным, кто её не оплатил

access-list 101 permit ip any any - пропустить всех в Инет (доступ в Инет контроллируется на граничном маршрутизаторе)

Зачем общий для ВСЕХ SVI, если у юзеров персональные интерфейсы?

Если доступ разрешен, то ставите на SVI юзеру ACL "доступ разрешен". Если запрещен - соответственно.

Иначе коммутатор будет нехило вставать раком при перегенерации этого мега-ACL.

В случае с локалкой потребуется 3 ACL - "запрещено всё, кроме кабинета", "запрещена локалка", "разрешено всё".

IP контролируются самим механизмом "вилан на юзера", их не надо перечислять.

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