Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

MLPPP Subscriber Accounting Statistics Overview

For broadband subscriber management edge router Point-to-Point Protocol (PPP) subscribers, the accounting statistics contain two groups:

  • The aggregate (IPv4 and IPv6) statistics group consists of statistics reported through these RADIUS attributes: Acct-Input-Octets, Acct-Output-Octets, Acct-Input-Packets, and Acct-Output-Packets.

  • The IPv6 portion of the aggregate statistics group reported through the Juniper Networks ERX-VSAs 151 through 156.

Broadband subscriber management edge router PPP logical interfaces (IFLs) support accurate accounting statistics by excluding PPP control traffic, and incrementing packet and octets at the point where the packet is about to leave the router. The packet is not dropped by CoS, filters, or policers.

For MLPPP subscribers, accounting is performed for each member link (currently limited to one) and not the bundle. The bundle IFL supports accurate accounting statistics only, and the member link supports transit statistics only. As a result, the following restrictions apply for member link final aggregate statistics:

  • Only aggregate statistics are available with no IPv6 specific statistics; for example, ERX-VSA 151 to 156 are all zeros.

  • Packets sent and received over the member link include fragments and non-fragmented packets.

  • Octets sent and received are bytes in the fragments and non-fragmented packets.

  • Aggregate statistics include packets that can be dropped in the router, such as CoS, filters, and policers.

  • Aggregate statistics include PPP control packets (LCP, PAP, CHAP, and NCP) and keepalive packets.

The following topics describe the statistics collection process in the lookup engine for member links and its bundle.

Member Link and Bundle Statistics Collection

MLPPP with MPC2 currently supports only one member link per bundle. However, support for accounting statistics must consider a true multilink scenario where multiple member links exist per bundle. From the lookup engine, only the bundle has the ability to maintain Layer 3 statistics. For an individual member link, only protocol-agnostic fragments (plus non-fragmented packets) are counted.

Figure 1 shows an MLPPP client with two active member links and the statistics maintained by the lookup engine. For MLPPP with MPC2, each member link and bundle can reside on different lookup engines from where the accounting statistics are maintained.

Figure 1: MLPPP Client with Two Active Member LinksMLPPP Client with Two Active Member Links

Client-to-Internet Traffic Statistics

When the client sends IP packets towards the Internet, they may be fragmented. For example, packet P1 is fragmented into F1 and F2, and the fragments belonging to a single packet can be sent on different links (Figure 1).

  • F1 is sent on Link 1

  • F2 is sent on Link 2

When Link 1 on the MX Series receives fragment F1, it is identified as an MLPPP encapsulated fragment. Because IPv4 or IPv6 families are indicated on the first fragment, all of the incoming fragments are counted using a protocol-agnostic method before the fragment is forwarded to the bundle for reassembly.

  • The protocol-agnostic incoming packet count is incremented by 1.

  • The protocol-agnostic incoming byte count is incremented by the size of the fragment.

Similarly on Link 2, fragment F2 is also counted using a protocol-agnostic method, and then forwarded to the bundle for reassembly.

Fragment F1 arrives at the bundle and is stored along with its MLPPP header containing the sequence number with the begin flag set to 0, and the end flag set to 1.

Fragment F2 arrives at the bundle and is stored along with its MLPPP header containing the sequence number with the begin flag set to 1, and the end flag set to 0.

The pattern of monotonically increasing sequence numbers, begin flag set to 1 and end flag set to 1, causes fragments F1 and F2 to be reassembled into a single packet.

After the packet has been reassembled, the packet's Layer 3 type (either IPv4 or IPv6) is determined at the bundle. Then, the packets and bytes are counted according to its Layer 3 type at the bundle based on accurate accounting statistics:

  • bundleA_ipv4_packets_from_client += 1

  • bundleA_ipv4_bytes_from_client += packet_size

Or

  • bundleA_ipv6_packets_from_client += 1

  • bundleA_ipv6_bytes_from_client += packet_size

Internet-to-Client Traffic Statistics

In the reverse direction, Layer 3 packets come from the Internet to the bundle.

The packets and bytes are counted according to its Layer 3 type at the bundle:

  • bundleA_ipv4_packets_to_client += 1

  • bundleA_ipv4_bytes_to_client += packet_size

Or

  • bundleA_ipv6_packets_to_client += 1

  • bundleA_ipv6_bytes_to_client += packet_size

If the packets are fragmented, the fragments belonging to the same packet can be sent out different links. Because no IPv4 or IPv6 families are indicated on the links, all of the outgoing fragments are counted using a protocol-agnostic method.

  • The protocol-agnostic outgoing packet count is incremented by 1.

  • The protocol-agnostic outgoing byte count is incremented by the size of the fragment.

RADIUS Final Statistics Output Example

The following output example shows RADIUS final statistics:

Related Documentation