Cisco Blogs

An introduction to the new Cisco Network Visibility Flow Protocol (nvzFlow)

- November 16, 2015 - 8 Comments

As recently announced, Cisco AnyConnect 4.2 extends visibility to the endpoint with the Network Visibility Module (NVM).  Users are one of the most vulnerable parts of any security strategy, with 78% of organizations saying in a recent survey that a malicious or negligent employee had been the cause of a breach.  However, until now, IT Administrators had been blind to user behavior on their devices.  NVM allows you to monitor and analyze this rich data to help you defend against potential security threats like data exfiltration and shadow IT, as well as address network operations challenges like application capacity planning and troubleshooting.

AnyConnect NVM supports the Cisco Network Visibility Flow protocol or nvzFlow for short
(pronounced: en-vizzy-flow).  The protocol is designed to provide greater network visibility of endpoints in a lightweight manner by extending standard IPFIX with a small set of high-value endpoint context data.  Leading IPFIX vendors have begun implementing the new protocol to provide customers with an unprecedented level of visibility.

Here are some examples of the types of questions an IT Administrator would like to answer:

  1. Where are the enterprise users accessing SaaS services from and what services are they accessing from a given location?
  2. Are they using a company asset or a BYOD device when accessing these services?
  3. Did they use an approved application or a potentially vulnerable version of an application?

The nvzFlow protocol allows for an IT administrator to answer these questions as follows:

Mary visited from an unmanaged Windows 8.1 laptop using a company approved browser, Firefox version 42, while she was connected on her local Starbucks’ Wi-Fi network.

From the above statement, the 5 key visibility categories are conveyed by the protocol as:

  • User (Mary)
  • Device (unmanaged Windows 8.1 laptop)
  • Application (approved browser, Firefox version 42)
  • Location (local Starbucks)
  • Destination (

Here are some basic reports that you can build using the rich nvzFlow data set with any IPFIX reporting tool that can support the protocol:

What are the top 15 network applications by downloaded data over the last 24 hours at our enterprise?


What are the top flows by destination domain over UDP in the last 24 hours?



How many different versions of Cisco Jabber are users running in the enterprise?
Also, what destination domains is Cisco Jabber connecting to so I can set appropriate firewall, proxy and split tunneling policies?



The enterprise IT team learned of a recent incident with Fred on his BYOD device.  The InfoSec team will need to determine where Fred was when he accessed the network over VPN and what destination domains Fred was connecting to.

FredMac1 (1)


As you can see, the protocol offers an impressive set of network visibility context. We have been running some advanced machine learning algorithms in the Office of the Security CTO on a few months of live nvzFlow data from several hundred AnyConnect NVM endpoints.  We will share some of our findings in a follow-on blog.

Meanwhile, for those of you who are interested in the details of the protocol, please read on.

nvzFlow IPFIX protocol:

This new protocol was developed by the Office of the Security CTO at Cisco, and is planned to be moved to a standards track in the near future.

In order to be included in the protocol, each data element must meet the following requirements:

  1. Convey information directly related to the five key visibility categories shown above.
  2. Be clear, obvious and of high value to an IT administrator.
  3. Is useful to analytics, while not requiring the use of analytics (raw-data value).
  4. Easily obtainable information across a wide variety of OS and device types.
  5. Lightweight and portable (no network, battery or CPU impact; no DPI required; etc.)

There are 3 templates as part of the nvzFlow Protocol:

  • Endpoint – Fields that are associated with an Endpoint Device, such as OS Name.
  • Interface – Fields associated with the network interface, such as Adapter Name.
  • Flow – Fields associated with the flow itself, such as L4 Bytes Out.

The Endpoint and Flow templates are present in the initial release of the AnyConnect Network Visibility Module.  Subsequent releases will support the remaining elements of the protocol.

Note that some fields will be present in multiple templates for cross correlation purposes.
These are mandatory fields, while all others can be either anonymized (“-“) or not sent at all.
Finally, all string types are encoded in UTF-8 format.

 Element ID with/without enterprise bit

Template Member

E = Endpoint

I = Interface

F = Per Flow


(M) = Mandatory


Data Type/

Data Type Semantics


 45100 / 12332
[ E, I, F (M) ]
 nvzFlowUDID  octetArray / Identifier  20 byte Unique ID that identifies the endpoint.
 45101 / 12333
[ E ]
 nvzFlowLoggedInUser  string / default  This is the logged in user on the device, in the form Authority\Principle. This is different from userName (id: 371), which is user associated with the flow.
 45102 / 12334
[ E ]
 nvzFlowOSName  string / default  Name of the operating system. E.g., Windows, Mac OS X
 45103 / 12335
[ E ]
 nvzFlowOSVersion  string / default  Version of the operating system. E.g., 5.0.2195 or 10.10
 45104 / 12336
[ E ]
 nvzFlowSystemManufacturer  string / default  Name of the manufacturer. E.g., Lenovo
 45105 / 12337
[ E ]
 nvzFlowSystemType  string / default  Type of the system. E.g., x86 or x64
 45106 / 12338
[ F ]
 nvzFlowProcessAccount  string / default  Authority\Principle of the process associated with the flow. E.g., ACME\JSmith, <machine>\JSmith
 45107 / 12339
[ F ]
 nvzFlowParentProcessAccount  string / default  Authority\Principle of the parent of the process associated with the flow. E.g., ACME\JSmith, <machine>\JSmith
 45108 / 12340
[ F ]
 nvzFlowProcessName  string / default  Name of the process associated with the flow. E.g., firefox.exe
 45109 / 12341
[ F ]
 nvzFlowProcessHash  octetArray / default  SHA256 hash of the process image on disk associated with the flow.
 45110 / 12342
[ F ]
 nvzFlowParentProcessName  string / default  Name of the parent of process associated with the flow. E.g., explorer.exe
45111 / 12343
[ F ]
nvzFlowParentProcessHash octetArray / default SHA256 hash of the process image on disk of the parent process associated with the flow.
45112 / 12344
[ F ]
nvzFlowDNSSuffix string / default Per-interface DNS suffix configured on the adapter associated with the flow for the endpoint. E.g.,
45113 / 12345
[ F ]
nvzFlowDestinationHostname string / default The FQDN (hostname) that resolved to the destination IP on the endpoint. E.g.,
45114 / 12346
[ F ]
nvzFlowL4ByteCountIn unsigned64 / totalCounter  Total number of incoming bytes on the flow at Layer4 (Transport). [payload only, without L4 headers]
 45115 / 12347
[ F ]
 nvzFlowL4ByteCountOut  unsigned64 / totalCounter  Total number of outgoing bytes on the flow at Layer4 (Transport). [payload only, without L4 headers]
v2 fields
45119 / 12351
[ E ]
 nvzFlowOSEdition  string / default  The OS Edition, such as Windows 8.1 Enterprise Edition
 45120 / 12352
[ F ]
 nvzFlowModuleNameList  basicList of string / default  List of 0 or more names of the modules hosted by the process that generated the flow.   This can include the main DLLs in common containers such as dllhost, svchost, rundll32, etc. It can also contain other hosted components such as the name of the jar file in a JVM.
 45121 / 12353
[ F ]
 nvzFlowModuleHashList basicList of octetArray / default List of 0 or more SHA256 hashes of the modules associated with the nvzFlowModuleNameList
 45122 / 12354
[ F ]
nvzFlowCoordinatesList  basicList of float32 / default  List of 32bit floating point values representing Accuracy, Latitude, Longitude, [Altitude] respectively. Altitude is optional.   Coordinate based location information such as GPS, Wi-Fi Approximation, etc., Accuracy in meters – defines the error margin.
 45123 / 12355
[ F, I (M) ]
 nvzFlowInterfaceInfoUID  unsigned32 / identifier Unique ID for an interface meta-data. Should be used to lookup the interface meta-data from the InterfaceInfo records.
45124 / 12356
[ I ]
 nvzFlowInterfaceIndex unsigned32 / default  The index of the Network interface as reported by the OS.
 45125 / 12357
[ I ]
 nvzFlowInterfaceType unsigned8 / default  Interface Type, such as Wired, Wireless, Cellular, VPN, Tunneled, Bluetooth, etc. Enumeration of network types, defined by this spec.
45126 / 12358
[ I ]
 nvzFlowInterfaceName  string / default Network Interface/Adapter name as reported by the OS.
 45127 / 12359
[ I ]
 nvzFlowInterfaceDetailsList basicList of string / default  List of name value pair (delimited by ‘=’) of other interface attributes of interest. E.g., SSID=internet.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. This is a very innovative export. We've added support for it as well. It provides much more insight into our VPN users.

    Clear write-up and sounds really useful.

    Nice post. Thanks Vinny.

    Excellent post Vinny. This information will be very helpful going forward.

  2. Very interesting new add-on to AnyConnect. Love to see this kind of intelligent innovation added to an already highly versatile product. The blog write-up is clear and helpful as well.

  3. Thanks for the interesting post, which platforms will this AnyConnect module be supported for?

    • AnyConnect 4.2 for Windows and Mac support the protocol as part of the AnyConnect Network Visibility Module.

  4. Nice article. Seems like a very useful set of endpoint data for threat defense.