Opendaylight-boron Study notes: 5 Openflowplugin Module

environment and software release notes

===

Sn-controller:

Cpu:2 cores

Ram:4gb

Disk:32gb

Operating system:centos7 x86_64 1611 (Linux 3.10.0-514) Infrastructure Server

IP1:10.0.3.100/24 (Public Network)

IP2:172.16.3.100/24 (SDN Network)

===

Opendaylight:boron

Download Address Reference

OpenFlow Plugin Project User Guide

"Opendaylight Application Guide" (Hong Tang, etc.) Installing the Openflowplugin module

Go to ODL console Karaf and install Openflowplugin by executing the following command:

Opendaylight-user@root>feature:install odl-openflowplugin-nxm-extensions Odl-openflowplugin-flow-services-ui Odl-openflowplugin-flow-services-rest odl-openflowplugin-flow-services Odl-openflowplugin-southbound Odl-openflowplugin-nsf-model odl-openflowplugin-drop-test Odl-openflowplugin-app-table-miss-enforcer Odl-openflowplugin-app-config-pusher odl-openflowplugin-app-topology odl-openflowplugin-app-bulk-o-matic Odl-openflowplugin-app-notifications Odl-openflowplugin-app-forwardingrules-manager Odl-openflowplugin-app-forwardingrules-sync
Opendaylight-user@root>feature:install Odl-openflowplugin-app-lldp-speaker-he
Opendaylight-user@root>feature:install Odl-restconf-all Odl-restconf Odl-restconf-noauth

Functional Experience end-to-end inventory (end to end Inventory)

With ODL inventory, you can view the node information for the current record. The following first creates a simple topology using mininet:

mininet Virtual machine parameters: HOSTNAME:MININET-VM1 Cpu:2 Nuclear RAM:4GB ip1:10.0.3.101 (Public network) ip2:172.16.3.101 (SDN Network)

mininet@mininet-vm1:~$ sudo mn--topo=single,2--mac--controller=remote,ip=10.0.3.100,port=6633--switch Ovsk, Protocols=openflow13
mininet> sh ovs-vsctl show
918037ec-b307-45d7-a75a-f1ac4337d135
    Bridge "S1"
        controller "tcp:10.0.3.100:6633"
            is_connected:true
        Controller "ptcp:6654"
        fail_mode:secure
        Port "S1"
            Interface "S1"
                type:internal
        Port "s1-eth1"
            Interface "s1-eth1"
        port "S1-eth2"
            Interface "S1-eth2"
    ovs_version: "2.0.2"

At this point, send the following rest request toward ODL:

http://10.0.3.100:8181/restconf/operational/opendaylight-inventory:nodes/

method:get

Headers:
Accept:application/xml

After sending the request, after prompting for the corresponding user name (admin) and password (admin), you can get an XML file close to more than 2000 lines, which contains information about S1, including port, connection information, etc. Because the content is too long, so it is not posted. You can also output only one node, showing information about that node, such as sending a rest request to ODL to view information for the openflow:1 (corresponding S1) node:

Http://10.0.3.100:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:1

Method:get

Headers:
accept:application/xml

Because there is currently only one node (S1), the content returned is the same as querying information for all nodes. end-to-end flow (end to end flows)

With OpenFlow Plugin, you can use rest requests to add, delete, and modify flow tables for inventory nodes. Then the above experimental environment, first in the MININET-VM1 MN console to view the S1 flow table information:

mininet> sh ovs-ofctl-o OpenFlow13 dump-flows s1
ofpst_flow reply (OF1.3) (xid=0x2):
 cookie= 0x2b00000000000000, duration=1689.737s, table=0, n_packets=5, n_bytes=322, Priority=2,in_port=1 Actions=output:2, controller:65535
 cookie=0x2b00000000000001, duration=1689.737s, table=0, n_packets=4, n_bytes=280, priority=2, in_port=2 actions=output:1,controller:65535
 cookie=0x2b00000000000000, duration=1691.669s, table=0, n_packets= 0, N_bytes=0, priority=100,dl_type=0x88cc actions=controller:65535
 cookie=0xa, duration=1691.688s, table=0, N_ Packets=0, n_bytes=0, Send_flow_rem priority=0 actions=controller:65535

Send the following rest request to the ODL controller and add the flow table to S1.

HTTP://10.0.3.100:8181/RESTCONF/CONFIG/OPENDAYLIGHT-INVENTORY:NODES/NODE/OPENFLOW:1/TABLE/0/FLOW/1 Method:put Headers:content-type:application/xml accept:application/xml authentication:body: <?xml version= "1.0" encoding= " UTF-8 "standalone=" no "?> <flow xmlns=" Urn:opendaylight:flow:inventory "> <priority>2</priority > <flow-name>Foo</flow-name> <match> <ethernet-match> <ethernet-
        type> <type>2048</type> </ethernet-type> </ethernet-match> <ipv4-destination>10.0.3.0/24</ipv4-destination> </match> <id>1</id> &lt ;table_id>0</table_id> <instructions> <instruction> <order>0</order&
            Gt <apply-actions> <action> <order>0</order> &L
       T;dec-nw-ttl/>         </action> </apply-actions> </instruction> </instructions> &LT;/FL Ow>

It is worth noting that the rest of the request in the table after 0 and flow after the 1 to be separate and the body and the corresponding.

After the request is sent, a status code of 201 created is returned. Description added the flow table successfully. Verify in the MN console of the MININET-VM1:

mininet> sh ovs-ofctl-o OpenFlow13 dump-flows s1
ofpst_flow reply (OF1.3) (xid=0x2):

At this point, the S1 flow table becomes empty. I can not explain this, I thought it was a step before a problem, so continue the following operation, intend to do it again:

mininet> exit mininet@mininet-vm1:~$ sudo mn-c mininet@mininet-vm1:~$ sudo ovs-vsctl show 918037ec-b307-45d7-a75a-f1ac4337d135 ovs_version: "2.0.2" mininet@mininet-vm1:~$ sudo mn--topo=single,2--mac--contr oller=remote,ip=10.0.3.100,port=6633--switch ovsk,protocols=openflow13 mininet> pingall * * ping:testing Ping reachability H1, H2 H2, H1 * * results:0% dropped (2/2 received) mininet> sh Ovs-ofctl-o OpenFlow13 DUMP-FL OWS S1 ofpst_flow reply (OF1.3) (xid=0x2): cookie=0x2a00000000000009, duration=44.424s, table=0, N_packets=1, n_bytes=98 , idle_timeout=600, hard_timeout=300, priority=10,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02 actions=output : 2 cookie=0x2a00000000000008, duration=44.424s, table=0, n_packets=2, n_bytes=140, idle_timeout=600, hard_timeout=300 , priority=10,dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:01 actions=output:1 cookie=0x0, duration=51.902s,
Table=0, N_packets=0, n_bytes=0, priority=2,ip,nw_dst=10.0.3.0/24 Actions=dec_ttl cookie=0x2b00000000000002, duration=50.003s, table=0, n_packets=5, n_bytes=322, Priority=2,in_port=1 actions=output : 2,controller:65535 cookie=0x2b00000000000003, duration=50.003s, table=0, n_packets=4, n_bytes=280, Priority=2,in_ port=2 actions=output:1,controller:65535 cookie=0x2b00000000000001, duration=51.942s, table=0, N_packets=0, n_bytes= 0, priority=100,dl_type=0x88cc actions=controller:65535 cookie=0x2b00000000000001, duration=51.974s, table=0, N_ Packets=0, n_bytes=0, priority=0 Actions=drop

And then something magical happened. Since I have not yet sent a request to ODL to add a flow table, I find that S1 has the flow table after the last time the flow table was added. Is it not possible to show the flow table before because of a bug in Mininet itself?? cannot be explained. At this point I decided to delete the added stream table again:

HTTP://10.0.3.100:8181/RESTCONF/CONFIG/OPENDAYLIGHT-INVENTORY:NODES/NODE/OPENFLOW:1/TABLE/0/FLOW/1

Method :D elete

Headers:
accept:application/xml

This returns a status code of OK. Then view the S1 flow table in the MN controller of the MININET-VM1.

mininet> sh ovs-ofctl-o OpenFlow13 dump-flows s1
ofpst_flow reply (OF1.3) (xid=0x2):
 cookie= 0x2b00000000000002, duration=1866.44s, table=0, n_packets=5, n_bytes=322, Priority=2,in_port=1 Actions=output:2, controller:65535
 cookie=0x2b00000000000003, duration=1866.44s, table=0, n_packets=4, n_bytes=280, Priority=2,in _port=2 actions=output:1,controller:65535
 cookie=0x2b00000000000001, duration=1868.379s, table=0, N_packets=0, N_bytes=0, priority=100,dl_type=0x88cc actions=controller:65535
 cookie=0x2b00000000000001, duration=1868.411s , Table=0, N_packets=0, n_bytes=0, priority=0 Actions=drop

At this point, it can be found that the flow chart is not. Analysis: The rest request sent from the beginning is added to the config configuration of md-sal, as to why the addition of MN after the display can not come out, it may be a bug. Also because it is added to the config configuration, so when I redo the second time, it will automatically add this stream table. It may be possible to understand that the configuration in config configuration is permanent, but in the operational configuration is only temporary effect. Later, however, I tried to change the rest request to a operational configuration, and found that there was no such rest interface, indicating that the added flow table would only add to the config configuration. In addition, after I deleted the flow table, I did it again and found that after sending the rest request to add the flow table, I looked at the S1 flow table in MN and found the flow table again, so we can be more certain that this should be a bug of mininet.

Some XML examples of flow table settings are given in the ODL website:
Ofp-example-flows End-to-end topology (end to End topology)

Also continue to use the above experimental environment, you can see the current topology information using the rest request below:

http://10.0.3.100:8181/restconf/operational/network-topology:network-topology/

method:get

Headers:
Accept:application/xml

In the returned XML, you can see that there are 4 kinds of topology-id, namely: Flow:1 netvirt:1 ovsdb:1 hwvtep:1

The current 4 Topology-id, only flow:1 have content, the other 3 are empty. Recall before doing OVSDB module related experiments, I think, when the MN OvS as long as a connection controller, will appear in the Flow:1 node information, when the MN set up the manager, the Ovsdb:1 will appear in the node information. As for the other 2 has not yet been involved, so I do not know what the circumstances of the two Topology-id will have content.

The content of the end-to-end topology is only described so much, and rest requests only provide queries.