I think there is absolutely a problem with switch configuration.
Considering the case I tried:
When I send action_output(port=of.OFPP_ FLOOD)), in stats reply 'port':
'OFPP_ALL'
I checked the OF SW 1.0.0 Specs to see if the numbers assigned to
definitions OFPP_ FLOOD .... etc. in file libopenflow_01.py and they are
correct.
But as you said there is probably a configuration problem with OVS mininet
is currently using.
Is there any guide to easily update mininet OVS, a link would be greatly
appreciated.
Otherwise I will try to find a workaround by using ofp_port_mod() but it is
not going to be beautiful.
Thanks
Mehmet Fatih
On Wed, May 29, 2013 at 11:31 AM, mehmet fatih Aktaş
<mfatihak...@gmail.com>wrote:
> 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
