FYI In the readme that comes with the HP switch it says:
When a rule is instantiated in hardware, full statistics are
no longer available for that rule. The following restrictions apply :
o byte_count is not available (software byte count only)
o statistics are updated at a large period interval
o flow_duration is larger than actual flow duration
On Sun, Oct 2, 2011 at 5:05 PM, Aaron Rosen <[email protected]> wrote:
> Hi Srini,
>
> nw_proto is set in what I pasted ..idle_timeout=5,hard_timeout=0,*udp*
> ,in_port=39,...
>
> Though you are right it seems that the dl_type is not set. In my controller
> I'm setting it so I'm not sure why it isn't showing up (I can confirm with
> wireshark) but it also seems like dpctl is not able to set the dl_type
> either. See below.
>
> Thanks,
>
> Aaron
>
> arosen@arosen-desktop ~ $ dpctl del-flows tcp:130.127.39.135:8888
> arosen@arosen-desktop ~ $ dpctl dump-flows tcp:130.127.39.135:8888
> stats_reply (xid=0x9418bd12): flags=none type=1(flow)
> arosen@arosen-desktop ~ $ dpctl add-flow
> tcp:130.127.39.135:8888idle_timeout=20,hard_timeout=222,
> *udp*,in_port=39,dl_src=00:1b:21:75:7a:92,dl_dst=00:1b:21:43:a1:e4,*
> dl_type=0x0800*
> ,nw_src=10.43.100.14,nw_dst=10.43.100.15,tp_dst=5001,actions=output:36
> arosen@arosen-desktop ~ $ dpctl dump-flows tcp:130.127.39.135:8888
> stats_reply (xid=0x96c5d0c7): flags=none type=1(flow)
> cookie=0, duration_sec=1s, duration_nsec=690000000s, table_id=0,
> priority=32768, n_packets=0, n_bytes=0,
> idle_timeout=20,hard_timeout=222,udp,in_port=39,dl_src=00:1b:21:75:7a:92,dl_dst=00:1b:21:43:a1:e4,nw_src=10.43.100.14,nw_dst=10.43.100.15,tp_dst=5001,actions=output:36
>
>
> On Sun, Oct 2, 2011 at 4:33 PM, Srini Seetharaman
> <[email protected]>wrote:
>
>> In your flow entry, I do not see that the dl_type and nw_proto are
>> set. It is possible that the switch is fwding the packets in software.
>> That would explain the discrepancy. I think the counts work
>> differently with the HP Procurve based on whether the flow is switched
>> in hardware or software.
>>
>> On Sun, Oct 2, 2011 at 1:11 PM, Rob Sherwood <[email protected]>
>> wrote:
>> > There is clearly something wrong with the output, because the number
>> > of packets (307696) is greater than the number of bytes (84672).
>> >
>> > I would talk to the HP folks with this - my guess is this is a
>> > firmware/architecture issue.
>> >
>> > - Rob
>> > .
>> >
>> > On Sun, Oct 2, 2011 at 12:31 PM, Aaron Rosen <[email protected]>
>> wrote:
>> >> Hello,
>> >> I'm trying to determine the throughput of a flow at each switch in a
>> >> network. Currently I'm just playing with dpctl to try and get this
>> >> information. Right now I'm sending a 10Mbit/sec udp stream into one of
>> my
>> >> switches. When I dump the flow out I get the following output:
>> >>
>> >> cookie=0, duration_sec=364s, duration_nsec=586000000s, table_id=0,
>> >> priority=65535, n_packets=307696, n_bytes=84672,
>> >>
>> idle_timeout=5,hard_timeout=0,udp,in_port=39,dl_vlan=0xffff,dl_vlan_pcp=0x00,dl_src=00:1b:21:75:7a:92,dl_dst=00:1b:21:5a:e6:a9,nw_src=10.42.15.104,nw_dst=10.42.15.55,nw_tos=0x00,tp_src=51661,tp_dst=5001,actions=output:43
>> >>
>> >> From this I would expect the throughput to be
>> ((84672*8)/(1000000))/364.
>> >> Though this is not correct. It seems the n_bytes counter is incorrect
>> and
>> >> does not update along side with the n_packets counter.
>> >> The n_packets counter seems to be correct
>> >> though (307696*1470*8)/(1000000)/364 = ~9.94Mbit/sec (Note where 1470
>> is
>> >> the mtu).
>> >> Is there another method for getting this information? In my application
>> I'm
>> >> sure I'm not going to be always transmitting at the MTU value.
>> >> Thanks,
>> >> Aaron
>> >> P.S: The switch I'm using is a HP procurve with the latest OF firmware.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Aaron O. Rosen
>> >> Masters Student - Network Communication
>> >> 306B Fluor Daniel
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> openflow-discuss mailing list
>> >> [email protected]
>> >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
>> >>
>> >>
>> > _______________________________________________
>> > openflow-discuss mailing list
>> > [email protected]
>> > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
>> >
>>
>
>
>
> --
> Aaron O. Rosen
> Masters Student - Network Communication
> 306B Fluor Daniel
>
>
>
--
Aaron O. Rosen
Masters Student - Network Communication
306B Fluor Daniel
_______________________________________________
openflow-discuss mailing list
[email protected]
https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
