Preview Tool

Cisco Bug: CSCus32847 - te_control traceback on asr9k 5.1.1

Last Modified

Aug 04, 2018

Products (1)

  • Cisco ASR 9000 Series Aggregation Services Routers

Known Affected Releases


Description (partial)

As part of soft-preemption statistics we keep a running counter of the total amount of bandwidth used by LSPs that are currently in soft-preempted state. The counter is kept per TE interface. It can be queried with the following command.

RP/0/0/CPU0:R2#show mpls traffic-eng link-management soft-preemption interface gigabitEthernet 0/2/0/3
Wed Jul 13 10:32:38.230 EDT
Soft-preemption Global Information:
  State: Enabled
  Timeout Interval: 60 seconds (Default)

Name: GigabitEthernet0/2/0/3; IPv4 Address:
Total Soft Preempted Bandwidth (BC0/BC1) kbps: 30000/0
Currently Soft Preempted Bandwidth (BC0/BC1) kbps: 0/0
Released Soft Preempted Bandwidth (BC0/BC1) kbps: 30000/0
Currently Over-subscribed Bandwidth (BC0/BC1) kbps: 0/0
Currently Soft Preempted Tunnels: 0 tunnels

The only symptom seen with the issue is that the counter may show a slightly wrong value (off by only a few kbps) and when it gets to "zero" it may underflow causing the traceback. The counter is only used for show purposes so there is absolutely no side effects to it having a wrong value.

The error message reported is printed when we attempt to decrement the counter and the resulting value would be below zero.

RP/0/RP0/CPU0:Jul  7 12:37:43.207 PDT: te_control[1052]:%ROUTING-MPLS_TE-3-ERR_INTERNAL_CHECK : te_s2l_decrement_soft_preempt_bw():line 2625: Unable to decrement soft-preempted BC0 BW  : pkg/bin/te_control: (PID=651627) :  -Traceback= 424b4a0 424845d 427ce2a 43c6ec2 43c7132 43c7643 a10b445 a109518 4578d00 4579817 4200038

The counter is incremented when an LSP gets soft-preempted and is decremented when a soft-preempted LSP is torn down. The value of the increment and decrement is generally the BW this LSP is reserving. When two LSPs of the same tunnel get soft-preempted (ex: current and reopt LSP) we have to take account that these LSPs are sharing their reserved BW. Here is where we run into the issue. 

Per soft-preempted LSP we do the following regarding the counter:
1)	We do the BW sharing logic in BYTES/sec as admission is done in BYTES/sec
2)	 Convert the result in kbps
3)	increment/decrement the counter in kbps. 

Depending on which LSP get soft-preempted first we can hit a rounding error in step (2). In the traces I was seeing that we were trying to decrement this counter by 1 kbps too much.

Having a Juniper head-end exposes this issue. The RSVP path message contains the reserved BW value in bytes . In XR, TE head-ends have the limitation of signaling LSPs with BW in kbps multiples. We convert the LSP BW from kbps to bytes/sec only when creating the RSVP PATH message. So the value we signal, as a head-end, is always going to be a multiple of 125 (bytes per Kilobits). We'll never hit this issue with XR head-ends. It appears Juniper will signal BW as values more granular than kbps thus exposing the issue.
Bug details contain sensitive information and therefore require a account to be viewed.

Bug Details Include

  • Full Description (including symptoms, conditions and workarounds)
  • Status
  • Severity
  • Known Fixed Releases
  • Related Community Discussions
  • Number of Related Support Cases
Bug information is viewable for customers and partners who have a service contract. Registered users can view up to 200 bugs per month without a service contract.