I am not running other components. As you suggested I once again monitored
the control traffic by using wireshark to make sure there is no other
component causing the problem.
I made a simple modification in the of_mod being sent once the sw is
connected.
Instead of
action_output(port=of.OFPP_CONTROLLER))
I changed it to
action_output(port=3))
to see if the rule for controller port is causing the problem and it turned
out that Yes it is.
When the rule is set for port=of.OFPP_CONTROLLER the ARP packet is both
forwarded to controller and broadcasted in respective order (checked the
order by wireshark)
But when the rule is set for port=any_sw_data_port everything works as
expected and packet is not broadcasted.
thanks.
--
Mehmet Fatih Aktas
On Tue, May 28, 2013 at 5:05 PM, Murphy McCauley
<murphy.mccau...@gmail.com>wrote:
> Your code appears to work as you intended here (Mininet with OVS built
> from the repo somewhere around 1.9.0).
>
> Are you running other components? For example, if you're running
> l2_learning, it will see the packet-in event, assume it was due to a table
> miss, and then instruct the switch to resend it.
>
> It may help to monitor the control traffic. You can easily dump it with
> the openflow.debug component and then load it into Wireshark to view with
> the OpenFlow dissector.
>
> -- Murphy
>
> On May 28, 2013, at 1:30 PM, mehmet fatih Aktaş wrote:
>
> > Hi,
> >
> > I programmed the OF controller to send a of_mod message:
> > m = of.ofp_flow_mod()
> > m.priority = 0x7000 # Pretty high
> > m.match.dl_type = ethernet.ARP_TYPE
> > m.match.dl_dst = EthAddr("FF:FF:FF:FF:FF:FF")
> > m.idle_timeout = 100
> > m.hard_timeout = 0
> > m.actions.append(of.ofp_
> > action_output(port=of.OFPP_CONTROLLER))
> > event.connection.send(m)
> >
> > once it is connected to a switch. The goal of this is to enforce all the
> ARP requested incoming to a connected sw to be directly forwarded to the
> controller WITHOUT broadcasting the ARP in any case.
> > And when I got the reply for flow_stats for a random sw, it is showing
> that of_mod is actually set correctly e.g.
> >
> > FlowStats rxed from sw_00-00-00-00-00-01 : [{'packet_count': 0,
> 'hard_timeout': 0, 'byte_count': 0, 'duration_sec': 0, 'actions':
> [{'max_len': 65535, 'type': 'OFPAT_OUTPUT', 'port': 'OFPP_CONTROLLER'}],
> 'duration_nsec': 44000000, 'priority': 28672, 'idle_timeout': 100,
> 'cookie': 0, 'table_id': 0, 'match': {'dl_type': 'ARP', 'dl_dst':
> 'ff:ff:ff:ff:ff:ff', 'get_nw_dst': 'None', 'get_nw_src': 'None'}}]
> >
> > However, sws continue broadcasting arp reqs even though they forward
> them also to the controller. What may be the possible problem causing that,
> any idea would be greatly appreciated.
> >
> > Thanks.
> >
> > Mehmet Fatih Aktas
> > _______________________________________________
> > openflow-discuss mailing list
> > openflow-discuss@lists.stanford.edu
> > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
>
>
_______________________________________________
openflow-discuss mailing list
openflow-discuss@lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
