[置顶] NOX的使用之学习篇【一】

学习材料：http://noxrepo.org/noxwiki/index.php/NOX_Installation#Installation

 

Q&A:

NOX runs, now what?

Many users start by playing around with the pyswitch component as is it a simple example written in python only, and it is a good start to get a feeling of the framework. Look at the code, see how it utilizes the python core API (defined in src/nox/lib/core.py) and maybe start experimenting with it using a single Openflow switch as the controlled entity. For a more challenging step, look at the Routing module, which makes use of the Authenticator, Topology and Discovery components, to see how you can start building bigger, multi-component applications.

However, keep in mind that what you just installed is merely a framework for programming network behaviours. The included Components are there to set a foundation and give examples of how NOX can be used. From know on, what happens with NOX and your network is what you want (and program) it to do.

How can I edit the flow table of a switch?

In order to see an example of setting up flows through a NOX component written in python, you can look at /src/nox/coreapps/examples/pyswitch.py The idea is that you need to construct the openflow packet manually, filling out the flow description and the actions, and then send it to the desired switch. Deleting flows works in the same way. The process is the same in a C++ component, just the API differs a bit.

 

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

Using NOX:

 

NOX must be invoked by the command line within the build/src directory. Generally, the command that starts the controller looks like this:

   ./nox_core [OPTIONS] [APP[=ARG[,ARG]...]] [APP[=ARG[,ARG]...]]...

Normally, NOX listens on a TCP port (SSL is supported though poorly documented at the moment) waiting for switches to connect. Once switches connect, NOX will dispatch network packets to the running components, and send OpenFlow messages to the switches on behalf of the components.

 

For instance, the following will initiate NOX, listening for incoming connections from Openflow switches on port 6633 (the Openflow protocol port):

   ./nox_core -v -i ptcp:6633

At this point, the core of NOX is running. However, while switches can now connect to the controller, no behaviour will be imposed on them by NOX. Recall that NOX is intended to provide the control logic for an entire network. This can mean many things, including: handling traffic engineering; routing; authentication; access control; virtual network creation; monitoring; and diagnostics. However, NOX itself does none of these things. Rather, it provides a programmatic interface to network components which perform the useful functionality. So, what is missing from the above command in order to give life to a NOX network is the Components NOX should run. These are passed as arguments to the above command.

 

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

NOX componets:

Network apps

This is the list of network applications that actually manage the network:

• Discovery keeps track of links between controlled switches.
• Topology provides an in-memory record of all links currently up in the network.
• Authenticator keeps track of the location of hosts and switches on the network.
• Routing is the component responsible for path calculation.

Net components are located in src/nox/netapps/

Web apps

NOX Web applications are used for managing NOX through web services.

• Webservice provides the web services interface for NOX applications.
• Webserver is the app hosting the control interface.
• Webserviceclient .

Web components are located in src/nox/webapps/

Third-party extensions

The components listed above are only those that come with the current NOX packaging. However it should be clear that NOX core is only the platform for programming network behaviour, and its power lies in its extensibility. The network behaviour itself is defined by the applications that NOX runs. Many extensions to NOX have been developed by various developers and researchers. Below is a non-extensive list with examples of third party NOX applications and projects that utilize NOX:

• OVN is a network virtualization framework based on NOX/Openflow.
• Basic Spanning Tree is a NOX module that constructs a spanning-tree for an OpenFlow network
• Mobile VMs is a demo application that won the award for best demonstration at SIGCOMM 2008
• RipCord is a modular platform for datacenter networking

The following extensions have since been incorporated into NOX.

• LAVI is a backend for network visualization.
• OpenRoads is a platform for innovation on SDN in mixed environments (fixed and wireless networks).

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

NOX events:

 

Core Events

NOX contains a number of built-in events which map directly to OpenFlow messages received by controlled switches. These include:

• Datapath_join_event : Issued whenever a new switch is detected on the network.
• Datapath_leave_event : Issued whenever a switch has left the network.
• Packet_in_event : Called for each new packet received by NOX. The event includes the switch ID, the incoming port, and the packet buffer.
• Flow_mod_event : Issued when a flow has been added or modified by NOX.
• Flow_removed_event : Raised when a flow in the network expires or has been removed.
• Port_status_event : Indicates a change in port status. Contains the current port state including whether it is disabled, speed, and the port name.
• Port_stats_in : Raised when a Port_stats message is received by a controlled switch in response to a Port_stats_request message and includes the current counter values for a given port (such as rx,tx, and errors).

Application Events

In addition, components themselves may define and throw higher level events which may be handled by any other events. The following events are thrown by existing NOX components.

• Host_event : Raised by the Authenticator whenever a new host has joined the network or a host leaves the network (generally due to timeout).
• Flow_in_event : Raised by the Authenticator whenever a Packet_in_event is received from the network. The Flow_in_event is then handled by the Routing application.
• Link_event : Raised by Discovery for each link discovery/change on the network. This can be used to reconstruct the network topology if the discovery application is being run.