Feature Navigator
Use the Cisco Feature Navigator to find information about feature, platform, and software image support. To access the Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on cisco.com is not required.
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The Cisco NCS 520 Series Ethernet Access Device is a family of low cost, fixed Carrier Ethernet Network Interface Devices (NID) and a switch that is targeted to be the next generation replacement of the Cisco ME 3400 series Access Switches. The Cisco NCS 520 Series Ethernet Access Device adds 10G NID and low-cost MBH switch to the existing Service Provider Access portfolio, with the following features:
MEF CE 3.0 compliant
Premium SKUs with support for extended temperature (from -40C to 65C)
Conformal coating on the PCBAs (to be able to support installation in ventilated enclosures)
This release note contains information about the Cisco NCS 520 Series Ethernet Access Device, provides features information for these devices, hardware support, limitations and restrictions, and caveats.
This release note provides information for these variants of the Cisco NCS 520 Series Ethernet Access Device:
N520-4G4Z-A (Base)
N520-X-4G4Z-A (Premium)
N520-X-4G4Z-D (Premium)
N520-20G4Z-A (Base)
N520-20G4Z-D (Base)
N520-X-20G4Z-A (Premium)
N520-X-20G4Z-D (Premium)
Use the Cisco Feature Navigator to find information about feature, platform, and software image support. To access the Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on cisco.com is not required.
The feature matrix lists the features supported for each platform. For more information, see the Cisco NCS 520 Ethernet Access Devices Feature Compatibility Matrix.
The Cisco NCS 520 Series Ethernet Access Device supports the following types of licenses:
Port Licensing—Port Upgrade license is available as a "Pay as you Grow" model.
10G upgrade license
1G upgrade license
Metro Access (default)
The following method is used to activate the above licenses:
Cisco Software Licensing—The Cisco Software License Activation feature is a set of processes and components to activate Cisco software feature sets by obtaining and validating fee-based Cisco software licenses.
Note |
Licenses that are generated by the Cisco Software Licensing are tied to the UDI of the chassis and a corresponding watchtower device certificate (WDC) is stored in the system. |
The following features are supported for the software licenses:
QoS, with deep buffers and hierarchical QoS (HQOS)
Layer 2: 802.1D, 802.1Q
Ethernet Virtual Circuit (EVC)
Ethernet OAM (802.11g, 802.3ah)
IPv4 host connectivity
IP Access License
If you are using Cisco IOS XE Bengaluru 17.6.1 or an earlier release version, Smart Licensing is not enabled by default. To enable Smart Licensing, see Software Activation Configuration Guide (Cisco NCS 520 Series).
This section explains the procedure to upgrade the Cisco NCS 520 Series Ethernet Access Device from Cisco IOS XE Fuji 16.9.x to Cisco IOS XE Gibraltar 16.12.x or later versions.
ROMMON version 1.5 is backward compatible. The backward compatibility of different ROMMON versions with IOS XE versions is in the following table:
Supported Cisco IOS XE release |
Supported ROMMON Version |
||
---|---|---|---|
Cisco IOS XE Fuji 16.8.x Cisco IOS XE Fuji 16.9.x Cisco IOS XE Gibraltar 16.11.x |
1.2 |
||
Cisco IOS XE Fuji 16.9.4 and later Cisco IOS XE Gibraltar 16.11.2 and later Cisco IOS XE Gibraltar 16.12.1 and later Cisco IOS XE Amsterdam 17.1.1 and later |
1.5 |
||
Cisco IOS XE Amsterdam 17.3.1 and later Cisco IOS XE Bengaluru 17.4.1 and later Cisco IOS XE Bengaluru 17.5.1 and later Cisco IOS XE Bengaluru 17.6.x and later Cisco IOS XE Cupertino 17.7.x and later Cisco IOS XE Cupertino 17.8.x and later Cisco IOS XE Cupertino 17.9.x and later |
1.6
|
Perform the following steps to migrate to Cisco IOS XE Cupertino 17.9.x:
Step 1 |
At the command prompt, run the following command to check the current ROMMON version.
|
||
Step 2 |
Copy the running configuration to the bootflash for backup.
|
||
Step 3 |
Copy the migration image to a bootflash location. You can download the migration image from the location: https://software.cisco.com/download/home/286320761/type/286317642/release/1.5.
|
||
Step 4 |
Copy the Cisco IOS XE Cupertino 17.9.x software image to bootflash. |
||
Step 5 |
Set the boot variable to migration image and reload the router.
|
||
Step 6 |
Verify the ROMMON image version. For the RJ-45 console: Check for the following logs during bootup. These logs indicate successful ROMMON upgrade. After a successful ROMMON upgrade, the node auto reloads. This action takes at least 5 minutes to complete successfully.
For VTY Session: Wait for 30 minutes for auto upgrade to complete, and the router to boot up. Reestablish the VTY session.
|
||
Step 7 |
Set the boot variable to the Cisco IOS XE Cupertino 17.9.x software image and delete the migration image from the bootflash. Reload the router to activate the Cisco IOS XE Cupertino 17.9.x software image.
|
||
Step 8 |
After booting the Cisco IOS XE Cupertino 17.9.x image, ROMMON and FPGA will automatically upgrade and the node is reloaded. Once the node is up, the output is displayed:
|
The table below lists the FPGA version of the software releases.
Release |
FPGA Version |
Cisco IOS XE Cupertino 17.9.6 |
0x00030025 |
Cisco IOS XE Cupertino 17.9.5a |
0x00030025 |
Cisco IOS XE Cupertino 17.9.4a |
0x00030025 |
Cisco IOS XE Cupertino 17.9.4 |
0x00030025 |
Cisco IOS XE Cupertino 17.9.3 |
0x00030025 |
Cisco IOS XE Cupertino 17.9.2a |
0x00030025 |
Cisco IOS XE Cupertino 17.9.1 |
0x00030025 |
Note |
The FPGA automatically upgrades to 0x00030025 from Cisco IOS XE Cupertino 17.7.1 onwards. The Cisco NCS 520 Series Ethernet Access Device will take around 210 seconds to reboot after a successful FPGA upgrade. Do not power-cycle the Ethernet Access Device during FPGA upgrade. |
Supported Cisco IOS XE Release |
ROMMON Version |
---|---|
Cisco IOS XE Cupertino 17.9.6 |
1.6 |
Cisco IOS XE Cupertino 17.9.5a |
1.6 |
Cisco IOS XE Cupertino 17.9.4a |
1.6 |
Cisco IOS XE Cupertino 17.9.4 |
1.6 |
Cisco IOS XE Cupertino 17.9.3 |
1.6 |
Cisco IOS XE Cupertino 17.9.2a |
1.6 |
Cisco IOS XE Cupertino 17.9.1 |
1.6 |
Note |
ROMMON automatically upgrades to 1.6 from Cisco IOS XE Cupertino 17.7.1 onwards. |
Note |
The error message "PLATFORM-1-NOSPACE: SD bootflash : no space alarm assert" may occur in the following scenarios:
This issue is observed on platforms which use EXT2 file systems. We recommend performing a reload of the router. As a result, above alarm will not be seen during the next reload due to FSCK(file systems check) execution. However, If the error persists after a router reload, we recommend to format the bootflash or FSCK manually from IOS. |
The default interface command is used to default the parameters under that interface. However, when speed is configured on the interface, the following error is displayed:
Speed is configured. Remove speed configuration before enabling auto-negotiation
Adding or deleting the Trunk Ethernet flow points (TEFPs) with scaled bridge-domain, without delay causes the Cisco NCS 520 Series Ethernet Access Device to crash.
Virtual services should be deactivated and uninstalled before performing replace operations.
The controller and nid-controller commands are not supported.
Cisco NCS 520 Series Ethernet Access Device displays an error in Hierarchical QoS policy while trying to remove the bandwidth and bandwidth percent commands from the default parent class dynamically. To remove the commands, you must first remove the bandwidth from child class and then from the parent class.
When port is in OPER-DOWN state, applying Hierarchical QoS followed by speed change sets wrong bandwidth values on standard queues. To work around the mismatch, you must reattach the policy to the port level again.