|
|
|
|
|
|
|
|
|
sourceMacAddress |
|
|
|
IEEE 802 source MAC address field. This field is collected only for a monitor attached in the ingress direction.
|
|
<collect | match> datalink mac source address input
|
|
postDestinationMacAddress |
|
|
|
The definition of this information element is identical to the definition of information element “destinationMacAddress,” except that it reports a potentially modified value caused by a middlebox function after the packet has passed the observation point.
|
|
<collect | match> datalink mac destination address output
|
|
vlanId |
|
|
|
IEEE 802.1Q VLAN identifier (VID) extracted from the tag control Information field that was attached to the IP packet.
This field is collected only for a monitor attached in the ingress direction.
|
|
<collect | match> datalink source-vlan-id
|
|
postVlanId |
|
|
|
The definition of this information element is identical to the definition of information element “vlanId,” except that it reports a potentially modified value caused by a middlebox function after the packet has passed the observation point.
|
|
<collect | match> datalink destination-vlan-id
|
|
destinationMacAddress |
|
|
|
IEEE 802 destination MAC address field. This field is collected only for a monitor attached in the ingress direction.
|
|
<collect | match> datalink mac destination address input
|
|
postSourceMacAddress |
|
|
|
The definition of this information element is identical to the definition of information element “sourceMacAddress,” except that it reports a potentially modified value caused by a middlebox function after the packet has passed the observation point.
|
|
<collect | match> datalink mac source address output
|
|
observationPointId |
|
|
|
An identifier of an observation point that is unique for each observation domain. It is recommended that this identifier be unique for each IPFIX device. Typically, this information element is used for limiting the scope of other information elements.
The field contains 8 bytes:
The 4 most significant bytes (MSBs) indicate the type. Currently, only type 1 is supported. When type is "1," the 4 least significant bytes (LSBs) indicate the interface SNMP index, which is also listed in the interface option template.
Observation Point Id: 4294967309 = 0x000000010000000D
The 4 MSBs indicate a type of 1. The 4 LSBs indicate that the SNMP index for the interface is 0xD.
|
|
<collect | match> flow observation point
|
|
tcpOptions |
|
|
|
TCP options in packets of this flow. The information is encoded in a set of bit fields. For each TCP option, there is a bit in this set. The bit is set to 1 if any observed packet of this flow contains the corresponding TCP option. Otherwise, if no observed packet of this flow contained the respective TCP option, the value of the corresponding bit is 0.
|
|
collect transport tcp option map
|
|
initiatorOctets |
|
|
|
Total number of layer 4 payload bytes in a flow from the initiator. The initiator is the device that triggered the session creation, and remains the same for the life of the session.
|
|
collect counter initiator bytes long
|
|
serverOctets |
|
|
|
Total number of layer 4 payload bytes in a flow from the server.
The server is the device that replies to the client, and remains the same for the life of the session.
|
|
collect connection server counter bytes long
|
|
egressVRFID |
|
|
|
Unique identifier of the VRF name where the packets of this flow are being sent. This identifier is unique per metering process.
|
|
<collect | match> routing vrf output
|
|
biflowDirection |
|
|
|
A description of the direction assignment method used to assign the Biflow Source and Destination. This Information Element may be present in a Flow Data Record, or applied to all flows exported from an Exporting Process or Observation Domain using IPFIX Options. If this Information Element is not present in a Flow Record or associated with a Biflow via scope, it is assumed that the configuration of the direction assignment method is done out-of-band. Note that when using IPFIX Options to apply this Information Element to all flows within an Observation Domain or from an Exporting Process, the Option SHOULD be sent reliably. If reliable transport is not available (i.e., when using UDP), this Information Element SHOULD appear in each Flow Record.
|
|
collect connection initiator
|
|
connectionCountNew |
|
|
|
This information element counts the number of TCP or UDP connections which were opened during the observation period. The observation period may be specified by the flow start and end timestamps.
|
|
collect connection new-connections
|
|
connectionSumDurationSeconds |
|
|
|
This information element aggregates the total time in seconds for all of the TCP or UDP connections which were in use during the observation period. For example if there are 5 concurrent connections each for 10 seconds, the value would be 50 s.
|
|
collect connection sum-duration
|
|
|
|
|
|
Identifies a transaction within a connection. A transaction is a meaningful exchange of application data between two network devices or a client and server. A transactionId is assigned the first time a flow is reported, so that later reports for the same flow will have the same transactionId. A different transactionId is used for each transaction within a TCP or UDP connection. The identifiers need not be sequential.
|
|
match connection transaction-id
|
|
clientPackets |
|
|
|
Total number of layer 4 packets in a flow from the client. The client is the device that triggered the session creation, and remains the same for the life of the session.
|
|
collect connection client counter packets long
|
|
serverPackets |
|
|
|
Total number of layer 4 packets in a flow from the server. The server is the device that replies to the client, and remains the same for the life of the session.
|
|
collect connection server counter packets long
|
|
monitoringIntervalStartMilliSeconds |
|
|
|
The absolute timestamp at which a monitoring interval starts. A monitoring interval is the period during which the metering Process is running.
|
|
match timestamp absolute monitoring-interval start
|
|
tcpWindowSizeMin |
|
|
|
|
|
collect transport tcp window-size minimum
|
|
tcpWindowSizeMax |
|
|
|
|
|
collect transport tcp window-size maximum
|
|
tcpMaximumSegmentSize |
|
|
|
TCP maximum segment size.
|
|
collect transport tcp maximum-segment-size
|
|
tcpWindowSizeSum |
|
|
|
Sum of TCP window size values. Divide by packet counter to get average.
|
|
collect transport tcp window-size sum
|
|
retransPackets |
|
|
|
Number of packets retransmitted by the client
|
|
collect connection client counter packets retransmitted
|
|
transactionCountDelta |
|
|
|
Total number of completed transactions observed for this flow.
|
|
collect connection transaction counter complete
|
|
sumTransactionTime |
|
|
|
Transaction time is the time between the client request and the corresponding last response packet from the server, as observed at the observation point. The value is the sum of all transaction times observed for this flow.
For the average, this field must be divided by transactionCountDelta (42040).
|
|
collect connection transaction duration sum
|
|
maxTransactionTime |
|
|
|
Maximum transaction time observed for this flow.
|
|
collect connection transaction duration max
|
|
minTransactionTime |
|
|
|
Minimum transaction time observed for this flow.
|
|
collect connection transaction duration min
|
|
numRespsCo untDelta |
|
|
|
Total number of responses sent by the server.
|
|
collect connection server counter responses
|
|
numResps1CountDelta |
|
|
|
Histogram Bucket 1 for response time. The bucket boundary should be specified in an option template or predefined in the reporting entity.
|
|
collect connection delay response to-server histogram
|
|
numResps2CountDelta |
|
|
|
Histogram Bucket 2 for response time. The bucket boundary should be specified in an option template or predefined in the reporting entity.
|
|
collect connection delay response to-server histogram
|
|
numResps3CountDelta |
|
|
|
Histogram Bucket 3 for response time. The bucket boundary should be specified in an option template or predefined in the reporting entity.
|
|
collect connection delay response to-server histogram
|
|
numResps4CountDelta |
|
|
|
Histogram Bucket 4 for response time. The bucket boundary should be specified in an option template or predefined in the reporting entity.
|
|
collect connection delay response to-server histogram
|
|
numResps5CountDelta |
|
|
|
Histogram Bucket 5 for response time. The bucket boundary should be specified in an option template or predefined in the reporting entity.
|
|
collect connection delay response to-server histogram
|
|
numResps6CountDelta |
|
|
|
Histogram Bucket 6 for response time. The bucket boundary should be specified in an option template or predefined in the reporting entity.
|
|
collect connection delay response to-server histogram
|
|
numResps7CountDelta |
|
|
|
Histogram Bucket 7 for response time. The bucket boundary should be specified in an option template or predefined in the reporting entity.
|
|
collect connection delay response to-server histogram
|
|
numLateRespsCountDelta |
|
|
|
Total number of late responses sent by the server. A late response is a response whose time is greater than the last bucket. This informational element can be treated as the last bucket that has no end limit.
|
|
collect connection delay response to-server histogram
|
|
sumRespTime |
|
|
|
Response time is the time between the client request and the corresponding first response packet from the server, as observed at the observation point. The value of this information element is the sum of all response times observed for the responses of this flow. For the average, this field must be divided by numRespsCountDelta (42060).
|
|
collect connection delay response to-server sum
|
|
maxRespTime |
|
|
|
Maximum response time observed for this flow.
|
|
collect connection delay response to-server max
|
|
minRespTime |
|
|
|
Minimum response time observed for this flow.
|
|
collect connection delay response to-server min
|
|
sumServerRespTime |
|
|
|
|
|
collect connection delay application sum
|
|
maxServerRespTime |
|
|
|
Maximum application delay observed for the responses of this flow.
|
|
collect connection delay application max
|
|
minServerRespTime |
|
|
|
Minimum application delay observed for the responses of this flow.
|
|
collect connection delay application min
|
|
sumTotalRespTime |
|
|
|
Total delay is the time between the client request and the first response packet from the server, as seen by the client. This is the sum of all total delays observed for the responses of this flow.
For the average, this field must be divided by numRespsCountDelta (42060)
|
|
collect connection delay response client-to-server sum
|
|
maxTotalRespTime |
|
|
|
Maximum total delay observed for the responses of this flow.
|
|
collect connection delay response client-to-server max
|
|
minTotalRespTime |
|
|
|
Minimum total delay observed for the responses of this flow.
|
|
collect connection delay response client-to-server min
|
|
sumNwkTime |
|
|
|
Network delay is the round-trip time between the client and the server, as measured by the observation point, calculated once per session. The value of this information element is the sum of all network delays observed for the sessions of this flow.
For the average, this field must be divided by connectionCountNew (278).
|
|
collect connection delay network client-to-server sum
|
|
maxNwkTime |
|
|
|
|
|
collect connection delay network client-to-server max
|
|
minNwkTime |
|
|
|
|
|
collect connection delay network client-to-server min
|
|
sumClientNwkTime |
|
|
|
Client network delay is the round-trip time between the observation point and the client, calculated once per session. The value of this information element is the sum of all client network delays observed for the sessions of this flow.
For the average, this field must be divided by connectionCountNew (278).
|
|
collect connection delay network to-client sum
|
|
maxClientNwkTime |
|
|
|
Maximum client network delay observed for the sessions of this flow.
|
|
collect connection delay network to-client max
|
|
minClientNwkTime |
|
|
|
Minimum client network delay observed for the sessions of this flow.
|
|
collect connection delay network to-client min
|
|
sumServerNwkTime |
|
|
|
Server network delay is the round-trip time between the observation point and the server, calculated once per session. The value of this information element is the sum of all server network delays observed for the sessions of this flow.
For the average, this field must be divided by connectionCountNew (278)
|
|
collect connection delay network to-server sum
|
|
maxServerNwkTime |
|
|
|
Maximum server network delay observed for the sessions of this flow.
|
|
collect connection delay network to-server max
|
|
minServerNwkTime |
|
|
|
Minimum server network delay observed for the sessions of this flow.
|
|
collect connection delay network to-server min
|
|
clientIPv4Address |
|
|
|
The IPv4 client address in the IP packet header. This may be the source or destination IP address, depending on the first packet of the connection. The client is the device that triggered the session creation, and remains the same for the life of the session.
|
|
<collect | match> client ipv4 address
|
|
serverIPv4Address |
|
|
|
The IPv4 server address in the IP packet header. The server is the device that replies to the client, and remains the same for the life of the session.
|
|
<collect | match> server ipv4 address
|
|
clientIPv6Address |
|
|
|
The IPv6 client address in the IP packet header. The client is the device that triggered the session creation, and remains the same for the life of the session.
|
|
<collect | match> client ipv6 address
|
|
serverIPv6Address |
|
|
|
IPv6 server address in the IP packer header. The server is the device that replies to the client, and remains the same for the life of the session.
|
|
<collect | match> server ipv6 address
|
|
clientTransportPort |
|
|
|
Client transport port identifier. This may be the source or destination transport port. The client is the device that triggered the session creation, and remains the same for the life of the session.
|
|
<collect | match> client transport port
|
|
serverTransportPort |
|
|
|
Server transport port identifier. This may be the source or destination transport port. The server is the device that replies to the client, and remains the same for the life of the session.
|
|
<collect | match> server transport port
|
|
classHierarchy |
|
|
|
Identifies the policy-map hierarchy for different policy-map types. The field contains the policy-id, followed by a list of classes representing the policy hierarchy:
{Pi | Ck … Cl}.
A dedicated option template contains the policy and class id mapping to name and type.
|
|
<collect | match> policy performance-monitor classification hierarchy
|
|
servicesWaasSegment |
|
|
|
WAAS optimization “segment” can have one of the following values:
|
|
<collect | match> services waas segment
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
servicesWaasPassThroughReason |
|
|
|
WAAS optimization pass-through reason can have one of the following values:
|
|
collect services waas passthrough-reason
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PT_FLOWSW_INT_ACL_DENY_INX
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
match policy qos queue id
|
|
|
|
|
|
QoS Policy drops per queue
|
|
collect policy qos queue drops
|
|
|
|
|
|
Identifies a connection. A connection identifier is created when a new TCP or UDP flow is created between server and client. A single connection can hold several transactions.
|
|
|