Yes, I cannot see a packet-out from controller as you said even though I
saw the packet-in.
If I do not the set output action for the sws at the beginning, since sw is
doing to the same thing as in when I set action_output(port=of.OFPP_
CONTROLLER)): both forwarding to controller and broadcasting.
I am doing this experiment by using mininet (the one inside the VM), I
could not find which OVS version installed.
I know we can update the OVS in mininet, but I am not sure if it is going
to worth the effort.
--
Mehmet Fatih
On Tue, May 28, 2013 at 7:12 PM, Murphy McCauley
<murphy.mccau...@gmail.com>wrote:
> 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
