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

[Russell Bryant]

On 08/01/2015 12:44 AM, Ben Pfaff wrote:
> 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.

No problem.  I copied it for the most part.  :-)

As you suggested, I'll incorporate it into the commit message, as well.

> 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.

No, the repetition is only in the logical space.  There's only a single
pair of patch ports per provider network.  In the above example, the
input flow looks like this:

 cookie=0x0, duration=338.834s, table=0, n_packets=0, n_bytes=0,
priority=100,in_port=1
actions=set_field:0x1->reg5,set_field:0x2->metadata,set_field:0x4->reg6,resubmit(,16),set_field:0x3->metadata,set_field:0x6->reg6,resubmit(,16),set_field:0x1->metadata,set_field:0x2->reg6,resubmit(,16),set_field:0x4->metadata,set_field:0x8->reg6,resubmit(,16)

This seemed like a good stopping point to make sure I had everything
right (I didn't ;-) ).  I still need to add VLAN support, which I was
thinking would result in 1 patch port per VLAN.  So, there could be a
lot more in that case.  I suppose I could try to do it all with flows,
instead?

-- 
Russell Bryant