Version 5 (modified by 11 years ago) (diff) | ,
---|
GENI layer1transport service usage
Introduction
This page describes how to use the layer1transport service.
Variables
Name | Description | Default Values |
<rest_port> | REST API port for FL | 18080 |
<flow_name> | Name of flow according to SFP |
Using the Service
The following is a brief description of how the service can be used.
Common Work flows
There are limitations to what this service can do at the moment, so below I will list some steps to take for various work flows.
Adding a new flow
When adding a new connection in that needs a new flow defined in the switch:
- Define the flows and put them into a new file under
/home/openflow/floodlight/flows.d/
- Run
service layer1transport reload
This should push the new flows without disrupting connectivity for other existing connections.
Removing a flow
When removing a connection that relies on a specific flow:
- Determine which flows should be removed and collect the names of the flows
- For each flow that should be removed, run
/home/openflow/floodlight/apps/layer1transport delete -n <flow_name> -p <rest_port>
This should remove flows by name without disrupting connectivity for other existing connections.
Updating an existing flow
If you need to update a flow that has already been defined and pushed:
- Update the flows file to use the new flow information
- Remove the old flow by running
/home/openflow/floodlight/apps/layer1transport delete -n <flow_name> -p <rest_port>
- Run:
service layer1transport reload
Restoring Static Flow Pusher (SFP) to a known state
If you believe that SFP may be out of sync with the desired state, but your are unsure what the specific problem is, then the best option may be to restart the service with:
service layer1transport restart
This will briefly remove and reinstall all static flows, so this is disruptive to connectivity managed by this service.
Listing the flows that SFP knows about
To list which flows SFP knows about, the most up-to-date information can be found in the SFP documentation.
Listing the flows that a switch knows about
To list which flows that a given switch knows about, the most up-to-date information can be found in the REST API documentation under the command for querying for flow statistics.
Defined Service Commands
start
The following command will cause the floodlight controller to start and it will push the flows that exist in the flows files.
service layer1transport start
stop
The following command will cause the flows that are defined in the flows files to be explicitly removed, and it will cause the floodlight controller to stop. Floodlight's SFP module will not preserve flows when floodlight is shut down, so any remaining flows (whether they are inserted through other means, or if they are stale for some reason) will be removed.
service layer1transport stop
reload
The following command will cause the floodlight module to read in the flows files, and add any flows which have names that are unknown to the floodlight SFP service. Note that this will not remove flows that are removed from files, it will not remove flows if a file has been removed, and it will not update flows with a name that SFP already knows about.
service layer1transport reload
restart
The following command will stop, pause, and then start the layer1transport service.
service layer1trasport restart
status
If the service is experiencing a failure condition, the status command will print out a message describing the failure and return a non-zero exit code. On success, the status command will print out a success message and return an exit code of zero. The command checks for the following:
- The underlying OpenFlow is controller running
- All flows that exist in
/home/openflow/floodlight/flows.d/
are currently being managed by the OpenFlow controllerservice layer1transport status