Pull to refresh

Comments 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.
Интересно было бы посмотреть на практическую реализацию!
Sign up to leave a comment.