MPLS QoS marking problems

[smailmilak]

Hi,

I have a problem with MPLS EXP marking between two devices. One is Cisco ME3600X and the other a 7609 RSP720 with ES+ card,

I mark the traffic on the ME3600X on the ingress interfaces, and on the egress interface I successfully match the marked packets (MPLS EXP bit 5).

Note: The ME3600X has a MPLS FRR tunnel configured and all traffic is passing through this tunnel (in OSPF routing table the next hop is the FRR tunnel).

The problem is that I don't see the marked EXP bit 5 on the neighbor router, but I see only EXP bit 0.

Trusting is configured on the 7609, well looks like it is enabled by default.

Do you have an idea or a document where I see how MPLS QoS should be configured when using mpls tunnels?

I already have the configuration guide for the ME3600X but the is no information how to solve this issue.

Is there a debug command which could help me.

[smailmilak]

Hi,

I edited my previous post a little bit, read the red text.

With "setting up mpls experimental impostion" you mean set (mark) with EXP 5 on the ingress interface?

Or matching it?

[Vaibhava Varma]

Hismailmilak

I did go through your text. I don't think this can be a platform related issue personally untill unless we see the result of setting up mpls experimental exposition 5 on the ingress of ME3600 where the L2 Traffic is arriving.

Regarding your questions :

–MPLS   can tunnel the QoS values of a packet (that is, QoS is transparent  from  edge to edge). With QoS transparency, the IP marking in the IP  packet  is preserved across the MPLS network.

Why do I have a problem then

SP Core is transparent to CE Traffic if  no QoS being applied within the Core based on EXP

The switch does not support egress QoS marking.  Hmm I am marking on ingress, and the marked packet should just be forwarded without       modifiyng it

Egress Policing is not applicable in some of the platforms as I have seen it,

•MPLS QoS classification does not work for bridged MPLS packets. What are "bridged" MPLS packets

I am not sure what bridged MPLS Packet means may be they are saying something for L2 VPN Traffic but again we can classify for L2 Traffic either it be ATM or Ethernet.

My last suggestion would be to set the mpls experimental impostion and notice any difference.

Regards

Varma

[smailmilak]

Hi,

I did what you said and there is no difference:

ME 3600X ingress interface

sh policy-map interface gi 0/3 service instance 799

GigabitEthernet0/3: EFP 799

  Service-policy input: TEST_INGRESS

    Class-map: hvataj_DSCP_ef (match-all) 

      12 packets, 984 bytes

      5 minute offered rate 0000 bps, drop rate 0000 bps

      Match:  dscp ef (46)

        set mpls exp imposition 5

    Class-map: class-default (match-any) 

      0 packets, 0 bytes

      5 minute offered rate 0000 bps, drop rate 0000 bps

      Match: any

Egress interface

sh policy-map interface gi 0/24

GigabitEthernet0/24

  Service-policy output: MPLS_LLQ_WAN_ES20

    Class-map: MPLS_VOICE (match-any) 

      18 packets, 1440 bytes

      30 second offered rate 0000 bps, drop rate 0000 bps

      Match: mpls experimental topmost 3  5

      police:

        cir 150000000 bps, bc 4687500 bytes

        conform-action transmit

        exceed-action drop

      conform: 19 (packets) 1446 (bytes)

      exceed: 0 (packets) 0 (bytes)

      conform: 0 bps, exceed: 0 bps

          Strict Priority

          Queue-limit current-queue-depth 0 bytes

              Output Queue:

                Tail Packets Drop: 0

                Tail Bytes Drop: 0

    Class-map: MPLS_CONTROL (match-any) 

      0 packets, 0 bytes

      30 second offered rate 0000 bps, drop rate 0000 bps

      Match: mpls experimental topmost 6

      Match: ip dscp cs6 (48)

          Bandwidth 1 (percent)

          Queue-limit current-queue-depth 0 bytes

              Output Queue:

                Tail Packets Drop: 0

                Tail Bytes Drop: 0

    Class-map: MPLS_VIDEO (match-any) 

      0 packets, 0 bytes

      30 second offered rate 0000 bps, drop rate 0000 bps

      Match: mpls experimental topmost 4

      Match: ip dscp cs4 (32)

          Bandwidth 30 (percent)

          Queue-limit current-queue-depth 0 bytes

              Output Queue:

                Tail Packets Drop: 0

                Tail Bytes Drop: 0

    Class-map: MPLS_CUSTOMER (match-any) 

      0 packets, 0 bytes

      30 second offered rate 0000 bps, drop rate 0000 bps

      Match: mpls experimental topmost 2

      Match: ip dscp cs2 (16)

          Bandwidth 20 (percent)

          Queue-limit current-queue-depth 0 bytes

              Output Queue:

                Tail Packets Drop: 0

                Tail Bytes Drop: 0

    Class-map: MPLS_MANAGEMENT (match-any) 

      0 packets, 0 bytes

      30 second offered rate 0000 bps, drop rate 0000 bps

      Match: mpls experimental topmost 1

      Match: ip dscp cs1 (8)

          Bandwidth 4 (percent)

          Queue-limit current-queue-depth 0 bytes

              Output Queue:

                Tail Packets Drop: 0

                Tail Bytes Drop: 0

    Class-map: class-default (match-any) 

      69 packets, 24528 bytes

      30 second offered rate 3000 bps, drop rate 0000 bps

      Match: any

          Bandwidth 30 (percent)

          Queue-limit current-queue-depth 0 bytes

              Output Queue:

                Tail Packets Drop: 0

                Tail Bytes Drop: 0

NEIGHBOR ROUTER 7609

sh policy-map inter gi 8/5

GigabitEthernet8/5

  Service-policy input: hvataj_exp_5

  Counters last updated 00:00:01 ago

    Class-map: match_exp_5 (match-any)

      0 packets, 0 bytes

      5 minute offered rate 0000 bps

      Match: mpls experimental topmost 5

    Class-map: hvataj_dscp_46 (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0000 bps

      Match:  dscp ef (46)

    Class-map: hvataj_dscp_0 (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0000 bps

      Match:  dscp default (0)

    Class-map: hvataj_cos_0 (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0000 bps

      Match: cos  0

    Class-map: match_exp_0 (match-all)

      17 packets, 1754 bytes

      5 minute offered rate 0000 bps

      Match: mpls experimental topmost 0

    Class-map: class-default (match-any)

      17 packets, 1880 bytes

      5 minute offered rate 0000 bps, drop rate 0000 bps

      Match: any

There must be a way to solve this one.

And thank you for your help. I really appreciate it.

[Vaibhava Varma]

Hismailmilak

Sorry but could not help to achieve a resolution yet. I did LAB a L2VPN with set mpls experimental imposition and it solved the above issue. Just using set mpls experimental topmost did not work for me either..

Hope someone else with an expertise can help us here :-)

Meanwhile I will keep thinking for this issue.

Regards

Varma

[Vaibhava Varma]

Hismailmilak

I did discuss on this more and here is what should be there in a nutshell for our case for the EXP5 Marking.

On the Ingress Interface side of ME3600 we apply a policy-map using default-class and set the mpls experimental imposition as 5 which would set the MPLS label 5 to the unlabelled frame arriving at the Ingress and would be passed transparently across SP Core as EXP5 only during all MPLS Label SWAP done in the Core.

I think we have already tried the "imposition" option and it does not works unfortunately so really not sure whats happening here when the Egress Interface of ME3600 shows EXP5 but the neighbouring router DM3's Ingress Interface connecting to ME3600's Egress shows no EXP5. When traffic is exiting out from ME3600's Egress already Label Swap would have happened and EXP5 would have been preserved.

Regards

Varma

[smailmilak]

Good news

I managed to match EXP 5 on the neighbor router, but problem is still not 100% solved.

Problem is this:

We have to use "imposition" instead of "topmost". You already said that

But  the neighbor router matches the EXP5 bit only if I delete the egress  policy map where I have LLQ and bandwidht percent in same policy-map.

policy-map MPLS_LLQ_WAN_ES20

class MPLS_VOICE

  police 150000000

  priority

class MPLS_CONTROL

  bandwidth percent 1

class MPLS_VIDEO

  bandwidth percent 30

class MPLS_CUSTOMER

  bandwidth percent 20

class MPLS_MANAGEMENT

  bandwidth percent 4

class class-default

  bandwidth percent 30

The  stupid thing is that I get an error message only when I first enter the  class maps with bandwidth percent and then the class map with priority  and policing.

"Strict priority or priority level cannot co-exist with bandwidth kbps/percent in any other class."

Documentation says this:

"Strict   priority cannot co-exist with bandwidth kbps/percent in any other   class. For strict priority, configure policer first and then configure   bandwidth on the same level classes."

I did this but the class map MPLS_VOICE with policing and priority defaults the EXP 5 to EXP 0!!!!! WHY??

When  I delete the MPLS_VOICE class and leave only the classes with bandwith  percent everything is ok, but there is no LLQ which is really needed for  voice traffic.

I found this open caveat

CSCtr65191

QoS: Exp value is reset to zero when the class has Policer configured.

Ingress Marking does not work if  packets are subjected to ingress  marking and egress policer, the  packet header is not modified according  to ingress marking action  configuration.

Workaround: None

[Vaibhava Varma]

Hismailmilak

Good that finaly whats happening is clear to us...

I tried to LAB the above Policy-Map on c7200 Platform and everything went as expected..set the exp5 at ingress of PE on PE-CE Link and see the same exp5 at ingress of P.on the PE-P link.

PE1#show policy-map interface Gi1/0

GigabitEthernet1/0

  Service-policy output: MPLS_LLQ_WAN_ES20

    queue stats for all priority classes:

      queue limit 64 packets

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts output/bytes output) 1247/169409

    Class-map: voice (match-all)

      1246 packets, 11416238 bytes

      5 minute offered rate 135000 bps, drop rate 0 bps

      Match: mpls experimental topmost 5

      police:

          cir 150000000 bps, bc 4687500 bytes

        conformed 1247 packets, 169409 bytes; actions:

          transmit

        exceeded 0 packets, 0 bytes; actions:

          drop

        conformed 4000 bps, exceed 0 bps

      Priority: Strict, burst bytes 1500, b/w exceed drops: 0

    Class-map: MPLS_CONTROL (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: mpls experimental topmost 4

      Queueing

      queue limit 64 packets

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts output/bytes output) 0/0

      bandwidth 1% (10000 kbps)

    Class-map: MPLS_VIDEO (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: mpls experimental topmost 2

      Queueing

      queue limit 64 packets

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts output/bytes output) 0/0

      bandwidth 30% (300000 kbps)

    Class-map: MPLS_CUSTOMER (match-all)

      96 packets, 7194 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: mpls experimental topmost 6

      Queueing

      queue limit 64 packets

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts output/bytes output) 96/7194

      bandwidth 20% (200000 kbps)

    Class-map: MPLS_MANAGEMENT (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: mpls experimental topmost 7

      Queueing

      queue limit 64 packets

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts output/bytes output) 0/0

      bandwidth 4% (40000 kbps)

    Class-map: class-default (match-any)

      243 packets, 72711 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

      Queueing

      queue limit 64 packets

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts output/bytes output) 243/20625

      bandwidth 30% (300000 kbps)

PE1#

P1#show policy-map interface Gi1/0

GigabitEthernet1/0

  Service-policy input: MATCH

    Class-map: EXP5 (match-all)

      1374 packets, 186872 bytes

      5 minute offered rate 3000 bps

      Match: mpls experimental topmost 5

    Class-map: EXP0 (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps

      Match: mpls experimental topmost 0

    Class-map: class-default (match-any)

      303 packets, 23794 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

P1#

Regards

Varma

[smailmilak]

Me again

I tried a few things today. First I read this in the config guide:

Configuring Marking

Use the set policy-map class configuration command to set or modify the attributes for traffic belonging to a specific class.

Follow these guidelines when configuring class-based marking:

•Hierarchical marking is not supported.

•You can only configure egress marking for classes on the third level of the policy map hierarchy.

First they say that hierarchical marking is not supported and then that it is supported only on the third level of policy map hierarchy.

I tried then with a three level hierarchy but I got an error when I wanted to attach it. I tried first to police in the Level 3 policy map, then I attached this policy-map to Level 2 where I remarked EXP 5 to EXP 5 and attached it to Level 1 policy-map where I shaped the traffic, but it did not work.

BUT I tried without policing, left only the priority command and used shaping on the other class maps:

policy-map TEST_EGRESS_SHAPE

class MPLS_VOICE

  priority

class MPLS_CONTROL

  shape average percent 1

class MPLS_VIDEO

  shape average percent 30

class MPLS_CUSTOMER

  shape average percent 20

class MPLS_MANAGEMENT

  shape average percent 4

class class-default

  shape average percent 30

Problem is that with shaping I can not get more bandwidth if there is no congestion and I am not sure about the function of the priority command.

This is what they say about the priority command:

Set the strict scheduling priority for this class.

Note Only one unique class map in an attached policy map can be associated with a priority command. You cannot configure priority along with any other queuing action (bandwidth or shape average).

So how much bandwidth will I get in the MPLS_VOICE class?

[Vaibhava Varma]

Hismailmilak

So now we are able to match the EXP5 being set on the ingress of ME3600 at the engress of DM3 using the above policy-map where we are using shaping ?

From my understanding with Shaping each traffic class have their own maximum BW fixed so looking at the above Policy-Map the fixed BW for the different classes is

1+30+20+4+30 = 85

and hence the left BW is 15 % which should be going to PQ traffic ie Voice. Did you try to set the BW % or BW argument with the priority command itself for MPLS_VOICE Class ?

Regards

Varma

[smailmilak]

Yes we are matching EXP 5 on DM3. But I don't know why I have to set EXP 5 in ingress. I was thinking that the DSCP 46 bit that we are sending )and matching on ingress) to the 3600X and forth should forwarded through the MPLS network as EXP 5 bit.

Unfortunately I cannot set BW with the prioritiy command. Only with combination of police BW and priority

(config-pmap-c)#priority ?

Yes, you are right with shaping, it's similar to policing but with one bucket more.

And you are probably right about the BW for 15% for PQ, but I wonder how I could set more bandwidth than 75% because usually the other 25% are reserved for routing protocols and similar and only with the command max-reserverd-bandwidth (which is not present on this switch) I can modify the BW precentage that I can use for class maps.

Really weird behaviour

and btw I have since yesterday an another problem. This is more a hardware issue

https://supportforums.cisco.com/message/3470787#3470787

Take a look if you have the time.

Thank you.

[Vaibhava Varma · Accepted solution]

Hismailmilak

We will need to explicitly mark the traffic at Ingress to EXP5 despite of the fact that the L2 Cos will be mapped to the L3 DSCP value if we are trusting the L2 cos on the ingress of ME 3600 using mls qos trust cos because I think here we are setting the DSCP to EF5 but the CoS is not being set to 5. if the L2 Frame which is originating from the Source has a L2 Cos of 5 we would have not needed to do explicit marking.

Unfortunately these are Platform related limitations for which sometimes workarounds are very hectic.

Hope that our assumption on the BW Share for the PQ is correct and we get the desired BW for Voice. What I think the BW distribution to the rest of the classes has to be made in accordance to after fulfilling the Voice Class requirement first per the required BW for the Voice Class.

I will sure take a look at the other issue and see what happened there.

We had a great discussion for this weird issue which has definitely given an oppurtunity to dive in depth on the QoS aspect and learn a lot of new things :-)

Regards

Varma

Note:Edited my Response posted 5 mins back as I did not think deeply for your question.

[smailmilak]

Yes, it was a great discussion and I learned a lot of new stuff about Cisco QoS.

I will try one more time with Hierarchical QoS, but it will probably not work.

Thank you very much for you help.

i wil of course grade you post.

[smailmilak]

Hi, I just want to inform you that this was a bug and Cisco is gonna release a new IOS on 30. Nov. where llq policing is working as it should.

Sent from Cisco Technical Support iPhone App