[Reanimator++]

В голове вертится такая схема сети -

Юзеры подключаются в свичи с изоляцией портов (Port Based VLAN) - планирую PS2216.

Изолированные друг от друга таким образом они не могут обмениваться данными даже на L2. Только с аплинком.

Все юзеры сводятся таким образом в один гиговый аплинк, где ставится PPPoE концентратор.

Концентратор хочу сделать на писюке.

 

Схема здесь уже обсуждалась - преимущества очевидны:

- полный контроль трафика в сети

- защищенность от большинства нездоровых явлений типа второго PPPoE концентратора в сети и т.п.

- дешевое оборудование.

 

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

 

1. Подскажите где толково почитать о том как работает Port Based Vlan.

Тут писали что схема легко масштабируется - в абонентский порт свича (№1) втыкаем еще один такой же свич (№2) аплинком и при этом юзеры все-равно друг друга не увидят.

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

 

2. Какое железо/софт выбрать для PPPoE концентратора?

Юзеров в этом сегменте будет порядка 100 (потом ожидается рост до 300-500). Думаю что 1 Гигабита им хватит (при условии что локальный трафик не тарифицируется).

Какой производительности писюк должен быть чтобы вытянуть гигабит PPPoE?

Какой софт использовать? (с FreeBSD/Linux дела не имел, потому спрашиваю что лучше для такой задачи)

[Kirya]

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

[Reanimator++]

Пока не тарифицируется...

Да и как еще можно контролировать трафик внутри используя неуправляемое оборудование?

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

А какие есть у схемы недостатки? Уязвимости?

[Kirya]

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

Только для этого тебе придется выставить двухядерник с pci-e/pci-x сетевкой, в случае гигабита, и делать довольно тонкую настройку mpd5/freebsd или kernel level/linux-а. Причем я еще не считаю процессорные затраты на обработку фильтров и биллинг инета.

 

А ради чего ?

Перекрыть самбу, чтоб якобы вирусы не плодились, загнав народ в DC ? Сетка слишком маленькая и DC будет пустой. FTP народ поднимать не будет из-за лени. Да и последние вирусы, которые напрягают реально больше всё в arp спуфинг уходят, так что тут схема с port vlan не спасет.

Вообщем я не вижу смысла геморроится.

Изменено 15 ноября, 2007 пользователем Kirya

[Reanimator++]

Задумался. Обработка PPPoE требует приличных процессорных затрат.

Можно конечно просто поверх схемы пустить TCP/IP и настроить маршрутизацию на сервере...

Но PPPoE как способ авторизации мне больше нравится...

Кстати проблем с arp в этом случае не должно быть... Т.к. по L2 только PPPoE будет работать, а дальше уже только маршрутизируемый на сервере TCP/IP. Т.е. arp не участвует...

 

А 400 Мбит PPPoE (в пике нагрузки) одноядерный РС с обычной гигабитной сетевой сможет терминировать? (пока чисто топологически больше не может получиться...)

[dIMbI4]

роутить немодно !!!!!!

[Kirya]

Маршрутизатор-то работает на L3.

И именно его arp таблицу будут забивать флудом вирусы.

Дальше начнет отваливаться маршрутизация...

 

2*400мбит (ибо сеть работает в full duplex, а PCI-нет) - это почти предел передачи шины PCI. Т.е одноядерник при "тонкой" настройке это конечно прожует, но вот что там по пути отвалится может, я прогнозировать не могу.

Изменено 15 ноября, 2007 пользователем Kirya

[Reanimator++]

А если зафильтровать на интерфейсе с пользователями все кроме PPPoE пакетиков?...

 

Т.е. в принципе получается схема жизнеспособна, проблемы могут возникнуть только при большой нагрузке. А раз уж "Сетка слишком маленькая и DC будет пустой", то откуда возьмутся мегабиты.

 

Да и делают же как-то люди.. вот Эр-телеком у нас - десятки тысяч абонентов и PPPoE...

 

// пошел читать маны по FreeBSD

[Kirya]

Для работы pppoe все равно нужны arp запросы. :)

[Reanimator++]

Чето я недопонимаю... В каком месте они там нужны?

http://ru.wikipedia.org/wiki/PPPoE

Там все на уровне MAC-адресов... И чето я не припомню arp-запросов когда сниффером слушал процесс соединения PPPoE...

[deep_admin]

схема более чем жизнеспособная, пппое в кернел-моде имеет network-speed, то есть практически без оверхеда

кстати такая схема легко масштабируется, можно поставить 2,3,N концентраторов которые на автомате будут балансировать пппое-подключения

[Reanimator++]

deep_admin, спасибо. Т.е. с масштабированием проблем тоже не будет.

 

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

[SergeiK]

Да можно, какие сложности.

Portbased vlan-ы работают в пределах одного свича, поэтому что там дальше стоит каждый конкретный свич не волнует.

Соответсвенно, далее, вы строите дерево этих свичей, и все.

[Reanimator++]

SergeiK

Сложности только в том что я недопонимаю как оно будет работать в дереве :)

то что каждому свичу пофиг на остальных это понятно.

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

Что сделает верхний свич? Отбросит пакет? или отправит обратно в аплинк нижестоящему свичу? и почему...

[Мартен]

такой ситуации в норме возникать не должно, т.к. если езернет-кадр шел с порта А свитча 1 на порт Б свитча 1, то за пределы свитча 1 он выйти не должен. Т.е. в аплинк он не попадет. А т.к. на считче 1 порт-изоляция, то кадр дропается.

Ситуация, когда кадр попадает на аплинк, возможна, если арп-таблица свитча 1 пустая(или переполнена). тогда кадр с порта А будет разослан броадкастом по всем доступным портам (в данном случае на аплинк). Но только 1 штука, т.к. следующий кадр будет отправлен с порта А на порт Б напрямую, не выходя за пределы свитча 1, ну и дропнется порт-изоляцией. а вот если арп-таблица свитча 1 переполнена каким-либо червем|хацкиром, то толку от порт-изоляции на данном свитче получается 0.

все вышеизложенное имхо, т.к. прошивки свитчам писал не я :)

[Алексей Андриянов]

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

[Солнечный КОТ]

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

Чво-чво-чво?

[Алексей Андриянов]

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

Чво-чво-чво?

CCENT/CCNA ICND1 Official Exam Certification Guide, Second Edition

Cisco Press | 641 blz. | Wendell Odom

ISBN: 9781587201820

 

страницы 175-176, поиск по фразе:

switch never forwards a frame outh the same interface on which it arrived

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

[zoro]

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

даже при широковещательном запросе свичь отсылает копии во все порты за исключением порта источника...

[Reanimator++]

Спасибо всем, разжевали.

 

Мартен, имхо даже переполнение таблицы маков свича не может привести к отправке пакета непосредственно с порта А на порт Б, т.к. на это стоит ограничение в порт базед влан (оно просто ограничивает возможность коммутации между портами).

В общем все ОК.

 

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

(отмечу сразу что всякого вещалова и т.п. мультикаста у меня не будет 100%).

[Reanimator++]

кстати, не могу найти дешевый свич умеющий Port based vlan и имеющий хотя бы один гигабитный порт...

[Nag]

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

1. Как между собой играть-то люди будут? Они же не увидят соседей. ;-)

2. Юрики от таких виланов будут бежать как черт от ладана.

 

А на кой черт такие сложности, когда уже коммутаторы Л3 в цене так упали, что впору на дома ставить?

[Reanimator++]

1. по бродкасту чтоли? )) один другому ип-ку свою скажет и будут играть в контрстрайк скока влезет. ))

 

2. а для юриков PPPoE недостаточно круто чтоли? ) Чем оно ущербно для них собсно? (реальный ip можно выдать, что еще может быть надо? )

 

3. L3 стоят 3$ за порт? )

[Kirya]

2. а для юриков PPPoE недостаточно круто чтоли? ) Чем оно ущербно для них собсно? (реальный ip можно выдать, что еще может быть надо? )

Спасиб. Посмешил. :)

Ваши конкуренты будут вам аплодировать стоя.

Изменено 18 ноября, 2007 пользователем Kirya

[Kirya]

А на кой черт такие сложности, когда уже коммутаторы Л3 в цене так упали, что впору на дома ставить?

Например ? :)