Monday, January 25, 2010

Open vSwitch

(diagram from Open vSwitch)

The Open vSwitch provides advanced switching capabilities for virtual servers. Currently the Open vSwitch supports Linux, Xen/XenServer, KVM and Virtual Box. The open source software is designed to be easily portable and is expected to support additional platforms in the future. The Open vSwitch is designed to integrate switching across multiple physical servers, providing an open source alternative to proprietary virtual switches such as VMWare's distributed switch and Cisco's Nexus 1000v.

The recent integration of sFlow traffic monitoring in the Open vSwitch extends the visibility into virtual servers, ensuring data center visibility and control.

Note: The Open vSwitch demonstrates how to integrate the reference sFlow agent code with a virtual switch or network adapter. Integrating sFlow requires minimal support in the "fast path" requiring only packet sampling and packet counters.

The following lines, added to the Open vSwitch configuration file (ovs-vswitchd.conf), configure sampling packets at 1-in-512, polling counters every 20 seconds and sending sFlow to an analyzer (10.0.0.50) over UDP using the default sFlow port (6343):

sflow.<bridgename>.agent    = eth0
sflow.<bridgename>.host     = 10.0.0.50:6343
sflow.<bridgename>.sampling = 512
sflow.<bridgename>.polling  = 20
sflow.<bridgename>.header   = 128

Note: Type "man ovs-vswitchd.conf" for a full list of configuration options. A previous posting discussed the selection of sampling rates.

The following screen capture, from the free sFlowTrend application, demonstrates the visibility provided by sFlow in the Open vSwitch:


All traffic is visible, traffic between virtual machines, and from the virtual machines to the outside world. In addition, sFlow is able to report on all the protocols on the network (note the layer 2, TCP and IPv6 flows in the chart), as well as information on VLANs and layer 2 priorities that is essential for managing switched traffic.

The second screen capture shows a bandwidth trend for a virtual adapter on the vSwitch:


This type of interface trending is a staple of network management, but obtaining the information is challenging in virtual environments. While SNMP is typically used to obtain this information from network equipment, servers are much less likely to be managed using SNMP and so SNMP polling is often not an option. In addition, there may be large numbers of virtual ports associated with each physical switch port. In a virtual environment with 10,000 physical switch ports you might need to monitor as many as 200,000 virtual ports. Even if SNMP agents were installed on all the servers, SNMP polling does not scale well to large numbers of interfaces. The integrated counter polling mechanism built into sFlow provides scalable monitoring of the utilization of every switch port in the network, both physical and virtual, quickly identifying problems wherever they may occur in the network.

Download Open vSwitch and sFlowTrend to evaluate the benefits of visibility in the virtualization layer.

Finally, the Open vSwitch also supports the OpenFlow to allow centralized control of switch forwarding. The combination of sFlow and OpenFlow in the vSwitches delivers visibility and control of the network edge.

Feb. 15, 2011 Update: The configuration steps shown in this article are no longer correct, more recent versions of the Open vSwitch use the ovs-vsctl command instead. The easiest way to manage the sFlow configuration of an Open vSwitch is to install the open source Host sFlow agent which will automatically manage sFlow settings in the Open vSwitch. For recent information on the Open vSwitch, click on the vSwitch label below.

15 comments:

  1. Hi,i use this configuration:
    i have ovs(192.168.100.2) installed in my openstack controller (192.168.100.246).
    i have sflow trend installed in monitoring host (192.168.100.110)
    2 vms are running with vnet interface.
    sflow..agent = eth0
    sflow..host = 192.168.100.110:6343
    in sflow trend i configure switch with 192.168.100.2 address
    but, this configuration doesn't work, sflow trend doesn't detect any thing.
    there is something wrong with all this?

    ReplyDelete
  2. You also need to enable sFlow on each bridge in OVS and set sampling and polling rates.

    See:
    http://openvswitch.org/?page_id=215

    The easiest way to configure sFlow is to install the Host sFlow agent:

    http://host-sflow.sourceforge.net

    The Host sFlow agent will automatically configure sFlow on the Open vSwitch. It will also export CPU/memory/disk counters from all the virtual machines that will be displayed in sFlowTrend along with the network data from the vSwitch.

    ReplyDelete
  3. I use only one ovs switch, how can i enabling sflow in ovs.
    in my configuration, i set sampling and polling rate.
    i think my problem is that when i execute "tcpdump -ni eth1 udp port 6343", no traffic is being sent.
    I apply this configuration
    COLLECTOR_IP=192.168.100.110
    COLLECTOR_PORT=6343
    AGENT_IP=eth0
    HEADER_BYTES=128
    SAMPLING_N=64
    POLLING_SECS=10
    then
    ovs-vsctl -- --id=@sflow create sflow agent=eth0 target=\"${COLLECTOR_IP}:${COLLECTOR_PORT}\" header=${HEADER_BYTES} sampling=64 polling=10 -- set bridge br0 sflow=@sflow

    there is a problem with the configuration of OVS?

    ReplyDelete
  4. If you ping 192.168.100.110 from the OVS box, does it succeed? Are you sure that the 192.168.100.110 is on eth1? The packets could be going out eth0.

    What output do you get when you list the sFlow configuration?
    ovs-vsctl list sflow
    ovs-vsctl list bridge br0

    Are you sure that br0 is correct? On xenserver/xcp it would be xenbr0.

    sFlow needs to be enabled on every bridge listed by "ovs-vsctl list bridge" to ensure all traffic is monitored. The Host sFlow agent automatically maintains the Open vSwitch sFlow settings for you, updating the configuration as bridges are added and removed.

    ReplyDelete
  5. ping 192.168.100.110 from host where ovs is installed (192.168.100.246 = eth0 ip address), succeed.
    ovs-vsctl list sflow shows me the configuration of sflow and br0 exists and is listed!

    ReplyDelete
  6. This comment has been removed by the author.

    ReplyDelete
  7. Are there any firewalls between the OVS box and sFlowTrend that would block UDP port 6343 traffic from OVS? The iptables on either box could be blocking the traffic.

    ReplyDelete
  8. The sFlow agent address has been set to eth0, so sFlowTrend should see sFlow arriving from an sFlow agent with IP address = 192.168.100.110 (eth0)

    ReplyDelete
  9. i disable firewall and open udp port 6343 in sFlow Trend host.

    ReplyDelete
  10. ovs-vsctl list sflow
    _uuid : eb7becee-7436-41e6-8467-abee3dd28a32
    agent : "eth0"
    external_ids : {}
    header : 128
    polling : 10
    sampling : 64
    targets : ["192.168.100.110:6343"]

    ovs-vsctl list-br
    br0

    tcpdump -ni eth0 udp port 6343 dosen't show any traffic

    ReplyDelete
  11. What does the command "ovs-vsctl list bridge" show?
    What is the output of ifconfig?

    If there are no ports defined on for br0 then you won't expect to see any sFow data.

    ReplyDelete
  12. ovs-vsctl list bridge shows only br0.
    vnet (virtual interface of vm) are attached to br0.
    ifconfig show br0 with ip address (192.168.100.2)
    i use br0 as an openstack bridge, and i don't know if i have to apply more rules in iptables or some thing else to permit udp:6343 traffic?

    ReplyDelete
    Replies
    1. Tries to use the loopback as collector, I had problems to configure the collector in a vlan. I solved it using loopback and iptables rule.

      For example:

      COLLECTOR_IP=127.0.0.1
      COLLECTOR_PORT=9990
      AGENT_IP=lo

      ----
      Test:

      tcpdump -ni lo udp port 6343

      Delete
  13. Is there any analyzer like nfdump -r ( for netflow) for Sflow to view the data at command line

    ReplyDelete