[Macil]

Все, блин, уши прожужжали! SDN туда... SDN сюда... Новые горизонты. Все быстро доставайте кошельки.

 

Ладно, уговорили. Смотрим. Краткий принцип работы: можем уведомлять контроллер о пришедшем пакете, контроллер может создавать записи в различных табицах, контроллер может получать уведомления о событиях, контроллер может собирать статистику, контроллер может осуществлять интроспекцию конфигурации коммутатора.

 

1. Этот самый флоу можно матчить весьма разнообразно: и по номеру порта (в терминах OF, т.е. не только физическому), и по адресу eth (ну это понятно), и даже по протоколу IP, адресу IP(6), номеру порта TCP/UDP. Ага!!! А вот и причина отсутствия победного шествия OpenFlow по планете. Говоря грубо, хрен вам а не OpenFlow в коммутаторах уровня доступа (про клиентские устройства скромно молчим).

 

2. Счётчики на каждый флоу. Занятно. Только как это соотносится с SDN? И сколько этих самых счётчиков (и флоу) сможет держать сферический свитч в вакууме?

 

3. Тайм-ауты на каждый флоу. Как принудительные (для истинных параноиков), так и по неактивности. С уведомлением контроллера о наступлении таймаута.

 

4. При прохождении пакета по флоу, выполняется набор (set в терминах из CS, т.е. не более одного типа) инструкций. Подберите слюни! Обязательной для реализации является только инструкция Write-Acition. Опять, в качестве параметра только *набор* действий.

 

5. Actions, они же действия. Output пересылает пакет на OpenFlow порт, как на физический, так и на логический, например можно передать пакет контроллеру. Drop он и в африке дроп. Group выполняет действия из таблицы Groups.

 

6. Группы. Есть отдельная таблица Groups. На каждую группу есть набор счётчиков и *список* т.н. называемых action buckets, содержащий *набор* действий. Стратегия исполнения зависит от типа. All исполняет все action bucket'ы, каждому из которых достаётся свой клон пакета. Основное назначение — мультикастный рутинг. Indirect исполняет только один бакет. Служит для построения уровня индирекции между флоу и действием, например, для создания «библиотеки» типовых действий.

 

7. Из спецификации не ясно, но кажется рекурсия на уровне флоу-таблиц и групп не гарантируется.

 

Из опционального.

 

8. Конвейер. Коммутатор может поддерживать несколько флоу-таблиц. В этом случае обязательной для реализации является инструкция Goto-Table, и можно реализовать инструкцию Write-Metadata для передачи информации между таблицами. Соответственно, новое правило матчинга. Каждому пакету сопоставляется *набор* действий, который формируется при прохождении конвейера, и исполняется после прохождения последней таблицы (без Goto-Table).

 

9. Инструкция Meter вызывает действия из таблицы Meter, служащей для организации QoS. Можно в зависимости от количества проходящих через флоу пакетов выполнять определённые операции. Увы, их всего две: drop и dscp remark. У ещё раз увы, нет операции «ничего не делать», поэтому для сбора статистики таблицу Meter использовать затруднительно.

 

10. Действия Set-Field и Push-Tag/Pop-Tag. Позволяют менять поля в и добавлять/убирать Q-in-Q, PBB и MPLS теги в пакете. В одном наборе действий (Action Set) для пакета может быть несколько действий с разными полями и тегами.

 

11. Действие Set-Queue позволяет задать очередь на порту назначения. Вендорспецифичненько.

 

12. Инструкция Apply-Actions применят *список* действий к пакету, без изменения Action Set.

 

13. Типы групп Select и Failover исполняют бакеты в зависимости от внедор-специфичных алгоритмов. Служат для распределения нагрузки и обеспечения отказоустойчивости.

 

А теперь резонный вопрос: «А нафига всё это?». Даже не нафига это в операторских сетях, а нафига это *вообще*? Нет, мне как прирождённому параноику вопросы построения флоу очень даже близки... Но тут бодливой корове Бог рогов не дал... Крупным сетям может быть приглянется тегирование Q-in-Q, PBB или MPLS... Но свичи и так умеют это делать и без OpenFlow, и точно так же в соответствии с разумением отдельного вендора. QoS, «красивая» «раскраска» трафика? Опять всё вендорспецифично. Что-то замутить на клиентском уровне? Дык, где оно ж на клиентском-то...

 

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

[nuclearcat]

Если рассматривать openflow как протокол для самостоятельного создания control plane - очень неплохое решение.

Ибо гибкости того же junos/ios часто не хватает, у каждого вендора своя идеология построения конфигурации, и иногда чуть-чуть чего-то не хватает.

В идеале конечно, а вот как реально обстоят дела в железе - я не смотрел

[wanderer_from]

SDN - это про маркетинг.

[Macil]

Если рассматривать openflow как протокол для самостоятельного создания control plane - очень неплохое решение

Чем именно неплохое? Нет, если есть ДЦ со 100500 коммутаторами в каждый порт которых воткнут определённый физический актив, и стоит задача по наступлению события собирать определённую конфигурацию, тут OpenFlow рулит.

 

А в сетях оператора или сетях предприятия задача стоит совершенно другая: есть 100500 пользователей, и несколько видов ресурсов к которым нужно обеспечить доступ. Если сеть большая — через n уровней агрегации.

 

Может быть и удастся сделать диалектический оборот и создавать сети с паутинной топологией на манер первых ПионерНетов, но: а) OpenFlow должна проникнуть на уровень доступа; б) не на существующей инфраструктуре работающего оператора. И вообще, это всё ненаучная фантастика.

[Macil]

Правильнее всего рассматривать SDN, как framework-платформу, которая позволяет сетевым администраторам как динамически, так и автоматически контролировать большое количество сетевых устройств, услуг, топологий и маршрутизации. Контролировать трафик, и обработку пакетов (включая качество обслуживания - QoS). Выстраивать различные политики с использованием языков высокого уровня и API.

Идея управляемого хаоса? Давайте забьём на архитектуру, фен-шуй, регулярность, планирование. Голая целесообразность! Половина коммутатора выполняет роль коммутатора доступа, другая половина — агрегации. Нормально! Районный узел коммутации? Зачем? Сегодня узел здесь, завтра — там. Опорная сеть? Совокупность линков, живущая своей бурной жизнью...

 

С другой стороны: географическая привязка каждого устройства, статистика как инструмент управления. Решения о строительстве принимаются на основании реальных показателей работы. Можно обосновать что строительство линка А -> B нужнее линка C -> D потому-то, и потому-то. Новое решение в сети? Мы можем плавно, с гранулярностью вплоть до конкретного флоу абонента, производить миграцию... И так же плавно откатывать назад. Мы можем сочетать архитектурные решения от полного пионернета где-нибудь в сельской местности, заканчивая полнейшим фен-шуем (который, собственно говоря, уже не будет SDN) в рамках какого-нибудь нового малоэтажного жилого комплекса.

 

Мечтать можно много. Теперь — реальность.

 

1. Нужны специалисты по OpenFlow и NETCONF. Их нет сегодня, и их не будет завтра. Вот например, никто мне не попрекнул что я сдуру залез не в тот раздел сайта ONF и слил спецификацию 1.4.1 вместо последней 1.5.1 в которой добавлены интересные и нужные вещи. Семантика OpenFlow сложна, семантика NETCONF — ещё более сложная. В результате, нужны специалисты с высокой квалификацией и соответствующим ценником за пределами возможностей телекома.

 

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

 

3. Нужны специалисты по управлению сетью. Это совершенно нетехническая должность. Нужно строить модели, обрабатывать информацию из системы управления, на её основе в соответствии со стратегией развития принимать решения, вырабатывать оперативные планы в соответствии с текущими условиями. И если я хотя бы теоретически представляю где брать специалистов из п.1 и п.2, то здесь... Это чисто уникальные специалисты, скорее в единственном экземпляре.

 

«Коробочное» решение не освобождает от наличия в штате подобных специалистов. Остаётся одно: аутсорс. Вернее — франчайзинг. Вкладывайте деньги, нанимайте оперативных специалистов, закупайте оборудование, стройте линки, ведите свою абонентскую политику... А мы вам — управление, консультации, обучение. Прибыль пополам. Увы, опять новогодние сказки.

[wanderer_from]

Идея управляемого хаоса? Давайте забьём на архитектуру, фен-шуй, регулярность, планирование. Голая целесообразность! Половина коммутатора выполняет роль коммутатора доступа, другая половина — агрегации. Нормально! Районный узел коммутации? Зачем? Сегодня узел здесь, завтра — там. Опорная сеть? Совокупность линков, живущая своей бурной жизнью...

ты так говоришь, как-будто это что-то плохое.

Появятся оборудование, спеки, софт. Скоро. Появятся и специалисты. Пока это действительно все сложно и трудно. Зато когда будут промышленные реализации NetCONF, OF, FNV и прочего - строить сети из кирпичиков будет на порядок проще. И быстрее. Потому что API и веб-интерфейсы, через которое, собственно, и будут управляться эти сети.

 

Но не сегодня и не завтра, согласен. Лет пять-семь.

[Macil]

Появятся оборудование, спеки, софт. Скоро. Появятся и специалисты.

Появятся. Куда они денутся? Бабло распилють, бюджеты освоють...

 

И специалисты, может быть, появятся. Только вопрос, сможет ли их себе позволить телеком? Как я понимаю, львиная доля затрат телекома — реальная: строительство, оборудование, оперативный персонал (монтажники, техподдержка, проектировшики-согласовальщики-заносильщики). Затраты на управление — минимум: архитекторы, специалисты по стратегическому планированию, финансовые аналитики, маректологи и т.п. есть только у очень крупных операторов. Сможет ли SDN снизить «реальные» затраты телекома? Ясен пень, однозначно «не сегодня»... Но я сомневаюсь, что даже чисто теоретически.

 

SDN как концепция способна дать много разнообразной управленческой информации: шутка ли, мониторинг развития сети в реальном времени просто так «в нагрузку». Дык, а кому она будет нужна, если соответствующие «спецы» есть только у «крупняка», а «крупняку» она в любом случае не нужна, так как его деятельность строится по другим принципам? Значит не будет никакого эффекта от оптимизации управления.

 

Сможет ли SDN снизить масштабные коэффициенты? Тоже весьма и весьма сомнительно. Тут опять на первом месте чёртова физика...

 

Сможет ли SDN позволить «зайти» туда куда Макар телят не гонял? Даёшь стратегию голубого океана в массы! Вот тут — может быть. Но всё-равно, куда важнее «комплексный» подход т.е. посадка на госресурсы.

 

Ещё одна серьёзная проблема, операторы класса Монополиста-Мироеда (и наши и импортные) уже вложились в PON. В самый мерзейший вариант PON: GPON. Смешно однако, но сей плод любви пьяных КТВшников и наркоманов из ITU-T — на данный момент наиболее приближенная к SDN концепция. Учитывая что у них в качестве опорной сети обычно SDH, то они могут позволить себе лет дцать сидеть на ж..., кормясь чисто маркетингом/демпингом/подачками от государства.

 

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

[saaremaa]

Имею мнение что пойдет это все туда же куда и IPV6.

[wanderer_from]

Сможет ли SDN снизить «реальные» затраты телекома? Ясен пень, однозначно «не сегодня»... Но я сомневаюсь, что даже чисто теоретически.

"реальные затраты" однозначно снизятся. Ошибка рассуждений заключается в том, что вы принимаете тот факт, что специалист должен разбираться по-полной в оборудовании - от производства чипов, до реализаци протокола мессенджера. Но на самом деле - это же не так. SDN просто снимет необходимость знать и понимать низкоуровневые протоколы. А высокоуровневые поддаются всяческой автоматизации.

 

Сможет ли SDN снизить масштабные коэффициенты? Тоже весьма и весьма сомнительно. Тут опять на первом месте чёртова физика...

Например, "чертова физика" занимает нехилую долю на рынке смартфонов. И вот тот же Андроид нисколечко не уронил коэффициент масштабируемости - как раз наоборот... Есть еще одно модное слово, которого выше не встретил: "коммодитизация". это значит, что сетевые универсальные устройства будут штамповаться большими тиражами, которые будут на порядки дешевле. А такая фигня, как "Смена протоколов", например, может происходить на всей сети быстро и безопасно. Без выноса трех четвертей оборудования.

 

SDN как концепция способна дать много разнообразной управленческой информации: шутка ли, мониторинг развития сети в реальном времени просто так «в нагрузку». Дык, а кому она будет нужна, если соответствующие «спецы» есть только у «крупняка», а «крупняку» она в любом случае не нужна, так как его деятельность строится по другим принципам? Значит не будет никакого эффекта от оптимизации управления.

Оптимизация возникнет от автоматизации. Про ПОН холиварить не буду :) (я согласен)

[Sergey Gilfanov]

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

IPv6 не требует выноса трех четвертей оборудования. Т.к. коммутаторам (L2) - должно быть пофиг, а иметь маршрутизаторы, которые ну совсем, на уровне железа, IPv6 не умеют - ну это очень стараться нужно было при построении сети. Однако что-то замена соответствующего софта и внедрение этого IPv6 как-то медленно и печально происходит.

А не 'быстро и безопасно'.

[zi_rus]

IPv6 не требует выноса трех четвертей оборудования

однако требует. другое дело что поддержка Ipv6 уже много лет обеспечивается практически во всем железе, так и SDN сейчас в топ железки запиливается

 

Однако что-то замена соответствующего софта и внедрение этого IPv6 как-то медленно и печально происходит.

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

SDN по сути никакой такой проблемы не решает, конфигурировать канал связи между двумя точками успешно получается и в классической сети. в лучшем случае его будут интегрировать во вновь строящихся ЦОД, да и то все будет зависеть от заказчика, один захочем снизить ОРЕХ и выберет SDN, а другой скажет что у него нет спецов так что делайте обычную сеть и не сношайте мозг какой-то непонятной фигней.

[Картуччо]

райп по сусекам поскребет

На днях где-то попадалось, что поскребли и нашли, количество свободных адресов существенно увеличилось.

C IPv6 кроме веб доступа к интернет гигантам в остальном куча проблем, которые решаются очень медленно.

В плане предоставления конкурентноспособной услуги пока что практичнее использовать CGN.

[Умник]

Macil, что же вы так переживаете? Значит эти технологии просто не нужны вам и вашей сети. Значит все задачи вы можете решить при помощи инструментов, которые настраиваются при помощи простого CLI оборудования вашего вендора. Ну и отлично. Google вот со своей огромной сетью, например, не смог, поэтому обратился к SDN. Посмотрите:

 

У них есть и других презентации. Поищите-посмотрите. Очень интересно. Возможно, что кто-то еще кроме них дорос, но не рассказывает. В любом случае исходить нужно из задач и подбирать (или создавать самому, если найти нельзя) соответствующие инструменты (или стандарты, но это уже совсем круто).

[Умник]

Имею мнение что пойдет это все туда же куда и IPV6.

И куда это у нас IPv6 пошел, расскажите?

[Умник]

поскребли и нашли

Вы этот proposal имеете ввиду? https://www.ripe.net/participate/policies/proposals/2015-05

[zi_rus]

Google вот со своей огромной сетью, например, не смог

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

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

[saaremaa]

И куда это у нас IPv6 пошел, расскажите?

Как стали заканчиваться адреса пели какая "классная" технология как будет здорово и каждый будет доволен. Прошло время а IPV6 никуда и не пошел - на месте стоит (считайте пошел на...к).

[Умник]

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

Хм. Я вроде бы об этом и написал. Всегда исходим из поставленных задач.

 

saaremaa, как так?

 

https://www.google.ru/ipv6/statistics.html

 

С 2012 года - с 0,3% до 10%. Причем это в среднем по миру. В Бельгии, например, 43%.

[saaremaa]

С 2012 года - с 0,3% до 10%. Причем это в среднем по миру. В Бельгии, например, 43%.

Мы с Вами в Бельгии живем? Давайте за Русь-Матушку.

Percentage of IPv6 users in Russia 0.16% (2012) → 0.76% (2016)

Меньше 1%, Карл! У нас в Литве еще меньше. Дальнейший диалог считаю бессмысленным по IPV6.

[Умник]

Не знаю, причем здесь Карл (мы же в России, правда?), но я не могу понять вашу мысль. Мне вот кажется, что невысокий процент проникновения IPv6 конкретно в РФ и в других странах не может говорить о том, что что-то не так с IPv6, но говорит о том, что что-то не так с этими странами.

[Картуччо]

пели какая "классная" технология как будет здорово и каждый будет доволен

Так пели далеко не все.

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

Что характерно, так оно и произошло. Экспериментаторы обнаружили, что на роутерах мыльницах запросто IPv6 не защищается вообще никак,

и можно в админку снаружи заходить.

[Умник]

Точнее, конечно, с провайдерами, которые в этих странах работают.

 

Экспериментаторы обнаружили, что на роутерах мыльницах запросто IPv6 не защищается вообще никак

И что, в этом виноваты разработчики протокола IPv6?

[Картуччо]

Разработчики, конечно, нет.

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

даже более того, нахрен не нужен и опасен.

[ChargeSet]

Большинство спокойно сидит за двумя NAT и не парятся. У меня вот как раз такой случай: Провайдер натит нас, абонентов (на роутер приходит 10.х.х.х), а вот у меня, как одного из, два телика, комп, планшет и два смарта, все ходят в интернет и никто не жалуется. Роутер умеет ip6, домашняя сеть тоже, но никто не просит. Ipv6 сейчас просто не нужен, ровно как и не особо нужен sdn.

[zi_rus]

Большинство спокойно сидит за двумя NAT и не парятся

какое прогрессивное решение, а потом что делать? тройной нат? четверной? n-ный?