QoS Classification/Marking Issue

Unanswered Question
Jun 9th, 2009

I have a rather infuriating issue that I can't seem to resolve. I have a 4-router setup in a lab:

R1-----R2-----R3-----R4

I have R3 and R4 configured to tag packets as IPP3 and IPP4, respectively, when they ping R1.

To test this, I have a policy-map on R2's ingress (right) interface that matches IPP3 and IPP4 in independent classes:

class-map match-all PREC4

match precedence 4

class-map match-all PREC3

match precedence 3

policy-map queuing

class PREC4

(drop)

class PREC3

(drop)

I place "drop" in parentheses because I'm adding/removing them as needed to test. So if I remove one class, say class PREC3, and have PREC4 drop IPP4 packets, R4 cannot ping R1 (as expected). If I then add class PREC3, and have it drop IPP3 packets, R3 cannot ping R1 (also as expected).

Here's the problem - if I apply "no drop" to one of the classes (either PREC3 or PREC4), both R3 and R4 can ping R1. This is in spite of the fact that the other class still has "drop" configured. Why would this be the case? If I configure "drop" again, neither router can ping.

Next - I can reset all this by configuring both classes for "no drop". Then I can apply "drop" to either class and make the appropriate router stop pinging, and even make both drop pinging by applying "drop" to both classes. But if both are configured for drop, and I configure "no drop" on either one of the classes, both routers are able to ping.

By the way, if anyone has any good show commands or debugs that will tell me how packets are being tagged, that would be wonderful. The fact that the policy-map drops specific packets tells me that the tagging is working, but I wouldn't mind seeing that for myself.

Thanks!

Jeff

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Jon Marshall Tue, 06/09/2009 - 06:36

Jeff

Could you post configs of R3 & R4 and explain how you are tagging the traffic on these routers.

Jon

jeff.kish Tue, 06/09/2009 - 06:46

Hi Jon,

Sure thing. Here's R2, R3, and R4.

I'm tagging R4's packets by tagging all packets exiting its fa0/0 interface. I'm tagging R3's packets by matching only ICMP packets with its l0 source address exiting its fa0/1 interface. EIGRP is used to make all routers aware of each others' loopbacks.

I'd appreciate anything you have to offer. Again, are there any good debug commands that will show a packet's markings? I was surprised to see that "debug ip packet detail" doesn't show QoS taggings.

If it helps:

R2 (fa0/1) ---- (fa0/1) R3 (fa0/0) ---- (fa0/0) R4

Attachment: 
Jon Marshall Tue, 06/09/2009 - 07:31

Jeff

I have just replicated this using dynamips and it works as expected for me ie. i can configure both to drop and then change one of them to "no Changing the vlan interface on a L3 switch should be possible remotely ie.

When you run the ping on R3 are you setting the source IP to be the loopback address ie. 3.3.3.3

Jon

jeff.kish Tue, 06/09/2009 - 07:42

I think some clipboard data got pasted into your post, but I got the message. :) Yes, I'm doing extended pings from the loopback address 3.3.3.3/4.4.4.4. As best I can tell, the tagging works fine because when I initially configure the policy-map to "drop", the pings stop. It's just the bizarre issue of allowing both to ping when I do "no drop" on either one of them.

I played with it a bit more, and the symptoms are the same whether I tag the R4 packets on R4 or R3. I suspect the issue is on R2.

Thanks for going to the trouble of replicating the setup. Maybe this is just an IOS bug? I have a 3600 so let me try replacing R2 with that and giving that a try.

Do you know of any debug commands that will show me the taggings on packets as they enter/exit an interface?

jeff.kish Tue, 06/09/2009 - 07:58

Unfortunately, I just pasted my R2 config onto a 3600, and I get the same symptoms. What a strange issue.

Jon, did you paste my configs directly into Dynamips, or did you configure it yourself? I just wonder if I'm misconfiguring something, somehow.

Here's what I see:

policy-map queuing

class PREC4

drop

class PREC3

drop

(R3 and R4 have continuous pings to R1, pings are blocked)

R2#conf t

Enter configuration commands, one per line. End with CNTL/Z.

R2(config)#policy-map queuing

R2(config-pmap)#class PREC4

R2(config-pmap-c)#no drop (both start pinging)

R2(config-pmap-c)#drop (both stop pinging)

R2(config-pmap-c)#class PREC3

R2(config-pmap-c)#no drop (both start pinging)

R2(config-pmap-c)#drop (both stop pinging)

However, if I start with them both in "no drop" and successfully pinging...

R2(config)#policy-map queuing

R2(config-pmap)#class PREC3

R2(config-pmap-c)#drop (R3 stops pinging)

R2(config-pmap-c)#no drop (R3 starts pinging)

R2(config-pmap)#class PREC4

R2(config-pmap-c)#drop (R4 stops pinging)

R2(config-pmap-c)#no drop (R4 starts pinging)

Jon Marshall Tue, 06/09/2009 - 07:59

Jeff

Yes some clipboard data did get added - removed now :-)

"Do you know of any debug commands that will show me the taggings on packets as they enter/exit an interface?"

No unfortunately. When i'm doing QOS i usually use an end host with wireshark and span ports out from the switches.

I simply modified the policy-map but have you tried removing the service-policy and then reapplying ?

Jon

jeff.kish Tue, 06/09/2009 - 08:05

I've removed/readded it, but here's a question - how does IOS handle policy-maps if I'm editing them while in use? When I configure "no drop" while actively using the policy-map to drop pings for both IPPs, does it somehow remove the policy-map from the interface?

Maybe my entire problem is that I'm not removing the policy-map from the interface before editing it. Were you removing it before editing it in Dynampis, Jon? What do you get if you change the policy-map while it's in use?

jeff.kish Tue, 06/09/2009 - 08:09

Okay, if I perform "no drop" on one of the classes while in use, both routers are able to ping. But if I then remove the policy-map from the interface and re-add it without changing anything, only the appropriate router can ping. The one that wasn't configured for "no drop" cannot ping.

Again, I guess you can't edit a policy-map in use? At least, not with predictable results?

Jon Marshall Tue, 06/09/2009 - 08:27

Jeff

"Were you removing it before editing it in Dynampis, Jon?"

No i wasn't and i have just retested with continuous pings and my results were as expected ie.

1) Configure both to drop

2) Start pings - obviously no success from either router

3) configure PREC4 not to drop - PREC4 packets get through but PREC3 packets still dropped.

4) Configure PREC4 to drop and PREC3 not to drop. As you would expect PREC4 packets blocked but PREC3 getting through.

All the above done without removing service-policy from interface. Reason i asked you to try removing it was that it seemed to ring a bell with me that you may need to remove and then reapply. Perhaps it is a difference in IOS.

What IOS are you running ?

Jon

jeff.kish Tue, 06/09/2009 - 08:37

12.3(26) for the 2651, 12.2(15)T14 for the 3640. Maybe it's the older Cisco hardware?

Actions

This Discussion