Thanks a lot for your suggestions,Murphy,
I could finally resolve my issues by looking at the packet traces/tcpdump
on all interfaces, made changes to it and finally gave my project
demo successfully!! :)
Thought It would be helpful, if I could provide my experience so that
others will not step into same mistake.
1) In the code below::
# Fill in default port group with all normal ports
for p in event.connection.ports:
if p >= of.OFPP_MAX: continue
config['port_groups'][0].append(p)
if dpid not in self.configs:
log.warning("No config for %i port switch %s",
len(event.connection.ports), dpid)
* config.update(self.configs.get(dpid, {}))*
The above code actually assigns all physical ports of a switch to one group
(when the switch connected or connectionUp event is fired)and then updates
the config file with the policies we entered in the config file. So
actually the config.update() function overwrites the previous contents of
the property in the config file. The mistake I have done is I just left the
port_groups property blank, which subsequently drops all the packets as it
does not belong to any of the port groups.
Example:
Consider port_grouping policy set for any of the switch (with ten ports) in
the network:
---If the policy for port_groups is defined: [1,2,3,4,5], [6,7,8,9,10]
<<Before config.update()>>
port_groups [[1,2,3,4,5,6,7,8,9,10]]
<<After config.update()>>
port_groups = [[1,2,3,4,5],[6,7,8,9,10]]
--if the policy for port_groups is defined: [[]] # blank
<<Before config.update()>>
port_groups [[1,2,3,4,5,6,7,8,9,10]]
<<After config.update()>>
port_groups = [[]]
The second case is what happened in my case.
And, the code-commented-1 and code-commented-2 in my previous posts works
just fine when included in the script. We have been using openVswitch
installed on a PC in our network to demo it on GENI. OpenVswitch also
supports flow-mod or actions that would flood it on multiple ports
((desired)) using multiple actions in the flow-mod message instead of
OFPP_FLOOD (which floods on all available ports).
But somehow the only issue I could not understand is, sometimes I receive
the packet_in message from the openVswitch with the switch physical port as
*65534*, this I have seen in the log messages when printed the
*even.port *which
leads to the packet being dropped as it doesn't belong to any of the switch
groups from the config file. I could see this issue frequently but
sometimes it doesn't show up!! strange ?
http://openvswitch.org/cgi-bin/ovsman.cgi?page=vswitchd%2Fovs-vswitchd.8
this link provides some info regarding the 65534 which is used as a local
port in openVswitch.
If any one has understood the root cause of this issue, please reply to
this post! It may be helpful for others who are facing similar issue.
Thanks & Regards,
Shashaankar
*Research Assistant (Systems Research Lab)*
*North Carolina State University*
*Computer Science Dept.*
314-609-903 <314-609-9035>
On Mon, Nov 26, 2012 at 2:57 AM, Murphy McCauley
<[email protected]>wrote:
> On Nov 25, 2012, at 6:39 PM, shashaankar reddy wrote:
>
> In order to make it work I commented it out following code, in
> l2_port_slicer:
> Code-Commented-1
> #group = self.port_groups.get(event.port)
> #if group is None:
> # log.debug("Dropping packets from non-grouped port %s.%i",
> # dpid_to_str(event.dpid), event.port)
> # drop(5)
> # return
>
> and
> Code-Commented-2
> # Send to all other ports in this group
> #for p in group:
> msg.actions.append(of.ofp_action_output(port = of.OFPP_FLOOD)) # *(and
> made this change for flooding)*
>
>
> So the test I'd run is:
> Leave all the code as original except switch to a single OFPP_FLOOD action
> (as in your Code-Commented-2 block). Set the config file to have no port
> group so that the component generates a single port group of all ports.
> Capture the OpenFlow traffic using Wireshark or the openflow.debug
> component. Then do a ping test. Be sure to wait for a few seconds after
> all switches connect before doing the test.
>
> Post the logs and pcap traces.
>
> If that test doesn't work, comment out JUST the drop(5) and return from
> the first code block and re-run it and post those logs and pcap traces too.
>
> I collected following logs when for different scenarios
> as described below: (It also includes few additional log messages for
> explanatory and debugging purpose)
>
>
> Without seeing the code or knowing your topology, it's hard to extract
> meaning from the additional logged info.
>
> Though I could not capture it i the above cases, I could also see the
> following log message:
>
> *Dropping packets from non-grouped port..... *when I included the code-1 in
> the script.
>
> You should check these. If the port number is very large or negative,
> it's probably fine. If it's a sane port number, this is a problem.
>
> Does any one have a clue which triggered this issue ?
>
> The possibilities that spring to mind are:
>
> 1) It could be that your switch doesn't support sending the same buffer
> out multiple ports. The OpenFlow 1.0 spec is murky on whether this is
> required or not (earlier versions were clearer) -- the best way to find out
> now is probably to check your switch's manual.
>
> 2) The switch is doing VLAN tagging which is messing things up.
>
> Though it may well be something entirely different.
>
> -- Murphy
>
