Collecting H3C NetStream info with Scrutinizer

[mciecior]

I have two H3C routers exporting NetStream data via udp/9995 to my Scrutinizer collector (which currently supports about 20 Cisco routers via udp/2055).

Scrutinizer accurately shows inbound flows on all the necessary interfaces, but no outbound traffic. I've confirmed that the router is configured to export both inbound and outbound traffic on both the WAN and LAN interfaces.

Is there something else I need to configure within Scrutinizer to see the inbound and outbound traffic? I'd like to view this NetStream info the same way I view all the other NetFlow information from my Cisco devices.

Thanks,
Mark

[BenjaminM]

Hello mciecior,

To accurately troubleshoot this issue I will need to ask you to give me some more data.

NetStream can come in v5/8/9 - Can you send us the NetStream configuration for this device?

Also, what version of Scrutinizer are you running at the moment?

Thank you,
Ben

[mciecior]

I don't have management access to the H3C routers, unfortunately. I know NetStream v9 is configured on both routers.

My Scrutinizer version is 8.0.2.12007

[BenjaminM]

Hi mciecior,

Do you have an application called wireshark? It is a protocol analyzer that will help us investigate this issue with the NetStream more in depth. You can download it from this website -
http://www.wireshark.org/

If you open it and click start you should be able to filter for the device you are looking for. You may have to run wireshark for up to 30 minutes to make sure you are capturing the templates.

If you take a look at this interface, can you copy and paste what wireshark displays?

Thank you,
Ben

[mciecior]

http://www.cloudshark.org/captures/42808d711e60

I filtered on just one of the H3C routers.

[mkrygeri]

Thanks. Looking at this pcap, it looks as if there are only flows ingress on interface index 15 to interface index 14. This explains why you are seeing only inbound on that interface.

This usually means that ingress netflow is not enabled on that interface (14).

Is it possible that someone missed a configuration option?

[mciecior]

Excellent, that's the detail I've been looking for. I'll ask them to check their side again to be sure.

How are you parsing the NetStream data? Do you know of a WireShark dissector for NetStream? I could give the other party much more damning evidence if I could show the ifindex's involved.

[mkrygeri]

Netstream is nothing more than regular netflow. You just need to right-click on one of the packets, choose "decode as", choose the UDP destination port you are using and choose CFLOW as the protocol you want to decode as.

This doesn't work on CloudShark. You have to use the WireShark application.

Please let me know ff you find this is a bug with netstream. We can make sure it is documented on our side as well.

[mciecior]

I see now that the first capture only showed unidirectional traffic. I think that's due to a misconfiguration on that particular router. I ran another capture from my Scrutinizer server, collecting all NetStream traffic from another H3C router (which is clearly sending bidirectional traffic).

I've attached a screenshot of that capture (http://www.cloudshark.org/captures/a25df815b6d0). The Input_int and Output_Int columns reference the cflow.inputint and cflow.outputint filters, respectively. The Scrutinizer server looks to be receiving bidirectional NetStream data. Yet when I look at interfaces 1 and 15 via Scrutinizer I see *only* inbound traffic on interface 15 and *only* outbound traffic on interface 1.

Looking into the CFLOW payload within WireShark, all the flows from interface 1 to 15 have a Data Flowset/Template ID of 3282, and all the flows from 15 to 1 have a Data Flowset/Template ID of 3281.

It looks to me like I'm now receiving bidirectional flow data (whereas I may not have been before). Scrutinizer is still only showing one direction. What else am I missing?

Thanks,
Mark

[mkrygeri]

Hi Mark,
We've evaluated the packet captures and we've isolated the problem. Without going too deeply into what is going on, it seems that H3C is using a different "info element" for egress traffic flow out octets.
Normally, vendors use the normal octets counter for both ingress and egress traffic all of this is contained in a single template data set. In this case, they are exporting 2 different data-sets. They are still sticking by the "rules" by doing thins this way, but it is the first time we have encountered it.

We are collecting the data being exported, but we don't support the "post out octets" info element with our standard reports.

I spoke with the lead engineer for our reporting engine, and he said he would be willing to build you a few reports to help you work around this and get the data you need. He is also going to contact H3C engineering and try and see if we can broaden our support for their gear.

I would like to get a list of reports that you commonly use.

I will PM you my contact info if you would like to correspond directly with me regarding this issue.

-Mike K