In this short blog post, we are going to give condensed overview of the four main flavors of Frame-Relay Traffic Shaping (FRTS). Historically, as IOS evolved with time, different methods have been introduced, having various level of feature support. Two main features, specific to Frame-Relay Traffic-Shaping are per-VC shaping and queueing and adaptive shaping in response to Frame-Rleay congestion notifications (e.g. BECNs). You’ll see that not every flavor supports these two features. We begin with the «fossil» known as Generic Traffic Shaping.
An unique feature of GTS is the ability to apply multiple shapers to a single interface. However, shapers are not cascaded, but rather a packet is assigned to the first matching shaper rule. In the example below, there are three rules, with the last one being “fallback”, matching all packets that didn’t match access-lists 100 and 101. Unlike using the legacy CAR feature (rate-limit command) you cannot «cascade» multiple traffic-shape statements on the same interface, i.e. there is no “continue” action.
You cannot apply GTS per-VC unless you have created a subinterface for this particular PVC. You may, however, enable shaping that adapts to FR BECNs, using the syntax traffic-shape adaptive {rate} along with traffic-shape rate. Notice that if multiple PVCs map to interface, reception of a BECN on any of the VCs will trigger speed throttling.
Legacy FRTS allows for various queueing methods on per-VC level. You may use any of legacy techniques such as Custom Queueing, Priority Queueing, FIFO and WFQ/IP RTP Priority. More importantly, you may enable CBWFQ on per-VC level, by using the map-class command service-policy output along with the policy-map implementing CBWFQ logic. Note that if you apply CBWFQ per-VC, the maximum avaiable bandwidth is based on minCIR settings for a VC, not the CIR.
All the above QoS mechanisms could be combined with Per-VC fragmentation enabled solely by using the map-class command frame-relay fragment. Normally, you need to enable fragmentation on every PVC terminated on the interface, so make sure you configure all map-classes properly. As soon as fragmentation is enabled, the interface-level FIFO queue is turned into special «truncated» Priority Queue used for interleaving fragments and voice packets. Only High and Normal queues out of the PQ are used to implement interleaving and you can inspect queue utilization using the command show queueing.
Obviously enough, you cannot use GTS on the same interface where FRTS has been enabled and vice-versa – IOS will reject the command. Compared to GTS, legacy FRTS provide a lot of syntactical consistency – you apply all features using the map-class commands plus you have a rich selection of QoS mechanisms along with that.
(BTW, if you’re wondering the purpose of frame-relay tc command under a map-class, it is used in zero-CIR scenarios for traffic policing. With zero-CIR policing all traffic is considered exceeding, but you may want to specify the peak rate by setting Be and Tc together).
Frame-Relay Fragmentation (FRF.12) is supported with MQC FRTS, however you have to enable it at the interface level using the command frame-relay fragment X end-to-end. Interleaving queue is created automatically and cannot be seen using IOS show commands. Fragmentation is enabled on all PVCs terminated at the interface.
Compared to legacy FRTS, the MQC equivalent has some unique features, known as «Voice Adaptive Shaping» and «Voice Adaptive Fragmentation». The first feature activates adaptive shaping when packets are detected in the LLQ queue (if there is one configured) and the second feature activates fragmentation under the same condition of traffic present in the LLQ. The first feature is useful in oversubscription scenario, where you want to slow down from peak rate to committed rate when sending VoIP traffic to ensure better voice quality. The second feature is more useful, and allows you enabling traffic fragmentation only when it’s really needed, i.e. when a voice calls is active.
Now for the CB-GTS limitation. There is a bunch, unfortunately. first of all, adaptive shaping does not work with CB-GTS i.e. the command shape average does not have any effect. Secondly, you may enable fragmentation at the interface level, but you cannot use any of MQC-based FRTS features, such as voice-adaptive fragmentation and shaping. Therefore, CB-GTS is not exactly a Frame-Relay Traffic Shaping solution, though it allows for generic shaping on per-VC basis.
Generic Traffic Shaping
This feature was initially designed to shape packet traffic sent over any media, be it Ethernet, Frame-Relay, PPP etc. The command syntax is traffic-shape {rate|group} and allows specifying traffic scope using an access-list (notice that different ACL types are supported). You may tune the Bc/Be values as well as the shaping queue depth (amount of buffers). If the shaper delays traffic, the queue service strategy would be fixed to WFQ with the queue size equal to the buffer space allocated. Additional WFQ parameters such as number of flows and congestive discard threshold could not be tuned and set based on the shaper rate automatically.An unique feature of GTS is the ability to apply multiple shapers to a single interface. However, shapers are not cascaded, but rather a packet is assigned to the first matching shaper rule. In the example below, there are three rules, with the last one being “fallback”, matching all packets that didn’t match access-lists 100 and 101. Unlike using the legacy CAR feature (rate-limit command) you cannot «cascade» multiple traffic-shape statements on the same interface, i.e. there is no “continue” action.
traffic-shape group 100 128000 traffic-shape group 101 64000 traffic-shape group 199 256000 ! access-list 199 permit ip any any
You cannot apply GTS per-VC unless you have created a subinterface for this particular PVC. You may, however, enable shaping that adapts to FR BECNs, using the syntax traffic-shape adaptive {rate} along with traffic-shape rate. Notice that if multiple PVCs map to interface, reception of a BECN on any of the VCs will trigger speed throttling.
Legacy Frame-Relay Traffic-Shaping
This feature uses the map-class frame-relay syntax and was initially designed to implement specifically Frame-Relay Traffic Shaping and Policing (FRTS and FRTP) in Cisco IOS routers. This is still probably the most widely used form of FRTS. You specify all parameters under a map-class and then apply this map-class to a specific PVC or interface using the syntax similar to the following:map-class frame-relay DLCI_101 frame-relay cir 256000 frame-relay bc 2560 frame-relay be 0 frame-relay mincir 192000 frame-relay adaptive-shaping becn ! interface Serial 0/0 frame-relay traffic-shaping ! interface Serial 0/0.1 frame-relay interface-dlci 101 class DLCI_101A mandatory command that goes with Legacy FRTS is frame-relay traffic-shaping applied to an interface (there is also frame-relay policing command to implement traffic policing). With this command applied, all PVC CIRs are set to default 56Kbps unless you change that value in a map-class that you apply. Additionally, interface software queue is turned into FIFO, and every PVC gets its own, second-level, logical queue realized as shaper’s queue. Therefore, FRTS enables “true” FRTS by allowing for two-level queueing hierarchy.
Legacy FRTS allows for various queueing methods on per-VC level. You may use any of legacy techniques such as Custom Queueing, Priority Queueing, FIFO and WFQ/IP RTP Priority. More importantly, you may enable CBWFQ on per-VC level, by using the map-class command service-policy output along with the policy-map implementing CBWFQ logic. Note that if you apply CBWFQ per-VC, the maximum avaiable bandwidth is based on minCIR settings for a VC, not the CIR.
All the above QoS mechanisms could be combined with Per-VC fragmentation enabled solely by using the map-class command frame-relay fragment. Normally, you need to enable fragmentation on every PVC terminated on the interface, so make sure you configure all map-classes properly. As soon as fragmentation is enabled, the interface-level FIFO queue is turned into special «truncated» Priority Queue used for interleaving fragments and voice packets. Only High and Normal queues out of the PQ are used to implement interleaving and you can inspect queue utilization using the command show queueing.
Obviously enough, you cannot use GTS on the same interface where FRTS has been enabled and vice-versa – IOS will reject the command. Compared to GTS, legacy FRTS provide a lot of syntactical consistency – you apply all features using the map-class commands plus you have a rich selection of QoS mechanisms along with that.
(BTW, if you’re wondering the purpose of frame-relay tc command under a map-class, it is used in zero-CIR scenarios for traffic policing. With zero-CIR policing all traffic is considered exceeding, but you may want to specify the peak rate by setting Be and Tc together).
MQC Frame-Relay Traffic-Shaping
This was Сisco’s attempt to leverage MQC syntax for the purpose of traffic-shaping. The problem was that the syntax is still combined with the “legacy” style map-class syntax. Here’s how it works:- You create a «first-level» policy-map implementing shaping for a VC. You can only use «class-default» at this level, and apply shaping parameters using the commands shape average, shape peak, and shape adaptive. For example:
policy-map SHAPE class class-default shape average 512000 5120 0 shape adaptive 256000 - You create «nested» or «second-level» policy that implements CBWFQ. Note that CBWFQ/LLQ is the only queueing method supported with MQC-based FRTS (no CQ or PQ allowed, though you can emulate WFQ using MQC syntax).
policy-map CBWFQ class VOICE priority 128 class class-default fair-queue
- Combine both policy-maps and attach the parent policy to a map class. You should not enable the interface-level command frame-relay traffic-shaping with MQC FRTS.
policy-map SHAPE class class-default service-policy CBWFQ ! map-class frame-relay DLCI_101 service-policy output SHAPE ! interface Serial 0/0.1 frame-relay interface-dlci 101 class DLCI_101
Frame-Relay Fragmentation (FRF.12) is supported with MQC FRTS, however you have to enable it at the interface level using the command frame-relay fragment X end-to-end. Interleaving queue is created automatically and cannot be seen using IOS show commands. Fragmentation is enabled on all PVCs terminated at the interface.
Compared to legacy FRTS, the MQC equivalent has some unique features, known as «Voice Adaptive Shaping» and «Voice Adaptive Fragmentation». The first feature activates adaptive shaping when packets are detected in the LLQ queue (if there is one configured) and the second feature activates fragmentation under the same condition of traffic present in the LLQ. The first feature is useful in oversubscription scenario, where you want to slow down from peak rate to committed rate when sending VoIP traffic to ensure better voice quality. The second feature is more useful, and allows you enabling traffic fragmentation only when it’s really needed, i.e. when a voice calls is active.
Class Based Generic Traffic Shaping (CB-GTS)
The last method is based purely on MQC syntax using the generic commad shape average. In many senses, it’s similar to the legacy GTS but uses newer syntax and supports more granular application. Have a look at the following example:policy-map SHAPE_DLCI_101 class class-default shape average 256000 ! ! You can match DLCI's in class-maps ! class-map DLCI_202 match fr-dlci 202 ! policy-map SHAPE_DLCI_202 ! policy-map INTERFACE_POLICY class DLCI_202 service-policy SHAPE_DLCI_202 ! interface Serial 0/0 service-policy output INTERFACE_POLICY ! interface Serial 0/0.1 frame-relay interface-dlci 101 service-policy output SHAPE_DLCI_101The above example shows you two approaches to implementing VC-specific shaping. The first one uses a specific subinterface and the second one uses a class-map matching specific DLCI. The first method more reminds the legacy GTS, while the second allows pushing all VC policy under a single policy-map. Of course, you can always nest another MQC policy under a shaped class and implement CBWFQ and/or traffic marking/policing, just like you would do with any normal MQC configuration. FRF.12 fragmentation is also supported by means of the interface-level command frame-relay fragment, the same used with MQC FRTS.
Now for the CB-GTS limitation. There is a bunch, unfortunately. first of all, adaptive shaping does not work with CB-GTS i.e. the command shape average does not have any effect. Secondly, you may enable fragmentation at the interface level, but you cannot use any of MQC-based FRTS features, such as voice-adaptive fragmentation and shaping. Therefore, CB-GTS is not exactly a Frame-Relay Traffic Shaping solution, though it allows for generic shaping on per-VC basis.
No comments:
Post a Comment