Cisco 4451 QoS on sub Port-Channel in suspended mode

[Joshua Head]

Hi I have deployed the following policy to a 4451 router;

policy-map QOS-dcsp#QUEUING_OUT
class QOS_8C#VOICE
priority
police rate percent 15
class QOS_8C#CONTROL-PLANE
bandwidth remaining percent 3
fair-queue
class QOS_8C#MULTIMEDIA-CONFERENCING
bandwidth remaining percent 40
fair-queue
random-detect dscp-based
class QOS_8C#MULTIMEDIA-STREAMING
bandwidth remaining percent 25
fair-queue
random-detect dscp-based
class QOS_8C#TRANSACTIONAL-DATA
bandwidth remaining percent 14
fair-queue
random-detect dscp-based
class QOS_8C#BULK-DATA
bandwidth remaining percent 9
fair-queue
random-detect dscp-based
class QOS_8C#SCAVENGER
bandwidth remaining percent 1
class class-default
bandwidth remaining percent 7
fair-queue
random-detect dscp-based

!

policy-map QOS-dcsp#QUEUING_OUT#SHAPE#500M#
class class-default
shape average 500MB
service-policy QOS-dcsp#QUEUING_OUT
!
policy-map QOS-dcsp#QUEUING_OUT#SHAPE#50M#
class class-default
shape average 50MB
service-policy QOS-dcsp#QUEUING_OUT

However the port-channel sub interfaces are giving the following error;

ROUTER(config-subif)#do show policy-map interface Port-channel5.1

Port-channel5.1

Service-policy input: QOS-MARKING_IN

Service policy QOS-MARKING_IN is in suspended mode

Service-policy output: QOS-dcsp#QUEUING_OUT#SHAPE#500M# is in suspended mode

I have read on various posts that this is due to port-channel load-balancing not being enabled, which it is not at present as this port-channel contains different networks sort of like a router-on-a-stick. Would there be any impact of enabling the port-channel load-balance manual and leaving it as default behavior on network traffic?

[Joseph W. Doherty]

Might be helpful if you would post the QOS-MARKING_IN service policy.

[Joshua Head]

Hi Joseph,

Please see below;

policy-map QOS-MARKING_IN
class QOS-MARKING_IN#VOICE
set dscp ef
class QOS-MARKING_IN#MM_CONF
set dscp af41
class QOS-MARKING_IN#MM_STREAM
set dscp af31
class QOS-MARKING_IN#CONTROL
set dscp cs6
class QOS-MARKING_IN#SIGNALING
set dscp cs3
class QOS-MARKING_IN#OAM
set dscp cs2
class QOS-MARKING_IN#TRANS_DATA
set dscp af21
class QOS-MARKING_IN#BULK_DATA
set dscp af11
class QOS-MARKING_IN#SCAVENGER
set dscp cs1
class class-default
set dscp default

[Joseph W. Doherty]

Thank you Joshua, since the error appears be with the ingress policy, I just wanted to insure your ingress policy didn't use any egress commands, and it doesn't appear to.

Additional questions:

Could you post all the class-maps that apply to both ingress and egress policies?

Could you post the actual interface configs, both port channel and underlying physical interfaces being used by port channel?

BTW, as an aside . . .

I generally recommend against using WRED, at all, unless one is a QoS expert, as it is surprisingly difficult to "get right".  Further, in your case, you're mixing FQ and WRED.  A (very/generally) "bad" combo, IMO.

Also, it seems you're using much of a "text book" QoS model, but in my experience, when you have a device that support FQ, you can eliminate many CBWFQ classes.

Lastly, if your 4451 supports 2nd tier PQ (LLQ), you might consider using real-time video for it.

[Joshua Head]

Hi Jospeh,

Thanks again for your response, a quick aside it looks like some of the message was cut off, it is both policies not just the inbound.

You are completely correct that this is a fairly text-book policy, it's adapted from Cisco 8 class queuing policy, I decided against using the second priority queue as there is no real-time video traffic going over these devices. I've noted your comments on the WRED and FQ, I will investigate that further to see whether they need removing or thresholds adjusting.

Further configuration requested is below;

Class-Maps

class-map match-any QOS-MARKING_IN#MM_STREAM
match access-group name ACL_QOS_IN#MM_STREAM__acl
class-map match-any QOS-MARKING_IN#OAM
match access-group name ACL_QOS_IN#OAM__acl
class-map match-any QOS-MARKING_IN#SIGNALING
match access-group name ACL_QOS_IN#SIGNALING__acl
class-map match-any QOS-MARKING_IN#BULK_DATA
match access-group name ACL_QOS_IN#BULK_DATA__acl
class-map match-any QOS-MARKING_IN#SCAVENGER
match access-group name ACL_QOS_IN#SCAVENGER__acl
class-map match-any QOS-MARKING_IN#MM_CONF
match access-group name ACL_QOS_IN#MM_CONF__acl
class-map match-any QOS_8C#SCAVENGER
match dscp cs1
class-map match-any QOS-MARKING_IN#VOICE
match access-group name ACL_QOS_IN#VOICE__acl
class-map match-any QOS_8C#VOICE
match dscp ef
class-map match-any QOS_8C#MULTIMEDIA-STREAMING
match dscp af32
match dscp af33
match dscp af31
match dscp cs3
class-map match-any QOS_8C#TRANSACTIONAL-DATA
match dscp af23
match dscp af21
match dscp af22
match dscp cs2
class-map match-any QOS-MARKING_IN#TUNNELED
match access-group name ACL_QOS_IN#TUNNELED__acl
class-map match-any QOS-MARKING_IN#TRANS_DATA
match access-group name ACL_QOS_IN#TRANS_DATA__acl
class-map match-any QOS_8C#BULK-DATA
match dscp af12
match dscp af13
match dscp af11
class-map match-any QOS_8C#MULTIMEDIA-CONFERENCING
match dscp af43
match dscp af41
match dscp af42
match dscp cs4
class-map match-any QOS_8C#CONTROL-PLANE
match dscp cs7
match dscp cs6

Port-Channel

interface Port-channel1
description Port Channel to Switch
no ip address
no negotiation auto
!
interface Port-channel1.100
description Cloud
encapsulation dot1Q 100
ip vrf forwarding cloud traffic
ip address 255.255.255.254
ip nat outside
ip virtual-reassembly
!
interface Port-channel1.110
encapsulation dot1Q 110
ip vrf forwarding cloud traffic
ip address 255.255.255.248
!
interface Port-channel1.120
encapsulation dot1Q 120
ip vrf forwarding cloud traffic
ip address 255.255.255.252
!
interface Port-channel1.130
encapsulation dot1Q 130
ip vrf forwarding cloud traffic
ip address 255.255.255.252
!
interface Port-channel1.140
encapsulation dot1Q 140
ip vrf forwarding cloud traffic
ip address 255.255.255.252
!
interface Port-channel1.150
encapsulation dot1Q 150
ip vrf forwarding cloud traffic
ip address 255.255.255.252
!
interface Port-channel1.1000
description Firewall
encapsulation dot1Q 1000
ip vrf forwarding cloud traffic
ip address 255.255.255.240
standby 10 ip
standby 10 priority 250
standby 10 preempt delay minimum 30
!
interface Port-channel1.1001
description Firewall
encapsulation dot1Q 1001
ip vrf forwarding cloud traffic
ip address 255.255.255.240
standby 2 ip
standby 2 priority 250
standby 2 preempt delay minimum 30
!
interface Port-channel1.1002
description Firewall
encapsulation dot1Q 1002
ip vrf forwarding cloud traffic
ip address 255.255.255.240
standby 2 ip
standby 2 priority 250
standby 2 preempt delay minimum 30
!
interface Port-channel1.1003
encapsulation dot1Q 1003
ip vrf forwarding cloud traffic
ip address
ip nat inside
!
interface Port-channel1.1004
encapsulation dot1Q 1004
ip vrf forwarding cloud traffic
ip address
ip nat inside
ip ospf cost 1
!
interface GigabitEthernet0/0/0
description Connection to Switch
no ip address
negotiation auto
channel-group 1 mode active
!
interface GigabitEthernet0/0/1
description Connection to Switch
no ip address
negotiation auto
channel-group 1 mode active
!
interface GigabitEthernet0/0/2
description Connection to Switch
no ip address
negotiation auto
channel-group 1 mode active

[Joseph W. Doherty]

I might be blind, but don't see service policies on any interfaces?

If so, service policies being rejected when you try to apply?

[Joshua Head]

Removed them since it didn't work, I've been doing plenty of reading. It looks to me like the platform qos aggregate command needs to be applied before the port-channels are added. So they will need to be re-created. It does look like that command brings its own nuances though.

[Joseph W. Doherty]

Laugh - over the years, I've seen port-channels, and their attached links, rather quirky (i.e. varies between IOS versions and/or platforms), in that where commands must be applied, and the order they need be applied, can very much impact whether the device will process them correctly.  (Generally, over time [i.e. with later IOSs or devices], you need to configure the physical Etherchannel ports less than the port channel.)

The good news, usually, is, when you hit upon the magic implementation sequence, it continues to function correctly.

In other words, yup try re-creating.  So far, I haven't seen any glaring errors with the commands I believe you wish to apply.

[Joshua Head]

Yep! That's exactly how I had first configured it, and it looks like it is working fine but when I did a pcap on a device downstream I noticed the packets had absolutely NO markings at all! Looks like it's changed in XE so let's see if doing this fixes the problem. Thanks for having a look.

[marce1000]

 - You may find this document informational : https://community.cisco.com/t5/networking-documents/suspended-qos-state-on-asr1000/tac-p/3159827

 M.