It is my pleasure to announce the release of NTA v4.1 RC1. To download the Release Candidate, please log into the customer portal and navigate to the NTA downloads section. A few important notes:
- RC builds are made available to existing customers prior to the formal release. These are used to get customer feedback in production environments.
- RC versions can be upgraded to later releases and are fully supported in production environments.
- Note this is the first NTA release that requires 64-bit. It is not compatible with 32-bit, as previously announced.
With that out of the way, let's jump into the contents of this release!
Automatic sample rate recognition now works even when vendors do not include certain RFC required fields to communicate their sampling rate. Although this change applies to all vendor's gear, this issue is particularly prevalent for Juniper equipment. You can see the results of the automatic detection of sampling rate on the NetFlow Sources page, as always:
In addition to improved automatic detection of sampling, we now support manual sample rate configuration. Clicking on the edit button as seen above in the "NetFlow Sources" page allows you to enter a manual sampling rate:
Whether your gear properly reports sampling rate per RFC, sort of reports it but doesn't comply with RFC, or outright doesn't report it, we should now have you covered!
It's Monday morning and one of your remote sites is reporting slow connectivity. You see high bandwidth utilization on the WAN interface so you jump in NTA to check out who or what is eating up all your bandwidth.
Here we see one specific endpoint taking the vast majority of the bandwidth. Okay, what's next?
Most engineers choose one of two paths:
- Contact the Desktop Support group to find what user that endpoint belongs to. Wait for them to respond. Get a name. Call the user and nicely ask them to stop whatever they're doing that's taking up all the bandwidth.
- Manually track down what switch port the device is connected to by repetitively executing "show ip arp" and "show mac-address-table" on one network device at a time until you've traced all the way to the endpoint. Then shut down the port. Problem solved. Hope it's not anyone too important.
Surely with all of our modern technology there's a better way to do this. With NTA 4.1, there is, thanks to UDT. Simply clicking on the endpoint IP address in the above chart yields the NetFlow Endpoint page:
This page now pulls in information from UDT (top right two resource) to tell you more about the endpoint including the most recent user log ins. If you want to call the user, you no longer have to get Desktop Support involved. You can check the GAL and call the user immediately.
Alternatively, if you're feeling more aggressive or the severity of the impact justifies faster action, click on the node IP or MAC address in the UDT resource to go to the UDT Endpoint page. From here, you can see what switch port the user is connected to and even administratively disable the port directly in the web UI.
In either case, we've walked from NPM alert or user complaint all the way to resolution fast and without involving another department or a bunch of CLI work!
The Database Settings section of the "NTA Settings" page has been redone and now includes number of flows per second being received and estimated size of your FSDB if you have not yet reached your retention period:
We've also made improvements in the following areas:
- Improved historical application update speed (up to 7x) in certain circumstances.
- 8-bit ToS support; properly mapping packets with explicit congestion bits set to the expected QOS category.
- Support for drag and drop resources.
- Fixed an issue that could sometimes cause FSDB Index Corruption.
Jump on over to the customer portal and grab RC1 to get this functionality into production! If you have any questions or comments, feel free to post them here.
I look forward to hearing your feedback!