vWireExample

Crossbow Virtual Wire Example (10 Minutes)

Description

This demo uses the Crossbow Virtual Wire network design tool to create 2 virtual private networks. One network contains a web server (192.168.2) while the client is connecting from a separate network (193.168.3). A router is set up to forward packets between the 2 networks. This is a self-contained private network. If you're interested in interacting with a public network, look at the Virtual Wire Demo. This demo script is modeled after vWireExample screencast by Kais Belgaied (found in the installation package referenced below).

OpenSolaris Versions Supported

2009.06

Points to Hit

  • Crossbow enables you to create virtual networks on which you can impose constraints.
  • The Crossbow Virtual Wire tool allows you to build those networks graphically.

Demo Prep

  • You'll find the screencast of this demo in the vWireBuilder/Watchme/VWireExample.html. Please watch it to better understand this script.
  • The Crossbow Virtual Wire installer creates a template zone that will be cloned as needed, for example, when you create a web server, router, firewall, client, etc. However, the screencast was prepared using SXCE. SXCE's zones have packages that are not included in OpenSolaris ipkg branded zones. So before we run the installation script, it needs to be modified to install the SUNWroute, SUNWapch22 and SUNWwget packages. Edit vWireBuilder/install.ksh and add the following to the end of the zone install line:
    pfexec zoneadm -z templatezone install -e SUNWroute -e SUNWapch22 -e SUNWwget
  • Run the installer.
  • Boot the template zone (pfexec zoneadm -z templatezone boot) so that the SMF service descriptions can be loaded. Therefore, they will also be loaded when the zone is cloned. If you fail to do this, you demo will spend unnecessary time doing this for each zone clone. The templatezone does not need to be running once this step is complete (pfexec zoneadm -z templatezone halt).

Gotchas

  • The graphical editor is still under development. Features like Delete are not implemented yet. So if you make a mistake you essentially have to start fresh (Project > New)

Demo

Design the Virtual Network

Here we'll create 2 virtual networks, one for a web server and another representing a client. They'll be connected with a router.

  • Click the Crossbow VWire Builder Demo icon on the Desktop. When prompted, choose the default option to Reset Configuration. This will delete any virtual remnants from a prior use of the tool.
  • Add 2 VSwitches
  • Add 4 VNICs. Connect vnic1 and vnic2 to vswitch1. Connect vnic3 and vnic4 to vswitch2.
  • Drag a WebServer on the canvas
  • Right-click vnic1 and select Connect To. Connect vnic1 to WebServer_1. Set the Static IP Address to 192.168.2.11.
  • Drag a Client onto the canvas.
  • Right-click vnic4 and select Connect To. Connect vnic4 to Client_1. Set the Static IP Address to 192.168.3.11.
  • Drag a Router onto the canvas.
  • Connect vnic2 to Router_1. Set the Static IP Address to 192.168.2.1.
  • Connect vnic3 to Router_1. Set the Static IP Address to 192.168.3.1.
Generate the Virtual Network
  • Select Action > Compile to generate the scripts that will create the virtual network we've just designed. Scroll the output window to review the scripts that were just created.
  • From a terminal, run dladm show-link to see the current list of links.
  • Run zoneadm list -cv to show the current list of zones.
  • Return to Crossbbow Virtual Wire and select Action > Execute to execute the scripts that were created by Compile.
  • Return to the terminal and run dladm show-link to see the ethersubs (2) and vnics (4) created by the script.
  • Run zoneadm list -cv* to show the zones created by the scripts (Router_1, WebServer_1 and Client_1)

Note, although the zones show as running, they will take several minutes to boot and configure themselves. You can run prstat -Z to monitor the progress. In the next step we will open consoles to the zones, which will also show the configuration progress if it hasn't yet been completed.

Test the Virtual Network

Return to Crossbow Virtual Wire. Right-click Client_1 and select Console... (note, the zone may still be configuring itself). Open consoles for WebServer_1 and Router_1. Log in using root/abc123.

In Client_1

Configure Client_1 to route requests to the web server's subnet.

  • Run ifconfig -a to show vnic4 is plumbed and ready to go.
  • ping 192.168.2.1 (the web server's subnet) - Host Unreachable from gateway Client_1
  • Run netstat -rn to show the routing table.
  • Run route add default 192.168.3.1 (the router on the client's subnet)
  • ping 192.168.2.1 (the web server's subnet) - is alive!

In WebServer_1

Configure WebServer_1 to route packets to the client's subnet.

  • Run ifconfig -a to show vnic1 is plumbed and ready to go.
  • ping 192.168.3.1 (the client's subnet) - Host Unreachable from gateway WebServer_1
  • Run netstat -rn to view the routing table
  • Run route add default 192.168.2.1 (the router on the web server's subnet)
  • ping 192.168.3.1 (the client's subnet) - is alive!
  • Run ping -ns 192.168.3.11 (the client). There's no response. Ctrl+C to break.

In Router_1

  • Run ifconfig -a to show vnic2 and vnic3 are plumbed and ready to go.
  • Run netstat -rn to view the routing table

In Client_1

  • run traceoute 192.168.2.1 (the router)
  • ping -ns 192.168.2.1 (it should work)
  • ping -ns 192.168.3.11 (the web server). There's no response. Leave it trying and move on...

In WebServer_1

  • ping -ns 192.168.3.11 (the client). There will be no response. Break.
  • ping -ns 192.168.3.1 (the router). It will succeed.
  • ping -ns 192.168.3.11 again. Leave it trying and move on...

In Router_1

Configure the Router_1 for forward requests across the subnets.

  • Run routeadm. You should see that all IPv4 forwarding is disabled.
  • Run routeadm -e ipv4-forwarding
  • Run routeadm -u to apply the changes. Watch the Client_1 and WebServer_1 terminal windows as this command completes and the pings start processing!
    Note, if you get an error running this command, make sure you modified the installation script as described in the Demo Setup steps above.

In Client_1

  • Run traceroute 192.168.2.11 (WebServer_1)
  • Run ping -ns 192.168.2.11 again.

In Router_1

  • reboot. You notice the pings temporarily stop and then restart

In WebServer_1

Enable Apache

  • svcadm enable apache22

In Client_1

  • Run wget 192.168.2.11, which should grab index.html.
Dynamic Bandwidth Control

Here will use a utility (netperf) to force network load on the system and dynamically alter the bandwidth.

In Client_1

  • Let's put some load on WebServer_1. Run /var/tmp/netperf -H 192.168.2.11 -l 300
  • Return to Crossbow Virtual Wire and select Action > Network Monitor Usage (This dialog doesn't open for me when running under VirtualBox. See the steps below for running it directly from Chime).
  • Right-click the line will all the activity and select Plot Throughput Over Time.
  • Right-click vnic1 and select Properties. Set the bandwidth to about 500 MBytes/sec.
  • Watch the graph and then set the bandwidth property to about 3000 MBytes /sec.
Configuring Chime to run the Network Monitor
  • Edit ~/vWireBuilder/OSOL0chime/bin/chime
  • Change the ROOT variable from /opt/OSOL0chime to ~/vWireBuilder/OSOL0chime
  • cp vWireBuilder/VWire/Network.xml vWireBuilder/OSOL0chime/displays/.
  • pfexec vWireBuilder/OSOL0chime/bin/chime
  • Run the Network trace

Demo Cleanup

These are the necessary steps to take in order to successfully run the demo again on the same machine.

  • Simple. The next time you start Crossbow Virtual Wire, choose the option to reset the configuration.

Labels

opensolaris opensolaris Delete
crossbow crossbow Delete
vwire vwire Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Sun Microsystems community and they might not be employed or in any way formally affiliated with Sun Microsystems. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Sun nor any other party necessarily agrees with them.

© 2010, Oracle Corporation and/or its affiliates
Powered by Atlassian Confluence
Oracle Social Media Participation Policy Privacy Policy Terms of Use Trademarks Site Map Employment Investor Relations Contact