furrry | Последний раз про Cisco

a Nexus 9000 не показывали?

Может и показывали, но я на эти сессии не ходила. Я больше по v6, операторскому роутингу и автоматизации.

Ну отношение двоякое.
С одной стороны хорошо, а с другой мы все (которые и CLI-то с трудом) останемся без работы.

Честно говоря, у меня смешанные чувства.
С одной стороны: круто-круто-круто!!!!!
С другой стороны, зная, какие у Cisco разработчики и пободавшись несколько лет с их SDK в других продуктак, даже не хочется думать _какие_ баги могут быть в OnePK. Опять же, пообщавшись с саппортом циско понимаешь, что исправление этих багов тебе ни в жизнь не продавить, только если кто-то из "очень большой" компании на них не нарвется и не продавит за тебя.

Вообще, конечно, грусто, что вместо радости за такую _интересную_ технологию у меня возникает пессимизм, который базируется на более чем десятилетнем опыте работы с cisco.

Дорогая, ну что Вы такое говорите, право! Мы же с Вами прекрасно понимаем, что из каждых 100 заработанных долларов - 1 доллар нам заплатили за то, что мы ~~махнули молотком~~ набрали что-то в CLI, а 99 - за то, что знали ~~куда бить~~ что именно и когда набирать!

нет, ну мы с Вами-то, конечно, сидим в центре Вселенной и усилием мысли перенаправляем потоки битов и байтов, повелеваем электромагнитными волнами одним взглядом. Я же сейчас не столько про нас, сколько про развитие индустрии вообще. Как вообще будут выглядеть advanced services в будущем, как это вписывается в модель заказчик-партнер-вендор, как программисты вообще собираются что-то писать под это железо? И открыто это продавать? Это или инженеров нужно учить Питону (что в случае со мной вообще затея интересная) или программистов - семиуровневой модели.
Очевидно, что за SDN будущее, и вообще надо было так с самого начала все строить, но вот с практической точки зрения - многонеясного(с).
Говорят, уже есть один готовый деплоймент как всегда в Bay Area, вот ну очень бы интересно было глянуть.

А вообще тема на редкость занимательная.

Следующим логичным шагом будет поставить антивирус.

Значит, еще лет десять попишем на Expect'е, ничего страшного.

Ну OpenPK это не совсем SDN. Вот Juniper уже давно с OpenFlow забавляется, но пока ничего работоспособного не представила. А учится питону придется всем. Ну или в GUI мышкой возить.

Да я боюсь, как бы из-за новомодного OnePK не перестал работать старый Expect.

Как прямо тут сказано у Евгении Борисовны: "C/Java/Python".
Так что учиться питону придётся не всем.

> Говорят, уже есть один готовый деплоймент

Как-то маловато, за полтора-то года существования onePK в открытом пространстве.

> Как вообще будут выглядеть advanced services в будущем

адванцед сервизес будут вокруг дизайна, запуска, и отладки application policies, которые будут рулить различными компутерными (в т.ч., сетевыми) ресурсами для важных бизнесу приложений.

Также см. OpenDaylight (только что первая версия вышла), хотя там ещё темна вода во облацех - полетит, или таки загнётся.

Edited 2014-02-06 09:19 (UTC)

> API позволяет делать packet injection into forwarding plane

http://archive.openflow.org/documents/openflow-spec-v1.0.0.pdf (Dated: Dec 31, 2009):

4.1.1 Controller-to-Switch

Controller/switch messages are initiated by the controller and may or may not require a response from the switch.

[...]

Send-Packet: These are used by the controller to send packets out of a specified port on the switch.

(Я типа понимаю разницу между API и протоколом по которому котроллер разговаривает с устройствами; но контроллер-то практически во всех случаях на север глядит через API, а посему... возможности отстрелить себе ногу из базуки по самые уши практически безграничны. И конкретно onePK для этого кагбэ совершенно необязателен).

Как будет выглядеть? Трава будет менее зелёной. Мужики скучнее. И т.д.
В IOS-ах уже Ричард знает сколько времени есть встроенный тикль.
А пенсионеры всё никак не дождутся, когда ж их нанимать-то начнут на тикле сетекод фигачить.

Песню про то, что "скоро нам, граждане, крышка" я слыхал ещё когда циска SDМ выпустила: "вот, кастомеры теперь будут теребить гуй мозолистой рукой, а мы все умрём от голода..."

"За SDN будущее"
Большой шкаф, большие шкафы с тупыми терминалами, персоналки, клиент-сервера, тонкие клиенты, облака.
Ты уверена, что на облаках всё закончится и не будет никакого "золото, суд, Сибирь"?
(Домашнее задание. Дано: "статика... дистанс вектор ... mpls ... sdn". Требуется: заполнить пробелы в моём образовании.)

С практической точки зрения мне представляется одна простая штука.
Если у тебя есть 5-6 роутеров, то даже мне ты сумеешь наглядно продемонстрировать, что бутерброд вкуснее кусать OSPF-ом, BGP и прочим MPLS-ом на язык. Или тонкую фекальную нотку в букете RIP/IGRP...
C SDN получается или "ну и чем это лучше X, Y или Z?" или же тысячи девайсов (каким-то магическим образом все с последней версией софта), кубокилометры трафика и мегатонны электричества. И тут приходится или адмиралов вернуть на воду или матросам "показать полную карту". И то и другое как правило "вообще затея интересная".

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

Я про то, что может быть теперь не надо будет извращаться, а можно будет делать это легко и приятно.

Я не уверена, что понимаю такую логику - но it might be just me ;)

Во-первых, заметим, что это не я первая произнесла SDN. По правде сказать, я бы вообще предпочла не упоминать эту аббревиатуру. Я вот тут как-то полчаса общалась с коллегой - без какого-либо намека на понимание между нами. В конце концов выяснилось, что когда я произношу "UPS" - я имею ввиду службу доставки. А он - источник безперебойного питания. Вот с SDN примерно так же. Одни под SDN понимают Python API к маршрутизаторам, другие - PCE, а третьи - OpenFlow.

Я, кстати, поняла, что в моей реальности инженеры все на чем-то в той или иной степени пишут, и я еще самая ленивая (меня на мою позицию полтора года не брали, потому что я на питоне отказывалась писать) - но допускаю, что это не везде так. В модель "заказчик - вендор - партнер" это вписывается как и раньше. Только вместо того, чтобы рассказывать, какие LSP и где настраивать - provision всего этого на контроллерах. Тебя же не удивляет, что теперь вместо настройки отдельных точек доступа - мышкой возят в WLC, или как оно там назыается.

Я тебя обожаю!

P.S. Но "мужики скучнее" - этого нам не надо!

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

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

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

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

Да вряд ли сиска CLI полностью убьет. Во-первых, CLI гораздо проще, быстрее и надежнее гуя, а во-вторых, в Nexus'ах CLI очень похож на CLI из IOS, то есть до основания разрушать пока что намерения нет.

У вендоров, которые на CLI кладут (например, F5), все гораздо хуже: команды для CLI от версии к версии меняются кардинально - до того, что проще на устройство ходить через HTTP API, чем через SSH.

Сиска себе такого не позволяет, так что еще поживем. А позволит - ну что ж, CCIE лаба будет длиться неделю, а не на один день.

Я опять потеряла нить этой дискуссии - откуда вообще взялось слово GUI? ;)

Ну так чтоб убить Expect, нужно убить CLI. А какая, собственно, альтернатива CLI? Только какой-то вариант GUI - либо на самой железке, либо на NMS.

Ну вообще для меня - альтернатива CLI на коробке - CLI на центральной системе управления ;))

...ну или shell на моей машине, как оно в реальности и происходит ;))

То есть питон через API. ;-)

Но мне все же кааца, что это побочный эффект от движения сиски в сторону Виндовс.

Не любить питон и любить shell?! Sed вместо нормальных regexp'ов, монструозные конструкции типа "exec 6<>/dev/tcp/127.0.0.1/80", если надо просто проверить, открыт ли порт?

Я предполагаю, что shell юниксовый, иначе в этом shell'е не будет SSH, во что я поверить не могу.

Я так по секрету скажу, что до прошлого ноября я циски не видела 5 лет, и была очень всем довольна. Циска тут вообще ни при чем.

Я определенно потеряла навык излагать свои мысли так, чтобы меня понимали.

Из shell'а запускаются *уже cуществующие* программы. Идея использовать сырой API каждый раз, когда надо обратиться к устройству, мне даже в голову не приходила - очевидно, у меня очень много рутинной повторяющиейся работы, и такого разнообразия, чтобы прям каждый раз надо что-но новое писать, со мной не случается.

Питонье АПИ выложили практически только что. Так что лучше говорить ну хотя бы про жабье.

> Очевидно, что за SDN будущее

А мне, вот, например, неочевидно.
Не могу не воткнуть сюда ссылку на прекрасное, на мой взгляд, мероприятие с участием

dbg:
http://tech.yandex.ru/events/science-seminars/SDN-21nov/ про этот самый SDN.

Последний раз про Cisco

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject