009-3240-008 (39XX 51XX SAOS 6.12 Configuration) RevA

39XX/51XX Service Delivery and Aggregation
Switches
Configuration
SAOS 6.12
Whats inside...
New in this release
Configuration fundamentals
Configuration management
Port management
Hardware resource management
System timing configuration
Link Layer Discovery Protocol (LLDP) configuration
VLAN management
IP management
MEF L2 VPN configuration
Provider Backbone Bridge Traffic Engineering (PBB-TE) implementation
Multiprotocol Label Switching (MPLS) configuration
L2 control frame tunneling configuration
Quality of Service configuration
Multicast services configuration
PWE services configuration
Error codes
009-3240-008 - Standard Revision A

May 2014
Copyright 2012-2014 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.
Copyright 2012-2014 Ciena Corporation. All Rights Reserved
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-CIENA24 (243-6224)
410-865-4961
In Europe, Middle East, 800-CIENA-24-7 (800-2436-2247)
and Africa +44-207-012-5508
In Asia-Pacific 800-CIENA-24-7 (800-2436-2247)
+81-3-6367-3989
+91-124-4340-600
In Caribbean and Latin 800-CIENA-24-7 (800-2436-2247)
America 410-865-4944 (USA)
Sales and General Information 410-694-5700 E-mail: sales@ciena.com
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-124-434-0500 E-mail: sales@ciena.com
In Latin America 011-5255-1719-0220 (Mexico City) E-mail: sales@ciena.com
Training 877-CIENA-TD (243-6283) E-mail: techtng@ciena.com
or 410-865-8996
For additional office locations and phone numbers, please visit the Ciena web site at www.ciena.com.
39XX/51XX Service Delivery and Aggregation Switches Configuration

SAOS 6.12 009-3240-008 Standard Revision A
Copyright 2012-2014 Ciena Corporation May 2014
IMPORTANT: PLEASE READ THIS LICENSE AGREEMENT (AGREEMENT) CAREFULLY BEFORE
INSTALLING OR USING CIENA CORPORATION (Ciena) SOFTWARE, HARDWARE OR DOCUMENTATION
(COLLECTIVELY, THE EQUIPMENT).
BY INSTALLING OR USING THE EQUIPMENT, YOU ACKNOWLEDGE THAT YOU HAVE READ THIS
AGREEMENT AND AGREE TO BE BOUND BY ITS TERMS AND CONDITIONS.
1. Right to Use License; Restrictions. Subject to these terms, and the payment of all applicable license fees,
Ciena grants to you, as end user, a non-exclusive license to use the Ciena software (the Software) in object code
form solely in connection with, and as embedded within, the Equipment,. You shall have the right to use the
Software solely for your own internal use and benefit. You may make one copy of the Software and documentation
solely for backup and archival purpose, however you must reproduce and affix all copyright and other proprietary
rights notices that appear in or on the original. You may not, without Ciena's prior written consent, (i) sublicense,
assign, sell, rent, lend, lease, transfer or otherwise distribute the Software; (ii) grant any rights in the Software or
documentation not expressly authorized herein; (iii) modify the Software nor provide any third person the means to
do the same; (iv) create derivative works, translate, disassemble, recompile, reverse engineer or attempt to obtain
the source code of the Software in any way; or (v) alter, destroy, or otherwise remove any proprietary notices or
labels on or embedded within the Software or documentation. You acknowledge that this license is subject to
Section 365 of the U.S. Bankruptcy Code and requires Ciena's consent to any assignment related to a bankruptcy
proceeding. Sole title to the Software and documentation, to any derivative works, and to any associated patents
and copyrights, remains with Ciena or its licensors. Ciena reserves to itself and its licensors all rights in the
Software and documentation not expressly granted to you. You shall preserve intact any notice of copyright,
trademark, logo, legend or other notice of ownership from any original or copies of the Software or documentation.
2. Audit: Upon Ciena's reasonable request, but not more frequently than annually without reasonable cause, you
shall permit Ciena to audit the use of the Software at such times as may be mutually agreed upon to ensure
compliance with this Agreement.
3. Confidentiality. You agree that you will receive confidential or proprietary information (Confidential Information)
in connection with the purchase, deployment and use of the Equipment. You will not disclose Confidential
Information to any third party without prior written consent of Ciena, will use it only for purposes for which it was
disclosed, use your best efforts to prevent and protect the contents of the Software from unauthorized disclosure or
use, and must treat it with the same degree of care as you do your own similar information, but with no less than
reasonable care. You acknowledge that the design and structure of the Software constitute trade secrets and/or
copyrighted materials of Ciena and agree that the Equipment is Confidential Information for purposes of this
Agreement.
4. 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 Equipment and any accompanying technical
data (collectively Materials) are commercial within the meaning of applicable Federal acquisition regulations.
These Materials were developed fully at private expense. U.S. Government use of the Materials is restricted by this
Agreement, and all other U.S. Government use is prohibited. In accordance with FAR 12.212 and DFAR
Supplement 227.7202, software delivered to you is commercial computer software and the use of that software is
further restricted by this Agreement.
5. Term of License. This license is effective until terminated. Customer may terminate this license at any time by
giving written notice to Ciena [or] and destroying or erasing all copies of Software including any documentation.
Ciena may terminate this Agreement and your license to the Software immediately by giving you written notice of
termination in the event that either (i) you breach any term or condition of this Agreement or (ii) you are wound up
other than voluntarily for the purposes of amalgamation or reorganization, have a receiver appointed or enter into
liquidation or bankruptcy or analogous process in your home country. Termination shall be without prejudice to any
other rights or remedies Ciena may have. In the event of any termination you will have no right to keep or use the
Software or any copy of the Software for any purpose and you shall destroy and erase all copies of such Software in
its possession or control, and forward written certification to Ciena that all such copies of Software have been
destroyed or erased.
6. Compliance with laws. You agree to comply with all applicable laws, including all import regulations, and to
obtain all required licenses and permits related to installation and use of Equipment. Software, including technical
data, is subject to U.S. export control laws, including the U.S. Export Administration Act and its associated
regulations, and may be subject to export or import regulations in other countries. Customer agrees to comply
strictly with all such regulations and acknowledges that it has the responsibility to obtain licenses to export, re-
export, or import Software.

7. Limitation of Liability. ANY LIABILITY OF Ciena SHALL BE LIMITED IN THE AGGREGATE TO THE
AMOUNTS PAID BY YOU 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 THIRD-PARTY SUPPLIER OF Ciena. NEITHER Ciena NOR ANY OF
ITS THIRD-PARTY SUPPLIERS 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
8. General. Ciena may assign this Agreement to any Ciena affiliate or to a purchaser of the intellectual property
rights in the Software, but otherwise neither this Agreement nor any rights hereunder may be assigned nor duties
delegated by either party, and any attempt to do so will be void. This Agreement shall be governed by the laws of
the State of Maryland (without regard to the conflict of laws provisions) and shall be enforceable in the courts of
Maryland. The U.N. Convention on Contracts for the International Sale of Goods shall not apply hereto. This
Agreement constitutes the complete and exclusive statement of 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
Publication history 0
May 2014
Revision A Standard
First Standard release of this document for SAOS 6.12.

vi Publication history

vii
Contents 0
About this document xix
New in this release 1-1
Configuration fundamentals 2-1

Ports 2-1
Hardware resources 2-1
System timing 2-2
Link Layer Discovery Protocol 2-2
Virtual Local Area Networks 2-2
IP management 2-3
Metro Ethernet Forum Layer 2 Virtual Private Networks 2-3
Provider Backbone Bridge Traffic Engineering 2-4
Multiprotocol Label Switching 2-4
Layer 2 control frame tunneling 2-4
Quality of Service 2-6
Multicast services 2-7
Configuration management 3-1

Accessing the CLI 3-1
Configuration files 3-1
List of procedures
3-1 Saving configuration changes 3-3
3-2 Displaying configuration files 3-4
3-3 Augmenting the current configuration 3-5
3-4 Restoring default configurations 3-7
3-5 Setting the default configuration files 3-8
3-6 Displaying the default configuration files 3-9
3-7 Resetting default configuration files to factory default files 3-10
Port management 4-1

Port attributes 4-1
Port loopback 4-5
Port statistics 4-6
Transceivers 4-9
Identification 4-9
Diagnostics 4-10

viii Contents
List of procedures
4-1 Setting port attributes 4-13
4-2 Resetting port attributes to default 4-14
4-3 Disabling a port 4-15
4-4 Enabling a port 4-16
4-5 Displaying port attributes 4-17
4-6 Displaying port statistics 4-18
4-7 Monitoring port statistics 4-23
4-8 Clearing current statistics 4-28
4-9 Displaying blade information 4-29
4-10 Displaying port capabilities 4-33
4-11 Displaying port Ethernet configuration 4-35
4-12 Displaying port status 4-36
4-13 Displaying a list of supported optics 4-37
4-14 Displaying transceiver information 4-38
4-15 Determining transceiver speed 4-41
4-16 Tuning XFP transceivers 4-43
4-17 Setting the port connector mode 4-45
Hardware resource management 5-1

List of procedures
5-1 Configuring resources 5-7
5-2 Freeing all accelerated CFM over PBB-TE resources 5-9
5-3 Restoring accelerated CFM over PBB-TE resources to default values 5-11
5-4 Freeing all broadcast containment resources 5-13
5-5 Restoring broadcast containment resources to default values 5-14
5-6 Freeing CFM resources 5-16
5-7 Restoring CFM resources to default values 5-17
5-8 Freeing DHCP relay resources 5-19
5-9 Restoring DHCP relay resources to default values 5-20
5-10 Configuring loss measurement resources 5-22
5-11 Freeing all loss measurement resources 5-24
5-12 Freeing traffic profiling resources 5-25
5-13 Setting traffic profiling resources 5-27
5-14 Restoring traffic profiling resources to default values 5-30
5-15 Freeing virtual circuit statistics resources 5-32
5-16 Restoring virtual circuit statistics resources to default values 5-33
5-17 Configuring virtual switch L2 enhanced transform resources 5-35
5-18 Freeing all virtual switch L2 enhanced transform resources 5-37
5-19 Configuring transport OAM resources 5-38
5-20 Freeing all transport OAM resources 5-40
5-21 Displaying resource configuration information 5-41
5-22 Resolving resource configuration validation errors 5-42
5-23 Addressing classifier resource allocation too small for current configuration
error 5-43
5-24 Displaying resource configuration in the configuration file 5-45
System timing configuration 6-1

Contents ix
Synchronous Ethernet 6-2

IEEE 1588 version 2 Precision Time Protocol 6-4
External timing interfaces 6-4
BITS 6-4
GPS 6-5
Clock selection algorithm 6-5
Quality level value definition 6-7
Frequency, phase and time-of-day configuration rules 6-11
Holdover interval 6-12
PTP clock type 6-12
Network configuration examples 6-13
Procedures 6-17
List of procedures
6-1 Enabling and disabling synchronization 6-19
6-2 Configuring synchronization 6-20
6-3 Configuring the PTP timing global attributes 6-23
6-4 Configuring global attributes for PTP input timing 6-25
6-5 Configuring global attributes for PTP output timing 6-26
6-6 Configuring global attributes for GPS output timing 6-27
6-7 Configuring SyncE input references 6-28
6-8 Configuring BITS input references 6-30
6-9 Configuring PTP input references 6-33
6-10 Configuring GPS input references 6-35
6-11 Configuring TDM input references 6-37
6-12 Configuring SyncE output references 6-39
6-13 Configuring BITS output reference 6-40
6-14 Configuring PTP output timing references 6-42
6-15 Configuring GPS output references 6-43
6-16 Configuring protection-groups 6-44
6-17 Clearing timing statistics 6-52
6-18 Displaying information for synchronization 6-53
6-19 Displaying SyncE information 6-57
6-20 Displaying BITS information 6-60
6-21 Displaying PTP information 6-63
6-22 Displaying GPS information 6-69
6-23 Displaying TDM information 6-72
6-24 Displaying frequency information 6-74
6-25 Displaying phase information 6-76
6-26 Displaying time-of-day information 6-78
6-27 Displaying protection-group information 6-80
6-28 Sample configuration: system timing by means of SyncE and PTP 6-83
6-29 Sample configuration: system timing by means of PTP Boundary Clock 6-85
Link Layer Discovery Protocol (LLDP) configuration 7-1

LLDP TLVs 7-3
Feature Benefits 7-6
List of procedures
7-1 Configuring LLDP 7-8
7-2 Configuring TLV transmission 7-10

x Contents
7-3 Displaying LLDP neighbors 7-12

7-4 Enabling and disabling SNMP notifications 7-13
VLAN management 8-1

VLANs and traffic flow 8-1
Acceptable Frame Types 8-1
Port VLAN ID 8-2
VLAN Ingress Filter 8-2
Egress Untagged VLAN 8-3
Behavior summary 8-4
VLAN/port configuration 8-4
VLAN translation 8-5
List of procedures
8-1 Changing the TPID stamp for a VLAN 8-7
8-2 Configuring a VLAN/port pair to ingress tagged traffic and egress tagged
traffic 8-8
8-3 Configuring a VLAN/port pair to ingress untagged traffic and egress untagged
traffic 8-10
8-4 Changing tag status 8-11
8-5 Configuring hybrid traffic 8-13
8-6 Emulating a tagged Ethernet port 8-14
8-7 Translating a single NNI VLAN 8-15
8-8 Translating a dual NNI VLAN 8-17
IP management 9-1
IPv6 9-1
IPv6 address format 9-1
IP address usage 9-2
EVC ping 9-5
Local EVC ping 9-7
List of procedures
9-1 Creating interfaces 9-11
9-2 Deleting an IP or loopback interface 9-14
9-3 Modifying an IP or loopback interface 9-15
9-4 Disabling an IP interface 9-16
9-5 Enabling an IP interface 9-17
9-6 Configuring IPv6 interfaces manually 9-18
9-7 Displaying an IP interface 9-20
9-8 Adding an IP route 9-24
9-9 Removing an IP route 9-25
9-10 Displaying the routing table 9-26
9-11 Displaying FIB entries 9-27
9-12 Enabling Layer 3 switching 9-29
9-13 Disabling Layer 3 switching 9-30
9-14 Displaying the status of Layer 3 switching 9-31
9-15 Clearing all FIB or AIB entries 9-32
9-16 Enabling logging of FIB or AIB events 9-33
9-17 Displaying FIB information 9-34

Contents xi
9-18 Adding a static ARP entry 9-35

9-19 Removing static ARP entries 9-36
9-20 Configuring EVC ping for use case A 9-37
9-21 Configuring EVC ping for use case B 9-42
9-22 Configuring EVC ping for use case C 9-46
9-23 Configuring EVC ping for use case D 9-50
9-24 Configuring EVC ping for use case E 9-55
9-25 Displaying static ARP entries 9-60
9-26 Displaying the AIB table 9-61
MEF L2 VPN configuration 10-1

Overview 10-1
Ethernet Service Types 10-2
E-Line Service Type 10-2
E-LAN Service Type 10-3
E-Tree Service Type 10-4
E-Access Service Type 10-5
Q-in-Q encapsulation 10-6
EPL and EVPL Provider Bridge configuration 10-6
Provider VLAN 10-7
Reserved VLAN 10-8
Virtual switch 10-8
Virtual circuits 10-9
Frame flooding behavior 10-10
Q-in-Q Ethertype 10-11
EVPL CoS 10-11
Virtual Switch CoS Policies 10-12
Virtual switch Member CoS Policy Override 10-12
EVPL Bundling 10-13
VLAN translation 10-14
Ingress push; egress pop (i-push,e-pop) 10-14
Ingress push; egress pop and stamp (i-push,e-pop:stamp) 10-15
Ingress stamp; egress match, pop, and stamp (i-stamp:push,e-match-
pop:stamp) 10-15
Private forwarding groups 10-17
L2-based PFG Forwarding policy sets 10-20
Port-based PFG egress profile 10-22
Port membership 10-24
Upgrading and downgrading a device 10-25
External Network-to-Network Interface Hairpin 10-26
Sub-port interfaces 10-26
List of procedures
10-1 Creating an EPL provider bridge 10-30
10-2 Creating an EVPL provider bridge 10-32
10-3 Configuring the fixed encapsulation priority value 10-34
10-4 Setting the CoS policy when adding VS members 10-35
10-5 Handling ingress untagged frames 10-36
10-6 Setting the L2 transform action on a port 10-38
10-7 Creating an i-push, e-pop Q-in-Q VS configuration 10-39

xii Contents
10-8 Creating a VS configuration with UNI only with bundled CVIDs 10-41
10-9 Creating an i-push, e-pop: stamp configuration 10-43
10-10 Creating an i-stamp:push,e-match-pop:stamp configuration 10-46
10-11 Configuring L2 PFGs 10-49
10-12 Configuring port-based PFGs 10-53
10-13 Configuring egress profile with traffic types 10-57
10-14 Disabling the PFG feature 10-60
10-15 Displaying the configuration of EVPL VS members 10-61
10-16 Displaying virtual switches 10-62
10-17 Displaying PFG information 10-63
10-18 Configuring EPL and EVPL for E-Access service types 10-65
10-19 Configuring CFM for E-Access service types 10-68
10-20 Configuring HIM for E-Access service types 10-71
10-21 Configuring L2 Control Frame Tunneling for E-Access service types 10-73
10-22 Configuring RFC 2544 Benchmarking for E-Access 10-74
Example 10-77
10-23 Configuring ENNI hairpin switching using sub-ports 10-79
10-24 Displaying statistics for sub-port interfaces 10-82
10-25 Clearing statistics for sub-port interfaces 10-84
Provider Backbone Bridge Traffic Engineering (PBB-TE)

implementation 11-1
VLAN Tagging 11-2
Q-in-Q 11-2
MAC Header Encapsulation 11-3
PBB-TE Tunnels 11-4
Connectivity Fault Management 11-7
PBB-TE Dual Homing 11-9
Tunnel Pairing and Synchronization 11-9
Benefits 11-10
List of procedures
11-1 Verifying that a port can participate in PBB-TE 11-12
11-2 Switching from non-native to native PBB-TE support 11-13
11-3 Enabling tunnel synchronization 11-14
11-4 Disabling tunnel synchronization 11-15
11-5 Configuring PBB-TE 11-16
11-6 Releasing reserved BVIDs 11-33
11-7 Displaying PBB-TE information 11-34
Multiprotocol Label Switching (MPLS) configuration 12-1

Overview 12-3
MPLS label operations 12-4
Implicit NULL label 12-5
Explicit NULL label 12-5
Router alert label 12-5
MPLS label format 12-5
MPLS-Traffic Engineering 12-6
MPLS-Transport Profile 12-6

Contents xiii
Interfaces 12-6
Tunnels 12-7
Next-hop diversity 12-10
Tunnel FEC for static LSP 12-11
Tunnel profiles 12-12
CoS profiles 12-12
Fast ReRoute profiles 12-12
MPLS L2 VPN services 12-13
VPWS 12-15
VPLS 12-16
H-VPLS 12-17
VPLS membership and MAC learning 12-18
Virtual circuits 12-19
Comparing raw and tagged PW type for virtual circuits 12-19
Virtual circuit connectivity verification profile configuration 12-22
Routing protocols 12-23
OSPF 12-23
IS-IS 12-24
Signaling protocols 12-25
RSVP-TE 12-25
LDP 12-28
Fault Management 12-28
Connectivity Fault Management over MPLS 12-28
Bidirectional Forwarding Detection (BFD) 12-29
Alarm Indication Signal (AIS) and Link Down Indication (LDI) 12-29
Complementary protocols 12-29
LSP ping 12-29
LSP traceroute 12-29
Benefits 12-29
Vendor interoperability 12-29
Platform requirements and capabilities 12-30
Remote Management for MPLS 12-33
Task flow 12-34
List of procedures
12-1 Installing the MPLS license on 39XX/51XX 12-40
12-2 Configuring IP interfaces on 39XX/51XX 12-42
12-3 Disabling RSTP and MSTP 12-43
12-4 Configuring OSPF routing protocol 12-44
12-5 Configuring IS-IS routing protocol 12-47
12-6 Configuring RSVP-TE 12-52
12-7 Configuring label ranges 12-56
12-8 Displaying label ranges 12-58
12-9 Configuring dynamic ingress TE tunnels 12-60
12-10 Configuring dynamic ingress uni-directional TP tunnels 12-61
12-11 Configuring static transit uni-directional TP tunnels 12-63
12-12 Configuring static uni-directional ingress TP tunnels 12-64
12-13 Configuring static uni-directional egress TP tunnels 12-66
12-14 Configuring static TE tunnels 12-67
12-15 Configuring co-routed TP tunnels 12-69

xiv Contents
12-16 Configuring static bi-directional ingress-associated TE tunnels 12-73

12-17 Configuring CoS profiles for MPLS tunnels 12-74
12-18 Configuring CoS profiles for MPLS tunnels 12-75
12-19 Configuring a dynamic ingress TE tunnel with FRR 12-76
12-20 Switching over to the backup GMPLS TP tunnel 12-78
12-21 Switching over to the backup TE tunnel 12-79
12-22 Switching over to protection pseudowire 12-80
12-23 Displaying MPLS TE-tunnel information 12-81
12-24 Displaying GMPLS TP tunnel information 12-85
12-25 Configuring LDP 12-89
12-26 Configuring dynamic virtual circuits 12-91
12-27 Configuring static virtual circuits 12-94
12-28 Displaying virtual circuits 12-98
12-29 Configuring virtual circuit connectivity verification profiles 12-101
12-30 Displaying a VCCV profile 12-102
12-31 Deleting a VCCV profile 12-103
12-32 Allocating resources for an MPLS management virtual switch (3916, 3930 and
3931 platforms) 12-104
12-33 Creating an MPLS management virtual switch 12-105
12-34 Displaying remote interface configuration 12-107
12-35 Changing the management virtual switch 12-108
12-36 Running ping for RSVP-TE tunnels 12-110
12-37 Running traceroute for RSVP-TE tunnels 12-111
12-38 Running ping for MPLS tunnels 12-112
12-39 Running ping for virtual circuits 12-114
12-40 Running a traceroute 12-115
12-41 Configuring a 39XX/51XX LSR 12-117
12-42 Configuring a 39XX/51XX VPWS 12-120
12-43 Configuring a 39XX/51XX VPLS 12-124
12-44 Configuring a 39XX/51XX H-VPLS 12-128
12-45 H-VPLS configuration example mixed platform 12-132
12-46 VPLS with CFM configuration example 3916 and 3960 12-140
12-47 G.8032 and VPLS interoperability example 12-144
12-48 MPLS-TP configuration example 12-149
L2 control frame tunneling configuration 13-1

Overview 13-1
Tunnel method 13-6
Configuration 13-8
List of procedures
13-1 Adding and removing untagged L2 control frame classification 13-9
13-2 Enabling and disabling L2 control frame tunneling 13-10
13-3 Adding and removing control protocols 13-11
13-4 Setting the disposition of control protocols 13-13
13-5 Setting L2 control frame tunneling attributes 13-14
13-6 Displaying enabled L2 control frame tunneling instances 13-15
13-7 Displaying the L2 control frame classification for a port 13-17
13-8 Displaying L2 control frame tunneling configuration in the configuration
file 13-18

Contents xv
13-9 Configuring L2 control frame tunneling 13-19

13-10 Configuring L2 control frame tunneling mode for MEF CE 2.0
compliance 13-25
Quality of Service configuration 14-1

Class of Services (CoS) policies and mapping 14-2
Traffic profiling 14-4
Determining classification attributes 14-4
Determining Metering Attributes 14-6
Traffic profiling with hierarchical ingress metering 14-7
Advanced classification mode 14-8
Congestion management 14-10
Creating and modifying sRED profiles 14-10
Creating and modifying sWRED profiles on the 3960 14-11
Creating and modifying sWRED profiles on the 3916, 3930, 3931, 3932, 5142,
5150, and 5160 14-13
Egress scheduling 14-14
Egress shaping 14-15
List of procedures
14-1 Configuring Class of Services (CoS) policies on a port 14-17
14-2 Displaying the CoS policy and mapping on a port 14-19
14-3 Creating a resolved CoS map 14-20
14-4 Modifying a resolved CoS map 14-22
14-5 Setting the resolved CoS map for a port 14-23
14-6 Deleting a custom R-CoS map 14-24
14-7 Displaying resolved CoS maps 14-25
14-8 Creating a frame CoS map 14-27
14-9 Modifying a frame CoS map 14-29
14-10 Deleting a frame CoS map 14-30
14-11 Setting the frame CoS map for a port 14-31
14-12 Displaying frame CoS maps 14-32
14-13 Configuring ingress R-CoS to egress queue mapping 14-33
14-14 Displaying an R-CoS map 14-34
14-15 Applying R-CoS policies and mapping in a VLAN 14-35
14-16 Applying R-CoS policies and mapping in a virtual switch 14-37
14-17 Enabling traffic profiling 14-40
14-18 Setting the traffic profiling provisioning mode 14-41
14-19 Displaying traffic profiling information 14-42
14-20 Setting traffic profiling port attributes 14-44
14-21 Configuring a traffic profiling standard profile 14-47
14-22 Configuring per-port standard traffic profiling 14-53
14-23 Configuring per-port and per-VLAN standard traffic profiling 14-54
14-24 Configuring hierarchical VLAN traffic profiles 14-56
14-25 Configuring hierarchical port traffic profiles 14-61
14-26 Configuring VS classification for standard traffic profiles 14-63
14-27 Configuring VS classification for HIM traffic profiles 14-64
14-28 Displaying standard traffic profiles 14-65
14-29 Clearing statistics for all standard profiles 14-67
14-30 Displaying statistics for all standard profiles 14-68

xvi Contents
14-31 Displaying throughput statistics for a traffic profile 14-69

14-32 Setting the per-port hierarchical traffic-profiling mode 14-70
14-33 Setting the child mode 14-71
14-34 Creating an sRED profile 14-72
14-35 Modifying an sRED profile 14-73
14-36 Creating an sWRED profile 14-74
14-37 Modifying an sWRED profile 14-75
14-38 Creating an sWRED profile 14-76
14-39 Modifying an sWRED profile 14-77
14-40 Displaying custom congestion avoidance profiles 14-78
14-41 Updating the congestion avoidance profile for an egress port queue 14-80
14-42 Clearing the congestion avoidance profile to the default for an egress port
queue 14-81
14-43 Displaying the congestion avoidance profile for an egress port queue 14-82
14-44 Deleting a custom congestion avoidance profile 14-84
14-45 Renaming custom congestion avoidance profile 14-85
14-46 Changing the algorithm of an egress port scheduler 14-86
14-47 Changing the weight of the scheduler for a queue 14-87
14-48 Displaying queue weight and scheduler algorithms 14-88
14-49 Configuring egress port and queue shaping 14-89
14-50 Displaying egress port queue configuration 14-92
14-51 Displaying egress port queue statistics 14-94
14-52 Configuring frame bandwidth calculation 14-95
Multicast services configuration 15-1

IGMP snooping 15-3
Enhanced features 15-4
Multicast operations 15-5
Multicast forwarding domains 15-5
Multicast interface 15-6
Multicast traffic filters 15-6
Multicast servers and routers 15-7
Server topology 15-7
IGMP query engine 15-8
Router IP address range 15-9
Channel stream 15-9
Statistics 15-11
Multicast-services attributes 15-13
List of procedures
15-1 Configuring a VLAN as a multicast L2 forwarding domain 15-15
15-2 Configuring channel streams 15-16
15-3 Configuring IGMP forking with VLAN translation 15-18
15-4 Configuring a multicast router topology 15-20
15-5 Configuring a multicast server topology 15-23
15-6 Configuring multicast servers with redundant routers 15-27
15-7 Configuring redundant query engines 15-32
15-8 Clearing multicast service statistics 15-36
15-9 Displaying multicast services information 15-37

Contents xvii
PWE services configuration 16-1

List of procedures
16-1 Configuring PWE services 16-6
16-2 Configuring TDM ports 16-7
16-3 Configuring TDM profiles 16-11
16-4 Configuring attachment circuits 16-13
16-5 Configuring virtual circuits 16-17
16-6 Configuring MPLS 16-25
16-7 Configuring Layer 2 virtual circuits 16-26
16-8 Configuring virtual switch cross-connections 16-27
16-9 Displaying TDM port information 16-28
16-10 Displaying attachment circuit information 16-30
16-11 Displaying virtual circuit information 16-31
16-12 Displaying virtual switch information 16-32
16-13 Displaying virtual switch cross-connection information 16-33
16-14 Configuring SAToP services over 802.1Q Metro Ethernet 16-34
16-15 Configuring SAToP services over QinQ Metro Ethernet 16-37
16-16 Configuring SAToP pseudowire over MPLS network 16-40
Error codes 17-1

Traffic profiling error codes 17-1

xviii Contents

xix
About this document 0
This manual describes how to configure system software on 39XX/51XX

Service Delivery and Aggregation switches. This system software is based on
a common Service Aware Operating System (SAOS) code base designed to
deliver consistent benefits across all Ethernet delivery, aggregation, and
distribution configurations.
Note: This system software cannot be installed on any other Service

Delivery Switches, Service Concentration Switches or Service
Aggregation Switches.
This manual provides information and examples for use in configuring system
software on any platform on which it is installed. It includes an explanation of
the key features supported by the devices and provides example
configurations for these features. Although these examples are useful in
configuration, they are not meant to be used as a configuration template.
Conventions used in this document

Hyperlinks are indicated by blue text in this document.
In procedures, the following text conventions are used:

courier text, for system responses
italic text, for expected results
bold text, for user input

xx About this document
Command syntax
A variety of symbols are used to indicate CLI command syntax. These
symbols describe how to enter a command. They are not entered as part of
the command itself. The following table summarizes command syntax
symbols.
Symbol Description
<> Encloses a variable or literal value that must be specified. Some

examples include:
server <IpAddress>
priority <NUMBER: 1-7>
dns <on|off>
description <String[31]>
For server <IpAddress>, the attribute could be entered as server
10.10.11.100 or server www.ciena.com. With priority <NUMBER:
1-7> the text within <> indicates that 1 - 7 are valid values. In the
example of dns <on|off>, either the literal value of on or off is
valid, such as dns on. For description <String[31]>, any string of
up to 31 characters is entered.
{} Encloses a required value or list of required arguments. One or

more values or arguments can be specified. For example, in the
syntax:
cfm mip create
{vlan <VlanId>}
{port <PortNameList>}
[level <NUMBER: 0-7>]
The vlan and port arguments are required. The level argument is
optional.
| Separates mutually exclusive items in a list, only one of which can

be entered. For example, in the syntax:
dhcp client options set subnet <on|off>
Either on or off must be specified, for example:

dhcp client options set subnet on
[] Encloses an optional value or a list of optional arguments. One or

more values or arguments can be specified. For example, in the
syntax:
arp show [interface <Interface>]
You can enter a value for interface <Interface> or not. For

example:
arp show

About this document xxi
Symbol Description
{ [ ], [ ], [ ] } Specifies a list of optional items where at least one must be

specified.
Indicates the example has been abbreviated and that the actual
display contains more information.
* Indicates zero or more occurrences of what is preceding.
Documents in the 39XX/51XX documentation suite

For descriptions of documents in the 39XX/51XX Service Delivery and
Aggregation Switches documentation suite, see 39XX/51XX Service Delivery
and Aggregation Switches Product Fundamentals (009-3220-006).

xxii About this document

1-1
New in this release 1-
The following sections summarize documentation changes in Configuration

(009-3220-008) for new software features introduced with SAOS 6.12.
1588v2 Boundary Clock

The following sections were updated:
System timing configuration on page 6-1
IEEE 1588 version 2 Precision Time Protocol on page 6-4
Clock selection algorithm on page 6-5
Quality level value definition on page 6-7
Frequency, phase and time-of-day configuration rules on page 6-11
Procedures on page 6-17
The following sections were added:
Holdover interval on page 6-12
PTP clock type on page 6-12
The following procedures were updated:
Configuring synchronization on page 6-20
Configuring the PTP timing global attributes on page 6-23
Configuring global attributes for PTP input timing on page 6-25
Configuring global attributes for PTP output timing on page 6-26
Configuring global attributes for GPS output timing on page 6-27
Configuring PTP input references on page 6-33
Configuring GPS input references on page 6-35
Configuring PTP output timing references on page 6-42
Configuring GPS output references on page 6-43
Configuring protection-groups on page 6-44
Clearing timing statistics on page 6-52
Displaying information for synchronization on page 6-53

1-2 New in this release
Displaying PTP information on page 6-63

Displaying GPS information on page 6-69
Displaying TDM information on page 6-72
Displaying frequency information on page 6-74
Displaying phase information on page 6-76
Displaying protection-group information on page 6-80
The following procedure was added:
Displaying time-of-day information on page 6-78
Support MEF 26.1 ENNI Hairpin
The following section was added:
External Network-to-Network Interface Hairpin on page 10-26
The following procedures were added:
Configuring ENNI hairpin switching using sub-ports on page 10-79
Displaying statistics for sub-port interfaces on page 10-82
Clearing statistics for sub-port interfaces on page 10-84
Static PW status signaling
The following section was updated:
Primary virtual circuit attributes on page 12-21
The following procedure was updated:
Configuring static virtual circuits on page 12-94
MAC Withdraw signaling over static PW
VPLS membership and MAC learning on page 12-18
EVC Ping/IP interface
IP management on page 2-3
Documentation enhancement
The following sections were added:
Ethernet Service Types on page 10-2
The following procedures were added:
Configuring EPL and EVPL for E-Access service types on page 10-65
Configuring CFM for E-Access service types on page 10-68
Configuring HIM for E-Access service types on page 10-71

New in this release 1-3
Configuring L2 Control Frame Tunneling for E-Access service types on

page 10-73
Configuring RFC 2544 Benchmarking for E-Access on page 10-74

1-4 New in this release

2-1
Configuration fundamentals 2-
This chapter provides an overview of the following components for building

networks and accounting:
Ports
Hardware resources
System timing
Link Layer Discovery Protocol
Virtual Local Area Networks
IP management
Metro Ethernet Forum Layer 2 Virtual Private Networks
Provider Backbone Bridge Traffic Engineering
Multiprotocol Label Switching
Layer 2 control frame tunneling
Quality of Service
Multicast services
Ports
Physical ports provide connectivity to other devices. Logical ports are created
when multiple physical ports are joined in a Link Aggregation Group (LAG).
Physical ports provide connectivity to other devices, which is essential for any
switching device. To aggregate bandwidth and provide link redundancy
between two devices, physical ports are added to a Link Aggregation Group
(LAG). The port management commands provide the ability to configure ports
and troubleshoot connectivity.
Hardware resources
The system assigns hardware resources (classifier, meter, and counter
resource types) for various software features. Depending upon the feature,
you can reassign these resources to provide additional resources for other
features.

2-2 Configuration fundamentals
This customized resource management is supported for the following

features:
Broadcast containment
CFM
DHCP relay
Traffic profiling
Virtual circuit statistics
Virtual switch Layer 2 enhanced transforms
Transport OAM
System timing
System timing recovers and distributes frequency, phase and time-of-day
(ToD) information in order to maintain synchronization between network
elements.
System timing comprises:

Synchronous Ethernet (SyncE)
IEEE version 2 Precision Time Protocol (PTP)
external interfaces, which comprise:
Building Integrated Timing Supply (BITS)
Global Positioning System (GPS)
Time Division Multiplexing (TDM) line timing
Pseduowire emulation (PWE)
Link Layer Discovery Protocol

Link Layer Discovery Protocol (LLDP) allows network equipment, for example,
stations, switches, bridges, routers, to advertise their parameters for network
topology discovery and management. Traditional network management
protocols, such as SNMP, running at key locations, use layer 3 protocols to
identify the devices connected to the network. The Link Layer Discovery
Protocol is a layer 2 protocol, allowing precise discovery of the physical-link
topology of the network. Devices act as LLDP agents, which drastically
increases the network discovery performance of SNMP applications, as well
as any system capable of accessing standard LLDP MIBs.
Virtual Local Area Networks

Virtual Local Area Networks (VLANs) are used to group resources that have
a common set of requirements, regardless of where they are located
physically. They also allow ports on a device to be grouped in order to limit the
distribution of unicast, multicast, and broadcast traffic. For example, flooded

traffic originating from a particular VLAN can be limited to only other ports
belonging to that VLAN. VLANs allow traffic on the same physical connection
to be divided into separate services. These services can then be further
divided into groups within each service.
Note: VLAN configuration is supported for compatibility with Enterprise

VLAN applications. For Carrier Ethernet applications, use virtual switch
configuration as described in MEF L2 VPN configuration on page 10-1.
IP management
IP management allows you to manage the switch using IPv4 and/or IPv6. IP
management applications are:
file transfer (xftp)
software upgrade
SNMP
syslog
RADIUS
TACACS+
NTP
SSH
Telnet
Two-Way Active Measurement Protocol (TWAMP)
RFC 2544
You can configure an IP interface with one IPv4 address and up to two IPv6
global or link local addresses. An IP interface, including local and remote
interfaces, can be created or configured with one IPv4 address and up to two
IPv6 addresses. A link-local addresses is allowed. Link-local addresses can
be duplicated if they are not configured on the same IP interface.
An IP interface can be created with an IPv4 address or an IPv6 address

specified, or with the auto-ipv6 option. Auto-generated SLAAC addresses and
link-local addresses are available for use when the auto-ipv6 option is chosen.
Up to 16 auto-generated SLAAC addresses can be instantiated when
connected to a remote router. A default link-local address is also always
available for use.
Metro Ethernet Forum Layer 2 Virtual Private Networks

Layer 2 (L2) Virtual Private Networks (VPNs) support the three Ethernet
Service Types defined by the Metro Ethernet Forum (MEF) as:
E-Line: point-to-point service among the same service provider

E-LAN: multiple point service

E-Tree: point-to-multipoint service
E-Access: point-to-point service among different service providers
These services are defined by the configuration of port and VLAN based
Ethernet Private Line/LAN (EPL) or Ethernet Virtual Private Line (EVPL). The
customer perspective is that their connection to the service provider is a direct
connection to a private line or LAN between their sites.
L2 VPNs transport Ethernet/802.3 and VLAN tagged traffic between multiple

sites that belong to the same L2 broadcast domain. These services are
deployed over Ethernet using an extension of 802.1Q, called Q-in-Q.
Provider Backbone Bridge Traffic Engineering

Provider Backbone Bridge Traffic Engineering (PBB-TE) allows providers to
create point-to-point, primary and backup Ethernet tunnels and specify the
path that traffic will take across their Ethernet metro networks. These paths
reserve appropriate bandwidth and support the provisioned QoS metrics.
However, PBB-TE is unique in that it actually disables some Ethernet features
in order to accomplish its goal of delivering traffic.
Multiprotocol Label Switching

Multiprotocol Label Switching (MPLS) is a protocol that allows different
networks to converge and appear to be a single autonomous network. MPLS
can be used to build seamless and consistent Layer 2 (L2) Virtual Private
Networks (VPNs) between two or more remote sites traversing many different
physical networks. The customer perspective is that their connection to the
service provider is a direct connection using a private Local Area Network
(LAN) between geographically separated sites.
Layer 2 control frame tunneling

A device identifies the associated protocol of L2 control frame based upon the
Media Access Control Destination Address (MAC DA) and other information
within the frame. Depending upon the state of processing, L2 control frames
can be in three forms:
untagged: standards-based definition of the protocols control frame. In
this form, the frame does not have a VLAN tag, but does have the protocol
specific MAC DA. Depending upon the protocol, it can have a specific
Ethertype value and other information. Typically, control frames in this
format are received from the subscriber facing interface.

transparent (tagged): one or more 802.1 VLAN tags have been added to
transform the frame, and the protocol specific MAC DA is left intact. This
form occurs when a control frame is received from a subscriber facing
interface, encapsulated as a data frame, and then forwarded from a
network facing interface for transport through the provider network.
L2 Protocol Tunneling (L2PT): standard MAC DA has been transformed to
the L2PT special MAC DA. The frames original Mac DA is replaced with a
configurable L2PT MAC address. The L2PT DA MAC can be configured
with a valid Multicast MAC address. The default system L2PT MAC is the
Generic Bridging PDU Tunneling (GBPT) MAC of
01:00:0C:CD:CD:CD:D0. It is not recommended to use L2PT MAC
belonging to the following MAC address blocks:
L2 Slow Protocol Block: 01:80:C2:XX:XX:XX
ISO 9542 Address: 09:00:2B:00:00:04/05
IEEE802.5 Block: 03:00:00:XX:XX:XX
IPv4 Multicast Block: 01:00:5E:XX:XX:XX
IPv6 Multicast Block: 33:33:XX:XX:XX:XX

Quality of Service
Quality of Service (QoS) refers to the management of bandwidth to ensure
that network traffic is allocated the desired amount of network resources.
Table 2-1 lists mechanisms for managing bandwidth.
Table 2-1
Mechanisms for managing bandwidth
Mechanism Description
Class of Services (CoS) CoS policies and mapping comprise the following:
policies and mapping Resolved CoS: applies a Resolved CoS Policy and Resolved CoS
Map on ingress. Optionally, remarks the frames Layer 2 priority and
color based upon the mapping. Assigns traffic to egress CoS queues
based upon Resolved CoS values. Ingress coloring influences both
traffic profiling and congestion avoidance processing. Traffic profiling
meters are now "color-aware" as of release 6.8.0. These meters
respond to ingress R-Color, but do not respond to ingress R-CoS
mappings. In release 6.9.1 and later, you can configure whether a
meter is color blind or color aware per traffic profile.
Egress Frame CoS Policy: enables an egress frame CoS policy.
Note: This setting is not available on 3940, and 5140 devices.
Frame CoS Mapping - applies a R-CoS and R-Color to frame Priority
Code Point (PCP)/Layer 2 (L2) CoS 802.1D priority and Discard
Eligibility Indicator (DEI)/Canonical Format Indicator (CFI) mapping
that remarks egressing L2 frames.
Traffic profiling and Traffic Provides ingress traffic classification and metering.
profiling with hierarchical Note: To configure traffic profiling, you need to install the Advanced
ingress metering Ethernet license key. To obtain the Advanced Ethernet license key,
contact Ciena Sales.
Congestion management Method for managing CoS queue traffic when congestion occurs on
egress.
Note: To enable configurable congestion avoidance, you need to
install the Advanced Ethernet license key. To obtain the Advanced
Ethernet license key, contact Ciena Sales.
Egress scheduling Determines the order in which the physical queues are processed.
Egress shaping Controls bandwidth for taking frames out of queues at egress
Configurable frame bandwidth Configure whether to use the inter-frame-gap (IFG) in the calculations
calculation for broadcast containment, ingress metering and egress shaping.

Multicast services
Traditional Internet Group Management Protocol (IGMP) was designed for
environments that have a low volume of multicast packets and no real-time
traffic requirements for processing IGMP messages. Cienas IGMP
implementation was designed for networks where multicast services are
critical, such as networks delivering IP broadcast video. Devices employ
enhanced IGMP snooping and various filters to limit multicast streams and
assure their timely delivery.
The following network elements support 1023 multicast groups:

3916
3930
3931
3932
3940
3960
5140
5142
5150
5160


3-1
Configuration management 3-
This chapter provides explanations for implementing the basic set up of a

device and describes the various options available to configure it, including:
Accessing the CLI on page 3-1
Configuration files on page 3-1
This chapter provides the procedures for configuration management.
Accessing the CLI

To access CLI commands, connect to the device by establishing a Telnet
session or through direct connection to the serial console port located on the
front of the control module.
For related procedures, see 39xx/51xx R6.11 Administration and Security

(009-3220-007).
Configuration files
A device can store multiple device configuration files. However, only one
configuration file can be active at a time. By default, configuration information
is saved to a file called startup-config. The startup-config file is also the
default load file. The parameters defined in the startup-config file are
applied when the device reboots (unless an alternate file is specified). The
current running configurations on a device are not saved to a configuration file
unless specifically saved. This includes configuration changes made using the
CLI or SNMP. If a device is rebooted without saving the configuration, all
changes are lost.
This chapter provides the following procedures:

Saving configuration changes on page 3-3
Displaying configuration files on page 3-4
Augmenting the current configuration on page 3-5
Restoring default configurations on page 3-7
Setting the default configuration files on page 3-8

3-2 Configuration management
Displaying the default configuration files on page 3-9

Resetting default configuration files to factory default files on page 3-10

Procedure 3-1
Saving configuration changes
In order to permanently save configuration changes, you must save the
running configuration to a configuration file. To save the running configuration,
use the configuration save command. By default, the command saves the
current configuration to the default configuration file, startup-config.
By saving alternate versions of command files, you can store multiple

configuration files for running different configurations of the system. For
example, you can save configuration to an alternate file as a backup to restore
to a previous configuration or you can store a configuration file for configuring
another device of the same family.
Note: If the running configuration has not been saved, an asterisk is

displayed in the CLI prompt, such as: *>. When you save the
configuration, the asterisk is removed.
Step Action
To save the running configuration

1 Save the running configuration:
configuration save
To save to an alternate filename
2 Save the configuration to an alternate filename:
configuration save filename <filename>
where
filename is the configuration file name.
<filename>
end
Example
The following example saves the default configuration file.
configuration save
The following example saves to an alternate filename.

configuration save filename myConfig

Procedure 3-2
Displaying configuration files
Display configuration files.
Step Action
1 Display the configuration:

configuration show [line-numbered] [differences-from-
saved]
where
line-numbered displays with line numbers.
differences-from- displays changes since last saved.
saved
2 Search the configuration file:

configuration search file <String>] [lines <NUMBER: 0-
40>] {string <String>}
where
file <String>] is the filename (no path).
lines <NUMBER: is the search window size.
0-40>
string <String> is the search string.
end
Example
The following example displays the differences between the running
configuration and the saved configuration file.
> configuration show differences-from-saved
diff /flash0/config/Mcast_Aggs_DG /ram/65700.out
4,6c4,6
< ! Created: Mon May 5 14:04:02 2008
---
> ! Created: Mon May 5 14:09:04 2008
The following example displays sections of a configuration file containing a

specific string.
> configuration search string dhcp

dhcp client disable
dhcp client set interface local

Procedure 3-3
Augmenting the current configuration
You can add configuration commands from a file to the current configuration
with the configuration augment command. By default, the commands are
added from a specified file stored on the file system at /flash0/config.
Note: If you want to apply the added commands to the default startup
command file, you need to save the configuration with the configuration
save command.
Step Action
1 Augment the current configuration with a file:

configuration augment {filename <String>} [server <IP
address or host name>] {default-tftp-server} {default-
ftp-server} {default-server} {default-sftp-server}
[sftp-server <IP address or host name>] [tftp-server <IP
address or host name>] [ftp-server <IP address or host
name>] [login-id <String[32]>] [password <Password
String>] [secret <String[256]>]
where
filename <String> is the configuration file name.
server <IP is the FTP server.
address or host
name>
default-tftp- indicates that the default TFTP server is used.
server
default-ftp-server indicates that the default FTP server is used.
default-server indicates that the default xFTP server is used.
default-sftp- indicates that the default SFTP server is used.
server
sftp-server <IP is the SFTP.
address or host
name>
tftp-server <IP is the TFTP server.
address or host
name>
ftp-server <IP is the FTP server.
address or host
name>

where
login-id is the FTP/SFTP username.
<String[32]>
password enter the password in clear text.
<Password
String>
secret sets the password using a pre-encrypted string.
<String[256]>
end
Example
The following example adds configuration commands to the configuration.
configuration augment filename /users/testuser/

myConfigAdd.txt default-server
WORKING: TFTP file transfer in progress
/users/testuser/myConfigA 100%
|******************************************************|
70 0:00:00 ETA

Procedure 3-4
Restoring default configurations
You can
reset configuration to user defaults
reset the device to factory defaults
After running any of the commands to activate an alternative configuration,

you have 10 seconds to cancel. To cancel, press Ctrl+C.
CAUTION
Loss of Configuration Information
When you reset a device to its factory default settings, all
configuration and file system changes are lost, including saved
configuration files and log files. Software License Keys that
were previously installed are not removed from the device.
Step Action
To reset configuration to user defaults

1 Reset configuration to user defaults:
configuration reset-to-user-config [filename <filename>]
where
filename is the configuration file name.
<filename>
To restore the device to factory defaults

2 Restore the device to factory defaults:
configuration reset-to-factory-defaults
end
Example
The following example resets the configuration to user defaults.
configuration reset-to-user-config filename myConfig

Procedure 3-5
Setting the default configuration files
You can set alternate configuration files as the default save file so that when
a configuration save is performed, the changes will be saved to the alternate
configuration file. When the device is rebooted, it will load the default-load file,
which may or may not be the same file as the default-save file. However, when
the device is rebooted it will load the startup-config file.
You can
set the default file for saving configuration
set the default file for loading configuration
Step Action
To set the default file for saving configuration

1 Set the default file for saving configuration:
configuration set default-save-filename <FileName>
To set the default file for loading configuration
2 Set the default file for loading configuration:
configuration set default-load-filename <FileName>
end

Procedure 3-6
Displaying the default configuration files
The default configuration files are
save
load
Step Action
1 Display the default save, load, and backup load files:

configuration list
Example
The following example shows sample output for the configuration list
command.
> configuration list
+--------------------------------------------------------------------------+
| Configuration Files |
+--------------------------------------------------------------------------+
| startup-config |
| test |
+--------------------------------------------------------------------------+
| Default Save File: test |
| Default Load File: test |
+--------------------------------------------------------------------------+

Procedure 3-7
Resetting default configuration files to factory default
files
You can
reset the default file for saving configuration
reset the default file for loading configuration
Step Action
To reset the default file for saving configuration

1 Reset the default file for saving configuration:
configuration unset default-save-filename
To reset the default file for loading configuration
2 Reset the default file for loading configuration:
configuration unset default-load-filename
end

4-1
Port management 4-
This chapter explains how to configure physical and logical port attributes.
Physical ports provide connectivity to other devices, which is essential for any
switching device. To aggregate bandwidth and provide link redundancy
between two devices, physical ports are added to a Link Aggregation Group
(LAG). The port management commands provide the ability to configure ports
and troubleshoot connectivity.
Port management addresses:

Port attributes
Port statistics
Transceivers
This chapter provides the procedures for port management.
Port attributes
Table 4-1 describes administrative and operational attributes for ports.
Table 4-1
Administrative and operational attributes for ports
Attribute Description
General
Port Name A 32 character string representing the name of the physical port or LAG. For
physical ports, the name represents the ports physical location identifying
the chassis module and port in the format:
<ModuleNumber>.<PortNumber>
Whenever a platform has a single module, the component number will be
left out of the name. For example, the 3960 platform is single module, so
each physical port is named only with the port number (1 through 12). The
5150 platform supports multiple modules, so each port on the second and
third module is named with the module and port numbers (2.1, 2.2, 3.1, 3.2).
Type Gigabit (GIG), 10 Gigabit (10GIG), or LAG.

4-2 Port management
Table 4-1
Service Port Type Indicates whether the port is a Subscriber, User to Network Interface (UNI),
or Network to Network Interface (NNI) port.
Spanning Tree State Indicates the state of Spanning Tree Protocol (STP), including: Disabled,
Forwarding, Learning, or Discarding. For additional information regarding
STP, refer to Configuring RSTP on page 19-1 and Configuring MSTP on
page 20-1.
MAC Address Media Access Control (MAC) address. By default, the MAC address is
uniquely assigned during manufacturing.
Link Flap Detection configuration for monitoring link state transitions.
Link State Indicates whether the port is enabled or disabled. By default the Admin link
state is disabled.
State Group Link State Indicates whether the port state mirror group link is enabled or disabled.
Blank indicates the port is not a member of a port state mirror group.
Acceptable frame type Designates the treatment of received frames to allow all, tagged-only, or
(acceptable-frame-type) untagged-only.
Flow Control (flow-ctrl) Prevents one port from sending data faster than the receiving port can
handle it. When the receiving port has all the data it can handle, it sends a
pause frame to the sender. The sender stops sending data until the pause
frame expires. Received (asym-rx), transmitted only (asym-tx), or Off
modes are supported; the default mode is off.
Auto-negotiation (auto- Determines whether ports negotiate with their link partner to operate with
neg) parameters common to both links. This method of auto negotiation follows
the IEEE 802.3z standard and provides a way to automatically connect
multiple types of devices. By default, auto negotiation is enabled.
Flow Control Advertised Determines whether flow control setting is advertised. Default is off.
(advertised-flow-control)
Duplex (duplex) Half or full. When the port is set to full duplex, it can transmit and receive
data simultaneously. With half duplex the port can transmit or receive data,
but not both simultaneously. Default duplex is set to full.
Inter-packet gap (IPG) Sets the inter-packet gap size. This attribute sets the IPG to 12 or 8 bytes.
size Note: The user will be prevented from configuring a port, previously
configured as a Benchmark port-under-test, to function with an IPG of 8
bytes. Similarly, the user will be prevented from configuring a port,
previously configured to function with an IPG of 8 bytes, as a Benchmark
port-under-test.

Port management 4-3
Table 4-1
Description (description) Configurable 128 character description of the port. By default, the
description is blank.
Speed Physical port speed, such as 1 Gbps or 10 Gbps. Not applicable for LAG
ports. The default value is auto, which matches the speed to the transceiver
speed. Any configured auto negotiation settings are ignored for transceivers
that do not support auto negotiation, that is, 100M- and 10G-based
transceivers.
Note: If you set a value for the speed attribute, the port stays in that speed
and a transceiver mismatch error is displayed if there is a mismatch. This
functionality is only supported on Ciena-supported transceivers.
Maximum frame size Maximum frame size in bytes allowed to ingress/egress the port. The default
(max-frame-size) value is 1526. Jumbo frames are supported with configurable range from
1522-9216. Maximum frame size is also referred to as Maximum
Transmission Unit (MTU) size.
Note: MPLS traffic will not obey the port MTU on the egress side for all
platforms, with the exception of the 5160 and the 5142.
Aggregation Membership Displays the link aggregation group of which the port is a member.
Port traffic mirroring
Mirror port Turns port mirroring on or off. Default is off.
Ingress-mirror Sets the mirror port for ingress traffic.
Egress-mirror Sets the mirror port for egress traffic.
Optic transceiver
Mode Shows the port connector mode, Copper RJ45, Small Form Factor
Pluggable (SFP), or SFP+.
XCVR Capabilities Indicates whether or not the capabilities of the port and the installed
Mismatch transceiver match.
Phy loopback

4-4 Port management
Table 4-1
Loopback Indicates whether internal physical loopback is enabled. By default, internal

loopback is off.
Internal loopback is supported where data that is destined to egress the port
in internal loopback mode will be looped back through the switch fabric and
out the port on which it came in. The loopback occurs in the PHY. Internal
loopback can be enabled on any physical port independently, regardless of
VLAN membership. For more information, refer to Port loopback on page
4-5.
Setting the internal loopback attribute automatically sets the ports learn limit
to 0, with an action of 'forward'. When the internal loopback setting is 'off',
the configured learn limit is then re-applied.
If more than two ports within the same VLAN are configured to participate in
an internal loopback test, there is a danger of creating a broadcast storm.
Class of Service (CoS)
Fixed Resolved CoS Sets the fixed resolved CoS value.

(fixed-rcos)
Fixed Resolved Color Sets the fixed resolved color, which is green or yellow.
(fixed-rcolor)
Resolved CoS (R-CoS) to Sets the R-CoS to F-CoS map.

Frame CoS (F-CoS) map
(frame-cos-map)
Resolved CoS Policy Sets Resolved CoS Policy.

(resolved-cos-policy)
Ingress to Egress Qmap Sets the R-CoS queue map to use in mapping internal CoS (R-CoS) at the
(ingress-to-egress-qmap) ingress port to a CoS queue at an egress port.
FCOS to RCOS Map Sets the frame CoS to R-CoS map.

(resolved-cos-map)
Remark L2 (resolved-cos- Enables or disables frame layer 2 remarking.

remark-l2)
VLAN specific
Egress Untag VLAN Sets the VLAN for egressing untagged data frames.
(egress-untag-vlan)
PVID (PVID) Port VLAN ID. Default is 1.
Ingress VLAN Filter (vlan- Filters frames that are not members of a configured VLAN. Default is
ingress-filter) enabled.

Port management 4-5
Table 4-1
VLAN Membership Displays the VLANs of which the port is a member.
Virtual switch and virtual circuit specific
Untagged Ctrl VS Untagged control frame virtual switch.

(untagged-ctrl-vs)
Untagged Data VS Untagged data frame virtual switch.

(untagged-data-vs)
Untagged Ingress Data Pushes and pops the specified VID as a Customer VID for frames forwarded
Vid (untagged-data-vid) to a virtual switch. Applicable only to ports associated with virtual switches.
Note: On the 3940 and 5140 platforms, the untagged-data-vid attribute
pushes the specified VID as a Customer VID on ingress but does not pop
the VID on egress.
Virtual switch ingress filter Filters frames that are not a member of a configured virtual switch.
(vs-ingress-filter)
Eth VC EtherType Displays the EtherType for Ethernet virtual circuits.
Eth VC EtherType Policy Displays the configured EtherType policy for the Ethernet virtual circuits.
VS L2 Transform (vs-l2- Enables VLAN translation for Q-in-Q with virtual switch L2 transform
transform) actions.
Port loopback
Figure 4-1 shows internal loopback on Port1. Traffic ingresses Port2 and is
intended to egress Port1. The traffic ingresses the switch fabric, is learned,
ingresses Port1 and is looped back and sent into the switch fabric.
Figure 4-1
Internal loopback
PORT1 PORT2
Switch
fabric

4-6 Port management
This chapter provides the following procedures for configuring ports:

Setting port attributes on page 4-13
Resetting port attributes to default on page 4-14
Disabling a port on page 4-15
Enabling a port on page 4-16
Displaying port attributes on page 4-17
Displaying blade information on page 4-29
Displaying port capabilities on page 4-33
Displaying port Ethernet configuration on page 4-35
Displaying port status on page 4-36
Port statistics
Table 4-2 describes port statistics.
Table 4-2
Port statistics
Port statistic Description
RxBytes Number of bytes received including those in bad packets.
RxPkts Number of packets received including all unicast, multicast, broadcast, MAC
control and bad packets.
RxCrcErrorPkts Number of packets received which contained an FCS error and were
between 64 and 1518* bytes in length.
RxMcastPkts Number of good multicast packets received that were between 64 and
1518* bytes in length. Excludes MAC control frames.
RxBcastPkts Number of good broadcast packets received that were between 64 and
1518* bytes in length. Excludes MAC control frames.
RxUcastPkts Number of good unicast packets received that were between 64 and Max
Frame Size bytes in length. Excludes MAC control frames.
UndersizePkts Number of packets received that were less than 64 bytes long and
contained a valid FCS and were otherwise well-formed.
OversizePkts Number of packets received that were longer than 1518* bytes to Max
Frame Size and contained a valid FCS and were otherwise well formed.
Includes unicast, multicast and broadcast packets.
FragmentsPkts Number of packets received that were between 10 and 63 bytes in length
and had either an FCS error or an alignment error.
JabbersPkts Number of packets received that were longer than 1518* bytes to Max
Frame Size and had an FCS error or an alignment error.

Port management 4-7
Table 4-2
Port statistics
RxPausePkts Number of received valid pause packets that were between 64 and 1518
bytes in length.
RxDropPkts The total number of valid packets received which were discarded due to lack
of resources, that is, rx buffer hits the discard limit, buffer pool full or back
pressure discard. RFC 2819 specifies that this number is not necessarily the
number of packets dropped; it is just the number of times this condition has
been detected.
RxDiscardPkts The Count of valid frames received which were discarded (filtered) by the
Forwarding Process. This includes packets dropped due to lack of
resources (RxDropPkts).
RxLOutRangePkts Number of packets received which exceeded Max Frame Size in length and
contained a valid or invalid FCS.
RxInErrorPkts Number of packets received which have FCS errors, or are either Undersize
or Out of Range.
64OctsPkts Number of packets received that were 64 bytes in length.
65To127OctsPkts Number of packets received that were between 65 and 127 bytes in length.
512To1023OctsPkts Number of packets received that were between 512 and 1023 bytes in
length.
length.
length.
length.
length.
TxBytes Number of bytes transmitted including those in bad packets.
TxPkts Number of packets transmitted including all unicast, multicast, broadcast,

MAC control and bad packets.
TxExDeferPkts Number of transmitted packets which experienced multiple deferrals (2 or

more deferrals.

4-8 Port management
Table 4-2
Port statistics
TxDeferPkts10 Number of transmitted packets which were deferred on the first

transmission but did not experience any subsequent collisions during
transmission.
TxGiantPkts Number of packets transmitted that were longer than 1518* bytes and were
otherwise well formed (valid FCS)
TxUnderRunPkts Number of transmitted underrun packets.
TxCrcErrorPkts Number of transmitted packets which contained an FCS error.
TxLCheckErrorPkts Number of transmitted length check packets
TxLOutRangePkts Number of transmitted length out of range packets
TxLateCollPkts Number of transmitted packets which experienced a late collision more than
512 bit times during a transmission attempt
TxExCollPkts Number of transmitted packets which experienced 16 collisions during

transmission and was aborted.
TxSingleCollPkts Number of transmitted packets which experienced a single collision.
TxCollPkts Number of transmitted packets which experienced 2-15 collisions (including

any late collisions) during transmission.
TxPausePkts Number of valid pause control packets transmitted that were between 64
and 1518* bytes in length.
TxUcastPkts Number of good unicast packets transmitted that were between 64 and
1518* bytes in length.
TxMcastPkts Number of good multicast packets transmitted that were between 64 and
TxBcastPkts Number of good broadcast packets transmitted that were between 64 and
Tx64OcPkts Number of packets transmitted that were 64 bytes in length.
Tx65To127OcPkts Number of packets transmitted that were between 65 and 127 bytes in
length.
length.
Tx256To511OcPkts Number of packets.transmitted that were between 256 and 511 bytes in
length.
length.

Port management 4-9
Table 4-2
Port statistics
length.
length.
length.
length.
Note: * 1522 bytes if VLAN tagged.

This chapter provides the following procedures for statistics:
Displaying port statistics on page 4-18
Monitoring port statistics on page 4-23
Clearing current statistics on page 4-28
Transceivers
This section describes
Identification
Diagnostics
Identification
Ciena devices support transceivers that contain a standard serial erasable
programmable read-only memory (EPROM) that provides information on the
type of SFP used. The following information is read from the EPROM:
Identifier Type (GBIC, SFP...)
Extended Identifier Type
Connector Type (SC, LC, MU, SG...)
Vendor Name
Vendor Organizational Unique Identifier (OUI)
Vendor Part Number
Vendor Serial Number
Vendor Revision Number
Encoding Algorithm (NRZ, Manchester...)
Manufacturing Date Code

4-10 Port management
Transceiver Code
Transceiver SFF-8472 Compliance Version
Diagnostics
Ciena devices support advanced transceivers that have an additional
diagnostic serial EPROM. The system software determines if the transceiver
has the diagnostic EPROM and will provide the following information to the
user:
Wavelength/Frequency
Temperature
Rx Power
Tx Power
Tx Disable State
Tx Fault State
Rx Rate Select State
The information is stored in a table on a per port basis. The standard EPROM
information is updated during initialization or when a new transceiver has
been inserted. The diagnostic information is updated at a rate of 1 port per 5
seconds. However, this process has a low priority, and in times of a heavy
CPU load, the information may be refreshed slowly or not at all.
Transceivers that support diagnostics can trigger events and SNMP traps.
Diagnostics on SFPs are the following:

BiasHigh
BiasLow
RxPowerHigh
RxPowerLow
TempHigh
TempLow
TxPowerHigh
TxPowerLow
VccHigh
VccLow
Diagnostics on XFPs are the following:

BiasHigh
BiasLow

Port management 4-11
RxPowerHigh
RxPowerLow
TempHigh
TempLow
TxPowerHigh
TxPowerLow
Each of these events and traps include a warning and alarm version of each,
for example, BiasHighAlarm and BiasHighWarning). Thresholds are set by the
SFP vendors, and are not programmable. Both event classes (alarm, warning)
are logged under the xcvr-mgr. The warnings are logged using the debug
category and warning severity. The alarms are logged using the debug
category and minor severity.
These alarms and warnings are based on flags that are set or cleared inside
the SFP. These flags are polled at a low priority and slow rate, so flags may
be set and then cleared without generating a trap or event. For example, if the
TempHigh alarm threshold is exceeded for a few seconds, and then cleared
before the flag is polled, it will not trigger a TempHigh alarm. You can forcibly
clear alarms and warnings by removing and then reinserting the transceiver
or disabling and then enabling the port.
Table 4-3 lists transceiver states and provides a description of each state.
Table 4-3
Transceiver states
State Description
INV! Invalid. The transceiver port state could not be determined

due to a system error.
UCTF Uncertified. The transceiver is not in the officially supported

set of transceivers on that device, for that software version.
The transceiver may or may not function properly.
WARN There are one or more warnings associated with the

transceiver, such as the port configuration settings (e.g.
speed, autonegotiation, etc) do not match the capabilities of
the transceiver. For example, the port is configured for Gig
speed, but the transceiver is 100m. Information about which
settings are incompatible are available in the output of the port
show port command.

Table 4-3
Transceiver states
State Description
FLT! Fault. The transceiver has been faulted for some reason;
typically this will be due to EEPROM checksum and/or read
failures.
Ena Enabled
Dis Disabled
This chapter provides the following procedures for configuring transceivers:

Displaying a list of supported optics on page 4-37
Displaying transceiver information on page 4-38
Determining transceiver speed on page 4-41
Tuning XFP transceivers on page 4-43
Setting the port connector mode on page 4-45

Procedure 4-1
Setting port attributes
Set port attributes. For information about port attributes, see Administrative
and operational attributes for ports.
Step Action
1 Set port attributes:

port set port <PortNameList> {[acceptable-frame-type
<all|tagged-only>],
[advertised-flow-control <asym-tx|off|sym-asym-
rx>],[auto-neg <on|off>],
[duplex <half|full>], [description <String[31]>],
[egress-frame-cos-policy <ignore|rcos-to-l2-outer-pcp-
map>]
[egress-untag-vlan <Vlan>], [egress-mirror <PortName>],
[fixed-rcos <NUMBER: 0-7], [fixed-rcolor <green|yellow>],
[flow-ctrl <asym-rx|asym-tx|off|sym>],
[ipg-decrease <0 | 4>
[ingress-mirror <PortName>], [link-flap-detect
<on|off>], [link-flap-count <#>], [link-flap-detect-time
<#>], [link-flap-hold-time <#>],
[ingress-to-egress-qmap <RcosQueueMap>] [max-frame-size
<NUMBER: 1522-9216>],
[mirror-port <on|off>], [mode <default|rj45|sfp>],
[loopback <on|off>],[pvid <Vlan>], [resolved-cos-policy
<dot1d-tag1-cos|fixed-cos|l3-dscp-cos>],
[resolved-cos-map <FcosRcosMap>], resolved-cos-remark-l2
<true|false>],
[speed <ten|hundred|gigabit|auto>], [untagged-ctrl-vs
<VirtualSwitchName>], [untagged-data-vs
<VirtualSwitchName>], [untagged-data-vid <VlanId>],
[vlan-ingress-filter <on>], [vs-ingress-filter <on>],
[vs-l2-transform <i-push,e-pop|i-push,e-pop:stamp|i-
stamp:push,e-match-pop:stamp>]}
end
Example
The following example sets the following port attributes on port 2.1:
disables auto-negotiation
sets the description to 1234_West_Street
port set port 2.1 auto-neg off description

1234_West_Street

Procedure 4-2
Resetting port attributes to default
Reset port attributes to default values.
Step Action
1 Reset port attributes to default values:

port unset port <port> {description} {egress-mirror}
{ingress-mirror} {mirror-encap} {mirror-encap-vid}
{mirror-encap-tpid} {untagged-ctrl-vs} {untagged-data-
vs} {untagged-data-vid} {mac-swap-vlan} {advertised-
speed} {advertised-duplex}
where
port <port> is the port.
description is the port description.
egress-mirror is egress port mirroring.
ingress-mirror is ingress port mirroring.
mirror-encap is port mirroring encapsulation.
mirror-encap-vid is the port mirroring encapsulation VID.
mirror-encap-tpid is the port mirroring encapsulation TPID.
untagged-ctrl-vs is the virtual switch for untagged control frames.
untagged-data-vs is the virtual switch for untagged data frames.
untagged-data- is the push/pop of VLAN ID for untagged data frames.
vid Note: On the 3940 and 5140 platforms, the untagged-data-
vid attribute pushes the VLAN ID on ingress but does not
pop the VLAN ID on egress.
{mac-swap-vlan} is the MAC SA/DA swap VLAN ID.
{advertised- is the advertised value for speed.
speed}
{advertised- is the advertised value for duplex.
duplex}
Example
The following example clears the description associated with port 1.
port unset port 1 description

Procedure 4-3
Disabling a port
When you disable a port, the Link State administrative status is changed to
disabled and the operational status shows disabled when the link is down.
When you disable a port directly, the transceiver is disabled.
Step Action
1 Enter the following command:

port disable port <PortNameList>
where
port is the port to be disabled.
<PortNameList>
end
Example
The following example disables port 1.
port disable port 1

Procedure 4-4
Enabling a port
When you enable a port, the Link State administrative status is changed to
enabled and the operational status shows enabled when the link is up.
When you enable a port directly, the transceiver is enabled.
Step Action
1 Enter the following command:

port enable port <port>
where
port <port> is the port to be enabled.
end
Example
The following example enables port 1.
port enable port 1

Procedure 4-5
Displaying port attributes
Display port attributes to
verify configuration
check link status
troubleshoot issues related to the port
Step Action
1 Display port attributes by entering the following command:

port show [port <port>]
where
port <port> is a 32-character string representing the name of the
physical port or LAG.
end
Example
The following example shows sample output of the port show command.
> port show

+-----------------------------------------------------------------------------+
| Port Table | Operational Status | Admin Config |
|--------+--------+----+--------------+----+---+-------+----+----+-------+----|
| Port | Port | | Link State | | | |Auto| | |Auto|
| Name | Type |Link| Duration |XCVR|STP| Mode |Neg |Link| Mode |Neg |
|--------+--------+----+--------------+----+---+-------+----+----+-------+----|
| 1 |10/100/G|Down| 0d 0h 0m 0s| |Dis| | |Ena |1000/FD| On |
| 2 | Gig | Up | 0d 3h56m14s|Ena |FWD|1000/FD| On |Ena |1000/FD| On |
...
+--------+--------+----+--------------+----+---+-------+----+----+-------+----+
The following example shows sample output of the port show command for a
specific port.
> port show port 1
+-------------------------------- PORT 1 INFO ---------------------------------+

| Field | Admin | Oper |
+--------------------------+-------------------------+-------------------------+
| Type | 10/100/G |
...
| Aggregation Membership | | |
| VLAN Membership | 1,10,100,1000 | 1,10,100,1000 |
+--------------------------+-------------------------+-------------------------+

Procedure 4-6
Displaying port statistics
Two sets of statistics are stored:
Current statistics, which are the values since the last statistics clear
operation.
Total statistics, which are the values since the last boot-up
The system also calculates throughput values to show current statistics in

terms of rate.
You can display

current statistics
total statistics
current throughput statistics
statistics for specific ports
Note: The port throughput rate measurement is a very rough

approximation that should not be expected to match actual rates.
Step Action
To display current statistics

1 Display current statistics:
port show statistics <statistics> [active] [delay
<NUMBER: 1-86400>] [count <NUMBER: 0-4294967295>] [scale
<tera|giga|mega|kilo|none>]
where
statistics is statistics collected since the last statistics clear operation.
<statistics>
active displays active statistics.
delay <NUMBER: is the length of time in seconds to display the statistics.
1-86400
count is the number of times to repeat the display.
<NUMBER: 0-
4294967295>
scale <tera | giga is the units for the displayed values.
| mega | kilo |
none>

To display total statistics

2 Display total statistics:
port show total-statistics <total-statistics> [active]
[delay <NUMBER: 1-86400>] [count <NUMBER: 0-4294967295>]
[scale <tera|giga|mega|kilo|none>]
where
total-statistics is all statistics collected since the last boot-up.
<total-statistics>
1-86400
<NUMBER: 0-
4294967295>
| mega | kilo |
none>
To display current throughput statistics

3 Display current throughput statistics:
port show throughput <throughput> [active] [delay
where
throughput is the port or ports to show.
<throughput>
1-86400
<NUMBER: 0-
4294967295>
scale <tera | giga is the units for the displayed values. The default value is
| mega | kilo | mega.
none>

To display statistics for specific ports

4 Display statistics for specific ports:
port show port <port> [active] [count <NUMBER: 0-
4294967295>] [capabilities] [delay <NUMBER: 1-86400>]
[statistics] [total-statistics] [throughput] [scale
<tera|giga|mega|kilo|none>] [vlan] [type
<all|basic|errors|tx|rx>]
where
<port> is the port or ports that you want to display port statistics for
count is the number of repetitions for throughput.
<NUMBER: 0-
4294967295>
capabilities displays port capabilities
delay <NUMBER: is the time between samples in seconds.
1-86400>
statistics displays port statistics.
total-statistics displays total port statistics.
throughput displays port throughput.
scale <tera | giga is the scale used to show statistics.
| mega | kilo |
none>
vlan displays port VLAN membership.
type <all | basic | is the type of statistics to show.
errors | tx | rx>
end
Examples
The following example shows sample output for all active port statistics
summary.
> port show statistics active
+---------------------------- PORT STATISTICS SUMMARY --------------------+

| Port | Byte | Pkt |
| | Tx | Rx | Tx | Rx |
+---------+----------------+----------------+--------------+--------------+
| 1 | 8326248088 | 0 | 67147162 | 0 |
| 2 | 8326247964 | 0 | 67147161 | 0 |
| 12 | 0 | 28879569152 | 0 | 225621634 |
+---------+----------------+----------------+--------------+--------------+
The following example shows sample output for all active port total statistics
summary.
> port show total-statistics active
+----------------------- PORT TOTAL STATISTICS SUMMARY --------------------


| | Tx | Rx | Tx | Rx |
+---------+----------------+----------------+--------------+--------------+
| 1 | 169713065596 | 1053155263708 | 325536280 | 1372943892 |
| 2 | 21452132866 | 19878912 | 77950273 | 310608 |
| 12 | 885114437038 | 193572376072 | 1147664620 | 490131140 |
+---------+----------------+----------------+--------------+--------------+
The following example shows sample output for all active port throughput
statistics.
> port show throughput active
+--------------- PORT THROUGHPUT SUMMARY 5 SECOND SAMPLE -----------------+

| Port | Bit Rate (Mbps) | Pkt Rate (Mpps) |
| | Tx | Rx | Tx | Rx |
+---------+----------------+-------------+----------------+---------------+
| 1 | 0.867 | | 0.001 | |
| 2 | 0.867 | | 0.001 | |
| 12 | | 2.008 | | 0.003 |
+---------+----------------+-------------+----------------+---------------+
The following example shows sample output for port 1 active statistics.
> port show port 1 statistics active
+--------------- PORT 1 STATISTICS -----+

| Statistic | Value |
+--------------------+------------------+
| RxBytes | 9659942 |
| RxPkts | 132603 |
| RxCrcErrorPkts | 1 |
| RxUcastPkts | 8499 |
| RxMcastPkts | 81206 |
| RxBcastPkts | 42897 |
| 64OctsPkts | 127628 |
| 65To127OctsPkts | 2345 |
| 256To511OctsPkts | 2629 |
| 512To1023OctsPkts | 1 |
| TxBytes | 1485924 |
| TxPkts | 12559 |
| TxUcastPkts | 8233 |
| TxMcastPkts | 4321 |
| TxBcastPkts | 5 |
| Tx64OcPkts | 4648 |
| Tx65To127OcPkts | 3293 |
| Tx128To255OcPkts | 4453 |
| Tx256To511OcPkts | 51 |
| Tx512To1023OcPkts | 56 |
| Tx1024To1518OcPkts | 58 |
+--------------------+------------------+
The following example shows sample output for port 1 total active statistics.
> port show port 1 total-statistics active
+-------------------- PORT 1 STATISTICS -------------------+

| Statistic | Total Value | Value |
+--------------------+------------------+------------------+
| RxBytes | 9677152 | 9677152 |
| RxPkts | 132855 | 132855 |
| RxCrcErrorPkts | 1 | 1 |
| RxUcastPkts | 8635 | 8635 |

| RxMcastPkts | 81281 | 81281 |

| RxBcastPkts | 42938 | 42938 |
| 64OctsPkts | 127873 | 127873 |
| 65To127OctsPkts | 2350 | 2350 |
| 256To511OctsPkts | 2631 | 2631 |
| 512To1023OctsPkts | 1 | 1 |
| TxBytes | 1493626 | 1493626 |
| TxPkts | 12654 | 12654 |
| TxUcastPkts | 8328 | 8328 |
| TxMcastPkts | 4321 | 4321 |
| TxBcastPkts | 5 | 5 |
| Tx64OcPkts | 4731 | 4731 |
| Tx65To127OcPkts | 3300 | 3300 |
| Tx128To255OcPkts | 4456 | 4456 |
| Tx256To511OcPkts | 52 | 52 |
| Tx512To1023OcPkts | 57 | 57 |
| Tx1024To1518OcPkts | 58 | 58 |
+--------------------+------------------+------------------+
The following example shows sample output for port 1 active throughput
statistics.
> port show port 1 throughput active
+---------------------- PORT 1 THROUGHPUT --------------------------------+

| Statistic | Current Value Delta Value Rate Mpps & Mbps |
+--------------------+----------------+----------------+------------------+
| Time | 1:19:56:19 | 0:00:14:20.0 | |
| RxBytes | 9.702 | 0.072 | 0.000 |
| RxPkts | 0.133 | 0.001 | 0.000 |
| RxUcastPkts | 0.009 | 0.000 | 0.000 |
| RxMcastPkts | 0.081 | 0.000 | 0.000 |
| RxBcastPkts | 0.043 | 0.000 | 0.000 |
| 64OctsPkts | 0.128 | 0.001 | 0.000 |
| 65To127OctsPkts | 0.002 | 0.000 | 0.000 |
| 256To511OctsPkts | 0.003 | 0.000 | 0.000 |
| TxBytes | 1.500 | 0.027 | 0.000 |
| TxPkts | 0.013 | 0.000 | 0.000 |
| TxUcastPkts | 0.008 | 0.000 | 0.000 |
| Tx64OcPkts | 0.005 | 0.000 | 0.000 |
| Tx65To127OcPkts | 0.003 | 0.000 | 0.000 |
| Tx128To255OcPkts | 0.004 | 0.000 | 0.000 |
| Tx256To511OcPkts | 0.000 | 0.000 | 0.000 |
| Tx512To1023OcPkts | 0.000 | 0.000 | 0.000 |
| Tx1024To1518OcPkts | 0.000 | 0.000 | 0.000 |
+--------------------+----------------+----------------+------------------+

Procedure 4-7
Monitoring port statistics
Use this procedure to continuously monitor port statistics for all ports or for
specific ports. The system displays the statistics and automatically clears the
screen before displaying the updated values.
To stop monitoring, press Ctrl+C.
Step Action
To monitor all ports for current statistics

1 Monitor all ports for current statistics:
port monitor statistics <statistics> [active] [delay
where
statistics displays all statistics collected from the last statistics clear
<statistics> operation.
1-86400
<NUMBER: 0-
4294967295>
| mega | kilo |
none>
To monitor all ports for total statistics

2 Monitor all ports for total statistics:
port monitor total-statistics <total-statistics> [active]
[delay <NUMBER: 1-86400>] [count <NUMBER: 0-4294967295>]
[scale <tera|giga|mega|kilo|none>]
where
total-statistics displays all statistics collected since the last boot-up.
<total-statistics>

where
1-86400
<NUMBER: 0-
4294967295>
| mega | kilo |
none>
To monitor all ports for throughput statistics
3 Monitor all ports for throughput statistics:
port monitor throughput <throughput> [active] [delay
where
throughput displays current throughput statistics.
<throughput>
1-86400
<NUMBER: 0-
4294967295>
| mega | kilo |
none>
To monitor specific ports

4 Monitor specific ports:
port monitor port <port> [active] [delay <NUMBER: 1-
86400>] [scale <tera|giga|mega|kilo|none>] {statistics]
[total-statistics] [throughput] [type
<all|basic|errors|tx|rx>]
where
port <port> is the port or ports that you want to monitor
1-86400
| mega | kilo |
none>
statistics displays port statistics.

where
total-statistics displays total port statistics.
throughput displays port throughput.
type <all | basic | is the type of statistics to show.
errors | tx | rx>
end
Examples
The following example shows sample output of monitoring total statistics for
all active ports.
> port monitor total-statistics active delay 10

<Screen clears>
+---------------------- PORT TOTAL STATISTICS SUMMARY --------------------+

| | Tx | Rx | Tx | Rx |
+---------+----------------+----------------+--------------+--------------+
| 1 | 170475797780 | 1053155263708 | 331687346 | 1372943892 |
| 2 | 22214864802 | 19878912 | 84101337 | 310608 |
| 12 | 885114437038 | 196217923208 | 1147664620 | 510799477 |
+---------+----------------+----------------+--------------+--------------+
The following example shows sample output of monitoring statistics for all
ports.
> port monitor statistics active delay 10

<Screen clears>
+-------------------------- PORT STATISTICS SUMMARY ----------------------+

| | Tx | Rx | Tx | Rx |
+---------+----------------+----------------+--------------+--------------+
| 2 | 36938335 | 67861410 | 224689 | 1023888 |
| 3 | 3522850 | 21965574 | 22329 | 228469 |
+---------+----------------+----------------+--------------+--------------+
The following example shows sample output of monitoring throughput

statistics for all ports.
> port monitor throughput active

Info: This CLI output may take a while to display press CTRL-C to abort
<Screen clears>
+------------- PORT THROUGHPUT SUMMARY 5 SECOND SAMPLE -----------------+
| Port | Bit Rate (Mbps) | Pkt Rate (Mpps) |
| | Tx | Rx | Tx | Rx |
+---------+----------------+----------------+--------------+--------------+
| 1 | 0.860 | | 0.001 | |
| 2 | 0.860 | | 0.001 | |
| 12 | | 2.984 | | 0.003 |
+---------+----------------+----------------+--------------+--------------+
The following example shows sample output of monitoring total statistics for a
specific port.
> port monitor port 1 total-statistics active delay 10

<Screen clears>
INFO: Waiting 10 seconds for display. Abort with CTRL-c
+-------------------- PORT 1 STATISTICS -------------------+

| Statistic | Total Value | Value |
+--------------------+------------------+------------------+
| RxBytes | 9844868 | 9844868 |
| RxPkts | 135233 | 135233 |
| RxCrcErrorPkts | 1 | 1 |
| RxUcastPkts | 9572 | 9572 |
| RxMcastPkts | 82222 | 82222 |
| RxBcastPkts | 43438 | 43438 |
| 64OctsPkts | 130164 | 130164 |
| 65To127OctsPkts | 2406 | 2406 |
| 256To511OctsPkts | 2662 | 2662 |
| 512To1023OctsPkts | 1 | 1 |
| TxBytes | 1580957 | 1580957 |
| TxPkts | 13396 | 13396 |
| TxUcastPkts | 9070 | 9070 |
| TxMcastPkts | 4321 | 4321 |
| TxBcastPkts | 5 | 5 |
| Tx64OcPkts | 5195 | 5195 |
| Tx65To127OcPkts | 3519 | 3519 |
| Tx128To255OcPkts | 4480 | 4480 |
| Tx256To511OcPkts | 65 | 65 |
| Tx512To1023OcPkts | 60 | 60 |
| Tx1024To1518OcPkts | 77 | 77 |
+--------------------+------------------+------------------+

The following example shows sample output for monitoring statistics for a
specific port.
> port monitor port 1 statistics active delay 10

<Screen clears>
+--------------- PORT 1 STATISTICS -----+

+--------------------+------------------+
| RxBytes | 9866442 |
| RxPkts | 135531 |
| RxCrcErrorPkts | 1 |
| RxUcastPkts | 9648 |
| RxMcastPkts | 82368 |
| RxBcastPkts | 43514 |
| 64OctsPkts | 130448 |
| 65To127OctsPkts | 2415 |
| 256To511OctsPkts | 2667 |
| 512To1023OctsPkts | 1 |
| TxBytes | 1586934 |
| TxPkts | 13454 |
| TxUcastPkts | 9128 |
| TxMcastPkts | 4321 |
| TxBcastPkts | 5 |
| Tx64OcPkts | 5238 |
| Tx65To127OcPkts | 3530 |
| Tx128To255OcPkts | 4482 |
| Tx256To511OcPkts | 66 |
| Tx512To1023OcPkts | 60 |
| Tx1024To1518OcPkts | 78 |
+--------------------+------------------+
The following example shows sample output for monitoring throughput

statistics for a specific port.
> port monitor port 1 throughput active

<Screen clears>
+---------------------- PORT 1 THROUGHPUT --------------------------------+

| Statistic | Current Value | Delta Value | Rate Mpps & Mbps |
+------------------+----------------+------------------+------------------+
| Time | 1:20:30:17 | 0:00:00:05.0 | |
| RxBytes | 9.887 | 0.000 | 0.000 |
| RxPkts | 0.136 | 0.000 | 0.000 |
| RxUcastPkts | 0.010 | 0.000 | 0.000 |
| RxMcastPkts | 0.083 | 0.000 | 0.000 |
| RxBcastPkts | 0.044 | 0.000 | 0.000 |
| 64OctsPkts | 0.131 | 0.000 | 0.000 |
| TxBytes | 1.593 | 0.000 | 0.000 |
| TxPkts | 0.014 | 0.000 | 0.000 |
| TxUcastPkts | 0.009 | 0.000 | 0.000 |
| Tx65To127OcPkts | 0.004 | 0.000 | 0.000 |
+------------------+----------------+------------------+------------------+

Procedure 4-8
Clearing current statistics
Clear current statistics when you no longer want to view them. Clearing
current statistics does not clear total statistics.
You can clear current statistics for

all ports
specific ports
Note: The port clear command does not clear TDM port statistics. For
more information about monitoring TDM statistics, refer to Performance
monitoring, in 39XX/51XX Service Delivery and Aggregation Switches
Fault and Performance Management (009-3220-009).
Step Action
To clear current statistics for all ports

1 Clear current statistics for all ports:
port clear statistics
To clear current statistics for specific ports
2 Clear current statistics for specific ports:
port clear port <port> statistics
where
port <port> is the port or ports that you want to clear statistics for.
end

Procedure 4-9
Displaying blade information
Display blade information.
Step Action
1 Display blade information:

blade show [attributes] [capabilities] [information]
[state]
where
attributes displays hardware device identification information.
Hardware device identification information is device type,
hardware version, serial number, MAC address,
manufactured date, and E-PROM (param) version.
The blade show attributes output varies depending on the
hardware platform. The CLEI Code is only displayed for
3916, 3930, 3931, and 5150 devices
capabilities displays the capabilities of the board and ports, including
blade type, RAM and flash file sizes, port types supported,
and enhanced ports.
information displays general blade information, including blade type,
number of ports, MAC address, administrative and
operational states, and date of last reboot.
state displays administrative and operational states.
end
Examples
The following example shows sample output for a single blade device.
> blade show
+----------------------- BLADE SUMMARY ----------------------+

| Slot | Ports | PortBaseMac | BladeType | OperState |
|------+-------+-------------------+-----------+-------------|
| 1 | 12 | 00:03:18:55:71:d2 | Single | Enabled |
+------+-------+-------------------+-----------+-------------+
The following example shows all extended blade details in one command (on
a 5150).
> blade show attributes capabilities information state
//The blade attributes:
+----------------- BLADE DEVICE ID -----------------+

| Parameter | Value |

+---------------------------+-----------------------+
| Board Device Type | 091 |
| Board Hardware Version | 1705150830/004 |
| Board Serial Number | B6054200 |
| Board MAC Address | 00:03:18:ac:e9:40 |
| Manufactured Date | 11-11-2010 |
| CLEI Code | COMP100BRA |
| Location of Manufacture | 1 |
| Module Part Num | 1705150900/009 |
| Module Serial Num | M6145938 |
| Param Version | 007 |
+---------------------------+-----------------------+
+--------------- MODULE 2 DEVICE ID ----------------+

+---------------------------+-----------------------+
| CLEI Code | COUIA3CPAA |
| Module Part Num | 1705100900/004 |
+---------------------------+-----------------------+
+--------------- MODULE 3 DEVICE ID ----------------+

+---------------------------+-----------------------+
| CLEI Code | COUIA7APAA |
| Module Part Num | 1705101900/002 |
+---------------------------+-----------------------+
//The blade capabilities:
+---------------------------- BOARD CAPABILITIES ----------------------------+

+--------------------+-------------------------------------------------------+
| Capability Class | 0 |
| Board Type | 091 |
| Board Name | CN 5150 |
| Board Description | CN 5150 Service Aggregation Switch |
| Blade Type | Single |
| No. Ports | 52 |
| Has Dcard | No |
| Address Ram Size | 0x0 |
| Boot Flash Size | 0x200000 |
| Packet Ram Size | 0x0 |
| Program Ram Size | 0x2000000 |
+--------------------+---------------------------------------------------------+
| No. 10 Gig Ports | 4 |
| No. Gig Ports | 48 |
| No. Fe Ports | 0 |
| No. 100Fx Ports | 0 |
| No. Eth Ports | 0 |
| Total Ports | 52 |
| Enhanced Ports List| 2.1 2.2 |
+--------------------+---------------------------------------------------------+

+-------------------------- SUMMARY PORT CAPABILITIES -----------------------------------+

| Port| Type | Speed | Duplex | Aneg | Pause | Enh |
+-----+--------------+-------------------------+----------+-------+---------------------+
| 1.1 | 100/G | 100Mbps,1Gig,Auto | half,full| on,off| off,sym,a-rx |No |
| 1.10| 100/G | 100Mbps,1Gig,Auto | half,full| on,off| off,sym,a-rx |No |
| 2.1 | 10GigEthernet| 10Gig | full | N/A | off |Yes |
| 2.2 | 10GigEthernet| 10Gig | full | N/A | off |Yes |
| 3.1 | 10GigEthernet| 10Gig | full | N/A | off |No |
| 3.2 | 10GigEthernet| 10Gig | full | N/A | off |No |
+-----+--------------+-------------------------+----------+-------+------------------+--+
//The blade information:
+------------------ BLADE INFO --------------------+

+-----------------------+--------------------------+
| Slot | 1 |
| Blade Type | Single |
| Number of Ports | 52 |
| Port Base MAC Address | 00:03:18:ac:e9:42 |
| Admin State | Enabled |
| Oper State | Enabled |

| Last Reboot | Thu Jan 1 00:00:00 1970 |

+-----------------------+--------------------------+
//The blade state:
+----- BLADE STATE ------+

| AdminState | OperState |
+------------+-----------+

Procedure 4-10
Displaying port capabilities
You can display:
port capabilities for the chassis and a summary of port capabilities
capabilities for a specified port
Step Action
To display port capabilities for the chassis and a summary of port capabilities
1 Display chassis port capabilities and a summary of all port capabilities:
port show capabilities
To display capabilities for a specific port
2 Display capabilities for a specific port:
port show port <port> capabilities
where
port <port> is a 32-character string representing the name of the
physical port or LAG.
end
Examples
The following example shows sample output for the port show capabilities
command.
> port show capabilities
+--------------------+----------------------------------------------------+
| No. 10 Gig Ports | 4 |
| No. Gig Ports | 8 |
| No. Fe Ports | 0 |
| No. 100Fx Ports | 0 |
| No. Eth Ports | 0 |
| Total Ports | 12 |
+--------------------+----------------------------------------------------+
+-------------------------- SUMMARY PORT CAPABILITIES -------------------------+

| Port| Type | Speed | Duplex | Aneg | Pause |
+-----+--------------+---------------------+----------+-------+----------------+
| 1 | 10/100/G | 10Mbps,100Mbps,1Gig,Auto| half,full| on,off| off,sym,a-rx |
| 9 | 10GigEthernet| 10Gig | full | N/A | off |


+-----+--------------+---------------------+----------+-------+----------------+
The following example shows sample output for the port show capabilities
command applied to a specified port.
> port show port 1 capabilities
+------------------------ PORT 1 CAPABILITIES --------------------+

| Field | Value |
+------------------------------+----------------------------------+
| Port Number | 1 |
| Port Type | 10/100/G |
| Port Speed | 10Mbps,100Mbps,1Gig,Auto |
| Port Duplex | half,full |
| Port Auto Negotiation | on,off |
| Port Pause Advertisement | off,sym,a-tx,s-a-rx |
| Port Pause | off,sym,a-rx |
| Port Feature Capabilities | Normal |
+------------------------------+----------------------------------+

Procedure 4-11
Displaying port Ethernet configuration
You can display port attributes for Ethernet configuration for all or for a specific
line module, including name, type, admin status, speed, duplex, flow control,
flow control advertised, auto negotiation, and MTU size.
Step Action
1 Display port attributes for Ethernet configuration:

port show ethernet-config
end
Example
The following example shows sample output for the port show ethernet-config
command.
> port show ethernet-config

+------------------------ PORT ETHERNET CONFIGURATION -------------------------+
| | | | | | | | | | Mirror |
| Port | Port | Admin | | | | FC |Auto | MTU | Status |
| Name | Type | Status | Speed | Dplx | FC | Adv |Neg | Size |State|Eg|Ig|
+--------+--------+--------+-------+------+-----+-----+-----+------+-----+--+--+
| 1 | Gig | Ena | 1000 | ?? | off | off | On | 1526 | Off | 0| 0|
| 2 | Gig | Ena | 1000 | Full | off | off | On | 1526 | Off | 0| 0|
| 3 | Gig | Ena | 1000 | Full | off | off | On | 1526 | Off | 0| 0|
| 4 |10/100/G| Ena | 1000 | ?? | off | off | On | 1526 | Off | 0| 0|
| 9 | 10Gig | Ena | 10G | ?? | off | off | Off | 1526 | Off | 0| 0|
+--------+--------+--------+-------+------+-----+-----+-----+------+-----+--+--+

Procedure 4-12
Displaying port status
Port status included the operational information, such as the link state, link
state duration, whether transceivers are enabled or disabled, speed, duplex,
maximum frame size, and flow control. You can display the status for all ports
or ports on a specific line module.
Step Action
1 Display port status:

port show status
end
Example
The following example shows sample output for the port show status
command.
> port show status

+------------------------ PORT OPERATIONAL STATUS ------------------------+
| | | |Link State| | |Speed/ |MTU |Flow |
|##| Description |Link|Duration |XCVR|STP|Duplex |Size|Ctrl |
+--+--------------------------+----+----------+----+---+-------+----+-----+
|1 | |Down| 1d21h35m| |Dis| |1526| |
|2 | | Up | 1d22h37m|Ena |FWD|1000/FD|1526|off |
|3 | | Up | 1d21h33m|Ena |FWD|1000/FD|1526|off |
|4 | |Down| 0h 0m 0s| |Dis| |1526| |
|5 | |Down| 0h 0m 0s| |Dis| |1526| |
|6 | |Down| 0h 0m 0s| |Dis| |1526| |
|7 | |Down| 0h 0m 0s| |Dis| |1526| |
|8 | |Down| 0h 0m 0s| |Dis| |1526| |
|9 | |Down| 0h 0m 0s| |Dis| |1526| |
|10| |Down| 0h 0m 0s| |Dis| |1526| |
|11| |Down| 0h 0m 0s| |Dis| |1526| |
|12| |Down| 0h 0m 0s| |Dis| |1526| |
+--+--------------------------+----+----------+----+---+-------+----+-----+

Procedure 4-13
Displaying a list of supported optics
Small Form-factor Pluggable (SFP) and 10 Gigabit SFPs (XFP) devices are
hot-swappable compact optical transceivers. Port transceiver information,
including status and type, is available via CLI or SNMP.
The system software supports transceivers that are compliant with the
following documents:
XFP Xcvr spec SFF INF 8077i Rev 4.5, Tunable Xcvr spec SFF-8477 Rev
1.3 Draft.
Small Form Factor Pluggable (SFP) Transceiver Multi Source Agreement,
September 14, 2000
Digital Diagnostic Monitoring Interface for Optical transceivers SFF-8473,
Draft Revision 9.0, April 4, 2002.
Step Action
1 Display a list of supported optics:

port xcvr show supported
Note: The output of "port xcvr show supported" is a generic table showing
the speed capabilities of each transceiver. However, the actual operational
speed depends upon the capabilities that are supported on the specific
platform and port.
end
Example
The following example shows sample output for the port xcvr show supported
command.
> port xcvr show supported
+----All Supported Transceivers----+

| | |
| Part Number | XCVR Speed |
+--------------------+-------------+
| XCVR-010X31 | 100M |
| XCVR-040X31 | 100M |
| XCVR-040R55 | 100M |
| XCVR-040R31 | 100M |
| XCVR-010S55 | 100M |
| XCVR-010S31 | 100M |
| XCVR-010L31 | 100M |
| XCVR-040L31 | 100M |
| XCVR-100D43 | 100M / 1G |
| XCVR-100D45 | 100M / 1G |
| XCVR-100D47 | 100M / 1G |
... |
+--------------------+-------------+

Procedure 4-14
Displaying transceiver information
Diagnostics can be displayed for transceivers that support diagnostics. If the
transceiver does not have internal diagnostics capabilities, an error is
returned.
You can display

diagnostic information for a specified port
a summary of transceiver status
a summary of transceiver status for a specific port
vendor EPROM data for a specific port
Step Action
To display diagnostic information for a specified port

1 Display diagnostic information for a specified port:
port show port <port> diagnostics
where
port <port> is the port or ports to show.
To display a summary of transceiver status

2 Display a summary of transceiver status:
port xcvr show
To display a summary of transceiver status for a specific port
3 Display a summary of transceiver status for a specific port:
port xcvr show port <port> state
where
To display vendor EPROM data for a specific port

4 Display vendor EPROM data for a specific port:
port show port <port> vendor
where
end

Example
The following example shows sample output for a transceiver that supports
diagnostics.
> port xcvr show port 3 diagnostics
+--------------------- XCVR DIAGNOSTICS - Port 3 -----------------+

| | | Alarm | Warning |
| Output | Value | Threshold | Flag | Threshold | Flag |
+---------------+----------+---------------+------+---------------+------+
| Temp (degC)| 42.031 | HIGH 105.000 | 0 | HIGH 100.000 | 0 |
| | | LOW -45.000 | 0 | LOW -40.000 | 0 |
+---------------+----------+---------------+------+---------------+------+
| Vcc (volts)| 3.299 | HIGH 3.630 | 0 | HIGH 3.460 | 0 |
| | | LOW 2.970 | 0 | LOW 3.130 | 0 |
+---------------+----------+---------------+------+---------------+------+
| Bias (mA)| 4.112 | HIGH 12.000 | 0 | HIGH 10.000 | 0 |
| | | LOW 1.000 | 0 | LOW 2.000 | 0 |
+---------------+----------+---------------+------+---------------+------+
| Tx Power (mW)| 0.257 | HIGH 1.412 | 0 | HIGH 0.707 | 0 |
| | | LOW 0.056 | 0 | LOW 0.112 | 0 |
+---------------+----------+---------------+------+---------------+------+
| Tx Power (dBm)| -5.8905 | HIGH +1.4999 | 0 | HIGH -1.5003 | 0 |
| | | LOW -12.5026 | 0 | LOW -9.5001 | 0 |
+---------------+----------+---------------+------+---------------+------+
| Rx Power (mW)| 0.0574 | HIGH 1.9954 | 0 | HIGH 1.0000 | 0 |
| | | LOW 0.0100 | 0 | LOW 0.0200 | 0 |
+---------------+----------+---------------+------+---------------+------+
| Rx Power (dBm)| -12.4109 | HIGH +3.0001 | 0 | HIGH +0.0000 | 0 |
| | | LOW -20.0000 | 0 | LOW -16.9897 | 0 |
+---------------+----------+---------------+------+---------------+------+
The following example shows sample output for a summary of transceiver

status.
> port xcvr show
+----+-----+-----+---------Transceiver-Status------------+----------------+----+
| |Admin| Oper| |Ether Medium & |Diag|
|Port|State|State| Vendor Name & Part Number |Connector Type |Data|
+----+-----+-----+---------------------------------------+----------------+----+
|1 |Empty| | | | |
|2 |Empty| | | | |
|3 |Ena |Ena |CIENA-FBX XCVR-A00G85 Rev10 |1000BASE-SX/LC |Yes |
|6 |Ena |Ena |CIENA-LMT XCVR-A80D43 RevA |1000BASE-LX/LC |Yes |
+----+-----+-----+---------------------------------------+----------------+----+
The following example shows sample output for a summary of transceiver

status for a specific port.
> port xcvr show port 12 state
+----+-----+-----+---------Transceiver-Status--------+---------------+----+
| |Admin| Oper| |Ether Medium & |Diag|
|Port|State|State| Vendor Name & Part Number |Connector Type |Data|
+----+-----+-----+-----------------------------------+---------------+----+
|12 |Ena |Ena |CIENA XCVR-010Y31 Rev10 |1000BASE-LX/LC | |
+----+-----+-----+-----------------------------------+---------------+----+

The following example shows sample output for vendor EPROM data for a
specific port.
> port xcvr show port 7 vendor
+------------------------ XCVR VENDOR DATA - Port 7 ------------------------+

| Parameter | Value | Decoded String Equivalent |
+--------------------------+--------------------+------------------------------+
| Identifier | 0x3 | SFP transceiver |
| Ext. Identifier | 0x4 | SFP/GBIC |
| Connector | 0x7 | LC |
+--------------------------+--------------------+------------------------------+
| Transceiver Codes | 0x010d001202000000 | |
| - 10 GbE Compliance | 0x00 | |
| - SONET Compliance | 0x0000 | |
| - Ethernet Compliance | 0x02 | 1000BASE-LX |
| - Link Length | 0x12 | Long distance (L) |
| - Transmitter Technology| 0x0012 | Longwave laser (LL) |
| - Transmission Media | 0x0d | Single Mode (SM) |
| - Channel speed | 0x01 | 100 MBytes/Sec |
+--------------------------+--------------------+------------------------------+
| Encoding | 0x01 | 8B10B |
| BR, Nominal | 13 | Gigabit |
|--------------------------+--------------------+------------------------------|
| Length(9um fiber) 1km | 10 | 10km |
| Length(9um fiber) 100m | 100 | 10000m |
| Length(50um) 10m | 55 | 550m |
| Length(62.5um) 10m | 55 | 550m |
| Length(copper) 1m | 0 | 0m |
|--------------------------+--------------------+------------------------------|
| Vendor Name | CIENA | |
| Vendor OUI | 0x000000 | |
| Vendor PN | XCVR-010M31-03 | |
| Vendor Revision | 10 | |
| Wavelength | 0 | |
|--------------------------+--------------------+------------------------------|
| Options | 0x1a | |
| - RATE_SELECT | Bit 5 | No |
| - TX_DISABLE | Bit 4 | Yes |
| - TX_FAULT | Bit 3 | Yes |
| - Loss of Signal Invert | Bit 2 | No |
| - Loss of Signal | Bit 1 | Yes |
|--------------------------+--------------------+------------------------------|
| BR, max | 0 | |
| BR, min | 0 | |
| Vendor Serial Number | A9640060800547 | |
| Date (mm/dd/yy) | 03/15/06 | |
|--------------------------+--------------------+------------------------------|
| Diag Monitor Type | 0x0 | |
| - Legacy diagnostics | Bit 7 | No |
| - Diagnostics monitoring| Bit 6 | No |
| - Internally calibrated | Bit 5 | No |
| - Externally calibrated | Bit 4 | No |
| - Rx power measurement | Bit 3 | OAM |
|--------------------------+--------------------+------------------------------|
| Enhanced Options | 0x0 | |
| - Alarm/Warning Flags | Bit 7 | No |
| - Soft TX_DISABLE | Bit 6 | No |
| - Soft TX_FAULT | Bit 5 | No |
| - Soft RX_LOS | Bit 4 | No |
| - Soft RATE_SELECT | Bit 3 | No |
|--------------------------+--------------------+------------------------------|
| SFF-8472 Compliance | 0x0 | None |
+--------------------------+--------------------+------------------------------+

Procedure 4-15
Determining transceiver speed
When a transceiver is plugged in, the port speed is blank until a link is
established, and then it is set to match the transceiver speed.
The Encoding Value column displays the actual value read from the optic,
while the Decoded String Equivalent column indicates the supported port
speed.
Step Action
1 Display transceiver information:

port xcvr show
2 Display transceiver vendor data:
port xcvr show port <port> vendor
where
vendor displays transceiver vendor data.
end
Examples
The following example shows sample output for the port show command.
> port show
+-----------------------------------------------------------------------------+
| Port Table | Operational Status | Admin Config |
|--------+--------+----+--------------+----+---+-------+----+----+-------+----|
| Port | Port | | Link State | | | |Auto| | |Auto|
| Name | Type |Link| Duration |XCVR|STP| Mode |Neg |Link| Mode |Neg |
|--------+--------+----+--------------+----+---+-------+----+----+-------+----|
| 1 |10/100/G| Up | 0d 5h 4m27s| |FWD| 100/FD| On |Ena |1000/FD| On |
| 2 |10/100/G| Up | 0d 5h 4m27s| |FWD| 100/FD| On |Ena |1000/FD| On |
| 3 |10/100/G|Down| 0d 0h 0m 0s| |Dis| | On |Ena |1000/FD| On |
| 9 |10/100/G|Down| 0d 0h 0m 0s| |Dis| | On |Ena |Auto/FD| On |
| 12 | Gig | Up | 4d 2h48m52s|Ena |FWD|1000/FD| On |Ena |Auto/FD| On |
+--------+--------+----+--------------+----+---+-------+----+----+-------+----+
The following example shows sample output for the port xcvr show port
<PortNameList> vendor command.

> port xcvr show port 1 vendor
+------------------------ XCVR VENDOR DATA - Port 1 ------------------------+

| Parameter | Value | Decoded String Equivalent |
+--------------------------+--------------------+------------------------------+
| Identifier | 0x3 | SFP transciever |
| Ext. Identifier | 0x4 | SFP/GBIC |
| Connector | 0x7 | LC |
+--------------------------+--------------------+------------------------------+
| Transceiver Codes | 0x0000000002000000 | |
| - SONET Compliance | 0x0000 | |
| - Ethernet Compliance | 0x02 | 1000BASE-LX |
| - Link Length | 0x00 | unknown |
| - Transmitter Technology| 0x0000 | unknown |
| - Transmission Media | 0x00 | unknown |
| - Channel speed | 0x00 | unknown |
+--------------------------+--------------------+------------------------------+
| Encoding | 0x01 | 8B10B |
| BR, Nominal | 13 | Gigabit |
|--------------------------+--------------------+------------------------------|
...
+--------------------------+--------------------+------------------------------+

Procedure 4-16
Tuning XFP transceivers
Tunable XFPs provide the ability to set the laser frequency in gigahertz (GHz),
wavelength in nanometers with decimals, or set the channel. When you set
the value for the frequency, wavelength, or channel, the other parameters are
automatically populated.
If the range is set out of the supported range for the XFP, an error message is
returned with the correct range. Attempting to set the tuning parameters for an
SFP that does not support tunability generates an error.
Note: Tuning an XCVR will cause a traffic outage lasting no more than a
few seconds.
Step Action
To tune XFP transceivers

1 View the current values for frequency, wavelength or channel:
port xcvr show port <port> tunability
where
tunability displays transceiver tunable data.
2 Set the frequency, wavelength, or channel:

port xcvr set port <port> {[frequency <NUMBER>] |
[wavelength <String>] | [channel <NUMBER>]}
where
port <port> is the port or ports to set.
frequency is the transceiver frequency in GHz.
<NUMBER>
wavelength is the transceiver wavelength in nanometers.
<String>
channel is the transceiver channel number.
<NUMBER>

To unset transceiver values

3 Unset transceiver values:
port xcvr unset port <port> {frequency} {wavelength}
{channel}
where
port <port> is the port or ports to unset.
frequency is the transceiver frequency.
<NUMBER>
wavelength is the transceiver wavelength.
<String>
channel is the transceiver channel number.
<NUMBER>
end
Examples
The following example shows sample output for a port with a tunable XFP.
> port xcvr show port 2.1 tunability
+-------------------- XCVR Tunability - Port 2.1 -----------------+

| Field | Value |
+----------------------------------------------------------------------+
| Frequency Tunable | Yes |
+-----------------------+-----------------+-----------------+----------+
| | GHz | nm | ch# |
| +-----------------+-----------------+----------+
| Admin | 191100 | 1568.8 | 1 |
| Oper Min | 191100 | 1568.8 | 1 |
| Oper Max | 196150 | 1528.4 | 102 |
| Oper Value | 191100 | 1568.8 | 1 |
| Oper Error | 0 | 0.0 | 0 |
+-----------------------+-----------------+-----------------+----------+
| Oper Grid Spacing | 50 |
+-----------------------+----------------------------------------------+
The following example shows sample output for a port without support for
tunability.
> port xcvr show port 48 tunability
Not Supported for port 48
The following example sets the frequency to 196150 on port 9.
> port xcvr set port 9 frequency 196150

Procedure 4-17
Setting the port connector mode
Some ports (called dual mode or combination ports) support both RJ45 and
SFP (including smaller size SFP+) connectors. Only one of these connectors
can be active at a given time. Some ports support a default connector mode,
where the mode operates as SFP if a transceiver is installed, or an RJ45 if not.
You can set the connector mode manually for the port. Table 4-4 shows the
dual mode ports and default mode for each platform that supports them.
Table 4-4
Factory default general port settings by platform
Platform Ports Default Connector Mode
3930 1-4 Default
3932 1-4 Default
3940 1-24 RJ45
5140 1-24 SFP
Note: The port connector mode is applicable only to combination ports

that support RJ45 or SFP connectors. It does not apply to XFP ports.
In addition, speed is set to Auto with auto-negotiation enabled. So, you can
install 1G or 100M transceivers, and the system will automatically set the
speed accordingly. If these settings or other port attributes are set explicitly
and do not match the capabilities of the active connector, a mismatch warning
is generated. The warning is cleared when the attributes match the
capabilities of the active connector.
Note: If you attempt to set the mode to a connector that is not supported
for the specified port, the system generates a Capability not supported
error message.
Step Action
1 Set the mode for a specific port:

port set port <port> mode <default|rj45|sfp>
where
mode is the physical interface connector mode.
<default|rj45|sfp>

Example
The following example sets the mode for port 9 to RJ45.
port set port 9 mode rj45

5-1
Hardware resource management 5-
This chapter describes how to configure resource management for

customized assignment of hardware resources.
CAUTION
Service disruption
Configuration of resource management requires a reboot to
implement changes.
The system assigns hardware resources (classifier, meter, and counter

resource types) for various software features. Depending upon the feature,
you can reassign these resources to provide additional resources for other
features.
This customized resource management is supported for the following

features:
Accelerated CFM over PBB-TE
Broadcast containment
CFM
DHCP relay
Loss measurement
Traffic profiling
Virtual circuit statistics
Virtual switch Layer 2 enhanced transforms
Transport OAM

5-2 Hardware resource management
Each resource type is mapped into a number of pools, where each pool
contains a number of resources. The number of pools and resources per pool
depends upon the platform as shown in Table 5-1.
Table 5-1
Resource pools
Platform Resource type Number of pools Pool boundary
3940, 5140 Classifiers 16 128
Meters 16 128
Counters 16 128
3916, 3930, 3931, Classifiers 8 256

3932
Meters 8 512 (256 meter pairs)
Counters 8 256
3960, 5142, 5150, Classifiers 16 512

5160
Meters 16 1024 (512 meter pairs)
Counters 16 512
Meter resources are allocated differently depending upon the platform. On the
3940 and 5140 platforms, the reserved resources limit prevents meters from
being consumed by other features. On the 3916, 3930, 3931, 3932, 3960,
5142, 5150, and 5160, the meter resources are global, and availability is not
restricted, but is only configurable for certain features. The 3916, 3930, 3931,
and 3932 platforms have an actual system wide limit of 2048. The 3960, 5142,
5150, and 5160 platforms have an actual system wide limit of 8192 meters,
though the sum of all assigned meter counts can exceed 8192 up to 16,384.
The reserved resource value represents a limit to the number of resources for
a feature, but does not guarantee availability.

Each feature consumes hardware resources at a different rate depending

upon the configuration as shown in Table 5-2.
Table 5-2
Resources consumed per feature and type
Feature Resource type Resources consumed
Accelerated CFM over Classifiers 1

PBT (configurable on
5150 only) Meters 0
Counters 0
Broadcast containment Classifiers 3 maximum per filter
Meters 2
Counters 2
CFM (not configurable Classifiers On 3960, 5142, 5150, and 5160 platforms, CFM
on 3916, 3930, 3931, consumes 39 static entries by default. On 3940 and
and 3932) 5140 platforms, CFM consumes classifiers depending
upon the configuration and classification type in use. For
details, refer to 39XX/51XX Service Delivery and
Aggregation Switches Fault and Performance
Management (009-3220-009).
Meters 0
Counters 0
DHCP relay (not Classifiers On 3960, 5142, 5150 and 5160 platforms, DHCP relay
configurable on 3916, consumes 2 static entries by default. On 3940 and 5140
3930, 3931, and 3932) platforms, DHCP relay consumes 2 classifiers for each
VLAN with DHCP relay enabled.
Meters 0
Counters 0
Loss Measurement Classifiers 2

(3916, 3930, 3931,
3932, 5142, 5160 Meters 0
only) Counters 0

Table 5-2
Resources consumed per feature and type (continued)
Traffic profiling Classifiers Varies. By default, each port is set to the standard-
dot1dpri mode, which consumes 2 classifiers per port.
Additional standard traffic profile entries consume
classifiers based on the highest number of configured
classifiers per type.
standard-dot1dpri - up to 8
standard-ip-prec - up to 8
standard-dscp - up to 64
standard-vlan - 1
standard-vlan-dot1dpri - up to 9
standard-vlan-ipp - up to 9
standard-vlan-dscp - up to 65
hierarchical-port (3916, 3930, 3931, 3932, 3960, 5142,
5150, and 5160) - Consumes classifiers based upon
the sum of the parent and child mode classifiers.
hierarchical-vlan (3916, 3930, 3931, 3932, 3960,
5142, 5150, and 5160) - Consumes classifiers based
upon the sum of the parent and child mode classifiers.
For example, if you created a traffic profile entry with
2.1D, 2 IP Prec, and 12 DSCP classifiers, the total
classifiers consumed would be 12.
Meters 2
Counters 2
Transport OAM Classifiers 250 static entries by default

(configurable on 3916,
3930, 3931, 3932, 3960 Meters 0
5142, 5150, and 5160 Counters 0
platforms)

Table 5-2
Resources consumed per feature and type (continued)
Virtual circuit statistics Classifiers Varies. When statistics are enabled for a virtual circuit,
classifiers are consumed depending upon the number of
ports in the provider VLAN associated with the virtual
circuit and the platform.
On the 3916, 3930, 3931, 3932, 3960, 5142, 5150, and
5160 platforms, a virtual circuit consumes one
classifier for received traffic, and each port in the
provider VLAN consumes one classifier for transmitted
traffic.
On the 3940 and 5140 platforms, a virtual circuit
consumes two classifiers for received traffic, and each
port in the provider VLAN consumes two classifiers for
transmitted traffic.
Meters 0
Counters Varies. When statistics are enabled for a virtual circuit,

counters are consumed depending upon the number of
ports in the provider VLAN associated with the virtual
circuit.
On the 3960, 5142, 5150, and 5160 platforms, a virtual
circuit consumes one counter for received traffic, and
each port in the provider VLAN consumes one counter
for transmitted traffic.
On the 3940 and 5140 platforms, a virtual circuit
consumes two counters for received traffic, and each
port in the provider VLAN consumes two counters for
transmitted traffic
Virtual switch enhanced Classifiers 8 static entries by default

L2 transform
(configurable on 3916, Meters 0
3930, 3931, 3932, 3960 Counters 0
5142, 5150, and 5160
platforms)

This chapter provides the following procedures for hardware resources:

Configuring resources on page 5-7
Freeing all accelerated CFM over PBB-TE resources on page 5-9
Restoring accelerated CFM over PBB-TE resources to default values on
page 5-11
Freeing all broadcast containment resources on page 5-13
Restoring broadcast containment resources to default values on page
5-14
Freeing CFM resources on page 5-16
Restoring CFM resources to default values on page 5-17
Freeing DHCP relay resources on page 5-19
Restoring DHCP relay resources to default values on page 5-20
Freeing traffic profiling resources on page 5-25
Setting traffic profiling resources on page 5-27
Restoring traffic profiling resources to default values on page 5-30
Freeing virtual circuit statistics resources on page 5-32
Restoring virtual circuit statistics resources to default values on page
5-33
Configuring virtual switch L2 enhanced transform resources on page
5-35
Freeing all virtual switch L2 enhanced transform resources on page 5-37
Configuring transport OAM resources on page 5-38
Freeing all transport OAM resources on page 5-40
Displaying resource configuration information on page 5-41
Resolving resource configuration validation errors on page 5-42
Addressing classifier resource allocation too small for current
configuration error on page 5-43
Displaying resource configuration in the configuration file on page 5-45

Procedure 5-1
Configuring resources
When setting the pool count, enter the value of the number of resources. The
system rounds the number of resources up to the nearest pool boundary listed
in Table 5-1 and allocates the specified number of resources by pool. For
example, if 750 traffic profile classifier resources are specified to be
reallocated on the 3960 platform, 750 is rounded up to the nearest pool
boundary, 1024, so 2 pools are reallocated.
On every platform, the number of allocated pools for each resource type must
match.
On the 3940 and 5140 platforms, the configured pool count for each resource
type must be equal.
On the 3916, 3930, 3931, 3932, 3960, 5142, 5150, and 5160 platforms, for
features that use meters, that is, traffic-profiling and broadcast-containment,
the configured count for meters must be equal to twice the configured count
of the classifier type. For features that do not use meters the value should be
0 for meters. The configured count for the classifier and counter must match,
otherwise, the validation will fail.
Note: For 3940 and 5140 platforms, the system software requires the
reservation of each resource type, regardless of whether the feature uses
the resource. For example, traffic profiling and broadcast containment are
the only two features that actually consume meter resources. If you are
configuring classifiers or counters to reassign them to a feature that
doesnt actually consume meters, you still have to configure the
assignment of meter resources.
After reassigning resources, you can manually run the command to validate
resource configuration. In addition, the system software performs resource
validation automatically when you save the configuration. When the validation
is successful, the CLI returns to the prompt. If resource validation fails, an
error message is generated. For error examples and resolutions, see
Resolving resource configuration validation errors on page 5-42.
Note: If resource validation fails while attempting to save the

configuration, the configuration is not saved.

Once the validation is successful, you need to reboot in order for the resource
allocation to take effect.
Step Action
1 Set the pool counts for each resource type per feature you want to reassign
from.
resource-manager pool set resource
<classifier|meter|counter> feature <accelerated-cfm-
over-pbt | broadcast-containment | cfm | dhcp-relay |
traffic-profiling | transport-oam | vc-statistics | vs-
enhanced-l2-transform> count <NUMBER>
2 Set the pool counts for each resource type per feature you want to reassign
to.
resource-manager pool set resource
<classifier|meter|counter> feature <accelerated-cfm-
over-pbt | broadcast-containment | cfm | dhcp-relay |
traffic-profiling | transport-oam | vc-statistics | vs-
enhanced-l2-transform> count <NUMBER>
3 Validate the configuration.
resource-manager validate
4 Save the configuration.
configuration save
5 Reboot the system to implement the changes.
chassis reboot
end

Procedure 5-2
Freeing all accelerated CFM over PBB-TE resources
If accelerated CFM over PBB-TE is not used, you can free up the classifier,
meter, and counter resources allocated to accelerated CFM over PBB-TE in
order to use them for other features, for example, traffic profiling. Free up
classifier, meter, and counter resources by setting them to 0.
CFM over PBB-TE resources are only configurable on the 5150 platform.
Step Action
1 Disable accelerated CFM over PBB-TE:

cfm service disable service <service>
where
service <service> is accelerated CFM over PBB-TE.
2 Unset the accelerate attribute:

cfm service unset service <service> accelerate
where
3 Enable accelerated CFM over PBB-TE:

cfm service enable service <service>
where
4 Set the pool count for classifier resources to 0.

resource-manager pool set resource classifier feature
accelerated-pbt-over-cfm count 0
5 Set the pool count for meter resources to 0.
resource-manager pool set resource meter feature
6 Set the pool count for counter resources to 0.
resource-manager pool set resource counter feature


configuration save
chassis reboot
end

Procedure 5-3
Restoring accelerated CFM over PBB-TE resources to
default values
Restore accelerated CFM over PBB-TE resources to default values if you
allocated the resources to different features, and then choose to use
accelerated CFM over PBB-TE.
Table 5-4 shows the default and maximum number of resources that can be
reserved for accelerated CFM over PBB-TE.
Table 5-3
Accelerated CFM over PBB-TE default and maximum resources reservation
Platform Resource type Default Maximum

resources
5150 Classifiers 512 512
Meters 0 512
Counters 512 512
Step Action
1 Set the pool count for classifier resources to the default for the platform:
accelerated-pbt-over-cfm count <ClassifierResources>
where
<ClassifierResources> is the default pool count for classifier resources for the
platform.
2 Set the pool count for meter resources to the default for the platform.
accelerated-pbt-over-cfm count <MeterResources>
where
<MeterResources> is the default pool count for meter resources for the
platform.

3 Set the pool count for counter resources to the default for the platform.
accelerated-pbt-over-cfm count <CounterResources>
where
<CounterResources> is the default pool count for counter resources for the
platform.

configuration save
chassis reboot
end

Procedure 5-4
Freeing all broadcast containment resources
If broadcast containment is not used, you can free up the classifier, meter, and
counter resources allocated to broadcast containment in order to use them for
other features, for example, traffic profiling. Free up classifier, meter, and
counter resources by setting them to 0.
Resources are not required if the broadcast containment resource mode is set
to off. You can set the broadcast containment resource mode by means of the
broadcast containment set resource mode off command.
Step Action
1 Delete any existing broadcast containment filters.

broadcast-containment delete filter <BcastFilterName>
where
<BcastFilterName> is the name of the broadcast containment filter to delete

broadcast-containment count 0
configuration save
chassis reboot
end

Procedure 5-5
Restoring broadcast containment resources to
default values
Restore broadcast containment resources to default values if you allocated
the resources to different features, and then choose to use broadcast
containment.
reserved for broadcast containment.
Table 5-4
Broadcast containment default and maximum resources reservation per
platform

resources
3940, 5140 Classifiers 128 128
Meters 128 128
Counters 128 128
3916, 3930, 3931, Classifiers 256 256

3932
Meters 512 512
Counters 256 256
3960, 5142, 5150, Classifiers 512 512

5160
Meters 1024 1024
Counters 512 512
Step Action
1 Set the pool count for classifier resources to the default for the platform:
broadcast-containment count <ClassifierResources>
where
platform.

broadcast-containment count <MeterResources>
where
platform.
broadcast-containment count <CounterResources>
where
platform.

configuration save
chassis reboot
end

Procedure 5-6
Freeing CFM resources
If for any reason, the number of consumed classifiers exceeds the configured
reservation, then CFM will switch from service network mode to global mode.
In global mode, classifiers are based on the EtherType and MD level only,
rather than service network, EtherType, and MD level, so any frame with a
CFM or Y.1731 EtherType will be delivered to the CPU.
If CFM is not used, you can reallocate the resources reserved for classifier,
meter, and counter resources to 0 and use them for another feature.
CFM resources are only configurable on the 3940, 3960, 5140, 5142, 5150,
and 5160 platforms.
Step Action
1 Delete any existing CFM services.

cfm service delete service <CfmService>
where
<CfmService> is the CFM service to delete

resource-manager pool set resource classifier feature cfm
count 0
resource-manager pool set resource meter feature cfm
count 0
resource-manager pool set resource counter feature cfm
count 0
configuration save
chassis reboot
end

Procedure 5-7
Restoring CFM resources to default values
Restore CFM resources to default values if you allocated the resources to
different features, and then choose to use CFM.
reserved for CFM.
Table 5-5
CFM default and maximum resource reservation per platform

resources
3940, 5140 Classifiers 128 1792
Meters 128 1792
Counters 128 1792
3916, 3930, 3931, Classifiers Not applicable Not applicable

3932
Meters Not applicable Not applicable
Counters Not applicable Not applicable
3960, 5142, 5150, Classifiers 512 512

5160
Meters 0 0
Counters 512 512
Step Action
1 Set the pool count for classifier resources to the default for the platform.
resource-manager pool set resource classifier feature cfm
count <ClassifierResources>
where
platform.

resource-manager pool set resource meter feature cfm
count <MeterResources>
where
platform.
resource-manager pool set resource counter feature cfm
count <CounterResources>
where
platform.

configuration save
chassis reboot
end

Procedure 5-8
Freeing DHCP relay resources
DHCP relay resources are only configurable on the 3940, 3960, 5140, 5142,
5150, and 5160 platforms.
If DHCP relay is not used, you can reallocate the resources reserved for
classifier, meter, and counter resources to 0 and use them for another feature.
Step Action
1 Delete any existing DHCP relay entries.

dhcp l2-relay-agent delete vlan <VlanList>
where
<VlanList> is the VLAN ID of the relay agent

dhcp-relay count 0
resource-manager pool set resource meter feature dhcp-
relay count 0
dhcp-relay count 0
configuration save
chassis reboot
end

Procedure 5-9
Restoring DHCP relay resources to default values
Restore DHCP relay resources to default values if you allocated the resources
to different features, and then choose to use DHCP relay.
reserved for DHCP relay.
Table 5-6
DHCP relay default and maximum resource reservation per platform

resources
3940, 5140 Classifiers 128 256
Meters 128 256
Counters 128 256
3916, 3930, 3931, Classifiers Not configurable Not configurable

3932
Meters Not configurable Not configurable
Counters Not configurable Not configurable
3960, 5142, 5150, Classifiers 512 512

5160
Meters 0 0
Counters 512 512
Step Action
dhcp-relay count <ClassifierResources>
where
platform.

relay count <MeterResources>
where
platform.
dhcp-relay count <CounterResources>
where
platform.

configuration save
chassis reboot
end

Procedure 5-10
Configuring loss measurement resources
Configure loss measurement resources so that hardware-assisted Y.1731
loss measurement session storage and counter management is performed by
means of the Broadcom processor instead of the FPGA. Loss management
resources are only configurable on the 3916, 3930, 3931, 3932, 5142, and
5160 platforms.
By default, loss measurement does not have any assigned resources. To use
this feature, you need to assign available classifier and counter resources to
it. On 3916, 3930, 3931, and 3932 platforms, allocation of one resource block
(of 256 classifiers) supports up to 42 loss measurement sessions. A maximum
of 120 loss measurement sessions can be configured for the platform. On
5142 and 5160 platforms, allocation of one resource block (of 512 classifiers)
supports up to 85 loss measurement sessions. A maximum of 255 loss
measurement sessions can be configured for the platform.
The default and maximum number of resources that can be reserved for loss
measurement are shown in Table 5-11.
Table 5-7
Loss measurement default and maximum resource reservations per platform
Platform Resource type Default Maximum resources
3940, 3960, 5140, 5150 Classifiers Not applicable Not applicable
3916, 3930, 3931, 3932 Classifiers 0 768
Meters 0 768
Counters 0 768
5142, 5160 Classifiers 0 1536
Meters 0 1536
Counters 0 1536

Step Action
loss-measurement count <ClassifierResources>
where
<ClassifierResources> is the desired pool count for classifier resources for the
platform.
relay count <MeterResources>
where
platform.
dhcp-relay count <CounterResources>
where
platform.

configuration save
chassis reboot
end

Procedure 5-11
Freeing all loss measurement resources
To configure loss measurement resources so that hardware-assisted Y.1731
loss measurement session storage and counter management is performed by
means of the FPGA instead of the Broadcom processor, you can reallocate
the resources back to 0 and use them for another feature.
Note that 0 is the default value for resources. Loss management resources are
only configurable on the 3916, 3930, 3931, 3932, 5142, and 5160 platforms.
Step Action

loss-measurement count 0
configuration save
chassis reboot
end

Procedure 5-12
Freeing traffic profiling resources
If traffic profiling is not used, you can reallocate the resources reserved for
classifier, meter, and counter resources to 0 and use them for another feature.
Note: On 3916, 3930, 3931, 3932, 3960, 5142, 5150, and 5160 platforms,
which use the global meter pool, the maximum resources shows a
configurable maximum and an actual maximum.
The configurable maximum is twice the number of classifiers and

counters and the value can be greater than the global meter pool.
The actual maximum is equal to the size of the global meter pool.
Before reassigning traffic profiling resources for other features on 3940 and
5140 platforms, you may need to adjust the port to traffic profiling meter pool
assignments to make sure there are enough traffic profiling meter pools that
are empty. When ports are associated with a traffic profiling meter pool as
described in Setting traffic profiling port attributes on page 14-44, hardware
resources are allocated for classifiers, meters, and counters (statistics). Also,
for each associated port, 2 classifier resources, 1 for ARP and 1 for non-
conforming standard profiles, are automatically consumed.
Step Action
1 Delete any existing traffic profiles.

traffic-profiling delete port <PortNameList> profile
<TrafficProfStd>
where
<PortNameList> is the list of ports that you want to delete existing traffic
profiles from.
<TrafficProfStd> sets the parent profile.
2 Set the traffic profiling mode to none for each port.

traffic-profiling set <PortName> mode none
where
<PortName> is the name of the port.

traffic-profiling count 0


resource-manager pool set resource meter feature traffic-
profiling count 0
configuration save
chassis reboot
end

Procedure 5-13
Setting traffic profiling resources
The default and maximum number of resources that can be reserved for traffic
profiling per resource type are shown in Table 5-8.
Table 5-8
Traffic profiling default and maximum resource reservation

resources
3940, 5140 Classifiers 1024 1792
Meters 1024 1792
Counters 1024 1792
3916, 3930, 3931, Classifiers 1024 1536

3932
Meters 2048 3072 (configurable)
2048 (actual)
Counters 1024 1536
3960, 5142, 5150, Classifiers 4096 7168

5160
Meters 8192 14336
(configurable) 8192
(actual)
Counters 4096 7168
Note: Traffic profiling meter pools are only applicable on 3940 and 5140
platforms.

Step Action
1 Determine available non-empty meter pools:

traffic-profiling show meter-pool
2 Reassign the ports in one of the meter pools to a different non-empty meter
pool:
traffic-profiling set port <PortName> meter-pool
<MeterPool>
where
port <PortName> is the port to be reassigned.
meter-pool is the non-empty meter pool that the ports are to be
<MeterPool> reassigned to.
3 Set classifier resources to lower the pool count by three resource pools:
traffic-profiling count <NUMBER>
where
count is the resource count.
<NUMBER>
4 Set meter resources to lower the pool count by three resource pools:
where
<NUMBER>
5 Set counter resources to lower the pool count by three resource pools:
where
<NUMBER>
6 Validate the configuration:

7 Save the configuration:
configuration save
8 Reboot the system to implement the changes:
chassis reboot
end

Example
The following example shows sample output for the traffic-profiling show
meter-pool command, which is used to determine available non-empty meter
pools in step 1.
+--------------------- TRAFFIC-PROFILING METER-POOL MAP -----------------------+

| Meter-Pool | Ports |Class | Used |Meters| Used |Stats | Used |
+------------+-----------------------+------+------+------+------+------+------+
| TP-POOL1 | | 128 | 2 | 64 | 0 | 64 | 0 |
+------------+-----------------------+------+------+------+------+------+------+
| TP-POOL2 | | 128 | 0 | 64 | 0 | 64 | 0 |
+------------+-----------------------+------+------+------+------+------+------+
| TP-POOL3 | 1 2 | 128 | 4 | 64 | 0 | 64 | 0 |
+------------+-----------------------+------+------+------+------+------+------+
| TP-POOL4 | 3 4 | 128 | 4 | 64 | 0 | 64 | 0 |
+------------+-----------------------+------+------+------+------+------+------+
| TP-POOL5 | 5 6 | 128 | 4 | 64 | 0 | 64 | 0 |
+------------+-----------------------+------+------+------+------+------+------+
| TP-POOL6 | 7 8 | 128 | 3 | 64 | 1 | 64 | 1 |
+------------+-----------------------+------+------+------+------+------+------+
| TP-POOL7 | 9 10 | 128 | 4 | 64 | 0 | 64 | 0 |
+------------+-----------------------+------+------+------+------+------+------+
| TP-POOL8 | 11 12 | 128 | 4 | 64 | 0 | 64 | 0 |
+------------+-----------------------+------+------+------+------+------+------+
In this example, ports 3 and 4 from TP-POOL4 are re-assigned to TP-POOL3

and TP-POOL5 respectively.
traffic-profiling set port 3 meter-pool TP-POOL3

traffic-profiling set port 4 meter-pool TP-POOL5

Procedure 5-14
Restoring traffic profiling resources to default values
Restore traffic profiling resources to default values if you allocated the
resources to different features, and then choose to use traffic profiling.
The default and maximum number of resources that can be reserved for traffic
profiling per resource type are shown in Table 5-9.
Table 5-9
Traffic profiling default and maximum resource reservation

resources
3940, 5140 Classifiers 1024 1792
Meters 1024 1792
Counters 1024 1792
3916, 3930, 3931, Classifiers 1024 1536

3932
Meters 2048 3072 (configurable)
2048 (actual)
Counters 1024 1536
3960, 5142, 5150, Classifiers 4096 7168

5160
Meters 8192 14336
(configurable) 8192
(actual)
Counters 4096 7168

Step Action
traffic-profiling count <ClassifierResources>
where
platform.
traffic-profiling count <MeterResources>
where
platform.
traffic-profiling count <CounterResources>
where
platform.

configuration save
chassis reboot
end

Procedure 5-15
Freeing virtual circuit statistics resources
If virtual circuit statistics are not used, you can reallocate the resources
reserved for classifier, meter, and counter resources to 0 and use them for
another feature.
Note: On 3916, 3930, 3931, 3932, 3960, 5142, 5150, and 5160 platforms,
which use the global meter pool, the maximum resources shows a
configurable maximum and an actual maximum.
The configurable maximum is twice the number of classifiers and

counters and the value can be greater than the global meter pool.
The actual maximum is equal to the size of the global meter pool.
Step Action
1 Disable statistics for each virtual circuit with statistics collection turned on.
virtual-circuit ethernet set vc <VcEth> statistics off
where
<VcEth> is the virtual circuit.

vc-statistics count 0
configuration save
chassis reboot
end

Procedure 5-16
Restoring virtual circuit statistics resources to default
values
Restore virtual circuit statistics resources to default values if you allocated the
resources to different features, and then choose to use virtual statistics
resources.
The default and maximum number of resources that can be reserved for
virtual circuit statistics are shown in Table 5-10.
Table 5-10
Virtual circuit statistics default and maximum resource reservation per
platform

resources
3940, 5140 Classifiers 128 1792
Meters 128 1792
Counters 128 1792
3916, 3930, 3931, Classifiers 128 1536

3932
Meters 0 0
Counters 128 1536
3960, 5142, 5150, Classifiers 512 7168

5160
Meters 0 0
Counters 512 7168
Step Action
vc-statistics count <ClassifierResources>
where
platform.

vc-statistics count <MeterResources>
where
platform.
vc-statistics count <CounterResources>
where
<CounterResources> is the default pool count for meter resources for the
platform.

configuration save
chassis reboot
end

Procedure 5-17
Configuring virtual switch L2 enhanced transform
resources
Virtual switch L2 enhanced transform resources are only applicable to the
3916, 3930, 3931, 3932, 3960, and 5150 platforms. Configuring virtual switch
L2 enhanced transform resources on the 3940 and 5140 platforms is not
supported. On the 5142 and 5160 platforms, it is not required.
By default, virtual switch L2 enhanced transform does not have any assigned
resources. To use this feature, you need to assign available classifier and
counter resources to it.
virtual switch L2 enhanced transform are shown in Table 5-11.
Table 5-11
Virtual switch L2 enhanced transform default and maximum resource reservations per platform
3940, 5140 Classifiers Not applicable Not applicable
5142, 5160 Classifiers Not required Not required
Meters Not required Not required
Counters Not required Not required
3916, 3930, 3931, 3932 Classifiers 0 256
Meters 0 0
Counters 0 256
3960, 5142, 5150, 5160 Classifiers 0 512
Meters 0 0
Counters 0 512

Step Action
1 Set the pool count for classifier resources.

vs-enhanced-l2-transform count <NUMBER>
where
count <NUMBER> is the number of resources to assign.
2 Set the pool count for counter resources.

vs-enhanced-l2-transform count <CounterResources>
where
<CounterResources> is the pool count for counter resources for the platform.

configuration save
chassis reboot
end

Procedure 5-18
Freeing all virtual switch L2 enhanced transform
resources
If virtual switch L2 enhanced transform is no longer used, you can reallocate
the resources reserved for classifier and counter resources back to 0 and use
them for another feature.
Note that 0 is the default value for classifier and counter resources.
Step Action
1 Remove the ports with virtual switch L2 enhanced transform configuration

from their associated virtual switch.
virtual-switch ethernet delete port <PortNameList> vlan
<VlanList>
where
<VlanList> is the virtual switch.
2 Set the virtual switch L2 transform mode to the default for all ports.
port set port 1-12 vs-l2-transform i-push,e-pop
vs-enhanced-l2-transform count 0
vs-enhanced-l2-transform count 0
configuration save
chassis reboot
end

Procedure 5-19
Configuring transport OAM resources
Configure transport OAM resources as required for use with OAM features
such as CFM over MPLS, CFM over PBB-TE, VCCV, LSP BFD, AIS/LDI, and
VS-based remote management.
Transport OAM resources are only applicable to the 3916, 3930, 3931, 3932,
3960, 5142, 5150, and 5160 platforms.
On the 3916, 3930, 3931, and 3932 platforms, transport OAM does not have
any assigned resources by default. To use this feature, you need to assign
available classifier and counter resources to it.
transport OAM are shown in Table 5-12.
Table 5-12
Transport OAM default and maximum resource reservations per platform
3940, 5140 Classifiers Not applicable Not applicable
3916, 3930, 3931, 3932 Classifiers 0 256
Meters 0 0
Counters 0 256
3960, 5142, 5150, 5160 Classifiers 512 512
Meters 0 0
Counters 512 512
Step Action
1 Set the pool count for classifier resources.

transport-oam count <NUMBER>
where
count <NUMBER> is the number of resources to assign.

2 Set the pool count for counter resources.

transport-oam count <CounterResources>
where
<CounterResources> is the pool count for counter resources for the platform.

configuration save
chassis reboot
end

Procedure 5-20
Freeing all transport OAM resources
If transport OAM is no longer used, you can reallocate the resources reserved
for classifier and counter resources back to 0 and use them for another
feature.
Note that 0 is the default value for classifier and counter resources on the
3916, 3930, 3931, 3932 platforms. The default value for classifier, meter, and
counter resources on the 3960, 5142, 5150, and 5160 platforms is 512.
Step Action

transport-oam count 0
transport-oam count 0
configuration save
chassis reboot
end

Procedure 5-21
Displaying resource configuration information
The system software provides a way to display the active configuration (what
is currently running) and the candidate configuration (what it will be upon
successful configuration save and reboot).You can also display detailed
resource information for the CFM feature on 3940 and 5140 platforms and for
the traffic profiling feature on all platforms.
Step Action
1 Determine the resource configuration information that you want to display.

If you want to display Then
active and candidate Perform step 2.
information
active configuration only Perform step 3.
candidate configuration only Perform step 4.
detailed resource Perform step 5.
information for the CFM
feature on the 3940 and
5140 platforms
detailed resource Perform step 6.
information for the traffic
profiling feature
2 Display both active and candidate configuration:

resource-manager show
3 Display active configuration only:

resource-manager show active
4 Display candidate configuration only:

resource-manager show candidate
5 Display detailed resource information for the CFM feature on the 3940 and
5140 platforms:
resource-manager show feature cfm
6 Display detailed resource information for the traffic profiling feature:

resource-manager show feature traffic-profiling
end

Procedure 5-22
Resolving resource configuration validation errors
This section provides examples of some common validation error messages
and the method to resolve them.
Example - ERROR: <feature>: classifier, meter, and counter pool counts must
match:
ERROR: traffic-profiling: classifier, meter, and counter pool counts must match
ERROR: : classifier pools=14 meter pools=13 counter pools=14
ERROR: Resource validation failed: Resource allocation invalid
Step Action
1 Display the candidate configuration.

resource-manager show candidate
+--------------------------+------------+------------+------------+------------+----------+
| CANDIDATE RESOURCE CONFIGURATION |
+--------------------------+------------+------------+------------+------------+----------+
| feature | resource | reserved | used | increment |pltfm max |
+--------------------------+------------+------------+------------+------------+----------+
...
2 Scroll to the section for the feature listed in the error message to find the
candidate configuration for the resource type.
...
| traffic-profiling | classifier | 1792 | 20 | 128 | 1792 |
| | meter | 512 | 0 | 128 | 1792 |
| | counter | 1792 | 0 | 128 | 1792 |
...
3 Set the pool count for the resource types to match.

Note: On the 3916, 3930, 3931, 3960 and 5150 platforms, in order for the
pool counts to match, the reserved meter resources must be twice that of
the reserved classifier resources. Also, the classifier and counter reserved
resources must be equal.

4 Re-validate the configuration.
configuration save
chassis reboot
end

Procedure 5-23
Addressing classifier resource allocation too small
for current configuration error
If there are not enough resources to support the configuration of a feature, the
following error is displayed when the resource-manager validate command is
executed:
ERROR: Resource validation failed: Resource allocation invalid
This error condition is addressed by performing one of the following:

increasing the pool count so that the number of resources matches the
active configuration
modifying the configuration of the feature
Step Action
To increase the pool count so that the number of resources matches the active configuration
1 Set the pool count for classifier, meter, and counter resources to the match
the active value shown in the error message.
vc-statistics count <ActiveValue>
where
<ActiveValue> is the active value displayed in the error message

configuration save
chassis reboot
To modify the configuration of the feature
1 Display the configuration of the feature. In this case, check for virtual circuits
with statistics collection turned on.
virtual-circuit show

+------ ETHERNET VIRTUAL CIRCUIT TABLE -----+

| Name | VLAN | Stats |
+-----------------+-------------------------+
| 101 | 101 | On |
+-----------------+-------------------------+
2 Modify the configuration of the feature.
virtual-circuit ethernet set vc 101 statistics off
configuration save
chassis reboot
end
Example
The following example shows sample output for the resource-manager
validate command for a configuration where there are not enough resources
to support the configuration of the virtual circuit statistics feature.
ERROR: vc-statistics: classifier resource allocation too
small for current configuration
ERROR: : candidate=0 active=128 used=2
ERROR: vc-statistics: counter resource allocation too small
for current configuration
ERROR: : candidate=0 active=128 used=2
ERROR: Resource validation failed: Resource allocation
invalid

Procedure 5-24
Displaying resource configuration in the
configuration file
Once resource validation passes and the configuration file is saved, resource
configuration is saved in the RESOURCE CONFIG section in the
configuration file.
Step Action
1 View resource configuration in the configuration file:

configuration show
end
Example
The following example shows sample output from the configuration show
command.
configuration show
! CN 3911 Configuration File

! Chassis MAC: 00:02:a1:22:bd:40
! Created: Thu Oct 22 21:38:31 2009
! Created by: CLI
! SW Package: Slot 1 - saos-06-06-00-0103
! Build Number: 4708
! MIB Number: 02-03-11-0027
!
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! RESOURCE CONFIG
!
resource-manager pool set feature traffic-profiling resource classifier count 1792
resource-manager pool set feature traffic-profiling resource meter count 1792
resource-manager pool set feature traffic-profiling resource counter count 1792
resource-manager pool set feature broadcast-containment resource classifier count 0
resource-manager pool set feature broadcast-containment resource meter count 0
resource-manager pool set feature broadcast-containment resource counter count 0
resource-manager pool set feature cfm resource classifier count 0
resource-manager pool set feature cfm resource meter count 0
resource-manager pool set feature cfm resource counter count 0
resource-manager pool set feature vc-statistics resource classifier count 0
resource-manager pool set feature vc-statistics resource meter count 0
resource-manager pool set feature vc-statistics resource counter count 0
resource-manager pool set feature dhcp-relay resource classifier count 0
resource-manager pool set feature dhcp-relay resource meter count 0
resource-manager pool set feature dhcp-relay resource counter count 0
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[more 9%] (q,g,space,enter)


6-1
System timing configuration 6-
System timing is the recovery and distribution of frequency, phase and time-
of-day information to maintain synchronization between network elements.
System timing is performed by means of:

Synchronous Ethernet
External timing interfaces, which are
BITS
GPS
TDM line timing
IEEE 1588 version 2 Precision Time Protocol
Note: To configure Synchronous Ethernet (SyncE), external timing

interfaces or TDM line timing, you need to install the Advanced Ethernet
license key. To configure IEEE 1588 v2 Precision Time Protocol, you need
to install the Advanced Synchronization license key. To obtain the
Advanced Ethernet license key or the Advanced Synchronization license
key, contact Ciena Sales.
System timing is supported on the following platforms:

3930 Sync
3930 Sync + External Timing
3931 Sync
3932
5142
5150 Packet Timing
5160
Note: The 3930 Sync, 3931 Sync, and 5150 platforms do not support
external timing interfaces. The optional 10G module with BITS interface is
required for BITS support on 5150.

6-2 System timing configuration
System timing recovers timing from external sources, that is, timing inputs,
and distributes timing to external destinations, that is, timing outputs, where
timing could comprise of frequency, phase and time-of-day.
A system can have multiple timing inputs: each timing input can have different
characteristics that give it preference over other timing inputs. Different types
of timing inputs can provide different components of frequency, phase and
time-of-day to which the local clock is synchronized. In turn, the frequency,
phase and time-of-day of the local clock can be distributed to other network
elements through different types of timing outputs.
Table 6-1 summarizes system timing inputs and outputs.
Table 6-1
System timing inputs and outputs
Frequency Phase Time of Day
Inputs SyncE on any Ethernet IEEE 1588v2 on any IEEE 1588v2 on any
port Ethernet port Ethernet port
IEEE 1588v2 on any 1 PPS interface 1 PPS interface
Ethernet port SYNC interface SYNC interface
SYNC interface (BITS) NTP
10MHz interface Set time
TDM port (3932 PWE)
Local oscillator
Outputs SyncE on any Ethernet 1 PPS interface IEEE 1588v2 on any

port SYNC interface Ethernet port
IEEE 1588v2 on any 1 PPS interface
Ethernet port SYNC interface
SYNC interface (BITS)
10 MHz interface
Synchronous Ethernet
SyncE support provides a migration path from existing frequency
synchronization distribution architectures based on SONET/SDH or GPS to a
next generation packet network-based frequency synchronization architecture
based on Carrier Ethernet with SyncE.
SyncE assures that frequency is distributed at the physical layer where it is not
subject to load impairments such as packet congestion and loss.

There can be a number of Ethernet switches involved in the distribution of the

reference timing signal. In such cases, the synchronization function within
these Ethernet switches must be able to recover synchronization line timing
from the incoming bit stream and propagate synchronization line timing to
outgoing Ethernet ports.
Figure 6-1 shows a reference timing signal, traceable to a Primary Reference

Clock (PRC), which is injected into the Ethernet switch using an external clock
port. This signal is extracted and processed by means of a synchronization
function before injecting timing onto the Ethernet bit stream leaving the
Ethernet switch. The clock supporting synchronous Ethernet networks is
called the Ethernet Equipment Clock (EEC).
Figure 6-1
Example of a synchronization network over synchronous Ethernet
Synchronization Status Messaging (SSM) is used to convey priority and clock

traceability. SSM messages indicate the quality level of the system clocks
located in the various network elements. Quality level is the holdover
performance of a clock.
SyncE port status is signaled by means of the Link Layer Discovery Protocol
(LLDP). For more information, refer to Link Layer Discovery Protocol (LLDP)
configuration on page 7-1.

IEEE 1588 version 2 Precision Time Protocol

IEEE 1588v2 Precision Time Protocol (PTP) synchronizes real-time clocks
over a network with sub-microsecond accuracy, very low network bandwidth,
and minimal CPU usage. PTP supports synchronization over various types of
network encapsulations, for example, UDP/IP and Ethernet. PTP supports
multicast and unicast messaging.
Clocks are organized in a hierarchy: master clocks supply timing information

to slave clocks. At the top of the hierarchy is the grandmaster clock. Typically,
the grandmaster clock has a high-quality time source connected to it, for
example, a GPS receiver or atomic clock.
39XX/51XX platforms can function as an ordinary clock (OC) slave as well as

boundary clock (BC). On an OC, a single port participates in the clock
hierarchy as a slave or master clock. On a BC, ports participate in the clock
hierarchy as slave and master clocks.
In BC mode, on the master side of some 39XX/51XX platforms (currently 5142

and 5160 only), one-step timestamping is supported. One-step timestamping
means that the outgoing PTP sync messages are timestamped by the
hardware as the packet is being transmitted onto the wire. For two-step
timestaming, the sync packet contains an estimate that is typically generated
in the software.
External timing interfaces

External timing interfaces are:
BITS
GPS
The BITS interface resides in the SYNC port.
BITS
BITS is a timing signal that is used to distribute frequency synchronization in
a telecom environment, typically in a central office. It is usually carried over
T1/E1 lines. Timing is encoded within the transmitted data signal to
synchronize the whole network.
The 3930 Sync + External Timing, 3932, 5142, the optional 10G module with
BITS interface for BITS support on 5150, and 5160 platforms input and output
standard electrical specifications for a BITS frequency as follows:
2.048 Mbps E1 compliant to ITU-T G.703-9
1.544 Mbps T1 compliant to GR-499 and ITU-T G.703-5
2048 KHz

Note: The SYNC port can be configured to be either BITS-IN or BITS-

OUT. It cannot be both BITS-IN and BITS-OUT simultaneously.
GPS
The 3930 Sync + External Timing, 3932, 5142, and 5160 platforms can
synchronize to a GPS receiver by means of:
10 MHz mini-coax connector, which allows a frequency reference signal to
be used as an input or generated as an output. The frequency of the signal
can be configured as 10 MHz, 2.048 MHz, or 1.544 MHz.
1 PPS mini-coax connector, which allows a 1 PPS signal to be used as an
input or generated as an output for phase synchronization. This interface
is also capable of recovering and generating embedded ToD messages.
The 1 PPS interface is unidirectional: it can be configured either as input
or output but not both simultaneously.
SYNC port, which allows a 1 PPS signal to be used as an input or
generated as an output for phase synchronization. This interface is also
capable of recovering and generating ToD messages. The SYNC port is
unidirectional: it can be configured either as input or output but not both
simultaneously.
For more information, refer to External timing, in 39XX/51XX Service

Delivery and Aggregation Switches Product Fundamentals (009-3220-006).
Clock selection algorithm

The clock selection algorithm selects the best available synchronization
source from the nominated clock references added to a protection-group.
When configured as an Option 1 (E1) clock it operates in revertive mode by
default. When configured as an Option 2 (T1) clock it operates in non-revertive
mode by default.
In revertive mode, the best reference is selected after a wait-to-restore period

has elapsed when a better reference is introduced. The wait-to-restore timer
only applies to revertive-mode.
In non-revertive mode, once a reference has been selected, the clock

selection algorithm does not select a new reference even if the new reference
is better. A new reference is selected only when the currently-selected
reference fails.
The clock selection algorithm uses the following criteria to select the clock
source from a set of configured clock references:
operator commands, that is, force switch and clear
loss-of-service, loss-of-frame, alarm indication signal, hardware not set
up, or clock out-of-frame

optional provisioned clock reference override-priority

optional provisioned clock reference forced quality level, which overrides
received quality level
received quality level (SSM/clockclass)
optional provisioned clock reference priority
The events that could trigger the algorithm are:

CLI commands:
add references to or remove references from a protection-group
Input reference override-priority, priority, forced-ql, or ql-receive
configuration changes
forced reference configuration changes
threshold-ql configuration changes
reversion-mode configuration changes
Physical characteristics:
received quality level value changes or timeout
loss-of-service, loss-of-frame, alarm indication signal, hardware not
set up, or clock out-of-frame by means of QL-FAILED changes
When no priority is configured among the references, for a tie-breaker case,
for example, no override-priorities/priorities are configured and all references
have the same quality level, the following order of protocol preference is used
to determine the preferred reference:
GPS
BITS
SyncE
PTP
TDM
In the case of a tie between references of the same protocol, the interface
identifier breaks the tie, for example, for SyncE port 1 is preferred over port 10
(the lower port is preferred) and for PTP master-ip-address 1.1.1.1 is preferred
over 2.2.2.2 (the lower address is preferred).
The clock selection algorithm applies to three separate protections groups:

frequency
phase
time-of-day

Quality level value definition

In SyncE, quality level is encoded in SSMs and is used to determine the
validity of the signal. If the received quality level of a clock source is below the
user-configured minimum quality level threshold, the clock source is deemed
invalid and does not participate in the clock selection algorithm. However, you
can configure a forced-ql attribute that can override the received quality level.
The BITS interface carries an SSM value defined by ITU-T G.781. Depending
on the configuration of the BITS interface type, that is, T1 or E1, the value of
SSM and the acceptable received quality levels for Sync-E and BITS are
defined in Table 6-2 through Table 6-5. All other received SSM values are
considered invalid on input.
For PTP, quality level is extracted from clockclass. For more information, refer
to Table 6-2 to Table 6-5. To be selectable, references that do not carry a
quality level must be configured with a forced-ql to meet clock selection
algorithm criteria.
Different types of inputs can have different scales, for example, SSM/
clockclass, to measure quality level. These quality levels are mapped to a
common scale with a preference score, where a lower number determines
higher preference, based on which an input is preferred over another. It is
important to note that there are separate quality level mappings for input and
output. Once all inputs are mapped to the common scale and the best input is
selected using clock selection algorithm criteria, the preference score of the
selected reference is then mapped back to SSM/clockclass on output
depending on the protocol of the output references.
Table 6-2 shows the input quality level mapping for Option I.
Table 6-2
Option I input quality level mapping
From BITS E1 From SyncE SSM From PTP QL name From QL

SSM clockclass preference
(G.8265.1)
80 1
82 2
0x2 0x2 84 QL-PRC 3
86 4
88 5
0x4 0x4 90 QL-SSU-A 6
92 7

Table 6-2
Option I input quality level mapping
From BITS E1 From SyncE SSM From PTP QL name From QL

SSM clockclass preference
(G.8265.1)
94 8
0x8 0x8 96 QL-SSU-B 9
98 10
100 11
102 12
0xB 0xB 104 QL-SEC/EEC1 13
106 14
108 15
0xF or QL-INVx 0xF or QL-INVx 110 QL-DNU 16
Table 6-3 shows the output quality level mapping for Option I.
Table 6-3
Option I output quality level mapping
From QL QL name To BITS T1 SSM To SyncE SSM To PTP

preference clockclass
(G.8265.1)
1 QL-PRC 0x2 0x2 80
2 82
3 84
4 QL-SSU-A 0x4 0x4 86
5 88
6 90
7 QL-SSU-B 0x8 0x8 92
8 94
9 96
10 98
11 100

Table 6-3
Option I output quality level mapping

(G.8265.1)
12 QL-SEC/EEC1 0xB 0xB 102
13 104
14 106
15 QL-DNU 0xF 0xF 108
16 110
Table 6-4 shows the input quality level mapping for Option II.
Table 6-4
Option II input quality level mapping
From BITS E1 From SyncE SSM From PTP QL name To QL preference

SSM clockclass
(G.8265.1)
0x04FF 0x1 80 QL-PRS 1
0x08FF 0x0 82 QL-STU 2
84 3
0x0CFF 0x7 86 QL-ST2 4
88 5
0x78FF 0x4 90 QL-TNC 6
92 7
94 8
96 9
98 10
0x7CFF 0xD 100 QL-ST3E 11
0x10FF 0xA 102 QL-ST3/EEC2 12
104 13

Table 6-4
Option II input quality level mapping
From BITS E1 From SyncE SSM From PTP QL name To QL preference

SSM clockclass
(G.8265.1)
0x22FF 0xC 106 QL-SMC 14
0x40FF 0xE 108 QL-PROV 15
0x30FF or QL- 0xF or QL-INVx 110 QL-DUS 16

INVx
Table 6-5 shows the output quality level mapping for Option II.
Table 6-5
Option II output quality level mapping

(G.8265.1)
1 QL-PRS 0x04FF 0x1 80
2 QL-STU 0x08FF 0x0 82
3 QL-PRS 0x04FF 0x1 84
4 QL-ST2 0x0CFF 0x7 86
5 QL-TNC 0x78FF 0x4 88
6 90
7 QL-ST3E 0x7CFF 0xD 92
8 94
9 96
10 98
11 100
12 QL-ST3/EEC2 0x10FF 0xA 102
13 QL-SMC 0x22FF 0xC 104
14 106
15 QL-PROV 0x40FF 0xE 108
16 QL-DUS 0xF 0xF 110

Frequency, phase and time-of-day configuration rules

In synchronization, frequency, phase and time-of-day are dependent upon
each other. Time-of-day reference depends on phase reference. Phase
reference depends on frequency reference. To prevent unwanted
configurations, the following rules must be followed:
1 References cannot be added to the time-of-day protection-group if the

phase protection-group is empty.
2 References cannot be added to the phase protection-group if the
frequency protection-group is empty
3 References can be added at any time to the frequency protection-group.
4 References can be removed at any time from the time-of-day protection-
group.
5 The last reference can only be removed from the phase protection-group
if the time-of-day protection-group is empty.
6 The last reference can only be removed from the frequency protection-
group if the phase protection-group is empty.
The time-of day protection-group depends on the phase protection-group. The
phase protection-group depends on the frequency protection-group. The
following table shows the four valid combinations at any time. Anything else
will be blocked by the CLI.
Table 6-6
Configuration rules
Frequency Phase Time-of-day Description
1 X Frequency references are added while time-of-day

and phase protection-groups are empty.
2 X X Phase references are added while the time-of-day

protection-group is empty and the frequency
protection-group is not empty.
3 X X X Time-of-day references are added while frequency

and phase protection-groups are not empty.
4 All protection-groups are empty.
Note: The selected phase reference should be traceable to the same

primary reference clock as the selected frequency reference. The selected
time-of-day reference should also be traceable to the same primary
reference clock as the selected phase reference. If the currently selected
frequency reference goes down, but is still added to the frequency
protection-group, the phase and time-of-day protection-groups will
disregard the selection and go into freerun/holdover. Similarly, when the

currently selected phase reference goes down, but is still added to the
phase protection-group, the time-of-day protection-group disregards the
selection and goes into freerun/holdover.
Holdover interval
The holdover interval gives you the option of selecting how you want to control
the protection-group operational quality level during holdover. This is
configured using the sync set holdover-interval <indefinite|24
hrs> command. The holdover and free-run quality levels are now the
oscillator quality level of the device. Use this command to have the protection-
group operational quality level transition to DNU/DUS (do not use) after 24
hours of being in holdover. To be consistent with G.781, the default holdover
interval is indefinite.
PTP clock type

The PTP clock type can be configured as ordinary clock slave or boundary
clock. You can set the PTP clock type from ordinary clock slave to boundary
clock or vice versa.
When the PTP clock-type is set from ordinary clock slave to boundary clock,
the CLI prints a message informing you to remove all GPS references that
were added to the protection-groups. When the PTP clock-type is set to
boundary clock, you can then create PTP output references, and you cannot
add any GPS references to protection-groups.
PTP outputs can only be derived from non-GPS inputs when PTP clock type
is set to boundary clock. In boundary clock mode, GPS input references are
disregarded for selection. Only non-GPS inputs qualify for selection while
timing distribution can occur via both GPS and non-GPS outputs.
If you set PTP clock-type from boundary clock to ordinary clock slave, the CLI
prints a message informing you to delete all PTP output references. When the
PTP clock is set to ordinary clock slave, you are not able to create PTP output
references, and you can add any GPS references to protection-groups.
Reversion-mode configuration is ignored while switching the PTP clock-type.

Network configuration examples

Figure 6-2 shows a linear topology example for system timing. In this example,
input references are configured on the ports with arrows. The input references
lock to the BITS signal and distribute the timing to the SyncE portion of the
network.
Figure 6-2
Linear topology

Figure 6-3 shows a ring topology example for system timing. In this example,
ports can be configured for input or output. BITS feeds timing to the network.
Note that the timing signal does not flow all the way around the ring. SyncE
alone cannot detect or prevent timing loops. Timing loops can only be
prevented with careful network planning, that is, proper configuration of
preferred inputs and the way the nodes are interconnected. Having a break in
the flow avoids timing loops.
Figure 6-3
Ring topology

Figure 6-4 shows an example of system timing using SyncE and PTP. In this
example, SyncE is used to recover frequency and PTP is used to recover
phase.
Figure 6-4
System timing using SyncE and PTP
Sample configuration: system timing by means of SyncE and PTP on page

6-83 provides the commands to configure this example.

Figure 6-5 shows an example of recovering PTP timing on an Ordinary Clock

Slave from a GrandMaster Clock via a Boundary Clock (priority 1) while
keeping the GrandMaster Clock as a backup timing reference (priority 2).
Figure 6-5
System timing using PTP timing
GrandMaster
e.g. Symmetricom TP 5000
2.2.2.1
VLAN 200
1
BoundaryClock
e.g. 5160
2.2.2.10
2
VLAN 200
3 OCSlave
e.g. 3930
2.2.2.20
Sample configuration: system timing by means of PTP Boundary Clock on

page 6-85 provides the commands to configure this example.

Procedures
Figure 6-6 shows the flow of system timing procedures.
Figure 6-6
System timing configuration
System timing
configuration
Initial configuration
Configure global attributes
Configure input references
Configure output references
Configure protection-groups
Display system timing information
End
Procedures for initial configuration are:

Enabling and disabling synchronization on page 6-19
Configuring synchronization on page 6-20
Procedures for configuring the global attributes for GPS output timing
Configuring the PTP timing global attributes on page 6-23
Configuring global attributes for PTP input timing on page 6-25
Configuring global attributes for PTP output timing on page 6-26
Configuring global attributes for GPS output timing on page 6-27

Procedure for configuring input references are:

Configuring SyncE input references on page 6-28
Configuring BITS input references on page 6-30
Configuring PTP input references on page 6-33
Configuring GPS input references on page 6-35
Configuring TDM input references on page 6-37
Procedures for configuring output references are:

Configuring SyncE output references on page 6-39
Configuring BITS output reference on page 6-40
Configuring PTP output timing references on page 6-42
Configuring GPS output references on page 6-43
Procedure for configuring protection-groups are:

Configuring protection-groups on page 6-44
Procedures for displaying system timing information are:
Displaying information for synchronization on page 6-53
Displaying SyncE information on page 6-57
Displaying BITS information on page 6-60
Displaying PTP information on page 6-63
Displaying GPS information on page 6-69
Displaying TDM information on page 6-72
Displaying frequency information on page 6-74
Displaying phase information on page 6-76
Displaying time-of-day information on page 6-78
Displaying protection-group information on page 6-80
For information about commands used to unset system timing configurations,

refer to 39XX/51XX Service Delivery and Aggregation Switches Command
Reference (009-3220-010).

Procedure 6-1
Enabling and disabling synchronization
You can enable and disable synchronization. Synchronization is enabled by
default.
Disabling synchronization results in the following:
the clock selection algorithm is frozen, that is, the system no longer
responds to events that trigger the clock selection algorithm
output references are shut down so that downstream nodes no longer
receive synchronization. Prior to shutting down the output references, the
output references that are capable of transmitting quality level transmit
QL-DNU/QL-DUS (do-not-use) messages to notify downstream nodes to
gracefully switch over to another reference.
Disable the synchronization feature for maintenance purposes.
Step Action
To enable synchronization
1 Enable synchronization:
sync enable
To disable synchronization
2 Disable synchronization:
sync disable
end

Procedure 6-2
Configuring synchronization
You can configure
hold-over interval period, which can be configured to be 24-hrs or
indefinite.
option type, which is a one-time mandatory configuration before all other
sync inputs, outputs, or protection-groups can be configured
reversion mode, which affects the behavior of clock selection algorithm
global wait-to-restore timer, which is related to reversion mode. The wait
to restore timer applies when the reversion mode is set to revertive.
Step Action
To set the holdover interval

1 Set the holdover interval:
sync set holdover-interval <indefinite | 24-hrs>
where
holdover-interval is the holdover interval. The default value is indefinite.
<indefinite | 24- If configured to be 24-hrs, the operational QL of the
hrs> protection-group will change from local oscillator QL to QL-
DUS/QL-DNU after being in holdover for 24 hours.
If the hold-over interval is configured to be indefinite, the
operational QL of the protection-group will not change
during holdover.

To set the option type

2 Set the option type:
sync set option-type <option1|option2|none>
where
option-type is the option type. The default value is none.
<option1| option1 applies to SDH networks optimized for the 2048
option2|none> kbit/s hierarchy
option2 applies to SDH networks optimized for the 1544
kbit/s hierarchy that includes the rates 1544 kbit/s, 6312
kbit/s and 44736 kbit/s
Note 1: When option-type is set to option1, reversion-mode
defaults to revertive. When option-type is set to option2,
reversion-mode defaults to non-revertive. You can explicitly
configure reversion-mode.
Note 2: Selection of the type determines the quality level
definition. For option1 quality level definitions, refer to Table
6-2 for Option I input quality level mapping and Table 6-3
for Option I output quality level mapping. For option2
quality level definitions, refer to Table 6-4 for Option II input
quality level mapping and Table 6-5 for Option II output
quality level mapping.
To change the option-type, ensure there are no existing
configurations.
To set the reversion-mode

3 Set the global reversion-mode:
sync set reversion-mode <non-revertive|revertive>
where
reversion-mode is the global reversion mode.
<non-revertive|
revertive>
To set the global wait-to-restore timer

4 Set the global wait-to-restore timer:
sync set wait-to-restore <MINUTES: 0-12>
where
wait-to-restore is the time assigned to the wait-to-restore timer. The wait-to-
<MINUTES: restore timer is used when the reversion mode is set to
0-12> revertive.
end
Example
The following example sets the holdover-interval to 24-hrs.

sync set holdover-interval 24-hrs
The following example sets the option type to option 1, for an SDH network
optimized for the 2048 kbit/s hierarchy. Note that the reversion mode defaults
to revertive.
sync set option-type option1
The following example sets the global reversion mode to non-revertive.
sync set reversion-mode non-revertive

Procedure 6-3
Configuring the PTP timing global attributes
You can configure the following PTP timing attributes:
address mode
domain number
profile identifier
profile version
tag priority
clock type
dscp value
Step Action
1 Globally set PTP timing attributes for the network element:

sync ptp set {address-mode <unicast>} {domain-number
<NUMBER: 4-23>} {profile-identifier <00-19-A7-00-01-00>}
{profile-version <1.0>} {protocol-version <2>} {tag-
priority <NUMBER: 0-7>} clock-type <oc-slave|bc> dscp
<0...63>
where
address-mode is the PTP address mode. The default value is unicast.
<unicast>
domain-number is the PTP domain number.
<NUMBER: 4-
23>
profile-identifier is the profile identifier for the network element.
<00-19-A7-00-
01-00>
profile-version is the profile version supported by the network element.
<1.0>
protocol-version is the PTP version supported by the network element.
<2>
tag-priority is the VLAN p-bits for outgoing PTP packets. The default
<NUMBER: 0..7> value is 0.
clock-type is the PTP clock type. The default is oc-slave.
dscp <0..63> sets the dscp value for PTP traffic.
end

Example
The following example sets global PTP timing attributes for the network
element.
sync ptp set address-mode unicast domain number 4 profile-

identifier 00-10-A7-00-01-00 profile-version 1.0
protocol-version 2 tag-priority 0 clock-type bc dscp 56

Procedure 6-4
Configuring global attributes for PTP input timing
Configure global attributes for PTP input timing.
Step Action
1 Set global attributes for PTP input timing:

sync ptp input set {announce-rx-loss-num <NUMBER: 2..10>}
{announce-tx-rate-request <1|1-2nd|1-4th|1-8th>} {delay-
request-tx-rate <64|32|16|8|4|2|1|1-2nd>} {sync-tx-rate-
request <64|32|16|8|4|2|1|1-2nd>} {unicast-request-
duration <SECONDS: 60-1000>}
where
announce-rx- is the PTP input announce receive loss number (announce
loss-num intervals). The default value is 3.
<NUMBER:
2..10>
announce-tx- is the PTP input announce transmit rate request, in packets
rate-request <1|- per second. The default value is 1-2nd.
2nd|1-4th|1-8th>
delay-request-tx- is the PTP input delay request transmit rate, in packets per
rate second. The default value is 64.
<64|32|16|8|4|2|1
|1-2nd>
sync-tx-rate- is the PTP input sync transmit rate request, in packets per
request second. The default value is 64.
<64|32|16|8|4|2|1
|1-2nd>
unicast-request- is the PTP input unicast request duration, in seconds. The
duration default value is 300.
<SECONDS: 60-
1000>
end
Example
The following example sets global attributes.
sync ptp input set unicast-request-duration 300 announce-

rx-loss-num 3 announce-tx-rate-request 1-2nd sync-tx-
rate-request 64 delay-request-tx-rate 64

Procedure 6-5
Configuring global attributes for PTP output timing
The maximum number of clients (slave sessions) is configurable from 0 to 16.
The default value is 16. Each platform has its limitation as shown in Table 6-7:
Table 6-7
Platform Recommended Max-Slave-

Sessions
3930 Sync 10
3930 Sync + External Timing 10
3931 Sync 5
3932 10
5142 16
5150 Packet Timing 10
5160 16
Configure global attributes for PTP output timing based on the platforms
recommended max-slave-session values.
Step Action
1 Set global attributes for PTP output timing:

sync ptp output set {max-slave-sessions <NUMBER 0..16>}
{timestamp-mode <one-step|two-step>}
where
max-slave- is the maximum number of slave sessions
sessions
<NUMBER 0-16>
timestamp-mode sets the timestamp mode to be either one-step or two-step
<one-step|two- Note: One-step timestamping is supported on the 5142 and
step>
5160 only.
Example
The following example sets global attributes for PTP output timing.
sync ptp output set max-slave sessions 15 timestamp-mode

one-step

Procedure 6-6
Configuring global attributes for GPS output timing
Configure global attributes for GPS output timing.
Step Action
1 Set the 1 PPS pulse width:

sync gps output set {1pps-pulse-width <MICROSECONDS>}
where
1pps-pulse-width is the GPS output 1 PPS pulse width in microseconds.
<MICROSECONDS>
Example
The following example sets 1 PPS pulse width.
sync gps output set 1 pps-pulse-width 1000

Procedure 6-7
Configuring SyncE input references
Configure SyncE input references to recover frequency timing from Ethernet
ports.
You can:
create a SyncE input reference
set attributes for a SyncE input reference
Step Action
To create a SyncE input reference

1 Create a SyncE input reference:
sync synce input create ref <ref> {forced-ql <Clock
Quality Level>} {override-priority <NUMBER: 1-10>} {port
<Physical port list>} {priority <NUMBER: 1-10>} {ql-
receive <disable|enable>}
where
ref <ref> is the identifier for the SyncE input reference.
forced-ql sets the quality level at which the received quality level is
<INTEGER: overridden.
0-15>
override-priority is the override-priority, with 1 being the highest override
<INTEGER: 1- priority.
10>
port <phy-port- is the physical port.
name>
priority is the priority, with 1 being the highest priority.
<NUMBER: 1-
10>
ql-receive enables or disables received quality level.
disable|enable

To set attributes for a SyncE input reference

2 Set attributes for a SyncE input reference:
sync synce input set ref <ref> {forced-ql <Clock Quality
Level>} {priority <NUMBER: 1-10>} {override-priority
<NUMBER: 1-10>} {ql-receive <disable|enable>}
where
ref <ref> is the identifier for the SyncE input reference.
forced-ql sets the quality level at which the received quality level is
<INTEGER: overridden.
0-15>
<NUMBER: 1-
10>
<INTEGER: priority.
1-10>
<disable|enable>
end
Example
The following example creates a SyncE input reference named
mySyncEinput5 on port 5 with a priority of 1.
sync synce input create ref SyncE_Port5_In port 5 priority

1

Procedure 6-8
Configuring BITS input references
Configure BITS input references to recover frequency timing from the SYNC
interface.
You can:
create a BITS input reference
set attributes for a BITS input reference
Step Action
To create a BITS input reference

1 Create a BITS input reference:
sync bits input create ref <ref> {bits-interface <BITS
interface>} {bits-mode <e1|t1|2048k>} {encoding
<ami|b8zs|hdb3>} {e1-ssm-location <sa4|sa5|sa6|sa7>}
{forced-ql <Quality Level>} {format <esf|e1-crc|e1-no-
crc|sf>} {override-priority <NUMBER: 1-10>} {priority
where
ref <ref> is the BITS input reference.
bits-interface <BITS is the BITS interface.
interface>
bits-mode is the mode.
<e1|t1|2048k>
encoding is the encoding type.
<ami|b8zs|hdb3> For T1 mode, the default value is ami.
For E1 mode, the default value is hdb3.
e1-ssm-location is the location for SSM messaging. This attribute applies
<sa4|sa5|sa6|sa7> only for E1 mode.
The default value is sa4.
forced-ql <Quality is the quality level at which the received quality level is
Level> overridden.
format <esf |e1-crc| is the format.
e1-no-crc|sf>

where
<NUMBER: 1..10> priority.
priority <NUMBER: is the priority, with 1 being the highest priority.
1..10>
<disable|enable> For E1 mode and format e1-crc, the default value is
enable.
For T1 mode and format esf, the default value is enable.
To set attributes for a BITS input reference
2 Set attributes for a BITS input reference:
sync bits input set ref <ref> {encoding <ami|b8zs|hdb3>}
{e1-ssm-location <sa4|sa5|sa6|sa7>} {forced-ql <Quality
Level>} {override-priority <NUMBER: 1-10>} {priority
where
forced-ql <Quality is the quality level at which the received quality level is
Level> overridden.
<NUMBER: 1..10> priority.
priority <NUMBER: is the priority, with 1 being the highest priority.
1..10>
<disable|enable> For E1 mode and format e1-crc, the default value is
enable.
For T1 mode and format t1-esf, the default value is
enable.
end

Example
The following example creates a BITS input reference named myBITSinput1
with a BITS interface of sync-rj-45-1 and a mode of T1.
sync bits input create ref myBITSinput1 bits-interface

sync-rj45-1 bits-mode t1 format esf

Procedure 6-9
Configuring PTP input references
Configure PTP input references to synchronize timing, that is, frequency,
phase, and time-of-day, from a grandmaster or boundary clock over a packet
network.
You can
create a PTP input timing reference
set attributes for a PTP input timing reference
Step Action
To create a PTP input timing reference

1 Create a PTP input timing reference:
sync ptp input create ref <ref> {encap-type <udp-over-
ip>}{forced-ql <Clock Quality level>} {ip-interface
<Interface Name>} {master-ip-address <IP address>}
{override-priority <NUMBER: 1..10>} {priority <NUMBER:
1..10>} {forced-clock-class <NUMBER: 80..110>} {ql-
receive <disable | enable>}
where
ref <ref> is the PTP input timing reference.
encap-type <udp- is the encapsulation type.
over-ip>
forced-ql <Clock is the forced quality level.
Quality level>
ip-interface is the IP interface name.
<Interface
Name>
master-ip- is the master IP address.
address <IP
address>
override-priority is the override priority, with 1 being the highest override
<NUMBER: priority.
1..10>

where
<NUMBER:
1..10>
forced-clock- is the forced clock class from 80-110.
class
ql-receive is the quality level receiving configuration.
<disable |
enable>
To set attributes for a PTP input timing reference
2 Set attributes for a PTP input timing reference:
sync ptp input set ref <ref> {forced-ql <Clock Quality
level>} {override-priority <NUMBER: 1-10>} {priority
<NUMBER: 1-10>} {forced-clock-class <80-110>} {ql-receive
<disable|enable>}
where
ref <ref> is the PTP input timing reference.
Quality level>
<NUMBER: 1- priority.
10>
<NUMBER: 1-
10>
forced-clock- Is the forced clock class from 80-110
class
ql-receive is the quality level receiving configuration.
<disable |
enable>
end
Example
The following example creates a PTP input timing reference named PTP_In.
sync ptp input create ref PTP_In master-ip-address 2.2.2.1

ip-interface PTP_Interface encap-type udp-over-ip
priority 2
The following example sets attributes for a PTP input timing reference named
PTP_In.
sync ptp input set ref PTP_In priority 2 forced-clock-class 80

ql-receive enable

Procedure 6-10
Configuring GPS input references
Configure GPS input references to recover timing from a GPS signal. GPS
input references can be configured by means of
10MHz coax connection (frequency only)
1PPS coax connection (phase and time-of-day)
SYNC interface (phase and time-of-day)
You can
create a GPS input reference
set attributes of a GPS input reference
Step Action
To create a GPS input reference

1 Create a GPS input reference:
sync gps input create ref <ref> {clock-mode
<frequency|phase>} {forced-ql <Clock Quality Level>}
{frequency-clock <10mhz|1544khz|2048khz>} {gps-interface
<GPS interface>} {override-priority <NUMBER: 1-10>}
{priority <NUMBER: 1-10>} frequency-clock <10mhz|2048
khz|1544khz>
where
ref <ref> is the GPS timing interface.
clock-mode is the GPS clock mode.
<frequency|
phase>
Quality level>
frequency-clock is the GPS frequency clock.
<10mhz|
1544khz|
2048khz>

where
gps-interface is the GPS interface.
<GPS interface>
10>
<NUMBER: 1-
10>
To set attributes of a GPS input reference
2 Set attributes of a GPS input reference:
sync gps input set ref <ref-name> {forced-ql <Clock
Quality Level>} {override-priority <NUMBER: 1-10>}
{priority <NUMBER: 1-10>}
where
ref <ref> is the GPS input timing reference.
Quality level>
{override-priority is the override priority, with 1 being the highest override
10>
<NUMBER: 1-
10>
end
Example
The following example creates a GPS input reference named
myGPS10MHzInput1.
sync gps input create ref myGPS10MHzInput1 clock-mode

frequency forced-ql prs frequency-clock 10mhz gps-
interface 10mhz-smb-1

Procedure 6-11
Configuring TDM input references
Configure TDM input references to extract line timing from TDM ports in the
PWE module.
Note: TDM references can be configured on the 3932 platform only.
You can
create a TDM input reference
set attributes of a TDM input reference
Step Action
To create a TDM input reference

1 Create a TDM input reference:
sync tdm input create ref <ref> {forced-ql <Clock Quality
Level>} {override-priority <NUMBER: 1-10>} {port <TDM
Port Name>} {priority <NUMBER: 1-10>}
where
ref <ref> is a TDM input timing reference.
Quality level>
override-priority is the override priority, with 1 being highest override priority.
<NUMBER: 1-
10>
port <TDM Port is the TDM port.
Name>
<NUMBER: 1-
10>

To set attributes of a TDM input reference

2 Set attributes of a TDM input reference:
sync tdm input set ref <ref> {forced-ql <Clock Quality
Level>} {override-priority <NUMBER: 1-10>} {priority
<NUMBER: 1-10>}
where
ref <ref> is a TDM input timing reference.
Quality level>
override-priority is the override priority, with 1 being highest override priority.
<NUMBER: 1-
10>
<NUMBER: 1-
10>
end
Example
The following example creates a TDM input reference named myTDMinput5
on port tdm05.
sync tdm input create ref myTDMinput5 forced-ql st2 port

tdm05

Procedure 6-12
Configuring SyncE output references
Configure SyncE output references to distribute frequency timing by means of
Ethernet ports.
Step Action
To create a SyncE output reference

1 Create a SyncE output reference:
sync synce output create ref <ref> port <Physical port>
where
ref <ref> is the SyncE output timing reference.
port <Physical is the physical port.
port list>
end
Example
The following example creates a SyncE output reference named
mySyncEoutput1 on port 1.
sync synce output create ref mySyncEoutput1 port 1

Procedure 6-13
Configuring BITS output reference
Configure BITS output references to distribute frequency timing by means of
the SYNC interface.
You can
create a BITS output reference
set attributes for a BITS output reference
Step Action
To create a BITS output reference

1 Create a BITS output reference:
sync bits output create ref <ref> {bits-interface <BITS
interface>} {bits-mode <e1|t1|2048k>} {encoding
<ami|b8zs|hdb3>} {e1-ssm-location <sa4|sa5|sa6|sa7>}
{format <e1-crc|e1-no-crc|esf|sf>} {t1-line-build-out
<133|266|399|533|655>}
where
ref <ref> is the BITS output reference.
bits-interface <BITS is the BITS interface.
interface>
bits-mode is the mode.
<e1|t1|2048k>
format <e1-crc|e1- is the format.
no-crc|t1-esf|t1-sf>
t1-line-build-out is the BITS line build-out.
<133|266|399|533|6 For line-build-out of 0 to 133 feet, select 133.
55>
For line-build-out of 133 to 266 feet, select 266.
The default value is 133.

To set attributes for a BITS output reference

2 Set attributes for a BITS output reference:
sync bits output set ref <ref> {encoding <ami|b8zs|hdb3>}
{t1-line-build-out <133|266|399|533|655>} {e1-ssm-
location <sa4|sa5|sa6|sa7>}
where
t1-line-build-out is the BITS line build-out.
<133|266|399|533|6 For line-build-out of 0 to 133 feet, select 133.
55>
end
Example
The following example creates a BITS output reference named E1_BITS_Out.
sync bits output create ref E1_BITS_Out bits-interface

sync-rj45-1 bits-mode e1 format e1-crc

Procedure 6-14
Configuring PTP output timing references
Configure PTP output references to distribute frequency, phase and time-of-
day information to connected PTP clients. You need to set the PTP clock-type
to bc (boundary clock) to configure PTP output references.
Step Action
To create a PTP output timing reference

1 Create a PTP output reference:
sync ptp output create ref <ref-name> ip-interface <IP
interface> encap-type <udp-over-ip>
where
<ref-name> is the PTP output reference being created.
ip-interface <IP is the IP interface.
interface>
encap-type (udp- is the encapsulation type.
over-ip>
Example
The following example creates a PTP output reference.
sync ptp output create ref PTPOut2 ip-interface

PTP_Interface encap-type udp-over-ip

Procedure 6-15
Configuring GPS output references
Configure GPS output references to distribute timing to a neighboring device
that accepts a GPS signal. GPS output references can be configured by
means of
10MHz coax connection (frequency only)
1PPS coax connection (phase and time-of-day)
SYNC interface (phase and time-of-day)
You can
create a GPS output reference
Step Action
To create a GPS output reference

1 Create a GPS output reference:
sync gps output create ref <ref> {clock-mode
<frequency|phase>} {frequency-clock
<10mhz|2048khz|1544khz>} {gps-interface <GPS interface>}
where
ref <ref> is the GPS output timing reference.
clock-mode is the GPS clock mode.
<frequency |
phase>
frequency-clock is the GPS frequency clock.
<10mhz|
1544khz|
2048khz>
gps-interface is the GPS interface.
<GPS interface>
end
Example
The following example creates a GPS output reference named
SMB_2048_Out.
sync gps output create ref SMB_2048_Out gps-interface

10mhz-smb-1 clock-mode frequency frequency-clock 2048khz

Procedure 6-16
Configuring protection-groups
Create protection-groups to initiate a clock selection algorithm session for the
type of timing, that is, frequency or phase. Only input references that are
added to a protection-group can take part in the clock selection process.
For Release 6.12, time-of-day extracted from PTP is only displayed. Full time-
of-day functionality will be supported in a future release. In Release 6.12, PTP
outputs can only be derived from non-GPS inputs when PTP clock-type is set
to boundary clock. In boundary clock mode, GPS input references are
disregarded for selection and only non-GPS inputs are qualified for selection
while timing distribution can take place via GPS and non-GPS outputs.
Table 6-8 list the maximum number of input references for each protection-
group by platform.
Table 6-8
Maximum input references for each protection-group
Platform Frequency Phase Time-of-Day
SyncE PTP BITS GPS TDM PTP GPS PTP
3930 Sync 6 2 0 0 0 2 0 2
3930 Sync + 10 2 1 1 0 2 2 2
External
Timing
3931 Sync 6 2 0 0 0 2 0 2
3932 10 2 1 1 2 2 2 2
5142 24 2 1 1 0 2 2 2
5150 SyncE 52 0 1** 0 0 0 0 0
5150 Packet 52 2 1** 0 0 2 0 2

Timing
5160 24 2 1 1 0 2 2 2
Note 1: ** requires the optional 10G module with BITS interface for BITS
support on the 5150.
Note 2: It is important to ensure that the selected time-of-day reference
is traceable to the same selected phase reference and that the selected
phase reference is traceable to the same selected frequency reference.

The color of the SYNC interface LED depends on the state of all configured
protection-groups. Table 6-9 lists protection-group states and describes the
SYNC interface LED associated with each protection-group state.
Table 6-9
Protection-group states
Protection-group states SYNC interface

LED
There are no protection-groups configured for frequency, Off

phase, and time-of-day.
One or more configured frequency, phase, or time-of-day Off

protection-groups is in Free Run state.
One or more configured frequency, phase, or time-of-day Solid yellow

protection-groups is in Holdover state, and all other configured
protection-groups are in Holdover, Acquiring Lock, or Locked
state.
One or more configured frequency, phase, and time-of-day Blinking green

protection-groups is in Acquiring Lock state, and all other
configured protection-groups are in Acquiring Lock or Locked
state.
All configured frequency, phase, and time-of-day protection- Solid green

groups are in Locked state.
You can
create a frequency protection-group
create a phase protection-group
create a time-of-day protection-group
set attributes for a frequency protection-group
set attributes for a phase protection-group
set attributes for a time-of-day protection-group
add an input reference to a frequency protection-group
add an input reference to a phase protection-group
add an input reference to a time-of-day protection-group
remove an input reference from a frequency protection-group
remove an input reference from a phase protection-group
remove an input reference from a time-of-day protection-group
clear a frequency protection-groups reference switch count
clear a phase protection-groups reference switch count

clear a time-of-day protection-groups reference switch count
Step Action
To create frequency protection-groups

1 Create a frequency protection-group:
sync frequency protection-group create group <group>
{threshold-ql <clock quality level>}
where
group <group> is the frequency protection-group.
threshold-ql is the threshold quality level.
<clock quality
level>
To create phase protection-groups

2 Create a phase protection-group:
sync phase protection-group create group <group>
where
group <group> is the phase protection-group.
<clock quality
level>
To create time-of-day protection-groups

3 Create a time-of-day protection-group:
sync time-of-day protection-group create group <group>
where
group <group> is the time-of-day protection-group.
<clock quality
level>

To set attributes for a frequency protection-group

4 Set attributes for a frequency protection-group:
sync frequency protection-group set group <group>
{forced-ref <configured frequency input timing
reference>} {threshold-ql <clock quality level>}
where
group <group> is the frequency protection-group.
forced-ref force switches to an input reference.
<configured
frequency input
timing reference>
<clock quality
level>
To set attributes for a phase protection-group

5 Set attributes for a phase protection-group:
sync phase protection-group set group <group> {forced-ref
<configured phase input timing reference>} {threshold-ql
<clock quality level>}
where
group <group> is the phase protection-group.
forced-ref force switches to an input reference.
<configured
phase input
timing reference>
<clock quality
level>

To set attributes for a time-of-day protection-group

6 Set attributes for a time-of-day protection-group:
sync time-of-day protection-group set group <group>
{forced-ref <configured time-of-day input timing
reference>} {threshold-ql <clock quality level>}
where
group <group> is the time-of-day protection-group
forced-ref force switches to an input reference
<configured time-
of-day input
timing reference>
threshold-ql is the threshold quality level
<clock quality
level>
To add an input reference to a frequency protection-group

7 Add an input reference to a frequency protection-group:
sync frequency protection-group add group <group> {input-
ref <list of configured frequency input timing
references>}
where
group <group> is the frequency protection-group
input-ref <list of is the list of input references to add to the frequency
configured protection-group
frequency input
timing
references>
To add an input reference to phase protection-group

8 Add an input reference to a phase protection-group:
sync phase protection-group add group <group> input-ref
<list of configured phase input timing references>}
where
group <group> is the phase protection-group
input-ref <list of is the list of input references to add to the phase protection-
configured phase group
input timing
references>

To add an input reference to time-of-day protection-group

9 Add an input reference to a time-of-day protection-group:
sync time-of-day protection-group add group <group>
input-ref <list of configured time-of-day input timing
references>}
where
input-ref <list of is the list of input references to add to the time-of-day
configured time- protection-group
of-day input
timing
references>
To remove an input reference from frequency protection-group

10 Remove an input reference from a protection-group:
sync frequency protection-group remove group <group>
{input-ref <list of configured frequency input timing
references>}
where
input-ref <list of is the list of input references to remove from the frequency
configured protection-group
frequency input
timing
references>
To remove an input reference from a phase protection-group

11 Remove an input reference from a protection-group:
sync phase protection-group remove group <group> {input-
ref <list of configured phase input timing references>}
where
input-ref <list of is the list of input references to remove from the phase
configured phase protection-group
input timing
references>

To remove an input reference from a time-of-day protection-group

12 Remove an input reference from a time-of-day protection-group:
sync time-of-day protection-group remove group <group>
{input-ref <list of configured time-of-day input timing
references>}
where
input-ref <list of is the list of input references to remove from the time-of-day
configured time- protection-group
of-day input
timing
references>
To clear a frequency protection-groups reference switch count

13 Clear a frequency protection-groups switch count:
sync frequency protection-group clear group <group-name>
ref-switch-count
where
To clear a phase protection-groups reference switch count

14 Clear a phase protection-groups switch count:
sync phase protection-group clear group <group-name> ref-
switch-count
where
To clear a time-of-day protection-groups reference switch count

15 Clear a time-of-day protection-groups switch count:
sync time-of-day protection-group clear group <group-
name> ref-switch-count
where
end
Example
The following example creates a frequency protection-group named
FreqProtGroup.
sync frequency protection-group create group FreqProtGroup

threshold-ql sec
The following example creates a time-of-day protection-group named

TODGroup.

sync time-of-day protection-group create group TODGroup

threshold-ql sec
The following example adds input references to the frequency protection-

group named FreqProtGroup.
sync frequency protection-group add group FreqProtGroup input-

ref PTP_In,SyncE_Port5_In
The following example adds input references to the time-of-day protection-

group named TODGroup.
sync time-of-day protection-group add group TODGroup input-ref

myPTPinput5

Procedure 6-17
Clearing timing statistics
You can clear
SyncE timing statistics
PTP master statistics
PTP client statistics
Step Action
To clear SyncE timing statistics

1 Clear SyncE timing statistics:
sync synce clear {statistics}
where
statistics clears SyncE timing statistics.
To clear PTP master statistics

2 Clear PTP master statistics:
sync ptp input clear master <clock-ID> {pdu-statistics}
where
master <clock- is the clock ID for the PTP master.
ID>
pdu-statistics clears PTP PDU statistics.
To clear PTP client statistics

3 Clear PTP client statistics:
sync ptp output clear client <clock-ID> {pdu-statistics}
where
client <clock-ID> is the clock ID for the PTP client.
pdu-statistics clears PTP PDU statistics.
end

Procedure 6-18
Displaying information for synchronization
You can display
global synchronization information
quality level hierarchy table, as defined in G.781
all configured references
Step Action
To display global synchronization information

1 Display global synchronization information:
sync show
To display the quality level hierarchy table
2 Display the quality level hierarchy table:
sync show ql-hierarchy-table
To display all configured references
3 Display all configured references:
sync show all
end
Example
The following example shows sample output for the sync show command.
sync show
+-------------------------- SYNC CONFIGURATION ---------------------------+

+-----------------------+-------------------------------------------------+
| Option Type | Option II |
| Reversion Mode | Non-Revertive (default) |
| Wait-to-restore timer | 5 minutes |
| Holdover Interval | Indefinite |
+-----------------------+-------------------------------------------------+
+--------------------- FREQUENCY OPERATIONAL STATE -----------------------+

+-----------------------+-------------------------------------------------+
| Operational Status | Locked |
| Duration | 1:01:10:10 |
| Operational QL | ST3E (last: ST2) |
| Selected Reference | myBITSinput1 |
| Timing Interface | sync-rj45-1 |
| Protocol | BITS |
| Ref Switch Count | 2 |
+-----------------------+-------------------------------------------------+

+------------------------- PHASE OPERATIONAL STATE -----------------------+

+-----------------------+-------------------------------------------------+
| Duration | 0:02:12:40 |
| Operational QL | ST3E (last: DNU) |
| Selected Reference | myPTPinput5 |
| Timing Interface | IP Interface : PTP_Interface |
| | Master IP Address: 10.10.10.1 |
| Protocol | PTP |
+-----------------------+-------------------------------------------------+
+-------------------------TIME-OF-DAY-OPERATIONAL STATE ------------------+

+-----------------------+-------------------------------------------------+
| Duration | 0:02:12:40 |
| Protocol | PTP |
+-----------------------+-------------------------------------------------+
| Time-of-day | Wed Dec 04 23:11:01 UTC 2013 |
+-----------------------+-------------------------------------------------+
The following example shows sample output for the sync show ql-hierarchy-
table command.
sync show ql-hierarchy-table
+--- HIERARCHY OF QUALITY LEVELS ---+

| Option I | Option II | Order |
+-----------+-----------+-----------+
| PRC | PRS | Highest |
| SSU-A | STU | | |
| SSU-B | ST2 | | |
| SEC/EEC1 *| TNC | | |
| DNU | ST3E *| | |
| | ST3/EEC2 | | |
| | SMC | | |
| | PROV | | |
| | DUS | Lowest |
+-----------+-----------+-----------+
* Local OCXO QL
The following example shows sample output for the sync show all command.
sync show all
+------------------------ FREQUENCY OPERATIONAL STATE -------------------------+

+-----------------------+------------------------------------------------------+
| Duration | 1:01:10:10 |
| Protocol | BITS |
+-----------------------+------------------------------------------------------+

+---------------------------------- FREQUENCY INPUT REFERENCES ----------------------------------+

|Prot | | Timing | |Over|Oper | | |
|Group| Reference Name | Interface |Proto|Prio| QL |Prio| Operational Status |
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
| F-- |myBITSinput1 |sync-rj45-1 |BITS | 1 |ST3E | - |Active |
| FPT |myPTPinput5 |PTP_Interface |PTP | - |ST3E | 3 |Active |
| F-- |mySyncEinput5 |port 5 |SyncE| - |ST2 | 1 |Active |
| --- |myGPS10MHzInput1 |10mhz-smb-1 |GPS | - |PRS | - |Active |
| --- |mySyncEinput8 |port 8 |SyncE| - | - | 4 |Not Authenticated |
| --- |myTDMinput5 |port tdm05 |TDM | - | - | - |Loss of Signal |
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
+-------------------------- FREQUENCY OUTPUT REFERENCES -------------------------+

| | Timing | |Oper | |
| Reference Name | Interface |Proto| QL | Operational Status |
+-------------------------------+---------------+-----+-----+--------------------+
|myGPS10MHzOutput2 |10mhz-smb-1 |GPS | - |Active |
|myBITSoutput2 |sync-rj45-1 |BITS |ST3E |Active |
|myPTPoutput9 |PTP_Interfac...|PTP |ST3E |Active |
|mySyncEoutput1 |port 1 |SyncE| - |Loss of Signal |
+-------------------------------+---------------+-----+-----+--------------------+
+--------------------------- PHASE OPERATIONAL STATE --------------------------+

+-----------------------+------------------------------------------------------+
| Duration | 0:02:12:40 |
| | Master IP Address : 10.10.10.1 |
| Protocol | PTP |
+-----------------------+------------------------------------------------------+
+------------------------------------- PHASE INPUT REFERENCES -----------------------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
+---------------------------- PHASE OUTPUT REFERENCES ---------------------------+

+-------------------------------+---------------+-----+-----+--------------------+
+-------------------------------+---------------+-----+-----+--------------------+
+------------------------ TIME-OF-DAY OPERATIONAL STATE -----------------------+

+-----------------------+------------------------------------------------------+
| Duration | 0:02:12:40 |
| Protocol | PTP |
+-----------------------+------------------------------------------------------+
+-----------------------+------------------------------------------------------+

+---------------------------------- TIME-OF-DAY INPUT REFERENCES --------------------------------+

+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
+------------------------- TIME-OF-DAY OUTPUT REFERENCES ------------------------+

+-------------------------------+---------------+-----+-----+--------------------+
+-------------------------------+---------------+-----+-----+--------------------+

Procedure 6-19
Displaying SyncE information
You can display:
summary information for SyncE
statistics information for SyncE
information for SyncE input references
detailed information for a SyncE input reference
information for SyncE output references
detailed information for a SyncE output reference
Step Action
To display summary information for SyncE

1 Display summary information for synchronous Ethernet:
sync synce show
To display statistics information for SyncE
2 Display statistics information for synchronous Ethernet:
sync synce show statistics
To display information for SyncE input references
3 Display information for synchronous Ethernet input references:
sync synce input show
To display detailed information for a SyncE input reference
4 Display detailed information for a SyncE input reference:
sync synce input show ref <ref-name>
where
ref <ref-name> is the SyncE input reference to display detailed information
for.
To display information for SyncE output references

5 Display information for SyncE output references:
sync synce output show

To display detailed information for a SyncE output reference

6 Display detailed information for a SyncE output reference:
sync synce output show ref <ref-name>
where
ref <ref-name> is the SyncE output reference to display detailed information
for.
end
Example
The following example shows sample output for the sync synce show
command.
sync synce show
+--------------------------- SYNCE INPUT REFERENCES -------------------------------+

+-----+---------------------+-----------+-----+----+-----+----+--------------------+
+-----+---------------------+-----------+-----+----+-----+----+--------------------+
+---------------------------- SYNCE OUTPUT REFERENCES ---------------------------+

+-------------------------------+---------------+-----+-----+--------------------+
+-------------------------------+---------------+-----+-----+--------------------+
The following example shows sample output for the sync synce show statistics
command.
sync synce show statistics
+-------+------------ SYNCE STATISTICS ---------------------+

| | Rx | Tx |
| QL +------------+------------+------------+------------+
| | Info Msg | Event Msg | Info Msg | Event Msg |
+-------+------------+------------+------------+------------+
| PRS | 0| 0| 0| 0|
| STU | 0| 0| 0| 0|
| ST2 | 0| 0| 0| 0|
| TNC | 0| 0| 0| 0|
| ST3E | 0| 0| 0| 0|
| ST3 | 0| 0| 0| 0|
| SMC | 0| 0| 0| 0|
| PROV | 0| 0| 0| 0|
| DUS | 0| 0| 0| 0|
+-------+------------+------------+------------+------------+
The following example shows sample output for the sync synce input show
command.
sync synce input show

+------------------------------ SYNCE INPUT REFERENCES ----------------------------+

+-----+---------------------+-----------+-----+----+-----+----+--------------------+
+-----+---------------------+-----------+-----+----+-----+----+--------------------+
The following example shows sample output for the sync synce input show ref
command for the input reference mySyncEinput5.
sync synce input show ref mySyncEinput5
+------------------------- SYNCE INPUT REFERENCE ------------------------+

+-----------------------+------------------------------------------------+
| Reference Name | mySyncEinput5 |
| Timing Interface | port 5 |
| Protection Group | myFreqGroup |
| Operational Status | Active |
+-----------------------+------------------------------------------------+
| Override-priority | - |
| Operational QL | ST2 |
| Forced QL | - |
| RX QL | ST2 |
| QL Receive | Enabled |
| Priority | 1 |
+-----------------------+------------------------------------------------+
The following example shows sample output for the sync synce output show
command.
sync synce output show
+------------------------ SYNCE OUTPUT REFERENCES -----------------------+

+-----------------------+---------------+-----+-----+--------------------+
+-----------------------+---------------+-----+-----+--------------------+
The following example shows sample output for the sync synce output show
ref command for the output reference mySyncEinput1.
sync synce output show ref mySyncEoutput1
+--------------------------- SYNCE OUTPUT REFERENCE ----------------------+

+-----------------------+-------------------------------------------------+
| Reference Name | mySyncEoutput1 |
| Operational Status | Loss of Signal |
+-----------------------+-------------------------------------------------+
| TX QL | - |
+-----------------------+-------------------------------------------------+

Procedure 6-20
Displaying BITS information
You can display:
summary information for BITS timing
information for BITS input references
detailed information for a BITS input reference
information for BITS output references
detailed information for a BITS output reference
Step Action
To display summary information for BITS timing

1 Display summary information for BITS timing:
sync bits show
To display information for BITS input references
2 Display information for BITS input references:
sync bits input show
To display detailed information for a BITS input reference
3 Display detailed information for a BITS input reference:
sync bits input show ref <ref>
To display information for BITS output references
4 Display information for BITS output references:
sync bits output show
To display detailed information for a BITS output reference
5 Display detailed information for a BITS output reference:
sync bits output show ref <ref>
end
Example
The following example shows sample output for the sync bits show command.
sync bits show
+-------------------------- BITS INPUT REFERENCES ---------------------------------+

+-----+-----------------+---------------+-----+----+-----+----+--------------------+
+-----+-----------------+---------------+-----+----+-----+----+--------------------+

+-------------------------- BITS OUTPUT REFERENCES ------------------------+

+-------------------------+---------------+-----+-----+--------------------+
+-------------------------+---------------+-----+-----+--------------------+
The following example shows sample output for the sync bits input show
command.
sync bits input show
+---------------------------- BITS INPUT REFERENCES -------------------------------+

+-----+-----------------+---------------+-----+----+-----+----+--------------------+
+-----+-----------------+---------------+-----+----+-----+----+--------------------+
The following example shows sample output for the sync bits input show ref
command for the input reference myBITSinput1.
sync bits input show ref myBITSinput1
+------------------------ BITS INPUT REFERENCE ------------------------+

+-----------------------+----------------------------------------------+
| Reference Name | myBITSinput1 |
| Protection Group | myFreqGroup |
+-----------------------+----------------------------------------------+
| BITS Mode | E1 |
| Format | ESF |
| Encoding | AMI |
| E1 SSM Location | SA4 |
+-----------------------+----------------------------------------------+
| Override Priority | 1 |
| Operational QL | ST3E |
| Forced QL | ST3E |
| RX QL | - |
| QL Receive | Disabled |
| Priority | - |
+-----------------------+----------------------------------------------+
The following example shows sample output for the sync bits output show
command.
sync bits output show

+-------------------------- BITS OUTPUT REFERENCES ------------------------+
+-------------------------+---------------+-----+-----+--------------------+
+-------------------------+---------------+-----+-----+--------------------+
The following example shows sample output for the sync bits output show ref
command for the output reference myBITSinput2.
sync bits output show ref myBITSinput2
+--------------------------- BITS OUTPUT REFERENCE -----------------------+

+-----------------------+-------------------------------------------------+
| Reference Name | myBITSinput2 |


+-----------------------+-------------------------------------------------+
| BITS Mode | E1 |
| Format | ESF |
| Encoding | AMI |
| E1 SSM Location | SA4 |
+-----------------------+-------------------------------------------------+
| TX QL | ST3E |
+-----------------------+-------------------------------------------------+

Procedure 6-21
Displaying PTP information
You can display:
summary information for PTP timing
performance statistics information for PTP timing
information for PTP input references
information for PTP output references
detailed information for a PTP input reference
detailed information for a PTP output reference
information for PTP masters
information for PTP clients
PDU statistics for a PTP master
PDU statistics for a PTP client
Step Action
To display summary information for PTP timing

1 Display summary information for PTP timing:
sync ptp show
To display performance statistics information for PTP timing
2 Display performance statistics information for PTP timing:
sync ptp show performance-statistics
To display information for PTP input references
3 Display information for PTP input references:
sync ptp input show
To display detailed information for a PTP input reference
4 Display detailed information for a PTP input reference:
sync ptp input show ref <ref-name>
To display the list of connected PTP masters
5 Display the list of connected PTP masters:
sync ptp input show master-list
To display the PDU statistics for a PTP master
6 Display the PDU statistics for a PTP master:
sync ptp input show master <clock-ID> pdu-statistics

To display information for PTP output references

7 Display information for PTP output references:
sync ptp output show
To display detailed information for a PTP output reference
8 Display detailed information for a PTP output reference:
sync ptp output show ref <ref-name>
To display the connected PTP client list
9 Display the connected PTP client list:
sync ptp output show client-list
To display the PDU statistics for a PTP client
10 Display the PDU statistics for a PTP client:
sync ptp output show client <clock-ID> pdu-statistics
end
Example
The following example shows sample output for the sync ptp show command.
sync ptp show
+----------------------------- PTP CONFIGURATION -------------------------+

+-----------------------+-------------------------------------------------+
| Clock Type | Boundary Clock |
| Clock Identity | AA:BB:CC:DD:EE:FF:00:11 |
| Address Mode | Unicast |
| Tag Priority | 0 |
| Protocol Version | 2 |
| Profile Version | 1.0 |
| Profile Identifier | 00:10:A7:00:01:00 |
| Domain Number | 4 |
| DSCP | 56 |
+-----------------------+-------------------------------------------------+
+--------------------------- PTP INPUT CONFIGURATION ---------------------+

+-----------------------+-------------------------------------------------+
| Unicast Req Duration | 300 |
| Announce Rx Timeout | 3 |
| Announce Tx Rate Req | 1-2nd |
| Sync Tx Rate Req | 64 pps |
| Delay Req Tx Rate | 64 pps |
+-----------------------+-------------------------------------------------+
+--------------------------------- PTP INPUT REFERENCES ----------------------------+

+-----+----------------+-----------------+-----+----+-----+----+-------------------+
|FPT- |myPTPinput5 |PTP_Interface |PTP | - |ST3E | 3 |Active |
+-----+----------------+-----------------+-----+----+-----+----+-------------------+

+--------------------------- PTP OUTPUT CONFIGURATION --------------------+

+-----------------------+-------------------------------------------------+
| Max Slave Sessions | 16 |
| Timestamp Mode | Two-step |
+-----------------------+-------------------------------------------------+
+---------------------------- PTP OUTPUT REFERENCES --------------+

| | Timing | |Over | |
+----------------+---------------+-----+-----+--------------------+
| myPTPinput9 |PTP Interfac...|PTP |ST3E | Active |
+----------------+---------------+-----+-----+--------------------+
The following command shows sample output for the sync ptp show
performance-statistics command.
sync ptp show performance-statistics
+------------------ PTP PERFORMANCE STATISTICS -------------------+

+------------------------------------------+----------------------+
| Frequency correction (ppb) | 20.471508 |
| Phase correction (ns) | 0.000000 |
| Minimal round trip delay (ns) | 0.000000 |
| Fwd Flow operational min TDEV (ns) | 3725.350342 |
| Rev flow operational min TDEV (ns) | 2298.259033 |
+------------------------------------------+----------------------+
The following command shows sample output for the sync ptp input show
command.
sync ptp input show
+--------------------------- PTP INPUT CONFIGURATION --------------------------+

+-----------------------+------------------------------------------------------+
| Unicast Req Duration | 300 |
| Announce Rx Timeout | 3 sec |
| Announce Rx Rate Req | 1-2nd |
| Sync Tx Rate Req | 64 pps |
| Delay Req Tx Rate | 64 pps |
+-----------------------+------------------------------------------------------+
+-------------------------------------- PTP INPUT REFERENCES ------------------------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
The following command shows sample output for the sync ptp input show ref
myPTPinput5 command.
sync ptp input show ref myPTPinput5
+----------------------------- PTP INPUT REFERENCE ----------------------------+

+-----------------------+------------------------------------------------------+
| Reference Name | myPTPinput5 |
| Protection Group | myFreqGroup, myPhaseGroup, myTodGroup |


+-----------------------+------------------------------------------------------+
| Encapsulation Type | UDP-over-IP |
+-----------------------+------------------------------------------------------+
| Override Priority | - |
| Oper Clock Class/QL | 100/ST3E |
| Forced Clock Class/QL | - |
| RX Clock Class/QL | 100/ST3E |
| QL Receive | Enabled |
| Priority | 3 |
+-----------------------+------------------------------------------------------+
The following command shows the sample output for the sync ptp input show
master-list command.
sync ptp input show master-list
+--------------------------------- PTP MASTER LIST ---------------------------------+

| | Announce| Announce| Sync | Sync |Delay Res|Delay Res|
| Clock Identity |Rate(pps)|Dur (sec)|Rate(pps)|Dur (sec)|Rate(pps)|Dur (sec)|
+-----------------------+---------+---------+---------+---------+---------+--------+
|00:11:22:33:44:55:66:77| 64| 300| 64| 300| 64| 300|
+-----------------------+---------+---------+---------+---------+---------+--------+
The following command shows sample output for the sync ptp input show
master 00.11.22.33.44.55.66.77 pdu-statistics command.
sync ptp input show master 00:11:22:33:44:55:66:77 pdu-statistics
+------------------------------ PTP MASTER ENTRY ------------------------------+

+-----------------------+------------------------------------------------------+
| Clock Identity | 00:11:22:33:44:55:66:77 |
| IP Address | 10.10.10.1 |
+-----------------------+------------------------------------------------------+
+--------------- PTP MASTER PDU STATISTICS ---------------+

+----------------------------------+----------------------+
| Rx Announce | 0 |
| Rx Sync | 0 |
| Rx Follow-up | 0 |
| Rx Delay Request | 0 |
| Rx Delay Response | 0 |
| Rx Signalling | 0 |
| Rx Management | 0 |
| Tx Announce | 0 |
| Tx Sync | 0 |
| Tx Follow-up | 0 |
| Tx Delay Request | 0 |
| Tx Delay Response | 0 |
| Tx Signalling | 0 |
| Tx Management | 0 |
+----------------------------------+----------------------+
The following command shows sample output for the sync ptp output show
command.
sync ptp output show
+-------------------------- PTP OUTPUT CONFIGURATION -------------------+

+-----------------------+-----------------------------------------------+
| Max Slave Sessions | 16 |
+-----------------------+-----------------------------------------------+
+----------------------------- PTP OUTPUT REFERENCES ----------------------------+

+-------------------------------+---------------+-----+-----+--------------------+
+-------------------------------+---------------+-----+-----+--------------------+
The following command shows sample output for the sync ptp output show ref
myPTPoutput5 command.
sync ptp output show ref myPTPoutput5
+--------------------------- PTP OUTPUT REFERENCE -------------------------+

+-----------------------+--------------------------------------------------+
| Reference Name | myPTPoutput5 |
| Timing Interface | IP Interface : PTP_InterfaceOut |
+-----------------------+--------------------------------------------------+
| Encapsulation Type | UDP-over-IP |
+-----------------------+--------------------------------------------------+
| TX Clock Class/QL | 100/ST3E |
+-----------------------+--------------------------------------------------+
The following command shows sample output for the sync ptp-output show
client-list command:
sync ptp output show client-list
+--------------------------------- PTP CLIENT LIST ---------------------------------+

| | Announce| Announce| Sync | Sync |Delay Res|Delay Res|
| Clock Identity |Rate(pps)|Dur (sec)|Rate(pps)|Dur (sec)|Rate(pps)|Dur (sec)|
+-----------------------+--------+----------+---------+---------+---------+--------+
|11:22:33:44:55:66:77:88| 64| 300| 64| 300| 64| 300|
|22:33:44:55:66:77:88:99| 64| 300| 64| 300| 64| 300|
|33:44:55:66:77:88:99:AA| 64| 300| 64| 300| 64| 300|
+-----------------------+---------+---------+---------+---------+---------+--------+
The following command shows a sample output for the sync ptp output show
client 11:22:33:44:55:66:77:88 pdu-statistics command:
sync ptp output show client 11:22:33:44:55:66:77:88 pdu-statistics
+------------------------------ PTP CLIENT ENTRY ------------------------------+

+-----------------------+------------------------------------------------------+
| Clock Identity | 11:22:33:44:55:66:77:88 |
| IP Address | 10.10.10.5 |
+-----------------------+------------------------------------------------------+
+--------------- PTP CLIENT PDU STATISTICS ---------------+
+----------------------------------+----------------------+
| Rx Announce | 0 |
| Rx Sync | 0 |
| Rx Follow-up | 0 |
| Rx Delay Request | 0 |
| Rx Delay Response | 0 |
| Rx Signalling | 0 |
| Rx Management | 0 |
| Tx Announce | 0 |
| Tx Sync | 0 |
| Tx Follow-up | 0 |
| Tx Delay Request | 0 |
| Tx Delay Response | 0 |

| Tx Signalling | 0 |
| Tx Management | 0 |
+----------------------------------+----------------------+

Procedure 6-22
Displaying GPS information
You can display:
summary information for GPS timing
information for GPS input references
detailed information for a GPS input reference
information for GPS output references
detailed information for a GPS output reference
Step Action
To display summary information for GPS timing

1 Display summary information for GPS timing:
sync gps show
To display information for GPS input references
2 Display information for GPS input references:
sync gps input show
To display detailed information for a GPS input reference
3 Display detailed information for a GPS input reference:
sync gps input show ref <ref-name>
To display information for GPS output references
4 Display information for GPS output references:
sync gps output show
To display detailed information for a GPS output reference
5 Display detailed information for a GPS output reference:
sync gps output show ref <ref-name>
end
Example
The following command shows sample output for the sync gps show
command.
sync gps show

+------------------------------------- GPS INPUT REFERENCES -------------------------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+

+--------------------------- GPS OUTPUT CONFIGURATION -------------------------+

+-----------------------+------------------------------------------------------+
| 1pps Pulse Width | 1000 usec |
+-----------------------+------------------------------------------------------+
+----------------------------- GPS OUTPUT REFERENCES ----------------------------+

+-------------------------------+---------------+-----+-----+--------------------+
+-------------------------------+---------------+-----+-----+--------------------+
The following command shows sample output for the sync gps input show
command.
sync gps input show

+------------------------------------- GPS INPUT REFERENCES -------------------------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
The following command shows sample output for the sync gps input show ref
myGPS10MHzInput1 command.
sync gps input show ref myGPS10MHzInput1
+--------------------------- GPS INPUT REFERENCE --------------------------+

+-----------------------+--------------------------------------------------+
| Reference Name | myGPS10MHzInput1 |
| Timing Interface | 10mhz-smb-1 |
| Protection Group | - |
+-----------------------+--------------------------------------------------+
| Clock Mode | Frequency |
| Frequency Clock | 10 MHz |
+-----------------------+--------------------------------------------------+
| Override Priority | - |
| Operational QL | PRS |
| Forced QL | PRS |
| Priority | - |
+-----------------------+--------------------------------------------------+
The following example shows sample output for the sync gps output show
command.
sync gps output show
+--------------------------- GPS OUTPUT CONFIGURATION -------------------------+

+-----------------------+------------------------------------------------------+
| 1pps Pulse Width | 1000 usec |
+-----------------------+------------------------------------------------------+
+----------------------------- GPS OUTPUT REFERENCES ----------------------------+

+-------------------------------+---------------+-----+-----+--------------------+
+-------------------------------+---------------+-----+-----+--------------------+

The following example shows sample output for the sync gps output show ref
myGPS10MHzOutput2 command.
sync gps output show ref myGPS10MHzOutput2
+--------------------------- GPS OUTPUT REFERENCE -------------------------+

+-----------------------+--------------------------------------------------+
| Reference Name | myGPS10MHzOutput2 |
| Timing Interface | 10mhz-smb-1 |
+-----------------------+--------------------------------------------------+
| Clock Mode | Frequency |
| Frequency Clock | 10 MHz |
+-----------------------+--------------------------------------------------+

Procedure 6-23
Displaying TDM information
You can display:
summary information for TDM timing
summary information for TDM input references
detailed information for a TDM input reference
Step Action
To display summary information for TDM timing

1 Display TDM information:
sync tdm show
To display summary information for TDM input references
2 Display summary information for TDM input references:
sync tdm input show
To display detailed information for a TDM input reference
3 Display detailed information for a TDM input reference:
sync tdm input show ref <ref-name>
end
Example
The following example shows sample output for the sync tdm show command.
sync tdm show
+------------------------------- TDM INPUT REFERENCES -----------------------------+

+-----+-----------------+---------------+-----+----+-----+----+--------------------+
+-----+-----------------+---------------+-----+----+-----+----+--------------------+
The following example shows sample output for the sync tdm input show
command.
sync tdm input show
+------------------------------- TDM INPUT REFERENCES -----------------------------+

+-----+-----------------+---------------+-----+----+-----+----+--------------------+
+-----+-----------------+---------------+-----+----+-----+----+--------------------+

The following example shows sample output for the sync tdm input show ref
myTDMinput5 command.
sync tdm input show ref myTDMinput5

+-------------------------- TDM INPUT REFERENCE --------------------------+
+-----------------------+-------------------------------------------------+
| Reference Name | myTDMinput5 |
| Protection Group | - |
| Operational Status | Loss of Signal |
+-----------------------+-------------------------------------------------+
| Override-priority | - |
| Operational QL | - |
| Forced QL | ST2 |
| Priority | - |
+-----------------------+-------------------------------------------------+

Procedure 6-24
Displaying frequency information
You can display
frequency information
summary information for frequency input references
summary information for frequency output references
Step Action
To display detailed information for frequency

1 Display detailed information for frequency:
sync frequency show
To display summary information for frequency input references
2 Display summary information for frequency input references:
sync frequency input show
To display summary information for frequency output references
3 Display summary information for output references for frequency:
sync frequency output show
end
Example
The following example shows sample output for the sync frequency show
command.
sync frequency show
+------------------------ FREQUENCY OPERATIONAL STATE -------------------------+

+-----------------------+------------------------------------------------------+
| Duration | 1:01:10:10 |
| Protocol | BITS |
+-----------------------+------------------------------------------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+


+-------------------------------+---------------+-----+-----+--------------------+
+-------------------------------+---------------+-----+-----+--------------------+
The following example shows sample output for the sync frequency input
show command.
sync frequency input show

+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
The following example shows sample output for the sync frequency output
show command.
sync frequency output show

+-------------------------------+---------------+-----+-----+--------------------+
+-------------------------------+---------------+-----+-----+--------------------+

Procedure 6-25
Displaying phase information
You can display:
phase information
summary information for phase input references
summary information for phase output references
Step Action
To display detailed phase information

1 Display detailed information for phase:
sync phase show
To display summary information for phase input references
2 Display summary information for input references for phase:
sync phase input show
To display summary information for phase output references
3 Display summary information for output references for phase:
sync phase output show
end
Example
The following example shows sample output for the sync phase show
command.
sync phase show
+--------------------------- PHASE OPERATIONAL STATE --------------------------+

+-----------------------+------------------------------------------------------+
| Duration | 0:02:12:40 |
| Protocol | PTP |
+-----------------------+------------------------------------------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+


+-------------------------------+---------------+-----+-----+--------------------+
+-------------------------------+---------------+-----+-----+--------------------+
The following example shows sample output for the sync phase input show
command.
sync phase input show

+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
The following example shows sample output for the sync phase output show
command.
sync phase output show

+-------------------------------+---------------+-----+-----+--------------------+
+-------------------------------+---------------+-----+-----+--------------------+

Procedure 6-26
Displaying time-of-day information
You can display detailed information for time-of-day:
Step Action
To display detailed information for time-of-day

1 Display detailed information for time of day:
sync time-of-day show
To display summary information for input references for time-of-day
2 Display summary information for input references for time of day:
sync time-of-day input show
To display summary information for output references for time-of-day
3 Display summary information for output references for time of day:
sync time-of-day output show
end
Example
The following example shows sample output for the sync time-of-day show
command.
sync time-of-day show
+------------------------ TIME-OF-DAY OPERATIONAL STATE -----------------------+

+-----------------------+------------------------------------------------------+
| Duration | 0:02:12:40 |
| Protocol | PTP |
+-----------------------+------------------------------------------------------+
+-----------------------+------------------------------------------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+

+-------------------------------+---------------+-----+-----+--------------------+
+-------------------------------+---------------+-----+-----+--------------------+

The following example shows sample output for the sync time-of-day input
show command.
sync time-of-day input show

+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
The following example shows sample output for the sync time-of-day output
show command.
sync time-of-day output show

+-------------------------------+---------------+-----+-----+--------------------+
+-------------------------------+---------------+-----+-----+--------------------+

Procedure 6-27
Displaying protection-group information
You can display detailed information for a:
frequency protection-group
phase protection-group
time-of-day protection-group
Step Action
To display detailed information for a given frequency protection-group

1 Display detailed information for a given frequency protection-group:
sync frequency protection-group show group <group>
To display detailed information for a given phase protection-group
2 Display detailed information for a given phase protection-group:
sync phase protection-group show group <group>
To display detailed information for a given time-of-day protection-group
3 Display detailed information for a given time-of-day protection-group:
sync time-of-day protection-group show group <group>
end
Example
The following example shows sample output for the sync frequency
protection-group show group command, where the group name is
myFreqGroup.
sync frequency protection-group show group myFreqGroup
+------------------------- FREQUENCY PROTECTION-GROUP -------------------------+

+-----------------------+------------------------------------------------------+
| Group Name | myFreqGroup |
| Threshold QL | PROV |
| Forced Reference | - |
+-----------------------+------------------------------------------------------+
| Duration | 1:01:10:10 |
| Protocol | BITS |
+-----------------------+------------------------------------------------------+

+-------------------------- FREQUENCY PROTECTION-GROUP INPUT REFERENCES -------------------------+

+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
The following example shows sample output for the sync phase protection-
group show group myPhaseGroup command.
sync phase protection-group show group myPhaseGroup
+--------------------------- PHASE PROTECTION-GROUP ---------------------------+

+-----------------------+------------------------------------------------------+
| Group Name | myPhaseGroup |
+-----------------------+------------------------------------------------------+
| Duration | 0:02:12:40 |
| Protocol | PTP |
+-----------------------+------------------------------------------------------+
+-------------------- PHASE PROTECTION-GROUP INPUT REFERENCES ---------------------+

|Prot | | Timing | |Over|Oper| | |
|Group| Reference Name | Interface |Proto|Prio| QL |Prio|Operational Status|
+-----+---------------------+--------------+-----+----+----+----+------------------+
| FPT |myPTPinput5 |PTP Interface |PTP | - |ST3E| 3 |Active |
+-----+---------------------+--------------+-----+----+----+----+------------------+
The following example shows sample output for the sync phase protection-
group show group myToDGroup command.
sync time-of-day protection-group show group MyToDGroup
+------------------------ TIME-OF-DAY PROTECTION-GROUP ------------------------+

+-----------------------+------------------------------------------------------+
| Group Name | myToDGroup |
+-----------------------+------------------------------------------------------+
| Duration | 0:02:12:40 |
| Protocol | PTP |
+-----------------------+------------------------------------------------------+
+-----------------------+------------------------------------------------------+

+------------------------- TIME-OF-DAY PROTECTION-GROUP INPUT REFERENCES ------------------------+

+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+
+-----+-------------------------------+---------------+-----+----+-----+----+--------------------+

Procedure 6-28
Sample configuration: system timing by means of
SyncE and PTP
The following sample configuration sets up system timing to:
recover frequency by means of SyncE (port 5) with PTP (master IP
address 2.2.2.1, vlan 200) as backup
recover phase by means of PTP (master IP address 2.2.2.1, vlan 200)
distribute frequency by means of BITS (SYNC RJ45 interface) and GPS
(10 MHz SMB interface)
distribute phase by means of GPS (1PPS SMB interface)
The network topology diagram for this configuration is shown in Figure 6-4 on
page 6-15.
Step Action
1 Set the option-type:

sync set option-type option1
Note: This is a mandatory one-time configuration that must be entered first.
2 Configure the VLAN and IP interface for the PTP session:
vlan create vlan 200
vlan add vlan 200 port 2
interface create ip-interface PTP_Interface ip 2.2.2.133/
24 vlan 200
3 Create the PTP input reference object:
sync ptp input create ref PTP_In master-ip-address
2.2.2.1 ip-interface PTP_Interface encap-type udp-over-ip
priority 2
4 Create the SyncE input reference object:
sync synce input create ref SyncE_Port5_In port 5 priority
1
5 Create the GPS output reference objects:
sync gps output create ref SMB_2048_Out gps-interface
10mhz-smb-1 clock-mode frequency frequency-clock 2048khz
sync gps output create ref 1PPS_SMB_Out gps-interface
1pps-smb-1 clock-mode phase
6 Create the BITS output reference object:
sync bits output create ref E1_BITS_Out bits-interface
sync-rj45-1 bits-mode e1 format e1-crc

7 Create the frequency protection-group object and add input references with
frequency components to it:
sync frequency protection-group create group
FreqProtGroup threshold-ql sec
sync frequency protection-group add group FreqProtGroup
input-ref PTP_In,SyncE_Port5_In
8 Create the phase protection-group object and add input references with
phase components to it:
sync phase protection-group create group PhaseProtGroup
threshold-ql sec
sync phase protection-group add group PhaseProtGroup
input-ref PTP_In
end

Procedure 6-29
Sample configuration: system timing by means of
PTP Boundary Clock
The following sample configuration sets up system timing to:
recover PTP timing on an Ordinary Clock Slave from a GrandMaster Clock
via a Boundary Clock while keeping the GrandMaster Clock as a backup
timing reference.
The network topology diagram for this configuration is shown in System

timing using PTP timing on page 6-16.
Step Action
To recover PTP timing on the Boundary Clock from the GrandMaster

vlan add vlan 200 port 1, 2
interface create ip-interface ptp200 ip 2.2.2.10/24 vlan
200
sync disable
3 Set the synchronization option type to option 2:
sync set option-type option 2
4 Set the reversion-mode to revertive:
sync set reversion-mode revertive
5 Set the wait-to-restore value:
sync set wait-to-restore 10
6 Set the clock type to boundary clock:
sync ptp set clock-type bc
7 Create the PTP input reference object for the GrandMaster Clock:
sync ptp input create ref GrandMaster encap-type udp-
over-ip ip-interface ptp200 master-ip-address 2.2.2.1
FreqProtGroup threshold-ql tnc
input-ref GrandMaster

threshold-ql tnc
10 Create the time-of-day protection-group object and add input references with
time-of-day components to it:
sync time-of-day protection-group create group
TodProtGroup theshold-q1 tnc
sync time-of-day protection-group add group TodProtGroup
11 Create the PTP output reference object:
sync ptp output create ref BoundaryClockOutput encap-type
udp-over-ip ip-interface ptp200
sync enable
To recover PTP timing on the Ordinary Clock Slave from the Boundary Clock while keeping the
GrandMaster as a backup timing reference
interface create ip-interface ptp200 ip 2.2.2.10/24 vlan
200
sync disable
15 Set the synchronization option type to option 2:
sync set option-type option 2
16 Set the reversion-mode to revertive:
sync set reversion-mode revertive
17 Set the wait-to-restore value:
sync set wait-to-restore 10
18 Set the clock type to ordinary clock slave:
sync ptp set clock-type oc-slave
19 Create PTP input reference object for the Boundary Clock:
sync ptp input create ref BoundaryClock encap-type udp-
priority 1
20 Create PTP input reference object for the GrandMaster clock:
sync ptp input create ref GrandMaster encap-type udp-
priority 2

FreqProtGroup threshold-ql tnc
input-ref BoundaryClock,GrandMaster
threshold-ql tnc
23 Create the time-of-day protection-group object and add input references with
time-of-day components to it:
sync time-of-day protection-group create group
TodProtGroup theshold-q1 tnc
sync time-of-day protection-group add group TodProtGroup
sync enable
end


7-1
Link Layer Discovery Protocol (LLDP)

configuration 7-
The system software supports Link Layer Discovery Protocol (LLDP) as

specified in the IEEE 802.1AB-2005 standard. Like Rapid Spanning Tree
Protocol (RSTP), LLDP is a link-constrained, layer 2 protocol. This means that
the exchange of LLDP messages only takes place between adjacent LLDP
agents (devices) on the network, unless control frame tunneling is used to
tunnel the Link Layer Discovery Protocol Data Units (LLDPDUs) through
another device.
LLDP agents communicate basic management information with each other by

exchanging LLDPDUs. The information about a device, and its immediate
neighbors is then retrievable through the standard LLDP MIBs using SNMP. It
is important to note that LLDP operates only on physical ports.

7-2 Link Layer Discovery Protocol (LLDP) configuration
As illustrated in Figure 7-1, LLDP Agent A exchanges LLDPDUs with LLDP

Agent B and Agent C, but not with Agent D since it is not directly connected to
Agent A.
Figure 7-1
Example of Architectural Relationship Between LLDP Agents
LLDP Agent B
LLDP Agent A
LLDP Agent C
LLDP Agent D
Note: Link Layer Discovery Protocol does not configure or control any
traffic or devices on the network. Its primary role is to report discovered
information to higher-layer management tools. It is not intended to act as
a configuration protocol for remote systems nor as a mechanism to signal
control information between ports.

LLDP TLVs
The LLDPDU is a layer 2 packet that consists of an L2 source, destination, and
an Ethertype field, and 4 or more Type Length and Value fields (TLVs). The
LLDP standard specifies 9 common TLV fields, 4 of which are mandatory
TLVs and the remaining 5 are optional TLVs to carry information for
broadcasting sender information.
Figure 7-2
LLDPDU Packet
Layer 2 DA, 01-80-C2-00-00-0E

Layer 2 SA, Port-MAC of the transmitting device
Layer 2 etherType field, 88-CC
Chassis ID TLV
Port ID TLV
TTL TLV
Optional TLVs
End of LLDPDU TLV
Periodic LLDPDUs are sent out at a user-defined interval; however, LLDPDUs

are also sent whenever LLDP TLV data has changed. An SNMP notification is
then generated after changed data is received from a neighboring device.
Upon receipt of this notification the SNMP management application polls the
LLDP MIB objects to determine what information has changed.

Common TLVs
Table 7-1 lists LLDP TLVs and provides a description for each TLV. The
system software supports the nine common TLVs specified by IEEE 802.1AB-
2005.
Table 7-1
Common TLVs
TLV Description
Common
Chassis ID TLV Identifies the chassis. This TLV contains the 802 LAN
station associated with the transmitting LLDP agent and
supports the MAC Address chassis ID subtype.
This TLV is mandatory.
Port ID TLV Identifies the port component that transmits the TLV. It
supports the Interface Alias port ID subtype.
Time To Live (TTL) TLV Indicates the number of seconds that the recipient LLDP
agent is to regard the information associated with this
LLDPDU to be valid.
Port Description TLV Specifies the description for the port as an alphanumeric
string.
This TLV is optional.
System Name TLV Specifies the assigned name as an alphanumeric string.

System Description TLV Indicates the system description as an alphanumeric

string.
System Capabilities TLV Identifies the primary functions of the system and
whether these primary functions are enabled. It supports
the bridge capability.
Management Address Identifies the IPv4 and IPv6 address associated with the
TLV(s) local LLDP agent that can be used to reach higher layer
entities to assist discovery by network management.
End of LLDPDU TLV Defines the end of LLDPDU with all 0 values in two
octets.

Table 7-1
Common TLVs
TLV Description
802.1 Organizationally Specific TLVs
Port VLAN ID TLV Allows a port to advertise its VLAN ID (PVID) that is
associated with untagged or priority tagged frames.
Port and Protocol VLAN The system software stores values received from the
ID TLV remote partner for this TLV but does not transmit this
TLV.
VLAN Name TLV The system software stores values received from the
remote partner for this TLV but does not transmit this
TLV.
Protocol ID TLV Allows an 802 LAN station to advertise particular

protocols that are accessible through the port. Currently,
the system software advertises the following protocols:
RSTP and 802.3ah OAM.
802.3 Organizationally Specific TLVs
MAC/PHY Configuration/ Advertises auto negotiation support and status, PMD

Status TLV auto negotiation capability, and operational MAU type.
Power via MDI TLV The system software stores values received from the
remote partner for this TLV but does not transmit this
TLV.
Link Aggregation TLV Advertises whether the link is capable of being

aggregated, whether the link is currently in an
aggregation, and the port ID of the aggregation if it is in
an aggregation. LLDP advertises Link Agg TLV in the
PDU but Link Aggregation is not currently supported and
is disabled.
Maximum Frame Size Advertises the maximum frame size capability.

TLV
Ciena Organizationally Specific TLVs

Table 7-1
Common TLVs
TLV Description
Unknown TLVs The system software stores all unknown TLVs for all
valid LLDP PDUs for retrieval.
LLDP Graceful Shut When an LLDP agent is administratively disabled, it

Down executes a graceful shutdown handshake. It sends out
the last LLDP PDU that specifies the TTL as zero in TTL
TLV. When its counterpart receives this LLDPDU, it
cleans up all the LLDP information received.
Encoding of SyncE Info This TLV conveys the following information:

SyncE capability of the port, which is one of
input only
output only
both
not supported
current SyncE configuration of the port, which is one of
input reference
output reference
both
not configured
Feature Benefits
Using LLDP for network topology discovery offers the following benefits to the
network provider:
Accurate network topology discovery and management
Support of standard tools using SNMP
Multi-vendor interoperability.
Accurate Network Topology Discovery and Management

Many network management tools use layer 3 protocols to automate the
discovery process and track topology configurations and changes. The use of
layer 2 LLDP allows network management tools to quickly and accurately
discover current network topologies and to track both intentional and
unintentional topology changes. Network administrators and technicians can
use the accurate and up-to-date topology information to more quickly
diagnose network problems in the field.

Support of Standard Tools

Each LLDP agent maintains its own per-port table of information in a standard
SNMP MIB. Updates are sent as needed to the closest connected device on
the network. Users access the device and manage LLDP information through
the command line interface (CLI). Users can display general information, for
example, Chassis ID and port configuration. Users with superuser security
privileges can configure LLDP options and manipulate TLVs. For example, a
specific port could be configured to only transmit or receive LLDPDUs.
LLDPDUs are used to update standard LLDP Management information

Databases (MIBs) allowing any standard SNMP application to monitor the
information as it changes.
Multi-vendor Interoperability
LLDP is a standards-based protocol. Using LLDP rather than a proprietary
topology discovery protocol allows the network provider to interoperate with
non-Ciena devices that also support LLDP.
This chapter provides the following procedures for LLDP:

Configuring LLDP on page 7-8
Configuring TLV transmission on page 7-10
Displaying LLDP neighbors on page 7-12
Enabling and disabling SNMP notifications on page 7-13

Procedure 7-1
Configuring LLDP
LLDP is enabled by default on all ports, but can be enabled or disabled on a
per-port basis.
CAUTION
Performance During Topology Discovery
The default settings for LLDP should be sufficient to ensure
proper topology discovery in most networks. Since Ethernet
Services Manager (ESM) topology discovery relies on LLDP
for higher performance topology discovery, care should be
taken when modifying the LLDP configuration. In certain
topologies, LLDP does not need to be forwarded, for example,
when using non-LLDP devices such as hubs.
Step Action
1 Display the current state of the port.

lldp show port <port>
where
<port> is the port to be disabled.
2 Disable the port.

lldp set port <port> disable
where
3 To verify the configuration of the port, execute the following command:

lldp show port <port> configuration
where
end
Example
In the following configuration example, the user displays the state of port 10,
then disables LLDP on this port. It should be noted as well that by using the
lldp show port command, information about the remote port (neighbor) can
be seen in the LLDP Remote Port TLV section of the output. This displays the
MAC address, port number, and other information of the connected remote
port.

Display the current state of port 10.
lldp show port 10

+----------- LLDP Port Configuration -----------+
| | | Basic | Org Specific | |
| | Admin |TLV Type| Dot1 |Dot3| | |
| Port | State |123456789|1234567|1234| |Notif|
+------+-------+---------+-------+----+---+-----+
|10 | Tx-Rx |111111111|1 1111|1111| | Off |
+------+-------+---------+-------+----+---+-----+
Set port 10 to disable.
lldp set port 10 disable
Verify the configuration of the port.
lldp show port 10 configuration

+----------- LLDP Port Configuration -----------+
| | | Basic | Org Specific | |
| | Admin |TLV Type| Dot1 |Dot3| | |
| Port | State |123456789|1234567|1234| |Notif|
+------+-------+---------+-------+----+---+-----+
|10 |Disable|111111111|1 1111|1111| | Off |
+------+-------+---------+-------+----+---+-----+

Procedure 7-2
Configuring TLV transmission
Some optional TLVs can be excluded from transmission in the LLDP PDU on
a per-port basis.
Step Action
1 Set TLV transmission parameters:

lldp tlvtx set port <port> mgmt-addr-local <on|off> mgmt-
addr-remote <on|off> port-descr <on|off> system-cap
<on|off> system-descr <on|off> system-name <on|off>
where
port <port> is the port list.
mgmt-addr-local indicates whether to transmit the Local Management
<on|off> Address. The default value is on.
mgmt-addr- indicates whether to transmit the Remote Management
remote <on|off> Address. The default value is on.
port-descr indicates whether to transmit the port description. The
<on|off> default value is on.
system-cap indicates whether to transmit the system capabilities. The
system-descr indicates whether to transmit the system description. The
system-name indicates whether to transmit the system name. The default
<on|off> value is on.
2 Set TLV transmission dot1 parameters:

lldp tlvtx-dot1 set port <port> port-vlan-id <on|off>
protocol-id-dot1x <on|off> protocol-id-lacp <on|off>
protocol-id-oam <on|off> protocol-id-stp <on|off>
where
port-vlan-id indicates whether to transmit the port VLAN ID. The default
<on|off> value is on.
protocol-id-dot1x indicates whether to transmit the protocol ID xdot1x. The

where
protocol-id-lacp indicates whether to transmit the protocol ID LACP. The
protocol-id-oam indicates whether to transmit the protocol ID OAM. The
protocol-id-stp indicates whether to transmit the protocol ID STP. The
3 Set TLV transmission dot3 parameters:
lldp tlvtx-dot3 set port <port> link-agg <on|off> mac-
phy-config <on|off> max-frame-size <on|off> power-via-mdi
<on|off>
where
link-agg <on|off> indicates whether to transmit the link aggregation status.
The default value is on.
mac-phy-config indicates whether to transmit the MAC Phy configuration.
<on|off> The default value is on.
max-frame-size indicates whether to transmit the maximum frame size. The
power-via-mdi indicates whether to transmit the power via MDI status. The
end

Procedure 7-3
Displaying LLDP neighbors
Display LLDP neighbors when you want to view the following information
about neighboring devices:
local port
remote port
remote management address
chassis identification
system name
Use the information to troubleshoot connectivity issues to other network

elements.
Step Action
1 Display neighboring devices:

lldp show neighbors
end
Example
The following example shows sample output for the lldp show neighbors
command.
lldp show neighbors

+--------------------------------------------------------------------------+
| LLDP Neighbors |
+--------------------------------------------------------------------------+
| Remote Addr: 192.0.2.1 |
| Local Addr: 10.5.5.164 |
| Local Addr: 2001:0db8:f018:1:202:5aff:fe01:b43a |
| Remote Addr: 2001:db8:: |
| System Name: 3930ET-2 |
| System Desc: 3930 Service Delivery Switch |
+------------+-------------------------------------------------------------+
| Local | Remote |
+------------+----------+--------------------------------------------------+
| Port | Port | Info |
+------------+----------+--------------------------------------------------+
| 5 | 5 | Chassis Id: 00025A01D309 |
| | | Mgmt Addr: 10.5.5.164 |
| | | 2001:0db8:f018:1:202:5aff:fe01:b43a |
| | | 2001:db8:: |
| | | System Name: 3930ET-2 |
| | | System Desc: 3930 Service Delivery Switch |
| | | SyncE Suppt: Input and Output |
| | | SyncE Confg: Input |
+------------+----------+--------------------------------------------------+

Procedure 7-4
Enabling and disabling SNMP notifications
LLDP supports the standard lldpRemTablesChange SNMP notification per
port. This notification is disabled by default. When enabled, an SNMP
notification is generated upon LLDP activity for the port when the value of the
lldpStatsRemTableLastChangeTime changes.
You can
enable SNMP notifications
disable SNMP notifications
Step Action
1 Enable notification of LLDP activity per port:

lldp set port <port> notification on
where
port <port> is the physical port to enable notification of LLDP activity for.
notification on enables notification.
2 Disable notification of LLDP activity per port:

lldp set port <port> notification off
where
port <port> is the physical port to disable notification of LLDP activity for.
notification off disables notification.
end


8-1
VLAN management 8-
This chapter details the function of VLANs. It also details how to configure port
settings to switch traffic properly through the network.
The following sections are in this chapter:

VLANs and traffic flow on page 8-1
Behavior summary on page 8-4
VLAN/port configuration on page 8-4
VLAN translation on page 8-5
Note: VLAN configuration requires installation of the Advanced Ethernet

(AE) license. If you do not have an AE license, contact Ciena Sales.
VLANs and traffic flow

VLANs determine how traffic is forwarded within a device. The ingress and
egress behavior of each port must be taken into account. The basic rules to
govern traffic forwarded through the device are as follows:
Port VLAN Membership
Acceptable Frame Types (ingress rule)
Port VLAN ID (PVID) (ingress rule)
Ingress Filtering (ingress rule)
Ingress Untagged Frames (ingress rule)
Egress Untagged VLAN (egress rule)
Acceptable Frame Types

When a frame arrives at a port on a device, it is first examined to determine
whether it is a tagged (contains a VLAN ID) or untagged frame. This is referred
to as the frame type. Each port of the device has an associated Acceptable
Frame Types (AFT) parameter that controls whether or not the port will accept
untagged frames. A port can be configured to admit ONLY tagged frames or
to admit ALL Frames.

8-2 VLAN management
When the value of the Acceptable Frame Types parameter is set to VLAN
tagged-only, tagged frames are allowed to ingress while untagged or priority-
tagged frames (i.e., a frame with no tag header, or a frame with a tag header
that carries the null VLAN ID) received on the port are discarded. Tagged
frames are then further processed according to the additional ingress rules set
on the port. In contrast, if the Acceptable Frame Types parameter is set to all,
all frames are allowed to ingress, regardless of their tag status.
Port VLAN ID
The full VLAN address range from 1 to 4094 can be supported per port. For
untagged or priority-tagged frames, the next ingress rule applied is the Port
VLAN ID (PVID). Each port on the device has an associated PVID. By default,
the PVID value is the default VLAN ID (VLAN 1). When an untagged frame
arrives at an ingress port (assuming that the port is set to accept all frame
types) it may be forwarded to all ports that are members of the configured
PVID (depending on additional ingress parameters set on the device). If an
ingress frame is not tagged with the VLAN specified by the ports PVID, then
the setting on the port's Ingress Filter will apply.
Similarly, if a port is removed from a VLAN that is also its PVID, the PVID value
remains the same and the port's Ingress Filter setting is therefore applied
(refer to the VLAN Ingress Filter section).
The PVID assignment for aggregated ports is slightly different. When a

physical port is added to an aggregation, it inherits the PVID setting of the
aggregation group. However, when the port is removed from the aggregation,
its own PVID setting becomes valid again.
Note: PVIDs can only be set to the VLAN ID of configured VLANs,

therefore the VLAN must exist before the corresponding PVID can be
assigned. The port does not however, have to be a member of the VLAN
in order to assign the PVID.
VLAN Ingress Filter

The last parameter applied to ingressing frames is the VLAN Ingress Filter.
The VLAN Ingress Filter forwards or discards a frame based on the VLAN tag.
When VLAN Ingress Filtering is enabled on a port (VLAN Ingress Filtering is
enabled by default), an ingressing frame that is tagged with a VLAN to which
the ingress port does not belong, will be discarded. For example, assuming
that VLAN 200 is configured on the device, if the ingressing frame is tagged
with VLAN 200, but the port is not a member of VLAN 200, the frame is
discarded.
If VLAN Ingress Filtering is disabled, ports do not consider the VLAN

membership of ingressing frames. In the above example, with VLAN Ingress
Filtering disabled, the frame tagged with VLAN 200 may be forwarded to all

VLAN management 8-3
port members of VLAN 200, regardless of whether the ingress port belongs
to VLAN 200. However, if VLAN 200 has not been configured on the device,
the frame is then dropped.
Egress Untagged VLAN

Once a frame reaches its egress port on the device, one final VLAN operation
is performed. The Egress Untagged VLAN (EUV) parameter determines
whether the egressing frame will be forwarded tagged or untagged. As a
frame egresses the device, its VLAN ID is compared to the EUV. If the VLAN
ID is the same as the EUV, then the VLAN tag is stripped from the egressing
frame and it is sent untagged. If the VLAN ID is not the same as the ports
EUV, then the frame is sent out with its tag intact. By default, the EUV is
VLAN 1, as is the PVID. When the PVID is changed, the EUV value
automatically updates to match the PVID, until it is explicitly set.
For example, the default PVID and EUV are set to 1. If you set ports PVID to
VLAN 200, and the EUV is automatically set to VLAN 200. A frame that is
tagged with VLAN 200 would have its tag stripped as it egresses. In contrast
a frame with a VLAN tag of 300 will egress with its tag intact.
However, if you set the EUV to 300, the PVID remains at 200. Now, the frame
tagged with VLAN 200 retains its tag on egress, and the frame with a VLAN
tag of 300 has its tag removed.

8-4 VLAN management
Behavior summary
The following tables summarize packet behavior.
Table 8-1
Ingress Behavior
Ingress AFT PVID Ingress Filter Behavior

Frame
Tagged Tagged-only N/A Disabled The frame is forwarded if the VLAN exists on
the device.
Tagged Tagged-only N/A Enabled The frame is forwarded if the ingress port is a
member of the ingressing frames VLAN.
Tagged All N/A Disabled The frame is forwarded if the VLAN exists on
the device.
Tagged All N/A Enabled The frame is forwarded if the ingress port is a
member of the ingressing frames VLAN.
Untagged Tagged-only N/A N/A The frame is dropped.
Untagged All Any Disabled The frame is forwarded to all ports that are
members of the ingressing ports PVID.
Untagged All Any Enabled The frame is forwarded to PVID members only
if the ingress port is a member of the PVID.
Table 8-2
Egress Behavior
Frame State EUV State Egress Behavior
Tagged VLAN ID = EUV Frame sent untagged.
Tagged VLAN ID EUV Frame sent tagged.
VLAN/port configuration
All of the frame forwarding behaviors discussed in this chapter are port-based
features, but require VLANs to tie them together. The VLAN can be thought of
as an imaginary wire that connects the ingress port to the egress port(s).
VLANs must be created using the CLI, MIB, or the Device Manager, prior to
configuring other features on the device. A VLAN is identified by two basic
parameters:
VLAN ID, which is the value used to identify the VLAN
VLAN Name, which is defined by the network operator. VLAN names may
not begin with a number. This is an optional parameter.

VLAN management 8-5
VLAN translation
VLAN tags in a LAN often identify separate logical broadcast domains, for
example, a workgroup. However, carriers are expected to support multiple
enterprise networks on the same infrastructure and yet still preserve each
LANs VLAN schema. Manipulation of VLAN tags is therefore very useful.
For example, in a Multi-Tenant unit (MTU) environment, such as an office

building with different subscribers, one switch may connect several subscriber
networks in the building. Although each group is associated with a different
physical port, care must be taken so that broadcast traffic is not exchanged
between subscribers.
In an MTU environment, subscribers define their own VLAN schema, which

may or may not be different from the carrier network or even other subscribers.
VLAN translation can be used to remap or swap one VLAN ID with another
VLAN ID.
VLAN translation is configured with port, VID, and VLAN entry which must
exist as port members of the local VLAN. On ingress, VLAN translation looks
up the frames outer VID and maps the VID to the local VLAN. This local VLAN
becomes the switching domain. On egress, VLAN translation looks up the
local VLAN and marks the associated VID in the frame.
Note: MAC learning is performed on the local VLAN.
VLAN translation can not be configured for:

A remote management VLAN
A VLAN in use by an Ethernet Virtual Circuit
A VLAN that is a member of a multicast service
A reserved VLAN
Ports that are virtual switch members
Table 8-3 shows the number of VLAN translation entries supported per
platform.
Table 8-3
Supported VLAN Translation Entries
Platform Entries Supported
3940 1000
3916, 3930, 3931, 3932, 3960, 4096

5142, 5150, 5160

8-6 VLAN management
Table 8-4 lists several features related to VLAN functionality and the support
provided for VLAN translation.
Table 8-4
Feature Support in VLAN Translation
Feature Support
Remote Management VLAN Not supported.
PVID Not supported.
Port untagged Not supported.
Egress untagged VLAN Not supported.
Broadcast Containment Supported. However, classification is based on the raw frame VID,
not the translated VID.
IGMP/Multicast services Supported.
CFM/Y.1731 Not supported.
Link aggregation Supported on 3960 and 5150. Supported with a separate entry per
physical port in the link aggregation group on 3940 and 5140
platforms.
DHCP Relay Supported. DHCP relay can be enabled on the local VLAN with
VLAN translation entries. DHCP frames are edited according to the
correct VIDs.
This chapter provides the following procedures for VLAN management:

Changing the TPID stamp for a VLAN on page 8-7
Configuring a VLAN/port pair to ingress tagged traffic and egress tagged
traffic on page 8-8
Configuring a VLAN/port pair to ingress untagged traffic and egress
untagged traffic on page 8-10
Changing tag status on page 8-11
Configuring hybrid traffic on page 8-13
Emulating a tagged Ethernet port on page 8-14
Translating a single NNI VLAN on page 8-15
Translating a dual NNI VLAN on page 8-17

VLAN management 8-7
Procedure 8-1
Changing the TPID stamp for a VLAN
By default, the outer Tag Protocol Identifier (TPID) of frames egressing a
member port is stamped with a value of 8100. This setting can be changed
per VLAN to 88a8 or 9100 or back to the default of 8100.
Step Action
1 Change the TPID stamp for a VLAN:

vlan set vlan <Vlan> egress-tpid <8100|9100|88A8>
where
vlan <Vlan> is the VLAN.
2 Set the VLAN Ethernet policy to vlan-tpid for the port on the VLAN where the
packets egress:
virtual-circuit ethernet set port <PortNameList> vlan-
ethertype-policy vlan-tpid
where
port is the port on the VLAN where the packages egress.
<PortNameList>
end

8-8 VLAN management
Procedure 8-2
Configuring a VLAN/port pair to ingress tagged traffic
and egress tagged traffic
This scenario is the default behavior for the device. The only requirement is to
add the ingress and egress ports to the same VLAN. Since the EUV and the
PVID are set to VLAN 1 by default, tagged frames enter the switch and egress
the switch with their original tag intact for the VLAN configured.
Note: By default, all ports are members of VLAN 1. Frames tagged with
VLAN 1 are also forwarded since the PVID is set to VLAN 1 by default and
is not changed in this example.
Step Action
1 Create the VLAN.

vlan create vlan <VlanList> [name <String[31]>]
where
vlan <VlanList> is the numeric VLAN ID or IDs to create. You can specify
one, a list, or a range.
name is an optional name. This parameter applies if you are
<String[31]> creating one VLAN.
2 Add the ingress and egress ports to the VLAN.

vlan add vlan <VlanList> port <PortNameList>} [tag
{<value> | none}]
3 To verify the creation of the VLAN, enter the following command:
vlan show [port <PortNameList> | vlan <VlanList>]
end

VLAN management 8-9
Example
The following example configures a port pair that receives frames tagged with
VLAN 300 and egresses them with the original tag intact.

vlan add vlan 300 port 1,5
vlan show vlan 300
+---------------------- VLAN INFO -----------------------+

+----------------------+---------------------------------+
| VLAN ID | 300 |
| Name | VLAN#300 |
| Features | |
|--------------------------------------------------------+
| VLAN Members |
| Port | VTag | VS-Sub |
|----------+-----------+---------------------------------+
| 1 | 300 | False |
| 5 | 300 | False |
|----------+-----------+---------------------------------+

8-10 VLAN management
Procedure 8-3
Configuring a VLAN/port pair to ingress untagged
traffic and egress untagged traffic
This scenario configures a port pair on a VLAN that receives untagged frames
and egress them untagged:
Step Action
1 Create the VLAN.

where

vlan add vlan <VlanList> port <PortNameList>
3 Set the AFT on all ports to All.
port set port <PortNameList> [acceptable-frame-type
<'all' | 'tagged-only'>]
4 Set the PVID on all ports to the VLAN used in Step 2. This command is used
with ports not associated with a virtual switch. When the PVID is set, the
egress untagged VLAN is automatically set to the same value as the PVID.
port set port <PortNameList> [pvid <VlanList>]
end
Example
The following example configures a VLAN port pair.

port set port 1,5 acceptable-frame-type all
port set port 1,5 pvid 300

VLAN management 8-11
Procedure 8-4
Changing tag status
In this port pair scenario, traffic for the specified VLAN enters one port
untagged and egresses its partner port tagged with a specified VLAN ID and
802.1.1d priority. When traffic flows in the opposite direction, frames tagged
with the specified VLAN and 802.1d priority will egress untagged.
Step Action
1 Create a VLAN.
where
Add the ingress and egress ports to the VLAN.

2 Set the PVID on the ingress ports to the VLAN used in Step 2.
3 To set the ingress fixed .1d priority on the port, enter the following command:
port set port port <PortNameList> [fixed-rcos <NUMBER: 0-
7>]
4 Set the AFT on all ports to All.
5 Set the EUV on the egress port (provider port) to a VLAN that is different than
the VLAN used in Step 2.
port set port <PortNameList> [egress-untag-vlan
<VlanList>]
end
Example
In our example, untagged frames ingressing on port 1 will egress port 5
tagged with a VLAN ID of 300 and 802.1d priority of 5. Frames that ingress on
port 5 with a VLAN tag of 300 and 802.1d priority of 5 will egress port 1
untagged.

Assume now that port 1 is connected to the subscriber while port 5 connects
to the provider network, the frame will pass between the subscriber and the
provider networks, but the VLAN tag of 300 and 802.1d priority of 5, which
may only have meaning in the provider network, will never be seen in the
customers network.

port set port 1 pvid 300
port set port 1 fixed-rcos 5
port set port 5 egress-untag-vlan 4094

Procedure 8-5
Configuring hybrid traffic
This scenario configures a port pair that will receive either tagged or untagged
frames. Tagged frames will egress with their original tag intact and untagged
frames will egress untagged.
Step Action
1 Create a VLAN.
where

vlan add vlan <VlanList> port <PortNameList> [tag
{<value> | none}]
3 Set the AFT on the ingress ports to All.
4 Set the PVID on the ingress ports to VLAN 1 (this is the default setting).
5 Set the EUV on the egress ports to VLAN 1 (this is the default setting).
<VlanList>]
end
Example
In this example, any traffic tagged with VLAN 300 enters the switch tagged
and leaves the switch still tagged with VLAN 300, while untagged traffic enters
untagged and leave untagged.

port set port 1 pvid 1
port set port 5 egress-untag-vlan 1

Procedure 8-6
Emulating a tagged Ethernet port
Emulate the standard behavior of a tagged Ethernet port. Standard tagged
Ethernet ports accept tagged frames and drop all untagged frames. To drop
frames that are tagged with a VLAN to which the ingress port does not belong,
do not disable VLAN Ingress Filtering.
Step Action
1 Create a VLAN.
where

{<value> | none}]
3 Set the AFT on the ports to Tagged-Only.
4 Disable Ingress VLAN Filtering on the ports. Disable VLAN Ingress Filtering
only if the ingress port is not a member of the tagged frames VLAN.
port set <PortNameList> [vlan-ingress-filter <'on' |
'off'>]
5 Set the EUV on the ports to the VLAN used in Step 2
<VlanList>]
end
Example
In the following example, VLAN filtering is disabled, allowing all tagged frames
to ingress if the VLAN they are tagged with has been configured on the device.
Frames that are tagged with a VLAN ID of 300 egress untagged.

port set port 1,5 acceptable-frame-type tagged-only
port set port 1,5 vlan-ingress-filter off
port set port 1,5 egress-untag-vlan 300

Procedure 8-7
Translating a single NNI VLAN
Translate a single NNI VLAN.
Step Action
1 Create a VLAN.
vlan create vlan <VlanList> [name <String[31]>]]
where

{<value> | none}]
3 Add the translation entry to map the local VLAN to the VID on egress.
vlan translate add port <PortNameList> vid <VID> vlan
<VlanList>
where
port is the egress port
<PortNameList>
vid <VlanList> is the VID to map to on egress
vlan <VlanList> is the local VLAN
4 Verify the configuration.

vlan translate show
end
Example
In the configuration shown in Figure 8-1, Port 9 and Port 12 are members of
local VLAN 1000. A VLAN translation entry maps Port 12 and VLAN 1000 to
VID 555. When a packet arrives at Port 9 with VID 1000 it is mapped directly
to local VLAN 1000, and then to VID 555. When a packet arrives at Port 12
with VID 555, it is mapped to local VLAN 1000.

Figure 8-1
Single NNI VLAN Translation
VLAN 1000
Port 12
Port 9 VID 555
VID 1000
The following example creates the configuration.

vlan add vlan 1000 port 9.12
vlan translate add port 12 vid 555 vlan 1000
vlan translate show
+-------------------------- VLAN TRANSLATE TABLE -------------------------+

| | Ingress | Egress | |
| | Frame | Swap-Internal | Internal | Swap-Frame | |
| Port | VID | VLAN | VLAN | VID | |
+-------------+--------+---------------+----------+------------+----------+
| 12 | 555 | 1000 | 1000 | 555 | |
+-------------+--------+---------------+----------+------------+----------+

Procedure 8-8
Translating a dual NNI VLAN
Translate a dual NNI VLAN.
Step Action
1 Create a VLAN.
vlan create vlan <VlanList> [name <String[31]>]]
where

{<value> | none}]
3 Add the translation entry to map the local VLAN to the first VID on egress.
<VlanList>
where
<PortNameList>
4 Add the translation entry to map the local VLAN to the second VID on egress.
<VlanList>
where
<PortNameList>
5 Verify the configuration.

vlan translate show
end

Example
In the configuration shown in Figure 8-2, Port 9 and Port 12 are members of
local VLAN 1000. A VLAN translation entry maps Port 12 and VLAN 1000 to
VID 555. Another maps Port 9 and VLAN 1000 to VID 888. When a packet
arrives at Port 9 with VID 888 it is mapped to local VLAN 1000 and then to VID
555. Likewise, when a packet arrives at Port 12 with VID 555, it is mapped to
local VLAN 1000 and then to VID 555.
Figure 8-2
Dual NNI VLAN Translation
VLAN 1000
Port 9
VID 888 Port 12
VID 555

vlan translate show
+------------------------- VLAN TRANSLATE TABLE --------------------------+

| | Ingress | Egress | |
| | Frame | Swap-Internal | Internal | Swap-Frame | |
| Port | VID | VLAN | VLAN | VID | |
+-------------+--------+---------------+----------+------------+----------+
| 9 | 888 | 1000 | 1000 | 888 | |
| 12 | 555 | 1000 | 1000 | 555 | |
+-------------+--------+---------------+----------+------------+----------+

9-1
IP management 9-
This chapter shows the commands for configuring static IP routing. 39xx/51xx
switches support IPv4 and IPv6.
Note 1: To configure and run IP static routing, you need to install the
Advanced-OAM license key. To obtain the Advanced-OAM license key,
contact Ciena Sales.
Note 2: For an example of configuring Static IP routing to support RFC
2544 benchmark testing refer to 009-3220-009, SAOS 6.11 Fault and
Performance Management.
Static IP routing comprises the following components:
IP Interfaces, which enables IP packet sending and receiving.
IP Loopback, which enables IP packets to ingress and egress over the
same interface.
Static IP routes, which defines static IP routes.
Forward Information Base (FIB), which stores static route and forwarding
information.
Static Address Resolution Protocol routes, which defines ARP static
routes.
Adjacency Information Base (AIB), which stores ARP static route and
adjacency information.
IPv6
IPv6 is the successor to IPv4. IPv6 provides a larger address space and
greater flexibility when assigning addresses.
IPv6 address format

IPv6 addresses have the following characteristics:
Addresses are 128-bits in length and are written as eight groups of 4
hexadecimal digits. For example:
0001:0002:0003:0004:0005:0006:0007:0008
Fields are separated by colons (:)

9-2 IP management
Numeric field values are 0-FFFF

Two colons together (::) can be used as a shorthand to represent some
number of all-zeros hexadecimal fields. The doubled colon can appear at
the beginning, the middle, or at the end of the address. Only one pair of
doubled colons can be used in an address. For example: ::1 or f:: are both
valid addresses.
Port numbers are added to IPv6 addresses by enclosing the IP address in
square brackets and then a colon followed by the port number. Because
square brackets can be interpreted as regular expressions, the IP address
and port number are enclosed in double quotes.
Ciena platforms accept most address forms called out in RFC4291, and emit
only address forms called out in RFC5952, but (per this RFC section 4.2.2)
Ciena platforms do not accept a double-colon that does not compress away
more than 16 bits of address, that is, 1:2:3:4:5:6::8 is not legal.
IP address usage
On an IPv6-enabled network, each network element can have multiple
multicast, anycast, and unicast addresses. IPv6 is most secure when used in
a unicast deployment, that is, one host to another host. Multicast and anycast
use one-to-many connections and are not recommended in a secure
environment.

IP management 9-3
Table 9-1 summarizes IPv6 address types.
Table 9-1
IPv6 address types and IPv4 equivalent
IPv6 name Description IPv4 equivalent Description
Anycast One-to-nearest. Uses Global Unique protocols in Addresses are

Unicast Addresses. Routers IPv4, for example, indistinguishable from a
only. Discovery uses. IGMP. normal unicast address.
Anycast (router-to-router) is
also used with IPv4
addresses, specifically with
DNS root servers, though
there may be other
instances.
Global Unicast Globally unique. Fully Global IP address IPv6 and IPv4 similar but
routable. Assigned by IANA/ IPv6 can have other scoped
Regional Internet Registries addresses.
(RIRs).
Link-Local Local LAN only. No real equivalent. Scoped address concept

Automatically assigned Assigned IPv4 over new to IPv6. Multicast may
based on MAC. Cannot be ARP'd MAC. also be scoped to link-local
routed outside local LAN. (RFC 4489).
Scoped address concept
new to IPv6. Multicast can
also be scoped to link.
Loopback Local interface scope. Same as IPv4 127.0.0.1 Same function
Multicast One-to-many. Hierarchy of Similar to IPv4 Class D Significantly more powerful

multicasting. than IPv4 version. No
broadcast in IPv6, replaced
by multicast. Multicast may
also be scoped to link-local
(RFC 4489).
Site-Local Optional. Local Site only. Private network address Scoped address concept
Cannot be routed over with multi-homed new to IPv6. Unlike the IPv4
Internet. Assigned by user. interface is closest private network address the
equivalent. IPv6 device can have, Link-
Local, Site-Local and a
Global Unicast address.
Site-Local while continuing
to exist in the IPv6
specification is currently not
supported.

9-4 IP management
IPv6 architecture allows an interface to have multiple addresses, for example,

link-local or global. 39xx/51xx switches also support IPv6 and IPv4
addresses. The rules for selecting the address to use in a particular situation
are the following:
Address pairs of the same scope or type (link-local, global) are preferred.
A smaller scope for the Destination address is preferred, that is, use the
smallest scope possible.
A non-deprecated address is preferred.
Transitional addresses, that is, IPv6 to IPv4 addresses, are not used if
native IPv6 addresses are available.
If all criteria are similar, address pairs with the longest common prefix are
preferred.
For source addresses, global addresses are preferred over temporary
addresses.
The attribute interface when adding a gateway is only required if the
gateway address is an IPv6 link-local address.
Each interface can have multiple IPv6 addresses in addition to the IPv4
addresses. 39xx/51xx switches support the use of up to 16 IPv6 addresses
per interface.
This chapter provides the following procedures for IP management:

Creating interfaces on page 9-11
Deleting an IP or loopback interface on page 9-14
Modifying an IP or loopback interface on page 9-15
Disabling an IP interface on page 9-16
Enabling an IP interface on page 9-17
Configuring IPv6 interfaces manually on page 9-18
Displaying an IP interface on page 9-20
Adding an IP route on page 9-24
Removing an IP route on page 9-25
Displaying the routing table on page 9-26
Displaying FIB entries on page 9-27
Enabling Layer 3 switching on page 9-29
Disabling Layer 3 switching on page 9-30
Adding a static ARP entry on page 9-35
Removing static ARP entries on page 9-36

IP management 9-5
Displaying static ARP entries on page 9-60

Displaying the AIB table on page 9-61
EVC ping
EVC ping is used by network operators to test connectivity through end-to-end
networks through an Ethernet Virtual Connection (EVC). Network operators
can initiate a ping of the remote EVC endpoint (NTE-2) before scheduling
deployment and testing of new equipment. EVC ping is configured using IP
interface and virtual switch members.
EVC ping can be used for EVPL and EPL services in IPv4-based and IPv6-
based networks.
When EVC ping is enabled, the NTE must be configured with an IP interface
whose IP address is coordinated with the network operator. Each IP interface
must be in its own subnet, and must not already be configured on the NTE.
Frames with any DSCP priority are accepted: frame treatment is subject to the
provisioned SLAs in the network. No special priority is given to this ping traffic.
Figure 9-1 and Figure 9-2 show EVC ping in the end-to-end network.
Figure 9-1
EVC ping in the end-to-end IPv4 network
(configured IP i/f)
IP: 192.0.2.4
(configured IP i/f)
IP: 192.0.2.1
(configured IP i/f)
IP: 10.10.10.3
IP: 10.10.10.1 IP: 10.10.10.2
UNI NNI NNI UNI
P P
CPE-1 E MPLS/ E CPE-2
NTE-1 VPLS NTE-2
(hub) P2
- - P3 P4
(spoke)
P1
1 2
Service #1
Service #2
Scenario 1 Ping 10.10.10.3

9-6 IP management
Figure 9-2
EVC ping in the end-to-end IPv6 network
Table 9-2 lists EVC ping use cases. Port-based service can have tagged or
untagged traffic sent from the network operator. VLAN-based service must
have tagged traffic, coordinated with the network operator.
Table 9-2
EVC ping use cases
Use Service on NTE- Ping/ARP Service on NTE- VLAN tag stack Ping/ARP
case 1 (hub) packet on NTE-1 2 (spoke) depth at NTE-2 packet on NTE-2
UNI NNI UNI
A port-based tagged port-based 2 tagged
B port-based untagged port-based 1 untagged
C VLAN-based tagged port-based 1 untagged
D port-based untagged VLAN-based 2 tagged
E VLAN-based tagged VLAN-based 2 tagged
EVC ping can be configured for

Use case A: virtual switch with EPL to IP interface with virtual switch
member
Use case B: virtual switch with EPL and untagged data virtual switch to IP
interface with VLAN
Use case C: virtual switch with EVPL to IP interface with VLAN

IP management 9-7
Use case D: virtual switch with EPL and untagged data virtual switch to IP
interface with virtual switch member
Use case E: virtual switch with EVPL to IP interface with virtual switch
member
Figure 9-3 shows EVC ping use cases.
Figure 9-3
EVC ping use cases
This chapter provides the following procedures for EVC ping:

Configuring EVC ping for use case A on page 9-37
Configuring EVC ping for use case B on page 9-42
Configuring EVC ping for use case C on page 9-46
Configuring EVC ping for use case D on page 9-50
Configuring EVC ping for use case E on page 9-55
Local EVC ping

A local EVC interface ping is an ICMP request and reply stream between an
external device connected by means of membership in an EPL or EVPL virtual
switch. The ip-interface that responds is located at the nearest EPL or EVPL
member access to the virtual switch. For a remote EVC interface ping request,
the ip-interface that responds is located at the far-end EPL or EVPL member
access to the virtual switch.
Figure 9-4 and Figure 9-5 show local and remote EVC ping in IPv4 and IPv6
networks.

9-8 IP management
Figure 9-4
Local and remote EVC ping in an IPv4 network
(configured IP i/f)
IP: 192.0.2.1 (configured IP i/f)
IP: 192.0.2.4
(configured IP i/f)
IP: 10.10.10.1 (configured IP i/f)
IP: 10.10.10.4
IP: 10.10.10.1 IP: 10.10.10.2
UNI NNI NNI UNI
P P
NTE-1 VPLS NTE-2
(hub) P2
- - P3 P4
(spoke)
P1
1 2
Service #1
Service #2
C-Tag S-Tag
Case A EPL EPL
Remote NTE-2 Ping 10.10.10.3
Local NTE-2 Ping 10.10.10.3
Local NTE-1 Ping 10.10.10.1
Ping 10.10.10.3
Remote NTE-1
Figure 9-5
Local and remote EVC ping in an IPv6 network

IP management 9-9
Local EVC interface ping and remote interface EVC ping are handled
differently when the IP interface pinged is configured as an SVLAN interface
or a virtual switch member interface, that is, double-tagged.
When the virtual switch member is used as EPL, the virtual switch member
can require the following configuration on the UNI port to ensure proper
datapath and VLAN flooding domain:
untagged-data-vs, which is used when untagged traffic is used into a
virtual switch.
untagged-data-vid, which is used when untagged traffic is used in to a
virtual switch and a specific ip-interface can be requested to be the
recipient of the ICMP traffic.
Table 9-3 summarizes EVC ping from a local virtual switch member with
SVLAN ip-interface.
Table 9-3
EVC ping from local virtual switch member with SVLAN ip-interface
Use case Default port untagged-data-vs Explanation

configuration configured
Untagged traffic No replies to ARP and ARP and ICMP traffic When untagged-data-vs
ICMP traffic are replied to normally is set, the traffic is
accepted and replied by
the SVLAN ip-interface.
Normal tagged traffic No replies to ARP and No replies to ARP and The CVID traffic is not
any CVID ICMP traffic ICMP traffic matched to the ip-
interface.
Single tagged traffic with No replies to ARP and No replies to ARP and On 3960, ARP and
CVID equal to SVLAN of ICMP traffic ICMP traffic ICMP traffic are replied
ip-interface untagged.
Note: Do not use
matching CVID and
SVID on 3960.
Double tagged traffic No replies to ARP and No replies to ARP and On 3960, traffic is
with CVID equal to ICMP traffic ICMP traffic replied with the CVID of
SVLAN of ip-interface the packet equal to the
SVLAN of the ip-
interface.
Note: Do not use
matching CVID SVID on
3960.

9-10 IP management
Table 9-4 summarizes EVC ping from local virtual switch member with virtual
switch member ip-interface.
Table 9-4
EVC ping from local virtual switch member with virtual switch member ip-interface
Use case Default port untagged-data-vs Explanation

configuration configured
Untagged traffic ARP and ICMP traffic ARP and ICMP traffic When untagged-data-vs
are replied to normally are replied to normally and untagged-data-vid
are set, the traffic is
accepted and replied by
the virtual switch
member ip-interface.
Normal tagged traffic No replies to ARP and No replies to ARP and The CVID traffic is not
any CVID ICMP traffic ICMP traffic matched to the ip-
interface.
Single tagged traffic with No replies to ARP and No replies to ARP and On 3960, ARP and
CVID equal to SVLAN of ICMP traffic ICMP traffic ICMP traffic are replied
ip-interface untagged.
Note: Do not use
matching CVID and
SVID on 3960.
Note: Inserting Static ARP Entries can lead to undesired behavior of

ICMP traffic. Do not use static ARP entries in an EVC ping testing
environment.

IP management 9-11
Procedure 9-1
Creating interfaces
You can create an:
IP interface
loopback interface
Create an IP interface to enable the sending and receiving of Layer 3 traffic.
Create a loopback interface when you need the Layer 3 traffic to ingress and
egress from the same interface.
Note 1: The IP address and subnet mask for an IP interface cannot define
a subnet that is already in use by a local or remote interface.
Note 2: In SAOS 6.10.2 the ip-forwarding setting is truncated and is not
saved in the configuration file. Any SAOS 6.10.2 interfaces with ip-
forwarding set to on will have ip-forwarding set to off in the configuration
file.

9-12 IP management
Step Action
To create an IP interface
1 Create an IP interface.
interface create ip-interface <ip-interface> {ip <IP
address with mask>} [vlan <VLAN>] [mtu <NUMBER: 1500-
9216>] [mac <MAC address: XX:XX:XX:XX:XX:XX>]
[ip-forwarding <on|off>] [service-mac <benchmark | local-
mgmt | remote-mgmt>]
where
ip-interface <ip- is a 15-character string to identify the interface. The
interface> following characters cannot be used:
!

%
,
/
?
:
ip <IP address is the IP address with mask.
with mask>
vlan <VLAN> is the VLAN ID for this interface (port service). The VLAN is
optional. When this occurs the ip-interface will obtain its L2
mapping through the use of virtual-switch member
configuration.
[mtu <NUMBER: is the interface MTU.
1500-9216>]
[mac <MAC is the MAC address.
address:
XX:XX:XX:XX:XX
:XX>]
ip-forwarding determines whether IP forwarding is on or off. The default
<on|off> value is off.
service-mac is the service name associated with the MAC address.
<benchmark | Alternate way of specifying the MAC address.
local-mgmt |
remote-mgmt>]

IP management 9-13
To create a loopback interface

2 Create a loopback interface:
interface create loopback <loopback> {ip <IP address>}
where
loopback is the loopback interface name.
<loopback>
ip <IP address> is the interface IP address.
end

9-14 IP management
Procedure 9-2
Deleting an IP or loopback interface
Delete an IP or loopback interface when it is no longer required.
Step Action
1 Delete an IP or loopback interface:

interface delete ip-interface <ip-interface>
where
ip-interface <ip- is the name of the interface to be deleted.
interface>
end

IP management 9-15
Procedure 9-3
Modifying an IP or loopback interface
Modify an IP or loopback interface to change the setting, for example, to
increase the maximum frame size to allow bigger frames.
Step Action
1 Modify an IP or loopback interface:

interface set ip-interface <Interface> {[ip <IpAddress>],
[ip-forwarding <on|off>], [mtu <1500-9216>]}
where
ip-interface is the IP or loopback interface to be modified.
<Interface>
ip <IpAddress> is the IP address.
ip forwarding determines whether IP forwarding is on or off. The default
<on|off> value is off.
mtu <1500- is the maximum transmission unit in bytes (maximum frame
9216> size). The default value is 1500.
end

9-16 IP management
Procedure 9-4
Disabling an IP interface
Disable an IP interface.
Step Action
1 Disable an IP interface:
interface disable ip-interface <Interface>
where
<Interface> is the IP interface to be disabled.
end

IP management 9-17
Procedure 9-5
Enabling an IP interface
Enable an IP Interface.
Step Action
1 Enable an IP interface:
interface enable ip-interface <Interface>
where
<Interface> is the IP interface to be enabled.
end

9-18 IP management
Procedure 9-6
Configuring IPv6 interfaces manually
Manually configure IPv6 interfaces.
Step Action
To add the local interface IPv6 address and subnet mask

1 Add the local interface IPv6 address and subnet mask:
interface local add ip <ip>
where
ip <ip> is the IPv6 address of interface.
To remove the local interface IPv6 address and subnet mask

2 Remove the local interface IPv6 address and subnet mask:
interface local remove ip <ip>
where
To add the remote interface IPv6 address and subnet mask

3 Add the remote interface IPv6 address and subnet mask:
interface remote add ip <ip>
where
To remove the remote interface IPv6 address and subnet mask

4 Remove the remote interface IPv6 address and subnet mask:
interface remote remove ip <ip>
where

IP management 9-19
To add an IPv6 gateway address

5 Add an IPv6 gateway address:
interface add { [gateway <gateway>] [interface
<local|remote>] }
where
gateway is the IPv6 gateway to be added.
<gateway> It is best practice to use the link-local address of the router
(starting with FE80::) as a gateway rather than the global
address of the router, as this allows ICMPv6 type 137
redirect messages to work correctly, thus enhancing
network reachability.
interface is the management interface.
<local|remote>
To remove an IPv6 gateway address

6 Remove an IPv6 gateway address:
interface remove { [gateway <gateway>] [interface
<local|remote>] }
where
gateway is the IPv6 gateway to be added.
<gateway>
interface is the management interface.
<local|remote>
end

9-20 IP management
Procedure 9-7
Displaying an IP interface
Display an IP interface to verify the configuration.
The Interface show command shows only operational addresses. The

Interface Management Table includes local, remote and IP interfaces. IP
interfaces are only IPv4 supported. Local and remote interfaces support both
IPv4 and IPv6.
The interface show command for local and remote interfaces displays the
source of configuration of the specified IP address, as shown in Table 9-5.
Table 9-5
Source of configuration of the specified IP address
Source Description
Manual Specifies configuration by user
SLAAC Configured with Stateless Auto configuration through

Router Advertisement messages
DHCP Configured through DHCP Server
Local Local Addresses including Link Local Addresses
Step Action
To display IP interfaces
1 Display IP interfaces:
interface show
To display local IP interfaces
2 Display local IP interfaces:
interface local show
To display remote IP interfaces
3 Display remote IP interfaces:
interface remote show

IP management 9-21
To display an IP interface
4 Display an IP interface:
interface show [ip-interface <Interface>]
where
<Interface> is the IP interface to be displayed.
end
Example
The following example shows sample output for the interface show command.
interface show
+----------------------------------- INTERFACE MANAGEMENT ------------------------------+
| Name | Management | IP Address/Prefix |
| | Domain | |
+---------------------+--------------------+--------------------------------------------+
| local | VLAN 0 | 10.1.29.255/21 |
| local | VLAN 0 | fdbf:bc21:b16a:1123:2021:5aff:fe01:b910/64 |
| local | VLAN 0 | fe80::202:5aff:fe01:b910/64 |
| remote | VLAN 123 | 10.2.29.253/21 |
| remote | VLAN 123 | fe80::202:5aff:fe01:b91f/64 |
| fred | VS Abcde67890abcde | 5.5.5.1/24 |
+---------------------+--------------------+--------------------------------------------+
+-------------- TCP/IP/STACK OPERATIONAL STATE ---------------+

+---------------------+---------------------------------------+
| IPv4 Gateway | 10.1.24.1 |
| IPv6 Gateway | fe80::214:22ff:fe73:3987 |
| IPv4 Forwarding | Off |
| Default DSCP | 0 |
+---------------------+---------------------------------------+
Note that fe80::202:5aff:fe01:b910/64 and fe80::202:5aff:fe01:b91f/64 are

link-local addresses. Link-local addresses are partially derived from the
chassis MAC address of the switch and are not routable outside of the local
network.
The following example shows sample output for the interface local show
command.
interface local show
+-------- INTERFACE OPERATIONAL STATE --------+

+---------------------+-----------------------+
| Name | local |
| Index | 2 |

9-22 IP management
| MAC Address | 00:02:5a:01:b9:10 |

| Management Domain | VLAN 0 |
| Priority | 0 |
| MTU | 1500 |
+---------------------+-----------------------+
+------------------------- ADMIN INTERFACE ADDRESSES --------------------------+

+---------------------+--------------------------------------------------------+
| IPv4 Addr/Mask | 10.1.30.254/21 |
| IPv6 Addr/Mask | 2001:1234:f00d:cafe:1111:1202:1001:1111/64 |
+---------------------+--------------------------------------------------------+
+---------------------- OPERATIONAL INTERFACE ADDRESSES -----------------------+

| Parameter | Value | Source |
+---------------------+---------------------------------------------+----------+
| IPv4 Addr/Mask | 10.1.30.7/21 | DHCP |
| IPv4 Broadcast Addr | 10.1.31.255 | |
| IPv6 Addr/Mask | 2001:1234:f00d:cafe:1111:1202:1001:1111/64 | Manual |
| | fe80::202:5aff:fe01:b990/64 | Local |
+---------------------+---------------------------------------------+----------+
The following example shows sample output for the interface remote show
command.
+-------- INTERFACE OPERATIONAL STATE --------+

+---------------------+-----------------------+
| Name | remote |
| Index | 15 |
| MAC Address | 00:02:5a:01:b9:1f |
| Management Domain | VLAN 123 |
| Priority | 7 |
| MTU | 1500 |
+---------------------+-----------------------+
+------------------------- ADMIN INTERFACE ADDRESSES --------------------------+

+---------------------+--------------------------------------------------------+
| IPv4 Addr/Mask | Not configured |
| IPv6 Addr/Mask | Not configured |
+---------------------+--------------------------------------------------------+
+---------------------- OPERATIONAL INTERFACE ADDRESSES -----------------------+

| Parameter | Value | Source |
+---------------------+---------------------------------------------+----------+
| IPv6 Addr/Mask | fe80::202:5aff:fe01:b91f/64 | Local |
+---------------------+---------------------------------------------+----------+

IP management 9-23
The following example shows sample output for the show ip-interface
command.
interface show ip-interface
+------------------------------- IP INTERFACE TABLE -----------------------------+

| Name | State | Management | MTU | IP Address/Prefix |
| |Adm |Oper| Domain | | |
+---------------------+----+----+--------------------+------+--------------------+
| joe |Ena |Dis | VLAN 100 | 1500 | 19.34.34.1/21 |
| fred |Ena |Ena | VS Abcde67890abcde | 1500 | 5.5.5.1/24 |
+---------------------+----+----+--------------------+------+--------------------+

9-24 IP management
Procedure 9-8
Adding an IP route
Add an IP route.
Step Action
1 Add an IP route:
ip route add {destination <IpAddressWithMask>} {gateway
<IpAddress>} [metric <#>] [domain-name <routing-domain-
name>]
where
destination is the destination route IP address in CIDR notation.
<IpAddressWith
Mask>
gateway is the gateway IP address for the associated IP or loopback
<IpAddress> interface.
metric <#> is the interface route cost metric. The default value is 0.
[domain-name is the routing domain.
<routing-domain-
name>]
end
Example
The following example adds an IP route with a destination IP address of
5.5.5.0/24, a gateway address of 6.6.6.6, and an interface route cost metric of
10.
ip route add destination 5.5.5.0/24 gateway 6.6.6.6 metric 10

IP management 9-25
Procedure 9-9
Removing an IP route
Remove an IP route when the IP route is no longer needed.
Step Action
1 Remove an IP route:
ip route remove [destination <IpAddressWithMask>],
[gateway <IpAddress>], |[metric <#>] [domain-name
<routing-domain-name>]
where
destination is the destination route IP address in CIDR notation.
<IpAddressWith
Mask>
gateway is the gateway IP address for the associated IP or loopback
<IpAddress> interface.
metric <#> is the interface route cost metric. The default value is 0.
<routing-domain-
name>]
end
Example
The following example removes a static IP route with a destination IP address
of 5.5.5.0/24, a gateway address of 6.6.6.6, and an interface route cost metric
of 10.
ip route remove destination 5.5.5.0/24 gateway 6.6.6.6 metric 10

9-26 IP management
Procedure 9-10
Displaying the routing table
Display the routing table to verify configuration.
Step Action
1 Display the routing table:

ip route show [domain-name <routing-domain-name>]
where
<routing-domain-
name>]
end
Example
The following example shows sample output for the ip route show command.
> ip route show
+-------------------------------- ROUTING TABLE -------------------------------+
|Act| Destination | Gateway | Genmask |Metric |Intf|Prot|
+---+-----------------+-----------------+-----------------+----------+----+----+
| | 10.0.0.0 | 1.1.1.1 | 255.0.0.0 | 0 | 5 | Inv|
+---+-----------------+-----------------+-----------------+----------+----+----+

IP management 9-27
Procedure 9-11
Displaying FIB entries
After creating a static IP route, the forwarding information is stored in the FIB.
The summary view is displayed by default.
You can display:

the FIB entry for the default route
a summary of FIB entries
details for each FIB entry
end
Step Action
To display the FIB entry for the default route

1 Display the FIB entry for the default route:
ip fib show [destination <Ip Address with mask>] [default]
where
destination is the destination route IP address/mask.
<Ip Address with
mask>
[default] displays the default route, if any configured.
To display a summary of FIB entries

2 Display a summary of FIB entries:
ip fib show [destination <Ip Address with mask>][summary]
where
destination is the destination route IP address/mask.
<Ip Address with
mask>
[summary] displays summary.

9-28 IP management
To display details for each FIB entry

3 Display details for each FIB entry:
ip fib show [destination <Ip Address with Mask>][details]
[summary]
where
destination is the destination route IP address.
<Ip Address with
Mask>
[details] displays details.
end
Example
The following example shows sample output for the ip fib show command. The
summary view is displayed by default.
> ip fib show
+------------------+----------------+---+---+----+------+-----------+
| Destination/ | NexthopIp |oif|Act|Path|Entry |Path Cost |
| NetMaskLen | |Idx|ion|Type|Id | |
+------------------+----------------+---+---+----+------+-----------+
|1.1.1.0/24 |- |- |loc|IF |0 |0 |
|1.1.1.0/32 |- |- |loc|IF |0 |0 |
|1.1.1.1/32 |- |- |loc|IF |0 |0 |
|1.1.1.2/32 |1.1.1.2 |5 |loc|ADJ |0 |0 |
|1.1.1.255/32 |- |- |loc|IF |0 |0 |
+------------------+----------------+---+---+----+------+-----------+
| oif: Outgoing Interface |
| entryId: Internal Id from Route Module (=0 local) |
| Action: fwd: Forward, loc: Local, rej: Reject, bck: BlackHole |
| C: Conn, LC: LocalConn, DC: DirectlyConn, Sta: Static |
| PathType: I1I: Isis L1 Int, I2I: Isis L2 Int |
| I1E: Isis L1 Ext, I2E: Isis L2 Ext, OIA: Ospf IntraArea |
| OA: Ospf InterArea, O1E: Ospf Type1 Ext, O2E: Ospf Type2 Ext |
| IC: Icmp, Oth: Other, IF: Local Interface, ADJ: Adjacency |
| unk: Unknown |
+-------------------------------------------------------------------+

IP management 9-29
Procedure 9-12
Enabling Layer 3 switching
FIB Layer 3 switching is enabled by default. In order for static IP routing to
support layer 3 traffic, such as for RFC 2544 and MPLS, FIB Layer 3 switching
must be enabled.
Step Action
1 Enable Layer 3 switching:

ip fib l3-switching enable
end

9-30 IP management
Procedure 9-13
Disabling Layer 3 switching
Disable Layer 3 switching when MPLS and benchmarking are no longer
required.
Step Action
1 Disable Layer 3 switching:

ip fib l3-switching disable
end

IP management 9-31
Procedure 9-14
Displaying the status of Layer 3 switching
Display the status of Layer 3 switching to learn whether Layer 3 switching is
enabled or disabled.
Step Action
1 Display the status of Layer 3 switching:

ip fib l3-switching show
end
Example
The following example shows sample output of the ip fib l3-switching show
command.
> ip fib l3-switching show
L3-Switching Enabled

9-32 IP management
Procedure 9-15
Clearing all FIB or AIB entries
Clear all FIB or AIB entries as part of a clean up operation, or when
troubleshooting.
Step Action
To clear all FIB entries

1 Clear all FIB entries:
ip fib flush
To clear all AIB entries
2 Clear all AIB entries
ip aib flush
end

IP management 9-33
Procedure 9-16
Enabling logging of FIB or AIB events
Enable logging of FIB or AIB events for troubleshooting.
Step Action
To enable logging of FIB events

1 Enable logging of FIB events:
ip fib debug events on
To enable logging of AIB events
2 Enable logging of AIB events:
ip aib debug events on
end

9-34 IP management
Procedure 9-17
Displaying FIB information
Display FIB information for troubleshooting purposes. You can display the
following information for the FIB:
log
interfaces
interface IP addresses
static resolutions
Step Action
To display the FIB log

1 Display the FIB log:
ip fib log show
To display the FIB interfaces
2 Display the FIB interfaces:
ip fib interfaces show [summary] [details]
where
summary displays a summary of FIB information for interfaces.
details displays detailed FIB information for interfaces.
To display the FIB interface IP addresses

3 Display the FIB interface IP addresses:
ip fib interfaceIpAddresses show [summary] | [details]
where
summary displays a summary of FIB information for interface IP
addresses.
details displays detailed FIB information for interface IP addresses.
To display the FIB static resolutions

4 Display the FIB static resolutions:
ip fib staticResolutions show [summary] | [details]
where
summary displays a summary of FIB information for static resolutions.
details displays detailed FIB information for static resolutions.
end

IP management 9-35
Procedure 9-18
Adding a static ARP entry
ARP maps an IP address to a physical MAC address. Entries can be learned
dynamically, such as when a device sends an ARP request or ping, but for the
entries to be permanent, as in the case of using a device as a static reflector
for RFC 2544, you can add a static entry.
Step Action
1 Add a static ARP entry:

arp static add {destination <IpAddress>} {mac
<MacAddress>} {ip-interface <Interface>}
where
destination is the destination host IP address.
<IpAddress>
mac is the destination MAC address.
<MacAddress>
ip-interface is the IP interface routed to the destination.
<Interface>
end

9-36 IP management
Procedure 9-19
Removing static ARP entries
Remove static ARP entries when they are no longer needed. You can remove
one static ARP entry
all static ARP entries
Step Action
To remove a static ARP entry

1 Remove a static ARP entry.
arp static remove {destination <IpAddress>} {ip-interface
<Interface>}
where
destination is the destination host IP address.
<IpAddress>
ip-interface is the IP interface routed to the destination.
<Interface>
To remove all static ARP entries

2 Remove all static ARP entries.
arp static remove-all
end

IP management 9-37
Procedure 9-20
Configuring EVC ping for use case A
Configure EVC ping for a virtual switch with EPL to IP interface with virtual
switch member configuration.
Step Action
Configure NTE-1
1 Create the VLAN:
vlan create vlan <vlan>
2 Add a port to the VLAN:
vlan add vlan <vlan> port <port>
3 Create an Ethernet virtual circuit:
virtual-circuit ethernet create vc <vc> vlan <vlan>
4 Add a reserved VLAN:
virtual-switch add reserved-vlan <reserved-vlan>
5 Create an Ethernet virtual switch:
virtual-switch ethernet create vs <vs> vc <vc>
6 Add subscriber members to the virtual switch:
virtual-switch ethernet add vs <vs> {port <port>} {vlan
<VLAN list>} {ip-interface <interface-name>} {encap-cos-
policy <dot1dpri-inherit | fixed | ip-prec-inherit |
phbg-inherit | port-inherit | vs-inherit>} {encap-fixed-
dot1dpri <NUMBER: 0-7>} [statistics <on | off>]
[translate-tag <NUMBER: 0-4094>] {service-vlan-tpid <8100
| 9100 | 88A8>}
7 Create the IP interface for the virtual switch:
interface create ip-interface <ip-interface> ip <ip
address>/<subnet-mask> vlan <vlan>
Configure NTE-2
8 Create the VLAN:

9-38 IP management

| 9100 | 88A8>}
15 Create the IP interface:
address>/<subnet-mask>
| 9100 | 88A8>}
The ip-interface is operational.
end
Example
Figure 9-6 and Figure 9-7 show a sample virtual switch with EPL to IP
interface with virtual switch member configuration in an IPv4 and IPv6
network.

IP management 9-39
Figure 9-6
Use case A IPv4 configuration example
(configured IP i/f)
IP: 192.0.2.4
(configured IP i/f)
IP: 192.0.2.1
(configured IP i/f)
IP: 10.10.10.3
IP: 10.10.10.1 IP: 10.10.10.2
UNI NNI NNI UNI
P P
NTE-1 VPLS NTE-2
(hub) P2
- - P3 P4
(spoke)
P1
1 2
Service #1
Service #2
C-Tag S-Tag
Case A EPL EPL
To configure the example shown in Figure 9-6:
Configure NTE-1.
vlan create vlan 8

virtual-circuit ethernet create vc vc8 vlan 8
virtual-switch add reserved-vlan 4000
virtual-switch ethernet create vs vs8 vc vc8
virtual-switch ethernet add vs vs8 port 1
interface create ip-interface ipvs8 ip 192.0.2.1/24 vlan 8
Configure NTE-2.
vlan create vlan 8


9-40 IP management
interface create ip-interface ipvs8 ip 20.20.20.4/24 vlan

8
interface create ip-interface ip24 ip 10.10.10.3/24
virtual-switch ethernet add vs 8 ip-interface ip24 vlan 24
Figure 9-7
Use case A IPv6 configuration example
Configure NTE-1.
vlan create vlan 8

interface create ip-interface ipvs8 ip 2001::1/64 vlan 8
Configure NTE-2.
vlan create vlan 8


IP management 9-41

interface create ip-interface ip24 ip 1001::3/64
virtual-switch ethernet add vs 8 ip-interface ip24 vlan 24

9-42 IP management
Procedure 9-21
Configuring EVC ping for use case B
Configure EVC ping for a virtual switch with EPL and untagged data virtual
switch to IP interface with VLAN configuration.
Step Action
Configure NTE-1
1 Create the VLAN:
| 9100 | 88A8>}
7 Set the virtual switch for untagged data frames:
port set port <port> untagged-data-vs <vs>
Configure NTE-2
8 Create the VLAN:

IP management 9-43

| 9100 | 88A8>}
14 Create the IP interface for the virtual switch and EPL:
end
Example
Figure 9-8 and Figure 9-9 show a sample virtual switch with EPL and
untagged data virtual switch to IP interface with VLAN configuration in an IPv4
and IPv6 network.
Figure 9-8
Use case B IPv4 configuration example
(configured IP i/f)
IP: 10.10.10.3
IP: 10.10.10.1 IP: 10.10.10.2
UNI NNI NNI UNI
P P
NTE-1 VPLS NTE-2
(hub) P2
- - P3 P4
(spoke)
P1
1 2
Service #1
Service #2
Case B EPL EPL

Configure NTE-1.

9-44 IP management
vlan create vlan 8

port set port 1 untagged-data-vs vs8
Configure NTE-2.
vlan create vlan 8


8
Figure 9-9
Use case B IPv6 configuration example
Configure NTE-1.

IP management 9-45
vlan create vlan 8

port set port 1 untagged-data-vs vs8
Configure NTE-2.
vlan create vlan 8


9-46 IP management
Procedure 9-22
Configuring EVC ping for use case C
Configure EVC ping for a virtual switch with EVPL to IP interface with VLAN
configuration.
Step Action
Configure NTE-1
1 Create the VLAN:
6 Add subscriber members to the virtual switch (EVPL):
| 9100 | 88A8>}
Configure NTE-2
7 Create the VLAN:

IP management 9-47

| 9100 | 88A8>}
13 Create the IP interface for the virtual switch and EPL:
end
Example
Figure 9-10 and Figure 9-11 show a sample virtual switch with EVPL to IP
interface with VLAN configuration in an IPv4 and IPv6 network.
Figure 9-10
Use case C IPv4 configuration example
(configured IP i/f)
IP: 10.10.10.3
IP: 10.10.10.1 IP: 10.10.10.2
UNI NNI NNI UNI
P P
NTE-1 VPLS NTE-2
(hub) P2
- - P3 P4
(spoke)
P1
1 2
Service #1
Service #2
Case C EVPL EPL

Configure NTE-1.
vlan create vlan 8


9-48 IP management
virtual-switch ethernet add vs vs8 port 1 vlan 24

translate-tag 0
port set port 1 vs-l2-transform i-stamp:push,e-match-
pop:stamp
Configure NTE-2.
vlan create vlan 8


8
Figure 9-11
Use case C IPv6 configuration example
Configure NTE-1.
vlan create vlan 8


IP management 9-49

translate-tag 0
set port 1 vs-l2-transform i-stamp:push,e-match-pop:stamp
Configure NTE-2.
vlan create vlan 8


9-50 IP management
Procedure 9-23
Configuring EVC ping for use case D
Configure EVC ping for virtual switch with EPL and untagged data virtual
switch to IP interface with virtual switch member configuration.
Step Action
Configure NTE-1
1 Create the VLAN:
6 Set the virtual switch for untagged data frames and set push/pop for the
specified VLAN ID for untagged data frames:
port set port <port> untagged-data-vs <vs> untagged-data-
vid <vlan>
7 Create the ip-interface for the virtual switch:
interface ip create ip-interface <ip-interface> ip <ip
Configure NTE-2
8 Create the VLAN:

IP management 9-51

| 9100 | 88A8>}
| 9100 | 88A8>}
end
Example
Figure 9-12 shows a sample virtual switch with EPL and untagged data virtual
switch to IP interface with virtual switch member configuration in an IPv4 and
IPv6 network.

9-52 IP management
Figure 9-12
Use case D IPv4 configuration example
(configured IP i/f)
IP: 192.0.2.4
(configured IP i/f)
IP: 192.0.2.1
(configured IP i/f)
IP: 10.10.10.3
IP: 10.10.10.1 IP: 10.10.10.2
UNI NNI NNI UNI
P P
NTE-1 VPLS NTE-2
(hub) P2
- - P3 P4
(spoke)
P1
1 2
Service #1
Service #2
Case B EPL EVPL

Configure NTE-1.
vlan create vlan 8

port set port 1 untagged-data-vs vs8 untagged-data-vid 24
Configure NTE-2.
vlan create vlan 8


IP management 9-53

8
virtual-switch ethernet add vs vs8 ip-interface ip24 vlan
24
Figure 9-13
Use case D IPv6 configuration example
Configure NTE-1.
vlan create vlan 8

port set port 1 untagged-data-vs vs8 untagged-data-vid 24
Configure NTE-2.
vlan create vlan 8


9-54 IP management


24

IP management 9-55
Procedure 9-24
Configuring EVC ping for use case E
Configure EVC ping for virtual switch with EVPL to IP interface with virtual
switch member configuration.
Step Action
Configure NTE-1
1 Create the VLAN:
6 Add virtual switch member attributes:
| 9100 | 88A8>}
7 Create the ip-interface for the virtual switch:
Configure NTE-2
8 Create the VLAN:

9-56 IP management

| 9100 | 88A8>}
| 9100 | 88A8>}
end
Example
Figure 9-14 and show a sample virtual switch with EVPL to IP interface with
virtual switch member configuration in an IPv4 and IPv6 network.

IP management 9-57
Figure 9-14
Use case E IPv4 configuration example
(configured IP i/f)
IP: 192.0.2.4
(configured IP i/f)
IP: 192.0.2.1
(configured IP i/f)
IP: 10.10.10.3
IP: 10.10.10.1 IP: 10.10.10.2
UNI NNI NNI UNI
P P
NTE-1 VPLS NTE-2
(hub) P2
- - P3 P4
(spoke)
P1
1 2
Service #1
Service #2
Case C EVPL EVPL

Configure NTE-1.
vlan create vlan 8

Configure NTE-2.
vlan create vlan 8


9-58 IP management

8
24
Figure 9-15
Use case E IPv6 configuration example
Configure NTE-1.
vlan create vlan 8

Configure NTE-2.
vlan create vlan 8


IP management 9-59


24

9-60 IP management
Procedure 9-25
Displaying static ARP entries
Display static ARP entries.
Step Action
1 Display static ARP entries:

arp static show
end
Example
The following example shows sample output for the arp static show command.
> arp static show
+----------------+------------------+--------------------+
| DestinationIp | DMAC | ifName (ifIndex) |
+----------------+------------------+--------------------+
|1.1.1.2 |00:02:5a:01:b3:c6 |Ref_Test (5 )|
+----------------+------------------+--------------------+

IP management 9-61
Procedure 9-26
Displaying the AIB table
Display the Adjacency Information Base (AIB) table to view adjacencies for
tunnels and AIS when the next hop is reachable.
Step Action
1 Display the AIB:

ip aib show [summary]|[details]
where
summary displays a summary of AIB information.
details displays detailed AIB information.
Example
The following example shows sample output for the ip aib show command.
> ip aib show
+---------------+-------+------------------+--------+
| NexthopIp |ifIndex| Dmac | ObjIdx |
+---------------+-------+------------------+--------+
|1.1.1.2 |5 |00:02:5a:01:b3:c6 |4 |
+---------------+-------+------------------+--------+

9-62 IP management

10-1
MEF L2 VPN configuration 10-
This chapter describes Layer 2 Virtual Private Networks and how to configure
them:
Overview
Ethernet Service Types
Q-in-Q encapsulation
EPL and EVPL Provider Bridge configuration
EVPL CoS
EVPL Bundling
VLAN translation
Private forwarding groups
External Network-to-Network Interface Hairpin
Note: In order to configure MEF L2 VPNs, you need to install the

Advanced Ethernet (AE) license key. License keys can be purchased by
contacting Ciena customer support.
Overview
Data moves through a Carrier Ethernet network by means of Point-to-Point
and Multipoint-to-Multipoint Ethernet Virtual Connections (EVCs). The types
of EVC points are:
User Network Interface (UNI), which is the physical demarcation between

the responsibility of a service provider and the subscriber.
The customer-side processes of the UNI are called the UNI-C and the
network-side processes are called the UNI-N.
External Network to Network Interface (ENNI), which is the physical
demarcation between the responsibility of two service providers. There
two types of services providers.

10-2 MEF L2 VPN configuration
One type of service provider sells Ethernet services to end user buyers
who are connected to the network by means of the NNI. The other type of
service provider is the operator who sells Ethernet services to the service
provider whose networks are connected by means of the ENNI.
Each service provider is responsible for their respective side of the service
demarcation up to the ENNI interconnection point.
The network-side processes on both sides of the ENNI are called ENNI-N.
Figure 10-1 shows an example of an EVC.
Figure 10-1
EVC example
EVC
UNI Service provider 1 Service provider 2

ENNI UNI
CE
CE
UNI-C UNI-N ENNI-N ENNI-N UNI-N UNI-C
Ethernet Service Types

Layer 2 (L2) Virtual Private Networks (VPNs) support the four Ethernet
Service Types defined by the Metro Ethernet Forum (MEF) as:
E-Line: point-to-point service among the same service provider
E-LAN: multiple point service
E-Tree: point-to-multipoint service
E-Access: point-to-point service among different service providers
E-Line Service Type

E-Line Service Types include Virtual Private Lines (EVPL), Ethernet Private
Lines (EPL), Ethernet Internet Access, and TDM Over Ethernet.
EVPL replaces Frame Relay or ATM L2 VPN services. It delivers higher

bandwidth, end-to-end services. EVPL enables multiple services (EVCs) to be
delivered over a single physical connection (user network interface) to
customer premises.

Figure 10-2 shows an E-Line service type Point-to-Point EVC among the
same service provider.
Figure 10-2
E-Line Service type Point-to-Point EVC
Point-to-Point EVC
UNI
UNI
For EPL, the point-to-point EVC provides connectivity between two user
network interfaces (UNIs) where all frames sent to the EVC from one UNI are
received by the other UNI. EPL provides a port-based service with single
service EVC across dedicated UNIs to provide site-to-site connectivity. EPL is
typically delivered by Ethernet over SDH with one customer/service per user
network interface (UNI) port.
E-LAN Service Type

E-LAN Service Types include multipoint L2 VPNs, Transparent LAN Service,
and Multicast networks. E-LAN Service Types are the foundation for IPTV and
Multicast networks. EP-LANs and EVP-LANs use this service type.
For EP-LANs, bridged Lan service is provided across a geographically

dispersed network. Each UNI is dedicated to the EP-LAN service. For EVP-
LANs, service multiplexing is allowed at each UNI. Multiple LAN services for
different customers are provided per each UNI port. An example of an E-LAN
Service Type is Internet access and corporate VPN access using one UNI.

Figure 10-2 shows an E-LAN service type Multi-point-to-Multi-point EVC.
Figure 10-3
E-LAN Service Type for Multi-point-to-Multi-point EVC
Multi-point to Multi-point EVC
UNI
UNI UNI
UNI
E-Tree Service Type

E-Tree Service Types include rooted multi-point L2 VPNs, broadcast
networks, and telemetry networks. The E-Tree Service Type includes EP-Tree
and EVP-Tree. Both allow root-to-root and root-to-leaf communication, but not
leaf-to-leaf communication. EP-Tree requires dedicated UNIs to the single
EP-Tree service. The EVP-Tree lets each UNI support multiple, simultaneous
services in a more complex configuration than EP-Tree.
The E-Tree Service Type is used for broadcast applications. For example, the
Root UNI can broadcast TV channels to all Leaf UNIs, and the Leaf UNIs can
send channel-changing information from each subscribers box back to the
Root UNI.

Figure 10-4 shows an E-Tree service type Rooted Multi-point EVC.
Figure 10-4
Rooted Multi-point EVC
UNI
UNI Rooted
Multi-point
EVC
UNI
E-Access Service Type

E-Access Service Type includes wholesale access services, Access EPL, and
Access EVPL. Access providers sell their services to retail. Service providers
deliver an EVC-based service to their subscribers. Access EPL and Access
EVPL use point-to-point Operator Virtual Connection (OVC) with one UNI
endpoint and one ENNI endpoint. An OVC with a UNI and ENNI endpoint is
used for Ethernet access services where an Ethernet access provider
provides a UNI at the subscribers premises. In this case, the Ethernet service
provider that does not have network facilities to reach the subscribers site.
The site can only be reached through an Ethernet access provider with
network facilities that reach the site.
Figure 10-4 shows an E-Access service type Point-to-Point EVC among

different service providers.
Figure 10-5
E-Access Service Type for Point-to-Point EVC
Carrier Ethernet Carrier Ethernet

UNI Service provider Access Network UNI
ENNI
E-Access

Q-in-Q encapsulation
Support for the MEF service types is configured by means of EPLs and EVPLs
that comply with 802.ad Provider Bridges standard (also called Q-in-Q
encapsulation and double tagging). Encapsulating the inner 802.1Q
Customer VLAN (C-VLAN) tag within the outer 802.1Q Service VLAN (S-
VLAN) tag enables the service provider to keep subscriber traffic separate,
even if the same CVLAN ID is used by more than one subscriber group.
The following configurations are supported:
Per-port (PP) Q-in-Q: SAOS supports point-to-point Ethernet Private Line
(EPL) with one EVC per UNI. Frames from port-based and port-vlan-
based classified UNI ingress are forwarded to an NNI egress by adding a
specified SVID, and are forwarded to a UNI egress by removing the SVID.
The UNI port only accepts an untagged-data-vs configuration that
matches the virtual switch of the Per Port (EPL) member. This can be used
in conjunction with the ingress-vs-filter.
Per-port-per-VLAN (PPV) Q-in-Q: SAOS supports point-to-point Ethernet
Virtual Private Line (EVPL) with multiple EVCs per UNI and fixed policy
priority bit re-marking on ingress. Frames from port-VLAN-based
classified UNI ingress are forwarded to the NNI egress by adding a
specified SVID.
EPL and EVPL Provider Bridge configuration

EPL and EVPL Provider Bridge configuration is implemented by attaching a
virtual circuit with its associated Provider VLAN, to a virtual switch, which
defines the subscriber ports (PP) or subscriber ports and VLANs (PPV). From
the subscribers perspective, the subscriber connection to the service provider
network is a direct connection using a private LAN between geographically-
separated sites.
The general steps for configuring an EPL or EVPL are:

1 Create a service provider VLAN.
2 Add the NNI port to the service provider VLAN.
3 Add reserved VLANs for use when creating virtual switches.
4 Create an Ethernet virtual circuit using the service provider VLAN.
5 Create the virtual switch and associate it with the virtual circuit
6 Add the UNI members to the Ethernet virtual switch.

Figure 10-6
EPL and EVPL configuration overview
EPL and EVPL configuration
Create a provider VLAN
Add the NNI port to the provider VLAN
Add a reserved VLAN
Create an Ethernet virtual circuit
Create an Ethernet virtual switch
EPL
EPL or EVPL
EVPL?
Add UNI to the Ethernet virtual switch Add UNI + CVID to the Ethernet virtual switch
Provider VLAN
In the fully configured EPL or EVPL, the provider VLAN is the Service VLAN
(S-VLAN) outer 802.1D tag and has an NNI (egress) port associated with it.
Note: By default, the outer Tag Protocol Identifier (TPID) of frames

egressing a member port is stamped with a value of 8100 by default. This
setting can be changed to 88a8 or 9100 or back to the default of 8100.

Figure 10-7
Provider VLAN overview using Q-in-Q
Provider VLAN
UNI NNI
VS VC
NNI
UNI
Reserved VLAN
A reserved VLAN is used internally to link a virtual switch with an internal
switching domain, and acts to connect both subscriber and provider facing
interfaces. A reserved VLAN must be created for each virtual switch before the
virtual switch is configured. The reserved VLAN pool is part of the same 1-
4094 range as the system VLAN pool. The system can automatically assign
the reserved VLAN from this pool when the virtual switch is created or you can
specify a reserved VLAN when you create the virtual switch.
Subscriber/UNI traffic can also be switched without connecting to the provider/

transport network.
Figure 10-8
Reserved VLAN
Reserved VLAN
UNI NNI
VS
NNI
UNI
Virtual switch
A virtual switch is a logical entity that can co-exist with other virtual switches
within a physical device. Virtual switches allow the physical device to provide
a variety of methods for classification, segregation, and flexibility in frame
processing. Virtual switches segment the system into separate logical
forwarding domains or flood domains to enable VLAN identifiers (VIDs) to be

reused across multiple virtual switches. For example, a VID of 101 instanced
on two or more virtual switches with unique port connectivity to each virtual
switch allows multiple customers to use VID 101 for their own network
connectivity, yet be completely isolated from each other. A virtual switch
provides the Layer 2 forwarding domain between its UNI members and the
NNI. It provides the ability to bring together different networks, while
maintaining their security and isolation.
Virtual switches are the switching construct used for Q-in-Q (as described in
this chapter), as well as, for PBB-TE, MPLS, and PWE (3932).
Note: When a port is added to a virtual switch, that port is automatically

removed from its external VLANs. Therefore, any VLAN add or VLAN
remove involving that port is not included in the Configuration file.
The number of virtual switches and members supported for Q-in-Q depends
upon the platform capabilities as shown in Table 10-1.
Table 10-1
Q-in-Q virtual switch capabilities
Platform Virtual switches Virtual switch Virtual switch

members per port members per
switch
3916, 3930, 3931, 256 1024 1024

3932
3940, 5140 128 512 512
3960 512 2048 2048
5142, 5160 1024 4096 4096
5150 1024 3584 3584
Note 1: The number of virtual switches and virtual switch members per
port and switch supported for Q-in-Q are reduced by the number of virtual
switches and virtual switch members per port and switch configured for
PBB-TE and MPLS.
Note 2: Virtual circuits and virtual switches have a 1:1 relationship. A
virtual circuit can only be associated with one virtual switch. A virtual
switch can only be associated with one virtual circuit.
Virtual circuits
A virtual circuit defines a secure logical connection between one or more
customer endpoints. It is a service trunk, where transport services start and
end. Virtual circuits use the S-VLAN (or Provider VLAN) to tag traffic from the
UNI side (encapsulate) and strip the S-VLAN (or Provider VLAN) from traffic

coming from the NNI side (decapsulate) over the service providers network to
allow data to be easily switched without the need for in-depth individual packet
analysis or routing decisions at each network device. They can be thought of
as the provider VLAN.
The number of virtual circuits supported for Q-in-Q depends upon the platform
capabilities as shown in Table 10-2.
Table 10-2
Q-in-Q virtual circuits supported per platform
Platform Virtual circuits
3916, 3930, 3931, 3932 256
3940, 5140 128
3960 512
5142, 5150, 5160 1024
Note: For 3940, 3960, 5140, 5142, 5150, and 5160 platforms, the number
of virtual circuits supported for Q-in-Q are reduced by the number of VSs
and virtual switch members per port and switch configured for Provider
Backbone Bridge Traffic Engineering (PBB-TE).
SAOS allows Ethernet virtual circuits to be statically created. An Ethernet-

virtual circuit uses an additional 802.1Q VLAN tag and includes the following:
Service Etype (default 0x8100)
Service VLAN ID (value 0-4095)
Service VLAN Priority Code Point (PCP) (also, called SVLAN 802.1D
priority) (value 0-7)
Figure 10-7 shows a Provider VLAN using Q-in-Q.
Frame flooding behavior

Frames received by an Ethernet virtual switch that are determined to be
unknown unicast (also known as a destination lookup failure (DLF), unknown
multicast, or broadcast will be flooded to the following:
all ports that are members of the virtual circuit's VLAN, if a virtual circuit is
assigned to the virtual switch
all ports that are included as an EPL or EVPL member of the virtual switch,
regardless if a customer VLAN tag exists, or if the C-VID of the frame
matches the C-VID configured against the EVPL member

Q-in-Q Ethertype
By default the outer tag TPID of frames egressing a member port is stamped
with a value of 8100. This setting can be changed per VLAN to 88a8 or 9100
or back to the default of 8100.
This setting supports compatibility with standard 802.1Q encapsulation

methods like Extreme's vMAN that uses the 9100, and 802.1ad for Provider
Bridging. Using the virtual-circuit ethernet set port command, the
Ethertype value to use can be configured as described in Table 10-3.
Table 10-3
Ethertype setting (per-port)
Name Description
8100 This indicates to use normal 802.1Q Ethertype for all frames
egressing the port.
9100 This indicates to use the 0x9100 Ethertype on frames using the
user configured policy described in Table 10-4.
88a8 This indicates to use the 802.1ad Ethertype on frames using the
user configured policy described in Table 10-4.
The virtual-circuit ethernet set port command includes a setting to

specify the policy or rules for applying that configured Ethertype on a per-port
basis as described in Table 10-4.
Table 10-4
Ethertype policy (per-port)
Name Description
all When this policy is set, all frames going out the port are stamped
with the configured Ethertype (see Table 10-3).
encap-only When this policy is set, only encapsulated frames going out a port
are stamped with the configured Ethertype (see Table 10-3). This
affects both single and double tagged frames that have had a
provider VLAN tag added to them.
vlan-tpid When this policy is set, frames going out a port are stamped with
the TPID value of the egress-tpid value assigned to the provider
VLAN.
EVPL CoS
Class of Service is configured by means of:
Virtual Switch CoS Policies
Virtual switch Member CoS Policy Override

Virtual Switch CoS Policies

Each virtual switch has default fixed encapsulation CoS policy (encap-cos-
policy) to mark the 802.1D priority value in the SVLAN tag that is pushed onto
the customer frame on egress from the UNI with the configured encapsulation
802.1D priority value (encap-fixed-dot1dpri). The CoS policy for the CVLAN
tag (subscriber-dot1dpri-policy) can only be set to leave, which does not
modify the frame. Also, for decapsulation, VSs only support a leave CoS
policy. When a virtual switch is created the default encap-fixed-dot1dpri value
is 2 and the subscriber-dot1dpri-policy is leave.
Virtual switch Member CoS Policy Override

By default, virtual switch members inherit the CoS policy from the virtual
switch. You can configure the encap-cos-policy of the virtual switch member
to one of three settings:
fixed The SVLAN 802.1D value is taken from the encap-fixed-dot1dpri
parameter of the virtual switch member.
port-inherit The SVLAN 802.1D value is based on the resolved Cos
policy of the port, which can be one of the following:
fixed CoS (fixed-cos) The SVLAN 802.1D value comes from the
configured fixed resolved CoS (fixed-rcos) of the port.
.1D mapped (dot1d-tag1-cos) Value is mapped from the CVLAN
802.1D value as shown in Table 10-5.
Table 10-5
Default .1D Mapped CoS Mapping Table
Customer SVLAN 802.1D
Frame 802.1D
0 0
1 1
2 2
3 3
4 4
5 5
6 6
7 7
DSCP mapped (l3-dscp-cos) - Value is mapped from the CVLAN

DSCP value as shown in Table 10-6.

Table 10-6
Default DSCP Mapping Table
Customer SVLAN 802.1D
Frame DSCP
0-7 0
8-15 1
16-23 2
24-31 3
32-39 4
40-47 5
48-55 6
56-63 7
vs-inherit Indicates that the SVLAN 802.1D value is defined by the

virtual switch encapsulation CoS policy configuration. This setting is
the default.
EVPL Bundling
SAOS supports EVPL bundling. EVPL bundling allows multiple customer
VLAN IDs (C-VIDs) to be mapped to one or more virtual switches. It should be
noted that EVPL bundling only functions where traffic is being encapsulated.
As an example, Figure 10-9 shows multiple C-VIDS ingressing on port 28.

VLANs 10-20 have been mapped to virtual switch 2, and VLANs 100-110 and
250 are mapped to Ethernet-VS 1. This allows multiple C-VIDs to be mapped
to two separate virtual switches.

Figure 10-9
Multiple C-VIDS to multiple virtual switches
Port 28
Virtual Switch 2 VID 10-20
Virtual Switch 1 VID 100-110, 250
Example
> virtual-switch ethernet add vs vs1 port 28 vlan 100-110,250
> virtual-switch ethernet add vs vs2 port 28 vlan 10-20
Note: If the port vlan-ingress-filter parameter is set to on, only frames that
match a configured VLAN tag are forwarded.
VLAN translation
The 3916, 3930, 3931, 3932, 3960, 5142, 5150, and 5160 platforms support
configurable VLAN translation to classify Q-in-Q traffic from one L2 switching
domain and remap it to another.
To configure VLAN translation for Q-in-Q traffic, set the virtual switch L2
transform actions on the UNI ports and a translation VLAN tag for the virtual
switch. L2 transform actions include:
Ingress push; egress pop (i-push,e-pop)
Upon ingress, the device looks up the frames VID (which becomes the C-VID)
and classifies to a virtual switch, then pushes the SVID tag onto the frame. At
egress, the device looks up the frames SVID and pops the SVID tag. This is
the default L2 transform action and is supported by all platforms running this
system software.

When a UNI port is configured with this L2 transform mode, the following rules
apply to the associated virtual switch:
EPL members can be added.
Single or multiple EVPL members can be added.
Multiple UNI port members can be added.
Can be specified as the virtual switch for untagged data and untagged
control frames for the port.
L2 control frame tunneling can be enabled.
All virtual switch members must have a translate tag of zero.
Ingress push; egress pop and stamp (i-push,e-pop:stamp)

Upon ingress, the device looks up the frames VID (which becomes the CVID)
and classifies it to a virtual switch, and pushes the SVID tag onto the frame.
At egress, the device looks up the frames SVID, pops the SVID tag, and
stamps the VID with the ingress classifier CVID.
When a UNI port is configured with this L2 transform mode, the following rules
apply to the associated virtual switch:
EPL members cannot be added.
Only one EVPL member can be added.
Cannot add multiple UNI port members.
Cannot be specified as the virtual switch for untagged data and untagged
control frames for the port.
L2 control frame tunneling cannot be enabled.
All virtual switch members must have a translate tag of zero.
Note: Only the 3916, 3930, 3931, 3932, 3960, 5142, 5150, 5160 support
this L2 transform mode.
Ingress stamp; egress match, pop, and stamp (i-stamp:push,e-match-

pop:stamp)
There are two scenarios supported under this mode depending on translate-
tag configuration, and both scenarios can be configured under the same
virtual switch at the same time.
When the translate-tag is non-zero:

upon UNI ingress, the device classifies a cVid and stamps <cVid [+ cPri]>,
and then pushes an sTag (Q-in-Q).

upon UNI egress, the device classifies <sVid + cVid> for exact match, and
then pops the sTag and stamps the cVid back to the original cVid used for
ingress-classification.
When the translate-tag is zero:

upon UNI ingress, the device classifies a cVid and stamps it with a new
sTag <sVid [+sPri]>.
upon UNI Egress, the device classifies an sVid for exact match, and then
stamps it back to the original cVid used for ingress-classification.
At ingress, the device looks up the incoming frame's outer vid (cVid) and
classifies it to a virtual switch. In addition, the device stamps the cVid with a
new unique cVid value, and then pushes the sTag onto the frame if the
translate-tag is not zero.
At egress, if the translate-tag is not zero, the device performs a qualified

lookup on the frame's <sVid + cVid>. On match, the device pops the sTag and
stamps the cVid with the original cVid specified as the ingress classifier. If the
translate-tag is zero, the classification is on sTag and stamped with the original
cVid back.
Due to the qualification of the <sVid + cVid> at egress and the relevant
uniqueness of the translated cVid to a port, using this transform-mode
constrains the configuration as follows:
Virtual switch can contain only one UNI port specification.
Virtual switch UNI member must contain one or more cVid specifications.
Vid bundle is OK since it exists on a single port.
The translate-tag value must be unique among cVids of the bundle.
The translate-tag value may be used by one or more bundles on
different virtual switches.
Only one cVid can be configured with translate-tag zero.
EPL is not allowed as a virtual switch member in this transform mode.
Note: Only the 3916, 3930, 3931, 3932, 3960, 5142, 5150, and 5160
support this L2 transform mode.
Under the following conditions, traffic can unexpectedly obtain the same S-
and C-VID and as a result, merge together toward the NNI direction:
Both zero translate-tag and non-zero translate-tag members are
provisioned under the same virtual switch.
Double-tagged traffic classifies to the zero translate-tag member from the
UNI side.

A non-zero translate-tag member has the same value as the inner tag of
the zero translate-tag traffic.
Ciena recommends that the network operator provision the non-zero

translate-tag member under another virtual switch.
Private forwarding groups

Layer 2 private forwarding groups (PFG) restrict forwarding of L2 traffic
between groups of ports within a shared VLAN or virtual switch. Port-based
PFGs alter the forwarding behavior of ports such that their forwarding domain
is restricted to a subset of ports on the switch. Unlike L2 PFG which restricts
the flow of traffic between ports on the same VLAN, port-based PFG is applied
to all VLANs. PFGs resolve traffic loops for networks that do not use loop
prevention techniques such as Spanning Tree Protocol (STP). PFGs are also
used to restrict traffic forwarding between customer-facing ports within a
particular forwarding domain.
Figure 10-10 shows an example where the core network connects to the
customer's access network by means of two metro aggregation devices. All
downlink ports on the metro devices are connected to a 3930 switch. The
3930 switch is used to provide services to two customer networks by means
of a 3902 switch and a 3911 switch.
Figure 10-10
Multi UNI/NNI example: L2 Network topology
In this configuration, both customer ends are provisioned for core access, but
at the same time communication is restricted between customer sites. This
can be accomplished by defining forwarding rules for specific groups of
interfaces within a forwarding domain. By separating NNIs and UNIs into two
forwarding groups, or PFGs, a set of forwarding rules can be applied to each

interface group. These forwarding rules can then be used to prevent traffic
from being switched between customer-facing interfaces while having more
than one customer provisioned under the same service instance.
Figure 10-11 illustrates the internal configuration of the 3930 switch shown in
Figure 10-10.
Figure 10-11
L2: Internal configuration of 3930 switch
Interfaces on 39XX/51XX platforms are divided into two PFGs: group A and
group B. Each PFG is a set of ports that obeys the same forwarding rules or
forwarding policy. Certain group forwarding policies are configurable and can
be set such that ports within the same group do not forward traffic to each
other.
Figure 10-12 shows an example where a port-based PFG facilitates a single

switch having more than two sets of private forwarding groups. In this
example, the 3930 switch provides services to four networks from two core
networks. Networks UNI-1 and UNI-2 are connected to core network NNI-1.
Networks UNI-3 and UNI-4 are connected to core network NNI-2.

Figure 10-12
Multi-UNI/Multi-NNI example: Port-based network topology
As with L2-based PFG, communication between sites must be restricted.

Communication between core networks may be restricted. By restricting
which ports may egress traffic received on a given port, forwarding domains
can be provided for each port.
Figure 10-13 shows the internal configuration of the 3930 switch. In both
Figure 10-12 and Figure 10-13 traffic may not cross the forwarding boundary
noted by the dotted red line.

Figure 10-13
Port-based: Internal configuration of 3930 switch
L2-based PFG Forwarding policy sets

The PFG feature uses policy sets, which house the port-based forwarding
groups and rules for VLANs and VLAN-based virtual switches. Configured
services on a single platform can inherit one of two global policy sets:
management policy set, which is a collection of forwarding policies to be
used exclusively on a device's current management VLAN.
universal policy set, which is a collection of forwarding policies that all
VLAN-based services can use, with the exception of the current
management VLAN.
Each policy set contains two distinct private forwarding groups (PFGs), group
A and group B. All interfaces on a device are divided into one of these two
PFGs for both the management and universal policy sets. This means that a
port can be a member of PFG A for the management policy set but be a
member of PFG B for the universal policy set. PFG membership of a particular
port is configured by means of the CLI and SNMP interfaces.
There is a forwarding policy, or set of rules, for every defined PFG which is
applied to all ports within that particular forwarding group. A forwarding policy
takes on one of the following values:
A: can only forward to port members of private forwarding group A
B: can only forward to port members of private forwarding group B
A,B: can forward to port members of both private forwarding group A and B

In the default configuration, all ports in PFG A can forward frames to all other
ports on the switch, including ports within the same forwarding group. Ports in
PFG B can only forward frames to ports in PFG A. This policy set is applied to
a device's current management VLAN.
When the management VLAN changes, the new forwarding domain inherits
this policy set, while the previous VLAN adopts the universal policy set. When
the management VLAN is changed, the administrative status of PFG on this
forwarding domain becomes disabled, that is, no forwarding rules are applied.
Note that the default management VLAN is VLAN 127.
The universal policy set is applied to all VLAN-based services, that is, VLANs
and VLAN-based virtual switches, excluding the management VLAN. This
policy set is also configurable by means of the CLI and SNMP interfaces.
Figure 10-14 shows the structure of the policy set.
Figure 10-14
Policy set structure
With L2-based PFG, traffic flow is restricted by placing ports into forwarding
groups and defining a set of rules between the groups. For example, PGA only
forwards to PFG B, as shown in Figure 10-15.

Figure 10-15
L2-based PFG filter
Port-based PFG egress profile

Port-based PFG defines forwarding restrictions for all data traffic on a set of
ports which share an egress forwarding policy. An egress forwarding policy
defines which ports may egress traffic which has been received on a port to
which this policy is applied.

Figure 10-16
Port-based PFG structure
In the example in Figure 10-17, the egress profile allows traffic to be forwarded
to ports B, D and F. The egress profile is assigned to port A. Each egress
profile is unidirectional, such that each port must be assigned an egress
profile if the data traffic it receives is to be restricted. Bidirectional port
forwarding may be configured by creating an egress profile for a set of ports,
and then assigning that egress profile to the same set of ports.

Figure 10-17
Port-based PFG egress profile
A port-based PFG egress profile defines forwarding restrictions for all data
traffic on a particular port. It may be applied to either Link Aggregation Groups
(LAGs) or physical ports. The same filter can be used on multiple ports.
Port-based PFG operates co-operatively with L2-based PFG. A port only

forwards to another port if port-based and L2-based rules allow it.
Traffic which is switched by the CPU/software is not affected by port-based

PFG restrictions. This includes frames which are generated by or destined for
the CPU, such as Connectivity Fault Management (CFM). CFM frames which
are not switched by the CPU obey the port-based PFG rules. This includes
RFC 2544 frames. If an RFC 2544 Port Under Test (PUT) is blocked by port
forwarding rules, it does not reflect, analyze or generate test frames.
Port membership
Physical ports on 39XX/51XX switches are divided into L2-based PFGs upon
system boot. Each L2-based PFG policy contains its own set of forwarding
groups. The L2 PFG membership of a port within a PFG policy is configurable
at any time through both the CLI and SNMP interfaces. Port membership also
extends to aggregated ports through LAGs.

When a LAG is created, the interface defaults to PFG A. Any port that is added
to a LAG inherits the forwarding group of that aggregation. Similarly, when a
port is removed from the aggregation, the port's original L2 PFG membership
(the forwarding group before entering into the LAG) is restored.
Table 10-7 lists default values for PFG A and PFG B.
Table 10-7
Platform PFG port membership default values
Platform PFG A PFG B
3916 1-6 --
3930 1-8 9,10
3931 1-8 9,10
3932 1-10 --
3940 1-24 --
3960 1-10 11,12
5140 1-24 --
5142 1-24 --
5150 1.1-1.36 1.37-1.48, 2.1, 2.2,

3.1, 3.2
5160 1-24 --
Port-based PFGs are defined similarly for UNI and NNI ports. There are no
restrictions on the number or membership of egress profiles.
As with L2-based PFG, port membership extends to aggregated ports through

LAGs. Any port that is added to a LAG inherits the egress profile of that
aggregation. When a port is removed from the aggregation, the ports original
egress profile membership is restored. A newly created LAG is not a member
of or associated with any egress profile.
Upgrading and downgrading a device

When a device is upgraded from a version of SAOS that does not support L2-
based PFG to one that does, most of the default L2-based PFG feature
settings are inherited. The policy sets are disabled and the management
VLAN is PFG disabled. Usually, when a device boots with default settings,
PFG is enabled on the management VLAN. However, the default PFG port-
memberships may conflict with a previously saved configuration. This can
prevent the communication of management traffic between provisioned
services.

Upgrading a device from a version of SAOS that does not support port-based
PFG to one that does will not have any port-based PFG restrictions.
Downgrading a device from an L2-based or port-based PFG release to a

release which does not support PFG requires the removal of all PFG
commands from the devices configuration file. This is required to eliminate
errors when loading any previously saved configuration files.
External Network-to-Network Interface Hairpin

External Network-to-Network Interface (ENNI) transforms and switches
frames out of the same physical port they came in on. Hairpin switching
occurs when a frame from an origin endpoint is returned in the direction it
came from in order to get to its destination endpoint. This is possible when an
Operator Virtual Connection (OVC) associates two or more OVC endpoints at
the ENNI. It allows traffic to be forwarded among multiple service flows of one
ENNI port or Link Aggregation Group (LAG).
Improper use of Hairpin Switching can result in a data loop between two
operator Metro Ethernet Networks (MENs) at a single ENNI.
Note: ENNI Hairpin is supported on the 3916, 3930, 3931, 3932, 5142,
5150 and 5160. ENNI Hairpin is not supported on the 3940, 3960 and
5140.
Sub-port interfaces
Sub-port interfaces are required to support ENNI hairpin switching. The
number of sub-port interfaces and sub-port-based virtual switches is impacted
by the configuration of other features and services in the device. Sub-port
interfaces provide the following capabilities:
Create, delete and modify a sub-port interface
Attach or detach a sub-port interface to or from an Ethernet virtual switch
Support a sub-port interface based on a port and a single outer VLAN ID
value:
Ingress frame classification for the sub-port interface is based on the
ingress port and outer VLAN ID value of the received frame.
Frames egressing a tagged sub-port interface will have its outer VLAN
ID value stamped to the VID configured for the sub-port interface. If the
frame is untagged when received on the ingress sub-port, a single
VLAN tag is pushed on the frame with the VID of the egress sub-port.
Support a sub-port interface based on port and untagged frames
Ingress frame classification for the sub-port interface is based on the
ingress port and the received frame being untagged. A tagged sub-
port only qualifies on untagged or priority tagged ingress traffic.

Frames egressing an untagged sub-port interface will have its most

outer VLAN tag popped off the frame. If the frame was untagged when
received on the ingress sub-port, the frame will remain untagged when
egressing the egress sub-port.
Receive and transmit statistics on a per sub-port interface based on frame
and byte counts
Parent port co-existence with VLAN members which is beneficial for
Other non-hairpinning OVC endpoints on the ENNI interface
Remote management on the ENNI-N device and through the ENNI
interface
Sub-port configuration restrictions
The following list outlines the sub-port configuration restrictions:
A sub-port cannot be attached to an MPLS virtual switch whose mode is
set to vpls or vpws.
A sub-port cannot co-exist on the same virtual switch with a VS member
or a virtual circuit. This means that
A sub-port cannot be attached to a virtual switch that currently
contains a VS member or a virtual circuit.
A VS member cannot be added to a virtual switch that has a sub-port
attached to it.
A virtual circuit cannot be set on a virtual switch that has a sub-port
attached to it.
A sub-port cannot co-exist on the same physical or aggregate port with a
VS member. This means that
A sub-port cannot be created where the parent port is currently part of
an existing VS member.
A VS member cannot be added where the port specified is a parent
port of an existing sub-port.
Sub-port configuration options
When the parent port of the sub-port interface is specified, there are two
configuration options on a sub-port interface to further perform classification
and egress L2 transforms. These options are
vtag-stack <vid> received VLAN tagged frames with the outer VID
matching the configured VID will be handled by the sub-port interface.
Frames being transmitted by the sub-port interface will have its most outer
VLAN tag stamped with the configured VID by the device before
transmission. If the frame is untagged, a VLAN tag with the configured VID
is pushed onto the frame by the device before transmission.
The following figure shows tagged sub-port switching behaviour.

Figure 10-18
Tagged sub-port switching behaviour
vlan-untagged-data received untagged or priority tagged frames will be

handled by the sub-port interface. Frames transmitted by the sub-port
interface will have its most outer VLAN tag popped off by the device before
transmission, if one exists.
The following figure shows tagged sub-port switching behaviour.
Figure 10-19
Untagged sub-port switching behaviour
Virtual switch behavior

The configuration of an Ethernet virtual switch to attach sub-ports is not
affected by ENNI Hairpin Switching. Frames will internally be L2 switch-based
on the reserved VLAN. The reserved VLAN will never be seen on the frame
outside the device unless the egress sub-port is configured with the same VID.

For MAC learning, frames received by sub-ports may be learned. If they are
learned, MAC learning entries are stored and referenced with the following
information:
Key: Virtual Switch, MAC Address
Destination: Sub-port

Procedure 10-1
Creating an EPL provider bridge
Create an EPL provider bridge.
Step Action
1 Create a provider VLAN (SVID).

vlan create vlan <VlanIdList> [name <String[31]>]
2 Add the NNI port to the provider VLAN.
virtual-switch add reserved-vlan <VLAN IDList>
4 Create an Ethernet virtual circuit using the provider VLAN.
virtual-circuit ethernet create {vc
<VirtualCircuitEthernetName[15]>} {vlan <Vlan>}
5 Create the virtual switch and associate it with the virtual circuit created in step
4.
virtual-switch ethernet create vs <VirtualSwitchName> vc
<VirtualCircuitEthernetName[15]> encap-fixed-dot1dpri
<NUMBER: 0-7>
6 Add UNI PORT members to the Ethernet virtual switches.
| 9100 | 88A8>}
end
Example
Figure 10-20 shows an example of an EPL provider bridge.

Figure 10-20
Ethernet Private Line
All customer VC
UNI VS
VLANs (CVID) 101 NNI
(SVID) CVID/101
The following example configures the EPL provider bridge.
> vlan create vlan 101

> vlan add vlan 101 port 10
> virtual-switch add reserved-vlan 1001
> virtual-circuit ethernet create vc EVC101 vlan 101
> virtual-switch ethernet create vs EVS100 vc EVC101 encap-fixed-dot1dpri 3
> virtual-switch ethernet add vs EVS100 port 1

Procedure 10-2
Creating an EVPL provider bridge
Create an EVPL provider bridge.
Step Action
1 Create a provider VLAN (SVID)

2 Add the NNI port to the VLAN.
5 Create Ethernet virtual switches using the Ethernet virtual circuit.
<VirtualCircuitName>
6 Add UNI PORT+CVID members to the Ethernet virtual switches.
| 9100 | 88A8>}
end
Example
Figure 10-21 shows an example of an EVPL provider bridge.

Figure 10-21
EVPL Provider Bridging
SVID (1000)
VC 1000/100
VS 1
CVID (100) SVID (2000)
VC NNI
UNI 2000/200
VS 2
CVID (200) (svid) SVID (3000)
VS 3 VC 3000/300
CVID (300)
Create a provider VLAN (SVID) and add the NNI port to the VLAN:

> vlan add vlan 1000,2000,3000 port 8
Create an Ethernet virtual circuit using the provider VLAN.
> virtual-circuit ethernet create vc vc1 vlan 1000

Add reserved VLANs for use when creating virtual switches.
> virtual-switch add reserved-vlan 4000,4001,4002
Create Ethernet virtual switches using the Ethernet virtual circuit.
> virtual-switch ethernet create vs vs1 vc vc1

Add UNI PORT+CVID members to the Ethernet virtual switches.
> virtual-switch ethernet add vs vs1 port 1 vlan 100


Procedure 10-3
Configuring the fixed encapsulation priority value
Configure the fixed encapsulation priority value. You can configure the fixed
encapsulation priority value for
a virtual switch upon creation
an existing virtual switch
Step Action
To configure the fixed encapsulation priority value for a virtual switch upon creation
1 Configure the fixed encapsulation priority value for a virtual switch upon
creation:
virtual-switch ethernet create vs <String> encap-fixed-
dot1dpri <NUMBER:0-7>
To configure the fixed encapsulation priority value for an existing virtual switch
2 Configure the fixed encapsulation priority value for an existing virtual switch:
virtual-switch ethernet set vs <vs> {decap-cos-policy
<fixed | leave | tunnel-inherit | vc-inherit>} {decap-
fixed-dot1dpri <NUMBER: 0-7>} {description <String[128]>}
{encap-cos-policy <dot1dpri-inherit | fixed | ip-prec-
inherit | phbg-inherit>} {encap-fixed-dot1dpri <NUMBER:
0-7>} {subscriber-dot1dpri-policy <leave | provider-
inherit>} {vc <Virtual Circuit Name>} [ip-iterface
<interface-name>]
end

Procedure 10-4
Setting the CoS policy when adding VS members
Set the CoS policy when adding VS members.
Step Action
1 Set the CoS policy when adding VS members:

| 9100 | 88A8>}
2 Set the CoS policy for existing VS members:
inherit>} {vc <Virtual Circuit Name>} [ip-interface
<interface-name>]
end
Example
The following example sets the CoS policy when adding VS members.

encap-cos-policy fixed encap-fixed-dot1dpri 6
The following example sets the CoS policy for existing VS members.
virtual-switch ethernet set port 5 vs vs150 encap-cos-

policy vs-inherit

Procedure 10-5
Handling ingress untagged frames
When a UNI port is set to accept all frame types, untagged data frames and
untagged control frames are allowed to ingress. If desired, you can configure
the port to forward these frames to specific virtual switches with the
untagged-ctrl-vs or untagged-data-vs attributes. Also, you can configure the
ports untagged-data-vid attribute to add (push) a CVID tag on untagged data
frames on ingress. In addition to the CVID, the tag can include the ports
ingress fixed .1d priority. These frames are encapsulated with the CVID tag
and a header that includes the Service VLAN ID (SVID). After processing, the
frames are decapsulated, and the CVID tag is retained on egress.
Note 1: The untagged-data-vs and untagged-ctrl-vs attributes do not

apply to MPLS virtual switches. All untagged traffic is directed to the MPLS
EPL virtual switch on that port.
Note 2: On the 3940 and 5140 platforms, the untagged-data-vid attribute
pushes the CVID on ingress but does not pop the CVID on egress.
Step Action
1 Create a provider VLAN (SVID)

4 Create the virtual switch and associate it with the virtual circuit:
virtual-switch ethernet create vs <VirtualSwitchName[15]>
vc <VirtualCircuitName[15]>
5 Add the UNI port to the virtual switch.
| 9100 | 88A8>}

6 Set UNI port attributes:

port set port <PortNameList> acceptable-frame-type
<all|taggedonly> untagged-data-vs <VirtualSwitchName>
untagged-data-vid <VlanId> fixed-rcos <NUMBER: 0-7]
where
port <PortNameList> is the port list
acceptable-frame- is the acceptable frame types mode
type <all|taggedonly>
untagged-data-vs is the virtual switch for untagged data frames
<VirtualSwitchName>
untagged-data-vid is the VLAN ID for untagged data frames
<VlanId> Note: On the 3940 and 5140 platforms, the untagged-
data-vid attribute pushes the VLAN ID on ingress but
does not pop the VLAN ID on egress.
fixed-rcos is the Fixed Resolved CoS value
<NUMBER: 0-7]
end
Example
The following example sets the following UNI port attributes:
accept all frame types
allow untagged data frames and untagged control frames to ingress
add (push) a CVID tag on untagged data frames on ingress and include
the ports ingress fixed .1d priority

> virtual-switch ethernet create vs vsX vc vc555
> virtual-switch ethernet add vs vsX port 1
> port set port 1 acceptable-frame-type all untagged-data-vs vsX
untagged-data-vid 555 fixed-rcos 5

Procedure 10-6
Setting the L2 transform action on a port
Set the L2 transform action on a port.
To enable transform actions other than the default on the 3916, 3930, 3931,
3932, 3960, and 5150 platforms, assign resources for the feature.
Note: For more information regarding resource management, see

Hardware resource management on page 5-1.
Step Action
1 Set the L2 transform action on a port:

port set port <PortName> vs-l2-transform <i-push,e-pop|i-
push,e-pop:stamp|i-stamp:push,e-match-pop:stamp>
To assign resources for the feature
resource-manager pool set resource classifier feature vs-
enhanced-l2-transform count 512
resource-manager pool set resource meter feature vs-
resource-manager pool set resource counter feature vs-
configuration save
chassis reboot
end

Procedure 10-7
Creating an i-push, e-pop Q-in-Q VS configuration
Create an i-push, e-pop Q-in-Q configuration.
Step Action
1 Set the virtual switch layer 2 transform action to support VLAN translation for
virtual switches on the first port:
port set port <PortNameList> vs-l2-transform i-push,e-pop
where
<PortNameList> is the name of the first port
virtual switches on the second port:
where
<PortNameList> is the name of the second port
3 Create a VLAN:
4 Add ports to the VLAN created in step 3.
5 Reserve VLANs for use in creating Virtual Switch Instances:
6 Create a static Ethernet virtual circuit for the specified VLAN object:
7 Create a virtual switch instance and associate a virtual circuit:
[vc <VirtualCircuitName[15]>] reserved-vlan <VLAN IDList>
8 Add an attachment circuit:
| 9100 | 88A8>}
end

Example
The example illustrated in Figure 10-22 shows a Q-in-Q VS configuration
where traffic is classified to CVID 555 and the SVID 100 is pushed on the
frame at ingress. From UNI-1 to UNI-2, the SVID is popped on egress. From
UNI to NNI, frames egress with SVID 100.
Figure 10-22
VS L2 transform: i-push,e-pop for Q-in-Q
CVID 555
UNI
Port 1
VS
VC Provider
VLAN 100
UNI NNI
Port 2 Port 10
CVID 555
SVID 100:CVID 555
> port set port 1 vs-l2-transform i-push,e-pop

> vlan add vlan 100 port 10
> virtual-switch ethernet create vs vs100 vc vc100 reserved-vlan 4000

Procedure 10-8
Creating a VS configuration with UNI only with
bundled CVIDs
Create a VS configuration with UNI only with bundled CVIDs.
Step Action
virtual switches on the first port:
where
<PortNameList> is the name of the first port
virtual switches on the second port:
where
<PortNameList> is the name of the second port

4 Create a virtual switch instance:
reserved-vlan <VLAN IDList>
5 Add attachment circuits for the first port:
| 9100 | 88A8>}
6 Add attachment circuits for the second port:
| 9100 | 88A8>}
end

Example
The example illustrated in Figure 10-22 shows a VS configuration where traffic
is classified to CVID 555 and 600. The SVID 4000 is pushed on the frame at
ingress and popped at egress.
Figure 10-23
VS L2 transform: i-push,e-pop for UNI only with bundled CVIDs
CVID 555
UNI
Port 1
CVID 600
VS
VLAN
4000
CVID 600 UNI
Port 2
CVID 555

> virtual-switch ethernet create vs vs100 reserved-vlan 4000

Procedure 10-9
Creating an i-push, e-pop: stamp configuration
Create an i-push, e-pop: stamp configuration.
Step Action
To configure Device A
virtual switches:
port set port <PortNameList> vs-l2-transform i-push,e-
pop:stamp
2 Create a VLAN:
| 9100 | 88A8>}
To configure Device B
virtual switches:
port set port <PortNameList> vs-l2-transform i-push,e-
pop:stamp
9 Create a VLAN:


| 9100 | 88A8>}
end
Example
In this example, ingress frames that classify to CVID 555 have the SVID 100
pushed onto them. On egress, any frames that classify to SVID 100 have the
SVID popped off and the CVID 555 stamped. For 3916, 3930, 3931, 3932,
3960, and 5150 platforms, this configuration requires the allocation of
resources as described in Setting the L2 transform action on a port.

Figure 10-24
VS L2 transform: i-push,e-pop:stamp for Q-in-Q
Device A
CVID 555
UNI
VS
VC Provider
Port 1
CVID 555 VLAN 100
NNI
Port 10
SVID 100:CVID 555 SVID 100:CVID 888
Device B
CVID 888
UNI VC Provider
Port 1 VS
VLAN 100
CVID 888
NNI
Port 10
Configure Device A.
port set port 1 vs-l2-transform i-push,e-pop:stamp

virtual-switch ethernet create vs vs100 vc vc1 reserved-vlan 4000
Configure Device B.
port set port 1 vs-l2-transform i-push,e-pop:stamp


Procedure 10-10
Creating an i-stamp:push,e-match-pop:stamp
configuration
Create an i-stamp:push,e-match-pop:stamp configuration.
Step Action
1 Sets the virtual switch layer 2 transform action to support VLAN translation for
virtual switches.
port set port <PortNameList> vs-l2-transform i-
stamp:push,e-match-pop:stamp
2 Create a VLAN:
7 Add attachment circuits:
| 9100 | 88A8>}
end
Example
The following examples show
When translate-tag is non-zero
When translate-tag is zero

When translate-tag is non-zero

In this scenario, frames with CVID 555, 600, or 777 classify to the UNI port 1.
Upon ingress, each frame is stamped with the new CVID 20, 30, or 40,
respectively, then the SVID 100 is pushed onto it. On egress, frames with the
SVID 100 plus the CVID 20, 30, or 40 have the SVID 100 popped off, and the
original CVID (555, 600, or 777) is stamped. For 3916, 3930, 3931, 3932,
3960, and 5150 platforms, this configuration requires the allocation of
resources as described in Setting the L2 transform action on a port.
Figure 10-25
VS L2 transform: i-push,e-pop for Q-in-Q
CVID 555 UNI NNI

Port 1 Port 10
CVID 600 VS
VC Provider
VLAN 100
CVID 777
SVID 100:CVID 20 SVID 100:CVID 30 SVID 100:CVID 40
port set port 1 vs-l2-transform i-stamp:push,e-match-pop:stamp

virtual-switch ethernet add vs vs100 port UNI-1 vlan 555 translate-tag 20
When translate-tag is zero

In this scenario, the SVID is 100. The Ethernet VC (using provider VLAN 100)
is associated with the virtual switch. When that association occurs, the active
VLAN changes from the initial "reserved VLAN" to the "provider VLAN. The
ports of the virtual switch belong to VLAN 100.
On frame ingress, the device looks up CVID 555 on port UNI-1. On match,
CVID 555 is stamped with translate-tag 20 and then pushed with sTag 100.

On frame egress, the device looks up SVID+(translate tag), that is, <100 +
20>. When the double-tag match is found, the device pops the sTag and
stamps the remaining tag with the initial CVID 555.
This process is repeated for each user CVID.
For 3916, 3930, 3931, 3932, 3960, and 5150 platforms, this configuration
requires the allocation of resources as described in Setting the L2 transform
action on a port.
port set port UNI-1 vs-l2-transform i-stamp:push,e-match-pop:stamp

vlan add vlan 100 port NNI-1
virtual-circuit ethernet create vc X vlan 100
virtual-switch ethernet create vs X vc X reserved-vlan 4000
virtual-switch ethernet add vs X port UNI-1 vlan 555 translate-tag 20

Procedure 10-11
Configuring L2 PFGs
Configure L2 PFGs to restrict forwarding of L2 traffic between groups of ports
within a shared VLAN or virtual switch.
L2 PFG contains three levels of configuration:

global administrative state, which by default is enabled
PFG policy set specifications
VLAN- and virtual switch-based configurations settings
The forwarding restrictions defined by L2 PFG become active, that is,

operationally-enabled, when all three levels of configuration are enabled.
By default, L2 PFG is
enabled globally
disabled for all policy sets excluding the management policy
disabled on all VSs and VLANs, with the exception of the management
VLAN which is enabled by default

Table 10-8 lists supported domains by platform.
Table 10-8
Supported domains by platform
Platform Domain
3916 management, universal
3940 management
5140 management
Step Action
1 Disable PFG globally:

private-forwarding-groups disable
2 Configure PFG port membership:
private-forwarding-groups set port <PORT> policy <'mgmt',
'univ'> fwd-group <A,B>
where
port <PORT> is the port.
policy <'mgmt', is the policy set.
'univ'>
fwd-group <A,B> is the PFG.

3 Configure the universal policy set:

private-forwarding-groups set policy <'mgmt', 'univ'>
[[policy-group-A <A,B>], [policy-group-B <A,B>]]
where
policy <'mgmt', is the policy set.
'univ'>
policy-group-A specifies which interfaces PFG A can forward to.
<A,B>
policy-group-B specifies which interfaces PFG B can forward to.
<A,B>
4 Configure required VLANs and virtual switches:

vlan create vlan <VLAN ID>
vlan add vlan <VLAN ID> port <PORT1>
virtual-circuit ethernet create vc <VC ID> vlan <VLAN ID>
virtual-switch add reserved-vlan <VLAN ID2>
virtual-switch ethernet create vs <VS ID> vc <VC ID>
virtual-switch ethernet add vs <VS ID> port <PORT2>
5 Enable PFG:
private-forwarding-groups enable vlan <VLAN>
private-forwarding-groups enable vs <VS>
private-forwarding-groups enable policy <'mgmt', 'univ'>
private-forwarding-groups enable
end
Example
Figure 10-26 illustrates a simplified example of PFG use on a 3930 platform.
Port 10 connects to a core network and ports 5 and 8 are connected to two
3902s. The 3902s represent two separate customer networks.

Figure 10-26
Sample configuration
P10
P5
P8
The following example configures one service instance while provisioning two
attachment customer networks. This configuration sets up a PFG such that
the 3902s can access the core network but cannot communicate with each
other.
private-forwarding-groups set port 10 policy univ fwd-
group B
group A
group A
private-forwarding-groups set policy univ policy-group-A
B policy-group-B A

Procedure 10-12
Configuring port-based PFGs
Configure port-based PFGs to alter the forwarding behavior of ports on all
VLANs.
Port-based PFG contains four levels of configuration:

global administrative state, which by default is enabled
global port-based administrative state
PFG egress profile configuration
port PFG configuration
Global administrative state determines whether PFG is enabled globally.

Disabling PFG removes the forwarding restrictions of PFG provisioned ports.
Global port-based administrative state determines whether port-based PFG is

enabled globally. Disabling PFG globally removes the forwarding restrictions
of PFG provisioned ports. Port-based PFG has its own administrative state.
This is disabled if port-based PFG is disabled. PFG is enabled, port-based
PFG may be enabled or disabled.
PFG egress profile configuration settings control the parameters that may be
applied to each port. These settings are applied to all ports which share that
egress profile.
Port PFG configuration settings assigns up to eight egress profiles for each
port. That means one per flood traffic type combination.
Egress profiles must contain optional forwarding or blocking based on the

following data traffic types:
unknown unicast
unknown multicast
broadcast
none of these
or any combination of these data traffic types. By default, traffic type is all,
meaning that all traffic is forwarded to the given egress ports or LAGs. See
Configuring egress profile with traffic types on page 10-57.
Step Action

1 Create an egress profile for traffic egressing on ports 1, 2, 3 and 5 by one of

the following two methods:
private-forwarding-groups port-forwarding create egress-
profile EPOL01
private-forwarding-groups port-forwarding add egress-
profile EPOL01 port 1-3,5
or
2 Assign this policy to port 8:
private-forwarding-groups port-forwarding add port 8
egress-profile EPOL01
3 Enable port-based PFG:
private-forwarding-groups port-forwarding enable
Example
Figure 10-27 shows a partial configuration in which data traffic ingressing on
port 8 may be forwarded only to ports 1, 2, 3 and 5.
Figure 10-27
Port-based PFG sample partial configuration
The following example configures an egress profile for traffic egressing on

ports 1,2, 3 and 5. The policy is set to port 8 and port-based PFG is enabled.

egress-profile EPOL01

Figure 10-28 shows a configuration with 8 ports. All forwarding configuration

is shown as unidirectional with bidirectional connections being achieved with
unidirectional configuration in both directions.
Figure 10-28
Unidirectional port-based PFG sample configuration
The following example creates egress profiles for traffic egressing on ports 1,
2, 3, 4, 7 and 8. The policies are assigned to the desired port, and port-based
PFG is enabled.

profile EP_un01 port 5,6
private-forwarding-groups port-forwarding create egress
profile EP_un02 port 7,8
private-forwarding groups port-forwarding create egress-
profile EP_nu01 port 1-3
profile EP_nu02 port 4
private-forwarding groups port-forwarding add port 1-3
egress-profile EP_un01
private-forwarding-groups port-forwarding add port 5,6
egress-profile EP_nu-01

Figure 10-29 shows how bidirectional port forwarding may be configured. Any
port which is in more than one egress profile applied to a port must not have
conflicting flood traffic types. That is, a port may not be in more than one
egress profile which is assigned to any port if its flood traffic types are not the
same.
Figure 10-29
Bidirectional port-based PFG sample configuration
The following example creates egress profiles for traffic egressing on ports 1,
2, 5 and 6. The policies are assigned to the desired port, and port-based PFG
is enabled.

profile EP_01 port 1,5
private-forwarding-groups port-forwarding create egress
private-forwarding groups port-forwarding create egress-
egress-profile EP_01
egress-profile EP_02,EP_03
egress-profile EP_01,EP_02
egress profile EP_03

Procedure 10-13
Configuring egress profile with traffic types
The traffic types previously described may be added to each egress profile
singly or in combinations of unknown-unicast, unknown multicast and
broadcast. The egress profile could have unknown-unicast and unknown-
multicast traffic with blocked broadcast traffic. The switch hardware cannot
selectively block known-unicast or known multicast traffic. These can only be
blocked by removing the respective egress ports from the egress profile.
There are eight combinations of allowed flood traffic types:

none (no unknown-unicast, unknown-multicast or broadcast)
unknown-unicast
unknown-multicast
broadcast
unknown-unicast and unknown-multicast
unknown-unicast and broadcast
unknown-multicast and broadcast
unknown-unicast, unknown-multicast and broadcast
The default is unknown-unicast, unknown-multicast and broadcast.
To allow a port to block broadcast traffic to one egress port, but allow it on
another requires that the ports be permitted to have more than one egress
profile assigned to them.
Step Action
1 Create an egress profile for traffic egressing on ports 5 and 6:

profile EP_un01 port 5
profile EP_un02 port 5 flood-type unknown-ucast, unknown-
mcast
profile EP_un03 port 6 flood-type none
2 Assign these policies to the desired ports:
egress-profile EP_un01,EP_un03

3 Enable port-based PFG:

Example
Figure 10-30 shows a sample port-based PFG configuration with restrictions
on flood traffic types for some ports.
Figure 10-30
Port-based PFT sample configuration with flood traffic types
The following example creates egress profiles for traffic egressing on ports 5
and 6. The policies are assigned to the desired port, and port-based PFG is
enabled.

profile EP_un01 port 5
profile EP_un02 port 5 flood-type unknown-ucast,unknown-
mcast
profile EP_un03 port 6 flood-type none



When two or more egress profiles are assigned to any port, each of the egress
ports they contain must have a matching flood traffic type with the other
egress profiles. This is shown in
Figure 10-31
Port-based PFG sample configuration with flood traffic conflict
The following example creates egress profiles for traffic egressing on ports 5
and 6. An attempt is made to assign policies to the desired ports. These have
conflicting allow-flood types to egress port 6.

profile EP_un01 port 5,6 flood-type unknown-ucast,
unknown-mcast
private-forwarding-groups port forwarding create egress -
profile EP_un02 port 6 flood-type bcast
egress-profile
EP_un01,EP_un02

Procedure 10-14
Disabling the PFG feature
Disable the PFG feature to alter the forwarding restrictions associated with a
particular PFG policy set. The PFG feature must be operationally-disabled on
all VLANs and virtual switches that reference the policy.
Step Action
1 Disable the PFG feature on the VLANs that reference the PFG policy set:
private-forwarding-groups disable vlan <VLAN ID>
2 Disable the PFG feature on the virtual switches that reference the PFG policy
set:
private-forwarding-groups disable vs <VS ID>
3 Disable the PFG policy set:
private-forwarding-groups disable policy <'mgmt', 'univ'>
4 Disable PFG globally:
5 Disable port-based PFG:
private-forwarding-groups port-forwarding disable
end

Procedure 10-15
Displaying the configuration of EVPL VS members
Display the configuration of EVPL VS members when troubleshooting.
Step Action
1 Display the configuration of each EVPL virtual-switch member:

virtual-switch ethernet show vs <VirtualSwitch>
where
vs is the virtual switch.
<VirtualSwitch>
end
Example
The following example shows sample output for the virtual switch with an
identifier of vs150.
> virtual-switch ethernet show vs vs150

+------------- ETHERNET VIRTUAL SWITCH INFO --------------+
+----------------------+----------------------------------+
| Name | vs150 |
| ID | 5 |
| Active VLAN | (150) VLAN#150 |
| Reserved VLAN | (2503) VLAN#150 |
| CPT Status | Disabled |
| CPT Method | l2pt |
| Transparent Validate | off |
| Mac Learning | Enabled |
| VC | (1) vc150 |
| Subscr Dot1D Policy | leave |
| Decap CoS Policy | leave |
| Decap Fixed Dot1DPri | 2 |
| Encap CoS Policy | fixed |
| Encap Fixed Dot1DPri | 2 |
+---------------------------------------------------------+
| Virtual Switch Members |
| Port | Subscriber VLAN | Encap Cos |Encap Fixed |
| | | Policy | Dot1DPri |
|----------+-----------------+---------------+------------|
| 5 | 151 | fixed | 6 |
| 5 | 152 | vs-inherit | 2 |
+---------------------------------------------------------+

Procedure 10-16
Displaying virtual switches
Display virtual switches to learn which reserved VLAN is associated with a
virtual switch.
Note: The default name for a reserved VLAN cannot be changed.

Reserved VLANs always appear in the format VLAN#XXX.
Step Action
1 Display the reserved VLAN associated with a virtual switch:

virtual-switch show
end
Example
The following example shows sample output for the virtual-switch show
command.
> virtual-switch show
+------------ VIRTUAL SWITCH RESERVED VLANS -----------+

| VLAN | Virtual Switch [Attached] |
+----------------------+-------------------------------+
| 4094 | (1) vs1 |
+----------------------+-------------------------------+
+----------------- ETHERNET VIRTUAL SWITCH TABLE ------------------------+

| | VLAN | | | Subscriber | |
| Name | Active | CPT | Virtual Circuit | Count | Description |
+-----------+--------+-----+-----------------+------------+--------------+
| vs1 | 4094 | Dis | | 0 | |
+-----------+--------+-----+-----------------+------------+--------------+

Procedure 10-17
Displaying PFG information
You can display
the administrative state of the PFG feature
VLAN-specific PFG settings
virtual switch-specific PFG settings
configuration settings for the PFG policy set
PFG settings for port membership
port-based PFG settings
port-based PFG egress profiles
port-based PFG settings for a port
Step Action
To display the administrative state of the PFG feature

1 Display the administrative state of the PFG feature:
private-forwarding-groups show
To display VLAN-specific PFG settings
2 Display VLAN-specific PFG settings:
private-forwarding-groups show vlan
To display virtual switch-specific PFG settings
3 Display virtual switch-specific PFG settings:
private-forwarding-groups show vs
To display the configuration settings for the PFG policy set
4 Display the configuration settings for the PFG policy set:
private-forwarding-groups show policy
To display the PFG settings for port membership
5 Display PFG settings for port membership:
private-forwarding-groups show port
To display port-based PFG settings
6 Display port-based PFG settings:
private-forwarding-groups port-forwarding show

To display port-based PFG egress profiles

7 Display port-based PFG egress profiles:
private-forwarding-groups port-forwarding egress-
[profile <egressProfile>]
where
show [profile is the PFG egress profile.
<egressProfile>]
To display port-based PFG settings for a port

8 Display port-based settings for a port:
private-forwarding-groups port-forwarding show port
<port>
where
show <port> is the port.
end

Procedure 10-18
Configuring EPL and EVPL for E-Access service types
This procedure shows how to configure the User Premises Equipment (UPE)
and the Network Premises Equipment (NPE) to support E-Access service
types.
Step Action
To configure the UPE as an EPL or EVPL

1 Configure the UNI and NNI ports maximum frame size.
port set port <PortList> max-frame-size <NUMBER:
1522..9216>
3 Configure the provider VLAN TPID.
vlan set vlan <VlanIdList> egress-tpid <8100|9100|88A8>
4 Add the NNI port to the provider VLAN.
5 Create a management VLAN.
6 Add the management port to the remote management VLAN.
7 Remove the ports from the default management VLANs.
vlan remove vlan <VlanList> port <PortNameList>
8 Change the remote interface to the new remote management VLAN.
interface remote set vlan <Vlan>
9 Configure the PVID and VLAN for egress untagged traffic.
port set port <PortList> egress-untag-vlan <Vlan>
10 Configure the acceptable frame type for the UNI port.
port set port <PortList> acceptable-frame-type
<all|tagged-only|untagged-only>

13 Create Ethernet virtual switches using the Ethernet virtual circuit.

<VirtualCircuitName>
14 Add UNI PORT+CVID members to the Ethernet virtual switch.
| 9100 | 88A8>}
Note: When the vlan <vlan list> parameter is specified, the UPE is
configured for an EVPL. When the vlan <vlan list> parameter is left out, the
UPE is configured for an EPL.
15 Set the UNI and NNI port VLAN Ethertype value and policy.
virtual-circuit ethernet set port <PortList> vlan-
ethertype <8100|9100|88A8> vlan-ethertype-policy
<all|encap-only|vlan-tpid>
To configure the NPE
16 Configure the UNI and NNI ports maximum frame size.
port set port <PortList> max-frame-size <NUMBER:
1522..9216>
18 Configure the provider VLAN TPID.
vlan set vlan <VlanIdList> egress-tpid <8100|9100|88A8>
19 Add the UNI and NNI ports to the provider VLAN.
20 Create a management VLAN.
21 Add the management port to the remote management VLAN.
22 Remove the ports from the default management VLANs.
vlan remove vlan <VlanList> port <PortNameList>
23 Change the remote interface to the new remote management VLAN.
interface remote set vlan <Vlan>
24 Configure the PVID and VLAN on the management port for egress untagged
traffic.
port set port <PortList> egress-untag-vlan <Vlan>
25 Configure the acceptable frame type for the ENNI port.
port set port <PortList> acceptable-frame-type
<all|tagged-only|untagged-only>

end
Example
Figure 10-32 shows an example of an E-Access EPL/EVPL where the ENNI
receives double tagged traffic with the outer SVID tag of 200 and inner CVID
tag of 100.
Figure 10-32
E-Access EPL/EVPL
ENNI I/F
UNI I/F Access Provider
Back-to-Back 2
Service
2 6
Provider
6
NPE
UPE
SVID 200:CVID 100
Configure the UPE

port set port 2 max-frame-size 9216
vlan create vlan 200 name S-tag
vlan set vlan 200 egress-tpid 88A8
vlan remove vlan 1 port 1
interface remote set vlan 128
port set port 1 pvid 128 egress-untag-vlan 128
port set port 6 acceptable-frame-type all
virtual-circuit ethernet create vc E-Access vlan 200
virtual-switch ethernet create vs E-Access vc E-Access
virtual-switch ethernet add vs E-Access port 6 vlan 100
virtual-circuit ethernet set port 2 vlan-ethertype 88A8 vlan-ethertype-policy
vlan-tpid
virtual-circuit ethernet set port 6 vlan-ethertype 88A8 vlan-ethertype-policy
vlan-tpid
Configure the NPE:

vlan create vlan 200 name S-tag
vlan set vlan 200 egress-tpid 88A8
interface remote set vlan 128
port set port 1 pvid 128 egress-untag-vlan 128

Procedure 10-19
Configuring CFM for E-Access service types
This procedure shows how to configure CFM over the User Premises
Equipment (UPE) and the Network Premises Equipment (NPE) for E-Access
service types created in Procedure 10-18.
Refer to the Fault and Performance guide for full details about CFM.
Step Action
To configure the UPE

1 Enable CFM.
cfm enable
2 Create a CFM service for the E-access virtual switch.
cfm service create
3 Enable the CFM service.
cfm service enable
4 Create an up MEP for the service for the UNI PORT+CVID.
cfm mep create
5 Send DMMs to the remote MEP:
cfm delay send
6 Set CFM service LMM interval:
cfm service set
7 Send LMMs to a remote MEP:
cfm frame-loss send
8 Display the MEP.
cfm mep show
9 Display the remote MEP
cfm remote-mep show
To configure the NPE
10 Enable CFM.
cfm enable
11 Turn off 802.1ad strict mode.
cfm set dot1ad-strict off
12 Create a CFM service for the E-access virtual switch.
cfm service create

13 Enable the CFM service.

cfm service enable
14 Create an up MEP for the service for the UNI PORT+CVID.
cfm mep create
15 Set the MEP attributes to use the tag-vid for the CVID and turn on the tag-
mode.
cfm mep set
16 Send DMMs to the remote MEP:
cfm delay send
17 Set the CFM service LMM interval:
cfm service set
18 Send LMMs to a remote MEP:
cfm frame-loss send
19 Display the MEP.
cfm mep show
20 Display the remote MEP
cfm remote-mep show
end
Example
UPE CFM for EVPL
cfm enable
cfm service create vs E-Access name ENNI-test md md4 next-mepid 611
cfm service enable service ENNI-test
cfm mep create service ENNI-test port 6 vlan 100 type up mepid 611
cfm delay send service EVPLOVC1 local-mepid 611 mepid 711 repeat 1 delay-
threshold 700 jitter-threshold 10
cfm service set service EVPLOVC1 lmm-interval 1sec
cfm frame-loss send service EVPLOVC1 local-mepid 611 mepid 711 repeat 1
cfm mep show
cfm remote-mep show
NPE CFM for EVPL

cfm enable
cfm set dot1ad-strict off
cfm service create vlan 200 name ENNI-test md md4 next-mepid 711
cfm mep create service ENNI-test port 6 type up mepid 711
cfm mep set service ENNI-test local-mepid 711 tag-vid 100
cfm mep set service ENNI-test local-mepid 711 tag-mode on
cfm mep show
cfm remote-mep show

UPE CFM for EPL

cfm enable
cfm service create vs E-Access name ENNI-test md md4 next-mepid 611
cfm mep show
cfm remote-mep show
NPE CFM for EPL

ccfm enable
cfm set dot1ad-strict on
cfm service create vlan 200 name ENNI-test md md4 next-mepid 711
cfm mep show
cfm remote-mep show

Procedure 10-20
Configuring HIM for E-Access service types
This procedure shows how to configure hierarchical ingress metering (HIM)
with traffic profiling on the UPE and NPE for E-Access service types created
in Procedure 10-18. The configuration on the UNI and ENNI is the same for
EVPL and EPL.
Refer to the <insert x-ref to QOS chapter> for full details about HIM.
Step Action
To configure the UPE UNI

1 Set the traffic profiling meter provisioning to EIR.
traffic-profiling set meter-provisioning eir
2 Set the UNI port traffic profiling to advanced mode.
traffic-profiling set port <PortName> mode advanced
3 Create a standard profile associated with the UNI port.
traffic-profiling standard-profile create port <PortName>
4 Enable traffic profiling on the UNI port.
traffic-profiling enable port <PortName>
5 Enable traffic profiling globally:
traffic-profiling enable
6 Display the traffic profiling throughput statistics:
traffic-profiling standard- throughput port <PortName>
To configure the NPE ENNI
7 Set the ENNI port traffic profiling to advanced hierarchical-vlan.
traffic-profiling set port <PortName> mode hierarchical-
vlan
8 Create a standard profile parent and child profiles associated with the ENNI
port and SVID.
traffic-profiling standard-profile create port <PortName>
9 Enable traffic profiling on the ENNI port.
traffic-profiling enable port <PortName>
10 Enable traffic profiling globally:
11 Display the traffic profiling statistics:

12 Display the traffic profiling throughput statistics for the child profile(s):
end
Example
This example shows configuration to limit the traffic rate to 50MB on the UNI
and apply a 3 Rate HIM on the ENNI.
UPE metering on UNI

traffic-profiling set port 6 mode advanced
traffic-profiling standard-profile create port 6 profile 1 name E-Access cir
50048 pir 50048 cbs 256 ebs 0 vs E-Access
traffic-profiling enable port 6
traffic-profiling standard- throughput port 6 traffic-profile E-access
NPE metering on ENNI

traffic-profiling set port 6 mode hierarchical-vlan
traffic-profiling standard-profile create port 6 profile 1 name flow1 cir
300224 pir 450048 cbs 16 ebs 16 statistics off vlan 200 child-mode standard-
dot1dpri
traffic-profiling standard-profile create port 6 profile 2 name cos0 cir
100032 pir 150016 cbs 128 ebs 128 dot1dpri 0 parent flow1
traffic-profiling standard- statistics
traffic-profiling standard- throughput port 6 traffic-profile cos0

Procedure 10-21
Configuring L2 Control Frame Tunneling for E-Access
service types
This procedure shows how to configure L2 control frame tunneling for E-
Access service types created in Procedure 10-18. The configuration is the
same for EVPL and EPL and on the UPE only.
Refer to the <insert x-ref to L2 Control Frame tunneling chapter> for full details
about HIM.
Step Action
To configure the UPE UNI

1 Configure the virtual switch for untagged data and control traffic.
port set port <PortList> untagged-data-vs
<VirtualSwitchName> untagged-ctrl-vs <VirtualSwitchName>
2 Configure the acceptable frame type for the UNI port to all.
port set port <PortList> acceptable-frame-type all
3 Enable L2 control frame tunneling for the virtual switch.
virtual-switch l2-cft enable vs <VirtualSwitchName>
4 Configure the protocols to tunnel for the virtual switch.
virtual-switch l2-cft protocol add vs <VirtualSwitchName>
Example
This example shows configuration to forward LACP.
UPE L2 control frame tunneling

port set port 6 untagged-data-vs E-Access untagged-ctrl-vs E-Access
virtual-switch l2-cft enable vs E-Access
virtual-switch l2-cft protocol add vs E-Access ctrl-protocol lacp disposition
forward
traffic-profiling standard- throughput port 6 traffic-profile E-access

Procedure 10-22
Configuring RFC 2544 Benchmarking for E-Access
This procedure shows how to configure RFC 2544 Benchmarking for E-
Access service types as created in Procedure 10-18.
Refer to the System performance testing with RFC 2544 benchmarking

chapter in the Fault and Performance Management guide for full details about
RFC 2544 Benchmarking.
Step Action

1 Set the port to test, role, and mode.
benchmark set port <port> role generator
where
2 Create the benchmark generator profile.

benchmark profile create name <String[15]>
where
name is the user-defined name for new profile.
<String[15]>
3 Set benchmark generator profile interval and duration attributes:

benchmark configuration set name <name> [interval <15Min
| 1Hr | 6Hr | Completion>] [duration <15Min | 1Hr | 6Hr |
24Hr | Indefinite | Once>]
where
name <name> is the profile to configure.
interval <15Min | is the interval time.
1Hr | 6Hr |
Completion>
duration <15Min | is the duration time.
1Hr | 6Hr | 24Hr |
Indefinite | Once>

4 Request benchmark generator profile traffic tests:

benchmark traffic set name <name> [throughput] [latency]
[PDV] [frameLoss] [rfc2544]
where
throughput is throughput test.
latency is latency test.
PDV is packet delay variation (PDV) test.
frameLoss is frame loss measurement test.
rfc2544 is a suite of tests that includes throughput, latency, and
frame loss.
5 Set benchmark generator profile payload attributes:

benchmark payload set name <name> [dstmac <MAC address:
XX:XX:XX:XX:XX:XX>] [vlan-encap-type <untagged | dot1q>]
[vid <NUMBER: 0-4095>] [pcp <NUMBER: 0-7>] [cfi <NUMBER:
0-1>] [tpid <NUMBER: 0-65535>] [pdu-type <ethernet | ip |
udp-echo>] custom-payload <String>][ip-src-addr <IP
address>] [ip-dest-addr <IP address>] [ip-dscp <NUMBER:
0-63>]
where
dstmac <MAC is the destination MAC address.
address:
XX:XX:XX:XX:XX
:XX>
vlan-encap-type is the VLAN encapsulation type. The default is untagged.
<untagged |
dot1q>
vid <NUMBER: 0- is the CVID value.
4095>
pcp is the customer priority code point (PCP) value.
<NUMBER: 0-7>
cfi is the customer canonical format indicator (CFI) value.
<NUMBER: 0-1>
tpid <NUMBER: is the customer tag protocol identifier (TPID) value.
0-65535>
pdu-type is the test PDU type. The default is ethernet.
<ethernet | ip |
udp-echo>
custom-payload is the custom payload to use with selected PDU type.
<String>

where
ip-src-addr is the IP source address.
<IP address>
ip-dest-addr is the IP destination address.
<IP address>
ip-dscp is the IP DSCP value.
<NUMBER: 0-
63>
6 Enable the benchmark profile:
benchmark profile enable name <name>
where
name <name> is the profile to enable.
7 Enable the generator:

benchmark generator enable
8 Enable the global state:
benchmark enable
9 Confirm the global and generator state and configuration:
benchmark show
10 Set the port to test, role, and mode.
benchmark set {port <Port>} [role <reflector|generator>]
[mode <in-service|out-of-service|vid-out-of-service>]}
where
port <Port> is the test port.
role <reflector| indicates the role of the test port, which is one of generator
generator> or reflector. The default is reflector.
mode <in- indicates the mode of the test port, which is one of in-service,
service| out-of-service, or vid-out-of-service. The default is in-
out-of- service.
service|vid-out-
of-service>
11 Set the reflector VID.

benchmark reflector set vid <NUMBER: 0-4095> vendor-type
<ciena | other>
where
vid <NUMBER: 0- is the SVID.
4095>
vendor-type is the generator vendor.
<ciena | other>

12 Enable the reflector.

benchmark reflector enable
13 Enable the global state.
benchmark enable
14 Confirm the configuration settings and that the global and reflector states are
enabled.
benchmark show
To check connectivity and start the test
15 Check connectivity between the generator and UNI reflector:
benchmark profile trigger name <name> connectivity-test
where
name <name> is the profile to test.
connectivity-test triggers a connectivity test on the selected profile.
16 Start the test:

benchmark profile start name <name> [dstmac <MAC address:
XX:XX:XX:XX:XX:XX>] [vid <NUMBER: 1-4095>]
where
name <name> is the profile to start.
dstmac <MAC is the destination MAC address.
address:
XX:XX:XX:XX:XX
:XX>
vid <NUMBER: 1- is the customer VLAN ID.
4095>
end
Example
This example shows configuration to forward LACP.
UPE RFC 2544 reflector for EVPL

benchmark set role generator port 6 mode vid-out-of-service
benchmark generator enable
benchmark profile create name 2544test
benchmark profile configuration set name 2544test interval Completion
benchmark profile configuration set name 2544test duration 15Min
benchmark profile configuration set name 2544test bandwidth 500
benchmark profile configuration set name 2544test vid-validation off
benchmark profile traffic set name 2544test throughput
benchmark profile payload set name 2544test dst-mac 00:23:8a:34:10:10
benchmark profile payload set name 2544test vlan-encap-type dot1q
benchmark profile payload set name 2544test vid 100
benchmark profile payload set name 2544test tpid 0x88A8
benchmark profile payload set name 2544test pdu-type udp-echo
benchmark profile enable name 2544test
benchmark set
benchmark enable

NPE RFC 2544 reflector for EVPL

benchmark set port 6
benchmark reflector set vid 200
benchmark reflector enable
benchmark set mode out-of-service
benchmark enable

Procedure 10-23
Configuring ENNI hairpin switching using sub-ports
Sub-port interfaces support ENNI hairpin switching. This procedure describes
how to configure a virtual switch for hairpin switching between sub-port
interfaces. When you create sub-port interfaces, you can specify whether you
want to turn on statistics.
For more information on links between sub-ports and MEF OVCs, see Q-in-
Q encapsulation on page 10-6.
To configure ENNI hairpin switching using a tagged sub-port on the INNI
Step Action
1 Create a virtual switch:

virtual-switch add reserved-vlan <VLAN ID>
virtual-switch ethernet create vs <virtual-switch-name>
2 Create a tagged INNI sub-port.
sub-port create sub-port <sub-port-name> parent-port
<port-name> vtag-stack <VLAN-ID> statistics <on|off>
Note: Optionally, statistics can be enabled on a per-sub-port basis. If you do
not specify an option, the default is off.
3 Attach the INNI tagged sub-port interface to the virtual switch:
virtual-switch ethernet attach sub-port <sub-port-name>
vs <virtual-switch-name>
4 Create the sub-port interfaces for the tagged ENNI port:
<port-name> vtag-stack <VLAN ID> statistics <on|off>
5 Attach the tagged ENNI sub-port interfaces to the virtual switch
6 View your configuration.
sub-port show
To configure ENNI hairpin switching using an untagged sub-port on the INNI
7 Create a virtual switch:
virtual-switch add reserved-vlan <VLAN ID>
virtual-switch ethernet create vs <virtual-switch-name>

8 Create an untagged INNI port.

<port-name> vlan-untagged-data statistics <on|off>
Note: Optionally, statistics can be enabled on a per-sub-port basis. If you do
not specify an option, the default is off.
9 Attach the INNI untagged sub-port interface to the virtual switch:
10 Create the sub-port interfaces for the tagged ENNI port:
<port-name> vtag-stack <VLAN ID> statistics <on|off>
11 Attach the tagged ENNI sub-port interfaces to the virtual switch
12 View your configuration.
sub-port show
where
<VLAN ID> is a particular VLAN ID which has not already been
configured on the device.
<virtual-switch- is a unique virtual-switch name to identify this virtual switch
name> instance.
<sub-port-name> is a unique sub-port name to identify this sub-port instance.
<port-name> identifies a particular port configured on the device.
<on|off> identifies whether statistics will be on or off for a particular
sub-port. The default is off.
end
Example
The following example configures ENNI hairpin switching using a tagged INNI
sub-port.

virtual-switch ethernet create vs vs4000
sub-port create sub-port inni.100 parent-port 1 vtag-stack 100

statistics on
virtual-switch ethernet attach sub-port inni.100 vs vs4000
sub-port create sub-port enni.2023 parent-port 2 vtag-stack

2023 statistics on
1028 statistics on

virtual-switch ethernet attach sub-port enni.2023 vs vs4000

The following example configures ENNI hairpin switching using an untagged

INNI sub-port.

virtual-switch ethernet create vs vs4000
sub-port create sub-port inni.untagged parent-port 1 vlan-

untagged-data statistics on
virtual-switch ethernet attach sub-port inni.untagged vs vs4000

1028 statistics on
2023 statistics on


Procedure 10-24
Displaying statistics for sub-port interfaces
You can display the administrative and operational attributes for all sub-port
interfaces on a device or for a specific list of sub-port interfaces. When the
statistics option is specified, the statistics counts for all sub-port interfaces that
have statistics currently enabled are displayed.
To display statistics for sub-ports with statistics enabled and non-zero
Step Action
1 Display statistics for sub-port interfaces on the device.

sub-port show statistics
To display statistics for sub-ports with statistics enabled and non-zero with a specified parent
port
2 Display statistics for sub-port interfaces that have the port specified as its
parent port.
sub-port show parent-port <port-name> statistics
where
<port-name> is the specified parent port you want to display statistics for.
To display statistics for sub-ports or a list of sub-ports

3 Display statistics for a specific sub-port or list of sub-ports.
sub-port show sub-port <sub-port-name-list> statistics
where
<sub-port-name- is the particular sub-port or list of sub-ports that you want to
list> display statistics for.
Example
The following example shows sample output for the sub-port show parent-port
statistics command.
> sub-port show statistics

+--------------------------- SUB-PORT STATISTICS SUMMARY --------------------+
| Sub-Port | Byte | Pkt |
| | Tx | Rx | Tx | Rx |
+--------------+----------------+----------------+----------------+----------+
| sp1.v101.p9 | 574563251000 | 0 | 574563253 | 0 |
| sp2.x102.p9 | 0 | 574563260000 | 0 | 574563260|
| sp3.v103.p10 | 574563271000 | 0 | 574563273 | 0 |
+--------------+----------------+----------------+----------------+----------+
The following example shows sample output for the sub-port show parent-port
<parent-port-name> statistics command.

> sub-port show parent-port 9 statistics

+------------------------- SUB-PORT STATISTICS FOR PARENT 9------------------------+
| Sub-Port | Byte | Pkt |
| | Tx | Rx | Tx | Rx |
+--------------+----------------+----------------+----------------+----------------+
| sp1.v101.p9 | 574563251000 | 0 | 574563253 | 0 |
| sp2.x102.p9 | 0 | 574563260000 | 0 | 574563260 |
+--------------+----------------+----------------+----------------+----------------+
The following example shows sample out put for statistics display command
on a single sub-port.
sub-port show sub-port sp1.v101.p9,sp2.x102.p9 statistics
+----------- SUB-PORT sp1.v101.p9 STATISICS -----------+

| Direction | Bytes | Packets |
+--------------+-------------------+-------------------+
| Rx | 0 | 0 |
| Tx | 4604013142000 | 4604013152 |
+--------------+-------------------+-------------------+
+----------- SUB-PORT sp2.x102.p9 STATISICS -----------+

| Direction | Bytes | Packets |
+--------------+-------------------+-------------------+
| Rx | 4604013198000 | 4604013201 |
| Tx | 0 | 0 |
+--------------+-------------------+-------------------+

Procedure 10-25
Clearing statistics for sub-port interfaces
You can clear statistic counts for all sub-port interfaces on a device or for a
specific list of sub-port interfaces.
Step Action
1 Clear statistics counts for sub-port interfaces.

sub-port clear sub-port <sub-port-object-list> statistics
where
<sub-port-object- is a list of sub-ports which have already been configured on
list> the device.
Example
The following example clears statistics counts for a single sub-port interface:
sub-port clear sub-port sp1.v101.p9

11-1
Provider Backbone Bridge Traffic

Engineering (PBB-TE) implementation 11-
This chapter details the implementation of Provider Backbone Bridge Traffic

Engineering (PBB-TE), formerly referred to as Provider Backbone Transport
(PBT), in the core of a Ciena network.
VLAN Tagging
Connectivity Fault Management
Benefits
Note: PBB-TE CLI commands continue to use PBT rather than PBB-TE
as the initial implementation was based on PBT.
A basic understanding of the IEEE 802.1Qay, IEEE 802.1Q, 802.1ad, and

802.1ah standards is assumed. In addition, it is highly recommended that
CFM (IEEE 802.1ag) be used to monitor the PBB-TE service to warn if any
faults occur in the service.
Table 11-1 summarizes PBB-TE for 39XX/51XX switches. Native PBB-TE

support is hardware-based.
Table 11-1
PBB-TE support for 39XX/51XX switches
Platform Non-native PBB-TE Native PBB-TE Ports
3916 Not supported Supported All ports
3940 Supported Not supported Enhanced ports only

11-2 Provider Backbone Bridge Traffic Engineering (PBB-TE) implementation
Table 11-1
PBB-TE support for 39XX/51XX switches
Platform Non-native PBB-TE Native PBB-TE Ports
5150 Supported (default) Supported All ports in native mode

Enhanced ports in non-
native mode
VLAN Tagging
The IEEE 802.1Q standard specifies a mechanism for adding tags to Ethernet
frames. This tagging allows an Ethernet network to be divided into virtual
networks or VLANs. Generally, individual customers in a providers network
are identified by unique VLAN IDs. Additionally, each customer typically uses
VLAN IDs in their own network to differentiate between service types (for
example, data or VoIP) and possibly to distinguish between departments. This
three-tier hierarchy allows separate domains for the service provider,
customer and individual enterprise departments.
Given the 12-bit size of the VLAN field in an Ethernet frame, the number of
available VLAN IDs is limited to 4,096. In a large provider network, the number
of customers could easily exceed 4,000, exhausting the available VLAN IDs
very quickly. To help improve network scalability, two standards have been
introduced to support this hierarchical approach, IEEE 802.1ad and IEEE
802.1ah.
Q-in-Q
The IEEE 802.1ad (also known as Q-in-Q, stacked VLANs, or Provider
Bridges), extends the original concept of VLAN tags by specifying a new
provider-administered 802.1Q tag (Q-tag) that wraps or encapsulates the
original customer packet in an additional header. This allows the service
provider to administer their own tags to identify individual customer networks,
while the first (original) Q-tag is unique within the customers own network.
This then allows for overlap between the customer and provider VLAN IDs
since the customer Q-tag is hidden while it is transported through the provider
network. However, while this Q-in-Q approach supports a three-tiered
hierarchy and frees up additional VLAN IDs, the service provider can still only
create 4,094 customer VLANs. Scalability is still an issue as 4,000 tags is
simply insufficient for large metropolitan networks. This shortcoming is
addressed by the second standard, IEEE 802.1ah.

Provider Backbone Bridge Traffic Engineering (PBB-TE) implementation 11-3
MAC Header Encapsulation

The IEEE 802.1ah standard, also known as MAC header encapsulation
(MAC-in-MAC) or Provider Backbone Bridging, encapsulates the customer
MAC header with a MAC header for the service provider. A 24-bit service tag
that identifies individual subscribers, is also used in the service provider MAC
header. This enables a maximum of 16 million service instances to be
supported, thus alleviating the scalability issue entirely.
With IEEE 802.1ah, the overall network is treated as separate service provider
and end customer domains. In the service provider domain, the network
switches on the service provider MAC header and the customer MAC is not
even visible. This introduces strict demarcation between the customer and
service provider, enabling a truly hierarchical approach to the network. MAC-
in-MAC greatly improves the scalability of Layer 2 networks.
This approach also alleviates another limitation to traditional Ethernet;

learning. Traditional Ethernet switch-based networks have two defining
characteristics that limit their topological size, namely learning and loop
avoidance. When a switch receives a packet destined for an end station it
does not yet know about, it floods the packet down every link on which it is
connected. This is referred to as Flood for Unknown. As the switch inspects
every packet it receives, it remembers or learns the association of sending
stations and ingress links. Each switch in the layer 2 domain learns the
address and associated link for every other device in the network.
While many metro and core devices may be able to support hundreds of
thousands of addresses, requiring each device in a providers network to
handle this number of addresses is cost prohibitive and impacts protection
switching schemes. MAC-in-MAC encapsulation solves this Layer 2 scalability
problem since there are now fewer MAC addresses to learn at the core.
The IEEE 802.1ah MAC header, specifies that a backbone VLAN tag (B-tag),
and an instance service VLAN tag (I-tag) be added to packets traversing the
provider backbone bridge. This extended service VLAN tag is mapped from
the Service VLAN ID tag and is not any longer than a normal VLAN tag. The
additional B-tag is then added to ensure that the switches in the middle of the
802.1ah core do not need to know about the 802.1ah functions, thus ensuring
backward compatibility. The backbone MAC header is then removed at the
other end of the providers 802.1ah backbone bridge. A big advantage of
802.1ah is that it works in conjunction with the 802.1ad Provider Bridges
VLAN stacking standard to allow both techniques to be used simultaneously.

PBB-TE Tunnels
Note: When using PBB-TE, RSTP/MSTP should not be enabled as all
PBB-TE ports need to be in the forwarding state. For example, if RSTP/
MSTP is enabled it could block one of the PBB-TE ports and thus remove
the backup tunnel.
PBB-TE has emerged to further address limitations related to scalability and

reliability. PBB-TE may be deployed in place of PBB or may run in parallel with
PBB. In both cases, PBB-TE eliminates the need for backbone core devices
to perform learning and flooding. Instead, point-to-point tunnels to transport
L2VPNs are provisioned. Rather than using RSTP/MSTP to prevent loops, the
tunnels are used to traffic engineer the provider backbone network.
A PBB-TE tunnel is unidirectional and is set up to ingress on a local node at

one edge of the provider backbone and to terminate on a remote device at the
other end of the backbone. This tunnel transports encapsulated subscriber
frames from the local node to the remote node. A second tunnel is then
configured in the opposite direction to ingress the remote node and terminate
on the local node. This serves as the transport for the reverse traffic. A tunnel
pair together make a bidirectional pipe referred to as a PBB-TE trunk.
PBB-TE tunnels are set up to transport Ethernet Virtual Circuits (IEEE

802.1ad), with the subscriber frames encapsulated using 802.1ah MAC-in-
MAC encapsulation. Tunnels are then identified by the Backbone Destination
Address (B-DA) and the Backbone Tag (B-Tag). In Figure 11-1, the highlighted
fields are added to the frame to identify tunnels and to identify flood domains
and interconnects.
Figure 11-1
PBB-TE Frame Format
Tunnel Identifier
Tunnel Identifier
Since the tunnels are point-to-point, PBB-TE can also achieve recovery times
approaching 50 ms. Providers can set up primary and protection PBB-TE
paths and then leverage Carrier Ethernet OAM standard CFM (IEEE 802.1ag)
to monitor the tunnels. This provides fault notifications in milliseconds and
thus carrier-grade failover times can be achieved.

Figure 11-2 shows an example PBB-TE network with the core provider
network in the center and three access networks attached to the core. In the
core, primary tunnels are configured (solid lines) as well as backup tunnels
(dotted lines) in order to provide resiliency and greater utilization of the
backbone network. Again, in the core, there is no loop detection and no
learning.
Figure 11-2
Example of a PBB-TE Network
The system software supports configuration of a maximum of 32 PBB-TE

bidirectional tunnels. However, one PBB-TE tunnel may be used to transport
multiple subscriber services. In addition, one virtual circuit must be created for
each service instance. A maximum of 127 virtual circuits are supported by one
PBB-TE tunnel. PBB-TE tunnels may also be configured across link
aggregation ports.
The PBB-TE virtual circuit must be attached to a virtual switch before

subscriber ports are attached. When detaching a PBB-TE virtual circuit from
a virtual switch, subscriber ports must be detached first.

Note: In PBB-TE native mode, PBB-TE subscribers and Q-in-Q

subscribers cannot be on the same port.
Figure 11-3 depicts two Provider Bridged networks interconnected by a PBB-

TE network. Two customer Layer 2 Virtual Private networks are shown
traversing primary and backup PBB-TE tunnels through the core network.
Figure 11-3
A PBB-TE Network with Primary and Backup Tunnels
Traffic from Customer A originates at its Site 1. The Provider Bridge

encapsulates the customer traffic by adding a Subscriber S-Tag containing the
configured S-VID value of 100 reserved for Customer A within its domain. This
traffic is then sent to the Provider Backbone Edge Bridge A (PBEB-A).
PBEB-A has been configured to assign Customer A traffic (S-VID=100) to a

24-bit Instance Service Identifier (I-SID) value of 10,000. This I-SID value is
associated with a primary and a backup PBB-TE tunnel. Each primary and
backup tunnel is identified using the combination of a PBEB Destination MAC
address and a Backbone-VID (B-VID). This is a significant difference between
PBB-TE and PBB. In PBB, B-VIDs represent flood domains that interconnect
multiple Provider Bridged networks. In PBB-TE, B-VIDs together with B-DAs
identify which tunnel the frame will use.
In our example, the PBEB-A encapsulates S-VID 100 traffic by adding the B-
DA value for PBEB-D, a B-SA value for PBEB-A, a B-VID value of 4001
(primary tunnel), and the I-SID value of 10,000. This MAC header
encapsulated traffic is forwarded to Provider Backbone Core Bridge-C
(PBCB-C). PBCB-C has been configured to not learn or flood traffic on B-VID

4001, which has been reserved for PBB-TE use. The fact that PBB-TE does
not learn or flood is an important point. Each PBCB device must be
provisioned with forwarding database entries in order to properly forward
traffic within the tunnels.
The PBCB-C forwarding table learns an entry for the combination of PBEB-D,
B-VID 4001 and the traffic is forwarded on the particular port in the direction
of PBEB-D. PBEB-D receives the traffic and removes the MAC header
encapsulation. Since the S-VID values are only locally significant to the
Provider Bridged network, a provider has the flexibility to translate the S-VID
value. In our example, PBEB-D has been configured to associate I-SID 10,000
with S-VID 110.
In this illustration, traffic from the tunnel is de-encapsulated and the S-VID is
remapped to the value of 110. The traffic is forwarded to the provider bridge
attached to Customer As Site 2. The S-Tag encapsulation is removed by the
PB device and the original customer frame from Site 1 is delivered to Site 2.
Note: It should also be noted that the PBB-TE service tag is 22 Bytes in
length and this needs to be taken into account when calculating available
bandwidth. For example, when sending a 64-Byte packet at 100% of line
rate through a PBB-TE tunnel, each 64-Byte frame is actually 86 Bytes
long (64 + 22).
Connectivity Fault Management

PBB-TE virtual switches and tunnels are monitored through the use of IEEE
802.1ag Connectivity Fault Management (CFM) Continuity Check Messages
(CCM). When CFM services are configured for PBB-TE virtual switches, CCM
control frames are sent and received within the PBB-TE tunnels and monitor
faults based on the associated PBB-TE virtual circuit events. For CFM
services that monitor PBB-TE tunnels, CCM control frames are sent and
received regularly along the PBB-TE tunnels. If the primary tunnel should
experience a fault, the tunnel endpoints automatically begin using the backup
tunnel. The forwarding database entries are pre-configured along the backup
path to minimize the failover and restoration times. Only one backup tunnel
can be created.

Figure 11-4
PBB-TE with CFM
up Tu
ck n ne
Ba l
MEP A MEP B
Ingress
Primary Tunnel
PBB-TE
Edge Bridge Egress PBB-TE
MEP C MEP D Edge Bridge
Note: Inner tag priority is used for scheduling frames when service levels
and mappings are applied to ports associated with PBB-TE tunnels. To
ensure proper QoS treatment of transiting CCM frames, which have a
single B-VID tag, an outer tag is pushed onto the frame. The addition of
this outer tag enables the inner tag priority to be detected correctly so that
these CCM frames are scheduled properly. Upon egress, the outer tag is
popped.
It should be noted that once a failover occurs (switching the path from the
primary to the backup tunnel), the default behavior is for the provisioned
primary tunnel to become the backup tunnel unless tunnel reversion is
configured using the pbt set tunnel-reversion command. The
tunnel-reversion command will automatically revert traffic back to the
provisioned primary tunnel once it is up and the reversion hold timer is
completed (pbt set reversion-hold-time).
Example
> pbt set tunnel-reversion off
> pbt set reversion-hold-time 3000
Manual reversion allows the network operator to control when or if the
reversion will take place (such as late at night or on a weekend) so that the
impact to the service is minimum. Manual reversion also prevents flapping
between the two tunnels if the primary is not entirely stable. Automatic tunnel
reversion is useful if the backup tunnel is inferior to the primary tunnel. Thus,
failback occurs automatically.
Note: When configuring PBB-TE reversion, tunnel reversion must be

enabled on all remote bridges and the reversion hold time must be set to
the same value. If reversion settings are not symmetrical, it can cause
issues with indicating the primary/backup tunnel and can cause delays in
reversions.

Ciena supports the draft IEEE 802.1ag CFM including MAC ping, MAC
traceroute, and CCM. Using these powerful CFM tools, both service
connectivity and PBB-TE tunnel resiliency is enhanced. In addition, CCM
thresholds can be configured to fine-tune protection switching.
PBB-TE Dual Homing

The system software also supports the dual homing of primary and backup
tunnels. This enables PBB-TE tunnels to terminate on entirely separate
devices. This offers device redundancy and path diversity for upstream
connections.
In Figure 11-5, device A is dual homed to device B and device C. This offers
link resiliency, such that if device B fails, traffic is then diverted to the backup
tunnel terminating at device C.
Figure 11-5
PBB-TE Dual Homing
l
n ne
Tu
a ry
im
Pr
C
Ingress Backup Tunnel
PBB-TE
Edge Bridge A
Dual homing is configured by specifying a unique MAC address and bridge

name when using the pbt remote-bridge create bridge-name command.
This second remote bridge is then specified when creating the backup tunnel.
Tunnel Pairing and Synchronization

Although PBB-TE tunnels are set up as trunks, and both an encapsulation and
a decapsulation tunnel are required for traffic transport, the tunnel states are
not automatically linked together. This makes it possible for the encap and
decap tunnels to have different operational states.
For example, if the encap tunnel was down due to misconfiguration, the decap
tunnel could still be up and running. This would allow incoming traffic to be
decapsulated, thus providing only unidirectional traffic on the circuit. This
creates a problem with devices on the terminating end of the tunnels. They
would accept all frames regardless of their B-VID value.

To avoid this behavior, encap and decap tunnels should be tied together using
the tunnel pair create command. By pairing encap and decap tunnels,
traffic on an interface is dropped unless the B-VID is specifically configured.
In addition, it synchronizes the operational state of the two tunnels. When one
tunnel goes down, encap or decap, CCMs are sent over the interface to
ensure that the device on the other end takes both tunnels down. The tunnel
state will remain down until the MEPs on the other devices have verified
connectivity.
In Figure 11-6, the encap tunnel on device B goes down. Device B then sends
a CCM error code to device A. Device A then takes down both the primary
encap and decap tunnels and a failover occurs to the backup tunnel.
Figure 11-6
Tunnel Pairing Example
Encap
Tunnel Tunnel
Pair Decap
B
Tunnel
el
nn
Tu
m ary
i
Pr
C
Backup Tunnel
To ensure synchronization between primary and backup tunnels, you can

enable tunnel synchronization. When tunnel synchronization is turned on for
the primary tunnel, a deactivation of either the primary or backup tunnel
causes CCMs to be transmitted to the inactive tunnel. This feature enables
interoperability with devices running the same system software. By default,
tunnel synchronization is disabled.
Benefits
The main benefits of PBB-TE include:
Removing the 4,000 tag limitation, enabling 16 million distinct services to
be configured.
No learning or flooding in the core of the network for a reduction in
complexity and cost.
Customer MAC address and other information is tunneled through the
providers network, enhancing security and scalability.
Using specifically engineered paths or tunnels allows the provider to target
maximum utilization of the core network devices.

The customer and Provider control domains are separated, allowing layer
2 control frames to be transported through the providers network.
802.1ag CFM can be used to monitor tunnels and provide carrier-grade
failover detection.
This chapter provides the following procedures for PBB-TE:

Verifying that a port can participate in PBB-TE on page 11-12
Switching from non-native to native PBB-TE support on page 11-13
Enabling tunnel synchronization on page 11-14
Disabling tunnel synchronization on page 11-15
Configuring PBB-TE on page 11-16
Releasing reserved BVIDs on page 11-33
Displaying PBB-TE information on page 11-34

Procedure 11-1
Verifying that a port can participate in PBB-TE
Verify that a port can participate in PBB-TE before using the port in a PBB-TE
configuration. Ports that can participate in PBB-TE have enhanced
capabilities.
You can display the capabilities of

a selected port
all ports
ports on a blade
Note: All ports on the 3916, 3930, 3931, 3932, 5142, 5150, and 5160
platforms are supported by native PBB-TE.
Step Action
To display the capabilities of a selected port

1 Display the capabilities of a selected port:
port show port <port> capabilities
where
port <port> is the port that you want to verify for PBB-TE participation.
capabilities displays the capabilities of the port.
To display the capabilities of all ports

2 Display the capabilities of all ports:
port show capabilities
To display the capabilities of all ports on a blade
3 Display the capabilities of all ports on a blade:
blade show capabilities
end

Procedure 11-2
Switching from non-native to native PBB-TE support
The 5150 platform can operate in non-native mode or native mode for PBB-
TE support. Native mode is hardware-based. By default, the 5150 platform
operates in non-native mode.
In non-native mode, the 5150 supports PBB-TE on enhanced ports only.
In native mode, the 5150 platform supports PBB-TE on all ports.
CAUTION
No automated conversion of management configuration
between non-native mode and native mode on 5150 platform
If you are currently using management over PBB-TE and you
plan to switch from non-native mode to native mode on a 5150
platform, contact Ciena support personnel to obtain details on
how this conversion is best accomplished.
Step Action
1 Switch from non-native to native PBB-TE support:

pbt set mode native
2 Save the configuration:
configuration save
3 Reboot the device:
chassis reboot now
end

Procedure 11-3
Enabling tunnel synchronization
You can enable tunnel synchronization
when creating a tunnel
for an existing tunnel
Step Action
To enable tunnel synchronization when creating a tunnel

1 Enable tunnel synchronization when creating a tunnel:
tunnel encap create static-pbt <static-pbt> tunnel-sync
on
where
<static-pbt> is the name of the tunnel.
To enable tunnel synchronization for an existing tunnel:

2 Enable tunnel synchronization for an existing tunnel:
tunnel encap set static-pbt <static-pbt> tunnel-sync on
where
end

Procedure 11-4
Disabling tunnel synchronization
You can disable tunnel synchronization
when creating a tunnel
for an existing tunnel
Step Action
To disable tunnel synchronization when creating a tunnel

1 Disable tunnel synchronization when creating a tunnel:
tunnel encap create static-pbt <static-pbt> tunnel-sync
off
where
To disable tunnel synchronization for an existing tunnel:

2 Disable tunnel synchronization for an existing tunnel:
tunnel encap set static-pbt <static-pbt> tunnel-sync off
where
end

Procedure 11-5
Configuring PBB-TE
Configuring PBB-TE comprises the following:
Prepare the device for PBB-TE
Configure PBB-TE parameters
Configure PBB-TE tunnels
Optionally configure PBB-TE back-up tunnels
Configure the virtual circuit
Configure the virtual switch
Configure in-band management (non-native PBB-TE)
Configure in-band management (native PBB-TE platform
Configure CFM on a PBB-TE virtual switch
Configure CFM on a PBB-TE tunnel
Optionally configure QoS on a PBB-TE tunnel
Note: It is recommended that you manually set the B-SA PBB-TE bridge
MAC address. If you do not set the B-SA PBB-TE bridge MAC address,
the system software will send the chassis base MAC address as the B-SA.
In the event of a hardware failure, the chassis base MAC would change,
requiring configuration changes on other devices configured to use this
device as a remote bridge. This setting needs to be unique from the B-SA
for all devices.
Note that configuration of the backup tunnel is optional, but recommended.

The tunnel name must also be the same as the primary tunnel.
Configuring a virtual circuit for PBB-TE involves setting the ingress I-SID for
service identification, the egress I-SID, the destination node, and the PBB-TE
tunnels to be used.
Note: The system can automatically assign a reserved VLAN to a PBB-

TE virtual switch upon creation or you can optionally specify a reserved
VLAN. This reserved VLAN becomes the S-VID in the S-Tag used upon
encapsulation. You can configure the VC to retain this S-Tag upon
encapsulation by setting the VC retain-stag attribute to yes. When this
attribute is set to yes, then the decapsulated frame must have the S-Tag
that matches the reserved VLAN of the VS and the egress ISID of the VC;
otherwise, it will be dropped.

The number of VCs supported for PBB-TE depends upon the platform
capabilities as shown in Table 11-2.
Table 11-2
PBB-TE virtual circuits supported per platform
Platform VCs
3916,3930,3931, 3932 256
3940, 5140 128
3960, 5142, 5150, 5160 512
Note: The number of VCs supported for PBB-TE is reduced by the

number of VCs configured for Q-in-Q.
When configuring a virtual circuit, you can choose to either replace the CVID
or push an SVID on the existing CVID. As such, the replace-ctag and retain-
stag options are mutually exclusive.
Replacing the CVID is not supported for in band management traffic. As such,
the replace-ctag and mgmt-vc options are mutually exclusive.
Configuring a virtual switch for PBB-TE involves creating reserved VLANs,

designating the PBB-TE VC to be used with the virtual switch, and adding
subscriber ports/VLANs. Optionally, Encap CoS policies may also be set for
CoS mapping between the customer frames and the encapsulation PBB-TE
tunnel header.
The number of VSs and members supported for PBB-TE depends upon the
platform capabilities as shown in Table 11-3.
Table 11-3
PBB-TE virtual switch capabilities
Platform VSs VS members per VS members per

port switch
3916, 3930, 3931, 256 512 512

3932
3940, 5140 128 512 512
3960 512 2048 2048
5142, 5150, 5160 512 3584 3584

Note: For 3940, 3960, 5140, and 5150 platforms, the number of VSs and
VS members per port and switch supported for PBB-TE are reduced by
the number of VSs and VS members per port and switch configured for Q-
in-Q.
Management VLAN traffic can be tunneled through a PBB-TE tunnel in non-

native mode by creating a management VC. The management VC creation
implicitly creates a management VS that can be displayed using show
commands but there are not any operations that can be performed on the
management VS. The management VC (mgmt-vc) will automatically take the
place of the remote management interface vlan. Only one management VC
can be created, and ports must be explicitly added to and deleted from the
management VLAN in order to be encapsulated in a PBB-TE tunnel.
When using native mode, management traffic can be tunneled through a PBB-
TE tunnel by using a management VS. Such a management VS is manually
configured and explicitly associated with the remote interface by the user.
Configuring CFM for the PBB-TE virtual switch requires enabling CFM
globally, creating a CFM service using the PBB-TE virtual switch, and then
enabling the service. CCMs and other CFM frames are transmitted out the
PBB-TE virtual circuit as PBB-TE data frames with full PBB-TE service
encapsulation and are forward to the virtual switch member ports after the
PBB-TE service header is removed.
Configuring CFM for the PBB-TE tunnels requires enabling CFM globally,
creating a CFM service using the PBB-TE tunnel, and then enabling the
service.
Configuring QoS for PBB-TE involves setting any traffic metering required at
the ingress (UNI) and setting the CoS marking policy. Only advanced mode is
supported on platforms with native PBB-TE, that is, 3916, 3930, 3931, 3932,
5142, 5150, and 5160.
Step Action
To prepare the device for PBB-TE

1 View software licence information:
software license show
2 Ensure that MSTP or RSTP is disabled either globally or on the individual
encap and decap tunnel port:
mstp disable
mstp show

or
rstp disable
rstp show
To configure PBB-TE parameters
3 Configure the PBB-TE bridge MAC that will be used as the B-SA in the
frames.
pbt set bridge-mac <MAC address: XX:XX:XX:XX:XX:XX>
reversion-hold-time <MILLISECONDS> service-tag-ethertype
<NUMBER: 1-65535> transit-tunnel-ethertype-remark <on |
off> tunnel-reversion <on | off> tunnel-tag-ethertype
<NUMBER: 1-65535> pbt set stag-tpid <8100|9100|88A8> mode
<native|non-native>
where
bridge-mac <MAC is the MAC address for the device used for PBT.
address:
XX:XX:XX:XX:XX:
XX>
reversion-hold-time is reversion hold time in milliseconds.
<MILLISECONDS>
service-tag- is the ether-type for the I-tag. In native mode, the default
ethertype value of 0x88e7is used: it is not configurable.
<NUMBER: Note: to avoid potential traffic loss, do not use Ethertype
1-65535>
values of 0x8100, 0x88a8, or the configured CFM Ethertype
(default 0x8902). In addition, switches are hard-coded to
recognize 0x88e7 as a valid service tag. PBB-TE frames
with the 0x88e7 service tag are received and processed in
addition to the configured service tag. In order to transmit
PBB-TE frames with the I-TAG of 0x88e7, set the service tag
to 0x88e7.
transit-tunnelis the remark B-tag ether-type for frames in transit.
ethertype-remark
<on | off>
tunnel-reversion sets the reversion behavior from backup to primary.
<on | off>

where
tunnel-tag- is the ether-type for the B-tag. The default value is 0x88a8.
ethertype The etype values are restricted to 0x8100, 0x9100 and
<NUMBER: 0x88a8.
1-65535> Note: In order for PBB-TE frames to be transmitted through
a legacy VLAN switch, the PBB-TE tunnel tag Ethertype
must be set to 0x8100 (33024 decimal). This is not
supported in native PBB-TE (3916,3930,3931, and 5150),
and therefore transit switches must be configured to mark
packets as 88a8 such as:
vlan set vlan 100 egress-tpid 88a8
virtual-circuit ethernet set port 7,10 vlan-
ethertype-policy vlan-tpid
pbt set stag-tpid is the stag-tpid etype.
<8100|9100|88A8> This attribute is not configurable in non-native mode.
mode <native| is the PBB-TE mode.

non-native>
4 Reserve Bridge VLAN IDs (B-VIDs). Each incoming tunnel requires a unique
B-VID.
pbt reserve bvid <VLAN ID List>
where
bvid <VLAN ID is the VLAN list.
List> Note: The maximum number of B-VIDs that can be
reserved is equal to the maximum number of PBB-TE
tunnels, which is 32.
5 Configure remote bridge names for use in tunnels and virtual circuits. For
operator convenience, tunnel endpoints can be identified with names by
associating a MAC address with name. The subsequent Tunnel and VC
configurations refer to the nodes by these names.
pbt remote-bridge create bridge-name <bridge-name>
bridge-mac <MAC address: XX:XX:XX:XX:XX:XX>
where
bridge-name is the bridge name.
<bridge-name>
bridge-mac is the MAC address for the node.
<MAC address:
XX:XX:XX:XX:XX
:XX>

To configure PBB-TE tunnels

6 Configure the encapsulation tunnel:
tunnel encap create static-pbt <static-pbt> {b-vid
<NUMBER: 2-4094>} {dest-bridge-name <PBT Bridge Name>}
encap-cos-policy <fixed|vc-inherit|vs-inherit|rcos-
mapped> encap-fixed-pcp <NUMBER: 0-7> {port <Port>}
tunnel-sync <on|off>
where
static-pbt <static- is the primary tunnel name.
pbt>
b-vid <NUMBER: is the encapsulation B-VID.
2-4094>
dest-bridge- is the destination bridge.
name <PBT
Bridge Name>
encap-cos-policy is the encapsulation CoS policy.
<fixed | vc-inherit
| vs-inherit>
encap-fixed-pcp is the encapsulation fixed PCP.
<NUMBER: 0-7>
port <Port> is the outgoing port for the tunnel.
tunnel-sync is the state of tunnel synchronization.
<on|off>
7 Configure the decapsulation tunnel:

tunnel decap create static-pbt <static-pbt> {b-vid
<NUMBER: 2-4094>} {port <Port>} {src-bridge-name <PBT
Bridge Name>}
where
static-pbt <static- is the tunnel name.
pbt>
b-vid <NUMBER: is the decapsulation B-VID.
2-4094>
port <Port> is the incoming port for the tunnel.
src-bridge-name is the source bridge.
<PBT Bridge
Name>

8 Pair the primary encapsulation and decapsulation tunnels:

tunnel pair create tnl-pair <tnl-pair> {encap-pbt <PBT
Primary Tunnel Name>] [encap-backup-pbt <PBT Backup
Tunnel Name>] {decap-pbt <PBT Decap Tunnel Name>}
where
tnl-pair <tnl-pair> is the tunnel pair name.
encap-pbt <PBT is the primary encapsulation tunnel.
Primary Tunnel Note: The BVID must be the same for paired encapsulation
Name>
and decapsulation tunnels.
encap-backup- is the backup encapsulation tunnel.
pbt <PBT Backup
Tunnel Name>
decap-pbt <PBT is the decapsulation tunnel.
Decap Tunnel
Name>
To configure the PBB-TE backup tunnels

9 Configure the backup encapsulation tunnel:
tunnel encap create static-backup-pbt <static-backup-pbt>
{b-vid <NUMBER: 2-4094>} {dest-bridge-name <PBT Bridge
Name>} encap-cos-policy <fixed | vc-inherit | vs-inherit>
encap-fixed-pcp <NUMBER: 0-7> {port <Port>}
where
static-backup-pbt is the backup tunnel name.
<static-backup-
pbt>
b-vid <NUMBER: is the encapsulation B-VID.
2-4094>
dest-bridge- is the destination bridge.
name <PBT
Bridge Name>
<fixed | vc-inherit
| vs-inherit>
encap-fixed-pcp is the encapsulation fixed PCP.
<NUMBER: 0-7>
port <Port> is the outgoing port for the tunnel.

10 Configure the backup decapsulation tunnel:

tunnel decap create static-pbt <static-pbt> {b-vid
<NUMBER: 2-4094>} port <Port> src-bridge-name <PBT Bridge
Name>}
where
static-pbt <static- is the tunnel name.
pbt>
b-vid <NUMBER: is the decapsulation B-VID.
2-4094>
port <Port> is the incoming port for the tunnel.
src-bridge-name is the source bridge.
<PBT Bridge
Name>
11 Pair the backup encapsulation and decapsulation tunnels:

tunnel pair create tnl-pair <tnl-pair> encap-backup-pbt
<PBT Backup Tunnel Name> decap-pbt <PBT Decap Tunnel Name>
where
tnl-pair <tnl-pair> is the tunnel pair name.
encap-backup- is the backup encapsulation tunnel.
pbt <PBT Backup Note: The BVID must be the same for paired encapsulation
Tunnel Name>
and decapsulation tunnels.
decap-pbt <PBT is the decapsulation tunnel.
Decap Tunnel
Name>
12 Display the tunnel configuration information to verify the configuration:

tunnel encap show

To configure the virtual circuit

13 Configure the virtual circuit:
virtual-circuit pbt create static-vc <static-vc> {egress-
isid <NUMBER: 1-16777215>} {ingress-isid <NUMBER: 1-
16777215>} {mgmt-vc <no|yes>} {replace-ctag <yes|no>}
{ctag <1-4095>} {tunnel <PBT Primary Tunnel Name>}
{retain-stag <no|yes>} {s-tag <NUMBER: 1-4095>}
where
static-vc is the PBB-TE virtual circuit name.
<static-vc>
egress-isid is the egress I-SID.
<NUMBER: 1- Note: Egress I-SID and ingress I-SID values must be the
16777215>
same when using native PBB-TE, that is, 3916, 3930, 3931,
and 5150 platforms.
ingress-isid is the ingress I-SID.
<NUMBER: 1-
16777215>
replace-ctag indicates whether the CVID is replaced.
<yes|no> The default value is no. If you set the value to yes without
specifying a valid c-tag value, the configuration will be
rejected.
Note: When the device is in non-native mode, this attribute
is hidden.
ctag <1-4095> is the value that the CVID is replaced with.
Note: When the device is in non-native mode, this attribute
is hidden.
mgmt-vc sets the virtual circuit to be a management virtual circuit.
<no | yes>
tunnel <PBT is the encapsulation PBB-TE tunnel name.
Primary Tunnel
Name>
retain-stag indicates whether to retain Q-in-Q tag over PBB-TE
<no | yes> encapsulation/decapsulation.
If the virtual switch is to be used for in-band management in
native PBB-TE mode, set this attribute to no.
s-tag <NUMBER: is the Q-in-Q tag value.
1-4095> If the retain-stag attribute is set to yes, native PBB-TE mode
requires that an s-tag value be specified explicitly.

To configure the virtual switch

14 Reserve VLANs for the virtual switch:
virtual-switch add reserved-vlan <VLAN ID List>
where
reserved-vlan is the VLAN list.
<VLAN ID List>
Note: The system can automatically assign the reserved VLAN from this
pool when the virtual switch is created or you can optionally specify a
reserved VLAN when you create the virtual switch by setting the
reserved-vlan attribute.
15 Create the virtual switch naming it and associating it with the PBB-TE virtual
circuit:
virtual-switch ethernet create vs <vs> reserved-vlan
<NUMBER: 1-4094> vc <Virtual Circuit Name>
where
vs <vs> is the virtual switch name.
reserved-vlan is the reserved VLAN.
<NUMBER:
1-4094>
vc <Virtual is the Ethernet virtual circuit.
Circuit Name>
16 Add the subscriber port and VLAN to the virtual switch:

| 9100 | 88A8>}

To configure in-band management (non-native PBB-TE)

17 Create a management virtual circuit:
virtual-circuit pbt create static-vc <static-vc> {egress-
isid <NUMBER: 1-16777215>} {ingress-isid <NUMBER: 1-
16777215>} mgmt-vc <no | yes> tunnel <PBT Primary Tunnel
Name> retain-stag <no | yes> {s-tag <NUMBER: 1-4095>}
where
static-vc is the PBB-TE virtual circuit name.
<static-vc>
egress-isid is the egress I-SID.
<NUMBER: 1- Note: Egress I-SID and ingress I-SID values must be the
16777215>
same when using native PBB-TE, that is, 3916, 3930, 3931,
and 5150 platforms.
ingress-isid is the ingress I-SID.
<NUMBER: 1-
16777215>
mgmt-vc sets the virtual circuit to be a management virtual circuit.
<no | yes>
tunnel <PBT is the encapsulation PBB-TE tunnel name.
Primary Tunnel
Name>
retain-stag indicates whether to retain Q-in-Q tag over PBB-TE
<no | yes> encapsulation/decapsulation.
s-tag <NUMBER: is the Q-in-Q tag value.
1-4095>
Note: Note: IPv6 in-band management is supported over native PBB-TE.

To configure in-band management (native PBB-TE platform)
18 Set the tag-vid for the VS created in step 15 to enable it to handle
management traffic:
virtual-switch cpu-if set vs <vs> tag-vid <NUMBER: 1-
4094>
where
tag-vid is the inner tag for PBB-TE management frames.
<NUMBER: 1- The default customer management VLAN is 127.
4094>
Note: IPv6 in-band management is not supported over non-native PBB-TE.

19 Set interface attributes:

interface remote set vs <vs>
where
vs <vs> is the management virtual switch.
To configure CFM on a PBB-TE virtual switch

20 Enable CFM globally.
cfm enable
21 Create the CFM service for the PBB-TE virtual switch.
cfm service create static-pbt <static-pbt> name
<String[45]>
where
static-pbt is the PBT tunnel service.
<static-pbt>
name is the CFM service name.
<String[45]>
22 Enable the CFM PBB-TE service.

where
service <service> is the service name.
To configure CFM on a PBB-TE tunnel

23 Enable CFM globally.
cfm enable
24 Create the CFM service for the PBB-TE tunnel.
cfm service create static-pbt <static-pbt> name
<String[45]> {next-mepid <NUMBER>]
where
static-pbt is the PBT tunnel service.
<static-pbt>
name is the CFM service name.
<String[45]>
next-mepid initialize next-mepid
<NUMBER>

25 If desired, the CCM interval can be configured, but the interval must be the
same on both sides of the tunnel endpoints. The default is 1 second.
Note: Setting the CCM Interval to 4 milliseconds is not recommended for a
production environment, although it can be used for testing.
cfm service set service <service> ccm-interval <0 | 1 | 2
| 3 | 4 | 5 | 6 | 7 | off | 3.33ms | 10ms | 100ms | 1sec
| 10sec | 1min | 10min>
where
ccm-interval <0 | is the CCM transmission interval index or time.
1|2|3|4|5|6|
7 | off | 3.33ms |
10ms | 100ms |
1sec | 10sec |
1min | 10min>
26 Enable the CFM PBB-TE service.

where
27 Verify that the MEP IDs at both ends of the tunnel are different:
cfm mep show
cfm remote-mep show
28 If the MEPS IDs are the same, change one of the MEP IDs:
cfm mep set service <service> port <Port> mepid <NUMBER:
1-8191>
where
port <Port> is the port.
mepid is the MEP ID.
<NUMBER:
1-8191>
To configure QoS on a PBB-TE tunnel

29 Set the port into advanced mode:
traffic-profiling set port <port> mode advanced
where

30 Set up ingress metering:

traffic-profiling standard-profile create port <port>
profile <NUMBER: 1-4096> cir <NUMBER> pir <NUMBER>
where
port <port> is the port number.
profile is the traffic profile number.
<NUMBER:
1-4096>
cir <NUMBER> is the committed information rate in Kbps of this traffic meter,
rounded to fit hardware.
pir <NUMBER> is the peak information rate in Kbps of this traffic meter,
rounded to fit hardware
traffic-profiling set port <port> mode <none | advanced |

standard-dot1dpri | standard-ip-prec | standard-dscp |
standard-vlan | standard-vlan-dot1dpri | standard-vlan-
ip-prec | standard-vlan-dscp | hierarchical-port |
hierarchical-vlan>
where
mode <none | is the remarking mode.
advanced |
standard-
dot1dpri |
standard-ip-prec |
standard-dscp |
standard-vlan |
standard-vlan-
dot1dpri |
standard-vlan-ip-
prec | standard-
vlan-dscp |
hierarchical-port |
hierarchical-
vlan>

31 Set CoS marking:

tunnel encap set static-pbt <static-pbt> encap-cos-policy
<fixed> encap-fixed-pcp <NUMBER: 0-7>
where
static-pbt is the backup tunnel name.
<static-pbt>
<fixed>
encap-fixed-pcp is the encapsulation fixed PCP policy.
<NUMBER: 0-7>

inherit>} {vc <Virtual Circuit Name>} [ip-interface
<interface-name>]
where
vs <vs> is the virtual switch name
<dot1dpri-inherit |
fixed | ip-prec-
inherit | phbg-
inherit>
encap-fixed- is the encapsulation fixed dot1dpri.
dot1dpri
<NUMBER: 0-7>
end
Example
The following configuration example displays the steps to configure a primary
and a backup PBB-TE tunnel over the devices shown in Figure 11-7. It also
employs CFM to monitor the connection. It assumes that PBB-TE mode is
enabled and that a valid PBB-TE license key is installed.
Figure 11-7
PBB-TE Configuration Example
The following example configures device 1 SJC.
SJC> rstp disable -OR- SJC> mstp disable

SJC> pbt set bridge-mac 00:02:a1:30:7c:80
SJC> pbt reserve bvid 2000,3000
SJC> pbt remote-bridge create bridge-name SFO bridge-mac 00:02:a1:30:7c:c0
SJC> tunnel encap create static-pbt to_SFO b-vid 2000 dest-bridge-name SFO
port 23 tunnel-sync on

SJC> tunnel decap create static-pbt frm_SFO b-vid 2000 src-bridge-name SFO
port 23
SJC> tunnel pair create tnl-pair SJC encap-pbt to_SFO decap-pbt frm_SFO
SJC> tunnel encap create static-backup-pbt to_SFO b-vid 3000 dest-bridge-name
SFO port 24
SJC> tunnel decap create static-pbt bkp_SFO b-vid 3000 src-bridge-name SFO
port 24
SJC> tunnel pair create tnl-pair SJC-Backup encap-backup-pbt to_SFO decap-pbt
bkp_sfo
SJC> virtual-circuit pbt create static-vc pbt dest-bridge-name SFO egress-isid
1 ingress-isid 2 tunnel to_SFO
SJC> virtual-switch add reserved-vlan 1000
SJC> virtual-switch ethernet create vs pbt vc pbt
SJC> virtual-switch ethernet add vs pbt port 1 vlan 10
SJC> cfm service create static-pbt to_SFO name PBT level 7 next-mepid 100
SJC> cfm service set service PBT alarm-time 0
SJC> cfm service enable service PBT
SJC> cfm service create static-backup-pbt to_SFO name PBT_BKP level 7 next-
mepid 101
SJC> cfm service enable service PBT_BKP
The following example configures device 2 SFO.
SFO> rstp disable -OR- SFO> mstp disable

SFO> pbt set bridge-mac 00:02:a1:30:7c:c0
SFO> pbt reserve bvid 2000,3000
SFO> pbt remote-bridge create bridge-name SJC bridge-mac 00:02:a1:30:7c:80
SFO> tunnel encap create static-pbt to_SJC b-vid 2000 dest-bridge-name SJC
port 23 tunnel-sync on
SFO> tunnel decap create static-pbt to_SJC b-vid 2000 src-bridge-name SJC port
23
SFO> tunnel pair create tnl-pair SFO encap-pbt to_SJC decap-pbt to_SJC
SFO> tunnel encap create static-backup-pbt to_SJC b-vid 3000 dest-bridge-name
SJC port 24
SFO> tunnel decap create static-pbt to_SJC b-vid 3000 src-bridge-name SJC port
24
SFO> tunnel pair create tnl-pair SFO-Backup encap-backup-pbt to_SJC decap-pbt
to_SJC
SFO> virtual-circuit pbt create static-vc pbt dest-bridge-name SJC egress-isid
2 ingress 1 tunnel to_SJC
SFO> virtual-switch add reserved-vlan 1000
SFO> virtual-switch ethernet create vs pbt vc pbt
SFO> virtual-switch ethernet add vs pbt port 1 vlan 10
SFO> cfm service create static-pbt to_SJC name PBT level 7 next-mepid 200
SFO> cfm service set service PBT alarm-time 0
SFO> cfm service enable service PBT
SFO> cfm service create static-backup-pbt to_SJC name PBT_BKP level 7 next-
mepid 201
SFO> cfm service enable service PBT_BKP
The following example configures device 3 MTV.
MTV> rstp disable -OR- MTV> mstp disable

MTV> vlan create vlan 2000,3000
MTV> vlan add vlan 2000,3000 port 21,23
MTV> cfm mip create vlan 2000 port 21 level 6


The following example configures device 4 Suny:
Suny> rstp disable -OR- Suny> mstp disable

Suny> vlan create vlan 2000,3000
Suny> vlan add vlan 2000,3000 port 22,26
Suny> cfm mip create vlan 2000 port 22 level 6

Procedure 11-6
Releasing reserved BVIDs
Release reserved BVIDs If you removed the PBB-TE configuration and want
to reuse the BVID for a VLAN ID.
Step Action
1 Release reserved BVIDs:

pbt release bvid <VLAN ID List>
where
bvid <VLAN ID is the VLAN or VLANs to be released.
List>
end

Procedure 11-7
Displaying PBB-TE information
Display PBB-TE information to view the PBB-TE global configuration.
Step Action
1 Display PBB-TE global configuration information:

pbt show
end
Example
The following example shows sample configuration for the pbt show
command.
+--------------------- PBT Attributes -----------------------+

| PBT Bridge MAC | 00:03:18:cf:ea:80 |
| PBT Service E-type | 0x88c8 |
| PBT Tunnel E-type | 0x88a8 |
| PBT S-tag Tpid | 0x8100 |
| PBT Transit Tunnel E-type Remark | On |
| PBT Tunnel Reversion | Off |
| PBT Reversion Hold Time | 3000 milli secs |
| PBT Admin Mode | Non-native |
| PBT Oper Mode | Non-native |
+----------------------------------+-------------------------+
+--------------- PBT Reserved B-VIDs ------------------+

| B-VID | In Use |
+----------------------------+-------------------------+
| No entries found |
+----------------------------+-------------------------+
+--------------- PBT Remote Bridges -------------------+

| Bridge Name | Index | Bridge MAC | In use |
+-----------------+-------+-------------------+--------+
| No entries found |
+-----------------+-------+-------------------+--------+

12-1
Multiprotocol Label Switching (MPLS)

configuration 12-
Multiprotocol Label Switching (MPLS) supports circuit (voice), cell-switched

(business) and packet switching in a single packet switched network to save
capital and operational expenditures. MPLS speeds up traditional IP
forwarding with a simplified header and lookup process. MPLS can be used to
build seamless and consistent Layer 2 (L2) Virtual Private Networks (VPNs)
between two or more remote sites traversing many different physical networks
with enhanced performance and topology discovery to ensure the most
efficient routes.
Note: SAOS 6.11 does not provide an automatic configuration convert

mechanism for MPLS. Any MPLS configuration from releases prior to
SAOS 6.11 will be lost upon upgrade to SAOS 6.11 and will need to be re-
configured.
This chapter contains the following sections:

Overview on page 12-3
MPLS label operations on page 12-4
MPLS label format on page 12-5
MPLS-Traffic Engineering on page 12-6
MPLS-Transport Profile on page 12-6
Interfaces on page 12-6
Tunnels on page 12-7
MPLS L2 VPN services on page 12-13
Virtual circuits on page 12-19
Routing protocols on page 12-23
Signaling protocols on page 12-25
Fault Management on page 12-28
Complementary protocols on page 12-29

12-2 Multiprotocol Label Switching (MPLS) configuration
Benefits on page 12-29

Vendor interoperability on page 12-29
Platform requirements and capabilities on page 12-30

Remote Management for MPLS on page 12-33

Task flow on page 12-34
Overview
A base MPLS network (or cloud) is defined by a region of two MPLS-enabled
switches or routers called Label Edge Routers (LERs), one for ingress and
one for egress. A set of Label Switch Routers (LSRs) reside within the cloud
between the LERs. The connection from the ingress LER to the intermediate
LSR(s) to the egress LERs is called the Label Switched Path (LSP). Figure
12-1 shows a sample MPLS network.
Figure 12-1
MPLS network
LSR
LSR
LER LSR
LSR
LER
LSP
Ethernet Network Ethernet Network
MPLS Cloud

Table 12-1 summarizes general MPLS terms.
Table 12-1
General MPLS terms
Term Definition
LSP Labeled Switched Path. The specific path through a network that a
datagram follows based on its MPLS labels.
LSR Label Switch Router. A device that switches the labels used to route
packets. When an LSR receives a packet, it uses the label included
in the packet header as an index to determine the next hop on the
Label Switched Path (LSP) and a corresponding label for the packet
from a look-up table. The old label is then removed from the header
and replaced with the new label before the packet is routed forward.
LER Label Edge Router. This device is on the edge of the MPLS cloud
and is responsible for initiating or terminating the LSPs. LERs can
be referred to as edge LSRs.
MPLS label operations

An IP packet enters an MPLS network through the ingress LER. The ingress
LER performs a routing lookup to determine the MPLS label, which
corresponds to a destination as stored in the forwarding information base
(FIB). This label also identifies the Forwarding Equivalence Class (FEC) so
that the packet is included in a set of packets with the same forwarding
destination and Class of Service (CoS).
MPLS label operations are push, swap, and pop.
The ingress LER inserts (pushes) this MPLS label (or stack of labels) between
the L2 and Layer 3 (L3) headers of the IP packet and changes the EtherType
value to indicate that the packet is labeled. Figure 12-2 shows the insertion of
the MPLS label.
Figure 12-2
MPLS label
L2 Frame Header L3 IP Header Payload
MPLS Label

The LER initiates the LSP and forwards the packet over the LSP to the
adjacent LSR. Each LSR swaps the label to the next hop label (or stack of
labels) of the next LSR (or egress LER) and forwards the packet.
When the IP packet reaches the egress LER, the egress LER performs a
routing lookup to determine the egress destination, removes (pops) the MPLS
label(s) and delivers the IP packet.
Implicit NULL label

In the case of Penultimate Hop Pop (PHOP), the penultimate hop LSR pops
the top label before forwarding the packet to the egress LSR. The egress LSR
signals that the label should be popped at the penultimate hop when it
provides an implicit NULL (0x03) label to the preceding hop, for a given tunnel
that is terminated by the egress LSR.
Explicit NULL label

The explicit NULL label has label value zero. The implicit forwarding
assumptions are the same as for the implicit NULL label in that the egress
LSR submits label value zero to its predecessor. The egress LSR signals that
at the penultimate hop the label should be swapped with value zero but
maintain the 'traffic class (tc) bits' intact so that proper queuing can be applied
to the received packet. The label stack depth is maintained but the top label
value of zero is only used for QoS purposes.
Router alert label

The router alert label has label value 1. The router alert label is pushed above
the pseudowire label and below the tunnel label in the MPLS label stack.
When the egress PE router receives the pseudowire packet, the router alert
label is exposed and the packet is delivered to the control plane.
MPLS label format

An MPLS label is a 32-bit field with the bit values as listed in Table 12-2.
Table 12-2
MPLS label format
Bit name Label (20 bits) TC (3 bits) S (1 bit) TTL (3 bits)
Bit number 0-19 20-22 23 24-31
Description 20-bit label with 3-bit IP 1-bit value indicates 8-bit TTL of IP
bits precedence CoS whether the label is header prevents
Note: The values the last label (single infinite loop of the
label or bottom of a packet
between 0 and 15
label stack)
are reserved.

Multiple labels (stack) are used for the following applications:

MPLS VPN uses 2 labels. One for the egress router (top label) and VPN
(second label).
MPLS Traffic Engineering uses 2 or more labels. The top is the endpoint
of the TE tunnel and the remaining show the destination.
In some cases, a combination of 3 or more labels are used for both. Multiple
labels are inserted as shown in Figure 12-3.
Figure 12-3
MPLS stacked label
L2 Frame Header Top Middle Bottom L3 IP Header Payload
MPLS-Traffic Engineering
MPLS-Traffic Engineering (MPLS-TE) features provide:
better usage of network links and resources
bandwidth and QoS guarantees
resiliency with fast reroute and recovery
In MPLS-TE implementations, LSPs are point-to-point and unidirectional.

Each LSP requires a separate LSP in the opposite direction for bidirectional
path connectivity.
MPLS-Transport Profile
MPLS-Transport Profile (MPLS-TP) builds upon MPLS-TE functionality for
implementation in a transport network. It provides the same MPLS-TE
features along with:
connection verification
fault monitoring
in-band control and management
In MPLS-TP implementations, LSPs are typically bidirectional whereby

forward and reverse LSPs are treated as a single entity at the terminating
LERs.
Interfaces
MPLS implementation requires an L3 IP interface for handling MPLS control
protocol traffic. This IP interface is associated with an L2 flood domain. On
39XX/51XX platforms this L2 flood domain is a VLAN.

The L2 flood domain is associated with the underlying one or more L2

interfaces. On 39XX/51XX platforms, this logical port interface maps directly
to a physical port or to a link aggregation group.
Tunnels
Tunnels can be created dynamically or statically. For co-routed tunnels, the
forward and reverse paths are on the same LSP. For associated bi-directional
tunnels, the forward and reverse paths are on different LSPs.
Table 12-3 lists the supported tunnels for TE and TP.
Table 12-3
Supported tunnels for TE and TP
TE TP
Dynamic Unidirectional Unidirectional

Associated bi-directional Associated bi-directional
Static Unidirectional Unidirectional

Associated bi-directional Associated bi-directional
Co-routed
In an associated bidirectional tunnel, each end node is configured with an LSP

to the other end. In addition, both end nodes are configured with the
association of the forward and reserve LSP. The association configuration of
two counter-directed LSPs at each end node makes the LSP an associated
bidirectional tunnel. In a co-routed bidirectional tunnel, the initiating end node
is configured with co-routed bidirectional LSP. The terminating end node
creates a reverse LSP dynamically upon receiving the signal.
In the case of static co-routed bidirectional tunnels, both end nodes are
configured with LSPs in each direction.
Note 1: The term 'ingress' is used interchangeably with the term initiator
for bidirectional tunnels to identify the initiator node. ingress' is preserved
as keyword in the SAOS CLI for backward compatibility.
Note 2: Penultimate Hop Popping (PHP) is prohibited for MPLS-TP
tunnels.

Dynamic and static tunnels share common attributes as listed in Table 12-4.
Table 12-4
Common tunnel attributes
Logical ID Creation index.
Time To Live (TTL) Policy When set to fixed, the value of the TTL in the tunnel label is set
according to the fixed TTL (fixed-ttl) value. The default (and only
supported) policy is fixed.
Fixed TTL Applicable when the TTL policy is set to fixed. The default is 255.
Destination IP address Sets the destination IP address for the tunnel.
Backup tunnel Ingress tunnel to protect the primary tunnel.
Tunnel reversion Indicates whether or not to switch from the backup to the primary
tunnel after the fault on the primary is cleared.
Reversion hold time Sets the amount of time in seconds to wait before switching from
the backup to the primary tunnel after the fault on the primary is
cleared (tunnel reversion). Default is 300 seconds. Applicable
when tunnel reversion is turned on.
Setup priority Setup priority is compared with the hold priority of existing LSP to
determine if preemption of those links should be allowed. The
setup of new tunnels requires this contention system when
resources for new services have been exceeded. The default
setup priority is 7, which is the lowest priority.
Hold priority Setup priority is compared with the hold priority of existing LSP to
determine if preemption of those links should be allowed. The
setup of new tunnels requires this contention system when
resources for new services have been exceeded. Default hold
priority is 0.
Bandwidth profile Associates the tunnel with a bandwidth profile that defines
bandwidth and burst size signaling information to be carried in
RSVP-TE path messages for interoperability with other vendor
core routers. You can create up to 64 bandwidth profiles with the
following attributes:
Bandwidth. Required attribute specifying the rate in kilobits per
second (kbps).
Burst. Optional attribute specifying the burst size in kilobytes.
Default is 128 kilobytes.
CoS profile Tunnel COS profile name.

BFD monitor BFD based fault monitoring
BFD profile BFD profile to be used for this session.
Count Number of tunnels.
Dynamic tunnels have additional attributes as listed in Table 12-5.

Table 12-5
Dynamic additional tunnel attributes
Record route For fastest reroute protection, the record route needs to be on. The
default is on. Fast ReRoute protection type attribute: protection-
type <link | node>
Path Explicit RSVP-TE path.
CSPF route Dynamic CSPF computed route.
Protection type Protection type.
FRR profile Tunnel FRR profile name.
Explicit tunnel path Tunnel explicit path name.
Static tunnels have additional attributes as listed in Table 12-6.

Table 12-6
Static tunnel additional attributes
Next hop IP address IP address of the next hop device.
Data interface Tunnel data plane IP Interface.
Label Tunnel label selected from the configured static label range.
Source IP address tunnel source IP address
Previous hop IP address Tunnel previous hop IP address used for AIS monitoring
In label Tunnel in label. The configured static label range determines the
valid range for static in labels.
Out label Tunnel out label.
Forward out label Forward encap tp-tunnel outgoing label.
Reverse in label Reverse decap tp-tunnel incoming label.
Forward tunnel Forward tunnel.

Reverse static tunnel Static reverse tunnel.
Reverse dyntun name Dynamic reverse tunnel name.
Reverse dyntun source IP address Dynamic reverse tunnel source IP address.
AIS monitor AIS based fault monitoring
AIS profile AIS profile to be used for this session
This chapter provides the following procedures for configuring dynamic and
static tunnels:
Configuring dynamic ingress TE tunnels on page 12-60
Configuring dynamic ingress uni-directional TP tunnels on page 12-61
Configuring static TE tunnels on page 12-67
Configuring co-routed TP tunnels on page 12-69
Configuring static bi-directional ingress-associated TE tunnels on page
12-73
Switching over to the backup GMPLS TP tunnel on page 12-78
Displaying MPLS TE-tunnel information on page 12-81
Next-hop diversity
It is recommended that a backup tunnel takes a diverse path from the primary
tunnel it is protecting so that failure on the intersecting node or link does not
cause the primary and backup tunnel to fail simultaneously. When the network
topology prevents this, there is no backup tunnel or a backup tunnel that may
share portions of a network topology. The second option provides protection
if the network nodes/links that fail are not shared between the primary and
backup.
When configuring the ingress unidirectional and ingress and egress co-routed
bidirectional static tunnels, users can select next (ingress) or previous
(egress) hop be not accessible through the same link as the primary LSP. This
is expressed by recovery-(p/n)hop-disjoint <none | link> when configuring
primary LSP. The default is link which forces you to provide a link diverse path.
Option none lets you fate share the link between primary and backup.
Note: Next-hop diversity is only available for static primary/backup

tunnels. When configuring primary and backup dynamic tunnels, you must
provide diverse explicit paths.

Tunnel FEC for static LSP

When configuring static LSP, you are encouraged to enter the following
additional parameters, as stated in RFC 6426:
Destination tunnel ID
Source Tunnel ID
LSP ID
These parameters are optional, however if you enter one, you have to enter all
parameters. These parameters are necessary to verify the connection for
LSP-BFD and LSP ping/traceroute interoperability. Identical information must
be configured at the other end. The dynamic tunnels exchange this
information in signaling which is why it is only needed for static tunnel
configuration.

Tunnel profiles
Tunnel profiles can be:
CoS profiles
Fast ReRoute profiles
CoS profiles
Table 12-7 lists attributes for CoS profiles.
Table 12-7
CoS profile attributes
CoS profile Tunnel COS profile name.
Frame COS map Selects frame-cos-map.
Frame COS policy Frame cos policy.
Fixed TC Encapsulation fixed Traffic Class (TC) value.
Resolved COS map Selects resolved-cos-map.
Resolved COS policy Resolved cos policy.
Resolved COS fixed Fixed resolved CoS value.
This chapter provides the following procedure for configuring CoS profiles:
Configuring CoS profiles for MPLS tunnels on page 12-74
Fast ReRoute profiles

Fast ReRoute (FRR) provides a quick failover to bypass the LSP at an
intermediate LSR when a local fault is detected. The head-end router signals
implementation of FRR at Point-of-Local-Repair (PLR) LSRs.
Table 12-7 lists attributes for FRR profiles.
Table 12-8
FRR profile attributes
FRR profile Tunnel FRR profile name.
Logical ID Profile index.
Setup priority FRR tunnel setup priority.
Hold priority FRR tunnel hold priority.
Hop limit FRR tunnel hop-limit.

Table 12-8
FRR profile attributes
Bandwidth Bandwidth (Kbps/s).
Bandwidth protection Bandwidth protection of FRR tunnel.
Node protection Node protection of FRR tunnel.
Protection method Bandwidth protection of FRR tunnel.
Colour group include any Tunnel colour-group-include-any.
Colour group include all Tunnel colour-group-include-any.
Colour group exclude any Tunnel colour-group-include-any.
This chapter provides the following procedure for configuring CoS profiles:
Configuring a dynamic ingress TE tunnel with FRR on page 12-76
MPLS L2 VPN services

MPLS LSPs provide the network infrastructure for service delivery
applications such as MPLS L2 VPNs.
Ciena's implementation of MPLS is based on RFC 4447 for L2VPN label

exchange. Ciena uses LDP for label exchange rather than Border Gateway
Protocol (BGP). Additional information on label exchange can be found in
Signaling protocols on page 12-25.
This implementation supports the simultaneous deployment of MPLS-based

L2 VPN services, including:
Virtual Private Wire Services (VPWS).
Virtual Private Local Area Network Services (VPLS).
Hierarchical VPLS (H-VPLS).

Table 12-9 provides definitions of terms used to describe MPLS L2 VPNs.
Table 12-9
MPLS L2 VPN terms
Term Definition
Provider Edge (PE) Router Router responsible for encapsulating client data to be
carried across the MPLS tunnels. This router is an LER
that delivers point-to-point or multipoint L2 connectivity
service to the service provider's clients.
Provider Router LSR that operates on the MPLS tunnel label.
Attachment Circuit (AC) Represents the client L2 circuit on the UNI port of the
PE.
Pseudowire (PW) Virtual circuit that encapsulates the client payload and
adds the PW header.
Multi-tenant Unit Switch A device that support L2 switching functionality and

(MTU-s) does all the normal bridging functions of learning and
replication on all of its ports, including the spoke virtual
circuit port. Only a single PW is required per VPLS
instance, reducing the signaling overhead between the
MTU-s and the PE.

VPWS
VPWS provides point-to-point connectivity between two remote Local Area
Networks (LANs). With this type of connectivity, MPLS provides the equivalent
of an E-LINE service (EPL or EVPL). Traffic is carried from a single
attachment circuit to exactly one PW, and MAC addresses are not learned for
the Ethernet attachment circuit. Figure 12-4 provides an example of a VPWS
with a one-to-one connection between CE1 and PE1.
Figure 12-4
VPWS connectivity
Client
One AC One PW Protected Network
Tunnel
CE-2
PE-1 PE-2
PW PW
Client CE-1
Network

VPLS
VPLS provides point-to-multipoint inter-LAN connectivity. With VPLS, PEs are
connected to each other with a full mesh of virtual circuits for each VPLS
instance as shown in Figure 12-5.
Figure 12-5
VPLS full mesh
Each PE provides one or more connections to the customer edge (CE)

devices by means of an attachment circuit to the PE MAC/VLAN bridge
function. PEs are connected to each other using virtual circuits. The bridge
function of the PE attaches to an emulated LAN, which is defined by a virtual
switch. The emulated LAN comprised of VPLS Forwarders which connect to
virtual circuits. This set of VPLS Forwarders connected by virtual circuits
represents a VPLS instance.
The bridge function learns MAC addresses, associates them with virtual
circuits, and ages them out in a standard manner. When a broadcast/
multicast/unknown frame arrives at the bridge function, the frame is forwarded
over all the virtual circuits attached to the VPLS forwarder. When a frame
arrives on a virtual circuit, the bridge function performs normal Source
Address (SA) MAC learning to associate the MAC address with the virtual
circuit. In this way, the PE emulates the behavior of a normal LAN. The CE
devices appear to be connected to a LAN even though the underlying
infrastructure is an MPLS network.

H-VPLS
The deployment of large-scale VPLS networks where each PE is connected
to all other PEs using a full mesh of virtual circuits does not allow complete
scalability. As a result, a Hierarchical VPLS (H-VPLS) model is used to allow
spoke connections to the VPLS core. As shown in Figure 12-6, a device
provides the functionality to interface with the VPLS core by functioning as an
MTU-s, which is connected as a spoke in the VPLS core using a virtual circuit.
Figure 12-6
H-VPLS with MTU-s spoke
In this H-VPLS model, there is only one logical connection, that is, virtual
circuit, from an MTU-s to the PE for a given VPLS instance. Each VPLS
instance supported by an MTU-s has a virtual switch defined as a virtual L2
switch.
The MTU-s must map incoming frames on its bridge module into VPLS
instances. This can be based on one of three methods:
physical ports
LAN tag of the ingress frame
virtual circuit MPLS label of the ingress frame

VPLS membership and MAC learning

The virtual switch provides a mapping between customer-facing ACs and
network-facing virtual circuits. A virtual switch can be dual-homed such that
there are multiple virtual circuits connecting the VPLS instance to the VPLS
hub. MAC addresses to be included in forwarding for the VPLS instance are
learned in one of two ways:
unqualified learning
qualified learning
MAC addresses that have been dynamically or statically learned are also
removed or unlearned explicitly through the MAC withdraw mechanisms.
Unqualified Learning
In unqualified learning, all traffic from a specific bridge port is assigned to a
single VPLS instance, that is, per-port attachment circuit, and shares a single
broadcast domain. MAC addresses need to be unique and non-overlapping
among customer VLANs or else they cannot be differentiated within the VPLS
instance.
An example of this is port-based VPLS service for a given customer. In this

case, all traffic that comes in on a physical port, which can include multiple
customer VLANs, is mapped to a single VPLS instance.
Qualified Learning
In qualified learning, each customer VLAN is assigned to its own VPLS
instance, which means that each customer VLAN has its own broadcast
domain and MAC address space. Unlike unqualified learning, MAC addresses
among customer VLANs can overlap with each other. They are handled
correctly since each customer VLAN has its own Forwarding Information Base
(FIB). When a VPLS instance is defined per-port per-VLAN, the customer
VLAN must be the same on each bridge port that is joining the virtual switch.
An example of qualified learning is per-port per-VLAN VPLS service.
MAC Withdraw
MAC withdraw is a signal typically sent from a node that wants remote peers
to flush all learned MAC addresses in a given VPLS instance. The receiving
node unlearns either MAC addresses present in the signal or all MAC
addresses if they are absent in the signal. SAOS only supports wildcard MAC
withdraw (no MAC address in the signal).
The send and receive processing of the MAC address withdraw signal
capability is, by default, turned on. It cannot be turned off. The MAC withdraw
signal is sent only when the standby pseudowire becomes operational. It is not
used for any other pseudowires that are not part of protection group.

Virtual circuits
A virtual circuit is a bidirectional connection between endpoints which can
multiplex/de-multiplex traffic over tunnels. Multiple virtual circuits between two
endpoints can use the same tunnels. For virtual circuits associated with an
MTU-s, a secondary virtual circuit can be configured to support dual-homed
protection.
Comparing raw and tagged PW type for virtual circuits

The term attachment circuit is used to describe the customer-facing port of an
Ethernet L2VPN service. The two types of ACs available are:
EPL attachment circuit, which is a port added to an L2VPN service
EVPL attachment circuit, which is a single VLAN added to an L2VPN
service
An EPL attachment circuit indicates that the outer VLAN tag of the frame, if
present, is not service delimiting and therefore is not meaningful to the PE. An
EPL attachment circuit always assumes the outer tag of the frame is a C-Tag.
An EVPL attachment circuit indicates that the outer VLAN tag of the frame is
service delimiting and should be used to identify the traffic. An EVPL
attachment circuit always assumes the outer tag of the frame is an S-Tag.
MPLS forwarding behavior depends on the type of attachment circuit/virtual

circuit combination configured. There are four possible combinations:
EPL attachment circuit with raw virtual circuit
EVPL attachment circuit with raw virtual circuit
EPL attachment circuit with tagged virtual circuit
EVPL attachment circuit with tagged virtual circuit
A raw PW type virtual circuit never carries a service delimiting tag. There are
only 2 possible options for this type: ignore the tag or pop it. In the case of an
EPL attachment circuit the tag is assumed to be a customer tag and it is
ignored. In the case of an EVPL attachment circuit the tag is assumed to be a
service provider tag and it is popped.
A tagged PW virtual circuit always carries a service delimiting tag. There are
two possible options for this type: stamp or push. In the case of an EPL
attachment circuit the outer tag is assumed to be a C-Tag and an additional
tag is pushed on the frame. In the case of an EVPL attachment circuit the
outer tag is assumed to be a service provider tag and it is stamped.

Figure 12-7 illustrates the process for determining the PW type.
Figure 12-7
Ingress Operation Decision Tree
Is the Outer VLAN

Service
Delimiting ?
S NO
YE
EVPL EPL
Should the service Should the service
carry a Service carry a Service
Delimiting VLAN ? Delimiting VLAN ?
S
S
NO
NO
YE
TAGGED
TAGGED YE RAW
Stamp outer VLAN RAW
Push VC No operation is
with VC configured Pop outer VLAN
configured VLAN performed.
VLAN
Note: If identical settings are configured on either end of the MPLS tunnel
the original frame is preserved through the service. The operation as the
customer frame egresses the service is contrary to the ingress operation.
However, the outer tag can also be permanently altered by changing the
attachment circuit/virtual switch combination on the egress side.
When configuring primary virtual circuits, follow these configuration rules:

All virtual circuit names must be unique.
A virtual circuit cannot be deleted unless it is detached from the virtual
switch.
Dynamic virtual circuits: For a given peer node, the Pseudowire ID of the
virtual circuits must be unique.
Static virtual circuits: Ingress label is unique across virtual circuits and
tunnels.

Primary dynamic and static MPLS virtual circuits support the attributes listed
in Table 12-10.
Table 12-10
Primary virtual circuit attributes
Name Unique 31 character name.
PW-ID PseudoWire identifier. Ranging from 1-4294967295. This identifier

must be the same at both ends of the PW.
Peer Peer IP address.
Ingress label Ingress label for the virtual circuit. Only applies to static virtual circuits.
Egress label Egress label for the virtual circuit. Only applies to static virtual circuits.
Tunnel Name of the tunnel.
PW type Pseudowire type. For static virtual circuits, the types are raw or
tagged. Default is raw. For dynamic virtual circuits, the types are eth-
raw, eth-tagged, or tdm.
PW mode Pseudowire mode:

Mesh. A virtual circuit between two PEs.
Spoke. A virtual circuit emanating towards the MTU-s.
MTU Maximum transmission unit 1500-9128. Default is 1500. This

parameter is exchanged during dynamic establishment of a PW and
must match in order for the PW to become operational between two
PEs.
Note: Mismatch of the MTU is one of the most common reasons for
PW to fail to become operational.
Status TLV On or off. Applies to virtual circuits and static virtual circuits. The static
virtual circuit carries status TLV in the OAM channel.
Service Delimiter VID Supports per VLAN TPID stamping for the specified VLAN ID (1-
4094). Used with the Service Delimiter TPID.
Service Delimiter TPID Selects the TPID value to stamp on egress frames for the VLAN ID
specified with the Service Delimiter VID:
8100 - 802.1Q Ethertype
9100 - Q-in-Q Ethertype
88a8 - Provider Bridge Ethertype

For dual-homed protection of an MTU-s primary dynamic virtual circuit, the

secondary virtual circuit is defined by setting the peer IP address, tunnel,
primary PW-ID, and secondary PW-ID. All other attributes are inherited from
the primary.
By default, the primary virtual circuit is the active virtual circuit. If the primary
fails, the secondary virtual circuit becomes the active virtual circuit. The active
virtual circuit (whether it is the primary or secondary) remains active unless it
fails or it can be manually switched over.
This chapter provides the following virtual circuit procedures:

Configuring dynamic virtual circuits on page 12-91
Displaying virtual circuits on page 12-98
Virtual circuit connectivity verification profile configuration
Virtual circuit connectivity verification (VCCV) provides a control channel that
is associated with a pseudowire, and corresponding operations and
management functions, such as connectivity verification, to be used over that
control channel. VCCV applies to all supported access circuit and transport
types currently defined for pseudowires.
A PW OAM channel is used by VCCV ping/traceroute and static pseudowire

(PW) status and MAC withdraw signaling. PW OAM uses four CC channel
types, listed according to preference:
0x04 - GAL/GACH channel
0x01 - Control word
0x02 - Router alert
0x03 - TTL exhaust
Only one channel can be used during the life of PW. For VCCV profile
configuration, the user provides the supported channels in the profile and
associates this profile for the PW. Error checks are performed during the
association with static PW. These include ensuring that none or more than
one channel type are selected, and conflicting channel types where PW status
signal is enabled but the channel type is other than 4.
Note: In Release 6.11, CC-type 0x03 for VCCV ping is used when PW is
mapped over unidirectional tunnel and CC-type 0x04 is used when PW is
mapped over a bidirectional tunnel. In order to interoperate with a node in
Release 6.11, do not configure an explicit VCCV profile for the PW. This
will enable the use of a default profile for the PW and select the right
channel based on the underlying tunnel type.

PW status and MAC withdraw over static PW is supported for CC-type 4 for
Release 6.12.
This chapter provides the following VCCV profile configuration procedure:

Configuring virtual circuit connectivity verification profiles on page
12-101
Routing protocols
MPLS network topology and routing information is monitored and maintained
by the following routing protocols:
Open Shortest Path First (OSPF)
Open Systems Interconnect (OSI) Intermediate System to Intermediate
System (IS-IS) Intra-domain Routing Protocol
These routing protocols discover neighbors in the MPLS network and

maintain the optimum route to them.
OSPF
OSPF is used to create an IP routing table for building dynamic MPLS tunnels.
One of several Interior Gateway Protocols (IGPs) designed to support routing
in an IP network within a single autonomous system (AS), OSPF is a link-state
protocol that uses configurable metrics to associate a cost with a link. These
metrics allow network administrators to manage their network based on the
speed, reliability, and delay of the network.
The OSPF protocol is a link-state routing protocol, which means that the
routers exchange topology information with their nearest neighbors. The
topology information, in the form of a link-state advertisement (LSA), is
flooded throughout the AS, so that every router within the system has a
complete representation of the topology. Devices build a Link State Database
(LSDB) based on this information. Each Area Border Router (ABR) has one
LSDB for each area to which it is connected. This information is then used to
calculate the shortest end-to-end paths through the system. This is
accomplished by means of Djikstra's Shortest Path First (SPF) algorithm. The
SPF tree, also known as the best path tree, is then submitted to the routing
table as OSPF routes. When a network topology change occurs, a
recalculation of the shortest path tree is performed. The network will converge
when all routers have recalculated their routing tables as a result of a change
in the topology.
OSPF neighbors are any two routers that have an interface to the same
network. When an OSPF device first joins a network, it uses the Hello Protocol
to discover its neighbors. Neighbors may form adjacencies for the purpose of
exchanging routing information. Not all neighbor pairs can become adjacent.
Adjacencies are formed by synchronizing the neighbors' topology databases

through the database exchange process. Two devices are said to be fully
adjacent when they have synchronized their databases. Routing information
is exchanged between the adjacent routers only, thereby conserving
bandwidth. Also, an authentication mechanism prevents unauthorized
neighbors from establishing adjacencies.
The multi-level hierarchy (two-level for OSPF) called area routing allows the
information about the topology within a defined area of the AS to be hidden
from routers outside this area, enabling an additional level of routing
protection and a reduction in routing protocol traffic. The authentication of all
protocol exchanges prevents unauthorized routers from joining the AS. The
system software supports two OSPF areas.
IS-IS
Similar to OSPF, IS-IS is a link-state routing protocol in the group of IGPs and
calculates the shortest end-to-end paths through the system with Djikstra's
Shortest Path First (SPF) algorithm. As defined in RFC1195, IS-IS supports
routing within IP only, OSI only, and dual (IP with OSI) domains and supports
two router levels, Level 1 and Level 2. With IS-IS, a routing domain can be
partitioned into multiple Level 1 router areas with a Level 2 interconnection
router. Level 1 routers within the same area exchange information, but for
destinations outside of the area, Level 1 routers forward to the nearest Level
2 or dual, that is, Level 1 and Level 2 router.
On a broadcast, multi-access network, an intermediate system is elected as

a designated router. An intermediate system supports one designated router
on a broadcast link for Level 1 and one for Level 2. The designated router on
a broadcast link represents a virtual node, called a Pseudo Node.
The Pseudo Node creates and updates link state packets to report link state
information to all systems on the broadcast sub-network. Also, it floods link
state packets on the network and periodically sends Complete Sequence
Numbers Packets (CSNPs) to synchronize link state databases at each
intermediate system on the network. All intermediate systems, including the
designated router, form adjacencies with the Pseudo Node using IS-IS Hello
Packets (IIH). To acknowledge receipt or to request link state information,
intermediate systems send Partial Sequence Number Packets (PSNP).
Intermediate systems are identified by a unique Network Entity Title (NET)

which maps to the NSEP router. NET comprises:
Area identifier, which is a variable dotted hexadecimal value from two
bytes to 13 bytes with the first byte value containing the Address Format
Identifier (AFI)
System identifier, which is a six-byte hexadecimal value derived from the
loopback IP address

The link state packet includes the NET and can optionally include a Dynamic
Hostname TLV that contains the symbolic name of the router, such as a Fully
Qualified Domain Name, which sends the link state packets.
The system software supports Level 1 routing capability for IPv4 protocol and
1 area with 3 area identifiers per node. IS-IS can be used to replace OSPF
functionality or it can be implemented simultaneously with OSPF.
Configuring a routing protocol is required in dynamic MPLS deployments and

optional for static MPLS deployments. Routing protocols are IS-IS and OSPF.
Note: You can configure both IS-IS and OSPF. However, to simplify
implementation, Ciena recommends using IS-IS or OSPF.
A loopback interface is required in order for higher level protocols, such as

RSVP-TE and LDP, to use the route information that OSPF or IS-IS provides.
This chapter provides the following routing protocol procedures:

Configuring OSPF routing protocol
Configuring IS-IS routing protocol
Signaling protocols
Dynamic MPLS networks are created and monitored with the signaling of
Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for tunnels,
and Label Distribution Protocol (LDP) for virtual circuits.
Tunnels and virtual circuits use label exchange following Martini
encapsulation without Control Word as defined in RFC4447. Martini
encapsulation consists of adding an Ethernet transport header to the
beginning of an incoming packet that includes the following:
Destination MAC address (DA) of the PE is contained in the Ethernet
transport header when directly connected to a device.
Source MAC address of the Multi-tenant Unit (MTU) or PE and the
provider VLAN.
MPLS Ethernet-type and both the tunnel and virtual circuit MPLS labels.
RSVP-TE
RSVP-TE is a protocol used to establish label switched paths (LSPs) in
dynamic MPLS networks. These LSPs allow the traffic trunks, which are a set
of flows aggregated by their service class on one or a set of LSPs, to be
carried through the network. One LSP can carry several traffic trunks. The
traffic that flows along an LSP is defined at the ingress node. When labels are
associated with traffic flows, routers can identify the appropriate reservation
state for a packet. These defined paths can be treated as tunnels, and are
described as LSP tunnels.

Tunnel creation
To create an LSP tunnel, the first MPLS device on the path creates an RSVP-
TE path message. A label binding for this path is requested and indicates
which network layer protocol is to be carried over the path. When the sending
device finds a path that either meets the tunnels QoS requirements, satisfies
the policies criteria, or can maximize the use of the network resources, an
explicit route is specified. This explicit route can be dynamically changed if the
device finds a better route. This event is recorded and the sender device is
notified.
The session created, or LSP, carries the load to the destination device along
the path. When the destination is reached, a received message is sent back
to the sending device, following the path in reverse order, which establishes
an accurate and effective LSP.
LSP tunnels support various policies to optimize network performance. For

example, policies can be established to reroute traffic when there is a node
failure, or when a path is overloaded with packets. RSVP-TE tunnels can be
established along a Traffic Engineered path identified using Constrained
Shortest Path First (CSPF), which is an algorithm used to resolve Quality of
Service routing queries. Alternately, tunnels can be established by following a
user-configured explicit path to the destination device. A Tunnel is defined as
a unidirectional (MPLS-TE) or bidirectional, that is, MPLS-TP, LSP path
between two devices.
Failover
MPLS tunnels can be protected by configuring backup tunnels at the head-
end LER. The backup tunnel provides protection end-to-end for the primary
tunnel by means of a set of LSR hops that are primary-path-negated. This
ensures that failure on primary path does not translate to simultaneous failure
on the backup path.
Authentication
RSVP-TE supports authentication at the IP interface level and at the IP
address level and optionally to use MD5 authentication.

In order for IP address level authentication to work, the parent IP interface

authentication must also be configured. Also, authentication configuration
between two devices affects the status of MPLS tunnels created by RSVP-TE
as shown in Table 12-11.
Table 12-11
Authentication Configuration and Tunnel Status
IP address level Interface level Message-digest value on both

configured on configured on
both both
Yes No Same
Yes No Different
Yes Yes Same at IP address level. Different at

interface level.
Yes Yes Different at IP address level. Same at

interface level.
Yes One only Same at IP address level. Default on interface

level.
No Yes Same.
No Yes Different.
No One only Different. Default on IP address and interface

levels on non configured device.
Paths
Configure RSVP-TE paths to implement RSVP-TE with Explicit Route Object
for tunnel redundancy or for the following use cases:
explicit strict route hops can be specified to navigate tunnels through
specific hops for cost and congestion avoidance purposes
explicit route hops could be sparse or network operator can configure
every single hop from source to destination. This would be close to
configuring static LSP but dynamic case and done only at the head end
explicit loose route hops can be specified when the network operator
prefers certain locations for tunnel to pass through but may not be sure if
TE attributes would be available
when tunnel needs to pass through multiple OSPF areas, Area Border
Routers should be specified as the explicit route hops
RSVP-TE configuration procedure is:
Configuring RSVP-TE

LDP
The principal role of LDP is to establish and maintain virtual circuits based
upon the agreement of the meaning of the label used to forward traffic.
Targeted LDP sessions are used.
Because LDP is a peer-to-peer protocol based on the establishment and
maintenance of TCP sessions, the following natural benefits exist:
LDP messages are reliably delivered by the underlying TCP, and state
information associated with explicitly-routed LSPs does not require
periodic refresh.
LDP messages are flow-controlled, that is throttled, through TCP.
The categories of LDP messages are:

Discovery messages announce and maintain the LSR presence in the
network.
Session messages create, maintain and terminate sessions between two
LDP peers that use LDP to exchange label mapping information.
Advertisement messages create, change and delete label mapping for
FEC, which is a set of packets with similar or identical characteristics.
Notification messages provide advisory information and signal error
information.
This chapter provides the following LDP procedure:
Configuring LDP
Fault Management
MPLS supports the following mechanisms for fault management:
Connectivity Fault Management over MPLS
Bidirectional Forwarding Detection (BFD)
Alarm Indication Signal (AIS) and Link Down Indication (LDI)
Note: For additional details, refer to 39XX/51XX 6.11 Service Delivery
and Aggregation Switches Fault and Performance Management (009-
3220-009.
Connectivity Fault Management over MPLS

MPLS virtual switches are monitored through the use of IEEE 802.1ag
Connectivity Fault Management (CFM) Continuity Check Messages (CCM).
Note: If a CFM service is configured on a virtual switch, the virtual switch

cannot be deleted unless the CFM service is deleted or changed to use a
different virtual switch.

Bidirectional Forwarding Detection (BFD)

MPLS-BFD implements a single-session BFD over an associated bidirectional
LSP, constructed from a pair of unidirectional LSPs, one in each direction. The
two LSPs operate virtually as one single entity for the purpose of protection
and switching.
Alarm Indication Signal (AIS) and Link Down Indication (LDI)

Alarm Indication Signal with Link Down Indication (AIS/LDI) are in-band
Operational, Administration and Maintenance (OAM) messages sent to
indicate service-interrupting faults on MPLS Label Switch Paths (LSPs).
Complementary protocols
Complementary protocols are:
LSP ping
LSP traceroute
LSP ping
LSP ping provides the ability to verify connectivity and detect faults of
RSVP-TE tunnels through the exchange of standard Echo Request and Echo
Reply messages.
LSP traceroute
LSP traceroute provides the ability to verify the path and isolate faults of
RSVP-TE tunnels through the exchange of standard Echo Request (with
increment TTL) and Echo Reply (with downstream mapping from transit
nodes).
This chapter provides the following complementary protocol procedures:

Running ping for RSVP-TE tunnels
Running ping for MPLS tunnels
Running a traceroute
Benefits
With MPLS and related protocols, service providers can provide customers
with the perspective of a direct connection to a private line or LAN between
their sites with enhanced performance, topology discovery to ensure the most
efficient routes, and interoperability with popular MPLS switching platforms.
Vendor interoperability
This MPLS implementation supports configurable label ranges for both static
and dynamic MPLS, and provides interoperability with other vendor devices.

Platform requirements and capabilities

Table 12-12 shows the platform requirements for MPLS.
Table 12-12
Requirements
Platform Requirements
3916 Requires 6.9.0 or later. Supported on all ports.
3932 Requires 6.11 or later. Supported on all ports.
Table 12-13, Table 12-14 and Table 12-15 show the platform capabilities.
Table 12-13
MPLS capabilities
Platform Ingress Tunnels Egress Tunnels Transit Bidirectional Tunnel Tunnel
Tunnels LSP Protection Protection
Protection Switching Switching
Groups for 1 for N
Tunnel Tunnels
3916 500, (400 500, (400 1000, (400 250

maximum maximum maximum
recommended recommended recommend
per port) per port) ed per port)
3930 500, (400 500, (400 1000, (400 250

3931 500, (400 500, (400 1000, (400 250

3932 500 500 1000

Platform Ingress Tunnels Egress Tunnels Transit Bidirectional Tunnel Tunnel

Tunnels LSP Protection Protection
Protection Switching Switching
Groups for 1 for N
Tunnel Tunnels
3960 500, (400 500, (400 1000, (400 250

5142 500 500 1000 250
5150 500, (400 500, (400 1000, (400 250 <=50 ms <=200 ms,
maximum maximum maximum N=50
5160 500 500 1000 250 <=50 ms <=200 ms,

N=50
Table 12-14
MPLS capabilities - continued
Platform PWs per VPLS VPWS Virtual LDP VPWS AC (EVPL)
VPLS Circuits Peers VS
(Pseudowires)
3916 1000 500 1000 1000 1000 1000 1000
3930 1000 500 1000 1000 1000 1000 1000
3931 1000 500 1000 1000 1000 1000 1000
3932 1000
3960 1000 500 1000 1000 1000 1000 1000
5142 4000 2000 1000 4000 1000 4000 4000
5150 2000 1000 2000 2000 1000 2000 2000
5160 4000 2000 4000 4000 1000 4000 4000

Table 12-15
MPLS capabilities - continued
Platform Dual home PW Dual home PW IGP (ISIS IGP IP
Protection (2 protection (10 Routes (OSPF) Interface
PWs) PWs) Routes s
3916 4000 4000
3930 4000
3931 4000 4000
3932
3960 4000 4000
5142 4000 4000
5150 <=1 sec <=5 sec 4000 128
5160 <=1 sec <=5 sec 4000 4000 128
Note: The 39XX/51XX system software does not block users from
configuring more tunnels than the maximum recommended per port. If
tunnels are configured beyond the recommended numbers, the system
might become unstable.
Table 12-16 shows the platform capabilities for related protocols.
Table 12-16
Related protocol capabilities
Platform IP Interfaces OSFP areas OSPF routes IS-IS areas IS-IS routes RSVP-TE Paths
3916 64 2 1000 3 400 256 with 16 hops

per path
3930 64 2 1000 3 400 256 with 16 hops

per path
3931 64 2 1000 3 400 256 with 16 hops

per path
3932 64 2 1000 3 400 256 with 16 hops

per path
3960 256 2 1000 3 400 256 with 16 hops

per path

Platform IP Interfaces OSFP areas OSPF routes IS-IS areas IS-IS routes RSVP-TE Paths
5142 256 2 1000 3 400 256 with 16 hops

per path
5150 256 2 1000 3 400 256 with 16 hops

per path
5160 256 2 1000 3 400 256 with 16 hops

per path
Remote Management for MPLS

You can access an IPv4 Remote Management Interface over an MPLS VPLS
mode virtual switch as an alternative to the management VLAN.
Before configuring management over MPLS, you must first allocate resources
to the transport-oam feature on 3916/30/31 platforms. For more information,
see Allocating resources for an MPLS management virtual switch (3916,
3930 and 3931 platforms) on page 12-104.
Figure 12-8 shows a sample topology with a remote management over an

MPLS VPLS virtual switch.
Figure 12-8
Remote Management Interface over an MPLS VPLS virtual switch
Remote Mgt I /F
IP: 192.168.1.2
L3-Int
VPLS Management Network
VS
VS 192.168.1.x
L3-Int
VPLS
VS
VS
MPLS MPLS MPLS-TE/TP Network MPLS MPLS

VC Tunnel Tunnel VC
Telnet, SNMP, ESM,

etc.
In order to carry remote interface traffic over an MPLS tunnel, the remote-
interface is associated with a virtual switch. One or more MPLS virtual circuits
can belong to the management virtual switch, which allows the management
traffic to travel over the MPLS tunnel(s).
This capability is supported on the following platforms:

3916
3930
3931
3932

5142
5150
5160
In order to carry remote interface traffic over an MPLS tunnel, the remote-
interface can be associated with a virtual switch. This implies that
management access to the switch can now be gained from any of the
members of this virtual switch, including attachment circuit members. Thus, if
customer attachment circuits exist on the virtual switch that is associated with
the remote interface, the customers may be able to obtain management
access to the node. In order to prevent this, it is recommended that the service
provider create an MPLS virtual switch specifically for use for management,
and only add a port where the VLAN-based management traffic arrives to the
MPLS virtual switch as an EVPL attachment circuit on a boundary node where
the network transitions from VLAN-based management to in-band MPLS-
based management.
Task flow
This section provides an overview of the tasks for configuring MPLS static and
dynamic configurations. The general steps for configuring MPLS are as
follows:
1 Install the MPLS software license. See Installing the MPLS license on
39XX/51XX on page 12-40.
2 Configure the IP interfaces. See Configuring IP interfaces on 39XX/51XX
on page 12-42.
3 Disable RSTP and MSTP. See Disabling RSTP and MSTP on page
12-43.
4 Configure the routing protocol(s).
a. Configure the OSPF routing protocol. See Configuring OSPF routing
protocol on page 12-44
b. Configure IS-IS routing protocol. Configuring IS-IS routing protocol
on page 12-47
5 Determine whether to use static or dynamic configuration.
6 If dynamic, configure the RSVP-TE protocol. See Configuring RSVP-TE
on page 12-52.
7 Configure label ranges. See Configuring label ranges on page 12-56.
8 Determine whether the switch is an LSR or LER based upon the location
of the switch in the network and whether to use MPLS-TE or MPLS-TP
tunnels.

9 Configure tunnels. See:

Configuring dynamic ingress TE tunnels on page 12-60.
Configuring dynamic ingress uni-directional TP tunnels on page 12-61
Configuring static TE tunnels on page 12-67
Configuring co-routed TP tunnels on page 12-69
Configuring static bi-directional ingress-associated TE tunnels on page
12-73
Configuring CoS profiles for MPLS tunnels on page 12-74
Configuring a dynamic ingress TE tunnel with FRR on page 12-76
Switching over to the backup GMPLS TP tunnel on page 12-78
Displaying MPLS TE-tunnel information on page 12-81
10 Configure LDP. See Configuring LDP on page 12-89.
11 For LER, configure the virtual circuit(s) and switch(es). See:
Configuring dynamic virtual circuits on page 12-91
Displaying virtual circuits on page 12-98
12 Configure remote management for MPLS, if desired. See:
Allocating resources for an MPLS management virtual switch (3916,
3930 and 3931 platforms) on page 12-104
Creating an MPLS management virtual switch on page 12-105
Displaying remote interface configuration on page 12-107
Changing the management virtual switch on page 12-108
Figure 12-9 provides an overview of MPLS configuration.

Figure 12-9
MPLS configuration overview
MPLS configuration
Installing the MPLS software license
Configuring IP interfaces
Disabling RSTP and MSTP
Configuring routing protocols
Static
Static or Dynamic
Dynamic?
Static configuration Dynamic configuration

Figure 12-10 provides an overview of static MPLS configuration.
Figure 12-10
MPLS static configuration overview
Static configuration
Configuring label ranges
LSR Ingress Ingress

LER
or or
Configuring ingress tunnels
LER? Egress?
LSR Egress
Configuring transit tunnels Configuring egress tunnels
Configuring virtual circuits
Configuring LDP Protocol
Configuring MPLS remote

management
End

Figure 12-11 provides an overview of dynamic MPLS configuration.
Figure 12-11
MPLS dynamic configuration overview
Dynamic configuration
Configuring RSVP-TE protocol
Configuring RSVP-TE paths
LSR Ingress
or LER or Ingress
LER? Egress? Configuring ingress tunnels
LSR Egress
Configuring transit tunnels
Configuring egress tunnels
Configuring LDP Protocol
LSR LER
or
LER?
LSR
Configuring MPLS remote

management
End

Figure 12-12 shows the workflow for configuring MPLS remote management
interface.
Figure 12-12
Remote management interface configuration overview
Yes 5150 w/ No
default
resources
Allocating resources for an MPLS

remote management interface
Creating an MPLS management

virtual switch
Displaying remote interface configuration
Changing the management virtual switch
Deleting an MPLS management virtual

switch
End

Procedure 12-1
Installing the MPLS license on 39XX/51XX
You can install a premium feature license key directly by identifying the license
key and module number. When the module number is left unspecified, the
value defaults to 1.
Step Action
1 Install a premium feature license key:

software license install [file <String>] [server <IP
Address or host name>][license-key <String>] [module
<NUMBER: 1-3>] default-tftp-server default-ftp-server
default-server default-sftp-server [sftp-server <IP
address or host name>] [tftp-server <IP address or host
name>] [ftp-server <IP address or host name>] [login-id
<String[32]>] [password <Password String>] [secret
<String[256]>]
where
file <String> is the license filename and path.
server <IP is the TFTP server.
Address or host
name>
license-key is the license key string.
<String>
module is the module number.
<NUMBER: 1-3>
default-tftp- uses the default TFTP server.
server
default-ftp-server uses the default FTP server.
default-server uses the default xFTP server.
default-sftp- uses the default SFTP server.
server
sftp-server <IP is the SFTP server.
address or host
name>
tftp-server <IP is the TFTP server.
address or host
name>
ftp-server <IP is the FTP server.
address or host
name>

where
login-id is the FTP/SFTP username.
<String[32]>
password enters the password in clear text.
<Password
String>
secret sets the password using a pre-encrypted string.
<String[256]>
end
Example
The following example installs a license key with implied module 1:
software license install license-key W123XYZ123XYZY
The following example installs a license key with module 2:
software license install license-key W123XYZ123XYZY

module 2

Procedure 12-2
Configuring IP interfaces on 39XX/51XX
For each MPLS deployment scenario, an IP interface and loopback interface
must be configured for the L2 routing domain to handle MPLS control protocol
traffic.
Step Action
1 Create the L2 flood domain for the desired VLAN and attach the underlying
L2 interfaces.
a. Create the VLAN and associate it with specific port(s).
vlan create vlan <vlan-id>
vlan add vlan <vlan-id> port <port-list>
port set port <port> pvid <vlan-id>
Note: A different VLAN should be used for each IP Interface and physical
port combination participating in the VPLS to prevents the creation of flood
domains across Layer 3 segments.
b. If operating in a ring topology, remove VLAN 1,127 from each of the
physical ports.
vlan remove vlan 1,127 port <port-list>
2 Create the IP interface to be used for routing/signaling.
interface create ip-interface <ip-interface-name> ip <ip-
address> vlan <vlan-id> [mtu <1500-9216>] [ip-forwarding
<on|off>]
3 Create the IP loopback interface (optional).
interface create loopback <loopback-interface-name> ip
<ip-address>
Note: The loopback address is typically used as the router identifier for
routing protocols, LDP identifier, and MPLS tunnel peer address.
end

Procedure 12-3
Disabling RSTP and MSTP
RSTP and MSTP do not interoperate with MPLS, so ensure these protocols
are disabled.
Step Action
To disable RSTP
1 Disable RSTP:
rstp disable
To disable MSTP
2 Disable MSTP:
mstp disable
end

Procedure 12-4
Configuring OSPF routing protocol
Configure OSPF.
The default OSPF area is area 0 (IP address 0.0.0.0 with the default type of
normal) is automatically created when you first attach an interface to area
0.0.0.0. Once created it cannot be deleted. You can optionally configure an
additional non-backbone area enabling the system to perform the functions of
an Area Border Router (ABR). With type normal, the continuous backbone
area called area 0.0.0.0 is directly connected to every other area and is used
for inter-area routing.
Step Action
To configure OSPF
1 Create an OSPF instance:
ospf instance create ospf-instance <instance-name>
where
ospf-instance is the OSPF instance name.
<instance-name>
2 Modify attributes for the OSPF instance (optional):

ospf instance set ospf-instance <ospf-instance>
where
<instance-name>
{rfc-1583- turns RFC 1583 compatibility on or off. Default is off to
compatible <on | maintain multiple intra AS routes. When AS boundary
off>} routers belong to different OSPF areas, and advertise the
same external destination, turn on RFC 1583 compatibility.
{router-id <IP is the OSPF router ID. Default is the loopback address.
address>}
{spf-delay- is the SPF delay interval in milliseconds. Default is 5000.
interval
<MILLISECOND
S: 0-
4294967295>}

3 Create an OSPF area (optional):

ospf area create area-ip <ipv4 address> ospf-instance
<instance-name> type <normal|nssa|stub>
where
area-ip <ipv4 is the IP address of the new non-backbone area.
address>
ospf-instance is the OSPF instance.
<instance-name>
type is the type of area.
4 Attach the OSPF instance to an IP interface and OSPF area:

ospf interface attach ip-interface <ip-interface> {area
<IpAddress>} {ospf-instance <instance-name>}
where
ip-interface <ip- is the IP interface name.
interface>
area <IP is the OSPF area.
address>
<instance-name>
5 Modify OSPF attributes for an IP interface (optional):

ospf interface set ip-interface <ip-interface> delay-
interval <SECONDS: 1-2147483647> hello-interval <SECONDS:
1-49999> poll-interval <SECONDS: 1-2147483647> priority
<0-255> retransmit-delay <SECONDS: 1-3000> transmit-delay
<MILLISECONDS: 1-429496799> cost-metric <NUMBER:
0..65535> authentication-type <none | text | md5>
password <Password String> [password-secret <String[62]>]
where
interface>
delay-interval is the delay interval of the interface in seconds.Default is 40
<SECONDS: 1- seconds.
2147483647>
hello-interval is the hello interval of the interface in seconds. Default is 10
49999>
poll-interval is the poll interval for the interface in seconds. Default is 120
2147483647>
priority <0-255> is the priority used for the interface. Default is 1.

where
retransmit-delay is the retransmit delay interval for the interface in seconds.
<SECONDS: 1- Default is 5 seconds.
3000>
transmit-delay is the transmit delay interval for the interface in milliseconds.
<MILLISECOND Default is 100 milliseconds.
S: 1-429496799>
cost-metric is the cost the interface. Default is 30.
authentication- is the authentication type. Default is none. Optionally, you
type <none | md5 can set the authentication type to use text or MD5
| text> authentication.
password is the authentication password of 1 to 8 characters. Default
<Password is blank. Required when the authentication type is set to text.
String>
[password-secret is the encoded password. Default is blank. Required when
<String[62]>] the authentication type is set to md5.
To display the configuration
6 Display the OSPF instance configuration (optional):
ospf instance show ospf-instance <instance-name>
where
<instance-name>
7 Display the OSPF area (optional):

ospf area show ospf-instance <instance-name> [area-ip
<area-ip>]
where
<instance-name>
area-ip <area-ip> is the area IP address.
statistics displays statistics.
8 Display OSPF IP interface information (optional):

ospf interface show ip-interface <ip-interface>
where
interface>
statistics shows OSPF interface statistics.
end

Procedure 12-5
Configuring IS-IS routing protocol
Configure IS-IS.
Step Action
To configure IS-IS
1 Create an IS-IS instance:
isis instance create isis-instance <isis-instance> area
<ISIS area> [level <L1>]
where
isis-instance is the isis instance name.
<isis-instance>
logical-id is the creation index used in configuration.
<NUMBER>]
area <ISIS area> is the area identifier, which has a variable length in Hex
(AFI.xxxx.xxxx.....).
level <L1> is the routing level.
2 Set the maximum lifetime and refresh interval to control link state packet
generation (optional):
isis lsp set isis-instance <isis-instance> [max-lifetime
<NUMBER: 350-65535>] [refresh-interval <NUMBER: 1-65535>]
where
<isis-instance>
max-lifetime is the maximum lifetime of an LSP. Default value is 1200
<NUMBER: 350- seconds.
65535>
refresh-interval is the LSP refresh interval. Default value is 900 seconds.
<NUMBER: 1-
65535>

3 Configure SPF calculation settings to control when updates to the link state
database occur (optional):
isis spf-calculations set isis-instance <isis-instance>
[max-delay <MILLISECONDS>] [threshold-restart-limit
<NUMBER: 1-100>] [threshold-update-restart <NUMBER: 1-
100>] [threshold-update-start <NUMBER: 1-100>]
where
isis-instance <isis- is the isis instance name.
instance>
max-delay is the maximum delay (msecs) to start a computation,
<MILLISECONDS> which determines how long to wait after a database update
before updating SPF routing calculations. Default is 5000
milliseconds. When set to 0, the routing calculation occurs
immediately following the database update.
threshold-restart- is the maximum number of restarts before an in-progress
limit <NUMBER: 1- computation run is completed. Default is 10.
100>
threshold-update- is the minimum number of changes before the restart of a
restart <NUMBER: in-progress computation before interrupting any running
1-100> SPF routing calculation. Default is -1 meaning that the no
interruptions will occur to SPF routing calculations. When
set to 0, a database update will cause any running SPF
routing calculation to be restarted.
threshold-update- is the minimum number of changes before the start of
start <NUMBER: 1- computation. Default is -1 meaning that the timing of the
100> SPF routing calculation is determined by the configured
calculation delay. When set to 0, any database update will
cause an SPF routing calculation to occur.
4 Configure IS-IS area authentication to authenticate sequence number

packets (SNPs), including, link state packets, CSNPs, and PSNPs (optional):
isis area-authentication set isis-instance set isis-
instance <isis-instance> [authentication-type {md5 | text
| none}] [password <Password String>][secret
<String[62]>] [send-only {yes | no} | snp-authenticate
{yes | no}]
where
<isis-instance>
authentication- is the type of authentication. Default is none. Optionally, you
type {md5 | text | can set the authentication type to use text or MD5
none} authentication.
password is the password. Default is blank. Required when the
<Password authentication type is set to text.
String>

where
[secret is the encoded password.
<String[62]>]
send-only {yes | determines whether authentication occurs only upon
no} sending packets. Default is no.
snp-authenticate is the CSNP,PSNP PDU validation.
{yes | no}
5 Configure IS-IS interface authentication at the router level (optional):
isis interface-authentication set ip-interface <ip-
interface> [authentication-type {md5 | text | none}]
[password <Password String>] [secret <String[62]>] [send-
only {yes | no}] level <L1>
where
interface>
authentication- is the type of authentication. Default is none. Optionally, you
type {md5 | text | can set the authentication type to use text or MD5
none} authentication.
password is the password. Default is blank. Required when the
<Password authentication type is set to text.
String>
[secret is the encoded password.
<String[62]>]
send-only {yes | determines whether authentication occurs only upon
no} sending packets. Default is no.
6 Associate an IP interface with an IS-IS instance:

isis interface attach ip-interface <interface-name> isis-
instance <instance-name> [level <L1>]
where
interface>
<isis-instance>

7 Modify the IS-IS padded hello for an IP interface (optional):

isis interface set ip-interface <interface-name> padded-
hello <yes | no>
where
interface>
lpadded-hello determines whether or not to pad hello packets up to the
<yes | no> MTU size of the associated IP interface. Default is to use the
padded hello.
8 Modify IS-IS interface level attributes for an IP interface:

isis interface-level set [level <L1 | L2>] [priority
<number>] [hello-timer <secs>] [hello-multiplier
<number>] [wide-metric <number>] [lsp-interval <msecs>]
[csnp-interval <secs>]
>
where
[level <L1 | L2>] is the routing level.
[priority is the designated router priority. Default is 64. Priority 0
<number>] means the interface does not become the designated router.
[hello-timer is the Minimum time between successive Hello packets.
<secs>] Default is 10 seconds.
[hello-multiplier is the hold time for transmitted hello packets. Default is 3.
<number>]
[wide-metric is the cost of the link. Default is 128.
<number>]
[lsp-interval is the Minimum time between successive link state packets
<msecs>] at the level on the circuit. Default is 50 milliseconds.
[csnp-interval is the minimum time in seconds between successive
<secs>] CSNPs. Default is 10 seconds.
To display the configuration
9 Display IS-IS instance protocol information:
isis instance show isis-instance <isis-instance>
{attached-interfaces | database | hostname | is-neighbors
{summary | details} | neighbors {summary | details} |
statistics}
where
<isis-instance>
attached- is the ISIS instance with its attachments.
interfaces
database is the protocol database details.

where
hostname is the known hostnames of IS neighbors.
is-neighbors is IS neighbors.
{summary |
details}
neighbors is the IP address of neighbors.
{summary |
details}
statistics is protocol statistics.
10 Display IS-IS interface authentication:
isis interface-authentication show [ip-interface <name>]
where
ip-interface is the IP interface.
<name>
end

Procedure 12-6
Configuring RSVP-TE
RSVP-TE sets up LSPs in dynamic deployments. By default RSVP-TE is
disabled. The minimum RSVP-TE configuration is to enable RSVP-TE is
globally and for the IP interface. RSVP-TE will signal over an IP interface when
it is enabled.
Figure 12-13 shows the workflow for configuring RSVP-TE.
Figure 12-13
MPLS RSVP-TE configuration overview
Configuring RSVP-TE retry
attributes (optional)
Configuring RSVP-TE for TE only
Configuring RSVP-TE attributes for

IP interfaces (optional)
Configuring RSVP-TE address

authentication (optional)
Configuring RSVP-TE paths (optional)
End
Step Action
1 Configure RSVP-TE retry attributes if variation from the default is

desired (optional).
a. Disable RSVP-TE.
rsvp-te disable

b. Set the retry attributes:

rsvp-te set retry-interval <NUMBER: 3...65> retry-
infinite <off>
where
retry-interval is the retry time interval in seconds. RSVP-TE attempts to
<NUMBER: restore tunnels ten times at the retry interval before it gives
3...65> up. The default setting is 3 seconds.
retry-infinite <on | turns infinite retries for RSVP tunnels on or off. If the retry
off> infinite attribute is turned on, when RSVP tunnels go down
because of any reason other than admin = down, RSVP tries
to restore the tunnel infinite times. Default is on.
c. Confirm RSVP-TE retry settings configuration (optional):

rsvp-te show [statistics]
2 Enable RSVP-TE globally.
rsvp-te enable
3 Enable RSVP-TE for the specific IP interface:
rsvp-te enable [ip-interface <interface-name>]
where
<interface-
name>
4 Configure RSVP-TE IP interface attributes if variation from the default is

desired (optional).
a. Set the RSVP-TE attributes for IP interfaces (optional):
rsvp-te set ip-interface <name> [advertised-label
<implicit-null | non-reserved>] [hello-interval
<NUMBER: 0-30>] [hello-tolerance <NUMBER: 0-10>]
[authentication-type <md5>] [message-digest-secret
<String[64]>] rs[password <password>]
where
<name>
[advertised-label is the advertised label to support an Implicit Null
<implicit-null | Label or a non-reserved label (default).
non-reserved>]
[hello-interval is the RSVP-TE hello message interval ranging from
<NUMBER: 0- 0-30 seconds. Default is 0, which is disabled.
30>]

where
[hello-tolerance is the RSVP-TE hello tolerance defines number of
<NUMBER: 0- hello intervals which may pass without receiving a
10>] successful Hello message from a partner before the
Hello session times out. The range is 0-10, and the
default is 3.
[authentication- is the authentication type to enable MD5
type <md5>] authentication. Default is none.
{password is an 8-40 character password string called the
<Password authentication message digest. Default is blank.
String>} Required when the authentication type is set to
MD5.
message-digest- is the encoded authentication message digest
secret password.
<String[64]>}
b. Confirm the RSVP-TE attributes for IP interfaces (optional):
rsvp-te interface show
5 Configure RSVP-TE IP address authentication (optional).

Step Action
a. Add an IP address:
rsvp-te authentication set peer <ip-address>
[authentication-type md5] [password <password>]
where
peer <ip- is the IP address of the peer.
address>
authentication- sets the authentication type to use MD5
type <md5> authentication. Default is blank.
password is an 8-30 character password. Required when the
<password> authentication type is set to MD5. Default is blank.
b. Confirm the IP address entry:

rsvp-te authentication show
6 Configure RSVP-TE paths (optional).
a. Create an RSVP-TE path:

rsvp-te path create rsvp-path <name>
b. Set the hops for an RSVP-TE path:
rsvp-te path set rsvp-path <name> index <number(1-
100)> ip <ip-address> [hop-type <strict | loose>]
c. Confirm configuration of all or specific paths:
rsvp-te path show [rsvp-path <name>]

Procedure 12-7
MPLS label ranges can be modified at any time. However, the chassis must
be rebooted in order for the new range to become operational. Also, label
ranges between static and dynamic cannot overlap.
CAUTION
Tunnels and VCs Could be Removed from Configuration
If there are any tunnels or virtual circuits configured to use
labels outside of the new range, they are removed from the
configuration upon reboot.
Static ingress labels can only be from the specified MPLS range. The
configured static label range determines the valid range for static in labels.
Static egress labels can be any valid label between 16-1044479. There are no
restrictions on static out labels.
The static pseudowire label range is reserved for MPLS static pseudowires.
The dynamic label range should be same on both ends of a tunnel or virtual
circuit. The dynamic label range is shared by virtual circuits and tunnels.
You can configure

static label ranges. The default minimum label value is 16; the default
maximum label value is 4095.
static pseudowire label ranges. The default minimum label value is 4096;
the default maximum label value is 8191.
dynamic label ranges. The default minimum label value is 8192; the
default maximum label value is 1044479.
Step Action
To configure static label ranges

1 Configure static tunnel label ranges:
mpls static-tunnel-label-range set min-label <16-1044479>
max-label <16-1044479>
To configure static pseudowire label ranges
2 Set the static pseudowire label range:
mpls static-vc-label-range set [min-label <NUMBER:16-
1044479>] [max-label <NUMBER:16-1044479>]

To configure dynamic label ranges

3 Configure dynamic label ranges:
mpls dynamic-label-range set min-label <18-1044479> max-
label <18-1044479>
end
Example
The following example sets the static tunnel label range with a minimum label
value of 30 and a maximum label value of 1023.
mpls static-tunnel-label-range set min-label 30 max-label 1023
The following example sets the static pseudowire label range with a minimum
label value of 30 and a maximum label value of 1023.
mpls static-vc-label-range set min-label 30 max-label 1023
The following example sets the dynamic label range with a minimum label
value of 2048 and a maximum label value of 131071.
mpls dynamic-label-range set min-label 2048 max-label 131071

Procedure 12-8
Displaying label ranges
You can display
static label ranges for tunnels
static label ranges for MPLS pseudowires
dynamic label ranges
Step Action
To display static label ranges for tunnels

1 Display static label ranges:
mpls static-tunnel-label-range show
To display static label ranges for MPLS pseudowires
2 Display static label ranges for MPLS pseudowires:
mpls static-vc-label-range show
To display dynamic label ranges
3 Display dynamic label ranges:
mpls dynamic-label-range show
end
Example
The following example shows sample output for the mpls static-tunnel-label-
range show command.

+--------------- MPLS/GMPLS Static Label Range ----------------+
| MPLS Admin Min Static-Total Label | 16 |
| MPLS Admin Max Static-Total Label | 8191 |
| MPLS Admin Min Static-Tunnel Label | 16 |
| MPLS Admin Max Static-Tunnel Label | 4095 |
+------------------------------------+-------------------------+
| MPLS Oper Min Static-Total Label | 16 |
| MPLS Oper Max Static-Total Label | 8191 |
| MPLS Oper Min Static-Tunnel Label | 16 |
| MPLS Oper Max Static-Tunnel Label | 4095 |
+------------------------------------+-------------------------+

The following example shows sample output for the mpls static-vc-label-range
show command.
+--------------- MPLS/GMPLS Static Label Range ----------------+

| MPLS Admin Min Static-Total Label | 16 |
| MPLS Admin Max Static-Total Label | 8191 |
| MPLS Admin Min Static-VC Label | 4096 |
| MPLS Admin Max Static-VC Label | 8191 |
+------------------------------------+-------------------------+
| MPLS Oper Min Static-Total Label | 16 |
| MPLS Oper Max Static-Total Label | 8191 |
| MPLS Oper Min Static-VC Label | 4096 |
| MPLS Oper Max Static-VC Label | 8191 |
+------------------------------------+-------------------------+
The following example shows sample output for the mpls dynamic-label-range
show command.
mpls dynamic-label-range show
+----------- MPLS/GMPLS Dynamic Label Range --------------+

| MPLS Admin Min Dynamic Label | 8192 |
| MPLS Admin Max Dynamic Label | 1044479 |
| MPLS Oper Min Dynamic Label | 8192 |
| MPLS Oper Max Dynamic Label | 1044479 |
+-------------------------------+-------------------------+

Procedure 12-9
Configuring dynamic ingress TE tunnels
For LERs, an ingress tunnel must be created. In order to manage bandwidth,
an tunnel bandwidth profile can be created first and then associated with the
tunnel.
Step Action
1 Create a tunnel bandwidth profile (optional):

mpls tunnel-bandwidth-profile create bandwidth-profile
<profile-name> bandwidth <NUMBER: 1000-10000000> [burst
<NUMBER: 12-256>]
2 Confirm the tunnel bandwidth profile configuration (optional):
mpls tunnel-bandwidth-profile show
3 Create a dynamic ingress TE tunnel:
mpls tunnel create rsvp-ingress <rsvp-ingress> dest-ip
<ip-address> [setup-priority <0-7>] [hold-priority <0-7>]
[bandwidth-profile <MPLS Tunnel Bandwidth Profile>]
[record-route <on | off>] {protection-type <link | node>}
[frr-signaling <on | off>] [frr-profile <MPLS Tunnel FRR
Profile>] [explicit-tunnel-path <MPLS Rsvp Path>] [cos-
profile <MPLS Tunnel COS Profile>] {ttl-policy <fixed>}
[fixed-ttl <NUMBER: 1-255>] [backup-tunnel <MPLS ingress
primary tunnel>] [reversion-hold-time <NUMBER: 0-3600>]
[tunnel-reversion <on | off>]
4 Enable the dynamic ingress TE tunnel:
mpls tunnel enable rsvp-ingress <rsvp-ingress>
end

Procedure 12-10
Configuring dynamic ingress uni-directional TP
tunnels
Configure dynamic ingress uni-directional TP tunnels.
Step Action
1 Create a dynamic ingress uni-directional GMPLS TP-Tunnel:

gmpls tp-tunnel create rsvp-ingress-unidir <rsvp-ingress-
unidir> dest-ip <IP address> [setup-priority <NUMBER: 0-
7>] [hold-priority <NUMBER: 0-7>] [bandwidth-profile
<MPLS Tunnel Bandwidth Profile>] [record-route <on |
off>] [cos-profile <MPLS Tunnel COS Profile>] {ttl-policy
<fixed>} [fixed-ttl <NUMBER: 1-255>] [reversion-hold-time
<NUMBER: 0-3600>] [tunnel-reversion <on | off>]
2 Confirm the configuration of the dynamic uni-directional TP tunnel:
gmpls tp-tunnel show rsvp-transit-unidir
<MplsTransitDynamicTpUniDirTunl>
end
Example
Dynamic unidirectional ingress TP tunnel
gmpls tp-tunnel create rsvp-ingress-unidir TP_UD_R1ToR3 dest-ip 1.1.1.1
gmpls tp-tunnel show rsvp-ingress-unidir TPUD_R1TOR3
+----------------GMPLS INGRESS TP-TUNNEL DETAILS-------------+

+---------------------------+--------------------------------+
|Tunnel Name |TPUD_R1TOR3 |
|Tunnel Index |8 |
|Tunnel Type |Dynamic |
|Direction |Unidir |
|Nodal Role |Ingress |
|Destination IP Address |1.1.1.1 |
|Source IP Address |10.10.10.10 |
|Next-Hop IP Address |5.1.1.1 |
|Admin State |Enabled |
|Oper State |Enabled |
|Forward Out-Label |11004 |
|LSP ID |1 |
|Explicit Path Index |0 |
|Explicit Path Name | |
|Setup Priority |7 |
|Hold Priority |0 |
|Record Route |On |
|CSPF Route Selection |On |
|Bandwidth-Profile Name | |
|Forward Tunnel Group Index |32776 |

|Forward Protection Role |Primary |

|Forward Protection State |Active |
|Forward Backup Tunnel Name |None Present |
|Forward Tunnel Reversion |On |
|Forward Reversion Hold-Time|30 |
|Forward CoS Profile Name |DefaultTunlCoSProfile |
|Forward CoS Profile Index |1 |
|TTL Policy |fixed |
|Fixed TTL |255 |
+---------------------------+--------------------------------+
Example
Dynamic uni-directional ingress TP tunnel with backup protection
gmpls tp-tunnel create rsvp-ingress-unidir rsvp-itnl-1.1.1.1 dest-ip 1.1.1.1
explicit-tunnel-path path-prim-1.1.1.1
gmpls tp-tunnel create rsvp-ingress-unidir rsvp-itnl-tp-bkp dest-ip 1.1.1.1

explicit-tunnel-path path-protect-1.1.1.1 backup-tunnel rsvp-itnl-1.1.1.1
gmpls tunnel show
Flags : P -> Primary B -> Backup

A -> Active S -> Standby
L -> Lone Member R -> Recovery Group Member
E -> Tunnel uses Explicit Path
+-------+--------+----------GMPLS INGRESS TP-TUNNEL TABLE---------+-------+-----+-----+-------+
|Type |Tunnel | Tunnel Name |Destination IP |Out |Admin|Oper | Flags |
| |Index | | |Label |State|State| |
+-------+--------+--------------------------------+---------------+-------+-----+-----+-+-+-+-+
|Dynamic|13 |rsvp-itnl-1.1.1.1 |1.1.1.1 |8202 |ENA |ENA |P|R|A|E|
|Dynamic|14 |rsvp-itnl-tp-bkp |1.1.1.1 |8193 |ENA |ENA |B|R|S|E|
+-------+--------+--------------------------------+---------------+-------+-----+-----+-+-+-+-+

Procedure 12-11
Configuring static transit uni-directional TP tunnels
Configure static transit uni-directional TP tunnels.
Step Action
1 Create a static transit uni-directional TP Tunnel:

gmpls tp-tunnel create static-transit-unidir <static-
transit-unidir> {dest-ip <IP address>} {src-ip <IP
address>} {next-hop-ip <IP address>} {forward-out-label
<NUMBER: 16-1044479>} {forward-in-label <NUMBER: 16-
1044479>} [cos-profile <MPLS Tunnel COS Profile>] {ttl-
policy <fixed | decrement>} [fixed-ttl <NUMBER: 1-255>]
[prev-hop-ip <IP address>] [ais-monitor <enable |
disable>] [ais-profile <AIS Profile List>]
2 Confirm the configuration.
gmpls tp-tunnel show static-transit-unidir <static-
transit-unidir>
end
Example
gmpls tp-tunnel create static-transit-unidir asoc-frm-10.10.10.10-to-1.1.1.1
dest-ip 1.1.1.1 src-ip 10.10.10.10 next-hop-ip 42.1.1.15 forward-in-label
1003 forward-out-label 1001
gmpls tp-tunnel create static-transit-unidir asoc-frm-1.1.1.1-to-10.10.10.10
dest-ip 10.10.10.10 src-ip 1.1.1.1 next-hop-ip 11.11.11.100 forward-in-label
1000 forward-out-label 1002

Procedure 12-12
Configuring static uni-directional ingress TP tunnels
Configure static ingress uni-directional TP tunnels.
Step Action
1 Create a static ingress uni-directional TP Tunnel:

gmpls tp-tunnel create static-ingress-unidir <static-
ingress-unidir> dest-ip <IpAddress> logical-id <number>
[src-tunnel-id <NUMBER>] [forward-lsp-id <NUMBER>] dest-
tunnel-id <NUMBER>] next-hop-ip <IpAddress> forward-out-
label <#16..1044479> [cos-profile <MplsTunlCosProfile>
[ttl-policy <fixed>] [recovery-nhop-disjoint
<none|link>] fixed-ttl <#1..255> reversion-hold-time
<#0..3600> tunnel-reversion <on|off> backup-tunnel
<MplsIngressPrimaryTpUniDirTunl>
gmpls tp-tunnel show static-ingress-unidir
<MplsIngressStaticTpUniDirTunl>
end
Example
Static uni-directional ingress TP tunnel
gmpls tp-tunnel create static-ingress-unidir st-ing-u-A dest-ip 1.1.1.1 next-
hop-ip 11.11.11.50 forward-out-label 1003
gmpls tp-tunnel show static-ingress-unidir st-ing-u-A
+---------------------------+--------------------------------+
|Tunnel Name |st-ing-u-A |
|Tunnel Index |4 |
|Tunnel Type |Static |
|Direction |Unidir |


|Fixed TTL |255 |
+---------------------------+--------------------------------+
Example
Static uni-directional ingress TP tunnel with backup protection
gmpls tp-tunnel create static-ingress-unidir sta-ing-u-tp-P dest-ip 1.1.1.1
next-hop-ip 5.1.1.1 forward-out-label 2003
gmpls tp-tunnel create static-ingress-unidir sta-ing-u-tp-B dest-ip 1.1.1.1

next-hop-ip 4.1.1.1 forward-out-label 2040 backup-tunnel sta-ing-u-tp-P
gmpls tp-tunnel show

+-------+--------+----------GMPLS INGRESS TP-TUNNEL TABLE---------+-------+-----+-----+-------+
|Type |Tunnel | Tunnel Name |Destination IP |Out |Admin|Oper | Flags |
| |Index | | |Label |State|State| |
+-------+--------+--------------------------------+---------------+-------+-----+-----+-+-+-+-+
|Static |11 |sta-ing-u-tp-P | 1.1.1.1 |2003 |ENA |ENA |P|R|A| |
|Static |12 |sta-ing-u-tp-B | 1.1.1.1 |2040 |ENA |ENA |B|R|S| |
+-------+--------+--------------------------------+---------------+-------+-----+-----+-+-+-+-+

Procedure 12-13
Configuring static uni-directional egress TP tunnels
Configure static uni-directional egress TP tunnels.
Step Action
1 Create a static egress uni-directional TP Tunnel:

gmpls tp-tunnel create static-egress-unidir <tp-tunnel-
name> src-ip <IpAddress> forward-in-label <#16..1044479>
prev-hop-ip <IpAddress> logical-d <number> [src-tunnel-id
<NUMBER>] [forward-lsp-id <NUMBER>][dest-tunnel-id
<NUMBER>] [recovery-phop-disjoint <none|link>]
gmpls tp-tunnel show static-egress-unidir
<MplsEgressStaticTpUniDirTunl>
end
Example
gmpls tp-tunnel create static-egress-unidir st-egr-u-A src-ip 1.1.1.1
forward-in-label 1002 prev-hop-ip 192.168.1.2 logic-id 10 src-tunnel-id 10
forward-lsp-id 1 dest-tunnel-id 10
gmpls tp-tunnel create static-egress-unidir st-egr-u-B src-ip 2.2.2.2

forward-in-label 1050 prev-hop-ip 192.168.2.2 logic-id 11 src-tunnel-id 11
forward-lsp-id 1 dest-tunnel-id 11

Procedure 12-14
Configuring static TE tunnels
A static TE deployment requires tunnel creation. The type of tunnel depends
on the role of the MPLS switch.
For ingress and egress LERs, create both an ingress and egress tunnel.
For an LSR, create a transit tunnel.
Note: The value for in-label must be in the configured static MPLS virtual
circuit label range.
Step Action
To configure a static ingress tunnel
1 Create a static ingress tunnel:

mpls tunnel create static-ingress <static-ingress>
[dest-ip <IP address>] [next-hop-ip <IP address>] {out-
label <NUMBER: 16-1044479>} [cos-profile <MPLS Tunnel COS
Profile>] {ttl-policy <fixed>} [fixed-ttl <NUMBER: 1-
255>] [recovery-nhop-disjoint <none | link>][backup-
tunnel <MPLS ingress primary tunnel>] [reversion-hold-
time <SECONDS: 0-3600>] [tunnel-reversion <on | off>]
To configure a static egress tunnel
2 Create a static egress tunnel:
mpls tunnel create static-egress <static-egress> [src-ip
<IP address>] {in-label <NUMBER: 16-1044479>}
To configure a static transit tunnel
3 Create a static transit tunnel:
mpls tunnel create static-transit <static-transit>
{dest-ip <IP address>} {src-ip <IP address>} {next-hop-ip
<IP address>} {in-label <NUMBER: 16-1044479>} {out-label
<NUMBER: 16-1044479>} {out-explicit-null-label} {out-no-
label} [cos-profile <MPLS Tunnel COS Profile>] {ttl-
policy <fixed | decrement>} [fixed-ttl <NUMBER: 1-255>]
[prev-hop-ip <IP address>] [ais-monitor <enable |
end

Example
MPLS-TE static ingress tunnel
mpls tunnel create static-ingress st-1.1.1.1-A dest-ip 1.1.1.1 next-hop-ip
11.11.11.50 out-label 300
Example
MPLS-TE static egress tunnel
mpls tunnel create static-egress st-frm-1.1.1.1 src-ip 1.1.1.1 in-label 400
Example
MPLS-TE static transit tunnel
mpls tunnel create static-transit frm-10.10.10.10-to-1.1.1.1 dest-ip 1.1.1.1
src-ip 10.10.10.10 next-hop-ip 42.1.1.15 in-label 300 out-label 301
mpls tunnel create static-transit frm-1.1.1.1-to-10.10.10.10 dest-ip
10.10.10.10 src-ip 1.1.1.1 next-hop-ip 11.11.11.100 in-label 401 out-label 400

Procedure 12-15
Configuring co-routed TP tunnels
Co-routed TP tunnels can be:
static ingress
static egress
static transit
Table 12-17 lists the default values for static ingress and egress co-routed TP
tunnels.
Table 12-17
Default values for static co-routed TP tunnels
Attribute Default value
ttl-policy fixed
fixed-ttl 255
reversion-hold-time 30
tunnel-reversion on
bfd-monitor disable
bfd-profile LSP_BFD_DEF_PROF
ais-monitor disable
ais-profile AIS_DEF_PROF
Note: The value for forward-in-label of the egress tunnel must be in the
configured static MPLS tunnel label range.
Step Action
To configure a static ingress co-routed TP tunnel

1 Create a static ingress co-routed TP-Tunnel:
gmpls tp-tunnel create static-ingress-corout <static-
ingress-corout> {dest-ip <IP address>} {next-hop-ip <IP
address>} {forward-out-label <NUMBER: 16-1044479>}
{reverse-in-label <NUMBER: 16-1044479> [cos-profile <MPLS
Tunnel COS Profile>] {ttl-policy <fixed>} [fixed-ttl
<NUMBER: 1-255>] [recovery-nhop-disjoint
<none|link>]logical-id <number> [src-tunnel-id
<NUMBER>][forward-lsp-id <NUMBER>][dest-tunnel-id

<NUMBER>] [backup-tunnel <MPLS ingress primary tp corout

tunnel>] [reversion-hold-time <NUMBER: 0-3600>] [tunnel-
reversion <on | off>] [bfd-monitor <enable | disable>]
[bfd-profile <MPLS BFD Profile List>] [ais-monitor
<enable | disable>] [ais-profile <AIS Profile List>]
2 Confirm static ingress co-routed TP-Tunnel creation:
gmpls tp-tunnel show static-ingress-corout <static-
ingress-corout>
To configure a static egress co-routed TP tunnel
3 Create a static egress co-routed TP-Tunnel:
gmpls tp-tunnel create static-egress-corout <static-
egress-corout> src-ip <IP address> prev-hop-ip <IP
address> forward-in-label <NUMBER: 16-1044479> reverse-
out-label <NUMBER: 16-1044479> [cos-profile <MPLS Tunnel
COS Profile>] [ttl-policy <fixed>] [fixed-ttl <NUMBER: 1-
255>] [reversion-hold-time <NUMBER: 0-3600>] [tunnel-
reversion <on | off>] [recovery-phop-disjoint
<none|link>]logical-id <number> [src-tunnel-id
<NUMBER>][forward-lsp-id <NUMBER>][dest-tunnel-id
<NUMBER>][backup-tunnel <MPLS static egress primary tp-
tunnel>] [bfd-monitor <enable | disable>] [bfd-profile
<MPLS BFD Profile List>][ais-monitor <enable | disable>]
[ais-profile <AIS Profile List>]
4 Confirm static egress co-routed TP-Tunnel creation:
gmpls tp-tunnel show static-egress-corout <static-egress-
corout>
To configure a static transit co-routed TP tunnel
5 Create a static transit co-routed TP-Tunnel:
gmpls tp-tunnel create static-transit-corout <static-
egress-corout> dest-ip <IP address> src-ip <IP address>
next-hop-ip <IP address> prev-hop-ip <IP address>
forward-in-label <NUMBER: 16-1044479> forward-out-label
<NUMBER: 16-1044479> reverse-in-label <NUMBER: 16-
1044479> reverse-out-label <NUMBER: 16-1044479> [cos-
profile <MPLS Tunnel COS Profile>] [ttl-policy <fixed>]
[fixed-ttl <NUMBER: 1-255>] [ais-monitor <enable |
6 Confirm static transit co-routed TP-Tunnel creation:
gmpls tp-tunnel show static-transit-corout <static-
transit-corout>
end
Example
GMPLS Static Co-routed ingress TP-Tunnel Creation

gmpls tp-tunnel create static-ingress-corout icor-to-1.1.1.1 dest-ip 1.1.1.1

next-hop-ip 5.1.1.1 forward-out-label 2003 reverse-in-label 2002
GMPLS Static Co-routed ingress TP-Tunnel Display

gmpls tp-tunnel show static-ingress-corout icor-to-1.1.1.1

+---------------------------+--------------------------------+
|Tunnel Name |icor-to-1.1.1.1 |
|Tunnel Index |6 |
|Direction |Bidir |
|Reverse In-Label |2002 |
|Fixed TTL |255 |
|BFD Monitoring |Disabled |
|BFD Profile ID |2 |
|BFD Profile Name |Active-LSP |
|BFD Session ID |3 |
|BFD Session Name |LBFS_10_06_icor-to-1.1.1.1_E |
|BFD Session Error Code |0 |
|AIS Monitoring |Disabled |
+---------------------------+--------------------------------+
Static Co-routed Egress TP-Tunnel Creation

gmpls tp-tunnel create static-egress-corout ecor-frm-2.2.2.2 src-ip 2.2.2.2
prev-hop-ip 5.1.1.1 forward-in-label 2040 reverse-out-label 2041
Static Co-routed Egress TP-Tunnel Detailed Display

gmpls tp-tunnel show static-egress-corout egr-cor-10.10.10.10
+------------GMPLS STATIC EGRESS TP-TUNNEL DETAILS-----------+

+---------------------------+--------------------------------+
|Tunnel Name |egr-cor-10.10.10.10 |
|Tunnel Index |2 |
|Direction |Bidir |
|Nodal Role |Egress |


|Prev-Hop IP Address |10.11.12.2 |
|Forward In-Label |2001 |
|Reverse Out-Label |2000 |
|Reverse Tunnel Group Index |32774 |
|Reverse Protection Role |Primary |
|Reverse Protection State |Active |
|Reverse Backup Tunnel Name |None Present |
|Reverse Tunnel Reversion |On |
|Reverse Tunl Reversion Time|30 |
|Reverse CoS-Profile Name |DefaultTunlCoSProfile |
|Reverse CoS-Profile Index |1 |
|Reverse TTL Policy |fixed |
|Reverse Fixed TTL |255 |
|BFD Monitoring |Disabled |
|BFD Profile ID |2 |
|BFD Profile Name |Active-LSP |
|BFD Session ID |2 |
|BFD Session Name |LBFS_12_02_egr-cor-10.10.10_E |
|BFD Session Error Code |0 |
|AIS Monitoring |Disabled |
+---------------------------+--------------------------------+
Static Co-routed transit TP-Tunnel Creation

gmpls tp-tunnel create static-transit-corout co-10.10.10.10-to-1.1.1.1 dest-
ip 1.1.1.1 src-ip 10.10.10.10 next-hop-ip 10.11.12.1 prev-hop-ip 5.1.1.10
forward-out-label 2001 forward-in-label 2003 reverse-out-label 2002 reverse-
in-label 2000
Static Co-routed transit TP-Tunnel Detailed Display
gmpls tp-tunnel show static-transit-corout co-10.10.10.10-to-1.1.1.1
+--------------GMPLS TRANSIT TP-TUNNEL DETAILS---------------+
+---------------------------+--------------------------------+
|Tunnel Name |co-10.10.10.10-to-1.1.1.1 |
|Tunnel Index |1 |
|Direction |Bidir |
|Nodal Role |Transit |
|Prev-Hop IP Address |5.1.1.10 |
|Forward In-Label |2003 |
|Reverse In-Label |2000 |
|Reverse Out-Label |2002 |
|TTL Policy |decrement |
|Fixed TTL |255 |
|AIS Monitoring State |Disabled |
+---------------------------+--------------------------------+

Procedure 12-16
Configuring static bi-directional ingress-associated
TE tunnels
Configure both ends of static bi-directional ingress-associated TE tunnels.
Step Action
1 Create a bi-directional ingress associated TE-Tunnel:

mpls tunnel create bidir-ingress-assoc <bidir-ingress-
assoc> {forward-tunnel <MPLS ingress tunnel>} {reverse-
static-tunnel <MPLS egress tunnel>} {reverse-dyntun-name
<String>} [reverse-dyntun-srcip <IP address>] [bfd-
monitor <enable | disable>] [bfd-profile <MPLS BFD
Profile List>] [ais-monitor <enable | disable>] [ais-
profile <AIS Profile List>]
2 Enable a bi-directional ingress associated TE-Tunnel:
mpls tunnel enable bidir-ingress-assoc <bidir-ingress-
assoc>
end
Example
TE-Associated tunnel creation of st-ing-associ-AP with a forward-tunnel
(ingress) of st-1.1.1.1-A and the reverse-static-tunnel of st-frm-1.1.1.1
(egress) shown in the examples for Configuring static TE tunnels on
page 12-67.
mpls tunnel create bidir-ingress-assoc st-ing-assoc-AP forward-tunnel st-
1.1.1.1-A reverse-static-tunnel st-frm-1.1.1.1

Procedure 12-17
Configuring CoS profiles for MPLS tunnels
Configure CoS profiles for MPLS tunnels.
Step Action
1 Create an MPLS tunnel CoS profile:

mpls tunnel-cos-profile create cos-profile <cos-profile>
[frame-cos-map <RCOS to FCOS Map>] [frame-cos-policy
<mapped | fixed>] [fixed-tc <NUMBER: 0-7>] [resolved-cos-
map <FCOS to RCOS Map>] [resolved-cos-policy <mapped |
fixed>]
2 Confirm the configuration of the specific profile.
mpls tunnel-cos-profile show cos-profile <cos-profile>
3 Display a summary of CoS profiles. (option
end
Example
mpls tunnel-cos-profile create cos-profile TE_TUN_COS_PROF frame-cos-policy
fixed fixed-tc 4 resolved-cos-policy fixed resolved-cos-fixed 6
mpls tunnel-cos-profile show cos-profile TE_TUN_COS_PROF
+------------MPLS Tunnel-CoS-Profile Details-----------------+

+---------------------------+--------------------------------+
|CoS Profile Name |TE_TUN_COS_PROF |
|CoS Profile Index |2 |
|Frame CoS Policy |fixed |
|Frame CoS Map Name |DefaultRcosFcos |
|Frame CoS Map ID |1 |
|Fixed TC |4 |
|Resolved CoS Policy |fixed |
|Resolved CoS Map Name |DefaultFcosRcos |
|Resolved CoS Map ID |1 |
|Resolved CoS Fixed |6 |
|Use Count |0 |
+---------------------------+--------------------------------+

Procedure 12-18
Configuring CoS profiles for MPLS tunnels
Display a summary of CoS profiles for MPLS tunnels.
Step Action
1 Display a summary of CoS profiles. (option

end
Example
mpls tunnel-cos-profile show
+-----------------------------------------------------------------------------------------------------------+
+---- MPLS Tunnel-COS-Profile Table ----+
+--------------------------------+------+-----------+--------+-------+----------+----------+---------+------+
| CoS-Mapping Profile Name |Index |FCoSPolicy|FCoSMapID|FixedTc|RCoSPolicy|RCoSMapID |RCoSFixed|UseCnt|
+--------------------------------+------+-----------+--------+-------+----------+----------+---------+------+
|DefaultTunlCoSProfile |1 |mapped |1 |0 |mapped |1 |0 |8 |
|TE_TUN_COS_PROF |2 |fixed |1 |4 |fixed |1 |6 |0 |
+--------------------------------+------+-----------+--------+-------+----------+----------+---------+------+

Procedure 12-19
Configuring a dynamic ingress TE tunnel with FRR
Configure a dynamic ingress tunnel with FRR to provide quick failover to a
bypass LSP at an intermediate LSR when a local fault is detected. The head-
end router signals FRR preferences to Point-of-Local-Repair (PLR) LSRs.
Note: FRR is configurable for MPLS-TE LSPs only.
Step Action
1 Create a tunnel Fast Reroute (FRR) profile:

mpls tunnel-frr-profile create frr-profile <frr-profile>
[setup-priority < NUMBER: 0-7>] [hold-priority <NUMBER:
0-7>] [hop-limit <NUMBER: 0-255>] [bandwidth <NUMBER:
1000-10000000>] [bw-protection <yes | no>] [node-
protection <yes | no>] [protection-method <detour
|facility >] [ color-group-include-any <NUMBER: 0-31>]
[color-group-include-all <NUMBER: 0-31>] [ color-group-
exclude-any <NUMBER: 0-31>]
2 Confirm the FRR profile:
mpls tunnel-frr-profile show
mpls tunnel-frr-profile show frr-profile <frr-profile>
3 Configure the tunnel at the head-end LER with FRR settings:
<ip-address> [setup-priority <0-7>] [hold-priority <0-7>]
[bandwidth-profile <MPLS Tunnel Bandwidth Profile>]
record-route on {protection-type <link | node>} [frr-
signaling <on | off>] [frr-profile <MPLS Tunnel FRR
Profile>] [explicit-tunnel-path <MPLS Rsvp Path>] [cos-
profile <MPLS Tunnel COS Profile>] {ttl-policy <fixed>}
[fixed-ttl <NUMBER: 1-255>] [backup-tunnel <MPLS ingress
primary tunnel>] [reversion-hold-time <NUMBER: 0-3600>]
[tunnel-reversion <on | off>]
4 Configure facility-based detours at each LSR (the candidate PLRs).
end
Example
MPLS-TE FRR Signaling Profile Create
mpls tunnel-frr-profile create frr-profile TETUN_FRR_PROFILE node-protection
yes setup-priority 5 hold-priority 5 hop-limit 14 protection-method facility
bw-protection yes bandwidth 5000 colour-group-include-any 13 colour-group-
exclude-any 23

MPLS-TE FRR Signaling Profile Display

mpls tunnel-frr-profile show
+-------------MPLS Tunnel Fast-Reroute Profile Table-------+--------+
| Profile Name | Protection | Protection | UseCnt |
| | BW | Node | Method | |
+--------------------------------+-----+------+------------+--------+
|DefaultFrrProfile |NO |NO |facility |0 |
|TETUN_FRR_PROFILE |YES |YES |facility |0 |
+--------------------------------+-----+------+------------+--------+
mpls tunnel-frr-profile show frr-profile TETUN_FRR_PROFILE
+-------------MPLS Tunnel Fast-Reroute Profile Details---------------+

|Profile Name |TETUN_FRR_PROFILE |
|Profile index |2 |
|Profile use count |0 |
|Setup Priority |5 |
|Hold Priority |5 |
|Hop Limit |14 |
|Bandwidth |5000 |
|Bandwidth Protection |YES |
|Node Protection |YES |
|Protection Method |Facility |
|Color Group Include Any |13 |
|Color Group Include All |0 |
|Color Group Exclude Any |23 |
+--------------------------------------------------------------------+

Procedure 12-20
Switching over to the backup GMPLS TP tunnel
You can switch over a:
GMPLS TP tunnel
static ingress bi-directional co-routed TP tunnel
static egress bi-directional co-routed TP tunnel
You can only switch over the active tunnel.
Note: If tunnel reversion is on, the system switches from the backup to
the primary tunnel once the fault on the primary tunnel is cleared and after
waiting the amount of time specified as the reversion hold time (the default
is 30 seconds). Do not switch over the backup GMPLS TP tunnel while the
reversion hold timer is counting down.
Step Action
To switch over a GMPLS TP tunnel

1 Switch a GMPLS TP-Tunnel to the backup tunnel:
gmpls tp-tunnel switchover rsvp-ingress-unidir <rsvp-
ingress-unidir>
To switch over a static ingress bi-directional co-routed TP tunnel
2 Switch a static ingress bi-directional co-routed TP-Tunnel to the backup
tunnel:
gmpls tp-tunnel switchover static-ingress-corout <static-
ingress-corout>
To switch over a static egress bi-directional co-routed TP tunnel
3 Switch a static egress bi-directional co-routed TP-Tunnel to the recovery
tunnel:
gmpls tp-tunnel switchover static-egress-corout <static-
egress-corout>
end

Procedure 12-21
Switching over to the backup TE tunnel
You can switch over:
an MPLS TE-Tunnel
a static ingress TE-Tunnel
a static bi-directional ingress associated TE-Tunnel
Step Action
To switch over an TE tunnel

1 Switch an active MPLS TE-Tunnel to the backup MPLS TE-Tunnel:
mpls tunnel switchover rsvp-ingress <rsvp-ingress>
To switch over a static ingress TE tunnel
2 Switch an active static ingress tunnel to the backup static ingress tunnel:
mpls tunnel switchover rsvp-ingress <rsvp-ingress>
To switch over a static bi-directional ingress associated TE Tunnel
3 Switch a static bi-directional ingress associated TE-Tunnel to the backup bi-
directional associated TE-Tunnel:
mpls tunnel switchover bidir-ingress-assoc <bidir-
ingress-assoc>
end

Procedure 12-22
Switching over to protection pseudowire
You can manually switch over to the dynamic protection virtual circuit.
Step Action
1 Switch over to the dynamic protection virtual circuit:

mpls l2-vpn protection switchover dynamic-vc <dynamic-vc>
end

Procedure 12-23
Displaying MPLS TE-tunnel information
Display tunnel information to confirm configuration.
You can display a list of tunnels, including:

type
index
name
destination IP address
label
administrative state
operational state
Optionally, you can display details about a specific tunnel. Also, you can filter
to display a list of tunnels by:
tunnel configuration (static or dynamic)
type (ingress or egress)
state (up or down)
specific static egress tunnel
Step Action
To display all or a specific tunnel

1 Display all or a specific tunnel:
mpls tunnel show matching-lsp <matching-lsp> {persist
<static|dynamic>} {type <ingress|egress |transit>} [state
<up|down>] [source <IP address>] [destination <IP
address>] [next-hop <IP address>] [out-ip-intf <Interface
Supports Signals>] [in-label <NUMBER: 16-1044479>] [out-

label <NUMBER: 16-1044479>] [recovery

<protected|unprotected>] [role <primary|backup|locally-
repaired| active-backup>]}
where
matching-lsp is the tunnel to be displayed.
<matching-lsp>
persist <static | filters by persistence.
dynamic>
type <ingress | filters by tunnel type.
egress | transit>
state <up | down> filters by operational state.
source <IP filters by source IP address.
address>
destination <IP filters by destination IP address.
address>
next-hop <IP filters by next hop IP address.
address>
out-ip-intf filters by outgoing IP interface.
<Interface
Supports
Signals>
in-label filters by inbound label
<NUMBER: 16-
1044479>
out-label filters by outbound label.
<NUMBER: 16-
1044479>
recovery filters by LSP recovery type.
<protected |
unprotected>
role <primary | filters by LSP protection role.
backup | locally-
repaired | active-
backup>
To display static ingress TE-tunnels

2 Display static ingress TE-tunnels:
mpls tunnel show static-ingress <static-ingress>
To display dynamic ingress TE-tunnels
3 Display dynamic ingress TE-tunnels:
mpls tunnel show rsvp-ingress <rsvp-ingress>

To display static egress TE-tunnels

4 Display static egress TE-tunnels:
mpls tunnel show static-egress <static-egress> src-ip <IP
address>
To display static transit TE-tunnels
5 Display static transit TE-tunnels:
mpls tunnel show static-transit <static-transit>
To display FRR bypass TE-LSPs
6 Display FRR bypass TE-LSPs:
mpls tunnel show frr-bypass-lsp <frr-bypass-lsp>
To display bi-directional ingress associated tunnels
7 Display all bi-directional ingress associated TE-Tunnel(s) or only the attribute
matched bi-directional associated TE tunnels:
mpls tunnel show matching-assoc <matching-assoc> [state
<up | down>] [destination <IP address>] [next-hop <IP
address>] [out-ip-intf <Interface Supports Signals>]
[out-label <NUMBER: 16-1044479>] [in-label <NUMBER: 16-
1044479>] [recovery <protected|unprotected>] [role
<primary|backup|locally-repaired|active-backup>]}
where
matching-assoc is the tunnel to be displayed.
<matching-
assoc>
address>
address>
out-ip-intf filters by outgoing IP interface.
<Interface
Supports
Signals>
out-label filters by out-bound label.
<NUMBER: 16-
1044479>

where
in-label filters by in-bound label.
<NUMBER: 16-
10444795>
recovery filters by recovery type.
<protected |
unprotected>
role <primary | filters by protection role.
backup | locally-
repaired | active-
backup>
To display bi-directional ingress associated tunnels
8 Display all bi-directional ingress associated TE-Tunnels:
mpls tunnel show bidir-ingress-assoc <bidir-ingress-
assoc>
To display static tunnel label range information
9 Display static tunnel label range information:
To display static label range information for MPLS pseudowires
10 Display static label range information for MPLS pseudowires:
To display the tunnel FRR profile for a specified FRR profile
11 Display the tunnel FRR profile for a specified FRR profile:
mpls tunnel-frr-profile show frr-profile <frr-profile>
To display the tunnel CoS profile
12 Display the selected tunnel CoS profile:
end

Procedure 12-24
Displaying GMPLS TP tunnel information
Display tunnel information to confirm configuration.
You can display:

GMPLS TP tunnels
tunnels filtered by attribute
static ingress TP co-routed tunnels
static ingress TP uni-directional tunnels
dynamic ingress TP uni-directional tunnels
static egress TP co-routed tunnels
static egress TP uni-directional tunnels
static transit TP co-routed tunnels
static transit TP uni-directional tunnels
bi-directional associated TP tunnels
bi-directional ingress TP tunnels
Step Action
To display GMPLS TP tunnels

1 Display GMPLS TP tunnels:
gmpls tp-tunnel show
To display tunnels filtered by attribute
2 Display tunnels filtered by attribute:
gmpls tp-tunnel show matching-lsp <matching-lsp> {persist
<static|dynamic>} {type <ingress|egress|transit>} [path-
type <corouted | unidirectional>] [state <up|down>]
[source <IP address>] [destination <IP address>] [next-
hop <IP address>] [prev-hop <IP address>] [fwd-out-ip-
intf <signal-interface-object>] [rev-out-ip-intf
<Interface Supports Data>] [fwd-out-ip-intf <Interface
Supports Data>] [fwd-in-label <NUMBER: 16-1044479>] [fwd-
out-label <NUMBER: 16-1044479>] [rev-in-label <NUMBER:

16-1044479>] [rev-out-label <NUMBER: 16-1044479>]

[recovery <protected|unprotected>] [role
<primary|backup|locally-repaired|active-backup>]
where
matching-lsp is the tunnel to be displayed.
<matching-lsp>
dynamic
type <ingress | filters by tunnel type.
egress | transit>]
path-type filters by tunnel path type.
<corouted |
unidirectional>]
source <IP filters by source IP address.
address>
address>
address>
prev-hop- <IP filters by previous hop IP address.
address>
fwd-out-ip-intf filters by forward outgoing IP interface.
<Interface
Supports Data>]
rev-out-ip-intf filters by reverse outgoing IP interface.
<Interface
Supports Data>
fwd-in-label filters by forward in-bound label.
<NUMBER: 16-
1044479>
fwd-out-label filters by forward out-bound label.
<NUMBER: 16-
1044479>
rev-in-label filters by reverse in-bound label.
<NUMBER: 16-
1044479>]

where
rev-out-label filters by reverse out-bound label.
<NUMBER: 16-
1044479>
recovery filters by failure recovery type.
<protected |
unprotected>
role <primary | filters by protection role.
backup | locally-
repaired | active-
backup>
To display static ingress TP co-routed tunnels
3 Display static ingress TP co-routed tunnels:
gmpls tp-tunnel show static-ingress-corout <static-
ingress-corout>
To display static ingress TP uni-directional tunnels
4 Display static ingress TP uni-directional tunnels:
gmpls tp-tunnel show static-ingress-unidir <static-
ingress-unidir>
To display dynamic ingress TP uni-directional tunnels
5 Display show dynamic ingress TP uni-directional tunnels:
gmpls tp-tunnel show rsvp-ingress-unidir <rsvp-ingress-
unidir>
To display static egress TP co-routed tunnels
6 Display static egress TP co-routed tunnels:
gmpls tp-tunnel show static-egress-corout <static-egress-
corout>
To display static egress TP uni-directional tunnels
7 Display static egress TP uni-directional tunnels:
gmpls tp-tunnel show static-egress-unidir <static-egress-
unidir>
To display static transit TP co-routed tunnels
8 Display static transit TP co-routed tunnels:
gmpls tp-tunnel show static-transit-corout <static-
transit-corout>
To display static transit TP uni-directional tunnels
9 Display static transit TP uni-directional tunnels:
gmpls tp-tunnel show static-transit-unidir <static-
transit-unidir>

To display bi-directional associated TP tunnels

10 Display bi-directional associated TP tunnels:
gmpls tp-tunnel show matching-assoc <matching-assoc>
[state <up | down>] [destination <IP address>] [next-hop
<IP address>] [out-ip-intf <Interface Supports Signals>]
[out-label <NUMBER: 16-1044479>] [in-label <NUMBER: 16-
1044479>] [recovery <protected | unprotected>] [role
<primary | backup | locally-repaired | activebackup>]
To display bi-directional ingress TP tunnels
11 Display bi-directional ingress TP tunnels:
gmpls tp-tunnel show static-ingress-assoc <static-
ingress-assoc>
end
Example
GMPLS Static Uni-dir All TP-Tunnel Filtered Display
gmpls tp-tunnel show matching-lsp persist static path-type unidirectional

+-------+---------+--------+----GMPLS INGRESS TP-TUNNEL TABLE-+---------------+---------+--------+-----+-----+-------+
|Type |Direction|Tunnel | Tunnel Name |Destination IP |Forward |Reverse |Admin|Oper | Flags |
| | |Index | | |Out Label|In Label|State|State| |
+-------+---------+--------+----------------------------------+---------------+---------+--------+-----+-----+-+-+-+-+
|Static |Unidir |4 |st-ing-u-A |1.1.1.1 |1003 |- |ENA |ENA |P|L|A| |
|Static |Unidir |5 |st-ing-u-B |2.2.2.2 |1051 |- |ENA |ENA |P|L|A| |
+-------+---------+--------+----------------------------------+---------------+---------+--------+-----+-----+-+-+-+-+
+-------+---------+--------+-GMPLS STATIC EGRESS TP-TUNNEL TABLE--------------+--------+---------+-----+-----+-+-+-+

|Type |Direction|Tunnel | Tunnel Name |Source IP |F
orward |Reverse |Admin|Oper |Flags|
| | |Index | | |In Label|Out Label|State|State| |
+-------+---------+--------+----------------------------------+---------------+--------+---------+-----+-----+-+-+-+
|Static |Unidir |1 |st-egr-u-A |1.1.1.1 |1002 |- |ENA |ENA |-|-|-|
|Static |Unidir |2 |st-egr-u-B |2.2.2.2 |1050 |- |ENA |ENA |-|-|-|
+-------+---------+--------+----------------------------------+---------------+--------+---------+-----+-----+-+-+-+
No Transit TP-Tunnel entries found

Procedure 12-25
Configuring LDP
LDP is required for dynamic MPLS deployments for signaling virtual circuits.
Sessions are established using UDP port 646 to a peer IP address that can
be directly connected or several hops away.
By default, LDP is globally disabled. For dynamic deployments, it must be

globally enabled.
LDP supports authentication to prevent unwanted connections.
You can
enable LDP globally
modify global LDP attributes
display global status
add an IP entry and password
display IP entries with an encoded password
Step Action
1 Enable LDP globally:

ldp enable
2 Modify global LDP attributes (optional):
ldp set {[hello-hold-time <NUMBER: 1-65535>], [keep-
alive-hold-time <NUMBER: 1-65535>]}
3 Display global status (optional).
ldp show
4 Add an IP entry and password (optional):
ldp authentication set {peer <IPAddress>}
{authentication-type <md5>} {password
<PasswordString[31]>} {secret <SecretString[62]>}
5 Display IP entries with an encoded password (optional):
ldp authentication show
6 Display LDP configuration:
ldp show [adjacency] [sessions] [timers]
end

Example
The following example shows a global configuration with IP entry and
password.
ldp enable
ldp show
+------------------- LDP GLOBAL CONFIG ---------------+
+---------------------------+-------------------------+
| LDP Admin State | Enabled |
| LDP Oper State | Enabled |
+---------------------------+-------------------------+
ldp authentication set peer 1.2.3.4 password myPassword
ldp authentication show
+------------ LDP Authentication Configuration Summary -------------------+
| Router Id | Encoded Password |
+----------------+--------------------------------------------------------+
|1.2.3.4 |ffe5109e033a3716e94f |
+----------------+--------------------------------------------------------+

Procedure 12-26
Configuring dynamic virtual circuits
You can
create a dynamic virtual circuit
create a dynamic protection virtual circuit
Step Action
To create a dynamic virtual circuit

1 Create a dynamic virtual circuit:
mpls l2-vpn create dynamic-vc <dynamic-vc> {pw-id
<NUMBER: 1-2147483647>} {peer <IP Address>} {te-tunnel
<MPLS ingress primary tunnel>} {tp-tunnel-ingr-corout
<MPLS ingress primary tp corout tunnel>} {tp-tunnel-egrs-
corout-static <MPLS static egress primary tp-tunnel>}
{tp-tunnel-egrs-corout-dynamic <String>} {te-tunnel-
assoc <MPLS assoc te-tunnel>} {tp-tunnel-assoc <MPLS
assoc tp-tunnel>} [pw-type <eth-raw|eth-tagged|tdm>] [mtu
<1500-9128>] [status-tlv <on|off>] [service-delimiter-
vid <NUMBER: 1-4094>] [service-delimiter-tpid
<8100|9100|88A8>] [pw-mode <mesh | spoke>] [pw-cos-
profile <MPLS Pseudowire COS Profile>] [pw-vccv-profile
<MPLS Pseudowire VCCV Profile>]
where
dynamic-vc is the name of the dynamic virtual circuit.
<dynamic-vc>
pw-id <NUMBER: is the VPN identifier.
1-2147483647>
peer <IP is the destination IP address.
Address>
te-tunnel <MPLS is the ingress transport primary TE tunnel.
ingress primary
tunnel>
tp-tunnel-ingr- is the ingress transport co-routed primary TP tunnel.
corout <MPLS
ingress primary
tp corout tunnel>
tp-tunnel-egrs- is the static egress transport co-routed primary TP tunnel.
corout-static
<MPLS static
egress primary
tp-tunnel>

where
tp-tunnel-egrs- is the name of the dynamic egress transport co-routed
corout-dynamic primary TP tunnel.
<String>
te-tunnel-assoc is the ingress transport associated primary TE tunnel.
<MPLS assoc te-
tunnel>
tp-tunnel-assoc is the ingress transport associated primary TP tunnel.
<MPLS assoc tp-
tunnel>
pw-type <eth- is the pseudowire type.
raw|eth-tagged|
tdm>
mtu <NUMBER: is the MTU in bytes.
1500-9128>
status-tlv determines whether status TLV is on or off.
<on|off>
service-delimiter- is the service delimiter VID.
vid <NUMBER: 1-
4094>
service-delimiter- is the service delimiter VLAN TPID.
tpid <8100|9100|
88A8>
[pw-mode <mesh is the pseudowire mode.
| spoke>]
pw-cos-profile is the pseudowire COS profile name.
<MPLS
Pseudowire CoS
Profile>
[pw-vccv-profile is the pseudowire VCCV profile name.
<MPLS
Pseudowire
VCCV Profile>]
2 Enable the virtual circuit:
mpls l2-vpn enable vc <vc>
where
vc <vc> is the virtual circuit to enable.
To create a dynamic protection virtual circuit

3 Create a dynamic protection virtual circuit:
mpls l2-vpn protection create dynamic-vc <dynamic-vc>
{secondary-pw-id <NUMBER: 1-2147483647>} {primary-vc-
name <Virtual Circuit Dynamic MPLS Name>} {peer <IP
address>} {te-tunnel <MPLS ingress primary tunnel>|tp-

tunnel-ingr-corout <MPLS ingress primary tp corout

tunnel>|tp-tunnel-egrs-corout-static <MPLS static egress
primary tp-tunne>|tp-tunnel-egrs-corout-dynamic
<String>} {te-tunnel-assoc <MPLS assoc te-tunnel>|tp-
tunnel-assoc <MPLS assoc tp-tunnel>}
end

Procedure 12-27
Configuring static virtual circuits
Configure static virtual circuits.
Note: The status interval value should consider how many PWs are
expected to be configured. For a large number of PWs, the refresh interval
must be set to a higher value. This reduces the frequency of a large
number of PW status message exchanges.
Step Action
1 Create a static virtual circuit:

mpls l2-vpn create static-vc <static-vc> {secondary-pw-id
<NUMBER: 1-2147483647> peer <ip-addr-str>} {te-tunnel
<Ingress-Primary-TE-Tunnel-Object> | tp-tunnel-ingr-
corout <Ingress-Primary-Corouted-TP-Tunnel-Object> | tp-
tunnel-egrs-corout-static <Static-Egress-Primary-
Corouted-TP-Tunnel> | tp-tunnel-egrs-corout-dynamic
<NAME-STRING> | te-tunnel-assoc <Primary-Associated-TE-
Tunnel> | tp-tunnel-assoc <Primary-Associated-TP-
Tunnel>} {peer <IP address>} in-label <NUMBER:
16..1048575> out-label <NUMBER: 16..1048575> [tunnel
<lsp-name>] [pw-type <eth-raw | eth-tagged | tdm>] [tdm-
profile <xml-tdm-profile>][pw-cword <on|off>][status-tlv
<on|off>] [refresh-status-interval <0..65535>] [pw-mode
<mesh | spoke>] [mtu <NUMBER: 1500-9128>] [service-
delimiter-vid <NUMBER: 1-4094>] [service-delimiter-tpid
<8100 | 9100 | 88A8>] [pw-cos-profile <xml-mpls-pw-cos-
profile>] [pw-vccv-profile <MPLS Pseudowire VCCV
Profile>]
where
static-vc <static-vc> Static virtual circuit name
{pw-id <NUMBER: 1- Set VPN ID
2147483647>}
{peer <IP address>} Set Destination IP address
{te-tunnel <Ingress- Selects ingress transport primary TE-
Primary-TE-Tunnel-Object> Tunnel.
tp-tunnel-ingr-corout Selects ingress transport co-routed
<Ingress-Primary- primary TP-Tunnel.
Corouted-TP-Tunnel-
Object>

where
tp-tunnel-egrs-corout-static Selects static egress transport co-routed
<Static-Egress-Primary- primary TP-Tunnel.
Corouted-TP-Tunnel>
tp-tunnel-egrs-corout- selects dynamic egress transport co-
dynamic <NAME-STRING> routed primary TP-Tunnel name.
te-tunnel-assoc <Primary- selects ingress transport associated
Associated-TE-Tunnel> primary TE-Tunnel.
tp-tunnel-assoc <Primary- selects ingress transport associated
Associated-TP-Tunnel> primary TP-Tunnel.
{ingress-label <NUMBER: set MPLS decap label.
16-1048575>}
{egress-label <NUMBER: set MPLS encap label.
16-1048575>}
{tunnel <MPLS ingress transport tunnel
primary tunnel>}
[pw-type <eth-raw | eth- pseudowire type
tagged| tdm>]
[tdm-profile <xml-tdm- Sets TDM
profile>] FSD-0038-001 SAOS 6.x S/W MPLS
Control Plane CLI FS - Ciena Confidential
and Proprietary 71
profile to be used to setup a static TDM
pseudowire.
status-tlv <on | off> determines if status TLV is on or off.
status-interval <0..65535> refreshes the current status of the
pseudowire to ensure that each end has
the others correct pseudowire status. 0
indicates no status refresh. The default is
600 seconds.
[pw-mode <mesh | spoke>] pseudowire mode
[mtu <NUMBER: 1500- sets MTU (bytes).
9128>]
[service-delimiter-vid service delimiter VID.
<NUMBER: 1-4094>]
[service-delimiter-tpid service delimiter VLAN TPID.
<8100 | 9100 | 88A8>]
[pw-cos-profile <MPLS is the pseudowire VCCV profile name.
Pseudowire CoS Profile>
[pw-vccv-profile <MPLS is the pseudowire VCCV profile name.
Pseudowire VCCV Profile>]

2 Enable the virtual circuit:

mpls l2-vpn enable [vc <vc-name>]
where
vc <vc-name> is the virtual circuit to enable.
3 Create a static protection virtual circuit:

mpls l2-vpn protection create static-vc <static-vc>
{secondary pw-id <NUMBER: 1-2147483647>} {primary-vc-name
<Virtual Circuit Static MPLS Name>} {peer <IP address>}
{in-label <NUMBER: 16-1044479>} {out-label <NUMBER: 16-
1044479>} {te-tunnel <MPLS ingress primary tunnel>|tp-
tunnel-ingr-corout <MPLS ingress primary tp corout
tunnel>|tp-tunnel-egrs-corout-static <MPLS static egress
primary tp-tunnel>|tp-tunnel-egrs-corout-dynamic
<String>|te-tunnel-assoc <MPLS assoc te-tunnel>|tp-
tunnel-assoc <MPLS assoc tp-tunnel>}[refresh-status-
interval <NUMBER: 0-65535>]
where
static-vc <static-vc> static virtual circuit name.
{secondarypw-id sets the VPN ID.
<NUMBER: 1-
2147483647>}
{peer <IP address>} sets the Destination IP address.
{in-label <NUMBER: 16- sets MPLS decapsulationlabel.
1044479>}
{out-label <NUMBER: 16- sets MPLS encapsulation label.
1044479>]
{te-tunnel <MPLS ingress selects the ingress transport primary TE-
primary tunnel>} Tunnel.
{tp-tunnel-ingr-corout <PLS selects th eingress transport co-routed
ingress primary tp corout primary TP-Tunnel.
tunnel>}
{tp-tunnel-egrs-corout-static selects the static egress transport co-
<MPLS static egress routed primary TP-Tunnel.
primary tp-tunnel>}
{tp-tunnel-egrs-corout- the dynamic egress transport co-routed
dynamic <String>} TP-Tunnel name.
{te-tunnel-assoc <MPLS selects the ingress transport associated
assoc te-tunnel>} primary TE-Tunnel.
tp-tunnel-assoc <MPLS selects the ingress transport associated
assoc tp-tunnel>} primary TP-Tunnel.
refresh-status-interval sets the refresh timer interval.
<Number: 0-65535>

end

Procedure 12-28
Displaying virtual circuits
You can display:
all virtual circuits
virtual circuits by attribute
detailed output of a selected virtual circuit
pseudowires by customer name
virtual circuit next hops
virtual circuit information based on tunnel group
Step Action
To display all virtual circuits

1 Display all Ethernet virtual circuits:
mpls l2-vpn show
To display virtual circuits by attribute
2 Display Ethernet virtual circuits by attribute:
mpls l2-vpn show matching-vc <matching-vc> {persist
<static|dynamic>} [state <up | down>] {pw-id <NUMBER>}
[source <IP address>] [destination <IP address>] [next-
hop <IP address>] [in-label <NUMBER: 16-1044479>] [out-
label <NUMBER: 16-1044479>] [recovery
<protected|unprotected>] [role
<primary|backup|standalone>] [te-tunnel <MPLS ingress
primary tunnel>] [tp-tunnel-ingr-corout <MPLS ingress
primary tp corout tunnel>] [tp-tunnel-egrs-corout-static
<MPLS static egress primary tp-tunnel>] [tp-tunnel-egrs-
corout-dynamic <String>] [te-tunnel-assoc <MPLS assoc te-
tunnel>] [tp-tunnel-assoc <MPLS assoc tp-tunnel>] [pw-
type <eth-raw | eth-tagged | tdm>] [pw-mode <mesh| spoke>]
[service-delimiter-vid <NUMBER: 1-4094>] [service-
delimiter-tpid <8100|9100|88A8>] [status-tlv <on| off>]
[pw-cos-profile <MPLS Pseudowire COS Profile>] [tdm-
profile <TDM Profile Name>]
where
matching-vc displays all matching VCs.
<matching-vc>
dynamic>

where
pw-id filters by VPN identifier.
<NUMBER>
source <IP filters by source IP address of the virtual circuit.
address>
destination <IP filters by destination IP address of the virtual circuit.
address>
next-hop <IP filters by next hop IP address of the virtual circuit.
address>
in-label filters by inbound label value of the virtual circuit.
<NUMBER>
out-label filters by outbound label value of the virtual circuit.
<NUMBER>
recovery filters by recovery type of the virtual circuit.
<protected |
unprotected>
role <primary | filters by current role of the virtual circuit.
backup |
standalone>]
te-tunnel <MPLS displays ingress transport primary TE-Tunnels.
ingress primary
tunnel>
tp-tunnel-ingr- displays ingress transport co-routed primary TP-Tunnels.
corout <MPLS
ingress primary
tp corout tunnel>
tp-tunnel-egrs- displays static egress transport corouted primary TP-
corout-static Tunnels.
<MPLS static
egress primary
tp-tunnel>
tp-tunnel-egrs- displays dynamic egress transport co-routed primary TP-
corout-dynamic Tunnels.
<String>]
[te-tunnel-assoc displays ingress transport associated primary TE-Tunnels.
<MPLS assoc te-
tunne>
tp-tunnel-assoc displays ingress transport associated primary TP-Tunnels.
<MPLS assoc tp-
tunnel>
pw-type <eth-raw filters by pseudowire type.
| eth-tagged |
tdm>

where
pw-mode <mesh| filters by pseudowire mode.
spoke>
service-delimiter- filters by service delimiter VLAN ID.
vid <NUMBER: 1-
4094>
service-delimiter- filters by service delimiter VLAN TPID.
tpid <8100 | 9100
| 88A8>
status-tlv <on | filters by status TLV settings.
off>
pw-cos-profile filters by pseudowire COS profile.
<MPLS
Pseudowire COS
Profile>
tdm-profile <TDM filters by TDM profile name.
Profile Name>
To display detailed output of a selected virtual circuit
3 Display detailed output of a selected virtual circuit:
mpls l2-vpn show vc <vc>
To display pseudowires by customer name
4 Display pseudowires by customer name:
mpls l2-vpn show customer <customer>
To display virtual circuit next hops
5 Display virtual circuit next hops:
mpls l2-vpn show vc-nexthops <vc-nexthops>
To display virtual circuit information based on tunnel group
6 Display virtual circuit information based on tunnel group:
mpls l2-vpn show vc-vifs <vc-vifs>
end

Procedure 12-29
Configuring virtual circuit connectivity verification
profiles
You can select the CC type value of 3 (TTL-exhaust) and/or 4 (GAL/GACH or
out-of-band-OAM channel). Both, one or none can be selected.
If a VCCV profile is not associated with a PW, a default VCCV profile with CC-
type 3 and CC-type 4 enabled, is associated.
Validity checks are performed at the time of a VCCV profile association with a
static PW. The association is rejected if
No CC-type is enabled
More than one CC-type is enabled
Conflicting CC-type is enabled. For example, PW status signaling is
enabled, but the VCCV profile has CC-type 3 enabled.
Step Action
To create a VCCV profile

1 Create a VCCV profile:
mpls l2-vpn pw-vccv-profile create vccv-profile <vccv-
profile> {logical-id <NUMBER>} [cc-ttl-exp <on|off>] [cc-
ciena-oob <on|off>]
where
vccv-profile is the Pseudowire VCCV profile name.
<vccv-profile>
(logical-id is the profile index
<NUMBER>
[cc-ttl-exp sets the TTL-expiry VCCV control channel (CC Type-3)
<on|off>] operation.
[cc-ciena-oob sets the Ciena proprietary out-of-band VCCV control
<on|off>] channel (CC Type 4 operation.
end

Procedure 12-30
Displaying a VCCV profile
You can display a VCCV profile.
Step Action
1 Display a VCCV profile:

mpls l2-vpn pw-vccv-profile show
end
Example
The following example shows the output for the mpls l2-vpn pw-vccv-profile
show command:
mpls l2-vpn pw-vccv-profile show
+----------------------------------------------------------------+
+---- L2-VPN Pseudowire-VCCV-Profile Table ----+
+--------------------------------+------+-------+---------+------+
| VCCV Profile Name |Index |CC |CC | USE |
| | |TTL Exp|CIENA OOB| COUNT|
+--------------------------------+------+-------+---------+------+
|DefaultPwVccvProfile |1 |Yes |Yes |0 |
|Profile-CC-3 |2 |Yes |No |0 |
|Profile-CC-4 |3 |No |Yes |1 |
|Profile-CC-3-4 |4 |Yes |Yes |0 |
|Profile-CC-none |5 |No |No |0 |
+--------------------------------+------+-------+---------+------+

Procedure 12-31
Deleting a VCCV profile
You can delete a VCCV profile.
Step Action
1 Display a VCCV profile:

mpls l2-vpn pw-vccv-profile <vccv-profile> delete
where
vccv-profile is the Pseudowire VCCV profile name you wish to delete.
<vccv-profile>
end

Procedure 12-32
Allocating resources for an MPLS management virtual
switch (3916, 3930 and 3931 platforms)
On the 3916, 3930 and 3931 platforms, support for an MPLS management
virtual switch requires adjustment of the default resource allocation:
If an attempt is made to use the interface remote set vs <vs-name>
command before these resources have been allocated on the 3916/30/31
platforms, an error message is displayed and the command is refused.
If an attempt is made to remove or reduce the resources allocated to the
transport-oam feature set while the remote interface is associated with a
virtual switch, the command is refused.
Step Action
1 Allocate resources to the transport-oam feature set:

resource-manager pool set feature transport-oam resource
classifier count 256
resource-manager pool set feature transport-oam resource
counter count 256
2 Deallocate resources from another feature (do one of the following two
options):
Reduce resources from the traffic-profiling feature:
resource-manager pool set feature traffic-profiling
resource classifier count 768
resource-manager pool set feature traffic-profiling
resource counter count 768
Eliminate resources from either the broadcast-containment or vc-
statistics feature:
resource-manager pool set feature <feature-name> resource
classifier count 0
resource-manager pool set feature <feature-name> resource
counter count 0
where
feature <feature-name> either broadcast-containment or vc-statistics
3 Save the configuration and reboot:

config save
reboot now
end

Procedure 12-33
Creating an MPLS management virtual switch
Create an MPLS management virtual switch by creating an MPLS virtual
switch and associating it with the remote interface.
Note 1: In order to carry remote interface traffic over an MPLS tunnel, the
remote-interface is associated with a virtual switch. Management access
to the switch can then be gained from any of the members of this virtual
switch, including attachment circuit members. Thus, if ACs exist on the
virtual switch that is associated with the Remote Interface, customers
could obtain management access to the node.
In order to prevent this, create an MPLS virtual switch specifically for use
for in-band management, and DO NOT attach customer ACs to that virtual
switch.
Note 2: For 3916, 3930 and 3931 platforms ensure that resource
allocations have been adjusted. See Allocating resources for an MPLS
management virtual switch (3916, 3930 and 3931 platforms) on page
12-104.
Note 3: Associating an MPLS virtual switch with the remote interface
does not change the basic properties of that virtual switch. Support for
features such as Traffic Profiling, L2-CFT, COS Mapping is unchanged.
Step Action
1 Create the virtual switch.

virtual-switch ethernet create vs <vs_name> mode vpls
where
vs <vs-name> is the name of the MPLS virtual switch
2 Attach the virtual switch to the MPLS virtual circuit:

virtual-switch ethernet attach vs <vs_name> mpls_vc
<vc_name>
where
vc <vc-name> is the name of the MPLS virtual circuit
3 Optionally, on 39XX/51XX platforms, add the virtual switch to port and vlan:
virtual-switch ethernet add vs <vs_name> port <n> vlan <n>
where

4 Associate the virtual switch with the remote interface:

interface remote set vs <vs_name>
where
end
If the CLI session in use is connected to the remote interface, the user loses
access by means of that current session as the remote interface is
reconfigured. The user must initiate a new session over the newly-configured
virtual switch.
At the node where VLAN-based management transitions to inband MPLS-

based management, the VLAN-based management traffic must be added to
the MPLS virtual switch as an EVPL attachment circuit, where the VLAN used
is the management VLAN.

Procedure 12-34
Displaying remote interface configuration
Display the remote interface configuration to identify the Management Domain
used for connectivity, which is either a VLAN or a virtual switch.
Step Action
1 Display information about the remote interface:

end
Example
In the example output below, the remote interface connectivity is provided
by an MPLS management virtual switch named MyMngmt1
+----------------------------------- INTERFACE STATE ------------------------------+
| Parameter | Value | Source | State |
+------------------------+----------------------------------+----------+-----------+
| Name | remote | | |
| Index | 15 | | |
| Admin State | Enabled | | |
| Oper State | Enabled | | |
| MAC Address | 00:02:5a:01:c5:4f | | |
| Management Domain | VS MyMngmt1 | | |
| Priority | 7 | | |
| MTU | 1500 | | |
+------------------------+----------------------------------+----------+-----------+
| IPv4 Oper addr/mask | 192.168.50.1/24 | Manual | PREFERRED |
| IPv4 Broadcast Address | 192.168.50.255 | Manual | PREFERRED |
+------------------------+----------------------------------+----------+-----------+
| IPv6 Oper addr/mask | fe80::202:5aff:fe01:c54f/64 | Internal | PREFERRED |
+------------------------+----------------------------------+----------+-----------+

Procedure 12-35
Changing the management virtual switch
You can create several MPLS or PBB-TE native mode virtual switches,
although only one virtual switch can be associated with the remote interface
at any point in time.
PBB-TE supports creation of a management virtual circuit to provide remote

management over PBB-TE tunnels. Remote interface management access
over PBB-TE is mutually exclusive with remote interface management access
over MPLS. You cannot configure a PBB-TE management virtual circuit if an
MPLS virtual switch is currently set on the remote interface, and vice-versa.
You can:
change the remote management interface to PBB-TE from an MPLS
virtual switch
change the remote management interface to PBB-TE from a PBB-TE
virtual switch
replace the management virtual switch with a management VLAN
replace the management VLAN with a management virtual switch
Step Action
To change the remote management interface to PBB-TE from an MPLS virtual switch
1 Move the remote management interface to a VLAN:
interface remote set vlan <VLAN>
2 Create the management PBB-TE virtual circuit as described in Configuring
PBB-TE on page 11-16.
To change the remote management interface to PBB-TE from a PBB-TE virtual switch
3 Delete the PBB-TE management virtual circuit used for remote
management:
virtual-circuit pbt delete static-vc
where
vc <vc-name> is the name of the PBB-TE virtual circuit
4 Create a new MPLS or PBB-TE virtual switch.

5 Associate the new MPLS or PBB-TE virtual switch with the remote interface:
interface remote set vs <Virtual Switch Name>
Remote interface connectivity is moved to the new virtual switch, and it
becomes the management virtual switch.

To replace the management virtual switch with a management VLAN

6 Replace the management virtual switch with a management VLAN:
interface remote set vlan <VLAN>
The old management virtual switch continues to exist and its membership is
not changed, but it no longer provides connectivity to the remote interface.
To replace the management VLAN with a management virtual switch
7 Replace the management virtual switch with a management VLAN:
interface remote set vs <Virtual Switch Name>
The old management virtual switch continues to exist and its membership is
not changed, but it no longer provides connectivity to the remote interface.
end

Procedure 12-36
Running ping for RSVP-TE tunnels
Run ping to test RSVP-TE tunnels.
Step Action
1 Ping an RSVP-TE tunnel:

mpls encap-tunnel ping rsvp-lsp
<TunnelDynamicEncapName[31]> [count <NUMBER: 1-100>]
[packet-size <NUMBER: 96-1464>] [timeout <NUMBER: 1000-
10000>] [ttl <NUMBER: 1-255>]
end
Example
The following example shows sample output for a ping operation.
> mpls encap-tunnel ping rsvp-lsp DynamicLSPA count 100

packet-size 1464
!!!!!!!!!
--------------- Statistics ---------------
100 packets transmitted, 9 packets received
round-trip (ms) min/avg/max = 10/20/89

Procedure 12-37
Running traceroute for RSVP-TE tunnels
Run traceroute to test RSVP-TE tunnels.
Step Action
1 Run a traceroute:
mpls encap-tunnel traceroute rsvp-lsp
<MplsDynamicEncapTunnel> [timeout <NUMBER: 1000-10000>]
[ttl <NUMBER: 1-30>]
end
Example
The following example shows sample output for a traceroute operation.
> mpls encap-tunnel encap traceroute rsvp-lsp DynamicLSPA
0 10.10.50.2 MRU 1500 Label: 28871
! 1 10.10.20.20 5 ms

Procedure 12-38
Running ping for MPLS tunnels
Run ping to test MPLS tunnels. You can ping:
ingress MPLS-TE unidirectional tunnels

ingress MPLS-TP bi-directional tunnels
ingress MPLS-TP unidirectional tunnels
egress MPLS-TP bi-directional tunnels
MPLS-TE bi-directional associated tunnels
MPLS-TP bi-directional associated tunnels
Table 12-18 lists attributes for mpls ping commands.
Table 12-18
Attributes for mpls ping commands
count <NUMBER: 1- is the number of packets to send. The default value is 5.

100>]
packet-size <NUMBER: is the packet size.

96-1464>] Default values are:
for a dynamic-tunnel: 96
for a static-tunnel: 118
timeout <NUMBER: 500- is the timeout in milliseconds. The default value is 1000.
10000>
ttl <NUMBER: 1-255> is the time-to-live. The default value is 255.
reply-mode <IPv4 | LSP> is the reply mode. The default value is LSP.
encap <IP/UDP | Non-IP/ is the type of encapsulation. The default value is IP/UDP.
UDP>
Step Action
To ping an ingress MPLS-TE tunnel

1 Ping an ingress MPLS-TE tunnel:
mpls ping tunnel <tunnel> [count <NUMBER: 1-100>]
10000>] [ttl <NUMBER: 1-255>]

To ping an ingress MPLS-TP bi-directional tunnel

2 Ping an ingress MPLS-TP bi-directional tunnel:
mpls ping tp-tunnel-ingress-corout <tp-tunnel-ingress-
corout> [count <NUMBER: 1-100>] [packet-size <NUMBER: 96-
1464>] [timeout <NUMBER: 500-10000>] [ttl <NUMBER: 1-
255>] [reply-mode <IPv4|LSP>] [encap <IP/UDP|Non-IP/UDP>]
To ping an ingress MPLS-TP unidirectional tunnel
3 Ping an ingress MPLS-TP unidirectional tunnel:
mpls ping tp-tunnel-ingress-unidir <tp-tunnel-ingress-
unidir> [count <NUMBER: 1-100>] [packet-size <NUMBER: 96-
255>]
To ping an egress MPLS-TP bi-directional tunnel
4 Ping an egress MPLS-TP bi-directional tunnel:
mpls ping tp-tunnel-egress-corout <tp-tunnel-egress-
corout> [count <NUMBER: 1-100>] [packet-size <NUMBER: 96-
255>] [reply-mode <IPv4|LSP>] [encap <IP/UDP|Non-IP/UDP>]
To ping an MPLS-TE bi-directional associated tunnel
5 Ping an MPLS-TE bi-directional associated tunnel:
mpls ping assoc-lsp <assoc-lsp> [count <NUMBER: 1-100>]
10000>] [ttl <NUMBER: 1-255>] [reply-mode <IPv4|LSP>]
To ping an MPLS-TP bi-directional associated tunnel
6 Ping an MPLS-TP bi-directional associated tunnel:
mpls ping assoc-tp-lsp <assoc-tp-lsp> [count <NUMBER: 1-
100>] [packet-size <NUMBER: 96-1464>] [timeout <NUMBER:
500-10000>] [ttl <NUMBER: 1-255>] [reply-mode <IPv4|LSP>]
Note: FEC validation is supported for ping and traceroute over static mpls-tp
tunnels. FEC parameters, src-tunnel-id, lsp-id and dest-tunnel-d can be
configured when a static mpls-tp tunnelis created. See Configuring static TE
tunnels on page 12-67. With the exception of dest-tunnel-id, these
parameters are validated by the receiving node of a ping packet. Dest-tunnel-
id is not validated in order that ping can be backward compatible with the
previous release.
end

Procedure 12-39
Running ping for virtual circuits
Run ping to test virtual circuits.
Step Action
1 Ping an MPLS virtual circuit:

mpls ping vc <vc> [count <NUMBER: 1-100>] [packet-size
<NUMBER: 114-1464>] [timeout <NUMBER: 500-10000>] [fec-
128-len <14|16>] [reply-mode <IPv4|LSP>]
where
vc <vc> is the MPLS pseudowire name.
count is the number of packets to send. The default value is 5.
<NUMBER: 1-
100>
packet-size Is the packet size in bytes. The default value is 114.
<NUMBER: 114-
1464>
timeout is the timeout value in milliseconds. The default value is
<NUMBER: 500- 1000.
10000>
fec-128-len <14| is the number of bytes to use for FEC 128 length. The default
16> value is 14.
reply-mode <IPv4 is the reply mode.
|LSP> For TE tunnels, no-op.
For TP tunnels, the default value is LSP.
Note: The reply-mode setting and vc cc-type setting must agree for vc
ping to proceed. The vc cc-type is specified in the pw-vccv-profile and
associated to a vc when the vc is created. If the negotiated cc-type is cc-
ttl-exp, the reply-mode must be set to ipv4; if the reply-mode is cc-ciena-
oob, the reply mode must be lsp. Also, cc-type must also be the same
between the 2 vc peers. If they are not configured with the same cc-type,
vc ping will not proceed.
end

Procedure 12-40
Running a traceroute
Run traceroute to test MPLS tunnels.
You can run a traceroute on:

ingress MPLS-TE tunnels
ingress MPLS-TP bidirectional tunnels
ingress MPLS-TP unidirectional tunnels
egress MPLS-TP bidirectional tunnels
MPLS-TE bi-directional associated tunnels
MPLS-TP bi-directional associated tunnels
Table 12-19 lists attributes for mpls traceroute commands.
Table 12-19
Attributes for mpls traceroute commands
Attribute Description Default value
timeout <NUMBER: 500- is the timeout value. 1000

10000>] Valid values are in the
range of 500 to 10000
milliseconds.
ttl <NUMBER: 1-30> is the time to live. 30

Valid values are numbers
in the range of 1 to 30.
encap <IP/UDP| is the encapsulation type. IP/UDP

Non-IP/UDP>
Step Action
To run a traceroute on an ingress MPLS-TE tunnel

1 Run a traceroute on an ingress MPLS-TE tunnel:
mpls traceroute tunnel <tunnel> [timeout <NUMBER: 500-
10000>] [ttl <NUMBER: 1-30>]

To run a traceroute on an ingress MPLS-TP bidirectional tunnel

2 Run a traceroute on an ingress MPLS-TP bidirectional tunnel:
mpls traceroute tp-tunnel-ingress-corout <tp-tunnel-
ingress-corout> [timeout <NUMBER: 500-10000>] [ttl
<NUMBER: 1-30>] encap <IP/UDP|Non-IP/UDP>]
To run a traceroute on an ingress MPLS-TP unidirectional tunnel
3 Run a traceroute on an ingress MPLS-TP unidirectional tunnel:
mpls traceroute tp-tunnel-ingress-unidir <tp-tunnel-
ingress-unidir> [timeout <NUMBER: 500-10000>] [ttl
<NUMBER: 1-30>]
To run a traceroute on an egress MPLS-TP bidirectional tunnel
4 Run a traceroute on an egress MPLS-TP bidirectional tunnel:
mpls traceroute tp-tunnel-egress-corout <tp-tunnel-
egress-corout> [timeout <NUMBER: 500-10000>] [ttl
<NUMBER: 1-30>] [encap <IP/UDP|Non-IP/UDP>]
To run a traceroute on an MPLS-TE bi-directional associated tunnel
5 Run a traceroute on an MPLS-TE bi-directional associated tunnel:
mpls traceroute assoc-lsp <assoc-lsp> [timeout <NUMBER:
500-10000>] [ttl <NUMBER: 1-30>]
To run a traceroute on an MPLS-TP bi-directional associated tunnel
6 Run a traceroute on an MPLS-TP bi-directional associated tunnel:
mpls traceroute assoc-tp-lsp <assoc-tp-lsp> [timeout
<NUMBER: 500-10000>] [ttl <NUMBER: 1-30>]
end

Procedure 12-41
Configuring a 39XX/51XX LSR
Configure a 39XX/51XX LSR to establish a dynamic base MPLS configuration
on a 39XX/51XX switch. The base configuration allows the switch to function
as an LSR and builds the foundation for LER functionality. This procedure sets
up the L3 interfaces, IGP, and signaling protocols used by MPLS.
Figure 12-14 shows the sample physical topology.
Figure 12-14
Sample physical topology
P1/1 R2 P2/1 P9 R5
5410 3960
lb: 2.2.2.2 v201 lb: 5.5.5.5
if1
v101
2.0
v102
5.0
02
1.1
mgt: 10.26.54.90 mgt: 10.26.62.119
1.4
:10
.10
.20
.10
:10
:10
2.2
01
P2.1 P2.2
01
4.0
P1/1
if1
if2
R1 R4
5410 5150
lb: 1.1.1.1 lb: 4.4.4.4
mgt: 10.26.54.80 mgt: 10.26.62.13
P3.1
if2
P3.2
4.0
if1
02
P2/1
04
3.3
:10
:10
.10
.20
R3 R6
.10
:10
1.4
v202
1.1
v104
03
6.0
3960 v103 3960
4.0
if1
lb: 3.3.3.3 lb: 6.6.6.6

mgt: 10.26.62.120 P10 P9 mgt: 10.26.62.118
P9
Step Action
1 Create a VLAN for each L3 interface / physical port pair.

vlan create vlan <vlan_#>
2 Add the L3 Interface VLAN to the associated physical port.
vlan add vlan <vlan_#> port <port_#>
3 If the switch is part of a ring topology, remove VLAN 1,127 from each of the
physical ports.
vlan remove vlan 1,127 port <port_#>
4 Disable RSTP.
rstp disable

5 Create the L3 and loopback interfaces.

interface create loopback <name> ip <ip>
interface create ip-interface <name> ip <ip> subnet
<subnet> vlan <vlan> ip-forwarding <on|off>
6 Create an IGP instance.
isis instance create isis-instance <instance_name> level
L1 area <area_#>
7 Attach each L3 interface to the IGP instance.
isis interface attach ip-interface <name> isis-instance
<name> level L1
8 Enable RSVP globally and on each of the interfaces previously created.
rsvp-te enable
rsvp-te enable ip-interface <name>
9 Enable LDP globally.
ldp enable
end
Example
The following sample configuration file segment shows the base LSR
configuration for the 3960 named R3 in the network topology diagram
shown in Figure 12-14 on page 12-117.
!-----------------------------------------------------
! General Device Config
!-----------------------------------------------------
system set host-name R3
! VLANs 1,127 have been removed from all ports in the base configuration. This
eliminates the possibility of L2 loops which allows RSTP to be disabled
globally.
rstp disable
interface create loopback lb ip 3.3.3.3
isis instance create isis-instance region1 level L1 area 46.0001
!-----------------------------------------------------
! Interface if104
!-----------------------------------------------------
!A different VLAN is used for each L3 Interface / physical port combination
to prevent a flood domain from forming.
vlan remove vlan 1,127 port 9
!The L3 interface named if104 is associated with VLAN 104 to coincide with
port 9 above. IP Forwarding is also enabled to allow routing between L3
interfaces.
interface create ip-interface if104 ip 10.104.13.3 subnet 255.255.255.0 vlan
104 ip-forwarding on
!Each L3 interface is attached to the IGP instance to signal that it should

be included in routing updates and to enable IGP signaling for that link.

isis interface attach ip-interface if104 isis-instance region1 level L1
!RSVP provides the signaling and label exchange mechanism that will be used
to generate the LSP. It must be enabled both globally and on each interface.
rsvp-te enable ip-interface loopback
rsvp-te enable
rsvp-te enable ip-interface if104
!LDP provides the signaling and label exchange mechanism that will be used to
generate the Pseudowire. LDP is enabled globally.
ldp enable
!-----------------------------------------------------
! Interface if103
!-----------------------------------------------------
vlan remove vlan 1,127 port 10
interface create ip-interface if103 ip 10.103.34.3 subnet 255.255.255.0 vlan

103 ip-forwarding on
isis interface attach ip-interface if103 isis-instance region1 level L1
rsvp-te enable ip-interface if103

Procedure 12-42
Configuring a 39XX/51XX VPWS
VPWS provides point-to-point connectivity between two remote Local Area
Networks (LANs). In this example protection switching is performed through
tunnel redundancy.
Note: This procedure assumes that the device has already been
configured with base LSR functionality as illustrated in Configuring a
39XX/51XX LSR on page 12-117.
Figure 12-15 shows the VPWS topology.
Figure 12-15
VPWS Topology
R2
Primary Path 5150
lb: 2.2.2.2
mgt: 0.26.107.242
R1 R4
3930 3960
lb: 1.1.1.1 lb: 4.4.4.4
mgt:10.26.107.241 mgt:10.26.107.244
R3
5150 Backup Path
lb: 3.3.3.3
mgt:10.26.107.243
Step Action

1 Create a virtual switch.

virtual-switch ethernet create vs <vs> mode <vpws|vpls>
where
mode is the capability of the virtual-switch.
<vpws|vpls>
2 Attach the UNI port(s) to the virtual switch.

virtual-switch ethernet add vs <vs> port <Port list> [vlan
<VLAN list>] [service-vlan-tpid <8100 | 9100 | 88A8>]
where
port <Port list> is the subscriber port list.
vlan <VLAN list> is the subscriber VLAN ID.
service-vlan-tpid is the service VLAN TPID value.
<8100 | 9100 |
88A8>
3 Create a primary and backup path.

rsvp-te path create rsvp-path <rsvp-path>
where
rsvp-path is the RSVP path to create.
<rsvp-path>
rsvp-te path set rsvp-path <rsvp-path> index

<NUMBER: 1-16> ip <IP address> hop-type <strict|loose>
where
rsvp-path is the RSVP path to create.
<rsvp-path>
index is the position of the node in the rsvp path list.
<NUMBER:
1-16>
ip <IP address> is the IP address.
hop-type is the hop type.
<strict|loose>

4 Create a primary and backup tunnel and apply the previously created path.
<IP address> explicit-tunnel-path <MPLS Rsvp Path>
[backup-tunnel <MPLS ingress primary tunnel>]
where
rsvp-ingress is the RSVP tunnel name.
<rsvp-ingress>
dest-ip <IP is the tunnel destination IP address.
address>
path <MPLS is the RSVP path name.
Rsvp Path>
[backup-tunnel is the list of primary tunnels.
<MPLS ingress
primary tunnel>]
5 Create a virtual circuit.

mpls l2-vpn create dynamic-vc <dynamic-vc> pw-id <NUMBER:
1-2147483647> peer <IP address> tunnel <MPLS ingress
primary tunnel> pw-type <eth-raw|eth-tagged> pw-mode
<mesh|spoke>
where
dynamic-vc is the dynamic virtual switch name.
<dynamic-vc>
pw-id <NUMBER: is the VPN ID.
1-2147483647>
address>
tunnel <MPLS is the transport tunnel.
ingress primary
tunnel>
pw-type <eth- is the pseudowire type.
raw|eth-tagged>
pw-mode is the pseudowire mode.
<mesh|spoke>
6 Attach the virtual circuit to the virtual switch.

virtual-switch ethernet attach mpls-vc <mpls-vc> vs <vs>
where
mpls-vc is the list of MPLS VCs.
<mpls-vc>
end

Example
The following sample configuration file segment shows the VPWS
configuration for the 3930 named R1 in the network topology diagram
shown in Figure 12-15 on page 12-120.
!--------------------------------- vpws-r1.r4-----------------------------!
! ----The primary path is created towards R2. This is also known as an Explicit
Route Object and is used to override the behavior of the IGP.
rsvp-te path create rsvp-path vpws-r1.r4.pri
rsvp-te path set rsvp-path vpws-r1.r4.pri index 5 ip 10.101.12.2 hop-type
loose
! ----Backup Path
rsvp-te path create rsvp-path vpws-r1.r4.bak
rsvp-te path set rsvp-path vpws-r1.r4.bak index 5 ip 10.104.13.3 hop-type
loose
! ----The primary tunnel is created as a dynamic RSVP tunnel. The destination

IP address is targeted at the loopback interface to ensure it is always up.
mpls tunnel create rsvp-ingress tun-vpws-r1.r4.pri dest-ip 4.4.4.4 explicit-
tunnel-path vpws-r1.r4.pri record-route on
! ----The backup tunnel is associated with the primary tunnel and is only
forwarding if the primary tunnel fails.
mpls tunnel create rsvp-ingress tun-vpws-r1.r4.bak dest-ip 4.4.4.4 explicit-
tunnel-path vpws-r1.r4.bak backup tun-vpws-r1.r4.pri
! ---- Virtual Circuit, Virtual Switch, and Attachment Circuit

mpls l2-vpn create dynamic-vc vpws-r1.r4 pw-id 100 peer 4.4.4.4 tunnel tun-
vpws-r1.r4.pri pw-mode mesh pw-type eth-raw
! ---- The Virtual Switch is configured in VPWS mode to prevent more than 1
attachment circuit from being added. This adheres to the strict definition of
VPWS only having a single attachment circuit.
virtual-switch ethernet create vs vpws-r1.r4 mode vpws
virtual-switch ethernet attach mpls-vc vpws-r1.r4 vs vpws-r1.r4
virtual-switch ethernet add vs vpws-r1.r4 port 10 vlan 100

Procedure 12-43
Configuring a 39XX/51XX VPLS
VPLS provides point-to-multipoint inter-LAN connectivity. With VPLS, PEs are
connected to each other with a full mesh of virtual circuits for each VPLS
instance. Each PE connects to an MTU-s on the UNI side through an MPLS
network, or it connects to a CE device through an untagged interface or
802.1Q interface.
Note: In Release 6.9, the system handles the outer VLAN which could be
C-VLAN, S-VLAN or B-VLAN and not the combination of multiple VLANs
as in Q-in-Q or MAC-in-MAC. This is true for a UNI port on a PE also.
Each mesh virtual circuit connects to a remote PE that is a member of the

same VPLS instance which provides emulated LAN service for the broadcast
domain of the virtual switch. When configuring the mesh virtual circuit, include
the virtual circuit identifier. For VPLS configuration, all the mesh virtual circuits
that are associated with the same virtual switch may or may not have the same
value.
Note 1: In order to be interoperable with other vendors, configure the

same virtual circuit identifier for the mesh virtual circuits that are added to
the same virtual circuit.
Note 2: This procedure assumes that the device has already been

Figure 12-16 on page 12-125 shows the VPLS topology.
Figure 12-16
VPLS topology
R2 R5
5150 5150
lb: 2.2.2.2 lb: 5.5.5.5
Full Mesh
R6
R3
5150 3960
lb: 6.6.6.6
lb: 3.3.3.3

Step Action

virtual-switch ethernet create vs <vs-name> mode
<vpws|vpls>
2 Add the UNI port(s) to the virtual switch.
virtual-switch ethernet add vs <vs-name> port <name>
[vlan <vlan-id>] [service-vlan-tpid <tpid>]
3 Create an explicit path for each PE in the VPLS mesh.
rsvp-te path set rsvp-path <name> index <#> ip <ip> hop-
type <loose|strict>
4 Create an MPLS tunnel for each PE in the MPLS mesh.
mpls tunnel create rsvp-ingress <name> dest-ip <ip>
explicit-tunnel-path <name> record-route <on|off>
5 Create a virtual circuit (Pseudowire) for each PE in the MPLS mesh.
mpls l2-vpn create dynamic-vc <name> pw-id <#> peer <ip>
tunnel <name> pw-mode <spoke|mesh> pw-type <eth-raw|eth-
tagged>
6 Attach each virtual circuit created in Step 5 to the virtual switch created in
Step 1.
virtual-switch ethernet attach mpls-vc <name> vs <name>
end

Example
The following sample configuration file segment shows the VPLS
configuration for the 5150 named R3 shown in Figure 12-15 on page
12-120.
!----------------------vpls-100
virtual-switch ethernet create vs vpls-100 mode vpls
virtual-switch ethernet add vs vpls-100 port 8 vlan 100
!----------------------------Peer: 2.2.2.2
! ----The path is associated with the tunnel. The purpose of the path is to allow
configuration or strict routing for the LSP.
rsvp-te path create rsvp-path R3_R2.path
rsvp-te path set rsvp-path R3_R2.path index 5 ip 10.103.34.4 hop-type loose
! ----Record route information is used to calculate Fast Re-route paths and

therefore should always be enabled if FRR protection is desired.
mpls tunnel create rsvp-ingress R3_R2 dest-ip 2.2.2.2 explicit-tunnel-path
R3_R2.path record-route on
! ---- The pw-mode MESH is what allows the ELAN behavior associated with a
VPLS. The pw-type ETH-RAW along with the attachment circuit type defines
the treatment of the outer VLAN of the ingress frame.
mpls l2-vpn create dynamic-vc vpls-100.R2 pw-id 100 peer 2.2.2.2 tunnel R3_R2
pw-mode mesh pw-type eth-raw
virtual-switch ethernet attach mpls-vc vpls-100.R2 vs vpls-100
!---------------------------Peer: 5.5.5.5
! ----Path to peer
! ----MPLS Tunnel
! ---- Virtual Circuit

!---------------------------Peer: 6.6.6.6
! ----Path to peer
! ----MPLS Tunnel
! ---- Virtual Circuit


Procedure 12-44
Configuring a 39XX/51XX H-VPLS
A Hierarchical VPLS (H-VPLS) model is used to allow spoke connections to
the VPLS core. A device provides the functionality to interface with the VPLS
core by functioning as an MTU-s, which is connected as a spoke in the VPLS
core using a virtual circuit.
An MTU-s connects to an PE on the NNI side through an MPLS network and

to a CE on the UNI side through an untagged interface or an 802.1Q interface.
Note: The system handles the outer VLAN which could be C-VLAN, S-
VLAN or B-VLAN and not the combination of multiple VLANs as in Q-in-Q
or MAC-in-MAC. This is true for a UNI port on a PE also.
Although MTU-s is an external device to a PE, it is viewed as an adjunct

device to the PE and used to address scalability.
Note: This procedure assumes that the device has already been

Figure 12-17 illustrates the H-VPLS topology which includes virtual circuit
redundancy for protection switching.
Figure 12-17
H-VPLS topology
R2
Primary Path 5150 R5
lb: 2.2.2.2 5150
lb: 5.5.5.5
VPLS Config From
Previous VPLS
Example
R1
3930
lb: 1.1.1.1
Backup Path R3 R6
5150 3960
lb: 3.3.3.3 lb: 6.6.6.6

Step Action

virtual-switch ethernet create vs <vs-name> mode
<vpws|vpls>
2 Attach the UNI port(s) to the virtual switch.
virtual-switch ethernet add vs <vs-name> port <name>
[vlan <vlan-id] [service-vlan-tpid <tpid>]
3 Create an explicit path for each endpoint.
rsvp-te path set rsvp-path <name> index <#> ip <ip> hop-
type <loose|strict>
4 Create an MPLS tunnel for each endpoint.
mpls tunnel create rsvp-ingress <name> dest-ip <ip>
explicit-tunnel-path <name> record-route <on|off>
5 Create a primary and protection virtual circuit (Pseudowire).
mpls l2-vpn create dynamic-vc <vc-name> pw-id <value>
peer <peer-ip-addr> tunnel <tunnel-name>
6 Attach the each virtual circuit to the virtual switch created in Step 1.
virtual-switch ethernet attach vs <vs-name> mpls-vc <vc-
name>
end

Example
The following sample configuration file segment shows the H-VPLS
configuration for the 3930 named R1 shown in Figure 12-17 on page
12-129.
H-VPLS Configuration Example on R1

!----------------hvpls-200
!----Since VPLS is a multipoint service the virtual switch mode should be set
to VPLS which will allow multiple attachment circuits. VPWS mode only allows
a single attachment circuit.
virtual-switch ethernet create vs hvpls-200 mode vpls
virtual-switch ethernet add vs hvpls-200 port 8 vlan 200
!----------------Primary Virtual Circuit: hvpls-200P

! ---- Primary Path
!-----Primary Tunnel

mpls l2-vpn create dynamic-vc hvpls-200P pw-id 200 peer 2.2.2.2 tunnel R1_R2
pw-mode spoke pw-type eth-raw
virtual-switch ethernet attach mpls-vc hvpls-200P vs hvpls-200
! ---- Backup Path

!-------Backup Tunnel

mpls l2-vpn protection create dynamic-vc hvpls-200B primary-vc-name hvpls-
200P secondary-pw-id 200 peer 3.3.3.3 tunnel R1_R3
virtual-switch ethernet attach mpls-vc hvpls-200B vs hvpls-200

Procedure 12-45
H-VPLS configuration example mixed platform
This example provides a mix of 39XX/51XX and 5410 devices with a VPLS
core and spoke virtual circuits as shown in Figure 12-18.
Figure 12-18
H-VPLS topology mixed platform
4/4
IXIA
4/3
1 1.8
3 1.7
3930 5150
9 1.1
9 1 4
6 2
3931 3916
5
1 5
8 3960 7
11
6/4
5410
6/3
1/2
IXIA

H-VPLS Configuration Example on 5410

configuration for the 5410 in Figure 12-18 on page 12-132.
rstp disable
mstp disable
aggregation disable
system shell set global-inactivity-timer off
port disable port 6/1-6/4

port enable port 6/4
port enable port 6/3
virtual-switch create vs test-vs
cpu-interface sub-interface create cpu-subinterface rg

cpu-interface sub-interface show
sub-port create sub-port sp6/4_1 parent-port 6/4 classifier-precedence 1

egress-l2-transform push-8100.305.1
sub-port add sub-port sp6/4_1 class-element 1 vtag-stack 305
sub-port create sub-port sp6/3_1 parent-port 6/3 classifier-precedence 1
egress-l2-transform push-8100.10.1
sub-port add sub-port sp6/3_1 class-element 1 vtag-stack 10
virtual-switch interface attach sub-port sp6/4_1 vs test-vs

virtual-switch interface attach cpu-subinterface rg vs test-vs
interface create loopback test-loop ip 3.100.1.1

interface create ip-interface test-ip ip 4.100.160.
100 subnet 255.255.255.0 vs test-vs
rsvp-te enable ip-interface test-loop

rsvp-te enable ip-interface test-ip
rsvp-te enable
ospf instance create ospf-instance ospfInst1

ospf instance enable ospf-instance ospfInst1
ospf instance set ospf-instance ospfInst1 router-id 3.100.1.1
ospf interface attach ip-interface test-ip ospf-instance ospfInst1
ospf interface enable ip-interface test-ip
ospf interface attach ip-interface test-loop ospf-instance ospfInst1
ospf interface enable ip-interface test-loop
mpls tunnel create rsvp-ingress dyn-100_160 dest-ip 3.160.1.1

mpls l2-vpn create dynamic-vc dynvc-100_160 peer 3.160.1.1 tunnel dyn-100_160
pw-id 109
ldp enable
virtual-switch create vs vpls

virtual-switch interface attach sub-port sp6/3_1 vs vpls
virtual-switch interface attach mpls-vc dynvc-100_160 vs vpls


rstp disable
mstp disable
aggregation disable
port disable port 1-6

port enable port 4
port enable port 2
port enable port 5
port enable port 6


interface create loopback loopback-B ip 3.116.1.1

interface create ip-interface intf-116_150 ip 4.116.150.116/24 vlan 302 ip-
forwarding on
forwarding on
forwarding on
ospf instance create ospf-instance OSPF-Inst-B

ospf instance set ospf-instance OSPF-Inst-B router-id 3.116.1.1
ospf instance enable ospf-instance OSPF-Inst-B
ospf interface attach ip-interface loopback-B ospf-instance OSPF-Inst-B

ospf interface enable ip-interface loopback-B
ospf interface attach ip-interface intf-116_150 ospf-instance OSPF-Inst-B
ospf interface enable ip-interface intf-116_150
rsvp-te set ip-interface loopback-B advertised-label non-reserved

rsvp-te set ip-interface intf-116_150 advertised-label implicit-null
rsvp-te set ip-interface intf-116_131 advertised-label non-reserved
rsvp-te enable ip-interface loopback-B
rsvp-te enable ip-interface intf-116_150
rsvp-te enable
mpls tunnel create rsvp-ingress rsvp-itnl-116_131 dest-ip 3.131.1.1


mpls tunnel create static-ingress stat-itnl-116_150 dest-ip 3.150.1.1 next-

hop-ip 4.116.150.150 label
105
mpls tunnel create static-egress stat-etnl-116_150
label 106
ldp enable
mpls l2-vpn create dynamic-vc dyn-116_131 pw-id 105 peer 3.131.1.1 tunnel
rsvp-itnl-116_131 pw-mode mesh
stat-itnl-116_150 pw-mode spoke
virtual-switch ethernet create vs vs-A mode vpls

virtual-switch ethernet attach mpls-vc dyn-116_131 vs vs-A

rstp disable
mstp disable
aggregation disable
port enable port 1

port enable port 9

vlan create vlan 10

interface create loopback loopback-A ip 3.130.1.1

forwarding on
ospf instance create ospf-instance OSPF-Inst-A

ospf instance set ospf-instance OSPF-Inst-A router-id 3.130.1.1
ospf instance enable ospf-instance OSPF-Inst-A
ospf interface attach ip-interface loopback-A ospf-instance OSPF-Inst-A
ospf interface enable ip-interface loopback-A
ospf interface attach ip-interface intf-130_131 ospf-instance OSPF-Inst-A
rsvp-te set ip-interface loopback-A advertised-label non-reserved

rsvp-te enable ip-interface loopback-A
rsvp-te enable

ldp enable
rsvp-itnl-130_131 pw-mode spoke
virtual-switch ethernet create vs vs-A mode vpws

virtual-switch ethernet add vs vs-A port 1 vlan 10

rstp disable
mstp disable
aggregation disable

port enable port 9
port enable port 5
port enable port 1
port enable port 6
port set port 5 mirror-port on


interface create loopback loopback-C ip 3.131.1.1

interface create ip-interface intf-131_130 ip 4.130131.131/24 vlan 300 ip-
forwarding on
forwarding on
forwarding on
ospf instance create ospf-instance OSPF-Inst-C

ospf instance set ospf-instance OSPF-Inst-C router-id 3.131.1.1
ospf instance enable ospf-instance OSPF-Inst-C
ospf interface attach ip-interface loopback-C ospf-instance OSPF-Inst-C
ospf interface enable ip-interface loopback-C
ospf interface attach ip-interface intf-131_130 ospf-instance OSPF-Inst-C
rsvp-te set ip-interface loopback-C advertised-label non-reserved



rsvp-te enable ip-interface loopback-C
rsvp-te enable

ldp enable
rsvp-itnl-131_130 pw-mode spoke


rstp disable
mstp disable
aggregation disable

port enable port 8
port enable port 7
port enable port 11


interface create loopback loopback-E ip 3.160.1.1

forwarding on
forwarding on
forwarding on
ospf instance create ospf-instance OSPF-Inst-E

ospf instance set ospf-instance OSPF-Inst-E router-id 3.160.1.1

ospf instance enable ospf-instance OSPF-Inst-E
ospf interface attach ip-interface loopback-E ospf-instance OSPF-Inst-E
ospf interface enable ip-interface loopback-E
ospf interface attach ip-interface intf-160_131 ospf-instance OSPF-Inst-E
rsvp-te set ip-interface loopback-E advertised-label non-reserved

rsvp-te enable ip-interface loopback-E
rsvp-te enable

ldp enable
mpls l2-vpn create dynamic-vc dyn-160_131 pw-id 106

peer 3.131.1.1 tunnel rsvp-itnl-160_131 pw-mode mesh
peer 3.116.1.1 tunnel rsvp-itnl-160_116 pw-mode mesh
peer 3.100.1.1 tunnel rsvp-itnl-160_100 pw-mode spoke


rstp disable
mstp disable
aggregation disable
port disable port 1.1-1.48

port enable port 1.8
port enable port 1.1

vlan create vlan 10

interface create loopback loopback-D ip 3.150.1.1

forwarding on
ospf instance create ospf-instance OSPF-Inst-D

ospf instance set ospf-instance OSPF-Inst-D router-id 3.150.1.1
ospf instance enable ospf-instance OSPF-Inst-D
ospf interface attach ip-interface loopback-D ospf-instance OSPF-Inst-D
ospf interface enable ip-interface loopback-D
ospf interface attach ip-interface intf-150_116 ospf-instance OSPF-Inst-D
rsvp-te set ip-interface loopback-D advertised-label non-reserved

rsvp-te enable ip-interface loopback-D
rsvp-te enable
mpls tunnel create static-ingress stat-itnl-150_116 dest-ip 3.116.1.1 next-

hop-ip 4.116.150.116 label 106
mpls tunnel create static-egress stat-etnl-150_116 label 105
ldp enable
stat-itnl-150_116 pw-mode spoke
virtual-switch ethernet create vs vs-A mode vpws

virtual-switch ethernet add vs vs-A port 1.8 vlan 10

Procedure 12-46
VPLS with CFM configuration example 3916 and 3960
This example shows a VPLS between two 3916 switches and a 3960 as
shown in Figure 12-19 with dynamic virtual circuits. The CFM service is
configured over the data virtual switch and virtual circuit endpoints have down
MEPs.
Figure 12-19
VPLS with CFM topology
1 2 2 3
3916-60 3916-80
6 3960-14 4
VPLS Configuration Example on 3916-80

This example shows the VPLS configuration of3916-80 shown in Figure
12-19.
system set host-name CN3916-80

rstp disable
mstp disable
aggregation disable
port disable port 1,5,6

port enable port 2,3,4


interface create loopback LBK ip 2.2.2.2

interface create ip-interface IFACE-4.1.1.2 ip 4.1.1.2/24 vlan 301 ip-
forwarding on


forwarding on
ospf instance create ospf-instance OSPF-INST

ospf instance set ospf-instance OSPF-INST router-id 2.2.2.2
ospf instance enable ospf-instance OSPF-INST
ospf interface attach ip-interface LBK ospf-instance OSPF-INST

ospf interface enable ip-interface LBK
ospf interface attach ip-interface IFACE-4.1.1.2 ospf-instance OSPF-INST
ospf interface enable ip-interface IFACE-4.1.1.2
rsvp-te enable
rsvp-te set ip-interface LBK advertised-label non-reserved
rsvp-te set ip-interface IFACE-4.1.1.2 advertised-label non-reserved
rsvp-te enable ip-interface LBK
rsvp-te enable ip-interface IFACE-4.1.1.2

mpls tunnel create rsvp-ingress rsvp-itnl-4.1.1 dest-ip 1.1.1.1
ldp enable
mpls l2-vpn create dynamic-vc dyn-4.1.1 pw-id 105 peer 1.1.1.1 tunnel rsvp-
itnl-4.1.1 pw-mode mesh

virtual-switch ethernet attach mpls-vc dyn-4.1.1 vs vs-A

This example shows the VPLS configuration of 3916-60 shown in Figure
12-19 on page 12-140.

rstp disable
mstp disable
aggregation disable
port disable port 3,4,5

port enable port 1,2,6




forwarding on
forwarding on



rsvp-te enable

ldp enable


12-19 on page 12-140.

rstp disable
mstp disable
aggregation disable
port disable port 1,2,3,5,7,8,9,10,11,12

port enable port 4,6




forwarding on
forwarding on


rsvp-te enable

ldp enable


Procedure 12-47
G.8032 and VPLS interoperability example
This example shows VPLS interoperability with G.8032 as shown in Figure
12-20.
Figure 12-20
G.8032 and VPLS topology
3916-80 5410 VPLS 3916-100
G.8032
3960-10 3916-60
For the scenario where all of the following are true:
virtual circuit is tagged

attachment circuit on the right hand is port classification only (no
service delimited tag)
The tagged traffic is actually coming in over the attachment circuit,
traffic that egresses the ring ports on the interconnect device are
double-tagged.
The inner tag is the subscriber tag and the outer tag is the service delimiter
VID pushed on by the virtual circuit. This is considered a mis-configuration
and an acceptable result.
When only the second is true, VLAN 801 and VLAN 802 traffic will actually go
out over the east and west (sub) ports that are in VS2, even though there is a
VR on that device that is actually blocking one of those ports. That's
considered an accept able result and is also considered a misconfiguration.

G.8032 and VPLS Configuration Example on 5410

This example shows the VPLS configuration of the 5410 shown in Figure
12-20 on page 12-144.
virtual-switch create vs test-vs-prim

virtual-switch create vs vpls
virtual-switch create vs raps_vs
virtual-switch create vs raps-vs-900
interface create loopback test-loop ip 10.10.10.10

interface create ip-interface test-ip-prim ip 1.1.1.1 subnet 255.255.255.0 vs
test-vs-prim
cpu-interface sub-interface create cpu-subinterface test-cpu-prim
sub-port create sub-port sp6.3 parent-port 6/3 classifier-precedence 1 egress-

l2-transform push-8100.301.1
sub-port add sub-port sp6.3 class-element 1 vtag-stack 301
sub-port create sub-port sp6.6-800 parent-port 6/6 classifier-precedence 100
sub-port add sub-port sp6.6-800 class-element 1 vtag-stack 801
rsvp-te enable ip-interface test-loop

rsvp-te enable ip-interface test-ip-prim
rsvp-te path create rsvp-path path-prim logical-id 1
rsvp-te path set rsvp-path path-prim index 1 ip 1.1.1.2
rsvp-te enable
mpls tunnel create rsvp-ingress itnl-prim path path-prim dest-ip 30.30.30.30

logical-id 1
ldp enable
mpls l2-vpn create dynamic-vc test-dynVc pw-id 201

peer 30.30.30.30 tunnel itnl-prim pw-type eth-tagged
ospf instance create ospf-instance ospfInst1

ospf interface attach ip-interface test-loop ospf-instance ospfInst1
ospf interface enable ip-interface test-loop
ospf interface attach ip-interface test-ip-prim ospf-instance ospfInst1
ospf interface enable ip-interface test-ip-prim
virtual-switch interface attach sub-port sp6.3 vs test-vs-prim

virtual-switch interface attach cpu-subinterface test-cpu-prim vs test-vs-
prim
virtual-switch interface attach sub-port sp6.6-800 vs raps_vs
virtual-switch interface attach sub-port sp6.4-800 vs raps_vs

virtual-switch interface attach mpls-vc test-dynVc vs raps_vs
rstp disable
aggregation disable
ring-protection logical-ring create logical-ring-name LR1 ring-id 1 west-port

6/6 east-port 6/4 WTR 1
ring-protection virtual-ring create virtual-ring-name VR1 logical-ring LR1
raps-vid 800
ring-protection virtual-ring set ring VR1 east-port-rpl owner
ring-protection virtual-ring add ring VR1 vs raps_vs
raps-vid 900
ring-protection virtual-ring add ring VR2 vs raps-vs-900
dhcp client enable
system shell set global-more off

12-20 on page 12-144.

interface create ip-interface LSR-IFACE-1 ip 1.1.1.2/24 vlan 301 ip-forwarding
on
virtual-switch ethernet create vs vs1 mode vpls

ospf instance create ospf-instance OSPF-Inst

ospf instance disable ospf-instance OSPF-Inst
ospf instance set ospf-instance OSPF-Inst router-id 30.30.30.30
ospf instance enable ospf-instance OSPF-Inst
ospf interface attach ip-interface LBK ospf-instance OSPF-Inst
ospf interface set ip-interface LBK priority 1
ospf interface attach ip-interface LSR-IFACE-1 ospf-instance OSPF-Inst
ospf interface set ip-interface LSR-IFACE-1 priority 1
ospf interface enable ip-interface LSR-IFACE-1

rsvp-te enable ip-interface LSR-IFACE-1
rsvp-te path create rsvp-path path1 logical-id 1
rsvp-te path set rsvp-path path1 index 1 ip 1.1.1.1
rsvp-te enable
mpls tunnel create rsvp-ingress RSVP-ITNL-2 explicit-tunnel-path path1 dest-

ip 10.10.10.10 logical-id 1

ldp enable
mpls l2-vpn create dynamic-vc PWDYN-1 pw-id 201 peer 10.10.10.10 tunnel RSVP-
ITNL-2 pw-type eth-tagged
virtual-switch ethernet attach mpls-vc PWDYN-1 vs vs1
rstp disable
mstp disable
aggregation disable
system shell set global-more off


12-20 on page 12-144.
vlan create vlan 801-802,901-902
port disable port 2

port disable port 5
port disable port 6
vlan add vlan 801-802,901-902 port 1

vlan add vlan 801-802 port 3
virtual-switch ethernet create vs vsA mode vpws

virtual-switch ethernet create vs vsB mode vpls
virtual-switch ethernet create vs vsC

4 east-port 1 WTR 1
raps-vid 800
ring-protection virtual-ring add ring VR1 vid 801-802
raps-vid 900

12-20 on page 12-144.

port disable port 3

port disable port 4
port disable port 5


2 east-port 6 WTR 1
raps-vid 800
raps-vid 900

12-20 on page 12-144.


4 east-port 1 WTR 1
raps-vid 800
raps-vid 900
end

Procedure 12-48
MPLS-TP configuration example
This example shows a general MPLS-TP configuration between DUTA, which
has a loopback address of 1.1.1.1, and DUTB, which has a loopback address
of 2.2.2.2.
All IP interfaces are enabled for RSVP-TE and RSVP-TE and LDP are globally
enabled.
Note 1: The 5410 does not support GMPLS configuration.

Note 2: This procedure assumes that the device has already been
DUTA configuration
This example shows the configuration on DUTA.
gmpls tp-tunnel create rsvp-ingress-unidir DUTA-DUTB-1 dest-ip 2.2.2.2

gmpls tp-tunnel create static-ingress-assoc DUTA-DUTB-ASSOC-1 forward-tunnel
DUTA-DUTB-1 reverse-dyntun-name DUTB-DUTA-1
mpls l2-vpn create dynamic-vc DUTA-DUTB-VC-1 peer 2.2.2.2 pw-id 12 tp-tunnel-

assoc DUTA-DUTB-ASSOC-1
mpls l2-vpn create dynamic-vc DUTA-DUTB-VC-2 peer 2.2.2.2 pw-id 1212 tp-
tunnel-assoc DUTA-DUTB-ASSOC-1
virtual-switch Ethernet create vs VPLS1 mode vpls

virtual-switch Ethernet create vs VPWS1 mode vpws
virtual-switch Ethernet attach mpls-vc DUTA-DUTB-VC-1 vs VPLS1

virtual-switch Ethernet attach mpls-vc DUTA-DUTB-VC-2 vs VPWS1
virtual-switch Ethernet add vs VPLS1 port 1 vlan 1001

virtual-switch Ethernet add vs VPWS1 port 1 vlan 1002
DUTB configuration
This example shows the configuration on DUTB.
gmpls tp-tunnel create rsvp-ingress-unidir DUTB-DUTA-1 dest-ip 1.1.1.1

gmpls tp-tunnel create static-ingress-assoc DUTB-DUTA-ASSOC-1 forward-tunnel
DUTB-DUTA-1 reverse-dyntun-name DUTA-DUTB-1
mpls l2-vpn create dynamic-vc DUTB-DUTA-VC-1 peer 1.1.1.1 pw-id 12 tp-tunnel-

assoc DUTB-DUTA-ASSOC-1
mpls l2-vpn create dynamic-vc DUTB-DUTA-VC-2 peer 1.1.1.1 pw-id 1212 tp-
tunnel-assoc DUTB-DUTA-ASSOC-1
virtual-switch Ethernet create vs VPLS1 mode vpls

virtual-switch Ethernet create vs VPWS1 mode vpws

virtual-switch Ethernet attach mpls-vc DUTB-DUTA-VC-1 vs VPLS1

virtual-switch Ethernet attach mpls-vc DUTB-DUTA-VC-1 vs VPWS1
virtual-switch Ethernet add vs VPLS1 port 1 vlan 1001

virtual-switch Ethernet add vs VPWS1 port 1 vlan 1002

13-1
L2 control frame tunneling configuration 13-
This chapter explains how to configure the treatment of Layer 2 (L2) control
frames with L2 control frame tunneling. With L2 control frame tunneling, you
can change the handling of untagged L2 control frames to be processed and
forwarded as if they were data frames instead of being discarded or locally
processed. Also, you can change the handling of transparent L2 control
frames to be transformed to L2PT frame format.
Note: To configure L2 control frame tunneling, you need to install the

Advanced Ethernet license key. To obtain the Advanced Ethernet license
key, contact Ciena Sales.
Overview
In conformance with IEEE standards, the default configuration does not
propagate untagged L2 control frames through the network. If the default
disposition is discard, the frames are dropped without further processing. If
the disposition is peer, the frames are forwarded to the software process that
handles the specific protocol. Table 13-1 shows the frame format for the three
forms for each protocol along with the default disposition for each.
Table 13-1
Control frame formats and disposition
Control frame Form Default DA MAC Type/Length LLC or Subtype

name (with CLI disposition address encapsulation EtherType
attribute)
Rapid Spanning Untagged Peer 01-80-C2- N/A DSAP/ N/A

Tree Protocol (rstp) 00-00-00 SSAP=0x4
2 Ctrl=0x03
Tagged Same as 01-80-C2- N/A DSAP/ N/A

data frame 00-00-00 SSAP=0x4
2 Ctrl=0x03
L2PT Same as 01-00-0C- N/A DSAP/ N/A

data frame CD-CD-D0 SSAP=0x4
2 Ctrl=0x03

13-2 L2 control frame tunneling configuration
Table 13-1

attribute)
Link Aggregation Untagged Peer 01-80-C2- N/A 88-09 01

Control Protocol 00-00-02
(lacp)
Tagged Same as 01-80-C2- N/A 88-09 01
data frame 00-00-02
L2PT Same as 01-00-0C- N/A 88-09 01

data frame CD-CD-D0
LACP Marker (lacp- Untagged Peer 01-80-C2- N/A 88-09 02

marker) 00-00-02

data frame 00-00-02
L2PT Same as 01-00-0C- N/A 88-09 02

data frame CD-CD-D0
802.3ah Operation, Untagged Discard 01-80-C2- N/A 88-09 03

Administration, and 00-00-02
Maintenance (oam)
data frame 00-00-02
L2PT Same as 01-00-0C- N/A 88-09 03

data frame CD-CD-D0
IEEE Std. 802.1X/ Untagged Discard 01-80-C2- N/A 88-8E N/A

EAPOL(802.1x) 00-00-03
Tagged Same as 01-80-C2- N/A 88-8E N/A

data frame 00-00-03
L2PT Same as 01-00-0C- N/A 88-8E N/A

data frame CD-CD-D0
LLDP 802.1ab(lldp) Untagged Peer 01-80-C2- N/A 88-CC N/A

00-00-0E
Tagged Same as 01-80-C2- N/A 88-CC N/A

data frame 00-00-0E
L2PT Same as 01-00-0C- N/A 88-CC N/A

data frame CD-CD-D0

Table 13-1

attribute)
Generic Attribute Untagged Discard 01-80-C2- N/A N/A N/A

Registration 00-00-2X
Protocol (GARP)
Block (garp-block) Tagged Same as 01-80-C2- N/A N/A N/A
data frame 00-00-2X
L2PT Not Not N/A N/A N/A

supported Supported
GARP Mulicast Untagged Discard 01-80-C2- N/A 00-01 N/A

Registration 00-00-20
Protocol (gmrp)
Tagged Same as 01-80-C2- N/A 00-01 N/A
data frame 00-00-20

supported Supported
GARP VLAN Untagged Discard 01-80-C2- N/A 00-01 N/A

Registration 00-00-21
Protocol (gvrp)
Tagged Same as 01-80-C2- N/A 00-01 N/A
data frame 00-00-21

supported Supported
Cisco-Port Untagged Discard 01-00-0C- SNAP 01-04 N/A

Aggregation CC-CC-CC
Protocol (cisco-
pagp) Tagged Same as 01-00-0C- SNAP 01-04 N/A
data frame CC-CC-CC
L2PT Same as 01-00-0C- SNAP 01-04 N/A

data frame CD-CD-D0
Cisco-Unidirectional Untagged Discard 01-00-0C- SNAP 01-11 N/A

Link Detection CC-CC-CC
(cisco-udld)
Tagged Same as 01-00-0C- SNAP 01-11 N/A
data frame CC-CC-CC

data frame CD-CD-D0

Table 13-1

attribute)
Cisco Discovery Untagged Discard 01-00-0C- SNAP 20-00 N/A

Protocol (cisco-cdp) CC-CC-CC

data frame CC-CC-CC

data frame CD-CD-D0
Cisco-Dynamic Untagged Discard 01-00-0C- SNAP 20-04 N/A

Trunking Protocol CC-CC-CC
(cisco-dtp)
data frame CC-CC-CC

data frame CD-CD-D0
Cisco-VLAN Untagged Discard 01-00-0C- SNAP 20-03 N/A

Trunking Protocol CC-CC-CC
(cisco-vtp)
data frame CC-CC-CC

data frame CD-CD-D0
Cisco-Per VLAN Untagged Discard 01-00-0C- SNAP 01-0B N/A

Spanning Tree CC-CC-CD
(cisco-pvst)
Tagged Same as 01-00-0C- SNAP 01-0B N/A
data frame CC-CC-CD
L2PT Same as 01-00-0C- SNAP 01-0B N/A

data frame CD-CD-D0
Cisco-VLAN Bridge Untagged Discard 01-00-0C- SNAP 01-0C N/A

(vlan-bridge) CD-CD-CE
Tagged Same as 01-00-0C- SNAP 01-0C N/A

data frame CD-CD-CE
L2PT Same as 01-00-0C- SNAP 01-0C N/A

data frame CD-CD-D0

Table 13-1

attribute)
Cisco STP Fast Untagged Discard 01-00-0C- SNAP 20-0A N/A

Uplink (cisco-stp- CD-CD-CD
uplink-fast)
Tagged Same as 01-00-0C- SNAP 20-0A N/A
data frame CD-CD-CD
L2PT Same as 01-00-0C- SNAP 20-0A N/A

data frame CD-CD-D0
Bridge Block Untagged Discard 01-80-C2- N/A N/A N/A

(bridge-block) 00-00-0X
Tagged Same as 01-80-C2- N/A N/A N/A

data frame 00-00-0X

supported Supported
All Bridges Block Untagged Discard 01-80-C2- N/A N/A N/A

(all-bridges-block) 00-00-1X
Tagged Same as 01-80-C2- N/A N/A N/A

data frame 00-00-1X

supported Supported
Tunnel method
The tunnel method controls the classification and processing of untagged L2
control frames. You can set the tunnel method for a virtual switch to one of two
modes, transparent or L2PT. The default mode is L2PT.
Note: The maximum number of L2 control frame tunnels in a device is

equal to the number of physical ports available, that is, UNI plus NNI.
Transparent Mode
When the tunnel method is in transparent mode, the switching chip hardware
handles dispositions without sending frames to the CPU for processing, and
is referred to as "fast path" operation. With "fast path" operation, untagged L2
control frame dispositions are maintained when the control frame ingresses a
customer-facing interface with the untagged-ctrl-vs specified. Protocol
dispositions are not maintained when the equivalent tagged L2 control frame

ingresses a network-facing interface(s). In transparent mode, the L2 control

frame is encapsulated accordingly, and the IEEE or Cisco MAC DA is left
intact.
Transparent mode is only supported on MPLS EPL virtual switches. MPLS

virtual switches do not support the L2PT mode.
L2PT Mode
When the virtual switch is configured for L2PT mode, L2 control frames are
classified and either dropped or forwarded, according to each protocol's
disposition and the untagged-ctrl-vs designation at each customer-facing
interface. In L2PT mode the L2 control frame is fully decoded based on the
proper IEEE or Cisco MAC DA and any relevant Op-Codes in the frame. If
there is a specific protocol match on a protocol that supports L2PT stamping,
the frame is eligible for conversion to and from L2PT and proper IEEE or Cisco
MAC DA. Certain protocols do not support L2PT transformation, since their
classification data does not contain enough information to uniquely identify
the protocol once the protocol-specific MAC DA has been replaced. Such
protocols do not have an L2PT form.
In general, when the virtual switch is in L2PT mode, the switching chip
hardware sends L2 control frames to the CPU for "slow-path" processing. The
frame agent will egress that frame out the customer-facing interfaces as a
"proper" IEEE or Cisco L2 control frame, and egress the frame out network-
facing interfaces as the same L2PT frame.
L2 control frames that ingress a network-facing interface are processed as

follows:
If the L2 control frame is in the L2PT-equivalent form and is fully
decodable, it is converted back to the proper IEEE or Cisco MAC DA.
Egressing Customer-Facing Interface(s): The proper IEEE or Cisco
MAC DA form of the frame will egress out all customer-facing
interfaces of the virtual switch.
Egressing Network-Facing Interface(s): The L2PT form of the frame
will egress out all network-facing interfaces, except for the interface on
which the frame ingressed.
If the L2 control frame has an L2PT MAC DA, but is not decodable, that
frame will be switched out all customer-facing and network-facing
interfaces with no conversion of MAC DA.
If the L2 control frame is already in the proper IEEE or Cisco MAC DA
form, that frame will be switched out all customer-facing and network-
facing interfaces with no conversion of MAC DA to L2PT. This means that

if an IEEE L2 control frame enters a network-facing interface, that same

frame will egress interfaces regardless of the L2PT mode enabled on the
virtual switch.
L2 control frames that ingress a customer-facing Interface are processed as

follows:
If the L2 control frame is in the L2PT-equivalent form, it will be treated as
a data frame and switched out all customer-facing and network-facing
interfaces with no conversion of MAC DA.
If the L2 control frame is in the proper IEEE or Cisco MAC DA untagged
form, that frame will subject to the disposition set for the protocol at the
virtual switch L2 control frame tunneling instance. This untagged L2
control frame has classified to the customer facing port based upon the
untagged-ctrl-vs attribute of that port.
Egressing Customer-Facing Interface(s): The proper IEEE or Cisco
MAC DA form of the frame will egress out all customer-facing
interfaces of the virtual switch. From customer-to-customer, the L2PT
form will not propagate.
Egressing Network-Facing Interface(s): The L2PT form of the frame
will egress out all network-facing interfaces, except for the interface on
which the frame ingressed.
If the L2 control frame has an IEEE or Cisco MAC DA, but is not
decodable, that frame will be switched out all customer-facing and
network-facing interfaces with no conversion of MAC DA.
Configuration
L2 control frame tunneling directs untagged L2 control frames into a
forwarding domain of a virtual switch. Every virtual switch is associated with
an L2 control frame tunneling configuration container. The container storing
the configuration information is called an L2 control frame tunneling instance,
which includes:
Administrative Status - whether or not L2 control frame tunneling is
enabled or disabled for the virtual switch.
Fixed .1D priority - sets the .1D priority value applied to untagged L2
control frames to provide the baseline for Class of Service (CoS)
treatment of the frame as it switches through the device. The priority value
ranges from 0-7, where 7 has the highest priority and 0 has the lowest
priority.
Protocol Disposition List - sets a user-defined list of protocols to be
processed by L2 control frame tunneling along with a disposition action of
forward or discard.

For the related procedure, see Configuring L2 control frame tunneling on

page 13-19.

Procedure 13-1
Adding and removing untagged L2 control frame
classification
In order for untagged L2 control frames to be directed from a port to a
forwarding domain, you need to add the untagged L2 control frame traffic
classification (untagged-ctrl-vs) to the port and the port must have some
membership in the designated virtual switch (virtual-switch ethernet
add vs <VirtualSwitchName> port <PortName> vlan <VlanId>). When
the untagged-ctrl-vs attribute has been designated, then the L2 control frame
tunneling instance of the specified virtual switch will be used to handle the
untagged L2 control frames that ingress the logical-port.
When the untagged-ctrl-vs attribute is removed, an untagged L2 control frame

is processed at the port according the default disposition for its protocol.
Step Action
To add L2 control frame classification

1 Add L2 control frame traffic classification for a port:
port set port <PortName> untagged-ctrl-vs
<VirtualSwitchName>
To remove L2 control frame traffic classification
2 Remove L2 control frame traffic classification for a port:
port unset port <PortName> untagged-ctrl-vs
<VirtualSwitchName>
end

Procedure 13-2
Enabling and disabling L2 control frame tunneling
You can enable an L2 control frame tunnel on each port of each device
simultaneously.
Note: The maximum number of L2 control frame tunnels in a device is

equal to the number of physical ports available, that is, UNI plus NNI.
When you disable L2 control frame tunneling for a specified virtual switch, any
configured L2PT transforms will not occur, and untagged L2 control frames
will be handled according to their default disposition.
Step Action
To enable L2 control frame tunneling

1 Enable L2 control frame tunneling:
virtual-switch l2-cft enable vs <VirtualSwitchName>
where
vs is the virtual switch that you want to enable L2 control
<VirtualSwitchName> frame tunneling on
To (optionally) set the destination MAC address

2 Disable L2 control frame tunneling:
virtual-switch l2-cft l2pt-mac set
To disable L2 control frame tunneling
3 Disable L2 control frame tunneling:
virtual-switch l2-cft disable vs <VirtualSwitchName>
where
vs is the virtual switch that you want to disable L2 control
<VirtualSwitchName> frame tunneling on
end

Procedure 13-3
Adding and removing control protocols
When adding a control protocol, you can optionally specify the disposition. If
you do not specify the disposition, the default disposition for the control
protocol is used.
When you remove a control protocol from a L2 control frame tunneling

instance, untagged L2 control frames will be processed according to the
default disposition for the control protocol.
Step Action
To add a control protocol

1 Add a control protocol to an L2 control frame tunneling instance:
virtual-switch l2-cft protocol add vs <VirtualSwitchName>
{ctrl-protocol <802.1x|all-bridges-block|bridge-
block|cisco-cdp|cisco-dtp|cisco-pagp|cisco-pvst|cisco-
stp-uplink-fast|cisco-udld|cisco-vtp|garp-
block|gmrp|gvrp|lacp|lacp-markerlldp|oam|rstp|vlan-
bridge>} [disposition <discard|forward>]
where
vs is the virtual switch.
<VirtualSwitchName>
ctrl-protocol is the control protocol.
disposition Valid values are:
discard, which discards the frame without further
processing
forward, which directs the frame to the forwarding
domain associated with the L2 control frame tunneling
instance. Frames with this disposition are subject to all
ingress and egress transformations configured on the
interface. In addition, these frames are flooded to all
logical interfaces attached to the virtual switch
associated with the L2 control frame tunneling
instance.
To remove a control protocol

2 Remove a control protocol from an L2 control frame tunneling instance:
virtual-switch l2-cft protocol remove vs
<VirtualSwitchName> {ctrl-protocol <802.1x|all-bridges-
block|bridge-block|cisco-cdp|cisco-dtp|cisco-pagp|cisco-

pvst|cisco-stp-uplink-fast|cisco-udld|cisco-vtp|garp-
block|gmrp|gvrp|lacp|lacp-marker|lldp|oam|rstp|vlan-
bridge>}
end

Procedure 13-4
Setting the disposition of control protocols
After you add a control protocol to an L2 control frame tunneling instance, you
can modify its disposition.
Step Action
1 Set the disposition of a control protocol in an L2 control frame tunneling

instance:
virtual-switch l2-cft protocol set vs <VirtualSwitchName>
{ctrl-protocol <802.1x|all-bridges-block|bridge-
block|cisco-cdp|cisco-dtp|cisco-pagp|cisco-pvst|cisco-
stp-uplink-fast|cisco-udld|cisco-vtp|garp-
block|gmrp|gvrp|lacp|lacp-marker|lldp|oam|rstp|vlan-
bridge>} {disposition <discard|forward>}
end

Procedure 13-5
Setting L2 control frame tunneling attributes
When an untagged frame is forwarded (encapsulated) by the L2 control frame
tunneling instance, it is given a Fixed .1D priority value. The default Fixed .1D
priority value is 6. You can modify it to a value between 0 and 7.
The tunnel method controls the classification and processing of untagged L2

control frames. You can set the tunnel method for a virtual switch to one of two
modes, transparent or L2PT. The default mode is L2PT.
Step Action
1 Set L2 control frame tunneling attributes:

virtual-switch l2-cft set vs <vs> priority <NUMBER: 0-7>
tunnel-method <l2pt|transparent>
where
priority is the .1D priority for encapsulated frames.
<NUMBER: 0-7>
tunnel-method tunnel encapsulation method.
<l2pt|transparent>
end

Procedure 13-6
Displaying enabled L2 control frame tunneling
instances
You can display a summary of all currently enabled L2 control frame tunneling
instances or details about a single L2 control frame tunneling instance
specified by virtual switch.
Note: L2 control frame tunneling is also called control protocol tunneling

(CPT). The virtual switch ethernet show vs
<VirtualSwitchName> command shows the status and tunnel method for
L2 control frame tunneling as CPT Status and CPT Method.
Step Action
1 To display a summary of enabled L2 control frame tunneling instances:

virtual-switch l2-cft show
2 To display details about a specific enabled L2 control frame tunneling
instance:
virtual-switch l2-cft show [vs <VirtualSwitchName>]
end
Examples
The following example shows sample output for a summary of enabled L2
control frame tunneling instances.
> virtual-switch l2-cft show
+------------------------- L2 Ctrl Protocol Tunneling --------------------+

| Virtual Switch | Admin State | Tunnel Method | Priority |
+------------------+-------------+-----------------------------+----------+
| cft_0 | Disabled | l2pt | 6 |
| cft-vs | Disabled | l2pt | 6 |
+------------------+-------------+-----------------------------+----------+

The following example shows sample output for details about a specific
enabled L2 control frame tunneling instance.
> virtual-switch l2-cft show vs cft-vs
+--------- L2 Ctrl Protocol Tunneling - cft-vs -+
+-----------------------+--------------------------------+
| Tunnel Method | l2pt |
| Priority | 6 |
+-----------------------+--------------------------------+
| Protocol Name | Disposition |
+-----------------------+--------------------------------+
| rstp | forward |
| lacp | forward |
+-----------------------+--------------------------------+

Procedure 13-7
Displaying the L2 control frame classification for a
port
Display the status of L2 control frame classification for a specific port.
Step Action
1 Display the status of L2 control frame classification:

port show port <PortName>
where
<PortName> is the port to display the status of L2 control frame
classification for.
The status of L2 control frame classification appears in the Untagged Ctrl VS

field.
end

Procedure 13-8
Displaying L2 control frame tunneling configuration in
the configuration file
L2 control frame tunneling related configuration is saved to the configuration
file in various sections, including:
VIRTUAL-CIRCUIT CONFIG:
VIRTUAL-SWITCH CONFIG:
L2 CFT PROTOCOL CONFIG:
Step Action
1 Display configuration information:

configuration show
end
Example
The following example shows sample output for the configuration show
command.
> configuration show
...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! VIRTUAL-CIRCUIT CONFIG: virtual circuits
!
virtual-circuit ethernet create vc cft-vc0 vlan 100
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! VIRTUAL-SWITCH CONFIG:
!
!
virtual-switch ethernet create vs cft-vs vc cft-vc0
!
virtual-switch ethernet add vs cft-vs port 9
!
port set port 9 untagged-ctrl-vs cft-vs
!
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! L2 CFT CONFIG:
!
virtual-switch l2-cft enable vs cft-vs
!
virtual-switch l2-cft protocol add vs cft-vs ctrl-protocol rstp disposition
forward
virtual-switch l2-cft protocol add vs cft-vs ctrl-protocol lacp disposition
forward
!

Procedure 13-9
Configuring L2 control frame tunneling
In general, L2 control frame tunneling includes the following steps:
Add a disposition of forward or discard for each protocol to be handled by
L2 control frame tunneling to the L2 control frame tunneling Instance
associated with the virtual switch to be used as an L2 control frame
forwarding-domain.
Enable the L2 control frame tunneling Instance.
Specify the untagged-ctrl-vs for each customer-facing virtual switch
interface member. Those interface members will handle untagged L2
control frames.
Enable L2PT mode at the virtual switch if L2PT transforms are to occur for
tunneled L2 control frames.
Configure the L2 control frame fixed .1D priority value - this is the frame
PCP that will go onto the frame when encapsulated.
Note: For L2 control frame tunneling over MPLS you do not need to
specify the untagged-ctrl-vs for each customer-facing virtual switch
interface member.
Step Action
1 Create the VLAN.

where
vlan <VlanIdList> is the VLAN identifier.
[name is the name of the VLAN.
<String[31]>] If no name is specified, a default name is assigned with the
form of VLAN#<VLANid>. For example if the VLAN ID is
1000 the VLAN name will be VLAN1000.
Note: VLAN names cannot begin with an integer. For
example, 3PUD is not valid, but PUD3 is allowed.

vlan add vlan <VlanIdList> port <PortNameList>
where
vlan <VlanIdList> is the VLAN created in step 1.
port is the list of ingress and egress ports.
<PortNameList>

3 To confirm the creation of the VLAN, enter the following command:

vlan show
4 Confirm that the ports are members of the VLAN.
vlan show vlan <VlanIdList>
where
<VlanIdList> is the VLAN created in step 1.
5 Create a virtual circuit and assign it to the VLAN.

virtual-circuit ethernet create vc cft-vc vlan
<VlanIdList>
where
<VlanIdList> is the VLAN created in step 1.
6 To confirm the creation of the virtual circuit, enter the following command:
7 To confirm that the VLAN is associated with the virtual circuit, enter the
following command:
virtual-circuit show vc cft-vc
8 Add a reserved VLAN.
virtual-switch add reserved-vlan <VLANIdList>
where
<VLANIdList> is the reserved VLANs used to create virtual switch
Instances.
Note: This command is platform-dependent.
9 Create the virtual switch.

vc <VirtualCircuitName[15]>
where
vs <VirtualSwitch is the name of the virtual switch.
Name[15]>
vc <VirtualCircuit is the name of the virtual circuit to be associated with the
Name[15]> virtual switch.
10 Add the ingress port to the virtual switch.



| 9100 | 88A8>}
where
vs <vs> is the virtual switch created in step 9.
port is the port name
<PortNameList>
11 Enable L2 control frame tunneling for the virtual switch.

virtual-switch l2-cft enable vs <VirtualSwitchName[15]>
where
vs <VirtualSwitch is the virtual switch created in step 9.
Name[15]>
12 Add the control protocols to the protocol disposition list with the desired
disposition for the L2 control frame tunneling instance.
virtual-switch l2-cft protocol add vs
<VirtualSwitchName[15]> {ctrl-protocol <802.1x|all-
bridgesblock|bridge-block|cisco-cdp|ciscodtp|cisco-
pagp|cisco-pvst|cisco-stpuplink- fast|cisco-udld|cisco-
vtp|garpblock|gmrp|gvrp|lacp|lacpmarker|
lldp|oam|rstp|vlan-bridge>} [disposition
<discard|forward>]
where
vs <VirtualSwitch is the virtual switch created in step 9.
Name[15]>
{ctrl-protocol is the control protocol to add.
<802.1x|all-
bridgesblock|
bridge-block|cisco-
cdp|ciscodtp| cisco-
pagp|cisco-
pvst|cisco-
stpuplink-
fast|cisco-
udld|cisco-
vtp|garpblock|
gmrp|gvrp|lacp|lac
pmarker|
lldp|oam|rstp|vlan-
bridge>}
[disposition is the disposition. If left unspecified, the disposition is set to
<discard|forward>] the default disposition for the specified control protocol.

13 Add the L2 control frame classification to the port for ingress traffic.
port set port <PortNameList> untagged-ctrl-vs
<VirtualSwitchName[15]>
where
port is the port created in step 10.
<PortNameList>
untagged-ctrl-vs is the virtual switch created in step 9.
<VirtualSwitch
Name[15]>
14 To confirm the L2 control frame tunnel configuration of the virtual switch, enter
the following command:
virtual-switch l2-cft show vs <VirtualSwitchName[15]>
where
untagged-ctrl-vs is the virtual switch created in step 9.
<VirtualSwitch
Name[15]>
end
Example
The following example shows how you can configure virtual switches and
ports to classify untagged L2 control frames and then transform them into the
L2PT form. The ingress port classification allows untagged L2 control frames
and frames with VLAN tag 100. The L2 control frame tunneling instance is
enabled for the virtual switch. Also, RSTP and LACP are added to the protocol
disposition list with the disposition of forwarding.
Create the VLAN 100.
Add the ingress and egress ports to VLAN 100.
Confirm the creation of VLAN 100.
vlan show
Confirm the ports are members of VLAN 100.
vlan show vlan 100
Create a virtual circuit and assign it to VLAN 100.

virtual-circuit ethernet create vc cft-vc vlan 100
Confirm the creation of the virtual circuit.
+------ ETHERNET VIRTUAL CIRCUIT TABLE -----+

| Name | VLAN |
+-----------------+-------------------------+
| cft-vc | 100 |
+-----------------+-------------------------+
Confirm that VLAN 100 is associated with the virtual circuit.
virtual-circuit show vc cft-vc
+------------ ETHERNET VIRTUAL CIRCUIT INFO ----------+

+----------------------+------------------------------+
| Name | cft-vc |
| ID | 1 |
| Provider VLAN | (100) VLAN#100 |
| Psuedo-Wire Type | untagged |
| VS Using | |
+-----------------------------------------------------+
Add reserved VLAN 1000.
Create the virtual switch.
virtual-switch ethernet create vs cft-vs vc cft-vc
Add the ingress port to the virtual switch.
virtual-switch ethernet add vs cft-vs port 1
Enable L2 control frame tunneling for the virtual switch.
virtual-switch l2-cft enable vs cft-vs
Add the control protocols to the protocol disposition list with the desired
disposition for the L2 control frame tunneling instance.
virtual-switch l2-cft protocol add vs cft-vs ctrl-

protocol rstp disposition forward

virtual-switch l2-cft protocol add vs cft-vs ctrl-

protocol lacp disposition forward
Add the L2 control frame classification to the port for ingress traffic.
port set port 1 untagged-ctrl-vs cft-vs
Confirm the L2 control frame tunnel configuration of the virtual switch.
virtual-switch l2-cft show vs cft-vs
+--------- L2 Ctrl Protocol Tunneling - cft-vs -+

+-----------------------+-----------------------------+
| Tunnel Method | l2pt |
| Priority | 6 |
+-----------------------+-----------------------------+
| Protocol Name | Disposition |
+-----------------------+-----------------------------+
| rstp | forward |
| lacp | forward |
+-----------------------+-----------------------------+

Procedure 13-10
Configuring L2 control frame tunneling mode for MEF
CE 2.0 compliance
Configure L2 control frame tunneling mode for MEF Carrier Ethernet (CE) 2.0
compliance.
Table 13-2 describes the behavior changes that occur when a device
configured for CE 2.0 mode is configured for CE 1.0 mode.
Table 13-2
CE 2.0 mode to CE 1.0 mode behavior changes
CE 2.0 Mode CE 1.0 mode

Case
CE2-Bridge-block 0B,0F,0C,0D Bridge block including 0B,0F,0C,0D
1 forward forward forward forward
2 discard discard discard discard
3 forward discard forward forward
4 discard forward discard discard
Note: If L2 control frame tunneling is set to CE 2.0 mode and the device
is downgraded to a release that does not support CE 2.0 mode, L2 control
frame tunneling reverts to a CE 1.0 configuration with the behavior
changes noted in Table 13-2.
Step Action
1 Set the L2 control frame tunneling mode:

virtual-switch l2-cft set mode <mef-ce1|mef-ce2>
where
mode <mef- is the mode.
ce1|mef-ce2>
end


14-1
Quality of Service configuration 14-
This chapter details Quality of Service (QoS) features of the system software,
including:
Class of Services (CoS) policies and mapping
Traffic profiling
Traffic profiling with hierarchical ingress metering
Congestion management
Egress scheduling
Egress shaping

14-2 Quality of Service configuration
Class of Services (CoS) policies and mapping

The system software associates an internal resolved CoS (R-CoS) value and
resolved Color (R-COLOR) with every ingress frame that classifies to a port.
The R-CoS and R-COLOR values provide the baseline for CoS treatment of a
frame as it switches through the device. The R-CoS value ranges from 0-7,
where 7 has the highest priority and 0 has the lowest priority. R-COLOR
values are green and yellow. The initial R-CoS and R-Color values depend
upon the configuration of the of the port, including virtual switch memberships.
As of release 6.9.1, traffic profiles support the ability to remark the meter's
colored output from yellow to green, green to yellow, or leave as-is on a per
traffic profile basis. In addition, the RCOS value can be remarked based on a
frames meter color output. See Traffic profiling on page 4 for more details.
The resolved CoS Policy configured on a port is ignored when it is involved in

one or more virtual switch (subscriber) memberships. With that configuration,
the R-CoS and R-Color is determined by the encap CoS policy (and priority)
that is configured at the virtual switch. However, when the encap CoS policy
configured on a Virtual Switch Member is port-inherit, the resolved Cos Policy
of the port is applied.
Note: If an EVPL member is set to use the port-inherit policy is set to l3-
dscp, then all of the L3 frames in the other EVPLs follow the L3 mapping
table, even if set to vs-inherit or fixed. If the frames are not L3 and are
tagged, then the L2 portion of the mapping table is in effect. If the frames
are not L3 and are untagged without an IP header, then the R-CoS and R-
Color are set according to the ports fixed setting. For untagged frames,
the R-CoS and R-Color are set according to the ports fixed setting.
The Egress Frame CoS Policy is configured per port and defines when to use
the Egress Frame CoS Map to remark an egress L2 frame's PCP and DEI
fields based on the internal R-CoS and R-Color values.
Figure 14-1 shows which policy and portion of the map is in effect depending
on the ports configuration.

Figure 14-1 Resolved CoS Policy and Mapping
Yes UNI No (VLAN only or NNI)

Virtual
Switch
(VS)?
Yes No
EPL
Present?
1
VS or more Port
Encap No EVPLs in Yes Resolved
CoS port-inherit? CoS
Policy? Policy?
Other L3 DSCP L3 DSCP

F-CoS>R-CoS F-CoS>R-CoS l3-dscp
EVPL CoS Color
member CoS
policy?
not L3, use L2
Outer.1d Outer .1d

F-CoS>R-CoS F-CoS>R-CoS dot1d-pri
CoS Color
not tagged, use port
Port Port fixed-rcos/

Fixed CoS Fixed fixed-rcolor
Color
fixed VS Encap Outer .1d

Fixed Derived
CoS Outer.1d Color
vs-inherit
Outer.1d Outer .1d
F-CoS>R-CoS Derived
CoS Color
port-inherit

Traffic profiling
Traffic profiling classifies traffic based on different classification rules and
meters the traffic flow to configured EIR/PIR and CIR values defined in kbps.
Depending upon how the traffic flow compares to these rates, the R-COLOR
of each frame is set to a specific value upon ingress. Traffic ingressing at a
rate:
Up to CIR will be marked Green and allowed through.
Above CIR and less than PIR will be marked Yellow and allowed through.
Above PIR will be marked Red and dropped.
Note: On a 100 Mbps port the CIR cannot be set to the full amount of
physical bandwidth of the port (100 Mbps). This is because 1 Mb of
bandwidth is reserved for the ingress and egress of BPDUs and other high
priority traffic. To commit all of the physical bandwidth to a CIR could
create a serious condition in which the device does not receive critical
frames. To avoid this issue, the CIR should only be configured to a
maximum of 99 Mbps.
Determining classification attributes

In order for traffic to classify to a traffic profile, you need to configure classifiers
for the selected mode by setting the ports standard profile. Even though
classifiers are not mandatory upon creation, the traffic profile will not work
without configuring appropriate classifiers. Classifiers include:
dot1dpri - Classifies to the traffic profile based on 802.1D priority value
ranging 0-7. Up to 8 classifiers are supported per port.
ip-prec - Classifies to the traffic profile based on IP precedence value
ranging 0-7. Up to 8 classifiers are supported per port.
dscp - Classifies to the traffic profile based on DSCP. Up to 64 classifiers
are supported per port.
dscp-remark-policy - leave ingressing SVLAN 802.1p bit value as-is or
mark with a fixed value.
vlan - Classifies to the traffic profile based on VLAN ID. One VLAN
classifier is supported per port per profile.
vs - Classifies the traffic profile based on the Ethernet VS ID. Note that
traffic profiles cannot classify to an MPLS VS.
untagged - Classifies to the traffic profile if the traffic has no VLAN tag. Any
other classifiers will be ignored, however, they will consume resources, if
configured. To conserve resources when using the untagged classifier,
clear any other classifiers from the traffic profile. One untagged classifier
is supported per port per profile.

Note 1: Untagged traffic classifies first by the selected mode. Unless a

profile is configured to specifically classify untagged traffic, untagged
traffic with an IP header can classify to an IP precedence or DSCP based
traffic profile,
Note 2: Traffic profiles with the untagged classifier cannot be assigned to
ARP or non-conforming per port entries.
VLAN classifiers can be combined with 802.1D, IP precedence, or DSCP,
depending upon the allocation of hardware resources. The maximum number
of classifiers (including ARP and non-conforming) that are configurable per
mode and per port (without any adjustment to resource management) are
listed in Table 14-1.*
Table 14-1
Configurable classifiers
Classifier Per mode Per port Per port Per port (3960,
(3940, 5140) (3916, 3930, 3931, 5142, 5150, 5160)
3932)
dot1dpri 8 8 8 8
ip-prec (ipp) 8 8 8 8
dscp 64 64 64 64
vlan or vs* 1 64 1024 4096
vlan or vs/dot1dpri* 8 128 1024 4096
vlan or vs/ip-prec* 8 128 1024 4096
vlan or vs/dscp* 64 128 1024 4096
untagged 1 1 1 1
Note 1: The actual number of configurable classifiers will be less due to

reserved profiles (ARP/non-conforming) per port. Each port automatically
consumes 2 classifiers, 1 for ARP and 1 for non-conforming standard
profiles.
Note 2: When setting multiple classifiers in one set command an overlap
condition can occur, depending on the order in which the classifiers are
added. To set both a CoS (dot1d, DSCP, IP) classifier with a VLAN
classifier, set the CoS classifier first and then the VLAN classifier. For
more information a boo ut traffic profiling error codes, refer to Traffic
profiling error codes.

Note 3: *The VS maximum is up to the configurable limits of the system.

The device will reach the VS limit before the classification limit is reached.
For example, on a 3960 512 virtual switches can be configured even
though 4096 classifiers can be configured.
Determining Metering Attributes
As of release 6.9.1, the meter provisioning mode can be set to either EIR or
PIR, and PIR will begin to be deprecated. The mode that is chosen dictates
how provisioning is accepted, displayed, and saved. If EIR is specified, PIR
provisioning is disallowed.
Metering is also defined at the ports standard profile by the following
attributes:
cir - Committed information rate in kbits ranging from 0 up to the
administrative port speed. (Mandatory, if PIR is not specified).
eir - Excess information rate in kbits ranging from 0 up to the administrative
port speed. (PIR = CIR+EIR when EIR is specified)
pir - Peak information rate in kbits ranging from 0 up to the administrative
port speed. (Mandatory, if CIR is not specified).
Note 1: On 3940 and 5140 switches, the configured CIR and PIR always
normalize to a rate equal to or greater than the configured value in 64 kbps
increments in order to be processed by the hardware. Also, the PIR will
normalize to be equal to or greater than the configured CIR. On 3916,
3930, 3931, 3932, 3960, 5142, 5150, and 5160 switches, the configured
CIR and PIR always normalize to a rate in varying increments depending
upon the sum of the configured rates of the CBS and EBS and the
configured rate of the PIR.
Note 2: SAOS 6.x devices do not support throughput beyond actual port
speed. However, 6.x devices will allow the user to configure a CIR value
beyond the corresponding port speed. A warning message is displayed.
If the sum of the CBS and EBS is:
0 or less than 16 M, the CIR and PIR increment in steps of 64 kbps
16 M and less than 32 M, the CIR and PIR increment by 128 kbps
64 M and less than 128 M, the CIR and PIR increment by 512kbps
If the PIR is:

0 or less than 16.78 Gbps, the CIR and PIR increment in steps of 64
kbps
16.78 Gbps and less than 33.55 Gbps, CIR and PIR increment by 128
kbps

33.55 Gbps and less than 40 Gbps, CIR and PIR increment by 256
kbps
cbs - Committed Burst Size (CBS) in kilobytes (kbytes). On 3940 and 5140
switches, the value entered for the CBS is adjusted by rounding up to the
nearest power of 2 from 4 (22) up to 16384 (214) in Kbytes. On 3916, 3930,
3931, 3932, 3960, 5142, 5150, and 5160 switches, the CBS entered
value, ranging from 0-262144 Kbytes, is adjusted by rounding up
depending upon the sum of the CBS and EBS and the configured rate of
the PIR using the same criteria as previously described for the CIR and
PIR.
ebs - Excess burst size (EBS) in kbytes. On 3940 and 5140 switches, the
EBS entered is adjusted to fit the Peak Burst Sized (PBS), as defined in
hardware based upon the CBS value, minus the CBS value. The PBS is
rounded by rounding up to the nearest power of 2 from 4 (22) up to 16384
(214) in Kbytes, and the EBS is rounded to fit these increments when
added to the CBS. For example, entering CBS of 4 Kbytes, and EBS of 8
Kbytes would equal a PBS of 12 Kbytes. Since the nearest power of 2
increment to 12 is 16, the EBS is rounded up to 12 Kbytes. On 3916, 3930,
3931, 3932, 3960, 5142, 5150, and 5160 switches, the EBS entered value,
ranging from 0-262144 Kbytes, is the configured rate of the PIR using the
same criteria as previously described for the CIR and PIR.
Note: If CIR is equal to PIR, and CBS and EBS values are not specified,
the system applies the default burst to both CBS and EBS upon a reboot.
This does not apply to HIM profiles.
For the related procedures, see Configuring per-port standard traffic profiling
on page 14-53 and Configuring per-port and per-VLAN standard traffic
profiling on page 14-54.
Traffic profiling with hierarchical ingress metering

On the 3916, 3930, 3931, 3932, 3960, 5142, 5150, and 5160 platforms, traffic
profiling supports HIM (hierarchical ingress metering). With hierarchical
ingress metering, frames classify to a parent traffic profile for metering, and
are fed to a child traffic profile for additional metering. Hierarchical ingress
metering is supported by setting the per-port traffic profiling mode to one of
the following types:
Hierarchical port (hierarchical-port) - for port based classification at the
parent traffic profile.
Note: Untagged traffic is treated as non-conforming traffic and passes
through the default profile at the child level, unless a child profile is
configured to classify untagged traffic,

Hierarchical VLAN (hierarchical-vlan) - for unique VLANs or a default

classification for the parent traffic profile. Only one default profile may
exist per parent or child. No other classification in the default profile.
Advanced - supports both hierarchical and non-hierarchical traffic. See
Advanced classification mode.
Note 1: Untagged traffic is treated as non-conforming traffic and passes
through the default profile at the parent level, unless a child profile or a
separate profile at the parent level (above the default) is configured to
classify untagged traffic.
Advanced classification mode
In the advanced traffic profile classification mode, both hierarchical and non-
hierarchical traffic profiles can coexist. In addition to being able to configure
HIM and standard-profiles on the same port, the system can classify on a VS
name (or VS+VLAN, VS+COS and/or VS+VLAN+COS), as shown in Figure
14-2. Advanced mode is the only mode that supports this type of EVC based
classification.
When configuring EVC-based traffic-profiling, the following dependencies

must be considered:
If the traffic-profile is classifying on a VS, the port that the profile is created
on must be a member (EPL or EVPL) of the Virtual Switch that is being
used as a classifier. Otherwise an error is generated when trying to create
this traffic-profile.
If the traffic-profile is classifying on VS+VLAN, the port that the profile is
created on must be a member of the VS. If it is added as an EVPL, the
VLAN used in the traffic-profile must match the VLAN of the VS member.
VS members cannot be removed if the port that they are on still has traffic-
profiles classifying on the VS. All traffic-profiles on the port must be
deleted before removing the port as a member of the VS.
A VS cannot be deleted if it still has traffic-profiles using it as a classifier.
The traffic-profiles must be deleted first and then the VS can be deleted.

Figure 14-2
EVC advanced mode classification
IBP per EVC EVC ID1 IBP per EVC
CE- VLAN CoS 0,1,2,3 IBP per CoS
IBP per CoS per EVC EVC2 CE- VLAN CoS 4,5 IBP per CoS
CE- VLAN CoS 6,7

IBP per CoS
HIBP per CoS CoS 0,1,2,3 IBP per CoS

EVC ID3 Shared BW
per EVC
CoS 4,5 IBP per CoS
When advanced mode is configured, the parent ports must have unique
virtual switches across all parent profiles. There can be no overlap in parent
classification. Also, child level classification cannot overlap any other classifier
in use, that is, the profiles cannot overlap with other parent/child or other non-
hierarchical profiles. A T2 untagged profile is the only exception as it could
overlap other DSCP/IPP child classifiers under a given parent.
If a profile is created without a parent in advanced mode, it is assumed to be

a standard profile without hierarchical metering, and it cannot be added to a
parent later. It must be deleted and re-created with the parent associated at
the time of creation. In addition, a child profile can only be removed from a
parent by deleting the child profile.
Note: In advanced mode if the parent is using a VLAN classifier, only

h-vlan child modes are allowed, and vlan-cos generates an error.
Likewise, if the parent classification is a VS, then any child mode other
than vlan-cos generates an error.
For the related procedures, see Configuring hierarchical VLAN traffic profiles
on page 14-56, Configuring hierarchical port traffic profiles on page 14-61,
Configuring VS classification for standard traffic profiles on page 14-63, and
Configuring VS classification for HIM traffic profiles on page 14-64.
With standard traffic profiling, a single port cannot support duplicate

classification, such as the same VLAN or untagged. Hierarchical ingress
metering provides the ability to classify based on multiple classifications and
values to the same VLAN at different metering rates for the same port.

When changing to or from a hierarchical mode, all traffic profile must be

removed from the port. Also, the arp-standard-profile and nonconform-
standard-profile per port attributes do not apply to ports in a hierarchical traffic
profiling mode. Before changing the parents child mode, be sure to remove
any child profiles.
Note: The classifier-mode attribute does not affect the default profile at
the child level for hierarchical port mode. Also, it does not affect the
default profile at the parent level for hierarchical VLAN mode.
Congestion management
Congestion management processing determines whether a frame should be
enqueued or dropped. Congestion management is configured per queue
based on a congestion avoidance profile associated with each CoS queue.
This profile contains the drop parameters for traffic. Drop parameters are
defined by the following general attributes:
Drop Threshold - defines the percentage of the queue capacity that is
reached before packets are eligible to be dropped.
Drop Probability - define the percentage of packets that are dropped
once the threshold is exceeded.
By dropping packets before the queue fills up, congestion management

controls the average buffer queue size. As packets are dropped, the packet
source automatically decreases its transmission rate until all the packets
reach their destination, indicating that the congestion is cleared. TCP is an
example of a protocol that dynamically adapts to congestion-induced frame
loss.
Depending upon the hardware platform, the system software supports Simple
Random Early Detection (sRED) profiles or simple Weighted Random Early
Discard (sWRED) profiles for congestion avoidance that are enabled by
default. You can configure custom congestion avoidance profiles for your
platform and configure the egress port queues to use them.
Creating and modifying sRED profiles

The 3940 and 5140 platforms support sRED profiles. By default there is one
congestion avoidance profile (Default-SRED) in the system that all queues
reference, and each port supports two default sRED curves per queue, one
for yellow traffic and one for green traffic. Each sRED curve supports a lower
drop threshold and drop probability. The upper threshold is not configurable,
and supports 128 packets per port.
When the number of packets are below the lower threshold, no packets are
dropped. When they exceed the lower threshold, and are below the upper
threshold, they are dropped according to the drop probability value. When the

number of packets reaches the upper threshold, all packets are dropped (100
percent drop probability) until the number of packets is below the upper
threshold.
For yellow packets, the default drop threshold is 50 percent. For green
packets, the default drop threshold is 75 percent. This means that the queue
capacity can be filled with 75 percent green packets, and 50 percent yellow
packets before the packets are eligible to be dropped. Additionally, both sRED
curves assign a drop probability percentage for green (0.09765625 percent or
1/1024) and yellow (6.25 percent or 1/16) packets per CoS queue that is
applied via a congestion avoidance profile.You can create up to 7 custom
congestion avoidance profiles and modify their configuration.
Lower drop threshold values for green or yellow traffic range from 1-100
percent. Drop probability values for green or yellow traffic include:
100pct - 100 percent
6.25pct - 6.25 percent or 1/16.
3.125pct - 3.125 percent or 1/32.
1.5625pct - 1.5625 percent or 1/64.
0.78125pct - 0.78125 percent or 1/128.
0.390625pct - 0.390625 percent or 1/256.
0.1953125pct - 0.1953125 percent or 1/512.
0.09765625pct - 0.09765625 percent or 1/1024.
If you create a custom sRED profile without specifying the thresholds or drop
probability values, the profile will be the same as the Default-SRED profile.
Creating and modifying sWRED profiles on the 3960

The 3960 platform supports simple Weighted Random Early Discard
(sWRED) profiles to handle three types of traffic:
TCP green traffic
TCP yellow traffic (has been metered to yellow from traffic profiling)
Non-TCP traffic
For each traffic type, an sWRED profile supports an sWRED curve with a
configurable start threshold (1-100 percent), upper threshold (1-100 percent),
and a maximum drop probability. Maximum drop probability values include:
75pct - 75 percent
50pct - 50 percent
25pct - 25 percent

10pct - 10 percent
9pct - 9 percent
8pct - 8 percent
7pct - 7 percent
6pct - 6 percent
5pct - 5 percent
4pct - 4 percent
3pct - 3 percent
2pct - 2 percent
1pct - 1 percent
0pct - 0 percent
When the number of packets are below the start threshold, no packets are
dropped. When they exceed the start threshold, and are below the upper
threshold, they are dropped according to the maximum drop probability value.
When the number of packets reaches the upper threshold, all packets are
dropped according to the maximum drop probability until the number of
packets is below the upper threshold.
The default sWRED profile (Default-S-WRED) on the 3960 is configured as

follows:
TCP green start threshold - 75 percent
TCP green maximum upper threshold - 100 percent
TCP green maximum drop probability - 0 percent
TCP yellow start threshold - 50 percent
TCP yellow maximum upper threshold - 100 percent
TCP yellow maximum drop probability - 100 percent
Non-TCP start threshold - 50 percent
Non-TCP maximum upper threshold - 100 percent
Non-TCP maximum drop probability - 100 percent
If you create a custom sWRED profile without specifying the thresholds or

drop probability values, the profile will be the same as the Default-S-WRED
profile.

Creating and modifying sWRED profiles on the 3916, 3930, 3931, 3932,
5142, 5150, and 5160
The 3916, 3930, 3931, 3932, 5142, 5150, and 5160 platforms support
sWRED profiles to handle two types of traffic:
Green traffic
Yellow traffic (has been metered to yellow from traffic profiling)
For each traffic type, an sWRED profile supports an sWRED curve with a
configurable lower threshold (1-100 percent), upper threshold (1-100
percent), and a maximum drop probability. Maximum drop probability values
include:
75pct - 75 percent
50pct - 50 percent
25pct - 25 percent
10pct - 10 percent
9pct - 9 percent
8pct - 8 percent
7pct - 7 percent
6pct - 6 percent
5pct - 5 percent
4pct - 4 percent
3pct - 3 percent
2pct - 2 percent
1pctv1 percent
0pct - 0 percent
When the number of packets are below the lower threshold, no packets are
dropped. When they exceed the lower threshold, and are below the upper
threshold, they are dropped according to the maximum drop probability value.
When the number of packets reaches the upper threshold, all packets are
dropped according to the maximum drop probability until the number of
packets is below the upper threshold.
The default sWRED profile (Default-S-WRED) is configured as follows:

Green lower threshold - 75 percent
Green upper threshold - 100 percent
Green maximum drop probability - 0 percent

Yellow lower threshold - 50 percent

Yellow upper threshold - 100 percent
Yellow maximum drop probability - 100 percent
If you create a custom WRED profile without specifying the thresholds or drop
probability values, the profile will be the same as the Default-S-WRED profile.
Egress scheduling
Scheduling determines the order in which the physical queues are processed.
By default, the system software follows the strict priority scheduling. CoS
queue 7 has the highest priority while CoS queue 0 has the lowest priority.
When contention (or congestion) for bandwidth occurs in the system, the
higher priority CoS queues will be serviced before the lower priority CoS
queues. With the default scheduler algorithm (strict), the 802.1p priority
(VLAN priority in the frame) is used to map to an internal priority (resolved
CoS) which is then mapped to a physical CoS queue. The result is that frames
with a higher priority will transmit before those with a lower priority. Strict
priority queuing reduces resources for low priority packets, but ensures low-
latency servicing of high-priority packets.
In addition to strict priority, three other scheduling methods can be configured

along with a scheduler weight. The scheduler weight determines the priority
of the queue in relation to the other queues in the egress port queue group.
When configured for any of these scheduler modes, if the scheduling weight
of a queue in the egress port queue group is set to 0, the scheduler will treat
that queue as if it is in strict priority mode.
Weighted Round Robin (WRR) - queues in the queuing group are
scheduled in a weighted fashion according to the per-queue scheduler-
weight.
Round-Robin (RR) - queues in the queuing group are scheduled as if all
queues in the queuing group have equal weighting.
Weighted Deficit Round Robin (WDRR) - queues in the queuing group are
scheduled in a weighted fashion according to the per-queue scheduler-
weight and frame size. When using this scheduler algorithm, you can
configure the scheduler granularity (wdrr-scheduler-granularity) to adjust
pool sizes in which the weights are applied. This setting is especially
useful when using port speeds lower than 10Mbps. Small pool sizes have
less latency, and more jitter. Larger sizes have more latency, and less jitter.
The value entered will be rounded to the nearest largest size of 50, 100,
200, 400, 800, or 1600 Kbytes. The default value is 1600 Kbytes.

Note: When egress scheduling is set to either WRR or WDRR on 3916,

3930, 3931, 3932 or 3960 devices, the CIR and CBS settings are ignored.
Do not configure CIR and CBS for WRR and WDRR scheduling modes.
Instead, configure the weight values to distribute the traffic associated with
each queue.
The default scheduler weights per queue are as follows:

Queue 0: 20
Queue 1: 30
Queue 2: 40
Queue 3: 50
Queue 4: 60
Queue 5: 70
Queue 6: 80
Queue 7: 0
Egress shaping
A shaper-rate and burst size can be configured on the egress port queue
group that limits the amount of egress bandwidth (in Kbps) a port uses(0 to 40
Gbps) and controls the amount of traffic (in Kbytes) that can burst (0 to 256
Mbytes). The configured shaper-rate normalizes to a rate in varying
increments depending upon the sum of the configured burst size.
In order to guarantee CIR, the individually-set CIR on queues must not be

oversubscribed for the egress port that the frames are egressing. That is, the
sum of all CIRs for the physical queues and the virtual queues in a queue
group on a port should not exceed the administrative (and operational) speed
of the port. When the shaper rate of the egress port queue group is set, it sets
a single Information Rate (IR) regardless of the CIR and EIR of the individual
queues. To guarantee CIR, the sum of the CIRs on each queue cannot exceed
the IR of the egress port queue group.
When a queue or an attribute of the egress queue group of an aggregated port

is modified, that value is updated at each queue or physical port of the
aggregation, with the exception of the shaper rate bandwidth, which differs
depending upon the platform:
3940, 5140 - The shaper rate bandwidth is divided equally among the
number of distributing ports. This means that the shaper rate can be used
to control the total bandwidth that the ports share, otherwise the ports
would each have an amount of bandwidth that would add up to a
cumulative amount of bandwidth for the aggregation member ports. The
default shaper rate is the same as the administrative port speed.

3916, 3930, 3931, 3932, 3960, 5142, 5150, 5160 - The shaper rate
bandwidth for the link aggregation defaults to a bandwidth equal to the
maximum number of 10 Gig ports allowed in a link aggregation, regardless
if the link aggregation consists of 1 Gig or 10 Gig ports.
For example, on a 3960 device, the maximum number of 10 Gig ports allowed
in a link aggregation is 2; therefore, the default Egress Shaper-Rate
Bandwidth for the link aggregation is 20 Gbps.
For a 5150 device, the maximum number of 10 Gig ports allowed in a link
aggregation is 4; therefore, the default Egress Shaper-Rate Bandwidth for the
link aggregation is 40 Gbps.
When you set the burst size, the value is rounded to the nearest larger 4Kbyte
block. The burst size is not divided among ports in an aggregation group. The
default burst size is 10240 Kbytes.

Procedure 14-1
Configuring Class of Services (CoS) policies on a port
You can configure CoS policies for each port.
Note: The egress frame CoS policy setting is not available on 3940 and
5140 devices.
The resolved CoS Policy options are:

Outer .1D mapped (dot1d-tag1-cos) -The Priority Code Point (PCP)/Layer
2 (L2) CoS 802.1D priority value from the outer-tag is mapped to R-CoS
and R-Color values derived from the Resolved CoS Mapping table. When
this policy is applied, CoS mapping is in trusted mode. This is the default
for all ports.
Fixed CoS (fixed-cos), Fixed R-CoS (fixed-rcos) and Fixed R-COLOR
(fixed-rcolor) - CoS values in the frame are ignored and fixed R-CoS is
applied to the frame from the Fixed Resolved CoS and Fixed Resolved
Color value for the port. When this policy is applied, CoS mapping is in
untrusted mode. The default Fixed Resolved CoS value is 0 and the
default Fixed Resolved Color is green.
Layer 3 DSCP CoS (l3-dscp-cos) - The Differentiated Services Code Point
(DSCP) CoS value from the Layer 3 Type Of Service (TOS) byte is
mapped to an R-CoS and R-Color value from the Resolved CoS Mapping
table. When this policy is applied, CoS mapping is in trusted mode.
The egress frame CoS policy options are to ignore or to re-mark the L2
frame's PCP and DEI fields based on the internal R-CoS and R-Color values
(rcos-to-l2-outer-pcp-map).
Step Action
To set the CoS policies and mapping

1 Set the resolved CoS policy:
port set port <PortNameList> [resolved-cos-policy <dot1d-
tag1-cos|fixed-cos|l3-dscp-cos>] [fixed-rcos <NUMBER: 0-
7] [fixed-rcolor <green|yellow>] [egress-frame-cos-
policy <ignore | rcos-to-l2-outer-pcp-map>]
end

Example
The following example sets a resolved CoS policy.
port set port 1 resolved-cos-policy dot1d-tag1-cos
The following example sets the policy to a fixed resolved CoS and fixed
resolved color.
port set port 1 resolved-cos-policy fixed-cos fixed-rcos 0 fixed-rcolor yellow
The following example sets an egress-frame-cos-policy.
port set port 1 egress-frame-cos-policy rcos-to-l2-outer-pcp-map

Procedure 14-2
Displaying the CoS policy and mapping on a port
The Resolved CoS Policy, Egress Frame CoS Policy, Fixed Resolved Color,
and Fixed Resolved CoS settings can be displayed for a specific port.
Step Action
1 Display the settings:

port show port <PortName>
where
port <PortName> is the port that you want to display settings for.
end
Example
The following example shows sample output for the port show port command.
port show port 1
+-------------------------------- PORT 1 INFO ----------------------------+

| Field | Admin | Oper |
+-------------------------+------------------------+----------------------+
| Type | GigEthernet |
...
| Fixed Resolved CoS | 0 | 0 |
| Fixed Resolved Color | green | green |
...
| Egress Frame Cos Policy | ignore | ignore |
...
| Resolved CoS Policy | dot1d-tag1-cos | dot1d-tag1-cos |
...
+-------------------------+------------------------+----------------------+

Procedure 14-3
Creating a resolved CoS map
Table 14-2 shows the default resolved CoS map (DefaultFcosRcos).
Table 14-2
Default resolved CoS map
Frame PCP/L2 DEI/CFI Frame L3 DSCP R-CoS R-COLOR

CoS 802.1D CoS
0 0 0-7 0 Green
0 1 0-7 0 Green
1 0 8-15 1 Green
1 1 8-15 1 Green
2 0 16-23 2 Green
2 1 16-23 2 Green
3 0 24-31 3 Green
3 1 24-31 3 Green
4 0 32-39 4 Green
4 1 32-39 4 Green
5 0 40-47 5 Green
5 1 40-47 5 Green
6 0 48-55 6 Green
6 1 48-55 6 Green
7 0 56-63 7 Green
7 1 56-63 7 Green
Untagged Untagged Untagged Ingress port fixed Ingress port fixed

PCP/L2 CoS R-COLOR
802.1D value
In addition to the default resolved CoS map, you can configure customized
maps and assign them to ports.

You can configure 1 custom resolved CoS map per port, including the
following types of mapping:
L2 CoS - maps the customer PCP/L2 CoS 802.1D and DEI/CFI priority to
R-CoS and R-COLOR.
L3 CoS - maps the customer L3 CoS DSCP to R-CoS and R-COLOR.
Step Action
1 Create a custom resolved CoS map:

traffic-services cos-mapping resolved-cos-map create
{cos-map <Resolved CoS Map Name>}
where
cos-map is the identifier for the custom resolved CoS map.
<Resolved CoS
Map Name>
end
Example
The following example creates a custom resolved CoS map with an identifier
of custom-1.
traffic-services cos-mapping resolved-cos-map create cos-map custom-1

Procedure 14-4
Modifying a resolved CoS map
You can modify the attributes for the default and all custom resolved CoS
maps.
Step Action
1 Modify a custom resolved CoS map:

traffic-services cos-mapping resolved-cos-map set {cos-
map <String[15]>} [dot1dpri-cos <0-7>] [dot1dpri-dei
<NUMBER:0-1>] [l3-cos-dscp <NUMBER:0-63>] [mpls-tc
<String>] {r-cos <NUMBER:0-7>} [r-color <green|yellow>]
where
cos-map <String[15]> is the identifier for the custom resolved CoS map.
[mpls-tc <String>] overloads the equivalent dot1dpri value with dot1dei=0
entry. The mpls-tc values apply only to MPLS enabled
devices.
end
Example
The following example modifies the attributes of the resolved CoS map
custom-1.
traffic-services cos-mapping resolved-cos-map set cos-map custom-1 dot1dpri-

cos 1,2,3,4 r-cos 1

Procedure 14-5
Setting the resolved CoS map for a port
By default, ports are set to use the default Resolved CoS Map. You can modify
the port to use a custom resolved CoS map or to reset to the default. In
addition, you can configure the port to remark the frames SVLAN Layer 2 CoS
value with the mapped R-CoS and R-COLOR values mapped from the
Customer DSCP or 802.1D priority.
Note: Remarking the frames Layer 3 DSCP CoS value with a mapped
DSCP value is implemented with traffic profile configuration.
Step Action
1 Set the resolved CoS map for a port:

port set port <PortNameList> resolved-cos-map <Resolved
CoS Map Name> resolved-cos-remark-l2 <false|true>
where
<PortNameList> is the port that you want to set a resolved CoS map for.
<Resolved CoS is the identifier for the resolved CoS map.
Map Name>
end
Example
The following example sets the resolved CoS map for a port.
port set port 1 resolved-cos-map custom-1 resolved-cos-remark-l2 true

Procedure 14-6
Deleting a custom R-CoS map
You can delete custom resolved CoS maps, but not the default.
Note: A custom R-CoS queue map cannot be deleted if it is assigned to

a port.
Step Action
1 Set the port using the custom R-CoS map to the default R-CoS map:
port set port <PortName> ingress-to-egress-qmap Default-
RCOS
traffic-services queuing queue-map delete rcos-map
custom-map-1
2 Delete a resolved CoS map:
traffic-services cos-mapping resolved-cos-map delete cos-
map <Resolved CoS Map Name>
where
cos-map is the resolved CoS map to delete.
<Resolved CoS
Map Name>
end
Example
The following example deletes the custom resolved CoS map name custom-1.
port set port 9 ingress-to-egress-qmap Default-RCOS

traffic-services queuing queue-map delete rcos-map custom-map-1
traffic-services cos-mapping resolved-cos-map delete cos-map custom-1

Procedure 14-7
Displaying resolved CoS maps
You can
display a summary of resolved CoS maps
display details for resolved CoS maps
Step Action
To display a summary of resolved CoS maps

1 Display a summary of resolved CoS maps:
traffic-services cos-mapping resolved-cos-map show [cos-
map <cos-map>]
where
cos-map <cos- is the FCOS->RCOS name.
map>
To display details for resolved CoS maps

2 Display details for resolved CoS maps:
traffic-services cos-mapping resolved-cos-map show [cos-
map <cos-map>] detail
where
map>
end
Example
The following example shows sample output for displaying resolved CoS
maps.
traffic-services cos-mapping resolved-cos-map show cos-map custom-1
+-------------------------------------------------------------------------+
| Ingress COS->RCOS Map Summary - custom-1 |
+-------------------------------------------------------------------------+
| Ingress COS || RCOS | RCOLOR |
| L2 COS | DEI/CFI || L3 DSCP || | |
+--------------+---------++------------------------------++------+--------+
| | || || | |
| 0 | 0 || || 0 | green |
| 0 | 1 || || | green |
| | || 0-7 || | green |
+--------------+---------++------------------------------++------+--------+
| | || || | |
| 1-4 | 0 || || 1 | green |

| 1 | 1 || || | green |
| | || 8-15 || | green |
+--------------+---------++------------------------------++------+--------+
| | || || | |
| 2 | 1 || || 2 | green |
| | || 16-23 || | green |
...
+--------------+---------++------------------------------++------+--------+
| | || || | |
| 7 | 0 || || 7 | green |
| 7 | 1 || || | green |
| | || 56-63 || | green |
+--------------+---------++------------------------------++------+--------+
The following example shows sample output for details of a resolved CoS
map.
traffic-services cos-mapping resolved-cos-map show cos-map custom-1 detail
+--------------------------------------+
| RESOLVED COS MAP DETAIL INFO |
+--------------------------------------+
| Name | custom-1 |
| logical-id | 2 |
+-------------------+++----------------+
| L2 Cos | DEI/CFI ||| RCOS | RCOLOR |
+-------------------+++-------+--------+
| 0 | 0 ||| 0 | green |
| 0 | 1 ||| 0 | green |
| 1 | 0 ||| 1 | green |
| 1 | 1 ||| 1 | green |
...
| 6 | 0 ||| 6 | green |
| 6 | 1 ||| 6 | green |
| 7 | 0 ||| 7 | green |
| 7 | 1 ||| 7 | green |
+-------------------+++-------+--------+
| L3 DSCP ||| RCOS | RCOLOR |
+-------------------+++-------+--------+
| 0 ||| 0 | green |
| 1 ||| 0 | green |
| 2 ||| 0 | green |
| 3 ||| 0 | green |
...
| 63 ||| 7 | green |
+-------------------+++-------+--------+

Procedure 14-8
Creating a frame CoS map
With frame CoS mapping, the R-CoS and R-Color associated with a frame is
mapped to specific CoS values in the frame based upon the default Frame
CoS mapping table (DefaultRcosFcos) as shown in Table 14-3.
Table 14-3
Default Frame CoS mapping table
R-CoS R-COLOR Frame L2 Frame L2 DEI

PCP
(0-7)
0 Green 0 0
0 Yellow 0 0
1 Green 1 0
1 Yellow 1 0
2 Green 2 0
2 Yellow 2 0
3 Green 3 0
3 Yellow 3 0
4 Green 4 0
4 Yellow 4 0
5 Green 5 0
5 Yellow 5 0
6 Green 6 0
6 Yellow 6 0
7 Green 7 0
7 Yellow 7 0
In addition to the default frame CoS map, you can configure customized maps
and assign them to ports.
You can configure up to 3 custom frame CoS maps to use the frames R-CoS
and R-Color to map the customer PCP/L2 CoS 802.1D and Discard Eligibility
Indicator (DEI) priority values upon egress.

DSCP value is implemented with traffic profile configuration.
Step Action
1 Create a custom frame CoS map:

traffic-services cos-mapping frame-cos-map create {cos-
map <String[15]>}
where
cos-map is the identifier for the custom frame CoS map.
<String[15]>
end
Example
The following example creates a custom frame CoS map.
traffic-services cos-mapping frame-cos-map create cos-map custom-1

Procedure 14-9
Modifying a frame CoS map
You can modify the attributes for the default and all custom frame CoS maps.
Step Action
1 Modify a custom frame CoS map:

traffic-services cos-mapping frame-cos-map set cos-map
<cos-map> {r-cos <NUMBER:0-7>} {r-color <green|yellow>}
[dot1dpri-cos <NUMBER: 0-7>] {dot1dpri-dei <NUMBER:0-1>}
{mpls-tc <NUMBER: 0-7>}
where
map>
r-cos is the RCOS value to use.
<NUMBER:0-7>
r-color is the resolved color.
<green|yellow>
dot1dpri-cos is the egress frame COS (pcp) value.
<NUMBER: 0-7>
dot1dpri-dei is the egress frame color.
<NUMBER:0-1>
mpls-tc overloads the equivalent dot1dpri value with dot1dei=0
<NUMBER: 0-7> entry. The mpls-tc values apply only to MPLS enabled
devices.
end
Example
The following example modifies a custom frame CoS map.
traffic-services cos-mapping frame-cos-map set cos-map fcustom-1 r-cos 1

r-color yellow dot1dpri-cos 1 dot1dpri-dei 1

Procedure 14-10
Deleting a frame CoS map
You can delete custom frame CoS maps, except for the default.
Step Action
1 Delete a frame CoS map:

traffic-services cos-mapping frame-cos-map delete cos-map
<RcosFcosMap>
where
map>
end
Example
The following example deletes a frame CoS map.
traffic-services cos-mapping frame-cos-map delete cos-map custom-1

Procedure 14-11
Setting the frame CoS map for a port
By default, ports are set to ignore frame CoS mapping. You can modify the
port to use a custom frame CoS map or the default. In addition, you can
configure the port to remark the frames SVLAN Layer 2 CoS and R-Color
value with the mapped R-CoS value mapped from the Customer DSCP or
802.1D priority.
DSCP value is implemented with traffic profile configuration. When egress
Frame CoS mapping is enabled, the ingress setting resolved-cos-remark-
l2 is overridden and will no longer preserve the incoming frame CoS.
Step Action
1 Set the Frame CoS map for a port:

port set port <PortNameList> frame-cos-map <Frame CoS Map
Name> egress-frame-cos-policy <ignore|rcos-to-l2-outer-
pcp-map> resolved-cos-remark-l2 <false|true>
end
Example
The following example sets the frame CoS map for a port.
port set port 1 frame-cos-map custom-1 egress-frame-cos-policy rcos-to-l2-

outer-pcp-map resolved-cos-remark-l2 true

Procedure 14-12
Displaying frame CoS maps
Display frame CoS maps.
Step Action
1 Display all frame CoS maps or a specific map:

traffic-services cos-mapping frame-cos-map show [frame-
cos-map <Frame CoS Map Name>]
where
frame-cos-map is the specific frame CoS map to be displayed.
<Frame CoS Map
Name>
end
Example
The following example shows sample output for a frame CoS map.
traffic-services cos-mapping frame-cos-map show
+---------------------------------------+
| RESOLVED COS MAP TO FRAME COS INFO |
+---------------------------------------+
| Name | DefaultRcosFcos |
| logical-id | 1 |
+-------+---------+++---------+---------+
| RCOS | RCOLOR ||| L2-COS | L2-DEI |
+-------+---------+++---------+---------+
| 0 | green ||| 0 | 0 |
| 0 | yellow ||| 0 | 0 |
| 1 | green ||| 1 | 0 |
| 1 | yellow ||| 1 | 0 |
| 2 | green ||| 2 | 0 |
| 2 | yellow ||| 2 | 0 |
| 3 | green ||| 3 | 0 |
| 3 | yellow ||| 3 | 0 |
| 4 | green ||| 4 | 0 |
| 4 | yellow ||| 4 | 0 |
| 5 | green ||| 5 | 0 |
| 5 | yellow ||| 5 | 0 |
| 6 | green ||| 6 | 0 |
| 6 | yellow ||| 6 | 0 |
| 7 | green ||| 7 | 0 |
| 7 | yellow ||| 7 | 0 |
+-------+---------+++---------+---------+

Procedure 14-13
Configuring ingress R-CoS to egress queue mapping
Each physical port supports 8 CoS queues. Depending upon the policies
applied to the port, the R-CoS and R-COLOR values may change during
processing. The final internal R-CoS value is used to map the frame to one of
the 8 physical port CoS queues as shown in Table 14-4
Table 14-4
Default internal R-CoS mapping
R-CoS Physical Port CoS Queue
0 0
1 0
2 1
3 2
4 3
5 4
6 5
7 6
Reserved for outbound CPU frames 7
In addition to the default queue mapping, you can create up to 7 custom

Queue Map Profiles map R-CoS to CoS queue. The mapping-mode of custom
queue map profiles is always R-CoS mapped. To configure a port to use a
custom queue map profile, set the ingress-to-egress-qmap attribute. R-CoS
values (0 - 7) can be mapped to CoS Queues (0 - 7), or any combination
thereof (for example, all 7 R-CoS values mapped to the same CoS queue).
To create and modify a custom R-CoS to CoS queue table and assign it to an egress port:
traffic-services queuing queue-map create rcos-map custom-map-1
traffic-services queuing queue-map set rcos-map custom-map-1 rcos 0 queue 3
port set port 9 ingress-to-egress-qmap custom-map-1
To set the R-CoS map to the default for a port:

Note: You cannot unset a port's ingress-to-egress-qmap profile, as this is
a required parameter. To remove a custom R-CoS profile from a port you
must replace it with another R-CoS profile (for example, the Default-RCOS
profile).
port set port 9 ingress-to-egress-qmap Default-RCOS

Procedure 14-14
Displaying an R-CoS map
Display an R-Cos map.
Step Action
1 To display an R-CoS map:

traffic-services queuing queue-map show [rcos-map
<RcosQueueMap>]
where
rcos-map is the R-CoS map to be displayed.
<RcosQueueMap>
end
Example
The following example shows output for the default R-CoS map.
traffic-services queuing queue-map show Default-RCOS
+---------------------------RCOS TO QUEUE MAPPING ------------------------+

| |
+-------------------------------+-----------------------------------------+
| Name | Default-RCOS |
| Id | 1 |
| Type | RCOS To Queue Mapping |
+-------------------------------------------------------------------------+
| RCOS: | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | |
| +---+---+---+---+---+---+---+---+ |
| Queue: | 0 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | |
+---------+---+---+---+---+---+---+---+---+-------------------------------+

Procedure 14-15
Applying R-CoS policies and mapping in a VLAN
With the example in this section, frames with VID 100 and specific PCP/L2
CoS 802.1D and DEI/CFI values are assigned an internal R-CoS as shown in
Table 14-5.
Table 14-5
Custom map
Frame PCP/ Frame DEI/ R-CoS R-COLOR

L2 CoS CFI
802.1D
0 0,1 1 Green
1 0,1 0 Yellow
2 0,1 1 Green
3 0,1 1 Green
4 0,1 2 Green
5 0,1 3 Green
6 0,1 4 Green
7 0,1 0 Yellow
Untagged frames will be assigned an R-CoS according to the ports fixed

R-CoS configuration. For example, a frame with VID 100 and PCP/L2 CoS.1D
value of 0 is mapped to R-CoS 1.

Figure 14-3
UNI NNI
R-CoS or
.1D 0 VLAN 100 to UNI R-CoS 1
DEI/CFI 0 CoS R-COLOR
VID 100 Queue Green
100
Step Action
1 Create the R-CoS map and set the mapping for PCP/L2 CoS.1D to R-CoS
values.
traffic-services cos-mapping resolved-cos-map create cos-map MyL2Map
traffic-services cos-mapping resolved-cos-map set cos-map MyL2Map dot1dpri-
cos 0,2,3 dot1dpri-dei 0,1 r-cos 1 r-color green
cos 1,7 dot1dpri-dei 0,1 r-cos 0 r-color yellow
cos 4 dot1dpri-dei 0,1 r-cos 2 r-color green
2 Configure the ingress ports resolved CoS Policy and Map.

port set port 2 resolved-cos-policy dot1d-tag1-cos resolved-cos-map MyL2Map
3 Create the provider VLANs and add the NNI port.

vlan create vlan 100,1000-1001
end

Procedure 14-16
Applying R-CoS policies and mapping in a virtual
switch
With the example in this section, frames with CVID 100 and specific DSCP
values are assigned an internal R-CoS as shown in Table 14-6, because the
virtual switch member inherits the custom R-CoS map of the port. Untagged
frames will be assigned an R-CoS according to the ports fixed R-CoS
configuration.
Table 14-6
Custom map
Frame DSCP R-CoS R-COLOR
6 1 Green
5 2 Green
4 3 Green
3 4 Green
2 5 Green
1 6 Green
0, 8 7 Yellow
As an example, a frame with CVID 100 and DSCP value of 0 is mapped to R-

CoS 7 and R-COLOR Yellow.
Figure 14-4
Frame with CVID 100 and DSCP value of 0 mapped to R-CoS 7 and R-COLOR Yellow
SVID (1000)
UNI NNI
R-CoS
DSCP 0 VC to R-CoS 7
CVID (100) TEST1 CoS R-COLOR
Queue Yellow
1000/100

Step Action
1 Create the R-CoS map:

traffic-services cos-mapping resolved-cos-map create cos-
map <cos-map>
2 Set the mapping for DSCP to R-CoS values:
traffic-services cos-mapping resolved-cos-map set cos-map
<cos-map> [l3-cos-dscp <dscp values and ranges>]
[dot1dpri-cos <dot1d values and ranges] [dot1dpri-dei
<NUMBER: 0-1>] [mpls-tc <mpls-tc values and ranges>]{r-
cos <NUMBER: 0-7>} [r-color <green|yellow>]
where
cos-map <cos- is the FCOS to RCOS name.
map>
l3-cos-dscp is the ingress DSCP value to map.
<dscp values and
ranges>
dot1dpri-cos is the ingress.1D value to map.
<dot1d values
and ranges
dot1dpri-dei is the ingress frame color cfi/dei value.
<NUMBER: 0-1>
mpls-tc <mpls-tc is the mpls tc/exp value to map.
values and
ranges>
r-cos <NUMBER: is the RCOS value to use.
0-7>
r-color is the resolved color.
<green|yellow>
3 Configure the resolved CoS Policy and map of the ingress port:
port set port <port> resolved-cos-policy {<dot1d-tag1-
cos|fixed-cos|l3-dscp-cos>} {resolved-cos-map <FCOS to
RCOS Map>}
4 Create the provider VLANs:
5 Add the NNI port:
6 Create the virtual circuits.
virtual-circuit ethernet create vc <vc> {vlan <VLAN>}
[statistics <on|off>]

7 Reserve VLANs for the virtual switches.

virtual-switch add reserved-vlan <VLAN ID list>
virtual-switch ethernet create vs <vs> vc <Virtual
Circuit Name>
8 Add the members with the encap policy to inherit from the port settings.
virtual-switch ethernet add vs <vs> port <Port list>
encap-cos-policy port-inherit
9 Set the untagged data virtual switch for the member port.
port set port <port> untagged-data-vs <Virtual Switch
Name>
end

Procedure 14-17
Enabling traffic profiling
By default, traffic profiling status is disabled globally and per port. In order to
configure traffic profiling, EIR/PIR, and CIR values must be provisioned.
Step Action
1 Enable traffic profiling:

traffic-profiling enable [<PortNameList>]
where
port is the port that you want to enable traffic profiling on.
<PortNameList>
end

Procedure 14-18
Setting the traffic profiling provisioning mode
Set the provisioning mode. You can set the provisioning mode to
EIR
PIR
Step Action
To set the provisioning mode to EIR

1 Set the provisioning mode to EIR:
To set the provisioning mode to PIR
2 Set the provisioning mode to PIR:
traffic-profiling set meter-provisioning pir
end

Procedure 14-19
Displaying traffic profiling information
You can display:
Status global and port

Per port attributes
Classification mode for all ports
Meter pool assignments for all ports on 3940 and 5140 platforms
Step Action
To display traffic profiling status

1 Display traffic profiling status:
traffic-profiling show
2 Display per port attributes:
traffic-profiling show port <PortName>
where
port <PortName> is the port that you want to display attributes for.
3 Display the classification mode for all ports:

traffic-profiling show classifier-mode
4 Display meter pool assignments for all ports:
end
Example
The following example shows the traffic-profiling status.
+------------ TRAFFIC PROFILING GLOBAL TABLE ---------------+
| Profiling Status | Disabled |
| meter-provisioning | eir |
+-----------------------------------------------------------+
+---------------- PORT TRAFFIC PROFILE TABLE ----------------+

| Port | Status | Mode |
| | Admin | Oper | |
+-----------+----------+----------+--------------------------+
| 1 | Disabled | Disabled | standard-dot1dpri |


+-----------+----------+----------+--------------------------+
The following example shows the traffic profiling per port attributes.
traffic-profiling show port 1

+---------------- TRAFFIC PROFILING TABLE -------------------+
| Port | 1 |
| Profiling Admin State | Disabled |
| Profiling Oper State | Disabled |
| Profiling Mode | standard-dot1dpri |
| Meter Pool | TP-POOL3 |
| Non-Conform Standard Profile | drop |
| ARP Standard Profile | bypass |
| Classification Mode | narrow |
+------------------------------------------------------------+
The following example displays the classification mode for all ports.
traffic-profiling show classifier-mode

+------ TRAFFIC-PROFILING PORT CLASSIFIER MODE -----+
| Port | Port Class Mode |
+----------------+----------------------------------+
| 1 | wide |
| 2 | narrow |
...
+----------------+----------------------------------+

Procedure 14-20
Setting traffic profiling port attributes
Traffic profiling can be configured per port and per EVC with the following
attributes:
arp-standard-profile - Sets whether non-conforming ARP frames are
associated with an existing standard profile or bypass traffic profiling. ARP
frames are treated specially because they are required for IP networks to
function. Dropping ARP frames would result in breaking an IP
network.The default setting is bypass. ARP bypass is only applicable
when the profiling mode is set to either standard-dscp or standard-ip-prec.
meter-pool - A meter pool provides the meter resources for traffic profiles
on 3940 and 5140 platforms. For 3916, 3930, 3931, 3932, 3960, 5142,
5150, and 5160 platforms, the meter-pool attribute does not apply. These
platforms use the global meter pool. The number of supported meters per
meter pool is 64. A single traffic profile consumes 1 meter in the meter
pool, and 2 hardware meter resources. You can change the meter pool for
a given port as long as there are enough resources in the newly assigned
meter pool. A given port can only be assigned to one meter pool. Default
metering pool assignments are shown in Table 14-7.
Note: The number of traffic profiles that can be supported on 3940 and
5140 platforms is less than the number of meters per pool. The actual
number of traffic profiles per metering pool depends upon the number of
ports in the meter pool and the number of classifiers configured per profile.
For additional information regarding traffic profiling resources, see
Hardware resource management on page 5-1.
Table 14-7
Metering pools default port assignment per platform
Platform Meter pool Ports
3940, 5140 TP-POOL1 1, 2, 3
TP-POOL2 4, 5, 6
TP-POOL3 7, 8, 9
TP-POOL4 10, 11, 12
TP-POOL5 13, 14, 15
TP-POOL6 16, 17, 18
TP-POOL7 19, 20, 21
TP-POOL8 22, 23, 24

classifier-mode - The classifier mode determines whether frames that are

to be dropped at ingress are applicable to the meter rates of all traffic
profiles configured against the port. When the mode is set to "narrow,"
traffic profile classification is restricted to only match frames that will not
be dropped at ingress. When the mode is set to "wide", traffic profile
classification is not restricted and may include traffic that is to be dropped
at ingress. The default classifier-mode is narrow.
mode - The mode sets the inspection point for classification:
none - Removes the default classifiers for the port freeing them to
be used by other ports in the same meter pool to use those
resources. Before setting the mode to none, remove any traffic
profiles created for the port. Traffic profiles cannot be created for a
port that is in the none mode. Applicable for 3940 and 5140
platforms. The 3916, 3930, 3931, 3932, 3960, 5142, 5150, and
5160 platforms consume classifiers from the global meter pool.
advanced - Supports EVC based classification, and supports
standard and hierarchical metering simultaneously. Not applicable
for 3940 and 5140 platforms. Note that non-conforming and ARP
profiles are not applicable to a port in advanced mode. Ports in
advanced mode behave like ports in hierarchical-vlan mode.
standard-dot1dpri - Finds a matching traffic profile using 802.1D
priority. This mode is the default.
standard-ip-prec - Finds a matching profiling using the upper 3 bits
of the TOS byte that make up the IP precedence.
standard-dscp - Finds a matching profiling using the DSCP value.
standard-vlan - Finds a matching profiling based upon the VLAN
ID.
standard-vlan-dot1dpri - Finds a matching profiling based upon the
VLAN ID and outer.1D priority value in the frame.
standard-vlan-ip-prec - Finds a matching profiling based upon the
VLAN ID and ip-precedence value in the frame.
standard-vlan-dscp - Finds a matching profiling based upon the
VLAN ID and the DSCP value in the frame.
nonconform-standard-profile - Sets whether non-conforming frames (that
are not ARP) are associated with a standard profile or dropped. Non-
conforming frames are those ingressing frames that do not match one of
the configured per-port traffic profiles. Note that nonconform-standard-
profile does not include untagged frames. For example, non-conforming
802.1D priority frames are those frames that do not have a matching
802.1D priority configured in one of the traffic profiles. The same applies
to DSCP (no matching 6 bit code point), and IP-Precedence (no matching

3 bit IP Precedence value). Note that certain frames, such as ARPs and
non-IP frames, will always be non-conforming because these frames do
not contain the DSCP field. The default setting is drop.
Note: The classifier-mode attribute does not apply to the nonconform-
standard-profile.
Step Action
1 Set the per port attributes:

traffic-profiling set port <PortName> {[arp-standard-
profile <bypass|<Traffic ProfilingStandardName>],
[meter-pool <TpMeterPoolName>], [classifier-mode
<narrow|wide>], [mode <none|advanced|standard-
dot1dpri|standard-ip-prec|standard-dscp|standard-
vlan|standard-vlan-dot1dpri|standard-vlan-ipp|standard-
vlan-dscp|hierarchical-port|hierarchical-vlan],
[nonconform-standard-profile
<drop|<TrafficProfilingStandardName>>]}
end
Example
The following example sets per-port attributes.
traffic-profiling set port 1 arp-standard-profile bypass meter-pool TP-POOL1

mode standard-vlan nonconform-standard-profile drop

Procedure 14-21
Configuring a traffic profiling standard profile
You can perform the following operations on a standard profile:
create
modify
remove classification attributes
delete
If a ports ARP and non-conforming standard profiles are set to the standard
profile to be deleted, set them to the default settings.
Traffic profile remarking policies take precedence over the RCOS->FCOS

map settings configured on the egress port.
Step Action
To create a standard profile

1 Create a standard profile:
traffic-profiling standard-profile create {port <port>}
[profile <NUMBER: 1-4096>] [dot1dpri <NUMBER>] [ip-prec
<NUMBER>] [dscp <NUMBER>] [dscp-remark-policy <leave |
fixed>] [fixed-dscp <NUMBER: 0-63>] {[cir <NUMBER>], [eir
<NUMBER>],[pir <NUMBER>], [cbs <NUMBER: 0-262144>], [ebs
<NUMBER: 0-262144>]} [name <String[15]>] [vlan <VLAN>][vs
<Virtual Switch Ethernet Name>] [statistics <on|off>]
[untagged] [parent <Traffic Profiling Standard Name>]
[child-mode <standard-dot1dpri | standard-ip-prec |
standard-dscp | standard-vlan | vlan-cos>] [default-
profile <true|false>] drop <true | false> [ingress-color-
aware <on|off>] [remark-color-policy <leave|yellow-to-
green|green-to-yellow>] [remark-rcos-policy
<leave|remark-green|remark-yellow|remark-both] [green-
remark-rcos <NUMBER: 0-7>] [yellow-remark-rcos <NUMBER:
0-7>].
where
{port <port>} is the port number.
[profile is the traffic profile number.
<NUMBER: 1-
4096>]
[dot1dpri is the 802.1D priority value of matching frames.
<NUMBER>]

where
[ip-prec is the IP Precedence value of matching frames.
<NUMBER>]
[dscp is the Differentiated Services Code Point (DSCP)
<NUMBER>] value of matching frames.
[dscp-remark- is the DSCP Remark Policy.
policy <leave | leave: leave as is
fixed>]
fixed: IPv4 frames that classify to the traffic profile
have the DSCP value marked with a fixed value,
[fixed-dscp is the value to use when remarking an IPv4 frame for
<NUMBER: 0- a traffic profile with a dscp-remark-policy of fixed.
63>]
{[cir <NUMBER>] is the committed information rate in Kbps of this
traffic meter, rounded to fit hardware.
[eir <NUMBER>] is the excess information rate in Kbps of this traffic
meter, rounded to fit hardware.
[pir <NUMBER>] is the peak information rate in Kbps of this traffic
meter, rounded to fit hardware.
[cbs <#>], is the meter committed burst size in Kbytes,
rounded to nearest size supported in hardware.
[ebs <#>]} is the excess burst size in Kbytes, rounded to
nearest size supported in hardware.
[name is the traffic profile name.
<String[15]>] If you do not specify a name, one is automatically
created for the traffic profile number, that is, STD#1
through STD#32.
[vlan <VLAN>] is the VLAN ID to monitor.
[vs <Virtual classifies the profile based on the Ethernet VS ID.
Switch Ethernet Note that traffic profiles cannot classify to an MPLS
Name>] VS.
[statistics Enable or disable collection of statistics for the traffic
<on|off>] profile
[untagged] Untagged frame classifier
[child-mode is the remarking mode for child profiles. Applicable
<standard- to parent profiles for platforms operating in
dot1dpri| hierarchical-port or hierarchical-vlan mode. Not
standard-ip-prec| applicable for 3940 and 5140.
standard-dscp|
standard-
vlan|vlan-cos>]

where
[default-profile indicates whether the profile is to be a default profile
<true|false>] for metering traffic that does not classify to the
parent or child profiles. Applicable to hierarchical
profiles. Not applicable for 3940 and 5140.
[drop indicates whether the profile automatically drops all
<true|false>] traffic that classifies to this profile.
Note: The very first frame counted in the statistics
on a profile with the drop attribute set may be
counted as forwarded when it is actually dropped
as it takes one frame to move the hardware out of
the previous profile.
[ingress-color- indicates whether the meter is color aware or color
aware <on|off>] blind.
[remark-color- is the meter output color remarking policy. Policies
policy are:
<leave|yellow-to- leave: leaves the R-Color of the frame as it was
green|green-to- classified by the port. This command is useful if the
yellow>] remark-color-policy was changed to yellow-to-
green or green-to-yellow and needs to be changed
back to the default.
yellow-to-green: changes the color of frames that
were classified by the port as yellow to green.
green-to-yellow: changes the color of frames that
were classified by the port as green to yellow.
Note: This attribute cannot be set on hierarchical
parent profiles.

where
[remark-rcos- is the meter output color-based rcos remarking
policy policy.
<leave|remark- Policies are:
green|remark-
yellow|remark- leave: leaves the R-CoS policy without change.
both] This command is useful if the remark-rcos-policy
was changed to remark-green or remark-yellow
and it needs to be changed back to the default.
remark-green: assigns a new R-CoS value to any
packets that are classified as green. The new R-
CoS value is assigned using green-remark-rcos
<NUMBER: 0-7>.
remark-yellow: assigns a new R-CoS value to any
packets that are classified as yellow. The new R-
CoS value is assigned using yellow-remark-rcos
<NUMBER: 0-7>.
remark-both: assigns a new R-CoS value to any
packets that are classified as green and to any
packets that are classified as yellow. The new R-
CoS value for green packets is assigned using
green-remark-rcos <NUMBER: 0-7>. The new r-
cos value for yellow packets is assigned using
yellow-remark-rcos <NUMBER: 0-7>.
Note: This attribute cannot be set on hierarchical
parent profiles.
[green-remark- is the RCOS value for green remarking.
rcos
<NUMBER: 0-7>]
[yellow-remark- is the RCOS value for yellow remarking.
rcos
<NUMBER: 0-7>]
CAUTION
Traffic Disruption Risk
Use caution when enabling the drop attribute when only one profile is present on the
port. When a profile matches remote management traffic, it can cause the device to
become unreachable.
TRAFFIC
To modify a standard profile

2 Modify attributes for a standard profile:
traffic-profiling standard-profile set {port <PortName>}
{profile <ProfileNumber>} {[dot1dpri <NUMBER LIST: 0-7>],
[ip-prec <NUMBER LIST: 0-7>], [dscp <NUMBER LIST: 0-63>],
[dscp-remark-policy <leave | fixed>], [fixed-dscp <0-
63>], [cir <NUMBER>], [pir <NUMBER>], [cbs <#>], [ebs

<#>], [name <TrafficProfilingStandardName[15]>], [vlan

<VLAN>], [vs <VsEth>], [statistics <on|off>] [untagged]
[drop <true|false>] [parent <TrafficProfStd>] [child-mode
<standard-dot1dpri|standard-ip-prec|standard-dscp|..>]
[default-profile <true|false>] [ingress-color-aware
<on|off>] [remark-color-policy <leave|yellow-to-
green|green-to-yellow>] [remark-rcos-policy
<leave|remark-green|remark-yellow|remark-both] [green-
remark-rcos <#>] [yellow-remark-rcos <#>]}
To remove classification attributes for a standard profile
3 Remove classification attributes for a standard profile:
traffic-profiling standard-profile unset {port
<PortNameList>} {profile
<TrafficProfilingStandardName[15]>} [dot1dpri <NUMBER
LIST: 0-7>] [ip-prec <NUMBER LIST: 0-7>] [dscp <NUMBER
LIST: 0-63>] [vlan] [untagged]
To delete a standard profile
4 Delete a standard profile:
traffic-profiling standard-profile delete {port
<PortNameList>} {profile <TrafficProfilingStandardName>}
end
Example
The following example uses EIR mode.

traffic-profiling standard-profile create port 1 name TP1 cir 256 eir 512
dot1dpri 1
The following example uses PIR mode.
traffic-profiling set meter-provisioning pir

traffic-profiling standard-profile create port 1 name TP1 cir 256 pir 768
dot1dpri 1
The following example sets the child mode as part of the parent profile.
traffic-profile standard create port AGGiTest name P1 cir 50048 child-mode

vlan-cos vs VS1
The following example remarks the metered output of a traffic profile.
traffic-profiling standard-profile create port 1 profile 1 remark-color-

policy yellow-to-green
The following example remarks the R-CoS per traffic-profile.
traffic-profiling standard-profile create port 2 profile 2 remark-rcos-policy

remark-green

The following example specifies that a traffic profile is color blind.
traffic-profiling standard-profile create port 1 profile 1 ingress-color-

aware off
The following example sets the .1D priority of matching frames to 1 for traffic
profile 1 on port 1.
traffic-profiling standard-profile set port 1 profile 1 dot1dpri 1
The following example unsets the standard traffic profile attributes.
traffic-profiling standard-profile unset port 1 profile 1 dot1dpri 1
In this example, assume a stream of frames enter the ingress port with a P-bit
value of 3. If no remark-rcos-policy is used, all the frames will have R-CoS
value of 3, so all the frames will be stored in the same egress queue and at
egress port they all will leave with P-bit of 3. To direct the Green frames and
Yellow frames to different egress queues you can use the remark-rcos-policy
to assign different R-CoS values to Yellow frames. But if the default R-CoS to
F-CoS mapping is used, the Yellow frames in the egress port will be assigned
the new P-bit values and will leave the port with the new P-bit value.
The following example assigns all Yellow frames in a port r-cos a value of 1:
traffic-profiling standard-profile set port <port number> profile <profile

name> remark-rcos-policy remark-yellow yellow-remark-rcos 1

Procedure 14-22
Configuring per-port standard traffic profiling
The configuration example in this section shows how to configure per-port
traffic profiling to meter ingress traffic based upon 802.1D priority.
Step Action
1 Enable traffic profiling globally.

2 Enable traffic profiling on port 1.
3 Confirm the global configuration (optional).
4 Set traffic profiling mode on port 1 to standard-dot1dpri (default) and a narrow
classifier-mode.
traffic-profiling set port 1 mode standard-dot1dpri
classifier-mode narrow
5 Confirm the per port configuration for port 1.
6 Create Traffic profile 1 on port 1 with CIR 3,000Kbps and PIR 3,200Kbps,
dot1dpri 0,1,2.
traffic-profiling standard-profile create port 1 profile
1 cir 3000 pir 3200 dot1dpri 0,1,2
dot1dpri 3,4,5.
2 cir 3000 pir 3200 dot1dpri 3,4,5
dot1dpri 6,7.
3 cir 2000 pir 2432 dot1dpri 6,7
9 Create Traffic profile 4 on port 1 with CIR 128Kbps and PIR 256Kbps for
untagged traffic.
4 untagged cir 128 pir 256 untagged
10 Display the traffic profiles associated with port 1 (Optional).
traffic-profiling standard-profile show port 1
end

Procedure 14-23
Configuring per-port and per-VLAN standard traffic
profiling
The configuration example in this section shows how to configure per-port and
per-VLAN traffic profiling to meter ingress traffic based upon VLAN tag. Port
1 is the UNI port and port 9 is the NNI port.
Step Action
1 Enable traffic profiling globally.

2 Enable traffic profiling on UNI port 1.
3 Confirm the global configuration (optional).
4 Set traffic profiling mode on port 1 to standard-vlan and a narrow classifier-
mode.
traffic-profiling set port 1 mode standard-vlan
classifier-mode narrow
5 Confirm the per port configuration for port 1.
6 Create VLAN 1001, 1002, 1003.
vlan create vlan 1001-1003
...This may take a while depending upon the VLAN range...

7 Add port 1 and 9 to VLAN1001, 1002, 1003.
vlan add vlan 1001-1003 port 1,9
...This may take a while depending upon the VLAN range...

8 Confirm the VLAN configuration (optional).
vlan show
9 Create Traffic profile 1 on port 1 with CIR 100 kbps and PIR 1024 Kbps, and
classifier VLAN 1001.
1 cir 100 pir 1024 vlan 1001
2 cir 100 pir 1024 vlan 1002

3 cir 100 pir 1024 vlan 1003
12 Create Traffic profile 4 on port 1 with CIR 128Kbps and PIR 256Kbps for
untagged traffic.
4 untagged cir 128 pir 256 untagged
13 Display the traffic profiles associated with port 1 (Optional).
end

Procedure 14-24
Configuring hierarchical VLAN traffic profiles
In the configuration example for this section, three parent profiles are
configured for three VLANs (2000, 2100, 4000) with different child modes and
profiles for 802.1D, DSCP, and IPP classification.
Step Action
1 Set the port mode to hierarchical VLAN mode.

traffic-profiling set port 6 mode hierarchical-vlan
2 Create the parent profile to classify traffic with VLAN 2000 with a narrow
classifier-mode and specify the child mode to classify based on 802.1D
priority.
traffic-profiling standard-profile create port 6 name
parent1 child-mode standard-dot1dpri cir 50000 cbs 8 vlan
2000 classifier-mode narrow
3 Create the child profile to classify traffic with 802.1D priority values 0 and 1.
child1 parent parent1 dot1dpri 0,1 cir 30000 pir 50000 cbs
4 ebs 2
4 Create the child profile to classify traffic with 802.1D priority values 2.
child2 parent parent1 dot1dpri 2 cir 10000 pir 50000 cbs
4 ebs 2
5 Create a child default under vlan 2000.
traffic-profiling standard-profile create port 6 default-
profile true cir 64 pir 45000 cbs 4 ebs 4 name
vlan2000child parent parent1

Figure 14-5
Hierarchical VLAN with 802.1D priority
802.1D Parent1 Profile

0,1
Child Mode 802.1D
VLAN 2000
802.1D
2
Default
classifier-mode and specify the child mode to classify based on DSCP
priority.
parent2 child-mode standard-dscp cir 50000 cbs 8 vlan 4000
7 Create the child profile to classify traffic with DSCP value 8.
child1dscp parent parent2 dscp 8 cir 20000 pir 50000 cbs
4 ebs 32

4 ebs 16
4 ebs 16
10 Create the child profile to classify and drop untagged traffic.
child4untagged parent parent2 drop true untagged
Figure 14-6
Hierarchical VLAN with DSCP priority
DSCP Parent2 Profile

8
Child Mode DSCP
VLAN 4000
DSCP
16
DSCP
32
Untagged
classifier-mode and specify the child mode to classify based on IP
precedence.
parentIpp child-mode standard-ip-prec cir 50000 cbs 8
vlan 2100

12 Create the child profile to classify traffic with IP precedence value 6.

child1ipp parent parentIpp ip-prec 6 cir 20000 pir 50000
cbs 4 ebs 16
cbs 4 ebs 16
cbs 4 ebs 16
15 Create the child profile to classify and drop untagged traffic.
child4ipp-untagged parent parentIpp drop true untagged
Note: Alternately, an profile can be created at the same level as the parent
to classify untagged traffic.

Figure 14-7
Hierarchical VLAN with IP precedence
IP-Prec Parent3 Profile

6
Child Mode IP Precedence
VLAN 2100
IP-Prec
5
IP-Prec
4
Untagged
16 Create a default profile at the parent level for handling traffic that does not
classify to the parent and child profiles.
traffic-profiling standard-profile create port 6 default-
profile true cir 15000 pir 45000 cbs 8 ebs 8 name
T1default
end

Procedure 14-25
Configuring hierarchical port traffic profiles
In the configuration example for this section, one parent profile with the
802.1D child mode and three child profiles for classification of specific 802.1D
values.
Step Action
1 Set the port mode to hierarchical port mode.

traffic-profiling set port 5 mode hierarchical-port
2 Create the parent profile with a narrow classifier-mode and the child mode to
classify based on 802.1D priority.
portdot1D child-mode standard-dot1dpri cir 50000 cbs 8
childdot1D1 parent portdot1D dot1dpri 6 cir 30000 pir
40000 cbs 4 ebs 2
childdot1D2 parent portdot1D dot1dpri 3 cir 10000 pir
25000 cbs 4 ebs 8
childdot1D3 parent portdot1D dot1dpri 4 cir 9800 pir 9800
cbs 4 ebs 16

Figure 14-8
Hierarchical port with 802.1D priority
802.1D portdot1D Parent Profile

6
Child Mode 802.1D
802.1D
3
802.1D
4

Procedure 14-26
Configuring VS classification for standard traffic
profiles
In the configuration example for this section, profile 1 classifies on all traffic
from port 1 that belongs to VS1 regardless of VLAN or COS. Traffic-profiles
2-4 only classify on traffic ingressing VS2 that have VLAN 2002 and the
respective CoS values provisioned for each profile.
Step Action
1 Create the virtual switches and add them to the respective VLANs.
virtual-switch add reserved-vlan 4091-4093
virtual-switch ethernet create vs VS1
virtual-switch Ethernet add vs VS1 port 1 vlan 1001
2 Enable traffic profiling and set the mode to advanced.
3 Create traffic profile 1 and assign it to VS1, specifying CIR and PIR values.
1 cir 1024 pir 2048 vs VS1
4 Create traffic profiles 2-4 and assign them to VS2, specifying CIR, PIR,
VLAN, and 802.1D values.
2 cir 4096 pir 8192 vs VS2 vlan 2002 dot1dpri 0,1,2,3
3 cir 512 pir 1024 vs VS2 vlan 2002 dot1dpri 4,5
4 cir 2048 pir 2048 vs VS2 vlan 2002 dot1dpri 6,7

Procedure 14-27
Configuring VS classification for HIM traffic profiles
In the configuration example for this section, regardless of the VLAN, any
traffic ingressing VS3 with the specified CoS values is classified/metered.
Step Action
1 Create the virtual switch configuration as described in Procedure 14-26.

2 Enable traffic profiling and set the mode to advanced.
3 Create parent traffic profile Parent1 and assign it to VS3 with child-mode
VLAN-CoS, specifying CIR and PIR values.
Parent1 child-mode vlan-cos cir 50048 vs VS3
4 Create child traffic profiles Child1 and Child2 and assign them to profile
Parent1, specifying CIR, PIR, and DSCP values.
Child1 parent Parent1 cir 1024 pir 2048 dscp 0,1,2,3
Child2 parent Parent1 cir 1024 pir 2048 dscp 4,5
end

Procedure 14-28
Displaying standard traffic profiles
You can display
all standard traffic profiles
standard traffic profiles associated with a specified port
Step Action
To display all standard traffic profiles

1 Display all standard traffic profiles:
traffic-profiling standard-profile show
To display standard traffic profiles associated with a specified port
2 Display standard traffic profiles associated with a specified port:
traffic-profiling standard-profile show [port
<PortName>]>
where
port <PortName> is the port that you want to display associated standard
traffic profiles for.
end
Example
The following example shows sample output for displaying all standard traffic
profiles.
traffic-profiling standard-profile show

+-------------------------------------+- STANDARD PROFILE TABLE------------------------------+
| Port | Profile | |Parent| BW (Kbps) | Max Burst KB | CLASSIFIERS |
| | ID| Name |Role|#Child| CIR | PIR | CBS | EBS | |
+-------+---+---------------+----+------+-------+-------+--------+--------+------------------+
| 1 |1 |STD#1 | N | 0 |128 |128 | 16 | 16 | .1D| 1 |
| | IPP| 1 |
+-------+---+---------------+----+------+-------+-------+--------+--------+------------------+
| 2 |1 |STD#1 | N | 0 |0 |256 | 0 | 16 | |
+-------+---+---------------+----+------+-------+-------+--------+--------+------- ----------+
| 2 |2 |untagged | N | 0 | 128 |256 | 16 | 16 | UT |
+-------+---+---------------+----+------+-------+-------+--------+--------+------------------+

The following example shows sample output for displaying standard profiles
associated with port 1.

+-------------------------------------+- STANDARD PROFILE TABLE------------------------------+
| Port | Profile | |Parent| BW (Kbps) | Max Burst KB | CLASSIFIERS |
| | ID| Name |Role|#Child| CIR | PIR | CBS | EBS | |
+-------+---+---------------+----+------+-------+-------+--------+--------+------------------+
| 1 |1 |STD#1 | N | 0 |128 |128 | 16 | 16 | .1D| 1 |
| | IPP| 1 |
+-------+---+---------------+----+------+-------+-------+--------+--------+------------------+

Procedure 14-29
Clearing statistics for all standard profiles
Statistics count the number of accepted and dropped bytes and packets for
each standard profile.
Note 1: Egress and traffic profile byte statistics show payload bytes
regardless of the frame bandwidth calculation setting described in the
Configuring frame bandwidth calculation procedure.
Note 2: The 3940 and 5140 platforms only support statistics for dropped
bytes and accepted bytes.
Step Action
1 Clear statistics for all standard profiles:

traffic-profiling standard-profile clear statistics
end

Procedure 14-30
Displaying statistics for all standard profiles
Display statistics for all standard profiles.
Step Action
1 Display statistics for all standard profiles:

traffic-profiling standard-profile show statistics
end
Example
The following example shows sample output for displaying statistics for all
standard profiles.
traffic-profiling standard-profile show statistics

+--------------------------------- STANDARD PROFILE TABLE ---------------------------------+
| Port | Profile | Statistics |
| | ID | Name | Type Bytes packets |
+-------+----+--------------------+--------------------------------------------------------+
|1 |1 |p1 | **** Child Profile List **** |
+-------+----+--------------------+---------------------------------+----------------------+
|1 |2 | child1 | Accepted 0 | 0 |
| | | | Dropped 0 | 0 |
+-------+----+--------------------+---------------------------------+----------------------+
| | | | **** Child Profiles Sum **** |
+-------+----+--------------------+---------------------------------+----------------------+
|1 |1 |p1 | Accepted 0 | 0 |
| | | | Dropped 0 | 0 |
+-------+----+--------------------+---------------------------------+----------------------+

Procedure 14-31
Displaying throughput statistics for a traffic profile
Display throughput statistics for a traffic profile to monitor the throughput traffic
profile from the CLI. Throughput statistics are used for troubleshooting.
Step Action
1 Display throughput statistics for a traffic profile:

traffic profiling standard-profile show throughput port
<PortName> traffic-profile <TrafficProfileName>
where
port <PortName> is the port that the traffic profile resides on
traffic-profile is the traffic profile that you want to monitor
<TrafficProfile
Name>
end

Procedure 14-32
Setting the per-port hierarchical traffic-profiling mode
Set the per-port hierarchical traffic-profiling mode.
Step Action
1 Set the per-port hierarchical traffic-profiling mode:

traffic-profiling set port <PortName> mode
<none|advanced|standard-dot1dpri|standard-ip-
prec|standard-dscp|standard-vlan|standard-vlan-
dot1dpri|standard-vlan-ip-prec|standard-vlan-
dscp|hierarchical-port|hierarchical-vlan>
end

Procedure 14-33
Setting the child mode
Set the child mode (child-mode) attribute to determine the classification of
child traffic profiles:
standard-dot1dpri - Finds a matching traffic profile using 802.1D priority.
This mode is the default.
standard-ip-prec - Finds a matching profiling using the upper 3 bits of the
TOS byte that make up the IP precedence.
standard-dscp - Finds a matching profiling using the DSCP value.
standard-vlan - Finds a matching profiling based upon the VLAN ID.
vlan-cos - Finds a matching profiling based upon the VLAN CoS. This child
mode is paired with a parent level EVC(VS) classification and it allows for
child profiles to have a VLAN, a VLAN + CoS, or CoS only, as long as the
child profiles dont overlap classification.
Note: If the parent profile is using a VS classifier, vlan-cos is the only
acceptable child mode, and the traffic profiling mode for the parent port
must be set to advanced.
Step Action
1 Set the child mode:

traffic-profiling standard-profile set {port
<PortNameList>} {profile <TrafficProfStd>} child-mode
<standard-dot1dpri|standard-ip-prec|standard-
dscp|standard-vlan|vlan-cos>
end

Procedure 14-34
Creating an sRED profile
Create an sRED profile.
Step Action
1 Create an sRED profile:

traffic-services queuing congestion-avoidance-profile
create profile <String[15]> [green-threshold <NUMBER: 1-
100>] [green-drop-probability
<100pct|6.25pct|3.125pct|1.5625pct|0.78125pct|0.390625pc
t|0.1953125pct|0.09765625pct>] [yellow-threshold
<NUMBER: 1-100>] [yellow-drop-probability
t|0.1953125pct|0.09765625pct>]]
end
Example
The following example creates an sRED profile.
traffic-services queuing congestion-avoidance-profile create profile green-

yellow-1 green-threshold 100 yellow-threshold 1 yellow-drop-probability
100pct

Procedure 14-35
Modifying an sRED profile
Modify an sRED profile.
Step Action
1 Modify an sRED profile:

set profile <CongestionAvoidanceProfile> {[green-
threshold <NUMBER: 1-100>], [green-drop-probability
t|0.1953125pct|0.09765625pct>], [yellow-threshold
<NUMBER: 1-100>], [yellow-drop-probability
t|0.1953125pct|0.09765625pct>]}
end
Example
The following example modifies an sRED profile.
traffic-services queuing congestion-avoidance-profile set profile green-

yellow-1 green-threshold 90 green-drop-probability 0.1953125pct yellow-
threshold 25

Procedure 14-36
Creating an sWRED profile
Create an sWRED profile.
Step Action
1 Create an sWRED profile:

create profile <String[15]>
[tcp-green-threshold <NUMBER: 1-100>] [tcp-green-upper-
threshold <NUMBER: 1-100>]
[tcp-green-max-drop-probability
<100pct|75pct|50pct|25pct|10pct|9pct|8pct|7pct|6pct|5pct
|4pct|3pct|2pct|1pct|0pct>] [tcp-yellow-threshold
<NUMBER: 1-100>] [tcp-yellow-upper-threshold <NUMBER: 1-
100>] [tcp-yellow-max-drop-probability
|4pct|3pct|2pct|1pct|0pct>] [non-tcp-threshold <NUMBER:
1-100>] [non-tcp-upper-threshold <NUMBER: 1-100>]
[non-tcp-max-drop-probability
|4pct|3pct|2pct|1pct|0pct>]
end
Example
The following example creates an sWRED profile.

yellow-1 tcp-green-upper-threshold 100 tcp-yellow-upper-threshold 1 tcp-
yellow-max-drop-probability 100pct

Procedure 14-37
Modifying an sWRED profile
Modify an sWRED profile.
Step Action
1 Modify an sWRED profile:

set profile <CongestionAvoidanceProfile> [tcp-green-
threshold <NUMBER: 1-100>] [tcp-green-upper-threshold
<NUMBER: 1-100>] [tcp-green-max-drop-probability
|4pct|3pct|2pct|1pct|0pct>] [tcp-yellow-threshold
<NUMBER: 1-100>] [tcp-yellow-upper-threshold <NUMBER: 1-
100>] [tcp-yellow-max-drop-probability
<100pct|75pct|50pct|25pct|10pct|9pct|8pct|7pct|
6pct|5pct|4pct|3pct|2pct|1pct|0pct>] [non-tcp-threshold
<NUMBER: 1-100>] [non-tcp-upper-threshold <NUMBER: 1-
100>][non-tcp-max-drop-probability <100pct|75pct|50pct
|25pct|10pct|9pct|8pct|7pct|6pct|5pct|4pct|3pct|2pct|1pc
t|0pct>]
end
Example
The following example modifies an sWRED profile.

yellow-1 non-tcp-upper-threshold 1 non-tcp-max-drop-probability 100pct

Procedure 14-38
Creating an sWRED profile
Create an sWRED profile.
Step Action
1 Create an sWRED profile:

create profile <String[15]>
[green-lower-threshold <NUMBER: 1-100>] [green-upper-
threshold <NUMBER: 1-100>]
[green-max-drop-probability
<100pct|75pct|50pct|25pct|10pct|9pct|8pct|7pct|6pct
|5pct|4pct|3pct|2pct|1pct|0pct>] [yellow-lower-threshold
<NUMBER: 1-100>] [yellow-upper-threshold <NUMBER: 1-100>]
[yellow-max-drop-probability <100pct|75pct|50pct
|25pct|10pct|9pct|8pct|7pct|6pct|5pct|4pct|3pct|2pct|1pc
t|0pct>]
end
Example
The following example creates an sWRED profile.

yellow-1 green-upper-threshold 100 yellow-upper-threshold 1 yellow-max-drop-
probability 100pct

Procedure 14-39
Modifying an sWRED profile
Modify an sWRED profile.
Step Action
1 Modify an sWRED profile:

set profile <CongestionAvoidanceProfile> [green-lower-
threshold <NUMBER: 1-100>] [green-upper-threshold
<NUMBER: 1-100>] [green-max-drop-probability
<100pct|75pct|50pct|25pct|
10pct|9pct|8pct|7pct|6pct|5pct|4pct|3pct|2pct|1pct|0pct>
] [yellow-lower-threshold <NUMBER: 1-100>] [yellow-upper-
threshold <NUMBER: 1-100>] [yellow-max-drop-probability
|4pct|3pct| 2pct|1pct|0pct>]
end
Example
The following example modifies an sWRED profile.

yellow-1 yellow-upper-threshold 50 yellow-max-drop-probability 100pct

Procedure 14-40
Displaying custom congestion avoidance profiles
You can
display all congestion avoidance profiles
display specific congestion avoidance profiles, including name, ID, type,
thresholds, and drop probability
Step Action
To display all congestion avoidance profiles

1 Display all congestion avoidance profiles:
show
To display a specific congestion avoidance profiles
2 Display a specific congestion avoidance profile:
show profile <CongestionAvoidanceProfile>
where
profile identifies the specific congestion avoidance profile.
<Congestion
AvoidanceProfile>
end
Examples
The following example shows the default sRED congestion avoidance profile.
traffic-services queuing congestion-avoidance-profile show profile

Default-SRED
+------------------ CONGESTION AVOIDANCE PROFILE DATA --------------------+

| |
+------------------------------+------------------------------------------+
| Name | Default-SRED |
| Id | 1 |
| Type | SRED |
+-------------------------------------------------------------------------+
| Green || Yellow |
| Threshold | Drop Probability || Threshold | Drop Probability |
+-----------+----------------------++-----------+-------------------------+
| 75 % |0.09765625pct.(1/1024 || 50 % | 6.25pct.......(1/16) |
+-----------+----------------------++-----------+-------------------------+

The following example shows the default sWRED congestion avoidance

profile on the 3960.
traffic-services queuing congestion-avoidance-profile show profile Default-S-

WRED
+-------------------------------- CONGESTION AVOIDANCE PROFILE DATA ---------------------------------+
| |
+--------------------------------+-------------------------------------------------------------------+
| Name | Default-S-WRED |
| Id | 1 |
| Type | WRED-Simple |
+----------------------------------------------------------------------------------------------------+
| Tcp-Green || Tcp-Yellow || Non-Tcp |
| Lower | Upper | Drop || Lower | Upper | Drop || Lower | Upper | Drop |
| Threshold | Threshold | Prob || Threshold | Threshold | Prob || Threshold | Threshold | Prob |
+-----------+-----------+--------++-----------+--------------------++-----------+-----------+--------+
| 75 | 100 | 0pct || 50 | 100 | 100pct || 75 | 100 | 0pct |
+-----------+-----------+--------++-----------+--------------------++-----------+-----------+--------+
The following example shows the default sWRED congestion avoidance
profile on the 5150.
traffic-services queuing congestion-avoidance-profile show profile Default-S-

WRED
traffic-services queuing congestion-avoidance-profile show
+--------------- CONGESTION AVOIDANCE PROFILE DATA ----------------+

| |
+--------------------------------+---------------------------------+
| Name | Default-S-WRED |
| Id | 1 |
+------------------------------------------------------------------+
| Green || Yellow |
| Lower | Upper | Drop || Lower | Upper | Drop |
| Threshold | Threshold | Prob || Threshold | Threshold | Prob |
+-----------+-----------+--------++-----------+--------------------+
| 75 % | 100 % | 0pct || 50 % | 100 % | 100pct |
| |
+--------------------------------+---------------------------------+
| Name | custom-default |
| Id | 2 |
+------------------------------------------------------------------+
| Green || Yellow |
| Lower | Upper | Drop || Lower | Upper | Drop |
| Threshold | Threshold | Prob || Threshold | Threshold | Prob |
+-----------+-----------+--------++-----------+--------------------+
| 75 % | 100 % | 0pct || 50 % | 100 % | 100pct |
+-----------+-----------+--------++-----------+--------------------+

Procedure 14-41
Updating the congestion avoidance profile for an
egress port queue
The default congestion avoidance profile for egress port queues is to use
Default-SRED or Default-S-WRED, depending upon the platform. After
creating custom congestion avoidance profiles, you can set the egress port
queues to use them. The queue is identified by queue number and egress port
queue group (PortQueueGroup), which is the egress port name.
Step Action
1 Update the congestion avoidance profile for an egress port queue:

traffic-services queuing egress-port-queue-group set
queue <NUMBER: 0-7> port <PortQueueGroup> congestion-
avoidance-profile <CongestionAvoidanceProfileName>
end
Example
The following example updates the congestion avoidance profile for an egress
port queue.
traffic-services queuing egress-port-queue-group set queue 2 port 1

congestion-avoidance-profile green-yellow-1

Procedure 14-42
Clearing the congestion avoidance profile to the
default for an egress port queue
Clear the congestion avoidance profile to the default for an egress port queue.
Step Action
1 Clear the congestion avoidance profile to the default for an egress port queue:
traffic-services queuing egress-port-queue-group unset
queue <NUMBER: 0-7> port <PortQueueGroup> congestion-
avoidance-profile
end
Example
The following example clears the congestion avoidance profile to the default.
traffic-services queuing egress-port-queue-group unset queue 2 port 1

congestion-avoidance-profile

Procedure 14-43
Displaying the congestion avoidance profile for an
egress port queue
Display the congestion avoidance profile for an egress port queue.
Step Action
1 To display the congestion avoidance profile for an egress port queue:

traffic-services queuing egress-port-queue-group show
queue <NUMBER: 0-7> port <PortQueueGroup>
end
Example
Example of sRED:
traffic-services queuing egress-port-queue-group show queue 0 port 1
+-------------------------------- QUEUE DATA -----------------------------+

| |
+-------------------------------+-----------------------------------------+
| Queue Id | 0 |
| Queue Group Name [Port] | 1 |
| Congestion Avoidance Profile | Default-SRED |
+-------------------------------------------------------------------------+
| Scheduler | Size | CIR | CBS | EIR | EBS |
| Pri Idx | Weight | (Pckts) | (Kbps) | (Kbytes) | (Kbps) | (Kbytes) |
+---------+---------+---------+----------+----------+----------+----------+
| 10000 | 20 | 100 | 0 | 0 |1000000 | 256 |
+---------+----------+--------+----------+----------+----------+----------+
Example of sWRED on the 3960:
traffic-services queuing egress-port-queue-group show queue 0 port 1
+-------------------------------- QUEUE DATA -----------------------------+

| |
+-------------------------------+-----------------------------------------+
| Queue Id | 0 |
| Queue Group Name [Port] | 1 |
| Congestion Avoidance Profile | Default-S-WRED |
+-------------------------------------------------------------------------+
+---------+---------+---------+----------+----------+----------+----------+
| 10000 | 20 | 100 | 0 | 0 |1000000 | 256 |
+---------+----------+--------+----------+----------+----------+----------+

Example of sWRED on the 5150:
traffic-services queuing egress-port-queue-group show queue 0 port 1.1
+-------------------------------- QUEUE DATA -----------------------------+

| |
+-------------------------------+-----------------------------------------+
| Queue Id | 0 |
| Queue Group Name [Port] | 1.1 |
| Congestion Avoidance Profile | Default-S-WRED |
+-------------------------------------------------------------------------+
+---------+---------+---------+----------+----------+----------+----------+
| 10000 | 20 | 100 | 0 | 0 |1000000 | 256 |
+---------+----------+--------+----------+----------+----------+----------+

Procedure 14-44
Deleting a custom congestion avoidance profile
Delete custom congestion avoidance profiles that are not in use.
Step Action
1 Delete a congestion avoidance profile:

delete profile <CongestionAvoidanceProfile>
where
profile identifies the congestion avoidance profile to be deleted.
<Congestion
AvoidanceProfile>
end

Procedure 14-45
Renaming custom congestion avoidance profile
You can change the name of a custom congestion avoidance profile.
Step Action
1 Rename a congestion avoidance profile:

rename profile <CongestionAvoidanceProfile> name
<String[15]>
where
profile identifies the congestion avoidance profile to be renamed.
<Congestion
AvoidanceProfile>
name <String[15]> is the new name for the congestion avoidance profile.
end

Procedure 14-46
Changing the algorithm of an egress port scheduler
Change the algorithm of an egress port scheduler.
Note: The wdrr-scheduler-granularity setting can be set with scheduler

algorithms other than WDRR, but does not go into effect until the
scheduler algorithm is changed to WDRR. The default setting is 1600 Kb.
Step Action
1 Change an egress port's scheduler algorithm and granularity for the egress
port queue group:
traffic-services queuing egress-port-queue-group set port
<PortQueueGroup> {[scheduler-algorithm <strict|round-
robin|weighted-deficit-round-robin|weighted-round-
robin>], [wdrr-scheduler-granularity <NUMBER: 50-1600>]}
end
Example
The following example changes an egress port's scheduler algorithm and
granularity for the egress port queue group.
traffic-services queuing egress-port-queue-group set port 9 scheduler-

algorithm weighted-round-robin

Procedure 14-47
Changing the weight of the scheduler for a queue
Change the weight of the scheduler for a queue.
Note: The default weight for CoS Queue 7 is 0, which is serviced in a

strict-priority fashion being the highest priority over all other CoS queues
in the Egress Queue group. Queue 7 is typically reserved for CPU-
Sourced traffic and should not be changed.
Step Action
1 Change a queue's scheduler weight for use with the ports scheduler
algorithm:
queue <NUMBER: 0-7> port <PortQueueGroup> scheduler-
weight <NUMBER: 0-1000>
end
Example
The following example changes a queues scheduler weight.
traffic-services queuing egress-port-queue-group set queue 0 port 9 scheduler-

weight 100

Procedure 14-48
Displaying queue weight and scheduler algorithms
Display queue weight and scheduler algorithms.
Step Action
1 Display queue weight and scheduler algorithms for all or a specific egress
port:
[port <PortQueueGroup>]
where
port <PortQueue is the specific egress port.
Group>
end
Example
The following example displays queue weight and scheduler algorithms.
traffic-services queuing egress-port-queue-group show port 9
+---------------------------- QUEUE GROUP DATA ---------------------------+

| |
+--------------------------------+----------------------------------------+
| Name [Port] | 9 |
| Id | 9 |
| Queue Count | 8 |
| Scheduling Algorithm | weighted-round-robin |
| Shaper Bandwidth (Kbps) | 1000000 |
| Shaper Burst Size (Kb) | 10240 |
+-------------------------------------------------------------------------+
| | Scheduler | Size | CIR | CBS | EIR | EBS |
| Q | Pri Idx | Weight | (Pckts) | (Kbps) | (Kbytes) | (Kbps) | (Kbytes)|
+---+---------+--------+---------+---------+----------+---------+---------+
| 0 | 10000 | 100 | 100 | 0 | 0 | 1000000 | 256 |
| 1 | 20000 | 30 | 100 | 0 | 0 | 1000000 | 256 |
| 2 | 30000 | 40 | 100 | 0 | 0 | 1000000 | 256 |
| 3 | 40000 | 50 | 100 | 0 | 0 | 1000000 | 256 |
| 4 | 50000 | 60 | 100 | 0 | 0 | 1000000 | 256 |
| 5 | 60000 | 70 | 100 | 0 | 0 | 1000000 | 256 |
| 6 | 70000 | 80 | 100 | 0 | 0 | 1000000 | 256 |
| 7 | 80000 | 0 | 100 | 102 | 256 | 1000000 | 256 |
+---+---------+--------+---------+---------+----------+---------+---------+

Procedure 14-49
Configuring egress port and queue shaping
You can set
egress port shaper-rate bandwidth
egress port shaper-rate burst-size
egress shaping parameter for each queue
Table 14-8 lists the steps that the shaper rate increments in based on the burst
size.
Table 14-8
Burst size to shaper-rate increment
Burst size Shaper rate increments in steps of
0 or less than 16 M 64 kbps

Note: 3940 and 5140 switches do not exceed 16
M, and always use this increment.
16 M and less than 32 M 128 kbps
Table 14-9 lists the steps that the CIR and PIR increments in based on the
shaper rate.
Table 14-9
Shaper rate to CIR and PIR increment
Shaper rate CIR and PIR increments in steps of
0 or less than 16.78 Gbps 64 kbps

Note: 3940 and 5140 switches do not
exceed 16 M, and always use this
increment.
16.78 Gbps and less than 33.55 Gbps 128 kbps
33.55 Gbps and less than 40 Gbps 256 kbps

Table 14-10 lists the parameters for individual shaping of queues.
Table 14-10
Parameters for individual shaping of queues
Parameter Description
CIR in Kbps The rate of traffic that can egress from a queue and be
considered guaranteed traffic. The default CIR for
queues 0-6 is 0, queue 7 is 1024. The CIR value ranges
from 0 to 40 Gbps (40000000 Kbps).
CBS in Kbytes The amount of CIR traffic that can burst from a queue
(the CIR bucket size). The default CBS for queues 0-6 is
0, queue 7 is 256. The CBS value ranges from 0 to 256
Mbytes.
EIR in Kbps The rate of traffic that can egress from a queue above
CIR and is considered non-guaranteed traffic. The
default EIR is the same as the administrative port speed.
The EIR value ranges from 0 to 40 Gbps.
EBS in Kbytes The amount of EIR traffic that can egress from a queue
(the EIR bucket size). The default EBS is 256. The EBS
value ranges from 0 to 256 Mbytes.
Note 1: In order for the EBS bucket to be drained, an EIR value must be
set.
Note 2: For 3940 and 5140 switches the sum of the CBS and EBS can be
less than or equal to 16 Mbytes. For 3916, 3930, 3931, 3932, 3960, 5142,
5150, and 5160 switches, the sum of the CBS and EBS can be less than
or equal to 256 Mbytes.
Note 3: Shaper-rates applied at the port level affect all 8 queues in the
egress queue group.
Step Action
To set the egress port shaper-rate bandwidth

1 Set the egress port shaper-rate bandwidth:
<PortQueueGroup> shaper-rate <NUMBER: 0-40000000>
To set the egress port shaper-rate burst-size
2 Set the egress port shaper-rate burst-size:
<PortQueueGroup> burst-size <NUMBER: 4-10240>

To set the egress shaping parameters for each queue

3 Set the egress shaping parameters for each queue:
queue <NUMBER: 0-7> port <PortQueueGroup> cir <NUMBER: 0-
20000000> cbs <NUMBER: 0-512> eir <NUMBER: 0-20000000>
ebs <NUMBER: 0-512>
end
Example
The following example sets the egress port shaper-rate bandwidth.
traffic-services queuing egress-port-queue-group set port 3 shaper-rate 1200
The following example sets the egress port shaper-rate burst-size.
traffic-services queuing egress-port-queue-group set port 3 burst-size 1024
The following example sets the egress shaping parameter per queue.
traffic-services queuing egress-port-queue-group set queue 0 port 9 cir 5000

cbs 5000 eir 4000 ebs 3000

Procedure 14-50
Displaying egress port queue configuration
You can display egress port queue configuration for
all ports
a queue group on a port
a port
Note: Egress and traffic profile byte statistics show payload bytes
Step Action
To display egress port queue configuration for all ports

1 Display egress port queue configuration for all ports:
where
queue <NUMBER: is the queue in the queue group
0-7>
port is the port on which the queue group is instantiated.
<PortQueueGroup>
To display egress port queue configuration for a queue group on a port

2 Display egress port queue configuration for a queue group on a port:
queue <NUMBER: 0-7> port <PortQueueGroup>
To display egress port queue configuration for a port
3 Display egress port queue configuration for a port:
port <PortQueueGroup>
end
Example
aggregation create aggregation agg1
traffic-services queuing egress-port-queue-group show port agg1

+---------------------------- QUEUE GROUP DATA ---------------------------+
| |
+--------------------------------+----------------------------------------+
| Name [Port] | agg1 |
| Id | 2049 |
| Queue Count | 8 |

| Scheduling Algorithm | strict |

| Shaper Bandwidth (Kbps) | 20000000 |
| Shaper Burst Size (Kb) | 10240 |
+-------------------------------------------------------------------------+
| | Scheduler | Size CIR | CBS | EIR | EBS |
| Q | Pri Idx | Weight | (Pckts) | (Kbps) | (Kbytes) | (Kbps) | (Kbytes)|
+---+---------+--------+-------------------+----------+---------+---------+
| 0 | 10000 | 20 | 100 | 0 | 0 | 20000000| 256 |
| 1 | 20000 | 30 | 100 | 0 | 0 | 20000000| 256 |
| 2 | 30000 | 40 | 100 | 0 | 0 | 20000000| 256 |
| 3 | 40000 | 50 | 100 | 0 | 0 | 20000000| 256 |
| 4 | 50000 | 60 | 100 | 0 | 0 | 20000000| 256 |
| 5 | 60000 | 70 | 100 | 0 | 0 | 20000000| 256 |
| 6 | 70000 | 80 | 100 | 0 | 0 | 20000000| 256 |
| 7 | 80000 | 0 | 100 | 1024 | 256 | 20000000| 256 |
|---+---------+--------+---------+---------+----------+---------+---------+

Procedure 14-51
Displaying egress port queue statistics
Statistics count the bytes and packets dropped and transmitted by the egress
port queues.
You can display egress port queue configuration for

all ports
a queue group on a port
a port
Note: Egress and traffic profile byte statistics show payload bytes
Step Action
To display egress port queue statistics for all ports

1 Display egress port queue configuration for all ports:
statistics
where
queue <NUMBER: is the queue in the queue group
0-7>
port is the port on which the queue group is instantiated.
<PortQueueGroup>
To display egress port queue statistics for a queue group on a port

2 Display egress port queue configuration for a queue group on a port:
queue <NUMBER: 0-7> port <PortQueueGroup> statistics
To display egress port queue statistics for a port
3 Display egress port queue configuration for a port:
port <PortQueueGroup> statistics
end

Procedure 14-52
Configuring frame bandwidth calculation
The system supports 20 bytes of IFG that can be considered when calculating
bandwidth for broadcast containment filters and for traffic profiling according
to CIR and PIR settings in a traffic profile for ingress metering and egress
shaping.
Step Action
1 To set the bandwidth calculation mode:

flow bw-calculation-mode set mode <payload | transport>
2 To NOT use IFG in bandwidth calculations:
flow bw-calculation set mode payload
3 To use IFG in bandwidth calculations:
flow bw-calculation set mode transport
Note that when the system is in payload calculation mode, the 20-byte IFG is
not considered in the bandwidth equations. However, the physical port must
still operate according to Ethernet standards and take into account the IFG
when transmitting packets. Therefore, the operator could possibly configure a
CIR sum at a port that would exceed the physical bandwidth of the port due
to the required IFG on the wire. The software does not attempt to adjust
bandwidth or issue user-events when in payload mode. The software
assumes bandwidth to be configured and consumed according to transport
mode.
Bandwidth rates are calculated differently for Layer 1 and Layer 2 packets as
shown in the following:
R1 - Layer 1 rate
R2 - Layer 2 rate
F - Packet frame size
Rate calculation formulas are:

R1 = R2/(F+20) * F
R2 = R1/F * (F+20)


15-1
Multicast services configuration 15-
Multicast services deliver data frames to multiple destinations by means of

frame replications. Frame replications take place in a switch that is directly
connected to a multicast server or indirectly connected to a multicast server
through a router or switch. In multicast services, frame replication can be to
selected members of the flood domain, decided either statically through
channel stream or dynamically using Internet Group Multicast Protocol
(IGMP) snooping. This allows network devices to discern multicast traffic and
act on it according to the local content rules and processes for the platform.
Note: To configure Multicast Services, you need to install the Advanced

Ethernet license key. To obtain the Advanced Ethernet license key, contact
Ciena Sales.
Multicast services in the network comprise the following components:

one or more multicast servers
one or more hosts
routers that replicate the multicast packets at L3 and send to multiple
interfaces
switches at L2 that forward multicast frames to multiple interfaces towards
the hosts, that is, the multicast termination points

15-2 Multicast services configuration
Figure 15-1 shows multicast services in the network.
Figure 15-1
Multicast services in the network
Multicast
Multicast Router
Server
Multicast
Service
Termination
Points
(IP TV, Set-top box)
Routers determine the multicast streams to send to a network interface by

means of IGMP. IGMP is used by IP hosts and multicast routers to establish
and maintain membership in multicast groups.

Table 15-1 lists IGMP messages.
Table 15-1
IGMP messages
Message Description
Report/Join Indicates that a host wants to receive a specific multicast

stream.
Leave Indicates that a host wants to leave a specific multicast

stream.
Query Indicates that an IGMP querier is determining which hosts are

on the interface. An IGMP querier is typically the router.
IGMP limits the multicast streams injected into LANs, but the traffic is flooded
to all LAN segments in the L2 forwarding domain. L2 switches that have IGMP
snooping enabled can establish multicast groups and limit the multicast
streams to be forwarded to only the LAN interfaces that have hosts with
members of the multicast group. The switch establishes the multicast group
filters and statically or dynamically sets up the multicast filters for the groups.
IGMP snooping
The switch maintains a list of multicast groups and a list of member interfaces
for each group. Interfaces are added and removed from the multicast group
based on IGMP join and leave messages received from a port.
The switch periodically updates the multicast group membership list.

Interfaces are removed from the multicast group if a join message is not
received from the interface after a timeout period.
If a multicast packet is received and the destination address is found in the list
of multicast groups, then this packet only egresses the Interfaces that are
members of the group. All other multicast packets flood to all Interfaces.
The switch identifies one Interface as the router port. The selection of the
router Interface is determined by general queries snooped by the switch.
IGMP join and leave messages are filtered by the switch. The switch forwards
the first join message and the last leave message.

Enhanced features
Table 15-2 lists the enhanced features of multicast services that are supported
by 39XX/51XX switches.
Table 15-2
Enhanced features for multicast services
Enhanced feature Description
Proxy reporting The switch replies directly to the router in response to an IGMP query
message. When a query is received, the switch sends IGMP membership
reports (for multicast groups that have at least one downstream host) to the
router based on the list of active multicast groups. The reports are sent to
the router at a constant rate, which reduces the bursting that would
otherwise occur.
This feature is always on when IGMP snooping is enabled.
Proxy query The switch sends the query message to one interface at a time. The delay
between interfaces can be configured by the network operator. The delay
balances the load on the CPU which reduces the channel-change latency.
The router has no knowledge of the delay because the switch implements
proxy reporting.
This feature is always on when IGMP snooping is enabled.
Query engine The network operator configures the switch to generate IGMP query
packets at regular intervals just like a router. Multicast servers can connect
directly to the multicast network without going through routers.
Inquisitive leave This feature supports network configurations that can have multiple IGMP
hosts on a single interface. Two or more hosts are "tuned" into a single
multicast group at the same time on the same interface. If the switch
responds immediately to an IGMP leave message for this group, service to
the other host or hosts tuned into the group is interrupted. The switch sends
one group-specific query to the interface with max-response set to last-
member-query-interval, and a timer is created with the same timeout value.
As soon as an IGMP membership report is received on the port for the
specific group, the timer is canceled. The interface is removed from the
group if the timer expires.
This feature can be enabled on any IGMP snooping-enabled L2 forwarding
domain.

Table 15-2
Enhanced features for multicast services
Enhanced feature Description
Channel stream A channel stream is a collection of user-defined multicast groups. The

switch always subscribes to these groups, even if there are no hosts joining
these groups. This feature can be used to reduce the latency experienced
by the end user by forwarding some multicast streams far down into the
network before they are requested by any IGMP host.
Unknown multicast This feature is used to filter multicast packets with unknown destination
filtering (UMF) addresses. The destination address is considered unknown if it cannot be
found in the list of active multicast groups. UMF can be enabled on any
multicast-enabled VLAN. The system tracks the setting for each L2
forwarding domain and passes this information down to the forward engine.
IGMP forking IGMP forking is the process of forwarding, that is, forking, the individual raw
join and leave messages that ingress the UNI port to the associated
subscriber or data service, that is, VLAN, egressing the NNI ports. These
raw subscriber-associated IGMPv3 and IGMPv2 PDUs provide
opportunities for northbound systems to perform additional statistics
tracking and QoS treatments. IGMP snooping must be enabled for forking
to work. See Configuring IGMP forking with VLAN translation on page
15-18.
Multicast operations
Multicast operations comprise:
Multicast forwarding domains on page 15-5
Multicast interface on page 15-6
Multicast traffic filters on page 15-6
Multicast servers and routers on page 15-7
Server topology on page 15-7
IGMP query engine on page 15-8
Router IP address range on page 15-9
Channel stream on page 15-9
Multicast forwarding domains

39XX/51XX switches use VLANs as the L2 forwarding domain. The
characteristics of the VLAN are combined with the multicast group IP address
to create unique entries in forwarding tables.

Multicast interface
SAOS uses ports as the multicast interface. When the network operator
enables multicast-services on a forwarding domain, all interfaces in the
forwarding domain are treated equally, that is:
multicast streams can ingress any interface and egress on any other
interfaces
all multicast groups in the channel stream egress all interfaces
any interface can become the router interface
The network operator can configure two sets of interfaces:

server interface
channel stream interface
Multicast traffic filters

Multicast features, for example, channel stream and IGMP snooping, are
methods for creating and deleting multicast traffic filters.
Table 15-3 is an example of a multicast traffic filter table. In this example, the
L2 forwarding domain has a total of eight interfaces which are numbered 1 to
8. There are two VLANs on the switch: VLAN-1 and VLAN-2. Interfaces can
belong to more than one VLAN. Also note that each entry in the table is
uniquely identified by a key which comprises the VLAN and multicast
destination IP address.
Note: Multicast addresses are specified as Layer 3 IP addresses.
Table 15-3
Example of a multicast traffic filter table
Interface VLAN Destination Egress Notes

(key) address (key) interface list
1 1 225.0.2.1 1,2,3,4 This is the typical multicast group entry.
2 2 225.0.2.1 5,7 This entry has the same destination address as

entry 1 but has a different VID and egress
interface list. This filter only affects the traffic on
VID 2.
3 1 225.0.2.2 6 This entry is a multicast group with a single

egress interface.
4 1 225.0.2.3 none This entry is a multicast group with no member

interfaces. This group could be in the linger
state.

Table 15-3
Example of a multicast traffic filter table
Interface VLAN Destination Egress Notes

(key) address (key) interface list
5 1 225.0.2.1 1,2,3,4,6,8 This entry is a channel stream group. Interface

5 is excluded from channel stream.
6 1 225.0.2.2 1,2,3,4,6,8 This entry is another channel stream group. All

channel-stream groups have the same egress
interface list.
8 1 Range: none This entry is the UMF filter. The destination

225.0.2.0 to address is the complete range of multicast
225.0.2.255 addresses. This entry is the last entry in the
table. It is the default entry when no other match
is found in the table.
Multicast servers and routers

A multicast server is considered to be any network device that forwards
multicast packets in the network. A multicast router is a special type of
multicast server. Routers are generally L3 (or better) devices running IGMP
and generating IGMP query messages. Any number of multicast servers can
be used on a forwarding domain at the same time, but only one device can act
as the IGMP query engine at any given time.
Server topology
Table 15-4 lists multicast delivery models for multicast services delivered over
L2 networks.
Table 15-4
Multicast delivery models for multicast services delivered over L2 networks
Multicast delivery mode Description
One-to-many One server sends multicast streams to many hosts on

the network. Membership reports are sent to a single
server interface. Example: IPTV.
This is a centralized delivery model.
Many-to-many Many servers send multicast streams to many hosts.

Membership reports are sent to all server interfaces in
the network. Example: Video conference.
This is a distributed delivery model.
Many-to-one Many servers send multicast stream to one host.

Membership reports are sent to all server interfaces in
the network. Example: surveillance.
This is a special case of many-to-many.

In the centralized server topology, all multicast services are delivered from one
L2 device to the rest of the network. Any number of multicast servers can be
used, but all multicast streams must flow downstream from one central point
and all membership reports flow upstream to this central point.
In the distributed server topology any number of multicast servers on the

network can interface with any device on the network.
Table 15-5 describes IGMP behavior for sever topologies.
Table 15-5
IGMP behavior for server topology
IGMP function Centralized Distributed
Receive General Query Reply to the router. Reply to the router.

Send membership reports for all Only send membership reports
active multicast groups. for channel stream groups.
Send Report (join/leave) Send to the router interface only. Send to all server and router
interfaces.
IGMP query engine

In a traditional multicast environment, all requests and queries are processed
through a multicast router. Typically, these routers are overburdened with
processing requirements and thus cannot respond as quickly as needed in a
converged service network. To eliminate the need for a separate IGMP router
and speed up multicast response times, the network operator can configure
service delivery switches to use a built-in IGMP query engine.
When the query engine is disabled, the switch does not send any query
message until the router port is learned. Once the router port is learned, the
switch continues to send query messages until a timeout occurs while waiting
for another query from the router. The router port is learned by snooping IGMP
query messages sent by the router. The switch saves the source IP address
and source MAC address of the router and uses this address whenever the
switch needs to send a query message to the network.
When the query engine is enabled, the switch uses the IP source address
configured by the user whenever it needs to send a query message to the
network. The switch starts sending general queries as soon as query-engine
and igmp-snooping are both enabled and they continue until the configuration
is changed. In this mode, the switch does not respond to a query received
from another device on the network unless that device has a lower IP address.

If you enable query-engine on two or more devices on the same network, both
devices send queries to the network but only one device, that is, the one with
the lower IP address, receives replies.
Note: When the server topology is set to centralized, only one switch on
the network can act as the master querier and all multicast servers must
interface directly with the master querier.
Router IP address range

39XX/51XX switches support a network that has two or more active multicast
servers operating at the same time on the same forwarding domain. The
network operator defines a separate range of multicast addresses for each
server.
The network operator can define a single range of multicast addresses for the
router. If the network operator defines this address range, the switch does not
send a membership report to the router for any multicast group that does not
fall inside this address range. If the network operator does not define this
address range, the switch forwards all membership reports to the router
regardless of the group address.
When two or more routers are used on the same network, that is, the server-
topology attribute is set to distributed, the router address range must remain
undefined so that all join messages are forwarded to all routers.
Channel stream
Any network running IGMP is bound to experience a certain amount of latency
between the IGMP join message and the arrival of the multicast group itself.
Channel stream reduces this latency and reduces the processing load on the
router. Channel stream defines a set of multicast groups that are flooded to all
interfaces in the forwarding domain, which brings multicast services far down
into the network, that is, closer to the subscriber, before any host joins the
groups. Latency is reduced because the IGMP join message does not need
to propagate all the way to the router. If channel stream is configured such that
multicast groups flow all the way to the switch, then the switch is the only
device that must process the join message in order to forward the multicast
group to the subscriber.
The channel stream must be configured before any multicast groups flow.
When multicast services are enabled for a particular forwarding domain, a
new channel stream is created for that forwarding domain. Multicast groups
can be added or removed from this channel stream at any time. As multicast
groups are added to the channel stream, they immediately begin to flow to all
interfaces in the forwarding domain.

The network operator can define a list of channel-stream interfaces. By

default, all interfaces in the forwarding domain belong to the channel stream
interface list. The network operator can remove any interface from this list.
Channel stream should be used with UMF. If a multicast stream arrives at the
switch before the multicast group is added to channel stream, the switch
floods or drops the stream depending on the setting for UMF. After the group
is added to channel stream, the group floods to all channel stream interfaces
regardless of the UMF setting. Therefore, UMF should be set to drop on the
channel stream device and all downstream devices.
Channel stream can be used with or without IGMP snooping. In most cases,
snooping should be enabled when channel stream is used, but it is not
required to do so. If multicast services originate from a router, then IGMP
snooping must be enabled in order for the switch to send IGMP membership
reports to the router. However, channel stream could be used in conjunction
with UMF as a way to selectively forward a subset of the multicast groups from
a multicast server to the rest of the network without IGMP snooping.
If a multicast group is added to channel stream and the source of the multicast
stream is the router, then the switch becomes a member of the multicast
group, and it behaves just like any other group member. The switch
immediately sends an IGMP join message to the router for this new multicast
group, and it responds to IGMP queries as long as the multicast group is a
member of channel stream. The switch forwards the multicast group to all
channel stream interfaces. Therefore, any IGMP membership reports
received by the switch from downstream devices are dropped.
The switch does not disrupt service to downstream devices when a multicast
group is added or removed from channel stream. If a multicast group is
already active on the switch when the group is added to channel stream, the
switch adds more interfaces to the multicast group. Similarly, when a multicast
group is removed from channel stream, the switch continues to flow the
multicast group to all interfaces that subscribe to the group. The switch does
not keep track of group membership while the group is part of channel stream.
When the group is removed from channel stream, the switch sends a group-
specific query to all interfaces in the network in order to determine the group
membership. If no hosts respond to the query within the timeout, the group
goes into the linger state.
It is not necessary to define the source interface for channel stream. It is also
not necessary for all groups in the channel stream to have the same source
interface. Some streams could ingress from a router while others ingress
directly from a video server. The switch sends join messages to the router for

all multicast groups in the channel stream whose group address falls in the
range reserved for the router, that is, the switch sends IGMP join messages to
the router as if the switch was an IGMP host.
Statistics
The switch keeps IGMP statistics. Table 15-6 lists the statistics collected for
each forwarding domain.
Table 15-6
Statistics collected for each forwarding domain
Statistic Description
Membership Number of reports transmitted out to the router.

Reports
Leave Reports Number of leave messages received, with and without errors.
Queries Received Number of query messages received, with and without errors.
Query Discard Number of query messages discarded: query packet received

on non-server interface; query packet received before the
reply to the last query is finished.
Router Timeouts Number of times the router times out without sending a query.
Query Reply Number of timeouts that occurred while sending membership

Timeouts reports to the router (error).
Router Discards Number of invalid IGMP frames from the router that have been
discarded, for example, join message.
Host Discards Number of join and leave messages from hosts that have
been discarded, including:
snooping disabled
invalid multicast group address
ingress interface was the router interface (centralized mode
only)
group is not active (leave packet only)
ingress interface does not belong to the forwarding domain
state of the ingress interface is not forwarding
Checksum Errors Number of IP packet checksum errors.
L2/L3 Mismatch Number of mismatches of L2/L3 mismatch. L2 destination

address is not equal to the group query and the IGMP group
address is equal to 0.0.0.0.
Unknown Packet Number of IGMP packets received that are of type unknown.
Type

Table 15-6
Statistics collected for each forwarding domain
Statistic Description
Exceeded Number of times a join message is received but the system

Resources cannot allocate a new group due to resource limitation.
Query Discarded Number of queries discarded because rapid recovery mode is

off.
Protocol Version The PDU version did not match the configured settings.
Discards

Multicast-services attributes
Table 15-7 lists multicast-services attributes.
Table 15-7
Attribute Default value Description
active-linger-timeout 30 Specifies how long the group should stay in the active state
<SECONDS: 0- after all members leave the group.
300> Note: This attribute is ignored in distributed mode.
compatibility-mode v2 Specifies the protocol compatibility mode.

<v2|v3>
default-router-port 0 Specifies the default router port to use if the actual router
<Port> port is not known.
Note: This attribute is not used in distributed mode.
fork <on|off> off Indicates whether to fork IGMP frames.
last-member-query- 10 Specifies the maximum response time inserted into G-S

interval queries sent in response to leave messages. Also the
<DECISECONDS: amount of time between G-S queries.
10-100> Note: This attribute is Ignored when inquisitive-leave is
disabled.
leave-mode <fast | fast Specifies how to handle leave messages.

inquisitive>
linger-timeout 125 Specifies the linger timer, which starts when a leave
<SECONDS: 10- message is sent to the router. The multicast filter is deleted
300> when the timer expires.
min-response-time 50 Specifies the value that the switch will use if the max-
<DECISECONDS: response-time in the query packet from the router falls
50-600> below this value.
server-topology centralized Specifies whether the server topology is centralized or

<centralized | distributed.
distributed>
priority <NUMBER: 7 Specifies the priority tag inserted into all IGMP messages.
0-7>
query-delay 10 Specifies how long to wait after sending a query before

<DECISECONDS: sending the next. The delay should be greater than the
1-100> query-response-interval.
query-engine <on | off Specifies whether the query engine is on or off.

off>

Table 15-7
Attribute Default value Description
query-interval 125 Specifies how often to send the general query.

<SECONDS: 10-
999999>
query-ip-source- 0.0.0.0 Specifies the source address used for all general queries
addr <IP address> sent on an L2 forwarding domain.
Note: This attribute is ignored when query-engine is
disabled.
query-response- 50 Specifies the amount of time to wait for a reply to the

interval general query. This value goes directly into the query
<DECISECONDS: packet. This interval should be shorter than query-delay.
10-255>
rapid-recovery- off Specifies whether rapid recovery mode is on or off.

mode <on | off>
robustness 1 Specifies the number of query replies (IGMP Join) or

<NUMBER: 1-2> Leaves to send for each multicast group.
router-address- undefined, that is, Specifies the range of IP addresses reserved for the router.
range <IP multicast 0.0.0.0 This setting should remain undefined when the server-
address range> topology is set to distributed. Valid range is 224.0.0.3 -
239.255.255.255.
router-query-interval 125 Used for selecting the IGMP querier when two or more
<SECONDS: 10- routers exist on the same network.
999999>
This chapter provides the following procedures for configuring multicast

services:
Configuring a VLAN as a multicast L2 forwarding domain on page 15-15
Configuring channel streams on page 15-16
Configuring IGMP forking with VLAN translation on page 15-18
Configuring a multicast router topology on page 15-20
Configuring a multicast server topology on page 15-23
Configuring multicast servers with redundant routers on page 15-27
Configuring redundant query engines on page 15-32
Clearing multicast service statistics on page 15-36
Displaying multicast services information on page 15-37

Procedure 15-1
Configuring a VLAN as a multicast L2 forwarding
domain
Configure a VLAN to act as a multicast L2 forwarding domain for multicast
services.
Step Action
1 Enable multicast services:

multicast-services enable
2 Enable multicast services on the switch:
multicast-services igmp-snooping enable
3 Set attributes for the VLAN acting as a multicast L2 forwarding domain:
multicast-services igmp-snooping set vlan <vlan> {active-
linger-timeout <SECONDS: 0-300>} {compatibility-mode
<v2|v3>} {default-router-port <Port>} {fork <on|off>}
{last-member-query-interval <DECISECONDS: 10..100>}
{leave-mode <fast|inquisitive>} {linger-timeout
<SECONDS: 10-300>} {min-response-time <DECISECONDS:
50..600>} {server-topology <centralized|distributed>}
{priority <NUMBER: 0-7>} {query-delay <DECISECONDS:
1..100>} {query-engine <on|off>} {query-interval
<SECONDS: 10-999999>} {query-ip-source-addr <IP address>}
{query-response-interval <DECISECONDS: 10..255>} {rapid-
recovery-mode <on|off>} {robustness <NUMBER: 1-2>}
{router-address-range <IP multicast address range>}
{router-query-interval <SECONDS: 10-999999>}
To add server ports to the multicast L2 forwarding domain
4 Add server ports to the multicast L2 forwarding domain:
multicast-services server-port add vlan <vlan> [port
<Port list>]
end

Procedure 15-2
Configuring channel streams
Configure a channel stream to define a set of multicast groups that are flooded
to all interfaces in the forwarding domain.
When multicast services are enabled for a particular forwarding domain, a

new and empty channel stream is created for that forwarding domain.
Multicast groups can be added or removed from this channel stream at any
time. As multicast groups are added to the channel stream, they immediately
begin to flow to all interfaces in the forwarding domain. Configured channel
streams are saved in the system configuration.
You can:
add a multicast group to a channel stream
remove a multicast group fro a channel stream
exclude a port from a channel stream
include a port in a channel stream
Step Action
To add a multicast group to a channel stream

1 Add a multicast group to a channel stream:
multicast-services channel-stream add vlan <vlan> {group-
address <IP multicast address range>}
where
vlan <vlan> is the VLAN to add the multicast group for.
group-address is the IP multicast address or addresses for the multicast
<IP multicast group.
address range>
To remove a multicast group from a channel stream

2 Remove a multicast group from a channel stream:
multicast-services channel-stream remove vlan <vlan>
{group-address <IP multicast address range>}
where
vlan <vlan> is the VLAN to remove the channel stream group from.
group-address is the IP multicast address or addresses for the channel
<IP multicast stream group.
address range>

To exclude a port from a channel stream

3 Exclude a port from a channel stream:
multicast-services channel-stream exclude vlan <vlan>
{port <Port list>}
where
vlan <vlan> is the VLAN.
port <Port list> is the port or ports to exclude.
To include a port in a channel stream

4 Include a port in a channel stream:
multicast-services channel-stream include vlan <vlan>
{port <Port list>}
where
vlan <vlan> is the VLAN.
port <Port list> is the port or ports to include.
end

Procedure 15-3
Configuring IGMP forking with VLAN translation
To configure IGMP forking with VLAN translation, IGMP snooping must be
enabled.
Step Action
1 Enable IGMP snooping:

2 Create a multicast VLAN:
vlan create vlan {vlan <VLAN>}
3 Add a host port:
vlan add vlan {vlan <VLAN>}{port <Port>}
4 Add a router port:
vlan add vlan {vlan <VLAN>} {port <Port>}
5 Create a multicast service:
multicast-services create vlan {vlan <VLAN>}
6 Turn IGMP forking on:
multicast-services igmp-snooping set vlan {vlan <VLAN>}
fork on
7 Create the upstream data vlan:
vlan create vlan {vlan <VLAN>}
8 Add the upstream data VLAN to the host and router port:
9 Configure VLAN translation to the host port:
vlan translate add {port <Port>} [vid <NUMBER: 0-4095>]
vlan {vlan <VLAN>}
end
Example
The following example shows IGMP forking with VLAN translation. This
example assumes that your multicast service is on vlan 100 and the upstream
data vlan is 101.

multicast-services create vlan 100
multicast-services igmp-snooping set vlan 100 fork on



Procedure 15-4
Configuring a multicast router topology
Configure devices in a network where a multicast server is delivering services
over the network by means of a multicast router, where the router is also the
querier and controls the delivery of multicast streams.
In this example, multicast services are delivered on VLAN 300.

Figure 15-2
Multicast services with a multicast router
Multicast
Server Router
Set Top Box
Device 1
Device 2 Device 4
Device 3
Set Top Box Set Top Box
The default value for the query-ip-source-address is 0.0.0.0. This value is

used as the source address for all query messages as well as for proxy-reply
messages sent to the router. The default value works in most cases. However,

if this address must be changed because of a router on the network, make

sure to use the correct address for the router interface you are using,
otherwise, the router may discard all proxy-reply messages from the device.
Step Action
1 Create a multicast entry for the VLAN on all devices, which enables multicast
services for the specified VLAN:
multicast-services create vlan <VlanList>
2 Set attributes for igmp-snooping. Note that query timers must be set to the
same values as on the multicast router:
4 To enable UMF on the specified VLAN for the devices that have subscriber
equipment connected to them (in our example, device 2 and 3), enter the
following command:
multicast-services umf drop
In this scenario, UMF blocks multicast streams originating from subscriber
equipment or other locations in the network. It also ensures the subscriber
devices receive only the multicast streams they have joined.
5 To verify the IGMP settings, enter the following command:
multicast-services show configuration
end
Example
The following example configures device 2 as seen in Figure 15-2.

multicast-services igmp-snooping set vlan 300 active-linger-
timeout 30 compatibility-mode v2 default-router-port 0 fork off
last-member-query-interval 10 leave-mode fast linger-timeout

125 min-response-time 50 server-topology centralized priority 7

query-delay 10 query-engine off query-interval 125 query-ip-
source-addr 0.0.0.0 query-response-interval 100 rapid-recovery-
mode off robustness 1 router-address-range 0.0.0.0 router-
query-interval 125
multicast-services umf drop vlan 300
multicast-services show configuration vlan 300
+-----------------------------------------------------------------------+
| Multicast-Services: Global Enable |
| IGMP-Snooping: Global Enable |
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+
| MULTICAST CONFIGURATION VLAN 300 VLAN#300 |
+-------------------------------------------------+---------------------+
| Multicast Services Admin State | enable |
| UMF | drop |
| WKM Forwarding | Disabled |
+-------------------------------------------------+---------------------+
| IGMP CONFIGURATION (general) |
+-------------------------------------------------+---------------------+
| IGMP Snooping Admin State | enable |
| IGMP Forking | off |
| IGMP Server Topology | centralized |
| IGMP Query Engine | off |
| IGMP Leave Mode | fast |
| IGMP Compatibility Mode | v2 |
| L2 Packet Priority | 7 |
| Robustness | 2 |
+-------------------------------------------------+---------------------+
| IGMP CONFIGURATION (proxy query) |
+-------------------------------------------------+---------------------+
| Proxy Query Interval (s) | 125 |
| Proxy Query Response Interval (ds) | 100 |
| Proxy Query Delay (ds) | 10 |
| Proxy Query Source Address | 0.0.0.0 |
| Last Member Query Interval (ds) | 10 |
+-------------------------------------------------+---------------------+
| IGMP CONFIGURATION (router) |
+-------------------------------------------------+---------------------+
| Router Query Interval (s) | 250 |
| Linger Timeout (s) | 120 |
| Active Linger Timeout (s) | 30 |
| Minimum Query Response Interval (ds) | 50 |
| Group Address Range (start) | 0.0.0.0 |
| Group Address Range (end) | 0.0.0.0 |
| Default Router Port | 0 |
| Rapid Query Mode | Off |
+-------------------------------------------------+---------------------+

Procedure 15-5
Configuring a multicast server topology
Configure devices in a network that does not employ a multicast router. The
multicast server floods a set of multicast streams on the network. The device
connected to the multicast server is configured to contain the multicast
streams and to act as the querier (Query Engine enabled) for downstream
devices.
For this example, multicast services are delivered on VLAN 300. In the
topology represented in Figure 15-3, UMF is required on device 1 to contain
the streams being flooded by the multicast server. On all other devices, UMF
is optional.

Figure 15-3
Delivering multicast services using the query engine
Multicast
Server
Set Top Box
Device 1
Device 2 Device 4
Device 3
Step Action
1 Create a multicast entry for the VLAN on all devices:

This enables multicast services for the specified VLAN.
2 Configure the query engine on the same device:


1..100>} query-engine on {query-interval <SECONDS: 10-
999999>} query-ip-source-addr 10.10.10.10 {query-
response-interval <DECISECONDS: 10..255>} {rapid-
4 To enable UMF on the specified VLAN for the devices that have subscriber
equipment connected to them (in our example, device 2 and 3), enter the
following command:
multicast-services umf drop vlan <VlanList>
5 To verify the IGMP settings, enter the following command:
end
Example
The following example configures device 1 as shown in Figure 15-3.

query-delay 10 query-engine on query-interval 125 query-ip-
source-addr 10.10.10.10 query-response-interval 100 rapid-
recovery-mode off robustness 1 router-address-range 0.0.0.0
router-query-interval 125
+-----------------------------------------------------------------------+
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+
| UMF | drop |
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+


| IGMP Query Engine | on |
| Robustness | 2 |
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+

Procedure 15-6
Configuring multicast servers with redundant routers
Configure devices in a network that has two or more redundant multicast
servers. Both multicast servers are connected to the network by means of a
multicast router. In this scenario, only one router, with its associated multicast
server, is active at a time. The second router and server are in a standby
mode. The active server is determined by identifying the router that has the
lowest IP address. This router handles general queries and authorizes the
delivery of various streams through the network.
Figure 15-4 shows a sample network topology for delivering multicast services
using redundant multicast routers.

Figure 15-4
Delivering multicast services using redundant multicast routers
Multicast Router 1 Multicast
Server 1 Server 2
Set Top Box Router 2

Device 1
Device 2
Device 4
Device 3
In response to a topology change, for example, if the link that has the router
port for the device goes down, the device will advertise a router address of
0.0.0.0 to indicate that it has lost the router. For example, assuming that router
1 has a lower IP address than Router 2, if the link between device 1 and
Router 1 goes down, devices 1, 2, 3 and 4 will send out general queries
advertising a router address of 0.0.0.0. Device 4 will become the interface for
multicast services and all joins/leaves will then be sent to it. However, when
Router 1 is restored, it will again become the primary router and Router 2 will
again go into standby mode.

This allows the network to continue delivery of multicast services while

ensuring the least delay in service possible. This also allows order to be
maintained between the two multicast routers, so that there is no competition
or confusion.
In this example, multicast services are assumed to be delivered on VLAN 300.

For the network represented in Figure 15-4, UMF is required on device 1 and
device 2. On all other devices, it is optional.
The default value for the query-ip-source-address is 0.0.0.0. This value is

used as the source address for all query messages as well as for proxy-reply
messages sent to the router. The default value should work in most cases.
However, if this address must be changed because of a router on the network,
make sure to use the correct address for the router interface you are using,
otherwise, the router may discard all proxy-reply messages from the device.
Step Action
1 Create a multicast entry for the VLAN on all devices:

2 Enable UMF on device 1 and device 4. (Optional) Enable UMF on the
specified VLAN for the devices that have subscriber equipment connected to
them (in our example, device 2 and 3).
3 Set attributes for igmp-snooping. Note that query timers must be set to the
same values as on the multicast router:
4 Enable IGMP snooping on all four devices.

5 (Optional) Verify the IGMP settings.

end
Example
The following example configures device 1 as shown in Figure 15-4. Note that
device 1 and device 4 have the same configuration.

query-delay 10 query-engine off query-interval 125 query-ip-
source-addr 0.0.0.0 query-response-interval 100 rapid-recovery-
mode off robustness 1 router-address-range 0.0.0.0 router-
query-interval 125
+-----------------------------------------------------------------------+
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+
| UMF | drop |
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+
| IGMP Query Engine | off |
| Robustness | 2 |
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+


+-------------------------------------------------+---------------------+

Procedure 15-7
Configuring redundant query engines
This example demonstrates how to configure devices in a network that has
redundant links between the multicast server and the rest of the network.
Figure 15-5
IGMP Snooping
Multicast
Set Top Box Server
Device 3
Device 1
Device 2
In this scenario, the query engine must be enabled on device 1 and device 3,
but only one query engine is active at a time. The second query engine is in
standby mode. The active query engine is determined by identifying the
engine with the lowest source IP address. This query engine then handles
general queries and authorizes the delivery of various streams through the
network.
In response to a topology change, for example, if the link that has the router
port for a device goes down, the device advertises a router address of 0.0.0.0
to indicate that it has lost the router.

For example, assuming that device 1 has a lower source IP address than
device 3, if the link between device 1 and the multicast server goes down,
devices 1, 2, and 3 send out general queries advertising a router address of
0.0.0.0. Device 3 then becomes the interface for multicast services and all join
and leave messages are sent to it. However, when the link between device 1
and the multicast server is restored, device 1 becomes the primary query
engine, and device 3 returns to standby mode.
This allows the network to continue delivery of multicast services while

ensuring the least delay in service possible. This also allows order to be
maintained between the two query engines, so that there is no competition or
confusion.
For the network represented in Figure 15-5, multicast services are assumed
to be delivered on VLAN 300. UMF is required on device 1 and device 3. On
all other devices, it is optional. The network is using RSTP.
Step Action
1 Create a multicast entry for the VLANs:

2 Configure the query engine on devices 1 and 3:
When using this command, the source IP address must come before the
Query Engine is enabled, in order to function properly. In addition, the router
port must be set to 0 (unlearned).
Make sure that the source IP address for the two devices is different and that
the device that should become the primary query engine has a lower IP
address.
3 Enable IGMP snooping on devices 1, 2, and 3:

4 Enable UMF on devices that have subscriber equipment connected to them:

5 (Optional) Verify the IGMP settings.
end
Example
The following example configures device 1 as shown in Figure 15-3. Note that
with the exception of the query engine source IP address, the configuration for
device 1 and device 3 is the same.

query-delay 10 query-engine on query-interval 125 query-ip-
source-addr 10.10.10.10 query-response-interval 100 rapid-
recovery-mode off robustness 1 router-address-range 0.0.0.0
router-query-interval 125
+-----------------------------------------------------------------------+
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+
| UMF | drop |
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+
| IGMP Query Engine | on |
| Robustness | 2 |
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+


+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+
+-------------------------------------------------+---------------------+

Procedure 15-8
Clearing multicast service statistics
You can clear:
multicast services statistics
multicast services statistics by VLAN
Step Action
To clear multicast services statistics

1 Clear multicast services statistics
multicast-services clear {statistics}
To clear multicast services statistics by VLAN
2 Clear multicast services statistics by VLAN
multicast-services clear vlan <vlan> {statistics}
end

Procedure 15-9
Displaying multicast services information
Display multicast services information to verify the configuration.
You can display:

a brief summary of multicast configuration and status
all configuration settings
all configuration and status
group status
active multicast groups
all configuration settings
Step Action
To display a brief summary of multicast configuration and status

1 Display a brief summary of multicast configuration and status:
multicast-services show brief
To display all configuration settings
2 Display all configuration settings:
multicast-services show configuration {vlan <VLAN list>}
To display all configuration and status
3 Display all configuration and status:
multicast-services show everything {vlan <VLAN list>}
To display group status
4 Display group status:
multicast-services show group-status {vlan <VLAN
list>}{group-address <IP multicast address range>}
To display all active multicast groups
5 Display all active multicast groups:
multicast-services show groups {vlan <VLAN list>} {port
<Port list>}
To display all configuration settings
6 Display all configuration settings:
multicast-services show status {vlan <VLAN list>}
end


16-1
PWE services configuration 16-
Pseudowire Emulation (PWE) services convert standard Time Division

Multiplexing (TDM) streams into Ethernet packets using pseudowire
technology. PWE services are provided by the 3932 platform.
There are three aspects to PWE services:

TDM services
encapsulation
transport
Note: Some encapsulations cannot be used with some transport options

in the SAOS software. For example, MEF8 encapsulation cannot be used
with MPLS transport.
PWE services work with SAOS software to provide the following TDM
services:
Structure-Agnostic TDM over Packet (SAToP)
Circuit Emulation Services over Packet Switched Networks (CESoP)
SAToP TDM pseudowire takes the raw TDM bit-stream from T1 or E1,
disregards any TDM structure imposed on it, prepends the pseudowire header
and dispatches the resulting packet stream over the Ethernet or MPLS PSN.
At the remote end, the pseudowire header information is used to identify the
egress attachment circuit. The TDM payload from the pseudowire is played
out over the egress attachment circuit using the clock information as defined
when the pseudowire is configured.
With CESoP, structured TDM signals are encapsulated in a pseudowire and

sent across the PSN. Advantages of CESoP are:
PSN bandwidth savings
DS0 level grooming
better resiliency to packet loss in the PSN
more flexible distribution

16-2 PWE services configuration
The encapsulation types that are supported are:

MEF8: The encapsulation header is identified by an ethertype of 88D8.
There are 3 components to this header:
Emulated Circuit Identifier (ECID) - this identifies the emulated circuit
being carried.
Control Word - provides sequencing and signaling of defects such as
AIS.
Optional RTP Header - timing and sequencing maybe provided via
Real-Time Transport Protocol (RTP). This is not supported in SAOS
software
Dry Martini: The encapsulation header is an MPLS header with an
optional control word. The MPLS bottom label is the PWE label. There is
no tunnel label.
MPLS: The encapsulation header is an MPLS header. The MPLS bottom
label is the PWE label. There is also a tunnel label identifying the MPLS
tunnel.
The supported transport for the PWE services are:

802.1Q: The Ethernet header contains one VLAN: the service VLAN (S-
VLAN). The S-VLAN and the destination MAC address identify the
Ethernet PSN.
QinQ: The Ethernet header contains two VLANS: the customer VLAN (C-
VLAN) and the S-VLAN. The S-VLAN and the destination MAC address
identify the Ethernet PSN.
MPLS: The MPLS header is also used for the transport where the tunnel
label is stacked on top of the PWE label. The tunnel label is used to identify
the MPLS PSN.
Figure 16-1 shows the encapsulation and transport types.

Figure 16-1
Encapsulation and transport types
When configuring TDM services, note the following:

The PWE hardware supports either T1 ports or E1 ports but not both at
the same time. By default, the PWE hardware is in T1 mode.
The PWE hardware supports 16 TDM T1 or E1 physical ports. Each port
can be channelized (NxDS0) and bundled where a bundle is treated as a
single pseudowire.
The number of pseudowire services that the PWE hardware supports is
up to 16 for SAToP and 24 for CESoP whether the configuration is T1 or
E1.
The procedures in this chapter are inter-related and are intended to be used
as building blocks that can be combined to offer various PWE services over
PSN. The procedures are:
Configuring PWE services on page 16-6
Configuring TDM ports on page 16-7
Configuring TDM profiles on page 16-11
Configuring attachment circuits on page 16-13
Configuring virtual circuits on page 16-17
Configuring MPLS on page 16-25
Configuring Layer 2 virtual circuits on page 16-26
Configuring virtual switch cross-connections on page 16-27

Figure 16-2 shows the flow of the procedures for end-to-end configuration.
Figure 16-2
PWE services configuration
PWE services
configuration
Configure attachment circuits
Configure tdm-mef8 Configure tdm-dry-martini Configure tdm-mpls

virtual circuit virtual circuit virtual circuit
Configure Ethernet Configure Ethernet Configure MPLS transport

virtual circuit virtual circuit (tunnel, mpls l2vpn)
Configure virtual switch

cross-connect
End
You can display information about configured PWE services. Procedures to

display information are:
Displaying TDM port information on page 16-28
Displaying attachment circuit information on page 16-30
Displaying virtual circuit information on page 16-31
Displaying virtual switch information on page 16-32

Additionally, this chapter provides end-to-end procedures for configuring

Mobile Wireless Backhaul (MWB) in Metro Ethernet or MPLS networks:
Configuring SAToP services over 802.1Q Metro Ethernet on page 16-34
Configuring SAToP services over QinQ Metro Ethernet on page 16-37
Configuring SAToP pseudowire over MPLS network on page 16-40

Procedure 16-1
Configuring PWE services
Configure PWE services to enable TDM ports and set the mode that PWE
services operates in. By default, TDM ports are disabled.
Prior to changing the mode in which the TDM port operates, all TDM virtual
circuits and associated cross connects as well as TDM profiles, attachment
circuits, and associated performance monitoring instances must be deleted.
Note: It takes a few seconds to re-initialize the chip set to operate in the
new TDM mode. During that re-initialization, TDM related configuration
changes and some TDM show commands are denied.
Step Action
1 Set the mode that the TDM port operates in:

port tdm set mode <e1|t1>
2 Enable TDM ports:
port tdm enable port <TDM port list>
end

Procedure 16-2
Configuring TDM ports
Configure TDM ports with T1 TDM port parameters if you configured PWE
functionality to run in T1 mode. Configure TDM ports with E1 port parameters
if you configured the PWE functionality to run in E1 mode.
Step Action
To configure T1 TDM port parameters

1 Configure T1 TDM port parameters:
port tdm t1 set port <port> [framing <unframed|super-
frame|extended-super-frame>] [line-code <b8zs|ami>]
[line-build-out <133|266|399|533|655>][clock-mode
<internal|recovered|adaptive>] [master-clock-src-port
<TDM Port Name>] [master-clock-src-tdm-vc <TDM VC Name>]
[loopback-mode disabled|local|remote>]}
where
port <TDM port is the TDM port list.
list>
framing is the framing.
<unframed|super unframed: only one SAToP attachment circuit can be
-frame|extended- created using the port.
super-frame>
super-frame or extended-super-frame: either one SAToP
attachment circuit can be created over the port or multiple
CESoP attachment circuits, each using different group of
timeslots.
The default value is unframed.
line-code is the encoding used for the TDM signal on the targeted port.
<b8zs|ami> b8zs: bipolar 8-zero substitution
ami: alternate mark inversion
The default value is b8zs.

where
line-build-out is the number of feet of cable separating the 3932 platform
<133|266|399| from the remote end of the T1 port. Each value represents
533|655> the end of a range.
133: 1 to 133 ft.
266: 134 to 266 ft.
399: 267 to 399 ft.
533: 400 to 533 ft.
655: 401 to 655 ft.
[clock-mode is the timing for the TDM port signal.
<internal| internal: indicates that the TDM port is using the 3932 clock
recovered| as defined by the system timing configuration.
adaptive>]
recovered: indicates that the TDM port is recovering the
clock from the RX signal of the given master-clock-src-port.
If master-clock-src-port is not specified, the clock is
recovered from the RX signal of the targeted TDM port.
adaptive: indicates that the TDM port is using the TDM
virtual circuit specified by master-clock-src-tdm-vc. A
maximum of 8 different TDM virtual circuits can be used as
reference clock. When using TDM-VC as the master
source, the clock mode for the TDM port can be configured
only once the TDM virtual circuit has been created.
The default value is internal.
master-clock-src- is the TDM port used as the master clock source when the
port <TDM Port clock mode is set to recovered.
Name>
master-clock-src- is the TDM VC used as the master clock source when the
tdm-vc <TDM VC clock mode is set to adaptive.
Name> Note: Only TDM VCs associated with TDM ports 1-8 can be
used as master-clock-source-tdm-vc.
loopback-mode is the loopback on the targeted ports. When loopback is
disabled|local| enabled, the operational state of the port is "maintenance".
remote> disabled: no loopback
local: loopback is towards system, that is, transmit to T1 is
received by the system
remote: loopback is towards user, that is, receive by T1 is
transmitted back to user
The default value is disabled.

To configure E1 TDM port parameters

2 Configure E1 TDM ports:
port tdm e1 set port <port> [clock-mode
<internal|recovered|adaptive>] [master-clock-src-port
<TDM Port Name>] [master-clock-src-tdm-vc <TDM VC Name>]
[framing <unframed| basic|crc-multiframe>] [line-code
<hdb3|ami>] [loopback-mode <disabled|local|remote>]
where
port <port> is the TDM port list.
clock-mode is the timing for the TDM port signal.
<internal| internal: indicates that the TDM port is using the 3932 clock
recovered|
adaptive> recovered: indicates that the TDM port is recovering the
clock from the RX signal of the given master-clock-src-port.
If master-clock-src-port is not specified, the clock is
recovered from the RX signal of the port.
adaptive: indicates that the TDM port is using the TDM
virtual circuit specified by master-clock-src-tdm-vc. A
maximum of 8 different TDM virtual circuits can be used as
reference clock. When using TDM-VC as the master
source, the clock mode for the TDM port can be configured
only once the TDM virtual circuit has been created.
The default value is internal.
Name>
master-clock-src- is the TDM VC used as the master clock source when the
tdm-vc <TDM VC clock mode is set to adaptive.
Name> Note: Only TDM VCs associated with TDM ports 1-8 can be
used as master-clock-source-tdm-vc.

where
framing is the framing.
<unframed|basic| unframed: unframed E1.
crc-multiframe>
basic: 32 channels/timeslots X8 bits per channel. Timeslot
0 is used for synchronization, alarm transport, and internal
carrier use.
crc-multiframe: consists of 16 basic frames.
The default value is unframed. Framing must be set to basic
or crc-multiframe in order to be able to configure CESoP
services over the TDM port.
line-code is the encoding used for the TDM signal on the targeted port.
<hdb3|ami> hdb3: high density bipolar 3
ami: alternate mark inversion
The default value is hdb3.
loopback-mode is the loopback on the targeted ports. When loopback is
<disabled enabled, the operational state of the port is "maintenance".
local|remote> disabled: no loopback
local: loopback is towards system, that is, transmit to E1 is
received by the system
remote: loopback is towards user, that is, receive by E1 is
transmitted back to user
The default value is disabled.
end

Procedure 16-3
Configuring TDM profiles
Configure a TDM profile to contain the TDM parameters that are used by the
TDM virtual circuit and the MPLS Layer 2 Virtual Private Network (L2VPN)
pseudowire.
A TDM profile can be used by one or more TDM virtual circuits and MPLS
L2VPN pseudowires. Note that once a profile has been associated with a
virtual circuit or MPLS L2VPN pseudowire, the parameters in the profile
cannot be changed without first disassociating the profile from all the virtual
circuits or MPLS L2VPNs that it is associated with. Alternately, you can create
another profile with different parameters and associate it with the required
virtual circuits and MPLS L2VPN pseudowires.
Note: A TDM profile cannot be deleted without first disassociating it from

a TDM virtual circuit or an MPLS L2VPN.

Step Action
1 Configure the TDM profile:

virtual-circuit tdm create tdm-profile <tdm-profile-name>
pwType {satop|cesop} payload-size <bytes>
where
tdm-profile <tdm- is the name of the TDM profile.
profile-name>
pwType is the pseudowire type, which is one of SAToP or CESoP.
{satop|cesop}
payload-size is the payload size.
<bytes> If the pwType is satop, payload-size is
for T1, multiples of 24 to a maximum of 192
for E1, multiples of 32 to a maximum of 256
If the pwType is cesop, payload-size depends on the
number of channels used by the attachment circuit that will
be referenced along with the TDM profile when the TDM VC
is created. The rules for payload-size where pwType is
cesop are:
Settable range is 1 to 192 for T1 and 1 to 256 for E1.
Must be a multiple of the number of channels configured on
the attachment circuit that is used. For example, 10
channels should use payload size of 10, 20, 30, and so on.
Payload-size maximum must not exceed 64 times the
number of channels. For example, payload-size for two
channels cannot be greater than 128.
Payload-size divided by the number-of-channels times 125
microseconds must not exceed configured PDV value of
TDM-VC, otherwise an error is returned by TDM-VC
configuration.
end

Procedure 16-4
Configuring attachment circuits
Configure an attachment circuit to represent the client UNI port as a single
logical entity.
For E1, channel 0 is always reserved. In PCM30, you must create a separate
CESoP pseudowire for the channel 16 signalling channel only, and then
bundle the other channels in other CESoP pseudowires.
You can
create a SAToP attachment circuit
create a CESoP attachment circuit
add channels to a CESoP attachment-circuit
remove channels from a CESoP attachment-circuit
set attributes for a CESoP attachment-circuit
unset attributes for a CESoP attachment-circuit
Note: An attachment circuit cannot be deleted if it is associated with a

TDM virtual circuit.
Step Action
To create an SAToP attachment circuit

1 Create an SAToP attachment circuit that uses the specified TDM port
instance:
attachment-circuit satop create ac <ac-name> port <TDM
port>
where
ac <ac-name> is the attachment circuit.
port <TDM port> is the TDM port.

To create a CESoP attachment circuit

2 Create a CESoP attachment circuit on the specified TDM port instance using
the selected list of channels:
attachment-circuit cesop create ac <ac-name> port <TDM
port> channel <channel-list> [master-clock-src <on|off>]]
where
port <TDM port> is the TDM port.
channel is the channel set.
<channel-list> If the TDM mode is set to T1, the channel set can be any un-
used channel in the range of 1 to 24.
If the TDM mode is set to E1, the channel set can be any un-
used channel in the range of 1 to 31. In E1 mode, channel 0
is reserved for signaling and cannot be used in a CESoP
attachment circuit.
[master-clock-src Note: indicates whether this circuit is the master clock
<on|off>] source in adaptive clock mode. The default value is off. Only
CESoP ACs associated with TDM port 1 to 8 can be
designated master clock source.
Note: There can only be one CESoP attachment circuit for
each TDM port designated as master clock source. Only the
TDM VC that is associated with a CESoP attachment circuit
that has its master clock source flag set to on can be used
as a master clock source TDM VC.
To add channels to a CESoP attachment-circuit

3 Add channels to a CESoP attachment circuit:
attachment-circuit cesop add ac <ac-name> channel
<channel-list>
where
<channel-list> In T1 mode, the channel set can be any un-used channel in
the range of 1 to 24.
In E1 mode, the channel set can be any un-used channel in
the range of 1 to 31. Channel 0 is reserved for signaling.

To remove channels from a CESoP attachment-circuit

4 Remove channels from a CESoP attachment circuit:
attachment-circuit cesop remove ac <ac-name> channel
<channel-list>
where
<channel-list>
To set CESoP attachment-circuit attributes

5 Set the attributes of the CESoP attachment circuit:
attachment-circuit cesop set ac <ac-name> [master-clock-
src <on|off>]
where
[master-clock-src indicates whether this circuit is the master clock source in
<on|off>] adaptive clock mode. The default value is off. If changing
from on to off, it can only be done if the associated TDM VC
is not currently used as a master clock source for one of the
TDM ports that have its clock mode set to adaptive. If setting
from off to on, it's allowed only if there is no other AC on the
targeted port with its master-clock-src flag set to on.
Only CESoP ACs associated with TDM port 1 to 8 can be
designated master clock source.

To unset CESoP attachment-circuit attributes

6 Unset the attributes of the CESoP attachment circuit:
attachment-circuit cesop unset ac <ac-name> [master-
clock-src]
where
[master-clock- sets the master clock source adaptive clock mode to the
src] default value of off.
end

Procedure 16-5
Configure a virtual circuit to represent the pseudowire-specific and PSN-
specific processing that the PWE functionality performs. The virtual circuit is
used for proxy PSN-specific processing.
Configuring a virtual circuit requires:

a corresponding attachment circuit
a TDM profile
Note: To change the attachment circuit associated with a virtual circuit,

delete and re-add the TDM virtual circuit with the new attachment circuit
association.
You can create and modify parameters for TDM virtual circuits of type:
MEF8
Dry Martini
MPLS
Note 1: The name of a TDM virtual circuit must be unique across all TDM
virtual circuits.
Note 2: A TDM virtual circuit cannot be deleted if it is associated with a
virtual-switch cross-connect or associated with a performance monitoring
instance.
Step Action
To create a TDM virtual circuit of type MEF8

1 Create a TDM virtual circuit of type MEF8:
virtual-circuit tdm-mef8 create vc <vc> {ac <Attachment
Circuit Name>} [c-vid <NUMBER: 1-4094>] [c-pcp <NUMBER:
0-7>] {peer-mac <MAC address: XX:XX:XX:XX:XX:XX>} [pdv
<NUMBER: 1000-32000>] {in-ecn <NUMBER: 1-65535>} {out-ecn
<NUMBER: 1-65535>} tdm-profile <TDM Profile Name>
where
vc <vc> is the virtual circuit name.
{ac <Attachment is the attachment circuit.
Circuit Name>}
[c-vid <NUMBER: is the CVLAN tag to be inserted in the Ethernet frame.
1-4094>]

where
[c-pcp is the P-bits (priority) value. The default value is 7.
<NUMBER: 0-7>]
{peer-mac <MAC is the 6-byte unicast MAC address of the remote end of the
address: PWE service.
XX:XX:XX:XX:XX
:XX>}
[pdv <NUMBER: is the Packet Delay Variation (PDV) in microseconds. The
1000-32000>] range is 1000 to 32000, that is, 1to 32 milliseconds. The pdv
parameter determines the size of the jitter buffer used to
store incoming TDM service packets. The value of the pdv
parameter must be greater than Payload-size divided by the
number of channels times 125 microseconds for the CESoP
TDM service.
For SAToP services, the default value is 3000
microseconds.
For CESoP services, the default value is calculated based
on the number of channels used according to the following
equation: ((payload-size modulo num-channels) + n) so that
this sum * 125 >= 1000.
{in-ecn is the incoming or local Ethernet Connection Identifier (EC-
<NUMBER: 1- ID). On packets received from the PSN, the EC-ID of the
65535>} ingress packet is used to find the local TDM service this
packet belongs to.
The value is in the range of 1 to 65535. It must be unique
amongst all tdm-mef8 (in-ecn).
{out-ecn is the outgoing or remote EC-ID that is inserted on the TDM
<NUMBER: 1- packet sent out to the PSN, that is, the EC-ID of the remote
65535>} peer. Set the out-ecn parameter to the in-ecn value at the
remote peer. Note that there are no local checks to verify
that the values correspond.
{tdm-profile is the TDM profile
<TDM Profile
Name>}

To modify parameters for a TDM virtual circuit of type MEF8

2 Modify parameters for a TDM virtual circuit of type MEF8:
virtual-circuit tdm-mef8 set vc <vc> [ac <Attachment
Circuit Name>] [c-vid <vid>] [c-pcp <pcp-value>] [peer-
mac <mac>][pdv <1000-32000>] [in-ecn <1-65535>] [out-ecn
<1-65535>] [tdm-profile <tdm-profile-name>]
where
vc <vc> is the virtual circuit.
[ac <Attachment is the attachment circuit.
Circuit Name>]
1-4094>]
<NUMBER: 0-7>]
[peer-mac <MAC is the 6-byte unicast MAC address of the remote end of the
XX:XX:XX:XX:XX
:XX>]
1000-32000>] range is 1000 to 32000, that is, 1 to 32 milliseconds. The pdv
TDM service.
microseconds.
this sum * 125 >= 1000.

where
[in-ecn is the incoming or local Ethernet Connection Identifier (EC-
<NUMBER: 1- ID). On packets received from the PSN, the EC-ID of the
65535>] ingress packet is used to find the local TDM service this
packet belongs to.
The value is in the range of 1 to 65535. It must be unique
amongst all tdm-mef8 (in-ecn).
[out-ecn is the outgoing or remote EC-ID that is inserted on the TDM
<NUMBER: 1- packet sent out to the PSN, that is, the EC-ID of the remote
65535>] peer. Set the out-ecn parameter to the in-ecn value at the
remote peer. Note that there are no local checks to verify
that the values correspond.
[tdm-profile is the TDM profile
<TDM Profile
Name>]
To create a TDM virtual circuit of type Dry Martini
3 Create a TDM virtual circuit of type Dry Martini:
virtual-circuit tdm-dry-martini create vc <vc> {ac
<Attachment Circuit Name>} [c-vid <NUMBER: 1-4094>] [c-
pcp <NUMBER: 0-7>] {peer-mac <MAC address:
XX:XX:XX:XX:XX:XX>} [pdv <NUMBER: 3000-32000>] {in-label
<NUMBER: 1-1048575>} {out-label <NUMBER: 1-1048575>}
{tdm-profile <TDM Profile Name>}
where
vc <vc> is the virtual circuit name.
{ac <Attachment is the attachment circuit.
Circuit Name>}
1-4094>]
<NUMBER: 0-7>]
{peer-mac <MAC is the 6-byte unicast MAC address of the remote end of the
XX:XX:XX:XX:XX
:XX>}

where
TDM service.
microseconds.
this sum * 125 >= 1000.
{in-label is the incoming or local, that is pseudowire, label. On packet
<NUMBER: 1- receive from the PSN, the pseudowire label from the packet
1048575>} is used to find local TDM service. It must be unique amongst
all tdm-dry-martini (in-label) values. The label must be in the
configured static MPLS VC label range.
{out-label is the outgoing or remote label that is inserted on the TDM
<NUMBER: 1- packet sent out to the PSN, that is, the pseudowire label of
1048575>} the remote peer. Set the value of the out-label parameter to
the value of the in-label at the remote peer. The label must
be in the configured static MPLS virtual circuit label range
and available, that is, not already used by static MPLS virtual
circuit or another TDM Dry Martini pseudowire. Note that
there are no local checks to verify that the values
correspond.
{tdm-profile is the TDM profile.
<TDM Profile
Name>}
To modify the parameters of a TDM virtual circuit of type Dry Martini
4 Modify the parameters of a TDM virtual circuit of type Dry Martini:
Note: This operation is only permitted if the TDM virtual circuit is not cross-
connected.
virtual-circuit tdm-dry-martini set vc <vc> [ac
<Attachment Circuit Name>] [c-vid <NUMBER: 1-4094>] [c-
pcp <NUMBER: 0-7>] [peer-mac <MAC address:

XX:XX:XX:XX:XX:XX>] [pdv <NUMBER: 1000-32000>] [in-label

<NUMBER: 1-1048575>] [out-label <NUMBER: 1-1048575>]
[tdm-profile <TDM Profile Name>]
where
vc <vc> is the virtual circuit.
[ac <Attachment is the attachment circuit.
Circuit Name>]
1-4094>]
<NUMBER: 0-7>]
[peer-mac <MAC is the 6-byte unicast MAC address of the Pseudowire at the
address: remote end of the PWE service.
XX:XX:XX:XX:XX
:XX>]
TDM service.
microseconds.
this sum * 125 >= 1000.
{in-label is the incoming or local, that is pseudowire, label. On packet
<NUMBER: 1- receive from the PSN, the pseudowire label from the packet
1048575>} is used to find local TDM service. It must be unique amongst
all tdm-dry-martini (in-label) values. The label must be in the
configured static MPLS VC label range.
{out-label is the outgoing or remote label that is inserted on the TDM
<NUMBER: 1- packet sent out to the PSN, that is, the pseudowire label of
1048575>} the remote peer. Set the value of the out-label parameter to
the value of the in-label at the remote peer. The label must
be in the configured static MPLS virtual circuit label range
and available, that is, not already used by static MPLS virtual
circuit or another TDM Dry Martini pseudowire. Note that
there are no local checks to verify that the values
correspond.
[tdm-profile is the TDM profile.
<TDM Profile
Name>]

To create a TDM virtual circuit of type MPLS

5 Create a TDM virtual circuit of type MPLS:
Note: The peer mac address, in-label, and out-label are set in the MPLS
L2VPN virtual circuit configuration.
virtual-circuit tdm-mpls create vc <vc-name> ac <ac-name>
[pdv <3000-32000> tdm-profile <tdm-profile-name>
where
vc <vc-name> is the virtual circuit.
pdv <3000- is the Packet Delay Variation (PDV) in microseconds. The
32000> range is 1000 to 32000, that is, 1 to 32 milliseconds. The pdv
TDM service.
microseconds.
this sum * 125 >= 1000.
tdm-profile <tdm- is the TDM profile.
profile-name>

To modify the parameters of a TDM virtual circuit of type MPLS

6 Modify the parameters of a TDM virtual circuit of type MPLS:
Note: This operation is only permitted if the TDM virtual circuit is not cross-
connected.
virtual-circuit tdm-mpls set vc <vc-name> [ac <ac-name>]
[pdv <3000-32000>][tdm-profile <tdm-profile-name>]
where
vc <vc-name> is the virtual circuit.
pdv <3000- is the Packet Delay Variation (PDV) in microseconds. The
32000> range is 1000 to 32000, that is, 1 to 32 milliseconds. The pdv
TDM service.
microseconds.
this sum * 125 >= 1000.
tdm-profile <tdm- is the TDM profile.
profile-name>
end

Procedure 16-6
Configuring MPLS
To configure MPLS, configure the following:
IP interfaces
IGP
tunnels
pseudowires
For procedures, refer to Configuring static virtual circuits on page 12-94.

Procedure 16-7
Configuring Layer 2 virtual circuits
Configure Layer 2 virtual circuits.
Step Action
1 Create a VLAN:
2 Add ports to the VLAN:
vlan add vlan <vlan> port <Port list>
end

Procedure 16-8
Configuring virtual switch cross-connections
Configure a virtual switch cross-connection to associate a UNI virtual circuit
with an NNI virtual circuit.
The UNI virtual circuits are mapped to attachment circuits and NNI virtual
circuits are mapped to Layer 2 or Layer 3 tunnels. Associating the two virtual
circuits creates a point-to-point path between attachment circuits and virtual
circuits into the PSN tunnel.
Step Action
1 Create a cross-connection between a TDM virtual circuit and an MPLS virtual

circuit:
virtual-switch cross-connect create xc <xconnect-name>
tdm-vc <vc-name> { { mpls-vc <mpls-vc-name> } | { eth-vc
<eth-vc-name> } }
where
xc <xconnect- is the name of the cross-connection.
name>
tdm-vc <vc- is the UNI virtual circuit and is customer-facing.
name>
mpls-vc <vc- is an NNI virtual circuit and is PSN-facing.
name>
eth-vc <eth-vc- is an NNI Ethernet virtual circuit and is PSN-facing. This
name> parameter is used with MEF8 and Dry-Martini to specify the
transport, that is, dot1q or QinQ.
2 Enable or disable the specified cross-connection:

Note: The cross-connection is enabled by default.
virtual-switch cross-connect {enable|disable} xc
<xconnect-name>
where
xc <xconnect- is the name of the cross-connection created in step 1.
name>
end

Procedure 16-9
Displaying TDM port information
You can display
global performance monitoring statistics for TDM ports, which are the total
counts since the last system restart or last TDM mode change
TDM mode, status and configuration a specified port
details on configuration and current active alarms for a specified port
Note: There is no command to clear the values displayed by the

command port tdm show port <port> statistics.
For more information about viewing and clearing TDM statistics, refer to
Performance monitoring, in 39XX/51XX Service Delivery and Aggregation
Switches Fault and Performance Management (009-3220-009). Ciena
recommends using performance monitoring to view TDM port statistics.
Step Action
To display global performance monitoring statistics for TDM ports

1 Display global performance monitoring statistics for TDM ports:
port tdm show port <port> statistics
To display the TDM mode, status and configuration of a specified port
2 Display the TDM mode, status and configuration for the specified port:
port tdm show
To display details on configuration and current active alarms for a specified port
3 Display details on configuration and current active alarms for the specified
port:
port tdm show port <port>
end
Example
The port tdm show command provides global configuration and status as
well as TDM configuration and status for all TDM ports.
Note: After a system reboot, the global state of TDM is in Initializing for
up to 3 minutes.
The following shows the output of the port tdm show command:
port tdm show
+-------------------------------------------+
| TDM Global Configuration and Status |
+------------------+------------------------+

+------------------+------------------------+
| Mode | t1 |
| State | ready |
+------------------+------------------------+
+-------------------------------------------------------------------------------------------------+
| TDM Ports Configuration and Status |
+-----+--------------------+--------+---------+----------+-----------+--------+----------+--------+
| Port| Framing | Line | Line | Loopback | Clock | Master | Admin | Oper |
| | | BldOut | Coding | Mode | Mode | Clock | State | State |
+-----+--------------------+--------+---------+----------+-----------+--------+----------+--------+
|tdm01|super-frame | 133 | ami | disabled | internal | | enabled | up |
|tdm16|extended-super-frame| 133 | b8zs | disabled | internal | | disabled | down |

+-----+--------------------+--------+---------+----------+-----------+--------+----------+--------+

Procedure 16-10
Displaying attachment circuit information
Display attachment circuit information.
Step Action
1 Display attachment circuit information for all or specified attachment circuits:

attachment-circuit {satop|cesop} show [ac <ac-name>]
end
Example
The following shows an example of the attachment-circuit show
command:
attachment-circuit show
+-------------------------------------------------------------------------------------+
| Attachment Circuits |
+--------------------+----------+--------+-------------------------+------------------+
| Name | Type | Port | Channels assigned | TDM VC |
+--------------------+----------+--------+-------------------------+------------------+
| AC1-VL824 | satop | tdm05 | | mefAC5-VL824 |
| AC4-VL827 | satop | tdm08 | | mefAC8-VL827 |
| AC9a-VL828 | cesop | tdm09 | 1-23 | mefAC9a-VL828 |
| AC9b-VL829 | cesop | tdm09 | 24 | mefAC9b-VL829 |
| *cesop01ts1-4 | cesop | tdm01 | 1-4 | |
+--------------------+----------+--------+-------------------------+------------------+
NOTE: * left of a CESoP attachment circuit name indicates it is designated as
master clock source

Procedure 16-11
Displaying virtual circuit information
You can display
all virtual circuits of type MEF 8 or a specific virtual circuit of type MEF8
all virtual circuits of type Dry Martini or a specific virtual circuit of type Dry
Martini
all virtual circuits of type MPLS or a specific virtual circuit of type MPLS
You can also display statistics for TDM virtual circuits by creating performance
monitoring instances. For more information, refer to Performance
monitoring, in 39XX/51XX Service Delivery and Aggregation Switches Fault
and Performance Management (009-3220-009).
Step Action
To display all virtual circuits of type MEF8 or a specific virtual circuit of type MEF8
1 Display all virtual circuits of type MEF 8 or a specific virtual circuit of type
MEF8:
virtual-circuit tdm-mef8 show [vc <vc-name>]
To display all virtual circuits of type Dry Martini or a specific virtual circuit of type Dry Martini
2 Display all virtual circuits of type Dry Martini or a specific virtual circuit of type
Dry Martini:
virtual-circuit tdm-dry-martini show [vc <vc-name>]
To display all virtual circuits of type MPLS or a specific virtual circuit of type MPLS
3 Display all virtual circuits of type MPLS or a specific virtual circuit of type
MPLS:
virtual-circuit tdm-mpls show [vc <vc-name>]
end
Example
The following shows an example of the virtual-circuit tdm-mef8 show
command:
virtual-circuit tdm-mef8 show
+--------------------------------------------------------------------------+
| Tdm MEF8 Virtual Circuits |
+-----------------+-------------------+-----------------+--------+---------+
| Name | AttachmentCircuit | Cross-connect | In Ecn | Out Ecn |
+-----------------+-------------------+-----------------+--------+---------+
| AC1-VL900 | AC1-VL900 | XC-Cir1VL900 | 11001 | 12001 |
| mefAC16-VL913 | AC16-VL913 | XC-Cir16VL913 | 11024 | 12024 |

+-----------------+-------------------+-----------------+--------+---------+

Procedure 16-12
Displaying virtual switch information
You can display
all virtual switch information
all configured cross-connections or a specific cross-connection
Step Action
To display all virtual switch information

1 Display all virtual switch information:
virtual-switch show
To display details about a specific virtual switch
2 Display details about a specific virtual switch:
virtual-switch show vs <vs> {statistics}
where
statistics displays subscriber port statistics.
end

Procedure 16-13
Displaying virtual switch cross-connection
information
You can display configuration and status for:
all configured cross-connections
a specific cross-connection
Step Action
To display all configured cross-connections

1 Display all configured cross-connections:
virtual-switch cross-connect show
To display a specific cross-connection
2 Display all configured cross-connections or a specific cross-connection:
virtual-switch cross-connect show xc <xc>
end
Example
The following shows an example of the virtual-switch cross-connect show
command:
virtual-switch cross-connect show
+------------------------------------------------------------------------------------+
| Cross-Connects |
+-----------------+-----------------+--------+-----------------+---------+-----------+
| Name | UNI VC Name | Type | NNI VC Name | Type | OperState |
+-----------------+-----------------+--------+-----------------+---------+-----------+
| XC-Cir5VL824 | mefAC5-VL824 | TDM | VCE-5-VL824 | Ethernet| up |
| XC-Cir9aVL828 | mefAC9a-VL828 | TDM | VCE-9a-VL828 | Ethernet| up |
| XC-Cir9bVL829 | mefAC9b-VL829 | TDM | VCE-9b-VL829 | Ethernet| up |
+-----------------+-----------------+--------+-----------------+---------+-----------+

Procedure 16-14
Configuring SAToP services over 802.1Q Metro
Ethernet
Configure SAToP services over 802.1q Metro Ethernet when you want to
dispatch TDM bit-streams from a T1 connection over Metro Ethernet using
MEF8 encapsulation or Dry-Martini encapsulation.
Figure 16-3 shows a Cell Site Gateway (CSG) router connected to an

Aggregator Site Gateway (ASG) router through Metro Ethernet.
Figure 16-3
CSG router connected to ASG router through Metro Ethernet
Step Action
1 Set T1 attributes for the port:

port tdm t1 set port <port> framing unframed [line-code
<b8zs|ami>] clock-mode <internal|recovered|adaptive>
[master-clock-src-port <TDM Port Name>] [master-clock-
src-tdm-vc <TDM VC Name>]
where
framing unframed sets the framing type to unframed.
line-code is the line coding type.
<b8zs|ami>

where
clock-mode is the clock mode.
<internal|
recovered|
adaptive>
Name>
master-clock-src- is the TDM virtual circuit used as the master clock source
tdm-vc <TDM VC when the clock mode is set to adaptive.
Name> Note: The TDM virtual circuit must be created before the
clock mode can be set on the port.
2 Create a SAToP attachment circuit using the specified TDM port instance:
attachment-circuit satop create ac <ac-name> port <port>
3 Set the TDM profile:
virtual-circuit tdm create tdm-profile <tdm-profile>
pwType satop {payload-size <NUMBER: 1-256>}
4 Create the virtual circuit by performing one of the following sub-steps.
a. Create a Dry Martini virtual circuit:
virtual-circuit tdm-dry-martini create vc <vc> ac
<Attachment Circuit Name> [c-vid <NUMBER: 1-4094>]
[c-pcp <NUMBER: 0-7>] {peer-mac <MAC address:
XX:XX:XX:XX:XX:XX>} [pdv <NUMBER: 1000-32000>] {in-
label <unit 1-1048575>} {out-label <unit 1-1048575>}
b. Create a MEF8 virtual circuit:
virtual-circuit tdm-mef8 create vc <vc> {ac
<Attachment Circuit Name>} [c-vid <NUMBER: 1-4094>]
XX:XX:XX:XX:XX:XX>} [pdv <NUMBER: 1000-32000>] {in-ecn
<NUMBER: 1-65535>} {out-ecn <NUMBER: 1-65535>} tdm-
profile <TDM Profile Name>
5 Create a VLAN:
8 Create a cross-connection:
virtual-switch cross-connect create xc <xc> tdm-vc <TDM
VC Name> eth-vc <Virtual Circuit Name>
end

Example
The following example configures SAToP over 802.1Q Metro Ethernet. The
Ethernet MAC header with CVLAN 100 serves as the PSN Layer 2 tunnel
through the service provider's Ethernet network. By default, the MAC address
is assigned to PWE and the C-VLAN type used is 0x8100.
port tdm t1 set port tdm01-tdm16 framing unframed line-

code ami line-build-out 133
attachment-circuit satop create ac satopAc1 port tdm01
virtual-circuit tdm create tdm-profile satop-profile1

pwType satop payload-size 192
virtual-circuit tdm-dry-martini create vc satop-vc1 ac

satopAc1 peer-mac 00:00:01:01:01:01 in-label 4097 out-
label 4097 pdv 3000 tdm-profile satop-profile1
virtual-circuit ethernet create vc ethernet-vc1 vlan 100
virtual-switch cross-connect create xc tdmVs tdm-vc

satop-vc1 eth-vc ethernet-vc1

Procedure 16-15
Configuring SAToP services over QinQ Metro Ethernet
Configure SAToP services for a QinQ-based Metro Ethernet network.
Figure 16-4 shows a CSG router connected to an ASG router through Metro
Ethernet - QinQ.
Figure 16-4
CSG router connected to ASG router through Metro Ethernet QinQ
Step Action

port tdm t1 set port <Port List> framing unframed line-
coding <b8zs|ami>] clock-mode recovered clock-mode
master-clock-src-port <TDM Port Name>] line-build-out
<133|266|399|533|655>]
3 Create a TDM virtual circuit by performing one of the following substeps.
a. Create a Dry Martini virtual circuit:
virtual-circuit tdm-dry-martini create vc <vc> ac
<Attachment Circuit Name> [c-vid <NUMBER: 1-4094>]
XX:XX:XX:XX:XX:XX>} [pdv <NUMBER: 1000-32000>] {in-
label <unit 1-1048575>} {out-label <unit 1-1048575>}

b. Create a MEF8 virtual circuit:

virtual-circuit tdm-mef8 create vc <vc> {ac
<Attachment Circuit Name>} [c-vid <NUMBER: 1-4094>]
XX:XX:XX:XX:XX:XX>} [pdv <NUMBER: 1000-32000>] {in-ecn
<NUMBER: 1-65535>} {out-ecn <NUMBER: 1-65535>} tdm-
profile <TDM Profile Name>
4 Create a VLAN:
7 Set port-based Ethernet virtual circuit attributes:
virtual-circuit ethernet set port <Port List> vlan-
ethertype <8100|9100|88A8> vlan-ethertype-policy
<all|encap-only|vlan-tpid>
8 Create a cross-connection:
VC Name> eth-vc <Virtual Circuit Name>
end
Example
The following example configures SAToP services over QinQ-based Metro
Ethernet. The Ethernet MAC header with SVLAN 300 and CVLAN 100 serves
as the PSN Layer 2 tunnel through the service provider's Ethernet network.
By default, the MAC address is assigned to PWE and C-VLAN type used is
0x8100.
port tdm t1 set port tdm02 clock-mode recovered
port tdm t1 set port tdm01 framing unframed line-code ami

clock-mode recovered master-clock-src-port tdm02 line-
build-out 133

virtual-circuit tdm-mef8 create vc satopVc1 ac satopAc1

c-vid 100 peer-mac 00:00:01:01:01:01 in-ecn 100 out-ecn
200 pdv 3000 tdm-profile satop-profile1

virtual-circuit ethernet create vc ethernet-vc1 vlan 300
virtual-switch cross-connect create xc mefVs tdm-vc

satopVc1 eth-vc ethernet-vc1

Procedure 16-16
Configuring SAToP pseudowire over MPLS network
Configure SAToP pseudowire over an MPLS network.
Figure 16-5 shows a CSG router connected to an ASG router through an

MPLS network.
Figure 16-5
CSG router connected to ASG router through MPLS network
Step Action

port tdm t1 set port <Port List> framing unframed line-
coding <b8zs|ami>] clock-mode recovered master-clock-src-
port <TDM Port Name>] line-build-out
<133|266|399|533|655>]
3 Create a TDM profile:
virtual-circuit tdm create tdm-profile <tdm-profile>
{pwType <satop | cesop>} {payload-size <NUMBER: 1-256>}
4 Create a TDM virtual circuit:
virtual-circuit tdm-mpls create vc <vc> ac <Attachment
Circuit Name> pdv <NUMBER: 1000-32000> tdm-profile <TDM
Profile Name>

5 Create static ingress TE-Tunnel:

mpls tunnel create static-ingress <static-ingress> dest-
ip <IP address> next-hop-ip <IP address> label <NUMBER:
16-1044479>
6 Create static decapsulation TE-Tunnel:
mpls tunnel create static-egress <static-egress> label
<NUMBER: 16-1044479> src-ip <IP address>
7 Create static MPLS virtual circuit:
mpls l2-vpn create static-vc <static-vc> pw-id <NUMBER:
1-2147483647> peer <IP address> in-label <NUMBER: 16-
1044479> out-label <NUMBER: 16-1044479> te-tunnel <MPLS
ingress primary tunnel> pwType tdm tdm-profile <TDM
Profile Name>
where
static-vc <static- is the static virtual circuit name.
vc>
pw-id <NUMBER: is the VPN ID.
1-2147483647>
address>
in-label is the MPLS decapsulation label.
<NUMBER: 16-
1044479>
out-label is the MPLS encapsulation label.
<NUMBER: 16-
1044479>
te-tunnel <MPLS is the ingress transport primary TE tunnel.
ingress primary
tunnel>
pwType tdm sets the pseudowire type to TDM.
tdm-profile <TDM is the TDM profile specified for the tdm virtual-circuit.
Profile Name>
8 Create cross-connection:
VC Name> mpls-vc <MPLS TDM Virtual Circuit Name>
end
Example
By default the MAC address is assigned to PWE and the C-VLAN type is
0x8100.
port tdm t1 set port tdm02 clock-mode recovered

port tdm t1 set port tdm01 framing unframed line-code ami

clock-mode recovered master-clock-src-port tdm02 line-
build-out 133

virtual-circuit tdm-mpls create vc satop-vc1 ac satopAc1

pdv 3000 tdm-profile satop-profile1
interface create loopback loop ip 20.20.20.20
mpls tunnel create static-ingress ingr-tnl dest-ip

2.2.2.2 next-hop-ip 10.2.2.2 out-label 500
mpls tunnel create static-egress egr-tnl in-label 600 src-

ip 1.1.1.1
mpls l2-vpn create static-vc mpls-vc peer 2.2.2.2 te-

tunnel ingr-tnl in-label 4097 out-label 4098 pw-id 1 pw-
type tdm tdm-profile satop-profile1
virtual-switch cross-connect create xc mplsTdmVs tdm-vc

satop-vc1 mpls-vc mpls-vc
end

17-1
Error codes 17-
This chapter lists error codes.
Traffic profiling error codes

Table 17-1 describes the overlap error codes that can occur in advanced
mode when provisioning multiple traffic profiles on the same port. For
example, if VLANA is provisioned with the VLAN attribute value A, it will
overlap with a traffic profile on the same port that has the same attribute value
for A.
The following is an example of configuring an overlap condition, and the

resulting error message:
> traffic-profiling set port 1 mode advanced

> traffic-profiling standard-profile create port 1 profile 1 name t1 cir 1024
pir 1024 cbs 32 ebs 0 dot1dpri 1
> traffic-profiling standard-profile create port 1 profile 2 name t2 cir 1024
pir 2048 cbs 32 ebs 0 dot1dpri 1
ERROR: Creating standard-profile 2 overlaps profile 1 on port 1 -- classifier

overlaps existing profile overlap_code #28
Table 17-1
Overlap Classifier combination Cause of overlap

code
1 Untagged Profile with either IP or dscp classifier
2 VlanA Profile with VS + Vlan classifiers and the Vlan A is a member of

the VS.
Profile with VS +Vlan + any COS (IP, dscp, dot1d) classifiers and
the Vlan A is a member of the VS.
3 VlanA Profile with VS classifier and VlanA is a member of the VS.

Profile with VS + any COS (IP,dscp,dot1d) classifiers and VlanA
is a member of the VS.

17-2 Error codes
Table 17-1
4 VlanA Profile with VlanA classifier.

Profile with VlanA + any COS (IP, dscp, dot1d) classifiers.
5 VlanA Profile with any COS (IP, dscp, dot1d) classifier.
6 VlanA + dot1dB Profile with VS + dot1dB classifiers and VlanA is a member of the
VS and dot1d value matches.
7 VlanA + dot1dB Profile with VS+VlanA+dot1dB classifiers and VlanA is a member

of the VS and the dot1d value matches.
8 VlanA + dot1dB Profile with VS classifier and VlanA is a member of the VS.
Profile with VS + IP or dscp classifiers and VlanA is a member of
the VS.
Profile with VS + Vlan classifiers and VlanA is a member of the
VS.
Profile with VS + Vlan +IP or dscp classifiers and VlanA is a
member of the VS.
9 VlanA + dot1dB Profile with VlanA +dot1dB classifiers and dot1d value matches.
10 VlanA + dot1dB Profile with VlanA classifier.

Profile with VlanA + IP or dscp classifiers.
11 VlanA + dot1dB Profile with IP or dscp classifiers.
12 VlanA + dot1dB Profile with dot1dB classifier and dot1d value matches.
13 VlanA + IPB Profile with VS + IPB classifiers and VlanA is a member of the VS
and IP value matches.
14 VlanA + IPB Profile with VS+VlanA+IPB classifiers and VlanA is a member of

the VS and the IP value matches.
15 VlanA + IPB Profile with VS classifier and VlanA is a member of the VS.
Profile with VS + dot1d or dscp classifiers and VlanA is a member
of the VS.
VS.
Profile with VS + Vlan +dot1d or dscp classifiers and VlanA is a
member of the VS.
16 VlanA + IPB Profile with VlanA +IPB classifiers and IP value matches.
17 VlanA + IPB Profile with VlanA classifier.

Profile with VlanA + dot1d or dscp classifiers.
18 VlanA + IPB Profile with dot1d or dscp classifiers.

Error codes 17-3
Table 17-1
19 VlanA + IPB Profile with IPB classifier and IP value matches.
20 VlanA + dscpB Profile with VS + dscpB classifiers and VlanA is a member of the
VS and dscp value matches.
21 VlanA + dscpB Profile with VS+VlanA+dscpB classifiers and VlanA is a member

of the VS and the dscp value matches.
22 VlanA + dscpB Profile with VS classifier and VlanA is a member of the VS.
Profile with VS + IP or dot1d classifiers and VlanA is a member
of the VS.
VS.
Profile with VS + Vlan +IP or dot1d classifiers and VlanA is a
member of the VS.
23 VlanA + dscpB Profile with VlanA +dscpB classifiers and dscp value matches.
24 VlanA + dscpB Profile with VlanA classifier.

Profile with VlanA + IP or dot1d classifiers.
25 VlanA + dscpB Profile with IP or dot1d classifiers.
26 VlanA + dscpB Profile with dscpB classifier and dscp value matches.
27 dot1dA Profile with VS classifier.

Profile with VS + IP or dscp classifiers.
Profile with VS + Vlan classifiers.
Profile with VS + Vlan + IP or dscp classifiers.
Profile with Vlan classifier.
Profile with Vlan + IP or dscp classifiers.
Profile with IP or dscp classifier.
28 dot1dA Profile with VS + dot1dA classifiers.

Profile with VS + Vlan +dot1dA classifiers.
Profile with Vlan +dot1dA classifiers.
Profile with dot1dA classifier.
Where the dot1d value matches.

17-4 Error codes
Table 17-1
29 IPA Profile with VS classifier.

Profile with VS + dot1d or dscp classifiers.
Profile with VS + Vlan + dot1d or dscp classifiers.
Profile with Vlan + dot1d or dscp classifiers.
Profile with dot1d or dscp classifier.
30 IPA Profile with VS + IPA classifiers.

Profile with VS + Vlan +IPA classifiers.
Profile with Vlan +IPA classifiers.
Profile with IPA classifier.
Where the IP value matches.
31 dscpA Profile with VS classifier.

Profile with VS + IP or dot1d classifiers.
Profile with VS + Vlan + IP or dot1d classifiers.
Profile with Vlan + IP or dot1d classifiers.
Profile with IP or dot1d classifier.
32 dscpA Profile with VS + dscpA classifiers.

Profile with VS + Vlan +dscpA classifiers.
Profile with Vlan +dscpA classifiers.
Profile with dscpA classifier.
Where the dscp value matches.
33 VSA Profile with VSA classifier.

Profile with VSA + any COS(dot1d,IP,dscp) classifiers.
Profile with VSA +Vlan classifiers.
Profile with VSA + Vlan + any COS(dot1d,IP,dscp) classifiers.
34 VSA Profile with Vlan classifier and Vlan is a member of VSA.

Profile with Vlan + any COS(dot1d, IP, dscp) classifiers and Vlan is a
member of VSA.
35 VSA Profile with any COS(dot1d,IP,dscp) classifier.

Error codes 17-5
Table 17-1
36 VSA + dot1dB Profile with VSA + dot1dB classifiers and dot1d value matches.
Profile with VSA +Vlan + dot1dB classifiers and dot1d value
matches.
37 VSA + dot1dB Profile with VSA classifier.

Profile with VSA +IP or dscp classifiers.
Profile with VSA + Vlan + IP or dscp classifiers.
38 VSA + dot1dB Profile with Vlan +dot1dB classifiers and Vlan is a member of VSA.
39 VSA + dot1dB Profile with Vlan and Vlan is a member of VSA.

Profile with Vlan + IP or dscp classifiers and Vlan is a member of VSA.
40 VSA + dot1dB Profile with dot1dB classifier.
41 VSA + dot1dB Profile with IP or dscp classifier.
42 VSA + IPB Profile with VSA + IPB classifiers and IP value matches.
Profile with VSA +Vlan + IPB classifiers and IP value matches.
43 VSA + IPB Profile with VSA classifier.

Profile with VSA +dot1d or dscp classifiers.
Profile with VSA + Vlan + dot1d or dscp classifiers.
44 VSA + IPB Profile with Vlan +IPB classifiers and Vlan is a member of VSA.
45 VSA + IPB Profile with Vlan and Vlan is a member of VSA.

Profile with Vlan + dot1d or dscp classifiers and Vlan is a member of
VSA.
46 VSA + IPB Profile with IPB classifier.
47 VSA + IPB Profile with dot1d or dscp classifier.
48 VSA + dscpB Profile with VSA + dscpB classifiers and dscp value matches.
Profile with VSA +Vlan + dscpB classifiers and dscp value
matches.
49 VSA + dscpB Profile with VSA classifier.

Profile with VSA +IP or dot1d classifiers.
Profile with VSA + Vlan + IP or dot1d classifiers.
50 VSA + dscpB Profile with Vlan +dscpB classifiers and Vlan is a member of VSA.

17-6 Error codes
Table 17-1
51 VSA + dscpB Profile with Vlan and Vlan is a member of VSA.

Profile with Vlan + IP or dot1d classifiers and Vlan is a member of VSA.
52 VSA + dscpB Profile with dscpB classifier.
53 VSA + dscpB Profile with IP or dot1d classifier.
54 VSA + VlanB Profile with VSA classifier.

Profile with VSA + any COS(dot1d, IP, dscp) classifiers.
55 VSA + VlanB Profile with VSA + VlanB classifiers.

Profile with VSA + VlanB +any COS(dot1d,IP,dscp) classifiers.
56 VSA + VlanB Profile with VlanB classifier and VlanB is a member of VSA.
Profile with VlanB + any COS (dot1d,IP,dscp) classifiers and VlanB is a
member of VSA.
57 VSA + VlanB Profile with any COS(dot1d, IP, dscp).
58 VSA + VlanB + dot1dC Profile with VSA + dot1dC classifiers and dot1d value matches.
59 VSA + VlanB + dot1dC Profile with VSA classifier.

Profile with VSA +IP or dscp classifiers.
60 VSA + VlanB + dot1dC Profile with VSA + VlanB + dot1dC classifiers and dot1d value
matches.
61 VSA + VlanB + dot1dC Profile with VSA + VlanB classifiers.

Profile with VSA + VlanB + IP or dscp classifiers.
62 VSA + VlanB + dot1dC Profile with VlanB +dot1dC classifiers and VlanB is a member of
VSA and dot1d value matches.
63 VSA + VlanB + dot1dC Profile with VlanB classifier and VlanB is a member of VSA.
Profile with VlanB + IP or dscp classifiers and VlanB is a member of VSA.
64 VSA + VlanB + dot1dC Profile with IP or dscp classifier.
65 VSA + VlanB + dot1dC Profile with dot1dC and dot1d value matches.
66 VSA + VlanB + IPC Profile with VSA +IPC classifiers and IP value matches.
67 VSA + VlanB + IPC Profile with VSA classifier.

Profile with VSA +dot1d or dscp classifiers.
68 VSA + VlanB + IPC Profile with VSA + VlanB + IPC classifiers and IP value matches.
69 VSA + VlanB + IPC Profile with VSA + VlanB classifiers.

Profile with VSA + VlanB + dot1d or dscp classifiers.

Error codes 17-7
Table 17-1
70 VSA + VlanB + IPC Profile with VlanB +IPC classifiers and VlanB is a member of VSA
and IP value matches.
71 VSA + VlanB + IPC Profile with VlanB classifier and VlanB is a member of VSA.
Profile with VlanB + dot1d or dscp classifiers and VlanB is a member of
VSA.
72 VSA + VlanB + IPC Profile with dot1d or dscp classifier.
73 VSA + VlanB + IPC Profile with IPC and IP value matches.
74 VSA + VlanB + dscpC Profile with VSA + dscpC classifiers and dscp value matches.
75 VSA + VlanB + dscpC Profile with VSA classifier.

Profile with VSA +IP or dot1d classifiers.
76 VSA + VlanB + dscpC Profile with VSA + VlanB + dscpC classifiers and dscp value
matches.
77 VSA + VlanB + dscpC Profile with VSA + VlanB classifiers.

Profile with VSA + VlanB + IP or dot1d classifiers.
78 VSA + VlanB + dscpC Profile with VlanB +dscpC classifiers and VlanB is a member of
VSA and dscp value matches.
79 VSA + VlanB + dscpC Profile with VlanB classifier and VlanB is a member of VSA.
Profile with VlanB + IP or dot1d classifiers and VlanB is a member of
VSA.
80 VSA + VlanB + dscpC Profile with IP or dot1d classifier.
81 VSA + VlanB + dscpC Profile with dscpC and dscp value matches.

17-8 Error codes

39XX/51XX Service Delivery and Aggregation Switches
Configuration
Copyright 2012-2014 Ciena Corporation. All rights reserved.
SAOS 6.12
Publication: 009-3240-008
Document status: Standard
Revision A
Document release date: May 2014
CONTACT CIENA
For additional information, office locations, and phone numbers, please visit the Ciena
web site at www.ciena.com

009-3240-008 (39XX 51XX SAOS 6.12 Configuration) RevA

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

009-3240-008 (39XX 51XX SAOS 6.12 Configuration) RevA

Caricato da

Copyright:

Formati disponibili

39XX/51XX Service Delivery and Aggregation

009-3240-008 - Standard Revision A

Corporate Headquarters 410-694-5700 or 800-921-1144 www.ciena.com

39XX/51XX Service Delivery and Aggregation Switches Configuration

39XX/51XX Service Delivery and Aggregation Switches Configuration

39XX/51XX Service Delivery and Aggregation Switches Configuration

First Standard release of this document for SAOS 6.12.

39XX/51XX Service Delivery and Aggregation Switches Configuration

39XX/51XX Service Delivery and Aggregation Switches Configuration

About this document xix

New in this release 1-1

Configuration fundamentals 2-1

Configuration management 3-1

Port management 4-1

39XX/51XX Service Delivery and Aggregation Switches Configuration

Hardware resource management 5-1

System timing configuration 6-1

39XX/51XX Service Delivery and Aggregation Switches Configuration

Synchronous Ethernet 6-2

Link Layer Discovery Protocol (LLDP) configuration 7-1

39XX/51XX Service Delivery and Aggregation Switches Configuration

7-3 Displaying LLDP neighbors 7-12

VLAN management 8-1

39XX/51XX Service Delivery and Aggregation Switches Configuration

9-18 Adding a static ARP entry 9-35

MEF L2 VPN configuration 10-1

39XX/51XX Service Delivery and Aggregation Switches Configuration

Provider Backbone Bridge Traffic Engineering (PBB-TE)

Multiprotocol Label Switching (MPLS) configuration 12-1

39XX/51XX Service Delivery and Aggregation Switches Configuration

39XX/51XX Service Delivery and Aggregation Switches Configuration

12-16 Configuring static bi-directional ingress-associated TE tunnels 12-73

L2 control frame tunneling configuration 13-1

39XX/51XX Service Delivery and Aggregation Switches Configuration

13-9 Configuring L2 control frame tunneling 13-19

Quality of Service configuration 14-1

39XX/51XX Service Delivery and Aggregation Switches Configuration

14-31 Displaying throughput statistics for a traffic profile 14-69

Multicast services configuration 15-1

39XX/51XX Service Delivery and Aggregation Switches Configuration

PWE services configuration 16-1

Error codes 17-1

39XX/51XX Service Delivery and Aggregation Switches Configuration

39XX/51XX Service Delivery and Aggregation Switches Configuration

About this document 0

This manual describes how to configure system software on 39XX/51XX

Note: This system software cannot be installed on any other Service

Conventions used in this document

In procedures, the following text conventions are used:

39XX/51XX Service Delivery and Aggregation Switches Configuration

<> Encloses a variable or literal value that must be specified. Some

{} Encloses a required value or list of required arguments. One or

| Separates mutually exclusive items in a list, only one of which can

Either on or off must be specified, for example:

[] Encloses an optional value or a list of optional arguments. One or

You can enter a value for interface <Interface> or not. For

39XX/51XX Service Delivery and Aggregation Switches Configuration

{ [ ], [ ], [ ] } Specifies a list of optional items where at least one must be

* Indicates zero or more occurrences of what is preceding.

Documents in the 39XX/51XX documentation suite

39XX/51XX Service Delivery and Aggregation Switches Configuration

39XX/51XX Service Delivery and Aggregation Switches Configuration

New in this release 1-