The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Сегментация коммутаторов в городской сети"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Маршрутизаторы CISCO и др. оборудование. (ACL, фильтрация и ограничение трафика)
Изначальное сообщение [ Отслеживать ]

"Сегментация коммутаторов в городской сети"  +/
Сообщение от SlavikSG (ok) on 24-Окт-12, 10:29 
Народ, привет!

Подскажите пожалуйста чайнику, как грамотно настроить сеть на примере трех цископодобных коммутаторов. Одна Агрегация (QTech QSW-8300), и два подсоединенных к ней Доступа  (QTech QSW-2800). Нужно сделать так, чтобы Доступы друг друга не видели. Скажем, если железок в сети будет от 2000 до 4000, то не приведет ли это к сильному "зашумлению" сети бродкастовым трафиком? А уж про бродастовый шторм я вообще молчу. Вся сеть ляжет. Вот и хотелось бы сегментировать железки по районам города.

В моей тестовой сборке "на столе" Вланы управления коммутаторами находятся в разных подсетях. Клиентские вланы тоже. Но когда они все собираются в кучу на коммутаторе Агрегации, то все коммутаторы начинают прозрачно видеть друг друга и пинговать. Проводя эксперименты я умышленно спровоцировал бродкастовый шторм (петлей) и разумеется все три коммутатора встали.

Пока получается изолировать Доступы друг от друга  только изоляцией портов на Агрегации. Но что-то мне подсказывает, что это неверное решение. Хоть и замечательно работает.

Или может вообще не обращать внимание на этот небольшой бродкаствый трафик между коммутаторами? Типа, засунуть их в одну подсеть с маской 255.255.248.0 и забить на это дело?

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Сегментация коммутаторов в городской сети"  +/
Сообщение от eek email on 24-Окт-12, 12:05 
Вас беспокоят броадкасты от интерфейсов управления или абонентские?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Сегментация коммутаторов в городской сети"  +/
Сообщение от SlavikSG (ok) on 24-Окт-12, 18:14 
> Вас беспокоят броадкасты от интерфейсов управления или абонентские?

Я и сам не знаю. Наверное, и то и другое. Просто впервые стоит такая задача. Опыта в этом деле ноль. Самого главного не могу понять. Нужно ли вообще закрывать коммутаторы и абонентов друг от друга внутри городской сети? Я не знаю, что можно ожидать в будущем, если и коммутаторы и абоненты будут видеть друга через внутреннюю городскую сеть. Нормально ли это будет?

Как я уже написал выше, команды на Агрегации:
isolate-port group 1 switchport interface ethernet 1/0/1
isolate-port group 2 switchport interface ethernet 1/0/2
isolate-port group 3 switchport interface ethernet 1/0/3
isolate-port group 4 switchport interface ethernet 1/0/4
isolate-port group 5 switchport interface ethernet 1/0/5
isolate-port group 6 switchport interface ethernet 1/0/6
isolate-port group 7 switchport interface ethernet 1/0/7
isolate-port group 8 switchport interface ethernet 1/0/8
isolate-port group 9 switchport interface ethernet 1/0/9
isolate-port group 10 switchport interface ethernet 1/0/10
isolate-port group 11 switchport interface ethernet 1/0/11
isolate-port group 12 switchport interface ethernet 1/0/12
isolate-port group 13 switchport interface ethernet 1/0/13
isolate-port group 14 switchport interface ethernet 1/0/14
isolate-port group 15 switchport interface ethernet 1/0/15
isolate-port group 16 switchport interface ethernet 1/0/16
isolate-port group 17 switchport interface ethernet 1/0/17
isolate-port group 18 switchport interface ethernet 1/0/18
isolate-port group 19 switchport interface ethernet 1/0/19
isolate-port group 20 switchport interface ethernet 1/0/20
isolate-port group 21 switchport interface ethernet 1/0/21
isolate-port group 22 switchport interface ethernet 1/0/22
isolate-port group 23 switchport interface ethernet 1/0/23
isolate-port group 24 switchport interface ethernet 1/0/24
самым замечательным образом решают эту задачу. Клиенты имеют у себя интернет, я имею доступ ко всем коммутаторам, и коммутаторы Доступа не видят друг друга. Но нужно ли это вообще делать???!!! И если нужно, то как правильно и грамотно это нужно делать?

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Сегментация коммутаторов в городской сети"  +/
Сообщение от fantom (ok) on 25-Окт-12, 10:22 
>> Вас беспокоят броадкасты от интерфейсов управления или абонентские?
> Я и сам не знаю.

ВОТ! пока вы не определитесь для себя с политикой доступа все остальные вопросы типа "а как правильно..." не имеют смысла, т.к. это будет мнение вида
"ПравильноТАК! ибо Я так сделал и МЕНЯ (заметьте - не Вас) это вполне устраивает!"

>[оверквотинг удален]
> isolate-port group 19 switchport interface ethernet 1/0/19
> isolate-port group 20 switchport interface ethernet 1/0/20
> isolate-port group 21 switchport interface ethernet 1/0/21
> isolate-port group 22 switchport interface ethernet 1/0/22
> isolate-port group 23 switchport interface ethernet 1/0/23
> isolate-port group 24 switchport interface ethernet 1/0/24
> самым замечательным образом решают эту задачу. Клиенты имеют у себя интернет, я
> имею доступ ко всем коммутаторам, и коммутаторы Доступа не видят друг
> друга. Но нужно ли это вообще делать???!!! И если нужно, то
> как правильно и грамотно это нужно делать?

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Сегментация коммутаторов в городской сети"  +/
Сообщение от SlavikSG (ok) on 25-Окт-12, 12:25 
> ...пока вы не определитесь для себя с политикой доступа все остальные
> вопросы типа "а как правильно..." не имеют смысла

Вы наверное не прочитали мои вопросы. Я спрашивал:
1. Будет ли сильный бродкастовый трафик между коммутаторами, если их количество достигнет 2000-4000 штук.
2. Если трафик будет сильный, то как грамотнее его уменьшить? Сегментацией сети на подсети? Или изоляции портов на Агрегации будет достаточно?

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Сегментация коммутаторов в городской сети"  +/
Сообщение от fantom (ok) on 25-Окт-12, 12:54 
>> ...пока вы не определитесь для себя с политикой доступа все остальные
>> вопросы типа "а как правильно..." не имеют смысла
> Вы наверное не прочитали мои вопросы. Я спрашивал:
> 1. Будет ли сильный бродкастовый трафик между коммутаторами, если их количество достигнет
> 2000-4000 штук.
> 2. Если трафик будет сильный, то как грамотнее его уменьшить? Сегментацией сети
> на подсети? Или изоляции портов на Агрегации будет достаточно?

Это я какраз прочел...
бродкаст создают не коммутаторы ;) а хосты, методов борьбы несколько:
1. изоляция портов на Агрегации(или доступа???) - но вы заодно изолируете хосты (или некие сегменты???) друг от друга, что может сказаться на используемых в сети сервисах (например если пользователи подсели на какой-нибудь безсерверный чат или привыкли спокойно переливать файло через вашу сетку и вы вдруг лишаете их столь привычного инструмента).
2. Сегментацией сети на подсети (естественно с разбиением на VLAN, иначе бесполезно)
бродкаст изолируется внутри одного сегмента и не перетекает в другие, взаимодействие между пользователями уже обеспечивается не на L2 а на L3 и через маршрутер(шлюз).
3. ограничение бродкаста на каждом порту коммутаторов доступа - и тада один отдельно взятый хост сможет только создать небольшую волну, а не шторм бродкастов.

варианты не исключающие, возможен как выбор только одного так и комбинация в любых вариантах....
Как, что и с чем комбинировать - определять ВАМ на основе ВАШЕЙ политики доступа.


Если вы хотите максимального контроля - изоляция на доступе + изоляция на агрегации + ограничение бродкаста на каждом (абонентском естественно) порту коммутаторов доступа - и вы сведете бродкаст к минимально возможному уровню, введете IPv6 и запретите IPv4 - и у вас его практически совсем не станет ;)

далее чем больше либерализма - тем больше бродкаста, какой уровень является приемлимым? да ХЗ, для когото до 10% пропускной способности канала не критичны и можно даже не чесаться, а кто-то при 1% уже ищет виновника и принимает меры....

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Сегментация коммутаторов в городской сети"  +/
Сообщение от SlavikSG (ok) on 25-Окт-12, 18:19 
Спасибо за ваш ответ!

Мне вот что не ясно! Вообще, теория гласит, что бродастовый трафик распространяется в пределах только одной подсети. А уж про один влан и тем более молчу. Стена!!! А на деле, на "столе", у меня получается обратное.

Поставил на стол Агрегацию. Подключил к ней два Доступа. По "Звезде", конечно. Каждый Доступ, к своему порту Агрегации. Оба Доступа сидят в разных клиентских подсетях и вланах. Так же есть один влан управления, который есть на всех трех коммутаторах. Это тоже своя личная подсеть, не связанная с клиентами. Подключил тестовый "комп клиента" к одному из портов коммутатора Доступа. Комп клиента подключил не напрямую в сетевую карту, а через его личный домашний коммутатор. На этом коммутаторе сделал петлю. Тем самым спровоцировал "Бродкастовый шторм". Начал смотреть на соседний Доступ. И постепенно увидел, что "шторм" распространяется и на него тоже. Во всяком случае, на его оптическом, транковом порту это очень заметно было по быстро мигающему светодиоду... Петлю убираю, светодиод перестает мигать. Отсюда и возник мой вопрос, как с этим бороться. Ведь клиентские вланы на Доступах разные, подсети разные, но "шторм" все равно распространяется. Распространяется он через Агрегацию. По сути, Агрегация связывает (маршрутизирует) оба клиентских влана друг с другом. Вот мне и не ясно, как с этим нужно правильно бороться. (Естественно, на клиентских портах будет стоять защита от петель, но пока я ее умышленно убрал).

С политикой определился. Пока это будет "влан на дом". Один или два коммутатора Доступа на одну "хрущевку". Абоненты одного дома, будут общаться друг с другом напрямую. Другие дома, уже через Агрегацию. Так планировалось. А в итоге получается, что спровоцированный мною "Шторм" распространятся через Агрегацию и на другие "дома-коммутаторы". И в итоге распространится на всю сеть. Изоляция портов, вы правильно подметили, тоже не есть гуд. Если клиенты начнут активно "юзаться" друг с другом, вся нагрузка ляжет на инетовский шлюз и пострадает уже скорость внешки.

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

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Сегментация коммутаторов в городской сети"  +/
Сообщение от Andrey (??) on 25-Окт-12, 18:29 
>[оверквотинг удален]
> с другом напрямую. Другие дома, уже через Агрегацию. Так планировалось. А
> в итоге получается, что спровоцированный мною "Шторм" распространятся через Агрегацию
> и на другие "дома-коммутаторы". И в итоге распространится на всю сеть.
> Изоляция портов, вы правильно подметили, тоже не есть гуд. Если клиенты
> начнут активно "юзаться" друг с другом, вся нагрузка ляжет на инетовский
> шлюз и пострадает уже скорость внешки.
> В общем пока, как полный чайник и новичок в этом вопросе, вижу
> переде собой только "замкнутый круг". Петлю на коммутаторе или на шее.
> :) Получается - либо неконтролируемый бродкаст, либо забитый под завязку инетовский
> шлюз. :(

1. Для всех Spanning Tree.
2. Для пользователей Private VLAN.
3. Нагрузка между пользователями выносится на L3 коммутатор, а не на "пограничник". Это равнозначно и для средних/больших офисных сетей и для ISP.
4. Используемые вами свитчи не поддерживают технологий Broadcast Storm Control, loop detect, или что-нибудь похожее? У разных производителей они могут называться по разному и по разному использоваться, но суть одна.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Сегментация коммутаторов в городской сети"  +/
Сообщение от fantom (ok) on 26-Окт-12, 09:38 
>[оверквотинг удален]
> с другом напрямую. Другие дома, уже через Агрегацию. Так планировалось. А
> в итоге получается, что спровоцированный мною "Шторм" распространятся через Агрегацию
> и на другие "дома-коммутаторы". И в итоге распространится на всю сеть.
> Изоляция портов, вы правильно подметили, тоже не есть гуд. Если клиенты
> начнут активно "юзаться" друг с другом, вся нагрузка ляжет на инетовский
> шлюз и пострадает уже скорость внешки.
> В общем пока, как полный чайник и новичок в этом вопросе, вижу
> переде собой только "замкнутый круг". Петлю на коммутаторе или на шее.
> :) Получается - либо неконтролируемый бродкаст, либо забитый под завязку инетовский
> шлюз. :(

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

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "Сегментация коммутаторов в городской сети"  +/
Сообщение от SlavikSG (ok) on 26-Окт-12, 11:31 
Спасибо за ваши ответы!

Есть и spanning-tree и Storm Control и loop detect.
Вообще, как я уже писал выше, эти коммутаторы на Циски очень похожи.

Буду разбираться. Кое-какие мысли уже назрели...

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру