Re: [ovs-discuss] OVS port name differ from interface name

[Shivaram Mysore]

There is s typo in add-br command.  Your bridge name is br instead of 0.br



/Shivaram
::Sent from my mobile device::

> On Jan 18, 2018, at 5:17 AM, Riccardo Ravaioli  
> wrote:
> 
> Hi Ben,
> 
> I have a related question. I do the following in order to have a bridge br 
> with ports 0.br, 1.br... and later add existing interfaces to such ports:
> 
> ovs-vsctl add-br br
> ovs-vsctl add-port br 0.br 
> ovs-vsctl --id=@ifce create interface  name=eth1 -- set port 0.br 
> interface=@ifce
> 
> When I execute the "ovs-vsctl add-port' command above I get an error saying 
> that 0.br doesn't correspond to any interface:
> ovs-vsctl: Error detected while setting up '0.switch5': could not open 
> network device 0.switch5 (No such device).
> 
> Can I pass an argument to "ovs-vsctl add-port" to tell OVS that 0.br is just 
> a switch port and not a real existing interface? 
> 
> 
> __
> 
> 
>> On 15 January 2018 at 20:19, Ben Pfaff  wrote:
>> On Mon, Jan 15, 2018 at 09:50:52AM -0800, Fred Licht wrote:
>> >Is it possible to have an OVS port ‘name’ differ from the interface 
>> > name?
>> >
>> > Bridge ovs-ha-sw
>> > Port ovs-ha-sw
>> > Interface ovs-ha-sw
>> > type: internal
>> > Port "bond1"
>> > Interface "bond1"
>> >
>> > To have the effect of:
>> >
>> > Bridge ovs-ha-sw
>> > Port ovs-ha-sw
>> > Interface ovs-ha-sw
>> > type: internal
>> > Port “east-west"
>> > Interface "bond1"
>> 
>> You can do it, but since port names are immutable it has to happen at
>> the time you add the port.  For example:
>> 
>> blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl add-br br0
>> blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl add-port br0 p0 -- set port 
>> p0 name=asdf
>> blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl show
>> 8b75cccb-f1eb-4e75-ac67-57ebac4e8432
>> Bridge "br0"
>> Port "br0"
>> Interface "br0"
>> type: internal
>> Port asdf
>> Interface "p0"
>> blp@sigabrt:~/nicira/ovs/tutorial(0)$
>> ___
>> 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
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS port name differ from interface name

[Riccardo Ravaioli]

In the example above my bridge name is br and my ports are named 0.br, 1.br,
etc.
It's just an example. I could have chosen myport0, myport1, etc.

On 18 January 2018 at 14:39, Shivaram Mysore 
wrote:

> There is s typo in add-br command.  Your bridge name is br instead of 0.br
>
>
>
> /Shivaram
> ::Sent from my mobile device::
>
> On Jan 18, 2018, at 5:17 AM, Riccardo Ravaioli 
> wrote:
>
> Hi Ben,
>
> I have a related question. I do the following in order to have a bridge br
> with ports 0.br, 1.br... and later add existing interfaces to such ports:
>
> ovs-vsctl add-br br
> ovs-vsctl add-port br 0.br
> ovs-vsctl --id=@ifce create interface  name=eth1 -- set port 0.br
> interface=@ifce
>
> When I execute the "ovs-vsctl add-port' command above I get an error
> saying that 0.br doesn't correspond to any interface:
> *ovs-vsctl: Error detected while setting up '0.switch5': could not open
> network device 0.switch5 (No such device).*
>
> Can I pass an argument to "ovs-vsctl add-port" to tell OVS that 0.br is
> just a switch port and not a real existing interface?
>
>
> __
>
>
> On 15 January 2018 at 20:19, Ben Pfaff  wrote:
>
>> On Mon, Jan 15, 2018 at 09:50:52AM -0800, Fred Licht wrote:
>> >Is it possible to have an OVS port ‘name’ differ from the interface
>> name?
>> >
>> > Bridge ovs-ha-sw
>> > Port ovs-ha-sw
>> > Interface ovs-ha-sw
>> > type: internal
>> > Port "bond1"
>> > Interface "bond1"
>> >
>> > To have the effect of:
>> >
>> > Bridge ovs-ha-sw
>> > Port ovs-ha-sw
>> > Interface ovs-ha-sw
>> > type: internal
>> > Port “east-west"
>> > Interface "bond1"
>>
>> You can do it, but since port names are immutable it has to happen at
>> the time you add the port.  For example:
>>
>> blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl add-br br0
>> blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl add-port br0 p0 -- set
>> port p0 name=asdf
>> blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl show
>> 8b75cccb-f1eb-4e75-ac67-57ebac4e8432
>> Bridge "br0"
>> Port "br0"
>> Interface "br0"
>> type: internal
>> Port asdf
>> Interface "p0"
>> blp@sigabrt:~/nicira/ovs/tutorial(0)$
>> ___
>> 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
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS port name differ from interface name

[Riccardo Ravaioli]

Hi Ben,

I have a related question. I do the following in order to have a bridge br
with ports 0.br, 1.br... and later add existing interfaces to such ports:

ovs-vsctl add-br br
ovs-vsctl add-port br 0.br
ovs-vsctl --id=@ifce create interface  name=eth1 -- set port 0.br
interface=@ifce

When I execute the "ovs-vsctl add-port' command above I get an error saying
that 0.br doesn't correspond to any interface:
*ovs-vsctl: Error detected while setting up '0.switch5': could not open
network device 0.switch5 (No such device).*

Can I pass an argument to "ovs-vsctl add-port" to tell OVS that 0.br is
just a switch port and not a real existing interface?


__


On 15 January 2018 at 20:19, Ben Pfaff  wrote:

> On Mon, Jan 15, 2018 at 09:50:52AM -0800, Fred Licht wrote:
> >Is it possible to have an OVS port ‘name’ differ from the interface
> name?
> >
> > Bridge ovs-ha-sw
> > Port ovs-ha-sw
> > Interface ovs-ha-sw
> > type: internal
> > Port "bond1"
> > Interface "bond1"
> >
> > To have the effect of:
> >
> > Bridge ovs-ha-sw
> > Port ovs-ha-sw
> > Interface ovs-ha-sw
> > type: internal
> > Port “east-west"
> > Interface "bond1"
>
> You can do it, but since port names are immutable it has to happen at
> the time you add the port.  For example:
>
> blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl add-br br0
> blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl add-port br0 p0 -- set
> port p0 name=asdf
> blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl show
> 8b75cccb-f1eb-4e75-ac67-57ebac4e8432
> Bridge "br0"
> Port "br0"
> Interface "br0"
> type: internal
> Port asdf
> Interface "p0"
> blp@sigabrt:~/nicira/ovs/tutorial(0)$
> ___
> 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

Re: [ovs-discuss] OVS port name differ from interface name

[Ben Pfaff]

Maybe you want it to be an "internal" port:
ovs-vsctl set interface  type=internal

On Thu, Jan 18, 2018 at 02:17:03PM +0100, Riccardo Ravaioli wrote:
> Hi Ben,
> 
> I have a related question. I do the following in order to have a bridge br
> with ports 0.br, 1.br... and later add existing interfaces to such ports:
> 
> ovs-vsctl add-br br
> ovs-vsctl add-port br 0.br
> ovs-vsctl --id=@ifce create interface  name=eth1 -- set port 0.br
> interface=@ifce
> 
> When I execute the "ovs-vsctl add-port' command above I get an error saying
> that 0.br doesn't correspond to any interface:
> *ovs-vsctl: Error detected while setting up '0.switch5': could not open
> network device 0.switch5 (No such device).*
> 
> Can I pass an argument to "ovs-vsctl add-port" to tell OVS that 0.br is
> just a switch port and not a real existing interface?
> 
> 
> __
> 
> 
> On 15 January 2018 at 20:19, Ben Pfaff  wrote:
> 
> > On Mon, Jan 15, 2018 at 09:50:52AM -0800, Fred Licht wrote:
> > >Is it possible to have an OVS port ‘name’ differ from the interface
> > name?
> > >
> > > Bridge ovs-ha-sw
> > > Port ovs-ha-sw
> > > Interface ovs-ha-sw
> > > type: internal
> > > Port "bond1"
> > > Interface "bond1"
> > >
> > > To have the effect of:
> > >
> > > Bridge ovs-ha-sw
> > > Port ovs-ha-sw
> > > Interface ovs-ha-sw
> > > type: internal
> > > Port “east-west"
> > > Interface "bond1"
> >
> > You can do it, but since port names are immutable it has to happen at
> > the time you add the port.  For example:
> >
> > blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl add-br br0
> > blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl add-port br0 p0 -- set
> > port p0 name=asdf
> > blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl show
> > 8b75cccb-f1eb-4e75-ac67-57ebac4e8432
> > Bridge "br0"
> > Port "br0"
> > Interface "br0"
> > type: internal
> > Port asdf
> > Interface "p0"
> > blp@sigabrt:~/nicira/ovs/tutorial(0)$
> > ___
> > 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

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

Re: [ovs-discuss] In 'OVS Faucet Tutorial', router does not work as expected at 'Step 4: Router Broadcasts ARP Request'

[Ben Pfaff]

I sent a series that adds these features:
https://patchwork.ozlabs.org/project/openvswitch/list/?series=24270

On Thu, Jan 18, 2018 at 09:34:40AM +1300, Brad Cowie wrote:
> We've had a bit of a think about this, variable length probably isn't too
> important (static 64b is probably fine), but yes, being able to set those
> 64 bytes will be quite useful with say with an extra "payload=0xC0FEFE"
> argument on ofproto/trace.
> 
> Brad
> 
> On 18 January 2018 at 07:17, Ben Pfaff  wrote:
> 
> > OK, sounds good.
> >
> > Do you think you need the ability to inject payloads of a specific
> > length or content?  It's easy to, for example, always generate 64 bytes
> > of payload, but it would be a little more challenging to plumb through
> > extra data or metadata.
> >
> > On Mon, Jan 15, 2018 at 01:48:10PM +1300, Brad Cowie wrote:
> > > Hi Ben,
> > >
> > > We looked a bit closer at this problem, and turns out the packet header
> > > size we were getting back from Ryu wasn't what we were expecting. We're
> > now
> > > calculating this correctly ourselves (instead of relying on Ryu) which
> > > removes the need for disabling the IP header length check in the tutorial
> > > (I've send another patch towards d...@openvswitch.org that does this).
> > >
> > > As for being able to inject payload into ofproto/trace generated packets
> > I
> > > think this would be quite useful for folks like us. We are looking at
> > > moving our test suite to using ofproto/trace to generate packets (instead
> > > of scapy) for throwing at test scenarios because it's considerably more
> > > lightweight and we are already using openvswitch as the core of our test
> > > suite.
> > >
> > > Brad
> > >
> > > On 9 January 2018 at 05:51, Ben Pfaff  wrote:
> > >
> > > > [dropping OP, who probably doesn't care]
> > > >
> > > > On Sat, Jan 06, 2018 at 12:07:09PM +1300, Brad Cowie wrote:
> > > > > What happened is that in faucet 1.6.12 we added a bunch of new packet
> > > > > handling sanity checks to help improve security of faucet's packet
> > > > > handling. Packets made by ofproto/trace -generate will have a
> > zero-length
> > > > > payload which trips some of our sanity checks which will cause us to
> > drop
> > > > > the packet.
> > > >
> > > > If OVS generated a packet with some nonzero size payload, would that
> > fix
> > > > the problem?  It's easy for us to change the details, we would just add
> > > > some code to flow_compose_l4() in lib/flow.c to put some L7 data into
> > > > the UDP packet.
> > > >
> > > > I suspect that changing the tutorial from using UDP to TCP might also
> > > > work around the issue?  After all, TCP packets with empty payloads are
> > > > pretty common, at least (off the top of my head) if they have SYN or
> > FIN
> > > > or RST attached.
> > > >
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Block outgoing packets on a specific port

[Ajit Warrier]

Our OVS runs a broadcast app that sends UDP packets out on br0. Currently
as expected, these packets go out of all interfaces in br0. I would like to
force it such that these packets do NOT go out of a specific interface, but
still goes out of the other interfaces.

I tried using open flow as below:

/tmp/ovs-ofctl add-flow br0
dl_type=0x800,nw_proto=17,tp_dst=699,actions=drop

What I am missing is a way to specify the egress port. Is this possible ?

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

Re: [ovs-discuss] unexpected behavior in ovs faucet tutorial

[Brad Cowie]

Hi Du,

Did you build your OpenvSwitch version 2.8.90 source? If so what git commit
are you using?

I just tried to replicate your problem with OVS 2.8.2 from git (commit
27dbf5d394) and that step of the tutorial works fine for me.

Perhaps you could send me the contents of your faucet.log and I can analyse
it for any issues that occurred.

Also note that "minimum_ip_size_check" is no longer required in faucet
1.6.16, I have update the tutorial text to reflect this.

Thanks,
Brad

On 16 January 2018 at 20:54, Hongwei Du  wrote:

> Hi, Lee
>
> Thanks for your advice. I tried to use faucet 1.6.16 and modify
> faucet.yaml to be like this
>
> dps:
> switch-1:
> dp_id: 0x1
> timeout: 3600
> arp_neighbor_timeout: 3600
> interfaces:
> 1:
> native_vlan: 100
> 2:
> native_vlan: 100
> 3:
> native_vlan: 100
> 4:
> native_vlan: 200
> 5:
> native_vlan: 200
> vlans:
> 100:
> minimum_ip_size_check: False
> 200:
> minimum_ip_size_check: False
>
> After clean-up and re-entering ovs sandbox and restarting faucet, I
> still cannot get anything in diff-flows.
>
>
> On Tue, Jan 16, 2018 at 3:19 PM, Robin Lee 
> wrote:
> >
> >
> > On Tue, Jan 16, 2018 at 3:04 PM, Hongwei Du  wrote:
> >>
> >> Hi,
> >>
> >> I'm following the ovs faucet tutorial to get familiar with
> >> openvswitch. Everything goes smoothly until section Triggering MAC
> >> Learning.
> >>
> >> I tried the ovs-appctl ofproto/trace ... ... -generate command, but no
> >> new logs showed in inst/faucet.log, and diff-flows also gives nothing.
> >>
> >> I'm using ovs 2.8.90, can anybody help me troubleshooting this?
> >> ___
> >> discuss mailing list
> >> disc...@openvswitch.org
> >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> >
> > Hi, Du
> >
> > This issue was just discussed in a recent talk[1].
> > Basically you should upgrade faucet to 1.6.15, and modify faucet.yaml
> with
> > respect
> > to the updated tutorial text[2].
> >
> > [1]
> > https://mail.openvswitch.org/pipermail/ovs-discuss/2018-
> January/045957.html
> > [2] http://docs.openvswitch.org/en/latest/tutorials/faucet/
> >
> > -robin
> ___
> 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

Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Vishal Deep Ajmera]

> OK, what about this patch instead? It should fix the issue without the
> errors.  I have not tested.

I tried your patch but it does not re-add the routes. The reason is doing
$ ifup br0 will not invoke ifup-post since the bridge port is already UP and so 
$OVSBRIDGECONFIGURED will be 'true'.

I think instead of doing 'ifup $OVS_BRIDGE', we should run ${OTHERSCRIPT} 
$OVS_BRIDGE 
under the mac check. Tried this and it is working.

Updated patch below.

+   BRIDGE_MAC_ORIG=$(get_hwaddr $OVS_BRIDGE)
ovs-vsctl -t ${TIMEOUT} \
-- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \
-- add-port "$OVS_BRIDGE" "$DEVICE" $OVS_OPTIONS \
-- set Interface "$DEVICE" type=dpdk ${OVS_EXTRA+-- 
$OVS_EXTRA}
+   BRIDGE_MAC=$(get_hwaddr $OVS_BRIDGE)
+   # The bridge will change its MAC to be the lower one among all 
its
+   # ports. Restore the configuration if that happens.
+   if [ "$BRIDGE_MAC_ORIG" != "$BRIDGE_MAC" ]; then
+   ${OTHERSCRIPT} "$OVS_BRIDGE"
+   fi

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

[ovs-discuss] Linking of OFPROTO and NETDEV libraries to OVS

[Aravind Prasad]

Hi All,

Is there a way to link OFPROTO and NETDEV libraries directly to OVS binary
without recompiling the OVS codebase. Like, downloading the OVS debian
binary directly and link the ofproto and netdev dynamic libraries to it.

Afaik, currently, we need to compile the OVS code with ofproto and netdev
libraries manually. And if thats the way, is supporting multiple datapath
elements the possible reason to mandate the recompilation of OVS codebase
with the libraries. Just curious to know :).

Thanks in advance for the info and support.

Thanks,
S. Aravind Prasad
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Flavio Leitner]

On Thu, Jan 18, 2018 at 10:12:40AM +, Vishal Deep Ajmera wrote:
> > BTW, I suggested earlier but maybe I wasn't clear.
> > 
> > Instead of adding networking configuration to the bridge's port, just
> > leave it alone with a name that doesn't bother you.
> > 
> > Then create an internal port with the name and the networking
> > configuration you need. It won't change its MAC and neither lose
> > the routes. They both will be tap devices anyways.
> 
> Issue with assigning IP and routes to a tap port is that this tap port gets
> a random mac address which cannot be guaranteed to be unique
> across multiple nodes. I think that is the reason why bridge is assigned
> same mac address of a physical port (when port is added to a bridge) since 
> physical ports will have unique mac address.

You could use MACADDR= in ifcfg to have a stable MAC if that's only
issue, but yeah, you would have to manage them.

-- 
Flavio

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

[ovs-discuss] vPort state

[Nitin Katiyar]

Hi,
Can someone help in understanding the reason for not allowing the vport state 
to DOWN.  Presently, if we try to bring down tunnel ports (or vPorts) using 
"ovs-ofctl mod-port" command then OVS rejects it as "not supported".

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

Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Flavio Leitner]

On Thu, Jan 18, 2018 at 08:32:03AM +, Vishal Deep Ajmera wrote:
> > OK, what about this patch instead? It should fix the issue without the
> > errors.  I have not tested.
> 
> I tried your patch but it does not re-add the routes. The reason is doing
> $ ifup br0 will not invoke ifup-post since the bridge port is already UP and 
> so 
> $OVSBRIDGECONFIGURED will be 'true'.

Yes, yes, I forgot that when I looked at the DHCP scenario which will
not work in this case then.
> 
> I think instead of doing 'ifup $OVS_BRIDGE', we should run ${OTHERSCRIPT} 
> $OVS_BRIDGE 
> under the mac check. Tried this and it is working.

It looks good to me. I hope it does work for any number of ports
and doesn't show any errors.  If that's the case, please submit a
formal patch to ovs-dev@ and don't forget to request to patch 2.9
(if you need that) as it's branched off at this point.

Thanks for working on this!
fbl

> 
> Updated patch below.
> 
> + BRIDGE_MAC_ORIG=$(get_hwaddr $OVS_BRIDGE)
>   ovs-vsctl -t ${TIMEOUT} \
>   -- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \
>   -- add-port "$OVS_BRIDGE" "$DEVICE" $OVS_OPTIONS \
>   -- set Interface "$DEVICE" type=dpdk ${OVS_EXTRA+-- 
> $OVS_EXTRA}
> + BRIDGE_MAC=$(get_hwaddr $OVS_BRIDGE)
> + # The bridge will change its MAC to be the lower one among all 
> its
> + # ports. Restore the configuration if that happens.
> + if [ "$BRIDGE_MAC_ORIG" != "$BRIDGE_MAC" ]; then
> + ${OTHERSCRIPT} "$OVS_BRIDGE"
> + fi




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

Re: [ovs-discuss] Block outgoing packets on a specific port

[Justin Pettit]

> On Jan 18, 2018, at 3:27 PM, Ajit Warrier  wrote:
> 
> Our OVS runs a broadcast app that sends UDP packets out on br0. Currently as 
> expected, these packets go out of all interfaces in br0. I would like to 
> force it such that these packets do NOT go out of a specific interface, but 
> still goes out of the other interfaces.
> 
> I tried using open flow as below:
> 
> /tmp/ovs-ofctl add-flow br0 dl_type=0x800,nw_proto=17,tp_dst=699,actions=drop
> 
> What I am missing is a way to specify the egress port. Is this possible ?

The only thing that comes to mind is to enumerate the ports it should go to, 
and then it will be implicitly dropped to that port.

--Justin


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

Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Vishal Deep Ajmera]

> BTW, I suggested earlier but maybe I wasn't clear.
> 
> Instead of adding networking configuration to the bridge's port, just
> leave it alone with a name that doesn't bother you.
> 
> Then create an internal port with the name and the networking
> configuration you need. It won't change its MAC and neither lose
> the routes. They both will be tap devices anyways.

Issue with assigning IP and routes to a tap port is that this tap port gets
a random mac address which cannot be guaranteed to be unique
across multiple nodes. I think that is the reason why bridge is assigned
same mac address of a physical port (when port is added to a bridge) since 
physical ports will have unique mac address.

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