Задачка с маршрутизацией, vlan и т.д.

[docent_stv]

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

Есть такая задача (проблема ? :-) )

Строим ethernet сеть городского масштаба. Объединяем коммутаторы второго уровня в кольца гигабитными оптическими линками. Оные кольца затем включаем в коммутаторы третьего уровня, которые в свою очередь объединены в большое кольцо. И на 2-м и на 3-м уровнях поддерживаются vlan, stp и др.

Собственно задача:

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

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

 

Крышу уже почти сорвало... Может быть у кого либо есть опыт в подобных извращениях ? :-)

[Guest]

Не надо ставить неправильных задач - и крыша будет на месте.

 

Можно, например, мониторить нагрузку на клиентских

интерфейсах (Вам же все равно, что там бродит?).

[Nag]

Тут без схемы и прописывания всех моментов не разобраться. :-(

Но дествительно, babolo прав, задача чем-то неправильным отдает на уровне постановки.

 

По мелочи...

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

 

А вообще, зачем в данном случае коммутаторы 3-го уровня? Транзитные виланы давать с приоретизацией по качеству и полосе? Посчитать трафик-то попроще можно. Видимо это еще и терминрирование виланов, и сервисы (какие?)... Надо все в постановке расписать правильными словами. ;-)

 

Но ладно. Пойдем поэтапно.

 

Посчитать межпользовательский трафик можно только

1. если давать каждому отдельный вилан.

2. считать на пользовательском порту.

Других способов нет даже в теории.

 

Варианты - давать отдельный вилан можно, но зело дорого и неправильно.

Как компромис - считать трафик только между коммутаторами (уж матрицу свитча в доме-то не положат). Или считать трафик "вразброс" - объединяя всех юзеров в десяток виланов случайным и иногда меняющимся образом.

 

Второй вариант - считать трафик езернет (не IP) на порту. То же возможно и недорого.

 

И... Третий вариант - делать туннели ПППоЕ, и терминировать их на уровне агрегирующего кольца... Или в центре... Это не мешает пользователю ставить IP, и общаться в сегменте напрямую. Поэтому можно сочетать с вариантами 1 и 2. Но при этом udp можно будет получать помимо туннеля... Наверно. ;-)

 

Далее, непонятки с udp. Он из кольца вообще не выходит? А откуда берется?

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

 

В общем, вопросов сильно много. ;-)

[docent_stv]

2babolo: Так вот в том то и дело, что не все равно... Часть IP трафика надо сосчитать и тарифицировать, а на другую часть надо не обращая внимания пропустить куда надо (это будет мультикастовый udp трафик).

 

2Nag: Коммутаторы третьего уровня в данном случае нужны чтобы поделить сеть на сегменты. Если не будет коммутаторов третьего уровня, то таблицы MAC-адресов в коммутаторах второго уровня будут быстро переполнятся, что, как можно предположить, вызовет приличные тормоза всей сети.

 

Если поэтапно, только в обратном порядке :-)

 

3. ПППоЕ при количестве клиентов порядка 3-4 тысяч (ну да, планы большие :-) ) очень сильно напряжет оборудование.

 

2. Подсчет ethernet трафика не подходит. Т.к. Вы правильно сказали: это будет видео, инкапсулированное в udp (кстати действительно мультикаст) а отделить потом видео от межпользовательского трафика будет крайне проблематично :)

 

1. Собственно так и хотелось бы это реализовать:

Абонентский порт включается в 2 vlan`а (на 2-м уровне есть поддержка ассиметричных vlan`ов) один для него является основным, а из второго только udp сыпется. Основной vlan терминируется на маршрутизаторе, но тем не менее не понятно, как заставить маршрутизатор пропускать через себя пакеты, которые из той же сети, что и источник.

[docent_stv]

По поводу топологии:

Коммутаторы третьего уровня объединены магистральным кольцом. К ним (к коммутаторам) подключены кольца, в которые объединены коммутаторы второго уровня. Так понятнее или нет ? :)

 

По поводу видео:

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

[Nag]

Коммутаторы третьего уровня в данном случае нужны чтобы поделить сеть на сегменты. Если не будет коммутаторов третьего уровня, то таблицы MAC-адресов в коммутаторах второго уровня будут быстро переполнятся, что, как можно предположить, вызовет приличные тормоза всей сети.  

 

Хм. Вообще, делить на сегменты не барское дело, т.е. это и маршрутизатор-считалка сделать может. Если он все равно есть. 3 уровень больше для сервисов нужен... ;-)

Да и переполнение таблиц МАСов - это совсем не причина тормозов (надеюсь, нет желания строить сеть на управляемых 100-баксовых мыльницах). Тут надо думать только о бродкастовых штормах, но это уже несколько другая история, и другие средства борьбы.

 

3. ПППоЕ при количестве клиентов порядка 3-4 тысяч (ну да, планы большие :-) ) очень сильно напряжет оборудование

 

Уж извините. Во первых, 3-4 т. клиентов - это довольно маленькия сеть. ;-) С его терминацией спраится недорогая жедезка - штук за 5-10 баксов. Если это кажется серьезной задачей - проект такого масштаба вообще ставится под сомнение. Один коммутатор третьего уровня стоит 2,5 штуки (Длинки для магистрали, простите, в сад).

 

2. Подсчет ethernet трафика не подходит. Т.к. Вы правильно сказали: это будет видео, инкапсулированное в udp (кстати действительно мультикаст) а отделить потом видео от межпользовательского трафика будет крайне проблематично :)  

 

А зачем его делить? Пусть себе считается 2 раза... Это можно тарифами достаточно легко разделить. И понятно для абонента. Есть локал (езернет) как услуга. Есть внешка (как другая услуга).

 

Далее. Потоки видео зачем вообще считать как трафик? Они же откуда-то уходят? И там есть (должен быть) механизм кодирования и авторизации... Зачем множить сущности?

 

Я вообще не понимаю, если вещание udp идет из центра, то почему говорится о его существовании только в клиентских кольцах? Оно буде переть из центра, и это совсем другая логика...

 

Абонентский порт включается в 2 vlan`а (на 2-м уровне есть поддержка ассиметричных vlan`ов) один для него является основным, а из второго только udp сыпется. Основной vlan терминируется на маршрутизаторе, но тем не менее не понятно, как заставить маршрутизатор пропускать через себя пакеты, которые из той же сети, что и источник.

 

Хм... Это вообще что за такой ассиметричный вилан? Можно поподробнее?

Я с трудом представляю себе даже включение порта в 2 тегированных вилана.

Даже в теории.

Может чего нового придумали конечно. Но это не будет стоить дешево.

[docent_stv]

Вообще, делить на сегменты не барское дело, т.е. это и маршрутизатор-считалка сделать может.  

 

Дык маршрутизатор то сколько трафика пропустить через себя сможет ? 100 Мбит/с ? А если гигабит пропускать, то это ж какой маршрутизатор то нужен ?

Чтобы у него штук 12-16 портов было ? А свитч третьего уровня -- дешево и сердито.

 

надеюсь, нет желания строить сеть на управляемых 100-баксовых мыльницах).  

 

Абонентское железо -- D-Link DES-3226S. Для магистрали -- D-Link DGS-3312S. Мыльницы, или нет ? Если можно, то по конкретнее, почему "в сад" ?

 

Далее. Потоки видео зачем вообще считать как трафик?

 

Так вот не хочется вообще его считать ! А при варианте учета ethernet трафика там будет все до кучи видео, интернет и внутрисетевой трафик. Интернет мы сосчитаем на шлюзе, внутрисетевой трафик на маршрутизаторе, подключенном к узловому коммутатору. Можно конечно интернет и интранет потом вычесть из ethernet`а на порту клиента и получится видео. Но нам то его считать как раз и не надо :-)))

 

Оно буде переть из центра, и это совсем другая логика

 

Эээ.. Не понял...

 

Это вообще что за такой ассиметричный вилан? Можно поподробнее?

 

Кончно: В D-Link DES-3226S (да и у други производителей) появилась новая фича -- порт можно включить как untagged в несколько vlan`ов. При этом первый vlan будет основным, через него собственно и будет идти работа, а через другие vlan`ы трафик будет только входящим. Сейчас не могу ссылку найти, но как только найду -- кину.

[Nag]

Дык маршрутизатор то сколько трафика пропустить через себя сможет ? 100 Мбит/с ? А если гигабит пропускать, то это ж какой маршрутизатор то нужен ?  

Чтобы у него штук 12-16 портов было ? А свитч третьего уровня -- дешево и сердито.  

 

Мда. А как же мил-человек, вы считать трафик тогда собрались? ;-)

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

 

Абонентское железо -- D-Link DES-3226S. Для магистрали -- D-Link DGS-3312S. Мыльницы, или нет ? Если можно, то по конкретнее, почему "в сад" ?  

 

Абонентское понятнет, наверно. :-)

А для магистрали... Хм. :-))) Ну попробуйте, можно будет заодно тотализатор устроить.

 

Так вот не хочется вообще его считать ! А при варианте учета ethernet трафика там будет все до кучи видео, интернет и внутрисетевой трафик. Интернет мы сосчитаем на шлюзе, внутрисетевой трафик на маршрутизаторе, подключенном к узловому коммутатору. Можно конечно интернет и интранет потом вычесть из ethernet`а на порту клиента и получится видео. Но нам то его считать как раз и не надо :-)))  

 

Э... Ну не хочется считать - так и не считайте. Нетфлов вроде как легко позволит выделить UDP из рассчетной базы. Или я ошибаюсь?

 

Кончно: В D-Link DES-3226S (да и у други производителей) появилась новая фича -- порт можно включить как untagged в несколько vlan`ов. При этом первый vlan будет основным, через него собственно и будет идти работа, а через другие vlan`ы трафик будет только входящим. Сейчас не могу ссылку найти, но как только найду -- кину.

 

Вот,вот. Этого я и боялся. ;-) Ключевое слово untagged.

Это для офиса как-то еще можно использовать. Наверно.

Для магистрали - в сад. ;-)

Почему - уже устал разъяснять...

 

В общем, придется наверно статью писать. ;-)

 

А пока - на самом деле, тут надо начинать рисовать проект... Хоть эскиз.

Но начинать надо с изучения принципов работы Ethernet. ;-) Прошу только не обижаться. Но к таким решениям надо серьезнее подходить, по крайней мере после этого не будет смешения принципиально разных виланов в одну кучу.

И со способами подсчета трафика ясность наступит...

[DiBrain]

агы untagged vlan существует только в пределах одной железки и не более того.

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

[Guest]

Не изобрейте велосибед. Есть один механизм, снятие общей статистики по SNMP.

[docent_stv]

Так ведь по SNMP получится очень и очень приблизительно. Туда будет включен и интернет трафик и локальный и видео. Потом это все обсчитать будет достаточно сложно.

[docent_stv]

Так ведь по SNMP получится очень и очень приблизительно. Туда будет включен и интернет трафик и локальный и видео. Потом это все обсчитать будет достаточно сложно.