Wednesday, 1 October 2014

Best Practices for Determining the Traffic Matrix in IP Networks

 
• Internal Traffic Matrix
   – PoP to PoP matrix
      • Can be from core (CR) or access (AR) routers
   – Class based
• External Traffic Matrix
    – PoP to External AS
          • BGP
          • Origin-AS or Peer-AS
                 – Peer-AS sufficient for Capacity Planning and Resilience Analysis
           • Useful for analyzing the impact of external failures on the core network (capacity/resilience)
• Example Data from Tier-1 IP Backbone
   – Measured Traffic Matrix (MPLS TE based)
   – European and American subnetworks
   – 24h data
• Properties
   – Temporal Distribution
       • How does the traffic vary over time
   – Spatial Distribution
       • How is traffic distributed in the network?
   – Relative Traffic Distribution
       • “Fanout”
Traffic Collection:
• Data is collected at fixed intervals
    – E.g. every 5 or 15 minutes
• Measurement of Byte Counters
    – Need to convert to rates
    – Based on measurement interval
• Create Traffic Matrix
   – Peak Hour Matrix
      • 5 or 15 min. average at the peak hour
   – Peak Matrix
      • Calculate the peak for every demand
      • Real peak or 95-percentile
Collection Methods:
• NetFlow
     – Routers collect “flow” information
    – Export of raw or aggregated data
• DCU
    – Routers collect aggregated destination statistics
•  MPLS
    – LDP
          • Measurement of LDP counters
     – RSVP
          • Measurement of Tunnel/LSP counters
• Estimation
     – Estimate Traffic Matrix based on Link Utilizations
Reference: http://www.ltcm.net/~telkamp/papers/p149-gunnar.pdf
 
 

Monday, 16 June 2014

Python API with Mininet on Ubuntu: Setting up a home Lab

Setting up SDN home lab with Mininet

Mininet creates a realistic virtual network, running real kernel, switch and application code, on a single machine (VM, cloud or native), in seconds, with a single command:

Figure 1: Mininet Virtual Environment

The Mininet CLI (and API) allos one to easily interact with the network, customize it, share it with others, or deploy it on real hardware. Hence, Mininet is useful for development, teaching, and research. Mininet is also a great way to develop, share, and experiment with OpenFlow and Software-Defined Networking systems. Mininet is actively developed and supported, and is released under a permissive BSD Open Source license.

1.      Downloading/Getting Started With Mininet

The easiest way to get started is to download a pre-packaged Mininet/Ubuntu VM. This VM includes Mininet itself, all OpenFlow binaries and tools pre-installed, and tweaks to the kernel configuration to support larger Mininet networks.

Option1: Mininet VM Installation (easy way out)

a.       Recommended is installation of the following Mininet VM image: https://d19vezwu8eufl6.cloudfront.net/sdn/srcs/pyretic_0.2.0.ova (64 bit image) https://d19vezwu8eufl6.cloudfront.net/sdn/srcs/pyretic_0.2.0_32bit.ova (32 bit image)


It comes pre-installed with the latest version of Mininet a.ka. HiFi and two OpenFlow Controllers (POX and Pyretic). The download will take some time. It’s ~ 800MB, compressed.

 

b.      Download Virtualization System:

Any virtualization system should work, but recommended is Oracle’s VirtualBox. It’s free and runs on Windows, Linux and OS X:

VirtualBox (Recommended): https://www.virtualbox.org/wiki/Downloads . Also supported are Qemu for any platform, VMware Workstation for Windows or Linux, VMware Fusion for Mac, or KVM (free, GPL) for Linux.

c.       Download X Server and SSH capable terminal:

 

For Windows install Xming and Putty.

For MAC OS install XQuartz and Terminal.app (builtin)

Linux comes pre-installed with X server and Gnome terminal + SSH (buitlin)

 

Option 2: Native Installation from Source

This option works well for local VM, remote EC2, and native installation. It assumes the starting point of a fresh Ubuntu (or, experimentally, Fedora) installation. (If you are upgrading from an older Mininet and/or OVS, see notes on removing old versions, below.)

 

Strongly recommended are more recent Ubuntu releases, because they support newer versions of Open vSwitch. (Fedora also supports recent OVS releases)

 

To install natively from source, first you need to get the source code:

 

git clone git://github.com/mininet/mininet
 

Note that the above git command will check out the latest and greatest Mininet (which is recommended) If you want to run the last tagged/released version of Mininet, use:

 

git clone git://github.com/mininet/mininet
git checkout -b 2.1.0p1 2.1.0p1
 

Once you have the source tree, the command to install Mininet is:

 

mininet/util/install.sh [options]

Typical install.sh options include:

·         -a: install everything that is included in the Mininet VM, including dependencies like Open vSwitch as well the additions like the OpenFlow wireshark dissector and POX. By default these tools will be built in directories created in your home directory.

·         -nfv: install Mininet, the OpenFlow reference switch, and Open vSwitch

·         -s mydir: use this option before other options to place source/build trees in a specified directory rather than in your home directory.

So, you will probably wish to use one (and only one) of the following commands:

 

To install everything (using your home directory): install.sh -a
To install everything (using another directory): install.sh -s mydir -a
To install Mininet + user switch + OVS (using your home dir): install.sh -nfv
To install Mininet + user switch + OVS (using another dir:) install.sh -s mydir –nfv
 

You can find out about other useful options (e.g. installing the wireshark dissector, if it’s not already included in your version of wireshark) using

 

install.sh –h
 

After the installation has completed, test the basic Mininet functionality:

 

sudo mn --test pingall

 

2.       Setup the Virtual Machine 

 

·         Start up VirtualBox, then select File>Import Appliance and select the .ova file.

·         Next, press the "Import" button. 

o   This will unpack and import the VM in your local machine. It will take a while - the unpacked image is about 3 GB.

 

3.       Boot VM

At this point the  VM should be ready to be started:

·         Press the "Start" arrow icon or double-click your VM within the VirtualBox window.

 

·         In the VM console window, log in with the user name and password for your VM. The username and password for this VM are:

 

o   User name - mininet

o   Password - mininet

 

Note that this user is a sudoer, so one can execute commands with root permissions by typing sudo command, where command is the command you wish to execute with root permission.

4.      Enable SSH

Ensure that the VM is turned off, otherwise VirtualBox will not allow any of the following changes:

a.       Select your VM and go to the Settings Tab.

b.      Go to Network->Adapter 2.

c.       Select the "Enable adapter" box, and attach it to "host-only network".

(Note: on a new VirtualBox installation you may not have any "host-only network" configured yet. To have one select File menu/Preferences/Network and "Add host-only network" button with default settings. Then you can try the attach.) This will allow you to easily access your VM through your host machine.

5.      Setting Up Network Access

The VM is shipped without a desktop environment, to reduce its size. Hence, X forwarding is needed, where programs display graphics through an X server running on the host OS.

To start up the X forwarding, first the guest IP address is required to be found.

6.      Connecting VirtualBox

If you are running VirtualBox, you should make sure your VM has two network interfaces. One should be a NAT interface that it can use to access the Internet, and the other should be a host-only interface to enable it to communicate with the host machine. For example, your NAT interface could be eth0 and have a 10.x IP address, and your host-only interface could be eth1 and have a 192.168.x IP address. You should ssh into the host-only interface at its associated IP address. Both interfaces should be configured using DHCP. If they are not already configured, you may have to run dhclient on each of them, as described below.

Access VM via SSH

In this step, you'll verify that you can connect from the host PC (your laptop) to the guest VM (Mininet) via SSH.

From the virtual machine console, log in to the VM, then enter:

 

$ ifconfig -a

      

You should see three interfaces (eth0, eth1, lo), Both eth0 and eth1 should have IP address assigned.

If this is not the case, type

$ sudo dhclient ethX

Replacing ethX with the name of a downed interfaces; sometimes the eth ports appear as eth2 or eth3, you can fix this by editing /etc/udev/rules.d/70-persistent-net.rules and removing the existing configuration lines. To avoid running this command each time you boot the VM, append the following lines in your /etc/network/interfaces file. (You will need sudo to edit this file)

auto eth1

iface eth1 inet dhcp

Note the IP address (probably the 192.168 one) for the host-only network; you'll need it later.

Next, follow the instructions below for your OS to log in.

1. Mac OS X and Linux

Open a terminal (Terminal.app in Mac, Gnome terminal in Ubuntu, etc). In that terminal, run:

$ ssh -X [user]@[Guest IP Here]

Replace [user] with the correct user name for your VM image.  Replace [Guest IP Here] with the IP you just noted. If ssh does not connect, make sure that you can ping the IP address you are connecting to.

Enter the password for your VM image. Next, try starting up an X terminal using

$ xterm

and a new terminal window should appear. If you have succeeded, you are done with the basic setup. Close the xterm. If you get a 'xterm: DISPLAY is not set error', verify your X server installation from above.

2. Windows

In order to use X11 applications such as xterm and wireshark, the Xming server must be running, and you must make an ssh connection with X11 forwarding enabled.

 

        First, start Xming (e.g. by double-clicking its icon.) No window will appear, but if you wish you can verify that it is running by looking for its process in Windows' task manger.

        Second, make an ssh connection with X11 forwarding enabled.

 

If you start up puTTY as a GUI application, you can connect by entering your VM's IP address and enabling X11 forwarding.

 

To enable X11 forwarding from puTTY's GUI, click puTTY->Connection->SSH->X11, then click on Forwarding->"Enable X11 Forwarding", as shown below:

Figure 2: Putty Configuration

You can also run putty (with the -X option for X11 forwarding) from the Windows command line:

 

·         Open a terminal: click the Windows 'Start' button, 'run', then enter 'cmd'.

·         Change to the directory where you saved putty.

C:> cd <dir>

·         Run:

C:> putty.exe -X openflow@[Guest IP Here]

·         Replace [Guest IP Here] with the IP you just noted.

·         If putty cannot connect, try pinging the VM's IP address to make sure you are connecting to the correct interface.

 

C:> ping [Guest IP Here]

·         Once the ssh connection succeeds or a terminal window for the VM pops up, log in to the VM. Now, type:

 

$ xterm -sb 500

to start an X terminal (the -sb 500 is optional but gives 500 lines of scrollback.)

A white terminal window should appear. If you have succeeded, you are done with the basic setup. Close the xterm.

 

 

If the xterm window does not appear, or if you get an error like "xterm: DISPLAY is not set," make sure that Xming is running in Windows and that you have correctly enabled X11 forwarding.

 

* These instructions are adapted from mininet.org.

Building the Network: Custom topologies using Mininet Python API

Most common 3-tier Datacenter architecture is the one based on core, aggregation and edge. The network in this example has hosts and switches connected in a linear topology, as shown in the figure below.

 

Data center networks typically have a tree-like topology. End-hosts connect to top-of-rack switches, which form the leaves (edges) of the tree; one or more core switches form the root; and one or more layers of aggregation switches form the middle of the tree.  In a basic tree topology, each switch (except the core switch) has a single parent switch.  Additional switches and links may be added to construct more complex tree topologies (e.g., fat tree) in an effort to improve fault tolerance or increase inter-rack bandwidth.

Figure 3: hosts and switches connected in a linear topology

Creating the Topology

Mininet supports parametrized topologies. With a few lines of Python code, one can create a flexible topology which can be configured based on the parameters passed into it, and reused for multiple experiments.

 

For example, our example network topology (based on Figure 3) consists of a specified number of hosts (h1 through hN) connected to their individual switches (s1 through sN):

Linear Topology (without Performance Settings)

 

The important classes, methods, functions and variables in the above code include:

·         Topo: the base class for Mininet topologies

·         addSwitch(): adds a switch to a topology and returns the switch name

·         addHost(): adds a host to a topology and returns the host name

·         addLink(): adds a bidirectional link to a topology (and returns a link key, but this is not important). Links in Mininet are bidirectional unless noted otherwise.

·         Mininet: main class to create and manage a network

·         start(): starts your network

·         pingAll(): tests connectivity by trying to have all nodes ping each other

·         stop(): stops your network

·         net.hosts: all the hosts in a network

·         dumpNodeConnections(): dumps connections to/from a set of nodes.

·         setLogLevel( 'info' | 'debug' | 'output' ): set Mininet's default output level; 'info' is recommended as it provides useful information.

Setting Performance Parameters

In addition to basic behavioral networking, Mininet provides performance limiting and isolation features, through the CPULimitedHost and TCLink classes.

 

There are multiple ways that these classes may be used, but one simple way is to specify them as the default host and link classes/constructors to Mininet(), and then to specify the appropriate parameters in the topology.

Linear Topology (with Performance Settings)

Some important methods and parameters:

self.addHost(name, cpu=f): This allows one to specify a fraction of overall system CPU resources which will be allocated to the virtual host.

 

self.addLink( node1, node2, bw=10, delay='5ms', max_queue_size=1000, loss=1, use_htb=True): adds a bidirectional link with bandwidth, delay and loss characteristics, with a maximum queue size of 1000 packets using the Hierarchical Token Bucket rate limiter and netem delay/loss emulator. The parameter bw is expressed as a number in Mb/s; delay is expressed as a string with units in place (e.g. '5ms', '100us', '1s'); loss is expressed as a percentage (between 0 and 100); and max_queue_size is expressed in packets.

Running in Mininet

To run the custom topology created above, following are the instructions:

·         Create a LinearTopo.py script on your Mininet VM and copy the contents of Linear Topology (without Performance Settings), listed above in it.

 

·         Make the script executable

chmod u+x LinearTopo.py

 

·         Execute the script

sudo ./LinearTopo.py

Sample Output

*** Creating network

*** Adding controller

*** Adding hosts:

h1 h2 h3 h4

*** Adding switches:

s1 s2 s3 s4

*** Adding links:

(h1, s1) (h2, s2) (h3, s3) (h4, s4) (s1, s2) (s2, s3) (s3, s4)

*** Configuring hosts

h1 h2 h3 h4

*** Starting controller

*** Starting 4 switches

s1 s2 s3 s4

Dumping host connections

h1 h1-eth0:s1-eth1

h2 h2-eth0:s2-eth1

h3 h3-eth0:s3-eth1

h4 h4-eth0:s4-eth1

Testing network connectivity

*** Ping: testing ping reachability

h1 -> h2 h3 h4

h2 -> h1 h3 h4

h3 -> h1 h2 h4

h4 -> h1 h2 h3

*** Results: 0% dropped (0/12 lost)

*** Stopping 4 hosts

h1 h2 h3 h4

*** Stopping 4 switches

s1 ...s2 ....s3 ....s4 ...

*** Stopping 1 controllers

c0

*** Done

 

 

Tuesday, 29 April 2014

Perl Script for Cisco IOS routers/switches for Information collection

Even though I had started out my life in IT moonlighting at a Calcutta (India) based start-up search-engine and greeting-card site (now arguably the largest in the country) as a Perl Programmer in mid-nineties,  about 14 years of hacking Cisco IOS, IOS-XR, NX-OS, BGP, MPLS, WAN Optimization, Juniper etc., had left me almost devoid of my ready skills in Perl, Python, C etc.

Woke up one morning few months back and realised that advent of SDN, NFV, Cloud etc. demands that I start to pick up my almost forgotten programming skills. So I enrolled myself to couple of Coursera modules for Python to get back into the game.  Strangely enough, I struggled to find a similar programme for Perl either on Coursera or eDX.

My industry background is a network-engineer bred on Cisco’s tech. Hence, as always, for me a good place (and comfort zone) to let lose the trial runs of scripts is the good old reliable Cisco IOS. I fired off a few scripts, needed Perl manuals big time for a starter, but felt the old commands slowly creeping back to the tips of my decrepit fingers. Perhaps there is hope for me after all!

My first stop was at http://stdioe.blogspot.co.uk/2011/09/how-to-connect-cisco-router-with-perl.html

The scripts did work, but I was not really satisfied. What I wanted was a bit more flexibility and to actually be able to collect the show command outputs in a separate file.

Perl Script for Cisco IOS routers/switches for Information collection; Connect through SSH

After a few trials with hard-coded target-hosts which is cumbersome because one needs to keep changing the script every time the need for connection comes up, I was finally able to define the target-host, the CLI password and enable secret as input variables. Thus the script hopefully achieved the flexibility to be used for any devices with any password without any need for hardcoding in the script itself. I also got ambitious and somehow managed to define the output of the show commands to be generated into a saved log file.

use Net::SSH2;

use warnings;

use strict;

my $host = $ARGV[0]; ### Input target host

string1

my $user = "admin";

my $password = $ARGV[1]; ### Input CLI/ssh password string2

my $secret = $ARGV[2]; ### Input enable pssswd as string3

my $ssh = Net::SSH2->new();

if(!$ssh->connect($host)){

print("Connection Failed\n");

exit(1);

}

if(!$ssh->auth_password($user,$password)){

     print("Authentication Failed");

     exit(1);

}

my $channel = $ssh->channel();

 

$channel->blocking(0);

$channel->shell();

print $channel "enable\n";

print $channel "$secret\n"; ### enable psswd from input string3

print $channel "term len 0\n";

print $channel "show clock\n";

print $channel "dir\n";

open (my $OUTPUTFILE, ">$host.log") or die "Can't open $host.log: $!"; ### target host as filename

    while (<$channel>) { 

    chomp;

    print $OUTPUTFILE "$_"; 

    }                      ### Get rid of the message lines

close $OUTPUTFILE or die "$OUTPUTFILE: $!";

 

Run command:  perl grabcisco.pl 10.1.1.1 password cisco -> Target host is '10.1.1.1'; ssh password is 'password', enable password is 'cisco' and output filename is '10.1.1.1.log')

My Perl skills are still not exactly great and the old fluidity of writing scripts are still a far cry, but perhaps not as far as they were, say, three months back. Persevere, persevere, persevere and lack of time generated by full-time professional engagement and a 1 year old son at home may one day wear off to get the creativity back!...”Yeah, and pigs might fly”, you say! J

 

 

 

 

 

 

 

 

Wednesday, 15 January 2014

SDN & OpenFlow 102: Open vSwitch

Why Open vSwitch?

=================

 

Reference and more info at: http://git.openvswitch.org/

 

Hypervisors need the ability to bridge traffic between VMs and with the outside world. On Linux-based Hypervisors, this used to mean using the built-in L2 switch (the Linux bridge), which is fast and reliable. So,it is reasonable to ask why Open vSwitch is used.

 

The answer is that Open vSwitch is targeted at multi-server virtualization deployments, a landscape for which the previous stack is not well suited. These environments are often characterized by highly

dynamic end-points, the maintenance of logical abstractions, and (sometimes) integration with or offloading to special purpose switching hardware.

 

The following characteristics and design considerations help Open vSwitch cope with the above requirements.

 

·         The mobility of state: All network state associated with a network entity (say a virtual machine) should be easily identifiable and migratable between different hosts. This may include traditional "soft state" (such as an entry in an L2 learning table), L3 forwarding state, policy routing state, ACLs, QoS policy, monitoring configuration (e.g. NetFlow, IPFIX, sFlow), etc.

 

Open vSwitch has support for both configuring and migrating both slow (configuration) and fast network state between instances. For example, if a VM migrates between end-hosts, it is possible to not only migrate associated configuration (SPAN rules, ACLs, QoS) but any live network state (including, for example, existing state which may be difficult to reconstruct). Further, Open vSwitch state is typed and backed by a real data-model allowing for the development of structured automation systems.

 

·         Responding to network dynamics: Virtual environments are often characterized by high-rates of change. VMs coming and going, VMs moving backwards and forwards in time, changes to the logical network environments, and so forth.

 

Open vSwitch supports a number of features that allow a network control system to respond and adapt as the environment changes. This includes simple accounting and visibility support such as NetFlow, IPFIX, and sFlow. But perhaps more useful, Open vSwitch supports a network state database (OVSDB) that supports remote triggers. Therefore, a piece of orchestration software can "watch" various aspects of the network and respond if/when they change. This is used heavily today, for example, to respond to and track VM migrations.

 

Open vSwitch also supports OpenFlow as a method of exporting remote access to control traffic. There are a number of uses for this including global network discovery through inspection of discovery or link-state traffic (e.g. LLDP, CDP, OSPF, etc.).

 

·         Maintenance of logical tags: Distributed virtual switches (such as VMware vDS and Cisco's Nexus 1000V) often maintain logical context within the network through appending or manipulating tags in network packets. This can be used to uniquely identify a VM (in a manner resistant to hardware spoofing), or to hold some other context that is only relevant in the logical domain. Much of the problem of building a distributed virtual switch is to efficiently and correctly manage these tags.

 

Open vSwitch includes multiple methods for specifying and maintaining tagging rules, all of which are accessible to a remote process for orchestration. Further, in many cases these tagging rules are stored in an optimized form so they don't have to be coupled with a heavyweight network device. This allows, for example, thousands of tagging or address remapping rules to be configured, changed, and migrated.

 

In a similar vein, Open vSwitch supports a GRE implementation that can handle thousands of simultaneous GRE tunnels and supports remote configuration for tunnel creation, configuration, and tear-down. This, for example, can be used to connect private VM networks in different data centers.

 

·         Hardware integration: Open vSwitch's forwarding path (the in-kernel datapath) is designed to be amenable to "offloading" packet processing to hardware chipsets, whether housed in a classic hardware switch chassis or in an end-host NIC. This allows for the Open vSwitch control path to be able to both control a pure software implementation or a hardware switch.

 

There are many ongoing efforts to port Open vSwitch to hardware chipsets. These include multiple merchant silicon chipsets (Broadcom and Marvell), as well as a number of vendor-specific platforms. (The PORTING file discusses how one would go about making such a port.)

 

The advantage of hardware integration is not only performance within virtualized environments. If physical switches also expose the Open vSwitch control abstractions, both bare-metal and virtualized hostingenvironments can be managed using the same mechanism for automated network control.

 

In many ways, Open vSwitch targets a different point in the design space than previous hypervisor networking stacks, focusing on the need for automated and dynamic network control in large-scale Linux-based virtualization environments.

 

The goal with Open vSwitch is to keep the in-kernel code as small as possible (as is necessary for performance) and to re-use existing subsystems when applicable (for example Open vSwitch uses the existing QoS stack). As of Linux 3.3, Open vSwitch is included as a part of the kernel and packaging for the userspace utilities are available on most popular distributions.

 

 

Does Open vSwitch only work on Linux?

 

No, Open vSwitch has been ported to a number of different operating systems and hardware platforms.  Most of the development work occurs on Linux, but the code should be portable to any POSIX system.  Open vSwitch has been ported to a number of different platforms, including FreeBSD, Windows, and even non-POSIX embedded systems.

 

By definition, the Open vSwitch Linux kernel module only works on Linux and will provide the highest performance.  However, a userspace datapath is available that should be very portable

 

More Info: http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=FAQ;hb=HEAD

 

 

Quick Virtualization Recap:

 

 

 

Desired Add Ins Include:

       Visibility that network administrators expect

       Higher Granularity of Control

       Scalability

 

Virtualized Networking is Different:

       A virtual switch is a software program that allows one virtual machine (VM) to communicate with another.

       A virtual switch does more than just forward data packets - can intelligently direct communication on the network by inspecting packets before passing them on.

       Some vendors embed virtual switches into their virtualization software, but a virtual switch can also be included in a server's hardware as part of its firmware.

       Hypervisors need to bridge traffic between VMs and the outside world.

       Linux-based hypervisors use built-in L2 switch (the Linux bridge), which is fast and reliable.

       So, WHY Open vSwitch ?...

Ø   Open vSwitch is targeted at multi-server virtualization deployments

 

 

 

 

Open vSwitch Design Considerations:

 

       Mobility of state: 

      Supports both configuring and migrating both slow (configuration) and fast network state between instances.

      May include an entry in an L2 learning table, L3 forwarding state, policy routing state, ACLs, QoS policy, monitoring configuration (e.g. NetFlow, IPFIX, sFlow), etc.

 

       Responding to network dynamics:

      Supports a number of features that allow a network control system to respond and adapt as the environment changes, for e.g., NetFlow, IPFIX, and sFlow

      supports a network state database (OVSDB) that supports remote triggers - used effectively to to respond to and track VM migrations

 

       supports OpenFlow for exporting remote access to control traffic.

 

       Maintenans logical tags:

       Distributed virtual switches maintain logical context within the network through appending or manipulating tags in network packets- for e.g., to uniquely identify a VM or to refer to some context which is only relevant in the logical domain

      Methods for specifying and maintaining tagging rules, all of which are accessible to a remote process for orchestration

       Supports a GRE implementation that can handle thousands of simultaneous GRE tunnels and supports remote configuration for tunnel creation, configuration, and tear-down. This, for e.g., can be used to connect private VM networks in different data centers.

 

       Hardware integration:

       Open vSwitch's forwarding path (the in-kernel datapath) is amenable to "offloading" packet processing to hardware chipsets, whether housed in a classic hardware switch chassis or in an end-host NIC. This allows for the Open vSwitch control path to be able to both control a pure software implementation or a hardware switch.

       Advantage of hardware integration:

      performance within virtualized environments.

      If physical switches also expose the Open vSwitch control abstractions, both bare-metal and virtualized hosting environments can be managed using the same mechanism for automated network control.

 

Open vSwitch Consepts:

 

       Multi-Layer Virtual Switch

       Flexible Controller in User-Space

       Fast Datapath in Kernel

       An implementation of Open Flow

       A switch contains ports

       A port may have one or more interfaces

       Bonding allows more than once interface per port

       Packets are forwarded by flow

 

 

 

 

 

 

 

 

 

 

 

 

 

Basic Configuration

 

 

Basic De-Configuration

 

 

 

Breakfast At Serengeti

Breakfast At Serengeti
Lion's Share

The Ngorongoro Family

The Ngorongoro Family
Click on the Picture Above To Make It Larger

Tabloid Time: The Aliens Are a'Landing ?!.. ;-)

At the risk of being ridiculed and being labelled a freak, I shall like to draw everyone's attention to the following recent events....If you watch the videos then turn on the sound for the commentary...



Fireball across Ausin, Texas (16th Feb 2009). According to BBC, apparently, its NOT debris from a recent satellite collision...:
http://news.bbc.co.uk/1/hi/world/7891912.stm
http://us.cnn.com/2009/US/02/15/texas.sky.debris/index.html

Same in Idaho in recent times. NO meteor remains found yet: http://news.bbc.co.uk/1/hi/sci/tech/7744585.stm

Exactly same in Sweden: http://news.bbc.co.uk/1/hi/world/europe/7836656.stm?lss

This was recorded on 25th Feb 2007 in Dakota, US:
http://www.youtube.com/watch?v=cVEsL584kGw&feature=related

This year has seen three of the spookiest UFO videos surface, with people in India, Mexico and even in space, NASA, spotting things they couldn't explain: http://www.youtube.com/watch?v=7WYRyuL4Z5I&feature=related

CHECK out this one on 24th Januray, 2009 in Argentina close to Buenos Aires:
You tube: www.youtube.com/
Press:
Press Coverage

AND Lastly, and more importantly, from Buzz Aldrin on Apollo 11 : http://www.youtube.com/watch?v=XlkV1ybBnHI

Heh?! Don't know how authentic these news are... don't even know if these are UFO's or meteors or ball lightning or something else. But, if meteors, then where are the meteorites ? However, I see no reason why life cannot exist in other planets and why they could not be sneaking around here :-) . I for one, have long suspected some of my relations to be space aliens or at least X-people from X-files :-)

I am waiting for a job on an Alien spaceship myself. :-)


Giraffes in Parallel Universe

Giraffes in Parallel Universe
At Lake Manyara

Serengeti Shall Never Die

Serengeti Shall Never Die
Wildebeeste Calf starts running only 5 min. after being born. CLICK on the pitcture to view Slideshow