Изоляция абонентов, оцените идею

[Sergey_Taurus]

Здравствуйте.

 

Наша копания приступает к строительству домовой сети городского масштаба. Системный интегратор, у которого мы уже приобрели оборудование предлагает вариант проекта, суть которого сводится к следующему:

1) В качестве абоненского коммутатора на 1-3 подъезда установлены AlliedTelesyn AT-8024. В целях исключения взаимодействия между абонентами (в силу ряда причин и условий) на AT-8024 включена изоляция портов, которая самим производителем называется MultipleVLAN.

2) В качестве коммутаторов узлов установлены AT-8824, на которые сходятся аплинки со всех абонентских коммутаторов района. В целях исключения взаимодействия абонентов разных AT-8024 через аплинк-порт между собой, каждый аплинк от AT-8024 на узле AT-8824 запихнут в отдельный VLAN.

 

Вроде цель достигнута. Но! Как только на VLAN'ы AT-8824 производится навешивание ИП-адресов, коммутатор самостоятельно строит таблицу маршрутизации и преспокойно пробрасывает пакеты из одного VLAN в другой...

 

Системный интегратор предложил фильтровать через hwfilter пакеты и пускать их только в подсеть на центральном узле, по следующему алгоритму:

 

create class=19 ipsa=10.19.0.0/16

create class=20 ipsa=10.20.0.0/16

create class=99 ipda=10.99.0.0/16

 

add switch hwf class=99 ac=for

add switch hwf class=19 ac=dis

add switch hwf class=20 ac=dis

 

Я конечно все понимаю, что они системные интеграторы и все такое, но мне это решение не нравится... Мне думается, не дело львиную долю производительности оборудования тратить на разбор пакетов. Или нагрузка будет не так уж и велика? Т.е. насколько правильно, рационально такое решение? Насколько оно единственно возможно при таких требованиях и таком оборудовании? Возможны ли какие-то "грабли" в будущем?

 

Есть ли способ каким-то образом отключить автоматическое построение маршрутов к локальным ИП-интерфейсам вроде комманды ip classless у циски?

 

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

[Nailer]

Я конечно все понимаю, что они системные интеграторы и все такое, но мне это решение не нравится... Мне думается, не дело львиную долю производительности оборудования тратить на разбор пакетов. Или нагрузка будет не так уж и велика? Т.е. насколько правильно, рационально такое решение? Насколько оно единственно возможно при таких требованиях и таком оборудовании? Возможны ли какие-то "грабли" в будущем?

 

Если у аллиедов свитчи построены нормально (аппаратно), то операции фильтрации должны выполняться аппаратно. Соответственно, без деградации производительности..

[Гoсть]

Sergey_Taurus,

вы чего хотите сделать то? убить связность между сегментами совсем?

вообще-то подобные фильтры не имеют права на существование как штатный элемент дизайна сети.

[Nag]

Это не системные интеграторы. Это продавцы Телесинов. ;-)

[cs]

Вобще у телесина вроде были обыкновенные фильтры по портам

[Sergey_Taurus]

Еще раз, что хочется: хочется чтобы клиенты были изолированы друго от друга на свиче куда они воткнуты раз, и в пределах всей сети два. Они должны ходить только в подсеть, где расположены сервера. Все.

 

Кто-нибудь может мне "на пальцах" объяснить:

1) Почему решение, предложенное "системным интегратором" неправильно

 

2) Как сделать правильно

 

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

[Grey]

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

[Nailer]

Еще раз, что хочется: хочется чтобы клиенты были изолированы друго от друга на свиче куда они воткнуты раз, и в пределах всей сети два. Они должны ходить только в подсеть, где расположены сервера. Все.

 

Кто-нибудь может мне "на пальцах" объяснить:

1) Почему решение, предложенное "системным интегратором" неправильно

 

2) Как сделать правильно

 

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

 

1. С чего вы взяли, что оно неправильно? Если вам не нарвится использование фильтров, задайте вопрос интегратору - эти фильтры вызывают деградацию производительности свитча или нет?

 

2. Тут это лучше не спрашивать, вам такого порасскажут.. ;-))

 

Зы. 2 Grey Роутер в ядро сети? И какой производительности вы планируете этот роутер? :-)

[Grey]

Зы. 2 Grey Роутер в ядро сети? И какой производительности вы планируете этот роутер? :-)

 

По задаче и производительсность :) А вообще, не надо роутеров... вообще нафига они нужны? Я слышал мнение от преподавателя в ВУЗе одном... роутеры это смерть сетей... :))) Не ставьте вообще роутеров... они сильно тормозят работу сети... ставьте свичи и живите спокойно... :) (Всё равно все умности делаются на умных свичах "аппаратно" т.е. всё равно софтово) ... :)

Утрирую конечно... :) Конечно "апаратные" решения лучше заточены в смысле производительности, но можно сделать всё тоже самое и на PC-роутере, и гибче получится... это всё исключительно ИМХО конечно... Считаю что сеть (большую сеть) строить на одном сегменте и в одной подсети - глупо, значит роутинг!? значит роутер нужен!? Хотя конечно если у Вас гигабит до клиента доходит и он (клиент) всю полосу пользует, тогда разговор другой... надо один сегмент и одну подсеть... и сиськами затариваться.... только покажите мне пальцем на сеть, где такое имеет место быть.... кто из клиентов гигабит (или даже сотню) заюзает под завязку в 90% времени работы? да ещё не один пользователь а ВСЕ пользователи в сети.... такое бывает? ;)

[mastermind]

Grey, есть еще Layer3 свитчи ;)

[Grey]

Grey, есть еще Layer3 свитчи ;)

как не странно, но я в курсе :)))

сколько стоит такой свич, чтоб можно было на нём сделать всё то что я могу сделать на FreeBSD?

Имеется в виду не только то что он (свич) и должен уметь делать, но и к примеру контроль и анализ трафика да ещё с подсчётом и отливом в SQL, да ещё замена софта если необходимо... или предлагается пользовать сиську и кувыркаться с заменой IOS-ов? нет уж... мне как-то удобнее на писюке это всё делать... и vlan терминировать и фаерволом рулить и шейпить и "зя/низя" делать и обсчитывать трафик для билинга или просто для анализа что бегает по сети... да можно массу дел вспомнить что обычно делают на таком аппарате... :), да хотябы на стыке сегментов tcpdump поюзать... :)

Килобаксов к сожалению не всегда хватает для сисек дюже вумных...

[Nailer]

Grey, ну началось :-))))

[vIv]

Еще раз, что хочется: хочется чтобы клиенты были изолированы друго от друга на свиче куда они воткнуты раз, и в пределах всей сети два. Они должны ходить только в подсеть, где расположены сервера. Все.

 

Кто-нибудь может мне "на пальцах" объяснить:

1) Почему решение, предложенное "системным интегратором" неправильно

 

8824 для данной задачи никоим боком не нужны.

 

2) Как сделать правильно

 

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

Если вообще всё порубить, то 8824 выкинуть, на их место поставить 8024 в той же конфигурации, что и на уровне доступа.

Ну или аналогичное что-то, но гигабитное.

 

Весь трафик со всей сети загнать в один-два порта "ТУТ-У-НАС-МЕГА-АПЛИНК"

 

Кстати, можно и не брать даже 8024, а посмотреть китайчатину, - с "port-bsed-типа-vlan" и гигабитами она должна копейки стоить... Там же даже мозгов не нужно...

 

 

---

И всё-таки, а зачем рубить связность?...

[Grey]

Grey, ну началось :-))))

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

Не понятно к чему это было "ну началось" :)

 

P.S. хотя..... что это я тут .... :)

[Nailer]

Grey, я в смысле опять грозит начаться флейм Soft_router vs. Cisco :-) в видоизмененном варианте Soft_router vs. AT :-)))

 

Я, пожалуй, участвовать не буду :-))

[vIv]

Для анализа и учёта трафика в пределах до 5-8 тысяч портов ЗА-ГЛАЗА достаточно ОДНОГО "тяжёлого" L3-коммутатора.

Который порубит сеть на соотв. количество сегментов, а трафик пустит на L3

 

Автор: сколько портов вообще планируется в сети? 4 гигабита обсчитанных - это около 900 баксов + 1500 за пустое шасси.

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

[Grey]

Grey, я в смысле опять грозит начаться флейм Soft_router vs. Cisco :-) в видоизмененном варианте Soft_router vs. AT :-)))

 

Я, пожалуй, участвовать не буду :-))

 

:) Вовсе не хотел такого поворота разговора... Просто если уж зашёл разговор... хочется услышать в чём я не прав? Всё же стоимость решения тоже имеет не малое значение, согласитесь...

[Grey]

Для анализа и учёта трафика в пределах до 5-8 тысяч портов ЗА-ГЛАЗА достаточно ОДНОГО "тяжёлого" L3-коммутатора.

Который порубит сеть на соотв. количество сегментов, а трафик пустит на L3

 

Какого рода анализ и учёт имелся в виду? Какие варианты есть сливать в обрабатывающую базу SQL? Один-два варианта софтовых связок это мне не нравится... Какой ещё выигрышь?

 

P.S. не сочтите за идиота... :) просто много над этим думал... пока не представляю что это за свич умный и сколько он может стоит чтоб получить на нём такую же гибкость как на писюке... Как правило бюджет ограничен... или просто дальнейшее развитие требует затрат и очень полезно использовать железо, которое можно перенастроив перебросить на любой кусок сети для выполнения новой хотя и схожей задачи...

[vIv]

sFlow или для любителей netFlow

лично мне при слове "гигабит" netFlow начинает сильно не нравиться ;-)

 

Любой нормальный биллинг жрёт эти стандартные потоки статистики.

 

Если ну уж очень хочется именно в SQL, то транслятор под вашу SQL-структуру пишется на коленке за пол-часа ;-)

 

Аппаратные ACL, очереди, маршрутизация...

 

Что ещё нужно для зонального коммутатора? ;-)

 

Тем более, что он такой вумный нужен (см. выше) - один на почти 10К юзеров.

 

Вот к примеру такой: HP ProCurve 5304 - шасси полтора штукаря, набивается модулями по 4 гигабита. Можно добавить резервный БП. Полностью hot swap железка.

Да, не кошкалист-6500, но для ЭТИХ задач вполне подходит

[Grey]

sFlow или для любителей netFlow

лично мне при слове "гигабит" netFlow начинает сильно не нравиться ;-)

 

Любой нормальный биллинг жрёт эти стандартные потоки статистики.

 

Если ну уж очень хочется именно в SQL, то транслятор под вашу SQL-структуру пишется на коленке за пол-часа ;-)

 

Аппаратные ACL, очереди, маршрутизация...

 

Что ещё нужно для зонального коммутатора? ;-)

 

Тем более, что он такой вумный нужен (см. выше) - один на почти 10К юзеров.

 

Вот к примеру такой: HP ProCurve 5304 - шасси полтора штукаря, набивается модулями по 4 гигабита. Можно добавить резервный БП. Полностью hot swap железка.

Да, не кошкалист-6500, но для ЭТИХ задач вполне подходит

 

и того сколько стоит?

[vIv]

Считаем модульный мутатор:

1) шасси - 1 штука - 1500

2) модуль 4 медных гигабита - 2 штука по 900

Итого: 1500+2*900=3300 за 8 100/1000 copper

 

Типа того. Цены примерные и зависят от того, где и сколько берёшь

[short]

vIv,

 

Вот к примеру такой: HP ProCurve 5304 -

 

говорят фильтрация на нем software based :) говорят 93xx нада - там hardware based

[vIv]

говорят, там по PowerPC на каждом модуле =)

Так-что правильнее будет сказать portware-based ;-)

 

на 5304 заводили 350 Extended-ACL (срабатывал последний) - реакции на это замечено не было. Дальше стало неинтересно просто...

 

Точнее будет сказать: там всё software срабатывает только когда надо скоммутировать пакет, для SA/DA которого нету таблицы коммутации. Второй такой же пакет пойдёт уже в коммутирующей матрице, проц его даже не увидит.

[Nailer]

vIv, гм. Интересно, что с ним будет от флуда..

[vIv]

Есть такая игрушка, тащи флудилку, посмотрим, что с ним будет :-)