Re: [ovs-discuss] Bridge in unknown state

[Eelco Chaudron via discuss]

On 23 Mar 2023, at 8:54, Alex Zetaeffesse wrote:

> Just a note aside; in OVS I haven't defined the port bond0 as trunk, it's
> just a (LACP) port, what comes in is processed and what comes from the
> other ports is sent out of it. Needless to say, perhaps, that I can have
> more control on which S-tagged frames the bond can process if I apply some
> options to it (like 1) trunk, 2) ethertype 88a8 and3) the list of tags
> allowed).

From the top of my head,  all ports are by default in trunk mode, so all you 
might need to add is a list of tags you want to allow.

The ovs-vsctl show only show the tag configuration, not the vlan_mode. As you 
suggested you can you the get command, or just dump all the config using 
“ovs-vsctl list port” with or without the port name.

//Eelco

> Alex
>
> On Wed, Mar 22, 2023 at 6:39 PM Alex Zetaeffesse  wrote:
>
>> On Wed, Mar 22, 2023 at 5:35 PM Eelco Chaudron 
>> wrote:
>>
>>>
>>>
>>> On 22 Mar 2023, at 17:19, Alex Zetaeffesse wrote:
>>>
 For the bridge's interfaces' list, I guess the shorter the output the
 better...

 root@pve:~# ovs-vsctl list-ifaces vmbr1
 enp6s0f0
 enp7s0f0
 sv_z1ad0101
 sv_z1ad0102
 sv_z1ad0103
 sv_z1ad0104
 sv_z1ad4064
>>>
>>> Use ovs-vsctl show, as it shows the bridge, and all the ports with the
>>> relations (and some additional config).
>>>
>>> For example:
>>>
>>> ovs-vsctl show
>>> 19ff182e-79a7-4f74-ae4a-5bc217d2c558
>>> Bridge br1
>>> Port br1
>>> Interface br1
>>> type: internal
>>> Bridge ovs_pvp_br0
>>> datapath_type: netdev
>>> Port dpdk0p1
>>> Interface dpdk0p1
>>> type: dpdk
>>> options: {dpdk-devargs=":17:00.1", n_rxq="2"}
>>> Port dpdk0p0
>>> Interface dpdk0p0
>>> type: dpdk
>>> options: {dpdk-devargs=":17:00.0", n_rxq="2"}
>>> Port vhost0
>>> Interface vhost0
>>> type: dpdkvhostuserclient
>>> options: {n_rxq="2", vhost-server-path="/tmp/vhost-sock0"}
>>> Port ovs_pvp_br0
>>> Interface ovs_pvp_br0
>>> type: internal
>>> ovs_version: "3.1.1"
>>
>>
>>
>> I was confusing OVS bond with kernel bond...
>> Anyway, this is what I did eventually
>>
>> ip link add bond0 type bond
>> ip link set bond0 type bond miimon 100 mode 802.3ad
>> ip link set enp6s0f0 down
>> ip link set enp6s0f0 master bond0
>> ip link set enp7s0f0 down
>> ip link set enp7s0f0 master bond0
>> ip link set bond0 up
>>
>> ovs-vsctl add-port vmbr1 bond0
>>
>> ovs-vsctl set port sv_z1ad0101 vlan_mode=dot1q-tunnel tag=101
>> ovs-vsctl set port sv_z1ad0102 vlan_mode=dot1q-tunnel tag=102
>> ovs-vsctl set port sv_z1ad0103 vlan_mode=dot1q-tunnel tag=103
>> ovs-vsctl set port sv_z1ad0104 vlan_mode=dot1q-tunnel tag=104
>>
>> "ovs-vsctl show" shows the port and their details but not the options
>> attached to them, is there any way to do that?
>>
>> Otherwise, I can get the details I need by specifying them
>>
>> root@pve:~# ovs-vsctl get port sv_z1ad0101 vlan_mode
>> dot1q-tunnel
>> root@pve:~# ovs-vsctl get port sv_z1ad0101 tag
>> 101
>>
>> It finally works!
>> Thanks for your patience and help!
>>
>> Now I know what bridges should look like when using ProxMox's tools; it's
>> time to move the challenge to their forum :-)
>>
>> Alex
>>
>>

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Bridge in unknown state

[Alex Zetaeffesse via discuss]

Just a note aside; in OVS I haven't defined the port bond0 as trunk, it's
just a (LACP) port, what comes in is processed and what comes from the
other ports is sent out of it. Needless to say, perhaps, that I can have
more control on which S-tagged frames the bond can process if I apply some
options to it (like 1) trunk, 2) ethertype 88a8 and3) the list of tags
allowed).

Alex

On Wed, Mar 22, 2023 at 6:39 PM Alex Zetaeffesse  wrote:

> On Wed, Mar 22, 2023 at 5:35 PM Eelco Chaudron 
> wrote:
>
>>
>>
>> On 22 Mar 2023, at 17:19, Alex Zetaeffesse wrote:
>>
>> > For the bridge's interfaces' list, I guess the shorter the output the
>> > better...
>> >
>> > root@pve:~# ovs-vsctl list-ifaces vmbr1
>> > enp6s0f0
>> > enp7s0f0
>> > sv_z1ad0101
>> > sv_z1ad0102
>> > sv_z1ad0103
>> > sv_z1ad0104
>> > sv_z1ad4064
>>
>> Use ovs-vsctl show, as it shows the bridge, and all the ports with the
>> relations (and some additional config).
>>
>> For example:
>>
>> ovs-vsctl show
>> 19ff182e-79a7-4f74-ae4a-5bc217d2c558
>> Bridge br1
>> Port br1
>> Interface br1
>> type: internal
>> Bridge ovs_pvp_br0
>> datapath_type: netdev
>> Port dpdk0p1
>> Interface dpdk0p1
>> type: dpdk
>> options: {dpdk-devargs=":17:00.1", n_rxq="2"}
>> Port dpdk0p0
>> Interface dpdk0p0
>> type: dpdk
>> options: {dpdk-devargs=":17:00.0", n_rxq="2"}
>> Port vhost0
>> Interface vhost0
>> type: dpdkvhostuserclient
>> options: {n_rxq="2", vhost-server-path="/tmp/vhost-sock0"}
>> Port ovs_pvp_br0
>> Interface ovs_pvp_br0
>> type: internal
>> ovs_version: "3.1.1"
>
>
>
> I was confusing OVS bond with kernel bond...
> Anyway, this is what I did eventually
>
> ip link add bond0 type bond
> ip link set bond0 type bond miimon 100 mode 802.3ad
> ip link set enp6s0f0 down
> ip link set enp6s0f0 master bond0
> ip link set enp7s0f0 down
> ip link set enp7s0f0 master bond0
> ip link set bond0 up
>
> ovs-vsctl add-port vmbr1 bond0
>
> ovs-vsctl set port sv_z1ad0101 vlan_mode=dot1q-tunnel tag=101
> ovs-vsctl set port sv_z1ad0102 vlan_mode=dot1q-tunnel tag=102
> ovs-vsctl set port sv_z1ad0103 vlan_mode=dot1q-tunnel tag=103
> ovs-vsctl set port sv_z1ad0104 vlan_mode=dot1q-tunnel tag=104
>
> "ovs-vsctl show" shows the port and their details but not the options
> attached to them, is there any way to do that?
>
> Otherwise, I can get the details I need by specifying them
>
> root@pve:~# ovs-vsctl get port sv_z1ad0101 vlan_mode
> dot1q-tunnel
> root@pve:~# ovs-vsctl get port sv_z1ad0101 tag
> 101
>
> It finally works!
> Thanks for your patience and help!
>
> Now I know what bridges should look like when using ProxMox's tools; it's
> time to move the challenge to their forum :-)
>
> Alex
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Bridge in unknown state

[Alex Zetaeffesse via discuss]

On Wed, Mar 22, 2023 at 5:35 PM Eelco Chaudron  wrote:

>
>
> On 22 Mar 2023, at 17:19, Alex Zetaeffesse wrote:
>
> > For the bridge's interfaces' list, I guess the shorter the output the
> > better...
> >
> > root@pve:~# ovs-vsctl list-ifaces vmbr1
> > enp6s0f0
> > enp7s0f0
> > sv_z1ad0101
> > sv_z1ad0102
> > sv_z1ad0103
> > sv_z1ad0104
> > sv_z1ad4064
>
> Use ovs-vsctl show, as it shows the bridge, and all the ports with the
> relations (and some additional config).
>
> For example:
>
> ovs-vsctl show
> 19ff182e-79a7-4f74-ae4a-5bc217d2c558
> Bridge br1
> Port br1
> Interface br1
> type: internal
> Bridge ovs_pvp_br0
> datapath_type: netdev
> Port dpdk0p1
> Interface dpdk0p1
> type: dpdk
> options: {dpdk-devargs=":17:00.1", n_rxq="2"}
> Port dpdk0p0
> Interface dpdk0p0
> type: dpdk
> options: {dpdk-devargs=":17:00.0", n_rxq="2"}
> Port vhost0
> Interface vhost0
> type: dpdkvhostuserclient
> options: {n_rxq="2", vhost-server-path="/tmp/vhost-sock0"}
> Port ovs_pvp_br0
> Interface ovs_pvp_br0
> type: internal
> ovs_version: "3.1.1"



I was confusing OVS bond with kernel bond...
Anyway, this is what I did eventually

ip link add bond0 type bond
ip link set bond0 type bond miimon 100 mode 802.3ad
ip link set enp6s0f0 down
ip link set enp6s0f0 master bond0
ip link set enp7s0f0 down
ip link set enp7s0f0 master bond0
ip link set bond0 up

ovs-vsctl add-port vmbr1 bond0

ovs-vsctl set port sv_z1ad0101 vlan_mode=dot1q-tunnel tag=101
ovs-vsctl set port sv_z1ad0102 vlan_mode=dot1q-tunnel tag=102
ovs-vsctl set port sv_z1ad0103 vlan_mode=dot1q-tunnel tag=103
ovs-vsctl set port sv_z1ad0104 vlan_mode=dot1q-tunnel tag=104

"ovs-vsctl show" shows the port and their details but not the options
attached to them, is there any way to do that?

Otherwise, I can get the details I need by specifying them

root@pve:~# ovs-vsctl get port sv_z1ad0101 vlan_mode
dot1q-tunnel
root@pve:~# ovs-vsctl get port sv_z1ad0101 tag
101

It finally works!
Thanks for your patience and help!

Now I know what bridges should look like when using ProxMox's tools; it's
time to move the challenge to their forum :-)

Alex
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Bridge in unknown state

[Eelco Chaudron via discuss]

On 22 Mar 2023, at 17:19, Alex Zetaeffesse wrote:

> For the bridge's interfaces' list, I guess the shorter the output the
> better...
>
> root@pve:~# ovs-vsctl list-ifaces vmbr1
> enp6s0f0
> enp7s0f0
> sv_z1ad0101
> sv_z1ad0102
> sv_z1ad0103
> sv_z1ad0104
> sv_z1ad4064

Use ovs-vsctl show, as it shows the bridge, and all the ports with the 
relations (and some additional config).

For example:

ovs-vsctl show
19ff182e-79a7-4f74-ae4a-5bc217d2c558
Bridge br1
Port br1
Interface br1
type: internal
Bridge ovs_pvp_br0
datapath_type: netdev
Port dpdk0p1
Interface dpdk0p1
type: dpdk
options: {dpdk-devargs=":17:00.1", n_rxq="2"}
Port dpdk0p0
Interface dpdk0p0
type: dpdk
options: {dpdk-devargs=":17:00.0", n_rxq="2"}
Port vhost0
Interface vhost0
type: dpdkvhostuserclient
options: {n_rxq="2", vhost-server-path="/tmp/vhost-sock0"}
Port ovs_pvp_br0
Interface ovs_pvp_br0
type: internal
ovs_version: "3.1.1"


> Alex
>
> On Wed, Mar 22, 2023 at 5:14 PM Alex Zetaeffesse  wrote:
>
>> The issue is that yet I confuse ports and interfaces.
>>
>> root@pve:~# ovs-vsctl del-port vmbr1 enp7s0f0
>> ovs-vsctl: no port named enp7s0f0
>> root@pve:~# ovs-vsctl add-port vmbr1 enp7s0f0
>> ovs-vsctl: cannot create a port named enp7s0f0 because an interface named
>> enp7s0f0 already exists on bridge vmbr1
>>
>> The trick that removed the physical interfaces was
>>
>> root@pve:~# ovs-vsctl --with-iface del-port vmbr1 enp7s0f0
>> root@pve:~# ovs-ofctl show vmbr1
>> OFPT_FEATURES_REPLY (xid=0x2): dpid:f6fe01a1e94d
>> n_tables:254, n_buffers:0
>> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
>> actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
>> mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
>>  2(sv_z1ad0101): addr:1e:9a:25:9b:22:0a
>>  config: 0
>>  state:  0
>>  speed: 0 Mbps now, 0 Mbps max
>>  3(sv_z1ad0102): addr:ba:46:f5:b8:4a:63
>>  config: 0
>>  state:  0
>>  speed: 0 Mbps now, 0 Mbps max
>>  4(sv_z1ad0103): addr:56:75:a3:a8:f7:89
>>  config: 0
>>  state:  0
>>  speed: 0 Mbps now, 0 Mbps max
>>  5(sv_z1ad0104): addr:9e:a9:30:0f:a2:53
>>  config: 0
>>  state:  0
>>  speed: 0 Mbps now, 0 Mbps max
>>  6(sv_z1ad4064): addr:26:de:29:e0:8a:12
>>  config: 0
>>  state:  0
>>  speed: 0 Mbps now, 0 Mbps max
>>  LOCAL(vmbr1): addr:f6:fe:01:a1:e9:4d
>>  config: 0
>>  state:  0
>>  speed: 0 Mbps now, 0 Mbps max
>> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
>>
>> and along with enp7s0f0, also enp6s0f0 and bond0 got removed from vmbr1
>> and bond0 was deleted :-/
>>
>> root@pve:~#
>> root@pve:~# ip link show bond0
>> Device "bond0" does not exist.
>> root@pve:~# ip link show dev bond0
>> Device "bond0" does not exist.
>> root@pve:~# ip link show dev enp7s0f0
>> 6: enp7s0f0:  mtu 1500 qdisc pfifo_fast
>> state UP mode DEFAULT group default qlen 1000
>> link/ether 00:1c:c4:47:63:33 brd ff:ff:ff:ff:ff:ff
>> root@pve:~# ip link show dev enp6s0f0
>> 4: enp6s0f0:  mtu 1500 qdisc pfifo_fast
>> state UP mode DEFAULT group default qlen 1000
>> link/ether 00:1c:c4:47:63:31 brd ff:ff:ff:ff:ff:ff
>>
>> I then added back the bond (bond0) to the bridge by issuing the following
>> command
>>
>> ovs-vsctl add-bond vmbr1 bond0 enp6s0f0 enp7s0f0
>>
>> but just the physical interfaces were added and not the intf bond0
>>
>> root@pve:~# ovs-ofctl show vmbr1
>> OFPT_FEATURES_REPLY (xid=0x2): dpid:001cc4476331
>> n_tables:254, n_buffers:0
>> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
>> actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
>> mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
>>  2(sv_z1ad0101): addr:1e:9a:25:9b:22:0a
>>  config: 0
>>  state:  0
>>  speed: 0 Mbps now, 0 Mbps max
>>  3(sv_z1ad0102): addr:ba:46:f5:b8:4a:63
>>  config: 0
>>  state:  0
>>  speed: 0 Mbps now, 0 Mbps max
>>  4(sv_z1ad0103): addr:56:75:a3:a8:f7:89
>>  config: 0
>>  state:  0
>>  speed: 0 Mbps now, 0 Mbps max
>>  5(sv_z1ad0104): addr:9e:a9:30:0f:a2:53
>>  config: 0
>>  state:  0
>>  speed: 0 Mbps now, 0 Mbps max
>>  6(sv_z1ad4064): addr:26:de:29:e0:8a:12
>>  config: 0
>>  state:  0
>>  speed: 0 Mbps now, 0 Mbps max
>>  10(enp7s0f0): addr:00:1c:c4:47:63:33
>>  config: 0
>>  state:  0
>>  current:1GB-FD COPPER AUTO_NEG
>>  advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
>>  supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
>>  speed: 1000 Mbps now, 1000 Mbps max
>>  

Re: [ovs-discuss] Bridge in unknown state

[Eelco Chaudron via discuss]

On 22 Mar 2023, at 14:42, Alex Zetaeffesse wrote:

> I will do my best in describing the goal and the issue
> The ports connected to the bridge (I shrunk the output for readability) are
> the following
>
> root@pve:~# ovs-ofctl show vmbr1
> [CUT]
>  2(sv_z1ad0101): addr:1e:9a:25:9b:22:0a
>  3(sv_z1ad0102): addr:ba:46:f5:b8:4a:63
>  4(sv_z1ad0103): addr:56:75:a3:a8:f7:89
>  5(sv_z1ad0104): addr:9e:a9:30:0f:a2:53
>  6(sv_z1ad4064): addr:26:de:29:e0:8a:12
>  7(enp6s0f0): addr:00:1c:c4:47:63:31
>  8(enp7s0f0): addr:00:1c:c4:47:63:33
>  9(bond0): addr:0a:aa:d5:40:6d:9a
>  LOCAL(vmbr1): addr:00:1c:c4:47:63:31
> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
>
> First of all the ports enps6s0f0 e enps7s0f0 (the physical memebers of
> bond0) should not be there.

I would suggest creating a kernel bond with the enp6s0f0 and enp7s0f0 members, 
and only adding that bond.

> The goal is to have just sv_x and bond0. Bond0 is supposed to receive
> 802.1ad traffic i.e. with ethertype 0x88a8.
> Then frames should be forwarded to each interface sv_x based on the
> 802.1ad tag, i.e. frames tagged with the tag 101 should be forwarded to the
> port q1ad0101, frames with tag 102 should be forwarded to the port
> q1ad0102, and so on.

Your sv_xx ports should be native tagged ports, for details see the 
https://docs.openvswitch.org/en/latest/faq/vlan/ documentation.

Your bond port should be a trunk port.

If you use the default NORMAL rule in openflow (check ovs-ofctl dump-flows 
vmbr1), this should work just fine. You can see the FDB table with the right 
VLAN tags (see ovs-appctl fdb/ commands).

> I think I have to remove the physical ones from the vmbr1 and possibly add
> the right flow. I don't think is the right way to do it, everything should
> be accomplished through the ProxMox Interface, but at least I will have a
> working scenario and discuss it in the ProxMox's forum.
>
> Thanks,
>
> Alex
>
>
>
> On Wed, Mar 22, 2023 at 10:54 AM Eelco Chaudron  wrote:
>
>>
>>
>> On 22 Mar 2023, at 10:49, Alex Zetaeffesse wrote:
>>
>>> Thank you Eelco,
>>>
>>> the thing is that I'm troubleshooting connectivity issues and the problem
>>> for the moment seems right in vmbr1.
>>> Hence I'm trying to understand if vmbr1 works as expected.
>>
>> For OVS to work the bridge does not need to be up. Traffic should just
>> work :)
>>
>> What are you trying to do, and does not work?
>>
>> You can check the following thinks:
>>
>> - Are the ports configured as needed (ovs-vsctl show)
>> - Are you OpenFlow rules as needed (ovs-ofctl dump-flows )
>> - If traffic is not working, check the dp rules (when you are actively
>> trying to send traffic as these rules time out after 10 seconds).
>> ovs-appctl dpctl/dump-flows
>>
>> Cheers,
>>
>> Eelco
>>
>>
>>
>>> On Wed, Mar 22, 2023 at 10:42 AM Eelco Chaudron 
>> wrote:
>>>


 On 21 Mar 2023, at 23:42, Alex Zetaeffesse via discuss wrote:

> Hi all,
>
> First of all, let me be clear on the fact that I'm the first who
>> doesn't
> want to run a mixed environment :-)
>
> In my ProxMox environment I have the following:
>
> root@pve:~# ip link show dev vmbr1
> 11: vmbr1:  mtu 1500 qdisc noqueue
>> state
> UNKNOWN mode DEFAULT group default qlen 1000
> link/ether 00:1c:c4:47:63:31 brd ff:ff:ff:ff:ff:ff

 This is the same on my Fedora and RHEL systems. The bridge show DOWN if
>> I
 bring it down, and UNKNOWN state when it’s up.

 [vagrant@f35 ~]$ sudo ovs-vsctl add-br br1
 [vagrant@f35 ~]$ ip link show bro
 6: br1:  mtu 1500 qdisc noop state DOWN mode
>> DEFAULT
 group default qlen 1000
 link/ether c6:c4:18:57:ba:48 brd ff:ff:ff:ff:ff:ff
 [vagrant@f35 ~]$ sudo ip link set br1 up
 [vagrant@f35 ~]$ ip link show br1
 6: br1:  mtu 1500 qdisc noqueue state
 UNKNOWN mode DEFAULT group default qlen 1000
 link/ether c6:c4:18:57:ba:48 brd ff:ff:ff:ff:ff:ff

 This might be a bug no one ever noticed :)

 //Eelco

> root@pve:~# ovs-ofctl show vmbr1
> OFPT_FEATURES_REPLY (xid=0x2): dpid:001cc4476331
> n_tables:254, n_buffers:0
> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS
>> ARP_MATCH_IP
> actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
> mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
>  2(sv_z1ad0101): addr:1e:9a:25:9b:22:0a
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
>  3(sv_z1ad0102): addr:ba:46:f5:b8:4a:63
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
>  4(sv_z1ad0103): addr:56:75:a3:a8:f7:89
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
>  5(sv_z1ad0104): addr:9e:a9:30:0f:a2:53
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
>  6(sv_z1ad4064): 

Re: [ovs-discuss] Bridge in unknown state

[Alex Zetaeffesse via discuss]

I will do my best in describing the goal and the issue
The ports connected to the bridge (I shrunk the output for readability) are
the following

root@pve:~# ovs-ofctl show vmbr1
[CUT]
 2(sv_z1ad0101): addr:1e:9a:25:9b:22:0a
 3(sv_z1ad0102): addr:ba:46:f5:b8:4a:63
 4(sv_z1ad0103): addr:56:75:a3:a8:f7:89
 5(sv_z1ad0104): addr:9e:a9:30:0f:a2:53
 6(sv_z1ad4064): addr:26:de:29:e0:8a:12
 7(enp6s0f0): addr:00:1c:c4:47:63:31
 8(enp7s0f0): addr:00:1c:c4:47:63:33
 9(bond0): addr:0a:aa:d5:40:6d:9a
 LOCAL(vmbr1): addr:00:1c:c4:47:63:31
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0

First of all the ports enps6s0f0 e enps7s0f0 (the physical memebers of
bond0) should not be there.
The goal is to have just sv_x and bond0. Bond0 is supposed to receive
802.1ad traffic i.e. with ethertype 0x88a8.
Then frames should be forwarded to each interface sv_x based on the
802.1ad tag, i.e. frames tagged with the tag 101 should be forwarded to the
port q1ad0101, frames with tag 102 should be forwarded to the port
q1ad0102, and so on.

I think I have to remove the physical ones from the vmbr1 and possibly add
the right flow. I don't think is the right way to do it, everything should
be accomplished through the ProxMox Interface, but at least I will have a
working scenario and discuss it in the ProxMox's forum.

Thanks,

Alex



On Wed, Mar 22, 2023 at 10:54 AM Eelco Chaudron  wrote:

>
>
> On 22 Mar 2023, at 10:49, Alex Zetaeffesse wrote:
>
> > Thank you Eelco,
> >
> > the thing is that I'm troubleshooting connectivity issues and the problem
> > for the moment seems right in vmbr1.
> > Hence I'm trying to understand if vmbr1 works as expected.
>
> For OVS to work the bridge does not need to be up. Traffic should just
> work :)
>
> What are you trying to do, and does not work?
>
> You can check the following thinks:
>
> - Are the ports configured as needed (ovs-vsctl show)
> - Are you OpenFlow rules as needed (ovs-ofctl dump-flows )
> - If traffic is not working, check the dp rules (when you are actively
> trying to send traffic as these rules time out after 10 seconds).
> ovs-appctl dpctl/dump-flows
>
> Cheers,
>
> Eelco
>
>
>
> > On Wed, Mar 22, 2023 at 10:42 AM Eelco Chaudron 
> wrote:
> >
> >>
> >>
> >> On 21 Mar 2023, at 23:42, Alex Zetaeffesse via discuss wrote:
> >>
> >>> Hi all,
> >>>
> >>> First of all, let me be clear on the fact that I'm the first who
> doesn't
> >>> want to run a mixed environment :-)
> >>>
> >>> In my ProxMox environment I have the following:
> >>>
> >>> root@pve:~# ip link show dev vmbr1
> >>> 11: vmbr1:  mtu 1500 qdisc noqueue
> state
> >>> UNKNOWN mode DEFAULT group default qlen 1000
> >>> link/ether 00:1c:c4:47:63:31 brd ff:ff:ff:ff:ff:ff
> >>
> >> This is the same on my Fedora and RHEL systems. The bridge show DOWN if
> I
> >> bring it down, and UNKNOWN state when it’s up.
> >>
> >> [vagrant@f35 ~]$ sudo ovs-vsctl add-br br1
> >> [vagrant@f35 ~]$ ip link show bro
> >> 6: br1:  mtu 1500 qdisc noop state DOWN mode
> DEFAULT
> >> group default qlen 1000
> >> link/ether c6:c4:18:57:ba:48 brd ff:ff:ff:ff:ff:ff
> >> [vagrant@f35 ~]$ sudo ip link set br1 up
> >> [vagrant@f35 ~]$ ip link show br1
> >> 6: br1:  mtu 1500 qdisc noqueue state
> >> UNKNOWN mode DEFAULT group default qlen 1000
> >> link/ether c6:c4:18:57:ba:48 brd ff:ff:ff:ff:ff:ff
> >>
> >> This might be a bug no one ever noticed :)
> >>
> >> //Eelco
> >>
> >>> root@pve:~# ovs-ofctl show vmbr1
> >>> OFPT_FEATURES_REPLY (xid=0x2): dpid:001cc4476331
> >>> n_tables:254, n_buffers:0
> >>> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS
> ARP_MATCH_IP
> >>> actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
> >>> mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
> >>>  2(sv_z1ad0101): addr:1e:9a:25:9b:22:0a
> >>>  config: 0
> >>>  state:  0
> >>>  speed: 0 Mbps now, 0 Mbps max
> >>>  3(sv_z1ad0102): addr:ba:46:f5:b8:4a:63
> >>>  config: 0
> >>>  state:  0
> >>>  speed: 0 Mbps now, 0 Mbps max
> >>>  4(sv_z1ad0103): addr:56:75:a3:a8:f7:89
> >>>  config: 0
> >>>  state:  0
> >>>  speed: 0 Mbps now, 0 Mbps max
> >>>  5(sv_z1ad0104): addr:9e:a9:30:0f:a2:53
> >>>  config: 0
> >>>  state:  0
> >>>  speed: 0 Mbps now, 0 Mbps max
> >>>  6(sv_z1ad4064): addr:26:de:29:e0:8a:12
> >>>  config: 0
> >>>  state:  0
> >>>  speed: 0 Mbps now, 0 Mbps max
> >>>  7(enp6s0f0): addr:00:1c:c4:47:63:31
> >>>  config: 0
> >>>  state:  0
> >>>  current:1GB-FD COPPER AUTO_NEG
> >>>  advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER
> AUTO_NEG
> >>>  supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER
> AUTO_NEG
> >>>  speed: 1000 Mbps now, 1000 Mbps max
> >>>  8(enp7s0f0): addr:00:1c:c4:47:63:33
> >>>  config: 0
> >>>  state:  0
> >>>  current:1GB-FD COPPER AUTO_NEG
> >>>  advertised: 10MB-HD 10MB-FD 100MB-HD 

Re: [ovs-discuss] Bridge in unknown state

[Ilya Maximets via discuss]

On 3/22/23 10:42, Eelco Chaudron via discuss wrote:
> 
> 
> On 21 Mar 2023, at 23:42, Alex Zetaeffesse via discuss wrote:
> 
>> Hi all,
>>
>> First of all, let me be clear on the fact that I'm the first who doesn't
>> want to run a mixed environment :-)
>>
>> In my ProxMox environment I have the following:
>>
>> root@pve:~# ip link show dev vmbr1
>> 11: vmbr1:  mtu 1500 qdisc noqueue state
>> UNKNOWN mode DEFAULT group default qlen 1000
>> link/ether 00:1c:c4:47:63:31 brd ff:ff:ff:ff:ff:ff
> 
> This is the same on my Fedora and RHEL systems. The bridge show DOWN if I 
> bring it down, and UNKNOWN state when it’s up.
> 
> [vagrant@f35 ~]$ sudo ovs-vsctl add-br br1
> [vagrant@f35 ~]$ ip link show bro
> 6: br1:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
> group default qlen 1000
> link/ether c6:c4:18:57:ba:48 brd ff:ff:ff:ff:ff:ff
> [vagrant@f35 ~]$ sudo ip link set br1 up
> [vagrant@f35 ~]$ ip link show br1
> 6: br1:  mtu 1500 qdisc noqueue state 
> UNKNOWN mode DEFAULT group default qlen 1000
> link/ether c6:c4:18:57:ba:48 brd ff:ff:ff:ff:ff:ff
> 
> This might be a bug no one ever noticed :)

IF_OPER_UNKNOWN (0):
  Interface is in unknown state, neither driver nor userspace has set
  operational state. Interface must be considered for user data as
  setting operational state has not been implemented in every driver.

I'm guessing that the latter applies to the OVS internal port, i.e.
we probably do not set operational state for them in the kernel.  But
that should not affect the traffic in any way as the kernel should
treat the UNKNOWN state more or less the same way as UP.

Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Bridge in unknown state

[Eelco Chaudron via discuss]

On 22 Mar 2023, at 10:49, Alex Zetaeffesse wrote:

> Thank you Eelco,
>
> the thing is that I'm troubleshooting connectivity issues and the problem
> for the moment seems right in vmbr1.
> Hence I'm trying to understand if vmbr1 works as expected.

For OVS to work the bridge does not need to be up. Traffic should just work :)

What are you trying to do, and does not work?

You can check the following thinks:

- Are the ports configured as needed (ovs-vsctl show)
- Are you OpenFlow rules as needed (ovs-ofctl dump-flows )
- If traffic is not working, check the dp rules (when you are actively trying 
to send traffic as these rules time out after 10 seconds). ovs-appctl 
dpctl/dump-flows

Cheers,

Eelco



> On Wed, Mar 22, 2023 at 10:42 AM Eelco Chaudron  wrote:
>
>>
>>
>> On 21 Mar 2023, at 23:42, Alex Zetaeffesse via discuss wrote:
>>
>>> Hi all,
>>>
>>> First of all, let me be clear on the fact that I'm the first who doesn't
>>> want to run a mixed environment :-)
>>>
>>> In my ProxMox environment I have the following:
>>>
>>> root@pve:~# ip link show dev vmbr1
>>> 11: vmbr1:  mtu 1500 qdisc noqueue state
>>> UNKNOWN mode DEFAULT group default qlen 1000
>>> link/ether 00:1c:c4:47:63:31 brd ff:ff:ff:ff:ff:ff
>>
>> This is the same on my Fedora and RHEL systems. The bridge show DOWN if I
>> bring it down, and UNKNOWN state when it’s up.
>>
>> [vagrant@f35 ~]$ sudo ovs-vsctl add-br br1
>> [vagrant@f35 ~]$ ip link show bro
>> 6: br1:  mtu 1500 qdisc noop state DOWN mode DEFAULT
>> group default qlen 1000
>> link/ether c6:c4:18:57:ba:48 brd ff:ff:ff:ff:ff:ff
>> [vagrant@f35 ~]$ sudo ip link set br1 up
>> [vagrant@f35 ~]$ ip link show br1
>> 6: br1:  mtu 1500 qdisc noqueue state
>> UNKNOWN mode DEFAULT group default qlen 1000
>> link/ether c6:c4:18:57:ba:48 brd ff:ff:ff:ff:ff:ff
>>
>> This might be a bug no one ever noticed :)
>>
>> //Eelco
>>
>>> root@pve:~# ovs-ofctl show vmbr1
>>> OFPT_FEATURES_REPLY (xid=0x2): dpid:001cc4476331
>>> n_tables:254, n_buffers:0
>>> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
>>> actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
>>> mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
>>>  2(sv_z1ad0101): addr:1e:9a:25:9b:22:0a
>>>  config: 0
>>>  state:  0
>>>  speed: 0 Mbps now, 0 Mbps max
>>>  3(sv_z1ad0102): addr:ba:46:f5:b8:4a:63
>>>  config: 0
>>>  state:  0
>>>  speed: 0 Mbps now, 0 Mbps max
>>>  4(sv_z1ad0103): addr:56:75:a3:a8:f7:89
>>>  config: 0
>>>  state:  0
>>>  speed: 0 Mbps now, 0 Mbps max
>>>  5(sv_z1ad0104): addr:9e:a9:30:0f:a2:53
>>>  config: 0
>>>  state:  0
>>>  speed: 0 Mbps now, 0 Mbps max
>>>  6(sv_z1ad4064): addr:26:de:29:e0:8a:12
>>>  config: 0
>>>  state:  0
>>>  speed: 0 Mbps now, 0 Mbps max
>>>  7(enp6s0f0): addr:00:1c:c4:47:63:31
>>>  config: 0
>>>  state:  0
>>>  current:1GB-FD COPPER AUTO_NEG
>>>  advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
>>>  supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
>>>  speed: 1000 Mbps now, 1000 Mbps max
>>>  8(enp7s0f0): addr:00:1c:c4:47:63:33
>>>  config: 0
>>>  state:  0
>>>  current:1GB-FD COPPER AUTO_NEG
>>>  advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
>>>  supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
>>>  speed: 1000 Mbps now, 1000 Mbps max
>>>  9(bond0): addr:0a:aa:d5:40:6d:9a
>>>  config: 0
>>>  state:  0
>>>  speed: 0 Mbps now, 0 Mbps max
>>>  LOCAL(vmbr1): addr:00:1c:c4:47:63:31
>>>  config: 0
>>>  state:  0
>>>  speed: 0 Mbps now, 0 Mbps max
>>> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
>>> root@pve:~# ovs-vsctl --version
>>> ovs-vsctl (Open vSwitch) 2.15.0
>>> DB Schema 8.2.0
>>>
>>> Is there any significant information in the ovs-dpctl output to see where
>>> the problem might be?
>>> Or what other command may I use to spot the issue?
>>>
>>> What surprises me is that two ports of the bridge vmbr1 have ovs-system
>> as
>>> master that is in DOWN state.
>>>
>>> root@pve:~# ip link show dev enp6s0f0
>>> 4: enp6s0f0:  mtu 1500 qdisc pfifo_fast
>>> master ovs-system state UP mode DEFAULT group default qlen 1000
>>> link/ether 00:1c:c4:47:63:31 brd ff:ff:ff:ff:ff:ff
>>> root@pve:~# ip link show dev enp7s0f0
>>> 6: enp7s0f0:  mtu 1500 qdisc pfifo_fast
>>> master ovs-system state UP mode DEFAULT group default qlen 1000
>>> link/ether 00:1c:c4:47:63:33 brd ff:ff:ff:ff:ff:ff
>>> root@pve:~# ip link show dev ovs-system
>>> 8: ovs-system:  mtu 1500 qdisc noop state DOWN mode
>>> DEFAULT group default qlen 1000
>>> link/ether f6:c6:45:e5:39:98 brd ff:ff:ff:ff:ff:ff
>>>
>>> Alex
>>> ___
>>> discuss mailing list
>>> disc...@openvswitch.org
>>> 

Re: [ovs-discuss] Bridge in unknown state

[Eelco Chaudron via discuss]

On 21 Mar 2023, at 23:42, Alex Zetaeffesse via discuss wrote:

> Hi all,
>
> First of all, let me be clear on the fact that I'm the first who doesn't
> want to run a mixed environment :-)
>
> In my ProxMox environment I have the following:
>
> root@pve:~# ip link show dev vmbr1
> 11: vmbr1:  mtu 1500 qdisc noqueue state
> UNKNOWN mode DEFAULT group default qlen 1000
> link/ether 00:1c:c4:47:63:31 brd ff:ff:ff:ff:ff:ff

This is the same on my Fedora and RHEL systems. The bridge show DOWN if I bring 
it down, and UNKNOWN state when it’s up.

[vagrant@f35 ~]$ sudo ovs-vsctl add-br br1
[vagrant@f35 ~]$ ip link show bro
6: br1:  mtu 1500 qdisc noop state DOWN mode DEFAULT group 
default qlen 1000
link/ether c6:c4:18:57:ba:48 brd ff:ff:ff:ff:ff:ff
[vagrant@f35 ~]$ sudo ip link set br1 up
[vagrant@f35 ~]$ ip link show br1
6: br1:  mtu 1500 qdisc noqueue state UNKNOWN 
mode DEFAULT group default qlen 1000
link/ether c6:c4:18:57:ba:48 brd ff:ff:ff:ff:ff:ff

This might be a bug no one ever noticed :)

//Eelco

> root@pve:~# ovs-ofctl show vmbr1
> OFPT_FEATURES_REPLY (xid=0x2): dpid:001cc4476331
> n_tables:254, n_buffers:0
> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
> actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
> mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
>  2(sv_z1ad0101): addr:1e:9a:25:9b:22:0a
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
>  3(sv_z1ad0102): addr:ba:46:f5:b8:4a:63
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
>  4(sv_z1ad0103): addr:56:75:a3:a8:f7:89
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
>  5(sv_z1ad0104): addr:9e:a9:30:0f:a2:53
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
>  6(sv_z1ad4064): addr:26:de:29:e0:8a:12
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
>  7(enp6s0f0): addr:00:1c:c4:47:63:31
>  config: 0
>  state:  0
>  current:1GB-FD COPPER AUTO_NEG
>  advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
>  supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
>  speed: 1000 Mbps now, 1000 Mbps max
>  8(enp7s0f0): addr:00:1c:c4:47:63:33
>  config: 0
>  state:  0
>  current:1GB-FD COPPER AUTO_NEG
>  advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
>  supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
>  speed: 1000 Mbps now, 1000 Mbps max
>  9(bond0): addr:0a:aa:d5:40:6d:9a
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
>  LOCAL(vmbr1): addr:00:1c:c4:47:63:31
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
> root@pve:~# ovs-vsctl --version
> ovs-vsctl (Open vSwitch) 2.15.0
> DB Schema 8.2.0
>
> Is there any significant information in the ovs-dpctl output to see where
> the problem might be?
> Or what other command may I use to spot the issue?
>
> What surprises me is that two ports of the bridge vmbr1 have ovs-system as
> master that is in DOWN state.
>
> root@pve:~# ip link show dev enp6s0f0
> 4: enp6s0f0:  mtu 1500 qdisc pfifo_fast
> master ovs-system state UP mode DEFAULT group default qlen 1000
> link/ether 00:1c:c4:47:63:31 brd ff:ff:ff:ff:ff:ff
> root@pve:~# ip link show dev enp7s0f0
> 6: enp7s0f0:  mtu 1500 qdisc pfifo_fast
> master ovs-system state UP mode DEFAULT group default qlen 1000
> link/ether 00:1c:c4:47:63:33 brd ff:ff:ff:ff:ff:ff
> root@pve:~# ip link show dev ovs-system
> 8: ovs-system:  mtu 1500 qdisc noop state DOWN mode
> DEFAULT group default qlen 1000
> link/ether f6:c6:45:e5:39:98 brd ff:ff:ff:ff:ff:ff
>
> Alex
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Bridge in unknown state

[Alex Zetaeffesse via discuss]

Hi all,

First of all, let me be clear on the fact that I'm the first who doesn't
want to run a mixed environment :-)

In my ProxMox environment I have the following:

root@pve:~# ip link show dev vmbr1
11: vmbr1:  mtu 1500 qdisc noqueue state
UNKNOWN mode DEFAULT group default qlen 1000
link/ether 00:1c:c4:47:63:31 brd ff:ff:ff:ff:ff:ff
root@pve:~# ovs-ofctl show vmbr1
OFPT_FEATURES_REPLY (xid=0x2): dpid:001cc4476331
n_tables:254, n_buffers:0
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
 2(sv_z1ad0101): addr:1e:9a:25:9b:22:0a
 config: 0
 state:  0
 speed: 0 Mbps now, 0 Mbps max
 3(sv_z1ad0102): addr:ba:46:f5:b8:4a:63
 config: 0
 state:  0
 speed: 0 Mbps now, 0 Mbps max
 4(sv_z1ad0103): addr:56:75:a3:a8:f7:89
 config: 0
 state:  0
 speed: 0 Mbps now, 0 Mbps max
 5(sv_z1ad0104): addr:9e:a9:30:0f:a2:53
 config: 0
 state:  0
 speed: 0 Mbps now, 0 Mbps max
 6(sv_z1ad4064): addr:26:de:29:e0:8a:12
 config: 0
 state:  0
 speed: 0 Mbps now, 0 Mbps max
 7(enp6s0f0): addr:00:1c:c4:47:63:31
 config: 0
 state:  0
 current:1GB-FD COPPER AUTO_NEG
 advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
 supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
 speed: 1000 Mbps now, 1000 Mbps max
 8(enp7s0f0): addr:00:1c:c4:47:63:33
 config: 0
 state:  0
 current:1GB-FD COPPER AUTO_NEG
 advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
 supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
 speed: 1000 Mbps now, 1000 Mbps max
 9(bond0): addr:0a:aa:d5:40:6d:9a
 config: 0
 state:  0
 speed: 0 Mbps now, 0 Mbps max
 LOCAL(vmbr1): addr:00:1c:c4:47:63:31
 config: 0
 state:  0
 speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
root@pve:~# ovs-vsctl --version
ovs-vsctl (Open vSwitch) 2.15.0
DB Schema 8.2.0

Is there any significant information in the ovs-dpctl output to see where
the problem might be?
Or what other command may I use to spot the issue?

What surprises me is that two ports of the bridge vmbr1 have ovs-system as
master that is in DOWN state.

root@pve:~# ip link show dev enp6s0f0
4: enp6s0f0:  mtu 1500 qdisc pfifo_fast
master ovs-system state UP mode DEFAULT group default qlen 1000
link/ether 00:1c:c4:47:63:31 brd ff:ff:ff:ff:ff:ff
root@pve:~# ip link show dev enp7s0f0
6: enp7s0f0:  mtu 1500 qdisc pfifo_fast
master ovs-system state UP mode DEFAULT group default qlen 1000
link/ether 00:1c:c4:47:63:33 brd ff:ff:ff:ff:ff:ff
root@pve:~# ip link show dev ovs-system
8: ovs-system:  mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether f6:c6:45:e5:39:98 brd ff:ff:ff:ff:ff:ff

Alex
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Bridge Hierarchy in OVS datapath

[Ben Pfaff]

On Mon, Oct 28, 2019 at 12:47:21PM +0530, Bhaskar Valaboju wrote:
> Based on documentation and code understanding I was under the impression
> that when a new bridge interface is created using ovs-vsct add-br* command,
> there will be a datapath instance created in kernel.  But my understanding
> seems wrong, there is only one datapath instance created and each bridge is
> added as an internal port to datapath.
> 
> I have a requirement to monitor OVS bridge and its hierarchy (ports added
> to it) in datapath.  Is there a way to get this information in datapath?

No.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Bridge Hierarchy in OVS datapath

[Bhaskar Valaboju]

Hello All,
Based on documentation and code understanding I was under the impression
that when a new bridge interface is created using ovs-vsct add-br* command,
there will be a datapath instance created in kernel.  But my understanding
seems wrong, there is only one datapath instance created and each bridge is
added as an internal port to datapath.

I have a requirement to monitor OVS bridge and its hierarchy (ports added
to it) in datapath.  Is there a way to get this information in datapath?

Thank you,
-Bhaskar
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Bridge datapath_type gets reset after couple of reboots

[Alex Yeh (ayeh) via discuss]

Ben,
Yes, it is intentional, ayeh-br1 has netdev set.

Thanks
Alex
(\__/)
(='.'=) 
(")_(")

-Original Message-
From: Ben Pfaff  
Sent: Thursday, June 20, 2019 5:29 PM
To: Alex Yeh (ayeh) 
Cc: Shriroop Joshi (shrirjos) ; 
ovs-discuss@openvswitch.org; Tobias Hofmann -T (tohofman - AAP3 INC at Cisco) 

Subject: Re: [ovs-discuss] Bridge datapath_type gets reset after couple of 
reboots

The ovsdb-tool.log shows several bridges being inserted but only one of them 
has its datapath_type set to netdev.  Is that intentional?

On Thu, Jun 20, 2019 at 11:46:09PM +, Alex Yeh (ayeh) wrote:
> Hi Ben,
>   Thanks for your reply and the suggestion.
>   We looked at the output of the command and don't seen command 
> explicitly modified the datapath_type on ayeh-br1 bridge. I turned on the 
> debug on ovs-vswitchd for the reboot hopefully it can provide some 
> information. I'm attaching the output from the command and the debug log from 
> ovs-vswitchd. 
> 
> Thanks much for any tip anyone can spare, Alex
> (\__/)
> (='.'=)
> (")_(")
> 
> -Original Message-
> From: Ben Pfaff 
> Sent: Thursday, June 20, 2019 9:26 AM
> To: Shriroop Joshi (shrirjos) 
> Cc: ovs-discuss@openvswitch.org; Alex Yeh (ayeh) ; 
> Tobias Hofmann -T (tohofman - AAP3 INC at Cisco) 
> Subject: Re: [ovs-discuss] Bridge datapath_type gets reset after 
> couple of reboots
> 
> On Thu, Jun 20, 2019 at 12:34:31AM +, Shriroop Joshi (shrirjos) via 
> discuss wrote:
> > I encountered a strange problem with OVS-DPDK. I created a bridge and 
> > changed its datapath_type to netdev after initializing DPDK.
> > After a couple of reboots, it's datapath_type gets reset with DPDK 
> > initialized. Also, vnics connected to the bridge get disconnected. We don't 
> > have any interfaces connected to the bridge. 
> 
> It's usually possible to track down the cause of database changes with 
> "ovsdb-tool -mm show-log", which shows what program made a change and when 
> and sometimes additional comments.

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Bridge datapath_type gets reset after couple of reboots

[Ben Pfaff]

The ovsdb-tool.log shows several bridges being inserted but only one of
them has its datapath_type set to netdev.  Is that intentional?

On Thu, Jun 20, 2019 at 11:46:09PM +, Alex Yeh (ayeh) wrote:
> Hi Ben,
>   Thanks for your reply and the suggestion.
>   We looked at the output of the command and don't seen command 
> explicitly modified the datapath_type on ayeh-br1 bridge. I turned on the 
> debug on ovs-vswitchd for the reboot hopefully it can provide some 
> information. I'm attaching the output from the command and the debug log from 
> ovs-vswitchd. 
> 
> Thanks much for any tip anyone can spare,
> Alex
> (\__/)
> (='.'=) 
> (")_(")
> 
> -Original Message-
> From: Ben Pfaff  
> Sent: Thursday, June 20, 2019 9:26 AM
> To: Shriroop Joshi (shrirjos) 
> Cc: ovs-discuss@openvswitch.org; Alex Yeh (ayeh) ; Tobias 
> Hofmann -T (tohofman - AAP3 INC at Cisco) 
> Subject: Re: [ovs-discuss] Bridge datapath_type gets reset after couple of 
> reboots
> 
> On Thu, Jun 20, 2019 at 12:34:31AM +, Shriroop Joshi (shrirjos) via 
> discuss wrote:
> > I encountered a strange problem with OVS-DPDK. I created a bridge and 
> > changed its datapath_type to netdev after initializing DPDK.
> > After a couple of reboots, it's datapath_type gets reset with DPDK 
> > initialized. Also, vnics connected to the bridge get disconnected. We don't 
> > have any interfaces connected to the bridge. 
> 
> It's usually possible to track down the cause of database changes with 
> "ovsdb-tool -mm show-log", which shows what program made a change and when 
> and sometimes additional comments.

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Bridge datapath_type gets reset after couple of reboots

[Ben Pfaff]

On Thu, Jun 20, 2019 at 12:34:31AM +, Shriroop Joshi (shrirjos) via discuss 
wrote:
> I encountered a strange problem with OVS-DPDK. I created a bridge and changed 
> its datapath_type to netdev after initializing DPDK.
> After a couple of reboots, it's datapath_type gets reset with DPDK 
> initialized. Also, vnics connected to the bridge get disconnected. We don't 
> have any interfaces connected to the bridge. 

It's usually possible to track down the cause of database changes with
"ovsdb-tool -mm show-log", which shows what program made a change and
when and sometimes additional comments.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Bridge

[Ben Pfaff]

On Fri, Dec 07, 2018 at 10:14:48AM +0530, Pranav Godway wrote:
>I want to understand what is meant by a bridge (br0) exactly.

A bridge and a switch are the same thing.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Bridge

[Pranav Godway]

Hi,
   I want to understand what is meant by a bridge (br0) exactly.

Regards
Pranav
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Bridge not taking ip address of bonded interface on dhclient command

[Tejali Bhujbal]

 I am using Ubuntu server and the following configuration but sometimes
vmbr0 does not take ip address at all.
so is there any alternative to dhclient?


ovs-vsctl add-br vmbr0
ifconfig vmbr0 up
ovs-vsctl add-bond vmbr0 bond0 enp7s0f0 enp7s0f1 trunks=1529,1530
ovs-vsctl set port bond0 lacp=active
ovs-vsctl set port bond0 bond-mode=balance-tcp
ovs-vsctl add-port vmbr0 vlan1529 tag=1529 -- set interface vlan1529
type=internal
ovs-vsctl add-port vmbr0 vlan1530 tag=1530 -- set interface vlan1530
type=internal
ifconfig bond0 0
dhclient vmbr0
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Bridge not working..

[Vishal Deep Ajmera]

Hi Steven,

Could you please dump the “ip route” table of kernel on the host ? I am 
suspecting if gateway configuration (10.80.180.1) on kitbr0 is causing an 
issue. Can you try removing the gateway configuration and verify again ?

Warm Regards,
Vishal Ajmera

From: ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Steven Pollock
Sent: Thursday, January 04, 2018 11:21 AM
To: ovs-discuss@openvswitch.org
Subject: [ovs-discuss] Bridge not working..

Hopefully this is the correct mailing list, there is no description on the 
admin page.

Running on Ubuntu 16.04 on top of vmware.

ens192 is connect to the 10.80.180.0/24<http://10.80.180.0/24> network
ens224 is connected to a standard vswitch4, and a windows machine is also 
connected to vswitch4

I expected packets from the windows machine 10.80.180.222 to pass through 
kitbr0 to any devices on the 10.80.180.0/24<http://10.80.180.0/24> network 
connected on ens192

Here is the /etc/network/interfaces


auto ens192

iface ens192 inet manual

auto ens224

iface ens224 inet manual



auto kitbr0

allow-ovs kitbr0

iface kitbr0 inet static

address 10.80.180.223

netmask 255.255.255.0

gateway 10.80.180.1

 ovs_type OVSBridge

 ovs_ports ens192 ens224


I also note that the mac address on the bridge and ens224 are the same.

The windows machine off ens224 can ping the bridge at 10.80.180.223
The devices off ens192 (the rest of the 10.80.180.x network) cannot ping 
10.80.180.223 however


ens192Link encap:Ethernet  HWaddr 00:50:56:ab:e2:5b

  inet6 addr: fe80::250:56ff:feab:e25b/64 Scope:Link

  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

  RX packets:74 errors:0 dropped:0 overruns:0 frame:0

  TX packets:369 errors:0 dropped:0 overruns:0 carrier:0

  collisions:0 txqueuelen:1000

  RX bytes:4964 (4.9 KB)  TX bytes:35695 (35.6 KB)



ens224Link encap:Ethernet  HWaddr 00:50:56:ab:46:85

  inet6 addr: fe80::250:56ff:feab:4685/64 Scope:Link

  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

  RX packets:289 errors:0 dropped:0 overruns:0 frame:0

  TX packets:166 errors:0 dropped:0 overruns:0 carrier:0

  collisions:0 txqueuelen:1000

  RX bytes:26138 (26.1 KB)  TX bytes:15431 (15.4 KB)



kitbr0Link encap:Ethernet  HWaddr 00:50:56:ab:46:85

  inet addr:10.80.180.223  Bcast:10.80.180.255  Mask:255.255.255.0

  inet6 addr: fe80::250:56ff:feab:4685/64 Scope:Link

  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

  RX packets:349 errors:0 dropped:37 overruns:0 frame:0

  TX packets:96 errors:0 dropped:0 overruns:0 carrier:0

  collisions:0 txqueuelen:1

  RX bytes:25386 (25.3 KB)  TX bytes:10749 (10.7 KB)



root@ovs:/etc/network# ovs-vsctl show

3a6b26a7-6e7a-44fd-8893-65f2c8fac4f2

Bridge "kitbr0"

Port "kitbr0"

Interface "kitbr0"

type: internal

Port "ens192"

Interface "ens192"

Port "ens224"

Interface "ens224"

ovs_version: "2.5.2"


Any clues about what is going are much appreciated. (I do not have a controller 
at this time)

thanks,

-Steve


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Bridge not working..

[Scott Lowe]

> On Jan 3, 2018, at 10:51 PM, Steven Pollock  wrote:
> 
> Hopefully this is the correct mailing list, there is no description on the 
> admin page.
> 
> Running on Ubuntu 16.04 on top of vmware.
> 
> ens192 is connect to the 10.80.180.0/24 network
> ens224 is connected to a standard vswitch4, and a windows machine is also 
> connected to vswitch4
> 
> I expected packets from the windows machine 10.80.180.222 to pass through 
> kitbr0 to any devices on the 10.80.180.0/24 network connected on ens192
> 
> Here is the /etc/network/interfaces
> 
> auto ens192
> iface ens192 inet manual
> 
> auto ens224
> iface ens224 inet manual
> 
> auto kitbr0
> allow-ovs kitbr0
> iface kitbr0 inet static
> address 10.80.180.223
> netmask 255.255.255.0
> gateway 10.80.180.1
>  ovs_type OVSBridge
>  ovs_ports ens192 ens224
> 
> 
> I also note that the mac address on the bridge and ens224 are the same.
> 
> The windows machine off ens224 can ping the bridge at 10.80.180.223
> The devices off ens192 (the rest of the 10.80.180.x network) cannot ping 
> 10.80.180.223 however
> 
> ens192Link encap:Ethernet  HWaddr 00:50:56:ab:e2:5b
>   inet6 addr: fe80::250:56ff:feab:e25b/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:74 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:369 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:4964 (4.9 KB)  TX bytes:35695 (35.6 KB)
> 
> ens224Link encap:Ethernet  HWaddr 00:50:56:ab:46:85
>   inet6 addr: fe80::250:56ff:feab:4685/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:289 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:166 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:26138 (26.1 KB)  TX bytes:15431 (15.4 KB)
> 
> kitbr0Link encap:Ethernet  HWaddr 00:50:56:ab:46:85
>   inet addr:10.80.180.223  Bcast:10.80.180.255  Mask:255.255.255.0
>   inet6 addr: fe80::250:56ff:feab:4685/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:349 errors:0 dropped:37 overruns:0 frame:0
>   TX packets:96 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1
>   RX bytes:25386 (25.3 KB)  TX bytes:10749 (10.7 KB)
> 
> 
> root@ovs:/etc/network# ovs-vsctl show
> 3a6b26a7-6e7a-44fd-8893-65f2c8fac4f2
> Bridge "kitbr0"
> Port "kitbr0"
> Interface "kitbr0"
> type: internal
> Port "ens192"
> Interface "ens192"
> Port "ens224"
> Interface "ens224"
> ovs_version: "2.5.2"
> 
> 
> Any clues about what is going are much appreciated. (I do not have a 
> controller at this time)


When running OVS in a VM on top of vSphere, you'll need to allow the NICs added 
to the OVS bridge to be in promiscuous mode. This is a setting on the vSwitch 
(IIRC it's called "Allow promiscuous mode"). Set that on the portgroup(s) where 
your interfaces are connected, and this should take care of it.

--
Scott



signature.asc
Description: Message signed with OpenPGP
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Bridge not working..

[Steven Pollock]

Hopefully this is the correct mailing list, there is no description on the
admin page.

Running on Ubuntu 16.04 on top of vmware.

ens192 is connect to the 10.80.180.0/24 network
ens224 is connected to a standard vswitch4, and a windows machine is also
connected to vswitch4

I expected packets from the windows machine 10.80.180.222 to pass through
kitbr0 to any devices on the 10.80.180.0/24 network connected on ens192

Here is the /etc/network/interfaces

auto ens192

iface ens192 inet manual

auto ens224

iface ens224 inet manual


auto kitbr0

allow-ovs kitbr0

iface kitbr0 inet static

address 10.80.180.223

netmask 255.255.255.0

gateway 10.80.180.1

 ovs_type OVSBridge

 ovs_ports ens192 ens224


I also note that the mac address on the bridge and ens224 are the same.

The windows machine off ens224 can ping the bridge at 10.80.180.223
The devices off ens192 (the rest of the 10.80.180.x network) cannot ping
10.80.180.223 however

ens192Link encap:Ethernet  HWaddr 00:50:56:ab:e2:5b

  inet6 addr: fe80::250:56ff:feab:e25b/64 Scope:Link

  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

  RX packets:74 errors:0 dropped:0 overruns:0 frame:0

  TX packets:369 errors:0 dropped:0 overruns:0 carrier:0

  collisions:0 txqueuelen:1000

  RX bytes:4964 (4.9 KB)  TX bytes:35695 (35.6 KB)


ens224Link encap:Ethernet  HWaddr 00:50:56:ab:46:85

  inet6 addr: fe80::250:56ff:feab:4685/64 Scope:Link

  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

  RX packets:289 errors:0 dropped:0 overruns:0 frame:0

  TX packets:166 errors:0 dropped:0 overruns:0 carrier:0

  collisions:0 txqueuelen:1000

  RX bytes:26138 (26.1 KB)  TX bytes:15431 (15.4 KB)


kitbr0Link encap:Ethernet  HWaddr 00:50:56:ab:46:85

  inet addr:10.80.180.223  Bcast:10.80.180.255  Mask:255.255.255.0

  inet6 addr: fe80::250:56ff:feab:4685/64 Scope:Link

  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

  RX packets:349 errors:0 dropped:37 overruns:0 frame:0

  TX packets:96 errors:0 dropped:0 overruns:0 carrier:0

  collisions:0 txqueuelen:1

  RX bytes:25386 (25.3 KB)  TX bytes:10749 (10.7 KB)


*root@ovs*:*/etc/network*# ovs-vsctl show

3a6b26a7-6e7a-44fd-8893-65f2c8fac4f2

Bridge "kitbr0"

Port "kitbr0"

Interface "kitbr0"

type: internal

Port "ens192"

Interface "ens192"

Port "ens224"

Interface "ens224"

ovs_version: "2.5.2"


Any clues about what is going are much appreciated. (I do not have a
controller at this time)

thanks,

-Steve
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] bridge several vlans and an IP IF

[IMMO WETZEL]

I fail with bridging multitagged vlans which brings me in trouble.
May be you can find the fault or solution for ovs

I do have one phy IF ens19 which is a trunk for several vlans.
But I do need only a few on a single iP interface.

Ens19.988
Ens19.988.0
Ens19.988.4090

These three vlans should be on a single bridge.
The bridge should get a ip interface which can be reached from the untagged, 
tagged and doubletagged vlan. Do to the scenario its not necessary to bridge 
between the three vlans .

Its simple to setup with bridgetools on linux but doesn't work.

I send a dhcp discover to the IP IF. This is received and processed from 
dhcrelay and the answer is on the IP IF of the bridge. (as far as tcpdump can 
see this)
But the frame never departed through the phy interface. All macs are learned 
and seen but the traffic isn't forwarded.

The only kick to bring it in working state is to remove the not necessary (for 
the moment) ifs for a moment and reconnect after dhcp is done and arps are 
exchange. Afterwards it works till arp/fdb aging is cleaning the tables.


1.   I wasn't able to bring together untagged single and doubletagged vlans 
on a single bridge. Un +tagged or un+double is possible but doesn't work.

2.   Same behavior with bridgeutils except the three vlans together on a 
bridge.

3.   All these /proc/sys/net/bridge/bridge-nf-* set to zero

4.   No firewall rules

5.   No ebtables rules



I really don't know why the frame isn't forwarded although the macs are valid 
and known.



Immo

THX alot



___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Bridge does not specify output ; ignoring? (OVS-DPDK Ubuntu)

[Aaron Conole]

"Stokes, Ian"  writes:

>> The mirror-related errors in the log.  ovs-tcpdump creates a mirror.
>
> Are there any other errors in the logs? (with a view to figuring out
> why traffic isn't reaching the VMs). Feel free to attach them if
> you're unsure.
>
> Can you provide some more detail with regards to your setup?
>
> OVS release/commit, DPDK release, QEMU version etc.
>
>> 
>> On Tue, Dec 06, 2016 at 03:05:32PM -0500, Lax Clarke wrote:
>> > Pardon?  What's caused by ovs-tcpdump??
>> >
>> > On Tue, Dec 6, 2016 at 2:17 PM, Ben Pfaff  wrote:
>> >
>> > > Oh, it's probably caused by ovs-tcpdump, now that I think about it.
>> > >
>> > > On Tue, Dec 06, 2016 at 01:20:19PM -0500, Lax Clarke wrote:
>> > > > I do not think we did.
>> > > >
>> > > > Only config we did:
>> > > >
>> > > > # Subscribers DPDK-based Bridge
>> > > > ovs-vsctl add-br flat-br-0 -- set bridge flat-br-0
>> > > > datapath_type=netdev ovs-vsctl add-port flat-br-0 dpdk0 -- set
>> > > > Interface dpdk0 type=dpdk ovs-vsctl add-port flat-br-0
>> > > > stack-1-pts-1-subscribers-1 -- set Interface
>> > > > stack-1-pts-1-subscribers-1 type=dpdkvhostuser
>> > > >
>> > > > # Internet DPDK-based Bridge
>> > > > ovs-vsctl add-br flat-br-1 -- set bridge flat-br-1
>> > > > datapath_type=netdev ovs-vsctl add-port flat-br-1 dpdk1 -- set
>> > > > Interface dpdk1 type=dpdk ovs-vsctl add-port flat-br-1
>> > > > stack-1-pts-1-internet-1 -- set Interface
>> > > > stack-1-pts-1-internet-1 type=dpdkvhostuser
>> > > >
>> > > > # Bring it up (not sure if needed) ip link set dev flat-br-0 up ip
>> > > > link set dev flat-br-1 up
>> > > >
>> > > > # Enable multi-queue on host side, 4 queues ovs-vsctl set
>> > > > interface dpdk0 options:n_rxq=2 ovs-vsctl set interface dpdk1
>> > > > options:n_rxq=2
>
> How are you launching the VMs (i.e. QEMU, libvirt)?
> What parameters are you using to launch & setup multi-queue for the VM 
> interfaces?

+1 - I'd like to see this information, as well.

Can you also do an `ls -lah $OVS_RUNDIR` where OVS_RUNDIR= the path to
the runtime directory of the vswitchd (usually either
/var/run/openvswitch, or /usr/var/run/openvswitch, or
/usr/local/var/run/openvswitch).

and a `ps aux | grep qemu`

There may be permissions issues when using vhost-user server mode
(possibly even selinux issues with the unix domain socket).

> Thanks
> Ian
>
. . .

>> > > > > > The error I see in ovs switch log says:
>> > > > > > 2016-12-06T17:14:41.170Z|00092|bridge|ERR|bridge flat-br-0:
>> > > > > > mirror
>> > > > > > m_flat-br-0 does not specify output; ignoring
>> > > > > > 2016-12-06T17:14:41.170Z|00093|bridge|ERR|bridge flat-br-0:
>> > > > > > mirror
>> > > > > > m_flat-br-0 does not specify output; ignoring
>> > > > > > 2016-12-06T17:14:41.170Z|00094|bridge|ERR|bridge flat-br-0:
>> > > > > > mirror
>> > > > > > m_flat-br-0 does not specify output; ignoring
>> > > > > > 2016-12-06T17:14:41.171Z|00095|bridge|ERR|bridge flat-br-1:
>> > > > > > mirror
>> > > > > > m_flat-br-1 does not specify output; ignoring
>> > > > > > 2016-12-06T17:14:41.171Z|00096|bridge|ERR|bridge flat-br-1:
>> > > > > > mirror
>> > > > > > m_flat-br-1 does not specify output; ignoring
>> > > > > > 2016-12-06T17:14:41.171Z|00097|bridge|ERR|bridge flat-br-1:
>> > > > > > mirror
>> > > > > > m_flat-br-1 does not specify output; ignoring

Sorry for jumping into this late;  I agree with Ben, this is likely
a mirror error caused by ovs-tcpdump.  I never tried it on the bridge
port, so I'll do some tests and see if I can recreate it.  In the
meantime, if you didn't create those mirror ports, feel free to remove
them.

I doubt it is related to your connectivity issue, though.

>> > > > > > What does this mean?
>> > > > > > I browsed code here
>> > > > > > https://github.com/osrg/openvswitch/blob/master/
>> > > vswitchd/bridge.c#L3641
>> > > > > > It seems to suggest that I need either an output port or an
>> > > > > > output
>> > > vlan.
>> > > > >
>> > > > > How did you configure mirroring?
>> > > > >
>> > >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Bridge does not specify output ; ignoring? (OVS-DPDK Ubuntu)

[Ben Pfaff]

The mirror-related errors in the log.  ovs-tcpdump creates a mirror.

On Tue, Dec 06, 2016 at 03:05:32PM -0500, Lax Clarke wrote:
> Pardon?  What's caused by ovs-tcpdump??
> 
> On Tue, Dec 6, 2016 at 2:17 PM, Ben Pfaff  wrote:
> 
> > Oh, it's probably caused by ovs-tcpdump, now that I think about it.
> >
> > On Tue, Dec 06, 2016 at 01:20:19PM -0500, Lax Clarke wrote:
> > > I do not think we did.
> > >
> > > Only config we did:
> > >
> > > # Subscribers DPDK-based Bridge
> > > ovs-vsctl add-br flat-br-0 -- set bridge flat-br-0 datapath_type=netdev
> > > ovs-vsctl add-port flat-br-0 dpdk0 -- set Interface dpdk0 type=dpdk
> > > ovs-vsctl add-port flat-br-0 stack-1-pts-1-subscribers-1 -- set Interface
> > > stack-1-pts-1-subscribers-1 type=dpdkvhostuser
> > >
> > > # Internet DPDK-based Bridge
> > > ovs-vsctl add-br flat-br-1 -- set bridge flat-br-1 datapath_type=netdev
> > > ovs-vsctl add-port flat-br-1 dpdk1 -- set Interface dpdk1 type=dpdk
> > > ovs-vsctl add-port flat-br-1 stack-1-pts-1-internet-1 -- set Interface
> > > stack-1-pts-1-internet-1 type=dpdkvhostuser
> > >
> > > # Bring it up (not sure if needed)
> > > ip link set dev flat-br-0 up
> > > ip link set dev flat-br-1 up
> > >
> > > # Enable multi-queue on host side, 4 queues
> > > ovs-vsctl set interface dpdk0 options:n_rxq=2
> > > ovs-vsctl set interface dpdk1 options:n_rxq=2
> > >
> > > # Give mode CPU Cores to ovs-vswitchd PMD threads
> > > ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=
> > >
> > >
> > > On Tue, Dec 6, 2016 at 12:37 PM, Ben Pfaff  wrote:
> > >
> > > > On Tue, Dec 06, 2016 at 12:20:35PM -0500, Lax Clarke wrote:
> > > > > I'm having trouble with 2 OVS bridges I've configured (sitting on
> > top of
> > > > > OVS-DPDK):
> > > > >
> > > > > 2e18698f-9583-4c59-972c-72c2c32cfc7d
> > > > > Bridge "flat-br-1"
> > > > > Port "stack-1-pts-1-internet-1"
> > > > > Interface "stack-1-pts-1-internet-1"
> > > > > type: dpdkvhostuser
> > > > > Port "flat-br-1"
> > > > > Interface "flat-br-1"
> > > > > type: internal
> > > > > Port "dpdk1"
> > > > > Interface "dpdk1"
> > > > > type: dpdk
> > > > > options: {n_rxq="2"}
> > > > > Bridge "flat-br-0"
> > > > > Port "flat-br-0"
> > > > > Interface "flat-br-0"
> > > > > type: internal
> > > > > Port "stack-1-pts-1-subscribers-1"
> > > > > Interface "stack-1-pts-1-subscribers-1"
> > > > > type: dpdkvhostuser
> > > > > Port "dpdk0"
> > > > > Interface "dpdk0"
> > > > > type: dpdk
> > > > > options: {n_rxq="2"}
> > > > > ovs_version: "2.6.0"
> > > > >
> > > > >
> > > > > I have these OF rules (nothing special):
> > > > > root@terago-2:/home/sandvine/svauto# ovs-ofctl dump-flows flat-br-0
> > > > > NXST_FLOW reply (xid=0x4):
> > > > >  cookie=0x0, duration=231.086s, table=0, n_packets=9853,
> > n_bytes=591180,
> > > > > idle_age=1, priority=0 actions=NORMAL
> > > > > root@terago-2:/home/sandvine/svauto# ovs-ofctl dump-flows flat-br-1
> > > > > NXST_FLOW reply (xid=0x4):
> > > > >  cookie=0x0, duration=234.638s, table=0, n_packets=9984,
> > n_bytes=599040,
> > > > > idle_age=2, priority=0 actions=NORMAL
> > > > >
> > > > > The traffic is reaching the bridges themselves (i.e., ovs-tcpdump on
> > > > > bridges shows the traffic), but not reaching the endpoints (VMs).
> > > >
> > > > OK...
> > > >
> > > > > The error I see in ovs switch log says:
> > > > > 2016-12-06T17:14:41.170Z|00092|bridge|ERR|bridge flat-br-0: mirror
> > > > > m_flat-br-0 does not specify output; ignoring
> > > > > 2016-12-06T17:14:41.170Z|00093|bridge|ERR|bridge flat-br-0: mirror
> > > > > m_flat-br-0 does not specify output; ignoring
> > > > > 2016-12-06T17:14:41.170Z|00094|bridge|ERR|bridge flat-br-0: mirror
> > > > > m_flat-br-0 does not specify output; ignoring
> > > > > 2016-12-06T17:14:41.171Z|00095|bridge|ERR|bridge flat-br-1: mirror
> > > > > m_flat-br-1 does not specify output; ignoring
> > > > > 2016-12-06T17:14:41.171Z|00096|bridge|ERR|bridge flat-br-1: mirror
> > > > > m_flat-br-1 does not specify output; ignoring
> > > > > 2016-12-06T17:14:41.171Z|00097|bridge|ERR|bridge flat-br-1: mirror
> > > > > m_flat-br-1 does not specify output; ignoring
> > > > >
> > > > > What does this mean?
> > > > > I browsed code here
> > > > > https://github.com/osrg/openvswitch/blob/master/
> > vswitchd/bridge.c#L3641
> > > > > It seems to suggest that I need either an output port or an output
> > vlan.
> > > >
> > > > How did you configure mirroring?
> > > >
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Bridge does not specify output ; ignoring? (OVS-DPDK Ubuntu)

[Lax Clarke]

I do not think we did.

Only config we did:

# Subscribers DPDK-based Bridge
ovs-vsctl add-br flat-br-0 -- set bridge flat-br-0 datapath_type=netdev
ovs-vsctl add-port flat-br-0 dpdk0 -- set Interface dpdk0 type=dpdk
ovs-vsctl add-port flat-br-0 stack-1-pts-1-subscribers-1 -- set Interface
stack-1-pts-1-subscribers-1 type=dpdkvhostuser

# Internet DPDK-based Bridge
ovs-vsctl add-br flat-br-1 -- set bridge flat-br-1 datapath_type=netdev
ovs-vsctl add-port flat-br-1 dpdk1 -- set Interface dpdk1 type=dpdk
ovs-vsctl add-port flat-br-1 stack-1-pts-1-internet-1 -- set Interface
stack-1-pts-1-internet-1 type=dpdkvhostuser

# Bring it up (not sure if needed)
ip link set dev flat-br-0 up
ip link set dev flat-br-1 up

# Enable multi-queue on host side, 4 queues
ovs-vsctl set interface dpdk0 options:n_rxq=2
ovs-vsctl set interface dpdk1 options:n_rxq=2

# Give mode CPU Cores to ovs-vswitchd PMD threads
ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=


On Tue, Dec 6, 2016 at 12:37 PM, Ben Pfaff  wrote:

> On Tue, Dec 06, 2016 at 12:20:35PM -0500, Lax Clarke wrote:
> > I'm having trouble with 2 OVS bridges I've configured (sitting on top of
> > OVS-DPDK):
> >
> > 2e18698f-9583-4c59-972c-72c2c32cfc7d
> > Bridge "flat-br-1"
> > Port "stack-1-pts-1-internet-1"
> > Interface "stack-1-pts-1-internet-1"
> > type: dpdkvhostuser
> > Port "flat-br-1"
> > Interface "flat-br-1"
> > type: internal
> > Port "dpdk1"
> > Interface "dpdk1"
> > type: dpdk
> > options: {n_rxq="2"}
> > Bridge "flat-br-0"
> > Port "flat-br-0"
> > Interface "flat-br-0"
> > type: internal
> > Port "stack-1-pts-1-subscribers-1"
> > Interface "stack-1-pts-1-subscribers-1"
> > type: dpdkvhostuser
> > Port "dpdk0"
> > Interface "dpdk0"
> > type: dpdk
> > options: {n_rxq="2"}
> > ovs_version: "2.6.0"
> >
> >
> > I have these OF rules (nothing special):
> > root@terago-2:/home/sandvine/svauto# ovs-ofctl dump-flows flat-br-0
> > NXST_FLOW reply (xid=0x4):
> >  cookie=0x0, duration=231.086s, table=0, n_packets=9853, n_bytes=591180,
> > idle_age=1, priority=0 actions=NORMAL
> > root@terago-2:/home/sandvine/svauto# ovs-ofctl dump-flows flat-br-1
> > NXST_FLOW reply (xid=0x4):
> >  cookie=0x0, duration=234.638s, table=0, n_packets=9984, n_bytes=599040,
> > idle_age=2, priority=0 actions=NORMAL
> >
> > The traffic is reaching the bridges themselves (i.e., ovs-tcpdump on
> > bridges shows the traffic), but not reaching the endpoints (VMs).
>
> OK...
>
> > The error I see in ovs switch log says:
> > 2016-12-06T17:14:41.170Z|00092|bridge|ERR|bridge flat-br-0: mirror
> > m_flat-br-0 does not specify output; ignoring
> > 2016-12-06T17:14:41.170Z|00093|bridge|ERR|bridge flat-br-0: mirror
> > m_flat-br-0 does not specify output; ignoring
> > 2016-12-06T17:14:41.170Z|00094|bridge|ERR|bridge flat-br-0: mirror
> > m_flat-br-0 does not specify output; ignoring
> > 2016-12-06T17:14:41.171Z|00095|bridge|ERR|bridge flat-br-1: mirror
> > m_flat-br-1 does not specify output; ignoring
> > 2016-12-06T17:14:41.171Z|00096|bridge|ERR|bridge flat-br-1: mirror
> > m_flat-br-1 does not specify output; ignoring
> > 2016-12-06T17:14:41.171Z|00097|bridge|ERR|bridge flat-br-1: mirror
> > m_flat-br-1 does not specify output; ignoring
> >
> > What does this mean?
> > I browsed code here
> > https://github.com/osrg/openvswitch/blob/master/vswitchd/bridge.c#L3641
> > It seems to suggest that I need either an output port or an output vlan.
>
> How did you configure mirroring?
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss