[c-nsp] output rate-limiting not working in 7609
Jimmy
jimmy at pacnet.net
Tue Mar 4 04:49:20 EST 2008
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:tstevens at cisco.com]
Sent: Tuesday, March 04, 2008 3:20 PM
To: Jimmy; cisco-nsp at 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:tstevens at cisco.com]
>Sent: Tuesday, March 04, 2008 12:30 PM
>To: Jimmy; petelists at templin.org; mtinka at globaltransit.net;
>christian at qunec.net; gniewomir.krol at aci.com.pl;
>cisco-nsp at 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:petelists at templin.org]
> >>Sent: Tuesday, March 04, 2008 12:26 AM
> >>To: Jimmy
> >>Cc: cisco-nsp at 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 at puck.nether.net
> >>https://puck.nether.net/mailman/listinfo/cisco-nsp
> >>archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> >
> >
> >Tim Stevenson, tstevens at cisco.com
> >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, tstevens at cisco.com
>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, tstevens at cisco.com
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.
More information about the cisco-nsp
mailing list