derini

1) 4350 выдержит 2 фулла легко при одинаковом количестве памяти. 6350 держит 4 фулла с гигом памяти. 2) да 3) им сессии плодить не надо, это не наты 4) врут. они про isg2000 это только рассказывают 1) в общем да 3) в предположении что они ещё и натят 4) isg2000 успешно провалился на тесте и был намертво завален потоком в 350 мегабит коллегами из ниеншанца, в ответ на что джуниперовцы рекомендовали как раз 6350 как вариянт который де справится (врать не буду, ещё не проверяли, говорю со слов их инженерной службы)

J6350 отличается от 4350 таки неслабо 1) j6350 выдержит 2 fullview, а вот 4350 никак, так что планируете 2 аплинка - про 4350 забудьте 2) на усреднённых пакетах в самом плохом случае 4350 даст 550-600 мегабит, 6350 вытянет честный гигабит 3) скорость с которой они способны плодить сессии - 4350 по моему 10к/сек, 6450 - 20к/сек 4) таки 6350 способен на скорости в гигабит способен ещё и натить, буквально на днях начальник системных инженеров джунипера клялся и божился что на гигабите будет натить без проблем а вообще решение простое, идите ка вы к интегратору какому нить (вимком, поплар, нетвелл) и заказывайте обе модели в тестирование, они такое делают без вопросов да ещё и инженера своего пришлють который всё шо надо настроит AT-x900-XT/S - уточните что именно вы с его помощью делать хотите? про циску врать не буду ибо не знаю

отвечу выдержкой из анализа проведённого специалистами junper'а про то, почему DHCP это плохо: 1) Плохая утилизация адресного пространства 2) Плохая авторизация (Option 61, Option 82) 3) Отсутствие keepalive 4) Отсутствие OAM 5) Невозможность выдать подсеть 6) IP уровень усложняющий резервирование 7) Усложняет переход на IPv6 8) Сложность контроля безопасности 9) Нет поддержки "wholesale" А вот выдержки из мнения специалистов DSLF, о том почему DHCP это плохо: Критичные недостатки 1) No "Per subscriber authentication" 2) No "Per subscriber state" 3) No "Per subscriber wholesale/vpn selection" полукритичные: 1) No "Subscriber separation" 2) No "Per subsriber multicast state, BW and Control"

на память у него 96 Gbps фабрика и шо то около 70 Mpps - 4-5 тыщ станций без вопросов пережуёть...телесинки вообще очень достойное и сильно недооценённое в нашей стране железо

туда же добавить Edge Core ES3528M, ES3526XA, ES3526YA, Opticin OS-242, ZTE 2626A, ZTE 2928, Planet FGSW-2620VS, Planet SGSW-2840, Linksys SRW224G4, Linksys SLM224G и DC DCS-3950-26C - вот тады будет цельная картина

вот о том то и речь что зверя не аутентифицируем тьфу-тьфу....бог миловал, мы сразу нормальное покупаем, тем более что у мну стойкая нелюбовь к кошкам

разделите на два сервантуса, на одном NAT и BGP, на другом PPPoE и PPTP - тогда и мегабит 300 выжать можно

а) преимущество кажущееся, вы аутентифицируете не абонента а своё оборудование и это плохо, это идеологически неправильно и повышает опекс б) согласен, это плюс, но актуально только в случае фтыкания кабеля непосредственно в комп абонента, мы от этого уже отказались ж) неправильная мысль, она кажется хорошей тока пока сеть маленькая, на большой сети выгодно поднимать функции фильтрации и IDP (вплоть до оганизации statefull firewall и IDP 2-7 level) в ядро сети на уровень аггрегации кастомерских вланов, так оно дешевле выходит при большой сети, например, сэкономив на узлах доступа по 100 баксов (учитываем не только стоимость железок но и опекс на их обслуживание и настройку), на сети из 1000 узлов доступа имеем возможность на эти денюжки прикупить серьёзный IDP (да ещё и останется средствов на что нить ещё в загашнике) и сканировать весь траффик аж вплоть до 7-го уровня буде захотим и резать потоки содержащие всяку каку (автоматом решает проблемы с ботнетами, спамерами, завирусованными абонентами, малолетними кулхацкерами и тд и тп) да ещё имеем в качестве бонуса централизованную базу инцидентов в сети, мы, например, счаз дописываем модуль который на основании данных от IDP поизводит автоматическое информиование зверей о том что у них на компе вирусня/бэкдоры/запчасти-ботнетов живут и инфомирование инженерного состава о попытках DoS/DDoS, bruteforce атаках и тд и тп. ну и IPoE - тут дело даже не в накладных расходах, их то как раз копейки, а в хреновой реализации PPPoE в CPE - не видел пока ни одной железки (промышленные a la AT-AR-xxx не рассматриваю, они то каэшн без проблем справляются) которая на PPPoE дала бы поток выше 65-70 мегабит при средненькой фрагментации траффика (в районе 256-512 байт на пакет в среднем), вот это дейтсивтельно не гуд, потому и жду пока выпустят ip sessions ибо они будут лишены этого недостатка, ибо там инкапсулирования не планируется Опять же продвигаю в головы некую тезу - инвестор всегда прав, он нам работу даёт, если он хочет подешевле и у него нет долговременных планов по развитию сети то мой вариант не катит, он очень затратен в начале (одни затраты на приличный BSR могут некоторых "инвесторов" до инфаркта довести, не говоря уже о затратах на приличный NAT, Firewall и IDP), если он готов вкладываться и ждать окупаемости в течение 2-3 лет и ожидается большая сеть, тогда самое то PPPoE + vlan-per-user - идеологически всё ж таки самый правильный вариант, но имеет очень высокий капекс при условии что не планируется дальнейшее развитие сети и резкое увеличение числа зверей, то:Vlan на дом, изоляция портов + DHCP + PPPoE/PPTP/L2TP централизованные с резевированием дехацепатор, dns и PPPoE/PPTP/L2TP аггрегатор на базе FreeBSD, все узлы доступа сводить на одну железку L3+ уровня (a la AT-9924SP) которая будет DHCP и DNS релеем, ну и ещё один сервак для BGP и NAT

бр...подумали что сказали? в броадкастах захлебнётесь милейший....Какие броадкасты при "вилан на юзера"??? уфф..., судя по всему друг друга не поняли, я уж испугался что было предложено на статике делать l2 сегменты на 16-32к пользователей раздали вы сетку /22 например своим способом, RIPE решил проверить утилизацию пространства, увидел что большая часть адресов не отзывается ибо компы у народа повыключены и возложил на ваш запрос о выделении следующего куска адресов, прецедентов полно с такой причиной отказаБРЕД. Вы клиентские компы не пробовали опрашивать? Ведь ни один не отзовётся, т.к. файрволл уже по-умолчанию включен. И что там проверять?RIPE-организация чисто бюрократическая, и ничего технического проверять не могут. Я так раздал уже /17. Попросили сделать статистику использования адресов. Сделал - их всё удовлетворило. Нет тут никакой разницы, PPPoE на реальных адресах, или IPoE... а вот я знаю случаи что уже отказывают, они счаз стали требовать чтобы в уже выделенных блоках утилизация была не менее 80% перед выделением следующего блока и даже требуют план на предполагаемые сроки освоения с обоснованием почему этот блок надо выделить а терь таки резюме, дабы наша дискуссия не перешла в стадию религиозного спора: PPPoE + vlan-per-user благо ибо: а) Все атрибуты пользователя это логин+пароль, и никаких более б) настройка абонентского терминала почти автоматическая в) заранее, на стадии дизайна сети, решается большой класс секурити проблем г) имеем единую точку дистрибуции и учёта услуг д) имеем практически неоганиченно масштабируемую систему е) низкий опекс PPPoE+vlan-per-user зло ибо: а) высокий капекс б) Некоторое снижение пропускной способности канала зверя в) Тебуется высокая квалификация инженерного персонала терь глядя на вышеописанное имеем, если цель инвестора, как говорится, быстро "отбить бабки" и продать сетку на сторону - схема невыгодна, если цель, построить и эксплуатировать сеть в течение длительного времени в расчёте на её развитие до большого числа абонентов - схема становится весьма привлекательна при готовности инвестора вложить в сеть много денег ещё на стадии проектирования и строительства

бр...подумали что сказали? в броадкастах захлебнётесь милейший.... раздали вы сетку /22 например своим способом, RIPE решил проверить утилизацию пространства, увидел что большая часть адресов не отзывается ибо компы у народа повыключены и возложил на ваш запрос о выделении следующего куска адресов, прецедентов полно с такой причиной отказа Мух с котлетами спутали, предложили на точке дистрибуции услуг знать данные о том как настроено оборудование, а не кто и как подключён, кроме того как вы думаете, в DSLF сидят дураки и они ip sessions просто так разрабатывают, от того что DHCP весь такой удобный и практичный и идеальный и ничё кроме него не канает? =) Опять путаем мух и котлеты - время аренды это время на которое мы зарезервировали адрес за пользователем, а не время пока он фактически работает, а для arp timeout - стоит у мну машинка, никаких пакетов не посылает, вот вам и arp-timeout хотя всё подключено, просто тупо стоит и ни единой датаграммы в канал не шлёт. Ровно по этому поводу в ip sessions собираются внедрить BFD. все на PPPoE, ещё не хватало разные способы авторизации плодить, да и физики уже частенько встречаются у которых не один терминал. Способ дистрибуции услуги должен быть един иначе сразу получаем проблемы с масштабируемостью и резко повышается опекс ну не совсем так....под словом "безопасность" в данном случае надо понимать следующее - "максимально возможное снижение рисков подключения к сети для любого пользователя независимо от типа терминала, настройки терминала и квалификации пользователя" и "максимально возможное снижение рисков для сети от подключения любого пользователя", так что тут не только дизайн но и большой комплекс работ по внедрению и эксплуатации соответствующего оборудования Во, золотые слова, особенно "По мере движения к триппер-плею не исключаю что будет", вот я сразу серьёзные сети и строю, а не пионернет, который потом перестравивать придётся, и сразу кроме инета предоставляю VoIP и IPTV P.S. с классическим ADSL никогда не работал, всю жизнь на ethernet сетях живу. P.P.S. Не утверждаю что PPPoE идеал, просто на данный момент ничего лучшего не придумано, с нетерпением жду лета когда выйдет ip sessions, который должен объеденить лучшие свойства DHCP и PPPoE

я счаз оказываю услуги и строю сети в 10-150 км от москвы и иду туда с московскими ценами и сервисами 1) Статика - попробуйте поработать с большой сеткой на статике, я пробовал, 18к абонентов, не понравилось, 98% времени call-центра занималось консультациями по настройке, кроме того иногда адреса в сегментиках кончались и приходилось их делить, а этио уже совсем геморрой, после этого опыта статику я даже в страшном сне не рассматриваю как основу2) DHCP а) Плохая утилизация адресного пространства - как тока начинаем раздавать реальники становится ужасающей проблемой особенно в свете ужесточившейся политики RIPE в части выделения адресного пространства с требованием утилизации не менее 80% уже имеющегося б) Плохая авторизация, что Option 61, что Option 82 в) Отсутствие keepalive г) Невозможность выдать подсеть, в отличие от PPPoE д) 3 уровень работы а не 2-ой как у PPPoE - резко усложняет резервирование е) Сложнее контролировать безопасность ж) Очень затруднительно организовывать тестирование линии для правильной динамической настройки QoS А это, пардон, задача CPE (Customer Premises Equipment) и никакой другой ноды и маркироваться траффик должен именно на нём, есть мнение что вообще скоро самым правильным способом строительства сетей станет наличие умного BSR, слегка умного DSLAM (что уж под ним ни понимать, хоть классический DSLAM, хоть L2 коммутатор, хоть ещё какую зверушку экзотичную) а между DSLAM'ом и BSR'ом голая оптика на CWDM'е - схема имеет ооочень низкий capex по сравнению с сетью построенной на l3-l2 свитчах. (Про технологии позволяющие CPE и BSR'у правильно учитывать реальную полосу пропускания читайте отдельно, например L2C, OAM) По поводу избыточности полосы - хотите предоставлять действительно качественную услугу - будьте добры организовывать эту самую избыточность заранее, причём избыточность в разы иначе при начале предоставления "тяжёлых" сервисов ваша сеть ляжет, ибо то, чего достаточно для организации "доступа в интернет без гарантий" будет смехотворно мало для организации любого подвида VOD или IPTV Золотые слова, инвестор всегда прав, и если он хочет подешевле, то стройте подешевле Нет, ибо звери продолжают видеть друг друга на 2-ом уровне, а енто не есть гуд и оставляет кучу проблем с внутрисегментным взаимодействием, а во вторых лишает единой точки предоставления услуг - после ентого ищите в сети левые dhcp, vpn и pppoe сервера, proxy, боритесь с broadcast storm, внутрисетевым гулянием вирусов, ищите какие из зверей стали частями botnet'ов и тд и тп, схема vlan-per-user все эти проблемы решает сразу

ASBR если по простому, это режим работы маршрутера када он считает себя бордером, в этом режиме он строит все известные ему маршуты, пытается их аггрегировать по маскам, то есть если есть клиенты с соседними айпишниками он их проанонсит не как два /32 маршрута а как один /31 и так далее, по крайней мере у себя наблюдал как летали ospf анонсы про саггрегированные сетки /21 а вообще самый простой способ - сделать чтобы каждый из насов отдавал свой отдельный непересекающийся с другими пул и поднять discard интерфейсы, потом тупо прописать маршруты на насы статикой, и пускай они сами разбираются есть у него клиент которому надо переправиьт пакет или пакет идёт никому и его надо слить в дискард

это то что до 10к зверей, а на меньшее количество vlan-per-user не нужен имхо, там проще проблемы секурити решать другими способами именно, ради раздачи настроек, DHCP не предлагать, по многим причинам не катит, статика - тем более, остаётся PPPoE, возможно будущий стандарт "ip sessions" будет лучше PPPoE но пока его нет я тоже практик и в телекоме слава богу поболе 10 лет работаю, так что все енти схемы пионернета уже пережил на собственной практике я видимо исключение - инвестор есть и бюджет поболе озвученной выше суммы будет, а кроме того если нет бюджета на развитие - нефиг пытаться городить что либо сложнее dhcp+vpn, там хотя бы на дешёвом гуано можно построить более-менее работающую сеть. А про дешёвые схемы - надоело через пару лет после запуска сети разгребать кучу проблем, из-за того что в начале кому то хотелось сэкономить и построить всё "подешевле"

бр....как всегда народ не думает про умное слово "opex" - посчитайте во что обойдётся эскплуатация вашей схемы с кучей длинков и поймёте что она выгодна пока сеть маленькая, а с нормальным оборудованием аля erx310/e120 и единой точкой предоставления услуги при увеличении количества абонентов "opex" не растут, а вот с длинками или чем то другим ой-ой.... терь собсно по поводу сабжа - схема vlan per user есть идеологически правильная, ибо резко повышает секурити, вопрос по поводу как ея конфигурить - на днях собсно представители из джунипера активно продвигали идею о статической конфигурации вланов на всём оборудовании "ниже" браса и терминировать их на брасе, а собсно автоизацию и настройки раздавать через pppoe - по их мнению такая схема наиболее проста в обслуживании и, в принципе, я с ними даже согласный в ентом вопросе, кроме того такая схема резко упрощает сбор статистики и снимает все вопросы по поводу блокировок/разблокировок абонента вопрос по поводу отслеживания атак и прочая и прочая: 1) во первых схема vlan per user большую часть таких проблем решает сам по себе 2) не смешивайте мух с котлетами - firewall и idp не есть функция узлов доступа (будь то dslam, обычный l2 коммутатор или что-то ещё) или точек дистрибуции услуг, для этого делаются отдельные серьёзные и не очень решения 3) приличную часть решения таких поблем можно по первости возложить прямо на тот же erx310/e120 пока не дорастёте до большого idp - ибо в части policy и всякой фильтрации железки тоже очень могучие, по крайней мере таких иерархических структур которые мона городить на джунипере ещё поискать надо где в принципе можно сделать

ASBR вас спасёт