Open Stack

On 08/20/2012 03:59 PM, Dan Wendlandt wrote:
> On Mon, Aug 20, 2012 at 12:49 PM, Chris Wright <chrisw at sous-sol.org> wrote:
>> * Chris Wright (chrisw at redhat.com) wrote:
>>> * Dan Wendlandt (dan at nicira.com) wrote:
>>>> basically, we're creating a patch port between br-int and br-tun in this
>>>> example.  In your case, you'd want to create a brX for each ethX, and then
>>>> attach ethX to brX.  The easiest thing to do would probably be that for a
>>>> mapping of a local vlan A to a global vlan M on ethX, create a patch port
>>>> from br-int to brX, and put the br-int port of the patch as an access port
>>>> on VLAN A, and put the brX side port as an access port on VLAN M (note,
>>>> putting a port as an access port in OVS just means setting the 'tag'
>>>> property on the Port, see:
>>>> https://github.com/openstack/quantum/blob/master/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py#L126
>>>> )
>>>>
>>>> veths would be very similar, just using a different library call to create
>>>> the pair of devices.  quantum.agent.linux.ip_lib has an add_veth() method
>>>> that let's you do this.
>>>
>>> Should be functionally equivalent to something like:
>>>
>>> ip link add name int-to-tun type veth peer name tun-to-int
>>> ovs-vsctl add-port br-int int-to-tun
>>> ovs-vsctl add-port br-tun tun-to-int
>>>
>>> to connect the two.
>>
>>
>>      eth0              VM0.....N              eth1
>>  +-----|-----+        +-|-|-|-|-|-+       +-----|-----+
>>  | ovs phys0 |        | ovs int   |       | ovs phys1 |
>>  +-----|-----+        +-|-------|-+       +-----|-----+
>>        +-veth0i--vethi0-+       +-vethi1--veth1i+
>>
>>
>> Just drew this to share with Bob to make sure we had the same mental picture.
> 
> Yes, that is correct.  I could imagine two possible models inline with
> what you drew:
> 
> 1) each 'phys0' only ever has at most one veth connection to 'int'.
> Thus, the veth ports would be trunks, carrying multiple VLANs.  OVS
> flows map from internal to external vlans.
> 
> 2) each 'phys0' has a separate veth for each external vlan.  veth
> ports are then just basic access ports, with the veth on 'int' having
> tag=X where X is the local vlan, and the paired veth on 'phys0' being
> tag=Y, where Y is the external VLAN.
> 
> I think #2 is probably easier to implement and reason about, though it
> ends up consuming more devices on the linux host.

I've been planning to implement #1, using flow entries to manipulate the
vlan_ids as packets travel over the veth into and out of the physical
network bridges. This seems straightforward. Am I missing something?

The inbound flow from the physical network bridge to the integration
bridge will match on the physical network vlan_id and then set the
vlan_id to the local_id used for the network on the integration bridge.

The outbound flow from the integration bridge to the physical network
bridge will match on the VM's port (or the local_id?) and then set the
vlan_id to the physical network vlan_id.

Does the above make sense? Note that local_id refers to the local
vlan_id assigned on the integration bridge.

I see the tunnel bridge outbound flow currently matches on in-port. Why
do that instead of matching on the local_id?

-Bob

> 
> dan
> 
>>
>> thanks,
>> -chris
> 
> 
>