Configuring CoS-Based Forwarding

You can apply CoS-based forwarding (CBF) only to a defined set of routes. Therefore you must configure a policy statement as in the following example:

[edit policy-options]policy-statement my-cos-forwarding {from {route-filter destination-prefix match-type;}then {cos-next-hop-map map-name;}}

This configuration specifies that routes matching the route filter are subject to the CoS next-hop mapping specified by map-name. For more information about configuring policy statements, see the Junos Policy Framework Configuration Guide.

Note: On M Series routers (except the M120 and M320 routers), forwarding-class-based matching and CBF do not work as expected if the forwarding class has been set with a multifield filter on an input interface.

To specify a CoS next-hop map, include the forwarding-policy statement at the [edit class-of-service] hierarchy level:

[edit class-of-service]forwarding-policy {next-hop-map map-name {forwarding-class class-name {next-hop [ next-hop-name ];lsp-next-hop [ lsp-regular-expression ];discard;}}}

When you configure CBF with OSPF as the interior gateway protocol (IGP), you must specify the next hop as an interface name or next-hop alias, not as an IP address. This is true because OSPF adds routes with the interface as the next hop for point-to-point interfaces; the next hop does not contain the IP address. For an example configuration, see Example: Configuring CoS-Based Forwarding.

For Layer 3 VPNs, when you use class-based forwarding for the routes received from the far-end provider-edge (PE) router within a VRF instance, the software can match the routes based on the attributes that come with the received route only. In other words, the matching can be based on the route within RIB-in. In this case, the route-filter statement you include at the [edit policy-options policy-statement my-cos-forwarding from] hierarchy level has no effect because the policy checks the bgp.l3vpn.0 table, not the vrf.inet.0 table.

The Junos OS 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. For example, the following configuration associates a set of forwarding classes and next-hop identifiers:

[edit class-of-service forwarding-policy]next-hop-map map1 {forwarding-class expedited-forwarding {next-hop next-hop1;next-hop next-hop2;}forwarding-class best-effort {next-hop next-hop3;lsp-next-hop lsp-next-hop4;}}

In this example, next-hop N is either an IP address or an egress interface for some next hop, and lsp-next-hop4 is a regular expression corresponding to any next hop with that label. Q1 through QN are a set of forwarding classes that map to the specific next hop. That is, when a packet is switched with Q1 through QN, it is forwarded out the interface associated with the associated next hop.

This configuration has the following implications:

A single forwarding class can map to multiple standard next hops or LSP next hops. This implies that load sharing is done across standard next hops or LSP next hops servicing the same class value. To make this work properly, the Junos OS creates a list of the equal-cost next hops and forwards packets according to standard load-sharing rules for that forwarding class.
If a forwarding class configuration includes LSP next hops and standard next hops, the LSP next hops are preferred over the standard next hops. In the preceding example, if both next-hop3 and lsp-next-hop4 are valid next hops for a route to which map1 is applied, the forwarding table includes entry lsp-next-hop4 only.
If next-hop-map does not specify all possible forwarding classes, the default forwarding class is selected as the default. If the default forwarding class is not specified in the next-hop map, a default is designated randomly. The default forwarding class is the class associated with queue 0.
For LSP next hops, the Junos OS uses UNIX regex(3)-style regular expressions. For example, if the following labels exist: lsp, lsp1, lsp2, lsp3, the statement lsp-next-hop lsp matches lsp, lsp1, lsp2, and lsp3. If you do not desire this behavior, you must use the anchor characters lsp-next-hop " ^lsp$", which match lsp only.
The route filter does not work because the policy checks against the bgp.l3vpn.0 table instead of the vrf.inet.0 table.

The final step is to apply the route filter to routes exported to the forwarding engine. This is shown in the following example:

routing-options {forwarding-table {export my-cos-forwarding;}}

This configuration instructs the routing process to insert routes to the forwarding engine matching my-cos-forwarding with the associated next-hop CBF rules.

The following algorithm is used when you apply a configuration to a route:

If the route is a single next-hop route, all traffic goes to that route; that is, no CBF takes effect.
For each next hop, associate the proper forwarding class. If a next hop appears in the route but not in the cos-next-hop map, it does not appear in the forwarding table entry.
The default forwarding class is used if all forwarding classes are not specified in the next-hop map. If the default is not specified, one is chosen randomly.