У кого-нибудь есть опыт работы с оборудованием от Nortel?

[Qsko]

Больше интересует вопрос что выбрать для пострения домашней сети, с планом на будущее. Пришёл к 2-м вариантам: либо Cisco в уровень агрегации и ядро впихнуть, либо разобраться с Nortel (после прочтения статьи про Ethernet, кроликов и деревья).

 

Буду очень благодарен за любую литературу по оборудованию Nortel, а особенно за статьи про то, как в Nortel видят построение MAN.

[Nailer]

Qsko, щас Прохожий прибежит ;-)))

 

 

Ну а пока его нет, почитайте топик http://forum.nag.ru/viewtopic.php?t=9953&s...0&postorder=asc

[Qsko]

Nailer, ой спасибки. А то зашёл и растерялся...

[Прохожий]

Nailer, не поминайте всуе! Что значит прибежит? С остоинством появится - это более адекватно.

 

Qsko, киньте координаты в личку, пришлю инфу. Что же касается Нортела вообще, буквально с Вами рядом есть товарищ, у которого его стоит изрядно, хотя и не в MAN, а в корпоративной сети, но одного семейчтва, известный под ником repa, поспрошайте у него по опыту эксплуатации :)

[Nag]

Не, ну зачем в личку-то?

Многим интересно. ;-)

[Qsko]

Прохожий, сегодня перечитал весь топик "Nortel vs Cisco". Долго ломал голову, где это у нас Нортел стоит и кто такой repa. Сперва подумал что это наш админ, но у нас фанат Cisco. :)

[Прохожий]

Не, ну зачем в личку-то?

Многим интересно. ;-)

 

У меня нету нынче настроя на 10 страниц флейма :) Зато есть много мегабайт информации :)

[Nag]

А ты мегабайты мне... Статьей.

;-)

И никакого флейма.

[Прохожий]

Прохожий, сегодня перечитал весь топик "Nortel vs Cisco". Долго ломал голову, где это у нас Нортел стоит и кто такой repa.

Нехай от сам объявится :)

Сперва подумал что это наш админ, но у нас фанат Cisco. :)

Бееееедненький!

[Qsko]

1. Спасибо Прохожему за инфу. Покопались, мануал на англом конечно не одолели, но с другими доками постарались как могли :)

 

2. Так понял, что в технологии NORTEL весь сетевой трафик идет через некого оператора, т.е. фактически через ядро. А как справляется NORTEL, когда трафик генерируется несколькими тысячами юзеров?! Ведь канал мах 1+1 Gb?

- 2.1. Т.е. мы имеем по 336 абонентов (в 1 кольце), полностью загружающих свои законные 100 МБит. В кольце всего можно вместить 14 устройств MESU. Итак-с, как теперь всё это должно работать?

- 2.2. Трафик между соседними абонентами в пределах одного MESU, как я понял гоняется через Passport, т.е. через центр сети. Так? Если да, то как быть, когда соседи по подъезду в нескольких домах начнут перекачивать друг у друга вечером примерно в одно время новые фильмы? По приблизительным рассчётам у них должна быть ну просто никакая скорость, а именно где-то 3-5 Мегабит.

- 2.3. В принципе то же самое можно реализовать и на CISCO. Тогда какой смысл брать NORTEL? Берём Циски, руками прописываем что отправлять трафик от пользователя только в вышестоящий коммутатор (маршрутизатор) и всё. Проблема решена. Причём в таком случае будет 2 ньюанса: 1) коммутаторы уровня доступа будут соеденины напрямую с маршрутизатором, т.е. топология звезда. Тогда 1 Gb будет делиться между 24 портами 1-го коммутатора, т.е. выигрываем в скорости. 2) От одного маршрутизатора можно пустить 24 или 48 линий по 1Gb к коммутаторам без всяких колец. Для домашней сети здесь большой надёжности не надо, а вот в скорости выиграем, не потеряв в управляемости. Такое решение может выйти дешевле Нортеловского. Плюс не забудем про скорость.

 

3. Кстати, есть теперь какая-нибудь разница между маршрутизаторами и управляемыме коммутаторами 3-го уровня?

[Nag]

Ох-хо...

Под многое создатели заточили нортел.

Но вот предусмотреть возможность такой халявы да... Не смогли. ;-)

[Guest]

Qsko

По поводу 3-го вопроса: Да, есть и большая.

[Прохожий]

А ты мегабайты мне... Статьей.  

;-)

И никакого флейма.

 

Вах, это же садиться надо и проиводить все в приемлимую для публикации форму. А это не цигарку выкурить... Однако времени требует немало...

[Прохожий]

1. Спасибо Прохожему за инфу. Покопались, мануал на англом конечно не одолели, но с другими доками постарались как могли :)

На здоровье!

2. Так понял, что в технологии NORTEL весь сетевой трафик идет через некого оператора, т.е. фактически через ядро. А как справляется NORTEL, когда трафик генерируется несколькими тысячами юзеров?! Ведь канал мах 1+1 Gb?

В каждом кольце - 1+1, но это не магистраль, это именно КОЛЬЦА ДОСТУПА. Магистраль - это уже то, что между PP8600, а там может быть от 1G до Nx10G, ну и всякие CWDM не возбраняется применять.

Слухи о прожорливости абонентов сильно преувеличены...

 - 2.1. Т.е. мы имеем по 336 абонентов (в 1 кольце), полностью загружающих свои законные 100 МБит. В кольце всего можно вместить 14 устройств MESU. Итак-с, как теперь всё это должно работать?

"средняя температура по больнице" получается действительно невысокая, но это за счет учета морга. Вот вопрос: У Вас хоть один юзер есть, который 100М канал грузит на 80% в течение времени более нескольких минут?

Еще раз: Слухи о прожорливости абонентов сильно преувеличены...

- 2.2. Трафик между соседними абонентами в пределах одного MESU, как я понял гоняется через Passport, т.е. через центр сети. Так? Если да, то как быть, когда соседи по подъезду в нескольких домах начнут перекачивать друг у друга вечером примерно в одно время новые фильмы? По приблизительным рассчётам у них должна быть ну просто никакая скорость, а именно где-то 3-5 Мегабит.

Есть такое понятие: вероятность. Какова вероятность того, что 168 пар юзеров одновременно начнут качать, причем строго попарно? В математике, конечно, есть такие числа... Наверное. Но вообще-то принято говорить "ассимптотически стремится к нулю"

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

 

Впрочем, если Ваша цель - обеспечить абонентов бесплатным пир-ту-пир сервисом - тогда конечно...

- 2.3. В принципе то же самое можно реализовать и на CISCO. Тогда какой смысл брать NORTEL? Берём Циски, руками прописываем что отправлять трафик от пользователя только в вышестоящий коммутатор (маршрутизатор) и всё. Проблема решена. Причём в таком случае будет 2 ньюанса: 1) коммутаторы уровня доступа будут соеденины напрямую с маршрутизатором, т.е. топология звезда. Тогда 1 Gb будет делиться между 24 портами 1-го коммутатора, т.е. выигрываем в скорости. 2) От одного маршрутизатора можно пустить 24 или 48 линий по 1Gb к коммутаторам без всяких колец. Для домашней сети здесь большой надёжности не надо, а вот в скорости выиграем, не потеряв в управляемости. Такое решение может выйти дешевле Нортеловского. Плюс не забудем про скорость.

Ключевая фраза - "прописываем руками". На каждом порту. Подумайте над этим.

 

Не только Cisco, есть еще десятки вендоров.

 

Если Ваша цель - только IP-доступ в Инет и к файлопомойке - то да, но берите лучше делинк, то же самое, тогда точно дешевле получится.

 

3. Кстати, есть теперь какая-нибудь разница между маршрутизаторами и управляемыме коммутаторами 3-го уровня?

Обычно так:

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

 

Маршрутизатор: максимальная функциональность по обработке на L3, но в большей степени программная реализация. Больше гибкость, ниже скорость.

 

Сухой остаток

Стоит понять, что решение Nortel - это сеть доступа на базе Ethernet, не больше и не меньше. Все, что она может сделать сама по себе - это L2VPN. Ее задача - сделать полностью подконтрольную передачу пакета из точка А в точку В, причем любого пакета, похожего на Ethernet. Это скорее аналог MPLS на уровне 2, чем Ethernet. Да, в такой парадигме где-то клиента надо терминировать. По версии Nortel на каждые 30-50 тысяч абонентов (или меньше, если это бизнес) надо ставить что-то типа SER 5500, на котором делать абонентам сервис. Да, получается что каждый абонент имеет персональный "виртуальный канал" к терминирующему устройству B-RAS. Да, пир-ту-пир в этой модели вызывает нагрузку на магистральном участке до терминирующего устройства.

 

С точки зрения одной частной задачи - IP-connectivity, есть масса более эффективных решений. С точки зрения работы одной сети на ряд задач, из которых означенная выше - частная, причем не самая доходная, получается совсем другой расклад. То есть если Вы не рассматривали задачу организации MPLS ядра сети в рамках решения на Cisco - значит и решение Nortel Вам не нужно.

 

В кратце на Nortel делается следующее:

1. Территория накрывается сеткой OESS (PP8600 + MESU 18xx + OM1xxx), с помощью одной только этой сети бизнесу дается L2VPN как услуга объединения сетей.

2. На эту же сеть заводятся xDSL концентраторы (для последней мили по меди)

3. Исходя из разумного понимания расставляются B-RAS, для которых L2VPN является "последней милей" к абоненту. BRAS делает IP-сервиc для каждого абонента, считает, защищает и опекает. Один BRAS на 30-50К абонентов.

4. Мультикастовый сервис делается прямо на OESS, через BRAS не ходит.

 

Почему так? Будете удивлены, но в операторских сетях трафик частников меркнет перед трафиком VPN разного вида. И потому очень быстрый и дешевый транспорт уровня 2 очень полезен, потом уже на него кладут IP.

 

Описанное же вами решение не даст НИЧЕГО кроме IP-connectivity, потому что Вы не сможете масштабировать его на L2 ввиду "врожденных пороков" Ethernet, а как только начали маршрутизировать - сразу потеряли услугу VPN, кроме, разве что, использования GRE, что не назовешь ни красивым ни простым решением.

[Qsko]

"средняя температура по больнице" получается действительно невысокая, но это за счет учета морга. Вот вопрос: У Вас хоть один юзер есть, который 100М канал грузит на 80% в течение времени более нескольких минут?

Предполагается, что трафик внутри дома будет бесплатным или почти бесплатным, отсюда и резкий скачок температуры внутри кольца. Так как быть в таком случае, или это "вне концепции Нортела"? Т.е. есть всё, но такого пиринга не будет.

 

Первый же вирусный шторм заколбасит Вашу сеть не по детски. и еще раз: Слухи о прожорливости абонентов сильно преувеличены...

Хм, нашу институтскую сеть не колбасит, хотя из неё выжимают все соки, а пользователи в ней сидят на 100 Мегбитах - грамотный админ рулит! Т.е. всё, что идёт через обенные диски проверяется на вирус, заражённые подсети блокируются автоматически. У Нортела есть такие механизмы? Кстати, где бы про его механизмы обеспечения безопасности почитать?

 

То есть если Вы не рассматривали задачу организации MPLS ядра сети в рамках решения на Cisco - значит и решение Nortel Вам не нужно.

До ядра пока не дошли. Сегодня пересчитали всех потенциальных "клиентов" (если так можно выразиться :-) ), прикинули какие расстояния и чердаки нас ждут. Ядро планируем разбирать где-то со среды. Не могли бы подкинуть инфу про организацию ядра сети?

 

Стоит понять, что решение Nortel - это сеть доступа на базе Ethernet

Так что с ядром посоветуете делать?

[Прохожий]

Qsko,

Пиринга не будет. Все механизмы безопасности - вне решения, поскольку ее надо делать на L3 а здесь L2 и задача одна - предсказуемый транспорт. Безопасность вся делается на сервисном узле, в случае Nortel это SER 5500. Там хоть антивирь поточный - любой каприз за Ваши деньги. Причем, немалые :)

 

Что поделаешь, OESS - это сеть для L2VPN, которая являтся суть сетью доступа для других услуг, и ничего кроме L2VPN не делает, хотя именно их делает очень хорошо, намного лучше чем кто бы ни было другой. Объективная реальность. А дальше можно это использовать, иметь очень стабильный и предсказуемый L2 транспорт и поверх него организовывать L2/L3 услуги, а

можно сказать, что так не годится и строить чистый IP на Cisco/Dlink ну или тех же ентерпрайз свичах Nortel (семейство BayStack). Других вариантов нет :)

 

Для фактически любого размера города ядро в случае OESS - это просто ряд каналов между теми же PP8600, на крайняк несколько PP8600 в варианте "Enterprise" для связки между агрегаторами, и дальше выход на глобальный MPLS с помощью OpteraMetro 8000 (суть тот же PP8600 по железу на самом деле :) или сервис+MPLS с помощью SER 5500. Ну, для эстетов могу предложить RPR на скорости 10G :)

 

Согласен, отсутствие P2P прямой коммутации - это весьма непривычно для домашних сетей, но для связистов это вполне нормально. Не забывайте, что QoS и гарантированная полоса - вещи относительные, я бы даже сказал статистические. Три сотни абонентов шарящие гигабит будут иметь вполне приятную скорость работы, в IP сетях oversubscription 1:300 имеет право на жизнь, более того, оправдан, ибо при больших пиках реальная средняя потребность мала до неприличияn и исчисляется сотнями килобит.

 

Желание построить "полностью неблокируемое" и "честные 10 мегабит на абонента" я целиком списываю на юношеский максимализм. Если бы сети связи так строились, телефон до сих пор был бы элитным прибором, доступным узкой прослойке толстосумов.

 

А вообще занятно: к этому решению все пытаются подходить со стандартным калибром обычной Ethernet сети :) Где тут у нас L3 свич? А как ограничивать даунлинк?

 

В то время как это совсем иное решение... В частноси, ВХОДЯЩИЙ в сеть трафик надо ограничивать. Даунлинк - он ограничивается на сервисном узле. Все, что вошло в сеть - надо передавать. Другая идеология, не лучше и не хуже, просто другая... Которую бывает довольно трудно понять.

[Qsko]

Другая идеология, не лучше и не хуже, просто другая... Которую бывает довольно трудно понять.

Вот этим и занимаемся на текущий момент :)

[vIv]

Простите, ограничивать входящий или вошедший?

Если вошедший, то получается "заплатили за трафик и подропали его вместо доставки потребителю".

А входящий - зачем его ограничивать? Пусть идёт, он же заказан и оплачен? Пока канал может передавать, пусть передаёт.

[Прохожий]

Простите, ограничивать входящий или вошедший?

Если вошедший, то получается "заплатили за трафик и подропали его вместо доставки потребителю".

А входящий - зачем его ограничивать? Пусть идёт, он же заказан и оплачен? Пока канал может передавать, пусть передаёт.

 

Вот в том и дело, что входящий от абонента трафик должен быть ограничен теми рамками, в которых он "оплачен". Если Вы собитаетесь раздавать порты-десятки, это ограничение получается автоматически. Но при этом ограничение общее. В данном случае модель более гибкая: есть общая полоса, нарезаемая с кратностью 1М и три значения CIR по трем классам трафика. Дальше - определенная логика трансляции маркеров QoS абонента в маркеры QoS оператора, причем в пределах каждого CIR по видам - трансляция, превышающий трафик - трансляция в более низкий класс.

[vIv]

от абонента - ДА! Тремя руками за!

Чем бы ещё? Это можно делать на уровне доступа? Модели?

[Прохожий]

от абонента - ДА! Тремя руками за!

Чем бы ещё? Это можно делать на уровне доступа? Модели?

 

Дык, в общем здесь такой способ обработки трафика доступен на каждом абонентском порту... Один общий CIR, и 3 CIR по классам плюс полисеры и классификация по 801.1p и DSCP. Превышение класса EF дропается, превышение AFx обрабаывается как BE, BE в пределах остатка общего CIR от фактического трафика более высоких классов.

[vIv]

от абонента - ДА! Тремя руками за!

Чем бы ещё? Это можно делать на уровне доступа? Модели?

 

на абсолютно любых коммутаторах?

[Прохожий]

от абонента - ДА! Тремя руками за!

Чем бы ещё? Это можно делать на уровне доступа? Модели?

 

на абсолютно любых коммутаторах?

 

Это делается на связке PP8600/MESU1800. На байстеках такого нет, ибо это есть железяки для LAN.

[vIv]

Спасибо!

[Прохожий]

Спасибо!

 

Да не за что!

 

Кстати, последний штрих: когда трафик отдается из операторской сети абоненту, на пакетах стоит ОРИГИНАЛЬНАЯ абонентская маркировка, с которой он вошел в операторскую сеть, а все описанное выше - это маркировка оператора, с которой он обрабатывается на операторской сети. Все это за счет "полной" инкапсуляции MAC-in-MAC. Таким образом, образуются абсолютно изолированные пространства QoS абонента и оператора и на входе по сути происходит трансляция одного в другое.

 

Аналогично, абосолютно изолированы пространства MAC адресов - ядро оператора НЕ РАБОТАЕТ с МАС абонента. Вообще. А работает с МАС, назначенным UNI (ака абонентскому порту).

 

Размер МАС таблиц на ядре определяется исключительно количеством UNI, и изменяются эти таблицы только при добавлении UNI, то есть новых устройств или активации сервиса на порту существующих. То есть предел МАС - это количество абонентских портов, а не суммарное количество хостов в сетях абонентов. Отсюда же возможность дублирования MAC у разных абонентов - пофигу, не беспокоит и к траблам не приводит.