Strangely we are seeing a terrible throughput drop when packets are matched
(by IP header)
and then modified and sent out through a different egress port (basically
NATting packets).
Line rates of the interfaces are 1 Gbps, but when we turn on the openflow
mode and
matched packets are forwarded through a different port (after their
source/destination IP addresses
are modified), their speed drastically drops to about 700 Kbps (99% drop in
throughput).
Regards
Sambuddho Chakravarty
On Thu, Jul 13, 2017 at 1:53 PM, Oleg Sadov <oleg.sa...@gmail.com> wrote:
> In fact, it depends on which fields are used in the match for HP switches:
>
> http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c03991489-1.pdf
>
> For ex. in HP 3500 yl MACs handled by software level, but IP address for
> IP Eth type (0x800) -- in hardware. As a consequence -- switching form MAC
> to IP matching can increase the throughput for such OF switches.
>
> 2017-07-13 8:56 GMT+03:00 Chaitanya Kumar <chaitanya12...@iiitd.ac.in>:
>
>> Hi
>>
>> We are working on a research project that involves HP OpenFlow enabled
>> switch (HP 3500 yl). We are facing some issues with performance
>> particularly when operating the switch in "OpenFlow" mode. The switch is
>> controlled via a desktop running the Ryu controller.
>>
>> The rules on the switch match packets based on the fields supported by
>> OpenFlow. Further, the switch also modifies a certain IP header field
>> (in this case the ToS bits) for packets that match the rules and are hence
>> forwarded.
>>
>> More precisely, the rules match the ToS bits of the packet and change
>> them to a different value before forwarding them to a chosen host.
>>
>> However, in the process, the forwarded packets achieve a throughput of no
>> more than 700kbps, while the source and destination hosts have 100 Mbit/s
>> Ethernet ports. If we disable "OpenFlow" mode and use it as it is then we
>> achieve a full throughput of 100Mbit/s (the Ethernet link speeds of the
>> client and server hosts). The end-to-end throughput was measured using
>> *iperf*.
>>
>> Could someone shed some light on the reason for this drastic performance
>> degradation? (all the switch does is match packets whose ToS value is
>> (say,) 0x28 and replaces it with 0x40 before forwarding them to the right
>> destination)
>>
>> Also, is there an alternative switch that someone has used successfully
>> for similar things?
>>
>>
>> A figure showing our experiment scenario is given below, for reference.
>>
>>
>>
>>
>> Thanks,
>>
>> Chaitanya
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Ryu-devel mailing list
>> Ryu-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>>
>>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
