Сообщение об ошибке многочастного запроса Openflow: OFPBRC_BAD_LEN (6) - PullRequest
Новая
       64

Сообщение об ошибке многочастного запроса Openflow: OFPBRC_BAD_LEN (6)

1 голос
/ 11 октября 2019

Короче говоря, у меня есть проект, который требует от меня создания контроллера с нуля в python и обработки запросов от коммутаторов, созданных с помощью топологии mininet в соответствии с протоколом Open Flow.

Полезные ресурсы протокола Open Flow:

Мой код доступен здесь на github для клонирования и полной прозрачности:

  • [удалено по состоянию на 10.12.2009, см. Мой ответ ниже]

Проблема Iя сталкиваюсь с тем, что я не могу отправить сообщение multipart-request для описания статистики порта (поиск PortDesc по этой ссылке ). Я не знаю, почему это так, но когда я просматриваю пакетные данные в wireshark, я получаю сообщение об ошибке «Диапазон выходит за пределы». Я не смог понять, почему это так. Вот несколько снимков экрана с пакетными данными:

Захваты Wireshark: Bytes where I created the multipart request Openflow multipart request mess Full screenshot of the openflow protocol

Lua сообщения об ошибках: Lua error message part 1 Lua error message part 2

Bad Request Ошибка Сообщение Ответ: Bad request error message response enter image description here Здесь следует отметить, что код говорит OFPBRC_BAD_LEN (6), но длина байтов, отправляемых в запросе из нескольких частей, имеет размер16.

Одноклассник, который правильно отправил свои пакетные данные, сказал, что они использовали ту же структуру упаковки, что и я, за исключением того, что они успешно (см. Документацию по python struct). Я не знаю, в чем проблема с моими, и у меня заканчиваются идеи для проверки. Будем весьма благодарны за любые указатели.

TL; DR: Я не могу отправить многокомпонентный запрос, и хотя я придерживаюсь спецификаций запроса, результаты продолжают возвращаться с кодом ошибки. Ошибка в wireshark говорит: «Диапазон выходит за пределы», и я не знаю, как еще структурировать мой запрос для исправления этого сообщения об ошибке.

1 Ответ

1 голос
/ 13 октября 2019

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

Решение:

Как вы можете видеть на скриншотах выше, яотправлял пакеты OpenFlow в протоколе версии 1.5, который является самой новой версией, но при посещении документации уровня сообщений openflow отображается только документация до версии 1.4.

Кроме того, последняя версия многочастного запроса, показанная в документации, является 1.3.1. Даже когда я отправляю многокомпонентный запрос для Open Flow Protocol версии 1.5, он не отображается как OpenFlowProtocol, а как обычный пакет TCP. Я сделал следующие 3 вещи:

  1. В своем файле топологии, где я создал переключатель, я инициализировал переключатели как s1 = self.addSwitch( 's1'). Я добавил к этому утверждению параметр протокола: s1 = self.addSwitch( 's1', protocols='OpenFlow14').

  2. Для удобства я также добавил protocols спецификацию к команде mininet в консоли: sudo mn --custom mytopo.py --topo mytopo --controller=remote,ipaddr=127.0.0.1,port=6653,protocols=OpenFlow14

  3. Я также изменил способЯ упаковывал запросы, поэтому вместо указания версии 1.5 (которая в заголовке пакета обозначена как «06»), я упаковал его как 1.4 (в заголовке пакета это «05»). req = struct.pack('!BBHI',5,5,8,0) (например, для feature_request сообщения, отправленного на коммутатор).

Эти шаги решили проблему, с которой я столкнулся, и мне удалось получить stats_reply отПереключатель.

Проблема (или в чем, я думаю, проблема):

Я считаю, что проблема была в том, что КАК СЕЙЧАС, Open Flow Version 1.5 пока не поддерживаетдля составного запроса, о чем свидетельствует отправка составного запроса на описание порта, он показывает обычный протокол TCP вместо протокола OpenFlow.

...