CoreyMac

How goes the performance and testing with the release of NTA v3.0 SP2? I assume it is not ready yet or someone would have said something...

We are giving up. Our NetFlow service must now be disabled until a fix is found. NetFlow V3 with or without SP1 is causing so many performance and timeout issues with deadlocked processes, a SQL server that grinds to a halt due to the large number of I/Os, etc... We get timeouts on startup with the services, also VoIP and…

Indirectly. What we are seeing is an increase in I/Os. This SQL server we are hitting now is very small and would have a much busier CPU if the I/O subsystem could handle more workload. Possibly it is too small given the way it is behaving, but with only 8 Netflow packets per second from only 1 production router we didn't…

Hello Andy, The same model. The switches we currently have with NetFlow enabled are two 6509s with redundant Sup720s… -Corey

For what it is worth, SP1 does not seem to really help much if any... The service restarted at 4am this morning and already has ~45K Raw packets in the queue... @ 30 flow updates per UDP/PDU packet that is ~1.3 million flow updates not being processed so far today... This is with an input packet rate of only 8 packets per…

As a work around, I just use a scheduled task to stop and restart the service before it runs the server out of memory... Not perfect, but lets me sleep better for now. My real concern in this is that if I am getting ~350K unprocessed blocks of data when I restart, am I really losing that information? If so, what…

For what it is worth, after applying SP2 I am getting this as well on switch flows, but not on router flows. All are Cisco v5...

David, thanks for the update. I look forward to our DBAs not giving me the evil-eye when I mention NetFlow in the hallway... :-)

Having an easy way to monitor the QoS queues would indeed be useful. Especially if you could associate it with the IP SLA you had for that queue and be able to watch in a single couple of graphs how well your QoS tuning was affecting the response time for the users. Seems to me that would be a powerful tool.

Using a non-core device as the SLA responder has several advantages. Orion and VoIP Monitor have more frequent updates than might want to subject your core Cisco devices to. VoIP monitor it is MUCH easier to monitor the links if it is given SNMP Write access to the SLA devices. This can be a bit risky in case Orion or the…

From what I can see, the only switches that Cisco's Feature Navigator seems to indicate supports the VoIP/Responder features are the 3560/3750 with IOS v12.2(40)SE. I have not tried them with VoIP Monitor just yet myself though...

You might want to consider that the devices running the WAN links do not need to be the the ones creating and running the SLAs for VoIP monitor. I use an older 7204 and a 2811 as two nodes that do little else but act as SLA Hubs endpoints for now... It just needs local Ethernet connectivity and a current enough IOS and RAM…

The similar problem I had was due to the view settings that older acount had when new pieces like NetFlow are added. The account values for views and such are not updated for these older accounts (or at least accounts that were there before NTA was installed). Once I changed this on any pre-existing accounts it stopped...…

Just as a side note these JPG images are sure distorted in the view I see for each message though when I click on them it looks fine...

Thanks very much. I think it will mean we can get by without creating hundreds of subnets and still be able to use the AS as a subnet/remote site grouping for MPLS... It should be a great improvement in usability for us... :-) -Corey

I have noticed similar things. The VoIP monitor does not always recover when an IP SLA router reboots. Sometimes both paths to/from another node are not collecting, sometimes only one. It seems to me that if the VoIP monitor has "X" number of paths collecting and yet it is not retrieving data for some of them it should…

It would be very helpful if we had some numbers to correlate with... n-Flows per second, or n-PDUs per minute/second will generate X SQL I/Os on average... I know the math is a little hard to pin down, but someone who knows how it works could provide a little Excel spreadsheet if needed... I know it would not be perfect,…

This same thing happens to us. I just stopped the process and logged back in and the memory and CPU have been released. We end up using 400-1000MB when it hangs up and even after the user interface is closed down the process stays and buries a CPU. This is most likely to happen when two of us are in it and at least one…

One more thing... I am running under SP1 now for Netflow...

We already have "Monitor All" selected. I will try and get to a packet trace tomorrow, but since the router flows are nearly always correct (they sort of have to be very close since the router is forwarding the traffic...) I am expecting the traces will show the same.

Justin, I have an idea that might help. If you start Windows Performance monitor on the server where your NetFlow collector is running and look under the SolarWinds performance object for the Raw Packet Queue Length. In other threads it was indicated that this is how far behind the NetFlow engine is in processing data from…

I too think this would be very useful for Orion to be able to do. Doing it manually is a huge time commitment...

NetFlow data collection is both Ingress and Egress though there are some restrictions with either of course. Many routers support Egress NetFlow after 12.3(11)T... http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/nflowegr.pdf

As you can see from this Orion chart of the interface traffic and with the router showing the flow stats, several things are amiss... The traffic according to the router flows is HTTP port 80, and the interface charts show that the traffic is continuously busy at near 100%. The NetFlow charts show a mix of traffic, much…

Thanks very much.

I have seen the same things in v2.2 and v3 but it is somewhat inconsistent... After the SQL performance problems cropped up I had assumed that this problem was actually due to unprocessed flow details being lost and not distilled completely from the flow data when the SQL server threads were being overwhelmed and never…

I think there is some confusion here about the Cisco HW/SW being used... The Cat65xx Supervisors are currently either the Sup2, Sup32 or the Sup720. All are capable of both L2 and L3 support. There is no Sup4 or Sup5. AFAIK there is also no NetFlow daughter card either as this is all handled by the PFC/MSFC team in the…

Thansk very much Andy.

Andy, In presenting the data for the VoIP sites and paths, it seems to me that with a fully meshed and large implementation it is just simply very difficult to organize the data collected in such a way as to make it available in a reasonable fashion. For such large configurations with dozens of paths (if not hundreds),…

Thanks Andy. I guess my thoughts are more along the lines of how the data is made available. The Orion interface allows us to gerneate view, graphs, data, etc... via HTTP. The Report writer requires that users have local login authority on the Orion servers as I understand it That means Terminal Services and users leaving…