From: steve@lockdown.nu
Date: Wed Mar 29 2006 - 07:02:29 GMT-3
Hi Petr, this email got me thinking.... would you say the following
configurations are functionally equivalent? On r1 I have configured MQC
based shape, and on r2 I have configured FRTS.
I am still unsure about the difference between shaping to average, and
shaping to peak though :(
!++++++++++++++++++++++ ROUTER 1 ++++++++++++++++++++++++++
policy-map PM2
class class-default
shape peak 256000 2560 5120
interface Serial0/0
ip address 1.1.1.102 255.255.255.0
encapsulation frame-relay
frame-relay map ip 1.1.1.201 102
frame-relay interface-dlci 102
class DLCI102_SHAPE
no frame-relay inverse-arp
map-class frame-relay DLCI102_SHAPE
service-policy output PM2
Rack1R1#show policy-map interface s0/0
Serial0/0: DLCI 102 -
Service-policy output: PM2
Class-map: class-default (match-any)
10 packets, 1040 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
768000/256000 960 2560 5120 10 960
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 10 1040 0 0 no
Rack1R1#show frame-relay pvc 102
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
input pkts 10 output pkts 10 in bytes 1040
out bytes 1040 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:17:51, last time pvc status changed 00:09:10
! +++++++++++++++++++++++++++ ROUTER 2 ++++++++++++++++++++++++++
interface Serial0/0
ip address 1.1.1.201 255.255.255.0
encapsulation frame-relay
no fair-queue
frame-relay traffic-shaping
frame-relay map ip 1.1.1.102 201
frame-relay interface-dlci 201
class DLCI201_SHAPE
no frame-relay inverse-arp
map-class frame-relay DLCI201_SHAPE
frame-relay cir 256000
frame-relay bc 2560
frame-relay be 5120
Rack1R2#show frame-relay pvc 201
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
input pkts 10 output pkts 10 in bytes 1040
out bytes 1040 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:08:58, last time pvc status changed 00:05:41
cir 256000 bc 2560 be 5120 byte limit 960 interval 10
mincir 128000 byte increment 320 Adaptive Shaping none
pkts 0 bytes 0 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: fifo
Output queue 0/40, 0 drop, 0 dequeued
> Hello Group,
>
> FR QoS has been a long time pain in the neck for most of us :))
> I tried to create a short summary of things I learned about FR QoS
> options.
>
> Hope you find it useful, and of course, any kind of feedback is welcome!
> :)
>
> Petr
>
> Frame-Relay QoS Options
>
> #1 Regulating traffic flow - shaping & policing:
>
> #1.1 GTS (legacy)
>
> - As usual GTS, works with WFQ shaper's queue.
> - Works per intf/subintf (no PVC granularity)
> - You can use adaptive keyword to adapt to BECNs, reflect as FECNs
> (As i understand, BECN received on any intf/subintf's PVCs
> will cause sending rate to fall down to minCIR)
> - You can use Fancy-queueing on interface with GTS.
>
> #1.2 FRTS (legacy)
>
> - Enforces rate per-VC (granular) - 56kbit 125ms default
> - FRTS parameters are configured under "map-class frame-relay"
> and require "frame-relay traffic-shaping" interface
> command
> - You can enable Fancy-queueing/FIFO per-VC
> - You can't enable Fancy-queueing at interface
> - Interface queue forced to FIFO (if no FRF.12)
> - Interface queue could be turned to PIPQ (PVCs
> are assigned to 4 pririty groups)
> - Interface queue forced to dual-FIFO (with FRF.12)
> - You can map 4 priority groups to 4 different VCs
> - You can turn per-VC queue to CBWFQ/LLQ, yet shape with FRTS
> (available queue bandwidth is calculated from minCIR/CIR)
> applied with "service policy" in "map-class frame-relay"
>
> #1.3 MQC FRTS (brand new)
>
> - No "frame-relay traffic-shaping" interface command required
> - Shaping is configure with MQC commands (shape average/adaprive),
> but you still use "map-class frame-relay" to apply it to DLCI
> - You can't use Fancy Queueing as per-VC queue, only CBWFQ/LLQ,
> as shaper's queue (hierarchical policy-maps config; available
> bandwidth is calculated from adaptive/average shape values).
> - You can't apply fragmentation in MQC config (hell i dunno why!
> :),
> you should apply it at interface level or at map-class.
> - Interface queue could be Fancy (not resticted to FIFO as with
> FRTS
> legacy)
> - You can't enable dual FIFO on interface with MQC FRTS
>
> #1.4 FR Adaptive traffic shaping (backoff to minCIR)
>
> - BECN adaptive - works with GTS/FRTS/MQC
> - Voice adaptive (VATS): You can enable VATS only with MQC (no
> FRTS
> support)
> - Intf congestion: You can enable this with MQC as well as with
> FRTS
> - VATS requires MQC shaping in VC's parent policy, and LLQ
> configured in
> child policy
>
> #1.5 Policing (generic)
>
> - CAR (per interface/subinterface)
> - MQC policer (per-class, per-VC policing) - same as usual.
> One note - you can set DE as markdown option.
>
> #2 Congestion Management:
>
> Remember, to queue at subintf, you need to create a state of congestion
> there,
> either with FRTS legacy, or with MQC FRTS.
>
> - With no configuration applied, all VCs share single interface queue
> - FRTS enables per-VC queueing (+shaping the same time)
> - FRTS permits per-VC Fancy Queueing
> - FRTS permits mapping 4 priority groups to 4 different VCs
> - Legacy FRTS could force interface queue to FIFO/dual FIFO/PIPQ
> - With MQC FRTS you need to enable MQC shaping in parent policy,
> in order to engage CBWFQ/LLQ in child policy.
> - MQC FRTS could exist with fancy-queueing on interface
> - dual FIFO in turned on by FRF.12 configuration in map-class +
> FRTS legacy enable on interface (simple FIFO)
> - FRF.12 in map-class turns per-VC queue to WFQ
> - Simply enabling per-VC IP RTP Priority/LLQ does not turn interface
> queue to dual FIFO
> - You can tune FR broadcast queue separately on interface
>
> #3 Classification & Marking
>
> - As usual, you can mark/classify with MQC
> - You can match DCLI in MQC class-map
> - MQC could be applied per-VC (with map-class)
> - MQC could be applied per-intf/subintf (with map-class or with
> service-policy, where you match dlci)
> - You can also mark with CAR (generic technique)
> - You can use markdown feature in MQC policer (generic technique)
> - You can set DE bit with legacy inteface commands per-VC
> (de-list/group)
> - You can set DE bit with MQC (class-based)
> - You can set DE bit with MQC policer markdown
>
> #4 Link Efficiency:
>
> Note, compression is performed before fragmentation
>
> #4.1 Fragmentation (FRF.12)
>
> - You can enable fragmentation with FRTS (per map-class)
> and apply it per-VC, per intrf/subintf
> - You can enable fragmentation at interface level
> (for all VCs) with FRTS legacy turned OFF
> - With interface-level fragmentation you can shape/queue
> only with MQC
> - When you turn on FRF.12 in map-class with FRTS, interface
> queue is forced to dual-FIFO
> - You can enable voice-adaptive fragmentation with FRTS or with
> MQC
> - To enable voice-adaptive fragmentation you need LLQ either
> within
> FRTS map-class, or configured with MQC
> - with FRF.12 and legacy FRTS you can only use WFQ/LLQ per-VC
> - Fragmentation is performed AFTER per-VC dequeueing
> - With dual FIFO unfragmented packets go to high-pririry queue
>
> #4.2 TCP header compression
>
> - TCP HC requires CISCO encapsulation on DLCI
> - You can tune specific dlci to use CISCO encapsulation
> with "frame-relay map"
> - TCP HC could be enabled per interfaces/subinterface/DLCI
> - TCP HC at interface prohibits the use of PQ/CQ at interface
> - TCP HC could be class-based with MQC configuration
> - TCP HC should be configured with frame-relay commands (not
> generic)
>
> #2.3 RTP header compression
>
> - Configured with frame-relay commands (non-generic)
> - No IPHC/ECRTP support
> - Could be configured per-VC (with frame-relay map)
> - RTP hdr compression could be class-based (with MQC)
>
> #4.4 Payload compression
>
> - Three types of compression
> - Could be tuned per-VC or per-interface/subinterface
> - Cisco-proprietary types require cisco encapsulation (per-VC)
>
> References:
>
> Configuring FR
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hwan_c/
> ch05/index.htm
>
> MQC FRTS
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hwan_c/
> ch05/hfrqosmq.htm
>
> LLQ for FRTS
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t
> /121t2/dtfrpqfq.htm
>
> FR Fragmentation at interface
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hwan_c/
> ch05/hfrfrint.htm
>
> VATS
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hwan_c/
> ch05/h_vats.htm
>
> Class-based header compression
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hqos_c/
> part30/ch10/qshdcmp4.htm
>
> IP RTP header compression
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hqos_c/
> part30/ch10/qshdcmp2.htm
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:40 GMT-3