Как стать автором
Обновить

Комментарии 12

Скажите мне, пожалуйста, ответ на главный вопрос: в openflow есть возможность упреждающей загрузки правил с запретом отправки пакетиков на инспекцию?

То, что я видел — выглядело как влажный ночной кошмар сетевого администратора, когда незнакомые flow отправляются на инспекцию. Влажный — это udp. Ночной — это завёрнутыми в TCP и SSL. Кошмар — это когда таких придёт несколько гигабит.
Это можно сделать даже несколькими разными способами: поставить флаг OFPPC_NO_PACKET_IN на конкретный порт, либо поставить table-miss правило с пустым экшном (drop). Вообще многие кошмары, фобии и предрассудки относительно openflow отпадают сами собой при внимательном ознакомлении с их спецификацией. Другое дело, что не всякий свитч (особенно физический) поддерживает те или иные аспекты этой спецификации.
Как прекратить слать с помощью flow в табличке, я понимаю.

Скажите мне, можно ли на коммутатор _сначала_ загрузить правила через openflow, и только потом подпускать его к трафику?

Потому что я говорил с сетевыми товарищами, их интересует вариант, когда они flowtable для коммутатора по его портам могут грузить асинхронно от проходящего трафика, а не реактивно, по факту его появления. Для понимания, «товарищи» занимаются сетями с загрузкой по 500-2500Г на каждый маршрутизатор через быгыпы.
Да, можно и нужно. За некоторыми исключениями использование реактивных флоу это признак кривого дизайна.
А можно конкретные примеры конфигураций? Я понимаю, что я могу пойти и почитать всё это, но вот по конкретному вопросу — мол, 40Г коммутатор фирмы «асус» цепляется к флоуконтроллеру с такими-то настройками, а коммутатор фирмы «дылинк» — вот с такими. А на контроллере вот такой минимальный конфиг.

Потому что пока что у меня от openflow, силами openvswitch (точнее, его нетлинка между dataplane и control plane, работавшем до некоторого времени в подобии openflow без звёздочек), крайне негативные впечатления.
Для простейшего примера можно взять тестбед на опенвсвиче, положить туда статические правила форвардинга и нагрузить его трафиком, потом — повторить то же на любом коммутаторе с OF. OVS с dpdk способен вытянуть полсотни гигабит на обычном сервере, windriver на допиленном хвастаются двумя сотнями.
Дело не в том, чтобы «нагрузить трафиком», а в том, что OVS дох (мегафлоу, вроде, дело поправили, но rackspace на openstack summit говорил, что не до конца) даже в режиме без «openflow-контроллера».

Если же к этому добавить падающий openflow-контроллер, то за сеть становится страшно.
Не хочу плохо говорить про рекспейс, но у них дохлый стек (тот, на котором они сейчас живут), и дикий eviction/addition rate, о ненужности чего было сказано ранее. Что они в той презентации навернули через xapi и зачем — непонятно. Они стучатся лбом о грабли реактивного подхода по кругу, проблемы неудивительны.
Да, чтобы не повторяться в нюансах — тут все расписано. Сейчас мы выросли еще дальше, так как требуется процессить бОльшие объемы трафика, плюс сделали BGP redistribution.
Интересно было бы посмотреть на практическую реализацию!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий