CTR 8540 3.4.0 Getting Started Configuration - June2017

CTR 8540
Getting Started Configuration

Version 3.4.0
260-668254-001
GETTING STARTED CONFIGURATION
Copyright & Terms of Use

July 2017
This documentation incorporates features and functions provided with CTR 8540
Getting Started Configuration, version 3.4.0.
Copyright © 2017 by Aviat Networks, Inc.
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 Inc.
To request permission, contact techpubs@aviatnet.com.
Warranty
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.
Safety Recommendations
The following safety recommendations must be considered to avoid injuries to

persons and/or damage to the equipment:
1. Installation and Service Personnel: Installation and service must be carried
out by authorized personnel who have the technical training and experience
necessary to be aware of any hazardous operations during installation and
service, and of measures to avoid any danger to themselves, to any other
personnel, and to the equipment.
2. Access to the Equipment: Access to the equipment in use must be restricted
to service personnel only.
3. Safety Norms: Recommended safety norms are detailed in the Health and
Safety sections of the Eclipse User Manual.
4. Service Personnel Skill: Service personnel must have received adequate
technical training on telecommunications and in particular on the equipment
and capabilities this addendum refers to.
Trademarks
All trademarks are the property of their respective owners.
260-668254-001 JULY 2017 III

IV AVIAT NETWORKS
Aviat NetworksTechnical Support

Service and Technical Support:
For customer service and technical support, contact one of the regional Technical
Help Desks listed below.
Americas Technical Help Desk EMEA Technical Help Desk Asia Pacific Technical Help Desk
Aviat Networks, Inc. Aviat Networks Aviat Networks
San Antonio, TX Blantyre, Glasgow, Scotland Clark Freeport Zone
U.S.A. G72 0FB Philippines 2023
United Kingdom
Phone:+1 210 526 6345 Phone: +1 210 526 6345 Phone: +1 210 526 6345
Toll Free (USA): Fax: Fax: +63 45 599 5196
+1 800 227 8332 +44 16 9871 7204 (English)
Fax:+1 210 526 6315 +33 1 5552 8012 (French)
Email: Email: Email:
CustomerCare.Americas@av CustomerCare.EMEA@aviatnet CustomerCare.Asia@aviatne
iatnet.com .com t.com
Global Support Hotline: +1 210 526 6345

Call this phone number for support from anywhere in the world. Aviat Networks'
Global Support Hotline is available 24 hours a day, 7 days a week, providing
uninterrupted support for all our customers.
When you call our Global Support Hotline:
l You will be greeted by an automated response that will ask you for your
PIN#. Request a PIN# here: http://aviatnetworks.com/contact-
us/technical-assistance/pin-request-form/.
l As soon as you enter your PIN#, you will be transferred to our Global
Technical Helpdesk that will assist you with your technical issue.
l If you do not have a PIN# your call will be answered by our Support
Assurance Desk. Your call will be supported and prioritized accordingly.
Or you can contact your local Aviat Networks office. Contact information is
available on our website at: http://www.aviatnetworks.com/services/customer-
support/technical-assistance/
Sales and Sales Support:

For sales information, contact one of the Aviat Networksheadquarters, or find
your regional sales office at: HTTP://WWW.AVIATNETWORKS.COM/.
260-668254-001 JULY 2017 V

Corporate Headquarters International Headquarters

California, USA Singapore
Aviat Networks, Inc. Aviat Networks (S) Pte. Ltd.
860 N. McCarthy Blvd., Suite 200 17, Changi Business Park Central 1
Milpitas, CA 95035 Honeywell Building, #04-01
U.S.A. Singapore 486073
Phone: + 1 408 941 7100 Phone: + 65 6496 0900

Fax: + 1 408 941 7110 Fax: + 65 6496 0999>
Toll Free for Sales Inquiries: Sales Inquiries:
+ 1 888 478 9669 +1-321-674-4252
VI AVIAT NETWORKS
Product Compliance Notes

CTR 8540, CTR 8312, CTR 8311, and CTR 8380 have been tested for and meet all
applicable EMC standards. The equipment was tested using screened cable; if any
other type of cable is used, it may violate EMC compliance.
CTR 8540, CTR 8312, CTR 8311, and CTR 8380 are Class A products. In a domestic
environment these products may cause radio interference in which case the user
may be required to take adequate measures. This equipment is intended to be
used exclusively in telecommunications centers.
Regulatory Information for 5.8 GHz Band

ODU 600
The following regulatory information applies to license-free operation on the 5.8

GHz band of ODU 600.
FCC Notices
l ODU 600, 5.8GHz, must be professionally installed and maintained.
l This equipment has been tested and found to comply with the limits for
a Class A digital device, pursuant to Part 15 of the FCC rules. These
limits are designed to provide reasonable protection against harmful
interference when the equipment is operated in a commercial
environment. This equipment generates, uses and can radiate radio
frequency energy and, if not installed and used in accordance with the
instruction manual, may cause harmful interference to radio
communications. Operation of this equipment in a residential
environment is likely to cause harmful interference in which case the
user will be required to correct the interference at their own expense.
l ODU 600, 5.8GHz, is compliant with the relevant parts of FCC CFR47,
Part 15.407.
l To ensure compliance with the FCC RF exposure requirements, a
minimum distance of 18 meters must be maintained between the
antenna and any persons whilst the unit is operational. This calculation
is based on the maximum conducted power and maximum antenna
gain.
l ODU 600, 5.8GHz, has been certified for use with a parabolic antenna
with a maximum gain of 45.9dBi or a flat panel antenna with a
maximum gain of 28dBi.
l The filters and software provided with this product allow for
transmission only in the frequency range 5725 – 5850 MHz to ensure
compliance with Part 15.407.
260-668254-001 JULY 2017 VII

l According to the conducted power limit in FCC CFR 47, Part 15.407, the
power for this device has been limited to 1W (30dBm) at the antenna
port.
l FCC CFR47, Part 15.407 excludes the use of point-to-multipoint
systems, omnidirectional applications and multiple co-located
intentional radiators. This system is only for fixed, point-to-point
operation.
International Use of 5.8 GHz

ODU 600 with CTR 8540, CTR 8312, CTR 8311, or CTR 8380, 5.8 GHz, does not
employ DFS, and as such the equipment cannot be deployed within Europe or any
country where DFS is a regulatory requirement for protection of radars.
Networking Devices in Electric Power Substations

For IEEE 1613 compliant products, category 7 Ethernet cables must be used in
order to ensure compliance.
WEEE Directive
In accordance with the WEEE Directive (2012/19/EU), CTR 8540, CTR 8312, CTR
8311, and CTR 8380 is marked with the following symbol:
This symbol indicates that this equipment should be collected separately for the
purposes of recovery and/or recycling.
For information about collection and recycling of Aviat Networks equipment
please contact your local Aviat Networks sales office. If you purchased your
product via a distributor please contact the distributor for information regarding
collection and recovery/recycling.
More information on the WEEE Directive is available at our website:
http://www.aviatnetworks.com/products/compliance/weee/.
(WEEE is the acronym for Waste Electrical and Electronic Equipment)
RoHS Directive
CTR 8540, CTR 8312, CTR 8311, and CTR 8380 meets the requirements of ROHS
directive 2011/65/EU.
VIII AVIAT NETWORKS

Declaration of Conformity, Radio Equipment Directive

(RED), 2014/53/EU
Aviat Networks tímto prohlašuje, že tento ODU 600/ODU 600sp

with CTR 8311, CTR 8312, CTR 8380, CTR 8540 je ve shodě se
Czech Republic základními požadavky a dalšími příslušnými ustanoveními
směrnice 2014/53/EU.
Undertegnede , Aviat Networks erklærer herved, at følgende
udstyr ODU 600/ODU 600sp with CTR 8311, CTR 8312, CTR
Denmark 8380, CTR 8540 overholder de væsentlige krav og øvrige
relevante krav i direktiv 2014/53/EU.
Hiermit erklärt , Aviat Networks dass sich das Gerät ODU
600/ODU 600sp with CTR 8311, CTR 8312, CTR 8380, CTR 8540
Germany Austria Switzerland Belgium in Übereinstimmung mit den grundlegenden Anforderungen und
den übrigen einschlägigen Bestimmungen der Richtlinie
2014/53/EU befindet.
Luxembourg Netherlands Liechtenstein
Käesolevaga kinnitab , Aviat Networks seadme ODU 600/ODU
600sp with CTR 8311, CTR 8312, CTR 8380, CTR 8540 vastavust
Estonia direktiivi 2014/53/EL põhinõuetele ja nimetatud direktiivist
tulenevatele teistele asjakohastele sätetele.
Hereby, Aviat Networks declares that ODU 600/ODU 600sp with
CTR 8311, CTR 8312, CTR 8380, CTR 8540 is in compliance with
United Kingdom Ireland Malta the essential requirements and other relevant provisions of
Directive 2014/53/EU.
Por medio de la presente Aviat Networks declara que el ODU
Spain cumple con los requisitos esenciales y cualesquiera otras
disposiciones aplicables o exigibles de la Directiva 2014/53/UE.
ΜΕ ΤΗΝ ΠΑΡΟΥΣΑ, Aviat Networks ΔΗΛΩΝΕΙ ΟΤΙ ODU 600/ODU
600sp with CTR 8311, CTR 8312, CTR 8380, CTR 8540
Greece Cyprus ΣΥΜΜΟΡΦΩΝΕΤΑΙ ΠΡΟΣ ΤΙΣ ΟΥΣΙΩΔΕΙΣ ΑΠΑΙΤΗΣΕΙΣ ΚΑΙ ΤΙΣ
ΛΟΙΠΕΣ ΣΧΕΤΙΚΕΣ ΔΙΑΤΑΞΕΙΣ ΤΗΣ ΟΔΗΓΙΑΣ 2014/53/ΕE.
Par la présente, Aviat Networks déclare que l'appareil ODU
France Luxembourg Switzerland Belgium est conforme aux exigences essentielles et aux autres
dispositions pertinentes de la directive 2014/53/UE.
Con la presente , Aviat Networks dichiara che questo ODU
Italy Switzerland è conforme ai requisiti essenziali ed alle altre disposizioni
pertinenti stabilite dalla direttiva 2014/53/UE.
Ar šo Aviat Networks deklarē, ka ODU 600/ODU 600sp with CTR
8311, CTR 8312, CTR 8380, CTR 8540 atbilst Direktīvas
Latvia 2014/53/ES būtiskajām prasībām un citiem ar to saistītajiem
noteikumiem,
Šiuo Aviat Networks deklaruoja, kad šis ODU 600/ODU 600sp
with CTR 8311, CTR 8312, CTR 8380, CTR 8540 atitinka
Lithuania esminius reikalavimus ir kitas 2014/53/ES Direktyvos nuostatas.
260-668254-001 JULY 2017 IX

Hierbij verklaart , Aviat Networks dat het toestel ODU 600/ODU

600sp with CTR 8311, CTR 8312, CTR 8380, CTR 8540 in
Netherlands Belgium overeenstemming is met de essentiële eisen en de andere
relevante bepalingen van richtlijn 2014/53/EU.
Hawnhekk, Aviat Networks, jiddikjara li dan ODU 600/ODU 600sp
with CTR 8311, CTR 8312, CTR 8380, CTR 8540 ikkonforma mal-
Malta ħtiġijiet essenzjali u ma provvedimenti oħrajn relevanti li hemm
fid-Dirrettiva 2014/53/UE.
Alulírott, Aviat Networks nyilatkozom, hogy a ODU 600/ODU
600sp with CTR 8311, CTR 8312, CTR 8380, CTR 8540 megfelel
Hungary a vonatkozó alapvetõ követelményeknek és az 2014/53/EU
irányelv egyéb elõírásainak.
Niniejszym Aviat Networks oświadcza, że ODU 600/ODU 600sp
with CTR 8311, CTR 8312, CTR 8380, CTR 8540 jest zgodny z
Poland zasadniczymi wymogami oraz pozostałymi stosownymi
postanowieniami Dyrektywy 2014/53/UE.
Aviat Networks declara que este ODU 600/ODU 600sp with CTR
8311, CTR 8312, CTR 8380, CTR 8540 LL/STR 600 está
Portugal conforme com os requisitos essenciais e outras disposições da
Directiva 2014/53/UE.
Aviat Networks izjavlja, da je ta ODU 600/ODU 600sp with CTR
8311, CTR 8312, CTR 8380, CTR 8540 v skladu z bistvenimi
Slovenia zahtevami in ostalimi relevantnimi določili direktive 2014/53/EU.
Aviat Networks týmto vyhlasuje, že ODU 600/ODU 600sp with
CTR 8311, CTR 8312, CTR 8380, CTR 8540 spĺňa základné
Slovakia požiadavky a všetky príslušné ustanovenia Smernice
2014/53/EÚ.
Aviat Networks vakuuttaa täten että ODU 600/ODU 600sp with
CTR 8311, CTR 8312, CTR 8380, CTR 8540 tyyppinen laite on
Finland direktiivin 2014/53/EU oleellisten vaatimusten ja sitä koskevien
direktiivin muiden ehtojen mukainen.
Härmed intygar Aviat Networks att denna ODU 600/ODU 600sp
with CTR 8311, CTR 8312, CTR 8380, CTR 8540 tår I
Sweden överensstämmelse med de väsentliga egenskapskrav och övriga
relevanta bestämmelser som framgår av direktiv 2014/53/EU.
Hér með lýsir Aviat Networks yfir því að ODU 600/ODU 600sp
with CTR 8311, CTR 8312, CTR 8380, CTR 8540 er í samræmi
við grunnkröfur og aðrar kröfur, sem gerðar eru í tilskipun
Iceland
2014/53/EU.
Aviat Networks erklærer herved at utstyret ODU 600/ODU 600sp
with CTR 8311, CTR 8312, CTR 8380, CTR 8540 er i samsvar
med de grunnleggende krav og øvrige relevante krav i direktiv
Norway
2014/53/EU.
Noi, Aviat Networks, declarăm pe propria noastră răspundere că
produsul ODU 600/ODU 600sp with CTR 8311, CTR 8312, CTR
România 8380, CTR 8540 este în conformitate cu cerinţele esenţiale şi
celelalte prevederi aplicabile ale Directivei 2014/53/UE.
Full declarations of conformity are available at:

http://aviatnetworks.com/doc/ODU600CTR8311CTR8312.pdf
http://aviatnetworks.com/doc/ODU600CTR8380.pdf
http://aviatnetworks.com/doc/ODU600CTR8540.pdf
http://aviatnetworks.com/doc/ODU600spCTR8311CTR8312.pdf
X AVIAT NETWORKS
http://aviatnetworks.com/doc/ODU600spCTR8380.pdf
http://aviatnetworks.com/doc/ODU600spCTR8540.pdf
Country Availability Matrix

Aviat’s radios are classified under the Radio Equipment Directive (2014/53/EU) as
Class 2 products. For details of where the equipment is intended to be used, see
the country matrix below. Aviat Networks intends to market this equipment
where a cross (X) is shown.
Band (GHz) L6 U6 07 08 10 11 13 15 18 23 26 28 32 38 42
Austria X X X X X X X X X X X X X X X
Belgium X X X X X X X X X X X X X
Bulgaria X X X X X X X X X X X X X
Cyprus X X X X X X X X X X X X X X
Czech Republic X X X X X X X X X X X
Denmark X X X X X X X X X X X X
Estonia X X X X X X X X X X X X X X X
Finland X X X X X X X X X X X X X X
France X X X X X X X X X X X X X X
Germany X X X X X X X X X X X X X X X
Greece X X X X X X X X
Hungary X X X X X X X X X X X
Iceland X X X X X X X X X X X X X
Ireland X X X X X X X X X X X
Italy X X X X X X X X X X X X X
Latvia X X X X X X X X X X X
Lithuania X X X X X X X X X X X X X X
Luxembourg X X X X X X X X X X X X X
Malta X X X X X X X X X X X X X
Netherlands X X X X X X X X X X X
Norway X X X X X X X X X X X X X
Poland X X X X X X X X X X X X X X
Portugal X X X X X X X X X X X X
Romania X X X X X X X X X X X X X X X
Slovak Republic X X X X X X X X X X X X X
Slovenia X X X X X X X X X X X X X X
Spain X X X X X X X X X X X X
Sweden X X X X X X X X X X X
Switzerland X X X X X X X X X X X X X X
United Kingdom X X X X X X X X X X X X X
IT SHOULD BE NOTED THAT A LICENSE TO OPERATE THIS EQUIPMENT

WILL BE REQUIRED AND THE RELEVANT REGULATOR MUST BE
CONTACTED PRIOR TO INSTALLATION AND COMMISSIONING.
260-668254-001 JULY 2017 XI

Contents
Copyright & Terms of Use iii

Aviat NetworksTechnical Support v
Product Compliance Notes vii
Regulatory Information for 5.8 GHz Band vii
Networking Devices in Electric Power Substations viii
WEEE Directive viii
RoHS Directive viii
Declaration of Conformity, Radio Equipment Directive (RED), 2014/53/EU ix
Contents xii
CTR 8500/8300 Configuration 14
Overview 14
Introduction 14
CLI or CTR Portal 15
CTR CLI Guide 17
Useful Tips and Shortcuts 17
Contexts 18
Local Management Access 18
Serial Port Access 19
Switch Port Access 21
Login 23
Adding and Changing Users and Passwords 23
Administrative Privilege 23
Local User Access 24
ProVision Access 24
Authentication, Authorization and Accounting (AAA) 25
Remote Server Configuration 26
Configuring TACACS+ to Perform AAA 26
Deconfiguring TACACS+ 27
Show Commands 27
Configuration Save and Revert Timer 27
CLI Script Entry 28
Changing IP Address and Local Management Access 29
Out-of-Box Defaults 30
Resetting Local Management Access 30
Adding In-Band Management Access 32
Routed Management 32
To Set Bridge Mode 35
Port Type 39
Reestablishing Local Management Access 39
To Enable or Disable a Port 40
XII AVIAT NETWORKS

To Set Port MTU Size 41

To Add or Remove a VLAN 42
Revert to Default Config 44
Slot Configuration 44
SW Loading 45
License Loading 47
Date and Time 49
Radio Configuration 49
Network Connectivity 66
Locate Me 67
Useful Show Commands 67
CTR CLI Example Configurations 69
QoS 69
Congestion Avoidance 76
ERPS 80
ESMC 87
E1/T1 Pseudowires 89
STM1/OC3 Pseudowire 92
Static LAG 94
Provider Edge Bridge Mode 96
ECFM 100
IP/MPLS 104
Example 1: VPWS Service 106
114
Example 2: L2VPN VPLS Configuration 126
Example 3: L3VPN Configuration 154
Example 4: End-to-End Protection Switching 166
Example 5: BFD Configuration 188
Example 6: POLICING PER L2VPN 191
Authentication, Authorization and Accounting (AAA) 195
Configuring TACACS+ to perform AAA 195
Deconfiguring TACACS+ 195
CTR Portal 196
Login 196
Health & Safety 199
260-668254-001 JULY 2017 XIII

CTR 8500/8300 CONFIGURATION CHAPTER 1
CTR 8500/8300 Configuration
Overview
This Getting Started Guide is intended for use at new installations where the CTR
is received with factory defaults loaded.
It is applicable to SW release 3.4 for CTR 8500 and CTR 8300.
The guide overviews CTR configuration using CLI, and introduces CTR Portal, the
menu-based Web GUI for CTR 8500, and CTR 8300.
l Mention of CTR 8500 in this guide refers to the CTR 8500 product
family, which currently comprises the CTR 8540.
l Mention of CTR 8300 in this guide refers to the CTR 8300 product
family, which currently comprises the CTR 8312, and CTR 8311.
Guidance is provided on essential configuration procedures with example CLI

scripts for basic set-up.
For more comprehensive CLI configuration information, refer to:
l CTR 8500/8300 CLI Reference Manual
l CTR 8500/8300 Configuration Guides for EOAM, ESMC, ERPS, VLAN,
MPLS, IS-IS, OAM, QoS, IP, STP
To configure CTR 8500 and CTR 8300 using its Web GUI, refer to the CTR Portal
Manual.
NOTE: Fo r i n fo rma ti o n o n ma n a g e me n t a cce ss u si n g Avi a t's Pro Vi si o n EMS,
o r o n SN MP u sa g e , co n ta ct Avi a t N e tw o rks.
To view health and safety requirements see Health & Safety on page 199.
NOTE: U nles s otherw is e noted, data in this doc ument is applicable to

C TR 8500 and C TR 8300.
Introduction
CTR 8500 and CTR 8300 provide in one compact carrier-class platform fully
integrated microwave link, L2 switch, and L3 router functions.
l The converged operation ensures interworking between microwave and
IP network links is optimized.
l Operation is uplink agnostic with options for IF or Ethernet connected
microwave, copper, or fiber media.
AVIAT NETWORKS JULY 2017 14

CHAPTER 1 CTR 8500/8300 CONFIGURATION
Microwave applications support scalable radio transport for conventional

microwave (5-42 GHz) and E-band microwave (70-80 GHz).
l For split-mount installations, IF connectivity is provided to Aviat’s ODU
600, ODU 600sp, and ODU 300hp.
l For all-indoor installations, IF connectivity is provided to Aviat's IRU
600
l For all-outdoor installations, PoE connectivity is provided by CTR 8500
to Aviat's family of WTM 3000 radios, or to any other external packet
radio.
l When connected to an Aviat radio the features include modulations to
1024 QAM, adaptive coding and modulation (ACM), and extensive
protection and co-path configurations.
CLI or CTR Portal

CTR 8500 and CTR 8300 can be configured using CLI, or its menu-driven Web
GUI, CTR Portal.
l CLI is accessed using the Telnet or SSH protocols from a terminal
emulation program such as the freeware 'PuTTY' or 'xterm'.
l CTR Portal is accessed through a web browser by entering the IP
Address of the device in the browser address bar.
NOTE: U nles s y ou are ex perienc ed in the us e of C LI, C TR Portal w ill
prov ide an eas ier, more us er-friendly c onfiguration experience.
At SW release 3.4 for CTR 8540 and CTR 8300 :

l CLI supports comprehensive configuration, and must be used to:
o Change or add user names and passwords
o Configure congestion avoidance
o Configure ERPS
o Configure ECFM (EOAM, Link and Service)
o Configure MPLS
o Configure IS-IS
o Configure (advanced) OSPF
o Revert to factory defaults
l CTR Portal should be used to:
o Load SW, license, and configuration files
o Configure radio/links
o Set plug-in slots
o Set Bridge Mode
o Set Router ports
15 JULY 2017 AVIAT NETWORKS

o Configure basic OSPF

o Configure switch-port settings
o Configure QoS
o Configure VLANs
o Set local date and time
o View/access alarms, diagnostics, performance, events, statistics
o Configure L1LA
o Configure MEF 8 pseudowire (E1 only)
o Configure Synchronous Mode
Refer to:
l CTR CLI Guide on page 17
l CTR CLI Example Configurations on page 69
l CTR Portal on page 196

CTR CLI Guide

This section provides guidance on the use of the CLI. See:
l Useful Tips and Shortcuts on page 17
l Contexts on page 18
l Local Management Access on page 18
l Login on page 23
l Adding and Changing Users and Passwords on page 23
l Authentication, Authorization and Accounting (AAA) on page 25
l Configuration Save and Revert Timer on page 27
l Changing IP Address and Local Management Access on page 29
l To Set Bridge Mode on page 35
l To Enable or Disable a Port on page 40
l To Set Port MTU Size on page 41
l To Add or Remove a VLAN on page 42
l Revert to Default Config on page 44
l Slot Configuration on page 44
l SW Loading on page 45
l License Loading on page 47
l Date and Time on page 49
l Radio Configuration on page 49
l Network Connectivity on page 66
l Locate Me on page 67
l Useful Show Commands on page 67
Useful Tips and Shortcuts

Type ? (space then ?) at the end of an incomplete command to view the
keywords and arguments that can be used to complete the command.
Type ? with no space at the end of a partial command to view the commands
that begin with those characters.
Type q to exit a CLI list at the --More-- prompt to return to the aos prompt.
Tab key for command line completion. The first few characters of a command
word/string can be typed and the Tab key pressed to complete the rest of the
item, providing the first few characters typed are unique to the remainder of the
word/string.
Abbreviated forms of the CLI commands are accepted when the short version is
unique. For example:

c t for configure terminal

int for interface
swi for switch
gi for gigabitethernet
ra for radio
unt for untagged
One caution is sh; in some contexts it will be interpreted as show, in others as
shut.
Contexts
aos# (Aviat operating system) indicates the privileged exec mode. It is the
prompt presented upon successful login.
l To enter the global configuration mode enter c t (configure terminal)
at the aos# prompt e.g.. aos# c t, at which point a prompt of aos
(config)# is returned.
l To enter the VLAN configuration mode enter aos(config)# vlan
<VID>, at which point a prompt of aos(config-vlan)# is returned.
o <> brackets denotes the user must input values specified, in this
instance the VLAN ID.
l To enter the interface configuration mode enter aos(config)# int gi
<port number>,(e.g. aos#(config)# int gi 0/4) at which point a
prompt of aos(config-if)# is returned.
o gi 0/4 indicates Ethernet switch port 4.
l Other modes such as aos(config-swl)# for software loading, and aos
(config-switch)# for switch configuration are illustrated in the
following sections. For a full showing of contexts refer to the CLI
Reference Manual.
l Enter 'exit' to go back one prompt level i.e. enter aos(config-vlan)#
exit to go back to aos(config)#.
l Enter 'end' to return to the aos# prompt from any level.
Local Management Access

CLI management access to CTR is enabled via connection options of:
l Serial data to a front panel V.24 Maintenance port, or
l Telnet (or SSH) to a front panel Ethernet switch port
Either can be used for out-of-box access and configuration.

l Serial maintenance port access, unlike switch-port access, is agnostic
to changes of IP address.

o Where your laptop has a COM port, connect to the CTR RJ-45
Maintenance V.24 port using the CTR serial cable (DB-9 female to
RJ-45, 2m). This cable is available as an accessory from Aviat
Networks, part number 037-502517-001.
o Where you laptop does not have a COM port, connect using a serial
USB adapter.
n For CTR 8540 an external adapter is required. A suitable USB to
DB-9 male adapter is available as an accessory from Aviat
Networks, part number 009-440084-001.
o The serial USB adapter is used in conjunction with the CTR
serial cable to complete connection to the CTR Maintenance
V.24 port.
o The serial USB adapter from Aviat Networks is WIN 7, WIN 8,
MAC OS compatible. Separate driver software is not required.
n For CTR 8300 a built-in adapter behind the Micro USB
Maintenance port provides USB-to-serial conversion.
o PC to CTR connection is via a standard USB to micro USB
adapter cable.
n CTR 8300 also has a standard RJ-45 Maintenance V.24 port,
which like the CTR 8540 requires an external serial USB to DB-9
male adapter, and a serial cable to complete the connection.
l Ethernet switch-port access is provided using a standard RJ-45 to RJ-45
Cat5 cable. A suitable cable (2m) is available as an accessory from
Aviat Networks, part number 037-579124-001.
l Both Serial and Telnet (or SSH) require a terminal emulation program
such as freeware 'PuTTY'. Download and install your preferred terminal
emulation program from the relevant supplier. The application can be
pinned to your PC task bar for easy on-going access.
l Secure SSH network access to a CTR can be forced by turning off Telnet
access using the command:
aos(config)# no feature telnet
To re-enable:
aos(config)# feature telnet
Serial Port Access

Serial access is particularly applicable to initial out-of-the box connection,
changes to local management access, or changes to bridge mode.
Procedure:
l Check/set your PC COM port settings.

n Where an external serial USB adapter is being used (CTR 8540 or

CTR 8300), the adapter must be inserted into a USB port to be
recognized/configurable.
n Where the built-in serial USB adapter on CTR 8300 is being used,
a USB to micro USB adapter cable must first be inserted between
your PC and the CTR.
n If the device driver for the USB adapter in use is not installed on
your PC, Windows will attempt to find it on the Internet,
assuming your PC is set for automatic Windows updating (the
default setting). Ensure you have the required driver software
correctly installed before you go to site for the first time.
n If Windows cannot find driver software on the Internet for the
built-in adapter on CTR 8300, go to
http://www.silabs.com/products/mcu/pages/usbtouartbridgevcp
drivers.aspx and click on (save) Download for Windows
XP/Server 2003/Vista/7/8/8.1. From the saved folder extract the
files and click to run the required Application;
CP210xVCPInstaller_x64 for a 64-bit PC, or CP210xVCPInstaller_
x86 for a 32-bit PC. (An incorrect selection for x64 or x86 your
PC should be advised by your PC).
o From the Control Panel select Device Manager > Ports (COM & LPT),
followed by:
n USB Serial Port (COM#) > Port Settings, where a USB adapter is
being used, or
n Communications Port (COM#) > Port Settings, for a PC fitted
with a DB-9 COM port.
o Double click on the selected device to reveal the Port Properties
window.
o Click on the Port Settings tab and enter COM Port Settings of:
n Bits per second: 115200
n Data bits: 8
n Parity: None
n Stop bits: 1
n Flow control: None
o To set/change the COM port number, click on the Advanced tab in the
Port Settings window.
n The COM port number must be different for each serial
connection/adapter type. For example COM1 for the
Communications Port, COM3 for an external serial USB adapter,
and COM4 for the built-in serial USB adapter on CTR 8300.
l Open and set the terminal emulator settings. Using PuTTY, the basic
options to load are:

o Connection Type: Serial

o Serial line: COM #, where # must be set to match the COM port
number assigned under the PC COM Port settings for the
connection to be used.
o Speed: 115200
Save these settings under a name such as: CTR serial3.
l With the appropriate Serial connection settings loaded in PuTTY, click
Open.
l At the login prompt enter root (the default user name), followed by
the password (default: admin123 ). See Login on page 23.
Switch Port Access

Management access from your PC to a front panel CTR port is enabled using a
VLAN interface (switched virtual interface), where the interface is configured for
out-of-band (OOB) management and assigned an IP address.
l Only one active management VLAN interface is permitted; this is the
Management VLAN Interface.
l The designated interface is fixed for management access purposes. It
cannot be used for user traffic.
l This OOB management access is default provided on VLAN 2, on switch-
port 1, using a static IP address of 192.168.1.1/255.255.255.0.
l The management VLAN ID, interface, and IP address can be
reconfigured as needed. See Changing IP Address and Local
Management Access on page 29.
l For network management using Aviat's ProVision EMS, or similar, in-
band NMS is employed whereby the management VLAN is transported
within the traffic data stream and the data interface or interfaces on the
CTR are configured as in-band management ports. This process adds
these interfaces to the management VLAN.
Local CLI access to the management interface is enabled through a terminal

emulator on your PC, such as PuTTY. However, your PC must first be set for a
LAN-compatible IP address (your PC must operate as a device on the same LAN
as the CTR).
Setting a Compatible IP address (Windows 7):

l Connect your PC to CTR switchport 1 using a standard RJ-45 to RJ-45
Cat5 cable.
l Click on the Internet Access icon in the System Tray, then on Open
Network and Sharing Center. Or from the Control Panel select
Network and Sharing Center.
l Under Access Type Internet select Local Area Connection, which

brings up Local Area Connection Status.

l Select Properties
l Highlight Internet Protocol Version 4 (TCP/IPv4) and click Properties
to display the Internet Protocol (TCP/IP) Properties window.
l Proceed to CLI Access Procedure below.
NOTE: Be fo re ma ki n g a n y ch a n g e to th e se tti n g s i n th i s w i n d o w , re co rd a n d
re ta i n th e e xi sti n g se tti n g s, w h i ch ma y p e rta i n to yo u r co mp a n y L AN .
o Select Use the following IP address, and in the IP address field
enter a LAN compatible IP address for the CTR, such as
192.168.1.2.
o Set a Subnet mask of 255.255.255.0 (same as the CTR).
o Setting a Default gateway only applies where other CTRs on the
same LAN are to be viewed via this connection.
o Click OK, OK ... on exit.
Connection
CLI access from your PC is enabled through use of a terminal emulator, such as
PuTTY.
l Open and set the terminal emulator settings. Using PuTTY, the basic
options to load for a Telnet session are:
o IP address: 192.168.1.1 (CTR default IP address)
o Connection type: Telnet
o Port 23
Save these settings in PuTTY under Saved Sessions using a name such
as: CTR Telnet.
l Fit an RJ45 cable from your PC to the CTR front panel switchport 1.
l Open PuTTY, load the saved CTR Telnet session, and click Open.

l At the login prompt enter root (the default user name), followed by
the password (default: admin123 ). See Login on page 23.
NOTE: SSH ac c es s is s upported us ing C onnec tion ty pe: SSH , and Port:
22. At login y ou may be pres ented w ith a s ec urity alert notice w ith options
to add the hos t k ey to PuTTY' s c ac he. Selec t the Yes option.
Login
When a CLI session is opened you will be presented with the login (user name)
and password prompts.
For a new installation enter the default user name of root, followed by the
default password of admin123 , at which point the CTR 8500 or CTR 8300 End
User License Agreement is presented together with the terms by which you
enter into this agreement. This is followed by the aos# (Aviat operating system)
prompt, at which point the CTR is available for configuration.
l The End User License Agreement is presented as a one-time event after
power-up, and unless accepted, any subsequent reboot.
New user names and passwords can be created and assigned to individual users
after Login.
You will be logged out automatically after a period of being logged in without
activity: Idle Timer expired, Timing Out !!!
Otherwise you will be logged out when closing your terminal emulation program
e.g. 'PuTTY'.
Adding and Changing Users and Passwords

NOTE: Fo r stro n g syste m se cu ri ty th e a d mi n i stra to r sh o u l d ch a n g e th e ro o t
u se r p a ssw o rd to a se cu re , co n fi d e n ti a l p a ssw o rd .
Administrative Privilege
The default root user password of admin123 provides executive access
(privilege level 15).
l The root user has full administrative privileges and can access all
aspects of the system.
l The root user cannot be deleted, but the default root user password can
be changed.
l The administrator must log in as a root user to create or delete other
users, or to change user passwords.
The default guest user password for limited-privilege access is guest123 (view-
only, privilege level 1).

NOTE: Currently only privilege levels 15 and 1 are supported. Entry of a level
between 1 and 15 will result in view-only access (level 1).
Local User Access

Under root user access, new users and passwords can be created and deleted in
the system using the following commands. Passwords must be between 8 and 32
characters long and contain at least one letter, one number, an alpha-numeric
character, and at least one lower and one upper case character. A new password
must have at least 4 characters different from the old password.
To change a password:
aos# c t
aos(config)# username <user name> password <new password>
aos(config)# config save
For example: username root password Admin3213$ disables the default root
password of admin123, and replaces it with Admin3213$.
To create an additional user name and to set its password and privilege level:
aos(config)# username <user name> password <password> privilege <1-15>
For example: username admin password Net3443* privilege 15 creates the user
name of admin with a password of Net3443* and a privilege level 15 for full access
rights.
Other related commands:
To delete a user and password (a currently active user cannot be deleted):
aos(config)# no username <user name>
To change a user privilege level:

aos(config)# user name <name> privilege <new privilege level>
ProVision Access
To access a CTR device under Aviat's ProVision EMS, SNMP must be enabled on
the CTR and a local user account established.
l The network administrator should determine the policy for SNMP
access, user-name, and password setting.
SNMP access is controlled through read and write SNMP community strings,
which define the relationship between the ProVision SNMP server and the CTR -
they act like passwords to control CTR's access to the server.
Procedure:
Configure the following on each CTR device. Refer to the CTR 8500/8300 CLI
Reference Manual for details.

l We recommend using the same values on each CTR, simplifying the

configuration and maintenance of passwords on ProVision. This also
provides the ability to use network auto discovery.
l For improved security, we also recommend using a different value
from the commonly used “public” / “private” values.
l The following example indicates the CLI commands required to enable
SNMP and configure read community string value “public1” and write
community string value “private1” on a CTR device:
aos# c t
aos(config)# snmp-server view all 1 included
aos(config)# snmp-server community public1 version both read all notify all
aos(config)# snmp-server community private1 version both read all write all
notify all
aos(config)# end
LLDP
LLDP is default enabled on CTR 8540 and CTR 8300 to allow bridges to advertise
their capabilities, and to learn about the capabilities of other devices on the
same LAN. It is used by ProVision to provide a unified network management
view of the LAN topology and connectivity for network administration and
trouble-shooting. The CTR implementation conforms to IEEE 802.1AB (2005).
l A network administration station connected to one bridge is able to
access connectivity information on the complete network.
l The information is sent using LLD Protocol Data Units (LLD PDUs).
The following show commands are available to view LLDP status:

aos# sh lldp
aos# sh lldp neighbors
aos# sh lldp neighbors detail
Authentication, Authorization and Accounting

(AAA)
Authentication, Authorization, and Accounting (AAA) of user login may be
performed by TACACS+ (Terminal Access Controller Access Control System
Plus). With TACACS+, the login credentials of users are stored on a remote AAA
server, which is interrogated when a user attempts login. The user's name and
password are authenticated and if this is successful, the user's stored privilege
level is obtained. Then, depending on the success of the last step, the user’s
access is authorised at that privilege level.
Additionally, TACACS+ provides a method to log information concerning login
sessions and command execution at the remote server (Accounting).

The out-of-box default is for TACACS+ to be disabled and for local login to be
enabled. The following sections describe how to enable the TACACS+ functions.
Remote Server Configuration

Successful TACACS+ operation requires the remote server to be configured
appropriately. This configuration is performed via whatever interface the
remote server application provides and is not described in detail here. Following
are some guidelines for server configuration:
l The CTR can support up to three TACACS+ servers simultaneously.
l The key shared between the CTR and the server must be configured.
l The user’s name and password must be configured.
l The user's privilege level must be configured by the ‘service = system’
AV pair.
l If Accounting is required, the server configuration must define the
accounting file location.
The following is an extract from a typical TACACS+ server configuration file:

# Define where to log accounting data
accounting file = /var/log/tac_plus.acct
# This is the key that clients have to use to access Tacacs+
key = "5h8s4y%E^o8*"
# admin group and privilege level of all members
group = admin {
service = system {
default attribute = permit
priv-lvl = 15
}
}
# user 'root' is member of group 'admin'
user = root {
member = admin
login = cleartext "password123"
}
Configuring TACACS+ to Perform AAA

Configure one to three TACACS+ servers
aos# configure terminal
aos(config)# tacacs-server [<index(1-3)>] address {<ipv4-address>
| <ipv6-address>} [port <tcp-port(1-65535)>] {key <secret key>}
NOTE: The port number defaults to 49 if omitted.

Configure the server timeout:

aos(config)# tacacs-client timeout {<seconds(1-10)>}
Configure TACACS+ as AAA method:
aos(config)# login authentication tacacs [local]
The addition of the optional ‘local’ configures fall back to the local login method,
if the configured TACACS+ servers are unable to be contacted.
Configure TACACS+ Accounting if required:
aos(config)# aaa accounting login tacacs
Deconfiguring TACACS+
Deconfigure a TACACS+ server so it is no longer used by the CTR:
aos(config)# no tacacs-server [<index(1-3)>]
Configure local AAA method (instead of TACACS+):
aos(config)# login authentication local
Deconfigure TACACS+ Accounting if required:
aos(config)# no aaa accounting login tacacs
Show Commands
Show configured TACACS+ servers:
aos# show tacacs-server [<index(1-3)>]
Show configured AAA method:
aos# show aaa
Configuration Save and Revert Timer

NOTE: C ommands entered under C LI are immediately committed, but
unless s av ed w ill be los t during any pow er-c ycle event. On restoration of
pow er the previously saved c onfiguration w ill be applied.
To save the current config:

aos# c t
The revert timer function should be used where planned configuration changes
may cause loss of management connectivity or remote-end connectivity, or
where there is potential for the change to disorder or corrupt an existing
configuration.

l The revert timer captures a snapshot of the current config, which will
be returned as the operating config if the timer is allowed to expire.
l While the revert timer is active, it will reset to its original time-out
value every time a configuration change is made (but the snapshot
remains as that which was captured at the revert-timer command).
l If a config save command is entered before timer expiry, the timer
function is aborted.
l If the timer is allowed to expire the terminal is rebooted and returned
with the snapshot config.
l A revert-cancel command is available to rescind the return to the
snapshot providing it is set within the time-out period after login
following the re-boot.
o This command applies after the terminal has rebooted and you have
determined there are no issues that require a revert to the saved
snapshot.
To set the revert timer:
aos# c t
aos(config)# revert-timer <seconds>
To cancel the revert timer:

aos# c t
aos(config)# no revert-timer
CLI Script Entry

Text-based scripts can be entered, as in this example.
The following script, copied from a Word document, is pasted (mouse right-
click) against the aos# prompt. The command-line context is not included (is not
required) in the script (for a valid script the context is auto sensed/entered).
configure terminal
switch default
set gvrp disable
set gmrp disable
shutdown garp
shutdown spanning-tree
no ethernet cfm start
bridge-mode customer
end
The resultant command set is accepted and displayed as follows:
aos(config)# switch default
aos(config-switch)# set gvrp disable
aos(config-switch)# set gmrp disable

aos(config-switch)# shutdown garp

aos(config-switch)# shutdown spanning-tree
aos(config-switch)# no ethernet cfm start
aos(config-switch)# bridge-mode customer
aos(config-switch)# end
Changing IP Address and Local Management

Access
The required management VLAN and switch port access should be configured
after initial turn-on.
Default IP management access is provided as out-of-band (OOB) on port 1,
VLAN 2.
l PC access to a switch port requires a dedicated port setting of:
management out-of-band.
The following examples show:

l How to show the default management VLAN 2 and its IP address
l How to show the default config for switch port 1.
l How to change/add management access
NOTE: For out-of-box c onfiguration us e the serial cable, as its connection
is management port and IP-addres s agnos tic .
o If the CTR is accessed using a Telnet session on switch port 1, and
the management port/VLAN or terminal IP address is changed, you
will drop connection.
o Where the IP address is changed you will likely need to reset the
TCP/IP settings on your PC to restore a compatible LAN connection.
NOTE: W hen adding (ac tiv ating) a port, its ty pe must be explicitly
specified as untagged for it to be able to trans mit frames w ith and w ithout
a VLAN tag. If untagged is not s pec ified it w ill be configured as a tagged
port ty pe and allow trans mis s ion only of frames w ith a specified VLAN
tag.
NOTE: The 192.168.255.x /24 s ubnet is res erved for internal use by the
sy stem s oftw are. The us er is res tric ted from configuring IP addres ses in
this subnet in AOS.
NOTE: Management ac c es s to the C TR s hall only be pos sible through the
default VR F. Management ac c es s v ia c us tomer VR F IP addres ses, or by
interfac es bound to c us tomer VR F is not permitted.
Output:
aos# show ip vrf

Virtual Context Table

---------------------
VcId VRF-Name Interfaces
---- ------- ----------
0 default vlan1, vlan2
Out-of-Box Defaults
Use these show commands to view current and subsequent changes to
management access.
To view the current configuration:
aos# show running-config
To confirm/show the current management VLAN 2 and its IP address:

aos# sh run int vlan 2
#Building configuration...
interface vlan 2
ip address 192.168.1.1 255.255.255.0
NOTE: The default VLAN 1 c annot be deleted. It is default not ass igned
to a port.
To confirm/show the current config for switch port 1:

aos# show qos global info
#Building configuration...
interface gigabitethernet 0/1
no shutdown
map switch default!
interface gigabitethernet 0/1
switchport pvid 2!
To show the current management VLAN and port, and port type:
aos# show management
Current Management vlan = 2
Member ports: Gi0/1
Port type: out-of-band
See Useful Show Commands on page 67.
Resetting Local Management Access

The following examples illustrate options available to change default local
management access settings.
To save changes made:
aos (config)# config save

NOTE: A rev ert timer func tion is av ailable to avoid loss of acc ess as a
result of c onfiguration c hanges that may c ause loss of connectivity. See
Confi gurati on Save and Revert Ti mer on page 27.
To reset the ip address for the default management VLAN, VLAN 2:

aos# c t
aos(config)# int vlan 2
aos(config-if)# ip address <ip address> <mask>
aos(config-if) end
The following example illustrates management access change for port, VID, and
IP address:
l Switch port 4 is to be activated and set as the local management access
port
o When a port is activated its context (name of the switch) must be
specified. Currently this must be specified as: map switch default.
l VLAN 101 is to be set as the management VLAN (on port 4)
o For out-of-band (local PC) management the VLAN must be specified
as: untagged
l Management (terminal) IP address is to be set as 192.168.4.52
255.255.255.0
l VLAN 2 is to be shut down
To activate port 4 and set it as an out-of-band management port:

aos(config)# int gi 0/4
aos(config-if)# map swi default
aos(config-if)# no shut
aos(config-if)# management out-of-band
aos(config-if) end
To configure VLAN 101 on port 4 and set it as management VLAN (replacing

VLAN 2):
aos(config)# vlan 101
aos(config-vlan)# ports gi 0/4 untagged gi 0/4
aos(config-vlan)# management
aos(config-vlan)# end
To activate VLAN 101 and assign it an IP address:

aos(config-if)# ip address 192.168.4.52 255.255.255.0
aos(config-if) no shut
aos(config-if) end
To verify IP address:
aos# show ip int
To remove the default IP address from the default management VLAN, VLAN 2:
aos(config-if)# shut
aos(config-if)# no vlan 2

aos(config-if) end
Because your PC is not VLAN aware, this process of changing the management
port and VID will also add the default VLAN 1 to the port 4 management port,
and add the management VLAN 101 to port 1.
To remove the VLAN 1 port association:
aos(config)# vlan 1
aos(config-vlan)# no ports
To remove management VLAN 101 from port 1:

aos(config-if)# no management
aos(config-if)# end
Adding In-Band Management Access

Management access via a network connection will typically be provided in-band
on the assigned management VLAN. The following example illustrates activation
of port 3 and its inclusion as an in-band management port. If the port is already
up, only the management instruction is required (1st and 4th lines).
This instruction must be repeated for all ports used for transporting the
management VLAN, which if via radio or PoE connections must include such
ports.
aos(config-if)# management
aos(config-if)# end
This process of adding a management port will also add the default VLAN 1 to
port 3.
To remove the vlan 1 port association:
aos(config)# vlan 1
aos(config-vlan)# no ports
Routed Management
Routed management using OSPF is an option available from SW release 3.0
onwards. It is particularly applicable in CTR 8500 and CTR 8300 networks
extended from Eclipse or other network devices using routed management.
l OSPF provides the dynamic routing function - NMS interfaces are
configured for OSPF.
The following example illustrates basic CTR 8540 / Eclipse MNS interoperation.

l Eclipse and CTR 8540 #1 are on the same subnet, with an Ethernet
cable connection between Eclipse DAC GE3 and CTR port 1.
l On Eclipse, an in-band bridged mode NMS connection is configured
between the NCC and DAC GE3 modules. Alternatively a RJ-45 cable
connection can be used between the NCC and DAC GE3 front panel
ports. Eclipse is configured using its Portal craft tool.
o In the Networking screen Interface addressing is used with OSPFv4
is selected on the required interfaces.
o Eclipse NMS is assigned to VLAN 2, priority 7 in the Networking > In-
Band screen.
l The co-located CTR 8540 #1, is port 1 connected to the Eclipse DAC
GE3.
o VLAN 2 on port 1 is the default local OOB NMS port. This is reset for
in-band management. VLAN 2, the default management VLAN, is
retained.
o OSPF is configured on port 1 and on the radio interface ra 2/1.
l On CTR 8540 #2 OSPF is configured on the radio interface ra 2/1. The
management PC is connected to the default OOB management port; gi
0/1, VLAN 2. A default gateway should be set on the PC (192.168.5.1),
otherwise static routes can be set to provide access to the remote
terminals.
Figure 1. Simple CTR-Eclipse Routed Management Example
CTR 8540 configuration preconditions:

l CTRs are out-of-box i.e. have default factory settings:

o IP management access is provided as out-of-band (OOB) on port 1,
VLAN 2.
o Bridge Mode is Customer Bridge.
l Install a RACx2 module in slot 2.
l Install a Carrier Ethernet feature license.
l Install relevant radio link RAC/RFU capacity, and ACM licenses.
l Configure radio link parameters using CLI or CTR Portal.
Eclipse Configuration
Eclipse NMS is assigned on VLAN 2 and included on the DAC GE3 trunk port
connection to the co-l0cated CTR 8540 #1.
l A bridged in-band connection is configured in the Networking > Inband
NMS screen with a user designated VID (2) and CoS priority (7). The
resulting VLAN is viewable in the DAC GE3 VLAN screen under VLAN
Membership, with a port designation of NMS. For configuration
information refer to the Eclipse User Manual > Volume 4 > Networking.
l In the Networking screen Interface addressing is selected, and on the
required interfaces IP addresses entered and OSPFv4 enabled.
CTR 8540 #1 Configuration
Change the IP address of the management interface (default port: gi 0/1) so

that the VLAN 2 interface IP address is on the same subnet as the Eclipse
Ethernet interface (192.168.3.1/24).
aos# c t
aos(config-if)# ex
Enable radio interface 2/1 and set an IP address of 192.168.121.1:

aos(config)# int ra 2/1
aos(config-if)# no map switch default
aos(config-if)# no switchport
aos(config)# ex
Set port 0/1 as an in-band management port:

aos(config-if)# ex
Enable OSPF, set router ID, and add networks into routing table:
aos(config)# router ospf
aos(config-router)# router-id 192.168.3.2
aos(config-router)# network 192.168.3.2 area 0.0.0.0


aos(config-router)# end
CTR 8540 #2 Configuration
Set VLAN 2 interface IP address (on default OOB local management port gi 0/1):
aos# c t
aos(config-if)# ex
Enable radio interface 2/1 and set an IP address of 192.168.12.1:

aos(config)# ex
Enable OSPF, set router ID, and add networks into routing table:
aos(config)# router ospf
aos(config-router)# router-id 192.168.5.1
To verify the OSPF routing table on the CSRs, and that the subnet has been
learnt:
aos# sh ip ospf route
To Set Bridge Mode

A bridge mode selection applies to all bridge ports. Applicable bridge modes
are:
l Customer Bridge customer. This is the default VLAN-aware mode for
untagged and/or tagged traffic.
o The default port type is Customer Bridge Port
o The base-bridge mode is default set for 802.1q VLAN aware. 802.1d
transparent mode is an option.
l Provider Bridge Edge provider-edge. Enables tunneling of customer
VLANs over a service provider VLAN - a service tag is added to a
customer VLAN tag (QinQ).
o The default port type is Provider Network Port, which does not
support the 'out-of-band' setting needed to allow local PC
management access.
o To allow local PC management access, the port type for

management access must be reset to Proprietary Provider Network

Port. See Port Type below.
o An example of provider edge bridge operation is shown at Provider
Edge Bridge Mode on page 96.
l Transparent Bridge transparent. Provides operation that is transparent
to the network hosts.
o Traffic is forwarded based solely on the learned source MAC address
of incoming frames from all attached networks - incoming frames
are re-directed based on the learned address of connected hosts
(addresses are held in the MAC address table).
o Source and destination information in the frame headers is not
modified.
CAUTION: When changing between customer bridge and provider edge bridge
modes, factory defaults must be restored before the mode change is made. This is to
ensure the existing configuration is fully erased before the change.
Provider Edge Bridge
To configure the bridge from the default Customer mode to Provider Edge, first
revert to factory defaults:
l Restore factory defaults (see Revert to Default Config on page 44):
aos(config)# config load factory-defaults revert-timer <seconds>
Wait for the reboot to complete, login, and cancel the revert timer:
l Disable the following non-applicable protocols:
aos(config)# sw default
aos(config-switch)# no ethernet cfm start
aos(config-switch)# exit
l Set Provider Edge mode:
aos(config)# bridge-mode provider-edge
To verify the bridge mode:

aos# show vlan device info
For more information see: Provider Edge Bridge Mode on page 96.
l Set local management port to propProviderNetworkPort to enable
local PC management access (see Port Type on page 39):
aos(config-if)# bridge port-type propProviderNetworkPort
aos(config-if)# end
l Set radio port to provider network port:

aos(config)# interface ra 1/1

aos(config-radio)# bridge port-type providerNetworkPort
aos(config-radio)# exit
l Assign port 0/1 and radio 1/1 to VLAN ID (VLAN ID is 40 in this
example):
aos(config-vlan)# ports gigabitethernet 0/1 ra 1/1 untagged
gi 0/1
aos(config-vlan)# exit
l On port 0/1 configure the switchport PVID and activate port (VLAN ID
is 40 in this example):
aos(config)# interface gigabitethernet 0/1
aos(config-if)# switchport pvid 40
aos(config-if)# no shutdown
aos(config-if)# exit
l Activate radio 1/1:
aos(config)# interface ra 1/1
aos(config-radio)# no shutdown
aos(config)# end
Customer Bridge
To return to Customer mode from Provider Edge, first revert to factory defaults:
l Restore factory defaults (see Revert to Default Config on page 44):
l Set customer mode:
aos(config)# bridge-mode customer
To verify the bridge mode:

Transparent Bridge
Transparent bridge is not a native mode. It operates through a port membership

configuration on a customer bridge to ensure tagged and untagged traffic is
forwarded without modification.
Operation is enabled by:
l Creation of VLAN 4094 to which all ports are added. All ports are set for
a PVID of 4094 so that all untagged frames are internally tagged as
VLAN 4094 at ingress, and stripped at egress, to provide transparent
communication.
l The adding of all ports to VLAN 1, for which transparent VLAN mode is

enabled. As all port members belong to VLAN 1 they are included in the
same broadcast group and VLAN tags are ignored. Hence,
communication between the ports is 'transparent' - all tagged frames
received on one member port are forwarded to all other member ports
of VLAN 1.
l The creation of VLAN 4094 and associated adding of all ports, and the
transparent mode setting on VLAN 1 and associated adding of all ports,
is established using the command: set transparent enable.
l To disable transparent mode: set transparent disable
The following procedure is based on:

l Commencement from factory default settings. If the CTR has been
configured away from factory default settings see: Revert to Default
Config on page 44.
l Log-in via a serial connection.
l Pre-installation of required plug-in modules (CTR 8540 only).
To enable transparent mode:

aos(config)# set transparent enable
CAUTION: This command removes local (out-of-band) management connectivity.
Under transparent mode local out-of-band management access is lost;

management becomes in-band because all port PVIDs are changed to 4094.
To reset local management connectivity see: Reestablishing Local Management
Access on page 39
To enable management (in-band) see: Adding In-Band Management Access on
page 32.
NOTE: N OTE: On C TR 8 5 4 0 a l l e n a b l e d sl o t i n te rfa ce s (POE a n d R a d i o )
sh o u l d b e a d d e d a s ma n a g e me n t (o n a tra n sp a re n t mo d e C TR ).
If a plug-in module is subsequently installed into a CTR8540, its interface(s)

must be manually added to support transparent mode. The following example is
for a RACx2 module in slot 1, with both ODU ports added:
aos(config-vlan)# ports add radio 1/1-2 untagged radio 1/1-2
aos(config)# vlan 1
aos(config-vlan)# ports add radio 1/1-2
If these radio ports are also used for in-band management then add:
aos(config)# int radio 1/1

To confirm VLAN status:

aos# show vlan
and
aos# show vlan port config
Port Type
A port type selection configures the bridge port type. Applicable types include:
l Customer Bridge Port customerBridgePort. This is the default port
type for a customer bridge and a provider bridge. Management access
can be 'in-band' or 'out-of-band'.
l Customer Edge Port customerEdgePort. This is the default port type
for a provider edge bridge. This port type only supports 'in-band'
management access.
l Proprietary Provider Network Port propProviderNetworkPort. This
option is required to enable 'out-of-band' management access when the
bridge mode is provider edge.
l Provider Network Port providerNetworkPort. This option is applicable
in provider bridges. The port is connected to a single provider.
Management access is 'in-band'.
l Customer Network Port customerNetworkPort. Sets the bridge port
type as customer network port. It has the following options:
o port-based
o s-tagged
o c-tagged
Example: to change port type on port 0/2 to propProviderNetworkPort:
aos(config-if)# end
To verify port type:

aos# show int
Reestablishing Local Management Access

The following procedure can be used to regain local PC management access.
l This example describes how to establish local PC management access
after a mode change to Provider Edge Bridge or Transparent Bridge.
l In this example factory defaults are used/restored:
o VLAN 2 on port 1 is set for management out-of-band.
o VLAN 2 IP address: 192.168.1.1.

NOTE: Where the default management VLAN 2 is not used/required on an out-of-

box CTR, it can be deleted using: aos(config)# no vlan 2. This would apply in
instances where the management VLAN is assigned a different number.
This first step only applies to a Provider Edge Bridge, where the port type must
be changed to Prop Provider Network Port to support management out-of-band.
To activate port 1, and change port type to Prop Provider Network Port:
The subsequent steps are used to re-establish management out-of-band on port

1 for the Provider Edge Bridge, or Transparent Bridge.
Assign port 0/1 to management VLAN 2:
aos(config)# vlan 2
aos(config-vlan)# management
Activate VLAN 2 and assign it an IP address:

aos(config-if) no shut
aos(config-if) exit
Activate port 0/1 for management out-of-band:

aosconfig-if)# management out-of-band
aos(config-if)# end
To verify IP address:
aos# show ip int
For more information see: Changing IP Address and Local Management Access
on page 29.
To Enable or Disable a Port

Where the port to be enabled is on a plug-in module e.g. RAC or PoE, the slot
must first be configured. See Slot Configuration on page 44.
To enable a switch port e.g port 2:
aos(config-if)# map switch default
aos(config-if)# end

To enable a PoE port e.g. port 1 on a PoE module in slot 3, and set a max power
e.g. 60W:
l Max permissible power is 70W
l An alarm will be raised if the power draw exceeds the set max
aos(config-if)# power inline auto max 60000
aos(config-if)# end
To enable a radio port e.g. port 1 on RACx2 module in slot 2:

aos(config-if)# end
To disable a port e.g. port 2:

aos(config-if)# end
Alternatively, to disable a port e.g. gi o/2:
aos(config-if)# shutdown
aos(config-if)# end
To view port status:

aos# show interfaces
To view PoE port status and configuration:

aos# show power inline
To configure a range of ports e.g. switchports 9 to 12:

aos(config)# int range gi 0/9-12
aos(config-if-range)# map switch default
aos(config-if-range)# no shut
aos(config-if-range)# end
To verify port status:

aos# show int description
To Set Port MTU Size

This command sets the MTU (frame size) for all frames transmitted and
received on an interface. The value ranges between 46 and 10214 bytes. The
default MTU from SW release 3.0 is 1542 bytes, to provide accommodation for
VLAN and MPLS tagging.
l If a specific MTU size was not set in a prior SW release, upgrading to
3.0 will reset the default to 1542 bytes (from 1500 bytes). Conversely,

if a specific MTU size was set in a prior SW release, the set size will be
retained in the 3.0 upgrade.
l The MTU defines the largest frame size that can be passed by an
interface without the need for fragmentation.
l Its configuration requires the interface(s) to be shutdown (If the
interface selected is not enabled, its shutdown is not required).
To set MTU on a specified (enabled) interface e.g. gi 0/2:

aos(config-if)# shut
aos(config-if)# mtu 9216
aos(config-if)# end
To view interface MTUs:

aos# show int mtu
NOTE: In C TR , the Max imum Trans mis s ion U nit (MTU ) setting applied to
an ethernet port or Inter VLAN R outing (IVR ) interface configures the
pay load w hic h lay er 2 c an ac c ept from the next higher layer. The default
MTU for ethernet and IVR interfac es in C TR is 1542 bytes. This w as
chosen to enable mos t internet applic ations to w ork over MPLS VPN
servic es . In the implementation of many other vendors, the interface MTU
is us ually tak en to be the max imum lay er 2 pack et size including layer 2
enc aps ulation. W hen inter-operating agains t suc h equipment, the
interfac e MTU v alue on C TR w ill hav e to be changed in order for IP
routing and MPLS protoc ols to inter-operate. For example, w hen w ork ing
w ith a dev ic e w hic h us es the different definition of MTU and a default
value of 1500 By tes , the MTU on C TR s hould be set to 1486 bytes.
To Add or Remove a VLAN

NOTE: VLAN c onfiguration (ex c ept management VLAN ) is bes t performed
us ing C TR Portal rather than C LI. It is eas ier/fas ter.
To add a member port or ports to a VLAN e.g. VLAN 7 on ports 2 to 5, with ports
2, 4, 5 supporting tagged operation, and port 3 untagged:
aos(config)# vlan 7
aos(config-vlan)# ports add gi 0/2-5 untagged gi 0/3
l If a port is not specified as untagged it permits transmission (egress) of
frames with its specified VLAN tag (VID).
l If a port type is specified as untagged, frames are sent (egressed)
without a VLAN tag. Typically used on ports connected to an end-user
device, such as a PC.
l If 'add' is not included in the command, as in ports add gi 0/2, then any

other ports that were configured in the VLAN membership will be

deleted.
To view the details of a particular VLAN e.g, VLAN 7:

aos# show vlan id 7
To view the details of all VLANs:

aos# show vlan
To remove a port from VLAN membership e.g. port 2 from VLAN 7:

aos(config)# vlan 7
aos(config-vlan)# no ports gi 0/2
NOTE: VLAN 1 c annot be remov ed.
To remove an untagged port from a VLAN e.g. port 3 from VLAN 7:

aos(config)# vlan 7
aos(config-vlan)# no ports gi 0/3 untagged gi 0/3
To remove a VLAN e.g. VLAN 7:

aos(config)# no vlan 7
To remove the management VLAN from a port e.g port 2:

aos(config-if)# no management
aos(config-if)# end
To set a PVID on a switch port:

l The PVID represents the VLAN ID e.g. 35, that is to be assigned to
untagged frames received on the port e.g. port 0/2.
l Untagged frames ingressing the port are forwarded within the switch
with a VLAN ID of 35.
l At egress on this port, tagged frames with a VLAN ID of 35 have their
tag stripped.
aos(config-vlan)# ports add gi 0/2 untagged gi 0/2
aos(config-if)# end
To set a VLAN priority (CoS) on the configured VLAN (PVID 35):

l The default priority is 0; the required priority in this example is 5.
aos(config-if)# switchport priority default 5
aos(config-if)# end
To check the default priority:

aos# show vlan port config port gi 0/2

l For comprehensive guidance on VLANs and QoS refer to the relevant

CTR 8500/8300 VLAN Configuration Guides.
l For an introduction to QoS configuration see QoS on page 69.
NOTE: When a port is set as a trunk port it becomes a member of all VLANs. The
VLAN setting for such a port should not be directly modified at the VLAN level as
this may trigger errors. Instead the command "switchport trunk allowed vlan
add/remove vlanid" should be used. Normally this command would only be used
to remove a VLAN on a trunk port - or add it back in.
Revert to Default Config

A command to return to factory defaults is provided.
l The command automatically reboots the terminal.
l The command includes a revert timer function, which unless activated
after reboot within a set time e.g. 500 seconds, will restore to the
configuration prior to the restore action.
To revert to the out-of-box default factory settings:

Slot Configuration
To set the expected plug-in module for a CTR 8540 slot. Applies to:
l POEx2 - Dual Power over Ethernet
l PWR - Redundant Power Supply
l PWRAUX - Redundant Power and Auxillary (not available at SW release
3.4)
l RACx1 - Single Radio Access
l RACx2 - Dual Radio Access
Example: configure slot 2 to expect a PoEx2 module:

aos(config)# slot 2 PoEx2
To disable a slot allocation e.g. a PoEx2 installed in slot 2:

aos(config)# no slot 2
To show information on the expected and detected plug-in modules:

aos# show slot

SW Loading
NOTE: SW loading is bes t performed us ing C TR Portal rather than C LI. It
is eas ier/fas ter.
When using CLI the operating SW is installed from a server whose location and
the required SW build is specified during the SW loading process. Telnet
connection to the CTR management port is required (do not use the serial V.24
Maintenance port).
l The following procedure is based on downloading a SW pack to your PC,
copying it to an http server on your PC, from where it is accessed and
installed on a CTR terminal.
l Once a terminal is operating within a network, new (updating) SW
would normally be installed remotely from a server located at the
network hub, using ProVision or other network management system.
A suitable freeware server for PC-based delivery is Lighty2Go. Go to

www.lighty2go.com. This is a portable LightTPD, MySQL & PHP (LiMP) stack,
which downloads (saves) as a 7-Zip file. Right-click and select Extract All to
reveal/save the stack to a folder location of choice.
l You will need to have 7-Zip (freeware) installed. Go to www.7-zip.org.
l Other freeware server options include lighttpd, nginx, apache. Unlike
the portable Lighty2Go, these are installed as programs on your PC and
will need setup to provide required connectability.
Applicable CLI commands for SW loading at a new installation are:

l show swload - to view the current SW load, and the loading process.
l swload - to set the context for SW loading.
l load-uri - to set the Uniform Resource Identifier (URI) of the SW pack
(.swpack) file.
l activate - to activate a SW pack that has been loaded using the load
command.
l rollback - to return to the SW prior to the last SW activation process.
l rollback-timeout - to set a SW load rollback timeout (in seconds).
o This can be useful to safe-guard against problems with new SW that
prevents a manual rollback.
o It should be used in conjunction with a no-rollback command to
cancel the rollback when not needed i.e. where the new SW load is
confirmed OK.
l abort - to abort a SW load prior to its activation.
For more SW load options, such as the activation timer, refer to the CTR
8500/8300 CLI Reference Manual.

NOTE: User configurations are retained for the current and prior SW versions.
Reversion to a prior version will install the configuration last saved with that
version. Similarly, return to a latter version will load the configuration saved
with that version - changes made while operating under an earlier version will
not be carried into latter versions.
l When a new SW version is loaded a configuration upgrade only runs
once; on the first boot up following the upgrade to the new version.
l From this point onwards the current and prior configurations are
completely independent.
l This means that if software is reverted to a previous version, any
changes to configuration made under this version will not be available
on the latter version after a subsequent return (reload) of the latter SW
version. Rather the configuration that was last used on that latter
version will be loaded.
Additionally, a configuration upgrade to a new SW version will always be to the

configuration saved under the next most recent software version that it can find,
regardless of which software was previously active.
l For example, where a CTR has configuration sets for software versions
2.2 and 2.4, but software version 2.2 is active (i.e. software had been
reverted at some point), a subsequent software upgrade to version 3.0
will upgrade with the 2.4 configuration set, regardless of the fact that
the most recent configuration used was from version 2.2.
Recommendations:
l Software should always be upgraded in ascending version order; avoid
rolling back to older versions where possible.
l If software version rollback is unavoidable, any configuration changes
made under the earlier software version will need to be reapplied after
subsequent software upgrade.
Procedure
This procedure is based on use of portable server Lighty2Go.
l Copy the downloaded CTR SW pack file (.swpack) to the HTDOCs folder
within the Lighty2Go folder.
o The SW pack will be automatically identified and installed from this
folder.
l Activate Lighty2Go by double clicking on the Start-Lighty batch file.
o After completion of the SW load process, double click on the Stop-
Lighty batch file. Otherwise it will remain available until PC
shutdown.
To confirm the current SW load:
aos# show swload
To identify and load a new SW pack:

aos(config)# swload
aos(config-swl)# load-uri http://<IP address of your PC>/<sw file>.swpack
For example: load-uri http://10.16.1.221/ctr8540-2.2.1.12.1675.swpack

To load and activate immediately:
aos(config-swl)# load activate
The loading process takes several minutes. During this time aos# show swload
can be used to verify the load action and its percent (load progress) completion.
Repeat aos# show swload to review load progress.
On load completion a terminal reboot is forced. On re-start a new login is
required.
To rollback to the previous load:
aos(config-swl)# rollback
To rollback to the previous load after a set time:

aos(config-swl)# rollback-timeout <seconds>
To cancel the set-time rollback:

aos(config-swl)# no rollback
If a load problem persists, won't load, or doesn't load correctly, or you wish to
abort the load, an abort command is used to return SW loading to an idle state,
which is required before any new load action is attempted. This can be
performed at any time up to the start of the SW activation process, after which
the rollback command must be used.
To abort a SW load:
aos(config-swl)# abort
License Loading
NOTE: Lic ens e loading is bes t performed us ing C TR Portal rather than
C LI. It is eas ier/fas ter.
Once a license is loaded it persists. There is no ability to unload a license.

l Licenses are specific to a terminal, identified by the serial number of
the SD card.
l New licenses are added using a copy-and-paste of the license text.
l The license text is downloaded from the Aviat CTR license server
website, where access to a purchased license is specific to a customer
and the serial number of the target terminal (SD card).
l This text is pasted after the CLI prompt that specifies the name of the
license.
Llicenses are available for Capacity, ACM operation to 256 QAM, ACM operation
to 1024 QAM, XPIC operation, 8x front panel switchport enable, SFP port enable,
TDM port enable, FPM (flexible power mode) for ODU 600 or ODU 600sp, and
Carrier Ethernet.

l The Carrier Ethernet license includes: EOAM, ECFM, PWE3MEF8, ERPS,

SYNCE, QinQ
To add a new license:

aos# license install "<license name>" contents "<paste of license text>"
The example below illustrates the procedure.
l The license name is slic_all.txt
l The contents section applies to the text between the " ", beginning with
# License and ending with ==. There must be no gaps inserted in this
paste content.
aos# license install "slic_all.txt" contents "# License -- 1221
# License CZG-60210, Features CZG-60922;CZG-60010-8;CZG-60016-4;CZG-
60018-8;CZG-60020-8;CZG-60070;CZG-60085;CZG-60090
Version=2
SerialNumber=LKA14040154
CidNumber=275048534430344730b012213300cbd5
Hardware=CTR8540
EOAM
ECFM
PWE3MEF8
QINQ
ERPS
SYNCE
CAPACITY=2000
FPM=8
XPIC=4
ACM256=8
ACM1024=8
ELECTRICALBLOCK=1
TDMBLOCK=2
SFPBLOCK=1
====== SIGNATURE FOLLOWS ======
FmoEKmPx9fja9QJ2KiS9MTVg006S8dRpPYc5d65f4FqPu7JcesPnRUx5OsVY2aSS
mwbyKf8SUSEf7YGhXxa9btxCbdzC1LOmO+5peI7w4Tow+Bw+EdLqElR1ZflOk6ej
rGzmpSOgx4rNQylQsIlMJ7NIQIooA/ufvcCe2HHyzp5p2yQ4j14xFqzuHQbEbzKd
nJtwTqiCDiuEy+6sGSOqXHP8QTZGrJb1Q4k9YmQd9tPgio+9brutWJil1+0nXfs3
tnJIWNbV48RUByX0FZoclSSUlfxdc8jkfJVKqzE1bc3nHYDU/cO5c9cN6o26dXMV
Ol73TedaIyS0eYa7h+qdfA=="
To show the installed license file and terminal serial number:

aos# show license
To show license usage:

aos# show license usage
l License Count indicates the number of licensed instances that are
available within the license
l Free Count indicates the available licensed instances (instances not

currently used).
l Type > dynamic indicates that license usage is assigned as-required,
such as ACM usage, which is assigned per-RAC when RACs are
configured for ACM operation.
l Type > static indicates that license usage is fixed (applied per-
chassis).
Date and Time

NOTE: D ate and time s etting is bes t performed using C TR Portal rather
than C LI. It is eas ier/fas ter.
To show date and time:

aos# show clock
To set local clock date and time:

aos# clock set hh:mm:ss <day (1-31)> <month> <year>
Example:
aos# clock set 18:04:10 18 october 2013
This command does not enable adjustment of time relative to UTC (Coordinated
Universal Time). UTC is set using an SNTP command, which first requires SNTP
enable. For example, to set UTC + 6.00 hours:
aos(config)# sntp
aos(config-sntp)# set sntp client enabled
aos(config-sntp)# set sntp client time-zone +6.00
To configure SNTP, refer to the CTR CLI Reference Manual.
Radio Configuration
NOTE: R adio c onfiguration is bes t performed using C TR Portal rather
Refer to:
l Radio Link Configuration on page 50
l Protected Radio Link Operation on page 53
l CCDP/XPIC Link Operation on page 58
l Protected CCDP/XPIC Link Operation (CTR 8540) on page 59
l ODU 600T/OBU Operation on page 61
l L1LA Operation on page 61
l L1LA Lite for CTR 8312 on page 64
l IDQ Optimization on page 65
l CTR 8500/8300 Configuration on page 14

Radio Link Configuration
Before configuring the radio elements check that the appropriate capacity and
any required feature (ACM, FPM) licenses are installed, and the RAC module is
plugged-in.
NOTE: CLI allows configuration of RAC/RFU radio elements without connection
to its intended RFU (ODU or IRU 600). If configured elements are not compatible
with the RFU, alarms will be raised when connection to the RFU is established.
At SW release 3.4 operation is supported on channel bandwidths of:
o ETSI: 3.5, 7, 14, 28, 40, 55 MHz.
o ANSI: 3.75, 5, 10, 20, 25, 30, 40, 50, 60, 80 MHz.
To set channel bandwidth:
l For the specified radio interface, ETSI or ANSI is entered together with
the bandwidth in MHz (for CTR 8312 the radio interfaces are identified
as 0/1 and 0/2; for CTR 8311 it is 0/1).
aos(config-radio)# bandwidth etsi 28
To set the modulation and modulation mask:

l The modulation options are QPSK, 16QAM, 32QAM, 64QAM, 128QAM,
256QAM, 512QAM, 1024QAM-HG (high-gain).
l Fixed or adaptive (ACM) modulation can be specified.
l ACM operation is set by entering a base (lowest) modulation and a
highest modulation. ACM action will range between these limits using
all intermediate modulations.
l A modulation mask setting applies on ETSI ACM modulation profiles (it
only has effect on ETSI profiles).
o It is used where there is a regulatory requirement in your link
operating license to ensure the transmitted signal is maintained
within a specified transmit mask over the ACM modulation states - it
sets the maximum allowable Tx power within an ACM scheme.
o Transmit masks are more stringent at the higher modulation rates,
which typically means the max Tx power permitted at the higher
rates is limited to ensure compliance.
o If a least stringent QPSK mask is selected it permits use of Tx
powers up to the maximum permitted on all ACM rates.
o If on the other hand, the highest modulation rate is selected it
means the max Tx power permitted on this rate must not be
exceeded on the lower rates - max Tx power settings are backed off
on the lower rates.
o Where the user-entered max Tx power setting is set sufficiently
below the maximum allowable Tx power on the highest modulation
rate, Tx power backoff will not occur.

o If a mask command is not entered, the max Tx power setting

defaults to the QPSK mask value.
To set ACM and mask (mask 512 QAM):
aos(config-radio)# modulation acm base 16qam max 512qam mask 512qam
To set a fixed modulation:
aos(config-radio)# modulation fixed 16qam
To set the maximum capacity to be used by the radio:

l Sets the carrying capacity of the link. This can be set to the maximum
configured by the modulation/bandwidth, or to a specified (lower)
capacity.
l The capacity selected is subtracted from the CTR capacity license.
aos(config-radio)# capacity max
or, for a specified capacity in Mbit/s:

aos(config-radio)# capacity 300
To set Tx and Rx frequencies:

l Frequencies are entered in MHz.
aos(config-radio)# frequency transmit 7855 receive 7610
To set Tx power:
l Tx output power is set in steps of 0.1 dBm.
aos(config-radio)# power 10.3
To assign a high Tx power license:

l High Tx power requires installation of an FPM (Flexible Power Mode)
license. One FPM license is consumed per radio interface.
aos(config-radio)# high-power
To un-assign:
aos(config-radio)# no high-power
To disable/enable the Factory Mute:

l All RFUs ex-factory have a one-time Tx mute applied to help ensure the
RFU is not powered-up before its licensed operational frequencies are
configured.
l The mute should be disabled only after the RFU has been connected to
its RAC and its configuration completed.
l The disable factory mute:.


aos(config-radio)# no factory-mute
To reset factory mute:
aos(config-radio)# factory-mute
To set ATPC (ATPC is not default enabled):

l ATPC min and max power levels, and fade margin, are set in steps of
0.1 dBm.
l ATPC is required for ACM operation.
aos(config-radio)# atpc power min 3.0 max 15.0 fademargin 7.0
To disable ATPC:
aos(config-radio)# no atpc
To set FCC compliant ATPC:

l Enables Federal Communications Commission (FCC) compliant ATPC
operation. Applies on ANSI bands only.
o Selection applies only to link operation under FCC jurisdiction where
the coordination notice permits a coordinated Tx power less than the
maximum Tx power under ATPC.
o Guidelines are provided within TIA TSB 10-F, Interference Criteria
for Microwave Systems.
aos(config-radio)# atpc fcc-compliant
To disable:
aos(config-radio)# no atpc fcc-compliant
Payload Encryption
To set payload encryption for the Tx:

l Payload encryption requires installation of a Payload Encryption
license.
l Both sides of a link need identical link-ids to successfully decrypt
traffic.
aos (config)# int ra 2/1
aos (config-radio)# payload-encryption config link-id “Password2016!”
aos (config-radio)# payload-encryption enable
To remove:
aos (config)# no payload-encryption enable
NOTE: Pay load enc ry ption w ill reduc e the maximum capacity of a link.

Table 1. Payload Encryption Throughput Reduction

Ethernet Frame Size (Bytes) Reduction
64 7.81%
128 3.91%
256 1.95%
512 0.97%
1024 0.48%
1518 0.32%
2048 0.24%
4096 0.12%
9600 0.05%
Example Link:
The following example shows configuration using RACx2 in slot 2. Operation is

non-protected, with ACM.
aos(config)# slot 2 racx2
aos(config-radio)# modulation acm base 16qam max 512qam mask 16qam
aos(config-radio)# atpc power min 6.5 max 19 fademargin 8
aos(config-radio)# capacity 400
aos(config-radio)# end
Protected Radio Link Operation
Radio settings for protected (1+1) operation can be synchronized (except Tx

power/ATPC), which must be individually set per interface) by enabling
protection at the outset i.e. after enabling the interfaces but before configuring
bandwidth, modulation, frequency etc. Select the primary designated interface
to set the radio parameters.
Protection types are hot-standby, or space-diversity.
l For CTR 8540 protected operation can be set:
o On a single RACx2 using ODU1 and ODU2 (intra-RAC protection).
o Between RACx2 modules in the same chassis (inter-RAC protection).
n One protected instance can be enabled using ODU1 with ODU1,
or ODU2 with ODU2.
o The unused ODU ports on the RACx2 modules must also be
configured for protection, even though they are not used.
n Two protection instances can be enabled using ODU1 with ODU1,
and ODU2 with ODU2.
o Each protected instance is unique - the radio parameters and
protection type (hot standby or space diversity) can be

different for each.

o Between RACx1 modules in the same chassis (inter-RAC protection).
l For CTR 8312 intra-RAC protected operation can be set on the
integrated RACx2 module using ODU1 and ODU2.
l Intra-RAC protection and inter-RAC protection requires configuration of
synchronous mode on the protected interfaces.
l When setting up an intra-RAC or inter-RAC protection instance, the
lowest numbered interface should always be configured as primary.
l Protected link operation is supported between a CTR 8312 and a CTR
8540 using a RAC2x for intra-RAC protection.
l Capacity licensing on a protected radio link applies to the link.
o When allocating capacity license to a protected link, only the first
interface (normally ODU1) is required to be licensed.
o Any capacity allocated to the second interface will be deducted from
the available capacity license, but will not be used by the protected
link.
l Multiple protection instances can be set (up to 4 using 4 RACx2 plug-
ins).
o Each instance must be individually numbered, from 1 to 4, as in prot
1 in the examples below.
Example Intra-RAC Protected Link: Protection on a CTR 8540 RACx2:
Configuration is identical for the local and remote sites except for the
synchronous mode NW clock settings.
l Intra-RAC protection requires configuration of synchronous mode on
the protected interfaces.
Configure hot-standby on RACx2 interfaces 2/1, 2/2 (Note that the lowest
numbered interface, in this case 2/1, must be specified for primary):
aos(config)# set prot 1 type hot-standby primary 2/1 secondary 2/2
Configure radio parameters for the primary interface:

aos(config-radio)# modulation acm base QPSK max 1024QAM-HG mask
1024QAM-HG
Configure the secondary interface:


Enable the protection instance:

aos(config)# int prot 1
aos(config)# map switch default
aos(config)# no shut
aos(config)#end
Enable synchronous mode on prot 1 - synchronous mode is required on

the protected interfaces:
At the master end (which can be either end):
aos(config-prot)# synchronous mode esmc-enabled
aos(config-prot)# exit
At the remote end:
aos(config)# network-clock input-source 1 int prot 1
aos(config)# network-clock wait-to-restore 0
aos(config)# network-clock hold-off 1800
aos(config)# end
To disable protection:
l The two interfaces are returned to non-protected operation, with each
retaining the radio settings established under protected operation.
aos(config)# no int prot 1
CAUTION: Before disabling protection, one of the links should be Tx muted to prevent
the potential for interference between the two identically configured radios.
Example Inter-RAC Protected Link: Inter-RAC protection (CTR 8540 only)

using interface 1 on RACx2 in slot 2 with interface 1 on RACx2 in slot 4:
Configure hot-standby on RACx2 interfaces 2/1, 4/1 (Note that the lowest
numbered interface, in this case 2/1, must be specified for primary):
Even though interfaces 2/2 and 4/2 are not used they must also be set
for protected operation. Interface 2/2 has the lowest numbered
interface, so it is specified for primary:
o With interfaces 2/2 and 4/2 not used no further configuration of
these interfaces is required.
o If interfaces 2/2 and 4/2 are to be used to establish a second
protected link, a separate configuration for the primary interface
and secondary interface, and protection type, is required.
Configuration is identical for the local and remote sites except for the
synchronous mode NW clock settings.

o Inter-RAC protection requires configuration of synchronous mode on

the protected interfaces.
Configure radio parameters for the primary interface:
aos(config-radio)# modulation acm base QPSK max 1024QAM-HG mask
1024QAM-HG
Configure the secondary interface:

Enable the protection instance:

aos(config-prot)# map switch default
aos(config-prot)# no shut
Repeat protection instance for prot 2:

Enable synchronous mode on prot 1 and prot 2 - for inter-RAC protection

synchronous mode is required on the protected interfaces:
At the remote end:


aos(config)# end
To set revertive switching on a protected interface e.g. prot 1:

l A revert switch can be set as a duration (seconds) from the time of the
protection switch, or as a time of day (time-stamp).
l For the duration option:
o Duration range is 20 to 86400 seconds (24 hrs).
o A revertive switch will occur if the primary Tx has been free of
alarms that trigger a Tx switch, for the set duration.
o Should an alarm occur during the duration period, the timer is reset.
l For the time of day option:
o A revertive switch will occur on time-out of the time of day and
duration timers.
o On expiration of time of day, the duration timer is engaged.
o A revertive switch will occur on alarm-free expiry of the duration
timer.
o Should an alarm occur during the duration period, the timer is reset.
o This behavior is permitted for a maximum 1 hour from the time of
day i.e. the duration timer criteria must be met within the 1 hour
limit. Otherwise, the time of day is reset to the next day.
aos(config-prot)# revert duration 180
or
aos(config-prot)# revert duration 60 scheduled time 14:30:32
or , for no revertive switch:

aos(config-prot)# no revert
To set protection combiner (splitter) values:

l Set values (dB) for the primary and secondary interface to match the
installed equal-loss or unequal loss combiner.
l The values are frequency-band specific. Refer to the CTR 8500/8300
Installation Guide for values.
l The values entered are for reference purposes only - they do not
impact Tx power or ATPC settings.
l The values entered can be seen using aos# show protection.
For equal loss:

aos(config-prot)# splitter equal -3
For unequal loss:


aos(config-prot)# splitter unequal primary -3 secondary -7
Show Commands
The following show commands are available to verify radio interface, link
configuration, and status:
aos# show radio link
aos# show radio features
aos# show sensor
aos# show radio diagnostic
aos# show protection
aos# show int status
aos# show rxperf
Diagnostic Commands
Diagnostic commands are available to enable and disable the following actions.
For detailed information refer to the CR 8500/8300 CLI Reference Manual, or
open a CTR Portal session.
l Lock a modem onto a particular modulation
l Force an IF loopback
l Disable modulation (carrier only)
l Set a Tx mute
l Disable the power supply to an RFU
l View the XPD on an XPIC link. An XPD-proportional voltage is provided
at the RFU BNC connector (supported RFUs only).
CCDP/XPIC Link Operation
2+0 XPIC operation is supported on CTR 8540 with a RACx2 module, and on CTR
8312 . Interface 1 (ODU1) is fixed for vertical polarization (must be connected
to the ODU connected to the vertical port on a dual-pol antenna), interface 2
(ODU2) is fixed for horizontal.
l XPIC operation requires a feature license. One XPIC license is
consumed per RACx2.
l A suitable dual-polarity antenna is required - refer to the CTR
8500/8300 Installation Guide for more information.
l Only one interface, ODU1, of the RACx2 needs to be XPIC enabled to
enable XPIC across both interfaces.
o Both interfaces must be separately configured for the same
frequency and channel bandwidth.
n Tx power and modulation do not need to be the same but to avoid
impacting the effectiveness of the XPIC function they should be
the same.
n Adaptive modulation can be used. The two links operate their
ACM stepping independently.

n For optimum RSL balance on the V and H links, and hence

optimum XPIC effectiveness, ATPC should be OFF, and ACM
should not be used. (ATPC is required on adaptive modulation
links).
o Do not use ATPC on fixed modulation links where the V+H
antenna cross-pol discrimination (XPD) under normal path
conditions is less than 25 dB.
o Do not use ACM (which default requires ATPC) on links where
the V+H antenna cross-pol discrimination (XPD) under normal
path conditions is less than 25 dB.
To enable XPIC (RACx2 module in CTR 8540 slot 2):
aos(config-radio)# xpic
To disable XPIC:
l The two interfaces are returned to non-XPIC operation, with each
retaining the radio settings established under XPIC operation.
aos(config-radio)# no xpic
CAUTION: Before disabling XPIC one of the links should be Tx muted to prevent the
potential for interference between the two identically configured radios.
To view link XPD:

aos# show sensor
Protected CCDP/XPIC Link Operation (CTR 8540)
Two RACx2 modules are used to provide 2+2 XPIC operation - two XPIC links
are hot-standby or space-diversity protected.
l Two protected links are established using inter-RAC protection on
RACx2 modules, after which XPIC is enabled.
l Operation requires an XPIC feature license.
The following example shows configuration of protection between interface 2/1

and interface 4/1, and separately between interface 2/2 and interface 4/2. Fixed
modulation and Tx power is used.
Configuration is identical for the local and remote sites except for synchronous
mode settings:
Step 1: Configure hot-standby on RACx2 interfaces 2/1, 4/1, and RACx2
interfaces 2/2, 4/2, specifying the lowest interface number for primary
in each case:
Step 2: Configure radio parameters for the primary interface:


aos(config-radio)# modulation fixed 256qam

aos(config-radio)# power 15
Step 3: Configure the secondary interface:

aos(config-radio)# power 15
Step 4: Repeat steps 2 and 3 for int ra 2/2 and int ra 4/2 using the same
frequency, modulation, bandwidth, Tx power settings.
Step 5: Enable the protection instance:
Step 6: Repeat protection instance for prot 2:

Step 7: Enable synchronous mode on prot 1 and prot 2 - synchronous

mode is required on the protection interfaces for inter-RAC protection:
At the remote end:
aos(config)# end

Step 8: Set XPIC operation between the protected links by enabling XPIC
on interface 1 of the primary RACx2:
aos(config-radio)# xpic
To set revertive switching and/or protection combiner (splitter) values, refer to the instruc-
tion under Example Protected Link above.
ODU 600T/OBU Operation
ODU 600T operation (5 to 11 GHz) applies to CTR 8540 and requires:

l Two RACx2 or four RACx1 modules for ACCP or ACAP configurations.
l Two RACx2 modules for CCDP/XPIC configurations.
Settings are similar to ODU 600 except that ODU 600T can be set to Tx High or
Tx Low on bands 6 to 11 GHz. However, 5 GHz ODU 600Ts are fixed for Tx High
or Tx Low.
OBU Tx and Rx filter bandwidths for an ODU port are determined by the channel
bandwidth specified at time of OBU order, and are printed on the OBU label.
Measured Tx/Rx insertion loss figures are provided with each OBU.
When configuring an ODU 600T ensure that:
l Tx/Rx center frequencies are configured in keeping with the
corresponding OBU filter bandwidths.
l OBU Tx/Rx insertion losses are accounted for when setting/reading Tx
power, and reading measured RSL. Set/read figures are at the ODU
600T RF port, not at the OBU antenna port.
l ATPC must be set. This applies to fixed and adaptive modulation. Note
that settings for maximum and minimum Tx power under ATPC
operation must account for the OBU Tx insertion loss.
L1LA Operation
L1LA Operation on CTR 8540
L1LA (Layer 1 Link Aggregation) aggregates the capacity provided on:

l One co-path group of up to 8 member links using one L1LA engine (L1LA
Group 1).
l Two separate co-path groups, each of up to 4 member links, using one
L1LA engine (L1LA Group 1) for one set, and another L1LA engine (L1LA
Group 2) for the second.
o This has application at repeater sites.
o With two groups, each group can only have a maximum of two odd
and two even numbered interfaces.
o Being odd or even is defined by the port number e.g radio interface
2/1 (slot 2, port 1) is an odd interface.
o For a protected link, being odd or even is determined by the lowest

port number of the protected pairing e.g. primary 4/2, secondary

4/1, counts as odd.
n With four links per group, there must be two odd and two even
numbered interfaces.
n With three links per group, there can be two odd and one even
numbered interface, or vice-versa.
n With two links per group, there can be two odd, two even, or one
odd and one even.
Member links can be established using RACx2 or RACx1, or a mix thereof.
l ODU1 and/or ODU 2 can be used on a RACx2 to provide member links
f0r N+0 operation.
l Where member links are to be protected and/or XPIC, L1LA operation is
set after completion of the protection and/0r XPIC link configuration.
RACx2 and RACx1 modules for member links can be located in any CTR 8540
slot.
l The same slot relationship does not need to be maintained on CTRs at
each end of the L1LA trunk group.
L1LA Operation on CTR 8312v2 and CTR 8380v2
NOTE: Vers ion 1 C TR 83x x do not s upport L1LA- only L1LA Lite.
L1LA aggregates the capacity provided on one co-path or XPIC group of 2

member links supported from ODU1 and ODU2.
2+0 L1LA interoperability between CTR 8540 and CTR 8312v2 is supported in
Release 3.4 (includes CTR 8380v2).
L1LA Functional Behaviour
Member links can be configured for adaptive or fixed modulation.

Where member links all have the same channel bandwidth (Ch BW):
l ETSI:
o Where all member links on an L1LA group are 28, 40 or 55 MHz Ch
BW there is no minimum permitted modulation.
o Where all member links on an L1LA group have a 14 MHz Ch BW the
minimum permitted modulation is 16 QAM.
o The L1LA overhead is 12 Mbit/s.
l ANSI:
o Where all member links an L1LA group are 20, 30, 40 or 50 MHz Ch
BW there is no minimum permitted modulation.


Where member links have different Ch BWs the combination of links is
restricted:
l ETSI:
o Where the Ch BW of one member link on an L1LA group is 40 MHz or
higher the other member links on the group must use a Ch BW of 55
MHz, 40 MHz, or 28 MHz.
o Where the Ch BWs on an L1LA group are 28 MHz or less, the
individual member links must use a Ch BW of 28 MHz or 14 MHz - 7
MHz is not an option.
l ANSI:
o Where the Ch BW of one member link on an L1LA group is 40 MHz or
higher the other member links on the group must use a Ch BW of 50
MHz, 40 MHz, or 30 MHz.
o Where the Ch BWs of all member links on an L1LA group are 30 MHz
or less, the individual member links must use a Ch BW of 30 MHz or
20 MHz - 10 MHz is not an option.
Loading (the distribution of traffic between member links) is automatically re-
balanced when a modulation change occurs on a member link. This operation is
hitless/errorless.
l L1LA employs Ethernet frame segmentation to achieve uniform,
balanced distribution.
l Segment lengths are automatically determined based on available
member link radio capacity.
l Segments are individually encapsulated and then distributed across all
available member links.
l Adaptive modulation changes trigger instant adjustment of segment
lengths and traffic re-distribution.
o A downshift to a lower modulation translates into an aggregation
capacity decrease (hitless for priority traffic).
o An upshift to a higher modulation translates into an aggregation
capacity increase (hitless).
l As a result, uniform load balancing and maximum aggregation gain is
always achieved on the capacity mix made available on member links.
Convergence and recovery from individual link failures is superior carrier-

grade; less than 2 msec.
L1LA Pre-Configuration:

L1LA configuration requires pre-configuration of the individual member radio

links. Link members can simple c0-path (no XPIC), 1+1 protected (no XPIC),
XPIC, or XPIC 2+2 protected.
l To set up radio links for N+0 operation, refer to Radio Link
Configuration on page 50
l To set up radio links for N+1 operation refer to Protected Radio Link
Operation on page 53
l To set up radio links for XPIC N+0 operation, refer to CCDP/XPIC Link
Operation on page 58
l To setup radio links for XPIC 2+2 operation, refer to Protected
CCDP/XPIC Link Operation (CTR 8540) on page 59
L1LA Configuration:
The following example shows an L1LA configuration to group four member links.
The links could, as above, be simple 4+0, or 4+0 over two XPIC link pairs.
l The L1la engine is No. 1 (group 1)
l The L1LA group is named L1LA-North
aos(config)# l1la 1 group l1la-north
aos(config)# int l1la 1
aos(config-l1la)# ports add ra 2/1 ra 2/2 ra 4/1 ra 4/2
aos(config-l1la)# no shut
aos(config-l1la)# end
Where the L1LA group is to include protected links only the primary radio
interfaces are included in the 'ports add' row.
The L1LA interface is used in configurations where the group is the target, such
as the adding of L1LA interface to a VLAN:
aos(config)# vlan 7
aos(config-vlan)# ports add l1la 1
To remove an active L1LA group e.g. group 1:

aos(config)# no l1la 1 group
To remove a radio link e.g. 2/1 from L1LA group 1:

aos(config)# l1la 1 group l1la-north
aos(config)# int l1la 1
aos(config-l1la)# no ports ra 2/1
aos(config-l1la)# end
Show commands:
aos# sh l1la
aos# sh l1la status
L1LA Lite for CTR 8312
L1LA Lite aggregates the capacity provided on one co-path or XPIC group of 2
member links supported from ODU1 and ODU2.

L1LA Lite Pre-Configuration:

l L1LA Lite requires pre-configuration of the individual member radio
links.
l Both links must be configured for the same channel bandwidth and
fixed modulation (adaptive modulation is not supported on L1LA Lite).
l Only ODU 1 of the CTR 8312 is configured to enable L1LA Lite on ODU1
and ODU2.
l The maximum MTU for L1LA Lite operation is 5ooo bytes.
l To set up radio links for N+0 operation, refer to Radio Link
Configuration on page 50
L1LA Lite Configuration:

To enable L1LA Lite:
aos(config)# l1la-lite
aos(config)# end
To disable L1LA Lite:

aos(config)# no l1la-lite
aos(config)# end
To verify the L1LA_Lite configuration:

aos# sh radio link
NOTE: L1LA Lite is intended for us e w ith C TR 8312. For interoperability
betw een C TR 8312v 2 and C TR 8540, or w here both ends of a trunk group
are C TR 8312v 2, refer to L1LA Operati on on page 61.
IDQ Optimization
IDQ optimization applies for an ODU that has a GaN PA (Power Amplifier),
currently all 6 GHz and 11 GHz, ODU 600, ODU 600T, and IRU 600 devices.
It resets the quiescent current (IDQ) on the PA to a value that equates to
optimum transmitted SNR. This calibration function is also performed
automatically on start-up or software upgrade.
l GaN devices can exhibit IDQ drift, which is a slow process.
l Re-calibration using the IDQ optimization command should only be
necessary when link SNR is found to be degraded under normal path
conditions (normal RSL). Current SNR values are displayed using the in
the command: aos# show sensor, and should be recorded at
commissioning for later comparison.
l At the outset, SNR values should be checked every quarter. This may
be extended to an annual check based on recorded performance.
l During the optimization process all traffic on the link is interrupted for
between 0.5 and 3 seconds.
l On a protected 1+1 or space diversity link the optimization process

must be performed on the online and offline (active/standby)

ODUs/IRUs separately.
l When performed on the online ODU/IRU a protection switch is forced.
l It can be performed on the offline ODU/IRU without impacting the
online ODU/IRU.
To start the IDQ calibration procedure for a specific radio interface - in this
example ra 2/1:
aos(config-radio)# idq-optimization start
To view the current state of the calibration procedure:

aos# show radio idq-optimisation
To stop the calibration function if it is currently running (for a specific radio

interface):
aos(config-radio)# idq-optimization stop
NOTE: Under normal use the show and stop commands are not required - the
calibration procedure will complete and stop automatically.
Radio Show Commands
The following show commands are available to verify radio interface, link
configuration, and status. Use the show sensor command to view link XPD
(cross polarization discrimination):
aos# show radio link
aos# show radio features
aos# show sensor
aos# show radio diagnostic
aos# show protection
aos# sh l1la
aos# sh l1la status
aos# show rxperf
Network Connectivity
Where terminals in the network are on the same subnet normal LAN connectivity
prevails.
Where terminals are on different subnets, static routing is used to enable
connectivity (dynamic routing is scheduled for a later SW release).
l IP routes are added to address all other terminals in the network, from
every terminal in the network.
To add a static route:

aos(config)# ip route <network portion of ip address of remote terminal>
<mask of remote terminal> <ip address of next hop terminal>

aos(config)# end
Example:
aos(config)# ip route 192.172.6.0 255.255.255.0 192.168.1.12
To show ip routes:
aos# show ip route
To delete a static route use the no form of the command e.g:

aos(config)# no ip route 192.172.6.0 255.255.255.0 192.168.1.12
Locate Me
A locate-me function is provided on CTR 8540 to physically identify it in an
equipment room by turning on a flashing light behind the Aviat logo on the CTR
front panel.
To turn on the locate-me function:
aos# locateme
To turn the function off:

aos# no locateme
Useful Show Commands

Show commands are executed through aos# show <command>

To Show: Command
Current config running-config
Current alarms alarm
Current alarm types alarm type
Current SW load and previous load swl
Manufacturing details (serial number etc.) manufacture-details
Licenses and usage (License Count column shows the number of licenses license usage
of type; the Free Count shows the number of licenses available for use)
IP interfaces (and IP address) ip int
Interfaces interfaces
Interface status int stat
Interface statistics per port int count
Sensor (measured/detected) data sensor
Active VLANs (and VLANs not active for which the port details are con- vlan
figured)
Management VLAN and interfaces management
MAC address table mac-address-table
VLAN info vlan device info
Date and time clock
Service VLANs and ports service vlan
Syslog contents log
List, in order, of the most recently executed commands history
The expected and detected plug-in modules in each slot slot
Back-up power status backup-power
Information on the sensors present in the system sensor
NOTE: Fo r a l i sti n g o f a l l sh o w co mma n d s, re fe r to th e C TR 8 5 0 0 /8 3 0 0 C L I

R e fe re n ce Ma n u a l .

CTR CLI Example Configurations

The following example configurations are designed to introduce use of CLI to
implement:
l QoS on page 69
l Congestion Avoidance on page 76
l ERPS on page 80
l ESMC on page 87
l E1/T1 Pseudowires on page 89
l STM1/OC3 Pseudowire on page 92
l Static LAG on page 94
l Provider Edge Bridge Mode on page 96
l ECFM on page 100
NOTE: To sa ve yo u r co n fi g u ra ti o n yo u mu st d o a co n fi g sa ve . Se e
Con figu rat ion Save an d Revert Tim er on page 2 7 .
QoS
NOTE: QoS c onfiguration is bes t performed using C TR Portal rather than
C LI. It is eas ier/fas ter.
The following CLI example illustrates basic QoS configuration using priority,
class and policy mapping, with scheduling at egress.
l For congestion avoidance using RED or WRED, see Congestion
Avoidance on page 76.
l Traffic policing (metering) is supported for CTR 8540.
l For more information refer to the CTR 8500/8300 QoS Configuration
Guide.
Options allow you to create a priority map, bind it to a VLAN or a port, and then
use any of the supported fields in the packet for classification (ipDSCP, ipTOS,
etc.). These mechanisms can apply regardless of a VLAN tag.
On VLAN tagged frames their CoS (Class of Service) 802.1p priority value is
used when determining port-port behavior through the switch. For native
(untagged) frames, the default priority of the input port is used. In both
instances a priority map is set on the active ports whereby the CoS value on the
ingressing frame (in-priority) is mapped by the classifier function to an egress
queue (regen-priority).
l On ingressing VLAN tagged frames the in-priority can be determined by
the CoS value in the VLAN tag.

l On untagged traffic the in-priority is determined by a port-based tag

(CoS value) assigned on the port.
l In most instances the regen-priority will be set to the in-priority value.
l Where set differently, the regen value only impacts at the egress
queue; the CoS tag on ingressing VLANs is retained beyond the switch
(beyond egress). Untagged frames egress as untagged.
Similarly a priority map can be set for ingressing DSCP (Differentiated Services
Code Point) tagged frames, whereby the DSCP value on the ingressing frame
(in-priority) is mapped by the classifier function to an 8-level (CoS value)
egress queue (regen-priority).
l The assigned regen value only impacts at the egress queue; the DSCP
value is retained beyond the switch.
l If an ingressing frame contains both DSCP and CoS tags, the DSCP tag
is used to determine QoS behavior within the switch.
l Ingress-to-egress port association on DSCP flows is MAC-learned.
Classifier Function :
Operation of the classifier for regen-priority can be summarized as:

l When a packet arrives it is classified with a particular egress priority
using the regen-priority command. This is a value between 0-7 where 7
specifies the highest priority.
l During the packet processing the bridge determines its egress interface
and the regen-priority determines into which queue on this egress
interface the packet is enqueued.
l The priority value on the queue mapping can be seen using the "show
queue" command: sh queue int <port>:
Class maps and policy maps are set (are required) in support of the priority
mapping for Access Control List (ACL) purposes.
l A class map is used to isolate and name a traffic flow (or class) from all
other traffic. It sets the criteria to further classify a specific traffic flow.
l Once a flow is matched against class-map criteria, it is further
classified using the policy map.
l Multiple priority mappings can be mapped to a common class map, and
multiple class mappings to a common policy map. A common class map
would typically apply to all flows configured on an interface.

l The default policy map is map ID 1, class 1. If a policy map is not set
all class settings will be mapped to this default. Policy map setting
particularly applies where flows are to be metered, as for policing.
The internal priority classification/mapping set at the ingress QoS stage

identifies the corresponding transmit queue at Egress.
Scheduling:
Scheduling algorithms determine the behavior between the different transmit

queues. The scheduler options are:
l Strict Priority: the port transmits all packets out of higher priority
queues before transmitting any from the lower priority queues.
l Round Robin: the port transmits the same number of packets from each
queue, in a round robin fashion.
l Weighted Round Robin: the port transmits an assigned number of
packets from each queue, in a round robin fashion.
l Weighted Fair Queuing: the port transmits each queue with a different
percentage of the port bandwidth. Plus, by supporting variable length
packets it ensures flows with larger packets are not assigned more
bandwidth than flows with smaller packets.
l Strict Round Robin: the port assigns strict priority on queues 1 and 2,
with other queues assigned a lower equal share.
l Strict Weighted Round Robin: the port assigns strict priority on queues
1 and 2, with other queues assigned a lower configurable share.
l Strict Weighted Fair Queuing: the port assigns strict priority on queues
1 and 2, with other queues assigned a lower configurable WFQ share.
l CIR EIR: the port assigns flows based on CIR, CBS, EIR and EBS user
settings, with each queue serviced in a Round Robin fashion.
l Strict CIR EIR: the port assigns a strict priority on queues 1 and 2 with
other queues assigns flows based on CIR, CBS, EIR and EBS user
settings
NOTE: Round Robin, Weighted Round Robin and Weighted Fair Queuing can (are
permitted) to drop high priority frames. Use of these schedulers is not
recommended when carrying high-priority traffic that must not be dropped e.g.
management or pseudo-wire. Instead, use schedulers with strict-priority
options such as Strict Round Robin, Strict Weighted Round Robin or Strict-
Weighted Fair Queuing, and ensure the essential traffic is assigned on queues 1
or 2 (priority 7 or 6 respectively).
The following diagram and configuration illustrates port-port connections and
egress queuing for a mix of tagged and untagged traffic. Traffic on switch ports
0/2, 0/3, 0/4 is bridged to radio (RACx2) port 2/1.

Figure 2. Basic QoS Example
Configuration preconditions:
l Set Bridge Mode to Customer Bridge (default mode).
l Configure slot 2 for a RACx2 module.
l Install relevant radio link RAC/RFU capacity, FPM and ACM licenses.
Procedure:
l Activate interfaces 0/2, 0/3, 0/4, 2/1. See: To Enable or Disable a
Port on page 40.
l Add Member ports to VLAN 10, VLAN 33, VLAN 110:
aos(config-vlan)# ports add gi 0/2 ra 2/1
To view VLAN details:

aos# show vlan
l Enable QoS Globally:
aos(config)# qos enable
aos(config)# no shut qos
aos(config)# end
To verify that QoS has been enabled:

aos# show qos global info
l Create Priority Maps for VLAN, DSCP and Untagged flows:

In this example where all flows are to/from a common radio interface,
priority mapping for the radio interface 2/1 is not essential. However for
completeness it is shown here.
For VLAN and DSCP flows:
aos(config)# priority-map 11
aos(config-pri-map)# map int gi 0/2 in-priority-type vlanPri in-
priority 5 regen-priority 5
aos(config-pri-map)# exit
aos(config-pri-map)# map int gi 0/4 in-priority-type ipDscp in-
aos(config-pri-map)# map int ra 2/1 in-priority-type vlanPri in-
aos( config-pri-map)# map int ra 2/1 in-priority-type ipDscp in-
For untagged flows:

To verify priority settings:

aos# show priority-map

Or for a specific map e.g. 11:

aos# show priority-map 11
l Create Class Maps. In this example class mapping is set per
interface. Note that the class-map number is simply an ID for the
class-map instance.
aos(config)# class-map 101
aos(config-class-map)# set class 500
aos(config-class-map)# match access-group priority-map 11
aos(config-class-map)# exit
aos(config-class-map)# end
To view class map entries:

aos# show class-map

l Create Policy Maps. A policy class is set for each of the gi/set class
interfaces.
aos(config)# policy-map 1000
aos(config-ply-map)# set policy class 500
aosconfig-ply-map)# exit
aosconfig-ply-map)# exit
aosconfig-ply-map)# end
aosconfig-ply-map)# end
To verify policy map settings:

aos# show policy-map
l Define port default priority (priority 2 for the untagged frames) on
port 3:
aos(config-if)# end
To check the default priority setting for a port, e.g. 0/3:

aos# show vlan port config port gi 0/3
l Define scheduler on ports. Strict priority is default set on all ports,
therefore no configuration is required on ports 0/2, 0/3, 0/4. WFQ is
configured on port 2/1, with weights shown below.
aos(config)# scheduler 1 int ra 2/1 sched-algo WFG
aos(config)# queue 6 int ra 2/1 scheduler 1 weight 40000
aos(config)# end
To revert a port (2/1) to strict priority:

aos (config)# scheduler 1 int ra 2/1 sched-algo strict-priority
To display scheduler settings:

aos# show scheduler
To display the queue entries for all interfaces:

aos# show queue
To display the queue entry for a specific interface e.g. 0/1:

aos# show queue int gi 0/1

Congestion Avoidance
NOTE: C onges tion Av oidanc e c onfiguration is bes t performed using C TR
Portal rather than C LI. It is eas ier/fas ter.
Queue size setting and the more advanced congestion avoidance RED and WRED
algorithms apply to CTR 8540 only.
Queue Size
Queue size (depth) settings in bytes or packets are used to set the maximum
number of bytes or packets that a queue can hold, above which all packets are
dropped (tail dropped). It indicates to the TCP end hosts to cease transmission
of packets until tail dropping has ceased.
Queue size limits can be set in packets (frames) or bytes:
l Packet-based has queue limits of 1-7000.
l Byte-based has queue limits of 1-524287.
RED and WRED

RED (Random Early Detection) and WRED (Weighted RED) are used to control
the average queue size by indicating to the TCP end hosts when they should
temporarily slow down transmission of packets.
l Through controlled packet dropping they instruct the packet source to
decrease its transmission rate as congestion builds so that all packets
reach their destination.
The parameters are set and applied on the egress queue(s).

l RED congestion control drops packets randomly such that all flows
going into the same queue generally experience the same drop rate.
l WRED combines the capabilities of the RED algorithm with classification
(which is user configurable and can be based on DSCP) to enable
preferential traffic handling for higher priority packets i.e. it can control
the dropping of packets per DSCP designated (class-based) flow, per
queue.
o It enables selective discard of lower priority traffic as the queue
begins to get congested.
l Both distribute losses in time to maintain normally low queue depth
while absorbing spikes.
l Congestion profiles are used to determine the point when dropping
begins, the point when all packets are dropped, and the maximum drop
probability.
o Minimum threshold is the value of the average queue size where the
drop algorithm is activated (below this value all traffic is passed).
n An arriving packet is queued only if the average queue size is
below the minimum queue threshold.

o Maximum threshold is the value of the average queue size above

which all traffic is dropped.
o Maximum probability (mark probability denominator) is the
maximum drop probability (in percent) at maximum threshold.
n When the average is between the minimum and the maximum
thresholds, the probability that the packet will be dropped can be
calculated by a straight line from the minimum threshold
(probability of drop 0) to the maximum threshold (probability of
drop is equal mark probability denominator).
n For example, if the mark probability denominator was set to 10,
when the queue depth reached the maximum threshold, the
probability of discard would be 10%, i.e. on average 1 in 10
packets would be dropped.
l For RED and WRED the min and max thresholds are set in bytes with
limits of 1-524287.
l For WRED a packet's drop precedence is determined by the classifier.
See Classifier Function: on page 70
o WRED supports three drop-precedence values; 0, 1, 2. All three
must be set with min and max threshold values, but all three do not
need to be used.
n If there is no class map associated with a drop-precedence, the
threshold values associated with the drop-precedence are not
used.
The following diagram and configuration procedure illustrates application of
queue limits, RED and WRED on RACx2 port 2/1.
Figure 3. Congestion Avoidance Example
l Configure slot 2 for a RACx2 module.
l Activate interfaces 0/2, 0/4, 2/1. See: To Enable or Disable a Port on

page 40.
Procedure:
l To configure a queue size on radio port 2/1:
Queue size in packets (frames) with a queue limit of 3000:
aos(config)# queue-template 10
aos(config-qtemplate)# algorithm taildrop-frames queue-limit 3000
aos(config-qtemplate)# exit
aos(config)# queue 6 int ra 2/1 queue-template 11
aos(config)# end
To alternatively configure the queue size in bytes (queue limit 400000

bytes):
aos(config-qtemplate)# algorithm taildrop-bytes queue-limit 400000
aos(config)# end
l To configure RED on radio port 2/1:

Min and max thresholds of 40000 and 300000 bytes respectively, and a
max probability of 80.
aos(config-qtemplate)# algorithm red min-threshold 40000 max-
threshold 300000 mark-probability-denominator 80
aos(config)# end
l To configure mapping and drop precedence for IpDSCP based WRED

on radio port 2/1:
Priority, class and policy maps are configured per DSCP flow. In this
example there are just two DSCP values to be mapped. However:
l Multiple different in-priorities (DSCP values) can be priority
mapped to a common or different regen-priority. Regen-priority
values range from 0 (lowest priority) to 7 (highest priority).
l Multiple different priority maps can be class-mapped to a common
or different drop-precedence. Drop-precedence values are 0, 1, or
2.
l Policy mapping is shown, but could be ignored as metering is not
required in this example, in which case the default policy map of
map ID 1, class 1, would prevail.
aos(config-pri-map)# map int ra 2/1 in-priority-type ipDscp in-

aos(config-pri-map)# map int ra 2/1 in-priority-type ipDscp in-
aos(config-cls-map)# match access-group priority-map 10
aos(config-cls-map)# set class 300 drop-precedence 0
aos(config-cls-map)# exit
aos(config-cls-map)# match access-group priority-map 11
aos(config-cls-map)# set class 400 drop-precedence 1
aos(config-cls-map)# exit
aos(config-ply-map)# exit
aos(config-ply-map)# exit
aos(config)# end
l Set WRED on radio port 2/1 :

max probability of 100 on drop precedence 0 (IpDSCP 45).
max probability of 100 on drop precedence 1 (IpDSCP 35).
WRED requires configuration of all three drop precedence instances (0,
1, 2). However, only 0 and 1 are associated with a class map (see item 3
above), which means the setting for drop-precedence 2 is ignored.
aos(config-qtemplate)# wred drop-precedence 0 min-threshold 250000
max-threshold 400000 mark-probability-denominator 100
aos(config-qtemplate)# algorithm wred
aos(config)# end
To disable RED or WRED e.g.WRED on queue template 12:

aos(config-qtemplate)# no algorithm
To verify queue template status e.g for radio port 2/1:

aos# sh queue int ra 2/1
NOTE:

l When a queue template is assigned to a queue it cannot be changed.

o To change a queue template assign the queue(s) that are using the
template to the default template (queue-template 0) before applying
changes to the template. Then re-assign the queue(s) from the
default template to the changed template.
l The congestion profile for a drop precedence cannot be changed if the
queue template's algorithm is active (i.e. set to WRED).
o To make a change first disable the congestion profile's algorithm
(i.e. execute "no algorithm"). This requires that no queue is assigned
to the template, as above. Then change the profile as needed, and
reset the algorithm.
l IP DSCP drop precedence is ignored by default. Creating priority maps
and class maps is mandatory for the drop precedence to come into
effect.
ERPS
The following example illustrates configuration of ERPS on a basic three-node
ring. Port-protection (as distinct from service-based protection) is used,
whereby if the ERPS control process blocks or unblocks a ring port, all traffic
through that port is affected.
l For service-based protection separate R-APS VLANs (and associated
traffic VLANs) are configured, with the RPL (Ring Protection Link) owner
for each R-APS VLAN applied on different nodes.
l Service-based protection is not currently supported.
l The default ERPS version is V2. Support for V1 provided.
The configuration process involves:

l Enabling ECFM and Y1731 on all nodes.
l Configuring the MD (Maintenance Domain) and service instances on all
nodes.
l Enabling CCMs (Continuity Check Message) for all MEPs.
l Enabling ERPS on all nodes.
l Configuring ring APS (Automatic Protection Switching) group on all
nodes.
l Associating the ERPS interfaces to the MEG (Maintenance Entity Group)
along with The ME (Maintenance Entity) and MEPs (Maintenance End
Point) on all nodes.
l Activating the APS group on all nodes.
l Configuring the RPL owner on one node.
NOTE: Tak e c are during c onfiguration to ens ure correct ass ociation of
ports w ith domain name and MPID (MEP ID ).

For comprehensive instruction refer to the CTR 8500/8300 ECFM and ERPS
Configuration Guides. An ECFM example is provided at: ECFM on page 100.
Figure 4. ERPS Node Topology
l Configure slot 4 in Nodes 2 & 3 for the PoE module
Procedure:
l Shutdown/disable spanning tree, GVRP, GMRP, GARP, on all three
nodes:
To verify that spanning tree and GARP are shutdown, GVRP, GMRP are
disabled, and Bridge Mode is configured as Customer Bridge (default
mode):
l Activate required Gig-E interfaces. See To Enable or Disable a Port on
page 40.
o Interfaces 0/2, 0/3, 0/9 on node 1.
o Interfaces 0/5, 4/2 node 2.

To verify interface status:

l Add member ports for VLAN 100 and VLAN 200 on all nodes. 100 is
the R-APS (Ring Automatic Protection Switching) VLAN, 200 is a
traffic VLAN (multiple traffic VLANS can be configured).
For node 1:
aos(config-vlan)# ports add gi 0/2,0/3,0/9
For node 2:
aos(config-vlan)# ports add git 0/5,4/2
aos(config-vlan)# ports add gi 0/5,4/2
For node 3:
To verify VLAN / interface status:

aos# show vlan
l Enable ECFM, Y1731, and ECFM offload on all nodes.
aos(config)# ether cfm start
aos(config)# ether cfm enable
aos(config)# ether cfm offload
aos(config)# ether cfm y1731 enable
aos(config)# end
To verify status (per node):

aos# show ether cfm global info
l Create a CFM domain name (clark), level (5), and service name (rex)
in node 1 and node 2. MEP direction is down/outward by default. CCM
interval 300 Hz.
For node 1:
aos(config)# ethernet cfm domain name clark level 5
aos(config-ether-ecfm)# service name rex vlan 100
aos(config-ether-ecfm)# mep crosscheck mpid 111 vlan 100


aos(config-ether-ecfm)# exit
aos(config-if)# ethernet cfm enable
aos(config-if)# ethernet cfm mep domain clark mpid 111 vlan 100
active
aos(config-ether-mep)# exit
aos(config)# ethernet cfm cc level 5 vlan 100 interval three-hundred-
hertz
aos(config)# ethernet cfm cc enable domain clark vlan 100
aos(config)# end
For node 2:
aos(config)# ethernet cfm domain name clark level 5
aos(config-ether-ecfm)# service name rex vlan 100
aos(config-if)# ethernet cfm mep domain clark mpid 112 vlan 100
active
hertz
aos(config)# ethernet cfm cc enable domain clark vlan 100
aos(config)# end
To verify that the domain is created and that the remote MAC is learned
in both nodes:
aos# show ether cfm service
l Create a CFM domain name (clark1), level (5), and service name
(rex1) in node 1 and node 3. MEP direction is down/outward by
default. CCM interval 300 Hz.
For Node 1:
aos(config)# ethernet cfm domain name clark1 level 5
aos(config-ether-ecfm)# service name rex1 vlan 100
aos(config-if)# ethernet cfm mep domain clark1 mpid 300 vlan 100
active


hertz
aos(config)# ethernet cfm cc enable domain clark1 vlan 100
aos(config)# end
For node 3:
active
hertz
aos(config)# end
in both nodes:
l Create a CFM domain name (clark2), level (5), and service name
(rex2) in node 2 and node 3. MEP direction is down/outward by
default. CCM interval 300 Hz.
For node 2:
active
hertz
aos(config)# end
For node 3:


active
hertz
aos(config)# end
in both nodes:
l Enable ERPS in all 3 nodes:
aos (config)# no shutdown aps ring
aos (config)# aps ring enable
aos (config)# end
Verify that ERPS module status is enabled in all nodes:

aos# show aps ring global info
l Create an APS ring group (group ID is set as 10) and associate the
ERPS interfaces to a maintenance entity group (MEG) along with
maintenance entity (ME) and maintenance end point (MEP) in all 3
nodes:
NOTE: Ens ure the ER PS interfac es are as s ociated in the order in w hich
they w ere c reated in s teps 5, 6, 7 abov e e.g. for node 1, interface 0/3
first, follow ed by 0/9 as in: aps working gi 0/3 gi 0/9 vlan 100.
For node 1:
aos(config)# aps ring group 10
aos(config-ring)# aps working gi 0/3 gi 0/9 vlan 100
aos(config-ring)# aps working meg 1 me 1 mep 111 meg 2 me 1 mep 300
aos(config-ring)# end
For node 2:
For node 3:

Verify that the ERPS interface and CFM configuration are configured
correctly in nodes:
aos# show aps ring configuration
l Activate the ring (APS group) on all nodes:
For all nodes:

aos(config-ring)# aps group active
Verify that the APS group is active, and ensure the ring state is shown as
Pending on all nodes (before configuring an RPL owner):
aos# show aps ring group 10
l Configure node 1 as RPL owner. Revertive switching is configured
with a WTR timer setting of 1000 milliseconds:
aos(config-ring)# no aps group active
aos(config-ring)# aps protect gi 0/9
aos(config-ring)# aps revert wtr 1000
aos(config-ring)# aps group active
Verify that node 1 is configured as RPL owner and that ring state is Idle:
aos# show aps ring configuration
Verify that interface 0/9 on node 1 is in a blocked state:

Verify that ring state is Idle on nodes 2 and 3:

Verify timers:
aos# show aps ring group 10 timers
This completes the setup.
l Protection switching can be verified by disabling an interface e.g. 4/2

on node 2.
aos(config-if)# end
Verify that ring state is changed to Protection in all nodes.

Verify that port status for interface 0/9 in node 1 is Unblocked.
Re-enable the interface in node 2:

aos(config-if)# end

Verify that ring state is changed to Idle in all nodes.

Verify that port status for interface 0/9 in node 1 is Blocked.
ESMC
NOTE: Sy nc E c onfiguration is bes t performed using C TR Portal rather
ESMC (Ethernet Synchronization Message Channel) and SSM (Synchronization

Status Message) options are used to enable SyncE clock sourcing, selection and
transport.
l Up to four external clock sources can be configured per CTR.
l The quality level (QL) advised by heartbeat SSM frames is used to
determine the clock selection order when multiple clock sources are
provided.
l A clock priority is also set for multiple clock sources to assist the
selection process when SSM is not enabled or where two or more
sources have the same QL.
l Should all external clock sources fail, an internal clock is used.
l Two industry-standard SSM option types are supported, Option I, and
Option II. These are selected based on the clock source hierarchy used
within the network. Generally Option I is aligned with SDH/ETSI
operation, and Option II with SONET/ANSI.
l Hold-off and wait-to-restore timers are provided.
o The hold-off timer ensures that short signal-fail conditions are not
acted on. The set-able range is 300 (default) to 1800 ms. In the
meantime the previous QL level is maintained.
o The wait-to-restore timer ensures that a previously failed clock
source has been fault-free for a specified time before becoming
available for selection. The set-able range is 0 (default) to 12
minutes. In the meantime the QL-failed status is maintained.
The following example illustrates basic operation. For more information refer to
the CTR 8500/8300 CLI Reference Manual.
Figure 5. Example ESMC Link

l Set slot 2 for the RACx2 module
Procedure:
l Activate required Gig-E interfaces. See To Enable or Disable a Port on
page 40.
o Interface 0/2, 2/1 on node 2.
l Enable ESMC on Node interfaces.
Node 1:
aos(config-if)# synchronous mode esmc-enabled
Node 2:
The following commands provide views of esmc status:

aos# show esmc
aos# show esmc all
aos# show esmc int gi 0/2
l Select clock sources and clock priority. 1 is highest clock priority.
Node 1:
aos(config)# network-clock input-source 1 int gi 0/2
aos(config)# exit
Node 2:
aos(config)# network-clock input-source 1 int ra 2/1

aos(config)# exit
The following commands provide views of network clock status:

aos# show network-clock
aos# show network-clock detail
aos# show network-clock detail int gi 0/2
l Set timers on both nodes; 500 ms for hold-off, 1 min for wait-to-
restore:
aos(config)# end
l Set network type for Option 1 (default) or Option 2:
aos(config)# network-clock synchronization network-type option-2
E1/T1 Pseudowires
NOTE: E1 ps eudow ire c onfiguration is bes t performed using C TR Portal
rather than C LI. It is eas ier/fas ter.
Configuration for MEF 8 (SAToP) pseudowire operation entails:

l Activation and configuration of required E1 or T1 trib interfaces.
l Each pseudowire is clocked from its E1/T1 input
l Activation of required Ethernet switch/radio ports
l VLAN activation on Ethernet switch/radio port(s)
l Circuit emulation configuration
l ESMC (SyncE) configuration on radio ports with the sync source
(internal) provided at Node 1
o The config example includes an alternative external clock source
option
Pseudowire licensing is included in the Carrier Ethernet license.
In the example below:
l Trib operation (controller mode) is set for E1
l All four trib ports are entered on a common VLAN 110
l Pseudowire (VLAN 110) priority is set to 6 (default is 7)

Figure 6. Example MEF 8 Pseudowire
l Set slot 2 for a RACx2 module.
l Install Carrier Ethernet and TDM feature licenses.
Procedure:
The procedure for Node 1 is detailed. The procedure for Node 2 is essentially
identical apart from the destination MAC address and SyncE settings.
l Activate required Gig-E and radio interfaces, 0/2 and 2/1. See To
Enable or Disable a Port on page 40.
l Add member port for VLAN 110 on the radio port. All four pseudowire
instances are to be assigned on VLAN 110.
aos(config-vlan)# ports add ra 2/1
l Set trib mode of operation to E1:
aos(config)# controller mode e1
aos(config-if)# end
l Set the circuit emulation (cem) for trib 1:
l To destination switch with MAC address 00:eO:e2:70:a6:71
l Virtual circuit ID (vcid) 1, a local identifier (recommend use of
values of 1 to 16 to match the trib port number)
l MEF 8 pseudowire
l On VLAN 110
l Reset the pseudowire egress queue priority (VLAN priority) from
default 7 (highest) to 6
l Using the Real Time Transport Protocol (rtp)
l Using an rtp payload of 256 bytes for E1 (192 bytes applies for T1)
l Packet re-ordering is enabled

l Using a jitter buffer size of 50000 us (settable jitter depth range is

1000-512000 is microseconds)
l Using differential time stamp mode for clock recovery
l The emulated circuit ID (ecid) is (must be) unique per trib across
the NW
aos(config)# int cem 0/1
aos(config-if)# xconnect 00:e0:e2:70:a6:71 vcid 1 enc mef8 vlan 110
aos(config-if-pw)#vlan-priority 7
aos(config-if-pw)#regen-priority 6
aos(config-if-pw)# rtp enable
aos(config-if-pw)# payload 256
aos(config-if-pw)# packet
aos(config-if-pw)# jitter-buffer 50000
aos(config-if-pw)# clock rec dif
aos(config-if-pw)# ecid 40
aos(config-if-pw)# no shut
aos(config-if-pw)# exit
NOTE: The v lan-priority and regen-priority s teps can be ignored if the
default priority (7) is to be retained.
Repeat the configuration for tribs 2-4 (cem 0/2 to cem 0/4).
l The vcid should be set to match the trib interface number (it can be
set differently at each end of the link e.g. trib 1 at one end and trib
7 at the other).
l The ecid must be uniquely set per pseudowire circuit, and must be
the same at both ends of the link.
l As all four pseudowire circuits have the same source/destination,
all are transported on the same VLAN.
To verify a pseudowire (by vcid):

aos# show pseudowire vcid 1
l Set the E1 trib line impedance and clock source:
aos(config)# controller e1 0/1
aos(config-controller)# line impedance unbalanced75ohms
aos(config-controller)# clock source line
aos(config-controller)# no shut
aos(config-controller)# end
To check the trib interface configuration:

aos# show controller e1 0/1
Repeat this step for Node 1 tribs 2-4.

l Configure SyncE. Refer to ESMC on page 87. Two clock source options
are shown for Node 1.
Node 1: Internal SyncE clock source, free running.


Node 2:
aos(config)# end
STM1/OC3 Pseudowire
A TSoP (Transparent SONET/SDH over Packet) SFP module is available to
provide fully transparent transport of an STM1/OC3 stream across an Ethernet
network.
l The STM1/OC3 bit-stream is encapsulated as a pseudowire and mapped
into an Ethernet Virtual Circuit (EVC) and transported as a VLAN on a
SyncE channel.
l Only two SFP modules may be connected (end-end) in the same VLAN.
If multiple STM1/OC3 pseudowires are required, then multiple VLAN’s
(EVCs) must be used.
l The SFP module automatically detects for STM1 or OC3.
l The optical LC interface supports a 155 Mbit/s, S1.1 (15km), 1310nm,
single-mode, optical data link.
l The configured radio path must provide a capacity of not less than 168
Mbit/s.
l The MTU size on all source, intermediate, and destination interfaces
must be not less than 860 bytes. CTR default is 1500.
Configuration entails:
l Activation of SFP port and in-path switch/radio ports.
l VLAN activation on in-path switch/radio port(s).
l ESMC (SyncE) configuration on in-path traffic ports.
o The STM1/OC3 SFP cannot be used to source the clock.
o If a clock source is not available on one of the bridge ports, the
internal clock on one CTR can be used to clock the other.
In the example below:
l VLAN 110 is configured for the STM1 pseudowire. Member ports are gi
0/9 and ra 2/1.
l VLAN 110 priority is set to 5 (default VLAN priority is 0).
l Internal clocking is used - the clock input source is configured on node
1, port 0/9, where without a clock input on that port the clock falls back
to internal.

Figure 7. Example STM1/OC3 Pseudowire
l Install the STM1/OC3 SFP transceiver in slot 0/9.
l Install Carrier Ethernet license.
l Configure radio link parameters using CLI or CTR Portal. The
modulation/bandwidth selection must provide a capacity of not less
than 168 Mbit/s.
l Ensure all source, intermediate and destination interfaces support an
MTU size of not less than 860 bytes.
Procedure:
The procedure for Node 1 is detailed. The procedure for Node 2 is essentially
identical apart from SyncE settings.
l Activate required Gig-E and radio interfaces, 0/9 and 2/1. See To
Enable or Disable a Port on page 40.
l Set the PVID to 110 on port 0/9 so that untagged frames (from the
SFP) are tagged on ingress, and untagged on egress (to the SFP):
aos(config-if)# end
l Set the priority (802.1p) on VLAN 110 to 5:
aos(config-if)# end
l Add member port ra 0/2 to VLAN 110:

l Configure SyncE on radio and SFP interfaces. Refer to ESMC on page

87.
Internal clocking is used by setting the input source on node 1, port 0/9,
where without a clock input on that port the clock falls back to internal.
Wait-to-restore and hold-off timers are not applicable.
Node 1:
aos(config)# end
Node 2:
aos(config)# end
Static LAG
LAG (static) and LACP are supported on CTR 8540 and CTR 8312.
Static LAG enables the bundling together of physical ports to form a single
logical channel.
l The capacity provided on multiple co-path links is aggregated to
provide one logical link of combined capacity.
l The links may be established on user-port connections to an external
switch.
o L1LA is required to aggregate co-path radio links.
l On the aggregation (trunk) port(s) the capacity supported is nominally
the sum of the capacity of each link.
l Links should be of the same port speed/duplex setting.
Load balancing is used to ensure traffic on the aggregation port is distributed as

evenly as possible over the co-path links.
l The load balancing mechanism L2 MAC-based. It takes no account of
the capacity supported on (configured on) member links.
l Should one link fail, its traffic is forwarded to the remaining link(s).
o Traffic on the failed link is momentarily interrupted.
o Traffic flows on the remaining link(s) are not affected unless

congestion occurs, and existing lower priority traffic is displaced

(dropped) under QoS action by higher priority traffic.
l When a failed link is restored, it is automatically brought back into the
LAG. Existing traffic flows are not affected.
l All packets associated with a particular end-end session are sent over
the same physical link - packets are not split across links.
The example below illustrates simple LAG operation on two user port
connections to an external switch.
VLAN 112 is used to map the aggregated channel group (port-channel 1) to the
front panel switchport 0/2.
Figure 8. Example Static LAG Application
l Install Carrier Ethernet feature license.
l Do not disable STP.
Procedure:
As the same interfaces are used on both nodes, the procedure is the same for
both nodes.
l Activate required Gig-E interfaces, o/5 and 0/6. See To Enable or
Disable a Port on page 40.


l To setup radio links for XPIC 2+2 operation, refer to Protected

CCDP/XPIC Link Operation (CTR 8540) on page 59.
l To setup L1LA on radio interfaces 2/1 and 2/2, refer to L1LA Operation
on page 61.

aos# show l1la status
l Configure the port-channel (port-channel is assigned a number: 1)
aos(config)# set port-channel enable
aos(config)# int port-channel 1
aos(config)# no shut
aos(config)# map sw default
aos(config)# end
To verify that the port-channel is created:

aos# show etherchannel port-channel
l Map the interfaces to the channel-group
aos(config)# int range gi 0/5-6
aos(config-if-range)# channel-group 1 mode on
aos(config)# exit
To verify that the switch interface is mapped to the channel-group:

aos# show etherchannel summary
l Map the port-channel and interface to a VLAN (112)
aos(config-vlan)# ports add port-channel 1 l1la 1
To display VLAN status:

aos# show vlan
Provider Edge Bridge Mode

NOTE: C LI s hould be us ed to s et the bridge mode and to configure
prov ider edge bridge QoS and C -VLAN to S-VLAN mapping - it is
eas ier/fas ter.
A provider edge bridge is used at the edge of a service provider network to

provide demarcation between customer and provider networks. At ingress
customer VLANs (C-VLANs) are encapsulated inside a provider VLAN (S-VLAN),
and the provider VLAN is used to determine traffic forwarding within the
provider network. At egress the provider VLAN tag is stripped.
The provider edge bridge is logically divided into C-VLAN (customer) and S-
VLAN (service provider) components, with internal PEP-to-CNP mapping
between.
l At ingress the C-VLAN bridge component supports selective frame
acceptance (filtering) and identification based on the presence of

customer VLAN tagged frames.

o The filtering includes options of untagged only, untagged and tagged,
tagged only, or tagged only but then only for frames with an 8100 or
88a8 TPID (Hexadecimal 0x8100 or 0x88a8).
o 8100 is most commonly used to identify a customer VID (CVID).
88a8 is normally used to identify a provider VID (SVID).
l The S-VLAN bridge component is responsible for tagging customer
frames with S-VLAN tags in the ingress direction and removing S-VLAN
tags in the egress direction.
o It is also responsible for running the provider's bridge protocol, such
as RSTP, MSTP, GVRP, etc.
o Each customer is assigned to one service instance (S-VLAN), which
can apply to multiple VLANs (C-VLANs) per customer.
o Up to 10 service bridge instances can be configured per CTR (based
on a max port availability of 20, and one-to-0ne mapping of S-VLAN
and C-VLAN components [ports]).
o Ingressing C-VLANs are tagged by the S-VLAN (frames are double
tagged).
o Ingressing untagged customer traffic can be port-tagged, in which
case frames are double-tagged by the S-VLAN.
l The designation of a port as a Customer Edge Port (CEP) implies
Provider Edge Bridge functionality and, specifically, the existence of a
C-VLAN component associated with that port. This C-VLAN component
is uniquely identified within the Bridge by the port number of the
associated CEP.
To allow local PC management access, the port type for management access
must be set to Proprietary Provider Network Port.
The following diagram and procedure illustrates basic operation.
l Customer 1 has tagged and untagged traffic. A Port VID (5) is
configured for untagged at ingress.
l Customer 2 has tagged traffic only.
l Both customers have an overlapping VID (33). These VLANs are held
separate over the service provider network.
l Each customer is assigned a unique S-VLAN.

Figure 9. Example Provider Edge Bridge Application
l Revert to factory defaults. See Revert to Default Config on page 44.
l Set Bridge Mode to Provider Edge. See To Set Bridge Mode on page 35
l To re-enable local management access on port 1, change port type to
Prop Provider Network Port. See Reestablishing Local Management
Access on page 39.
l Install required feature licenses: Carrier Ethernet and Gig-E SFP Ports.
Procedure:
l Activate required switch interfaces, 0/2, 0/3, 0/12. See To Enable or
Disable a Port on page 40.
l Assign port type as Customer Edge for the customer interfaces:
aos(config-if)# bridge port-type customerEdgePort
aos(config-if)# bridge port-type customerEdgePort
aos(config-if)# end
To show port type, per interface:

aos# show provider-bridge port config port gigabitethernet 0/2
l Add CEP port 0/2 to VLAN 5, where VLAN 5 is to be set as switchport
PVID for untagged frames:
aos(config)# vlan 5
To verify VLAN setting:

aos# show vlan

l On CEP port 0/2 configure the switchport PVID (to apply on untagged
frames):
aos(config-if)# end
To verify PVID setting:

aos# show vlan port config
l On CEP port 0/2 configure C-VLAN to S-VLAN mapping for tagged and
untagged:
aos(config-if)# switchport customer-vlan 33 service-vlan 140
untagged-pep False untagged-cep False
aos(config-if)# switchport customer-vlan 5 service-vlan 140 untagged-
pep False untagged-cep True
To show S-VLANs:
aos# show service vlan
l On CEP port 0/3 configure C-VLAN to S-VLAN mapping:
To show S-VLANs:
aos# show service vlan
l Configure the S-VLAN's and add ports 0/2 and 0/12, and 0/3 and 0/12,
as members. The S-VLAN tag is stripped (untagged) at CEP egress:
aos(config)# sw default
aos(config-switch)# vlan 140
aos(config-switch-vlan)# vlan active
aos(config-switch-vlan)# ports add gi 0/2,0/12 untagged gi 0/2
aos(config-switch-vlan)# exit
aos(config-switch)# vlan 150
aos(config-switch-vlan)# vlan active
aos(config-switch-vlan)# ports add gi 0/3,0/12 untagged gi 0/3
aos(config-switch-vlan)# end
To show VLAN status:

aos# show vlan

ECFM
ECFM (Ethernet Connectivity Fault Management), also known as Service OAM, is
used to detect network faults and provide measures of network performance. It
operates through use of messaging (CFM PDUs [Ethernet frames]) sent
alongside user traffic whereby the frame content defines the message type and
function.
l CTR support for CFM is compatible with the IEEE 802.1ag, and ITU-T
Y.1731 standards.
l These protocols allow for two types of maintenance points and up to
eight Maintenance Domains (MD’s) to be associated with a given
service.
l A Maintenance End Point (MEP) is used at the edge of a domain to
control management of a given service. A Maintenance Intermediate
Point (MIP) is optionally used within the domain, between MEPs, to aid
in the monitoring and maintenance of the service.
l The eight Maintenance Domain (MD) levels are typically grouped as
follows:
o Subscriber MD: Levels 5-7 are typically are allocated for Subscriber
use for managing the service within the Subscriber’s domain, e.g.,
from CE to CE.
o Service Provider MD: Levels 3-4 are typically allocated for Service
Provider use for managing the service within the Service Provider’s
domain, e.g., from UNI-to-UNI.
o Operator MD: Levels 1-2 are typically allocated for Operator use for
managing the service from within the Operator’s domain.
o UNI Maintenance Entity (UNI ME): The UNI ME, typically at level 0,
is allocated for managing the UNI link.
For more information refer to the CTR 8500/8300 CLI Reference Manual or to the
CTR 8500/8300 ECFM Configuration Guide.
CFM Message Types
Continuity Check (CC)
CFM CC functions support continuity checking for a given EVC (Ethernet Virtual
Connection) across the entire service using a CC Message (CCM), sent from one
MEP to another MEP. For services with more than two MEPs, CCMs are enabled
on all MEPs such that each MEP sends CCMs to all of its peers.

A service provider may elect to send CCMs at a fast rate to quickly detect
service failures, and perhaps switch the service to a back-up protected path.
Alternatively, CCMs could be sent at a slower rate to track the service
performance. Another use case is basic fault management, where CCMs are
used to detect loss of continuity or unintended connectivity among MEPs.
Link Trace
The CFM Link Trace (LT) or 'traceroute' function enables path tracing for a given
EVC across the entire service using a LT Message (LTM), which is sent on
demand from one MEP towards a target MEP (or target MIP). If a MIP is
configured between the MEPS at the same MD level as set in the LTM, the MIP
will respond with a LT Response (LTR) to the source MEP, and relay the original
LTM towards the target, with the TTL (Time To Live) field decremented.
Loopback
The CFM Loopback (LB) function enables the pinging of a target MEP or MIP using
an LB Message (LBM), which is sent on demand from one MEP towards the target
MEP or MIP. If a MIP is configured between the MEPs at the same MD level as set
in the LBM, and if the target for the LBM is the MIP itself, then the MIP will
respond with a LB Response (LBR) to the source MEP.
Example Network
In the example 802.1ag network below:
l Untagged frames received on ports 0/2 at each end of the network are
assigned a VLAN tag (PVID) of 6 over the network. This PVID is stripped
at egress.
l VLAN 6 is assigned to domain level 5
l The assigned domain name is 'wingate'
l The assigned service name is 'client1'
l MIPS are created indirectly on nodes 3 & 4 using implicit MIP creation
based on evaluation of the default MD level (5), corresponding to VLAN
6
o Where permitted it will create one MIP instance for every
vlan/interface pair on the bridge node
o Other evaluation objects can be selected for implicit MIP creation.
MIPs can also be created explicitly.

Figure 10. ECFM Example Network
l Configure slot 2 on all nodes for a RACx2 module.
l Install optical SFPs where shown on nodes 2 & 3.
l Install a Gig-E SFP license on nodes 2 & 3.
Procedure:
l Activate required Gig-E and radio interfaces. See To Enable or Disable
a Port on page 40.
Interface 0/2, 2/1 on nodes 1 & 4; interface 0/9, 2/1 on nodes 2 & 3.
l Set VLAN 6 port membership (0/2) and switchport PVID 6 on nodes 1
& 4:
aos(config)# vlan 6
aos(config-int)# switchport pvid 6
aos(config-int)# exit
l Set VLAN 6 port membership on nodes 2 & 3:
aos(config)# vlan 6
aos(config-vlan)# ports add gi 0/9

l Enable ECFM 802.1ag on all nodes:
aos(config)# ethernet cfm start
aos(config)# ethernet cfm enable
aos(config)# end
To confirm ECFM status:

aos# show ether cfm global info
l Configure ECFM entities on node 1:
aos(config)# ethernet cfm domain name wingate level 5
aos(config-ether-ecfm)# service name client1 vlan 6
aos(config-radio)# ethernet cfm mep domain wingate mpid 200 vlan 6
active
aos(config)# ethernet cfm cc enable domain wingate vlan 6
aos(config)# end
l Configure ECFM entities on node 4:
aos(config)# ethernet cfm domain name wingate level 5
aos(config-ether-ecfm)# service name client1 vlan 6
aos(config-radio)# ethernet cfm mep domain wingate mpid 201 vlan 6
active
aos(config)# ethernet cfm cc enable domain wingate vlan 6
aos(config)# end
l Configure ECFM entities on nodes 2 & 3:
aos(config)# ethernet cfm mip dynamic evaluation
aos(config)# ethernet cfm default-domain global level 5 mip-creation-
criteria default
aos(config)# end
The following show commands are available to verify ECFM configuration:

aos# show ether cfm maintenance-points local level 5
aos# show ether cfm domain brief
aos# show ether cfm domain
aos# show ether cfm service brief
aos# show ether cfm maintenance-points local detail mpid <local mpid
number e.g. 200>

aos# show ethernet cfm maintenance-points remote
To enable the traceroute and loopback cache:

aos(config)# ether cfm traceroute cache
aos(config)# ether cfm loopback cache
aos(config)# end
Use the following commands to verify configuration and to show errors:

aos# show ether cfm global information
aos# show eth cfm errors
The following commands are available to clear cached statistics, globally or specific:
aos# clear ether cfm statistics
aos# clear ether cfm statistics int ra 2/1
aos# clear ether cfm statistics int ra 2/1 level 5 vlan 6
aos# clear ethernet cfm traceroute-cache
To traceroute to the remote MAC:

aos# traceroute ethernet mac 00:e0:e2:70:b8:d6 level 5 vlan 6
To verify the traceroute log:

aos# show eth cfm traceroute-cache
To verify the LBR count:

aos# show ether cfm statistics int ra 2/1
To ping the remote MAC:

aos# ping ethernet mac 00:e0:e2:70:b8:d6 level 5 vlan 6
For more information on ECFM configuation and opertion, refer to the CTR
8500/8300 ECFM Configuration Guide.
IP/MPLS
CTR provides comprehensive MPLS capabilities with LDP and RSVP-TE signaled
LSPs. Layer 2 and layer 3 virtual private networks are supported.
l MPLS provides a mechanism to engineer traffic flows across a network

that are independent of routing tables. It does so by assigning short
labels to data packets that describe how to forward them through the
network.
l This is in contrast to Layer 3 forwarding where as a packet travels from
one router to the next, an independent forwarding decision is made at
each router based on analysis of the packet header and the information
learned and held in the node routing table.
l VPN services are offered at L2 (VPLS and VPWS) and L3 (L3VPN) to
provide a private network service delivered over a shared (provider)
network with each customer seeing their network as one dedicated to
their use.

Key IP/MPLS terms
Interior Gateway Protocol (IGP)
A protocol used to exchange routing information between routers in the same

autonomous system. All examples in this section use IS-IS as the IGP.
Layer 2 Virtual Private Network (L2VPN)
VPN service offered at layer 2 (link layer)
Layer 3 Virtual Private Network (L2VPN)
VPN service offered at layer 3. Traffic exchange happens at IP layer. The

provider network propagates routing information across different customer
sites.
Virtual Private Wire Service (VPWS)
This is a type of L2VPN service which provides point-to-point connectivity at

layer 2.
Virtual Private LAN Service (VPLS)
This service provides multipoint-to-multipoint connectivity at layer 2. This

service makes provider’s network appear as a virtual switch to the customer.
Attachment Circuit (AC)
This is the circuit or virtual circuit through which the customer edge device
connects to the provider edge device to access L2VPN service. The attachment
circuit could be a physical interface (e.g. an Ethernet port), a VLAN or a VLAN
over a specific physical interface.
Traffic Engineering (TE)
The capability to direct traffic flows across the network based on predefined
paths or user-defined criteria such as bandwidth, latency, etc. MPLS traffic
engineering has two key components:
l Traffic Engineering extensions (TE Extensions) to IGPs (for example,
IS-IS or OSPF) which allow traffic engineering metrics to be exchanged
across the routers in the network
l A signaling protocol which can signal MPLS label switched paths
calculated based on TE information.
CTR supports TE extensions to IS-IS protocol. CTR also supports RSVP-TE

protocol to signal TE LSPs.

Label Distribution Protocol (LDP)
LDP is another protocol used to signal MPLS Label Switched Paths (LSPs) across
MPLS network. When used for this purpose, LDP entity on each router
automatically forms adjacency with LDP entities in its immediate neighbours to
signal the LSPs across the network. This is non-targeted mode of operation. LDP
can also operate in targeted mode whereby the user manually configures the
adjacency. Non-targeted mode is typically used to signal MPLS labels for L2VPN
pseudowires across the edge devices on a service provider’s network. CTR
supports both non-targeted and targeted LDP modes.
The following sections show example networks and configurations to
demonstrate MPLS features of CTR. Following examples are included:
l VPWS Service over RSVP-TE signaled LSPs
l VPLS Service over RSVP-TE signaled LSPs
l L3VPN Service over LDP signaled LSPs
l TE LSPs with 1-to-1 End-to-End Protection
Example 1: VPWS Service

The following example illustrates configuration of a VPWS service over traffic-
engineered LSPs. Key steps for this configuration include:
l Configure required interfaces, ip addresses, and loopback interfaces.
Attachment Circuit ports are configured as switch ports. Ports
connecting provider devices are configured as router ports.
l Configure IS-IS with traffic engineering extensions on each CTR.
l Configure traffic engineering information for each link (TE-links).
l Configure RSVP-TE protocol on each CTR. RSVP-TE should be enabled
on all router ports in MPLS network.
l Configure targeted LDP sessions across the edge devices.
l Configure MPLS TE tunnels (LSPs) between the edge devices. Tunnels
are unidirectional and a tunnel needs to be configured at the head-end
router in each direction.
l Configure VPWS service over the MPLS TE tunnels and connect it to
the attachment circuit (AC) on each edge router.

In the figure above:

l R1 ,R2 ,R3 and R4 represent CTR's
l P1 , P2 ,P3 and P4 imply port 1 ,port 2 ,port 3 and port 4 respectively
l Host A, Host B and Host C represent Host devices connected to the
CTR's
Initial Configuration
Router R1
Creating the Interfaces:
Create a virtual context with the name default and shut down Spanning Tree:

Configure interfaces gi 0/1, 0/2 and 0/3

aos(config)# interface gi 0/3
aos(config)# end
Configure Loopback 0
aos(config)# interface loopback 0
Router R2
Creating the Interfaces
Create a virtual context with the name ‘default’ and shut down Spanning Tree.
Configure interfaces gi 0/1 and 0/2
aos(config)# end

Router R3
aos(config)# end
Router R4


aos(config)# end
After configuring the interfaces on all devices and ensuring physical

connectivity, use the following command to show the status of IP interfaces:
aos# show ip interface
Configuring ISIS
Router R1
Setup IS-IS with the following configuration:

l Network Entity Title per the above table

l Inter-Area Router (Level 2)
l Wide Metric
aos(config)# router isis
aos(config-router)# net 49:00:10:11:11:11:11:11:11:00
aos(config-router)# is-type level-2
aos(config-router)# metric-style wide
Enable IS-IS on Loopback 0
aos(config-if)# ip router isis
aos(config-if)#end
Enable network broadcast on all interfaces
aos(config-if)# interface gi 0/1
aos(config-if)# ip router isis broadcast
Router R2

l Wide Metric
aos(config-if)# end


Router R3

l Wide Metric
aos(config-if)#end
Router R4

l Wide Metric

aos(config-if)#end
After IS-IS is enabled on all CTRs, use the following commands to check the
routing table:
aos# show ip route
aos# show ip isis route
It will take a few seconds for the routing protocols to converge and the routing
information to become stable in the tables.
Configuring ISIS-TE
The base IS-IS protocol is not capable of exchanging traffic engineering

information by itself. To achieve this, TE extensions to IS-IS have to be turned
on in each device.
Router R1
Configure ISIS-TE
aos(config-router)# mpls traffic-eng router-id 1.1.1.1
aos(config-router)# mpls traffic-eng
Router R2
Configure ISIS-TE

Router R3
Configure ISIS-TE
Router R4
Configure ISIS-TE
Creating Traffic Engineering (TE) Links

TE link is an abstraction which allows the user to configure traffic engineering
specific information for every IP link on a device. The TE information includes a
TE metric and maximum/ minimum bandwidth. Care should be taken to ensure
that for every link, the parameters configured on routers at either end are
consistent.
Router R1
Create TE Link, te12, from P1 to P2 with the following configuration:

l IPv4 address type
l Metric 100
l Minimum bandwidth of 1024 bps
l Maximum bandwidth of 1 Gbps
l PSC1 switching capability
l Packet encoding
aos(config)# mpls traffic-eng tunnels
aos(config)# mpls traffic-eng
aos(config-mpls-te)#te-link te12
aos(config-mpls-te-link)# shutdown
aos(config-mpls-te-link)# address-type ipv4
aos(config-mpls-te-link)# metric 100

aos(config-mpls-te-link)# local te-link ipv4 10.0.12.1 remote te-

link ipv4 10.0.12.2
aos(config-mpls-te-link)# resource-class class-value 1
aos(config-mpls-te-link)# no shutdown
aos(config-mpls-te-link)# interface gigabitethernet 0/1
aos(config-mpls-comp-link)# min lsp bandwidth 1024
aos(config-mpls-comp-link)# max reservable bandwidth 1000000
aos(config-mpls-comp-link)# switching-capability psc1 encoding
packet
aos(config-mpls-comp-link)# no shutdown
aos(config-mpls-comp-link)# exit
aos(config-mpls-te)# advertise
l IPv4 address type
l Metric 100
l Packet encoding
link ipv4 10.0.14.4
packet
Router R2

l IPv4 address type

l Metric 100
l Packet encoding
link ipv4 10.0.12.1
packet
l IPv4 address type
l Metric 100
l Packet encoding
link ipv4 10.0.12.1

packet
Router R3

l IPv4 address type
l Metric 100
l • Packet encoding
link ipv4 10.0.23.2
packet

l IPv4 address type
l Metric 100


l Packet encoding
link ipv4 10.0.34.4
packet
Router R4

l IPv4 address type
l Metric 100
l Packet encoding
link ipv4 10.0.14.1


packet

l IPv4 address type
l Metric 100
l Packet encoding- z
link ipv4 10.0.34.3
packet

Enable MPLS IP on interfaces of all switches

Router R1
Enable MPLS IP on all the MPLS interfaces. This has to be done before any MPLS
specific protocols (RSVP-TE, LDP) can be used on the interface. MPLS IP should
be enabled only on router ports and not on AC ports which are configured as
switch ports.
aos(config-if)# mpls ip
Router R2
Enable MPLS IP on all the interfaces

aos(config-if)#shutdown
Router R3

aos(config-if)#no shutdown

Router R4

Enabling RSVP
Router R1
Configure RSVP and enable it on all the interfaces used in MPLS forwarding
(router ports). Once enabled, the RSVP-TE entity on the CTR will try to form
adjacency with RSVP-TE entity on the neighboring device on each link where
RSVP-TE has been enabled. After the adjacency is up, the link can be used in
RSVP-TE signaled LSPs.
aos(config)# rsvp
aos(config-rsvp)# router-id 1.1.1.1
aos(config-rsvp)# signalling label range min 100100 max 100199
aos(config-rsvp)# signalling hello supported
aos(config-rsvp)# signalling hello refresh interval 6000
aos(config-rsvp)# set rsvp enable
aos(config-rsvp)# interface gigabitethernet 0/1
aos(config-rsvp-if)# signalling hello supported
aos(config-rsvp-if)# no shutdown
aos(config-rsvp-if)# exit

Router R2
Configure RSVP and enable it on all the interfaces

aos(config)# rsvp
Router R3

aos(config)# rsvp
Router R4

aos(config)# rsvp


After configuring RSVP on all devices, the following CLI commands can be used
at any CTR to inspect the status:
aos# sh rsvp neighbor
aos# sh rsvp counters messages
Enabling T-LDP between R1 and R3

In this example, targeted LDP sessions are used to signal MPLs labels for L2VPN
pseudowires across the edge devices. CTR also supports manual configuration of
these labels. However, using T-LDP requires less configuration from the user.
This example shows configuration of L2VPN using T-LDP.
Router R1
Enable targeted LDP on R1 with the following configuration:

l Loopback 0 as Router ID (with force option)
l Targeted neighbour 3.3.3.3
l Label range 160100 – 160199
l Unsolicited label distribution
l Liberal label retention
aos(config)# mpls ldp
aos(config-mpls-ldp)# router-id loopback 0 force
aos(config-mpls-ldp)# entity 1
aos(config-mpls-ldp-entity-1)#neighbor 3.3.3.3 targeted
aos(config-mpls-ldp-entity-1)#ldp label range min 160100 max
160199
aos(config-mpls-ldp-entity-1)#transport-address tlv loopback 0
aos(config-mpls-ldp-entity-1)#label distribution unsolicited
aos(config-mpls-ldp-entity-1)#label retention liberal

aos(config-mpls-ldp-entity-1)# no shutdown
aos(config-mpls-ldp-entity-1)#end
Router R3

l Label range 160300 – 160399
160399
After configuring T-LDP on all devices, the following CLI commands can be used
aos# sh mpls ldp parameters
aos# sh mpls ldp neighbor
Tunnel Configurations
Unlike LDP signaled LSPs which are negotiated automatically, traffic engineered
MPLS tunnels have to be manually configured. MPLS TE tunnels are
unidirectional. Each tunnel is configured at the head end device. In this
example, a tunnel from R1 to R3 will be configured on R1, whereas the reverse
tunnel will be configured on R3.
LSP between R1 and R3
Configure a Label Switched Path between R1 and R3

Router R1
Setup an LSP from R1 to R3 with the following configuration:

l RSVP signalling
l 20 Mbps bandwidth
l Q7 priority
l Dynamic operation. For explicit path configuration see Example 4: End-
to-End Protection Switching on page 166.
aos(config)# interface mplstunnel 113
aos(config-if)# tunnel mpls destination 3.3.3.3 source 1.1.1.1
aos(config-if)# tunnel signalling protocol rsvp
aos(config-if)# tunnel mode mpls traffic-eng
aos(config-if)# tunnel mpls traffic-eng bandwidth 20000
aos(config-if)# tunnel mpls traffic-eng priority 7 7
aos(config-if)# tunnel endpoint capability encoding lsp-packet
switching psc1
aos(config-if)# tunnel type mpls
aos(config-if)# tunnel mpls traffic-eng path-option number 1
dynamic
aos(config-if)# end
Router R3
l RSVP signalling
l 20 Mbps bandwidth
l Q7 priority
switching psc1
dynamic
aos(config-if)# end

After configuring the tunnels, the following CLI commands can be used to
inspect the status of tunnels on edge and transit devices:
aos# sh rsvp request
aos# show mpls traffic-engineering tunnels brief
aos# show mpls traffic-engineering tunnels
VPWS between R1 and R3
Create a VPWS between R1 and R3. VPWS is a point to point service and is
configured directly under the attachment circuit interface on each device.
Router R1
Setup a VPWS from R1 to R3 with the following configuration. gi 0/2 is used as

attachment circuit on this device.
aos(config)# interface gigabit ethernet 0/2
mpls l2transport pwidfec 3.3.3.3 pwid 1 groupid 1 mplstype te 113
131
Router R3
Setup a VPWS from R3 to R1 with the following configuration. gi 0/1 is used as

attachment circuit on this device.
aos(config)# interface gigabit ethernet 0/1
mpls l2transport pwidfec 1.1.1.1 pwid 1 groupid 1 mplstype te 131
113
aos(config-if)# show mpls l2transport detail
Example 2: L2VPN VPLS Configuration

The following example illustrates configuration of a VPLS service over traffic-
engineered LSPs. Key steps for this configuration include:
l Configure IS-IS with traffic engineering extensions on each CTR.
l Configure traffic engineering information for each link (TE-links).
l Configure RSVP-TE protocol on each CTR. RSVP-TE should be enabled
on all router ports in MPLS network.
l Configure targeted LDP sessions across the edge devices.
l Configure MPLS TE tunnels (LSPs) between the edge devices. Tunnels

are unidirectional and a tunnel needs to be configured at the head-end

router in each direction.
l Configure MPLS OAM for VCCV configuration.
l Configure VPLS service over the MPLS TE tunnels and connect it to the
attachment circuit (AC) on each edge router.
l Configure VCCV control channel capabilities and connectivity
verification capabilities.

l R1 ,R2 ,R3 and R4 represent CTR's
l P1 , P2 ,P3 and P4 imply port1 ,port 2 ,port 3 and port 4 respectively
l Host A, Host B and Host C represent Host devices connected to the
CTR's

To connect Host A, Host B and Host C, VPLS needs to be created between R1, R3
and R4.
Router R1
aos(config)# end
Router R2

aos(config)# end
Router R3

aos(config)# end
Router R4
aos(config)# end
After configuring the interfaces on all devices and ensuring physical

connectivity, use the following command to show the status of IP interfaces:

Configuring ISIS
Configure the R routers with the following NET IDs.
Router R1

l Wide Metric
aos(config-if)#end
Router R2


l Wide Metric
aos(config-if)# end
Router R3

l Wide Metric
aos(config-if)#end

Router R4

l Wide Metric
aos(config-if)#end
After IS-IS is enabled on all CTRs, use the following commands to check the
routing table:
aos# show ip route
It will take a few seconds for the routing protocols to converge and the routing
information to become stable in the tables.

Configuring ISIS-TE
The base IS-IS protocol is not capable of exchanging traffic engineering
information by itself. To achieve this, TE extensions to IS-IS have to be turned
on in each device. The following commands enable ISIS-TE on the routers.
Router R1
Configure ISIS-TE
Router R2
Configure ISIS-TE
Router R3
Configure ISIS-TE
Router R4
Configure ISIS-TE

Creating Traffic Engineering (TE) Links

TE link is an abstraction which allows the user to configure traffic engineering
specific information for every IP link on a device. The TE information includes a
TE metric and maximum and minimum bandwidth.
Router R1
Create TE Link, ‘te12’, from P1 to P2 with the following configuration:

l IPv4 address type
l Metric 100
l Packet encoding
link ipv4 10.0.12.2
packet
l IPv4 address type
l Metric 100
l Packet encoding


link ipv4 10.0.14.4
packet
Router R2

l IPv4 address type
l Metric 100
l Packet encoding
link ipv4 10.0.12.1
packet

l IPv4 address type
l Metric 100
l Packet encoding
link ipv4 10.0.12.1
packet
Router R3

l IPv4 address type
l Metric 100
l Packet encoding

link ipv4 10.0.23.2
packet
l IPv4 address type
l Metric 100
l Packet encoding
link ipv4 10.0.34.4
packet

Router R4

l IPv4 address type
l Metric 100
l Packet encoding
link ipv4 10.0.14.1
packet
l IPv4 address type
l Metric 100
l Packet encoding


link ipv4 10.0.34.3
packet
Enable MPLS IP on interfaces of all switches

Router R1
specific protocols (RSVP-TE, LDP) can be used on the interface. MPLS IP should
be enabled only on router ports and not on AC ports which are configured as
switch ports.
Router R2


Router R3

Router R4

Enabling RSVP
Router R1
Configure RSVP and enable it on all the interfaces used in MPLS forwarding
(router ports). Once enabled, the RSVP-TE entity on CTR will try to form
adjacency with RSVP-TE entity on the neighboring device on each link where
RSVP-TE has been enabled. After the adjacency is up, the link can be used in
RSVP-TE signaled LSPs.
aos(config)# rsvp


Router R2

aos(config)# rsvp
Router R3

aos(config)# rsvp

Router R4

aos(config)# rsvp
After configuring RSVP on all devices, the following CLI commands can be used
aos# sh rsvp neighbor
aos# sh rsvp counters messages

In this example, targeted LDP sessions are used to signal MPLs labels for L2VPN
pseudowires across the edge devices. CTR also supports manual configuration of
these labels. However, using T-LDP requires less configuration from the user.
This example shows configuration of L2VPN using T-LDP.
Router R1

l Label range 160100 – 160199


161399
Router R3

l Label range 160300 – 160399
163199

Router R1


l Label range 160100 – 160199

161499
Router R4

l Label range 160300 – 160399
164199

Router R3


l Label range 160100 – 160199
163499
Router R4

l Label range 160300 – 160399
164399
After configuring T-LDP on all devices, the following CLI commands can be used
aos# sh mpls ldp parameters
aos# sh mpls ldp neighbor

Unlike LDP signaled LSPs which are negotiated automatically, traffic engineered
MPLS tunnels have to be manually configured. MPLS TE tunnels are
unidirectional. Each tunnel is configured at the head end device. In this
example, a tunnel from R1 to R3 will be configured on R1, whereas the reverse
tunnel will be configured on R3.

Router R1

l RSVP signalling
l 20 Mbps bandwidth
l Q7 priority
switching psc1
dynamic
aos(config-if)# end
Router R3

l RSVP signalling
l 20 Mbps bandwidth
l Q7 priority


switching psc1
dynamic
aos(config-if)# end

Router R1

l RSVP signalling
l 20 Mbps bandwidth
l Q7 priority
l Dynamic operation
switching psc1
dynamic
aos(config-if)# end
Router R4

l RSVP signalling
l 20 Mbps bandwidth

l Q7 priority
l Dynamic operation
switching psc1
dynamic
aos(config-if)# end

Router R3

l RSVP signalling
l 20 Mbps bandwidth
l Q7 priority
l Dynamic operation
switching psc1
dynamic
aos(config-if)# end
Router R4

l RSVP signalling
l 20 Mbps bandwidth
l Q7 priority
l Dynamic operation
switching psc1
dynamic
aos(config-if)# end
MPLS OAM Configuration
At R1
Entering the global configuration mode

Enabling OAM globally
aos(config)# mpls oam enable
Enabling notification for pseuowire status
aos(config)# pseudowire-notification pw-status
Configuring global Control channel capabilities
aos(config)# pw-cc-capability pw-ach router-alert-label ttl-expiry
Configuring global Connectivity Verification capabilities
aos(config)# pw-cv-capability lsp-ping bfd-ach-encap-fault bfd-
ach-encap-fault-status-notify
At R3
Entering the global configuration mode


Enabling OAM globally
aos(config)# mpls oam enable
Enabling notification for pseuowire status
aos(config)# pseudowire-notification pw-status
Configuring global Control channel capabilities
aos(config)# pw-cc-capability pw-ach router-alert-label ttl-expiry
Configuring global Connectivity Verification capabilities
aos(config)# pw-cv-capability lsp-ping bfd-ach-encap-fault bfd-
ach-encap-fault-status-notify
VLAN Configuration
Create a VLAN for the VPLS on R1, R3 and R4. In this example, the attachment
circuit is VLAN 102 over physical port specified on each device. This is known as
Port + VLAN attachment circuit.
Router R1
Include Port 1 (gi 0/1)

aos(config-vlan)# ports gi 0/1
Router R3

Router R4

VPLS between R1, R3 and R4
Create a VPLS service between R1, R3 and R4. VPLS and VCCV configurations
has to be applied on all edge routers participating in the VPLS instance. Full
mesh of L2VPN pseudowires is configured.

Router R1
Setup a VPLS with R3 and R4 with the following configuration. Pseudowires are
created to R3 and R4. A virtual forwarding instance is created and connected to
attachment circuit which is VLAN 102 over port gi 0/1.
aos(config-switch)# l2 vfi VPLS_R1_R3_R4 manual
aos(config-switch-vfi)# vpn 102
aos(config-switch-vfi)# neighbor 3.3.3.3 pwidfec pwid 213 groupid
1 encapsulation mpls mplstype te 213 231
Configuring VCCV control channel capabilities and connectivity verification
capabilities.
aos(config-switch-vfi)# pseudowire-oam pwid 213 local-cc-type
router-alert-label local-cv-type lsp-ping bfd-ach-encap-fault
remote-cc-type router-alert-label remote-cv-type lsp-ping bfd-ach-
encap-fault

capabilities.
encap-fault
aos(config-switch-vfi)# end
aos(config-switch-vfi)# xconnect vfi VPLS_R1_R3_R4 port-vlan vlan
102
end
Router R3


capabilities.
encap-fault

capabilities.
encap-fault
102
end
Router R4
102
end

After configuration is complete, the following CLI commands can be used to

inspect the status of service at each edge router:
aos# sh mpls l2transport detail
aos# sh vfi
aos# show mpls l2transport global information
aos#ping mpls pseudowire 1.1.1.1 vc-id 1 encap-type vccv-
negotiated
Example 3: L3VPN Configuration

L3VPN service provides VPN connectivity at IP layer. The provider and customer
routers collaborate in routing decisions. However, customer’s traffic and routing
information is kept separate from the other customers and provider in the
provider’s network. This example uses static routing on the interface between
CE and PE. However, CTR supports other configurations where dynamic routing
protocols can be used on CE-R interface to announce routes from a customer
site to the provider’s edge device. These routes can then be propagated
automatically to the customer sites.
The following example illustrates configuration of an L3VPN service over LDP
signaled LSPs with static routing at CE-PE interface. Key steps for this
configuration include:
l Configure IS-IS as the IGP.
l Configure non targeted LDP to signal MPLS LSPs across the network.
l Configure MP-BGP sessions on provider edge routers.
l Configure static routes on CE devices.

l 1 ,2 and 3 represent CTR's
l CE1 and CE2 are Customer Edge devices connected at each end of the
L3VPN

Router R1
aos(config-switch)# shutdown lldp
Configure interface gi 0/10
aos(config)# end
Router R2


Configure interfaces gi 0/10 and l1la 1
aos(config)# interface l1la 1
aos(config)# end
Router R3
Configure interface l1la 1
aos(config)# interface l1la 1

aos(config)# end
Router 6 (CE1)
aos(config)# end
aos(config)# end
aos(config-if)# no ip address
aos(config)# end

Router 7 (CE2)
aos(config)# end
aos(config)# end
aos(config-if)# no ip address
aos(config)# end
After creating IP interfaces, use the following CLI command to check their status
on each device:

Configuring ISIS
IS-IS is used as the IGP within the provider’s network in this example.
Configure the R routers with the following NET IDs.
Router R1
Setup IS-IS with the following configuration

l Wide Metric
aos(config-if)#end
aos(config)# end
Router R2

l Wide Metric


aos(config-if)# end
aos(config-if)# interface l1la 1
Router R3

l Wide Metric
aos(config-if)#end
aos(config)# end

After waiting for the routing protocol to converge, the routing tables can be
inspected using following CLI commands on any CTR in provider’s network:
aos# show ip route
Enable MPLS IP on the MPLS interfaces

specific protocols (RSVP-TE, LDP) can be used on the interface.
Router R1

aos(config)# end
Router R2

aos(config)# end
Router R3


aos(config)# end
Enabling LDP
The following example demonstrates using LDP as a signalling protocol to signal
MPLS LSPs. An LDP entity has to be created on each MPLS router in provider's
network. By default, LDP will be enabled on all interfaces on which MPLS IP has
been enabled. The LDP entities will form adjacency with the neighbors on all the
MPLS enabled links and will participate in label negotiation and LSP signaling.
Router R1
Enable LDP on R1 with the following configuration

l Label range 4100 – 4199
aos(config-mpls-ldp-entity-1)# ldp label range min 4100 max 4199
aos(config-mpls-ldp-entity-1)# label distribution unsolicited
aos(config-mpls-ldp-entity-1)# label retention liberal
aos(config-mpls-ldp-entity-1)# transport-address tlv loopback 0
Router R2
Enable LDP on R1 with the following configuration

aos(config-mpls-ldp-entity-1)# ldp label range min 4200 max 4299
aos(config-mpls-ldp-entity-1)# label distribution unsolicited
aos(config-mpls-ldp-entity-1)# label retention liberal
aos(config-mpls-ldp-entity-1)# transport-address tlv loopback 0

Router R3
Enable targeted LDP on R1 with the following configuration

aos(config-mpls-ldp-entity-1)#ldp label range min 4300 max 4399
After configuring LDP on all MPLS routers use following CLI commands to inspect
the status of LDP entities and the LDP database:
aos# show mpls ldp parameters
aos# show mpls ldp discovery
aos# show mpls ldp neighbor
aos# show mpls ldp database
VRF Configurations
A VRF has to be configured for each L3VPN service. VRF is only configured in
provider edge devices. Other devices in the provider’s network simply forward
MPLS labeled traffic and are agnostic to VPN service.
VRF between R1 and R3
Configure a Virtual Routing and Forwarding instance between R1 and R3

Router R1
Setup a VRF from R1 to R3


aos(config-if)# end
aos(config)# ip vrf red
aos(config)# end
aos(config-if)# ip vrf forwarding red
aos(config-if)# end
Define a static route for customer data
aos(config)# ip vrf red 6.6.6.6 255.255.255.255 20.0.67.6
aos(config)# end
aos(config)# ip vrf red mpls
aos(config-vrf)# rd 100:11
aos(config-vrf)# route-target export 700:11
aos(config)# end
Router R3
Setup a VRF from R3 to R1

aos(config-if)# end
aos(config)# ip vrf red
aos(config)# end
aos(config-if)# ip vrf forwarding red
aos(config-if)# end
Define a static route for customer data
aos(config)# ip vrf red 7.7.7.7 255.255.255.255 30.0.76.6

aos(config)# end
aos(config)# ip vrf red mpls
aos(config-vrf)# rd 300:11
aos(config)# end
MP-BGP over the backbone
Configure MP-BGP to establish routes between R1 and R3.

Router R1
Setup a MP-BGP on R1 with the following configuration

aos(config)# as-num 500
aos(config)# router bgp 500
aos(config-router)# bgp router-id 1.1.1.1
aos(config-router)# label-allocation-mode per-vrf
aos(config-router)# neighbor 3.3.3.3 remote-as 500
aos(config-router)# neighbor 3.3.3.3 update-source 1.1.1.1
aos(config-router)# address-family vpnv4
aos(config-router)# neighbor 3.3.3.3 activate
aos(config-router)# address-family vpnv4 vrf red
aos(config-router)# redistribute all
Router R3
Setup a MP-BGP on R3 with the following configuration

aos(config)# as-num 500
aos(config-router)# bgp router-id 3.3.3.3
aos(config-router)# label-allocation-mode per-vrf
aos(config-router)# neighbor 1.1.1.1 remote-as 500
aos(config-router)# neighbor 1.1.1.1 update-source 3.3.3.3
aos(config-router)# address-family vpnv4
aos(config-router)# neighbor 1.1.1.1 activate

aos(config-router)# address-family vpnv4 vrf red

aos(config-router)# redistribute all
Add a route through the L3VPN
Add a route for customer data from CE1 to CE2 through the L3VPN
Router 6 (CE1)
Add route through the L3VPN

aos(config)# end
After configuration is complete, the following CLI commands can be used to
inspect the status:
aos# show ip route
aos# sh ip vrf
aos# show ip bgp vpnv4 all
Router 7 (CE2)
Add route through the L3VPN

aos(config)# end
Example 4: End-to-End Protection Switching

The following example illustrates the 1-to-1 end-to-end protection feature for
MPLS-TE LSPs. This feature allows the user to specify two path options for a
tunnel through the network. Option 1 is the working path and option 2 is the
protecting path. Normally, the tunnel will be established over path option 1. In
case of a node or link failure on the path, the tunnel and the traffic will quickly
switch over to path option 2. The paths specified can be dynamic or explicit. If
the path is specified as dynamic, the head endrouter will calculate the route for
the tunnel based on the constraints specified by the user (for example,
bandwidth required for the tunnel) and the traffic engineering topology
information for the network which the head end learns using IGP’s TE
extensions. In case of explicit path, the user manually specifies the path for the
tunnel as a sequence of IP addresses for each hop through the network. The
explicit path could be strict, in which case every single hop is specified by the
user, or loose, in which case a subset of hops is specified. On CTR, the working
path can be dynamic or explicit. However the protecting path has to be explicit.

The topology is similar to Example 1: VPWS Service on page 106. This example
illustrates setting up MPLS tunnel with dynamic working path and explicit /strict
protecting path. Once the protected tunnel is configured, steps in examples 1, 2,
or 3 could be followed to establish a VPN service over the tunnel.
In the figure below:

l R1 ,R2 ,R3 and R4 represent AOS switches
l P1 , P2 ,P3 and P4 imply port1 ,port 2 ,port 3 and port 4 respectively
l HostA, HostB and HostC represent Host devices connected to the AOS
switches
Figure 11. Topology Setup for Protected Configuration

Initial Configurations
This section explains the initial configurations for entering different modes.
At R1:
To Configure R1 execute the following commands:

Create a virtual context with the name default and shut down the spanning tree:
Configure Loopback 0 at R1:

Configure interfaces 0/1, 0/2 and 0/3:

aos(config)# end
At R2:



Configure interfaces 0/1 and 0/2:

aos(config)# end
At R3:





aos(config)# end
At R4:



aos(config)# end

Configuring ISIS
At R1
Enter the Global Configuration mode

Enable the ISIS routing process

Configure the network entity title

Configure the is-type as level-2

Configure the isis metric to wide

Exit from the Router Configuration mode

Enter the Global Configuration mode.

Enable ISIS in process on loopback 0

aos(config-if)#end

Enable broadcast network in all interfaces

At R2








aos(config-if)#end


At R3









aos(config-if)#end


At R4








aos(config-if)#end



Configuring ISIS-TE on the Router

Execute the following commands for all switches:
At R1

Enable the ISIS routing process.

Set the ISIS-TE


At R2


Set the ISIS-TE


At R3


Set the ISIS-TE


At R4



Set the ISIS-TE


Creating TE Links
At R1
Creating TE-Link at P2:

Enable TLM module

Enter into TLM configuration mode.

Configure a te-link ‘te12’

Disable the te-link

Configure the address type of the te-link

aos(config-mpls-te-link)#address-type ipv4
Configure the metric of the te-link

aos(config-mpls-te-link)#metric 100
Configure the router identifier of the remote router

aos(config-mpls-te-link)#local te-link ipv4 10.0.12.1 remote te-link ipv4
10.0.12.2
Configure the resource-class of the te-link

aos(config-mpls-te-link)#resource-class class-value 1
Enable the te-link

Associate a component link with the te-link

Configure minimum LSP bandwidth of the component link

aos(config-mpls-comp-link)#min lsp bandwidth 1024
Configure maximum reservable bandwidth of the component link

aos(config-mpls-comp-link)#max reservable bandwidth 1000000
Configure switching and encoding type of the component link

aos(config-mpls-comp-link)#switching-capability psc1 encoding packet
Enable the component link

aos(config-mpls-te)#advertise

Enable TLM module



Disable the te-link




10.0.14.4

Enable the te-link







At R2

Enable TLM module



Disable the te-link




10.0.12.1

Enable the te-link







Enable TLM module



Disable the te-link




10.0.23.3

Enable the te-link






At R3

Enable TLM module



Disable the te-link




10.0.23.2

Enable the te-link







Enable TLM module



Disable the te-link




10.0.34.4

Enable the te-link






At R4

Enable TLM module



Disable the te-link




10.0.14.1


Enable the te-link







Enable TLM module



Disable the te-link




10.0.34.3

Enable the te-link







Enable MPLS IP on the interfaces for all switches
At R1

Enable MPLS IP network in all interfaces

At R2


At R3


At R3


Enabling RSVP on Interfaces

At R1

Enter the RSVP Configuration mode

aos(config)# rsvp
Configure router-id
Configure RSVP parameters

Enable RSVP globally on the router

Configure RSVP on interfaces


At R2


aos(config)# rsvp
Configure router-id



At R3


aos(config)# rsvp
Configure router-id




At R4


aos(config)# rsvp
Configure router-id



aos(config-rsvp-if)# end

At R1

Entering the MPLS ldp Configuration Mode

Configuring the loopback 0 as the router-id with force option

Create a MPLS ldp entity for targeted LDP session

Configuring a neighbor as target

Assign minimum and maximum range of labels for the entity

Configuring the transport address with loopback 0

Configuring the label distribution as unsolicited

Configuring the label retention as liberal

Enabling the label distribution

Returning to Global Configuration Mode

At R3

Entering the MPLS ldp Configuration Mode

Configuring the loopback 0 as the router-id with force option

Create a MPLS ldp entity for targeted LDP session

Configuring a neighbor as target

Assign minimum and maximum range of labels for the entity

Configuring the transport address with loopback 0

Configuring the label distribution as unsolicited

Configuring the label retention as liberal

Enabling the label distribution

Returning to Global Configuration Mode

Hop Table Configurations
Before a strict path can be used as a path option for an MPLS TE tunnel, the path
needs to specified as a sequence of IP addresses for each hop. The path thus
created is given an ID and is saved in the configuration to be used in the tunnel
configuration.
At R1
Enter Global Configuration mode:

Configure path identifier and path option 1

aos(config)# ip explicit-path identifier 1 path-option number 1
Configure individual hops in path-option

aos(cfg-ip-expl-path)# index 1 next-address strict 2.2.2.2
Return to root mode

aos(cfg-ip-expl-path)# end

Configure path identifier and path option 2

aos(config)# ip explicit-path identifier 1 path-option number 2
Configure individual hops in path-option

Return to root mode

aos(cfg-ip-expl-path)# end
At R1
Execute the following commands:

Enter Tunnel mode

aos(config)#interface mplstunnel 113
Configure the source and destination of the tunnel

aos(config-if)#tunnel mpls destination 3.3.3.3 source 1.1.1.1
Configure signaling protocol for the tunnel

aos(config-if)#tunnel signalling protocol rsvp

Configure tunnel mode as mpls-te

aos(config-if)#tunnel mode mpls traffic-eng
Configure tunnel bandwidth

aos(config-if)#tunnel mpls traffic-eng bandwidth 40000
Specify the encoding type and switching type for the tunnel
aos(config-if)#tunnel endpoint capability encoding lsp-packet switching psc1
Specify the tunnel type

Associate hop table indexes with tunnel

aos(config-if)#tunnel mpls traffic-eng path-option number 1 explicit
identifier 1
Associate hop table indexes with back up tunnel

aos(config-if)#tunnel mpls traffic-eng backup path-option number 2 explicit
identifier 1
Specify end to end protection type

aos(config-if)# tunnel mpls end-to-end protection-type one-to-one
Enabling the tunnel

Returning to the root mode

aos(config-if)# end
After configuring tunnels, the following CLI commands can be used to inspect
the status of tunnels on edge and transit devices:
You need to pay attention to Protection status – this should normally say
Available to indicate that protection is configured and the protecting path is
available. In case of a failure on working path, the tunnel switches to protecting
path and the protection status should say in use.
Example 5: BFD Configuration

The Aviat Networks BFD software is a portable implementation of the
Bidirectional Forwarding Detection Protocol which provides fast forwarding-path
failure detection between two forwarding engines connected by a link.
This section describes configuration of the Aviat Networks BFD features using
CLI interfaces.
To configure BFD over MPLS Tunnel, execute the following commands:

At R1
This command enters into the global configuration mode

aos#config terminal
No form of the command starts BFD functionality.
aos(config)# no shutdown bfd
Enables the bfd functionality
aos(config)# bfd enable
Creates the BFD session and enters into the BFD session mode.(no form deletd
the BFD session)
aos(config)# bfd session 1
Creates the parameters of the path to be monitored and configures the BFD
session for MPLS Paths.
aos(config-bfdsess)# bfd mpls traffic-eng tunnel 113 source
1.1.1.1 destination 3.3.3.3
Sets the BFD session interval to be used for monitoring the path of the BFD(no
form sets the interval values to default)
aos(config-bfdsess)# bfd interval 400 min_rx 400 multiplier 5
To set the system role for the BFD session(active/passive)
aos(config-bfdsess)# bfd params role active
Configuring the BFD session type
aos(config-bfdsess)# bfd params sess-type single-hop
Session discriminator to be used by the remote system for the BFD session.
aos(config-bfdsess)# bfd params remote-discr 2
BFD session mode (cc/cv)
aos(config-bfdsess)# bfd params mode cc
Flags configuration for BFD session
aos(config-bfdsess)# bfd set offload
Returing to the root mode
aos(config-bfdsess)# end
At R3
This command enters into the global configuration mode

aos#config terminal
No form of the command starts BFD functionality.
aos(config)# no shutdown bfd
Enables the bfd functionality
aos(config)# bfd enable
Creates the BFD session and enters into the BFD session mode.(no form deletd
the BFD session)

aos(config)# bfd session 2

Creates the parameters of the path to be monitored and configures the BFD
session for MPLS Paths.
aos(config-bfdsess)# bfd mpls traffic-eng tunnel 131 source
3.3.3.3 destination 1.1.1.1
Sets the BFD session interval to be used for monitoring the path of the BFD(no
form sets the interval values to default)
aos(config-bfdsess)# bfd interval 400 min_rx 400 multiplier 5
To set the system role for the BFD session(active/passive)
aos(config-bfdsess)# bfd params role active
Configuring the BFD session type
aos(config-bfdsess)# bfd params sess-type single-hop
Session discriminator to be used by the remote system for the BFD session.
aos(config-bfdsess)# bfd params remote-discr 1
BFD session mode (cc/cv)
aos(config-bfdsess)# bfd params mode cc
Flags configuration for BFD session
aos(config-bfdsess)# bfd set offload
Returing to the root mode
aos(config-bfdsess)# end
After configuring the BFD following CLI commands can be used to inspect the
status:
aos#Show bfd global info
aos#Show bfd session details/mapping/summary
aos#Show bfd stats
aos#Show bfd neighbours summary/detail/all

Example 6: POLICING PER L2VPN

Figure 12. Ingress and egress policing for L2VPN services
Policing for L2VPN services (VPWS, VPLS) is configured at the attachment

circuits (AC) in provider edge routers. The objective is to police the traffic for
each L2VPN customer. Ingress policing applies to the traffic which a customer
edge device feeds in to the L2VPN service. Egress policing applies to the
aggregate L2VPN traffic leaving the MPLS network towards a particular
customer edge device. Note that the above diagram shows a simplified case of
point to point network. In case of VPLS, the aggregate egress traffic might
include multiple streams of traffic originating from different PE devices.
In AOS Release 3.4, CTR supports egress policing per L2VPN service. Ingress
policing can be achieved using L2QOS in combination with classification based
on ACLs (incorporating ports, VLANs or combinations). L2VPN policing is
configured at the attachment circuit which can be a port, VLAN or Port + VLAN.
In case of multiple attachment circuits at a device, policing should be configured
at each attachment circuit individually.
This example demonstrates L2VPN policing configuration for a VPLS service with
Port + VLAN attachment circuits. The topology and network used is the same as
in Example 2: L2VPN VPLS Configuration.

Configuring VPLS
Follow all steps in example 2 to set up the VPLS service with Port + VLAN based
attachment circuits.
Configuring Ingress Policing

The following steps will configure ingress policing for L2VPN traffic at the
attachment circuits on all three PE routers (R1, R2, R4). Attachment circuits are:
At R1: Port gi 0/1 VLAN 102
Note that the ingress policing is configured using L2QOS functions.
Configure ACL
At routers R1, R3, R4
Create access control list with VLAN 102 which is the VLAN for Port+VLAN
Attachment circuits:
aos(config)# mac access-list extended 10
aos(config-ext-macl) # permit any any vlan 102
aos(config-ext-macl) # end
Associate ACL with attachment circuit port
At router R1
aos(config-if)# mac access-group 10 in
aos(config-if)# end

At routers R3 and R4
aos(config-if)# mac access-group 10 in
aos(config-if)# end
Create Class Maps
Create class map based on the ACL set up above.

aos(config-cls-map)# set class 10 pre-color none
aos(config-cls-map)#match access-group mac-access-list 10
aos(config-cls-map)# end
Create Meters
Create metering configuration to be used for policing. In this case CIR is

40Mbps, CBS is 10240, EIR is 50Mbps EBS is 10240 and the meter is color-blind.
aos(config)# meter 10
aos(config-meter)# meter-type mefDeCoupled cir 5000000 cbs 10240
eir 6250000 ebs 10240
aos(config-meter)# end
Create Policy Map
Create policy maps with settings: yellow traffic marked with PCP=0, red traffic
dropped. Apply the class maps and meters created above to the policy map.
aos(config-ply-map)# set meter 10 exceed-action set-inner-vlan-pri
0 violate-action drop
aos(config-ply-map)# end
Configuring Egress Policing

The following steps will configure egress policer for L2VPN traffic at the
attachment circuits on all three PE routers (R1, R2, R4). Attachment circuits are:


Create Meters
Create metering configuration to be used for policing. In this case CIR is

50Mbps, CBS is 10240
aos(config)# meter 20
aos(config-meter)# meter-type simpleTokenBucket cir 6250000 cbs
10240
aos(config-meter)# end
Create Policy Map

aos(config-ply-map)# set meter 20 violate-action drop
aos(config-ply-map)# end
Apply policy settings to VPLS attachment circuits
At router R1
aos(config-vlan)# l2vpn-rate-limit egress set policy 20 interface
gigabitethernet 0/1
aos#
At routers R3 and R4
aos(config-vlan)# l2vpn-rate-limit egress set policy 20 interface
gigabitethernet 0/2
aos#
The active configuration can be viewed using the following command:
aos#show l2vpn-rate-limit

Authentication, Authorization and Accounting

(AAA)
Configuring TACACS+ to perform AAA

Configure a TACACS+ server:
aos (config)# tacacs-server 1 address 12.0.0.1 port 49 key
5h8s4y%E^o8*
Configure the server timeout to 3 seconds:
aos(config)# tacacs-client timeout 3
Configure TACACS+ with fall back to Local as AAA method:
aos(config)# login authentiction tacacs local
Configure TACACS+ Accounting:
aos(config)# aaa accounting login tacacs
Deconfiguring TACACS+
Deconfigure a TACACS+ server so it is no longer used by the CTR:
aos(config)# no tacacs-server 1
Configure local AAA method (instead of TACACS+);
aos(config)# login authentication local
Deconfigure TACACS+ Accounting if required:
aos(config)# no aaa accounting login tacacs

CTR Portal
CTR Portal provides an easy-to-use interface for configuration, monitoring,
maintenance, and diagnostic functions.
CTR Portal should be used to:
o Load SW, license, and configuration files
o Configure radio/links
o Set plug-in slots
o Set Bridge Mode
o Set Router ports
o Configure basic OSPF
o Configure switch-port settings
o Configure QoS
o Configure VLANs
o Set local date and time
o View/access alarms, diagnostics, performance, events, statistics
o Configure L1LA
o Configure MEF 8 pseudowire (E1 only)
o Configure Synchronous Mode
CTR Portal access is achieved through one of the following browsers:
l Internet Explorer 10.0 or later
l Mozilla Firefox 25.0 or later
l Google Chrome 30.0 or later
l Apple Safari 6.0 or later
NOTE: J av as c ript mus t be enabled on all brow s er ty pes.
NOTE: A minimum PC dis play res olution of 1024 x 768 is required.
Login
Login is achieved by entering the IP address of the CTR, followed by a user
name and password.
l User names and passwords cannot be set using CTR Portal - these must
be set using CLI. See Changing IP Address and Local Management
Access on page 29.
o The default user name is root, and the default password for full

administrative permissions is admin123 .

o The default port for management access is GigE electrical port 1
(out-of-band management access is provided on port 1, VLAN 2).
l Users will be logged out automatically after a period of being logged in
without activity.
l While more than one user can log in at a time, it is best to restrict to
one user to avoid configuration conflict/confusion.
Pre-Login
Before login is attempted your PC must be set to have a LAN-compatible IP
address (your PC must operate as a device on the same LAN as the CTR), and an
RJ-45 (Cat5) cable must be connected from your PC Local Area Connection port
to the CTR management port, which is default switch-port 1. For setup
information see Switch Port Access on page 21.
Procedure:
With your PC connected to the CTR:
l Launch a web browser on your computer.
l Enter the CTR IP address in the address bar of the web page. For
example, if the IP address of the CTR is 192.168.1.1, then enter
192.168.1.1 in the address bar.
l The Login page appears.
l Enter the user name and password. Then, click Login.

l The CTR home-page Equipment screen displays. The screen below is
indicative of a new out-of-box CTR where:
o Plug-in modules have been physically installed and detected, but
not set/confirmed.
o All front panel user ports are available (not grayed-out), meaning
feature licenses have been installed (included on the SD card) to
enable electrical GigE ports 5 to 8, 4x SFP ports, and 16x E1/DS1
trib ports.

CTR Portal Help

For information on the operation of CTR Portal and its configuration, diagnostic,
and performance monitoring options, click on the Help tab in the top toolbar.
l This help is the online version of the CTR Portal Manual. This manual is
also available as a PDF document from Aviat Networks.
l The help topic displayed is context sensitive i.e. the topic presented
reflects the screen opened at the time of selection.
l Once opened the contents of the online help can be searched as an
online document.
l To regain the context sensitive capability, close the online help.

Health & Safety

Personnel involved with the installation, configuration, or servicing of CTR 8500
or CTR 8300 and their radio transceiver options must be aware of and comply
with the following health and safety requirements.
CAUTION: For comprehensive health and safety requirements, including those for installation of tower-
mounted devices, refer to the CTR 8500/8300 Installation Guide.
CAUTION: Local safety regulations must be used if mandatory. Safety instructions in this guide should
be used in addition to the local safety regulations. Should there be conflict between safety instructions stated
in this guide and those from local regulations, mandatory local norms shall prevail.
Caution Item Information

Installation and Ser- Installation and service must be carried out by authorized personnel who have the
vice Personnel technical training and experience necessary to be aware of any hazardous operations
during installation and service, and of measures to avoid any danger to themselves, to
any other personnel, and to the equipment.
Service personnel must have received adequate technical training on the equipment this
guide refers to.
Laser and Fiber Any fiber optic transmitters used are IEC60825-1 / 21CFR1040-1 Class I compliant and
Optic Cable Hazards present no danger to personnel in normal use. However, do not look into active
unterminated optical ports or fibers. If visual inspection is required ensure the
equipment is turned off or, if a fiber cable, disconnect the far end.
Protect/cover unconnected optical fiber connectors with dust caps.
Place all optical fiber cuttings in a suitable container for safe disposal. Bare fibers and
fiber scraps can easily penetrate the skin and eyes.
Protection from RF CTR radio products do not generate RF fields intense enough to cause RF burns.
Exposure However, when installing, servicing or inspecting an antenna always comply with the
Protection from RF Exposure guidelines detailed in The CTR 8500/8300 Installation
Guide.
Airflow Rack installations must be made so the airflow required for safe and correct operation of
Requirements the equipment is not compromised.
For CTR 8540 unobstructed air passage must be maintained to each side of the chassis,
which requires a minimum of 50 mm (2 inches) of side spacing to any rack panels, cable
bundles or similar. Unused front panel slots on the CTR 8540 must be fitted with a
blanking panel.
For CTR 8300 unobstructed air passage is required above the unit for ventilation
purposes. For more information refer to the CTR 8300 Getting Started Installation Guide,
or to the CTR 8500/8300 Installation Guide.
EMC CTR is a Class A product. In a domestic environment this product may cause radio
interference in which case the user may be required to take adequate measures. This
equipment is intended to be used exclusively in telecommunications centers.
ESD ESD (electrostatic discharge) can damage electronic components. Even if components
remain functional, ESD can cause latent damage that results in premature failure. Always
wear proper ESD grounding straps when changing or handling the plug-in cards and
avoid hand contact with the PCB back-plane and top-plane.
Indoor Unit and DC The ground for CTR indoor unit(s) must be connected directly to the dc supply system
Supply Grounding ground conductor, or to a bonding jumper from a grounding terminal bar, or bus to
which the dc supply system grounding is connected.

Mains Power Supply CTR dc power, IF, tributary, auxiliary and NMS cables are not to be routed with any AC
Routing mains power lines. They are also to be kept away from any power lines which cross them.
Maximum Ambient The maximum ambient temperature (Tmra) for CTR indoor units and outdoor units is
Temperature +55° C (131° F). To ensure correct operation and to maximize long term component
reliability, ambient temperatures must not be exceeded. Operational specification
compliance is not guaranteed for higher ambients.
The maximum ambient temperature applies to the immediate operating environment of
the CTR indoor unit, which, if installed in a rack, is the ambient within the rack.
DC Supply Voltage CTR power supply modules have the +ve pin on their d.c. power supply connector connected to chassis ground.
and Polarity They must be used with a -48 Vdc power supply which has a +ve ground; the power supply ground conductor is the
+ve supply to CTR.
WARNING: The input is reverse polarity protected against swapping the -
48Vdc and Earth feeds. The input is not protected against feeding +48Vdc to
the Ground pin and Earth to the -48Vdc pin. This will result in an internal
protection circuit failure. NEVER connect to a Negative- Earth Supply.
For IRU 600 variants that require a separate wide-mouth +/-21 to +/-56 Vdc power supply connection, both pins on its
power supply connector are isolated from chassis ground.
Connection to D.C. CAUTION: This equipment has a connection between the earthed conductor of the d.c. supply
Supply Ground circuit and the earthing conductor.
This equipment must be connected directly to the d.c. supply system grounding electrode conductor or to a bonding
jumper from a grounding terminal bar or bus to which the d.c. supply system grounding electrode is connected.
Switching or disconnecting devices must not be in the grounded circuit conductor between the d.c. source and the
point of connection of the grounding electrode conductor.
This equipment must be located in the same immediate area (such as, adjacent cabinets) as any other equipment
that has a connection between the grounded conductor of the same d.c. supply circuit and the grounding conductor,
and also the point of grounding of the d.c. system. The d.c. system shall not be grounded elsewhere.
The d.c. supply source must be located within the same premises as the equipment.
Main Power Supply An appropriate disconnect device for the -48 Vdc power supply unit must be provided as
Disconnect part of the building installation.
Restricted Access The CTR system must be installed in restricted access sites. The indoor unit and
associated power supply must be installed in restricted areas, such as dedicated
equipment rooms, closets, cabinets, or the like. Access to any tower and antenna location
must be restricted.
For USA:
In restricted access areas install the CTR system in accordance with articles 110-26 and
110-27 of the 2002 National Electrical Code ANSI/NFPA 70, or to any subsequent update
to this code for the relevant articles.

260-668254-001
WWW.AVIATNETWORKS.COM

CTR 8540 3.4.0 Getting Started Configuration - June2017

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

CTR 8540 3.4.0 Getting Started Configuration - June2017

Caricato da

Copyright:

Formati disponibili

CTR 8540

Getting Started Configuration

Copyright & Terms of Use

All rights reserved.

Aviat Networks makes no representation or warranties with respect to the

The following safety recommendations must be considered to avoid injuries to

All trademarks are the property of their respective owners.

260-668254-001 JULY 2017 III

Aviat NetworksTechnical Support

Global Support Hotline: +1 210 526 6345

Sales and Sales Support:

260-668254-001 JULY 2017 V

Corporate Headquarters International Headquarters

Phone: + 1 408 941 7100 Phone: + 65 6496 0900

Product Compliance Notes

Regulatory Information for 5.8 GHz Band

The following regulatory information applies to license-free operation on the 5.8

260-668254-001 JULY 2017 VII

International Use of 5.8 GHz

Networking Devices in Electric Power Substations

VIII AVIAT NETWORKS

Declaration of Conformity, Radio Equipment Directive

Aviat Networks tímto prohlašuje, že tento ODU 600/ODU 600sp

260-668254-001 JULY 2017 IX

Hierbij verklaart , Aviat Networks dat het toestel ODU 600/ODU

Full declarations of conformity are available at:

Country Availability Matrix

IT SHOULD BE NOTED THAT A LICENSE TO OPERATE THIS EQUIPMENT

260-668254-001 JULY 2017 XI

Copyright & Terms of Use iii

XII AVIAT NETWORKS

To Set Port MTU Size 41

260-668254-001 JULY 2017 XIII

CTR 8500/8300 Configuration

Guidance is provided on essential configuration procedures with example CLI

NOTE: U nles s otherw is e noted, data in this doc ument is applicable to

AVIAT NETWORKS JULY 2017 14

Microwave applications support scalable radio transport for conventional

CLI or CTR Portal

At SW release 3.4 for CTR 8540 and CTR 8300 :

15 JULY 2017 AVIAT NETWORKS

o Configure basic OSPF

AVIAT NETWORKS JULY 2017 16

CTR CLI Guide

Useful Tips and Shortcuts

17 JULY 2017 AVIAT NETWORKS

c t for configure terminal

Local Management Access

Either can be used for out-of-box access and configuration.

AVIAT NETWORKS JULY 2017 18

Serial Port Access

19 JULY 2017 AVIAT NETWORKS

n Where an external serial USB adapter is being used (CTR 8540 or

AVIAT NETWORKS JULY 2017 20

o Connection Type: Serial

Switch Port Access

Local CLI access to the management interface is enabled through a terminal

Setting a Compatible IP address (Windows 7):

21 JULY 2017 AVIAT NETWORKS

brings up Local Area Connection Status.

AVIAT NETWORKS JULY 2017 22

Adding and Changing Users and Passwords

23 JULY 2017 AVIAT NETWORKS