[c-nsp] One or two policy and class maps?

Paolo Lucente pl+list at pmacct.net
Tue Dec 11 07:25:49 EST 2007


Hi Frank,

the Sup32 is the supervisor engine meant for deployments at the access
layer - ie. in this context it supports SRR (which is way better the
blunt egress policing) and WRED. No switch fabric though.

Full-featured shaping is not cheap as you need intelligent WAN hardware
in order to do that (FlexWANs, SIPs/SPAs). SRR (Shaped Round Robin), on
the other hand, is also supported on selected LAN modules and thus it's
likely to result cheaper to implement. Again SRR is typically an access
thing, requires dedicating ports as it's a scheduling algorithm and is
applied to interfaces, no SVIs. All in all, ther is an option.

Cheers,
Paolo


On Mon, Dec 10, 2007 at 05:57:18PM -0600, Frank Bulk wrote:
> To answer my own question, almost two months later: we settled on using an
> 'any any' for our ACL and since I'm told this is done in hardware, it
> doesn't really matter if there are one or two class maps.
> 
> We can only do policing, not shaping, because we're not working with OSMs.
> Yes, the traffic flow is choppy, but that's all there's to it.  It does seem
> to work consistently well if the traffic in inter or intra-blade.
> 
> So despite the fancy SUP module and DFC3C's on our 10/100/1000 blade, the
> only thing we gain is outbound policing.
> 
> Frank
>  
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Frank Bulk
> Sent: Thursday, October 18, 2007 9:36 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] One or two policy and class maps?
> 
> I have a 7609-S with the RSP720 and PFC3C, which supports in and outbound
> QoS flows.
> 
> Should I be using one or two policy and class maps?  The first method, if I
> understand this correctly, has a single service policy in configuration that
> is moot because there will never be matches one direction.  The second one,
> while more complex, eliminates checking flow ACL matches that will never
> exist.
> 
> This:
> 
> class-map match-any test-networks
>   match access-group name test-policer-inbound
>   match access-group name test-policer-outbound
> 
> policy-map test-policer
>   class test-networks
>    police cir 2000000 pir 2000000    conform-action transmit
> exceed-action drop
> 
> interface Vlan203
>  ip address 167.a.b.c 255.255.255.252
>  service-policy input test-policer
>  service-policy output test-policer
> end
> 
> or this:
> 
> class-map match-any test-inbound-networks
>   match access-group name test-policer-inbound
> 
> class-map match-any test-outbound-networks
>   match access-group name test-policer-outbound
> 
> policy-map test-inbound-policer
>   class test-inbound-networks
>    police cir 2000000 pir 2000000    conform-action transmit
> exceed-action drop
> 
> policy-map test-outbound-policer
>   class test-outbound-networks
>    police cir 2000000 pir 2000000    conform-action transmit
> exceed-action drop
> 
> interface Vlan203
>  ip address 167.a.b.c 255.255.255.252
>  service-policy input test-inbound-policer
>  service-policy output test-outbound-policer
> end
> 
> The rest of the config can be found below.
> 
> Regards,
> 
> Frank
> =====================================================
> vlan 203
>  name Test
> 
> interface GigabitEthernet1/5
>  description Test
>  switchport
>  switchport access vlan 203
>  speed 100
>  duplex full
> 
> ip access-list extended test-policer_inbound
>  permit ip any d.e.f.0 0.0.0.255
> ip access-list extended test-policer_outbound
>  permit ip d.e.f.0 0.0.0.255 any



More information about the cisco-nsp mailing list