Paxton

Что значит не совсем? ;) Значит, что функциональность ISG-софта на ESR'е, основанном на PXF, не совсем идентична ISG IOS'у, доступному на софтверных платформах (той же 7201/7301). Кстати, там от конфигурирования Etherchannel оно уже не падает или все так же, как раньше? :)

Лучше или хуже - вопрос метафизический или даже религиозный. Но, to be honest, - жуниперы работают вполне сносно напрямую с RADIUS'ом без SDX/SRC-PE. Опять же ISG на ESR-е - это как бы еще не совсем ISG...

ERX-310 и E320

Что, так спамом с обратным адресом president@whitehouse.gov и приходят? :) Про ДСЛ часто вообще забываю. ;-) Может и зря - но как-то брр... :-) Из перечисленного, технически все сводится к одному - есть CPE, причем весьма умное, часто многопортовое. До сих пор важность этого отличия мне не так бросалась в глаза. Самое главное в вышеперечисленном в том, что для DSL-щиков CPE легко интегрируется в S-VLAN модель предоставления услуги. С точки зрения пользователя вообще мало что изменяется при подключении новых услуг, разве что мыльницу нужно приобрести с большим числом дырок, чтобы в них повтыкать STB и IP Phone. Ум, кстати, DSL-евской мыльнице сильно большой не нужен, в отличие от Ethernet-овской (см. проблемы C-VLAN). Если бы не было проблем с мультикастом, с этим заморским трипл-плеем вообще бы проблем не было и вся страна уже давно называлась не родиной слонов, а родиной победившего трипл-плея :) Тут опять проблема возникает проблема конфликта понятий:C-VLAN и S-VLAN - это схема доставки услуг до потребителя - грубо говоря количество VC и VLAN на пользователя/услугу. В то же время PPPoE или IPoE (которые также бывает DHCP или Static), не считая еще всяких PPTP и L2TP - это уже схема предоставления конкретной услуги. Поэтому PPPoE сам по себе не может помешать C-VLAN-у стать C-VLAN-ом, так же как C-VLAN не может помешать PPPoE :) Может быть все же перечисленные ниже проблемы не зависят от модели, а общи для обоих вариантов? ;-) Вот как раз-таки, как говорят в Одессе, имеем две большие разницы.Если удается впехнуть себе в сеть S-VLAN модель - то проблемы CPE как бы уже и нет. Сверху у нас столько интерфейсов сколько услуг - значит CPE - L2 устройство, адресация раздельная для каждой услуги - какую хотим, такую и воротим. Фактически это как раз тот геморррой, который плющит техсаппорт ДСЛщиков. ;-) И который никак не стоит весить на себя... Не совсем так. Ничто не мешает промышленным способом преднастроить простое CPE. Но если требуется настройка внутренних сетей, причем в нескольких комбинациях услуг - вот тут уже преднастройка будет сдавать сбои.Именно потому, что приходится городить сложную схему на CPE, возникают сложности с ее преднастройкой, провижионингом (гвоздь бы забить в голову тому, кто придумал это слово, попроще не могли никак обозвать) и поддержкой. А у DSL-щиков разве сложные CPE? По-моему, лет 5-10 назад это называлось Translation Bridge и было всем известно и понятно. Думаю за это время все не сильно усложнилось. Так что, если что и плющит нормальных DSL-щиков, то точно не проблемы с CPE. Им, кстати, в силу прямой связи DSLAM-CPE, им гораздо проще мониторить состояние канала до абонента, что упрощает траблшутинг. Ну в принципе альтернатив эзеру на сегодняшний день немного и в российских реалиях даже этим немногим альтернативам приходится туго. Что там имеется - DSL (проблема - скорость), PON (цена), wireless всех мастей в расчет пока не берем, похоже не созрел он еще для нормальной услуги.DSL разгоняет AT&T (в частности SBC) - посмотрим, что у них выйдет с их проектом U-verse. PON - уже даже в России его пытаются внедрять - тоже посмотрим. Пока самые радужные перспективы на доступе у эзера. Проблема мне видится не юзерском порту, а выше, в оборудовании доступа-распределения провайдера. Если из них выкинуть всякие ARPы и MAC-learning'и, добавить к транкам Fast Reroute и при этом не изменить их цены - вот в чем, на мой взгляд, должно заключаться развитие операторского железа. P.S> Не могу не поздравить все прогрессивное человечество, пережившее первую волну праздников!

Тут надо заметить, что на авторство не претендую. Будем считать, что я просто мимо проходил :) А про subscriber - специально написано, чтобы было понятно, что не расшифровка термина, а объяснение другими словами ;) Кто кому будет заказывать? ;-) Наверное нужно спросить там же, где брали в предыдущий раз. Я думаю в Хунипере все не только уже написано, но и переведено на великий и могучий ;) Собственно, я к этому и вел. Если ориентироваться на решение от вендора, надо понимать, что он скрывает, как и почему двигаются конкретные подходы. S-VLAN - вроде как для DSL-щиков видится вариантом нумбер ван. Почему? - проблемы с security уже давно решены на DSLAM-ах, современный DSLAM все прекрасно заизолирует - легко подать несколько VC/VLAN-ов до абонента - снимается решение великой дилемы L2/L3 CPE - отдельные интерфейсы, стало быть L2 CPE прекрасно все сбриджует. - можно даже поиграть в DSL-евский QoS между VC. - легко разделяется организация простого интернета и дабл-трипл-плея - просто продаются разные CPE А для Ethernet-прова S-VLAN - это действительно большой геморрой с неизвестными бонусами: - нужны домовые коммутаторы со всем фаршем port security, private vlan, dhcp snooping, static arp/arp snooping и т.д. А это как все понимают - деньги - пользовательский порт - транк (!). Вот уж чего не хватало домохозяйке, которой нужен только интернет, так это поиски и настройка CPE. Простая услуга должна предоставляться просто. Если нужны малтиплеи - тогда уже идут в ход CPE и т.д. - снижается число используемых VLAN/MAC-адресов, так у современного оборудования вроде как выправили эти проблемки. Опять же с ограничениями, но решаемыми. Кроме этого еще мультикастовые проблемы (поддержка снупингов из вланов различной степени теггированности, распространение mcast-a по метро-сети). Но с мультикастом проблемы по большей части общие (с вариациями) у всех схем. C C-VLAN-ом есть не такие уж и небольшие сети (собственно, я не видел еще ни одной Ethernet не-C-VLAN сети). Хотя, как тут уже отмечено, рекордсмен в России пока работает на S-VLAN модели. Но не стоит забывать, что у C-VLAN модели есть и проблемы... - Все-таки мыльница L2 или L3? Если L2 - то как выдаются адреса ТВ, IP-фону? Пров держит базу MAC-адресов и DHCP-шит по ней? Выглядит не ахти, не правда ли? Или не держит и все сервисы доступны любому устройству (ломайте, гости дорогие)? Как организовать доступ нескольким ПК в интернет? Несколько PPPoE сессий или DHCP адресов? А BRAS от количества сессий не порвется? DHCP адреса выдавать по какому принципу? Всем белые, включая STB и телефоны? Или опять базу MAC-адресов китайский адаптеров держать? Ну и т.д. Если L3 - то это NAT, сразу будут домохозяйки с low-id емулями и прочей недовольностью. Опять проблемы с выдачей адресов - да есть CPE с DHCP Proxy, но фактически все выливается в управление и поддержку пользовательскими CPE. Это как раз то, о чем мечатет любой оператор - еще несколько тыcяч девайсов на его NOC. L3 для value added services и L2 для интернета - ну и сколько этот монстр будет стоить? и называться будет что-то воде cisco 1821? :) - PPPoE или DHCP Интернет? С PPPoE вроде бы все замечательно - всегда известно, когда совершеноо подключение, когда отключение, RADIUS, все дела. Но для IP TV все равно нужен DHCP, так почему же все сразу на нем не сделать? DHCP - замечательно, мы это сделали. А теперь у нас перезагрузился BRAS. Сколько там у нас DHCP Lease? Часы, дни? Когда, значит, к нам пользователь-то без посторонней помощи вернется? :) Потом еще куча вопросов с резервированием у всех схем. Ну и так далее. Чем дальше в лес, то бишь в трипл-плей, тем толще партизаны... Похоже пока MPLS-like технологии в усеченном виде не проберутся в коммутаторы не будет счастья Ether-оператору. Сейчас, вроде как, активно ведется работа в этом направлении - хотя бы тот же Nortel с его PBB/PBT (или как там его правильно) и IEEE 802.1ah со товарищи. Но это же не означает, что нужно накрываться простыней и ползти на кладбище. Что-нибудь придумать наверняка можно. Перефразируя Козьму Пруткова - что один человек сломал, другой завсегда построить сможет :) P.S> Почитал сколько понаписал - жуть. Слава богу, хоть читать наверняка никто не станет - многа буков :)

Гость, это ты глючишь. Терминологию правь. ;-) Ну или под Джуниер подстраивай. Я дико извиняюсь за вторжение в вашу беседу. Но называть сие терминологией Джунипера я бы не стал. Ибо в то время автор бумаги весьма путался в C-VLAN и S-VLAN моделях, что подтверждалось в личных беседах. Так что бумажка представляла собой не особо творческий перевод на русский + немного авторского колорита в виде, например, Shared VLAN-ов. :) Действительно, у Хунипера есть упоминание в документах и презентациях термина Shared VLAN. Но вот обычно в каком контексте: "S-VLAN - shared VLAN per service. С-VLAN - VLAN per subscriber". Видимо, тогда все смешалось после быстрой смены вендоров в голове у автора - Алкатель и Джунипер, и наоборот. Опять же тогда самым писком было рассуждение о Shared Shaper-ах на Е-серии ;) А чтобы узнать правильный перевод - достаточно загуглить. Сайты с ieee и itu в названиях точно дадут авторитетный ответ. P.S> Кстати бумага устарела. Надо бы вам заказать написание новой. Ибо с тех пор у Juniper появился настоящий коммутатор (коммутатор сделанный из Т-серии - это марка!). А значит, раз есть коммутатор и S-VLAN модель не так уж плоха (ну хотя бы для DSL-щиков), да и Single Service Edge - не всегда самая удачная концепция. Железо нужно продавать, значит просто необходима новая концепция :)