For interfaces that carry IPv4, IPv6, or MPLS traffic, you can configure class-of-service (CoS) features to provide multiple classes of service for different applications. On the router, you can configure multiple forwarding classes for transmitting packets, define which packets are placed into each output queue, schedule the transmission service level for each queue, and manage congestion using a Random Early Detection (RED) algorithm. To configure CoS properties, include the following statements: [edit] class-of-service { classifiers { type classifier-name { import ( classifier-name default); forwarding-class class-name { loss-priority (low high) code-points [ alias bits ]; } } } code-point-aliases { (dscp exp ieee-802.1 inet-precedence) { alias-name bits ; } } drop-profiles { profile-name { fill-level percentage drop-probability percentage ; interpolate { drop-probability value ; fill-level value ; } } } forwarding-classes { queue queue-number class-name ; } forwarding-policy { next-hop-map map-name { forwarding-class class-name { next-hop [ next-hop-name ]; } } class class-name { classification-override { forwarding-class class-name ; } } } interfaces interface-name { scheduler-map map-name ; unit logical-unit-number { classifiers { (dscp exp ieee-802.1 inet-precedence) ( classifier-name default); } forwarding-class class-name ; rewrite-rules { (dscp exp inet-precedence) ( rewrite-name default); } } } } rewrite-rules { (dscp exp inet-precedence) rewrite-name { import ( rewrite-name default); forwarding-class class-name { loss-priority (low high) code-point ( alias bits ); } } } scheduler-maps { map-name { forwarding-class class-name scheduler scheduler-name ; } } schedulers { scheduler-name { transmit-rate ( rate percent percentage remainder) <exact>; maximum-buffer-delay ( milliseconds percent percentage remainder); priority (low high); drop-profile-map loss-priority (low high) protocol (non-tcp tcp any) drop-profile profile-name ; } } } Table 6.11 lists the RFCs that define the standards supported by certain aspects of the JUNOS CoS software. Table 6.11. CoS Standards Supported by JUNOS Software
The JUNOS software supports only two loss priorities and, by default, supports only one assured forwarding (AF) class, although you can configure more at the expense of other class types. Only IEEE 802.1p Layer 2 classification propagation mechanisms are currently supported. RFC 2983, Diffserv and Tunnels , is not supported. Defining Code-Point AliasesA code-point alias is a name you assign to a set of DiffServ code-point (DSCP) bits. When you configure classes and define classifiers, you can refer to the code points by these alias names. You can configure user -defined classifiers in terms of alias names . If the value of an alias changes, it alters the behavior of any classifier that references that alias. Table 6.12, Table 6.13, Table 6.14, and Table 6.15 list the default mappings between the bit values and standard aliases. For example, it is widely accepted that the alias for DSCP 101110 is expedited forwarding (ef). To define a code-point alias, include the code-point-aliases statement: [edit class-of-service] code-point-aliases { (dscp exp ieee-802.1 inet-precedence) { alias-name bits ; } } Table 6.12. Default DSCP Mappings for DiffServ Code Points
Table 6.13. Default DSCP Mappings for MPLS EXP Code Points
Table 6.14. Default DSCP Mappings for IEEE 802.1 Code Points
Table 6.15. Default DSCP Mappings for Legacy IP Precedence Code Points
Configuring Forwarding ClassesForwarding classes control how packets are assigned to output queues. To assign each forwarding class to an internal queue number, include the forwarding-classes statement: [edit class-of-service] forwarding-classes { queue queue-number class-name ; } The default CoS configuration is based on queue number. The name of the forwarding class that shows up when the default configuration is displayed is the forwarding class currently associated with that queue. Following is the default configuration for forwarding classes: [edit class-of-service] forwarding-classes { queue 0 best-effort; queue 1 expedited-forwarding; queue 2 assured-forwarding; queue 3 network-control; } If you reassign the forwarding-class names, the forwarding-class name best-effort appears in the locations in the configuration previously occupied by network-control , as follows : forwarding-classes { queue 0 network-control; queue 1 assured-forwarding; queue 2 expedited-forwarding; queue 3 best-effort; } In the current default configuration, only IP precedence classifiers are associated with interfaces, the only classes designated are best effort and network control, and schedulers are not defined for the expedited-forwarding or assured-forwarding classes. You must make a conscious effort to classify packets to the expedited-forwarding or assured-forwarding class and define schedulers for these classes. If classifiers fail to classify a packet, it always receives the default classification, to the class associated with queue 0. The number of queues depends on the hardware in the chassis. CoS configurations are inherently contingent on the number of queues on the system. Only two classes, best-effort and network-control , are actually referenced in the default configuration. The default configuration works on any platform. CoS configurations that specify more queues than the platform can support are not accepted. The commit fails with a detailed message that states the total number of queues available. Classifying Packets by Behavior Aggregate ClassThe simplest way to classify a packet is to use behavior aggregate classification. The DSCP or IP precedence bits of the IP header convey the behavior aggregate class information. The information might also be found in the MPLS EXP bits or IEEE 802.1p CoS bits. Table 6.16 lists the default system classification scheme for the well-known DSCPs. Note that all af classes other than af11, af12, and af13 are mapped to best-effort , because RFC 2597 prohibits a node from aggregating classes. In effect, mapping to best-effort implies that the node does not support that class. Table 6.16. Default Behavior Aggregate Classification
To define new classifiers for all code-point types, include the classifiers statement: [edit class-of-service] classifiers { (dscp exp ieee-802.1 inet-precedence) classifier- name { import [ classifier-name default]; forwarding-class class-name { loss-priority (low high) code-points [ alias bits ]; } } } To assign the classification map to a logical interface, include the forwarding-class statement in the following configuration. The dscp classifier classifies all incoming IPv4 packets, while the exp classifier handles MPLS packet classification. [edit class-of-service interfaces interface-name unit logical-unit-number ] forwarding-class class-name ; classifiers { (dscp exp ieee-802.1 inet-precedence) (classifier- name default); } Configuring Scheduling Policy MapsYou use scheduling policy maps to configure the forwarding classes that represent packet queues and associate them with physical interfaces. A scheduler configuration block specifies the buffer size, bandwidth, and priority for a queue. It also specifies the RED drop profile for packets that fall within specification and out of specification. To configure schedulers, include the schedulers statement: [edit class-of-service] schedulers { scheduler-name { transmit-rate ( rate percent percentage remainder) <exact>; maximum-buffer-delay ( time percent percentage remainder); priority (low high); drop-profile-map loss-priority (low high) protocol (non-tcp tcp any) drop-profile profile-name ; } } After you define a scheduler, include it in a scheduler map to map a given forwarding class to a scheduler configuration: [edit class-of-service] scheduler-maps { map-name { forwarding-class class-name scheduler scheduler-name ; } } Then associate the map-name with an output interface: [edit class-of-service] interfaces { interface-name { scheduler-map map-name ; } } You must configure each forwarding class in turn . The following is the default set of schedulers and scheduler maps: [edit class-of-service] schedulers { network-control { transmit-rate percent 5; maximum-buffer-delay percent 5; priority low; drop-profile-map loss-priority low protocol-type any drop-profile passive; drop-profile-map loss-priority high protocol-type any drop-profile aggressive; } best-effort { transmit-rate percent 95; maximum-buffer-delay 95; priority low; drop-profile-map loss-priority low protocol-type any drop-profile passive; drop-profile-map loss-priority high protocol-type any drop-profile aggressive; } } scheduler-map default { forwarding-class best-effort scheduler best-effort; forwarding-class network-control scheduler network- control; } Configuring RED Drop ProfilesRED drop profiles are associated with the forwarding classes and loss priorities from the scheduler map you configured on the interface. To configure the drop profiles themselves , include the drop-profiles statement: [edit class-of-service] drop-profiles { profile-name { fill-level percentage drop-probability percentage ; interpolate { fill-level value ; drop-probability value ; } } } Include either the interpolate statement and its options, or the fill-level and drop-probability percentage values. These two alternatives enable you to configure either each individual drop probability at up to 64 fill-level/drop-probability paired values, or a profile represented as a series of line segments. If you include the interpolate statement, you can specify more than 64 pairs, but the system generates only 64 discrete entries. The line segments are defined in terms of the following graphical model: in the first quadrant, the x axis represents the fill level, and the y axis represents the drop probability. The initial line segment spans from the origin (0,0) to the point (<l1>, <p1>); a second line runs from (<l1>, <p1>) to (<l2>, <p2>) and so forth, until a final line segment connects (100, 100). The system automatically constructs a drop profile containing 64 fill levels at drop probabilities that approximate the calculated line segments. Figure 6.6 shows sample line graphs contrasting use of the segment percentages (on the left) and interpolated values (on the right). Figure 6.6. Segmented and Interpolated Drop Profiles
The JUNOS software supports two packet loss priority (PLP) designations, low and high. The packet loss priority is used to determine the RED drop profile when queuing a packet. You can set it by configuring a classifier or policer. Rewriting Packet Header InformationYou can rewrite the packet header bits because the logical interface transmits the packet along with the forwarding class and PLP information associated with the packet. The rewrite-rules configurations define the mappings. Table 6.17 lists the default mappings. Table 6.17. Default Packet Header Rewrite Mappings
To configure a rewrite-rules mapping and associate it with the appropriate forwarding class and code-point alias or bit set, include the rewrite-rules statement: [edit class-of-service] rewrite-rules { (dscp exp inet-precedence) rewrite-name { import ( rewrite-name default); forwarding-class class-name { loss-priority (low high) code-point alias bits ; } } } To assign the rewrite-rules configuration to the output logical interface, include the following statements: [edit class-of-service] interfaces { interface-name { unit logical-unit-number { rewrite-rules { (dscp exp inet-precedence) rewrite-rule-name ; } } } } Configuring CoS-Based Forwarding
CoS-based forwarding enables you to control next-hop selection based on a packet's class of service and, in particular, the value of the IP packet's precedence bits. For example, you might want to specify a particular interface or next hop to carry high-priority traffic while all best-effort traffic takes some other path. When a routing protocol discovers equal cost paths, it can pick a path at random or load-share across the paths either through hash selection or round robin . CoS-based forwarding allows path selection based on class. You can apply CoS-based forwarding only to a defined set of routes. To do this, include the cos-next-hop-map statement in a policy then statement. To apply a CoS next-hop map, include the forwarding-policy statement: [edit class-of-service] forwarding-policy { next-hop-map map-name { forwarding-class class-name { next-hop [ next-hop-name ]; } } } The JUNOS software applies the CoS next-hop map to the set of next hops previously defined; the next hops themselves can be located across any outgoing interfaces on the router. Finally, apply the route filter to routes exported to the forwarding engine. This configuration instructs the routing process to insert routes to the forwarding engine matching my-cos-forwarding with the associated next-hop CoS-based forwarding rules. routing-options { forwarding-table { export my-cos-forwarding; } } The following rules are used to apply a configuration to a route:
For IPv4 or IPv6 packets, you can override the incoming classification, assigning them to the same forwarding class based on their input interface, input precedence bits, or destination address. You do so by defining a policy class when configuring CoS properties and referencing this class when configuring a routing policy. When you override the classification of incoming packets, any mappings you configured for associated precedence bits or incoming interfaces to output transmission queues are ignored. Also, if the packet loss priority bit was set in the packet by the incoming interface, the packet-loss priority bit is cleared. To override the input packet classification, do the following:
|