On Thu, Aug 14, 2014 at 12:03 PM, Mark Maglana <mmagl...@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 <mmagl...@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@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
