mousus Опубликовано 28 марта, 2009 · Жалоба предстоит в обозримом будущем сдавать узел связи небольшого провайдерского уровня, вот на скорую руку набросал эскиз того что примерно планируется, просьба покритиковать выбранную схему Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 28 марта, 2009 · Жалоба жесть... стройте уж тогда кольцом - надежность та-же админить легче. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mousus Опубликовано 28 марта, 2009 · Жалоба а в чём именно жесть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 28 марта, 2009 · Жалоба а в чём именно жесть? жесть -как вы собираетесь организовать эти пересикающиеся туда сюда связи и главное ими управлять. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alexandr Ovcharenko Опубликовано 28 марта, 2009 · Жалоба +1 Жесть! Да, именно так и строят "узел связи небольшого провайдерского уровня". Но исключительно в случае если вендоры/интеграторы предложили достойный откат. Объясните пожалуйста, какие именно УНИКАЛЬНО-НЕДУБЛИРУЮЩИЕ функции будут выполнять: 1. Пограничные коммутаторы. 2. СОРЕ-маршрутизаторы. 3. СОРЕ-коммутаторы стекируемые. 4. Коммутаторы биллинга. Не кажется ли Вам, что это все с успехом заменит один (или 2 для резервирования) L3-свича. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
CNick Опубликовано 28 марта, 2009 (изменено) · Жалоба зачем core комутаторы и core маршрутизаторы отдельно? В ядре маршрутизируеться только свои адреса, коих не так много. L3 комутатор запросто такое зароутить может. П.C. Глядя на схему сраза в голову Бритва Окаммы лезит :) +1Жесть! Да, именно так и строят "узел связи небольшого провайдерского уровня". Судя по схеме в небольшом узле связи одного только билинга будет стойки две ;) Изменено 28 марта, 2009 пользователем CNick Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alexandr Ovcharenko Опубликовано 28 марта, 2009 · Жалоба Вон в соседнем топике про кольцо на 10Г люди тоже мутят проект небольшого провайдера на 2000 абонентов с бюджетом узла на $300К. Автор, вы часом не из этой же конторы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 28 марта, 2009 (изменено) · Жалоба чем то поверпоинт от циски напоминает :D Изменено 28 марта, 2009 пользователем ingress Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mousus Опубликовано 28 марта, 2009 · Жалоба Вон в соседнем топике про кольцо на 10Г люди тоже мутят проект небольшого провайдера на 2000 абонентов с бюджетом узла на $300К. Автор, вы часом не из этой же конторы?контора одна, палаты разные)) сейчас это всё работает на одном (!) управляемом L2 коммутаторе и маленькой кучке софт-роутеров под FreeBSD, и задумалось расширение с переделкой, (планы как всегда Наполеоновские) и в классической ситуации когда денег лишних нет и есть желание купить с запасом на вырост, чтобы потом какое то время не вкладывать деньги (которые еще отбить надо будет) в покупку дополнительного железа, кстати если уж пошла речь о резервировании, то кто каким способом обеспечивает? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
CNick Опубликовано 29 марта, 2009 · Жалоба Ключевое слово "все работает" :) А зачем что-то усложнять если все и так работает. По поводу резервирования.... чем меньше устройст тем меньше нужно резервировать )) ИМХО роль Пограничных маршрутизаторов Пограничных коммутатов. СОРЕ-маршрутизаторов СОРЕ-стекируемых комутаторов и Коммутаторы биллинга. Может исполнять одна кошка 65xx с двумя супервизорами и двумя бп для резервирования, куда и втыкать аплинки билинг и сервера доступа. Хотя в идеале лучше бордеры на отдельную железку вынести. 65хх это для примера, если конкретно интересует выбор железа, лучше озвучить количество абонентов, бюджет, и текущюю нагрузку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alexandr Ovcharenko Опубликовано 29 марта, 2009 · Жалоба +1 Если терминация/шейпинг вынесена на сервера доступа, то все остальное легко сделает один 65хх. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EvilX Опубликовано 29 марта, 2009 · Жалоба Жесть, конечно. Кроме того, "беспроводные" пишется через С. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mousus Опубликовано 29 марта, 2009 · Жалоба спасибо огромное за разумную критику, вот что у меня получилось с учётом ваших пожеланий: нагрузка до 2000 абонентов, боюсь что кочьего представителя 65хх пока не потянем, серверы доступа уже сделаны на отдельных машинах с FreeBSD, там же и режется скорость, в дальнейшем планируестя переход на аппаратное решение, в качестве бордеров пока присматриваемся к кошачьим 36хх (сейчас также их роль исполняет FreeBSD) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 29 марта, 2009 · Жалоба О... появился разум.... Если узел в одном месте, то можно объединить core комутатор и комутатор биллинга. Пограничный комутатор, пограничные маршрутизаторы и кор комутатор - наверно разумнее объединить. Не очень понятно что имелось ввиду про комутатор беспроводных клиентов, если у вас точки доступа стоят в тех-же местах где проводные абоненты (на крышах домов например), то гораздо проще объединить их через ту-же физику но в отдельном ВЛАНЕ. Вряд-ли вам при таком кол-ве абонентов понадобиться больше одного сервера биллинга - для его резервирования хватит машины стоящей в стороне с бэкапом "от вчера". А вот серверов доступа понадопится скорее всего 2-3 штуки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alexandr Ovcharenko Опубликовано 29 марта, 2009 · Жалоба :) Вы опять не учли главного - чем больше промежуточного активного оборудования между клиентом и инетом, тем больше вероятных точек отказа, а значит и головной боли у саппорта. В Вашей схеме 4 блока - пограничный коммутатор, коре-маршрутизатор, коре коммутатор и коммутатор биллинга - можно заменить одним гигабитным свичем L3. Например каталист 3560Г или что-то более бюджетное - типа эдж-кор 4626. А если раскинуть мозгами, и свести серверы биллинга, доступа и бордеры в одну адресную зону, то маршрутизация там вообще нафиг не нужна. Тогда за уши хватит свича L2. Понятно, что хочется красиво, как в учебнике по циске, и чтобы на будущее запас был. Но судите сами: 1. В чём смысл пограничного коммутатора? Только в том, что у коре-маршрутизатора нет лишнего порта для линка с бордерами. Что явно нереально. 2. В чём смысл коре-коммутатора? Опять же в том, что у коре-маршрутизатора нет лишних портов для линка с серверами доступа и биллингом. Да, иногда такое бывает, но лучше этого не допускать. 3. Коммутатор биллинга и коре-коммутатор - почему разнесены? Логически это одна железяка. Или проблема в прокладке кабелей между серверами биллинга и коре-коммутатором? Обычно это максимум соседние стойки. 4. Как уже и писалось выше - зачем лишняя маршрутизация в ядре? Коре-маршрутизатор имеет смысл, если у Вас совсем много серверов доступа и серверов биллинга. У Вас 2К абонентов? Даже с учетом роста, вряд ли будет более десятка серверов. Кого тут маршрутизировать? Сделать все сервера в одной адресной зоне с бордерами и все. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mousus Опубликовано 29 марта, 2009 · Жалоба О... появился разум.... Если узел в одном месте, то можно объединить core комутатор и комутатор биллинга. Пограничный комутатор, пограничные маршрутизаторы и кор комутатор - наверно разумнее объединить. Не очень понятно что имелось ввиду про комутатор беспроводных клиентов, если у вас точки доступа стоят в тех-же местах где проводные абоненты (на крышах домов например), то гораздо проще объединить их через ту-же физику но в отдельном ВЛАНЕ. Вряд-ли вам при таком кол-ве абонентов понадобиться больше одного сервера биллинга - для его резервирования хватит машины стоящей в стороне с бэкапом "от вчера". А вот серверов доступа понадопится скорее всего 2-3 штуки. да, узел в одном месте планируется, а вот проводные абоненты и точки доступа разнесены, и установка точек доступа планируется там, где уже есть другие проводные операторы, и их задача обеспечить интернетом тех абонентов, куда кинуть кабель крайне затруднительно (например частный сектор, и удалённые районы на другом берегу Волги, ибо оптику туда по определению кинуть даже при наличаи толстого кошелька непросто) да коммутатор биллинга, CORE коммутатор и пограничный коммутатор есть идея сделать на одной железке Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mousus Опубликовано 29 марта, 2009 · Жалоба А если раскинуть мозгами, и свести серверы биллинга, доступа и бордеры в одну адресную зону, то маршрутизация там вообще нафиг не нужна. Тогда за уши хватит свича L2.да, вы правы и сходя из того что такая железка (Dlink DGS-3100-24) у меня уже полгода пылится дома в шкафу то можно применить её "порезав" на несколько VLAN`ов единственное что останавливает от использования только одной этой железки, так тот факт что планируется еще в эту схему поселить в дальнейшем IPTV и VoIP, соответственно закрадывается мысль както всётаки разнести всё по разным железякам Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alexandr Ovcharenko Опубликовано 29 марта, 2009 (изменено) · Жалоба единственное что останавливает от использования только одной этой железки, так тот факт что планируется еще в эту схему поселить в дальнейшем IPTV и VoIP, соответственно закрадывается мысль както всётаки разнести всё по разным железякам А что это меняет? Когда дойдет дело до внедрения просто воткнете в центральную железяку еще одну для ТВ и одну для голоса. Тут гораздо важнее будет - насколько правильно организован доступ/агрегация/распределение, смогут ли они нормально новые сервисы доставить конечному юзеру. Изменено 29 марта, 2009 пользователем Alexandr Ovcharenko Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mousus Опубликовано 29 марта, 2009 · Жалоба да пожалуй это превыше всего, вот правда как быть если ко всему этому надо еще и отказоустойчивость с резервированием приделать, да это усложняет задачу, как грамотнее сделать резервирование в по сути линейной схеме: интернет-бордер-коммутатор узла-сервер доступа-коммутатор распределения-пользователь что и как имеет смысл резервировать (не иучитывая мощность и нагрузку)? 2 бордера от разных провайдеров от 2 серверов доступа но как тогда резервировать коммутатор узла (в котором под разным соусом и вланом но торчит всё, если он большой и очень умный) в случае кошачьего каталиста 65хх ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 29 марта, 2009 · Жалоба резервировать бэкапом настроек, железками нка складе, круглосуточной аварийной службой Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mousus Опубликовано 29 марта, 2009 · Жалоба большой понятно, а если "маленьких и много" ? тоесть конечно понятно что пытаться резервировать каждый порт, и точрчащий в нём сервер малость параноидально, но всёже кроме "дяди васи" на дежурстве с такимже коммутатором в одном кармане и конфигом в другом кармане как можно подстраховаться Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 29 марта, 2009 (изменено) · Жалоба Для начала подумайте, что можно отрезервировать, а что - нет. И сколько это будет стоить, исходя из этого стройте ваши планы. Изменено 29 марта, 2009 пользователем sdy_moscow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 30 марта, 2009 · Жалоба но как тогда резервировать коммутатор узла (в котором под разным соусом и вланом но торчит всё, если он большой и очень умный) в случае кошачьего каталиста 65хх ? Как раз в этом случае проще всего))) 2БП, 2 супервизора и запасной линейный модуль на складе))) Правда от пожара не спасёт, ибо нет географически распределённой схемы))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...