On Nov 23, 2012, at 5:34 PM, shashaankar reddy wrote: > #This module will implement the feature of providing the user with an option > to group flows into broadcast domains based on ingress ports of the switch. > This is a pseudo VLAN implementation using OpenFlow. Except, VLANs are tied > to ports and it is exhaustive to make management changes to VLAN > configuration. Here, the administrator only needs to enter the ports in the > configuration file. > > So for example consider a switch s1 (1,2,3,4,5,6,7,8,9,10) with ten ports and > now I configure ports (5,6,7) to be in one domain, and all broadcast traffic > from these ports should be sent only among these ports (broad cast traffic > from port 5 --> flood on port 6, 7 or Broadcast traffic on port 6 --> flood > on ports 5, and 7). > > 1) Could you please let me know how can I achieve this requirement? Since in > this case I need to keep track configuration of each switch in the network > and then form policies on those switch ports to redirect traffic accordingly.
Instead of sending floods to OFPP_FLOOD, just keep a list of which ports are in which group, and add an output action for each port in the same group as the packet's input port. You might consider just installing a flow for every source/destination MAC pair when the destination MAC is a multicast address. > # Now, for implementing blocking flows for IP addresses and application ports > based on l2_learning.py > > 1) After, I parse the packet (packet = event.parsed), could you redirect me > to complete list of properties of this parsed packet so that I can use it in > my code. It's not the most complete section, but read the "Working with packets: pox.lib.packet" section of the POX manual at: https://openflow.stanford.edu/display/ONL/POX+Wiki In short, event.parsed is an ethernet object. Its payload property will often be an ipv4 object. The ipv4 object's payload will often be a tcp object. The tcp object's payload will usually just be bytes. So, in short, it's a chain of objects which have attributes corresponding to header fields. For more detail, read some of the code for the sample components in POX or read some of the code in pox/lib/packet. The fields of a packet should all be initialized in the __init__() methods, so you can use that to see what fields are available. > 2) In this I also need to access application port (TCP/UDP port) can I get it > from parsed packet properties. Something like: event.parsed.find("tcp").srcport > As you mentioned "You can examine which switches are currently connected by > iterating over core.openflow.connections. That will give you each of the > Connection objects. You can then inspect their "ports" attributes to see > their ports,..." > > 3) Could you also redirect me to some links that will provide complete list > of properties or methods that I can access the contents of the packet_in > message, (In Mininet I saw the communication between switch and the > controller exchange a lot of openflow messages - packet_in , packet_out, and > flowmod) as a Newbie to openflow I'm finding it difficult with accessing the > properties of each message. You should refer to the OpenFlow 1.0 specification and the "OpenFlow in POX" section of the manual. > # Finally, we have very short span of time to complete our project, I would > admire any prompt help from you and as we are planning a demo of our project > on GENI platform do you think there will be any portability issues? I don't have much personal experience with this, but I can tell you anecdotally that you may well have portability issues. Different types of switches often have their own quirks. And I believe some hardware switches are not great at doing the type of per-flow access control stuff you're doing. Maybe this will get you started: http://www.noxathome.org/x/Murphy/l2_port_slicer.py It's a modification of l2_learning that can filter by TCP/UDP port or IP/subnet and can create flood groups, all configurable through a JSON config file. Read the comment block at the top for more info and a sample config file. -- Murphy
