Пользовательский OpenFlow через OpenDaylight не имеет никакого эффекта - PullRequest
Новая
       8

Пользовательский OpenFlow через OpenDaylight не имеет никакого эффекта

0 голосов
/ 11 мая 2018

У меня есть две виртуальные машины в облаке OpenStack.Используя следующую команду, я могу отправить данные между ними: 

# On the server (IP 10.0.0.7)    
nc -u -l -p 7865

# On the client (10.0.0.10)
nc -u 10.0.0.7 7865

Теперь я хотел бы заблокировать связь с 10.0.0.10 до 10.0.0.7 (но все же разрешить ее в другом направлении).Итак, я создаю этот поток: 

root@ubuntu:/opt/stack/opendaylight# cat my_custom_flow.xml 
<?xml version="1.0"?>
<flow xmlns="urn:opendaylight:flow:inventory">
  <priority>1</priority>
  <flow-name>nakrule-custom-flow</flow-name>
  <idle-timeout>12000</idle-timeout>
  <match>
    <ethernet-match>
      <ethernet-type>
        <type>2048</type>
      </ethernet-type>
    </ethernet-match>
    <ipv4-source>10.0.0.10/32</ipv4-source>
    <ipv4-destination>10.0.0.7/32</ipv4-destination>
    <ip-match>
      <ip-dscp>28</ip-dscp>
    </ip-match>
  </match>
  <id>10</id>
  <table_id>0</table_id>
  <instructions>
    <instruction>
      <order>6555</order>
    </instruction>
    <instruction>
      <order>0</order>
      <apply-actions>
        <action>
          <order>0</order>
          <drop-action/>
        </action>
      </apply-actions>
    </instruction>
  </instructions>
</flow>

Затем я отправляю поток на мой коммутатор.Я использую OpenDaylight в качестве контроллера SDN для управления моим облаком OpenStack.У меня есть два переключателя, br-int и br-ex.Порт для каждой виртуальной машины в OpenStack создается на br-int.Я могу получить идентификатор коммутатора с помощью следующей команды: 

curl -u admin:admin http://192.168.100.100:8181/restconf/config/opendaylight-inventory:nodes | python -m json.tool | grep '"id": "openflow:'[0-9]*'"' 

"id": "openflow:2025202531975591"
"id": "openflow:202520253197559"

Коммутатор с идентификатором 202520253197559 имеет много потоков в своей таблице, в то время как другой имеет значение 2-3.Поэтому я предполагаю, что 202520253197559 - это br-int, и поэтому добавьте в него свой новый поток с помощью следующей команды: 

curl -u admin:admin -H 'Content-Type: application/yang.data+xml' -X PUT -d @my_custom_flow.xml http://192.168.100.100:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:202520253197559/table/234/flow/10

Теперь я могу увидеть свой поток с помощью другого запроса REST: 

curl -u admin:admin http://192.168.100.100:8181/restconf/config/opendaylight-inventory:nodes | python -m json.tool

{
    "flow-name": "nakrule-custom-flow",
    "id": "10",
    "idle-timeout": 12000,
    "instructions": {
        "instruction": [
            {
                "order": 6555
            },
            {
                "apply-actions": {
                    "action": [
                        {
                            "drop-action": {},
                            "order": 0
                        }
                    ]
                },
                "order": 0
            }
        ]
    },
    "match": {
        "ethernet-match": {
            "ethernet-type": {
                "type": 2048
            }
        },
        "ip-match": {
            "ip-dscp": 28
        },
        "ipv4-destination": "10.0.0.7/32",
        "ipv4-source": "10.0.0.10/32"
    },
    "priority": 1,
    "table_id": 0
},

Однако затем я возвращаюсь к своим двум виртуальным машинам, они все еще могут успешно отправлять данные друг другу.Более того, использование следующей команды ничего не возвращает: 

ovs-ofctl dump-flows br-int --protocols=OpenFlow13 | grep nakrule

Я должен увидеть мой новый поток, означает ли это, что OpenDaylight не добавляет его в мой переключатель? 

root@ubuntu:/opt/stack# ovs-ofctl snoop br-int
2018-05-11T09:15:27Z|00001|vconn|ERR|unix:/var/run/openvswitch/br-int.snoop: received OpenFlow version 0x04 != expected 01
2018-05-11T09:15:27Z|00002|vconn|ERR|unix:/var/run/openvswitch/br-int.snoop: received OpenFlow version 0x04 != expected 01

Заранее спасибо.

1 Ответ

0 голосов
/ 11 мая 2018

вы уверены, что openflow: 1 - это идентификатор узла коммутатора (br-int), который Вы хотите программировать. Я сомневаюсь в этом. Обычно openflow: 1 это что-то мы видим из развертывания мининет.

сделать GET для API топологии через RESTCONF и выяснить идентификатор узла вашего переключателя (ов). Или вы можете догадаться, найдя Mac адрес используемого вами br-int и преобразование HEX в десятичное число.

Например, mininet на самом деле упрощает свои MAC-адреса, например 00: 00: 00: 00: 00: 01, поэтому он заканчивается открытым потоком: 1

другая проблема, которую я замечаю в вашем обновленном вопросе, заключается в том, что вы отправляете поток для таблицы 234 в URL, но указание таблицы 0 в потоке данные.

Кроме того, вы можете проверить config / store в restconf для этих узлов, чтобы посмотрите, принимает ли ODL поток. Если это в магазине конфигурации и этот переключатель подключен к плагину openflow, тогда поток должен быть нажатым на переключатель.

еще одно место, где можно найти подсказки, это karaf.log.

наконец, если вы думаете, что все правильно, и поток должен стать отправлено на коммутатор, но коммутатор не показывает поток, затем попробуйте сделать захват пакета. Возможно, ваш коммутатор отклоняет поток по какой-то причине. Это также может быть показано в журналах ovs, если это тот случай. Я сомневаюсь, что это в чем проблема, но просто добавив ее в случае.

...