[c-nsp] output rate-limiting not working in 7609
Tim Stevenson
tstevens at cisco.com
Wed Mar 5 12:24:30 EST 2008
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: cisco-nsp-bounces at puck.nether.net
>[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jimmy
>Sent: Tuesday, March 04, 2008 12:35 AM
>To: tstevens at cisco.com; cisco-nsp at puck.nether.net
>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: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.
>
>_______________________________________________
>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.
More information about the cisco-nsp
mailing list