Logging and Reporting Function for Subscribers
The logging and reporting function (LRF) enables you to log data for TDF subscriber data sessions and send that data in an IPFIX format to an external log collector using UDP-based transport. These data session logs can include subscriber information, application information, HTTP metadata, data volume, time-of-day information, and source and destination details.
The external collector, which is not a Juniper Networks product, may then use this data to perform analytics that provide you with insights about subscriber and application usage, allowing you to create packages and policies that increase revenue.
Log and Report Control
A TDF subscriber’s data sessions are logged and sent to collectors based on an LRF profile you configure and associate with the subscriber.
The LRF profile includes:
Templates—Specify the type of data that you want sent and the trigger that causes data to be sent. You can configure a maximum of 16 templates in an LRF profile.
Collectors—Identify the destination to send data to. You can configure a maximum of eight collectors in an LRF profile.
LRF rules—Specify the template and collector to use and, if applicable, a data volume limit or a time limit that triggers the sending of data. An LRF rule’s actions are performed when the matching conditions in a static PCC rule that references the LRF rule are met. You can configure a maximum of 32 LRF rules in an LRF profile.
You associate the LRF profile with a subscriber by assigning the LRF profile to the subscriber-aware TDF service set that belongs to the TDF interface (mif) in the subscriber’s TDF domain.
You specify the data fields in a template by configuring one or more types for the template; for example, HTTP and IPv4. Each type represents a set of fields, and the template you configure includes fields from all the types you configure. The template is sent to the collector when you configure it, and is re-sent at a configurable interval. The template types that you can select and the fields that are included by each type are:
Device Data—Contains data fields specific to the device collecting the logging feed:
DPI Engine Version
IP address of SCG/BNG (in IPv4 format)
DNS—Contains the DNS response time data field.
Flow ID—Contains the Flow ID data field.
When HTTP multiple transaction logging is enabled, FlowID is an implicit type that gets included with the HTTP template. When the consolidated session log is generated at the time of SESSION_CLOSE, LRF includes the FlowID that can be used to correlate with the HTTP transaction log records.
HTTP—Contains data fields for the HTTP meta-data from header fields:
Content Length - Request
HTTP Response Code
Time to First Byte
IFL subscriber—Contains data fields specific to IFL-based subscribers:
IPFlow—Contains data fields for the uplink and downlink octets and bytes. When a data record for volume limit is exported, these IPFlow statistics in the record are the actual data received after the last volume limit was reported in that data session and not cumulative data.
Ip Protocol—Protocol ID from IP header; for example, 17 (UDP), 6 (TCP).
Record Reason—A value of 1 for the session close and a value of 2 for volume-limit.
IPFlow Extended—Contains data fields for the service set name, routing instance, and payload timestamps. The initiator of the very first packet of a session is the client and the responder is the server.
IPFlow TCP Timestamp—Contains data fields for TCP-related timestamps:
Retransmitted TCP packets uplink
Retransmitted TCP packets downlink
Smooth RTT uplink
Smooth RTT downlink
Client setup Time
Server Setup time
TCP flow creation timestamp
First Client Payload TS
First Server Payload TS
Acknowledged volumes uplink
Acknowledged volumes downlink
IPFlow Timestamp—Contains data fields for the flow start and end timestamps:
Flow Start Time—For TCP, the flow start time is when the SYN packet is received. For UDP, it is when the first packet is sent.
Flow End Time
IPv4—Contains data fields for the basic source and destination IPv4 information:
Source IPv4 Address
Destination IPv4 Address
IPv4 Extended—Contains data fields for the elements of IPv4 extended fields:
IPv4 TOS / IPv4 Destination Mask IPv4 Next Hop
Class of Service
IPv4 Source Mask
IPv4 Next Hop
IPv6—Contains data fields for the basic source and destination IPv6 information:
Source IPv6 Address
Destination IPv6 Address
IPv6 Extended—Contains data fields for the elements of IPv6 extended fields:
IPv6 Source Mask
IPv6 Destination Mask
IPv6 Next Hop
L7 Application—Contains data fields for the Layer 7 application:
Application Protocol—Application data protocol below the classified application name; for example,
Application Name—Application name; for example,
Mobile Subscriber—Contains data fields specific to mobile subscribers:
RADIUS Called Station ID
PCC—Contains the PCC rule name data field.
Status Code Distribution—Contains data fields for the HTTP or DNS status codes:
Status code 1
Status code 2
Status code 3
Status code 4
Status code 5
Num Instances 1
Num Instances 2
Num Instances 3
Num Instances 4
Num Instances 5
Subscriber Data—Contains data fields for Generic Subscriber information that can be included with wireless (mobile) subscribers or wireline subscribers:
Subscriber Type—1 for IP-based subscriber, 2 for IFL-based subscriber.
Subscriber IP Address
NAS Port ID
NAS Port Type
RADIUS Calling Station ID
Transport Layer—Contains data fields for the transport layer:
Source Transport Port
Destination Transport Port
Video—Contains data fields for video traffic:
Wireline Subscriber—Contains the UserName data field for wireline subscribers. This is the same as RADIUS Called Station ID.
The template that is specified in an LRF rule determines the set of data fields that are included when data is sent to a collector. The data message includes a pointer to the template ID so that the collector can correlate the data contents with the data field lengths and types.
In a template, you also specify the type of trigger that determines when to send data to the collector. This trigger type can be a data volume limit, a time limit, or the closing of a data session. (UDP sessions are considered closed after 60 seconds of inactivity; TCP sessions are considered closed when a FIN, FIN-ACK, or RST is received.)
HTTP Transaction Logging
You may enable HTTP transaction logging in an LRF profile. This causes each HTTP transaction in a TCP session to be separately logged and sent to the collector, as shown in Figure 1. This option is only relevant when the template being used includes HTTP in the template type.
By default, HTTP transaction logging is disabled, and the HTTP transaction records for a TCP session are sent together as one group of records.