cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
561
Views
0
Helpful
0
Replies

Egress QoS configuration on Etherchannel

j.hoffmann
Level 1
Level 1

ASR903 / RSP3 / IOS-XE 03.18.05.SP.156-2.SP5-ext

 

Hi community members,

I have a problem as follows.

 

On a "normal" physical 10GE interface I have configured a parent egress policy which traffic-classes matching
on different service instances.
I achieve an egress shaping per service instance with an average shape placed in each traffic class of the parent policy.
Additionally, I have a child policy inside each parent policy traffic class.
The child policy performs the task of class-based egress queuing and maps qos-groups to CoS values for the proper
CoS marking of outgoing traffic.

 

policy-map CHILD_EGRESS_PROFIL-1
class QOS-GROUP5
priority percent 10
set cos 5
class QOS-GROUP4
set cos 4
bandwidth remaining ratio 4
class QOS-GROUP2
set cos 2
bandwidth remaining ratio 3
class QOS-GROUP1
set cos 1
bandwidth remaining ratio 2


policy-map PARENT
class ServiceInstance_10
shape average [provisioned upstream bandwidth]
service-policy CHILD_EGRESS_PROFIL-1
class ServiceInstance_20
shape average [provisioned upstream bandwidth]
service-policy CHILD_EGRESS_PROFIL-1


interface TenGigabitEthernet0/5/1
no ip address
service-policy output PARENT

service instance 10 ethernet
encapsulation dot1q 10
rewrite ingress tag pop 1 symmetric
bridge-domain 10
!
service instance 20 ethernet
encapsulation dot1q 20
rewrite ingress tag pop 1 symmetric
bridge-domain 20

 

All the configuration above shows the expected proper function.

But now it is necessary to change the configuration using an etherchannel and the physical interface will be the first memberlink of the channel.

If I move the configuration to the new Interface Po1, I get the following error message:

ASR903(config-if)#service-policy output PARENT
No queueing actions are allowed on port-channel main interface and port-channel EVC/TEFP

Having regard to the IOS-XE documentation, this behaviour was foreseeable.
The shaping-, bandwidth- and priority-commands which I've used are only applicable for the physical memberlinks of an etherchannel.

But I guessed that a match on service instances is not possible on the level of the memberlinks, because the service instances are configured on the etherchannel "one level higher".

A test to configure the parent policy on the memberlink of the etherchannel leads to the following error message (as confirmation of my guess):

ASR903(config-if)#service-policy output PARENT
Qos : Policy-map with service instance match on PC member link is not allowed

It would be great if anybody in the community could give me a helpful hint to solve my problem!

Thanks in advance!

Jens

 

0 Replies 0
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: