Legacy Frame-Relay Traffic Shaping

 

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.
Thekey characteristic is that all settings are configured under map-class command mode, and later are applied to a particular set PVCs. The
sameconfiguration concept was used for legacy ATM configuration mode (map-class atm).

LegacyFRTS 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 112PVC 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 usesFIFO as per-VC queue:

Rack1R1#show frame-relay pvc 113PVC 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 4pririty 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 tolow 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 112PVC 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 113PVC 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 interfacequeue is changed to dual-FIFO
- This is due to the fact that fragmentation is ineffective withoutinterleaving
- Fragment size is calculated based on physical interface speed to allowminimum serialization delay

Example: Enable FRF.12 fragmentation for PVC DLCI 112 and physicalinterface 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 112PVC 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 (inversePIPQ)
- 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 andsend 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 101interface 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:0Interface Serial0/0/0:0 queueing strategy: priorityOutput queue utilization (queue/count)	high/217 medium/0 normal/1104 low/55Rack1R1#show frame-relay pvc 112PVC 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 withFRTS
- 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 112PVC 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 undermap-class do the following:

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

ShareThis