At 11:14 PM 3/6/2008 +0800, Edwin Lok wrote: >Hi Tim, > >How about the egress policing on a 7600-SIP-400 and SPA-2X1GE-V2 combo?
Ingress and Egress policing on FlexWAN, Enhanced FlexWAN, 7600-SIP-200, and 7600-SIP-400 is performed the line card by the processors of vary types (CPU/NPU depends on the card). Ian >Is egress policing done at the egress or still on the FE ingress interfaces? > >Thanks > >Rgds >Edwin > >On Thu, Mar 6, 2008 at 1:24 AM, Tim Stevenson <[EMAIL PROTECTED]> wrote: > > The problem exists as long as there are multiple > > active forwarding engines in the box, even > if you use the uplinks on the sup. > > > > Tim > > > > (BTW, the uplinks on the RSP are active on both sups). > > > > At 06:51 AM 3/5/2008 -0600, Frank Bulk - iNAME observed: > > > > > > >Perhaps this is a naïve question, as I'm in the same boat as Jimmy, but > > >should I put my 2 backbones on my RSP720s > instead, one backbone on each of > > >them, to avoid the problem? Will the GigE > ports on each of the RSP720s be > > >in a working state, or only the active sup? > > > > > >Frank > > > > > >-----Original Message----- > > >From: [EMAIL PROTECTED] > > >[mailto:[EMAIL PROTECTED] On Behalf Of Jimmy > > >Sent: Tuesday, March 04, 2008 12:35 AM > > >To: [EMAIL PROTECTED]; [email protected] > > >Subject: Re: [c-nsp] output rate-limiting not working in 7609 > > > > > >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]; [email protected] > > >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: [email protected] > > > >>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 [email protected] > > > >>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. > > > > > >_______________________________________________ > > >cisco-nsp mailing list [email protected] > > >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. > > > > _______________________________________________ > > cisco-nsp mailing list [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > >_______________________________________________ >cisco-nsp mailing list [email protected] >https://puck.nether.net/mailman/listinfo/cisco-nsp >archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
