Hi Murphy, Thanks a lot,
Does that basically means: actions = [[openflow.OFPAT_OUTPUT, [0, openflow.OFPP_IN_PORT]]] Regards, Vishal On Fri, Mar 30, 2012 at 8:19 PM, Murphy McCauley <[email protected]>wrote: > Specifically in order to avoid creating loops, an output action will > generally not go back out of the incoming port. If you do really want to > do this, you must add an output action that outputs to the OFPP_IN_PORT > virtual port. If you check the spec, it describes OFPP_IN_PORT as "Send > the packet out the input port. This virtual port must be explicitly used > in order to send back out of the input port." > > -- Murphy > > On Mar 30, 2012, at 5:09 PM, Vishal wrote: > > > Hi, > > > > I have 2 openvswitches: OVS1 and OVS2 > > > > OVS1, port 3 is connected to OVS2's port 3 > > > > so, I set up a rule, saying traffic_matching_some_condition, when > received on port 3 send it back to port 3 (for both the switches, in > pyswitch, handle packet in). > > > > The above should in theory, cause a packet to ping pong between the two > interfaces until the hard time out. --> essentially, it's forcibly creating > a loop. > > > > > > I achieve this by setting -> out_port = 3 (instead of prt[0] for the > matching flow) in pyswitch. > > actions = [[openflow.OFPAT_OUTPUT, [0, out_port]]] > > inst.install_datapath_flow(dpid, flow, CACHE_TIMEOUT, > openflow.OFP_FLOW_PERMANENT, > > actions, bufid, > openflow.OFP_DEFAULT_PRIORITY, inport, buf) > > > > > > When I look at Flow Mod for this flow, it correctly sets the port to 3. > > > > The problem is that the actual packet is not being sent by the switch > back to the port on which it was received. > > > > On wireshark, I see that number of packets on each switch is same as > number of packets generated by one client host connected to one of the > switches. > > > > Is there a mechanism to prevent such looping in the openv switch or am i > doing something wrong ? > > > > Regards, > > Vishal > >
