OF 1.3.3 spec (7.2.3.5 Flow Match Field Masking) says:
An all-zero-bits oxm_mask is equivalent to omitting the OXM TLV entirely.
An all-one-bits oxm_mask
is equivalent to specifying 0 for oxm_hasmask and omitting oxm_mask.
This patch fixes to compare OFPMatch ignoring fields that masks a
OF 1.3.3 spec (3 Glossary) says:
Flow Entry: an element in a flow table used to match and process packets.
It contains a set of
match fields for matching packets, a priority for matching precedence, a
set of counters to track
packets, and a set of instructions to apply (see 5.2).
Ac
OF 1.3.3 spec (7.2.3.5 Flow Match Field Masking) says:
An all-zero-bits oxm_mask is equivalent to omitting the OXM TLV entirely.
An all-one-bits oxm_mask
is equivalent to specifying 0 for oxm_hasmask and omitting oxm_mask.
This patch fixes to compare OFPMatch ignoring masks that are all
Hi,
On Fri, 11 Apr 2014 12:48:35 +0200
Hanieh Rajabi wrote:
> Since I have added extra functionality to my openflow 1.3, I need the
> controller app send the feature request to the switch to inquiry about the
> new added feature.
> But by running
>
> @set_ev_cls(ofp_event.EventOFPSwitchFeature
Thanks :-)
(2014/04/15 10:50), FUJITA Tomonori wrote:
> On Thu, 6 Mar 2014 19:14:56 +0900
> Hiroaki KAWAI wrote:
>
>> i-tagged packets will have ETH_TYPE=0x88E7. The tests are
>> rewritten in the same way with MPLS.
>
> Really sorry about the delay. I've just merged this patch.
>
> Thanks a l
On Thu, 6 Mar 2014 19:14:56 +0900
Hiroaki KAWAI wrote:
> i-tagged packets will have ETH_TYPE=0x88E7. The tests are
> rewritten in the same way with MPLS.
Really sorry about the delay. I've just merged this patch.
Thanks a lot!
--
Hi,
On Wed, 9 Apr 2014 12:04:17 +0800
arne_goetje wrote:
> I noticed that the PBB packet tests, in contrast to the MPLS packet tests
> (i.e. those tests where you send PBB packets from the packet generator),
> currently get matched against their encapsulated payload, while the MPLS
> packets
Hi,
Thanks for pointing out the issue,
On Wed, 9 Apr 2014 11:57:52 +0800
arne_goetje wrote:
> I noticed that in some cases (e.g. vlan_vid, ipv4_src, ipv4_dst, etc.)
> when the flow-mod did not specify any mask value (e.g. IPv4 host IP =/32
> mask), the switch still adds this mask and returns
> Hi guys,
> I am doing a project in RYU controller.I want to modify the
> source mac and ip address of the packet in the controller. SO i request you
> to send me a sample code or send me the details how to modify it.
> Thank you in advance,
using packet libra
> Dear all,
>
> I have tried the past days to set up a test environment to reproduce the
> compliance tests with our switching hardware. Without success so far.
> I have Ryu 3.7 running on a KVM instance (Ubuntu 14.04) with Openvswitch
> 2.1 either in the same VM or on the host machine (I tried
> I have slightly modified the simple_switch.py to print out switch and link
> information using
>
> ryu.topology.api.get_all_switch(switch)
> AND
> ryu.topology.api.get_all_link(switch)
>
> The above two functions are defined in ryu/topology/api.py
>
> {noformat}
>@set_ev_cls(ofp_event.Even
Hi guys,
I am doing a project in RYU controller.I want to modify the
source mac and ip address of the packet in the controller. SO i request you
to send me a sample code or send me the details how to modify it.
Thank you in advance,
With Regards,
Sarath Allaka
I have slightly modified the simple_switch.py to print out switch and link
information using
ryu.topology.api.get_all_switch(switch)
AND
ryu.topology.api.get_all_link(switch)
The above two functions are defined in ryu/topology/api.py
{noformat}
@set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DIS
Dear all,
I have tried the past days to set up a test environment to reproduce the
compliance tests with our switching hardware. Without success so far.
I have Ryu 3.7 running on a KVM instance (Ubuntu 14.04) with Openvswitch
2.1 either in the same VM or on the host machine (I tried both setups)
> Ah I see.Thanks for the explanation. I have one more question to ask
>
> I want to do something similar to the following from simple_switch.py
> application
>
> sw_list = ryu.topology.api.get_all_switch(self)
> link_list = ryu.topology.api.get_all_links(self)
>
> I basically want to modify m
Ah I see.Thanks for the explanation. I have one more question to ask
I want to do something similar to the following from simple_switch.py
application
sw_list = ryu.topology.api.get_all_switch(self)
link_list = ryu.topology.api.get_all_links(self)
I basically want to modify my program so as to
>
> On Apr 8, 2014, at 11:54 PM, YAMAMOTO Takashi wrote:
>
>> there are a few ways to use ryu+openstack.
>>
>> a. "ryu" plugin
>>it uses openflow 1.0 and depends on ovs features.
>>(nicira extensions, ovsdb, ...)
>>
>> b. "ofagent" ml2 mech driver
>>while it aims to support pure op
> I tried again and I am seeing the same result.i.e port 6633 being opened by
> the controller.
>
> But once I connect the topology of switches(mininet) to ryu "OpenFlow
> Controller" (ryu-manager ryu/app/simple_switch.py).
>
> I see a lot of packet_in messages in the controller.what is the reaso
I tried again and I am seeing the same result.i.e port 6633 being opened by
the controller.
But once I connect the topology of switches(mininet) to ryu "OpenFlow
Controller" (ryu-manager ryu/app/simple_switch.py).
I see a lot of packet_in messages in the controller.what is the reason for
this?
I
19 matches
Mail list logo
