проектузла связи

[mousus]

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

[sdy_moscow]

жесть... стройте уж тогда кольцом - надежность та-же админить легче.

[mousus]

а в чём именно жесть?

[sdy_moscow]

а в чём именно жесть?

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

[Alexandr Ovcharenko]

+1

Жесть! Да, именно так и строят "узел связи небольшого провайдерского уровня". Но исключительно в случае если вендоры/интеграторы предложили достойный откат.

Объясните пожалуйста, какие именно УНИКАЛЬНО-НЕДУБЛИРУЮЩИЕ функции будут выполнять:

1. Пограничные коммутаторы.

2. СОРЕ-маршрутизаторы.

3. СОРЕ-коммутаторы стекируемые.

4. Коммутаторы биллинга.

 

Не кажется ли Вам, что это все с успехом заменит один (или 2 для резервирования) L3-свича.

[CNick]

зачем core комутаторы и core маршрутизаторы отдельно?

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

L3 комутатор запросто такое зароутить может.

 

П.C. Глядя на схему сраза в голову Бритва Окаммы лезит :)

 

+1

Жесть! Да, именно так и строят "узел связи небольшого провайдерского уровня".

Судя по схеме в небольшом узле связи одного только билинга будет стойки две ;) Edited March 28, 2009 by CNick

[Alexandr Ovcharenko]

Вон в соседнем топике про кольцо на 10Г люди тоже мутят проект небольшого провайдера на 2000 абонентов с бюджетом узла на $300К. Автор, вы часом не из этой же конторы?

[ingress]

чем то поверпоинт от циски напоминает :D

Edited March 28, 2009 by ingress

[mousus]

Вон в соседнем топике про кольцо на 10Г люди тоже мутят проект небольшого провайдера на 2000 абонентов с бюджетом узла на $300К. Автор, вы часом не из этой же конторы?

контора одна, палаты разные))

 

сейчас это всё работает на одном (!) управляемом L2 коммутаторе и маленькой кучке софт-роутеров под FreeBSD, и задумалось расширение с переделкой, (планы как всегда Наполеоновские) и в классической ситуации когда денег лишних нет и есть желание купить с запасом на вырост, чтобы потом какое то время не вкладывать деньги (которые еще отбить надо будет) в покупку дополнительного железа, кстати если уж пошла речь о резервировании, то кто каким способом обеспечивает?

[CNick]

Ключевое слово "все работает" :) А зачем что-то усложнять если все и так работает. По поводу резервирования.... чем меньше устройст тем меньше нужно резервировать ))

 

ИМХО роль

Пограничных маршрутизаторов

Пограничных коммутатов.

СОРЕ-маршрутизаторов

СОРЕ-стекируемых комутаторов

и

Коммутаторы биллинга.

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

Хотя в идеале лучше бордеры на отдельную железку вынести.

 

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

[Alexandr Ovcharenko]

+1

Если терминация/шейпинг вынесена на сервера доступа, то все остальное легко сделает один 65хх.

[EvilX]

Жесть, конечно.

Кроме того, "беспроводные" пишется через С.

[mousus]

спасибо огромное за разумную критику, вот что у меня получилось с учётом ваших пожеланий:

 

нагрузка до 2000 абонентов, боюсь что кочьего представителя 65хх пока не потянем, серверы доступа уже сделаны на отдельных машинах с FreeBSD, там же и режется скорость, в дальнейшем планируестя переход на аппаратное решение, в качестве бордеров пока присматриваемся к кошачьим 36хх (сейчас также их роль исполняет FreeBSD)

[sdy_moscow]

О... появился разум....

 

Если узел в одном месте, то можно объединить core комутатор и комутатор биллинга.

 

Пограничный комутатор, пограничные маршрутизаторы и кор комутатор - наверно разумнее объединить.

 

Не очень понятно что имелось ввиду про комутатор беспроводных клиентов, если у вас точки доступа стоят в тех-же местах где проводные абоненты (на крышах домов например), то гораздо проще объединить их через ту-же физику но в отдельном ВЛАНЕ.

 

Вряд-ли вам при таком кол-ве абонентов понадобиться больше одного сервера биллинга - для его резервирования хватит машины стоящей в стороне с бэкапом "от вчера". А вот серверов доступа понадопится скорее всего 2-3 штуки.

[Alexandr Ovcharenko]

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

В Вашей схеме 4 блока - пограничный коммутатор, коре-маршрутизатор, коре коммутатор и коммутатор биллинга - можно заменить одним гигабитным свичем L3. Например каталист 3560Г или что-то более бюджетное - типа эдж-кор 4626. А если раскинуть мозгами, и свести серверы биллинга, доступа и бордеры в одну адресную зону, то маршрутизация там вообще нафиг не нужна. Тогда за уши хватит свича L2.

Понятно, что хочется красиво, как в учебнике по циске, и чтобы на будущее запас был. Но судите сами:

1. В чём смысл пограничного коммутатора? Только в том, что у коре-маршрутизатора нет лишнего порта для линка с бордерами. Что явно нереально.

2. В чём смысл коре-коммутатора? Опять же в том, что у коре-маршрутизатора нет лишних портов для линка с серверами доступа и биллингом. Да, иногда такое бывает, но лучше этого не допускать.

3. Коммутатор биллинга и коре-коммутатор - почему разнесены? Логически это одна железяка. Или проблема в прокладке кабелей между серверами биллинга и коре-коммутатором? Обычно это максимум соседние стойки.

4. Как уже и писалось выше - зачем лишняя маршрутизация в ядре? Коре-маршрутизатор имеет смысл, если у Вас совсем много серверов доступа и серверов биллинга. У Вас 2К абонентов? Даже с учетом роста, вряд ли будет более десятка серверов. Кого тут маршрутизировать? Сделать все сервера в одной адресной зоне с бордерами и все.

[mousus]

О... появился разум....

 

Если узел в одном месте, то можно объединить core комутатор и комутатор биллинга.

 

Пограничный комутатор, пограничные маршрутизаторы и кор комутатор - наверно разумнее объединить.

 

Не очень понятно что имелось ввиду про комутатор беспроводных клиентов, если у вас точки доступа стоят в тех-же местах где проводные абоненты (на крышах домов например), то гораздо проще объединить их через ту-же физику но в отдельном ВЛАНЕ.

 

Вряд-ли вам при таком кол-ве абонентов понадобиться больше одного сервера биллинга - для его резервирования хватит машины стоящей в стороне с бэкапом "от вчера". А вот серверов доступа понадопится скорее всего 2-3 штуки.

да, узел в одном месте планируется, а вот проводные абоненты и точки доступа разнесены, и установка точек доступа планируется там, где уже есть другие проводные операторы, и их задача обеспечить интернетом тех абонентов, куда кинуть кабель крайне затруднительно (например частный сектор, и удалённые районы на другом берегу Волги, ибо оптику туда по определению кинуть даже при наличаи толстого кошелька непросто) да коммутатор биллинга, CORE коммутатор и пограничный коммутатор есть идея сделать на одной железке

[mousus]

А если раскинуть мозгами, и свести серверы биллинга, доступа и бордеры в одну адресную зону, то маршрутизация там вообще нафиг не нужна. Тогда за уши хватит свича L2.

да, вы правы и сходя из того что такая железка (Dlink DGS-3100-24) у меня уже полгода пылится дома в шкафу то можно применить её "порезав" на несколько VLAN`ов

 

единственное что останавливает от использования только одной этой железки, так тот факт что планируется еще в эту схему поселить в дальнейшем IPTV и VoIP, соответственно закрадывается мысль както всётаки разнести всё по разным железякам

[Alexandr Ovcharenko]

единственное что останавливает от использования только одной этой железки, так тот факт что планируется еще в эту схему поселить в дальнейшем IPTV и VoIP, соответственно закрадывается мысль както всётаки разнести всё по разным железякам

А что это меняет? Когда дойдет дело до внедрения просто воткнете в центральную железяку еще одну для ТВ и одну для голоса. Тут гораздо важнее будет - насколько правильно организован доступ/агрегация/распределение, смогут ли они нормально новые сервисы доставить конечному юзеру.

Edited March 29, 2009 by Alexandr Ovcharenko

[mousus]

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

интернет-бордер-коммутатор узла-сервер доступа-коммутатор распределения-пользователь

 

что и как имеет смысл резервировать (не иучитывая мощность и нагрузку)?

 

2 бордера от разных провайдеров

от 2 серверов доступа

 

но как тогда резервировать коммутатор узла (в котором под разным соусом и вланом но торчит всё, если он большой и очень умный) в случае кошачьего каталиста 65хх ?

[sdy_moscow]

резервировать

бэкапом настроек,

железками нка складе,

круглосуточной аварийной службой

[mousus]

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

[sdy_moscow]

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

Edited March 29, 2009 by sdy_moscow

[Stak]

но как тогда резервировать коммутатор узла (в котором под разным соусом и вланом но торчит всё, если он большой и очень умный) в случае кошачьего каталиста 65хх ?

Как раз в этом случае проще всего))) 2БП, 2 супервизора и запасной линейный модуль на складе))) Правда от пожара не спасёт, ибо нет географически распределённой схемы)))