Comment 29 for bug 1912844

> The next question is exactly which interfaces we should be excluding from the set of interfaces we consider. At the moment, my POC is excluding interfaces whose name matches an OVS bridge, determined via `ovs-vsctl list-br`. In an instance with an additional VLAN to the above configurations, I see:
>
> # ovs-vsctl list-br
> ovs-br
> ovs-br.100
> ovs-br.200
>
> Does this seems appropriate? I also notice that querying for internal interfaces returns the same set:

While listing the bridges would work for configurations that make use
of the 'fake-bridge' paradigm, it would not work for listing
interfaces in configurations that do not use it. So I would rely on
querying the port/interface tables as entry point instead.

> # ovs-vsctl find interface type=internal | grep ^name
> name : ovs-br
> name : ovs-br.200
> name : ovs-br.100

The interface types I know about today are 'dpdk', 'system', and 'internal'.

Interfaces of type 'dpdk' would probably be invisible from the kernel
sysfs and netlink interfaces pov, interfaces of type 'system' have
their origin in the system and cloud-init would most likely already
know all about them. Interfaces of type 'internal' may be used for
other things than VLANs so depending on what you want to match on it
may or may not be precise enough. See below for some further
discussion.

> I don't think we want to exclude every interface known to OVS, because I believe that would regress bug 1898997. From an instance launched from the integration test for that bug:
>
> cb6840fc-f53d-471b-b7e7-aa7398fd4c37
> Bridge ovs-br
> fail_mode: standalone
> Port enp5s0
> Interface enp5s0
> Port ovs-br
> Interface ovs-br
> type: internal
> ovs_version: "2.13.1"
>
> We _do_ still want to consider enp5s0 in cloud-init's code, because it's a real interface that isn't (entirely?) configured by OVS.
>
> Thoughts? (If this isn't a sufficient problem description, let me know!)

Do I understand correctly that the goal is to find any OVS managed
interface with a VLAN tag to exclude it from the duplicate MAC check?
If so the following may be an approach to find them:

    ovs-vsctl find port 'tag>0'

From the port name you can find the associated interfaces and there is
also a shorthand to find on which bridge a port belongs:

    ovs-vsctl port-to-br <PORT NAME>