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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
