Software Defined Networking
1751794 Members
4921 Online
108781 Solutions
New Discussion

Measure port stats over shorter duration?

 
Dave-B
Frequent Advisor

Measure port stats over shorter duration?

I have a use case where I want to measure the RX and TX rate over each physical link over a short time period, to determine the remaining capacity on the link.

 

The REST API  /sdn/v2.0/of/stats/ports command gives me rx_bytes and  tx_bytes, but the measurement seems to be over a long duration, e.g.

 

duration_sec":4294967295,"duration_nsec":4294967295

 

I presume the rx_byte and tx_byte count is over the last 4294967295 seconds.

 

Is it possible to reset the duration or set a much shorter duration, e.g. 5 seconds?

 

The REST API for /sdn/v2.0/of/stats/ports only lists GET commands.

 

Dave.

13 REPLIES 13
sdnindia
Trusted Contributor

Re: Measure port stats over shorter duration?

Hello Dave,

 

Apologies for late delay. Please follow below steps and let us know if this solves your problem-

  1. Open SDN UI page and click on Configurations item [ i.e. https://Controller_IP:8443/sdn/ui/app/index#configs]
  2. Click on com.hp.sdn.ctl.of.impl.TraceManager and click on Modify.
  3. There you can modify the value for record.duration .
  4.  Select “OpenFlow Trace” category and click the “Start recording”, this will start TX&RX recording according to the duration setup as in step 3.

 

      Note :  The TX & RX statistics results are just simple data list, not as rich as RSAPI responses, hope this can help you currently.

 

Thanks,

HP SDN Team

sdnindia
Trusted Contributor

Re: Measure port stats over shorter duration?

Hi Dave,

Doing a follow up to see if previous post helps you.
Please let us know if your problem is solved or you still have some problem.

Thanks,
HP SDN Team

Dave-B
Frequent Advisor

Re: Measure port stats over shorter duration?

Thanks for the reply, only just checked back.

 

I changed the measurement duration and started , but the rx_packets, tx_packets, rx_bytes and tx_bytes values available through port stats appear to be cumulative and are never reset.

 

e.g. If I read the port stas for a switch, change the TraceManager duration to 1 second and then read the stats again:

 

$ curl -sk -H "X-Auth-Token: XXXXXXXXXXXXXXXXX" https://localhost:8443/sdn/v2.0/of/stats/ports?dpid="00:02:c8:cb:b8:3e:fe:40"
{"stats":[{"dpid":"00:02:c8:cb:b8:3e:fe:40","version":"1.3.0","port_stats":[{"port_id":25,"rx_packets":42433489,"tx_packets":962417,"rx_bytes":64250654185,"tx_bytes":81289883,"rx_dropped":0,"tx_dropped":0,"rx_errors":0,"tx_errors":0,"collisions":0,"duration_sec":4294967295,"duration_nsec":4294967295,"rx_crc_err":0,"rx_frame_err":0,"rx_over_err":0}

 

Set Configuration / com.hp.sdn.ctl.of.impl.TraceManager to 1 second
Strarted Openflow Trace
14:54:53.056 MX_CHECKPOINT Recording started [1s]

 

$ curl -sk -H "X-Auth-Token: XXXXXXXXXXXXXXXXX" https://localhost:8443/sdn/v2.0/of/stats/ports?dpid="00:02:c8:cb:b8:3e:fe:40"
{"stats":[{"dpid":"00:02:c8:cb:b8:3e:fe:40","version":"1.3.0","port_stats":[{"port_id":25,"rx_packets":48901389,"tx_packets":1523378,"rx_bytes":74066600037,"tx_bytes":120561103,"rx_dropped":0,"tx_dropped":0,"rx_errors":0,"tx_errors":0,"collisions":0,"duration_sec":4294967295,"duration_nsec":4294967295,"rx_crc_err":0,"rx_frame_err":0,"rx_over_err":0}

The rx_packets, tx_packets, rx_bytes and tx_byte are too large to be measured over 1 second and always increase.

I do not think the values have been reset since I powered on the switch.

 

Is there some way to reset the stats, or is this something determined by the switch firmware?

 

Dave.

 

Gerhard Roets
Esteemed Contributor

Re: Measure port stats over shorter duration?

Hi Dave

 

I am in the process of investigating your request there is multiple anlges that I am looking into. I will keep you posted.

 

Kind Regards

Gerhard

HP SDN Team

Gerhard Roets
Esteemed Contributor

Re: Measure port stats over shorter duration?

Hi Dave

First let’s start with what duration_sec and duration_nsec is the time since this OpenFlow switch port was active. These are not intervals but the time at what this sample was collected. This is to enable the user to eliminate the latency in the OpenFlow control channel exchange. If you query this via REST this will add even more latency.

 

The point in time can be calculated as follow: The total duration in nanoseconds can be computed as duration_sec*10^9+duration nsec ( Or in terms of seconds duration_sec.duration_nsec*10^-9).

 

As an example Assume duration_sec=9 and duration_nsec=1,000,000 then this would be

90,000,000,001,000,000 nanoseconds or 9.000,1 seconds

 

Note that the minimum required accuracy required by the OpenFlow spec is 1 sec.

 

Note the data for the number of bytes and packets on a port is not being reset when being queried.

 

Based on the data supplied and other forum questions you posted this looks like you are using Provision switches. Currently there is an issue that is being worked on since the values returned duration_sec":4294967295," and duration_nsec":4294967295 is incorrect. This will be fixed in a future version of software. Be aware that these timers can be reset to zero under certain circumstances like rebooting a switch or interface module.

 

The port stats is typically tied to the physical port interface so it might not always be the best object to measure unless it is used exclusively for OpenFlow related traffic. On some switches you can reset the interface counters to zero, but this will not reset the duration counters which might lead to other anomalies especially if you are going to compare this to meter counters for instance. On the Provision switches the command is “clear statistics global”. Personally I prefer not to reset counters but always compare differences.

 

The logic below is generic for any switch that supports this.

The logic is as follows under normal circumstances

  1. Collect sample one and store the counters of interest including the duration values
  2. Also store the system time at which you collected this
  3. Sleep for the sample interval
  4. Collect sample two and store the counters of interest including the duration values
  5. Also store the system time at which you collected this

Now at this point you can subtract the sample one values from the sample two values.

You can calculate the interval over which this took place, and you can compare it to the system time interval and account for anomalies based on this for instance counters being reset or something similar, and enable you to take appropriate action.

 

As a workaround for the issue mentioned above while the issue mentioned for duration_sec and duration_nsec is being worked on simply base the calculation on the system time. You will need to account for latency when using this option or just be aware of it.

 

Sample of the exercise (I am using a switch that return duration_sec and duration_nsec correctly). I will transmit about 1000 frames of 640 bytes each over this interval. I used a packet generator for this.

dpid is my datapath id tok is my x-auth-token

gpr@sdn1:~$ curl --header "X-Auth-Token:$tok" --header "Content-Type:application/json" --fail -ksS --request GET --url https://10.128.10.9:8443/sdn/v2.0/of/stats/ports?dpid=$dpid\&port_id=2 | python -mjson.tool

{

   "stats": [

       {

           "dpid": "10:00:00:9c:02:d6:83:80",

           "port_stats": [

               {

                   "collisions": 0,

                   "duration_nsec": 15966126,

                   "duration_sec": 3892,

                    "port_id": 2,

                   "rx_bytes": 0,

                   "rx_crc_err": 0,

                   "rx_dropped": 0,

                   "rx_errors": 0,

                   "rx_frame_err": 0,

                   "rx_over_err": 0,

                    "rx_packets": 0,

                   "tx_bytes": 48015,

                   "tx_dropped": 0,

                   "tx_errors": 0,

                   "tx_packets": 414

               }

           ],

           "version": "1.3.0"

       }

   ]

}

gpr@sdn1:~$ date +%s%N

1407514765158335470

 

>>>> Inject packets here

 

gpr@sdn1:~$ curl --header "X-Auth-Token:$tok" --header "Content-Type:application/json" --fail -ksS --request GET --url https://10.128.10.9:8443/sdn/v2.0/of/stats/ports?dpid=$dpid\&port_id=2 | python -mjson.tool

{

   "stats": [

       {

           "dpid": "10:00:00:9c:02:d6:83:80",

           "port_stats": [

               {

                   "collisions": 0,

                   "duration_nsec": 699442120,

                   "duration_sec": 3924,

                    "port_id": 2,

                   "rx_bytes": 640000,

                   "rx_crc_err": 0,

                   "rx_dropped": 0,

                   "rx_errors": 0,

                   "rx_frame_err": 0,

                   "rx_over_err": 0,

                   "rx_packets": 1000,

                   "tx_bytes": 48872,

                   "tx_dropped": 0,

                   "tx_errors": 0,

                   "tx_packets": 423

               }

           ],

           "version": "1.3.0"

       }

   ]

}

gpr@sdn1:~$ date +%s%N

1407514797295400313

 

Sample 1

Duration1 = 3892 + 15966126*10^-9 = 3892.015966126 seconds

BytesRX1 = 0

PacketRX1 = 0

Systime1 = 1407514765158335470 nanoseconds = 1407514765.15833547 seconds

 

Duration2 = 3924 + 699442120*10^-9 = 3924.69944212 seconds

BytesRX2 = 640000

PacketRX2 = 1000

Systime2 = 1407514797295400313 nanoseconds = 1407514797.295400313 seconds

 

Duration_delta=32.683475994

BytesRX_delta=640000

PacketsRX_delta=1000

Systime_delta=32.137064843

The difference between Systime_delta and Duration_delta is not that big and I know I used the up arrow to enter the commands so I am happy with that.

 

This then gives me the following based on duration from the switch, I rounded these numbers.

BytesRX/sec = 19582 bytes per second

PacketsRX/sec = 31 packets per second

I hope this helps explain this.

 

I hope this helps explain this

 

Gerhard Roets

HP SDN Team

Dave-B
Frequent Advisor

Re: Measure port stats over shorter duration?

Hi Gerhard,

 

I  have split my switches using Non SDN and SDN VLANs.

Ports 1 -  2 = Non SDN

Ports 3 - 26 = SDN VLAN

 

I´m seeing 2 separate issues.

 

 

1) When I specify the port_id, the rest interfaces reports for the wrong port id. The port id is out by 2, the number of ports in the non SDN VLAN.

 

e.g. I am actively using ports 11, 25, 26 in my SDN VLAN.

 

curl -sk -H "X-Auth-Token: $Token" --header "Content-Type:application/json" --request GET --url https://localhost:8443/sdn/v2.0/of/stats/ports?dpid="00:02:c8:cb:b8:3e:fe:40"\&port_id="11"
{"stats":[{"dpid":"00:02:c8:cb:b8:3e:fe:40","version":"1.3.0","port_stats":[{"port_id":13,"rx_packets":0,"tx_packets":0,"rx_bytes":0,"tx_bytes":0,"rx_dropped":0,"tx_dropped":0,"rx_errors":0,"tx_errors":0,"collisions":0,"duration_sec":4294967295,"duration_nsec":4294967295,"rx_crc_err":0,"rx_frame_err":0,"rx_over_err":0}]}]}

curl -sk -H "X-Auth-Token: $Token" --header "Content-Type:application/json" --request GET --url https://localhost:8443/sdn/v2.0/of/stats/ports?dpid="00:02:c8:cb:b8:3e:fe:40"\&port_id="25"
{"error":"com.hp.api.NotFoundException","message":"No such port: 0x19"}
curl -sk -H "X-Auth-Token: 2d9a3crequest GET --url https://localhost:8443/sdn/v2.0/of/stats/ports?dpid="00:02:c8:cb:b8:3e:fe:40"\&port_id="26"
{"error":"com.hp.api.NotFoundException","message":"No such port: 0x1a"}

 

curl -sk -H "X-Auth-Token: $Token" https://192.168.40.200:8443/sdn/v2.0/of/datapaths/00:02:c8:cb:b8:3e:fe:40/ports
{"version":"1.3.0","ports":[{"id":3,"name":"3","mac":"c8:cb:b8:3e:fe:7d","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":4,"name":"4","mac":"c8:cb:b8:3e:fe:7c","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":5,"name":"5","mac":"c8:cb:b8:3e:fe:7b","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":6,"name":"6","mac":"c8:cb:b8:3e:fe:7a","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":7,"name":"7","mac":"c8:cb:b8:3e:fe:79","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":8,"name":"8","mac":"c8:cb:b8:3e:fe:78","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":9,"name":"9","mac":"c8:cb:b8:3e:fe:77","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":10,"name":"10","mac":"c8:cb:b8:3e:fe:76","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":11,"name":"11","mac":"c8:cb:b8:3e:fe:75","current_speed":3567587328,"max_speed":3567587328,"config":[],"state":["live"],"current_features":["rate_1gb_fd","rate_1tb_fd"],"advertised_features":[],"supported_features":["rate_10mb_hd","rate_10mb_fd","rate_100mb_hd","rate_100mb_fd","rate_1gb_fd","rate_1tb_fd"],"peer_features":[]},{"id":12,"name":"12","mac":"c8:cb:b8:3e:fe:74","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":13,"name":"13","mac":"c8:cb:b8:3e:fe:73","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":14,"name":"14","mac":"c8:cb:b8:3e:fe:72","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":15,"name":"15","mac":"c8:cb:b8:3e:fe:71","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":16,"name":"16","mac":"c8:cb:b8:3e:fe:70","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":17,"name":"17","mac":"c8:cb:b8:3e:fe:6f","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":18,"name":"18","mac":"c8:cb:b8:3e:fe:6e","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":19,"name":"19","mac":"c8:cb:b8:3e:fe:6d","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":20,"name":"20","mac":"c8:cb:b8:3e:fe:6c","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":21,"name":"21","mac":"c8:cb:b8:3e:fe:6b","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":22,"name":"22","mac":"c8:cb:b8:3e:fe:6a","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":23,"name":"23","mac":"c8:cb:b8:3e:fe:69","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":24,"name":"24","mac":"c8:cb:b8:3e:fe:68","config":[],"state":["link_down"],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]},{"id":25,"name":"25","mac":"c8:cb:b8:3e:fe:67","current_speed":3567587328,"max_speed":3567587328,"config":[],"state":["live"],"current_features":["rate_10gb_fd","rate_1tb_fd"],"advertised_features":[],"supported_features":["rate_1gb_fd","rate_10gb_fd","rate_1tb_fd"],"peer_features":[]},{"id":26,"name":"26","mac":"c8:cb:b8:3e:fe:66","current_speed":3567587328,"max_speed":3567587328,"config":[],"state":["live"],"current_features":["rate_10gb_fd","rate_1tb_fd"],"advertised_features":[],"supported_features":["rate_1gb_fd","rate_10gb_fd","rate_1tb_fd"],"peer_features":[]},{"id":4294967294,"name":"local","mac":"c8:cb:b8:3e:fe:40","config":[],"state":[],"current_features":[],"advertised_features":[],"supported_features":[],"peer_features":[]}]}

 

 

If I subtract 2 from my specified port (use port_id=9, instead of port 11, I get stats for port 11

curl -sk -H "X-Auth-Token: $Token" --header "Content-Type:application/json" --request GET --url https://localhost:8443/sdn/v2.0/of/stats/ports?dpid="00:02:c8:cb:b8:3e:fe:40"\&port_id="9"
{"stats":[{"dpid":"00:02:c8:cb:b8:3e:fe:40","version":"1.3.0","port_stats":[{"port_id":11,"rx_packets":5163461,"tx_packets":57540915,"rx_bytes":361358686,"tx_bytes":86512752444,"rx_dropped":0,"tx_dropped":0,"rx_errors":0,"tx_errors":0,"collisions":0,"duration_sec":4294967295,"duration_nsec":4294967295,"rx_crc_err":0,"rx_frame_err":0,"rx_over_err":0}]}]}

 

 

 

2) The duration never changes

$ date
Wed Aug 13 12:04:50 BST 2014
$ curl -sk -H "X-Auth-Token: 2d9a3c4d9bcf44809c6fa69a1cd174e9" --header "Content-Type:application/json" --request GET --url https://localhost:8443/sdn/v2.0/of/stats/ports?dpid="00:02:c8:cb:b8:3e:fe:40"\&port_id="9"
{"stats":[{"dpid":"00:02:c8:cb:b8:3e:fe:40","version":"1.3.0","port_stats":[{"port_id":11,"rx_packets":5163461,"tx_packets":57540981,"rx_bytes":361358686,"tx_bytes":86512766062,"rx_dropped":0,"tx_dropped":0,"rx_errors":0,"tx_errors":0,"collisions":0,"duration_sec":4294967295,"duration_nsec":4294967295,"rx_crc_err":0,"rx_frame_err":0,"rx_over_err":0}]}]}


>> sent some datat

$ date
Wed Aug 13 12:06:55 BST 2014
curl -sk -H "X-Auth-Token: 2d9a3c4d9bcf44809c6fa69a1cd174e9" --header "Content-Type:application/json" --request GET --url https://localhost:8443/sdn/v2.0/of/stats/ports?dpid="00:02:c8:cb:b8:3e:fe:40"\&port_id="9"
{"stats":[{"dpid":"00:02:c8:cb:b8:3e:fe:40","version":"1.3.0","port_stats":[{"port_id":11,"rx_packets":5303048,"tx_packets":59131575,"rx_bytes":371129708,"tx_bytes":88926719002,"rx_dropped":0,"tx_dropped":0,"rx_errors":0,"tx_errors":0,"collisions":0,"duration_sec":4294967295,"duration_nsec":4294967295,"rx_crc_err":0,"rx_frame_err":0,"rx_over_err":0}]}]}

 

Both port stat measurements have

duration_sec":4294967295,"duration_nsec":4294967295

 

I don´t know if this is related to having 2 VLANS?

 

 

Dave.

 

 

Dave-B
Frequent Advisor

Re: Measure port stats over shorter duration?

Gerhard,

 

If I move all the switch ports into VLAN 2, my SDN VLAN and hard reboot the switch, then individual port_id reads give the correct port_id stats response, e.g.

 

$ curl -sk -H "X-Auth-Token: $Token" --header "Content-Type:application/json" --request GET --url https://localhost:8443/sdn/v2.0/of/stats/ports?dpid="00:02:c8:cb:b8:3e:fe:40"\&port_id="11" {"stats":[{"dpid":"00:02:c8:cb:b8:3e:fe:40","version":"1.3.0","port_stats":[{"port_id":11,"rx_packets":3,"tx_packets":89,"rx_bytes":192,"tx_bytes":17444,"rx_dropped":0,"tx_dropped":0,"rx_errors":0,"tx_errors":0,"collisions":0,"duration_sec":4294967295,"duration_nsec":4294967295,"rx_crc_err":0,"rx_frame_err":0,"rx_over_err":0}]}]}

 

However, the duration values still do not change.

 

Do I have to enable some sort of port measurments in the normal switch OS, through the command line interface?

 

Any thoughts on what is needed?

 

Dave.

 

Gerhard Roets
Esteemed Contributor

Re: Measure port stats over shorter duration?

Hi Dave

 

With regards to the port offset. I will need to dig into that one a bit

With regards to to the duration values. That is an issue that has been reported and will be fixed in a future software release for the switches.

 

Kind Regards

Gerhard

 

Gerhard Roets
Esteemed Contributor

Re: Measure port stats over shorter duration?

Hi Dave

 

With regards to the missallingned port-stats.

 

I reproduced you issue and found I do not see the issue in KA.15.15.0006. If you are running an earlier version would you mind giving the update software a try and tell me if it works.

 

https://h10145.www1.hp.com/Downloads/SoftwareReleases.aspx?ProductNumber=J9573A&lang=en&cc=us&prodSeriesId=1827663

 

Kind Regards

Gerhard