Changes between Version 4 and Version 5 of Internal/OpenFlow/ofTopology


Ignore:
Timestamp:
Jan 30, 2012, 1:21:51 AM (12 years ago)
Author:
akoshibe
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Internal/OpenFlow/ofTopology

    v4 v5  
    22This is a rough overview of the steps one needs to take in order to simulate point-to-point links between nodes sharing a single switch (e.g. within the same broadcast domain), using !OpenFlow-controlled nodes as a means to move traffic from one VLAN to another. The steps described here are incomplete; Things will be updated as methods are refined/improved.
    33
     4== Background ==
     5VLANs are good for breaking up broadcast domains. If each node is placed on separate VLANs and given a choice of a few "gateways" out of its VLAN, it has no choice but to communicate through the gateway(s). How the gateway nodes moves packets/frames from one VLAN to another depends on which network layer(s) are involved.
     6
    47== Prerequisites ==
    5 VLANs are good for breaking up broadcast domains. If each node is placed on separate VLANs and given a choice of a few "gateways" out of its VLAN, it has no choice but to communicate through the gateway(s). How the gateway nodes moves packets/frames from one VLAN to another depends on which network layer(s) are involved.
    6 
    78This page assumes that you have a setup similar to [http://www.orbit-lab.org/wiki/Documentation/OpenFlow SB9], as well as a node with a working install of NetFPGA drivers or !OpenvSwitch, depending on how links are being set up. For the !OpenFlow methods, you also need a !OpenFlow controller that allows you to push flows to your software defined switch. You should have access to the switch that the nodes are sharing as well, since you need to slice it into VLANs. The following links describe setup and use of theses components (internal links):
    89 
     
    1314
    1415The system used here is Ubuntu10.10 (kernel: 2.6.35-30-generic). Command syntax will change depending on your distro.
     16
     17First and foremost, the shared switch should be split into several VLANs according to your topology. Two interconnected nodes should be on the same VLAN e.g. the switch-ports connected to them should be associated with the same VLAN ID. Nodes connected to more than one element should sit on a trunked port open to all VLANs the node should associate with.
    1518
    1619== Contents ==