The Topology application provides an in-memory record of all links currently up in the network. It does not post any events, but rather exposes methods to retrieve the links sourced at any given datapath in the network.
The routing application keeps track of shortest-path routes between any two authenticated datapaths in the network. Routing interacts with the Topology component in order to maintain routes. On link changes, the set of affected routes is updated.
Routing currently listens for Flow_in_events which are raised by the Authenticator when a Packet_in_event is received from the network, and routes them by setting up exact match flow entries in all switches along the path from the source to destination access points.
Routing operates as follows:
- It pulls in the authenticator component which tracks MAC addresses and the switch ports they are bound to
- For each packet in which the destination MAC address has been discovered, a point to point route is calculated and a flow entry is added to each switch along path.
- If the destination MAC has not been discovered, the packet is flooded
In that sense, the name of the component "Routing" does not refer to standard IP based routing. This has been the source of a lot of confusion and the module should probably be renamed to "forwarding" or something similarly generic. Its operation is simple, "routing" identifies hosts by their MACs and sets up routes per-flow. If routing doesn't know the location of the destination MAC, it floods the packet. The flows themselves are exact match for all OpenFlow fields (and therefore that routing decision should only apply to the packets of that particular flow).
Packet in event
This event is defined in the file src/include/packet-in.hh
This event is defined in the file src/nox/apps/discovery/link-event.hh
Flow expired event
This event is defined in the file src/include/flow-expired.hh
Flow expired events are thrown for each openflow expiration message received by the controller.
Expiration messages are sent by the switches on flow timeout (either hard or soft). Flow expirations are only generated by switches if they to do so by the controller (flow expirations are not enabled in NOX by default).
Datapath leave event
This event is defined in the file src/include/datapath-leave.hh
NOX API notes
All of the packet processing code is in nox/lib/packet/.
In general you can iterate over the packet headers using .next. So packet.next should be the IP header. packet.next.next the tcp header and so on. Note that if VLANs are in play, they'll come in as an additional header.
Alternatively, if you know what type of packet you have, you can also use the protocol name (rather than next)
my_iphdr = packet.ip
One way to get the location of a MAC is to call authenticator::get_dl_addr_entry()
The returned DLEntry should contain all known locations for that address.
Other applications can also ask the routing module for a specific route using the “get_route” method.
pytopology has a method get_outlinks thats takes a source datapathid and destination datapathid, and returns a list of all of the port pairs that are connected. This is defined in pytopology.i
if datapath 1's ports 5 and 6 are connected to datapath 2's ports 3 and 4 respectively, you would have the following.
from nox.lib.netinet.netinet import create_datapathid_from_host
dp1 = create_datapathid_from_host(1) dp2 = create_datapathid_from_host(2) ports = pytop.get_outlinks(dp1, dp2)
where ports would be a list of PyLinkPorts of length 2, where PyLinkPorts is described in that pytopology.i file. Particularly it would be the equivalent of [ (5, 3), (6, 4) ] , however it's actually a SWIG-ed out list, which needs to be iterated through using begin(), incr(), and end().