QoS on the GigaEthernet of the 7200VXR-NPEG1

[luis.rueda]

While applying qos to NPE-G1 GigaEthernet intefaces I noticed that everytime I apply CBWFQ or LLQ to an output QoS technique on the subinterfaces of the gigaethernet link of the 7200VXR-NPE-G1, the interface resets!! Is this the regular behaviour ? I'm running IOS 12.0(30)S5 SERVICE PROVIDER.... any help would be appreciated.

Regards,

Luis

[balajitvk]

Hi Luis,

U mentioned it as interface resets - Whether line status is going down and up or the interface counter value gets reseted???? If possible could u provide interface config and its status before and after applying CBWFQ.

Rgds,

[luis.rueda]

Hi All,

Sure, interface reset counters increment, and interface goes Down and then up, I'm providing full configuration, ip addresses will be omitted of course.

interface GigabitEthernet0/3

bandwidth 32768

ip address XXX.XXX.XXX.XXX 255.255.255.252

no ip directed-broadcast

duplex full

speed 100

media-type rj45

no negotiation auto

mpls label protocol ldp

tag-switching mtu 2018

tag-switching ip

no cdp enable

7206VXR-NPE-G1#sh int gi0/3 | inc interface

Last clearing of "show interface" counters 00:02:13

0 output errors, 0 collisions, 0 interface resets

class-map match-any QoS-MPLS-CD

match mpls experimental 2

match mpls experimental 3

class-map match-any QoS-MPLS-BE

match mpls experimental 0

match mpls experimental 1

class-map match-any QoS-MPLS-RT

match mpls experimental 5

match mpls experimental 7

!

!

policy-map QoS-MPLS-Core

class QoS-MPLS-CD

bandwidth percent 40

fair-queue

random-detect dscp-based

class QoS-MPLS-BE

bandwidth percent 24

fair-queue

random-detect dscp-based

class QoS-MPLS-RT

priority percent 35

7206VXR-NPE-G1(config)#int gi0/3

7206VXR-NPE-G1(config-if)#do term mon

7206VXR-NPE-G1(config-if)#service-policy output QoS-MPLS-Core

7206VXR-NPE-G1(config-if)#

000120: Apr 13 12:26:05.443: %OSPF-5-ADJCHG: Process 1, Nbr XXX.XXX.XXX.XXX on GigabitEthernet0/3 from FULL to DOWN, Neighbor Down: Interface down or detached

000121: Apr 13 12:26:05.475: %LDP-5-NBRCHG: LDP Neighbor XXX.XXX.XXX.XXX:0 is DOWN (Interface not operational)

000122: Apr 13 12:26:06.443: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/3, changed state to down

7206-COBOG-CL72-II(config-if)#

000123: Apr 13 12:26:07.919: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/3, changed state to up

7206VXR-NPE-G1(config-if)#

000124: Apr 13 12:26:13.779: %OSPF-5-ADJCHG: Process 1, Nbr XXX.XXX.XXX.XXX on GigabitEthernet0/3 from LOADING to FULL, Loading Done

7206VXR-NPE-G1(config-if)#

000125: Apr 13 12:26:21.299: %LDP-5-NBRCHG: LDP Neighbor XXX.XXX.XXX.XXX:0 is UP

7206VXR-NPE-G1(config-if)#end

7206VXR-NPE-G1#sh int gi0/3 | inc interface

000126: Apr 13 12:26:33.935: %SYS-5-CONFIG_I: Configured from console by lrueda on vty0 (XXX.XXX.XXX.XXX)

7206VXR-NPE-G1#sh int gi0/3 | inc interface

Last clearing of "show interface" counters 00:04:00

1 output errors, 0 collisions, 6 interface resets

As you may see here, the LLQ is applyied and everything works normally after it, but the main issue is that the interface resets, OSPF, adjacencies reset and LDP also resets. If I do that on a FastEthernet address on the I/O card that doesn't happen. The main problem is when I apply CBWFQ or LLQ to subinterfaces for client access, since they reset the whole interface and every client drops.....

Regards,

Luis

[globalnettech]

Hello Luis,

I am not sure how much you can test with your configuration, since you apparently have live customers that are affected, but I wonder if the problem might be related to the fact that you are effectively putting 99% of the bandwidth in the classes, leaving only 1% for control traffic; OSPF might not like that, you could try and reserve a lower percentage and leave more for control traffic (e.g. reserve 75%).

Saludos,

GNT

[luis.rueda]

Hello,

Actually I have a couple of 7200VXR-NPE-G1 which I haven't installed, but certainly if I apply the same QoS Technique to a FastEthernet interface on the same router, the interface won't reset. But still, I tried reserving less than 75% but the problem is still the same, I forgot to mention this earlier, but I have 10 equipment like this one, and the problem happens in all 10 of them.

Thanks,

Luis

[globalnettech]

Hola Luis,

I did a bug search, but that came up empty. Does the subinterface let you apply the policy at all ? Is there anything displayed on your console such as ´output policy not supported´?

Saludos,

GNT

[globalnettech]

Hello,

try to disable keepalives on the interface (no keepalive), and check if that makes a difference. One other thing I noticed is that you specified ´bandwidth 32xxx´ on your interface, which means that your QoS bandwidth reservations are going to be based on those 32MB, is that what you want ?

Regards,

GNT

[luis.rueda]

Hi there,

Tried the no keepalive thing, and even though the interface won't go down and the Up, the ospf adjacencies do. regarding the Bandwidth, that is correct, actually this is a Link from one 7200 to another 7200 through a LAN radio Link that can go up to 32mbps, but still I tried this connecting a computer directly to the router, and it is still the same thing.

Thanks,

Luis

[mheusinger]

Hello,

when you have only 32 MB available, I would strongly recommend a nested policy. CBWFQ or LLQ will only kick in, when your physical interface is overloaded, i.e. when you are sending more than 100 MB. So you need to shape all traffic to the 32 MB and then use another policy-map to distribute those 32 MB among your traffic classes.

An example config would look like this:

policy-map shape32

class class-default

shape 32000000

service-policy output QoS-MPLS-Core

interface GigabitEthernet0/3

bandwidth 32768

service-policy output shape32

Make sure you leave some extra room for Layer2 keepalives, LDP, OSPF, etc.

This does not directly address your problem, but maybe you are lucky and the proper config for your environment does not reset the interface.

Hope this helps! Please rate all posts.

Regards, Martin

[luis.rueda]

Martin,

Thanks for your tip, I'll keep it in mind, finally a case was opened for this issue, and TAC pointed out to me the following bug CSCed28579 which by the way is as cisco says "the expected behaviour", I do not really agree with this because if it's for a trunk, then everything will be fine (i.e you change the MPLS trunks QoS every once in a while), but the same thing happens for subinterfaces on which I have more that 200 customers, imagine reseting 200 customers just so you may apply LLQ for a single one!!

Regards,

Luis