Understanding CoS on an MX Series Aggregation Device in Junos Fusion Provider Edge

Overview of CoS on Different Types of Ports in Junos Fusion

Figure 2 provides an overview of packet flow through Junos Fusion and how CoS features are applied at the different ports.

Figure 2: Junos Fusion CoS Feature Application

All configuration for CoS policies for Junos Fusion is done on the aggregation device. For CoS policies that you define for extended ports, however, different portions of that policy are applied at different points in a packet’s path through Junos Fusion. From Figure 2:

1. As a packet enters an extended port, any port-level (physical interface-level) behavior aggregate (BA) classifier you define for that port is applied to derive a forwarding class and packet loss priority.

2. As that packet exits the uplink port, you can apply schedulers or enhanced transmission selection (ETS) based on the port-level BA classifier assigned at the ingress extended port.

3. As the packet enters the aggregation device at the cascade port, any multifield classifiers, policers, or logical interface-level BA classifiers you define for the ingress extended port are applied.

4. As the packet exits the aggregation device at the cascade port, any rewrite rules you define for the egress extended port, as well as any schedulers you define for the cascade port, are applied, unless the rewrite rule is associated with an extended port logical interface. Also, the forwarding class determined in the previous step is carried in the 801.2BR header to the satellite device and used to select the output queue at the egress extended port.

5. Finally, as the packet exits an extended port, any schedulers or ETS you define for that port are applied based on the forwarding class determined by the multifield classifiers, policers, or logical interface-level BA classifiers defined for the ingress extended port.

The following sections provide further information about implementing CoS on each port type in Junos Fusion.

CoS on Extended Ports and Uplink Ports in Junos Fusion

All class of service (CoS) scheduling policies for extended ports and uplink ports on the satellite devices are provisioned on the MX Series aggregation device. Similarly, standard Junos OS CoS commands are issued on the MX Series aggregation device for retrieving extended port and uplink port CoS states and queue statistics. The MX Series aggregation device supports configuring the following CoS features for each extended port and uplink port on each satellite device:

• Behavior aggregate classifiers

• Multifield classifiers

• Input and output policers

• Forwarding classes

• Traffic control profiles

• Schedulers and scheduler maps

• Per-unit and hierarchical schedulers (extended ports only)

• Egress rewrite rules

While CoS features for satellite device ports are configured on the aggregation device, the actual classification, queueing, and scheduling is performed on the satellite devices. Information on actual traffic shaping is not passed back to the aggregation device. Logical interface statistics for the show interfaces command are collected on the aggregate device and do not include shaping rate data. For actual traffic statistics gathered on satellite device interfaces, use the statistics for the physical interface and not the logical interface.

Per-unit and Hierarchical Scheduling on Extended Ports

Junos Fusion Provider Edge supports per-unit and hierarchical schedulers on extended ports. To support per-unit or hierarchical scheduling on an extended port, all cascade ports on the aggregation device for that extended port must have a queueing chip.

To enable per-unit scheduling on an extended port, enable the per-unit-scheduler option at the [edit interfaces interface-name] hierarchy level for the extended port.

To enable hierarchical scheduling on an extended port, enable the hierarchical-scheduler option at the [edit interfaces interface-name] hierarchy level for the extended port.

Junos Fusion treats the cascade ports connecting the aggregation device to the satellite device as aggregated Ethernet ports with aggregation done automatically without configuration. By default the Junos Fusion implementation of hierarchical CoS applies the scheduler parameters across all cascade ports in scale mode. Because scale mode divides the configured shaper equally across the cascade ports, traffic drops can start before a customer reaches its committed rate for a particular flow. You can set all cascade ports on an aggregation device to be in replicate mode, thereby copying scheduler parameters to each level of the aggregated interface member links, and automatically target all of an extended port’s traffic to a specific cascade port. To do this, simply enable target-mode for the satellite device at the [edit chassis satellite-management fpc fpc-number] hierarchy level. For example:

Broadband Subscriber Services Support

Junos Fusion Provider Edge supports Broadband Edge Subscriber Management, including standard CoS functionality for Broadband Edge Subscriber Management.

BNG on Junos Fusion Provider Edge supports the following CoS scheduling hierarchies:

• Dynamic logical interface set/Static-VLAN-Demux/Extended port physical interface

• Dynamic logical interface/Extended port physical interface

• Dynamic logical interface set/Extended port physical interface

• Dynamic logical interface/Dynamic logical interface set/Extended port physical interface

To support 4 levels of hierarchical scheduling (for example, queue/dynamic logical interface/dynamic logical interface set/extended port physical interface), you need MPCs on the aggregation device that support at least 5 levels of hierarchical scheduling. This is because one level of scheduling is consumed by the cascade port. Every MPC on the aggregation device configured for Broadband Edge Subscriber Management must support at least 4 levels of hierarchical scheduling. Also, the maximum-hierarchy-levels option at the [edit interfaces interface-name hierarchical-scheduler] hierarchy for the extended port must be set to one less what the MPC for the associated cascade port supports because of the one level of scheduling the cascade port consumes.

Classifiers and rewrite rules are supported on subscriber logical interfaces.

Shaping calculations include the 801.BR overhead bytes.

The show class-of-service scheduler-hierarchy interface command is supported and shows the cascade port as part of the hierarchy. For example:

In the above sample output, ge-100/0/0 is the extended port and xe-2/0/5 is the cascade port.

CoS Hierarchical Port Scheduling with Enhanced Transmission Selection in Junos Fusion

In Junos Fusion, the satellite device can be either a QFX5100 or an EX4300 device. The QFX5100 supports enhanced transmission selection (ETS), which is described in IEEE 802.1Qaz. Configuration support for ETS has been added to the MX Series device only for satellite device ports that support this feature. If ETS is configured on the MX Series aggregation device for a satellite device port that does not support ETS, the satellite devices converts the ETS configuration to port scheduler.

CoS on Cascade Ports in Junos Fusion

When a cascade port is created, two logical interfaces are automatically created:

• One in-band management logical interface (assigned unit 32769) for traffic that only flows between the aggregation device and the satellite devices, such as keepalives, for provisioning information, and for software updates.

• One for data logical interface (assigned unit 32770) for regular traffic that flows into and out of Junos Fusion.

Per-unit scheduling is automatically enabled on the cascade port to support multiple queues on each of the logical interfaces.

50 Mbps of bandwidth is reserved for the management logical interface. The remaining bandwidth is available to the data logical interface. A shaping rate of 10 percent is also applied to the management logical interface, which means it can use up to 10 percent of the full interface bandwidth, if available.

The default scheduling policy is applied to the data logical interface. This reserves 95 percent of the available bandwidth and buffer space for the best effort forwarding class (mapped to queue 0) and 5 percent for the network control forwarding class (mapped to queue 3). You can create custom forwarding classes and schedulers by applying a custom scheduler map to this logical interface.