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
- 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
- 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
- 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
- Note that available bandwidth will be calculated from minCIR value, which is CIR/2 by default
Example: Implement CBWFQ Per-VC
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_384KVerification: 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 0The 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 dequeuedCheck 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_LOWVerfication: 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_FRF12Verfication: 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 0Look 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 113Verfication:
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_CBWFQVerfication: 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 0To 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
0 comments:
Post a Comment