[c-nsp] ES20+ L3 subinterface or service instance ?

Tony td_miles at yahoo.com
Tue Apr 23 19:37:13 EDT 2013


Hi,





>________________________________
> From: Saku Ytti <saku at ytti.fi>
>
>On (2013-04-21 03:11 -0700), Tony wrote:
>
>Hi,
>
>> We are starting to migrate some connections from SIP400/SPA to ES20+ cards on our 7609's (sup720 w/ SRD4)
>
>> interface GigabitEthernet2/0/1.512
>>  service-policy output shape_to_carrier_tail_speed
>
>You should definitely use subinterfaces when you can, EVC when you must.
>
>Please pay attention to your MQC configs, SIP400 and ES+ QoS configs are
>not 1:1 compatible. You should relab all your QoS to confirm they behave in
>a manner you expect.
>Even when it's simple as shaper, ask yourself, do you expect to receive L1
>or L2 speed? What are you receiving today?
>

Thanks for the tip, can you put me out of my misery and say which one shapes at L1 and which at L2 ?

I was making some changes this morning and I got this error:

"Police and Strict Priority must be configured together"

when trying to apply an existing policy to an ES+ sub-interface. Which is strange because I thought that a PQ always had a built in policer at it's rate to prevent it from starving other queue's anyway.

The policy-map in question looks like this:

policy-map pq-and-data-5m
  class class-default
    shape average 5000000
   service-policy pq-and-data-policy

policy-map pq-and-data-policy
  class class-pq
    priority percent 40
  class class-data
    bandwidth percent 35

So that it shapes to the link speed (5Mbps in this case) and then creates two queues, one a PQ (for VoIP typically) and the other a queue for important stuff (eg. signalling, Citrix/RDP, etc). We have different parent shapers for different links speeds but they all use the same child policy so a "percent" value is required rather than a fixed bandwidth amount.

The above works on the SIP400, but gave that error when I tried to apply it to the ES card.

This is easy enough to work around by changing the child policy to be this instead:

policy-map pq-and-data-policy
  class class-pq
   police rate percent 40
    priority
  class class-data
    bandwidth percent 35

Is there any real difference between the two policies ? If I look at the output from "show policy-map" they appear to be much the same in what they are doing (bandwidths are different because one is 2M & one is 5M parent shaper):

SPA:
        Class-map: class-pq (match-any)
          4228795 packets, 332827590 bytes
          30 second offered rate 0000 bps, drop rate 0000 bps
          Match: ip dscp ef (46)
          Match: ip dscp cs5 (40)
          Priority: 40% (800 kbps), burst bytes 20000, b/w exceed drops: 0

ES:
        Class-map: class-pq (match-any)
          0 packets, 0 bytes
          30 second offered rate 0000 bps, drop rate 0000 bps
          Match: ip dscp ef (46)
          Match: ip dscp cs5 (40)
          police:
             rate 40 %
               (2000000 bps, burst 62500 bytes)
              conformed 0 packets, 0 bytes; action:
                transmit
              exceeded 0 packets, 0 bytes; action:
                drop
              conformed 0000 bps, exceeded 0000 bps
          Priority: Strict, b/w exceed drops: 0


I am yet to try and see if the policy with the additional specific "police" command will work on the SPA, but is there any reason why it shouldn't ? We'd prefer to having a single set of child policies that will work on both cards, rather than maintaining another set just for the ES cards.

Thanks,
Tony.




More information about the cisco-nsp mailing list