Jan
22

This is the most well-known FRTS method, which has been available for quite a while on Cisco routers. It is now being outdated by MQC configurations.
The key characteristic is that all settings are configured under map-class command mode, and later are applied to a particular set PVCs. The
same configuration concept was used for legacy ATM configuration mode (map-class atm).

Legacy FRTS has the following characteristics:

- Enabled with frame-relay traffic-shaping command at physical interface level
- Incompatible with GTS or MQC commands at subinterfaces or physical interface levels
- With FRTS you can enforce bitrate per-VC (VC-granular, unlike GTS), by applying a map-class to PVC
- When no map-class is explicitly applied to PVC, it's CIR and Tc are set to 56K/125ms by default
- Shaping parameters are configured under map-class frame-relay configuration submode
- Allows to configure fancy-queueing (WFQ/PQ/CQ) or simple FIFO per-VC
- No option to configure fancy-queueing at interface level: interface queue is forced to FIFO (if no FRF.12 is configured)
- Allows for adaptive shaping (throttling down to minCIR) on BECN reception (just as GTS) and option to reflect incoming FECNs as BECNs
- Option to enable adaptive shaping which responds to interface congestion (non-empty interface queue)

Example: Shape PVC to 384Kbps with minimal Tc (10ms) and WFQ as interface queue

map-class frame-relay SHAPE_384K
frame-relay cir 384000
frame-relay bc 3840
frame-relay be 0
!
! Adaptive shaping: respond to BECNs and interface congestion
!
frame-relay adaptive-shaping becn
frame-relay adaptive-shaping interface-congestion
!
! Per-VC fancy-queueing
!
frame-relay fair-queue
!
interface Serial 0/0/0:0
frame-relay traffic-shaping
!
interface Serial 0/0/0:0.1
ip address 177.0.112.1 255.255.255.0
frame-relay interface-dlci 112
class SHAPE_384K

Verification: Check FRTS settings for the configured PVC

Rack1R1#show frame-relay pvc 112

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0

cir 384000 bc 3840 be 0 byte limit 480 interval 10 <------ Shaping parameters
mincir 192000 byte increment 480 Adaptive Shaping BECN and IF_CONG <---- Adaptive Shaping enabled
pkts 0 bytes 0 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: weighted fair <---- WFQ is the per-VC queue
Current fair queue configuration:
Discard Dynamic Reserved
threshold queue count queue count
64 16 0
Output queue size 0/max total 600/drops 0

The other PVC, with no class configured, has CIR set to 56Kbps and uses FIFO as per-VC queue:

Rack1R1#show frame-relay pvc 113

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 113, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0.2

cir 56000 bc 7000 be 0 byte limit 875 interval 125 <---- CIR=56K
mincir 28000 byte increment 875 Adaptive Shaping none
pkts 74 bytes 5157 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: fifo <------------------ FIFO
Output queue 0/40, 0 drop, 0 dequeued

Check the physical interface queue:

Rack1R1#show interfaces serial 0/0/0:0 | inc Queue
Queueing strategy: fifo

- Interface queue could be changed to PIPQ (PVCs are assigned to 4 pririty groups, with PQ being physical interface queue)
- PIPQ stands for PVC Interface Priority queueing

Example: Map PVC 112 traffic to high interface queue, and PVC 113 to low interface queue, with WFQ being per-VC queueing

!
! Shape to 384K an assign to high interface level queue
!
map-class frame-relay SHAPE_384K_HIGH
frame-relay cir 384000
frame-relay bc 3840
frame-relay be 0
!
! Per-VC fancy-queueing
!
frame-relay fair-queue
frame-relay interface-queue priority high

!
! Shape to 256k an assign to low interface level queue
!
map-class frame-relay SHAPE_256K_LOW
frame-relay cir 256000
frame-relay bc 2560
frame-relay be 0
!
! Per-VC fancy-queueing
!
frame-relay fair-queue
frame-relay interface-queue priority low

!
! Enable PIPQ as interface queueing strategy
!
interface Serial 0/0/0:0
frame-relay traffic-shaping
frame-relay interface-queue priority
!
interface Serial 0/0/0:0.1
ip address 177.0.112.1 255.255.255.0
frame-relay interface-dlci 112
class SHAPE_384K_HIGH
!
interface Serial 0/0/0:0.2
ip address 177.0.113.1 255.255.255.0
frame-relay interface-dlci 113
class SHAPE_256K_LOW

Verfication: Check PVC interface-level priorities

Rack1R1#show frame-relay pvc 112

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0.1

cir 384000 bc 3840 be 0 byte limit 480 interval 10
mincir 192000 byte increment 480 Adaptive Shaping none
pkts 1687 bytes 113543 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: weighted fair
Current fair queue configuration:
Discard Dynamic Reserved
threshold queue count queue count
64 16 0
Output queue size 0/max total 600/drops 0
priority high
^^^^^^^^^^^^^

Rack1R1#show frame-relay pvc 113

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 113, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0.2

cir 256000 bc 2560 be 0 byte limit 320 interval 10
mincir 128000 byte increment 320 Adaptive Shaping none
pkts 1137 bytes 79691 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: weighted fair
Current fair queue configuration:
Discard Dynamic Reserved
threshold queue count queue count
64 16 0
Output queue size 0/max total 600/drops 0
priority low
^^^^^^^^^^^^

Verify interface-level queue:

Rack1R1#show interfaces serial 0/0/0:0 | inc (Output|high)
Output queue (queue priority: size/max/drops):
high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/0

- With FRF.12 fragmentation configured per any PVC, physical interface queue is changed to dual-FIFO
- This is due to the fact that fragmentation is ineffective without interleaving
- Fragment size is calculated based on physical interface speed to allow minimum serialization delay

Example: Enable FRF.12 fragmentation for PVC DLCI 112 and physical interface speed 512Kbps

!
! PVC shaped to 384Kbps, with physical interface speed 512Kbps
!
map-class frame-relay SHAPE_384K_FRF12
frame-relay cir 384000
frame-relay bc 3840
frame-relay be 0
!
! Per-VC fancy-queueing
!
frame-relay fair-queue

!
! Enable FRF.12 per VC. Fragment size = 512Kbps*0,01/8 = 640 bytes
!
frame-relay fragment 640
!
!
!
interface Serial 0/0/0:0
frame-relay traffic-shaping
!
interface Serial 0/0/0:0.1
ip address 177.0.112.1 255.255.255.0
frame-relay interface-dlci 112
class SHAPE_384K_FRF12

Verfication: Check PVC settings

Rack1R1#show frame-relay pvc 112

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0.1

fragment type end-to-end fragment size 640
cir 384000 bc 3840 be 0 limit 480 interval 10
mincir 192000 byte increment 480 BECN response no IF_CONG no
frags 1999 bytes 135126 frags delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: weighted fair
Current fair queue configuration:
Discard Dynamic Reserved
threshold queue count queue count
64 16 0
Output queue size 0/max total 600/drops 0

Look at physical interface queue:

Rack1R1#show interfaces serial 0/0/0:0 | inc Queu|Output q
Queueing strategy: dual fifo
Output queue: high size/max/dropped 0/256/0
Output queue: 0/128 (size/max)

- You can map up to 4 priority queues to 4 different VCs (inverse PIPQ)
- This scenario usually implies multiple PVCs running between two sites (e.g. PVC for voice and PVC for data)

Example: Map voice packets to high interface-level priority queue and send them over PVC 112

!
! Voice bearer
!
access-list 101 permit udp any any range 16384 32767

!
! Simple priority list to classify voice bearer to high queue
!
priority-list 1 protocol ip high list 101

interface Serial 0/0/0:0
ip address 177.1.0.1 255.255.255.0
!
! We apply the priority group twice: first to implement queueing
!
priority-group 1
!
! Next to map priority levels to DLCIs
!
frame-relay priority-dlci-group 1 112 112 113 113

Verfication:

Rack1R1#show queueing interface serial 0/0/0:0
Interface Serial0/0/0:0 queueing strategy: priority

Output queue utilization (queue/count)
high/217 medium/0 normal/1104 low/55

Rack1R1#show frame-relay pvc 112

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0

pvc create time 3d01h, last time pvc status changed 3d01h
Priority DLCI Group 1, DLCI 112 (HIGH), DLCI 112 (MEDIUM)
DLCI 113 (NORMAL), DLCI 113 (LOW)

- You can change per-VC queue to CBWFQ/LLQ, and still shape with FRTS
- Note that available bandwidth will be calculated from minCIR value, which is CIR/2 by default

Example: Implement CBWFQ Per-VC

!
! Classify voice using NBAR
!
class-map VOICE
match protocol rtp

!
! Simple LLQ
!
policy-map CBWFQ
class VOICE
priority 64
class class-default
bandwidth 64

!
! Use CBWFQ as queueing strategy
! Note that MinCIR = 384/2=192Kbps
!
map-class frame-relay SHAPE_384K_CBWFQ
frame-relay cir 384000
frame-relay bc 3840
frame-relay be 0
service-policy output CBWFQ
!
!
!
interface Serial 0/0/0:0
frame-relay traffic-shaping
!
interface Serial 0/0/0:0.1
ip address 177.0.112.1 255.255.255.0
frame-relay interface-dlci 112
class SHAPE_384K_CBWFQ

Verfication: Check PVC queueing strategy

Rack1R1#show frame-relay pvc 112

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0

cir 384000 bc 3840 be 0 byte limit 480 interval 10
mincir 192000 byte increment 480 Adaptive Shaping none
pkts 0 bytes 0 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
service policy CBWFQ
Serial0/0/0:0: DLCI 112 -

Service-policy output: CBWFQ

Class-map: VOICE (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol rtp
Queueing
Strict Priority
Output Queue: Conversation 40
Bandwidth 64 (kbps) Burst 1600 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0

Class-map: class-default (match-any)
32 packets, 2560 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
Output Queue: Conversation 41
Bandwidth 128 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Output queue size 0/max total 600/drops 0

To verify that only MinCIR of bandwidth is allocated to CBWFQ under map-class do the following:

Rack1R1(config)#policy-map CBWFQ
Rack1R1(config-pmap)# class VOICE
Rack1R1(config-pmap-c)# priority 64
Rack1R1(config-pmap-c)# class class-default
Rack1R1(config-pmap-c)# bandwidth 192
I/f Serial0/0/0:0 DLCI 112 Class class-default requested bandwidth 192 (kbps) Only 128 (kbps) available

Petr Lapukhov, 4xCCIE/CCDE
About Petr Lapukhov, 4xCCIE/CCDE

Petr Lapukhov has more than 12 years of experience working with Cisco Systems products. Not only is he the only person in the world to have earned four CCIEs (Routing & Switching, Security, Service Provider, and Voice) in just two years, he also passed every exam the first time. He shares his knowledge and experience with INE’s students through our various products and programs. Petr works with all of the technologies covered within his four CCIE tracks on a daily basis, staying current with any changes in the industry. He has also received his Cisco Certified Design Expert (CCDE) certification, joining a small group of distinguished individuals who have achieved this status. Petr is a contributor to INE’s blog and our INE IEOC Community Forum. You may contact Petr Lapukhov at petr@ine.com.

Subscribe to INE Blog Updates

New Blog Posts!