CTR 8540 CTR 8300 - Release 3.10.0 (45.6148) Customer Software Release Notes September 2019

CTR 8540, 8300, 8300v2 and 8380 –
Release 3.10.0(45.6148)
Customer Software Release Notes
Software Version 3.10.0
RELEASE NOTE DATE: 26th September 2019
P/N 275-250424-006148 – CTR 8540

P/N 275-250427-006148 – CTR 8300
P/N 275-250432-006148 – CTR 8300v2
DocReg Ref: 2841-253
WWW.AVIATNETWORKS.COM
COMBINED CTR 8540 & CTR 8300 RELEASE NOTES
White Paper
Copyright © 2018 by Aviat Networks.

All rights reserved. No part of this publication may be reproduced, transmitted, transcribed, stored in
a retrieval system, or translated into any language or computer language, in any form or by any
means, electronic, magnetic, optical, chemical, manual or otherwise, without the prior written
permission of Aviat Networks.
DISCLAIMER
Aviat Networks makes no representation or warranties with respect to the contents hereof and
specifically disclaims any implied warranties or merchantability or fitness for any particular purpose.
Further, Aviat Networks reserves the right to revise this publication and to make changes from time
to time in the content hereof without obligation of Aviat Networks to notify any person of such
revision or changes.
TECHNICAL SUPPORT
If you require technical assistance or if you have discovered a product issue, please contact the
Technical Help Desk nearest to you as soon as possible. Their contact details are shown below:
USA Europe, Middle East & Asia/Pacific

Africa
Aviat Networks Aviat Networks Aviat Networks
860 N McCarthy Blvd #200 4 Bell Drive Bldg 10 Unit B, Philexcel Industrial
Milpitas, CA 95035 Hamilton International Technology Park
Phone: +1 800 227 8332 free within Park Clark Special Economic Zone
US only. Or +001 408 567 7000 Blantyre, Scotland, G72 0FB Clark Field
United Kingdom Pampanga
Aviat Networks Phone : +44 1698 717 200 Philippines ,C-2009
5250 Prue Rd. Building 5, Phone: +63 45 599 5192
Suite 535 Aviat Networks
San Antonio, TX 78240 Batiment Le Dynasteur E-mail:
Phone: +1 800 227 8332 free within 10-12 Rue Andras Beck TAC.APAC@aviatnet.com
US only. Or +001 408 567 7000 Meudon La Foret cedex
92366
E-mail: Tel : +33 1 77 31 00 00

TAC.AM@aviatnet.com
E-mail:
TAC.EMEA@aviatnet.com
2 © AVIAT NETWORKS, INC. (2015) ALL RIGHTS RESERVED SEPTEMBER 27, 2019
White Paper
Table of Contents
Scope and Purpose .............................................................................................. 4
CTR 8540 Release Features and Functionality Supported ............................... 6
CTR 8540 Functionality Not Included in this release ...................................... 15
CTR 8540 Software Version Upgrade Compatibility ....................................... 16
CTR 8540 Software Part Numbers .................................................................... 16
CTR 8540 ProVision Support ............................................................................ 16
CTR 8540 Hardware Supported ......................................................................... 16
CTR 8540 Hardware and Software Compatibility ............................................ 17
CTR 8540 Profiles Supported ............................................................................ 18
CTR 8300 Release Features and Functionality Supported ............................. 23
CTR 8300 Functionality Not Included in this release ...................................... 28
CTR 8300 Software Version Upgrade Compatibility ....................................... 29
CTR 8300v2 Software Version Upgrade Compatibility ................................... 29
CTR 8300 Software Part Numbers .................................................................... 29
CTR 8300 ProVision Support ............................................................................ 29
CTR 8300 Hardware Supported ......................................................................... 30
CTR 8300 Hardware and Software Compatibility ............................................ 31
CTR 8300 Profiles Supported ............................................................................ 32
CTR 8540 and CTR 8300 Known Issues ........................................................... 37
CTR 8540 Closed Field Issues .......................................................................... 62
White Paper
Scope and Purpose

This document provides software release information, including supported functionality, compatibility,
resolved issues and known customer affecting issues, for the associated software version.
The intended users of this document are:

• Aviat Networks Customers
• Aviat Networks Product Support staff
• Aviat Networks Field Service staff
The CTR platform 3.10.0 software is released for General Availability (GA) with CTR 8540, CTR
8300, CTR 8300v2 and CTR 8380v1/v2 at version 3.10.0 (45.6148). It may be downloaded and
deployed in customer networks where the network design that requires the deployment of new
features made available within this release have been validated by Aviat Networks.
The features and fixes made available in this software release have been tested and packaged in
this software release ready for all customers (unless the customer has a specific build requirement).
This release delivers
• Support four NTP server configuration

• LDP IGP Synchronization for IS-IS (Point-Point)
• Source IP address for SNMPv2/v3, SNTP and Syslog
• CIT Field issues
.
Please contact your Aviat Networks representative if you would like to evaluate and deploy any of the
new CTR functionality or to request a network design validation.
The following tables summarize the new features and functionality now supported (new features added
with this release are shown in Green).
Please note that if you are currently operating with a 2.x.y feature license these will need to be
upgraded to 3.x.y feature licenses to use the new 3.x features made available in this release. Please
contact your local Aviat representative for details. For those customers with pre-existing Release 2
features already licensed, these will continue to be available after upgrading to 3.x.y.
White Paper
IMPORTANT; PLEASE NOTE THE FOLLOWING SOFTWARE UPGRADE/DOWNGRADE
CONSIDERATIONS:
1) Hardware and Software Compatibility

When upgrading or downgrading software, please refer to the CTR 8540 and CTR 8300 hardware and
software compatibility tables to ensure that the software being loaded will be supported by the hardware
being updated.
2) Memory Usage During Upgrade

In previous software releases (prior to CTR release 3.4.x), if the CTR memory usage was significantly high
at the point where a software load was performed, there was a possibility that the CTR would reboot and
fail the software load. The workaround was for the user to re-apply the software pack. The occurrence of
this issue is rare (less than 1% of upgrades). This issue has been resolved since software release 3.5.20.
3) DRAM Memory Initialization Issue

When completing a software upgrade on the CTR 8540 from version 2.2.0 or 2.2.1, to version 3.x. it is
possible that the CTR terminal may become unresponsive during the software initiated reboot and will
require a power cycle to recover operation. While the occurrence of this issue is rare (less than 1% of
upgrades) it is highly recommended that staff be on site during the upgrade to power cycle the terminal if
needed. This issue is associated with the DRAM memory initialization process of the previous version of
software and it was rectified in the earlier 2.4.0 GA Release. This does not apply to the CTR 8300.
4) Downgrading to Version 2.x

If a CTR has been shipped with 3.x software loaded, and the user immediately downgrades to a 2.x based
release the configuration file storage format will not allow the terminal to be upgraded again to 3.x without
losing the configuration file. It is recommended that CTRs are NOT DOWNGRADED from 3.x to 2.x version
SW. Only version upgrades are currently supported. Please contact Aviat Networks for support in
upgrading any terminals that may have been downgraded. A manual rectification process can be followed
during upgrade to restore the configuration.
5) BFD Incompatibility Between Versions

BFD over OSPF operation is incompatible between version 3.5.2 or earlier and version 3.5.22 or later.
Traffic will not pass over a link between two CTR’s running incompatible versions if BFD is enabled. Failure
to take this into account during network upgrade could result in CTR’s becoming isolated and unable to be
upgraded remotely.
Two methods of upgrading CTR’s which use BFD are given below. Instructions assume CTR’s are running
version 3.5.2 or earlier prior to upgrade.;
Method 1 – Disable BFD

Step 1: Disable BFD over OSPF in CTR;
conf terminal
router ospf
disable bfd
end
Step 2: Save the configuration in CTR

Step 3: Upgrade CTR to R3.6.2 or later
Repeat above steps with all CTR’s in network. When all of the CTR’s in the network have been
upgraded to R3.6.2, BFD for OSPF can be re-enabled in all CTR’s;
conf terminal
router ospf
enable bfd
bfd all-interface
end
White Paper
Method 2 – Simultaneous Activation

If it can be guaranteed that all connected CTR’s can be activated simultaneously after upgrade there
is no requirement to disable BFD prior to upgrade as described in Method 1.
6) Login Authentication option

Users are unable to access the CTR8300/8540 after upgrading from version 3.5.22 to later version if the
login authentication is configured as TACACS only. Login authentication configuration needs to be modified
to “TACACS local” before upgrading software version.
Step 1: Modify login authentication configuration in CTR;
conf terminal
login authentication tacacs local
end
Step 2: Save the configuration in CTR

Step 3: Upgrade CTR to R3.6.2 or later
Login authentication configuration can be changed back to TACACS only after upgrading the software.
7) Upgrading from Release 3.4

When upgrading from versions 3.4.0, 3.4.1, 3.4.2 and 3.4.3, it is recommended to reboot the CTR8540
prior to starting the software upgrade
CTR 8540 Release Features and Functionality Supported
Hardware
CTE-002-001 CTR 8540 Chassis with Fan Assembly, blank plates and install kit
Note: Software R3.0.2 and later require revision HSC 3 or later chassis main
boards.
CTX-880-001 CTR RACx2 Dual IF Radio Access Module 1024 QAM, ACM and XPIC Capable
Note: Software R3.0.2 and later require revision 002 or later RACx2 cards.
CTX-800-001 CTR RACx1 Single IF Radio Access Module 1024 QAM, ACM Capable
Note: Software R3.0.2 and later require revision 002 or later RACx1 cards.
CTP-120-001 CTR 8500 Series 2xPOE GBE, 70W/56V, Power Over Ethernet Module
CTS-100-001 CTR 8500 Series Redundant Power Module, 48VDC
CTF-001-001 CTR 8500 Series FAN Module
079-422667-001 SFP TSoP STM-1/OC3 over Gig-E, S1.1 15km SMF 1310nm LC
STM-1/OC3 Transparent Pseudowire over Gigabit Ethernet – SFP Module
079-422673-001 SFP TSoP STM-4/OC12 over Gig-E, S1.1 15km SMF 1310nm LC
STM-4/OC12 Transparent Pseudowire over Gigabit Ethernet – SFP Module
White Paper
Software and Feature Licenses
CZL-60200 CTR 8500 Series R2 BASE Software License
Includes : System Admin and Operation, CLI, CTR Portal, SNMP management
CZL-60210 CTR 8500 Series R2 CARRIER ETHERNET Software License
Includes BASE plus : VLAN, Q-in-Q, E-OAM, QoS, ERPS, LACP and MEF-8 Pseudowire
Includes : System Admin and Operation, CLI, CTR Portal, SNMP management, OSPF
CZL-60301 CTR 8500 Series R3 BASE + TDM Software License
Includes BASE plus SYNCE, MEF-8 Pseudowire and OSPF and 16 TDM ports
Includes BASE plus : VLAN, Q-in-Q, E-OAM, QoS, ERPS, SYNCE, MEF-8 Pseudowire and
OSPF
CZL-60340 1 CTR 8500 Series R3 MPLS STANDARD Software License
Includes Base and Carrier Ethernet license plus : OSPF, ISIS, LDP, RSVP, MPLS, MPLS_OAM,
MPLS_TDM, L2VPN
CZF-60030 CTR 8500 Payload Encryption (One License Per Chassis)
CZF-60050 CTR 8500 Secure Authentication Client, Centralized Usr Acct Mgmt (One License Per Chassis) -
TACACS
CZF-60060 CTR 8500 Secure Management (One License Per Chassis)
CZL-60350 1 CTR 8500 Series R3 MPLS STANDARD Software License
Includes Base, Carrier Ethernet and MPLS Standard license’s plus : L3-VPN,
OSPF-TE, ISIS-TE, MPLS-TE, BGP
CTR 8500 Series R2 to R3 BASE Software License Upgrade
CZG-60R00 Includes : System Admin and Operation, CLI, CTR Portal, SNMP management, OSPF
CZG-60R10 CTR 8500 Series R2 to R3 CARRIER ETHERNET Software License Upgrade
Includes BASE plus : VLAN, Q-in-Q, E-OAM, QoS, ERPS, SYNCE, MEF-8 Pseudowire and
OSPF
CZG-60P10 CTR 8500 CARRIER ETHERNET SOFTWARE LICENSE - UPGRADE FROM BASE
CZG-60P40 1 CTR 8500 MPLS STANDARD SOFTWARE LICENSE - UPGRADE FROM BASE
CZG-60P41 1 CTR 8500 MPLS STANDARD SOFTWARE LICENSE - UPGRADE FROM CARRIER ETHERNET
CZG-60P50 1 CTR 8500 MPLS ADVANCED SOFTWARE LICENSE - UPGRADE FROM BASE
CZG-60P51 1 CTR 8500 MPLS ADVANCED SOFTWARE LICENSE - UPGRADE FROM CARRIER ETHERNET
CZF-609xx CTR ODU Airlink Capacity Licenses
CZF-60010 Flexible Power Mode License (one license per ODU 600)
CZF-60011 IRU600 High Power License (one License per RFU)
CZF-60016 XPIC license for RACx2 (one license per RACx2)
CZF-60018 ACM License up to 256 QAM (one license per ODU)
CZF-60020 ACM License up to 1024 QAM (one license per ODU)
CZF-60030 Payload Encryption (one license per chassis)
CZF-60040 L1LA (Layer One Link Aggregation) license
CZF-60060 Secure Authentication – TACACS+ (one license per chassis)
CZF-60070 Enable Four Electrical 10/100/1000 ports
CZF-60080 Enable Eight TDM ports
CZF-60085 Enable Sixteen TDM ports
CZF-60090 Enable Four Gig-E SFP ports
CZF-60100 1588v2 PTP Transparent Clock (One license per chassis)
1 Please contact your Aviat Networks representative to arrange support for L3 / MPLS functionality.
White Paper
Radio Functionality and ODU Interoperability with RACx1 and RACx2
ETSI Channel 3.5, 7, 13.75 / 14, 27.5 / 28 / 29.65, 40 and 55 / 56 MHz channels (refer to
Support modem profile section for full detail on all profiles available in this release)
ANSI Channel 3.75, 5, 10, 20, 25, 30, 40, 50, 60 and 80 MHz channels (refer to modem profile
Support section for full detail on all profiles available in this release)
Modulations QPSK, 16, 32, 64, 128, 256, 512 & 1024 QAM – Both ACM and Fixed modes.
Includes ATPC operation
XPIC / CCDP ETSI Channels –13.75 / 14, 27.5 / 28 / 29.65, 40 and 55 / 56 MHz
Support ANSI Channels – 25, 30, 40, 50, 60 and 80 MHz
Operation supported with 2+0, 2+2 and N+N Protected/Space Diversity
configurations, including ACM, ATPC and L1LA operation on RACx2
Note: V & H Pol must operate on the same RACx2
1+1 ODU Protection RACx2 Supports two IF connected ODUs for 1+1 Protection
(Intra-RAC) Typically <50ms switching for ODU failure
Errorless 1+1 Receiver Space Diversity
Fixed Modulation and ACM is supported
1+1 ODU & RAC RACx1 and RACx2 support ODU and RAC protection between two cards of the
Protection same type. A RACx1 can protect the operation of another RACx1. A RACx2
(Inter-RAC) can protect the two interfaces of its partner RACx2.
Typically <50ms switching for ODU failure
ODU 600 Bands 5, 5.8, 6, 7, 8, 10, 11, 13, 15, 18, 23, 26, 28, 32, 38 & 42 GHz - Up to 1024 QAM
ODU 600sp 6, 7, 8, 11, 13, 15, 18, 23, 26, 28, 32 & 38 GHz – Up to 512 QAM
ODU 300hp Bands 5, 6, 7, 8, 10, 11, 13, 15, 18, 23, 26, 28, 32 & 38 GHz – Up to 256 QAM only
ODU 600T Support for the STR 600 Outdoor Branching Unit and the associated ODU 600T
bands, RACx1 or RACx2.
ODU 600v2 L6, U6, 7, 8, 10, 11, 13, 15, 18 GHz – Up to 1024 QAM
IRU 600v3 L6, U6 & 11GHz bands up to 1024QAM
Note: Operation with EHP has some limitations
IRU 600v4 L6, U6, FCC7 (upper portion of U6 RFU) and 11GHz HP and EHP bands up to
1024QAM
IFG & Pre-Headers Optimization of over-the-air throughput by compressing the inter frame gap and
preamble
L1LA Layer One Link Aggregation, consisting of a single L1LA group with up to 8
member ports, or two L1LA groups with up to 4 member ports in each group.
Member ports may be ACM, protected and XPIC capable.
This release supports the following L1LA configurations:

- Single and Dual L1LA groups of 2+0 and 2+2
- Single and Dual L1LA groups of 3+0 or a Single group of 3+3
- Single and Dual L1LA groups of 4+0 or a Single group of 4+4
- Single L1LA group of 5+0, 6+0, 7+0 and 8+0
2+0 OTA Interoperability with CTR 8312v2 and 8380v2 is now supported
L1LA support over PoE interfaces to enable WTM4K trunking, subject to

restrictions detailed in the L1LA Operations section of the CTR8540 Getting
Started Configuration manual.
Payload Encryption AES256 bit over-the-air Encryption is supported on RACx1 and RACx2.
Supported along with the following functionality:
White Paper
- 1+0, 1+1, N+N Protection and Space Diversity links
- L1LA, ACM & XPIC
PCR Paperless Chart Recorder
Carrier Ethernet Functionality

Ethernet Switching Switching support has been validated up to 4 Gbps with this release
MAC Learning of up to 8000 addresses (256 are reserved for Static MAC
addresses with the remaining 7744 for dynamic MAC learning)
VLANs 802.1Q VLAN Tag and untag, filtering / membership per customer and provider
tag
802.1ad Provider Bridging (QinQ), VLAN translation
Support for 4095 VLANs with up to 250 configured per CTR
QoS – 8 Queues Classification: VLAN, DSCP or Port based (MPLS EXP excluded)
Scheduling: Strict, RR, WRR, CIR/EIR, and Hybrid options of Strict-RR, Strict-
WRR and Strict-CIR/EIR. Supports up to 3 strict priority in Hybrid mode
Tail drop and WRED queuing, Configurable Tx Queue Buffers
Storm Control, Ingress Traffic Policing, 802.1p QoS Traffic remarking
Port mirroring (single destination)
Output Rate Limiting : Static on outgoing ports
Dynamic Shaping with ICF on RAC interfaces for hitless ACM control
Jumbo Frames MTU sizes from 64 to 10,000 byte supported
Sync-E Synchronous Ethernet is supported on all front panel Electrical Gig-E interfaces,
Optical SFPs, E1/T1 interfaces and the PoEx2 Module. ESMC and SSMs are
supported with fallback to internal Stratum-3 clock.
E1/T1 ports can also be used as a Sync-E clock source, note that SSM is not
supported over E1/T1 links. Synchronous Ethernet is supported on router ports.
User configurable SSM/ESMC Quality Level output may also be set for clocks
running in Freerun and Holdover mode.
LAG Layer 2 Link Aggregation (802.1AX) on front ports, RAC and PoE interfaces.
LACP Static and Dynamic LAG is supported in this release.
Note: LAG on RAC interfaces must use fixed modulation member ports with
equal capacity. ACM cannot be enabled on RAC interfaces in a LAG group. The
more efficient L1LA solution is recommended for RAC interfaces.
ERPS Ethernet Ring Protection compliant (G.8032) – Port Based and VLAN Based
ERPS over RAC radio links and front panel ports only – Not validated over WTM
3205/PoEx2
ECFM with OAM CCM – CCM offloaded by default, configurable for 100ms and
greater periods.
OAM based network device switching <300ms with 100ms CCM.
<50ms with 3.3 and 10ms CCM
ERPS Sub-rings
RSTP & MSTP Rapid and Multiple Spanning Tree Protocol (IEEE 802.1W and 802.1S)
Ethernet OAM 802.1ag / Y.1731 CC, LB & LT, PD, PDV, LM, including UP MEP support.
802.3ah ETH-AIS & ETH-RDI
MEF 35 MEF35 PM 1 performance measurement functions (single ended delay and
single ended synthetic loss measurements)
PTP 1588v2 CTR supports agnostic transport of 1588v2 PTP packets with classification and
scheduling user configurable per QoS policy.
White Paper
It is recommended that the highest priority be used for PTP to provide optimum
PDV performance.
PTP 1588v2 Transparent Clock (TC) is available on the CTR 8540 operation
over the RACx1 and RACx2 and now also supported interoperability with CTR
8300v2 and CTR 8380v2. This feature provides superior PTP clock accuracy
and is enabled via the new software feature license CZF-60100.
Link Status Used to force an Ethernet port to shutdown at both ends of radio link in the event
Propagation (LSP) of a link failure, and to restore its operation when the link is re established.
Support for PB (PNP, CEP, CNP, PPNP) & CB bridge mode as local and
monitored port.
L3 / MPLS Functionality (please see footnote Error! Bookmark not defined. on page 7)
IPv4 IPv4 unicast routing and forwarding.
IS-IS IS-IS routing including Traffic Engineering extensions, level 2 only. This release
also adds support for wide metrics on non Traffic Engineered links.
RSVP-TE MPLS LSP signaling using RSVP-TE (excluding FRR).
1:1 LSP Protection over OSPF/OSPF-TE
L2VPN Layer 2 VPN - VPWS & VPLS
L3VPN Layer 3 VPN, support for eBGP as routing protocol on CE-PE interface.
Including MD5 Authentication for BGP.
VPN Mapping to Ability to use Interface VLAN Routers (IVR) on a CE-PE link.
Multiple Subports
VRF Ping & VRF Ping is used to verify L3VPN connectivity across provider edge devices.
Traceroute The IP interfaces supported for this feature include both loopback and physical
IP interfaces in an L3VPN VRF.
MPLS SAToP PW MPLS SAToP Pseudowires
MPLS LM and DM MPLS Packet Loss measurements and Delay measurements. (RFC 6374)
MPLS-TP This release adds support for the following MPLS-TP features.
Static Provisioning of:
• Unidirectional P2P Transport Paths
• Bidirectional Co-Routed P2P Transport Paths (Symmetric & Asymmetric)
• Associative Bidirectional P2P Transport Paths (Symmetric & Asymmetric)
• Unidirectional P2MP Transport Paths
The following Quality of Service mapping techniques can be applied
• Manual static priority
• 802.1p based priority
• DSCP based priority
Supported MPLS OAM and Failure Detection methods (subject to the
configuration required)
• LSP Ping
• LSP Trace
• BFD
Policing per L2VPN Ingress and Egress policing L2 VPN services for CIR, PIR and Classification of
traffic
MPLS Alarms Introduction of the following MPLS Alarms:
• MPLS TE tunnel down
• MPLS tunnel rerouted (including protection switch)
• MPLS tunnel re-optimized
• PW (L2VPN) down
White Paper
• LSP down
• IGP neighbor loss
LDP neighbor down
MPLS LSP • 1:1 RSVP-TE End-to-End protection, protection path must be explicit-
Protection strict. (explicit-loose is not fully validated in this release).
BFD BFD monitoring of MPLS-TE LSPs, LDP & OSPF, including hardware offloading
LDP & T-LDP Label Distribution Protocol and Targeted LDP.
Including:
• MD5 Authentication for LDP sessions
• LDP-IGP Synchronization for OSPF (Point-to-Point)
• LDP-IGP Synchronization for ISIS (Point-to-Point)
OAM LSP Ping and Traceroute.
Higher Layer Protocols

DHCP Relay Agent DHCP relay agent functionality as defined in section 8 of RFC 951 & section 4 of
RFC1542
L3 / MPLS Scalability and Performance (Validated at release date of these notes)

Max static routes 10,000
Max ISIS routes with LDP 1,000
Max number of ISIS routers in area 100
ISIS convergence time Typically less than 10 seconds
Max number of VRF (excluding default) 9
Max VLAN interfaces in VRF 150
Max ISIS routes 2,500
Max BGP routes 10,000
Max Head RSVP-TE Tunnels2,3 200
Max Tail RSVP-TE Tunnels2,3 200
Max Transit RSVP-TE Tunnels2,3 150
Typical RSVP-TE Tunnels combination 50/50/100
supported simultaneously (Head/Tail/Transit)2
Min reservable bandwidth in TE link 1Kbps
Max ARP database 1,000 Per VRF
Max IP throughput 4 Gbps with 64B packets
7.9 Gbps with 10KB packets
Max IP forwarding rate 5.5Mpps
Max IP forwarding latency 41s@1518B
Max IP forwarding jitter 2s
Max IP Interfaces 190 IPv4 Interfaces comprising a maximum of:
• 20 Physical and virtual interfaces (Front panel,
plug-in, protection, L1LA and Virtual LAG)
• 20 Loopback interfaces
• 150 L2 VLAN (IP VLAN interfaces/IVRs)
2 The number is for un-protected, unidirectional tunnels. For 1:1 protected tunnels, the number is halved
3 This is the number of tunnels supported if no other types of RSVP-TE tunnels exist on the router
White Paper
Ethernet Diagnostics
Ethernet Utilisation Graphical display of Ethernet utilization via the Web GUI.
Graphing
TDM Functionality
16xE1 Standard unstructured MEF 8 efficient Ethernet Pseudowire to carry structure
agnostic TDM payload from E1 or to Ethernet interfaces. Supports up to 16xE1
per CTR.
16xT1 Standard unstructured MEF 8 efficient Ethernet Pseudowire to carry structure
agnostic TDM payload from T1 or to Ethernet interfaces. Supports up to 16xT1
per CTR.
Strong Security
SNMP v3 Support for SNMPv3
Mechanised Attack Prevention of multiple high speed failed login attempts (brute force attacks)
Prevention
HTTPS In strong security mode, the web server allows connections only over HTTPS
This feature facilitates
User Access • Local User Account management
• User authentication
Management
• User privilege level setting
• Capture and display of last login information
When strong security mode is enabled the following protocols are disabled:
• telnet
Removal of insecure • HTTP
management • SNMPv1/v2
protocols Note: Some customers may wish to run SNMPv2 even after entering strong
security mode. To support this requirement, re-enabling SNMPv1/v2 in strong
security mode is permitted.
Security events are captured via Secure Syslog functionality.
Secure Syslogs
Access of Secure Syslogs is via authorized users only.
Login warning banners containing security notices that are configurable by the
Warning Banners user. Support for independent pre-login and post-login banners.
Secure File Transfer Secure transfer of selected system files to or from the CTR.
Secure storage of encryption keys and certificates for various protocols (SSH,
Key Storage HTTPS, Payload Encryption, SNMPv3)
Weak ciphers are disabled when strong security is enabled.
Strong Ciphers Strong ciphers are enabled for all management protocols when a strong security
license is present.
Management of user sessions:
User Sessions • Configuration of session inactivity timeouts
• Configuration of the maximum number of concurrent sessions
Access Control Lists Access Control Lists for IP
White Paper
CTR Administration and Operation Functionality
AOS Aviat OS Software upgrade from CLI or Web Interface. Active and inactive
versions maintained for rollback after upgrade. No traffic impact during upload,
only on activation (outage on activation typically 2 mins)
Licenses Feature and capacity licenses can be applied or upgraded to SD card S/N
(future releases will enable additional flexibility in allocating licenses)
Configuration Configurations can be saved and loaded, temporary changes reverted, revert to
factory defaults. Active configurations are stored on SD card and can be re-fitted
to another CTR chassis.
Management IPv4 addressing with an In-Band Management VLAN. Telnet or SSH access
Interface (SSH uses low level 56 bit cypher as part of BASE license – higher levels
enabled with Strong Security when released)
Console access through V.24 port for local CLI Interface
SNMPv2c / SNMPv3 ProVision or MIB interface support – Standard and Aviat proprietary MIBs
• Source IP address Configuration
Alarm & Event and Alarm capture, time stamp and logging.
Performance Ethernet statistics (partial RMON 1), Radio performance statistics
Indications Front Panel LED indicators for main board and plug-in cards
Locate-ME function, when enabled, blinks the Aviat logo on the terminal front
panel
Date & Time Simple Network Time Protocol (SNTP V4) support as well as embedded real
time clock
• Four NTP Servers Configuration
• Source IP Address Configuration
Web UI The Web UI has been enhanced to provide:
• Remote syslog view
• SNTP configuration
o Four NTP Servers configuration
• Provider-Edge switch mode selection
• QoS MPLS EXP and QoS Congestion Control
• Routed NMS configuration
• SNMPv2 Configuration
Hostname The ability to set a name in the CLI that is displayed in the command prompt
TACACS+ TACACS client to allow CTR to authenticate with an external TACACS server
SSH Client Launch a SSH client from within the AOS CLI environment to connect to another
CTR terminal
OSPF OSPF provided to enable Routed NMS compatibility and interoperability with
Eclipse equipment.
White Paper
OSPF Functionality Sub Features Status

Authentication Simple Text Authentication Released
MD5 Authentication Released
Interface cost Released
Router Type Internal Router Released
Backbone Router Released
Area Boundary Router (ABR) Released
Autonomous System Boundary Router (ASBR) Released
Interface Config Interface Priority Released
LSA Retransmit Interval Released
LSA Transmit Delay Released
Hello Interval Released
Dead Interval Released
Hold Timer Released
Network Type Broadcast Network Type Support Released
Point-to-Point Network Type Support Released
Non Broadcast Network Type Support Not Validated
Point-To-Multipoint Network Type Support Not Validated
Administrative distance Released
Route Summarization Type 3 LSA Released
Type 5 LSA Released
Type 7 LSA Released
Stub Areas Backbone Area (Area 0) Released
Standard Area Released
NSSA - Not-So-Stubby Area Released
Stub area Released
Totally Stubby Area Released
Virtual Links Not Validated
Redistribution Directly connected and static routes only Released
BFD support, including hardware offloading Released
Traffic Engineering - OSPF-TE Released
Opaque LSA for OSPF_TE Released
Hiding Transit Only Networks in OSPF Released
LDP IGP Synchronization for OSPF Released
Scalability Performance (Validated at release date of these notes)
Number Of OSPF Routes are supported 10,000
LSA Database Limit 10,000
Number of Areas 20
Number of Interfaces per router on a OSPF process 20
White Paper
WTM validation with 2xPoE Module

WTM 3300 1+0 Configurations only have been validated when operating in a CTR nodal
network running Carrier Ethernet functionality across these radio links.
Note that there is no common configuration integration between CTR and WTM
other than Provision Element Management. Each product uses its own web
based configuration tools.
The signaling between the CTR 8540 2xPoE card and WTM 3300 for traffic
shaping and ACM interworking will shape traffic according to the WTM 3300
over the air rate.
2xPoE Module
10/100/1000 Mbps All interface speeds supported.
Interfaces
CTR 8540 Functionality Not Included in this release
CTR 8540 Functionality that is not included or validated in this release

IRU 600v1 & v2 Operation with RACx2 or RACx1
Frequency Diversity For RACx2 or RACx1
ERPS Support over PoEx2 and WTM links
Link Status Degraded mode - The local user port shuts down responding to decrease in
Propagation capacity of radio link
LAG as monitored port or local user port
Multi-hop LSP
Carrier Ethernet Features

OAM
Flow Control
Dying Gasp
QoS QoS Congestion Control for L3 traffic streams
L3 / MPLS Features
RSVP-TE Fast re-route
White Paper
CTR 8540 Software Version Upgrade Compatibility
This release is compatible with the following previous field release for CTR 8540 as follows:
• 3.0.0(21.3069)
• 3.0.2(21.3211)
• 3.0.3(21.3265)
• 3.1.0(31.3266)
• 3.1.0(41.3363)
• 3.2.0(32.3614)
• 3.3.0(34.4070)
• 3.4.0(35.4269)
• 3.4.0(35.4435)
• 3.5.1(37.4745)
• 3.5.2(37.4705)
• 3.5.3(37.4676)
• 3.5.4(38.4742)
• 3.5.7(37.4814)
• 3.5.9(38.4819)
• 3.5.20(39.5084)
• 3.5.21(39.5293)
• 3.5.22(39.5392)
• 3.6.1(41.5670)
• 3.6.2(41.5714)
• 3.7.0(42.5860)
• 3.8.0(43.5950)
• 3.9.0(44.6088)
CTR 8540 Software Part Numbers
Product Part Number Version Build
CTR 8540 Customer Software 275-250424-006148 3.10.0 6148
CTR 8540 ProVision Support

The new features in release 3.10.0 require ProVision Element Manager System software version
7.9.2 or later. Earlier releases of ProVision do not fully support release 3.10.0.
CTR 8540 Hardware Supported

The following table details the hardware that is supported by this software and corresponding part
numbers.
Software Product Part Number Notes

CTR 8540 Chassis CTE-002-001
CTR RACx2 CTX-880-001
CTR RACx1 CTX-800-001
CTR 8500 2xPOE CTP-120-001
CTR 8500 Redundant Power CTS-100-001
Module
ODU 300 HP EAH-xx-xxxx-xxx Limited to 256QAM
operation only
ODU 600 5-42 GHz EEH-05 to EEH-42
ODU 600 7/8 GHz Enhanced EEH-07 E / EEH-08 E
ODU 600sp 6-38 GHz EES-07 to -38 Limited to 512QAM
operation only
White Paper
IRU600v3 L6, U6 & 11GHz EV/B/N1XX-XX-XX- Up to 1024QAM
300
ODU 600v2 ECH-FF-TTTT-RRR Up to 1024 QAM
FF= Frequency Band
TTTT = T-R Split
RRR = Revision
CTR 8540 Hardware and Software Compatibility

The following tables list the minimum software version to be used with a version of hardware. A later
version of software can be used with an earlier version of hardware but not the reverse (e.g. you can
use 3.1.0 software with CTR 8540 Mainboard HSC 3 because the minimum software version for that
HSC is 3.0.2. In the same way you cannot use 2.4.0 software, because 2.4.0 is a lower version than
the minimum needed for HSC 3). Details of the hardware version are provided in the manufacturing
details screen of the GUI or by using the “show manufacturing-details” command in the CLI. The
HSC number is the first 3 digits in the revision number shown as 1 in the GUI and CLI screen
captures below.
Hardware HSC Mainboard Software Software

Part Number Version Part Number
CTE-002-001 CTR 8540 004 021-142741-002 3.1.0(41.3363) 275-250424-003363
003 021-142741-001 3.0.2(21.3211) 275-250424-003211
002 021-142741-001 2.4.0(20.2694) 275-250424-002694
Hardware Revision Part Number Software Software

Version Part Number
CTX-880-001 CTR 8500 RACx2 2 Refer hardware 3.0.2(21.3211) 275-250424-003211
1 2.4.0(20.2694) 275-250424-002694
CTX-800-001 CTR 8500 RACx1 2 Refer hardware 3.0.2(21.3211) 275-250424-003211

1 2.4.0(20.2694) 275-250424-002694
CTP-120-001 CTR 8500 2xPOE 1 Refer hardware 2.4.0(20.2694) 275-250424-002694
CTS-100-001 CTR 8500 Redundant PSU 1 Refer hardware 2.4.0(20.2694) 275-250424-002694
White Paper
CTR 8540 Profiles Supported
3.5 MHz ETSI Airlink Capacity Modulation Enabled Modules
ACM - non-XPIC 3.93 Mbps QPSK CTR 8540 RACx1 / RACx2
ACM - non-XPIC 9.79 Mbps 16QAM CTR 8540 RACx1 / RACx2

13.75 / 14.0 MHz ETSI Airlink Capacity Modulation Enabled Modules

ACM - XPIC 18.18 Mbps QPSK CTR 8540 RACx2 only
ACM - XPIC 34.99 Mbps 16QAM CTR 8540 RACx2 only
27.5 / 28.0 / 29.65 MHz ETSI Airlink Capacity Modulation Enabled Modules
White Paper

White Paper
3.75 MHz ANSI Airlink Capacity Modulation Enabled Modules




White Paper



White Paper


White Paper
CTR 8300 Release Features and Functionality Supported
Hardware
CTI-311-001 CTR 8311 (version 1) with RAC 1x, 2 GE, 2 SFP, 16E1/DS1
Software and Feature Licenses

Includes : System Admin and Operation, CLI, Web GUI, SNMP management,
OSPF
CZL-63300v2 CTR 8300v2 Series R3 BASE Software License
Includes : System Admin and Operation, CLI, Web GUI, SNMP management,
OSPF
CZL-63301 CTR 8300 Series R3 BASE + TDM Software License
CZL-63301v2 CTR 8300v2 Series R3 BASE + TDM Software License
Includes BASE plus : VLAN, Q-in-Q, E-OAM, QoS, ERPS, SYNCE,MEF-8
Pseudowire and OSPF
CZL-63310v2 CTR 8300v2 Series R3 CARRIER ETHERNET Software License
Includes BASE plus : VLAN, Q-in-Q, E-OAM, QoS, ERPS, SYNCE,MEF-8
Pseudowire and OSPF
CZG-63R00 CTR 8300 Series R2 to R3 BASE Software License Upgrade
Includes : System Admin and Operation, CLI, CTR Portal, SNMP management,
OSPF
CZG-63R10 CTR 8300 Series R2 to R3 CARRIER ETHERNET Software License Upgrade
Includes BASE plus : VLAN, Q-in-Q, E-OAM, QoS, ERPS, SYNCE, MEF-8
Pseudowire and OSPF
CZF-639xx CTR ODU Airlink Capacity Licenses
CZF-63010 CTR 8300 Flexible Power Mode (One license per ODU600)
CZF-63016 CTR 8300 XPIC (One license per chassis – CTR 8312 only)
CZF-63018 CTR 8300 Adaptive Modulation up to 256 QAM support (One license per ODU)
CZF-63020 CTR 8300 Adaptive Modulation up to 1024 QAM support (One license per ODU)
CZF-63030 CTR 8300 Payload Encryption (One license per CTR 8312v2 only)
CZF-63040 CTR 8300v2 L1 Link Aggregation (One license per CTR 8312v2 only)
CZF-63045 CTR 8300 L1 Link Aggregation Lite (One license per chassis - CTR 8312v1/v2)
CZF-63050 CTR 8300 Secure Authentication Client, Centralized Usr Acct Mgmt (One
License Per Chassis)
CZF-63060 CTR 8300 Secure Management (One License Per Chassis)
CZF-63080 CTR 8300 Enable Eight TDM ports
CZF-63085 CTR 8300 Enable Sixteen TDM ports
CZF-63100 CTR 8300v2 1588v2 PTP Transparent Clock (One License per Chassis)
White Paper
Radio Functionality and ODU Interoperability with RAC interface

ETSI Channel 3.5, 7, 13.75 / 14, 27.5 / 28 / 29.65, 40 and 55 / 56 MHz channels (refer to
Support modem profile section for full detail on all profiles available in this release)
ANSI Channel 3.75, 5, 10, 20, 25, 30, 40, 50, 60 and 80 MHz channels (refer to modem profile
Support section for full detail on all profiles available in this release)
Modulations QPSK, 16, 32, 64, 128, 256, 512 & 1024 QAM – Both ACM and Fixed modes
Includes ATPC operation
XPIC / CCDP ETSI Channels –13.75 / 14, 27.5 / 28 / 29.65, 40 and 55 / 56 MHz
ANSI Channels – 25, 30, 40, 50, 60 and 80 MHz
Operation on CTR 8312 only supported for 2+0 with ACM & ATPC. Note that
when used with 2+0 L1LA-Lite ACM is not supported.
1+1 ODU Protection CTR 8312 supports two IF connected ODUs for 1+1 Protection
Typically <50ms switching for ODU failure
ODU 600 Bands 5, 5.8, 6, 7, 8, 10, 11, 13, 15, 18, 23, 26, 28, 32, 38 & 42 GHz - Up to 1024 QAM
ODU 600sp 6, 7, 8, 11, 13, 15, 18, 23, 26, 28, 32 & 38 GHz – Up to 512 QAM
ODU 300hp Bands 5, 6, 7, 8, 10, 11, 13, 15, 18, 23, 26, 28, 32 & 38 GHz – Up to 256 QAM only
ODU 600v2 L6, U6, 7, 8, 10, 11, 13, 15, 18 GHz – Up to 1024 QAM
IRU 600v3 L6, U6 & 11GHz bands up to 1024QAM
Note: Operation with EHP has some limitations
IRU 600v4 L6, U6, FCC7 (upper portion of U6 RFU) and 11GHz HP and EHP bands up to
1024QAM
IFG & Pre Headers Optimization of OTA throughput by compressing the inter frame gap and
preamble
L1LA Lite Layer One Link Aggregation-Lite provides a mechanism to aggregate the two
radio paths on a CTR8312 together to provide a higher capacity link. L1LA-Lite
requires Static profiles of equal capacity and ACM cannot be enabled.
Member ports may be XPIC capable.
Both CTR8300 and 8300v2 provide support for this feature
L1LA 2+0 Layer One Link Aggregation, consisting of a single L1LA group with 2
member ports. Member ports may be ACM and XPIC capable.
CTR 8312v2 Only
2+0 OTA Interoperability with CTR 8540 RACx2 is now supported
Payload Encryption AES256 bit over-the-air Encryption is supported on the CTR 8300v2 & CTR
8380v2 along with the following functionality:
• Protected links
• L1LA, ACM & XPIC
10/100 Base-T on Support 10-BaseT and 100-BaseT operation on CTR8300V2 with Apache
the Electrical SFP SE1000000SYNERXX electrical SFP
(CTR 8300v2 Only)
PCR Paperless Chart Recorder
White Paper
Carrier Ethernet Functionality
Ethernet Switching Switching support has been validated up to 4 Gbps with this release
MAC Learning of up to 2000 addresses (256 are reserved for Static MAC
addresses with the remaining 1744 for dynamic MAC learning)
VLANs 802.1Q VLAN Tag and untag, filtering / membership per customer and provider
tag
802.1ad Provider Bridging (QinQ), VLAN translation
Support for 4095 VLANs with up to 250 configured per CTR
QoS – 8 Queues Classification : VLAN, DSCP or Port based (MPLS EXP excluded)
Scheduling : Strict, RR, WRR, CIR/EIR, and Hybrid options of Strict-RR, Strict-
WRR and Strict-CIR/EIR. Supports up to 3 strict priority in Hybrid mode
Tail drop and WRED queuing, Configurable Tx Queue Buffers
Storm Control, Ingress Traffic Policing, 802.1p QoS Traffic remarking
Port mirroring (single destination)
Output Rate Limiting : Static on outgoing ports
Dynamic Shaping on RAC interfaces for hitless ACM control
Jumbo Frames MTU sizes from 64 to 10,000 byte supported
Sync-E Synchronous Ethernet is supported on all front panel Electrical Gig-E interfaces,
Optical SFPs. ESMC and SSMs are supported with fallback to internal Stratum-3
clock.
E1 ports can also be used as a Sync-E clock source. SSM is not supported over
E1 links.
T1 as a Sync-E source is not supported.
User configurable SSM/ESMC Quality Level output may also be set for clocks
running in Freerun and Holdover mode.
LAG Layer 2 Link Aggregation (802.1AX) on front ports, radio interfaces. Static and
LACP Dynamic LAG is supported in this release.
Note: LAG on radio interfaces must use fixed modulation member ports with
equal capacity. ACM cannot be enabled on radio interfaces in a LAG group. The
more efficient L1LA-Lite solution is recommended for RAC interfaces.
ERPS Ethernet Ring Protection compliant (G.8032) – Port Based and VLAN Based
Supports up to four concurrent ERP rings
ERPS over RAC radio links and front panel ports only
ECFM with OAM CCM period of 100ms, 10ms and 3.3ms with CCM offloading
Switching times for RAC/Radio failover accelerated to <50ms with CCM
offloading enabled (default setting)
OAM based network device switching <300ms
ERPS Sub-rings
RSTP & MSTP Rapid and Multiple Spanning Tree Protocol (IEEE 802.1W and 802.1S)
Ethernet OAM 802.1ag / Y.1731 CC, LB & LT, PD, PDV, LM.
802.3ah ETH-AIS & ETH-RDI
MEF 35 MEF35 PM 1 performance measurement functions (single ended delay and
single ended synthetic loss measurements)
PTP 1588v2 CTR supports agnostic transport of 1588v2 PTP packets with classification and
scheduling user configurable per QoS policy.
It is recommended that the highest priority be used for PTP to provide optimum
PDV performance.
PTP 1588v2 Transparent Clock (TC) is available on the CTR 8300v2 supports
interoperability with CTR 8540. This feature provides superior PTP clock
accuracy and is enabled via the new software feature license CZF-63100.
White Paper
Link Status Used to force an Ethernet port to shutdown at both ends of radio link in the event
Propagation (LSP) of a link failure, and to restore its operation when the link is re established.
Support for PB (PNP, CEP, CNP, PPNP) & CB bridge mode as local and
monitored port.
TDM Functionality
16 x E1 Standard unstructured MEF 8 efficient Ethernet Pseudowire to carry structure
agnostic TDM payload from the E1 interfaces to Ethernet interfaces. Supports up
to 16xE1 per CTR.
16 x T1 Standard unstructured MEF 8 efficient Ethernet Pseudowire to carry structure
agnostic TDM payload from T1 or to Ethernet interfaces. Supports up to 16xT1
per CTR.
Ethernet Diagnostics
Ethernet Utilisation Graphical display of Ethernet utilization via the Web GUI.
Graphing
Strong Security
Support for SNMPv3
SNMP v3
• Configuration of Source IP address
Mechanised Attack Prevention of multiple high speed failed login attempts (brute force attacks)
Prevention
HTTPS In strong security mode, the web server allows connections only over HTTPS
This feature facilitates
User Access • Local User Account management
• User authentication
Management
• User privilege level setting
• Capture and display of last login information
When strong security mode is enabled the following protocols are disabled:
• telnet
Removal of insecure • HTTP
management • SNMPv1/v2
protocols Note: Some customers may wish to run SNMPv2 even after entering strong
security mode. To support this requirement, re-enabling SNMPv1/v2 in strong
security mode is permitted.
Security events are captured via Secure Syslog functionality.
Secure Syslogs Access of Secure Syslogs is via authorized users only.
Login warning banners containing security notices that are configurable by the
Warning Banners
user. Support for independent pre-login and post-login banners.
Secure File Transfer Secure transfer of selected system files to or from the CTR.
Secure storage of encryption keys and certificates for various protocols (SSH,
Key Storage HTTPS, Payload Encryption, SNMPv3)
Weak ciphers are disabled when strong security is enabled.
Strong Ciphers Strong ciphers are enabled for all management protocols when a strong security
license is present.
Management of user sessions:
User Sessions • Configuration of session inactivity timeouts
• Configuration of the maximum number of concurrent sessions
White Paper
Access Control Lists Access Control Lists for IP
Interoperability
CTR 8540 The CTR 8300 series supports interoperability with the CTR 8540 fitted with
interoperability RAC 1x and RAC 2x in 1+0, 1+1, 2 x 1+0 and 2+0/XPIC configurations.
CTR Administration and Operation Functionality

AOS Aviat OS Software upgrade from CLI or Web Interface. Active and inactive
versions maintained for rollback after upgrade. No traffic impact during upload,
only on activation (outage on activation typically 2mins)
Licenses Feature and capacity licenses can be applied or upgraded to SD card S/N
(future releases will enable additional flexibility in allocating licenses)
Configuration Configurations can be saved and loaded, temporary changes reverted, revert to
factory defaults. Active configurations are stored on SD card and can be re-fitted
to another CTR chassis.
Management IPv4 addressing with an In-Band Management VLAN. Telnet or SSH access
Interface (SSH uses low level 56 bit cypher as part of BASE license – higher levels
enabled with Strong Security when released)
Console access through V.24 port for local CLI Interface
SNMPv2c / SNMPv3 ProVision or MIB interface support – Standard and Aviat proprietary MIBs
Alarm & Event and Alarm capture, time stamp and logging.
Performance Ethernet statistics (partial RMON 1), Radio performance statistics
Indications Front Panel LED indicators for main board and plug-in cards
Locate-ME function, when enabled, blinks the Aviat logo on the terminal front
panel
Date & Time Simple Network Time Protocol (SNTP V4) support as well as embedded real
time clock
• Four NTP Servers Configuration
Web UI The Web UI has been enhanced to provide:
• Remote syslog view
• SNTP configuration
o Four NTP Servers configuration
• Provider-Edge switch mode selection
• Routed NMS configuration
• SNMPv2 Configuration
Hostname The ability to set a name in the CLI that is displayed in the command prompt
TACACS+ TACACS client to allow CTR to authenticate with an external TACACS server
SSH Client Launch a SSH client from within the AOS CLI environment to connect to another
CTR terminal
OSPF OSPF is provided to enable Routed NMS compatibility and interoperability with
Eclipse equipment (See OSPF Functionality and Performance detail referenced
earlier in this document).
White Paper
CTR 8300 Functionality Not Included in this release
CTR 8300 Functionality that is not included or validated in this release

IRU 600v1 & v2 Operation with CTR 8311 and CTR 8312
STR 600 Operation with CTR 8311 and CTR 8312
Frequency Diversity For CTR 8312
Link Status Degraded mode - The local user port shuts down responding to decrease in
Propagation capacity of radio link
LAG as monitored port or local user port
Multi-hop LSP
Carrier Ethernet Features

OAM
Flow Control
Dying Gasp
QoS QoS Congestion Control for L3 traffic streams
White Paper
CTR 8300 Software Version Upgrade Compatibility
This release is compatible with the following releases of CTR 8300:
• 3.0.0(21.3069)
• 3.0.2(21.3211)
• 3.0.3(21.3265)
• 3.1.0(31.3266)
• 3.1.0(41.3363)
• 3.2.0(32.3614)
• 3.3.0(34.4070)
• 3.4.0(35.4269)
• 3.4.0(35.4435)
• 3.5.1(37.4745)
• 3.5.2(37.4705)
• 3.5.3(37.4676)
• 3.5.4(38.4742)
• 3.5.7(37.4814)
• 3.5.9(38.4819)
• 3.5.20(39.5084)
• 3.5.21(39.5293)
• 3.5.22(39.5392)
• 3.6.1(41.5670)
• 3.6.2(41.5714)
• 3.7.0(42.5860)
• 3.8.0(43.5950)
• 3.9.0(44.6088)
CTR 8300v2 Software Version Upgrade Compatibility

This release is compatible with the following releases of CTR 8300v2:
• 3.2.2(33.4082)
• 3.4.0(35.4269)
• 3.4.0(35.4435)
• 3.5.1(37.4745)
• 3.5.2(37.4705)
• 3.5.3(37.4676)
• 3.5.4(38.4742)
• 3.5.7(37.4814)
• 3.5.9(38.4819)
• 3.5.20(39.5084)
• 3.5.21(39.5293)
• 3.5.22(39.5392)
• 3.6.1(41.5670)
• 3.6.2(41.5714)
• 3.7.0(42.5860)
• 3.8.0(43.5950)
• 3.9.0(44.6088)
CTR 8300 Software Part Numbers

Product Part Number Version Build
CTR 8300 Customer Software 275-250427-006148 3.10.0 6148

CTR 8300v2 Customer 275-250432-006148 3.10.0 6148
Software
CTR 8300 ProVision Support

The new features in release 3.10.0 require ProVision Element Manager System software version
7.9.2 or later. Earlier releases of ProVision do not fully support release 3.10.0.
White Paper
CTR 8300 Hardware Supported

The following table details the hardware that is supported by this software and corresponding part
numbers.
Software Product Part Number Notes

CTR 8311v1 CTI-311-001
CTR 8312v1 CTI-312-001
CTR 8311v2 CTI-311-002
CTR 8312v2 CTI-312-002
CTR 8380v1 CTO-XXXX-XXX-001
CTR 8380v2 CTO-XXXX-XXX-002
ODU 300 HP EAH-xx-xxxx-xxx Limited to 256QAM
operation only
ODU 600 5-42 GHz EEH-05 to EEH-42
ODU 600 7/8 GHz Enhanced EEH-07 E / EEH-08 E
ODU 600sp 6-38 GHz EES-07 to -38 Limited to 512QAM
operation only
IRU600v3 L6, U6 & 11GHz EV/B/N1XX-XX-XX- Up to 1024QAM
300
ODU 600v2 ECH-FF-TTTT-RRR Up to 1024 QAM
FF= Frequency Band
TTTT = T-R Split
RRR = Revision
White Paper
CTR 8300 Hardware and Software Compatibility
The following tables list the minimum software version to be used with a version of hardware. A later
version of software can be used with an earlier version of hardware but not the reverse (e.g. you can
use 3.2.1 software with CTR 8311v1, but not 2.3.0 software with the CTR-8311v2. Details of the
hardware version are provided in the manufacturing details screen of the GUI or by using the “show
manufacturing-details” command in the CLI. The HSC number is the first 3 digits in the revision
number shown as 1 in the GUI and CLI screen captures below.
Hardware HSC Part Number Software Software

Version Part Number
CTI-311-001 CTR-8311 003 Refer hardware 2.3.0(14.2446) 275-250427-002446
CTI-311-002 CTR-8312v2 004 Refer hardware 3.2.1(33.4082) 275-250432-004082
CTI-312-001 CTR-8311 003 Refer hardware 2.3.0(14.2446) 275-250427-002446
CTI-312-002 CTR-8312v2 004 Refer hardware 3.2.1(33.4082) 275-250432-004082
Hardware HSC Part Number Software Software

Version Part Number
CTO-XXXX-XXX-001 CTR-8380 003 Refer hardware 3.1.1(44.3625) 275-250427-003625
CTO-XXXX-XXX-002 CTR-8380v2 004 Refer hardware 3.2.1(33.4082) 275-250432-004082
White Paper
CTR 8300 Profiles Supported

ACM - non-XPIC 3.93 Mbps QPSK CTR 8311 / CTR 8312
ACM - non-XPIC 9.79 Mbps 16QAM CTR 8311 / CTR 8312


ACM - XPIC 18.18 Mbps QPSK CTR 8312
ACM - XPIC 34.99 Mbps 16QAM CTR 8312
27.5 / 28.0 / 29.65 MHz ETSI Airlink Capacity Modulation Enabled Modules
White Paper

White Paper




White Paper

White Paper


White Paper
CTR 8540 and CTR 8300 Known Issues
The following table lists known issues in this release.
White Paper
Feature Ref Product Summary Details
ACL: L2 ACL does not block Configured L2 Access Control Lists do not block
ACL CSR-20522 8540
ECFM pdus ECFM PDUS on the specified VLAN.
The command 'modulation acm The command "modulation acm base 1024qam" is
8540, base 1024qam' is allowed, even permitted, even when there is no installed licence
ACM CSR-7990
8300 when there is no ACM1024 for the 1024 QAM feature. The command has no
license affect on the operation of the radio.
A rapidly changing alarm condition may lead to a
state where the Web user interface incorrectly
shows that there are no active alarms. In the
The count of active alarms and
situation where an alarm changes state more than
8540, the overall alarm status can be
Alarm CSR-8190 five times during a 30 second period, its logging is
8300 incorrectly displayed when
suspended until the alarm condition remains
alarm logging is suspended
stable for 30 seconds. In this suspended period,
the count of active alarms and the overall alarm
status of the unit may be incorrectly displayed.
An alarm may take 3 to 4 minutes to be raised after
An alarm may take 3 to 4
a front panel interface is enabled and no cable is
minutes to be raised after a
Alarm CSR-8822 8540 plugged in. The delay only exists on front panel
front panel interface is enabled
interfaces (0/1 to 0/8), the alarm is raised
and no cable is plugged in
immediately for SFP or PoE interfaces.
In rare cases an active alarm may not be displayed
CTR Portal may not show in the in the CTR Portal alarm screen if the alarm has not
Alarm CSR-9903 8300 alarms screen an alarm shown been mapped to an entity.
as active on the status bar The workaround is to use the Event Log in CTR
Portal to locate the raised alarm.
The SFP interface's 'module missing' alarm is
Alarms: Module missing alarm
8540, suspended when the unit is started with a saved
Alarm CSR-10357 gets suspended when starting
8300 configuration that expected an SFP, and none is
up with a missing SFP
fitted.
During initial configuration or after a system reset,
Factory Tx Mute Alarm not
the Factory Tx Mute alarm does not get raised. If a
raised during initial
Alarm CSR-18924 8540 radio link is down (The Tx Path Lost and/or Traffic
configuration or after system
Path Down alarm is active), check that the factory
restart
mute is not enabled.
BFD : Removal of a BFD
When a BFD session associated with a protected
session (without using "bfd
RSVP-TE tunnel is removed via configuration, the
params sess-admin-status
tunnel will switch to protecting path and protection
BFD CSR-16167 8540 stop") causes a switch to the
functionality on that tunnel will not work from that
protecting tunnel, but no further
point onward. If protection without BFD is desired,
tunnel protection switching will
it is recommended to reconfigure the tunnel.
occur
When deleting a BFD session over an MPLS
BFD : Traffic is dropped for a
tunnel, traffic can get dropped for several minutes
few minutes after deleting a
BFD CSR-17479 8540 and then recovered. To prevent this situation, set
BFD session over an MPLS
the admin status of the BFD session to down
tunnel
before deleting it.
L3VPN: BGP Stuck in Connect
BGP CSR-19920 8540 state after link flaps when using On-demand mode is not supported in this release.
on-demand mode
In case of route-map being used for redistribution
under BGP context and if the user removes
redistribution for one type of route-types along
with the route-map (no redistribute <route-type>
route-map <rmap-name>), this removes the route-
Route-map configuration
map from redistribution of all the other route-types
disappears from all redistribute
under the BGP context.
BGP CSR-28580 8540 commands when a redistribute
To avoid removal of route-map from all other
CLI command is removed under
redistribute command, it is recommended to use
BGP context
the command no redistribute <route-type> under
the BGP context to remove the redistribute of
specific route-type without affecting the removal of
route-map from other route types
White Paper
When stopping and then restarting an Optical SFP
interface using the "shutdown" & "no shutdown"
commands, the interface will cease to pass traffic
if these commands have been entered on the same
CLI line e.g.:
aos(congig-if)# shutdown; mtu 10000; no

No customer traffic through
shutdown
Optical SFP ports if the "shut"
8540,
CLI CSR-7410 and "no shut" commands are
8300 To recover from this, the user should reissue the
entered in the same line on the
"no shutdown" command e.g.:
CLI
aos(congig-if)# no shutdown
This issue can be avoided all together by entering

the commands on separate lines e.g.:
aos(congig-if)# shutdown
aos(congig-if)# mtu 10000
aos(congig-if)# no shutdown
The CLI command "clear line vty all" will cause all
When using the “clear line vty subsequent CLI sessions to be unable to execute
8540, all” command to close all open commands.
CLI CSR-9934
8300 CLI connections, the CLI
session stops This CLI command should not be used. To recover
from this issue the device must be power cycled.
The diagnostic xpd-on-bnc command is not
XPIC - The cross polarised functional, and should not be used. This
8540, interference level on the ODU diagnostic outputs a voltage level on the ODU BNC
CLI CSR-10091
8300 BNC connector is not supported that is proportional to the cross polarised
on all ODU types interference level in XPIC systems. It is not
working.
Some commands executed via the CLI will lock out
other NMS sessions while they are executing. For
CLI: Commands that take a long
8540, example, executing and ECFM ping or trace link
CLI CSR-11719 time may cause other GUI and
8300 which may take tens of seconds to run will cause
CLI sessions to wait
other CLI sessions and GUI sessions to pause
until the ECFM operation has completed.
The CLI accepts the input "r" as a shortcut for the
"reload" command. This command reboots the
Entering "r" in CLI causes unit without a confirmation prompt. A reboot will
CLI CSR-12671 8540 reload without user disrupt customer traffic.
confirmation
CLI users must be careful not to accidentally
trigger a reboot in this way.
An error message may be generated when clearing
CLI: Executing the command
QoS queue statistic counters with radio protection
clear qos queue-stats system
8540, enabled. The statistic counters will be reset as
CLI CSR-13001 provides ambiguous error
8300 expected, and the traffic or other settings will not
information. However queue
be affected. This issue does not occur if protection
statistics are cleared
is disabled.
The radio link may fail if the modulation has been
set to an invalid value via command line interface,
From CLI RF Modulation 1024
8540, i.e. modulation set to 1024QAM-HG on ODU300.
CLI CSR-13100 QAM-HG can be applied for
8300 Always use the correct modulation in CLI or
ODU300
configure it via CTR Portal, and recover by
reloading both CTRs in the radio link.
Whilst configuring the QoS settings, the priority
map ID range allows entry of values 0-65535.
However, an ID of 0 is not valid and should not be
8540, CLI : Zero Priority Map value is
CLI CSR-13145 used as it creates an invalid entry. The following
8300 allowed by CLI
command line is invalid and should not be used;
aos(config-cls-map)# match access-group priority-
map 0.
Diagnostics status displayed by CLI consoles
Diagnostics reported in CLI as sometimes do not match the actual diagnostics
CLI CSR-13343 8540 being active/inactive are not status implemented on the cards. For example,
actually active/inactive diagnostics reported in CLI as being
active/inactive may not actually be active/inactive.
White Paper
Issuing a 'shutdown' command on a radio interface
only shuts down that interface from a traffic /
Ethernet point of view, and disables any LEDs and
alarms associated with that interface.
Radio Interface CLI: shutting
8540, down radio interface does not This command does not affect the physical link.
CLI CSR-13407
8300 mute RFU, no warning This means that a connected RFU will not be
displayed muted and appropriate precautions must continue
to be taken.
No warning message is displayed in the CLI under

this scenario.
The CLI supports 8 concurrent Telnet CLI
sessions. If the user tries to open more than 8
Telnet-based CLI sessions, the 9th session will be
rejected, but an event log entry is not generated to
Event log: There is no event log
indicate that the maximum number of Telnet
CLI CSR-15055 8540 msg, if there is too many telnet
sessions are open.
CLI sessions
However, the behaviour is different with SSH CLI
sessions. If the maximum number of SSH sessions
are exceeded then an event log entry is generated.
The Speed/Configuration of SFP ports may be
inaccurate or inconsistent when there is no SFP
Different display of speed when
CLI CSR-18557 8540 module present. This does not affect operation of
speed "auto" is configured
the device, and the correct speed will be disaplyed
once an SFP module is inserted.
When resetting the configuration to factory
defaults without setting the revert timer, the
following error is displayed: "% Cannot perform
factory defaults load operation. Please check
'Configuration Load Information'".
Revert timer requirement is not
8540, advised on issuing the
Config CSR-4196 The error does not explicitly inform the user that
8300 command 'config load factory-
the revert timer needs to be set.
defaults' without a timer setting
To avoid this error, set the revert timer when
resetting the configuration by using the command
"config load factory-defaults revert-timer
<number>"
The command 'switchport trunk allowed vlan
exclude' is intended to allow a trunk port to be
8540, "switchport trunk allowed vlan"
Config CSR-13528 excluded from a particular VLAN (Virtual LAN). In
8300 command is not supported
release 3.0, this feature is not supported, as it is
not saved in the configuration file.
CTR Portal: The displayed
8540, In the CTR Portal / Radio Link Performance page,
CTR Portal CSR-6599 Receive Signal Level may take
8300 the RSL value can take up to 2 seconds to update.
up to 2 seconds to update
The CTR Portal, Radio Link History page may error
CTR Portal: Radio Link History or stop responding if left for more than 1-2 hours.
8540, page can become unaccessible This does not affect the device, only CTR Portal
CTR Portal CSR-8218
8300 after running for more than 1 to running in the web browser. This issue may be
2 hours resolved by refreshing the page in the web
browser.
CTR Portal Interface Statistics page: When using
the capture feature, "N/A" may be displayed in
CTR Portal: Interface statistics place of a value if the counter being monitored
8540,
CTR Portal CSR-8257 may be shown as N/A in wraps around, or if it has been cleared to zero via
8300
captured mode the clear interfaces command in CLI.
Stopping and restarting the statistics capture will
resolve the issue.
In the CTR Portal Radio Configuration page, the
list of selectable bandwidths is not limited to the
connected RFU's supported bandwidths. If an
CTR Portal: Radio configuration
8540, unsupported bandwidth is selected, the Tx
CTR Portal CSR-8745 bandwidths are not correctly
8300 Frequency and Rx Frequency input fields will show
limited by the connected RFU
an "out of range" error, with a minimum allowed
Frequency larger than the maximum allowed
Frequency.
CTR Portal may not display The CTR Portal display of radio link performance
8540,
CTR Portal CSR-9181 radio link performance data in data in the daily view may indicate there is no data
8300
the daily view for the interface, or display an empty graph.
Web-GUI: "Unsaved The CTR Portal Network Synchronization pages do
configuration changes" status not trigger an "Unsaved configuration changes"
CTR Portal CSR-11403 8300 not reflected in System warning after applying configuration changes.
Activities drop-down on Configuration has to be saved by explicit user-
Network Sync Sources page. initiated action.
White Paper
The CTR Portal Interface Statistics page displays
CSR1000: Web UI does not map
MTU as 0 for loopback interfaces. Use the CLI
CTR Portal CSR-12283 8540 the correct MTU of loopback
command "show interface mtu" to view loopback
interface
interface MTU.
After configuring SyncE in CTR Portal, the
SyncE/WebGUI: System activity
customer may not see the information "Unsaved
does not indicate ("Unsaved
configuration changes". The system is failing to
CTR Portal CSR-12474 8300 configuration changes flag is
report the change of configuration status. Users
not raised") when syncE
can still force the system to save the
configuration is changed
configuration.
The CTR Portal classification page may show
CTR Portal - removed or "undefined" in place of an interface name, in a QoS
aggregated interface that has classification membership. This is caused by
CTR Portal CSR-12507 8540 QoS configured shows aggregating or removing an interface while still
incorrectly on classification having QoS classification configured.
page Workaround is to delete the QoS classification for
an interface prior to removing or aggregating.
If the CIR (Committed Information Rate) or EIR
QoS Scheduling: GUI shows
(Excess Information Rate) value entered via CTR
error when trying to set a CIR or
CTR Portal CSR-12742 8540 Portal is not divisible by 8 then an error is
EIR value that is not divisible by
reported, however the bit rate is still applied
8
rounded up to the nearest 8 bit value.
In CTR Portal, the VLAN page may become
sluggish when displaying a large number of
CTR Portal: VLAN page
8540, configured VLANs, approximately over 150. The
CTR Portal CSR-12801 becomes sluggish with large
8300 actual number of VLANs to trigger this will vary
amount of VLANs
depending on the user's computer. The CLI can be
used to configure VLANs without this limitation.
CTR Portal statistics capture is held in Portal PC
CTR Portal - Statistics capture
CTR Portal CSR-12994 8540 memory, which may limit the capture period to less
duration limit
than 48 hours.
The device graphic displayed on the CTR Portal
Equipment page will render an SFP (Small Form-
CTR Portal - Equipment page Factor Pluggable) transceiver module if the
8540,
CTR Portal CSR-13008 renderers SFP regardless of if a interface is enabled, regardless of whether an SFP
8300
SFP module is inserted module is physically present.
Also note the the SFP module rendered does not
take into account the type of SFP module.
When issuing a software upload via the Web GUI, if
the session timer is set to a value shorter than the
time taken to complete a software upload, the user
will be logged out of the Web GUI before the
8540,
GUI session times-out during upload finishes. The software upload will
CTR Portal CSR-26680 8300,
software loading successfully continue in the background.
8300v2
This is different behaviour to previous releases of
software where there was no session timeout so
the user would only get logged out once the
upload was complete and the unit restarted.
When using Provision for network management, at
times Provision can report Event Collection Failed
alarm. This is due to a momentary communication
8540,
Event Collection failed error loss in the Provision with the CTR HTTP/HTTPS
CTR Portal CSR-28381 8300,
appearing in Provision service.
8300v2
This is a non-service impacting alarm and will
clear within a minute. The event collection will
resume normally after the alarm has cleared.
ECFM (Ethernet Connectivity Fault Management)
Ethernet CFM Statistics not
received and sent Continuity Check Messages
ECFM CSR-3910 8540 increasing when CC offload
statistics counters are not increasing in Continuity
enabled
Check Message Offload mode.
traceroute operations may fail if the Traceroute
ECFM: Traceroute can fail if the
cache is cleared during trace route operation. The
ECFM CSR-11651 8540 traceroute cache is cleared
ECFM Y.1731 Traceroute hold time determines
during the trace operation
when the cache is cleared, so this can be modified
to reduce the impact of the behaviour.
configured for 100Hz or 300Hz CCMs (Continuity
ECFM: Errors and indeterminate Check Messages) may lead to errors and
8540,
ECFM CSR-13362 behaviour if 300Hz CCMs are connectivity issues if hardware offloading is
8300
configured WITHOUT Offloading disabled. It is highly recommended that hardware
offloading is enabled if 100Hz or 300Hz CCMs are
configured.
While configuring Y.1731 performance monitoring,
Up MEP: OAM PM sessions
the user must first configure continuity check
ECFM CSR-16830 8540 cannot be created without
(ETH-CC) before configuring Y.1731 frame loss/
creating CCM sessions first
frame delay measurements.
White Paper
If an Ethernet ping command is executed without
the 'count' option, the output display will be
stopped upon encountering a failed LBR (Loop
Back Reply), and any further information will not
Y.1731: Ethernet ping executed
be displayed.
ECFM CSR-17207 8540 without the "count" option exits
on first lost LBR
There are two options to resolve this;
1) Specify the count of LBM's to be transmitted.
2) Increase the value of the Loop Back Deadline
(LBDeadline) timer.
If a down MEP (Maintenance Association End
Point) is configured on an interface that is a
member port of a static LAG (Link Aggregation)
group, by removing this interface from the LAG
group, the remote end MAC address could not be
ECFM: VLAN unaware MEP - learned.
Remote MAC is not learnt after
ECFM CSR-17220 8540
removal of channel-group from This can be resolved by either of the following
port-channel member interface steps;
1. Add the interface back to the LAG group, and
the remote mac address will be learned.
2. Re-configure the down MEP on the interface that
is removed from the LAG group, and the remote
mac address will be learned.
Enabling the port mirroring diagnostic function
ECFM with Port mirroring may when ECFM is configured may result in an
ECFM CSR-18530 8540 result in unexpected device unexpected device reset. To avoid this potential
reset issue, port mirroring should not be used in
combination with ECFM.
CTR does not support using offloaded and non-
offloaded maintenance end points (MEPs)
together. Having such combinations may cause
CTR crashes when using ECFM
unwanted behaviour and in some cases may lead
ECFM CSR-20649 8300 non-offloaded and offloaded
to system failure.
mode together
When using ECFM, customers are advised to use
offloaded mode (default) for accuracy and better
performance.
The CLI allows RSTP (Rapid Spanning Tree
Protocol) & MSTP (Multiple Spanning Tree
Protocol) to be enabled on an interface that
already have ERPS (Ethernet Ring Protection
Switching) or ELPS (Ethernet Linear Protection
ERPS: RSTP & MSTP can be
8540, Switching) enabled. This is an invalid
ERPS CSR-5741 enabled on ERPS/ELPS enabled
8300 configuration and the user should avoid setting
interfaces
the system in this state.
The correct method is to disable ERPS/ELPS

before enabling RSTP or MSTP on a particular
interface.
STP (Spanning Tree Protocol) will not work
properly if it is enabled on ports that were
previously configured to use ERPS (Ethernet Ring
ERPS: MSTP state is incorrect Protection Switching) loop avoidance protocol.
ERPS CSR-10625 8540 for ring ports after disabling To ensure it operates correctly, disable and enable
ERPS the ports that were previously configured as ring
ports. Alternately, rebooting the CTR after saving
the configuration will allow to STP to work
correctly.
ERPS (Ethernet Ring Protection Switching) switch
ERPS: It takes more than 50 ms
ERPS CSR-12067 8540 time is sometimes is 60-70ms, which is slightly
to switch to protection
higher than the intended maximum value of 50ms.
ERPS: The switching time is
On rare occasions the ERPS switching time may
more than 500ms when failing
ERPS CSR-24737 8540 exceed 500ms when the failing port is on the RPL
ports on RPL Owner configured
owner.
with WTR
When an Ethernet Ring is in the Pending state,
executing command "aps clear" may not able to
set the RPL Owner port back to the "Blocked"
ERPS: The RPL interface is not state.
ERPS CSR-24747 8540 blocked after aps clear
operation (intermittent) Since the ring status will still be in the IDLE state
as expected and RPL Neighbour will be in
"Blocked" state, there should not be any traffic
impact.
White Paper
When connecting two CTR 8540s through WTM
3300 by POE cards, if both ICF(by command "icf")
PoE/WTM 3300: Able to and rate limit(by command "power inline auto max
configure rate limit in PoE ports <milliwatts>") are configured, traffic loss may be
ICF CSR-12544 8540
when ICF is enabled; Affects observed for high priority traffic.
data traffic
Please avoid enabling and configuring rate limit
when ICF is enabled.
When connecting two CTR 8540 devices through
the WTM3300 unit by PoE (Power over Ethernet)
cards, if the link between WTM3300s is down, you
WTM ICF packets indicate "link may not be able to connect to WTMs to manage
down". Result: Unable to them and the status of the PoE cards would be
ICF CSR-13184 8540
manage WTM when RF link is observed as "down".
down.
To manage the WTM modules when PoE link
status is "down", turn off ICF (Internal Control
Frame). This makes WTM accessible.
Deleting an IP route or changing the management
IP address may produce an error on the CLI.
Example:
aos(config)# no ip route 0.0.0.0 0.0.0.0

11.214.76.145
8540, Deleting an IP route produces
IPv4 CSR-5071 RTNETLINK answers: No such process
8300 an error message on console
Error deleting IP route: cmd = 'ip route del
0.0.0.0/0.0.0.0 via 11.214.76.145'
If the error is seen, it will be displayed only on the

first change.
There is no impact on the system functionality
when this happens.
IP fragmentation is supported by the software. But
IP packets that need
8540, it is still recommended to keep the MTU (Maximum
IPv4 CSR-12193 fragmenting are forwarded to
8300 Transmission Unit) setting consistent across
the host
customers' networks to prevent fragmentation.
Failure to create static ARP In order to configure a static ARP entry for a VLAN
entry for vlan ip interface if IP Address, a static Mac must first be configured
IPv4 CSR-21512 8540
static MAC is not previously first. If this is not done, then the static ARP entry
configured will fail configuration.
When a CTR device is reloaded, the LSP sequence
number is not incremented.
ISIS LSP sequence number not This has no effect on operation between CTR
ISIS CSR-17609 8540
incremented after device reload units, but may present an issue with ISIS
convergence when interoperating between CTR
and equipment from other vendors.
On a network with more than 2000 routes, a
ISIS: System instability while
CTR8540 device running IS-IS might reboot if a
ISIS CSR-22319 8540 doing interface flap with more
large number of network link failures happen in a
than 2000 routes
short span of time.
The LSP (Label Switched Path) sequence number
field in the "show ip isiste database" command
output may not show the correct sequence number
ISIS-TE: TE database shows corresponding to the LSP entry shown in the
ISIS-TE CSR-15726 8540
invalid LSP sequence number "show ip isis database" output. This does not
affect the operation of the ISIS-TE ( Intermediate
System to Intermediate System-Traffic
Engineering) protocol.
In CTR8540, 'no int l1la' command is not
supported. Use 'no l1la <instance> group'
L1LA: 'no int l1la' command is
L1LA CSR-10207 8540 command instead of 'no int l1la <instance>' to
not supported
remove an L1LA (Layer 1 Link Aggregation)
interface.
When an L1LA (Layer 1 Link Aggregation) link is
L1LA: Link failure alarm
brought up from a saved configuration file, the link
resulting from a degraded
failure alarms for this L1LA interface will no longer
L1LA CSR-10257 8540 member port is not raised after
be raised. However any failures in the radio
the terminal configuration is
interfaces belonging to an L1LA group can be
restored
identified via the radio link failure alarms.
When configuring an invalid L1LA (Layer 1 Link
L1LA: interface number error Aggregation) group number from the CLI, the error
L1LA CSR-10343 8540 when creating an L1LA instance message reports an incorrect range of valid group
greater than 2 number values. Please note that only group
numbers in the range of [1 - 2] are valid for L1LA.
White Paper
No help exists in the CLI for L1LA commands. For
example 'no l1la'.
L1LA: Incorrect help text for 'no
L1LA CSR-10344 8540 For help setting up L1LA, refer to the Radio Link
l1la ?' command
Configuration section of the Getting Started
Configuration Guide
example 'ports'.
L1LA: 'ports' is not listed as
help in 'no ?' command
Configuration Guide
example 'no interface'.
L1LA: 'no interface l?' does not
list L1LA as an option
Configuration Guide
L1LA: 'show interfaces l' does No help exists in the CLI for L1LA commands. For
not autocomplete when example 'show interfaces'.
L1LA CSR-10351 8540 pressing tab and 'show For help setting up L1LA, refer to the Radio Link
interfaces l?' gives 'Invalid Configuration section of the Getting Started
Command' Configuration Guide
L1LA: 'Interface range radio 4/1- The CLI command 'Interface range radio x/y-z' is
2' command is not usable when not usable when radio x/y-x is part of an L1LA
L1LA CSR-10359 8540
radio 4/1-2 are part of an L1LA (Layer 1 Link Aggregation) group. The interfaces
group have to be configured individually.
No help exists in the CLI for L1LA (Layer 1 Link
L1lA: 'ports add l?' is an Invalid Aggregation) commands. For example 'ports add'.
L1LA CSR-10360 8540 Command and 'ports add For help setting up L1LA, refer to the Radio Link
l<TAB>' does not auto-complete Configuration section of the Getting Started
Configuration Guide
No help exists in the CLI for L1LA (Layer 1 Link
Aggregation) commands. For example 'ports add'.
L1LA: No help text for 'ports
add l1la ?' and 'no ports l1la ?'
Configuration Guide
L1LA: Configuring MTU of a It is not possible to set an MTU on a radio interface
L1LA CSR-10381 8540 radio interface results in "Fatal that is part of an L1LA (Layer 1 Link Aggregation)
Error: Command Failed" group.
When changing from a single L1LA (Layer 1 Link
Aggregation) group configuration to a two group
L1LA: Resources not released
configuration, it is advised that the existing L1LA
L1LA CSR-11013 8540 when changing from single to
group first be removed and re-created. This will
two-group configuration
release any resources required for a two group
configuration to be created.
The CTR supports group operations on interface
ranges only for ranges specified in
slot/startInterface-endInterface format.
Eg-
{code}
CLI gets stuck in if-range
aos# interface range gigabitethernet 0/2-6
context when "interface range"
L1LA CSR-11939 8540 or aos# interface range radio 3/1-2
command is used without
{code}
actually specifying a range
For any other range, the CLI may go into an
unresponsive state and ignore commands.
Logging out and logging back in will restore
correct operation.
When configuring L1LA (Layer 1 Link Aggregation)
L1LA: one of interface in group 8+0, one of radio interfaces in the group may not
L1LA CSR-12340 8540
is down come up into an active state. The workaround is to
reload the unit.
The CLI prompt may be changed from "aos(config-
IP: CLI prompt changes from l1la)#" to "aos(config-if)#" after enabling l1la port
"config-l1la" to "config-if" when as a non-switchport.
L1LA CSR-12790 8540
changing interface l1la to routed
(IP) port There are no other side effects rather than the
prompt itself.
In some circumstances an L1LA group with a large
L1LA: When modulation is number of interfaces may go down if multiple radio
L1LA CSR-13275 8540 changed from QPSK, L1LA link modulation settings are changed at the same
interface may go down time. To fix, change the modulation settings again,
or save the config and reboot the board.
White Paper
With full L1LA protection (4+4) configured and
after a reload, occasionally the L1LA interface will
L1LA with protection (4+4):
not be brought up successfully and the traffic will
Traffic not restored after
L1LA CSR-17329 8540 be blocked.
configuration reload,
intermittent (10% failure rate)
This situation can be resolved by a reload or
power cycle.
L1LA on PoE: high priority
High priority frames may be dropped when one of
L1LA CSR-27467 8540 frames dropped when one of
L1LA members on PoE interfaces has bit errors.
L1LA members has BER
In some rare cases, even after the L1LA group has
L1LA warning persists even
been removed, some of the L1LA alarms for
L1LA CSR-28557 8540 when l1la removed from
member suspension would persist on the device.
configuration
These alarms will be cleared upon a reload.
When L1LA (Layer 1 Link Aggregation) Lite is
L1LA-Lite capacity on slave disabled, any licensed capacity previously
L1LA Lite CSR-10295 8300 radio ports is not restored after assigned to each of the individual radio interfaces
disabling L1LA-Lite is not automatically restored and must be
manually re-assigned.
L1LA-Lite: high priority packets
may be dropped momentarily When a degraded L1LA-lite link is restored to full
L1LA Lite CSR-10462 8300 while switching between a operation it is possible that a small number of high
degraded link (single link) and a priority packets will be dropped.
fully working link (both links up)
L1LA (Layer 1 Link Aggregation) Lite mode can
only be used to aggregate radio links where the
L1LA-Lite configuration is not
L1LA Lite CSR-10770 8300 modulation is fixed. Aggregation of links
supported with ACM profiles
configured in ACM (Adaptive Coding and
Modulation) mode is not supported at this time.
For CTR8300 L1LA (Layer 1 Link Aggregation) Lite
L1LA: Limitation on Jumbo mode, a maximum frame size limitation of 5K bytes
L1LA Lite CSR-11996 8300
Frames for L1LA Lite is in place. Frames larger than this may be
dropped.
After configuring MPLS and VPLS, an attempt to
LDP-TLDP-L2VPN : Changing
change bridge mode from Customer to Provider-
the Bridge-mode from Customer
L2VPN CSR-17499 8540 Edge bridge creates an internal error. The
to Provider-edge bridge creates
recommended procedure is to change the bridge
error
mode before configuring MPLS and VPLS settings.
When traceroute is performed over an L3 MPLS
L3VPN: The egress PE router is
L3VPN CSR-19784 8540 VPN network, the resultant output does not display
not shown in traceroute
the egress PE router.
The status for a port-channel with LACP (Link
Aggregation Control Protocol) enabled may be
LACP: unnegotiated members indicated as up even if LACP is not running on the
LACP CSR-12226 8540
are up receiving end. Expected behaviour would be that
ports are up only after the link state has been
negotiated.
Choosing dest-l4-port or src-l4-port as the load-
balancing policy for a LAG (Link Aggregation
Group) port-channel will cause a WDDI (WinPath
LACP: WDDI BUS ERROR with Device Driver Interface) bus error, and the CTR will
LACP CSR-14656 8540
l4-port load-balance reboot.
Work-around is to instead use a MAC or IP based

load balancing policy for the port channel
Packet and Octet counters for port-channels may
LAG: Interface counters for not update correctly when the port-channel has a
port-channel do not increment PoE or RAC port in the channel and one port is
LAG CSR-10110 8540
correctly if one of the member degraded. The counters for the individual PoE and
ports is degraded RAC port are not affected and will reflect the
correct counts.
LAG (PB): Unable to pass traffic
In PEB (Provider Edge Bridge) mode, it is required
on LAG in PB mode if LAG is
LAG CSR-11126 8300 that PB bridge mode is configured prior to setting
configured before changing to
up a Link Aggregation Group.
PB mode
In Provider Edge Bridge mode, an ECFM (Ethernet
Connectivity Fault Management) CCM (Continuity
Check Message) session on a Port-Channel LAG
LAG,PB: CCM sessions on LAG (Link Aggregation Group) does not establish, if
LAG CSR-12501 8540 interfaces are down until the this is the initial configuration following a power
interface is restarted cycle after loading (resetting) factory defaults. The
workaround is to set the Port-Channel interface
administration status down and up again, or to
configure save and reload.
White Paper
The CTR device supports the following scheduling
algorithms over the LAG (Link Aggregation Group)
LAG/QoS: Hybrid scheduler
interface.
algorithms (Strict-WRR, Strict-
LAG CSR-13146 8540 1. Strict Priority 2. Weighted Round Robin and
WFQ and Strict-RR) are not
3.Round Robin.
supported over LAG interface
Other hybrid scheduling algorithms are currently
not supported for the LAG interface.
Individual member ports may still exist in a VLAN
(Virtual LAN) setting even if they have been
EtherChannel: Individual configured into a port-channel. (A port-channel
member ports which are part of does not inherit the VLAN membership of its
LAG CSR-13166 8540 VLAN may not be removed member ports. Hence when a port is aggregated
when they are bundled into Port into a port channel port, it should be removed from
Channel the membership of the specific VLAN). Manually
removing affected member ports from the VLAN
can recover the problem.
CTR crashes when port-channel The port mirror feature should be enabled only for
LAG CSR-14866 8540 interface is source of monitor one port at a time, otherwise it may cause system
session overload and crash after a few minutes.
Static LAG over 2.5Gbps SFPs When static LAG is configured with 2.5Gbps SFP
LAG CSR-18039 8540 has a limited throughput of interfaces as members, traffic throughput is
~2Gbps. limited to ~2Gbps.
When configuring load balancing for LAG, the
ports should first be shut down to prevent any
If LAG load balancing is
traffic flowing. After configuring load balancing,
LAG CSR-18571 8540 configured while traffic is
the ports may be re-enabled. Failure to follow this
running, the device may reset
sequence may result in an unexpected device
reset.
CTR currently does not support the use of same
loopback as transport address for TCP sessions
LDP: T-LDP down if configured for LDP and T-LDP adjacencies. If both LDP and T-
along with LDP on directly LDP are being used on a CTR, it is recommended
LDP CSR-17000 8540
connected CTRs, both LDP and to create at least two loopback addresses - one of
T-LDP using transport loopback them should be used in transport address TLV for
LDP sessions, and the other one for T-LDP
sessions.
MPLS signalling protocols (LDP, RSVP-TE, etc.)
are not supported on interfaces which are part of
non-default VRFs. Attempts to enable "mpls ip" on
an interface in a non-default VRF might disrupt
LDP stops working on all
LDP operation on interfaces in default VRF. To
interfaces, if "mpls ip" is
LDP CSR-25320 8540 recover from such situations, first disable MPLS
(mis)configured on a interface
on interfaces in non-default VRFs by issuing "no
that belongs in a VRF
mpls ip" cmmand under interface configuration,
and then reset the affected LDP entities by issuing
"shut" command followed by "no shut" under LDP
entity configuration.
For targeted LDP sessions, LDP-IGP sync feature
is not supported.
In case if the "ldp igp-sync" command is given
LDP IGP_SYNC configuration is
inside the entity level before the "neighbor
LDP CSR-28707 8540 accepted for targeted LDP
<x.x.x.x> targeted" command, the command
Entity
"neighbor <x.x.x.x> targeted" does not throw an
error that ldp-igp sync is not supported in targeted
LDP session
When allocating capacity license to a protected
radio link using the CLI, only the first interface is
required to be licensed. Any capacity allocated to
Customer can over allocate
the second interface will be deducted from the
Licensing CSR-9145 8540 capacity license for protected
available capacity license, but will not be used by
links
the protected radio link. There is no need to
allocate any capacity to the second interface in a
protected radio link configuration.
If an LDP (Label Distribution Protocol) entity is
created, MPLS IP cannot be deleted from the
MPLS: LDP cannot be disabled corresponding interface if the "no mpls ip"
per interface (mpls ip command command is issued too soon after the 'shutdown'
MPLS CSR-16151 8540 cannot be erased) for approx 30 command. In this case an error will be shown and
sec after interface is shut down. the command will fail. This may be avoided by
Works afterwards. waiting 30+ seconds after the 'shutdown'
command before executing the command "no
mpls ip".
White Paper
Repeatedly using the traceroute command on an
On an MPLS network, the
MPLS network may result in missing
traceroute command on some
acknowledgements on some routers, due to the
MPLS CSR-18993 8540 routers will show missing
command being issued too quickly. This issue will
acknowledgments if the
not be observed if there are several seconds of
command is issued too quickly
idle time between repeat commands.
On some occasions RSVP-TE 1-1 End-to-End
protected tunnel without BFD monitoring may not
switch over to protecting path when working path
MPLS End- E2E tunnels do not always
fails.
to-End CSR-22574 8540 switchover properly in case
Protection without BFD
Work around: Recommended practice is to always
configure a BFD session to monitor working path
for a protected tunnel.
When displaying MPLS LM&DM measurement
MPLS LM&DM: Rolling buffer is
information through CLI show commands, the
not showing the last
MPLS OAM CSR-16941 8540 most recent measurement is shown in the first
measurement in the last place in
(uppermost) slot instead of the last slot where it
the buffer
may be more logically expected.
If both MPLS LM & DM and VCCV (Virtual Circuit
Connectivity Verification) features are required to
OAM:Configuration be enabled on an L2VPN pseudowire, the control
incompatibility with MPLS LM & channel type for VCCV must be set to router-alert-
MPLS OAM CSR-17101 8540
DM and VCCV over L2VPN label (defined as out of band control channel in
Pseudowire RFC 5085). MPLS LM & DM will not function if
VCCV control channel type is set to pw-ach (pw-
ach is also known as in-band control channel).
LM&DM: LM one way The two end-points involved in One-Way MPLS
measurement (over LSP), packet loss and delay measurements are required
MPLS OAM CSR-17285 8540 measurements missing even to be time-synchronized. Without synchronization,
though 1LM PDUs were both packet loss and delay measurements will not
received function and the results will be inaccurate.
MPLS LM&DM: DM doesn’t Packet size setting is currently not supported by
MPLS OAM CSR-17299 8540 support setting packet size as MPLS DM (Delay Measurement). The packet size is
required fixed at 64 octets.
Sometimes the MPLS Loss Measurement (LM)
feature may incorrectly report a single digit packet
loss when there is no loss on the circuit. This error
is caused by a delay in the sampling of transmit
and receive counters.
To minimize this possibility it is recommended that

the LM feature should be used with a BFD
MPLS LM DM: Loss
(Bidirectional Forwarding Detection) interval of
MPLS OAM CSR-17473 8540 measurement may incorrectly
300ms and a LM query interval of 10 seconds. This
record a single digit packet loss
will provide a loss measurement granularity of
approximately 3.3%.
These settings are appropriate for L2VPN pseudo-

wires and unprotected LSPs (Label Switched
Paths) but not for protected LSPs where the BFD
session is being used to support both LM and LSP
protection.
MPLS delay measurement (DM) has the following
limitations:
1- Measurements include a bias of approximately

5ms because of processing delays in the control
plane – this means that the DM feature will report a
delay of approximately 5ms when the actual delay
MPLS-LMDM: Some LM/DM 2-
is close to 0. This bias is expected to be variable,
MPLS OAM CSR-17474 8540 way queries take more than
based on the CPU load. As a result, the MPLS DM
4.5ms
feature cannot reliably measure network delays
below 10ms.
2- Some individual measurements during a

session may falsely report abnormally high delay.
The average measurement should be relied on
rather than minimum and maximum numbers.
In order to interoperate with a Ciso router to
MPLS OAM: [INTEROP] LSP perform an MPLS ping from the CTR command
ping is not working between line, the FEC type "ldp" must be specified.
MPLS OAM CSR-21831 8540
Cisco and CTR - 'm' -
unsupported tlvs For example: ping mpls ipv4 10.254.128.51/32 fec-
type ldp
White Paper
Operational State display in "show mpls traffic-eng
te-link" command does not function correctly and
Incorrectly configured TE-Link
simply displays the administrative state of the TE-
reports it is UP - Makes
MPLS TE CSR-19671 8540 Link. A misconfigured TE-Link will appear "Up" on
debugging connectivity issues
the display when it is actually not functioning. This
hard
information should not be use in debugging traffic
engineering issues on the network.
When using the command "redistribute
connected", the default metric type is "2".Thus
issuing the command "redistribute connected
metric nnn", (where nnn is the metric value), will
reset the metric type to the default value of "2"
even if it has previously been set to a different
value.
In order to overcome this, the command should be

OSPF: Previously configured fully specified to include the metric-type parameter
OSPF CSR-20556 8540 nssa metric type is overwritten e.g."redistribute connected metric nnn metric-type
when configuring metric value t, (where t is the metric type).
So for example to set a metric value of 444 and

metric type of 1 the command should be
"redistribute connected metric 444 metric-type 1".
Without specifying the metric type, the metric type
will default to '2'.
Workaround: Always specify the metric type when

using this command.
In Provider Bridge mode, a Provider Network Port
Provider Edge Bridge: A Service
(PNP) accepts frames with outer VLAN type set to
8540, VLAN Tag with EtherType other
PB CSR-2504 0x8100 (C-VLAN), when it should only be accepting
8300 than 0x88a8 is admitted by PNP
frames with outer VLAN type set to 0x88a8 (S-
port in Provider Bridge mode
VLAN).
S-VLAN tag type swap functionality (configured
with CLI command "switchport Dot1q ethertype
mapping") does not work.
8540, Provider Edge Bridge: Ethertype
PB CSR-7414
8300 mapping does not function Therefore, in Provider Bridge mode, the standard
VLAN tag types should be used (0x8100 for C-
VLAN and 0x88a8 for S-VLAN) as there is no
workaround for the issue.
Frames with more than one customer VLAN
PB: Frames with multiple (Virtual LAN) tag (C-VLAN) are not forwarded to the
8540, Customer VLAN tags are not provider bridge network interface.
PB CSR-7509
8300 forwarded to the Provider Single C-VLAN tagged frames are processed
Bridge network port correctly, the configured S-VLAN tag is applied
and the frames are forwarded.
Due to the extra packet processing required on a
CTR 8300 when in provider edge bridge mode, it is
Provider Edge Bridge: Traffic
possible when sending a bi-directional stream of
Loss (25%) occurs from CEP to
64 byte frames between two interfaces to exceed
PB CSR-10861 8300 PNP ports when sending bi-
the switching capability of the unit, which is
directional 64 byte frames via a
approximately 1.6 Gbps. A larger frame size (128
CTR 8300
bytes or higher) must be used to avoid this
limitation.
In PB (Provider Bridge) or PEB (Provider Edge
Bridge) mode, the policing function is only able to
remark the PCP (Priority Code Point) and DEI
(Drop Eligible Indicator) bit. Remarking of IP TOS
PB: remarking of IP DSCP or
PB CSR-11360 8540 (Type Of Service)or DSCP (Differentiated Services
TOS is not correctly supported
Code Point) is not supported in these modes (it is
supported in Customer Bridge mode). Currently
the CLI does not return an error to indicate that it
is not supported.
"switchport customer-vlan <x> svlan-priotype
<copy|fixed|none> <y>" command is not
PB mode: CEP port, "switchport
implemented in Release 3.0.
8540, customer-vlan <x> svlan-
PB CSR-11477
8300 priotype <copy|fixed|none> ..."
The "service-vlan <x> recv-priority <0-7> regen-
command not working
priority <0-7>" command may be used to modify /
regenerate priority.
White Paper
In Provider Edge Bridge mode (PEB), priority
mapping in the direction from CNP (S-VLAN
tagged based) towards PNP port uses C-VLAN
(inner VLAN) priority rather than S-VLAN priority
(outer VLAN). It is expected that S-VLAN priority is
PB: Scheduling for S+C tagged
used for priority mapping.
PB CSR-11722 8540 packet from CNP S-tag ->PNP
Priority mapping for single tagged packets (S-
uses the CVLAN priority value
VLAN tag only) is working as expected.
This issue affects only S-tagged CNP ports. There
is no issue with priority mapping in the case of
Port based CNP ports which should be used as a
workaround for the problem.
There may be errors displayed in configuring an
PB: Fatal error is reported when interface's CVLAN-SVLAN mapping when the
PB CSR-12411 8540 trying add more than two ports interface is enabled.
with CVLAN to SVLAN mapping It is recommended that the interface is shutdown
before modifying its CVlan-SVlan mapping.
Some PoE configuration objects When executing the "show running-config"
POE CSR-1782 8540 do not appear in show running command, some PoE related configuration objects
configuration will not appear.
For Ethernet interfaces on the PoE card, a
manually set link duplex status is not correctly
reflected in RSTP (Rapid Spanning Tree Protocol)
or MSTP (Multiple Spanning Tree Protocol) type.
A manually set duplex status for For example. if the duplex status is manually set to
a PoE interface is not reflected half-duplex, the RSTP/MSTP interface type is
POE CSR-4891 8540
correctly in the RSTP or MSTP incorrectly set to P2P.
type
The issue is not seen if link duplex status changes
due to the interface auto-negotiation process.
This issue exists for PoE interfaces only, there is
no issue for other Ethernet interfaces.
Frames on a PoE interface are limited to 75% of the
maximum interface line rate. This restriction was
originally established when the only supported line
POE: When speed is set to rate was 1GB. Later software releases now support
10/100 Mbps, frame loss occurs 10 and 100 MB interface line rates, but the 75%
POE CSR-10209 8540
if the traffic rate is higher than restriction is still being applied. For a 10 MB
75% of the port capacity interface, 7.6 MB is delivered without loss, for 100
MB 75.7 MB is delivered. If greater though put is
required then configure the PoE interface to be
1GB.
A sustained 1 Gbps data stream sent into the PoE
(Power over Ethernet) card port may result in a
A sustained 1G line rate into
loss of all traffic over that interface after
POE CSR-11798 8540 POE card results in loss of
approximately 5 minutes. The issue does not exist
traffic
for connecting devices that deliver 750 Mbps or
less.
When using a WTM3300 in ACM (Adaptive Coding
Modulation) mode, a very small packet loss may be
QoS: Small packet loss on observed when the modulation changes to or from
POE CSR-12937 8540 WTM3300 when changing ACM 64qam. All ACM changes between lower order
modulation to or from 64qam modulations are unaffected, so this issue can be
avoided by configuring the ACM maximum
modulation lower than 64qam.
When connecting two CTR 8540s through a WTM
3300 radio link using the POE plug-in cards and
High priority traffic drops are
support for ICF's is enabled on the PoE card, some
reported with 64 bytes frames
POE CSR-25536 8540 traffic loss may be seen in the high priority traffic
when WTM3300 over PoE with
queue where multiple priority traffic streams are in
ICF enabled
operation and the traffic is made up exclusively of
64 bytes Ethernet frames.
The GUI may fail to display an error for an
unsuccessful XPIC (Cross Polarization
Web UI does not display error
Interference Cancellation) configuration on a
Protection CSR-10684 8540 message while enabling XPIC
protection interface. In such a case, the CLI can be
on inter RAC protected interface
used to configure XPIC on protection to display
the relevant reason for failure.
The G.826 statistic counter may not report any
Prot: G826 counters do not
Protection CSR-12380 8300 errors when an error or failure occurs on the radio
report any errors
link.
The protected interface status may erroneously be
reported as 'up' if all RAC plugin cards that are
Protected RAC Status Online /
members of the protection configuration are
Protection CSR-12682 8540 UP when both RACs have been
physically removed from the chassis. The correct
removed.
interface status will be reported once the RAC
plugins are re-inserted.
White Paper
Protection switching times may
Protection switching times may exceed the
Protection CSR-12974 8300 exceed the nominal 50ms
nominal 50ms maximum on CTR 8312.
maximum on CTR 8312
Occasionally (one in 50 attempts), when executing
radio protection switches (inter or intra RAC
Protection: Occasional large
8540, protection), the switches may take longer than
Protection CSR-13036 traffic outage from WP3 on
8300 expected and large amounts of traffic loss may
protection switching
occur on either direction. The traffic outage may
last up to 1 second.
If the protection Transmitter Online diagnostic is
Prot (1+1): Guard timer gets
active and the locked transmit path needs to be
stuck at 1 second when perform
Protection CSR-13329 8540 changed, the diagnostic must first be disabled.
multiple switches via TXonline
The diagnostic may then be re-enabled to lock the
diagnostics
Transmit path to the other interface.
When a radio protection Tx switch takes place,
A radio protection Tx switch there is always a brief traffic outage in the transmit
may also cause a brief outage in direction. If a protected radio link is configured for
Protection CSR-15715 8540
the Rx direction when ACM is ACM (Adaptive Coding and Modulation), a brief (<
configured. 50ms) traffic outage may also be observed in the
receive direction in some cases.
When PTP is enabled and an RFU power off switch
secondary->primary RFU power
(using RFU power off diagnostic) from secondary
Protection CSR-20169 8540 off prot switch: Small Rx path
to primary interface, is initiated, a small loss in the
loss when PTP is enabled
Rx path is observed (RX outage < 0.6ms).
Use of the radio protection diagnostic to lock the
online plug-in may cause the protected interface to
HSB link in service failure fail, if the online plugin and online transmitter are
Protection CSR-27424 8540 through one RAC with no on different plug-in modules.
alarms, not passing traffic In the case of failure, switching either the online
transmitter or online plug-in so that they are on the
same module will restore the link.
A pseudowire link cannot have different ECID's
PWE: Pseudowire configuration (Ethernet Circuit ID's) for each direction.
8540,
PWE CSR-3534 does not allow different ECID's
8300
for each direction The workaround is to configure both ends of the
pseudowire link to use the same ECID.
The single PWE3 (PseudoWire Emulation 3) trib
option supported is MEF8 with differential clock
PWE: RTP is active even if
8540, recover.
PWE CSR-4412 disabled in the configuration of
8300 This requires enabling of the optional RTP (Real
Pseudowires
Time Transport Protocol) header, with an RTP
payload of 256 bytes (for E1).
No alarm is raised when pseudowire packets are
lost as a result of jitter buffer overruns.
8540, No pseudowire jitter buffer
PWE CSR-4619
8300 overrun alarm The workaround is to check the "Buffer Overun
Dropped Packets" counter by using the "show
pseudowire counters vcid <1-128>" CLI command.
The pseudowire entries created using SNMP
(Simple Network Management Protocol) cannot be
PWE: MEF 8 Pseudowire entries
8540, fully configured. The resulting entry is only
PWE CSR-6868 created using SNMP cannot be
8300 partially complete and is not visible in the CLI. The
fully configured
CLI may be used to correctly create pseudowire
entries.
When a Pseudowire link is enabled after a CTR is
rebooted, the link test will show a PWE
PWE: tributary link-test fails to
(PseudoWire Emulation) failure due to pattern loss.
PWE CSR-11005 8540 synchronise first time after
The PWE link is working correctly and the
reboot
incorrect error report can be cleared by disabling
and re-enabling the loopback setting.
When Tributary Link Test (PRBS) is enabled for the
first time on a pseudowire circuit that has just
Line-Facing PRBS Link Test been configured, it fails to synchronise and report
PWE CSR-11825 8540 does not work the first time it's Pattern Loss. The Tributary Link Test (PRBS) must
enabled be disabled, then re-enabled a second time for it to
take effect. Subsequent uses of this diagnostic
mode will as expected.
White Paper
For Tributary Diagnostics (Pseudowires), the
Radio Facing PRBS (PseudoRandom Binary
Sequence) Link Test may not send traffic if the
tributary input has AIS (Alarm Indication Signal), or
PRBS Radio Facing Link Test
if there is no tributary input. The expected
8540, does not carry traffic if tributary
PWE CSR-11955 behavior would be for the diagnostic (PRBS) signal
8300 input has AIS when you start
to take precedence and be transmitted.
test
To resolve this issue ensure there is no AIS on the
the tributary input. If the problem persists,
configure a radio facing loopback diagnostic on
the affected tributary.
In some rare cases, PWE interfaces can not be
PWE interface intermittently
enabled or disabled using CTR Portal. If this issue
PWE CSR-18975 8540 cannot be enabled or disabled
is encountered, the CLI "shutdown" and "no
via CTR Portal (AC 88063)
shutdown" commands may be used instead.
PWR module may indicate When the power supply is removed from a power
power is present even when it is plugin card, it may fail to raise a warning alarm
PWR CSR-10904 8540
not connected to a power even though the power supply is configured as
source expected.
The QoS scheduling algorithms with priority
mapping do not operate correctly for Layer 2 Link
Aggregation (LAG) on port-channels.
QoS: Round Robin QoS
8540, The workaround is to rate limit the Egress port
QoS CSR-6564 scheduling does not operate
8300 with a value that equals the maximum Layer 1
correctly over a LAG interface
capacity of all members of the LAG Group. For
example, if a LAG Group consists of 2 1Gbps
members, the egress rate limit should be set to
2Gbps/8 bytes per second).
When configuring congestion control via the CLI,
QOS: mark-probability- the MPD (mark-probability-denominator) value
denominator(MPD) for RED is directly sets the maximum drop probability in
QoS CSR-10364 8540
same as max-drop-probability percent (100 / MPD), and not the denominator term.
(1/MPD) For example a MPD value of 5 will set the
maximum drop probability to 5%, and not 20%.
The QoS scheduling algorithms with strict priority
(strict priority, strict cir-eir, strict WFQ and struct
WRR) do not work as expected for packet sizes
QoS: Inconsistent behaviour for
less than 256 bytes.
QoS CSR-10570 8540 strict-cir-eir scheduling for
frame sizes less than 256 bytes
Lower priority traffic is assigned a small amount of
bandwidth during congestion while higher priority
traffic is available.
The congestion control settings are not properly
applied to a link aggregation interface that has
member ports that are RAC or PoE interfaces. No
QoS: Congestion control error is seen but the queue size remains fixed to
settings cannot be applied to 100 packets on each member port.
QoS CSR-10613 8540
LAG that includes PoE or RAC Congestion control for link aggregations that have
member ports RAC or PoE interfaces is not supported in this
software release, it is recommended that
congestion control for is not configured on this
type of link aggregation.
Storm control suppression thresholds do not work
accurately while configuring traffic suppression.
STORM CONTROL: Excess They have a tolerance of 10-15%.
QoS CSR-10760 8540
frames received To mitigate this, set the storm control rate values
to be 10% lower than their desired suppression
thresholds.
For QoS (Quality of Service) port-channel ports,
QOS Tail Drop functionality may the tail drop congestion avoidance may not work
not work correctly on a port- when configured with a non-strict priority
QoS CSR-10849 8540
channel with a non-strict scheduling algorithm. Congestion avoidance
priority scheduling algorithm works as expected with strict priority scheduling
algorithms.
The strict priority scheduling algorithm may not
work correctly for frame sizes exceeding 1000
bytes, when the packet-based tail drop congestion
Strict Priority Scheduling stops
8540, avoidance is applied to the queues.
QoS CSR-10881 working after configuring
8300 To resolve this issue, restrict the configured
multiple queue templates
queue-size to 300 or less. Alternately it is
recommended that the byte-based tail drop is used
for larger frame sizes.
White Paper
When the QoS scheduler is set to 'Round Robin'
QoS: when set scheduler to RR,
for the Radio and POE interfaces, the distribution
the distribution of drop traffic is
QoS CSR-11432 8540 of traffic may not be even across all the queues.
not equal (the highest priority
More drops may be seen for the higher priority
drop the most traffic)
frames.
When attempting to shut down QoS (Quality of
Service) using the CLI command "shutdown qos"
with L1LA (Layer 1 Link Aggregation) or inter/intra
RAC (Radio Access Card) protection configured,
QoS: Once set RF link to RF
the error "Fatal Error: Command Failed" may be
8540, Protection type, “shut qos"
QoS CSR-12092 observed and the operation will fail.
8300 throws Fatal Error and does not
shutdown the QoS
Work around: To fix this issue, please delete the
L1LA or inter/intra RAC protection interface and
reboot the device. Then you can shut down QoS by
cli command "shutdown qos".
The 'show qos queue-stats' command does not
CLI: show qos queue-stats
display the statistics for protection interfaces
8540, executed without interface
QoS CSR-12998 unless it is explicitly specified. The following
8300 option argument does not
variant of the command is required; aos#show qos
display protection interfaces
queue-stats interface prot <instance>
CTR Portal does not currently provide functionality
8540, CTR Portal - no functionality to to clear QoS queue statistics. This can instead be
QoS CSR-12999
8300 clear QoS queue stats accomplished by using the CLI command "clear
qos queue-stats" from the aos# prompt.
In CTR Portal, the QoS (Quality of Service)
CTR : QoS stats counter not statistics counters for an interface may incorrectly
updated for gig 0/1 interface report zeros when there is traffic passing through
QoS CSR-13223 8540
which is part of management that interface. This error does not affect the traffic,
VLAN and the QoS statistics counters are available
correctly via the CLI.
Using a combination of the CLI and CTR Portal to
configure QoS may lead to an invalid
configuration. QoS should be configured using
either the CLI or CTR Portal, but not both.
In the event of the configuration being corrupted

Configuring QoS using a
as a result of mixing the two configuration
combination of CTR Portal and
QoS CSR-17135 8540 methods, then the CLI must be used to recover the
CLI commands may lead to an
configuration. The class-maps need to be
invalid configuration
inspected, and the correct CLASS/ policy-map
should be re-assigned to each of the 'broken'
class-maps. Alternatively, the CTR may be
configured from factory defaults, and QoS
configuration re-applied using either the CLI or
CTR Portal as indicated.
When configuring CIR-EIR scheduling is via CTR
Portal, one single shape-template is applied to all 8
QoS CIR-EIR scheduling queues of the interface, so it is only possible to
QoS CSR-17785 8540 configuration options are configure equal CIR-EIR parameters for all 8
limited when using CTR Portal queues. If different shape-templates are required
for individual queues of a single interface, this
must be configured using the CLI.
If a priority-map that is referenced to a class-map
Editing or removing a QoS is removed, the class-map can no longer be
QoS CSR-18125 8540 class-map is not possible if the changed or deleted. If this situation is
priority-map has been deleted encountered, a priority-map must be created with
the same ID.
White Paper
In certain rare cases, some of the interfaces are
will not appear in the scheduler page in Web-UI.
This is due to the multiple ports having the same
Global ID in the scheduler command. Doing a
reload will not resolve this issue.
Workaround: Giving the following commands in
the same order would solve the issue,
• "shutdown qos"
• "no shutdown qos"
8540, However, this workaround has the following
Missing interfaces on Qos
QoS CSR-28656 8300, impact.
Scheduling page of the Web-UI
8300v2 • There will be a slight traffic drop when
these commands are executed as the
QoS parameters are deleted and then re-
created in both SW and HW
• Any Qos configuration done earlier
(Queue parameters, Scheduler
parameters, Priority map, class map, etc)
will be reset to default values. Hence the
entire QoS configuration needs to be re-
done and config saved.
The radio diagnostic mode "Carrier Only" may
The radio diagnostic mode cause spectrum mask violations when turned on
8540,
RAC CSR-5735 "Carrier Only" may cause TX or off.
8300
spectrum mask violation
Carrier Only mode should not be enabled.
If a slot is reconfigured from a RACx1 to a RACx2
Received Signal Level (RSL)
and back again, it is possible for the RSL on the
shows 0dBm after reconfiguring
RAC CSR-5982 8540 Radio Link Performance graph to show 0dBm
a chassis slot to a different type
instead of the actual value. Restarting the CTR
of RAC
after reconfiguration will resolve the issue.
A radio path error rate may be recorded when
pseudowire traffic containing 2^15 pseudo random
bit pattern (PRBS) is transported at highest
modulations.
This issue may also be seen with 2^9 PRBS and
Radio path errors may be
2^20 PRBS.
recorded for higher modulations
8540,
RAC CSR-6323 when transporting pseudowire
8300 The workaround is to use a different test pattern in
traffic containing a 2^15 test
the pseudo-wire data, preferably 2^23 PRBS or
pattern
2^11 PRBS. The problem only exists with the
specific 2^15, 2^9 and 2^20 test patterns at the
highest modulations in some radio conditions. It is
not expected that there will be a resolution for this
issue.
The radio interface IF Loopback diagnostic does
not loop back customer traffic. The diagnostic
feature will correctly link the demodulator to the
8540, IF Loopback diagnostic does
RAC CSR-7263 modulated signal, and the demodulator will lock to
8300 not loop back Ethernet traffic
that and record a valid SNR value. The
troubleshooting value of the feature is limited to
this aspect.
The real time radio performance counters do not
Real-time Radio Link work if a RACx2 card is replaced with a RACx1
Performance statistics are not card (for example, reported RSL stays at 0dBm).
RAC CSR-8184 8540
working when a RACx2 is The same issue exists if a RACx1 is replaced with
replaced with a RACx1 card a RACx2. A terminal restart is required to correct
this problem.
When configuring the bandwidth of a radio
The CLI does not check-limit the
interface, the CLI does not apply any check-limits
selected radio channel
8540, to the bandwidth selection. If the bandwidth is set
RAC CSR-8744 bandwidth against the
8300 to a value that is invalid for the current frequency
frequency settings and
settings and/or connected RFU capabilities, then
connected RFU capabilities
the radio link will not come up.
Setting the "Locked Plugin Online" diagnostic on a
Prot: RAC protection Plugin
protection interface via the GUI does not trigger a
RAC CSR-10021 8540 Online diagnostic does not
protection switch. The CLI may be used to set this
function correctly
diagnostic correctly.
White Paper
On the boundary between two 15-minute periods
of G.826 radio link performance statistics, if the
device is in the middle of a 10-second block
change between available and unavailable, the
8540,
RAC CSR-10047 G826 qhour stats are incorrect counts for the later 15-minute period may be
8300
incorrect.
This may result in Unavailable Seconds and
Available Seconds counts not totaling 900
seconds (15 minutes)
The "show interface capabilities" command does
The show interface capabilities not correctly display the capability values for a
8540,
RAC CSR-10115 CLI does not display bandwidth, radio interface. In order to view the current
8300
txfreq or txpwr for radio ports capability information for a radio interface, use the
"show radio link" command.
The protection interface "diagnostic plugin-online"
command requires the chassis number to be
prefixed to the slot and port identifier.
Example:
aos# c t
aos#(config) int prot 1
aos(config-prot)# diagnostic plugin-online 3/2
RAC protection CLI command indefinite
RAC CSR-10158 8540 help text for Online Plugin
diagnostic function is incorrect Invalid chassis number: 3
% Could not determine specified slot

aos(config-prot)# diagnostic plugin-online 1/3/2
indefinite
aos(config-prot)#
The radio port 3/2 is not accepted unless the

chassis is also specified. Chassis 1 is the local
chassis.
The 'RFU not detected' alarm may momentarily
toggle state (clear) on a radio port that has been
'RFU not detected' alarm may enabled but does not have an ODU connected.
8540,
RAC CSR-13158 unexpectedly clear even though
8300
no RFU is physically present. This can happen on a CTR 8312 unit or on a RACx2
card where one of the two radio interfaces are
connected to an RFU.
1 errored second may be observed on G.826
8540, Reset G826 performance history
performance history even if there was no traffic
RAC CSR-13359 8300, data will incorrectly log 1 error
lost. This may happen after the G.826 performance
8300v2 seconds (intermittent issue)
history has been reset.
The xpd-on-bnc diagnostic does not function
Diagnostic to output XPD
reliably when enabled on CTR8300 series devices.
voltage on ODU BNC connector
RAC CSR-13514 8300 Instead, use the CTR Portal > Statistics > Radio
does not work on CTR83xx with
Link Performance page, or the CLI show sensor
any ODU
command to monitor cross polar interference.
After disabling XPIC, the XPD
After disabling XPIC, the XPD sensor value is still
RAC CSR-24036 8540 sensor value is still shown until
shown until reboot (AC 98224).
reboot (AC 98224)
The new license, "Secure Authentication Client
nodal license", bundle change includes a license
for RADIUS. However, RADIUS is not currently a
User can configure Radius
8540, supported protocol in the CTR and using any of
configuration with new license
RADIUS CSR-23895 8300, the RADIUS configuration commands may cause
("Secure Authentication Client
8300v2 system issue.
nodal license") bundle change
The customer should not use any of the RADIUS
configuration commands.
The fragments counter in the RMON feature does
8540, RMON fragments counter does not increment ("show rmon statistics"). Invalid
RMON CSR-8228
8300 not increase Ethernet frames (less than 64 bytes long) will not
be counted.
The command "spanning-tree priority" should set
RSTP: Bridge priority cannot be
the Bridge Priority for the spanning tree in steps of
8540, configured for the spanning tree
RSTP CSR-8091 4096. This command has no effect if the device is
8300 protocol for devices in provider
configured as a provider edge bridge ("bridge-
edge bridge mode
mode provider-edge").
White Paper
When running RSVP-TE and LDP simulataneously,
“mpls ip” is erased per interface when an RSVP-TE
link is erased. Under this circumstance traffic will
not be forwarded over that link. Typical use case is
when the customer has LDP established
RSVP-TE and LDP throughout the network and some RSVP-TE tunnel
RSVP-TE CSR-19204 8540 simultaneously: Erasing MPLS additionally. The issue happens when those
TE config disrupts LDP certain tunnels and TE-link are erased.
Workaround:
It may help if "mpls ip" is configured immediately
after removing the "te-link", but this is not a
guaranteed solution.
The configuration order is important when setting
up RSVP-TE tunnels. Failure to configure the
tunnel in the correct sequence may result in the
tunnel not coming up.
RSVP-TE CSR-21739 8540 RSVP-TE: Tunnels fail to go up To ensure that the command "tunnel mpls traffic-
eng path-option number", will successfully
execute, the following conditions must be met:
* MPLS is enabled on the interface
* Tunnel is created
* Tunnel is not shutdown
TACACS+ (Terminal Access Controller Access
Control System Plus) Command Accounting
operates only on CLI entered commands. All CLI
entered commands result in Accounting records
TACACS+: Account Logging of
Security CSR-16913 8540 being generated but configuration operations
GUI Changes not supported
performed via the Web GUI do not result in
Accounting records being generated. Session
Start and Stop records are generated for login
from both the CLI and the Web GUI.
For TACACS+ users the login attack prevention
will only work if logging in via ssh or telnet since
8540, Login Attack prevention does
the mechanised attack prevention is based on the
Security CSR-25672 8300, not work for TACACS+ users
IP blocking.
8300v2 logged in via console
However, for *TACACS+ users logged in via
console* this login block is not applied.
8540, SNMP Traps: Traps sometimes SNMP trap messages are sometimes lost during
SNMP CSR-12659
8300 lost on startup the start-up procedure.
If the ECFM (Ethernet Connectivity Fault
Management) mode is changed from Y.1731 to
802.1ag while the Y.1731 link status alarm is
Third party alarm interface not
SNMP CSR-13183 8540 raised, the link status alarm clear message will not
in sync with CLI
be sent.
The workaround is to change the ECFM mode after
link status alarm clear message is received.
If the SNTP client time-zone is changed, the
resultant display via the "show sntp unicast-mode
status" CLI command is inaccurate.
The issue may be resolved by manually calculating

8540, SNTP client up time depends on
SNTP CSR-5690 the uptime, taking into account the change in time
8300 time zone setting
zone. For example if the timezone is changed the
user must determine the time difference between
the previous and current time zones and then
subtract that from, or add it to, uptime as
appropriate.
The terminal will not synchronise its time with an
SNTP: The terminal will not
SNTP server if the connection has been
synchronise its time with a
8540, interrupted for an hour or more. To workaround
SNTP CSR-8545 unicast SNTP server if there has
8300 this issue, the SNTP client can be restarted:
been a connectivity interruption
# set sntp client disabled
of 1 hour or more
# set sntp client enabled
If the time source used for synchronizing the local
SNTP: clock time source of system clock needs to be changed to 'internal-
"internal-oscillator” can not be oscillator', then the SNTP client needs to be
SNTP CSR-10940 8540
set unless the SNTP client is disabled first. The following command can be used
disabled to disable the SNTP client.
aos(config-sntp)# set sntp client disabled
Attempting to configure more
than two SNTP servers, results The current software only supports a maximum of
SNTP CSR-10955 8540
in a "Duplicate server type" two SNTP servers.
error
White Paper
SNTP: Missing “Last updated There is no "Last updated Time from the
time from Secondary server” Secondary Server" when the command "show sntp
SNTP CSR-10956 8540
message in “sh sntp unicast- unicast-mode status" is run from the CLI. This
mode status“ information is never displayed.
If the SNTP Destination Time Stamp is in UTC and
the CTR system time is not in UTC this system
detects a mismatch in the value and sets the Sntp
8540, Client Status value as
SNTP CSR-27544 8300, The SNTP status is not correct "SYNCHRONIZED_TO_LOCAL". In this situation,
8300v2 the system will be acting correctly, but the SNTP
Client Status will be incorrectly reported as
"SYNCHRONIZED TO LOCAL", instead of
"SYNCHRONIZED TO PRIMARY SERVER".
Changing or disabling the time-out value by
issuing "exec-timeout" or "no exec-timeout"
command doesn't work for SSH tunnel
8540, exec-timeout does not work on connections. There is no error when executing the
SSH CSR-14867
8300 an SSH connection command, but the time-out will always be the
default value which is 5 minutes.
Other connections such as Telnet and serial are
not affected.
When a protection interface is made part of a
spanning-tree, the link type defaults to "Shared
LAN" instead of "P2P". This means the link will
STP : Spanning tree "Type"
take an additional 20 seconds for traffic to recover
value is set as shared LAN for
STP CSR-10490 8540 after the shutdown of an interface.
protection interface, it should
be set as P2P
To avoid this, manually set the link type to "P2P"
after adding the protection interface to the
spanning tree.
While configuring ERPS (Ethernet Ring Protection
Switching), if MSTP (Multiple Spanning Tree
STP: MSTP cost could be set
protocol) is used to deduce the dynamic path cost,
STP CSR-10588 8540 incorrectly for ERPS enabled
the interfaces that are part of the ERPS ring need
Radio interfaces
to be enabled before MSTP is used. If not,
erroneous path costs may be observed.
When configuring ISIS network and "ip routing" is
enabled, occasionally a system failure and reboot
MSTP: DUT crash when "ip
STP CSR-16316 8540 was observed. This was observed rarely and has
routing" is enabled
not been observed lately and so is considered to
be no longer an issue.
After completing a successful software activation,
an abort command must be issued before
attempting another software upgrade. The abort
After completing a software command is required to acknowledge the software
activation, an abort command activation, cancel any pending revert timers and
8540,
SW Load CSR-1716 must be issued before ready the software loading subsystem for any
8300
attempting another software future software upgrade.
upgrade
An abort may be issued via the CLI (software
loading mode), Web GUI or SNMP
(aviatSwManagement.mib).
In certain situations where new MAC addresses
MAC address table may not are arriving at a high rate the MAC address cache
Switching CSR-12591 8540 capture expected 7740 may not support the expected 7740 MAC address
addresses when flooding entries. The supported number of entries may be
as low as 6286.
Although the system does not support SSM
(Synchronisation Status message) functionality on
E1/T1 interfaces, the user is still able to select this
option through WebUI and SNMP. CLI does not
User is permitted to set syncE have this issue. If this option is selected, clock
SYNC CSR-10612 8540 SSM enabled mode for e1/t1 selection algorithm for this sources may not work
interfaces via SNMP and WebUI correctly.
User should make sure that SSM disabled mode is

selected for E/T1 sources if they are used in the
clock selection process.
Show network clock command The "show network-clock" command may fail on a
fails on slave device after slave device after removing the interface carrying
SYNC CSR-13162 8540
removing interface carrying the the clock. It is recommended to issue the
clock command before removing the interface.
White Paper
A maximum of two SFP modules can be used as
clock sources for sync-E. When configuring sync-
E, adding more than two SFP modules as clock
sources should be avoided. Configuring more than
two SFP clock sources will add them to the list, but
sync-E only supports a
they will not become available even if previously
SYNC CSR-18434 8540 maximum of two SFP modules
configured SFP sources are removed.
as clock sources
A work around is to first remove all SFP clock
sources, and then add the desired two sources.
Alternatively, update the configuration to only
include the two desired sources, and then reset
the device.
T1 cannot be used as a synchronisation source on
the CTR8300 family products.
8300, CTR8300 is unable to lock on to
SYNC CSR-21640
8300v2 a T1 signal as clock source
T1 as a synchronisation source feature is available
on CTR8540.
During a normal system shutdown the console
may display internal shutdown messages such as
"WATCHD: Mainboard shutdown" and
"ALARMMGR: devo: Trapped signal 15 (SIGTERM).
Unpublishing objects".
Reload command results in
8540, "WATCHD: Mainboard
System CSR-3657 These are normal internal messages related to
8300 shutdown" and "devo: Trapped
system clean-up prior to shutting down. No user
signal 15 (SIGTERM)" errors
action is required and the system will continue to
function normally.
The command that triggers a shutdown followed

by a restart is the "reload" command.
Output from the "show clock properties" CLI
command, may indicate an incorrect HoldOver
Mode status. HoldOver Mode should only be
enabled if the local clock has lost synchronization
8540, System clock HoldOver is
System CSR-5199 with an external time source. However, the
8300 always enabled
command output may indicate that the system
clock is in HoldOver Mode even if it is currently
synchronized to an external clock source on the
network.
When using an Electrical SFP a link will not be
Electrical SFPs do not support established unless the connected device is
System CSR-8221 8300 10/100/1000 with auto- configured for 1000BaseT with auto-negotiation
negotiation disabled enabled. Devices operating in 10/100 mode are not
currently supported.
Enabling the internal debug interface enetpktdump
CTR may go through an may result in a system restart. This debug
8540, unwanted restart when the interface is not intended for customer use and will
System CSR-9176
8300 debug interface enetpktdump is be removed in later versions of the software. It is
enabled recommended not to use the "debug interface
enetpktdump" command.
Interface statistics for CTR 8300 The in-discards counter displayed when issuing
may not show a correct in- the "show interface counters" command may not
System CSR-9520 8300 discard count when a large report the correct number of discarded frames
number of frames are discarded when a large number of frames are discarded in
in short succession short succession.
High rate (100 Mbps) of slow protocol data into the
system may overload the CPU and result in 100%
High Rate (100 Mbps) of slow
CPU utilization. The standard definition specifies a
System CSR-10045 8540 protocol frames overloads the
maximum of 10 packets per second per port for
CPU
any type of slow protocol. If this is followed, the
CPU utilization will not be overloaded.
ARP table indicates the
Dynamically learnt ARP table entries are
System CSR-10179 8540 mapping as static even when it
incorrectly reported as static.
is learnt dynamically
Port Mirror: STP & LACP control When port mirroring is used with port-channel as
packets are not getting mirrored the source port, some L2 protocol packets may not
System CSR-10659 8540 on the destination port, when be mirrored to the destination port as expected.
monitor source port as “port- These packets can be observed by using a
channel” physical port as the mirroring source instead.
Port Mirror: does not work Port-mirroring may not work reliably with port-
System CSR-10662 8540 reliably with a port-channel as channel as the source port. It is advisable to use
the source port physical ports as the source ports instead.
White Paper
CTR supports a maximum of 10 devices in the
connected device table. When adding devices in
the CTR Portal "System Configuration->Connected
Connected Devices: unable to
Devices" page, adding more than 10 devices will
System CSR-10755 8540 add more than 10 connected
have no effect on the table.
devices.
The Connected Devices page communicates with
the CTR about the WTM units connected to plug-in
PoE ports.
When transparent mode is enabled on a CTR that
has port-channels configured, the setting does not
Transparent mode not taking take effect for the port-channels.
System CSR-11026 8540 effect on configured port To resolve this issue, after enabling transparent
channel . mode, remove all of the port channel members
from each port-channel. Then re-add them to each
port-channel.
CTR cannot mark host If the CTR is behind other network equipment, then
System CSR-12267 8540 generated traffic with specific the management packet generated by CTR cannot
DSCP or 802.1p be remarked with a specific DSCP or 802.1p.
A fatal error can occur when trying to delete a
Port Mirror: Fatal error whilst
monitor-session if the source has two different
trying to delete the monitor-
System CSR-12844 8300 ports for Tx and Rx. To resolve this, when
session if source has two
configuring Port Mirroring the option 'both' should
different ports for Tx and Rx.
be used for the source port, rather than 'tx' or 'rx'.
The "In Unicast Packets" counter may still
increase when packets have already been dropped
MTU setting: Counter "IN
due to inappropriate MTU (Maximum Transmission
System CSR-12917 8540 unicast Packets" increases
Unit) settings. The counter can be found by
even packets are dropped
issuing "show interface counters" command or
through Web GUI.
2^15-1 pattern PRBS (PseudoRandom Binary
T1 Line Facing PRBS Link Test
Sequence) is not supported.
System CSR-13116 8300 does not sync with a BER
QRSS (Quasi Random Signal Source ) pattern
Tester
should be used instead.
If excess VLAN (Virtual LAN) traffic is received on
an interface that is not a member of the VLAN, the
CTR may experience high CPU usage and drop
packets. This may be prevented by the following
CTRs in Transparent mode &
configuration changes:
System CSR-13134 8540 carrying traffic are dropping
* If the traffic is expected, add the interface to the
packets
required VLAN.
* If the traffic is not expected, turn on interface
ingress filtering (aos(config-if)# switchport
ingress-filter), which will filter out the traffic.
IP addresses in the subnet - IP addresses in the subnet range 192.168.255.x/24
8540,
System CSR-15509 192.168.255.x/24 are not are reserved internally by CTR. The user is not
8300
available for AOS configuration able to assign IP address in this range.
When using 2.5Gbps SFP modules, the maximum
throughput is reduced for small packet sizes. The
maximum throughput when sending only 64 byte
2.5 Gbps: Traffic is blocked if
System CSR-18078 8540 frames is ~2.2Gbps, and exceeding this limit may
overload traffic is sent
cause excessive packet loss. The throughput limit
does not impact traffic when larger or mixed size
frames are used.
When using 2.5Gbps SFP modules, ensure that the
port speed is correctly configured at both ends. If
Invalid port speed configuration
ports are mis-configured for 2.5Gpbs at one end
System CSR-18138 8540 when using 2.5Gbps SFP
and 1Gbps at the other, all traffic will be dropped,
modules is not detected
but no alarm will be raised and the port status will
be reported as up.
Passive SFP+ cables do not support Loss of
Signal (LoS) signalling. Thus in the event of a
remote end failure the local end may still report the
Passive SFP+ doesn't support
System CSR-18542 8540 link up.
LoS with 2.5Gbps operation
This affects the user interface (CLI/GUI) only;
operation of supported features and protocols are
unaffected.
White Paper
The enabling of debug commands is part of the
configuration data. If configuration is saved with
debug commands enabled, the enabling of debug
will persist over reloads. This may become a
problem if the number of debug operations
enabled, causes the CPU to experience extreme
loading. Under this condition the CTR may
repeatedly reset, since the debug commands will
Debug commands persist be enabled after each reset and the CPU will
System CSR-23329 8540
across reloads experience extreme loading on each occasion. The
CTR may eventually roll back to the inactive
software, due to too many resets.
Workaround: In order to avoid this situation, do

not enable debug on multiple protocols
simultaneously and only enable debug for the time
that it is required. Once debugging is no longer
required it should be disabled.
A Smart SDH SFP that is disabled or unlicensed
will continue to send 155Mbps of data to the
configured VLAN for that SFP (the PVID),
8540, Inactive/Disabled/Unlicensed
consuming bandwidth on radio links configured to
System CSR-23612 8300, STM1 SFP generating 155Mbps
carry that VLAN.
8300v2 traffic (AC 98563)
The workaround is to configure the PVID for the
SFP so that it is not part of the data stream while it
is disabled.
The configuration and viewing of QoS based ACLs
are not supported via the Web GUI. Viewing such
configurations in the Web GUI may cause the Web
GUI error during Classification
System CSR-25315 8540 GUI to show an error.
page load
Workaround: The user should configure and view
such configurations via the CLI.
The "username" command should not be used in
configuration scripts downloaded through the GUI
script loader functionality. Doing so can cause the
CLI Password change causes unit to become unresponsive as the system will be
System CSR-26184 8540
issues with ISS. waiting for password verification.
The only way to recover from this situation is to

perform a manual reboot.
If a software downgrade is performed to version
3.5 or lower and if there already exist more than 20
local user accounts in the current version, then
User accounts lost after
8540, only the default user accounts ‘root’ and ‘guest’
System CSR-24858 downgrade if total number of
8300 will be present after downgrade.
user accounts exceed 20
Workaround: Ensure there are only 20 or less user
accounts before performing the downgrade.
If a packet interface is oversubscribed and a E1/T1

CEM (Circuit Emulation) service (Pseudowire) that
originates on the Unit (and is destined to the
oversubscribed port), has lower priority and is
therefore dropping packets, service availability on
other CEM services on the same Unit may be
Lower priority Ethernet traffic
8540, degraded (packet drops), even if they are
Traffic CSR-11799 may supersede higher priority
8300 configured with highest priority.
pseudowire traffic
The issue happens only if the destination port for
the CEM services is oversubscribed.
To prevent this issue from occurring all used E1/T1
CEM (Circuit Emulated) service (Pseudowires)
should be configured with higher priority
compared to other types of traffic.
CTR 8300: Dropped traffic is
There may be traffic loss between CTRs connected
seen when untagged
8540, via radio protected link when SyncE is not
Traffic CSR-12409 bidirectional traffic is sent
8300 enabled.
through protected link on one
Enabling SyncE can resolve this problem.
direction
Global protocol VLAN (Virtual LAN) configuration
does not reflect protocol VLAN configuration on
individual VLAN's. Although changing protocol
VLAN: Global protocol VLAN VLAN configuration is reflected in global protocol
8540,
VLAN CSR-8391 status does not affect individual VLAN status, the functionality is not applied to the
8300
protocol VLAN configuration system.
To ensure correct operation, use per VLAN
configuration of protocol VLAN functionality and
not global configuration.
White Paper
It is not a legitimate operation to delete VLAN 1. If
CTR Portal - Message upon
an attempt is made to delete it from the CTR Portal,
VLAN CSR-12678 8540 attempting to delete default
a generic "Failed to Delete" error message is
VLAN is non-specific
displayed.
If a trunk port is configured on an existing VLAN
VLAN : MAC learning fails when (Virtual LAN), the MAC learning on this port will fail
VLAN CSR-12735 8300 Trunk port is configured after and the traffic will get flooded. The trunk port
the creation of VLAN should be configured before adding it to any
VLANs.
After configuring transparent mode through CTR
Portal, virtual ports (radio, POE, prot, l1la, LAG
interfaces) fail to get automatically added to the
default VLAN (Virtual LAN) when brought up. The
Transparent Mode: WDDI error
user would need to manually add these virtual
is reported when add the RAC
VLAN CSR-12986 8540 ports to the default VLAN. This problem occurs
interfaces to VLAN 1 after
only for the very first virtual port added after
enabling the transparent mode
setting transparent mode through CTR Portal.
This issue may be resolved by adding the radio

interface to the default VLAN again.
Small VLAN-tagged Ethernet frames aren't padded
Small ethernet frames aren't
to 64 Bytes upon egress on virtual ports. As a
VLAN CSR-12990 8540 padded correctly to 64B upon
result, 60B frames received by the other device are
egress on virtual ports
discarded.
The CTR Portal VLAN (Virtual LAN) page allows the
CTR Portal - In transparent
8540, removal of VLAN 4094 when operating in
VLAN CSR-13076 VLAN mode, allows removal of
8300 Transparent VLAN mode. VLAN 4094 is required
VLAN 4094
and should never be removed.
It is not possible to remove a VLAN (Virtual LAN)
from a radio interface using the "remove" key
word. The following command will not work on
radio interfaces: switchport trunk allowed vlan
remove <vlan_list>
As a workaround, a VLAN can be removed using
VLAN : can not remove a VLAN the forbidden key word. For example, removing
VLAN CSR-13557 8540
from a trunk radio interface interface 3 from VLAN 100 :
aos# c t
aos(config)# vlan 100
aos(config-vlan)# ports gi 0/2 gi 0/4 forbidden gi
0/3
aos(config-vlan)# ex
aos(config)# conf save
Defining a protected radio interface as a trunk port
VLAN: Console error reported
may result in an error message on the console.
VLAN CSR-13569 8540 when a protected radio interface
This feature functions correctly and the error
port mode is defined as a trunk
report can be ignored.
The CTR 8300 may generate an error when the
8300, CTR 8300 does not support 250 maximum permitted number of VLANs are
VLAN CSR-18442
8300v2 VLANs configured. To avoid this issue, do not configure
more than 248 VLANs.
In a scenario where there are 150 VLAN IP
190 interfaces: it takes a minute interfaces with all the VLANs having a single trunk
to transition a trunk interface port as their active member, if the trunk port is
VLAN CSR-19695 8540
with 150 VLANs between administratively shut down, it may take up to a
up/down operational state minute for all the IPs to be brought down and the
CLI/GUI will be unresponsive during that period.
Transparent VLAN mode can only be enabled in
Customer Bridge Mode. In this mode when there
are router ports configured on the CTR, the CLI
prevents the user from enabling Transparent VLAN
and will display error message but the CTR web
8540, portal still provides the user with an option to
Unable to enable Transparent
VLAN CSR-28530 8300, enable Transparent VLAN. On selecting this
VLAN mode using Web-UI
8300v2 option, no error message will is displayed even
though the configuration is not applied
successfully.
Workaround: Do not enable Transparent VLAN

when router ports are configured in the CTR
White Paper
If an operational L2VPN Pseudowire (PW) is bound
to an RSVP-TE tunnel and the RSVP-TE tunnel
priority constraints are changed, the PW goes
VPWS remains down when down.
VPWS CSR-23507 8540 tuning E2E RSVP-TE priority
constraints Workaround:
Delete the PW, shut down the tunnel, make config
changes to the tunnel, re-enable the tunnel,
configure the PW again.
White Paper
CTR 8540 Closed Field Issues
The following table lists field issues that have been resolved in this release.
Feature Refs Product Summary Details

When software was upgraded to R3.9 on units
running 4+4 L1LA using ODU600T, 5GHz with
64QAM fixed modulation, the L1LA link will
become unstable and not pass any traffic. This
CSR-28596 is due to very high receive latency on one or
3.9 software intermittent error in
L1LA CS0019167/ 8540 more member links in the L1LA group. Also, this
64QAM 5GHZ links.
INC0010781 would result in protection switching to not
operate correctly.
This issue has been resolved in the 3.9.1 LA

version and this release of software.
Two issues fixed in this release
1. CTR8540 running R3.9 software did
not recognize the IRU600v3 lower
6GHz band radios and hence they
could not be configured.
2. When modulation is set to 512QAM, in
the IRU600v3 lower 6GHz EHP units,
Issues with IRU600V3 related to
the transmit power will not meet the
IRU600v3 CSR-28754 8540 L6 recognition and Tx Power in
specification of 35.5dBm.
the 3.9 software.
The correct L6 frequency band ID is now applied
to units which report U6 but have L6 frequency
capabilities thus allowing the right power
backoffs to be applied and to display the correct
band name.
This issue has been resolved in the 3.9.2
version of software as well.
Previously when the last C-VLAN to S-
VLAN mapping of any S-VLAN is deleted, all
CSR-28723 CEP port stops passing ALL
traffic on that CEP port would get dropped.
PB CS0023035/ 8540 traffic when deleting C-VLAN to
This issue is fixed in this version of software. All
INC0010821 S-VLAN mapping
C-VLAN mappings for a S-VLAN can be removed
without traffic impact on other S-VLAN
Previously the value of current in the sensor
CSR-28396
Incorrect critical high value for status page of the GUI would show values
Sensor CS0014236/ 8540
current exceeding the critical high value.
INC0010661
This is now corrected in this release of software.
This is a duplicate of the previous customer
case CS0013653/ INC0010634 which was fixed in
CSR-28755 R3.9.0 GA. This software version includes one
Watchdog resets at multiple sites
ERPS CS0024525/ 8540 additional fix by implementing a locking
running software 3.7.0 GA
INC0010846 mechanism to improve robustness of the
system when there is an ARP flood in the
network.
Previously due to the inability to load balance
the inbound traffic, the CTR would drop traffic
Inbound Traffic Load Balancing
CSR-28578 from third party vendors wherever there was a
from the Huawei Core to the CTR
BGP CS0017734/ 8540 bandwidth constraint on the radio link.
using Community as the BGP
INC0010772 This release of software supports the route-map
Attribute
configuration with community attribute to
achieve load balancing.
In some cases, the default route added for NMS
would get overwritten by the CTR with a route
used by the debug cards. This would result in
CSR-28512 Issues with Management Port
System 8540 CTR not responding to ping requests to the
CS0014718 Connections
management IP.
This issue has been resolved in this release of
software
Due to a memory leak in the ISIS module when
CSR-28504
LDP-IGP synchronization is enabled, the ISIS
CS0016009/
ISIS 8540 ISIS adjacency lost adjacency would be lost on the CTR. This
INC0010728
memory leak has been fixed in this release of
software
Due to the above-mentioned issue the BGP
CSR-28508 session would change to Idle state once routes
BGP CS0015897/ 8540 BGP session became Idle are removed as a result of ISIS adjacency loss.
INC0010726 The above memory leak fix addresses this issue
as well.
White Paper
Previously in a sequence of configuration with
ISIS enabled, while mapping VRF to IVR
interface without adding ports to the VLAN, the
CSR-28516 hardware layer resource corruption can happen
WDDI error occurs sequence of
CS0015660/ resulting in undefined system behavior.
L3VPN 8540 configuring ISIS + VRF + IVR (no
INC0010725 This issue has been fixed in this release of
ports associated to VLAN)
software. The workaround of adding ports to
VLAN before mapping VRF to IVR interface is no
longer required.
Previously the SNMPv3 configurations will not

8540, be displayed in the ‘show running-config’ output
CSR-28765
8300, SNMPv3 Configurations are not for SNMP if command is executed by a
SNMP CS0025799/
8300v2 shown for TACACS+ users TACACS+ user.
INC0010859
This issue has been resolved in this version of
software.
Aviat Networks encourages its customers to report problems so we can resolve them
as quickly as possible. If you encounter a technical issue, please contact us using
the information on page 2 of these Release Notes.

CTR 8540 CTR 8300 - Release 3.10.0 (45.6148) Customer Software Release Notes September 2019

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CTR 8540 CTR 8300 - Release 3.10.0 (45.6148) Customer Software Release Notes September 2019

Uploaded by

Copyright:

Available Formats

CTR 8540, 8300, 8300v2 and 8380 –

RELEASE NOTE DATE: 26th September 2019

P/N 275-250424-006148 – CTR 8540

DocReg Ref: 2841-253

Copyright © 2018 by Aviat Networks.

USA Europe, Middle East & Asia/Pacific

E-mail: Tel : +33 1 77 31 00 00

Scope and Purpose

The intended users of this document are:

This release delivers

• Support four NTP server configuration

1) Hardware and Software Compatibility

2) Memory Usage During Upgrade

3) DRAM Memory Initialization Issue

4) Downgrading to Version 2.x

5) BFD Incompatibility Between Versions

Method 1 – Disable BFD

Step 2: Save the configuration in CTR

Method 2 – Simultaneous Activation

6) Login Authentication option

Step 1: Modify login authentication configuration in CTR;

Step 2: Save the configuration in CTR

7) Upgrading from Release 3.4

CTR 8540 Release Features and Functionality Supported

This release supports the following L1LA configurations:

L1LA support over PoE interfaces to enable WTM4K trunking, subject to

Carrier Ethernet Functionality

Higher Layer Protocols

L3 / MPLS Scalability and Performance (Validated at release date of these notes)

OSPF Functionality Sub Features Status

WTM validation with 2xPoE Module

CTR 8540 Functionality Not Included in this release

CTR 8540 Functionality that is not included or validated in this release

Carrier Ethernet Features

CTR 8540 Customer Software 275-250424-006148 3.10.0 6148

CTR 8540 ProVision Support

CTR 8540 Hardware Supported

Software Product Part Number Notes

CTR 8540 Hardware and Software Compatibility

Hardware HSC Mainboard Software Software

Hardware Revision Part Number Software Software

CTX-800-001 CTR 8500 RACx1 2 Refer hardware 3.0.2(21.3211) 275-250424-003211

CTP-120-001 CTR 8500 2xPOE 1 Refer hardware 2.4.0(20.2694) 275-250424-002694

CTS-100-001 CTR 8500 Redundant PSU 1 Refer hardware 2.4.0(20.2694) 275-250424-002694

7.0 MHz ETSI Airlink Capacity Modulation Enabled Modules

13.75 / 14.0 MHz ETSI Airlink Capacity Modulation Enabled Modules

55.0 / 56.0 MHz ETSI Airlink Capacity Modulation Enabled Modules

5.0 MHz ANSI Airlink Capacity Modulation Enabled Modules

10.0 MHz ANSI Airlink Capacity Modulation Enabled Modules

20.0 MHz ANSI Airlink Capacity Modulation Enabled Modules

25.0 MHz ANSI Airlink Capacity Modulation Enabled Modules

30.0 MHz ANSI Airlink Capacity Modulation Enabled Modules

40.0 MHz ANSI Airlink Capacity Modulation Enabled Modules

50.0 MHz ANSI Airlink Capacity Modulation Enabled Modules

60.0 MHz ANSI Airlink Capacity Modulation Enabled Modules

80.0 MHz ANSI Airlink Capacity Modulation Enabled Modules

Software and Feature Licenses

Radio Functionality and ODU Interoperability with RAC interface

CTR Administration and Operation Functionality

CTR 8300 Functionality that is not included or validated in this release

Carrier Ethernet Features

CTR 8300v2 Software Version Upgrade Compatibility

CTR 8300 Software Part Numbers