Parsing of a flow with tp_dst and tp_src in port/mask format does not work.
Currently parseIntMatch() assumes only a single port in tp_dst and tp_src and not a port-range. As a result parsing a flow with port range fails.

tp_dst=0xea60/0xffe0

'ovs-ofctl add-group' is not supported yet. Are there any plans to add the support ? Some advanced features are dependent on Group table for example load-balancing.

Hi all.

If there're not any OpenvSwitch in the system but the length of the return value of VSwitch.ListBridges() is 1 not zero.

I think that is caused by the strings.Split and you can find it below.

Do we need to fix it by return a empty string array if the output of list-br is empty string?

Thanks.

I am using this library to parse OVS flows, and I need the n_bytes and n_packets information of the flow. I noticed that these fields are ignored in the UnmarshalText function. I think it would be beneficial if I could access n_bytes and n_packets directly from the Flow structure.

I solved my problem by using the DumpAggregate function. However, in my case, I need to retrieve the n_bytes of many flows, which results in numerous DumpAggregate calls instead of a single DumpFlows call.

I'm curious whether this behavior is intentional or simply not yet implemented. If there are no other considerations, I would be willing to contribute some code to address this issue.

Despite the documentation for e.g. TransportSourcePort saying that it "matches packets with a transport layer (TCP/UDP)" port, it does not actually work with UDP--OvS reports an error if you try to match using tp_src or tp_dst when the protocol udp is specified: prerequisites not met for setting tp_src.

I expect to have a PR ready to address this in the not-too-distant future.

The ovs-vsctl is able to set a lot of options for the port, such as tos、dst_port and so on. Maybe can extend the InterfaceOptions by adding "Options" ([]string) field for developer to add any option freely by themselves。

i'm using now ebay/go-ovn with own fixes for dhcp support and logical router.
Do you plan to start supporting ovn features so i can contribute more code (as ebay/go-ovn maintainers not respond via issues)

I see that we can only set openflow protocols as bridge options.

// Bridge sets configuration for a bridge using the values from a BridgeOptions
// struct.
func (v *VSwitchSetService) Bridge(bridge string, options BridgeOptions) error {
        // Prepend command line arguments before expanding options slice
        // and appending it
        args := []string{"set", "bridge", bridge}
        args = append(args, options.slice()...)
        log.Println(args)
        _, err := v.v.exec(args...)
        return err
}

Would it be possible to add another method to allow for setting something like "other-config:forward-bpdu=true", or possibly extend the BridgeOptions struct to allow 'other-options'

// BridgeOther allows for setting of non openflow BridgeOptions
func (v *VSwitchSetService) BridgeOther(bridge string, options string) error {
        // Prepend command line arguments before expanding options string
        // and appending it
        args := []string{"set", "bridge", bridge}
        args = append(args, options)
        _, err := v.v.exec(args...)
        return err
}

Thanks!

Hi.
I want to use the vSwitch client to add the port with the vlan tag.

I saw the original AddPort method only accept the interface name but no more options.

Thanks.

Is there any support and data wrappers for ovs-vsctl list interface command and the likes of it? If not, are there plans to add the support?
I didn't find any code examples for any db query except ListDatabases, am I missing something?

This is a Feature Request

ovs-vsctl is able to set external-ids properties to records in ovsdb

ovs-vsctl set Interface foo external-ids:iface-id=bar external-ids:iface-status=active external-ids:attached-mac=<mac> external-ids:vm-uuid:<uuid>

This is actually used by OpenStack Nova agent to pass information for Neutron agent to populate proper overflow rules.

go-openvswicth has (v *VSwitchSetService) Interface(ifi string, options InterfaceOptions) method able to set Interface properties, however, not external-ids ones.

go-openvswitch should extend the Interface method to make it possible to set external-ids key-value pairs.

Is there a way to connect ovsdb-server running as a remote TCP server? I found the package ovs only support Unix domain server.

Original requirement: fetch vport stats like rx_packets tx_packets etc.

I've run into an issue when trying to dump flows or delete flows using Openflow14.

If I create a new client and specify the protocols it is not used on all open flow executions

client := ovs.New(
    ovs.Debug("true"),
    ovs.Debug(ovs.Protocols([]string{ovs.ProtocolOpenFlow14}),
)

client.OpenFlow.DelFlows(
    "br1",
    &ovs.MatchFlow{
        Cookie:    cookie, // cookie and mask are predefined outside this example
        CookieMask: mask,
    },
)

This results in

2019/01/03 20:51:32 ovs: exec: ovs-ofctl [del-flows br1 cookie=0x0000006000000000/0x00000fffff000000,table=0]
2019/01/03 20:51:32 ovs: exec: "2019-01-03T20:51:32Z|00001|vconn|WARN|unix:/var/run/openvswitch/br1.mgmt: version negotiation failed (we support version 0x01, peer supports version 0x05)\novs-ofctl: br1: failed to connect to socket (Broken pipe)"

If I use the patch

diff --git a/vendor/github.com/digitalocean/go-openvswitch/ovs/openflow.go b/vendor/github.com/digitalocean/go-openvswitch/ovs/openflow.go
index 7591482..8bd339a 100644
--- a/vendor/github.com/digitalocean/go-openvswitch/ovs/openflow.go
+++ b/vendor/github.com/digitalocean/go-openvswitch/ovs/openflow.go
@@ -453,6 +453,7 @@ func parseEach(in []byte, prefix []byte, fn func(b []byte) error) error {

 // exec executes an ExecFunc using 'ovs-ofctl'.
 func (o *OpenFlowService) exec(args ...string) ([]byte, error) {
+       args = append(o.c.ofctlFlags, args...)
        return o.c.exec("ovs-ofctl", args...)
 }

it adds the flag and works as expected.

2019/01/03 21:00:59 ovs: exec: ovs-ofctl [--protocols=OpenFlow14 del-flows br1 cookie=0x0000006000000000/0x00000fffff000000,table=0]
2019/01/03 21:00:59 ovs: exec: ""

My question is. Should this flag be added to every execution like it is in this patch or should it only be added for specific commands?

So far it is not added for dump-flows or del-flows which cause the above error for me. If it is safe to add to every ovs-ofctl command I can get the PR created to add it and remove the specific ones for commands. Or if there is a list of commands it should be used on I can open a PR for just those.

Hi,

I recently discovered this project in search for a way to manipulate flow tables on OVS using Golang.

The AddFlow function works well for me, and I suppose that instead of modifying a flow, I could delete it and add the new one.

Yet, I wanted to ask if there is a reason for not supporting client.OpenFlow.ModFlow()? Or does it do delete and add internally anyway? Maybe I could contribute this functionality if there is a reason to do so.

Hope to hear from you soon!
LaumiH

when use ovs-ofctl not support --strict
when use matchflow to del flows, not support priority

Hii.

The type of PortID in the PortStats is int and it's not a fixed length type.
We will meet the problems if we want to write that PortStats struct to buffer via the binary.Write.

I think we can fix that problem by changing the type from int to int32 to make the whole structure fixed length.

What do you think ?

Thanks.

type PortStats struct {
	// PortID specifies the OVS port ID which this PortStats refers to.
	PortID int

	// Received and Transmitted contain information regarding the number
	// of received and transmitted packets, bytes, etc.
	// OVS stores all of these counters as uint64 values.
	Received    PortStatsReceive
	Transmitted PortStatsTransmit
}