Ask Your Question
0

how to debug flow table configuration failure(flow_mod message not generated)

asked 2015-07-23 22:33:30 -0700

sdnsdn gravatar image

Hi, we use ODL Helium SR3 as controller and indigo as switch, they are connected successfully. when we plan to configure flow table from Postman, Postman return 200 ok, but we found the flow_mod message is not generated, because we can't capture the flow mod message in wireshark.

the postman scripts is:

http://127.0.0.1:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/60/flow/6

<flow xmlns="urn:opendaylight:flow:inventory"></flow>

<priority>2</priority>
<flow-name>Foo</flow-name>
<id>6</id>
<table_id>60</table_id>
<instructions>
    <instruction>
        <order>0</order>
        <apply-actions>
            <action>
               <order>0</order>
               <dec-nw-ttl/>
            </action>
        </apply-actions>
    </instruction>
</instructions>

so we have to debug ODL. we enabled log:set TRACE org.opendaylight.controller. The log captured from ODL, no error log found. Does anyone know how to debug issue like that? And does anyone know the main procedure from rest api to flow_mod message generation? any suggestions are welcome, thanks.

2015-07-24 10:05:06,145 | DEBUG | qtp1145478749-76 | SnapshotBackedWriteTransaction | 220 - org.opendaylight.controller.sal-inmemory-datastore - 1.1.3.Helium-SR3 | Write Tx: DOM-OPER-10 allocated with snapshot org.opendaylight.yangtools.yang.data.api.schema.tree.spi.Version@7e2ae2f0

2015-07-24 10:05:06,187 | DEBUG | qtp1145478749-76 | SnapshotBackedWriteTransaction | 220 - org.opendaylight.controller.sal-inmemory-datastore - 1.1.3.Helium-SR3 | Write Tx: DOM-CFG-10 allocated with snapshot org.opendaylight.yangtools.yang.data.api.schema.tree.spi.Version@1907cd1b

2015-07-24 10:05:06,188 | TRACE | qtp1145478749-76 | BrokerFacade | 222 - org.opendaylight.controller.sal-rest-connector - 1.1.3.Helium-SR3 | Put CONFIGURATION via Restconf: /(urn:opendaylight:inventory?revision=2013-08-19)nodes/node/node[{(urn:opendaylight:inventory?revision=2013-08-19)id=openflow:1}]/AugmentationIdentifier{childNames=[(urn:opendaylight:flow:inventory?revision=2013-08-19)manufacturer, (urn:opendaylight:flow:inventory?revision=2013-08-19)hardware, (urn:opendaylight:flow:inventory?revision=2013-08-19)software, (urn:opendaylight:flow:inventory?revision=2013-08-19)serial-number, (urn:opendaylight:flow:inventory?revision=2013-08-19)description, (urn:opendaylight:flow:inventory?revision=2013-08-19)group, (urn:opendaylight:flow:inventory?revision=2013-08-19)table, (urn:opendaylight:flow:inventory?revision=2013-08-19)ip-address, (urn:opendaylight:flow:inventory?revision=2013-08-19)meter, (urn:opendaylight:flow:inventory?revision=2013-08-19)supported-match-types, (urn:opendaylight:flow:inventory?revision=2013-08-19)supported-instructions, (urn:opendaylight:flow:inventory?revision=2013-08-19)supported-actions, (urn:opendaylight:flow:inventory?revision=2013-08-19)switch-features]}/(urn:opendaylight:flow:inventory?revision=2013-08-19)table/table[{(urn:opendaylight:flow:inventory?revision=2013-08-19)id=60}]/flow/flow[{(urn:opendaylight:flow:inventory?revision=2013-08-19)id=6}]

2015-07-24 10:05:06,188 | DEBUG | qtp1145478749-76 | apshotBackedReadWriteTransaction | 220 - org.opendaylight.controller.sal-inmemory-datastore - 1.1.3.Helium-SR3 | Tx: DOM-CFG-10 Read: /(urn:opendaylight:inventory?revision=2013-08-19)nodes

2015-07-24 10:05:06,189 | DEBUG | qtp1145478749-76 | apshotBackedReadWriteTransaction | 220 - org.opendaylight.controller.sal-inmemory-datastore - 1.1.3.Helium-SR3 | Tx: DOM-CFG-10 Read: /(urn:opendaylight:inventory?revision=2013-08-19)nodes/node

2015-07-24 10:05:06,189 | DEBUG | qtp1145478749-76 | apshotBackedReadWriteTransaction | 220 - org.opendaylight.controller.sal-inmemory-datastore - 1.1.3.Helium-SR3 | Tx: DOM-CFG-10 Read: /(urn:opendaylight:inventory?revision=2013-08-19)nodes/node/node[{(urn:opendaylight:inventory?revision=2013-08-19)id=openflow:1}]

edit retag flag offensive close merge delete

1 answer

Sort by » oldest newest most voted
0

answered 2015-07-23 23:24:29 -0700

Ashwini_Mhatre gravatar image

Hi, following procedure will help u in understanding flow add method. A client application requests a flow add through the REST API of the Controller. (Note that in the AD-SAL, there is a dedicated NB REST API on top of the Flow Programming Service. The MD-SAL provides a common infrastructure where data and functions defined in models can be accessed by means of a common REST API. For more information, see http://datatracker.ietf.org/doc/draft-bierman-netconf-restconf/ ). The client application provides all parameters for the flow in the REST call. 1. Data from the ‘Add Flow’ request is deserialized, and a new flow is created in the Flow Service configuration data tree. (Note that in this example the configuration and operational data trees are separated; this may be different for other services). Note also that the REST call returns success to the caller as soon as the flow data is written to the configuration data tree. 2. Since the Flow Programmer Service is registered to receive notifications for data changes in the Flow Service data tree, the MD-SAL generates a ‘data changed’ notification to the Flow Programmer Service. 3. The Flow Programmer Service reads the newly added flow, and performs a flow add operation (which is basically the same as in the AD-SAL). 4. At some point during the flow addition operation, the Flow Programmer Service needs to tell the OF Plugin to add the flow in the appropriate switch. The Flow Programmer Service uses the OF Plugin generated API to create the RPC input parameter DTO for the “AddFlow” RPC of the OF Plugin. 5. The Flow Programmer Service gets the service instance (actually, a proxy), and invokes the “AddFlow” RPC on the service. The MD-SAL will route the request to the appropriate OF Plugin (which implements the requested RPC). 6. The ‘AddFlow’ RPC request is routed to the OF Plugin, and the implementation method of the “AddFlow” RPC is invoked. 7. The ‘AddFlow’ RPC implementation uses the OF Plugin API to read values from the DTO of the RPC input parameter. (Note that the implementation will use the getter methods of the DTO generated from the yang model of the RPC to read the values from the received DTO.)

Regards, Ashwini

edit flag offensive delete publish link more

Comments

Hi, Ashwini Many thanks, the flowadd procedure explanation is very clear. currently, the 1st step is ok, Rest API call returns 200 ok, and trace log show the flow is created at data tree. and how can I check the 2nd step and the latter? are there other log switch for them? log:set TRACE org.opendaylight.controller command is used by me now. Or could you show me the some key functions name and I can add log to trace the flowadd procedure. thanks. Regards, Terry

sdnsdn ( 2015-07-24 01:36:07 -0700 )edit

Hi, if you are using openvswitch u get logs from /var/log/openvswitch. that addflow method will take object of flow and that object of flow is converted into flow-mod meassage. if that object is in not proper format it will not add the flow. p.s please vote me by clicking on right sign if the above answer is useful to you. Regards, Ashwini mhatre

Ashwini_Mhatre ( 2015-07-24 02:54:50 -0700 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

[hide preview]

Question Tools

Follow
1 follower

Stats

Asked: 2015-07-23 22:33:30 -0700

Seen: 368 times

Last updated: Jul 23 '15