When you monitor the control traffic, you obviously see a packet-in from the
switch carrying the ARP packet. But you never see a packet-out going back from
the controller, right?
When you set the output port to some real port number, I assume you then see
the packet coming out that port, but NOT the rest of the ports (like you do
when you are sending to the OFPP_CONTROLLER port). What if you remove the
output action altogether?
Offhand, this sounds like a problem with the switch or configuration
(especially since it seems to work correctly here). What switch are you using?
Can you try a different/more recent version of it or its firmware?
-- Murphy
On May 28, 2013, at 3:14 PM, mehmet fatih Aktaş wrote:
> 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
