Guest

Preview Tool

Cisco Bug: CSCtc68342 - BNA Devices sending SABME cause DLSw FST High CPU after interface drop.

Last Modified

Jan 29, 2017

Products (7)

  • Cisco IOS
  • Cisco 7301 Router
  • Cisco 7206 Router
  • Cisco 7206VXR Router
  • Cisco 7204 Router
  • Cisco 7202 Router
  • Cisco 7204VXR Router

Known Affected Releases

12.3(12e)

Description (partial)

Symptom:
<p>High CPU in DLSw message proc when interface is shut down or lost when
connecting BNA devices over DLSW FST peers.<p>

Conditions:
<p>The environment consists of DLSW FST connections meshed in a rectangle
configuration. The BNA (Burrows Network Architecture) hosts are connecting over
these links.  The reason for FST is that these hosts start sessions by  sending
in SABME requests (and usually quite a lot of them) every 2 seconds.
   
  <p>This environment was brought up in production and was working okay until
there was a test scenario performed where a WAN interface was taken down to
simulate an outage.  All DLSw routers experienced high CPU with one in
particular being hit harder than others.  What the customer noted was that the
DLSW peer did not go down, but remained connected.  It appears when the outage
occurred, the hosts started sending in SABMEs for each mac address it has in
its list every 2 seconds (there are over 200 hosts in the production network).
  To recover, the LAN, the interfaces that the hosts were connected to had to
be shut down.  After a period of time the CPU utilization went down, and the
DLSw peer status changed to DISCONN.  When the LAN interfaces were brought back
up, the router was able to handle the input and did not experience the high cpu
utilization again (with the remote peer down).  
   
  <p>It seems the Keepalive process never gets invoked as the rapid rate of
incoming SABMEs appears as data to be sent by DLSw.  Since FST is IP, we just
keep sending the data (no acknowledgment) and the BNA hosts just keep on
sending as well, driving up the cpu utilization and not allowing Keepalive
processing to bring the DLSw peer connection down.
   
  <p>Another recovery scenario was to remove the DLSw config from the most
affected router.  DLSW DISABLE was not attempted, but could be an additional
recovery method. <p>
Bug details contain sensitive information and therefore require a Cisco.com 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.