# Revision history [back]

### Forwarding Rules Manager (FRM) does not create a FLOW-MOD message.

Hello community,

I'm trying to use the Learning-Switch sample from "openflowplugin/samples/learning-switch/", described in the wiki, in MD-SALAppTutorial.

I got the setting working in general, the "all-to-controller" flow is established and packets can be forwarded by the controller to the destination. However, the programming of the "mactomac flows" does not work.

It works up to:

dataStoreAccessor.writeFlowToConfig(flowPath, srcToDstFlow.build());


So, I can see the flow via RESTCONF in the config tree of the node. But a FLOW-MOD message is never sent (verified with wireshark).

Establishing a the flow via RESTCONF works fine (and I can see the FLOW-MOD message in wireshark). In order to create this restconf request I display all flows in the config tree of my node. Here, the "not established" flow is shown, as I just said. Using just this XML-output to create a new restconf request successfully creates the flow on the openflow switch (I only have to change the ID). So, I guess the flow is syntactically correct.

The questing is, why does the Forwarding Rules Manager (FRM) not issue an Flow-Mod message? Has somebody encountered similar behavior?

Can anyone give me a hint how to debug the asynchronous flow programming (and probably the FRM) to find out where my request got stuck?

Thanks,

Mario

### Forwarding Rules Manager (FRM) does not create a FLOW-MOD message.

Hello community,

I'm trying to use the Learning-Switch sample from "openflowplugin/samples/learning-switch/", described in the wiki, in MD-SALAppTutorial.

I got the setting working in general, the "all-to-controller" flow is established and packets can be forwarded by the controller to the destination. However, the programming of the "mactomac flows" does not work.

It works up to:

dataStoreAccessor.writeFlowToConfig(flowPath, srcToDstFlow.build());


So, I can see the flow via RESTCONF in the config tree of the node. But a FLOW-MOD message is never sent (verified with wireshark).

Establishing a the flow via RESTCONF works fine (and I can see the FLOW-MOD message in wireshark). In order to create this restconf request I display all flows in the config tree of my node. Here, the "not established" flow is shown, as I just said. Using just this XML-output to create a new restconf request successfully creates the flow on the openflow switch (I only have to change the ID). So, I guess the flow is syntactically correct.

The questing is, why does the Forwarding Rules Manager (FRM) not issue an Flow-Mod message? Has somebody anybody encountered similar behavior?

Can anyone give me a hint how to debug the asynchronous flow programming (and probably the FRM) to find out where my request got stuck?

Thanks,

Mario

### [Update] Forwarding Rules Manager (FRM) does not create a FLOW-MOD message.

Hello community,

I'm trying to use the Learning-Switch sample from "openflowplugin/samples/learning-switch/", described in the wiki, in MD-SALAppTutorialMD-SAL_App_Tutorial.

I got the setting working in general, the "all-to-controller" flow is established and packets can be forwarded by the controller to the destination. However, the programming of the "mactomac flows" does not work.

It works up to:

dataStoreAccessor.writeFlowToConfig(flowPath, srcToDstFlow.build());


So, I can see the flow via RESTCONF in the config tree of the node. But a FLOW-MOD message is never sent (verified with wireshark).

Establishing a the flow via RESTCONF works fine (and I can see the FLOW-MOD message in wireshark). In order to create this restconf request I display all flows in the config tree of my node. Here, the "not established" flow is shown, as I just said. Using just this XML-output to create a new restconf request successfully creates the flow on the openflow switch (I only have to change the ID). So, I guess the flow is syntactically correct.

The questing is, why does the Forwarding Rules Manager (FRM) not issue an Flow-Mod message? Has anybody encountered similar behavior?

Can anyone give me a hint how to debug the asynchronous flow programming (and probably the FRM) to find out where my request got stuck?

+++ UPDATE: +++ I found out that the flow-mod messages will be sent successfully under certain circumstances:

If the switch gets disconnected from the controller after a flow should have been installed and reconnected again, then Opendaylight actually pushes the flow to the switch.

This means that the entry in the data store is perfectly fine, but the creation of the flow-mod message is just not triggered.

Can anyone confirm this issue?

Whom should I address in a bug report, MD-SAL, the Forwarding Rules Manager or maybe the Openflow plugin? I'm just not sure which component misses/looses the initial flow-establishment event. +++

Thanks,

Mario

### [Update] Forwarding Rules Manager (FRM) does not create a FLOW-MOD message.

Hello community,

I'm trying to use the Learning-Switch sample from "openflowplugin/samples/learning-switch/", described in the wiki, in MD-SAL_App_Tutorial.

I got the setting working in general, the "all-to-controller" flow is established and packets can be forwarded by the controller to the destination. However, the programming of the "mactomac flows" does not work.

It works up to:

dataStoreAccessor.writeFlowToConfig(flowPath, srcToDstFlow.build());


So, I can see the flow via RESTCONF in the config tree of the node. But a FLOW-MOD message is never sent (verified with wireshark).

Establishing a the flow via RESTCONF works fine (and I can see the FLOW-MOD message in wireshark). In order to create this restconf request I display all flows in the config tree of my node. Here, the "not established" flow is shown, as I just said. Using just this XML-output to create a new restconf request successfully creates the flow on the openflow switch (I only have to change the ID). So, I guess the flow is syntactically correct.

The questing is, why does the Forwarding Rules Manager (FRM) not issue an Flow-Mod message? Has anybody encountered similar behavior?

Can anyone give me a hint how to debug the asynchronous flow programming (and probably the FRM) to find out where my request got stuck?

+++ UPDATE: +++ I found out that the flow-mod messages will be sent successfully under certain circumstances:

If the switch gets disconnected from the controller after a flow should have been installed and reconnected again, then Opendaylight actually pushes the flow to the switch.

This means that the entry in the data store is perfectly fine, but the creation of the flow-mod message is just not triggered.

Can anyone confirm this issue?

Whom should I address in a bug report, MD-SAL, the Forwarding Rules Manager or maybe the Openflow plugin? I'm just not sure which component misses/looses the initial flow-establishment event. +++

event.

Thanks,

Mario

### [Update] Forwarding Rules Manager (FRM) does not create a FLOW-MOD message.

Hello community,

I'm trying to use the Learning-Switch sample from "openflowplugin/samples/learning-switch/", described in the wiki, in MD-SAL_App_Tutorial.

I got the setting working in general, the "all-to-controller" flow is established and packets can be forwarded by the controller to the destination. However, the programming of the "mactomac flows" does not work.

It works up to:

dataStoreAccessor.writeFlowToConfig(flowPath, srcToDstFlow.build());


So, I can see the flow via RESTCONF in the config tree of the node. But a FLOW-MOD message is never sent (verified with wireshark).

Establishing a the flow via RESTCONF works fine (and I can see the FLOW-MOD message in wireshark). In order to create this restconf request I display all flows in the config tree of my node. Here, the "not established" flow is shown, as I just said. Using just this XML-output to create a new restconf request successfully creates the flow on the openflow switch (I only have to change the ID). So, I guess the flow is syntactically correct.

The questing is, why does the Forwarding Rules Manager (FRM) not issue an Flow-Mod message? Has anybody encountered similar behavior?

Can anyone give me a hint how to debug the asynchronous flow programming (and probably the FRM) to find out where my request got stuck?

+++ UPDATE: +++ +++

I found out that the flow-mod messages will be sent successfully under certain circumstances:

If the switch gets disconnected from the controller after a flow should have been installed and reconnected again, then Opendaylight actually pushes the flow to the switch.

This means that the entry in the data store is perfectly fine, but the creation of the flow-mod message is just not triggered.

Can anyone confirm this issue?

Whom should I address in a bug report, MD-SAL, the Forwarding Rules Manager or maybe the Openflow plugin? I'm just not sure which component misses/looses the initial flow-establishment event.

Thanks,

Mario

### [Update] Forwarding Rules Manager (FRM) does not create a FLOW-MOD message.message. [Update]

Hello community,

I'm trying to use the Learning-Switch sample from "openflowplugin/samples/learning-switch/", described in the wiki, in MD-SAL_App_Tutorial.

I got the setting working in general, the "all-to-controller" flow is established and packets can be forwarded by the controller to the destination. However, the programming of the "mactomac flows" does not work.

It works up to:

dataStoreAccessor.writeFlowToConfig(flowPath, srcToDstFlow.build());


So, I can see the flow via RESTCONF in the config tree of the node. But a FLOW-MOD message is never sent (verified with wireshark).

Establishing a the flow via RESTCONF works fine (and I can see the FLOW-MOD message in wireshark). In order to create this restconf request I display all flows in the config tree of my node. Here, the "not established" flow is shown, as I just said. Using just this XML-output to create a new restconf request successfully creates the flow on the openflow switch (I only have to change the ID). So, I guess the flow is syntactically correct.

The questing is, why does the Forwarding Rules Manager (FRM) not issue an Flow-Mod message? Has anybody encountered similar behavior?

Can anyone give me a hint how to debug the asynchronous flow programming (and probably the FRM) to find out where my request got stuck?

+++ UPDATE: +++

I found out that the flow-mod messages will be sent successfully under certain circumstances:

If the switch gets disconnected from the controller after a flow should have been installed and reconnected again, then Opendaylight actually pushes the flow to the switch.

This means that the entry in the data store is perfectly fine, but the creation of the flow-mod message is just not triggered.

Can anyone confirm this issue?

Whom should I address in a bug report, MD-SAL, the Forwarding Rules Manager or maybe the Openflow plugin? I'm just not sure which component misses/looses the initial flow-establishment event.

Thanks,

Mario