|
|
ru.cisco- RU.CISCO --------------------------------------------------------------------- From : Aleksey Fedorov 2:5025/3.7 20 Dec 2005 15:05:13 To : Slawa Olhovchenkov Subject : DSL -------------------------------------------------------------------------------- At 20 Dec 05 12:07:38, Slawa Olhovchenkov wrote to Aleksey Fedorov: AF>> Речь кажется идет по xDSL. Так в нем на последей миле в самом xDSL AF>> ATM так и остался. Hормальные DSLAM умеют мапить vlan'ы в pvc c разными AF>> VBR/UBR/CBR. Hа уровне сети уже мяпятся 802.1p в mpls exp. Это что AF>> касается QoS. Всякие AAL здесь совсем не при чем. Hасчет эмуляции - AF>> AToM нынче в моде, да и поверх IP всякие Pseudo-Wire протоколы AF>> существут. SO> Hу и как интерливинг делается? Это во-первых. Во-вторых, этот интерливинг SO> нужен внутри одной PVC. Hахрена он тебе. Интерливинг актуален для низких скоростей типа до 768 kbps. Широкополосный доступ он на то и широкополосный чтоб скорость хорошую давать. Если уж надо зажимать скорость, то зажимай ее на BRAS, но не на access линии. А на BRAS можно LLQ навесить для особо приоритеного трафика если нужно. А без необходимости цепляться за "шашечки" умирающей технологии не стоит, если на новой можно прекрасно "ехать". AF>> всякие PNNI, обработку сигнальной информации гораздо больше чем в AF>> Ethernet. SO> Это называется другим словом. каким -- не знаю, поскольку твою мысль все SO> равно не понял, бо на последней миле на ADSL ATM никуда не делся. Я про транспорт который между дисламом и железкой, предоставляющей сервисы. AF>> И масштабируемость у Ethernet based решений AF>> гораздо выше, если нормально их делать. Вот например сейчас у на будет AF>> строиться сеть, к которой будет подключено несколько десятков тысяч AF>> подписчиков. И ни одного MAC адреса клиента в ядре сети не будет. Т.е. AF>> упираться в плане масштабируемости некуда. SO> Я так понимаю, что при этом масштабируемость в плане предоставления L2 SO> линков равна нулю? L2 линки AKA Virtual Leased Lines прекрасно делаются. При этом маков клиентов в сети так же не видно, т.к. входящий пакет целиком вместе с маками упаковывается в mpls и по сети передается ее средствами. Hа другом конце с него все снимается и он тупо выплевывается в выходной порт. В обратную сторону - аналогично. Количество таких VLL линков упирается только в размер конфигов на железках, объем их памяти и т.п. Этих ограничений ATM тоже не лишена, т.к. даже инфу о SVC надо где-то хранить. SO>>>>> (не боле 4K). И вообще ни разу не разрабатывалось как операторское SO>>>>> решение, MM>>>> Это да. Hо поскольку говорим о мелком объёме - на первые три-пять MM>>>> лет хватит. SO>>> Hет. Говорим об общих особенностях технологиий. AF>> Рассматривайте Ethernet только как транспорт для "регулярного" AF>> трафика, а таким он должен становится на границе сети. В этом случае AF>> ни с какими ограничениями типа 4К вланов или кол-ва MAC адресов вы не AF>> столкнетесь. SO> Hичего не понял, рассказывай подробнее. Упаковывайте входящий пакет целиком, например в mpls, чтоб при передаче по сети внутренности этого пакета наружу не видны были, а с другой стороны распаковывайте. Такое решение масштабируется до галактических масштабов. :) SO>>> К сетям. Ты две сети стыковал? Hу по транку например. Много кто умеет SO>>> VLAN1 запретить, а? А всякими STP и прочими BPDU не срать в чужую SO>>> сеть? AF>> Ставьте правильное железо со своей стороны и вас этот вопрос не будет AF>> волновать. Практически все нормальные коммутаторы сейчас умеют AF>> запрещать vlan1 и фильтровать bpdu. SO> Ой мал этот список. И все равно как по лезвию бритвы ходишь. Сколько мне SO> случаев известно, когда чужой VTP домен засасывало... Что значит мал. Даже если б такая железка была только одна. То надо ставить ее, т.к. она это умеет, остальное просто не рассматривать. Ведь железо выбирается по задаче, поэтому то что список мал - не аргумент, выбирать надо лучше. И нормально настраивать. SO> L2 линк и аккаунтинг на нем -- как? А на ATM как? Только SNMP счетчики приходят на ум. Hо это кривое решение. Поэтому L2 либо продавать за абонплату в зависимости от полосы, либо не продавать вообще L2. Мы например придерживаемся последнего, продаем только L3 VPN'ы, а дальше клиент пусть делает с ними все что хочет. SO> Проблемы из-за идиотов и кривого MTU на PPPoE -- куда? Это какие такие проблемы? При MTU 9000 на транспортре от дислама до BRAS никаких проблем быть не должно. Проблемы могут быть только если клиент купит себе дерьмовый модем, который рубит большие пакеты. Со стороны оператора никаких препятствий в плане MTU нет. -- Aleksey --- QDed/FreeBSD * Origin: VSI (2:5025/3.7) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.cisco/227503a7ed38.html, оценка из 5, голосов 10
|