[BiWiS]

обреченные :)

[balabol]

По субъективному техническому суждению могу сказать о печалях L2 на доступе. Во-первых эффективные манагеры понакупят адского кошмара с урезанным функционалом и сомнительным качеством исполнения. То есть при любой модернизации доступа придется тратить в 3 раза больше времени на планирование. Во-вторых тунели/vpn/nat дебагятся по доступным материалам в сети и тут энтузиасты суппорта вам в помощь. Чего не скажешь о том же MPLS L2 VPN (вспомните как пионерами в крупных конторах мы искали чего есть такое Bras). "Просто" одновременно пользователю и суппорту - это дорого. Потому как в таком случае сложно должно быть сборщикам и разработчикам. У меня лично была мысль гонять 82 между оборудованием на первом этапе через cron с перспективой ухода в SNMP, а прописанный клиентом статик на сетевуху обходить путем назначения DHCP-клиентом порта (за опцию тарифа). Да и вообще до упора экономики проекта стараться гонять дополнительные протоколы и инсталлируемое ПО внутри оборудования по сетке для управления. Но пока коплю ресурсы, чтобы перестать быть теоретиком.

Изменено 15 января, 2014 пользователем balabol

[tunny]

Хотя я говорю суппорту, что при отказе от тунелей: "Вас всех можно уволить"

Не все так гладко с опц82 и связанными с ней рюшечками.

Суппорт просит периодически кого-то разбанить - хз чего там у юзеров с dhcp клиентами твориться, на стенде все работает красиво )

(понапокупают себе хрен знает каких девайсов : )

 

Не все так гладко с L3 на многих свичах у многих вендоров. Значит надо до браса L2 тащить.

Либо выкинуть эти свичи (хотя с L2 у них все в поряде) и купить те, которые не имеют проблем с роутингом, но стоят в 10 раз дороже (или все таки эти деньги на брас потратить?)

 

Не все так гладко с тазиками - если я умру - кому-то придется разбираться в моих соплях, скриптах, конфигах - либо свои на ходу лепить.

В случае браса - обратиться к интегратору, сообществу, мануалу - ибо там стандартизировано (теоретически)

 

 

Не все так гладко с брасами операторского уровня :)

 

Смотря что считать "не гладко". На MX нету ната в базе, плюс interim-update-interval не может быть меньше 10 минут. Больше минусов назвать не могу.

 

Ну, NAT я лично считаю вынужденным геморроем, и если есть возможность его не юзать, его надо НЕ юзать, потому что

не все гладко с NAT )

а можно поподробней что за бан с опцией 82? Зачем сразу на технологию пинять, работает нормально, а держать стадо вланов (на каждого абонента) что-то не хочется.

 

имхо, L3 на агрегации добавляет гибкости и ограждает брас от всякого л2 мусора от абонентских устройств. на нормальных свичах гладко с л3 если не искать "такой же, но с перламутровыми пуговками"))

 

я б не рискнул МХ ставить как брас, пусть доточат, а там и поглядим. на том же мх80 вообще не интересные ограничения по сабскрайберам. на шассиках тоже надо доки рыть. функционал в продакшене еще толком не отработан, в прошлом году в массы только пошел...

 

про нат вобщем согласен, но тот же дуалстек как без него?

[DVM-Avgoor]

я б не рискнул МХ ставить как брас, пусть доточат, а там и поглядим. на том же мх80 вообще не интересные ограничения по сабскрайберам. на шассиках тоже надо доки рыть. функционал в продакшене еще толком не отработан, в прошлом году в массы только пошел...

 

 

А выбор-то и не большой.

На SE600 тоже дофига issues от релиза к релизу.

ASR1k - вроде не плохо, иногда крашится :)

ASR9k сыро-сыро-сыро.

Какие еще варианты?

 

PS. Ну и стандартный вопрос: какие функции недоточены в MX?

Изменено 15 января, 2014 пользователем DVM-Avgoor

[darkagent]

ASR1k - вроде не плохо, иногда крашится :)

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

[redds537]

а можно поподробней что за бан с опцией 82? Зачем сразу на технологию пинять, работает нормально, а держать стадо вланов (на каждого абонента) что-то не хочется.

Я не технологию пинаю. А реализацию в реал лайф.

Сама по себе сферическая технология в вакууме очень красивая.

Но в реальности есть всякая хрень с ее реализацией у разных вендоров + всякие особенности релеев и DHCP серверов и биллингов.

Плюс разные фичи на свичах, которые у разных вендоров по разному называются - которые дропают трафик юзера (это я и называю - попасть в бан на доступе), если он как-то "не так" запросил/получил адрес по DHCP,

или вообще не запросил, или не вовремя запросил, или вручную свой же адрес прописал.

Плюс ко всему DHCP клиенты в разных разнообразных холодильниках ведут себя не совсем одинаково.

В итоге все как-то не очень четко. На 17 000 юзерах статистика эта выглядет более весомее в абсолютных цифрах.

Я наелся.

Хочется - чтобы просто был порт юзера, просто тегировался юзерским вланом, и просто билинг и в итоге брас знают, что трафик с такими вот тэгами = трафик такого вот юзера.

Плюс юзеры полностью изолированы - и не нужно всяких других "защит" от всякого спуфинга и т.д.

В общем - чем меньше сущностей юзается на свичах доступа - тем лучше - это мое мнение.

Первоначальная настройка влана на юзера меня не пугает - это посильная задача.

Хранить конфиги и автоматизировать конфигурирование при замене вышедших из строя свчией - это посильная задача.

Менять тысячи свчией на другого вендора, чтобы проверить снова, что может быть все таки бывает все хорошо - нет, спасибо.

 

имхо, L3 на агрегации добавляет гибкости и ограждает брас от всякого л2 мусора от абонентских устройств. на нормальных свичах гладко с л3 если не искать "такой же, но с перламутровыми пуговками"))

Та же фигня - есть проблемы с роутингом у многих недорогих свчичей агрегации - менять? Не спасибо - зачем проверять, вдруг снова не повезет. Тем более, что с L2 на агрегации - все четко.

Вот и получается - чем проще свичи доступа/агрегации - тем больше требований к центру (к брасу и ядру).

Вся надежда на брас.

БРАС просто обязан прожевывать любой "мусор" от юзеров и даже не поперхнуться.

Если у многих свчией есть разный тротлинг (ограничение различных пакетов в секунуд - типа арп, dhcp, igmp, bpdu и т.д) - то на брасе тем более это есть и должно четко работать.

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

 

 

про нат вобщем согласен, но тот же дуалстек как без него?

в идеале отдаешь белый ipv4 и белый(белые) ipv6 юзеру - и никаких NAT, тунелей, брокеров и прочих компромиссов.

 

На SE600 тоже дофига issues от релиза к релизу.

Есть ли нерешенные критические issues?

Изменено 15 января, 2014 пользователем redds537

[DVM-Avgoor]

Это открытая инфа? Где можно следить за списком багов и фиксов?

 

 

Нет конечно, инфы вообще о этих железках мало. Как в прочем у эрикссона со всеми железками.

В Европе же принято маркетинг-булшит-данными заменять даташиты и errata.

 

http://forum.nag.ru/forum/index.php?showtopic=65559&st=0

[xcme]

а можно поподробней что за бан с опцией 82? Зачем сразу на технологию пинять, работает нормально, а держать стадо вланов (на каждого абонента) что-то не хочется.

У человека смешались в голове опция 82 и айпи-порт-мак-биндинг (или его аналоги).

С самой опцией 82 на тех же длинках проблем нет. А вот IMPB странный, да. Дважды пробовали внедрить - не взлетело. А потом дизайн сети стал таков, что это стало даже вредным.

[uk2558]

У нас, конечно, абонентов по меньше. IPoE сделали так: физики терминируются на Cisco 3750G, ip unnum, option 82, DHCP relay, белые адреса /32, vlan на пользователя. DHCP на тазике. До 1000 пользователей на Cisco. Всего около 10 таких Cisco. Между ними OSPF кольцо - в нем бегает локальный трафик и IX на скорости до 100 мБит(одна из Cisco берет IX по BGP). Так же, каждая Cisco смотрит на коммутатор в ядро отдельным линком (это внешний трафик). За коммутатором в ядре стоят два шейпера на FreeBSD с 10 G карточками, балансируется всё при помощи OSPF. Трафик во внешку с каждой Cisco от 200 до 700 мБит. За шейперами стоит бордер.

[DVM-Avgoor]

физики терминируются на Cisco 3750G,

А почему не на 4948?

[uk2558]

физики терминируются на Cisco 3750G,

А почему не на 4948?

Так исторически сложилось )) В свое время, одно ЮР лицо, рассчиталось с нами 3 шт. 3750G. С этого IPoE и понеслась. На IPoE примерно 80% физиков. В остальных случаях - PPPoE на Cisco 3845. IPoE кошерно, но есть шероховатости. Cisco 4948 рассматривается как upgrade.

[redds537]

IPoE кошерно, но есть шероховатости

Можете подробней?

[Diamont]

IPoE сделали так: физики терминируются на Cisco 3750G, ip unnum, option 82, DHCP relay, белые адреса /32, vlan на пользователя

Хорошо, что ещё и рррое не добавили...

[DVM-Avgoor]

 

Цитата

IPoE кошерно, но есть шероховатости

 

Можете подробней?

 

Дык, когда пытаешься натянуть сессионные механизмы AAA на чистый TCP/IP всегда получаются шероховатости. Шагрень на поверхности мироздания, так сказать.

Оттуда и ноги растут всех IPoE проблем. (Ибо надо из чего-то сессию соорудить, а стандартизованного механизма со стороны клиента то нет, оттуда и старт по DHCP или первому пакету...)

[smsm]

да от вариантов руки разбегаются. имхо.

самое простое..

на дом/группу домов - влан и сеть.. /24 допустим серых адресов и сколько-то белых

терминировать все пользовательские вланы на 65хх.

потом на исг, в роли которого что-то, начиная от esr10008..

потом в нат(ы) на юниксе.. те в бгп.

биллингов - масса.. нетап, инлайн..

авторизация по ипу( ип ручками у пользователя ) или по опш82.. или по логину/паролю..

на исг какие-то ресурсы делаются с доступом без авторизации..яндекс, контакт.. хз

это расписано, есть примеры, всё довольно просто и быстро внедряется.

ну или правильный..

как в 4 сообщении. имхо.

но ессно это уже думать нада как внедрять..

лично мы с пптр переползли на простую схему, потом на правильную ( в процессе )

тыщ 15 коннектов в пике, около 10Г трафика.

[DVM-Avgoor]

Это все архаичная фигня. Если есть BRAS не нужно терминировать вланы сначала на 65ой а потом делать авторизацию по волшебству.

Конечно можно купить всякого пылью покрытого хлама на ебее типа 65ой, а потом страдать это внедряя. Зато дешево :)

Получить в итоге хрен пойми что, потому что 65ая ку-ин-ку терминировать не умеет, влан на пользователя в таких объемах она не выживет.

Откуда берется дебильная привычка ломать себе пальцы изобретая велосипед? С этим вашим /24 на дом, потом в эксплуатации придется держать нечто большее чем пару обезьян на телефоне, потому что будет распределение, списки какие-нибудь вланов/ип/домов. Ад же, зачем все это?

[smsm]

ну так и говорю.

это просто, быстро. не особо сложно внедряется.

то-есть плюсы только это.

65хх обычно уже есть .. или куча 3750.. или что-то похожее.

[DVM-Avgoor]

Ну если задача что-нибудь сделать ради того чтобы люди не сидели на попе а работали, то почему бы и нет :)

А если надо сделать хорошо, то это вэлкам к аппаратным БРАС. Я все эти радости внедрял уже, у каждой есть свои неприятные моменты.

65ая + c-vlan + dhcp opt82, в принципе очень не плохо смотрится, у меня такое в продакшене стоит и не жужжит. Но там нету сессионной модели, пользователи "всегда онлайн".

А с новыми BRAS все гораздо приятнее, все более стандартизовано. Из костылей там надо пожалуй написать скрипт CoA в биллинг, да внести аттрибуты вендорские. Красота, надо брать (С)

[uk2558]

IPoE кошерно, но есть шероховатости

Можете подробней?

Редко, но все же, Cisco 3750 перестает релеить dhcp запросы от клиентов. Рандомно. Примерно раз в пол года. Лечиться только перезагрузкой.

Далее - не все роутеры способны работать с /32 на интерфейсе и шлюзом из другой сети. У нас составлен список совместимых роутеров, проводятся разъяснительные работы с клиентами - но все равно, иногда кто то покупает несовместимый роутер. Для для таких и держим PPPoE. Работают Asus RT-Nxx, Dlink старше 6хх серии, старшие версии TP-Link, или всё то, на что можно поставить DD-WRT.

[xcme]

С этим вашим /24 на дом, потом в эксплуатации придется держать нечто большее чем пару обезьян на телефоне, потому что будет распределение, списки какие-нибудь вланов/ип/домов. Ад же, зачем все это?

Если у вас сотрудники - обезьяны, то кто тогда абоненты? Может и не клиенты даже? :)

Честно стараюсь понять, в чем удобство влан-на-юзера, но что-то никак. Наверное, тут как в единоборствах - надо чтобы кто-то показал, а "по книжкам" бесполезно. :)

 

А списки да, есть у нас (вида коммутатор-сеть). Всегда известно кто что получил или получал когда либо. Помогает в работе ТП и при разборе запросов от органов.

[tunny]

Это все архаичная фигня. Если есть BRAS не нужно терминировать вланы сначала на 65ой а потом делать авторизацию по волшебству.

....

IPoE over L3, не архаичная, а удобная "фигня" имеющая право на жизнь.) или такое мнение потому что на МХ оно не работает никогда?))) вланы терминируются пусть на 65ом, а авторизация по dhcp-пакетам на брасе или это и есть волшебство?) потестил non-dhcp clips, на юриков повешу.

В отдаленных районах подняли IPoE L3, нет желания из далека весь мусор гнать в центр и локальный трафик там замкнут, стоит 460й с оспф, юрики - вилан до браса.

Остальная - л2 до браса с opt82, планируем тоже мигрировать на l3, не к спеху пока. опция 82 и биндинг работает, больше проблем было при связке с биллингом. с мультикастом еще погемороились.

 

P.S. про недопиленность МХ, пусть другие софт тестят)) я подожду, не горит, а там посмотрим. (как и аср9000, с ним вообще печаль))

имхо, из реального сейчас можно юзать se и asr1000

[Saab95]

Честно стараюсь понять, в чем удобство влан-на-юзера, но что-то никак. Наверное, тут как в единоборствах - надо чтобы кто-то показал, а "по книжкам" бесполезно. :)

 

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

[xcme]

можно резать скорость в центре

А кто-то делает по другому? о_О

[DVM-Avgoor]

Если у вас сотрудники - обезьяны, то кто тогда абоненты? Может и не клиенты даже? :)

 

 

А вы платите каждому саппортисту как инженеру СПД?

 

Честно стараюсь понять, в чем удобство влан-на-юзера, но что-то никак. Наверное, тут как в единоборствах - надо чтобы кто-то показал, а "по книжкам" бесполезно. :)

 

 

Как в чем, в изолированности же. Не надо никаких arp-inspection, ip source guard. Всем пофиг что там абонент делает в своем влане, пусть тешится.

Это того стоит.

 

 

IPoE over L3, не архаичная, а удобная "фигня" имеющая право на жизнь.) или такое мнение потому что на МХ оно не работает никогда?))) вланы терминируются пусть на 65ом, а авторизация по dhcp-пакетам на брасе или это и есть волшебство?) потестил non-dhcp clips, на юриков повешу.

 

Вы какую-то хрень молотите, честно. Я не знаю зачем делать так, если у вас уже есть брас. На MX non-dhcp нету. Оно и нахер не надо, оно для людей которые не понимают что такое брас и где в схеме он должен стоять.

 

ОФТОП. Но меня очень радует, с другой стороны, что есть столько замечательных мнений. Значит есть еще на просторах родины "операторы", которые способны землю рыть лишь бы изобрести свой никому не нужный велосипед. Придумать промежуточную технологию типа "влан на парочку домов и соседний ларек", лишь бы не делать c-vlan. Но дробить то надо, а то штормы кладут все? :) Забавно.

[xcme]

Как в чем, в изолированности же. Не надо никаких arp-inspection, ip source guard. Всем пофиг что там абонент делает в своем влане, пусть тешится.

Это того стоит.

config traffic_segmentation 1-24 forward_list 25

На 95% делает то же самое, не?

Дополнительно срезаем с абонента невалидные ARP по бинарной маске (если у него пул IP). Получаем примерно так 99%. Остается единственный способ "нагадить" - поставить себе MAC шлюза. Если совсем параноя - можно прописать его статиком на аплинке и получаем на 99.9% полную изоляцию в схеме влан-на-коммутатор.