Hi Tim, Thanks again for your input. By the way, is this issue confirmed solved if we use ES20?
Cheers, Jimmy -----Original Message----- From: Tim Stevenson [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2008 3:20 PM To: Jimmy; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] output rate-limiting not working in 7609 As another poster suggested, this is a proverbial "hardware limitation" - there "may" be a future forwarding engine that resolves this issue by "synching" distributed policers. Assuming both hardware & software delivery on these platforms & that it works as we hope it will. As it stands right now, I am not aware of any workaround other than "converting" your egress polices to ingress, which is typically easier said than done. Tim At 02:34 PM 3/4/2008 +0800, Jimmy observed: >Hi Tim, > >Thanks for your input. >Actually we have 2 backbones connected to this 7600. >One is in slot 1 and the other one is in slot 2. >This explain the n times of the configured rate that I am getting on >that egress interface rite now (2x155M) > >Is there any better workaround? It is not good idea to put both >backbones on the same slot. It supposes to be for redundancy. > >Cheers, >Jimmy > >-----Original Message----- >From: Tim Stevenson [mailto:[EMAIL PROTECTED] >Sent: Tuesday, March 04, 2008 12:30 PM >To: Jimmy; [EMAIL PROTECTED]; [EMAIL PROTECTED]; >[EMAIL PROTECTED]; [EMAIL PROTECTED]; >cisco-nsp@puck.nether.net >Subject: Re: [c-nsp] output rate-limiting not working in 7609 > >At 08:15 PM 3/3/2008 -0800, Tim Stevenson observed: > >Jimmy, > >In 6500/7600, policing and other forwarding decisions are always > >performed on the INGRESS card - including egress policy enforcement. > >Above I meant to say "the INGRESS FORWARDING ENGINE" - which may be >just one, ie the PFC on the sup (regardless of which card the traffic >came in on), or could be one of many, ie, one of several DFCs that sit >on some/all cards. The rest of the below applies in that case. >Obviously with just one FE, there is only one point of policy action. > >Tim > > > >Therefore, in a distributed (ie, w/DFCs) system, you potentially > >could get n times the configured rate, where n is the number of > >forwarding engines that traffic destined for the egress interface > >could potentially come in on. > > > >Of course, the problem with your workaround is that no one module > >will ever allow more than 155M even if no traffic is coming in on the > >other module. > > > >Tim > > > >At 11:51 AM 3/4/2008 +0800, Jimmy observed: > >>Hi guys, > >> > >>Thanks for the feedback. Actually I have tried using MQC on the > >>egress >side. > >>It is Layer 3 port. > >>The port is in slot 1. For some reason when I do "show policy-map > >>interface", it is showing an output from 2 slots instead of 1. I am > >>using a dirty trick to temporarily solve the issue. I did policing > >>to 155M instead of 310M. With this setting, the traffic can only reach 310M. > >> > >>Any idea why we need to configure like that? Or anyone has > >>encountered the same issue? > >> > >>Cheers, > >>Jimmy > >> > >>------------------------------- > >>interface GigabitEthernet1/9 > >> ip route-cache flow > >> load-interval 30 > >> speed nonegotiate > >> mls netflow sampling > >> service-policy input CUSTOMER-310m > >> service-policy output CUSTOMER-155M > >> > >>policy-map CUSTOMER-155M > >> class class-default > >> police cir 155000000 bc 15500000 be 15500000 conform-action > >>transmit exceed-action drop ----> POLICE to 155M > >> > >>gw1.hkg4#sh policy int g1/9 > >> GigabitEthernet1/9 > >> > >> Service-policy output: CUSTOMER-155M > >> > >> class-map: class-default (match-any) > >> Match: any > >> police : > >> 155000000 bps 15500000 limit 15500000 extended limit > >> Earl in slot 1 : > >> 16889514278576 bytes > >> 30 second offered rate 196550600 bps > >> aggregate-forwarded 13191791357655 bytes action: transmit > >> exceeded 3697722920921 bytes action: drop > >> aggregate-forward 157101144 bps exceed 40026752 bps > >> Earl in slot 2 : ----------------------------> ANOTHER POLICING ??? > >> 14639062953589 bytes > >> 30 second offered rate 174721136 bps > >> aggregate-forwarded 13135487245073 bytes action: transmit > >> exceeded 1503575708516 bytes action: drop > >> aggregate-forward 159830912 bps exceed 18063232 bps > >> Earl in slot 5 : > >> 30560015 bytes > >> 30 second offered rate 176 bps > >> aggregate-forwarded 30560015 bytes action: transmit > >> exceeded 0 bytes action: drop > >> aggregate-forward 240 bps exceed 0 bps > >> > >>gw1.hkg4#sh mls qos ip g 1/9 > >> [In] Policy map is CUSTOMER-310m [Out] Policy map is CUSTOMER-155M > >> QoS Summary [IPv4]: (* - shared aggregates, Mod - switch module) > >> > >> Int Mod Dir Class-map DSCP Agg Trust Fl AgForward-By > >>AgPoliced-By > >> Id Id > >>-------------------------------------------------------------------- > >>-- > >>------ > >>--- > >> Gi1/9 1 In class-defa 0 1 dscp 0 486690994913 > >>54268431391 > >> Gi1/9 1 Out class-defa 0 2 -- 0 548444567177 > >>399451084094 > >> Gi1/9 2 Out class-defa 0 1 -- 0 492136489401 > >>404181645273 ----> SHOULDN'T HAVE ANY OUTPUT > >> Gi1/9 5 Out class-defa 0 1 -- 0 30561099 > >>0 > >>----------------------------------------------- > >> > >>-----Original Message----- > >>From: Pete Templin [mailto:[EMAIL PROTECTED] > >>Sent: Tuesday, March 04, 2008 12:26 AM > >>To: Jimmy > >>Cc: cisco-nsp@puck.nether.net > >>Subject: Re: [c-nsp] output rate-limiting not working in 7609 > >> > >>Jimmy wrote: > >> > >> > I have encountered rate-limiting issue on CISCO7609 platform. > >> > > >> > Example is: > >> > > >> > interface GigabitEthernet1/9 > >> > rate-limit input 310000000 4843750 9687500 conform-action > >> > transmit exceed-action drop rate-limit output 310000000 4843750 > >> > 9687500 conform-action transmit exceed-action drop -------> NOT > >> > WORKING > >> > > >> > The output rate-limiting is not working. The traffic still can go > >> > above 310M and can hit 1G. > >> > I have created SR with cisco. They are saying there is no work > >> > around for this except that we use ES20 to use policy-map on the >interface. > >> > >>Your example is too short - is it a layer 3 port? If so, a policer > >>inside a policy-map should work. If not, it won't work. From the > >>Sup720 >datasheet: > >>rate limiting is possible on "Ingress port or VLAN and egress VLAN > >>or > >>Layer-3 port". > >> > >>pt > >> > >>_______________________________________________ > >>cisco-nsp mailing list cisco-nsp@puck.nether.net > >>https://puck.nether.net/mailman/listinfo/cisco-nsp > >>archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > > > > >Tim Stevenson, [EMAIL PROTECTED] > >Routing & Switching CCIE #5561 > >Technical Marketing Engineer, Data Center BU Cisco Systems, > >http://www.cisco.com IP Phone: 408-526-6759 > >******************************************************** > >The contents of this message may be *Cisco Confidential* and are > >intended for the specified recipients only. > > > >Tim Stevenson, [EMAIL PROTECTED] >Routing & Switching CCIE #5561 >Technical Marketing Engineer, Data Center BU Cisco Systems, >http://www.cisco.com IP Phone: 408-526-6759 >******************************************************** >The contents of this message may be *Cisco Confidential* and are >intended for the specified recipients only. Tim Stevenson, [EMAIL PROTECTED] Routing & Switching CCIE #5561 Technical Marketing Engineer, Data Center BU Cisco Systems, http://www.cisco.com IP Phone: 408-526-6759 ******************************************************** The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/