Operating System: All
Platform: All

Attachment karaf.log has been added with description: Karaf log

Attachment karaf.log has been added with description: CLI walkthrough

(In reply to Timothy Rozet from comment #1)
> Created attachment 906 [details]
> CLI walkthrough

Hi Timothy,

The attachment 906 (CLI Walkthrough) looks to be the same as the attachment 905 (karaf.log). Could you also provide the local.conf files for the node setup. Any details to reproduce the problem would be greatly appreciated.

Thanks, Vinh

Hi Vinh,

I think you can use this local.conf to stack up with L3 features so that br-ex is required.
Steps top reproduce will be to

a. stack up
b. perform some operations
c. unset Manager in OVS
d. set MAnager as ODL:6640 to OVS
e. The br-ex will be already there, so ODL may not install flows.

Please try this.

(In reply to Venkatrangan Govindarajan from comment #3)
> Hi Vinh,
>
> I think you can use this local.conf to stack up with L3 features so that
> br-ex is required.
> Steps top reproduce will be to
>
> a. stack up
> b. perform some operations
> c. unset Manager in OVS
> d. set MAnager as ODL:6640 to OVS
> e. The br-ex will be already there, so ODL may not install flows.
>
> Please try this.

The problem still cannot reproduced with deleting and recreating the bridge after unset Manager. These are the CLI walk-through:

$ sudo ovs-ofctl dump-flows br-ex -O OpenFlow13
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x0, duration=19.211s, table=0, n_packets=0, n_bytes=0, dl_type=0x88cc actions=CONTROLLER:65535
cookie=0x0, duration=19.211s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
1) $ sudo ovs-vsctl del-manager
2) $ sudo ovs-vsctl del-br br-ex
3) $ sudo ovs-vsctl add-br br-ex – set-controller br-ex tcp:10.128.0.3:6653
4) $ sudo ovs-ofctl dump-flows br-ex -O OpenFlow13
OFPST_FLOW reply (OF1.3) (xid=0x2):
5) $ sudo ovs-vsctl set-manager tcp:10.128.0.3:6640
6) $ sudo ovs-ofctl dump-flows br-ex -O OpenFlow13
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x0, duration=5.898s, table=0, n_packets=0, n_bytes=0, dl_type=0x88cc actions=CONTROLLER:65535
cookie=0x0, duration=5.898s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL

​However the problem can be reproduced (flows are not pushed) if I delete the flows instead of deleting and recreating the bridge in step 2) and 3).

(In reply to Timothy Rozet from comment #1)
> Created attachment 906 [details]
> CLI walkthrough

Hi Timothy,

is it possible to send your CLI walkthrough for reproducing this bug?

thanks.

Hi Bertrand,
We saw this in OPNFV Apex installer. The Installer creates br-ex and puts the a host port on it with no IP for DVR case, before it ever connects to ODL. It doesn't seem to happen every time. Give me a week or so to try to investigate and see if I can consistently reproduce.

Thanks.

gerrit - to be reviewed for the scenario Vinh described: https://git.opendaylight.org/gerrit/#/c/38895/

Just got back to this bug. I am seeing it still with Beryllium SR2:

[root@overcloud-controller-0 log]# ovs-ofctl -O openflow13 dump-flows br-int
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x0, duration=8956.247s, table=0, n_packets=0, n_bytes=0, dl_type=0x88cc actions=CONTROLLER:65535
cookie=0x0, duration=8956.247s, table=0, n_packets=0, n_bytes=0, priority=0 actions=goto_table:20
cookie=0x0, duration=8956.247s, table=20, n_packets=0, n_bytes=0, priority=0 actions=goto_table:30
cookie=0x0, duration=8956.247s, table=30, n_packets=0, n_bytes=0, priority=0 actions=goto_table:40
cookie=0x0, duration=8956.247s, table=40, n_packets=0, n_bytes=0, priority=0 actions=goto_table:50
cookie=0x0, duration=8956.247s, table=50, n_packets=0, n_bytes=0, priority=0 actions=goto_table:60
cookie=0x0, duration=8956.247s, table=60, n_packets=0, n_bytes=0, priority=0 actions=goto_table:70
cookie=0x0, duration=8956.247s, table=70, n_packets=0, n_bytes=0, priority=0 actions=goto_table:80
cookie=0x0, duration=8956.247s, table=80, n_packets=0, n_bytes=0, priority=0 actions=goto_table:90
cookie=0x0, duration=8956.247s, table=90, n_packets=0, n_bytes=0, priority=0 actions=goto_table:100
cookie=0x0, duration=8956.247s, table=100, n_packets=0, n_bytes=0, priority=0 actions=goto_table:110
cookie=0x0, duration=8956.247s, table=110, n_packets=0, n_bytes=0, priority=0 actions=drop
[root@overcloud-controller-0 log]# ovs-ofctl -O openflow13 dump-flows br-ex
OFPST_FLOW reply (OF1.3) (xid=0x2):
[root@overcloud-controller-0 log]# ovs-vsctl show
a090eb87-75c0-4cef-80e5-c79cc81f9998
Manager "tcp:192.0.2.8:6640"
is_connected: true
Bridge br-int
Controller "tcp:192.0.2.8:6653"
is_connected: true
fail_mode: secure
Port br-int
Interface br-int
type: internal
Bridge br-ex
Controller "tcp:192.0.2.8:6653"
is_connected: true
fail_mode: secure
Port "ens8"
Interface "ens8"
Port br-ex
Interface br-ex
type: internal
ovs_version: "2.5.0"

[root@overcloud-controller-0 opendaylight]# cat etc/custom.properties | grep ovsdb.l3
ovsdb.l3.fwd.enabled=yes
ovsdb.l3.arp.responder.disabled=no

1. ovsdb.l3gateway.mac=00:00:5E:00:02:01

Will attach all karaf logs

Hi Timothy,

my patch hasn't been merged yet so the SR2 distribution is expected to fail. You'd have to test with your own ODL build after applying my patch to see if the issue is resolved.

thanks.

Attachment br-ex_no_flows_karaf_logs.tar.gz has been added with description: Latest full karaf logs

This behaviour is no longer present with patch https://git.opendaylight.org/gerrit/#/c/40744/

The br-ex flows are now showing up after switch is reconnected to ODL.

Looks good in our OPNFV deploys. Thanks!