Examples: Configuring Bandwidth Management

Bandwidth management enables you to control the multicast flows that leave a multicast interface. This control enables you to better manage your multicast traffic and reduce or eliminate the chances of interface oversubscription or congestion.

Bandwidth management ensures that multicast traffic oversubscription does not occur on an interface. When managing multicast bandwidth, you define the maximum amount of multicast bandwidth that an individual interface can use as well as the bandwidth individual multicast flows use.

For example, the routing software cannot add a flow to an interface if doing so exceeds the allowed bandwidth for that interface. Under these circumstances, the interface is rejected. This rejection, however, does not prevent a multicast protocol (for example, PIM) from sending a join message upstream. Traffic continues to arrive on the router, even though the router is not sending the flow from the expected outgoing interfaces.

You can configure the flow bandwidth statically by specifying a bandwidth value for the flow in bits per second, or you can enable the flow bandwidth to be measured and adaptively changed. When using the adaptive bandwidth option, the routing software queries the statistics for the flows to be measured at 5-second intervals and calculates the bandwidth based on the queries. The routing software uses the maximum value measured within the last minute (that is, the last 12 measuring points) as the flow bandwidth.

For more information, see the following sections:

• Bandwidth Management and PIM Graceful Restart

• Bandwidth Management and Source Redundancy

• Logical Systems and Bandwidth Oversubscription

When using PIM graceful restart, after the routing process restarts on the Routing Engine, previously admitted interfaces are always readmitted and the available bandwidth is adjusted on the interfaces. When using the adaptive bandwidth option, the bandwidth measurement is initially based on the configured or default starting bandwidth, which might be inaccurate during the first minute. This means that new flows might be incorrectly rejected or admitted temporarily. You can correct this problem by issuing the clear multicast bandwidth-admission operational command.

If PIM graceful restart is not configured, after the routing process restarts, previously admitted or rejected interfaces might be rejected or admitted in an unpredictable manner.

When using source redundancy, multiple sources (for example, s1 and s2) might exist for the same destination group (g). However, only one of the sources can actively transmit at any time. In this case, multiple forwarding entries—(s1,g) and (s2,g)—are created after each goes through the admission process.

With redundant sources, unlike unrelated entries, an OIF that is already admitted for one entry—for example, (s1,g)—is automatically admitted for other redundancy entries—for example, (s2,g). The remaining bandwidth on the interface is deducted each time an outbound interface is added, even though only one sender actively transmits. By measuring bandwidth, the bandwidth deducted for the inactive entries is credited back when the router detects no traffic is being transmitted.

For more information about defining redundant sources, see Example: Configuring a Multicast Flow Map.

You can manage bandwidth at both the physical and logical interface level. However, if more than one logical system shares the same physical interface, the interface might become oversubscribed. Oversubscription occurs if the total bandwidth of all separately configured maximum bandwidth values for the interfaces on each logical system exceeds the bandwidth of the physical interface.

When displaying interface bandwidth information, a negative available bandwidth value indicates oversubscription on the interface.

Interface bandwidth can become oversubscribed when the configured maximum bandwidth decreases or when some flow bandwidths increase because of a configuration change or an actual increase in the traffic rate.

Interface bandwidth can become available again if one of the following occurs:

• The configured maximum bandwidth increases.

• Some flows are no longer transmitted from interfaces, and bandwidth reserves for them are now available to other flows.

• Some flow bandwidths decrease because of a configuration change or an actual decrease in the traffic rate.

Interfaces that are rejected for a flow because of insufficient bandwidth are not automatically readmitted, even when bandwidth becomes available again. Rejected interfaces have an opportunity to be readmitted when one of the following occurs:

• The multicast routing protocol updates the forwarding entry for the flow after receiving a join, leave, or prune message or after a topology change occurs.

• The multicast routing protocol updates the forwarding entry for the flow due to configuration changes.

• You manually reapply bandwidth management to a specific flow or to all flows using the clear multicast bandwidth-admission operational command.

In addition, even if previously available bandwidth is no longer available, already admitted interfaces are not removed until one of the following occurs:

• The multicast routing protocol explicitly removes the interfaces after receiving a leave or prune message or after a topology change occurs.

• You manually reapply bandwidth management to a specific flow or to all flows using the clear multicast bandwidth-admission operational command.

This example shows you how to configure the maximum bandwidth for a physical or logical interface.

This example shows how to configure an MX Series router to function as a broadband service router (BSR).

For Juniper Networks M320 Multiservice Edge Routers and T Series Core Routers with the Intelligent Queuing (IQ), IQ2, Enhanced IQ (IQE), Multiservices link services intelligent queuing (LSQ) interfaces, or ATM2 PICs, you can classify unicast and multicast packets based on the egress interface. For unicast traffic, you can also use a multifield filter, but only egress interface classification applies to multicast traffic as well as unicast traffic. If you configure egress classification of an interface, you cannot perform Differentiated Services code point (DSCP) rewrites on the interface. By default, the system does not perform any classification based on the egress interface.

On an MX Series router that contains MPCs and MS-DPCs, multicast packets are dropped on the router and not processed properly if the router contains MLPPP LSQ logical interfaces that function as multicast receivers and if the network services mode is configured as enhanced IP mode on the router. This behavior is expected with LSQ interfaces in conjunction with enhanced IP mode. In such a scenario, if enhanced IP mode is not configured, multicasting works correctly. However, if the router contains redundant LSQ interfaces and enhanced IP network services mode configured with FIB localization, multicast works properly.

To enable packet classification by the egress interface, you first configure a forwarding class map and one or more queue numbers for the egress interface at the [edit class-of-service forwarding-class-map forwarding-class-map-name] hierarchy level:

For T Series routers that are restricted to only four queues, you can control the queue assignment with the restricted-queue option, or you can allow the system to automatically determine the queue in a modular fashion. For example, a map assigning packets to queue 6 would map to queue 2 on a four-queue system.

Once the forwarding class map has been configured, you apply the map to the logical interface by using the output-forwarding-class-map statement at the [edit class-of-service interfaces interface-name unit logical-unit-number ] hierarchy level:

All parameters relating to the queues and forwarding class must be configured as well. For more information about configuring forwarding classes and queues, see Configuring a Custom Forwarding Class for Each Queue.

This example shows how to configure an interface-specific forwarding-class map named FCMAP1 that restricts queues 5 and 6 to different queues on four-queue systems and then applies FCMAP1 to unit 0 of interface ge-6/0/0:

Note that without the restricted-queue option in FCMAP1, the example would assign FC1 and FC2 to queues 2 and 1, respectively, on a system restricted to four queues.

Use the show class-of-service forwarding-class forwarding-class-map-name command to display the forwarding-class map queue configuration:

Use the show class-of-service interface interface-name command to display the forwarding-class maps (and other information) assigned to a logical interface:

ACX routers use the recycle interface to loopback or recirculate traffic from the egress interface to the ingress for additional processing. This is needed for applications that require additional processing.

The recycle interface is an internal channelized interface that has an egress shaper that limits the flow rate of outbound traffic. By default, the recycle interface bandwidth is based on chassis oversubscription and platform specific FPC or interface configuration.

Applications that use the recycle mechanism, configure channels or virtual ports based on need, which in turn goes through an application shaper similar to the egress shaper on the recycle interface. The recycle interface can support a maximum of 256 channels or virtual logical ports. All the recycle channels operate at the same priority. The recycled traffic is then forwarded using the calendar slot based on the weight assigned to it. Other types of interfaces like the NIF interface forward traffic by occupying other slots on the calendar proportional to its bandwidth.

Figure 1 illustrates the the recycle mechanism and its components.

Figure 2: The recycle mechanism

• Sh1 – Recycle interface shaper

• SA1 – Application #1 shaper over recycle channel 1

• SAn – Application #n shaper over recycle channel n (max 256)

• B1 – Calendar slot weight for traffic from the recycle interface. This reflects the calendar bandwidth value allocated to the recycle interface.

• B2 – Calendar slot weight for traffic from interfaces other than the recycle interface. For example the NIF interface.

The recycle mechanism has two modes of operation:

• Default Recycle Bandwidth Mode

• Configurable Recycle Bandwidth Mode

• Default Recycle Bandwidth Mode
• Configurable Recycle Bandwidth Mode