Logging and Reporting Function for Subscribers

Log and Report Control

A subscriber’s data sessions are logged and sent to collectors based on an LRF profile that 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 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.

To associate the LRF profile with a subscriber:

• For Junos OS Subscriber Aware, assign the LRF profile to the subscriber-aware TDF service set that belongs to the TDF interface (mif) in the subscriber’s TDF domain.

• For Junos OS Broadband Subscriber Management, assign the LRF profile to the service set that is configured for application-aware policy control.

Templates

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 TDF gateway (in IPv4 format)

• DNS—(Not available if Next Gen Services is enabled with the MX-SPC3 services card) 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 metadata from header fields:

  • User Agent

  • Content Length - Request

  • HTTP Response Code

  • Language

  • Host

  • Location

  • Http Method

  • Referer (HTTP)

  • MIME type

  • Time to First Byte

• IFL subscriber— Contains data fields specific to IFL-based subscribers:

  • Subscriber Name—Not applicable for BNG subscribers, hence this value is not be honored (is filled with zero).

  • IFL Name—Filled with default IFL name (filled with values Next Gen Services IFL)

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

  • Uplink Octets

  • Downlink Octets

  • Uplink Packets

  • Downlink Packets

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

  • Service-Set-Name—Filled with active service-set-name (16 byte value is filled active service-set-name. For example, if service-set-name is: bng-service-set-1, the template has a value of: bng-service-set-(16bytes)

  • Routing-Instance—Not applicable for BNG subscribers, hence this value is not be honored (is filled with zero).

• IPFlow TCP—Contains data fields for TCP-related timestamps:

  • Retransmitted TCP packets uplink

  • Retransmitted TCP packets downlink

  • TCP flow creation timestamp

• IPFlow TCP Timestamp—Contains IBM-specific data fields for TCP-related timestamps:

  • Smooth RTT uplink

  • Smooth RTT downlink

  • Client setup time

  • Server Setup time

  • First Client Payload timestamp

  • Upload time

  • First Server Payload timestamp

  • Download time

  • Acknowledged volumes uplink

  • Acknowledged volumes downlink

  To use the IPFlow TCP Timestamp template when configuring an LRF profile, identify the template as vendor specific to avoid a commit warning. See Configuring an LRF Profile for Subscribers.

• 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—(Not available if Next Gen Services with the MX-SPC3 services card are enabled) Contains data fields for the elements of IPv4 extended fields:

  • IPv4 TOS / Class of Service

  • IPv4 Source Mask

  • IPv4 Destination Mask

  • IPv4 Next Hop

• IPv6—Contains data fields for the basic source and destination IPv6 information:

  • Source IPv6 Address

  • Destination IPv6 Address

• IPv6 Extended—(Not available if Next Gen Services are enabled with the MX-SPC3 services card) Contains data fields for the elements of IPv6 extended fields:

  • IPv6 Source Mask

  • IPv6 Destination Mask

  • IPv6 Next Hop

  • Traffic Class

• L7 Application—Contains data fields for the Layer 7 application:

  • Application Protocol—Application data protocol below the classified application name; for example, http or ssl.

  • Application Name—Application name; for example, junos:facebook or junos:Netflix.

  • Host—HTTP header host when application protocol is http, SSL common name when application protocol is ssl, DNS name when application protocol is dns.

• Mobile Subscriber—(Not available if Next Gen Services with the MX-SPC3 services card are enabled) Contains data fields specific to mobile subscribers:

  • IMSI

  • MSISDN

  • IMEI

  • RAT-type

  • ULI

  • RADIUS Called Station ID

• PCC—Contains the PCC rule name data field.Not applicable if Next Gen Services are enabled.

• 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:

  • NAS_IP_ADDR—Not applicable for BNG subscribers, hence this value is not be honored (is filled with zero).

  • Subscriber Type—1 for IP-based subscriber, 2 for IFL-based subscriber.

  • Subscriber IP Address

  • Subscriber VRF—Not applicable for BNG subscribers, hence this value is not be honored (is filled with zero).

  • NAS Port ID—Not applicable for BNG subscribers, hence this value is not be honored (is filled with zero).

  • Accounting-Session-Id—Not applicable for BNG subscribers, hence this value is not be honored (is filled with zero).

  • Class—Not applicable for BNG subscribers, hence this value is not be honored (is filled with zero).

  • NAS Port Type—Not applicable for BNG subscribers, hence this value is not be honored (is filled with zero).

• Transport Layer—Contains data fields for the transport layer:

  • Source Transport Port

  • Destination Transport Port

• Video—(Not available if Next Gen Services with the MX-SPC3 services card are enabled) Contains data fields for video traffic:

  • Bitrate

  • Duration

• Wireline Subscriber—(Not available if Next Gen Services with the MX-SPC3 serices card are enabled) 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.

Figure 1: HTTP Transaction Logging