01-13-2019 11:18 PM
Dear all,
I have a case as below.
RP/0/RP0/CPU0:CRS16.01#show running-config policy-map QUEUING_TO_PE
Mon Jan 14 00:46:59.623 HANOI
policy-map QUEUING_TO_PE
class PQ1
priority level 1
police rate percent 100
!
!
class PQ2
priority level 2
police rate percent 100
!
!
class WFQ4
bandwidth percent 33
!
class WFQ3
bandwidth percent 26
!
class WFQ2
bandwidth percent 20
!
class WFQ1
bandwidth percent 13
!
class class-default
bandwidth percent 8
random-detect discard-class 0 60 ms 100 ms
!
end-policy-map
!
RP/0/RP0/CPU0:CRS16.01#configure terminal
Mon Jan 14 00:42:29.384 HANOI
RP/0/RP0/CPU0:CRS16.01(config)#interface bundle-ether 25
RP/0/RP0/CPU0:CRS16.01(config-if)#no service-policy output
RP/0/RP0/CPU0:CRS16.01(config-if)#service-policy output QUEUING_TO_PE
RP/0/RP0/CPU0:CRS16.01(config-if)#commit
Mon Jan 14 00:43:36.641 HANOI
% Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. Please issue 'show configuration failed [inheritance]' from this session to view the errors
RP/0/RP0/CPU0:NTH9205CRT01.CKV.CRS16.01(config-if)#show configuration failed [inheritance]
Mon Jan 14 00:43:47.840 HANOI
!! SEMANTIC ERRORS: This configuration was rejected by
!! the system due to semantic errors. The individual
!! errors with each failed configuration command can be
!! found below.
interface Bundle-Ether25
service-policy output QUEUING_TO_PE
!!% 'qos_ea' detected the 'fatal' condition 'qos policy is not supported'
!
end
But when I've configured under another bundle interface (BE31), it has been permitted.
RP/0/RP0/CPU0:CRS16.01#configure terminal
RP/0/RP0/CPU0:CRS16.01(config)#interface Bundle-Ether31
RP/0/RP0/CPU0:CRS16.01(config-if)#no service-policy output
RP/0/RP0/CPU0:CRS16.01(config-if)#service-policy output QUEUING_TO_PE
RP/0/RP0/CPU0:CRS16.01(config-if)#commit
RP/0/RP0/CPU0:CRS16.01(config-if)#
I figure out the interface member of BE35 belong to FP-140, instead of 40x10Ge as BE31.
Bundle-Ether31 is up, line protocol is up
  Interface state transitions: 1
  Hardware is Aggregated Ethernet interface(s), address is b0aa.77ba.8018
     No. of members in this bundle: 2
      TenGigE0/0/0/31              Full-duplex  10000Mb/s    Active          
      TenGigE0/0/0/38              Full-duplex  10000Mb/s    Active      
Bundle-Ether25 is up, line protocol is up
  Interface state transitions: 1
     No. of members in this bundle: 4
      TenGigE0/6/0/0               Full-duplex  10000Mb/s    Active          
      TenGigE0/6/0/1               Full-duplex  10000Mb/s    Active          
      TenGigE0/6/0/2               Full-duplex  10000Mb/s    Active          
      TenGigE0/6/0/3               Full-duplex  10000Mb/s    Active         
RP/0/RP0/CPU0:CRS16.01#admin show platform
Mon Jan 14 08:15:45.139 HANOI
Node          Type              PLIM               State           Config State
------------- ----------------- ------------------ --------------- ---------------
0/0/CPU0      LSP-X             40-10GbE           IOS XR RUN      PWR,NSHUT,MON
0/5/CPU0      LSP-X             4-100GbE           IOS XR RUN      PWR,NSHUT,MON
0/6/CPU0      FP-140G           14-10GbE           IOS XR RUN      PWR,NSHUT,MON
0/8/CPU0      FP-140G           14-10GbE           IOS XR RUN      PWR,NSHUT,MON
0/9/CPU0      LSP-X             4-100GbE           IOS XR RUN      PWR,NSHUT,MON
0/10/CPU0     LSP-X             4-100GbE           IOS XR RUN      PWR,NSHUT,MON
0/RP0/CPU0    RP(Active)        N/A                IOS XR RUN      PWR,NSHUT,MON
0/RP1/CPU0    RP(Standby)       N/A                IOS XR RUN      PWR,NSHUT,MON
Does the FP-140G affect to the QoS configuration? Please let me know it any documentation or advice for me.
Thank in advance.
01-14-2019 06:52 AM
Can we try reducing the policer to less than 100% and try to apply it to the FP140 card?
01-14-2019 06:18 PM
Dear guy,
We applied the policer with the total bandwidth of PQ1 and PQ2 queues was less than 100% as below.
policy-map QUEUING_TO_PE
class PQ1
  priority level 1
  police rate percent 29
  !
 !
 class PQ2
  priority level 2
  police rate percent 70
  !
But now we want to expand the bandwidth limitation for PQ1 and PQ2 queues up to 100% as the supporting IOS XR 6.1.4.
01-15-2019 06:54 AM
The total policer needs to be below 100% for that card combination
01-16-2019 08:50 PM
Thanks for your response. I've submitted this case to Cisco TAC for supporting.
01-14-2019 07:01 AM
There is limited QoS support on FP vs LSP-X cards.
I am not sure if multiple priority queues are supported on FP-140 cards.
01-14-2019 06:10 PM
Dear Mimtiaz,
We can apply the multiple priority queues as the previous policy-map. But the total bandwidth is less than 100% for both PQ1 and PQ2 queues.
RP/0/RP0/CPU0:CRS16.01#show running-config policy-map QUEUING_TO_PE
Mon Jan 14 00:46:59.623 HANOI
policy-map QUEUING_TO_PE
class PQ1
  priority level 1
  police rate percent 29
  !
 !
 class PQ2
  priority level 2
  police rate percent 70
  !
 !
 class WFQ4
  bandwidth percent 33
 !
 class WFQ3
  bandwidth percent 26
 !
 class WFQ2
  bandwidth percent 20
 !
 class WFQ1
  bandwidth percent 13
 !
 class class-default
  bandwidth percent 8
  random-detect discard-class 0 60 ms 100 ms
 !
 end-policy-map
 
					
				
				
			
		
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide