323-1851-101 (6500 R12.6 Datacomms Planning Procedures) Issue1 PDF

6500 Packet-Optical Platform
Data Communications Planning and

User Guide
Release 12.6
What’s inside...
New in this release and documentation roadmap
Data communications planning
Comms setting management procedures for D-Series and S-Series
Comms setting management procedures for T-Series
323-1851-101 - Standard Issue 1

September 2019
Copyright© 2017-2019 Ciena® Corporation. All rights reserved.
LEGAL NOTICES
THIS DOCUMENT CONTAINS CONFIDENTIAL AND TRADE SECRET INFORMATION OF CIENA
CORPORATION AND ITS RECEIPT OR POSSESSION DOES NOT CONVEY ANY RIGHTS TO REPRODUCE
OR DISCLOSE ITS CONTENTS, OR TO MANUFACTURE, USE, OR SELL ANYTHING THAT IT MAY DESCRIBE.
REPRODUCTION, DISCLOSURE, OR USE IN WHOLE OR IN PART WITHOUT THE SPECIFIC WRITTEN
AUTHORIZATION OF CIENA CORPORATION IS STRICTLY FORBIDDEN.
EVERY EFFORT HAS BEEN MADE TO ENSURE THAT THE INFORMATION IN THIS DOCUMENT IS
COMPLETE AND ACCURATE AT THE TIME OF PUBLISHING; HOWEVER, THE INFORMATION CONTAINED IN
THIS DOCUMENT IS SUBJECT TO CHANGE.
While the information in this document is believed to be accurate and reliable, except as otherwise expressly agreed
to in writing CIENA PROVIDES THIS DOCUMENT “AS IS” WITHOUT WARRANTY OR CONDITION OF ANY
KIND, EITHER EXPRESS OR IMPLIED. The information and/or products described in this document are subject to
change without notice. For the most up-to-date technical publications, visit www.ciena.com.
Copyright© 2017-2019 Ciena® Corporation. All Rights Reserved
Use or disclosure of data contained in this document is subject to the Legal Notices and restrictions in this section
and, unless governed by a valid license agreement signed between you and Ciena, the Licensing Agreement that
follows.
The material contained in this document is also protected by copyright laws of the United States of America and
other countries. It may not be reproduced or distributed in any form by any means, altered in any fashion, or stored
in a data base or retrieval system, without express written permission of the Ciena Corporation.
Security
Ciena® cannot be responsible for unauthorized use of equipment and will not make allowance or credit for
unauthorized use or access.
Contacting Ciena
Corporate Headquarters 410-694-5700 or 800-921-1144 www.ciena.com
Customer Technical Support/Warranty
In North America 1-800-CIENA-24 (243-6224)
410-865-4961
In Europe, Middle East, 800-CIENA-24-7 (800-2436-2247)
and Africa +44-207-012-5508
00 0800 77 454 (Slovenia)
In Asia-Pacific 800-CIENA-24-7 (800-2436-2247)
+81-3-6367-3989
+91-124-4340-600
120 11104 (Vietnam)
000 8004401369 (India)
In Caribbean and Latin 800-CIENA-24-7 (800-2436-2247)
America 1230-020-0845 (Chile)
009 800-2436-2247 (Colombia)
0800-77-454 (Mexico and Peru)
00 008000442510 (Panama)
Sales and General Information North America: 1-800-207-3714 E-mail: sales@ciena.com
International: +44 20 7012 5555
In North America 410-694-5700 or 800-207-3714 E-mail: sales@ciena.com
In Europe +44-207-012-5500 (UK) E-mail: sales@ciena.com
In Asia +81-3-3248-4680 (Japan) E-mail: sales@ciena.com
In India +91-22-42419600 E-mail: sales@ciena.com
In Latin America 011-5255-1719-0220 (Mexico City) E-mail: sales@ciena.com
Training E-mail: learning@ciena.com
6500 Packet-Optical Platform Data Communications Planning and User Guide

Release 12.6 323-1851-101 Standard Issue 1
Copyright© 2017-2019 Ciena® Corporation September 2019
For additional office locations and phone numbers, please visit the Ciena web site at www.ciena.com.
READ THIS LICENSE AGREEMENT (“LICENSE”) CAREFULLY BEFORE INSTALLING OR USING CIENA
SOFTWARE OR DOCUMENTATION. THIS LICENSE IS AN AGREEMENT BETWEEN YOU AND CIENA
COMMUNICATIONS, INC. (OR, AS APPLICABLE, SUCH OTHER CIENA CORPORATION AFFILIATE
LICENSOR) (“CIENA”) GOVERNING YOUR RIGHTS TO USE THE SOFTWARE. BY INSTALLING OR USING
THE SOFTWARE, YOU ACKNOWLEDGE THAT YOU HAVE READ THIS LICENSE AND AGREE TO BE BOUND
BY IT.
1. License Grant. Ciena may provide “Software” to you either (1) embedded within or running on a hardware
product or (2) as a standalone application, and Software includes upgrades acquired by you from Ciena or a Ciena
authorized reseller. Subject to these terms, and payment of all applicable License fees including any usage-based
fees, Ciena grants you, as end user, a non-exclusive, non-transferable, personal License to use the Software only in
object code form and only for its intended use as evidenced by the applicable product documentation. Unless the
context does not permit, Software also includes associated documentation.
2. Open Source and Third Party Licenses. Software excludes any open source or third-party programs supplied
by Ciena under a separate license, and you agree to be bound by the terms of any such license. If a separate
license is not provided, any open source and third party programs are considered “Software” and their use
governed by the terms of this License.
3. Title. You are granted no title or ownership rights in or to the Software. Unless specifically authorized by Ciena in
writing, you are not authorized to create any derivative works based upon the Software. Title to the Software,
including any copies or derivative works based thereon, and to all copyrights, patents, trade secrets and other
intellectual property rights in or to the Software, are and shall remain the property of Ciena and/or its licensors.
Ciena's licensors are third party beneficiaries of this License. Ciena reserves to itself and its licensors all rights in
the Software not expressly granted to you.
4. Confidentiality. The Software contains trade secrets of Ciena. Such trade secrets include, without limitation, the
design, structure and logic of individual Software programs, their interactions with other portions of the Software,
internal and external interfaces, and the programming techniques employed. The Software and related technical
and commercial information, and other information received in connection with the purchase and use of the
Software that a reasonable person would recognize as being confidential, are all confidential information of Ciena
(“Confidential Information”).
5. Obligations. You shall:
i) Hold the Software and Confidential Information in strict confidence for the benefit of Ciena using your best efforts
to protect the Software and Confidential Information from unauthorized disclosure or use, and treat the Software
and Confidential Information with the same degree of care as you do your own similar information, but no less than
reasonable care;
ii) Keep a current record of the location of each copy of the Software you make;
iii) Use the Software only in accordance with the authorized usage level;
iv) Preserve intact any copyright, trademark, logo, legend or other notice of ownership on any original or copies of
the Software, and affix to each copy of the Software you make, in the same form and location, a reproduction of the
copyright notices, trademarks, and all other proprietary legends and/or logos appearing on the original copy of the
Software delivered to you; and
v) Issue instructions to your authorized personnel to whom Software is disclosed, advising them of the confidential
nature of the Software and provide them with a summary of the requirements of this License.
6. Restrictions. You shall not:
i) Use the Software or Confidential Information a) for any purpose other than your own internal business purposes;
and b) other than as expressly permitted by this License;
ii) Allow anyone other than your authorized personnel who need to use the Software in connection with your rights
or obligations under this License to have access to the Software;
iii) Make any copies of the Software except such limited number of copies, in machine readable form only, as may
be reasonably necessary for execution in accordance with the authorized usage level or for archival purposes only;
iv) Make any modifications, enhancements, adaptations, derivative works, or translations to or of the Software;
v) Reverse engineer, disassemble, reverse translate, decompile, or in any other manner decode the Software;
vi) Make full or partial copies of the associated documentation or other printed or machine-readable matter provided
with the Software unless it was supplied by Ciena in a form intended for reproduction;

vii) Export or re-export the Software from the country in which it was received from Ciena or its authorized reseller
unless authorized by Ciena in writing; or
viii) Publish the results of any benchmark tests run on the Software.
7. Audit: Upon Ciena's reasonable request you shall permit Ciena to audit the use of the Software to ensure
compliance with this License.
8. U.S. Government Use. The Software is provided to the Government only with restricted rights and limited rights.
Use, duplication, or disclosure by the Government is subject to restrictions set forth in FAR Sections 52-227-14 and
52-227-19 or DFARS Section 52.227-7013(C)(1)(ii), as applicable. The Software and any accompanying technical
data (collectively “Materials”) are commercial within the meaning of applicable Federal acquisition regulations. The
Materials were developed fully at private expense. U.S. Government use of the Materials is restricted by this
License, and all other U.S. Government use is prohibited. In accordance with FAR 12.212 and DFAR Supplement
227.7202, the Software is commercial computer software and the use of the Software is further restricted by this
License.
9. Term of License. This License is effective until the applicable subscription period expires or the License is
terminated. You may terminate this License by giving written notice to Ciena. This License will terminate
immediately if (i) you breach any term or condition of this License or (ii) you become insolvent, cease to carry on
business in the ordinary course, have a receiver appointed, enter into liquidation or bankruptcy, or any analogous
process in your home country. Termination shall be without prejudice to any other rights or remedies Ciena may
have. Upon any termination of this License you shall destroy and erase all copies of the Software in your
possession or control, and forward written certification to Ciena that all such copies of Software have been
destroyed or erased. Your obligations to hold the Confidential Information in confidence, as provided in this License,
shall survive the termination of this License.
10. Compliance with laws. You agree to comply with all laws related to your installation and use of the Software.
Software is subject to U.S. export control laws, and may be subject to export or import regulations in other
countries. If Ciena authorizes you to import or export the Software in writing, you shall obtain all necessary licenses
or permits and comply with all applicable laws.
11. Limitation of Liability. ANY LIABILITY OF CIENA SHALL BE LIMITED IN THE AGGREGATE TO THE
AMOUNTS PAID BY YOU TO CIENA OR ITS AUTHORIZED RESELLER FOR THE SOFTWARE. THIS
LIMITATION APPLIES TO ALL CAUSES OF ACTION, INCLUDING WITHOUT LIMITATION BREACH OF
CONTRACT, BREACH OF WARRANTY, NEGLIGENCE, STRICT LIABILITY, MISREPRESENTATION AND OTHER
TORTS. THE LIMITATIONS OF LIABILITY DESCRIBED IN THIS SECTION ALSO APPLY TO ANY LICENSOR OF
CIENA. NEITHER CIENA NOR ANY OF ITS LICENSORS SHALL BE LIABLE FOR ANY INJURY, LOSS OR
DAMAGE, WHETHER INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL INCLUDING WITHOUT
LIMITATION ANY LOST PROFITS, CONTRACTS, DATA OR PROGRAMS, AND THE COST OF RECOVERING
SUCH DATA OR PROGRAMS, EVEN IF INFORMED OF THE POSSIBILITY OF SUCH DAMAGES IN ADVANCE.
12. General. Ciena may assign this License to an affiliate or to a purchaser of the intellectual property rights in the
Software. You shall not assign or transfer this License or any rights hereunder, and any attempt to do so will be void.
This License shall be governed by the laws of the State of New York without regard to conflict of laws provisions.
The U.N. Convention on Contracts for the International Sale of Goods shall not apply hereto. This License
constitutes the complete and exclusive agreement between the parties relating to the license for the Software and
supersedes all proposals, communications, purchase orders, and prior agreements, verbal or written, between the
parties. If any portion hereof is found to be void or unenforceable, the remaining provisions shall remain in full force
and effect.

v
Contents 0
New in this release and documentation roadmap xi
Data communications planning 1-1

Overview 1-1
Abbreviations used in this chapter 1-4
6500 network element (NE) data communication interfaces 1-7
LAN ports 1-9
Serial/RS-232 ports 1-15
Host Only Mode 1-15
Communication interfaces for accessing remote sites 1-15
6500 network element (NE) IPv4 addressing 1-37
Single Public IP 1-37
General IP address configuration rules 1-37
6500 network element (NE) IPv6 addressing 1-42
6500 network element (NE) internal routing protocols 1-45
Non-routing Mode (D-Series/S-Series shelf IPv4 only) 1-45
IISIS router (IPv4 only) 1-45
IISIS circuits (IPv4 only) 1-46
OSPFv2 router (for IPv4) 1-50
OSPFv2 circuits (for IPv4) 1-52
IP static route (D-Series/S-Series shelf IPv4 only) 1-56
Shelf IP redistribution (D-Series/S-Series shelf IPv4 only) 1-56
OSPFv3 (for IPv6) 1-59
Other protocols 1-59
Static route behavior for IPv6 and T-Series shelves 1-60
Equal-cost multi-path (ECMP) 1-60
6500 network element (NE) IPv4 supported protocols 1-61
Internal SNTP client/server 1-61
Secure HTTP 1-61
DHCP 1-62
DHCP relay agent for Zero Touch Provisioning (not applicable to T-Series) 1-63
FTP 1-63
Secure shell and SFTP 1-64
NETCONF 1-68
PPP 1-68
Telnet 1-69
OSI rlogin support 1-69
GRE 1-69

vi Contents
6500 network element (NE) IPv6 supported protocols and applications 1-71
6500 network element (NE) IPv6 comms feature support and GNE support 1-73
Data communications with shelf processor/control and timing module (CTM)
redundancy 1-74
Data communications support with shelf processor/CTM redundancy 1-74
COLAN alarms with SP/CTM redundancy 1-75
Craft communications 1-75
IPv4 external DCN connectivity 1-78
General DCN network design considerations 1-78
Best practices 1-78
Internal Communications Requirements 1-79
Address Resolution (AR) and Topology Resolution (TR) 1-79
Wavelength re-routing 1-80
DCN design for manual wavelength re-routing during failures 1-80
COLAN use for external DCN connectivity 1-82
Stretched spans 1-82
Stretched spans with SLDD/IISIS 1-83
IPv4 external DCN connectivity—Public IP address model 1-84
IPv4 external DCN connectivity—Private-IP address model 1-85
RADIUS gateway 1-87
Reverse Port NAT 1-87
TL1 Gateway 1-89
TIDc member shelf GNE support 1-91
IPv6 external DCN connectivity 1-96
GNE configurations 1-96
General DCN provisioning rules 1-97
IPv4 route redistribution and summarization 1-98
IPv6 route redistribution 1-100
Provisioning the DCN parameters 1-102
IPv6 planning and provisioning guidelines 1-105
TID consolidation (TIDc) 1-107
Comms within a consolidated node 1-108
Gateway Network Element (GNE) for a consolidated node 1-108
Consolidated node engineering guidelines 1-109
OSC for shelf interconnect (TIDc over OSC) 1-114
SONET/SDH, OTN, and Photonic Control Plane considerations 1-115
In-band communications for SONET/SDH Control Plane 1-115
In-band communications for OTN Control Plane 1-116
Photonic Control Plane data communications 1-116
PKT/OTN cross-connect circuit pack and CTM communications
considerations 1-119
Redundant OSPF configuration with multiple OSPF areas (Photonics only) 1-121
Opaque LSAs 1-130
OSPF Opaque Link State Advertisement parameter 1-130
DCN scalability and opaque LSAs 1-131
Opaque LSA engineering guidelines 1-131
Database Replication Service (DBRS) (D-Series/S-Series shelf IPv4 only) 1-132
OSPF Opaque LSA flooding Control (OOLFC, IPv4 only) 1-137
Site-Level Data Distribution (SLDD) 1-142
Service and Photonic layer interoperability (SPLI) 1-146

Contents vii
OSPF Multi-Area Adjacency (OMA, T-Series shelves only) 1-146

OSPF RFC 2328-compatible ABR (T-Series shelves only) 1-149
DCN design examples 1-153
DCN example 1—6500 GNE configuration - standalone Static GNE
configuration 1-156
DCN example 2—6500 GNE configuration - individual LAN drops from customer
DCN 1-164
DCN example 3—6500 GNE configuration - redundant OSPF GNE configuration
(each GNE in different OSPF area) 1-170
(GNEs in same OSPF area) 1-177
(using tunnels on DCN) 1-186
DCN example 6—6500 GNE configuration - standalone ARP GNE
configuration 1-195
DCN example 7—6500 GNE configuration - standalone ARP GNE with numbered
ILAN interface 1-202
DCN example 8—6500 GNE configuration - redundant ARP GNE
configuration 1-206
DCN example 9—6500 GNE configuration - redundant NAT GNE
configuration 1-215
DCN example 10—6500 GNE configuration - redundant NAT GNE configuration
with nodes running Packet services 1-223
DCN example 11—6500 GNE configuration - standalone Private-IP
addressing 1-230
DCN example 12—6500 GNE configuration - redundant Private-IP
addressing 1-236
DCN example 13—6500 GNE configuration - standalone Private-IP 1-243
DCN example 14—using single 6500 GNE with IISIS through 6500 network to
reach remote 6130 network elements 1-249
DCN example 15—using single 6500 GNE with IISIS to reach remote 6130
network elements in a SNCP/UPSR ring configuration with generic SDH/
SONET equipment 1-255
DCN example 16—management of OM 4000 through 6500 with IP only external
DCN 1-261
DCN example 17—management of 6500 through non-6500 network
element 1-267
DCN example 18—management of OM 3500 through 6500 1-272
DCN example 19—6500 MSPP and Photonics with OM 3500, using both OSPF
and IISIS 1-278
DCN example 20—management of OM 3500 through 6500 using GRE
tunnel 1-286
DCN example 21—auto-tunneling 1-291
DCN example 22—6500/HDX interworking using HDX DCC transparency and
multiple OSI areas 1-294
DCN example 23—using OSPF with two 6500 gateway network elements
connected to OSPF backbone with collocated CPL network elements 1-296
DCN example 24—Voice over IP (VoIP) orderwire 1-301
DCN example 25—DBRS use in a mesh network 1-305
DCN example 26—IPv6 DCN LAN drop to every shelf 1-308

viii Contents
DCN example 27—IPv6 statically routed GNE configuration 1-312

DCN example 28—IPv6 ND Proxy GNE configuration 1-316
DCN example 29—IPv6 redundant OSPF GNEs with IPv4 redundant OSPF
GNEs 1-320
6500 DCC interworking with IP-managed or OSI-managed network elements 1-323
6500 DCC interworking with IP-managed network elements 1-323
6500 DCC interworking with OSI-managed network elements 1-324
DCC protection 1-326
FTP/FTAM Bridge (file transfer translation device) 1-327
OSI data communications on the 6500 1-330
6500 DCC transparency 1-330
Interworking requirements 1-331
Limitations 1-331
6500 and CPL interworking 1-333
Internal DCN architectures 1-336
OSC communications in 6500/CPL line interworking configurations 1-339
6500 and 5100/5200 interworking 1-340
6500/5200 network with 6500 Proxy ARP GNE configuration 1-346
6500/5200 DCN engineering guidelines 1-348
Greenfield 6500/5200 network with 6500 GNE interworking 1-351
Example of 6500 commissioning information 1-352
Example of 5200 commissioning information 1-356
Migrate an existing 5200 network with Proxy ARP GNE to an integrated 5200/6500
network with 6500 Proxy ARP GNE 1-362
GNE migration procedure 1-366
6500 and Optical Long Haul 1600G interworking 1-379
Dial-up connectivity 1-383
Firewalls 1-384
Data communication security features and considerations 1-388
Provisionable port filtering 1-388
GNE port filtering 1-389
Craft reach-through security 1-389
RADIUS enhancements 1-390
TACACS+ 1-390
Debug port hardening 1-391
IP access control 1-392
Encryption OTR key management communications (does not apply to T-Series
shelves) 1-393
Non-segregated (Layer 3) solution 1-393
Segregated (Layer 2) solution 1-394
Provisioning encryption card communications 1-399
Guidelines and restrictions 1-401
Troubleshooting 1-402
DCN engineering guidelines 1-404
DCN design bandwidth requirements 1-407
DCN dimensioning example: 6500 MSPP with 6130 (IISIS routing) 1-412
IPv6 engineering guidelines 1-417
6500 service metrics 1-417
Migration from IPv4 to IPv6 1-420
Preserving comms data when saving and restoring provisioning data 1-421

Contents ix
IP networks, addressing, and masks 1-422

Dotted decimal notation for IPv4 addresses 1-423
Circuitless IP interface 1-425
IP routing protocols 1-426
ARP 1-426
TARP 1-427
Proxy ARP 1-427
OSPF 1-427
OSPF LSA generation 1-435
Router LSA 1-435
Network LSA 1-435
AS-External LSA 1-435
Network Summary LSAs and ASBR Summary LSAs 1-435
Route preference 1-436
Static and default routes 1-437
Subnetting and supernetting - IP addressing examples 1-438
Comms setting management procedures for D-Series and

S-Series 2-1
Overview 2-1
Site Manager navigation 2-4
Procedures and options for Comms Setting Management 2-5
Associated procedures 2-5
List of procedures
2-1 Retrieving communications settings 2-6
2-2 Editing the communications settings 2-9
2-3 Editing the IP Version 2-12
2-4 Editing the Site Level Data Distribution 2-14
2-5 Migrating an MD5 key 2-16
2-6 Adding a new entry in the communications settings 2-17
2-7 Deleting an entry in the communications settings 2-19
2-8 Displaying link local information 2-21
2-9 Performing a ping using Site Manager 2-22
2-10 Performing a trace route using Site Manager 2-24
2-11 Using the 6500 CLI ping and trace commands 2-25
Communications management parameters 2-31
Comms Setting Management options 2-31
Routers tab 2-35
Interfaces tab 2-67
Services tab 2-93
Comms setting management procedures for T-Series 3-1

Overview 3-1
Site Manager navigation 3-4
Procedures and options for Comms Setting Management 3-5
Associated procedures 3-5

x Contents
List of procedures
3-1 Retrieving communications settings 3-6
3-2 Editing the communications settings 3-7
3-3 Editing the Site Level Data Distribution 3-9
3-4 Migrating an MD5 key 3-11
3-5 Adding a new entry in the communications settings 3-12
3-6 Deleting an entry in the communications settings 3-14
3-7 Using the 6500 CLI ping and trace commands 3-16
Communications management parameters 3-21
Comms Setting Management options 3-21
Routers tab 3-24
Interfaces tab 3-49
Services tab 3-66

xi
New in this release and documentation

roadmap 0
This Technical Publication supports 6500 Packet-Optical Platform (6500)

Release 12.6 software and subsequent maintenance releases for
Release 12.6.
Issue 1
The following section details what’s new in 6500 Data Communications
Planning and User Guide, 323-1851-101, Standard Issue 1 for Release 12.6.
The following new/enhanced features are covered in this document:

• new circuit packs and modules
— PKT/OTN I/F 100G/2x40G 1xQSFP28/2xQSFP+ (NTK668AM and
NTK668CA), also known as 100G/2x40G PKT/OTN I/F
— OTN Flex MOTR 2xCFP2/20xSFP+/16xSFP (NTK532GA), also
known as 2xCFP2 OTN Flex MOTR
• new software features
— NETCONF support with IPv6
— OSPF neighbor retrieval
— Addition of ECDH-SHA2-NISTP256 and ECDH-SHA2-NISTP384 key
exchange methods
— IP Dead Gateway Detection (IPDGD) is no longer supported on 6500
— harmonization of datacomms features between D-Series/S-series and
T-series shelves (for example, Private-IP and IPv4 route redistribution
and summarization)
6500 technical publications

The following two roadmaps identify the technical publications that support the
6500 D-Series and S-Series and the technical publications that support the
6500 T-Series platform for Release 12.6.

xii New in this release and documentation roadmap
6500 D-Series and S-Series roadmap
Planning a Network Installing, Managing and Maintaining and Circuit Pack-Based

Commissioning and Provisioning Troubleshooting Documentation
Testing a Network a Network a Network
Documentation Installation - Administration Fault Management - Common Equipment

Roadmap General Information and Security Performance (323-1851-102.1)
(323-1851-090) (323-1851-201.0) (323-1851-301) Monitoring
(323-1851-520) Electrical
Planning - Installation - Configuration -
(323-1851-102.2)
Parts 1, 2, and 3 2-slot Shelves Provisioning &
(NTRN10EY) Operating Parts 1 & 2 Fault Management -
(323-1851-201.1) OC-n/STM-n
Data Comms (323-1851-310) Alarm Clearing
(323-1851-102.3)
Planning & User Guide Installation - 7-slot & Parts 1 and 2
(323-1851-101) 6500-7 packet-optical Configuration - (323-1851-543) WaveLogic Ai, Flex,
Shelves Protection Switching 100G+, 40G,
Ordering Information
(323-1851-201.2) (323-1851-315) Fault Management - OSIC ISS, & SLIC10
(323-1851-151)
Module (323-1851-102.4)
Manufacturing Installation - Configuration - Replacement
Discontinued Parts 14-slot Shelves Bandwidth & Data (323-1851-545)
(323-1851-155) (323-1851-201.3) Services Parts 1,2,3 Broadband/SMUX
(323-1851-320) OTN FLEX MOTR
NBI Fundamentals Installation - Fault Management - (323-1851-102.5)
(323-1851-165) 32-slot Shelves Configuration - SNMP
(323-1851-201.4) Control Plane (323-1851-740) Photonics
Latency
(323-1851-330) Equipment
Specifications Passive Chassis
(323-1851-170) Encryption and FIPS Fault Management - (323-1851-102.6)
(2150 & Photonics), Customer Visible
Pluggable Security Policy
Filters, and Modules Logs Data and Layer 2
Datasheets Overview and
(323-1851-201.5) (323-1851-840) (323-1851-102.7)
and Reference Procedures
(323-1851-180) (323-1851-340)
Licensing OTN I/F, PKT I/F, &
TL-1 Description (323-1851-210) MyCryptoTool PKT/OTN I/F
(323-1851-190) Certificate (323-1851-102.8)
Commissioning Management and
CLI Reference and Testing Quick Start
(323-1851-193) (323-1851-221) (323-1851-341)
Site Manager
Fundamentals
(323-1851-195)
SAOS-based Command Fault and MIB

Configuration Reference
Packet Services Reference Performance
(323-1851-630) (323-1851-690)
Documentation (323-1851-610) (323-1851-650)
Supporting WaveLogic Photonics 6500 Data 6500 Control Plane Submarine Networking
Documentation Coherent Select Application Guide Application Guide Application Guide
(323-1851-980) (NTRN15BA) (NTRN71AA) (NTRN72AA)
6500 Photonic Common 6500 - 5400 / 8700 Fiber Node Return 6500 AC Rectifier
Layer Guide Photonic Layer Interworking Solution Configuration (323-1851-900)
(NTRN15DA) Technical Publications (323-1851-160) (323-1851-985)

New in this release and documentation roadmap xiii
6500 T-Series roadmap
Planning a Network Installing, Managing and Maintaining and

Commissioning and Provisioning Troubleshooting
Testing a Network a Network a Network
T-Series Administration Fault Management -

Installation - Performance
Shelf Guide and Security
T-Series Shelves Monitoring
(323-1851-103) (323-1851-301)
(323-1851-201.6) (323-1851-520)
Data Communications Configuration -
Planning and Licensing Provisioning and Fault Management -
User Guide (323-1851-210) Operating Parts 1 & 2 Alarm Clearing
(323-1851-101) for T-Series Parts 1 and 2
T-Series Shelf (323-1851-311) for T-Series
Manufacturing Guide
(323-1851-544)
Discontinued Parts (323-1851-103) Configuration -
(323-1851-155) Protection Switching Fault Management -
(323-1851-315) Module
NBI Fundamentals
Replacement
(323-1851-165) Configuration - for T-Series
Bandwidth (323-1851-546)
TL-1 Description for T-Series
for T-Series (323-1851-321) Fault Management -
(323-1851-191) SNMP
CLI Reference Configuration - (323-1851-740)
for T-Series Control Plane
(323-1851-194) (323-1851-330) Fault Management -
Customer Visible
Site Manager Logs
Fundamentals (323-1851-840)
(323-1851-195)
SAOS-based Command Fault and MIB

Packet Services Configuration Reference
Reference Performance
Documentation (323-1851-630) (323-1851-690)
(323-1851-610) (323-1851-650)

xiv New in this release and documentation roadmap

1-1
Data communications planning 1-
Overview
This chapter provides an overview of 6500 Packet-Optical Platform (6500)
network data communications. Table 1-1 on page 1-2 lists the topics covered
in this chapter.
This chapter also provides information on typical Data Communications

Network (DCN) configurations/models, and examples and guidance on
provisioning different configurations.
For related procedure and parameter information for D-Series/S-Series

shelves, refer to Chapter 2, “Comms setting management procedures for
D-Series and S-Series”.
For related procedure and parameter information for T-Series shelves, refer to
Chapter 3, “Comms setting management procedures for T-Series”.
It is recommended to review Commissioning and Testing, 323-1851-221 and

the “Commissioning and testing” chapter of the 6500-T Series Shelves -
Guide, 323-1851-103, to learn more about data communications provisioning
during SLAT and provisioning of the 6500 network element.
For detailed datacomm guidelines for submarine applications, refer to the

Submarine Networking Application Guide, NTRN72AA.
6500 Release 11.0 introduced the T-Series shelf. 6500 Release 11.1
introduced IP version 6 (IPv6). Where certain features/functions/support of
IPv6 and 6500 T-Series diverge from IPv4 and D-Series/S-Series shelves,
these are noted. For more information on T-Series datacomms, refer to the
“Datacomms” chapter in the T-Series Packet-Optical Shelf - Guide,
323-1851-103.
Note: Unless otherwise specified, eMOTR in this document refers to

eMOTR (NTK536AA, NTK536AB, NTK536FA, NTK536FB) and eMOTR
Edge (NTK536BE) variants.

1-2 Data communications planning
Other product name short forms are used as follows:

• OM 3100, OM 3300, OM 3400, and OM 3500 for: Optical Metro 3100,
3300, 3400, and 3500
• OM 4000, OM 4100, OM 4150, and OM 4200 for: Optical Metro 4000,
4100, 4150, and 4200
• 5100 and 5200 for: 5100 and 5200 Advanced Services Platform
• 5400 for: 5410 Packet-Optical Platform and 5430 Packet-Optical Platform
• 61x0, 6110, 6130, 6150 for: 6110, 6130, and 6150 Multiservice Optical
Platform
• CPL for: Common Photonic Layer
• OneControl for: OneControl Unified Management System
Table 1-1
Topics in this document
Topic
“6500 network element (NE) data communication interfaces” on page 1-7
“6500 network element (NE) IPv4 addressing” on page 1-37
“6500 network element (NE) IPv6 addressing” on page 1-42
“6500 network element (NE) internal routing protocols” on page 1-45
“6500 network element (NE) IPv4 supported protocols” on page 1-61
“6500 network element (NE) IPv6 supported protocols and applications” on page 1-71
“Data communications with shelf processor/control and timing module (CTM) redundancy” on page 1-74
“IPv4 external DCN connectivity” on page 1-78
“IPv4 external DCN connectivity—Public IP address model” on page 1-84
“IPv4 external DCN connectivity—Private-IP address model” on page 1-85

“IPv6 external DCN connectivity” on page 1-96
“General DCN provisioning rules” on page 1-97
“TID consolidation (TIDc)” on page 1-107

“OSC for shelf interconnect (TIDc over OSC)” on page 1-114
“SONET/SDH, OTN, and Photonic Control Plane considerations” on page 1-115
“Redundant OSPF configuration with multiple OSPF areas (Photonics only)” on page 1-121
“Opaque LSAs” on page 1-130
“Site-Level Data Distribution (SLDD)” on page 1-142

Table 1-1
Topics in this document (continued)
Topic
“Service and Photonic layer interoperability (SPLI)” on page 1-146

“OSPF Multi-Area Adjacency (OMA, T-Series shelves only)” on page 1-146
“OSPF RFC 2328-compatible ABR (T-Series shelves only)” on page 1-149
“DCN design examples” on page 1-153

“6500 DCC interworking with IP-managed or OSI-managed network elements” on page 1-323
“FTP/FTAM Bridge (file transfer translation device)” on page 1-327
“OSI data communications on the 6500” on page 1-330
“6500 DCC transparency” on page 1-330
“6500 and CPL interworking” on page 1-333
“6500 and 5100/5200 interworking” on page 1-340
“6500 and Optical Long Haul 1600G interworking” on page 1-379
“Dial-up connectivity” on page 1-383
“Firewalls” on page 1-384
“Data communication security features and considerations” on page 1-388
“Encryption OTR key management communications (does not apply to T-Series shelves)” on
page 1-393
“Troubleshooting” on page 1-402
“DCN engineering guidelines” on page 1-404
“Migration from IPv4 to IPv6” on page 1-420
“Preserving comms data when saving and restoring provisioning data” on page 1-421
“Appendix A” on page 1-422

• “IP networks, addressing, and masks” on page 1-422
• “IP routing protocols” on page 1-426
• “Subnetting and supernetting - IP addressing examples” on page 1-438

Abbreviations used in this chapter

AFI Authority and Format Identifier
ARP Address resolution protocol
ASBR Autonomous system border router
CHAP Challenge-handshake authentication protocol
COLAN Central office local area network
DCC Data communications channel
DCN Data communications network

DHCP Dynamic host configuration protocol
DS1 Digital signal, level 1
DSM DS1 service module

DSO Dynamic shared object
DSP Domain specific part
FCS Frame check sequence

FTP File transfer protocol
GCC General communications channel
GRE Generic route encapsulation

HDLC High level data link control
ILAN Intershelf local area network
ID Identifier
IP Internet protocol
IPv4 Internet protocol version 4

IISIS Integrated ISIS
ISIS Intermediate system to intermediate system
LAN Local area network

LAPD Link access protocol on the D-channel
LLDCC Lower layer DCC
LSA Link state advertisement

MAC Media access control
MD5 Message digest 5 algorithm
MDIX Medium-dependent interface cross-over
MS Multiplex section
NAT Network Address Translation
NDP Neighbor discovery protocol (refers to Ciena topology feature),

Neighbor discovery (ND) proxy (refers to IPv6 protocol)
NET Network entity title
NSAP Network access service point

NSSA Not so stubby area
OAM Operations, administration, and maintenance
OCI Optical Channel Interface
OCLD Optical Channel and Laser Detector
OSC Optical service channel
OSI Open systems interconnect
OSPF Open shortest path first
OSPFv2 Open shortest path first, version 2 (refers to OSPF for IPv4)
OTM Optical transport module
OTN Optical transport network
OTU Optical channel transport unit
PAP Password authentication protocol
PC Personal computer
PPP Point-to-point protocol

PWSM Packet Wavelength Service Management
RS Regenerator section
SDH Synchronous digital hierarchy
SDH-J Synchronous digital hierarchy-Japan
SONET Synchronous optical network
SP Shelf processor

SSH Secure shell
SMUX Super multiplexer
SLDD Site Level Data Distribution
TARP TID address resolution protocol
TID Target identifier
ULDCC Upper layer DCC
UPC User privilege code
WSC Wayside channel

6500 network element (NE) data communication interfaces

Figure 1-1 on page 1-7 and Figure 1-2 on page 1-8 provide an overview of the
6500 OAM communications architecture.
Note that in certain Photonic configurations the inter-shelf local area network
(ILAN) ports can be used to connect to the Customer DCN.
Figure 1-1
6500 OAM data communication interfaces for D-Series/S-Series shelves
Local Craft Access Used for

temporary access
Craft RS232
(LAN 15 &16) DTE
10/100BT Modem
COLAN A
10/100BT
Carrier SONET SDCC/LDCC
Access SDH RS/MS Embedded
DCN 6500 G.709 GCC0/1 DCC/GCC/OSC
Network Element OSC Remote
COLAN X Access
10/100BT
PPP/LAPD
ILAN IN ILAN OUT

Used for external 10/100BT 10/100BT Wayside Used between
DCN access sites
Embedded Customer
DCN Site Traffi c
Interconnect
Used between
shelves at a site
Used for 10BT
customer traffic
between sites

Figure 1-2
6500 OAM communications architecture for T-Series shelves
Local Craft Access
Used for local

access at a site
Craft RS232
100/1000BT DTE
Modem
COLAN A Point-to-point
100/1000BT protocol
Carrier Embedded
Access COLAN X DCN Remote
DCN 100/1000BT 6500 Access
Network Element GCCx/OSC
Used between
Used for external Wayside sites
DCN access Used for 10/100BT
customer traffic
6 ILAN ports (10/100/1000BT) between sites
ILAN-IN1/2/3, ILAN-OUT1/2/3
Used between
shelves at a site Embedded DCN Site Customer Traffic
Interconnect

LAN ports
The 6500 shelf supports the following Ethernet ports:
• COLAN-X
— This is the port used to connect to the external DCN in most cases. In
dual SP/CTM configurations, it is automatically switched in hardware
to the active SP/CTM. In some cases, if available, this port can also be
used for inter-shelf communications, similar to an ILAN.
• COLAN-A
— This port can also be used to connect to the external DCN. However,
since it offers a reduced set of functionality versus COLAN-X,
COLAN-X is the preferred port for DCN connectivity. On 6500-7
packet-optical, 32-slot, and T-Series shelves, COLAN-A is
automatically switched in hardware to the active SP/CTM. On 14-slot
shelves, if the SP in slot 16 is active, the connection from COLAN-A is
tunneled through the SP in slot 15, and therefore requires the slot 15
SP to be present. Connectivity to COLAN-A can also be disrupted
temporarily on SP switch-overs or if SP-15 restarts.
— If some cases, if available, this port may also be used for inter-shelf
communications, similar to an ILAN.
• ILAN-IN and ILAN-OUT (for D-Series/S-Series shelves); and
ILAN-IN1/2/3 and ILAN-OUT1/2/3 (T-Series shelves)
— These ports are used to interconnect collocated shelves. In some
special cases, ILAN may also be used to connect to the external DCN.
In dual SP/CTM configurations, ILANs are automatically switched in
hardware to the active SP/CTM.
ILAN-IN is not supported on the 2-slot shelf (NTK503MAE5 and
NTK503NAE5 variants), and is not supported on the 2-slot Type 2 shelf when
equipped with an SPAP circuit pack (NTK555LA). Use COLAN-X in its place.
— Throughout this document, where references to ILAN-IN/OUT exist,
note that they apply equally to ILAN-IN1/IN2/IN3/OUT1/OUT2/OUT3
on T-Series shelves.
• Craft port
— Located on each SP/CTM faceplate, this port provides access to the
local shelf, and if craft reach-through is provisioned, to other shelves
in the network. Although the craft port is functional on both active and
inactive SP/CTM, the craft port on the inactive SP/CTM is for Ciena
debug access only.
COLAN-B is not supported on any shelf type.
Table 1-2 on page 1-10 summarizes the LAN ports supported on the 6500.

Table 1-2
Supported LAN and physical interface ports
LAN port Shelf
2-slot 7-slot 6500-7 14-slot 32-slot T-Series

packet-
optical
10/100BT, half-/full-duplex 100/1000BT,
full-duplex
(except
Ethernet
Wayside port)
COLAN-X (MDI) Supported Supported Supported Supported Supported Supported
COLAN-A (MDI) Supported Supported Supported Supported Supported Supported

Note 1 Note 2
COLAN-B (MDI) Not Not applicable Not Not Not Not

applicable applicable supported applicable applicable
ILAN-IN (MDI) Supported Supported Supported Supported Supported Not

Note 1 applicable
and
Note 3
• ILAN-1N1 (MDI) Not Not applicable Not Not Not Supported

• ILAN-1N2 (MDI) applicable applicable applicable applicable
• ILAN-1N3 (MDI)
ILAN-OUT (MDI) Supported Supported Supported Supported Supported Not

applicable
• ILAN-OUT1 (MDI) Not Not applicable Not Not Not Supported

• ILAN-OUT2 (MDI) applicable applicable applicable applicable
• ILAN-OUT3 (MDI)

Table 1-2
Supported LAN and physical interface ports (continued)
LAN port Shelf

packet-
optical
full-duplex
(except
Ethernet
Wayside port)
DTE serial port Supported • Not Supported Supported Supported Supported as

(RS232) as supported as as as SERIAL-X
SERIAL-X on 7-slot SERIAL-X SERIAL-X SERIAL-X
Note 1 optical shelf with
(NTK503PA) NTK505JB
• Supported access
as panel
SERIAL-X
on 7-slot
optical
Type 2 shelf
(NTK503KA)
Note 1
Shelf Supported Supported as • Supported • Supported • Supported • Supported

processor/CTM as LAN-15 LAN-15 as LAN-15 as as as LAN-41
craft port (MDI-X) (slot 15) (slot 15) (slot 15) LAN-15 LAN-41 (slot 41)
• Supported (slot 15) (slot 41) • Supported
as LAN-16 • Supported • Supported as LAN-42
(slot 16) as as (slot 42)
LAN-16 LAN-42
(slot 16) (slot 42)
USB Not Supported Supported Supported Supported Not

applicable Note 4 Note 5 Note 5 Note 5 supported
Ethernet Wayside Supported Supported on Supported Supported Supported Supported on
port (MDI-X) on ESAM SRA, SAM, on SRA, on SRA, on SRA, RLA modules
Note 6 and ESAM, SAM, SAM, SAM, as applicable
SPAP-2 2xOSC, and ESAM, and ESAM, and ESAM, and Note 7
w/2xOSC SPAP-2 2xOSC 2xOSC 2xOSC
circuit w/2xOSC circuit circuit circuit
packs as circuit packs packs as packs as packs as
applicable as applicable applicable applicable applicable
Note 1

Table 1-2
Supported LAN and physical interface ports (continued)
LAN port Shelf

packet-
optical
full-duplex
(except
Ethernet
Wayside port)
Note 1: Only supported on 2-slot Type 2 shelf if an SPAP-2 w/2xOSC is equipped in slot 15.
Note 2: Supported as a virtual interface for shelf processor in slot 16 if the respective shelf processor
in slot 15 is available to perform tunneling.
Note 3: On the 2-slot shelf (NTK503MAE5 and NTK503NAE5 variants), where ILAN-IN is not
supported, COLAN-X can be used in place of ILAN-IN.
Note 4: Supported in the 7 -slot shelf NTK503PAE5 variant when equipped with an SP-2 shelf
processor circuit pack. Not supported in the 7-slot optical Type 2 shelf (NTK503KA).
Note 5: Supported when the shelf is equipped with an SP-2 circuit pack.
Note 6: Use of the 100BT setting on RLA modules (T-Series shelf only), SRA, SAM, ESAM, 2xOSC,
and SPAP-2 w/2xOSC circuit packs requires use of traffic policing to limit the rate to 40 Mb/s. Refer to
“Wayside channel (WSC) interface” on page 1-31.
Note 7: The Ethernet Wayside port on T-Series shelves support 10/100BT, half-/full-duplex.
The 10/100BT ports support both Ethernet 2 (IP) and IEEE Std 802.3 (OSI).
Each LAN port is configurable as half-duplex 10 Mbit/s, half-duplex 100 Mbit/s,
full-duplex 10 Mbit/s, full-duplex 100 Mbit/s, or Automatic. If you set the
configuration to Automatic, auto-negotiation is enabled. Auto-negotiation
automatically senses the speed (10BT/100BT) and mode (half-/full-duplex)
settings of the link.
The 100/1000BT ports support both Ethernet 2 (IP) and IEEE Std 802.3 (OSI).
Each LAN port is configurable as full-duplex 100 Mbit/s, full-duplex 1000
Mbit/s, or Automatic. If you set the configuration to Automatic,
auto-negotiation is enabled. Auto-negotiation automatically senses the speed
(100BT/1000BT) settings of the link.
If the configuration is set to Automatic, the LAN ports, including Wayside ports,
automatically detect the correct MDI/MDI-X setting to use, so either straight or
crossover cables can be used. If the configuration is not set to Automatic, then
use a straight cable to connect MDI to MDI-X interface types, and a crossover
cable to connect MDI to MDI and MDI-X to MDI-X interface types.

Ensure the LAN port configuration on each side of a point to point

configuration is the same (AUTO-AUTO, FD100BT-FD100BT).
LAN implementation rules

You must observe the following rules when you implement the LAN:
• By default, only the craft LAN port (Craft port) is configured with the
configuration set to Automatic.
• For gateway network elements, at least one COLAN or ILAN port must be
configured for connection to the customer DCN.
• Redundant NAT, proxy ARP GNE, and single-public-IP configurations are
only supported on COLAN-X.
• In other GNE configurations, such as private-IP and OSPF, COLAN-X and
COLAN-A can be used together for redundant access to/from the external
DCN, but must be in different subnets. If only one interface is used, it is
recommended to use COLAN-X.
• In the Private-IP GNE configuration, if COLAN-A is numbered, it is
controlled by the Private-IP functionality and therefore not available for
other uses. Either COLAN-X or COLAN-A, but not both, can be active at
any given time. However, if COLAN-A is unnumbered, it is not controlled
by Private-IP and is available for other uses, such as for internal
connections (for example, to transponder shelves).
Note: COLAN-A is not supported as a Private-IP interface on T-Series,
and therefore should not be connected to the external DCN. However, it
can be used for internal (6500-to-6500) connectivity.
• It is recommended that the ILAN ports are used for connecting to

collocated 6500 network elements, OSI devices, or an external IISIS.
When using the ILAN to connect to collocated network elements or OSI
devices:
— ensure that the port is enabled and the configuration is correctly set
(matches the device you are connecting to). Ensure that the correct
type of Ethernet cable is used.
— if connecting to another 6500 network element and IISIS runs on the
ILAN interface, set the IPv4 address of the ILAN port to 0.0.0.0
(netmask 255.255.255.255). IISIS does not apply to IPv6.
An IP address of 0.0.0.0 indicates the interface is using an
unnumbered IP address and borrows the SHELF IP address for
communications. If no IP address is assigned to the port only OSI
communications are available on the port.
— if connecting to another 6500 network element and OSPF runs on the
ILAN interface, the ILAN port can be numbered or un-numbered
(preferred). For un-numbered, set the IPv4 address of the ILAN port to
0.0.0.0 (netmask 255.255.255.255) or IPv6 address to ::/128.

— If connecting to a CPL network element, ILAN ports must be running

OSPF.
— if connecting to a CPL network element, use ILAN ports at each
co-located site.
— The CPL un-numbered configuration requires a next hop IP address.
— 6500 ILAN carrying OSPF can be connected to CPL ILAN using
numbered (CPL releases below 3.1) or unnumbered (preferred for
CPL3.1 and higher) ILAN ports. For connections to CPL3.1 or higher
set the IP addresses as follows:
– for 6500, the IP on ILAN should be set to 0.0.0.0 with netmask
255.255.255.255
– for CPL Release 3.1 and 3.2, the IP on the ILAN should be set to
0.0.0.0 with netmask 0.0.0.0 and next hop address equal to the
shelf-IP of the far-end shelf
— if there are more than two NEs to be interconnected, use daisy chain.
— if connecting to an OM 3000 or OM 4000 network element or an OSI
managed device using a ILAN or COLAN (-X or -A) port, do not set an
IP address for the port. An IISIS circuit can be provisioned on a port
without an IP address provisioned if the NPS secure http
— Override parameter of the IISIS circuit is set to LAN_OSIONLY.
— if internal routing is IISIS, provision an IISIS circuit on the ILAN port
with neighbor protocol supported override parameter set to Off.
— if internal routing is OSPF, provision an OSPF circuit on the ILAN port.
Systems equipped with Photonics equipment or systems using TID
consolidation must use OSPF as the internal routing protocol.
— un-numbered links (OSPF, IISIS and OSI) must be point-to-point
connections.
• Do not add a LAN port unless the port will be connected, otherwise LAN
alarms will be raised.
• IISIS on the ILAN ports can be used to connect a 6500 network element
to multiple collocated 6500 network elements and OSI devices through an
Ethernet hub or switch, provided the ILAN ports do not have an IP
assigned and the IISIS circuits have their NPS Override parameter set to
LAN_OSIONLY. Despite having this option, the ring over point-to-point
connections configuration is recommended. This does not apply to
unnumbered ILAN ports.

• When using OSPF on the ILAN ports to connect to collocated 6500

network elements or collocated CPL network elements, a ring connection
of the ILAN ports is recommended. If only two network elements are
collocated, a ring connection between the ILAN ports can be used for
redundancy but the OSPF circuit costs for each connection must be
different.
• The CPL un-numbered configuration requires a next hop IP address.
• Do not add IISIS circuits or OSPF circuits to LAN ports provisioned with
the non-routing mode set to On.
Serial/RS-232 ports
The 6500 shelf supports the following RS-232 ports:
• an RS-232 DTE port located on the access panel intended for a
permanent modem connection. The DB9 RS-232 DTE port is a switched
interface. This interface is switched to the active SP/CTM automatically by
hardware. The 2-slot, 7-slot, and 6500-7 packet-optical shelves do not
have an DB9 RS-232 DTE access port.
ATTENTION
The 6500 32-slot shelf is equipped with two USB faceplate ports on the SP
instead of the DB9 RS-232 DCE port.
The serial/RS-232 parameters cannot be edited and are set to the default
settings.
It is recommended that the serial port on a PC connected to the 6500 is set to

either 9600 or 19200.
Host Only Mode

The Host Only Mode option is displayed in Site Manager, but is not supported
in this release.
Communication interfaces for accessing remote sites

Possible interfaces include:
• Optical Service Channel (OSC) interface
• DCC/GCC interface (Data Communication Channel/General
Communication Channel interface)
• Wayside channel (WSC) interface
Optical Service Channel (OSC) interface

Communication between 6500 adjacent sites can be realized using the OSC.
A transmit and receive fiber pair provides a bidirectional channel between
sites. This channel provides point-to-point data communications using

Ethernet over SONET/SDH (EOS) mapping protocols. The OSC wavelength

(1510 nm) falls outside the DWDM plan. It is sourced and terminated at each
node thus allowing OSC communication between all elements on the line.
The OSC and the wayside channel (WSC) have a combined total bandwidth
of 100 Mb/s in each direction. Therefore, WSC traffic reduces the available
bandwidth on the OSC up to certain limits (refer to “Wayside channel (WSC)
interface” on page 1-31 for details). If the wayside channel is used in a
particular network deployment, this should be taken into account when
engineering the number of devices subtended over OSC.
OSC implementation rules

You must observe the following rules when you implement the OSC:
• It is recommended that the OSC be provisioned and functional.
• OSPF runs on the OSC, IISIS is not supported on the OSC.
• When GCC is used on a system that also has OSC, GCC should typically
be configured to use OSPF (the default is IISIS). However, in some cases
it can be advantageous to enable IISIS over GCC for converged MSPP
and Photonic services.
• The Auto OSC/OSPF Provisioning parameter in the Site Manager Node
information application System sub-tab (or ED-SYS TL-1 command and
the OSCMODE parameter) defines whether the OSC will be provisioned
or not when the SFP on the RLA module (T-Series shelf only), SRA, SAM,
ESAM, 2xOSC, and SPAP-2 w/2xOSC circuit pack is provisioned. By
default, when the OSC autoprovisions, the associated OSPF circuit and
router also autoprovisions. Note that the OSC OSPF circuit and OSPF
router (if not existing already) will autoprovision only if the SHELF IP has
been provisioned on the NE.
• If an OSPF circuit is auto-created, the circuit defaults to area 0.0.0.0.
Thus, if OSC is required to be provisioned in an area other than the
backbone area (0.0.0.0), OSC circuit auto-creation must be disabled
(using the TL-1 ED-SYS command by setting OSCMODE to DISABLED,
or from the Site Manager, Node Information->System tab, by setting Auto
OSC/OSPF provisioning to disabled). The required areas can be manually
provisioned for the OSC.
DCC/GCC interface
Communications between 6500 adjacent sites can be realized using
OCn/STMn section/regenerator section (RS) DCC or the line/multiplex section
(MS) DCC available on each OCn/STMn optical port. Communications
between 6500 adjacent sites can also be supported using the general
communication channel 0 (GCC0) and the general communication channel 1
(GCC1) interface available on each OTM1 (GCC0 only), OTM2, OTM3, OTM4,
or OTMC2 optical port (except on the 10G AM1/AM2 OTM2 optical port).

Each DCC interface can support either PPP (IP-based DCC datalink layer),
LAPD (OSI-based DCC datalink layer), or Transparent (HDLC-based DCC
datalink layer). Each GCC interface can support only PPP. The GCC interface
on the SuperMux (GFP-T and GFP-F variants) and 20G (2+8)xOC-n/STM-n
LO circuit packs also supports LAPD.
The DCC Transparency only supports transparency of HDLC based datalink

protocols. Any non-HDLC formatted packets will be discarded. LAPD and PPP
are both HDLC based protocols.
DCC transparency is not supported on the 40G and 100G interface circuit
packs. Transparency is not supported on GCC interfaces.
For more information about DCC Transparency, see “6500 DCC transparency”
on page 1-330.
Facilities on which the SONET/SDH Control Plane is enabled are required to

have the Line/Multiplex Section (MS) DCC allocated for Control Plane
communications. Refer to “Lower layer DCC implementation rules” on
page 1-17, and to the Control Plane Application Guide, NTRN71AA, for more
information.
Facilities on which the OTN Control Plane is enabled are required to have the
GCC1 or GCC2 allocated for Control Plane communications. If GCC1 is used
by the OTN Control Plane, then GCC2 cannot be used for OAM
communications. If OAM communications is required, then GCC0 or GCC1
should be used for OAM and GCC2 should be used for the OTN Control Plane.
Refer to “Lower layer GCC implementation rules” on page 1-21, and to the
Control Plane Application Guide, NTRN71AA, for more information.
ATTENTION
When using OSPF on the DCC/GCC channels, IS-to-IS Hello (IIH) topology
auto-discovery does not function across the DCC/GCC channels. IIH-based
auto-discovery does function across DCC/GCC channels when using IISIS.
Lower layer DCC implementation rules

You must observe the following rules when you implement the lower layer
DCC:
• For each OCn/STMn optical port, the DCC can be configured as
section/RS and line/MS. SDCC and LDCC can coexist on the same port
for all circuit packs, except the MXC circuit pack.
• You can add SDCC/LDCC data communication channel(s) against
OC-n/STM-n facilities using the Site Manager Configuration > Comms
Setting Management application.

• Each OCn/STMn optical port can support a protocol of PPP, LAPD, or

Transparent. The default is PPP.
— When using DCC to connect to a 6500 (or any network element that
supports IP based DCC datalink layer), select PPP as the protocol.
— When using DCC to connect to an OSI-based DCC datalink layer,
select LAPD as the protocol.
— When using DCC between 6500 network elements that support both
IISIS and OSPF, it is recommended that IISIS is used as it supports
additional functionality (for example, GRE auto-tunnels).
• If an OC-n/STM-n optical port is configured for LAPD, the frame size can
be configured between 512 and 1492. The default is 1304. The LAPD
frame size must be set to the same setting at both ends of the optical link
otherwise communication problems can occur.
• The HDLC FCS mode is provisionable to either 16 bit or 32 bit when the
DCC Carrier is provisioned as Section or Line, and the Protocol is
provisioned as PPP or Transparent.
• After a new DCC channel has been provisioned, an IISIS circuit or OSPF
circuit must be added for this port. OSPF circuits are only supported on
PPP ports. You cannot provision an IISIS circuit and an OSPF circuit on
the same DCC channel.
• When an OC-n/STM-n facility is placed out-of-service (OOS), the
corresponding SDCC comms channel remains up, with the exception of
40G XCIF circuit pack. The 40G XCIF circuit pack behavior is different
because the OC-192/STM-64 facilities are virtual ports, not physical ones.
• You can add an IP static route for a port after provisioning a new DCC
channel without an IISIS circuit or OSPF circuit provisioned for the port.
You must delete the associated IP static route before deleting the DCC
channel.
• You must delete the associated IISIS circuit or OSPF circuit before
deleting the DCC channel.
• For the 40G XCIF circuit pack, you can add GCC1 data communication
channel against OTM3 facilities or SDCC/LDCC data communication
channel(s) against OC-192/STM-64 facilities.
• One section/RS DCC per optical port and up to two line/MS DCC per
OC-n/STM-n optical circuit pack are supported. For SuperMux (GFP-T
and GFP-F variants) circuit packs, GCC0 and section/RS is supported on
each OCn/STMn line facility and line/MS DCC is supported on the
OCn/STMn client and line facilities with the following rule: maximum two
line/MS DCC or one line/MS DCC and one GCC (GCC0/1 on OTM2
facility, line/MS DCC available on any Line/Client facility).

• For the 16xOC-n/STM-n circuit pack the following applies:

— Section/RS DCC is provisionable on all 16 ports (default is off)
— Line/MS DCC is provisionable on all 16 ports (only 2 Line/MS DCC are
supported on the 5G variant of the circuit pack) (default is off)
• For 20G (2+8)xOC-n/STM-n and 20G (2+8)xOC-n/STM-n OTN circuit
packs, the following applies:
— Section/RS DCC and Line/MS DCC are provisionable on all optical
ports
— Maximum of 8 x Section/RS DCC and 8 x Line/MS DCC are available
on the OC-n/STM-n facilities
— Maximum of 2 x GCC0, and 2 x GCC1 and 2 x GCC2 are available on
the OTM2 facilities (NTK521DAE5 and NTK522DAE5 variants only)
Refer to Table 1-3 on page 1-21 to determine the available facilities
and the maximum DCC and/or GCC channels available.
ATTENTION
Ports 1 and 3 and ports 2 and 7 share the same Section/RS DCC
and Line/MS DCC, as both ports cannot be provisioned at the same
time.
• For 8xOC-n/STM-n circuit packs, Section/RS DCC and Line/MS DCC are
supported on all eight ports.
For additional details, refer to Table 2-34 on page 2-85 and Table 3-24 on
page 3-59.
Facilities on which the SONET/SDH Control Plane is enabled are required to

have the Line/Multiplex Section (MS) DCC allocated for Control Plane
communications. The L/MSDCC channel requires the following parameters:
• Carrier = Line (SONET)/Multiplex Section (SDH)
• Network domain = SONETCP
• Protocol = LAPD
• L2 frame size = 9000
More information can be found in the Control Plane Application Guide,

NTRN71AA.

The supported options for the different network element types are as follows:
• 6500
— Supported Carriers: section/RS, line/MS
— L2 frame size: 512 to 1492 (default 1304) (for LAPD only)
— L2 side role: automatic (default)
• OM 4000
The DCC supported is dependent on the circuit pack type, refer to the
OM 4000 documentation for details.
— L2 frame size: 512 (default, not configurable)
— L2 side role: automatic (default, not configurable)
• OM 3000
— L2 frame size: 512 to 1492 (default 1304)
— L2 side role: network, user, or automatic
• Optical Cross Connect HDX/HDXc
Optical Cross Connect HDX/HDXs documentation for details.
— L2 side role: network, user, or automatic (default)
• Optical Cross Connect DX
Optical Cross Connect DX documentation for details.
• 6110 (supported using IISIS/OSPF routing)
— Two DCCs needs to be provisioned (working and protection), one per
optical port: section/RS, line/MS, or off (default)
— L2 frame size (PPP protocol): MTU size 240 to 1518 (default 1510 - IP
level, 1518 - PPP level)
— L2 protocol PPP: Standard PPP, RFC1661/PPP (default), or HDLC
Framing
— L2 side role: automatic (default, cannot be changed)

Lower layer GCC implementation rules

Table 1-3 on page 1-21 lists the GCC0 and GCC1 support for 6500 circuit
packs.
Table 1-3
GCC support
Circuit pack GCC0 supported GCC1 supported GCC1 GCC2

interface(s) interface(s) supported supported
(MCN) (MCN) interface(s) interface(s)
(SCN) (SCN, except
where noted)
10G OTM2 port 1 facility OTM mapping client

OC-192/STM-64 port 2
WT
10GEL WT OTM2 port 1 facility OTM mapping client
port 2
10G OTU2 WT OTM2 port 1 facility
10G OTR • OTM2 port 1 facility OTM2 mapping client

• OTM port 2 facility port 2
(client)
2x10G OTR • OTM2 line ports OTM2 mapping client

(1 and 3) ports (2 and 4)
• OTM2 client ports
(2 and 4)
4x10G OTR OTM2 line ports OTM2 mapping client

(NTK530QA (5 to 8) ports (1 to 4)
variant)
4x10G OTR OTM2 line ports OTM2 mapping client Note 1
(NTK530QE (5 to 8) ports (1 to 4)
variant)
4x10G OTR • OTM2 line ports OTM2 mapping client

(NTK530QM and (5 to 8) ports (1 to 4)
NTK530QP • OTM2 client ports
variant) (1 to 4)
10G OTSC • OTM2 port 1 facility OTM2 mapping client

• OTM2 port 2 port 2
client facility

Table 1-3
GCC support (continued)

(SCN) (SCN, except
where noted)
SuperMux with OTM2 port 1 facility OTM2 port 1 facility

integrated DWDM Note 2 Note 2
SuperMux with OTM2 port 1 facility OTM2 port 1 facility

XFP
2.5G MOTR OTM2 port 1 facility OTM1 mapping client

(NTK530NA ports 2 to 5
variant)
2.5G MOTR • OTM2 port 1 facility OTM1 mapping client
(NTK530NC • OTM1 ports 2 to 5 ports 2 to 5
variant) client facilities
FLEX MOTR OTM2 line OTM2 line (ports 1
(ports 1 and 2) and 2)
8xOTN Flex OTM1 line facility OTM1 line facility

MOTR
(1+8)xOTN Flex OTM1 and OTM2 line OTM1 and OTM2 line
MOTR facilities facilities
2xCFP2 OTN • OTU2/OTU2E for • ODUTTP/ODUCTP

Flex MOTR client ports 1 to 20 with facilities for client ports
OTUTTP facility 1 to 20
• OTU4/ODU4 for line • ODUTTP facility for line
ports 41 and 42 with ports 41 and 42
OTUTTP facility
• (2+8)xOC-n/ OTM2 line port 1 and 2 OTM2 mapping line port
STM-n 1 and 2
STS-1/VC-3
OTN 20G
• (2+8)xOC-n/
STM-n LO 20G

Table 1-3

(SCN) (SCN, except
where noted)
eMOTR • OTUTTP facility on • ODUTTP facility on

ports 9 to 12 ports 9 to 12
• When mated with 40G • ODU3-rate ODUTTP
OCLD or 40G facility on backplane
wavelength-selective ports 100 and 200
40G OCLD, supported • When mated with 40G
on the OCLD OTUTTP OCLD or 40G
facility wavelength-selective
40G OCLD, supported
on the eMOTR ODU3
ODUTTP facility
eMOTR Edge • OTUTTP facility on • ODUTTP facility on

ports 11 to 14 ports 11 to 14
• When mated with 40G • ODU3-rate ODUTTP
OCLD or 40G facility on backplane
wavelength-selective ports 100 and 200
40G OCLD, supported • When mated with 40G
on the OCLD OTUTTP OCLD or 40G
facility wavelength-selective
40G OCLD, supported
on the eMOTR ODU3
ODUTTP facility
• 40G OCLD OTM3 line port 1

C-Band
• 40G OCLD
L-Band
40G OCLD - OTM3 line port 1

Wavelength
Selective
40G UOCLD OTM3 line port 1
40G OCI OTM3 mapping port 100

40G+ CFP OCI OTM3 client port 1 OTM3 mapping port 100
40/43G OCI OTM3 client port 1 OTM3 mapping port 100

Table 1-3

(SCN) (SCN, except
where noted)
40G MUX OCI OTM3 mapping port 100
40G XCIF OTM3 mapping port 100
40G OTN XCIF OTUTTP associated If used for MCN, FTTP facility FTTP facility
with the mated pair supported on ODUTTP
(40G OCLD or or ODUCTP facility
40G OCI)
100G OCLD OTM4 line port 1

• 100G WL3 OTM4 line port 1
OCLD
• 100G WL3e
OCLD
• Flex2 OTM4 line port 1
WL3/WL3e
OCLD
• Flex2 WL3e
OCLD
Flex3 WL3e • OTM4 line port 1
OCLD • OTMC2 port 1
FLex4 WL3e • OTM4 line port 1

OCLD • OTMC2 port 1
100GE OCI OTM4 mapping facility
100G OCI OTM4 client facility OTM4 mapping facility
10x10GE MUX OTM4 mapping port 100

10x10G MUX OTM4 mapping port 100
100G (2xQSFP+/ OTM3 client ports 3 OTM4 mapping port 100

2xSFP+) MUX and 4

Table 1-3

(SCN) (SCN, except
where noted)
200G (2x100G/ OTM4 client ports 1 • OTM3 facilities (ports 1

5x40G) MUX and 2 and 2, 4 and 5)
• OTM4 client mapping
facilities (ports 1 and 2)
or muxing facilities
(ports 100 and 101)
100G WL3e OTR • OTM4 line port 1 OTM4 mapping layer

• OTM4 client port 2 associated with
ETH100G client port 2
100G WL3n OTR • OTM4 line port 1 OTM4 mapping layer

• OTM4 client port 2 associated with
ETH100G client port 2
100G WL3n • OTM4 line port 1 • OTM4 line facility port 1

MOTR • OTM2 client ports 2 • OTM3 mapping facility
to 11 ports 104 and 108
• WLAi MOTR • OTUTTP facility • ODU4 ODUCTP facility

• WLAi MOTR • OTU4 OTUTTP facility ports 2 to 5 towards the
w/OPS ports 2 to 5 line port
• ODUTTP facility on line
port 1
• WLAi FOTR • OTUTTP line facility • ODUTTP on line port 1
• WLAi FOTR • OTU4 OTUTTP facility • ODUCTP facility on
w/OPS on ports 41-44 applicable client ports
• OTU2/2e OTUTTP (including sub-ports on
facility on ports 17-19, ports 41-44)
23, 24, 29-31, 35, 36
100G PKT/OTN OTUTTP associated If used for MCN, FTTP facility FTTP facility
XCIF with the mated pair supported on ODUTTP
(100G OCLD or OCI) or ODUCTP facility
10x10G OTU2 OTUTTP facility ODU2 OTUTTP facility OTUTTP
PKT/OTN I/F on ports 1 to 10 ODUTTP/ODUCTP on ports 1 to 10 facility on
facility on ports 1 to 10 ports 1 to 10

Table 1-3

(SCN) (SCN, except
where noted)
100G WL3n OTU4 OTUTTP facility ODU4 OTUTTP facility OTUTTP

PKT/OTN I/F ODUTTP/ODUCTP facility
facility
100G/2x40G • OTU3 OTUTTP facility • ODU3 OTUTTP facility OTUTTP
PKT/OTN I/F (ports 1 and 2) ODUTTP/ODUCTP facility
(NTK668AB) • OTU4 OTUTTP facility facility (ports 1 and 2)
(port 3) • ODU4
ODUTTP/ODUCTP
facility (port 3)
100G/2x40G • OTU3 OTUTTP facility • ODU3

PKT/OTN I/F (ports 1 and 2) ODUTTP/ODUCTP
(NTK668CA and • OTU4 OTUTTP facility facility (ports 1 and 2)
NTK668AM) (port 3) • ODU4
ODUTTP/ODUCTP
facility (port 3)
20x10G SFP+ I/F OTU2 OTUTTP ports 1 ODU2 OTUTTP ports OTUTTP
module to 20 ODUTTP/ODUCTP 1 to 20 ports 1 to 20
ports 1 to 20
2x100G CFP2 I/F OTU4 OTUTTP ports 1 ODU4 OTUTTP ports OTUTTP
module and 2 ODUTTP/ODUCTP 1 and 2 ports 1 and 2
ports 1 and 2
2x100G WL3n I/F OTU4 OTUTTP ports 1 ODU4 OTUTTP ports OTUTTP
module and 2 ODUTTP/ODUCTP 1 and 2 ports 1 and 2
ports 1 and 2
40x10G SFP+ I/F OTU2 OTUTTP ports 1 ODU2 OTUTTP ports OTUTTP
to 40 ODUTTP/ODUCTP 1 to 40 ports 1 to 40
ports 1 to 40
5x100G WL3n OTU4 OTUTTP ports 1 ODU4 OTUTTP ports OTUTTP

CFP2-ACO I/F to 5 ODUTTP/ODUCTP 1 to 5 ports 1 to 5
ports 1 to 5

Table 1-3

(SCN) (SCN, except
where noted)
5x100G/12x40G • OTU4 OTUTTP ports • ODU4 ODUTTP ports OTUTTP ports OTUTTP
I/F 2,3, 7,8 and 12 2,3, 7,8 and 12 1 to 12 ports 1 to 12
• OTU3 OTUTTP ports • ODU3 ODUTTP ports 1
1 to 12 to 12
500G 2xUSS • OTUTTP ports • OTUTTP ports OTUTTP ports • OTUTTP

ports
Note 1: When encryption mode is 'segregated', used to access encryption cards on remote shelves.
Up to 4 GCC2 supported per card.
Note 2: Either GCC0 or GCC1 may be provisioned, but not both.
The following rules must be observed when implementing lower layer GCC:
• The following facilities and equipment support the GCC0 transparency,
where the GCC0 bytes in the OTU2 overhead are passed transparently
through the equipment when the OTU Overhead on-Terminating setting
includes GCC0:
— OTM2 facilities on 2x10G OTR, 4x10G OTR, 40G MUX OCI, 10x10G
MUX, and 100G WL3n MOTR, with the exception of OTM2 mapping
layer facilities.
• The Auto GCC0 Provisioning parameter in the Site Manager Node
Information application System sub-tab (or ED-SYS TL-1 command and
the GCC0 MODE parameter) defines whether a GCC0 PPP circuit (with
IP address of 0.0.0.0) and an associated IISIS or OSPF circuit are
automatically created when the OTM1/OTM2/OTM3/OTM4/OTMC2/OTM
facility is provisioned. By default, the Auto GCC0 Provisioning parameter
is set to Disabled. The 20G (2+8)xOC-n/STM-n LO and SuperMux circuit
packs do not autoprovision GCC0.

• The Auto GCC1 Provisioning parameter in Site Manager Node

Information application System sub-tab (or ED-SYS TL-1 command and
the GCC1MODE parameter) defines whether a GCC1 PPP circuit (with IP
address of 0.0.0.0) and an associated IISIS or OSPF circuit are
automatically created when the OTM2/OTM3/OTM4 facility is provisioned.
By default, the Auto GCC1 Provisioning parameter is set to Disabled.
The following cards do not support GCC1 auto-provisioning:
— 20G (2+8)xOC-n/STM-n LO
— SuperMux
— 10G OTSC
— 10G OTR
— PKT I/F, OTN I/F, and PKT/OTN I/F
• You must delete the associated Static Route, IISIS circuit, or OSPF circuit
before deleting the GCC channel.
For additional details, refer to Table 2-34 on page 2-85 and Table 3-24 on
page 3-59.
Facilities on which the OTN Control Plane is enabled are required to have the
GCC1 or GCC2 allocated for Control Plane communications. The GCC
channel requires the following parameters:
• Carrier = GCC1 or GCC2
• Network domain = OTNCP
More information can be found in the Control Plane Application Guide,

NTRN71AA.
Table 1-4 on page 1-29 shows the supported comms channels on the
SuperMux (GFP-T and GFP-F variants) circuit packs.

Table 1-4
Supported comms channels on the SuperMux circuit packs
Comms Maximum Ports

channel number
configurations supported Supported on client side Supported on line side
GCC0 1 No Yes, up to 1
GCC1 1 No Yes
GCC2 0 No No
SDCC 17 Yes, up to 16 Yes, up to 1
LDCC 2 (Note) Yes, up to 2 Yes, up to 1

Note: For NTK535EA/EB variant, maximum 2 LDCC or 1 LDCC and 1 GCC
(GCC0/1 on OTM2 facility, LDCC available on any Line/Client facility) are supported.
For NTK535FA variant, there are no limits. GCC0 and GCC1 on OTM2 are supported
simultaneously, 11 LDCC and 11 SDCC on OC-n/STM-n facilities are supported.
Table 1-5 on page 1-29 shows the supported channel configurations on the
SuperMux circuit packs.
Table 1-5
Supported channel configurations on the SuperMux circuit packs
Channel configurations Supported on Supported on line

client side side
SDCC only Yes Yes
LDCC only Yes Yes
GCC only No Yes

SDCC and LDCC simultaneously Yes Yes
SDCC and GCC simultaneously No Yes
LDCC and GCC simultaneously No Yes
SDCC, LDCC and GCC simultaneously No Yes
Table 1-6 on page 1-30 shows the supported channel configurations on the
20G (2+8)xOC-n/STM-n LO circuit packs.

Table 1-6
Supported datacomm channels on the MRO circuit packs
Circuit pack Comms Max number Ports
channel supported
5G 16xOC-n/STM-n (NTK12FAE5, NTK513FAE5) GCC0 0 NA

GCC1 0 NA
GCC2 0 NA
SDCC 16 1-16
LDCC 2 1-16
10G 16xOC-n/STM-n (NTK512GAE5, NT513GAE5) GCC0 0 NA

GCC1 0 NA
GCC2 0 NA
SDCC 16 1-16
LDCC 16 1-16
(2+8)xOC-n/STM-n STS-1/VC-3 20G (NTK521CAE5) GCC0 0 NA

(2+8)xOC-n/STM-n LO 20G (NTK522CAE5) GCC1 0 NA
GCC2 0 NA
SDCC 8 1-10
LDCC 8 1-10
(2+8)xOC-n/STM-n STS-1/VC-3 OTN 20G (NTK521DAE5) GCC0 2 1-2

(2+8)xOC-n/STM-n LO OTN 20G (NTK522DAE5) GCC1 2 1-2
GCC2 0 NA
SDCC 8 1-10
LDCC 8 1-10
8xOC-n/STM-n (NTK511AA) SDCC 8 1-8

LDCC 8 1-8
Upper layer DCC implementation rules (does not apply to T-Series

shelves)
The 6500 requires OSI manual area addresses to interop with other OSI
products. The manual area addresses are used to form the NSAP address of
each network element in the OSI level 1 area.
You must observe the following rules when you add manual area addresses:
• You must have at least one manual area address, you cannot delete a
manual area address if it is the only one in the list.
• The default manual area address is 490000.
• Up to three manual area addresses can be provisioned.
• If a new manual area address is provisioned, it is recommended that the
default manual area address of 490000 is deleted if not required.

• After the manual area addresses are added/changed, perform a warm

restart of the shelf processor.
• The routing table supports a maximum of 150 nodes (IS and ES) in a
Level 1 area. A Routing Table Overflow alarm is raised if the 150 limit is
exceeded.
Wayside channel (WSC) interface

The wayside access ports on the RLA modules (T-Series shelf only), SRA,
SAM, ESAM, 2xOSC, and SPAP-2 w/2xOSC circuit packs allow the
communication infrastructure to be shared with wayside traffic flows that
originate and terminate external to the line system. As such, the
communication infrastructure acts as a pipe to allow the transfer of these flows
between sites. Refer to Figure 1-3 on page 1-33 for a Photonic system
Ethernet wayside port usage example.
Table 1-7 on page 1-31 shows the WSC-to-OSC port associations used for
Ethernet connectivity.
Table 1-7
WSC-to-OSC port associations for Ethernet connectivity
Circuit pack/module WSC port Associated OSC port
• 2xOSC WSC3 OSC1

• SPAP2 w/2xOSC WSC4 OSC2
• SRA WSC1 OSC2

• SAM
• ESAM
RLA WSC1 OSC2
One important characteristic of these flows is that they enter the system
through one wayside port and exit the system through another wayside port.
They are not allowed to terminate at any element within the system. Wayside
ports can be bridged externally through an Ethernet cable to maintain wayside
connectivity between OSC facing directions. Pass-through packets that are
virtual local area network (VLAN) tagged in the following range: 256-4094 are
supported on the wayside channel.
The OSC and the wayside channel (WSC) have a combined total bandwidth
of 100Mb/s in each direction. Therefore WSC traffic reduces the available
bandwidth on the OSC up to certain limits as described in the following
paragraphs.

In 6500 releases prior to Release 7.0, the wayside channel ports can be set
to 10Base-T (Half or Full duplex). That is, wayside traffic over OSC is limited
to 10Mb/s. 10Base-T is the recommended setting for most network
applications as it reserves most of the bandwidth of the OSC for optical control
and OAM messaging.
In Release 7.0 and later, the wayside channel ports can also be set to
Full duplex 100BT, Half duplex 100BT, or Automatic (in the Site Manager
Comms Setting Management application Interfaces tab, Interface type
LAN). The default setting is Full Duplex 10Base-T for D-Series/S-Series
shelves. The default setting is Automatic for T-Series shelves.
Auto-negotiation automatically senses the speed (10BT/100BT) and mode
(half-/full-duplex) settings of the link. If the configuration is set to Automatic,
the Wayside ports automatically detect the correct MDI/MDI-X setting to use,
so either straight or crossover cables can be used. If the configuration is not
set to automatic, then since the Wayside ports are MDI-X type use a straight
cable to connect to a MDI interface or a crossover cable to connect to a MDI-X
interface.
The Automatic and 100Base-T settings can only be used in conjunction with
traffic policing which ensures that a maximum of 40 Mb/s of data is sent over
the wayside channel. (Note that the rate may vary somewhat depending on
the packet frame size.) When the 6500 software detects the traffic rate
exceeds 40 Mb/s, wayside traffic is limited to avoid OSC link congestion. OSC
link congestion can cause packet delays, loss on the 6500 internal traffic and
network management traffic, OSC comms loss, failure of optical control (DOC
adjacency failure alarms), and loss of association on network management
systems. To avoid wayside channel limiting, it is recommended to control the
traffic at the traffic sources. This can be done by setting up external traffic
management policies on the routers that are connected to wayside ports. The
traffic management policies need to set the limit of the wayside traffic to be
lower than 40 Mb/s. 6500 automatically terminates the wayside channel
squelching and traffic resumes when it detects that the wayside channel traffic
rate is lower than 40 Mb/s.
Orderwire functionality is supported using a third-party VoIP call server and

VoIP phones networked through the 6500 10/100Base-T wayside ports.
Commercial routers/switches are needed to support this orderwire solution.
Figure 1-4 on page 1-34 shows a simple setup diagram of the generic
VoIP-based orderwire solution deployed over the 6500 wayside channel.
The wayside access ports on the RLA modules (T-Series shelf only), SRA,
SAM, ESAM, 2xOSC, and SPAP-2 w/2xOSC circuit packs for customer use
(IP over 10/100Base-T Ethernet data communications for unspecified use by
the customer) are provided by two 10/100Base-T ports (RJ-45 MDI-X
connectors). The wayside access ports are referred to as WSC ports.

Figure 1-3
Photonic system Ethernet wayside port usage example
Terminal Site Amplifier Site
2 OSC2 Out OSC1 Out 1 Photonic

OSC2 OSC1 1 OSC1 Out OSC2 Out 2
2 OSC2 In OSC1 In 1 Layer OSC1 OSC2
1 OSC1 In OSC2 In 2
WSC4 WSC3
WSC3 WSC4
Wayside (WSC) ports are MDI-X.

RJ45
Subtending L2
or L3 device Photonic
Layer
L1/L2 Service and other L0 circuit packs
are not shown.
WSC4 is unused in this example.
Terminal Site
Wayside (WSC) ports are MDI-X.
2 OSC2 Out OSC1 Out 1

OSC2 OSC1
At network elements with subtending L2 or L3 devices, 2 OSC2 In OSC1 In 1
check the subtending device RJ45 Ethernet port type to
WSC4 WSC3
determine the cable type required to connect to the
Wayside (MDI-X) port. If the RJ45 Ethernet port type is:
- MDI-X, then use a cross-over cable.
- MDI, then use a straight cable.
- Auto MDI-X, then use either a cross-over or straight cable.
RJ45
Attention: Auto MDI-X ports on subtending Ethernet ports Subtending L2

or L3 device
detect if the connection requires a crossover cable, and
automatically selects the MDI or MDI-X configuration to
properly match the other end of the link. If using “Auto”, L1/L2 Service and other L0 circuit packs
both sides must be set to “Auto”. are not shown.
WSC4 is unused in this example.
Wayside (WSC) ports are MDI-X
Legend
Type of cable dependent on subtending Ethernet port type
Cross-over cable

Figure 1-4
Generic VoIP based orderwire solution
Terminal TOADM Line Amp Terminal
2xOSC 2xOSC 2xOSC 2xOSC 2xOSC
Wayside Wayside
ports ports
Switch/ Switch/ Switch/ Switch/

Router Router Router Router
VoIP Call VoIP

Manager Phones
WLAi submarine wayside channel (not applicable to T-Series)

This release supports wayside channel on D-Series/S-Series shelves using
WLAi MOTR (NTK538DR/NTK538DS) and WLAi FOTR
(NTK538FR/NTK538FS) circuit packs. The main application for the wayside
channel is on stretch-spans, such as submarine segments. In this case, there
is a requirement to provide an out-of-band transparent channel between
end-points (for example, SLTEs), but due to large distance the OSC-based
wayside channel is not available.
The submarine wayside channel is associated with the ODUTTP facility on the
line-side port of WLAi MOTR/WLAi FOTR circuit packs. It passes
transparently through regen sites, since it operates in the ODU layer.

The wayside channel can provide up to 26 Mbps of bandwidth, depending on

how the channel is configured (refer to “WLAi submarine wayside
configuration” on page 1-36). It is created by designating an unused COLAN
or ILAN port on the 6500 access panel to be used for wayside access and
associating it with the appropriate ODUTTP facility. In this release, a 1:1
ODUTTP-to-LAN mapping is supported. However, multiple mappings per
shelf are supported. That is, to create multiple wayside channels.
Figure 1-5
Submarine wayside channel access example

WLAi submarine wayside configuration

Configuration of a submarine wayside channel involves two steps:
• Provision an unused COLAN/ILAN port for wayside access (ENT-WSC).
• Provision the lower-layer information (ENT-LLSDCC):
— AID = ODUTTP-shelf-slot-1-CNP1
— CARRIER = EXT (extended) or GCC2 (refer to “WLAi submarine
wayside guidelines” on page 1-36)
— NETDOMAIN = WSC
— LAN port = the LAN port designated for wayside access
Refer to Procedure 2-2, “Editing the communications settings” and “LAN

parameters” on page 2-77 for further details.
WLAi submarine wayside guidelines

Note the following guidelines when using the WLAi submarine wayside
channel:
• A 1:1 ODUTTP-to-LAN mapping is the supported solution for initial
submarine wayside deployments.
• Multiple mappings per shelf are supported to create more than one
wayside if access panel ports are available. For example, one using
ILAN-IN and one using COLAN-A).
• Maximum bandwidth (26 Mbps) is achieved when the carrier is set to EXT
(extended), which is the normal usage for submarine applications. Other
settings are not recommended.
• In this release, the submarine wayside is supported on 14-slot and 32-slot
shelves equipped with SP-2.
• The COLAN-A port is the LAN port normally available for wayside in
submarine deployments on 32-slot shelves. For 14-slot shelves,
COLAN-A can only be provisioned for wayside use if SP redundancy is not
provisioned. COLAN-X and ILAN can also be used if available.
• When a wayside is provisioned against a specific ODUTTP, it is
recommended that no other GCCx be provisioned to ensure optimum
wayside performance in EXT mode.
• Traffic to the specified wayside LAN port should be rate-limited to avoid
exceeding the above rates.
• User traffic entering the wayside must be VLAN-tagged with TPID (tag
protocol ID) of 0x8100 and a VLAN in the range of 1 to 4094.
Restrictions
If a LAN port is used for wayside access, it cannot be used for other purposes.

6500 network element (NE) IPv4 addressing

For background information on assigning IP addresses in a network, see “IP
networks, addressing, and masks” on page 1-422 and “Subnetting and
supernetting - IP addressing examples” on page 1-438.
For information on IPv6, refer to “6500 network element (NE) IPv6 addressing”
on page 1-42. IP versions are enabled/disabled/edited using the options in the
IP Versions Configuration service type (Services tab). Refer to Procedure 2-3,
“Editing the IP Version”.
Single Public IP
Starting in 6500 Release 5.0, you can provision the shelf with only one IP
address. If the NE is a remote NE (in a GNE configuration) then this IP
address is provisioned as the SHELF IP address. If the NE is a GNE, then this
IP address is provisioned as the SHELF IP address (with netmask of
255.255.255.255) and as the COLAN-X IP address (with appropriate
netmask).
Single Public IP is not supported for the following DCN configurations:

• Standalone OSPF
• Redundant OSPF
• Redundant NAT
Single Public IP is supported on Redundant SP/CTM configurations, provided

that the COLAN-X interface is used to connect to the DCN.
General IP address configuration rules

You must observe the following general rules when you implement the IP
addresses:
• Each network element must be assigned at least one IP address and
subnet mask, usually the SHELF IP address, sometimes referred to as the
circuitless IP.
• The SHELF IP must have a subnet mask of 255.255.255.255.
• Each interface on the network element with an IP address/netmask must
be in a separate subnet with the following exceptions:
— un-numbered interfaces are always set to IP 0.0.0.0/32
— single public IP configurations, where the COLAN and shelf-IP can be
set to the same value. Refer to “Single Public IP” on page 1-37.
• If the 6500 network uses a public GNE configuration (all configurations
except Private-IP GNE mode) and the 6500 network is connected to an
external DCN, the IP addresses must be unique within the external DCN.

• If using a Private-IP GNE configuration and the 6500 network is connected

to an external DCN, the GNE addresses must be unique within the
external DCN. The RNE addresses must not overlap with any external
DCN addresses, but do not need to be unique between independent 6500
private-IP networks.
• All gateway network elements for a particular sub-network must be
connected to different IP sub-networks to ensure a fully redundant
solution.
• For redundant gateway network element configurations, it is
recommended that the management system (for example, OneControl) be
located in a different IP sub-network than the 6500 interfaces (including
the COLAN ports).
• IP addresses in the 169.254.0.0/16 range (IPv4 link-local addresses, as
per RFC3927) are not allowed on 6500.
• IP addresses in the 192.168.0.0/24 subnet are not allowed on 6500.
• When assigning Private-IP addresses, it is recommended that the IP
addresses in the range of 10.1.1.0 to 10.4.255.255 are not used. These IP
addresses are used by the 5100/5200 network elements for internal data
communications so must not be used in any 6500 network that will contain
5100/5200 network elements.
• An un-numbered IP address (0.0.0.0) is assigned to optical ports
automatically when PPP DCC/GCC is enabled and the circuit is created.
Do not change these un-numbered IP addresses unless you are
interworking with 5100/5200 (refer to “6500 and 5100/5200 interworking”
on page 1-340).
• For a gateway network element using proxy ARP, the subnet of the DCN
router port that connects to the COLAN-X port must be large enough to
support the COLAN-X port and the SHELF IP address of every network
element for which the gateway network element will proxy ARP. Proxy ARP
must be enabled on the COLAN-X port.
• The control IP address on the PKT/OTN cross-connect circuit pack is a
host address that is distinct from the shelf IP address but can otherwise
be treated similarly.For further details, refer to “PKT/OTN cross-connect
circuit pack and CTM communications considerations” on page 1-119.
• When IP addresses are configured for MPLS through the SAOS CLI (for
example, the loopback interface address), ensure that these addresses do
not overlap with OAM IP addresses, such as the shelf IP, COLAN IP, craft
IP, etc.

Craft LAN port IP address configuration rules

You must observe the following rules when you implement the IP address on
the Craft LAN port:
• LAN-15 is the craft port on the SP in slot 15 of 2-slot, 7-slot, 6500-7
packet-optical, or 14-slot shelf; and LAN-16 is the craft port on the SP in
slot 16 of the 6500-7 packet-optical and 14-slot shelf.
• LAN-41 is the craft port on the SP in slot 41 of 32-slot shelves; and LAN-42
is the craft port on the SP in slot 42 of 32-slot shelves.
• LAN-41 is the craft port on the CTM in slot 41 of T-Series shelves; and
LAN-42 is the craft port on the CTM in slot 42 of T-Series shelves.
• The craft LAN port (LAN-15/LAN-41) has a default IP address of 10.0.0.1
which allows a local craft PC with an IP address configured (see “DHCP”
on page 1-62) to access the network element. The Craft LAN port
(LAN-16/LAN-42) has a default IP address of 10.0.0.5). The Craft LAN
port (LAN-15/16/41/42) subnet mask is always 255.255.255.252 (four
addresses). One address is for the network element, one address is for
the remote PC, one address is the subnet identifier (first address of the
subnet), and one address is the broadcast address (last address of
subnet).
• The LAN-15/16/41/42 port should only be connected to a PC for craft
access. Do not connect the LAN-15/16/41/42 port to any network.
• If you want to be able to access remote network elements using the
LAN-15/16/41/42 port, you must:
— ensure that the host-only mode is set to Off
— assign unique IP addresses to each LAN-15/16/41/42 port as each
LAN-15/16/41/42 port defaults to the same address
(10.0.0.1/10.0.0.5). These unique addresses do not need to be
external DCN addresses but the address/subnet must be unique
within the internal DCN address.
– if the unique IP address is not a DCN address, you can access the
local and remote network elements but not the DCN.
– if the unique IP address is an DCN address, you can access the
local and remote network elements as well as the DCN
— add an IISIS or OSPF circuit on LAN-15/16/41/42
— ensure that an IISIS or OSPF router exists

— if the network element connects to the DCN using OSPF and the Craft
IP addresses are from a Private-IP address range, Private-IP
addresses can be advertised to the DCN. To avoid this, you can:
– filter out the Private-IP addresses at the gateway router level
– use public IP addresses
– use IISIS as the internal routing protocol and configure the route
redistribution so the Craft Private-IP addresses are not advertised
to the DCN
ILAN port IP address configuration rules

You must observe the following rules when you implement the IP address on
the ILAN ports:
• ILAN ports are used for connecting to collocated network elements, OSI
devices, an external IISIS device, or External DCN router in OSPF
networks.
• When connecting to a collocated 6500 network element using internal
IISIS routing, the IP address must be un-numbered (0.0.0.0), (Netmask =
255.255.255.255).
• Unnumbered links (OSPF, IISIS and OSI) must be point-to-point
connections.
• If not using un-numbered ILAN ports, when connecting to a collocated
6500 network element or CPL network element using internal OSPF
routing, you must assign unique IP addresses to each ILAN port (including
those on the CPL network elements). The IP addresses of the ILAN ports
must be in the same subnet as the ports on the collocated network
element to which it connects. These IP addresses must be public IP
addresses (or Private-IP addresses mapped to public IP addresses in a
NAT table) if full access is required.
If the ILAN ports are provisioned with public IP addresses in a single or
redundant GNE configuration using proxy ARP configuration (refer to
“DCN example 6—6500 GNE configuration - standalone ARP GNE
configuration” on page 1-195 and “DCN example 8—6500 GNE
configuration - redundant ARP GNE configuration” on page 1-206), the
ILAN IP addresses must be included in the proxy ARP entries (only the
actual IP address assigned, not the whole ILAN subnet range).

If the ILAN ports are provisioned with Private-IP addresses in a dual GNE
using proxy ARP/NAT configuration (refer to “DCN example 9—6500 GNE
configuration - redundant NAT GNE configuration” on page 1-215):
— the ILAN IP addresses must be included in the proxy ARP entries (only
the actual IP address assigned, not the whole ILAN subnet range)
— the NAT tables must include entries which map the ILAN IP addresses
to the allocated network element public IP address. The Prime
parameter for the ILAN entries must be set to No.
— When connecting to a collocated OSI device, an IP address is not
required. However, an IP address (un-numbered or numbered) is
required before an IISIS circuit can be provisioned on the port.
• When using OSPF on the ILAN ports to connect to collocated 6500
network elements or collocated CPL network elements, a ring connection
of the ILAN ports is recommended.
• ILAN can also be used to connect the NE to the external DCN network in
certain configurations.
• Opaque LSAs are enabled by default on ILAN ports. They can be disabled
if required for specific configurations (for example, if the ILAN is used to
connect the NE to the external DCN network).
• Opaque LSAs are disabled by default on COLAN ports. They can be
enabled if required for specific configurations.
• Opaque LSAs are required for Photonic applications (for example, DOC)
and for TID Consolidation shelf discovery.

6500 network element (NE) IPv6 addressing

As of 6500 Release 11.1, the 6500 supports IP version 6 (IPv6). The main
advantage of IPv6 is the vastly increased address range available, as it uses
128-bit addresses versus IPv4 32-bit addresses. IPv6 also introduces a
number of other changes and additions versus IPv4, such as a modified
packet format to improve the efficiency of packet header processing, improved
support for multi-casting and mandatory link-local addresses.
IP versions are enabled/disabled/edited using the options in the IP Versions

Configuration service type (Services tab). Refer to Procedure 2-3, “Editing the
IP Version”.
IP address notation
IPv6 addresses use the following notation:
• IPv6 addresses are represented as eight groups of four hexadecimal
digits, sometimes referred to as ‘hextets’, with the groups separated by
colons (for example, 2001:11b:d068:0042:0000:6a32:3b1c:0092).
• The hex numbers are not case sensitive. For example, ‘d06a’ is equivalent
to ‘D06A’.
• Subnets are indicated using prefix notation, similar to IPv4 CIDR notation.
For example, 2001:11b:d068::/48 indicates there are 48 network bits and
80 host bits.
• Addresses can be abbreviated:
— Leading zeros can be omitted (for example, in a given hextet, ‘0’ is
equivalent to ‘0000’).
— Trailing zeros cannot be omitted (for example, in a given hextet, ‘17’ is
not equivalent to ‘1700’).
— A contiguous block of zeros can be represented by ‘::’ (double colon).
For example, 2001:0db8:0000:130f:0000:0000:087c:140b is
abbreviated as 2001:0db8:0:130f::87c:140b.
— ‘::’ (double colon) can only appear once in a given address.
— An all-zeros address is represented by ‘::’ (double colon).
6500 implementation
6500 supports a dual-stack implementation, meaning IPv4 and IPv6 operate
independently. This has the following implications:
• IPv4 and IPv6 have no direct interaction with each other.
• Provisioning of the protocols is completely independent. This includes the
IP address itself, the GNE configuration and routing protocols (for
example, the IPv4 GNE configuration could be Private-IP and the IPv6
GNE configuration could be OSPF.)

• One or both protocols can operate at any given time. IPv6 is disabled by
default, but can be enabled concurrently with IPv4 or instead of IPv4.
• A given interface can be provisioned with an IPv4 address, an IPv6
address, or both.
Figure 1-6
6500 dual stack
Addressing
6500 supports end-to-end visibility of all shelves by requiring all shelves to be
assigned a DCN-routable IPv6 address. There is no support for any network
address translation (NAT) models.
Both numbered and unnumbered IPv6 interfaces are supported. An

unnumbered interface is indicated by a double colon (‘::’).
As per IPv4, 6500 supports a ‘single shelf IP’ mode where the COLAN and
shelf IP can be assigned the same IPv6 address in order to simplify
assignment and tracking of addresses. This is supported in a ‘DCN drop’
configuration (all shelves directly connected to DCN) and ND Proxy
configuration.

6500 does not support stateless address auto-configuration (SLAAC).
As per IPv6 standards, link-local IPv6 addresses are assigned to all interfaces
automatically. In Site Manager, link-local addresses are not displayed with the
routable IPv6 addresses but are retrievable in a specific ‘link local’ screen
found under the 'services' tab of the Comms Setting Management application
in Site Manager.
The shelf loopback interface is always /128, just as in IPv4 it is always /32
(255.255.255.255). The shelf loopback interfaces for all shelves in a given
network segment can be assigned from a common /64 subnet.
In keeping with best common practices for IPv6, it is recommended that LAN
interfaces are assigned a minimum /64 subnet.
For IPv6 DCN examples, refer to the following:

• DCN example 26—IPv6 DCN LAN drop to every shelf
• DCN example 27—IPv6 statically routed GNE configuration
• DCN example 28—IPv6 ND Proxy GNE configuration
• DCN example 29—IPv6 redundant OSPF GNEs with IPv4 redundant
OSPF GNEs

6500 network element (NE) internal routing protocols

OSPF or IISIS can be used as the internal routing protocol for 6500 network
elements. However, Photonics applications and TID consolidation require that
OSPF be used as the internal routing protocol.
For more information about the relationship between routing protocols refer to
“IPv4 route redistribution and summarization” on page 1-98.
Non-routing Mode (D-Series/S-Series shelf IPv4 only)

The Non-routing Mode parameter determines if the user can enable a routing
protocol on a given interface. If the Non-routing Mode is On, the user is not
allowed to provision an OSPF or IISIS circuit on the interface.
IISIS router (IPv4 only)

Integrated ISIS (IISIS) is a routing protocol based on the OSI Intra-domain
routing protocol with IP-specific extensions as specified in RFC1195. IISIS
allows IP and OSI to co-exist in a single routing domain, allowing IP-only
routers, OSI-only routers, and dual IP/OSI routers to be effective in routing in
a single network.
IISIS can be used as the internal 6500 routing protocol and is available on all
interfaces except Auto-tunnel, OSC interfaces and the RS-232 ports. The
IISIS router allows the shelf processor to route messages across any LAN or
DCC/GCC port (except Auto-tunnel interfaces, OSC, and RS-232 ports).
IISIS router implementation rules

You must observe the following rules when you implement the IISIS router:
• For T-Series shelves, IISIS is supported for IP routing only. Therefore, the
following are not supported:
— OSI services (for example, TARP), OSI applications (for example, OSI
Rlogin)
— OSI data forwarding (CLNP)
— IISIS auto-tunneling
— GRE tunnels
— IISIS circuits with an NPSOVERRIDE value other than OFF
• If IISIS is used as the internal routing protocol, you must add an IISIS
router for each network element (gateway network elements and
non-gateway network elements).
• It is recommended that route summarization is set to On (default setting).
• For a gateway network element, you must set up a redistribution list
(Static, OSPF) when the gateway network element connects to an
external DCN that does not support IISIS.

• When adding a redistribution list for an IISIS router, you must set the
metric (cost) of any OSPF or static route distribution entries to between 1
and 63. For more information on Route redistribution, refer to “IPv4 route
redistribution and summarization” on page 1-98.
• The IISIS router requires an upper layer DCC MAA. The default MAA is
490000 and is autoprovisioned.
IISIS circuits (IPv4 only)

An IISIS circuit links the LAN or DCC/GCC ports to the IISIS router.
CAUTION
Configuring LAN ports
Unnumbered connections can only be used for point-to-point
links. IISIS is the only routing protocol that can be configured
to run over LAN ports without an IP address assigned.
ATTENTION
All Comms (for example, COLAN-X) Ethernet ports are auto-sensing.
NPSOVERRIDE (D-Series/S-Series shelf only)

Neighbor Protocols Supported Override (NPSOVERRIDE) is a parameter
associated with IISIS circuits. It controls how IISIS operates on the interface
and is dependent on the interface type and the layer-2 protocol provisioned
against the interface. This section summarizes the valid values of the
parameter and its behavior.
Table 1-8 on page 1-47 shows the valid values of the NPSOVERRIDE
parameters for the supported interfaces types and layer-2 protocols.

Table 1-8
NPSOVERRIDE valid values
NPSOVERRIDE LAN (Ethernet) Optical Optical interface

(raw TL-1) Note 1 interface (PPP) (LAPD)
IP and OSI (DUAL) X X X

Note 3 Note 3
IP (IPONLY) X X X
Note 3 Note 3
OSIONLY ÷ ÷ ÷
LAN_OSIONLY ÷ X X
OFF ÷ ÷ X
Note 1: Site Manager value shown. Equivalent TL-1 value is shown in brackets for
cases where it differs from the value shown in Site Manager.
Note 2: X indicates that value is not allowed.
Note 3: Setting is not supported. May be set to this value but behaves as if
parameter was set to OFF.
Table 1-9 on page 1-48 describes the behavior of the NPSOVERRIDE

parameter for the values supported.

Table 1-9
NPSOVERRIDE behavior
NPSOVERRIDE Description
(TL-1) Note
IP and OSI (DUAL) Not supported
IP (IPONLY) Not supported

OSIONLY LAN interface
— IISIS does not advertise IP addresses in the IS-IS hello packets sent over
the interface
— available as an option for legacy applications, but generally LAN_OSIONLY
is recommended when provisioning new IISIS circuits.
— can be used to connect to:
– an OSI device using a point-to-point connection with an unnumbered IP
address (0.0.0.0).
– a broadcast network only if interface has a unique IP address assigned
(i.e. not unnumbered).
Optical interface (PPP/LAPD)
— IISIS attempts to form IP adjacencies, but will not inject these adjacencies
into the IP routing table.
— for any IP adjacencies formed, IISIS attempts to create a GRE auto-tunnel
for the IP packets to be sent over.
— any packets to be sent to the IP adjacency will first be encapsulated in OSI
packets before being forwarded through the established GRE auto-tunnel.
— can be used when connecting to an OSI device such as an OM 3000 or OM
4000.
LAN_OSIONLY LAN interface

— includes behavior associated with OSIONLY for Optical interfaces (above)
but, additionally, IISIS will not advertise IP addresses in the IS-IS hello
packets sent over the interface.
— can be used when connecting to an OSI-only broadcast network or a
point-to-point connection. No IP address is required.
OFF IISIS functions normally on the interface, i.e. IISIS attempts to form both OSI and
IP adjacencies over the interface.
Note: Site Manager value shown. Equivalent TL-1 value is shown in brackets for cases where it differs
from the value shown in Site Manager.

IISIS circuit implementation rules

You must observe the following rules when you implement the IISIS circuits:
• For T-Series shelves, IISIS is supported for IP routing only. Therefore, the
following are not supported:
— OSI services (for example, TARP), OSI applications (for example, OSI
Rlogin)
— OSI data forwarding (CLNP)
— IISIS auto-tunneling
— GRE tunnels
— IISIS circuits with an NPSOVERRIDE value other than OFF
• You must create an IISIS circuit on each provisioned interface you want
IISIS to run on (except Auto-tunnels and the RS-232 ports). Do not create
an IISIS circuit on the COLAN interfaces if the interface is not connected
to external DCN running IISIS (except Auto-tunnel interfaces, OSC, and
RS-232 ports).
• Depending on system settings and card type, an IISIS circuit may be
auto-provisioned in some cases. Refer to the Auto GCC0 Provisioning
and Auto GCC1 Provisioning description in “Lower layer GCC
implementation rules” on page 1-21 for further details.
• Do not configure an IISIS circuit on the LAN-15/16/41/42 port unless using
the port to access (reach through to) another 6500 on the network (see
“Craft LAN port IP address configuration rules” on page 1-39 for more
information).
• The un-numbered IP address is added by default with the ENT-LLSDCC
TL-1 command. The ED-IP TL-1 command is required to change it to a
numbered IP address.
• Un-numbered links (OSPF and IISIS) must be point-to-point connections.
• Link without any IP address can be combined with an IISIS circuit with the
NPS Override parameter set to LAN_OSIONLY to create OSI only
broadcast connections.
• An IP address (un-numbered or numbered) is required before an IISIS
circuit can be provisioned on a LAN (COLAN or ILAN) port. However, an
ISIS circuit can be added to port without an IP address if the NPS Override
parameter is set to LAN_OSIONLY.
• As of Release 10.1, both IISIS and OSPF circuits can be provisioned on
the same unnumbered LAN interface (ILAN/COLAN).

• Use the circuit default metric parameter to represent the speed of the
circuit. Recommended settings are:
— COLAN and ILAN ports: 4
— SHELF IP: 4
— Line/MS DCC: 5
— GCC0/GCC1: 5
— Section/RS DCC: 6
These are the default settings.
• When provisioning an IISIS circuit on an ILAN, COLAN, or optical DCC
port (running LAPD) connected to OSI managed networks elements (for
example, OM 3000 and OM 4000), you must ensure that neighbor protocol
supported override parameter is set to OSI. For ILAN ports,
LAN_OSIONLY can be used for the neighbor protocol supported override
parameter.
• You must create an IISIS circuit on the SHELF IP.
• When provisioning an IISIS circuit on an ILAN or optical DCC/GCC port
(running PPP) connected to another 6500 network element, you must
ensure that neighbor protocol supported override parameter is set to Off.
• If the circuit packs interop with 6500 Photonic Layer or CPL line, set GCC0
Mode to DISABLED or OSPF.
• You can not provision an IISIS circuit for a Transparent DCC.
• You must delete the associated IP static route before deleting an IISIS
circuit or OSPF circuit
• Ensure that the non-routing mode is set to Off before adding IISIS circuits
to LAN ports.
• If both GCC0 and GCC1 comms channels are provisioned on the shelf
with IISIS circuits using Circuit Default Metric, GCC1 comms channel will
be preferred over the GCC0 comms channel.
OSPFv2 router (for IPv4)

Open Shortest Path First (OSPF) Protocol is an Interior Gateway Protocol
(IGP) that distributes routing information between routers belonging to a
single autonomous system (AS). Intended for use in large networks, OSPF is
a link-state protocol which supports IP subnetting and the tagging of
externally-derived routing information.
6500 supports OSPFv2 routing on all interfaces for interworking with an

external customer OSPF DCN. For more information about OSPF, see “IP
routing protocols” on page 1-426.

OSPFv2 router implementation rules

You must observe the following rules when you implement the OSPFv2 router:
• If IISIS is used as the internal routing protocol, you must add an OSPFv2
router for each gateway network element that interfaces to an OSPF
network and each network element that interfaces to an OSPF network
element.
• If OSPFv2 is used as the internal routing protocol, you must add an
OSPFv2 router for each 6500 network element.
• It is recommended that the SHELF IP address is used for the OSPFv2
router ID.
• It is recommended that route summarization is set to On (default setting).
• For a gateway network element with static routing or internal IISIS routing,
you must set up a redistribution list (Static, ISIS) which defines the IP
subnet and submask of all the 6500 network elements.
You must also add an OSPFv2 distribution list for the IISIS router to
distribute DCN routes to the other 6500 network elements (see “IISIS
router (IPv4 only)” on page 1-45).
Redistribution lists are not required in an OSPF only network.
• If one gateway network element is preferred from a routing perspective,
links to/from that GNE must be given a lower OSPF metric than those
to/from any other gateway network elements in the network.
• The Autonomous System Boundary Router (ASBR) parameter
determines if the OSPFv2 router accepts route redistribution from another
autonomous system (IISIS or static routes). The ASBR parameter must be
set to ON if redistributing static or IISIS routes into OSPF. Otherwise, it is
recommended that the ASBR parameter is set to OFF (default). For more
information on ASBR settings, refer to “OSPF Router ASBR setting” on
page 1-433. For more information on 6500 configurations requiring ASBR
functionality, refer to “6500 configurations requiring ASBR set to ON” on
page 1-434. For more information on Route redistribution, refer to “IPv4
route redistribution and summarization” on page 1-98.
• T-Series shelves support two alternative OSPF ABR behaviors: RFC 3509
(default) and RFC 2328-compatible. RFC 2328-compatible mode can be
used in some network scenarios to provide route visibility across OSPF
area boundaries. Refer to “OSPF RFC 2328-compatible ABR (T-Series
shelves only)” on page 1-149 for more information.
• As of Release 12.0, 6500 and CPL support a configurable RFC 1583
mode, which specifies how OSPF calculates paths to external
destinations. Refer to “OSPF Router RFC1583 mode, CPL” on page 1-54
for more information.

OSPFv2 circuits (for IPv4)

An OSPFv2 circuit links the LAN or DCC/GCC ports to the OSPFv2 router.
OSPFv2 circuits can be edited. Refer to Procedure 2-2, “Editing the

communications settings” and Procedure 3-2, “Editing the communications
settings” for details on how to edit OSPFv2 circuits.
CAUTION
Configuring LAN ports
Unnumbered connections can only be used for point-to-point
links.
ATTENTION
All Comms (for example, COLAN-X) Ethernet ports are auto-sensing.
OSPF circuit implementation rules

You must observe the following rules when you implement the OSPF circuits:
• An OSPF circuit needs to be provisioned against an interface if the
network element is intended to form an adjacency over that interface. The
passive parameter needs to be set to OFF in this case.
• An OSPF circuit with the passive parameter set to ON may be provisioned
against an interface if the intent is to advertise the interface through OSPF
without forming an adjacency. No OSPF adjacency alarms will be raised
on this interface.
• As of Release 10.1, both IISIS and OSPF circuits can be provisioned on
the same unnumbered LAN interface (ILAN/COLAN).
• Depending on system settings and card type, an OSPF circuit may be
auto-provisioned in some cases. Refer to the Auto GCC0 Provisioning
and Auto GCC1 Provisioning description in “Lower layer GCC
implementation rules” on page 1-21 for further details.
• For OSPF circuits on the LAN ports, use a metric cost that is the same as
the external router Ethernet port.
• For OSPF circuits on DCC/GCC ports, it is recommended to use the
following default metrics:
— Line/MS DCC: 174 (MSPP services)
— Section/RS DCC: 520 (MSPP services)
— OTU1 GCC: 303
— OTU2/ODU2 GCC: 75

ATTENTION
As the GCC is lower bandwidth than the OSC, it is important to set
the OSPF cost of the GCC channel to ensure that the OSC channel
is the preferred route in a homogeneous OSPF routing domain. Note
that the total OSPF route cost, for a given route between any two
NEs is the sum of the OSPF route cost for each intermediate hop in
that route.
• For MSPP services, when using OSPF on the DCC/GCC channels,

topology auto-discovery does not function. Auto-discovery does function
across DCC/GCC channels using IISIS.
• If the 6500 is in an OSPF only network, you must create an OSPF circuit
on the SHELF IP.
• The OSPF cost for the shelf interface is zero by default and is not
modifiable.
• The following parameters are dependent on the network implementation:
— Network area: OSPF area the OSPF circuit is in (defaults to backbone
area, 0.0.0.0)
— Area: determines type of area (Off [normal], NSSA, or Stub). NSSAs
and Stub areas are not supported in the current release.
ATTENTION
Use special care if provisioning OSPF circuits in the backbone area
(0.0.0.0), either through auto-provisioning or manual provisioning.
Creating a partitioned backbone can cause connectivity problems.
For example, if a backbone exists in the external DCN and a
backbone OSPF circuit is created in the 6500 internal network, some
NEs may become unreachable. In most cases, 6500 OSPF circuits
should be provisioned in non-backbone areas.
• The 6500 supports null, simple, and MD5 authentication types for OSPF
protocol exchanges. The authentication type is configurable on a
per-interface basis. All devices connected to a common subnet require the
same authentication settings for adjacencies to form. The supported
authentication types are described in “OSPF authentication” on
page 1-54.
• The following parameters are normally left at the default settings for most
network applications:
— Area default cost: 1 (default)
— Dead interval: 40 (default)

— Hello interval: 10 (default)

— Retransmit interval: 5 (default)
— Transmit delay: 1 (default)
— Priority: 1 (default). Setting the priority to 0 prevents the OSPF router
from becoming a designated router (DR).
— Passive: OFF (default). Setting passive to ON prevents the OSPF
Adjacency Loss alarm from be raised against the interface.
• You can not provision an OSPF circuit for a Transparent DCC.
• Do not add OSPF circuits to LAN ports provisioned with the non-routing
mode set to On.
• SPLI requires OSPF between the shelf with the CMD, OMD, or OMX and
the shelf with the OTMn/OTU facility. For a single-shelf site (with Photonics
and transponders in same shelf), an OSPF circuit must be provisioned on
the shelf interface. If you set up comms to an MSPP shelf with IISIS
instead of OSPF, SPLI will not work.
• T-Series shelves support OSPF Multi-area Adjacency, as per RFC5185.
Refer to “OSPF Multi-Area Adjacency (OMA, T-Series shelves only)” on
page 1-146 for more information.
OSPF Router RFC1583 mode, CPL

The RFC1583 mode setting determines how OSPF calculates paths to
external destinations that are advertised by multiple ASBRs in different OSPF
areas. Prior to 6500 Release 12.0, the only supported mode was RFC 1583
compatible, where OSPF would prefer the lowest cost path. Beginning in
Release 12.0, RFC 1583 compatible mode can be disabled, such that OSPF
prefers an intra-area path when selecting from a set of ASBRs that are all
advertising the same destination. This is the RFC 2178 (and later)
recommended mode in order to avoid routing loops.
Provisioning: RFC1583 mode is enabled/disabled in the OSPF router settings.
Rules and restrictions: OSPF Router RFC1583 mode is supported on 6500

(all shelf types) and CPL. All routers in a network should have the same
setting for RFC 1583 mode. If this is not the case, routing loops can occur.
OSPF authentication
The following are the supported OSPF authentication types:
• Type 0: null authentication (default)—protocol exchanges are not
authenticated.
• Type 1: simple authentication—a simple alphanumeric password is used
for authentication. This “clear” password consists of 1 to 8 alphanumeric
characters (case sensitive) and special characters and is included in the
OSPF packet that is transmitted.

• Type 2: cryptographic authentication using MD5—a message digest is

computed, using the OSPF packet and a key (password) as input, and is
appended to and transmitted in the OSPF packet. A key ID identifies which
key was used to create the message digest. On the receiving side, a
message digest is calculated using the same key and compared to the
message digest from the transmitting end. The key itself is not transmitted
in the packet.
The key is a combination of 1 to 16 characters (case sensitive) and special
characters. The key ID is an integer between 0 and 255. When multiple
key/keyID pairs are configured on an interface, the key IDs must be
unique.
The 6500 supports a maximum of two key/keyID pairs per OSPF circuit.
Supporting two keys allows a transition from one key to another without
disrupting the OSPF adjacency on the link/subnet. The process of
changing keys is sometimes referred to as a “rollover”. It is expected that
normally a single key is active on a given OSPF circuit except during
rollover. To assist with the rollover, the authentication status of the keys
(MD5 Key 1 and MD5 Key 2 parameters) is shown in the Comms Setting
Management Site Manager application (Routers tab, select OSPF Circuit
from Router type drop-down list). The possible authentication status
values are “accepting” and “rejecting”, indicating that a given key is either
passing authentication or failing authentication, respectively.
The rollover process involves adding a second key to an interface,
verifying the second key is in “accepting” status, then deleting the first key.
Refer to the following for more details:
— Procedure 2-5, “Migrating an MD5 key” and Procedure 3-4, “Migrating
an MD5 key”: use Edit button in Comms Setting Management Site
Manager application (Routers tab, select OSPF Circuit from Router
type drop-down list)
— parameter options and descriptions:
– for D-Series and S-Series shelves: Table 2-8 on page 2-45 and
Table 2-9 on page 2-48
– for T-Series shelves: Table 3-6 on page 3-32
If changing authentication type on a given interface, any existing
adjacencies will be disrupted until all interfaces are configured with the
same authentication parameters.
6500 MD5 notes:
— MD5 is only supported on SP-2 (NTK555CAE5, NTK555EAE5, and
NTK555FAE5) and SPAP2 w/2xOSC (NTK555NA/NTK555NB) circuit
packs.
— The 6500 supports a maximum of two key/keyID pairs per OSPF
circuit.

— To avoid disrupting an OSPF adjacency while transitioning from an old

key to a new key, ensure that the status of the new key is “accepting”
before deleting the old key.
— The 6500 does not support:
– key life cycle management.
– the “last authentication key expiration” notification defined in RFC
2328.
IP static route (D-Series/S-Series shelf IPv4 only)

The IP static route option provides details of the static IP routing (see “Static
and default routes” on page 1-437 for more information). Use the IP static
route option to add/delete static routes.
IP static route implementation rules

You must observe the following rules when you implement static routes in the
IP routing table:
• The next hop provisioning of the static IP must be in the same subnet as
the interface against which it is provisioned.
• If provisioning a static route through an unnumbered interface, the next
hop should be set to 0.0.0.0.
Shelf IP redistribution (D-Series/S-Series shelf IPv4 only)

Description
In some network configurations, given shelves may participate in multiple
non-backbone OSPF areas but have no connection to the OSPF backbone
(area 0.0.0.0). An example is shown in Figure 1-7 on page 1-58.
The SHELF IP address generally needs to be visible in each area the shelf
participates in, for applications such as OAM management, consolidated
nodes, and Domain Optical Control (DOC), for example. Since the SHELF IP
address interface can only participate in one OSPF area, this can necessitate
the addition of static routes and associated route redistributions in order to
provide the required IP visibility of this SHELF IP into each area. This can add
provisioning complexity and, further, since these static routes are associated
with a specific interface, if the interface goes down, the route may disappear
from the OSPF routing domain.
The shelf IP redistribution feature provides a way of redistributing the SHELF

IP address in to multiple OSPF areas without provisioning static routes. The
SHELF IP is redistributed into all subtending OSPF areas. This feature
reduces provisioning complexity and, since there is no physical interface
associated with this redistribution, it does not depend on the state (up/down)
of the interface.

Configuration
Shelf IP redistribution can be enabled on a per-shelf basis using the Shelf IP
Redistribution parameter associated with the OSPF router instance. It is
disabled by default. Refer to Table 2-8 on page 2-45 to Table 2-11 on
page 2-52 for parameter details.
Engineering guidelines
This feature should only be used in configurations where there is no OSPF
backbone in the OSPF autonomous system.
The Autonomous System Boundary Router parameter associated with the

OSPF router must be enabled when the shelf IP redistribution feature is
enabled.
If shelf IP redistribution is enabled, an OSPF circuit should not be assigned to

the SHELF IP interface.
Each shelf with the shelf IP redistribution feature enabled originates one
OSPF Type-5 LSA.

Figure 1-7
Example network: NEs in multiple non-backbone OSPF areas but no connection to OSPF
backbone
External DCN
Shelf IP Redistribution enabled Shelf IP Redistribution enabled
Domain/Area A Area B Domain/Area C
Shelf1 Shelf2
SiteID 2
Shelf1 shelf IP visible in Areas A and B Shelf2 shelf IP visible in Areas B and C
Legend
COLAN-X
6500 ROADM shelf
COLAN-A
ILAN-IN
ILAN-OUT 6500 amplifier shelf

OSPFv3 (for IPv6)

The 6500 supports OSPF for IPv6, referred to as OSPFv3. OSPFv3 only
supports IPv6, and therefore if OSPF is required in an IPv4 context, such as
in a dual-stack configuration, OSPFv2 is also required.
OSPFv3 provides similar functionality to OSPFv2. However, on 6500 there are

some differences in implementation as outlined below:
• The OSPFv3 router-ID is the only parameter that needs to be configured.
The router-ID is 32-bit dotted-decimal value, in accordance with OSPFv2,
and it is recommended to set it to same value as the OSPFv2 router-ID if
both are configured.
• The OSC OSPFv3 circuit does not auto-provision when the OSC facility is
provisioned and the Node Information System parameter “Auto
OSC/OSPF provisioning” is set to OSPF. The OSPFv3 circuit must be
manually provisioned, but before it can be an unnumbered IP address
(::/128) must be provisioned against the OSC.
• The OSPFv3 ASBR attribute is set automatically if the route redistribution
parameter is set in any IPv6 static route.
• The shelf-RD parameter is not supported.
• The opaque filter is not supported, as there are no opaque LSAs in
OSPFv3.
• The route summarization parameter is not supported.
• OSPFv3 circuits on the shelf interface and craft interface always behave
as passive interfaces (no adjacency formed), regardless of what the
'passive' parameter is set to. This is true in OSPFv2 and OSPFv3. In
OSPFv3, the 'passive' parameter defaults to 'ON' to reflect the actual
behavior. However, in OSPFv2, the 'passive' parameter defaults to 'OFF'
even though the circuit is indeed passive.
• OSPFv3 authentication is not supported.
ATTENTION
Use special care if provisioning OSPF circuits in the backbone area
(0.0.0.0). Creating a partitioned backbone can cause connectivity
problems. For example, if a backbone exists in the external DCN and
a backbone OSPF circuit is created in the 6500 internal network,
some NEs may become unreachable. In most cases, 6500 OSPF
circuits should be provisioned in non-backbone areas.
Other protocols
IISIS for IPv6 is not supported.

Static route behavior for IPv6 and T-Series shelves

This section describes functionality introduced in Release 11.1 related to how
static routes are defined for both IPv6 and T-Series shelf. Existing capabilities
are also described for completeness.
Next-hop provisioning
For D-Series/S-Series shelves running IPv4, static routes may be defined as
follows:
• Specify interface and next-hop: This type of static route specifies both the
interface through which the next-hop is found and the IP address of the
next-hop itself. This method is used for numbered interfaces, such as
numbered LAN interfaces that are connected to broadcast networks. The
next-hop is part of the adjacent subnet in this case.
• Specify interface only: This type of static route specifies only the interface
through which the next-hop is found. This method is used for unnumbered
point-to-point interfaces, such as GCC/DCC/OSC and unnumbered LANs,
since there is only one device at the far-end of the link and it has no
interface IP address.
Beginning in Release 11.1 (for IPv6 and T-Series shelf), this additional method
may be used to specify a static route:
• Specify next-hop only: This type of static route specifies only the next-hop.
The interface is not specified and is determined through the forwarding
table, and therefore has the possible advantage of providing increased
resiliency to faults—if one path to the next-hop fails and another path
exists, the static route is still valid and usable. In this case, the next-hop
should not be part of an adjacent subnet. This method is sometimes
referred to as a ‘floating’ static route.
Static routes with same destination

On a D-Series/S-Series shelf for IPv4, each static route must have a unique
destination (that is, an IP address/mask combination).
In IPv6, multiple static routes to the same destination are supported. In such
a case, the handling of the routes is as follows: the lowest cost route is used.
If multiple equal-cost routes exist, one is chosen and used.
For a T-Series shelf, multiple static routes to the same destination are
supported. In such a case, the handling of the routes is as follows: the lowest
cost route is used. If multiple equal-cost routes exist, since ECMP is
supported, the routes are shared.
Equal-cost multi-path (ECMP)

6500 shelves support ECMP, where next-hop forwarding to a given destination
can occur over multiple equal-cost paths. 6500 shelves implement the highest
random weight algorithm in accordance with RFC 2991.

6500 network element (NE) IPv4 supported protocols

Internal SNTP client/server
The 6500 supports Simple Network Time Protocol (SNTP) for time-of-day
synchronization with external servers. The configuration of SNTP on the 6500
depends on whether the GNE configuration is a public-IP model or a
private-IP model.
In the public-IP model, the SNTP client on each 6500 node is typically
configured to synchronize with external SNTP servers.
In the private-IP model, the SNTP client on the GNEs is configured to

synchronize with external SNTP servers, while the RNEs synchronize with the
SNTP server on the GNEs.
The internal SNTP server functionality is available in all GNE configurations.

The SNTP clients on the GNEs are configured with the IP address of the time
servers in the DCN. The RNE SNTP clients are provisioned with the IP
addresses of the GNEs.
The GNE synchronizes its own Time of Day via an external SNTP server on
the customer DCN.
Secure HTTP
The Secure HTTP service builds upon the standard HTTP server currently
available on the 6500. Integration of the Standard SSL library, FIPS compliant,
with the existing standard HTTP server provides the level of security needed
for the Secure HTTP service.
The 6500 supports both the standard HTTP server and the Secure HTTP
server. The Secure HTTP server runs on port 443.
By default, both standard and Secure HTTP servers are enabled.
ATTENTION
In Photonic networks, do not disable the standard HTTP or Secure HTTP
servers on NEs that were upgraded to 6500 Release 10.1 or higher until all
NEs have been upgraded to Release 10.1 or higher. Disabling HTTP servers
before all NEs are upgraded will affect DOC behavior.

Using Site Manager or TL-1 commands, you can perform the following:
• Enable/disable the standard and/or secure HTTP server
• Retrieve settings for both the standard and secure HTTP servers
• Force NE host key re-compute SSL and security certificate regeneration
• TL-1 commands also allow to retrieve SSL public key information
Only SSL certificate key size of 1024 is supported. Entering a key size of 512
will be rejected.
The standard and Secure HTTP servers allow Site Manager to retrieve the NE
SNMP MIBs from the MIB browser.
When you connect to the server with a fresh browser session (a session that
never connected to the server), a warning message appears indicating that
the certificate being sent from the server to the browser. You must accept this
certificate for the connection to be completed.
Note that when you connect to the server for the first time, the connection can
take up to one minute to complete. However, in Private-IP configuration, a
connection to the RNE with a fresh browser, can take more than one minute.
DHCP
6500 supports a dynamic host configuration protocol (DHCP) server on the
Craft Ethernet interface on the SP/CTM (LAN-15/16/41/42). The DHCP
server:
• eliminates the need for the Craft user to manually assign an IP address to
the Craft PC when it is connected to the Craft Ethernet port
• facilitates moving the craft PCs to a Craft port on a different network
element, without re-assigning an IP address to the craft PC
The DHCP server is only supported on the craft Ethernet port

(LAN-15/16/41/42 on the shelf processor/control and timing module [CTM]).
The DHCP server supports Microsoft Windows DHCP clients. The DHCP
server is enabled by default and has the following default values:
• IP address: 10.0.0.2 for LAN-15/41 and 10.0.0.6 for LAN-16/42
• Netmask: 255.255.255.252
• Gateway address: 10.0.0.1 (default IP address of LAN-15/41) or 10.0.0.5
(default IP address for LAN-16/42)
• Default lease period: 600 seconds
• Maximum lease period: 7200 seconds
The IP and gateway addresses are automatically updated when the

LAN-15/16/41/42 IP address is changed.

DHCP relay agent for Zero Touch Provisioning (not applicable to T-Series)
Zero Touch Provisioning (ZTP) is a feature that simplifies the initial
commissioning of a shelf from the perspective of the installer by allowing the
shelf to retrieve its provisioning information and subsequently provision itself
automatically. Depending on the requirements of a given customer’s
operations, the provisioning information can range from the minimal amount
required to make the shelf visible on the network (for example, basic shelf and
data comms provisioning) to a larger set of commands including equipment
and services provisioning. If the shelf receives the minimal amount of
provisioning information, the remainder of the provisioning can be performed
remotely via Site Manager or the network management system (NMS).
ZTP, the DHCP relay agent and DHCP relay agent interfaces are managed
using the Comms Setting Management application. For information on:
• equipment requirements and detailed procedures related to ZTP and the
DHCP relay agent, refer to Commissioning and Testing, 323-1851-221
• ZTP parameters refer to “Zero Touch Provisioning parameters” on
page 2-99
• DHCP relay agent parameters refer to “DHCP Relay Agent parameters”
on page 2-94
• DHCP relay agent interface parameters, refer to “DHCP RA Interfaces
parameters” on page 2-95
FTP
File transfer protocol (FTP) is a standard Internet protocol used for transferring
files across a network. This protocol uses a client/server architecture. Both an
FTP client and server are supported on the shelf processor/control and timing
module (CTM) of the 6500.
The FTP protocol is used on the 6500 platform to handle all file transfers within
the network element, between network elements, and between the network
element and the management system. The user can enable/disable the FTP
server and can configure the time before an idle FTP session is disconnected.
The FTP server has the following characteristics:
• disabled by default
• “put” only allowed to the “/loadmgmt/craft” directory
• only binary supported
PPP is not supported over the serial ports in the current release, therefore
FTP and HTTP over the serial ports is not supported. For FTP and HTTP
access (for example, when performing database backup and restore
operations), use the LAN ports. For information on SFTP, refer to “Secure shell
and SFTP” on page 1-64.

Secure shell and SFTP

Secure shell (SSH) is a protocol which provides encrypted communication
between the 6500 network element and Site Manager or OneControl. 6500
also supports secure FTP (SFTP) v3/v4 compliant client on the network
element and an SFTP v3 compliant server on Site Manager and OneControl
for file transfers (for example, backup and restore).
SSH and SFTP are employed to secure the network management traffic. SSH
client/server solutions provide secure replacements for Telnet, rlogin, FTP,
etc. SSH connections provide highly secure authentication, encryption, and
data integrity to combat password theft and other security threats.
6500 SSH/SFTP features include:

• secure encrypted communication
• provisionable Idle timeout
• provisionable number of maximum connections
• ability to enable/disable the SSH server
• public/private key pair generation utilities
6500 supports:
• SSH/SFTP authentication with a DSA key type and 512 or 1024 bit key
size
• SSH/SFTP authentication with a RSA key type and 1024, 2048 or 3072 bit
key size
• SSL certificates with an RSA key type (1024, 2048, and 3072 bit key size),
and SHA1 and SHA256 hash fingerprint type. RSA and ECDSA
certificates may be uploaded to replace the self signed certificates.
SSH/SFTP configuration
The SSH/SFTP client and server must each be enabled and configured in
each of the required applications/platforms prior to use.
Configure the 6500 network element as follows:

• If required, enable SSH/SFTP. By default the SSH client, SFTP client, and
SFTP server are enabled. The SSH server is enabled by default, and the
maximum number of active sessions it supports is three.
• Disable regular Telnet on the NE (optional). Regular Telnet and SSH can
both be enabled on the NE. This is only allowed when SSH is enabled.
Non-secure Telnet ports are disabled. Serial ports are always accessible.

ATTENTION
If both SSH and Telnet servers are enabled, the total maximum number of
SSH and Telnet sessions combined cannot exceed 21. For example, if SSH
is enabled with 16 maximum sessions, you cannot have more than five
enabled Telnet sessions. To increase the maximum number of Telnet
sessions, you must reduce the maximum number of SSH sessions.
Where possible a default SSH configuration will be used and initial

public/private keys will be automatically generated. This will allow a simple
and fast way for users to quickly establish SSH sessions.
SSH re-keying
When an SSH session is established, a secret key is negotiated to encrypt
communication between the client and server. The re-keying feature forces a
renegotiation of the session key after one hour of the session or 1 GB of data
transfer.
SSH host key validation

As part of the SSH protocol, a client may validate the server's host key. By
default, the SFTP client on the NE logs and accepts the server fingerprint. The
SSH Host Key Validation feature enables host key validation in the SFTP
client. In order to use this feature, an administrator will need to provision all
the public keys of the SFTP servers that the NE will connect to via SFTP.
Public key authentication

The public key authentication feature enables public key authentication on the
SSH server. Administrators will need to provision each user's public key. Every
user will also be required to supply an SSH userid as part of their login to the
NE.

SSH/SFTP port numbers

Table 1-10 on page 1-66 indicates the SSH/SFTP client and server port
numbers to use for a particular NE (for example, 6500).
Table 1-10
SSH/SFTP port numbers
SSH/SFTP port number Description 6500 unsecured

ports
22 (default for SSH) SSH server: Telnet, TL-1 (user 23

shell)
20001 SSH server: Telnet, TL-1 10001
20002 SSH server: CLI 10010, 10020
28888 SSH server: Internal Ciena debug 8888

Originating port: 20004 (default) to 20030 SFTP client: FTP 20, 21
Destination port: 22 (default) (Note)
Note: The NE uses, in a sequential fashion, ports between 20004 and 20030 (for example, the first
session uses 20004, the second one 20005, and so on). The destination port defaults to 22, but you can
provision it to be anything between 1 and 65535, inclusive.

SSH/SFTP encryption parameters

Table 1-11 on page 1-67 indicates the SSH/SFTP client and server encryption
parameters used by the 6500 NE.
Table 1-11
SSH/SFTP encryption parameters
SSH/SFTP Description Cipher options

encryption parameter
Encryption The encryption cipher indicates which • AES-128 (CBC) (Note 1, Note 3)
algorithm is used to encrypt the SSH • AES-192 (CBC) (Note 1, Note 3)
messages.
• AES-256 (CBC) (Note 1, Note 3)
• 3DES (Note 2)
• AES-128 (CTR) (Note 1, Note 4)
• 3DES
Message The Message Authentication Code (MAC) • MD5 (Note 5)

Authentication Code indicates which algorithm is used to • MD5-96 (Note 5)
generate the MACs.
• SHA1 (Note 6)
• SHA1-96 (Note 6)
• SHA2-256 (Note 6)
Note 1: AES stands for Advanced Encryption Standard.

Note 2: 3DES stands for Triple Digital Encryption Standard.
Note 3: CBC stands for Cipher Block Chaining Mode.
Note 4: CTR stands for Counter Mode.
Note 5: MD5 stands for Message Digest-5.
Note 6: SHA1 stands for Secure Hash Algorithm-1.

NETCONF
Release 12.6 adds support for the Network Configuration Protocol
(NETCONF), an XML-based network management protocol specification. You
can use NETCONF to install, manipulate, and delete network device
configurations, and to provision and activate network services.
NETCONF works with YANG modules (which define the configuration data,
state data, and the capabilities available on a 6500 node) to perform tasks on
a 6500.
To communicate with a 6500 node through the NETCONF interface, you

require a NETCONF client, which uses XML data encoding to exchange
configuration data and protocol messages with the 6500 node.
Communication between a NETCONF client and 6500 is session-based.
The NETCONF client and 6500 communicate using Transmission Control

Protocol (TCP) for reliability and Secure Shell (SSH) for security. On 6500,
NETCONF accesses TCP port 830.
NETCONF uses a simple remote procedure call (RPC) mechanism to

facilitate communication between a client and server.
To use the NETCONF server on 6500, the server must be enabled. The
NETCONF server is disabled by default. Use Site Manager or the
ED-NETCONF TL-1 command to enable or disable the NETCONF server.
For more information on NETCONF, refer to NBI Fundamentals,

323-1851-165.
For information on enabling NETCONF, refer to Procedure 2-2, “Editing the

communications settings” and Procedure 3-2, “Editing the communications
settings”.
PPP
Point-to-point protocol (PPP) is a data link layer protocol used to pass data
between two systems on behalf of the IP network layer protocol.
For 6500, only the magic number support PPP parameter can be edited
(default On), the remaining parameters are set to the default settings. For
details of the default settings, refer to Table 2-36 on page 2-87 and Table 3-26
on page 3-62.
PPP is not supported over the serial ports in the current release, therefore
FTP and HTTP over the serial ports is not supported. For FTP and HTTP
access (for example, when performing database backup and restore
operations), use the LAN ports.

Telnet
Telnet is a user command and an underlying TCP/IP protocol for accessing
remote computers. A Telnet client is supported on the shelf processor/control
and timing module (CTM) of the 6500 which allows login to other network
elements. The user can configure the maximum number of concurrent Telnet
sessions allowed and the time before an idle Telnet session is disconnected.
ATTENTION
The Telnet server can be disabled if the SSH server is enabled.
OSI rlogin support

OSI rlogin allows you to log in to the following platforms:
• OM 3000
• Optical Cross Connect DX
• Optical Cross Connect HDXc/HDX
• S/DMS TransportNode TN-16X
• OC-48 Classic
Only one OSI rlogin session can originate from the 6500 at a time.
OSI rlogin allows you to log in using Site Manager and TL-1 to the 6500 from
the OM 3000 platform. The rlogins connecting to the 6500 network element
count towards the maximum number of concurrent Telnet sessions.
The OSI rlogin is accessed from the CLI on the ports listed in Table 1-10 on
page 1-66 when breaking out from a TL-1 session.
You can use a OM 3500 Site Manager (in stand alone or consolidated craft
mode) connected to a 6500 network element to OSI rlogin to an OM 3500
network element to allow the OM 3500 network element to be managed using
Site Manager and not just TL-1 (requires the Requires Manual
Connection/Secure Modem at Gateway Node option to be selected on the
Login window).
For a detailed procedure, see Administration and Security, 323-1851-301.
GRE
Generic routing encapsulation (GRE) provides a standard method for
transporting one arbitrary network layer protocol over another arbitrary
network layer protocol (tunneling). A tunnel is effectively a point-to-point
connection which allows packets to be enclosed/encapsulated within another
packet.

6500 supports static tunnels and auto-tunnels:

• Static tunnels are user defined point-to-point tunnels used to pass packets
from one node to another. Static tunnels are ideal for bridging sections of
a network which do not support a protocol (for example, routing IP packets
through an OSI network). The user creates a static tunnel by specifying a
protocol (OSI or IP) and a tunnel termination point (IP or OSI address).
Creating a static tunnel to a specific destination only allows packets to be
sent to that destination. You must configure a tunnel in the opposite
direction for packets to be returned.
• Auto-tunnels are dynamically created and removed as required by a dual
router. Auto-tunnels do not require user intervention but only operate over
IISIS sections of the network. The mechanism for setting up auto tunnels
on 6500 leverages the optional encapsulation TLV of the IISIS LSPs (TLV
type 16). During IISIS shortest path first calculations, if the 6500 has any
adjacencies over circuits that are marked as only able to forward OSI, but
not IP PDUs, it will search the LSP from that adjacency to find the closest
NE to the adjacency that is capable of GRE encapsulation of IP over OSI
(as indicated by TLV 16). This NE will be chosen as the end point for the
GRE auto-tunnel created over the circuit. The 6500 only sets up one
auto-tunnel per path, which means that the 6500 will not establish auto
tunnels to other NEs capable of GRE IP over OSI encapsulation that are
reachable (shortest path) through the closer NE it already established an
auto tunnel with.
GRE implementation rules

You must observe the following rules when you implement GRE:
• Up to 4 static tunnels can be configured for each protocol. For an OSI
tunnel (GRE-OSI-1 to 4), you must provision the destination OSI (NSAP)
address. For an IP tunnel (GRE-IP-1 to 4), you must provision the
destination IP address.
• When provisioning OSI tunnels (GRE-OSI-1 to 4), the network selector
(NSEL, last 2 bytes of NSAP) of the provisioned NSAP destination
address must be set to “00” (6500 internally automatically sets the NSEL
to support the required transport service).
• The destination node/router must also be configured for tunneling with the
destination address of the 6500 network element (normally the COLAN
port address).
ATTENTION
Auto-tunnels are dynamically created as needed. They are different from
GRE tunnels. There is no hard-coded limits on Auto-tunnels.

6500 network element (NE) IPv6 supported protocols and

applications
For IPv6, the following protocols and applications are supported, generally
at-par with IPv4 functionality:
• Protocol support
— Telnet server and client
— SSH server and client
— FTP server and client
— SFTP server and client
— HTTP server and client
— HTTPS server and client
— NETCONF
— SNMP
— TOD (SNTP) client
— RADIUS
— TACACS+
— gRPC
— DHCP server on craft port. For further details on the IPv6 DHCP
server on the craft port, refer to “Craft communications” on page 1-75.
— Ping and Traceroute server and client
• Application support
— Upgrades and load delivery
— Database backup and restore
— PM retrieval and Syslog
— RTRV-LOG
— OTDR
— Integrated Test Set and Link Data
— CLI and SNMP Proxy
— Craft reach-through

Exclusions
The following features and functions are not supported on 6500 with IPv6:
• RTRV-NODES: This impacts Site Manager ‘visible NE information’, Add
Node, and Find Node dialogs.
• Network-level duplicate address detection
• Access to Encryption OTR circuit packs

6500 network element (NE) IPv6 comms feature support and GNE
support
For IPv6, the following IPv6 comms features are supported:
• Static routing
• OSPFv3
• COLAN, ILAN, shelf, craft, DCC, GCC and OSC interfaces
• IPv6 static routes
• Firewall
The following is not supported:

• AR (Address Resolution)
• OSPFv3 authentication
• OSI and IISIS
• TL1 Gateway
• DBRS and OOLFC (OSPF opaque filtering)
• IP Access Control List (ACL)
For IPv6, the following IPv6 GNE features are supported:

• OSPF GNE
• Static routing GNE
• ND (Neighbor Discovery) proxy GNE
The following is not supported:

• NAT GNE
• Private IP GNE
• Redundant ARP GNE. Note: IPv6 ND proxy is equivalent to Standalone
Proxy ARP in IPv4

Data communications with shelf processor/control and timing

module (CTM) redundancy
6500 supports shelf processor/control and timing module (CTM) redundancy
on the 6500-7 packet-optical, 14-slot, 32-slot, and T-Series shelves. One shelf
can support up to two shelf processors/CTMs in slots 15 and 16 of a 6500-7
packet-optical and 14-slot shelf, and slots 41 and 42 of a 32-slot and T-Series
shelf. Shelf processor redundancy is not supported on the 2-slot or 7-slot
shelves. For the 6500-7 packet-optical shelf, shelf processor redundancy only
applies to the SP-2 shelf processor variants. For the 14-slot shelf and 32-slot
shelves, shelf processor redundancy applies to SP-2 shelf processor variants.
Redundant shelf processor/CTM configurations are supported provided both

shelf processor/CTM slots are using the same shelf processor/CTM (same
PEC). Mixed NTK555AAE5/NTK555ABE5 shelf processors and SP-2
redundant configurations are only supported during shelf processor
reconfiguration. With shelf processor reconfiguration, you can move from an
NTK555AAE5/NTK555ABE5 to an SP-2 in an existing redundant
configuration. Note that NTK555AAE5/NTK555ABE5 shelf processors are no
longer supported in Release 12.1 and above.
Data communications support with shelf processor/CTM redundancy

When shelf processor/CTM redundancy is provisioned, one shelf
processor/CTM is active and one is standby. The active shelf processor/CTM
controls the majority of the data communications for the network element. This
includes COLAN, ILAN, GCC/DCC/OSC, craft data communications, routing
functions (IP and OSI), TL-1, and CLI. Note that on 14-slot shelves, COLAN-A
has some limitations. Refer to “LAN ports” on page 1-9 for details. The
standby shelf processor/CTM supports only the following limited data
communications for Ciena personnel only:
• debug access through craft port. For more details, refer to “Craft
communications” on page 1-75.
• debug access through serial port if available
For shelf processor/CTM redundancy engineering rules, refer to the

“Engineering rules for 1+1 SP equipment protection” section in Part 2 of
Configuration - Provisioning and Operating, 323-1851-310; and the
“Engineering rules for 1+1 CTM equipment protection” section in Part 2 of
Configuration - Provisioning and Operating for T-Series, 323-1851-311.

COLAN alarms with SP/CTM redundancy

COLAN-X and COLAN-A may be provisioned regardless of which SP/CTM is
active. COLAN alarms are generated by the active SP/CTM.
On D-Series/S-Series shelves, the COLAN-X and COLAN-A link failure

alarms indicate the respective COLAN connection has failed and are
generated regardless of which SP is active. On a 14-slot shelf with the SP in
slot 16 active, the COLAN-A link failure alarm may also indicate one of the
following:
• the SP in slot 15 has failed
• there is a communication failure between the SPs in slots 15 and 16
On T-Series shelves, there is a generic 'LAN link failure alarm' used for all LAN
failures, including COLANs and ILANs, with the applicable interface specified
by the AID. The alarm is generated regardless of which CTM Is active.
Craft communications
Craft communications on the active SP/CTM and the standby SP/CTM (for
14-slot, 32-slot, and T-Series shelves with SP/CTM redundancy) work
independently.
When connecting a Craft PC to the craft port on the active SP/CTM, the PC
has access to the following functions:
• DHCP is available to assign IP address to the Craft PC
• Access to all TL-1 commands including Site Manager support
• Access to debug interface (Ciena personnel only)
• Craft reach-through capability
ATTENTION
Craft reach-through capability is only available on the active SP/CTM when
the IP address is changed from default to a unique IP address in the internal
network. The user must be authenticated on the local NE before
reach-through access is granted to other NEs.
When connecting a Craft PC to the craft port on the standby SP/CTM (for
14-slot, 32-slot, and T-Series shelves), the PC has access to limited functions:
• DHCP is available to assign IP address to the Craft PC
• Access to debug interface (Ciena personnel only)
LAN-15 is the craft port on the SP in slot 15 of a 2-slot, 7-slot, 6500-7

packet-optical or 14-slot shelf. LAN-41 is the craft port on the SP/CTM in slot
41 of a 32-slot, and T-Series shelf.

The IPv4 DHCP on the LAN-15 and LAN-41 ports is defaulted as:
• Server state: ENABLED
• Server IP Address: 10.0.0.1
• Subnet Mask: 255.255.255.252
• IP Address for client: 10.0.0.2
• Server Pool End Address: 10.0.0.2
• Gateway IP Address: 10.0.0.1
• Default Lease Time: 600
• Maximum Lease Time: 7200
• Server state: disabled
• Server IPv6 address: fd00:238a:6500:a::1/64
— If using non-default addresses, the user may specify only the upper 64
bits (that is, the /64 prefix). The least-significant 64 bits must be ::1.
The client address will always have the same upper 64 bits as the
server and have a least-significant 64 bits of ::2.
• Client IPv6 address: fd00:238a:6500:a::2/64
• Gateway IPv6 address (as seen by craft PC): the link-local address of the
LAN-15/41 port. This value is visible from within Site Manager Comms
Setting Management/Services/LinkLocal.
• Preferred lifetime: 600 seconds
• Valid lifetime: 600 seconds
Note: Certain newer versions of macOS may not work with the IPv6
DHCP server when connected to the craft port. In this case, it is suggested
to use IPv4 DHCP to access the craft port.
LAN-16 is the craft port on the SP in slot 16 of a 6500-7 packet-optical and

14-slot shelf. LAN-42 is the craft port on the SP/CTM in slot 42 of a 32-slot,
and T-Series shelf. The 2-slot, and 7-slot shelves do not have a LAN-16 port.
• Server state is: ENABLED
• Server IP Address: 10.0.0.5
• Subnet Mask: 255.255.255.252
• IP address for client: 10.0.0.6
• Gateway IP Address: 10.0.0.5

• Default Lease Time: 600

• Maximum Lease Time: 7200
• Server state: disabled
• Server IPv6 address: fd00:238a:6500:b::1/64
— If using non-default addresses, the user may specify only the upper 64
bits (that is, the /64 prefix). The least-significant 64 bits must be ::1.
The client address will always have the same upper 64 bits as the
server and have a least-significant 64 bits of ::2.
• Client IPv6 address: fd00:238a:6500:b::2/64
• Gateway IPv6 address (as seen by craft PC): the link-local address of the
LAN-16/42 port. This value is visible from within Site Manager Comms
Setting Management/Services/LinkLocal.
• Preferred lifetime: 600 seconds
• Valid lifetime: 600 seconds
Note: Certain newer versions of macOS may not work with the IPv6
DHCP server when connected to the craft port. In this case, it is suggested
to use IPv4 DHCP to access the craft port.
In SP/CTM redundant configurations, both LAN-15 and LAN-16 or LAN-41

and LAN-42 Craft ports can be provisioned but only the active SP/CTM will
take the craft provisioning. The standby SP/CTM always uses the default
setting. For example, assume the LAN-15 port IP address is provisioned as
10.0.0.9 and the LAN-16 port IP address is provisioned as 10.0.0.13. If the SP
in slot 15 of a 14-slot shelf is active, the LAN-15 port IP address is 10.0.0.9
and the LAN-16 port IP address is the default IP (for example, 10.0.0.5). If the
SP in slot 16 of a 14-slot shelf is active, the LAN-16 port IP address is
10.0.0.13 and the LAN-15 port IP address is the default IP (for example,
10.0.0.1).

IPv4 external DCN connectivity

Connectivity of the 6500 network element (NE) to an external DCN is typically
through the COLAN interface (10/100Base-T-RJ-45) located on the access
panel (AP).
6500 supports two basic DCN models, a public IP address model and a
Private-IP address model. The following sections provide general information
about these basic DCN models. Subsequent sections provide general
provisioning guidance and examples of DCN configurations.
General DCN network design considerations

Best practices
The 6500 supports some common routing functions, such as OSPF, to
support both external (‘north-south’) and internal (‘east-west’) communication
requirements. This allows it to be integrated into a variety of network
configurations. However, since the 6500 is not a commercial router, prudent
network designs should aim to minimize the impact on 6500 resources (such
as memory and CPU). Consideration should be given to both static factors (for
example, engineering guidelines regarding recommended maximums) and
dynamic factors (for example, network stability), and should account for
network growth.
Ciena recommends a highly segmented OAM network design, which offers

the advantages of minimizing resource consumption, minimizing scope of
impact of failures, and can lead to more ‘cookie-cutter’ planning and
deployment.
The information below outlines strategies that can be used.
Minimize overall OSPF load

If using OSPF GNEs:
• If using an OSPF backbone:
– Designate external (non-6500) routers as the ABRs
– Minimize the number of ABRs
– Minimize the number of Type-3 LSAs advertised by ABRs by
implementing Type-3 LSA filtering on those ABRs.
• Minimize route information advertised from external DCN into 6500.
Typically, only a default route is required to reach external destinations (for
example, management subnets, RADIUS server, NTP server, etc.)
Segment the OSPF network: reduce area size, avoid use of an OSPF
backbone, implement non-OSPF boundary sites using iISIS (for routing) and
SLDD (for AR/TR distribution).

Minimize the number Type-11 LSAs, and the AR and TR records contained
therein. Since Type-11 LSAs have AS-wide flooding scope, reduced OSPF
area size and use of SLDD at area boundary sites is a recommended
approach. OOLFC may also be used to reduce Type-11 LSA count in
all-OSPF configurations. In some cases, OOLFC can be used in conjunction
with SLDD.
Minimize churn
Consider churn from external destinations which could impact 6500, for
example through OSPF flooding.
Minimize the ‘impact radius’ of failures. Strategies such as reduced area size,
network segmentation and route filtering can help to reduce the impact of
failures in one area, such as flapping links, on other areas.
Address failures promptly.
Internal Communications Requirements

In determining the appropriate external DCN connectivity model for a specific
6500 deployment, it is important to consider both the NMS-to-NE
communications requirements (‘north/south’) and the internal NE
communications requirements (‘east/west’). The following sections provide
some details on the internal communications requirements that can factor into
these design decisions in some cases.
Address Resolution (AR) and Topology Resolution (TR)

In addition to providing IPv4 visibility within a Photonic network, OSPFv2 is
also used to transport Address Resolution (AR) and Topology Resolution (TR)
records via Type-11 opaque LSAs, as discussed in “Opaque LSAs” on
page 1-130. AR and TR records support applications such as Domain Optical
Control (DOC).
The general scope requirements for both AR and TR are site and domain:
• Shelves within a given site, determined by the Site-ID parameter, require
each other’s AR and TR records.
• Shelves within a given Photonic domain, determined by the OSID
parameter, require each other’s AR and TR records.
It is important to consider these requirements in the context of possible

network failures, such as fiber breaks, and with respect to overall user
requirements. In this regard, the following points apply:
• TR records provide units of topology information on which larger
topological views of the network are built.
• To delete channels from a Photonic domain, the topology for that domain
is required.

• Disruptions to OSPF, such as during failures, can lead to an inability to

refresh TR and AR records. If not refreshed, these records timeout
approximately one hour after such a failure.
• This has implications if there is a requirement to re-route channels due to
a failure. Depending on how re-routing is initiated (see below), this can
drive additional requirements into the DCN design.
Wavelength re-routing
If the L0 Photonic Control Plane is used to re-route wavelengths, re-routing is
initiated autonomously and completes before topology times-out. It is
recommended to use the L0 Photonic Control Plane for wavelength re-routing.
If re-routing is initiated manually, such as through PWSM Wavelength Service

Restoration, topology may time-out before wavelength re-routing is initiated
and therefore channel deletion may fail. This scenario may be mitigated
through DCN design, as discussed below.
DCN design for manual wavelength re-routing during failures

To maintain topology in the presence of certain failures, a diverse OSPF
flooding path is required.
In networks with OOLFC enabled, the scope of opaque LSAs is necessarily

restricted to allow for scale, and therefore a diverse flooding path through the
external DCN will generally be required. The following requirements for that
approach apply:
• An OSPF GNE configuration is used.
• Opaque LSAs are enabled on the OSPF circuits connecting the GNEs to
the external DCN (typically using COLAN).
• A path for opaque LSAs exists through the external DCN. This can be
provided using one of the following methods:
— A resilient non-backbone OSPF area, such that no failure in the area
can cause the area to become partitioned.
— A contiguous OSPF backbone. External DCN routers must support
and allow flooding of opaque LSAs.
— An intra-area OSPF circuit over a GRE tunnel between external DCN
routers. The routers supporting the GRE endpoints must support and
allow flooding of opaque LSAs. Refer to Figure 1-8 on page 1-81.
The chosen method must survive the failure.
If not using an OSPF GNE configuration (that is, for ARP, Private IP, NAT, DCN
Drop configurations), it is not possible to provide a diverse OSPF flooding path
through the external DCN.

Figure 1-8
Use of GRE tunnels with intra-area OSPF for diverse flooding

COLAN use for external DCN connectivity

The following points clarify some aspects of COLAN usage for external DCN
connectivity:
• Redundant NAT, proxy ARP GNE, and single-public-IP configurations are
only supported on COLAN-X.
• In other GNE configurations, such as private-IP and OSPF, COLAN-X and
COLAN-A can be used together for redundant access to/from the external
DCN, but must be in different subnets. If only one interface is used, it is
recommended to use COLAN-X.
Note: COLAN-A is not supported as a Private-IP interface, and therefore
should not be connected to the external DCN. However, it can be used as
an unnumbered link for internal (6500-to-6500) connectivity.
Stretched spans
Normally OSC is used to carry Photonic communications traffic between sites
due to its relatively high bandwidth and low latency, and this is the
recommended method whenever available. However, in some applications,
such as submarine, the large distances and associated fiber losses mean that
OSC cannot be used due to link budget exhaustion. These are referred to as
‘stretched spans’. In stretched spans, it is recommended to use a
high-bandwidth GCC0 channel, such as that provided by 100G circuit packs,
as an alternative to OSC. This helps to minimize latency versus, for example,
using a communications path through the external DCN which could have
larger and/or more variable latency. It is also recommended to limit the
number of nodes communicating across the link by making the stretched span
a single-section domain and limiting the number of amplifiers in the domain
that contains the stretch span. Contact Ciena for assistance.
Whenever possible, it is recommended that more than one channel across the
stretched span be configured with the GCC0 workaround for redundancy.
OSPF costs of the GCC0 links and within the Photonic network should be
carefully engineered to avoid internal traffic traversing the external DCN or the
use of the lower bandwidth GCC0 link for customer DCN traffic under normal
operating conditions. GNE placement with respect to the stretched span
should also be considered to limit the number of nodes that may be isolated
under a fiber cut scenario.
First channel turn-up and recovery from fiber cuts need to be performed
manually. The workaround only applies to one stretched span per optical path
and there must be only one stretched span in the link.

Stretched spans with SLDD/IISIS

If stretched spans exist in a network that is segmented from an OSPF
perspective, such as when using SLDD and IISIS, consideration must be
given to the location of the circuit packs providing GCC across the span. The
context below focuses on submarine deployments, as this is a common
stretched span application.
For DOC to operate across the stretched span, the shelves with the DOC
instances require IP visibility and AR/TR of each other and every device
between them in the domain, implying they must be in the same OSPF area.
Since SLDD and IISIS are used to provide a seam from an OSPF perspective,
it is necessary for the circuit packs providing GCC across the span to exist on
the same ‘side’ of the SLDD/IISIS seam. It is recommended, and in many
cases necessary, that the circuit packs providing GCC be in the same shelf as
the SLTE OTS. Figure 1-9 on page 1-83, illustrates such a configuration.
Figure 1-9
Stretched span with SLDD/IISIS
SLTE OTS
OSPF
iISIS
SLDD/IISIS
GCC0
Legend
COLAN-X
COLAN-A
ILAN-IN/ILAN-1
ILAN-OUT/ILAN-2

IPv4 external DCN connectivity—Public IP address model

In the Public IP address model, all nodes have a unique IP address,
addressable from the DCN.
The following configurations are supported in the public IP address model:

• non-redundant
— individual LAN drops to each shelf from external DCN
— static routing to/from external DCN
— standalone ARP GNE
— standalone OSPF GNE
• redundant
— redundant NAT GNEs
— redundant ARP GNEs
— redundant OSPF GNEs
Examples of these configurations can be found in the “DCN design examples”

on page 1-153 section.
NAT can be used on the gateway network element to translate between

internal Private-IP addresses and external public IP addresses in which case
a tunnel is not required. For further information, see “DCN design examples”
on page 1-153. NAT is only supported on OneControl 3.0 and above. Note
that although the NAT GNE configuration uses Private-IP addresses for the
shelves within the network, each shelf requires public IP addresses
(DCN-visible) allocated and therefore this configuration is considered to be a
public model.

IPv4 external DCN connectivity—Private-IP address model

In the Private-IP address model, only the GNE COLAN interfaces are
assigned DCN-routable IP addresses. The GNE shelf-IP address and all the
RNEs can be assigned non-DCN-routable IP addresses. Management
operations to and from RNEs is achieved using a combination of application
gateways and Reverse Port NAT (Network Address Translation).
Private-IP has the following advantages:

• Reduces the number of required public DCN-routable IP addresses:
Requires only one public IP address per GNE.
• Simplifies DCN interworking by avoiding the need to run a routing protocol
on the COLAN interface(s).
• Increases security: Remote 6500 NEs reside on a Private-IP network
which is separate from the Customer DCN.
• Both standalone and redundant configurations are supported.
• IISIS or OSPF can be used in the private network in the same way as other
configurations such as Redundant NAT.
For Private-IP GNE, however, there are engineering limits on the number of
RNEs that can be supported due to the additional processing required on the
GNE for TL1 Gateway, RPNAT and NAPT. Refer to the “DCN engineering
guidelines” on page 1-404 for more information on these limits, and to “TIDc
member shelf GNE support” on page 1-91 for a mitigation strategy.
A 2-slot shelf is not recommended as a Private-IP GNE. Contact Ciena if you

require a 2-slot shelf to be configured as a Private-IP GNE. A 2-slot shelf may
act as an RNE in a Private-IP configuration.

The use of Private-IP changes the management of IP based RNEs in the

network such that:
• External IP DCN to RNE management access is either through
— TL1 Gateway, as provided by the TL1 Gateway feature. This is the
recommended TL-1 access method in a Private-IP configuration. For
more information on TL1 Gateway, refer to “TL1 Gateway” on
page 1-89.
— Reverse port NAT. This is where specific TCP/UDP ports on the GNE
map to a specific RNE and service on that RNE. RPNAT can be used
to provide access to non-TL-1-based services, such as SAOS-based
CLI and SNMP access for eMOTR circuit packs, and Ciena technical
support access to debug interfaces.
— a two hop procedure for support if Reverse Port NAT is not configured.
This involves accessing the GNE using SSH/Telnet, then using Telnet
to the desired RNE.
• Internal IP RNE to DCN access, such as for load delivery and
backup/restore operations, is handled using Network Address Port
Translation (NAPT) on the GNE.
With Private-IP, public DCN and private 6500 network routing information is
not shared. Though the internal address space within the private network is
private, this space must not overlap with any address space in the DCN. This
is because packets within the private network need to be sent to the DCN,
based on the DCN IP addresses. Separate Private-IP networks can have
overlapping address spaces.
Configuring a GNE and subtending RNEs into a Private-IP configuration

involves:
• setting up the GNE mode as Private-IP
• configuring the desired gateway services on the GNE
• provisioning Private-IP address on each NE
• if using RADIUS authentication, configuring the GNEs to point to the
external RADIUS servers, and configuring the RNEs to point to the
RADIUS proxy on the GNE(s)
In 6500, each GNE needs to be configured with one or more static routes to
the external DCN, which in turn need to be redistributed into the internal
OSPF or IISIS network to provide DCN reachability to the RNEs. This allows
the RNEs to originate connections and send packets to the DCN IP
addresses.

RADIUS gateway
When using RADIUS, RNE login authentication is provided by the RADIUS
client on the RNE which accesses the DCN RADIUS servers via the RADIUS
gateway on the GNE, which acts as a proxy.
RADIUS clients on RNEs are configured to point to the GNE(s). Generally any
access to the GNEs within the Private-IP network should be using the
Private-IP addresses.
Reverse Port NAT

Reverse Port NAT provides the ability to map TCP/UDP ports on the GNE
COLAN interface on the customer DCN to specific ports for the same protocol
on RNEs in the private network, in order to facilitate external DCN access to
the RNEs (ports disabled by default).
Reverse Port NAT DCN ports must be configured in the range of

NATBASEPORT + 2050 to NATBASEPORT + 4099. The default and
recommended value for NATBASEPORT is 50000. With this value, DCN ports
must therefore fall in the range of 52050 to 54099. The NATBASEPORT value
is user-provisionable. If changed from the default value of 50000, it is
recommended that NATBASEPORT is not set to a value less than 5000 to
avoid potential overlap with internally reserved ports.
The NAT Starting Port (NATBASEPORT) parameter value is provisioned

using the Comms Setting Management application in the Configuration
menu of Site Manager (for details, refer to:
• for D-Series and S-Series shelves
— Procedure 2-2, “Editing the communications settings”
— Table 2-50 on page 2-99
• for T-Series shelves
— Procedure 3-2, “Editing the communications settings”
— Table 3-35 on page 3-71
Dynamic port ranges (ED-NAT) should not overlap with other local GNE port.
Private-IP supports FTP client, FTP server, active and passive FTP, SFTP,
SNMP, SSH, Telnet, HTTP, CLI, and Secure HTTP (via mapping of Public IP
address and port to Private-IP address).
The 6500 FTP server supports both passive and active FTP. However, the
client only supports active FTP. Load deliveries, backups and restores use the
FTP client.

For SNMP and SAOS-based CLI access to eMOTR circuit packs on RNEs,
Reverse Port NAT entries must be added to map unique GNE ports to the
appropriate service ports on the RNEs. For SNMP, this is UDP port 161. For
SAOS-based CLI, this is port 10010 or 10020 for Telnet, or port 20002 for
SSH. For consolidated nodes (TIDc) containing eMOTR circuit packs,
Reverse Port NAT entries are only required for access to the primary shelf of
the TIDc, since access to eMOTR circuit packs on member shelves is
provided through SNMP proxy and CLI proxy functions on the primary shelf.
Ports that are present in the Reverse Port NAT table can be detected by port
scanning software.
Table 1-12 shows the ports that can be added to the Reverse Port NAT table
on a Private-IP GNE.
Table 1-12
Reverse Port NAT ports
Remote NE Port Remote NE Service Protocol

21 FTP (Note) TCP
22 SSH TCP
23 Telnet TCP
80 HTTP TCP
161 SNMP UDP
443 secure HTTP TCP
1010 remote debug access by Ciena (WinShell) TCP
3083 TL-1 over Telnet (no echo) TCP
8888, 8889 remote debug access by Ciena (MCEMON) TCP
10001 OneControl management access to 6500 TCP
10010 CLI TCP
10020 CLI TCP
28888 SSH port for remote debug access by Ciena TCP
20000 SSH port used by OneControl to manage 6500 TCP
20001 SSH port used by OneControl to manage 6500 TCP

20002 SSH port for CLI TCP
Note: Only if using external FTP client to access RNEs (not needed for load
deliveries or backup and restore operations).

Port filtering
For further details on port filtering, refer to “Provisionable port filtering” on
page 1-388.
TL1 Gateway
The TL1 Gateway applies to the 6500 network GNE. This feature provides a
TL-1 connectivity abstraction layer for customer initiated TL-1 connections to
network elements that subtend a 6500 GNE.
TL1 Gateway is not supported in IPv6.
TL1 Gateway functionality is not recommended on 2-slot shelves.
The TL1 Gateway removes the need to have multiple and individual
connectivity to each local or remote node to be managed by the Operations
System (OS or OSS). The gateway provides TL-1 session multiplexing where
multiple TL-1 sessions between a TL1 Gateway NE and an RNE (Remote
Network Element) can be multiplexed into a single TL-1 session between OS
and TL1 Gateway NE.
The OSI and IP TL1 Gateways facilitate TL-1 connectivity from an IP-based
Customer DCN to third-party OSI based network elements or 6500 network
elements subtending the 6500 TL1 Gateway. You can then perform one or
multiple simultaneous TL-1 logins to subtending third-party OSI based
network elements or subtending 6500 network elements via Telnet from the
DCN into the 6500 TL1 Gateway.
The TL1 Gateway feature supports the two flavors described below.
OSI TL1 Gateway

The OSI TL1 Gateway facilitates TL-1 connectivity from an IP based
Customer DCN to third-party OSI based network elements subtending the
6500 GNE. Via Telnet from the DCN into the 6500 GNE, the Customer can
then perform one or multiple simultaneous TL-1 logins to subtending
third-party OSI based network elements. See Figure 1-10 on page 1-90.
For non-Ciena third-party network elements, there may not be an entry in the
TARP data cache. A third-party NE that sends out a TARP type IV message
will be in the TARP data cache, but if the TL1 Gateway NE restarts, the TARP
data cache will be empty. In this case, the first TL-1 command sent to that NE
will be denied and the TL1 Gateway will send a TARP request to fill its TARP
data cache.
If the network element is in the network and responds to the TARP request,
the next TL-1 command will complete as expected.

ATTENTION
TARP on the 6500 only supports upper-case TIDs. For example, TARP would
interpret OTTAWA and Ottawa to be the same TID. If mixed-case TIDs are
provisioned, unexpected results will occur.
IP TL1 Gateway
The IP TL1 Gateway facilitates TL-1 connectivity from an IP based Customer
DCN to 6500 or CPL (Release 5.0 and above) network elements subtending
the 6500 GNE. Via Telnet from the DCN into the 6500 GNE, the customer can
then perform one or multiple simultaneous TL-1 logins to any subtending 6500
or CPL network elements. See Figure 1-11 on page 1-91.
In each case, it is possible to have multiple Telnet sessions to the GNE, then
for each Telnet session, the user can perform multiple ACT-USERs to the
RNE. Note that in order for different users (accounts) to reach the same RNE,
separate Telnet sessions will be needed. Only one user can be supported per
Telnet.
Figure 1-10
6500 OSI TL1 Gateway
OS T-TD NE
TL1/TCP - TL1/OSI
TL1 Translation Function TL1
Initiator Responder
TL1 Initiator
and responder
TCP/IP TCP/IP OSI OSI

stack stack stack stack
TCP connection OSI connection
TCP/IP network OSI network

Figure 1-11
6500 IP TL1 Gateway
OS T-TD NE
TL1 TL1 Initiator TL1

Initiator and responder Responder
TCP/IP TCP/IP TCP/IP TCP/IP

stack stack stack stack
TCP connection TCP connection
TCP/IP network TCP/IP network
TIDc member shelf GNE support

6500 supports Private-IP GNE, including TL1 Gateway, on both TIDc primary
and member shelves. This flexibility helps to simplify network design by
facilitating a more “cookie-cutter” approach to GNE placement and allowing
more GNEs to be deployed to keep fan-out numbers (that is, the number of
RNEs subtending a given GNE pair) within engineering guidelines. For
example, at a Photonic ROADM TIDc, each shelf facing a Photonic line,
whether TIDc primary or member, could act as a GNE for subtending NEs
within that line.
Member shelf GNE support can also help to off load processing from the TIDc
primary shelf, which retains responsibility for managing the TID from a TL-1
perspective (all TL-1 to the TID is managed by the TIDc primary shelf).
Figure 1-12 on page 1-92 illustrates a simple example where a member shelf
GNE is used in a ROADM TIDc.

Figure 1-12
TIDc member as GNE
COLAN-X with public IP

connected to DCN drop
ROADM 1
ILAN ring G R R
Legend
= ROADM site with consolidated TID
G = TIDC member shelf GNE
P = TIDC primary shelf
M = TIDC member shelf
R = Remote NE
Additional flexibility is achieved in that a TIDc member shelf could be

'promoted' to a GNE/TL1 Gateway to provide management access for a new
subnet without impacting the existing shelves.
To create a new subnet from a TIDc node, the following steps would need to
be followed:
• provision one of the member shelves as a GNE
• add a DCN drop to the GNE COLAN-X interface
• add the subtending RNEs to the GNEs span of control
The RNEs can then be managed using the TL1 Gateway function through the
newly promoted member/GNE shelf.

TL1 Gateway provisioning

The Site Manager Node Information application (TL1 Gateway sub-tab) or
ED-TL1GW TL-1 command is used to enable/disable the TL1 Gateway
functions via the Gateway Network Element (GNE) and Remote Network
Element (RNE) attributes, as described below:
• the GNE attribute specifies if the TL1 Gateway function is enabled or
disabled. If enabled, the node can forward TL-1 to a remote node; if
disabled, the node cannot act as a gateway to another node.
• the RNE attribute specifies if the node accepts TL-1 sessions from a TL1
Gateway or not. If disabled, port 3081, used for accepting the TL-1
sessions, is closed.
For more information on TL-1 commands, see TL-1 Description,

323-1851-190.
The following section describes the various combinations of settings for the
above attributes as it applies to a TIDc member shelf.
• GNE=ENABLED, RNE=ENABLED
— ACT-USER command to the TID of the TIDc will login the user into the
primary shelf.
— Since the RNE function is enabled, this node can act as an RNE as
well.
• GNE=DISABLED, RNE=ENABLED
— This setting disables the TL1 Gateway forwarding function and can be
used to get local access to a TIDc member shelf. Note that all the
RNEs managed through this GNE shelf will go into the LOA state.
— Since the RNE function is enabled, this node can act as an RNE.
• GNE=ENABLED, RNE=DISABLED
— ACT-USER command to the TID of the TIDc will login the user into the
primary shelf.
— Since the RNE function is disabled, this node cannot act as an RNE.
• GNE=DISABLED, RNE=DISABLED (default setting)
— This setting disables the TL1 Gateway forwarding function and can be
used to get local access to a TIDc member shelf. Note that all the
RNEs managed through this GNE shelf will go into the LOA state.
— Since the RNE function is disabled, this node cannot act as an RNE.

Note that the default setting of both the “GNE” and “RNE” parameters is
DISABLED. In a public-IP GNE configuration, where TL1 Gateway is not used,
the defaults can be left as-is. In a Private-IP system where TL1 Gateway is
used, Table 1-13 on page 1-94 shows the minimum functions which must be
enabled for the various roles a shelf may have in order to provide full access
to all shelves in the network.
Table 1-13
GNE and RNE attribute minimum requirements in a private-IP system
Shelf role GNE attribute RNE attribute
Shelf is GNE and TIDc member Enabled Enabled
Shelf is non-GNE and TIDc member X X
Shelf is TIDc primary X Enabled
Shelf is RNE (not TIDc or GNE) X Enabled
Note: X = Do not care
Engineering considerations
• GNE/TL1 Gateway must be a Photonics shelf
• refer to “TID consolidation (TIDc)” on page 1-107 and “Consolidated node
engineering guidelines” on page 1-109 for more specific limits on TIDc
and Private-IP GNE configurations.
OneControl considerations for Private-IP GNE configurations

If OneControl is used for management of a 6500 network which is in either a
single- or dual-GNE private-IP configuration, the following requirements must
be met:
• Starting in 6500 Release 8.0 (corresponding with Optical Solution
Release (OSR) 18.0), it was necessary to configure a subnet name (GNE
subnet or reporting subnet) on each shelf in a Private-IP/TL1 Gateway
system. As of 6500 Release 10.05 and OneControl Release 4.1, if
OneControl is configured to support asymmetric spans-of-control, subnet
names are not required and any existing subnet names carried over from
previous releases are ignored.
• In general, in dual-GNE Private-IP configurations, it is recommended to
make spans of control symmetrical for simplicity. In other words, each
GNE has the same set of RNEs and the opposite GNE in its span of
control list. To address specific network configurations, spans of control
may also be asymmetrical. However, a given NE can only exist in a
maximum of two, i.e. managed via two Private-IP GNEs. An example of
asymmetric spans of control is given in Figure 1-13 on page 1-95.

• On each GNE, the NE list (span-of-control list) must be configured to

include all RNEs and the other GNE (if present).
• A single public IP address is supported per GNE. It is recommended that
the COLAN-X interface is used as this public interface.
In a dual-GNE configuration, OneControl load shares between the two GNEs

based on the routing cost (referred to as “reachability metric” in Site Manager)
retrieved in the NE-list (span-of-control list), using the GNE with lowest cost
path to reach each RNE.
For more information, refer to the OneControl documentation suite,

450-3241-xxx.
Figure 1-13
Example of asymmetric spans of control
GNE-1 RNE-A RNE-B RNE-C GNE-2
RNE-D
RNE-E
GNE-3
GNE-1 span of control = RNE-A, RNE-B, RNE-C, RNE-D, RNE-E, GNE-2

GNE-2 span of control = RNE-A, RNE-B, RNE-C, GNE-3
GNE-3 span of control = RNE-D, RNE-E, GNE-1

IPv6 external DCN connectivity

GNE configurations
6500 supports the following IPv6 GNE configurations: statically routed, ND
Proxy and OSPFv3. In addition to these ‘gateway’ configurations, each shelf
can also be directly connected to the external DCN, sometimes referred to as
a ‘DCN drop’ configuration. The GNE configurations are described below:
• Static route—One or more static routes are configured on the DCN router
pointing to the subnet (generally a /64) containing the shelf IP addresses,
with the GNE COLAN interface as the next hop. Likewise, one or more
static routes are configured on the GNE shelf pointing to the next-hop
DCN router, and redistributed into the internal routing domain (OSPF).
Assigning the shelf IP addresses from the same subnet simplifies the
provisioning of the static routes on the DCN router considerably.
• ND Proxy—This GNE configuration operates similarly to the IPv4 Proxy
ARP configuration. It requires the shelf IP addresses of the RNEs to be
assigned from the same subnet as the GNE COLAN interface connected
to the DCN. The GNE will respond to Neighbor Solicitation requests on
behalf of the RNEs and then forward traffic to those RNEs. For the egress
direction, one or more static routes are configured on the GNE and
redistributed into the internal 6500 routing domain.
Note that unlike the IPv4 Proxy ARP configuration where it was necessary
to set the ‘ARP Proxy’ parameter on the IP interface, with ND Proxy this is
not necessary. Provisioning ND Proxy entries will enable this functionality.
• OSPFv3 GNE—This configuration uses OSPFv3 on the COLAN
interface(s) to exchange routing information with DCN routers. This
solution provides the best resiliency, as OSPF will automatically route
around failures at the IP layer.
Exclusions
These GNE configurations are not supported in IPv6:
• Private-IP
• Redundant NAT
• Redundant ARP
Note: IPv6 ND proxy is equivalent to Standalone Proxy ARP in IPv4.

General DCN provisioning rules

This section provides general information about provisioning the DCN
parameters on a 6500 network element. The parameters are provisioned
using the Comms Setting Management application in the Configuration
menu of Site Manager (for related procedures and parameter information,
refer to Chapter 2, “Comms setting management procedures for D-Series and
S-Series” and Chapter 3, “Comms setting management procedures for
T-Series”). Procedures associated with the provisioning of the DCN
parameters are also included in the Nodal SLAT Assistant Tool (SAT) available
in the Tools menu of Site Manager.
The provisioning of DCN parameters is dependent on whether the 6500 is a

gateway or a non-gateway network element. For a gateway network element,
additional parameters must be provisioned associated with the connection to
the external DCN. “DCN design examples” on page 1-153 provides example
DCN configurations and associated provisioning details.
In redundant configurations, the GNEs configurations should generally match.

For example, if one GNE is NAT, the other also must be NAT (cannot be
Private-IP, OSPF, ARP, etc.)
The actual parameters that must be configured depend on the DCN

configuration (for example parameters, refer to “DCN design examples” on
page 1-153).
OSPF or IISIS can be used as the internal routing protocol for 6500 network
elements. However, Photonic applications (for example, DOC) and TID
consolidation require that OSPF be used as the internal routing protocol. IISIS
can be used on DCC/GCC to provide data communications to remote OSI
network elements.
When using OSPF on the DCC/GCC channels, topology auto-discovery does

not function across the DCC/GCC channels. Auto-discovery does function
For systems with Photonic equipment, the OSC channel can be set up to
provide data communication between 6500 sites as Photonic applications
require it. GCC/DCC channels are not usually used. However in certain
scenarios such as Single Stretch Spans (SSS) they can be required. Refer to
“Stretched spans” on page 1-82 and “Stretched spans with SLDD/IISIS” on
page 1-83 for more information on stretched spans. If OSI is required for a
remote network element (for example, OM 3000), IISIS can be set up on a
DCC.

IPv4 route redistribution and summarization

Route redistribution is used to redistribute routes from one routing domain to
another, or to redistribute static routes into a routing domain. It is controlled by
adding route redistribution entries into the appropriate IISIS or OSPF router.
These entries control what routes are redistributed into this routing domain.
The redistribution entry consists of an IP address, mask, metric and metric
type. The IP address and mask combine to filter which route entries will be
distributed in the destination routing domain.
If redistributing into OSPF, the metric-type parameter is not used. Routes are
always redistributed as type-1 external LSAs (internal metric is considered in
determining the cost to external destinations).
If redistributing into IISIS, the metric-type parameter is used. Internal means

that the internal metric will be included in determining the cost to external
destinations. External means that the internal metric is not included. Only the
external metric is used. Note that 6500 redistributes external destinations into
IISIS from static routes or from OSPF using a TLV (type-length-value) of 130.
Route summarization may be used in conjunction with route redistribution to

allow the redistributed routes to be summarized. This helps to minimize the
size of the routing tables in that routing domain. Route summarization is either
on or off. When on, if any routes match the redistribution entry, a route is
installed which is equal to the redistribution entry itself.
Table 1-14 on page 1-99 illustrates an example of how routes are redistributed
from routing-domain 1 to routing-domain 2 using the redistribution entry at a
router in domain 2. Two cases are shown, one with route summarization off,
one with summarization on. The redistribution entry (1.0.0.0/8) specifies that
the first octet must be '1'.
When summarization is off, routes with a first octet of '1' are distributed into
routing domain 2 as-is. When summarization is on, the presence of any route
in routing domain 1 with a first octet of '1' results in the distribution of the
summarized route 1.0.0.0/8 into domain 2.

Table 1-14
Route Summarization
Route Summarization = OFF Route Summarization = ON
IP address Mask IP address Mask
Routing-domain 1 10.10.10.0 255.255.255.0 10.10.10.0 255.255.255.0
5.5.0.0 255.255.0.0 5.5.0.0 255.255.0.0
1.2.3.4 255.255.255.255 1.2.3.4 255.255.255.255
1.3.4.0 255.255.255.0 1.3.4.0 255.255.255.0
1.16.0.0 255.255.0.0 1.16.0.0 255.255.0.0
Domain 2 redistribution 1.0.0.0 255.0.0.0 1.0.0.0 255.0.0.0

entry (RDENTRY)
Routing-domain 2 1.2.3.4 255.255.255.255 1.0.0.0 255.0.0.0
1.3.4.0 255.255.255.0
1.16.0.0 255.255.0.0
Note that a redistribution entry of 0.0.0.0/0.0.0.0 may be used to redistribute

a default route (0.0.0.0/0.0.0.0). For redistribution to occur, there must be an
exact match (that is, default route must exist in the domain from which routes
are redistributed). It does not result in all routes redistributed, as was the case
in previous 6500 releases.

IPv6 route redistribution

IPv6 redistribution provisioning
In IPv6, the model for specifying redistribution of static routes into OSPFv3
differs from that on D-Series/S-Series shelves in the IPv4 space.
In IPv4 on D-Series/S-Series shelves, static routes and redistributions are

provisioned separately, with the latter being done as part of the router
provisioning, (for example, OSPF RD entry). In IPv6, redistribution of a static
route into OSPFv3, if required, is specified when the static route is
provisioned. The metric type (internal/Type-1 or external/Type-2) is specified,
and the cost of the static route is used as the metric in the redistribution. Refer
to Figure 1-14 on page 1-100 for an example which shows the redistribution
fields. There is no explicit step to set the OSPFv3 router as an ASBR
(Autonomous System Boundary Router). If redistribution is enabled, the
OSPFv3 router is automatically set as an ASBR.
Figure 1-14
Add IPv6 Static Route dialog box

IPv6 route redistribution behavior

There are some differences in how routes are redistributed into OSPF in
OSPFv3 (IPv6). These are described below:
• A given static route with redistribution enabled results in that route being
redistributed.
• A less-specific IP/prefix with redistribution enabled may also cause a
match on more-specific IP/prefixes that do not have redistribution enabled,
and cause the latter to be redistributed as well. These have the metric-type
and metric of the less-specific IP/prefix entry.
• OSPFv3 supports origination and handling of both Type-1 and Type-2
metric types in AS-external (Type-5) LSAs.
Examples are shown in Table 1-15 on page 1-101.
Table 1-15
IPv6 route redistribution examples
Static route(s) Redistribution entry Redistributed route(s)
2620:10b:d058::/48 OSPFv3 2620:10b:d058::/48
2620:10b:d058::/48 OFF 2607:f8b0:400d:c02::/64

2607:f8b0:400d:c02::/64 OSPFv3
2620:10b:d058::/48 OSPFv3 2620:10b:d058::/48

2607:f8b0:400d:c02::/64 OSPFv3 2607:f8b0:400d:c02::/64
::/0 OSPFv3 ::/0
2620:10b:d058:f83a::1/128 OFF 2620:10b:d058:f83a::1/128

::/0 OSPFv3 ::/0
2620:10b:d058:f83a::1/128 OFF 2620:10b:d058:f83a::1/128

2620:10b:abcd:efef::/64 OFF 2620:10b:abcd:efef::/64
2620::/16 OSPFv3 2620::0/16

Provisioning the DCN parameters

The sequence for provisioning the DCN parameters on a gateway network
element is:
1 If the network element is a gateway network element (GNE), provision the
GNE configuration.
— Select the Interfaces tab and select GNE as the Interface type.
Possible configurations are:
— Standalone STATIC
— Standalone and Redundant ARP
— Standalone and Redundant NAT
Note: 2-slot shelves are not recommended as a NAT GNEs. Contact
Ciena if you require a 2-slot shelf to be configured as a NAT GNE.
— Standalone and Redundant OSPF
— Standalone and Redundant Private-IP
Note: A 2-slot shelf is not recommended as a Private-IP GNE. Contact
Ciena if you require a 2-slot shelf to be configured as a Private-IP GNE.
A 2-slot shelf may act as an RNE in a Private-IP configuration.
2 Provision the SHELF IP address.
Select the Interfaces tab and select IP as the Interface type. Provision
the appropriate information for the SHELF IP (see “6500 network element
(NE) IPv4 addressing” on page 1-37).
3 Provision the IISIS or OSPF router.
If using IISIS as the internal routing protocol or if the shelf will connect to
an OSI-managed network element, provision the IISIS router.
— Select the Routers tab and select IISIS Router as the Router type.
Add the IISIS router and route redistribution (see “IISIS router (IPv4
only)” on page 1-45).
If using OSPF as the internal routing protocol or using OSPF between
gateway and external DCN, provision the OSPF router.
— Select the Routers tab and select OSPF Router as the Router type.
Add an OSPF router and route redistribution (see “OSPFv2 router (for
IPv4)” on page 1-50).

4 Set up ports to allow communication channel between 6500 sites.

If the system contains Photonic equipment, provision the OSC. All other
communication channels (DCC/GCC) must be disabled.
— The Auto OSC/OSPF Provisioning parameter in the Site Manager
Node information application System sub-tab (or ED-SYS TL-1
command and the OSCMODE parameter) defines whether the OSC
will be provisioned or not when the SFP on the RLA modules (T-Series
shelf only), SRA, SAM, ESAM, 2xOSC, and SPAP-2 w/2xOSC circuit
packs is provisioned. By default, when the OSC autoprovisions, the
associated OSPF circuit is autoprovisioned in Area 0.0.0.0, and the
OSPF router autoprovisions if it does not already exist.
If the system does not contain Photonic equipment, provision the
DCC/GCC (on
OCn/STMn/STMnJ/OTM1/OTM2/OTM3/OTM4/OTMC2/OTM ports).
— Select the Interfaces tab and select Lower Layer DCC/GCC as the
Interface type. Add the appropriate DCC/GCC (section/RS, line/MS,
or GCC0/GCC1) and the protocol (LAPD, PPP, or Transparent) for the
associated
OCn/STMn/STMnJ/OTM1/OTM2/OTM3/OTM4/OTMC2/OTM port
(see “Lower layer DCC implementation rules” on page 1-17). If you
choose the Transparent protocol, you must specify the mate DCC.
5 Provision ILAN ports (if required).
Select the Interfaces tab and select LAN as the Interface type. Enable
the appropriate ILAN port (see “LAN ports” on page 1-9).
the appropriate information for the ILAN port (see “6500 network element
(NE) IPv4 addressing” on page 1-37).

6 Provision the IISIS or OSPF circuits against each comms port provisioned
on the network element.
If using IISIS as the internal routing protocol or if the comms port will
connect to an OSI-managed network element, provision the IISIS circuits.
— Select the Routers tab and select IISIS Circuit as the Router type.
Add an IISIS circuit to each comms port provisioned on the network
element that requires IISIS routing (COLAN, ILAN, SHELF,
OC-n/STM-n DCC ports, OTM1/OTM2/OTM3/OTM4/OTMC2/OTM
GCC ports, and GRE tunnels) (see “IISIS circuits (IPv4 only)” on
page 1-46).
If using OSPF as the internal routing protocol or using OSPF between
gateway and external DCN, provision the OSPF circuit.
— Select the Routers tab and select OSPF Circuit as the Router type.
Add the OSPF circuit to each comms port provisioned on the network
element that requires OSPF routing (COLAN, OSC, ILAN, SHELF,
OC-n/STM-n DCC ports, and
OTM1/OTM2/OTM3/OTM4/OTMC2/OTM GCC ports) (see “OSPFv2
circuits (for IPv4)” on page 1-52).
The Auto OSC/OSPF Provisioning parameter in the Site Manager Node
information application System sub-tab (or ED-SYS TL-1 command and
the OSCMODE parameter) defines whether the OSC will be provisioned
or not when the SFP on the RLA modules (T-Series shelf only), SRA,
SAM, ESAM, 2xOSC, and SPAP-2 w/2xOSC circuit packs is provisioned.
By default, the OSC autoprovisions and the associated OSPF circuit is
autoprovisioned in Area 0.0.0.0.
7 Provision manual area addresses (MAA) (if interworking with other OSI
products using different MAAs).
Select the Routers tab and select Upper Layer DCC as the Router type.
Add/delete the necessary manual area addresses (see “Upper layer DCC
implementation rules (does not apply to T-Series shelves)” on page 1-30).
The 6500 has a default MAA of 490000. It is recommended that the default
MAA of 490000 is deleted if not required (you cannot delete it if it is the
only MAA).
8 Provision GRE tunnels (if using tunnels between gateway network
element and management system or between network elements).
Select the Interfaces tab and select GRE as the Interface type. Add the
OSI over IP or IP over OSI tunnels (GRE-IP-1 to 4, GRE-OSI-1 to 4) (see
“GRE” on page 1-69).

9 If the network element is a GNE, provision the COLAN port.

Select the Interfaces tab and select LAN as the Interface type. Enable
the appropriate COLAN port (COLAN-shelf#-X port recommended) (see
“LAN ports” on page 1-9).
the appropriate information for the COLAN port (see “6500 network
element (NE) IPv4 addressing” on page 1-37).
10 If the network element is a GNE, provision the IP static route (if using
Static routing between gateway and external DCN).
Select the Routers tab and select IP Static Route as the Router type.
Add a static route for the COLAN port (see “IP static route
(D-Series/S-Series shelf IPv4 only)” on page 1-56).
11 If the network element is a GNE, provision proxy ARP (if required).
Select the Interfaces tab and select ARP Proxy as the Interface type.
Add the proxy ARP address range (see “Proxy ARP” on page 1-427).
12 If the network element is a GNE, provision NAT (if required).
Select the Routers tab and select NAT as the Router type. Add a NAT
entry for each address that must be mapped from the external IP address
to the remote 6500 network element IP addresses.
13 If the network element is a GNE, provision Reverse Port NAT Provisioning
(if required).
Select the Routers tab and select Reverse Port NAT. Add a Reverse Port
NAT entry for each 6500 remote network element port that must be
mapped to a port on the GNE.
IPv6 planning and provisioning guidelines

Unnumbered interfaces are supported in both IPv4 and IPv6, but if both IPv4
and IPv6 are configured on a given interface, both must be either numbered
or unnumbered.
IPv6 is disabled by default. Therefore, the craft port on an unprovisioned

out-of-the-box 6500 shelf only supports IPv4 by default.
IPv6 can only be disabled on a shelf, and subsequently removed, if all IPv6
provisioning is removed first.

Differences compared to IPv4

This section outlines differences in 6500 provisioning and behavior in its IPv6
implementation compared to its IPv4 implementation:
• Index-based provisioning—6500 uses an index-based provisioning model
for certain IPv6 attributes. The index forms part of the access identifier
(AID). This approach provides more flexibility and facilitates
implementation of future functionality. This applies to provisioning of:
— IPv6 address
— IPv6 static routes
— ND Proxy entries
— OSPFv3 circuits
Note: OSPFv3 circuits also introduce an ‘instance’ parameter, but it is
not supported.
• Site Manager generally separates IPv4 and IPv6 parameters into separate
tabs on the respective Site Manager dialogs (for example, IP address,
OSPF router, OSPF circuits, static routes, GNE configuration, ARP Proxy,
and ARP table).

TID consolidation (TIDc)

Target identifier (TID) consolidation allows multiple shelves at a site to be
managed under the same TID (also referred to as Node name). Note that a
“site” refers to co-located shelves that have the same Site ID and which can
be daisy-chained together via LAN ports (typically ILAN).
TID consolidation reduces the number of TIDs and nodes to be managed in

the network. In a consolidated node, each shelf shares the same TID, but has
a unique logical shelf number. The logical shelf number is provisioned during
commissioning, and is contained in the access identifier (AID) for each shelf.
Both the TID and logical shelf number are required to target a shelf in a
consolidated node.
In a consolidated node, a single shelf is either a primary shelf or a member

shelf. The primary shelf represents the group of shelves in a consolidated
node. There can be only one primary shelf within a consolidated node. The
primary shelf is responsible for receiving and distributing all the TL-1
messages in the consolidated node. The primary shelf maintains the member
shelf list, member shelves time synchronization, and security features. A shelf
that does not belong to a consolidated node is referred to as a standalone
shelf (TID consolidation and Primary shelf parameters are set to disabled).
The primary shelf and the member shelves exchange information through the
lowest cost comms path, typically over ILAN-to-ILAN connections.
IISIS can be supported on the DCC/GCC channels in a TIDc. An ILAN

connection with OSI can be connected to a consolidated TIDc if required.
ATTENTION
6500 network elements must be de-enrolled from OneControl server before
TID consolidation is performed. For more information, refer to the “Network
management” chapter in the OneControl Unified Management System
Manager for 6k, OM5k and CPL Standard Operations Guide, 450-3241-301.
Refer to the “TID consolidation (TIDc)” section in chapter 4 of Administration

and Security, 323-1851-301, for more details and related procedures.

Comms within a consolidated node

In order for “consolidation” to succeed:
• A primary shelf must be provisioned for a TIDc.
• Each member Logical Shelf number must be unique within the
consolidated node.
• Each member shelf Node name (TID) must be the same as the primary
shelf Node name.
• Each member shelf Site ID must be the same as the primary shelf Site ID.
• Each member shelf must be assigned a SHELF IP address.
• Member shelves require bidirectional IP communication with the primary
shelf. This can be accomplished using OSPF, IISIS or static routing,
typically over point-to-point ILAN connections.
• The primary shelf requires AR (Address Resolution) records from the
member shelves. This requirement can be met either by configuring OSPF
to run between primary and member shelves, or by using Database
Replication Service (DBRS). Refer to the communications management
procedures in Chapter 2, “Comms setting management procedures for
D-Series and S-Series” and Chapter 3, “Comms setting management
procedures for T-Series”, “LAN ports” on page 1-9, and “Database
Replication Service (DBRS) (D-Series/S-Series shelf IPv4 only)” on
page 1-132.
• For a 2-slot shelf, if the COLAN is used as an ILAN port for TIDc
communications, opaque LSAs must be enabled (Opaque Link State
Advertisement must be set to On) on the OSPF circuit associated with
the COLAN port.
Gateway Network Element (GNE) for a consolidated node

In a consolidated node (TIDc), a single shelf is either a primary shelf or a
member shelf. The Primary shelf represents the group of shelves within a
TIDc. There can be only one Primary shelf within a TIDc. Therefore, the
Primary shelf is also configured as the GNE for the TIDc. All DCN comms
configurations are supported for the TIDc.
If a 2-slot shelf TIDc primary is also a GNE, only one LAN port is available to
connect to other shelves in the TIDc. As a result, the TIDc configuration will
not be fully redundant. Refer to the “Consolidated node engineering
guidelines” on page 1-109 for details on when a 2-slot shelf can act as the
primary shelf of a TIDc. This restriction does not apply to a 2-slot optical
Type 2 shelf equipped with an SPAP-2 w/2xOSC circuit pack.

Consolidated node engineering guidelines

The following are the TIDc engineering guidelines:
• All member shelves within a TIDc must be running the same release as
the primary shelf release.
• The types of shelves and processors in the TIDc determine which shelf
type and shelf processor variant/control and timing module (CTM) must
used for the primary shelf. Refer to Table 1-16 on page 1-111 for details.
• The following types of consolidated nodes are supported:
— 6500 D-Series/S-Series only
— mixed 6500 D-Series/S-Series and CPL
— 6500 T-Series only
— mixed 6500 D-Series/S-Series and 6500 T-Series
• A TIDc containing CPL Channel Access nodes (OADM) member shelves
is no longer supported and cannot be upgraded to Release 12.1 and
above.
• As of Release 12.1, a greenfield TIDc cannot have CPL Channel Access
nodes (OADM) member shelves.
• As of Release 12.1, mixed consolidated nodes with CPL member shelves
and primary shelves equipped with an SPAP-2 w/2xOSC shelf processor
are no longer supported.
• Refer to Table 1-17 on page 1-112 for engineering guidelines regarding
the maximum number of member shelves.
• 6500 shelves equipped with eMOTR circuit packs can be part of a TIDc.
— If eMOTR circuit packs are used in member shelves of a TIDc, the
SNMP Enhanced Proxy must be set to On. For steps, refer to the
“Enabling or disabling the SNMP agent and the SNMP proxy”
procedure in Fault Management - SNMP, 323-1851-740. For more
information on the SNMP proxy, refer to the “SNMP proxy” section in
Fault Management - SNMP, 323-1851-740.
• 6500 shelves equipped with PKT/OTN cross-connect circuit packs can be
part of a TIDc.
• TIDc requires IPv4 and IPv4-based AR records. However, IPv6 (on
D-Series/S-Series shelves) may be overlaid on TIDc nodes for
north-south management communications if required.
For further details on IPv6, refer to “IPv6 external DCN connectivity” on
page 1-96. IPv6 is not supported on T-Series shelves.

• Control Plane considerations:

— For D-Series/S-Series shelves, multiple OSRP instances are
supported on a consolidated node (TIDc) with:
– one Photonic OSRP instance on the primary shelf.
– one (or more) SONET/SDH OSRP instances on member shelves.
– one (or more) OTN OSRP instances on member shelves.
Note: A SONET/SDH OSRP instance and OTN OSRP instance cannot
reside on the same member shelf.
— For T-Series shelves, multiple OSRP instances are supported on the
same shelf: Photonic OSRP and OTN OSRP. This also applies to
T-Series shelves within a TIDc. Note that within a TIDc, there can only
be one Photonic OSRP and/or one (or more) OTN OSRP instance.
— Following an edit of the Control IP address on the primary shelf, all
member shelves of the TIDc must also be restarted. Otherwise, an
OSRP “Remote Node Unreachable” alarms can be raised against
OSRP links passing through these member shelves.
— A shelf that has Coherent Select provisioning enabled cannot be
TID-consolidated with a shelf provisioned with a Photonic OSRP
instance. For details on Coherent Select configurations, including
provisioning information, refer to WaveLogic Photonics Coherent
Select, 323-1851-980. Coherent Select is not supported on T-Series
shelves.
— For Photonic systems running the Photonic L0 Control Plane, OBM
everywhere can only be enabled (by setting the Autoroute OTS
parameter to Disabled) on consolidated nodes. Refer to the “OTS
Management” chapter in Part 1 of Configuration - Provisioning and
Operating, 323-1851-310/Configuration - Provisioning and Operating
for T-Series, 323-1851-311; and the 6500 Packet-Optical Platform
Photonic Layer Guide, NTRN15DA, for further details.
— In public-IP GNE configurations, the following guidelines apply:
– If there is a single GNE in the TIDc, the primary shelf should be
GNE.
– For scalability reasons, it may be advantageous to have multiple
GNEs per TIDc in some Photonic networks. The primary shelf
should act as GNE for the TIDc. Member shelves may be GNEs for
the nodes in the Photonic lines which the members face.

Table 1-16
Supported TIDc member shelf types
Shelf processor variant of PECs Supported TIDc member shelf types
primary shelf
SP-2 • NTK555CAE5 • all D-Series/S-Series shelf types using any

• NTK555EAE5 supported shelf processor variant
• NTK555FAE5 • CPL shelf, except Channel Access nodes (OADM).

For CPL mixed TIDc engineering guidelines, refer to
the Common Photonic Layer Planning Guide,
NTT840FV
SPAP (Note) NTK555LA • 6500 2-slot shelf with integrated SP

• 6500 2-slot optical Type 2 shelf equipped with SPAP
2-slot shelf with integrated SP • NTK503MAE5 • 6500 2-slot shelf with integrated SP
(Note) • NTK503NAE5 • 6500 2-slot optical Type 2 shelf equipped with SPAP
SPAP-2 w/2xOSC • NTK555NA • 6500 2-slot

• NTK555NB • 6500 2-slot optical Type 2
• 6500 7-slot optical Type 2
CTM • NTK710AAE5 • T-Series shelf

• NTK710ABE5 • all D-Series/S-Series shelf types and all shelf
processor variants
Note: If the primary shelf is also a GNE, only one LAN port is available to connect to other shelves in
the TIDc. As a result, this TIDc configuration is not fully redundant.

Table 1-17
TIDc maximum number of shelves
TIDc configuration Primary shelf Engineering considerations

D-Series/S-Series Refer to Table 1-16 on Maximum of 36 shelves if SP-2 is equipped on the
only page 1-111 primary shelf. Otherwise, maximum of 16 shelves.
6500 T-Series only T-Series Maximum of 36 shelves.
Mixed T-Series Maximum of 36 shelves.

D-Series/S-Series
and T-Series
Mixed 6500 and CPL Refer to Table 1-16 on • Maximum of 36 shelves if SP-2 is equipped on the
page 1-111 primary shelf. Maximum of 16 shelves if SPAP-2 is
equipped on the primary shelf.
• The primary shelf requires a combined 6500 and CPL
network element software load.
• Only Transponder and Photonic services are
supported.
• MSPP cross-connect circuit packs are not supported.
• Integrated ISIS (IISIS) is not supported on CPL.
Therefore, if DBRS runs between 6500 and CPL
shelves within a TIDc, static routes must be used to
provide IP connectivity within the TIDc. Static routes
do not provide routing redundancy.
Note: Mixed consolidated nodes that include CPL
Channel Access node (OADM) member shelves are not
supported.

When selecting the primary shelf of a TIDc, it is recommended that:

• If the site must contain a GNE, the primary shelf is chosen as the GNE.
• When there are different types of 6500 shelves, choose the primary shelf
based on the following order:
— a 6500 shelf equipped with an SP-2 circuit pack is preferred over a
shelf equipped with a non-SP-2 shelf processor.
— 6500 shelf with no Photonic circuit packs and only Transponder circuit
packs.
— 6500 shelf with MSPP cross-connect circuit packs.
— 6500 shelf with Photonic circuit packs with no DOC instances.
— 6500 shelf with Photonic circuit packs with DOC instances.
• Since Optical Bandwidth Manager (OBM) only runs on the primary shelf
of a consolidated TID, it is recommended that all new Photonic shelves
running Release 5.0 or higher use TID consolidation even if the site
contains only one shelf. A valid configuration for a single-shelf TID is to
enable TIDc and designate the single shelf as primary.
• When a NE is removed from the TIDc configuration, the TOD server
should be re-provisioned to the server IP for the network. Otherwise, the
NE can not synchronize with the TOD server.
• Pre-Release 5.0 sites upgraded to Release 5.0 or higher need to be TID
consolidated if Photonic equipment/shelves are added to the site.

OSC for shelf interconnect (TIDc over OSC)

Description
The OSC for shelf-interconnect capability provides a way to interconnect
shelves at a site when Ethernet connections (for example, ILAN-to-ILAN)
cannot be used because the distance between shelves is too large. Rather
than use external copper-to-fiber converters, direct OSC-to-OSC connections
can be used.
This capability can be used for shelves that are TID consolidated, or for
shelves in separate TIDs but at the same site (for example, for SPLI).
Configuration
This configuration requires a dedicated pair of fibers to connect each pair of
OSC ports. The OSC port is not part of an OTS (optical transport section).
From a data communications perspective, each OSC port is configured as it
would be when used in a traditional optical line application (that is, part of an
OTS) in that it is unnumbered and requires an OSPF circuit.
Short-reach CWDM SFPs are supported for this application.
Engineering guidelines
The following are the OSC for shelf interconnect engineering guidelines:
• The OSC for shelf-interconnect capability is supported on 2xOSC and
SPAP2 w/2xOSC circuit packs only.
• Up to three ports on a given shelf are supported for shelf-interconnect
purposes.
• The NTTP04BF and NTTP04CF SFPs are recommended for this purpose,
since they are intended for short-reach applications. However, other SFP
variants supported by the 2xOSC and SPAP-2 w/2xOSC circuit packs can
also be used, but may require padding/attenuation to avoid overloading
the pluggable Rx interface.
• Compared to ILAN, the following features are not supported on the OSC:
IISIS, DBRS, SLDD, OOLFC, numbered interfaces.

SONET/SDH, OTN, and Photonic Control Plane considerations

Optical Signaling and Routing Protocol (OSRP) is the set of protocols and
algorithms used by the SONET/SDH Control Plane, OTN Control Plane, and
Photonic Control Plane. OSRP instances provisioned on 6500 nodes must be
able to communicate to perform their functions. Only in-band communications
between OSRP instances is supported for the SONET/SDH and OTN Control
Plane. In-band and Out-of-band communications are supported for the
Photonic Control Plane.
More details and diagrams on SONET/SDH Control Plane, OTN Control

Plane, and Photonic Control Plane can be found in the Control Plane
Application Guide, NTRN71AA.
This section describes the data communications considerations of the

SONET/SDH Control Plane, OTN Control Plane, and Photonic Control Plane.
In-band communications for SONET/SDH Control Plane

For in-band communication between OSRP instances, each facility on which
SONET/SDH Control Plane is enabled requires the Line DCC channel to be
allocated for control plane communications (neighbor discovery, topology
discovery, routing and signaling). This LDCC channel requires the following
parameters and settings:
• Carrier = Line (SONET)/Multiplex Section (SDH)
• Network domain = SONETCP
• Protocol = LAPD
• L2 frame size = 9000
No additional provisioning, such as IP address or OSPF/IISIS circuits, is

required on the LDCC channel for OSRP communications.
If OAM communications are also required between shelves containing OSRP

instances, the Section DCC (SDCC) channel must be used (Netdomain =
MCN), as Control Plane and OAM communications do not share the same
channel. This is supported for OC-48/STM-16 and OC-192/STM-64 facilities.

In-band communications for OTN Control Plane

For in-band communication between OSRP instances, each facility on which
OTN Control Plane is enabled requires the GCC channel to be allocated for
control plane communications (neighbor discovery, topology discovery,
routing and signaling). This GCC channel requires the following parameters
and settings:
• Carrier = GCC1 or GCC2
• Network domain = OTNCP

required on the GCC channel for OSRP communications.

instances, the GCC0 or GCC1 channel must be used (Netdomain = MCN), as
Control Plane and OAM communications do not share the same channel.
GCC1 can be used for either Control Plane communications or management
communications (OAM), but not both. GCC2 can only be used for Control
Plane communications.
Note: When GCC1 and GCC2 are used for OTN control plane,
RTRV-LLSDCC always shows the OPER_CARRIER as
DISCONNECTED. This is different than GCC0 and GCC1 in the MCN
domain, which shows “GCC0” and “GCC1”, respectively, if the link is UP.
Photonic Control Plane data communications

The OSRP instance for the Photonic Control Plane runs on the auxiliary
processor of the SP-2 circuit pack in the primary shelf of a consolidated node
(TIDc). In 6500-based Photonic networks with OSC, neighboring OSRP
instances communicate using in-band (IB) “peer-to-peer” messaging over the
OSC. In some cases, out-of-band (OOB) messaging may be required.
Out-of-band messaging in this context is defined as messaging over an
arbitrary IP infrastructure. Refer to “Out-of-band communications for Photonic
Control Plane” on page 1-117 for details on OOB communications.
Prior to Release 12.1, a control-IP address was required in most cases for
communications between the TIDc primary shelf and member shelves. As of
Release 12.1, the control-IP is only required for OOB OSRP communications.

Out-of-band communications for Photonic Control Plane

In some configurations, in-band messaging between OSRP instances across
the OSC is not possible and out-of-band (OOB) messaging is used. In this
context, OOB messaging implies that messages are routed arbitrarily over the
IP infrastructure. These OOB configurations include:
• A Photonic line that has a Release 12.0 (and above) CPL ROADM shelf at
one or both ends, as CPL does not support in-band OSRP messaging.
Refer to Figure 1-17 on page 1-124. Note that a CPL-based DGE or line
amplifier in a 6500-based ROADM line is able to pass in-band OSRP
traffic between the 6500 ROADM shelves.
• Stretched-span configurations where GCC is used for inter-site
communications rather than OSC.
• Submarine configurations where GCC is used for inter-site
communications.
For spans where OOB messaging is required, a control IP address must be

provisioned at each end of the span.
Detailed provisioning information and guidelines for the control IP address are
given below:
• The control IP address is a host address (/32) that is distinct from the
SHELF IP address but can otherwise be treated similarly. It has an AID of:
CONTROL-shelf#-GROUP0.
• The control IP is provisioned on the primary shelf of a TIDc.
— A warm restart of CPU2 on the active SP-2 Dual CPU circuit pack
(NTK555FAE5) is required to activate changes in the control IP
provisioning.
— The control IP requires an OSPF circuit and requires that the
Autonomous System Border Router parameter be set to ON for the
OSPF router. For details, refer to:
– For D-Series and S-Series shelves: Table 2-10 on page 2-50 and
Table 2-11 on page 2-52
– For T-Series shelves: Table 3-6 on page 3-32

Figure 1-15
OOB configuration example: Photonic line with Release 12.0 (and above) CPL ROADM shelf at
one end
Primary Primary
Out-of-band OSRP
messaging
CPL
TID-1 TID-2
Domain/Area A
Legend
COLAN-X/1
6500 ROADM shelf
COLAN-A
ILAN-IN
CPL ROADM shelf
ILAN-OUT

PKT/OTN cross-connect circuit pack and CTM communications

considerations
Packet services are configured through the SAOS-based CLI on the PKT/OTN
cross-connect circuit pack or Control and timing module (CTM). This
SAOS-based CLI can be accessed by:
• using Site Manager to start a SAOS-based CLI session. For further
details, refer to the “Starting a SAOS-based CLI session using Site
Manager” procedure in the “Command line interface” chapter of
Administration and Security, 323-1851-301.
• telnetting to the shelf processor. For further details, refer to the
“SAOS-based CLI” section in the “Command line interface” chapter of
Administration and Security, 323-1851-301.
• using a control IP address allocated to the PKT/OTN cross-connect circuit
pack or CTM. The control IP address is a host address that is distinct from
the shelf IP address but can otherwise be treated similarly. It has an AID
of: CONTROL-shelf#-GROUP1. This access method is further described
in the sections below.
Access to the control IP is supported in the following public-IP GNE

configurations only:
• standalone ARP
• redundant OSPF
Refer to the SAOS-based Packet Services Command Reference,

323-1851-610, for detailed information on SAOS-based CLI commands used
to provision Layer 2 services on the PKT/OTN cross-connect circuit pack or
CTM.
Accessing the PKT/OTN cross-connect circuit pack from the Craft port
The SAOS-based CLI on the PKT/OTN cross-connect circuit pack can be
accessed from the Craft interface port by specifying the control IP address as
the destination. The default control IP address is 169.254.46.146, but is
overwritten by the public IP address that is assigned when commissioned.
If the control IP address is changed, all open SAOS-based CLI sessions to the
PKT/OTN cross-connect circuit pack will hang and eventually timeout. A new
SAOS-based CLI session must be started following a change in the control IP
address. Ensure all configuration data is saved prior to editing the control IP
address. Failure to do so may result in loss of unsaved configuration data.

Accessing the SAOS-based CLI from the Craft interface port of the active shelf
processor also requires:
• HOSTONLY must be provisioned to OFF on the Craft port of the active
shelf processor. For further details, refer to the “Provisioning craft access”
procedure in Commissioning and Testing, 323-1851-221.
• the device used for login must be on the same subnet as the Craft port
(control IP address does not need to be on the same subnet).
• the user first opens a TL-1 session by specifying the Craft port IP address
as the destination. This login session must remain actively connected until
the next step is completed.
• the user then opens a SAOS-based CLI session using Telnet or SSH login
(using the same userID) by specifying the control IP address as the
destination.
To use SSH to log into the SAOS-based CLI through the Craft interface, the
CLI SSH server must be set up to accept the login client IP address (using the
ssh server add command). For syntax and usage of the ssh server add
command, refer to the SAOS-based Packet Services Command Reference,
323-1851-610.

Redundant OSPF configuration with multiple OSPF areas (Photonics

only)
A Multiple Area configuration is recommended for networks that are already,
or are expected to grow, to greater than 100 NEs.
Note that when setting up Multiple Area configurations, inter-area routing

occurs through the backbone (area 0.0.0.0).
Large networks
For a network with more than 32 Photonic or Broadband shelves, with
redundant OSPF DCN with multiple areas, it is recommended to use an
external router for ABR, area summarization, route aggregation, and filtering
as needed to allow the network to scale. See Figure 1-17 on page 1-124.
In the example shown the DCN router as the ABR (Area Border Router) can
be set up to:
• Filter routes advertised from backbone into non-backbone area.
• Use Summarization to reduce the number of LSA advertised into the
backbone and/or use summarization to reduce the number of LSAs
advertised into the internal 6500 comms network.
The interconnection of area C, area B, and area A at DCN router R2 is an

example of 3-way branching. Figure 1-18 on page 1-125 provides an example
of detailed connectivity at a 3-way branching site.
ATTENTION
When you are setting up a multiple OSPF configuration, set the OSCMODE
(parameter of the ED-SYS) command to DISABLED (default value is OSPF).
Otherwise, equipping/insertion of an OSC circuit pack will cause OSPF
circuits to be automatically created in area 0.0.0.0 and this can result in an
isolated area 0.0.0.0 and can cause loss of comms.
Small networks
For a network with less than 32 Photonic or Broadband shelves, with
redundant OSPF DCN with multiple areas, you can use the ABR feature built
into the 6500 at area boundaries. See Figure 1-16 on page 1-123.
The 6500 shelves that have OSPF circuits provisioned in more than one area,
behave as ABRs, provided they have at least one interface that is configured
to be in area 0.0.0.0 (backbone area).

Each 6500 OSPF area needs to be a resilient comms network. This will allow
for area aggregation to be provisioned on the ABRs at a later date when this
feature becomes available (area aggregation may be used to reduce routing
table and LSA database size).
Connectivity at 3-way Branch Site

For details of connectivity at 3-way branch site, see Figure 1-18 on
page 1-125.
At a 3-way branch site COLAN is used to connect the NE to the customer DCN
Router (in some earlier releases it may be necessary to use the ILAN, instead
of the COLAN to connect to the DCN router; this is because opaque LSAs
were used to pass internal data and opaque LSAs were blocked form COLAN.
This is now provisionable).
ILANs are used to interconnect NEs at each of the branch sites.

Figure 1-16
Redundant OSPF configuration with multiple OSPF areas (Photonics)
Customer DCN
OSPF area 0.0.0.0
(backbone)
COLAN
connections to
Customer DCN
in area 0.0.0.0
(backbone)
6500 6500
Shelf Shelf
6500
Shelf
TIDC
6500 6500 6500 6500
Shelf Shelf Shelf Shelf
6500
6500 Shelf 6500
Shelf Shelf
6500 6500
6500 ILAN Shelf
Shelf OSPF in 6500 Shelf
6500 Shelf
area
Shelf
0.0.0.0
(backbone)
OSPF area 0.0.0.2 OSPF area 0.0.0.3 OSPF area 0.0.0.4
Each area needs ILAN

to be single interconnects
resilient comms provisioned with
network OSPF circuits in
area 0.0.0.0
Redundant
connections to OSC OSC
backbone - to OTS OTS
guard against
isolated area Shelf 1
0.0.0.0 in case of
COLAN failure
Same
TID
LEGEND
Shelf 2
= COLAN
= ILAN in area 0.0.0.0 Shelf 3
= Comms OSPF connection can be Shelf 4
ILAN, OSC or DCC/GCC

Figure 1-17
Redundant OSPF configuration with multiple OSPF area configuration at a 3-way branching site
Router ports configured Area aggregation and

to be in same OSPF route filtering can be
area as COLAN to configured on customer
which they are attached ABRs to minimize
information flow
Customer DCN
OSPF area 0.0.0.0
R4
R1
R2 R3
6500
Customer
Shelf
routers are
6500 DOC 2 6500 ABRs
Shelf OSPF Area B Shelf
6500
6500 6500 Shelf
Shelf Shelf
DOC 3
6500 6500
OSPF Area C
Shelf Shelf
6500
Shelf 6500 6500
Shelf Shelf
6500 6500
6500 Shelf DOC 1 Shelf
interconnected OSPF Area A
via OSPF circuits
6500 6500
Shelf Shelf

Figure 1-18
Connectivity at 3-way branch site
DOC 2
>2 6500
OSPF Area B
CP
L
X
L
0C CP
65
X X
X
65
0C
65
0C
65
0C
65
0C DOC 3
X X
2 6500
X X OSPF Area C
X X
0C CP
L
X 65
X
DOC 1
1 6500
Customer DCN
OSPF Area A
Router R2
IPv6 configurations
6500 provides support for the following network deployments:
• Homogeneous IPv4 deployments
• Homogeneous IPv6 deployments.
• Mixed IPv4/IPv6 deployments.
See Figure 1-20 on page 1-127 for an example of a homogeneous IPv6

configuration. Note this configuration assumes that IPv4 is not required, but
as noted in the “IPv6 exclusions” on page 1-126, some applications do not
support IPv6. Therefore, use of those applications necessitates deployment
of IPv4 for 6500-internal communications. However, IPv6 can be used in this
situation for north-south management communications (that is, OneControl,
RADIUS authentication, Time of Day synchronization, etc.) Refer to
Figure 1-19 on page 1-126 for a pictorial representation of IPv6 in this type of
model.

IPv6 exclusions
The following features and functions are not supported on 6500 with IPv6:
• Consolidated nodes (TIDc): IPv6/OSPFv3 can be overlaid for north/south
management communications, but TIDc still requires IPv4/OSPFv2.
• Photonics
Figure 1-19
IPv6 for north-south communications, with IPv4 for internal communications
See Figure 1-21 on page 1-128 and Figure 1-22 on page 1-129 for high-level
examples of mixed IPv4/IPv6 configurations. Figure 1-21 on page 1-128
shows how an IPv6 ring could be added into an existing IPv4 deployment.
Figure 1-22 on page 1-129 shows how an IPv6 shelf could be added to an
existing IPv4 ring. Also refer to “Migration from IPv4 to IPv6” on page 1-420
for a high-level description of the steps to migrate a network from IPv4 to IPv6.

Figure 1-20
Homogeneous IPv6 deployment with redundant GNEs

Figure 1-21
Augment of existing IPv4 configuration with new IPv6 ring

Figure 1-22
Augment of existing IPv4 ring with new IPv6 shelf

Opaque LSAs
This section gives a brief background on OSPF Opaque Link State
Advertisement (LSA) to assist with the understanding of the sections that
follow.
Opaque LSAs are described in RFC2370. There are three types of opaque
LSAs: types 9, 10 and 11, each of which has a different flooding scope. This
section focuses on Type-11 LSAs, as they are used by the 6500 and CPL.
OSPF Type-11 opaque LSAs are flooded throughout the AS by OSPF. Their
flooding scope is equivalent to the AS-External (type 5) LSA.
The 6500 and CPL use Type-11 opaque LSAs for distributing Address
Resolution (AR) and Topology Resolution (TR) records (one record per LSA).
AR and TR records are used by various applications including Photonics (for
example, Domain Optical Control), Service-Photonic Layer Interoperability,
and others (for example, Private-IP span of control) to determine the network
addresses and topology information. This information is stored in databases
on the 6500 and CPL shelves after being exchanged by OSPF.
Opaque LSAs are an OSPFv2 feature. They do not apply to OSPFv3, and
therefore associated mechanisms to manage opaque LSA flooding (DBRS,
OOLFC) do not apply to OSPFv3.
Also, since AR and TR information are flooded using opaque LSAs, any
applications that require AR (such as TIDc, SPLI, and Photonics) require
OSPFv2 to be provisioned.
Refer to “OSPF” on page 1-427 for more information on OSPF.
OSPF Opaque Link State Advertisement parameter

Although Type-11 LSAs normally have AS-wide scope, to allow the flooding of
those opaque LSAs to be controlled, 6500 and CPL have the ability to disable
flooding of these opaque LSAs on certain Ethernet interfaces on both 6500
and CPL using the Opaque Link State Advertisement parameter associated
with the OSPF circuit. For parameter details, refer to:
• for D-Series and S-Series shelves: Table 2-8 on page 2-45 and Table 2-9
on page 2-48
• for T-Series shelves: Table 3-6 on page 3-32

The possible opaque LSA flooding scopes that can be created are defined
below:
• OSPF autonomous system-wide: Opaque LSAs are flooded throughout
the OSPF autonomous system (AS). The OSPF AS could be a single area
or hierarchical with multiple OSPF areas connected via a backbone. This
is the normal scope of a Type-11 opaque LSA.
• Disabled at GNEs: With this solution, the GNEs do not flood opaque LSAs
on the interfaces connected to the customer DCN. This only applies to
configurations in which an OSPF GNE solution (standalone or redundant)
is used. For other GNE solutions, there is no flooding of any kind of OSPF
LSAs to the customer DCN since OSPF is not used.
DCN scalability and opaque LSAs

The following sections provide information on features that can be used in
larger networks to help manage system resources used by address and
topology resolution records (AR and TR). These features include Database
Replication Service (DBRS) (D-Series/S-Series shelf IPv4 only), and OSPF
Opaque LSA flooding Control (OOLFC, IPv4 only).
Opaque LSA engineering guidelines

The maximum number of opaque LSAs for non-SP-2 is 1200. The maximum
number of opaque LSAs for SP-2/CTM is 1600 (only supported if entire OSPF
network is SP-2/CTM).
Note that:
• There is one AR record per shelf.
• There is one TR record per channel access OTS (Optical Transport
Section) per NE.
• There is one TR record for each pair of amplifier OTSes per NE
• One Type-11 opaque LSA is used for each AR and TR record. For
example, if a shelf has a single channel access OTS, there would be two
Type-11 opaque LSAs: one for the AR record and one for the TR record.

Database Replication Service (DBRS) (D-Series/S-Series shelf IPv4 only)
ATTENTION
The following discussion purposefully avoids using the term OSPF AS
(autonomous system) in the context of DBRS. The generic term “OSPF
network” is henceforth used in the DBRS context to describe a contiguous
OSPF network, consisting of network elements and routers, in which opaque
LSAs are flooded using OSPF.
An OSPF network:
• may or may not correspond to an OSPF autonomous system.
• can describe a single OSPF area or a hierarchical OSPF network
including a backbone area (0.0.0.0)
• may or may not include customer DCN equipment depending on whether
opaque LSAs are enabled on the interfaces connected to the customer
DCN (as described above).
To comply with network engineering guidelines related to scalability and limit

NE resource consumption, it may be necessary for NEs and routers to be
segmented into different OSPF networks so that IP routing LSAs are not
shared.
To support Photonic applications across separate OSPF networks, a method

for exchanging only the AR/TR information between them is required. DBRS
provides a mechanism for passing AR/TR records between nodes in separate
adjacent OSPF networks and triggering the flooding of this information
through opaque LSAs within DBRS-connected networks. This is shown in
Figure 1-23 on page 1-133.
Each 6500 and CPL shelf generates one AR record. Each channel access
OTS generates one TR record. Each pair of amplifier OTSes generates one
TR record.

Figure 1-23
AR/TR exchange between adjacent OSPF networks
AR/TR exchange AR/TR exchange
Network-1 Network-2 Network-3
DBRS DBRS DBRS DBRS

Gateway Gateway Gateway Gateway
Adjacent OSPF networks Adjacent OSPF networks
network-1 contains network-2 contains network-3 contains

records from: records from: records from:
network-1 network-1 network-2
network-2 network-2 network-3
network-3
The DBRS connection point between two OSPF networks is referred to as the
DBRS gateway. A DBRS gateway exchanges its own AR/TR data with the
adjacent DBRS gateway. A DBRS gateway does not exchange AR/TR data
that originated from another DBRS gateway.
DBRS configuration
DBRS can be configured on 6500 and CPL equipment. DBRS can only be
configured to run between network elements. The network elements must be
in different domains (i.e. different OSID). All network elements in the same
domain/OSID must be in the same OSPF network. Optical directions
contained within the same 6500 shelf must be in the same OSPF network.
DBRS is supported between 6500 and CPL Release 5.0 and above.
Engineering guidelines of both products must be considered, and if
differences exist, the lower/more restrictive values must be used.
DBRS is supported over ILAN and COLAN links. A typical configuration uses
ILAN-to-ILAN links between DBRS gateways.

The exchange of AR and TR records over a DBRS link may be

enabled/disabled as follows:
• AR only
• AR and TR. TR cannot be enabled separately because the topology
applications depend on AR data.
Typically, AR and TR would be enabled in a 6500 or CPL network.
As DBRS is used between OSPF networks, OSPF does not run on a

DBRS-enabled link. DBRS does not impose any restrictions on which OSPF
areas should or should not be present in adjacent networks. Since the
networks remain independent from an OSPF perspective, the same areas can
exist in adjacent networks.
6500 GCC/DCC channels that cross between OSPF networks must not share
OSPF data between the networks. Either the GCC/DCC must be disabled or
IISIS used but not redistributed into OSPF.
DBRS DCN design considerations

DCN design needs to consider the following when DBRS is used:
• IP routing between DBRS gateways
• DBRS connection redundancy between neighbor OSPF networks
• scope of AR/TR information exchange
• engineering guidelines
• engineering considerations
IP routing between DBRS gateways

OSPF is not configured on DBRS gateway LAN links since the intent is to keep
OSPF networks separate with respect to IP routing information.
Communications between the SHELF IP addresses of the DBRS gateway

network elements is required for proper operation of the Photonics
applications and TIDc.
Routing between the DBRS gateway SHELF IPs can be achieved using either
static routes or IISIS.
• 6500 supports both static routes and IISIS.
• CPL supports static routing only

If a consolidated node (TIDc) is connected with numbered interfaces and

static routes are used to provide the IP connectivity, additional static routes
may be required to provide visibility of the numbered interfaces across a
DBRS boundary. This is due to the fact that some applications use the
address of the egress interface as the source IP address, not the SHELF IP
address. Therefore, it is recommended to use unnumbered interfaces to
connect the shelves at the TIDc.
DBRS redundancy
A maximum of two DBRS links can be configured between any two given
OSPF networks in order to provide redundancy for the exchange of AR and
TR records. The following redundancy configurations are supported, as
shown in Figure 1-24 on page 1-135 and Figure 1-25 on page 1-136:
• link redundancy, where two links connect a pair of DBRS gateway shelves.
This provides protection against a single link failure, but not an NE failure.
• NE redundancy, where two NEs in each OSPF network are DBRS
enabled, and they connect to two NEs in another network. This provides
protection against a link failure and an NE failure.
Figure 1-24
Link redundancy
Redundant DBRS-enabled links - same NE
Network-1 Network-2
DBRS DBRS
Gateway Gateway

Figure 1-25
NE redundancy
Redundant DBRS-enabled links - different NEs
DBRS DBRS
Network-1 Gateway Gateway Network-2
DBRS DBRS
Gateway Gateway
Scope of AR/TR information exchange

DBRS shares AR and TR records between adjacent networks only, an OSPF
network which is connected to multiple neighboring networks using DBRS will
contain the AR/TR records from all those networks.
For example, in Figure 1-23 on page 1-133, Network-2 would contain the
AR/TR records for Network-1, Network-2 and Network-3.
OSPF Network-1, on the other hand, would contain AR/TR records from only
Network-1 and Network-2. From a Photonic application perspective, this is
sufficient to be able to manage the services across Network-1 through
Network-2 to Network-3, since these applications require AR/TR from the
'next hop' network only.

DBRS engineering guidelines

Below are the DBRS engineering guidelines:
• When DBRS is used, it exchanges Type-11 opaque LSAs between
adjacent OSPF networks. Therefore, the opaque LSA count must include
both locally generated Type-11 opaque LSAs and those received from
adjacent OSPF systems.
• A maximum of three OSPF networks can meet at a Photonics branch point

using DBRS
• Maximum of two DBRS-enabled links between any two OSPF networks.
Note that the two networks can meet at more than two points, but DBRS
is only supported on a maximum of two of links.
DBRS engineering considerations

For SPLI operation, the service and Photonic shelves that are inter-operating
must be in the same OSPF network. For other requirements, contact Ciena
Systems and Network Engineering.
OSPF Opaque LSA flooding Control (OOLFC, IPv4 only)

Description
OSPF Opaque LSA Flooding Control (OOLFC) is one of a set of features that
can be used in larger networks to manage system resources used by Address
Resolution (AR) and Topology Resolution (TR) records, which are transported
by OSPF Type-11 opaque LSAs.
OOLFC is recommended for use in networks which there is one contiguous

OSPF scope with a large number of shelves and where engineering limits
regarding number of LSAs may be approached. These types of networks may
include those with OSPF GNEs connected to an external backbone, such as
that shown in Figure 1-26 on page 1-139, and also OSPF-based networks
that do not have an OSPF backbone, such as that shown in Figure 1-27 on
page 1-140.
When enabled, OOLFC filters Type-11 opaque LSAs containing AR and TR

on ingress, discarding all LSAs except those that meet “accept” criteria. The
accept criteria are based on siteID and OSPF area. LSAs that originate from
the same siteID or OSPF area as the recipient are accepted and handled
normally by OSPF. With respect to OSPF area, since any given shelf can
participate in more than one OSPF area, if any area on the receiving end
matches any area of the originating shelf, this criterion is met and the LSA is
accepted.
OOLFC allows filtering on all interfaces. Expanded interface support helps in

dense optical networks with multiple Photonic directions per shelf (for
example, single shelf sites where filtering on COLAN/ILAN may not be
possible).

Use of OOLFC is illustrated in Figure 1-26 on page 1-139 and Figure 1-27 on
page 1-140. Figure 1-26 on page 1-139 consists of an external OSPF
backbone area (0.0.0.0) and subtending non-backbone areas, with a single
Photonic domain per OSPF area. The external routers act as Area Border
Routers, as the COLAN-X ports on the 6500 GNEs are configured to be in
their respective non-backbone OSPF areas. The shelves at each site form a
consolidated node (TIDc). Since Type-11 opaque LSAs have an AS-wide
scope, all LSAs exist in the OSPF backbone. However, with OOLFC enabled
on the GNE shelves, LSAs not belonging to the siteID or OSPF area of the
GNE are discarded, thus reducing the number of LSAs in each non-backbone
area.
Figure 1-27 on page 1-140 illustrates a network consisting of two Photonic

domains, each in a single OSPF area (areas A and C), and a two-way ROADM
site (siteID 2) that has a third OSPF area (area B). The shelves at siteID 2 form
a TIDc. In this illustration, OSPF is not running on the COLAN ports connected
to the external DCN. With OOLFC enabled, filtering is active on the ILAN
interfaces of both shelves at siteID 2, so that only the Type-11 opaque LSAs
from siteID 2 area allowed into domains A and C. The Type-11 LSAs from
Domain/Area A do not reside in Domain/Area C, nor are Area C LSAs found
in Area A. This helps minimize the system resources used in each of these
domains.

Figure 1-26
Example network: OSPF GNEs connected to an external backbone
Area 0.0.0.0
ABR
ABR
ABR Accept = SiteID 3, Area B
COLAN interfaces are
Accept = SiteID 1, Area A
in their respective
non-backbone areas.
Accept = SiteID 2, Area B
Accept = SiteID 2, Area A
Domain/Area A Domain/Area B
SiteID 1 SiteID 2 SiteID 3
These shelves contain AR/TR of shelves in SiteID 1, These shelves contain AR/TR of shelves in SiteID 2,
Domain/Area A and SiteID 2, but not Domain/Area B Domain/Area B and SiteID 3, but not Domain/AreaA
or SiteID 3. or SiteID 1.
Legend
COLAN-X
6500 ROADM shelf Ingress OSPF filter on the respective
COLAN-A interface (that is, filtering is done
within the shelf).
ILAN-IN

Figure 1-27
Example network: OSPF-based networks that do not have an OSPF backbone
External DCN
Accept = SiteID 2, Area A, B Accept = SiteID 2, Area B, C
Domain/Area A Area B Domain/Area C
SiteID 2
These shelves contain AR/TR of shelves in These shelves contain AR/TR of shelves in
Domain/Area A and SiteID 2, but not Domain/Area C. Domain/Area C and SiteID 2, but not Domain/Area A.
Legend
COLAN-X
6500 ROADM shelf Ingress OSPF filter on the respective
COLAN-A interface (that is, filtering is done
within the shelf).
ILAN-IN
Configuration
OOLFC may be enabled on a per-shelf basis using the Opaque Filter
parameter associated with the OSPF router instance. OOLFC is enabled in
the OSPF router settings and supports two filtering modes: LAN-only (COLAN
and ILAN) and ALL (all interfaces). For parameter details, refer to:
• for D-Series and S-Series shelves: Table 2-8 on page 2-45 and Table 2-9
on page 2-48
• for T-Series shelves: Table 3-6 on page 3-32
If using OOLFC, all shelves in a network can have the feature enabled. The
feature may also be enabled only at strategic points in the network, such as
on the GNE shelves in Figure 1-26 on page 1-139.

Engineering considerations
In a given network, use of OOLFC is intended to be mutually exclusive with
DBRS. At the nodal level, it is not possible to enable OOLFC if DBRS is
already configured.
The accept criteria listed in the feature description are sufficient to satisfy the
requirements of all NE applications. However, the reduced scope of the AR
and TR records has some design considerations listed below:
• OOLFC effectively reduces the scope of the address and topology
information available on any given shelf. Some components of Site
Manager use this information and are affected as follows:
— The Visualization tool uses topology information as input. Therefore,
the scope of the visualization may be reduced as a result.
— The Login Dialog “Find” feature uses AR information to determine
visible nodes. The scope of visible nodes may be reduced as a result
of OOLFC.
• Private-IP GNEs use AR to define the span of control and to translate
TID-to-IP for TL1 Gateway connections to remote NEs. When designing
networks with Private-IP GNEs and OOLFC, the span of control cannot
include remote NEs that are outside the locally filtered AR scope.
• Prior to Release 12.0, OOLFC supported only OFF/ON settings. Starting
in Release 12.0, OOLFC supports OFF, ALL and LAN-only settings. Over
an upgrade from a release prior to Release 12.0 to Release 12.0 and
above, the settings are handled as described in Table 1-18 on page 1-141.
Table 1-18
OOLFC settings over upgrade to Release 12.0
Pre-release 12.0 setting Release 12.0 and above setting
OFF OFF
ON ALL

Site-Level Data Distribution (SLDD)

SLDD is a network scalability feature. Some 6500 applications rely on address
resolution (AR) and topology resolution (TR) records, which are natively
transported through a network using OSPF.
Large networks may require OSPF segmentation to manage system

resources.
SLDD can be used as a non-OSPF AR/TR data distribution mechanism within

a site. When used together with a non-OSPF routing protocol such as IISIS,
which provides the IP visibility within a site, OSPF networks can then be
segmented to allow for large scale.
The key attributes of SLDD are:

• provides a non-OSPF AR/TR transport mechanism which operates within
the scope of a site
• operates at Layer 3, but is independent of the routing layer
• enabled using a simple on/off switch. When enabled, applies to
ILAN-IN/OUT by default. Flexibility to handle alternate connectivity options
is provided through the ability to enable the feature on COLANs.
• requires a contiguous network of SLDD-enabled shelves at the site,
connected through SLDD-enabled interfaces (for example, ILAN/COLAN)
• resilient as long as site datacomms is resilient
SLDD considerations
The following are SLDD considerations:
• SLDD may be deployed at strategic locations to manage overall network
size. This is at the discretion of the network engineer, and should consider
network topology, OSPF engineering guidelines, and operational factors.
Refer to Figure 1-28 on page 1-144 for an SLDD example.
• At a site that is designated as an SLDD site, SLDD must be enabled on all
shelves at that site. Generally, interfaces with SLDD enabled use a
non-OSPF routing protocol for intra-site IP connectivity, as the goal is to
segment the network from an OSPF perspective. Integrated-ISIS is
recommended for this purpose.
• When SLDD is enabled, by default it is active on ILAN-IN/OUT (6500-type
shelves) and ILAN-IN1/OUT1 (T-Series shelves). Depending on the
specific intra-site connectivity details, additional ports may need to be
enabled.

• SLDD distributes AR/TR within a given site. This is determined by the

‘scope-ID’ parameter. By default the scope-ID is set to the same value as
the site-ID, and this is recommended for most configurations. However, if
necessary, the scope-ID value can be over-ridden by changing the
‘configuration’ parameter to ‘manual’. Only shelves with the same
scope-ID will exchange AR/TR.
• SLDD is supported on both D-Series/S-Series and T-Series shelves
• For interop scenarios between D-Series/S-Series and T-Series shelves,
SLDD is supported with D-Series/S-Series Photonics and T-Series
switching.
• SLDD supports an adjacency alarm for each interface in the interface list
to indicate when an adjacency goes down.
• SLDD supports an autonomous output (AO) message to notify of
operational state changes on a given interface.
• From a network perspective, OOLFC and SLDD are supported
concurrently, as complimentary schemes to manage OSPF Type-11
LSAs.

Figure 1-28
SLDD example

SLDD prerequisites
For SLDD to operate, the following conditions must be satisfied:
• The shelf IP address must be provisioned.
• SLDD-enabled interfaces must be provisioned at Layer-2 (ENT-LAN) and
Layer-3. The IP address can be numbered or unnumbered (0.0.0.0).
• At the nodal level, the feature is mutually exclusive with DBRS. Therefore,
DBRS must not be enabled on the SLDD-enabled node.
• If a particular network design requires OSPF on an SLDD-enabled
interface for intra-site connectivity, SLDD does not preclude this but OSPF
opaque LSAs must be disabled on that interface. Generally,
Integrated-ISIS is recommended for intra-site IP connectivity.
SLDD operational states

SLDD provides operational status information to allow users to verify proper
provisioning and operation of the feature. Refer to Table 1-19 on page 1-145.
These states are visible in Site Manager in the SLDD screen (Comms setting
management > Routers > SLDD).
Table 1-19
SLDD operational states
State Description
Active – Interface up The feature is enabled, the interface is fully provisioned and the
SLDD adjacency is up.
Un-provisioned – Interface Down The feature is disabled, or the interface is not fully provisioned.
Fault detected – Adjacency down The SLDD adjacency on this interface is down.
Fault detected – Link down The physical link (for example, ILAN) is down

Service and Photonic layer interoperability (SPLI)

The SPLI feature simplifies the provisioning within a Site ID. It consists three
major functionalities:
• Adjacency discovery: Auto discover the far-end port and make matches if
expected far-end address is provisioned on one end. The SPLI feature can
match CMD to transponder, WSS to WSS, WSS Switch port to LIM,
CCMD8x16 to WSS20x1 sub-port, and WSS20x1 sub-port to WSS 20x1
sub-port adjacencies, and so on.
• Transponder information discovery: Once a match is made between a
CMD channel port and a transponder port, transponder information can be
auto-discovered and sent to the Photonics shelf.
• Photonics parameter provisioning: Based on the auto discovered
transponder information and Photonic layer information, The Photonics
layer sets the appropriate Photonic parameter values on the CMD port
connected to the transponder. Then the SPLI application sends these
parameter values to the transponder shelf and the parameters on the
transponder port are auto-provisioned.
SPLI is an application that discovers and associates connected equipment on

shelves. SPLI validation is performed at two levels:
• First, SPLI checks for the same site ID between the shelves.
• If the site IDs do no match, SPLI checks whether the site ID of the peer
shelves are provisioned as a part of its own site group. Refer to the
“Editing the nodal shelf parameters” procedure in Administration and
Security, 323-1851-301, for steps on how to provision the site group list.
SPLI messages can be UDP or TCP with secure comms (SSH).
For further details on SPLI, refer to the:

• “Service and Photonic Layer Interoperability (SPLI)” section in 6500
Packet-Optical Platform Photonic Layer Guide, NTRN15DA
• “Service and photonic layer interoperability (SPLI)” section in Part 1 of
Configuration - Provisioning and Operating, 323-1851-310/Configuration -
Provisioning and Operating for T-Series, 323-1851-311
• “Service and Photonic layer interoperability (SPLI)” section in
Administration and Security, 323-1851-301
OSPF Multi-Area Adjacency (OMA, T-Series shelves only)

The OSPF Multi-Area Adjacency feature (OMA) implements support for
RFC5185 on the T-Series shelf platform. OMA allows multiple non-backbone
OSPF circuits to be provisioned on the same unnumbered AID, thereby
allowing OSPF areas to overlap. This feature is meant to allow for simple
network scale in configurations where an OSPF backbone is not available.

OMA is generally suited to networks that have some or all of these

characteristics: are dense and meshy, have relatively large OSPF areas
containing multiple ASBRs, and have multiple shelves straddling OSPF areas.
On T-Series shelves, the shelf-IP address can only be configured in a single

OSPF area. Historically, this has sometimes created challenges to satisfy the
routing visibility requirements in networks without an OSPF backbone since,
in typical applications, the shelf-IP must be visible in two or more areas.
Examples of this are when a single shelf faces multiple optical domains, each
in a unique OSPF area, or when a single shelf has one OSPF area facing an
optical domain and another facing the local ROADM site.
With OMA, the shelf-IP address can still only be configured in a single OSPF
area, since it is a stub interface (refer to RFC5185). However, a point-to-point
interface connecting two shelves (with shelf-IPs in different areas) can have
two areas provisioned. This extends each area to its neighbor shelf thereby
allowing each to have visibility into the neighboring area and thus to the
neighboring shelf-IP. Refer to Figure 1-29 on page 1-147.
Table 1-19 on page 1-145 outlines factors to consider when considering use
of OMA versus RFC 2328-compatible ABR when designing a network.
Figure 1-29
Overlapping OSPF areas using OSPF Multi-Area Adjacency
OSPF-A
OSPF-B
Shelf- Shelf-
IP A IP B
Shelf-A Shelf-B
OSC
OSPF-A extended to shelf-B and OSPF-B extended to shelf-A using OSPF Multi-area Adjacency
on OSC
• Shelf-A can see shelf-IP of shelf-B through OSPF-B.
• Shelf-B can see shelf-IP of shelf-A through OSPF-A.

Provisioning
OSPF Multi-Area Adjacency is provisioned simply by adding more than one
OSPF circuit to a given AID according to the rules and restrictions below.
Rules and restrictions

The following rules and restrictions apply to OSPF Multi-Area Adjacency:
• OMA is supported on T-Series shelves only.
• The first OSPF circuit to be provisioned on an AID must have the
PRIMARYAREA parameter set to ON (this is referred to as the primary
circuit).
• All subsequent OSPF circuits on the same AID must have the
PRIMARYAREA parameter set to OFF (these are referred to as the
non-primary circuits).
• Each OSPF circuit on the same AID must have a unique NETAREA.
• The NETAREA parameter is mandatory for deleting multi-area circuits.
• Multi-area circuits are only supported on unnumbered interfaces.
• A maximum of 8 OSPF circuits can be provisioned on the same AID.
• The primary OSPF circuit cannot be deleted if there are non-primary
OSPF circuits present on the same AID (that is, all non-primary circuits
have to be deleted before the primary can be deleted).
• The NETAREA parameter cannot be edited for multi area circuits.
• The PRIMARYAREA parameter cannot be edited for multi area circuits.
• Non-primary circuits do not have opaque LSA capability. The user may
provide the opaque parameter while provisioning a non-primary circuit,
however it will not have any effect on non-primary circuits.
• The RTRV-OSPF-CIRCUIT command does not display the opaque field
for non-primary circuits.
• The OSPF Opaque LSA Flooding Control feature (OOLFC) is not affected
by non-primary circuits.
• The OSPF Adjacency Loss alarm is raised if at least one OSPF circuit
(primary or non-primary) has an adjacency down (on the same AID).
• The OSPF Adjacency Loss alarm is cleared when all OSPF circuits
(primary and non-primary) have adjacency up (one the same AID).
• In addition to the OSPF Adjacency Loss alarm, the
OSPF-NETAREA-ADJACENCY-UP and
OSPF-NETAREA-ADJACENCY-DOWN events are generated when an
OSPF circuit adjacency goes up or down for primary and non-primary
circuits. The following are some examples:
OME-000102034D00 90-12-27 00:08:14

A 0000000066 REPT EVT COM
"ILAN-8-IN1:LAN_OSPF_NETA_DN,TC,12-27,00-08-14,NEND,NA,,,:\"OSPFv2
NETAREA Adjacency
Down\",NONE:0800000000-7013-1985,:YEAR=1990,MODE=NONE,ADDITIONALINFO
=\"Netarea: 1.2.3.4\""
OME-000102034D00 90-12-27 00:08:54
A 0000000069 REPT EVT COM
"ILAN-8-IN1:LAN_OSPF_NETA_UP,TC,12-27,00-08-54,NEND,NA,,,:\"OSPFv2
NETAREA Adjacency
Up\",NONE:0800000000-7017-1990,:YEAR=1990,MODE=NONE,ADDITIONALINFO=\
"Netarea: 1.2.3.4\""
OSPF RFC 2328-compatible ABR (T-Series shelves only)

Beginning in Release 12.0, the T-Series shelf offers two alternative OSPF
ABR behaviors: RFC 2328-compatible (new) and RFC 3509 (existing).
RFC 2328-compatible ABR mode allows a shelf that is participating in multiple
non-backbone OSPF areas to act as an ABR, thereby allowing it to generate
summary LSAs into adjacent areas. Prior to Release 12.0, T-Series shelves
only supported RFC 3509 behavior, where the shelf acts as ABR only if one
of the areas is the backbone.
RFC 2328-compatible ABR mode is suited to networks that have some or all
of these characteristics: multiple non-backbone OSPF areas that are relatively
small (for example, an OSPF area per site and an area per Photonic
direction), small number of ABRs between any two given areas (two or fewer
areas), and a small number of ASBRs in any given area (two or more areas).
On T-Series shelves, the shelf-IP address can only be configured in a single

OSPF area. Historically, this sometimes created challenges to satisfy the
routing visibility requirements in networks without an OSPF backbone, since
in typical applications, the shelf-IP must be visible in two or more areas.
Examples of this are when a single shelf faces multiple optical domains, each
in a unique OSPF area, or when a single shelf has one OSPF area facing an
optical domain and another facing the local ROADM site.
With RFC 2328-compatible ABR mode, a shelf configured with two or more
non-backbone OSPF areas acts as an ABR and generates summary LSAs,
allowing the shelf-IP address to be visible in adjacent OSPF areas. Refer to
Figure 1-30 on page 1-150. The summary LSAs are flooded into adjacent
areas only. Refer to Figure 1-31 on page 1-151.
According to RFC 2328, an ABR can only process backbone summary LSAs.
The T-Series shelf implementation allows processing of non-backbone
summary LSAs to address networks with multiple non-backbone areas. See
the associated restriction below. This behavior is compatible with RFC 2328.

RFC-3509 is the default value and is maintained over pre-Release 12.0 to

Release 12.0 upgrades.
Table 1-19 on page 1-145 outlines factors to consider when considering use
of OMA versus RFC 2328-compatible ABR when designing a network.
Provisioning
RFC 2328-compatible ABR mode is enabled/disabled in the OSPF routing
settings.
Rules and restrictions

An NE acting as an RFC 2328-compatible ABR cannot have a backbone
OSPF area configured on any of its OSPF interfaces.
Figure 1-30
OSPF RFC 2328-compatible ABR
OSPF-A Shelf-A Shelf-B

OSPF-B
Shelf- Shelf-
IP A IP B
ABR
Summary LSAs for OSPF-A into OSPF-B
Summary LSAs for OSPF-B into OSPF-A
Allows all shelves in OSPF-A to see all shelves in OSPF-B

Figure 1-31
Scope of summary LSAs with RFC 2328-compatible ABR mode
Summary LSAs exchanged

between adjacent areas only
OSPF-A ABR OSPF-B ABR OSPF-C
Shelf IP Shelf IP Shelf IP Shelf IP
No additional provisioning on
line amps
This shelf will have visibility

to far end of adjacent areas
Shelf IP ROADM shelf
line amp

Table 1-20
Factors influencing use of OSPF Multi-area Adjacency (OMA) versus RFC 2328-compatible ABR
Number of Multi-area RFC Notes

adjacency 2328-compatible
ABR
Shelves Large Small If the shelves straddling OSPF areas are

straddling/connecting declared as ABRs (that is, set as RFC
two given OSPF 2328-C), then each ABR summarizes routes
areas via Type-3 and Type-4 LSAs. Therefore, more
ABRs results in more summary LSAs, which
need to be taken into consideration with
respect to engineering limits. OSPF area size
and number of ASBRs are also factors. See
below.
Therefore, RFC 2328-C is better suited to
smaller numbers.
Nodes per area Large Small In RFC 2328-C mode, Type-3 summary LSAs
are generated in proportion to the number of
nodes in the area (number of nodes multiplied
by number of ABRs).
small areas.
ASBRs per area Large Small In RFC 2328-C mode, Type-4 summary LSAs
are generated in proportion to the number of
ASBRs in the area (number of ASBRs
multiplied by number of ABRs).
smaller numbers.
Line amps in spans Small Large In Release 12.0, OMA is not supported on
6500 line amplifiers. However, it can be used
on spans without line amps, or RFC
2328-compatible ABR can be used.
Shelves Large Small If a given area has many shelves connecting to

straddling/connecting other areas, then in RFC 2328-C mode, it
a given area to other receives summary LSAs from all those areas.
areas Therefore, RFC 2828-C is better suited to
small number of connection points.

DCN design examples

This section describes different options available for designing a data
communications network containing 6500 network elements. The section
covers the following examples:
• DCN example 1—6500 GNE configuration - standalone Static GNE
configuration. Used for 6500 networks with a single gateway network
element into a non-IISIS or non-OSPF network (for example, external RIP
protocol network).
• DCN example 2—6500 GNE configuration - individual LAN drops from
customer DCN. Used where the 6500 network elements are all connected
directly to routers in the DCN.
• DCN example 3—6500 GNE configuration - redundant OSPF GNE
configuration (each GNE in different OSPF area). Used for redundant
6500 networks with two gateway network elements into an OSPF network
using non-backbone OSPF areas.
configuration (GNEs in same OSPF area). Used for redundant 6500
networks with two gateway network elements into the OSPF backbone
area.
configuration (using tunnels on DCN) (MSPP services). Used if IP address
isolation is required between the 6500 network and the external DCN
network or secure communication is required across a public IP network.
• DCN example 6—6500 GNE configuration - standalone ARP GNE
configuration. Used for 6500 networks with a single gateway network
element into a non-IISIS or non-OSPF network. Using ARP Proxy means
that static routes do not have to be provisioned on the DCN routers.
• DCN example 7—6500 GNE configuration - standalone ARP GNE with
numbered ILAN interface Used to illustrate how to configure the network
when numbered ILANs are used in conjunction with a proxy ARP GNE
configuration.
• DCN example 8—6500 GNE configuration - redundant ARP GNE
configuration. Used for 6500 networks with a redundant gateway network
element into a non-IISIS or non-OSPF network. Using ARP Proxy means
that static routes do not have to be provisioned on the DCN routers.
• DCN example 9—6500 GNE configuration - redundant NAT GNE
configuration. Used for 6500 networks with dual gateway network
elements into a non-IISIS or non-OSPF network. Using proxy ARP means
that static routes do not have to be provisioned on the DCN routers. NAT
is used to translate between public IP addresses and the Private-IP
addresses provisioned on the network elements.

• DCN example 10—6500 GNE configuration - redundant NAT GNE

configuration with nodes running Packet services.
• DCN example 11—6500 GNE configuration - standalone Private-IP
addressing
• DCN example 12—6500 GNE configuration - redundant Private-IP
addressing
• DCN example 13—6500 GNE configuration - standalone Private-IP
• DCN example 14—using single 6500 GNE with IISIS through 6500
network to reach remote 6130 network elements
• DCN example 15—using single 6500 GNE with IISIS to reach remote
6130 network elements in a SNCP/UPSR ring configuration with generic
SDH/SONET equipment
• DCN example 16—management of OM 4000 through 6500 with IP only
external DCN (MSPP services). Used where the 6500 network is between
management system and the OM 4000 network elements.
• DCN example 17—management of 6500 through non-6500 network
element (MSPP services). Used when managing the 6500 network when
part of the network contains non-6500 network elements.
• DCN example 18—management of OM 3500 through 6500 (MSPP
services). Used where the 6500 network is between the OM 3500
head-end network element and the subtending OM 3500 network
elements. Requires the OM 3500 head-end network element to be
collocated with gateway 6500 network element and connected with the
ILAN interface.
• DCN example 19—6500 MSPP and Photonics with OM 3500, using both
OSPF and IISIS
• DCN example 20—management of OM 3500 through 6500 using GRE
tunnel (MSPP services). Used where the 6500 network is between the
OM 3500 head-end network element and the gateway network element.
Requires a GRE tunnel between the 6500 gateway network element and
the OM 3500 network element with the network processor.
• DCN example 21—auto-tunneling (MSPP services). Shows the creation
of auto-tunnels over an optical interface or LAN.
• DCN example 22—6500/HDX interworking using HDX DCC transparency
and multiple OSI areas (MSPP services). Used when managing the 6500
network when part of the network contains HDX/HDXc network elements
(using transparent DCC on the HDX/HDXc).

• DCN example 23—using OSPF with two 6500 gateway network elements
connected to OSPF backbone with collocated CPL network elements.
Used for redundant 6500 networks with two gateway network elements
into the OSPF backbone area with CPL network elements collocated with
the 6500 network elements.
• DCN example 24—Voice over IP (VoIP) orderwire. Illustrates how to use
IP telephony to provide orderwire communication between 6500 network
elements.
• DCN example 25—DBRS use in a mesh network. Outlines the DBRS and
IP routing provisioning required for a site within a mesh network.
• DCN example 26—IPv6 DCN LAN drop to every shelf. Illustrates how to
use IPv6 with a DCN LAN drop to every shelf.
• DCN example 27—IPv6 statically routed GNE configuration. Illustrates
how to use IPv6 with a statically routed GNE configuration.
• DCN example 28—IPv6 ND Proxy GNE configuration. Illustrates how to
use IPv6 with an ND Proxy GNE configuration.
• DCN example 29—IPv6 redundant OSPF GNEs with IPv4 redundant
OSPF GNEs. Illustrates how to use IPv6 with redundant OSPF GNEs with
IPv4 redundant OSPF GNEs.
For DCN interworking between the 6500 and 6110/6130/6150, refer to the
6110/6130/6150 planning guide.

DCN example 1—6500 GNE configuration - standalone Static GNE

configuration
In this example (see Figure 1-32 on page 1-158), one 6500 network element
is connected to the external DCN and acts as the gateway network element
for the other 6500 network elements. One or more static routes are added to
the router in the external DCN for each of the network elements whose traffic
is to be routed through the gateway network element. Likewise, a static route
pointing towards the external management subnet(s) is configured on the
6500 GNE and redistributed into the internal routing domain (either OSPF or
IISIS).
This configuration avoids the use of routing protocols between the 6500
network elements and the external DCN, but requires configuration changes
in the external DCN router and does not provide redundant access to the 6500
network in case of DCN or COLAN failure.
ILAN ports can be used to connect collocated network elements. For more
information, see “ILAN port IP address configuration rules” on page 1-40.
Addressing
In this example, each 6500 network element is assigned a SHELF IP address
from the same subnet. This allows a single static route on the external router
to cover the whole subnet. The COLAN interface on the gateway network
element is assigned an IP address in the same subnet of the router port
connected to the gateway network element.
The example shows the case where the GNE shelf and COLAN IP addresses
are different. This provides consistency in the shelf IP addressing for the
network elements. However, it is also possible for the shelf and COLAN
interfaces on the GNE to be set to the same value (single-public-IP
configuration).
Routing
The internal routing protocol can be either OSPF or IISIS. OSPF is required
for Photonic applications (for example, DOC) and TID consolidation. IISIS is
required in applications that need IIH topology auto-discovery across
DCC/GCC channels, or that require OSI traffic to be routed through the
network.

Data communications channels

For Photonic networks, the OSC must be configured with OSPF to provide
data communications between sites, and it is not necessary to provision
DCC/GCC channels for inter-site communications. OSC is the preferred
communications channel for most applications, but GCC and DCC channels
may also be used in some applications, such as Single Stretch Spans. If OSI
is required for a remote network element (for example, OM 3000 series), IISIS
can be set up on a DCC channel.
For networks without Photonic equipment, DCC and/or GCC channels can be
configured to provide inter-site communications if required.
6500 provisioning details

Table 1-21 on page 1-159 details the DCN parameters for the 6500 network
elements in the DCN for the configuration outlined in this DCN example. For
general provisioning guidelines, see “General DCN provisioning rules” on
page 1-97.
For parameters not listed, use the default settings or leave blank.
Router provisioning information

The static routing must also be set up on the router (IP subnet 10.5.17.0,
subnet mask 255.255.255.248, next hop 10.6.1.2, cost 2).

Figure 1-32
DCN example 1 diagram—Standalone static
RADIUS X terminal
10.11.12.171 10.11.12.170
Subnet: 10.11.12.160
Subnetmask: 255.255.255.224
Broadcast: 10.11.12.191
OneControl Optical
10.11.12.168 Network
Manager
10.11.12.161
10.11.12.172/27
ROUTER
10.6.1.1/30
10.5.17.2/32
Subnet: 10.5.17.0
NE2 Subnetmask: 255.255.255.248
6500
NE1 NE3
COLAN-X
10.6.1.2/30
10.5.17.1/32 10.5.17.3/32
NE4
/27 is 255.255.255.224 10.5.17.4/32
/29 is 255.255.255.248
/30 is 255.255.255.252
/32 is 255.255.255.255

Table 1-21
DCN example 1—6500 DCN provisioning details
Parameters NE1 NE2 NE3 NE4

1 Setup GNE configuration
Name GNE-shelf# - - -
Configuration Standalone - - -
Access Static - - -
Group - - - -
Primary - - - -
2 Set up IP address
Add COLAN-shelf#-X port Yes No No No
Add IP address on COLAN-shelf#-X port:
IP address 10.6.1.2 - - -
Netmask 255.255.255.252 - - -
Non-routing mode Off - - -
ARP proxy Off - - -
Add IP address on shelf (SHELF-shelf#):
IP address 10.5.17.1 10.5.17.2 10.5.17.3 10.5.17.4
Netmask 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255
Non-routing mode Off Off Off Off

Table 1-21
DCN example 1—6500 DCN provisioning details (continued)

3 Set up IP routing (Note 1)
Either
a. For internal IISIS
routing:
Add IISIS router: Yes Yes Yes Yes
Router level Level-1 Level-1 Level-1 Level-1
L1 priority 64 64 64 64
Route summarization On On On On
Route redistribution Static distribution - - -
IP subnet 10.11.12.160 - - -
Subnet mask 255.255.255.224 - - -
Metric 10 - - -
Metric type External - - -
or
b. For internal OSPF
routing:
Add OSPF router: Yes Yes Yes Yes
OSPF Router Id 10.5.17.1 10.5.17.2 10.5.17.3 10.5.17.4
Autonomous System On Off Off Off
Border Router
IP subnet 10.11.12.160 - - -
Subnet mask 255.255.255.224 - - -
Metric 10 - - -
4 Set up lower layer DCC/GCC (Note 2 and Note 3)
Add DCC/GCC:
Name OCn/STMn/OTMn- OCn/STMn/OTMn- OCn/STMn/OTMn- OCn/STMn/OTMn-
shelf#-slot#-port# shelf#-slot#-port# shelf#-slot#-port# shelf#-slot#-port#
Carrier Line/MS, Section/RS, Line/MS, Section/RS, Line/MS, Section/RS, Line/MS, Section/RS,
GCC0, GCC1 GCC0, GCC1 GCC0, GCC1 GCC0, GCC1
Protocol PPP PPP PPP PPP
Add DCC/GCC:
GCC0, GCC1 GCC0, GCC1 GCC0, GCC1 GCC0, GCC1

Table 1-21

5 Set up internal (IISIS or OSPF) routing
Either:
routing, add IISIS circuits
for:
SHELF-shelf#
Name SHELF-shelf# SHELF-shelf# SHELF-shelf# SHELF-shelf#
Circuit default metric 4 4 4 4
Neighbor protocols Off Off Off Off
supported override
DCC/GCC (Note 3 and
Note 4):
GCC0/GCC1 GCC0/GCC1 GCC0/GCC1 GCC0/GCC1
Circuit default metric 5 (Line/MS and 5 (Line/MS and 5 (Line/MS and 5 (Line/MS and
GCC0/GCC1), GCC0/GCC1), GCC0/GCC1) GCC0/GCC1)
6 (Section/RS) 6 (Section/RS) 6 (Section/RS) 6 (Section/RS)
supported override

Table 1-21

or
routing, add OSPF circuits
for:
SHELF-shelf#:
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Cost 0 0 0 0
Area Off Off Off Off
Password authentication Off Off Off Off
Circuit password - - - -
OSC:
Name OSC-shelf#-slot#- OSC-shelf#-slot#- OSC-shelf#-slot#- OSC-shelf#-slot#-
port# port# port# port#
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
10 10 10
Cost 10
Off Off Off
Area Off
Off Off Off
Password authentication Off
- - -
Circuit password -
DCC/GCC (Note 3 and
Note 4):
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Cost 174 (Line/MS), 174 (Line/MS), 174 (Line/MS), 174 (Line/MS),
520 (Section/RS), 520 (Section/RS), 520 (Section/RS), 520 (Section/RS),
303 (OTU1/ODU1 303 (OTU1/ODU1 303 (OTU1/ODU1 303 (OTU1/ODU1
GCC) GCC) GCC) GCC)
GCC) GCC) GCC) GCC)
GCC) GCC) GCC) GCC)
GCC) GCC) GCC) GCC)

Table 1-21

6 Set up external (static) routing (Note 5 and Note 6)
Add static IP route (gateway network element only):
IP subnet 10.11.12.160 - - -
Subnet mask 255.255.255.224 - - -
Next hop 10.6.1.1 - - -
Cost 2 - - -
Circuit Id COLAN-shelf#-X - - -
Note 1: The gateway 6500 network element requires an IISIS or OSPF router with static redistribution. The non-gateway
6500 network elements only require a basic IISIS or OSPF router without any redistribution.
Note 2: GCC is applicable to the circuit packs as described in “Lower layer GCC implementation rules”. DCC/GCC must
be set up on each facility when communication to Neighbor network element is required.
Note 3: Depending on the nodal system parameters, GCC0 and GCC1 circuits and associated IISIS or OSPF circuits can
be automatically created when an OTM1/OTM2/OTM3/OTM4/OTMC2/OTM facility is provisioned.
Note 4: An IISIS or OSPF circuit is required for each DCC/GCC provisioned.
Note 5: Only the gateway 6500 network element requires static routing.
Note 6: A 0.0.0.0/0.0.0.0 default route can be used if the internal routing is OSPF. If interconnecting with CPL using the
ILAN ports, only use the 0.0.0.0/0.0.0.0 default route if CPL is also using the 0.0.0.0/0.0.0.0 default route.

DCN example 2—6500 GNE configuration - individual LAN drops from

customer DCN
In this example (see Figure 1-33 on page 1-165), the 6500 network elements
are all connected directly to routers in the DCN. Each network element looks
like a host on the DCN, and no routing is performed on the COLAN interface.
It is relatively simple to configure, but requires a LAN drop for each shelf,
including TIDc member shelves, and does not provide redundant access to
the 6500 network in case of DCN or COLAN failure.
ILAN ports can be used to connect collocated network elements. For more
Addressing
The single-public-IP mode, where shelf interface and COLAN-X interface are
set to the same value, is supported and recommended in this configuration.
The IP must be unique and must belong to the same subnet as the router to
which the shelf is connected.
Routing
The internal routing protocol can be either OSPF or IISIS. OSPF is required
for Photonic applications (for example, DOC) and TID consolidation. IISIS is
required in applications that need IIH topology auto-discovery across
DCC/GCC channels, or that require OSI traffic to be routed through the
network.
A static route is provisioned on each COLAN interface to provide IP visibility

to the external DCN. It is not necessary to redistribute this static route into
OSPF or IISIS, since each shelf has direct connectivity to the external DCN.
Data communications channels

For Photonic networks, the OSC must be configured with OSPF to provide
data communications between sites, and it is not necessary to provision
DCC/GCC channels for inter-site communications. OSC is the preferred
communications channel for most applications, but GCC and DCC channels
may also be used in some applications, such as Single Stretch Spans. If OSI
can be set up on a DCC channel.
For networks without Photonic equipment, DCC and/or GCC channels can be
configured to provide inter-site communications if required.

page 1-97.

Figure 1-33
DCN example 2 diagram—Individual LAN drops from customer DCN
OneControl
47.1.1.1/29
R4
DCN
R1 R3
R2
COLAN-X
47.1.1.22/30
NE2
COLAN-X COLAN-X
47.1.1.18/30 47.1.1.26/30
NE3
NE1
6500
/29 is 255.255.255.248
/30 is 255.255.255.252
/32 is 255.255.255.255

Table 1-22
Parameters NE1 NE2 NE3

Name - - -
Configuration - - -
Access - - -
Group - - -
Primary - - -
2 Set up IP address
Add COLAN-shelf#-X port Yes Yes Yes
Add IP address on
COLAN-shelf#-X port:
IP address 47.1.1.18 47.1.1.22 47.1.1.26
Netmask 255.255.255.252 255.255.255.252 255.255.255.252
Non-routing mode Off Off Off
ARP proxy Off Off Off
Add IP address on shelf
(SHELF-shelf#):
IP address 47.1.1.18 47.1.1.22 47.1.1.26
Netmask 255.255.255.255 255.255.255.255 255.255.255.255
Either:
a. For internal IISIS routing:
Add IISIS router: Yes Yes Yes
Router level Level-1 Level-1 Level-1
L1 priority 64 64 64
Route summarization On On On
or
b. For internal OSPF routing:
Add OSPF router: Yes Yes Yes
OSPF Router Id 10.5.17.1 10.5.17.2 10.5.17.3
Route summarization On On On
Autonomous System Off Off Off
Border Router

Table 1-22

4 Set up Lower Layer DCC/GCC (Note 2 and Note 3)
Add DCC/GCC:
Name OCn/STMn/OTMn-shelf#- OCn/STMn/OTMn-shelf#- OCn/STMn/OTMn-shelf#-
slot#-port# slot#-port# slot#-port#
Carrier Line/MS, Section/RS, Line/MS, Section/RS, Line/MS, Section/RS,
GCC0/GCC1 GCC0/GCC1 GCC0/GCC1
Protocol PPP PPP PPP
Either:
a. For internal IISIS routing,
add IISIS circuits for:
SHELF-shelf#:
Name SHELF-shelf# SHELF-shelf# SHELF-shelf#
Circuit default metric 4 4 4
Neighbor protocols Off Off Off
supported override
DCC/GCC (Note 3 and
Note 4):
Circuit default metric 5 (Line/MS and 5 (Line/MS and 5 (Line/MS and
GCC0/GCC1), GCC0/GCC1), GCC0/GCC1),
6 (Section/RS) 6 (Section/RS) 6 (Section/RS)
Neighbor protocols Off Off Off
supported override

Table 1-22

or
b. For internal OSPF routing,
add OSPF circuits for:
SHELF-shelf#:
Network area 0.0.0.0 0.0.0.0 0.0.0.0
Cost 0 0 0
Area Off Off Off
Password authentication Off Off Off
Circuit password - - -
OSC:
Name OSC-shelf#-slot#-port# OSC-shelf#-slot#-port# OSC-shelf#-slot#-port#
Network area 0.0.0.0 0.0.0.0 0.0.0.0
Cost 10 10 10
Area Off Off Off
DCC/GCC (Note 3 and
Note 4):
Name OCn/STMn/OTMn- OCn/STMn/OTMn- OCn/STMn/OTMn-
shelf#-slot#-port# shelf#-slot#-port# shelf#-slot#-port#
Network area 0.0.0.0 0.0.0.0 0.0.0.0
Cost 174 (Line/MS), 174 (Line/MS), 174 (Line/MS),
520 (Section/RS), 520 (Section/RS), 520 (Section/RS),
303 (OTU1/ODU1 GCC) 303 (OTU1/ODU1 GCC) 303 (OTU1/ODU1 GCC)
Area Off Off Off
6 Set up external static routing (Note 5)
Add static IP route:
IP subnet 47.0.0.0 47.0.0.0 47.0.0.0
Subnet mask 255.0.0.0 255.0.0.0 255.0.0.0
Next hop 47.1.1.17 47.1.1.21 47.1.1.25
Cost 2 2 2
Circuit Id COLAN-shelf#-X COLAN-shelf#-X COLAN-shelf#-X

Table 1-22

Note 1: If internal routing is IISIS, the 6500 network elements just require an IISIS router without any redistribution.
If internal routing is OSPF, the 6500 network elements just require an OSPF router without any redistribution.
Note 2: GCC is applicable to the circuit packs as described in “Lower layer GCC implementation rules”. DCC/GCC
must be set up on each facility when communication to Neighbor network element is required.
Note 3: Depending on the nodal system parameters, GCC0 and GCC1 circuits and associated IISIS or OSPF
circuits can be automatically created when an OTM1/OTM2/OTM3/OTM4/OTMC2/OTM facility is provisioned
Note 5: The 6500 network elements require static routing.

DCN example 3—6500 GNE configuration - redundant OSPF GNE

configuration (each GNE in different OSPF area)
In this example (see Figure 1-34 on page 1-172), two 6500 network elements
are connected to the external DCN and act as the gateway network element
for the other 6500 network elements. OSPF is used on the COLAN interface
of gateway network elements for integration with the external DCN. The
overall design must ensure that only packets meant for the 6500 network
elements are routed over the DCC/GCC and not other DCN traffic. The 6500
network elements send all routes to the DCN using IISIS to OSPF
redistribution and receive all routes from the DCN using OSPF to IISIS
redistribution.
ATTENTION
This configuration is only supported if the internal routing protocol is IISIS.
Photonic applications (for example, DOC) and TID consolidation require that
OSPF be used as the internal routing protocol. Networks requiring this
functionality can not use this configuration. For dual GNEs with OSPF as the
internal routing protocol refer to Figure 1-82 on page 1-344.
Each 6500 network element is assigned a SHELF IP address from the DCN
address space. The COLAN interface on the gateway network elements are
assigned an IP address in the same subnet of the router port connected to the
gateway network element. Each SHELF IP address is visible within the
external DCN.
ILAN ports can be used to connect to collocated network elements. For more
The gateway network elements are configured as an OSPF autonomous

system boundary routers (ABSR). They are located between the OSPF
autonomous system and a non-OSPF area (IISIS). The example shows the
gateway network elements in different OSPF areas but they could be
connected to the same OSPF area if required as the AS-External_LSA
redistributed route into IISIS does not take precedence to an IISIS learned
route.
PPP is used as the data link layer across the DCC/GCC for communication
between the 6500 network elements.

6500 provisioning information

page 1-97.
6500 extra provisioning information for LAN-15/16/41/42 if used to

access other network elements
Table 1-24 on page 1-176 details extra provisioning details for configuring the
craft port (LAN-15/16/41/42) with non-default IP addresses which allows the
craft user visibility of all the network elements in the subsystem. Provisioning
of the craft port (LAN-15/16/41/42) with non-default IP addresses is also
applicable to the other examples in this section.
For more information, see “Craft LAN port IP address configuration rules” on
page 1-39.
Router configuration information

The OSPF routers (R1 and R2) are area border routers (ABR).

Figure 1-34
DCN example 3 diagram—Redundant OSPF GNE configuration (each GNE in different OSPF area)
RADIUS OneControl
47.1.1.2/29 47.1.1.1/29
Subnet: 47.1.1.0/29
47.1.1.3/29
R3
Note:
IP addresses in DCN
Router DCN Network backbone not shown.
OSPF Backbone Area 0.0.0.0
R2
R1
47.1.1.17/30 47.1.1.21/30
COLAN-X OSPF OSPF COLAN-X

47.1.1.18/30 Area Area 47.1.1.22/30
0001 0002
NE1 NE4
47.1.1.32/32 47.1.1.35/32
/29 is 255.255.255.248 NE2 NE3

/30 is 255.255.255.252
/32 is 255.255.255.255 47.1.1.33/32 47.1.1.34/32

Table 1-23

Name GNE-shelf# - - GNE-shelf#
Configuration Redundant - - Redundant
Access OSPF - - OSPF
Group - - - -
Primary - - - -
2 Set up IP address
Add COLAN-shelf#-X port Yes No No Yes
Add IP address on
IP address 47.1.1.18 - - 47.1.1.22
Netmask 255.255.255.252 - - 255.255.255.252
Non-routing mode Off - - Off
ARP proxy Off - - Off
(SHELF-shelf#):
IP address 47.1.1.32 47.1.1.33 47.1.1.34 47.1.1.35
Netmask 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255
3 Set up IP routing (Note 1 and Note 2)
L1 priority 64 64 64 64
Route summarization: On On On On
Route redistribution OSPF distribution - - OSPF distribution
IP subnet (Note 3) 47.0.0.0 - - 47.0.0.0
Subnet mask 255.0.0.0 - - 255.0.0.0
Metric 10 - - 20
Metric type External - - External
Add OSPF router: Yes No No Yes
OSPF Router Id 47.1.1.32 - - 47.1.1.35
Route summarization On - - On
Autonomous System On - - On
Border Router
Route redistribution ISIS distribution - - ISIS distribution
IP subnet 47.1.1.32 - - 47.1.1.32
Subnet mask 255.255.255.248 - - 255.255.255.248
Metric 10 - - 20

Table 1-23

Add DCC/GCC:
Carrier Line/MS, Line/MS, Line/MS, Line/MS, Section/RS
Section/RS, Section/RS, Section/RS GCC0/GCC1
5 Set up internal (IISIS) routing
Add IISIS circuit for:
SHELF-shelf#:
supported override
DCC/GCC (Note 5 and
Note 6):
Carrier Line/MS, Line/MS, Line/MS, Line/MS,
Section/RS, Section/RS, Section/RS, Section/RS,
Circuit default metric GCC0/GCC1 GCC0/GCC1 GCC0/GCC1 GCC0/GCC1
5 (Line/MS and 5 (Line/MS and 5 (Line/MS and 5 (Line/MS and
GCC0/GCC1), GCC0/GCC1), GCC0/GCC1), GCC0/GCC1),
Neighbor protocols 6 (Section/RS) 6 (Section/RS) 6 (Section/RS) 6 (Section/RS)
supported override Off Off Off Off
6 Set up external (OSPF) routing
Add OSPF circuit for
COLAN-X:
Name COLAN-shelf#-X - - COLAN-shelf#-X
Network area 0.0.0.1 - - 0.0.0.2
Cost 0 - - 0
Priority (Note 7) 1 - - 1
Area Off - - Off
Password authentication Off - - Off

Table 1-23

Note 1: Only the gateway 6500 network elements require an OSPF router.
Note 2: The gateway 6500 network element requires an IISIS router with OSPF redistribution. The non-gateway
6500 network elements only require a basic IISIS router without any redistribution.
Note 3: 47.1.1.0 /29 (NMS LAN) and Local COLAN-X IP subnet are used for distribution into IISIS as it provides
some resilience and aids diagnostics from the COLAN-X subnet.
circuits can be automatically created when an OTM1/OTM2/OTM3/OTM4/OTMC2/OTM facility is provisioned.
Note 6: An IISIS circuit is required for each DCC/GCC provisioned.
Note 7: You can set the priority to 0 if you do not want the network element OSPF router to become the designated
router (DR).

Table 1-24
DCN example 3—additional provisioning when using LAN-15/LAN-41 to access other network
elements

1 Set up IP address
Change IP address
LAN-shelf#-15/41:
IP address 10.10.10.5 10.10.10.13 10.10.10.21 10.10.10.29
Netmask 255.255.255.252 255.255.255.252 255.255.255.252 255.255.255.252
Add IISIS circuit for
LAN-shelf#-15/41:
Name LAN-shelf#-15/41 LAN-shelf#-15/41 LAN-shelf#-15/41 LAN-shelf#-15/41
supported override
Note: For more information on using the LAN-15/41 port to access other network elements, see “Craft LAN port IP
address configuration rules” on page 1-39.
Table 1-25
DCN example 3—additional provisioning when using LAN-16/LAN-42 to access other network
elements

1 Set up IP address
Change IP address
LAN-shelf#-16/42:
IP address 10.10.10.9 10.10.10.17 10.10.10.25 10.10.10.33
Netmask 255.255.255.252 255.255.255.252 255.255.255.252 255.255.255.252
Add IISIS circuit for
LAN-shelf#-16/42:
Name LAN-shelf#-16/42 LAN-shelf#-16/42 LAN-shelf#-16/42 LAN-shelf#-16/42
supported override
Note: For more information on using the LAN-16/42 port to access other network elements, see “Craft LAN port IP
address configuration rules” on page 1-39.


configuration (GNEs in same OSPF area)
In this example, two 6500 network elements are connected to either the OSPF
backbone (see Figure 1-35 on page 1-179) or the same non-backbone OSPF
areas (see Figure 1-36 on page 1-180) and act as the gateway network
element for the other 6500 network elements. The gateway network elements
look like OSPF routers in the DCN. OSPF is used on the COLAN interface of
gateway network elements for integration with the external DCN. The COLAN
ports must be in the same area and have the same configuration as the DCN
router.
The overall design must ensure that only packets meant for the 6500 network
network elements send/receive all routes to/from the DCN. If the internal
routing is IISIS, the 6500 network elements send all routes to the DCN using
IISIS to OSPF redistribution and receive all routes from the DCN using OSPF
to IISIS redistribution.
external DCN.
The internal routing protocol can be either IISIS or OSPF. When the internal
routing protocol is OSPF, OSI traffic cannot be routed through the network
element.
OSPF be used as the internal routing protocol. IISIS can be used on
DCC/GCC to provide data communications to remote OSI network elements.

For added redundancy you can create a tunnel between R1 and R2 and
enable OSPF on the tunnel with the same non-backbone area (Area 0001).

When the internal routing is IISIS, the gateway network elements are
configured as an OSPF autonomous system boundary router (ABSR) as they
are located between the OSPF autonomous system and a non-OSPF area
(IISIS). When the internal routing is OSPF, the gateway network elements are
configured with the OSPF ABSR set to Off as they are located in an OSPF
area.
For systems without Photonic equipment, PPP is used as the data link layer
across the DCC/GCC for communication between the 6500 network
elements.
For systems with Photonic equipment, the OSC channel must be set up to
require it. OSPF runs on the OSC, IISIS is not supported on the OSC. If OSI
can be set up on a DCC.

elements in the DCN for the DCN example 4 configuration. For general
provisioning guidelines, see “General DCN provisioning rules” on page 1-97.

Figure 1-35
DCN example 4 diagram—Redundant OSPF with two 6500 gateway network elements connected
to the OSPF backbone
RADIUS OneControl
47.1.1.2/29 47.1.1.1/29
Subnet: 47.1.1.0/29
47.1.1.3/29
R1 Note:
IP addresses in DCN
backbone not shown.
Router DCN Network
COLAN-X COLAN-X
47.1.1.18/30 47.1.1.22/30
NE1 NE4
47.1.1.32/32 47.1.1.35/32
/29 is 255.255.255.248 NE2 NE3

/30 is 255.255.255.252
/32 is 255.255.255.255 47.1.1.33/32 47.1.1.34/32

Figure 1-36
DCN example 4 diagram—Redundant OSPF with two 6500 gateway network elements connected
to the same non-backbone OSPF area
RADIUS OneControl
47.1.1.2/29 47.1.1.1/29
Subnet: 47.1.1.0/29
47.1.1.3/29
R3
NOTE:
IP addresses in DCN
Router DCN Network backbone not shown.
R2
R1
47.1.1.17/30 47.1.1.21/30

47.1.1.18/30 Area Area 47.1.1.22/30
0001 0001
NE1 NE4
47.1.1.32/32 47.1.1.35/32
/29 is 255.255.255.248 NE2 NE3

/30 is 255.255.255.252
/32 is 255.255.255.255 47.1.1.33/32 47.1.1.34/32

Table 1-26

Name GNE-shelf#- - - GNE-shelf#-
Group - - - -
Primary - - - -
2 Set up IP address
Add IP address on
IP address 47.1.1.18 - - 47.1.1.22
Netmask 255.255.255.252 - - 255.255.255.252
(SHELF-shelf#):
IP address 47.1.1.32 47.1.1.33 47.1.1.34 47.1.1.35
Netmask 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255

Table 1-26

Either:
L1 priority 64 64 64 64
IP subnet (Note 3) 47.1.1.0 - - 47.1.1.0
Subnet mask 255.255.255.248 - - 255.255.255.248
Metric 10 - - 20
IP subnet (Note 3) 47.1.1.16 - - 47.1.1.20
Subnet mask 255.255.255.252 - - 255.255.255.252
Metric 10 - - 20
OSPF Router Id 47.1.1.32 - - 47.1.1.35
Border Router - -
IP subnet 47.1.1.32 - - 47.1.1.32
Subnet mask 255.255.255.248 - - 255.255.255.248
Metric 10 - - 20
or
OSPF Router ID 47.1.1.32 47.1.1.33 47.1.1.34 47.1.1.35
Autonomous System Off Off Off Off
Border Router
Add DCC/GCC:

Table 1-26

Either:
SHELF-shelf#:
supported override
DCC/GCC (Note 5 and
Note 6):
Circuit default metric GCC0/GCC1 GCC0/GCC1 GCC0/GCC1 GCC0/GCC1
5 (Line/MS and 5 (Line/MS and 5 (Line/MS and 5 (Line/MS and
GCC0/GCC1) GCC0/GCC1) GCC0/GCC1) GCC0/GCC1)
Neighbor protocols 6 (Section/RS) 6 (Section/RS) 6 (Section/RS) 6 (Section/RS)
supported override Off Off Off Off
or
SHELF-shelf#:
Network area (OSPF 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
backbone)
non-backbone) 0 0
Cost 0 Off Off 0
Circuit password - -
OSC:
Name OSC-shelf#- OSC-shelf#- OSC-shelf#- OSC-shelf#-
slot#-port# slot#-port# slot#-port# slot#-port#
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Cost 10 10 10 10

Table 1-26

DCC/GCC (Note 5 and
Note 6):
backbone)
non-backbone)
GCC) GCC) GCC) GCC)
GCC) GCC) GCC) GCC)
GCC) GCC) GCC) GCC)
12 (OTU4/ODU4
GCC)
COLAN-shelf#-X:
Network area (OSPF 0.0.0.0 - - 0.0.0.0
backbone)
Network area (OSPF 0.0.0.1 - - 0.0.0.1
non-backbone)
Cost (Note 7) 0 - - 0
Area Off - - Off
Note 1: If internal routing is IISIS, only the gateway 6500 network elements require an OSPF router. If internal
routing is OSPF, all the 6500 network elements require an OSPF router.
Note 2: If internal routing is IISIS, the gateway 6500 network element requires an IISIS router with OSPF
redistribution and the non-gateway 6500 network elements only require a basic IISIS router without any
redistribution. If internal routing is OSPF, all the 6500 network element do not require an IISIS router.
Note 3: 47.1.1.0 /29 (NMS LAN) and Local COLAN-X IP subnet are used for distribution into IISIS as it provides
some resilience and aids diagnostics from the COLAN-X subnet.

Table 1-26

Note 7: For Photonics applications, the OSPF cost of the COLAN interface is typically set high (for example, 1000)
to ensure internal management traffic stays internal.
router (DR).


configuration (using tunnels on DCN)
This design (see Figure 1-37 on page 1-188) can be used when:
• address isolation is required between the 6500 network elements and the
external DCN networks (for example, GRE or IPSec VPN tunnels)
• secure communication is required across a public IP network (for example,
IPSec VPN tunnels)
The configuration requires extra routers to be installed at the 6500 gateway

and management sites.
In this example, two 6500 network elements are connected to the external
DCN and act as gateway network elements for the other 6500 network
elements. OSPF is used on the COLAN interface of gateway network
elements for integration with the external DCN. As the tunnels are on the
external routers, the routing mechanism on the 6500 can be any of the
supported mechanisms (for example, static routing), see the other examples
in this chapter for details.
Each 6500 network element is assigned a SHELF IP address from the same
subnet. The COLAN interface on the gateway network element is assigned an
IP address in the same subnet of the router port connected to the gateway
network element. Each SHELF IP address is visible from the management
LAN but is not visible from the router DCN. The customer must assign unique
IP addresses to the network elements from the Private-IP addressing range.
element.


VPN tunnels (for example, GRE, IPSec, or MPLS) are used between routers
connected to the management systems (for example, OneControl) and the
routers connected to the 6500 gateway network elements. All traffic to/from
the 6500 network elements and the management systems are in the tunnels.
In this example, NE2 and NE3 cannot ping R1 and R2 without redistributing
10.6.1.30 and 10.6.1.5 into IISIS.
The gateway network element is configured as an OSPF autonomous system

boundary router (ABSR) as it is located between the OSPF autonomous
system and a non-OSPF area (IISIS).
OSPF areas 1 and 2 are interconnected through the backbone area with R3
acting as the ABR. Alternatively, R1 and R2 can be ABRs with the tunnel
interfaces in the backbone area; this is the configuration assumed for this
example.
elements.
For systems with Photonic equipment, the OSC channel must be set up to
require it. OSPF runs on the OSC. IISIS is not supported on the OSC. GCC
and DCC channels should not be provisioned to provide a data
communication path between 6500 sites. If OSI is required for a remote
network element (for example, OM 3000), IISIS can be set up on a DCC.

elements in the DCN for the DCN example 5 configuration. These settings are
for OSPF routing. As the tunnels are on the external routers, any of the 6500
routing mechanisms detailed in this chapter can be used. For general

Figure 1-37
DCN example 5 diagram—Redundant OSPF using DCN tunnels
RADIUS OneControl
10.11.12.1/29 10.11.12.2/29
Subnet: 10.11.12.0/29
R3 10.11.12.3/29
Any OSPF area
47.3.3.1/30 or other protocol
Router DCN
Network
47.1.1.1/30 47.2.2.1/30
R1 R2
10.6.1.1/30 10.6.1.5/30

10.6.1.2/30 Area Area 10.6.1.6/30
0001 0002
NE1 NE4
10.5.1.1/32 10.5.1.4/32
NE2 NE3
/29 is 255.255.255.248
/30 is 255.255.255.252
10.5.1.2/32 10.5.1.4/32
/32 is 255.255.255.255

Table 1-27

Group - - - -
Primary - - - -
2 Set up IP address
Add IP address on
IP address 10.6.1.2 - - 10.6.1.6
Netmask 255.255.255.252 - - 255.255.255.252
(SHELF-shelf#):
IP address 10.5.1.1 10.5.1.2 10.5.1.3 10.5.1.4
Netmask 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255
Either:
routing:
L1 priority 64 64 64 64
IP subnet 10.11.12.0 - - 10.11.12.0
Subnet mask 255.255.255.248 - - 255.255.255.248
Metric 10 - - 20
OSPF Router Id 10.5.1.1 - - 10.5.1.4
Border Router
IP subnet 10.5.1.0 - - 10.5.1.0
Subnet mask 255.255.255.240 - - 255.255.255.240
Metric 10 - - 20

Table 1-27

or
routing:
Router level 10.5.1.1 10.5.1.2 10.5.1.3 10.5.1.4
L1 priority External External External External
Autonomous System Off Off Off Off
Border Router
Add DCC/GCC:
GCC0/GCC1 GCC0/GCC1 GCC0/GCC1 GCC0/GCC
PPP PPP
Protocol PPP PPP
Either:
a. For IISIS internal
for:
SHELF-shelf#:
supported override
DCC/GCC (Note 4 and
Note 5):
supported override

Table 1-27

or
b. For OSPF internal
for:
SHELF-shelf#:
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Cost 0 0 0 0
DCC/GCC (Note 4 and
Note 5):
GCC) GCC) GCC) GCC)
75 (OTU2/ODU2 GCC) 75 (OTU2/ODU2 GCC) 75 (OTU2/ODU2 GCC) 75 (OTU2/ODU2 GCC)
OSC:
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Cost 10 10 10 10
COLAN-shelf#-X:
Network area 0.0.0.1 - - 0.0.0.2
Cost 0 - - 0
Area Off - - Off

Table 1-27

Note 1: If internal routing is IISIS, only the gateway 6500 network elements require an OSPF router. If internal routing is
OSPF, all the 6500 network elements require an OSPF router.
Note 2: If internal routing is IISIS, the gateway 6500 network element requires an IISIS router with OSPF redistribution and
the non-gateway 6500 network elements only require a basic IISIS router without any redistribution. If internal routing is
OSPF, all the 6500 network element do not require an IISIS router, and all 6500 NEs must be in the same OSPF area.
Note 3: GCC is applicable to the circuit packs as described in “Lower layer GCC implementation rules”. DCC/GCC must be
set up on each facility when communication to Neighbor network element is required.
Note 6: You can set the priority to 0 if you do not want the network element OSPF router to become the designated router
(DR).
Router configuration information - general

R1 and R2 are configured as ABRs in this example with the tunnel interfaces
in the backbone area and the LAN interfaces to NE1 and NE2 in OSPF area 1
and OSPF area 2. R1, R2, and R3 each have an interface connected to the
Router DCN which are assigned an IP address from the Router DCN. For this
example, it is assumed that this interface is provided by Ethernet.
• R1 configuration (circuitless IP addresses not detailed)
— IP addresses:
– Public LAN (connected to DCN): 47.1.1.1/30
– Private LAN (connected to NE1): 10.6.1.1/30
— enable OSPF router
– ABR in OSPF backbone 0.0.0.0 (if using different OSPF areas)
or
normal router in OSPF backbone 0.0.0.0 (if using single OSPF
area)
– enable OSPF on the Ethernet interface 10.6.1.1 using OSPF area
0.0.0.1
– enable OSPF on the VPN tunnel using OSPF area 0.0.0.0


— IP addresses:
– Private LAN (connected to NE4): 10.6.1.5/30
– ABR into OSPF backbone 0.0.0.0 (if using different OSPF areas)
or
normal router in OSPF backbone 0.0.0.0 (if using single OSPF
area)
– enable OSPF on the Ethernet interface 10.6.1.5 in OSPF area
0.0.0.2
– enable OSPF on the VPN tunnel using OSPF area 0.0.0.0
— IP addresses:
– Private LAN (connected to management LAN): 10.11.12.3/29
– ABR in OSPF backbone 0.0.0.0
– enable OSPF on the VPN tunnels using OSPF area 0.0.0.0
Router configuration information - VPN tunnels

If addition to configuring the basic router configuration, the additional VPN
tunnel configuration is as follows:
• R1 configuration
— tunnel 1
– source: 47.1.1.1
– destination: 47.3.3.1 (R3 public LAN port)
— tunnel 2
– source: 47.2.2.1

— tunnel 1
– source: 47.3.3.1
— tunnel 2
– source: 47.3.3.1
For detailed information, see the specific router documentation.

DCN example 6—6500 GNE configuration - standalone ARP GNE

configuration
for the other 6500 network elements. This example is similar to DCN
Standalone Static example with the exception that static routes are not
required to be provisioned at the router connected to the gateway network
element. The gateway network element will proxy ARP for the IP addresses in
subnet A which includes the remote network elements.
subnet. The COLAN-X interface on the gateway network element is assigned
an IP address in the same subnet of the router port connected to the gateway
network element. Each SHELF IP address is visible within the external DCN.
The subnet on the DCN router port that connects to the COLAN-X port of the
gateway network elements must be large enough to support the COLAN-X
port and the SHELF IP address of every network element for which the
gateway network element will proxy ARP. It is recommended that the GNE
COLAN IP address and SHELF IP address be the same. Proxy ARP is set to
On for the COLAN-X interface.
In addition, a default route (static route) is provisioned at the gateway network

element which is redistributed in the IISIS or OSPF router. The IP addresses
of the remote NEs and ILAN ports (if the ILAN ports are numbered) are
provisioned in the Proxy ARP table on the GNE, so that it can proxy ARP for
their IP addresses.
The ILAN ports can be used to connect to collocated network elements. For
more information, see “ILAN port IP address configuration rules” on
page 1-40.
element.

This example does not provide redundant access to the 6500 network in case
of DCN failure.

elements.
For systems with Photonic equipment, the OSC channel must be setup to
require it. OSPF runs on the OSC, IISIS is not supported on the OSC. GCC


Figure 1-38
DCN example 6 diagram—Standalone ARP
RADIUS OneControl
47.1.1.2/29 47.1.1.1/29
Subnet: 47.1.1.0/29
47.1.1.3/29
DCN
Network
Subnet A
47.114.242.x/24
47.114.242.1/24
COLAN-X
47.114.242.2/24
GNE A with NE1 NE4

ARP proxy for
IP addresses 47.114.242.2/32 47.114.242.5/32
47.114.242.3 to
47.114.242.5
NE2 NE3
/24 is 255.255.255.0
/29 is 255.255.255.248
47.114.242.3/32 47.114.242.4/32
/30 is 255.255.255.252
/32 is 255.255.255.255

Table 1-28

Configuration Standalone - - -
Access ARP - - -
Group - - - -
Primary - - - -
2 Set up IP address
Add IP address on
IP address 47.114.242.2 - - -
Netmask 255.255.255.0 - - -
ARP proxy On - - -
(SHELF-shelf#):
IP address 47.114.242.2 47.114.242.3 47.114.242.4 47.114.242.5
Netmask 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255
Either:
L1 priority 64 64 64 64
IP subnet 47.0.0.0 - - -
Subnet mask 255.0.0.0 - - -
Metric 10 - - -
or
OSPF Router Id 47.114.242.2 47.114.242.3 47.114.242.4 47.114.242.5
Autonomous System Border On Off Off Off
Router
IP subnet 47.0.0.0 - - -
Subnet mask 255.0.0.0 - - -
Metric 10 - - -

Table 1-28

Add DCC/GCC:
Either:
a. For internal IISIS routing, add
IISIS circuits for:
SHELF-shelf#:
Neighbor protocols supported Off Off Off Off
override
DCC/GCC (Note 3 and Note 4):
Neighbor protocols supported Off Off Off Off
override

Table 1-28

or
SHELF-shelf#:
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Cost 0 0 0 0
OSC:
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Cost 10 10 10 10
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
GCC) GCC) GCC) GCC)
GCC) GCC) GCC) GCC)
GCC) GCC) GCC) GCC)
GCC) GCC) GCC) GCC)
6 Set up external routing (Note 5)
Add static IP route (gateway network element only):
IP subnet 47.0.0.0 - - -
Subnet mask 255.0.0.0 - - -
Next hop 47.114.242.1 - - -
Cost 2 - - -
Circuit Id COLAN-shelf#-X - - -

Table 1-28

7 Set up ARP proxy
Add address range for ARP proxy:
First address 47.114.242.3 - - -
Last address 47.114.242.5 - - -
Note 1: The gateway 6500 network element requires an IISIS or OSPF router with static redistribution. The
non-gateway 6500 network elements only require a basic IISIS or OSPF router without any redistribution.
Note 5: A 0.0.0.0/0.0.0.0 default route can be used if the internal routing is OSPF. If interconnecting with CPL using
the ILAN ports, only use the 0.0.0.0/0.0.0.0 default route if CPL is also using the 0.0.0.0/0.0.0.0 default route.

DCN example 7—6500 GNE configuration - standalone ARP GNE with

numbered ILAN interface
This example illustrates how to configure the network when numbered ILANs
are used in conjunction with a proxy ARP GNE configuration. It is
recommended that internal interfaces are made unnumbered whenever
possible but in some circumstances it may be necessary to assign
DCN-visible IP addresses. For example, the ILAN must be numbered if the
ILAN is running either OSPF or IISIS and is connected with multiple nodes via
a hub or switch.
Note that if the proxy ARP GNE does not have any numbered ILANs, no
special configuration is necessary (refer to “DCN example 6—6500 GNE
configuration - standalone ARP GNE configuration” on page 1-195).
In general, in a proxy ARP configuration, the DCN-visible IP addresses need

to logically appear as if they are directly connected to the DCN router subnet
even though, physically, this is not the case. The device that does the ARP
proxying will send ARP responses on behalf of other devices.
In this example, the proxy ARP GNE will proxy for the subtending RNEs and
the DCN-visible ILAN IP addresses. All of these addresses belong to the DCN
router subnet 47.134.10.0/24.
This configuration needs to be treated as a special case, however, because

the 6500, similar to standard routers, does not allow overlapping IP address
ranges on its interfaces (Note: a single public IP GNE configuration, where the
shelf-IP and COLAN IP are the same is allowed). Therefore it would not be
possible to assign a numbered ILAN on the proxy ARP GNE in the same
subnet as the COLAN-X interface. For example, if the COLAN-X interface was
configured as 47.134.10.126/24, it would not be possible to assign
47.134.10.80/30 to an ILAN interface.
The key to this configuration is that the GNE COLAN-X interface must be
assigned a smaller subnet than the corresponding default gateway. However,
the COLAN-X subnet must be large enough to include the default gateway.
The numbered ILAN interface(s) must fall outside the COLAN-X subnet.
Details on this configuration follow.

Referring to Figure 1-39 on page 1-204, GNE1 would normally have a subnet
mask of 255.255.255.0 (/24) corresponding to the DCN router it is connected
to, but is instead given a mask of 255.255.255.128 (/25). This allows the
ILAN-OUT IP subnet of 47.134.10.220/30 to be assigned without causing
overlap, since it is outside the range of the COLAN-X port (47.134.10.0 to
47.134.10.127). Both the GNE1 COLAN-X subnet (47.134.10.126/25) and the
ILAN-OUT subnet still fall within the larger subnet of the DCN router interface
- 47.134.10.1/24. The COLAN-X subnet is large enough to include the DCN
router interface (default gateway).
If using numbered ILANs at non-GNE sites, the only requirement is that the
addresses belong to the DCN router subnet. In this example, the addresses
fall within the COLAN-X subnet of the GNE.
Table 1-29 on page 1-203 illustrates how the subnets are configured in this
example. The top line shows the entire DCN router subnet. By assigning the
smaller subnet mask to the COLAN-X interface, it belongs to the lower half of
the DCN router subnet. The ILAN subnet at Site-1, which includes the GNE
ILAN interface, belongs to the upper half of the DCN router subnet. The ILAN
subnet at Site-2 belongs to the COLAN-X subnet. (Note that this diagram is
not to scale.)
Table 1-29
DCN example 7—Subnet configuration
DCN router subnet 47.134.10.0/24 * * * * * * * * * * * * * * * *
COLAN-X subnet 47.124.10.0/25 * * * * * * * *
ILAN subnet - Site 1 47.134.10.220/30 *

(GNE)
ILAN subnet - Site 2 47.134.10.100/30 *
GNE1 is configured to proxy ARP for all RNE SHELF IP addresses and
the ILAN interface IP addresses (not the subnet or broadcast addresses).
Operationally, this configuration will result in non-standard traffic flows in
some cases. Specifically, if egress traffic from the GNE is trying to reach
the 47.134.10.128/25 subnet other than the ILAN subnets, it will first be
forwarded to the default gateway (DCN router interface) rather than being
sent directly to the destination host.
The internal routing protocol is not shown as it is not important for this
example. It could be IISIS or OSPF, or both. The default static route must
be distributed to the RNEs so that destination IP addresses located
externally can be reached.

Note that the same approach can be applied to a redundant ARP GNE
configuration if DCN-visible IP addresses are required on the GNE ILAN
interfaces.
Figure 1-39
DCN example 7 diagram—Subnet configuration
Site Manager OneControl
GNE1 proxy ARPs for IP addresses:

47.134.10.57
47.134.10.122
DCN Network 47.134.10.123
47.134.10.221
47.134.10.222
47.134.10.101
47.134.10.102
Router interface: ILAN-IN IP
47.134.10.1/24 47.134.10.222/30
GNE1 RNE3
Shelf IP: 47.134.10.2/32 Shelf IP: 47.134.10.123/32
COLAN-X IP: 47.134.10.2/25
Site 1
ILAN-OUT IP
47.134.10.221/30
unnumbered GCC channel unnumbered GCC channel

ILAN-IN IP
47.134.10.102/30
RNE1
Shelf IP: 47.134.10. 57/32 RNE2
Shelf IP: 47.134.10.122/32
Site 2
ILAN-OUT IP
47.134.10.101/30

Table 1-30
Parameters GNE1 RNE1 RNE2 RNE3

Configuration Standalone ARP - - -
Group - - - -
Primary - - - -
2 Set up IP address
Add IP address on
IP address 47.134.10.2 - - -
Netmask 255.255.255.128 - - -
ARP proxy ON - - -
(SHELF-shelf#):
IP address 47.134.10.2 47.134.10.57 47.134.10.122 47.134.10.123
Netmask 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255
Add IP address on ILAN - - - -
(ILAN-shelf#-IN - - - -
IP address - - - -
Netmask - - - -
Non-routing mode - - - -
Add IP address on ILAN - - - -
(ILAN-shelf#-OUT - - - -
IP address 47.134.10.221 47.134.10.101 47.134.10.102 47.134.10.222
Netmask 255.255.255.252 255.255.255.252 255.255.255.252 255.255.255.252
3 Set up External routing
Add static IP route (gateway
network element only):
IP subnet 0.0.0.0
Subnet mask 0.0.0.0
Next hop 47.134.10.1
Cost 10
Circuit ID COLAN-shelf#-X
4 Set up ARP Proxy
Add address range for ARP 47.134.10.57
proxy: 47.134.10.122
47.134.10.123
47.134.10.221
47.134.10.222
47.134.10.101
47.134.10.102

DCN example 8—6500 GNE configuration - redundant ARP GNE

configuration
• GNEs may be deployed to manage arbitrary sections of a larger linear or
ring system. That is, GNEs are configured to be in specific redundancy
groups.
• In Figure 1-42 on page 1-212, GNE 1A and GNE 2A are both in the same
redundancy group and manage section A of the network. When using
wayside with spanning tree groups, then a restriction of seven switch hops
applies (spanning tree uses a default TTL of 7).
• Each GNE pair provides redundant DCN comms access to the RNEs
(Remote Network Elements) within the section. The GNE pairs must
co-exist on the same L2 network.
• CARP (Common Address Redundancy Protocol) is used to determine
which GNE is currently active, and thus providing DCN comms access, for
each RNE.
• For complete redundancy, the L2 network should also be configured to
provide redundant access. This may mean configuring the L2 network in
a ring configuration, in which case Spanning Tree (or like) should be used
to prevent looping and subsequent broadcast storms.
ATTENTION
Spanning Tree does not handle uni-directional failures very elegantly. It is
highly recommended that an additional functionality be configured to cover
this deficiency (for example, VLACP).
• GNEs use proxy ARP and gratuitous ARP to notify external routers of the
RNE IP addresses for which they are providing gateway services.
• A GNE negotiates master/backup responsibilities for each IP in its proxy
IP table, individually. That is, the GNE may become master for one of the
IPs in its proxy list but may be backup for another IP in its Proxy list. A GNE
that is master for an IP provides DCN comms access to the RNE. A GNE
will always attempt to become master of its own COLAN IP.

• During provisioning of a Redundant ARP GNE configuration, a Duplicate

IP Address alarm is raised. Provisioning of a Redundant ARP
configuration (particularly if single shelf IP is used) requires the COLAN IP
of both GNEs to be entered in the Proxy list of both GNEs. A GNE attempts
to become master for all IPs in its Proxy list and upon becoming master
sends a gratuitous arp for that IP. When provisioning of one of the GNEs
is completed (and before completion of provisioning its partner GNE), the
GNE can become master and send a gratuitous arp for its proposed
partner GNEs COLAN IP. The intended partner GNE raises the Duplicate
IP Address alarm. Once provisioning of the partner GNE is completed, the
partner GNE takes over as master for its own COLAN IP. A GNE is always
the preferred master for its own COLAN IP and the Duplicate IP Address
alarm clears.
• Each 6500 NE is provisioned with one public IP only. At the GNEs, this
address can serve as the SHELF IP and the COLAN IP. The IPs assigned
to NEs that are in the same managed 6500 section must be from the same
subnet. This is required in order to receive ARP from the DCN Router.
• The ILAN ports are given un-numbered IP addresses.
• The GNEs need to be co-located on the same L2 network. You must
provide this L2 network and ensure that it provides the required level of
redundancy (for full redundancy, the L2 network must also be fully
redundant). Where the GNEs are not co-located at the same site, the
wayside can be used to provide this L2 network. When using the wayside
for the L2 network, the wayside must be configured as a ring for full
redundancy.
ATTENTION
The Redundant ARP GNE configuration does not detect L2 failures (on your
L2 network), other than the COLAN port to the GNE being down.
• GNEs must be provisioned with the configuration set to “redundant” and

access set to “ARP”.
• Proxy ARP IPs must be provisioned at both GNEs. The IPs assigned to
the RNEs must be added to the proxy IP list at both GNEs. Also the
COLAN IP addresses (or the public shelf IP addresses) of both GNEs
must be added to the Proxy IP list (if they are not, there is no redundancy
to the GNEs).
• The IPs assigned to NEs that are in the same managed section must be
from the same subnet (required to receive ARP from the DCN router).
• The COLAN port of the GNEs must be provisioned with Proxy ARP set to
on.

• A static route must be provisioned at each GNE and the routing distributed
to the RNEs.
• The Redundant ARP GNE solution is designed to provide full comms DCN
availability when deployed in conjunction with a fully redundant external
customer DCN network. Thus ensuring that management systems (for
example, OneControl or Site Manager) maintain comms to the 6500
network under single failure conditions. The following are the
recommended network connections:
— Connect each GNE, of a managed section, to an Ethernet switch or
layer 2 network, that is connected to two routers on the Ethernet
domain. The routers and the GNEs are connected to the same IP
VLAN or LAN, with the two routers using VRRP (Virtual Router
Redundancy Protocol) or HSRP (Hot Standby Routing Protocol) to
provide a redundant default gateway for the GNEs.
— Use Auto-Negotiation on all COLAN Ethernet connections as this may
assist in detecting uni-directional failures of the Ethernet connection.
The ILAN ports can be used to connect to collocated network elements. For
more information, see “ILAN port IP address configuration rules” on
page 1-40.
Guidelines for section segmentation in redundant ARP comms

configurations
In a redundant ARP GNE configuration, the network can (and in most cases
should) be segmented into several managed sections. Managed sections are
parts of the network that are managed, for DCN comms purposes, by the
same pair of GNEs (a master GNE and a backup GNE).
A managed section must reside on a single L2 network, as master and backup

GNEs exchange CARP message packets (these packets are multicast)
across the L2 network.
The GNE that is the current master sends one L2 CARP message every 2 or
3 seconds for each RNE it is managing. In addition, each GNE sends one
CARP L2 message, for itself, every 1 second.
Managed sections should be set up with the following objectives:

• Contain comms internal messaging, whenever possible, to within a single
managed section (to minimize cross section messaging).
• Limit number of CARP L2 messages arriving at the GNE COLAN interface
to a reasonable number.
• DCN drops required to GNEs

Every GNE must be configured with a default (or static) route with the next hop
as the gateway IP. This default route must be distributed to the RNEs using
OSPF. This route provides the comms path from the 6500 NEs to your DCN.
It should be noted that the RNEs receive the distributed default routes from all
the GNEs within the network (that is, not just the GNEs of their own managed
sections). The RNE store all these routes in its LSA database but the routing
table will select the one with the lowest cost. Generally, costs should be setup
to ensure that the outgoing packets stay on the same L2 network. This is
particularly important if you have IP filtering configured on your routers
(configured to reject packets that originate from unknown source IPs such as
source IPs from outside the expected subnet).
Default route selection

Figure 1-40 on page 1-209 shows two managed sections, sections A and B
on separate L2 networks connected to the customer DCN.
Within section B, NE4 and NE7 are provisioned with a default route pointing
to the customer DCN. These default routes are then distributed to the RNEs.
If NE4 is the preferred GNE, then it is desirable to provision the costs of the
redistributed default routes such that the one originating from NE4 always
gives the lowest cost and is therefore the preferred route. Under normal
operating conditions packets from section B are routed to NE4 and out the
COLAN of NE4 to your DCN.
Figure 1-40
Managed sections example 1
Customer DCN
Router configured to
only allow subnet Y
addresses through
Subnet Y Subnet X
NE1 NE2 NE3 NE4 NE5 NE6 NE7
Section A Section B
Packet flow out

In the case when the COLAN of NE4 loses connectivity. NE4 detects link down
on the COLAN port and the default route associated with this interface is no
longer redistributed to the RNEs. The routing tables of the RNEs select the
next default route with the lowest cost. If the default route received by NE5
from NE3 is a lower cost than the one received at this same NE (NE5) from
NE7, then NE5 will route its outbound packets to NE3 and over subnet Y.
In Figure 1-41 on page 1-210, when the COLAN port to NE4 is down, NE5
selects the default route from NE3 because this route has a lower cost than
the route from NE7. The default route cost is the sum of the costs as
redistributed and the cost of links it must travel over. This will cause a problem
if the customer router connected to the COLAN of NE3 rejects packets that
originate from IP addresses that are outside the required subnet. One way to
avoid this scenario is to set the cost of the link between the two managed
sections high. For example, setting the link cost between NE3 and NE4 to 200
ensures NE5 always selects the default route from NE4 or NE7. This helps in
achieving the objective of containing comms internal messaging within a
managed section.
Figure 1-41
Managed sections example 2
Subnet Y Subnet X
10 10 10 10
NE3 NE4 NE5 NE6 NE7
NE3 redistributes NE4 redistributes NE7 redistributes

with cost of 10 with cost of 10 with cost of 30
NE5 receives
redistributed route
from NE7 with cost
NE5 receives of 30+10+10=50
redistributed route
from NE3 with cost
of 10+10+10
Legend
10 = Link cost
= Outbound packet
flow from NE5

DOC considerations
DOC sends messages within a domain. When setting high link costs, ensure
that the overall cost of messaging within a DOC domain is not so high that
messages are routed out the COLAN using the customer DCN. DOC domains
are limited to 32 NEs.
If possible comms Redundant ARP managed sections should be aligned with

DOC domains because it:
• helps to contain internal messaging within a managed section
• gives a total of around 20 CARP L2 messages per second on the L2
network (reasonable)
• allows for the link cost between managed sections to be set high without
risk of routing DOC using the customer DCN
Refer to 6500 Packet-Optical Platform Photonic Layer Guide, NTRN15DA,
for detailed information on Photonic concepts, applications, and
engineering rules supported for 6500.
Wayside as L2 network
When wayside is used as the L2 network, it needs to be configured such that
the number of L2 messages that are received by a GNE is contained at a
reasonable level (around 50 messages). This can be achieved by either:
• limiting the span of each wayside segment
• implementing VLANs
Summary of section segmentation guidelines

Section segmentation guidelines include:
• A managed section must reside on a single L2 subnet.
• Wherever possible, a managed section should be aligned with a DOC
domain.
• Number of NEs within a managed section must be limited to 150 shelves
or less.
• Link costs, between managed sections, should be set high (to contain
internal messaging within managed section).
• GNEs must align with available DCN drops.


Figure 1-42
DCN example 8 diagram—Redundant ARP
RADIUS OneControl
47.1.1.2/24 47.1.1.1/24
Subnet: 47.1.1.0/24
47.1.1.3/24
DCN Network
47.2.1.4/24
47.1.1.4/24
L2 Network L2 Network
COLAN: COLAN: COLAN:

47.1.1.18/24 COLAN:
47.1.1.20/24 47.2.1.20/24
47.2.1.18/24
6500 NE 6500 NE 6500 NE 6500 NE 6500 NE 6500 NE
NE1: NE2: NE3: NE4: NE5: NE6:

47.1.1.18/32 47.1.1.19/32 47.1.1.20/32 47.2.1.18/32 47.2.1.19/32 47.2.1.20/32
GNE 1A GNE 2A GNE 1B GNE 2B
Section A Section B
Legend /24 is 255.255.255.0

= Optical /29 is 255.255.255.248
= Ethernet /30 is 255.255.255.252
/32 is 255.255.255.255

Table 1-31
Parameters NE1 NE2 NE3 NE4 NE5 NE6

Name GNE-shelf# - GNE-shelf# GNE-shelf# - GNE-shelf#
Configuration Redundant - Redundant Redundant - Redundant
Access ARP - ARP ARP - ARP
Group 1 - 1 2 - 2
Primary Yes - No Yes - No
2 Set up IP address
Add COLAN-shelf# Yes No Yes Yes No Yes
-X port
Add IP address on
COLAN-shelf#-
X port:
IP address 47.1.1.18 - 47.1.1.20 47.2.1.18 - 47.2.1.20
Netmask /24 - /24 /24 - /24
Non-routing mode Off - Off Off - Off
ARP proxy On - On On - On
Add shelf IP address
(SHELF-shelf#):
IP address 47.1.1.18 47.1.1.19 47.1.1.20 47.2.1.18 47.2.1.19 47.2.1.20
Netmask /32 /32 /32 /32 /32 /32
Non-routing mode Off Off Off Off Off Off
Add OSPF router: Yes Yes Yes Yes Yes Yes
OSPF Router Id 47.1.1.18 47.1.1.19 47.1.1.20 47.2.1.18 47.2.1.19 47.2.1.20
Route summarization On On On On On On
Autonomous System On Off On On Off Off
Border Router
Route redistribution Static distribution - Static distribution Static distribution Static distribution
IP subnet 47.0.0.0 - 47.0.0.0 47.0.0.0 - 47.0.0.0
Subnet mask /8 - /8 /8 - /8
Metric 10 - 10 10 - 10
Metric type Internal - Internal Internal - Internal
4 Set up internal OSPF routing

Add OSPF circuits
for:
SHELF-shelf#
Name SHELF-shelf# SHELF-shelf# SHELF-shelf# SHELF-shelf# SHELF-shelf# SHELF-shelf#
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Cost 0 0 0 0 0 0
Area Off Off Off Off Off Off
Password Off Off Off Off Off Off
authentication
Circuit password - - - - - -

Table 1-31
Parameters NE1 NE2 NE3 NE4 NE5 NE6

OSC:
Name OSC-shelf#- OSC-shelf#- OSC-shelf#- OSC-shelf#- OSC-shelf#- OSC-shelf#-
slot#-port# slot#-port# slot#-port# slot#-port# slot#-port# slot#-port#
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Cost (Note 3) 10 10 10 10 10 10
Area Off Off Off Off Off Off
Password Off Off Off Off Off Off
authentication
Add static IP route
(gateway network
elements only):
IP subnet 47.0.0.0 - 47.0.0.0 47.0.0.0 - 47.0.0.0
Subnet mask /8 - /8 /8 - /8
Next hop 47.1.1.1 - 47.1.1.1 47.2.1.1 - 47.2.1.1
Cost 1 - 1 1 - 1
Circuit Id COLAN--shelf#- - COLAN--shelf#- COLAN--shelf#- - COLAN--shelf#-
X X X X
6 Set up ARP proxy
Add address range
for ARP proxy:
First address 47.1.1.18 - 47.1.1.18 47.2.1.18 - 47.2.1.18
Last address 47.1.1.20 - 47.1.1.20 47.2.1.20 - 47.2.1.20
Note 1: The gateway 6500 network element requires an OSPF router with static redistribution. The non-gateway 6500
network elements only require a basic OSPF router without any redistribution.
Note 2: A 0.0.0.0/0.0.0.0 default route can be used.
Note 3: OSC cost of 10 shown for links within the managed section. The cost of the OSC link between NE3 and NE4, however,
should be set sufficiently high to keep traffic within each managed section even under failure scenarios. In this example,
assuming an ILAN cost of 10, an OSC cost >20 would be sufficient.


configuration
are connected to the external DCN and act as the gateway network element
for the other 6500 network elements. Each gateway network element uses
proxy ARP for the connected subnet (subnet A for NE1 and subnet B for NE4)
and NAT to translate between the public and Private-IP addresses. Two GNEs
on the same subnet is also supported. In the case where both GNEs reside
on the same subnet, It is recommended that the GNEs have separate IP
address ranges for Proxy Arp and NAT.
Each 6500 network element is assigned a private SHELF IP address. The

COLAN-X interfaces on the gateway network elements are assigned a public
network element. The subnet on the DCN router port that connects to the
COLAN-X port of the gateway network elements must be large enough to
element for which the gateway network element will proxy ARP. DCN router
directly connected to COLAN-X port also need to be in the same subnet.
2-slot shelves are not recommended as a NAT GNEs. Contact Ciena if you
require a 2-slot shelf to be configured as a NAT GNE.
element.

Each GNE requires two public IP addresses - one for the COLAN port and one
allocated for access using its counterpart GNE. The management system
accesses a GNE by either using the COLAN port or the allocated SHELF IP
address through the other GNE. The management system must support two
IP addresses per network element.

Each remote network element is also allocated one public IP address for each
gateway network element (one for subnet A and one for subnet B). These IP
addresses are allocated but not provisioned. The NAT table is provisioned to
map these allocated IP addresses to the actual private SHELF IP addresses.
The NAT at the gateway network elements translates:
• the public IP addresses to private addresses (incoming packets)
• the Private-IP addresses to public IP addresses (outgoing packets)
CAUTION
SHELF IP address
The NAT tables and the proxy ARP range must not include
the SHELF IP address of the gateway network element on
which the NAT table and the proxy ARP range are
provisioned (but must include the other gateway network
element).
In addition, a default route (static route) is provisioned at each gateway

network element which is redistributed in the IISIS or OSPF router. The static
route cost and the metric cost of the static route in the redistribution entry must
be different at each gateway network element (assign a lower static route cost
and a metric cost to the preferred gateway network element).
elements.
For systems with Photonic equipment, the OSC channel must be setup to
require it. OSPF runs on the OSC, IISIS is not supported on the OSC. GCC

NAT implementation rules

You must observe the following rules when you implement the NAT feature:
• The 6500 NAT does not support a mixed configuration of nodes that use
NAT and those that do not use NAT. If NAT is used on the gateway network
element, all the subtending nodes from the gateway network element must
be added to the NAT table on the gateway network element. If a node is
not included in the NAT table, connections originated from that node to the
external DCN will fail.
ATTENTION
6500 NAT does not support provisioning of COLAN-A interface.
• 6500 NAT does not support passive FTP sessions where the client is the
subtending network element and the server is in the external DCN. If using
a dual GNE with NAT configuration, you must ensure that all subtending
network elements use active FTP only.
• The Prime parameter indicates whether the remote SHELF IP address is
used for mapping of incoming packets. Select Yes (default) if SHELF IP
address is used. Select No if IP addresses on other interfaces are used for
mapping of incoming packets (for example, an ILAN interface provisioned
with an IP address).
• If a 6500 network element has an ILAN port with a numbered IP address,
the NAT table must contain two entries. One entry maps the SHELF IP
address to the allocated external IP address, the other entry maps the
ILAN IP address to the same allocated external SHELF IP address. NAT
entries are not required for un-numbered ILAN ports (0.0.0.0).
• If intrusion detection is set to Source Based on certain comms
configuration (TL1 Gateway, Proxy ARP/NAT, and Private-IP) and
repeated intrusion attempts occur, the user with valid user IDs and
passwords can be locked out of the NEs. To avoid this, set the intrusion
detection to User Based instead of Source Based.


Figure 1-43
DCN example 9 diagram—Redundant NAT GNE configuration
OneControl
47.1.1.1/29
Subnet: 47.1.1.0/29
47.1.1.3/29
Subnet A Subnet B
47.114.242.x/24 47.114.244.x/24
DCN
Network
COLAN-X 47.114.244.1/24
47.114.242.1/24 COLAN-X
47.114.242.2/24
47.114.244.2/24
GNE A with GNE B with
ARP proxy for ARP proxy for
IP addresses IP addresses
47.114.242.29 to NE1 NE4 47.114.244.28 to
47.114.242.31 47.114.244.30
NAT table for GNE A 20.2.1.2/32 20.2.1.5/32 NAT table for GNE B
47.114.242.29 -> 20.2.1.3 47.114.244.30 -> 20.2.1.2
47.114.242.30 -> 20.2.1.4 47.114.244.29 -> 20.2.1.3
47.114.242.31 -> 20.2.1.5 47.114.244.28 -> 20.2.1.4
NE2 NE3
/24 is 255.255.255.0
20.2.1.3/32 20.2.1.4/32
/29 is 255.255.255.248
/30 is 255.255.255.252
/32 is 255.255.255.255

Table 1-32

Access NAT - - NAT
Group - - - -
Primary - - - -
2 Set up IP address
Add COLAN-shelf#- Yes No No Yes
X port
Add IP address on
IP address 47.114.242.2 - - 47.114.244.2
Netmask 255.255.255.0 - - 255.255.255.0
ARP proxy On - - On
(SHELF-shelf#):
IP address 20.2.1.2 20.2.1.3 20.2.1.4 20.2.1.5
Netmask 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255
Either:
L1 priority 64 64 64 64
Route redistribution Static distribution - - Static distribution
IP subnet 0.0.0.0 - - 0.0.0.0
Subnet mask 0.0.0.0 - - 0.0.0.0
Metric 10 - - 20
or
routing:
OSPF Router Id 20.2.1.2 20.2.1.3 20.2.1.4 20.2.1.5
Autonomous System On Off Off On
Border Router
IP subnet 0.0.0.0 - - 0.0.0.0
Subnet mask 0.0.0.0 - - 0.0.0.0
Metric 10 - - 20

Table 1-32

Add DCC/GCC:
Either:
SHELF-shelf#:
supported override
DCC/GCC (Note 4 and
Note 5):
Carrier Line/MS, Section/RS, Line/MS, Section/RS, Line/MS, Section/RS, Line/MS, Section/RS
supported override

Table 1-32

or
for:
SHELF-shelf#:
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Cost 0 0 0 0
OSC:
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Cost 10 10 10 10
DCC/GCC (Note 4 and
Note 5):
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
GCC) GCC) GCC) GCC)
GCC) GCC) GCC) GCC)
GCC) GCC) GCC) GCC)
GCC) GCC) GCC) GCC)
6 Set up external routing (see Note 6)
NEs only):
IP subnet 0.0.0.0 - -- 0.0.0.0
Subnet mask 0.0.0.0 - - 0.0.0.0
Next hop 47.114.242.1 - - 47.114.244.1
Cost 2 - - 20
Circuit Id COLAN-shelf#-X - - COLAN-shelf#-X

Table 1-32

7 Set up ARP proxy
Add address range for ARP
proxy:
First address 47.114.242.29 - - 47.114.244.28
Last address 47.114.242.31 - - 47.114.244.30
8 Add NAT table
Add NAT table:
DCN IP address 47.114.242.29 - - 47.114.244.30
Remote NE IP address 20.2.1.3 - - 20.2.1.2
Prime Yes - - Yes
DCN IP address 47.114.242.30 - - 47.114.244.29
Prime Yes - - Yes
DCN IP address 47.114.242.31 - - 47.114.244.28
Prime Yes - - Yes
Note 1: The gateway 6500 network elements require an IISIS or OSPF router with static redistribution. The non-gateway
Note 2: OSPF/IISIS circuit metric are set differently on each GNE. This is done to illustrate a means to specify which
way traffic will flow (through which GNE) when connections are initiated from one of the Remote NEs
Note 4: Depending on the nodal system parameters, GCC0 and GCC1 circuits and associated IISIS or OSPF circuits
can be automatically created when an OTM1/OTM2/OTM3/OTM4/OTMC2/OTM facility is provisioned.
Note 6: If interconnecting with CPL using the ILAN ports, only use the 0.0.0.0/0.0.0.0 default route if CPL is also using
the 0.0.0.0/0.0.0.0 default route.


configuration with nodes running Packet services
Note: This example is included for completeness. However, the
recommended method for accessing the PKT/OTN cross-connect (XC)
circuit pack is using the 6500 CLI and SNMP proxies rather than using the
control-IP, since the control-IP results in the consumption of more IP
addresses. Refer to “DCN example 9—6500 GNE configuration -
redundant NAT GNE configuration” on page 1-215 for Redundant NAT
configuration details, and other examples for other GNE configurations.
This example (see Figure 1-44 on page 1-225) illustrates a redundant NAT
GNE configuration with a subtending shelf that includes a PKT/OTN XC circuit
pack (either single or pair). Refer to the generic redundant NAT example
(“DCN example 9—6500 GNE configuration - redundant NAT GNE
configuration” on page 1-215) for more general information on the redundant
NAT configuration. This example focuses on the Packet services aspects of
this GNE configuration.
Nodes running Packet services have two IP addressable entities: the shelf
interface and the PKT/OTN cross-connect. (The IP address pertains to the
PKT/OTN cross-connect entity, and not necessarily a specific XC circuit pack
in the dual XC case.) In a redundant NAT GNE configuration, these nodes
therefore require two private IP addresses and four public IP addresses (two
per GNE). Each GNE requires the corresponding NAT entries to translate
between the public and private addresses, and the Proxy ARP entry for the
public addresses. In terms of the GNE configuration, a PKT/OTN
cross-connect can be thought of as another subtending node in the network.
This DCN example is very similar to “DCN example 9—6500 GNE

configuration - redundant NAT GNE configuration” on page 1-215, except that
in this case NE3 contains a PKT/OTN cross-connect circuit pack. NE3
therefore has two private addresses: 20.2.1.4 for the shelf interface, and
20.2.1.6 for the PKT/OTN cross-connect. Each GNE (NE1 and NE4) contains
the corresponding NAT entries and proxy ARP entries.
An OSPF circuit is assigned to the PKT/OTN cross-connect

CONTROL-shelf#-GROUP1 interface on NE3 to provide visibility of this
interface, similar to how the shelf interface is advertised. The Autonomous
System Border Router parameter associated with the OSPF router on NE3
must be set to ON for this interface to be advertised.
IISIS is not supported for the PKT/OTN cross-connect

CONTROL-shelf#-GROUP1 interface.

To enable the SAOS-based CLI to reach an external device, the following

provisioning is required on each NE in the NAT system equipped with a
PKT/OTN cross-connect circuit pack (regardless of it being a GNE or RNE).
For this example, a default interface route must be provisioned on the
PKT/OTN cross-connect circuit packs using the interface route add
SAOS-based CLI command:
> interface route add destination 0.0.0.0 subnet 0.0.0.0 gateway
20.2.1.6 metric 10
Optionally, the default route 0.0.0.0 subnet 0.0.0.0 can be replaced by a

specific destination and subnet, depending on customer scenarios.
For syntax and usage of the interface route add command, refer to the
SAOS-based Packet Services Command Reference, 323-1851-610.
Examples of when the CLI must reach an external device include:

• sending an SNMP trap
• setting up the DNS server list for domain name lookup
• transferring configuration files from an external device.

Figure 1-44 on page 1-225 and Table 1-33 on page 1-226 details the DCN
provisioning for the 6500 network elements in the DCN for this DCN example
configuration. For general provisioning guidelines, see “General DCN
provisioning rules” on page 1-97.

Figure 1-44
DCN example 10 diagram—Redundant NAT GNE configuration with nodes running Packet
services

Table 1-33

Access NAT - - NAT
Group - - - -
Primary - - - -
2 Set up IP address
Add COLAN-shelf#- Yes No No Yes
X port
Add IP address on
IP address 47.114.242.2 - - 47.114.244.2
Netmask 255.255.255.0 - - 255.255.255.0
ARP proxy On - - On
(SHELF-shelf#):
IP address 20.2.1.2 20.2.1.3 20.2.1.4 20.2.1.5
Netmask 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255
Add IP address on
PKT/OTN XC
CONTROL-shelf#-
GROUP1:
IP address - - 20.2.1.6 -
Netmask - - 255.255.255.255 -
Non-routing mode - - Off -
For internal OSPF routing:
OSPF Router Id 20.2.1.2 20.2.1.3 20.2.1.4 20.2.1.5
Autonomous System On Off On On
Border Router
IP subnet 0.0.0.0 - - 0.0.0.0
Subnet mask 0.0.0.0 - - 0.0.0.0
Metric 10 - - 20

Table 1-33

Add DCC/GCC:
For internal OSPF routing,
SHELF-shelf#:
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Cost 0 0 0 0
CONTROL-shelf#-
GROUP1
Name CONTROL-shelf#-
GROUP1
Network area 0.0.0.0
Cost 10
Area Off
Password authentication Off
Circuit password -
OSC:
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Cost 10 10 10 10

Table 1-33

DCC/GCC (Note 4 and
Note 5):
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
GCC) GCC) GCC) GCC)
GCC) GCC) GCC) GCC)
GCC) GCC) GCC) GCC)
GCC) GCC) GCC) GCC)
NEs only):
IP subnet 0.0.0.0 - -- 0.0.0.0
Subnet mask 0.0.0.0 - - 0.0.0.0
Next hop 47.114.242.1 - - 47.114.244.1
Cost 2 - - 20
Circuit Id COLAN-shelf#-X - - COLAN-shelf#-X
7 Set up ARP proxy
proxy:
First address 47.114.242.29 - - 47.114.244.27
Last address 47.114.242.32 - - 47.114.244.30

Table 1-33

8 Add NAT table
Add NAT table:
DCN IP address 47.114.242.29 - - 47.114.244.30
Remote NE IP Address 20.2.1.3 - - 20.2.1.2
Prime Yes - - Yes
DCN IP address 47.114.242.30 - - 47.114.244.29
Prime Yes - - Yes
DCN IP address 47.114.242.31 - - 47.114.244.28
Prime Yes - - Yes
DCN IP address 47.114.242.32 - - 47.114.244.27
Prime Yes - - Yes
Note 1: The gateway 6500 network elements require an OSPF router with static redistribution. The non-gateway 6500
network elements only require a basic OSPF router without any redistribution.
Note 2: OSPF circuit metric are set differently on each GNE. This is done to illustrate a means to specify which way
traffic will flow (through which GNE) when connections are initiated from one of the Remote NEs
Note 4: Depending on the nodal system parameters, GCC0 and GCC1 circuits and associated IOSPF circuits can be
automatically created when an OTM1/OTM2/OTM3/OTM4/OTMC2/OTM facility is provisioned.
Note 5: An OSPF circuit is required for each DCC/GCC provisioned.
Note 6: If interconnecting with CPL using the ILAN ports, only use the 0.0.0.0/0.0.0.0 default route if CPL is also using
the 0.0.0.0/0.0.0.0 default route.


addressing
Figure 1-45 on page 1-231 provides an example of a standalone Private-IP
network. In the Private-IP example, a default route to the GNE is distributed to
the Remote NEs (RNEs) which allows the RNEs to originate connections and
send packets using the DCN IP addresses.
The external IP DCN to RNE management access is as follows:

• Through TL1 Gateway. This is the primary TL-1 access to the RNEs for
Private-IP configurations. The TL1 Gateway GNE attribute is enabled on
the GNE, allowing it to forward TL-1 to the RNEs. The RNE attribute is
enabled on the RNEs, allowing them to accept TL-1 sessions from the
gateway on the GNE.
• For Telnet, a Reverse Port NAT entry is added for port 23 for each RNE
ATTENTION
TL1 Gateway can be used to gain access to RNEs in order to make
provisioning changes and retrieve them. In order to do this, the Span of
Control (SOC) needs to be provisioned. The SOC is setup on the GNE (using
ENT-NE-LIST TL-1 command), and the TID of every RNE that the GNE can
connect to, is entered in the SOC.
The shelf IP addresses are private. The COLAN interface on the GNE has a
public address. The GNE distributes the static route to the RNEs.

Figure 1-45
DCN example 11 diagram—6500 Private-IP address
47.3.3.3 47.4.4.4
DCN
47.1.1.1
COLAN-X
GNE
Shelf
10.1.1.1
6500
RNE1 RNE2
Shelf Shelf
10.1.1.3 10.1.1.4
Legend
= Subnet 1: private IP, includes all NEs
= GNEs interface to DCN as simple hosts

(GNEs may be on the same or on a different shelf)

Table 1-34
Parameters GNE1 RNE1 RNE2

Name GNE-shelf# - -
Configuration standalone - -
Access Private-IP - -
Group - - -
Primary - - -
GNE subnet name (Note 1) Subnet 1 - -
2 Set up NE IP address
Add COLAN-1-X port Yes No No
Add IP address on COLAN-1-X
port:
IP address 47.1.1.1 - -
Netmask 255.255.255.0 - -
Non-routing mode Off - -
ARP proxy Off - -
Add IP address on circuitless IP
(SHELF-1):
IP address 10.1.1.1 10.1.1.3 10.1.1.4
Netmask 255.255.255.255 255.255.255.255 255.255.255.255

Table 1-34

3 Set up internal routes (IISIS or OSPF) (Note 2)
Add static IP route (gateway NE
only):
IP subnet 0.0.0.0 - --
Subnet mask 0.0.0.0 - -
Next hop 47.1.1.2 - -
Cost 2 - -
Circuit Id COLAN-1-X - -
For internal IISIS routing:
Route summarization: On On On
Route redistribution Static redistribution - -
IP subnet 0.0.0.0 - -
Metric 10 - -
Metric type External - -
OSPF Router Id: 10.1.1.1 10.1.1.3 10.1.1.4
Route summarization: ON ON ON
Autonomous System Border
Router: On Off Off
Route redistribution Static Redistribution - -
IP subnet: 0.0.0.0 - -
Subnet mask: 0.0.0.0 - -
Metric: 10 - -
Metric type: External - -
4 Set up DCC (Note 3)
Add DCC on:
OC-192/STM-64 in slot 5:
Carrier Line/MS Line/MS Line/MS
Either:
a. For internal IISIS routing, add
IISIS circuits for:
SHELF-shelf#:
Neighbor protocols supported Off Off Off
override

Table 1-34

GCC0/GCC1) GCC0/GCC1), GCC0/GCC1)
override
or
SHELF-shelf#:
Name SHELF-shelf# SHELFSHELF-shelf# SHELFSHELF-shelf#
Network area 0.0.0.0 0.0.0.0 0.0.0.0
Cost 0 0 0
Area Off Off Off
OSC:
Network area 0.0.0.0 0.0.0.0 0.0.0.0
Cost 10 10 10
Area Off Off Off
Network area 0.0.0.0 0.0.0.0 0.0.0.0
Area Off Off Off

Table 1-34

Note 1: OneControl also requires this subnet name to be configured on each shelf within the span of control of the GNE.
For further details, refer to “OneControl considerations for Private-IP GNE configurations” on page 1-94.
non-gateways 6500 network element just requires a basic IISIS or OSPF router without any redistribution.
Note 3: Assumes line/MS DCC on OC-192/STM-64 circuit pack is slots 5 and 6 is used to connect 6500 network
elements. Section/RS DCC could be used (as long as far end setting is same).
Note 4: Depending on the nodal system parameters, GCC0 and GCC1 circuits and associated IISIS or OSPF circuits
can be automatically created when an OTM1/OTM2/OTM3/OTM4/OTMC2/OTM facility is provisioned (not applicable to
SuperMux and 20G (2+8)xOC-n/STM-n LO).
Table 1-35
DCN example 11—6500 Reverse Port NAT provisioning parameters
Parameters (Note 1)
1 Provision Reverse Port NAT at GNE1
Port Type TCP TCP TCP
DCN Port (Note 2) 52052 52053 52054
RNE IP 10.1.1.2 10.1.1.3 10.1.1.4
RNE Port 23 23 23
Note 1: The example above is for Telnet access to remote NEs using Reverse Port NAT.
Reverse Port NAT entries also need to be created for any ports the user wants to access on
the remote NEs from the DCN. For a complete list of ports used by network elements see
Table 1-12 on page 1-88.
Note 2: These DCN port values assume the default NATBASEPORT value of 50000 is used.
Refer to “Reverse Port NAT” on page 1-87 or more information.
Table 1-36
DCN example 11—6500 TL1 Gateway provisioning parameters
1 Provision TL1 Gateway
GNE Enable Disable Disable
RNE Disable Enable Enable

DCN example 12—6500 GNE configuration - redundant Private-IP

addressing
Figure 1-46 on page 1-237 provides an example of a Redundant Private-IP
network. In the Private-IP example, a default route to the GNE is distributed to
the Remote NEs (RNEs) which allows the RNEs to originate connections and
send packets using the DCN IP addresses.

the GNE shelves, allowing them to forward TL-1 to the RNEs. The RNE
attribute is enabled on the RNEs, allowing them to accept TL-1 sessions
from the gateway on the GNEs, and is also enabled on the GNEs to allow
each GNE to accept TL-1 sessions from the other GNEs.
• For Telnet, a Reverse Port NAT entry is added for port 23 for each RNE.
ATTENTION
The shelf IP addresses are private. The COLAN interfaces on the GNEs have
public addresses. Both GNEs distribute the static route to the RNEs.

Figure 1-46
Management
47.3.3.3
DCN
47.1.1.1 47.2.2.2
Public GNE1 GNE2
Private
Shelf
10.1.1.1
Shelf
Each GNE 10.1.1.2
distributes DCN
reachability info OSPF/iISIS
to the RNEs in
the private
network RNE1 RNE2
Shelf Shelf
10.1.1.3 10.1.1.4

Table 1-37
Parameters GNE1 RNE1 RNE2 GNE2

Access Private-IP - - Private-IP
Group - - - -
Primary - - - -
GNE subnet name Subnet 1 - - Subnet 1
(Note 1)
Add COLAN-1-X port Yes No No No
Add IP address on
COLAN-1-X port: Yes
IP address 47.1.1.1 - - 47.2.2.2
Netmask 255.255.255.0 - - 255.255.255.0
Add IP address on
circuitless IP (SHELF-1):
IP address 10.1.1.1 10.1.1.3 10.1.1.4 10.1.1.2
Netmask 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255

Table 1-37

3 Set up routing (Note 2)
Add static IP route
(gateway NE only):
IP subnet 0.0.0.0 - - 0.0.0.0
Subnet mask 0.0.0.0 - - 0.0.0.0
Next hop 47.1.1.2 - - 47.2.2.1
Cost 2 - - 2
Circuit Id COLAN-1-X - - COLAN-1-X
L1 priority 64 64 64 64
Route redistribution Static redistribution - - Static redistribution
IP subnet 0.0.0.0 - - 0.0.0.0
Subnet mask 0.0.0.0 - - 0.0.0.0
Metric 10 - - 10
For internal OSPF
routing:
OSPF Router Id: 10.1.1.1 10.1.1.3 10.1.1.4 10.1.1.2
Route summarization ON ON ON ON
Autonomous System
Border Router: On Off Off On
Route redistribution Static Redistribution - - Static Redistribution
IP subnet 0.0.0.0 - - 0.0.0.0
Subnet mask 0.0.0.0 - - 0.0.0.0
Metric 10 - - 10
Add DCC on:
Carrier Line/MS Line/MS Line/MS Line/MS
Carrier Line/MS Line/MS Line/MS Line/MS

Table 1-37

Either:
for:
SHELF-shelf#:
supported override
DCC/GCC (Note 4 and
Note 5):
GCC0/GCC1), GCC0/GCC1), GCC0/GCC1) GCC0/GCC1
supported override

Table 1-37

or
for:
SHELF-shelf#:
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Cost 0 0 0 0
OSC:
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Cost 10 10 10 10
DCC/GCC (Note 4 and
Note 5):
Network area 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
GCC) GCC) GCC) GCC)
Note 1: OneControl also requires this subnet name to be configured on each shelf within the span of control of the GNE. For
further details, refer to “OneControl considerations for Private-IP GNE configurations” on page 1-94.
Note 2: The gateway 6500 network element requires an IISIS or OSPF router with static redistribution. The non-gateway
Note 3: Assumes line/MS DCC on OC-192/STM-64 circuit pack is slots 5 and 6 is used to connect 6500 network elements.
Section/RS DCC could be used (as long as far end setting is same).

Table 1-38
DCN example 12—6500 Reverse Port NAT provisioning parameters
Parameters (Note 1)
DCN Port (Note 2) 52052 52053 52054
RNE IP 10.1.1.2 10.1.1.3 10.1.1.4
RNE Port 23 23 23
DCN Port (Note 2) 52051 52053 52054
RNE IP 10.1.1.1 10.1.1.3 10.1.1.4
RNE Port 23 23 23
Note 1: The example above is for Telnet access to remote NEs using Reverse Port NAT.
Reverse Port NAT entries also need to be created for any ports the user wants to access on the
remote NEs from the DCN. For a complete list of ports used by network elements see Table 1-12
on page 1-88.
Note 2: These DCN port values assume the default NATBASEPORT value of 50000 is used.
Refer to “Reverse Port NAT” on page 1-87 or more information.
Table 1-39

GNE Enable Disable Disable Enable
RNE Enable Enable Enable Enable


Figure 1-47 on page 1-244 provides an example of a standalone Private-IP
configuration. In the Private-IP example, a default route to the GNE is
distributed to the Remote NEs (RNEs) which allows the RNEs to originate
connections and send packets using the DCN IP addresses.

the GNE, allowing it to forward TL-1 to the RNEs. The RNE attribute is
enabled on the RNEs, allowing them to accept TL-1 sessions from the
gateway on the GNE.
• For Telnet, a Reverse Port NAT entry is added for port 23 for each RNE
ATTENTION

Figure 1-47
47.3.3.3 47.4.4.4
DCN
47.1.1.1
COLAN-X
GNE
Shelf
10.1.1.1
6500
RNE1 RNE2
Shelf Shelf
10.1.1.3 10.1.1.4
Legend
= Subnet 1: private IP, includes all NEs
= GNEs interface to DCN as simple hosts

(GNEs may be on the same or on a different shelf)
Note: GNE is expected to be a dual SP shelf

Table 1-40
Parameters GNE RNE1 RNE2

Name GNE-shelf# - -
Configuration standalone - -
Access Private-IP - -
Group - - -
Primary - - -
GNE subnet name (Note 1) Subnet 1 - -
Add COLAN-1-X port Yes No No
Add IP address on COLAN-1-X port:
IP address 47.1.1.1 - -
Netmask 255.255.255.0 - -
ARP proxy Off - -
Add IP address on circuitless IP
(SHELF-1):
IP address 10.1.1.1 10.1.1.3 10.1.1.4
Netmask 255.255.255.255 255.255.255.255 255.255.255.255

Table 1-40

3 Set up routing (Note 2)
Add static IP route (gateway NE
only):
IP subnet 0.0.0.0 - -
Next hop 47.1.1.2 - -
Cost 2 - -
Circuit Id COLAN-1-X - -
Route redistribution Static redistribution - -
IP subnet 0.0.0.0 - -
Metric 10 - -
OSPF Router Id: 10.1.1.1 10.1.1.3 10.1.1.4
Route summarization: ON ON ON
Router: On Off Off
Route redistribution Static Redistribution - -
IP subnet: 0.0.0.0 - -
Subnet mask: 0.0.0.0 - -
Metric: 10 - -
Metric type: External - -
Add DCC on:
Either:
a. For internal IISIS routing, add IISIS
circuits for:
SHELF-shelf#:
override

Table 1-40

GCC0/GCC1), GCC0/GCC1), GCC0/GCC1)
override
or
b. For internal OSPF routing, add
OSPF circuits for:
SHELF-shelf#:
Network area 0.0.0.0 0.0.0.0 0.0.0.0
Cost 0 0 0
Area Off Off Off
OSC:
Network area 0.0.0.0 0.0.0.0 0.0.0.0
Cost 10 10 10
Area Off Off Off
Network area 0.0.0.0 0.0.0.0 0.0.0.0
Area Off Off Off

Table 1-40

Note 1: OneControl also requires this subnet name to be configured on each shelf within the span of control of the
GNE. For further details, refer to “OneControl considerations for Private-IP GNE configurations” on page 1-94.
non-gateway 6500 network elements only require a basic IISIS or OSPF router without any redistribution.
elements. Section/RS DCC could be used (as long as far end setting is same).
Table 1-41
DCN example 13—6500 reverse port NAT provisioning parameters
Parameters (Note 1)
1 Provision reverse port NAT at GNE1
Port Type TCP TCP -
DCN Port (Note 2) 52052 52053 -
RNE IP 10.1.1.2 10.1.1.3 -
RNE Port 23 23 -
Note 1: The example above is for FTP access to the DCN for remove NEs. Reverse Port NAT entries
also need to be created for any ports the user wants to access on the remote NEs from the DCN. For a
complete list of ports used by network elements see Table 1-12 on page 1-88.
Note 2: These DCN port values assume the default NATBASEPORT value of 50000 is used. Refer to
“Reverse Port NAT” on page 1-87 for more information.
Table 1-42

GNE Enable Disable Disable
RNE Disable Enable Enable

DCN example 14—using single 6500 GNE with IISIS through 6500 network
to reach remote 6130 network elements
In this example (refer to Figure 1-48 on page 1-250 and Figure 1-49 on
page 1-251), a single 6500 network element is used as the GNE to establish
communication between the external DCN and the 6130 and the 6500
network elements.
IISIS routing protocol is used with auto-tunneling to establish communication

from the 6500 GNE to the remote 6130 through the 6500 network.
The remote 6130 NEs are provisioned as proxy ARP neighbors at the 6500
GNE.
DCN provisioning details

Table 1-43 on page 1-252, Table 1-44 on page 1-252, and Table 1-45 on
page 1-254 detail the DCN parameters for this DCN example configuration.
ATTENTION
For parameters not listed, use the default settings.

Figure 1-48
DCN example 14 diagram—Single 6500 GNE with IISIS to remote 6130 NEs
OneControl R1 IP
IP and R2
OSI DCN
OSI area (for example, 0002)

IP
6500
H
61x0
A
6500
Target F
node
MS DCC 6500
61x0 G
B
61x0
C
Packets routed using iIS-IS/PPP
Legend
= iIS-IS/OSI/LAPD/DCC
= iIS-IS/IP/PPP/DCC
= OSPF/IP/PPP/DCC
= IP/GRE/OSI
= OSI
= Static IP route/IP/PPP/DCC
61x0 = 6110 or 6130

Figure 1-49
DCN example 14 diagram—IP logical view
OSPF area 0.0.0.0

OneControl
OSI area 0002
Legend
= IP connection
= OSPF routing between NEs/Router
= iISIS routing between NEs
= Static/Default routing

Table 1-43
Parameters 6130 A 6130 B 6130 C

1 Set up IP address
LAN-1-6 port:
IP address 192.168.1.254 192.168.1.254 192.168.1.254
Netmask /24 /24 /24
Default gateway - - -
Router ID:
IP address 47.1.3.65 47.1.3.66 47.1.3.67
Netmask /32 /32 /32
2 Set up IP routing
Ethernet OSPF enable No No No
OSPF area - - -
3 Set up IISIS (Nodal level)
IISIS Enable: Enable Enable Enable
MAA 1 490000 490000 490000
MAA 2 - - -
MAA 3 - - -
4 Set up DCC
STM/OC port 1:
MTU 1518 1518 1518
IISIS Enable Enable Enable
STM/OC port 2
MTU 1518 1518 1518
IISIS Enable Enable Enable
Table 1-44
Parameters 6500 H 6500 G 6500 F

1 Set up IP address
Interface: COLANX - -
IP address 47.1.3.11 - -
Netmask /29 - -
Interface: - - -
IP address - - -
Netmask - - -
Default gateway - - -
Circuitless IP (SHELF IP):
IP address 47.1.3.11 47.1.3.11 47.1.3.11
Netmask /29 /29 /29

Table 1-44
Parameters 6500 H 6500 G 6500 F

2 Set up IP routing
Global Routing IIS-IS IIS-IS IIS-IS
Route redistribution OSPF redistribution - -
Ethernet OSPF enable COLANX - -
OSPF area 0.0.0.0 - -
3 Set up DCC
Interface 1: S-5-1 S-5-1 S-1-1
MTU 1500 1500 1500
Interface 2: S-6-1 S-6-1 S-2-1
MTU 1500 1500 1500
Interface 3: - - S-5-1
Protocol - - PPP
MTU - - 1500
Interface 4: - - S-6-1
Protocol - - PPP
MTU - - 1500
4 Set up MAA
OSI Local MAA:
MAA 1 490000 490000 490000
MAA 2 - - -
MAA 3 - - -
5 Set up Proxy ARP
Proxy ARP Neighbor IP addresses:
Neighbor 1 47.1.3.65 - -
Neighbor 2 47.1.3.66 - -
Neighbor 3 47.1.3.67 - -
Neighbor 4 47.1.3.93 - -
Neighbor 5 47.1.3.94 - -

Table 1-45
DCN example 14—Router and OneControl DCN provisioning details
Parameters Router 1 Router 2 OneControl
1 Set up IP address
Interface: - - -
IP address 47.1.1.1 47.1.3.1 -
Netmask /29 /29 -
Interface: - - -
IP address - - 47.1.1.5
Netmask - - /29
Default gateway - - 47.1.1.1
Circuitless IP:
IP address 47.1.1.128 47.1.1.129 -
Netmask /32 /32 -
2 Set up IP routing
Global OSPF enable Yes Yes -
OSPF area 0.0.0.0 0.0.0.0 -
Ethernet OSPF enable Yes Yes -
OSPF area 0.0.0.0 0.0.0.0 -

DCN example 15—using single 6500 GNE with IISIS to reach remote 6130
network elements in a SNCP/UPSR ring configuration with generic
SDH/SONET equipment
In this example (see Figure 1-50 on page 1-256, Figure 1-51 on page 1-257,
and Figure 1-52 on page 1-258), a single 6500 network element is used as the
GNE to establish communication between the external DCN and the 6130
within a SNCP/UPSR ring with generic SONET/SDH equipment (such as
OM 3000, OM 4000, and TN-1C network elements).
IISIS routing protocol is used with auto-tunneling to establish communication

from the 6500 GNE to the remote 6130 network elements.
The remote 6130 NEs are provisioned as proxy ARP neighbors at the 6500
GNE.
DCN provisioning details

Table 1-46 on page 1-259 and Table 1-47 on page 1-260 detail the DCN
parameters for this configuration.
ATTENTION
For parameters not listed, use the default settings.

Figure 1-50
DCN example 15 diagram—Single 6500 with IISIS to reach remote 6130 NEs in SNCP/UPSR with
generic SDH/SONET equipment
OSI and
OneControl R1 IP DCN
IP
R2
IP
6500
61x0 H
A
XXX
F
6500
61x0
RS DCC G
B
XXX
C
Legend
= iIS-IS/OSI/LAPD/DCC
= iIS-IS/IP/PPP/DCC
= OSPF/IP/PPP/DCC
= IP/GRE/OSI
= OSI
= Static IP route/IP/PPP/DCC
61x0 = 6110 or 6130

Figure 1-51
DCN example 15 diagram—IP logical view
OSPF area 0.0.0.0

OneControl
61x0 A
6500 H
61x0 B
OSI area 0002 6500 G
Legend
= IP connection
= OSPF routing between NEs/Router
= iISIS routing between NEs
= Static/Default routing
61x0 = 6110 or 6130

Figure 1-52
DCN example 15 diagram—IISIS / ISIS logical view
OneControl R1
OSI
OSI and R2
IP DCN
6500
H
61x0
RS DCC A XXX
F
6500
G
61x0
B
XXX
C
Legend
= OSI connection
= iISIS/ISIS routing between NEs
61x0 = 6110 or O6130

Table 1-46
DCN example 15—6130, 6500, and OSI NE DCN provisioning details
Parameters 6130 A 6130 B NE C NE F 6500 G 6500 H

1 Set up IP address
LAN-1-6 port: COLANX
IP address 192.168.1.254 192.168.1.254 - - - 47.1.3.2
Netmask /24 /24 - - - -
Default gateway - - - - - -
Shelf IP (Router ID on
6130):
IP address 47.1.3.65 47.1.3.66 - - 47.1.3.93 47.1.3.92
Netmask /32 /32 - - /32 /32
2 Set up IP routing
Global Routing - - ISIS ISIS IISIS IISIS
Route redistribution - - - - - OSPF
redistribution
Ethernet OSPF enable Disable Disable - - - Yes
OSPF area - - - - - 0.0.0.2
Static routing 1
Address 0.0.0.0 0.0.0.0
Netmask /0 /0
Next hop IP address 0.0.0.0 0.0.0.0
Next hop interface AGRE AGRE
Advertise No No
3 Set up IISIS (nodal level)
IISIS Enable: Enable Enable
MAA 1 490000 490000
MAA 2 - -
MAA 3 - -
4 Set up DCC
Interface 1: STM/OC P1 STM/OC P1 S-5-1 S-5-1 S-5-1 S-5-1
Protocol LAPD PPP LAPD LAPD LAPD PPP
MTU 512 1518 512 512 512 1500
IISIS Enable Enable Yes Yes
Interface 2 STM/OC P2 STM/OC P2 S-6-1 S-6-1 S-6-1 S-6-1
Protocol PPP LAPD LAPD LAPD PPP LAPD
MTU 1518 512 512 512 1500 512
IISIS Enable Enable Yes Yes
Interface 3 - - - S-1-1 - -
Protocol - - - LAPD - -
MTU - - - 512 - -
Interface 4 - - - S-2-1 - -
Protocol - - - LAPD - -
MTU - - - 512 - -

Table 1-46
DCN example 15—6130, 6500, and OSI NE DCN provisioning details (continued)
Parameters 6130 A 6130 B NE C NE F 6500 G 6500 H

5 Set up proxy ARP
Proxy ARP Neighbor IP - - - - -
addresses:
Neighbor 1 47.1.3.65
Table 1-47
DCN example 15—Router and OneControl DCN provisioning details
Parameters Router 1 Router 2 OneControl

1 Set up IP address
Interface: -
IP address 47.1.1.1 47.1.3.1 -
Netmask /29 /29 -
Interface: - - -
IP address - - 47.1.1.5
Netmask - - /29
Default gateway - - 47.1.1.1
Circuitless IP:
IP address 47.1.1.128 47.1.1.129 -
Netmask /32 /32 -
2 Set up IP routing
Global OSPF enable Yes Yes -
OSPF area 0.0.0.0 0.0.0.0 -
Ethernet OSPF enable Yes Yes -
OSPF area 0.0.0.0 0.0.0.0 -

DCN example 16—management of OM 4000 through 6500 with IP only

external DCN
This design (see Figure 1-53 on page 1-262) is used when managing
OM 4000 network elements (or Optical TN-1C network elements) through the
6500 network elements. As the 6500 has OSI capability, the OM 4000 network
elements are managed natively after the tunnel through the access DCN has
been terminated.
In this example, The EC-1 management site is used to tunnel the OSI data
over IP to the single gateway 6500 network element. The gateway 6500
network element de-encapsulates the OSI packets which are then routed
through the other 6500 network elements as native OSI packets to the
OM 4000 network elements.
ATTENTION
Refer to the appropriate EC-1 engineering guidelines in the “24xDS3/EC-1
working and protection” section of the “Electrical circuit packs and I/O
panels” chapter in Electrical Circuit Packs, 323-1851-102.2, to verify the
number of tunnels supported and the number of subtended NEs supported
by a tunnel.
network element. Each SHELF IP address is visible within the external DCN.
The example assumes all network elements are in the default 49000 MAA.
The DCC interfaces between the 6500 network elements are configured for
PPP. The DCC interfaces on the 6500 network element connecting to the
OM 4000 network elements are configured for LAPD, as OSI is used.

elements in the DCN for this configuration. For general provisioning
guidelines, see “General DCN provisioning rules” on page 1-97.
For information and procedures on EC-1 provisioning, see Part 1 of

Configuration - Provisioning and Operating, 323-1851-310/Configuration -
Provisioning and Operating for T-Series, 323-1851-311.

Figure 1-53
DCN example 16 diagram—Managing OM 4000 through 6500 with IP only external DCN
EC-1
OneControl
48.1.1.2/29
Tunnel Terminating IP
48.1.1.1/29 Addresses (EC-1 and 6500)
IP 48.1.1.2 and 48.1.1.13
R2
48.1.1.3/29
48.1.1.9/30
IP Only DCN
OSPF Area 0
R1
48.1.1.14/30
OSPF
COLAN Area 1
48.1.1.13/30
NE1
48.1.1.41/32
iISIS routing 48.1.1.43/32
of IP and CLNP
NE2 over DCC
NE3 NE5
48.1.1.42/32 iISIS routing

of CLNP
6500 over DCC
NE4 NE6
OM4000
/29 is 255.255.255.248
/30 is 255.255.255.252
/32 is 255.255.255.255

Table 1-48

1 Set up IP address
Add COLAN-shelf#-X port Yes No No
Add IP address on
IP address 48.1.1.13 - -
Netmask 255.255.255.252 - -
ARP proxy Off - -
(SHELF-shelf#):
IP address 48.1.1.41 48.1.1.42 48.1.1.43
Netmask 255.255.255.255 255.255.255.255 255.255.255.255
2 Set up IP routing (see Note 1 and Note 2)
Route redistribution OSPF distribution - -
IP subnet 48.1.1.0 - -
Subnet mask 255.255.255.248 - -
Metric 2 - -
Add OSPF router: Yes No No
OSPF Router Id 48.1.1.41 - -
Route summarization On - -
Autonomous System On - -
Border Route
Route Redistribution ISIS distribution - -
IP subnet 48.1.1.40 - -
Subnet mask 255.255.255.248 - -
Metric 10 - -

Table 1-48

Add DCC on:
OC192/STM64 in slot 5:
OC12/STM4 in slot 1 port 1:
Carrier - - Line/MS
Protocol - - LAPD
L2 size (Note 4) - - 512
Carrier - - Line/MS
Protocol - - LAPD
L2 size (Note 4) - - 512
4 Add OSI over IP tunnel
Add tunnel:
Name GRE-IP-1 - -
Source IP address 48.1.1.13 - -
Destination IP address 48.1.1.2 - -

Table 1-48

SHELF-shelf#:
override
DCC on OC192 /STM64 in
slot 5:
Name OC192/STM64-shelf#-5-1 OC192/STM64-shelf#-5-1 OC192/STM64-shelf#-5-1
override
slot 6:
Name OC192/STM64-shelf#-6-1 OC192/STM64-shelf#-6-1 OC192/STM64-shelf#-6-1
override
DCC on OC12 /STM4 in slot 1
port 1:
Name - - OC12/STM4-shelf#-1-1
Circuit default metric - - 5
Neighbor protocols supported - - OSIONLY
override
DCC on OC12 /STM4 in slot 2
port 1:
Name - - OC12/STM4-shelf#-2-1
Neighbor protocols supported - - OSIONLY
override
GRE-IP-1:
Name -
Circuit default metric GRE-IP-1 - -
Neighbor protocols supported 4 - -
override Off -

Table 1-48

COLAN-shelf#-X
Name COLAN-shelf#-X - -
Network area 0.0.0.1 - -
Cost 0 - -
Area Off - -
Password authentication Off - -
Note 1: Only the gateway 6500 network element requires an OSPF router.
elements and line/MS DCC on port 1 of OC-12/STM-4 circuit pack is slots 1 and 2 is used to connect to OM 4000
network elements. Section/RS DCC could be used (as long as far end setting is same), see “Redundant OSPF
configuration with multiple OSPF area configuration at a 3-way branching site” on page 1-124.
Note 4: If connecting to other network element types make sure that the L2 size (and line/MS or section/RS
selection) is the same on the other network elements and the 6500 network elements. The OM 4000 network
elements have a L2 size of 512 which cannot be configured. The 6500 network elements default to a L2 size of 1304.
When connecting to OM 4000 network elements, you must change the settings on the 6500 network elements to
512.

DCN example 17—management of 6500 through non-6500 network

element
This design (see Figure 1-54 on page 1-268) is used when managing 6500
network elements through a non-6500 network element. The example uses
OM 4000 series network elements, but the design equally applies to other
network element type (for example, OM 3500 or Optical TN-1C network
elements).
Auto-tunneling is used to package the IP packets for the subtended 6500

network elements into OSI packets to traverse the OSI only network. Using
the GRE auto-tunneling and the IISIS routing, the 6500 network elements can
identify dual routers that can be used for the origination and termination of
dynamically tunneled data. In this example, an auto-tunnel will be established
between NE2 and NE4 because they are the two closest IP-capable 6500
shelves that border the OSI network.
In the example, NE2 (47.1.3.2) identifies that there is an OSI only network
portion between it and the destination network element. If an IP packet
destined for NE4 (47.1.3.4) arrives at NE2, NE2 encapsulates (auto-tunnels)
the IP information in an OSI PDU. The OSI PDU destination address will be
the OSI of NE4. All intermediate OM 4000 network elements and 6500
network elements will route the packet using IISIS routes to the destination.
Similarly, IP packets forwarded toward NE2 from NE4 will have an OSI PDU
destination address of NE2.
This example uses the flat DCN model therefore public IP addresses are used
for the 6500 SHELF addresses which are visible in the external DCN.
PPP. The DCC interfaces on the 6500 network element connecting to the OM
4000 network elements are configured for LAPD, as OSI is used.

This configuration does not require any special provisioning as auto-tunneling
is used to traverse the OSI only network.
elements in the DCN for this DCN example configuration. For general

Figure 1-54
DCN example 17 diagram—Managing 6500 through non-6500 network
OneControl EC-1
47.1.1.1/24 47.1.1.2/24
DGW 471.1.254/24 DGW 47.1.1.254/24 OSI
IP OSI Area A
OSPF 47.1.1.254/24
Area 39.x..x.000A
0000 R3 L2 47.1.2.3/32
L2 L2
47.1.2.1/32 L1/L2 47.1.2.2/32
39.x..x.000B L2
L2 L2 39.x..x.000B Dual homed
R1 R2 leased bandwidth
47.1.2.4/32 47.1.2.5/32
39.x..x.000B L1 R4 R5 L1
39.x..x.000B
47.1.2.18/28 47.1.2.34/28
OSI OSI
OSPF
Area IP IP
0001
COLAN-X COLAN-X
47.1.2.17/28 47.1.2.33/28 COLAN-A
COLAN-A OSI Area B
NE1 L1 NE3
L1 L1
47.1.3.1/32 47.1.3.3/32
39.x..x.000B iISIS routing 39.x..x.000B
of IP and CLNP
6500 over DCC
NE2
L1
47.1.3.2/32
OM4000 39.x..x.000B ISIS routing
(or any OSI based NE) of CLNP over DCC.
IP is tunneled. L1 39.x..x.000B
OSI Area B
/24 is 255.255.255.0
L1
/28 is 255.255.255.240 39.x..x.000B
L1
/29 is 255.255.255.248
/32 is 255.255.255.255 NE4
39.x..x.000B L1 39.x..x.000B
47.X.X.X = IP address
39.x.x.0000 = OSI area address
47.1.3.4/32

Table 1-49

1 Set up interfaces (LANs and IP addresses)
Add COLAN-shelf#-X port Yes No Yes No
Add IP address on
IP address 47.1.2.17 - 47.1.2.33 -
Netmask 255.255.255.240 - 255.255.255.240 -
Non-routing mode Off - Off -
ARP proxy Off - Off -
(SHELF-shelf#):
IP address 47.1.3.1 47.1.3.2 47.1.3.3 47.1.3.4
Netmask 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255
Add COLAN-shelf#-A port Yes No Yes No
Add IP address on
COLAN-shelf#-A port:
IP address - -
Netmask - -
Non-routing mode Off - Off -
2 Set up MAAs
Edit MAAs
Manual Area Address 1 - - - -
Manual Area Address 2 39.528F.8000.0000. 39.528F.8000.0000. 39.528F.8000.0000. 39.528F.8000.0000
0000.0002.000B 0000.0002.000B 0000.0002.000B .0000.0002.000B
Manual Area Address 3 - - - -
L1 priority 64 64 64 64
Route redistribution OSPF distribution - OSPF distribution -
IP subnet 47.1.1.0 - 47.1.1.0 -
Subnet mask 255.255.255.0 - 255.255.255.0 -
Metric 2 - 2 -
Metric type External - External -
Add OSPF router: Yes No Yes No
OSPF Router Id 47.1.3.1 - 47.1.3.4 -
Route summarization On - On -
Autonomous System On - On -
Border Router
Route redistribution ISIS distribution - ISIS distribution -
IP subnet 47.1.3.0 - 47.1.3.0 -
Subnet mask 255.255.255.248 - 255.255.255.248 -
Metric 10 - 10 -
Metric type External - External -

Table 1-49

Add DCC on:
Carrier Line/MS Line/MS Line/MS -
Protocol PPP PPP PPP -
Carrier Line/MS Line/MS Line/MS -
Protocol PPP PPP PPP -
Carrier - Line/MS - -
Protocol - LAPD - -
L2 size (see Note 4) - 512 - -
Carrier - Line/MS - Line/MS
Protocol - LAPD - LAPD
L2 size (see Note 4) - 512 - 512
SHELF-shelf#:
supported override (OSI
only)
slot 5:
Name OC192/STM64-shelf#- OC192/STM64- OC192/STM64-shelf#- -
5-1 shelf#-5-1 5-1
Circuit default metric 5 5 5 -
Neighbor protocols Off Off Off -
supported override
slot 6:
Name OC192/STM64- OC192/STM64- OC192/STM64- -
shelf#-6-1 shelf#-6-1 shelf#-6-1
Circuit default metric 5 5 5 -
Neighbor protocols Off Off Off -
supported override
COLAN-shelf#-A:
Name COLAN-shelf#-A - COLAN-shelf#-A -
Circuit default metric 4 - 4 -
Neighbor protocols LANOSIONLY - LANOSIONLY -
supported override (Note 5)

Table 1-49

slot 1 port 1:
Name - OC12/STM4-shelf#- - OC12/STM4-shelf#
1-1 -
Circuit default metric - 5 - 1-1
Neighbor protocols - OSIONLY - 5
supported override OSIONLY
slot 6 port 1:
Name - OC12/STM4-shelf#- -
2-1 -
Circuit default metric - 5 -
Neighbor protocols - OSIONLY - -
supported override -
COLAN-shelf#-X
Name COLAN-shelf#-X - COLAN-shelf#-X -
Network area 0.0.0.1 - 0.0.0.1 -
Cost 0 - 0 -
Area Off - Off -
Password authentication Off - Off -
Note 1: Only the gateway 6500 network elements require an OSPF router.
Note 2: The gateway 6500 network element requires an IISIS router with OSPF redistribution. The non-gateway 6500
network elements only require a basic IISIS router without any redistribution.
Note 3: Assumes:
• line/MS DCC on OC-192/STM-64 circuit pack is slots 5 and 6 is used to connect 6500 network elements NE1, NE2, and
NE3
• line/MS DCC on port 1 of OC-12/STM-4 circuit pack is slots 1 and 2 is used to connect NE2 to OM 4000 network
elements
• line/MS DCC on port 1 of OC-12/STM-4 circuit pack is slot 1 is used to connect NE4 to OM 4000 network element.
• section/RS DCC could be used (as long as far end setting is same), see “Redundant OSPF configuration with multiple
OSPF area configuration at a 3-way branching site” on page 1-124.
Note 4: If connecting to other network element types make sure that the L2 size (and line/MS or section/RS selection)
is the same on the other network elements and the 6500 network elements. The OM 4000 network elements have a L2
size of 512, which cannot be configured. The 6500 network elements default to a L2 size of 1304. When connecting to
OM 4000 network elements, you must change the settings on the 6500 network elements to 512.
Note 5: DCN Router connection for COLAN-A can be point-to-point only.

DCN example 18—management of OM 3500 through 6500

OM 3000 network elements through the 6500 network elements.
In this example, the OM 3500 head-end network element with the network
processor (NP) is collocated with the gateway 6500 network element (NE1)
which also has a COLAN connection to the external DCN.
The 6500 network elements forward the OSI only traffic between the OM 3500
head-end network element and the OM 3500 network element subtended
from the 6500 network element (NE3).
Each 6500 network element is assigned a circuitless SHELF IP address from

the same subnet. The COLAN interface on the gateway network element is
gateway network element.
To provide address isolation in this example, DCN tunnels are used between
routers connected to the management systems (for example, OneControl)
and the routers connected to the 6500 gateway network element. All traffic
to/from the 6500 network elements and the management systems are in the
tunnels. Private-IP addresses are used for the 6500 SHELF IP addresses
which are not visible in the external DCN. The ILAN interface used to connect
to the OM 3500 head-end network element does not require an IP address.


Figure 1-55
DCN example 18 diagram—Managing OM 3500 through 6500
MOA
OneControl
10.6.1.2/29
10.6.1.1/29
Subnet: 10.6.1.0/29
10.6.1.3/29 R2
48.3.3.1/30
Carrier
Access
DCN
48.2.2.1/30
48.1.1.14/29 R1
COLAN
NE1 48.1.1.15/29
COLAN ILAN ILAN
OM3500
48.1.1.13/29 with NP
10.5.1.1/32
iISIS routing 10.5.1.3/32
of IP and CLNP
NE2 over DCC
NE3
10.5.1.2/32 iISIS routing

6500 of CLNP
over DCC
OM3500
/29 is 255.255.255.248
/30 is 255.255.255.252
/32 is 255.255.255.255

Table 1-50

1 Set up IP address and LANs
Add IP address on COLAN-1-X port:
IP address 48.1.1.13 - -
Netmask 255.255.255.252 - -
ARP proxy Off - -
IP address
Netmask 10.5.1.1 10.5.1.2 10.5.1.3
Non-routing mode 255.255.255.255 255.255.255.255 255.255.255.255
Add ILAN-shelf#-IN port Off Off Off
Add IP address on ILAN-shelf#-IN port: Yes No No
IP address 0.0.0.0 - -
Netmask 255.255.255.255 - -
Route redistribution OSPF distribution - -
IP subnet 10.6.1.1 - -
Subnet mask 255.255.255.248 - -
Metric 2 - -
Border Router
Route redistribution ISIS distribution - -
IP subnet 10.5.1.1 - -
Subnet mask 255.255.255.248 - -
Metric 2 - -

Table 1-50

Add DCC on:
Carrier - - Section/RS
Protocol - - LAPD
L2 size (Note 4) - - 1304
Protocol - - LAPD
L2 size (Note 4) - - 1304
SHELF-shelf#:
Neighbor protocols supported override Off Off Off
slot 5:
Name OC192/STM64-shelf#- OC192/STM64-shelf#- OC192/STM64-shelf#
5-1 5-1 -5-1
DCC on OC192 /STM64 in slot 6:
Name OC192/STM64-shelf#- OC192/STM64-shelf#- OC192/STM64-shelf#-
6-1 6-1 6-1

Table 1-50

DCC on OC12 /STM4 in slot 1 port 1:
Name - - OC12/STM4-shelf#-
1-1
Neighbor protocols supported override - - OSIONLY
Name - - OC12/STM4-shelf#-
2-1
ILAN-shelf#-IN: - - -
Name ILAN-shelf#-IN - -
Circuit default metric 4 - -
Neighbor protocols supported override Off -
Add OSPF circuit for COLAN-shelf#-X:
Name
Network area COLAN-shelf#-X - -
Cost 0.0.0.0 - -
Area 0 - -
Password authentication Off - -
Circuit password Off - -
- - -
elements and section/RS DCC on port 1 of OC-12/STM-4 circuit pack is slots 1 and 2 is used to connect to OM 3500
network elements.
Note 4: The OM 3500 and 6500 network elements default to a L2 size of 1304. If you change the settings on the
6500 network elements you must also change the settings on the OM 3500 network elements.

R1 is configured as ABRs in this example (alternatively R2 could be the ABR)
with the tunnel interfaces in the backbone area and the LAN interfaces to NE1.
R1 and R2 each have an interface connected to the Router DCN which are
assigned an IP address from the Router DCN. For this example, it is assumed
that this interface is provided by Ethernet.
— IP addresses:
– Ethernet interface connected to Router DCN: 48.2.2.1/30

– Ethernet interface connected to gateway network element:

48.1.1.14/30
— OSPF router
– ABR into OSPF backbone 0.0.0.0
– OSPF circuit on 48.1.1.14 in OSPF area 0.0.0.0
— static route
– destination: 48.0.0.0
– subnet mask: 255.0.0.0
– next hop: 48.2.2.2 (assumed, not shown in example)
— tunnel
– source: 48.2.2.1
– destination: 48.3.3.1 (R2 Ethernet port)
– mode: GRE IP
— IP addresses:
– Ethernet interface connected to Router DCN: 48.3.3.1/30
– Ethernet interface connected to management LAN: 10.6.1.3/29
— OSPF router
– normal router in OSPF backbone 0.0.0.0
– OSPF circuit on 10.6.1.3 in OSPF area 0.0.0.0
— static route
– destination: 48.0.0.0
– subnet mask: 255.0.0.0
– next hop: 48.3.3.2 (assumed, not shown in example)
— tunnel
– source: 47.3.3.1
– destination: 48.2.2.1 (R1 Ethernet port)
– mode: GRE IP

DCN example 19—6500 MSPP and Photonics with OM 3500, using both
OSPF and IISIS
This example (refer to Figure 1-56 on page 1-279), illustrates how a network
consisting of 6500 MSPP and Photonics, along with OM 3500 network
elements, is configured using both OSPF and IISIS to provide the required
management visibility and support the internal Photonics applications.
The OM 3500 head-end network element (NE1) with the network processor
(NP) is connected with the gateway 6500 network element (NE1) over DCC,
and NE1 also has a COLAN connection to the external DCN. 6500 NE1 is
configured as a proxy-ARP GNE (optional, but used in this example) to
support IP communications to the subtending 6500 shelves. The OM 3500 NP
provides access to the subtending OM 3500 NE2 via TL1 Gateway.
IISIS is configured on the OC-192 links that form the five node ring, which
includes 6500 NE1, 6500 NE2, 6500 Photonic AMP, 6500 MSPP, and
OM 3500 NE2; and on the link between OM 3500 NE1 and 6500 NE1. (If the
6500 and OM 3500 NEs are co-located, then ILAN could be used instead of
IISIS.) This forms an OSI network, which supports the OM 3500, allowing
access to OM 3500 NE2 from the NP on OM 3500 NE1 via TL1 Gateway.
Since the OM 3500 supports only LAPD, SDCC links between the 6500 and
OM 3500 are configured with LAPD. 6500-to-6500 links are configured with
PPP.
OSPF is configured on 6500 NE1, 6500 NE2 and the 6500 Photonic AMP, and
runs across the OSC to support Photonics. The SHELF IP addresses for 6500
NE1 and 6500 NE2 each require both an OSPF and an IISIS circuit.
At both 6500 NE1 and 6500 NE2, the SHELF IP address of the 6500 Photonic
AMP is redistributed into IISIS to provide resilient communications between
those shelves and the amplifier shelf in case of fiber breaks.

Table 1-51 on page 1-280 details the DCN parameters this configuration. For
general provisioning guidelines, refer to “General DCN provisioning rules” on
page 1-97.

Figure 1-56
DCN example 19 diagram—Mixed routing protocol (OSPF and IISIS) in same shelf

Table 1-51
Parameters 6500 6500 Photonic 6500 6500 MSPP OM 3500 OM 3500

Photonic- AMP Site Photonic- NE1 NE2
MSPP NE1 MSPP NE2
(GNE)
Name GNE-shelf# - - - NA NA
Configuration Standalone - - - NA NA
Access ARP - - - NA NA
Group - - - - NA NA
Primary - - - - NA NA
2 Set up IP address
Add COLAN-shelf#-X Yes No No No
port
Add IP address on
IP address 47.114.242.2 - - - NA NA
Netmask 255.255.255.0 - - - NA NA
Non-routing mode Off - - - NA NA
ARP proxy On - - - NA NA
(SHELF-shelf#):
IP address 47.114.242.2 47.114.242.3 47.114.242.4 47.114.242.5 NA NA
Netmask 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255 NA NA
Non-routing mode Off Off Off Off NA NA
Add IP address on
OM 3500 NP COLAN:
IP address - - - - 47.114.242.10 -
Netmask - - - - 255.255.255.0 -

Table 1-51

MSPP NE1 MSPP NE2
(GNE)
3 Set up IP routing
Add IISIS router: Yes No Yes Yes NA NA
Router level Level-1 - Level-1 Level-1 NA NA
L1 priority 64 - 64 64 NA NA
Route summarization: On - On On NA NA
Route redistribution OSPF - OSPF - NA NA
distribution distribution
IP subnet 47.114.242.3 - 47.114.242.3 - NA NA
Subnet mask 255.255.255.255 - 255.255.255.255 - NA NA
Metric 10 - 10 - NA NA
Metric type External - External - NA NA
Route redistribution Static distribution - - - NA NA
IP subnet 0.0.0.0 - - - NA NA
Subnet mask 0.0.0.0 - - - NA NA
Metric 10 - - - NA NA
Metric type External - - - NA NA
Add OSPF router: Yes Yes Yes No NA NA
OSPF Router Id 47.114.242.2 47.114.242.3 47.114.242.4 - NA NA
Route summarization On On On - NA NA
Autonomous System On Off Off - NA NA
Border Router
Route redistribution Static distribution - - - NA NA
IP subnet 0.0.0.0 - - - NA NA
Subnet mask 0.0.0.0 - - - NA NA
Metric 10 - - - NA NA
Metric type External - - - NA NA

Table 1-51

MSPP NE1 MSPP NE2
(GNE)
4 Set up Lower Layer DCC/GCC (Note 1)
Add DCC/GCC:
Name OC192/STM64- - OC192/STM64- OC192/STM64- OC192/ OC192/
1-5-1 1-6-1 1-9-1 STM64-11 STM64-11
Carrier SDCC - SDCC SDCC SDCC SDCC
Network Domain MCN - MCN MCN - -
Protocol LAPD - LAPD LAPD LAPD LAPD
L2 Frame Size 1304 - 1304 1304 1304 1304
FCS Mode - - - - - -
Add DCC/GCC:
Name OC192/STM64- - OC192/STM64- OC192/STM64- - OC192/
1-9-1 1-5-1 1-10-1 STM64-12
Carrier SDCC or LDCC - SDCC or LDCC SDCC or LDCC - SDCC
Note 2 Note 2 Note 2
Network Domain - - - - - -
Protocol PPP - PPP PPP - LAPD
L2 Frame Size - - - - - 1304
FCS Mode 16 bit - 16 bit 16 bit - -
Add DCC/GCC:
Name OC192/STM64- - - - - -
1-10-1
Carrier SDCC or LDCC - - - - -
Note 2
Network Domain - - - - - -
Protocol PPP - - - - -
L2 Frame Size - - - - - -
FCS Mode 16 bit - - - - -

Table 1-51

MSPP NE1 MSPP NE2
(GNE)
5 Set up internal (IISIS and OSPF) routing (Note 2)
For IISIS internal
routing, add IISIS
circuits for:
SHELF-shelf#:
Name SHELF-1 - SHELF-1 SHELF-1 NA NA
Circuit default metric 4 - 4 4 NA NA
Neighbor protocols Off - Off Off NA NA
supported override
DCC/GCC:
Name OC192/STM64- - OC192/STM64- OC192/STM64- NA NA
1-5-1 1-6-1 1-9-1
Carrier same as DCC - same as DCC same as DCC NA NA
carrier carrier carrier
Circuit default metric use default - use default use default NA NA
Neighbor protocols OSI - OSI OSI NA NA
supported override
DCC/GCC:
Name OC192/STM64- - OC192/STM64- OC192/TM64- NA NA
1-9-1 1-5-1 1-10-1
Carrier same as DCC - same as DCC same as DCC NA NA
carrier carrier carrier
Circuit default metric use default - use default use default NA NA
Neighbor protocols Off - Off Off NA NA
supported override
DCC/GCC:
Name OC192/STM64- - - - NA NA
1-10-1
Carrier same as DCC - - - NA NA
carrier
Circuit default metric use default - - - NA NA
Neighbor protocols Off - - - NA NA
supported override

Table 1-51

MSPP NE1 MSPP NE2
(GNE)
For internal OSPF
routing, add OSPF
circuits for:
SHELF-shelf#:
Name SHELF-1 SHELF-1 SHELF-1 - - -
Network area (Note 3) 0.0.0.0 0.0.0.0 0.0.0.0 - - -
Cost 0 0 0 - - -
Area Off Off Off - - -
Password Off Off Off - - -
authentication
OSC (auto-configured):
Name OSC-1-1-1 OSC-1-1-1 OSC-1-1-1 - - -
Network area (Note 3) 0.0.0.0 0.0.0.0 0.0.0.0 - - -
Cost 10 10 10 - - -
Area Off Off Off - - -
Password Off Off Off - - -
authentication - - - - - -
Circuit password
OSC (auto-configured):
Name - OSC-1-4-1 - - - -
Network area (Note 3) - 0.0.0.0 - - - -
Cost - 10 - - - -
Area - Off - - - -
Password - Off - - - -
authentication
6 Set up external routing
Add static IP route (GNE
only):
IP subnet 0.0.0.0 - - - - -
Subnet mask 0.0.0.0 - - - - -
Next hop 47.114.242.1 - - - - -
Cost 1 - - - - -
Circuit ID COLAN-1-X - - - - -

Table 1-51

MSPP NE1 MSPP NE2
(GNE)
7 Set up ARP proxy
Add address range for
ARP proxy:
First address 47.114.242.3 - - - - -
Last address 47.114.242.5 - - - - -
Note 1: OSC (for the Photonic and amplifier shelves) is automatically configured when the OSC circuit packs and SFPs are
inserted.
Note 2: Must match provisioning at far end. LDCC is preferred.
Note 3: OSC is automatically configured as OSPF circuit to OSPF area 0.0.0.0 when auto OSC is set to OSPF (default shelf
setting). The OSPF area can be edited on the OSPF circuits if a different OSPF area is required.

DCN example 20—management of OM 3500 through 6500 using GRE

tunnel
OM 3000 network elements through the 6500 network elements. In this
example, the OM 3500 network element with the network processor (NP) is
located remotely and does not have a COLAN connection to the external
DCN. Data communication between the OM 3500 network element and the
6500 is OSI and the IP over OSI GRE tunnel is used to carry the comms
between the DCN and the NP.
network element.
The default gateway of the OM 3500 NP must be in the same subnet as the
OM 3500 NP COLAN IP address. In this example, the OM 3500 COLAN IP
address and default gateway are in the same subnet as the 6500 network
element connected to it. The COLAN port and IP address of the NP must be
provisioned before the GRE tunnel.
In this example, OSPF routing is used to connect to the OSPF backbone area
(0.0.0.0). OSPF in different areas, static routes, static routes with proxy ARP,
and static routes with proxy ARP/NAT can also be used if required. Refer to
the relevant examples in this chapter for more information on these other
configurations. Proxy ARP can be used on 6500 NE1 instead of a static route
on R1 to advertise the OM 3500 to the DCN if OSPF is not used.

OM 3500 provisioning details

The COLAN of the OM 3500 NP must be provisioned with an IP address of
10.5.1.4, a netmask of 255.255.255.248, and a default gateway of 10.5.1.3.
The GRE tunnel must be provisioned with the destination address of the
NSAP of the 6500 network element (490000006038DF9B3E00 in the
example in Figure 1-57 on page 1-287).

Figure 1-57
DCN example 20 diagram—Managing OM 3500 through 6500 using a GRE tunnel
MOA
OneControl
10.6.1.2/29
10.6.1.1/29
Subnet: 10.6.1.0/29
10.6.1.3/29 R2
Carrier
Access
DCN
48.1.1.14/29 R1
NE1
COLAN
48.1.1.13/29
IP over OSI
GRE tunnel
10.5.1.1/32 4900000060
iISIS routing 38df9b3e00 OM3500
of IP and CLNP with NP
COLAN
NE2 over DCC 10.5.1.4/29
NE3
4900000000
10.5.1.3/32 75de3d9a00
10.5.1.2/32
iISIS routing
6500 of CLNP
over DCC
OM3500
/29 is 255.255.255.248
/30 is 255.255.255.252
/32 is 255.255.255.255

Table 1-52

1 Set up IP address and LANs
Add IP address on COLAN-shelf#-X port:
IP address 48.1.1.13 - -
Netmask 255.255.255.248 - -
ARP proxy Off - -
IP address 10.5.1.1 10.5.1.2 10.5.1.3
Netmask 255.255.255.255 255.255.255.255 255.255.255.255
2 Set up MAA (Note 1)
Edit MAAs
Manual Area Address 1 490000 490000 490000
Manual Area Address 2 - - -
Manual Area Address 3 - - -
Route redistribution OSPF distribution - Static distribution
IP subnet 10.6.1.1 - 10.5.1.4
Subnet mask 255.255.255.248 - 255.255.255.255
Metric 2 - 2
Metric type External - External
Border Router
Route redistribution ISIS distribution - -
IP subnet 10.5.1.1 - -
Subnet mask 255.255.255.248 - -
Metric 2 - -

Table 1-52

Add DCC on:
Protocol - - LAPD
L2 size (see Note 5) - - 1304
Protocol - - LAPD
L2 size (see Note 5) - - 1304
5 Add IP over OSI tunnel
Add tunnel:
Name - - GRE-OSI-1
Network area - - 490000000075
DE3D9A00 (Note 6)
SHELF-shelf#:
Name OC192/STM64- OC192/STM64- OC192/STM64-
shelf#-5-1 shelf#-5-1 shelf#-5-1
Name OC192/STM64- OC192/STM64- OC192/STM64-she
shelf#-6-1 shelf#-6-1 lf#-6-1

Table 1-52

Name - - OC12/STM4-shelf#
-1-1
Neighbor protocols supported override OSIONLY
Name - - OC12/STM4-shelf#
-2-1
7 Set up external (static) routing
IP subnet - - 10.5.1.4
Subnet mask - - 255.255.255.255
Next hop - - 0.0.0.0
Cost - - 2
Circuit Id - - GRE-OSI-1
Add OSPF circuit for COLAN-shelf#-X:
Name COLAN-shelf#-X - -
Network area 0.0.0.0 - -
Cost 0 - -
Area Off - -
Password authentication - - -
Note 1: 490000 is the default MAA. If a different MAA is required, all the 6500 and OM 3500 network elements must
be provisioned with the same MAA.
Note 3: The gateway 6500 network element requires an IISIS router with OSPF redistribution. The 6500
non-gateway 6500 network element connected to the OM 3500 with the NP requires an IISIS router with Static
redistribution. The other non-gateway 6500 network elements only requires a basic IISIS router without any
redistribution.
elements and section/RS DCC on port 1 of OC-12/STM-4 circuit pack is slots 1 and 2 is used to connect to OM 3500
network elements.
Note 5: The OM 3500 and 6500 network elements default to a L2 size of 1304. If you change the settings on the
6500 network elements you must also change the settings on the OM 3500 network elements.
Note 6: This is the full NSAP address which is unique for each OM 3500 NP.

DCN example 21—auto-tunneling

In these examples (see Figure 1-58 on page 1-292 and Figure 1-59 on
page 1-293) auto-tunneling is used to package the IP packets for the
subtended 6500 network elements into OSI packets to traverse the OSI only
network. Using the GRE auto-tunneling and the IISIS routing, the 6500
network elements can identify dual routers that can be used for the origination
and termination of dynamically tunneled data.
In Figure 1-58 on page 1-292, an IP over OSI auto-tunnel is created between

NE1 and NE2 over the DCC on the optical interfaces to the OSI network
element (for example, Optical Cross Connect HDX).
In Figure 1-59 on page 1-293, an IP over OSI auto-tunnel is created between

NE1 and NE2 over the LAN (using the ILAN port on the 6500) to the OSI
network element and then the DCC on the optical interface to NE2.

No special provisioning is required for the 6500 network element in these
configurations as the auto-tunnels are created without user intervention. The
following are some general provisioning information (refer to the other DCN
examples in this chapter for provisioning details on similar configurations):
• In Figure 1-58 on page 1-292, the DCC on the 6500 and the OSI network
element must be configured for LAPD (with same L2 frame size). The
neighbor protocols supported override parameter for the IISIS circuits on
the DCC of NE1 and NE2 must be set to OSIONLY.
• In Figure 1-59 on page 1-293, the ILAN must be configured on NE1 and
an IISIS circuit added for the ILAN (the neighbor protocol supported
override parameter for the ILAN must be set to OSIONLY or
LAN_OSIONLY (recommended)). In addition, the DCC on the 6500 and
the OSI network element must be configured for LAPD (with same L2
frame size).
• 490000 is the default MAA. If a different MAA is required, all 6500 and OSI
network elements should be provisioned with the same MAA.

Figure 1-58
DCN example 21 diagram—Auto-tunneling over DCC
EMS
47.1.1.1/24
DGW 47.1.1.254/24
47.1.1.254/24
R2 47.1.2.3/32
Router DCN Network

OSPF Backbone Area 0.0.0.0 NOTE:
IP addresses in DCN
backbone not shown
R1 47.1.2.1/32
47.1.2.18/28
IP and OSPF
OSPF
COLAN-X Area
47.1.2.17/28 0001
NE1 DCC
47.1.3.1/32
OSI
Network Element
6500
DCC DCC
/24 is 255.255.255.0 iISIS
/28 is 255.255.255.240
/32 is 255.255.255.255
IP over OSI NE2

Autotunnel 47.1.3.2/32

Figure 1-59
DCN example 21 diagram—Auto-tunneling over the LAN
EMS
47.1.1.1/24
DGW 47.1.1.254/24
47.1.1.254/24
R2 47.1.2.3/32
Router DCN Network

R1 47.1.2.1/32
47.1.2.18/28
IP and OSPF
OSPF
COLAN-X Area
47.1.2.17/28 0001
NE1 ILAN 47.1.2.19/28
47.1.3.1/32
OSI
Network
Element
6500
DCC DCC
/24 is 255.255.255.0 iISIS
/28 is 255.255.255.240
/32 is 255.255.255.255
IP over OSI
Autotunnel NE2
47.1.3.2/32

DCN example 22—6500/HDX interworking using HDX DCC transparency

and multiple OSI areas
This example (see Figure 1-60 on page 1-295) shows the 6500 interworking
with Optical Cross Connect HDX/HDXc using the DCC transparency feature
on the HDX/HDXc and multiple OSI areas. The DCC transparency feature on
the HDX is used to transparently connect 6500 network elements that are in
different OSI areas than the HDX.
The network consists of three OSI areas as follows:

• OSI Area 1 (39....0001): 6500 NE1, NE4, and NE5
• OSI Area 2 (39....0002): 6500 NE2, NE6, and NE7 and the HDX
• OSI Area 3 (39....0003): 6500 NE3, NE8, and NE9
For OSI Area 1, the DCC from/to the 6500 gateway network element is
transparently connected on the HDX (which is in OSI Area 2) to the
subtending 6500 rings. A separate OCn/STMn connection is available on the
6500 gateway network element to each subtending ring, therefore the DCC is
transparently connected directly through the HDX.
For OSI Area 2, the 6500 network elements are in the same OSI area as the
HDX therefore IP over OSI auto-tunnels are created over the LAN and the
DCC (see “DCN example 21—auto-tunneling” on page 1-291 for details).
For OSI Area 3, the DCC from/to the 6500 gateway network element is
transparently connected on the HDX (which is in OSI Area 2) to the
subtending 6500 rings. As there is not an separate OCn/STMn connection
from the 6500 gateway network element to each of the subtending rings, the
DCC is daisy-chained between the subtending rings on the HDX so that all the
6500 network elements have DCC connectivity to the 6500 gateway network
element.

No special provisioning is required for the 6500 network element in these
configurations (refer to the other DCN examples in this chapter for
provisioning details on similar configurations).

Figure 1-60
DCN example 22 diagram—6500/HDX interworking using HDX DCC transparency and multiple OSI
areas
EMS
47.1.1.1/24
DGW 47.1.1.254/24
R2 47.1.1.254/24
47.1.2.3/32
Router DCN Network

R1
47.1.2.18/28
OSI 1
OSI 2 OSI 3
OSPF IP
Area
0001 COLAN-X
COLAN-X COLAN-A
47.1.2.20/28 47.1.2.21/28
COLAN-X COLAN-A COLAN-A
47.1.2.17/28 47.1.4.2/32
39...0002
NE1 ILAN NE2 47.1.5.3/32
47.1.3.1/32 39...0003
39...0001 HDX
39...0002 NE3
OC-n/STM-n connection Single OC-n/STM-n
to HDX required for each connection to HDX
subtended ring required with DCC
daisy-chained between
rings on HDX
47.1.5.9/32
47.1.3.4/32 39...0003
39...0001
NE4 NE9
47.1.5.8/32
47.1.3.5/32 39...0003
NE5 39...0001 47.1.4.6/32 47.1.4.7/32 NE8
39...0002 39...0002
NE6 NE7
6500
/24 is 255.255.255.0
DCC over optical /28 is 255.255.255.240
/32 is 255.255.255.255
IP over OSI autotunnel
Transparent DCC connection

DCN example 23—using OSPF with two 6500 gateway network elements
connected to OSPF backbone with collocated CPL network elements
are connected to the OSPF backbone and act as the gateway network
element for the other 6500 network elements. The gateway network elements
look like OSPF routers in the DCN. OSPF is used on the COLAN interface of
gateway network elements for integration with the external DCN. The COLAN
ports must be in the same area and have the same configuration as the DCN
router. For more information on 6500 and CPL interworking, see “DCN design
examples” on page 1-153.
ILAN ports are used to connect to collocated CPL network elements. For more
In this example, the internal routing protocol is OSPF. When the internal
element.
The overall design must ensure that only packets meant for the 6500 network
network elements send/receive all routes to/from the DCN.
external DCN. The ILAN IN ports are assigned an IP address in the same
subnet as the ILAN port on the CPL to which it is connected.
PPP is used as the data link layer across the DCC/GCC for communication
between the 6500 network elements or between the 6500 network elements
and the CPL network elements.


Figure 1-61
DCN example 23 diagram—Using OSPF with two 6500 gateway network elements connected to
the OSPF backbone with collocated CPL network elements
RADIUS OneControl
47.1.1.2/29 47.1.1.1/29
Subnet: 47.1.1.0/29
47.1.1.3/29
Router DCN Network

47.114.249.101/30 47.114.249.105/30 COLAN-X

COLAN-X 47.114.249.106/30
47.114.249.102/30
NE1 NE2 ILAN-IN

47.114.249.113/32 47.114.249.114/32 47.114.239.242/30
ILAN-IN
47.114.239.225/30
ILAN1 ILAN1
47.114.239.229/30 47.114.239.238/30
ILAN2 ILAN1 ILAN1 ILAN2

47.114.239.226/30 47.114.239.230/30 47.114.239.237/30 47.114.239.241/30
NE3 NE4 NE5 NE6

47.114.249.115/32 47.114.249.116/32 47.114.249.119/32 47.114.249.120/32
ILAN2 ILAN1
47.114.239.233/30 47.114.239.234/30
NE7 NE8
47.114.249.117/32 47.114.249.118/32
6500
/29 is 255.255.255.248
/30 is 255.255.255.252 CPL
/32 is 255.255.255.255

Table 1-53
Parameters NE1 NE2

1 Set up IP address (Note 1)
Add COLAN-shelf#-X port Yes No
Add IP address on COLAN-
shelf#-X port:
IP address 47.114.249.102 47.114.249.106
Netmask 255.255.255.252 255.255.255.252
Non-routing mode Off Off
ARP proxy Off Off
Add IP address on shelf (SHELF-1):
IP address 47.114.249.113 47.114.249.114
Netmask 255.255.255.255 255.255.255.255
Add ILAN-shelf#-IN port Yes Yes
Add IP address on ILAN-shelf#-IN:
IP address 47.114.239.225 47.114.239.242
Netmask 255.255.255.252 255.255.255.252
2 Set up IP routing
Add OSPF router: Yes Yes
OSPF Router ID 47.114.249.113 47.114.249.114
Route summarization On On
Autonomous System Border Router Off Off
Add DCC/GCC:
Name OCn/STMn/OTMn-shelf#-slot#-port# OCn/STMn/OTMn-shelf#-slot#-port#
Carrier Line/MS, Section/RS, GCC0/GCC1 Line/MS, Section/RS, GCC0/GCC1
Protocol PPP PPP

Table 1-53
Parameters NE1 NE2

Add OSPF circuits for:
SHELF-shelf#:
Name SHELF-shelf# SHELF-shelf#
Network area 0.0.0.0 0.0.0.0
Cost 0 0
Area Off Off
Password authentication Off Off
Name OCn/STMn/OTMn-shelf#-slot#-port# OCn/STMn/OTMn-shelf#-slot#-port#
Carrier Line/MS, Section/RS, GCC0/GCC1 Line/MS, Section/RS, GCC0/GCC1
Cost 174 (Line/MS), 174 (Line/MS),
520 (Section/RS), 520 (Section/RS),
303 (OTU1/ODU1 GCC) 303 (OTU1/ODU1 GCC)
Area Off Off
ILAN-shelf#-IN:
Name ILAN-shelf#-IN ILAN-shelf#-IN
Network area 0.0.0.0 0.0.0.0
Cost 10 10
Area Off Off
Add OSPF circuit for COLAN-
shelf#-X:
Name COLAN-shelf#-X COLAN-shelf#-X
Network area 0.0.0.0 0.0.0.0
Cost 0 0
Priority (Note 5) 1 1
Area Off Off

Table 1-53
Parameters NE1 NE2

Note 1: CPL R3.0 supports the ability to run OSPF over un-numbered ILAN ports between CPL nodes (that is, ILAN
ports could have IP address 0.0.0.0)
Note 4: An OSPF circuit is required for each DCC/GCC provisioned.
router (DR).

DCN example 24—Voice over IP (VoIP) orderwire

In this example (see Figure 1-62 on page 1-303), IP telephony is used to
provide orderwire communication between 6500 network elements. The
configuration uses IP telephones connected to the ILAN ports on the 6500
network elements and external IP telephony equipment.
The example in Figure 1-62 on page 1-303 only details the IP telephony
requirements and does not detail the management requirements which must
be set up as required using the other examples in this chapter as a basis.
The ILAN-IN interfaces on the remote 6500 network elements are connected
to the IP telephone and are assigned Private-IP addresses in the same subnet
as the IP telephone. Static routes are provisioned on the remote 6500 network
elements to the IP telephones, the static routes are redistributed in the IISIS
router.
At the gateway 6500 network element, the COLAN-X interface is connected

to the IP router and a static route is provisioned to the VoIP server, the static
route is redistributed in the IISIS router. As the gateway 6500 network element
is collocated with the IP server, the IP telephone at this site can be connected
to a port on the IP server.
At the VoIP server, static routes are provisioned to each of the 6500 network
elements.
Signaling traffic is routed between each IP telephone and the VoIP server
whilst the voice traffic is routed between the IP telephones used in the call.
VoIP traffic must be configured to reduce bandwidth requirements (for

example, use G.723 or G.729 compression and use silence suppression) and
to reduce the number of packets required per call (for example, configure
50 ms or greater speech per packet).
ATTENTION
It is recommended that only one telephone call be made on the network at
the same time.

It is assumed that the IP interfaces and IP routing required for the DCN
connectivity is already provisioned and verified. The following information
provides additional provisioning information for extending the IP network for
the IP telephony. Once provisioned, you must verify the VoIP telephony
connectivity.

page 1-97.
ATTENTION
The following example configuration is for information only. Contact your
Ciena account prime if information is required on engineering a real-life VoIP
solution.
The VoIP server is configured as follows:

• IP address: 10.10.12.0/32
• Ethernet port: 10.10.11.1/24
• static routes to the IP telephone subnets:
— 10.0.1.0/24, next hop 10.10.11.5
— 10.0.2.0/24, next hop 10.10.11.5
— 10.0.3.0/24, next hop 10.10.11.5
The IP telephony settings on the VoIP server must be provisioned accordingly.
The IP router is configured as follows:

• IP addresses (SHELF IP addresses not detailed):
— Ethernet interface connected to VoIP server: 10.10.1.5/24
— Ethernet interface connected to gateway network element: 10.0.3.2/24
— Ethernet interface connected to IP telephone: 10.0.3.3/24
• static routes to the VoIP server:
— 10.10.12.0/32, next hop 10.10.11.1
• RIP (for example):
— 10.0.2.0/24
— 10.10.11.0/24

Figure 1-62
DCN example 24 diagram—VoIP orderwire
VoIP server
10.10.12.0 (VoIP server)
Static routes:
10.0.1.0/24 next hop 10.10.11.5
IP telephone A 10.0.2.0/24 next hop 10.10.11.5
Ext: 19148
10.10.11.1 10.0.3.0/24 next hop 10.10.11.5
IP: 10.0.3.4
Gateway: 10.0.3.2
10.10.11.5/24
IP: 10.0.3.3 Static route:
IP router
10.10.12.0/32
IP telephone B IP: 10.0.3.2 next hop 10.10.11.1
Ext: 19146 RIP:
IP: 10.0.1.3 10.0.3.0/24
Gateway: 10.0.1.1 10.10.11.0/24
ILAN
10.0.1.1/24 COLAN-X
10.0.3.1/24
NE2 NE1
NE3
ILAN
10.0.2.1/24
IP telephone C /24 is 255.255.255.0
Ext: 19147 /32 is 255.255.255.255
IP: 10.0.2.3
Gateway: 10.0.2.1

Table 1-54

1 Set up IP address
Add IP address on
IP address 10.0.3.1 - -
Netmask 255.255.255.0 - -
Add ILAN-IN port No Yes Yes
Add IP address on ILAN-IN port:
IP address - 10.0.1.1 10.0.2.1
Netmask - 255.255.255.0 255.255.255.0
Non-routing mode - Off Off
2 Set up IP routing (Note)
IP subnet 10.10.12.0 10.0.1.3 10.0.2.3
Subnet mask 255.255.255.255 255.255.255.255 255.255.255.255
Next hop 10.0.3.2 10.0.1.1 10.0.2.1
Cost 2 2 2
Circuit Id COLAN-shelf#-X ILAN-shelf#-IN ILAN-shelf#-IN
Add route redistribution to IISIS
router:
Route redistribution Static distribution Static distribution Static distribution
IP subnet 10.10.12.0 10.0.1.3 10.0.2.3
Subnet mask 255.255.255.255 255.255.255.255 255.255.255.255
Metric 10 10 10
Metric type External External External
Note: Assumes IISIS router is already provisioned.

DCN example 25—DBRS use in a mesh network

This example outlines the DBRS and IP routing provisioning required for a site
within a mesh network.
ATTENTION
The following example purposefully avoids using the term OSPF AS
(autonomous system) in the context of DBRS. The generic term “OSPF
network” is henceforth used in the DBRS context to describe a contiguous
OSPF network, consisting of network elements and routers, in which opaque
LSAs are flooded using OSPF. An OSPF network:
• may or may not correspond to an OSPF autonomous system.
• can describe a single OSPF area or a hierarchical OSPF network,
including a backbone area (0.0.0.0).
• may or may not include customer DCN equipment depending on whether
opaque LSAs are enabled on the interfaces connected to the customer
DCN.
In Figure 1-63 on page 1-305, the network consists of a number of optical

sites. Each cloud represents a number of NEs that are provisioned to be in the
same OSPF network.
Figure 1-63
DCN example 25 diagram—Mesh network
Site C Site D Site E
network-2 network-4
network-1 network-3
Site B Site A Site F
See detail for Site A

In this example, the DCN designer has determined that using a single
multi-area OSPF network to provide a solution is not appropriate for this
network/customer. Therefore this design uses DBRS at each site that has
more than one OSPF network so that AR and TR data can be shared between
the networks. A maximum of three OSPF networks can be provisioned at a
DBRS-enabled site. In this case, Site A has three OSPF networks.
The provisioning data for Site A within the example network is given below.
Figure 1-64
DCN example 25 diagram—Site A details
OSPF
Network 1
Shelf 1
DB
RS RS
DB
OSPF iISIS OSPF
Network 3 Shelf 3 Shelf 2 Network 2
DBRS
Site A consists of three 6500 shelves in a TID consolidated (TIDc)

configuration. All three shelves contain Photonics and transponders.
Each shelf has two unnumbered ILAN connections running IISIS and with
DBRS enabled.
The connections are:

• Shelf 1 ILAN IN - Shelf 2 ILAN OUT
In this example, the external DCN connectivity is not shown; and therefore
assumes that the external DCN connectivity solution does not support the
shelf-to-shelf communications required at branching sites. Therefore, IISIS on
the ILAN ports provides IP routing redundancy between the shelves in the
TIDc. The SHELF IP address on each shelf is redistributed into IISIS so that
it is visible at the other shelves. This provides connectivity at the TIDc.

However, since there is only a single DBRS link between any two OSPF
networks and since DBRS only exchanges AR and TR data with adjacent
networks, there is no DBRS redundancy.
Table 1-55
DCN example 25—DBRS provisioning details
Parameters Shelf 1 Shelf 2 Shelf 3
SHELF IP
Address 10.6.1.1 10.6.2.1 10.6.3.1
Subnet mask 255.255.255.255 255.255.255.255 255.255.255.255
ILAN IN IP
Address 0.0.0.0 0.0.0.0 0.0.0.0
Subnet mask 255.255.255.255 255.255.255.255 255.255.255.255
ILAN OUT IP
Address 0.0.0.0 0.0.0.0 0.0.0.0
Subnet mask 255.255.255.255 255.255.255.255 255.255.255.255
OSPF Router
Router ID 10.6.1.1 10.6.2.1 10.6.3.1
Router redistribution none none none
OSPF Circuits
SHELF-1: Network Area 0.0.0.1 NA NA
OSC-1-x-1: Network Area 0.0.0.1 NA NA
SHELF-2: Network Area NA 0.0.0.2 NA
OSC-2-x-1: Network Area NA 0.0.0.2 NA
OSC-2-x-2: Network Area NA 0.0.0.2 NA
SHELF-3: Network Area NA NA 0.0.0.3
OSC-3-x-1: Network Area NA NA 0.0.0.3
OSC-3-x-2: Network Area NA NA 0.0.0.3
IISIS Router:
Router summarization On On On
Router redistribution OSPF distribution OSPF distribution OSPF distribution
IP subnet 10.6.1.1 10.6.2.1 10.6.3.1
Subnet mask 255.255.255.255 255.255.255.255 255.255.255.255
IISIS Circuits:
ILAN-x-IN Default values Default values Default values
ILAN-x-OUT Default values Default values Default values
Database Replication:
ILAN-x-IN
Address resolution Enabled Enabled Enabled
Topology resolution Enabled Enabled Enabled
ILAN-x-OUT
Address resolution Enabled Enabled Enabled
Topology resolution Enabled Enabled Enabled

DCN example 26—IPv6 DCN LAN drop to every shelf

The example in Figure 1-65 on page 1-309 shows three sites with all shelves
connected to the external DCN. Site 2 has a 2-node consolidated TID. In this
configuration, each shelf can be assigned a single IPv6 address that is used
for the COLAN and the shelf interface. The prefix of the COLAN is set to match
that of the external DCN (generally a /64), while the shelf interface is a /128.
Since this example includes a consolidated TID and since it is assumed that
DOC (domain optical control) is running across the optical line, IPv4
provisioning is also required for internal communications. However, IPv4 is not
required on the COLAN interfaces as IPv6 is used for north-south
management communications.
Only the IPv6 provisioning is shown in the diagram for simplicity, but the
provisioning matrix shows example IPv4 provisioning.
For illustrative purposes, the OSPFv2 and OSPFv3 area IDs are shown with
different values in the provisioning matrix. They could also be configured with
the same values, as OSPFv2 and OSPFv3 have no interaction. The OSPFv2
and v3 router IDs are set to the same value as a recommended best practice
to allow for easier planning and tracking of a given shelf.
page 1-97.

Figure 1-65
DCN example 26 diagram—DCN LAN drop to every shelf
Table 1-56
Parameters Site 1, Shelf-1 Site 2, Shelf-1 Site 2, Shelf-2 Site 3, Shelf-1

IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6
1 GNE provisioning
Configuration None None None None None None None None
Access
2 Set up IP address
COLAN 2001:db8: 2001:db8: 2001:db8: 2001:db8:
1234:aaaa 1234:bbbb 1234:bbbb 1234:cccc
::2/64 ::2/64 ::3/64 ::2/64
Shelf 47.99.1.2/ 2001:db8: 47.100.1.8 2001:db8: 47.100.1.9 2001:db8: 47.101.1.77 2001:db8:
32 1234:aaaa /32 1234:bbbb /32 1234:bbbb /32 1234:cccc
::2/128 ::2/128 ::3/128 ::2/128
OSC ::/128 ::/128 ::/128 ::/128
ILAN-IN 0.0.0.0/32 ::/128
ILAN-OUT 0.0.0.0/32 ::/128

Table 1-56

3 OSPF router provisioning
OSPF router 47.99.1.2 47.99.1.2 47.100.1.8 47.100.1.8 47.100.1.9 47.100.1.9 47.101.1.77 47.101.1.77
ID
Route ON NA ON NA ON NA ON NA
Summarization
Autonomous OFF NA OFF NA OFF NA OFF NA
System Border
Router
Opaque Filter OFF NA OFF NA OFF NA OFF NA
Shelf OFF NA OFF NA OFF NA OFF NA
Re-distribution
Route See Static See Static See Static See Static
Redistribution route route route route
(IPv4) provisioning provisionin provisionin provisioning
g g
IP Subnet
Subnet Mask
Metric
Metric Type
4 OSPF circuit provisioning
Shelf interface
Area 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4
Cost 0 0 0 0 0 0 0 0
OSC
interface(s)
Area 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4
Cost 10 10 10 10 10 10 10 10
Opaque ON ON ON ON
ON/OFF
ILAN-IN
Area 0.0.0.1 1.2.3.4
Cost 10 10
Opaque ON
ON/OFF
ILAN-OUT
Area 0.0.0.1 1.2.3.4
Cost 10 10
Opaque ON
ON/OFF

Table 1-56

5 Static route provisioning
IP destination ::/0 ::/0 ::/0 ::/0
Mask (IPv4)
Next hop 2001:db8: 2001:db8: 2001:db8: 2001:db8:
1234:aaaa 1234:bbbb 1234:bbbb 1234:cccc
::1 ::1 ::1 ::1
Cost 1000 1000 1000 1000
Circuit ID COLAN-X COLAN-X COLAN-X COLAN-X
Redistribution See Route OFF See Route OFF See Route OFF See Route OFF
Redistribut Redistributi Redistributi Redistributio
ion (IPv4) on (IPv4) on (IPv4) n (IPv4)
Redistribution NA NA NA NA
Type

DCN example 27—IPv6 statically routed GNE configuration

The example in Figure 1-66 on page 1-313 shows three sites but with a single
shelf at Site 1 connected to the external DCN acting as the gateway network
element. Site 2 has a 2-node consolidated TID. The COLAN port of the GNE
is assigned an IPv6 address from the same /64 subnet as the external DCN
router R1. In line with recommended best practices, the /128 shelf IP
addresses are assigned from a separate common /64 subnet.
One or more static routes are added to the router in the external DCN to reach
remote network elements through the GNE. If shelf IP addresses are
assigned from a common prefix (for example, /64), only a single static route
pointing to that prefix is necessary.
Likewise, one or more static routes are added on the GNE pointing to external
management destinations and are redistributed into the internal routing
domain.
This configuration avoids the use of routing protocols between the 6500
network elements and the external DCN, but requires configuration changes
in the external DCN router and does not provide redundant access to the 6500
network in case of DCN or COLAN failure.
page 1-97.

Figure 1-66
DCN example 27 diagram—Statically routed GNE configuration
Table 1-57

1 GNE provisioning
Configuration Standalone
Access Static
2 Set up IP address
COLAN 2001:db8:
1234:aaaa
::2/64
Shelf 47.99.1.2 2001:db8: 47.100.1.8 2001:db8: 47.100.1.9 2001:db8: 47.101.1.77 2001:db8:
/32 1234:bbbb /32 1234:bbbb /32 1234:bbbb /32 1234:bbbb
::1/128 ::2/128 ::3/128 ::4/128
OSC ::/128 ::/128 ::/128 ::/128
ILAN-IN 0.0.0.0/32 ::/128
ILAN-OUT 0.0.0.0/32 ::/128

Table 1-57

OSPF router 47.99.1.2 47.99.1.2 47.100.1.8 47.100.1.8 47.100.1.9 47.100.1.9 47.101.1.77 47.101.1.77
ID
Summarization
(IPv4)
System Border
Router
Re-distribution
(IPv4) provisioning provisioning provisioning provisioning
IP Subnet
Subnet Mask
Metric
Metric Type
Shelf interface
Area 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4
Cost 0 0 0 0 0 0 0 0
OSC
interface(s)
Area 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4
Cost 10 10 10 10 10 10 10 10
Opaque ON ON ON ON
ON/OFF
ILAN-IN
Area 0.0.0.1 1.2.3.4
Cost 10 10
Opaque ON
ON/OFF
ILAN-OUT
Area 0.0.0.1 1.2.3.4
Cost 10 10
Opaque ON
ON/OFF

Table 1-57

IP destination ::/0
Mask (IPv4)
Next hop 2001:db8:
1234:aaaa
::1
Cost 1000
Circuit ID COLAN-X
Redistribution See OSPFv3 See Route OFF See Route OFF See Route OFF
(IPv6) Route Redistribu Redistribu Redistributi
Redistrib tion (IPv4) tion (IPv4) on (IPv4)
ution
(IPv4)
Redistribution Internal
Type (IPv6)

DCN example 28—IPv6 ND Proxy GNE configuration

The example in Figure 1-67 on page 1-317 shows an IPv6 ND Proxy
configuration with a single GNE at Site 1. The shelf IPv6 addresses of the
RNEs are allocated from the same subnet as the GNE COLAN-X, in this case
the 2001:db8:1234:aaaa::/64 subnet. The GNE responds to Neighbor
Solicitation requests on behalf of the RNEs, similar to the way the GNE would
respond to ARP requests in the IPv4 Proxy ARP configuration. The GNE shelf
IP address is set to the same value as its COLAN-X address in order to
simplify provisioning.
Two IPv6 static routes are defined on the GNE shelf, one for each of the
management subnets, and redistributed into OSPF. Note that for IPv6, the
redistribution is specified as part of the IPv6 static route provisioning, unlike
IPv4 where it is done via a separate provisioning step.
page 1-97.

Figure 1-67
DCN example 28 diagram—IPv6 ND Proxy GNE configuration
Table 1-58
1 GNE provisioning
Configuration Standalone
Access ND Proxy
2 Set up IP address
COLAN 2001:db8:
1234:aaaa
::2/64
Shelf 192.168.93. 2001:db8: 192.168.95. 2001:db8: 192.168.62. 2001:db8: 192.168.63. 2001:db8:
1/32 1234:aaaa 12/32 1234:aaaa 16/32 1234:aaaa 10/32 1234:aaaa
::2/128 ::abc2/128 ::abc3/128 ::abc4/128
OSC ::/128 ::/128 ::/128 ::/128
ILAN-IN 0.0.0.0/32 ::/128
ILAN-OUT 0.0.0.0/32 ::/128

Table 1-58
OSPF router 192.168.93.1 192.168.93.1 192.168.95. 192.168.95 192.168.62. 192.168.62 192.168.63. 192.168.
ID 12 .12 16 .16 10 63.10
Summarization
System Border
Router
Re-distribution

IP Subnet
Subnet Mask
Metric
Metric Type

IP Subnet
Subnet Mask
Metric
Metric Type

Shelf
interface
Area 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4
Cost 0 0 0 0 0 0 0 0
OSC
interface(s)
Area 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4
Cost 10 10 10 10 10 10 10 10
Opaque ON ON ON ON
ON/OFF
ILAN-IN
Area 0.0.0.1 1.2.3.4
Cost 10 10
Opaque ON
ON/OFF

Table 1-58
ILAN-OUT
Area 0.0.0.1 1.2.3.4
Cost 10 10
Opaque ON
ON/OFF
IP destination 2620:db8:
1234:1111
::/64
Mask (IPv4)
Next hop 2001:db8:
1234:aaaa
::1
Cost 100
Circuit ID COLAN-X
Redistribution See Route OSPFv3 See Route OFF See Route OFF See Route OFF
(IPv6) Redistribution Redistribution Redistribution Redistribution
(IPv4) (IPv4) (IPv4) (IPv4)
Type (IPv6)
IP destination 2620:db8:
1234:2222
::/64
Mask (IPv4)
Next hop 2001:db8:
1234:aaaa
::1
Cost 100
Circuit ID COLAN-X
Redistribution See Route OSPFv3 See Route OFF See Route OFF See Route
(IPv6) Redistribution Redistribution Redistribution Redistribution
(IPv4) (IPv4) (IPv4) (IPv4)
Type (IPv6)
6 ND proxy entries
Entry 1 2001:db8:
1234:aaaa
::abc2
Entry 2 2001:db8:
1234:aaaa
::abc3
Entry 3 2001:db8:
1234:aaaa
::abc4

DCN example 29—IPv6 redundant OSPF GNEs with IPv4 redundant OSPF
GNEs
The example in Figure 1-68 on page 1-321 shows a configuration where two
shelves are acting as GNEs, each running both OSPFv2 and OSPFv3 on the
COLAN-X to form adjacencies with the external DCN routers. In both cases,
it is assumed that an OSPF backbone area (0.0.0.0) exists in the external
DCN, and that DCN routers R1 and R2 act as Area Border Routers (ABRs).
Route summarization and filtering can be configured on those routers in
multi-area networks to reduce the amount of routing information advertised
into the 6500 network for scalability purposes.
Within the 6500 network, this example shows the OSPFv2 and OSPFv3 area
IDs with different values (0.0.0.1 and 1.2.3.4, respectively) in the provisioning
matrix, although they could also be set to the same value since the two
protocols are independent. The router IDs are set to the same value to simplify
planning and tracking.
The OSPFv2 circuits are all configured with opaque LSAs enabled, except on
the shelf IP interface where the value is not relevant. Having opaque LSAs
enabled on the COLAN ports allows the backbone to provide a resilient path
for opaque LSAs as well as for IP routing.
In terms of addressing, the COLAN ports of the GNE are assigned IPv6
addresses from the same /64 subnet as the external DCN routers (R1 and
R2). In line with recommended best practices, the /128 shelf IP addresses are
assigned from a separate common /64 subnet. Likewise, the IPv4 addresses
for the COLAN ports are from the respective IPv4 COLAN subnets, and the
shelf IP addresses are assigned from a common IPv4 subnet.
It is assumed that reachability to the management subnets is advertised into

the 6500 network, so no static route provisioning is necessary on the 6500
GNEs.
Note that only the IPv6 provisioning is shown in the diagram for simplicity, but
the provisioning matrix shows example IPv4 provisioning.
page 1-97.

Figure 1-68
DCN example 29 diagram—IPv6 redundant OSPF GNEs with IPv4 redundant OSPF GNEs
Table 1-59

1 GNE provisioning
Configuration Redundant Redundant Redundant Redundant
Access OSPF OSPFv3 OSPF OSPFv3
2 Set up IP address
COLAN 47.99.1.2/ 2001:db8 47.101.1.77 2001:db8
24 :1234:aaaa /26 :1234:cccc
::2/64 ::2/64
Shelf 47.10.11.2 2001:db8 47.10.11.3 2001:db8 47.10.11.4 2001:db8 47.10.11.5/ 2001:db8
/32 :1234:bbbb /32 :1234:bbbb /32 :1234:bbbb 32 :1234:bbbb
::1/128 ::2/128 ::3/128 ::4/128
OSC ::/128 ::/128 ::/128 ::/128
ILAN-IN 0.0.0.0/32 ::/128
ILAN-OUT 0.0.0.0/32 ::/128

Table 1-59

OSPF router 47.10.11.2 47.10.11.2 47.10.11.3 47.10.11.3 47.10.11.4 47.10.11.4 47.10.11.5 47.10.11.5
ID
Summarization
System Border
Router
Shelf-IP OFF NA OFF NA OFF NA OFF NA
Re-distribution
COLAN-X
interface
Area 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4
Cost 1000 1000 1000 1000
Opaque ON ON
ON/OFF
Shelf interface
Area 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4
Cost 0 0 0 0 0 0 0 0
OSC
interface(s)
Area 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4 0.0.0.1 1.2.3.4
Cost 10 10 10 10 10 10 10 10
Opaque ON ON ON ON
ON/OFF
ILAN-IN
Area 0.0.0.1 1.2.3.4
Cost 10 10
Opaque ON
ON/OFF
ILAN-OUT
Area 0.0.0.1 1.2.3.4
Cost 10 10
Opaque ON
ON/OFF

6500 DCC interworking with IP-managed or OSI-managed network

elements
The 6500 uses an IP-based data communications infrastructure for network
element management and interworking with IP-managed network elements.
6500 also supports Open Systems Interconnection (OSI) based
infrastructures for interoperability with OSI-managed network elements.
The SONET/SDH/SDH-J optical interfaces support both section/RS and

line/MS DCC. Each DCC interface supports PPP, LAPD, and Transparent with
PPP being the default.
Line/MS DCC provides a faster link than section/RS DCC. If an optical facility
is taken out-of-service, line/MS DCC is lost but section/RS DCC remains up.
Make sure that the settings at each end of the DCC channels are the same.
6500 DCC interworking with IP-managed network elements

Because 6500 uses an IP-based DCC infrastructure, the 6500 network
element interworks with IP-managed network elements by acting as an IP
router for the whole network. PPP is used as the data link layer across the
section/RS and line/MS DCCs. Figure 1-69 on page 1-324 shows the 6500
interworking with IP-managed network elements.

Figure 1-69
6500 DCC interworking with IP-managed network elements
NEs across
Managing
6500 NE
IP-managed NEs
Carrier
Access
DCN
6500 IP-Managed NE
DCC
COLAN DCC
6500 routing IP-DCC

messages between
IP-Managed NE subtending IP-managed NEs
Provisioning 6500 to interwork with IP-managed DCC network elements

6500 supports both section/RS and line/MS DCC datalink layer settings which
enable interworking.
6500 DCC interworking with OSI-managed network elements

The 6500 provides a 4-layer OSI stack (ISO 802.3 encapsulation) for
interoperability with OSI-managed network elements. The following scenarios
are typical examples of 6500 interworking with OSI-managed network
elements:
• 6500 routing OSI messages between subtending OSI-based network
elements
• Managing OSI-managed network elements across 6500 network
elements

Figure 1-70 on page 1-325 shows the 6500 interworking with OSI-managed
network elements. The configuration in Figure 1-70 on page 1-325 assumes
that the gateway network element is not acting as a TL1 Gateway. The
gateway network element will pass through OSI management traffic but
cannot be used to access the OSI based network elements.
Figure 1-70
6500 DCC interworking with OSI-managed network elements
NEs across
Managing
6500 NE
OSI-managed NEs
Carrier
Access
DCN
6500 OSI-Managed NE
DCC
COLAN DCC
6500 routing OSI-DCC

messages between
OSI-Managed NE subtending OSI-managed NEs
Provisioning 6500 to interwork with OSI-based DCC network elements

6500 provides the capability to manually configure the section/RS and line/MS
DCC datalink layer settings, which enable interworking. 6500 also provides
the capability to manually configure the data link layer parameters for LAPD
and other appropriate parameters to ensure they line up with the subtending
equipment OSI parameters.
OSI System Ids are derived automatically from the 6500 shelf MAC address.
The 6500 supports three configurable manual area addresses (MAAs). A
default MAA of 49000 is assigned to a network element.

DCC protection
6500 supports the following protection schemes for the DCC interfaces:
• protected DCC (route diversity Off) where DCC comms follows traffic
• unprotected DCC (route diversity On) where DCC comms does not follow
traffic
For BLSR/MS-SPRing/HERS and UPSR/SNCP configurations, route diversity

is always on. Route diversity is not applicable to unprotected configurations.
Protected DCC (route diversity off) is not supported on PPP DCC channels
(only supported for LAPD DCC channels). You cannot set route diversity to off
if either of the DCCs in the 1+1/MSP linear protection scheme is set to PPP.
Protected DCC
Protected DCC (route diversity off) is only supported on 1+1/MSP linear
protection schemes. If the 1+1/MSP linear protection is unidirectional, the
DCC follows traffic regardless of the facility traffic is on, thus DCC traffic can
be on different facilities for the transmit and receive direction.
For protected DCC (route diversity off), you must provision two DCC channels,
one for each port of the 1+1/MSP protection pair. DCC is sent on both working
and protection ports but only the receive DCC of the active port is selected.
With route diversity off, only the DCC associated with the active port is
alarmed.
Unprotected DCC
For unprotected DCC (route diversity on), you can provision one or two links
for the 1+1/MSP protection pair. If you provision DCC on both working and
protection ports, DCC is transmitted and received on both ports. With route
diversity on, the DCC associated with the each port is alarmed separately.

FTP/FTAM Bridge (file transfer translation device)

The FTP-FTAM FTTD Feature allows the 6500 to provide a file transfer bridge
between the Customer DCN and the optical network.
The FTP/FTAM Bridge allows users to perform file transfer (software

download and backup/restore) from the IP-based DCN to OSI-based
subtending NEs that communicate over DCC using only OSI protocols. This
allows 6500 to become a GNE for other vendor’s equipment that are OSI-only
managed. In a mixed-vendor network, file transfer over OSI is done using the
FTAM protocol, over a 7-layer OSI stack.
The bridging of FTP to FTAM is done using a one step process. In this
process, FTAM Responder on the 6500 NE translates the request for an FTP
file to an FTP request over the DCN to the OSS, with the retrieved file being
passed back to the FTAM Initiator on the RNE that made the request. See
Figure 1-71 on page 1-328.
This feature is designed only for managing third-party RNEs. The 6500 cannot
not act as an FTAM RNE, as its load delivery and Backup and Restore file
transfers are done only over FTP. There are no 6500 TL-1 commands that
initiate FTAM file transfers.
The TL1 Gateway allows customers to manage the OSI-based RNEs from
their OSS through TL-1. The FTP/FTAM Bridge requires the file transfer to be
initiated from the RNE, so the FTP/FTAM Bridge is dependent on the TL1
Gateway feature.
Note that FTTD and the TL1 Gateway can run on different NEs.
TL-1 commands example

The FTP/FTAM Bridge on the 6500 will be invoked from an RNE using the
COPY-RFILE
TL-1 command described in NSIF-033-1999.

The FTP/FTAM Bridge on the 6500 can also be invoked by RNEs that do not
support COPY-RFILE, but have their own proprietary command for file
transfers. The following is an example for this case:
• without an FTP/FTAM Bridge, i.e. simple FTAM write to a GNE, the
command looks as follows:
SAV-PROV:::X::ADMIN,ADMIN:DESTTYPE=TID,DESTADDR=GNET
ID,DIR="/loadmgmt/backups",CHKALM=N;
• with an FTP/FTAM Bridge, write to a Remote destination over the DCN via
GNETID
SAV-PROV:::X::ADMIN,ADMIN:DESTTYPE=TID,DESTADDR=GNET
ID,DIR="ftp://user:PWD@47.128.16.168/home/loadmgmt/backups",
CHKALM=N;
Figure 1-71
6500 FTP-FTAM FTTD
OSS TL1 initiator
FTP Client
DCN
Buffer
FTP
FTAM Responder
GNE
6500
FT-TD TL1-TD
FTAM
FTAM Initiator TL1 Responder
OSI RNE
The FTP/FTAM Bridge is compliant with NSIF-033-1999.

A maximum of 8 simultaneous FTAM sessions are supported.
The FTAM Responder authenticates its users from the generic 6500 User
Database (same as ACT-USER or the FTP server).
A user needs a minimum UPC of 3 to be authenticated by FTAM.
No provisioning is required on the 6500 for the FTAM Responder. It is always

enabled.
For an RNE to access the 6500 FTAM Responder, from anywhere in the OSI
Network, it is necessary for that RNE to be present in the 6500’s OSI Routing
table (RTVR-RTG-TBL).
The FTAM Responder does not allow direct FTAM write to the 6500 (only write
over an FTP Bridge). Direct FTAM read from the 6500 is allowed, only from
the “/loadmgmt” directory (or subdirectories).
A member shelf in a TID-consolidated note cannot act as a File Transfer

Translation Device (FTTD). The FTAM Responder on a TIDc member shelf will
not accept FTAM connections
Limitations
• The FTP-FTAM Bridge feature does not interwork with Ciena OM 3000 SP.
The OM 3000 SP supports a proprietary file transfer mechanism called
ALFTAM. ALFTAM uses a 4 layer OSI stack. The FTP-FTAM Bridge
feature on 6500 supports a full 7 layer OSI stack.
• The FTP-FTAM Bridge feature does not interwork with Ciena OM 3000 NP.
The OM 3000 NP supports non standard FTAM addressing (used when
NP does backup and restore of files to an OPC). The 6500 FTP-FTAM
Bridge feature complies to the GR-253-CORE FTAM addressing (Note:
file transfers between 6500 SP and an OM 3000 NP can be achieved via
an IP GRE tunnel).
• The FTP-FTAM Bridge feature supports only FTAM-3 (binary) file types.
FTAM-1 (text) file types are not supported.
• For the FTP/FTAM Bridge feature, the RNE must provide, in the FTP URL,
an IP address for the hostname. A domain name does not work, as the
6500 does not have the DNS services to resolve it to an IP address. The
FTP/FTAM Bridge feature does not comply with NSIF-033-1999 R7-99,
which requires the FT-TD to access a DNS server and determine the IP
address of a host.

OSI data communications on the 6500

The Data Communications Network Planning Guide, NTR710AM, provides
information on DCN planning for some OSI-based Ciena products. This guide
includes general information on OSI data communications and addressing
and can be used as a reference for OSI data communications information.
OSI data communications is not supported on T-Series shelves.
6500 DCC transparency

DCC Transparency is the bidirectional hairpinning of the Section/RS and/or
Line/MS DCC across two optical ports.
ATTENTION
GCC Transparency is not supported.
When you provision a bidirectional DCC Transparency connection across an

optical port pair, the DCC data is forwarded to the mate optical port where it
is transmitted out (HDLC encapsulated). In this case, the DCC traffic becomes
transparent to the 6500. In addition, the 6500 becomes transparent to the
network elements communicating over those ports.
In the SONET/SDH DCC, 6500 uses the HDLC (High-Level Data Link Control)
protocol to encapsulate Layer 2 protocol data. HDLC frames contain a Frame
Check Sequence (FCS) that can be 16-bit or 32-bit in length computed over
the Address, Control, and Information fields. It provides a means by which the
receiver can detect errors that may have been induced during the
transmission of the frame, such as lost bits, flipped bits, and extraneous bits.
The 6500 HDLC FCS can be either 16-bit or 32-bit when setting up a DCC
Transparent connection.
The following rules are applied to DCC transparency support in 6500:

• You can not provision an IISIS/OSPF circuit for a transparent DCC
• A section or line DCC port can only have one “protocol” running on it at a
time, either LAPD, PPP or Transparent. To change the protocol, the DCC
port must be deleted and re-created.
• The DCC Transparency connection cannot be edited once provisioned.
You need to delete the provisioned connection before creating a new one.
• The DCC Transparency connection cannot be provisioned to itself.
• DCC Transparency is supported on all circuit packs that support DCC and
only on ports that support DCC. The connection can be provisioned from
any port on any circuit pack to any other port on any circuit pack. This
includes from one port to another port on the same circuit pack.

• DCC Transparency supports provisioning between non-similar traffic line

rates. For example, section DCC from a 2.5G port can be DCC hairpinned
to the section DCC of a 10G port.
• The DCC Transparency connection must be between equivalent DCC
types (a Section DCC port to Section DCC or a Line DCC port to a Line
DCC port). You cannot provision a Line DCC to a Section DCC and
vice-versa.
• It is recommended not to exceed one hop when using DCC Transparency.
• The 6500 HDLC Frame Check Sequence (FCS) can be set to be either
16-bit or 32-bit when setting up a DCC Transparent connection.
Interworking requirements
• DCC Transparency provides transparency between two NEs at the
datalink layer.
• DCC Transparency only supports transparency of HDLC based datalink
protocols.
• DCC Transparency does not translate between different datalink
protocols. For example, if one end NE uses PPP and the other end NE
uses LAPD, putting them though the DCC Transparency will not make
them inter-operate.
• DCC Transparency applies to SONET, SDH, and SDH-J protocols.
• DCC Transparency supports transparency of packets that are less than
approximately 1530 bytes.
• DCC Transparency is not reliant on any provisioned datalink (or higher)
parameters on the far-end/connecting NEs, except for not exceeding the
maximum packet size.
• DCC Transparency connectivity does not affect any protection capabilities
on the port.
• DCC Transparency is not affected by OSI areas or domains (that is,
connections for NEs belonging to different OSI areas or domains on the
same 6500).
Limitations
• When configuring DCC Transparency across two 6500 nodes or more, a
path for each side of the ring or linear span must be configured to provide
protection.
• When configuring DCC Transparency across two 6500 nodes or more, the
DCC Transparency replaces the DCC normally used for these node to
communicate to each other. Thus each 6500 requires an individual LAN
drop.

ATTENTION
If two nodes are interconnected by another ring or linear span where DCC
can be enabled, then an individual LAN drop is not necessary.
Figure 1-72
Example of DCC transparency across two 6500 nodes
OM3000 Site
Manager
+ OM3000
6110 MS-MOA
WEB UI
PC-1
LAN
Section DCC
LAPD Section DCC
OM3500 LAPD 3500
Section or Line
TDCC path 1
NP
OC-48
Linear
OC-192 Ring
Section Section
DCC DCC
GRE GRE
Tunnel Tunnel
Section or Line
TDCC path 2
6500 6500
6110 NE1 PC-2 6110 NE2
Legend
= OC-48 Interfaces
= OC-192 Interfaces
= OC-3 or 12 Interfaces

6500 and CPL interworking

Interconnecting the 6500 and CPL comms networks provides the following
advantages:
• Provides a redundant comms path for each other in case of OSC or GCC
comms failure.
• Provides the ability to have a common gateway network element function.
• Permits a craft connected to a 6500 shelf to access CPL shelves and vice
versa.
For these reasons it is recommended that 6500 and CPL be interconnected

by ILAN ports at each collocated site. If there are more than two network
elements to be interconnected, the network elements can be daisy chained.
OSPF must be enabled on the ILAN ports of both the 6500 and CPL.
6500 ILAN carrying OSPF can be connected to CPL ILAN as follows:

• on 6500, the IP on ILAN should be set to 0.0.0.0 with net mask
255.255.255.255
• on CPL Release 3.1 the IP on ILAN should be set to 0.0.0.0 with net mask
0.0.0.0
Note that for CPL, the parameter specifying the destination IP must also be
set.
OSPF runs on the CPL OSC and the ILAN ports interconnecting the 6500 to
the CPL shelves. The GCC channels run IISIS or OSPF as the routing
protocol.
6500 Release 9.1 and CPL Release 5.0 supports a mixed TIDc configuration.
Refer to “TID consolidation (TIDc)” on page 1-107 for details.
For more information on 6500/CPL interworking and supported

configurations, refer to the 6500 Interworking guide.
Refer to Table 1-75 on page 1-417 for information on communication port

speeds for 6500.
For CPL OSC and ILAN communication ports speed, refer to the “Data
communications” chapter in Part 2 of the Common Photonic Layer Planning
Guide, NTT840FV.
Figure 1-73 on page 1-334 to Figure 1-78 on page 1-338 shows the typical
interworking between 6500 and CPL.

Figure 1-73
6500/CPL interworking: Homogeneous OSPF network
Terminal Regenerator Terminal
ILAN/OSPF ILAN/OSPF ILAN/OSPF ILAN/OSPF
6500 CPL CPL 6500 CPL CPL 6500
OSC/PPP/OSPF OSC/PPP/OSPF
GCCO/PPP/OSPF GCCO/PPP/OSPF
When interworking between 6500 and CPL it is recommended that all

interconnected nodes run the OSPF routing protocol only. Configuring all
nodes in a homogeneous routing domain simplifies configuration. A
homogeneous OSPF routing domain eliminates the need for route
redistribution between IISIS.
ATTENTION
As the GCC is lower bandwidth than the OSC, it is important to set the OSPF
cost of the GCC channel to ensure that the OSC channel is the preferred
route in a homogeneous OSPF routing domain. Note that the total OSPF
route cost, for a given route between any two NEs is the sum of the OSPF
route cost for each intermediate hop in that route.
In cases where both the OSPF and IISIS routing protocols are used within the
network, each 6500 node should be configured such that any given interface
participates in only one routing domain (that is, on any given 6500 NE, any
given interface should be configured with either an OSPF circuit, OR an IISIS
circuit, not both at the same time.)

Figure 1-74
6500/CPL interworking: OSPF preferred route
GCCO/PPP/IISIS GCCO/PPP/IISIS
6500 provisioning includes:

• OSPF circuits provisioned against SHELF-IP interface
• IISIS circuits provisioned against optical interface
• OSPF routes get redistributed into IISIS
In this example, OSPF is the preferred route. IISIS is an alternate path.
Figure 1-75
6500/CPL interworking: IISIS preferred route
GCCO/PPP/IISIS GCCO/PPP/IISIS

6500 provisioning includes:

• IISIS circuits provisioned against SHELF-IP interface
• OSPF circuits provisioned against ILAN interface
• IISIS routes get redistributed into OSPF
In this example, IISIS is the preferred route. OSPF is an alternate path.
For example, if cost of the OSC and ILAN links is 10 and there are 10 hops to
get to a remote CPL, then the cost over the OSC channel to reach the remote
CPL is 100. If you have a GCC cost set to 75 and an ILAN cost set to 10 with
three hops (CPL to 6500 over ILAN=10, 6500 to 6500 over GCC =75 and 6500
to CPL over ILAN=10), then the cost to reach the remote CPL is 95. In this
case the channel over the GCC is a lower cost and will be the selected path
which is not recommended.
The GCC cost should be changed from the default to guarantee that the cost
is lower for the ILAN/OSC path than that of the GCC path. In this example, you
should set the GCC to at least 85, to get a total cost of 105. This ensures that
the CPL system uses the ILAN and OSC connections and does not route over
the lower bandwidth GCC to a remote site unless there is an OSC failure. This
applies to all links in the network.
Internal DCN architectures

For networks with Single Stretch Spans (SSS), the CPL OSC is not available
for Comms. Therefore you need to use the 6500 GCC communications to
provide the CPL communications path.
Combined Internal DCN for CPL and 6500 provides the following advantages:
• Highest Bandwidth Solution
— provides a 100+Mbps DCN capability shared with DOC traffic (for
example, 50 Mbps for DCN)
• Lowest Latency
— lower per OSC link as 155Mbps clocking
• Simplify the In-Band Design and Maximizes Resilience
— DCN is provided as part of the CPL layer, then the 6500 connectivity
is not required to provide comms or redundancy
Figure 1-76 on page 1-337 shows the 6500 and the CPL Combined In-Band
Comms with internal OSPF and no SSS link.

Figure 1-76
6500/CPL interworking: Optimal DCN Configuration—no SSS
DCN DCN
L L L CP L L L CP
CP CP CP L CP CP CP L
00 00 00 00
65 65 65 65
Legend
= Fiber with OSC
= Fiber without OSC (Single Stretch Span)
= Ethernet NE - NE (OSPF Routing)
= Ethernet NE - DCN (OSPF Routing)
= Global Communications Channel (GCC)
Comms with internal OSPF and SSS link.
Figure 1-77
6500/CPL interworking: Optimal DCN Configuration—with SSS
SSS Link
Comms over
DCN OSC should DCN
not be used
L L L CP L CP
CP CP CP L CP L
GCC GCC
00 00 00 00
65 65 65 65
DCN Design
ensures that the
GCC communications
is used
Legend
= Fiber with OSC
= Fiber without OSC (Single Stretch Span)
= Ethernet NE - NE (OSPF Routing)
= Ethernet NE - DCN (OSPF Routing)
= Global Communications Channel (GCC)

Comms with Ethernet connectivity at non-GNE sites.
Figure 1-78
6500/CPL interworking: Optimal DCN configuration—Ethernet connectivity
1 x 6500 2 x 6500
X X
L CP CP L
CP L L CP
X X X X
00 00 00
65 X 65 X 65
>2 x 6500
L CP
CP L
00 X 00
65 65
X X
X X
00 00
65 X 65
For an example of interconnecting the 6500 and the CPL network elements,
see “DCN example 23—using OSPF with two 6500 gateway network
elements connected to OSPF backbone with collocated CPL network
elements” on page 1-296.

OSC communications in 6500/CPL line interworking configurations

Regardless of the 6500/CPL release combination, in a given supported
6500/CPL line interworking configuration, from a communications
perspective, the OSC between the 6500 and CPL work the same way as if the
CPL NE was a 6500 NE. Refer to Figure 1-79 on page 1-339 for an example.
6500 Private-IP GNE configurations are not supported by OneControl, but
other 6500 GNE configurations can be used to manage the CPL remote
network elements.
Figure 1-79
6500/CPL interworking: OSC communications (example)
6500 CPL 6500

ROADM or
... ROADM or
TOADM or
TOADM or
ROADM or
TOADM or
...
GOADM or
Line amp Line amp
Line amp

6500 and 5100/5200 interworking

For 5100/5200 and 6500 network elements to interwork, you must manually
provision the OSPF Area ID, IP address, authentication password and router
dead interval on the GCC link to be the same as 5100/5200.
• Area ID—The Area ID of a GCC channel on the 5100/5200 can be either
user-provisioned or by default the area is the same as the IP address of
the primary shelf. In either case it is never the backbone area. If a 6500 is
connected to an 5100/5200, the Area ID of the GCC link must be the same
as the 5100/5200.
• IP address—The 5100/5200 assumes it is connected to a numbered
point-to-point link. Therefore the 6500 GCC link requires an IP address to
be assigned. The address must be 10.0.x.y, where 129 <= x <= 254, and
32 <= y < 96. The mask must be set to 255.255.255.0. If the 6500 has links
to more than one 5100/5200, each link must have a unique subnet
assigned (a unique value for 'x', above). After assigning the IP address, a
warm restart of the 6500 circuit pack is required.
• Authentication—The 5100/5200 uses simple password authentication in
all its packets. The default password is OPTeraM (case sensitive). 6500
allows the authentication to be enabled per circuit and allows the
password to be set per circuit.
• Router Dead Interval - The router dead interval of the 5100/5200 and 6500
link must match. The 6500 side is configurable and must be set to 30
seconds.
• Interworking is only supported on the GCC link between the 6500
10G OTR, 2x10G OTR, 10G OTSC, 10G OTN WT, or 40G MUX OCI
circuit pack, and the 5100/5200 L2 MOTR, QTR, QTRE, and 10G Ultra
circuit packs.
• With OM5000 using Stretched Span through GCC channels, the only way
to provide a functional comms path that will pass Opaque LSA type 11
messages (required for AR and TR) is to carry the full 6500 ILAN 100bT
in band via 1 GbE port path (using a media converter) on a point to point
10G MOTR service across the long span.

• Interworking must be limited to one link between a given 6500 NE and a

given 5100/5200 NE. For example, if there are two 10G OTR, 2x10G OTR,
or 10G OTSC circuit packs in the 6500 NE and two 10G Ultra circuit packs
in the 5100/5200 NE, only one circuit pack must have a GCC link up. The
GCC channels must be disabled on the other circuit pack. Failure to meet
this rule will cause a loss of association between the 6500 and 5100/5200
shelves. It is possible to have a given 6500 NE connected to multiple
5100/5200 NEs using a single link to each. In order to disable the extra
links:
— on the 6500, delete the OSPF circuits on the extra links
— on the 5100/5200, disable any GCC channels to the 6500 NE. This
can be done under the OTR facility page in System Manager.
• The 5100/5200 cannot be a GNE for a 6500 or CPL NE.
• 6500 cannot be a GNE for an 5100/5200 shelf with the 6500 “Dual GNE
using NAT” DCN comms configuration. Other 6500 DCN comms
configuration can be used (for example, Dual GNE with OSPF, Single GNE
using static routes or Proxy ARP).
• It is recommended that the ED-SYS parameters for GCC0MODE and
GCC1MODE be turned off on 6500 NEs that will interwork with 5100/5200
NEs since the default autoprovisioning configuration will need to be
deleted anyway.
Figure 1-80 on page 1-341 shows the typical interworking between the 6500
and the 5100/5200.
Figure 1-80
6500 and 5100/5200 interworking (Broadband services)
Regen
OTU2 client
5100/5200 5100/5200
10G 10G 10G 10G

Ultra Line RS8 OTR OTR Line RS8 Ultra
or SCFEC or SCFEC
GCC0 (OSPF) GCC0 (OSPF)
GCC1/2 (OSPF)

The following engineering rules exist:

• The 10G OTR, 2x10G OTR, or 10G OTSC is a regenerator which
sources/sinks GCC0. GCC1 and GCC2 are passed transparently through.
• The 10G Ultra supports both GCC1/2, both are available end-end.
• The user can choose the autoprovisioning behavior of the GCC0 channel
using the ED-SYS command. By default, GCC0 will be disabled. When
interworking with 5100/5200, the GCC0 channel must be provisioned with
the OSPF protocol.
• The default values the 6500 NE uses for OSPF autoprovisioning do not
match the values used by the 5100/5200. The 5100/5200 expects a
non-backbone area, a numbered interface, a specific OSPF password and
a router dead interval of 30 seconds. The 6500 autoprovisions in the
backbone area, as an un-numbered interface with no OSPF password and
with a router dead interval of 40 seconds.
• GCC 1 or 2 must be enabled so that the 5100/5200 shelves become
OSPF neighbors. This is important because 5100/5200 uses a proprietary
protocol called NNP (nearest neighbor protocol) to propagate events and
alarms around the ring. NNP is dependent on OSPF neighbor
relationships. Without GCC1/2, events occurring on one 5100/5200 shelf
will not appear on an SMI session hosted off the other 5100/5200 shelf.
Figure 1-81 on page 1-343 shows the interworking between the 6500 and the
5100/5200 (single GNE using Proxy ARP).

Figure 1-81
6500 and 5100/5200 interworking (single GNE using Proxy ARP)
OneControl
OSPF area 1
CPL CPL Craft
DCN Subnet
C
Subnet
A 6500
6500
OSPF Regen
Regen OSPF
area 1
area 1
5100/ 5100/
5200 5200
Subnet
B
LEGEND
= COLAN = ILAN
= GCC0 = OSC
= GCC1 = Craft connection

• In this configuration, one NE is connected to the DCN and does proxy ARP
for the remote NEs (RNEs). The RNE can be another 6500 shelf
connected by an ILAN or GCC link, a CPL shelf, or an 5100/5200 shelf.
• The entire network has a single connection to the DCN through a 6500
shelf. This COLAN port of the GNE is in DCN subnet A.
• The CPL and 5100/5200 are RNEs. It is also possible for the CPL to be
the GNE since it supports the single GNE solution.
• All the RNEs and the SHELF IP address of the GNE is in DCN subnet B.
• The DCN router interface subnet is at least as large as subnet A and
subnet B combined.
• The Craft ports are in subnet C. Every NE has a unique craft port subnet.
• The GNE is provisioned to do proxy ARP for subnet B.
• The 5100/5200 and 6500 interconnect through a GCC channel running
OSPF. 6500 and CPL interconnect using OSPF on the ILAN ports.

• The CPL, 6500, and 5100/5200 shelves run in an OSPF non-backbone

area. The 6500 and CPL shelves must be in the same area as the
5100/5200. This must be provisioned on the 6500 and CPL.
• The craft PC has IP reachability to every NE in the network if an OSPF
circuit is created on the LAN-15/LAN-41 port. The craft does not have
reachability to the customer DCN.
Figure 1-82 on page 1-344 shows the interworking between the 6500 and the
5100/5200 (Dual GNE using OSPF).
Figure 1-82
6500 and 5100/5200 interworking (Dual GNE using OSPF)
OneControl
Regen site
DCN DCN
OSPF area 1
CPL CPL CPL CPL
GNE 6500 6500 6500 6500 GNE

1 2
OSPF area 1
5100/ OSPF area 1 5100/ Craft

5200 5200
LEGEND
= COLAN = ILAN
= GCC0 = OSC
= GCC1 = Craft connection


• GNE 1 and GNE 2 are both connected to the customer DCN through
COLAN ports. The CPL and 5100/5200 are RNEs. The CPL can be the
GNE if desired.
• The 5100/5200 and 6500 interconnect through a GCC channel running
OSPF. 6500 and CPL interconnect by OSPF on the ILAN ports.
• The CPL, 6500, and 5100/5200 shelves run in an OSPF non-backbone
area. The 6500 and CPL shelves must be in the same area as the
5100/5200. This must be provisioned on the 6500 and CPL.
• OSPF is enabled on the GNE COLAN ports and has the same Area ID has
defined by 5100/5200. The Gateway router ports are also in the same
Area ID.
• OSPF is used across the 6500 GCC0 circuits. The OSPF parameters
must match the 5100/5200 values.
• Because every 6500 node has a CPL interconnect as well, every node has
reachability to every other node.
• Every NE is assigned an IP address in the DCN space. Connectivity to the
SHELF IP address is advertised to the DCN as a host route.
• The configuration can cause the 5100/5200 internal Private-IPs (10.1.1.0
to 10.4.255.255) to be advertised to the DCN. You can filter out these IPs
at the gateway router level.
• The craft port is assigned a unique IP subnet and OSPF is enabled on the
craft port of each NE.
— The craft is able to access every NE. If the craft IP subnet is from the
DCN address space, the craft subnet is also advertised to the DCN, so
the craft is able to access the DCN. This is not the case if the craft IP
subnet is not from the DCN address space.
— If the Craft IPs are from a Private-IP address range, they can be
advertised to the DCN. To avoid this, you can either filter out the
Private-IP addresses at the gateway router level or you can use public
IP addresses.
• If the 5100/5200 Network is in Private-IP configuration and the 6500
network is in Public IP configuration (Private-IP not supported on 6500),
then System Manager Interface (SMI) must be configured to send
SNMPv3 requests to the NEs.

6500/5200 network with 6500 Proxy ARP GNE configuration

for the other 6500 and 5200 network elements. The 6500 gateway network
element will proxy ARP for all network element IP addresses in subnet A
which includes the remote network elements.
Each 6500 and 5200 network element is assigned a public SHELF IP address
from the same subnet. The 6500 COLAN-X interface on the gateway network
element is assigned an IP address in the same subnet of the router port
connected to the gateway network element. Each SHELF IP address is visible
within the external DCN. The subnet on the DCN router port that connects to
the COLAN-X port of the gateway network elements, must be large enough to
element for which the gateway network element will proxy ARP for. The GCC
link between 6500 shelves is unnumbered to conserve IP addresses.
The 5200 2X and 6500 ILAN-IN Ethernet ports are cabled to an Ethernet hub
to connect the collocated network elements. Private-IP addresses are
assigned on the 2X-ILAN interfaces to conserve public IP addresses.
A default route (static route) is provisioned at the gateway 6500 network

element which is redistributed in the OSPF router. The IP addresses of the
remote 5200 and 6500 network elements are provisioned in the proxy ARP
table on the 6500 GNE, so that it can proxy ARP for their IP addresses.
The internal routing protocol for the 6500/5200 network is OSPF. When the
internal routing protocol is OSPF, OSI traffic cannot be routed through the
network element.

Figure 1-83
Example of 6500/5200 network
Site
SMI
Manager
LAN
DCN/WAN
2X ILAN subnet:
default addresses
10.2.1.Shelf ID/24 Ethernet Hub
LAN LAN COLAN-X

2X 2X LAN Out In
In GNE
Site 1 5000 NE1 5000 NE2 6500 NE1 6500 NE2
Shelf IP: Shelf IP: Shelf IP: Shelf IP:
47.1.1.6/32 47.1.1.7/32 47.1.1.3/32 47.1.1.2/32
Shelf ID: 1 Shelf ID: 2 5000 NE ID: 5 5000 NE ID: 6
Hub Group: 1 Hub Group: 1
Primary
Shelf IP: Shelf IP: Shelf IP: Shelf IP:

47.1.1.8/32 47.1.1.9/32 47.1.1.4/32 47.1.1.5/32
Shelf ID: 3 Shelf ID: 4 5000 NE ID: 7 5000 NE ID: 8
Hub Group: 2 Hub Group: 2
Site 2 5000 NE3 5000 NE4 6500 NE3 6500 NE4
LAN LAN LAN
2X 2X
In Out In
2X ILAN subnet: Ethernet Hub

default addresses
10.2.2.Shelf ID/24
Legend
Numbered Ethernet
Un-numbered Ethernet
5000-series comms channel
6500 comms channel

6500/5200 DCN engineering guidelines

The following are DCN engineering guidelines for 6500/5200.
• SMI management of 6500 is not supported. Therefore, the 6500 must not
be provisioned for this application. The following parameters should be left
at the disabled values:
— OM5000 Primary IP = 0.0.0.0 (default)
— OM5000 NE ID = 0 (default)
Otherwise, data communications inter-operation between 6500 and
5100/5200 is supported.
• All 5200 network elements must be running a committed software load of
release 10.1 or later.
• The 6500 must be explicitly configured to run OSPF to allow routes to be
learned between the 5200 and the 6500. An OSPF router and OSPF
circuits must be added for the ILAN and shelf interfaces.
• It is recommended that OSPF be used as the only routing protocol within
the integrated 5200 and 6500 network. This simplifies network
configuration and support.
• There must be at least one site where the 5200 and 6500 network
elements are physically interconnected using Ethernet-2X and ILAN ports.
Having more than one interconnection point can provide improved
tolerance to network disruptions.
• Ethernet-2X to ILAN links can use 'private' (non-DCN-visible) addresses,
including the default 5200 Ethernet-2X addresses
(10.2.hubbing-group.shelfID/24). Note that 6500 does not have the
concept of 'hubbing-group'. If the Ethernet-2X default address is used, the
6500 ILAN link must be configured to be in the same subnet as the 5200
Ethernet-2X port(s). For example, if the 5200 hubbing-group is '3', the
ILAN address should be in the 10.2.3.x/24 subnet.
• OSPF costs on the 6500 ILAN links which are connected to collocated
5200 network elements should be set sufficiently high so that 6500
external traffic always prefers to stay inside the 6500 network.
• 6500 OSPF circuits for interconnected ILAN-2X ports and all SHELF IP
interfaces must be added using the parameters shown in Table 1-60 on
page 1-349.

• 6500 OSPF circuits for internal circuits (ILAN-to-ILAN, DCC, and GCC)
can be chosen as per existing 6500 guidelines, with the exception of the
OSPF area, which must be set to the same value as the 5200 network.
See Table 1-61 on page 1-350 for the recommended OSPF circuit
settings.
• 5200 external time of day synchronization is not supported when the 6500
is configured as the GNE.
Table 1-60
6500 ILAN-2X and SHELF OSPF circuit parameters
Parameter Value
Name ILAN-shelf#-IN/OUT and SHELF-shelf#
Network area set to OSPF area ID of 5200 network
Cost • SHELF = 0 (read only)

• ILAN-2X = 10000 (Note 1)
Area default cost 1 (default)
Router dead interval 30 seconds
Hello interval 10 seconds (default)
Retransmit interval 5 seconds (default)

Transmit delay 1 (default)
Priority 6
Area Off (default)

Area virtual link leave blank (default)
Password authentication On
Circuit password (case sensitive) OPTeraM

Opaque link state advertisement Off (Note 2)
Note 1: Recommended values. Actual values can be changed to suit network

requirements.
Note 2: Recommended setting, since 5200 does not support opaque LSAs.

Table 1-61
6500 ILAN-ILAN and GCC OSPF circuit parameters
Parameter Value
Name ILAN-shelf#-IN/OUT OTM3-shelf#-slot#-port#
Network area set to OSPF area ID of 5200 network

Cost ILAN = 10 (default)
OTU3/ODU3 GCC = 19 (Note)
Area default cost 1 (default)
Router dead interval 40 seconds (default)
Hello interval 10 seconds (default)
Retransmit interval 5 seconds (default)
Transmit delay 1 (default)
Priority 1 (default)
Area Off (default)
Area virtual link leave blank (default)
Password authentication Off (default)
Circuit password (case sensitive) -
Opaque link state advertisement On (default)
Note: Recommended values. Actual values can be changed to suit network requirements

Greenfield 6500/5200 network with 6500 GNE interworking

SMI management of 40G services with 6500 as GNE is performed as follows:
1 Ensure the installation of the 6500 and 5200 network elements is complete.
2 Commission the 6500 network elements using the data in Table 1-62 on
page 1-352 as a guide. Follow the Nodal SLAT Procedures Commissioning
and Testing, 323-1851-221.
3 After all 6500 40G OCLD and Wavelength-Selective 40G OCLD circuit packs
have their wavelength tuned and the “Tx Tuning in Progress” alarm has
cleared, perform a non-service affecting warm restart for all circuit packs that
raise the “GCC0 Link Fail” alarm.
From the Site Manager Faults/Restart menu:
• select Shelf: shelf#
• select Circuit pack: 40GOCLD-slot#
• select the Restart type: Warm
• click OK
Repeat step 3 for all 40G OCLD and Wavelength-Selective 40G OCLD circuit
packs on the 6500 network elements that raise the “GCC0 Link Fail” alarm.
4 Commission the 5200 network elements using the data in Table 1-63 on
page 1-356 as a guide. Follow the 5200 Commissioning Procedures in
323-1701-220.
5 Verify all 6500 and 5200 network elements are accessible from the DCN:
• Ping all 6500 and 5200 SHELF IP addresses from a PC or workstation in
the DCN. Verify that each shelf is reachable.
• Perform a traceroute to each 6500 and 5200 shelf to verify that the path
is as expected.

Example of 6500 commissioning information

Table 1-62 on page 1-352 provides an example of the commissioning
information and DCN parameters for the 6500 network elements shown in
Figure 1-83 on page 1-347. Blank 6500 commissioning worksheets are
provided in Table 1-64 on page 1-357 to assist with network planning.
Table 1-62
Example of 6500 commissioning data
6500 commissioning NE1 NE2 NE3 NE4

1 NE Identification
NE Name (TID) 6500-1 6500-2 6500-3 6500-4
CLLI - - - -
2 NE configuration
Shelf Number 1 1 1 1
Shelf IP address 47.1.1.3 47.1.1.2 47.1.1.4 47.1.1.5
OM5000 NE ID 0 0 0 0
OM5000 Primary IP address 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Site ID 1 1 2 2
Sit Name Site 1 Site 1 Site 2 Site 2
TID Consolidation Disable Disable Disable Disable
TID Consolidation Primary Disable Disable Disable Disable
NE Mode SONET SONET SONET SONET
GCC0 Mode OSPF OSPF OSPF OSPF
Alarm Correlation Off Off Off Off
Bay Number - - - -
Frame Identification Code - - - -
Subnet Name - - - -
Bay Number and FIC in AO False False False False
3 GNE configuration
GNE No Yes No No
Single Shelf IP - Yes - -
GNE Configuration - Standalone ARP - -
OSPF Router Id 47.1.1.3 47.1.1.2 47.1.1.4 47.1.1.5
Link State Announcement External External External External
Type
Autonomous System
Border Router Off Off Off Off

Table 1-62
Example of 6500 commissioning data (continued)

5 ILAN provisioning
Add ILAN-shelf#-IN port Yes Yes Yes Yes
Add IP address on
ILAN-shelf#-IN port:
IP Address 10.2.1.5 0.0.0.0 10.2.1.7 0.0.0.0
Subnet Mask 255.255.255.0 255.255.255.255 255.255.255.0 255.255.255.255
Port Enabled Yes Yes Yes Yes
Routing Protocol OSPF OSPF OSPF OSPF
Network Area 47.1.1.6 47.1.1.6 47.1.1.6 47.1.1.6
Cost 10000 10 (default) 10000 10 (default)
Dead Interval 30 40 (default) 30 40 (default)
Hello Interval 10 (default) 10 (default) 10 (default) 10 (default)
Retransmit Interval 5 (default) 5 (default) 5 (default) 5 (default)
Transmit Delay 1 (default) 1 (default) 1 (default) 1 (default)
Priority 6 1 (default) 6 1 (default)
Area Default Cost 1 (default) 1 (default) 1 (default) 1 (default)
Area Virtual Link - - - -
Area Off (default) Off (default) Off (default) Off (default)
Password Authentication On Off (default) On Off (default)
Password OPTeraM - OPTeraM -
Opaque Link State Off - Off -
Advertisement
Add ILAN-shelf#-OUT port Yes No Yes No
Add IP address on
ILAN-shelf#-OUT port:
IP Address 0.0.0.0 - 0.0.0.0 -
Subnet Mask 255.255.255.255 - 255.255.255.255 -
Port Enabled Yes - Yes -
Routing Protocol OSPF - OSPF -
Network Area 47.1.1.6 - 47.1.1.6 -
Cost 10 (default) - 10 (default) -
Dead Interval 40 (default) - 40 (default) -
Hello Interval 10 (default) - 10 (default) -
Retransmit Interval 5 (default) - 5 (default) -
Transmit Delay 1 (default) - 1 (default) -
Priority 1 (default) - 1 (default) -
Area Default Cost 1 (default) - 1 (default) -
Area Off (default) - Off (default) -
Password Authentication Off (default) - Off (default) -
Password - - - -

Table 1-62

6 Shelf IP provisioning
IP Address 47.1.1.3 47.1.1.2 47.1.1.4 47.1.1.5
Subnet Mask 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255
Routing Protocol OSPF OSPF OSPF OSPF
Network Area 47.1.1.6 47.1.1.6 47.1.1.6 47.1.1.6
Cost 0 (read only) 0 (read only) 0 (read only) 0 (read only)
Dead Interval 30 30 30 30
Priority 6 6 6 6
Area Off (default) Off (default) Off (default) Off (default)
Password Authentication On On On On
Password OPTeraM OPTeraM OPTeraM OPTeraM
7 COLAN provisioning
Add COLAN-shelf#-X port No Yes No No
IP Address - 47.1.1.2 - -
Subnet Mask - 255.255.255.0 - -
Proxy ARP - On - -
Port Enabled - Yes - -
Default Gateway - 47.1.1.1 - -
Default Gateway Cost - 2 - -
OSPF Redistribution - No - -
8 Proxy ARP provisioning (Note)
proxy:
Start address - 47.1.1.3 - -
End address - 47.1.1.9 - -

Table 1-62

9 DCC/GCC provisioning
Add/Edit GCC:
AID OTM3/OTM4-shelf#- OTM3/OTM4-shelf#- OTM3/OTM4-shelf# OTM3/OTM4-shelf#-
slot#-port# slot#-port# - slot#-port#
Carrier GCC0 GCC0 slot#-port# GCC0
Protocol PPP PPP GCC0 PPP
IP Address 0.0.0.0 0.0.0.0 PPP 0.0.0.0
Subnet Mask 255.255.255.255 255.255.255.255 0.0.0.0 255.255.255.255
Routing Protocol OSPF OSPF 255.255.255.255 OSPF
Network Area 47.1.1.6 47.1.1.6 OSPF 47.1.1.6
Cost 19 (default) 19 (default) 47.1.1.6 19 (default)
Dead Interval 40 (default) 40 (default) 19 (default) 40 (default)
Priority 1 (default) 1 (default) 1 (default) 1 (default)
Area Virtual Link - - 1 (default) -
Area Off (default) Off (default) - Off (default)
Password Authentication Off (default) Off (default) Off (default) Off (default)
Password - - Off (default) -
-
10 Static routes provisioning
IP Address - 0.0.0.0 - -
Subnet Mask - 0.0.0.0 - -
Next Hop - 47.1.1.1 - -
Circuit - COLAN-shelf#-X - -
Cost - 2 - -
11 OSPF - routes distribution
Add Static Redistribution
(GNE only)
IP Address - 0.0.0.0 - -
Subnet Mask - 0.0.0.0 - -
Metric - 10 - -
Metric Type - External - -
Distribution List - STATICRDLIST - -
Note: IP addresses in the Proxy ARP table must be entered individually if the address range for all network
elements are not consecutive.

Example of 5200 commissioning information

Table 1-63 on page 1-356 provides an example of the commissioning
information and DCN parameters for the 5200 network elements shown in
Figure 1-83 on page 1-347. Blank 5200 commissioning worksheets are
provided in Table 1-65 on page 1-361 to assist with network planning.
Table 1-63
Example of 5200 commissioning data

Network Name 5200 Network 5200 Network 5200 Network 5200 Network
Site Name (CLLI) Site 1 Site 1 Site 2 Site 2
Shelf Name OM5000-1 OM5000-2 OM5000-3 OM5000-4
Shelf Description Shelf 1 Shelf 2 Shelf 3 Shelf 4
Site ID 1 1 2 2
Shelf Identifier 1 2 3 4
Shelf is DCN Gateway No No No No
External Routing Mode NONE NONE NONE NONE
Shelf Address 47.1.1.6 47.1.1.7 47.1.1.8 47.1.1.9
Primary Shelf Address 47.1.1.6 47.1.1.6 47.1.1.6 47.1.1.6
Subnet Mask 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255
DHCP Address 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Default Gateway Address 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Shelf Type OADM OADM OADM OADM
Ethernet Hubbing Group 1 1 2 2
10Base-T 1X ENABLED ENABLED ENABLED ENABLED
Set TID to SHELF NAME Yes Yes Yes Yes
Additional provisioning steps
Set Internal OSPF Area ID 47.1.1.6 (Primary) 47.1.1.6 (Primary) 47.1.1.6 (Primary) 47.1.1.6 (Primary)

Table 1-64
6500 commissioning worksheet

1 NE Identification
NE Name (TID)
CLLI
2 NE configuration
Shelf Number
Shelf IP address
Site ID
Sit Name
TID Consolidation
TID Consolidation Primary
NE Mode
GCC0 Mode
Alarm Correlation
Bay Number
Frame Identification Code
Subnet Name
Bay Number and FIC in AO
3 GNE configuration
GNE
Single Shelf IP
GNE Configuration
4 OSPF Router Provisioning
OSPF Router Id
Link State Announcement
Type
Route summarization
Router

Table 1-64
6500 commissioning worksheet (continued)

5 ILAN Provisioning (Note)
Add ILAN-shelf#-IN port
Add IP address on
ILAN-shelf#-IN port:
IP Address
Subnet Mask
Port Enabled
Routing Protocol
Network Area
Cost
Dead Interval
Hello Interval
Retransmit Interval
Transmit Delay
Priority
Area Default Cost
Area Virtual Link
Area
Password Authentication
Password
Opaque Link State
Advertisement
Add ILAN-shelf#-OUT port
Add IP address on
ILAN-shelf#-OUT port:
IP Address
Subnet Mask
Port Enabled
Routing Protocol
Network Area
Cost
Dead Interval
Hello Interval
Retransmit Interval
Transmit Delay
Priority
Area Default Cost
Area Virtual Link
Area
Password

Table 1-64

6 Shelf IP provisioning
IP Address
Subnet Mask
Routing Protocol
Network Area
Cost
Dead Interval
Hello Interval
Retransmit Interval
Transmit Delay
Priority
Area Default Cost
Area Virtual Link
Area
Password
7 COLAN provisioning
Add COLAN-shelf#-X port
IP Address
Subnet Mask
Proxy ARP
Port Enabled
Default Gateway
Default Gateway Cost
OSPF Redistribution
8 Proxy ARP provisioning
proxy:
Start address
End address

Table 1-64

9 DCC/GCC provisioning
Add/Edit GCC:
AID
Carrier
Protocol
IP Address
Subnet Mask
Routing Protocol
Network Area
Cost
Dead Interval
Hello Interval
Retransmit Interval
Transmit Delay
Priority
Area Default Cost
Area Virtual Link
Area
Password
10 Static routes provisioning
IP Address
Subnet Mask
Next Hop
Circuit
Cost
11 OSPF - routes distribution
Add Static Redistribution
(GNE only)
IP Address
Subnet Mask
Metric
Metric Type
Distribution List
Note: The ILAN-IN OSPF Circuits for the ILAN-2X connection on 6500-1 and 6500-3 must be edited
using Site Manager to ensure the Opaque Link State Advertisement is properly set to OFF. The 6500
NSAT tool does not allow you to set this value and it will default to ON.

Table 1-65
5200 commissioning worksheet
Network Name
Site Name (CLLI)
Shelf Name
Shelf Description
Site ID
Shelf Identifier 1 2 3 4
Shelf is DCN Gateway No No No No
External Routing Mode NONE NONE NONE NONE
Shelf Address
Primary Shelf Address
Subnet Mask 255.255.255.255 255.255.255.255 255.255.255.255 255.255.255.255
DHCP Address 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Default Gateway Address 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Shelf Type
Ethernet Hubbing Group
Set TID to SHELF NAME Yes Yes Yes Yes
Additional provisioning steps
Set Internal OSPF Area ID

Migrate an existing 5200 network with Proxy ARP GNE to an integrated

5200/6500 network with 6500 Proxy ARP GNE
This section details the steps involved in migrating the data communications
from an 5200-only network with Proxy ARP GNE to an integrated 5200/6500
network with a 6500 Proxy ARP GNE.
The high-level steps are:

• Connect the 6500 shelves into the existing 5200 network
• Verify the connectivity
• Prepare the 6500 Proxy ARP GNE
• Remove the 5200 GNE
• Connect the 6500 GNE and complete the provisioning
• Verify the connectivity
Preliminary conditions
The following are pre-conditions and information that should be gathered
before starting the migration.
• Ensure that the IP addressing plan for the 6500 shelves has been
prepared prior to starting the migration procedure. Since both the 5200
and 6500 shelves will be managed through a proxy ARP GNE, these
addresses (one per shelf) must be allocated from the DCN subnet to
which the GNE is attached.
• Ensure that the OSPF area of the existing 5200 network is known. If set to
0.0.0.0 (default), the OSPF area is set to be the same value as the IP
address of the 5200 primary shelf.
• Ensure that the hubbing-group at each 5200 site where 6500 shelves will
be interconnected is known.
• Ensure that the current 5200 GNE and the new 6500 GNE-to-be are
located at the same site. Therefore, the 6500 COLAN-X port will be
connected to the same subnet that the 5200 GNE was.

Limitations
It is recommended to use Private-IP addresses on the 2X-ILAN subnets.
When the 6500 NEs interconnected to the 5200 network and an 5200 GNE is
being used (interim step), some functionality is limited. In general, any
applications that initiate communications from the interconnected 6500
shelves out to the DCN will have limited functionality. These applications
include:
• FTP: affects load delivery, backups and restores
• SNTP: affects TOD synchronization to external sources. TOD may still be
synchronized to the 5200 primary shelf.
• RADIUS: affects centralized authentication to external servers
Once the GNE functionality is switched to the 6500, the limitations described
above no longer apply.
ATTENTION
There can be some temporary connectivity issues from the DCN to some
shelves due to stale ARP cache entries in the DCN router. These ARP cache
entries will time-out automatically and the duration will depend on how the
router is configured. The router may have its ARP cache flushed manually if
necessary.
ATTENTION
The 6500 GNE should not be connected to the DCN subnet until the 5200
GNE is fully decommissioned as a GNE and disconnected from that subnet
to avoid any potential conflicts.
Configuration example
The following configuration example is referred to throughout this document to
help illustrate the steps. It shows the target network configuration (i.e. after the
migration is complete), with one 6500 GNE and one 6500 interconnected to
the 5200 network at each site.

Figure 1-84
Network example
SMI
LAN
DCN/WAN
Private IPs
10.2.1.shelf ID/24 Hub High OSPF
cost
2X 2X In Out In COLAN-X
Site 1 5000 NE1 5000 NE2 6500 NE1 6500 NE2 GNE
(HG 1)
Site 2
(HG 2) 5000 NE3 5000 NE4 6500 NE3 6500 NE4
2X 2X In Out In
High OSPF
Private IPs Hub
cost
10.2.2.shelf ID/24
Legend
Numbered Ethernet
Un-numbered Ethernet
6500 comms channel

Configuration notes
It is expected that:
• There will be two interconnection sites to provide a redundancy between
the 5200 communication network and the 6500 communication network.
• The ILAN-IN port will be used to connect to the 5200 2X port(s). Note that
ILAN-IN and ILAN-OUT are identical so either could be used, but for
simplicity in this and the following procedures, it is assumed ILAN-IN is
used.
• All interfaces on the 6500s use unnumbered links except for the ILAN-IN
ports connected to the 5200s.
• The collocated 5200 and 6500 shelves will have their Ethernet-2X and
ILAN-IN/OUT ports connected directly or through an Ethernet hub. If more
than one 6500 shelf is collocated with the 5200, only one 6500 shelf
ILAN-IN/OUT port is required to be connected to the Ethernet hub. The
other 6500 shelves will be daisy-chained together (ILAN-IN to ILAN-OUT)
using unnumbered links.
• Interconnected shelves will use the 5200 default private addresses for the
Ethernet-2X and ILAN-IN/OUT ports, following the scheme of
10.2.hubbing-group.shelfID. Since the 6500 shelves will be assigned an
5200 shelfID and those shelfIDs must be unique within the 5200/6500
network, this guarantees uniqueness of the IP addresses. (Note:
hubbing-group is an 5200-only parameter assigned at commissioning
time. All shelves at the same site are assigned the same hubbing-group.)
• The 6500 OSPF circuit cost for the ILAN-IN/OUT port connected to the
collocated 5200 shelves should be set very high (10000) so that only
inter-shelf traffic (5200 primary to and from 6500 shelves) uses the
interconnection links.
• Redundant GCCs exist within the 6500 wavelengths to provide a fault
tolerant communication path between 6500 shelves.

GNE migration procedure

Connect the 6500 shelves
During this phase, the 6500 shelves are added to an existing 5200 network.
This phase is done as per existing configuration guidelines, with two
exceptions:
• The 6500 OSPF circuit cost assigned to the ILAN-IN links connected to
the 5200 network should be set very high (10000).
• The 2X-ILAN subnet uses the 5200 default IP address range
(10.2.hubbing-group.shelfID) rather than public IP addresses. Note that
this limits the types of actions that can be done on the 6500 shelves. Refer
to the section Limitations section for more information.
Figure 1-85 on page 1-367, provides an example 5200-only network to which

6500 shelves will be interconnected.
Figure 1-86 on page 1-368 shows the configuration once the 6500 shelves
are connected into the network. 6500-1 and 6500-3 are connected to the
same hub as the collocated 5200 shelves. 6500-1 and 6500-2 are
daisy-chained using unnumbered ILAN links, as are 6500-3 and 6500-4. The
6500-1 and 6500-3 ILAN-IN links are assigned 10.2.hubbing-group.shelfID IP
addresses; the cost of OSPF circuits on those links is set very high (10000).

Figure 1-85
Existing 5200 network
SMI
LAN
DCN/WAN
Private IPs
10.2.HG.shelf ID/24
1X 2X 2X
GNE 5000 NE1 5000 NE2
5000 NE3 5000 NE4

2X 2X
Private IPs
10.2.HG.shelf ID/24
Legend
Numbered Ethernet

Figure 1-86
6500 shelves interconnected
SMI
LAN
DCN/WAN
High OSPF cost

Private IPs
10.2.HG.shelf ID/24
unnumbered
1X 2X 2X In Out In COLAN-X
GNE 5000 NE1 5000 NE2 6500 NE1 6500 NE2
5000 NE3 5000 NE4 6500 NE3 6500 NE4
2X 2X In Out In
unnumbered
Private IPs
10.2.HG.shelf ID/24 High OSPF cost
Legend
Numbered Ethernet
Unnumbered Ethernet
6500 comms channel

The high-level steps for adding the 6500 shelves to an existing 5200 network
are outlined below:
• Commission the 6500s: shelf IP address, 5200 shelf OSPF circuits, GCC
links, GCC OSPF circuits, ILAN links and ILAN OSPF circuits
(daisy-chain).
• If connecting to the 5200, provision the 6500 ILAN-IN port with an IP
address following the 10.2.hubbing-group.shelfID scheme. Provision an
OSPF circuit according to existing configuration guidelines. Note that the
OSPF cost of this link should be set much higher than the cost of the
longest path in the network. A value of 10,000 or higher is suitable for
small to medium size networks.
• Connect the collocated 6500s together using the ILAN-OUT/IN ports in a
daisy-chain fashion. Use unnumbered IP addresses on these ILAN ports
and add OSPF circuits.
• At each interconnection site, connect the ILAN-IN port of one 6500 shelf
to the Ethernet hub in which the 5200 2X ports are connected.
Verify the connectivity to 6500 shelves

• Ping the 6500 shelf IP addresses from a PC or workstation in the DCN.
Verify that each shelf is reachable.
• From a command prompt on a PC, perform a trace route to each 6500
shelf and verify that the path is as expected.
Configure the 6500 GNE

In this phase of the migration, one 6500 shelf is configured to be a GNE. Site
Manager is used for this procedure.
ATTENTION
The 6500 GNE will be configured in this procedure but should not be
connected to the DCN at this time. It will be connected to the DCN once the
existing 5200 GNE is decommissioned as the GNE.
• Using Site Manager, login to the 6500 that is to become the GNE.
• Add a LAN interface for the COLAN-X port of the GNE. See Figure 1-87
on page 1-370. Under Comms setting management/interfaces:
— select LAN
— click Add
— choose the COLAN-X interface
— Configuration - Automatic
— click OK

ATTENTION
A “COLAN-X port failure” alarm will be raised and will stay active until the
port is connected to the DCN LAN in a later phase.
Figure 1-87
Add LAN parameters
• Add an IP interface for the COLAN-X port. The COLAN-X IP address

should be set to the same address as the SHELF IP, but the COLAN-X
mask should be set appropriately for the subnet it will connect to. For
example, if the COLAN-X will connect to a /24 DCN subnet, the mask will
be 255.255.255.0. See Figure 1-88 on page 1-371. Under Comms setting
management/interfaces:
— select IP
— click Add
— choose the COLAN-X interface
— IP address—must be set to same address as SHELF IP
— Netmask—must be set appropriately for the DCN subnet that the
COLAN-X will connect to. For example, if the DCN subnet is /24, the
mask will be 255.255.255.0.
— Non-routing mode—OFF
— ARP Proxy—ON
— click OK

Figure 1-88
Add IP parameters
• Add a static default route. See Figure 1-89 on page 1-372. Under Comms
setting management/Routers:
— select IP Static Route
— click Add
— IP subnet - 0.0.0.0
— Subnet mask - 0.0.0.0
— Next Hop - IP address of next-hop DCN router
— Cost - set to desired cost for link
— Circuit Id - COLAN-shelf#-X
— click OK

Figure 1-89
Add IP static route parameters
• Redistribute the default static route into OSPF. See Figure 1-90 on
page 1-373. Under Comms setting management/Routers:
— select OSPF Router
— under Redistribution, select Add
– Route redistribution - Static Distribution
– IP subnet - 0.0.0.0
– Subnet mask - 0.0.0.0
– Metric - select an appropriate metric. This is the OSPF cost that
will be associated with the redistributed static route. Note that the
route will be redistributed as a Type-1 external LSA (internal cost
is considered in routing calculation)
– Metric type - Internal
– click OK

Figure 1-90
Add OSPF redistribution parameters
• Configure the 6500 GNE as a standalone Proxy ARP GNE. See

Figure 1-91 on page 1-373. Under Comms setting
management/Interfaces:
— select GNE
— click Add
— Configuration - Standalone
— Access - ARP
— click OK
Figure 1-91
Add GNE parameters

• Add all 5200 and 6500 non-GNE shelf IP addresses to the Proxy ARP
table so that the GNE will proxy for these addresses. See Figure 1-92 on
page 1-374. Under Comms setting management/Interfaces:
— select Interface type: ARP Proxy
— click Add
— enter each shelf IP address as a single entry, or if the addresses are
contiguous, as a range. Do not enter any IP addresses that are not
contained within this 5200/6500 network.
— click OK
Figure 1-92
Add ARP proxy parameters
In the example network of Figure 1-86 on page 1-368, 6500-2 will become the
GNE and has the COLAN-X configured as per the above steps.
Remove the 5200 GNE
ATTENTION
If using a PC, you need to execute the ipconfig/release and ipconfig/renew
commands on the PC connected to the 2X port of 5200 while it is being
deprovisioned.
You must click the Renew DHCP Lease button in the System Preferences
on the Mac connected to the 2X port of 5200 while it is being deprovisioned.
In this phase, the existing 5200 GNE is reconfigured to be an RNE. Referring

to the example shown in Figure 1-84 on page 1-364, this procedure would be
performed on OM5000-1.

Figure 1-86 on page 1-368 shows the configuration once the 6500 shelves
are connected into the network. 6500-1 and 6500-3 are connected to the
same hub as the collocated 5200 shelves. 6500-1 and 6500-2 are
daisy-chained using unnumbered ILAN links, as are 6500-3 and 6500-4. The
6500-1 and 6500-3 ILAN-IN links are assigned 10.2.hubbing-group.shelfID IP
addresses; the cost of OSPF circuits on those links is set very high (10000).
The steps are:

• Using System Manager, select the GNE shelf in the navigation tree.
• Disable alarms on the 1X-Ethernet port, as this port will be disconnected.
From the Configuration/Communications tab, right-click on the GNE and
select Modify. See Figure 1-93 on page 1-376.
• Click Port Control
• For the Ethernet Port-1 Alarm menu, select Disabled
• Click OK

Figure 1-93
Port control settings
Optionally, the 1X-Ethernet port may be disabled in the Port Control Settings
window if craft access through this port is not required.
• From the Shelf Configuration window, edit the communication settings as
follows (refer to Figure 1-94 on page 1-377):
— uncheck Shelf is DCN Gateway
— set the Subnet Mask to 255.255.255.255
— click OK
— allow shelf to restart (non-service affecting restart)

Figure 1-94
Shelf configuration
Remove the cable from the GNE 1X-Ethernet port. Since this shelf is no
longer a GNE, the 1X port should not be connected to the DCN.

Connect the 6500 GNE to the DCN and verify connectivity

In this section, the 6500 GNE is connected to the DCN subnet and
connectivity to all NEs is verified.
• Connect the COLAN-X port of the 6500 GNE to the DCN subnet. Once the
cable is connected, verify that the link LED of the COLAN-X port is
illuminated.
• Ping all 6500 and 5200 shelf IP addresses from a PC or workstation in the
DCN. Verify that each shelf is reachable (see Note below).
• From a command prompt on a PC, perform a trace route to each 6500 and
5200 shelf to verify that the path is as expected.
ATTENTION
There can be some temporary connectivity issues from the DCN to some
shelves due to stale ARP cache entries in the DCN router. These ARP cache
entries will time-out automatically and the duration will depend on how the
router is configured. The router may have its ARP cache flushed manually if
necessary.

6500 and Optical Long Haul 1600G interworking

6500 network element supports interworking with Long Haul 1600G using
PBE functionality.
The PBE requires OSI communications between the head-end amp-site of the
LH1600G system and all 6500 shelves housing AM2-capable transmitters to
be adjusted.
Interworking between Optical Long Haul 1600G and 6500 is only required to
support single stretch span, that is, when the OSC is not available due to an
unrepeatered link. In this case, the OSI traffic between two Optical Long Haul
1600G network elements traverse the GCC channel. The OSI packets are not
IP encapsulated but are transmitted natively in a PPP packet.
Since IISIS is used as the internal routing protocol on 6500, the 6500 network
elements appear in the OSI routing table on the Optical Long Haul 1600G
network elements. The Optical Long Haul 1600G network elements appear in
the OSI routing table on the 6500 network elements.
6500 cannot be a head end (or GNE) for an Optical Long Haul 1600G. The
Optical Long Haul 1600G must have its own DCN drop through an OPC.
The Broadband network element and Long Haul network element can be
connected together using an Ethernet cable (LH MI Ethernet port to
Broadband ILAN port). This will provide a method such that the Broadband
network element TID is displayed in the Long Haul user interface.
Figure 1-95 on page 1-379 shows the typical interworking between the 6500
and the Optical Long Haul 1600G.
Figure 1-95
6500 and Optical Long Haul 1600G interworking
ISIS/OSI/Ethernet ISIS/OSI/Ethernet
ILAN MI MI ILAN
OSC - ISIS/OSI/LAPD
6500 1600G 1600G 6500
GCC0/1 - ilSIS/OSI/PPP
Figure 1-96 on page 1-380 and Figure 1-97 on page 1-381 show the TIDc
Configuration without Private-IP and PBE where any GNE configuration can
be used except Private-IP.

In Figure 1-96 on page 1-380, LH1600G network element is connected to

6500 network element via ILAN/MI ports. Each ILAN port requires a public
DCN IP address to be used with PBE.
The ILAN interface must be provisioned to have both OSPF and IISIS
protocols running on them. OSPF is required for TIDc functionality and IISIS
is required for PBE server functionality. The ILAN interface must be numbered
for this application.
In Figure 1-96 on page 1-380 any GNE configuration can be used as long as
it is not a Private-IP.
Figure 1-96
TIDc configuration without Private-IP and PBE
DCN
Each member shelf

has a public SHELF IP
COLAN-X
Primary shelf
with public
SHELF IP
OSPF&iISIS OSPF&iISIS
ILAN ILAN
OSPF&iISIS MI OSPF&iISIS
LH LH MI card acts
as a HUB
Legend
ILAN IP address, must be numbered public IP
(DCN address)

6500 network elements via COLAN ports. ILAN ports do not require Public IP
addresses as in configuration in Figure 1-96 on page 1-380.
LH1600G can be connected to up to three 6500 shelves (total number of MI

ports on LH). You may use an external hub/switch to connect to more network
elements.

Figure 1-97
TIDc configuration without Private-IP and PBE
DCN
Each member shelf

COLAN-X
Primary shelf
with public
SHELF IP
OSPF OSPF
COLAN-A OSPF COLAN-A COLAN-A
iISIS
MI MI
LH LH MI card acts
as a HUB
Legend
ILAN IP address, maybe be un-numbered
(0.0.0.0) or numbered public (DCN address)

6500 network elements via ILAN/MI ports. ILAN ports must be numbered
Private-IPs. This option does not require additional DCN IP addresses.
The ILAN interface must be provisioned to have both OSPF and IISIS
protocols running on them. OSPF is required for TIDc functionality and IISIS
is required for PBE server functionality. The ILAN interface must be numbered
for this application.
In Figure 1-98 on page 1-382 any GNE configuration can be used as long as
it is not a Private-IP.

Figure 1-98
TIDc configuration with Private-IP and PBE
DCN
Each member shelf

COLAN-X
Primary shelf
with public
SHELF IP
OSPF&iISIS OSPF&iISIS
ILAN ILAN
OSPF&iISIS MI OSPF&iISIS
LH LH MI card acts
as a HUB
Legend
ILAN IP address, must be private
(non DCN)

Dial-up connectivity
The 6500 also supports connectivity to the 6500 network element using
dial-up. Dial-up access allows for remote access to the 6500 network using an
analog line. Dial-up access is also required in order to receive proper
assistance from Ciena support teams. Dial-up access is only available to
access the local network element, you cannot directly reach other network
elements on the DCN from the RS-232 port. You can reach remote network
elements using the nested Telnets functionality available from the command
line interface (CLI), which is accessible when breaking out from a TL-1
session.
You can switch between TL-1 and the 6500 CLI by typing Ctrl+B when
connected using the serial port.
If you are telneting into a shelf and need to toggle between the TL-1 and CLI
on that session, you have to Telnet into the CLI ports first, then Telnet into the
other sessions.
This method requires an externally callable telephone line and an external

modem to connect to the DTE interface (DB9 male connector) located on the
access panel of the 6500 network element. The modem must be
Hayes-compatible (able to respond to AT command set) and there must be an
ability to locally provision the modem. To hook up the modem to the 6500
network element, an RS-232 cable is needed. The cable must be DB9 female
connector on the side connecting to the 6500 network element and to
whatever specification to connect to the modem.
Set the modem to assert CD “carrier detect” only when modem is connected.
(When carrier detect goes down due to phone call loss, serial sessions get
logged out immediately instead of waiting for the timeout).

Firewalls
The firewall is supported in both IPv4 and IPv6.
Table 1-66 on page 1-384 shows which ports must be passed through any
firewall between the management systems and the 6500 network.
Table 1-66
Port filtering ports
Port End point Initiated by Application Transport Description

protocol
20 FTP server FTP server FTP TCP FTP data connection (active FTP mode).
21 FTP server NE FTP TCP FTP control connection (active FTP
mode).
22 NE • OneControl SSH TCP Used on NE for SSH-based TL-1

• Site access.
Manager
22 SFTP NE SSH TCP Used on remote SFTP server for

server backup/restore, load delivery and PM
retrieval operations. The NE initiates
session from ports in the range 20004 to
20020.
23 NE • OneControl Telnet/TL-1 TCP Telnet port used for Telnet/TL-1 access.

• Site
Manager
49 TACACS+ NE TACACS+ TCP Default port used to access an external

server TACACS+ server. This port may be
changed from the default value.
80 NE External web HTTP TCP HTTP port used for web browser access
browser to NE. The following applications are
available:
• Site Manager web launch
• SLAT wizard
• MIB definitions
• Site Manager self description download
(as part of Site Manager discovery) for
releases other than Release 12.6
123 SNTP NE SNTP UDP SNTP port used for time-of-day
server synchronization.

Table 1-66
Port filtering ports (continued)

protocol
161 NE External SNMP UDP SNMP port used for accessing MIBs on
SNMP-based 6500. This port is disabled by default.
manager
162 SNMP trap NE SNMP UDP SNMP trap destination port.
receiver
443 NE External web HTTPS TCP Secure HTTP port used for secure web
browser browser access to NE.
514 Syslog NE Syslog UDP Syslog server port.

Server
1812 RADIUS NE RADIUS UDP RADIUS server port used for RADIUS
server authentication.
1813 RADIUS NE RADIUS UDP RADIUS Accounting server port used for
Accounting RADIUS accounting.
Server
2122 OneControl OneControl FTP TCP Used to initiate the FTP data connection
from OneControl to the network element.
2123 OneControl NE FTP TCP Used to receive the FTP control

connection initiated from the network
element.
3083 NE Third-party Telnet/TL-1 TCP Standard Telnet/TL-1 port. Not used by

TL-1-based Site Manager or OneControl, but may be
manager used by third-party TL-1 based
management platform.
7071 License NE HTTPS TCP Secure HTTP port on external licensing

server server.
7072 License NE HTTP TCP HTTP port on external licensing server.

server
8443 NE REST client REST over TCP REST interface for 6500
HTTPS
8888 NE External Telnet TCP Used for remote debug access to 6500
Telnet client by Ciena.
8889 NE External Telnet TCP Used for remote debug access to 6500
Telnet client by Ciena.
10001 NE OneControl Telnet/TL-1 TCP Raw TL-1 (no echo) port used by the
OneControl to manage the 6500.

Table 1-66
Port filtering ports (continued)

protocol
10010 NE OneControl Telnet TCP Used by the OneControl to access OSI

Rlogin from the CLI.
10020 NE External Telnet TCP Used to access the CLI.

Telnet client
10161 NE external gRPC TCP Port used to access gRPC services on

gRPC client NE. Disabled by default.
20000 NE • OneControl SSH TCP SSH port used by OneControl or

• External third-party TL-1 based management
SSH client platform. This port does not provide echo
and is equivalent to the services on port
10001.
20001 NE OneControl SSH TCP SSH port used by OneControl to

manage the 6500.
20002 NE External SSH SSH TCP SSH port used to access CLI.
client
28888 NE External SSH SSH TCP SSH port used for remote debug access
client to 6500 by Ciena.
50000 NE NE Various TCP, UDP In Private-IP GNE mode, default source

to ports for all TCP and UDP flows from the
50511 network elements. This range is
configurable using the ED-NAT
command.
52050 NE External Various, TCP With the default NATBASEPORT value

to application depending and/or of 50000, ports in this range may be
54099 on customer UDP configured to provide access to
requirements applications on remote Network
Elements in a Private-IP network.
Specific port values and range of ports
depend on customer requirements and
whether NATBASEPORT was changed
from the default value. Refer to “Reverse
Port NAT” on page 1-87.

The following points must be considered when provisioning the firewalls:

• If the NE is not managed using SSH, ports 20, 21, and 10001 are
mandatory. If the NE is managed using SSH, ports 22, 20001 are
mandatory ports. Other ports are required if the associated
feature/management system is used.
• 6500 initiates sessions such as FTP (ports 20 and 21) and SFTP (ports
20004 to 20020 inclusive). A list of these sessions and the direction of the
messages is included in Table 1-66 on page 1-384. Ensure that opened
firewall ports are in the correct direction.
• Firewall on port 80 (HTTP server) or port 443 (Secure HTTP) is not
required if Site Manager will only be loaded to a local PC using the craft
port unless you need Management Information Base (MIBs) or 6500 SLAT
tools which require the HTTP or Secure HTTP access to NE.
• OAM data is only downloaded by Site Manager on login if it is not already
available locally. The OAM data for a particular release is embedded within
Site Manager as part of the desktop installer for that release.
For more information on firewalls for OneControl, refer to the OneControl

Engineering Guide, 450-3201-010.

Data communication security features and considerations

The 6500 provides the following security features managed from Site
Manager:
• Provisionable port filtering
• GNE port filtering
• Craft reach-through security
• RADIUS enhancements
• TACACS+
• Debug port hardening
• IP access control
Provisionable port filtering

There are two independent port filtering components: egress filtering and
ingress filtering. Provisionable port filtering is supported on all shelf processor
types and on D-Series/S-Series shelves. Use of egress port filtering is not
recommended.
On T-Series shelves, only ingress port filtering is supported.
Ingress port filtering

Ingress port filtering is a per-NE filtering that applies to traffic being sent to a
given network element. It allows the administrator to block any open ports,
such as for applications that are not being used. Disabling a port makes it
appear that the associated services are not active from the COLAN, ILAN, or
Craft ports. Refer to “Firewalls” on page 1-384 for a list of applications and
associated ports.
See Table 2-13 on page 2-54/Table 3-9 on page 3-38 and Table 2-14 on
page 2-55/Table 3-10 on page 3-39 for TCP and UDP ports/ranges open by
default that can be blocked or unblocked. If you attempt to block a port or port
range which is not in the above lists, the command will be denied with an error
message.
When a user enters a block request for a specified interface, a new filtering
rule is created for this interface. Packets that arrive on this specified
port/interface are blocked. A port that is blocked can be unblocked by deleting
the associated block filter rule.
The ingress filter list can have a maximum of 100 entries.

For more information and related procedures on port filtering, refer to

Chapter 2, “Comms setting management procedures for D-Series and
S-Series” and Chapter 3, “Comms setting management procedures for
T-Series”.
GNE port filtering

The GNE port filtering feature can be used to block access to specific
destination TCP/UDP ports on the GNE COLAN-X and/or COLAN-A
interfaces, preventing access to those ports on the local GNE shelf as well as
any downstream shelves.
Up to 10 filters can be defined. Each filter specifies one TCP/UDP port, and
can be applied to COLAN-X and/or COLAN-A.
GNE filtering applies to shelf types equipped with the SPAP-2 w/2xOSC
(NTK555NA/NB) shelf processor or SP-2 shelf processor
(NTK555CA/NTK555EA/NTK555FA), or CTM.
In Site Manager, GNE filtering is provisioned through the Interfaces tab of the
Comms Setting Management application. Refer to “Editing the
communications settings” on page 2-9/“Editing the communications settings”
on page 3-7 and “GNE Port Filter parameters” on page 2-72/“GNE Port Filter
parameters” on page 3-52 for provisioning details.
Craft reach-through security

6500 supports the craft reach-through security feature. Users connected to
the NE through the Craft port cannot reach out to other NEs using the local
NE until they have authenticated from the local craft PC.
Refer to “Accessing the PKT/OTN cross-connect circuit pack from the Craft
port” on page 1-119 for further details on accessing the PKT/OTN
cross-connect circuit pack SAOS-based CLI from the Craft port.

RADIUS enhancements
6500 supports the following enhancements to the 6500 RADIUS client and
gateway:
• RADIUS Proxy server (Authentication and Accounting) provisioning can
be performed on member shelves of a consolidated node (TIDc) by using
the Shelf drop-down list in the Centralized Security Administration Site
Manager application. For related procedures, refer to the centralized
security administration procedures in the “User account management and
administration” chapter in Administration and Security, 323-1851-301.
• The RADIUS gateway and Centralized Security Administration (CSA)
mode provisioning dependencies are removed. This allows the gateway to
be enabled on the TIDc member shelf while disallowing direct login to the
member.
• The Centralized Security Administration Site Manager application
RADIUS provisioning support the Auto generate shared secret
parameter, which automatically generates a shared secret. For
provisioning steps, refer to the “Provisioning the primary or secondary
RADIUS authentication server” and “Provisioning the RADIUS proxy
server settings” procedures in Administration and Security, 323-1851-301.
The shared secret is derived from the IP address of the RADIUS server.
This allows the management system to automatically provision the
RADIUS proxy and remote NEs without requiring an explicit shared secret
to be provided by the user.
Note: Auto generate shared secret is only supported when the RADIUS
server or proxy is another 6500 NE. Third-party RADIUS servers are not
supported.
TACACS+
6500 supports TACACS+ for centralized authentication, authorization and
accounting (AAA). For more information on TACACS+, refer to the
“Centralized Security Administration (CSA)” section in Administration and
Security, 323-1851-301.
When using TACACS+, both GNE and RNE shelves communicate directly
with external TACACS+ servers regardless of GNE configuration (that is, both
DCN-routable IP addressing configurations and non-DCN-routable
('Private-IP') addressing configurations). This is somewhat different than
RADIUS where, in a Private-IP GNE configuration, RNEs communicate with
a RADIUS gateway application on the GNEs (GNEs communication with
external RADIUS servers).

Debug port hardening

The following enhancements are supported on the debug port:
• Security audit log generation for all access attempts on the debug port.
• Optional “Debug Port In Use” minor, nsa alarm notification when the
debug port is in use.
• A security log (SECU400) is generated with a different log event type to
distinguish debug port userid/password login from debug port
challenge-response login. It also indicates operation failure/success.
• Intrusion detection/handling is applied to logins on the debug port.
Intrusion blocking is not supported. Intrusion Attempt alarm is raised if the
number of invalid responses reaches the maximum (MXINV).
• Displaying of an active debug port session in the Site Manager
Security->Active Users application and with the RTRV-ACTIVE-USER
TL-1 command.
• Optional enforcement of customer controlled userid/password
authentication on the debug port in addition to the existing Ciena
controlled challenge-response authentication.
• Display of the existing configurable banner on the debug port.
• Debug Login Authentication is “optional” (Disabled by default)
• For SECU400 log, debug port userid/password login and debug port
challenge response login have:
— Same login event type if they are both valid
— Different login event type if userid/password login valid, but challenge
response is invalid

IP access control
The IP access control list (ACL) feature adds filtering to any ingress traffic on
a given physical interface. The filtering rules are used to determine whether
incoming DCN traffic is allowed or denied based upon a combination of IP
address and subnet provisioning. This functionality adds an additional layer of
security and lowers the potential of unauthorized network element access.
IP ACL is supported on the:

• COLAN-A, COLAN-X, ILAN-IN, and ILAN-OUT interfaces on the SP-2
circuit pack (but not in a dual shelf processor configuration for a 14-slot
shelf when the SP-2 in slot 16 is active)
• COLAN-X and ILAN-OUT interfaces on the integrated SP on the 2-slot
shelf
• COLAN-X and ILAN-OUT interfaces on the SPAP circuit pack
(NTK555LA)
• COLAN-X, COLAN-A, ILAN-IN, and ILAN-OUT interfaces on the SPAP-2
w/2xOSC circuit pack (NTK555NA/NTK555NB)
• ILAN-<shelf>-IN1, ILAN-<shelf>-IN2, ILAN-<shelf>-IN3,
ILAN-<shelf>-OUT1, ILAN-<shelf>-OUT2, and ILAN-<shelf>-OUT3 on
the T-Series shelf
6500 does not support IPv6 access control lists (ACL).
For more information on the IP access control feature, refer to Administration

and Security, 323-1851-301.

Encryption OTR key management communications (does not apply to

T-Series shelves)
This section describes supported data communications configurations,
guidelines, and considerations related to key management of the 4x10G OTR
w/Encryption 4xXFP/4xSFP+ circuit pack (NTK530QE). Keys are managed by
accessing an HTTPS server on each encryption card from a client web
browser. Access to the HTTPS server is supported in two modes, as outlined
below:
• Non-segregated—this is a Layer 3 solution for configurations where there
is no requirement to separate OAM communications from key
management communications, such as when a single enterprise is
responsible for managing the network and the encryption keys.
• Segregated—this is a Layer 2 solution for configurations where it is
necessary to separate OAM communications from key management
communications, such as when the enterprise that manages the network
is different than that which manages the keys.
These solutions are mutually exclusive at both the nodal level and at the
network level. Mixing the two solutions in the same network or the same shelf
is not supported. Furthermore, there is no support for in-service migration
from one configuration to the other.
Encryption OTR key management is not supported using IPv6.
Encryption and FIPS Security Policy Overview and Procedures,

323-1851-340, contains information and procedures related to the 6500
encryption application.
Non-segregated (Layer 3) solution

The non-segregated (L3) solution can be used in configurations where there
is no requirement to separate OAM communications from key management
communications. Keys are managed using HTTPS from a web browser client
on the customer PC which connects to the server on the encryption card
through an HTTPS proxy on the shelf processor (refer to Figure 1-99 on
page 1-394).
Encryption cards are accessed using the format:

https://<ip address>:<proxy port>, where ip address is the shelf IP address,
and proxy port is the proxy port for a specific encryption card. The port number
is derived using the formula: 6500 + slot number, as shown in Table 1-67 on
page 1-394.
A maximum of five concurrent HTTPS proxy sessions are supported per shelf.

The non-segregated solution is only supported in DCN-routable (“public”) IP

GNE configurations. Redundant NAT and Private-IP GNE are not supported.
Figure 1-99
Non-segregated (L3) solution for encryption card key management communications
Table 1-67
Port mappings for encryption card access in Non-segregated (L3) solution
Shelf type Slot number HTTPS proxy ports
2-slot 1, 2 6501 to 6502
• 7-slot 1 to 7 6501 to 6507

• 6500-7 packet-optical
14-slot 1 to 14 6501 to 6514

32-slot • 1 to 8 6501 to 6508
• 11 to 18 6511 to 6518
• 21 to 28 6521 to 6528
• 31 to 38 6531 to 6538
Segregated (Layer 2) solution

The segregated (L2) solution can be used in configurations where there is a
requirement to separate OAM communications from key management
communications. In this solution, a dedicated access panel LAN port
(COLAN-X, COLAN-A, ILAN-IN, or ILAN-OUT) is used to access encryption
cards on the head-end shelf and also, using dedicated GCC2 channels, to
encryption cards on remote shelves (refer to Figure 1-100 on page 1-395).

There is no shelf processor involvement on either the head-end or remote

shelves in this solution, as communications are forwarded at Layer 2. Each
encryption card requires a unique IP address.
Figure 1-100
Segregated (L2) solution for encryption card key management communications
GCC2 access to remote encryption cards in segregated solution

GCC2 is used to provide remote access to encryption cards. Neither GCC0
nor GCC1 are supported for this purpose. Access to the remote shelf is
through a single GCC2 hop, and each GCC2 link is dedicated to a single
encryption card on the remote shelf. The NTK530QE variant of the
4x10G OTR circuit pack supports four GCC2 channels. Refer to Figure 1-101
on page 1-396 to Figure 1-108 on page 1-399 for examples of supported
configurations using GCC2.
CAUTION
Risk of communication loss on GCC2 link
A loss of remote access to the 4x10G OTR encryption cards
can occur if GCC2 is used to provide remote access to the
4x10G OTR encryption cards, and the GCC2 is routed through
a 5400 network that uses GCC2 in any of the following ways:
• GCC2 squelching is used on any link
• GCC2/GCC12 is enabled for 5400 OSRP
• GCC2/GCC12 is enabled to provide IpOverGCC
communication channel(s)

Figure 1-101
GCC2 access to remote encryption cards
Figure 1-102
Two head-end shelves with a single GCC2 to two different encryption cards on a remote shelf

Figure 1-103
Single head-end shelf, single remote shelf, two pairs of encryption cards
Figure 1-104
Single head-end shelf to four remote shelves

Redundant access to remote encryption cards is achieved by using more than

one GCC2 link between two paired encryption cards (refer to Figure 1-105 on
page 1-398), or using two different head-end shelves and two unique GCC2
links to the same remote encryption card (refer to Figure 1-106 on
page 1-398). In the former case, switching between GCC links is done
automatically if a fault occurs on the other.
Figure 1-105
Two GCC2 links between head-end shelf encryption card and remote encryption card
Figure 1-106
Two head-end shelves providing redundant access to remote encryption card
Unsupported uses of GCC2

The following uses of GCC2 for remote access to encryption cards are not
supported:
• Two different encryption cards on a head-end shelf accessing the same
encryption card on a remote shelf (refer to Figure 1-107 on page 1-399).
• GCC2 between encryption cards on two different head-end shelves (refer
to Figure 1-108 on page 1-399).

Figure 1-107
Unsupported configuration—two encryption cards on head-end connected to same encryption
card on remote shelf
Figure 1-108
Unsupported configuration—GCC2 between two head-end shelves
Provisioning encryption card communications

Encryption card communications is disabled by default. The details for
enabling the feature depend on the mode (non-segregated or segregated),
and are outlined below. For more information, refer to the “Encryption
procedures” chapter in Encryption and FIPS Security Policy Overview and
Procedures, 323-1851-340.

Provisioning the non-segregated (L3) solution

To enable the non-segregated solution, the encryption access Mode is set to
Non-Segregated. This is done on each shelf containing the encryption cards,
whether GNE or RNE, since the solution is only supported in public IP
(DCN-routable) GNE configurations.
For further details, refer to the “Provisioning the Encryption Comms for
HTTPS Proxy Solution (Layer 3)” procedure in Encryption and FIPS Security
Policy Overview and Procedures, 323-1851-340.
Provisioning the segregated (L2) solution

For the segregated solution, the following provisioning steps are required:
• On head-end shelves:
— Set the encryption access Mode to Segregated. Select the LAN Port
(COLAN-X/COLAN-A/ILAN-IN/ILAN-OUT) that is to be dedicated for
encryption communications. Note that the L2 LAN parameters must
also be provisioned (Site Manager > Comms Setting Management >
Interfaces > LAN). For steps, refer to Procedure 2-2, “Editing the
communications settings”. This LAN port must not be used for
management communications. COLAN-A on the 6500 14-slot shelf
offers a reduced set of functionality versus COLAN-X; therefore,
COLAN-X is the preferred port for DCN connectivity.
— Assign an IP address, subnet mask, and gateway to each encryption
card on the head-end shelf. The gateway is the IP address of the
external DCN router.
— Provision dedicated GCC2 channels to access remote encryption
cards. The Network Domain is set to ENCRYP.
• On remote shelves:
— Set the encryption access Mode to Segregated. Set the LAN Port to
None (default value).
— Assign an IP address, subnet mask, and gateway to each encryption
card. The gateway is the IP address of the external DCN router.
— Provision dedicated GCC2 channels to provide access from the
head-end encryption cards. The Network Domain is set to ENCRYP.
For further details, refer to the “Provisioning the Encryption Comms for the
Layer 2 (Segregated) Solution” procedure Encryption and FIPS Security
Policy Overview and Procedures, 323-1851-340.

Provisioning rules
For the segregated solution, the following rules exist:
• The encryption card IP address can be entered only after the encryption
access mode is set to segregated.
• The encryption card IP address must be deleted before changing the
mode from segregated to either non-segregated or off.
• Setting the network domain to ENCRYP is only allowed if the carrier is set
to GCC2 and only on encryption OTR cards.
Guidelines and restrictions

GNE considerations
The segregated (L2) solution is supported in all supported 6500 GNE
configurations, since it is independent of the routing layer.
The non-segregated (L3) solution is supported in all GNE configurations,

except Private-IP and Redundant NAT configurations.
TIDc considerations
The non-segregated (L3) solution has no TIDc restrictions or limitations. Each
shelf has a DCN-routable IP address, allowing access from the external DCN
directly to the shelf processor on both primary and member shelves.
In the segregated solution, each shelf of the TIDc, both primary and members,
requires a dedicated LAN port for access to encryption cards on that shelf or
remote shelves connected to it via GCC2.

Troubleshooting
The following section provides some DCN troubleshooting information for
some common scenarios. For information and procedures for the DCN
troubleshooting tools, refer to Procedure 2-11, “Using the 6500 CLI ping and
trace commands” and Procedure 2-11, “Using the 6500 CLI ping and trace
commands”.
Telnet and ping successful to all DCC/GCC connected SHELF IP

addresses
If Telnet and ping are successful to all DCC/GCC connected SHELF IP
addresses, the DCN is correctly provisioned on all the 6500 network
elements.
Telnet and ping will fail if the SHELF IP address is a Private-IP address.
Telnet and ping successful to head-end COLAN and SHELF IP

addresses only
If Telnet and ping are successful to the head-end COLAN and SHELF IP
addresses only, there could be a DCN issue between the 6500 network
elements due to either a DCC/GCC or route distribution issue.
Telnet and ping will fail if the SHELF IP address is a Private-IP address.
Verify:
• the DCC/GCC (or ILAN) provisioning and use the IP Routing Table to
ensure that the SHELF IP addresses are learned over the IISIS or OSPF
• the route distribution to IISIS or OSPF on the head-end and attempt a ping
from 6500 to 6500 network element
Telnet and ping successful to head-end COLAN IP address only

If Telnet and ping are successful to the head-end COLAN IP address only,
there could be a DCN issue with the head-end distribution of SHELF IP
addresses to the customer DCN.
Verify the route distribution at the head-end 6500 network element.

Telnet and ping unsuccessful to head-end COLAN IP address

If Telnet and ping are unsuccessful to the head-end COLAN IP address, there
could be physical problems at the head-end.
Verify at the head-end network element that:

• the COLAN port has been enabled
• the correct Ethernet cable is used if the COLAN configuration is not
Automatic
• the maintenance interface card (MIC) is fully seated if COLAN-X is used

DCN engineering guidelines

The following are DCN engineering guidelines for 6500. For the following
guidelines, a gateway network element (GNE) subsystem is a complete DCN
network of NEs accessed through a GNE with COLAN access. The term GNE
subsystem applies to both the NEs accessed using DCC/GCC from the GNE,
and the GNE itself.
For the 6500 service metric scalability rules refer to Table 1-75 on page 1-417.
ATTENTION
For configurations that exceed the following guidelines, contact Ciena for
assistance.
• IISIS
— Maximum of 150 ISs and ESs nodes per OSI area.
— Maximum of 200 L1 LSPs per OSI area.
— Average of 10 adjacencies per L1 IS.
— Maximum of 80 adjacencies per L1 IS.
— Recommended IISIS circuit metrics:
– LAN: 4
– Line/MS DCC: 5
– Section/RS DCC: 6
– GCC0/GCC1: 5
– 40G GCC0/GCC1: 4
– 40G UOCLD GCC0/GCC1: 4
– 100G GCC0/GCC1: 4
— Maximum 160 routes redistributed into IISIS (80 static routes and 80
OSPF routes)
• OSPFv2
The guidelines in Table 1-68 on page 1-405 are not intended as design
goals, but rather as absolute maximums. Network designs should aim to
minimize OSPF load. Refer to “Best practices” on page 1-78 for guidance.

Table 1-68
OSPFv2 guidelines
OSPFv2 element Maximum
LSA maximums per Type (Note 1):

• Type-1 (defines maximum routers per area, Note 2) • 150
• Type-2 • 300
• Type-3 • 500
• Type-4 • 500
• Type-5 • 500
• Type-11 (Note 3 and Note 4) • 1600
Combined LSA maximum (all Types) 1800
Number of OSPF circuits 64
Number of OSPF adjacencies 80
Number of routes redistributed into OSPF 160 (80 static and 80 IISIS)
Note 1: Individual maximums per LSA type shown, but combined LSA maximum (all types) still applies.
In other words, (Type-1 + Type-2 + Type-3 + Type-4 + Type-5 + Type-11) must be less than or equal to
the combined LSA maximum).
Note 2: Since there is one Type-1 LSA per router, this defines the maximum number of routers per area.
Note 3: It is highly recommended that the number of Type-11 LSAs is minimized through appropriate
network design incorporating OSPF segmentation and SLDD and/or OOLFC Type-11 control
mechanisms.
Note 4: Maximum number of opaque LSAs for SP-2/CTM is 1600 (only supported if entire OSPF
network is SP-2/CTM). Maximum number of opaque LSAs for non-SP-2 is 1200.
• OSI
— Maximum of 150 OSI routes (NSAP) in the L1 routing table.
• IP
— The 6500 IP routing table supports 500 IP routes in total.
— Maximum of 90 hops from OneControl to 6500.
• Private-IP
— If the GNE is equipped with an SP-2 circuit pack (NTK555CAE5,
NTK555EAE5, and NTK555FAE5), a maximum of 12 MSPP RNE
shelves can subtend the GNE, or a maximum of 36 Photonic and/or
Broadband RNE shelves can subtend the GNE.
— Maximum of 512 reverse port NAT entries.
— If the GNE is a reverse port NAT, configure the map ports on the GNE
to be within the 52050 to 54099 range (if possible).

• TL1 Gateway
— The recommended maximum number of northbound management
sessions per 6500 TL1 Gateway is four (for example, from OneControl,
Site Manager, or other management platform).
— The maximum number of subtending shelves supported by a
Private-IP GNE is provided in the Private-IP engineering guidelines
above.
— The maximum number of TL1 Gateway sessions can be found using
the formula (maximum # of northbound sessions x maximum #
subtending shelves). For example, with four northbound sessions and
a maximum of 36 subtending shelves, the maximum number of TL1
Gateway sessions is 4 x 36 = 144.
— The TL1 Gateway sessions can be a mix of IP TL1 Gateway and OSI
TL1 Gateway.
— The maximum number of OSI devices managed through TL1 Gateway
is 24.
• Redundant ARP
— Maximum of 150 shelves subtending the redundant ARP GNEs.
— The last octet of each IP address must be unique.
• Physical (DCC/GCC/OSC)
— Maximum of two Line/MS DCCs per OCn/STMn or MXC circuit pack.
— Maximum of 80 DCCs per shelf (on a 32-slot shelf, the maximum is
128 DCCs).
— A maximum of 60 GCC channels are supported.
— Maximum of one GCC0 and one GCC1 per WT circuit pack.
— For the SuperMux NTK535EA/NTK535EB variant, maximum two line
DCCs, or, one line DCC and one of GCC0/GCC1 per SuperMux
(GFP-T and GFP-F variants) circuit pack.
— For the SuperMux NTK535FA variant, there are no limits. GCC0 and
GCC1 on OTM2 are supported simultaneously, 11 LDCC and 11
SDCC on OC-n/STM-n facilities are supported.
— Maximum of two dual-OSCs or four OSC channels, per shelf.
— Maximum of two Section/RS or Line/MS DCCs per
5G 16xOC-n/STM-n circuit pack (NTK512FAE5 and NTK513FAE5).
— Maximum of 16 Section/RS or Line/MS DCCs per
10G 16xOC-n/STM-n circuit pack (NTK512GAE5 and NTK513GAE5).
— Maximum of 16 DCC channels (eight Section/RS DCC and eight
Line/MS DCC) on the 8xOC-n/STM-n (NTK511AA) circuit pack.

DCN design bandwidth requirements

Introduction
When performing the bandwidth dimensioning for a DCN design it is important
to consider the following characteristics:
• Communication Interface Bandwidth: The bandwidth available on the
DCN Interface.
• NE Throughput: The bandwidth that a NE is capable of forwarding.
• Minimum Link Speed and Per-NE Bandwidth: The minimum link speed
required by a group of NEs and the average bandwidth allocated to a
Network Element when performing the DCN design.
It is also necessary to consider the network topology and the traffic being
routed through the various interfaces and Network Elements. It is important to
consider these under normal conditions as well as failure conditions. For
example in a dual Gateway NE (GNE) subsystem it is necessary to design the
network such that a single GNE can forward all traffic for the entire subsystem.
The main applications which generate traffic in the DCN are described below:
• OAM&P traffic: Operations, Administration, Maintenance & Provisioning
traffic flows are between the User (craft PC/Management System) and the
Network Element, typically via a GNE. Where TID consolidation (TIDc) is
used the following traffic flow must be additionally understood:
— TID consolidation (TIDc): With TIDc the OneControl forwards all
OAM&P traffic towards the TIDc primary. The TIDc primary forwards
the OAM&P traffic to the appropriate TIDc member shelf. Typically
TIDc traffic between the primary and member shelves will use local
Ethernet connectivity at the site; however, in failure conditions TIDc
traffic may use additional communication interfaces (Internal or
External) to maintain comms between member shelves.
• Photonic applications: For detailed information on Photonic concepts,
applications, and engineering rules supported for 6500, refer to 6500
Packet-Optical Platform Photonic Layer Guide, NTRN15DA. A summary
of the main traffic flows associated with Photonic applications are as
follows:
— Domain Optical Control (DOC): DOC traffic flows between Network
Elements. Typically DOC traffic will utilize the internal communication
interfaces (OSC, Ethernet (and GCC in Single Stretch Span
solutions)) however in some topologies it may be beneficial to use the
External DCN as a backup for DOC traffic.
DOC can delete or auto-delete channels that traverse a faulted span
as long as the topology remains available. This is the case for domains
that are upstream of the faulted span, downstream of the faulted span,
and for the domain that contains the faulted span. For example, If there

is fiber cut between node A and B, as long as there is a redundant

datacomm link between A and B, topology can still be built, and
channels can be deleted or auto-deleted.
Communication interface bandwidth
Table 1-69 on page 1-408 provides the bandwidth capabilities of the
communications interfaces on the 6500.
Table 1-69
Communication interface bandwidth
Communication interface Interface Estimated bandwidth available for OAM&P if

bandwidth Photonic applications transported over this
(kbit/s) interface (kbit/s)
Section/RS DCC BW 192 NA—avoid Photonic applications

Line/MS DCC BW 576 NA—avoid Photonic applications
GCC0/GCC1 (OTM1) 333 NA—avoid Photonic applications
GCC0/GCC1 (OTM2) 1300 300 (Note 1)
GCC0/GCC1 (OTM3) 3000 2300 (Note 1)
GCC0/GCC1 (OTM3 for 2000 1300 (Note 1)

40G UOCLD)
GCC0/GCC1 (OTM4) 4000 3300 (Note 1)

OSC 100000 40000
Ethernet (Full duplex) 10000/100000 40000 (Note 2)

Note 1: Photonic application traffic is typically routed over OSC and Ethernet interfaces. In Single Stretch
Span (SSS) solutions where the OSC may not be available, Photonic application traffic may be routed over
GCC channels. When Photonic application traffic is routed over a GCC it is important to minimize the DOC
and OAM&P traffic over the GCC through careful design of DOC domains and OSPF costs.
Note 2: 100Mbit/s full duplex recommended if Photonic applications (OPM, TIDc, DOC) using Ethernet
Interfaces.
6500 NE throughput
The 6500 supports hardware and software forwarding. It is important to
establish which forwarding mechanism is being used to determine which
throughput figure to use when performing the DCN bandwidth dimensioning.
Software forwarding is used as follows:

• OSI PDUs
• IP over GRE (forwarding IP over an OSI cloud for example). It is important
to apply the software forwarding guidelines to the nodes that actually
perform the tunneling - therefore the node performing the
encapsulation/de-encapsulation must be established for each direction.

• Network Address Translation (NAT) GNE - including redundant and

non-redundant options.
• Private-IP address mode GNE
Hardware forwarding is used in all other cases. This includes GNEs in the
following configurations:
• Proxy ARP
• Static routing
• IISIS routing
• OSPF routing
Table 1-70 on page 1-409 provides the NE throughput values for the 6500.
Table 1-70
6500 NE throughput
Forwarding Mechanism NE throughput

Hardware forwarding No Practical Limit (Note 1)
Software forwarding 844k bit/s (Note 2, Note 3)
Note 1: Typically the sum of the available Communication Interface bandwidth will
determine the maximum throughput of a 6500 NE when using Hardware forwarding.
Note 2: The 6500 software forwarding achieves approximately 550 packets per
second. The actual throughput depends on the packet size. The value stated has
been calculated from an average packet size of 192 bytes which is an expected
standard profile for most applications.
Note 3: If using Private-IP GNE mode, refer to the “Private-IP” “DCN engineering
guidelines” on page 1-404 for the maximum number of RNEs that can subtend the
GNE.
It is important to consider the NE throughput capabilities of all NEs in the

network. Typically GNEs have the highest NE throughput; however it is
necessary to consider all NEs. For example if a 6500 is the GNE for 61x0 NEs,
it is important to ensure that the 61x0 NEs throughput capabilities are not
exceeded. Refer to the 61x0 planning guide for NE throughput capabilities.
Minimum link speed and per-NE bandwidth

To allow for timely discovery/alignment, burst handling, and to avoid timeouts,
it is necessary to ensure that there is a minimum link speed to an NE. The
recommended minimum link speeds for OneControl managed NEs are
provided in Table 1-71 on page 1-410.

Table 1-71
Network element minimum link speeds
Network Element Minimum Link Speed
61x0 128 kbit/s
CPL 128 kbit/s
5100/5200 128 kbit/s
6500 200 kbit/s
The per-NE bandwidth provides an average bandwidth figure per-NE that can
be used to dimension the DCN. The per-NE bandwidth is dependent on the
NE type and the operational characteristics of the network. The following
operational characteristics of a network influence the per-NE bandwidth
figures:
• Craft operations and the number of users: The amount of provisioning
(changed facilities and changed cross connects per second).
• Status of Network: Number of alarms per second.
• OneControl: The number of OneControl servers that an NE is enrolled to,
PM collection, backup and restore.
• One-time Operations: Software downloads.
The above operational characteristics vary from network to network. To

provide engineering guidelines the Per-NE Bandwidth figures are provided in
three categories as follows:
• Minimum Bandwidth: These values should be used for the following
operating model:
— Stable network with minimal alarm changes per second.
— Minimal provisioning activity with a low level of changed facilities and
cross connects per second.
— Small number of craft users.
• Typical Bandwidth: These values should be used for the following
operational model:
— Typical networks with 0.5 alarm changes per second for the 61x0 and
three alarm changes per second for the 6500.
— Typical provisioning activity with 0.5 XC/facility changes per second for
the 61x0 and 3 XC/facility changes per second for the 6500.
— Typical number of craft users - assuming a craft session to NE ratio of
1:6.

— One software download per NE per day.

— Good network discovery/alignment times.
• Maximum Bandwidth: These values should be used for the following
operational model:
— Networks with three alarm changes per second for the 61x0 and five
alarm changes per second for the 6500.
— Maximum provisioning activity with 3 XC/facility changes per second
for the 61x0 and 5 XC/facility changes per second for the 6500.
— High number of craft users - assuming a craft session to NE ratio of
1:1.
— One SW download per NE per day.
— Optimum network discovery/alignment times.
For all scenarios in Table 1-72 on page 1-411 it is assumed that 15 minute PM
collection and bulk provisioning are not used with less than 5 NE backups
per-NE per day.
The average bandwidth required per-NE is provided for Single OneControl

and Dual OneControl deployments for each category described in Table 1-72
on page 1-411.
Table 1-72
Per-NE bandwidth requirements
Shelf Type Minimum Bandwidth Typical Bandwidth Maximum Bandwidth

(kbit/s) - non (kbit/s) (kbit/s)
OneControl
managed solutions Single Dual Single Dual
OneControl OneControl OneControl OneControl
6500 NE (Note 1) 29 59 95 137 197

Legacy OSI based 3 3 3 3 3
6110/6130 (Note 2) 12 11 17 76 112
Note 1: These figures assume a 6500 NE configuration of 6500 MSPP with LO/HO XC and Photonic
equipment. This 6500 NE type is has the highest bandwidth requirement. Subsequent releases will
provide a breakdown of the bandwidth requirements per 6500 NE configuration.
Note 2: Refer to the 61x0 planning guide for additional engineering guidelines which need to be
considered for 61x0 deployments such as NE throughput and hop count.

DCN dimensioning example: 6500 MSPP with 6130 (IISIS routing)

Figure 1-109 on page 1-412 provides an example network with a single 6500
MSPP GNE. All nodes in the network use IISIS routing. A failure is assumed
between GNE1 and NE4 to ensure the worst case failure scenario is
considered. The following DCN bandwidth calculations are applicable:
Figure 1-109
6500 MSPP with 6130 (IISIS routing)
DCN Fiber failure
00 00 5 * 6130
65 65
5 * 6130 Ring (iISIS)
Ring (iISIS)
GNE1 NE4
Line/MS DCC with iISIS routing
00 00
65 65
5 * 6130 NE2 NE3

Ring (iISIS) 5 * 6130
Ring (iISIS)
Legend
00
65 = 6500 MSPP L0/H0 XC
NE throughput
IP comms between the 6500 GNE and the other 6500 NEs will use hardware
forwarding. Each remote 6130 will auto tunnel IP packets towards the External
DCN therefore software forwarding must be considered for each 6130 NE.

Table 1-73
GNE throughput requirements
NE throughput Minimum Typical bandwidth Maximum bandwidth
bandwidth (kbit/s) (kbit/s)
(kbit/s) for
non-OneControl Single Dual Single Dual
managed OneControl OneControl OneControl OneControl
solutions
GNE1 hardware forwarding 116 236 380 548 788
GNE1 software forwarding 240 220 340 1520 2240
NE2 software forwarding 180 165 255 1140 1680

6130 throughput (Note) 48 44 68 304 448
Note: 6130 throughput assumes 6130 NEs are in a ring and the worst case fiber failure is present.
The GNE does not exceed its software forwarding capabilities in the minimum
and typical Bandwidth operational models. If the Maximum bandwidth model
must be applied to this network additional GNEs should be considered. It is
worth noting that the NE throughput must be considered at all NEs not just the
GNE.
Communications interface bandwidth

The highest bandwidth requirement is on the LINE/MS DCC link between
GNE1 and NE2. The total required for this link is as follows:
Table 1-74
Worst case Line/MS DCC bandwidth loading
NE Throughput Minimum Typical bandwidth (kbit/s) Maximum bandwidth

bandwidth (kbit/s)
(kbit/s)
non-OneControl Single Dual Single Dual
managed OneControl OneControl OneControl OneControl
solutions
MSDCC GNE1 - NE2 267 342 540 1551 2271

As can be seen from Table 1-74 on page 1-413 the operational models
resulting in minimum and typical bandwidth requirements do not exceed the
Line/MS DCC. If the operational model results in the maximum bandwidth
usage the Line/MS DCC bandwidth between GNE1 and NE2 may become
congested during busy periods, with the possibility of sub-optimal
performance under this worst case failure scenario.
A possible solution to ensure optimal performance is to add an extra GNE,

ideally at NE3 to protect against the worst case fiber failure.
• DSM support
— 6500 only network with direct IP access
– no limit on the number of DSMs in the GNE subsystem
– section/RS, line/MS, and GCC bandwidth (see “Physical
(DCC/GCC/OSC)” on page 1-406) should consider each 6500
network element with one to eight DSMs as the equivalent of two
6500 network elements and each 6500 network element with nine
to sixteen DSMs as the equivalent of three 6500 network elements
– a single network element can support a maximum of 16 DSMs.
— 6500 only network with NAT or Private-IP on GNE
– maximum of 80 DSMs in the GNE subsystem
– when considering DCN throughput (see “Physical
(DCC/GCC/OSC)” on page 1-406), each 6500 network element
with one to eight DSMs should be considered the equivalent of two
6500 network elements, each 6500 network element with nine to
16 DSMs should be considered the equivalent of three 6500
network elements. For example, if you have two network elements
with 16 DSMs and two network elements with eight DSMs, this is
equivalent to 10 network elements (2x3 + 2x2), which would allow
another two subtended 6500 network elements (from the 12 limit
for 6500 network elements with low-order cross-connects) if these
did not have DSMs connected.

• Telnet sessions
— When considering DCN engineering guidelines, a maximum of 18
Telnet sessions per network element should be used.
If both SSH and Telnet servers are enabled, the total maximum
number of SSH and Telnet sessions cannot exceed 18.
— All 6500 network elements with IP configured
No limit on the number of sessions per 6500 GNE subsystem except
for limit on the section/RS, line/MS, or GCC bandwidth (see “Physical
(DCC/GCC/OSC)” on page 1-406).
— All 6500 network elements with IP configured and using NAT
Maximum of 54 Telnet sessions with autonomous output (AO)
message reporting enabled for a GNE subsystem. This maximum can
be increased if OM 3000/OM 4000/6110 network elements are
substituted for the 6500 network elements (maximum of two
TL-1/CLUI sessions per OM 3000/OM 4000/6110 network element).
For example, a GNE subsystem with one gateway 6500 network
element, eleven subtending 6500 network elements, and nine
OM 3000/OM 4000/6500 network elements can have a maximum of
62 Telnet sessions (four Telnet sessions for each of the eleven 6500
network elements and two TL-1/CLUI sessions for each of the nine
OM 3000/OM 4000/6500 network elements).
— If more than four Telnet sessions per 6500 network element are
required, AO message reporting must be disabled for the additional
Telnet sessions. The additional Telnet sessions must be through local
connections on the network element or a COLAN connection and not
through a DCC/GCC or ILAN connection.
The OM 3000 and OM 4000 do not use Telnet (OM 3000 uses TL-1
sessions and OM 4000 uses CLUI sessions) except for the Telnet
sessions between the OM 3000 and the NP. The TL-1 and CLUI sessions
and the Telnet sessions used when GRE tunneling from the 6500 to the
OM 3000 NP should be used for calculating the maximum number of
Telnet sessions.
To inhibit and allow AO message reporting on 6500, use the TL-1
INH-MSG-ALL and ALW-MSG-ALL commands. The INH-MSG-ALL
command disables AO message reporting only for that Telnet session.
Each Site Manager session in 6500 opens a Telnet session (which must
be counted towards the maximum number of Telnet sessions). To inhibit
AO message reporting from Site Manager, clear the Auto Refresh check
box in the Active Alarms application and run the INH-MSG-ALL command
from the TL1 Command Builder application. To enable AO message
reporting from Site Manager again, run the INH-MSG-ALL command from
the TL1 Command Builder application and select the Auto Refresh check
box in the Active Alarms application if real-time monitoring of alarms is
required.

• Software release delivery

— 6500 network element with direct IP access: No limit on parallel
software delivery through the GNE except as limited by the
section/RS, line/MS, or GCC bandwidth (see “Physical
(DCC/GCC/OSC)” on page 1-406).
— Maximum of one software delivery at a time to a shelf through a
private-IP or NAT GNE. Note that consolidated TID sites may consist
of several shelves.
• Serial ports
— AO message reporting must be disabled on serial port connections.
• Cross-connects
— 6500 network element with direct IP access
– Supports network elements with fully provisioned cross-connects.
No direct COLAN access required.
— 6500 network element with NAT or Private-IP on GNE
– A 6500 network element with more than 5000 cross-connects
subtending from a GNE with NAT or Private-IP should be
considered the equivalent of two 6500 network elements when
considering DCN throughput (see “Physical (DCC/GCC/OSC)” on
page 1-406). For example, if all the subtended 6500 network
elements have more than 5000 low-order cross-connects, only six
subtended 6500 network elements are allowed from the 12 limit.
• VT1.5/VC12 alarm enabling/disabling
— If failure conditions are present, commands to enable or disable
VT1.5/VC11 and VT2/VC12 alarms should be performed on a single
STS1/VC4 granularity or smaller. There is an upper limit of 1344
enabled VT1.5/VC11 and VT2/VC12 alarms per interface circuit pack.
• Static routes
— A maximum of 80 static routes can be provisioned on a 6500 network
element.
Table 1-75 on page 1-417 summarizes the scalability rules for the 6500.

IPv6 engineering guidelines

The following guidelines are independent of any corresponding IPv4
engineering guidelines:
• Maximum of 700 IPv6 routes
• Maximum of 80 IPv6 static routes
• Maximum of 600 OSPFv3 routers per OSPFv3 area
• Maximum of 64 OSPFv3 circuits
• Maximum of 80 OSPFv3 adjacencies
• Maximum of 150 ND proxy entries
6500 service metrics

Table 1-75
6500 service metrics
Data communications channels Value Comments
Section/regenerator section (S-DCC, RS-DCC) 192 kbps
Line/Multiplex Section (L-DCC, MS-DCC) 576 kbps
Optical Service Channel (OSC) 576 kbps MOR, MOR Plus and 1600 amplifiers.
Optical Service Channel (OSC) 100 Mbps CPL, 6500: Ethernet over OC3/STM1
SONET/SDH.
Only supports OSPF.
General Communication Channel (GCC)

• OTM1 • 327 kbps
• OTM2 • 1.3 Mbps
• OTM3 • 3 Mbps
• OTM3 (40G UOCLD) • 2 Mbps
• OTM4 • 8 Mbps
• OTMC2 • 8 Mbps
SDCC and LDCC supported packet sizes 512 to 1492 For 6500, refer to “Lower layer DCC
(default 1304) implementation rules” on page 1-17.
Maximum number of line/MS DCCs per 2 Refer to “IISIS router implementation

OCn/STMn or MXC circuit pack rules” on page 1-45.
Maximum DCCs per network element 80/128 Refer to “Lower layer DCC
implementation rules” on page 1-17.
Maximum number of GCCs per network element 60 Refer to “Lower layer DCC

Table 1-75
6500 service metrics (continued)
Maximum number of GCC0 and one GCC1 per 1 Refer to “Lower layer DCC
WT circuit pack implementation rules” on page 1-17.
Maximum line DCCs per SuperMux circuit pack 2 No GCC. Refer to “Lower layer DCC
implementation rules” on page 1-17
Maximum number of line DCC and of 1 each One line DCC and one of
GCC0/GCC1 per SuperMux circuit pack GCC0/GCC1 per SuperMux circuit
pack. Refer to “Lower layer DCC
Maximum number of dual-OSCs per network 2 Refer to “Lower layer DCC

element implementation rules” on page 1-17.
Maximum number of OSCs per network element 4 Refer to “Lower layer DCC
NE throughput
NE Throughput software forwarding Refer to “6500 NE throughput” on

• packet size of 192 bytes • 844.8 kbps page 1-409.
• packet size of 256 bytes • 1126 kbps

• packet size of 448 bytes • 1971 kbps
IISIS
Maximum number of nodes in an area 150 Refer to “IISIS router implementation
rules” on page 1-45.
Maximum L1 LSP per area 200 Refer to “IISIS router implementation

Average number adjacencies per L1 10 Refer to “IISIS router implementation

Maximum number of adjacencies per L1 80 Refer to “IISIS router implementation
Maximum routes redistributed into IISIS 160 Refer to “IISIS router implementation
Maximum OSI routes (NSAP) in the L1 routing 150 Refer to “IISIS router implementation
table rules” on page 1-45.
OSPF
Maximum OSPF routers per OSPF area 150 Refer to “OSPFv2 router

Table 1-75
6500 service metrics (continued)
Maximum OSPF circuits are supported 64 Refer to “OSPF circuit

Maximum routes redistributed into OSPF 160 80 static routes and 80 IISIS routes.
Refer to “OSPFv2 router
Maximum IP routes 500
Maximum of hops from OneControl to 6500 90 To manage latency/delay between

the NE and OneControl. Refer to
“OSPFv2 router implementation
General IP NA
Maximum number of static routes supported 80
Maximum number of opaque LSAs for non-SP-2 1200 Refer to “DCN engineering
guidelines” on page 1-404.
Maximum of opaque LSAs for SP-2/CTM (only 1600 Refer to “DCN engineering
supported if entire OSPF network is SP-2/CTM) guidelines” on page 1-404.
Maximum number of LSAs (all types) • 1800 Refer to “DCN engineering

guidelines” on page 1-404.
GNE
Maximum number of remote NEs managed via 12 SP1

Private-IP

Migration from IPv4 to IPv6

Since IPv4 and IPv6 are implemented as separate stacks, migration of a
system from IPv4 to IPv6 generally involves these high-level steps:
• Access the system using IPv4.
• Upgrade system, if necessary, to a release supporting IPv6.
• Enable IPv6.
• Overlay IPv6 on top of the existing IPv4 configuration. This includes
assigning IP addresses, routing protocols, configuring GNE mode, etc.
• Verify provisioning using ping, traceroute, etc.
• Stop accessing the system using IPv4 (Site Manager, OneControl, etc.)
• Begin accessing the system using IPv6 addresses.
• If desired, and subject to the “Exclusions” on page 1-72, remove IPv4
provisioning.
If completely removing IPv4 provisioning, it is important not to delete the
shelf IPv4 address until all unnumbered interfaces are deleted, since
unnumbered interfaces 'borrow' the shelf IP address. The recommended
de-provisioning steps are:
— ensure auto-provisioning of IPv4 OSPF/IISIS on OSC and GCC is
disabled
— delete OSPFv2 router, OSPFv2 circuits and OSPF redistribution
entries
— delete IISIS router, IISIS circuits and IISIS redistribution entries
— delete IPv4 static routes
— delete IPv4 unnumbered and numbered interfaces except shelf IP
interface
— delete IPv4 shelf IP interface
Support for migration from IPv4 to IPv6 is available from Ciena professional
services.

Preserving comms data when saving and restoring provisioning data

The preserve comms data option allows all the network element provisioning
data except comms-related information to be saved and restored from either
a local or remote server. This feature allows an operator to efficiently provision
network elements by cloning network element provisioned data without
impacting comms-related information on the cloned network elements.
If the new network elements have different configurations than the cloned
(golden) network element, the DCC/GCC comms may not be preserved on
the network elements. To completely preserve the DCC/GCC comms, the new
network elements must have the same equipment (same PECs) and facilities
as the golden network element for all slots and ports (and be functioning the
same).
If the new network elements do not have the same equipment (same PECs)
and facilities as the golden network element, the database is still cloned to the
new network element but circuit pack mismatch alarms are raised. After the
restore, you must manually correct mismatches by deleting/provisioning
equipment to clear mismatches and DCC/GCC failures. All provisioning data
is restored on matching equipment.
When saving and restoring the provisioning data, the user has the option of
selecting the Do not backup or restore the Comms settings and Shelf
Data option. When this option is selected, the comms-related information is
not saved or restored. The Do not backup or restore the Comms settings
and Shelf Data option must be used in pairs, both the save and restore
operation must have the option selected or deselected otherwise the restore
operation fails.
To use this feature to clone network elements with the same provisioning data
except comms-related information:
• provision a network element with the required provisioning data and save
the provisioning data with the Do not backup or restore the Comms
settings and Shelf Data option selected to a chosen location (golden
database)
• provision the comms-related information on the new network elements
• restore the provisioning data from the golden database to the new network
elements with the Do not backup or restore the Comms settings and
Shelf Data option selected
For more information, refer to Administration and Security, 323-1851-301.

Appendix A
The following sections contain background information on:
• “IP networks, addressing, and masks” on page 1-422
• “IP routing protocols” on page 1-426
• “Subnetting and supernetting - IP addressing examples” on page 1-438
IP networks, addressing, and masks

This section briefly explains the concepts of IP (Internet Protocol, version 4)
addressing and uses examples from DCN to illustrate.
• Every interface within an IP system must have a unique IP address (four
bytes expressed in decimal and separated by dots [for example,
192.168.12.43]). For more information on this notation, see “Dotted
decimal notation for IPv4 addresses” on page 1-423.
• The IP addresses available for the system are divided into networks and
further subdivided into subnetworks.
• Devices must be grouped together such that they are directly connected
only to other devices with IP addresses conforming to the same
subnetwork addresses.
• There are two groups of networks: public and private networks.
— Public networks are those networks which can be connected to the
Internet; therefore they are accessible from any device outside that
network, as long as this device is also connected to the Internet.
— Private networks are isolated from the outside world; therefore they
cannot be connected to the Internet, and as such they are not
accessible by any device that does not belong to the same network.
Well-defined ranges of addresses are reserved for private networks.
– One of the address ranges available for private networks is
192.168.x.y (x = 0 to 255, y = 0 to 255, which is the decimal
representation of an 8-bit binary number); “x” is the part of the IP
address which is available for the network address. For example,
192.168.1.0, 192.168.2.0, and 192.168.3.0 are three different
network addresses. Every device or interface connected to
network 192.168.1.0 must have an IP address that is 192.168.1.y,
where “y” is the part of the IP address which is available for both
the subnetworks and the host ID (identifier).
Note: IP addresses in the 192.168.0.0/24 subnet are not allowed on
6500.
• The subnetwork mask identifies the number of bits allocated to the host ID
and the number allocated to the subnetwork.

• When subnetting a network, two addresses are not available: those

identified by all ones (used as a broadcast address) and all zeros
(reserved by convention as it is used to identify the network).
• As for subnets, host addresses of all ones (broadcast) and all zeros (by
convention) are not available.
• The network designer must decide how many bits define the subnetwork
and how many define the host ID, according to the actual and possible
future network architecture.
It is important to note that the original distinction of addresses between

classes A, B, and C did not allow the network designer to vary the length of
the subnetwork mask after an IP address was assigned. In fact, classes A, B,
and C defined a rigid scheme for assigning the number of bits which identify
the networks, and those which identify the host ID, regardless of the network
designer needs. For its intrinsic limits, the notation for classes A, B, and C is
no longer used.
The next section shows the bit significance of the dotted decimal notation.
Dotted decimal notation for IPv4 addresses

An IPv4 address is 32 bits long. To aid memory of this string of digits, the
address is split into 4 groups of 8 bits each. These are represented by a
decimal number between 0 and 255 for ease of display. The decimal number
has no other significance.
The decimal number represented by the eight bits can be determined by

looking up the decimal value of each bit and then simply adding them up:
• 00000001 is represented by 1

Example: 10010001
• Total 145
An IP address contains a 32-bit address field and a 32-bit subnet mask. The
mask defines which part of the address is a network address and which is a
device address. The mask thus allows a router to decide whether the address
of the packet is destined for one of the subnets to which it is connected.
For example, an address of 47.9.64.172 has a mask of 255.255.240.0. An

AND function is performed on the mask and the address:
Address of packet is:
00101111.00001001.01000000.10101100
Mask is:
11111111.11111111.11110000.00000000
This means that the network part of the address is:
00101111.00001001.01000000.00000000
The device part of the address is:
00000000.00000000.00000000.10101100
occupying the last 12 bits.
CIDR (Classless Inter-Domain Routing) addresses represent masks in a

different way. A CIDR address is defined by a starting address and a mask
which defines the size of the address allocation.

For example, an allocation of addresses in the range 196.0.16.0 to

196.0.31.255 can be represented by:
196.0.16.0/20
where the 20 is a mask of 20 contiguous 1 bits.
Start address is:
11000100.00000000.00010000.00000000
End address is:
11000100.00000000.00011111.11111111
And the mask is:
11111111.11111111.11110000.00000000
The last 12 bits are available to the user to use as subnet address and
device address.
This notation is conventional for CIDR addresses. However, the method in

which an IP address is configured can vary according to the router where it is
performed.
Circuitless IP interface
A circuitless IP interface (SHELF IP interface on 6500) is a virtual interface
that exists in software only. The special property of this interface is that it
always exists and is therefore always included in the routing tables. Ethernet
and serial interfaces cease to exist if a connector falls out, or if the device at
the other end of the cable fails for any reason. The interface then shuts down
and is removed from the routing tables.
Some manufacturers use other terms for the circuitless IP interface (for
example, loopback interface).
Having an interface that always exists within a router is very useful for the
following reasons:
• If a tunnel is set up between two router interfaces and one of the interfaces
fails, the tunnel fails. However, when the tunnel is set up between two
circuitless IP interfaces, if the normal route fails, the tunnel is re-routed if
another route exists and does not fail.
• If during a Telnet session on a router the interface to which the session is
connected goes down, then the session is lost. Another connection using
the IP address of an alternative interface must be made. If Telnet sessions
are set up to connect to the router using the circuitless IP interface, then
loss of one interface is not a problem, providing the router has at least one
working IP interface.

• Other interfaces can be referenced to the circuitless IP interface. This is

known as an un-numbered interface. This applies only to point-to-point
interfaces (that is, not an Ethernet port). This reduces the number of IP
addresses needed.
It is more difficult to find faults in a network with an un-numbered link. The
use of un-numbered links is still permissible where sufficient IP addressing
space is not available.
• The circuitless IP interface identifies a router for OSPF (Open Shortest
Path First), tunneling, and management.
IP routing protocols
The primary function of IP, which resides at the network layer (3) of the OSI
(Open Systems Interconnect) model, is to receive data from the higher layer
protocols (TCP [Transmission Control Protocol] or UDP [User Datagram
Protocol] layers) on a source host, create a datagram and route the datagram
through a network to a destination host. Secondary functions of IP include
fragmentation and reassembly of the datagram, and packet lifetime control.
The most important IP routing protocols are explained in the following
sections.
ARP
ARP (Address Resolution Protocol) is used to map IP addresses to LAN
(Local Area Network) hardware addresses. When a host wishes to send a
packet to a host on another network, it sends the packet to its gateway for
forwarding. It can also do the same for a packet destined for a host within the
same network but it leads to excessively high traffic levels, especially if a large
number of hosts are on the LAN. Therefore, in order to reduce the traffic on a
LAN, a node uses ARP with another node when it determines that the
destination address is on a directly attached network. The node can
determine if the host is local by comparing the network portion of its own IP
address (including the subnet) with the target address.
Therefore, in order to avoid using the gateway, the originating host must
determine the destination host’s local data link layer address. It achieves this
by sending out an ARP request message containing its own IP address and
data link layer address, and the IP address of the destination host. This
message is sent using the gateway. The destination host then responds with
an ARP reply message containing its own data link layer address and uses the
originating host’s data link layer address as the destination address. Thus the
reply does not need to go using the gateway. The originating host and
destination host store the learned network and data link layer address pairing
in their ARP caches for future use, thus avoiding the use of the gateway
altogether. The rest of the hosts on the LAN build up similar caches, thus
reducing LAN traffic.

TARP
The TID address resolution protocol (TARP) is used by TL1-based network
elements to convert target identifiers (TID) into network service access points
(NSAP). An NSAP is used internally in a SONET/SDH communications
network as a means of addressing a network element.
TARP is a propagation protocol. TARP uses this propagation method with a

distributed database of learned TID/network entity title (NET) mappings.
TARP allows network elements to translate between TID and NET by
automatically exchanging mapping information with other TL1-based network
elements without the need for crafts person intervention. No additional
address provisioning is required at the network element to support TARP.
6500 supports both TARP transparency and TARP propagation which is

required for operations, administration, and maintenance (OAM)
interoperability between 6500 network elements and network elements that
are based on TL-1.
ATTENTION
TARP on the 6500 only supports upper-case TIDs. For example, TARP would
interpret OTTAWA and Ottawa to be the same TID. If mixed-case TIDS are
provisioned, unexpected results will occur.
Proxy ARP
Proxy ARP allows a gateway network element to respond to an ARP request
from a locally attached host or end station for a remote destination. It does so
by sending an ARP response back to the local host with its own MAC address
of the network element interface for the subnet on which the ARP request was
received. The reply is generated only if the network element has an active
route to the destination.
OSPF
OSPF (Open Shortest Path First) is an open protocol, as defined in Request
For Comments (RFC) 2328. It is based on the Dijkstra’s “Shortest Path First”
algorithm, which is a link state routing mechanism.
In an OSPF network, each router maintains a link-state database that

describes the topology of the autonomous system (AS). The database
contains the local state for each router in the AS, including the router’s usable
interfaces and reachable neighbors. Each router periodically checks for
changes in its local state and shares any changes detected by flooding
link-state advertisements (LSAs) throughout the AS. Routers synchronize
their topological databases based on the sharing of information from LSAs.

From the topological database, each router constructs a shortest-path tree,

with itself as the root. The shortest-path tree gives the optimal route to each
destination in the AS. Routing information from outside the AS appears on the
tree as leaves. OSPF routes IP traffic based solely on the destination IP
address and subnet mask contained in the IP packet header.
OSPF is designed specifically for use on larger networks, providing several

features to reduce the amount of traffic and processing overhead associated
with the routing protocol. Amongst these features are the ability to segment a
large network into a number of areas, and route summarization, a technique
which greatly reduces the volume of route advertisement traffic where the
addressing scheme is hierarchical.
The manner in which a network is segmented into areas is governed by strict

rules. There is a core area—known as the backbone area—which is area
0.0.0.0, sometimes referred to as area 0. All other areas are connected
directly to the backbone area. See Figure 1-110 on page 1-432.
The topology of each OSPF area is invisible to entities outside the area. This
area partitioning system speeds up routing, because all packets with
destinations within an area are contained within that area; packets destined
for another area are sent to the backbone area for redirection.
A router (boundary router) must always be used as the interface between the
two networks. There can be more than one router performing this role.
The rules for area use within OSPF networks contrast with the way areas are
implemented in OSI in the following ways:
• There is no requirement for a backbone area within OSI.
• The border between OSI areas is between routers (that is, a OSI router
can only reside in one area), whereas the border between OSPF areas
runs through a router (that is, an OSPF router can be in more than one
area).

Interfacing with other Autonomous Systems

OSPF can redistribute routes learned from other routing protocols, such as
IISIS, or static routes into the OSPF autonomous system (AS) to provide
visibility of destinations in other ASes. An OSPF router that redistributes
routes from another AS is called an Autonomous System Boundary Router
(ASBR).
Routes are redistributed into OSPF using Type-5 External LSAs with either a
Type-1 or Type-2 external metric. Type-1 external metrics consider the units of
the external AS to be comparable to those of the OSPF AS and therefore
routing calculations include both the internal and external metrics. Type-2
external metrics are considered an order of magnitude greater than the
internal metrics and therefore only the external metrics are used in routing
calculations (internal metrics may, however, be used to break ties).
For more information related to ASBR settings, refer to “OSPF Router ASBR
setting” on page 1-433. For information on when ASBR functionality is
required in 6500 configurations, refer to “6500 configurations requiring ASBR
set to ON” on page 1-434. For more information on route redistribution and
summarization, refer to “IPv4 route redistribution and summarization” on
page 1-98.
Supported OSPF version

Ciena supports OSPFv2 (RFC 2328) with the following features:
• OSPF version 2 Management Information Base (RFC 1850)
• The Link State Database (RFC 2178)
• The OSPF Opaque LSA Option (RFC 2370)
The “OSPF NSSA Option (RFC 1587)” and “OSPF Database Overflow (RFC
1765)” are not supported for 6500.
RFC 5250 is not supported for 6500. In particular, section 5, which deals with
inter-area considerations, is not followed. 6500 originates Type-11 opaque
LSAs but may have the ASBR parameter associated with the OSPF router
instance set to OFF (default). Refer to “OSPF Router ASBR setting” on
page 1-433, “Opaque LSAs” on page 1-130, and “Database Replication
Service (DBRS) (D-Series/S-Series shelf IPv4 only)” on page 1-132 for more
information.
Implementing OSPF in a network

This section covers issues that the implementer of an OSPF network must be
aware of.

Terms
Some terms associated with OSPF are:
• Costs: Routes have a cost associated with them. The higher the cost the
less favorable the route.
• Policy filters: This parameter only applies when an OSPF network uses
external routes. An announce filter acts on the outward advertisements
form the OSPF area and the accept filter acts on inward advertisements.
As the LSPs are modified by the filter and the resultant used to produce a
routing table, it follows that policy filters must be applied to all routers in
the OSPF network and not just to the boundary router.
• Link state: is the status of a link between two routers.
• Cost of a link: is computed from bandwidth, real cost, availability,
reliability and other link metrics.
• OSPF area: is a collection of connected routers which exchange link state
updates.
• Adjacencies database: lists all a router’s neighbors.
• Link State Database: is a list of link states from all other routers in the
OSPF area. All routers have identical link state databases.
• OSPF routing table: is produced from the OSPF link state database.
• Routing table (forwarding table): The best routes are chosen from all
protocol routing tables. Note that each router has a different routing table.
• Backbone area: Area to which all other OSPF areas are connected. It is
referred to as area 0.0.0.0 or area 0.
• Standard area: Area which is not the backbone area but which receives
all link state updates from external networks.
• Stub areas: These are areas which can have more than one interface, but
by definition do not carry transit data and do not receive link state updates
from external networks. All routers in a stub area must be set to be stub
routers. How this is implemented varies between router manufacturers.
• Totally stubby areas: Stub areas which do not receive summary LSAs.
• NSSA (Not So Stubby Areas): Stub areas which receive certain link state
updates from external networks (this feature is not supported because of
its incompatibility with opaque LSAs).
• Router ID: This is the number by which each router is known to OSPF. On
a Bay router, the default is the IP address of the first configured interface.
On Cisco, the default is the highest configured IP address. On both routers
it must be manually configured to be the same as the circuitless
IP/loopback address.
• Border router: A router which is in the backbone area and one or more
other OSPF areas.

• Boundary router (or ASBR—Autonomous System Boundary Router):

A router which is the gateway between an OSPF network and another
network which uses a separate routing mechanism, including static
routes. A router advertises itself as an ASBR using the E-bit in the router
LSA that it generates. Area border routers (ABR) in the network generate
Type-4 summary LSAs to advertise reachability information for the
ASBRs. Refer to “OSPF Router ASBR setting” on page 1-433.
• Designated router: Link state routing protocols have an inherent problem
when a number of routers exist on the same LAN. The solution is for a
router to be elected as a proxy for all the routers on the LAN. This is known
as a designated router (DR). The DR creates a dummy routing entity with
which all routers on the LAN form an adjacency. There are no other
adjacencies formed on the LAN. Thus, routers on a LAN will have only one
link on the LAN, rather than one for each of the other routers on the LAN.
This means that the number of links on a LAN with n routers is reduced
from n * (n - 1) to n * 2:
— A router with a priority of 0 never becomes DR.
— If a router with a higher priority connects to the network there is no
reelection.
— Changing router priorities does not cause a reelection.
— Changing router IDs does not cause a reelection.
• OSPF multicasts. Packets sent out with 224.0.0.5 are sent to all OSPF
routers. Packets sent out with 224.0.0.6 are sent to all OSPF designated
routers.
Topology considerations
An OSPF network has to be planned out in areas to take full advantage of the
protocol. With OSPF packets destined for an area outside the current area are
sent to area 0. Thus it can be inferred that all areas must have a connection
to area 0. There can be more than one connection between an area and area
0 but there must be no inter-area connections. It can be concluded that OSPF
networks are tree structures which lend themselves to hierarchical addressing
schemes using variable length subnet masks.
OSPF places demands upon a routing processor. It is recommended that no

more than 150 OSPF routers be placed within an OSPF area.
The designated router on a LAN in a network running OSPF has a very high
processor utilization. It can be that some routers are unsuitable for this role
and so must be allocated a priority of 0.
Wherever possible the DCN network must be fitted into one area (area 0). This
gives the benefit of OSPF speed and versatility without the restrictions on
topology.

Figure 1-110
OSPF areas
Area 1
Area 2
Area 0
(Backbone)
Area 3
Area 4
Basic OSPF configuration steps for each interface are:

1 enable OSPF
2 define an OSPF area
3 define the interface type
4 define the interface metrics
Other parameters may need to be changed.
Advantages of OSPF
OSPF is link state technology as opposed to the distance vector technology
and OSPF addresses the requirements of large scalable networks. Issues
addressed by OSPF are:
• Speed of convergence: With OSPF convergence is quicker because
routing changes are flooded throughout the network and new routing
tables computed in parallel.
• Variable length subnet masks: OSPF supports variable subnet masking
and advertises varying levels of subnets.
• Route summarization: OSPF supports route summarization which is the
consolidation of multiple routes into one single advertisement. It requires
a hierarchical network but has the advantage of confining topology
changes to within an area and so significantly reduces the workload on
routers in other areas.

Figure 1-111
Route summarization
• Supernetting: Supernetting comes from the introduction of CIDR.

Address space is allocated without class as a contiguous number of class
C addresses. For example, an allocation of addresses in the range
196.0.16.0 to 196.0.31.255 could be represented by 196.0.16/20. Such an
entry in a routing table is referred to as a supernet. Subnetting is used to
achieve route summarization and cannot be used with routing protocols
such as RIP which categorize IP addresses by class.
• Network reachability: There is no path limit with OSPF.
• Bandwidth considerations: OSPF just sends out link state updates
when they occur, with a maximum interval of 30 minutes.
• Route selection: OSPF determines a best route using the concept of
cost. Each interface configured with OSPF has a metric parameter, whose
value has been derived from the formula 108/interface speed (however, it
is at the discretion of the engineer to change it, if required—for example,
when the link is busy). According to the formula, some values are:
— Ethernet 100BaseTX: 1
— Ethernet 10BaseT: 10
— Serial at 2 Mbit/s: 48
— Serial at 64 kbit/s: 1562
OSPF Router ASBR setting

An OSPF autonomous system boundary router (ASBR) is a router that
imports routing information learned from other routing protocols into OSPF. A
router advertises itself as an ASBR using the E-bit in the router LSA that it
generates. Area border routers (ABR) in the network generate Type-4
summary LSAs to advertise reachability information for the ASBRs.

In the context of 6500, a network element can import static routes and IISIS
routes into OSPF, and does so if the following conditions are met:
• the ASBR parameter associated with the OSPF router instance is set to
ON. The default is OFF.
• one or more OSPF redistribution policies are defined and met.
Setting the ASBR parameter to ON results in the E-bit being set in the router
LSA regardless of whether routes are actually being imported into OSPF by
that router, and ABRs in the network would generate Type-4 summary LSAs
for that router. Therefore, to minimize the number of Type-4 LSAs and the
overall OSPF database size, it is recommended that the ASBR parameter be
set to ON only for NEs that are truly acting as ASBRs. For all other NEs, the
ASBR parameter should be set to OFF.
ATTENTION
In 6500 releases prior to Release 7.0, the default ASBR setting was ON and,
as a result, some NEs in existing networks may have the parameter enabled
unnecessarily. Ciena recommends that for larger networks the parameter be
disabled if not required. Contact Ciena technical support for information on
how this can be performed.
6500 configurations requiring ASBR set to ON

The following configurations require the OSPF router ASBR parameter to be
set to ON:
• GNEs which redistribute static route(s) into OSPF, including:
— Standalone static GNEs
— Standalone and redundant ARP GNEs
— Redundant NAT GNEs
— Standalone and redundant Private-IP GNEs
• If using DBRS, any nodes at a DBRS gateway site that are redistributing
static routes into OSPF (refer to DBRS section)
• Any node that redistributes routes from IISIS into OSPF. For example, a
GNE that uses OSPF on its COLAN connection to the DCN and IISIS
internally to support subtending OM 3000 NEs, with routes redistributed
between them, would require ASBR set to ON. Refer to “DCN example
18—management of OM 3500 through 6500” on page 1-272.

OSPF LSA generation

This section describes the circumstances in which the various types of OSPF
routing LSAs can be generated in an OSPF network. This information can be
used to determine the total number of LSAs generated in a given network and
whether engineering guidelines are being met, especially when DBRS is
used.
Router LSA
Each OSPF router in an OSPF area will generate a router LSA with intra area
flooding scope (flooded to all OSPF routers in the OSPF area). In DCN
solutions the total number of router LSAs in an OSPF area is the sum of the
External DCN routers in the OSPF area and the number of OSPF enabled
Network Elements in the OSPF area. The router LSA describes the router's
OSPF interfaces to an area and will increase in size with the number of OSPF
interfaces configured in the area.
ATTENTION
A router LSA generated from a 6500 with multiple GCC channels using
OSPF will be significantly larger than the LSA generated from an NE with
OSC/Ethernet OSPF interfaces. If large router LSAs will be present it may be
necessary to assign a value of 2 or 3 (depending on number of OSPF
interfaces) to each LSA when counting the total LSAs for engineering
purposes.
Network LSA
A Network LSA will be generated for each numbered Ethernet LAN in the
OSPF area and has intra area flooding scope.
AS-External LSA
Autonomous System Boundary Routers (ASBRs) advertise routes to
destinations which are outside the OSPF autonomous system (AS) using AS
External LSAs. One AS-External LSA will be generated for each IP route
advertised into the OSPF AS. AS-External LSAs are flooded throughout the
OSPF AS. It is important to consider how many AS-External LSAs are being
advertised into the OSPF autonomous system by ASBRs. A router distributing
either a static or default route into the OSPF autonomous system is an ASBR.
A router distributing a route learned from another routing protocol (BGP, IISIS,
EIGRP, RIP, or other OSPF AS) is an ASBR.
Network Summary LSAs and ASBR Summary LSAs

Area Border Routers (ABRs) advertise Network Summary and ASBR
Summary LSAs into the non-backbone OSPF areas. ABRs also advertise
Network Summary LSAs into the backbone OSPF area from the
non-backbone areas - this is an engineering consideration for the External
DCN Design and not discussed any further here.

To provide scalability ABRs are typically able to control the number of Network
Summary LSAs that are advertised into the non-backbone OSPF areas. It is
important to understand the number of Network Summary LSAs (if any) that
are advertised in by the ABRs.
Each ABR will advertise an ASBR Summary LSA into the non-backbone
OSPF areas for each ASBR in the OSPF AS. ABRs will not advertise an
ASBR Summary LSA into a non-backbone area for an ASBR which is part of
that non-backbone area (the router LSA received from the ASBR is used
instead).
Each ABR for an OSPF area will advertise Network Summary LSAs
(depending on route summarization and filtering configuration) and ASBR
Summary LSAs. Typically two ABRs are required as a minimum to provide
resilience, therefore each Network Summary LSA will be advertised into the
non-backbone area twice (once from each ABR). In some situations it is
necessary to have more than two ABRs; the impact on the number of LSAs in
the area should be considered in these scenarios.
By default, in 6500 R7.0 and above and CPL4.02 and above, ASBR
functionality is disabled when the OSPF router is created. Leaving the ASBR
parameter disabled on network elements, where ASBR functionality is not
required, will reduce the number of ASBR Summary LSAs generated by Area
Border Routers (ABRs) into the non-backbone OSPF area(s). Refer to “OSPF
Router ASBR setting” on page 1-433.
Route preference
All routing protocols are assigned a preference which allows the router to
select routes when different protocols each report a path to the same network.
It could be considered as a measure of availability. For 6500, the preferences
are as follows:
Most specific Route -> Local configured interfaces -> Static routes -> ISIS
(Internal) -> OSPF (Internal) -> OSPF (External, learned) -> IISIS (External,
learned).

Static and default routes

Static routes are manually configured on a router in contrast to routes
learned using a routing protocol. Static routes are permanent and remain in
the routing table even though an interface associated with the route goes
down. They are most commonly used for:
• Defining routes to use when two autonomous systems must exchange
routing information, rather than having entire routing tables exchanged.
Often subnetworks linked to an external DCN do not wish to receive
routing updates but require some facilities provided by the an external
DCN. The intermediate router on the border would advertise to the
external DCN that it had a route to the subnetwork.
• A network which has dial-on-demand links. Routing updates passing over
this link would keep the link up permanently. A static route ensures that the
link is only enabled when traffic data requires the link to reach its
destination.
Routers must be configured to listen to and redistribute static routes.
Default routes are a form of static routes in that they provide a catch-all for
destinations not contained in routing tables. In effect they provide a static
route to a large network rather than a specific IP address or subnetwork. In
the case of the subnetwork attached to an external DCN, the intermediate
router on the border has a default route to the external DCN advertised into
the subnetwork.
Figure 1-112 on page 1-437 provides an example of the way that static routes
and default routes are used.
Figure 1-112
Default and static routes

Subnetting and supernetting - IP addressing examples

When a network address is allocated, the network administrator may need to
subdivide the network into smaller subnetworks, based on the network
design. This is achieved by subnetting the network address, which consists in
subdividing the available network address range into smaller subnetwork
addresses ranges. To do so, the network administrator can allocate some of
the available bits for the subnetworks and some for the hosts.
A free form string of 20 alpha-numeric characters is used to easily locate the

equipment in a central office. Subnet is used to organize/select NEs in the
management system. You have to use a defined subnet name provisioned for
all the NEs within a subnet.
Supernetting is the opposite of subnetting, as it consists in aggregating

several networks together into a single address and relevant address mask.
Supernetting is used for route summarization (sometimes called route
aggregation), to allow collections of networks to be advertised with a single
routing entry. This reduces the burden of big routing tables to advertise a large
number of hosts.
The following example shows typical IP addressing for an example network

containing two routers. The example is used to illustrate the mechanism of
address allocation and subnetting. You must remember to allow for network
expansion when allocating IP addresses. Failure to do so can lead to
unnecessary and time-consuming address reallocation when modifications to
the network are made.
Although not shown in these examples, when address availability is limited, it

can be beneficial to begin network numbering from the most significant end of
the mask to allow the network/host boundary to be redefined at a later date
without allocating new addresses.
For example, if an allocation of IP addresses were given with a mask of

255.255.240.0, six bits could be used for host (h) and six bits for
subnetworks (s):
11111111.11111111.1111nnnn.nnhhhhhh
Host numbering would start 000001, 000010, 000011, ..., but network
numbering would start at 100000, 010000, 110000, ... .
Figure 1-113 on page 1-439 provides an example of two routers within a DCN.
Figure 1-113 on page 1-439 is only an example used to illustrate the general
principles of IP addressing allocation.

Figure 1-113
Example IP addressing for two routers within a DCN
Between them, the two routers shown in Figure 1-113 on page 1-439 have the
following interfaces:
• router 1, serial 0
• router 1, Ethernet 0
• router 1, circuitless IP
• router 2, Ethernet 0
• router 2, circuitless IP
Seven separate subnetworks are required. These are the networks connected
to R1 Ethernet 0, R1 circuitless IP, R2 Ethernet 0, and R2 circuitless IP, and
the three serial links. In order to provide seven subnetworks, three bits are
required.
If four bits are used for the subnetwork addresses, it provides provisioning for
up to 14 subnetworks; subnets 0000 and 1111 are reserved. This leaves four
bits that are used for the host ID.
However, not all the subnetworks must be the same size. Only two devices are
on a WAN point-to-point link, so a mask of 255.255.255.252 would suffice,
giving four combinations (host ID of 00 and 11 not allowed). SHELF IP
addresses are singularities and in general can have a mask of
255.255.255.255. In the following examples, one subnet has been further
subnetted for the serial links and another for the circuitless IP interfaces.

Circuitless IP interfaces on Ciena routers, running versions of Bay RS prior to

15.0 must use a subnet mask of 255.255.255.252.
Four bits gives 16 combinations. The host IDs of 0000 and 1111 are reserved.
The Ethernet port of the router usually has host ID 0001. Therefore 0010 to
1110 are available for up to 13 other devices.
The subnetwork mask is therefore:

• in binary
11111111 11111111 11111111 1111 0000
Subnetwork Host ID
• in decimal: 255.255.255.240
Subnetworks available with this mask are:

• 192.168.7.0 (reserved as the subnet field is all zeros)
• 192.168.7.16
• 192.168.7.32
• 192 168.7.192
• 192 168.7.208 (addresses in this range are used for serial interfaces with
a mask of 255.255.255.252, four addresses)
• 192 168.7.224 (addresses in this subnet range are used for circuitless IP
interfaces with a mask of 255.255.255.252, single address)
Therefore, the following addresses can be allocated for the Ethernet ports
(see Figure 1-114 on page 1-442):
• R1 Ethernet 0
— subnetwork 192.168.7.16 (192.168.7.0 is reserved)
— IP address 192.168.7.17, subnetwork mask 255.255.255.240
— host ID for other devices connected to R1 Ethernet 0: 192.168.7.18 to
192.168.7.30
• R2 Ethernet 0
— subnetwork 192.168.7.32
— host ID for other devices connected to R2 Ethernet 0: 192.168.7.34 to
192.168.7.46

Circuitless IP addresses are as follows:

• R1 circuitless IP
• R2 circuitless IP
— IP address 192.168.7.229 subnetwork mask 255.255.255.255
Serial interface addresses are as follows:

• serial link 1
— subnetwork 192.168.7.208
— IP address 192.168.7.209 and 192.168.7.210 (address used by the
router at the other end of link 1), subnetwork mask 255.255.255.252
• serial link 2
— subnetwork 192.168.7.212
— IP address 192.168.7.213 and 192.168.7.214, subnetwork mask
255.255.255.252
• serial link 3
— subnetwork 192.168.7.216
— IP address 192.168.7.217 and 192.168.7.218 (address used by the
router at the other end of link 3), subnetwork mask 255.255.255.252
Subnetworks 192.168.7.48, 192.168.7.64, up to 192.168.7.192 are available

for future expansion. Note that network address 192.168.7.0 is used in order
to leave network addresses 192.168.1.0 through 192.168.6.0 for the
management areas.

Figure 1-114
Allocation of IP addresses

2-1
Comms setting management

procedures for D-Series and S-Series 2-
Overview
This chapter provides procedures and parameter information related to the
6500 Packet-Optical Platform (6500) network data communications for
D-Series and S-Series shelves.
Note: You must refer to Chapter 1, “Data communications planning” for

an overview of 6500 communications planning before you start using the
procedures in this section.

DCN DCN

2-2 Comms setting management procedures for D-Series and S-Series
ID Identifier

Comms setting management procedures for D-Series and S-Series 2-3

SP Shelf processor
SSH Secure shell
WSC Wayside channel

Site Manager navigation

The following figure provides an overview of the Site Manager navigation
associated with communications management for the 6500. The figure shows
the path from the Site Manager menu bar.

Procedures and options for Comms Setting Management

Comms Setting Management window
Options Procedures
Opening window
Comms Setting Procedure 2-1, “Retrieving communications settings”

Management “Communications management parameters” on page 2-31
Edit command
Comms Setting “Editing the communications settings” on page 2-9
Management Procedure 2-3, “Editing the IP Version”
Procedure 2-4, “Editing the Site Level Data Distribution”
Procedure 2-5, “Migrating an MD5 key”
Add command
Comms Setting Procedure 2-6, “Adding a new entry in the communications settings”
Management
Delete command
Comms Setting Procedure 2-7, “Deleting an entry in the communications settings”

Management
Link, ping, and trace commands
Comms Setting Procedure 2-8, “Displaying link local information”

Management
Comms Setting Procedure 2-9, “Performing a ping using Site Manager”

Management
Comms Setting Procedure 2-10, “Performing a trace route using Site Manager”
Management
Command line Procedure 2-11, “Using the 6500 CLI ping and trace commands”
interface Note: You must use the command line interface and not the Site Manager to
perform this procedure.
Associated procedures
Some procedures require the user to perform procedures relating to other
topics. Before performing a procedure, if necessary ensure that the
information about the associated procedures is available.
All procedures assume that the user is logged in to the network element (see
Administration and Security, 323-1851-301).

Procedure 2-1
Retrieving communications settings
Use this procedure to retrieve the provisioned parameters associated with the
DCN. For more information on these parameters and how they apply to the
DCN, refer to Chapter 1, “Data communications planning”.
The Comms Setting Management parameters that display on Site Manager

for the Routers, Interfaces, and Services windows change depending on the
enabled IP version(s). If the NE is set to IPv6 = Enable and
IPv4 = Administratively Disabled, the Site Manager applications that are only
for IPv4 will be removed and/or grayed out.
The first time you login to Site Manager and access the Comms Setting
Management application, the IPv4 tab is displayed by default.
If an IPv6 tab is not displayed, that means the application is either

independent of the Internet protocol or it does not support IPv6 (for example,
NAT Configuration only has a single tab).
The IPv4/IPv6 context is held per NE basis from the Site Manager. For
example, if you switch to IPv6 for IP and then access the OSPF application,
the IPv6 context will be maintained. You can switch between IPv4 and IPv6 at
any time.
IPv4 and IPv6 tabs will be enabled/disabled according to the state of the NE.
Prerequisites
To perform this procedure, you must use an account with a level 1 UPC or
higher.

Procedure 2-1 (continued)

Step Action
1 Select the required network element in the navigation tree.

2 Select Comms Setting Management from the Configuration drop-down
menu to open the Comms Setting Management application. The Comms
Setting Management application contains three tabs which provide access
to associated parameters as follows:
• Routers
IISIS Circuit, IISIS Router, IP Static Route, Static NAT, Reverse Port NAT,
OSPF Circuit, OSPF Router, Port Filter, Upper Layer DCC, SLDD, Visible
NE Information, IISIS Routing Table, IP Routing Table, OSPF Neighbors
The IP Static Route, OSPF Circuit, OSPF Router, and IP Routing Table
windows contain two tabs: IPV4 and IPV6.
• Interfaces
ARP/ND Proxy, ARP/ND Table, DSM OAM Link, Encryption Access,
GNE, GNE Port Filter, GRE, IP, LAN, Lower Layer DCC/GCC, NDP, PPP,
Serial/RS232, TL1 Gateway Connections, USB
The ARP/ND Proxy, ARP/ND Table, GNE, and IP windows contain two
tabs: IPV4 and IPV6.
• Services
IP Version Configuration, Database Replication, DHCP, DHCP Relay
Agent, DHCP RA Interfaces, FTP, SSH/Telnet, NETCONF, HTTP/
HTTPS, TEST-PING, Zero Touch Provisioning, NAT Configuration,
Traceroute, LinkLocal
Note 1: The IP versions are enabled/disabled/edited using the options in

the IP Version Configuration service type (Services tab).
Note 2: The DHCP Relay Agent option has an DHCP RA Stats button
used to display the DHCP RA server statistics.
3 Select the required shelf from the Shelf drop-down list.
4 Select the appropriate comms type from the Router type, Interface type, or
Service type drop-down list.


Step Action
5 If the IPv4 tab and IPv6 tab are shown, select the desired tab.
Note 1: The Comms Setting Management parameters that display on Site
Manager for the Routers, Interfaces, and Services windows will change
depending on the enabled IP version(s). If the NE is set to IPv6 = Enable and
Note 2: The first time you login to Site Manager and access the Comms
Setting Management application, the IPv4 tab will be displayed by default.
Note 3: If an IPv6 tab is not displayed, that means the application is either
Note 4: The IPv4/IPv6 context is held per NE basis from the Site Manager.
For example, if you switch to IPv6 for IP and then access the OSPF
application, the IPv6 context will be maintained. You can switch between IPv4
and IPv6 at any time.
Note 5: IPv4 and IPv6 tabs will be enabled/disabled according to the state of
the NE.
The information about the selected comms is displayed. See
“Communications management parameters” on page 2-31 for information
about the options available. For tables, the number of items in the table is
displayed on the right above the table.
—end—

Procedure 2-2
Editing the communications settings
Use this procedure to edit the provisioned parameters associated with the
DCN. For more information on these parameters and how they apply to the
DCN, refer to Chapter 1, “Data communications planning”.
Prerequisites
higher.
Step Action

menu to open the Comms Setting Management application.
3 Select the required tab: Routers, Interfaces, or Services.
Service type drop-down list. See “Communications management
parameters” on page 2-31 for the options that can be edited.
Note 1: The Comms Setting Management parameters that display on Site
Manager for the Routers, Interfaces, and Services windows will change
depending on the enabled IP version(s). If the NE is set to IPv6 = Enable and
Note 2: The first time you login to Site Manager and access the Comms
Setting Management application, the IPv4 tab will be displayed by default.
Note 3: If an IPv6 tab is not displayed, that means the application is either
Note 4: The IPv4/IPv6 context is held per NE basis from the Site Manager.
For example, if you switch to IPv6 for IP and then access the OSPF
application, the IPv6 context will be maintained. You can switch between IPv4
and IPv6 at any time.
Note 5: IPv4 and IPv6 tabs will be enabled/disabled according to the state of
the NE.


Step Action
7 Select the required circuit/port/entry in the table.

8 Click Edit (or Enable/Disable for Interface type: DSM OAM Link application
and for Service type: Database Replication) to open the appropriate edit
dialog box.
9 Edit the parameters as required. See the following for editable parameters:
• Routers
— “OSPF Circuit parameters” on page 2-44
— “OSPF Router parameters” on page 2-50
Note: You can edit the static route for IPv6 only. You cannot edit it for
IPv4.
• Interfaces
— “ARP/ND Table parameters” on page 2-68
Note: You can edit ND Proxy list items, but you cannot edit Proxy ARP
list items.
— “DSM OAM Link parameters” on page 2-69
— Encryption Access, refer to Encryption and FIPS Security Policy
Overview and Procedures, 323-1851-340
— “IP parameters” on page 2-74
— “LAN parameters” on page 2-77
— “GNE parameters” on page 2-70
Note: You can edit GNE for IPv4 only. You cannot edit it for IPv6.
— “Lower Layer DCC/GCC parameters” on page 2-79
Note: The Edit button for the lower layer DCC/GCC parameters is only
applicable to LAPD parameters.
— “NDP parameters” on page 2-86
— “PPP parameters” on page 2-87
— “USB parameters” on page 2-92


Step Action
• Services
— “IP Version Configuration parameters” on page 2-97. For the
procedure, refer to Procedure 2-3, “Editing the IP Version”.)
— “Database Replication Service” on page 2-93
Note: The Database Replication Service window contains a Disable
button and an Enable button instead of an Edit button.
— “DHCP parameters” on page 2-94
— “DHCP Relay Agent parameters” on page 2-94
— “FTP parameters” on page 2-96
— “NETCONF parameters” on page 2-96
— “HTTP/HTTPS parameters” on page 2-96
— “SSH/Telnet parameters” on page 2-100
— “Zero Touch Provisioning parameters” on page 2-99
— “NAT Configuration parameters” on page 2-99
10 Click OK.
—end—

Procedure 2-3
Editing the IP Version
Use this procedure to edit the IP version. 6500 supports IPv4 and IPv6. One
or both protocols can operate at any given time. IPv4 is enabled by default.
IPv6 is disabled by default, but it can be enabled concurrently with IPv4 or
instead of IPv4. The IPv4 addresses and IPv6 addresses work independently
and simultaneously.
The IPv6 version setting must be turned on before the corresponding IPv6
provisioning commands will be accepted. For example, to provision an IPv6
address (in the Site Manager or TL1), IPv6 must be turned on. Prior to
disabling IPv6, the IPv6 provisioning must be deleted. IPv6 is not supported
on CPL.
The IPv4 Version setting does not need to be turned on before the
corresponding IPv4 provisioning commands will be accepted. The IPv4
Version setting has an administrative enable/disable option. This setting only
determines if the IPv4 options are displayed/available in Site Manager. The
provisioned IPv4 settings do not need to be removed before administratively
disabling IPv4.
For details about IPv4 and IPv6 support, refer to “IPv4 external DCN
connectivity” on page 1-78 and “IPv6 external DCN connectivity” on
page 1-96. For details about the IPv4 and IPv6 parameters, refer to “IP
parameters” on page 2-74. For more information on these parameters and
how they apply to the DCN, refer to Chapter 1, “Data communications
planning”.
Prerequisites
To perform this procedure you must:
• use an account with a level 3 UPC or higher
• remove all previously configured IPv6 addresses from the NE prior to
disabling IPv6


Editing the IP Version
Step Action

3 Select the Services tab.
4 Select IP Version Configuration from the Service Type drop-down list.
6 Click Edit.
7 At the IPv4 Status drop-down list, select Administrative Enable (default), or
Administrative Disable.
Note 1: When you select Administrative Disable for IPv4, you are turning off
the IPv4 options in Site Manager only; you are not turning off IPv4 in the
network element. The NE will never turn off IPv4 support.
Note 2: You do not need to remove provisioned IPv4 addresses before
selecting the Administrative Disable option for IPv4.
8 At the IPv6 Status drop-down list, select ENABLE or DISABLE (default).
Note: Prior to disabling IPv6, you must remove any provisioned IPv6
addresses.
9 At the IPv6 hop limit, enter the IPv6 hop limit. The range is 1-255. The default
is 90.
10 Click OK.
—end—

Procedure 2-4
Editing the Site Level Data Distribution
Use this procedure to edit the Site Level Data Distribution. For details, refer to
“Site Level Data Distribution (SLDD) parameters” on page 2-58. For more
information on these parameters and how they apply to the DCN, refer to
“Site-Level Data Distribution (SLDD)” on page 1-142.
The P and/or G in suffix(es) displayed next to the shelf number denote(s) the
Primary shelf and/or a GNE.
Prerequisites
To perform this procedure
• You must use an account with a level 3 UPC or higher.
• SLDD interface provisioning shall be blocked if an OSPF circuit with
Opaque = ON exists against the interface.
• DBRS and SLDD are mutually exclusive on ILAN and COLAN interfaces.
The DBRS feature will block provisioning any interfaces if the SLDD
feature is enabled. The SLDD feature will block provisioning if DBRS is
enabled.
• A port and circuit must be provisioned for the SLDD interface to enter into
an active state.
Step Action
Enabling, Disabling, or Editing SLDD

3 Select the Routers tab.
4 Select SLDD from the Router Type drop-down list.
6 Click Edit.
7 At the Admin State parameter, select Enable to enable SLDD or select
Disable to disable SLDD.


Step Action
8 At the Configuration drop-down list, in most cases, select Auto (the default
value), in which case the Scope-ID is automatically set to be the same value
as the Site ID of the shelf, and then go to step 10.
If the configuration is set to Manual, the Scope-ID must be specified in the
next step. It is recommended to consult with Ciena before setting to Manual.
9 At the SLDD Scope ID parameter, enter the scope ID. This parameter can be
edited only if the Configuration is Manual. Only shelves with the same Scope
ID will exchange information. It is recommended to consult with Ciena before
setting a manual Scope ID.
10 Click OK.
Adding an interface to the SLDD List
16 Click Add.
17 At the Name parameter, select the interface from the drop down list.
18 Click OK.
Deleting an item from the SLDD List
24 Select the interface in the table you want to delete.
25 Click Delete.
—end—

Procedure 2-5
Migrating an MD5 key
Use this procedure to migrate an IPv4 OSPF adjacency from one MD5 key
(older) to another MD5 key (newer). It covers the OSPF circuits at both ends
of the adjacency. For more information on MD5 authentication, refer to
Chapter 1, “Data communications planning”.
This procedure applies to 6500 to 6500 OSPF adjacencies. Similar steps can
be followed for 6500 to third party adjacencies, taking into consideration the
specifics of the third party device.
Prerequisites
• the OSPF circuits must be provisioned with the MD5 authentication type.
• you must use an account with a level 3 UPC or higher.
Step Action
1 Identify the network element at each end of the adjacency (referred to as

network element A and network element B henceforth).
2 Select network element A in the navigation tree.
4 In the Routers tab, select the required shelf from the Shelf drop-down list.
5 Select the OSPF Circuit from the Router type drop-down list.
6 Select the required OSPF circuit in the table.
7 Click Edit to open the Edit OSPF Circuit Parameters dialog box.
8 Enter the new MD5 key in the Key 2 field if the old key is Key 1, or in the Key 1
field if the old key is Key 2. Enter a unique ID in the corresponding ID field.
9 Click OK.
10 Repeat step 2 to step 9 for network element B.
11 In the OSPF Circuits table for both network elements A and B, verify that the
status of the new key is “Accepting” for the OSPF circuit you just edited. Click
Refresh if necessary. If the status does not change to “Accepting”, check the
provisioned key and ID values to ensure they match at each end.
12 Select the OSPF circuit on network element A and click Edit.
13 Remove the old MD5 key and click OK.
14 Repeat step 12 and step 13 for network element B.
—end—

Procedure 2-6
Adding a new entry in the communications settings
Use this procedure to add a new entry (interface, circuit, router) in the
communications settings. For more information on these parameters and how
they apply to the DCN, refer to Chapter 1, “Data communications planning”.
Prerequisites
higher.
Step Action

5 Select the appropriate comms type from the Router type or Interface type
drop-down list. See “Communications management parameters” on
page 2-31 for the options where an entry can be added.
7 Click Add to open the appropriate add dialog box.
8 Add the parameters as required (if appropriate). See the following for
parameters that can be added:
• Routers
— “IISIS Circuit parameters” on page 2-35
— “IISIS Router parameters” on page 2-38
— “IP Static Route parameters” on page 2-39
— “Static NAT parameters” on page 2-42
— “Reverse Port NAT parameters” on page 2-43
— “Port Filter parameters” on page 2-53
— “Upper Layer DCC parameters” on page 2-56


Step Action
• Interfaces
— “ARP/ND Proxy parameters” on page 2-67
— Encryption Access, refer to Encryption and FIPS Security Policy
Overview and Procedures, 323-1851-340
— “GNE Port Filter parameters” on page 2-72
— “GRE parameters” on page 2-72
For the Add IISIS Router Parameters and the Add IPv4 OSPF Router
Parameters dialogs, you have the option of adding distribution lists. To add a
distribution list, use the Add button in the Redistribution section (lower
section). A maximum of 80 distribution lists can be added for each type of list.
To delete a distribution list, select the distribution list in the Redistribution
section (lower section) and select Delete.
• Services
— “DHCP RA Interfaces parameters” on page 2-95
9 If Then
the dialog allows more than one entry to be click Apply. Go to step 8
added and you want to add another entry
otherwise go to step 10
10 Click OK.
After the manual area addresses are added/changed, perform a warm restart
of the shelf processor.
—end—

Procedure 2-7
Deleting an entry in the communications settings
Use this procedure to delete an entry (interface, circuit, router) in the
communications settings. For more information on these parameters and how
they apply to the DCN, refer to Chapter 1, “Data communications planning”.
Prerequisites
higher.
Step Action

page 2-31 for the options where an entry can be deleted.
7 Delete the parameters as required (if appropriate). See the following for
entries that can be deleted:
• Routers
— “Static NAT parameters” on page 2-42


Step Action
• Interfaces
— “GRE parameters” on page 2-72
For the Add IISIS Router Parameters and the Add IPv4 OSPF Router
Parameters dialogs, you have the option of adding distribution lists. To add a
distribution list, use the Add button in the Redistribution section (lower
section). A maximum of 80 distribution lists can be added for each type of list.
To delete a distribution list, select the distribution list in the Redistribution
section (lower section) and select Delete.
• Services
— “DHCP RA Interfaces parameters” on page 2-95
8 If you want to delete Then in the table, select
one circuit/port/entry the circuit/port/entry you want to delete from the
list of circuits/ports/entries
some but not all circuits/ select the first circuit/port/entry in the list and hold
ports/entries down the Ctrl key while individually clicking on
each required circuit/port/entry
all circuits/ports/entries select the first circuit/port/entry in the list and hold
down the Shift key while clicking once on the last
circuit/port/entry in the list.
or
select any circuit/port/entry in the list and then
Ctrl+A (Ctrl and A keys together) to select all
circuits/ports/entries
Bulk deletion is supported for some circuits/ports/entries in this release. For
the list of supported circuits/ports/entries, refer to “Communications
management parameters” on page 2-31.
9 Click Delete.
10 Click Yes to close the warning box.
—end—

Procedure 2-8
Displaying link local information
Use this procedure to display the IPv6 link local address for interfaces.
Prerequisites
higher.
Step Action

3 In the Services tab, select the required shelf from the Shelf drop-down list.
4 Select LinkLocal from the Service Type drop-down list.
5 Refer to “LinkLocal parameters” on page 2-98.
—end—

Procedure 2-9
Performing a ping using Site Manager
Use this procedure to perform a ping using the TEST-PING option in Site
Manager. This procedure is applicable for IPv4 or IPv6.
If you perform another ping without clearing the screen, the old ping
information will be cleared and the most recent ping will be displayed. The
window displays only one result at a time, but the Comms log contains all of
the attempts.
The ping details are not shown in real time (meaning for every attempt/count
it does, the screen doesn't update). It waits for the ping to be complete.
Depending on the response time of the network, it could take some time to
display anything.
Prerequisites
higher.
Step Action
Performing a ping
4 Select TEST-PING from the Service Type drop-down list.
5 Click Ping.
6 Enter the IP Address, Count, Packet Size, and Timeout values. Refer to
“TEST-PING parameters” on page 2-103.
7 Click OK.
This completes the procedure.


Performing a ping using Site Manager
Step Action
Clearing a ping
11 Select the TEST-PING from the Service Type drop-down list.
12 Click Clear to clear the ping results.
—end—

Procedure 2-10
Performing a trace route using Site Manager
Use this procedure to trace a route using the Traceroute option in Site
Manager. This procedure is applicable for IPv4 or IPv6.
If you perform another trace route request, the old trace route information will
be cleared and the most recent trace route information will be displayed. The
window displays only one result at a time, but the Comms log contains all of
the attempts.
The trace route details are not shown in real time (meaning for every attempt/
count it does, the screen doesn't update). It waits for the trace route to be
complete. Depending on the response time of the network, it could take some
time to display anything.
Prerequisites
higher.
Step Action
Performing a ping
4 Select Traceroute from the Service Type drop-down list.
5 Click Traceroute.
6 Enter the IP Address, Hop Limit, number of Probes per hop, and TimeOut
values. Refer to “Traceroute parameters” on page 2-103.
7 Click OK.
—end—

Procedure 2-11
Using the 6500 CLI ping and trace commands
Use this procedure to test for network connectivity using IP and OSI ping and
trace commands. These commands are available in the 6500 command line
interface (CLI) when using Telnet or a terminal session.
Note: The user ID and password input in the command line interface is
not case-sensitive and is converted to uppercase unless enclosed by
double quotes ("). User IDs and passwords containing lowercase
characters can be entered by enclosing them in double quotes. The
challenge/response input is case-sensitive and does not require double
quotes.
Prerequisites
higher.
Step Action
1 If you are using Then

a Terminal session Start a terminal session (see Administration and
Security, 323-1851-301 for detailed procedures).
Telnet Open a Telnet session (see Administration and
When you use the CLI port number (10010 or 10020) or SSH port (20002) for
a Site Manager terminal session or Telnet access, you access the CLI directly.
2 At the login prompt, enter the user ID by entering:
<user ID>
See Note at the beginning of this procedure.
3 At the password prompt, enter the password by entering:
<password>


Step Action
4 If you want to use the Then go to

IP ping tool for IPv4 step 5
IP ping tool for IPv6 step 6
IP traceroute tool for IPv4 step 7
IP traceroute tool for IPv6 step 8
OSI netping tool step 9
OSI clping tool step 10
OSI coping tool step 11
Telnet Administration and Security, 323-1851-301
for detailed procedure
OSI Rlogin Administration and Security, 323-1851-301
Rtrv_nsap Administration and Security, 323-1851-301
logout step 12
Performing a ping for an IPv4 address

5 Type ping followed by the ping parameters as shown below:
ping <IP-ADDR> [count <COUNT>] [size <SIZE>]
where
<IP-ADDR> is the IPv4 address in the format xxx.xxx.xxx.xxx
<COUNT> is optional repeat count (1 to 255, default 5)
<SIZE> is optional datagram size in bytes (8 to 1450,
default 100)
The response to the ping is displayed.

If you want to test the connectivity using another command, go back to step 4.
Otherwise, you have completed this procedure.


Step Action
Performing a ping for an IPv6 address

6 Type ping6 followed by the ping parameters as shown below:
ping6 <IP-ADDR> [count <COUNT>] [size <SIZE>] [timeout <TIMEOUT>]
where
<IP-ADDR> is the IPv6 address in the format of eight groups of
four hexadecimal digits, separated by ':' (colon)
default 100)
<TIMEOUT> is the timeout period in seconds (1-60, default 10)

Performing a trace route for an IPv4 address
7 Type traceroute followed by the traceroute parameters as shown below:
traceroute <IP-ADDR> [nprobes <PROBE-COUNT>]
[timeout <TIMEOUT-VAL>] [ttl <TTL>]
where
<IP-ADDR> is the IP address in the format xxx.xxx.xxx.xxx
<PROBE-COUNT> is optional repeat count (1 to 10, default 3)
<TIMEOUT-VAL> is optional timeout in seconds (1 to 10, default
10)
<TTL> is optional time to live (1 to 255, default 30)
The response to the traceroute response is displayed.



Step Action
Performing a trace route for an IPv6 address

8 Type traceroute6 followed by the traceroute parameters as shown below:
traceroute6 <IP-ADDR> [hoplimit <HOPLIMIT>]
[nprobes <PROBE-COUNT>] [timeout <TIMEOUT-VAL>] [ttl <TTL>]
where
<IP-ADDR> is the IPv6 address in the format of eight
groups of four hexadecimal digits, separated
by ':' (colon)
<HOPLIMIT> is the maximum number of hops allowed
(1-13, default 10)
10)

Performing a net ping
9 Type netping followed by the netping parameters as shown below:
netping <OSI-ADDR>
where
<OSI-ADDR> is the OSI NSAP address in the format
[<AA><SYSID><NSEL>] where
AA is Area identifier
SYSID is System Identifier
NSEL is NSAP Selector
A response to the netping is displayed.



Step Action
Performing a connectionless ping

10 Type clping followed by the clping parameters as shown below:
clping <OSI-ADDR> [number <NUM>] [rate <RATE>]
[size<TSDU_SIZE >] [validate <VALIDATE_FLAG>]
where
<OSI-ADDR> is the OSI NET address of the remote node to
ping in non-RPF format
[<AA><SYSID><NSEL> (use zero N-selector)
where
<NUM> is optional number of TSDUs to send (1 to 500,
default 20)
<RATE> is optional rate at which to send in seconds (0 to
300, default 1)
<TSDU_SIZE> is optional size in bytes of TSDUs to send (12 to
1425, default 64)
<VALIDATE_FLAG> is optional validate the contents of looped back
TSDUs (0 for no, 1 for yes, default 0)
A response to the clping is displayed.



Step Action
Performing a connection oriented ping

11 Type coping followed by the coping parameters as shown below:
coping <OSI-ADDR> [number <NUM>] [rate <RATE>]
where
where
SYSID is System Identifier, and
default 20)
300, default 1)
16384, default 64)
A response to the coping is displayed.

12 Either:
• close the terminal session (see Administration and Security,
323-1851-301 for detailed procedures).
• exit and close the Telnet session by entering:
— Ctrl+]
— quit
—end—

Communications management parameters

Comms Setting Management options
Table 2-1
Option Description Add/Delete Edit
Routers
IISIS Circuit Displays information about the IISIS circuits. See “IISIS Circuit Yes (Note 1) No
parameters” on page 2-35.
IISIS Router Displays information about the IISIS routing. See “IISIS Router Yes (Note 2) No
IP Static Route Displays information about the IP Static Route. See “IP Static Yes (Note 1) No
Route parameters” on page 2-39.
Static NAT Displays information about the Static Network Address Yes (Note 1) No
Translation (NAT). See “Static NAT parameters” on page 2-42.
Reverse Port Display the information about mapping the TCP/UDP port of Yes (Note 1) No
NAT external requests to other internal port numbers and use a single
external IP address to access service in the internal network. See
“Reverse Port NAT parameters” on page 2-43.
OSPF Circuit Displays information about the OSPF circuits. See “OSPF Circuit Yes No
OSPF Router Displays information about the OSPF routers. Supported on all Yes (Note 2) No
Ethernet, GCC channels, and static tunnels but not the craft LAN
port on the shelf processor. See “OSPF Router parameters” on
page 2-50.
Port Filter Displays information about the port filtering. It applies to IP Yes No
packets that are being forwarded from a private interface to a
public one, on the GNE. See “Port Filter parameters” on
page 2-53.
Upper Layer Displays information about the manual area addresses used in Yes No
DCC OSI addressing. See “Upper Layer DCC parameters” on
page 2-56.
SLDD Displays information about the Site Level Data Distribution Yes Yes
(SLDD). See “Site Level Data Distribution (SLDD) parameters” on
page 2-58.
Visible NE Displays the routing information. See “Visible NE Information No No

Information parameters” on page 2-60.
IISIS Routing Displays the routing table. See “IISIS Routing Table parameters” No No
Table on page 2-61.

Table 2-1
Comms Setting Management options (continued)
IP Routing Displays information about IP routing. See “IP Routing Table No No

Table parameters” on page 2-62.
OSPF Displays information about OSPF neighbors. See “OSPF No No
Neighbors Neighbors parameters” on page 2-65.
Interfaces
ARP/ND Proxy Displays information about the ARP Proxy IP address. See “ARP/ Yes (Note 1) No
ND Proxy parameters” on page 2-67.
ARP/ND Table Displays information about the ARP table. See “ARP/ND Table No No
DSM OAM Link Displays information about the DSM OAM link status for OC3 No Yes
facilities. See “DSM OAM Link parameters” on page 2-69.
Encryption Refer to Encryption and FIPS Security Policy Overview and Yes Yes
Access Procedures, 323-1851-340.
GNE Displays GNE information used for tunneling on all interfaces Yes (Note 1) No
“GNE parameters” on page 2-70.
GNE Port Filter Displays information about the GNE port filtering interface. See Yes (Note 1) No
“GNE Port Filter parameters” on page 2-72
GRE Displays GRE information used for tunneling on all interfaces Yes (Note 1) No
except the RS-232 port. See “GRE parameters” on page 2-72.
IP Displays information about the IP on the LAN and RS-232 serial Yes Yes
ports. See “IP parameters” on page 2-74.
LAN Displays information about the six external LAN interfaces. “LAN Yes Yes
Lower Layer Displays information about the DCC/GCC communication on the Yes Yes
DCC/GCC OC-n/STM-n/STM0J/STM1J/STM4J and GCC communication
on the OTMn ports, and for specific circuit packs, the submarine
wayside channel. See “Lower Layer DCC/GCC parameters” on
page 2-79.
NDP Displays the admin state of the NDP feature and the facilities with Yes Yes
NDP enabled. See “NDP parameters” on page 2-86.
PPP Displays information about point-to-point protocol for No Yes

communication on the OC-n/STM-n/STM0J/STM1J/STM4J/
OTMn ports and the RS-232 serial ports. See “PPP parameters”
on page 2-87.

Table 2-1
Serial/RS-232 Displays information about the serial RS-232 ports. See “Serial/ No Yes
RS-232 parameters” on page 2-88.
TL1 Gateway Displays information about the TL1 Gateway Connections. See No No
Connections “TL1 Gateway Connections parameters” on page 2-91.
USB Displays the status of the SP2 USB ports. See “USB parameters” No Yes
on page 2-92.
Services
IP Version Displays IP version settings. See “IP Version Configuration No Yes

Configuration parameters” on page 2-97.
Database Displays services to replicate AR/TR data between independent No No

Replication OSPF networks. See “Database Replication Service” on
page 2-93.
DHCP Displays information about the DHCP service used for local PC No Yes
access. See “DHCP parameters” on page 2-94.
DHCP Relay Displays information about the Relay Agent server. See “DHCP Yes Yes
Agent Relay Agent parameters” on page 2-94.
Note: For detailed DHCP Relay Agent related procedures, refer
to Commissioning and Testing, 323-1851-221.
DHCP RA Displays information about the DHCP RA interfaces. See “DHCP Yes No
Interfaces RA Interfaces parameters” on page 2-95.
Note: For detailed DHCP RA Interfaces related procedures, refer
to Commissioning and Testing, 323-1851-221.
FTP Displays information about the file transfer protocol (FTP) service No Yes
used for transferring files to/from the network element. See “FTP
SSH/Telnet Displays information about SSH and Telnet used for remote No Yes
access to/from remote computers. See “SSH/Telnet parameters”
on page 2-100.
NETCONF Displays information about the NETCONF service. See No Yes

“NETCONF parameters” on page 2-96.
HTTP/HTTPS Displays information about the support secure HTTP service. See No Yes
“HTTP/HTTPS parameters” on page 2-96.
TEST-PING Enables the user to perform a ping. See “TEST-PING N/A N/A

Table 2-1
Zero Touch Displays information about Zero Touch Provisioning. See “Zero No Yes
Provisioning Touch Provisioning parameters” on page 2-99.
NAT Displays information about NAT configuration. See “NAT No Yes
Configuration Configuration parameters” on page 2-99.
Traceroute Enables the user to trace the route. See “Traceroute parameters” N/A N/A
on page 2-103.
LinkLocal Displays the link local addresses for all interfaces. See “LinkLocal N/A N/A
Note 1: Bulk deletion is supported for this Comms Setting Management option. Refer to Procedure 2-7,
“Deleting an entry in the communications settings” for more information on how to perform a bulk
deletion.
Note 2: Bulk deletion is supported for the redistribution section of this Comms Setting Management
option. Refer to Procedure 2-7, “Deleting an entry in the communications settings” for more information
on how to perform a bulk deletion.

Routers tab
IISIS Circuit parameters
ISIS is a routing protocol based on the OSI intra-domain routing protocol with
IP-specific extensions as specified in RFC1195. IISIS allows IP and OSI to
coexist in a single routing domain, allowing IP-only routers, OSI-only routers,
and dual IP/OSI routers to be effective in routing in a single network.
The IISIS Circuit option is only applicable for IPv4. The IISIS Circuit option has
a single table. Use the Add button to provision new IISIS circuits and the
Delete button to delete existing IISIS circuits. You must create an IISIS circuit
on each provisioned interface you want IISIS to run on (except Auto-tunnels
and the RS-232 ports).
Note 1: It is recommended that an IISIS circuit is not created for

LAN-shelf-15/LAN-shelf-41 unless LAN-shelf-15/LAN-shelf-41 is
configured to access remote network elements.
Note 2: Do not add IISIS circuits to LAN ports provisioned with the
non-routing mode set to On.
Note 3: Do not create an IISIS circuit on the COLAN interfaces if the
interface is not connected to external DCN running IISIS.
For host OC-3 ports used for connecting to a DSM, an IISIS circuit is
automatically added/deleted when enabling/disabling a DSM OAM link (see
“DSM OAM Link parameters” on page 2-69).
For OTMn ports (except for OTM2 ports on 1xOC-192/STM-64, 2x10G OTR,
or SuperMux circuit packs, and OTM3 ports on 40G OCI circuit packs), a
GCC0 or GCC1 PPP circuit (with IP address of 0.0.0.0) and an associated
IISIS circuit are automatically created when the OTMn facility is provisioned if
the default auto GCC0 mode or GCC1 mode parameter is set to IISIS in the
System tab of the Node Information application and if the Shelf IP has been
provisioned on the NE.
When provisioning both GCC0 and GCC1 with default IISIS metrics on a shelf,
Comms over GCC1 is preferred as opposed to GCC0.

Table 2-2
Parameter Options Description Addable/
Editable
Unit • SHELF-shelf Displays the available ports for an IISIS circuit. Yes
• LAN-shelf-15 Only OC-n/STM-n/STM0J/STM1J/STM4J/
• LAN-shelf-41 OTMn ports and OTUTTP/ODUTTP/ODUCTP
AID with lower layer DCC/GCC0/GCC1
• LAN-shelf-16 (or 42) provisioned are available for selection.
• COLAN-shelf-A IISIS over the GRE interfaces is not supported in
• COLAN-shelf-X this release.
• ILAN-shelf-IN
• ILAN-shelf-OUT
• GRE-shelf-IP-1 to 4
• OC-n/STM-n/STM0J/
STM1J/STM4J/OTMn
ports
• OTUTTP/ODUTTP/
ODUCTP AID
Carrier • Section/RS Displays the DCC channel used, section/RS, Yes
• Line/MS Line/MS, GCC used, GCC0 or GCC1 (options
available depend on circuit pack type and
• GCC0 function).
• GCC1
Circuit 1 to 63 Sets the circuit default metric used to calculate Yes

Default the best route. Default depends on type of
Metric interface as follows:
• SHELF, LAN-shelf-15/LAN-shelf-41
LAN-shelf-16LAN-shelf-42, COLAN, ILAN,
GRE-IP: 4
• OC-n/STM-n/STM0J/STM1J/STM4J/OTMn
ports with Line/MS DCC/GCC0/GCC1
provisioned: 5
• OTUTTP/ODUTTP/ODUCTP AID: 5
• OC-n/EC1/STM-n/STM0J/STM1J/STM4J
ports with section/RS DCC provisioned: 6
Select a higher value for a slower circuit.

Table 2-2
IISIS Circuit parameters (continued)

Editable
Level 2 Only • On Sets the status of level 2 only routing on the No

• Off (default) IISIS circuit.
Not supported in this release, On option is
always disabled.
3 Way • On Sets the status of 3-way handshaking on the No

Handshake • Off (default) IISIS circuit.
Not supported in this release, On option is
always disabled.
Neighbour • Off (default) Sets the protocols supported on neighbor Yes

Protocols • IP routers (overrides what the router advertises).
Supported Note 1: OSI is only valid if LAPD is selected.
Override • OSI
Note 2: When provisioning an IISIS circuit on an
• IP and OSI
ILAN port, you must ensure that neighbor
protocol supported override parameter is set to
Off.
optical DCC port connected to OSI managed
network elements (for example, Optical Metro
3000 and Optical Metro 4000), you must ensure
that neighbor protocol supported override
parameter is set to OSI.
optical DCC port connected to another 6500
network element, you must ensure that neighbor
protocol supported override parameter is set to
Off.
Note 5: The “IP” and “IP and OSI” options are
not supported.

IISIS Router parameters

The IISIS Router option is only applicable for IPv4. The IISIS Router option
has two tables.
• The upper Router table displays information about the IISIS router. Use
the Add button to add an IISIS router (only one allowed). Use the Delete
button to delete the existing IISIS router. If not already created, an IISIS
router is automatically created when an OTMn facility is provisioned
(except for OTM2 ports on 1xOC-192/STM-64, 2x10G OTR, or SuperMux
circuit packs) if the default auto GCC0 or GCC1 mode is set to IISIS in the
System tab of the Node Information application and if the Shelf IP has
• The lower Redistribution table displays information about the redistribution
lists provisioned for the IISIS router. Use the Add button to add IISIS
redistribution list parameters. Use the Delete button to delete a
redistribution list.
Table 2-3

Editable
Router table
Router Level Level 1 Sets the IISIS router level. Level 2 not supported in this No
release, option is always disabled.
L1 Priority 1 to 127 Sets the level 1 router priority. The L1 router assigned Yes
(default 64) the highest priority becomes the L1 designated router
for that LAN segment.
L2 Priority 1 to 127 Sets the level 2 router priority. The L2 router assigned No
(default 64) the highest priority becomes the L2 designated router
for that LAN segment.
Not supported in this release, option is disabled.
Route • On (default) Sets whether routes (Off) or route summaries (On) are Yes
Summarization • Off redistributed.
Redistribution table
Route • OSPF Sets the IISIS router distribution list entries for the Yes
Redistribution/ Distribution selected IISIS router.
List • Static
Distribution
(default)
IP Subnet Standard dot Sets the IP subnet address of the distribution list entry Yes
notation for the selected IISIS router.

Table 2-3
IISIS Router parameters (continued)

Editable
Subnet Mask Standard dot Sets the subnet mask of the distribution list entry for the Yes
notation selected IISIS router.
Metric 1 to 63 Sets the metric (cost) of the distribution list entry for the Yes
selected IISIS router.
Metric Type • External Sets the metric type of the distribution list entry for the Yes
(default) selected IISIS router.
• Internal
IP Static Route parameters

The IP Static Route option contain two tabs: IPv4 and IPv6. The IP versions
are enabled/disabled/edited using the options in the IP Versions Configuration
service type (Services tab).
The IP Static Route option has a single table which displays static entries. Use
the Add button to add a static entry and Delete button to delete an existing
static entry. The IPv6 tab also contains an Edit button for this option. Use the
Check button to start a netmask provisioning check on all the IP static routes
in order to let you know if the next hop IP for each IP static route is within the
subnet of the Circuit ID IP.
Table 2-4
IPv4 Static Route parameters

Editable
IP Subnet Standard dot notation Sets the destination IP subnet of the static route Yes
entry.
Subnet Mask Standard dot notation Sets the subnet mask of the table entries. Yes
Next Hop Standard dot notation Sets the IP address of the next hop. Yes
Note: The Next Hop IP for each IP Static Route must
be within the subnet of the Circuit ID IP (see “IP
parameters” on page 2-74).
Cost 1 to 65535 Sets the cost of the link. Yes

Table 2-4
IPv4 Static Route parameters (continued)

Editable
Circuit ID • COLAN-shelf-A Sets the circuit identifier of the port used to get to the Yes
• COLAN-shelf-X next hop.
• ILAN-shelf-IN
• ILAN-shelf-OUT
• GRE-shelf-OSI-1 to
4
• LAN-shelf-15
• LAN-shelf-41
• LAN-shelf-16
• LAN-shelf-42
• OC-n/STM-n/
STM0J/STM1J/
STM4J/ OTMn/
OTUTTP/ ODUTTP/
ODUCTP port
• OSC-shelf-slot- port
• SERIAL-shelf-X
Carrier • Section/RS Selects the DCC channel used, section/RS or Line/ Yes
• Line/MS MS, GCC used, GCC0 or GCC1 (options available
depend on circuit pack type and function).
• GCC0
• GCC1
Status • FORWARDING Displays the status of the route. No
• REJECTED • FORWARDING
Forwarding means the route is active in the routing
table and its next hop is reachable.
• REJECTED
Note: Rejected means that the route is not in the
routing table and its next hop is not reachable
Description alphanumeric Sets the character string from 1-64 characters used Yes
to label the static route.

Table 2-5
Editable
Instance Id STATICRT-<shelf>-1 Specifies the index-based AID of the static route. Yes
to 80
IP Subnet Eight groups of four Specifies the IPv6 destination subnet of the static Yes
hexadecimal digits, route entry. The full length can be used or the
separated by ':' reduced length version can be used (removing the
(colon) leading zeros and the intermediate block of 0000).
Prefix 0 to 128 Specifies the IPv6 prefix of the destination subnet. Yes
Next Hop Eight groups of four Specifies the IPv6 address of the next hop. The full Yes
hexadecimal digits, length can be used or the reduced length version can
separated by ':' be used (removing the leading zeros and the
(colon) intermediate block of 0000.
Cost 1 to 65535 Specifies the cost associated with the static route. Yes
Circuit ID pull-down menu Specifies the circuit identifier of the port used to get Yes
to the next hop.
If the Next Hop is provisioned, the Circuit ID is
optional.
Carrier • Section/RS Specifies the DCC channel used, section/RS or Line/ Yes
• Line/MS MS, GCC used, GCC0 or GCC1 (options available
depend on circuit pack type and function).
• GCC0
• GCC1
RD Type Internal, External If redistribution into OSPFv3 is enabled, specifies Yes

metric type for routes redistributed into OSPFv3.
Internal results in Type-1 metric, External results in
Type-2 metric.
Redistribute • OFF Specifies whether this static route is redistributed into Yes
• OSPFv3 OSPFv3. If redistributed, the metric is the same as
the cost specified in the static route and the
metric-type is specified through the RD Type
parameter, above. OSPFv3 refers to OSPF for IPv6.

Static NAT parameters

The Static NAT option has a single table. Use the Add button to provision a
new Static NAT entry and the Delete button to delete an existing Static NAT
entry.
Table 2-6
Static NAT parameters

Editable
DCN IP Standard dot Sets the DCN IP address. Yes

address notation
Remote NE IP Standard dot Sets the Remote NE IP address. Yes

address notation
Prime • Yes (default) Sets the prime. The Prime parameter indicates which of the Yes
• No RNE IP address (A RNE shelf may have more than one IP
e.g. shelf, ILAN-In,...) is used for mapping of incoming
packets. It is recommended that the prime is set to Yes for
the entries which RNE is a shelf-IP address
Note 1: The Add button will be disabled for Private IP configuration of the GNE. The Add button is
enabled when the GNE is in “Redundant' and “NAT” Configuration.
Note 2: If multiple entries need to be deleted, select multiple entries and click on Delete button for bulk
deletion.

Reverse Port NAT parameters

Reverse Port NAT entries are entered on a Private-IP GNE to provide access
to specific services on remote NEs.
The Reverse Port NAT option is only applicable for IPv4.The Reverse Port
NAT entry has a single table. Use the Add button to provision a new Reverse
Port NAT entry and the Delete button to delete an existing Reverse Port NAT
entry. The Add button is disabled when Static NAT entries exist.
Table 2-7

Editable
DCN IP Address Standard dot notation Displays the active public IP of the GNE. No
DCN Port (NATBASEPORT + 2050) to Sets the external port which is being Yes
(Note 1) (NATBASEPORT + 4099) mapped.
The default value of
NATBASEPORT is 50000.
Remote NE IP Standard dot notation Identifies the Private IP of the remote NE. Yes
Address
Remote NE • HTTP Select the service that will be used to Yes

Service • Secure HTTP access the remote NE.
• FTP
• NETCONF
• NNCLI (Telnet)
• NNCLI (SSH)
• TL1 (Telnet)
• TL1 (SSH)
• SNMP
• Other

Table 2-7
Reverse Port NAT parameters (continued)

Editable
Remote NE Port 1 to 65535 Displays the internal port which is being Yes
(Note 2) mapped.
Protocol • TCP Displays which type of the protocol is Yes

(Note 3) • UDP applicable to the remote NE port.
Note 1: NATBASEPORT can be modified in Site Manager under 'NAT configuration' in the Comms
Setting Management/Services tab. The default range of dynamic NAT ports that are opened on the NE
are 50000 to 50511. This range can be changed by editing the NAT configuration parameters.
Note 2: For a selected service in the Remote NE Service parameter, the remote NE port field is
populated with the port number for that service, except for the “Other” service. Only for the “Other”
service, the remote NE port field is provisionable.
Note 3: For the SNMP service, the Protocol is always UDP. For the rest of the Remote NE Service
options except “Other”, the Protocol is always TCP. Only for the “Other” service, the Protocol parameter
is provisionable. For Ciena support access to debug ports 8888, 8889, and 28888, choose TCP.
OSPF Circuit parameters

The OSPF Circuit option contains two tabs: IPV4 and IPV6. The IP versions
OSPFv2 refers to OSPF for IPv4. OSPFv3 refers to OSPF for IPv6.
The OSPF Circuit option has a single table which displays information about
the OSPF circuit. Use the Add button to add an OSPF circuit or the Edit
button to edit an existing OSPF circuit. Use the Delete button to delete an
existing OSPF circuit.
An OSPF circuit cannot be provisioned against a lower layer DCC with its
Protocol parameter set to LAPD.
Note 1: Do not add OSPF circuits to LAN ports provisioned with the
Note 2: Do not create an OSPF circuit on the COLAN interfaces if the
interface is not connected to external DCN running OSPF.

The OSPF circuits will automatically create for IPv4 as follows: For IPv4, for
OTMn ports (except for OTM2 ports on 1xOC-192/STM-64, 2x10G OTR, or
SuperMux circuit packs, and OTM3 ports on 40G OCI circuit packs), a GCC0
or GCC1 PPP circuit (with IP address of 0.0.0.0) and an associated OSPF
circuit are automatically created when the OTM2 facility is provisioned if the
default auto GCC0 mode or GCC1 mode parameter is set to OSPF in the
System tab of the Node Information application and if the Shelf IP has been
For IPv6, OSPF circuits are not automatically created.
Table 2-8
IPv4 OSPF Circuit parameters
Editable
Unit/Name • COLAN-shelf-A Displays the ports available for OSPFv2. Yes

• COLAN-shelf-X
• ILAN-shelf-IN
• ILAN-shelf-OUT
• LAN-shelf-15/ 41
• LAN-shelf-16/42
• SHELF-shelf
• CONTROL-shelf-
GROUP0
• CONTROL-shelf-
GROUP1
STM1J/STM4J/OTMn
ports
• OTUTTP/ODUTTP/
ODUCTP AID
Carrier • Section/RS Sets the DCC/GCC carrier. Yes

• Line/MS Only applicable to OCn/STMn/OTMn ports and
• GCC0 OTUTTP/ODUTTP/ODUCTP AID.
• GCC1
Network Area Standard dot notation Sets the area (defaults to backbone area of Yes
0.0.0.0).

Table 2-8
IPv4 OSPF Circuit parameters (continued)

Editable
Cost 1 to 65535 Sets the cost of the route (reflects speed of Yes
interface). Defaults are as follows:
• SHELF: 0 (read only)
• LAN-shelf-15/LAN-shelf-41,
LAN-shelf-16LAN-shelf-42, COLAN, ILAN: 10
• GCC0/1 on OTM1: 303
• GCC0/1 on OTM2: 75
• GCC0/1 on OTUTTP/ODUTTP/ODUCTP: 75
• Section/RS DCC: 520
• Line/MS DCC: 174
Area Default 1 to 16777215 Sets the cost of the route to the next area. No
Cost (default 1) Note: It is not supported in this release.
Dead Interval 1 to 65535 Sets the interval (in seconds) at which hello Yes
(default is 40) packets must not be seen before neighbors
declare the router down.
Hello Interval 1 to 65535 Sets the interval (in seconds) between the hello Yes
(default is 10) packets that the router sends on the interface.
Retransmit 1 to 3600 (default is 5) Sets the interval (in seconds) required between No
Interval link-state advertisement retransmissions.
Note: It is not supported in this release.
Transmit Delay 1 to 3600 (default is 1) Sets the estimated time (in seconds) it takes to No
transmit a link state update packet over this
interface.
Priority 0 to 255 (default is 1) Sets the router priority value used in multi-access Yes
networks for the election of the designated router
(0 indicates that router is not eligible to become
designated router).
Area • Off (default) Sets whether the router is in a not so stubby area Yes
• NSSA (NSSA) or stub area. NSSA and Stub not
supported in this release.
• Stub

Table 2-8

Editable
Opaque Link • On (default) Sets whether opaque link state advertisement Yes
State • Off performs on the OSPFv2 circuit. Default Off for
Advertisement COLAN, ILAN, and LAN ports. Default On for all
other ports.
Passive OSPF • On Determines whether OSPFv2 adjacency loss Yes

Circuit • Off (default) should be detected. If set to On, OSPFv2
adjacency loss will be ignored.
Authentication • Null (default) Sets the authentication type. Null means no Yes
Type • Simple authentication.
• MD5
Simple string of up to 8 Sets the password if authentication type is simple Yes

Password characters password.
Status • Accepting Displays the status of the simple password No
• Rejecting authentication.
• Null • Accepting: The password is valid.

• Rejecting: The password is not valid.
• Null: The password is not provisioned.
MD5 Identifier 1 0 to 255 Sets the identifier for the first MD5 key. Must be Yes
unique on an OSPFv2 interface.
MD5 Key 1 string of up to 16 Sets the password for the first MD5 key. Yes
characters
Status 1 • Accepting Displays the status of the authentication using No

• Rejecting MD5 Key 1.
• Null • Accepting: The authentication key is valid.

• Rejecting: The authentication key is not valid.
• Null: The authentication key is not provisioned.

Table 2-8

Editable
MD5 Identifier 2 0 to 255 Sets the identifier for the second MD5 key. Must Yes
be unique on an OSPFv2 interface.
MD5 Key 2 string of up to 16 Sets the password for the second MD5 key. Yes
characters


• Null: The authentication key is not provisioned.
Table 2-9

Editable
AID OSPFV3-<shelf>-1 to Displays the index-based AID of the OSPFv3 Yes

256 circuit.
Circuit Interface Sets the interface to which the OSPFv3 circuit is Yes
assigned.
Carrier • Section Sets the DCC or GCC channel. Options depend Yes
• Line on the circuit pack type and function.
• GCC0
• GCC1
• LAN-shelf-15/LAN-shelf-41,
LAN-shelf-16LAN-shelf-42, COLAN, ILAN: 10
• GCC0/1 on OTM1: 303
• GCC0/1 on OTUTTP/ODUTTP/ODUCTP: 75
• section/RS DCC: 520
• Line/MS DCC: 174

Table 2-9

Editable
Dead Interval 1 to 65535 Sets the interval (in seconds) after which router is Yes
(sec) (default 40) declared down if no hello packets are received.
Hello Interval 1 to 65535 Sets the interval (in seconds) between the hello Yes
(sec) (default 10) packets that the router sends on the interface.
Instance Id 0 Sets the instance Id. No

Network Area Standard dot notation Sets the area to which the interface is assigned Yes
(defaults to backbone area of 0.0.0.0).
Passive OSPF • On If redistribution into OSPFv3 is enabled, specifies Yes

Circuit • Off (default) metric type for routes redistributed into OSPFv3.
Internal results in Type-1 metric, External results
in Type-2 metric.
Primary Area • On (default) Sets the primary area. No

• Off Note: It is not supported in this release.
Priority 0 to 255 (default 1) Sets the router priority value used in multi-access Yes
networks for the election of the designated router
(0 indicates that router is not eligible to become
designated router). Used in the designated router
election algorithm.
Retransmit 1 to 3600 (default 5) Sets the interval (in seconds) required between No
Interval (sec) link-state advertisement retransmissions.
Transmit Delay 1 to 3600 (default 1) Sets the estimated time (in seconds) it takes to No
(sec) transmit a link state update packet over this
interface.

OSPF Router parameters

The OSPF Router option contain two tabs: IPV4 and IPV6. The IP versions
service type (Services tab). OSPFv2 refers to OSPF for IPv4. OSPFv3 refers
to OSPF for IPv6.
For the IPv4 tab, the OSPF Router option has two tables.
• The upper Router table displays information about the OSPFv2 router.
Use the Add button to add an OSPF router. Use the Edit button to edit an
OSPFv2 router. Use the Delete button to delete an existing OSPFv2
router.
lists provisioned for the OSPFv2 router. Use the Add button to add
OSPFv2 redistribution list parameters. Use the Delete button to delete a
For IPv4, if not already created, an OSPF router is automatically created when
an OTMn facility is provisioned (except for OTM2 ports on 1xOC-192/STM-64,
2x10G OTR, or SMUX circuit packs, and OTM3 ports on 40G OCI circuit
packs) if the default GCC0 and/or GGC1 mode is set to OSPF in the System
tab of the Node Information application and if the Shelf IP has been
For the IPv6 tab, the OSPF Router option has a single table. The Router table
displays information about the OSPFv3 router. Use the Add button to add an
OSPFv3 router. Use the Edit button to edit an OSPFv3 router. Use the Delete
button to delete an existing OSPFv3 router.
For IPv6, OSPF Routers are not automatically created. Redistribution is

performed on the static route in IPv6, not on the OSPFv3 router.
Table 2-10
IPv4 OSPF Router parameters

Editable
Router
OSPF Router Standard dot Sets the router ID for the OSPFv2. Yes
Id notation It is recommended that the SHELF address (if
provisioned) is used as the OSPFv2 Router ID.
Link State • External (default) Sets the type of link state announcement used. Yes
• Router This parameter is not used and can be left at the
• Summary default value (External).

Table 2-10
IPv4 OSPF Router parameters (continued)

Editable
Route • ON (default) Sets whether routes (off) or route summaries (On) are Yes
Summarization • OFF redistributed.
Autonomous • ON (default) Sets the autonomous system border router (ASBR). Yes
System Border • OFF ASBR identifies whether an OSPFv2 router can
Router accept input (route redistribution) from another
autonomous system such as IISIS, or static routes.
Opaque Filter • All Disables the OSPF Opaque LSA Flooding Control Yes
• LAN (OOLFC), or enables for LAN, or enables for all.
• Off (default) OOLFC reduces the number of Type 11 opaque

LSAs containing AR and TR records in the OSPF
database for 6500 shelf that is part of an OSPF
network.
Cannot be set to on (All or LAN) if ODBR is on. And
vice versa.
Shelf IP • ON Enables or disables shelf IP redistribution. Shelf IP Yes

Redistribution • OFF (default) redistribution provides the ability to redistribute a
route to the local shelf IP into all OSPF areas that the
local shelf participates in. All NEs in these
participating OSPFv2 areas will install the received
route into their local IP routing table. Only supported
in OSPF networks without a backbone.
ABR • RFC 3509 (default) Selects the Area Border Router. Yes
• RFC 2328
Compatible
RFC1583 • On (default) Enables or disables the Request for Comments Yes

• Off (RFC) 1583 compatibility.
Redistribution
Route • IISIS Distribution Sets the origin of the route(s) to be redistributed. Yes
Redistribution/ • Static Distribution
List (default)
IP Subnet Standard dot Sets the IP subnet address for redistribution. Yes
notation

Table 2-10

Editable
Subnet Mask Standard dot Sets the subnet mask for redistribution. Yes
notation
Metric 1 to 65535 Sets the metric for redistribution. Yes
Metric Type • External (default) Sets the metric type for redistribution. Yes
• Internal
Table 2-11

Editable
OSPFv3 Standard dot Sets the router ID for the OSPFv3. Yes
Router Id notation The OSPFv3 Router ID is automatically filled in/
entered. Because it uses the standard dot notation,
Site Manger will auto fill the IP with the IPv4 Shelf IP
if it is provisioned when you click the Add button.
It is recommended to use the IPV4 SHELF IP as the
OSPFv3 Router ID.

Port Filter parameters

The Port Filter entry has a single table. Use the Add button to provision a new
Port entry and the Delete button to delete an existing Port Filter entry. Port
Filter changes will be reflected for both IPv4 and IPv6. See Table 2-13 on
page 2-54 and Table 2-14 on page 2-55 for TCP and UDP ports/ranges open
by default that can be blocked or unblocked.
Table 2-12

Editable
Unit • COLAN-shelf-A Displays the provisioned ports. Yes

• COLAN-shelf-X Refer to “Provisionable port filtering” on
page 1-388.
Action • Block Displays the action to be taken when IP packets Yes

• Permit match the filter rule.
Filtering Location • Ingress Sets the location of the filter rule for the Yes
• REMFORWARDOUT provisioned port.
Protocol • TCP Sets the TCP or UDP protocol which is Yes

• UDP applicable to the permitted destination port.
Destination Start 1 to 65535 Sets the start of the blocked or permitted port of Yes
Port the protocol type.
Destination End 1 to 65535 Sets the end of the blocked or permitted port of Yes
Port the protocol type.
Note: You are allowed the provisioning of the Port filtering on the GNE when it is configured in Private
IP mode.

Table 2-13
TCP ports/ranges open by default
Port Description
20, 21 FTP
22 SSH (TL1)
23 Telnet (TL1)
80 HTTP
443 Secure HTTP
830 NETCONF
1010 Ciena debug
1500-1507 Optical Section Channel Topology
1545-1552 Network Channel Topology
2650, 2651 Optical Section Channel Topology 2 TCP server
2654-2661 Network Channel Topology 1 TCP server

3081 IANA Length-Value TL1
3083 IANA Raw Telnet TL1
4000 DBRS: Database Replication System
8888 Ciena debug
8889 Ciena debug (emergency access)
10001 Telnet (TL1 - no echo, no prompt)
10010, 10020 CLI
20000 SSH (TL1 - no echo, no prompt)
20001 SSH (TL1)
20002 SSH (CLI)
28888 SSH (Ciena debug)
50000-50511 PASSIVE ftpd connections AND/OR NAT ports

Table 2-14
UDP ports/ranges open by default
Port Description
67-68 DHCP
123 SNTP
161-162 SNMP
1024 reserved
1509-1516 Optical Section Channel topology
1530 Topology UDP Server

1590 CBT Send UDP Port
1593-1594 Network Channel topology
1812 RADIUS
2112-2113 Inter Node Signaling
2600-2602 Adjacency Auto Discovery
3085 LOC Three Message Protocol
4000 DBRS: Database Replication System
4100 Inter-Shelf-Task for OM5000 SMI solution
4321 TEAS
4322 RAS
17185 VxWorks Workbench

20560 Photonic Domain Messaging
33434-33946 Traceroute
50000-50511 NAT ports

Upper Layer DCC parameters

The Upper Layer DCC option is only applicable for IPv4.The Upper Layer DCC
option has a single table with three entries, one for each of the three possible
manual area addresses required to interoperability with other OSI products.
The manual area addresses are used to form the NSAP address of each
network element in the OSI level 1 area.
Use the Add button to add new manual area addresses to an unprovisioned
entry.
CAUTION
Loss of data communications
The deleting of existing manual addresses can cause a loss of
OSI data communications to the network element. IP based
data communications will be unaffected unless the network
element is being accessed through another OSI-based node.
To edit an existing manual area address, add a new manual area address to
an empty entry to support other equipment then delete existing manual area
address.
Note: If you are moving this network element to a new area, the manual
area address must be added to all network elements before you delete the
old manual area address.
When editing an address, you can either enter the complete address in the
Area address field or enter the individual components of the address in the
Area Address Components fields.
If you enter an Address Format ID (AFI) and Initial Domain ID (IDI) of 39840F
(either in the Area address field or the Address format ID and Initial domain ID
fields), it is recognized as the country code for the United States and the
Domain specific part (DSP) field is replaced with fields for the individual
components of the DSP. For other AFI and IDI entries in the AFI and IDI fields,
you must enter all components of the DSP in either the Area address field or
the Domain specific part (DSP) field.
Use the Delete button to delete an existing manual area address:

• A warning dialog is displayed when you attempt to delete a manual area
address allowing you to cancel the delete operation.

Table 2-15
Editable
Number •1 Displays the three possible manual area addresses. The No

•2 default for manual area address 1 is 490000.
•3
Manual Area 6 to Sets the manual area addresses. When editing an address, Yes
Address 26-hexadecimal the user can enter:
number • a free form manual area address or a manual area
address. The manual area address must be less than or
equal to 26 hexadecimal characters. The number of
characters must be even.
• the individual components of the address in the Area
Address Components fields:
— Address format ID (2 hexadecimal characters)
— Initial domain ID (4 hexadecimal characters, pad with
‘F’ hexadecimal characters if less than four characters)
— Domain specific part (up to 20 hexadecimal characters)
— DSP format ID (2 hexadecimal characters, default value
is 80)
— Organization ID (6 hexadecimal characters)
— Domain (4 hexadecimal characters)
— Area (4 hexadecimal characters).
The domain specific part field is replaced by the DSP format
ID, Organization ID, Domain, and Area fields if the Address
format ID and Initial domain ID fields are 39840F.
Calculated 6 to 26 Displays the calculated manual area addresses. No

Manual Area hexadecimal
Address number

Site Level Data Distribution (SLDD) parameters


resources.

a site. When used together with a non-OSPF routing protocol such as
integrated ISIS (IISIS), which provides the IP visibility within a site, OSPF
networks can then be segmented to allow for large scale.
The SLDD option has a single table. Use the Edit button to change the SLDD
admin state (enable/disable). When the SLDD feature is first enabled, the
ILAN interfaces will be added to the list.
The configuration should, in most cases, be set to Auto (the default value).
This forces the Site-ID to be used as the SLDD Scope ID.
In this release, SLDD is supported on the SP2 and SPAP2.
SLDD supports site level configurations with Photonic branching (maximum of

8 branches in this release).
In some special circumstances, it may be necessary to override use of the

Site-ID to a manually set Scope ID. In this case, the configuration can be set
to Manual and the SLDD Scope ID can be set to a user-defined value. The
shelves will only exchange data if they have the same Scope ID. It is
recommended to contact Ciena support if considering setting the
configuration to Manual.
Use the Add and Delete buttons to add or delete interfaces to the list of
interfaces on which SLDD will be active. This will be determined by knowing
which interfaces are used for the physical intra-site connectivity in a given site.
ILAN interfaces are added to the list by default, but can be removed if
necessary. COLAN interface(s) can also be added. Interfaces can be added
or deleted from the list regardless of the SLDD admin state.

Table 2-16
Site Level Data Distribution parameters
Editable
Admin State • Enabled Enables/disables the SLDD feature. Yes

• Disabled
Configuration • Auto (default) Selects the configuration mode for the Scope ID. Yes
• Manual Note: Select Auto (the default value) for most
configurations. This will allow the Site-ID to be used
to scope SLDD data. In some special
circumstances, it may be necessary to override use
of the Site-ID to a manually set SLDD Scope ID. In
this case, choose Manual and set the SLDD Scope
ID parameter, below. The shelves will only
exchange data if they have the same SLDD Scope
ID. It is recommended to contact Ciena support
before using a manual SLDD Scope ID.
SLDD Scope integer Sets the Site Level Data Distribution Scope ID. This Yes
ID is only required, and can only be edited, if setting
Configuration to Manual (see above). The format is
0-65535. The default is 0. This parameter is
read-only when Configuration = Auto and defaults
to the Site-ID.
Unit string Select the interface to provision for SLDD. Yes

Supported interfaces are COLAN and ILAN.
State • Active - interface Up Displays the interface’s state: No

• Unprovisioned - • Active - interface Up: the interface is fully
interface Down provisioned and the adjacency is up.
• Fault detected - • Unprovisioned - interface Down: the interface is
adjacency Down not fully provisioned, or the feature is disabled.
• Fault detected - • Fault detected - adjacency Down: the adjacency is
interface Down down.
• Fault detected - interface Down: the link (ILAN/
COLAN) is down.

Visible NE Information parameters

The Visible NE Information option is only applicable for IPv4.The Visible NE
Information option has a single table which displays all network elements that
can be reached. The table is read-only.
Each row lists the address information required to communicate with that
network element. The name column can be used to identify the network
element being queried. The Visible NE Information is a dynamic list that is
updated each time a network element or circuit is added in the network. Use
the Refresh button each time a change is made.
Table 2-17
Editable
Name Character string (up to Displays the system identifier (name) of the network No
20 characters) element.
ID ##.###.#.# Displays the id of network element. No
Protocol • OSI Displays the routing protocol used on the network No

• IP element.
Network Standard dot notation Displays the IP address of the network element. No
Address
Alternate Standard dot notation Displays the COLAN-X IP address. No

Address
MAC 12-hexadecimal Displays the MAC address of the network element. No

Address characters
Member True, False Displays whether the shelf is a member in a No
consolidated node.
Site ID Integer value Displays the provisioned site identifier. No
Type Character string Displays the network element equipment type (for No
example, 6500).
Supported • Yes Displays whether network element is supported by No
• No Site Manager (only 6500 currently supported).
Additional Character string Displays additional information. No

Information
Note: If the Static NAT feature is being used for head-ending the network, the displayed IP addresses
in Visible NE Information application are the remote IP addresses of the NEs and not the DCN IP
addresses.

IISIS Routing Table parameters

The IISIS Routing Table option has a single table which displays all network
elements that can be reached. The table is read-only.
The IISIS Routing Table supports a maximum of 150 nodes in a level 1 area.
A Routing Table Overflow alarm is raised if the 150 limit is exceeded.
Each row lists route information required to reach that network element. The
row with a cost of 0 and adjacency of 00:00:00:00:00:00 is the accessed
network element.
The IISIS Routing Table is a dynamic list that is updated each time a network
element or circuit is added in the network. Use the Refresh button each time
a change is made.
Table 2-18
IISIS Router Table parameters

Editable
Destination 12-hexadecimal Displays the MAC address of the destination element. No

characters
Adjacency 12-hexadecimal Displays the MAC address of the adjacent network No

characters element (00:00:00:00:00:00 is the accessed network
element).
Cost 0 to 1023 Displays the OSI cost values (0 is the accessed network No
element).

IP Routing Table parameters

The IP Routing Table option contain two tabs: IPV4 and IPV6. The IP versions
IPv4 and IPv6 are not compatible with each other and as a result have
completely separate (non-interacting) routing tables.
The IP Routing Table option has a single table which displays the static routing
information. The table is read-only.
The IP Routing Table is a dynamic list that is updated each time a network
a change is made.
Table 2-19
IP Routing Table parameters for IPv4

Editable
IP Subnet Standard dot notation Displays the destination IP subnet of the static entry. No
Subnet Mask Standard dot notation Displays the subnet mask of the table entries. No
Next Hop Eight groups of four Displays the IPv6 address of the next hop. No
hexadecimal digits,
separated by ':' (colon)
Cost 1 to 65535 Displays the cost of the link (Note). No
External 1 to 65535 Displays the external cost of the link (Note). No

Cost

Table 2-19
IP Routing Table parameters for IPv4 (continued)

Editable
Circuit ID • SHELF-shelf Displays the circuit identifier of the port used to get to No
• COLAN-shelf-A the next hop.
• COLAN-shelf-X
• ILAN-shelf-IN
• ILAN-shelf-OUT
• GRE-shelf-OSI-1 to 4
• LAN-shelf-15
• LAN-shelf-41
• LAN-shelf-16
• LAN-shelf-42
STM1J/STM4J/
OTMn ports
• SERIAL-shelf-X
Carrier • Section/RS Displays the carrier selected for the Section/RS DCC, No
• Line/MS Line/MS DCC and GCC circuit, or GCC0 or GCC1.
• GCC0 Only applicable to OC-n/STM-n/OTMn ports.
• GCC1
Owner • Static Displays the owner of the entry. No
• Local
• IISIS
• OSPF
Tunnel Displays the other node the tunnel is terminated on. No

Termination
Note: The metric (cost) that is advertised for an external route can be one or two types. Type 1 metrics
are comparable to the link state metric. The type 2 metrics are assumed to be larger than the cost of any
intra-AS path. In this case, the external cost value will be shown in the External Cost parameter while
the regular link state metric cost value will be shown in the Cost parameter.

Table 2-20
IP Routing Table parameters for IPv6

Editable
IP Subnet Eight groups of four Displays the destination IP subnet of the static entry. No
hexadecimal digits,
separated by ':' (colon)
Prefix 0 to 128 Specifies the IPv6 prefix. Yes
Next Hop Standard dot notation Displays the IP address of the next hop. No
Circuit ID • SHELF-shelf Displays the circuit identifier of the port used to get to No
• COLAN-shelf-A the next hop.
• COLAN-shelf-X
• ILAN-shelf-IN
• ILAN-shelf-OUT
• GRE-shelf-OSI-1 to 4
• LAN-shelf-15
• LAN-shelf-41
• LAN-shelf-16
• LAN-shelf-42
• OC-n/STM-n/
STM0J/STM1J/
STM4J/OTMn ports
• SERIAL-shelfX

Table 2-20
IP Routing Table parameters for IPv6 (continued)

Editable
Carrier • Section/RS Displays the carrier selected for the Section/RS DCC, No
• Line/MS Line/MS DCC and GCC circuit, or GCC0 or GCC1.
• GCC0 Only applicable to OC-n/STM-n/OTMn ports.
• GCC1
• Local
• IISIS
• OSPF
are comparable to the link state metric. The type 2 metrics are assumed to be larger than the cost of
any intra-AS path. In this case, the external cost value will be shown in the External Cost parameter
while the regular link state metric cost value will be shown in the Cost parameter.
OSPF Neighbors parameters

The OSPF Neighbors option has a single table which displays OSPF neighbor
The OSPF Neighbors table is a dynamic list that is updated each time
neighbor information is changed in the network. Use the Refresh button each
time a change is made.

Table 2-21
Editable
AID • COLAN-shelf-A Displays the circuit No

• COLAN-shelf-X identifier of the neighbor.
• ILAN-shelf-IN
• ILAN-shelf-OUT
• LAN-shelf-16/42
• SHELF-shelf
• CONTROL-shelf- GROUP0
• CONTROL-shelf- GROUP1
• OC-n/STM-n/STM0J/STM1J/STM4J/OTMn ports
• OTUTTP/ODUTTP/ ODUCTP AID
Adjacency • ATTEMPT Displays the neighbor No

State • DOWN adjacency status.
• EXCHANGE
• EXCHANGESTART
• FULL
• INITIALIZING
• LOADING
• TWOWAY
• OTHER
Carrier • Section Displays the DCC or No

• Line GCC channel.
• GCC0
• GCC1
Neighbor IP Standard dot notation Displays the IP address No

of the neighbor.
Neighbor Standard dot notation Displays the OSPF No
Router ID router ID of the neighbor.

Interfaces tab
ARP/ND Proxy parameters
The ARP/ND Proxy option contain two tabs: IPV4 and IPV6. The IP versions
The ARP/ND Proxy option has a single table. Use the Add button to provision
a new ARP/ND Proxy IP address. Use the Delete button to delete an existing
ARP Proxy IP address. The ND Proxy option also contains an Edit button.
Table 2-22
IPv4 ARP Proxy parameters
Editable
IP address Standard dot notation Displays the ARP Proxy IP address. No
Address range Address range, Single Determines if either an address range or a single Yes
or Single address address is added.
address
First address Standard dot notation Sets the first ARP Proxy IP address. Yes
Only applicable when Address range is selected.
Last address Standard dot notation Sets the last ARP Proxy IP address. Yes
Address Standard dot notation Enter the ARP Proxy IP address. Yes
Only applicable when Single address is selected.
Table 2-23
IPv6 ND Proxy parameters

Editable
Aid NDPROXY-<shelf>-1 to 150 Sets the index-based AID. Yes

Circuit COLAN-<shelf>-X Displays the IPv6 ND Proxy circuit. No
Only supported on COLAN-x in this
release.
IP Address Eight groups of four hexadecimal Sets the IPv6 Proxy IP address. Yes
digits, separated by ':' (colon). The full length can be used or the
reduced length version can be used
(removing the leading zeros and
the intermediate block of 0000).

ARP/ND Table parameters

The ARP/ND Table option contain two tabs: IPV4 and IPV6. The IP versions
The ARP/ND Table option has a single table which displays the dynamic
routing information. This table is read-only. The read-only ARP time out field
is displayed above the dynamic routing information table on the IPv4 tab.
Table 2-24

Editable
IPv4 ARP time 3600 Displays time in seconds before an inactive No
out entry is removed from the table.
MAC Address 12-hexadecimal characters Displays the hardware MAC address of the No
destination host.
IP Address Standard dot notation (IPv4) Displays the IP address of the destination No
or eight groups of four host.
hexadecimal digits (IPv6) For IPv6, the full length can be used or the
reduced length version can be used
(removing the leading zeros and the
intermediate block of 0000).
Unit • COLAN-shelf-A Displays the LAN interface used to connect No

• COLAN-shelf-X to the destination host.
• ILAN-shelf-IN
• ILAN-shelf-OUT
• LAN-shelf-15
• LAN-shelf- 41
• LAN-shelf-16
• LAN-shelf- 42
Type • Local Displays the IPv4 ARP entry type. Local No

• Dynamic indicates an entry associated with a
destination local to the shelf. Dynamic
• Broadcast indicates a learned entry from the network.
• Point to Point Broadcast indicates the ARP entry used
when the destination IP is the broadcast
address for a subnet.

DSM OAM Link parameters

The DSM OAM Link option has a single table. The table lists the status of the
OC-3 facilities that can host DS1TM equipment or for which DSM OAM links
can be enabled to support the hosting of DS1TM equipment.
OC-3 facilities that meet the following criteria are displayed in the table:
• have DS1TM equipment provisioned
• do not have DS1TM equipment provisioned and the lower layer DCC/GCC
is provisioned as Section DCC with LAPD and L2 frame size of 1304
• do not have DS1TM equipment provisioned and the lower layer DCC/GCC
is not provisioned
• are unprotected
OC-3 facilities that do not meet these criteria are not displayed.
Use the Enable or Disable to set the DSM OAM link status of the selected
OC-3 facility. Setting the state to Enable provisions the lower layer DCC/GCC
and IISIS circuit to the following parameters required to host DS1TM
equipment:
• lower layer DCC/GCC: Carrier = Section, Protocol = LAPD, L2 Frame Size
= 1304
• IISIS circuit: Circuit Default Metric: 6, Neighbour Protocols Supported
Override = OSI
The Enable and Disable buttons are disabled if the DSM OAM link is in use.
For information on provisioning a DSM, refer to “Procedures and options for

equipment provisioning” section in the “Equipment and facility provisioning”
chapter in Part 1 of Configuration - Provisioning and Operating,
323-1851-310.

Table 2-25
DSM OAM Link parameters
Editable
Unit OC-3 optical Displays OC-3 facilities that have: No

ports • DS1TM equipment provisioned
• do not have DS1TM equipment provisioned and the lower
layer DCC/GCC is provisioned with LAPD and Section
DCC
• do not have DS1TM equipment provisioned and the lower
layer DCC/GCC is not provisioned
State • Disabled Sets the status of the DSM OAM link. A facility is Yes
• Enabled automatically disabled if:
• no layer DCC has been provisioned on the facility or a
lower layer DCC/GCC has been provisioned as LAPD and
the L2 frame size is not equal to 1304
• the IISIS circuit is configured and the parameters are not:
— circuit default metric: 6
— neighbor protocols supported override: OSI
In Use • Yes Displays whether the facility is in use for DSM OAM comms No
• No (DS1TM equipment provisioned on the port).
GNE parameters
The GNE option contain two tabs: IPV4 and IPV6. The IP versions are
enabled/disabled/edited using the options in the IP Versions Configuration
The GNE option has a single table. The GNE pairs provide redundant DCN
comms access to remote nodes within the section. Use the Add button to
provision a new comms access and Delete button to delete an existing one.

Table 2-26
IPv4 GNE parameters
Editable
Unit SHELF-shelf Displays the access identifier (AID) of the GNE. Yes
Configuration Redundant, Standalone Defines the GNE configuration. Yes
Access • NAT Sets the DCN access mechanism to be used. Yes

• ARP
• OSPF
• Static
• Private IP
Group (Note 1 Integer value between 1 Specifies the redundancy group that the GNE Yes
and Note 2) and 255 belongs to for master/backup negotiation.
Primary • Yes Sets the GNE as being the preferred MASTER. Yes
(Note 2) • No (default)
GNE Subnet string of up to 36 Sets a unique name for the GNE. Yes
Name (Note 3) alphanumeric characters
Note 1: It does not accept ‘0’ as first digit.

Note 2: It is a mandatory parameter if configuration is on REDUNDANT and Access is on ARP,
otherwise it is not applicable.
Note 3: This parameter is only applicable to Private IP Access.
Table 2-27
IPv6 GNE parameters

Editable
AID SHELF-shelf Displays the access identifier (AID) of the GNE. Yes
Access • Static Sets the GNE access mode. Yes

• ND Proxy
• OSPFv3
Configuration Redundant, Standalone Defines the GNE configuration. Yes

GNE Port Filter parameters

The GNE Port Filter option has a single table. Use the Add button to provision
a new GNE port filter and Delete button to delete an existing one.
Table 2-28

Editable
AID PORTFILTER-shelf-1 to 10 Sets the access identifier (AID) of the GNE Yes
port filter.
Protocol TCP Sets the protocol of the destination port, Yes

UDP
Drop Port 1 to 65535 Sets the destination port, Yes
Access • ON (default) Determines whether the COLAN-X access Yes

COLAN-X • OFF filter is on or off,
Access • ON Determines whether the COLAN-A access Yes

COLAN-A • OFF (default) filter is on or off,
GRE parameters
The GRE option has a single table. Use the Add button to provision a new
static tunnel. Use the Delete button to delete an existing static tunnel. This
option is only applicable for IPv4.
Table 2-29
GRE parameters

Editable
Unit • GRE-shelf-IP-1 to 4 Displays the possible static tunnel configurations (four Yes
• GRE-shelf-OSI-1 to for each network layer protocol, IP or OSI).
4

Table 2-29
GRE parameters (continued)

Editable
Source Standard dot notation Sets the IP address of the source device on the tunnel. Yes
Address (IP) Note: Only applicable to GRE-shelf-IP-1 to 4. Not
applicable to GRE-shelf-OSI-1 to 4.
Destination • Standard dot Sets the IP or OSI address of the destination device on Yes
Address notation (IP) the tunnel (Note).
• NSAP (OSI)
Note: The NSAP is up to 40 characters depending on the first 2 characters (AFI). For example, for an
AFI of 49, the range is 20 characters (6 characters for area address, 12 characters for system id, and 2
characters for network selector). The network selector (NSEL, last 2 bytes of NSAP) of the provisioned
NSAP destination address must be set to ‘00’ (6500 internally automatically sets the NSEL to support
the required transport service).

IP parameters
The IP option contains two tabs: IPv4 and IPv6. The IP versions are enabled/
disabled/edited using the options in the IP Versions Configuration service type
(Services tab).
The IP option has a single table which displays all the provisioned ports. Use
the:
• Add button to add an entry
• Delete button to delete an existing entry
• Edit button to edit the parameters of an existing entry
Note 1: Make sure the shelf IP address is different from the loopback
interface IP address configured through the SAOS CLI.
Note 2: Following an edit of the Control IP address on the primary shelf,
all member shelves of the TIDc must also be restarted. Otherwise, an
OSRP “Remote Node Unreachable” alarms can be raised against OSRP
links passing through these member shelves.
Note 3: ADJPEER provisioning allows one OTS to have multiple “virtual”
neighbors. In some cases, IP addresses become stale when downstream
neighbor nodes are updated. These stale IP addresses can be removed
from the database. Contact Ciena technical support for assistance if you
are editing the shelf IP address of a submarine Branching Unit (BU) link
with ADJPEERs facilities.
An IP entry is automatically added or deleted for an OCn/STMn/OTMn port or

an OTUTTP/ODUTTP/ODUCTP AID when the associated PPP DCC/GCC
entry is added or deleted.

Table 2-30
IPv4 parameters
Editable
Unit • SHELF-shelf Displays the provisioned ports. SHELF is the Yes

• COLAN-shelf-A circuitless IP.
• COLAN-shelf-X When adding an IP, the Add IP Parameters dialog box

lists the ports that are provisioned but do not have IP
• ILAN-shelf-IN addresses (optical ports with LAPD facilities are not
• ILAN-shelf-OUT listed). If all the provisioned ports have IP addresses,
• LAN-shelf-15 an error message is displayed and the Add IP
Parameters dialog box is not displayed. If you select
• LAN-shelf-41 Apply in the Add IP Parameters dialog box and you
• LAN-shelf-16 are adding an IP address to the last provisioned port
• LAN-shelf-42 without an IP address, the Add IP Parameters dialog
box closes.
• SERIAL-shelf-X
An IP address of 0.0.0.0 is assigned to OC-n/STM-n/
• CONTROL-shelf- STM0J/STM1J/STM4J/OTMn ports or OTUTTP/
GROUP0 ODUTTP/ODUCTP AID automatically when PPP
• CONTROL-shelf- DCC/GCC is enabled and the circuit is created.
GROUP1
• OC-n/STM-n/ STM0J/
STM1J/ STM4J/
OTMn ports
• OTUTTP/ODUTTP/
ODUCTP AID
Carrier • Section/RS Selects the DCC/GCC carrier. Yes
• Line/MS Only applicable to OCn/STMn/OTMn ports and
• GCC0 OTUTTP/ODUTTP/ODUCTP AID.
• GCC1
IP Address Standard dot notation Sets the IP address for the selected port. Yes
Broadcast Standard dot notation Displays the IP broadcast address derived from the IP No
Address address and the subnet mask. Read-only.
Netmask Standard dot notation Sets the subnet mask for the selected port. Yes
SHELF netmask must be 255.255.255.255.
For the LAN-shelf-15/41 and LAN-shelf-16 (or 42)
ports, the netmask is restricted to 255.255.255.252.
For un-numbered ILAN, the netmask is restricted to
255.255.255.255.
Default 1 to 255 (default 90) Sets the number of hops before a packet is dropped. Yes
Time to Live (Note)

Table 2-30
IPv4 parameters (continued)

Editable
Host Only The Host Only Mode option is displayed in Site

Mode Manager, but is not supported in this release.
Non-routing • On Sets the non-routing mode. When on, routing updates Yes
Mode • Off (default) are not propagated but packets are forwarded
through the interface.
ARP Proxy • On Sets the support for proxy ARP on the interface. Yes
• Off (default) This parameter is only visible when the Unit (facility
AID) is COLAN-X.
Network Management Displays the network domain. No

Domain Communications
Network
Note: It is only editable for SHELF AID in Add and Edit dialog in this release. Not editable for other AID.
Table 2-31
IPv6 parameters

Editable
AID IPADDR-<shelf>-1 to Displays the index-based AID of the IPv6 address. No

256
Circuit Pull-down menu Specifies the interface associated to which the IPv6 Yes
address is assigned.
Carrier • Section/RS Selects the DCC or GCC channel. The options Yes
• Line/MS depend on the circuit pack type and function.
• GCC0
• GCC1
IP Address Eight groups of four Specifies the IPv6 address. Yes
hexadecimal digits,
separated by ':'
(colon)
Prefix 0 to 128 Specifies the IPv6 prefix. Yes

LAN parameters
The LAN option has a single table which displays all the provisioned LAN
ports. Use the:
Note 1: Do not add IISIS circuits or OSPF circuits to LAN ports

provisioned with the non-routing mode set to On.
Note 2: If the port configuration is set to 100BT for the WSC port, the
actual traffic rate over the wayside channel should not exceed 40Mb/s. If
the 6500 detects that the traffic rate exceeds this, wayside traffic is
rate-limited to avoid OSC link congestion.
Table 2-32
LAN parameters

Editable
Unit • LAN-shelf-15/41 Select the provisioned LAN ports. LAN-shelf-15/41 Yes

• LAN-shelf-16/ 42 is the craft LAN port on the shelf processor in slot
15/41 and LAN-shelf-16 (or 42) is the craft LAN port
• COLAN-shelf-A on the shelf processor in slot 16 (or 42).
• COLAN-shelf-X WSC-shelf-slot-3 and WSC-shelf-slot-4 are on the
• ILAN-shelf-IN 2xOSC or SPAP-2 w/2xOSC card. Remaining ports
are located on the access panel.
• ILAN-shelf-OUT
• WSC-shelf-slot-3
• WSC-shelf-slot-4
Configuration • Automatic (default) Sets the port configuration for each provisioned Yes
(Note) • Half duplex 10BT LAN port. Half duplex 10BT is Half-Duplex 10 Mbit/
s, Half duplex 100BT is Half-Duplex 100 Mbit/s, Full
• Half duplex 100BT duplex 10BT is Full-Duplex 10 Mbit/s, Full duplex
• Full duplex 10BT 100BT is Full-Duplex 100 Mbit/s, and Automatic is
• Full duplex 100BT auto-negotiation.
Negotiated • Half duplex 10BT Displays the provisioned or negotiated port No

Configuration • Half duplex 100BT configuration.
• Full duplex 10BT

• Disconnected
MAC Address 12-hexadecimal Displays the unique MAC address assigned to the No
characters LAN port.

Table 2-32
LAN parameters (continued)

Editable
Port • ENABLED Displays whether the LAN port is enabled or No

• DISABLED (default) disabled.
For LAN ports provisioned as WSC ports “-” is
displayed
WSC Enabled • unchecked (default) Sets whether the Wayside channel is enabled No
• checked (checked) or disabled (unchecked) on the LAN port.
Enabling WSC provisions the LAN port as a WSC
port. This selection is made in the Add dialog.
Note: Only applies to D-Series and S-Series
shelves. Refer to “WLAi submarine wayside
channel (not applicable to T-Series)” on page 1-34
for further details.
Note: If you set the LAN port configuration to Automatic (default), auto-negotiation is enabled.
Auto-negotiation automatically senses the speed/mode settings of the link. Use a straight-through when
connecting a PC to LAN-shelf-15/41 or LAN-shelf-16 (or 42). Use a cross-over cable to connect 6500
NEs together with ILAN. Use a straight-through when connecting COLAN port to the LAB LAN (It is
subject to change depending on what is connected to and what is configured). For WSC ports, the
default is Full duplex 10BT, and both 10BT and 100BT (Half or Full duplex) are supported. If the WSC
port is set to 10BT, the green and amber LED will be active. If set to 100BT, only the amber LED will be
active. If the port configuration is set to 100BT for the WSC port, the actual traffic rate over the wayside
channel should not exceed 40Mb/s. If the 6500 detects that the traffic rate exceeds this, wayside traffic
is rate-limited to avoid OSC link congestion. Refer to the 6500 Packet-Optical Platform Photonic Layer
Guide, NTRN15DA for details.

Lower Layer DCC/GCC parameters

The Lower Layer DCC/GCC option provides a single table which displays the
DCC/GCC parameters for any OC-n/STM-n/STM0J/STM1J/STM4J/OTMn/
OTUTTP/ODUTTP/ODUCTP/FTTP facilities which have a lower layer DCC/
GCC provisioned.
For information on GCC support on the circuit packs, refer to Table 2-33 on
page 2-81.
When the ODUk layer is terminated, the GCC1 overhead is terminated

whether the GCC1 channel is provisioned or not. When the ODUk layer is
monitored or transparent, the GCC1 overhead is passed through
transparently if the GCC1 channel is not provisioned.
Use the Add button to provision new DCC/GCC circuits and the Delete button
to delete existing DCC/GCC circuits. The Edit button is only enabled for
editing the LAPD parameters.
When adding/editing a DCC/GCC circuit, consider the following:

• A maximum of two Line/MS DCC circuits are supported on each 8xOC-3/
12/STM-1/4 circuit pack.
• On the (2+8)xOC-n/STM-n circuit pack, 8 x SDCC/RS DCC and 8 x LDCC/
MS DCC are available on the OCn/STMn facilities. Port 1 and Port 3 and
Port 2 and Port 7 share the same SDCC/RS DCC and LDCC/MS DCC as
both ports cannot be provision at the same time.
• Each end of the DCC/GCC circuit must be provisioned with the same
options.
• When adding a DCC circuit, the L2 Frame Size and L2 Side Role fields
only become available when the LAPD option is selected.
• When adding a DCC circuit, the Mate field only become available when
the Transparent option is selected.
• Once a new DCC/GCC circuit has been added, an IISIS or OSPF circuit
must be added for this port (except for a transparent DCC). See “IISIS
Circuit parameters” on page 2-35 and “OSPF Circuit parameters” on
page 2-44.
• You must delete the IISIS or OSPF circuit for the DCC/GCC circuit before
deleting the DCC/GCC circuit.
• To edit the DCC/GCC parameters (other than the L2 Side Role
parameter) for a Wayside LAN facility, you must delete the existing entry
and create a new one with the required values.

• For OTMn ports (except for OTM2 ports on 1xOC-192/STM-64,

2x10G OTR, or SuperMux circuit packs, and OTM3 ports on 40G OCI
circuit packs), a GCC0 or GCC1 PPP circuit (with IP address of 0.0.0.0)
and an associated IISIS or OSPF circuit are automatically created when
the OTMn facility is provisioned if the default auto GCC0 mode or GCC1
mode parameter is set to IISIS or OSPF in the System tab of the Node
Information application and if the Shelf IP has been provisioned on the NE.
If not already created, an IISIS router or OSPF router is also created.
• For OTUTTP ports, a GCC0 circuit and an associated IISIS or OSPF
circuit are automatically created when the OTUTTP facility is provisioned
if the default auto GCC0 mode parameter is set to IISIS or OSPF in the
• For the 2x10G OTR, the GCC1For the 2x10G OTR, the GCC1 is only
auto-created on the OTM2 connection facing facility. An OTM2 connection
facing facility is auto-created against port 2 or port 4 when creating a
non-OTM2 facility. For example, if port 2 is provisioned as an ETH10G
facility, port 2 will also auto-create an OTM2 layer facility and GCC1 will be
provisioned against that facility if the default auto GCC1 is enabled. See
“Rules for the 2x10G OTR circuit packs” section in the “Equipment and
facility provisioning” chapter in Part 1 of Configuration - Provisioning and
Operating, 323-1851-310, for more information.
• For IPv4, adding or deleting a lower layer DCC/GCC entry with its Protocol
parameter set to PPP, automatically adds or deletes an associated PPP
circuit with IP address of 0.0.0.0.
• You cannot edit the LAPD frame size if the DSM OAM Link status of an
OC-3 facility is Enabled.
• For host OC-3 ports used for connecting to a DSM, a DCC circuit is
automatically added/deleted when enabling/disabling a DSM OAM link
(see “DSM OAM Link parameters” on page 2-69).
Note: If a GCC1 link is provisioned on the OTM3 mapping facilities

between two 40G MUX (NTK525CF variant) circuit packs, an OOS of the
OTM3 mapping facility at one end will cause the GCC1 link disconnected.
A GCC1 Link Fail alarm may be raised on the other end.

For in-band communication between OSRP nodes, each facility on which

OSRP is enabled requires the Line/MS DCC or GCC1/GCC2 channel to be
allocated for Layer 1 control plane communications (neighbor discovery,
topology discovery, routing and signaling). This LDCC or GCC channel
requires the following parameters and settings:
• Carrier = Line/MS or GCC1/GCC2
• Network Domain = SONET/SDH Control Plane or OTNCP
• Protocol = LAPD (automatically set for the SONET/SDH Control Plane
network domain) or PPP (automatically set for the OTN CP network
domain)

required on the LDCC or GCC channel for OSRP communications.

instances, the Section DCC (SDCC) channel must be used (Network
Domain = MCN), as control plane and OAM communications do not share the
same channel.
If network domain is OTNCP, the OTUk rate must be 2, 3, 3E2, or 4.
For more information about the Layer 1 control plane communications, refer
to Part 2 of 6500 Packet-Optical Platform Control Plane Application Guide,
NTRN71AA.
Table 2-33
GCC support on circuit packs
Circuit Packs GCC0 GCC1 GCC2

(Note 1)
10GWT and 10GELWT (Note 2) X X

10GOTNWT (Note 3) X
2x10G OTR (Note 4, Note 5, and Note 6) X X
4x10G OTR (Note 7) X X X
10G OTR (Note 8 and Note 9) X X
10G OTSC (Note 9) X X
SuperMux (Note 2 and Note 10) X X

2.5G MOTR (Note 11) X X
40G MUX OCI (Note 12) X X X
L2 MOTR (Note 13) X X

Table 2-33
GCC support on circuit packs (continued)

(Note 1)
Flex MOTR (Note 14) X X

8xOTN Flex MOTR and (1+8)xOTN Flex MOTR (Note 15) X X
2xCFP2 OTN Flex MOTR (Note 16) X X
40G XCIF (Note 12) X
40G OCI (Note 18) X X X
40G OCLD/Wavelength-Selective 40G OCLD (Note 17) X X
40G ULH OCLD (Note 17) X
100G OCLD or 100G WL3/WL3e OCLD (Note 20) X
Flex2 WL3/WL3e OCLD/Flex3 WL3e OCLD (Note 21) X
Flex4 WL3e OCLD (Note 22) X
10x10GE MUX, 10x10G MUX, and 100G (2xQSFP+/2xSFP+) MUX X X

(Note 23)
100G WL3n MOTR (Note 24) X X
100GE OCI (Note 25) X
100G OCI (Note 26) X X

100G WL3e OTR (Note 26) X X
(2+8)xOC-n/STM-n (Note 19) X X
40G OTN XCIF (Note 27 to Note 29) X X
16xFLEX OTN I/F (Note 27 to Note 29) X X
4x10G Packet I/F (Note 27 to Note 28) X X
eMOTR (Note 27 to Note 28) X X
10x10G PKT/OTN I/F X X X
100G PKT/OTN XCIF X X
200G (2x100G/5x40G) MUX) (Note 30) X

100G WL3n OTR (Note 31) X X
• WLAi MOTR (Note 32) X X

• WLAi MOTR w/OPS (Note 32)

Table 2-33

(Note 1)
• WLAi FOTR X X
• WLAi FOTR w/OPS
Note 1: GCC2 is supported in the OTNCP domain. Supported on the OTU2 facilities on 40G MUX OCI
and 10x10G PKT/OTN I/F, OTU3 facilities on the 40G OCI and 40G OCLD/Wavelength-Selective 40G
OCLD, and OTU4 facilities on the 100G PKT/OTN XCIF. GCC2 is also supported in the ENCRYP
domain for OTM2 client facilities on 4x10G OTR (NTK530QE variant) when the encryption mode is
segregated.
Note 2: Supported on the line OTM2 facility of the circuit packs (port 1).
Note 3: GCC0 supported on line OTM2 port (port 1). GCC1 on client OTM2 port (port 2) are passed
through transparently.
Note 4: GCC0 can be provisioned and monitored on ports 1 to 4 when their facility type is OTM2.
Note 5: GCC1 can be provisioned and monitored on ports 2 and 4 when their facility is provisioned as
mapped non-OTM2. There is an OTM2 connection facility (facing the line side) that is auto-created
against port 2 (or port 4) when a mapped non-OTM2 is provisioned. It is this connection facing facility
that GCC1 is provisioned against. See “Rules for the 2x10G OTR circuit packs” section in the
“Equipment and facility provisioning” chapter in Part 1 of Configuration - Provisioning and Operating,
323-1851-310, for more information.
Note 6: OTM2 out of service (OOS) on the line port (1 or 3) will cause GCC1 loss on the associated
client port (2 or 4). However, GCC0 is still functional.
Note 7: GCC0 is supported on the OTM2 line facilities. GCC1 is supported on the OTM2 mapping layer
facilities. In the OTU2 regeneration configuration (applicable to the NTK530QM/QE variants), GCC0 is
also supported on the OTM2 client ports.
Note 8: With 10G and 10GE clients, GCC0 and GCC1 supported on the line OTM2 facility of the circuit
packs (port 1).
Note 9: With OTM2 clients, GCC0 supported on line OTM2 port (port 1). GCC1 on client OTM2 port
(port 2) is passed through transparently.GCC1 supported on the line OTM2 facility (port 1). GCC0
supported on the line and client OTM2 facility (port 1 and port 2).
Note 10: The GCC0/GCC1 system default does not apply to SuperMux.
Note 11: GCC1 and GCC0 supported on the OTM2 port (port 1) and GCC0 supported on the OTM1
client port (port 2 to port 5).
Note 12: GCC1 supported on the OTM3 mapping layer facility (port 100). GCC0 supported on the
OTM2 client facilities (ports 1 to 4). Cannot provision OTM3 GCC1 on 40G MUX OCI (NTK525CF
variant) if DM is enabled on port 100 OTM3 or TCMCTP, and vice versa.
Note 13: Limit of two total GCC ports shared between two OTM2-configured line ports.
Note 14: Supported on the OTM2 line facilities (port 1 and port 2).
Note 15: Supported on the OTM1 and OTM2 line facilities.

Table 2-33

(Note 1)
Note 16: GCC0 cannot be enabled for an OTU interface on port 41 or port 42 of the 2xCFP2 OTN Flex
MOTR circuit pack if there is a facility loopback active on the port. For details on releasing the loopback,
refer to the “Operating/releasing a loopback” procedure in Part 1of Configuration - Provisioning and
Operating, 323-1851-310.
Note 17: Supported on the OTM3 line facility (port 1).
Note 18: GCC1 supported on the OTM3 mapping layer facility (port 1). GCC0 supported on the OTM3
client facility (port 1) on the 40/43G OCI and 40G+ CFP OCI circuit packs.
Note 19: 2 x GCC0 and 2 x GCC1 are available on the OTM2 of the (2+8)xOC-n/STM-n OTN 20G.
Note 20: Supported on the line OTM4 facility (port 1).
Note 21: Supported on the line OTM4/OTMC2 or OTUTTP facility (port 1). When in BPSK mode, GCC0
is provisioned on the prime OTM4 or OTUTTP facility only.
Note 22: GCC0 supported between Broadband interfaces.
Note 23: GCC1 supported on the virtual aggregate OTM4 facility (port 100). GCC0 supported on the
OTM2 client facility on the 10x10G MUX OCI.
Note 24: GCC1 supported on the OTM3 mapping facility (port 104 or 108). GCC0 supported on the
OTM4 line facility and OTM2 client facilities.
Note 25: Supported on the OTM4 mapping facility.
Note 26: GCC0 supported on the OTM4 client facility. GCC1 supported on the OTM4 mapping facility.
Note 27: GCC0 is provisioned on OTUTTP.
Note 28: GCC1 is provisioned on ODUTTP or ODUCTP if network domain is MCN. The ODU facility
must exist before GCC1 can be provisioned. GCC1 is not supported on the eMOTR backplane
ODU2TTP.
Note 29: GCC1 is provisioned on OTUTTP (single card) or FTTP (dual card) if network domain is
OTNCP. The ODU facility does not need to exist before GCC1 is provisioned.
Note 30: GCC1 is supported on OTM3 facilities (all ports except port 3) and OTM4 facilities (port 100).
Note 31: GCC0 is supported on OTU4 line. GCC1 is supported on the OTM4 mapping layer facility
associated to the ETH100G client port.
Note 32: GCC0 supported on OTUTTP line port 1, OTUTTP client facility ports 2-5. GCC1 supported
on ODUTTP line port 1, ODUCTP facility on ports 2-5.

Table 2-34
Editable
Name OC-n/STM-n/STM0J/ Displays all the provisioned OC-n/STM-n/STM0J/ Yes

STM1J/STM4J/ STM1J/STM4J/OTMn/OTUTTP/ODUTTP/
OTMn/OTUTTP/ ODUCTP/FTTP ports in the Add dialog. This
ODUTTP/ODUCTP/ parameter appears only in the Add Lower Layer
FTTP ports DCC/GCC Parameters dialog box.
Unit • OC-n/STM-n/ Displays the AID of the provisioned DCC/GCC link. No

STM0J/STM1J/
STM4J/OTMn-shelf-
slot-port
• OTUTTP/ODUTTP/
ODUCTP/FTTP AID
Carrier • Section/RS Selects the carrier for the Section/ DCC, line DCC Yes
• Line/MS and GCC circuit.
• GCC0 GCC2 and EXT only apply to ODUTTP facilities for

WSC ports.
• GCC1
• GCC2
• EXT
Operation • Section/RS Displays the status of the DCC/GCC circuit. No

Carrier • Line/MS
• GCC0
• GCC1
• Disconnected
Network • MCN (default) Indicates the communications network domain. Yes or No

Domain • SONET/SDH MCN for management communications network, depends on
Control Plane SONET/SDH Control Plane or OTNCP for OSRP facility and
control plane network, wayside Channel for WSC carrier
• OTNCP LAN facility.
• Wayside Channel Wayside Channel is displayed only when an
ODUTTP facility carrier is set to GCC2 or EXT.
Protocol • LAPD Select the LAPD, NDP, PPP, or Transparent radio Yes or No
• NDP button to set the protocol of the DCC/GCC circuit. depends on
OTMn/OTUTTP/ODUTTP/ODUCTP/FTTP ports facility and
• PPP (default) support PPP only. carrier
• Transparent NDP is only supported for interop between 6500
and 4200/CoreDirector (or older releases of 5400).

Table 2-34
Lower Layer DCC/GCC parameters (continued)

Editable
LAN Port • COLAN-shelf-A Select the LAN port for the Wayside channel on the No
• COLAN-shelf-X ODUTTP facility (only applicable to Wayside
Channel).
• ILAN-shelf-IN
Note: COLAN-A on 14-slot shelves can only
• ILAN-shelf-OUT be provisioned for wayside use if SP
redundancy is not provisioned.
L2 Frame • 512 to 1492 (default Sets the LAPD frame size (only applicable to Yes for
Size 1304) for MCN LAPD). MCN
• 9000 for SONET/ CAUTION No for
SDH Control Plane Each end of the DCC circuit must be provisioned SONET/
and OTNCP with the same LAPD frame size. Defaults on SDH
different equipment types may be different. Control
Plane and
OTNCP
L2 Side Role Automatic Displays the LAPD link mode (only applicable to No
LAPD).
Operation L2 • Network Displays the availability of L2 side role when adding No
Side Role • User a DCC/GCC circuit (only applicable to LAPD).
• Disconnected
Mate OC-n/STM-n/STM0J/ Sets the Mate DCC (another OCn/STMn/STMnJ Yes

STM1J/STM4J optical port) for the transparent DCC (only
applicable to the Transparent option).
FCS Mode • 16 bit (default) Sets the frame check sequence (FCS) mode. Only Yes
• 32 bit applicable to the Transparent protocol or the PPP
protocol when the carrier is Section/RS or Line/MS.
NDP parameters
The NDP option has a single table which displays the NDP provisioning
information. The administration state of the NDP feature is displayed in the
Admin State field above the table.
Use the Edit button to edit the Admin state to enable or disable the NDP
feature on the shelf. The Shelf IP must be provisioned before you can enable
the NDP feature on the shelf. Use the Add button to enable NDP on an OTMn,
ODUTTP, or OTUTTP facility. Use the Delete button to disable NDP on an
OTMn, ODUTTP, or OTUTTP facility.

Table 2-35
NDP parameters
Editable
Admin State • Disabled (default) Displays the administration state of the NDP feature. Yes
• Enabled
Unit • OTMn-shelf-slot- Displays the OTMn, ODUTTP, or OTUTTP facility AID. Yes
port
• OTUTTP AID
• ODUTTP AID
Carrier • GCC0 Displays the carrier. Yes

• GCC1
PPP parameters
The PPP option has a single table which displays entries for the ports
configured for PPP. Use the Edit button to edit the PPP magic number support
parameter.
Table 2-36
PPP parameters

Editable
Unit • SERIAL-shelf-X, OC-n/ Displays the RS-232 serial ports and optical No
STM-n/STM0J/ ports available for PPP. SERIAL-shelf-15/41 is
• STM1J/STM4J/OTMn on the shelf processor.
ports
• OTUTTP/ODUTTP/
ODUCTP AID
Carrier • Section/RS Selects the carrier for the Section/RS DCC, Line/ Yes
• Line/MS MS DCC and GCC circuit, or GCC0 or GCC1.
• GCC0 Only applicable to OCn/STMn/OTMn ports and

OTUTTP/ODUTTP/ODUCTP AID.
• GCC1
Frame Size 64 to 4470 (default 1500) Displays the PPP frame size. No
Negotiated 64 to 4470 Displays the negotiated frame size. Read-only. No

Frame Size

Table 2-36
PPP parameters (continued)

Editable
Preferred • 16 bits (default) Displays the preferred frame checksum value. No

Frame • 32 bits
Checksum
• Off
Magic • On Sets whether magic number is supported on the Yes

Number • Off (default) PPP circuit. The magic number is used for
Support detecting links that are in the looped-back
condition.
Security Type Off (default), CHAP, PAP Displays the security used on the PPP circuit. No
Local Secret Up to 253 character string Displays the local secret when the Security type No
is CHAP or PAP.
Remote Up to 253 character string Displays the remote secret when the Security No
Secret type is CHAP or PAP.
IP Header • On Displays the IP header compression status. No

Compression • Off (default)
Heartbeat • On (default) Displays whether heartbeat generation and No

• Off detection is supported.
Peer IP Standard dot notation Displays the IP address of the remote end No
Address device.
Serial/RS-232 parameters
The Serial/RS-232 option has a single table which displays information on the
serial ports. The table is read-only.
Note: It is recommended that the serial port on a PC connected to the

6500 is set to either 9600 or 19200.

Table 2-37
Editable
Unit • SERIAL-shelf-16 (or 42) Displays possible RS-232 serial ports. No

• SERIAL-shelf-X
Protocol • Auto (default) Displays the protocol for the serial port. No
• PPP
• VT100
Protocol • 60 to 3600 (default 300) Displays the period of inactivity before a No

Timeout PPP configured serial port reverts to the
default mode.
Negotiated • 60 to 3600 Displays the negotiated protocol. No

Protocol • Disconnected For this release, Disconnected is displayed
irrespective of the negotiated protocol.
Baud Rate • 9600 Displays the baud for the serial port. No
• 19200
• 38400
• 57600
• 115200
• Auto (default)
Negotiated • 9600 Displays the negotiated baud. No

Baud Rate • 19200 For this release, Disconnected is displayed
• 38400 irrespective of the negotiated baud.
• 57600
• 115200
• Disconnected
Data Bits •4 Displays the number of data bits. No

•5
•6
•7
• 8 (default)

Table 2-37
Serial/RS-232 parameters (continued)

Editable
Parity • None (default) Displays the parity. No

• Odd
• Even
• Mark
• Space
Stop Bits • 1 (default) Displays the number of stop bits. No

• 1.5
•2
Hardware • On Displays whether hardware flow control is No

Flow Control • Off (default) used.

TL1 Gateway Connections parameters

The TL1 Gateway Connections option has a single table which displays
information on the TL1 Gateway Connections. The table is read-only.
Table 2-38

Editable
NE Name string Displays the TID of the RNE. No

Session 1 to 18 A unique number assigned by the system to identify the user No
telnet session.
Status • UP Displays the status of the TL1 gateway connection. No

• DOWN • UP – the connection to the RNE is up
• DOWN – the connection to the RNE is down
Protocol • ISO Displays the protocol used by the TL1 gateway to access the No
• INET RNE.
• ISO – 7 layer OSI protocol
• INET – TCP/IP protocol

USB parameters
The USB option has a single table which displays status of the USB ports.
Use the:
• Unmount button to safety remove a USB external storage device from the
selected USB port.
• Mount button to mount a USB device on a specific USB port.
• Edit button to turn automount on/off for the selected USB port
.
Table 2-39
USB parameters

Editable
Unit/Name • USB-shelf-slot-1 Displays the USB port ID. The slot number is the SP2 No
• USB-shelf-slot-2 slot number.
Automount • ON Specifies whether to automount a USB device when Yes

• OFF connected to a USB port.
Status • Mounted Displays the status of the USB port. No

• Unmounted
• Empty
Failure See description Displays the description of the failure if the USB device No
Description is failed:
• USB Ok
• Host Error Condition
• USB Not Supported
• Failure During Mount
• USB Disabled

Services tab
Database Replication Service
The Database Replication Service (DBRS) provides a service to replicate AR/
TR data between independent OSPF networks. It allows for the deployment
of smaller, less complex OSPF networks while maintaining 6500 applications
such as Topology.
Note 1: DBRS cannot be put across two OSPF networks that have the
same OSIDs. In this case, you must edit one of the OSIDs to ensure that
each network has a unique OSID.
Note 2: When reconfiguring from a DBRS configuration to an OSPF
configuration, you must wait 60 minutes after disabling DBRS
(Procedure 2-2, “Editing the communications settings”) before
provisioning the OSPF circuit (Procedure 2-6, “Adding a new entry in the
communications settings”).
Table 2-40
Database Replication Service parameters

Editable
Unit • COLAN-shelf-A Displays the possible database ports. No

• COLAN-shelf-X
• ILAN-shelf-IN
• ILAN-shelf-OUT
Database • Topology resolution Displays the type of the database resolution. No

• Address resolution
State • Enabled Displays the state of the database replication. Yes

• Disabled This parameter can only be enabled if the Opaque
Filter parameter is disabled for the OSPF router.

DHCP parameters
The DHCP option has a single table with a single entry.
Use the Edit button to edit the DHCP parameters.
Table 2-41
DHCP parameters

Editable
Unit • LAN-shelf-15 Displays the LAN port available for the No

• LAN-shelf-41 DHCP.
• LAN-shelf-16
• LAN-shelf-42
IPv4 Server • Enabled (default) Sets the status of the DHCP IPv4 Yes
• Disabled server on the craft LAN port.
IPv6 Server • Enabled Sets the status of the DHCP IPv6 Yes
• Disabled (default) server on the craft LAN port.
DHCP Relay Agent parameters

The DHCP Relay Agent option has a single table with a single entry.
Use the:
• Add button to add a DHCP Relay Agent server.
• Edit button to edit the DHCP Relay Agent mode.
• Delete button to delete the DHCP Relay Agent server.
• DHCP RA Stats button to open the DHCP RA server statistics window.

Table 2-42
DHCP Relay Agent parameters
Editable
Mode • Off (default) Displays the DHCP RA mode. Yes (edit only)
• Manual If mode is set to Manual, DHCP RA
• Auto interfaces are set manually (refer to
“DHCP RA Interfaces parameters” on
page 2-95).
AID DHCPRASRVR-shelf-1 Displays the DHCP RA server AID. Yes (add only)
IP Address Standard dot notation Displays the IP address of the DHCP RA Yes (add only)
server.
DHCP RA Interfaces parameters

The DHCP RA Interfaces option has a single table which displays the DHCP
RA Interfaces.
Use the Add button to add a DHCP Relay Agent interface and the Delete
button to delete the DHCP Relay Agent interface. These actions are only
allowed when the DHCP RA mode is 'Manual'.
Table 2-43
DHCP RA Interfaces parameters
Parameter Options Description Addable
AID DHCPRA-shelf-1 to 20 Displays the AID of the DHCP RA Yes

interface.
Circuit • COLAN-shelf-A (default) Displays the interface used for the Yes
• COLAN-shelf-X DHCP RA interface.
• ILAN-shelf-IN
• ILAN-shelf-OUT
• OSC-shelf-slot-port
Plain RA • ON Displays whether plain RA is on or off. Yes
• OFF (default)

FTP parameters
The FTP option has a single table with a single entry. Use the Edit button to
edit the FTP parameters.
Table 2-44
FTP parameters

Editable
Server • Disabled (default) Sets the status of the ftp server. Yes
• Enabled
Maximum 8 Displays the maximum number of concurrent FTP No

number of FTP sessions that are allowed to the network element.
sessions
Idle timeout 1 to 900 (default 180) Sets the time (in seconds) before an idle ftp Yes
(seconds) session is disconnected.
NETCONF parameters
The NETCONF option has a single table with a single entry. Use the Edit
button to edit the NETCONF parameter.
Table 2-45
NETCONF parameters

Editable
State • Enabled Sets whether NETCONF is enabled or disabled. Yes

• Disabled (default)
HTTP/HTTPS parameters
The HTTP/HTTPS option has a single table with a single entry. Use the Edit
button to edit the HTTP/HTTPS parameter.
Table 2-46

Editable
HTTP server • Enabled (default) Sets the status of the HTTP protocol access. Yes
• Disabled
HTTPS server • Enabled (default) Sets the status of the HTTPS protocol access. Yes
• Disabled

IP Version Configuration parameters

This release supports IPv4 and IPv6 addresses.
Use the Edit button to edit the IP Version Configuration parameters listed in
Table 2-47 on page 2-98. The editable IP Version Configuration parameters
may be configured per shelf.
The IPv4 addresses and IPv6 addresses work independently and

simultaneously.
The IPv6 version setting must be turned on before the corresponding IPv6
provisioning commands will be accepted. For example, to provision an IPv6
address (in the Site Manager or TL1), IPv6 must be turned on. Before
disabling IPv6, the IPv6 provisioning must be deleted. IPv6 is not supported
on CPL.
The IPv4 Version setting does not need to be turned on before the
corresponding IPv4 provisioning commands will be accepted. The IPv4
Version setting has an administrative enable/disable option. This setting only
determines if the IPv4 options are displayed/available in Site Manager. The
provisioned IPv4 settings do not need to be removed before administratively
disabling IPv4.
The following rules apply. For more information, refer to Chapter 1, “Data
communications planning”.
• IPv6 is supported on SP2 and SPAP2. IPv6 is not supported on SP1,
SPAP1, or any trib cards, including OTN/PKT/eMOTR.
• A 6500 NE with SP2 and SPAP2 supports dual stack and therefore IPv4
and IPv6 can be enabled simultaneously.

Table 2-47
IP Version Configuration parameters

Editable
IPv4 Status • Administrative Enable Enables/disables the ability to make Yes

(default) provisioning changes to IPv4.
• Administrative Disable
IPv6 Status • ENABLE Enables/disables IPv6. IPv6 can only be Yes

• DISABLE (default) disabled if all IPv6 provisioning is
removed.
IPv6 Hop Limit • 1-255 Sets the IPV6 hop limit. Yes
• Default is 90.
IPv6 Capability • YES Indicates if this network element type No

• NO supports IPv6.
LinkLocal parameters
The LinkLocal option has a single table which displays the IPv6 Link Local
addresses for all interfaces. The table is read-only and only applicable for
IPv6.
Table 2-48
LinkLocal parameters
Editable
AID AID Displays the AID. No
Carrier • GCC0 Displays the overhead bytes that carry the DCC No
• GCC1 or G.709 GCC.
• GCC2
• LINE
• SECTION
Circuit string Displays the specific port/facility it is associated No

to.
IP Address Eight groups of four Displays the IPv6 address of the interface. No
hexadecimal digits (IPv6)
Prefix 0-128 Displays the IP prefix of the address. No

Zero Touch Provisioning parameters

The Zero Touch Provisioning (ZTP) option has a single table which displays
information on zero touch provisioning. The ZTP statistics are displayed within
the application.
Use the Edit button to edit the ZTP admin state.
Table 2-49
Zero Touch Provisioning parameters
Parameter Options Description Editable

Admin State • Auto (default) Specifies the ZTP admin state: Yes
• On • Auto specifies that the presence/absence
• Off of the RJ45 Ethernet loopback pluggable
determines whether ZTP is enabled.
• On/Off can be used to override use of the
RJ45 Ethernet loopback pluggable.
NAT Configuration parameters

The NAT Configuration option has a single table with a single entry. Use the
Edit button to edit the NAT Configuration parameter.
Table 2-50
Editable
NAT Starting 1024 to 65535 Sets the base UDP/TCP port value dynamically Yes
Port allocated for connection flows managed by NAT
services. It applies to Redundant NAT and Private IP
GNEs.
Note: If not specified, the current value is not changed.
If never configured, the default is 50000.
NAT Number 256 to 1024 Specifies the number of UDP/TCP port values Yes
of Entries dynamically allocated for connection flows managed by
NAT services. It applies to Redundant NAT and Private
IP GNEs.

SSH/Telnet parameters
The SSH/Telnet option has a single table with a single entry. Use the Edit
button to edit the SSH/Telnet parameters.
Table 2-51

Editable
SSH Server • Enabled (default) Sets the status of the SSH server. Yes
• Disabled Note: An SSH server cannot be disabled unless a
telnet server is enabled.
Telnet Server • Enabled (default) Sets the status of the telnet server. Yes
• Disabled Note: A telnet server cannot be disabled unless an
SSH server is enabled.
SSH Maximum 1 to 18 (default 3) Sets the maximum number of concurrent SSH sessions Yes
number of SSH that are allowed to the network element.
sessions Note 1: If both SSH and telnet servers are enabled, the
total maximum number of SSH and telnet sessions
cannot exceed 18. For example, if SSH is enabled with
16 maximum sessions, you cannot have more than two
enabled telnet sessions. To increase the maximum
number of telnet sessions, you must first reduce the
maximum number of SSH sessions.
Note 2: Within 18 maximum number of telnet and SSH
sessions, up to 16 TL1 sessions are supported on SP1
and up to 17 TL1 sessions are supported on SP2. Each
TL1 gateway session will count as one telnet session.
Telnet 1 to 18 (default 18) Sets the maximum number of concurrent Telnet Yes
Maximum sessions that are allowed to the network element.
number of Note 1: If both SSH and telnet servers are enabled, the
telnet sessions total maximum number of SSH and telnet sessions
cannot exceed 18. For example, if telnet is enabled with
16 maximum sessions, you cannot have more than two
enabled SSH sessions. To increase the maximum
number of SSH sessions, you must first reduce the
maximum number of telnet sessions.
Note 2: Within 18 maximum number of telnet and SSH
sessions, up to 16 TL1 sessions are supported on SP1
and up to 17 TL1 sessions are supported on SP2. Each
TL1 gateway session will count as one telnet session.
SSH Idle 0 to 99 (default 30) Sets the time (in minutes) before an idle SSH session Yes
timeout is disconnected. A value of 0 indicates infinite (no
(minutes) timeout).

Table 2-51
SSH/Telnet parameters (continued)

Editable
Telnet Idle 0 to 99 (default 30) Sets the time (in minutes) before an idle Telnet session Yes
(minutes) timeout).
SSH CIPHER • AES128CTR Select the check box(es) to enable the corresponding Yes
• AES128CBC secure shell (SSH) cipher(s).
• AES192CTR
• AES192CBC
• AES256CTR
• AES256CBC
• RIJNDAEL128CBC
• RIJNDAEL192CBC
• RIJNDAEL256CBC
• 3DESCBC
SSH HMAC • MD5 Select the check box(es) to enable the corresponding Yes
• MD596 secure shell (SSH) hash message authentication
codes (HMACs).
• SHA1
• SHA196
• SHA256
SSH Key Exchange
Host Key • DSA Select the check box(es) to enable the corresponding Yes
Algorithms • RSA host key algorithm(s).
Key Exchange • DH-GROUP1 Select the check box(es) to enable the corresponding Yes
Method • DH-GROUP14 key exchange method(s):
• ECDH-SHA2-NIST • DH-GROUP1 corresponds to Diffie-Hellman Group 1

P256 key exchange.
• ECDH-SHA2-NIST • DH-GROUP14 corresponds to Diffie-Hellman Group

P384 14 key exchange.
• ECDH-SHA2-NISTP256 corresponds to Elliptic Curve
Diffie-Hellman (ECDH) key exchange method with
ephemeral keys generated on the NISTP256 curve.
• ECDH-SHA2-NISTP384 corresponds to Elliptic Curve
Diffie-Hellman (ECDH) key exchange method with
ephemeral keys generated on the NISTP384 curve

Table 2-51

Editable
Key • Yes Select whether key re-exchange is enabled (Yes) or Yes

Re-Exchange • No (default) disabled (No).
The key re-exchange feature forces SSH sessions to
renegotiate their session keys after 500 MB of data is
transferred or after 1 hour of time has elapsed since the
last key exchange.
SSH Client
Host Key • Yes Select whether host key validation is enabled (Yes) or Yes
Validation • No (default) disabled (No).
Host Key Validation enables the SFTP client to validate
a remote SFTP server's host key. If the remote SFTP
server's host key is not contained within the known host
key list, the connection is denied.
SSH Server
Server Auth • None (default) Select the SSH server authentication method. Yes
• Public Key Note: The 6500 always requires authentication in its
applications and this enforces additional authentication
at the SSH layer.
SSH Log Level
Log Level • 1 (default) Select the SSH log level: Yes

•2 • Level 1 supports connection logs (including SFTP
client connection logs).
• Level 2 adds SSH server connection logs.

TEST-PING parameters
The TEST-PING option has a single table which displays information on the
ping results. Use the Ping button to perform a ping.
Table 2-52
TEST-PING parameters

Editable
IP Address Standard dot notation (IPv4) or Specifies the target IPv4 or IPv6. This Yes
eight groups of four hexadecimal parameter is mandatory.
digits (IPv6)
Count 1-10 (default is 3) Selects the ping count. Yes
Packet Size 8-8182 (default is 8) Selects the packet data size. Yes
TimeOut 1-10 (default is 1) Selects the timeout period in seconds. Yes
Traceroute parameters
The traceroute option has a single table which displays information on the
trace route results. Use the Traceroute button to trace a route.
Table 2-53
Traceroute parameters

Editable
IP Address Standard dot notation (IPv4) or Specifies the target IP. This parameter is Yes
eight groups of four hexadecimal mandatory.
digits (IPv6)
Hop Limit 1-30 (default is 10) Selects the hop limit. The limit includes Yes
both IPv4 and IPv6 sessions. Although
there is separation of the protocols, they
are a combined total in this case.
Probes 1-3 (default is 3) Selects the number of probes per hop. Yes
TimeOut 1-60 (default is 10) Selects the timeout period in seconds. Yes
Trace Route string Displays the trace route results. No

Summary


3-1
Comms setting management

procedures for T-Series 3-
Overview
This chapter provides procedures and parameter information related to the
6500 Packet-Optical Platform (6500) network data communications for
T-Series shelves.
Note: You must refer to Chapter 1, “Data communications planning” for

an overview of 6500 communications planning before you start using the
procedures in this section.

DCN DCN

3-2 Comms setting management procedures for T-Series
ID Identifier


SP Shelf processor
SSH Secure shell
WSC Wayside channel

Site Manager navigation

The following figure provides an overview of the Site Manager navigation
associated with communications management for the 6500. The figure shows
the path from the Site Manager menu bar.

Procedures and options for Comms Setting Management

Comms Setting Management window
Options Procedures
Opening window
Comms Setting Procedure 3-1, “Retrieving communications settings”

Management “Communications management parameters” on page 3-21
Edit command
Comms Setting Procedure 3-2, “Editing the communications settings”
Management Procedure 3-3, “Editing the Site Level Data Distribution”
Procedure 3-4, “Migrating an MD5 key”
Add command
Comms Setting Procedure 3-5, “Adding a new entry in the communications settings”
Management
Delete command
Comms Setting Procedure 3-6, “Deleting an entry in the communications settings”

Management
Ping and trace commands

Command line Procedure 3-7, “Using the 6500 CLI ping and trace commands”
interface Note: You must use the command line interface and not the Site Manager to
perform this procedure.
Associated procedures
Some procedures require the user to perform procedures relating to other
topics. Before performing a procedure, if necessary ensure that the
information about the associated procedures is available.
All procedures assume that the user is logged in to the network element (see
Administration and Security, 323-1851-301).
In this release, some communications windows contain an IPV4 tab and IPV6
tab. The IPV6 tab is not supported for T-Series in this release and is grayed
out.

Procedure 3-1
Use this procedure to retrieve the provisioned parameters associated with the
data communication network.
Step Action

The Comms Setting Management application contains three tabs which
provide access to associated parameters as follows:
• Routers
IISIS Circuit, IISIS Router, IP Static Route, Reverse Port NAT, OSPF
Circuit, OSPF Router, Port Filter, Upper Layer DCC, SLDD, Visible NE
Information, IISIS Routing Table, IP Routing Table, OSPF Neighbors
• Interfaces
ARP/ND Proxy, ARP/ND Table, GNE, GNE Port Filter, IP, LAN, Lower
Layer DCC/GCC, NDP, PPP, Serial/RS232, TL1 Gateway Connections,
USB
• Services
DHCP, FTP, SSH/Telnet, NETCONF, HTTP/HTTPS, NAT Configuration
3 Select the required tab.
Service type drop-down list.
The information about the selected comms is displayed. See
“Communications management parameters” on page 3-21 for information
about the options available.
For tables, the number of items in the table is displayed on the right above the
table.
—end—

Procedure 3-2
Use this procedure to edit the provisioned parameters associated with the
data communication network.
Prerequisites
higher.
Step Action

Service type drop-down list. See “Communications management
parameters” on page 3-21 for the options that can be edited.
6 Select the required circuit/port/entry in the table.
7 Click Edit to open the appropriate edit dialog box.


Step Action
8 Edit the parameters as required. See the following for editable parameters:
• Routers
• Interfaces
— “PPP parameters” on page 3-62
• Services
— “DHCP parameters” on page 3-66
— “FTP parameters” on page 3-66
— “NETCONF parameters” on page 3-67
— “SSH/Telnet parameters” on page 3-67
— “HTTP/HTTPS parameters” on page 3-70
— “NAT Configuration parameters” on page 3-71
9 Click OK.
—end—

Procedure 3-3
Use this procedure to edit the Site Level Data Distribution. For details, refer to
“Site Level Data Distribution (SLDD) parameters” on page 3-42. For more
information on these parameters and how they apply to the data
communication network, refer to Chapter 1, “Data communications planning”.
The P and/or G in suffix(es) displayed next to the shelf number denote(s) the
Primary shelf and/or a GNE.
Prerequisites
• To perform this procedure, you must use an account with a level 3 UPC or
higher.
• SLDD interface provisioning shall be blocked if an OSPF circuit with
Opaque = ON exists against the interface.
• A port and circuit must be provisioned for the SLDD interface to enter into
an active state.
Step Action
Enabling, Disabling, or Editing SLDD

6 Click Edit.
7 At the Admin State parameter, select Enable to enable SLDD or select
Disable to disable SLDD.
8 At the Configuration drop-down list, in most cases, select Auto (the default
value), in which case the Scope-ID is automatically set to be the same value
as the Site ID of the shelf, and then go to step 10.
If the configuration is set to Manual, the Scope-ID must be specified in the
next step. It is recommended to consult with Ciena before setting to Manual.


Step Action
9 At the SLDD Scope ID parameter, enter the scope ID. This parameter can be
edited only if the Configuration is Manual. Only shelves with the same Scope
ID will exchange information. It is recommended to consult with Ciena before
setting a manual Scope ID.
10 Click OK.
Adding an interface to the SLDD List
16 Click Add.
17 At the Name parameter, select the interface from the drop down list.
18 Click OK.
Deleting an item from the SLDD List
24 Select the interface in the table you want to delete.
25 Click Delete.
—end—

Procedure 3-4
Migrating an MD5 key
Use this procedure to migrate an IPv4 OSPF adjacency from one MD5 key
(older) to another MD5 key (newer). It covers the OSPF circuits at both ends
of the adjacency.
This procedure applies to 6500 to 6500 OSPF adjacencies. Similar steps can
be followed for 6500 to third party adjacencies, taking into consideration the
specifics of the third party device.
Prerequisites
• the OSPF circuits must be provisioned with the MD5 authentication type.
• you must use an account with a level 3 UPC or higher.
Step Action
1 Identify the network element at each end of the adjacency (referred to as

network element A and network element B henceforth).
2 Select network element A in the navigation tree.
4 In the Routers tab, select the required shelf from the Shelf drop-down list.
5 Select the OSPF Circuit from the Router type drop-down list.
6 Select the required OSPF circuit in the table.
7 Click Edit to open the Edit OSPF Circuit Parameters dialog box.
8 Enter the new MD5 key in the Key 2 field if the old key is Key 1, or in the
Key 1 field if the old key is Key 2. Enter a unique ID in the corresponding ID
field.
9 Click OK.
10 Repeat step 2 to step 9 for network element B.
11 In the OSPF Circuits table for both network elements A and B, verify that the
status of the new key is “Accepting” for the OSPF circuit you just edited. Click
Refresh if necessary. If the status does not change to “Accepting”, check the
provisioned key and ID values to ensure they match at each end.
12 Select the OSPF circuit on network element A and click Edit.
13 Remove the old MD5 key and click OK.
14 Repeat step 12 and step 13 for network element B.
—end—

Procedure 3-5
Use this procedure to add a new entry (interface, circuit, router) in the
communications settings.
Prerequisites
higher.
Step Action

page 3-21 for the options where an entry can be added.
6 Click Add to open the appropriate add dialog box.
7 Add the parameters as required (if appropriate). See the following for
parameters that can be added:
• Routers


Step Action
• Interfaces
— “GNE parameter” on page 3-51
For the Add IISIS Router Parameters and the Add OSPF Router Parameters
dialogs, you have the option of adding distribution lists. To add a distribution
list, use the Add button in the Redistribution section (lower section). A
maximum of 80 distribution lists can be added for each type of list. To delete
a distribution list, select the distribution list in the Redistribution section
(lower section) and select Delete.
8 If Then
the dialog allows more than one entry to be click Apply, go to step 7
added and you want to add another entry
otherwise go to step 9
9 Click OK.
After the manual area addresses are added/changed, perform a protection
switch of the CTM.
—end—

Procedure 3-6
Use this procedure to delete an entry (interface, circuit, router) in the
communications settings.
Prerequisites
higher.
Step Action

page 3-21 for the options where an entry can be deleted.
6 Delete the parameters as required (if appropriate). See the following for
entries that can be deleted:
• Routers


Step Action
• Interfaces
— “GNE parameter” on page 3-51
7 If you want to delete Then in the table, select

one circuit/port/entry the circuit/port/entry you want to delete from the
list of circuits/ports/entries
some but not all circuits/ select the first circuit/port/entry in the list and
ports/entries hold down the Ctrl key while individually clicking
on each required circuit/port/entry
all circuits/ports/entries select the first circuit/port/entry in the list and
hold down the Shift key while clicking once on
the last circuit/port/entry in the list.
or
select any circuit/port/entry in the list and then
Ctrl+A (Ctrl and A keys together) to select all
circuits/ports/entries
Bulk deletion is supported for some circuits/ports/entries in this release.
For the list of supported circuits/ports/entries, refer to “Communications
management parameters” on page 3-21.
8 Click Delete.
9 Click Yes to close the warning box.
—end—

Procedure 3-7
Use this procedure to test for network connectivity using IP and OSI ping and
trace commands. These commands are available in the 6500 command line
interface (CLI) when using Telnet or a terminal session.
Note: The user ID and password input in the command line interface is
not case-sensitive and is converted to uppercase unless enclosed by
double quotes ("). User IDs and passwords containing lowercase
characters can be entered by enclosing them in double quotes. The
challenge/response input is case-sensitive and does not require double
quotes.
Prerequisites
higher.
Step Action
1 If you are using Then

a Terminal session Start a terminal session (see Administration and
Telnet Open a Telnet session (see Administration and
When you use the CLI port number (10010 or 10020) or SSH port (20002) for
a Site Manager terminal session or Telnet access, you access the CLI directly.
2 At the login prompt, enter the user ID by entering:
<user ID>
3 At the password prompt, enter the password by entering:
<password>


Step Action
4 If you want to use the Then go to

IP ping tool step 5
IP traceroute tool step 6
OSI netping tool step 7
OSI clping tool step 8
OSI coping tool step 9
Telnet Administration and Security,
323-1851-301 for detailed
procedure
OSI Rlogin Administration and Security,
procedure
Rtrv_nsap Administration and Security,
procedure
logout step 10
5 Type ping followed by the ping parameters as shown below:

ping <IP-ADDR> [count <COUNT>] [size <SIZE>]
where
default 100)



Step Action
6 Type traceroute followed by the traceroute parameters as shown below:

traceroute <IP-ADDR> [nprobes <PROBE-COUNT>]
[timeout <TIMEOUT-VAL>] [ttl <TTL>]
where
10)

7 Type netping followed by the netping parameters as shown below:
netping <OSI-ADDR>
where
<OSI-ADDR> is the OSI NSAP address in the format
[<AA><SYSID><NSEL>] where
A response to the netping is displayed.



Step Action
8 Type clping followed by the clping parameters as shown below:

clping <OSI-ADDR> [number <NUM>] [rate <RATE>]
where
where
default 20)
300, default 1)
1425, default 64)
A response to the clping is displayed.



Step Action
9 Type coping followed by the coping parameters as shown below:

coping <OSI-ADDR> [number <NUM>] [rate <RATE>]
where
where
default 20)
<RATE> is optional rate at which to send in seconds (0
to 300, default 1)
16384, default 64)
A response to the coping is displayed.

10 Either:
• close the terminal session (see Administration and Security,
323-1851-301 for detailed procedures).
• exit and close the Telnet session by entering:
— Ctrl+]
— quit
—end—

Communications management parameters

Table 3-1
Routers
IISIS Circuit Displays information about the IISIS circuits. See “IISIS Circuit Yes (Note 1) No
IISIS Router Displays information about the IISIS routing. See “IISIS Router Yes (Note 2) No
IP Static Route Displays information about the IP Static Route. See “IP Static Yes (Note 1) No
Route parameters” on page 3-27.
Reverse Port Display the information about mapping the TCP/UDP port of Yes (Note 1) No
NAT external requests to other internal port numbers and use a single
external IP address to access service in the internal network.
See “Reverse Port NAT parameters” on page 3-29.
OSPF Circuit Displays information about the OSPF circuits. See “OSPF Circuit Yes No
OSPF Router Displays information about the OSPF routers. Supported on all Yes (Note 2) No
Ethernet, GCC channels, and static tunnels but not the craft LAN
port on the CTM. See “OSPF Router parameters” on page 3-35.
Port Filter Displays information about the port filtering. It applies to IP Yes No
packets that are being forwarded from a private interface to a
public one, on the GNE. See “Port Filter parameters” on
page 3-37.
Upper Layer Displays information about the manual area addresses used in Yes No
DCC OSI addressing. See “Upper Layer DCC parameters” on
page 3-40.
SLDD Displays information about the Site Level Data Distribution Yes Yes
(SLDD). See “Site Level Data Distribution (SLDD) parameters”
on page 3-42.
Visible NE Displays the routing information. See “Visible NE Information No No
Information parameters” on page 3-44.
IISIS Routing Displays the routing table. See “IISIS Routing Table parameters” No No
Table on page 3-45.
IP Routing Displays information about IP routing. See “IP Routing Table No No

Table parameters” on page 3-45.

Table 3-1
OSPF Displays information about OSPF neighbors. See “OSPF No No

Neighbors Neighbors parameters” on page 3-47.
Interfaces
ARP/ND Proxy Displays information about the ARP Proxy IP address. See Yes (Note 1) No
“ARP/ND Proxy parameters” on page 3-49.
ARP/ND Table Displays information about the ARP table. See “ARP/ND Table No No
GNE Displays GNE information used for tunneling on all interfaces Yes (Note 1) No
“GNE parameter” on page 3-51.
GNE Port Filter Displays information about the GNE port filtering interface. See Yes (Note 1) No
“GNE Port Filter parameters” on page 3-52
IP Displays information about the IP on the LAN and RS-232 serial Yes Yes
ports. See “IP parameters” on page 3-52.
LAN Displays information about the six external LAN interfaces. “LAN Yes Yes
Lower Layer Displays information about the DCC/GCC communication. See Yes Yes
DCC/GCC “Lower Layer DCC/GCC parameters” on page 3-56.
NDP Displays the admin state of the NDP feature and the facilities with Yes Yes
NDP enabled. See “NDP parameters” on page 3-61.
PPP Displays information about point-to-point protocol for No Yes

communication. See “PPP parameters” on page 3-62.
Serial/RS-232 Displays information about the serial RS-232 ports. See “Serial/ No Yes
RS-232 parameters” on page 3-63.
TL1 Gateway Displays information about the TL1 Gateway Connections. See No No
Connections “TL1 Gateway Connections parameters” on page 3-64.
USB Displays the status of the USB ports. See “USB parameters” on No Yes
page 3-65.
Services
DHCP Displays information about the DHCP service used for local PC No Yes
access. See “DHCP parameters” on page 3-66.
FTP Displays information about the file transfer protocol (FTP) service No Yes
used for transferring files to/from the network element. See “FTP

Table 3-1
NETCONF Displays information about the NETCONF service. See No Yes

“NETCONF parameters” on page 3-67.
SSH/Telnet Displays information about SSH and Telnet used for remote No Yes
access to/from remote computers. See “SSH/Telnet parameters”
on page 3-67.
HTTP/HTTPS Displays information about the support secure HTTP service. No Yes
See “HTTP/HTTPS parameters” on page 3-70.
NAT See “NAT Configuration parameters” on page 3-71. No Yes

Configuration
Note 1: Bulk deletion is supported for this Comms Setting Management option. Refer to Procedure 3-6,
“Deleting an entry in the communications settings” for more information on how to perform a bulk
deletion.
Note 2: Bulk deletion is supported for the redistribution section of this Comms Setting Management
option. Refer to Procedure 3-6, “Deleting an entry in the communications settings” for more information
on how to perform a bulk deletion.

Routers tab
IISIS is a routing protocol based on the OSI intra-domain routing protocol with
IP-specific extensions as specified in RFC1195. IISIS allows IP and OSI to
coexist in a single routing domain, allowing IP-only routers, OSI-only routers,
and dual IP/OSI routers to be effective in routing in a single network.
The IISIS Circuit option has a single table. Use the Add button to provision
new IISIS circuits and the Delete button to delete existing IISIS circuits. You
must create an IISIS circuit on each provisioned interface you want IISIS to
run on (except Auto-tunnels and the RS-232 ports).
Note 1: It is recommended that an IISIS circuit is not created for

LAN-shelf-41 unless LAN-shelf-41 is configured to access remote network
elements.
Note 2: Do not add IISIS circuits to LAN ports provisioned with the
Note 3: Do not create an IISIS circuit on the COLAN interfaces if the
interface is not connected to external DCN running IISIS.
For OTMn ports, a GCC0 or GCC1 PPP circuit (with IP address of 0.0.0.0) and
an associated IISIS circuit are automatically created when a PTP facility with
OTUn service type is provisioned if:
• the default auto GCC0 mode or GCC1 mode parameter is set to IISIS in
the System tab of the Node Information application and
• the Shelf IP has been provisioned on the NE.
When provisioning both GCC0 and GCC1 with default IISIS metrics on a shelf,
Comms over GCC1 is preferred as opposed to GCC0.

Table 3-2
Editable
Unit • SHELF-shelf Displays the available ports for an IISIS circuit. Yes
• LAN-shelf-41 Only OTUTTP/ODUTTP AID with lower layer GCC0/
• LAN-shelf-42 GCC1/GCC2 provisioned are available for selection.
• COLAN-shelf-A
• COLAN-shelf-X
• ILAN-shelf-IN1
• ILAN-shelf-IN2
• ILAN-shelf-IN3
• ILAN-shelf-OUT1
• ILAN-shelf-OUT2
• ILAN-shelf-OUT3
• OTUTTP/ODUTTP
AID
Carrier • GCC0 Sets the carrier selected for the GCC (options Yes
• GCC1 available depend on circuit pack type and function).
Only applicable to Unit types with OTUTTP/ODUTTP
• GCC2 AID.
Circuit 1 to 63 Sets the circuit default metric used to calculate the Yes
Default best route. Default depends on type of interface as
Metric follows:
• SHELF, LAN-shelf-41, LAN-shelf-42, COLAN,
ILAN: 4
• OTUTTP/ODUTTP AID: 55
Select a higher value for a slower circuit.
Level 2 Only • On Sets the status of level 2 only routing on the IISIS No
• Off (default) circuit. Not supported in this release, On option is
always disabled.
3 Way • On Sets the status of 3-way handshaking on the IISIS No

Handshake • Off (default) circuit. Not supported in this release, On option is
always disabled.
Neighbour Off Displays the protocols supported on neighbor routers Yes
Protocols (overrides what the router advertises). In this
Supported release, only Off is supported for Neighbor Protocols
Override Supported Override (NPSOVERRIDE).


The IISIS Router option has two tables.
• The upper Router table displays information about the IISIS router. Use
the Add button to add an IISIS router (only one allowed). Use the Delete
button to delete the existing IISIS router. If not already created, an IISIS
router is automatically created when an OTU service type facility is
provisioned and provided if:
— the default GCC0 and/or GGC1 mode is set to IISIS in the System tab
of the Node Information application, and
— the Shelf IP has been provisioned on the NE.
lists provisioned for the IISIS router. Use the Add button to add IISIS
Table 3-3

Editable
Router table
Router Level Level 1 Sets the IISIS router level. Level 2 not supported No
in this release, option is always disabled.
L1 Priority 1 to 127 (default 64) Sets the level 1 router priority. The L1 router Yes
assigned the highest priority becomes the L1
designated router for that LAN segment.
L2 Priority 1 to 127 Sets the level 2 router priority. The L2 router No

(default 64) assigned the highest priority becomes the L2
designated router for that LAN segment.
Not supported in this release, option is disabled.
Route On (default), Off Sets whether routes (Off) or route summaries Yes
Summarization (On) are redistributed.
Redistribution table
Route • OSPF Distribution Sets the IISIS router distribution list entries for Yes
Redistribution/ • Static Distribution the selected IISIS router. The maximum is 80 for
List (default) each.
IP Subnet Standard dot notation Sets the IP subnet address of the distribution list Yes
entry for the selected IISIS router.

Table 3-3
IISIS Router parameters (continued)

Editable
Subnet Mask Standard dot notation Sets the subnet mask of the distribution list entry Yes
for the selected IISIS router.
Metric 1 to 63 Sets the metric (cost) of the distribution list entry Yes
for the selected IISIS router.
Metric Type External (default), Sets the metric type of the distribution list entry Yes
Internal for the selected IISIS router.
IP Static Route parameters

The IP Static Route option has a single table which displays static entries. Use
the Add button to add a static entry and Delete button to delete an existing
static entry. Use the Check button to start a netmask provisioning check on all
the IP static routes in order to let you know if the next hop IP for each IP static
route is within the subnet of the Circuit ID IP.
Table 3-4

Editable
IP Subnet Standard dot notation Sets the destination IP subnet of the static route Yes
entry.
Subnet Mask Standard dot notation Sets the subnet mask of the table entries. Yes
Next Hop Standard dot notation Sets the IP address of the next hop. Yes
Cost 1 to 65535 Sets the cost of the link. Yes

Table 3-4
IPv4 Static Route parameters (continued)

Editable
Circuit ID • COLAN-shelf-A Sets the circuit identifier of the port used to get to the Yes
• COLAN-shelf-X next hop.
• ILAN-shelf-IN1 If the Next Hop is provisioned, the Circuit ID is
optional.
• ILAN-shelf-IN2
• ILAN-shelf-IN3
• ILAN-shelf-OUT1
• ILAN-shelf-OUT2
• ILAN-shelf-OUT3
• LAN-shelf-41
• LAN-shelf-42
• OTUTTP/ODUTTP
port
Carrier • GCC0 Sets the carrier selected for the GCC (options Yes
Only applicable to OTU service type facilities.
• GCC2
Status • FORWARDING Displays the status of the route. No

• REJECTED • FORWARDING
Forwarding means the route is active in the routing
table and its next hop is reachable.
• REJECTED
Note: Rejected means that the route is not in the
routing table and its next hop is not reachable


Reverse Port NAT entries are entered on a Private-IP GNE to provide access
to specific services on remote NEs.
The Reverse Port NAT entry has a single table. Use the Add button to
provision a new Reverse Port NAT entry and the Delete button to delete an
existing Reverse Port NAT entry.
Table 3-5

Editable
DCN IP Address Standard dot notation Displays the active public IP of the GNE. No
DCN Port (NATBASEPORT + 2050) to Sets the external port which is being Yes
(Note 1) (NATBASEPORT + 4099) mapped.
The default value of
NATBASEPORT is 50000.
Remote NE IP Standard dot notation Identifies the Private IP of the remote NE. Yes
Address
Remote NE • HTTP Select the service that will be used to Yes

Service • Secure HTTP access the remote NE.
• FTP
• NETCONF
• NNCLI (Telnet)
• NNCLI (SSH)
• TL1 (Telnet)
• TL1 (SSH)
• SNMP
• Other

Table 3-5
Reverse Port NAT parameters (continued)

Editable
Remote NE Port 1 to 65535 Displays the internal port which is being Yes
(Note 2) mapped.
Protocol • TCP Displays which type of the protocol is Yes

(Note 3) • UDP applicable to the remote NE port.
Note 1: NATBASEPORT can be modified in Site Manager under 'NAT configuration' in the Comms
Setting Management/Services tab. The default range of dynamic NAT ports that are opened on the NE
are 50000 to 50511. This range can be changed by editing the NAT configuration parameters.
Note 2: For a selected service in the Remote NE Service parameter, the remote NE port field is
populated with the port number for that service, except for the “Other” service. Only for the “Other”
service, the remote NE port field is provisionable.
Note 3: For the SNMP service, the Protocol is always UDP. For the rest of the Remote NE Service
options except “Other”, the Protocol is always TCP. Only for the “Other” service, the Protocol parameter
is provisionable. For Ciena support access to debug ports 8888, 8889, and 28888, choose TCP.

OSPF Circuit parameters

The OSPF Circuit option has a single table which displays information about
the OSPF circuit. Use the Add button to add an OSPF circuit or the Edit
button to edit an existing OSPF circuit. Use the Delete button to delete an
existing OSPF circuit.
An OSPF circuit cannot be provisioned against a lower layer DCC with its
Protocol parameter set to LAPD.
Note 1: Do not add OSPF circuits to LAN ports provisioned with the
Note 2: Do not create an OSPF circuit on the COLAN interfaces if the
interface is not connected to external DCN running OSPF.
The OSPF circuits will automatically create for IPv4 as follows: For IPv4, for
OTMn ports, a GCC0 or GCC1 PPP circuit (with IP address of 0.0.0.0) and an
associated OSPF circuit are automatically created when the OTM2 facility is
provisioned if the default auto GCC0 mode or GCC1 mode parameter is set to
OSPF in the System tab of the Node Information application and if the Shelf
IP has been provisioned on the NE.

Table 3-6
Editable
Unit/Name • COLAN-shelf-A Displays the ports available for OSPF. Yes

• COLAN-shelf-X
• LAN-shelf-IN1
• ILAN-shelf-IN2
• ILAN-shelf-IN3
• ILAN-shelf-OUT1
• ILAN-shelf-OUT2
• ILAN-shelf-OUT3
• LAN-shelf-41
• LAN-shelf-42
• SHELF-shelf
• CONTROL-shelf-
GROUP0
• CONTROL-shelf-
GROUP1
• OTUTTP/ODUTTP AID
Carrier • GCC0 Sets the GCC carrier selected for the GCC Yes
• GCC1 (options available depend on circuit pack type
and function). Only applicable to Unit types
• GCC2 with OTUTTP/ODUTTP AID.
Network Area Standard dot notation Sets the network area (defaults to backbone Yes
area of 0.0.0.0). If there are multiple circuits on
an AID, you cannot edit the Network Area
parameter of any circuit on that AID.
• LAN-shelf-41, LAN-shelf-42, COLAN, ILAN:
10
• GCC0/1/2 on OTUTTP/ODUTTP: 75
Area Default 1 to 16777215 (default 1) Sets the cost of the route to the next area. No
Cost Note: It is not supported in this release.

Table 3-6

Editable
Dead Interval 1 to 65535 Sets the interval (in seconds) at which hello Yes
(default 40) packets must not be seen before neighbors
declare the router down.
Hello Interval 1 to 65535 Sets the interval (in seconds) between the Yes
(default 10) hello packets that the router sends on the
interface.
Retransmit 1 to 3600 (default 5) Sets the interval (in seconds) required No

Interval between link-state advertisement
retransmissions.
Transmit Delay 1 to 3600 (default 1) Sets the estimated time (in seconds) it takes to No
transmit a link state update packet over this
interface.
Primary Area • On (default) Sets the primary area. The Primary Area Yes
• Off parameter for the first circuit on an AID has to
be set to ON (which is the default). All circuits
provisioned after that have to be set to Primary
Area OFF. The multi-area OSPF circuit feature
is applicable for T-Series IPv4 only.
Priority 0 to 255 (default 1) Sets the router priority value used in Yes
multi-access networks for the election of the
designated router (0 indicates that router is not
eligible to become designated router).
Area • Off (default) Sets whether the router is in a not so stubby Yes
• NSSA area (NSSA) or stub area. NSSA and Stub not
supported in this release.
• Stub
Opaque Link • On Sets whether opaque link state advertisement Yes

State • Off performs on the OSPF circuit. Default Off for
Advertisement COLAN, ILAN, and LAN ports. Default On for
all other ports.
Passive OSPF • On Determines whether OSPF adjacency loss Yes

Circuit • Off (default) should be detected. If set to On, OSPF
adjacency loss will be ignored.

Table 3-6

Editable
Authentication • Null (default) Sets the authentication type. Null means no Yes
Type • Simple authentication.
• MD5
Simple string of up to 8 characters Sets the password if authentication type is Yes

Password simple password.
Status • Accepting Displays the status of the simple password No

• Rejecting authentication.
• Null • Accepting: The password is valid.

• Rejecting: The password is not valid.
• Null: The password is not provisioned.
MD5 Identifier 1 0 to 255 Sets the identifier for the first MD5 key. Must Yes
be unique on an OSPF interface.
MD5 Key 1 string of up to 16 Sets the password for the first MD5 key. Yes
characters


• Null: The authentication key is not
provisioned.
MD5 Identifier 2 0 to 255 Sets the identifier for the second MD5 key. Yes
Must be unique on an OSPF interface.
MD5 Key 2 string of up to 16 Sets the password for the second MD5 key. Yes
characters
MD5 Status 2 • Accepting Displays the status of the authentication using No


• Null: The authentication key is not
provisioned.

OSPF Router parameters

The OSPF Router option has two tables.
• The upper Router table displays information about the OSPF router. Use
the Add button to add an OSPF router. Use the Edit button to edit an
OSPF router. Use the Delete button to delete an existing OSPF router.
lists provisioned for the OSPF router. Use the Add button to add OSPF
If not already created, an OSPF router is automatically created when an

OTMn facility is provisioned if the default GCC0 and/or GGC1 mode is set to
OSPF in the System tab of the Node Information application and if the Shelf
IP has been provisioned on the NE.
Table 3-7

Editable
Router
Unit Shelf-slot Displays the name. No
OSPF Router Standard dot Sets the router ID for the OSPFv2. Yes
Id notation It is recommended that the SHELF address (if
provisioned) is used as the OSPFv2 Router Id.
Route • On (default) Sets whether routes (off) or route summaries (On) are Yes
Summarization • Off redistributed.
Autonomous • On (default) Sets the autonomous system border router (ASBR). Yes
System Border • Off ASBR identifies whether an OSPFv2 router can
Router accept input (route redistribution) from another
autonomous system such as IISIS, or static routes.
Opaque Filter • All Disables the OSPF Opaque LSA Flooding Control Yes
• LAN (OOLFC), or enables for LAN, or enables for all.
• Off (default) OOLFC reduces the number of Type 11 opaque

LSAs containing AR and TR records in the OSPF
database for 6500 shelf that is part of an OSPF
network.
Cannot be set to on (All or LAN) if ODBR is on. And
vice versa.

Table 3-7

Editable
Shelf IP • On Enables or disables shelf IP redistribution. Shelf IP Yes

Redistribution • Off (default) redistribution provides the ability to redistribute a
route to the local shelf IP into all OSPFv2 areas that
the local shelf participates in. All NEs in these
participating OSPFv2 areas will install the received
route into their local IP routing table. Only supported
in OSPF networks without a backbone.
ABR • RFC 3509 (default) Selects the Area Border Router. Yes
• RFC 2328
Compatible
RFC1583 • On (default) Enables or disables the Request for Comments Yes

• Off (RFC) 1583 compatibility.
Redistribution
Route • IISIS Distribution Sets the origin of the route(s) to be redistributed. Yes
Redistribution/ • Static Distribution
List (default)
IP Subnet Standard dot Sets the IP subnet address for redistribution. Yes
notation
Subnet Mask Standard dot Sets the subnet mask for redistribution. Yes
notation
Metric 1 to 65535 Sets the metric for redistribution. Yes

Metric Type • External (default) Sets the metric type for redistribution. Yes
• Internal


The Port Filter entry has a single table. Use the Add button to provision a new
Port entry and the Delete button to delete an existing Port Filter entry. See
Table 3-9 on page 3-38 and Table 3-10 on page 3-39 for TCP and UDP ports/
ranges open by default that can be blocked or unblocked.
Table 3-8
Editable
Unit • COLAN-shelf-A Displays the provisioned ports. Yes

• COLAN-shelf-X Refer to “Provisionable port filtering” on
• ILAN-shelf-IN1/OUT1 to 3 page 1-388.
• LAN-shelf-41/42
Action • Block Displays the action to be taken when IP Yes

• Permit packets match the filter rule.
Filtering Ingress Sets the location of the filter rule for the Yes
Location provisioned port.
Protocol • TCP Sets the TCP or UDP protocol which is Yes

• UDP applicable to the permitted destination port.
Destination 1 to 65535 Sets the start of the blocked or permitted Yes

Start Port port of the protocol type.
Destination 1 to 65535 Sets the end of the blocked or permitted Yes

End Port port of the protocol type.
Note: You are allowed the provisioning of the Port filtering on the GNE when it is configured in Private
IP mode.

Table 3-9
TCP ports/ranges open by default
Port Description
20, 21 FTP
22 SSH (TL1)
23 Telnet (TL1)
80 HTTP
443 Secure HTTP
830 NETCONF
1010 Ciena debug
1500-1507 Optical Section Channel Topology
2650, 2651 Optical Section Channel Topology 2 TCP server
2654-2661 Network Channel Topology 1 TCP server

3081 IANA Length-Value TL1
3083 IANA Raw Telnet TL1
8888 Ciena debug
8889 Ciena debug (emergency access)
10001 Telnet (TL1 - no echo, no prompt)
10010, 10020 CLI
20000 SSH (TL1 - no echo, no prompt)
20001 SSH (TL1)
20002 SSH (CLI)
28888 SSH (Ciena debug)
50000-50511 PASSIVE ftpd connections AND/OR NAT ports

Table 3-10
UDP ports/ranges open by default
Port Description
67-68 DHCP
123 SNTP
161-162 SNMP
1024 reserved
1509-1516 Optical Section Channel topology
1530 Topology UDP Server

1590 CBT Send UDP Port
1593-1594 Network Channel topology
1812 RADIUS
2112-2113 Inter Node Signaling
2600-2602 Adjacency Auto Discovery
3085 LOC Three Message Protocol
4100 Inter-Shelf-Task for OM5000 SMI solution
4321 TEAS
4322 RAS
17185 VxWorks Workbench
20560 Photonic Domain Messaging

33434-33946 Traceroute
50000-50511 NAT ports


The Upper Layer DCC option has a single table with three entries, one for
each of the three possible manual area addresses required to interoperability
with other OSI products. The manual area addresses are used to form the
NSAP address of each network element in the OSI level 1 area.
Use the Add button to add new manual area addresses to an unprovisioned
entry.
CAUTION
Loss of data communications
The deleting of existing manual addresses can cause a loss of
OSI data communications to the network element. IP based
data communications will be unaffected unless the network
element is being accessed through another OSI-based node.
To edit an existing manual area address, add a new manual area address to
an empty entry to support other equipment then delete existing manual area
address.
Note: If you are moving this network element to a new area, the manual
area address must be added to all network elements before you delete the
old manual area address.
When editing an address, you can either enter the complete address in the
Area address field or enter the individual components of the address in the
Area Address Components fields.
If you enter an Address Format ID (AFI) and Initial Domain ID (IDI) of 39840F
(either in the Area address field or the Address format ID and Initial domain ID
fields), it is recognized as the country code for the United States and the
Domain specific part (DSP) field is replaced with fields for the individual
components of the DSP. For other AFI and IDI entries in the AFI and IDI fields,
you must enter all components of the DSP in either the Area address field or
the Domain specific part (DSP) field.
Use the Delete button to delete an existing manual area address:

• A warning dialog is displayed when you attempt to delete a manual area
address allowing you to cancel the delete operation.

Table 3-11
Editable
Number 1, 2, 3 Displays the three possible manual area addresses. The No

default for manual area address 1 is 490000.
Manual Area 6 to 26 Sets the manual area addresses. When editing an address, Yes
Address hexadecimal the user can enter:
number • a free form manual area address or a manual area address.
The manual area address must be less than or equal to 26
hexadecimal characters. The number of characters must be
even.
• the individual components of the address in the Area
Address Components fields:
— Address format ID (2 hexadecimal characters)
— Initial domain ID (4 hexadecimal characters, pad with ‘F’
hexadecimal characters if less than four characters)
— Domain specific part (up to 20 hexadecimal characters)
— DSP format ID (2 hexadecimal characters, default value is
80)
— Organization ID (6 hexadecimal characters)
— Domain (4 hexadecimal characters)
— Area (4 hexadecimal characters).
The domain specific part field is replaced by the DSP format
ID, Organization ID, Domain, and Area fields if the Address
format ID and Initial domain ID fields are 39840F.
Calculated 6 to 26 Displays the calculated manual area addresses. No

Manual Area hexadecimal
Address number

Site Level Data Distribution (SLDD) parameters


resources.

a site. When used together with a non-OSPF routing protocol such as
integrated ISIS (IISIS), which provides the IP visibility within a site, OSPF
networks can then be segmented to allow for large scale.
The SLDD option has a single table. Use the Edit button to change the SLDD
admin state (enable/disable). For the T-Series shelves, when the SLDD
feature is first enabled, only the ILAN-IN1 and ILAN-OUT1 interfaces are
added by default.
The configuration should, in most cases, be set to Auto (the default value).
This forces the Site-ID to be used as the SLDD Scope ID.
SLDD supports site level configurations with Photonic branching (maximum of

8 branches in this release).
In some special circumstances, it may be necessary to override use of the

Site-ID to a manually set Scope ID. In this case, the configuration can be set
to Manual and the SLDD Scope ID can be set to a user-defined value. The
shelves will only exchange data if they have the same Scope ID. It is
recommended to contact Ciena support if considering setting the
configuration to Manual.
Use the Add and Delete buttons to add or delete interfaces to the list of
interfaces on which SLDD will be active. This will be determined by knowing
which interfaces are used for the physical intra-site connectivity in a given site.
ILAN interfaces are added to the list by default, but can be removed if
necessary. For the T-Series shelves, only the ILAN-IN1 and ILAN-OUT1
interfaces are added by default. COLAN interface(s) can also be added.
Interfaces can be added or deleted from the list regardless of the SLDD admin
state. Refer to Procedure 3-3, “Editing the Site Level Data Distribution” for the
procedure.

Table 3-12
Site Level Data Distribution parameters
Editable
Admin State • Enabled Enables/disables the SLDD feature. Yes

• Disabled
Configuration • Auto (default) Selects the configuration mode for the Scope ID. Yes
• Manual Note: Select Auto (the default value) for most
configurations. This will allow the Site-ID to be used
to scope SLDD data. In some special
circumstances, it may be necessary to override use
of the Site-ID to a manually set SLDD Scope ID. In
this case, choose Manual and set the SLDD Scope
ID parameter, below. The shelves will only
exchange data if they have the same SLDD Scope
ID. It is recommended to contact Ciena support
before using a manual SLDD Scope ID.
SLDD Scope integer Sets the Site Level Data Distribution Scope ID. This Yes
ID is only required, and can only be edited, if setting
Configuration to Manual (see above). The format is
0-65535. The default is 0. This parameter is
read-only when Configuration = Auto and defaults
to the Site-ID.
Unit string Select the interface to provision for SLDD. Yes

Supported interfaces are COLAN, ILAN, OSC.
State • Active - interface Up Displays the interface’s state: No

• Unprovisioned - • Active - interface Up: the interface is fully
interface Down provisioned and the adjacency is up.
• Fault detected - • Unprovisioned - interface Down:
adjacency Down the interface is not fully provisioned, or the feature
• Fault detected - is disabled.
interface Down • Fault detected - adjacency Down: the adjacency is
down.
• Fault detected - interface Down: the link (ILAN/
COLAN) is down.


The Visible NE Information option has a single table which displays all network
Each row lists the address information required to communicate with that
network element. The name column can be used to identify the network
element being queried.
The Visible NE Information is a dynamic list that is updated each time a

network element or circuit is added in the network. Use the Refresh button
each time a change is made.
Table 3-13
Editable
Name Character string (up Displays the system identifier (name) of the network No
to 20 characters) element.
ID ##.###.#.# Displays the id of network element. No
Protocol • OSI Displays the routing protocol used on the network No

• IP element.
Network Standard dot Displays the IP address of the network element. No

Address notation
Alternate Standard dot Displays the COLAN-X IP address. No

Address notation
MAC 12-hexadecimal Displays the MAC address of the network element. No

Address characters
Member • True Displays whether the shelf is a member in a No

• False consolidated node.
Site ID Integer value Displays the provisioned site identifier. No
Type Character string Displays the network element equipment type (for No
example, 6500).
Supported • Yes Displays whether network element is supported by Site No

• No Manager (only 6500 currently supported).
Additional Character string Displays additional information. No

Information


The IISIS Routing Table option has a single table which displays all network
The IISIS Routing Table supports a maximum of 150 nodes in a level 1 area.
A Routing Table Overflow alarm is raised if the 150 limit is exceeded.
Each row lists route information required to reach that network element. The
row with a cost of 0 and adjacency of 00:00:00:00:00:00 is the accessed
network element.
The IISIS Routing Table is a dynamic list that is updated each time a network
a change is made.
Table 3-14

Editable
Destination 12-hexadecimal Displays the MAC address of the destination element. No

characters
Adjacency 12-hexadecimal Displays the MAC address of the adjacent network element No
characters (00:00:00:00:00:00 is the accessed network element).
Cost 0 to 1023 Displays the OSI cost values (0 is the accessed network No
element).

The IP Routing Table option has a single table which displays the static routing
The IP Routing Table is a dynamic list that is updated each time a network
a change is made.

Table 3-15
Editable
IP Subnet Standard dot notation Displays the destination IP subnet of the No

static entry.
Subnet Mask Standard dot notation Displays the subnet mask of the table No
entries.
Next Hop Standard dot notation Displays the IP address of the next hop. No
External 1 to 65535 Displays the external cost of the link No

Cost (Note).
Circuit ID • SHELF-shelf Displays the circuit identifier of the port No

• COLAN-shelf-A used to get to the next hop.
• COLAN-shelf-X
• ILAN-shelf-IN1
• ILAN-shelf-IN2
• ILAN-shelf-IN3
• ILAN-shelf-OUT1
• ILAN-shelf-OUT2
• ILAN-shelf-OUT3
• LAN-shelf-41
• LAN-shelf-42
• SERIAL-shelf-X
• OTUTTP/ODUTTP/ODUCTP
Carrier • GCC0 Displays the carrier selected for the No
• GCC1 GCC (options available depend on
circuit pack type and function). Only
• GCC2 applicable to OTU service type facilities.

Table 3-15
IP Routing Table parameters (continued)

Editable

• Local
• IISIS
• OSPF
Tunnel - Displays the other node the tunnel is No
Termination terminated on.
are comparable to the link state metric. The type 2 metrics are assumed to be larger than the cost of
any intra-AS path. In this case, the external cost value will be shown in the External Cost parameter
while the regular link state metric cost value will be shown in the Cost parameter.

The OSPF Neighbors option has a single table which displays OSPF neighbor
The OSPF Neighbors table is a dynamic list that is updated each time
neighbor information is changed in the network. Use the Refresh button each
time a change is made.

Table 3-16
Editable
AID • COLAN-shelf-A Displays the circuit identifier of the neighbor. No

• COLAN-shelf-X
• ILAN-shelf-IN
• ILAN-shelf-OUT
• LAN-shelf-16/42
• SHELF-shelf
• CONTROL-shelf-
GROUP0
• CONTROL-shelf-
GROUP1
STM1J/STM4J/OTMn
ports
• OTUTTP/ODUTTP/
ODUCTP AID
Adjacency • ATTEMPT Displays the neighbor adjacency status. No

State • DOWN
• EXCHANGE
• EXCHANGESTART
• FULL
• INITIALIZING
• LOADING
• TWOWAY
• OTHER
Carrier • Section Displays the DCC or GCC channel. No

• Line
• GCC0
• GCC1
Neighbor IP Standard dot notation Displays the IP address of the neighbor. No
Neighbor Standard dot notation Displays the OSPF router ID of the neighbor. No
Router ID

Interfaces tab
ARP/ND Proxy parameters
The ARP/ND Proxy option contains two tabs: IPV4 and IPV6. The IPv6
options are not supported in this release.
The ARP/ND Proxy option has a single table. Use the Add button to provision
a new ARP Proxy IP address. Use the Delete button to delete an existing ARP
Proxy IP address.
Table 3-17
IPv4 ARP parameters
Editable
IP address Standard dot notation Displays the ARP Proxy IP address. No
Address range Address range, Single Determines if either an address range or a single Yes
or Single address address is added.
address
First address Standard dot notation Sets the first ARP Proxy IP address. Yes
Last address Standard dot notation Sets the last ARP Proxy IP address. Yes
Address Standard dot notation Enter the ARP Proxy IP address. Yes
Only applicable when Single address is selected.

The ARP/ND Table option contains two tabs: IPV4 and IPV6. The IPv6 options
are not supported in this release.
The ARP Table option has a single table which displays the dynamic routing
information. This table is read-only. The read-only ARP Time Out field is
displayed above the dynamic routing information table.

Table 3-18
ARP Table parameters
Editable
ARP time out 3600 Displays time in seconds before an inactive entry is No
removed from the table.
MAC Address 12-hexadecimal Displays the hardware MAC address of the No

characters destination host.
IP Address Standard dot notation Displays the IP address of the destination host. No
Unit • COLAN-shelf-A Displays the LAN interface used to connect to the No

• COLAN-shelf-X destination host.
• ILAN-shelf-IN1
• ILAN-shelf-IN2
• ILAN-shelf-IN3
• ILAN-shelf-OUT1
• ILAN-shelf-OUT2
• ILAN-shelf-
OUT3LAN-shelf-41
• LAN-shelf-42
Type • Local Displays the ARP entry type. Local indicates an No

• Dynamic entry associated with a destination local to the shelf.
Dynamic indicates a learned entry from the
• Broadcast network. Broadcast indicates the ARP entry used
• Point to Point when the destination IP is the broadcast address for
a subnet.

GNE parameter
The GNE option has a single table. The GNE pairs provide redundant DCN
comms access to remote nodes within the section. Use the Add button to
provision a new comms access and Delete button to delete an existing one.
Table 3-19
GNE parameters

Editable
Unit SHELF-shelf Displays the access identifier (AID) of the GNE. Yes
Configuration • Redundant Defines the GNE configuration. Yes

• Standalone
Access • NAT Sets the DCN access mechanism to be used. Yes

• ARP Private-IP GNE and ARP are not supported on
COLAN-A.
• OSPF
• Static
• PrivateIP
Group (Note 1 Integer value Specifies the redundancy group that the GNE Yes
and Note 2) between 1 and 255 belongs to for master/backup negotiation.
Primary • Yes Sets the GNE as being the preferred MASTER. Yes
(Note 2) • No (default)
GNE Subnet string of up to 36 Sets a unique name for the GNE. Yes
Name (Note 2) alphanumeric
characters
Note 1: It does not accept ‘0’ as first digit.

Note 2: It is a mandatory parameter if configuration is on REDUNDANT and Access is on ARP,
otherwise it is not applicable.
Note 3: This parameter is only applicable to Private IP Access.


The GNE Port Filter option has a single table. Use the Add button to provision
a new GNE port filter and Delete button to delete an existing one.
Table 3-20

Editable
AID PORTFILTER-shelf-1 to 10 Sets the access identifier (AID) of the GNE Yes
port filter.
Protocol TCP Sets the protocol of the destination port, Yes

UDP
Drop Port 1 to 65535 Sets the destination port, Yes
Access • ON (default) Determines whether the COLAN-X access Yes

COLAN-X • OFF filter is on or off,
Access • ON Determines whether the COLAN-A access Yes

COLAN-A • OFF (default) filter is on or off,
IP parameters
The IP option has a single table which displays all the provisioned ports. Use
the:
When deleting and then re-adding IP addresses on the COLAN and ILAN
ports, you must restart the network element by performing a cold restart on
the CTM before the new (added) IP addresses become active.
Note 1: Make sure the shelf IP address is different from the loopback
interface IP address configured through the SAOS CLI.
Note 2: The shelf must be restarted after changing the shelf IP address.
Note 3: Following an edit of the Control IP address on the primary shelf,
all member shelves of the TIDc must also be restarted. Otherwise, an
OSRP “Remote Node Unreachable” alarms can be raised against OSRP
links passing through these member shelves.
An IP entry is automatically added or deleted for an OTUTTP/ODUTTP/

ODUCTP AID when the associated PPP GCC entry is added or deleted.

Table 3-21
IPv4 IP parameters
Editable
Unit • SHELF-shelf Displays the provisioned ports. SHELF is the Yes

• COLAN-shelf-A circuitless IP.
• COLAN-shelf-X When adding an IP, the Add IP Parameters dialog

box lists the ports that are provisioned but do not have
• ILAN-shelf-IN1 IP addresses. If all the provisioned ports have IP
• ILAN-shelf-IN2 addresses, an error message is displayed and the
• ILAN-shelf-IN3 Add IP Parameters dialog box is not displayed. If you
select Apply in the Add IP Parameters dialog box and
• ILAN-shelf-OUT1 you are adding an IP address to the last provisioned
• ILAN-shelf-OUT2 port without an IP address, the Add IP Parameters
• ILAN-shelf-OUT3 dialog box closes.
• LAN-shelf-41 An IP address of 0.0.0.0 is assigned to OTUTTP/

ODUTTP AID automatically when PPP DCC/GCC is
• LAN-shelf-42 enabled and the circuit is created.
• SERIAL-shelf-41
• SERIAL-shelf-X
• CONTROL-shelf-
GROUP0
• CONTROL-shelf-
GROUP1
• OTUTTP/ODUTTP
AID
Carrier • GCC0 Sets the GCC carrier used (options available depend Yes
• GCC1 on circuit pack type and function). Only applicable to
Unit types with OTUTTP/ODUTTP AID.
• GCC2
IP Address Standard dot notation Sets the IP address for the selected port. Yes
Broadcast Standard dot notation Displays the IP broadcast address derived from the IP No
Address address and the subnet mask. Read-only.
Netmask Standard dot notation Sets the subnet mask for the selected port. Yes
SHELF netmask must be 255.255.255.255.
For the LAN-shelf-41 and LAN-shelf-42 ports, the
netmask is restricted to 255.255.255.252.
For un-numbered ILAN, the netmask is restricted to
255.255.255.255.
Default 1 to 255 (default 90) Sets the number of hops before a packet is dropped. Yes
Time to Live (Note)

Table 3-21
IPv4 IP parameters (continued)

Editable
Host Only The Host Only Mode option is displayed in Site

Mode Manager, but is not supported in this release.
Non-routing • On Sets the non-routing mode. When on, routing updates Yes
Mode • Off (default) are not propagated but packets are forwarded
through the interface.
ARP Proxy • On Sets the support for proxy ARP on the interface. Yes
• Off (default) This parameter is only visible when the Unit (facility
AID) is COLAN-X.
Network Management Displays the network domain. No

Domain Communications
Network
Note: It is only editable for SHELF AID in Add and Edit dialog in this release. Not editable for other AID.
LAN parameters
The LAN option has a single table which displays all the provisioned LAN
ports. Use the:
Note 1: Do not add IISIS circuits or OSPF circuits to LAN ports

provisioned with the non-routing mode set to On.
Note 2: If the port configuration is set to 100BT for the WSC port, the
actual traffic rate over the wayside channel should not exceed should not
exceed 40Mb/s. If the 6500 detects that the traffic rate exceeds this,
wayside traffic is rate-limited to avoid OSC link congestion.

Table 3-22
LAN parameters
Editable
Unit • LAN-shelf-41 Select the provisioned LAN ports. LAN-shelf-41 is Yes

• LAN-shelf-42 the craft LAN port on the CTM in slot 41 and
LAN-shelf-42 is the craft LAN port on the CTM in
• COLAN-shelf-A slot 42. Remaining ports are located on the access
• COLAN-shelf-X panel.
• ILAN-shelf-IN1
• ILAN-shelf-IN2
• ILAN-shelf-IN3
• ILAN-shelf-OUT1
• ILAN-shelf-OUT2
• ILAN-shelf-OUT3
Configuration • Automatic (default) Sets the port configuration for each provisioned Yes
(Note) • Full duplex 100BT LAN port. Full duplex 100BT is Full-Duplex
100 Mbit/s, Full duplex 1000BT is Full-Duplex
• Full duplex 1000BT 1000 Mbit/s and Automatic is auto-negotiation.
Negotiated • Half duplex 10BT Displays the negotiated port configuration. No

Configuration • Half duplex 100BT
• Half duplex 1000BT
• Disconnected
MAC Address 12-hexadecimal Displays the unique MAC address assigned to the No
characters LAN port.
Auto Neg • Auto (default) Sets the SyncE line timing mode. No
Control • Master Choose Master or Slave to request the LAN port
• Slave become a timing master or slave during negotiation.
Otherwise, leave at default value of Auto.
Valid only if Network Domain is set to PKT.

Table 3-22
LAN parameters (continued)

Editable
Network • MCN (default) Set to PKT if using port for SyncE. Otherwise, set to No
Domain • PKT MCN.
Port • ENABLED Displays whether the LAN port is enabled or No

• DISABLED (default) disabled.
For LAN ports provisioned as WSC ports “-” is
displayed
Note: If you set the LAN port configuration to Automatic (default), auto-negotiation is enabled.
Auto-negotiation automatically senses the speed/mode settings of the link. Use a straight-through cable
when connecting a PC to LAN-shelf-41 or LAN-shelf-42. Use a cross-over cable to connect 6500 NEs
together with ILAN. Use a straight-through cable when connecting COLAN port to the LAB LAN (It is
subject to change depending on what is connected to and what is configured).

The Lower Layer DCC/GCC option provides a single table which displays the
DCC/GCC parameters for any OTUTTP/ODUTTP/FTTP facilities which have
a lower layer DCC/GCC provisioned.
For information on GCC support on the circuit packs, refer to Table 3-23 on
page 3-58.
When the ODUk layer is terminated, the GCC1 overhead is terminated

whether the GCC1 channel is provisioned or not. When the ODUk layer is
monitored or transparent, the GCC1 overhead is passed through
transparently if the GCC1 channel is not provisioned.
Use the Add button to provision new DCC/GCC circuits and the Delete button
to delete existing DCC/GCC circuits. When adding a DCC/GCC circuit,
consider the following:
• Each end of the DCC/GCC circuit must be provisioned with the same
options.
• Once a new DCC/GCC circuit has been added, an IISIS or OSPF circuit
must be added for this port. See “IISIS Circuit parameters” on page 3-24
and “OSPF Circuit parameters” on page 3-31.
• You must delete the IISIS or OSPF circuit for the DCC/GCC circuit before
deleting the DCC/GCC circuit.

• To edit the DCC/GCC parameters (other than the L2 Side Role

parameter) for a Wayside LAN facility, you must delete the existing entry
and create a new one with the required values.
• For OTUTTP ports, a GCC0 circuit and an associated IISIS or OSPF
circuit are automatically created when the OTUTTP facility is provisioned
if the default auto GCC0 mode parameter is set to IISIS or OSPF in the
• For IPv4, adding or deleting a lower layer DCC/GCC entry with its Protocol
parameter set to PPP, automatically adds or deletes an associated PPP
circuit with IP address of 0.0.0.0.
For in-band communication between OSRP nodes, each facility on which

OSRP is enabled requires the GCC1/GCC2 channel to be allocated for Layer
1 control plane communications (neighbor discovery, topology discovery,
routing and signaling). This GCC channel requires the following parameters
and settings:
• Carrier = GCC1/GCC2
• Network Domain = SONET/SDH Control Plane or OTNCP
• Protocol = PPP (automatically set for the OTN CP network domain)

required on the GCC channel for OSRP communications.
If network domain is OTNCP, the OTUk rate must be 2, 3, 3E2, or 4.

Table 3-23
GCC support on 6500 T-Series circuit packs
20x10G SFP+ PKT/OTN I/F Module (NTK760AA) X X

GCC0 and GCC1 supported on OTUTTP line facility
40x10G SFP+ PKT/OTN I/F Module (NTK761AA) X X X

GCC0, GCC1, and GCC2 on OTUTTP line facility
2x100G CFP2 PKT/OTN I/F Module (NTK760BA) X X X

GCC0 and GCC1 supported on OTUTTP line facility
2x100G WaveLogic 3n C-Band PKT/OTN I/F Module X X X

(NTK760MJ/NTK760MK/NTK760ML/NTK760MM)
GCC0, GCC1, and GCC2 supported on OTU4 line
5x100G/12x40G QSFP28/QSFP+ PKT/OTN I/F (NTK762EA) X X X

GCC0, GCC1, and GCC2 on OTUTTP line facility
5x100G WaveLogic 3n CFP2-ACO PKT/OTN I/F (NTK762MA) X X X

GCC0, GCC1, and GCC2 on OTU4 line
500G 2xUSS X X X
• MCN GCC0 on OTUTTP facility
• GCC1 on ODUTTP facility.
• SCN GCC1 and GCC2 on OTUTTP facility
The above GCC comms are supported on four different pluggables
or ports: WLAi module, 5xQSFP, 12xPSFP, and host ports.

Table 3-24
Editable
Name OTUTTP/ODUTTP/ Displays all the provisioned OTUTTP/ODUTTP/ Yes

FTTP ports FTTP ports in the Add dialog. This parameter
appears only in the Add Lower Layer DCC/GCC
Parameters dialog box.
Unit OTUTTP/ODUTTP/ Displays the AID of the provisioned DCC/GCC link. No

FTTP AID
Carrier • GCC0 Sets the GCC carrier selected for the GCC (options Yes
Only applicable to Unit types with OTUTTP/
ODUTTP AID.
Operation • GCC0 Displays the status of the GCC circuit. No

Carrier • GCC1
• Disconnected
Protocol LAPD, NDP, PPP Select the LAPD, NDP, PPP, or Transparent radio Yes or No
(default), Transparent button to set the protocol of the DCC/GCC circuit. / depends
OTUTTP/ODUTTP/FTTP ports support PPP only, on facility
so 6500-T12 shelf and 6500-T24 shelf support PPP and carrier
only. NDP is only supported for inter-op between
6500 and 4200/CoreDirector (or older releases of
5400).
L2 Frame • 512 to 1492 (default Sets the LAPD frame size (only applicable to Yes for
Size 1304) for MCN LAPD). LAPD protocol is used internally in OTNCP MCN
• 9000 for OTNCP and this parameter cannot be changed. No for
CAUTION OTNCP
Each end of the DCC circuit must be provisioned
with the same LAPD frame size. Defaults on
different equipment types may be different.
L2 Side Role Automatic Displays the LAPD link mode (only applicable to No
LAPD).
Operation L2 • Network, User Displays the availability of L2 side role when adding No
Side Role • Disconnected a DCC/GCC circuit (only applicable to LAPD).

Table 3-24
Lower Layer DCC/GCC parameters (continued)

Editable
Mate OC-n/STM-n/STM0J/ Sets the Mate DCC (only applicable to the No

STM1J/STM4J Transparent option). Transparent DCC is not
supported on T-Series.
FCS Mode 16 bit (default), 32 bit Sets the frame check sequence (FCS) mode. Not No
applicable for T-Series.
Network • MCN (default) Indicates the communications network domain. Yes or No

Domain • SONET/SDH MCN for management communications network, depends
Control Plane SONET/SDH Control Plane or OTNCP for OSRP on facility
control plane network. and carrier
• OTNCP

NDP parameters
The NDP option has a single table which displays the NDP provisioning
information. The administration state of the NDP feature is displayed in the
Admin State field above the table.
Use the Edit button to edit the Admin state to enable or disable the NDP
feature on the shelf. The Shelf IP must be provisioned before you can enable
the NDP feature on the shelf. Use the Add button to enable NDP on an
ODUTTP or OTUTTP facility. Use the Delete button to disable NDP on an
ODUTTP or OTUTTP facility.
Table 3-25
NDP parameters

Editable
Admin State • Disabled (default) Displays the administration state of the NDP feature. Yes
• Enabled
Unit OTUTTP AID Displays the ODUTTP or OTUTTP facility AID. Yes
ODUTTP AID
Carrier • GCC0 Displays the carrier selected for the GCC. Yes
• GCC1

PPP parameters
The PPP option has a single table which displays entries for the ports
configured for PPP. Use the Edit button to edit the PPP magic number support
parameter.
Table 3-26
PPP parameters
Editable
Unit SERIAL-shelf-X, Displays the RS-232 serial ports and optical No

OTUTTP/ODUTTP AID ports available for PPP. SERIAL-shelf- 41 is on
the CTM.
Carrier • GCC0 Selects the carrier for the GCC circuit. Only Yes
• GCC1 applicable to OTUTTP/ODUTTP AID.
Frame Size 64 to 4470 Displays the PPP frame size. No

(default 1500)
Negotiated 64 to 4470 Displays the negotiated frame size. Read-only. No

Frame Size
Preferred 16 bits (default), 32 bits, Displays the preferred frame checksum value. No
Frame Off
Checksum
Magic • On Sets whether magic number is supported on the Yes

Number • Off (default) PPP circuit. The magic number is used for
Support detecting links that are in the looped-back
condition.
Security Type • Off (default) Displays the security used on the PPP circuit. No
• CHAP
• PAP
Local Secret Up to 253 character string Displays the local secret when the Security type No
is CHAP or PAP.
Remote Up to 253 character string Displays the remote secret when the Security No
Secret type is CHAP or PAP.
IP Header • On Displays the IP header compression status. No
Compression • Off (default)
Heartbeat • On (default) Displays whether heartbeat generation and No

• Off detection is supported.
Peer IP Standard dot notation Displays the IP address of the remote end No
Address device.

The Serial/RS-232 option has a single table which displays information on the
serial ports. The table is read-only.
Note: It is recommended that the serial port on a PC connected to the

6500 is set to either 9600 or 19200.
Table 3-27

Editable
Unit SERIAL-shelf-X Displays possible RS-232 serial ports. No

Protocol • Auto (default) Displays the protocol for the serial port. No
• PPP
• VT100
Protocol 60 to 3600 Displays the period of inactivity before a PPP No

Timeout (default 300) configured serial port reverts to the default mode.
Negotiated • 60 to 3600 Displays the negotiated protocol. For this No
Protocol • Disconnected release, Disconnected is displayed irrespective
of the negotiated protocol.
Baud Rate • 9600 Displays the baud for the serial port. No
• 19200
• 38400
• 57600
• 115200
• Auto (default)
Negotiated • 9600 Displays the negotiated baud. For this release, No
Baud Rate • 19200 Disconnected is displayed irrespective of the
negotiated baud.
• 38400
• 57600
• 115200
• Disconnected
Data Bits •4 Displays the number of data bits. No

•5
•6
•7
• 8 (default)

Table 3-27
Serial/RS-232 parameters (continued)

Editable
Parity • None (default) Displays the parity. No

• Odd
• Even
• Mark
• Space
Stop Bits • 1 (default) Displays the number of stop bits. No

• 1.5
•2
Hardware • On Displays whether hardware flow control is used. No
Flow Control • Off (default)

The TL1 Gateway Connections option has a single table which displays
information on the TL1 Gateway Connections. The table is read-only.
Table 3-28

Editable
NE Name string Displays the TID of the RNE. No
Session 1 to 18 A unique number assigned by the system to identify the user No

telnet session.
Status • UP Displays the status of the TL1 gateway connection. No

• DOWN • UP – the connection to the RNE is up
• DOWN – the connection to the RNE is down
Protocol • ISO Displays the protocol used by the TL1 gateway to access the No
• INET RNE.
• ISO – 7 layer OSI protocol
• INET – TCP/IP protocol

USB parameters
The USB option has a single table which displays status of the CTM USB
ports. The table is read-only. The USB port on the CTM is reserved for future
use.
Table 3-29
USB parameters

Editable
Unit/Name USB-shelf-slot-1 Displays the USB port ID. The slot number is the CTM No
USB-shelf-slot-2 slot number.
Automount • ON Specifies whether to automount a USB device when Yes

• OFF connected to a USB port.
Status • Mounted Displays the status of the USB port. No

• Unmounted
• Empty
Failure See description Displays the description of the failure if the USB device No
Description is failed:
• USB Ok
• Host Error Condition
• USB Not Supported
• Failure During Mount
• USB Disabled

Services tab
DHCP parameters
The DHCP option has a single table with a single entry. Use the Edit button to
edit the DHCP parameters.
Table 3-30
DHCP parameters

Editable
Unit LAN-shelf-15 (or 41) Displays the LAN port available for the DHCP. No
LAN-shelf-16 (or 42)
IPv4 Server • On (default) Sets the status of the DHCP IPv4 server on the craft Yes
• Off LAN port.
IPv6 Server • On Not available for this release. No

• Off (default)
FTP parameters
The FTP option has a single table with a single entry. Use the Edit button to
edit the FTP parameters.
Table 3-31
FTP parameters

Editable
Server • Disabled Sets the status of the ftp server. Yes

(default)
• Enabled
Maximum 8 Displays the maximum number of concurrent FTP No

number of FTP sessions that are allowed to the network element.
sessions
Idle timeout 1 to 900 Sets the time (in seconds) before an idle ftp session is Yes
(seconds) (default is 180) disconnected.

NETCONF parameters
The NETCONF option has a single table with a single entry. Use the Edit
button to edit the NETCONF parameter.
Table 3-32
NETCONF parameters

Editable
State • Enabled Sets the status of the NETCONF protocol access. Yes
• Disabled (default)
The SSH/Telnet option has a single table with a single entry. Use the Edit
button to edit the SSH parameters.
Table 3-33

Editable
SSH Server • Enabled (default) Sets the status of the SSH server. Yes
• Disabled Note: An SSH server cannot be disabled unless a
telnet server is enabled.
Telnet Server • Enabled (default) Sets the status of the telnet server. Yes
• Disabled Note: A telnet server cannot be disabled unless an
SSH server is enabled.
SSH 1 to 18 (default 3) Sets the maximum number of concurrent SSH Yes

number of Note 1: If both SSH and Telnet servers are enabled,
SSH the total maximum number of SSH and Telnet sessions
sessions on the NE cannot exceed 31. For example, if SSH is
enabled with 20 maximum sessions, you cannot have
more than 11 enabled Telnet sessions. To increase the
maximum number of Telnet sessions, you must first
reduce the maximum number of SSH sessions.
Note 2: Within 31 maximum number of Telnet and
SSH sessions, up to 18 (Telnet & SSH combined) TL1
sessions are supported on each CTM; CTM-41/42.
Debug port has maximum of 5 sessions and each SSH
or Telnet connection consumes one session. Each TL1
gateway session, whether reaching GNE or RNE will
count as one SSH/Telnet session on the gateway NE.

Table 3-33

Editable
Telnet 1 to 18 (default 18) Sets the maximum number of concurrent SSH Yes
number of Note 1: If both SSH and Telnet servers are enabled,
telnet the total maximum number of SSH and Telnet sessions
sessions on the NE cannot exceed 31. For example, if SSH is
enabled with 20 maximum sessions, you cannot have
more than 11 enabled Telnet sessions. To increase the
maximum number of Telnet sessions, you must first
reduce the maximum number of SSH sessions.
Note 2: Within 31 maximum number of Telnet and
SSH sessions, up to 18 (Telnet & SSH combined) TL1
sessions are supported on each CTM; CTM-41/42.
Debug port has maximum of 5 sessions and each SSH
or Telnet connection consumes one session. Each TL1
gateway session, whether reaching GNE or RNE will
count as one SSH/Telnet session on the gateway NE.
SSH Idle 0 to 99 (default 30) Sets the time (in minutes) before an idle SSH session Yes
(minutes) timeout).
Telnet Idle 0 to 99 (default 30) Sets the time (in minutes) before an idle Telnet session Yes
(minutes) timeout).
SSH CIPHER • AES128CTR Select the check box(es) to enable the corresponding Yes
• AES128CBC secure shell (SSH) cipher(s).
• AES192CTR
• AES192CBC
• AES256CTR
• AES256CBC
• RIJNDAEL128CBC
• RIJNDAEL192CBC
• RIJNDAEL256CBC
• 3DESCBC
SSH HMAC • MD5 Select the check box(es) to enable the corresponding Yes
• MD596 secure shell (SSH) hash message authentication
codes (HMACs).
• SHA1
• SHA196
• SHA256

Table 3-33

Editable
SSH Key Exchange

Host Key • DSA Select the check box(es) to enable the corresponding Yes
Algorithms • RSA host key algorithm(s).
Key • DH-GROUP1 Select the check box(es) to enable the corresponding Yes
Exchange • DH-GROUP14 key exchange method(s):
Method
• ECDH-SHA2-NISTP • DH-GROUP1 corresponds to Diffie-Hellman Group 1
256 key exchange.
• ECDH-SHA2-NISTP • DH-GROUP14 corresponds to Diffie-Hellman Group

384 14 key exchange.
• ECDH-SHA2-NISTP256 corresponds to Elliptic
Curve Diffie-Hellman (ECDH) key exchange method
with ephemeral keys generated on the NISTP256
curve.
• ECDH-SHA2-NISTP384 corresponds to Elliptic
Curve Diffie-Hellman (ECDH) key exchange method
with ephemeral keys generated on the NISTP384
curve
Key • Yes Select whether key re-exchange is enabled (Yes) or Yes

Re-Exchange • No (default) disabled (No).
The key re-exchange feature forces SSH sessions to
renegotiate their session keys after 500 MB of data is
transferred or after 1 hour of time has elapsed since
the last key exchange.
SSH Client
Host Key • Yes Select whether host key validation is enabled (Yes) or Yes
Validation • No (default) disabled (No).
Host Key Validation enables the SFTP client to
validate a remote SFTP server's host key. If the remote
SFTP server's host key is not contained within the
known host key list, the connection is denied.
SSH Server
Server Auth • None (default) Select the SSH server authentication method. Yes
• Public Key Note: The 6500 always requires authentication in its
applications and this enforces additional
authentication at the SSH layer.

Table 3-33

Editable
SSH Log Level

Log Level • 1 (default) Select the SSH log level: Yes
•2 • Level 1 supports connection logs (including SFTP
client connection logs).
• Level 2 adds SSH server connection logs.
The HTTP/HTTPS option has a single table with a single entry. Use the Edit
button to edit the HTTP/HTTPS parameter.
Table 3-34

Editable
HTTP server • Enabled (default) Sets the status of the HTTP protocol access. Yes
• Disabled
HTTPS server • Enabled (default) Sets the status of the HTTPS protocol access. Yes
• Disabled


The NAT Configuration option has a single table with a single entry. Use the
Edit button to edit the NAT Configuration parameter.
Table 3-35

Editable
NAT Starting 1024 to 65535 Sets the base UDP/TCP port value dynamically Yes
Port allocated for connection flows managed by NAT
services. It applies to Redundant NAT.
NAT Number 256 to 1024 Specifies the number of UDP/TCP port values Yes
of Entries dynamically allocated for connection flows managed by
NAT services. It applies to Redundant NAT.


6500 Packet-Optical Platform
Data Communications Planning and User Guide
Copyright© 2017-2019 Ciena® Corporation. All rights reserved.
Release 12.6
Publication: 323-1851-101
Document status: Standard
Issue 1
Document release date: September 2019
CONTACT CIENA
For additional information, office locations, and phone numbers, please visit the Ciena
web site at www.ciena.com

323-1851-101 (6500 R12.6 Datacomms Planning Procedures) Issue1 PDF

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

323-1851-101 (6500 R12.6 Datacomms Planning Procedures) Issue1 PDF

Caricato da

Copyright:

Formati disponibili

6500 Packet-Optical Platform

Data Communications Planning and

323-1851-101 - Standard Issue 1

6500 Packet-Optical Platform Data Communications Planning and User Guide

6500 Packet-Optical Platform Data Communications Planning and User Guide

6500 Packet-Optical Platform Data Communications Planning and User Guide

New in this release and documentation roadmap xi

Data communications planning 1-1

6500 Packet-Optical Platform Data Communications Planning and User Guide

6500 Packet-Optical Platform Data Communications Planning and User Guide

OSPF Multi-Area Adjacency (OMA, T-Series shelves only) 1-146

6500 Packet-Optical Platform Data Communications Planning and User Guide

DCN example 27—IPv6 statically routed GNE configuration 1-312

6500 Packet-Optical Platform Data Communications Planning and User Guide

IP networks, addressing, and masks 1-422

Comms setting management procedures for D-Series and

Comms setting management procedures for T-Series 3-1

6500 Packet-Optical Platform Data Communications Planning and User Guide

6500 Packet-Optical Platform Data Communications Planning and User Guide

New in this release and documentation

This Technical Publication supports 6500 Packet-Optical Platform (6500)

The following new/enhanced features are covered in this document:

6500 technical publications

6500 Packet-Optical Platform Data Communications Planning and User Guide

6500 D-Series and S-Series roadmap

Planning a Network Installing, Managing and Maintaining and Circuit Pack-Based

Documentation Installation - Administration Fault Management - Common Equipment

SAOS-based Command Fault and MIB

6500 Packet-Optical Platform Data Communications Planning and User Guide

6500 T-Series roadmap

Planning a Network Installing, Managing and Maintaining and

T-Series Administration Fault Management -

SAOS-based Command Fault and MIB

6500 Packet-Optical Platform Data Communications Planning and User Guide

6500 Packet-Optical Platform Data Communications Planning and User Guide

Data communications planning 1-

This chapter also provides information on typical Data Communications

For related procedure and parameter information for D-Series/S-Series

It is recommended to review Commissioning and Testing, 323-1851-221 and

For detailed datacomm guidelines for submarine applications, refer to the

Note: Unless otherwise specified, eMOTR in this document refers to

6500 Packet-Optical Platform Data Communications Planning and User Guide

Other product name short forms are used as follows:

“6500 network element (NE) data communication interfaces” on page 1-7

“6500 network element (NE) IPv4 addressing” on page 1-37

“6500 network element (NE) IPv6 addressing” on page 1-42

“6500 network element (NE) internal routing protocols” on page 1-45

“6500 network element (NE) IPv4 supported protocols” on page 1-61

“IPv4 external DCN connectivity—Public IP address model” on page 1-84

“IPv4 external DCN connectivity—Private-IP address model” on page 1-85

“General DCN provisioning rules” on page 1-97

“TID consolidation (TIDc)” on page 1-107

“SONET/SDH, OTN, and Photonic Control Plane considerations” on page 1-115

“Opaque LSAs” on page 1-130

“Site-Level Data Distribution (SLDD)” on page 1-142

6500 Packet-Optical Platform Data Communications Planning and User Guide

“Service and Photonic layer interoperability (SPLI)” on page 1-146

“OSPF RFC 2328-compatible ABR (T-Series shelves only)” on page 1-149

“DCN design examples” on page 1-153

“FTP/FTAM Bridge (file transfer translation device)” on page 1-327

“OSI data communications on the 6500” on page 1-330

“6500 DCC transparency” on page 1-330

“6500 and CPL interworking” on page 1-333