Aviat

CTR 8500 CONFIGURATION
MPLS
Version 3.4
260-668256-014
Copyright & Terms of Use
December 2016
This documentation incorporates features and functions provided with CTR 8500 for software release 3.4
Copyright © 2016 by Aviat Networks, Inc.
All rights reserved. No part of this publication may be reproduced, transmitted, transcribed, stored in a
retrieval system, or translated into any language or computer language, in any form or by any means, elec-
tronic, magnetic, optical, chemical, manual or otherwise, without the prior written permission of Aviat Net-
works Inc. To request permission, contact techpubs@aviatnet.com.
Warranty
Aviat Networks makes no representation or warranties with respect to the contents hereof and specifically dis-
claims any implied warranties or merchantability or fitness for any particular purpose. Further, Aviat Net-
works reserves the right to revise this publication and to make changes from time to time in the content
hereof without obligation of Aviat Networks to notify any person of such revision or changes.
Safety Recommendations
The following safety recommendations must be considered to avoid injuries to persons and/or damage to the
equipment:
1. Installation and Service Personnel: Installation and service must be carried out by authorized personnel who
have the technical training and experience necessary to be aware of any hazardous operations during install-
ation and service, and of measures to avoid any danger to themselves, to any other personnel, and to the equip-
ment.
2. Access to the Equipment: Access to the equipment in use must be restricted to service personnel only.
3. Safety Norms: Recommended safety norms are detailed in the Health and Safety sections of this guide.
Local safety regulations must be used if mandatory. Safety instructions in this guide should be used in addi-
tion to the local safety regulations. In the case of conflict between safety instructions stated in this guide and
those indicated in local regulations, mandatory local norms will prevail. Should local regulations not be man-
datory, then the safety norms in this guide will prevail.
4. Service Personnel Skill: Service personnel must have received adequate technical training on tele-
communications and in particular on the equipment this guide refers to.
Trademarks
All trademarks are the property of their respective owners.
End User License Agreement and Open Source
By using this product you agree to the terms of the CTR 8540 End User License Agreement; to view this, log
into a CTR 8540 or CTR 8300 using the CLI command window and enter the CLI command “show EULA”.
The CTR 8540 and CTR 8300 use free and open source software components, which can be viewed by using
the CLI command “show system acknowledgments”. This command also details the licenses associated with
each component and describes the methods available to acquire the open source software.
260-668256-014 DECEMBER 2016 I

MPLS CONFIGURATION FOR CTR 8500
Aviat Networks Technical & Sales

Support
Technical Service and Support
For customer service and technical support contact the Global Technical Help Desk (GTHD). A call will be
answered by GTHD support staff who will resolve the issue, if possible, or quickly pass the call to the appro-
priate TAC engineer for resolution.
The GTHD number is: +1-210-526-6345, or toll free 1-800-227-8332 within USA
For 24/7 access you will need your Support Assurance PIN. Without a PIN you will still receive support, but the
support process will require an additional screening step.
Americas Technical Help Desk EMEA Technical Help Desk Asia Pacific Technical Help Desk
Aviat Networks,Inc. Aviat Networks Aviat Networks
San Antonio, TX Blantyre, Glasgow G72 0FB Clark Freeport Zone
USA UK Philippines 2023
Phone: +1 210 526 6345 Phone: +1 210 526 6345 Phone: +1 210 526 6345
Toll Free (USA):1-800-227-8332 Fax: +44 16 9871 7204 (English) Fax: +63 45 599 5196
Fax +1 210-526-6315 Fax: +33 1 5552 8012 (French)
TAC.AM@aviatnet.com TAC.EMEA@aviatnet.com TAC.APAC@aviatnet.com
Sales and Sales Support

Contact one of the Aviat Networks headquarters, or find your regional sales office on the Aviat Networks web
site.
Corporate Headquarters, California, USA International Headquarters , Singapore
Aviat Networks, Inc. Aviat Networks(S) Pte. Ltd.
860 N. McCarthy Blvd., Suite 200 17, Changi Business Park Central 1
Milpitas, CA 95035 Honeywell Building, #04-01
U.S.A. Singapore 486073
Phone: + 408 941 7100 Phone: +65 6496 0900
Fax: + 408 941 7110 Fax: + 65 6496 0999
Sales Inquiries: +1-321-674-4252
II AVIAT NETWORKS
Product Compliance Notes

CTR 8540, CTR 8312, CTR 8311, and CTR 8380 were tested using screened cable; if any other type of cable is
used, it may violate EMC compliance.
CTR 8540, CTR 8312, CTR 8311, and CTR 8380 are Class A products. In a domestic environment these products
may cause radio interference in which case the user may be required to take adequate measures. This equip-
ment is intended to be used exclusively in telecommunications centers.
Regulatory Information for ODU 600, 5.8GHz Band

The following regulatory information applies to license-free operation on the 5.8 GHz band of ODU 600.
FCC Notices
1. The ODU 600, 5.8GHz must be professionally installed and maintained.
2. This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant
to Part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful inter-
ference when the equipment is operated in a commercial environment. This equipment generates, uses and
can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual,
may cause harmful interference to radio communications. Operation of this equipment in a residential envir-
onment is likely to cause harmful interference in which case the user will be required to correct the inter-
ference at his own expense.
3. ODU 600, 5.8GHz is compliant with the relevant parts of FCC CFR47, Part 15.407.
4. To ensure compliance with the FCC RF exposure requirements, a minimum distance of 18 meters must be
maintained between the antenna and any persons whilst the unit is operational. This calculation is based on
the maximum conducted power and maximum antenna gain.
5. ODU 600, 5.8GHz has been certified for use with a parabolic antenna with a maximum gain of 45.9dBi or a
flat panel antenna with a maximum gain of 28dBi.
6. The software provided with this product allows for transmission only in the frequency range 5725 – 5850
MHz to ensure compliance with Part 15.407.
7. According to the conducted power limit in FCC CFR 47, Part 15.407, the power for this device has been lim-
ited to 1W (30dBm) at the antenna port.
8. FCC CFR47, Part 15.407 excludes the use of point-to-multipoint systems, omnidirectional applications and
multiple co-located intentional radiators. This system is only for fixed, point-to-point operation.
International Use of 5.8GHz

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

For IEEE 1613 compliant products, category 7 Ethernet cables must be used in order to ensure
compliance.
260-668256-014 DECEMBER 2016 III

WEEE Directive
In accordance with the WEEE Directive (2012/19/EU), CTR 8540, CTR 8312, CTR 8311, and CTR 8380 are marked
with the following symbol:
This symbol indicates that this equipment should be collected separately for the purposes of recovery and/or
recycling.
For information about collection and recycling of Aviat Networks equipment please contact your local Aviat
Networks sales office. If you purchased your product via a distributor please contact the distributor for inform-
ation regarding collection and recovery/recycling.
More information on the WEEE Directive is available at our website:
http://www.aviatnetworks.com/products/compliance/weee/.
(WEEE is the acronym for Waste Electrical and Electronic Equipment)
RoHS Directive
CTR 8540, CTR 8312, CTR 8311, and CTR 8380 meet the requirements of ROHS directive 2011/65/EU.
Declaration of Conformity, R&TTE Directive, 1999/5/EC

The reference to CTR in this declaration denotes intended use of the CTR 8540, CTR 8312, CTR 8311, or
CTR 8380 with one or more of the following Aviat Networks ODUs: ODU 600, ODU 600sp, ODU 300hp.
IV AVIAT NETWORKS
260-668256-014 DECEMBER 2016 V

The CTR 8540, CTR 8312, CTR 8311, or CTR 8380 with an ODU 600, ODU 600sp, or ODU 300hp radio is classified
under the R&TTE Directive 99/5/EC as a class 2.8 radio (microwave fixed link) product.
Point-to-point radio relay equipment is intended to be used for:
- Interconnecting private and public networks.
- Interconnecting mobile base stations back to the PSTN point of presence (POP).
For details of where the equipment is intended to be used, see the country matrix below.
- AVIAT NETWORKS intends to market this equipment where a cross (X) is shown in the table below.
- The information contained in this table has been gathered from the relevant government authorities and
relates only to European countries participating in the R&TTE directive.
It s h ou l d b e n oted th at a l i c en s e to op er ate th i s eq u i p men t i s l i kel y to b e n ec es s ar y, an d
th e ap p r op r i ate r eg u l ator y ad mi n i s tr ati on s h ou l d b e c on tac ted .
VI AVIAT NETWORKS
260-668256-014 DECEMBER 2016 VII

Table of Contents
Copyright & Terms of Use i
Aviat Networks Technical & Sales Support ii
Product Compliance Notes iii
Regulatory Information for ODU 600, 5.8GHz Band iii
International Use of 5.8GHz iii
Networking Devices in Electric Power Substations iii
WEEE Directive iv
RoHS Directive iv
Declaration of Conformity, R&TTE Directive, 1999/5/EC iv
Table of Contents i
CHAPTER 1. INTRODUCTION 1
Purpose and Scope 1
Acronyms 1
References 4
Document Conventions 5
How This Manual Is Organized 5
CHAPTER 2. EXAMPLE TOPOLOGIES 7

Topology Diagrams 7
Pre-Requisite Global Configurations 9
Configuring Loopback Interfaces 9
Configuring IP addresses for Physical Interfaces 9
IS-IS Router Configuration 10
IS-IS Circuit Configuration 10
Useful Show Commands 10
Example Configuration Scripts: IPv4 and IS-IS 11
Topology A 11
Topology B 14
Topology C 20
CHAPTER 3. MPLS TRAFFIC ENGINEERING FUNDAMENTALS 33

TE-Link Configuration 33
260-668256-014 DECEMBER 2016 I

Enabling TE Extensions for IS-IS 35

Configuring RSVP-TE 36
Example Configuration Scripts: TE links, ISIS-TE and RSVP-TE 37
Configuration for Topology A 37
Configuration for Topology B 41
Configuration for Topology C 47
CHAPTER 4. CONFIGURING MPLS TRAFFIC ENGINEERED LSPS 61

Path Options for TE-Tunnels 61
Dynamic Path Option 61
Explicit Path Option 62
Bandwidth Attribute for TE-Tunnels 64
Priority Attributes for TE-Tunnels 64
Affinity Attribute for TE-Tunnels 65
Record-route Option 65
Example Configuration Scripts: Dynamic MPLS-TE Tunnels 66
Dynamic Tunnels for Topology A 66
Dynamic Tunnels for Topology B 67
Dynamic Tunnels for Topology C 68
CHAPTER 5. LAYER 2 VIRTUAL PRIVATE NETWORKS 71

Reference Model For L2 Transport Over MPLS 71
Service Types 71
Attachment Circuit Types 72
Pseudo-wires 72
Pseudo-wire Establishment 72
Pseudo-wire Modes: Raw vs. Tagged 73
Targeted LDP Configuration 74
VPWS Configuration 75
Configuration Example: VPWS with Port Based Attachment Circuit 75
Configuration Example: VPWS with Port+Vlan Based Attachment Circuit 76
VPLS Configuration 77
Configuration Example: VPLS with VLAN Based Attachment Circuit 77
II AVIAT NETWORKS
CHAPTER 6. LAYER 3 VIRTUAL PRIVATE NETWORKS 83

Overview 83
VRF Configuration 84
L3VPN Route AND Label Distribution 85
Route Distinguisher (RD) 85
Route Target (RT) 86
MP-BGP Peering 86
Configure CE-PE Routing 87
Static Routing 88
eBGP Routing 88
Example Configuration Scripts 90
VRF & MP-BGP Configuration (Topology B) 90
CE-PE Static Routing (Topology B) 97
CE-PE eBGP (Topology B) 98
CHAPTER 7. MPLS PING & TRACE ROUTE 101

Introduction 101
ping mpls IPv4 target (LDP signalled LSP) 101
ping mpls RSVP-TE tunnel 102
ping mpls L2VPN Pseudowire 103
trace mpls IPv4 target (LDP signalled LSP) 104
CHAPTER 8. END TO END LSP PROTECTION 105

Failure Detection 105
BFD for failure detection on MPLS-TE Tunnels 105
Protection Mode 1:1 106
Configuration Example – 1:1 End To End Protection With BFD (Using explicit paths for
working and protecting LSPs) 107
CHAPTER 9. APPENDIX A – MPLS LABEL RANGES IN AOS 111

Nomenclature 111
Remote Label 111
Local Label 111
Local Label Ranges 111
Remote Label Ranges 113
260-668256-014 DECEMBER 2016 III

Chapter 1. Introduction
Aviat Networks MPLS provides a feature-rich, efficient and flexible label switching capability as
required by industry standards. It enables service providers to implement VPN services, traffic
engineering, redundancy and fast failure detection in the networks. Key MPLS features
supported on AOS include:
l LDP and RSVP-TE for MPLS LSP signalling
l Layer 2 and Layer 3 VPNs
l TDM transport over MPLS networks
l Rich set of traffic engineering capabilities
l Fast failure detection and LSP protection
l Quality of Service
l Diagnostics and OAM functions
Purpose and Scope

This document describes configuration of MPLS functionality on CTR 8500. The reader is
expected to have a basic understanding of IP routing and MPLS technologies, as well as basic
familiarity with Aviat Networks CTR platform.
Some MPLS features are described in their dedicated configuration manuals. Please refer to
section References for a list of relevant Aviat Networks user documents.
Acronyms
Table 1-1. Acronyms
Acronym Explanation
ABR Area Boundary Router (in OSPF)
ARP Address Resolution Protocol
AS Autonomous System
ASBR Autonomous System Boundary Router (in
OSPF)
ATM Asynchronous Transfer Mode
BFD Bidirectional Forwarding Detection – A fast
failure detection protocol
260-668256-014 DECEMBER 2016 1

CHAPTER 1. INTRODUCTION
BGP Border Gateway Protocol

CE Customer Edge
CE Router Customer Edge Router
CLI Command Line Interface
CSPF Constrained SPF (Constrained Shortest Path
First) – Algorithm for computing path on
traffic engineered LSP using the traffic
engineering topology information in the traffic
engineering database.
FEC Forwarding Equivalence Class
FTN Tunnel Forwarding Equivalence Class (FTN) to Next
Hop Label Forwarding Entry (NHLFE) Tunnel
- Maps a Forwarding Equivalence Class (e.g. IP
traffic with specific destination address, DSCP
markings) to an MPLS LSP at the edge of an
MPLS network
GMPLS Generalized MPLS
IGP Interior Gateway Protocol
IP Internet Protocol
IPv4 Internet Protocol Version 4
IPv6 Internet Protocol Version 6
IS-IS Intermediate System to Intermediate System
(An Interior Gateway Protocol)
L2VPN Layer 2 Virtual Private Network
L3 Layer 3 - Network Layer
L3VPN Layer 3 Virtual Private Network
LAN Local Area Network
LB Link Bundling
LDP Label Distribution Protocol – Used for
signalling MPLS LSP labels
LER Label Edge Router
LSP Label Switched Path
LSR Label Switch Router
ME Maintenance Entity
MEG Maintenance Entity Group
MEP Maintenance Entity Group End Point
MIB Management Information Base
MP-BGP Multiprotocol Extensions for BGP
MPLS Multi-Protocol Label Switching
2 AVIAT NETWORKS
OAM Operations, Administration and Management

OSPF Open Shortest Path First (An Interior Gateway
Protocol)
PE Provider Edge
PE Router Provider Edge Router
PHB Per Hop Behaviour
PSC Per Hop Behaviour Scheduling Class
PSC Interfaces Packet Switching Capable Interfaces
PST Path Segmented Tunnel
PW Pseudo-wire
PWE Pseudo-wire Emulation Edge to Edge
QoS Quality of Service
RD Route Distinguisher – Used in L3VPN. RD is
appended to an IPv4 address in a customer’s
VRF to convert it to VPNv4 address which can
be signalled to remote PEs via MP-BGP
RSVP Resource Reservation Protocol
RSVPTE Resource Reservation Protocol with Traffic
Engineering – Used for signalling traffic
engineered tunnels/LSPs
RT Route Target – Used in L3VPN to control
dissemination of customer VRF routes
SAToP Structure-Agnostic Time Division Multiplexing
(TDM) over Packet
SNMP Simple Network Management Protocol
TCP Transmission Control Protocol
TDM Time Division Multiplexing
TE Traffic Engineering
TE Link Traffic Engineering Link
T-LDP Targeted Label Distribution Protocol – Mainly
used to signal L2VPN Pseudo-wire labels
across PE routers
TLM TE Link Manager – A software entity in AOS
responsible for managing TE link information
TLV Type Length Value Encoding
UDP User Datagram Protocol
VC Virtual Circuit
VCCV Virtual Circuit Connectivity Verification
VFI Virtual Forwarding Instance
260-668256-014 DECEMBER 2016 3

CHAPTER 1. INTRODUCTION
VLAN Virtual Local Area Network

VLL Virtual Leased Line
VPLS Virtual Private LAN Service
VPN Virtual Private Network
VPWS Virtual Private Wire Service
References
l CTR 8500/8300 Getting Started - Configuration
l CTR 8500/8300 Configuration – IP
l CTR 8500/8300 Configuration – ISIS
l CTR 8500/8300 Configuration – MEF-8 CESoETH/MPLS SAToP
l CTR 8500/8300 Configuration – MPLS Packet Loss and Delay Measurement
l CTR 8500/8300 CLI Reference Manual Vol 1
l CTR 8500/8300 CLI Reference Manual Vol 2
l E. Rosen, A. Viswanathan, R. Callon, “Multiprotocol Label Switching Architecture”,
RFC 3031, January 2001.
l R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, A. Viswanathan, “A
Framework for Multiprotocol Label Switching”, draft-ietf-mpls-framework-05.txt,
September 1999.
l C. Boscher, P. Cheval, L. Wu, E. Gray, “LDP State Machine”, RFC 3215, January
2002.
l E. Rosen, D. Tappan, G. Federkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta, “MPLS
Label Stack Encoding”, RFC 3032, January 2001.
l L. Andersson, I.minei, B. Thomas, “LDP Specification”, RFC 5036, October 2007.
l D. Awduche, L. Berer, D. Gan, T. Li, G, Swallow, V. Srinivasan, “RSVP-TE:
Extensions to RSVP for LSP Tunnels”, RFC 3209, December 2001.
l S. Bryant, P. Pate, “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture”, RFC
3985, March 2005.
l L. Martini, N. El-Aawar, T. Smith, G. Heron, “Pseudowire Setup and Maintenance
Using the Label Distribution Protocol (LDP)”, RFC 4447, April 2006.
l L. Martini, E. Rosen, N. El-Aawar, G. Heron, “Encapsulation Methods for Transport
of Ethernet over MPLS Networks”, RFC 4448, April 2006.
l F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J.
Heinanen, “MPLS Support of Differentiated Services”, RFC 3270, May 2002.
l E. Rosen, Y. Rekhter, “BGP/MPLS IP Virtual Private Networks” , RFC 4364, Feb
2006.
4 AVIAT NETWORKS
Document Conventions
Table 1-2. Document Conventions
Convention Usage
Code Text CLI Commands
Code Italics User inputs to command
Blue code CLI Command Output
Red Code Output for configured value
How This Manual Is Organized

Communication networks can be viewed as being organized in multiple layers (physical, link,
network layers etc.) and planes (data, control, management). Aviat Networks MPLS supports
multiple protocols in each of the different layers and planes. OSPF, IS-IS and BGP are
supported for IPv4 routing. LSP signalling is supported via static configuration, LDP and
RSVP-TE. Layer 2 VPN pseudo-wires can be configured statically or via targeted LDP. Layer 3
VPNs support a number of options for routing between CE and PE devices. AOS
implementation is flexible and enables the service providers to choose any suitable protocol or
mechanism for each layer. This results in a large matrix of possible combinations of protocols
which cannot be covered individually. To address this problem, we have taken the following
approach in this manual:
l Interior gateway protocols are described in their own dedicated manuals.
l IS-IS is chosen as underlying IGP for all examples in this manual.
l A set of basic network topologies and relevant IP layer configurations are provided in
chapter 2. Most MPLS feature configuration examples are constructed over these
baseline configurations.
l Configuration examples for L2VPN and L3VPN are described over RSVP-TE based
LSPs.
l Where possible, configuration examples for a feature in higher layer builds upon the
examples for lower layer configuration in previous chapters.
260-668256-014 DECEMBER 2016 5

Chapter 2. Example Topologies

This section shows some basic network topologies and provides minimal IPv4 and IS-IS routing
configuration for these topologies. This is a pre-requisite configuration for various MPLS feature
examples which follow in subsequent chapters. The information in this section is concise. For
details on IS-IS configuration on AOS, please refer to CTR 8500/8300 Configuration – ISIS.
Topology Diagrams
Topology A- is used for describing simple point to point services such as VPWS
Topology B- is used for describing multipoint services such as VPLS and L3VPN
Topology C- is used for describing traffic engineering and LSP protection
Following conventions are used in this document:
l Rest of the document will refer to the topologies in this section by using the topology
labels -Topology A, Topology B etc.
l Labels CTR A, CTR B, etc. represent CTR devices within a topology. These labels are
used in the subsequent sections to refer to the particular device.
l GI 0/2 to GI 0/7 represent the front panel Ethernet ports on the CTR devices.
l ‘To CE’ represents a connection to a Customer Edge device. The connection to CE
device can be at layer 2 (Ethernet/VLAN) or layer 3 (IPv4), depending on the type of
MPLS service being configured. Details of CE-PE link configuration are specific to the
type of service being configured and are included in the service configuration
examples.
Figure 2-1. Topology A
260-668256-014 DECEMBER 2016 7

CHAPTER 2. EXAMPLE TOPOLOGIES
Figure 2-2. Topology B
Figure 2-3. Topology C
8 AVIAT NETWORKS
Pre-Requisite Global Configurations

For all examples in this manual, it is assumed that the CTR is in ‘customer bridge’ mode and
unwanted layer 2 protocols such as Spanning Tree Protocol and Generic Attribute Registration
Protocol (GARP) are turned off. The following configuration achieves this:
aos# configure terminal
aos(config)# switch default
aos(config-switch)# shutdown spanning-tree
aos(config-switch)# set gmrp disable
aos(config-switch)# set gvrp disable
aos(config-switch)# shutdown garp
aos(config-switch)# bridge-mode customer
aos(config-switch)# end
Configuring Loopback Interfaces

IPv4 loopback interfaces are used for multiple purposes including identifying the device,
addressing it for management, and directing control plane traffic to the device. Many routing
protocols (OSPF, BGP) and signalling protocols (LDP, RSVP) use loopback addresses to identify
the device. All examples in this manual require at least one loopback interface to be configured
on CTR. Loopback interface can be configured through the following commands:
aos(config)# interface loopback 0
aos(config-if)# ip address 1.1.1.1.255.255.255.255
aos(config-if)# no shutdown
aos(config-if)# end
In this example, loopback 0 is the identifier assigned to the interface – the format for this is
keyword loopback followed by a number. Apart from this, IP address and subnet mask are
required before the loopback interface is activated with no shutdown command.
Configuring IP addresses for Physical Interfaces

By default, all physical ports on CTR operate as layer 2 ports, called switchport, and are
mapped to the default switch context. In order to use the port for IP/MPLS functionality, it
must be unmapped from the default switch context and enabled for layer 3 operation with no
switchport command. After this, an IP address and subnet mask can be assigned. The following
example shows how to configure IP address 10.0.12.1/24 on front panel Ethernet port gi 0/2:
aos(config)# interface gigabitethernet 0/2
aos(config-if)# shutdown
aos(config-if)# no map switch default
aos(config-if)# no switchport
260-668256-014 DECEMBER 2016 9

aos(config-if)# ip address 10.0.12.1

255.255.255.0
aos(config-if)# exit
IS-IS Router Configuration

For example, in this manual, all devices will be configured with an instance of level-2 IS-IS
router. A net address and level-2 configuration is the minimal configuration required. In later
sections, traffic-engineering extensions for IS-IS will be enabled where required. Following
commands are required for the minimal configuration:
Enable IS-IS routing process.
aos(config)# router isis
Set Net ID
aos(config-router)# net 01:01:00:00:00:00:01:00
Assign a working area type
aos(config-router)# is-type level-2
aos(config-router)# exit
IS-IS Circuit Configuration

Minimal configuration for each IS-IS circuit includes specifying the circuit type (level 1, level 2)
and broadcast vs. point-to-point operating mode. All examples in this manual use level-2
circuits in broadcast mode. The following example shows how to configure this for front panel
Ethernet port gi 0/2:
aos(config)# interface gigabitethernet 0/2
aos(config-if)# ip router isis broadcast
aos(config-if)# isis circuit-type level-2-only
aos(config-if)# exit
Useful Show Commands

l aos# sh ip interface – Displays all IP enabled interfaces with address and
status information.
l aos# sh ip route – Displays all IP global routing table. This includes static
routes and routes learnt via all routing protocols.
l aos# sh ip isis route – Displays IS-IS specific routing table.
10 AVIAT NETWORKS
Example Configuration Scripts: IPv4 and IS-IS
Topology A
Configuration Summary
This section includes complete configuration scripts for all devices in Topology A on page 7. The
scripts can be copied into a text file and applied to a CTR device running with factory default
configuration. The scripts will configure basic IP interfaces in accordance with the following
tables. All devices are in the same IS-IS level-2 area and all circuits are broadcast type.
Table 2-1. Topology A - Device IP and IS-IS Configuration
Device Loopback Address IS-IS NET ID

CTR A 1.1.1.1/32 01:01:00:00:00:00:01:00
CTR B 2.2.2.2/32 01:01:00:00:00:00:02:00
CTR C 3.3.3.3/32 01:01:00:00:00:00:03:00
Table 2-2. Topology A - Port Connections and IP Addresses
Device Interface IP Address Connects to

CTR A Gi 0/2 10.0.12.1/24 CTR B Gi 0/2
CTR B Gi 0/2 10.0.12.2/24 CTR A Gi 0/2
CTR B Gi 0/3 10.0.23.2/24 CTR C gi 0/3
CTR C Gi 0/3 10.0.23.3/24 CTR B gi 0/3
CTR A Configuration
configure terminal
switch default
shutdown spanning-tree
set gmrp disable
set gvrp disable
shutdown garp
bridge-mode customer
end
configure terminal
interface loopback 0
ip address 1.1.1.1 255.255.255.255
no shutdown
end
configure terminal
260-668256-014 DECEMBER 2016 11

interface gigabitethernet 0/2

shutdown
no map switch default
no switchport
ip address 10.0.12.1 255.255.255.0
no shutdown
end
configure terminal
router isis
net 01:01:00:00:00:00:01:00
is-type level-2
exit
ip router isis
isis circuit-type level-2-only
exit
ip router isis broadcast
end
CTR B Configuration
configure terminal
switch default
set gmrp disable
set gvrp disable
shutdown garp
end
configure terminal
ip address 2.2.2.2 255.255.255.255
no shutdown
end
configure terminal
shutdown
no switchport
ip address 10.0.12.2 255.255.255.0
12 AVIAT NETWORKS
no shutdown
exit
shutdown
no switchport
ip address 10.0.23.2 255.255.255.0
no shutdown
end
configure terminal
router isis
net 01:01:00:00:00:00:02:00
is-type level-2
exit
ip router isis
exit
exit
end
CTR C Configuration
configure terminal
switch default
set gmrp disable
set gvrp disable
shutdown garp
end
configure terminal
ip address 3.3.3.3 255.255.255.255
no shutdown
end
260-668256-014 DECEMBER 2016 13

configure terminal
shutdown
no switchport
ip address 10.0.23.3 255.255.255.0
no shutdown
end
configure terminal
router isis
net 01:01:00:00:00:00:03:00
is-type level-2
exit
ip router isis
exit
end
Topology B
This section includes complete configuration scripts for all devices in Topology B on page 8.
The scripts can be copied into a text file and applied to a CTR device running with factory
default configuration. The scripts will configure basic IP interfaces in accordance with the
following tables. All devices are in the same IS-IS level-2 area and all circuits are broadcast
type.
Table 2-3. Topology B - Device IP and IS-IS Configuration

CTR A 1.1.1.1 01:01:00:00:00:00:01:00
CTR B 2.2.2.2 01:01:00:00:00:00:02:00
CTR C 3.3.3.3 01:01:00:00:00:00:03:00
CTR D 4.4.4.4 01:01:00:00:00:00:04:00
14 AVIAT NETWORKS
Table 2-4. Topology B - Port Connections and IP Addresses

CTR A Gi 0/2 10.0.12.1/24 CTR B Gi 0/2
CTR A Gi 0/4 10.0.14.1/24 CTR D Gi 0/4
CTR B Gi 0/2 10.0.12.2/24 CTR A Gi 0/2
CTR B Gi 0/3 10.0.23.2/24 CTR C Gi 0/3
CTR B Gi 0/5 10.0.24.2/24 CTR D Gi 0/5
CTR C Gi 0/3 10.0.23.3/24 CTR B Gi 0/3
CTR C Gi 0/6 10.0.34.3/24 CTR D Gi 0/6
CTR D Gi 0/4 10.0.14.4/24 CTR A Gi 0/4
CTR D Gi 0/5 10.0.24.4/24 CTR B Gi 0/5
CTR D Gi 0/6 10.0.34.4/24 CTR C Gi 0/6
CTR A Configuration
configure terminal
switch default
set gmrp disable
set gvrp disable
shutdown garp
end
configure terminal
ip address 1.1.1.1 255.255.255.255
no shutdown
end
configure terminal
shutdown
no switchport
ip address 10.0.12.1 255.255.255.0
no shutdown
exit
shutdown
no switchport
ip address 10.0.14.1 255.255.255.0
260-668256-014 DECEMBER 2016 15

no shutdown
end
configure terminal
router isis
net 01:01:00:00:00:00:01:00
is-type level-2
exit
ip router isis
exit
exit
end
CTR B Configuration
configure terminal
switch default
set gmrp disable
set gvrp disable
shutdown garp
end
configure terminal
ip address 2.2.2.2 255.255.255.255
no shutdown
end
configure terminal
shutdown
no switchport
ip address 10.0.12.2 255.255.255.0
no shutdown
16 AVIAT NETWORKS
exit
shutdown
no switchport
ip address 10.0.23.2 255.255.255.0
no shutdown
exit
shutdown
no switchport
ip address 10.0.24.2 255.255.255.0
no shutdown
end
configure terminal
router isis
net 01:01:00:00:00:00:02:00
is-type level-2
exit
ip router isis
exit
exit
exit
end
CTR C Configuration
configure terminal
switch default
set gmrp disable
set gvrp disable
260-668256-014 DECEMBER 2016 17

shutdown garp
end
configure terminal
ip address 3.3.3.3 255.255.255.255
no shutdown
end
configure terminal
shutdown
no switchport
ip address 10.0.23.3 255.255.255.0
no shutdown
exit
shutdown
no switchport
ip address 10.0.34.3 255.255.255.0
no shutdown
end
configure terminal
router isis
net 01:01:00:00:00:00:03:00
is-type level-2
exit
ip router isis
exit
exit
end
18 AVIAT NETWORKS
CTR D Configuration
configure terminal
switch default
set gmrp disable
set gvrp disable
shutdown garp
end
configure terminal
ip address 4.4.4.4 255.255.255.255
no shutdown
end
configure terminal
shutdown
no switchport
ip address 10.0.14.4 255.255.255.0
no shutdown
exit
shutdown
no switchport
ip address 10.0.24.4 255.255.255.0
no shutdown
exit
shutdown
no switchport
ip address 10.0.34.4 255.255.255.0
no shutdown
end
configure terminal
router isis
net 01:01:00:00:00:00:04:00
is-type level-2
exit
260-668256-014 DECEMBER 2016 19

ip router isis
exit
exit
exit
end
Topology C
This section includes complete configuration scripts for all devices in Topology C on page 8.
The scripts can be copied into a text file and applied to a CTR device running with factory
default configuration. The scripts will configure basic IP interfaces in accordance with the
following tables. All devices are in the same IS-IS level-2 area and all circuits are broadcast
type.
Table 2-5. Topology C - Device IP and IS-IS Configuration

CTR A 1.1.1.1 01:01:00:00:00:00:01:00
CTR B 2.2.2.2 01:01:00:00:00:00:02:00
CTR C 3.3.3.3 01:01:00:00:00:00:03:00
CTR D 4.4.4.4 01:01:00:00:00:00:04:00
CTR E 5.5.5.5 01:01:00:00:00:00:05:00
CTR F 6.6.6.6 01:01:00:00:00:00:06:00
CTR G 7.7.7.7 01:01:00:00:00:00:07:00
Table 2-6. Topology C - Port Connections and IP Addresses

CTR A Gi 0/2 10.0.12.1/24 CTR B Gi 0/2
CTR A Gi 0/3 10.0.16.1/24 CTR F Gi 0/3
CTR B Gi 0/2 10.0.12.2/24 CTR A Gi 0/2
20 AVIAT NETWORKS
CTR B Gi 0/4 10.0.26.2/24 CTR F Gi 0/4

CTR B Gi 0/6 10.0.23.2/24 CTR C Gi 0/6
CTR B Gi 0/7 10.0.27.2/24 CTR G Gi 0/7
CTR C Gi 0/4 10.0.37.3/24 CTR G Gi 0/4
CTR C Gi 0/5 10.0.34.3/24 CTR D Gi 0/5
CTR C Gi 0/6 10.0.23.3/24 CTR B Gi 0/6
CTR D Gi 0/2 10.0.45.4/24 CTR E Gi 0/2
CTR D Gi 0/5 10.0.34.4/24 CTR 5 Gi 0/5
CTR D Gi 0/7 10.0.46.4/24 CTR F Gi 0/7
CTR E Gi 0/2 10.0.45.5/24 CTR D Gi 0/2
CTR E Gi 0/5 10.0.56.5/24 CTR F Gi 0/5
CTR E Gi 0/6 10.0.57.5/24 CTR G Gi 0/6
CTR F Gi 0/3 10.0.16.6/24 CTR A Gi 0/3
CTR F Gi 0/4 10.0.26.6/24 CTR B Gi 0/4
CTR F Gi 0/5 10.0.56.6/24 CTR E Gi 0/5
CTR F Gi 0/7 10.0.46.6/24 CTR D Gi 0/7
CTR G Gi 0/4 10.0.37.7/24 CTR C Gi 0/4
CTR G Gi 0/6 10.0.57.7/24 CTR E Gi 0/6
CTR G Gi 0/7 10.0.27.7/24 CTR B Gi 0/7
CTR A Configuration
configure terminal
switch default
set gmrp disable
set gvrp disable
shutdown garp
end
configure terminal
ip address 1.1.1.1 255.255.255.255
no shutdown
end
configure terminal
shutdown
260-668256-014 DECEMBER 2016 21

no switchport
ip address 10.0.12.1 255.255.255.0
no shutdown
exit
shutdown
no switchport
ip address 10.0.16.1 255.255.255.0
no shutdown
end
configure terminal
router isis
net 01:01:00:00:00:00:01:00
is-type level-2
exit
ip router isis
exit
exit
end
CTR B Configuration
configure terminal
switch default
set gmrp disable
set gvrp disable
shutdown garp
end
configure terminal
ip address 2.2.2.2 255.255.255.255
no shutdown
22 AVIAT NETWORKS
end
configure terminal
shutdown
no switchport
ip address 10.0.12.2 255.255.255.0
no shutdown
exit
shutdown
no switchport
ip address 10.0.26.2 255.255.255.0
no shutdown
exit
shutdown
no switchport
ip address 10.0.23.2 255.255.255.0
no shutdown
exit
shutdown
no switchport
ip address 10.0.27.2 255.255.255.0
no shutdown
end
configure terminal
router isis
net 01:01:00:00:00:00:02:00
is-type level-2
exit
ip router isis
exit
exit
260-668256-014 DECEMBER 2016 23


exit
exit
end
CTR C Configuration
configure terminal
switch default
set gmrp disable
set gvrp disable
shutdown garp
end
configure terminal
ip address 3.3.3.3 255.255.255.255
no shutdown
end
configure terminal
shutdown
no switchport
ip address 10.0.37.3 255.255.255.0
no shutdown
exit
shutdown
no switchport
ip address 10.0.34.3 255.255.255.0
no shutdown
exit
24 AVIAT NETWORKS

shutdown
no switchport
ip address 10.0.23.3 255.255.255.0
no shutdown
end
configure terminal
router isis
net 01:01:00:00:00:00:03:00
is-type level-2
exit
ip router isis
exit
exit
exit
end
CTR D Configuration
configure terminal
switch default
set gmrp disable
set gvrp disable
shutdown garp
end
configure terminal
ip address 4.4.4.4 255.255.255.255
no shutdown
260-668256-014 DECEMBER 2016 25

end
configure terminal
shutdown
no switchport
ip address 10.0.45.4 255.255.255.0
no shutdown
exit
shutdown
no switchport
ip address 10.0.34.4 255.255.255.0
no shutdown
exit
shutdown
no switchport
ip address 10.0.46.4 255.255.255.0
no shutdown
end
configure terminal
router isis
net 01:01:00:00:00:00:04:00
is-type level-2
exit
ip router isis
exit
exit
exit
26 AVIAT NETWORKS
end
CTR E Configuration
configure terminal
switch default
set gmrp disable
set gvrp disable
shutdown garp
end
configure terminal
ip address 5.5.5.5 255.255.255.255
no shutdown
end
configure terminal
shutdown
no switchport
ip address 10.0.45.5 255.255.255.0
no shutdown
exit
shutdown
no switchport
ip address 10.0.56.5 255.255.255.0
no shutdown
exit
shutdown
no switchport
ip address 10.0.57.5 255.255.255.0
no shutdown
end
configure terminal
router isis
net 01:01:00:00:00:00:05:00
260-668256-014 DECEMBER 2016 27

is-type level-2
exit
ip router isis
exit
exit
exit
end
CTR F Configuration
configure terminal
switch default
set gmrp disable
set gvrp disable
shutdown garp
end
configure terminal
ip address 6.6.6.6 255.255.255.255
no shutdown
end
configure terminal
shutdown
no switchport
ip address 10.0.16.6 255.255.255.0
no shutdown
exit
28 AVIAT NETWORKS
shutdown
no switchport
ip address 10.0.26.6 255.255.255.0
no shutdown
exit
shutdown
no switchport
ip address 10.0.56.6 255.255.255.0
no shutdown
exit
shutdown
no switchport
ip address 10.0.46.6 255.255.255.0
no shutdown
end
configure terminal
router isis
net 01:01:00:00:00:00:06:00
is-type level-2
exit
ip router isis
exit
exit
exit
exit
260-668256-014 DECEMBER 2016 29

end
CTR G Configuration
configure terminal
switch default
set gmrp disable
set gvrp disable
shutdown garp
end
configure terminal
ip address 7.7.7.7 255.255.255.255
no shutdown
end
configure terminal
shutdown
no switchport
ip address 10.0.37.7 255.255.255.0
no shutdown
exit
shutdown
no switchport
ip address 10.0.57.7 255.255.255.0
no shutdown
exit
shutdown
no switchport
ip address 10.0.27.7 255.255.255.0
no shutdown
end
configure terminal
router isis
net 01:01:00:00:00:00:07:00
30 AVIAT NETWORKS
is-type level-2
exit
ip router isis
exit
exit
exit
end
260-668256-014 DECEMBER 2016 31

Chapter 3. MPLS Traffic

Engineering Fundamentals
MPLS traffic engineering allows a high level of control over the path which traffic takes through
the network. The tunnel paths can be determined based on link parameters such as available
bandwidth, administrative colouring etc. allowing the operators to balance the utilization of
links. Before MPLS traffic engineered tunnels can be set up, a number of underlying parameters
and signalling protocols have to be configured in the network. Configuration of these underlying
elements is the subject of this chapter. These elements include:
l Traffic engineering parameters for individual links. In AOS, this information is
encapsulated in Traffic Engineering Link (TE-Link).
l Network-wide dissemination of traffic engineering link parameters by enabling TE
extensions for the IGP
I n SW Rel ease 3.4, TE Extensi ons are onl y supported for I S-I S. TE-
extensi on support for OSPF i s experi mental .
l Enabling and configuring RSVP-TE entities on all devices. RSVP-TE is the protocol
which signals the LSPs.
TE-Link Configuration
In CTR, a TE-Link is a logical interface that describes the traffic engineering parameters of a
link connected to the router. The link parameters are configured for the egress direction. This
means that for a link ‘A-B’ between devices A and B, a TE-link has to be configured on device A
describing parameters for traffic in A→ B direction, and another TE-link on device B for traffic
in B→ A direction.
The supported Traffic Engineering parameters are as follows:
l Traffic Engineering Metric – By default this has the same value as IGP metric for the
link. However, service proviers are free to change the value and use any meaning/
interpretation that suits their needs. For example, metric can be configured based on
the latency of the link.
l Resource-class or Administrative colour – Allows links to be administratively grouped
allowing the user to prefer or exclude certain groups for an LSP. This value is a 32-bit
bit field. Each bit can have a meaning assigned by a service provider. The bit-field for
a particular link is compared against configured ‘affinity’ attribute of MPLS tunnel
(See chapter 4), to determine if a tunnel is allowed to use this link.
l Maximum Link Bandwidth
260-668256-014 DECEMBER 2016 33

CHAPTER 3. MPLS TRAFFIC ENGINEERING FUNDAMENTALS
l Maximum reservable Bandwidth – This parameter can be more or less than the
maximum link bandwidth allowing the operators to enable over-subscription/ under-
subscription of links
l Minimum reservable bandwidth
The mi ni mum reservabl e bandwi dth i s adverti sed i n RSVP-TE
si gnal l i ng and i s compared wi th user confi gured val ue for the
tunnel . However, AOS does not support path cal cul ati on usi ng
mi ni mum reservabl e bandwi dth as a constrai nt.
TE- Links can only be created on IP interfaces which do not already have MPLS
enabled on them. If a TE- link is to be created over a physical interface, mpls ip must
NOT be enabled on that interface before TE-link creation. The process of mapping the
TE-Link to a physical interface will enable the mpls ip automatically.
I n SW Rel ease 3.4, support for creati ng TE-Li nks over I VRs (VLAN I P
I nterfaces) i s not avai l abl e.
Ensure that the l ocal TE-Li nk I P address matches the I P i nterface i t wi l l be
mapped to. I SI S-TE wi l l onl y fl ood the address speci fi ed i n the TE-Li nk,
whi ch can onl y be manual l y confi gured i n Rel ease 3.4.
The following example shows configuration of a TE-link on a link from CTR A to CTR B (A→ B
direction), in Topology A.
Globally enable support for MPLS traffic engineering

aos(config)# mpls traffic-eng tunnels
Create a TE-LINK called te12 and specify IP addresses for local and remote ends. Remote router
ID is the router ID assigned to TE-router at the other end of the link.
aos(config)# mpls traffic-eng
aos(config-mpls-te)# te-link te12
aos(config-mpls-te-link)# address-type ipv4
aos(config-mpls-te-link)# local te-link ipv4
10.0.12.1 remote te-link ipv4 10.0.12.2
aos(config-mpls-te-link)# remote router-id
2.2.2.2
aos(config-mpls-te-link)# resource-class class-
value 0x1
aos(config-mpls-te-link)# no shutdown
Map the TE-Link to a physical interface, in this case front panel port 2, and specify link
parameters:
aos(config-mpls-te-link)# int gi 0/2
aos(config-mpls-comp-link)# min lsp bandwidth
1024
aos(config-mpls-comp-link)# max reservable
bandwidth 20000
34 AVIAT NETWORKS
aos(config-mpls-comp-link)# switching-capability
psc1 encoding packet
aos(config-mpls-comp-link)# no shutdown
aos(config-mpls-comp-link)# exit
Enable IGP advertisement for this TE-Link:

aos(config-mpls-te-link)# advertise
aos(config-mpls-te-link)# exit
aos(config-mpls-te)# exit
Enabling TE Extensions for IS-IS

Traffic Engineering extensions on ISIS can be enabled to flood TE-Link advertisements and
calculate tunnel paths for RSVP-TE via the following steps in the router isis configuration
mode:
1. Set the traffic engineering router ID using the command mpls traffic-eng
router id x.x.x.x. The router ID must correspond to the IP address of a
configured loopback address on the CTR.
2. Enable the TE-Database and begin TE-Link information flooding using the
command mpls traffic-eng [level-1 | level-2 | level-1-2]. TE
extensions can be enabled on level 1 only, level 2 only or both. Not selecting a level
will enable TE extensions all currently enabled ISIS levels.
The following example shows configuring TE extensions for IS-IS on CTR A, in Topology A:
Enable ISIS routing process.
aos(config)# router isis
Set Traffic Engineering router ID.

aos(config-router)# mpls traffic-eng router-id
1.1.1.1
Enable Traffic Engineering Database and flooding

aos(config-router)# mpls traffic-eng
aos(config-router)# end
Enabl i ng the TE Extensi ons on an I SI S l evel wi l l automati cal l y set the I SI S
metri c styl e to wi de for that l evel . There i s currentl y no support for the
transi ti onal metri c styl e.
260-668256-014 DECEMBER 2016 35

Configuring RSVP-TE
RSVP-TE is the signalling protocol used for setting up traffic-engineered LSPs in an MPLS
network. When a TE-tunnel is configured, the path for the tunnel is computed at the head end
router by executing CSPF algorithm over the TE database1. The tunnel is signalled over
calculated path via RSVP-TE protocol which communicates the path information to each router
along the path, checks the router at each hop for errors and signals the ingress and egress labels
for each hop along the signalled tunnel. All routers participating in traffic engineering must
have RSVP-TE configured.
RSVP-TE must first be configured globally by specifying a router ID which corresponds to an
already configured loopback address, the outgoing label range, the hello packet refresh interval
and the maximum number of interfaces participating in RSVP.
The confi gured Label range onl y appl i es to outgoi ng l abel s bei ng
di stri buted from the l ocal node to the far end on l abel exchange (i ngress
packets wi l l be tagged wi th thi s l abel ). CTR i s abl e to accept any unused
i ncomi ng l abel from i ts nei ghbouri ng devi ces.
Each interface participating in RSVP-TE signalling must also be specified in the RSVP
configuration, in order for the label exchange to take place on those interfaces.
F or each i nterface parti ci pati ng i n RSVP-TE, a ‘ si gnal l i ng l i nk attri butes’
parameter can be set. Thi s must match the Resource Cl ass set for the TE-
Li nk confi gured for the i nterface i n order for tunnel s wi th resource cl ass
based constrai nts to be si gnal l ed successful l y.
The following example shows configuration of RSVP-TE entity on CTR A, in Topology A:
Set global (per router) configuration for RSVP including router ID and label range and enable
the RSVP entity:
aos(config)# rsvp
aos(config-rsvp)# set rsvp disable
aos(config-rsvp)# router-id 1.1.1.1
aos(config-rsvp)# signalling label range min
100001 max 100100
aos(config-rsvp)# signalling hello supported
aos(config-rsvp)# signalling hello refresh
interval 30000
aos(config-rsvp)# signalling max interfaces 8
aos(config-rsvp)# set rsvp enable
Enable RSVP on individual interfaces which are to be made available for MPLS LSPs – in this
case it is front panel port 2:
aos(config-rsvp)# interface gi 0/2
aos(config-rsvp-if)# signalling link attributes
0x1
aos(config-rsvp-if)# no shutdown
1In certain cases, for example when using loose hops in LSP path specification, only part of the
CSPF computation happens at the head-end.
36 AVIAT NETWORKS
aos(config-rsvp-if)# exit
aos(config-rsvp-if)# exit

l sh mpls traffic engineering te-link: Shows details and status of all TE-
links on the router.
l sh rsvp req: Shows requests sent via RSVP protocol. This will display useful
information when a tunnel has been configured on the device.
Example Configuration Scripts: TE links, ISIS-TE

and RSVP-TE
This section provides scripts with all pre-requisite configurations for setting up MPLS-TE
tunnels. Complete configuration scripts for all devices in topologies A, B and C from section 2.1
are provided. These scripts perform the following operations:
l Configure TE-Links for each IP link in the MPLS network (excluding links to CE
devices).
l Enable TE Extensions for IS-IS including wide metric support.
l Enable and configure RSVP-TE on all devices. RSVP-TE is enabled on all MPLS
interfaces.
The scripts can be copied into a text file and applied to a CTR device. It is assumed that before
applying the scripts in this section, the appropriate baseline IP and IS-IS configuration from the
section Example Configuration Scripts: IPv4 and IS-IS on page 11 have been applied to the
devices.
After the scripts in this section are applied, the network will be ready for setting up MPLS-TE
tunnels via user specified constraints.
Configuration for Topology A

CTR A Configuration
configure terminal
mpls traffic-eng tunnels
mpls traffic-eng
te-link te12
address-type ipv4
local te-link ipv4 10.0.12.1 remote te-link ipv4
10.0.12.2
remote router-id 2.2.2.2
resource-class class-value 0x1
260-668256-014 DECEMBER 2016 37

no shutdown
int gi 0/2
min lsp bandwidth 1024
max reservable bandwidth 20000
switching-capability psc1 encoding packet
no shutdown
exit
advertise
exit
exit
configure terminal
router isis
mpls traffic-eng router-id 1.1.1.1
mpls traffic-eng
end
rsvp
set rsvp disable
router-id 1.1.1.1
signalling label range min 100101 max 100200
signalling hello supported
signalling hello refresh interval 30000
signalling max interfaces 8
set rsvp enable
interface gi 0/2
signalling link attributes 0x1
no shutdown
exit
exit
CTR B Configuration
configure terminal
mpls traffic-eng
te-link te21
address-type ipv4
10.0.12.1
no shutdown
int gi 0/2
38 AVIAT NETWORKS

no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te23
address-type ipv4
10.0.23.3
no shutdown
int gi 0/3
no shutdown
exit
advertise
exit
exit
configure terminal
router isis
end
rsvp
set rsvp disable
router-id 2.2.2.2
set rsvp enable
interface gi 0/2
no shutdown
exit
interface gi 0/3
no shutdown
exit
exit
260-668256-014 DECEMBER 2016 39

CTR C Configuration
configure terminal
mpls traffic-eng
te-link te32
address-type ipv4
10.0.23.2
no shutdown
int gi 0/3
no shutdown
exit
advertise
exit
exit
configure terminal
router isis
end
rsvp
set rsvp disable
router-id 3.3.3.3
set rsvp enable
interface gi 0/3
no shutdown
exit
exit
40 AVIAT NETWORKS
Configuration for Topology B

CTR A Configuration
configure terminal
mpls traffic-eng
te-link te12
address-type ipv4
10.0.12.2
no shutdown
int gi 0/3
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te14
address-type ipv4
10.0.14.4
no shutdown
int gi 0/4
no shutdown
exit
advertise
exit
exit
configure terminal
router isis
end
260-668256-014 DECEMBER 2016 41

rsvp
set rsvp disable
router-id 1.1.1.1
set rsvp enable
interface gi 0/2
no shutdown
exit
interface gi 0/4
no shutdown
exit
exit
CTR B Configuration
configure terminal
mpls traffic-eng
te-link te21
address-type ipv4
10.0.12.1
no shutdown
int gi 0/2
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te24
address-type ipv4
10.0.24.4
42 AVIAT NETWORKS

no shutdown
int gi 0/5
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te23
address-type ipv4
10.0.23.3
no shutdown
int gi 0/3
no shutdown
exit
advertise
exit
exit
configure terminal
router isis
end
rsvp
set rsvp disable
router-id 2.2.2.2
set rsvp enable
interface gi 0/2
no shutdown
exit
interface gi 0/3
260-668256-014 DECEMBER 2016 43


no shutdown
exit
interface gi 0/5
no shutdown
exit
exit
CTR C Configuration
configure terminal
mpls traffic-eng
te-link te32
address-type ipv32
10.0.23.2
no shutdown
int gi 0/3
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te34
address-type ipv4
10.0.34.4
no shutdown
int gi 0/6
no shutdown
exit
advertise
44 AVIAT NETWORKS
exit
exit
configure terminal
router isis
end
rsvp
set rsvp disable
router-id 3.3.3.3
set rsvp enable
interface gi 0/3
no shutdown
exit
interface gi 0/6
no shutdown
exit
exit
CTR D Configuration
configure terminal
mpls traffic-eng
te-link te41
address-type ipv4
10.0.14.1
no shutdown
int gi 0/4
no shutdown
exit
advertise
exit
exit
260-668256-014 DECEMBER 2016 45

mpls traffic-eng
te-link te42
address-type ipv4
10.0.24.2
no shutdown
int gi 0/5
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te43
address-type ipv4
10.0.34.3
no shutdown
int gi 0/6
no shutdown
exit
advertise
exit
exit
configure terminal
router isis
end
rsvp
set rsvp disable
router-id 4.4.4.4
46 AVIAT NETWORKS
set rsvp enable

interface gi 0/4
no shutdown
exit
interface gi 0/5
no shutdown
exit
interface gi 0/6
no shutdown
exit
exit
Configuration for Topology C

CTR A Configuration
configure terminal
mpls traffic-eng
te-link te12
address-type ipv4
10.0.12.2
no shutdown
int gi 0/2
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te16
address-type ipv4
10.0.16.6
260-668256-014 DECEMBER 2016 47


no shutdown
int gi 0/3
no shutdown
exit
advertise
exit
exit
configure terminal
router isis
end
rsvp
set rsvp disable
router-id 1.1.1.1
set rsvp enable
interface gi 0/2
no shutdown
exit
interface gi 0/3
no shutdown
exit
exit
CTR B Configuration
configure terminal
mpls traffic-eng
te-link te21
address-type ipv4
10.0.12.1
no shutdown
48 AVIAT NETWORKS
int gi 0/2
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te26
address-type ipv4
10.0.26.6
no shutdown
int gi 0/4
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te27
address-type ipv4
10.0.27.7
no shutdown
int gi 0/7
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te23
260-668256-014 DECEMBER 2016 49

address-type ipv4
10.0.23.3
no shutdown
int gi 0/6
no shutdown
exit
advertise
exit
exit
configure terminal
router isis
end
rsvp
set rsvp disable
router-id 2.2.2.2
set rsvp enable
interface gi 0/2
no shutdown
exit
interface gi 0/4
no shutdown
exit
interface gi 0/6
no shutdown
exit
interface gi 0/7
no shutdown
exit
exit
50 AVIAT NETWORKS
CTR C Configuration
configure terminal
mpls traffic-eng
te-link te32
address-type ipv4
10.0.23.2
no shutdown
int gi 0/6
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te37
address-type ipv4
10.0.37.7
no shutdown
int gi 0/4
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te34
address-type ipv4
10.0.34.4
260-668256-014 DECEMBER 2016 51

no shutdown
int gi 0/5
no shutdown
exit
advertise
exit
exit
configure terminal
router isis
end
rsvp
set rsvp disable
router-id 3.3.3.3
set rsvp enable
interface gi 0/4
no shutdown
exit
interface gi 0/5
no shutdown
exit
interface gi 0/6
no shutdown
exit
exit
CTR D Configuration
configure terminal
mpls traffic-eng
te-link te43
address-type ipv4
52 AVIAT NETWORKS

10.0.34.3
no shutdown
int gi 0/5
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te46
address-type ipv4
10.0.46.46.6
no shutdown
int gi 0/7
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te45
address-type ipv4
10.0.45.5
no shutdown
int gi 0/2
no shutdown
exit
260-668256-014 DECEMBER 2016 53

advertise
exit
exit
configure terminal
router isis
end
rsvp
set rsvp disable
router-id 4.4.4.4
set rsvp enable
interface gi 0/2
no shutdown
exit
interface gi 0/5
no shutdown
exit
interface gi 0/7
no shutdown
exit
exit
CTR E Configuration
configure terminal
mpls traffic-eng
te-link te56
address-type ipv4
10.0.56.6
no shutdown
int gi 0/1
54 AVIAT NETWORKS

no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te57
address-type ipv4
10.0.57.7
no shutdown
int gi 0/6
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te54
address-type ipv4
10.0.45.4
no shutdown
int gi 0/2
no shutdown
exit
advertise
exit
exit
configure terminal
router isis
end
rsvp
260-668256-014 DECEMBER 2016 55

set rsvp disable

router-id 5.5.5.5
set rsvp enable
interface gi 0/1
no shutdown
exit
interface gi 0/2
no shutdown
exit
interface gi 0/6
no shutdown
exit
exit
CTR F Configuration
configure terminal
mpls traffic-eng
te-link te61
address-type ipv4
10.0.16.1
no shutdown
int gi 0/3
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te62
address-type ipv4
56 AVIAT NETWORKS

10.0.26.2
no shutdown
int gi 0/4
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te64
address-type ipv4
10.0.46.4
no shutdown
int gi 0/7
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te65
address-type ipv4
10.0.56.5
no shutdown
int gi 0/1
no shutdown
exit
260-668256-014 DECEMBER 2016 57

advertise
exit
exit
configure terminal
router isis
end
rsvp
set rsvp disable
router-id 6.6.6.6
set rsvp enable
interface gi 0/1
no shutdown
exit
interface gi 0/3
no shutdown
exit
interface gi 0/4
no shutdown
exit
interface gi 0/7
no shutdown
exit
exit
CTR G Configuration
configure terminal
mpls traffic-eng
te-link te72
address-type ipv4
10.0.27.2
no shutdown
58 AVIAT NETWORKS
int gi 0/7
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te75
address-type ipv4
10.0.57.5
no shutdown
int gi 0/6
no shutdown
exit
advertise
exit
exit
mpls traffic-eng
te-link te73
address-type ipv4
10.0.37.3
no shutdown
int gi 0/4
no shutdown
exit
advertise
exit
exit
configure terminal
router isis
260-668256-014 DECEMBER 2016 59


end
rsvp
set rsvp disable
router-id 7.7.7.7
set rsvp enable
interface gi 0/4
no shutdown
exit
interface gi 0/6
no shutdown
exit
interface gi 0/7
no shutdown
exit
exit
60 AVIAT NETWORKS
Chapter 4. Configuring MPLS

Traffic Engineered LSPs
AOS allows operators a great degree of control over routing of MPLS tunnels1. This control is
exercised mainly by specifying various attributes of the tunnels. These attributes are described
in the sections below.
Path Options for TE-Tunnels

Direct control over path taken by a tunnel can be exercised by configuring path options, which
can be dynamic or explicit.
Dynamic Path Option

With dynamic path option, the tunnel path is calculated based on the lowest cost path which
satisfies all other constraints specified for the tunnel, such as bandwidth, resource class. The
path is calculated using the TE-metrics in the TE Database.
Note that the default value of TE-metric is the IGP cost of the link. Unless some TE-link metrics
have been changed, the tunnel configured with dynamic path option will follow the IGP’s
lowest cost path if this path meets all the constraints.
The following example shows configuration of a TE- tunnel from CTR A to CTR B in Topology A
1RFC-3209 defines LSP tunnel as follows:
Once a label is assigned to a set of packets, the label effectively defines the ‘flow’ through the
LSP. We refer to such an LSP as an ‘LSP tunnel’ because the traffic through it is opaque to
intermediate nodes along the label switched path.
The terms LSP Tunnel/MPLS Tunnel and LSP are often used interchangeably in literature. The
distinction is usually not important except in the cases of protected tunnel where a single
tunnel can have two LSPs: a working (main) LSP and a protecting (backup) LSP.
From the perspective of user configuration in CTR, an MPLS Tunnel is an interface on a device
with an identifier assigned to it. Once established, the tunnel can be used as a next hop for an
IP address, bound to an L2VPN pseudo-wire or assigned an L3VPN binding. The LSP is the
actual label switched path which the tunnel takes through the network and is identified by an
LSP ID as well as state information within individual routers which includes incoming and
outgoing labels at each hop. The tunnel is configured by an operator, LSP is calculated and
signalled internally by AOS software in cooperation with other routers along the path.
260-668256-014 DECEMBER 2016 61

CHAPTER 4. CONFIGURING MPLS TRAFFIC ENGINEERED LSPS
aos(config)# int mplstunnel 13

aos(config-if)# tunnel mpls destination 1.1.1.1
source 3.3.3.3
aos(config-if)# tunnel mode mpls traffic-eng
aos(config-if)# tunnel signalling protocol rsvp
aos(config-if)# tunnel mpls traffic-eng path-
option number 1 dynamic
Source and Desti nati on I P addresses are mandatory and are set to RSVP
router I D for source and desti nati on routers.
I n SW Rel ease 3.4, onl y mpl s traffi c-engi neeri ng i s supported as the
tunnel mode. uni di recti onal , corouted-bi di reti onal and associ ated-
bi di recti onal modes are not supported.
I n SW Rel ease 3.4, onl y rsvp i s supported as tunnel si gnal l i ng protocol .
stati c, crl dp, none and other opti ons are not supported.
Explicit Path Option

AOS allows configuring explicit path as a list of IP addresses (RSVP router IDs), and using it as
path option for MPLS tunnels. The constraints specified in the configured path will be applied.
The tunnel will fail to come up if the configured path is invalid or if the required resources such
as bandwidth are not available on the configured path.
Tunnel path can be specified using one of the following ways:
Strict Hop
When a hop is specified as strict in the path option, it is supposed to be directly reachable from
the hop before it in the path specification.
The following example demonstrates configuration of a tunnel from CTR A to CTR D in
Topology C via CTR B, CTRG, and CTR E
Define an explicit path consisting of a set of strict hops and assign it identifier 1:
aos(config)# ip explicit-path identifier 1
aos(cfg-ip-expl-path)# index 1 next-address
strict 2.2.2.2
strict 7.7.7.7
strict 5.5.5.5
strict 4.4.4.4
aos(cfg-ip-expl-path)# exit
Use explicit path 1 as the path option for the tunnel:

62 AVIAT NETWORKS

source 1.1.1.1
option number 1 explicit identifier 1
Loose Hop
When a hop in the path is specified as loose, the path from the previous hop to the loose hop is
calculated using TE-metric or other constraints provided. The path beyond the loose hop is not
calculated at the head end. The loose hop router is expected to run a CSPF calculation to
calculate the route from itself to the tail end or to the next loose hop. This option is typically
used when the tunnel spans multiple IGP areas. The area boundary router (L1-2 router in case
of IS-IS) is specified as a loose hop in this case.
The following example demonstrates configuration of a tunnel from CTR A to CTR D in
Topology C, using CTR E as a loose hop. In this case, the head end calculates path to CTR E
using default TE-metric. CTR E calculates the path to the tail end which is directly connected.
As a result, the tunnel will take the path CTR A→ CTR F→ CTR E→ CTR D.
Define an explicit path consisting of a loose hop and assign it identifier 1:
loose 5.5.5.5

source 1.1.1.1
aos(config-if)# tunnel mpls traffic-eng record-
route
Exclude Address
Exclude address is used to define a path option where the specified node should not be used on
the path of the tunnel.
As an example, consider Topology C. Based on IGP cost, the shortest path from CTR A to CTR
D is via CTR F (CTR A → CTR F → CTR D). If the operator wishes to avoid routing the tunnel
through CTR F, the address of CTR F can be specified in the exclude list. In that case, the
260-668256-014 DECEMBER 2016 63

tunnel will be routed via next best path (CTR A → CTR B → CTR C → CTR D). This is shown
in the following example:
Define an explicit path with CTR F (6.6.6.6) as exclude address and assign it identifier 1:
aos(cfg-ip-expl-path)# index 1 exclude-address
6.6.6.6

source 1.1.1.1
Bandwidth Attribute for TE-Tunnels

Tunnel routing can be managed by specifying bandwidth constraint for the tunnel. When
bandwidth constraint is specified, a link will be used on the tunnel path only if the available
bandwidth is more than the configured bandwidth for the tunnel. If this constraint is not met,
either some of the existing tunnels will be pre-empted based on the set-up and hold priorities
(see Priority Attributes for TE-Tunnels on page 64) or the tunnel setup will fail. Bandwidth
attribute is specified under the mpls tunnel interface configuration with the following
command:
aos(config-if)# tunnel mpls traffic-eng
bandwidth <value in kbps>
Bandwi dth must be hi gher than 1024 kpbs.

Bandwi dth reservati on parameter i s used onl y for tunnel si gnal l i ng .
Reservi ng bandwi dth for a tunnel does not necessari l y guarantee that the
tunnel wi l l carry traffi c at thi s bandwi dth, nor wi l l i t restri ct a tunnel from
passi ng traffi c at a hi gher bandwi dth than i t has reserved. I f traffi c
pol i ci ng i s requi red, i t must be confi gured separatel y.
Priority Attributes for TE-Tunnels

MPLS tunnel priorities affect the behaviour when enough resources are not available for a newly
created tunnel. In this case the setup priority of the new tunnel is compared against the hold
priority of existing tunnels on the link. If an existing tunnel with lower priority is found, it will
64 AVIAT NETWORKS
be torn down to make room for the new tunnel. Tunnel setup and hold priorities are configured
with the following command under mpls tunnel interface configuration:
aos(config-if)# tunnel mpls traffic-eng priority
<setup priority 0-7> <hold priority 0-7>
0 i s the hi ghest pri ori ty, 7 i s the l owest.
Affinity Attribute for TE-Tunnels

The affinity attribute of a tunnel is compared against the resource class value of a TE-link to
determine if the link is allowed to be used on the tunnel. Both affinity and resource class are 32-
bit bit-masks used to group the links based on operator-determined parameters, e.g. latency,
geographical constraints etc. Three types of affinity attributes can be specified for a tunnel:
l Exclude-all attribute: A link will not be used for the tunnel if the link’s resource class
specification includes any attribute included in the exclude-all affinity value for the
tunnel.
l Include-any attribute: A link will be used for the tunnel if it carries any of the
attribute in include-any affinity parameter for the tunnel.
l Include-all: A link will be used for the tunnel if it carries all the attributes in include-
all affinity parameter for the tunnel.
Record-route Option
This option enables the inclusion of Record Route Object (RFC 3209) in the RSVP-TE messages.
This object records the path actually taken by the LSP.
Note: The use of record-route opti on i s mandatory when l oose hops are
used on the tunnel path.
This option can be enabled via following command under mpls tunnel interface configuration:
aos(config-if)# tunnel mpls traffic-eng record-
route

l sh mpls traffic-eng tunnels brief: Shows status and brief
information about the configured tunnels.
l sh mpls traffic-eng tunnels: Shows detailed information about the
configured tunnels.
260-668256-014 DECEMBER 2016 65

Example Configuration Scripts: Dynamic MPLS-TE

Tunnels
The scripts in this section are provided to support configuration examples in the following
chapters. These scripts can be copied into the configuration console. The scripts will establish
full mesh of MPLS-TE tunnels between provider edge routers in example topologies in Topology
Diagrams on page 7. Configurations from Example Configuration Scripts: IPv4 and IS-IS on
page 11 and Example Configuration Scripts: TE links, ISIS-TE and RSVP-TE on page 37 must
be completed before applying the configurations in this section.
Dynamic Tunnels for Topology A

CTR A Configuration
Tunnel from CTR A to CTR C
configure terminal
int mplstunnel 13
tunnel mpls destination 3.3.3.3 source 1.1.1.1
tunnel mode mpls traffic-eng
tunnel signalling protocol rsvp
tunnel mpls traffic-eng path-option number 1
dynamic
no shutdown
end
CTR C Configuration
Tunnel from CTR C to CTR A
configure terminal
int mplstunnel 31
dynamic
no shutdown
66 AVIAT NETWORKS
Dynamic Tunnels for Topology B

CTR A Configuration
configure terminal
int mplstunnel 13
dynamic
no shutdown
end
Tunnel from CTR A to CTR D

configure terminal
int mplstunnel 14
dynamic
no shutdown
end
CTR C Configuration
Tunnel from CTR C to CTR A
configure terminal
int mplstunnel 31
dynamic
no shutdown
Tunnel from CTR C to CTR D

configure terminal
int mplstunnel 34
260-668256-014 DECEMBER 2016 67


dynamic
no shutdown
CTR D Configuration
Tunnel from CTR D to CTR A
source 4.4.4.4
aos(config-if)# end
Tunnel from CTR D to CTR C

source 4.4.4.4
Dynamic Tunnels for Topology C

CTR A Configuration
configure terminal
int mplstunnel 14
dynamic
no shutdown
end
68 AVIAT NETWORKS
CTR D Configuration
Tunnel from CTR D to CTR A
configure terminal
int mplstunnel 41
dynamic
no shutdown
260-668256-014 DECEMBER 2016 69

Chapter 5. Layer 2 Virtual

Private Networks
Reference Model For L2 Transport Over MPLS
Figure 5-1. PWE3 Network Reference Model for MPLS L2VPNs
L2VPN implementation in AOS is based on pseudo-wires and follows the reference model
described in RFC-3985. The model is shown in figure PWE3 Network Reference Model for MPLS
L2VPNs, above. All configurations for L2VPNs reside on the provider edge routers. The core
routers in the network only have to provide MPLS transport via LDP or RSVP-TE signalled
LSPs. Key elements and supported features for L2VPNS are summarised below.
Service Types
l Virtual Private Wire Service (VPWS): VPWS provides a layer 2 point-to-point
connection, which is effectively equivalent to providing a leased line supporting
Ethernet transport.
l Virtual Private LAN Service (VPLS): VPLS provides a Layer 2 multipoint service which
extends a private LAN segment across the provider’s MPLS network. This creates the
appearance to the users that all sites are interconnected though a single Ethernet
switch. In addition to providing layer 2 transport, VPLS also provides switch
functions such as MAC address learning and ageing.
260-668256-014 DECEMBER 2016 71

CHAPTER 5. LAYER 2 VIRTUAL PRIVATE NETWORKS
Both VPWS and VPLS transport Layer 2 Ethernet frames across the network. This in turn
allows any type of Layer 3 payload, not just IP, being carried by those Ethernet frames to be
conveyed.
Attachment Circuit Types

A customer edge device accesses the L2VPN service by connecting to the provider edge device
via an attachment circuit (AC). The following types of attachment circuits are supported:
l Port – A physical interface such as an Ethernet port. Any traffic that arrives on the
port is passed on to the L2VPN PW.
l VLAN – Connecting to PE over a single VLAN (Only supported for VPLS). The VLAN
on the PE device may contain more than one port. This type of attachment circuit is
typically used when an L2VPN site has multiple pieces of customer equipment which
have to be connected to same L2VPN service via a single PE router. The recommended
configuration is to create a VLAN based attachment circuit on PE router with a port
provided for each piece of external equipment.
A physi cal port cannot be a member of more than one VLAN based
attachment ci rcui ts.
l Port + VLAN – This configuration provides the ability to create multiple attachment
circuits on a single physical port. The traffic for each attachment circuit is identified
by the VLAN tag configured for that attachment circuit and is mapped to the
appropriate L2VPN PW. This scheme is useful for separating different types of traffic
arriving on the same physical interface, e.g. separating customer data traffic from
management traffic and mapping them to different L2VPN services.
Pseudo-wires
Pseudo-wires are the mechanism used to carry L2 frames over MPLS cloud. Pseudo-wires are
configured on the provider edge devices and are invisible to the core routers (LSRs or P-routers).
In data plane, packets belonging to a PW are identified by a PW label plus optional control
word and associated channel headers. PW label is pushed on the packet at the PE router before
the MPLS LSP label i.e., PW label is the inner label in MPLS label stack. MPLS routers in the
network (P routers) switch the packets based on the outermost label only (MPLS transport
label). At the remote PE router, after the MPLS transport label is popped, the PW label is used
to map the packet to the appropriate attachment circuit.
Pseudo-wire Establishment
Pseudowire establishment involves exchange of PW labels and other control information across
PE routers. In AOS, this can be accomplished in one of the two possible ways:
l Manual/ static configuration of labels and PW parameters at both ends
l Using Targeted LDP to allocate labels and negotiate PW parameters
72 AVIAT NETWORKS
Pseudo-wire Modes: Raw vs. Tagged

RFC 4448 specifies two operating modes for L2VPN Pseudowire.
l Tagged mode- Service delimiting tag is carried over the PW. If a service delimiting
tag is not present on the traffic received at the attachment circuit, a dummy tag is
inserted.
l Raw mode- Service delimiting tag is stripped before a packet is sent on the PW.
I t i s recommended to use Raw mode pseudo-wi res when connecti ng to

port-based attachment ci rcui ts.
I t i s recommended to use tagged mode pseudo wi res when connecti ng to
VLAN or Port+VLAN based attachment ci rcui ts.
Service Delimiting Tag Conventions In AOS

l On a port based attachment circuit, a service-delimiting tag is deemed to be not
present. All traffic arriving on the port is sent to the L2VPN PW connected to the AC.
Any VLAN tags present on the traffic are considered to be customer tags and are
preserved over the emulated service.
Maxi mum of 2 customer VLAN tags can be preserved for raw
mode PW.
Maxi mum of 1 VLAN tag can be preserved for tagged mode PW.
I f customer traffi c has 2 VLAN tags, the outer customer tag i s
overwri tten by dummy servi ce-del i mi ti ng tag. F or thi s reason,
i t i s not recommended to use tagged mode pseuodowi re wi th
Port based attachment ci rcui ts.
l On VLAN and Port+VLAN ACs, the Attachment Circuit VLAN tag on the PE node is
considered to be the service delimiting tag. The outermost tag on customer traffic is
compared against the service delimiting tag to identify the correct PW.
I t i s possi bl e for Attachment Ci rcui ts at both ends of a
pseudo-wi re to use di fferent VLAN I Ds. F or exampl e, A PW
can be connected to AC Port Gi 0/1:VLAN 100 at PE 1 and to
Port Gi 0/2: VLAN 200 at PE 2. I n thi s case, traffi c whi ch
arri ves from the customer network wi th VLAN 100 i s mapped
on the pseodowi re and at the egress si de, the servi ce
del i mi ti ng tag i s overwri tten by the VLAN I D of egress
attachment ci rcui t, i .e. the traffi c i s sent out to CE2 devi ce
wi th outermost VLAN tag 200. Thi s provi des a way of doi ng
VLAN transl ati on.
260-668256-014 DECEMBER 2016 73

Targeted LDP Configuration

Pseudowires are the common building blocks for both VPWS and VPLS. It is recommended to
use T-LDP to signal pseudo-wires. In order to exchange Pseudowire setup information, the PE
routers at both ends require a T-LDP session established between them. IPv4 connectivity and
reachability must be established between the two devices for T-LDP session to be set up. After
that, the following configuration is required:
l Enable the LDP process and assign router ID to local LDP router.
l Create an LDP ‘entity’ to manage the session with a particular remote end PE. A
separate entity has to be configured for T-LDP session with each PE.
l Under each entity, specify IP address of the remote PE (LDP router ID).
l Under each entity, specify a label range to be used.
I n SW Rel ease 3.4, the transport address used for a T-LDP sessi on shoul d
be the l oopback i nterface.
AOS uses l i beral l abel retenti on mode and unsol i ci ted l abel di stri buti on
mode by defaul t.
The following example shows configuration of T-LDP on CTR A in Topology A. A targeted LDP
session is configured towards CTR C. Similar configuration on CTR C is required for the session
to be established.
On CTR A:
aos(config)# mpls ldp
aos(config-mpls-ldp)# router-id loopback 0 force
aos(config-mpls-ldp)# entity 1
aos(config-mpls-ldp-entity-1)# neighbor 3.3.3.3
targeted
aos(config-mpls-ldp-entity-1)# ldp label range
min 160100 max 160199
aos(config-mpls-ldp-entity-1)# transport-address
tlv loopback 0
aos(config-mpls-ldp-entity-1)# no shutdown
aos(config-mpls-ldp-entity-1)# end
On CTR C:
targeted
min 160300 max 160399
74 AVIAT NETWORKS
tlv loopback 0
aos(config-mpls-ldp-entity-1)# end
VPWS Configuration
After IPv4 connectivity and MPLS transport have been provisioned in the network, follow the
steps below for configuration of VPWS:
1. Configure targeted LDP sessions across the edge devices. This step is not required
if manual configuration of PW labels will be used.
I t i s recommended to use T-LDP for si gnal l i ng PWs because
stati c confi gurati on of l abel s i s hard to manage i n l arge
networks.
2. Configure PW and connect it to the attachment circuit (AC) on each edge router.
Configuration Example: VPWS with Port Based

Attachment Circuit
This example demonstrates creation of a VPWS service between CTR A and CTR C on Topology
A. It is assumed that IPv4 and LSP configuration is completed on the topology according to
scripts in the following sections:
l Topology A on page 11
l Configuration for Topology A on page 37
l Dynamic Tunnels for Topology A on page 66
l T-LDP is configured with script in section Targeted LDP Configuration on page 74.
VPWS is a point to point service and is configured directly under the attachment circuit
interface on each device. In this case port Gi0/4 is used as attachment circuit on both devices.
On CTR A:
aos(config)# interface gigabit ethernet 0/4
Connect the interface to pseuodowire. Target PE for PW is 3.3.3.3, PW ID is set to 1. The PW

goes over MPLS-TE LSPs, forward tunnel 13 and reverse tunnel 31:
aos(config-if)#mpls l2transport pwidfec 3.3.3.3
pwid 1 groupid 1 mplstype te 13 31 pwtype eth
On CTR C:
260-668256-014 DECEMBER 2016 75

Connect the interface to pseuodowire. Target PE for PW is 1.1.1.1, PW ID is set to 1. The PW

goes over MPLS-TE LSPs, forward tunnel 31 and reverse tunnel 13:
aos(config-if)#mpls l2transport pwidfec 1.1.1.1
pwid 1 groupid 1 mplstype te 31 13 pwtype eth
Configuration Example: VPWS with Port+Vlan Based

Attachment Circuit
This example demonstrates creation of two VPWS services between CTR A and CTR C on
Topology A. It is assumed that IPv4 and LSP configuration is completed on the topology
according to scripts in the following sections:
l Topology A on page 11
l Configuration for Topology A on page 37
l Dynamic Tunnels for Topology A on page 66
l T-LDP is configured with script in section Targeted LDP Configuration on page 74.
Both VPWS services terminate on physical port Gi 0/4 but use different Port+VLAN attachment
circuits. PW 1 will use VLAN 101 as attachment circuit, PW 2 will use VLAN 102. For Port +
VLAN AC, the service is configured under VLAN interface. The PW is configured in tagged
mode.
On CTR A:
aos(config-switch)# vlan 101
aos(config-switch-vlan)# ports add gig 0/4
aos(config-switch-vlan)# mpls l2transport
pwidfec 3.3.3.3 pwid 1 groupid 1 mplstype te 13
31 port-ifindex gigabitethernet 0/4 pwtype
ethtag
aos(config-switch-vlan)# end

ethtag
76 AVIAT NETWORKS
On CTR C:
ethtag

ethtag
VPLS Configuration
The key steps for configuration of a VPLS service after IPv4 connectivity and LSPs have been
established are:
1. Configure targeted LDP sessions across the edge devices. Each PE router should
have a T-LDP session with all other PE routers in the VPLS service.
2. Configure a VFI and VPN instance for the service.
3. Add PWs to the VPN instance. This is different from VPWS where PWs are created
directly under interface or VLAN configuration in CLI. In most scenarios a PW to
each PE router has to be configured, i.e. all PE devices participating in the VPLS
service are connected with a full mesh of PWs.
4. Connect the attachment circuits to the VFI instance.
Configuration Example: VPLS with VLAN Based

Attachment Circuit
This example demonstrates creation of a VPLS service with CTR A, CTR B and CTR C as PE
routers on Topology B. It is assumed that IPv4 and LSP configuration is completed on the
260-668256-014 DECEMBER 2016 77

topology according to scripts in the following sections:

l Topology B on page 14
l Configuration for Topology B on page 41
l Dynamic Tunnels for Topology B on page 67
The attachment circuit is VLAN 101. In this case the VLAN has only one port Gi 0/4. However,
multiple ports can be added to the VLAN and traffic arriving on any of those ports with VLAN
101 as outer tag will be forwarded via VPLS.
CTR A Configuration
Enable LDP and configure targeted LDP entities towards CTR C and CTR D:
targeted
min 160100 max 160149
tlv loopback 0
aos(config-mpls-ldp-entity-1)# exit
targeted
min 160150 max 160199
tlv loopback 0
Configure VLAN for attachment circuit:

aos(config)# vlan 102
aos(config-vlan)# ports gi 0/4
aos(config-vlan)# exit
Configure VFI and VPN. A user defined string is assigned to the VFI for identification. In this
case, the VFI is called VPLS_ACD. Configure two PWs under the VPN instance, one towards
CTR C and one towards CTR D:
aos(config-switch)# l2 vfi VPLS_ACD manual
aos(config-switch-vfi)# vpn 1
78 AVIAT NETWORKS
aos(config-switch-vfi)# neighbor 3.3.3.3 pwidfec

pwid 13 groupid 1 encapsulation mpls mplstype te
13 31 pwtype ethtag
14 41 pwtype ethtag
aos(config-switch-vfi)# end
Connect the AC VLAN to the VFI:

aos(config-vlan)# xconnect vfi VPLS_ACD
aos(config-vlan)# end
CTR C Configuration
Enable LDP and configure targeted LDP entities towards CTR A and CTR D:
targeted
min 160200 max 160249
tlv loopback 0
targeted
min 160250 max 160299
tlv loopback 0

260-668256-014 DECEMBER 2016 79

CTR A and one towards CTR D:
31 13 pwtype ethtag
34 43 pwtype ethtag

CTR D Configuration
Enable LDP and configure targeted LDP entities towards CTR A and CTR C:
targeted
min 160300 max 160349
tlv loopback 0
targeted
min 160350 max 160399
tlv loopback 0
80 AVIAT NETWORKS

CTR A and one towards CTR C:
41 14 pwtype ethtag
43 34 pwtype ethtag

Variation 1: Port Based Attachment Circuit

In order to configure VPSL with port based attachment circuit, following modifications are
required to the above configuration:
1. Remove pwtype ethtag config from all Pseudowire configurations in order to
make PWs raw mode. CTR A configuration for VFI is modified as follows:
13 31
14 41
260-668256-014 DECEMBER 2016 81

2. Instead of connecting VLAN 102 to VFI, issue xconnect command under

interface configuration for the AC port. For example, use the following commands on
CTR A to connect physical port gi 0/5 to VPLS. Ensure Gi 0/5 is not in any vlan.
aos(config)# int gi 0/5
aos(config-if)# xconnect vfi VPLS_ACD
aos(config-if)# end
Variation 2: Port+VLAN Based Attachment Circuit

In order to configure VPLS with port+vlan based attachment circuit, the following
modifications are required to the above configuration:
Ensure the port is a member of attachment circuit vlan. Add vlan ID to the xconnect
command when connecting port to the VFI:
aos(config)# int gi 0/5
aos(config-if)# xconnect vfi VPLS_ACD port-vlan
102
aos(config-if)# end

l show mpls l2transport summary or sh mpls l2transport detail:
Shows status and information about the configured L2VPN PWs.
l show vfi: Displays information about all VFIs on the system.
l show mac-address-table: Lists MAC addresses. This includes MAC
addresses on VFIs for VPLS. VPLS addresses are listed under VLAN 4097
onwards.
82 AVIAT NETWORKS
Chapter 6. Layer 3 Virtual

Private Networks
Overview
MPLS Layer 3 VPNs (also known as BGP/MPLS VPNs) provide VPN service at the IP layer.
Typically, at each VPN site, a provider edge router peers with a customer edge router which
connects to the rest of the customer network. Similar to L2VPN, most L3VPN configuration
resides in edge routers only. The core routers in the service provider’s network simply switch
traffic based on MPLS transport labels.
The following sections describe the individual elements of L3VPNs and their configuration in
AOS. Most examples in this chapter are based on slightly modified version of Topology B. It is
assumed that basic IP and IS-IS configuration, MPLS traffic engineering and LSP configuration
has been completed according to scripts in the following sections:
The new element introduced here are the three CE routers which peer with their corresponding
PE routers at each VPN site.
Figure 6-1. Modified Topology B for L3VPN - CE Devices Added
260-668256-014 DECEMBER 2016 83

VRF Configuration
A separate Virtual Routing and Forwarding (VRF) instance is created on the provider edge
routers for each L3VPN service. A VRF instance maintains separate (private) routing and
forwarding tables for a L3VPN service containg routing information to get customer traffc across
different VPN sites. Each PE-CE link on a PE router is assigned to a particular VRF. The traffic
arriving at the PE router from a CE router is mapped to the correct L3VPN service, based on
the local configuration on the PE router, which assigns the receiving interface to a particular
VRF. The traffic arriving from the provider core is demultiplexed based on the VPN label
described in the section L3VPN Route AND Label Distribution and mapped to the correct VRF
instance. Once the VRF instance is identified, the forwarding decision is made in both
directions based on the routing table for that VRF.
Loopback interfaces can also be added to a VRF and are useful for diagnostic and identification
purposes. For example, to be used as router IDs for routing protocols running on CE-PE
interface.
I n SW Rel ease 3.4, I P pi ng from a l oopback address i n a VRF to a l oopback

address i n the same VRF on a remote PE router (al so known as VRF Pi ng),
i s not supported i n CTR.
The following example shows configuration of a VRF on CTR A. The VRF is given customer1
as the identifier. It has two interfaces: physical port gi 0/7 and a loopback interface:
Create VRF customer1 :
aos(config)# ip vrf customer1
aos(config)# end
Add port gi 0/7 to VRF and assign it an IP address. ip vrf forwarding <vrf-
identifier> command assigns the interface to a specific VRF. Without this command, the
interface would belong to the default VRF which is used for ‘normal’ IPv4 forwarding as
opposed to L3VPN forwarding.
aos(config)# interface gi 0/7
aos(config-if)# shutdown
aos(config-if)# no map switch default
aos(config-if)# ip vrf forwarding customer1
255.255.255.0
aos(config-if)# end
Add a loopback interface to the VRF:

aos(config)# interface loopback 1
84 AVIAT NETWORKS
aos(config-if)# ip vrf forwarding customer1

255.255.255.255
aos(config-if)# end
L3VPN Route AND Label Distribution

BGP with multiprotocol extensions (MP-BGP) is used to signal L3VPN labels across the PE
devices. The VPN label is pushed on the packets before the MPLS transport label (VPN label is
the inner label). This label is transparent to the core routers and is used at the remote PE to
map the arriving packets to the correct VRF. L3VPN label distribution requires little to no
configuration from the user apart from the label allocation mode. This can be one label per VRF
or one label per route, which means separate label for each route in the VRF.
MP-BGP is also used to exchange VRF routing information among PE routers. All PE routers
participating in L3VPN service must have a full mesh of BGP sessions, unless a route reflector
is used. BGP provides a great degree of control over how the routes are propagated and shared
across VPN sites. Route Distinguishers and Route Targets are two key constructs involved in
MP-BGP configuration for L3VPNS. These are described in the following sections.
Route Distinguisher (RD)

A PE router learns and maintains customer route information for the local site, such as which
customer prefixes are aavailable at the site and are reachable via this PE router. The PE router
might learn this information via a routing protocol running on CE-PE interface or this
information might be statically configured in the PE router. The PE router uses MP-BGP to
send this information to other PE routers in the network. With MP-BGP exchange, it also learns
about other customer prefixes and the correct PE devices which should be used to reach those
prefixes.
When IP prefixes belonging to customer VRFs (L3VPNs) are carried across the provider network
using BGP, they need to be distinguished from IP prefixes belonging to the provider’s own
network and from IP prefixes belonging to other customer’s networks. This enables customers to
use overlapping IP address space. BGP’s multiprotocol extensions provide this capability by
introducing VPNv4 address family.
When a PE router uses BGP to exchange L3VPN prefixes, it converts them from IPv4 to VPNv4
family addresses. To achieve this, the PE router adds a Route Distinguisher (RD) to the
customer’s IP prefix. Route Distinguisher is usually statically configured in the PE routers. Its
only role is to make the VPN addresses uniquely identifiable. Any convenient allocation scheme
can be used to configure RDs, for example, one RD per VPN or one RD per site in a VPN. In
AOS, RD can be configured as the AS number followed by a number or an IP addresss followed
by a number.
The following example shows configuring a route distinguisher 65001:11 for on a PE router for
VRF customer1. It is assumed that 65001 is the AS number used in provider’s network:
aos(config)# ip vrf customer1 mpls
aos(ip-vrf-mpls)# rd 65001:11
aos(ip-vrf-mpls)# end
260-668256-014 DECEMBER 2016 85

Route Target (RT)

Route target is a BGP Extended Community attribute which is used to apply constraints to
distribution and sharing of customer route information.
A PE router will attach RTs to all customer prefixes it advertises via MP-BGP. The RT applied
to advertised routes is controlled via export route target configuration in the PE for a particular
VRF.
When VPNv4 routes are received at a PE, the attached RTs are compared with the settings for
all defined VRFs. If a particular VRF has an import route target configured with an RT value
that is attached to the incoming route, then the incoming route is accepted into VRF and
installed in the VRF routing table. Using this mechanism a number of VPN connectivity policies
can be implemented. For example, routes can be exchanged across all sites in a single VPN or
restirictions on connectivity can be imposed by configuring certain PEs to accept routes with
only a subset of RTs.
The format of route target in AOS is similar to route distinguisher, i.e. AS number followed by a
number or IP address followed by an number.
The following example demonstrates RT configuration on CTR A for Topology B (Figure-
Modified Topology B for L3VPN - CE Devices Added). AS:nn format is used here. It is assumed
that AS number for provider’s network is 65001. It is assumed that CTR C and CTR D export
routes with RTs 65001:13 and 65001:14 respectively. CTR A is being configured to accept all
routes with these two RTs. CTR A exports its routes with RT 65001:11.
aos(config)# ip vrf customer1 mpls
aos(ip-vrf-mpls)# route-target import 100:13
aos(ip-vrf-mpls)# route-target import 100:14
aos(ip-vrf-mpls)# route-target export 100:11
aos(ip-vrf-mpls)# end
MP-BGP Peering
Once RDs and RTs are configured, the full mesh of MP-BGP peerings among all PE routers has
to be configured. Under each BGP neighbour which is a PE, address family VPNv4 has to be
enabled. Redistribution of internal routes for VRF has to be enabled for BGP. If TE tunnels are
being used, L3VPN binding to the tunnels has to be configured. The following example shows
this configuration for CTR A with MP-BGP sessions to CTR C and CTR D (Figure- Modified
Topology B for L3VPN - CE Devices Added):
Enable BGP routing in the device and apply global BGP configuration. The local BGP entity
should be configured with the AS number for the provider’s network. In this example, the
number is assumed to be 65001:
aos(config)# router bgp 65001
aos(config-router)# redistribute all
aos(config-router)# bgp router-id 1.1.1.1
aos(config-router)# label-allocation-mode per-
vrf
86 AVIAT NETWORKS
Configure sessions with other BGP peers. Redistribution of VPNv4 address family has to be
enabled with each peer. In this example, the two BGP peers are the PE routers (CTR-C 3.3.3.3
and CTR-D 4.4.4.4):
aos(config-router)# neighbor 3.3.3.3 remote-as
65001
aos(config-router)# neighbor 3.3.3.3 update-
source 1.1.1.1
aos(config-router)# address-family vpnv4
aos(config-router-afvpnv4)# neighbor 3.3.3.3
activate
aos(config-router-afvpnv4)# ex
65001
aos(config-router)# neighbor 4.4.4.4 update-
source 1.1.1.1
aos(config-router)# address-family vpnv4
aos(config-router-afvpnv4)# neighbor 4.4.4.4
activate
aos(config-router-afvpnv4)# end
Configure redistribution of VRF customer1 routes to BGP:
aos(config-router)# address-family ipv4 vrf
customer1
aos(config-router-af4)# bgp redistribute-
internal
aos(config-router-af4)# redistribute all
aos(config-router-af4)# end
Configure MPLS-TE tunnel bindings:

aos(config)# mpls l3vpn binding ipv4 3.3.3.3
255.255.255.255 rsvp-te 13
aos(config)# mpls l3vpn binding ipv4 4.4.4.4
255.255.255.255 rsvp-te 14
aos(config)# end
Configure CE-PE Routing

So far, most of the configuration has been on PE devices. At this stage, provider network has
been configured to propagate customer routes across different VPN sites and also to forward
traffic to these routes. The last step is to enable configuration of routing information between
PE and CE devices to enable the PE routers to learn customer routes.
260-668256-014 DECEMBER 2016 87

Static Routing
Simplest solution is to use static routing. A CE device has a static route, or multiple static
routes if needed, configured on it which uses the PE device as the next hop to all VPN addresses
on remote sites. The PE router has a static route towards CE configured for all the prefixes
present on the VPN site to which the PE router is connected. PE router will redistribute this
information to other PEs via MP-BGP.
This requires prior knowledge of prefixes present at each site which have to be statically
configured on PE and CE devices.
The following example shows static configuration at Site A (CTR A and CTR CE-A) in Topology
B (Figure- Modified Topology B for L3VPN - CE Devices Added. It is assumed that a CTR CE-A
has a loopback address 12.12.12.12/32 which is being configured to be reachable from other VPN
sites. Also assume that customer site has a local subnet 20.11.0.0/16 which is being configured
to be reachable from other sites.
Configuration on CTR-A is to add static routes in VRF customer1. These static routes use
directly connected link 20.0.11.1 (assuming the other side has address 20.0.11.2) as the next
hop:
aos# c t
aos(config)# ip route vrf customer1 12.12.12.12
255.255.255.255 20.0.11.2
aos(config)# ip route vrf customer1 20.11.0.0
255.255.0.0 20.0.11.2
aos(config)# end
Configuration on CTR CE-A is to use CTR A as next hop for all remote sites. Assume CTR C
and CTR D have similar loopback addresses (32.32.32.32 & 42.42.42.42) and network segments
connected (20.13.0.0/16 and 20.14.0.0/16). CTR CE-A will use CTR-A as the next hop for all of
these addresses. Note that VRF is only applicable to PE router. At the CE router, the connection
appears to be a ‘normal’ IPv4 connection and all addresses are in the default VRF:
aos# c t
aos(config)# ip route 32.32.32.32
255.255.255.255 20.0.11.1
aos(config)# ip route 42.42.42.42
255.255.255.255 20.0.11.1
aos(config)# ip route 20.13.0.0 255.255.0.0
20.0.11.1
aos(config)# ip route 20.14.0.0 255.255.0.0
20.0.11.1
aos(config)# end
eBGP Routing
eBGP is a popular dynamic routing protocol used on CE-PE interface. When eBGP is used, the
AS-nubmer on CE router will be the AS number for customer’s network (which is different from
provider’s AS). The PE device is configured to redistribute IP addresses from VRF customer1 to
eBGP. Note that a single instance of BGP is running on the PE device and it handles both MP-
88 AVIAT NETWORKS
BGP peerings for L3VPN signalling within the provider’s network and CE-PE signalling with
customer router. The peers for each address family and VRF are configured separately.
For Topology B (Figure- Modified Topology B for L3VPN - CE Devices Added), after all
configurations till section L3VPN Route AND Label Distribution on page 85 are complete, the
following configuration will enable eBGP as CE-PE routing protocol on VRF customer1. Note
that remote-as override option must be set to prevent BGP’s loop prevention mechanism to kick
in when a route from a remote customer site is advertised, if all customer sites use same AS
number:
aos(config-router)# address-family ipv4 vrf
customer1
aos(config-router-af4)# neighbor 20.0.11.2
remote-as 65002
aos(config-router-af4)# neighbor 20.0.11.2
activate
aos(config-router-af4)# neighbor 20.0.11.2 next-
hop-self
aos(config-router-af4)# neighbor 20.0.11.2 as-
override
aos(config-router-af4)# end
At CTR CE-A an eBGP instance with neighbourship to local PE has to be configured. Note that
the CE device sees all addresses as ‘normal’ IPv4 addresses in its default VRF:
aos# c t
aos(config-router)# bgp router-id 12.12.12.12
65001
aos(config-router)# redistribute all
aos(config-router)# end

l show ip bgp summary: BGP summary status.
l show ip bgp neighbor: List of BGP peers and status of sessions.
l show ip bgp rib: BGP routing information base.
l show ip interface vrf <vrf-name>: List of IP interfaces in a VRF.
l show ip route vrf <vrf-name>: routing table entires specific to the
VRF.
260-668256-014 DECEMBER 2016 89

Example Configuration Scripts

This example demonstrates creation of an L3VPN service with three sites on Topology B
(Figure- Modified Topology B for L3VPN - CE Devices Added). It is assumed that IPv4 and
MPLS-TE LSP configuration has been completed on the topology according to scripts in the
following sections:
VRF & MP-BGP Configuration (Topology B)

In this section interface, VRF and MP-BGP configuration is performed on PE routers. IP
interfaces are configured on CE devices.
For details on individual steps in this configuration on CTR A, refer to:
l VRF Configuration on page 84
l L3VPN Route AND Label Distribution on page 85
CTR A Configuration
configure terminal
ip vrf customer1
end
Add port gi 0/7 to VRF and give it an IP address:

configure terminal
interface gi 0/7
shutdown
no shutdown
ip vrf forwarding customer1
ip address 20.0.11.1 255.255.255.0
no shutdown
end

configure terminal
ip address 11.11.11.11 255.255.255.255
end
Configure RD and RTs:

configure terminal
90 AVIAT NETWORKS
ip vrf customer1 mpls

rd 65001:11
end
configure terminal
route-target import 100:13
route-target export 100:11
end
Configure MP-BGP peers and enable for address family vpnv4:

configure terminal
router bgp 65001
redistribute all
bgp router-id 1.1.1.1
label-allocation-mode per-vrf
neighbor 3.3.3.3 remote-as 65001
neighbor 3.3.3.3 update-source 1.1.1.1
address-family vpnv4
neighbor 3.3.3.3 activate
ex
end
Configure redistribution of VRF customer1 routes to MP-BGP (internal):
configure terminal
router bgp 65001
address-family ipv4 vrf customer1
bgp redistribute-internal
redistribute all
end

configure terminal
mpls l3vpn binding ipv4 3.3.3.3 255.255.255.255
rsvp-te 13
rsvp-te 14
end
260-668256-014 DECEMBER 2016 91

CTR C Configuration
configure terminal
ip vrf customer1
end

configure terminal
interface gi 0/7
shutdown
no shutdown
ip address 20.0.13.1 255.255.255.0
no shutdown
end

configure terminal
ip address 33.33.33.33 255.255.255.255
end

configure terminal
rd 65001:13
end
configure terminal
end

configure terminal
router bgp 65001
redistribute all
92 AVIAT NETWORKS
ex
end
configure terminal
router bgp 65001
redistribute all
end

configure terminal
rsvp-te 31
rsvp-te 34
end
CTR D Configuration
configure terminal
ip vrf customer1
end

configure terminal
interface gi 0/7
shutdown
no shutdown
ip address 20.0.14.1 255.255.255.0
no shutdown
end

configure terminal
260-668256-014 DECEMBER 2016 93


ip address 44.44.44.44 255.255.255.255
end

configure terminal
rd 65001:14
end
configure terminal
end

configure terminal
router bgp 65001
redistribute all
ex
end
configure terminal
router bgp 65001
redistribute all
end

configure terminal
rsvp-te 41
94 AVIAT NETWORKS

rsvp-te 43
end
CTR CE-A Configuration
Global L3 configurations, create IP link to PE and a loopback address:

configure terminal
switch default
set gmrp disable
set gvrp disable
shutdown garp
end
configure terminal
ip address 12.12.12.12 255.255.255.255
no shutdown
end
configure terminal
shutdown
no switchport
ip address 20.0.11.2 255.255.255.0
no shutdown
end
CTR CE-C Configuration

configure terminal
switch default
set gmrp disable
set gvrp disable
shutdown garp
end
configure terminal
260-668256-014 DECEMBER 2016 95

ip address 32.32.32.32 255.255.255.255

no shutdown
end
configure terminal
shutdown
no switchport
ip address 20.0.13.2 255.255.255.0
no shutdown
end
CTR CE-D Configuration

configure terminal
switch default
set gmrp disable
set gvrp disable
shutdown garp
end
configure terminal
ip address 42.42.42.42 255.255.255.255
no shutdown
end
configure terminal
shutdown
no switchport
ip address 20.0.14.2 255.255.255.0
no shutdown
end
96 AVIAT NETWORKS
CE-PE Static Routing (Topology B)

This section demonstrates configuration of static CE-PE routing for VRF customer1 on Topology
B (Figure- Modified Topology B for L3VPN - CE Devices Added). It is assumed that all
configuration till sectionVRF & MP-BGP Configuration (Topology B) has been completed.
It is assumed that CTR CE-A has a network segment 20.11.0.0/16 connected to it which shall
be made reachable via L3VPN. Similarly, it is assumed that CTR-C has a segment 20.13.0.0/16
and CTR-D has a segment 20.14.0.0/16.
For details on individual steps in this configuration on CTR A and CTR CE-A, refer to Static
Routing on page 88.
CTR A Configuration
c t
ip route vrf customer1 12.12.12.12
255.255.255.255 20.0.11.2
ip route vrf customer1 20.11.0.0 255.255.0.0
20.0.11.2
end
CTR C Configuration
c t
255.255.255.255 20.0.13.2
20.0.13.2
end
CTR D Configuration
c t
255.255.255.255 20.0.14.2
20.0.14.2
end

c t
ip route 32.32.32.32 255.255.255.255 20.0.11.1
ip route 42.42.42.42 255.255.255.255 20.0.11.1
ip route 20.13.0.0 255.255.0.0 20.0.11.1
ip route 20.14.0.0 255.255.0.0 20.0.11.1
end
260-668256-014 DECEMBER 2016 97


c t
ip route 12.12.12.12 255.255.255.255 20.0.13.1
ip route 42.42.42.42 255.255.255.255 20.0.13.1
ip route 20.11.0.0 255.255.0.0 20.0.13.1
ip route 20.14.0.0 255.255.0.0 20.0.13.1
end

c t
ip route 12.12.12.12 255.255.255.255 20.0.14.1
ip route 32.32.32.32 255.255.255.255 20.0.14.1
ip route 20.11.0.0 255.255.0.0 20.0.14.1
ip route 20.13.0.0 255.255.0.0 20.0.14.1
end
CE-PE eBGP (Topology B)

This section demonstrates configuration of eBGP routing on CE-PE interface for VRF customer1
onTopology B (Figure- Modified Topology B for L3VPN - CE Devices Added). It is assumed that
all configuration till section VRF & MP-BGP Configuration (Topology B) has been completed.
For details on individual steps in this configuration on CTR A, refer to eBGP Routing on page
88.
CTR A Configuration
configure terminal
router bgp 65001
neighbor 20.0.11.2 next-hop-self
neighbor 20.0.11.2 as-override
end
CTR C Configuration
configure terminal
router bgp 65001
98 AVIAT NETWORKS

end
CTR D Configuration
configure terminal
router bgp 65001
end

c t
router bgp 65002
redistribute all
end

c t
router bgp 65002
redistribute all
end

c t
router bgp 65002
redistribute all
end
260-668256-014 DECEMBER 2016 99

Chapter 7. MPLS Ping & Trace

Route
Introduction
To verify the connectivity of LSP connections an MPLS ping can be sent by using the ping
mpls command. An MPLS echo reply is sent in response to an MPLS ping request.
To test the path, the trace mpls command can be used. The trace mpls command is
similar to the ping mpls command except that the trace command will send several echo
request packets with increasing TTL (similar to IP Traceroute).
There are four fundamental variations of the command;
l ipv4 – Verification of an LSP bound to a specified ipv4 address.
l pseudowire – Verification of Virtual Circuit Connections (VCCV).
l traffic-eng – Verification of a Traffic-Engineered (TE) Tunnel.
l meg-name – Verification of a Maintenance Entity Group (MEG).
I n SW Rel ease 3.4, LSP Pi ng wi th MEG opti on i s not supported.
ping mpls IPv4 target (LDP signalled LSP)

This command can be used to send an echo request for an LSP which is bound to the
designated IPv4 address. The CTR will place a label on the packet according to the FEC
designated by the IPv4 address.
An example to verify ipv4 LDP signalled LSP of specified address and mask length:
aos#ping mpls ipv4 3.3.3.3/32
Sending 5, 100-byte MPLS Echos to 3.3.3.3/32,
timeout is 2 seconds
Codes :
'!' - success, 'Q' - request not sent, '.' -
timeout,
'L' - labeled output interface, 'B' - unlabeled
output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, m -
FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs,
'N' - no rx label,
260-668256-014 DECEMBER 2016 101

CHAPTER 7. MPLS PING & TRACE ROUTE
'P' - no rx intf label prot, 'p' - premature

termination of LSP,
'R' - transit router, 'X' - unknown return code,
'x' - return code 0,
'I' - Unknown upstream interface index, 'U' -
Reserved
! ! ! ! !
Success Rate is 100 percent (5/5), round-trip
min/avg/max = 62/70/94 ms
ping mpls RSVP-TE tunnel

This command can be used to verify a Traffic-Engineered (TE) Tunnel.
An example to verify Traffic-Engineered Tunnel number 1 with verbose output:
aos#ping mpls traffic-eng Tunnel 1 verbose
Sending 5, 100-byte MPLS Echos to Tunnel 1,
Codes :
timeout,
output interface,
FEC mismatch,
'N' - no rx label,
termination of LSP,
Reserved
Type escape sequence to abort.

!size 100, reply addr 10.160.142.4, return code 3
Success Rate is 100 percent (5/5), round-trip

min/avg/max = 61/71/87 ms
102 AVIAT NETWORKS

ping mpls L2VPN Pseudowire

This command can be used to verify a Virtual Circuit Connection (VCCV) enabled pseudowire.
Before this command can be used, pseudo-wire OAM capabilities must be globally enabled and
VCCV must be configured on the PW.
PW OAM capabilities can be globally enabled via following set of commands. For more
information, refer to CTR 8500/8300 CLI Reference Manual Vol 2 for details):
aos(config)# configure terminal
aos(config)# mpls oam enable
aos(config)# pseudowire-notification pw-status
aos(config)# pw-cc-capability router-alert-label
aos(config)# pw-cv-capability lsp-ping
aos(config)# end
In addition, OAM capability and relevant parameters need to be configured over the L2VPN PW
under the individual PW configuration via pseudowire-oam command. For example,
configuration in Configuration Example: VPWS with Port Based Attachment Circuit on page 75
for VPWS PW will be modified as follows to enable OAM capability:
aos(config-if)# mpls l2transport pwidfec 3.3.3.3
pwid 1 groupid 1 mplstype te 13 31
aos(config-if)# mpls pseudowire-oam pwid 1
local-cc-type router-alert-label local-cv-type
lsp-ping remote-cc-type router-alert-label
remote-cv-type lsp-ping
aos(config-if)# end
An example to verify pseudowire at the specified ipv4 address and virtual circuit id:
aos#ping mpls pseudowire 3.3.3.3 vc-id 1

Sending 5, 100-byte MPLS Echos to 3.3.3.3,
timeout is 2 seconds, send interval is 0
msec:
Codes :
timeout,
output interface,
FEC mismatch,
'N' - no rx label,
260-668256-014 DECEMBER 2016 103

CHAPTER 7. MPLS PING & TRACE ROUTE
'P' - no rx intf label psrot, 'p' - premature

termination of LSP,
Reserved

! ! ! ! !
Success rate is 100 percent (5/5), round-trip
min/avg/max = 28/32/40 ms PE-802#
trace mpls IPv4 target (LDP signalled LSP)

This command can be used to send a traceroute request for an LSP which is bound to the
designated IPv4 address.
An example to verify ipv4 LDP signalled LSP of specified address and mask length:
aos#trace mpls ipv4 3.3.3.3/32
Tracing MPLS Label Switched Path to to 3.3.3.3/32,
Codes :
timeout,
output interface,
FEC mismatch,
'N' - no rx label,
termination of LSP,
Reserved

0 1.1.1.1 2.2.2.2 MRU 1500 [Labels: 40 Exp: 0]
L 1 2.2.2.2 3.3.3.3 MRU 1500 [Labels: implicit-
null 25 Exp: 0] 63 ms ret code 8
! 2 3.3.3.3 65 ms, ret code 3
104 AVIAT NETWORKS

Chapter 8. End To End LSP

Protection
RFC 4872 describes a number of possible mechanisms for end to end recovery of MPLS LSPs. In
general terms, the recovery process consists of:
l detecting a failure; and
l B- switching the traffic to an alternative path
The alternative path is determined by the head-end router for the LSP. Depending on the
protection mechanism in use, this path may or may not be calculated and signalled in advance.
The following sections describe configuration of different elements of LSP protection in AOS.
Failure Detection
The simplest failure detection configuration is to rely on the mechanisms built-in to RSVP-TE.
An RSVP-TE node is expected to send a PATH ERROR message to the head end LSR of an LSP
when a failure on the LSP is detected. For example, a physical link being used by an LSP goes
down. RSVP-TE also maintains Hello timers to aid detection of adjacency failures. If protection
for a tunnel is converted, the head end LSR can react to this message and switch the traffc to
alternative path. No additional configuration on a tunnel is needed for this kind of detection.
RSVP-TE based failure detection mechanisms tend to be slow in detecting failures. The
recommended method of failure detection for protected LSPs is using BFD with hardware
offloading.
BFD for failure detection on MPLS-TE Tunnels

CTR supports BFD with hardware offloading. BFD interval can be set to as low as 1
millisecond. Lower BFD intervals offer faster detection times.
The following example shows configuration of BFD to monitor a pair of MPLS tunnels between
two routers 1.1.1.1 and 4.4.4.4. A BFD session has to be configured at both devices.
Globally enable BFD module on the router:
aos(config)# no shutdown bfd
aos(config)# bfd enable
Configure a BFD session number 10 on the router 1.1.1.1 . A similar session needs to be
configured at the router 4.4.4.4. The session ID of the session on remote device should be used
as BFD discriminator in router 1.1.1.1. The following configuration is for router 1.1.1.1. It enables
hardware offloading for BFD and sets BFD interval to 3 msec.
260-668256-014 DECEMBER 2016 105

CHAPTER 8. END TO END LSP PROTECTION
aos(config)# bfd session 10

aos(config-bfdsess)# bfd mpls traffic-eng
tunnel 1 source 1.1.1.1 destina 4.4.4.4
aos(config-bfdsess)# bfd set offload
aos(config-bfdsess)# bfd interval 3 min_rx 3
multiplier 3
aos(config-bfdsess)# bfd params sess-type
single-hop
aos(config-bfdsess)# bfd params remote-discr 20
aos(config-bfdsess)# bfd params role active
aos(config-bfdsess)# bfd params mode cc
aos(config-bfdsess)# bfd enable
aos(config-bfdsess)# end
I n SW Rel ease 3.4, the BF D sessi on i s associ ated wi th an MPLS –Tunnel

and not wi th i ndi vi dual LSPs. The sessi on associ ated wi th the tunnel can
moni tor onl y the worki ng LSP for the tunnel . F ai l ures on the protecti ng
LSPs cannot be detected wi th BF D.
Protection Mode 1:1

AOS supports 1:1 protection mode for MPLS-TE tunnels. In this mode, both working and
protecting LSPs are calculated and signalled in advance. Under normal conditions, the traffic
flows through the working LSP. As soon as a failure is detected on working LSP, the head-end
router switches the traffic to protecting LSP.
By defaul t, 1:1 protecti on i n AOS operates i n ‘ reverti ve’ mode wi th a fi xed
wai t to restore ti mer of 120s. The expected behavi our i n thi s mode i s:
upon fi rst fai l ure, traffi c swi tches to protecti ng path. As soon as worki ng
path i s operati onal , the head end node starts the wai t to restore ti mer.
After 120 sec of worki ng path becomi ng functi onal , traffi c i s swi tched to
worki ng path agai n.
The path options for working and protecting path are configured individually using the
commands described in Path Options for TE-Tunnels on page 61.
I n SW Rel ease 3.4, the worki ng LSP can use al l path opti ons descri bed i n
secti on 4.1. However, the protecti ng LSP must al ways be defi ned as an
expl i ci t path wi th a sequence of stri ct hops.
106 AVIAT NETWORKS

RF C 4872 assumes worki ng and protecti ng LSPs to be resource-di sj oi nt.

AOS does not enforce thi s restri cti on. Thi s al l ows some protecti on to be
confi gured on network topol ogi es where more than one ful l y resource-
di sj oi nt path i s not avai l abl e. The obvi ous down-si de of usi ng non-di sj oi nt
paths i s that no protecti on wi l l be avai l abl e agai nst fai l ure on a l i nk/node
used by both worki ng and protecti ng LSPs. Therefore, to maxi mi ze the
benefi ts of LSP protecti on, operators shoul d avoi d shari ng l i nks/nodes
between worki ng and protecti ng LSPs wherever i t i s possi bl e to do so.
The steps for configuration of an MPLS-TE tunnel with 1:1 protection are:
l Define paths for working and protecting LSPs using ip explicit-path command.
This is not needed if dynamic path option is to be used.
l Under MPLS tunnel configuration specify:
o End to end protection type as one-to-one.
o Specify the explicit path identifier configured above as path option 1 for working
LSP or specify dynamic path under option 1.
o Specify the explicit path identifier configured above for protecting LSP as backup-
path.
These steps are demonstrated in the sections below.
Configuration Example – 1:1 End To End Protection

With BFD (Using explicit paths for working and
protecting LSPs)
This example provides configuration scripts which can be used to establish protected tunnels
between CTR A and CTR D in Topology C. BFD is enabled with hardware offloading to support
fast recovery.
It is assumed that IS-IS with TE extensions, TE-Links, and RSVP-TE configurations have been
completed on all nodes in the network using scripts provided in sections Topology C on page 20
and Configuration for Topology C on page 47. Note that tunnels, BFD and protection
configuration are needed only at the tunnel endpoint nodes. Intermediate nodes in the network
only need to be running ISIS-TE, TE-links and RSVP-TE (Configured in sections 2.8.3 and
3.5.3).
Details of tunnels are:
Tunnel from CTR-A to CTRD:
Working path: CTR-A → CTR-F → CTR-D
Protecting path: CTR-A → CTR-B → CTR-C → CTR-D
Tunnel from CTR-D to CTRA:

Working path: CTR-D → CTR-F → CTR-A
Protecting path: CTR-D → CTR-C → CTR-B → CTR-A
260-668256-014 DECEMBER 2016 107

CTR-A Configuration
Define explicit paths for LSPs:
configure terminal
ip explicit-path identifier 1
index 1 next-address strict 6.6.6.6
exit
end
Configure protected tunnel use path 1 for working path and path 2 for backup path:
configure terminal
interface mplstunnel 1
tunnel mpls traffic-eng record-route
tunnel endpoint capability encoding lsp-packet
switching psc1
explicit identifier 1
tunnel mpls traffic-eng backup path-option
number 1 explicit identifier 2
tunnel mpls end-to-end-protection-type one-to-
one
no shut
end
Enable BFD, and configure BFD with hardware offloading to monitor the working LSP:
configure terminal
no shutdown bfd
bfd enable
bfd session 10
bfd mpls traffic-eng tunnel 1 source 1.1.1.1
dest 4.4.4.4
bfd set offload
bfd interval 3 min_rx 3 multiplier 3
bfd params sess-type single-hop
bfd params remote-discr 20
bfd enable
end
108 AVIAT NETWORKS

CTR-D Configuration
Define explicit paths for LSPs:
configure terminal
exit
end
Configure protected tunnel use path 1 for working path and path 2 for backup path:
configure terminal
interface mplstunnel 2
tunnel mpls traffic-eng record-route
tunnel endpoint capability encoding lsp-packet
switching psc1
explicit identifier 1
tunnel mpls traffic-eng backup path-option
number 1 explicit identifier 2
tunnel mpls end-to-end-protection-type one-to-
one
no shut
end
Enable BFD, and configure BFD with hardware offloading to monitor the working LSP:
configure terminal
no shutdown bfd
bfd enable
bfd session 20
bfd mpls traffic-eng tunnel 2 source 4.4.4.4
dest 1.1.1.1
bfd set offload
bfd interval 3 min_rx 3 multiplier 3
bfd params sess-type single-hop
bfd params remote-discr 10
260-668256-014 DECEMBER 2016 109

bfd enable
end
110 AVIAT NETWORKS

Chapter 9. Appendix A – MPLS

Label Ranges In AOS
Nomenclature
Remote Label
This is also called out label or push label. This label is advertised to the device under
configuration from its partner device. This label will be ‘pushed’ on all packets before they are
sent out towards the partner. Partner could be the next hop for an LSP or the remote PE router
for AToM, L2VPN and L3VPN service.
Local Label
This is also called in label or pop label. This is the label which the device being configured
advertises to its partners. The device unvder configuration expects the partner to send the
traffic with this label pushed on it. The device will use this label to map the packet to an LSP or
service and will perform a pop or swap operation on this label.
Local Label Ranges

Table 9-1. Local Label Ranges
Configuration
Label Range Application
Information
0-15 Standard reserved labels
16-99 Reserved/Unused in AOS
100-100,000 MPLS LSPs signalled with LDP Configured under non-
targeted ldp entity with
command:
ldp label range min
<value> max <value>
If not configured, the
entity will use entire label
range.
100,001-160,000 MPLS LSPs signalled with RSVP-TE Configured under rsvp
entity with command:
260-668256-014 DECEMBER 2016 111

CHAPTER 9. APPENDIX A – MPLS LABEL RANGES IN AOS
signalling label
range min <value>
max <value>
If not configured, the
entity will use entire
available range 160,001-
200,000
160,001-200,000 AToM services signalled with T-LDP Configured under
(e.g VPWS, VPLS, SAToP) targeted ldp entity with
command :
ldp label range min
<value> max <value>
If multiple targeted LDP
entities are configured on
a single device, they must
have nonoverlapping
label ranges.
200,001-300,000 Space available for static label Availale for configuration
assignment. Usable for static LSPs and as ”local label” in the
AToM. following commands:
Static LSP:
mpls static binding
…
mpls static
crossconnect …
VPWS/AToM:
mpls l2transport
manual <ip-addr>
pwid <id>
locallabel <label>
…
VPLS:
neighbour <ip-addr>
manual pwid <id>
locallabel <label>
…
300,001-400,000 L3VPN Labels The range is internally
resered for L3VPN labels.
400,001-1,048,575 Reserved/Unused in AOS
112 AVIAT NETWORKS

Remote Label Ranges

To allow maximum inter-operability against other vendors, AOS allows the entire MPLS label
space (16-1,048,575) to be used as remote label range for all applications. In cases where remote
label is received via a dynamic signalling protocol, AOS will honour any label in the range (16-
1,048,575) as out label and will push the label to the traffic at the appropriate position in the
MPLS label stack. For static configuration, AOS allows the entire range (16-1,048,575) to be
configured as out label or remote label.
260-668256-014 DECEMBER 2016 113

260-668256-014
WWW.AVIATNETWORKS.COM

Aviat

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Aviat

Hochgeladen von

Copyright:

Verfügbare Formate

CTR 8500 CONFIGURATION

260-668256-014 DECEMBER 2016 I

Aviat Networks Technical & Sales

Sales and Sales Support

Product Compliance Notes

Regulatory Information for ODU 600, 5.8GHz Band

International Use of 5.8GHz

Networking Devices in Electric Power Substations

260-668256-014 DECEMBER 2016 III

Declaration of Conformity, R&TTE Directive, 1999/5/EC

260-668256-014 DECEMBER 2016 V

260-668256-014 DECEMBER 2016 VII

CHAPTER 2. EXAMPLE TOPOLOGIES 7

CHAPTER 3. MPLS TRAFFIC ENGINEERING FUNDAMENTALS 33

260-668256-014 DECEMBER 2016 I

Enabling TE Extensions for IS-IS 35

CHAPTER 4. CONFIGURING MPLS TRAFFIC ENGINEERED LSPS 61

CHAPTER 5. LAYER 2 VIRTUAL PRIVATE NETWORKS 71

CHAPTER 6. LAYER 3 VIRTUAL PRIVATE NETWORKS 83

CHAPTER 7. MPLS PING & TRACE ROUTE 101

CHAPTER 8. END TO END LSP PROTECTION 105

CHAPTER 9. APPENDIX A – MPLS LABEL RANGES IN AOS 111

260-668256-014 DECEMBER 2016 III

Purpose and Scope

260-668256-014 DECEMBER 2016 1

BGP Border Gateway Protocol

OAM Operations, Administration and Management

260-668256-014 DECEMBER 2016 3

VLAN Virtual Local Area Network

How This Manual Is Organized

260-668256-014 DECEMBER 2016 5

Chapter 2. Example Topologies

Figure 2-1. Topology A

260-668256-014 DECEMBER 2016 7

Figure 2-2. Topology B

Figure 2-3. Topology C

Pre-Requisite Global Configurations

Configuring Loopback Interfaces

Configuring IP addresses for Physical Interfaces

260-668256-014 DECEMBER 2016 9

aos(config-if)# ip address 10.0.12.1

IS-IS Router Configuration

IS-IS Circuit Configuration

Useful Show Commands

Example Configuration Scripts: IPv4 and IS-IS

Device Loopback Address IS-IS NET ID

Table 2-2. Topology A - Port Connections and IP Addresses

Device Interface IP Address Connects to

260-668256-014 DECEMBER 2016 11

interface gigabitethernet 0/2

260-668256-014 DECEMBER 2016 13

Device Loopback Address IS-IS NET ID

Table 2-4. Topology B - Port Connections and IP Addresses

Device Interface IP Address Connects to

260-668256-014 DECEMBER 2016 15

260-668256-014 DECEMBER 2016 17

260-668256-014 DECEMBER 2016 19

Device Loopback Address IS-IS NET ID

Table 2-6. Topology C - Port Connections and IP Addresses

Device Interface IP Address Connects to

CTR B Gi 0/4 10.0.26.2/24 CTR F Gi 0/4

260-668256-014 DECEMBER 2016 21

260-668256-014 DECEMBER 2016 23