Operating System: All
Platform: All

Which flow are you referring to that dont get created? Are you referring to the OpenFlow flows? If so, the OpenFlow flows have nothing to do with "ip-mgmt-address" being set.

To be able to debug this problem, I need the following pieces of information:

• The complete SFC configuration, including: SFs, SFFs, SFCs, SFPs, and RSPs.
• a dump of the OpenFlow flows from each SFF using the command: "sudo ovs-ofctl -O OpenFlow13 dump-flows <SFF switch name>"

Brady

Attachment chain_setup.txt has been added with description: sfc configuration

I am referring to OF flow on OVS, when packet is returned from SF.

My basic topology/chain setup:
Client > classifier (python) -> SFF (OVS <> SF python) > SFF (python <> SF python) -> Server

Created flows on OVS:
root@OVS1:~# ovs-ofctl -O OpenFlow13 dump-flows sw1
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x14, duration=4.070s, table=0, n_packets=0, n_bytes=0, priority=250,ip actions=goto_table:3
cookie=0x14, duration=4.056s, table=3, n_packets=0, n_bytes=0, priority=540,nsp=2,nsi=255 actions=load:0xc0a82133->NXM_NX_TUN_IPV4_DST[],goto_table:10
cookie=0xba5eba11ba5eba11, duration=4.049s, table=10, n_packets=0, n_bytes=0, priority=640,nsp=2,nsi=255 actions=move:NXM_NX_NSH_C1[]>NXM_NX_NSH_C1[],move:NXM_NX_NSH_C2[]>NXM_NX_NSH_C2[],move:NXM_NX_TUN_ID[0..31]->NXM_NX_TUN_ID[0..31],IN_PORT

Created flows on OVS (new chain), when second hop SF has "ip-mgmt-address" set:
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x14, duration=4.740s, table=0, n_packets=0, n_bytes=0, priority=250,ip actions=goto_table:3
cookie=0x14, duration=878.708s, table=3, n_packets=0, n_bytes=0, priority=540,nsp=2,nsi=255 actions=load:0xc0a82133->NXM_NX_TUN_IPV4_DST[],goto_table:10
cookie=0x14, duration=4.729s, table=3, n_packets=0, n_bytes=0, priority=540,nsp=3,nsi=255 actions=load:0xc0a82133->NXM_NX_TUN_IPV4_DST[],goto_table:10
cookie=0x14, duration=4.674s, table=3, n_packets=0, n_bytes=0, priority=540,nsp=3,nsi=254 actions=load:0xc0a82135->NXM_NX_TUN_IPV4_DST[],goto_table:10
cookie=0xba5eba11ba5eba11, duration=878.701s, table=10, n_packets=0, n_bytes=0, priority=640,nsp=2,nsi=255 actions=move:NXM_NX_NSH_C1[]>NXM_NX_NSH_C1[],move:NXM_NX_NSH_C2[]>NXM_NX_NSH_C2[],move:NXM_NX_TUN_ID[0..31]->NXM_NX_TUN_ID[0..31],IN_PORT
cookie=0xba5eba11ba5eba11, duration=4.722s, table=10, n_packets=0, n_bytes=0, priority=640,nsp=3,nsi=255 actions=move:NXM_NX_NSH_C1[]>NXM_NX_NSH_C1[],move:NXM_NX_NSH_C2[]>NXM_NX_NSH_C2[],move:NXM_NX_TUN_ID[0..31]->NXM_NX_TUN_ID[0..31],IN_PORT
cookie=0xba5eba11ba5eba11, duration=4.668s, table=10, n_packets=0, n_bytes=0, priority=640,nsp=3,nsi=254 actions=move:NXM_NX_NSH_C1[]>NXM_NX_NSH_C1[],move:NXM_NX_NSH_C2[]>NXM_NX_NSH_C2[],move:NXM_NX_TUN_ID[0..31]->NXM_NX_TUN_ID[0..31],IN_PORT

Configuration is in att.

Controller branch used - master

This is a little bit old, but so far, I haven't been able to reproduce the failure.

In my testing environment, using the same type of configuration and removing the ip-mgmt-address from one of the SFs, flows are properly created.

Could you reproduce the bug or should we close it?

I tested this on Fluorine, and all flows are created as expected when the ip-mgmt-address is not specified on the SFs. Considering the sfc-agent is no longer supported, Im closing this bug.