Привет, ещё один производитель коммутаторов виртуализовал свой софт и сделал возможным его запуск на всяких commodity или white box устройствах: http://tinyurl.com/h5kmhzc Не могу оценить, насколько это действие осмыслено, но общий тренд понятен - вендоры уходят в соревнование софтов, оставляя аппаратную часть на откуп производителям коммодити-чипов типа Broadcom etc -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison
Привет,
Основная идея дать возможность поуправлять своими коробками на доступном
тестовом стенде.
1) Обкатка решений с SDN
2) Ознакомление и обучение _до_ покупки
Без этого их сейчас никто не будет покупать.
Небольшой процент от продаж чужого железа сейчас или процент от 0 никогда.
На самом деле все не так уж и плохо в плане коммодити аппаратной части:
Intel vs AMD
NVIDIA vs ATI
QCOM vs MediaTek
Стабильное соревнование двух лидеров гарантирует качество уже лет 10 как.
Главное, чтобы все не начало упираться во владельцев фабрик по
производству, такую мелочь как Samsung и Intel.
Осталось дождаться на двух рынках стабилизации поставщиков аппаратной части:
- память (всякая разная)
- сеть (wifi уже поделен, mobile более-менее тоже, осталась только сеть
которая wired)
После этого станет не сильно важно, у кого софт круче из продающих чужое
железо. Станет важно кто из клепателей бирок на чужое железо шустрее правит
недочеты FW и выпускает стабильные дизайны.
Вот зачем пользователю помнить имя производителя маршрутизатора? Он ведь не
отличается от телефона или ноутбука. Пользователь оперирует
характеристиками в терминах ресурсов приложений, так почему сеть должна
отличаться?
Regards,
Andrii
2017-03-10 0:17 GMT+02:00 Volodymyr Litovka
Привет,
Виртуализация - это конечно приятно, действительно в том числе для
тестирования. У меня вот запущен Unetlab в котором собрана сеть из vMX и
vSR, можно еще туда добавить vXR ;)
Но таки inhouse чипы все еще могут давать всякое преимущество, начиная от
каких-то фич, которые Broadcom откажется реализовывать или отложит в долгий
ящик, заканчивая просто другой архитектурой.
Насчет зачем помнить имя производителя маршрутизатора - так просто не
выветрится, сколько вендоры (особенно С и чуть меньше J) вкладывались в
создание _культуры_ сетевых инженеров - тут тебе и community и сертификации
и все такое. А про никто не помнит название производителя телефона -
расскажи это Apple'офилам ;)
2017-03-10 2:15 GMT+02:00 Andrii Zarechanskyi
-- MYL2-RIPE
Миша,
За создание культуры конечно плюс. С другой стороны, все фломастеры
одинаковые. Вопрос в том, будет ли он именно того оттенка и толщины, как ты
привык. Но смысл написанного данным фломастером все равно не изменится. Или
у тебя внезапно появились явные предпочтения какой именно CLI использовать?
Какой не хочешь, я более-менее помню.
А насчет новых архитектур и функционала, их диктует не броадком. Они
приходит от культурных мальчиков и девочек, работающих архитекторами в
небольших американских компаниях и решающих задачи, как дешевле и надежней
построить транспорт от youtube до тебя. Так вот с той стороны, нет запроса
на функциональность.
Быстрее, надежней и проще. Логику что и куда коммутировать они напишут
сами. Ведь получилось у них изменить рынок аппаратных серверов. Теперь
очередь за поставщиками неплохого железа с проблемным софтом, функционала
которого 80% никто массово не использует.
2017-03-10 8:21 GMT+02:00 Michail Litvak
On 3/10/17 11:57 AM, Andrii Zarechanskyi wrote:
В далёком 2005 году я слушал выступление инженера Google перед инженерами Cisco. Он говорил примерно следующее - "Whatever you're doing, guys, is a piece of crap. As well as Foundry, Brocade, Force10 doing... we don't need your QoS, your logic and your features. Just give us fat pipes and we'll decide how to forward data through". Мы тогда похихикали, а зря... ;-) Где сейчас Гугль с Амазоном и где - все эти вендоры. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison
С одной стороны да, но с другой стороны я был удивлен, когда узла какое количество серверов от буквы D все еще использует Google сейчас. Они за счет вендора содержат и поддерживают всё железо стоящее не в их датацентрах. Заявки на замену в 95% случаев отрабатываются без человека со стороны G. Т.е. сервисная составляющая бизнеса как-то выживет. Regards, Andrii
2017-03-10 11:32 GMT+01:00 Andrii Zarechanskyi
Кроме сервисной составляющей (для своего железа она заточена под свои площадки) есть еще regulatory compliance - сертифицировать свое железо для использования в большом количестве стран, особенно для использования в чужой сети это большой головняк. D (равно как и C и J) решает его по всему миру и (в условиях вендорной конкуренции) за вменяемую денежку. Серверная/сетевая часть для своих datacenters - другая экономика. Малое количество стран, сильно большие объемы и полностью своя экосистема всего датацентра.
Regards, Andrii
-- Regards, Volodymyr.
2017-03-10 11:13 GMT+01:00 Volodymyr Litovka
Помнишь фамилию персонажа который выступал?
Мы тогда похихикали, а зря... ;-) Где сейчас Гугль с Амазоном и где - все эти вендоры.
Тут есть одна хитрость - сейчас все еще популярно держать две разные сети, одну с big-fat-pipes для DC-DC траффика и вторую (изрядно худее) для DC-Internet траффика. Для первой популярно клепать свое железо - экономика там такая, да и переманить из вендоров людей умеющих сделать свитч/роутер под заказ не есть проблема. Написать свой control plane - отдельная история, но как показывает практика если вложиться в этот вопрос ресурсами то это тоже решаемая (за несколько лет) задача. Для второй все еще выгоднее использовать (в большинстве своем) вендорное железо, софт и старый добрый BGP с MPLS-TE. Одна из причин - гораздо более стабильное и откатанное решение для критического revenue generating траффика, да и вендоры в условиях конкуренции таки успевают выпускать толковые продукты (C Fretta vs J MX) или уходят в прошлое (F10 или B). А что там будет дальше - будем посмотреть :-) Из личного опыта - troubleshooting разваливающегося TX-Matrix или SDN контроллера управляющего купкой больших коробок сопоставимые по сложности задачи. И там и там нужен толковый network engineer или devops :-)
-- Regards, Volodymyr.
Внутри которых стоит один и тот же чипсет Broadcom на линейной плате. И как всегда появляется вопрос, а зачем платить C/J за криво написанный bootloader с лишним функционалом, который всё равно общается с одним и тем же железом по протоколу очень похожему на следующий драфт openflow (скорее всего так сейчас).
Ну, скорее такой человек называется NetOps. Но пока такой титул не пишут в вакансиях. Regards, Andrii
2017-03-10 14:58 GMT+02:00 Michail Litvak
ALU всегда были немного другими. Их за это никто не винит. Один прилепили свой интерфейс к фабрике к чипсету и назвали это Trio. Другие просто называют поколения линейных плат по названим продуктов Broadcom и не парятся, хотя у них тоже свой интерфейс к фабрике. Как думаешь, почему у них типы плат с разными типами скоростей появляются в одинаковых набивках? И цифры в datasheet всегда похожи.
Любой инженер должен быть в меру ленив. А значит должен уметь автоматизировать. Отсюда и NetOps. Regards, Andrii
IMHO все слишком оптимистично: 1) у банков до сих пор есть банкоматы с “защищенными каналами связи", магазинам нужны платежные терминалы с Wi-Fi, пожарникам/полиции/скорой помощи - “надежный” G9, etc, etc, etc. Все это продается и работает на 20летних технологиях - SLA, QoS, IPSEC, L3VPN и все что масштабируется. При этом никакие big pipe никому не нужны 2) написание своего “control plane” - задача а) дорогая и б) ненадежная - слишком большие риски. Поэтому многие и делают так и делали последние 10-20 лет - риск разработки перекладываем на вендора и покупает у него готовый продукт с поддержкой. Что действительно изменилось, то что у вендоров _можно_ купить software без hardware но за это нужно скорее благодарить VMWare и виртуализацию на серверах 3) TX-Matrix это раутер и, при правильном планировании сети, в случае аварии мы его а) изолируем б) открываем P1 case with Juniper с) получаем медаль за быстрое решение проблемы. В случае проблем с SDN controller у нас проблема, например, во всем датацентре и тут от network engineer ничего не зависит - максимум можно помолится что переключение с primary controller на backup произойдет успешно, потерь трафика не будет и новый баг не будет найдет. Но если молитва не была услышана то прийдется будить support, а потом developers, потом лепить патч. И что самое ужасное что через 6-9 месяцев цикл повторится. P.S. А вообще я люблю новые технологии на iPhone, MacBook и других _личных_ устройствах :) Максим
Не совсем так. Сидело в комнате два инженера. Один из них был пацаном олдскульным, в электричество не верил и неистово дрочил на редистрибуцию из OSPF в BGP и обратно. Второй в свободное от OSPF время возился с Opendaylight, Openflow и Python. Первый был очень ценным чуваком - на нём держалась вся сеть. Поэтому, когда настали тяжелые времена, второго немедля сократили к хуям, а первого позвали к главному и сказали - "ты же очень ценный для нас человек, поэтому тебя мы бережем и не сокращаем, но вынуждены уменьшить зарплату." Второй на радостях напился, перекрестился и через полгода работал в Амазоне. Первый подался туда же, но был послан туда, куда сократили второго. Потому что кроме OSPF и BGP ничего полезного не знал. Они потом переписывались - второй рассказывал первому, как роботы бороздят просторы складов Амазона под управлением из облака, а первый жаловался, что он пол-года назад открыл кейс в Битриксе, а эти падлы до сих пор не могут исправить баг в 1С-Складе. Где-то так, я бы сказал. On 3/13/17 9:33 PM, Maksym Tuyluk wrote:
-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison
Привет ! Tuesday, March 14, 2017, 1:26:58 AM, Volodymyr Litovka doka.ua@gmail.com you wrote: VL> Второй в свободное от OSPF время возился с Opendaylight, Openflow VL> и Python. ...мне доводится иногда общаться с "мальчиками писателями кода" на всякие Питоны и "фреймворки", так вот я за олдскул голосую. Потому что мальчики на самом деле пишут код для сферического коня в вакууме а не процессора Интел, который в РС работает, и даже не для процессоров Анроид. Почему ? да потому что у них "хай левел программинг", да и то больной на голову в философском плане построения кода. А то что "внутри компа неонка" они уже не знают, они знают "функции", "наследования", "Обьекты" и прочее, и думают что на этом мир держится. ...потому и не могут исправить баг в 1С-Складе - для этого надо не на Питоне проги писать :-) ...а про "стек TCP/IP" я вообще промолчу: их знания заканчиваются "вызов процедуры отправить блок" ... -- Best regards, Alexander V Soroka http://www.svr.ua/ AS106-RIPE mailto:alex@euro.net.ua
Привет,
2017-03-14 1:26 GMT+02:00 Volodymyr Litovka
Вот зачем дрочить на известное извращение ? А может он строил Seamless MPLS на MBH и читал про Segment routing и EVPN.
Второй в свободное от OSPF время возился с Opendaylight, Openflow и Python.
Тогда уж лучше Tail-f ;) А python, чай не haskell его можно и за неделю осилить, особенно если раньше на Perl писал ;)
Скорее сказали, а теперь ты работаешь на outsource в китайской компании Плохой путь (tm) Второй на радостях напился, перекрестился и через полгода работал в Амазоне.
Первый подался туда же, но был послан туда, куда сократили второго. Потому что кроме OSPF и BGP ничего полезного не знал.
Ну, а первый мог на самом деле поехать в Какой-то Краков в Cisco TAC ;) Наверняка у него при такой любви к редистрибуции были сертификаты от вендора.
Роботы то бороздят, но второй с таким же успехом мог стать QA или там DevOps.
-- MYL2-RIPE
On 3/14/17 10:44 AM, Michail Litvak wrote:
Владимир, зочем ви тгавите ? (c) :-)
ага-ага, в ожидании, когда придет Juniper c Wandl'ом или Cisco с Tail-F и им скажут - вас тут пятеро ваще не нужно, остаётся один :-) -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison
Наверное имело бы смысл говорить о соотношении размера сетевой инфраструктуры и количества сетевых инженеров. Грубо говоря, несколько сетевых инженеров в МТС - это намного больше, чем несколько десятков сетевых инженеров в Гугле :) Но тут уж я наверняка не знаю. On 3/14/17 1:49 PM, Michail Litvak wrote:
-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison
2017-03-14 12:52 GMT+01:00 Volodymyr Litovka
Затраты на инженеров это Opex. У publicly traded companies соотношение (*) доходы/Opex это важный финансовый индикатор. Потому приоритет для соотв. начальства это sublinear growth и unit cost reduction дабы (*) не пугали инвесторов, финансовых аналитиков и share holders. Автоматизация это один из путей unit cost reduction, outsourcing/offshoring просто другой путь :-) On 3/14/17 1:49 PM, Michail Litvak wrote:
certain type of network), которым нужны network engineers. В группу которая занимается решением вопросов раздачи Internet в Африке через дроны/воздушные шарики или бесплатного WIFI на железнодорожных станциях rural India нужны инженеры с разными скилами. Аналогично skills set для: - GFiber - Internet-facing сети - DC-DC сети - корпоративной сети - CDN несколько разный. Чтото из этого поддается автоматизации проще, чтото сложнее. Ну и никто не отменил artrition - люди заболевают или хужее, уходят в творческий отпуск, на пенсию, переходят в другую контору или уходят в devops/software engineers.
-- Regards, Volodymyr.
hi, Tue, Mar 14, 2017 at 14:17:15, sha90w wrote about "Re: [uanog] Arista: девочки - направо, мальчики - палево":
Нетч, ну мы ж говорим о сетевых инженерах, а не о facility или как они там...
А что, я не могу тоже набросить? ;) Но с учётом того, как жалуются на уровень квалификации народа на местах, может оказаться, что в работу входит и это. По крайней мере, по отношению к собственно сетевому оборудованию.
Надеюсь сетевые сервера не вставляют %)
Вот я задам упреждающий вопрос. Есть ли сейчас что-то достаточно стандартизованное, чтобы спокойно потянуло от миллиона VLAN'ов в большой сети? И чтобы ещё и раутинговые демоны дружили с ним? -netch-
Не совсем понятно какую задачу ты решаешь, но посмотри на EVPN как на сам подход и на его реализацию как EVPN у Juniper и PBB-EVPN у Cisco. Но эти решения для того, чтобы склеить географически разнесенных DC и сделать их прозрачными для перетекающих туда-обратно виртуальных машин. -netch-
On Sun, Mar 12, 2017 at 09:39:14PM +0100, Maksym Tuyluk wrote:
IMHO все слишком оптимистично: 1) у банков до сих пор есть банкоматы с ???защищенными каналами связи", магазинам нужны платежные терминалы с Wi-Fi, пожарникам/полиции/скорой помощи - ???надежный??? G9, etc, etc, etc. Все это продается и работает на 20летних технологиях - SLA, QoS, IPSEC, L3VPN и все что масштабируется. При этом никакие big pipe никому не нужны
Ровно до тех пор, пока на рынке не появится конкурент, который будет решать задачу существенно дешевле или не найдёт и реализует преимущества от других подходов.
Скорее, задача требующая кучи специфичных знаний. Заказчик знает, что ему надо, вендор знает как это сделать.
Что-то не вижу разницы, приводящей к "такой красоте". Кроме как надежды, что "кто-то" после ТТ решит проблему быстро, а девелоперы "виртуально пошлют". -- Best regards, Paul Arakelyan.
On Sun, Mar 12, 2017 at 08:35:44PM +0100, Maksym Tuyluk wrote:
IMHO проблема более глобальная: вендоры не умеют слушать клиентов. А набор новых фич зависит, от желания маркетинга, а не того что нужно клиентам.
Не, ну они умеют. Если их чуть-ли не купить. "заинтересовать заказом на цифру с кучей нулей", в то время как нужно "минимизировать расходы и убедиться, что подход работает". Кстати - вот так и рождается то, над чем я сначала хихикал - коррупция внутри корпораций. Когда мне объяснили, за что брали взятки манагеры МТС, я был в шоке от изобретательности :). -- Best regards, Paul Arakelyan.
И что в 2005 году Google был в Top 20? Или он проходил по категории “масик который сосет”? Думаю, что все было гораздо печальнее: в 2005 над ним смеялись, а сейчас, те кто смеялся, безуспешно пытаются хотя-бы показать бывшему “масику” хоть какую-нибудь презентацию. Но признавать ошибок никто не хочет и не будет. Если еще одна история про смех: 10 лет назад инженеры из Nokia смеялись над Apple, т.к. у нового телефона "батарейка хватало на 1 день” или “если телефон уронить, то он разобьется”. А теперь смеются студенты бизнес школ когда изучают историю “Как посмеяться 5 лет и потерять весь рынок”. И, что самое удивительное, все это время Nokia тоже считала что у нее есть "World Top20 клиентов” которые _всегда_ будут платить Или более приземленное: кто был лидером на рынке PE/edge routers 10 лет назад? И на каком месте сейчас “бывший” лидер? Что самое удивительное, что "World Top20 клиентов" тоже ушли (или уходят), но они обычно уходят последними, когда менять/догонять уже поздно. Максим
2017-03-10 11:57 GMT+02:00 Andrii Zarechanskyi
Как там - "ну мы же профессионалы" (c) можем даже шилом нацарапать ;) Вопрос еще, что китайские игрушки не приносят радости ;) А CLI я предпочитаю в таком порядке: 1. Juniper 2. IOS XR 3. SR OS 4. Cisco IOS and подобные.
Да, я читал про эти всякие B4 и SixPack с Jupiter, но оно заточено именно под эти самые задачи двигать что-то между ДЦ притом когда есть информация где и какие приложения. Но в области обычных ISP и операторов все (к счастью) остается по прежнему - там нет 100500 программеров чтобы это писать самим каждый раз. Они же сами в том же Google Fiber используют AFAIK обычные рутеры различных вендоров. Хотя идея, что сисадмины больше не нужны - теперь DevOps рулят. И туда же про network engineers - не очень радует, остается только надеяться, что наш век хватит и классических сетей без вот этого всего ;)
А можно пример изменения рынка серверов ? Я знаю, что у них внутри все кастомное, но Dell и HP как делали обычные bare metall так и делают и их покупают и даже арендуют. Проблема, что в софте обычных вендоров куча legacy и куча кода который используется малым количеством заказчиков понятна и очевидна тут наверное есть куда меняться - хотя и не особо что-то делается.
-- MYL2-RIPE
On 3/10/17 12:27 PM, Michail Litvak wrote:
Facebook decide to forgo using traditional routing protocols and roll there own using swift and zeroMQ. They aren't the only ones either I believe google rolls their own and if you listen to Russ White on the packet pusher it sounds like LinkedIn uses their Kafka messaging bus to propagate routing info. https://code.facebook.com/posts/1142111519143652/introducing-open-r-a-new-mo... -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison
Вопрос номер раз, а коммутаторы там чьи? ) Если мне не изменяет память, коммутаторы там сваренные по запросу. А сколько времени осталось обычным ISP? Когда 75% нагрузки начнет приходить от трех-пяти основных игроков контракт с абонентом перестанет быть "Подключение к сети Интернет", а станет контрактом на подключение к сетям A-B-C-D-E-F, и немножечко Интернета. Так а зачем 100500 разработчиков, если у тебя есть глаза чтобы посмотреть уже выложенные проекты на github? Просто есть функция - смотреть фильм и слушать музыку. На твоем ноуте это делают скорее всего разные приложения. Точно также, через несколько лет у тебя будет свой предпочтительный BGPd и OSPFd управляющий коробочкой. Хотя идея, что сисадмины больше не нужны - теперь DevOps рулят. И туда же
про network engineers - не очень радует, остается только надеяться, что наш век хватит и классических сетей без вот этого всего ;)
Эм. А что такое классическая сеть? Коммутатор X.25, FR или LSR?
Внутри DC только свое. Точно не помню, но вроде капитальные затраты ужались в три раза после перехода на открытые проекты как самого DC, так и серверного железа. А вот то, что снаружи - носит лейбочку. По двум причинам - сервис без участия человека и сертификация во множестве стран и на чужих площадках, как ранее написал vovik@.
XR вроде должен был уже получить асинхронное обновление пакетов. Когда обновить BGP можно не затрагивая OSPF и IS-IS. Разговоры об этом уже несколько лет идут. Хотя конечно этого мало. Regards, Andrii
2017-03-10 15:05 GMT+02:00 Andrii Zarechanskyi
Я не спорю, что коммутаторы там свои и притом зачастую дешево и сердито слепленные - типа каждая LC это свитч и фабрика это тоже свитч, просто в одном корпусе.
Ну контракт контрактом - но кто доставит к нему в мобильное устройство/ в дом? Труба то какая-то останется...
Ну согласись, качество проектов на github особенно касающихся сети желает лучшего... Хотя может я отстал и уже есть хорошая реализация ISIS opensource или там MPLS стека... (хотя IGP не нужен, есть же ZeroMQ ;) Ну есть Vyatta, но незнаю - не щупал...
Ой... ну да, кто-то наверное и FR любил с X.25 и плевался на MPLS ;)
Ну я вот не смог быстро найти, какой-то известный чувак ушел в стартап и собирался делать OS для routers вот с этой самой идеей, что много таскать с собой legacy и от этого раздувается и баги лезут... Сюда же вот и открытый chipset: https://www.barefootnetworks.com/
On Fri, Mar 10, 2017 at 03:24:16PM +0200, Michail Litvak wrote:
недавно по-приколу влил два fullview на ubiquiti edgerouter, который суть и есть vyatta. на посмотреть - работает. вкрутить и забыть - не раньше чем через год-полтора буду снова пробовать. mbr, -- Igor "CacoDem0n" Grabin
Правильно труба доставит. А сколько она на этом заработает?
Но время идет и новые проекты появляются. Плюс виртуальный легаси. И стоит еще не забывать бойцов из OpenBSD. У них свой OSPF/BGP и первая реализация VRRP/CARP OpenSource. Когда им станет интересен IS-IS/RSVP/LDP тоже думаю напишут. Плюс не стоит забывать про попытки написать LDPd для Linux. Опять же, не такая уж и большая проблема написать весь стек. Эту работу уже проделали много раз. Взять хоть бы Juniper на старте или MikroTik/Arista сейчас. Ведь скорее всего брались уже готовые проекты и переписывались под себя и появлялся новый легаси. XR вроде должен был уже получить асинхронное обновление пакетов. Когда
https://mikrotik.com/software = routeros разве не оно?
Сюда же вот и открытый chipset: https://www.barefootnetworks.com/
Идем и читаем: <cite> 1. Barefoot’s Tofino is a 6.5Tb/s (65 x 100GE or 260 x 25GE) fully user-programmable switch .. Tofino is fully programmable via the P4 programming language 2. The P4 programming language .. First created by Barefoot, Google, Intel, Microsoft, Stanford and Princeton. P4 allows programmers to unambiguously specify forwarding behavior. .. </cite> И еще одно доказательство того факта, что кому-то проще сделать самим, а не просить _экспертов_. Regards, Andrii
2017-03-10 15:45 GMT+02:00 Andrii Zarechanskyi
Ну мы ж тут не со стороны акционеров трубы, а со стороны кто на трубу работает... хотя понятно, что если труба не заработает - то и не заплатит, наверное просто труба будет п принадлежать вот этим A-B-C-etc.
Вот уж OpeBSD при всем к нему хорошем отношении уж довольно маргинальный продукт, я никого и не знаю кроме Демона кто бы его использовал ;)
Да ну, в микромире какой-то хаченый линукс с quagga... Скорей всего это https://cumulusnetworks.com
Да, идея супер. Только вопрос когда и за сколько его можно будет купить. -- MYL2-RIPE
Из опёнка многое переноситься во FreeBSD. Из FreeBSD попадает в Darwin и Linux. Не всегда напрямую, иногда переписывают с нуля. В любом случае обмен идеями и их реализацией идёт. И еще одно доказательство того факта, что кому-то проще сделать самим, а не
А что именно купить? Фиксированный коммутатор на 65x100GE? Подожди когда цену объявит кто-то из _экспертов_. Потом вычти норму ожидаемой прибыльности закладываемой для технологических компаний на уолл-стрит и получишь что-то вроде 30%-35% от цены вендора для работающего решения без рюшечек. Думаю продавать начнут уже в этом году. Объемы растут. Чем-то все это перемалывать нужно.
On Fri, Mar 10, 2017 at 04:42:21PM +0200, Michail Litvak wrote:
Михаил, "маргинальный продукт" используется и крайне активно - https://atmnis.com/ JFYI ;-).
On Fri, Mar 10, 2017 at 03:45:59PM +0200, Andrii Zarechanskyi wrote:
коллега, вы пытались пользоваться этим bgp? я - пробовал ;-)). то есть да, его можно добить до ума, но мне так кажется, что свой следующий debugging frenzy я посвящу написанию подробной телеги в сторону ubiquiti, так как их попытка сделать железку вокруг vyatta выглядит достаточно трогательно. openbgpd на сейчас уже втупую бессмысленно дёргать на bare metal, а под hypervisor'ом - тем более бессмысленно, несмотря на то, что open является чуть ли не единственной операционкой, в которой подможество vmware tools тупо вшиты в ядро ;-). mbr, -- Igor "CacoDem0n" Grabin
On Fri, Mar 10, 2017 at 03:45:59PM +0200, Andrii Zarechanskyi wrote:
Ровно столько, на сколько рынок согласится. Типичный разговор с обзвонщиками: - Здравствуйте, это компания ***. У нас для Вас выгодное предложение, 100500каналов! - Сколько Вы мне будете платить? - ?!?ШО?! - А в чём же выгода, если прибыли я не получаю? - Козёл! бип-бип-бип В чём работа ISP? В работе с конечными абонентами и их, нередко, нестандартными проблемами, в работе в условиях местных законов и правил. Грубо говоря, ISP - это розничная торговля. Да, мы можем дожить до "ISP нету", но это будет следствием покупки их контент-провайдерами. Тогда всё может станть плохо. Грубо говоря, гугл вполне сможет зашейпить-забанить вконтактик и наоборот. Зато расходы можно будет оптимизировать. Появятся аналоги "Ашана" :). -- Best regards, Paul Arakelyan.
IMHO CLI сейчас делятся на две категории: 1) нормально автоматизируются (конфигурация и выводы show команд в XML/JSON, candidate config, commit, rollback, etc) 2) автоматизация через "спагетти код" вида “if version==1 then … ifelse version==2 then …” т.е. как последние 10-15 лет Максим
Макс,
Тестирования и замена аппаратной лаборатории на виртуальную появляются чуть
позже.
Когда уже оборудование куплено или в рамках PoC.
В любом случае, даже когда есть результаты PoC, должна еще пройти
сертификация оборудования для использования на сети в определенной роли. И
как раз сертификация включает в себя тестирование на реальных задачах
покупателя, проверку функционала в виртуальной лаборатории с последующим
переносом на тестовый физический участок.
2017-03-12 21:02 GMT+02:00 Maksym Tuyluk
Зачем тратить время и ресурсы на PoC? Можно взять софт и просто протестировать на совместимость с текущей сетью. Иногда сразу понятно, что PoC уже не нужен. P.S. Но если вендор организовывает PoC в Сан Хосе и оплачивает самолет, гостиницу и машину, то PoC состоится всегда! :) Максим
participants (12)
-
Alexander V Soroka -
Andrii Stesin -
Andrii Zarechanskyi -
Gregory Edigarov -
Igor Grabin -
Maksym Tuyluk -
Michail Litvak -
Paul Arakelyan -
Sergey Prysiazhnyi -
Valentin Nechayev -
Volodymyr Litovka -
Volodymyr Yakovenko