GigaSMART NetFlow Generation
Required License: NetFlow GenerationRequired License for NetFlow with Second Level Maps: Adaptive Packet Filtering (APF)
Supported Devices : GigaVUE- HC1 Gen 2, GigaVUE‑HC2,GigaVUE- HC3 Gen 2.
Refer to Supported GigaSMART Operations for more details on the devices that support GigaSMART operations.
NetFlow Generation is a simple and effective way to increase visibility into traffic flows and usage patterns across systems. The flow-generated data can be used to build relationships and usage patterns between nodes on the network. Routers and switches that support NetFlow can collect IP traffic statistics to be exported as NetFlow records.
However, the processor and memory load of enabling NetFlow can cause service degradation and affect their ability to pass traffic without introducing latency and packet drops. Due to this processing overhead, sampled NetFlow is implemented in most of the high-end routers. Sampling in every “N” packets for NetFlow processing can severely limit the visibility needed to monitor flows.
The advanced capabilities of GigaSMART® technology can be leveraged to summarize and generate unsampled NetFlow statistics from incoming traffic streams. Offloading NetFlow Generation to an out-of-band solution like the Gigamon Deep Observability Pipeline completely eliminates the risk of using core production network resources in generating this data. Combined with the flexibility offered by Gigamon’s patented Flow Mapping®® technology, operators can pick and choose from which flows to generate NetFlow statistics, while at the same time sending the original packets to other monitoring tools.
Support for NetFlow versions 5 and 9 and IP Information Export (IPFIX), as well as CEF, enables seamless integration with standards-based collectors. NetFlow records can also be exported to multiple collectors concurrently, providing a single flow source for business-critical management applications such as security, billing, and capacity planning. Exported flows can also be filtered so that collectors only receive the specific records relevant to them.
Note: Legacy NetFlow supports only one NetFlow version (v5, v9 or IPFIX) record and NetFlow exporter format version per engine unless the exporter format is CEF.
Gigamon has also extended IPFIX to include URL information, providing insight into HTTP and SIP traffic. Other enterprise extensions for IPFIX are HTTP, DNS, and SSL certificates, which provide metadata that can be used for security analysis.
Additionally, Gigamon’s Deep Observability Pipeline architecture is the first in the industry to summarize flow statistics as well as to provide the flexibility of aggregating, replicating, filtering, and forwarding raw traffic streams to monitoring tools for detailed troubleshooting and analytics.
The Gigamon Deep Observability Pipeline establishes a scalable framework to deliver pervasive flow-level visibility across enterprises, data centers, and service provider environments to accurately design, engineer, optimize, and manage their network infrastructure.
Note: NetFlow Generation exports records using IPv4. IPv6 is not supported.
GigaSMART operations with a NetFlow component can be assigned to multiple GigaSMART groups or GigaSMART groups consisting of multiple GigaSMART engine ports.
NetFlow/IPFIX Generation is a pillar of the GigaSECURE Security Delivery Platform.
NetFlow Generation is displayed in 1.
1 | NetFlow Generation Gigamon Solution |
In 1, incoming packets from network(s) enter the Gigamon Deep Observability Pipeline and are directed by maps to NetFlow. NetFlow examines the incoming packets and converts the packets of choice into flows records. Specific flows are then forwarded to specific tools, such as Security, Application Performance, and Customer Experience Management (CEM) tools.
Active Timeout
When a flow is active (GigaSMART engine receives packet) and sends packets for more than delta seconds, it hits an active timeout of delta seconds.
Inactive Timeout
When a flow stops sending packets for more than delta seconds, it hits inactive timeout of delta.
However, there can be some flows which are not exported at the end of active/inactive timeout.
The following diagram shows an example when Legacy NetFlow can push flows after active timeout.
In the above diagram, the blue vertical line represents the absolute time. The black vertical line represents the time at which GigaSMART engine starts exporting data after inactive time out. The green curly brackets represent the active timeout. The width of the black line represents the time taken by the exporter to push all the existing flows.
After a black line ends, it takes 60 seconds for another black line to start. This 60 second gap is represented by the green curly brackets. To ensure that each flow could be sent only once, there is only one vertical black line at any point of time.
In the above example, the red arrow represent a new flow in the network. When the flow starts and reaches the first black line, the GigaSMART engine calculates if the flow has reached the active time out. Here, since the flow has not reached the active Time out, the GigaSMART engine does not export the data for the flow.
The time consumed by the export process depends on the number of the flows that are being exported. The export process restarts after active timeout (the second black line). When the flow reaches the second black line, GigaSMART engine exports data for that flow.
Note: The difference between the time taken at which data is first exported for the flow and the flow start time is greater than the active timeout.
Hence, it is possible for the GigaSMART engine to rarely consume more time to export data of active flows.
Note: For inactive timeout also the Legacy NetFlow pushes the flows in same manner as explained in the example.
NetFlow Generation collects IP traffic statistics on all interfaces where a NetFlow Monitor is enabled. It then gathers the statistics of the traffic flows and exports the NetFlow records to at least one NetFlow collector (typically a device that performs the actual traffic analysis based on the information from the NetFlow records).
2 shows the NetFlow Generation components.
2 | NetFlow Generation Components |
illustrates the NetFlow Generation and how its components are associated. The NetFlow Generation associates its components in the following order:
1. | One or more Records are associated to the Monitor. |
2. | The Monitor is associated to the GigaSMART group. |
3. | The Exporter is associated to the IP interface with tool port. |
4. | The map will eventually bind to the Exporter, Record, and Monitor. |
Note: The dotted line from the map represents the interaction between the NetFlow Generation components.
Refer to Example 1: NetFlow Generation Configuration on page 631 for an example configuration of the following components.
NetFlow operates on the network flow. The incoming traffic on the network ports contains inputs such as, source and destination IP addresses, source and destination ports, interfaces, and so on. The network ports provide traffic to maps.
Traffic is received and acted upon according to maps. Maps determine what traffic is forwarded to NetFlow. Through map configuration, you add rules to filter the packets that need to go to NetFlow, and associate the map to the IP interface with tool port to specify where to send the filtered traffic.
Starting in software version 4.3.01, NetFlow supports both first level and second level maps. First level maps contain flow mapping rules to filter traffic that is needed by NetFlow and then send the filtered traffic to the IP interface with tool ports.
Second level maps are used for configuring filtering rules enabled through Adaptive Packet Filtering (APF). A virtual port is configured that directs traffic to the second level map. After the APF rules are applied, the filtered traffic that is needed by NetFlow is sent to the IP interface tool ports.
For examples of first level maps, refer to GigaSMART NetFlow Generation and GigaSMART NetFlow Generation.
For examples of first and second level maps, refer to GigaSMART NetFlow Generation and GigaSMART NetFlow Generation.
A NetFlow record contains key elements that specify what to match in the flow, such as all packets with the same source and destination port, or anything that comes in on a particular interface. A flow record also contains non-key elements that specify what information to collect for the flow, such as when the flow started or the number of bytes in the flow.
For NetFlow-v5, the fields in the flow record are fixed. For details, refer to V5 Fixed Record Template on page 657.
For NetFlow-v9 and IPFIX, you configure the fields, and thus create a record template. You specify how the fields are organized and in what order. The template is sent to the collector, so the collector knows what fields to expect in a NetFlow record. The template is sent periodically.
Starting in software version 4.6, multiple records are supported. An increased number of records allows more NetFlow data to be exported.
The maximum number of records is five. For all five records, each record must have the same match fields but differing collect fields. The same match fields will define the flows being considered. The different collect fields will define multiple templates sent to the NetFlow servers.
Starting in software version 5.1 for IPFIX and software version 5.2 for v5 and v9, a mix of IPv4 and IPv6 collect fields (IPv4 source/destination and IPv6 source/destination) are not supported in one record. Instead, create two records, one for IPv4 collect fields and one for IPv6 collect fields. When the IPv4/IPv6 collect fields are in separate records, an exporter will only send out records with non-blank elements.
Monitors store the NetFlow records associated with them. The configuration of a monitor includes the definition of the cache that specifies the records that you want to store, as well as timeouts associated with the cache. The cache can contain up to 4 million entries.
There can be a maximum of two monitors on a GigaSMART line card or module, one associated with each e port.
Starting in software version 4.6, up to five records can be added to the monitor. This results in the creation of five templates. For all five records, each record must have the same match fields but differing collect fields.
NetFlow data can be sampled. Sampling reduces the amount of ingress traffic sent to NetFlow for processing, which reduces the load on external collectors.
A NetFlow monitor can have multiple records with different sampling rates. The records are only updated with packets at the rate specified.
The following types of sampling are available: single-rate or multi-rate, as well as no sampling.
Sampling is enabled and disabled on the NetFlow monitor, across all flows. When sampling is enabled, you define the sampling rate by specifying a number for 1 in N, where N is the packet count.
For single-rate, the number can be from 10 to 16000. For multi-rate, the number can be from 1 to 16000. Single-rate applies to all records, whereas multi-rate applies to any record.
Note: In a single-rate sampling type, all the NetFlow records are sampled in the same rate. In multi-rate sampling type, the sampling rate of the NetFlow records differ according to the settings defined in the individual records.
For example, if sampling is 1 in 1024, 1 packet in 1024 will be selected for NetFlow. The default is 1 in 1, which means no sampling.
Note: The sampling mode in this release is deterministic. The selection of the packet is not random. Deterministic sampling means that if the rate is 1 in 1024, after 1023 packets, the 1024th packet is selected, while packets 1 to 1023 are ignored.
NetFlow records are sent to exporters. Each exporter is associated with one external collector. Records can be exported to both IPv4 and IPv6 destination. Either IPv4 or IPv6 destination address can be configured in an exporter. There can be up to six exporters that send flow records to up to six external collectors. The six destinations are per GigaSMART engine.
The configuration of an exporter includes the IP address of a collector, the transport protocol and destination port, and the template refresh interval, which specifies the frequency of when the record template is sent to the collector.
Starting in software version 5.1, an option is added to assign different exporters to different records. Instead of records being sent to all exporters, you can add an exporter to a record, which defines the exporter to which the record is sent.
NetFlow exporters are associated with IP interface, since exporters route both records and templates to collectors in the network.
Note: It is expected that the gateway specified in the IP interface configuration does Layer 3 routing. However, when the IP interface and the collector’s IP address are in the same subnet, the following applies:
Configure the IP interface’s gateway IP address to the same as the collector’s IP address. |
Configure the IP interface’s subnet mask. |
The maximum number of exporters supported per GigaSMART group is six. |
In addition to the NetFlow components, there are also the following enhancements:
Exporter Filtering |
Remote Interface IDs |
NetFlow Option Templates |
IPFIX Extension: HTTP Response Code |
IPFIX Extension: Packet URL |
IPFIX Extension: User Agent |
IPFIX Extension: Domain Name Service (DNS) |
IPFIX Extension: SSL Metadata |
SNMP Packet Support on IP Interfaces with Tool Ports |
NetFlow Format Support on Exporters |
Not all collectors are interested in all kinds of packets. On each exporter, you can configure pass filters to filter the records transmitted to a collector. Thus, you can send a subset of records to a collector, such as the flow records for UDP packets or for packets coming in on a particular port.
Filtering is based on criteria, such as ports or IP addresses. For example, you can filter on different interfaces, such as single port (1/1/x1) or a contiguous range of ports (1/1/x1..x4). Note that you can only filter the criteria or a subset of the criteria that you configured for the match fields in the record.
Note: If no filters are configured, all records are sent to the collectors.
The exporter pass filters are as follows:
Input interface |
IPv4 and IPv6 DiffServ Code Point (DSCP) |
IPv4 and IPv6 source address |
IPv4 and IPv6 destination address |
IPv4 protocol |
IPv4 Type of Service (TOS) |
IPv6 flow label |
L4 source and destination port |
MAC source and destination address |
VLAN ID |
Take into account the following considerations:
an exporter can have up to 5 filter rules |
each rule can have up to 4 attributes |
input interface can only be specified once per filter |
other attributes can be specified multiple time in a rule |
two rules cannot be identical |
For an example of exporter filtering, refer to GigaSMART NetFlow Generation.
Interface ID, ingress as well as egress, can be configured as match and collect fields. Interface IDs can be local or remote. If you are interested in the interface ID on which a packet arrives, you need the port number of the node sending the packet. To get that information, you can use the LLDP/CDP discovery protocols that talk to neighbors to fetch the remote interface ID.
Discovery has to be either enabled or disabled on all the ports in a map. If discovery is enabled, the remote interface ID is sent in the NetFlow data record, as learned through LLDP/CDP.
To configure port discovery with NetFlow, enable discovery on the port or ports that are specified in the Source field of the associated map.
Note the following:
You cannot modify discovery once the map is defined. |
Local port IDs are unique across a cluster. Remote IDs might not be unique. With port discovery enabled, there is a possibility of port ID collisions. |
Note: If port discovery is not enabled, the local port ID is sent in the NetFlow data record.
When port discovery is enabled, the sending of the remote ID requires the collaboration of the end nodes. NetFlow expects an integer for port ID. If end nodes send an alphanumeric string, MAC address, or IP address (non-integers), that cannot be translated in an integer, NetFlow interprets them as either 0xFFFF or 0xFFFFFFFF.
When port discovery is enabled and ingress LLDP/CDP packets contain interface IDs that cannot be translated into an integer, use the collect field interface input name in the flow record definition. Using an interface name will send meaningful information about a network port to help identify the port to which the flow record refers.
To access GigaSMART within GigaVUE-FM, access a device that has been added to GigaVUE-FM from the GigaVUE-FM interface. GigaSMART appears in the navigation pane of the device view on supported devices. Refer to the Access GigaSMART from GigaVUE‑FM for details.
To use the collect field interface input name, do the following:
1. | From the device view, select GigaSMART > NetFlow / IPFIX Generation > Records. |
2. | Click New to create a new Record or select the recored and click Edit to change an existing record. |
3. | Click in the field Non-Key Fields (Collect) and select Interface from the list. |
4. | Select Input and then Input Name. Specify an input Width as shown in 3. |
5. | Click Save. |
3 | Collect Field Interface input Name |
For NetFlow-v9 and IPFIX, each exporter periodically sends option templates and option data records. There are two supported option templates, as follows:
Interface ID to name mapping template and data record |
Exporter statistics template and data record |
The option template for interface ID to name mapping contains an interface ID and name pair. Instead of a local port ID, the actual port number is available. For NetFlow-v9, the name field has a fixed length of 32 bytes. Names shorter than 32 bytes will be padded, while names longer than 32 bytes will be truncated. For IPFIX, the name field is of variable length.
Note: When port discovery is disabled for the port or ports specified in the Source field of the associated map, the interface option data record sends the interface ID to name mapping. But when discovery is enabled, interface option data records are not sent.
Each exporter sends out statistics, based on the standards. The exporter statistics option template includes information such as the exported flow record count, the exported message total count, and the exported octet total count.
By default, the transmission of option templates from the exporter is always enabled. The frequency of the transmission can be configured using the Template Refresh interval field in the NetFlow Exporter configuration page. To open the configuration page, select GigaSMART > NetFlow / IPFIX Generation > Exporters and click New.
IPFIX Extension: HTTP Response Code
For IPFIX only, use the collect field Private PEN HTTP Response Code in the flow record definition for capturing any packet with an HTTP response code embedded in it. This is a private information element extension, specific to Gigamon. The only valid private enterprise name (pen) is gigamon.
The HTTP response code information is captured from the packet and reported in the NetFlow record. The captured HTTP response code will be from the first packet that has HTTP/1 at the start of the HTTP header.
The field length in the flow record is a fixed length of 2 bytes.The range of response code values is from 100 to 599, as follows:
100-199 (informational) |
200-299 (success related) |
300-399 (redirection) |
400-499 (client requests) |
500-599 (server related) |
If there is no HTTP response code in the flow, a zero value will be reported.
Note: In releases prior to software version 5.2, HTTP Response Code was directly under Private PEN. Starting in software version 5.2, there is a new HTTP section with Response Code under it. For backwards compatibility, both are supported.
To access GigaSMART within GigaVUE-FM, access a device that has been added to GigaVUE-FM from the GigaVUE-FM interface. GigaSMART appears in the navigation pane of the device view on supported devices. Refer to the Access GigaSMART from GigaVUE‑FM for details.
To configure the NetFlow record for capturing any packet with an HTTP response code embedded in it, do the following:
1. | From the device view, select GigaSMART > NetFlow / IPFIX Generation > Records. |
2. | Click New. Refer to 4. |
4 | NetFlow Record Configuration for HTTP Response Code |
3. | For Version, select IPFIX. |
4. | Click the Non-Key Fields (Collect) drop-down list and select Private. |
5. | In the Private non-key field, do the following: |
Set PEN to gigamon. (This is the default.) |
Select HTTP Response Code. |
6. | Click Save. |
For IPFIX only, use the collect field Private PEN HTTP URL in the flow record definition for capturing any packet with a URL embedded in it. This is a private information element extension, specific to Gigamon. The only valid private enterprise name (pen) is gigamon.
The following URL information is captured from the packet and reported in the NetFlow record:
HTTP: GET, POST, PUT, DELETE, and HEAD method types |
SIP: INVITE, ACK, BYE, REGISTER, OPTIONS, and CANCEL request types |
The captured URL will be from the first packet that contains a URL. If there are additional URLs in subsequent packets in the flow, they will be ignored. If there is no URL in the flow, a zero length will be reported.
Note: The URL will always appear as the last element in a template, no matter the order in which the collect fields were configured.
Note: In releases prior to software version 5.2, URL was directly under Private PEN. Starting in software version 5.2, there is a new HTTP section with URL under it. For backwards compatibility, both are supported.
In 4 in the Private non-key field, select URL and enter an optional width.
For IPFIX only, use the collect field Private PEN HTTP User Agent in the flow record definition for capturing any packet with a user agent in the HTTP request header to gather information about clients user agents.
In general, the HTTP request is sent from the browser to the web application, so User Agent is filled in by the browser. As such, different browsers fill in this field with different values.
The maximum user agent length that is allowed in the data record is 250 bytes. The default is 150 bytes. Use the width parameter to specify a user agent length of up to 250 bytes.
In 4 in the Private non-key field, select User Agent and enter an optional width.
For IPFIX only, use the non-key or collect field Private PEN DNS in the flow record definition for capturing any packet with Domain Name Service (DNS) parameters embedded in it. This is a private information element, specific to Gigamon. The only valid private enterprise name (pen) is gigamon.
A domain name service translates host names into IP addresses. DNS has been exploited by attackers. Use this NetFlow enterprise element to gather metadata to help protect against security threats.
When certain DNS parameters are configured, the corresponding values for those collect parameters can be displayed in hexadecimal format or in text format. The following DNS parameters can display their values as text when the text version of that parameter is used:
Additional Class, Additional Class Text |
Additional Type, Additional Type Text |
Authority Class, Authority Class Text |
Authority Type, Authority Type Text |
Query Class, Query Class Text |
Query Type, Query Type Text |
Response Class, Response Class Text |
Response IPv4 Address, Response IPv4 Address Text |
Response IPv6 Address, Response IPv6 Address Text |
Response Type. Response Type Text |
For example, if the DNS query-type parameter collects a hexadecimal value of 0x1, the query-type-text parameter collects the text string A, which refers to the IP address of the host.
The DNS parameters are captured from the packet and reported in the NetFlow record. Refer to Display Exporter Statistics and NetFlow Exporter Statistics Definitions.
In the NetFlow record, the collect fields may contain one the following:
Only private enterprise elements such as SSL, HTTP, or DNS |
Only non-private enterprise elements such as source IP address |
Both private and non-private elements |
If all the collect fields contain only the private enterprise elements, and if during run-time, the records are blank or empty, they will not be added to NetFlow, however they will be counted in the exporter statistics as Empty Records Not Added.
If the collect fields contain both private and non-private enterprise elements, and if during run-time, the private enterprise elements are blank or empty, the records can be exported to the collector.
To access GigaSMART within GigaVUE-FM, access a device that has been added to GigaVUE-FM from the GigaVUE-FM interface. GigaSMART appears in the navigation pane of the device view on supported devices. Refer to the Access GigaSMART from GigaVUE‑FM for details.
To configure the NetFlow record for capturing any packet with (DNS) parameters embedded in it, do the following:
1. | Go to GigaSMART > NetFlow / IPFIX Generation > Records. |
2. | Click New. Refer to 5. |
5 | NetFlow Record Configuration for DNS |
3. | In the Alias field, enter a name. |
4. | To export the blank pen records, select Export Blank Pen. |
5. | For Version, select IPFIX. |
6. | Click the Non-Key fields (Collect) drop-down list and select Private. |
7. | In the PEN field, enter gigamon. (This is the default.) |
8. | Click DNS and select the parameters. The Number of Collects field is displayed for some DNS parameters. Refer to Table 6: DNS Parameters . |
9. | In the Number of Collects field, specify the number of instances of elements to collect from the DNS request. The value ranges from 1 to 10. The default value is 1. |
10. | Click Save. |
Method |
For more information: |
Additional Name |
The domain name in the additional records section. |
Additional Type |
The additional type containing one of the RR type code. |
Additional Type Text |
The text string that corresponds to the hexadecimal value of the additional type containing one of the RR type code. |
Additional Class |
The additional class containing one of the RR class code. |
Additional Class Text |
The text string that corresponds to the hexadecimal value of the additional class containing one of the RR class code. |
Additional TTL |
The time-to-live (TTL), which is the time interval in seconds that the record is cached in the additional records section. |
Additional RData |
The content that describes the resource in the additional records section. |
Additional RData Length |
The length of the rdata field in the additional records section. |
AN Count |
The number of resource records in the answer section. |
AR Count |
The number of resource records in the additional records section. |
Authority Name |
The domain name in the authority section. |
Authority Type |
The authority type containing one of the RR type code. |
Authority Type Text |
The text string that corresponds to the hexadecimal value of the authority type containing one of the RR type code. |
Authority Class |
The authority class containing one of the RR class code. |
Authority Class Text |
The text string that corresponds to the hexadecimal value of the authority class containing one of the RR class code. |
Authority TTL |
The time-to-live (TTL), which is the time interval in seconds that the record is cached in the authority section. |
Authority RData |
The content that describes the resource in the authority section. The format of the rdata field varies according to the type and class of the resource record. |
Authority RData Length |
The length of the rdata field in the authority section. |
Bits Count |
The variable length of a bit map. The bit map must be a multiple of 8 bits long. For example: "/QR=1/AA=0/TC=0/RD=1/RA=1/AD=0/CD=0/Z=0", where /QR is the query (0) or a response (1), /AA is the authoritative answer, /TC is the truncation, /RD is the recursion desired, /RA is the recursion available, /AD is the authentic data, /CD is the checking disabled, and /Z is the reserved for future use. |
Identifier |
The identifier (Transaction ID) generated by the device that creates the DNS query and is copied by the server into the response so it can be used by that device to match that query to the corresponding reply received from the DNS server. |
NS Count |
The number of the name server (NS) resource records in the authority records section. |
Op Code |
The query type. |
Qd Count |
The number of entries in the question section. |
Query Class |
The query format containing one of the RR class codes. |
Query Class Text |
The text string that corresponds to the hexadecimal value of the query format containing one of the RR class codes. |
Query Name |
The domain name requested in the query. The maximum name length is 64 bytes. If the name is longer, it will be truncated. |
Query Type |
The query format containing one of the RR type codes. |
Query Type Text |
The text string that corresponds to the hexadecimal value of the query format containing one of the RR type codes. |
Response Code |
The type of the response. |
Response Class |
The response format containing one of the RR class codes. |
Response Class Text |
The text string that corresponds to the hexadecimal value of the response format containing one of the RR class codes. |
Response Name |
The domain name in the response. The maximum name length is 64 bytes. If the name is longer, it will be truncated. |
Response Type |
The query type specified in the response. |
Response Type Text |
The text string that corresponds to the hexadecimal value of the query type specified in the response. |
Response RData Length |
The length of the rdata field in the response data field. |
Response RData |
The content that describes the resource in the response data field. The format of the rdata field varies according to the type and class of the resource record. |
Response-TTL |
The time-to-live (TTL), which is the time interval in seconds that the record is cached. |
Response iPv4 Address |
The IPv4 address in the response if the response type host and class are Internet/IPv4. |
Response iPv4 Address Text |
The text string that corresponds to the hexadecimal value of the IPv4 address in the response if the response type host and class are Internet/IPv4. The format is dotted decimal. |
Response IPv6 Address |
The IPv6 address in the response if the response type host and class are Internet/IPv6. |
Response iPv6 Address Text |
The text string that corresponds to the hexadecimal value of the IPv6 address in the response if the response type host and class are Internet/IPv6. The format is dotted decimal. |
For IPFIX only, use the collect field Private PEN ssl in the flow record definition for capturing any packet with Secure Sockets Layer (SSL) or server metadata embedded in it, such as common name. This is a private information element extension, specific to Gigamon. The only valid private enterprise name (pen) is gigamon.
Examining the parameters associated with the SSL certificate or the SSL server provides visibility into SSL flows in the network and helps detect malicious activity. For example, checking the issuer might reveal an unknown self-signed certificate or a certificate signed by a questionable Certificate Authority (CA). Checking the certificate validity dates might reveal an expired certificate.
When NetFlow collects SSL certificate metadata, it makes use of the GigaSMART SSL application, described in GigaSMART Passive TLS/SSL Decryption. The data is routed to the SSL application first and then to NetFlow. If de-duplication is also enabled, the data is routed from de-duplication to SSL, and then to NetFlow. The SSL application does not decrypt the data.
Note: Only the NetFlow Generation license is needed for NetFlow to collect SSL certificate metadata.
When certain SSL certificate parameters are configured, the corresponding values for those collect parameters can be displayed in hexadecimal format or in text format. The following SSL certificate parameters can display their values as text when the text version of that parameter is used:
Serial Number, Serial Number Text |
Signature Algorithm, Signature Algorithm Text |
Subject Algorithm, Subject Algorithm Text |
Valid Not After, Valid Not After Text |
Valid Not Before, Valid Not Before Text |
To access GigaSMART within GigaVUE-FM, access a device that has been added to GigaVUE-FM from the GigaVUE-FM interface. GigaSMART appears in the navigation pane of the device view on supported devices. Refer to the Access GigaSMART from GigaVUE‑FM for details.
To configure a record for SSL Certificate or SSL Server, do the following:
- From the device view, select GigaSMART > NetFlow / IPFIX Generation > Records.
- Click New.
- For Version, select IPFIX.
- Click in the Non-Key fields (Collect) field.
- Select Private from the drop-down list.
- In the Private non-key field, do the following:
- Set PEN to gigamon.
- Under SSL, select the SSL Certificate and SSL Server parameters and specify a width value in bytes. For example, Certificate Issuer Common Name and Certificate Subject Common Name as shown in 7.
7 | NetFlow Record Configuration for SSL |
When certain SSL server parameters are configured, the corresponding values for those collect parameters can be displayed in hexadecimal format or in text format. The following SSL server parameters can display their values as text when the text version of that parameter is used:
Cipher, Cipher Text |
Version, Version Text |
For example, if the ssl server cipher parameter collects a hexadecimal value of C027, the ssl server cipher-text parameter collects the following text string:
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
The parameters supported for the SSL certificate are as follows:
Certificate Issuer—the certificate issuer, which identifies the entity that has signed and issued the certificate. For example: "/C=US/ST=Arizona/L=Scottsdale/O=MyCo2.com, Inc./OU=http://certs.myco2.com/repository//CN=MyCo2 Secure Certificate Authority", where /C is the country name, /ST is the state or province, /L is the locality name, /O is the organization name, /OU is the organizational unit name, and /CN is the common name. |
Certificate Issuer Common Name—the certificate issuer common name, which is a subset of Issuer. |
Certificate Subject—the certificate subject, which identifies the entity associated with the public key stored in the subject public key. The Certificate Subject has the same fields as the CertificateIssuer. |
Certificate Subject Common Name—the certificate subject common name, which is a subset of Subject. |
Certificate Subject Alternative Name—the subject alternative name, which allows identities to be bound to the subject of the certificate. This parameter is useful to detect if the certificate claims to sign for anything else and to detect anomalies such as certificates that claim to sign for a wildcard (*). The first subject alternative name present in the certificate is collected. |
Certificate Valid Not Before and Certificate Valid Not After—the date on which the certificate validity period begins and ends. The certificate validity period is the time interval during which the CA warrants that it will maintain information about the status of the certificate. It is expressed in universal time. The format is YYMMDDHHMMSSZ, where Z is Zulu time (GMT). |
Certificate Valid Not Before Text and Certificate Valid Not After Text—the text string that corresponds to the hexadecimal value of the date on which the certificate validity period begins and ends. The format is MMM DD HH:MM:SS YYYY GMT. |
Certificate Serial Number—the unique number for each certificate issued by a given CA. The issuer name and serial number identify a unique certificate. This parameter is useful to detect any certificate changes or substitutions. |
Certificate Serial Number Text—the text string that corresponds to the hexadecimal value of the unique number for each certificate issued by a given CA. |
Certificate Signature Algorithm—the identifier for the cryptographic algorithm used by the CA to sign the certificate, defined in ASN.1 format. This parameter is useful to detect servers that are not compliant with an organization’s cryptographic standards. |
Certificate Signature Algorithm Text—the text string that corresponds to the hexadecimal value of the identifier for the cryptographic algorithm used by the CA to sign the certificate, defined in ASN.1 format. This parameter is useful to detect servers that are not compliant with an organization’s cryptographic standards. |
Certificate Subject Algorithm—the subject public key algorithm used, defined in ASN.1 format, such as RSA or DSA. |
Certificate Subject Algorithm Text—The text string that corresponds to the hexadecimal value of the subject public key algorithm used, defined in ASN.1 format, such as RSA or DSA. |
Certificate Subject Key Size—the subject public key size. |
Optionally, on the issuer, Certificate Issuer Common Name, Certificate Subject, Certificate Subject Common Name, and Certificate Subject Alternative Name parameters, you can indicate the width of the field in bytes.
The parameters supported for the SSL server are as follows:
Server Name Indication—the extension to the Transport Layer Security (TLS) protocol by which a client indicates the host name to which it is attempting to connect at the start of the handshaking process. |
Server Version—the version of SSL, including the major and minor version. |
Server Version Text—the text string that corresponds to the hexadecimal value of the identifier for the version of SSL, including the major and minor version. |
Server Cipher—the cipher that the server agreed to use for that session. |
Server Cipher Text—the text string that corresponds to the hexadecimal value of the identifier for the cipher that the server agreed to use for that session. |
Server Compression Method—the server compression method, which is typically not set (in other words, NULL). This parameter is useful to detect attacks that use compression. |
Server Session ID—the session identifier, generated by a server, which identifies a particular session. This parameter is useful to detect a session restart. |
Optionally, on the Server Name Indication parameter, you can indicated the width of the field in bytes.
Restrict Ports for NetFlow SSL Sessions
SSL metadata is collected by sending all traffic to the SSL module. The SSL module accepts all IPv4 TCP packets and attempts to find SSL sessions. During the process of finding these sessions, the metadata required by NetFlow is extracted.
To improve the throughput of SSL metadata extraction for NetFlow, the TCP ports can be restricted. Reducing the TCP packets inspected by limiting the TCP ports inspected reduces the amount of packets sent to the SSL module.
Configure the monitor to scan specific ports for SSL. Options are available to scan all ports, a list of up to 10 ports, or well-known ports.
The following are the well-known ports:
MAP_SSL_PORT 993 |
POP3_SSL_PORT 995 |
SMTP_SSL_PORT 465 |
LDAP_SSL_PORT 636 |
NNTP_SSL_PORT 563 |
HTTP_SSL_PORT 443 |
To access GigaSMART within GigaVUE-FM, access a device that has been added to GigaVUE-FM from the GigaVUE-FM interface. GigaSMART appears in the navigation pane of the device view on supported devices. Refer to the Access GigaSMART from GigaVUE‑FM for details.
To configure the SSL certificate and server parameters to collect, do the following in the UI, for example:
1. | From the device view, select GigaSMART > NetFlow / IPFIX Generation > Records. |
2. | Click New. |
3. | Enter an alias in the Alias field to identify this record. For example, ipfixrec. |
4. | Select IPFIX. |
5. | From the Non-Key Field (Collect) list, select Private. |
6. | Set PEN to gigamon. (This is the default.) |
7. | Under SSL, select any of the following: |
Certificate issuer Common Name Width 30 |
Certificate Subject Common Name Width 40 |
Certificate issuer Width 150 |
Certificate Subject Width 120 |
Certificate Valid Not Before |
Certificate Valid Not After |
Certificate Serial Number |
Certificate Signature Algorithm |
Certificate Signature Algorithm Text |
Certificate Subject Algorithm |
Certificate Subject Algorithm Text |
Certificate Subject Key Size |
Certificate Subject Alternative Name |
Server Name Indication Width 64 |
Server Version |
Server Version Text |
Server Cipher |
Server Cipher Text |
Server Compression Method |
Server Session ID |
8. | Click Save. |
When collecting SSL certificate metadata, the match conditions must be configured so that the NetFlow sessions match the SSL sessions. To do this, configure the following in the NetFlow record for IPv4 flows:
1. | From the device view, select GigaSMART >NetFlow Record / IPFIX Generation. |
2. | Select the record ipfixrec and click Edit. (This is the record configured in the previous section Configure SSL Certificate and Server Parameters.) |
3. | From the Key Fields (Match) list, select IPv4. |
4. | Select Protocol. |
5. | Under Source select Address. |
6. | Under Destination select Address. |
7. | From the Key Fields (Match) list, select Transport and then select the following: |
Source Port |
Destination Port |
8. | Click OK. |
Or, configure the following in the NetFlow record for IPv6 flows:
1. | From the device view, select GigaSMART >NetFlow Record / IPFIX Generation. |
2. | Select the record ipfixrec and click Edit. (This is the record configured in the previous section Configure SSL Certificate and Server Parameters.) |
3. | From the Key Fields (Match) list, select IPv6. |
4. | Select Protocol. |
5. | Under Source select Address. |
6. | Under Destination select Address. |
7. | From the Key Fields (Match) list, select Transport and then select the following: |
Source Port |
Destination Port |
8. | Click OK. |
Or, configure the following in the NetFlow record for a mix of IPv4 and IPv6 flows:
1. | From the device view, select GigaSMART >NetFlow Record / IPFIX Generation. |
2. | Select the record ipfixrec and click Edit. (This is the record configured in the previous section Configure SSL Certificate and Server Parameters.) |
3. | From the Key Fields (Match) list, select IPv4. |
4. | Select Protocol. |
5. | Under Source select Address. |
6. | Under Destination select Address. |
7. | From the Key Fields (Match) list, select IPv6. |
8. | Select Protocol. |
9. | Under Source select Address. |
10. | Under Destination select Address. |
11. | From the Key Fields (Match) list, select Transport and then select the following: |
Source Port |
Destination Port |
12. | Click OK. |
Refer to NetFlow Statistics Definitions for descriptions of these statistics as well as to GigaSMART Operations Statistics Definitions.
Refer to the following notes and considerations for SSL certificate metadata:
When the GigaSMART SSL application is gathering SSL certificate metadata for NetFlow, it is not able to decrypt SSL packets at the same time. |
Using the SSL application plus NetFlow to collect SSL certificate metadata consumes GigaSMART resources, resulting in less memory for other GigaSMART applications. |
To retrieve SSL certificate metadata, there must be a valid SSL session in which most of the packets that form the session are received, as follows: |
For the SSL certificate parameters, all packets up to at least the certificate packet must be received. |
For the SSL server parameters except SeverName Indication, all packets up to the server hello packet must be received. |
For the ServerName Indication SSL server parameter, all packets up to the client hello packet must be received. |
SNMP packet support on IP interfaces with tool ports processes SNMP packets arriving on IP interfaces with tool ports and forwards them to GigaSMART so that external NetFlow collectors can integrate with GigaSMARTNetFlow Generation.
External collectors need to recognize GigaSMARTNetFlow Generation as a valid NetFlow interface. The validation can be manual or automatic, as follows:
with manual validation, configuration on the collector side must provide the details of GigaSMARTNetFlow Generation |
with automatic validation, the recipient collector initiates an SNMP query requesting relevant information and GigaSMARTNetFlow Generation responds to it with the required information |
SNMP packet support on IP interfaces with tool ports provides automatic validation. Starting in software version 4.5, GigaSMARTNetFlow Generation processes SNMP packets arriving on IP interfaces with tool ports.
NetFlow records are sent to exporters through IP interfaces with tool ports. Each NetFlow exporter is associated with one external collector. Up to six exporters can send flow records to up to six external collectors.
An IP interface with tool port can have multiple exporters. An external collector can listen to multiple exporters.
To listen to SNMP packets from external collectors, enable SNMP under the NetFlow exporter. The following are the steps to allow external collectors to send SNMP packets to the IP interface with tool port:
1. | From the device view, select GigaSMART > NetFlow > Exporters. |
2. | Click New to create a new exporter or Edit to configure an existing exporter. |
3. | Select SNMP under the SNMP section. |
These steps enables SNMP on the default port, which is port number 161.
Note: Only the default SNMP port is supported for packets arriving on the IP interface. If the incoming request uses a non-default SNMP port, they will be dropped at the IP interface.
To disable listening for SNMP packets by a specified NetFlow exporter, uncheck the SNMP check box.
By default, listening to SNMP packets from external collectors is disabled.
NetFlow Exporters support versions IPFIX, v5, and v9. Starting in software version 5.3, the Common Event Format (CEF) version 23 is also supported. CEF is a standard format used by event collection/correlation Security Information and Event Management (SIEM) vendors. SIEMs such as Arcsight, Splunk, and QRadar accept CEF format. By supporting CEF, NetFlow metadata can integrate with and use a variety of SIEMs.
CEF is a logging format that uses the syslog message as a transport mechanism, meaning that the CEF message (header and payload) is included within the syslog message. The transport protocol that is supported is UDP and the default port number is 514.
Metadata that is generated by NetFlow can be exported in the supported formats to one or more collectors. Each exporter must have the same export type (v5, v9, IPFIX, or CEF). One CEF message is sent out per record per flow.
Also, starting in software version 5.3, IP fragmentation is supported. CEF does not allow a message to be split over multiple CEF payloads. Since CEF messages are verbose, they can be larger than the MTU.
To support CEF messages that exceed the MTU, a single IP datagram containing a CEF message will be broken up into multiple packets of smaller sizes. The reassembly of the datagram will occur at the receiving end (at the SIEMs).
For details on the CEF message format, refer to
An example of the CEF message format is as follows:
Fri Feb 23 02:25:37 2018 9/3/e1 CEF:23|Gigamon|metadata|5.3.00|4|metadatageneration|6| src=68.94.156.1 GigamonMdataDnsAdditionalType=41GigamonMdataDnsAdditionalTypeText=OPT
In the example CEF message, there is a syslog header, a CEF header, and an extension that contains the CEF payload. The fields are delimited with a vertical bar (|).
The syslog header contains the following:
timestamp—Fri Feb 23 02:25:37 2018 |
host name identifier—9/3/e1 |
Note: The host name identifier has the format <box ID>/<slot ID>/<engine ID>.For example, 9/3/e1 means 9 is the box ID, 3 is the slot ID, and e1 is the engine ID.
The CEF header contains the following:
version—CEF:23 |
device vendor—Gigamon |
device product—metadata |
device version—5.3.00 |
signature identifier—4 |
name—metadata generation |
severity—6 |
The CEF extension contains key-value pairs delimited with a space. In the example CEF message, the following is the CEF payload, in plaintext:
src=68.94.156.1 |
GigamonMdataDnsAdditionalType=41 |
GigamonMdataDnsAdditionalTypeText=OPT |
The CEF standard specifies key-value pairs. There are some predefined standardkeys, for example, src is a predefined key for source IP address.
For keys that are not predefined in the CEF standard, such as the NetFlow metadata elements in the CEF extension, there are custom-defined keys. Custom-defined keys have the following format:
<VendorNameProductNameExplanatoryKeyName> |
For example, GigamonMdataDnsAdditionalTypeText, is a custom-defined key that contains the following:
VendorName—Gigamon |
ProductName—Mdata |
ExplanatoryKeyName—DnsAdditionalTypeText |
Another example of the CEF format is the following SSL record:
Thu Mar 1 08:21:28 2018 1/1/e1 CEF:23|Gigamon|metadata|5.3.00|4|metadata
generation|6|GigamonMdataSslIssuerName=DigiCert SHA2 High Assurance S
dpt=54839 GigamonMdataSslValidNotBefore=3137303130363030303030305a
GigamonMdataSslSerialNo=0118ee3c2167b99e1b718c6eadb8fb4d00000000
GigamonMdataSslValidNotAfter=3230303131353132303030305a
GigamonMdataSslCertSigAlgo=2a864886f70d01010b
GigamonMdataSslCertSubAlgo=2a864886f70d010101
GigamonMdataSslCertSubKeySize=270 GigamonMdataSslServerVersion=771
GigamonMdataSslCertSubAltName=*.stickyadstv.com
GigamonMdataSslServerCompressionMethod=192 GigamonMdataSslServerCipher=49199
GigamonMdataSslServerVersionText=TLSv1.2 GigamonMdataSslServerSessionId=63
GigamonMdataSslIssuer=2f433d55532f4f3d446967694365727420496e632f4f553d7777772e6469676963
6572742e636f6d2f434e3d446967694365727420534841322048696768204173737572616e636
52053657276 6572204341 GigamonMdataSslCertSubCommonName=*.stickyadstv.com
GigamonMdataSslSub=2f433d55532f53543d4e657720596f726b2f4c3d4e657720596f726b2f4f3d4672656
5776865656c204d6564696120496e632f4f553d46726565776865656c2f434e3d2a2e737469636b796164737 4762e636f6d dst=10.50.22.59 src=38.106.34.118 spt=443
To display exporter statistics, select GigaSMART > GigaSMART Operations (GSOP) > Statistics and open the GigaSMART Statistics Quick View to view the NetFlow Statistics.
Refer to NetFlow Exporter Statistics Definitions for descriptions of the statistics.
To display exporter statistics, select GigaSMART > GigaSMART Operations (GSOP) > Statistics and open the GigaSMART Statistics Quick View to view the NetFlow Statistics.
Refer to NetFlow Monitor Statistics Definitions for descriptions of these statistics.
To display IP interfaces statistics, select Ports > IP Interfaces > Statistics and look for the IP interface ID in the statistics table.
Refer to IP Interfaces Statistics Definitions for descriptions of these statistics.
There may be instances where a NetFlow Generation configuration may require alteration by modifying a NetFlow Generation Monitor Configuration or a NetFlow Generation Record Configuration. It may further require that the configuration be removed entirely. In such instances, refer to the following.
This example shows the modification of a NetFlow Generation Monitor configuration.
1. | Unlink the monitor from GigaSMART Parameters. |
a. | From the device view, select GigaSMART > GigaSMART Groups > GigaSMART Groups. |
b. | Select the GigaSMART group to modify. |
c. | Click Edit. |
d. | Under NetFlow, select None in the Monitor field. |
e. | Click Save. |
2. | Modify the monitor parameters. |
a. | From the device view, select GigaSMART > NetFlow / IPFIX Generation > Monitors. |
b. | Select the Monitor to modify. |
c. | Click Edit. |
d. | Under Config, modify the monitor parameters. |
e. | Select the record from the Record(s) list to re-add it to the monitor. |
3. | Re-add the monitor to GigaSMART Parameters for the changes to take affect. |
a. | From the device view, select GigaSMART > GigaSMART Groups > GigaSMART Groups. |
b. | Select the GigaSMART group to modify. |
c. | Click Edit. |
d. | Under NetFlow, select the monitor in the Monitor field. |
e. | Click Save. |
This example shows the modification of a NetFlow Generation Record configuration.
1. | Unlink the monitor from gsparams. |
a. | From the device view, select GigaSMART > GigaSMART Groups > GigaSMART Groups. |
b. | Select the GigaSMART group to modify. |
c. | Click Edit. |
d. | Under NetFlow, select None in the Monitor field. |
e. | Click Save. |
2. | Modify the record bound to the monitor. |
a. | From the device view, select GigaSMART > NetFlow / IPFIX Generation > Records. |
b. | Select the record to modify. |
c. | Click Edit. |
d. | Modify the record configuration. |
3. | Re-add the monitor to the GigaSMART Parameters for changes in record to take affect. |
a. | From the device view, select GigaSMART > GigaSMART Groups > GigaSMART Groups. |
b. | Select the GigaSMART group to modify. |
c. | Click Edit. |
d. | Under NetFlow, select the monitor in the Monitor field. |
e. | Click Save. |
Use the following steps to remove a NetFlow Generation Configuration:
1. | Remove the NetFlow parameter from the GigaSMART Group. |
a. | From the device view, select GigaSMART > GigaSMART Groups > GigaSMART Groups. |
b. | Select the GigaSMART Group. |
c. | Click Edit. |
d. | Under NetFlow, select None in the Monitor field. |
2. | Delete the Maps. |
a. | Select Maps > Maps > Maps. |
b. | Select Table View. |
c. | Select the Maps. |
d. | Click Delete. |
3. | Delete the IP interface. |
a. | Select Ports > IP Interfaces. |
b. | Select the port. |
c. | Click Delete. |
4. | Delete the monitor, records, and exporter |
a. | From the device view, select GigaSMART > NetFlow / IPFIX Generation > Monitors. |
b. | Select the monitor, and then click Delete. |
c. | Select Records |
d. | Select the record, and then click Delete |
e. | Select Records. |
f. | Select the record, and then click Delete. |
NetFlow v5 records have a template of fixed fields that cannot be edited. The template contains Match/Key and Collect/Non-Key elements. It has an alias of predefined_netflow_v5_record.
To display the template, select GigaSMART > NetFlow / IPFIX Generation > Records and click on predefined_netflow_v5_record to display the Record Quick View shown in 8.
8 | NetFlow Record predefined_netflow_v5_record |
NetFlow v9 and IPFIX records allow the user to configure Match/Key and Collect/Non-Key elements.
NetFlow v9 and IPFIX records allow the you to configure Match/Key elements.
Note: NetFlow v9 does not support Match/Key elements whose ID on the specified link is greater than 128. For additional information, refer to the following:
http://www.iana.org/assignments/ipfix/ipfix.xhtml
To configure the Match/Key elements, click in the Key Fields (Match) field in the NetFlow Record configuration page and select the match type.
The supported combinations of Match/Key elements are outlined in the following table:
Match Type |
Parameters |
|
|
Description |
Data Link |
Source Mac |
|
|
Supported for v9 and IPFIX. |
|
Destination |
|
|
Supported for v9 and IPFIX. |
|
VLAN |
|
|
Supported for v9 and IPFIX. |
Interface |
Input physical |
Physical Width-2 Physical Width-4 |
|
Supported for v9 and IPFIX. for width, the only supported values are 2 or 4. |
IPv4 |
Destination |
Address |
|
Configures the IPv4 destination address as a key field. Supported for v9 and IPFIX. |
|
|
Prefix |
<netmask | mask_length> |
Configures a prefix for the IPv4 destination address as a key field. Supported for v9 and IPFIX. |
|
DSCP |
|
|
Supported only for IPFIX. |
|
Fragmentation Flags |
|
|
Supported only for IPFIX. |
|
Fragmentation ID |
|
|
Supported for v9 and IPFIX. |
|
Fragmentation Offset |
|
|
Supported for v9 and IPFIX. |
|
Header Length |
|
|
Supported only for IPFIX. |
|
Option Map |
|
|
Supported only for IPFIX. |
|
Precedence |
|
|
Supported only for IPFIX. |
|
Protocol |
|
|
Supported for v9 and IPFIX. |
|
Section |
Header Size |
<size> |
Configures the number of bytes of raw data starting at the IPv4 header, to use as a key field. The range is from 1 to 128. Supported only for IPFIX. |
|
|
Payload Size |
<size> |
Configures the number of bytes of raw data starting at the IPv4 payload, to use as a key field. The range is from 1 to 128. Supported only for IPFIX. |
|
Source |
Address |
|
Supported for v9 and IPFIX. |
|
|
Prefix |
<netmask | mask_length> |
Supported for v9 and IPFIX. |
|
TOS |
|
|
Supported only for IPFIX. |
|
Total Length |
maximum | minimum |
|
Supported only for IPFIX. |
|
TTL |
|
|
Supported only for IPFIX. |
|
Version |
|
|
Supported for v9 and IPFIX. |
IPv6 |
Destination |
Address |
|
Supported for v9 and IPFIX. |
|
|
Prefix |
<netmask | mask_length> |
Supported only for IPFIX. |
|
DSCP |
|
|
Supported only for IPFIX. |
|
Extension Map |
|
|
Supported for v9 and IPFIX. |
|
Flow Label |
|
|
Supported for v9 and IPFIX. |
|
Fragmentation Flags |
|
|
Supported only for IPFIX. |
|
Fragmentation ID |
|
|
Supported for v9 and IPFIX. |
|
Fragmentation Offset |
|
|
Supported for v9 and IPFIX. |
|
Hop Limit |
|
|
Supported only for IPFIX. |
|
Length |
Header |
|
Supported only for IPFIX. |
|
|
Payload |
|
Supported only for IPFIX. |
|
|
Total |
|
Supported only for IPFIX. |
|
Next Header |
|
|
Supported only for IPFIX. |
|
payload-length |
|
|
Supported only for IPFIX. |
|
Precedence |
|
|
Supported only for IPFIX. |
|
Protocol |
|
|
Supported for v9 and IPFIX. |
|
Section |
Header Size |
<size> |
Supported only for IPFIX. The range is from 1 to 128. |
|
|
Payload Size |
<size> |
Supported only for IPFIX. The range is from 1 to 128. |
|
Source |
Address |
|
Supported for v9 and IPFIX. |
|
|
Prefix |
<netmask | mask_length> |
Supported only for IPFIX. |
|
Traffic Class |
|
|
Supported for v9 and IPFIX. |
|
Version |
|
|
Supported for v9 and IPFIX. |
Transport |
Destination Port |
|
|
Supported for v9 and IPFIX. |
|
ICMP |
IPv4 |
Code |
Supported only for IPFIX. |
|
|
|
Type |
Supported only for IPFIX. |
|
|
IPv6 |
Code |
Supported only for IPFIX. |
|
|
|
Type |
Supported only for IPFIX. |
|
Source Port |
|
|
Supported for v9 and IPFIX. |
|
TCP |
ACK Number |
|
Supported only for IPFIX. |
|
|
Destination Port |
|
Supported only for IPFIX. |
|
|
Flags <enable | disable> |
[ACK] | [CWR] | [ECE] | [FIN] | [PSH] | [RST] | [SYN] | [URG] |
Supported only for v9 and IPFIX. |
|
|
Header Length |
|
Supported only for IPFIX. |
|
|
Sequence Number |
|
Supported only for IPFIX. |
|
|
Source Port |
|
Supported only for IPFIX. |
|
|
Urgent Pointer |
|
Supported only for IPFIX. |
|
|
window-size |
|
Supported only for IPFIX. |
|
UDP |
Destination Port |
|
Supported only for IPFIX. |
|
|
Message Length |
|
Supported only for IPFIX. |
|
|
Source Port |
|
Supported only for IPFIX. |
NetFlow v9 and IPFIX records allow the user to configure Collect/Non-Key elements.
The number of Collect/Non-Key elements in a record can be up to 32. Each Collect/Non-Key element has a size. The accumulated size of the Collect/Non-Key elements in the record cannot exceed 1024 bytes. The supported Collect/Non-Key elements is determined either by the maximum number of elements in a record (32) or by the maximum size (1024 bytes), whichever is reached first.
Note: NetFlow v9 does not support Collect/Non-Key elements whose ID on the specified link is greater than 128. For additional information, refer to the following:
http://www.iana.org/assignments/ipfix/ipfix.xhtml
To configure the Collect/Non-Key elements, click in the Non-Key Fields (Collect) field in the NetFlow Record configuration page and select the match type.
The supported combinations of Collect/Non-Key elements are outlined in the following table:
Collect Type |
Parameters |
Size |
|
Description |
Counter |
Bytes |
32 64 |
|
Supported for v9 and IPFIX. |
|
Packets |
32 64 |
|
Supported for v9 and IPFIX. |
Datalink |
Source |
|
|
Supported for v9 and IPFIX. |
|
Mac Destination |
|
|
Supported for v9 and IPFIX. |
|
VLAN |
|
|
Supported for v9 and IPFIX. |
Flow |
End Reason |
|
|
Supported only for IPFIX. |
Interface |
Input Name |
Input Width |
[width] |
Supported for v9 and IPFIX. for width, the range is from 1 to 32. |
|
Physical |
Physical Width-2 Physical Width-4 |
|
Supported for v9 and IPFIX. For width, the only supported values are 2 or 4. |
|
Output |
Physical Width-2 Physical Width-4 |
|
Supported for v9 and IPFIX. For width, the only supported values are 2 or 4. |
IPv4 |
Destination |
Address |
|
Configures the IPv4 destination address as a non-key field. Supported for v9 and IPFIX. |
|
|
Prefix |
<netmask | mask_length> |
Supported for v9 and IPFIX. |
|
DSCP |
|
|
Supported only for IPFIX. |
|
Fragmentation Flags |
|
|
Supported only for IPFIX. |
|
Fragmentation ID |
|
|
Supported for v9 and IPFIX. |
|
Offset |
|
|
Supported for v9 and IPFIX. |
|
Header Length |
|
|
Supported only for IPFIX. |
|
Option Map |
|
|
Supported only for IPFIX. |
|
Precedence |
|
|
Supported only for IPFIX. |
|
Protocol |
|
|
Supported for v9 and IPFIX. |
|
Section |
Header Size |
<size> |
Configures the number of bytes of raw data starting at the IPv4 header, to use as a key field. The range is from 1 to 128. Supported for v9 and IPFIX. |
|
|
Payload Size |
<size> |
Configures the number of bytes of raw data starting at the IPv4 payload to use as a key field. The range is from 1 to 128. Supported for v9 and IPFIX. |
|
Source |
Address |
|
Supported for v9 and IPFIX. |
|
|
Prefix |
<netmask | mask_length> |
Configures a prefix for the IPv4 destination address as a non-key field. Supported for v9 and IPFIX. |
|
TOS |
|
|
Supported only for IPFIX. |
|
Total Length |
[maximum] |
|
Supported only for IPFIX. |
|
|
[minimum] |
|
Supported only for IPFIX. |
|
TTL |
|
|
Supported only for IPFIX. |
|
Version |
|
|
Supported for v9 and IPFIX. |
IPv6 |
Destination |
Address |
|
Supported for v9 and IPFIX. |
|
|
Prefix |
<netmask | mask_length> |
Supported only for IPFIX. |
|
DSCP |
|
|
Supported only for IPFIX. |
|
Extension Map |
|
|
Supported for v9 and IPFIX. |
|
Flow Label |
|
|
Supported for v9 and IPFIX. |
|
Fragmentation Flags |
|
|
Supported only for IPFIX. |
|
Fragmentation ID |
|
|
Supported for v9 and IPFIX. |
|
Fragmentation Offset |
|
|
Supported for v9 and IPFIX. |
|
Hop Limit |
[maximum] |
|
Supported only for IPFIX. |
|
|
[minimum] |
|
Supported only for IPFIX. |
|
Length |
Header |
|
Supported for v9 and IPFIX. |
|
|
Payload |
|
Supported only for IPFIX. |
|
|
Total |
[maximum] |
Supported only for IPFIX. |
|
|
|
[minimum] |
Supported only for IPFIX. |
|
Next Header |
|
|
Supported only for IPFIX. |
|
Precedence |
|
|
Supported only for IPFIX. |
|
Protocol |
|
|
Supported for v9 and IPFIX. |
|
Section |
Header Size |
<size> |
Supported only for IPFIX. The range is from 1 to 128. |
|
|
Payload Size |
<size> |
Supported only for IPFIX. The range is from 1 to 128. |
|
Source |
Address |
|
Supported for v9 and IPFIX. |
|
|
Prefix |
<netmask | mask_length> |
Configures a prefix for the IPv4 destination address as a non-key field. Supported only for IPFIX. |
|
Traffic Class |
|
|
Supported for v9 and IPFIX. |
|
Version |
|
|
Supported for v9 and IPFIX. |
Private |
PEN <pen name> |
DNS |
<additional-class [number-of-collects <1-10>] | additional-class-text [number-of-collects <1-10>] |additional-name [number-of-collects <1-10>] | additional-rd-length [number-of-collects <1-10>] | additional-rdata [number-of-collects <1-10> | width <1-128>] | additional-ttl [number-of-collects <1-10>] | additional-type [number-of-collects <1-10>] | additional-type-text [number-of-collects <1-10>] | an-count | ar-count |authority-class [number-of-collects <1-10>] | authority-class-text [number-of-collects <1-10>] | authority-name [number-of-collects <1-10>] | authority-rd-length [number-of-collects <1-10>] | authority-rdata [number-of-collects <1-10> | width <1-128>] | authority-ttl [number-of-collects <1-10>] | authority-type [number-of-collects <1-10>] | authority-type-text [number-of-collects <1-10>] | bits | identifier | ns-count | op-code | qd-count | query-class [number-of-collects <1-10>] | query-class-text [number-of-collects <1-10>] | query-name [number-of-collects <1-10>] | query-type [number-of-collects <1-10>] | |
Supported only for IPFIX. |
Private (continued) |
PEN <pen name> |
DNS |
query-type-text [number-of-collects <1-10>] | response-class [number-of-collects <1-10>] | response-class-text [number-of-collects <1-10>] | response-code | response-ipv4-addr [number-of-collects <1-10>] |response-ipv4-addr-text [number-of-collects <1-10>] | response-ipv6-addr [number-of-collects <1-10>] | response-ipv6-addr-text [number-of-collects <1-10>] |response-name [number-of-collects <1-10>] | response-rd-length [number-of-collects <1-10>] | response-rdata [number-of-collects <1-10> | width <1-128>] | response-ttl [number-of-collects <1-10>] | response-type [number-of-collects <1-10>] |response-type-text [number-of-collects <1-10>]> |
Supported only for IPFIX. |
Private |
PEN <pen name> |
HTTP |
Response Code |
Supported only for IPFIX. |
Private |
PEN <pen name> |
HTTP |
URL |
Supported only for IPFIX. For width, the range is from 1 to 250. |
Private |
PEN <pen name> |
HTTP |
User Agent |
Supported only for IPFIX. For width, the range is from 1 to 250. |
Private |
PEN <pen name> |
SSL Certificate |
<Issuer [width] | Issuer Common Name [width] | Serial Number | Serial Number Text | Signature Algorithm |Signature Algorithm Text | Subject [width] | Subject Algorithm | Subject Algorithm Text | Subject Alternative Name [width] | Subject Common Name | [width] | Subject Key Size | Valid Not After | Valid Not After Text | Valid Not Before | Valid Not Before Text> |
Supported only for IPFIX. For width of Issuer and Subject, the range is from 1 to 250. For width of Issuer Common Name, Subject Alternative Name, and Subject Common Name, the range is from 1 to 64. |
Private |
PEN <pen name> |
SSL Server |
<Cipher | Cipher Text | Compression Method | Name Indication [width] | Session ID | Version | Version Text> |
Supported only for IPFIX. For width, the range is from 1 to 64. |
Private |
PEN <pen name> |
URL |
[width] |
Supported only for IPFIX. For width, the range is from 1 to 250. |
timestamp |
Sys-uptime First |
|
|
Supported for v9 and IPFIX. |
|
Sys-uptime First Last |
|
|
Supported for v9 and IPFIX. |
transport |
Destination Port |
|
|
Supported for v9 and IPFIX. |
|
ICMP |
IPv4 Code |
|
Supported only for IPFIX. |
|
|
IPv4 Code Type |
|
Supported only for IPFIX. |
|
|
ipv6 Code |
|
Supported only for IPFIX. |
|
|
ipv6 Type |
|
Supported only for IPFIX. |
|
Source Port |
|
|
Supported for v9 and IPFIX. |
|
TCP Flags |
[ACK] | [CWR] | [ECE] | [FIN] | [PSH] | [RST] | [SYN] | [URG] |
|
Supported for v9 and IPFIX. |
|
TCP |
ACK Number |
|
Supported only for IPFIX. |
|
|
Destination Port |
|
Supported only for IPFIX. |
|
|
Header Length |
|
Supported only for IPFIX. |
|
|
Sequence Number |
|
Supported only for IPFIX. |
|
|
Source Port |
|
Supported only for IPFIX. |
|
|
Urgent Pointer |
|
Supported only for IPFIX. |
|
|
Window Size |
|
Supported only for IPFIX. |
|
UDP |
Destination Port |
|
Supported only for IPFIX. |
|
|
Message Length |
|
Supported only for IPFIX. |
|
|
Source Port |
|
Supported only for IPFIX. |
Classic NetFlow operates in a cacheless mode and exports packets using TCP protocol. NetFlow monitor enables you to set the cache timeout to zero and makes the NetFlow to operate in a cacheless mode. Each packet received by the NetFlow is treated as a complete flow and the metadata extracted from the packet are immediately exported without caching the flow.
The two main advantages of a cacheless mode are as follows:
- The metadata are directly sent to the export buffer as they are not copied to cache.
- The cacheless mode provides more record space.
When NetFlow operates in a cacheless mode, the NetFlow sends metadata for every incoming packet, hence the number of flows are equal to the number of incoming packets.
For NetFlow to export packets in TCP, you should Configure Apps Exporter, which is also used by 3GPP CUPS and Tunneling.
- You must define at least 2 exporters, such as apps exporter, apps netflow exporter.
- You must provide same name for the exporters. The name must be followed by a number in the range from 1 to 9.
- You can add up to 64 apps exporters to one NetFlow Engine. Flows is load balanced across these exporters based on the inner IP address and the direction of the flow.
- You can export only IPv4 using TCP through the exporter.
- The maximum number of bytes exported for the inner payload data is 9600.
- If a record has any inner collects and the packet does not have any inner fields , the record will not be collected.
-
In a cluster environment, when there is a NetFlow configuration, the backup-and-restore functionality does not work as expected. The restore operation does not push the configuration to the GigaSMART engine of non-master nodes. It is recommended to copy and paste the configuration backup file instead of running the “config text apply” operation.
For more information about the commands, refer to GigaVUE-OS CLI Reference Guide.