GigaSMART NetFlow Generation

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.

The GigaSMART group specifies the GigaSMART engine to use, such as 8/1/e1 or 8/1/e2.

GSOP

The GigaSMART operation enables NetFlow. If a second level map is configured, the GigaSMART operation directs traffic to APF first, and then to NetFlow.

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.

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:

o

Set PEN to gigamon. (This is the default.)

o

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.

Table 6: DNS Parameters

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:

1. From the device view, select GigaSMART > NetFlow / IPFIX Generation > Records.
2. Click New.
3. For Version, select IPFIX.
4. Click in the Non-Key fields (Collect) field.
5. Select Private from the drop-down list.
6. 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:

o

Certificate issuer Common Name Width 30

o

Certificate Subject Common Name Width 40

o

Certificate issuer Width 150

o

Certificate Subject Width 120

o

Certificate Valid Not Before

o

Certificate Valid Not After

o

Certificate Serial Number

o

Certificate Signature Algorithm

o

Certificate Signature Algorithm Text

o

Certificate Subject Algorithm

o

Certificate Subject Algorithm Text

o

Certificate Subject Key Size

o

Certificate Subject Alternative Name

o

Server Name Indication Width 64

o

Server Version

o

Server Version Text

o

Server Cipher

o

Server Cipher Text

o

Server Compression Method

o

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:

o

Source Port

o

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:

o

Source Port

o

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:

o

Source Port

o

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:

o

For the SSL certificate parameters, all packets up to at least the certificate packet must be received.

o

For the SSL server parameters except SeverName Indication, all packets up to the server hello packet must be received.

o

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

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 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.