Release Notes for Cisco IOS Release 15.5(3)M
The following release notes support Cisco IOS Releases 15.5(3)M and higher releases. These releases support the Cisco 5900 Embedded Services Routers (ESR) platforms. These release notes are updated to describe new features, limitations, troubleshooting, recommended configurations, caveats, and how to obtain support and documentation.
Image Information and Supported Platforms
Note You must have a Cisco.com account to download the software.
Cisco IOS Release 15.5(3)M includes the following Cisco IOS images:
Note Please see the 5921 Enterprise Based Image information under New Features Supported.
New Features Supported
5921 Enterprise Based Image
Starting with the 15.5(3)M release, a new Enterprise Based image will be available for the 5921 ESR. The feature set provides core routing functionality but removes the advanced IP Security features (IPSec, VPN), Unified Call Manager, WAAS, and IP Mobility from the 5921 Advanced feature set. It will support three throughputs with Smart Licensing mode including 10, 25, and 50MB.
The image label is c5921i86-entbasek9-tar.SPA.155-3.M.
Note The CSL license is not supported in 15.5(3)M enterprise based image. The enterprise based image supports both node-lock-machine and node-lock-storage license schemes.
DLEP Version 7
The 5900 series Embedded Routers support Dynamic Link Exchange Protocol (DLEP) version7 with Cisco IOS Release 15.5(3)M. Understanding and Configuring DLEP information can be found here:
Background information about DLEP can be found here:
End User Interface
The CLI has some differences noted below:
[no] ip dlep vtemplate <number> [port <nnnnn>] [version <v1.5> or <v1.7>] [tcp port <nnnn>]
- The default UDP port is 55555 and the default TCP port is 55556
- The default value for version is 0 (DLEP1.0)
- TCP port applies only for DLEPv1.5 or v1.7
- Interface can be configured either for DLEPv1.0, DLEPv1.5, or DLEPv1.7
[no] ip dlep heartbeat-threshold <n>
- This CLI is not applicable for DLEPv1.5 or DLEPv1.7
- The default heartbeat threshold value for DLEPv1.5 and DLEPv1.7 is 2 seconds
Commands common to DLEPv5 and DLEPv7:
[no] ip dlep neighbor-down-ack-timeout <nnnn>
[no] ip dlep peer-terminate-ack-timeout <nnnn>
show dlep client [interface]
show dlep neighbor [interface]
show dlep counters [interface]
show dlep config [interface]
clear dlep client [interface] [<peer ID>]
clear dlep neighbor [interface] [<session ID>]
clear dlep counters [<Interface>]
The Cisco 5921 ESR has the following limitation:
With the 5921 ESR, several situations have been encountered in which the e1000e Ethernet driver strips VLAN tags before a frame reaches the 5921. This will result in dot1q trunking not performing properly (the 5921 will receive frames with no VLAN tag, even though it is configured to expect VLAN tags). In IOS, you will notice this by seeing ARP or ping failures.
If you see such behavior, please issue the following debug command from IOS:
# debug arp
Now, try the ping again. If the VLAN tag stripping issue is present, you will see a "wrong cable" message similar to the following:
*Jan 14 21:49:50.874: IP ARP rep filtered src 192.168.110.2 e05f.b986.5500, dst 192.168.110.1 0022.4d7b.e424 wrong cable, interface Ethernet0/0.130
Now switch to the Linux command line and see if the e1000e driver is being used by issuing the following command (using eth0 as an example):
[root@router ~]# ethtool -i eth0
driver: e1000e <== LOOK FOR THIS
From the Linux command line, verify the VLAN mode of the device:
[root@router ~]# ethtool -d eth0
0x00000: CTRL (Device control register) 0x58100248
Endian mode (buffers): little
Invert Loss-Of-Signal: no
Receive flow control: enabled
Transmit flow control: enabled
VLAN mode: enabled <== LOOK FOR THIS
Auto speed detect: disabled
If the VLAN mode is enabled, this indicates that the driver is stripping the VLAN tags.
To remedy this using CentOS, please upgrade to the latest e1000e driver by following these steps from the Linux command line:
#yum install kernel-devel gcc gcc-c++ make wget
#tar zxf e1000e-3.0.4.tar.gz
If the process ends with the following message, ignore it:
/bin/sh: man: command not found
From the Linux command line, verify that the new driver has been activated:
[root@centos src]# ethtool -i eth0
version: 3.0.4-NAPI <== LOOK FOR THIS
Caveats describe unexpected behavior in Cisco IOS releases. Caveats listed as open in a prior release are carried forward to the next release as either open or closed (resolved).
Cisco IOS Release 15.5(3)M
The following sections list caveats for Cisco IOS Release 15.5(3)M:
Crash leaded by BADSHARE messages when shaping traffic
1. Apply a shaper on LAN interface that is oversubscribed by traffic coming in on a DMVPN tunnel
2. The following error messages may be seen
-Traceback= 17376E8z 771568z 16A5CCz 15433Cz 861BECz 1423B8z 1423B8z 861CA8z 238ABFCz 238ACC4z 238828Cz 23B73D4z 16570C8z 1654774z 845470z 84CB70z
%SYS-2-BADSHARE: Bad refcount in datag ram_done, ptr=9580798, count=0
3. The device crashes. In some circumstances the device may not crash and an output queue wedge occurs
On the c5940, the " show proc cpu " shows Total CPU less than interrupt CPU.
IPv4 and IPV6 Multicast traffic does not pass through VMI interfaces.
This happens only when Multicast traffic has to be forwarded over VMI interfaces.
On the C2800 Series Integrated Services Routers, when running DLEP, the router crashes at bma_soutput.
EIGRP Internal routes do not get a route-tag appended when using a distribute-list with a route-map. If these are EIGRP External routes they do not have this problem and the route-tag is set as per the route-map.
In a c5940 which registers hardware SEC Engine as a valid hardware entropy source, the crypto packets shall be depleted after 256 attempts of entropy collection (roughly 10 days). This could hinder the crypto services that needs the crypto packets.
Routes pointing to Null0 do not appear in Routing Table.
Incomplete ESP entries cause high CPU load.
When you have incoming traffic on the outside interface, the CPU will go to a very high load (70% +) with little traffic.
DLEP VRF aware support request
Physical interface configured under a certain VRF, breaks DLEP adjacency with radio device.
ip address 192.168.1.25 255.255.255.0
vrf forwarding VRF-TEST <<< If we add this line, the DLEP adjacency goes down.
ip unnumbered GigabitEthernet0/0.99
vrf forwarding VRF-TEST <<< DLEP works fine with VMI interface configured with a VRF. However since it uses IP unnumbered, the IP address is not considered part of the VRF Routing table and remains in Global Routing table.
VRF configured under a physical interface which we intend to use for DLEP adjacency.
Do not configure a physical interface intended to be used for DLEP under any VRF.
Further Problem Description :
VMI interface used by DLEP is going down and neighbor getting deleted when physical interfaces is configured under a VRF (not in Global Routing table).
Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, using the Cisco Bug Search Tool (BST), submitting a service request, and gathering additional information, see What’s New in Cisco Product Documentation at: http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html.
Subscribe to What’s New in Cisco Product Documentation, which lists all new and revised Cisco technical documentation, as an RSS feed and deliver content directly to your desktop using a reader application. The RSS feeds are a free service.
© 2012-2015 Cisco Systems, Inc. All rights reserved.
Printed in the USA on recycled paper containing 10% postconsumer waste.