Angel, I believe I was running into the same problem the other day.
What I came to figure, is that it the policy maps and classes seemed to be all correct, because the counters would increase on the class but never the compress stats. What I found, which I think is the correct answer, is that you cannot apply class based cRTP to a frame-relay map class or similar. Whenever you have a frame-relay map class, you must go to the sub interface, and do: frame-relay ip rtp header-compression However if you would apply the exact same policy map to a Virtual Template for MLP LFI, the cRTP would work just fine. I believe there is some lab that is misleading, because it asks you to configure class based cRTP with FRF.12, which from my practice can't be done. I believe I read somewhere that class based cRTP and frame-relay don't match, but can't find it again. If someone could validate or refute my findings, will be appreciated. Cheers. On Mon, Mar 22, 2010 at 10:03 AM, Angel Perez <[email protected]> wrote: > Hi: > > After a reload the class map in classifiying packets correctly, but crtp > doesn't work either. > > * > Class-map: med (match-any) > 825 packets, 52840 bytes > > 5 minute offered rate 0 bps, drop rate 0 bps > Match: protocol rtp > 824 packets, 52736 bytes > > 5 minute rate 0 bps > Match: protocol rtcp > 1 packets, 104 bytes > > 5 minute rate 0 bps > Priority: 52 kbps, burst bytes 1500, b/w exceed drops: 0 > > compress: > header ip rtp > UDP/RTP (compression on, Cisco, RTP) > Sent: 0 total, 0 compressed, > 0 bytes saved, 0 bytes sent > rate 0 bps > * > > > ------------------------------ > From: [email protected] > To: [email protected] > Date: Mon, 22 Mar 2010 12:28:13 +0000 > Subject: [OSL | CCIE_Voice] CB Traffic shapping compress rtp headers > > > Hello: > > I want to compress rtp headers. The policy map is catching > traffic becouse I can see class-map "med" packets growing, but the problem > I have is that med class is not classifing this traffic as rtp, so I guess > this is way rtp compression is not working > > This situattion is very strange becouse the class-map is matching rtp or > rtcp (match any) so one of the two protocol counters should grow like the > class-map counter (see output) > > Could this be a bug? Any suggestions? > > > I've the following class map and policy map: > > *class-map match-any med > match protocol rtp > match protocol rtcp > class-map match-any sig > match protocol h323 > match protocol mgcp > match protocol rsvp > match protocol sip > match protocol skinny > ! > ! > policy-map voice > class med > priority 52 > compress head ip rtp > class sig > bandwidth 16 > class class-default > fair-queue > policy-map shapping > class class-default > shape average 384000 3840 > service-policy voice* > ** > show policy-map interface serial 0/2/0.102 > > > *HQ#sh policy-map interface seri 0/2/0.102 > Serial0/2/0.102: DLCI 102 -* > * Service-policy output: shapping* > * Class-map: class-default (match-any) > 10855 packets, 682844 bytes > 5 minute offered rate 0 bps, drop rate 0 bps > Match: any > Queueing > queue limit 64 packets > (queue depth/total drops/no-buffer drops) 0/0/0 > (pkts output/bytes output) 10855/682844 > shape (average) cir 384000, bc 3840, be 3840 > target shape rate 384000 > lower bound cir 0, adapt to fecn 0* > * Service-policy : voice* > * queue stats for all priority classes: > Queueing > queue limit 64 packets > (queue depth/total drops/no-buffer drops) 0/0/0 > (pkts output/bytes output) 6725/430332* > * Class-map: med (match-any) > 6725 packets, 430332 bytes > 5 minute offered rate 0 bps, drop rate 0 bps > Match: protocol rtp > 0 packets, 0 bytes > 5 minute rate 0 bps > Match: protocol rtcp > 0 packets, 0 bytes > 5 minute rate 0 bps > Priority: 52 kbps, burst bytes 1500, b/w exceed drops: 0 > > compress: > header ip rtp > UDP/RTP (compression on, Cisco, RTP) > Sent: 0 total, 0 compressed, > 0 bytes saved, 0 bytes sent > rate 0 bps* > > * Class-map: sig (match-any) > 158 packets, 13676 bytes > 5 minute offered rate 0 bps, drop rate 0 bps > Match: protocol h323 > 0 packets, 0 bytes > 5 minute rate 0 bps > Match: protocol mgcp > 0 packets, 0 bytes > 5 minute rate 0 bps > Match: protocol rsvp > 0 packets, 0 bytes > 5 minute rate 0 bps > Match: protocol sip > 0 packets, 0 bytes > 5 minute rate 0 bps > Match: protocol skinny > 158 packets, 13676 bytes > 5 minute rate 0 bps > Queueing > queue limit 64 packets > (queue depth/total drops/no-buffer drops) 0/0/0 > (pkts output/bytes output) 158/13676 > bandwidth 16 kbps* > * Class-map: class-default (match-any) > 3972 packets, 238836 bytes > 5 minute offered rate 0 bps, drop rate 0 bps > Match: any > Queueing > queue limit 64 packets > (queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0 > (pkts output/bytes output) 3972/238836 > Fair-queue: per-flow queue limit 16* > ** > > > ------------------------------ > Hotmail: Powerful Free email with security by Microsoft. Get it > now.<https://signup.live.com/signup.aspx?id=60969> > ------------------------------ > Hotmail: Trusted email with powerful SPAM protection. Sign up > now.<https://signup.live.com/signup.aspx?id=60969> > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
