19. S-VLAN Statistics Collection

19.1. Overview

The following S-VLAN statistics are supported per direction (ingress or egress):

  1. the number of forwarded bytes per S-VLAN (aggregated IPv4 + IPv6)
  2. the number forwarded packets per S-VLAN (aggregated IPv4 + IPv6)

S-VLAN statistics collection is supported only in the ESM context and is based on the subscriber queue or policer statistics. SAP queue statistics are excluded from the S-VLAN count. In ESM, in addition to subscriber queues, each SAP hosting a subscriber (or subscribers) may have its own queues associated with the default QoS SAP policy or a configured QoS SAP policy.

Although the principal use case calls for statistics collection on S-VLANs, this feature does not differentiate between QinQ and dot1q frames. Statistics are collected per outer tag, regardless of the encapsulation. In a QinQ environment, this translates to statistics collection on S-VLANs, while in dot1q environment, statistics are gathered per C-vlan (which is the only VLAN tag in the frame).

When policers are deployed on egress, traffic flowing through them is also traversing a queue or a queue group to which the policer is tied. Policers are always tied to a queue or a queue group. To avoid double counting, statistics must be gathered only from a single entity in the chain (policer or the immediately followed queue), but not both. The following is a list of supported egress deployments with policers that produces accurate S-VLAN statistics collection with no double-counting:

  1. Policers that are attached to the default queue-group
  2. Policers that are attached to a more specific queue-group
  3. Policers that are attached to the subscriber (local) queues. In this case, only policer statistics are included in S-VLAN statistics while the post-policer queue statistics are ignored. This also means that if traffic is sent directly to this queue without first going through a policer (for example, traffic mapped through an FC directly to a queue), such traffic is omitted from S-VLAN statistics.
  4. HQOS managed policers that are attached to the queues group (default or a specific one). Traffic traversing HQoS managed policers is accounted for in HQoS, while traffic traversing non-HQoS managed policers is not included in HQoS calculations. Such queue-groups must have the following command configured to avoid double counting:
     
     
    configure
       qos
          queue-group-templates
             egress
                queue-group <name>
                   no queues-hqos-manageable 
    The no queues-hqos-manageable command prevents HQoS from using the queue group statistics in its calculation, and therefore, it avoids double-counting.

Figure 239 displays an example of how egress S-VLAN statistics are used.

Figure 239:  Egress S-VLAN Statistics in Relation to QoS Deployment Models  

In Figure 239, the right side of the diagram represents traffic streams and their mapping to policers and queues according to the configuration statement shown on the left side. The four green lines represent traffic streams that are counted properly, and the two red lines represent the two streams that are counted incorrectly (they are either double counted, or not counted at all). The colored boxes numbered 1-6 represent a traffic stream with relevant classification fields. For example, traffic stream in box 1 has destination IP address set to 192.0.2.10 and DSCP values set to AF21.

  1. The purple traffic stream is classified through ip-criteria (dest-ip=102.0.2.10 in entry 10), which has higher evaluation priority than classification using DSCP (DSCP=AF21). Traffic is matched directly to policer 1 and a default queue-group after that, and not to queue 1 as DSCP=AF21 would suggest. Drops on the queue-group are reflected in forwarded statistics for policer 1.
  2. The green traffic stream is not classified through ip-criteria (dst-ip 192.0.2.40 is outside any configured entry in the ip-criteria). Instead, this traffic is classified using DSCP=BE which is mapped to FC ‘BE’ and then to policer 1. In terms of statistics, this case is identical to the previous case (1).
  3. The grey traffic stream is not classified through ip-criteria (dst-ip 192.0.2.60 is outside any configured entry in the ip-criteria). Instead, this traffic is classified using DSCP=AF12 which is mapped to FC ‘l1’ and then to policer 1 followed by a local queue 1. In this case, only policer statistics are counted towards S-VLANs statistics. This is expected for accurate accounting (no double accounting).
  4. The orange traffic stream is not accounted in S-VLAN statistics. Classification is performed based on DSCP=AF21 which is mapped to FC ‘h1’ and then to queue 1. For the purpose of S-VLAN statistics collection, counters on queue 1 in this example are not collected because this queue is an explicitly configured post policer queue (both, policer 1 and 2 are fed into this queue by explicit configuration). This excludes queue counters from being counted in the S-VLAN statistics which is desired behavior when traffic is passed through a policer first (which is not the case here).
  5. The brown traffic steam is classified through ip-criteria (entry 20). Traffic is mapped to policer 2 and then to local queue 1. Similar to case 3), S-VLAN statistics are properly counted in this example. Drops on the queue 1 are reflected in forwarded stats for policer 2.
  6. The blue traffic stream is classified through ip-criteria (entry 30). Traffic is mapped to the policer 3 and the local post-policer queue which is derived from FC mapping (DSCP=EF →FC ‘ef’ → queue 2. This case is akin to dynamic policers (this is how dynamic policers are mapped to local queues, using FC). S-VLAN statistics are not counted properly, because the mapping between the policer and the post-policer local queue is not explicit using the configuration but instead it is implicitly derived using FC. As a result, double counting occurs.

19.1.1. Statistics Retention

The SR OS node preserves statistics from a subscriber even when the subscriber is disconnected, and the subscriber’s policers or queues are released. This prevents statistics fluctuation in relation to subscriber presence and ensures that a statistic counter once accounted on an S-VLAN remains accounted for during the life time of that S-VLAN, unless the S-VLAN stats are manually cleared by a clear command.

Reporting such absolute (or cumulative) count in S-VLAN statistics allows smooth measurement of bandwidth per S-VLAN without dips caused by departing subscribers.

Sudden changes in bandwidth (the difference in byte count between two consecutive stats polls, divided by the collection interval) can arise only from a failed path to the subscriber (ports and access nodes) and this can be used to track per S-VLAN failures in the network.

19.1.1.1. MIBs

The S-VLAN statistics are provided in the form of a read-only MIB table with the currently active S-VLANs.

The key for the MIB table are the <port-id> (which can also be a LAG-id or PW-port-id) and <svlan-id>.

Once the S-VLAN is instantiated (either statically or through MSAP), it is placed as an entry in the MIB table. Once the S-VLAN is no longer present in the system, it is removed automatically from the table.

Each S-VLAN can be queried through SNMP either directly or as an SNMP walk, in which case, all entries in the table are read.

The MIB table name is tmnxSubSvlanStatsTable. The format is displayed in Figure 240.

Figure 240:  tmnxSubSvlanStatsTable MIB Table 

19.1.2. Enabling S-VLAN Statistics Collection

S-VLAN statistics collection is enabled through a configuration flag on a global level:

configure
   subscriber-mgmt
      svlan-statistics
         [no] shutdown

Once S-VLAN statistics collection is enabled, the MIB table is populated automatically with the current S-VLAN entries, up to the supported limit. This also means that on-line change (while subscribers are active) is supported for all subscribers that are currently active on the S-VLAN.