[Contents] [Prev] [Next] [Index] [Report an Error]

Controlling Remaining Traffic

You can configure many logical interfaces under an interface. However, only a subset of them might have a traffic control profile attached. For example, you can configure three logical interfaces (units) over the same service VLAN, but apply a traffic control profile specifying best-effort and voice queues to only one of the logical interface units. Traffic from the two remaining logical interfaces is considered remaining traffic. To configure transmit rate guarantees for the remaining traffic, you configure the output-traffic-control-profile-remaining statement specifying a guaranteed rate for the remaining traffic. Without this statement, the remaining traffic gets a default, minimal bandwidth. In the same way, the shaping-rate and delay-buffer-rate statements can be specified in the traffic control profile referenced with the output-traffic-control-profile-remaining statement in order to shape and provide buffering for remaining traffic.

Consider the interface shown in Figure 18. Customer VLANs 3 and 4 have no explicit traffic control profile. However, the service provider might want to establish a shaping and guaranteed transmit rate for aggregate traffic heading for those customer VLANs. The solution in to configure and apply a traffic control profile for all remaining traffic on the interface.

Figure 18: Handling Remaining Traffic

Image g016857.gif

This example considers the case where customer VLANs 3 and 4 have no explicit traffic control profile, yet need to establish a shaping and guaranteed transmit rate for traffic heading for those customer VLANs. The solution is to add a traffic control profile to the svlan1 interface set. This example builds on the example used in (placeholder) and so does not repeat all configuration details, only those at the service VLAN level.

[edit class-of-service interfaces]
interface-set svlan0 {
output-traffic-control-profile tcp-svlan0;
}
interface-set svlan1 {
output-traffic-control-profile tcp-svlan1; # For explicitly shaped traffic.
output-traffic-control-profile-remaining tcp-svlan1-remaining; # For all remaining traffic.
}
[edit class-of-service traffic-control-profiles]
tcp-svlan1 {
shaping-rate 400m;
guaranteed-rate 300m;
}
tcp-svlan1-remaining {
shaping-rate 300m;
guaranteed-rate 200m;
scheduler-map smap-remainder; # this smap is not shown in detail
}

Next, consider the example shown in Figure 19.

Figure 19: Another Example of Handling Remaining Traffic

Image g016865.gif

In this example, ge-1/0/0 has three logical interfaces (unit 1, unit 2, and unit 3), and SVLAN 2000, which are covered by the interface set:

This example does not include the [edit interfaces] configuration.

[edit class-of-service interfaces]
interface-set {
svlan0 {
output-traffic-control-profile tcp-svlan0; # Guarantee & shaper for svlan0.
}
}
ge-1/0/0 {
output-traffic-control-profile-remaining tcp-svlan0-rem;
# Unit 3 and 4 are not explicitly configured, but captured by “remaining”
unit 1 {
output-traffic-control-profile tcp-ifl1; # Unit 1 be & ef queues.
}
}

Here is how the traffic control profiles for this example are configured:

[edit class-of-service traffic-control-profiles]
tcp-svlan0 {
shaping-rate 200m;
guaranteed-rate 100m;
}
tcp-svlan0-rem {
shaping-rate 300m;
guaranteed-rate 200m;
scheduler-map smap-svlan0-rem; # This specifies queues for remaining traffic
}
tcp-ifl1 {
scheduler-map smap-ifl1;
}

Finally, here are the scheduler maps and queues for the example:

[edit class-of-service scheduler-maps]
smap-svlan0-rem {
forwarding-class best-effort scheduler sched-foo;
}
smap-ifl1 {
forwarding-class best-effort scheduler sched-bar;
forwarding-class assured-forwarding scheduler sched-baz;
}

The configuration for the referenced schedulers are not given for this example.


[Contents] [Prev] [Next] [Index] [Report an Error]