[OPNFLWPLUG-184] Notification of FLOW_REMOVED is not sent when using the new OF plugin. Created: 09/Jun/14  Updated: 27/Sep/21  Resolved: 19/Jun/14

Status: Resolved
Project: OpenFlowPlugin
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Hideyuki Tai Assignee: Hideyuki Tai
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC

Issue Links:
Blocks
blocks OPNFLWPLUG-110 Milestone: AD-SAL Compatibility adapt... Resolved
External issue ID: 1167

 Description   

I run the Virtualization edition with vtn option with the new OF plugin, and I had VTN Manager install flow entries whose idle timeout was configured to 300.
After I waited 300 seconds, OpenFlow switches sent FLOW_REMOVED messages to the controller.
However, IFlowProgrammerListener.flowRemoved(Node, Flow) was not invoked, so VTN Manager didn't notice that.

Please note that when I run without the new OF plugin, but with the old OF plugin, IFlowProgrammerListener.flowRemoved(Node, Flow) was invoked correctly.

What I used
-----------

The latest version of the Virtualization Edition on 5th June.

$ pwd
/home/odp/work/integration

odc180 $ git log -3 --oneline
90e2f0c INTEGRAT-4: Remove toaster from virt edition
64e608a Adding extra TCs for RESTCONF
3516960 Uploaded working AD-SAL cluster testcases

How to produce
--------------

1. Start up the Virtualization edition with -of13 and vtn option.

$ ./run.sh -of13 -virt vtn

2. Create a virtual bridge using REST API exposed by VTN Manager.

curl --user "admin":"admin" -H "Accept: application/json" -H \
"Content-type: application/json" -X POST \
http://192.168.60.180:8080/controller/nb/v2/vtn/default/vtns/vtn1 \
-d '

{"description": "Virtual Tenat 1"}

'

curl --user "admin":"admin" -H "Accept: application/json" -H \
"Content-type: application/json" -X POST \
http://192.168.60.180:8080/controller/nb/v2/vtn/default/vtns/vtn1/vbridges/vbr1 \
-d '{}'

curl --user "admin":"admin" -H "Accept: application/json" -H \
"Content-type: application/json" -X POST \
http://192.168.60.180:8080/controller/nb/v2/vtn/default/vtns/vtn1/vbridges/vbr1/interfaces/if1 \
-d '{}'

curl --user "admin":"admin" -H "Accept: application/json" -H \
"Content-type: application/json" -X POST \
http://192.168.60.180:8080/controller/nb/v2/vtn/default/vtns/vtn1/vbridges/vbr1/interfaces/if2 \
-d '{}'

curl --user "admin":"admin" -H "Accept: application/json" -H \
"Content-type: application/json" -X PUT \
http://192.168.60.180:8080/controller/nb/v2/vtn/default/vtns/vtn1/vbridges/vbr1/interfaces/if1/portmap \
-d '{"node":

{"type":"MD_SAL","id":"openflow:3"}

, "port": {"name": "s3-eth1"}}'

curl --user "admin":"admin" -H "Accept: application/json" -H \
"Content-type: application/json" -X PUT \
http://192.168.60.180:8080/controller/nb/v2/vtn/default/vtns/vtn1/vbridges/vbr1/interfaces/if2/portmap \
-d '{"node":

{"type":"MD_SAL","id":"openflow:7"}

, "port": {"name": "s7-eth2"}}'

3. Run Mininet and run OF1.0 switches.

sudo mn --controller=remote,192.168.60.180 --topo tree,3

4. Send ping packets from h1 to h8.

mininet> h1 ping h8

At this time, VTN Manager installs ten flow entries into the switches based on the above configuration.

5. Check flow entries in mininet.

Two flow entries have "idle_timeout=300", in s3 and s7.

mininet> dpctl dump-flows

      • s1 ------------------------------------------------------------------------
        NXST_FLOW reply (xid=0x4):
        cookie=0x0, duration=295.615s, table=0, n_packets=0, n_bytes=0, idle_age=295, priority=10,in_port=1,dl_vlan=0,dl_src=e6:e1:fe:2f:2e:ea,dl_dst=6e:0c:a2:71:13:1c actions=output:2
        cookie=0x0, duration=295.69s, table=0, n_packets=0, n_bytes=0, idle_age=295, priority=10,in_port=2,dl_vlan=0,dl_src=6e:0c:a2:71:13:1c,dl_dst=e6:e1:fe:2f:2e:ea actions=output:1
      • s2 ------------------------------------------------------------------------
        NXST_FLOW reply (xid=0x4):
        cookie=0x0, duration=295.587s, table=0, n_packets=0, n_bytes=0, idle_age=295, priority=10,in_port=1,dl_vlan=0,dl_src=e6:e1:fe:2f:2e:ea,dl_dst=6e:0c:a2:71:13:1c actions=output:3
        cookie=0x0, duration=295.657s, table=0, n_packets=0, n_bytes=0, idle_age=295, priority=10,in_port=3,dl_vlan=0,dl_src=6e:0c:a2:71:13:1c,dl_dst=e6:e1:fe:2f:2e:ea actions=output:1
      • s3 ------------------------------------------------------------------------
        NXST_FLOW reply (xid=0x4):
        cookie=0x0, duration=295.588s, table=0, n_packets=0, n_bytes=0, idle_timeout=300, idle_age=295, priority=10,in_port=1,dl_vlan=0,dl_src=e6:e1:fe:2f:2e:ea,dl_dst=6e:0c:a2:71:13:1c actions=output:3
        cookie=0x0, duration=295.732s, table=0, n_packets=0, n_bytes=0, idle_age=295, priority=10,in_port=3,dl_vlan=0,dl_src=6e:0c:a2:71:13:1c,dl_dst=e6:e1:fe:2f:2e:ea actions=output:1
      • s4 ------------------------------------------------------------------------
        NXST_FLOW reply (xid=0x4):
      • s5 ------------------------------------------------------------------------
        NXST_FLOW reply (xid=0x4):
        cookie=0x0, duration=295.615s, table=0, n_packets=0, n_bytes=0, idle_age=295, priority=10,in_port=3,dl_vlan=0,dl_src=e6:e1:fe:2f:2e:ea,dl_dst=6e:0c:a2:71:13:1c actions=output:2
        cookie=0x0, duration=295.679s, table=0, n_packets=0, n_bytes=0, idle_age=295, priority=10,in_port=2,dl_vlan=0,dl_src=6e:0c:a2:71:13:1c,dl_dst=e6:e1:fe:2f:2e:ea actions=output:3
      • s6 ------------------------------------------------------------------------
        NXST_FLOW reply (xid=0x4):
      • s7 ------------------------------------------------------------------------
        NXST_FLOW reply (xid=0x4):
        cookie=0x0, duration=295.612s, table=0, n_packets=0, n_bytes=0, idle_age=295, priority=10,in_port=3,dl_vlan=0,dl_src=e6:e1:fe:2f:2e:ea,dl_dst=6e:0c:a2:71:13:1c actions=output:2
        cookie=0x0, duration=295.65s, table=0, n_packets=0, n_bytes=0, idle_timeout=300, idle_age=295, priority=10,in_port=2,dl_vlan=0,dl_src=6e:0c:a2:71:13:1c,dl_dst=e6:e1:fe:2f:2e:ea actions=output:3

6. Wait 300 seconds.

7. Check flow entries in mininet again.

The two flow entries whose idle_timeout is configured 300 is removed.

mininet> dpctl dump-flows

      • s1 ------------------------------------------------------------------------
        NXST_FLOW reply (xid=0x4):
        cookie=0x0, duration=365.604s, table=0, n_packets=0, n_bytes=0, idle_age=365, priority=10,in_port=1,dl_vlan=0,dl_src=e6:e1:fe:2f:2e:ea,dl_dst=6e:0c:a2:71:13:1c actions=output:2
        cookie=0x0, duration=365.679s, table=0, n_packets=0, n_bytes=0, idle_age=365, priority=10,in_port=2,dl_vlan=0,dl_src=6e:0c:a2:71:13:1c,dl_dst=e6:e1:fe:2f:2e:ea actions=output:1
      • s2 ------------------------------------------------------------------------
        NXST_FLOW reply (xid=0x4):
        cookie=0x0, duration=365.576s, table=0, n_packets=0, n_bytes=0, idle_age=365, priority=10,in_port=1,dl_vlan=0,dl_src=e6:e1:fe:2f:2e:ea,dl_dst=6e:0c:a2:71:13:1c actions=output:3
        cookie=0x0, duration=365.646s, table=0, n_packets=0, n_bytes=0, idle_age=365, priority=10,in_port=3,dl_vlan=0,dl_src=6e:0c:a2:71:13:1c,dl_dst=e6:e1:fe:2f:2e:ea actions=output:1
      • s3 ------------------------------------------------------------------------
        NXST_FLOW reply (xid=0x4):
        cookie=0x0, duration=365.721s, table=0, n_packets=0, n_bytes=0, idle_age=365, priority=10,in_port=3,dl_vlan=0,dl_src=6e:0c:a2:71:13:1c,dl_dst=e6:e1:fe:2f:2e:ea actions=output:1
      • s4 ------------------------------------------------------------------------
        NXST_FLOW reply (xid=0x4):
      • s5 ------------------------------------------------------------------------
        NXST_FLOW reply (xid=0x4):
        cookie=0x0, duration=365.603s, table=0, n_packets=0, n_bytes=0, idle_age=365, priority=10,in_port=3,dl_vlan=0,dl_src=e6:e1:fe:2f:2e:ea,dl_dst=6e:0c:a2:71:13:1c actions=output:2
        cookie=0x0, duration=365.667s, table=0, n_packets=0, n_bytes=0, idle_age=365, priority=10,in_port=2,dl_vlan=0,dl_src=6e:0c:a2:71:13:1c,dl_dst=e6:e1:fe:2f:2e:ea actions=output:3
      • s6 ------------------------------------------------------------------------
        NXST_FLOW reply (xid=0x4):
      • s7 ------------------------------------------------------------------------
        NXST_FLOW reply (xid=0x4):
        cookie=0x0, duration=365.6s, table=0, n_packets=0, n_bytes=0, idle_age=365, priority=10,in_port=3,dl_vlan=0,dl_src=e6:e1:fe:2f:2e:ea,dl_dst=6e:0c:a2:71:13:1c actions=output:2

I captured all packets on the OpenFlow channels by using tcpdump, and confirmed that switches sent FLOW_REMOVED messages to the controller.
However, IFlowProgrammerListener.flowRemoved(Node, Flow) was not invoked, so VTN Manager didn't notice that.

 Comments   
Comment by Michal Rehak [ 12/Jun/14 ]

https://git.opendaylight.org/gerrit/#/c/7950/

Hideyuki, could you retest, please?

Comment by Hideyuki Tai [ 13/Jun/14 ]

(In reply to michal rehak from comment #1)
> https://git.opendaylight.org/gerrit/#/c/7950/
>
> Hideyuki, could you retest, please?

Thank you!
I'll test it today.

Comment by Abhijit Kumbhare [ 13/Jun/14 ]

(In reply to Hideyuki Tai from comment #2)
> (In reply to michal rehak from comment #1)
> > https://git.opendaylight.org/gerrit/#/c/7950/
> >
> > Hideyuki, could you retest, please?
>
> Thank you!
> I'll test it today.

Looks like it needs merging into controller - adding EAW.

Comment by Hideyuki Tai [ 13/Jun/14 ]

(In reply to michal rehak from comment #1)
> https://git.opendaylight.org/gerrit/#/c/7950/
>
> Hideyuki, could you retest, please?

Hi Michal,

I pulled the latest code of Integration Git repository, and built the Virtualization Edition on 13th June.
And I applied the change of your patch to the Virtualization edition.

After that, I re-executed the same scenario I written in comment #1.
I confirmed that IFlowProgrammerListener.flowRemoved(Node, Flow) was invoked, so VTN Manager noticed that.

When OpenFlow switches on Mininet sent FLOW_REMOVED messages to the controller, I saw the following TRACE messages output by VTN Manager.
These meant that VTN Manger received the notifications.

2014-06-13 10:24:54.332 EDT [md-sal-binding-notification-247] TRACE o.o.v.m.internal.VTNManagerImpl - default: flowRemoved() called: node=MD_SAL|openflow:7,
flow=Flow[match = Match [fields=

{DL_DST=DL_DST(5a:3e:78:56:1e:6c), DL_VLAN=DL_VLAN(0), DL_SRC=DL_SRC(de:82:78:cc:9e:fd)}

, matches=14], actions = null, priori
ty = 10, id = 0, idleTimeout = 300, hardTimeout = 0]
2014-06-13 10:24:54.332 EDT [md-sal-binding-notification-241] TRACE o.o.v.m.internal.VTNManagerImpl - default: flowRemoved() called: node=MD_SAL|openflow:7,
flow=Flow[match = Match [fields=

{DL_DST=DL_DST(5a:3e:78:56:1e:6c), DL_VLAN=DL_VLAN(0), DL_SRC=DL_SRC(de:82:78:cc:9e:fd)}

, matches=14], actions = null, priori
ty = 10, id = 0, idleTimeout = 300, hardTimeout = 0]

However, action information in FLOW_REMOVED notification was wrong.
It should contain a "OUTPUT" action, but it was null.

Comment by Michal Rehak [ 19/Jun/14 ]

Right - missing instructions are caused by yang model. There are 2 types of flow removed notifications - one is fired upon successful sending of flowMod message to device and second is fired upon flow removal confirmation message received from device.
And the second one is used here and there are no instructions inside.

Is this necessary for VTN manager to have instructions contained in flowRemoved notification? The reason for not having instructions here is simple - instructions are not sent within this message (as defined by OF-1.3 spec.). And flow can be identified by combination of priority and match.

In case that instructions are necessary here, I would vote for creating another bug.

Thank you.

Comment by Hideyuki Tai [ 19/Jun/14 ]

(In reply to michal rehak from comment #5)
> Right - missing instructions are caused by yang model. There are 2 types of
> flow removed notifications - one is fired upon successful sending of flowMod
> message to device and second is fired upon flow removal confirmation message
> received from device.
> And the second one is used here and there are no instructions inside.
>
> Is this necessary for VTN manager to have instructions contained in
> flowRemoved notification? The reason for not having instructions here is
> simple - instructions are not sent within this message (as defined by OF-1.3
> spec.). And flow can be identified by combination of priority and match.
>
> In case that instructions are necessary here, I would vote for creating
> another bug.
>
> Thank you.

Thank you for your confirmation.

It is fine for VTN Manager to not have instructions in flowRemoved notification.
As you mentioned, VTN Manager can identify a flow by combination of priority and match.

Comment by Michal Rehak [ 19/Jun/14 ]

Great,
would you mark this bug as resolved, please?

Generated at Wed Feb 07 20:31:47 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.