Policing on a Switch

GabeGabe ✭✭

 

R1--------|   
              | SW1------SW2-------R3
R2--------|

 

Hello community, I cannot understand the behavior I am seeing here. Can someone help please?

SW1(config)#int ra f0/1 , f0/3
SW1(config-if-range)#mls qos trust dscp

SW1(config-if-range)#do sh mls qos int f0/1 ----------> Link to R1
FastEthernet0/1
trust state: trust dscp
trust mode: trust dscp
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: port-based

SW1(config-if-range)#do sh mls qos int f0/3 ----------------> Link to R2
FastEthernet0/3
trust state: trust dscp
trust mode: trust dscp
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: port-based

 

SW2(config)#do sh policy-map int f0/13 -------------------> Link to SW1
 FastEthernet0/13

  Service-policy input: Police

    Class-map: DSCP-10 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp af11 (10)

    Class-map: DSCP-20 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp af22 (20)

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps

SW2(config)#do sh mls qos int f0/13
FastEthernet0/13
Attached policy-map for Ingress: Police
trust state: trust dscp
trust mode: trust dscp
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: DSCP-1->60
Trust device: none
qos mode: port-based

SW2(config)#do sh mls qos map dscp-mutation

   Dscp-dscp mutation map:
   DSCP-1->60:
     d1 :  d2 0  1  2  3  4  5  6  7  8  9
     ---------------------------------------
      0 :    00 60 02 03 04 05 06 07 08 09
      1 :    10 11 12 13 14 15 16 17 18 19
      2 :    20 21 22 23 24 25 26 27 28 29
      3 :    30 31 32 33 34 35 36 37 38 39
      4 :    40 41 42 43 44 45 46 47 48 49
      5 :    50 51 52 53 54 55 56 57 58 59
      6 :    60 61 62 63

1) If SW2 has DSCP rewrite enabled, R3 sees DSCP 0 instead coming from both R1,R2 instead of DSCP 10 and 20 respectively and the policer on SW2 does not seem to match anything, not even the class-default class. Why does the policy not show any match?

SW2(config)#do sh mls qos
QoS is enabled
QoS ip packet dscp rewrite is enabled

SW2(config)#do sh policy-map int f0/13
 FastEthernet0/13

  Service-policy input: Police

    Class-map: DSCP-10 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp af11 (10)

    Class-map: DSCP-20 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp af22 (20)

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps

R3(config)#do sh policy-map int g0/0 | s DSCP-10|DSCP-20|DSCP-0
    Class-map: DSCP-10 (match-all)
      0 packets, 0 bytes
      30 second offered rate 0 bps
      Match:  dscp af11 (10)

    Class-map: DSCP-20 (match-all)
      0 packets, 0 bytes
      30 second offered rate 0 bps
      Match:  dscp af22 (20)

    Class-map: DSCP-0 (match-all)
      1013 packets, 1533682 bytes
      30 second offered rate 293000 bps
      Match:  dscp default (0)

2) After resetting the counters on R3 and disabling DSCP rewrite on SW2, R3 starts matching on DSCP 10 and 20, but SW2's policy map still does not match on anything. Why does R3 start seeing DSCP 10 and 20 when DSCP rewrite is disabled? Why does SW2's policy map not show any matches? (I did try disabling and re-enabling "mls qos")

SW2(config)#no mls qos rewrite ip dscp
SW2(config)#do sh mls qos
QoS is enabled
QoS ip packet dscp rewrite is disabled

SW2(config)#do sh policy-map int f0/13
 FastEthernet0/13

  Service-policy input: Police

    Class-map: DSCP-10 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp af11 (10)

    Class-map: DSCP-20 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp af22 (20)

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
        0 packets, 0 bytes
        5 minute rate 0 bps

R3(config)#do clear counters
Clear "show interface" counters on all interfaces [confirm]
R3(config)#do sh policy-map int g0/0 | s DSCP-10|DSCP-20|DSCP-0
*Apr 10 02:07:42.177: %CLEAR-5-COUNTERS: Clear counter on all interfaces by console
R3(config)#do sh policy-map int g0/0 | s DSCP-10|DSCP-20|DSCP-0
    Class-map: DSCP-10 (match-all)
      97 packets, 146858 bytes
      30 second offered rate 147000 bps
      Match:  dscp af11 (10)

    Class-map: DSCP-20 (match-all)
      72 packets, 109008 bytes
      30 second offered rate 107000 bps
      Match:  dscp af22 (20)

    Class-map: DSCP-0 (match-all)
      0 packets, 0 bytes
      30 second offered rate 520000 bps
      Match:  dscp default (0)

Thanks in advance and sorry for the long post

Comments

  • Which switches are you using and image version?

    Could you post ur configs to see where is the problem etc.

    Thanks

  • GabeGabe ✭✭

    They are 3560-X switches running 12.2(55) but I think this is how they are supposed to behave although I do not understand why...

    R1:
    policy-map QoS-Out
      class class-default
        set dscp 10
    !
    int f0/0
      ip add 10.1.1.1 255.255.255.0
      service-policy output QoS-Out

    R2:
    policy-map QoS-Out
      class class-default
        set dscp 20
    !
    int f0/0
      ip add 10.1.1.2 255.255.255.0
      service-policy output QoS-Out

    R3:
    class-map DSCP-10
      match dscp 10
    !
    class-map DSCP-20
      match dscp 20
    !
    policy-map QoS-In
      class DSCP-10
      class DSCP-20
    !
    int g0/0
      ip add 10.1.1.3 255.255.255.0
      service-policy input QoS-In

    SW1
    mls qos
    !
    int f0/1
      description to R1
      mls qos trust dscp
    !
    int f0/3
      description to R2
      mls qos trust dscp
    !
    int f0/13
     description ToSW2
     sw trunk encap dot
     sw mode trunk

    SW2:
    mls qos
    mls qos map dscp-mutation DSCP-1->60 1 to 60 ----> You can ignore this line as it was for another testing
    mls qos rewrite ip dscp ---> This is on by default and traffic gets remarked to DSCP 0 with this feature on
    no mls qos rewrite ip dscp ---> I turned it off and then R3 starts seeing traffic marked with DSCP 10 and 20 but
    ! when I enter "show policy-map int f0/13" on SW2, the policy does not show any matches (see first post)
    !
    class-map DSCP-10
      match ip dscp 10
    !
    class-map DSCP-20
      match ip dscp 20
    !
    policy-map Police
      class DSCP-10
        police 1000000 32000 exceed drop
      class DSCP-20
        police 2000000 32000 exceed drop
    !
    int f0/13
      description to SW1
      sw trunk encap dot
      sw mode trunk
      mls qos trust dscp
      mls qos dscp-mutation DSCP-1->60 -----> Ignore this
      service-policy input Police
    !
    int f0/2
      description to R3

    Thanks for looking into this, I hope you can help me understand the behavior seen here :)

  • I think this may help with your first quesiton:

    The QoS counters on the Catalyst switches, although present in the out seldome populated.  I belive this is a due to hardware limiations of ASICs.  I know this to be true of hte 3560s, I suspect the same with 3560x.

    Therefor:   show policy-map inter x/y   will no show you anything,  but show mls qos inter x/y statistics will

    Example below:

    On SW2:
    clear mls qos interface statistics
    !

    From R1:

    Rack1R1#ping 1.2.3.3 repeat 33
    Type escape sequence to abort.
    Sending 33, 100-byte ICMP Echos to 1.2.3.3, timeout is 2 seconds:
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    Success rate is 100 percent (33/33), round-trip min/avg/max = 1/3/4 ms


    On SW2:

    Rack1SW2#show mls qos inter fa0/13 statistics
    FastEthernet0/13 (All statistics are in packets)

      dscp: incoming
    -------------------------------

      0 -  4 :           0            0            0            0            0
      5 -  9 :           0            0            0            0            0
     10 - 14 :          33            0            0            0            0
     15 - 19 :           0            0            0            0            0
     20 - 24 :           0            0            0            0            0
     25 - 29 :           0            0            0            0            0
     30 - 34 :           0            0            0            0            0
     35 - 39 :           0            0            0            0            0

    ...
    <Output Snipped>
    .......

    Policer: Inprofile:           33 OutofProfile:            0

    Rack1SW2#

     

     

  • Regarding question #2:

    What behaviour would you expect?   Think about it, if you are telling switch to leave the DSCP marking along "no mls qos rewirte ip dscp",  and you are trusting the DSCP marking inbound....why would R3 NOT see those markings?

    Maybe I miss-understood you question on this one.

  • GabeGabe ✭✭

    Hi 1000BaseT... cool name by the way ;)

    Thanks for looking into this!!!

    I did see the interface statistics accounting for the incoming DSCP values but I was looking for a better "show" command to validate the policer is working in terms of bandwidth restrictions without going to R3. Is there such command? So the policy map shows nothing due to hardware limitations if I understood correctly?

    For the second question, I am trying to understand why the switch rewrites packets to 0 (mls qos rewrite ip dscp) if the port is already trusting DSCP marks. If you take the policer off the port the switch does not rewrite anything to 0 but if you apply the policer to the port again, the switch goes back to rewriting packets to 0. Why?

  • Hi Gabe,

    Thanks…and no prob!

    #1, Correct…to see if your policer is working (aka active or not),  I think the best you’re going to get (as far as I know) is “In profile” / “Out of Profile”.       If it’s in profiles, those packets were under your policer’s CIR,  if out of profile…there were above the CIR and drop or remarked, etc.

     

    Rack1SW2#show mls qos inter fa0/13 statistics | be Policer

    Policer: Inprofile:           33 OutofProfile:            0

     

    #2   Now I understand your question.   This is because; you are not trusting in the policy-map.   Once the packet is matched in the policy-map (if there is no trust)  it does not fall back to the interface trust setting.  You set the trust dscp at the interface level, but that is ignored due to the policy-map being applied.

    To fix simply, go to your policy, add the “trust dscp” command under some (or all) of your defined classes.  

    HTH.

  • GabeGabe ✭✭

    Amazing... thanks a lot for clearing things up on #2. I did not know you also had to trust at the policy map level and always wondered what that command was there for. What's the logig behind it though? I mean, if you trust it on an interface level I would think it means you DO WANT to trust it so why would you have to confirm that at the policy map level as well?

    Again, thanks for sharing the knowledge :)

Sign In or Register to comment.