[ovs-dev] [PATCH] ovs-vtep: Clarifications on the README

Gurucharan Shetty shettyg at nicira.com
Thu Aug 14 20:57:49 UTC 2014


On Thu, Aug 14, 2014 at 12:03 PM, Mark Maglana <mmaglana at gmail.com> wrote:
> The README was not clear on whether the steps are for attaching physical
> or virtual machines to the emulated VTEP. This adds more detail to the
> README so that readers will know what to do if they want to attach physical
> machines or otherwise.
>
> Signed-off-by: Mark Maglana <mmaglana at gmail.com>
Thank you for the contribution. I have a few comments.
> ---
>  vtep/README.ovs-vtep | 103 +++++++++++++++++++++++++++++++++++++++++----------
>  1 file changed, 83 insertions(+), 20 deletions(-)
>
> diff --git a/vtep/README.ovs-vtep b/vtep/README.ovs-vtep
> index 79e1538..4f51ee4 100644
> --- a/vtep/README.ovs-vtep
> +++ b/vtep/README.ovs-vtep
> @@ -6,6 +6,73 @@ Open vSwitch for forwarding.  The emulator is a Python script that
>  invokes calls to vtep-ctl and various OVS commands, so these commands
>  will need to be available in the emulator's path.
>
> +Requirements
> +============
> +
> +1. Open vSwitch.
The above is a little vague. "Open vSwitch" does include VTEP in its
code repository.
I added some details here. I will send it in an updated patch. Have a
look-over and tell me what you think.

> +
> +2. The vtep-ctl CLI tool. If you built OVS from source, there should
> +   be a VTEP package that was also built with it. Otherwise, use your
> +   distro's package manager to find an install it.
> +
> +Design
> +======
> +
> +At the end of this process, you should have the following setup:
> +
> +
> +      +---------------------------------------------------+
> +      | Host Machine                                      |
> +      |                                                   |
> +      |                                                   |
> +      |       +---------+ +---------+                     |
> +      |       |         | |         |                     |
> +      |       |   VM1   | |   VM2   |                     |
> +      |       |         | |         |                     |
> +      |       +----o----+ +----o----+                     |
> +      |            |           |                          |
> +      | br0 +------o-----------o--------------------o--+  |
> +      |            p0          p1                  br0    |
> +      |                                                   |
> +      |                                                   |
> +      |                              +------+   +------+  |
> +      +------------------------------| eth0 |---| eth1 |--+
> +                                     +------+   +------+
> +                                     10.1.1.1   10.2.2.1
> +                        MANAGEMENT      |          |
> +                      +-----------------o----+     |
> +                                                   |
> +                                   DATA/TUNNEL     |
> +                                 +-----------------o---+
> +
> +Notes:
> +
> +1. We will use Open vSwitch to create our "physical" switch labeled br0
> +
> +2. Our "physical" switch br0 will have one internal port also named br0
> +   and two "physical" ports, namely p0 and p1.
> +
> +3. The host machine must have two external interfaces. We will use eth0
> +   for management traffic and eth1 for tunnel traffic. Please take note
> +   of their IP addresses in the diagram. You do not have to use exactly
> +   the same IP addresses. Just know that the above will be used in the
> +   steps below.
It is not a "must" to have two physical interfaces. One can have both mgmt and
tunnel using the same interface.
> +
> +4. You can optionally connect physical machines instead of virtual
> +   machines to switch br0. In that case:
> +
> +   4.1. Make sure you have two extra physical interfaces in your host
> +        machine, eth2 and eth3.
> +
> +   4.2. In the rest of this doc, replace p0 with eth2 and p1 with eth3.
> +
> +5. In addition to implementing p0 and p1 as physical interfaces, you can
> +   also optionally implement them as standalone TAP devices, or VM
> +   interfaces for simulation.
> +
> +6. Creating and attaching the VMs is outside the scope of this document
> +   and is included in the diagram for reference purposes only.
> +
>  Startup
>  =======
>
> @@ -28,37 +95,33 @@ instance that handles both the OVS and VTEP schema.
>      ovs-vswitchd --log-file --detach --pidfile \
>        unix:/var/run/openvswitch/db.sock
>
> -4. Create a "physical" switch in OVS:
> +4. Create a "physical" switch and its ports in OVS:
>
>      ovs-vsctl add-br br0
> -    ovs-vsctl add-port br0 eth0
> +    ovs-vsctl add-port br0 p0
> +    ovs-vsctl add-port br0 p1
>
>  5. Configure the physical switch in the VTEP database:
>
>      vtep-ctl add-ps br0
> -    vtep-ctl add-port br0 eth0
> -    vtep-ctl set Physical_Switch br0 tunnel_ips=192.168.0.3
> +    vtep-ctl set Physical_Switch br0 tunnel_ips=10.2.2.1
>
> -6. Start the VTEP emulator:
> +6. Start the VTEP emulator. Run the following from the same directory
> +   as this README:
>
> -    ovs-vtep --log-file=/var/log/openvswitch/ovs-vtep.log \
> +    ./ovs-vtep --log-file=/var/log/openvswitch/ovs-vtep.log \
>        --pidfile=/var/run/openvswitch/ovs-vtep.pid \
>        --detach br0
>
> -7. Configure the VTEP database's manager to point at a NVC:
> -
> -    vtep-ctl set-manager tcp:192.168.0.99:6632
> -
> -The example provided creates a physical switch with a single physical
> -port attached to it.  If more than one physical port is needed, it would
> -be added to "br0" to both the OVS and VTEP databases:
> +7. Configure the VTEP database's manager to point at an NVC:
>
> -    ovs-vsctl add-port br0 eth1
> -    vtep-ctl add-port br0 eth1
> +    vtep-ctl set-manager tcp:<CONTROLLER IP>:6632
>
> +   Where CONTROLLER IP is your controller's IP address that is accessible
> +   via the Host Machine's eth0 interface.
>
> -Simulating a NVC
> -================
> +Simulating an NVC
> +=================
>
>  A VTEP implementation expects to be driven by a Network Virtualization
>  Controller (NVC), such as NSX.  If one does not exist, it's possible to
> @@ -70,13 +133,13 @@ use vtep-ctl to simulate one:
>
>  2. Bind the logical switch to a port:
>
> -    vtep-ctl bind-ls br0 eth0 0 ls0
> +    vtep-ctl bind-ls br0 p0 0 ls0
>      vtep-ctl set Logical_Switch ls0 tunnel_key=33
>
>  3. Direct unknown destinations out a tunnel:
>
> -    vtep-ctl add-mcast-remote ls0 unknown-dst 192.168.1.34
> +    vtep-ctl add-mcast-remote ls0 unknown-dst 10.2.2.2
>
>  4. Direct unicast destinations out a different tunnel:
>
> -    vtep-ctl add-ucast-remote ls0 11:22:33:44:55:66 192.168.1.33
> +    vtep-ctl add-ucast-remote ls0 11:22:33:44:55:66 10.2.2.3
> --
> 2.0.3
>
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev



More information about the dev mailing list