From: Petr Lapukhov (petrsoft@gmail.com)
Date: Wed Mar 29 2006 - 09:11:44 GMT-3
Hello Steve,
To have both configs equivalent, you need to specify
"shape average" in policy-map.
shape peak has long time been a stange thing for most of us.
Back it times, Chris Lewis noted, that it has been created for
specific customer for some "specific purpose" :)
Actually "shape peak" behaves like shape average,
having Tc=Bc/CIR, but every Tc it could send Bc+Be number of bytes,
if needed.(shape average could send Be, only if it has enough credits
accumulated for intervals of silence).
So you could get target "average" rate of (Bc+Be)/Tc with "shape peak".
HTH
Petr
2006/3/29, steve@lockdown.nu <steve@lockdown.nu>:
>
> 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