[ovs-dev] [PATCH v5 5/6] ovn: Add "localnet" logical port type.

Ben Pfaff blp at nicira.com
Sat Aug 1 04:44:17 UTC 2015


On Fri, Jul 31, 2015 at 10:19:32PM -0400, Russell Bryant wrote:
> On 07/31/2015 07:26 PM, Ben Pfaff wrote:
> > I'm not sure I correctly understand the model for using these.  Maybe
> > you can flesh out an example to help me.  Suppose I have a pair of
> > hypervisors A and B, and each HV has two VMs (A1 and A2, B1 and B2), and
> > all four of the VMs are connected to the same Neutron provider network.
> > How many OVN Logical_Switches would I have and what would their
> > membership look like?  On each HV, what interfaces would be attached to
> > br-int?
> 
> That scenario is really close to what I describe in the overview mail,
> except I only had 1 VM per hypervisor.
> 
> http://openvswitch.org/pipermail/dev/2015-July/058367.html
> 
> A simulation of your scenario would be (with ovs-sandbox):
> 
> > ovs-vsctl add-br br-eth1
> > ovs-vsctl set open .  external-ids:ovn-bridge-mappings=physnet1:br-eth1
> > 
> > for n in 1 2 3 4; do 
> >     ovn-nbctl lswitch-add provnet1-$n
> > 
> >     ovn-nbctl lport-add provnet1-$n provnet1-$n-port1
> >     ovn-nbctl lport-set-macs provnet1-$n-port1 00:00:00:00:00:0$n
> >     ovn-nbctl lport-set-port-security provnet1-$n-port1 00:00:00:00:00:0$n
> > 
> >     ovn-nbctl lport-add provnet1-$n provnet1-$n-physnet1
> >     ovn-nbctl lport-set-macs provnet1-$n-physnet1 unknown
> >     ovn-nbctl lport-set-type provnet1-$n-physnet1 localnet
> >     ovn-nbctl lport-set-options provnet1-$n-physnet1 network_name=physnet1
> > done
> > 
> 
> The above gets us the following logical config:
> 
> $ ovn-nbctl show
>     lswitch 457a1810-b3c5-40f9-835e-4f86a65bb60d (provnet1-3)
>         lport provnet1-3-port1
>             macs: 00:00:00:00:00:03
>         lport provnet1-3-physnet1
>             macs: unknown
>     lswitch 40afcc6e-464e-44db-bb57-0f13da299cbd (provnet1-2)
>         lport provnet1-2-port1
>             macs: 00:00:00:00:00:02
>         lport provnet1-2-physnet1
>             macs: unknown
>     lswitch b603dff3-cd7c-4d82-be19-1bfe2a4f5897 (provnet1-4)
>         lport provnet1-4-physnet1
>             macs: unknown
>         lport provnet1-4-port1
>             macs: 00:00:00:00:00:04
>     lswitch 0bd64e33-90f7-4d19-b2c2-2e39ba7b3317 (provnet1-1)
>         lport provnet1-1-physnet1
>             macs: unknown
>         lport provnet1-1-port1
>             macs: 00:00:00:00:00:01
> 
> The output doesn't show it, but the "physnet" ports are type=localnet.
> 
> Now we can bind the first 2 ports locally.  For the second two ports, we
> can create a fake chassis and update the DB to reflect that the ports
> are bound to the fake chassis.
> 
> > ovs-vsctl add-port br-int lport1 -- set Interface lport1 external_ids:iface-id=provnet1-1-port1
> > ovs-vsctl add-port br-int lport2 -- set Interface lport1 external_ids:iface-id=provnet1-2-port1
> > 
> > # Create a fake chassis
> > encaps_uuid=$(ovsdb-client dump OVN_Southbound | grep -A 3 Encap | tail -n 1 | awk '{print $1}')
> > chassis=$(ovsdb-client transact '["OVN_Southbound",{"op":"insert","table":"Chassis","row":{"name":"fakechassis","encaps":["uuid","'$encaps_uuid'"]}}]')
> > chassis_uuid=$(echo $chassis | sed -e 's/^.*\"uuid\",\"\(.*\)\".*/\1/')
> > uuid=$(ovsdb-client dump OVN_Southbound | grep -A 10 Binding | grep provnet1-3-port1 | awk '{print $1}')
> > ovsdb-client transact '["OVN_Southbound",{"op":"update","table":"Binding","where":[["_uuid","==",["uuid","'$uuid'"]]],"row":{"chassis":["uuid","'$chassis_uuid'"]}}]'
> > uuid=$(ovsdb-client dump OVN_Southbound | grep -A 10 Binding | grep provnet1-4-port1 | awk '{print $1}')
> > ovsdb-client transact '["OVN_Southbound",{"op":"update","table":"Binding","where":[["_uuid","==",["uuid","'$uuid'"]]],"row":{"chassis":["uuid","'$chassis_uuid'"]}}]'
> 
> Does that make sense?

Yes.

Sorry, I forgot that there was a detailed example earlier.  I didn't
mean to make you go to a lot of work to repeat it.

I am slightly concerned about having a pair of patch ports per provider
network port (that is what the above implies, right?), but let's go
ahead and try that and if it's a problem we can figure out an
optimization.

Thanks,

Ben.



More information about the dev mailing list