Subscriber volume statistics by default count Layer 2 frame sizes optionally modified by configuration such as packet-byte-offset, last mile aware shaping, and so on.
To report subscriber volume statistics as Layer 3 (IP) packet sizes, the volume-stats-type can be configured to ip in the subscriber profile:
configure
subscriber-mgmt
sub-profile <subscriber-profile-name>
volume-stats-type ip
volume-stats-type ip affects the subscriber statistics in SNMP, CLI, RADIUS accounting, XML accounting and Diameter Gx usage monitoring. Volume quota for RADIUS or Diameter Credit Control applications are interpreted as Layer 3 quota.
The following restrictions apply for volume-stats-type ip:
Layer 3/IP accounting is not supported in combination with MLPPP
Layer 3/IP accounting in combination with ESMoPW and last-mile-aware shaping may be inaccurate if the MPLS encapsulation overhead changes during the lifetime of a subscriber.
Layer 3/IP accounting is restricted to a single encap per sla-profile instance (queue instance). The first host associated with the sla-profile instance (queue instance) determines the allowed encapsulation. Conflicting encapsulations are:
PPPoE and IPoE on regular Ethernet SAPs
PPPoE and IPoE on PW SAPs
PPPoE keep alive packets do not contain IP payload and introduce an error in Layer 3/IP accounting when enabled in combination with L2TP-LAC. A workaround is to isolate the keep alives in a separate queue or policer.
Padding of frames smaller than the Ethernet minimum frame size (64B) may introduce an inaccuracy in Layer 3/IP accounting.
With ATM in the last mile, last-mile-aware shaping may introduce an inaccuracy in Layer 3/IP accounting.
Packet-Byte-Offset (PBO) changes during the lifetime of a subscriber introduces an inaccuracy in Layer 3/IP accounting.