Download Cisco IOS Switching Services Configuration Guide

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Document related concepts

Net bias wikipedia, lookup

Peering wikipedia, lookup

Parallel port wikipedia, lookup

Airborne Networking wikipedia, lookup

Network tap wikipedia, lookup

Deep packet inspection wikipedia, lookup

Computer network wikipedia, lookup

IEEE 1355 wikipedia, lookup

AppleTalk wikipedia, lookup

Recursive InterNetwork Architecture (RINA) wikipedia, lookup

Point-to-Point Protocol over Ethernet wikipedia, lookup

IEEE 802.1aq wikipedia, lookup

Spanning Tree Protocol wikipedia, lookup

Serial digital interface wikipedia, lookup

Zero-configuration networking wikipedia, lookup

Wake-on-LAN wikipedia, lookup

Cracking of wireless networks wikipedia, lookup

Virtual LAN wikipedia, lookup

Asynchronous Transfer Mode wikipedia, lookup

Multiprotocol Label Switching wikipedia, lookup

Transcript
Cisco IOS
Switching Services
Configuration Guide
Release 12.2
Corporate Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 526-4100
Customer Order Number: DOC-7811749=
Text Part Number: 78-11749-02
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT
NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE
PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR
APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION
PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO
LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of
UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED
“AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL
DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR
INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
AccessPath, AtmDirector, Browse with Me, CCDA, CCDE, CCDP, CCIE, CCNA, CCNP, CCSI, CD-PAC, CiscoLink, the Cisco NetWorks logo, the Cisco
Powered Network logo, Cisco Systems Networking Academy, the Cisco Systems Networking Academy logo, Fast Step, Follow Me Browsing, FormShare,
FrameShare, GigaStack, IGX, Internet Quotient, IP/VC, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, MGX,
the Networkers logo, Packet, PIX, RateMUX, ScriptBuilder, ScriptShare, SlideCast, SMARTnet, TransPath, Unity, Voice LAN, Wavelength Router, and
WebViewer are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All That’s Possible, and Empowering
the Internet Generation, are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, Cisco, the Cisco Certified Internetwork Expert logo,
Cisco IOS, the Cisco IOS logo, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Enterprise/Solver, EtherChannel, EtherSwitch, FastHub,
FastSwitch, IOS, IP/TV, LightStream, MICA, Network Registrar, Post-Routing, Pre-Routing, Registrar, StrataView Plus, Stratm, SwitchProbe, TeleRouter,
and VCO are registered trademarks of Cisco Systems, Inc. or its affiliates in the U.S. and certain other countries.
All other brands, names, or trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner
does not imply a partnership relationship between Cisco and any other company. (0102R)
Cisco IOS Switching Services Configuration Guide
Copyright © 2001–2006 Cisco Systems, Inc.
All rights reserved.
C O N T E N T S
About Cisco IOS Software Documentation
Documentation Objectives
Audience
xxiii
xxiii
xxiii
Documentation Organization xxiii
Documentation Modules xxiii
Master Indexes xxvi
Supporting Documents and Resources
New and Changed Information
Document Conventions
xxvi
xxvii
Command Syntax Conventions
Cisco.com
xxvi
xxviii
xxviii
World Wide Web
xxviii
Documentation CD-ROM
xxix
Ordering Documentation
xxix
Documentation Feedback
xxix
Using Cisco IOS Software
xxxi
Understanding Command Modes
xxxi
Getting Help xxxii
Example: How to Find Command Options
xxxiii
Using the no and default Forms of Commands
xxxv
Saving Configuration Changes
xxxvi
Filtering Output from the show and more Commands
xxxvi
Identifying Supported Platforms xxxvii
Using Feature Navigator xxxvii
Using Software Release Notes xxxvii
Cisco IOS Switching Services Overview
Document Organization
Related References
XC-1
XC-1
XC-2
Cisco IOS Switching Services Configuration Guide
iii
Contents
CISCO IOS SWITCHING PATHS
Cisco IOS Switching Paths Overview
XC-4
Basic Router Platform Architecture and Processes XC-4
Cisco Routing and Switching Processes XC-5
Routing Processes XC-5
Switching Processes XC-6
Basic Switching Paths XC-7
Process Switching XC-7
Fast Switching XC-7
CEF Switching XC-8
dCEF Switching XC-8
Platform and Switching Path Correlation
XC-9
Features That Affect Performance XC-9
Queueing XC-10
Random Early Detection (RED) XC-10
Compression XC-10
Filtering XC-10
Encryption XC-10
Accounting XC-10
Configuring Fast Switching
XC-11
Fast Switching Configuration Task List XC-11
Enabling AppleTalk Fast Switching XC-11
Enabling IP Fast Switching XC-12
Enabling Fast Switching on the Same IP Interface XC-12
Enabling Fast Switching of IPX Directed Broadcast Packets
Enabling SMDS Fast Switching XC-13
Disabling Fast Switching for Troubleshooting XC-13
Disabling AppleTalk Fast Switching XC-14
Disabling Banyan VINES Fast Switching XC-14
Disabling DECnet Fast Switching XC-14
Disabling IPX Fast Switching XC-15
Disabling ISO CLNS Fast Switching Through the Cache
Disabling XNS Fast Switching XC-15
Controlling the Route Cache XC-15
Controlling Route Cache Invalidation for IP XC-16
Displaying System and Network Statistics XC-16
Adjusting the Route Cache for IPX XC-16
Controlling IPX Route Cache Size XC-16
Cisco IOS Switching Services Configuration Guide
iv
XC-13
XC-15
Contents
Controlling IPX Route Cache Invalidation
Padding Odd-Length IPX Packets XC-17
Cisco Express Forwarding Overview
Benefits
XC-17
XC-19
XC-19
Restrictions
XC-20
CEF Components XC-20
Forwarding Information Base XC-21
Adjacency Tables XC-21
Adjacency Discovery XC-21
Adjacency Resolution XC-21
Adjacency Types That Require Special Handling
Unresolved Adjacency XC-22
Supported Media
XC-21
XC-22
CEF Operation Modes XC-22
Central CEF Mode XC-23
Distributed CEF Mode XC-24
CEF and dCEF Additional Capabilities
XC-25
TMS and CEF Nonrecursive Accounting XC-25
TMS Data XC-26
How Backbone Routers Collect TMS Data XC-26
Viewing the TMS Data XC-29
Viewing the TMS Data Through the NDA XC-29
Viewing the TMS Data by Reading the Virtual Files That Reside on the Backbone Router
Viewing TMS Data Through the show ip cef Command XC-32
Viewing the BGP Neighbor Autonomous Systems XC-32
Network Services Engine
Virtual Profile CEF
XC-30
XC-33
XC-34
Configuring Cisco Express Forwarding
XC-36
Configuring CEF XC-36
Enabling CEF or dCEF XC-37
Configuring Load Balancing for CEF XC-38
Configuring per-Destination Load Balancing XC-38
Configuring per-Packet Load Balancing XC-39
Selecting a Load Balancing Algorithm XC-39
Configuring Network Accounting for CEF XC-40
Enabling Network Accounting for CEF XC-40
Enabling a Backbone Router to Collect Traffic Matrix Statistics (TMS) Data
Using the NDA for TMS Data Collection XC-41
XC-40
Cisco IOS Switching Services Configuration Guide
v
Contents
Verifying Network Accounting Information XC-43
Configuring Distributed Tunnel Switching for CEF XC-43
Configuring the Network Services Engine XC-44
Configuring the PXF Processor XC-44
Verifying the PXF Processor XC-44
Troubleshooting the PXF Processor XC-45
Monitoring the PXF Processor XC-45
Configuring Virtual Profile Switching for CEF XC-46
Verifying Virtual Profile Interfaces XC-46
Verifying CEF XC-46
Troubleshooting Tips XC-47
Enabling CEF Consistency Checkers XC-47
Displaying CEF Table Inconsistencies XC-47
Clearing CEF Table Inconsistencies XC-47
IP CEF Nonrecursive Accounting Example
XC-48
NETFLOW SWITCHING
NetFlow Overview
XC-50
Accounting Statistics XC-50
Capturing Traffic Data XC-50
NetFlow Cache XC-51
NetFlow Data Format
XC-51
NetFlow Aggregation XC-54
Benefits XC-54
Aggregation Cache Schemes XC-54
Autonomous System Aggregation Scheme XC-56
Destination Prefix Aggregation Scheme XC-57
Prefix Aggregation Scheme XC-58
Protocol Port Aggregation Scheme XC-59
Source Prefix Aggregation Scheme XC-60
Aggregation Scheme Fields and Key Fields XC-61
Setting a NetFlow Minimum Mask XC-62
NetFlow Policy Routing XC-63
Benefits XC-63
Restrictions XC-64
Configuring NetFlow
What is NetFlow?
XC-65
XC-65
NetFlow Configuration Task List
Cisco IOS Switching Services Configuration Guide
vi
XC-66
Contents
Enabling NetFlow XC-66
Exporting NetFlow Statistics XC-67
Customizing the Number of Entries in the NetFlow Cache XC-67
Managing NetFlow Statistics XC-68
Configuring IP Distributed and NetFlow on VIP Interfaces XC-68
Configuring an Aggregation Cache XC-69
Verifying Aggregation Cache Configuration and Data Export XC-69
Configuring a NetFlow Minimum Prefix Mask for Router-Based Aggregation XC-69
Configuring the Minimum Mask of a Prefix Aggregation Scheme XC-70
Configuring the Minimum Mask of a Destination-Prefix Aggregation Scheme XC-70
Configuring the Minimum Mask of a Source-Prefix Aggregation Scheme XC-70
Monitoring and Maintaining Minimum Masks for Aggregation Schemes XC-71
Configuring NetFlow Policy Routing XC-71
Monitoring NetFlow Policy Routing XC-72
NetFlow Configuration Examples XC-72
NetFlow Configuration Example XC-72
NetFlow Aggregation Configuration Examples XC-76
Autonomous System Configuration Example XC-76
Destination Prefix Configuration Example XC-76
Prefix Configuration Example XC-77
Protocol Port Configuration Example XC-77
Source Prefix Configuration Example XC-77
Setting a NetFlow Minimum Prefix Mask for Router-Based Aggregation Examples
Prefix Aggregation Scheme Example XC-77
Destination-Prefix Aggregation Scheme Example XC-78
Source-Prefix Aggregation Scheme Example XC-78
NetFlow Policy Routing Example XC-78
XC-77
MULTIPROTOCOL LABEL SWITCHING
Multiprotocol Label Switching Overview
MPLS/Tag Switching Terminology
XC-80
XC-81
MPLS Commands and Saved Configurations
MPLS/Tag Switching CLI Command Summary
Benefits
XC-81
XC-82
XC-83
Label Switching Functions
XC-84
Distribution of Label Bindings
MPLS and Routing
XC-85
XC-85
MPLS Traffic Engineering
XC-85
Cisco IOS Switching Services Configuration Guide
vii
Contents
Why Use MPLS Traffic Engineering? XC-86
How MPLS Traffic Engineering Works XC-86
Mapping Traffic into Tunnels XC-87
Enhancement to the SPF Computation XC-87
Special Cases and Exceptions XC-88
Additional Enhancements to SPF Computation Using Configured Tunnel Metrics XC-89
Making the Transition from an IS-IS Network to a New Technology XC-90
New Extensions for the IS-IS Routing Protocol XC-91
The Problem in Theory XC-91
The Problem in Practice XC-91
First Solution for Making the Transition from an IS-IS Network to a New Technology XC-92
Second Solution for Making the Transition from an IS-IS Network to a New Technology XC-93
TLV Configuration Commands XC-93
Implementation in Cisco IOS Software XC-93
MPLS Virtual Private Networks XC-94
Benefits XC-94
Increased BGP Functionality XC-97
VPN Operation XC-98
Distribution of VPN Routing Information XC-99
BGP Distribution of VPN Routing Information XC-99
MPLS Forwarding XC-99
MPLS VPN Cable Interfaces XC-100
Benefits XC-102
Interautonomous Systems for MPLS VPNs XC-103
Routing Between Autonomous Systems XC-104
Routing Between Subautonomous Systems in a Confederation
HSRP Support for MPLS VPNS XC-110
MPLS Quality of Service XC-110
Specifying the QoS in the IP Precedence Field
XC-111
MPLS Label Switch Controller XC-113
MPLS LSC Functional Description XC-113
Using Controlled ATM Switch Ports as Router Interfaces XC-115
Using the MPLS LSC as a Label Edge Device XC-115
Creating Virtual Trunks XC-116
Typical ATM Hybrid Network with Virtual Trunks XC-116
Virtual Trunk Configuration XC-117
Using LSC Redundancy XC-118
LSC Redundancy Architecture XC-119
General Redundancy Operational Modes XC-120
Cisco IOS Switching Services Configuration Guide
viii
XC-109
Contents
How LSC Redundancy Differs from Router and Switch Redundancy XC-120
How the LSC, ATM Switch, and VSI Work Together XC-124
Implementing LSC Redundancy XC-124
Reducing the Number of LVCs for LSC Redundancy XC-128
Implementation Considerations XC-129
Reducing the Number of Label Switch Paths Created in an MPLS Network XC-130
Using an Access List to Disable Creation of LSPs to Destination IP Addresses XC-130
Disabling the LSC from Acting as an Edge LSR XC-133
Using the Cisco 6400 Universal Access Concentrator as an MPLS LSC XC-133
Cisco 6400 UAC Architectural Overview XC-134
Configuring Permanent Virtual Circuits and Permanent Virtual Paths XC-135
Control VC Setup for MPLS LSC Functions XC-137
Configuring the Cisco 6400 UAC to Perform Basic MPLS LSC Operations XC-138
Supporting ATM Forum Protocols XC-139
MPLS Egress NetFlow Accounting
XC-139
Configuring Multiprotocol Label Switching
XC-141
Configuring MPLS Levels of Control XC-141
Case 1—Enable MPLS Incrementally in a Network XC-143
Case 2—Route Labeled Packets to Network A Only XC-144
Case 3—Limit Label Distribution on an MPLS Network XC-144
Configuring a Router for MPLS Forwarding
XC-145
Configuring MPLS Traffic Engineering XC-146
Configuring a Device to Support Tunnels XC-146
Configuring an Interface to Support RSVP-Based Tunnel Signalling and IGP Flooding
Configuring IS-IS for MPLS Traffic Engineering XC-147
Configuring OSPF for MPLS Traffic Engineering XC-148
Configuring an MPLS Traffic Engineering Tunnel XC-148
Configuring MPLS Traffic Engineering Paths
XC-147
XC-149
Configuring MPLS Virtual Private Networks XC-149
Defining VPNs XC-149
Configuring BGP Routing Sessions XC-150
Configuring PE to PE Routing Sessions XC-150
Configuring BGP PE to CE Routing Sessions XC-151
Configuring RIP PE to CE Routing Sessions XC-151
Configuring Static Route PE to CE Routing Sessions XC-152
Configuring MPLS VPNs with Cable Interfaces XC-152
Restrictions XC-153
Creating VRFs for Each VPN XC-154
Cisco IOS Switching Services Configuration Guide
ix
Contents
Defining Subinterfaces on a Physical Cable Interface and Assigning VRFs XC-155
Configuring Cable Interface Bundles XC-156
Configuring Subinterfaces and MPLS VPNs on a Bundle Master XC-157
Configuring MPLS in the P Routers in the Provider Core XC-157
Verifying the MPLS VPN Configuration XC-158
Configuring Interautonomous Systems for MPLS VPNs XC-158
Configuring EBGP Routing for the Exchange of VPN Routes Between Autonomous
Systems XC-159
Configuring EBGP Routing for the Exchange of VPN Routes Between Subautonomous Systems in
a Confederation XC-159
Displaying VPN-IPv4 LFIB Entries XC-161
Verifying VPN Operation XC-161
Configuring MPLS QoS Backbone Support
LSRs XC-162
ATM-LSRs XC-162
ATM Switches XC-163
XC-162
Configuring MPLS QoS XC-164
Configuring QoS XC-164
Setting the MPLS Experimental Field Value XC-165
Importance of Prioritizing a Packet Appropriately XC-165
Configuring the Ingress MPLS Router XC-166
Using the Modular QoS CLI to Configure the Ingress Label Switching Router XC-166
Configuring a Class Map to Classify IP Packets XC-166
Configuring a Policy Map to Set the MPLS Experimental Field XC-167
Configuring the Input Interface to Attach the Service Policy XC-167
Using CAR to Configure the Ingress Label Switching Router XC-167
Configuring a Rate Limit Access List for Classifying IP Packets XC-168
Configuring a Rate-Limit on an Input Interface to Set MPLS Packets XC-168
Configuring the Output IP QoS of the Packet XC-168
Configuring PVC Mode in a Non-MPLS-Enabled Core XC-169
Configuring Multi-VC Mode in a MPLS-Enabled Core XC-169
Configuring Multi-VCs Using the Cos-Map Function XC-170
Configuring DWFQ and Changing Queue Weights on an Outgoing Interface XC-170
Verifying QoS Operation XC-171
Configuring the MPLS Label Switch Controller XC-171
Configuring MPLS on the Cisco 7200 Series LSCs for BPX and IGX Switches XC-171
Configuring the Cisco 6400 UAC LSC XC-172
Configuring Cisco 6400 UAC NRP as an MPLS LSC XC-173
Configuring the Cisco 6400 UAC NSP for MPLS Connectivity to BPX XC-173
Verifying MPLS LSC Configuration XC-175
Cisco IOS Switching Services Configuration Guide
x
Contents
Configuring MPLS Egress NetFlow Accounting XC-175
Enabling MPLS Egress NetFlow Accounting XC-176
Configuring NetFlow Aggregation Cache XC-176
Troubleshooting MPLS Egress NetFlow Accounting XC-176
Verifying MPLS Egress NetFlow Accounting Configuration XC-177
Monitoring and Maintaining MPLS Egress NetFlow Accounting XC-181
Verifying Configuration of MPLS Forwarding
XC-181
MPLS Configuration Examples XC-182
Enabling MPLS Incrementally in a Network Example XC-182
Enabling MPLS for a Subset of Destination Prefixes Example XC-182
Selecting the Destination Prefixes and Paths Example XC-183
Displaying MPLS LDP Binding Information Example XC-183
Displaying MPLS Forwarding Table Information Example XC-184
Displaying MPLS Interface Information Example XC-185
Displaying MPLS LDP Neighbor Information Example XC-186
Enabling LSP Tunnel Signalling Example XC-186
Configuring an LSP Tunnel Example XC-186
Displaying the LSP Tunnel Information Example XC-187
Configuring MPLS Traffic Engineering Examples XC-187
Configuring MPLS Traffic Engineering Using IS-IS Example XC-188
Configuring MPLS Traffic Engineering Using OSPF Example XC-188
Configuring an MPLS Traffic Engineering Tunnel Example XC-189
Configuring Enhanced SPF Routing over a Tunnel Example XC-190
Configuring MPLS VPNs Examples XC-190
Configuring MPLS VPNs Example XC-190
Defining a Cable Subinterface Example XC-192
Cable Interface Bundling Example XC-192
Subinterface Definition on Bundle Master Example XC-193
Cable Interface Bundle Master Configuration Example XC-193
Configuring EBGP Routing to Exchange VPN Routes Between Autonomous Systems XC-200
Configuring EBGP Routing to Exchange VPN Routes Between Autonomous Systems in a
Confederation XC-207
Implementing MPLS QoS Example XC-214
Configuring CEF Example XC-214
Running IP on Router 2 Example XC-215
Running IP on Router 1 Example XC-215
Running MPLS on Router 4 Example XC-215
Running MPLS on Router 3 Example XC-216
Running MPLS on Router 5 Example XC-218
Running MPLS on Router 6 Example XC-219
Cisco IOS Switching Services Configuration Guide
xi
Contents
Configuring ATM Switch 2 Example XC-220
Configuring ATM Switch 1 Example XC-220
Configuring an MPLS LSC Examples XC-221
Configuring ATM-LSRs Example XC-221
Configuring Multi-VCs Example XC-224
Configuring ATM-LSRs with a Cisco 6400 NRP Operating as LSC Example XC-226
Configuring ATM LSRs Through ATM Network Using Cisco 7200 LSCs Implementing Virtual
Trunking Example XC-229
Configuring ATM LSRs Through ATM Network Using Cisco 6400 NRP LSCs Implementing Virtual
Trunking Example XC-232
Configuring LSC Hot Redundancy Example XC-235
Configuring LSC Warm Standby Redundancy Example XC-240
Configuring an Interface Using Two VSI Partitions Example XC-241
Using an Access List to Control the Creation of Headend VCs XC-242
MPLS Egress NetFlow Accounting Example XC-244
MULTILAYER SWITCHING
Multilayer Switching Overview
Terminology
XC-247
XC-248
Introduction to MLS
Key MLS Features
MLS Implementation
XC-248
XC-249
XC-250
Standard and Extended Access Lists XC-252
Restrictions on Using IP Router Commands with MLS Enabled
General Guidelines XC-253
Introduction to IP Multicast MLS XC-253
IP Multicast MLS Network Topology XC-253
IP Multicast MLS Components XC-255
Layer 2 Multicast Forwarding Table XC-255
Layer 3 Multicast MLS Cache XC-255
IP Multicast MLS Flow Mask XC-256
Layer 3-Switched Multicast Packet Rewrite XC-256
Partially and Completely Switched Flows XC-257
Introduction to IPX MLS XC-257
IPX MLS Components XC-258
IPX MLS Flows XC-258
MLS Cache XC-258
Flow Mask Modes XC-259
Layer 3-Switched Packet Rewrite
Cisco IOS Switching Services Configuration Guide
xii
XC-259
XC-253
Contents
IPX MLS Operation XC-260
Standard Access Lists XC-261
Guidelines for External Routers
XC-262
Features That Affect MLS XC-262
Access Lists XC-262
Input Access Lists XC-262
Output Access Lists XC-262
Access List Impact on Flow Masks
Reflexive Access Lists XC-263
IP Accounting XC-263
Data Encryption XC-263
Policy Route Maps XC-263
TCP Intercept XC-263
Network Address Translation XC-263
Committed Access Rate XC-263
Maximum Transmission Unit XC-264
Configuring IP Multilayer Switching
XC-263
XC-265
Configuring and Monitoring MLS XC-265
Configuring MLS on a Router XC-266
Monitoring MLS XC-267
Monitoring MLS for an Interface XC-268
Monitoring MLS Interfaces for VTP Domains
Configuring NetFlow Data Export XC-269
Specifying an NDE Address on the Router
XC-268
XC-269
Multilayer Switching Configuration Examples XC-269
Router Configuration Without Access Lists Example XC-269
Router Configuration with a Standard Access List Example XC-270
Router Configuration with an Extended Access List Example XC-271
Configuring IP Multicast Multilayer Switching
Prerequisites
XC-273
XC-273
Restrictions XC-274
Router Configuration Restrictions XC-274
External Router Guidelines XC-275
Access List Restrictions and Guidelines XC-275
Configuring and Monitoring IP Multicast MLS
Enabling IP Multicast Routing XC-276
Enabling IP PIM XC-276
Enabling IP Multicast MLS XC-276
XC-275
Cisco IOS Switching Services Configuration Guide
xiii
Contents
Specifying a Management Interface XC-277
Monitoring and Maintaining IP Multicast MLS
XC-277
IP Multicast MLS Configuration Examples XC-277
Basic IP Multicast MLS Network Examples XC-278
Network Topology Example XC-278
Operation Before IP Multicast MLS Example XC-279
Operation After IP Multicast MLS Example XC-279
Router Configuration XC-279
Switch Configuration XC-280
Complex IP Multicast MLS Network Examples XC-280
Network Topology Example XC-281
Operation Before IP Multicast MLS Example XC-282
Operation After IP Multicast MLS Example XC-282
Configuring IPX Multilayer Switching
Prerequisites
XC-285
XC-285
Restrictions XC-286
General Configuration Guidelines XC-286
External Router Guidelines XC-286
Access List Restrictions XC-286
Restrictions on Interaction of IPX MLS with Other Features
Restriction on Maximum Transmission Unit Size XC-287
XC-287
IPX MLS Configuration Task List XC-287
Adding an IPX MLS Interface to a VTP Domain XC-288
Enabling Multilayer Switching Protocol (MLSP) on the Router XC-288
Assigning a VLAN ID to a Router Interface XC-288
Enabling IPX MLS on a Router Interface XC-289
Specifying a Router Interface As a Management Interface XC-289
Verifying IPX MLS on the Router XC-289
Troubleshooting Tips
XC-290
Monitoring and Maintaining IPX MLS on the Router
XC-290
IPX MLS Configuration Examples XC-290
Complex IPX MLS Network Examples XC-291
IPX MLS Network Topology Example XC-291
Operation Before IPX MLS Example XC-292
Operation After IPX MLS Example XC-292
Switch A Configuration XC-293
Switch B Configuration XC-293
Switch C Configuration XC-294
Cisco IOS Switching Services Configuration Guide
xiv
Contents
MLS-RP Configuration XC-294
Router with No Access Lists Configuration XC-295
Configuring a Router with a Standard Access List Example
XC-295
MULTICAST DISTRIBUTED SWITCHING
Configuring Multicast Distributed Switching
MDS Configuration Task List XC-299
Enabling MDS XC-299
Monitoring and Maintaining MDS
MDS Configuration Example
XC-298
XC-299
XC-300
VLANS
Routing Between VLANs Overview
XC-302
What Is a VLAN? XC-302
LAN Segmentation XC-303
Security XC-304
Broadcast Control XC-304
Performance XC-304
Network Management XC-304
Network Monitoring Using SNMP XC-304
Communication Between VLANs XC-304
Relaying Function XC-305
Native VLAN XC-307
PVST+ XC-307
Ingress and Egress Rules XC-308
Integrated Routing and Bridging XC-308
VLAN Colors
XC-309
Why Implement VLANs?
XC-309
Communicating Between VLANs XC-309
Inter-Switch Link Protocol XC-310
IEEE 802.10 Protocol XC-310
IEEE 802.1Q Protocol XC-310
ATM LANE Protocol XC-310
ATM LANE Fast Simple Server Replication Protocol
VLAN Interoperability XC-311
Inter-VLAN Communications
VLAN Translation XC-312
Designing Switched VLANs
XC-311
XC-311
XC-312
Cisco IOS Switching Services Configuration Guide
xv
Contents
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
Overview of the ISL Protocol XC-313
Frame Tagging in ISL XC-313
ISL Encapsulation Configuration Task List XC-314
Configuring AppleTalk Routing over ISL XC-314
Enabling AppleTalk Routing XC-315
Defining the VLAN Encapsulation Format XC-315
Configuring AppleTalk on the Subinterface XC-315
Configuring Banyan VINES Routing over ISL XC-316
Enabling Banyan VINES Routing XC-316
Defining the VLAN Encapsulation Format XC-316
Configuring Banyan VINES on the Subinterface XC-316
Configuring DECnet Routing over ISL XC-316
Enabling DECnet Routing XC-317
Defining the VLAN Encapsulation Format XC-317
Configuring DECnet on the Subinterface XC-317
Configuring the Hot Standby Router Protocol over ISL XC-317
Defining the Encapsulation Format XC-319
Defining the IP Address XC-319
Enabling HSRP XC-319
Configuring IP Routing over TRISL XC-320
Enabling IP Routing XC-320
Defining the VLAN Encapsulation Format XC-320
Assigning IP Address to Network Interface XC-321
Configuring IPX Routing on 802.10 VLANs over ISL XC-321
Enabling NetWare Routing XC-322
Defining the VLAN Encapsulation Format XC-322
Configuring NetWare on the Subinterface XC-322
Configuring IPX Routing over TRISL XC-322
Enabling NetWare Routing XC-323
Defining the VLAN Encapsulation Format XC-323
Configuring NetWare on the Subinterface XC-323
Configuring VIP Distributed Switching over ISL XC-324
Enabling IP Routing XC-325
Enabling VIP Distributed Switching XC-325
Configuring ISL Encapsulation on the Subinterface XC-325
Configuring XNS Routing over ISL XC-325
Enabling XNS Routing XC-326
Defining the VLAN Encapsulation Format XC-326
Configuring XNS on the Subinterface XC-326
Cisco IOS Switching Services Configuration Guide
xvi
XC-313
Contents
Configuring CLNS Routing over ISL XC-326
Enabling CLNS Routing XC-327
Defining the VLAN Encapsulation Format XC-327
Configuring CLNS on the Subinterface XC-327
Configuring IS-IS Routing over ISL XC-327
Enabling IS-IS Routing XC-328
Defining the VLAN Encapsulation Format XC-328
Configuring IS-IS on the Subinterface XC-328
Monitoring and Maintaining VLAN Subinterfaces XC-328
ISL Encapsulation Configuration Examples XC-328
AppleTalk Routing over ISL Configuration Examples XC-329
Banyan VINES Routing over ISL Configuration Example XC-330
DECnet Routing over ISL Configuration Example XC-330
HSRP over ISL Configuration Example XC-330
IP Routing with RIF Between TrBRF VLANs Example XC-332
IP Routing Between a TRISL VLAN and an Ethernet ISL VLAN Example XC-333
IPX Routing over ISL Configuration Example XC-334
IPX Routing on FDDI Interfaces with SDE Example XC-335
Routing with RIF Between a TRISL VLAN and a Token Ring Interface Example XC-335
VIP Distributed Switching over ISL Configuration Example XC-336
XNS Routing over ISL Configuration Example XC-338
CLNS Routing over ISL Configuration Example XC-338
IS-IS Routing over ISL Configuration Example XC-338
Configuring Routing Between VLANs with IEEE 802.10 Encapsulation
XC-339
Configuring AppleTalk Routing over IEEE 802.10 XC-339
Enabling AppleTalk Routing XC-340
Configuring AppleTalk on the Subinterface XC-340
Defining the VLAN Encapsulation Format XC-341
Monitoring and Maintaining VLAN Subinterfaces XC-341
Routing AppleTalk over IEEE 802.10 Configuration Example
XC-341
Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation
XC-343
IEEE 802.1Q Encapsulation VLANs Configuration Task List XC-343
Configuring AppleTalk Routing over IEEE 802.1Q XC-344
Enabling AppleTalk Routing XC-344
Configuring AppleTalk on the Subinterface XC-345
Defining the VLAN Encapsulation Format XC-345
Configuring IP Routing over IEEE 802.1Q XC-345
Enabling IP Routing XC-345
Cisco IOS Switching Services Configuration Guide
xvii
Contents
Defining the VLAN Encapsulation Format XC-346
Assigning an IP Address to Network Interface XC-346
Configuring IPX Routing over IEEE 802.1Q XC-346
Enabling NetWare Routing XC-347
Defining the VLAN Encapsulation Format XC-347
Configuring NetWare on the Subinterface XC-347
Configuring a VLAN for a bridge-group with Default VLAN1 XC-347
Configuring a VLAN for a bridge-group as a Native VLAN XC-348
Monitoring and Maintaining VLAN Subinterfaces XC-348
IEEE 802.1Q Encapsulation Configuration Examples XC-348
Configuring AppleTalk over IEEE 802.1Q Example XC-349
Configuring IP Routing over IEEE 802.1Q Example XC-349
Configuring IPX Routing over IEEE 802.1Q Example XC-349
VLAN 100 for Bridge Group 1 with Default VLAN 1 Example XC-349
VLAN 20 for Bridge Group 1 with Native VLAN Example XC-349
VLAN ISL or IEEE 802.1Q Routing Example XC-350
VLAN IEEE 802.1Q Bridging Example XC-351
VLAN IEEE 802.1Q IRB Example XC-352
LAN EMULATION
LAN Emulation Overview
XC-354
LAN Emulation XC-354
LANE Components XC-355
LANE Operation and Communication XC-355
Client Joining an ELAN XC-356
Address Resolution XC-357
Multicast Traffic XC-357
Typical LANE Scenarios XC-358
Single ELAN Scenario XC-358
Multiple ELAN Scenario XC-359
Configuring LAN Emulation
XC-360
LANE on ATM XC-360
Benefits of LANE XC-361
LANE Components XC-361
Simple Server Redundancy XC-361
LANE Implementation Considerations
Network Support XC-362
Hardware Support XC-363
Cisco IOS Switching Services Configuration Guide
xviii
XC-362
Contents
Addressing XC-363
LANE ATM Addresses XC-364
Method of Automatically Assigning ATM Addresses XC-364
Using ATM Address Templates XC-365
Rules for Assigning Components to Interfaces and Subinterfaces XC-366
LANE Configuration Task List XC-366
Creating a LANE Plan and Worksheet XC-367
Configuring the Prefix on the Switch XC-367
Setting Up the Signalling and ILMI PVCs XC-368
Displaying LANE Default Addresses XC-368
Entering the LECS’s ATM Address on the Cisco Switch XC-368
Entering the ATM Addresses on the Cisco LightStream 1010 ATM Switch XC-369
Entering the ATM Addresses on the Cisco LightStream 100 ATM Switch XC-369
Setting Up the LECS’s Database XC-370
Setting Up the Database for the Default ELAN Only XC-370
Setting Up the Database for Unrestricted-Membership Emulated LANs XC-371
Setting Up the Database for Restricted-Membership LANs XC-372
Enabling the LECS XC-373
Setting Up LESs and Clients XC-374
Setting Up the Server, BUS, and a Client on a Subinterface XC-375
Setting Up Only a Client on a Subinterface XC-375
Disabling the LE_FLUSH Process of LAN Emulation Clients XC-376
Setting Up LANE Clients for MPOA XC-377
Configuring Fault-Tolerant Operation XC-377
Simple Server Redundancy Requirements XC-377
Fast Simple Server Redundancy Requirements XC-378
Redundant Configuration Servers XC-378
Redundant Servers and BUSs XC-378
Implementation Considerations XC-378
SSRP Changes to Reduce Network Flap XC-380
Monitoring and Maintaining the LANE Components XC-381
LANE Configuration Examples XC-383
Default Configuration for a Single Ethernet ELAN Example XC-383
Default Configuration for a Single Ethernet ELAN with a Backup LECS and LES Example
Multiple Token Ring ELANs with Unrestricted Membership Example XC-385
Router 1 Configuration XC-386
Router 2 Configuration XC-387
Router 3 Configuration XC-387
Router 4 Configuration XC-387
Multiple Token Ring ELANs with Restricted Membership Example XC-388
XC-384
Cisco IOS Switching Services Configuration Guide
xix
Contents
Router 1 Configuration XC-388
Router 2 Configuration XC-389
Router 3 Configuration XC-389
Router 4 Configuration XC-390
TR-LANE with 2-Port SRB Example XC-390
Router 1 Configuration XC-391
Router 2 Configuration XC-391
TR-LANE with Multiport SRB Example XC-392
Router 1 Configuration XC-392
Router 2 Configuration XC-393
Routing Between Token Ring and Ethernet Emulated LANs Example
Router 1 Configuration XC-394
Router 2 Configuration XC-395
Router 3 Configuration XC-395
Disabling LANE Flush Process Example XC-396
Configuring Token Ring LAN Emulation
XC-394
XC-397
Token Ring LANE on ATM XC-397
Benefits XC-398
LANE Token Ring Components XC-398
Network Support
Restrictions
Prerequisites
XC-399
XC-400
XC-401
Token Ring LANE Configuration Task List XC-402
Opening a Session from the Switch to the ATM Module XC-402
Creating a LANE Plan and Worksheet XC-403
Default LANE Configuration XC-404
Configuring the ATM Module from the Terminal XC-404
Configuring the ATM Module from NVRAM XC-405
Configuring the Prefix on the LightStream 1010 Switch XC-405
Setting Up the Signalling PVC XC-406
Displaying LANE Default Addresses XC-406
Entering the LECS ATM Address on the LightStream 1010 Switch XC-406
Configuring the LECS Database XC-407
Setting Up the Database for the Default ELAN XC-408
Setting Up the Database for Unrestricted-Membership ELANs XC-409
Setting Up the Database for Restricted-Membership ELANs XC-410
Binding the LECS to the ATM Interface XC-412
Setting Up a LES/BUS and a LEC XC-412
Setting Up the LES/BUS for an ELAN XC-413
Cisco IOS Switching Services Configuration Guide
xx
Contents
Setting Up a LEC for an ELAN XC-413
Configuring Redundant LANE Services XC-416
Enabling Redundant LECSs XC-417
Enabling ILMI Keepalive Timeout XC-417
Using UNI 3.1 Signalling Support XC-418
Configuring Fast SSRP for Redundant LANE Services
Verifying the LANE Setup XC-420
Monitoring and Maintaining LANE Components XC-421
Token Ring LANE Configuration Example XC-421
Example Assumptions XC-422
Configuring the TrCRF Example XC-422
Configuring the LES/BUS and the LEC Example
Multiprotocol over ATM Overview
XC-418
XC-422
XC-427
How MPOA Works XC-427
Traffic Flow XC-429
Interaction with LANE XC-429
MPOA Components
Benefits
XC-430
XC-431
Configuring an MPC/MPS
XC-431
Configuring the Multiprotocol over ATM Client
How MPC Works
XC-433
XC-433
MPC Configuration Task List XC-433
Configuring the ELAN ID XC-434
Configuring the MPC XC-434
Configuring the MPC Variables XC-435
Monitoring and Maintaining the MPC XC-435
MPC Configuration Example
XC-436
Configuring the Multiprotocol over ATM Server
How MPS Works XC-439
MPS-NHRP-Routing Interaction
Shortcut Domains XC-440
XC-439
XC-439
MPS Configuration Task List XC-440
Configuring the ELAN ID XC-440
Configuring the MPS XC-441
Configuring the MPS Variables XC-441
Monitoring and Maintaining the MPS XC-442
MPS Configuration Example
XC-442
Cisco IOS Switching Services Configuration Guide
xxi
Contents
Configuring Token Ring LAN Emulation for Multiprotocol over ATM
How Token Ring MPOA Works
XC-445
XC-445
Token Ring LANE for MPOA Configuration Task List
Configuring a Token Ring LEC XC-446
Configuring the LECS Database XC-446
Configuring the LES/BUS XC-446
XC-445
Token Ring LANE Configuration Examples XC-447
MPOA Token Ring LANE Configuration in an IP-Routed Domain Example XC-447
MPOA Token Ring LANE Configuration in an IP SRB-Routed Domain Example XC-451
INDEX
Cisco IOS Switching Services Configuration Guide
xxii
About Cisco IOS Software Documentation
This chapter discusses the objectives, audience, organization, and conventions of Cisco IOS software
documentation. It also provides sources for obtaining documentation from Cisco Systems.
Documentation Objectives
Cisco IOS software documentation describes the tasks and commands necessary to configure and
maintain Cisco networking devices.
Audience
The Cisco IOS software documentation set is intended primarily for users who configure and maintain
Cisco networking devices (such as routers and switches) but who may not be familiar with the tasks,
the relationship between tasks, or the Cisco IOS software commands necessary to perform particular
tasks.
Documentation Organization
The Cisco IOS software documentation set consists of documentation modules and master indexes. In
addition to the main documentation set, there are supporting documents and resources.
Documentation Modules
The Cisco IOS documentation modules consist of configuration guides and corresponding command
reference publications. Chapters in a configuration guide describe protocols, configuration tasks, and
Cisco IOS software functionality and contain comprehensive configuration examples. Chapters in a
command reference publication provide complete Cisco IOS command syntax information. Use each
configuration guide in conjunction with its corresponding command reference publication.
Cisco IOS Switching Services Configuration Guide
xxiii
About Cisco IOS Software Documentation
Documentation Organization
Figure 1 shows the Cisco IOS software documentation modules.
Note
Figure 1
The abbreviations (for example, FC and FR) next to the book icons are page designators,
which are defined in a key in the index of each document to help you with navigation. The
bullets under each module list the major technology areas discussed in the corresponding
books.
Cisco IOS Software Documentation Modules
IPC
FC
Cisco IOS
Configuration
Fundamentals
Configuration
Guide
Cisco IOS
Configuration
Fundamentals
Command
Reference
FR
IP2R
Module FC/FR:
• Cisco IOS User
Interfaces
• File Management
• System Management
Cisco IOS
Wide-Area
Networking
Command
Reference
WR
Module WC/WR:
• ATM
• Broadband Access
• Frame Relay
• SMDS
• X.25 and LAPB
Cisco IOS
IP Command
Reference,
Volume 1 of 3:
Addressing
and Services
Cisco IOS
IP Command
Reference,
Volume 2 of 3:
Routing
Protocols
P2C
IP3R
Cisco IOS
IP Command
Reference,
Volume 3 of 3:
Multicast
Cisco IOS
Interface
Configuration
Guide
IR
P3C
Cisco IOS
AppleTalk and
Novell IPX
Configuration
Guide
P2R
Module IPC/IP1R/IP2R/IP3R:
• IP Addressing and Services
• IP Routing Protocols
• IP Multicast
IC
Cisco IOS
Wide-Area
Networking
Configuration
Guide
IP1R
Module IC/IR:
• LAN Interfaces
• Serial Interfaces
• Logical Interfaces
P3R
Module P2C/P2R:
• AppleTalk
• Novell IPX
MWC
Cisco IOS
Interface
Command
Reference
Cisco IOS
AppleTalk and
Novell IPX
Command
Reference
Cisco IOS
Mobile
Wireless
Configuration
Guide
MWR
Cisco IOS
Mobile
Wireless
Command
Reference
Module MWC/MWR:
• General Packet
Radio Service
Cisco IOS
Apollo Domain,
Banyan VINES,
DECnet, ISO
CLNS, and XNS
Configuration
Guide
SC
Cisco IOS
Apollo Domain,
Banyan VINES,
DECnet, ISO
CLNS, and XNS
Command
Reference
Module P3C/P3R:
• Apollo Domain
• Banyan VINES
• DECnet
• ISO CLNS
• XNS
Cisco IOS
Security
Configuration
Guide
SR
Cisco IOS
Security
Command
Reference
Module SC/SR:
• AAA Security Services
• Security Server Protocols
• Traffic Filtering and Firewalls
• IP Security and Encryption
• Passwords and Privileges
• Neighbor Router Authentication
• IP Security Options
• Supported AV Pairs
47953
WC
Cisco IOS
IP
Configuration
Guide
Cisco IOS Switching Services Configuration Guide
xxiv
About Cisco IOS Software Documentation
Documentation Organization
Cisco IOS
Dial
Technologies
Configuration
Guide
TC
BC
Cisco IOS
Terminal
Services
Configuration
Guide
Cisco IOS
Bridging and
IBM Networking
Configuration
Guide
B2R
B1R
DR
Cisco IOS
Dial
Technologies
Command
Reference
TR
Module DC/DR:
• Preparing for Dial Access
• Modem and Dial Shelf Configuration
and Management
• ISDN Configuration
• Signalling Configuration
• Dial-on-Demand Routing
Configuration
• Dial-Backup Configuration
• Dial-Related Addressing Services
• Virtual Templates, Profiles, and
Networks
• PPP Configuration
• Callback and Bandwidth Allocation
Configuration
• Dial Access Specialized Features
• Dial Access Scenarios
VC
Cisco IOS
Voice, Video,
and Fax
Configuration
Guide
VR
Cisco IOS
Voice, Video,
and Fax
Command
Reference
Module VC/VR:
• Voice over IP
• Call Control Signalling
• Voice over
Frame Relay
• Voice over ATM
• Telephony Applications
• Trunk Management
• Fax, Video, and
Modem Support
Cisco IOS
Terminal
Services
Command
Reference
Module TC/TR:
• ARA
• LAT
• NASI
• Telnet
• TN3270
• XRemote
• X.28 PAD
• Protocol Translation
QC
Cisco IOS
Quality of
Service
Solutions
Configuration
Guide
QR
Cisco IOS
Quality of
Service
Solutions
Command
Reference
Module QC/QR:
• Packet Classification
• Congestion Management
• Congestion Avoidance
• Policing and Shaping
• Signalling
• Link Efficiency
Mechanisms
Cisco IOS
Bridging
and IBM
Networking
Command
Reference,
Volume 1 of 2
Cisco IOS
Bridging
and IBM
Networking
Command
Reference,
Volume 2 of 2
Module BC/B1R:
• Transparent
Bridging
• SRB
• Token Ring
Inter-Switch Link
• Token Ring Route
Switch Module
• RSRB
• DLSw+
• Serial Tunnel and
Block Serial Tunnel
• LLC2 and SDLC
• IBM Network
Media Translation
• SNA Frame Relay
Access
• NCIA Client/Server
• Airline Product Set
XC
Module BC/B2R:
• DSPU and SNA
Service Point
• SNA Switching
Services
• Cisco Transaction
Connection
• Cisco Mainframe
Channel Connection
• CLAW and TCP/IP
Offload
• CSNA, CMPC,
and CMPC+
• TN3270 Server
Cisco IOS
Switching
Services
Configuration
Guide
XR
Cisco IOS
Switching
Services
Command
Reference
Module XC/XR:
• Cisco IOS
Switching Paths
• NetFlow Switching
• Multiprotocol Label Switching
• Multilayer Switching
• Multicast Distributed Switching
• Virtual LANs
• LAN Emulation
47954
DC
Cisco IOS Switching Services Configuration Guide
xxv
About Cisco IOS Software Documentation
New and Changed Information
Master Indexes
Two master indexes provide indexing information for the Cisco IOS software documentation set:
an index for the configuration guides and an index for the command references. Individual books also
contain a book-specific index.
The master indexes provide a quick way for you to find a command when you know the command name
but not which module contains the command. When you use the online master indexes, you can click
the page number for an index entry and go to that page in the online document.
Supporting Documents and Resources
The following documents and resources support the Cisco IOS software documentation set:
•
Cisco IOS Command Summary (two volumes)—This publication explains the function and syntax
of the Cisco IOS software commands. For more information about defaults and usage guidelines,
refer to the Cisco IOS command reference publications.
•
Cisco IOS System Error Messages—This publication lists and describes Cisco IOS system error
messages. Not all system error messages indicate problems with your system. Some are purely
informational, and others may help diagnose problems with communications lines, internal
hardware, or the system software.
•
Cisco IOS Debug Command Reference—This publication contains an alphabetical listing of the
debug commands and their descriptions. Documentation for each command includes a brief
description of its use, command syntax, usage guidelines, and sample output.
•
Internetworking Terms and Acronyms—This Cisco publication compiles and defines the terms and
acronyms used in the internetworking industry.
•
New feature documentation—Feature module documentation introduces new networking
functionality, released after the publication of the Cisco IOS software documentation set, that
supports Cisco networking technology and hardware.
•
Release notes—This documentation describes system requirements, provides new and changed
information, and includes other useful information about specific software releases.
•
Caveats documentation—This documentation provides information about Cisco IOS software
defects in specific software releases.
New and Changed Information
Since the last release of the Cisco IOS Switching Services Configuration Guide, the term ‘quality of
service’ (QoS) replaces the term ‘class of service’ (CoS). All references to Multiprotocol Label
Switching (MPLS) CoS functionality has been replaced by the MPLS QoS functionality, which is
documented in the “Multiprotocol Label Switching Overview” chapter and the “Configuring
Multiprotocol Label Switching” chapter.
Cisco IOS Switching Services Configuration Guide
xxvi
About Cisco IOS Software Documentation
Document Conventions
Document Conventions
The Cisco IOS documentation set uses the following conventions:
Convention
Description
^ or Ctrl
The ^ and Ctrl symbols represent the Control key. For example, the key combination ^D or Ctrl-D
means hold down the Control key while you press the D key. Keys are indicated in capital letters but
are not case sensitive.
string
A string is a nonquoted set of characters. For example, when setting an SNMP community string to
public, do not use quotation marks around the string or the string will include the quotation marks.
Examples use the following conventions:
Convention
Description
screen
Examples of information displayed on the screen are set in Courier font.
boldface screen
Examples of text that you must enter are set in Courier bold font.
<
Angle brackets enclose nonprinting characters, such as passwords.
>
!
[
An exclamation point at the beginning of a line indicates a comment line. (Exclamation points are also
displayed by the Cisco IOS software for certain processes.)
]
Square brackets enclose default responses to system prompts.
The following conventions are used to attract the attention of the reader:
Caution
Note
Timesaver
Means reader be careful. In this situation, you might do something that could result in
equipment damage or loss of data.
Means reader take note. Notes contain helpful suggestions or references to materials not
contained in this manual.
Means the described action saves time. You can save time by performing the action
described in the paragraph.
Within Cisco IOS software documentation, the term router is generally used to refer to a variety of Cisco
products (for example, routers, access servers, and switches). Routers, access servers, and other
networking devices that support Cisco IOS software are shown interchangeably within examples. These
products are used only for illustrative purposes; that is, an example that shows one product does not
necessarily indicate that other products are not supported.
Cisco IOS Switching Services Configuration Guide
xxvii
About Cisco IOS Software Documentation
Command Syntax Conventions
Command Syntax Conventions
Command syntax descriptions use the following conventions:
Convention
Description
boldface
Boldface text indicates commands and keywords that you enter literally as shown.
italics
Italic text indicates arguments for which you supply values.
[x]
Square brackets enclose an optional element (keyword or argument).
{x}
Braces enclose a required element (keyword or argument).
|
A vertical line, or pipe, indicates a choice within an optional or required element.
[x {y | z}]
Braces and vertical lines (pipes) within square brackets indicate a required choice within an
optional element.
Cisco.com
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open
access to Cisco information and resources at any time, from anywhere in the world. This highly
integrated Internet application is a powerful, easy-to-use tool for doing business with Cisco.
Cisco.com provides a broad range of features and services to help customers and partners streamline
business processes and improve productivity. Through Cisco.com, you can find information about Cisco
and our networking solutions, services, and programs. In addition, you can resolve technical issues
using online technical support, you can download and test software packages, and you can order Cisco
learning materials and merchandise. Valuable online skill assessment, training, and certification
programs are also available.
Customers and partners can self-register on Cisco.com to obtain additional personalized information
and services. Registered users can order products, check on the status of an order, access technical
support, and view benefits specific to their relationships with Cisco.
To access Cisco.com, go to the following website:
http://www.cisco.com
World Wide Web
You can access the most current Cisco documentation on the World Wide Web at the following sites:
•
http://www.cisco.com
•
http://www-china.cisco.com
•
http://www-europe.cisco.com
Cisco IOS Switching Services Configuration Guide
xxviii
About Cisco IOS Software Documentation
Documentation CD-ROM
Documentation CD-ROM
Cisco documentation and additional literature are available in a CD-ROM package, which ships
with your product. The Documentation CD-ROM is updated monthly and may be more current than
printed documentation. The CD-ROM package is available as a single unit or as an annual subscription.
Ordering Documentation
Cisco documentation can by ordered in the following ways:
•
Registered Cisco Direct Customers can order Cisco product documentation from the Networking
Products MarketPlace:
http://www.cisco.com/cgi-bin/order/order_root.pl
•
Registered Cisco.com users can order the Documentation CD-ROM through the online
Subscription Store:
http://www.cisco.com/go/subscription
•
Nonregistered Cisco.com users can order documentation through a local account representative by
calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, in North America, by
calling 800 553-NETS(6387).
Documentation Feedback
If you are reading Cisco product documentation on the World Wide Web, you can submit technical
comments electronically. Click Feedback in the toolbar and select Documentation. After you complete
the form, click Submit to send it to Cisco.
You can e-mail your comments to [email protected]
To submit your comments by mail, for your convenience many documents contain a response card
behind the front cover. Otherwise, you can mail your comments to the following address:
Cisco Systems, Inc.
Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
Cisco IOS Switching Services Configuration Guide
xxix
About Cisco IOS Software Documentation
Documentation Feedback
Cisco IOS Switching Services Configuration Guide
xxx
Using Cisco IOS Software
This chapter provides helpful tips for understanding and configuring Cisco IOS software using the
command-line interface (CLI). It contains the following sections:
•
Understanding Command Modes
•
Getting Help
•
Using the no and default Forms of Commands
•
Saving Configuration Changes
•
Filtering Output from the show and more Commands
•
Identifying Supported Platforms
For an overview of Cisco IOS software configuration, refer to the Cisco IOS Configuration
Fundamentals Configuration Guide.
For information on the conventions used in the Cisco IOS software documentation set, see the chapter
“About Cisco IOS Software Documentation” located at the beginning of this book.
Understanding Command Modes
You use the CLI to access Cisco IOS software. Because the CLI is divided into many different modes,
the commands available to you at any given time depend on the mode you are currently in. Entering a
question mark (?) at the CLI prompt allows you to obtain a list of commands available for each
command mode.
When you log in to the CLI, you are in user EXEC mode. User EXEC mode contains only a limited
subset of commands. To have access to all commands, you must enter privileged EXEC mode, normally
by using a password. From privileged EXEC mode you can issue any EXEC command—user or
privileged mode—or you can enter global configuration mode. Most EXEC commands are one-time
commands. For example, show commands show important status information, and clear commands
clear counters or interfaces. The EXEC commands are not saved when the software reboots.
Configuration modes allow you to make changes to the running configuration. If you later save the
running configuration to the startup configuration, these changed commands are stored when the
software is rebooted. To enter specific configuration modes, you must start at global configuration
mode. From global configuration mode, you can enter interface configuration mode and a variety of
other modes, such as protocol-specific modes.
ROM monitor mode is a separate mode used when the Cisco IOS software cannot load properly. If a
valid software image is not found when the software boots or if the configuration file is corrupted at
startup, the software might enter ROM monitor mode.
Cisco IOS Switching Services Configuration Guide
xxxi
Using Cisco IOS Software
Getting Help
Table 1 describes how to access and exit various common command modes of the Cisco IOS software.
It also shows examples of the prompts displayed for each mode.
Table 1
Accessing and Exiting Command Modes
Command
Mode
Access Method
Prompt
Exit Method
User EXEC
Log in.
Router>
Use the logout command.
Privileged
EXEC
From user EXEC mode,
use the enable EXEC
command.
Router#
To return to user EXEC mode, use the disable
command.
Global
configuration
From privileged EXEC
mode, use the configure
terminal privileged
EXEC command.
Router(config)#
To return to privileged EXEC mode from global
configuration mode, use the exit or end command,
or press Ctrl-Z.
Interface
configuration
From global
configuration mode,
specify an interface using
an interface command.
Router(config-if)#
To return to global configuration mode, use the exit
command.
From privileged EXEC
mode, use the reload
EXEC command. Press
the Break key during the
first 60 seconds while the
system is booting.
>
ROM monitor
To return to privileged EXEC mode, use the end
command, or press Ctrl-Z.
To exit ROM monitor mode, use the continue
command.
For more information on command modes, refer to the “Using the Command-Line Interface” chapter in
the Cisco IOS Configuration Fundamentals Configuration Guide.
Getting Help
Entering a question mark (?) at the CLI prompt displays a list of commands available for each command
mode. You can also get a list of keywords and arguments associated with any command by using the
context-sensitive help feature.
To get help specific to a command mode, a command, a keyword, or an argument, use one of the
following commands:
Command
Purpose
help
Provides a brief description of the help system in any command mode.
abbreviated-command-entry?
Provides a list of commands that begin with a particular character string. (No space
between command and question mark.)
abbreviated-command-entry<Tab>
Completes a partial command name.
?
Lists all commands available for a particular command mode.
command ?
Lists the keywords or arguments that you must enter next on the command line.
(Space between command and question mark.)
Cisco IOS Switching Services Configuration Guide
xxxii
Using Cisco IOS Software
Getting Help
Example: How to Find Command Options
This section provides an example of how to display syntax for a command. The syntax can consist of
optional or required keywords and arguments. To display keywords and arguments for a command, enter
a question mark (?) at the configuration prompt or after entering part of a command followed by a space.
The Cisco IOS software displays a list and brief description of available keywords and arguments. For
example, if you were in global configuration mode and wanted to see all the keywords or arguments for
the arap command, you would type arap ?.
The <cr> symbol in command help output stands for “carriage return.” On older keyboards, the carriage
return key is the Return key. On most modern keyboards, the carriage return key is the Enter key. The
<cr> symbol at the end of command help output indicates that you have the option to press Enter to
complete the command and that the arguments and keywords in the list preceding the <cr> symbol are
optional. The <cr> symbol by itself indicates that no more arguments or keywords are available and that
you must press Enter to complete the command.
Table 2 shows examples of how you can use the question mark (?) to assist you in entering commands.
The table steps you through configuring an IP address on a serial interface on a Cisco 7206 router that
is running Cisco IOS Release 12.0(3).
Table 2
How to Find Command Options
Command
Comment
Router> enable
Password: <password>
Router#
Enter the enable command and
password to access privileged EXEC
commands. You are in privileged
EXEC mode when the prompt changes
to Router#.
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#
Enter the configure terminal
privileged EXEC command to enter
global configuration mode. You are in
global configuration mode when the
prompt changes to Router(config)#.
Router(config)# interface serial ?
<0-6>
Serial interface number
Router(config)# interface serial 4 ?
/
Router(config)# interface serial 4/ ?
<0-3>
Serial interface number
Router(config)# interface serial 4/0
Router(config-if)#
Enter interface configuration mode by
specifying the serial interface that you
want to configure using the interface
serial global configuration command.
Enter ? to display what you must enter
next on the command line. In this
example, you must enter the serial
interface slot number and port number,
separated by a forward slash.
You are in interface configuration mode
when the prompt changes to
Router(config-if)#.
Cisco IOS Switching Services Configuration Guide
xxxiii
Using Cisco IOS Software
Getting Help
Table 2
How to Find Command Options (continued)
Command
Comment
Router(config-if)# ?
Interface configuration commands:
.
.
.
ip
Interface Internet Protocol config commands
keepalive
Enable keepalive
lan-name
LAN Name command
llc2
LLC2 Interface Subcommands
load-interval
Specify interval for load calculation for an
interface
locaddr-priority
Assign a priority group
logging
Configure logging for interface
loopback
Configure internal loopback on an interface
mac-address
Manually set interface MAC address
mls
mls router sub/interface commands
mpoa
MPOA interface configuration commands
mtu
Set the interface Maximum Transmission Unit (MTU)
netbios
Use a defined NETBIOS access list or enable
name-caching
no
Negate a command or set its defaults
nrzi-encoding
Enable use of NRZI encoding
ntp
Configure NTP
.
.
.
Router(config-if)#
Enter ? to display a list of all the
interface configuration commands
available for the serial interface. This
example shows only some of the
available interface configuration
commands.
Router(config-if)# ip ?
Interface IP configuration subcommands:
access-group
Specify access control for packets
accounting
Enable IP accounting on this interface
address
Set the IP address of an interface
authentication
authentication subcommands
bandwidth-percent
Set EIGRP bandwidth limit
broadcast-address
Set the broadcast address of an interface
cgmp
Enable/disable CGMP
directed-broadcast Enable forwarding of directed broadcasts
dvmrp
DVMRP interface commands
hello-interval
Configures IP-EIGRP hello interval
helper-address
Specify a destination address for UDP broadcasts
hold-time
Configures IP-EIGRP hold time
.
.
.
Router(config-if)# ip
Enter the command that you want to
configure for the interface. This
example uses the ip command.
Cisco IOS Switching Services Configuration Guide
xxxiv
Enter ? to display what you must enter
next on the command line. This
example shows only some of the
available interface IP configuration
commands.
Using Cisco IOS Software
Using the no and default Forms of Commands
Table 2
How to Find Command Options (continued)
Command
Comment
Router(config-if)# ip address ?
A.B.C.D
IP address
negotiated
IP Address negotiated over PPP
Router(config-if)# ip address
Enter the command that you want to
configure for the interface. This
example uses the ip address command.
Enter ? to display what you must enter
next on the command line. In this
example, you must enter an IP address
or the negotiated keyword.
A carriage return (<cr>) is not
displayed; therefore, you must enter
additional keywords or arguments to
complete the command.
Enter the keyword or argument you
want to use. This example uses the
172.16.0.1 IP address.
Router(config-if)# ip address 172.16.0.1 ?
A.B.C.D
IP subnet mask
Router(config-if)# ip address 172.16.0.1
Enter ? to display what you must enter
next on the command line. In this
example, you must enter an IP subnet
mask.
A <cr> is not displayed; therefore, you
must enter additional keywords or
arguments to complete the command.
Router(config-if)# ip address 172.16.0.1 255.255.255.0 ?
secondary
Make this IP address a secondary address
<cr>
Router(config-if)# ip address 172.16.0.1 255.255.255.0
Enter the IP subnet mask. This example
uses the 255.255.255.0 IP subnet mask.
Enter ? to display what you must enter
next on the command line. In this
example, you can enter the secondary
keyword, or you can press Enter.
A <cr> is displayed; you can press
Enter to complete the command, or
you can enter another keyword.
Router(config-if)# ip address 172.16.0.1 255.255.255.0
Router(config-if)#
In this example, Enter is pressed to
complete the command.
Using the no and default Forms of Commands
Almost every configuration command has a no form. In general, use the no form to disable a function.
Use the command without the no keyword to reenable a disabled function or to enable a function that
is disabled by default. For example, IP routing is enabled by default. To disable IP routing, use the no
ip routing command; to reenable IP routing, use the ip routing command. The Cisco IOS software
command reference publications provide the complete syntax for the configuration commands and
describe what the no form of a command does.
Configuration commands also can have a default form, which returns the command settings to the
default values. Most commands are disabled by default, so in such cases using the default form has the
same result as using the no form of the command. However, some commands are enabled by default and
Cisco IOS Switching Services Configuration Guide
xxxv
Using Cisco IOS Software
Saving Configuration Changes
have variables set to certain default values. In these cases, the default form of the command enables the
command and sets the variables to their default values. The Cisco IOS software command reference
publications describe the effect of the default form of a command if the command functions differently
than the no form.
Saving Configuration Changes
Use the copy system:running-config nvram:startup-config command to save your configuration
changes to the startup configuration so that the changes will not be lost if the software reloads or a
power outage occurs. For example:
Router# copy system:running-config nvram:startup-config
Building configuration...
It might take a minute or two to save the configuration. After the configuration has been saved, the
following output appears:
[OK]
Router#
On most platforms, this task saves the configuration to NVRAM. On the Class A Flash file system
platforms, this task saves the configuration to the location specified by the CONFIG_FILE environment
variable. The CONFIG_FILE variable defaults to NVRAM.
Filtering Output from the show and more Commands
In Cisco IOS Release 12.0(1)T and later releases, you can search and filter the output of show and more
commands. This functionality is useful if you need to sort through large amounts of output or if you
want to exclude output that you need not see.
To use this functionality, enter a show or more command followed by the “pipe” character (|); one of
the keywords begin, include, or exclude; and a regular expression on which you want to search or filter
(the expression is case-sensitive):
command | {begin | include | exclude} regular-expression
The output matches certain lines of information in the configuration file. The following example
illustrates how to use output modifiers with the show interface command when you want the output to
include only lines in which the expression “protocol” appears:
Router# show interface | include protocol
FastEthernet0/0 is up, line protocol is up
Serial4/0 is up, line protocol is up
Serial4/1 is up, line protocol is up
Serial4/2 is administratively down, line protocol is down
Serial4/3 is administratively down, line protocol is down
For more information on the search and filter functionality, refer to the “Using the Command-Line
Interface” chapter in the Cisco IOS Configuration Fundamentals Configuration Guide.
Cisco IOS Switching Services Configuration Guide
xxxvi
Using Cisco IOS Software
Identifying Supported Platforms
Identifying Supported Platforms
Cisco IOS software is packaged in feature sets consisting of software images that support specific
platforms. The feature sets available for a specific platform depend on which Cisco IOS software
images are included in a release. To identify the set of software images available in a specific release
or to find out if a feature is available in a given Cisco IOS software image, see the following sections:
•
Using Feature Navigator
•
Using Software Release Notes
Using Feature Navigator
Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software
images support a particular set of features and which features are supported in a particular Cisco IOS
image.
Feature Navigator is available 24 hours a day, 7 days a week. To access Feature Navigator, you must
have an account on Cisco.com. If you have forgotten or lost your account information, e-mail the
Contact Database Administration group at [email protected] If you do not have an account on
Cisco.com, go to http://www.cisco.com/register and follow the directions to establish an account.
To use Feature Navigator, you must have a JavaScript-enabled web browser such as Netscape 3.0 or
later, or Internet Explorer 4.0 or later. Internet Explorer 4.0 always has JavaScript enabled. To enable
JavaScript for Netscape 3.x or Netscape 4.x, follow the instructions provided with the web browser. For
JavaScript support and enabling instructions for other browsers, check with the browser vendor.
Feature Navigator is updated when major Cisco IOS software releases and technology releases occur.
You can access Feature Navigator at the following URL:
http://www.cisco.com/go/fn
Using Software Release Notes
Cisco IOS software releases include release notes that provide the following information:
•
Platform support information
•
Memory recommendations
•
Microcode support information
•
Feature set tables
•
Feature descriptions
•
Open and resolved severity 1 and 2 caveats for all platforms
Release notes are intended to be release-specific for the most current release, and the information
provided in these documents may not be cumulative in providing information about features that first
appeared in previous releases.
Cisco IOS Switching Services Configuration Guide
xxxvii
Using Cisco IOS Software
Identifying Supported Platforms
Cisco IOS Switching Services Configuration Guide
xxxviii
Cisco IOS Switching Services Overview
The Cisco IOS Switching Services Configuration Guide provides guidelines for configuring switching
paths and routing between virtual local-area networks (VLANs) by using Cisco IOS software.
This guide is intended for the network administrator who designs and implements router-based
internetworks and needs to incorporate switching, NetFlow accounting, or routing between VLANs into
the network. It presents a set of general guidelines for configuring switching of various protocols,
NetFlow accounting, routing between VLANs, and LAN emulation. The objective of this guide is to
provide you with the information you need to configure any of these features.
You should know how to configure a Cisco router and should be familiar with the protocols and media
that your routers are configured to support. Knowledge of basic network topology is essential.
Document Organization
This document comprises seven parts, each focusing on a different aspect of switching within Cisco IOS
software. Each part begins with a brief technology overview and follows with the corresponding
configuration guidelines for that technology or set of features. This document contains these parts:
•
Cisco IOS Switching Paths—Provides an overview of basic routing and switching processes.
It describes switching paths available in Cisco IOS software. Configuration guidelines are provided
for configuring and managing fast switching of various protocols. Provides an overview of Cisco
Express Forwarding (CEF), the advanced Layer 3 IP switching technology that optimizes
performance and scalability in networks with large and dynamic traffic patterns. Guidelines are
provided for configuring and managing CEF.
•
NetFlow Switching—Provides an overview of the NetFlow switching technology and describes the
NetFlow accounting features. Guidelines are provided for configuring and managing NetFlow
switching.
•
Multiprotocol Label Switching (MPLS)—Provides an overview of MPLS Switching, the switching
technology that combines the performance of Layer 2 switching with the scalability of Layer 3
routing. Guidelines are provided for configuring and managing MPLS Switching.
•
Multilayer Switching—Provides an overview of Multilayer Switching (MLS). MLS provides
high-performance Layer 3 switching for the Catalyst 5000 series LAN switches working in
conjunction with Cisco routers. Guidelines are provided for configuring and managing IP MLS,
IP Multicast MLS, and IPX MLS on Cisco routers.
•
Multicast Distributed Switching—Provides an overview of Multicast Distributed Switching (MDS).
MDS performs distributed switching of multicast packets in the line cards of Route Switch
Processor (RSP)-based platforms. Guidelines are provided for configuring and managing MDS.
Cisco IOS Switching Services Configuration Guide
XC-1
Cisco IOS Switching Services Overview
Related References
•
VLANs—Provides an overview of VLANs. Guidelines are provided for configuring routing
between VLANs using the Inter-Switch Link (ISL), IEEE 802.10, and IEEE 802.1Q protocols for
packet encapsulation.
•
LAN Emulation—Provides an overview of LAN Emulation (LANE). Guidelines are provided for
defining VLANs in ATM networks and Multiprotocol over ATM (MPOA).
Related References
The references listed in this section contain background information that is helpful in designing
internetworks that incorporate switching and VLANs when planning routing between VLANs:
•
Cisco Internetwork Design Guide
This guide presents a set of general guidelines for planning internetworks and provides specific
suggestions for several key internetworking implementations. This guide focuses on design issues
of large-scale implementations for environments such as IP internetworks, Enhanced Interior
Gateway Routing Protocol (IGRP), Open Shortest Path First (OSPF), IBM System Network
Architecture (SNA) internetworks, source-route bridging (SRB), Synchronous Data Link Control
(SDLC) and serial tunneling (STUN), SDLC Logical Link, Control type 2 (SDLLC), Qualified
Logical Link Control (QLLC), ATM internetworks, packet service internetworks, Frame Relay, and
dial-on-demand routing (DDR) internetworks.
•
Cisco Catalyst 5000 Series Software Configuration Guide
This guide is designed to help you understand the Catalyst 5000 series switches, initially configure
the switch to work in your network, and customize the switch configuration to fit your needs. For an
alphabetical listing of software commands used to configure and maintain the switch, refer to the
Catalyst 5000 Series Command Reference publication.
•
CiscoWorks for Switched Internetworks—VlanDirector Getting Started Guide
This guide provides an overview of VLANs and describes how to use VlanDirector to create and
manage VLANs. VlanDirector is a management tool with a graphical user interface that provides
multiple windows for adding new users, moving users between wiring closets, changing user VLAN
associations, displaying configuration status, and providing both physical and logical views of
interconnected Catalyst switches. Network administrators responsible for initial setup and
configuration of VLANs will find this guide useful for understanding VLANs and segmenting LANs
with VLAN configurations.
Cisco IOS Switching Services Configuration Guide
XC-2
Cisco IOS Switching Paths
Cisco IOS Switching Paths Overview
This chapter describes switching paths that can be configured on Cisco IOS devices. It contains the
following sections:
•
Basic Router Platform Architecture and Processes
•
Basic Switching Paths
•
Features That Affect Performance
Basic Router Platform Architecture and Processes
To understand how switching works, it helps to first understand the basic router architecture and where
various processes occur in the router.
Fast switching is enabled by default on all interfaces that support fast switching. If you have a situation
where you need to disable fast switching and fall back to the process-switching path, understanding how
various processes affect the router and where they occur will help you determine your alternatives.
This understanding is especially helpful when you are troubleshooting traffic problems or need to
process packets that require special handling. Some diagnostic or control resources are not compatible
with fast switching or come at the expense of processing and switching efficiency. Understanding the
effects of those resources can help you minimize their effect on network performance.
Figure 2 illustrates a possible internal configuration of a Cisco 7500 series router. In this configuration,
the Cisco 7500 series router has an integrated Route Switch Processor (RSP) and uses route caching to
forward packets. The Cisco 7500 series router also uses Versatile Interface Processors (VIPs), a
RISC-based interface processor that receives and caches routing information from the RSP. The VIP card
uses the route cache to make switching decisions locally, which relieves the RSP of involvement and
speeds overall throughput. This type of switching is called distributed switching. Multiple VIP cards can
be installed in one router.
Cisco IOS Switching Services Configuration Guide
XC-4
Cisco IOS Switching Paths Overview
Basic Router Platform Architecture and Processes
Figure 2
Basic Router Architecture
Routing
processor
Switching
processor
Ethernet
Fast Ethernet
Packet
over Sonet
Frame
Relay
FDDI
ATM
S6777
Interface
processors
Cisco Routing and Switching Processes
The routing, or forwarding, function comprises two interrelated processes to move information in the
network:
•
Making a routing decision by routing
•
Moving packets to the next hop destination by switching
Cisco IOS platforms perform both routing and switching, and there are several types of each.
Routing Processes
The routing process assesses the source and destination of traffic based on knowledge of network
conditions. Routing functions identify the best path to use for moving the traffic to the destination out
one or more of the router interfaces. The routing decision is based on various criteria such as link speed,
topological distance, and protocol. Each protocol maintains its own routing information.
Routing is more processing intensive and has higher latency than switching as it determines path and
next hop considerations. The first packet routed requires a lookup in the routing table to determine the
route. The route cache is populated after the first packet is routed by the route-table lookup. Subsequent
traffic for the same destination is switched using the routing information stored in the route cache.
Cisco IOS Switching Services Configuration Guide
XC-5
Cisco IOS Switching Paths Overview
Basic Router Platform Architecture and Processes
Figure 3 illustrates the basic routing process.
Figure 3
The Routing Process
101
Router A
102
FDDI
Update
Update
Router B
Update
ATM
Router C
Update
103
Update
104
105
Token
Ring
106
S6778
Router D
A router sends routing updates out each of its interfaces that are configured for a particular protocol.
It also receives routing updates from other attached routers. From these received updates and its
knowledge of attached networks, it builds a map of the network topology.
Switching Processes
Through the switching process, the router determines the next hop toward the destination address.
Switching moves traffic from an input interface to one or more output interfaces. Switching is optimized
and has lower latency than routing because it can move packets, frames, or cells from buffer to buffer
with simpler determination of the source and destination of the traffic. It saves resources because it does
not involve extra lookups. Figure 4 illustrates the basic switching process.
Figure 4
The Switching Process
102
FDDI
Data
Data
Router B
103
104
Ethernet
Data
header
Cisco IOS Switching Services Configuration Guide
XC-6
ATM
S6779
FDDI
header
Cisco IOS Switching Paths Overview
Basic Switching Paths
In Figure 4, packets are received on the Fast Ethernet interface and destined for the FDDI interface.
Based on information in the packet header and destination information stored in the routing table,
the router determines the destination interface. It looks in the routing table of the protocol to discover
the destination interface that services the destination address of the packet.
The destination address is stored in tables such as ARP tables for IP or AARP tables for AppleTalk.
If there is no entry for the destination, the router will either drop the packet (and inform the user if the
protocol provides that feature) or discover the destination address by some other address resolution
process, such as through ARP. Layer 3 IP addressing information is mapped to the Layer 2 MAC address
for the next hop. Figure 5 illustrates the mapping that occurs to determine the next hop.
Layer 3-to-Layer 2 Mapping
Layer 3
IP address
Next hop
Wire
Layer 2 MAC address
S6839
Figure 5
Basic Switching Paths
Basic switching paths are described in the following sections:
•
Process Switching
•
Fast Switching
•
CEF Switching
•
dCEF Switching
Process Switching
In process switching the first packet is copied to the system buffer. The router looks up the Layer 3
network address in the routing table and initializes the fast-switch cache. The frame is rewritten with the
destination address and sent to the outgoing interface that services that destination. Subsequent packets
for that destination are sent by the same switching path. The route processor computes the cyclical
redundancy check (CRC).
Fast Switching
When packets are fast switched, the first packet is copied to packet memory and the destination network
or host is found in the fast-switching cache. The frame is rewritten and sent to the outgoing interface that
services the destination. Subsequent packets for the same destination use the same switching path.
The interface processor computes the CRC. Fast switching is described in the “Configuring Fast
Switching” chapter later in this publication.
Cisco IOS Switching Services Configuration Guide
XC-7
Cisco IOS Switching Paths Overview
Basic Switching Paths
CEF Switching
When CEF mode is enabled, the CEF FIB and adjacency tables reside on the RP, and the RP performs
the express forwarding. You can use CEF mode when line cards are not available for CEF switching or
when you need to use features not compatible with dCEF switching. For information on configuring
CEF, see the “Cisco Express Forwarding Overview” chapter later in this publication.
Note
Beginning with Cisco IOS Release 12.0, CEF is the preferred and default switching path. NetFlow
switching has been integrated into CEF switching. For information on NetFlow switching, see the
“Cisco Express Forwarding Overview” chapter and the “Configuring Cisco Express Forwarding”
chapter later in this publication.
dCEF Switching
In distributed switching, the switching process occurs on VIP and other interface cards that support
switching. When dCEF is enabled, line cards, such as VIP line cards or GSR line cards, maintain an
identical copy of the FIB and adjacency tables. The line cards perform the express forwarding between
port adapters, relieving the RSP of involvement in the switching operation. dCEF uses an Inter Process
Communication (IPC) mechanism to ensure synchronization of FIBs and adjacency tables on the RP and
line cards.
For model numbers and hardware compatibility information, refer to the Cisco Product Catalog.
For information on configuring dCEF, see the “Configuring Cisco Express Forwarding” chapter later in
this publication.
For information on configuring Multicast Distributed Switching (MDS), see the “Configuring Multicast
Distributed Switching” chapter later in this publication.
Figure 6 illustrates the distributed switching process on the Cisco 7500 series.
Figure 6
Distributed Switching on Cisco 7500 Series Routers
Switching types
Process switching (initialization)
Fast switching
Optimum switching
Fast switching cache
Route Switch
Processor
(RSP)
Optimum switching cache
Interface
processor
Versatile
Interface
Processor (VIP)
Interface
processor
Cisco IOS Switching Services Configuration Guide
XC-8
S6780
CyBus
Cisco IOS Switching Paths Overview
Features That Affect Performance
The VIP card installed in this router maintains a copy of the routing cache information needed to forward
packets. Because the VIP card has the routing information it needs, it performs the switching locally,
making the packet forwarding much faster. Router throughput is increased linearly based on the number
of VIP cards installed in the router.
Platform and Switching Path Correlation
Depending on the routing platform you are using, availability and default implementations of switching
paths varies. Table 3 shows the correlation between Cisco IOS switching paths and routing platforms.
Table 3
Switching Paths on Cisco 7200 and Cisco 7500 Series Routers
Switching Path
Cisco
7200
Series
Cisco
7500
Series
Process switching
Yes
Fast switching
Comments
Configuration Command
Yes
Initializes switching
caches
no protocol route-cache
Yes
Yes
Default (except for IP)
protocol route-cache
CEF switching
Yes
Yes
Default for IP
protocol route-cache cef
dCEF switching
No
Yes
Using second-generation protocol route-cache cef
VIP line cards
distributed
Features That Affect Performance
Performance is derived from the switching mechanism you are using. Some Cisco IOS features require
special handling and cannot be switched until the additional processing they require has been performed.
This special handling is not processing that the interface processors can do. Because these features
require additional processing, they affect switching performance. These features include the following:
•
Queueing
•
Random Early Detection (RED)
•
Compression
•
Filtering (using access lists)
•
Encryption
•
Accounting
For information on Quality of Service (QoS) performance, refer to the Cisco IOS Quality of Service
Solutions Configuration Guide.
Cisco IOS Switching Services Configuration Guide
XC-9
Cisco IOS Switching Paths Overview
Features That Affect Performance
Queueing
Queueing occurs when network congestion occurs. When traffic is moving well within the network,
packets are sent as they arrive at the interface. Cisco IOS software implements four different
queueing algorithms as follows:
•
FIFO queueing—Packets are forwarded in the same order in which they arrive at the interface.
•
Priority queueing (PQ)—Packets are forwarded based on an assigned priority. You can create
priority lists and groups to define rules for assigning packets to priority queues.
•
Custom queueing (CQ)—You can control a percentage of interface bandwidth for specified traffic
by creating protocol queue lists and custom queue lists.
•
Weighted fair queueing (WFQ)—WFQ provides automatic traffic priority management.
Low-bandwidth sessions have priority over high-bandwidth sessions. High-bandwidth sessions are
assigned weights. WFQ is the default for interfaces slower than 2.048 Mbps.
Random Early Detection (RED)
RED is designed for congestion avoidance. Traffic is prioritized based on type of service (ToS), or
precedence. This feature is available on T3, OC-3, and ATM interfaces.
Compression
Depending on the protocol you are using, various compression options are available in Cisco IOS
software. Refer to the Cisco IOS configuration guide for the protocol you are using to learn compression
options available.
Filtering
You can define access lists to control access to or from a router for a number of services. You could,
for example, define an access list to prevent packets with a certain IP address from leaving a particular
interface on a router. How access lists are used depends on the protocol. For information on access lists,
refer to the appropriate Cisco IOS configuration guide for the protocol you are using.
Encryption
Encryption algorithms are applied to data to alter its appearance, making it incomprehensible to those
not authorized to see the data. For information about encryption features available with the Cisco IOS
software, refer to the Cisco IOS Security Configuration Guide.
Accounting
You can configure accounting features to collect network data related to resource usage. The information
you collect (in the form of statistics) can be used for billing, chargeback, and planning resource usage.
Refer to the appropriate Cisco IOS configuration guide for the protocol you are using for information
regarding accounting features you can use.
Cisco IOS Switching Services Configuration Guide
XC-10
Configuring Fast Switching
This chapter describes how to configure fast switching on Cisco IOS devices. It provides configuration
guidelines for switching paths and tuning guidelines.
For a complete description of the commands in this chapter, refer to the the Cisco IOS Switching Services
Command Reference. To locate documentation of other commands that appear in this chapter, use the
command reference master index or search online.
To identify the hardware platform or software image information associated with a feature, use the
Feature Navigator on Cisco.com to search for information about the feature or refer to the software
release notes for a specific release. For more information, see the section “Identifying Supported
Platforms” in the chapter “Using Cisco IOS Software.”
Fast Switching Configuration Task List
Fast switching allows higher throughput by switching a packet using a cache created by the initial packet
sent to a particular destination. Destination addresses are stored in the high-speed cache to expedite
forwarding. Routers offer better packet-transfer performance when fast switching is enabled. Fast
switching is enabled by default on all interfaces that support fast switching.
To configure fast switching, perform the tasks described in the following sections:
•
Enabling AppleTalk Fast Switching
•
Enabling IP Fast Switching
•
Enabling Fast Switching on the Same IP Interface
•
Enabling Fast Switching of IPX Directed Broadcast Packets
•
Enabling SMDS Fast Switching
Fast switching is not supported for the X.25 encapsulations.
Enabling AppleTalk Fast Switching
AppleTalk access lists are automatically fast switched. Access list fast switching improves the
performance of AppleTalk traffic when access lists are defined on an interface. Refer to the “Configuring
AppleTalk” chapter in the Cisco IOS AppleTalk and Novell IPX Configuration Guide for guidelines on
creating and using access lists and configuring AppleTalk.
Cisco IOS Switching Services Configuration Guide
XC-11
Configuring Fast Switching
Fast Switching Configuration Task List
Enabling IP Fast Switching
Fast switching involves the use of a high-speed switching cache for IP routing. Destination IP addresses
are stored in the high-speed cache to expedite packet forwarding. In some cases, fast switching is
inappropriate, such as when slow-speed serial links (64K and below) are being fed from higher-speed
media such as T1 or Ethernet. In such a case, disabling fast switching can reduce the packet drop rate to
some extent. Fast switching allows outgoing packets to be load balanced on a per-destination basis.
To enable or disable fast switching, use the following commands in interface configuration mode:
Command
Purpose
Router(config-if)# ip route-cache
Enables fast switching (use of a high-speed route cache for IP routing).
Router(config-if)# no ip route-cache
Disables fast switching and enables load balancing on a per-packet basis.
Enabling Fast Switching on the Same IP Interface
You can enable IP fast switching when the input and output interfaces are the same interface.
This normally is not recommended, though it is useful when you have partially meshed media such as
Frame Relay. You could use this feature on other interfaces, although it is not recommended because it
would interfere with redirection.
Figure 7 illustrates a scenario where enabling fast switching on the same IP interface is desirable. Router
A has a data-link connection identifier (DLCI) to Router B, and Router B has a DLCI to Router C. There
is no DLCI between Routers A and C; traffic between them must go in and out of Router B through the
same interface.
IP Fast Switching on the Same Interface
Router A
Frame Relay
Network
Router C
Router B
S1527a
Figure 7
To allow IP fast switching on the same interface, use the following command in interface configuration
mode:
Command
Purpose
Router(config-if)# ip route-cache
same-interface
Enables the fast switching of packets out of the same interface on which
they arrived.
Cisco IOS Switching Services Configuration Guide
XC-12
Configuring Fast Switching
Disabling Fast Switching for Troubleshooting
Enabling Fast Switching of IPX Directed Broadcast Packets
By default, Cisco IOS software switches IPX packets that have been directed to the broadcast address.
To enable fast switching of these IPX-directed broadcast packets, use the following command in global
configuration mode:
Command
Purpose
Router(config)# ipx
broadcast-fastswitching
Enables fast switching of IPX directed broadcast packets.
Enabling SMDS Fast Switching
SMDS fast switching of IP, IPX, and AppleTalk packets provides faster packet transfer on serial links
with speeds above 56 kbps. Use fast switching if you use high-speed, packet-switched, datagram-based
WAN technologies such as Frame Relay offered by service providers.
By default, SMDS fast switching is enabled.
To reenable fast switching if it has been disabled, use the following commands in interface configuration
mode:
Command
Purpose
Step 1
Router(config-if)# interface type
number
Defines the type and unit number of the interface, and enters interface
configuration mode.
Step 2
Router(config-subif)#
encapsulation smds
Sets SMDS encapsulation.
Step 3
Router(config-if)# ip route-cache
Enables the interface for IP fast switching.
Step 4
Router(config-if)# ipx
route-cache
Enables the interface for IPX fast switching.
Step 5
Router(config-if)# appletalk
route-cache
Enables the interface for AppleTalk fast switching.
Disabling Fast Switching for Troubleshooting
Fast switching uses a cache created by previous packets to achieve a higher packet throughput. Packet
transfer performance is generally better when fast switching is enabled. Fast switching also provides
load sharing on a per-destination basis.
By default, fast switching is enabled on all interfaces that support fast switching. However, you may
want to disable fast switching to save memory space on interface cards and to help avoid congestion
when high-bandwidth interfaces are writing large amounts of information to low-bandwidth interfaces.
This is especially important when using rates slower than T1.
Fast switching is not supported on serial interfaces using encapsulations other than HDLC.
Note
Turning off fast switching increases system overhead because the packets will be process
switched by the system’s CPU.
Cisco IOS Switching Services Configuration Guide
XC-13
Configuring Fast Switching
Disabling Fast Switching for Troubleshooting
For some diagnostics, such as debugging and packet-level tracing, you will need to disable fast
switching. Disabling fast switching causes the router to fall back to process switching the packets. If fast
switching is running, you might only see the first packet to each destination in the output of any
packet-level debugging commands. Subsequent packets to the same destination will be fast switched.
Many packet level debugging commands cannot process packets that are fast switched. You might want
to turn off fast switching temporarily to use process switching instead while you are trying to capture
information to diagnose a problem.
To disable fast switching, perform the tasks described in the following sections:
•
Disabling AppleTalk Fast Switching
•
Disabling Banyan VINES Fast Switching
•
Disabling DECnet Fast Switching
•
Disabling IPX Fast Switching
•
Disabling ISO CLNS Fast Switching Through the Cache
•
Disabling XNS Fast Switching
Disabling AppleTalk Fast Switching
To disable AppleTalk fast switching on an interface, use the following command in interface
configuration mode:
Command
Purpose
Router(config-if)# no appletalk
route-cache
Disables AppleTalk fast switching.
Disabling Banyan VINES Fast Switching
Fast switching is enabled by default on all interfaces on which it is supported.
To disable fast switching on an interface, use the following command in interface configuration mode:
Command
Purpose
Router(config-if)# no vines route-cache
Disables fast switching.
Disabling DECnet Fast Switching
By default, DECnet routing software implements fast switching of DECnet packets.
To disable fast switching of DECnet packets, use the following command in interface configuration
mode:
Command
Purpose
Router(config-if)# no decnet route-cache
Disables fast switching of DECnet packets on a per-interface basis.
Cisco IOS Switching Services Configuration Guide
XC-14
Configuring Fast Switching
Controlling the Route Cache
Disabling IPX Fast Switching
To disable IPX fast switching, use the following command in interface configuration mode:
Command
Purpose
Router(config-if)# no ipx route-cache
Disables IPX fast switching.
Disabling ISO CLNS Fast Switching Through the Cache
ISO CLNS fast switching through the cache is enabled by default for all supported interfaces. To disable
fast switching, use the following command in interface configuration mode:
Command
Purpose
Router(config-if)# no clns route-cache
Disables fast switching.
Note
The cache still exists and is used after the no clns route-cache interface configuration command is
used; the software does not do fast switching through the cache.
Disabling XNS Fast Switching
To disable XNS fast switching on an interface, use the following command in interface configuration
mode:
Command
Purpose
Router(config-if)# no xns route-cache
Disables XNS fast switching.
Controlling the Route Cache
The high-speed route cache used by IP fast switching is invalidated when the IP routing table changes.
By default, the invalidation of the cache is delayed slightly to avoid excessive CPU load while the routing
table is changing. To control the route cache, perform the tasks described in the following sections:
•
Controlling Route Cache Invalidation for IP
•
Displaying System and Network Statistics
•
Adjusting the Route Cache for IPX
•
Padding Odd-Length IPX Packets
Cisco IOS Switching Services Configuration Guide
XC-15
Configuring Fast Switching
Controlling the Route Cache
Controlling Route Cache Invalidation for IP
To control route cache invalidation, use the following commands in global configuration mode as needed
for your network:
Command
Purpose
Router(config)# no ip
cache-invalidate-delay
Allows immediate invalidation of the cache.
Router(config)# ip cache-invalidate-delay
[minimum maximum quiet threshold]
Delays invalidation of the cache.
Caution
Normally, this task should not be necessary. It should be performed only under the guidance of
technical staff. Incorrect configuration can seriously degrade the performance of your router.
Displaying System and Network Statistics
You can display the contents of IP routing tables and caches. The resulting information can be used to
determine resource utilization and to solve network problems.
To display system and network statistics, use the following command in privileged EXEC mode:
Command
Purpose
Router# show ip cache [prefix mask] [type number]
Displays the routing table cache used to fast switch IP
traffic.
Adjusting the Route Cache for IPX
Adjusting the route cache allows you to control the size of the route cache, reduce memory consumption,
and improve router performance. You accomplish these tasks by controlling the route cache size and
route cache invalidation. The following sections describe these optional tasks:
•
Controlling IPX Route Cache Size (Optional)
•
Controlling IPX Route Cache Invalidation (Optional)
Controlling IPX Route Cache Size
You can limit the number of entries stored in the IPX route cache to free up router memory and aid router
processing.
Storing too many entries in the route cache can use a substantial amount of router memory, causing
router processing to slow. This situation is most common on large networks that run network
management applications for NetWare.
For example, if a network management station is responsible for managing all clients and servers in a
very large (greater than 50,000 nodes) Novell network, the routers on the local segment can become
inundated with route cache entries. You can set a maximum number of route cache entries on these
routers to free up router memory and aid router processing.
Cisco IOS Switching Services Configuration Guide
XC-16
Configuring Fast Switching
Controlling the Route Cache
To set a maximum limit on the number of entries in the IPX route cache, use the following command in
global configuration mode:
Command
Purpose
Router(config)# ipx route-cache max-size size
Sets a maximum limit on the number of entries in the IPX
route cache.
If the route cache has more entries than the specified limit, the extra entries are not deleted. However,
they may be removed if route cache invalidation is in use. See the “Controlling IPX Route Cache
Invalidation” section in this chapter for more information on invalidating route cache entries.
Controlling IPX Route Cache Invalidation
You can configure the router to invalidate inactive fast-switch cache entries. If these entries remain
invalidated for 1 minute, the router purges the entries from the route cache.
Purging invalidated entries reduces the size of the route cache, reduces memory consumption, and
improves router performance. Purging entries also helps ensure accurate route cache information.
You specify the period of time that valid fast switch cache entries must be inactive before the router
invalidates them. You can also specify the number of cache entries that the router can invalidate per
minute.
To configure the router to invalidate fast-switch cache entries that are inactive, use the following
command in global configuration mode:
Command
Purpose
Router(config)# ipx route-cache inactivity-timeout
period [rate]
Invalidates fast switch cache entries that are inactive.
When you use the ipx route-cache inactivity-timeout command with the ipx route-cache max-size
global configuration command, you can ensure a small route cache with fresh entries.
Padding Odd-Length IPX Packets
Some IPX end hosts accept only even-length Ethernet packets. If the length of a packet is odd, the packet
must be padded with an extra byte so that end host can receive it. By default, Cisco IOS software pads
odd-length Ethernet packets.
However, there are cases in certain topologies where nonpadded Ethernet packets are forwarded onto a
remote Ethernet network. Under specific conditions, you can enable padding on intermediate media as
a temporary workaround for this problem. Note that you should perform this task only under the
guidance of a customer engineer or other service representative.
Cisco IOS Switching Services Configuration Guide
XC-17
Configuring Fast Switching
Controlling the Route Cache
To enable the padding of odd-length packets, use the following commands in interface configuration
mode:
Command
Purpose
Step 1
Router(config-if)# no ipx route-cache
Disables fast switching.
Step 2
Router(config-if)# ipx
pad-process-switched-packets
Enables the padding of odd-length packets.
Cisco IOS Switching Services Configuration Guide
XC-18
Cisco Express Forwarding Overview
Cisco Express Forwarding (CEF) is advanced, Layer 3 IP switching technology. CEF optimizes network
performance and scalability for networks with large and dynamic traffic patterns, such as the Internet,
on networks characterized by intensive Web-based applications, or interactive sessions.
Procedures for configuring CEF or distributed CEF (dCEF) are provided in the “Configuring Cisco
Express Forwarding” chapter later in this publication.
This chapter describes CEF. It contains the following sections:
•
Benefits
•
Restrictions
•
CEF Components
•
Supported Media
•
CEF Operation Modes
•
TMS and CEF Nonrecursive Accounting
•
Network Services Engine
•
Virtual Profile CEF
Benefits
CEF offers the following benefits:
•
Improved performance—CEF is less CPU-intensive than fast switching route caching. More CPU
processing power can be dedicated to Layer 3 services such as quality of service (QoS) and
encryption.
•
Scalability—CEF offers full switching capacity at each line card when dCEF mode is active.
•
Resilience—CEF offers an unprecedented level of switching consistency and stability in large
dynamic networks. In dynamic networks, fast-switched cache entries are frequently invalidated due
to routing changes. These changes can cause traffic to be process switched using the routing table,
rather than fast switched using the route cache. Because the Forwarding Information Base (FIB)
lookup table contains all known routes that exist in the routing table, it eliminates route cache
maintenance and the fast-switch or process-switch forwarding scenario. CEF can switch traffic more
efficiently than typical demand caching schemes.
Cisco IOS Switching Services Configuration Guide
XC-19
Cisco Express Forwarding Overview
Restrictions
Although you can use CEF in any part of a network, it is designed for high-performance, highly resilient
Layer 3 IP backbone switching. For example, Figure 8 shows CEF being run on Cisco 12000 series
Gigabit Switch Routers (GSRs) at aggregation points at the core of a network where traffic levels are
dense and performance is critical.
Cisco Express Forwarding
CEF running
at the network
core
CEF
CEF
CEF
CEF
Peripheral
routers and
switches
S6782
Figure 8
In a typical high-capacity Internet service provider (ISP) environment, Cisco 12012 GSRs as aggregation
devices at the core of the network support links to Cisco 7500 series routers or other feeder devices. CEF
in these platforms at the network core provides the performance and scalability needed to respond to
continued growth and steadily increasing network traffic. CEF is a distributed switching mechanism that
scales linearly with the number of interface cards and the bandwidth installed in the router.
Restrictions
•
The Cisco 12000 series Gigabit Switch Routers operate only in distributed CEF mode.
•
Distributed CEF switching cannot be configured on the same VIP card as distributed fast switching.
•
Distributed CEF is not supported on Cisco 7200 series routers.
•
If you enable CEF and then create an access list that uses the log keyword, the packets that match
the access list are not CEF switched. They are fast switched. Logging disables CEF.
CEF Components
Information conventionally stored in a route cache is stored in several data structures for CEF switching.
The data structures provide optimized lookup for efficient packet forwarding. The two main components
of CEF operation are described in the following sections:
•
Forwarding Information Base
•
Adjacency Tables
Cisco IOS Switching Services Configuration Guide
XC-20
Cisco Express Forwarding Overview
CEF Components
Forwarding Information Base
CEF uses a FIB to make IP destination prefix-based switching decisions. The FIB is conceptually similar
to a routing table or information base. It maintains a mirror image of the forwarding information
contained in the IP routing table. When routing or topology changes occur in the network, the IP routing
table is updated, and those changes are reflected in the FIB. The FIB maintains next hop address
information based on the information in the IP routing table.
Because there is a one-to-one correlation between FIB entries and routing table entries, the FIB contains
all known routes and eliminates the need for route cache maintenance that is associated with switching
paths such as fast switching and optimum switching.
Adjacency Tables
Nodes in the network are said to be adjacent if they can reach each other with a single hop across a link
layer. In addition to the FIB, CEF uses adjacency tables to prepend Layer 2 addressing information.
The adjacency table maintains Layer 2 next-hop addresses for all FIB entries.
Adjacency Discovery
The adjacency table is populated as adjacencies are discovered. Each time an adjacency entry is created
(such as through ARP), a link-layer header for that adjacent node is precomputed and stored in the
adjacency table. Once a route is determined, it points to a next hop and corresponding adjacency entry.
It is subsequently used for encapsulation during CEF switching of packets.
Adjacency Resolution
A route might have several paths to a destination prefix, such as when a router is configured for
simultaneous load balancing and redundancy. For each resolved path, a pointer is added for the
adjacency corresponding to the next hop interface for that path. This mechanism is used for load
balancing across several paths.
Adjacency Types That Require Special Handling
In addition to adjacencies associated with next hop interfaces (host-route adjacencies), other types of
adjacencies are used to expedite switching when certain exception conditions exist. When the prefix is
defined, prefixes requiring exception processing are cached with one of the special adjacencies listed in
Table 4.
Table 4
Adjacency Types for Exception Processing
This adjacency type...
Receives this processing...
Null adjacency
Packets destined for a Null0 interface are dropped. This can be used as an
effective form of access filtering.
Glean adjacency
When a router is connected directly to several hosts, the FIB table on the
router maintains a prefix for the subnet rather than for the individual host
prefixes. The subnet prefix points to a glean adjacency. When packets
need to be forwarded to a specific host, the adjacency database is gleaned
for the specific prefix.
Cisco IOS Switching Services Configuration Guide
XC-21
Cisco Express Forwarding Overview
Supported Media
Table 4
Adjacency Types for Exception Processing (continued)
This adjacency type...
Receives this processing...
Punt adjacency
Features that require special handling or features that are not yet
supported in conjunction with CEF switching paths are forwarded to the
next switching layer for handling. Features that are not supported are
forwarded to the next higher switching level.
Discard adjacency
Packets are discarded.
Drop adjacency
Packets are dropped, but the prefix is checked.
Unresolved Adjacency
When a link-layer header is prepended to packets, the FIB requires the prepend to point to an adjacency
corresponding to the next hop. If an adjacency was created by the FIB and not discovered through a
mechanism, such as ARP, the Layer 2 addressing information is not known and the adjacency is
considered incomplete. Once the Layer 2 information is known, the packet is forwarded to the Route
Processor (RP), and the adjacency is determined through ARP.
Supported Media
CEF currently supports ATM/AAL5snap, ATM/AAL5mux, ATM/AAL5nlpid, Frame Relay, Ethernet,
FDDI, PPP, HDLC, and tunnels.
CEF Operation Modes
CEF can be enabled in one of two modes described in the following sections:
•
Central CEF Mode
•
Distributed CEF Mode
Cisco IOS Switching Services Configuration Guide
XC-22
Cisco Express Forwarding Overview
CEF Operation Modes
Central CEF Mode
When CEF mode is enabled, the CEF FIB and adjacency tables reside on the RP, and the RP performs
the express forwarding. You can use CEF mode when line cards are not available for CEF switching or
when you need to use features not compatible with dCEF switching.
Figure 9 shows the relationship between the routing table, FIB, and adjacency table during CEF mode.
The Catalyst switches forward traffic from workgroup LANs to a Cisco 7500 series router on the
enterprise backbone running CEF. The RP performs the express forwarding.
CEF Mode
Cisco 7500
series router
running CEF
Route Processor
Routing
table
Interface
card
E1
E2
Adjacency
table
FIB table
Interface
card
E1
Interface card
E2
E1
E2
S6783
Figure 9
Cisco
Catalyst
switches
Workgroup LAN
Workgroup LAN
Workgroup LAN
Cisco IOS Switching Services Configuration Guide
XC-23
Cisco Express Forwarding Overview
CEF Operation Modes
Distributed CEF Mode
When dCEF is enabled, line cards, such as VIP line cards or GSR line cards, maintain an identical copy
of the FIB and adjacency tables. The line cards perform the express forwarding between port adapters,
relieving the RSP of involvement in the switching operation.
dCEF uses an Inter Process Communication (IPC) mechanism to ensure synchronization of FIB tables
and adjacency tables on the RP and line cards.
Figure 10 shows the relationship between the RP and line cards when dCEF mode is active.
Figure 10
dCEF Mode
Route Processor
Routing
table
FIB table
Adjacency
table
IPC
FIB
OC-12
Adjacency
table
OC-3
Line card
FIB
FE
Cisco 7200
and 7500
series routers
Adjacency
table
Serial
Line card
FIB
T3
Adjacency
table
FDDI
S6784
Line card
Cisco 7200
and 7500
series router
GSR
In this Cisco 12000 series router, the line cards perform the switching. In other routers where you can
mix various types of cards in the same router, all of the cards you are using may not support CEF. When
a line card that does not support CEF receives a packet, the line card forwards the packet to the next
higher switching layer (the RP) or forwards the packet to the next hop for processing. This structure
allows legacy interface processors to exist in the router with newer interface processors.
Note
The Cisco 12000 series GSR operate only in dCEF mode; dCEF switching cannot be configured on
the same VIP card as distributed fast switching, and dCEF is not supported on Cisco 7200 series
routers.
Cisco IOS Switching Services Configuration Guide
XC-24
Cisco Express Forwarding Overview
TMS and CEF Nonrecursive Accounting
CEF and dCEF Additional Capabilities
In addition to configuring CEF and dCEF, you can also configure the following features:
•
Distributed CEF switching using access lists
•
Distributed CEF switching of Frame Relay packets
•
Distributed CEF switching during packet fragmentation
•
Load balancing on a per-destination-source host pair or per-packet basis
•
Distributed CEF switching across IP tunnels
For information on enabling these features, see the chapter “Configuring Cisco Express Forwarding.”
TMS and CEF Nonrecursive Accounting
Traffic matrix statistics (TMS) data is counted during packet forwarding by CEF nonrecursive
accounting. TMS enables an administrator to capture and analyze traffic data entering a backbone that
is running the Border Gateway Protocol (BGP). This feature also allows an administrator to determine
the neighbor autonomous systems of a BGP destination.
The following paragraphs explain how CEF nonrecursive accounting aggregates packet statistics for IGP
routes and their dependent BGP routes.
For example, a BGP network deployed by a service provider has the following components:
•
IGP routes that describe the next hop to which traffic should be sent.
•
BGP routes that specify an intermediate address to which traffic should be sent.
In this example, the intermediate address might be several hops away. The next hop for the BGP route
is the next hop for the intermediate address of the BGP route. The BGP route is called recursive, because
it points (through its intermediate address) to an IGP route that provides the next hop for forwarding.
CEF represents IGP routes as nonrecursive entries and BGP routes as recursive entries that resolve to
nonrecursive entries.
CEF nonrecursive accounting counts the packets for all the CEF recursive entries that resolve to a CEF
nonrecursive entry and the packets for the nonrecursive entry. The number of packets is collected and
totalled in one location.
The following example networks show how CEF nonrecursive accounting counts packets when BGP
routes resolve to one IGP route and when they do not. A multiaccess network access point (NAP) has
BGP routes referring to hosts on that network.
•
If the network is advertised as a single IGP route, all the BGP routes to the various hosts at that NAP
resolve to a single IGP route. CEF nonrecursive accounting summarizes the packets to all of the BGP
destinations.
•
If a network administrator instead advertises individual host routes from the NAP network to the
IGP, CEF nonrecursive accounting will count packets to those hosts separately.
The count of packets forwarded based on a nonrecursive CEF entry can be split into two bins based on
whether the input interface of the backbone router is configured as internal or external. Thus, all packets
that arrive on external interfaces (external to the region of interest) and are forwarded based on a given
IGP route (either directly or through a recursive BGP route) are counted together.
Cisco IOS Switching Services Configuration Guide
XC-25
Cisco Express Forwarding Overview
TMS and CEF Nonrecursive Accounting
TMS Data
The TMS feature allows an administrator to gather the following data:
•
The number of packets and bytes that travel across the backbone from internal and external sources.
The packets and bytes are called traffic matrix statistics and are useful for determining how much
traffic a backbone handles. You can analyze the traffic matrix statistics using the following methods:
– Collecting and viewing the TMS data through the application of the Network Data Analyzer
(NDA).
– Reading the TMS data that resides on the backbone router.
The following sections explain how to collect and view the traffic matrix statistics using the
command-line interface (CLI) and the NDA. For detailed instructions on using the NDA, see the
Network Data Analyzer Installation and User Guide.
•
The neighbor autonomous systems of a BGP destination. You can view the neighbor autonomous
systems of a BGP destination by reading the tmasinfo_ascii file that resides on the backbone router.
How Backbone Routers Collect TMS Data
By enabling a backbone router to gather traffic matrix statistics, you can determine the amount of traffic
that enters the backbone from sites outside of the backbone. You can also determine the amount of traffic
that is generated within the backbone. The traffic matrix statistics help you optimize and manage traffic
across the backbone.
Cisco IOS Switching Services Configuration Guide
XC-26
Cisco Express Forwarding Overview
TMS and CEF Nonrecursive Accounting
Figure 11 shows a sample backbone, represented by darkly shaded routers and bold links. The lighter
shaded and unshaded routers are outside the backbone. The traffic that travels through the backbone is
the area of interest for TMS collection.
Figure 11
Network Backbone and Routers
San Francisco POP
New York POP
ISP 1
EGBP
ISP 2
EGBP
Los Angeles POP
Atlanta POP
Legend:
Backbone router
Edge router
47160
Router
Backbone
Cisco IOS Switching Services Configuration Guide
XC-27
Cisco Express Forwarding Overview
TMS and CEF Nonrecursive Accounting
Figure 12 shows an exploded view of the backbone router that links the Los Angeles point of presence
(POP) in Figure 11 to the Atlanta POP. The bold line represents the backbone link going to the Atlanta
POP.
Figure 12
Traffic Traveling Through a Backbone Router
D
C
B
47161
A
The following types of traffic travel through the backbone router shown in Figure 12:
•
The dotted line marked A represents traffic entering the backbone from a router that is not part of
the backbone. This is called external traffic.
•
The dotted lines marked B and D represent traffic that is exiting the backbone. The router interprets
traffic from paths B and D as being generated from within the backbone. This is called internal
traffic.
•
The dotted line marked C represents traffic that is not using the backbone and is not of interest to
TMS.
You can determine the amount of traffic the backbone handles by enabling a backbone router to track the
number of packets and bytes that travel through it. You can separate the traffic into the categories
“internal” and “external.” You separate the traffic by designating incoming interfaces on the backbone
router as internal or external.
Once you enable a backbone router to collect traffic matrix statistics, it starts free running counters,
which dynamically update when network traffic passes through the backbone router. You can retrieve a
snapshot of the traffic matrix statistics, either through a command to the backbone router or through the
NDA.
External traffic (path A) is the most important for determining the amount of traffic. Internal traffic
(paths B and D) is useful for ensuring that you are capturing all the TMS data. When you receive a
snapshot of the traffic matrix statistics, the packets and bytes are displayed in internal and external
categories.
Cisco IOS Switching Services Configuration Guide
XC-28
Cisco Express Forwarding Overview
TMS and CEF Nonrecursive Accounting
Viewing the TMS Data
Once TMS data is collected, you have the following options for viewing the data:
•
Viewing the data in a graphical format, using the NDA Display module. The Display module is
useful for graphing the traffic matrix data and comparing statistics. See the section “Viewing the
TMS Data Through the NDA” for more information.
•
Entering the more system:vfiles/tmstats_ascii EXEC command on the backbone router. This
command displays a table of traffic matrix statistics. See the section “Viewing the TMS Data by
Reading the Virtual Files that Reside on the Backbone Router” for more information.
•
Entering the show ip cef EXEC command on the backbone router. This command displays
nonrecursive accounting data for the backbone router. Included in the output is the number of
packets and bytes of internal and external traffic that have been collected. See the section “Viewing
TMS Data Through the show ip cef Command” for more information.
Viewing the TMS Data Through the NDA
The Network Data Analyzer collects TMS data from the backbone router and displays it using the NDA
Display module. The TMS data can look similar to the data shown in Figure 13 and Figure 14. The
display format depends on the aggregation scheme you selected. Refer to the Network Data Analyzer
Installation and User Guide for more information.
(The NDA Display module is wide. You must slide the scroll bar to the right and left to see all of the
data. Figure 13 and Figure 14 taken together show all the columns of data.)
Figure 13
Displaying TMS Data Through the NDA (Part 1)
Cisco IOS Switching Services Configuration Guide
XC-29
Cisco Express Forwarding Overview
TMS and CEF Nonrecursive Accounting
Figure 14
Displaying TMS Data Through the NDA (Part 2)
Viewing the TMS Data by Reading the Virtual Files That Reside on the Backbone Router
You can read the TMS data that resides on the backbone router and is stored in the following virtual files:
•
tmstats_ascii—TMS data in ASCII (human readable) format.
•
tmstats_binary—TMS data in binary (space-efficient) format.
Reading the ASCII File
To view statistics in the ASCII file, enter the following command on the backbone router:
Router# more system:/vfiles/tmstats_ascii
Each file displayed consists of header information and records. A line of space follows the header and
each record. A bar (|) separates consecutive fields within a header or record. The first field in a record
specifies the type of record. The following example shows a sample TMSTATS_ASCII file:
VERSION 1|ADDR 172.27.32.24|AGGREGATION TrafficMatrix.ascii|SYSUPTIME 41428|routerUTC
3104467160|NTP unsynchronized|DURATION 1|
p|10.1.0.0/16|242|1|50|2|100
p|172.27.32.0/22|242|0|0|0|0
The following sections describe the header and the various types of records you can display.
File Header
The ASCII file header provides the address of the backbone router and information about how much time
the router used to collect and export the TMS data. The header occupies one line and uses the following
format:
VERSION 1|ADDR<address>|AGGREGATIONTrafficMatrix.ascii|SYSUPTIME<seconds>|
routerUTC<routerUTC>|NTP<synchronized|unsynchronized>|DURATION<aggregateTime>|
Cisco IOS Switching Services Configuration Guide
XC-30
Cisco Express Forwarding Overview
TMS and CEF Nonrecursive Accounting
Table 5 describes the fields in the file header of the TMSTATS_ASCII file.
Table 5
TMSTATS_ASCII File Header
Maximum Field
Length
Field
Description
10
VERSION
File format version.
21
ADDR
The IP address of the router.
32
AGGREGATION
The type of data being aggregated.
21
SYSUPTIME
The time of export (in seconds) since the router booted.
21
routerUTC
The time of export (in seconds) since 1900-01-01
(Coordinated Universal Time (UTC)), as determined by
the router.
19
NTP
Whether Coordinated Universal Time (UTC) of the router
has been synchronized by the Network Time Protocol
(NTP).
20
DURATION
The time needed to capture the data (in seconds).
Destination Prefix Record
The destination prefix record displays the internal and external packets and bytes for the IGP route and
uses the following format:
p|<destPrefix/Mask>|<creationSysUpTime>|<internalPackets>|
<internalBytes>|<externalPackets>|<externalBytes>
Table 6 describes the fields in the destination prefix record.
Table 6
Destination Prefix Record Fields
Maximum
Field Length
Field
Description
2
<recordType>
p means that the record represents dynamic label
switching data or traffic engineered (TE) tunnel traffic
data.
19
destPrefix/Mask
The IP prefix address/mask (a.b.c.d/len format) for this
IGP route.
11
creationSysUpTime
The sysUpTime when the record was first created.
21
internalPackets
Internal packet count.
21
internalBytes
Internal byte count.
21
externalPackets
External packet count.
20
externalBytes
External byte count (no trailing |).
Tunnel Midpoint Record
The tunnel midpoint record displays the internal and external packets and bytes for the tunnel head and
uses the following format:
t|<headAddr><tun_id>|<creationSysUpTime>|
<internalPackets>|<internalBytes>|<externalPackets>|<externalBytes>
Cisco IOS Switching Services Configuration Guide
XC-31
Cisco Express Forwarding Overview
TMS and CEF Nonrecursive Accounting
Table 7 describes the fields in the tunnel midpoint record.
Table 7
Tunnel Midpoint Record Fields
Maximum
Field Length
Field
Description
2
<recordType>
t means that the record represents TE tunnel midpoint
data.
27
headAddr<space>tun_id
The IP address of the tunnel head and tunnel interface
number.
11
creationSysUpTime
The sysUpTime when the record was first created.
21
internalPackets
Internal packet count.
21
internalBytes
Internal byte count.
21
externalPackets
External packet count.
20
externalBytes
External byte count (no trailing |).
Reading the Binary File
The binary file tmstats_binary contains the same information as the ASCII file, except in a
space-efficient format. You can copy this file from the router and read it with any utility that accepts files
in binary format.
Viewing TMS Data Through the show ip cef Command
You can use the show ip cef EXEC command to display nonrecursive accounting information, including
the internal and external packets and bytes that have traveled through the IP prefix address/mask
(a.b.c.d/len format) for an IGP route.
router# show ip cef 192.168.1.8
192.168.1.8/32, version 220, per-destination sharing
0 packets, 0 bytes
tag information set
local tag:17
via 192.168.67.8, FastEthernet6/0, 0 dependencies
next hop 192.168.67.8, FastEthernet6/0
valid adjacency
tag rewrite with Fa6/0, 192.168.67.8, tags imposed {}
1143 packets, 56702 bytes switched through the prefix
30 second output rate 0 Kbits/sec
tmstats:external 0 packets, 0 bytes
internal 1144 packets, 56742 bytes
Viewing the BGP Neighbor Autonomous Systems
The TMS feature also displays the BGP neighbor autonomous system (AS) associated with each IGP
destination. You can display all the neighbor autonomous systems for any IGP destination.
The tmasinfo file is in the ASCII format, which is the only one provided for this data. Enter the following
command to read the tmasinfo file:
Router# more system:/vfiles/tmasinfo
Cisco IOS Switching Services Configuration Guide
XC-32
Cisco Express Forwarding Overview
Network Services Engine
Each file consists of header information and a number of records. A line of space follows the header and
each record. A bar (|) separates consecutive fields within a header or a record.
Header Format
The file header provides the address of the router and indicates how much time the router used to collect
and export the data. The file header uses the following format:
VERSION 1|ADDR<address>|AGGREGATION ASList.ascii|SYSUPTIME<seconds>|routerUTC
<routerUTC>|DURATION<aggregateTime>|
Table 8 describes the fields in the file header.
Table 8
TMASINFO File Header
Max. Length
Field
Description
5
VERSION
File format version.
15
ADDR
The IP address of the router.
20
AGGREGATION
The type of data being aggregated.
10
SYSUPTIME
The time of export (in seconds) since router booted.
10
routerUTC
The time of export (in seconds) since 1900-01-01, as determined
by the router.
10
DURATION
The time needed to capture the data (in seconds).
Neighbor Autonomous System Record
The neighbor autonomous system record displays the neighbor autonomous system and the underlying
prefix/mask for each BGP route. The record uses the following format:
<nonrecursivePrefix/Mask>|<AS>|<destinationPrefix/Mask>
Table 9 describes the fields in the neighbor autonomous system record.
Table 9
Neighbor Autonomous System Record Fields
Maximum Field
Length
Field
Description
18
nonrecursivePrefix/Mask The IP prefix address/mask (a.b.c.d/len format) for this
IGP route.
5
AS
The neighbor autonomous system.
18
destinationPrefix/Mask
The prefix/mask for the FIB entry (typically BGP route).
Network Services Engine
The network services engine (NSE) is a processor engine for Cisco series routers. The NSE delivers wire
rate OC-3 throughput while running concurrent high-touch WAN edge services. The NSE takes
advantage of a new technology called Parallel eXpress Forwarding (PXF).
Note
Before enabling the PXF processor, you must have IP routing and IP CEF switching turned on.
Cisco IOS Switching Services Configuration Guide
XC-33
Cisco Express Forwarding Overview
Virtual Profile CEF
For information on configuring NSE, see the “Cisco Express Forwarding Overview” chapter later in this
publication.
Network Services Engine benefits and requirements are as follows:
•
Accelerated services—The following features are accelerated on the NSE: Network Address
Translation (NAT), weighted fair queueing (WFQ), and NetFlow for both enterprise and service
provider customers.
•
PXF field upgradable—PXF is based on microcode and can be upgraded with new software features
in future Cisco IOS releases.
The PXF processor enables IP parallel processing functions that work with the primary processor to
provide accelerated IP Layer 3 feature processing. The PXF processor off-loads IP packet
processing and switching functions from the RP to provide accelerated and highly consistent
switching performance when coupled with one or more of several IP services features such as access
Control Lists (ACLs), address translation, quality of service (QoS), flow accounting, and traffic
shaping.
PXF offers the advantage of hardware-based switching power, plus the flexibility of a programmable
architecture. The PXF architecture provides future-proofing—if additional features are added, an
application-specific integrated circuit (ASIC) will not be required. New features for accelerated
services can be added by reprogramming the PXF processor.
•
System requirements—An NSE-1 can be used on existing Cisco 7200 VXR series routers with
Cisco Release IOS 12.1(1)E or a later version of Cisco IOS Release 12.1 E, and with
Cisco IOS Release 12.1(5)T or a later version of Cisco IOS Release 12.1 T.
•
High performance—Network-layer services such as traffic management, security, and QoS benefit
significantly from NSE-1 high-performance. NSE-1 is the first Cisco processing engine to offer
integrated hardware acceleration, increasing Cisco 7200 VXR series system performance by 50 to
300 percent for combined “high-touch” WAN edge services.
Virtual Profile CEF
The Virtual Profile CEF feature allows you to enable asynchronous and ISDN interfaces in CEF
switching. This feature allows you to create a datagram prefix and cache it in an adjacency table for fast
reference and rewrite during the call setup. For information on configuring the Virtual Profile CEF
feature, see the “Configuring Cisco Express Forwarding” chapter later in this publication.
Cisco IOS Switching Services Configuration Guide
XC-34
Cisco Express Forwarding Overview
Virtual Profile CEF
Virtual Profile CEF benefits are as follows:
•
FIB—Virtual Profile (VP) CEF switching allows the user to use the FIB to look up a route for a
forwarding packet. Because the FIB is populated by routing topology, not by traffic, the FIB is a
performance enhancement over cache tables used in fast switching.
•
MPLS VPN/BGP integration—VP CEF switching enables VP to be used in other technologies that
require CEF switching, such as MPLS Virtual Private Network/Border Gateway Protocol
(VPN/BGP).
•
ISDN interfaces—VP CEF allows you to enable ISDN interfaces in CEF switching.
Cisco IOS Switching Services Configuration Guide
XC-35
Configuring Cisco Express Forwarding
This chapter describes the required and optional tasks for configuring Cisco Express Forwarding (CEF)
and distributed CEF (dCEF).
For a complete description of the commands in this chapter, refer to the the Cisco IOS Switching Services
Command Reference. To locate documentation of other commands that appear in this chapter, use the
command reference master index or search online.
To identify the hardware platform or software image information associated with a feature, use the
Feature Navigator on Cisco.com to search for information about the feature or refer to the software
release notes for a specific release. For more information, see the section “Identifying Supported
Platforms” in the chapter “Using Cisco IOS Software.”
Configuring CEF
To configure CEF, perform the tasks described in the following sections. The task in the first section is
required; the tasks in the remaining sections are optional.
•
Enabling CEF or dCEF (Required)
•
Configuring Load Balancing for CEF (Optional)
•
Configuring Network Accounting for CEF (Optional)
•
Configuring Distributed Tunnel Switching for CEF (Optional)
•
Configuring the Network Services Engine (Optional)
•
Configuring Virtual Profile Switching for CEF (Optional)
•
Verifying CEF (Optional)
•
Troubleshooting Tips (Optional)
For an example configuration of IP CEF non-recursive accounting, refer to the “IP CEF Nonrecursive
Accounting Example” section.
Cisco IOS Switching Services Configuration Guide
XC-36
Configuring Cisco Express Forwarding
Configuring CEF
Enabling CEF or dCEF
Enable CEF when your router has interface processors that do not support dCEF.
To enable CEF, use the following command in global configuration mode:
Command
Purpose
Router(config)# ip cef
Enables standard CEF operation.
Enable dCEF when you want your line cards to perform express forwarding so that the route processor
(RP) can handle routing protocols or switch packets from legacy interface processors.
Note
On the Cisco 12000 series Internet router, dCEF is enabled by default. The command to enable dCEF
is not available. Also, the configuration file does not indicate that dCEF is enabled on the router.
To enable or disable dCEF operation, use one of the following commands in global configuration mode
as needed:
Command
Purpose
Router(config)# ip cef distributed
Enables dCEF operation.
Router(config)# no ip cef distributed
Disables dCEF operation.
When you enable CEF or dCEF globally, all interfaces that support CEF are enabled by default. If you
want to turn off CEF or dCEF on a particular interface, you can do so.
To disable CEF or dCEF on an interface, use the following command in interface configuration mode:
Command
Purpose
Router(config-if)# no ip route-cache cef
Disables CEF operation on the interface.
When you disable CEF or dCEF, Cisco IOS software switches packets received on the interface using
the next fastest switching path. In the case of dCEF, the next fastest switching path is CEF on the RP.
If you have disabled CEF or dCEF operation on an interface and want to reenable it, you can do so by
using the ip route-cache cef command in interface configuration mode.
Note
On the Cisco 12000 series, you must not disable dCEF on an interface.
Cisco IOS Switching Services Configuration Guide
XC-37
Configuring Cisco Express Forwarding
Configuring CEF
Configuring Load Balancing for CEF
CEF load balancing is based on a combination of source and destination packet information; it allows
you to optimize resources by distributing traffic over multiple paths for transferring data to a destination.
You can configure load balancing on a per-destination or per-packet basis. Load balancing decisions are
made on the outbound interface and so load balancing must be configured on the outbound interface.
Load distortions may occur across multiple routers when the same load balancing algorithm is used on
every router. You can resolve these distortions by selecting a specific load balancing algorithm based on
your network environment.
To configure and fine-tune load balancing for CEF, perform the optional tasks described in the following
sections:
•
Configuring per-Destination Load Balancing (Optional)
•
Configuring per-Packet Load Balancing (Optional)
•
Selecting a Load Balancing Algorithm (Optional)
Configuring per-Destination Load Balancing
Per-destination load balancing is enabled by default when you enable CEF. To use per-destination load
balancing, you do not perform any additional tasks once you enable CEF.
Per-destination load balancing allows the router to use multiple paths to achieve load sharing. Packets
for a given source-destination host pair are guaranteed to take the same path, even if multiple paths are
available. Traffic destined for different pairs tend to take different paths. Per-destination load balancing
is enabled by default when you enable CEF, and is the load balancing method of choice for most
situations.
Because per-destination load balancing depends on the statistical distribution of traffic, load sharing
becomes more effective as the number of source-destination pairs increase.
You can use per-destination load balancing to ensure that packets for a given host pair arrive in order.
All packets for a certain host pair are routed over the same link (or links).
Disabling per-Destination Load Balancing
Typically, you would disable per-destination load balancing when you want to enable per-packet load
balancing.
To disable per-destination load balancing, use the following command in interface configuration mode:
Command
Purpose
Router(config-if)# no ip load-sharing
per-destination
Disables per-destination load balancing.
Cisco IOS Switching Services Configuration Guide
XC-38
Configuring Cisco Express Forwarding
Configuring CEF
Configuring per-Packet Load Balancing
Per-packet load balancing allows the router to send successive data packets over paths without regard to
individual hosts or user sessions. It uses the round-robin method to determine which path each packet
takes to the destination. Per-packet load balancing ensures balancing over multiple links.
Note
Per-packet load balancing via CEF is not supported on Engine 2 Gigabit Switch Router (GSR)
line cards (LCs).
Path utilization with per-packet load balancing is good for single path destinations, but packets for a
given source-destination host pair might take different paths. Per-packet load balancing could introduce
reordering of packets. This type of load balancing would be inappropriate for certain types of data traffic
(such as voice traffic over IP) that depend on packets arriving at the destination in sequence.
Use per-packet load balancing to help ensure that a path for a single source-destination host pair does
not get overloaded. If the bulk of the data passing through parallel links is for a single pair,
per-destination load balancing will overload a single link while other links have very little traffic.
Enabling per-packet load balancing allows you to use alternate paths to the same busy destination.
To enable per-packet load balancing, use the following command in interface configuration mode:
Command
Purpose
Router(config-if)# ip load-sharing per-packet
Enables per-packet load balancing.
Note
If you want to enable per-packet load balancing to a particular destination, all interfaces that can
forward traffic to the destination must be enabled for per-packet load balancing.
Selecting a Load Balancing Algorithm
The router is set to perform universal load sharing by default. In universal load sharing, each router on
the network can make a different load sharing decision for each source and destination address pair;
thereby, resolving load sharing distortions. For example, the tunnel algorithm is designed to balance the
per-packet load when only a few source and destination pairs are involved.
To select a load balancing algorithm, use one of the following commands in global configuration mode:
Command
Purpose
Router(config)# ip cef load-sharing algorithm
original
Sets the load sharing algorithm to the original based on a source and
destination hash.
Router(config)# ip cef load-sharing algorithm
tunnel id
Sets the load sharing algorithm for use in tunnel environments or in
environments where there are only a few IP source and destination
address pairs.
Router(config)# ip cef load-sharing algorithm
universal id
Sets the load sharing algorithm to the universal algorithm that uses a
source and destination, and ID hash.
Cisco IOS Switching Services Configuration Guide
XC-39
Configuring Cisco Express Forwarding
Configuring CEF
Configuring Network Accounting for CEF
You might want to collect statistics to better understand CEF patterns in your network. For example,
you might want to collect information such as the number of packets and bytes switched to a destination
or the number of packets switched through a destination.
To configure network accounting for CEF, perform the optional tasks described in the following sections:
•
Enabling Network Accounting for CEF (Optional)
•
Enabling a Backbone Router to Collect Traffic Matrix Statistics (TMS) Data (Optional)
•
Verifying Network Accounting Information (Optional)
Enabling Network Accounting for CEF
To collect network accounting information for CEF, use one of the following commands in global
configuration mode as needed:
Command
Purpose
Router(config)# ip cef accounting per-prefix
Enables the collection of the number of packets and bytes express
forwarded to a destination IP address (or prefix).
Router(config)# ip cef accounting
non-recursive
Enables the collection of the number of packets express forwarded
through a destination IP address.
When you enable network accounting for CEF from global configuration mode, accounting information
is collected on the RP.
When you enable network accounting for dCEF from global configuration mode, accounting information
grouped by IP prefix (recursive or nonrecursive) is not sent to the RP, but is collected on the line card.
To verify the statistics, use the show cef linecard command in privileged EXEC mode.
Enabling a Backbone Router to Collect Traffic Matrix Statistics (TMS) Data
The procedure for enabling a backbone router to collect TMS data includes enabling nonrecursive
accounting and setting the interfaces on the router to collect internal or external traffic matrix statistics.
The internal and external settings are used only for TMS collection. The interfaces are set to internal by
default.
Note
Make sure you set the incoming interfaces (not the outgoing ones) to collect internal and external
traffic.
You can perform these tasks either through the command-line interface or through the Network Data
Analyzer (NDA). The following sections explain each procedure.
Cisco IOS Switching Services Configuration Guide
XC-40
Configuring Cisco Express Forwarding
Configuring CEF
To enable a backbone router to collect TMS data and separate internal and external traffic, use the
following commands beginning in global configuration mode:
Command
Purpose
Step 1
Router(config)# ip cef
Enables CEF on the router.
Step 2
Router(config)# ip cef
accounting non-recursive
Enables nonrecursive accounting on the router.
Step 3
Router(config)# interface
type number
Specifies the interface on the backbone router that you intend to
configure.
Step 4
Router(config-if)# ip cef
accounting non-recursive
external
Sets the specified incoming interface so that it can collect traffic
entering the backbone router from external sources.
or
Router(config-if)# ip cef
accounting non-recursive
internal
Sets the specified incoming interface so that it can collect internal
traffic in the backbone router.
You can repeat Steps 3 and 4 for each incoming interface that you want to configure for TMS.
Using the NDA for TMS Data Collection
Use the NDA to enable TMS data collection and set the incoming interfaces on the backbone router to
collect internal and external traffic. For specific instructions, refer to the Network Data Analyzer
Installation and User Guide.
Enabling the NDA for TMS Data Collection
To enable TMS data collection, you must create a TMS collection and specify the following information:
•
The name of the collection
•
The router from which you want to collect TMS data
•
How often and how long to collect TMS data
The window for enabling the collection of TMS data is similar to the one shown in Figure 15.
Cisco IOS Switching Services Configuration Guide
XC-41
Configuring Cisco Express Forwarding
Configuring CEF
Figure 15
Setting the NDA Traffic Matrix Statistics Control Window
Setting Internal and External Interfaces on the Router
The NDA Traffic Matrix Statistics Control window allows you to set the interfaces on the backbone
router to collect internal and external packets and bytes as shown in Figure 16. By default, all interfaces
are set to internal. Set the internal and external interfaces and click Apply. When the NDA asks if you
want to enable CEF, click Yes.
Cisco IOS Switching Services Configuration Guide
XC-42
Configuring Cisco Express Forwarding
Configuring CEF
Figure 16
Setting the NDA Configuration Window
Verifying Network Accounting Information
To view collected accounting information, use the following command in EXEC mode:
Command
Purpose
Router# show ip cef
Displays the collected accounting information.
Configuring Distributed Tunnel Switching for CEF
CEF supports distributed tunnel switching, such as GRE tunnels. Distributed tunnel switching is enabled
automatically when you enable CEF or dCEF. You do not perform any additional tasks to enable
distributed tunnel switching once you enable CEF or dCEF.
Cisco IOS Switching Services Configuration Guide
XC-43
Configuring Cisco Express Forwarding
Configuring CEF
Configuring the Network Services Engine
The Network Services Engine (NSE) or Parallel eXpress Forwarding (PXF) processor is turned on by
default. If it is ever disabled, you must enable it to take advantage of IP packet switching and feature
acceleration.
Note
Before enabling the PXF processor, you must have IP routing and IP CEF switching turned on.
To configure the NSE, perform the tasks described in the following sections. The task in the first section
is required; the tasks in the remaining sections are optional:
•
Configuring the PXF Processor (Required)
•
Verifying the PXF Processor (Optional)
•
Troubleshooting the PXF Processor (Optional)
•
Monitoring the PXF Processor (Optional)
Configuring the PXF Processor
To enable the PXF processor, use the following command in global configuration mode:
Command
Purpose
Router(config)# [no] ip pxf
Enables PXF processing.
Verifying the PXF Processor
Enter the show pxf accounting command to view all the supported interfaces.
Router# show pxf accounting ?
ATM
Ethernet
FastEthernet
Hssi
Null
POS
Serial
summary
ATM interface
IEEE 802.3
FastEthernet IEEE 802.3
High Speed Serial Interface
Null interface
Packet over Sonet
Serial
PXF summary statistics
Cisco IOS Switching Services Configuration Guide
XC-44
Configuring Cisco Express Forwarding
Configuring CEF
Troubleshooting the PXF Processor
Use the workarounds listed in Table 10 if you encounter an error message.
Table 10
PXF Error Messages
Error Message
Workaround
WARNING:PXF Exception:mac_xid=0x10000
*** IHB watchdog timer expired
6d16h:%PXF-2-EXCEPTION:pxf exception on
pxf tmc.
Enter the show pxf crash EXEC command to obtain
more information.
PXF processor hang and error message:
WARNING:PXF Exception:mac_xid=0x8
*** External Memory Column 3 exception,
type = 20
This error message indicates that the PXF processor
has been left in HALT state. During bootup, the PXF
processor is in error state and cannot be brought up. To
work around this problem, reload the router.
PXF processor crash and error message:
00:49:37:Fatal pxf interrupt,
int_reg=0x80, int_mask=0xFFFF, config=0x1FF4000
00:49:37:-Traceback= 6055B9CC 60530D10
This message indicates that the PXF processor
encountered a serious error and crashed. To work
around this problem, reload the router.
Monitoring the PXF Processor
To monitor PXF processors, use the following commands in privileged EXEC mode:
Command
Purpose
Router# show pxf accounting
Displays PXF switching statistics for all interfaces.
Router# show pxf accounting ethernet
Displays PXF switching statistics for Ethernet interfaces.
Router# show pxf accounting null
Displays PXF switching statistics for NULL interfaces.
Router# show pxf accounting pos
Displays PXF switching statistics for packet OC-3 interfaces.
Router# show pxf accounting serial
Displays PXF switching statistics for serial interfaces.
Router# show pxf accounting summary
Displays a summary of PXF switching statistics.
Router# show pxf crash
Displays PXF crash information.
Router# show pxf feature cef
Displays PXF routing feature tables for CEF.
Router# show pxf feature nat
Displays PXF routing tables for NAT.
Router# show pxf interface
Displays a summary of the interfaces in the router and the PXF features and
capabilities that are enabled on these interfaces.
Cisco IOS Switching Services Configuration Guide
XC-45
Configuring Cisco Express Forwarding
Configuring CEF
Configuring Virtual Profile Switching for CEF
CEF supports virtual profile switching. Virtual profile switching is enabled automatically when you
enable CEF. You do not perform any additional tasks to enable virtual profile switching once you enable
CEF.
Verifying Virtual Profile Interfaces
To monitor and maintain virtual profile interfaces, use the following commands in privileged EXEC
mode as needed:
Command
Purpose
Router# show adjacency detail
Displays CEF adjacency table information.
Router# show ip cef
Displays entries in the FIB that are unresolved or
displays a summary of the FIB.
Router# show ip interfaces virtual-access number
Displays network-layer IP information about a
specified virtual access interface.
Verifying CEF
To verify CEF-related information, use the following commands in privileged EXEC mode:
Command
Purpose
Router# show cef
Displays which packets the line cards dropped or displays which packets were
not express forwarded.
Router# show cef interface
Displays CEF-related interface information.
Router# show cef linecard
Displays CEF-related interface information by line card.
Router# show ip cef adjacency
Displays CEF recursive and direct prefixes resolved through an adjacency.
Router# show ip cef events
Displays all recorded CEF FIB and adjacency events.
Router# show ip cef exact-route
Displays the exact route for a source-destination IP address pair.
Router# show ip cef traffic
prefix-length
Displays CEF traffic statistics.
Cisco IOS Switching Services Configuration Guide
XC-46
Configuring Cisco Express Forwarding
Configuring CEF
Troubleshooting Tips
CEF uses routing information that is retrieved from the Routing Information Base (RIB), Route
Processor (RP), and the line card (LC) databases to perform express forwarding. As updates occur to
these databases, inconsistencies may result due to the asynchronous nature of the distribution
mechanism for these databases.
If you find a database inconsistency, such as an IP prefix missing from a line card or an RP; you can
investigate and resolve these instances by referencing the CEF system error messages that occur and by
issuing CEF debug and show commands.
For CEF consistency checker system error messages, refer to the System Error Messages for 12.2T in the
“New Features in Release 12.2T” area of Cisco.com.
Enabling CEF Consistency Checkers
To enable CEF consistency checkers, use the following command in global configuration mode:
Command
Purpose
Router(config)# ip cef table
consistency-check
Enables CEF table consistency checker types and parameters.
You can enable the following CEF consistency checker types:
•
Lc-detect — Active line card checker to detect missing prefixes.
•
Scan-lc — Passive scan checker of tables on a line card.
•
Scan-rib — Passive scan checker of tables on an RP against the RIB.
•
Scan-rp — Passive scan checker of tables on an RP.
Displaying CEF Table Inconsistencies
To display CEF table inconsistency records found by the lc-detect, scan-rp, scan-rib, and scan-lc
detection mechanisms, use the following command in privileged EXEC mode:
Command
Purpose
Router# show ip cef inconsistency
Displays CEF IP prefix inconsistencies.
Clearing CEF Table Inconsistencies
To clear CEF table inconsistencies, use the following commands in privileged EXEC mode:
Command
Purpose
Router# clear ip cef inconsistency
Clears CEF inconsistency statistics and records found by the CEF consistency
checkers.
Router# clear cef linecard
Clears CEF information from linecards.
Cisco IOS Switching Services Configuration Guide
XC-47
Configuring Cisco Express Forwarding
IP CEF Nonrecursive Accounting Example
IP CEF Nonrecursive Accounting Example
The following example shows how to enable routers to collect internal and external packets and bytes
that travel through the backbone routers. Figure 17 shows the sample backbone configuration.
Sample Backbone Configuration
47162
Figure 17
Router A
e1/0
(external)
Router B
e1/1
e1/0
(external)
(internal)
Router C
e1/1
e1/0
(internal)
(external)
Router D
e1/1
(external)
Router A Configuration
Router(config)# ip cef
Router(config)# ip cef accounting non-recursive
Router(config)# interface e1/0
Router(config-if)# ip cef accounting non-recursive external
Router B Configuration: e1/1
Router(config)# ip cef
Router(config)# ip cef accounting non-recursive
Router(config)# interface e1/1
Router(config-if)# ip cef accounting non-recursive external
Router B Configuration: e1/0
Router(config)# interface e1/0
Router(config-if)# ip cef accounting non-recursive internal
Router C Configuration: e1/1:
Router(config)# ip cef
Router(config)# ip cef accounting non-recursive
Router(config)# interface e1/1
Router(config-if)# ip cef accounting non-recursive internal
Router C Configuration: e1/0
Router(config)# interface e1/0
Router(config-if)# ip cef accounting non-recursive external
Router D Configuration
Router(config)# ip cef
Router(config)# ip cef accounting non-recursive
Router(config)# interface e1/1
Router(config-if)# ip cef accounting non-recursive external
Cisco IOS Switching Services Configuration Guide
XC-48
NetFlow Switching
NetFlow Overview
Release 12.2
April 30, 2001
NetFlow provides network administrators with access to call detail recording information from their data
networks. Exported NetFlow data can be used for a variety of purposes, including network management
and planning, enterprise accounting and departmental chargebacks, ISP billing, data warehousing, and
data mining for marketing purposes. NetFlow also provides a highly efficient mechanism with which to
process security access lists without paying as much of a performance penalty as is incurred with other
available switching methods.
Procedures for configuring NetFlow are provided in the “Configuring NetFlow” chapter later in this
publication.
This chapter describes NetFlow. It contains the following sections:
•
Accounting Statistics
•
NetFlow Data Format
•
NetFlow Aggregation
•
NetFlow Policy Routing
Accounting Statistics
NetFlow is a technology that captures as part of its switching function a rich set of traffic statistics. These
traffic statistics include user, protocol, port, and type of service (ToS) information that can be used for
a wide variety of purposes such as network analysis and planning, accounting, and billing.
NetFlow is supported on IP and IP encapsulated traffic over all interface types and encapsulations except
for ISL/VLAN, ATM, and Frame Relay interfaces when more than one input Access Control List is used
on the interface, and ATM LANE.
Capturing Traffic Data
In conventional switching at the network layer, each incoming packet is handled on an individual basis
with a series of functions to perform access list checks, capture accounting data, and switch the packet.
With NetFlow, after a flow has been identified and access list processing of the first packet in the flow
has been performed, all subsequent packets are handled on a connection-oriented basis as part of the
flow, where access list checks are bypassed, and packet switching and statistics capture are performed
in tandem.
Cisco IOS Switching Services Configuration Guide
XC-50
NetFlow Overview
NetFlow Data Format
A network flow is identified as a unidirectional stream of packets between a given source and
destination—both defined by a network-layer IP address and transport-layer port number. Specifically,
a flow is identified as the combination of the following fields:
•
Source IP address
•
Destination IP address
•
Source port number
•
Destination port number
•
Protocol type
•
Type of service
•
Input interface
NetFlow Cache
NetFlow operates by creating a flow cache that contains the information needed to switch and perform
access list checking for all active flows. The NetFlow cache is built by processing the first packet of a
flow through the standard switching path. As a result, each flow is associated with an incoming and
outgoing interface port number and with a specific security access permission and encryption policy.
The cache also includes entries for traffic statistics that are updated in tandem with the switching of
subsequent packets. After the NetFlow cache is created, packets identified as belonging to an existing
flow can be switched based on the cached information and security access list checks bypassed.
Flow information is maintained within the NetFlow cache for all active flows.
NetFlow Data Format
NetFlow exports flow information in UDP datagrams in one of two formats. The version 1 format was
the initially released version, and version 5 is a later enhancement to add Border Gateway Protocol
(BGP) autonomous system (AS) information and flow sequence numbers. Versions 2 through 4 were not
released.
In version 1 and version 5 formats, the datagram consists of a header and one or more flow records.
The first field of the header contain the version number of the export datagram. Typically, a receiving
application that accepts either format allocates a buffer large enough for the largest possible datagram
from either format and uses the version from the header to determine how to interpret the datagram.
The second field in the header is the number of records in the datagram and should be used to index
through the records.
All fields in either version 1 or version 5 formats are in network byte order. Table 11 and Table 12
describe the data format for version 1, and Table 13 and Table 14 describe the data format for version 5.
We recommend that receiving applications check datagrams to ensure that the datagrams are from a valid
NetFlow source. We recommend that you first check the size of the datagram to make sure it is at least
long enough to contain the version and count fields. Next we recommend that you verify that the version
is valid (1 or 5) and that the number of received bytes is enough for the header and count flow records
(using the appropriate version).
Cisco IOS Switching Services Configuration Guide
XC-51
NetFlow Overview
NetFlow Data Format
Because NetFlow export uses UDP to send export datagrams, it is possible for datagrams to be lost.
To determine whether or flow export information is lost, the version 5 header format contains a flow
sequence number. The sequence number is equal to the sequence number of the previous datagram plus
the number of flows in the previous datagram. After receiving a new datagram, the receiving application
can subtract the expected sequence number from the sequence number in the header to get the number
of missed flows.
Table 11 lists the bytes for the version 1 header format.
Table 11
Version 1 Header Format
Bytes
Content
Description
0 to 3
version and count
Netflow export format version number and number of flows
exported in this packet (1 to 24).
4 to 7
SysUptime
Current time (in milliseconds) since router booted.
8 to 11
unix_secs
Current seconds since 0000 UTC 1970.
12 to 15
unix_nsecs
Residual nanoseconds since 0000 UTC 1970.
Table 12 lists the byte definitions for version 1 flow record format.
Table 12
Version 1 Flow Record Format
Bytes
Content
Description
0 to 3
srcaddr
Source IP address.
4 to 7
dstaddr
Destination IP address.
8 to 11
nexthop
IP address of the next hop router.
12 to 15
input and output
SNMP index of the input and output interface.
16 to 19
dPkts
Packets in the flow.
20 to 23
dOctets
Total number of Layer 3 bytes in the flow’s packets.
24 to 27
First
SysUptime at start of flow.
28 to 31
Last
SysUptime at the time the last packet of flow was received.
32 to 35
srcport and dstport
TCP/UDP source and destination port number or equivalent.
36 to 39
pad1, prot, and tos
Unused (zero) byte, IP protocol (for example, 6 = TCP,
17 = UDP), and IP ToS.
40 to 43
flags, pad2, and pad3 Cumulative OR of TCP flags. Pad 2 and pad 3 are unused
(zero) bytes.
44 to 47
reserved
Cisco IOS Switching Services Configuration Guide
XC-52
Unused (zero) bytes.
NetFlow Overview
NetFlow Data Format
Table 13 lists the byte definitions for the version 5 header format.
Table 13
Version 5 Header Format
Bytes
Content
Description
0 to 3
version and count
Netflow export format version number and number of flows
exported in this packet (1 to 30).
4 to 7
SysUptime
Current time (in milliseconds) since the router booted
8 to 11
unix_secs
Current seconds since 0000 UTC 1970.
12 to 15
unix_nsecs
Residual nanoseconds since 0000 UTC 1970.
16 to 19
flow_sequence
Sequence counter of total flows seen.
20 to 23
reserved
Unused (zero) bytes.
Table 14 lists the byte definitions for the version 5 flow record format.
Table 14
Version 5 Flow Record Format
Bytes
Content
Description
0 to 3
srcaddr
Source IP address.
4 to 7
dstaddr
Destination IP address.
8 to 11
nexthop
IP address of the next hop router.
12 to 15
input and output
SNMP index of the input and output interface.
16 to 19
dPkts
Packets in the flow.
20 to 23
dOctets
Total number of Layer 3 bytes in the flow’s packets.
24 to 27
First
SysUptime at start of flow.
28 to 31
Last
SysUptime at the time the last packet of flow was received.
32 to 35
srcport and dstport
TCP/UDP source and destination port number or equivalent.
36 to 39
pad1, tcp_flags, prot, Unused (zero) byte, Cumulative OR of TCP flags, IP protocol
and tos
(for example, 6 = TCP, 17 = UDP), and IP ToS.
40 to 43
src_as and dst_as
Autonomous system of the source and destination, either
origin or peer.
44 to 47
src_mask, dst_mask,
and pad2
Source and destination address prefix mask bits. Pad 2 is
unused (zero) bytes.
Cisco IOS Switching Services Configuration Guide
XC-53
NetFlow Overview
NetFlow Aggregation
NetFlow Aggregation
By maintaining one or more extra flow caches, called aggregation caches, the NetFlow Aggregation
feature allows limited aggregation of NetFlow data export streams on a router.
Note
To collect NetFlow version 8 data export records, use NetFlow FlowCollector version 3.0.
Version 2.0 and earlier versions do not support version 8 data export record formats.
Benefits
The NetFlow Aggregation feature provides the following benefits:
•
Reduced bandwidth requirement—NetFlow aggregation caches reduce the bandwidth required
between routers and NetFlow management workstations.
•
Reduced NetFlow workstation requirements—NetFlow aggregation caches reduce the number of
NetFlow management workstations required.
•
Improved router scalability—NetFlow aggregation caches improve the scalability of
high-flow-per-second routers, such as the Cisco 7500 series.
Aggregation Cache Schemes
The aggregation cache schemes are described in the following sections:
•
Autonomous System Aggregation Scheme
•
Destination Prefix Aggregation Scheme
•
Prefix Aggregation Scheme
•
Protocol Port Aggregation Scheme
•
Source Prefix Aggregation Scheme
•
Aggregation Scheme Fields and Key Fields
You can configure each aggregation cache with its individual cache size, cache ager timeout parameter,
export destination IP address, and export destination UDP port. As data flows expire in the main
NetFlow cache, the flows are added to each enabled aggregation cache. Each aggregation cache contains
different field combinations that determine which data flows are grouped. The default aggregation cache
size is 4096.
Table 15 lists definitions for the data export record terms used in each aggregation scheme.
Table 15
Data Export Record Terms and Definitions
Term
Definition
Bytes
Number of bytes in the aggregated flows.
Destination BGP autonomous system Peer or origin autonomous system of the destination prefix (IP
address.)
Destination interface
SNMP index of the output interface.
Destination port
Destination UDP or TCP port number.
Cisco IOS Switching Services Configuration Guide
XC-54
NetFlow Overview
NetFlow Aggregation
Table 15
Data Export Record Terms and Definitions (continued)
Term
Definition
Destination prefix
Destination IP address ANDed with the destination prefix
mask.
First
System uptime when the first packet was switched.
Flows
Number of main cache flows that were aggregated.
Last
System uptime when the last packet was switched.
Packets
Number of packets in the aggregated flows.
PAD
Zero field.
Protocol
IP protocol byte.
Source BGP autonomous system
Peer or origin autonomous system of the source prefix.
Source interface
SNMP index of the input interface.
Source port
Source UDP or TCP port number if applicable.
Source prefix
Source IP address ANDed with the source prefix mask, or the
prefix that the source IP address of the aggregated flows belong
to.
Cisco IOS Switching Services Configuration Guide
XC-55
NetFlow Overview
NetFlow Aggregation
Autonomous System Aggregation Scheme
The Autonomous System aggregation scheme provides substantial NetFlow export data volume
reduction and generates autonomous system-to-autonomous system traffic flow data. The scheme groups
data flows with the same source BGP autonomous system, destination BGP autonomous system, input
interface, and output interface. See Figure 18.
The aggregated NetFlow data export records report the following:
•
Source and destination BGP autonomous system
•
Number of packets summarized by the aggregated record
•
Number of flows summarized by the aggregated record
•
Number of bytes summarized by the aggregated record
•
Output and input interfaces
•
Time stamp when the first packet is switched and time stamp when the last packet is switched
Autonomous System Aggregation Data Export Format
0
0
Flows
4
4
Packets
8
8
Bytes
12 12
First time stamp
16 16
Last time stamp
20 20
Source AS
Destination AS
24 24
Source interface
Destination interface
Cisco IOS Switching Services Configuration Guide
XC-56
26462
Figure 18
NetFlow Overview
NetFlow Aggregation
Destination Prefix Aggregation Scheme
The Destination Prefix aggregation scheme generates data so that you can examine the destinations of
network traffic passing through a NetFlow-enabled device. The scheme groups data flows with the same
destination prefix, destination prefix mask, destination BGP autonomous system, and output interface.
See Figure 19.
The aggregated NetFlow data export records report the following:
•
Destination prefix
•
Destination prefix mask
•
Destination BGP autonomous system
•
Number of flows summarized by the aggregated record
•
Number of bytes summarized by the aggregated record
•
Number of packets summarized by the aggregated record
•
Output interface
•
Time stamp when the first packet is switched and time stamp when the last packet is switched
Destination Prefix Aggregation Data Export Record Format
0
0
Flows
4
4
Packets
8
8
Bytes
12
12
First time stamp
16
16
Last time stamp
20
20
Destination prefix
24
24
28
Destination mask
bits
PAD
Destination interface
Destination AS
Reserved
463
Figure 19
Cisco IOS Switching Services Configuration Guide
XC-57
NetFlow Overview
NetFlow Aggregation
Prefix Aggregation Scheme
The Prefix aggregation scheme generates data so that you can examine the sources and destinations of
network traffic passing through a NetFlow-enabled device. The scheme groups data flows with the same
source prefix, destination prefix, source prefix mask, destination prefix mask, source BGP autonomous
system, destination BGP autonomous system, input interface, and output interface. See Figure 20.
The aggregated NetFlow data export records report the following:
•
Source and destination prefix
•
Source and destination prefix mask
•
Source and destination BGP autonomous system
•
Number of flows summarized by the aggregated record
•
Number of bytes summarized by the aggregated record
•
Number of packets summarized by the aggregated record
•
Input and output interface
•
Time stamp when the first packet is switched and time stamp when the last packet is switched
Prefix Aggregation Data Export Record Format
0
0
Flows
4
4
Packets
8
8
Bytes
12 12
First time stamp
16 16
Last time stamp
20 20
Source prefix
24 24
Destination prefix
28 28
Destination mask
bits
Source mask
bits
32 32
Source AS
Destination AS
36 36
Source interface
Destination interface
Cisco IOS Switching Services Configuration Guide
XC-58
Reserved
26464
Figure 20
NetFlow Overview
NetFlow Aggregation
Protocol Port Aggregation Scheme
The Protocol Port aggregation scheme generates data so that you can examine network usage by traffic
type. The scheme groups data flows with the same IP protocol, source port number, and destination port
number when applicable. See Figure 21.
The aggregated NetFlow data export records report the following:
•
Source and destination port numbers
•
IP protocol (where 6 = TCP, 17 = UDP, and so on)
•
Number of flows summarized by the aggregated record
•
Number of bytes summarized by the aggregated record
•
Number of packets summarized by the aggregated record
•
Time stamp when the first packet is switched and time stamp when the last packet is switched
Protocol Port Aggregation Data Export Record Format
0
0
Flows
4
4
Packets
8
8
Bytes
12 12
First time stamp
16 16
Last time stamp
20 20
24 24
Protocol
PAD
Source port
Reserved
Destination port
26465
Figure 21
Cisco IOS Switching Services Configuration Guide
XC-59
NetFlow Overview
NetFlow Aggregation
Source Prefix Aggregation Scheme
The Source Prefix aggregation scheme generates data so that you can examine the sources of network
traffic passing through a NetFlow-enabled device. The scheme groups data flows with the same source
prefix, source prefix mask, source BGP autonomous system, and input interface. See Figure 22.
The aggregated NetFlow data export records report the following:
•
Source prefix
•
Source prefix mask
•
Source BGP autonomous system
•
Number of bytes summarized by the aggregated record
•
Number of packets summarized by the aggregated record
•
Input interface
•
Time stamp when the first packet is switched and time stamp when the last packet is switched
Source Prefix Aggregation Data Export Record Format
0
0
Flows
4
4
Packets
8
8
Bytes
12
12
First time stamp
16
16
Last time stamp
20
20
Source prefix
24
24
28
28
Source mask
bits
Source interface
Cisco IOS Switching Services Configuration Guide
XC-60
PAD
Source AS
Reserved
26466
Figure 22
NetFlow Overview
NetFlow Aggregation
Aggregation Scheme Fields and Key Fields
To coordinate flow aggregation on your router, determine the fields from which you want to collect data.
Table 16 shows which fields are valid for the different aggregation schemes and which fields are part of
the keys. Key fields define a unique flow.
Table 16
Aggregation Scheme Data Fields
Data Fields
Aggregation Schemes
Autonomous
System
Destination
Prefix
Prefix
Protocol
Port
Source Prefix
Source Prefix
Destination Prefix
Protocol
*
Type of Service Byte
Source Port
*
Destination Port
*
Source Interface
*
Destination Interface
*
*
*
*
*
OR’d TCP Flags
Source BGP
Autonomous System
*
Destination BGP
Autonomous System
*
*
*
Source Prefix Mask
*
*
*
Destination Prefix Mask
*
*
*
Next Hop IP Adress
Source Encap Bytes
Destination Encap Bytes
Source Prefix
*
Destination Prefix
*
*
*
First Timestamp
x
x
x
x
x
Last Timestamp
x
x
x
x
x
Flows
x
x
x
x
x
Packets
x
x
x
x
x
Bytes
x
x
x
x
x
* = exported key field
x = exported field
Cisco IOS Switching Services Configuration Guide
XC-61
NetFlow Overview
NetFlow Aggregation
New Version 8 NetFlow Data Export Support
NetFlow exports flow information in UDP datagrams in one of several formats. Version 8, a new data
export version, has been added to support data exports from aggregation caches. Version 8 allows for
export datagrams to contain a subset of the usual version 5 export data, which is valid for a particular
aggregation scheme type.
Figure 23 shows the version 8 header with the version and time stamp information. Table 17 lists
definitions for terms used in the version 8 header.
Version 8 Header Format
0
Version
Count
4
System uptime
8
UNIX seconds
12
UNIX nanoseconds
16
Sequence number
20
Engine type
Engine ID
24
Table 17
Aggregation
Aggregation
version
Reserved
26467
Figure 23
Terms and Definitions for Version 8 Headers
Term
Definition
Version
The flow export format version number. In this case, the number is “8.”
Count
The number of export records in the datagram.
System uptime
The number of milliseconds since the router was last booted.
UNIX seconds
The number of seconds since 0000 UTC 1970.
UNIX nanoseconds
The number of residual nanoseconds since 0000UTC 1970.
Sequence number
Sequence counter of total flows sent for this export stream.
Engine type
The type of switching engine. RP = 0 and LC = 1.
Engine ID
The slot number of the NetFlow engine.
Aggregation
The type of aggregation scheme being used.
Aggregation version
The aggregation subformat version number. The current value is “2.”
Setting a NetFlow Minimum Mask
The NetFlow Minimum Prefix Mask for Router Based Aggregation feature allows the user to set a
minimum mask size. The IP address that is added to the aggregation cache is ANDed with the maximum
of the two masks: user-entered mask and the routing table mask.
Cisco IOS Switching Services Configuration Guide
XC-62
NetFlow Overview
NetFlow Policy Routing
To enable this feature for a particular aggregation cache, configure the desired minimum mask value
using the NetFlow aggregation cache commands. The minimum mask value used by the router selects
the granularity of the NetFlow data that will be collected as follows:
•
For coarse NetFlow collection granularity, select a low minimum mask value.
•
For fine NetFlow collection granularity, select a high minimum mask value.
The mask values range from 1 to 32.
Note
Setting a NetFlow minimum mask size is not available in Autonomous System aggregation and
Protocol Port aggregation.
NetFlow Policy Routing
NetFlow policy routing (NPR) integrates policy routing, which enables traffic engineering and traffic
classification, with NetFlow services, which provide billing, capacity planning, and monitoring
information on real-time traffic flows. IP policy routing now works with Cisco Express Forwarding
(CEF), Distributed CEF (dCEF), and NetFlow.
As quality of service (QoS) and traffic engineering become more popular, so does interest in the ability
of policy routing to selectively set IP precedence and type of service (TOS) bits (based on access lists
and packet size), thereby routing packets based on predefined policy. It is important that policy routing
work well in large, dynamic routing environments. Hence, distributed support allows you to leverage
your investment in distributed architecture.
Cisco IOS introduced three technologies for IP Policy Routing. See Table 18.
Table 18
Three Technologies for IP Policy Routing
Technology
Description
CEF
Looks at a Forwarding Information Base (FIB) table instead of a routing table when
switching packets.
dCEF
Addresses the scalability and maintenance problems of a demand caching scheme.
NetFlow
A Cisco IOS software accounting tool for network planning, accounting, billing and
security.
NPR leverages these technologies. To configure NetFlow policy routing, see the chapter “Configuring
NetFlow” in this publication.
Benefits
NetFlow policy routing provides the following benefits:
•
NPR takes advantage of the new switching services. CEF, dCEF, and NetFlow can now use policy
routing.
•
Now that policy routing is integrated into CEF, policy routing can be deployed on a wide scale and
on high-speed interfaces.
Cisco IOS Switching Services Configuration Guide
XC-63
NetFlow Overview
NetFlow Policy Routing
Restrictions
NetFlow policy routing has the following restrictions:
•
NPR is only available on Cisco IOS CEF-based platforms.
•
Distributed FIB-based policy routing is only available on platforms that support dCEF and images
that support dCEF.
•
dCEF—The set ip next-hop verify-availability route-map configuration command is not supported
in dCEF because dCEF does not support the Cisco Discovery Protocol (CDP) database.
Cisco IOS Switching Services Configuration Guide
XC-64
Configuring NetFlow
This chapter describes how to configure NetFlow data accounting on your routing devices.
For a complete description of the commands in this chapter, refer to the the Cisco IOS Switching Services
Command Reference. To locate documentation of other commands that appear in this chapter, use the
command reference master index or search online.
To identify the hardware platform or software image information associated with a feature, use the
Feature Navigator on Cisco.com to search for information about the feature or refer to the software
release notes for a specific release. For more information, see the section “Finding Support Information
for Platforms and Cisco IOS Software Images” in the chapter “Using Cisco IOS Software.”
What is NetFlow?
NetFlow enables you to collect traffic flow statistics on your routing devices. NetFlow is based on
identifying packet flows for ingress IP packets. It does not involve any connection-setup protocol either
between routers or to any other networking device or end station and does not require any change
externally—either to the traffic or packets themselves or to any other networking device. NetFlow is
completely transparent to the existing network, including end stations and application software and
network devices like LAN switches. Also, NetFlow is performed independently on each internetworking
device, it need not be operational on each router in the network. Using NetFlow Data Export (NDE), you
can export data to a remote workstation for data collection and further processing. Network planners can
selectively invoke NDE on a router or on a per-subinterface basis to gain traffic performance, control, or
accounting benefits in specific network locations.
Cisco IOS Switching Services Configuration Guide
XC-65
Configuring NetFlow
NetFlow Configuration Task List
Note
NetFlow does consume additional memory and CPU resources; therefore, it is important to
understand the resources required on your router before enabling NetFlow.
NetFlow Configuration Task List
To configure NetFlow, perform the tasks described in the following sections. The task in the first section
is required; the remaining tasks are optional.
•
Enabling NetFlow (Required)
•
Exporting NetFlow Statistics (Optional)
•
Customizing the Number of Entries in the NetFlow Cache (Optional)
•
Managing NetFlow Statistics (Optional)
•
Configuring IP Distributed and NetFlow on VIP Interfaces (Optional)
•
Configuring an Aggregation Cache (Optional)
•
Configuring a NetFlow Minimum Prefix Mask for Router-Based Aggregation (Optional)
•
Configuring NetFlow Policy Routing (Optional)
Enabling NetFlow
To enable NetFlow, first configure the router for IP routing as described in the IP configuration chapters
in the Cisco IOS IP Configuration Guide, Volume 2 of 3: Routing Protocols. After you configure IP
routing, use the following commands beginning in global configuration mode:
Step 1
Command
Purpose
Router(config)# interface type
slot/port-adapter/port (Cisco 7500 series
routers)
Specifies the interface, and enter interface configuration
mode.
or
Router(config)# interface type slot/port
(Cisco 7200 series routers)
Step 2
Router(config-if)# ip route-cache flow
Cisco IOS Switching Services Configuration Guide
XC-66
Enables NetFlow for IP routing.
Configuring NetFlow
NetFlow Configuration Task List
Exporting NetFlow Statistics
NetFlow information can also be exported to network management applications. To configure the router
to export NetFlow statistics maintained in the NetFlow cache to a workstation when a flow expires, use
either of the following commands in global configuration mode:
Command
Purpose
Router(config)# ip flow-export ip-address udp-port
[version 1]
Configures the router to export NetFlow cache entries to a
workstation if you are using receiving software that requires
version 1. Version 1 is the default.
Router(config)# ip flow-export ip-address udp-port
version 5 [origin-as | peer-as]
Configures the router to export NetFlow cache entries to a
workstation if you are using receiving software that accepts
version 5. Optionally specify the origin or peer autonomous
system. The default is to export neither AS that provides
improved performance.
Caution
Entering the ip flow-export or no ip flow-export
command on the Cisco 12000 Series Internet
Routers and specifying any version format other
than version 1 (in other words, entering the ip
flow-export or no ip flow-export command and
specifying either the version 5 or version 9
keyword) causes packet forwarding to stop for a
few seconds while NetFlow reloads the route
processor and line card CEF tables. To avoid
interruption of service to a live network, apply this
command during a change window, or include it in
the startup-config file to be executed during a
router reboot.
Customizing the Number of Entries in the NetFlow Cache
Normally the size of the NetFlow cache will meet your needs. However, you can increase or decrease
the number of entries maintained in the cache to meet the needs of your NetFlow traffic rates. The default
is 64K flow cache entries. Each cache entry requires about 64 bytes of storage. Assuming a cache with
the default number of entries, about 4 MB of DRAM would be required. Each time a new flow is taken
from the free flow queue, the number of free flows is checked. If only a few free flows remain, NetFlow
attempts to age 30 flows using an accelerated timeout. If only one free flow remains, NetFlow
automatically ages 30 flows regardless of their age. The intent is to ensure that free flow entries are
always available.
To customize the number of entries in the NetFlow cache, use the following command in global
configuration mode:
Command
Purpose
Router(config)# ip flow-cache entries number
Changes the number of entries maintained in the NetFlow
cache. The number of entries can be from 1024 to 524288.
The default is 65536.
Cisco IOS Switching Services Configuration Guide
XC-67
Configuring NetFlow
NetFlow Configuration Task List
Caution
We recommend that you not change the NetFlow cache entries. Improper use of this feature could
cause network problems. To return to the default NetFlow cache entries, use the no ip flow-cache
entries global configuration command.
Managing NetFlow Statistics
You can display and clear NetFlow statistics. NetFlow statistics consist of IP packet size distribution, IP
flow cache information, and flow information such as the protocol, total flow, flows per second, and so
on. The resulting information can be used to determine information about your router traffic. To manage
NetFlow statistics, use the following commands in privileged EXEC mode as needed:
Command
Purpose
Router# show ip cache flow
Displays the NetFlow statistics.
Router# clear ip flow stats
Clears the NetFlow statistics.
Configuring IP Distributed and NetFlow on VIP Interfaces
On Cisco 7500 series routers with a Route Switch Processor (RSP) and with Versatile Interface
Processor (VIP) controllers, the VIP hardware can be configured to switch packets received by the VIP
with no per-packet intervention on the part of the RSP. This process is called distributed switching.
Distributed switching decreases the demand on the RSP.
The VIP hardware can also be configured for NetFlow, a high-performance feature that caches
information about the flow. NetFlow data can also be exported to network management applications.
Refer to the Cisco Product Catalog for information about VIP port adapters used for distributed
switching.
To configure distributed switching on the VIP, first configure the router for IP routing as described in
this chapter and the various routing protocol chapters, depending on the protocols you use. After you
configure IP routing, use the following commands beginning in global configuration mode:
Command
Purpose
Step 1
Router(config)# interface type
slot/port-adapter/port
Specifies the interface, and enters interface configuration
mode.
Step 2
Router(config-if)# ip route-cache distributed
Enables VIP distributed switching of IP packets on the
interface.
Step 3
Router(config-if)# ip route-cache flow
Enables NetFlow.
Cisco IOS Switching Services Configuration Guide
XC-68
Configuring NetFlow
NetFlow Configuration Task List
To export NetFlow cache entries to a workstation when a flow expires, use the following command in
global configuration mode:
Command
Purpose
Router(config)# ip flow-export ip-address udp-port
Configures the router to export NetFlow cache entries to a
workstation.
Configuring an Aggregation Cache
To configure an aggregation cache, you must enter aggregation cache configuration mode, and you must
decide which type of aggregation scheme you would like to configure: Autonomous System, Destination
Prefix, Prefix, Protocol Prefix, or Source Prefix aggregation cache. Once you define the aggregation
scheme, define the operational parameters for that scheme:
Command
Purpose
Step 1
Router(config)# ip flow-aggregation cache as
Enters aggregation cache configuration mode and enables an
aggregation cache scheme (as, destination-prefix, prefix,
protocol-port, or source-prefix).
Step 2
Router(config-flow-cache)# cache entries 2046
Specifies the number (in this example, 2046) of cache entries
to allocate for the Autonomous System aggregation cache.
Step 3
Router(config-flow-cache)# cache timeout
inactive 199
Specifies the number of seconds (in this example, 199) that
an inactive entry is allowed to remain in the aggregation
cache before it is deleted.
Step 4
Router(config-flow-cache)# cache timeout
active 45
Specifies the number of minutes (in this example, 45) that an
active entry is active.
Step 5
Router(config-flow-cache)# export destination
10.42.41.1 9991
Enables the data export.
Step 6
Router(config-flow-cache)# enabled
Enables aggregation cache creation.
Verifying Aggregation Cache Configuration and Data Export
To verify the aggregation cache information, use the following command in EXEC mode:
Command
Purpose
Router# show ip cache flow aggregation
Displays the aggregation cache information.
To confirm data export, use the following command in EXEC mode:
Command
Purpose
Router# show ip flow export
Displays the statistics for the data export including the main cache and
all other enabled caches.
Configuring a NetFlow Minimum Prefix Mask for Router-Based Aggregation
Cisco IOS Switching Services Configuration Guide
XC-69
Configuring NetFlow
NetFlow Configuration Task List
To configure NetFlow Minimum Prefix Mask for Router-Based Aggregation feature, perform the tasks
described in the following sections. Each task is optional.
•
Configuring the Minimum Mask of a Prefix Aggregation Scheme (Optional)
•
Configuring the Minimum Mask of a Destination-Prefix Aggregation Scheme (Optional)
•
Configuring the Minimum Mask of a Source-Prefix Aggregation Scheme (Optional)
Per form the following section to verify your NetFlow aggregation configuration:
•
Monitoring and Maintaining Minimum Masks for Aggregation Schemes (Optional)
Configuring the Minimum Mask of a Prefix Aggregation Scheme
To configure the minimum mask of a prefix aggregation scheme, use the following commands beginning
in aggregation cache configuration mode:
Command
Purpose
Step 1
Router(config)# ip flow-aggregation cache prefix
Configures the prefix aggregation cache.
Step 2
Router(config-flow-cache)# mask source minimum value
Specifies the minimum value for the source
mask.
Step 3
Router(config-flow-cache)# mask destination minimum value
Specifies minimum value for the
destination mask.
Configuring the Minimum Mask of a Destination-Prefix Aggregation Scheme
To configure the minimum mask of a destination-prefix aggregation scheme, use the following
commands beginning in aggregation cache configuration mode:
Command
Purpose
Step 1
Router(config)# ip flow-aggregation cache destination-prefix
Configures the destination aggregation
cache.
Step 2
Router(config-flow-cache)# mask destination minimum value
Specifies the minimum value for the
destination mask.
Configuring the Minimum Mask of a Source-Prefix Aggregation Scheme
To configure the minimum mask of a source-prefix aggregation scheme, use the following commands
beginning in aggregation cache configuration mode:
Command
Purpose
Step 1
Router(config)# ip flow-aggregation cache source-prefix
Configures the source-prefix aggregation
cache.
Step 2
Router(config-flow-cache)# mask source minimum value
Specifies the minimum value for the source
mask.
Cisco IOS Switching Services Configuration Guide
XC-70
Configuring NetFlow
NetFlow Configuration Task List
Monitoring and Maintaining Minimum Masks for Aggregation Schemes
To view the configured value of the minimum mask, use the following commands for each aggregation
scheme in EXEC mode, as needed:
Command
Purpose
Router# show ip cache flow aggregation prefix
Displays the configured value of the
minimum mask in the prefix aggregation
scheme.
Router# show ip cache flow aggregation destination-prefix
Displays the configured value of the
minimum mask in the destination-prefix
aggregation scheme.
Router# show ip cache flow aggregation source-prefix
Displays the configured value of the
minimum mask in the source-prefix
aggregation scheme.
Note
If the minimum mask has not been explicitly configured, no minimum mask information is displayed.
The default value of the minimum mask is zero. The configurable range for the minimum mask is
from 1 to 32. An appropriate value should be chosen by the user depending on the traffic. A higher
value of the minimum mask will provide more detailed network addresses, but it may also result in
increased number of flows in the aggregation cache.
Configuring NetFlow Policy Routing
As long as policy routing is configured, NetFlow policy routing (NPR) is enabled by default and cannot
be disabled. That is, NPR is the default policy routing mode. No configuration tasks are required to
enable policy routing in conjunction with CEF or dCEF. As soon as one of these features is turned on,
packets are automatically subject to policy routing in the appropriate switching path.
There is one optional configuration command (set ip next-hop verify-availability route-map
configuration command). This command has the following restrictions:
•
It can cause some performance degradation.
•
CDP must be configured on the interface.
•
The direct next hop must be a Cisco device with CDP enabled.
•
It is not available in dCEF due to the dependency of the CDP neighbor database.
It is assumed that policy routing itself is already configured.
If the router is policy routing packets to the next hop and the next hop happens to be down, the router
will try unsuccessfully to use Address Resolution Protocol (ARP) for the next hop (which is down). This
behavior will continue forever.
To prevent this situation, you can configure the router to first verify that the next hops of the route map
are CDP neighbors of the router before routing to that next hop.
Cisco IOS Switching Services Configuration Guide
XC-71
Configuring NetFlow
NetFlow Configuration Examples
This task is optional because some media or encapsulations do not support CDP, or it may not be a Cisco
device that is sending the router traffic.
To configure the router to verify that the next hop is a CDP neighbor before the router tries to policy
route to it, use the following command in route-map configuration mode:
Command
Purpose
Router(config-route-map)# set ip next-hop
verify-availability
Causes the router to confirm that the next hops of the route map are
CDP neighbors of the router.
If the command shown is set and the next hop is not a CDP neighbor, the router looks to the subsequent
next hop, if there is one. If there is none, the packets simply are not policy routed.
If the command shown is not set, the packets are either successfully policy routed or remain forever
unrouted.
If you want to selectively verify availability of only some next hops, you can configure different
route-map entries (under the same route-map name) with different criteria (using access list matching or
packet size matching), and use the set ip next-hop verify-availability route-map configuration
command selectively.
Monitoring NetFlow Policy Routing
Typically, you would use existing policy routing and NetFlow show EXEC commands to monitor these
features. For more information on these show commands, refer to the policy routing and NetFlow
documentation.
To display the route map Inter Processor Communication (IPC) message statistics in the RP or VIP, use
the following command in EXEC mode:
Command
Purpose
Router# show route-map ipc
Displays the route map IPC message statistics in the RP or VIP.
NetFlow Configuration Examples
This section provides the following basic configuration examples:
•
NetFlow Configuration Example
•
NetFlow Aggregation Configuration Examples
•
Setting a NetFlow Minimum Prefix Mask for Router-Based Aggregation Examples
NetFlow Configuration Example
The following example shows how to modify the configuration of serial interface 3/0/0 to enable
NetFlow and to export the flow statistics for further processing to UDP port 0 on a workstation with the
IP address of 1.1.15.1. In this example, existing NetFlow statistics are cleared to ensure accurate
information when the show ip cache flow command in privileged EXEC mode is entered to view a
summary of the NetFlow statistics.
Cisco IOS Switching Services Configuration Guide
XC-72
Configuring NetFlow
NetFlow Configuration Examples
configure terminal
interface serial 3/0/0
ip route-cache flow
exit
ip flow-export 1.1.15.1 0 version 5 peer-as
exit
clear ip flow stats
The following is a sample display of a main cache using the show ip cache flow command:
Router# show ip cache flow
IP packet size distribution (230151 total packets):
1-32
64
96 128 160 192 224 256 288 320 352 384 416 448 480
.999 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
The preceding output shows the percentage distribution of packets by size range. In this display, 99.9
percent of the packets fall in the size range from 1 to 32 bytes.
IP Flow Switching Cache, 4456448 bytes
65509 active, 27 inactive, 820628747 added
955454490 ager polls, 0 flow alloc failures
Exporting flows to 1.1.15.1 (2057)
820563238 flows exported in 34485239 udp datagrams, 0 failed
last clearing of statistics 00:00:03
Protocol
-------TCP-BGP
UDP-other
ICMP
Total:
SrcIf
Port Msk
Et1/1
0000 /8
Et1/2
0000 /8
Et1/2
0000 /0
Et1/2
0000 /0
Et1/2
0000 /0
Et1/2
0000 /0
Et1/2
0000 /0
Et1/2
0000 /0
Et1/2
0000 /0
Et1/2
0000 /0
Et1/2
0000 /0
Et1/2
0000 /0
Et1/2
Total
Flows
71
17
18966
19054
Flows
/Sec
0.0
0.0
6.7
6.7
SrcIPaddress
AS
52.52.52.1
50
52.52.52.1
50
10.1.3.2
0
11.1.3.2
0
14.1.3.2
0
15.1.3.2
0
12.1.3.2
0
13.1.3.2
0
18.1.3.2
0
19.1.3.2
0
16.1.3.2
0
17.1.3.2
0
22.1.3.2
Packets Bytes
/Flow /Pkt
1
49
1
328
10
28
10
28
DstIf
Port Msk
Fd4/0
0000 /8
Fd4/0
0000 /8
Fd4/0
0000 /8
Fd4/0
0000 /8
Fd4/0
0000 /8
Fd4/0
0000 /8
Fd4/0
0000 /8
Fd4/0
0000 /8
Fd4/0
0000 /8
Fd4/0
0000 /8
Fd4/0
0000 /8
Fd4/0
0000 /8
Fd4/0
AS
40
40
40
40
40
40
40
40
40
40
40
40
Packets Active(Sec) Idle(Sec)
/Sec
/Flow
/Flow
0.0
2.5
15.8
0.0
0.0
15.7
72.9
0.1
22.9
72.9
0.1
22.9
DstIPaddress
NextHop
42.42.42.1
202.120.130.2
42.42.42.1
202.120.130.2
42.42.42.1
202.120.130.2
42.42.42.1
202.120.130.2
42.42.42.1
202.120.130.2
42.42.42.1
202.120.130.2
42.42.42.1
202.120.130.2
42.42.42.1
202.120.130.2
42.42.42.1
202.120.130.2
42.42.42.1
202.120.130.2
42.42.42.1
202.120.130.2
42.42.42.1
202.120.130.2
42.42.42.1
Pr TOS Flgs Pkts
B/Pk Active
01 55 10
3748
28
17.8
01 CC 10
3568
28
17.8
01 C0 10
1124
28
17.8
01 C0 10
1157
28
17.7
01 C0 10
1149
28
17.8
01 C0 10
1127
28
17.7
01 C0 10
1204
28
17.8
01 C0 10
1159
28
17.8
01 C0 10
1223
28
17.8
01 C0 10
1264
28
17.8
01 C0 10
1170
28
17.8
01 C0 10
1167
28
17.8
01 C0 10
1193
Cisco IOS Switching Services Configuration Guide
XC-73
Configuring NetFlow
NetFlow Configuration Examples
0000 /0
Et1/2
0000 /0
Et1/1
00B3 /32
Et1/0
0000 /8
Note
0
23.1.3.2
0
50.50.50.1
0
8.8.8.8
302
0000 /8
Fd4/0
0000 /8
Local
2AF8 /32
Et0/0*
0800 /8
40
40
0
300
202.120.130.2
42.42.42.1
202.120.130.2
31.31.31.1
0.0.0.0
9.9.9.9
3.3.3.3
28
10
28
06 C0 18
49
01 00 10
100
01 C0
17.8
1212
17.7
2
10.1
3
0.1
The very last entry in the “DstIf” field has an asterisk (*) next to the destination interface. The asterisk
(*) immediately following the “DstIf” field indicates that the flow being shown is an egress flow.
Table 19 describes the significant fields shown in the flow switching cache lines of the display.
Table 19
show ip cache flow Field Descriptions in Flow Switching Cache Display
Field
Description
bytes
Number of bytes of memory used by the NetFlow cache.
active
Number of active flows in the NetFlow cache at the time this command was
entered.
inactive
Number of flow buffers that are allocated in the NetFlow cache, but were
not currently assigned to a specific flow at the time this command was
entered.
added
Number of flows created since the start of the summary period.
ager polls
Number of times the NetFlow code looked at the cache to cause entries to
expire (used by Cisco for diagnostics only).
flow alloc failures
Number of times the NetFlow code tried to allocate a flow but could not.
Exporting flows
IP address and User Datagram Protocol (UDP) port number of the
workstation to which flows are exported.
flows exported in udp
datagrams
Total number of flows exported and the total number of UDP datagrams
used to export the flows to the workstation.
failed
Number of flows that could not be exported by the router because of output
interface limitations.
last clearing of statistics Standard time output (hh:mm:ss) since the clear ip flow stats privileged
EXEC command was executed. This time output changes to hours and days
after the time exceeds 24 hours.
Table 20 describes the significant fields shown in the activity by protocol lines of the display.
Table 20
show ip cache flow Field Descriptions in Activity by Protocol Display
Field
Description
Protocol
IP protocol and the well-known port number as described in RFC 1340.
Total Flows
Number of flows for this protocol since the last time statistics were cleared.
Flows/Sec
Average number of flows for this protocol seen per second; equal to total
flows/number of seconds for this summary period.
Cisco IOS Switching Services Configuration Guide
XC-74
Configuring NetFlow
NetFlow Configuration Examples
Table 20
show ip cache flow Field Descriptions in Activity by Protocol Display (continued)
Field
Description
Packets/Flow
Average number of packets observed for the flows seen for this protocol. Equal to
total packets for this protocol or number of flows for this protocol for this
summary period.
Bytes/Pkt
Average number of bytes observed for the packets seen for this protocol (total
bytes for this protocol or total number of packet for this protocol for this summary
period).
Packets/Sec
Average number of packets for this protocol per second (total packets for this
protocol) or total number of seconds for this summary period.
Active(Sec)/Flow Sum of all the seconds from the first packet to the last packet of an expired flow
(for example, TCP FIN, timeout, and so on), in seconds or total flows for this
protocol for this summary period.
Idle(Sec)/Flow
Sum of all the seconds from the last packet seen in each nonexpired flow for this
protocol until the time at which this command was entered, in seconds or total
flows for this protocol for this summary period.
Table 21 describes the significant fields in the NetFlow record lines of the display.
Table 21
show ip cache verbose flow Field Descriptions in NetFlow Record Display
Field
Description
SrcIf
Interface on which the packet was received.
Port Msk AS
Source Border Gateway Protocol (BGP) autonomous system. This is always
set to 0 in MPLS flows.
SrcIPaddress
IP address of the device that transmitted the packet.
DstIf
Interface from which the packet was transmitted.
The DstIf interface can be reported as “Null” if the packets are any of
the following:
Note
•
Blocked by an ACL
•
Process-switched
•
Multicast traffic
•
Locally-generated traffic
•
Tunnels (IPIP, GRE, IPSEC, L2TP)
•
Web Cache Communication Protocol (WCCP)
•
Using a static route to a Null0 interface
•
Dropped by Quality of Service (QoS) rules (for example, Committed
Access Rate or Policing)
The following rules apply to QoS traffic:
Port Msk AS
•
The DstIf information is correct if the traffic is not dropped by QoS
•
The DstIf will be reported as “Null” when the traffic is dropped due to QoS
rules.
Destination BGP autonomous system. This is always set to 0 in MPLS flows.
Cisco IOS Switching Services Configuration Guide
XC-75
Configuring NetFlow
NetFlow Configuration Examples
Table 21
show ip cache verbose flow Field Descriptions in NetFlow Record Display (continued)
Field
Description
DstIPaddress
IP address of the destination device.
NextHop
Specifies the BGP next-hop address. This is always set to 0 in MPLS flows.
Pr
IP protocol well-known port number as described in RFC 1340, displayed in
hexadecimal format.
B/Pk
Average number of bytes observed for the packets seen for this protocol (total
bytes for this protocol or the total number of flows for this protocol for this
summary period).
Flgs
TCP flags (result of bitwise OR of TCP flags from all packets in the flow).
Active
Number of active flows in the NetFlow cache at the time this command was
entered.
Pkts
Number of packets switched through this flow.
NetFlow Aggregation Configuration Examples
This section provides the following aggregation cache configuration examples:
•
Autonomous System Configuration Example
•
Destination Prefix Configuration Example
•
Prefix Configuration Example
•
Protocol Port Configuration Example
•
Source Prefix Configuration Example
Autonomous System Configuration Example
The following example shows how to configure an Autonomous System aggregation cache with a cache
size of 2046, an inactive timeout of 200 seconds, a cache active timeout of 45 minutes, an export
destination IP address of 10.42.42.1, and a destination port of 9992:
Router(config)# ip flow-aggregation cache as
Router(config-flow-cache)# cache entries 2046
Router(config-flow-cache)# cache timeout inactive 200
Router(config-flow-cache)# cache timeout active 45
Router(config-flow-cache)# export destination 10.42.42.1 9992
Router(config-flow-cache)# enabled
Destination Prefix Configuration Example
The following example shows how to configure a Destination Prefix aggregation cache with a cache size
of 2046, an inactive timeout of 200 seconds, a cache active timeout of 45 minutes, an export destination
IP address of 10.42.42.1, and a destination port of 9992:
Router(config)# ip flow-aggregation cache destination-prefix
Router(config-flow-cache)# cache entries 2046
Router(config-flow-cache)# cache timeout inactive 200
Router(config-flow-cache)# cache timeout active 45
Router(config-flow-cache)# export destination 10.42.42.1 9992
Router(config-flow-cache)# enabled
Cisco IOS Switching Services Configuration Guide
XC-76
Configuring NetFlow
NetFlow Configuration Examples
Prefix Configuration Example
The following example shows how to configure a Prefix aggregation cache with a cache size of 2046, an
inactive timeout of 200 seconds, a cache active timeout of 45 minutes, an export destination IP address
of 10.42.42.1, and a destination port of 9992:
Router(config)# ip flow-aggregation cache prefix
Router(config-flow-cache)# cache entries 2046
Router(config-flow-cache)# cache timeout inactive 200
Router(config-flow-cache)# cache timeout active 45
Router(config-flow-cache)# export destination 10.42.42.1 9992
Router(config-flow-cache)# enabled
Protocol Port Configuration Example
The following example shows how to configure a Protocol Port aggregation cache with a cache size of
2046, an inactive timeout of 200 seconds, a cache active timeout of 45 minutes, an export destination IP
address of 10.42.42.1, and a destination port of 9992:
Router(config)# ip flow-aggregation cache protocol-port
Router(config-flow-cache)# cache entries 2046
Router(config-flow-cache)# cache timeout inactive 200
Router(config-flow-cache)# cache timeout active 45
Router(config-flow-cache)# export destination 10.42.42.1 9992
Router(config-flow-cache)# enabled
Source Prefix Configuration Example
The following example shows how to configure a Source Prefix aggregation cache with a cache size of
2046, an inactive timeout of 200 seconds, a cache active timeout of 45 minutes, an export destination IP
address of 10.42.42.1, and a destination port of 9992:
Router(config)# ip flow-aggregation cache source-prefix
Router(config-flow-cache)# cache entries 2046
Router(config-flow-cache)# cache timeout inactive 200
Router(config-flow-cache)# cache timeout active 45
Router(config-flow-cache)# export destination 10.42.42.1 9992
Router(config-flow-cache)# enabled
Setting a NetFlow Minimum Prefix Mask for Router-Based Aggregation
Examples
This section provides the following NetFlow minimum prefix mask aggregation cache configuration
examples:
•
Prefix Aggregation Scheme Example
•
Destination-Prefix Aggregation Scheme Example
•
Source-Prefix Aggregation Scheme Example
Prefix Aggregation Scheme Example
!
ip flow-aggregation cache prefix
mask source minimum 24
Cisco IOS Switching Services Configuration Guide
XC-77
Configuring NetFlow
NetFlow Configuration Examples
mask destination minimum 28
Destination-Prefix Aggregation Scheme Example
!
ip flow-aggregation cache destination-prefix
mask destination minimum 32
!
Source-Prefix Aggregation Scheme Example
ip flow-aggregation cache source-prefix
mask source minimum 30
!
NetFlow Policy Routing Example
The following example configures CEF and NetFlow. It also configures policy routing to verify that next
hop 50.0.0.8 of route map named test is a CDP neighbor before the router tries to policy route to it.
If the first packet is being policy routed via route map test sequence 10, the subsequent packets of the
same flow always take the same route map test sequence 10, not route map test sequence 20, because
they all match or pass access list 1 check.
ip cef
interface ethernet0/0/1
ip route-cache flow
ip policy route-map test
route-map test permit 10
match ip address 1
set ip precedence priority
set ip next-hop 50.0.0.8
set ip next-hop verify-availability
route-map test permit 20
match ip address 101
set interface Ethernet0/0/3
set ip tos max-throughput
Cisco IOS Switching Services Configuration Guide
XC-78
Multiprotocol Label Switching
Multiprotocol Label Switching Overview
This chapter describes the Multiprotocol Label Switching (MPLS) distribution protocol. MPLS is a
high-performance packet forwarding technology that integrates the performance and traffic management
capabilities of data link layer (Layer 2) switching with the scalability, flexibility, and performance of
network-layer (Layer 3) routing. It enables service providers to meet challenges brought about by
explosive growth and provides the opportunity for differentiated services without necessitating the
sacrifice of existing infrastructure.
The MPLS architecture is remarkable for its flexibility:
•
Data can be transferred over any combination of Layer 2 technologies
•
Support is offered for all Layer 3 protocols
•
Scaling is possible well beyond anything offered in today’s networks.
Specifically, MPLS can efficiently enable the delivery of IP services over an ATM switched network.
It supports the creation of different routes between a source and a destination on a purely router-based
Internet backbone. Service providers who use MPLS can save money and increase revenue and
productivity.
Procedures for configuring MPLS are provided in the “Configuring Multiprotocol Label Switching”
chapter later in this publication.
Note
Label switching on a router requires that Cisco Express Forwarding (CEF) be enabled on that router.
Refer to the CEF feature documentation for configuration information. For more information on
enabling CEF, see the “Configuring Cisco Express Forwarding” chapter in this publication.
This chapter describes MPLS. It contains the following sections:
•
MPLS/Tag Switching Terminology
•
MPLS Commands and Saved Configurations
•
MPLS/Tag Switching CLI Command Summary
•
Benefits
•
Label Switching Functions
•
Distribution of Label Bindings
•
MPLS and Routing
•
MPLS Traffic Engineering
•
MPLS Virtual Private Networks
Cisco IOS Switching Services Configuration Guide
XC-80
Multiprotocol Label Switching Overview
MPLS/Tag Switching Terminology
•
MPLS Quality of Service
•
MPLS Label Switch Controller
•
MPLS Egress NetFlow Accounting
MPLS/Tag Switching Terminology
Beginning with Cisco IOS Release 12.1, the Tag Switching distribution protocol has been replaced with
the MPLS distribution protocol. MPLS supports the following:
•
Tag Switching features
•
Tag Switching command-line interface (CLI) commands
Table 22 lists tag switching terms (found in earlier releases of this document) and the equivalent MPLS
terms used in this document.
Table 22
Equivalency Table for Tag Switching and MPLS Terms
Old Tag Switching Terminology
New MPLS Terminology
Tag Switching
Multiprotocol Label Switching (MPLS)
Tag (short for Tag Switching)
MPLS
Tag (item or packet)
Label
TDP (Tag Distribution Protocol)
LDP (Label Distribution Protocol)
Cisco TDP and LDP (MPLS Label Distribution Protocol) are
nearly identical in function, but use incompatible message
formats and some different procedures. Cisco is changing
from TDP to a fully compliant LDP.
Tag Switched
Label Switched
TFIB (Tag Forwarding Information
Base)
LFIB (Label Forwarding Information Base)
TSR (Tag Switching Router)
LSR (Label Switching Router)
TSC (Tag Switch Controller)
LSC (Label Switch Controller)
ATM-TSR (ATM Tag Switch Router)
ATM-LSR (ATM Label Switch Router, such as the
Cisco BPX 8650 switch)
TVC (Tag VC, Tag Virtual Circuit)
LVC (Label VC, Label Virtual Circuit)
TSP (Tag Switch Path)
LSP (Label Switch Path)
XTag ATM (extended Tag ATM port)
XmplsATM (extended MPLS ATM port)
MPLS Commands and Saved Configurations
During the transition period from tag switching to MPLS, if a configuration command has both MPLS
and tag switching forms, the tag switching version is written to saved configurations. For example, you
can configure MPLS hop-by-hop forwarding for a router POS interface by issuing the following
commands:
Router# configure terminal
Router(config)# interface POS3/0
Cisco IOS Switching Services Configuration Guide
XC-81
Multiprotocol Label Switching Overview
MPLS/Tag Switching CLI Command Summary
Router(config-if)# mpls ip
In this example, the mpls ip command has a tag switching form (tag-switching ip). After you enter these
commands and save this configuration or display the running configuration by means of the show
running configuration command, the configuration commands appear as follows:
interface POS3/0
tag-switching ip
Saving the tag switching form of commands (that have both tag switching and MPLS forms) allows for
backward compatibility. You can use a new router software image to modify and write configurations,
and then later use configurations created by the new image with earlier software versions that do not
support the MPLS forms of commands
Using the tag switching forms of the commands allows older software that supports tag switching
commands, but not new MPLS commands, to successfully interpret interface configurations.
MPLS/Tag Switching CLI Command Summary
Table 23 summarizes general-purpose MPLS commands. Except where otherwise noted, these MPLS
commands have been derived from existing tag-switching commands to preserve the familiar syntax of
existing commands that formed the basis for implementing new MPLS functionality.
Table 23
Summary of MPLS Commands Described in this Document
Corresponding Tag Switching
Command
Command
Description
debug mpls adjacency
debug tag-switching adjacency Displays changes to label switching entries in the
adjacency database.
debug mpls events
debug tag-switching events
Displays information about significant MPLS events.
debug mpls lfib cef
debug tag-switching tfib cef
Prints detailed information about label rewrites being
created, resolved, and deactivated as CEF routes are
added, changed, or removed.
debug mpls lfib enc
debug tag-switching tfib enc
Prints detailed information about label encapsulations
while label rewrites are created or updated and placed
into the label forwarding information base (LFIB).
debug mpls lfib lsp
debug tag-switching tfib tsp
Prints detailed information about label rewrites being
created and deleted as TSP tunnels are added or
removed.
debug mpls lfib state
debug tag-switching tfib state
Traces what happens when label switching is enabled
or disabled.
debug mpls lfib struct
debug tag-switching tfib struct Traces the allocation and freeing of LFIB-related data
structures, such as the LFIB itself, label-rewrites, and
label-info data.
debug mpls packets
debug tag-switching packets
Displays labeled packets switched by the host router.
interface atm
interface atm
Enters interface configuration mode, specifies ATM as
the interface type, and enables the creation of a
subinterface on the ATM interface.
Cisco IOS Switching Services Configuration Guide
XC-82
Multiprotocol Label Switching Overview
Benefits
Table 23
Summary of MPLS Commands Described in this Document (continued)
Command
Corresponding Tag Switching
Command
mpls atm control-vc
tag-switching atm control-vc
Configures the VPI and VCI to be used for the initial
link to the label switching peer device.
mpls atm vpi
tag-switching atm vpi
Configures the range of values to be used in the VPI
field for label VCs.
mpls ip (global configuration)
tag-switching ip (global
configuration)
Enables MPLS forwarding of IPv4 packets along
normally routed paths for the platform.
mpls ip (interface
configuration)
tag-switching ip (interface
configuration)
Enables MPLS forwarding of IPv4 packets along
normally routed paths for a particular interface.
mpls ip default-route
tag-switching ip default-route
Enables the distribution of labels associated with the IP
default route.
mpls ip propagate-ttl
tag-switching ip propagate-ttl
Sets the time-to-live (TTL) value when an IP packet is
encapsulated in MPLS.
mpls ip ttl-expiration pop
N/A
Forwards packets using the global IP routing table or
the original label stack, depending on the number of
labels in the packet.
mpls label range
tag-switching tag-range
downstream
Configures the range of local labels available for use
on packet interfaces.
Description
Note
The syntax of this command differs slightly
from its tag-switching counterpart.
mpls mtu
tag-switching mtu
Sets the per-interface maximum transmission unit
(MTU) for labeled packets.
show mpls forwarding-table
show tag-switching
forwarding-table
Displays the contents of the label forwarding
information base (LFIB).
show mpls interfaces
show tag-switching interfaces
Displays information about one or more interfaces that
have been configured for label switching.
show mpls label range
N/A
Displays the range of local labels available for use on
packet interfaces.
Benefits
MPLS provides the following major benefits to service provider networks:
•
Scalable support for SVirtual Private Networks (VPNs)—MPLS enables VPN services to be
supported in service provider networks, thereby greatly accelerating Internet growth.
The use of MPLS for VPNs provides an attractive alternative to the building of VPNs by means of
either ATM or Frame Relay permanent virtual circuits (PVCs) or various forms of tunneling to
interconnect routers at customer sites.
Unlike the PVC VPN model, the MPLS VPN model is highly scalable and can accommodate
increasing numbers of sites and customers. The MPLS VPN model also supports “any-to-any”
communication among VPN sites without requiring a full mesh of PVCs or the backhauling
Cisco IOS Switching Services Configuration Guide
XC-83
Multiprotocol Label Switching Overview
Label Switching Functions
(suboptimal routing) of traffic across the service provider network. For each MPLS VPN user, the
network of the service provider appears to function as a private IP backbone over which the user can
reach other sites within the VPN organization, but not the sites of any other VPN organization.
From a user perspective, the MPLS VPN model enables network routing to be dramatically
simplified. For example, rather than needing to manage routing over a topologically complex virtual
backbone composed of many PVCs, an MPLS VPN user can generally employ the backbone of the
service provider as the default route in communicating with all of the other VPN sites.
•
Explicit routing capabilities (also called constraint-based routing or traffic engineering)—Explicit
routing employs “constraint-based routing,” in which the path for a traffic flow is the shortest path
that meets the resource requirements (constraints) of the traffic flow.
In MPLS traffic engineering, factors such as bandwidth requirements, media requirements, and the
priority of one traffic flow versus another can be taken into account. These traffic engineering
capabilities enable the administrator of a service provider network to perform the following tasks:
– Control traffic flow in the network
– Reduce congestion in the network
– Make best use of network resources
Thus, the network administrator can specify the amount of traffic expected to flow between various
points in the network (thereby establishing a traffic matrix), while relying on the routing system to
perform the following tasks:
– Calculate the best paths for network traffic
– Set up the explicit paths to carry the traffic
•
Support for IP routing on ATM switches (also called IP and ATM integration)—MPLS enables an
ATM switch to perform virtually all of the functions of an IP router. This capability of an ATM
switch stems from the fact that the MPLS forwarding paradigm (namely, label swapping) is exactly
the same as the forwarding paradigm provided by ATM switch hardware.
The key difference between a conventional ATM switch and an ATM label switch is the control
software used by the latter to establish its virtual channel identifier (VCI) table entries. An ATM
label switch uses IP routing protocols and the TDP to establish VCI table entries.
An ATM label switch can function as a conventional ATM switch. In this dual mode, the ATM switch
resources (such as VCI space and bandwidth) are partitioned between the MPLS control plane and
the ATM control plane. The MPLS control plane provides IP-based services, while the ATM control
plane supports ATM-oriented functions, such as circuit emulation or PVC services.
Label Switching Functions
In conventional Layer 3 forwarding mechanisms, as a packet traverses the network, each router extracts
all the information relevant to forwarding the packet from the Layer 3 header. This information is then
used as an index for a routing table lookup to determine the next hop for the packet.
In the most common case, the only relevant field in the header is the destination address field, but in
some cases other header fields might also be relevant. As a result, the header analysis must be done
independently at each router through which the packet passes. A complicated table lookup must also be
done at each router.
In label switching, the analysis of the Layer 3 header is done only once. The Layer 3 header is then
mapped into a fixed length, unstructured value called a label.
Cisco IOS Switching Services Configuration Guide
XC-84
Multiprotocol Label Switching Overview
Distribution of Label Bindings
Many different headers can map to the same label, as long as those headers always result in the same
choice of next hop. In effect, a label represents a forwarding equivalence class—that is, a set of packets
that, however different they may be, are indistinguishable by the forwarding function.
The initial choice of a label need not be based exclusively on the contents of the Layer 3 packet header;
for example, forwarding decisions at subsequent hops can also be based on routing policy.
Once a label is assigned, a short label header is added at the front of the Layer 3 packet. This header is
carried across the network as part of the packet. At subsequent hops through each MPLS router in the
network, labels are swapped and forwarding decisions are made by means of MPLS forwarding table
lookup for the label carried in the packet header. Hence, the packet header need not be reevaluated during
packet transit through the network. Because the label is of fixed length and unstructured, the MPLS
forwarding table lookup process is both straightforward and fast.
Distribution of Label Bindings
Each LSR in the network makes an independent, local decision as to which label value to use to represent
a forwarding equivalence class. This association is known as a label binding. Each LSR informs its
neighbors of the label bindings it has made. This awareness of label bindings by neighboring routers is
facilitated by the following protocols:
•
TDP—Used to support MPLS forwarding along normally routed paths
•
Resource Reservation Protocol (RSVP)—Used to support MPLS traffic engineering
•
Border Gateway Protocol (BGP)—Used to support MPLS VPNs
When a labeled packet is being sent from LSR A to the neighboring LSR B, the label value carried by
the IP packet is the label value that LSR B assigned to represent the forwarding equivalence class of the
packet. Thus, the label value changes as the IP packet traverses the network.
MPLS and Routing
A label represents a forwarding equivalence class, but it does not represent a particular path through the
network. In general, the path through the network continues to be chosen by the existing Layer 3 routing
algorithms such as OSPF, Enhanced IGRP, and BGP. That is, at each hop when a label is looked up, the
next hop chosen is determined by the dynamic routing algorithm.
MPLS Traffic Engineering
MPLS traffic engineering software enables an MPLS backbone to replicate and expand upon the traffic
engineering capabilities of Layer 2 ATM and Frame Relay networks. MPLS is an integration of Layer 2
and Layer 3 technologies. By making traditional Layer 2 features available to Layer 3, MPLS enables
traffic engineering. Thus, you can offer in a one-tier network what now can be achieved only by
overlaying a Layer 3 network on a Layer 2 network.
Traffic engineering is essential for service provider and Internet service provider (ISP) backbones. Such
backbones must support a high use of transmission capacity, and the networks must be very resilient so
that they can withstand link or node failures.
MPLS traffic engineering provides an integrated approach to traffic engineering. With MPLS, traffic
engineering capabilities are integrated into Layer 3, which optimizes the routing of IP traffic, given the
constraints imposed by backbone capacity and topology.
Cisco IOS Switching Services Configuration Guide
XC-85
Multiprotocol Label Switching Overview
MPLS Traffic Engineering
Why Use MPLS Traffic Engineering?
WAN connections are an expensive item in an ISP budget. Traffic engineering enables ISPs to route
network traffic to offer the best service to their users in terms of throughput and delay. By making the
service provider more efficient, traffic engineering reduces the cost of the network.
Currently, some ISPs base their services on an overlay model. In the overlay model, transmission
facilities are managed by Layer 2 switching. The routers see only a fully meshed virtual topology,
making most destinations appear one hop away. If you use the explicit Layer 2 transit layer, you can
precisely control how traffic uses available bandwidth. However, the overlay model has numerous
disadvantages. MPLS traffic engineering achieves the traffic engineering benefits of the overlay model
without running a separate network, and without needing a nonscalable, full mesh of router
interconnects.
How MPLS Traffic Engineering Works
MPLS traffic engineering automatically establishes and maintains LSPs across the backbone by using
RSVP. The path that an LSP uses is determined by the LSP resource requirements and network resources,
such as bandwidth.
Available resources are flooded by means of extensions to a link-state-based Interior Gateway Protocol
(IGP).
Traffic engineering tunnels are calculated at the LSP head based on a fit between required and available
resources (constraint-based routing). The IGP automatically routes the traffic onto these LSPs.
Typically, a packet crossing the MPLS traffic engineering backbone travels on a single LSP that connects
the ingress point to the egress point.
MPLS traffic engineering is built on the following Cisco IOS mechanisms:
•
IP tunnel interfaces—From a Layer 2 standpoint, an MPLS tunnel interface represents the head of
an LSP. It is configured with a set of resource requirements, such as bandwidth and media
requirements, and priority.
From a Layer 3 standpoint, an LSP tunnel interface is the head-end of a unidirectional virtual link
to the tunnel destination.
•
MPLS traffic engineering path calculation module—This calculation module operates at the LSP
head. The module determines a path to use for an LSP. The path calculation uses a link-state
database containing flooded topology and resource information.
•
RSVP with traffic engineering extensions—RSVP operates at each LSP hop and is used to signal
and maintain LSPs based on the calculated path.
•
MPLS traffic engineering link management module—This module operates at each LSP hop, does
link call admission on the RSVP signalling messages, and does bookkeeping of topology and
resource information to be flooded.
•
Link-state IGP (Intermediate System-to-Intermediate System (IS-IS) or OSPF—each with traffic
engineering extensions)—These IGPs are used to globally flood topology and resource information
from the link management module.
•
Enhancements to the SPF calculation used by the link-state IGP (IS-IS or OSPF)—The IGP
automatically routes traffic onto the appropriate LSP tunnel based on tunnel destination. Static
routes can also be used to direct traffic onto LSP tunnels.
•
Label switching forwarding—This forwarding mechanism provides routers with a Layer 2-like
ability to direct traffic across multiple hops of the LSP established by RSVP signalling.
Cisco IOS Switching Services Configuration Guide
XC-86
Multiprotocol Label Switching Overview
MPLS Traffic Engineering
One approach to engineering a backbone is to define a mesh of tunnels from every ingress device to every
egress device. The MPLS traffic engineering path calculation and signalling modules determine the path
taken by the LSPs for these tunnels, subject to resource availability and the dynamic state of the network.
The IGP, operating at an ingress device, determines which traffic should go to which egress device, and
steers that traffic into the tunnel from ingress to egress.
A flow from an ingress device to an egress device might be so large that it cannot fit over a single link,
so it cannot be carried by a single tunnel. In this case, multiple tunnels between a given ingress and
egress can be configured, and the flow is load-shared among them.
For more information about MPLS, see the following Cisco documentation:
•
Cisco IOS Switching Services Configuration Guide, “Multiprotocol Label Switching” chapter
•
Cisco IOS Switching Services Command Reference, “Switching Commands Introduction” chapter
Mapping Traffic into Tunnels
This section describes how traffic is mapped into tunnels; that is, how conventional hop-by-hop
link-state routing protocols interact with MPLS traffic engineering capabilities. In particular, this section
describes how the shortest path first (SPF) algorithm, sometimes called a Dijkstra algorithm, has been
enhanced so that a link-state IGP can automatically forward traffic over tunnels that MPLS traffic
engineering establishes.
Link-state protocols, like integrated IS-IS or OSPF, use an SPF algorithm to compute a shortest path tree
from the headend node to all nodes in the network. Routing tables are derived from this shortest path
tree. The routing tables contain ordered sets of destination and first hop information. If a router does
normal hop-by-hop routing, the first hop is over a physical interface attached to the router.
New traffic engineering algorithms calculate explicit routes to one or more nodes in the network. The
originating router views these explicit routes as logical interfaces. In the context of this document, these
explicit routes are represented by LSPs and referred to as traffic engineering tunnels (TE tunnels).
The following sections describe how link-state IGPs can use these shortcuts, and how they can install
routes in the routing table that point to these TE tunnels. These tunnels use explicit routes, and the path
taken by a TE tunnel is controlled by the router that is the headend of the tunnel. In the absence of errors,
TE tunnels are guaranteed not to loop, but routers must agree on how to use the TE tunnels. Otherwise,
traffic might loop through two or more tunnels.
Enhancement to the SPF Computation
During each step of the SPF computation, a router discovers the path to one node in the network, as
follows:
•
If that node is directly connected to the calculating router, the first hop information is derived from
the adjacency database.
•
If the node is not directly connected to the calculating router, the node inherits the first hop
information from the parents of that node. Each node has one or more parents, and each node is the
parent of zero or more downstream nodes.
For traffic engineering purposes, each router maintains a list of all TE tunnels that originate at this head
end router. For each of those TE tunnels, the router at the tailend is known to the head end router.
Cisco IOS Switching Services Configuration Guide
XC-87
Multiprotocol Label Switching Overview
MPLS Traffic Engineering
During the SPF computation, the TENT (tentative) list stores paths that are possibly the best paths and
the PATH list stores paths that are definitely the best paths. When it is determined that a path is the best
possible path, the node is moved from TENT to PATH. PATH is thus the set of nodes for which the best
path from the computing router has been found. Each PATH entry consists of ID, path cost, and
forwarding direction.
The router must determine the first hop information using one of the following methods:
•
Examine the list of tail-end routers directly reachable by a TE tunnel. If there is a TE tunnel to this
node, use the TE tunnel as the first hop.
•
If there is no TE tunnel and the node is directly connected, use the first hop information from the
adjacency database.
•
If the node is not directly connected and is not directly reachable by a TE tunnel, copy the first hop
information from the parent nodes to the new node.
As a result of this computation, traffic to nodes that are the tail end of TE tunnels flows over the
TE tunnels. Traffic to nodes that are downstream of the tail-end nodes also flows over the TE tunnels. If
there is more than one TE tunnel to different intermediate nodes on the path to destination node X, traffic
flows over the TE tunnel whose tail-end node is closest to node X.
Special Cases and Exceptions
The SPF algorithm finds equal-cost parallel paths to destinations. The enhancement previously
described does not change this behavior. Traffic can be forwarded over any of the following:
•
One or more native IP paths
•
One or more traffic engineering tunnels
•
A combination of native IP paths and traffic engineering tunnels
A special situation occurs in the topology shown in Figure 24.
Figure 24
Router B
Router C
Router D
Router E
26682
Router A
Sample Topology of Parallel Native Paths and Paths over TE Tunnels
Cisco IOS Switching Services Configuration Guide
XC-88
Multiprotocol Label Switching Overview
MPLS Traffic Engineering
If parallel native IP paths and paths over TE tunnels are available, the following implementations allow
you to force traffic to flow over TE tunnels only or only over native IP paths. Assume that all links have
the same cost and that a TE tunnel is set up from Router A to Router D.
•
When the SPF calculation puts Router C on the TENT list, it realizes that Router C is not directly
connected. It uses the first hop information from the parent, which is Router B.
•
When the SPF calculation on Router A puts Router D on the TENT list, it realizes that Router D is
the tail end of a TE tunnel. Thus Router A installs a route to Router D by the TE tunnel, and not by
Router B.
•
When Router A puts Router E on the TENT list, it realizes that Router E is not directly connected,
and that Router E is not the tail end of a TE tunnel. Therefore Router A copies the first hop
information from the parents (Router C and Router D) to the first-hop information of Router E.
Traffic to Router E now load balances over the following:
•
The native IP path by Router A to Router B to Router C
•
The TE tunnel Router A to Router D
Additional Enhancements to SPF Computation Using Configured Tunnel Metrics
When traffic engineering tunnels install an IGP route in a Router Information Base (RIB) as next hops,
the distance or metric of the route must be calculated. Normally, you could make the metric the same as
the IGP metric over native IP paths as if the TE tunnels did not exist. For example, Router A can reach
Router C with the shortest distance of 20. X is a route advertised in IGP by Router C. Route X is installed
in the RIB of Router A with the metric of 20. When a TE tunnel from Router A to Router C comes up,
by default the route is installed with a metric of 20, but the next hop information for X is changed.
Although the same metric scheme can work well in other situations, for some applications it is useful to
change the TE tunnel metric (for instance, when there are equal cost paths through TE tunnel and native
IP links). You can adjust TE tunnel metrics to force the traffic to prefer the TE tunnel, to prefer the native
IP paths, or to load share among them.
Suppose that multiple TE tunnels go to the same destination or different destinations. TE tunnel metrics
can force the traffic to prefer some TE tunnels over others, regardless of IGP distances to those
destinations.
Setting metrics on TE tunnels does not affect the basic SPF algorithm. It affects only two questions:
•
Is the TE tunnel installed as one of the next hops to the destination routers?
•
What is the metric value of the routes being installed into the RIB?
You can modify the metrics for determining the first hop information in one of the following ways:
•
If the metric of the TE tunnel to the tail end routers is higher than the metric for the other TE tunnels
or native hop-by-hop IGP paths, this tunnel is not installed as the next hop.
•
If the metric of the TE tunnel is equal to the metric of either other TE tunnels or native hop-by-hop
IGP paths, this tunnel is added to the existing next hops.
•
If the metric of the TE tunnel is lower than the metric of other TE tunnels or native hop-by-hop IGP
paths, this tunnel replaces them as the only next hop.
In each of these cases, the IGP assigns metrics to routes associated with those tail end routers and their
downstream routers.
Cisco IOS Switching Services Configuration Guide
XC-89
Multiprotocol Label Switching Overview
MPLS Traffic Engineering
The SPF computation is loop free because the traffic through the TE tunnels is basically source routed.
The result of TE tunnel metric adjustment is the control of traffic load sharing. If there is only one way
to reach the destination through a single TE tunnel, then no matter what metric is assigned, the traffic
has only one way to go.
You can represent the TE tunnel metric in two different ways: as an absolute (or fixed) metric, or as a
relative (or floating) metric.
If you use an absolute metric, the routes assigned with the metric are fixed. This metric is used not only
for the routes sourced on the TE tunnel tail end router, but also for each route downstream of this tail
end router that uses this TE tunnel as one of its next hops.
For example, if you have TE tunnels to two core routers in a remote point of presence (POP), and one of
them has an absolute metric of 1, all traffic going to that POP traverses this low-metric TE tunnel.
If you use a relative metric, the actual assigned metric value of routes is based on the IGP metric. This
relative metric can be positive or negative, and is bounded by minimum and maximum allowed metric
values. For example, assume the topology shown in Figure 25.
Figure 25
Topology That Has No Traffic Engineering Tunnel
Router A
Router B
Metric = 10
Router C
Metric = 10
Metric = 10
Subnet x
Router E
Metric = 10
Subnet y
Subnet z
26511
MPLS TE-tunnel T1
Router D
If there is no TE tunnel, Router A installs routes x, y, and z and assigns metrics 20, 30, and 40,
respectively. Suppose that Router A has a TE tunnel T1 to Router C. If the relative metric –5 is used on
tunnel T1, the routers x, y, and z have the installed metrics of 15, 25, and 35. If an absolute metric of 5
is used on tunnel T1, routes x, y and z have the same metric 5 installed in the RIB for Router A. The
assigning of no metric on the TE tunnel is a special case, a relative metric scheme where the metric is 0.
Making the Transition from an IS-IS Network to a New Technology
IS-IS includes extensions for MPLS traffic engineering and for other purposes. Running MPLS traffic
engineering over IS-IS or taking advantage of these other extensions requires transition to an IS-IS
network to this new technology. This section describes these extensions and discusses two ways to
migrate an existing IS-IS network from the standard ISO 10589 protocol to IS-IS with new extensions.
Note
Running MPLS traffic engineering over an existing IS-IS network requires a transition to
incorporating extensions to IS-IS. However, running MPLS traffic engineering over OSPF does not
require any similar network transition.
Cisco IOS Switching Services Configuration Guide
XC-90
Multiprotocol Label Switching Overview
MPLS Traffic Engineering
New Extensions for the IS-IS Routing Protocol
New extensions for the IS-IS routing protocol serve the following purposes:
•
Remove the 6-bit limit on link metrics.
•
Allow interarea IP routes.
•
Enable IS-IS to carry different kinds of information for traffic engineering. In the future, more
extensions might be needed.
To serve these purposes, two new type, length, and value objects (TLVs) have been defined:
Note
•
TLV 22 describes links (or rather adjacencies). It serves the same purpose as the IS neighbor option
in ISO 10589 (TLV 2).
•
TLV 135 describes reachable IP prefixes. It is similar to the IP Neighbor options from RFC 1195
(TLVs 128 and 130).
For the purpose of briefness, these two new TLVs, 22 and 135, are referred to as “new-style TLVs.”
TLVs 2, 128, and 130 are referred to as “old-style TLVs.”
Both new TLVs have a fixed length part, followed by optional sub-TLVs. The metric space in these new
TLVs has been enhanced from 6 bits to 24 or 32 bits. The sub-TLVs allow you to add new properties to
links and prefixes. Traffic engineering is the first technology to use this ability to add new properties to
a link.
The Problem in Theory
Link-state routing protocols compute loop-free routes. This is guaranteed because all routers calculate
their routing tables based on the same information from the link-state database.
There is a problem when some routers look at old-style TLVs and some routers look at new-style TLVs
because the routers can base their SPF calculations on different information. This can cause routing
loops.
The Problem in Practice
The easiest way to migrate from old-style TLVs to new-style TLVs would be to introduce a “flag day.”
A flag day means that you reconfigure all routers during a short period of time, during which service is
interrupted. If the implementation of a flag day is not acceptable, a network administrator needs to find
a viable solution for modern existing networks.
Network administrators have the following problems related to TLVs:
•
They need to run an IS-IS network where some routers are advertising and using the new-style TLVs
and, at the same time, other routers are capable only of advertising and using old-style TLVs.
•
They need to test new traffic engineering software in existing networks on a limited number of
routers. They cannot upgrade all their routers in their production networks or in their test networks
before they start testing.
The new extensions allow a network administrator to use old-style TLVs in one area, and new-style TLVs
in another area. However, this is not a solution for administrators that need or want to run their network
in one single area.
The following sections describe two solutions to the problem of the network administrator.
Cisco IOS Switching Services Configuration Guide
XC-91
Multiprotocol Label Switching Overview
MPLS Traffic Engineering
First Solution for Making the Transition from an IS-IS Network to a New Technology
When you migrate from old-style TLVs to new-style TLVs, you can advertise the same information
twice—once in old-style TLVs and once in new-style TLVs. This ensures that all routers can understand
what is advertised.
There are three disadvantages to using that approach:
•
Size of the LSPs—During the transition, the LSPs grow to about twice their original size. This might
be a problem in networks where the link-state database is large. A link-state database might be large
for the following reasons:
– There are many routers, and thus LSPs.
– There are many neighbors or IP prefixes per router. A router that advertises substantial
information causes the LSPs to be fragmented.
•
Unpredictable results—In a large network, this solution can produce unpredictable results. A large
network in transition pushes the limits regarding LSP flooding and SPF scaling. During the
transition, the following behavior might occur:
– You can expect some extra network instability.
– Traffic engineering extensions might cause LSPs to be reflooded frequently.
•
Ambiguity—If a router encounters different information in the old-style TLVs and the new-style
TLVs, it may not be clear what the router should do.
These problems can be largely solved easily by using the following:
•
All information in old-style and new-style TLVs in an LSP
•
The adjacency with the lowest link metric if an adjacency is advertised more than once
The main benefit to advertising the same information twice is that network administrators can use
new-style TLVs before all routers in the network can understand them.
Transition Actions During the First Solution
When making the transition from using IS-IS with old-style TLVs to new-style TLVs, you can perform
the following actions:
•
If all routers run old software, advertise and use only old-style TLVs.
•
Upgrade some routers to newer software.
•
Configure some routers with new software to advertise both old-style and new-style TLVs. They
accept both styles of TLVs. Configure other routers (with old software) to continue advertising and
using only old-style TLVs.
•
Test traffic engineering in parts of your network; however, new-style TLVs cannot be used yet.
•
If the whole network needs to migrate, upgrade and configure all remaining routers to advertise and
accept both styles of TLVs.
•
Configure all routers to advertise and accept only new-style TLVs.
•
Configure metrics larger than 63.
For more information about how to perform these actions, see the section “TLV Configuration
Commands.”
Cisco IOS Switching Services Configuration Guide
XC-92
Multiprotocol Label Switching Overview
MPLS Traffic Engineering
Second Solution for Making the Transition from an IS-IS Network to a New Technology
Routers advertise only one style of TLVs at the same time, but can understand both types of TLVs during
migration. There are two main benefits to this approach:
•
LSPs stay approximately the same size during migration.
•
There is no ambiguity when the same information is advertised twice inside one LSP.
This method is useful when you move the whole network (or a whole area) to use wider metrics (that is,
you want a router running IS-IS to generate and accept only new-style TLVs). For more information, see
the metric-style wide router configuration command.
The disadvantage is that all routers must understand the new-style TLVs before any router can start
advertising new-style TLVs. It does not help the second problem, where network administrators want to
use the new-style TLVs for traffic engineering, while some routers are capable of understanding only
old-style TLVs.
Transition Actions During the Second Solution
If you use the second solution, you can perform the following actions:
•
If all routers run old software, advertise and use only old-style TLVs.
•
Upgrade all routers to newer software.
•
Configure all routers one-by-one to advertise old-style TLVs, but to accept both styles of TLVs.
•
Configure all routers one-by-one to advertise new-style TLVs, but to accept both styles of TLVs.
•
Configure all routers one-by-one to advertise and to accept only new-style TLVs.
•
Configure metrics larger than 63.
TLV Configuration Commands
Cisco IOS software has a new router isis CLI command called metric-style. Once you are in the router
IS-IS command mode, you have the option to choose the following:
•
Metric-style narrow—Enables the router to generate and accept only old-style TLVs
•
Metric-style transition—Enables the router to generate and accept both old-style and new-style
TLVs
•
Metric-style wide—Enables the router to generate and accept only new-style TLVs
You can use either of two transition schemes when you are using the metric-style commands:
•
Narrow to transition to wide
•
Narrow to narrow transition to wide transition to wide
Implementation in Cisco IOS Software
Cisco IOS software implements both transition solutions of moving your IS-IS network to a new
technology. Network administrators can choose the solution that suits them. For test networks, the first
solution is ideal (see the section “First Solution for Making the Transition from an IS-IS Network to a
New Technology”). For a real transition, both solutions can be used. The first solution requires fewer
Cisco IOS Switching Services Configuration Guide
XC-93
Multiprotocol Label Switching Overview
MPLS Virtual Private Networks
steps and less configuration. Only the largest networks that do not want to double their link-state
database during transition need to use the second solution (see the “Second Solution for Making the
Transition from an IS-IS Network to a New Technology”).
MPLS Virtual Private Networks
Using MPLS VPNs in a Cisco IOS network provide the capability to deploy and administer scalable
Layer 3 VPN backbone services including applications, data hosting network commerce, and telephony
services to business customers. A VPN is a secure IP-based network that shares resources on one or more
physical networks. A VPN contains geographically dispersed sites that can communicate securely over
a shared backbone.
A one-to-one relationship does not necessarily exist between customer sites and VPNs; a given site can
be a member of multiple VPNs. However, a site can associate with only one VPN routing and forwarding
instance (VRF). Each VPN is associated with one or more VPN VRFs. A VRF includes routing and
forwarding tables and rules that define the VPN membership of customer devices attached to CE routers.
A VRF consists of the following:
•
IP routing table
•
CEF table
•
Set of interfaces that use the CEF forwarding table
•
Set of rules and routing protocol parameters to control the information in the routing tables
VPN routing information is stored in the IP routing table and the CEF table for each VRF. A separate set
of routing and CEF tables is maintained for each VRF. These tables prevent information from being
forwarded outside a VPN and also prevent packets that are outside a VPN from being forwarded to a
router within the VPN.
The following sections provide more information on MPLS VPNs:
•
Benefits
•
VPN Operation
•
Distribution of VPN Routing Information
•
BGP Distribution of VPN Routing Information
•
MPLS Forwarding
•
MPLS VPN Cable Interfaces
•
Interautonomous Systems for MPLS VPNs
•
HSRP Support for MPLS VPNS
Benefits
MPLS VPNs allow service providers to deploy scalable VPNs and build the foundation to deliver
value-added services, including the following:
•
Connectionless service—A significant technical advantage of MPLS VPNs is that they are
connectionless. The Internet owes its success to its basic technology, TCP/IP. TCP/IP is built on
packet-based, connectionless network paradigm. This means that no prior action is necessary to
establish communication between hosts, making it easy for two parties to communicate. To establish
privacy in a connectionless IP environment, current VPN solutions impose a connection-oriented,
Cisco IOS Switching Services Configuration Guide
XC-94
Multiprotocol Label Switching Overview
MPLS Virtual Private Networks
point-to-point overlay on the network. Even if it runs over a connectionless network, a VPN cannot
take advantage of the ease of connectivity and multiple services available in connectionless
networks. When you create a connectionless VPN, you do not need tunnels and encryption for
network privacy, thus eliminating substantial complexity.
•
Centralized service—Building VPNs in Layer 3 allows delivery of targeted services to a group of
users represented by a VPN. A VPN must give service providers more than a mechanism for
privately connecting users to intranet services. It must also provide a way to flexibly deliver
value-added services to targeted customers. Scalability is critical, because customers want to use
services privately in their intranets and extranets. Because MPLS VPNs are seen as private intranets,
you may use IP services such as the following:
– Multicast
– Quality of service (QoS)
– Telephony support within a VPN
– Centralized services including content and web hosting to a VPN
You can customize several combinations of specialized services for individual customers.
For example, a service that combines IP multicast with a low-latency service class enables
videoconferencing within an intranet.
•
Scalability—If you create a VPN using connection-oriented, point-to-point overlays, Frame Relay,
or ATM virtual connections, the VPN’s key deficiency of the VPN is scalability. Specifically,
connection-oriented VPNs without fully meshed connections between customer sites are not
optimal. MPLS-based VPNs instead use the peer model and Layer 3 connectionless architecture to
leverage a highly scalable VPN solution. The peer model requires a customer site to only peer with
one provider edge (PE) router as opposed to all other CPE or CE routers that are members of the
VPN. The connectionless architecture allows the creation of VPNs in Layer 3, eliminating the need
for tunnels or virtual connections.
The following are scalability issues of MPLS VPNs due to the partitioning of VPN routes between
PE routers and the further partitioning of VPN and IGP routes between PE routers and provider (P)
routers in a core network:
– PE routers must maintain VPN routes for those VPNs that are members.
– P routers do not maintain any VPN routes.
This increases the scalability of the provider’s core and ensures that no one device is a scalability
bottleneck.
•
Security—MPLS VPNs offer the same level of security as connection-oriented VPNs. Packets from
one VPN do not inadvertently go to another VPN. Security is provided
– At the edge of a provider network, ensuring that packets received from a customer are placed
on the correct VPN.
– At the backbone, ensuring that VPN traffic is kept separate. Malicious spoofing (an attempt to
gain access to a PE router) is nearly impossible because the packets received from customers
are IP packets. These IP packets must be received on a particular interface or subinterface to be
uniquely identified with a VPN label.
•
Easy to create—To take full advantage of VPNs, it must be easy for you to create new VPNs and
user communities. Because MPLS VPNs are connectionless, no specific point-to-point connection
maps or topologies are required. You can add sites to intranets and extranets and form closed user
groups. When you manage VPNs in this manner, it enables membership of any given site in multiple
VPNs, maximizing flexibility in building intranets and extranets.
Cisco IOS Switching Services Configuration Guide
XC-95
Multiprotocol Label Switching Overview
MPLS Virtual Private Networks
•
Flexible addressing—To make a VPN service more accessible, customers of a service provider can
design their own addressing plan, independent of addressing plans for other service provider
customers. Many customers use private address spaces and do not want to invest the time and
expense of converting to public IP addresses to enable intranet connectivity. MPLS VPNs allow
customers to continue to use their present address spaces without Network Address Translation
(NAT) by providing a public and private view of the address. A NAT is required only if two VPNs
with overlapping address spaces want to communicate. This enables customers to use their own
unregistered private addresses, and to communicate freely across a public IP network.
•
Integrated Quality of Service (QoS) support—QoS is an important requirement for many IP VPN
customers. It provides the ability to address two fundamental VPN requirements:
– Predictable performance and policy implementation
– Support for multiple levels of service in an MPLS VPN
Network traffic is classified and labeled at the edge of the network before traffic is aggregated
according to policies defined by subscribers and implemented by the provider and transported across
the provider core. Traffic at the edge and core of the network can then be differentiated into different
classes by drop probability or delay.
•
Straightforward migration—For service providers to quickly deploy VPN services, use a
straightforward migration path. MPLS VPNs are unique because you can build them over multiple
network architectures, including IP, ATM, Frame Relay, and hybrid networks.
Migration for the end customer is simplified because there is no requirement to support MPLS on
the CE router and no modifications are required to a intranet belonging to a customer.
Figure 26 shows an example of a VPN with a service provider (P) backbone network, service
provider edge routers (PE), and customer edge routers (CE).
Figure 26
VPNs with a Service Provider Backbone
VPN 2
VPN 1
Site 1
PE
Service provider
backbone
P
Site 1
P
CE
PE
CE
Site 2
P
P
PE
CE
VPN 1
CE
17265
Site 2
A VPN contains customer devices attached to the CE routers. These customer devices use VPNs to
exchange information between devices. Only the PE routers are aware of the VPNs.
Cisco IOS Switching Services Configuration Guide
XC-96
Multiprotocol Label Switching Overview
MPLS Virtual Private Networks
Figure 27 shows five customer sites communicating within three VPNs. The VPNs can communicate
with the following sites:
•
VPN1—Sites 2 and 4
•
VPN2—Sites 1, 3, and 4
•
VPN3—Sites 1,3, and 5
Figure 27
Customer Sites within VPNs
VPN2
VPN3
VPN1
Site 1
Site 2
Site 4
Site 5
17266
Site 3
Increased BGP Functionality
The following is a list of increased BGP functionality:
•
Configuring BGP hub and spoke connections—Configuring PE routers in a hub and spoke
configuration allows a CE router to readvertise all prefixes containing duplicate autonomous system
numbers (ASNs) to neighboring PE routers. Using duplicate ASNs in a hub and spoke configuration
provides faster convergence of routing information within geographically dispersed locations.
•
Configuring faster convergence for BGP VRF routes—Configuring scanning intervals of BGP
routers decreases import processing time of VPNv4 routing information, thereby providing faster
convergence of routing information. Routing tables are updated with routing information about
VPNv4 routes learned from PE routers or route reflectors.
•
Limiting VPN VRFs—Limiting the number of routes in a VRF prevents a PE router from importing
too many routes, thus diminishing the performance of a router. This enhancement can also be used
to enforce the maximum number of members that can join a VPN from a particular site. A threshold
is set in the VRF routing table to limit the number of VRF routes imported.
•
Reusing ASNs in an MPLS VPN environment—Configuring a PE router to reuse an existing ASN
allows customers to configure BGP routes with the same ASNs in multiple geographically dispersed
sites, providing better scalability between sites.
•
Distributing BGP OSPF routing information—Setting a separate router ID for each interface or
subinterface on a PE router attached to multiple CE routers within a VPN provides increased
flexibility through OSPF when routers exchange routing information between sites.
Table 24 lists the MPLS VPN features and the associated BGP commands.
Cisco IOS Switching Services Configuration Guide
XC-97
Multiprotocol Label Switching Overview
MPLS Virtual Private Networks
Table 24
MPLS VPN Features and the Associated BGP Commands
Name of Cisco IOS Feature Command
Description
Configuring Faster
Convergence for BGP
VRF Routes
bgp scan-time import
Configures scanning intervals of BGP routers to
decrease import processing time of routing
information.
Limiting VRF Routes
maximum routes
Limits the number of routes in a VRF to prevent
a PE router from importing too many routes.
Configuring BGP Hub and neighbor allowas-in
Spoke Connections
Configures PE routers to allow CE routers to
readvertise all prefixes that contain duplicate
ASNs to neighboring PE routers.
Reusing ASNs in an
MPLS VPN Environment
neighbor as-override
Configures a PE router to reuse the same ASN
on all sites within an MPLS VPN by overriding
private ASNs.
Distributing BGP OSPF
Routing Information
set ospf router-id
Sets a separate router ID for each interface or
subinterface on the PE router for each directly
attached CE router.
VPN Operation
Each VPN is associated with one or more VRFs. A VRF defines the VPN membership of a customer site
attached to a PE router. A VRF consists of an IP routing table, a derived CEF table, a set of interfaces
that use the forwarding table, and a set of rules and routing protocol parameters that control the
information that is included into the routing table.
A one-to-one relationship does not necessarily exist between customer sites and VPNs. A given site can
be a member of multiple VPNs, as shown in Figure 27. However, a site can only associate with one (and
only one) VRF. A customer’s site VRF contains all the routes available to the site from the VPNs of
which it is a member.
Packet forwarding information is stored in the IP routing table and the CEF table for each VRF.
A separate set of routing and CEF tables is maintained for each VRF. These tables prevent information
from being forwarded outside a VPN, and also prevent packets that are outside a VPN from being
forwarded to a router within the VPN.
Cisco IOS Switching Services Configuration Guide
XC-98
Multiprotocol Label Switching Overview
MPLS Virtual Private Networks
Distribution of VPN Routing Information
The distribution of VPN routing information is controlled through the use of VPN route target
communities, implemented by BGP extended communities. Distribution of VPN routing information
works as follows:
•
When a VPN route learned from a CE router is injected into BGP, a list of VPN route target extended
community attributes is associated with it. Typically the list of route target community extended
values is set from an export list of route targets associated with the VRF from which the route was
learned.
•
An import list of route target extended communities is associated with each VRF. The import list
defines route target extended community attributes that a route must have in order for the route to
be imported into the VRF. For example, if the import list for a particular VRF includes route target
extended communities A, B, and C, then any VPN route that carries any of those route target
extended communities—A, B, or C—is imported into the VRF.
BGP Distribution of VPN Routing Information
A PE router can learn an IP prefix from a CE router by static configuration, through a BGP session with
the CE router, or through the Routing Information Protocol (RIP) exchange with the CE router. The IP
prefix is a member of the IPv4 address family. After it learns the IP prefix, the PE converts it into a
VPN-IPv4 prefix by combining it with an 8-byte route distinguisher (RD). The generated prefix is a
member of the VPN-IPv4 address family. It uniquely identifies the customer address, even if the
customer site is using globally nonunique (unregistered private) IP addresses.
The RD used to generate the VPN-IPv4 prefix is specified by a configuration command associated with
the VRF on the PE router.
BGP distributes reachability information for VPN-IPv4 prefixes for each VPN. BGP communication
takes place at two levels: within IP domains, known as autonomous systems (Interior BGP or IBGP) and
between autonomous systems (Exterior BGP or EBGP). PE-PE or PE-RR (route reflector) sessions are
IBGP sessions, and PE-CE sessions are EBGP sessions.
BGP propagates reachability information for VPN-IPv4 prefixes among PE routers by means of the BGP
multiprotocol extensions, which define support for address families other than IPv4. It does this in a way
that ensures that the routes for a given VPN are learned only by other members of that VPN, enabling
members of the VPN to communicate.
MPLS Forwarding
Based on routing information stored in the VRF IP routing table and VRF CEF table, packets are
forwarded to their destination using MPLS.
A PE router binds a label to each customer prefix learned from a CE router and includes the label in the
network-layer reachability information (NLRI) for the prefix that it advertises to other PE routers. When
a PE router forwards a packet received from a CE router across the provider network, it labels the packet
with the label learned from the destination PE router. When the destination PE router receives the labeled
packet, it pops the label and uses it to direct the packet to the correct CE router. Label forwarding across
the provider backbone, is based on either dynamic label switching or traffic engineered paths. A
customer data packet carries two levels of labels when traversing the backbone:
•
The top label directs the packet to the correct PE router.
•
The second label indicates how that PE router should forward the packet to the CE router.
Cisco IOS Switching Services Configuration Guide
XC-99
Multiprotocol Label Switching Overview
MPLS Virtual Private Networks
MPLS VPN Cable Interfaces
Using MPLS VPN technology, service providers can create scalable and efficient private networks using
a shared hybrid fiber coaxial (HFC) network and IP infrastructure.
The cable MPLS VPN network consists of the following:
•
The multiple service operator (MSO) or cable company that owns the physical infrastructure and
builds VPNs for the ISPs to move traffic over the cable and IP backbone.
•
ISPs that use the HFC network and IP infrastructure to supply Internet service to cable customers.
Each ISP moves traffic to and from the PC of a subscriber, through the physical network infrastructure
of the MSO, to the network of the ISP. MPLS VPNs, created in Layer 3, provide privacy and security by
constraining the distribution of the routes of a VPN only to the routers that belong to its network. Thus,
each VPN of the ISP is insulated from other ISPs that use the same MSO infrastructure.
An MPLS VPN assigns a unique VRF instance to each VPN. A VRF instance consists of an IP routing
table, a derived forwarding table, a set of interfaces that use the forwarding table, and a set of rules and
routing protocols that determine the contents of the forwarding table.
Each PE router maintains one or more VRF tables. It looks up a IP destination address of a packet in the
appropriate VRF table, only if the packet arrived directly through an interface associated with that table.
MPLS VPNs use a combination of BGP and IP address resolution to ensure security. Refer to the
“Configuring Multiprotocol Label Switching” chapter later in this publication.
Figure 28 shows a cable MPLS VPN network. The routers in the network are as follows:
•
Provider (P) router—Routers in the core of the provider network. P routers run MPLS switching,
and do not attach VPN labels (MPLS label in each route assigned by the PE router) to routed packets.
VPN labels are used to direct data packets to the correct egress router.
•
PE router—Router that attaches the VPN label to incoming packets based on the interface or
subinterface on which they are received. A PE router attaches directly to a CE router. In the MPLS
VPN approach, each Cisco uBR7200 series router acts as a PE router.
•
Customer (C) router—Router in the ISP or enterprise network.
•
Customer Edge (CE) router—Edge router on the network of the ISP that connects to the PE router
on the network of the MSO. A CE router must interface with a PE router.
The MPLS network has a unique VPN that exclusively manages the MSOs devices called the
management VPN. It contains servers and devices that other VPNs can access. The management VPN
connects the Cisco uBR7200 series router to a PE router, which connects to management servers such
as Cisco Network Registrar (CNR) and Time of Day (ToD) servers. A PE router connects to management
servers and is a part of the management VPN. Regardless of the ISP they belong to, the management
servers serve the Dynamic Host Configuration Protocol (DHCP), DNS (Domain Name System), and ToD
requests coming from PCs or cable modems.
Cisco IOS Switching Services Configuration Guide
XC-100
Multiprotocol Label Switching Overview
MPLS Virtual Private Networks
Figure 28
MPLS VPN Network
ISP-A
customer
ISP-A
VPN
CE
PE
VPN
Provider
core
ISP-B
VPN
HFC cable network
A
MSO
PE
Cisco
uBR 7246
ISP-B
customer
VPN B
CE
N
VP T
M
MG
PE
35638
Management
router
Management subnet
Cable VPN configuration involves the following:
Note
•
MSO domain that requires a direct peering link to each enterprise network (ISP), provisioning
servers for residential and commercial subscribers, and dynamic DNS for commercial users. The
MSO manages cable interface IP addressing, Data-over-Cable Service Interface Specifications
(DOCSIS) provisioning, CM host names, routing modifications, privilege levels, and usernames and
passwords.
•
ISP or enterprise domain that includes the DHCP server for subscriber or telecommuter host devices,
enterprise gateway within the MSO address space, and static routes back to the telecommuter
subnets.
We recommend that the MSO assign all addresses to the end-user devices and gateway interfaces.
The MSO can also use split management to let the ISP configure tunnels and security.
In an MPLS VPN configuration, the MSO must configure the following:
•
CMTS (Cisco uBR7200 series routers)
•
P routers
•
PE routers
•
CE routers
•
One VPN per ISP DOCSIS server for all cable modem customers. The MSO must attach DOCSIS
servers to the management VPN, and make them visible.
The MSO must configure Cisco uBR7200 series routers that serve the ISP, and remote PE routers
connecting to the ISP, as PE routers in the VPN.
Cisco IOS Switching Services Configuration Guide
XC-101
Multiprotocol Label Switching Overview
MPLS Virtual Private Networks
The MSO must determine the primary IP address range, which is the range of the MSO for all cable
modems belonging to the ISP subscribers.
The ISP must determine the secondary IP address range, which is the range of the ISP for its subscriber
PCs.
To reduce security breaches and differentiate DHCP requests from cable modems in VPNs or under
specific ISP management, MSOs can use the cable helper-address cable interface command in Cisco
IOS software. The MSO can specify the host IP address to be accessible only in the VPN of the ISP. This
lets the ISP use its DHCP server to allocate IP addresses. Cable modem IP addresses must be accessible
from the management VPN.
The MPLS VPN approach of creating VPNs for individual ISPs or customers requires subinterfaces to
be configured on the cable interface or the cable interface bundle. Each ISP requires one subinterface.
The subinterfaces are tied to the VRF tables for their respective ISPs. The first subinterface must be
created on the cable interface bound to the management VPN.
To route a reply from the CNR back to the cable modem, the PE router that connects to the CNR must
import the routes of the ISP VPN into the management VPN. Similarly, to forward management requests
(such as DHCP renewal to CNR) to the cable modems, the ISP VPN must export and import the
appropriate management VPN routes.
Cisco uBR7200 series software supports the definition of logical network-layer interfaces over a
physical cable interface or a bundle of cable interfaces. You can create subinterfaces on either a physical
cable interface or a bundle of cable interfaces. Subinterfaces let service providers share one IP subnet
across multiple cable interfaces grouped into a cable interface bundle.
You can group all of the cable interfaces on a Cisco uBR7200 series router into a single bundle so that
only one subnet is required for each router. When you group cable interfaces, no separate IP subnet or
each individual cable interface is required. This grouping avoids performance, memory, and security
problems in using a bridging solution to manage subnets, especially for a large number of subscribers.
Subinterfaces allow traffic to be differentiated on a single physical interface, and assigned to multiple
VPNs. You can configure multiple subinterfaces, and associate an MPLS VPN with each subinterface.
You can split a single physical interface (the cable plant) into multiple subinterfaces, where each
subinterface is associated with a specific VPN. Each ISP requires access on a physical interface and is
given its own subinterface. Create a management subinterface to support cable modem initialization
from an ISP.
Using each subinterface associated with a specific VPN (and therefore, ISP), subscribers connect to a
logical subinterface, which reflects the ISP that provides their subscribed services. When properly
configured, subscriber traffic enters the appropriate subinterface and VPN.
The CMTS MSO administrator can define subinterfaces on a cable physical interface and assign Layer
3 configurations to each subinterface, or bundle a group of physical interfaces, define subinterfaces on
the bundle master, and give each subinterface a Layer 3 configuration.
Benefits
MPLS VPNs with cable interfaces provide the following benefits:
•
MPLS VPNs give cable MSOs and ISPs a manageable way of supporting multiple access to a cable
plant. Service providers can create scalable and efficient VPNs across the core of their networks.
MPLS VPNs provide systems support scalability in cable transport infrastructure and management.
•
Each ISP can support Internet access services from a PC of a subscriber through a physical cable
plant of a MSO to their networks.
Cisco IOS Switching Services Configuration Guide
XC-102
Multiprotocol Label Switching Overview
MPLS Virtual Private Networks
•
MPLS VPNs allow MSOs to deliver value-added services through an ISP, and thus, deliver
connectivity to a wider set of potential customers. MSOs can partner with ISPs to deliver multiple
services from multiple ISPs and add value within the own network of a MSO using VPN technology.
•
Subscribers can select combinations of services from various service providers.
•
The Cisco IOS MPLS VPN cable feature sets build on CMTS DOCSIS 1.0 and DOCSIS 1.0
extensions to ensure that services are reliably and optimally delivered over the cable plant. MPLS
VPN provides systems support domain selection, authentication per subscriber, selection of Quality
of Service (QoS), policy-based routing (PBR), and the ability to reach behind the cable modem to
subscriber end devices for QoS and billing while preventing session spoofing.
•
MPLS VPN technology ensures both secure access across the shared cable infrastructure and service
integrity.
•
Cable interface bundling eliminates the need for an IP subnet on each cable interface. Instead, an IP
subnet is only required for each cable interface bundle. All cable interfaces in a Cisco uBR7200
series router can be added to a single bundle.
Interautonomous Systems for MPLS VPNs
The interautonomous system for MPLS VPNs feature allows an MPLS VPN to span service providers
and autonomous systems.
As VPNs grow, their requirements expand. In some cases, VPNs need to reside on different autonomous
systems in different geographic areas. (An autonomous system is a single network or group of networks
that is controlled by a common system administration group and that uses a single, clearly defined
routing protocol.) Also, some VPNs need to extend across multiple service providers (overlapping
VPNs). Regardless of the complexity and location of the VPNs, the connection between autonomous
systems must be seamless to the customer.
The interautonomous systems for MPLS VPNs feature provides seamless integration of autonomous
systems and service providers. Separate autonomous systems from different service providers can
communicate by exchanging IPv4 network layer reachability information (NLRI) in the form of
VPN-IPv4 addresses. The border edge routers of autonomous systems use the EBGP to exchange that
information. Then, an IGP distributes the network layer information for VPN-IPv4 prefixes throughout
each VPN and each autonomous system. Routing information uses the following protocols:
•
Within an autonomous system, routing information is shared using an IGP.
•
Between autonomous systems, routing information is shared using an EBGP. An EBGP allows a
service provider to set up an interdomain routing system that guarantees the loop-free exchange of
routing information between separate autonomous systems.
An MPLS VPN with interautonomous system support allows a service provider to provide to customers
scalable Layer 3 VPN services, such as web hosting, application hosting, interactive learning, electronic
commerce, and telephony service. A VPN service provider supplies a secure, IP-based network that
shares resources on one or more physical networks.
The primary function of an EBGP is to exchange network reachability information between autonomous
systems, including information about the list of autonomous system routes. The autonomous systems use
EGBP border edge routers to distribute the routes, which include label switching information. Each
border edge router rewrites the next hop and MPLS labels.
Cisco IOS Switching Services Configuration Guide
XC-103
Multiprotocol Label Switching Overview
MPLS Virtual Private Networks
Interautonomous system configurations supported in an MPLS VPN can include the following:
•
Interprovider VPN—MPLS VPNs that include two or more autonomous systems, connected by
separate border edge routers. The autonomous systems exchange routes using EBGP. No IGP or
routing information is exchanged between the autonomous systems.
•
BGP confederations—MPLS VPNs that divide a single autonomous system into multiple
subautonomous systems, and classify them as a single, designated confederation. The network
recognizes the confederation as a single autonomous system. The peers in the different autonomous
systems communicate over EBGP sessions; however, they can exchange route information as if they
were IBGP peers.
Benefits of interautonomous Systems for MPLS VPNs are as follows:
•
Allows a VPN to cross more than one service provider backbone—The interautonomous systems for
MPLS VPNs feature allows service providers, running separate autonomous systems, to jointly offer
MPLS VPN services to the same end customer. A VPN can begin at one customer site and traverse
different VPN service provider backbones before arriving at another site of the same customer.
Previous MPLS VPNs could only traverse a single BGP autonomous system service provider
backbone. The interautonomous system feature allows multiple autonomous systems to form a
continuous (and seamless) network between customer sites of a service provider.
•
Allows a VPN to exist in different areas—The interautonomous systems for MPLS VPNs feature
allows a service provider to create a VPN in different geographic areas. Having all VPN traffic flow
through one point (between the areas) allows for better rate control of network traffic between the
areas.
•
Allows confederations to optimize IBGP meshing—The interautonomous systems for MPLS VPNs
feature can make IBGP meshing in an autonomous system more organized and manageable. You can
divide an autonomous system into multiple, separate subautonomous systems and then classify them
into a single confederation (even though the entire VPN backbone appears as a single autonomous
system). This capability allows a service provider to offer MPLS VPNs across the confederation
because it supports the exchange of labeled VPN-IPv4 NLRI between the subautonomous systems
that form the confederation.
Routing Between Autonomous Systems
Figure 29 illustrates one MPLS VPN consisting of two separate autonomous systems. Each autonomous
system operates under different administrative control and runs a different IGP. Service providers
exchange routing information through EBGP border edge routers (ASBR1 and ASBR2).
Cisco IOS Switching Services Configuration Guide
XC-104
Multiprotocol Label Switching Overview
MPLS Virtual Private Networks
Figure 29
EBGP Connection Between Two Autonomous Systems
Service Provider 1
Service Provider 2
RR-1
RR-2
Core of P
routers
Core of P
routers
EBGP VPNv4
routes with label
distribution
PE-1
ASBR1
CE-1
PE-2
ASBR2
CE-2
PE-3
CE-5
CE-3
CE-4
VPN1
43877
VPN1
This configuration uses the following process to transmit information:
Step 1
The provider edge router (PE-1) assigns a label for a route before distributing that route. The PE router
uses the multiprotocol extensions of a BGP to send label mapping information. The PE router distributes
the route as an VPN-IPv4 address. The address label and the VPN identifier are encoded as part of the
NLRI.
Step 2
The two route reflectors (RR-1 and RR-2) reflect VPN-IPv4 internal routes within the autonomous
system. The border edge routers of autonomous systems (ASBR1 and ASBR2) advertise the VPN-IPv4
external routes.
Step 3
The EBGP border edge router (ASBR1) redistributes the route to the next autonomous system (ASBR2).
ASBR1 specifies its own address as the value of the EBGP next hop attribute and assigns a new label.
The address ensures the following:
Step 4
•
That the next hop router is always reachable in the service provider (P) backbone network.
•
That the label assigned by the distributing router is properly interpreted. (The label associated with
a route must be assigned by the corresponding next hop router.)
The EBGP border edge router (ASBR2) redistributes the route in one of the following ways, depending
on its configuration:
•
If the IBGP neighbors are configured with the neighbor next-hop-self router configuration
command, ASBR2 changes the next hop address of updates received from the EBGP peer, then
forwards it.
•
If the IBGP neighbors are not configured with the neighbor next-hop-self router configuration
command, the next hop address does not get changed. ASBR2 must propagate a host route for the
EBGP peer through the IGP. To propagate the EBGP VPN-IPv4 neighbor host route, use the
redistribute connected subnets command. The EBGP VPN-IPv4 neighbor host route is
automatically installed in the routing table when the neighbor comes up. This is essential to establish
the label-switched path between PE routers in different autonomous systems.
Cisco IOS Switching Services Configuration Guide
XC-105
Multiprotocol Label Switching Overview
MPLS Virtual Private Networks
Exchanging VPN Routing Information
Autonomous systems exchange VPN routing information (routes and labels) to establish connections.
To control connections between autonomous systems, the PE routers and EBGP border edge routers
maintain an LFIB. The LFIB manages the labels and routes that the PE routers and EBGP border edge
routers receive during the exchange of VPN information.
Figure 30 illustrates the exchange of VPN route and label information between autonomous systems.
The autonomous systems use the following guidelines to exchange VPN routing information:
•
Routing information includes:
– The destination network (N)
– The next hop field associated with the distributing router
– A local MPLS label (L)
•
An RD1: route distinguisher (the route target value) is part of a destination network address to make
the VPN-IPv4 route globally unique in the VPN service provider environment.
•
When a router redistributes the route, it reassigns the label value and sets the next hop field to the
address of the distributing router (next-hop-self). Each VPN-IPv4 NRLI includes an MPLS label.
When a router changes the next hop field for a route, it changes the label field to a value that is
significant to the next hop destination router.
Figure 30
Exchanging Routes and Labels Between Autonomous Systems in an Interprovider VPN
Network
Service Provider 1
Service Provider 2
RR-1
RR-2
Network = RD1:N
Next hop = ASBR2
Label = L3
Network = RD1:N
Next hop = PE-1
Label = L1
Core of P
routers
Network = RD1:N
Next hop = ASBR2
Label = L3
Network = RD1:N
Next hop = PE-1
Label = L1
Core of P
routers
PE-2
PE-1
ASBR2
Network = RD1:N
Next hop = ASBR1
Label = L2
Network = N
Next hop = CE-2
PE-3
ASBR1
43878
Network = N
Next hop = PE-3
CE-1
CE-2
VPN1
CE-3
CE-4
CE-5
VPN1
Figure 31 illustrates the exchange of VPN route and label information between autonomous systems.
The difference between Figure 30 and Figure 31 is that ASBR2 is configured with the redistribute
connected router configuration command, which propagates the host routes to all PEs. The redistribute
connected router configuration command is necessary because ASBR2 is not configured to change the
next hop address.
Cisco IOS Switching Services Configuration Guide
XC-106
Multiprotocol Label Switching Overview
MPLS Virtual Private Networks
Exchanging Routes and Labels Between Autonomous Systems in an Interprovider VPN
Network
Service Provider 1
Service Provider 2
RR-1
RR-2
Network = RD1:N
Next hop = ASBR1
Label = L2
Network = RD1:N
Next hop = PE-1
Label = L1
Core of P
routers
Network = RD1:N
Next hop = ASBR1
Label = L2
Network = RD1:N
Next hop = PE-1
Label = L1
Core of P
routers
PE-3
PE-2
PE-1
ASBR1
ASBR2
Network = RD1:N
Next hop = ASBR1
Label = L2
Network = N
Next hop = CE-2
CE-1
Network = N
Next hop = PE-3
CE-2
CE-5
VPN1
CE-3
CE-4
48299
Figure 31
VPN1
Packet Forwarding
Figure 32 illustrates how packets are forwarded between autonomous systems in an interprovider
network using the following packet forwarding method.
Packets are forwarded to their destination by means of MPLS. Packets use the routing information stored
in the LFIB of each PE router and EBGP border edge router.
The service provider VPN backbone uses dynamic label switching to forward labels.
Each autonomous system uses standard multilevel labeling to forward packets between the edges of the
autonomous system routers (for example, from CE-5 to PE-3). Between autonomous systems, only a
single level of labeling is used, corresponding to the advertised route.
A data packet carries two levels of labels when traversing the VPN backbone:
•
The first label (IGP route label) directs the packet to the correct PE router or EBGP border edge
router. (For example, the IGP label of ASBR2 points to the ASBR2 border edge router.)
•
The second label (VPN route label) directs the packet to the appropriate PE router or EBGP border
edge router.
Cisco IOS Switching Services Configuration Guide
XC-107
Multiprotocol Label Switching Overview
MPLS Virtual Private Networks
Figure 32
Forwarding Packets Between Autonomous Systems in an Interprovider VPN Network
Service Provider 2
RR-1
RR-2
Network = N
IGP label = ASBR2
VPN label = L3
Service Provider 1
Core of P
routers
Network = N
IGP label = PE1
VPN label = L1
Network = N
VPN label = L1
Core of P
routers
Network = N
VPN label = L3
Network = RD1:N
VPN label = L2
PE-1
ASBR1
PE-2
ASBR2
PE-3
Network = RD1:N
Network = RD1:N
CE-1
CE-2
CE-5
CE-3
43879
VPN 1
CE-4
VPN 1
Figure 33 illustrates the same packet forwarding method, except the EBGP router (ASBR1) forwards the
packet without reassigning it a new label.
Figure 33
Forwarding Packets Between Autonomous Systems in an Interprovider VPN Network
Service Provider 2
RR-2
Network = N
IGP label = ASBR1
VPN label = L2
Core of P
routers
Network = N
VPN label = L1
Network = RD1:N Network = RD1:N
IGP label = PE1 IGP label = ASBR1
VPN label = L1
VPN label = L2
Network = RD1:N
VPN label = L2
PE-1
ASBR1
PE-2
ASBR2
Network = N
CE-1
CE-2
CE-5
CE-3
CE-4
VPN 1
XC-108
PE-3
Network = N
VPN 1
Cisco IOS Switching Services Configuration Guide
Core of P
routers
48300
RR-1
Service Provider 1
Multiprotocol Label Switching Overview
MPLS Virtual Private Networks
Routing Between Subautonomous Systems in a Confederation
A VPN can span service providers running in separate autonomous systems or between multiple
subautonomous systems that have been grouped together to form a confederation.
A confederation reduces the total number of peer devices in an autonomous system. A confederation
divides an autonomous system into subautonomous systems and assigns a confederation identifier to the
autonomous systems.
In a confederation, each subautonomous system is fully meshed with other subautonomous systems. The
subautonomous systems communicate using an IGP, such as OSPF or IS-IS. Each subautonomous
system also has an EBGP connection to the other subautonomous systems. The confederation EBGP
(CEBGP) border edge routers forward next-hop-self addresses between the specified subautonomous
systems. The next-hop-self address forces the BGP to use a specified address as the next hop rather than
letting the protocol choose the next hop.
You can configure a confederation with separate subautonomous systems in two ways:
Note
•
You can configure a router to forward next-hop-self addresses between only the CEBGP border edge
routers (both directions). The subautonomous systems (IBGP peers) at the subautonomous system
border do not forward the next-hop-self address. Each subautonomous system runs as a single IGP
domain. However, the CEBGP border edge router addresses are known in the IGP domains.
•
You can configure a router to forward next-hop-self addresses between the CEBGP border edge
routers (both directions) and within the IBGP peers at the subautonomous system border. Each
subautonomous system runs as a single IGP domain but also forwards next-hop-self addresses
between the PE routers in the domain. The CEBGP border edge router addresses are known in the
IGP domains.
Figure 30 and Figure 31 illustrate how two autonomous systems exchange routes and forward
packets. Subautonomous systems in a confederation use a similar method of exchanging routes and
forwarding packets.
Figure 34 illustrates a typical MPLS VPN confederation configuration. The following behavior occurs
in this confederation configuration:
•
The two CEBGP border edge routers exchange VPN-IPv4 addresses with labels between the two
subautonomous systems.
•
The distributing router changes the next hop addresses and labels and uses a next-hop-self address.
•
IGP-1 and IGP-2 know the addresses of CEBGP-1 and CEBGP-2.
Cisco IOS Switching Services Configuration Guide
XC-109
Multiprotocol Label Switching Overview
MPLS Quality of Service
EBGP Connection Between Two Subautonomous Systems in a Confederation
Service Provider 1
Service Provider 1
Sub-AS1 with
IGP-1
Core of P
routers
Sub-AS2 with
IGP-2
Core of P
routers
eBGP intraconfederation
for VPNv4 routes with label
distribution
PE-1
PE-2
CEBGP-2
CEGBP-1
CE-1
PE-3
CE-2
CE-5
VPN 1
CE-3
CE-4
VPN 1
43880
Figure 34
The following behavior occurs in this confederation configuration:
•
CEBGP border edge routers function as neighboring peers between the subautonomous systems.
The subautonomous systems use EBGP to exchange route information.
•
Each CEBGP border edge router (CEBGP-1 and CEBGP-2) assigns a label for the route before
distributing the route to the next subautonomous system. The CEBGP border edge router distributes
the route as an VPN-IPv4 address by using the multiprotocol extensions of BGP. The label and the
VPN identifier are encoded as part of the NLRI.
•
Each PE and CEBGP border edge router assigns its own label to each VPN-IPv4 address prefix
before redistributing the routes. The CEBGP border edge routers exchange VPN-IPv4 addresses
with the labels. The next-hop-self address is included in the label (as the value of the EBGP next
hop attribute). Within the subautonomous systems, the CEBGP border edge router address is
distributed throughout the IBGP neighbors and the two CEBGP border edge routers are known to
both confederations.
HSRP Support for MPLS VPNS
Hot Standby Router Protocol (HSRP) can now provide transparent “first-hop IP routing” redundancy for
workstations or routers connected to interfaces within MPLS VPNs. For more information on enabling
HSRP or configuring HSRP group attributes, refer to the “Configuring IP Services” chapter in the
Cisco IOS IP Configuration Guide.
MPLS Quality of Service
The quality of service (QoS) feature for MPLS enables network administrators to provide differentiated
types of service across an MPLS network. Differentiated service satisfies a range of requirements by
supplying for each packet transmitted the particular kind of service specified for that packet by its QoS.
Service can be specified in different ways, for example, using the IP precedence bit settings in IP
packets.
Cisco IOS Switching Services Configuration Guide
XC-110
Multiprotocol Label Switching Overview
MPLS Quality of Service
In supplying differentiated service, MPLS QoS offers packet classification, congestion avoidance, and
congestion management. Table 25 lists these functions and their descriptions.
Table 25
QoS Services and Features
Service
QoS Function
Packet
Committed access rate (CAR).
classification Packets are classified at the edge
of the network before labels are
assigned.
Note
Description
Classifies packets according to input or output
transmission rates. Allows you to set the MPLS
experimental bits or the IP Precedence or DSCP bits
(whichever is appropriate).
Congestion
avoidance
Monitors network traffic to prevent congestion by
Weighted Random Early
dropping packets based on the IP Precedence or
Detection (WRED). Packet
classes are differentiated based on DSCP bits or the MPLS experimental field.
drop probability.
Congestion
management
An automated scheduling system that uses a
Class-based weighted fair
queueing algorithm to ensure bandwidth allocation
queueing (CBWFQ). Packet
classes are differentiated based on to different classes of network traffic.
bandwidth and bounded delay.
MPLS QoS lets you duplicate Cisco IOS IP QoS (Layer 3) features as closely as possible in MPLS
devices, including label edge routers (LERs), LSRs, and ATM-LSRs. MPLS QoS functions map
nearly one-for-one to IP QoS functions on all interface types.
For more information on configuration of the QoS functions (CAR, WRED, and CBWFQ), refer to the
Cisco IOS Quality of Service Solutions Configuration Guide.
For complete command syntax information for CAR, WRED, and WFQ, refer to the Cisco IOS Quality
of Service Solutions Command Reference.
Specifying the QoS in the IP Precedence Field
When you send IP packets from one site to another, the IP Precedence field (the first three bits of the
DSCP field in the header of an IP packet) specifies the QoS. Based on the IP precedence marking, the
packet is given the desired treatment such as the latency or the percent of bandwidth allowed for that
quality of service. If the service provider network is an MPLS network, then the IP precedence bits are
copied into the MPLS EXP field at the edge of the network. However, the service provider might want
to set a QoS for a MPLS packet to a different value determined by the service offering.
This feature allows the service provider to set the MPLS experimental field instead of overwriting the
value in the IP precedence field belonging to a customer. The IP header remains available for the
customer’s use; the QoS of an IP packet is not changed as the packet travels through the MPLS network.
Cisco IOS Switching Services Configuration Guide
XC-111
Multiprotocol Label Switching Overview
MPLS Quality of Service
Figure 35 shows an MPLS network that connects two sites of a IP network belonging to a customer.
Figure 35
MPLS Network Connecting Two Sites of a IP Network Belonging to a Customer
IP
network
MPLS
network
MPLS
network
IP
network
Host A
Host B
PE1
P1
P2
PE2
CE2
41867
CE1
Owned by
service provider
Note
The network is bidirectional, but for the purpose of this document the packets move left to right.
In Figure 35, the symbols have the following meanings displayed in Table 26:
Table 26
Note
Device Symbols
Symbol
Meaning
CE1
Customer equipment 1
PE1
Service provider edge router (ingress LSR)
P1
Service provider router within the core of the network of the service provider
P2
Service provider router within the core of the network of the service provider
PE2
Service provider edge router (egress LSR)
CE2
Customer equipment 2
Notice that PE1 and PE2 are at the boundaries between the MPLS network and the IP network.
In Figure 35, the following behavior occurs:
•
Packets arrive as IP packets at PE1, the provider edge router (also known as the ingress label
switching router).
•
PE1 sends the packets as MPLS packets.
•
Within the service provider network, there is no IP Precedence field for the queueing mechanism to
look at because the packets are MPLS packets. The packets remain MPLS packets until they arrive
at PE2, the provider edge router.
•
PE2 removes the label from each packet and forwards the packets as IP packets.
Cisco IOS Switching Services Configuration Guide
XC-112
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
This MPLS QoS enhancement allows service providers to classify packets according to their type, input
interface, and other factors by setting (marking) each packet within the MPLS experimental field without
changing the IP Precedence or DSCP field. For example, service providers can classify packets with or
without considering the rate of the packets that PE1 receives. If the rate is a consideration, the service
provider marks in-rate packets differently from out-of-rate packets.
Note
The MPLS experimental bits allow you to specify the QoS for an MPLS packet. The IP
Precedence/DSCP bits allow you to specify the QoS for an IP packet.
MPLS Label Switch Controller
The MPLS LSC, combined with slave ATM switch, supports scalable integration of IP services over an
ATM network. The MPLS LSC enables the slave ATM switch to do the following:
•
Participate in an MPLS network
•
Directly peer with IP routers
•
Support the IP features in Cisco IOS software
The MPLS LSC supports highly scalable integration of MPLS (IP+ATM) services by using a direct peer
relationship between the ATM switch and MPLS routers. This direct peer relationship removes the
limitation on the number of IP edge routers (typical of traditional IP-over-ATM networks), allowing
service providers to meet growing demands for IP services. The MPLS LSC also supports direct and
rapid implementation of advanced IP services over ATM networks using ATM switches.
MPLS combines the performance and VC capabilities of Layer 2 (data link layer) switching with the
scalability of Layer 3 (network layer) routing capabilities. This combination enables service providers
to deliver solutions for managing growth, providing differentiated services, and leveraging existing
networking infrastructures.
The MPLS LSC architecture provides the following flexibility:
•
Run applications over any combination of Layer 2 technologies
•
Support any Layer 3 protocol while scaling the network to meet future needs
By deploying the MPLS LSC across large enterprise networks or wide area networks, you can achieve
the following benefits:
•
Save money by using existing ATM and routing infrastructures
•
Grow revenue using MPLS-enabled services
•
Increase productivity through enhanced network scalability and performance
MPLS LSC Functional Description
The MPLS LSC is an LSR that is configured to control the operation of a separate ATM switch. Together,
the MPLS LSC and the controlled ATM switch function as a single ATM MPLS router (ATM-LSR).
Cisco IOS Switching Services Configuration Guide
XC-113
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
Figure 36 shows the functional relationship between the MPLS LSC and the ATM switch that it controls.
MPLS Label Switch Controller and Controlled ATM Switch
Label switch controller
VSI
Master control port/
switch control port
Controlled ATM switch
LC-ATM
interface
Other label controlled
or nonlabeled controlled
router interfaces
LC-ATM interface
LC-ATM
interface
S6867
Figure 36
The following routers can function as an MPLS LSC:
•
Cisco 7200 series router
•
Cisco 6400 Universal Access Concentrator (UAC)
The following ATM switches can function with the Cisco 7200 series router as the controlled ATM
switch:
Note
•
Cisco BPX 8600, 8650 (which includes a Cisco 7204 router), and 8680
•
Cisco IGX 8410, 8420, and 8430
QoS is not an available feature with the IGX series ATM switches.
The MPLS LSC controls the ATM switch by means of the VSI, which runs over an ATM link connecting
the two devices.
The dotted line in Figure 36 represents the logical boundaries of the external interfaces of the MPLS
LSC and the controlled ATM switch, as discovered by the IP routing topology. The controlled ATM
switch provides one or more XTagATM interfaces at this external boundary. The MPLS LSC can
incorporate other label controlled or nonlabel controlled router interfaces.
MPLS LSC benefits are as follows:
•
IP-ATM integration—Enables ATM switches to directly support advanced IP services and protocols,
thereby reducing operational costs and bandwidth requirements, while at the same time decreasing
time-to-market for new services.
•
Explicit routing—Provides Layer 2 VCs to gigabit router backbones and integrated IP+ATM
environments, including support for explicit routing and provisioning of IP VPN services.
•
SVPNs—Supports IP-based VPNs on either a Frame Relay or ATM backbone, an integrated
IP-ATM backbone, or a gigabit router backbone.
Cisco IOS Switching Services Configuration Guide
XC-114
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
Using Controlled ATM Switch Ports as Router Interfaces
In the LSC, the XTagATM ports on the controlled ATM switch are used as a Cisco IOS interface type
called extended Label ATM (XTagATM). To associate these XTagATM interfaces with particular
physical interfaces on the controlled ATM switch, use the extended-port interface configuration
command.
Figure 37 shows a typical MPLS LSC configuration that controls three ATM ports on a Cisco BPX
switch: ports 6.1, 6.2, and 12.2. These corresponding XTagATM interfaces were created on the MPLS
LSC and associated with the corresponding ATM ports on the Cisco BPX switch by means of the
extended-port command.
Figure 37
Typical MPLS LSC and BPX Configuration
Label Switch Controller
(7200 series)
XTagATM61
XTagATM62
XTagATM122
extended-port a1/0
BPX 6.1
extended-port a1/0
BPX 6.2
extended-port a1/0
BPX 12.2
Master control port
ATM1/0
tag-control-protocol vsi
Switch Control Protocol
(Virtual Switch Interface)
Switch Control
Port (12.1)
Controlled Switch
(BPX)
6.2
12.2
S6856
6.1
Figure 37 shows the following:
•
An additional port on the Cisco BPX switch (port 12.1) acts as the switch control port
•
An ATM interface (ATM1/0) on the MPLS LSC acts as the master control port
Using the MPLS LSC as a Label Edge Device
Note
Using the MPLS LSC as a label edge device is not recommended. Using the MPLS LSC as a label
edge device introduces unnecessary complexity to the configuration. Refer to the tag-switching atm
disable-headend-vc command in the Cisco IOS Switching Services Command Reference to disable
edge LSR functionality on the LSC.
Cisco IOS Switching Services Configuration Guide
XC-115
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
The MPLS LSC can perform as label edge device for the following purposes:
•
Function simultaneously as a controller for an ATM switch and as a label edge device. Traffic can
be forwarded between a router interface and an interface on the controlled switch, and between two
XTagATM interfaces on the controlled switch.
•
Perform label imposition and disposition and serve as the headend or tailend of a label-switched path
tunnel.
However, when the MPLS LSC acts as a label edge device, it is limited by the following factors:
•
Label space for LSC-terminated VCs is limited by the number of VCs supported on the control link.
•
Packets are process switched between the LSC edge and an XTagATM interface.
•
Throughput depends on the following factors:
– The slave switch VSI partition configuration of the maximum cells per second for the master
control port interface and the XTagATM interface.
– SAR limitations of the ATM Lite (PA-A1) and ATM Deluxe (PA-A3) and process switching.
– CPU utilization for the LSC and edge LSR functionality.
Creating Virtual Trunks
Virtual trunks provide connectivity for Cisco WAN MPLS switches through an ATM cloud, as shown in
Figure 38. Because several virtual trunks can be configured across a given private or public physical
trunk, virtual trunks provide a cost-effective means of connecting across an entire ATM network.
The ATM equipment in the cloud must support virtual path switching and transmission of ATM cells
based solely on the VPI in the ATM cell header. The VPI is provided by the ATM cloud administrator
(that is, by the service provider).
Typical ATM Hybrid Network with Virtual Trunks
Figure 38 shows three Cisco WAN MPLS switching networks, each connected to an ATM network by a
physical line. The ATM network links all three of these subnetworks to every other subnetwork with a
fully meshed network of virtual trunks. In this example, each physical interface is configured with two
virtual trunks.
Cisco IOS Switching Services Configuration Guide
XC-116
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
Figure 38
Typical ATM Hybrid Network Using Virtual Trunks
MPLS
MPLS
Physical
interface
Virtual
trunk
MPLS
33962
ATM
Benefits of virtual trunks are as follows:
•
Reduced costs—By sharing the resources of a single physical trunk among a number of virtual
(logical) trunks, each of the virtual trunks provided by the public carrier needs to be assigned only
as much bandwidth as needed for that interface, rather than the full T3, E3, OC-3, or OC-12
bandwidth of an entire physical trunk.
•
Migration of MPLS services into existing networks—VSI virtual trunks allow MPLS services to be
carried over part of a network that does not support MPLS services. The part of the network that
does not support such services may be a public ATM network, for example, that consists of switches
that are not MPLS-enabled.
Virtual Trunk Configuration
A virtual trunk number (slot number.port number.trunk number) differentiates the virtual trunks found
within a physical trunk port. In Figure 39, three virtual trunks (4.1.1, 4.1.2, and 4.1.3) are configured on
a physical trunk that connects to the port 4.1 interface of a BXM switch.
Cisco IOS Switching Services Configuration Guide
XC-117
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
Figure 39
Virtual Trunks Configured on a Physical Trunk
4.1.1 (virtual trunk)
4.1.2 (virtual trunk)
4.1.3 (virtual trunk)
Physical trunk
(slot4 port 1)
4.1.31 (virtual trunk)
33963
.
.
.
These virtual trunks are mapped to the XTagATM interfaces on the LSC. On the XTagATM interface,
you configure the respective VPI value using the tag-switching atm vp-tunnel vpi interface command.
This VPI should match the VPI in the ATM network. The LVCs are generated inside this Virtual Path
(VP), and this VP carries the LVCs and their traffic across the network.
Virtual Trunk Bandwidth
The total bandwidth of all the virtual trunks on one port cannot exceed the maximum bandwidth of the
port. Trunk loading (units of load) is maintained per virtual trunk, but the cumulative loading of all
virtual trunks on a port is restricted by the transmit and receive rates for the port.
Virtual Trunk Features
The maximum number of virtual trunks that can be configured per card equals the number of virtual
interfaces on the BPX or IGX switch. The following lists virtual interface support for BXM and UXM:
•
The BXM supports 32 virtual interfaces; hence, it supports up to 32 virtual trunks. Accordingly, you
can have interfaces ranging from XTagATM411 to XtagATM4131 on the same physical interface.
•
The UXM supports 16 virtual interfaces. You can have interfaces ranging from XTagATM411 to
XTagATM 4116.
Using LSC Redundancy
The following sections explain how LSC redundancy works:
•
LSC Redundancy Architecture
•
General Redundancy Operational Modes
•
How LSC Redundancy Differs from Router and Switch Redundancy
•
How the LSC, ATM Switch, and VSI Work Together
•
Implementing LSC Redundancy
•
Reducing the Number of LVCs for LSC Redundancy
Cisco IOS Switching Services Configuration Guide
XC-118
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
LSC Redundancy Architecture
LSC redundancy allows you to create a highly reliable IP network, one whose reliability is nearly
equivalent to that provided by Hot Standby routing. Instead of using Hot Standby routing processes to
create redundancy, this method uses a combination of LSCs, the VSI, and IP routing paths with the same
cost path for hot redundancy, or different costs for warm redundancy. The VSI allows multiple control
planes (MPLS, Private Network-Network Interface (PNNI), and voice) to control the same switch. Each
control plane controls a different partition of the switch.
In the LSC redundancy model, two independent LSCs control the different partitions of the switch. Thus,
two separate MPLS control planes set up connections on different partitions of the same switch. This is
where LSC redundancy differs from Hot Standby redundancy: the LSCs do not need copies of the other
internal state to create redundancy; the LSCs control the partitions of the switch independently.
A single IP network consists of switches with one LSC (or a Hot Standby pair of LSCs) and MPLS edge
LSRs.
If you change that network configuration by assigning two LSCs per switch, you form two separate
MPLS control planes for the network. You logically create two independent parallel IP subnetworks
linked at the edge.
If the two LSCs on each switch are assigned identical shares of switch resources and links, the two
subnetworks are identical. You have two identical parallel IP subnetworks on virtually the same
equipment, which would otherwise support only one network.
For example, Figure 40 shows a network of switches that each have two LSCs. MPLS edge LSRs are
located at the edge of the network, to form a single IP network. The LSCs on each switch have identical
shares of switch resources and links, which makes the networks identical. In other words, there are two
identical parallel IP subnetworks.
Figure 40
LSC Redundancy Model
Physical LSC redundant network
LSC-1
LSC-2
ATM switch
LSC-3
LSC-4
ATM switch
Edge LSR
Edge LSR
Logical equivalent
ATM-LSR-1
ATM-LSR-3
Edge LSR
ATM-LSR-2
ATM-LSR-4
35149
Edge LSR
Cisco IOS Switching Services Configuration Guide
XC-119
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
Part of the redundancy model includes edge LSRs, which link the two networks at the edge.
If the network uses OSPF or a similar IP routing protocol with an equal cost on each path, then there are
at least two equally viable paths from every edge LSR to every other edge LSR. The OSPF equal-cost
multipath distributes traffic evenly on both paths. Therefore, MPLS sets up two identical sets of
connections for the two MPLS control planes. IP traffic travels equally across the two sets of
connections.
Note
The LSC redundancy model works with any routing protocol. For example, you can use OSPF or
IS-IS. Also, you can use both the TDP and the LDP.
With the LSC redundancy model, if one LSC on a switch fails, IP traffic uses the other path, without
needing to establish new links. LSC redundancy does not require the network to set up new connections
when a controller fails. Because the connections to the other paths have already been established, the
interruption to the traffic flow is negligible. The LSC redundancy model is as reliable as networks that
use Hot Standby controllers. LSC redundancy requires hardware like that used by Hot Standby
controllers. However, the controllers act independently, rather than in Hot Standby mode. For LSC
redundancy to work, the hardware must have connection capacity for doubled-up connections.
If an LSC fails and LSC redundancy is not present, IP traffic halts until other switches break their present
connections and reroute traffic around the failed controller. The stopped IP traffic results in undesirable
unreliability.
General Redundancy Operational Modes
The LSC redundancy model allows you to use the following four operational models. Most other
redundancy models cannot accommodate all of these redundancy models.
•
Transparent Mode—The primary and secondary redundant systems have the same copies of the
image and startup configurations. When one system fails, the other takes over, and the operations
are identical. However, this mode risks software failures, because both systems use the same
algorithms. A software problem on the primary system is likely to affect the secondary system as
well.
•
Upgrade mode—You can upgrade the image or configuration of the redundant system, without
rebooting the entire system. You can use this mode to change the resources between different
partitions of the slave ATM switch.
•
Nontransparent mode—The primary and secondary systems have different images or configurations.
This mode is more reliable than transparent mode, which loads the same software on both
controllers. In nontransparent mode, the use of different images and configurations reduces the risk
of both systems encountering the same problem.
•
Experimental mode—You load an experimental version of the image or configuration on the
secondary system. You can use experimental mode when you want to test the new images in a real
environment.
How LSC Redundancy Differs from Router and Switch Redundancy
In traditional IP router networks, network managers ensure reliability by creating multiple paths through
the network from every source to every destination. If a device or link on one path fails, IP traffic uses
an alternate path to reach its destination.
Cisco IOS Switching Services Configuration Guide
XC-120
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
Router Redundancy
Because routers need not establish a VC to transfer data, they are inherently connectionless. When a
router discovers a failed device or link, it requires approximately less than 1 second to reroute traffic
from one path to another.
Routers can incorporate a warm or Hot Standby routing process to increase reliability. The routing
processes share information about the routes to direct different streams of IP traffic. They need not keep
or share connection information. Routers can also include redundant switch fabrics, backplanes, power
supplies, and other components to decrease the chances of node failures.
ATM, Frame Relay, and Circuit Switch Redundancy
ATM, Frame Relay, and circuit switch networks transfer data by establishing circuits or VCs. To ensure
the transfer of data in switches, network managers incorporate redundant switch components. If any
component fails, a spare component takes over. Switches can have redundant line cards, power supplies,
fans, backplanes, switch fabrics, line cards, and control cards. The following describes these redundant
components:
•
The redundant backplanes include all the hardware to operate two backplanes and to switch to the
backup backplane if one fails.
•
Redundant line cards protect against failed links. If a link to a line card fails, the redundant line card
takes over. To create redundant line cards, you must program the same connection information into
both line cards. This ensures that the circuits or VCs are not disrupted when the new line card takes
over.
•
The redundant switch fabric must also have the same connection information as the active switch
fabric.
A software application usually monitors the state of the switches and their components. If a problem
arises, the software sets an alarm to bring attention to the faulty component.
The redundant switch hardware and software are required, because switches take some time to reroute
traffic when a failure occurs. Switches can have connection routing software, such as Cisco automatic
connection routing, PNNI, or MPLS. However, rerouting the connections in a switch takes much more
time than rerouting traffic in a router network. Rerouting connections in a switch requires calculating
routes and reprogramming some hardware for each connection. In router networks, large aggregates of
traffic can be rerouted simultaneously, with little or no hardware programming. Therefore, router
networks can reroute traffic more quickly and easily than connection oriented networks. Router networks
rely on rerouting techniques to ensure reliability. Connection-oriented networks use rerouting only as a
last resort.
General Hot/Warm Standby Redundancy in Switches
Network managers can install redundant copies of the connection routing software for ATM and Frame
Relay switches on a redundant pair of control processors.
With Hot Standby redundancy, the active process sends its state to the spare process to keep the spare
process up to date in case it needs to take over. The active process sends the state information to the spare
process or writes the state to a disk, where both processes can access the information. In either case, the
state information is shared between controllers. Because the state of the network routing tables changes
frequently, the software must perform much work to maintain consistent routing states between
redundant pairs of controllers.
With Warm Standby redundancy, the state information is not shared between the active and spare
processes. If a failure occurs, the spare process resets all of the connections and reestablishes them.
Reliability decreases when the spare resets the connections. The chance of losing data increases.
Cisco IOS Switching Services Configuration Guide
XC-121
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
LSC Redundancy
Connecting two independent LSCs to each switch by the VSI creates two identical subnetworks.
Multipath IP routing uses both subnetworks equally. Thus, both subnetworks have identical connections.
If a controller in one subnetwork fails, the multipath IP routing diverts traffic to the other path. Because
the connections already exist in the alternate path, the reroute time is very fast. The LSC redundancy
model matches the reliability of networks with Hot Standby controllers, without the difficulty of
implementing Hot Standby redundancy.
One benefit of implementing the LSC redundancy model is that you eliminate the single point of failure
between the LSC and the ATM switch it controls. If one LSC fails, the other LSC takes over and routes
the data on the other path. The following sections explain the other benefits of LSC redundancy.
LSC Redundancy Does Not Use Shared States or Databases
In the LSC redundancy model, the LSCs do not share states or databases, which increases reliability.
Sometimes, when states and databases are shared, an error in the state or database information can cause
both controllers to fail simultaneously.
Also, new software features and enhancements do not affect LSC redundancy. Because the LSCs do not
share states or database information, you need not worry about ensuring redundancy during every step
of the update.
LSC Redundancy Allows Different Software Versions
The LSCs work independently and there is no interaction between the controllers. They do not share the
state or database of the controller, as other redundancy models require. Therefore, you can run different
versions of the Cisco IOS software on the LSCs, which provides the following advantages:
Note
•
You can test the features of the latest version of software without risking reliability. You can run the
latest version of the Cisco IOS software on one LSC and an older version of the Cisco IOS software
on a different LSC. If the LSC running the new Cisco IOS software fails, the LSC running the older
software takes over.
•
Running different versions of the Cisco IOS software reduces the chance of having both controllers
fail. If you run the same version of the Cisco IOS software on both controllers and that version
contains a problem, it could cause both controllers to fail. Running different versions on the
controllers eliminates the possibility of each controller failing because of the same problem.
Using different Cisco IOS software version on different LSCs is recommended only as a temporary
measure. Different versions of Cisco IOS software in a network could be incompatible, although it
is unlikely. For best results, run the same version of Cisco IOS software on all devices.
LSC Redundancy Allows Different Hardware
You can use different models of routers in this LSC redundancy model. For example, one LSC can be a
Cisco 7200 series router, and the other LSC can be a Cisco 7500 series router. Using different hardware
in the redundancy model reduces the chance that a hardware fault would interrupt network traffic.
LSC Redundancy Allows You to Switch from Hot to Warm Redundancy Immediately
You can implement hot or warm redundancy and switch from one model to the other. Hot redundancy
can use redundant physical interfaces, slave ATM switches with Y redundancy, and redundant LSCs to
enable parallel paths and near-instant failover. If your resources are limited, you can implement warm
Cisco IOS Switching Services Configuration Guide
XC-122
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
redundancy, which uses only redundant LSCs. When one controller fails, the backup controller requires
some reroute time. As your network grows, you can switch from hot to warm redundancy and back,
without bringing down the entire network.
Other redundancy models require complex hardware and software configurations, which are difficult to
alter when you change the network configuration. You must manually change the connection routing
software from Hot Standby mode to Warm Standby mode.
LSC Redundancy Provides an Easy Migration from Standalone LSCs to Redundant LSCs
You can migrate from a standalone LSC to a redundant LSC and back again without affecting network
operations. Because the LSCs work independently, you can add a redundant LSC without interrupting
the other LSC.
LSC Redundancy Allows Configuration Changes in a Live Network
The hot LSC redundancy model provides two parallel, independent networks. Therefore, you can disable
one LSC without affecting the other LSC. This feature has the following benefits:
•
LSC redundancy model facilitates configuration changes and updates. After you finish with
configuration changes or image upgrades to the LSC, you can add it back to the network and resume
the LSC redundancy model.
•
The redundancy model protects the network during partitioning of the ATM switch. You can disable
one path and perform partitioning on that path. While you are performing the partitioning, data uses
the other path. The network is safe from the effects of the partitioning, which include breaking or
establishing LVC connections.
LSC Redundancy Provides Fast Reroute in IP+ATM Networks
The hot LSC redundancy model offers redundant paths for every destination. Therefore, reroute recovery
is very fast. Other rerouting processes in IP+ATM networks require many steps and take longer to
reroute.
In normal IP+ATM networks, the reroute process consists of the following steps:
•
Detecting the failure
•
Converging the Layer 2 routing protocols
•
Completing label distribution for all destinations
•
Establishing new connections for all destinations
After this reroute process, the new path is ready to transfer data. Rerouting data using this process takes
time.
The hot LSC redundancy method allows you to quickly reroute data in IP+ATM networks without using
the normal reroute process. When you incorporate hot LSC redundancy, you create parallel paths. Every
destination has at least one alternative path. If a device or link along the path fails, the data uses the other
path to reach its destination. The hot LSC redundancy model provides the fastest reroute recovery time
for IP+ATM networks.
Cisco IOS Switching Services Configuration Guide
XC-123
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
How the LSC, ATM Switch, and VSI Work Together
In an LSC implementation, the LSC and slave ATM switch have the following characteristics:
•
The LSC runs all of the control protocols.
•
The ATM switch forwards the data.
•
Each physical interface on the slave ATM switch maps to an XTagATM interface on the LSC. Each
XTagATM interface has a dedicated LDP session with a corresponding interface on the edge. The
XTagATM interfaces are mapped in the routing topology, and the ATM switch behaves as a router.
•
The LSC can also function as an edge LSR. The data for the edge LSR passes through the control
interface of the router.
If a component on the LSC fails, the IP switching function of the ATM switch is disabled. The standalone
LSC is the single point of failure.
The VSI implementation includes the following characteristics:
•
The VSI allows multiple, independent control planes to control a switch. The VSI ensures that the
control processes (Signaling System 7 (SS7), MPLS, PNNI, and so on) can act independently of
each other by using a VSI slave process to control the resources of the switch and apportion them to
the correct control planes.
•
In MPLS, each physical interface on the slave ATM switch maps to an XTagATM interface on the
LSC through the VSI. In other words, physical interfaces are mapped to their respective logical
interfaces.
•
The routing protocol on the LSC generates route tables entries. The master sends connection
requests and connection release requests to the slave.
•
The slave sends the configured bandwidth parameters for the ATM switch interface to the master in
the VSI messages. The master includes the bandwidth information in the link-state topology. You
can override these bandwidth values by manually configuring the bandwidth on the XTagATM
interfaces.
Implementing LSC Redundancy
To make an LSC redundant, you can partition the resources of the slave ATM switch, implement a
parallel VSI model, assign redundant LSCs to each switch, and create redundant LSRs. The following
sections explain these steps.
Cisco IOS Switching Services Configuration Guide
XC-124
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
Partitioning the Resources of the ATM Switch
In the LSC redundancy model, two LSCs control different partitions of the ATM switch. When you
partition the ATM switch for LSC redundancy, use the following guidelines:
•
Make the MPLS partitions identical. If you create two partitions, make sure both partitions have the
same amount of resources. (You can have two MPLS VSI partitions per switch.) Use the cnfrsrc
router configuration command to configure the partitions.
•
If the partitions are on the same switch card, perform the following steps:
– Create different control VCs for each partition. For example, there can be only one (0, 32)
control VC on the XTagATM interface. To map two XTagATM interfaces on the same ATM
switch interface, use a different control VC for the second LSC. Use the tag-switching atm
control-vc interface command.
– Create the LVC on the XTagATM interfaces using nonintersecting VPI ranges. Use the
tag-switching atm vpi interface command.
•
Specify the bandwidth information on the XTagATM interfaces. Normally, this information is read
from the slave ATM switch. When you specify the bandwidth on the XTagATM interface, the value
you enter takes precedence over the switch-configured interface bandwidth.
•
Configure the logical channel number (LCN) ranges for each partition according to the expected
number of connections.
See the documentation on the Cisco BPX 8600 series or Cisco IGX 8400 series switches for more
information about configuring the slave ATM switch.
Implementing the Parallel VSI Model
The parallel VSI model means that the physical interfaces on the ATM switch are shared by more than
one LSC. For instance, LSC1 in Table 26 maps VSI slave interfaces 1 to N to the ATM switch physical
interfaces 1 to N. LSC2 maps VSI slave interfaces to the ATM switch’s physical interfaces 1 to N. LSC1
and LSC2 share the same physical interfaces on the ATM switch. With this mapping, you achieve fully
meshed independent masters.
Figure 41 shows four ATM physical interfaces mapped as four XTagATM interfaces at LSC1 and LSC2.
Each LSC is not aware that the other LSC is mapped to the same interfaces. Both LSCs are active all the
time. The ATM switch runs the same VSI protocol on both partitions.
XTagATM Interfaces
LSC 1
XtagATM
interfaces
Control
port
LSC 2
Control
port
VSI 1 VSI 2
ATM Switch
48468
Figure 41
Cisco IOS Switching Services Configuration Guide
XC-125
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
Adding Interface Redundancy
To ensure reliability throughout the LSC redundant network, you can also implement:
•
Redundant interfaces between the edge LSR and the ATM-LSR. Most edge LSRs are collocated with
the LSCs. Creating redundant interfaces between the edge LSRs and the ATM LSRs reduces the
chance of a disruption in network traffic by providing parallel paths.
•
Redundant virtual trunks and VP tunnels between slave ATM switches. To ensure hot redundancy
between the ATM switches, you can create redundant virtual trunks and VP tunnels. See Figure 42.
Interface Redundancy
LSC
Edge LSR
LSC
ATM switch
LSC
Virtual Trunk/
VP Tunnel
ATM
networks
LSC
Edge LSR
LSC
Edge LSR
Virtual trunk
Physical interface
Virtual trunk/
VP tunnel ATM switch
LSC
ATM switch
35150
Figure 42
Implementing Hot or Warm LSC Redundancy
Virtually any configuration of switches and LSCs that provides hot redundancy can also provide warm
redundancy. You can also switch from warm to hot redundancy with little or no change to the links,
switch configurations, or partitions.
Hot and warm redundancy differ in the following ways:
•
Hot redundancy uses both paths to route traffic. You set up both paths using equal-cost multipath
routing, so that traffic is load balanced between the two paths. As a result, hot redundancy uses twice
the number of MPLS label VCs as warm redundancy.
•
Warm redundancy uses only one path at a time. You set up the paths so that one path has a higher
cost than the other. Traffic only uses one path and the other path is a backup path.
The following sections explain the two redundancy models in detail.
Implementing Hot LSC Redundancy
Hot redundancy provides near-instant failover to the other path when an LSC fails. When you set up hot
redundancy, both LSCs are active and have the same routing costs on both paths. To ensure that the
routing costs are the same, run the same routing protocols on the redundant LSCs.
In hot redundancy, the LSCs run parallel and independent LDPs. At the edge LSRs, when the LDP has
multiple routes for the same destination, it requests multiple labels. It also requests multiple labels when
it needs to support QoS. When one LSC fails, the labels distributed by that LSC are removed.
Cisco IOS Switching Services Configuration Guide
XC-126
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
To achieve hot redundancy, you can implement the following redundant components:
•
Redundant physical interfaces between the edge LSR and the ATM-LSR to ensure reliability in case
one physical interface fails.
•
Redundant interfaces or redundant VP tunnels between the ATM switches.
•
Slave ATM switches, such as the BPX 8650, can have redundant control cards and switch fabrics. If
redundant switch fabrics are used and the primary switch fails, the other switch fabric takes over.
•
Redundant LSCs.
•
The same routing protocol running on both LSCs. (You can have different tag or label distribution
protocols.)
Figure 43 shows one example of how hot LSC redundancy can be implemented.
Figure 43
Hot LSC Redundancy
Physical LSC redundant network
LSC-1
LSC-2
ATM switch
LSC-3
LSC-4
ATM switch
Edge LSR
Edge LSR
Logical equivalent
ATM-LSR-1
ATM-LSR-3
Edge LSR
ATM-LSR-2
ATM-LSR-4
35149
Edge LSR
Implementing Warm LSC Redundancy
To achieve warm redundancy, you need only redundant LSCs. You need not run the same routing
protocols or distribution protocols on the LSCs.
Note
You can use different routing protocols on parallel LSCs. However, you do not get near-instant
failover. The failover time includes the time it takes to reroute the traffic, plus the LDP bind request
time. If the primary routing protocol fails, the secondary routing protocol finds new routes and
creates new LVCs. An advantage to using different routing protocols is that the ATM switch uses
fewer resources and offers more robust redundancy.
Cisco IOS Switching Services Configuration Guide
XC-127
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
If you run the same routing protocols, specify a higher cost for the interfaces on the backup LSC to allow
the data to use only the lower-cost path and also saves resources on the ATM switch (the edge LSR
requests LVCs only through the lower-cost LSC). When the primary LSC fails, the edge LSR uses the
backup LSC and creates new paths to the destination. Creating new paths requires reroute time and LDP
negotiation time.
Figure 44 shows one example of how warm LSC redundancy can be implemented.
Figure 44
Warm LSC Redundancy
Physical LSC redundant network
LSC-2
LSC-1
LSC-4
Virtual trunk/
VP tunnel 10
Virtual trunk/
VP tunnel 4
Edge LSR
LSC-3
ATM switch
Virtual trunk/
VP tunnel 8
Virtual trunk/
VP tunnel 12
Virtual trunk/
VP tunnel 16
ATM switch
Virtual trunk/
VP tunnel 20
Edge LSR
Note: Tunnels are virtual interfaces.
Physical interfaces are marked by thin lines.
Logical equivalent
ATM-LSR-1
ATM-LSR-3
Edge LSR
35152
Edge LSR
ATM-LSR-2
ATM-LSR-4
Reducing the Number of LVCs for LSC Redundancy
By default, an LSC includes edge LSR functionality, which means that the LSC can act as a label edge
device. To achieve the edge LSR functionality, the LSC creates an LSP for each destination in the route
table.
With LSC redundancy, if 400 destinations exist in the network, each redundant LSC adds 400 headend
VCs. In hot redundancy mode, 800 headend VCs are created for the LSCs. If the LSCs are not edge
LSRs, then 800 LVCs are wasted.
The number of LVCs increases as the number of redundant LSCs increases. In the case of a VC-merged
system, the number of LVCs can be low. However, in non-VC-merged system, the number of LVCs can
be high. To reduce the number of LVCs, disable the edge LSR functionality in the LSC. Enter the
tag-switching atm disable headend-vc interface command to disable the edge LSR functionality on the
LSC and prevent the creation of headend VCs.
Cisco IOS Switching Services Configuration Guide
XC-128
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
Note
As an alternative to the tag-switching atm disable headend-vc interface command, you can issue
the tag-switching request-tags for interface command with an access list to save LVC space.
For more information on reducing the number of LVCs, see the “Reducing the Number of Label Switch
Paths Created in an MPLS Network” section.
Implementation Considerations
The following sections explain items that need to be considered when implementing hot or warm LSC
redundancy in a network.
Hot LSC Redundancy Considerations
The following list explains the items you need to consider when implementing hot LSC redundancy:
•
LSC hot redundancy needs parallel paths. Specifically, there must be the capacity for at least two
end-to-end parallel paths traveling from each source to each destination. Each path is controlled by
one of a pair of redundant LSCs.
•
LSPs for the destinations are initiated from the edge LSR. The edge LSR initiates multiple paths for
a destination only if it has parallel paths to its next hop. Therefore, it is important to have parallel
paths from the edge LSR. You can achieve parallel paths by having two physical links from the edge
LSR or by having two separate VP tunnels on one link.
•
Hot redundancy protection extends from the edge LSR only as far as parallel paths are present. So,
it is best if parallel paths are present throughout the entire network.
•
Hot redundancy increases the number of VCs used in the network. Each physical link with two VSI
partitions has twice the number of VCs used than would otherwise be the case. Various techniques
can be used to alleviate VC usage. The use of unnumbered links (“ip unnumbered” in the Cisco IOS
link configuration) reduces the number of routes in the routing table and hence the number of VCs
required. On the LSCs, you can use the tag-switching atm disable headend-vc interface command
to disable edge LSR functionality on the LSC and also reduce the number of VCs used. The
tag-switching request-tags for interface command with an access list also restricts the creation of
LVCs.
Warm LSC Redundancy Considerations
The following list explains the items you need to consider when implementing warm LSC redundancy:
•
LSC warm redundancy needs a single active path between the source and destination. However,
there is also a requirement for end-to-end parallel paths, as in the hot redundancy case. Only one
path has an active LSP for the destination. In the event of the failure, the other path is established,
with some delay due to rerouting.
•
The number of VCs in the network does not change with the warm redundancy.
•
Hot LSC redundancy achieves failure recovery with little loss of traffic. However, hot redundancy
doubles the VC requirements in the network. Warm LSC redundancy requires the same number of
VCs as a similar network without LSC redundancy. However, traffic loss due to a failure is greater;
traffic may be lost for a period of seconds during rerouting.
Cisco IOS Switching Services Configuration Guide
XC-129
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
Note
The precise traffic loss depends on the type of failure. If the failure is in an LSC, the LSPs controlled
by that LSC typically remain connected for some time. Traffic can still flow successfully on the
“failed” path until the edge LSRs switch all traffic to the alternate path (which might occur tens of
seconds later, depending on routing protocol configuration). The only traffic loss might occur in the
edge LSR when traffic changes to the new path, which typically takes a few milliseconds or less.
Reducing the Number of Label Switch Paths Created in an MPLS Network
You can use two methods to reduce the number of LSPs created in an MPLS network:
•
Disable LSPs from being created from a edge LSR or LSC to a destination IP address. Use the
tag-switching request-tags for interface command. Specify the destination IP addresses that you
want to disable from creating LSPs. This command allows you to permit creation of some LSPs,
while preventing the creation of others.
•
Disable the LSC from acting as an edge LSR by using the tag-switching atm disable headend-vc
interface command. This command removes all LSPs that originate at the MPLS LSC and disables
the LSC from acting as an edge LSR.
Using an Access List to Disable Creation of LSPs to Destination IP Addresses
You can prevent LSPs from being created between edge LSRs and LSCs to prevent the unnecessary use
of LVC resources in a slave ATM switch. Use the tag-switching request-tags for interface command
with an access list to disable the creation of the LSPs.
Some LSPs are often unnecessary between some edge LSRs in an MPLS network. Every time a new
destination is created, LSPs are created from all edge LSRs in the MPLS network to the new destination.
You can create an access list at an edge LSR or LSC to restrict the destinations for which a
downstream-on-demand request is issued.
For example, Figure 45 is an MPLS ATM network that consists of the following elements:
•
The PE routers in the VPN require LSPs to communicate with each other.
•
All the PE routers are in network 1 (198.x.x.x).
•
All the IGP IP addresses are in network 2 (192.x.x.x).
•
If numbered interfaces are required (for network management or other purposes), they are placed in
network 2 (192.x.x.x).
Use tag-switching request-tags for interface commands to accomplish the following tasks:
•
Allow the PE routers in network 1 to create LSPs and communicate with each other.
•
Prevent LSPs from being created in network 2.
Performing these tasks reduces the number of LSPs in the MPLS ATM cloud, which reduces the VC
usage in the cloud.
Cisco IOS Switching Services Configuration Guide
XC-130
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
Figure 45
Sample MPLS ATM Network
CE router
PE router
192.168.x.x
PE router
192.168.x.x
CE router
MPLS ATM
Network
IGP
172.16.x.x
PE router
192.168.x.x
PE router
192.168.x.x
CE router
46928
CE router
Note
When using access lists to prevent the creation of headend LVCs or LSPs, do not disable the LSC
from acting as an edge LSR with the tag-switching disable headend-vc interface command, which
prevents all LSPs from being established.
Cisco IOS Switching Services Configuration Guide
XC-131
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
The following examples of the tag-switching request tags-for interface command use Figure 46 as a
basis. The examples show different ways to disable the creation of LSPs from the LSC to the edge LSR,
and from the edge LSRs to the LSC.
Figure 46
Sample Configuration
45566
LSC
172.16.53.1
Edge LSR 1
192.168.0.1
ATM switch
Edge LSR 2
192.168.0.2
Using a Numbered Access List
The following examples use a numbered access list to restrict creation of LSPs.
Preventing LSPs from the LSC to the Edge LSRs
The following example prevents LSPs from being established from the LSC to all 198.x.x.x destinations.
However, transit LSPs are allowed between 198.x.x.x destinations. Add the following commands to the
LSC configuration:
tag-switching request-tags for 1
access-list 1 deny 198.0.0.0 0.255.255.255
access-list 1 permit any
Preventing LSPs from the Edge LSRs to the LSC
The following example prevents headend LVCs from being established from edge LSR 1 and edge LSR
2 to the LSC (192.x.x.x). However, transit LSPs are allowed between 198.x.x.x destinations. Add the
following commands to the edge LSR 1 and 2 configurations:
tag-switching request-tags for 1
access-list 1 deny 192.0.0.0 0.255.255.255
access-list 1 permit any
Using a Named Access List
The following examples use a named access list to perform the same tasks as in the previous examples:
tag-switching request-tags for nolervcs
ip access-list standard nolervcs
deny
198.0.0.0 0.255.255.255
permit any
tag-switching request-tags for nolervcs
ip access-list standard nolervcs
deny 192.0.0.0 0.255.255.255
permit any
Cisco IOS Switching Services Configuration Guide
XC-132
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
Specifying Exact Match IP Addresses with an Access List
The following examples use exact IP addresses to perform the same tasks as in the previous examples:
tag-switching
access-list 1
access-list 1
access-list 1
request-tags for 1
deny 198.5.0.1 0.0.0.0
deny 198.5.0.2 0.0.0.0
permit any
tag-switching request-tags for 1
access-list 1 deny 192.6.53.1 0.0.0.0
access-list 1 permit any
Instead of configuring an access list on the LSC, you can issue the tag-switching atm
disable-headend-vc interface command to disable the creation of LSPs. This command works only with
LSCs.
Disabling the LSC from Acting as an Edge LSR
To remove all LSPs from the MPLS LSC and disable its ability to function as an edge LSR, you can use
either of the following interface commands:
•
tag-switching atm disable-headend-vc
•
tag-switching request-tags for
Disabling the LSC from acting as an edge LSR causes the LSC to stop initiating LSPs to any destination.
Therefore, the number of LVCs used in the network is reduced. The LSC can still terminate tailend
LVCs, if required.
With downstream on demand, LVCs are depleted with the addition of each new node. These commands
save resources by disabling the LSC from setting up unwanted LSPs. The absence of those LSPs allows
traffic to follow the same path as control traffic.
The following example uses the tag-switching atm disable-headend-vc interface command to disable
the LSC from functioning as an edge LSR. The following line is added to the LSC configuration:
tag-switching atm disable-headend vc
The following example uses the tag-switching request-tags for interface command to disable the LSC
from functioning as an edge LSR. The following lines are added to the LSC configuration:
tag-switching request-tags for dedicatedlsc
ip access-list standard dedicatedlsc
deny
any
Note
For a Cisco 6400 UAC with an NRP configured to function as an LSC, disable the LSC from acting
as an edge LSR. An NRP LSC should only support label switch paths through the controlled ATM
switch under VSI control.
Using the Cisco 6400 Universal Access Concentrator as an MPLS LSC
You can configure the Cisco 6400 UAC to operate as an MPLS LSC in an MPLS network. The hardware
that supports MPLS LSC functionality on the Cisco 6400 UAC is described in the following sections.
Cisco IOS Switching Services Configuration Guide
XC-133
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
Note
If you configure a Cisco 6400 UAC with a node resource processor (NRP) to function as an LSC,
disable MPLS edge LSR functionality. Refer to the tag-switching atm disable-headend-vc
command in the Cisco IOS Switching Services Command Reference for information on disabling
MPLS edge LSR functionality. An NRP LSC should support transit label switch paths only through
the controlled ATM switch under VSI control.
Cisco 6400 UAC Architectural Overview
A Cisco 6400 UAC can operate as an MPLS LSC if it incorporates the following components:
•
Node switch processor (NSP)—The NSP incorporates an ATM switch fabric, enabling the Cisco
6400 UAC to function as ATM-LSR in a network. The NSP manages all the external ATM interfaces
for the Cisco 6400 UAC.
•
NRP—The NRP enables a Cisco 6400 UAC to function as an LSC. When you use the NRP as an
LSC, however, you must not configure the NRP to perform other functions.
The NRP contains internal ATM interfaces that enable it to be connected to the NSP.
However, the NRP cannot access the external ATM interfaces of the Cisco 6400 UAC. Only the
NSP can access the external ATM interfaces.
Note
•
A Cisco 6400 UAC chassis can accommodate multiple NRPs, including one dedicated to
MPLS LSC functions. You cannot use an additional NRP as an MPLS LSC. However,
you can use additional NRPs to run MPLS and perform other networking services.
ATM port adapter—The Cisco 6400 UAC uses an ATM port adapter to provide external connectivity
for the NSP.
Cisco IOS Switching Services Configuration Guide
XC-134
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
Figure 47 shows the components that you can configure to enable the Cisco 6400 UAC to function as an
MPLS LSC.
Figure 47
Cisco 6400 UAC Configured as an MPLS LSC
ATM port adapter
provides external
ATM connectivity
for NSP
NRP supports
LSC functions for
Cisco 6400 UAC
N
R
P
1
E
d
g
e
PVP
(n)
PVP
(n)
x
.
.
PVP
(n+3)
PVP
L
S
C
.
.
x
PVP
(n+3)
x
PVP
N
S
P
30787
L
S
R
N
R
P
2
Cisco 6400 UAC chassis
Additional NRPs can
support MPLS and
IP Layer 3 services
Legend: x = switch fabric
NSP supports ATM
switching functions
for Cisco 6400 UAC
Configuring Permanent Virtual Circuits and Permanent Virtual Paths
The NRP controls the slave ATM switch through the VSI protocol. The VSI protocol operates over a
PVC that you configure. The PVC is dedicated to the VCs that the VSI control channel uses.
For the NRP to control an ATM switch through the VSI, cross-connect the control VCs from the ATM
switch through the NSP to the NRP. The ATM switch (BPX) uses defined control VCs for each BXM
slot of the BPX chassis, enabling the LSC to control external XTagATM interfaces through the VSI.
Table 27 defines the PVCs that must be configured on the NSP interface connected to the BPX VSI shelf.
These PVCs are cross-connected via the NSP to the NRP VSI master control port, which is running the
VSI protocol.
For an NRP that is installed in slot 3 of a Cisco 6400 UAC chassis, the master control port would be
ATM3/0/0 on the NSP. As shown in Figure 37, the BPX switch control interface is 12.1, and the NSP
ATM port connected to this interface is the ATM interface that is cross-connected to ATM3/0/0. Because
Cisco IOS Switching Services Configuration Guide
XC-135
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
Figure 37 shows that the BXM slaves in BPX slots 6 and 12 are configured as external XTagATM ports,
the PVCs that must be cross-connected through the NSP are 0/45 for slot 6 and 0/51 for slot 12,
respectively, as outlined in Table 27.
Table 27
VSI Interface Control PVCs for BPX VSI Slave Slots
BPX VSI Slave Slot
VSI Interface Control VC
1
0/40
2
0/41
3
0/42
4
0/43
5
0/44
6
0/45
7
0/46
8
0/47
9
0/48
10
0/49
11
0/50
12
0/51
13
0/52
14
0/53
Figure 48 shows the functional relationships among the Cisco 6400 UAC hardware components and the
permanent virtual paths (PVPs) that you can configure to support MPLS LSC functionality.
Figure 48
Cisco 6400 UAC PVP Configuration for MPLS LSC Functions
VP = n from
NSP to
slave ATM switch
PVPs for
LSC functions
VP = n from
NSP to NRP
VC = 0/32 VC = 0/32
6.1
12.2
VC = 2/83
I/F = xtag2
VC = 2/83
mapped to
0/32
I/F = xtag1
VC = 2/35
mapped to
0/32
VC = 2/35
Slave ATM switch
NRP
NSP
Cisco 6400 UAC
PVP for VSI
control channel
Cisco IOS Switching Services Configuration Guide
XC-136
29752
VSI interface
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
All other MPLS LSC functions, such as routing, terminating LVCs, and LDP control VCs (default 0/32),
can be accomplished by means of a separate, manually configured PVP (see the upper shaded area in
Figure 48). The value of “n” for this manually configured PVP must be the same among all the associated
devices (the NRP, the NSP, and the slave ATM switch). Because the NSP uses VP = 0 for ATM Forum
signalling and the BPX uses VP = 1 for autoroute, the value of “n” for this PVP for MPLS LSC functions
must be greater than or equal to 2, while not exceeding an upper bound.
Note that some edge LSRs have ATM interfaces with limited VC space per virtual path (VP). For these
interface types, you define several VPs. For example, the Cisco ATM Port Adapter (PA-A1) and the AIP
interface are limited to VC range 33 through 1018. To use the full capacity of the ATM interface,
configure four consecutive VPs. Make sure the VPs are within the configured range of the BPX.
For internodal BPX connections, we suggest that you configure VPs 2 through 15; for edge LSRs, we
suggest that you configure VPs 2 through 5. (Refer to the BPX cnfrsrc command in the Cisco BPX 8600
Series documentation for examples of how to configure BPX service nodes.)
Control VC Setup for MPLS LSC Functions
After you connect the NRP, the NSP, and the slave ATM switch by means of manually configured PVPs
(as shown in Figure 48), the NRP can control the slave ATM switch as though it is directly connected to
the NRP. The NRP discovers the interfaces of the slave ATM switch and establishes the default control
VC to be used in creating MPLS VCs.
The slave ATM switch shown in Figure 48 incorporates two external ATM interfaces (labeled xtag1 and
xtag2) that are known to the NRP as XTagATM61 and XTagATM122, respectively. On interface 6.1 of
the slave ATM switch, VC = 0/32 is connected to VC 2/35 by the VSI protocol. On the NRP, VC 2/35 is
terminated on interface XTagATM61 and mapped to VC 0/32, also by means of the VSI protocol. This
mapping enables the LDP to discover MPLS LSC neighbors by means of the default control VC 0/32 on
the physical interface. On interface 12.2 of the slave ATM switch, VC 0/32 is connected to VC 2/83 by
the VSI protocol. On the NRP, VC 2/83 is terminated on interface XTagATM122 and mapped to VC 0/32.
Note that the selection of these VCs is dependent on the availability of VC space. Hence it is not
predictable which physical VC will be mapped to the external default control VC 0/32 on the XTagATM
interface. The control VC will be shown as a PVC on the LSC, as opposed to an LVC, when you enter
the Cisco IOS show xtagatm vc EXEC command.
Cisco IOS Switching Services Configuration Guide
XC-137
Multiprotocol Label Switching Overview
MPLS Label Switch Controller
Configuring the Cisco 6400 UAC to Perform Basic MPLS LSC Operations
Figure 49 shows a Cisco 6400 UAC containing a single NRP that has been configured to perform basic
MPLS LSC operations.
Figure 49
Typical Cisco 6400 UAC Configuration to Support MPLS LSC Functions
Io = 2.2.2.2 Io = 3.3.3.3
LSR1
LSR2
LDP and routing paths
between LSR1 and LSR2
Data path between
LSR1 and LSR2 for
their respective
networks
6.1
12.2
Loopback = 1.1.1.1
NRP
NSP
29753
Slave ATM switch
Cisco 6400 UAC
Note
If the NRP incurs a fault that causes it to malfunction (in a single NRP configuration), the LVCs and
routing paths pertaining to MPLS LSC functions are lost.
Note
The loopback addresses must be configured with a 32-bit mask and be included in the relevant IGP
or BGP routing protocol, as shown in the following example:
ip address 192.103.210.5 255.255.255.255
Defining the MPLS Control and IP Routing Paths
In the MPLS LSC topology shown in Figure 49, the devices labeled LSR1 and LSR2 are external to the
Cisco 6400 UAC. These devices, with loopback addresses as their respective LDP identifiers, are
connected to two separate interfaces labeled 6.1 and 12.2 on the slave ATM switch. Both LSR1 and LSR2
learn about the routes of each other from the NRP by means of the data path represented as the thick
dashed line in Figure 49. Subsequently, LVCs are established by means of LDP operations to create the
data paths between LSR1 and LSR2 through the ATM slave switch.
Both LSR1 and LSR2 learn of the loopback address of the NRP and create a data path (LVCs) from each
other that terminates in the NRP. These LVCs, called tailend LVCs, are not shown in Figure 49.
Cisco IOS Switching Services Configuration Guide
XC-138
Multiprotocol Label Switching Overview
MPLS Egress NetFlow Accounting
Disabling Edge LVCs
By default, the NRP requests LVCs for the next hop devices (the LSRs shown in Figure 49). The headend
LVCs enable the LSC to operate as an edge LSR. Because the NRP is dedicated to the slave ATM switch
by default, the headend LVCs are not required.
Note
If a Cisco 6400 UAC with an NRP is configured to function as an LSC, disable the edge LSR
functionality. An NRP LSC should support transit LSPs only through the controlled ATM switch
under VSI control. Refer to the tag-switching atm disable-headend-vc interface command in the
Cisco IOS Switching Services Command Reference to disable edge LSR functionality.
The tag-switching atm disable-headend-vc command disables the default behavior of the NRP in
setting up headend switch LVCs, thereby saving VC space.
Supporting ATM Forum Protocols
You can connect the MPLS LSC to a network that is running ATM Forum protocols while the MPLS
LSC simultaneously performs its functions. However, you must connect the ATM Forum network
through a separate ATM interface (that is, not through the master control port).
MPLS Egress NetFlow Accounting
MPLS egress NetFlow accounting allows you to capture IP flow information for packets undergoing
MPLS label disposition; that is, packets that arrive on a router as MPLS and are sent as IP.
Previous to the MPLS Egress NetFlow Accounting feature, you captured NetFlow data only for flows
that arrived on the packet in IP format. When an edge router performed MPLS label imposition (received
an IP packet and sent it as an MPLS packet), NetFlow data was captured when the packet entered the
network. Inside the network, the packet was switched based only on MPLS information, and thus
NetFlow information was not captured until after the last label was removed.
One common application of the MPLS egress NetFlow accounting feature allows you to capture the
MPLS VPN IP flows that are traveling from one site of a VPN to another site of the same VPN through
the service provider backbone.
Previous to the MPLS Egress NetFlow Accounting feature, you captured flows only for IP packets on
the ingress interface of a router. You could not capture flows for MPLS encapsulated frames, which were
switched through CEF from the input port. Therefore, in an MPLS VPN environment you captured flow
information as packets were received from a CE router and forwarded to the backbone. However, you
could not capture flow information as packets were sent to a CE router because those packets were
received as MPLS frames.
The MPLS egress NetFlow accounting feature lets you capture the flows on the outgoing interfaces.
Figure 50 shows a sample topology. To capture the flow of traffic going to Site 2 of VPN 1 from any
remote VPN 1 sites, you enable MPLS egress NetFlow accounting on link PE2-CE5 of provider edge
router PE2. The flows are stored in a global flow cache maintained by the router. You can use the show
ip cache flow EXEC command or other aggregation flow commands to view the egress flow data.
Cisco IOS Switching Services Configuration Guide
XC-139
Multiprotocol Label Switching Overview
MPLS Egress NetFlow Accounting
Provider and Customer Networks with MPLS Egress NetFlow Accounting
Site 2
VPN 1
C
VPN-SC
Backbone
Site 1
VPN 1
CE5
Collector 2
P
CE1
PE1
PE2
Collector 1
Site 2
VPN 2
CE2
P
PE3
Site 3
VPN 1
PE4
Site 1
VPN 2
Site 4
VPN 1
CE4
CE6
CE3
42949
Figure 50
The PE routers export the captured flows to the configured collector devices in the provider network.
The NetFlow Analyzer or the VPN solution center (VPN-SC) application collects this information and
computes and displays site-to-site VPN traffic statistics.
Benefits to MPLS Egress NetFlow Accounting are as follows:
•
Enhanced network monitoring for complete billing solution—You can now capture flows on the
egress and ingress router interfaces to provide complete end-to-end usage information on network
traffic. The accounting server uses the collected data for various levels of aggregation for accounting
reports and API accounting information, thus providing a complete billing solution.
•
More accurate accounting statistics—NetFlow data statistics now account for all the packets that are
dropped in the core of the service provider network, thus providing more accurate traffic statistics
and patterns.
Cisco IOS Switching Services Configuration Guide
XC-140
Configuring Multiprotocol Label Switching
This chapter describes how to configure your network to perform Multiprotocol Label Switching
(MPLS).
This chapter contains the following sections:
•
Configuring MPLS Levels of Control
•
Configuring a Router for MPLS Forwarding
•
Configuring MPLS Traffic Engineering
•
Configuring MPLS Traffic Engineering Paths
•
Configuring MPLS Virtual Private Networks
•
Configuring MPLS QoS Backbone Support
•
Configuring MPLS QoS
•
Configuring the MPLS Label Switch Controller
•
Configuring MPLS Egress NetFlow Accounting
•
Verifying Configuration of MPLS Forwarding
For configuration examples on MPLS, see the “MPLS Configuration Examples” section.
For a complete description of the commands in this chapter, refer to the the Cisco IOS Switching Services
Command Reference. To locate documentation of other commands that appear in this chapter, use the
command reference master index or search online.
To identify the hardware platform or software image information associated with a feature, use the
Feature Navigator on Cisco.com to search for information about the feature or refer to the software
release notes for a specific release. For more information, see the section “Identifying Supported
Platforms” in the chapter “Using Cisco IOS Software.”
Configuring MPLS Levels of Control
This section describes three sample cases where MPLS is configured on Cisco 7500 and 7200 series
routers. These cases show the levels of control possible in selecting how MPLS is deployed in a network.
Cisco IOS Switching Services Configuration Guide
XC-141
Configuring Multiprotocol Label Switching
Configuring MPLS Levels of Control
Table 28 lists the cases, including the steps to perform MPLS and their corresponding
Cisco IOS CLI commands.
Table 28
MPLS—Levels of Control
Levels of Control Examples
Description
Case 1—Enable MPLS Incrementally in a Network The steps necessary for incrementally deploying
MPLS through a network, assuming that packets
to all destination prefixes should be label
switched.
Case 2—Route Labeled Packets to Network A Only The mechanism by which MPLS can be
restricted, such that packets are label switched to
only a subset of destinations.
Case 3—Limit Label Distribution on an MPLS
Network
The mechanisms for further controlling the
distribution of labels within a network.
For more information about the Cisco IOS CLI commands, see the chapter “MPLS Commands” in the
Cisco IOS Switching Services Command Reference.
Figure 51 shows a router-only MPLS network with Ethernet interfaces. The following sections outline
the procedures for configuring MPLS and displaying MPLS information in a network based on the
topology shown in Figure 51.
Note
Ethernet interfaces are shown in Figure 51, but any of the interfaces that are supported could be used
instead. ATM interfaces operating as TC-ATM interfaces are the exception to this statement.
Figure 51
A Router-Only MPLS Network with Ethernet Interfaces
R1
R4
e0/1
e0/2
e0/2
e0/1
R7
e0/1
e0/1
e0/2
R3
e0/4
e0/2
e0/2
Network A
e0/1
e0/2
R6
e0/4
e0/3
e0/1
e0/1
R5
e0/1
e0/2
Network B
R8
S5918
R2
e0/2
e0/3
Cisco IOS Switching Services Configuration Guide
XC-142
Configuring Multiprotocol Label Switching
Configuring MPLS Levels of Control
Case 1—Enable MPLS Incrementally in a Network
In the first case, assume that you want to deploy MPLS incrementally throughout a network of routers,
but that you do not want to restrict which destination prefixes are label switched. For a description of the
commands listed in these cases, see the chapter “MPLS Commands” in the Cisco IOS Switching Services
Command Reference.
To enable MPLS incrementally in a network, use the following commands beginning in router
configuration mode (see Figure 51):
Step 1
Step 2
Command
Purpose
At R1:
Router# configuration terminal
Router(config)# ip cef distributed
Router(config)# tag-switching advertise-tags
Router(config)# interface e0/1
Router(config-if)# tag-switching ip
Router(config-if)# exit
At R3:
Router# configuration terminal
Router(config)# ip cef distributed
Router(config)# tag-switching advertise-tags
Router(config)# interface e0/1
Router(config-if)# tag-switching ip
Enables MPLS between R1 and R3.
At R3:
Router(config)# interface e0/2
Router(config-if)# tag-switching ip
Router(config-if)# exit
At R4:
Router# configuration terminal
Router(config)# ip cef distributed
Router(config)# tag-switching advertise-tags
Router(config)# interface e0/2
Router(config-if)# tag-switching ip
Router(config-if)# exit
Enables MPLS between R3 and R4.
In order to configure distributed VIP MPLS, you
must configure dCEF switching. Enter the ip cef
distributed global configuration command on all
routers.
After you perform these steps, R1 applies labels to packets that are forwarded through Ethernet
interface e0/1, with a next hop to R3.
You can enable MPLS throughout the rest of the network by repeating steps 1 and 2 as appropriate on
other routers until all routers and interfaces are enabled for MPLS. See the example in the “Enabling
MPLS Incrementally in a Network Example” section.
Cisco IOS Switching Services Configuration Guide
XC-143
Configuring Multiprotocol Label Switching
Configuring MPLS Levels of Control
Case 2—Route Labeled Packets to Network A Only
In the second case, assume that you want to enable MPLS for a subset of destination prefixes. This option
might be used to test MPLS across a large network. In this case, you would configure the system so that
only a small number of destinations is label switched (for example, internal test networks) without the
majority of traffic being affected.
To enable MPLS for a subset of destination prefixes, use the following commands at each router in the
network in router configuration mode (see Figure 51):
Step 1
Command
Purpose
Router(config)# access-list 1 permit A
Limits label distribution by using an access
list.
(Enter the actual network address and
netmask in place of permit A. For example,
access-list 1 permit 192.5.34. 0 0.0.0.255.)
Step 2
Router(config)# tag-switching advertise-tags for 1
Instructs the router to advertise for network
A only to all adjacent label switch routers.
Any labels for other destination networks
that the router may have distributed before
this step are withdrawn.
Case 3—Limit Label Distribution on an MPLS Network
The third case demonstrates the full control available to you in determining the destination prefixes and
paths for which MPLS is enabled.
Configure the routers so that packets addressed to network A are labeled, all other packets are unlabeled,
and only links R1-R3, R3-R4, R4-R6, and R6-R7 carry labeled packets addressed to network A. For
example, suppose the normally routed path for packets arriving at R1 addressed to network A or
network B is R1, R3, R5, R6, R7. A packet addressed to network A would flow labeled on links R1-R3
and R6-R7, and unlabeled on links R3-R5 and R5-R6. A packet addressed to network B would follow
the same path, but would be unlabeled on all links.
Assume that at the outset the routers are configured so that packets addressed to network A are labeled
and all other packets are unlabeled (as at the completion of Case 2).
Use the tag-switching advertise-tags command and access lists to limit label distribution. Specifically,
you need to configure routers R2, R5, and R8 to distribute no labels to other routers. This ensures that
no other routers send labeled packets to any of those three. You also need to configure routers R1, R3,
R4, R6, and R7 to distribute labels only for network A and to distribute them only to the appropriate
adjacent router; that is, R3 distributes its label for network A only to R1, R4 only to R3, and so on.
To limit label distribution on a MPLS network, use the following commands in router configuration
mode:
Command
Purpose
Step 1
Router(config)# no tag-switching advertise-tags
Configures R2 to distribute no labels.
Step 2
Router(config)# no tag-switching advertise-tags
Configures R5 to distribute no labels.
Cisco IOS Switching Services Configuration Guide
XC-144
Configuring Multiprotocol Label Switching
Configuring a Router for MPLS Forwarding
Command
Purpose
Step 3
Router(config)# no tag-switching advertise-tags
Configures R8 to distribute no labels
Step 4
Router(config)#
Router(config)#
Router(config)#
Router(config)#
Configures R3 by defining an access list and
by instructing the router to distribute labels
for the networks permitted by access list 1
(created as part of case 2) to the routers
permitted by access list 2.
access-list 2 permit R1
no tag-switching advertise-tags for 1
tag-switching advertise-tags for 1 to 2
exit
The access list 2 permit R1 command
permits R1 and denies all other routers.
(Enter the actual network address and
netmask in place of permit R1. For example,
access-list 1 permit 192.5.34.0 0.0.0.255.)
Step 5
Step 6
Step 7
Step 8
Router(config)#
Router(config)#
Router(config)#
Router(config)#
access-list 1 permit A
access-list 2 permit R1
tag-switching advertise-tags for 1 to 2
exit
Configures R3.
Router(config)#
Router(config)#
Router(config)#
Router(config)#
access-list 1 permit A
access-list 2 permit R3
tag-switching advertise-tags for 1 to 2
exit
Configures R4.
Router(config)#
Router(config)#
Router(config)#
Router(config)#
access-list 1 permit A
access-list 2 permit R4
tag-switching advertise-tags for 1 to 2
exit
Configures R6.
Router(config)#
Router(config)#
Router(config)#
Router(config)#
access-list 1 permit A
access-list 2 permit R6
tag-switching advertise-tags for 1 to 2
exit
Configures R7.
(Enter the actual network address and
netmask in place of permit R1. For example,
access-list 1 permit 192.5.34.0 0.0.0.255.)
(Enter the actual network address and
netmask in place of permit R1. For example,
access-list 1 permit 192.5.34.0 0.0.0.255.)
(Enter the actual network address and
netmask in place of permit R1. For example,
access-list 1 permit 192.5.34.0 0.0.0.255.)
(Enter the actual network address and
netmask in place of permit R1. For example,
access-list 1 permit 192.5.34.0 0.0.0.255.)
Configuring a Router for MPLS Forwarding
MPLS forwarding on routers requires that CEF be enabled. To enable CEF on a router, enter the
following commands:
Router# configure terminal
Router(config)# ip cef [distributed]
Note
For best MPLS forwarding performance, use the distributed option on routers that support this
option.
For more information on the CEF commands, refer to the Cisco IOS Switching Services Command
Reference.
Cisco IOS Switching Services Configuration Guide
XC-145
Configuring Multiprotocol Label Switching
Configuring MPLS Traffic Engineering
Configuring MPLS Traffic Engineering
Perform the following tasks before you enable MPLS traffic engineering:
•
Turn on MPLS tunnels
•
Turn on CEF
•
Turn on IS-IS or OSPF
To configure MPLS traffic engineering, perform the tasks described in the following sections:
•
Configuring a Device to Support Tunnels
•
Configuring an Interface to Support RSVP-Based Tunnel Signalling and IGP Flooding
•
Configuring IS-IS for MPLS Traffic Engineering
•
Configuring OSPF for MPLS Traffic Engineering
•
Configuring an MPLS Traffic Engineering Tunnel
Configuring a Device to Support Tunnels
To configure a device to support tunnels, use the following commands in global configuration mode:
Step 1
Command
Purpose
Router(config)# ip cef
Enables standard CEF operation.
For information about CEF configuration and the
command syntax, see the Cisco IOS Switching
Services Command Reference.
Step 2
Router(config)# mpls traffic-eng tunnels
Cisco IOS Switching Services Configuration Guide
XC-146
Enables the MPLS traffic engineering tunnel feature
on a device.
Configuring Multiprotocol Label Switching
Configuring MPLS Traffic Engineering
Configuring an Interface to Support RSVP-Based Tunnel Signalling and IGP
Flooding
To configure an interface to support RSVP-based tunnel signalling and IGP flooding, use the following
commands in interface configuration mode:
Note
You must enable the tunnel feature on interfaces that you want to support MPLS traffic engineering.
Command
Purpose
Step 1
Router(config-if)# mpls traffic-eng tunnels
Enables MPLS traffic engineering tunnels on an
interface.
Step 2
Router(config-if)# ip rsvp bandwidth bandwidth
Enables RSVP for IP on an interface and specifies
the amount of bandwidth that will be reserved.
For a description of the ip rsvp interface command
syntax, see the Cisco IOS Quality of Service
Solutions Command Reference.
Configuring IS-IS for MPLS Traffic Engineering
To configure IS-IS for MPLS traffic engineering, perform the steps described below. For a description
of the IS-IS commands (excluding the IS-IS traffic engineering commands), see the Cisco IOS IP and
IP Routing Command Reference.
Command
Purpose
Step 1
Router(config)# router isis
Enables IS-IS routing and specifies an IS-IS process for IP. This
command places the router in router configuration mode.
Step 2
Router(config-router)# mpls
traffic-eng level-1
Turns on MPLS traffic engineering for IS-IS level 1.
Step 3
Router(config-router)# mpls
traffic-eng router-id loopback0
Specifies that the traffic engineering router identifier for the node is
the IP address associated with interface loopback0.
Step 4
Router(config-router)# metric-style
wide
Configures a router to generate and accept only new-style TLVs.
Cisco IOS Switching Services Configuration Guide
XC-147
Configuring Multiprotocol Label Switching
Configuring MPLS Traffic Engineering
Configuring OSPF for MPLS Traffic Engineering
To configure OSPF for MPLS traffic engineering, use the following commands beginning in global
configuration mode. For a description of the OSPF commands (excluding the OSPF traffic engineering
commands), see the Cisco IOS IP Command Reference, Volume 2 of 3: Routing Protocols.
Step 1
Command
Purpose
Router(config)# router ospf process-id
Configures an OSPF routing process for IP and places the router in
configuration mode.
The process-id argument is an internally used identification
parameter for an OSPF routing process. It is locally assigned and
can be any positive integer. Assign a unique value for each OSPF
routing process.
Step 2
Router(config-router)# mpls
traffic-eng
area 0
Turns on MPLS traffic engineering for OSPF area 0.
Step 3
Router(config-router)# mpls
traffic-eng
router-id loopback0
Specifies that the traffic engineering router identifier for the node is
the IP address associated with interface loopback0.
Configuring an MPLS Traffic Engineering Tunnel
To configure an MPLS traffic engineering tunnel, use the following commands in interface configuration
mode. This tunnel has two path setup options: a preferred explicit path and a backup dynamic path.
Command
Purpose
Step 1
Router(config)# interface tunnel
Configures an interface type and enters interface configuration
mode.
Step 2
Router(config)# ip unnumbered loopback0
Gives the tunnel interface an IP address.
An MPLS traffic engineering tunnel interface should be
unnumbered because it represents a unidirectional link.
Step 3
Router(config-if)# tunnel destination
A.B.C.D
Specifies the destination for a tunnel.
Step 4
Router(config-if)# tunnel mode mpls
traffic-eng
Sets the tunnel encapsulation mode to MPLS traffic engineering.
Step 5
Router(config-if)# tunnel mpls
traffic-eng bandwidth bandwidth
Configures the bandwidth for the MPLS traffic engineering tunnel.
Step 6
Router(config-if)# tunnel mpls
traffic-eng
path-option number {dynamic |
explicit {name path-name |
path-number}} [lockdown]
Configures the tunnel to use a named IP explicit path or a path
dynamically calculated from the traffic engineering topology
database. A dynamic path is used if an explicit path is unavailable.
Cisco IOS Switching Services Configuration Guide
XC-148
Configuring Multiprotocol Label Switching
Configuring MPLS Traffic Engineering Paths
Configuring MPLS Traffic Engineering Paths
To configure an MPLS traffic engineering tunnel that an IGP can use, use the following commands in
interface configuration mode:
Command
Purpose
Step 1
Router(config-if)# interface tunnel1
Configures an interface type and enters interface
configuration mode.
Step 2
Router(config-if)# tunnel mpls traffic-eng autoroute
announce
Causes the IGP to use the tunnel in its enhanced SPF
calculation.
Configuring MPLS Virtual Private Networks
To configure and verify VPNs, perform the tasks described in the following sections:
•
Defining VPNs
•
Configuring BGP Routing Sessions
•
Configuring PE to PE Routing Sessions
•
Configuring BGP PE to CE Routing Sessions
•
Configuring RIP PE to CE Routing Sessions
•
Configuring Static Route PE to CE Routing Sessions
•
Configuring MPLS VPNs with Cable Interfaces
•
Configuring Interautonomous Systems for MPLS VPNs
•
Verifying VPN Operation
Defining VPNs
To define VPN routing instances, use the following commands beginning in router configuration mode
on the PE router:
Command
Purpose
Step 1
Router(config)# ip vrf vrf-name
Enters VRF configuration mode and defines the
VPN routing instance by assigning a VRF name.
Step 2
Router(config-vrf)# rd route-distinguisher
Creates routing and forwarding tables.
Step 3
Router(config-vrf)# route-target {import | export |
both} route-target-ext-community
Creates a list of import or export route target
communities for the specified VRF.
Step 4
Router(config-vrf)# import map route-map
(Optional) Associates the specified route map
with the VRF.
Step 5
Router(config-vrf)# export map route-map
(Optional) Associates the specified export route
map with the VRF.
Step 6
Router(config-if)# ip vrf forwarding vrf-name
Associates a VRF with an interface or
subinterface.
Cisco IOS Switching Services Configuration Guide
XC-149
Configuring Multiprotocol Label Switching
Configuring MPLS Virtual Private Networks
Configuring BGP Routing Sessions
To configure BGP routing sessions in a provider network, use the following commands beginning in
router configuration mode on the PE router:
Command
Purpose
Step 1
Router(config)# router bgp autonomous-system
Configures the BGP routing process with the
autonomous system number passed along to other
BGP routers.
Step 2
Router(config-router)# neighbor {ip-address |
peer-group-name} remote-as number
Specifies a neighbor’s IP address or BGP peer
group identifying it to the local autonomous
system.
Step 3
Router(config-router)# neighbor ip-address activate
Activates the advertisement of the IPv4 address
family.
Configuring PE to PE Routing Sessions
To configure PE to PE routing sessions in a provider network, use the following commands beginning
in router configuration mode on the PE router:
Command
Purpose
Step 1
Router(config-router)# address-family vpnv4 [unicast |
multicast]
Defines IBGP parameters for VPNv4 NLRI
exchange.
Step 2
Router(config-router-af)# neighbor address remote-as
as-number
Defines an IBGP session to exchange VPNv4
NLRIs.
Step 3
Router(config-router-af)# neighbor address activate
Activates the advertisement of the IPv4 address
family.
Cisco IOS Switching Services Configuration Guide
XC-150
Configuring Multiprotocol Label Switching
Configuring MPLS Virtual Private Networks
Configuring BGP PE to CE Routing Sessions
To configure BGP PE to CE routing sessions, use the following commands beginning in router
configuration mode on the PE router:
Step 1
Command
Purpose
Router(config-router)# address-family ipv4 [unicast]
vrf vrf-name
Defines EBGP parameters for PE to CE routing
sessions.
Note
The default is Off for autosummary and
synchronization in the VRF
address-family submode.
Step 2
Router(config-router-af)# neighbor address remote-as
as-number
Defines an EBGP session between PE and CE
routers.
Step 3
Router(config-router-af)# neighbor address activate
Activates the advertisement of the IPv4 address
family.
Configuring RIP PE to CE Routing Sessions
To configure RIP PE to CE routing sessions, use the following commands beginning in router
configuration mode on the PE router:
Command
Purpose
Step 1
Router(config)# router rip
Enables RIP.
Step 2
Router(config-router-af)# address-family ipv4
[unicast] vrf vrf-name
Defines RIP parameters for PE to CE routing
sessions.
Note
Step 3
Router(config-router-af)# network prefix
The default is Off for auto-summary and
synchronization in the VRF
address-family submode.
Enables RIP on the PE to CE link.
Cisco IOS Switching Services Configuration Guide
XC-151
Configuring Multiprotocol Label Switching
Configuring MPLS Virtual Private Networks
Configuring Static Route PE to CE Routing Sessions
To configure static route PE to CE routing sessions, use the following commands in router configuration
mode on the PE router:
Command
Purpose
Step 1
Router(config)# ip route vrf vrf-name
Defines static route parameters for every PE to CE
session.
Step 2
Router(config-router)# address-family ipv4 [unicast]
vrf vrf-name
Defines static route parameters for every BGP PE
to CE routing session.
Note
The default is Off for auto-summary and
synchronization in the VRF
address-family submode.
Step 3
Router(config-router-af)# redistribute static
Redistributes VRF static routes into the VRF BGP
table.
Step 4
Router(config-router-af)# redistribute connected
Redistributes directly connected networks into the
VRF BGP table.
Configuring MPLS VPNs with Cable Interfaces
Before configuring IP-based VPNs on Cisco uBR7200 series, perform the following tasks:
•
Ensure that your network supports reliable broadband data transmission. Your network area must be
swept, balanced, and certified based on National Television Standards Committee (NTSC) or
appropriate international cable plant recommendations. Ensure that your network area meets all
DOCSIS or European Data-over-Cable Service Interface Specifications (EuroDOCSIS) downstream
and upstream RF requirements.
•
Ensure that your Cisco uBR7200 series universal broadband router is installed following
instructions in the Cisco uBR7200 Series Universal Broadband Router Hardware Installation Guide
and the Regulatory Compliance and Safety Information for the Cisco uBR7200 Series Universal
Broadband Router.
•
Ensure that your Cisco uBR7200 series universal broadband router is configured for basic
operations following instructions in the Cisco uBR7200 Series Universal Broadband Router
Software Configuration Guide. The chassis must contain at least one port adapter to provide
backbone connectivity and one Cisco cable modem card to serve as the RF cable TV interface.
Cisco IOS Switching Services Configuration Guide
XC-152
Configuring Multiprotocol Label Switching
Configuring MPLS Virtual Private Networks
To configure MPLS VPNs with cable interfaces, perform the tasks described in the following sections.
The first two sections are required tasks; the remaining tasks are optional:
•
Creating VRFs for Each VPN (Required)
•
Defining Subinterfaces on a Physical Cable Interface and Assigning VRFs (Required)
•
Configuring Cable Interface Bundles (Optional)
•
Configuring Subinterfaces and MPLS VPNs on a Bundle Master (Optional)
•
Configuring MPLS in the P Routers in the Provider Core (Optional)
•
Verifying the MPLS VPN Configuration (Optional)
Restrictions
The following restrictions apply to configuring MPLS VPNs with cable interfaces:
•
Each subinterface on the CMTS requires an address range from the ISP and from the MSO. These
two ranges must not overlap and must be extensible to support an increased number of subscribers
for scalability. Cisco IOS Release 12.1(2)EC and 12.1(2)T do not support overlapping addresses for
the MPLS VPN subinterface.
Note
This document does not address allocation and management of MSO and ISP IP addresses.
See Configuring Multiprotocol Label Switching for this information.
•
Cisco IOS Release 12.1(2) T supports the cable source-verify dhcp cable interface command, but
Cisco IOS Release 12.1(2)EC does not support it. The cable source-verify dhcp cable interface
command enables Dynamic Host Control Protocol (DHCP) servers to verify IP addresses of
upstream traffic, and prevent MSO users from using unauthorized, spoofed, or stolen IP addresses.
•
When using only MPLS VPNs, create subinterfaces on the bundle master, assign them an IP address,
and provide VRF configuration for each ISP. When you create subinterfaces and configure only
MPLS VPNs, the cable interface bundling feature is independent of the MPLS VPN.
•
When using cable interface bundling, perform the following tasks:
– Define one of the interfaces in the bundle as the bundle master interface.
– Specify all generic IP networking information (such as IP address, routing protocols, and
switching modes) on the bundle master interface. Do not specify generic IP networking
information on bundle slave interfaces. If you attempt to add an interface to a bundle as a
nonmaster interface and an IP address is assigned to this interface, the command will fail. You
must remove the IP address configuration before you can add the interface to a bundle.
– An interface that has a subinterfaces defined over it is not allowed to be a part of the bundle.
– Specify generic (not downstream or upstream related) cable interface configurations, such as
source-verify or ARP handling, on the master interface. Do not specify generic configuration
on nonmaster interfaces.
– If you configure an interface as a part of a bundle and it is not the master interface, all generic
cable configuration for this interface is removed. The master interface configuration will then
apply to all interfaces in the bundle.
Cisco IOS Switching Services Configuration Guide
XC-153
Configuring Multiprotocol Label Switching
Configuring MPLS Virtual Private Networks
•
Cable interface bundling is only supported on cable interfaces. Cisco IOS software provides cable
interfaces with Cisco uBR-MC11, Cisco uBR-MC12, Cisco uBR-MC14, and Cisco uBR-MC16
cable modem cards.
•
Interface bundles can only be configured using the command-line interface (including the CLI-based
HTML configuration).
Creating VRFs for Each VPN
To create VRFs for each VPN, use the following commands beginning in router configuration mode:
Note
Because only the CMTS has logical subinterfaces, assignments of VRFs on the other PE devices will
be to specific physical interfaces.
Command
Purpose
Step 1
Router(config)# ip vrf mgmt-vpn
Enters VRF configuration mode and maps a VRF
table to the VPN (specified by mgmt-vpn argument).
The management VPN is the first VPN configured.
Step 2
Router(config-vrf)# rd mgmt-rd
Creates a routing and forwarding table by assigning
a RD to the management VPN.
Step 3
Router(config-vrf)# route-target {export| import|
both} mgmt-rd
Exports or imports all routes for the RD of the
management VPN. This determines which routes
will be shared within VRFs.
Step 4
Router(config-vrf)# route-target import isp1-vpn-rd
Imports all routes for the VPNs (isp1-vpn argument)
route distinguisher.
Step 5
Router(config-vrf)# route-target import isp2-vpn-rd
Imports all routes for the VPNs (isp2-vpn argument)
RD.
Step 6
Router(config-vrf)# ip vrf isp1-vpn
Creates a routing and forwarding table by assigning
a RD to isp1-vpn argument) .
Step 7
Router(config-vrf)# rd mgmt-rd
Creates a routing and forwarding table by assigning
a RD (mgmt-rd argument) to the management VPN
(mgmt-vpn argument) .
Step 8
Router(config-vrf)# route-target export isp1-vpn-rd
Exports all routes for the VPNs (isp1-vpn argument)
RD.
Step 9
Router(config-vrf)# route-target import isp1-vpn-rd
Imports all routes for the VPNs (isp1-vpn argument)
RD.
Step 10
Router(config-vrf)# route-target import mgmt-vpn-rd
Exports all routes for the VPNs (mgmt-vpn
argument) RD.
Step 11
Router(config-vrf)# ip vrf isp2-vpn
Creates a routing and forwarding table by assigning
a RD to isp2-vpn argument) .
Step 12
Router(config-vrf)# route-target export isp2-vpn-rd
Exports all routes for the VPNs (isp2-vpn argument)
RD.
Step 13
Router(config-vrf)# route-target import isp2-vpn-rd
Imports all routes for the VPNs (isp2-vpn argument)
RD.
Step 14
Router(config-vrf)# route-target import mgmt-vpn-rd
Imports all routes for the VPNs (mgmt-vpn
argument) RD.
Cisco IOS Switching Services Configuration Guide
XC-154
Configuring Multiprotocol Label Switching
Configuring MPLS Virtual Private Networks
Defining Subinterfaces on a Physical Cable Interface and Assigning VRFs
To create a logical cable subinterface, use the following commands beginning in global configuration
mode. Create one subinterface for each VPN (one per ISP). The first subinterface created must be
configured as part of the management VPN (with the lowest subinterface number). Create VRFs using
the procedure described in the “Creating VRFs for Each VPN” section and apply them to the
subinterface.
Command
Purpose
Step 1
Router# configure terminal
Enters configuration mode.
Step 2
Router(config)# interface cable slot/port
Enters cable interface configuration mode.
slot = slot number in chassis (slot numbers begin
with a 0).
port = port number on cable modem card slot (port
numbers begin with a 0).
Step 3
Router(config-if)# interface cable slot/port.n
Defines the first (management) subinterface with the
lowest subinterface number. Valid range for n is
from 1 to 255.
Step 4
Router(config-subif)# description string
Identifies the subinterface as the management
subinterface.
Step 5
Router(config-subif)# ip vrf forwarding mgmt-vpn
Assigns the subinterface to the management VPN
(the MPLS VPN used by the MSO to supply service
to customers).
Step 6
Router(config-subif)# ip address ipaddress mask
Assigns the subinterface an IP address and a subnet
mask.
Step 7
Router(config-subif)# cable helper-address
ip-address cable-modem
Forwards DHCP requests from cable modems to the
IP address listed.
Step 8
Router(config-subif)# cable helper-address
ip-address host
Forwards DHCP requests from hosts to the IP
address listed.
Step 9
Router(config-if)# interface cable slot/port.n
Defines an additional subinterface for the ISP (such
as isp1). Valid range for n is 1 to 255.
Step 10
Router(config-subif)# description string
Identifies the subinterface (such as subinterface for
the isp1-vpn argument).
Step 11
Router(config-subif)# ip vrf forwarding isp1-vpn
Assigns the subinterface to isp1-vpn VPN.
Step 12
Router(config-subif)# ip address ipaddress mask
Assigns the subinterface an IP address and a subnet
mask.
Step 13
Router(config-subif)# cable helper-address
ip-address cable-modem
Forwards DHCP requests from cable modems to the
IP address listed.
Step 14
Router(config-subif)# cable helper-address
ip-address host
Forwards DHCP requests from hosts to the IP
address listed.
Step 15
Router(config-if)# interface cable slot/port.n
Defines an additional subinterface for the ISP (such
as isp2). Valid range for n is 1 to 255.
Step 16
Router(config-subif)# description string
Identifies the subinterface (such as subinterface for
the isp2-vpn argument) .
Step 17
Router(config-subif)# ip vrf forwarding isp2-vpn
Assigns the subinterface to isp2-vpn VPN.
Cisco IOS Switching Services Configuration Guide
XC-155
Configuring Multiprotocol Label Switching
Configuring MPLS Virtual Private Networks
Command
Purpose
Step 18
Router(config-subif)# ip address ipaddress mask
Assigns the subinterface an IP address and a subnet
mask.
Step 19
Router(config-subif)# cable helper-address
ip-address cable-modem
Forwards DHCP requests from cable modems to the
IP address listed.
Step 20
Router(config-subif)# cable helper-address
ip-address host
Forwards DHCP requests from hosts to the IP
address listed.
Step 21
Router(config)# copy running-config startup-config
Returns to configuration mode, and stores the
configuration or changes to your startup
configuration in NVRAM.
Note
Step 22
Router(config)# exit
Use this command to save the
configuration settings that you created in
the Cisco uBR7200 series universal
broadband router using the configuration
mode, the setup facility, and AutoInstall. If
you fail to do this, your configuration will
be lost the next time you reload the router.
Returns to configuration mode.
Configuring Cable Interface Bundles
To assign a cable interface to a bundle, use the following commands beginning in global configuration
mode:
Step 1
Command
Purpose
Router(config)# interface cable slot/port
Enters the cable interface configuration mode.
slot = slot number in chassis (slot numbers begin
with 0).
port = port number on cable modem card slot (port
numbers begin with 0).
IP addresses are not assigned to this interface. They
are assigned to the logical subinterfaces created
within this interface.
Step 2
Router(config-if)# cable bundle bundle-number master
Cisco IOS Switching Services Configuration Guide
XC-156
Defines the interface as the bundle’s master
interface. Valid range for bundle-number argument
is from 1 to 255.
Configuring Multiprotocol Label Switching
Configuring MPLS Virtual Private Networks
Step 3
Command
Purpose
Router(config)# interface cable slot/port
Enters the cable interface configuration mode for
another cable interface.
slot = slot number in chassis (slot numbers begin
with 0).
port = port number on cable modem card slot (port
numbers begin with 0).
IP addresses are not assigned to this interface. They
are assigned to the logical subinterfaces created
within this interface.
Step 4
Router(config-if)# cable bundle bundle-number
Adds the interface to the bundle specified by
bundle-number. Valid range for the bundle-number
argument is from 1 to 255.
Configuring Subinterfaces and MPLS VPNs on a Bundle Master
To configure subinterfaces on a bundle master and assign each subinterface a Layer 3 configuration,
configure cable interface bundles using the procedure described in the “Configuring Cable Interface
Bundles” section.
Define subinterfaces on the bundle master interface and assign a Layer 3 configuration to each
subinterface using the procedure described in the “Defining Subinterfaces on a Physical Cable Interface
and Assigning VRFs” section. Create one subinterface for each customer VPN (one per ISP).
Configuring MPLS in the P Routers in the Provider Core
To configure MPLS in the P routers in the provider core, use the following commands beginning in router
configuration mode:
Command
Purpose
Step 1
Router(config)# ip cef
Enables CEF operation.
Step 2
Router(config)# interface FastEthernet slot/port
Enters FastEthernet interface configuration mode.
Step 3
Router(config-if)# ip address ip-address mask
Defines the primary IP address range for the
interface.
Step 4
Router(config-if)# mpls ip
Enables the interface to be forwarded to an MPLS
packet.
Step 5
Router(config-if)# mpls label-protocol ldp
Enables Label Distribution Protocol (LDP) on the
interface.
Cisco IOS Switching Services Configuration Guide
XC-157
Configuring Multiprotocol Label Switching
Configuring MPLS Virtual Private Networks
Step 6
Command
Purpose
Router(config)# copy running-config startup-config
Stores the configuration or changes to your startup
configuration in NVRAM.
Note
Step 7
Router(config)# exit
Use this command to save the
configuration settings that you created in
the Cisco uBR7200 series universal
broadband router using the configuration
mode, the setup facility, and AutoInstall. If
you fail to do this, your configuration will
be lost the next time you reload the router.
Returns to the configuration mode.
Verifying the MPLS VPN Configuration
To verify MPLS VPN operations on PE routers, use the following EXEC commands:
Command
Purpose
Step 1
Router# show ip vrf
Displays the set of VRFs and interfaces.
Step 2
Router# show ip route vrf
Displays the IP routing table for a VRF.
Step 3
Router# show ip protocols vrf
Displays the routing protocol information for a VRF.
Step 4
Router(config)# show cable bundle n forwarding-table
Displays the forwarding table for the specified
interface.
Configuring Interautonomous Systems for MPLS VPNs
Before you configure EBGP routing between autonomous systems or subautonomous systems in an
MPLS VPN, ensure that you have properly configured all MPLS VPN routing instances and sessions.
The configuration tasks outlined in this section build from those configuration tasks.
Perform the following tasks before you enable configure EBGP routing between autonomous systems or
subautonomous systems in an MPLS VPN:
•
Define VPN routing instances
•
Configure BGP routing sessions in the service provider (P) network
•
Configure PE to PE routing sessions in the service provider (P) network
•
Configure BGP PE to CE routing sessions
Cisco IOS Switching Services Configuration Guide
XC-158
Configuring Multiprotocol Label Switching
Configuring MPLS Virtual Private Networks
To configure the exchange of VPN-IPv4 addresses between two or more autonomous systems or
subautonomous systems in a confederation, perform the tasks described in the following sections. The
tasks in the following sections are described as required or optional:
•
Configuring EBGP Routing for the Exchange of VPN Routes Between Autonomous Systems
(Required)
•
Configuring EBGP Routing for the Exchange of VPN Routes Between Subautonomous Systems in
a Confederation (Required)
•
Displaying VPN-IPv4 LFIB Entries (Optional)
Configuring EBGP Routing for the Exchange of VPN Routes Between Autonomous Systems
To configure an EBGP border edge router in an autonomous system to exchange VPN routes with
another autonomous system, use the following commands beginning in global configuration mode:
Note
Enter the redistribute connected subnets command in the IGP configuration portion of the router
to propagates host routes for VPN-IPv4 EBGP neighbors to other routers and provider edge routers.
Alternatively, you can specify the next-hop-self address when you configure IBGP neighbors.
Command
Purpose
Step 1
Router(config)# router bgp autonomous-system
Creates an EBGP routing process and assigns it an AS
number. The autonomous system number is passed along
to identify the router to EBGP routers in another
autonomous system.
Step 2
Router(config)# no bgp default route-target
filter
Disables BGP route-target filtering. All received BGP
VPN-IPv4 routes are accepted by the router.
Step 3
Router(config-router)# address-family
vpnv4[unicast]
Configures a routing session to carry VPN-IPv4 addresses
across the VPN backbone. Each address has been made
globally unique by the addition of an 8-byte RD. Unicast
is optional; use it if you need to specify a unicast prefix.
Step 4
Router(config-router-af)# neighbor
peer-group-name remote-as autonomous-system
Enters the address-family submode and specifies a
neighboring EBGP peer group. This EBGP peer group is
identified to the specified autonomous system.
Step 5
Router(config-router-af)# neighbor
peer-group-name activate
Activates the advertisement of the VPN-IPv4 address
family to a neighboring EBGP router.
Step 6
Router(config-router-af)# exit-address-family
Exits from the address-family submode of the global
configuration mode.
Configuring EBGP Routing for the Exchange of VPN Routes Between Subautonomous Systems in a
Confederation
In this confederation, subautonomous system IGP domains must know the addresses of CEBGP-1 and
CEBGP-2. If you do not specify a next-hop-self address as part of the router configuration, ensure that
the addresses of all PE routers in the subautonomous system are distributed throughout the network, not
just the addresses of CEBGP-1 and CEBGP-2.
Cisco IOS Switching Services Configuration Guide
XC-159
Configuring Multiprotocol Label Switching
Configuring MPLS Virtual Private Networks
Note
To ensure that the host routes for VPN-IPv4 EBGP neighbors are propagated (by means of the IGP)
to the other routers and provider edge routers, specify the redistribute connected router
configuration command in the IGP configuration portion of the CEBGP router. If you are using
OSPF, make sure that the OSPF process is not enabled on the CEBGP interface where the
“redistribute connected” subnet exists.
To configure EBGP border edge router in a confederation to exchange VPN routes with another
subautonomous system, use the following commands beginning in global configuration mode:
Command
Purpose
Step 1
Router(config)# router bgp subautonomous-system
Creates an EBGP routing process and assigns it an
autonomous system number. The subautonomous system
number is passed along to identify the router to EBGP
routers in other subautonomous systems.
Step 2
Router(config)# bgp confederation identifier
autonomous-system
Defines an EBGP confederation by specifying a
confederation identifier associated with each
subautonomous system. The subautonomous systems
appear as a single autonomous system.
Step 3
Router(config)# bgp confederation peers
subautonomous-systems
Specifies the subautonomous systems that belong to the
confederation (identifying neighbors from other
subautonomous systems within the confederation as
special EBGP peers).
Step 4
Router(config)# no bgp default route-target
filter
Disables BGP route-target community filtering. All
received BGP VPN-IPv4 routes are accepted by the
router.
Step 5
Router(config-router)# address-family
vpnv4[unicast]
Configures a routing session to carry VPN-IPv4 addresses
across the VPN backbone. Each address has been made
globally unique by the addition of an 8-byte RD. Unicast
is optional; use it if you need to specify a unicast prefix.
Step 6
Router(config-router-af)# neighbor
peer-group-name remote-as autonomous-system
Enters the address-family submode and specifies a
neighboring EBGP peer group. This EBGP peer group is
identified to the specified subautonomous system.
Step 7
Router(config-router-af)# neighbor
peer-group-name next-hop-self
Advertises the router as the next hop for the specified
neighbor. If you specify a next-hop-self address as part of
the router configuration, you need not use the
redistribute connected router configuration command
Step 8
Router(config-router-af)# neighbor
peer-group-name activate
Activates the advertisement of the VPN-IPv4 address
family to a neighboring PE router in the specified
subautonomous system.
Step 9
Router(config-router-af)# exit-address-family
Exits from the address-family submode of the global
configuration mode.
Cisco IOS Switching Services Configuration Guide
XC-160
Configuring Multiprotocol Label Switching
Configuring MPLS Virtual Private Networks
Displaying VPN-IPv4 LFIB Entries
To display the VPN-IPv4 Label Forwarding Information Base (LFIB) entries at the border edge routers
in the autonomous systems, use the following EXEC commands:
Command
Purpose
Step 1
Router# show ip bgp vpnv4 all [ tags]
Displays information about all VPN-IPv4 labels.
Step 2
Router# show tag-switching forwarding-table
Displays the contents of the LFIB (such as
VPN-IPv4 prefix or length and BGP next hop
destination for the route).
The following is an example of how the VPN-IPv4 LFIB entries appear when you use the show
tag-switching forwarding-table privileged EXEC command:
Router# show tag-switching forwarding-table
Local
tag
33
35
Note
Outgoing
tag or VC
33
27
Prefix
Bytes tag
or Tunnel Id
switched
10.120.4.0/24
0
100:12:10.200.0.1/32 \
0
Outgoing
interface
Hs0/0
Next Hop
point2point
Hs0/0
point2point
In this example, the Prefix field appears as a VPN-IPv4 RD, plus the prefix. If the value is longer
than the Prefix column (as illustrated in the last line of the example), the output automatically wraps
onto the next line in the forwarding table to preserve column alignment.
Verifying VPN Operation
To verify VPN operation by displaying routing information on the PE routers, use the following show
commands, as needed:
Command
Purpose
Router# show ip vrf
Displays the set of defined VRFs and interfaces.
Router# show ip vrf [{brief | detail | interfaces}] vrf-name
Displays information about defined VRFs and
associated interfaces.
Router# show ip route vrf vrf-name
Displays the IP routing table for a VRF.
Router# show ip protocols vrf vrf-name
Displays the routing protocol information for a VRF.
Router# show ip cef vrf vrf-name
Displays the CEF forwarding table associated with a
VRF.
Router# show ip interface interface-number
Displays the VRF table associated with an interface.
Router# show ip bgp vpnv4 all [tags]
Displays information about all BGP VPN-IPv4
prefixes.
Router# show tag-switching forwarding vrf vrf-name [prefix
mask/length][detail]
Displays label forwarding entries that correspond to
VRF routes advertised by this router.
Cisco IOS Switching Services Configuration Guide
XC-161
Configuring Multiprotocol Label Switching
Configuring MPLS QoS Backbone Support
Configuring MPLS QoS Backbone Support
Several different methods exist for supporting QoS across an MPLS backbone, the choice depending on
whether the core has label switch routers (LSRs) or ATM-LSRs. In each case, however, the QoS building
blocks are the same: CAR, WRED, and WFQ.
Three configurations are described in this section:
•
LSRs used at the core of the network backbone
•
ATM-LSRs used at the core of the network backbone
•
ATM switches without the MPLS feature enabled
LSRs
LSRs at the core of the MPLS backbone are usually either Cisco 7200 and Cisco 7500 series routers
running MPLS software. Packets are processed as follows:
1.
IP packets enter into the edge of the MPLS network.
2.
The edge LSRs invoke CAR to classify the IP packets and possibly set IP precedence. Alternatively,
IP packets can be received with their IP precedence already set.
3.
For each packet, the router performs a lookup on the IP address to determine the next hop LSR.
4.
The appropriate label is placed on the packet with the IP Precedence bits copied into every label
entry in the MPLS header.
5.
The labeled packet is then forwarded to the appropriate output interface for processing.
6.
The packets are differentiated by class. This is done according to drop probability (WRED) or
according to bandwidth and delay (WFQ). In either case, LSRs enforce the defined differentiation
by continuing to employ WRED or WFQ on each hop.
ATM-LSRs
ATM-LSRs at the core implement the multiple label virtual circuit model (LVC). In the multiple LVC
model, one label is assigned for each service class for each destination. The operation of the edge LSR
is the same as that described previously for the LSR case, except that the output is an ATM interface.
WRED is used to define service classes and determine discard policy during congestion.
In the multiple LVC model, however, class-based WFQ (CBWFQ) is used to define the amount of
bandwidth available to each service class. Packets are scheduled by class during congestion. The
ATM-LSRs participate in the differentiation of classes with WFQ and intelligently drop packets when
congestion occurs. The mechanism for this discard activity is weighted early packet discard (WEPD).
Cisco IOS Switching Services Configuration Guide
XC-162
Configuring Multiprotocol Label Switching
Configuring MPLS QoS Backbone Support
ATM Switches
When the core network uses ATM switches and the edge of the network uses MPLS-enabled edge LSRs,
the edge LSRs are interconnected through a mesh of ATM Forum PVCs (CBR, VBR, or UBR) over the
ATM core switches. The edge LSRs invoke WFQ on a per-VC basis to provide differentiation based on
the delay of each MPLS QoS multiplexed onto the ATM Forum PVC. Optionally, WRED can also be
used on a per-VC basis to manage drop priority between classes when congestion occurs on the edge
LSR.
Table 29 lists the MPLS QoS features supported on packet interfaces.
Table 29
MPLS QoS Features Supported on Packet Interfaces
MPLS QoS Packet Feature
Cisco 7500
Series
Cisco 7200
Series
Cisco 4000
Series
Cisco 3600
Series
Cisco 2600
Series
Per-interface WRED
X
X
X
X
Untested
Per-interface, per-flow
WFQ
X
X
X
X
Untested
Per-interface, per-class
WFQ
X
X
X
X
Untested
Table 30 lists the MPLS QoS features supported on ATM interfaces.
Table 30
MPLS QoS Features Supported on ATM Interfaces
MPLS QoS ATM Forum
PVCs Feature
Per-VC WRED
Per-VC WRED and
per VC, per-class WFQ
Cisco 7500
Series
Cisco 7200
Series
Cisco 4000
Series
Cisco 3600
Series
Cisco 2600
Series
X1
X1
—
—
—
—
X
1
—
—
—
X2
X2
—
—
—
2
2
—
—
—
MPLS QoS Multi-VC or LBR
Feature
Per-interface WRED
Per-interface, per-class
WFQ
X
X
1. This feature is only available on the PA-A3.
2. This feature is only available on the PA-A1.
Cisco IOS Switching Services Configuration Guide
XC-163
Configuring Multiprotocol Label Switching
Configuring MPLS QoS
Table 31 lists the MPLS QoS features supported on ATM switches.
Table 31
MPLS QoS Features Supported on ATM Switches
MPLS QoS ATM Forum
PVCs Feature
LightStream
1010 ATM
Switch1
BPX 8650
Series
MGX 8800
Series
Catalyst 8540
MSR1
MPLS QoS ATM Forum
PVCs
X
X
X
X
MPLS QoS Multi-VC or
LBR—per-class WFQ
X
—
—
—
1. This switch can be used for the core only.
Configuring MPLS QoS
Perform the following tasks before you enable MPLS traffic engineering:
•
Turn on MPLS tunnels
•
Turn on CEF
To configure MPLS QoS, perform the tasks described in the following sections. The first five sections
are described as required; the remaining tasks are optional:
•
Configuring QoS (Required)
•
Setting the MPLS Experimental Field Value (Required)
•
Using the Modular QoS CLI to Configure the Ingress Label Switching Router (Required)
•
Using CAR to Configure the Ingress Label Switching Router (Required)
•
Configuring the Output IP QoS of the Packet (Required)
•
Configuring PVC Mode in a Non-MPLS-Enabled Core (Optional)
•
Configuring Multi-VC Mode in a MPLS-Enabled Core (Optional)
•
Configuring Multi-VCs Using the Cos-Map Function (Optional)
•
Configuring DWFQ and Changing Queue Weights on an Outgoing Interface (Optional)
•
Verifying QoS Operation (Optional)
Configuring QoS
To configure QoS, you can configure one or more of the following features (in addition, of course, to
other items not described in this document):
•
CAR
•
WRED
•
WFQ
Cisco IOS Switching Services Configuration Guide
XC-164
Configuring Multiprotocol Label Switching
Configuring MPLS QoS
Setting the MPLS Experimental Field Value
Setting the MPLS experimental field value satisfies the requirement of service providers that do not want
the value of the IP Precedence field modified within IP packets transported through their networks.
By choosing different values for the MPLS experimental field, you can mark packets based on their
characteristics, such as rate or type, so that packets have the priority that they require during periods of
congestion.
Figure 52 shows a MPLS network of a service provider that connects two sites of a network belonging
to a customer.
Figure 52
MPLS Network Connecting Two Sites of a Customer’s IP Network
IP
network
MPLS
network
MPLS
network
IP
network
Host A
Host B
PE1
P1
P2
PE2
CE2
41867
CE1
Owned by
service provider
To use these features in a network, set the MPLS experimental field value at PE1 (the ingress label
switching router) by using the modular QoS CLI or the rate-limit interface command that CAR provides
to set the QoS value in the MPLS packet. For detailed instructions, see the “Setting the MPLS
Experimental Field Value” section.
Importance of Prioritizing a Packet Appropriately
During Step 1 of the configuration process (described in the “Using the Modular QoS CLI to Configure
the Ingress Label Switching Router” and “Using CAR to Configure the Ingress Label Switching Router”
sections) you classify IP packets according to their source address, destination address, port, protocol
identification, or quality of service field. For example, packets can be identified based on one or more
of the specified fields, as Voice over IP (VoIP) or a File Transfer Protocol (FTP). Packet
classification/marking is important because a priority of a packet is determined by how it is classified or
marked.
A priority of a packet affects how the packet is treated during periods of congestion. For example, service
providers have service level agreements (SLAs) with customers. The agreement specifies how much
traffic the service provider has agreed to deliver. To comply with the agreement, the customer must not
send more than the agreed-upon rate. Packets are considered to be in-rate or out-of-rate. If there is
congestion in the network, out-of-rate packets might be dropped more aggressively.
Cisco IOS Switching Services Configuration Guide
XC-165
Configuring Multiprotocol Label Switching
Configuring MPLS QoS
Configuring the Ingress MPLS Router
To classify IP packets, you configure the ingress label switching router. Packets are received at the
ingress router as IP packets and sent as MPLS packets. To perform the configuration, use either of the
following features:
•
Modular QoS CLI, the newer and more flexible method—Use this method if you do not want to
consider the rate of the packets that PE1 receives.
•
CAR—Use if you want to consider the rate of the incoming packets:
– If a packet conforms to the SLA between the service provider and the customer (that is, the
packet is in-rate), the service provider gives the packet preferential treatment when the network
of a service provider is congested.
– If a packet does not conform (that is, it is out-of-rate) and the network is congested, the service
provider might discard the packet or give it less preferential treatment.
Using the Modular QoS CLI to Configure the Ingress Label Switching Router
To use the modular QoS CLI to configure PE1 (the ingress label switching router), perform the following
steps:
Step 1
Configure a class map to classify IP packets according to their IP precedence.
Step 2
Configure a policy map to mark MPLS packets. (Write their classification into the MPLS experimental
field.)
Step 3
Configure the input interface to attach the service policy.
Configuring a Class Map to Classify IP Packets
To configure a class map, use the following commands beginning in global configuration mode:
Command
Purpose
Step 1
Router(config)# class-map class-map name
Specifies the class map to which packets will be
matched.
Step 2
Router(config-c-map)# match criteria
Specifies the packet characteristics that will be
matched to the class.
Step 3
Router(config-c-map)# end
Exits class-map configuration mode.
In the following example, all packets that contain IP Precedence 4 are matched by the class-map name
IP_prec4:
Router(config)# class-map IP_prec4
Router(config-c-map)# match ip precedence 4
Router(config-c-map)# end
Cisco IOS Switching Services Configuration Guide
XC-166
Configuring Multiprotocol Label Switching
Configuring MPLS QoS
Configuring a Policy Map to Set the MPLS Experimental Field
To configure a policy map, use the following commands beginning in global configuration mode:
Command
Purpose
Step 1
Router(config)# policy-map policy-map name
Creates a policy map that can be attached to one or
more interfaces to specify a service policy.
Step 2
Router(config-p-map)# class class-map name
Specifies the name of the class map previously
designated in the class-map command.
Step 3
Router(config-p-map-c)# set mpls experimental value
Designates the value to which the MPLS bits are
set if the packets match the specified policy map.
Step 4
Router(config-p-map-c)# end
Exits policy-map configuration mode.
In the following example, the value in the MPLS experimental field of each packet that is matched by
the class-map IP_prec4 is set to 5:
Router(config)# policy-map set_experimental_5
Router(config-p-map)# class IP_prec4
Router(config-p-map-c)# set mpls experimental 5
Router(config-p-map-c)# end
Configuring the Input Interface to Attach the Service Policy
To configure the input interface, use the following commands beginning in global configuration mode:
Command
Purpose
Step 1
Router(config)# interface name
Designates the input interface.
Step 2
Router(config-int)# service-policy input policy-map
name
Attaches the specified policy map to the input
interface.
Step 3
Router(config-int)# end
Exits interface configuration mode.
In the following example, the service policy set_experimental_5 is attached to an Ethernet input
interface:
Router(config)# interface ethernet 1/0/0
Router(config-int)# service-policy input set_experimental_5
Router(config-int)# end
Using CAR to Configure the Ingress Label Switching Router
To use CAR to configure the ingress label switching router, perform the following steps:
Step 1
Configure an IP rate-limit access list for classifying IP packets according to their IP precedence. Perform
this step at PE1 (the ingress LSR).
Step 2
Configure a rate limit on an input interface to set MPLS packets. (Write the classification of the packet
into the MPLS experimental field.)
Cisco IOS Switching Services Configuration Guide
XC-167
Configuring Multiprotocol Label Switching
Configuring MPLS QoS
These steps are explained in the following sections.
Configuring a Rate Limit Access List for Classifying IP Packets
To configure a rate limit access list, use the following commands beginning in global configuration
mode:
Command
Purpose
Step 1
Router(config)# access-list rate-limit acl-index
precedence
Specifies the criteria to be matched.
Step 2
Router(config)# end
Exits configuration mode.
In the following example, all packets that contain IP Precedence 4 are matched by the rate-limit access
list 24:
Router(config)# access-list rate-limit 24 4
Router(config)# end
Configuring a Rate-Limit on an Input Interface to Set MPLS Packets
To configure a rate-limit on an input interface, use the following commands beginning in global
configuration mode:
Command
Purpose
Step 1
Router(config)# interface name
Designates the input interface.
Step 2
Router(config-int)# rate-limit input [access-group
[rate-limit]acl-index] bps burst-normal burst-max
conform-action set-mpls-exp-transmit exp exceed-action
set-mpls-exp-transmit exp
Specifies the action to take on packets during label
imposition.
In the following example, the experimental field for the output MPLS packet is set to 4 if the input IP
packets match the access list and conform to the rate. The MPLS experimental field is set to 0 if packets
match access list 24 and exceed the input rate.
Router(config)# interface ethernet 1/0/0
Router(config-int)# rate-limit input access-group rate-limit 24 8000 8000 8000
conform-action set-mpls-exp-transmit 4 exceed-action set-mpls-exp-transmit 0
Configuring the Output IP QoS of the Packet
The output QoS of the packet is determined by the IP header information. For configuration details, refer
to the Cisco IOS Quality of Service Solutions Configuration Guide.
Cisco IOS Switching Services Configuration Guide
XC-168
Configuring Multiprotocol Label Switching
Configuring MPLS QoS
Configuring PVC Mode in a Non-MPLS-Enabled Core
To configure a PVC in a non-MPLS-enabled core, use the following commands beginning in router
configuration mode:
Command
Purpose
Step 1
Router(config)# interface type number point-to-point
Configures a point-to-point ATM subinterface.
Step 2
Router(config-subif)# ip unnumbered Loopback0
Assigns an IP address to the subinterface.
Step 3
Router(config-subif)# pvc 4/40
Creates a PVC on the subinterface.
Step 4
Router(config-if-atm-vc)# random-detect attach
groupname
Activates WRED or dWRED on the interface.
Step 5
Router(config-if-atm-vc)# encapsulation aal5snap
Sets encapsulation type for the PVC.
Step 6
Router(config-subif)# exit
Exits from PVC mode and enters subinterface
mode.
Step 7
Router(config-subif)# tag-switching ip
Enables MPLS IP on the point-to-point interface.
Configuring Multi-VC Mode in a MPLS-Enabled Core
To configure multi-VC mode in an MPLS-enabled core, use the following commands beginning in router
configuration mode:
Note
The default for the multi-VC mode creates four VCs for each MPLS destination.
Command
Purpose
Step 1
Router(config)# interface type number tag-switching
Configures an ATM MPLS subinterface.
Step 2
Router(config-subif)# ip unnumbered Loopback0
Assigns an IP address to the subinterface.
Step 3
Router(config-subif)# tag-switching atm multi-vc
Enables ATM multi-VC mode on the subinterface.
Step 4
Router(config-subif)# tag-switching ip
Enables MPLS on the ATM subinterface.
Cisco IOS Switching Services Configuration Guide
XC-169
Configuring Multiprotocol Label Switching
Configuring MPLS QoS
Configuring Multi-VCs Using the Cos-Map Function
If you do not choose to use the default for configuring label VCs, you can configure fewer label VCs by
using the QoS map function. To use the QoS map function, use the following commands beginning in
router configuration mode:
Command
Purpose
Step 1
Router(config)# tag-switching cos-map cos-map number
Creates a QoS map.
Step 2
Router(config-tag-cos-map)# class 1 premium
Enters the cos-map submode and maps premium
and standard classes to label VCs.
This QoS map assigns class 1 traffic to share the
same label VC as class 2 traffic. The numbers you
assign to the QoS map range from 0 to 3.
The defaults are:
•
class 0 is available
•
class 1 is standard
•
class 2 is premium
•
class 3 is control
Step 3
Router(config-tag-cos-map)# exit
Exits the MPLS QoS map submode.
Step 4
Router(config)# access-list access-list-number permit
destination
Creates an access list.
The access list acts on traffic going to the
specified destination address.
Step 5
Router(config)# tag-switching prefix-map prefix-map
access-list access-list cos-map cos-map
Configures the router to use a specified QoS map
when an MPLS destination prefix matches the
specified access list.
Configuring DWFQ and Changing Queue Weights on an Outgoing Interface
To configure distributed WFQ (dWFQ) and change queue weights on an interface, use the following
commands in interface configuration mode after specifying the interface:
Command
Purpose
Step 1
Router(config)# interface type number
Specifies the interface type and number.
Step 2
Router(config-if)# fair-queue tos
Configures an interface to use fair queueing.
Step 3
Router(config)# fair-queue tos class weight
Changes the class weight on the specified
interface.
Cisco IOS Switching Services Configuration Guide
XC-170
Configuring Multiprotocol Label Switching
Configuring the MPLS Label Switch Controller
Verifying QoS Operation
To verify the operation of MPLS QoS, use the following EXEC commands:
Command
Purpose
Step 1
Router# show tag-switching interfaces interfaces
Displays detailed information about label
switching interfaces.
Step 2
Router# show tag-switching cos-map
Displays the QoS map used to assign VCs.
Step 3
Router# show tag-switching prefix-map
Displays the prefix map used to assign a QoS map
to network prefixes.
Configuring the MPLS Label Switch Controller
To enable MPLS LSC functionality, perform the tasks described in the following sections. The first two
sections are required tasks; the remaining task is optional:
•
Configuring MPLS on the Cisco 7200 Series LSCs for BPX and IGX Switches (Required)
•
Configuring the Cisco 6400 UAC LSC (Required)
•
Verifying MPLS LSC Configuration (Optional)
Refer to the Cisco BPX 8600 or IGX 8400 series documentation for BPX or IGX service node
configuration examples.
Configuring MPLS on the Cisco 7200 Series LSCs for BPX and IGX Switches
To configure MPLS on the Cisco 7200 Series LSCs for BPX and IGX switches, use the following
commands on each LSC in the configuration beginning in router configuration mode.
Note
If you are configuring for LSC redundancy, ensure that the controller ID matches the slave and is
unique to the LSC system. Also, make sure that the VPI/VC value for the control VC matches its peer.
Command
Purpose
Step 1
Router(config)# interface loopback0
Router(config-if)# ip address 192.103.210.5
255.255.255.255
Enables a loopback interface. A loopback
interface provides stable router and LDP
identifiers.
Step 2
Router(config)# tag-switching atm disable-headend-vc
Forces the LSC not to assign headend VCs for
each destination prefix. With downstream on
demand, MPLS ATM networks LVCs are a limited
resource that are easily depleted with the addition
of each new node.
Cisco IOS Switching Services Configuration Guide
XC-171
Configuring Multiprotocol Label Switching
Configuring the MPLS Label Switch Controller
Step 3
Command
Purpose
Router(config)# interface atm1/0
Router(config-if)# tag-control-protocol vsi id 1
Enables the VSI protocol on the control interface
ATM1/0 with controller ID 1. (Use a unique ID for
each LSC.)
For the IGX, use the tag-control-protocol vsi
slaves 32 id 1 command.
Step 4
Router(config-if)# interface XTagATM61
Router(config-if)# extended-port atm1/0 bpx 6.1
Configures MPLS on the extended label ATM
interface by creating an extended label ATM
(XTagATM) virtual interface and binding it to
BPX port 6.1.
For the IGX, use the extended-port atm1/0
descriptor 0.6.1.0 command.
Step 5
Step 6
Router(config-if)#
Router(config-if)#
Router(config-if)#
Router(config-if)#
ip unnumbered loopback0
tag-switching atm vpi 2-5
tag-switching ip
exit
Router(config-if)# interface XTagATM1222
Router(config-if)# extended-port atm1/0 bpx 12.2.2
Configures MPLS on the extended label
ATM interface.
Limit the range so that the total number of VPIs
does not exceed 4. For example:
tag-switching atm vpi 2-5
tag-switching atm vpi 10-13
Configures MPLS on another extended label ATM
interface by creating an extended label ATM
(XTagATM) virtual interface and binding it to
BPX virtual trunk interface 12.2.2.
For the IGX, use the extended-port atm1/0
descriptor 0.12.2.2 command.
Step 7
Step 8
Router(config-if)#
Router(config-if)#
Router(config-if)#
Router(config-if)#
ip unnumbered loopback0
tag-switching atm vp-tunnel 2
tag-switching ip
exit
Router(config)# ip cef
Configures MPLS on the extended label
ATM interface using a VP-tunnel interface.
This will limit the VPI to only vpi = 2. The
command will also map tag atm control vc
to 2,32.
Enables CEF switching.
Configuring the Cisco 6400 UAC LSC
To configure a Cisco 6400 UAC LSC, perform the tasks in the following sections. The first section
contains a required task; the remaining task is optional:
•
Configuring Cisco 6400 UAC NRP as an MPLS LSC (Required)
•
Configuring the Cisco 6400 UAC NSP for MPLS Connectivity to BPX (Optional)
Cisco IOS Switching Services Configuration Guide
XC-172
Configuring Multiprotocol Label Switching
Configuring the MPLS Label Switch Controller
Configuring Cisco 6400 UAC NRP as an MPLS LSC
To configure a Cisco 6400 UAC NRP as an MPLS LSC, use the following commands beginning in global
configuration mode:
Command
Purpose
Step 1
Router(config)# interface loopback0
Router(config-if)# ip address 192.103.210.5
255.255.255.255
Enables a loopback interface. A loopback
interface provides stable router and LDP
identifiers.
Step 2
Router(config)# interface atm0/0/0
Router(config-if)# tag-control-protocol vsi
Enables the VSI protocol on the control interface
ATM0/0/0.
Step 3
Router(config-if)# interface XTagATM61
Router(config-if)# extended-port atm1/0 bpx 6.1
Configures MPLS on the extended label ATM
interface by creating an extended label ATM
(XTagATM) virtual interface and binding it to
BPX port 6.1.
Step 4
Router(config-if)#
Router(config-if)#
Router(config-if)#
Router(config-if)#
Configures MPLS on the extended label
ATM interface.
ip unnumbered loopback0
tag-switching atm vpi 2-5
tag-switching ip
exit
Limit the range so that the total number of VPIs
does not exceed 4. For example:
tag-switching atm vpi 2-5
tag-switching atm vpi 10-13
Step 5
Router(config-if)# interface XTagATM122
Router(config-if)# extended-port atm1/0 bpx 12.2
Configures MPLS on the other extended label
ATM interface by creating an extended label ATM
(XTagATM) virtual interface and binding it to
BPX port 12.2.
Step 6
Router(config-if)#
Router(config-if)#
Router(config-if)#
Router(config-if)#
Configures MPLS on the extended label
ATM interface.
ip unnumbered loopback0
tag-switching atm vpi 2-5
tag-switching ip
exit
Limits the range so that the total number of VPIs
does not exceed 4. For example:
tag-switching atm vpi 2-5
tag-switching atm vpi 10-13
Step 7
Router(config)# ip cef
Enables CEF switching.
Step 8
Router(config)# tag-switching atm disable-headend-vc
Disables headend VC label advertisement.
Configuring the Cisco 6400 UAC NSP for MPLS Connectivity to BPX
To configure a Cisco 6400 UAC NSP for MPLS connectivity to BPX, use the following commands
beginning in global configuration mode:
Command
Purpose
Step 1
Switch# show hardware
3/0
NRP
00-0000-00 .......
Displays the hardware connected to the
Cisco 6400 UAC, including the position (3/0) of
the NRP in the Cisco 6400 chassis.
Step 2
Switch(config)# interface atm3/0/0
Specifies the ATM interface for which you want to
configure PVCs and PVPs.
Cisco IOS Switching Services Configuration Guide
XC-173
Configuring Multiprotocol Label Switching
Configuring the MPLS Label Switch Controller
Command
Step 3
Purpose
Switch(config-if)#
atm pvc 0 40 interface
atm pvc 0 41 interface
atm pvc 0 42 interface
atm pvc 0 43 interface
atm pvc 0 44 interface
atm pvc 0 45 interface
atm pvc 0 46 interface
atm pvc 0 47 interface
atm pvc 0 48 interface
atm pvc 0 49 interface
atm pvc 0 50 interface
atm pvc 0 51 interface
atm pvc 0 52 interface
atm pvc 0 53 interface
ATM1/0/0
ATM1/0/0
ATM1/0/0
ATM1/0/0
ATM1/0/0
ATM1/0/0
ATM1/0/0
ATM1/0/0
ATM1/0/0
ATM1/0/0
ATM1/0/0
ATM1/0/0
ATM1/0/0
ATM1/0/0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
40
41
42
43
44
45
46
47
48
49
50
51
52
53
Configures the PVC for the VSI control channel,
depending on which of the 14 slots in the
Cisco BPX is occupied by a Cisco BXM. If you do
not know the BPX slots containing a BXM,
configure all 14 PVCs to ensure that the NSP
functions properly.
Note
Do not enable MPLS on this interface.
However, if you know that Cisco BPX slots 10 and
12, for example, contain a BXM, you only need to
configure PVCs corresponding to those slots, as
follows:
atm pvc 0 49 interface ATM1/0/0 0 49
atm pvc 0 51 interface ATM1/0/0 0 51
Instead of configuring multiple PVCs, you can
configure PVP 0 by deleting all well-known VCs.
For example, you can use the atm
manual-well-known-vc delete command on both
interfaces and then configure PVP 0, as follows:
atm pvp 0 interface ATM1/0/0 0
Step 4
Switch(config-if)#
atm pvp 2 interface
atm pvp 3 interface
atm pvp 4 interface
atm pvp 5 interface
ATM1/0/0
ATM1/0/0
ATM1/0/0
ATM1/0/0
2
3
4
5
Cisco IOS Switching Services Configuration Guide
XC-174
Configures the PVPs for the LVCs. For XTagATM
interfaces, use the VPI range 2 through 5 (by
issuing a tag-switching atm vpi 2-5 command). If
you want to use some other VPI range, configure
the PVPs accordingly.
Configuring Multiprotocol Label Switching
Configuring MPLS Egress NetFlow Accounting
Verifying MPLS LSC Configuration
To verify your MPLS LSC configuration, use the following commands in EXEC mode:
Command
Purpose
Step 1
Router# show controller vsi session
Displays the VSI session state.
Step 2
Router# show tag-switching interfaces
Displays the MPLS-enabled interface states.
Step 3
Router# show controllers vsi control-interface
Displays information about an ATM interface that
controls an external ATM switch or VSI control
interface.
Step 4
Router# show interface XTagATM
Displays information about an extended MPLS
ATM interface.
Step 5
Router# show tag-switching tdp discovery
Displays information about the discovery of
MPLS neighbors.
Step 6
Router# show tag-switching tdp neighbor
Displays information about the MPLS neighbor
relationship.
Step 7
Router# show tag-switching atm capabilities
Displays information about negotiated of TDP or
LDP control VPs.
Step 8
Router# show tag-switching atm-tdp bindings
Displays the current headend, tailend, and transit
dynamic tag bindings for the destinations.
Step 9
Router# show tag-switching atm-tdp bindwait
Displays the tag VCs that are in bindwait state
along with their destinations.
Step 10
Router# show tag-switching atm summary
Displays summary information about the number
of destination networks discovered via routing
protocol and the LVCs created on each extended
label ATM interface.
Configuring MPLS Egress NetFlow Accounting
To configure MPLS egress NetFlow, perform the tasks described in the following sections. The first
section contains a required task; the remaining tasks are optional:
•
Enabling MPLS Egress NetFlow Accounting (Required)
•
Configuring NetFlow Aggregation Cache (Optional)
•
Troubleshooting MPLS Egress NetFlow Accounting (Optional)
•
Verifying MPLS Egress NetFlow Accounting Configuration (Optional)
•
Monitoring and Maintaining MPLS Egress NetFlow Accounting (Optional)
Cisco IOS Switching Services Configuration Guide
XC-175
Configuring Multiprotocol Label Switching
Configuring MPLS Egress NetFlow Accounting
Enabling MPLS Egress NetFlow Accounting
To enable MPLS egress NetFlow accounting, use the following command in interface configuration
mode:
Command
Purpose
Router(config-if)# mpls netflow egress
Enables MPLS egress NetFlow accounting on the egress
router interface.
Configuring NetFlow Aggregation Cache
To configure NetFlow aggregation cache, use the following global configuration command:
Command
Purpose
Router(config)# ip flow-aggregation cache as
destination-prefix | prefix | protocol-port |
source-prefix
|
Enters aggregation cache configuration mode and enables
an aggregation cache scheme (as, destination-prefix, prefix,
protocol-port, or source-prefix).
For more information on NetFlow aggregation, see the
“Related Documents” section.
Troubleshooting MPLS Egress NetFlow Accounting
To troubleshoot the MPLS egress NetFlow accounting feature, use the following commands in EXEC
mode, as needed:
Command
Purpose
Router# show mpls forwarding-table detail
Displays detailed MPLS forwarding-table entries.
The output has been modified to show if MPLS
egress NetFlow accounting is applied to packets
destined to an entry. This is for debugging
purposes only.
Router# show mpls interfaces internal all
Displays detailed information about all of the
MPLS interfaces in the router. The output has been
modified to show if MPLS egress NetFlow
accounting is enabled on the interface. This is for
debugging purposes only.
Cisco IOS Switching Services Configuration Guide
XC-176
Configuring Multiprotocol Label Switching
Configuring MPLS Egress NetFlow Accounting
Verifying MPLS Egress NetFlow Accounting Configuration
To verify MPLS egress NetFlow accounting configuration, perform the following steps:
Step 1
Note
Enter the show ip cache flow EXEC command to display a summary of NetFlow switching statistics.
This is an existing command that displays ingress and egress NetFlow statistics.
Router# show ip cache flow
IP packet size distribution (10 total packets):
1-32
64
96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .000 .000 1.00 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 4456704 bytes
1 active, 65535 inactive, 2 added
26 ager polls, 0 flow alloc failures
last clearing of statistics never
Protocol
Total
Flows
Packets Bytes
-------Flows
/Sec
/Flow /Pkt
ICMP
1
0.0
5
100
Total :
1
0.0
5
100
SrcIf
Et1/1
SrcIPaddress
34.0.0.2
DstIf
Et1/4
Packets Active(Sec) Idle(Sec)
/Sec
/Flow
/Flow
0.0
0.0
15.7
0.0
0.0
15.7
DstIPaddress
180.1.1.2
Pr SrcP DstP
01 0000 0800
Pkts
5
Table 32 describes the fields in the flow switching cache lines of the output.
Table 32
show ip cache flow Field Descriptions—Flow Switching Cache
Field
Description
IP packet size distribution
The two lines below this banner show the percentage distribution of
packets by size range.
bytes
Number of bytes of memory the NetFlow cache uses.
active
Number of active flows in the NetFlow cache at the time this
command is entered.
inactive
Number of flow buffers that are allocated in the NetFlow cache but
are not assigned to a specific flow at the time this command is
entered.
added
Number of flows created since the start of the summary period.
ager polls
Number of times the NetFlow code looked at the cache to remove
expired entries (used by Cisco for diagnostics only).
flow alloc failures
Number of times the NetFlow code tried to allocate a flow but could
not.
last clearing of statistics
Standard time output (hh:mm:ss) since the clear ip flow stats EXEC
command was executed. This time output changes to hours and days
after 24 hours is exceeded.
Cisco IOS Switching Services Configuration Guide
XC-177
Configuring Multiprotocol Label Switching
Configuring MPLS Egress NetFlow Accounting
Table 33 describes the fields in the activity-by-protocol lines of the output.
Table 33
show ip cache flow Field Descriptions—Activity-by-Protocol
Field
Description
Protocol
IP protocol and the “well known” port number as described in
RFC 1340.
Total Flows
Number of flows for this protocol since the last time statistics were
cleared.
Flows/Sec
Average number of flows for this protocol seen per second; equal to
total flows/number of seconds for this summary period.
Packets/Flow
Average number of packets observed for the flows seen for this
protocol. Equal to total packets for this protocol/number of flows for
this protocol for this summary period.
Bytes/Pkt
Average number of bytes observed for the packets seen for this
protocol (total bytes for this protocol and the total number of packet
for this protocol for this summary period).
Packets/Sec
Average number of packets for this protocol per second (total
packets for this protocol and the total number of seconds for this
summary period).
Active(Sec)/Flow
Sum of all the seconds from the first packet to the last packet of an
expired flow (for example, TCP FIN, time out, and so on) in
seconds/total flows for this protocol for this summary period.
Idle(Sec)/Flow
Sum of all the seconds from the last packet seen in each nonexpired
flow for this protocol until the time this command was entered, in
seconds/total flows for this protocol for this summary period.
Table 34 describes the fields in the current flow lines of the output.
Table 34
Step 2
show ip cache flow Field Descriptions—Current Flow
Field
Description
SrcIf
Internal port name of the router for the source interface.
SrcIPaddress
Source IP address for this flow.
DstIf
Internal port name of the router for the destination interface.
DstIPaddress
Destination IP address for this flow.
Pr
IP protocol; for example, 6 = TCP, 17 = UDP, ... as defined in
RFC 1340.
SrcP
Source port address, TCP/UDP “well known” port number, as
defined in RFC 1340.
DstP
Destination port address, TCP/UDP “well known” port number, as
defined in RFC 1340.
Pkts
Number of packets that the router observed for this flow.
Enter the show ip cache flow aggregation EXEC command to display the contents of the aggregation
cache. To display the prefix-based aggregation cache, use the following EXEC commands:
Cisco IOS Switching Services Configuration Guide
XC-178
Configuring Multiprotocol Label Switching
Configuring MPLS Egress NetFlow Accounting
Router# show ip cache flow agg
Router# show ip cache flow aggregation pref
Router# show ip cache flow aggregation prefix
IP Flow Switching Cache, 278544 bytes
1 active, 4095 inactive, 1 added
4 ager polls, 0 flow alloc failures
Src If
Et1/1
Router#
Src Prefix
34.0.0.0
Msk
/8
Dst If
Et1/4
Dst Prefix
180.1.1.0
Msk Flows
/24
1
Pkts
5
Table 35 describes the fields in the flow switching cache lines of the output.
Table 35
show ip cache flow aggregation prefix Field Descriptions—Flow Switching Cache
Field
Description
bytes
Number of bytes of memory the NetFlow cache uses.
active
Number of active flows in the NetFlow cache at the time this
command is entered.
inactive
Number of flow buffers that are allocated in the NetFlow cache but
are not assigned to a specific flow at the time this command is
entered.
added
Number of flows created since the start of the summary period.
ager polls
Number of times the NetFlow code looked at the cache to remove
expired entries (used by Cisco for diagnostics only).
flow alloc failures
Number of times the NetFlow code tried to allocate a flow but could
not.
Cisco IOS Switching Services Configuration Guide
XC-179
Configuring Multiprotocol Label Switching
Configuring MPLS Egress NetFlow Accounting
Table 36 describes the fields in the current flow lines of the output.
Table 36
show ip cache flow aggregation prefix Field Descriptions—Current Flow
Field
Description
Src If
Router’s internal port name for the source interface.
Src Prefix
Source IP address for this flow.
Msk
Mask source.
Dst If
Router's internal port name for the destination interface.
Dst Prefix
Destination prefix aggregation cache scheme.
Msk
Mask destination.
Flows
Number of flows.
Pkts
Number of packets that the router observed for this flow.
The ip flow-aggregation cache command has other options, including the following:
{as | destination-prefix | prefix | protocol-port | source-prefix}
Note
For more information on these options, refer to the NetFlow Aggregation documentation.
Here is sample configuration output from the NetFlow aggregation cache:
Router(config)# ip flow-agg
Router(config)# ip flow-aggregation cache
Router(config)# ip flow-aggregation cache ?
as
AS aggregation
destination-prefix Destination Prefix aggregation
prefix
Prefix aggregation
protocol-port
Protocol and port aggregation
source-prefix
Source Prefix aggregation
Router(config)# ip flow-aggregation cache prefix
Router(config-flow-cache)# enable
Here is sample output displaying the IP aggregation cache contents:
Router# show ip cache flow aggregation ?
as
AS aggregation cache
destination-prefix Destination Prefix aggregation cache
prefix
Source/Destination Prefix aggregation cache
protocol-port
Protocol and port aggregation cache
source-prefix
Source Prefix aggregation cache
Router# show ip cache flow
IP packet size distribution (206 total packets):
1-32
64
96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .854 .000 .145 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 4292920 bytes
0 active, 62977 inactive, 182 added
2912 ager polls, 0 flow alloc failures
Active flows timeout in 30 minutes
Inactive flows timeout in 15 seconds
Cisco IOS Switching Services Configuration Guide
XC-180
Configuring Multiprotocol Label Switching
Verifying Configuration of MPLS Forwarding
last clearing of statistics never
Protocol
Total
Flows
Packets Bytes
-------Flows
/Sec
/Flow /Pkt
ICMP
182
0.0
1
62
Total :
182
0.0
1
62
SrcIf
SrcIPaddress
DstIf
Packets Active(Sec) Idle(Sec)
/Sec
/Flow /Flow
0.0
0.0 15.5
0.0
0.0 15.5
DstIPaddress
Pr SrcP DstP
Pkts
Msk Flows
/32 1
Pkts
5
Router# show ip cache flow aggregation prefix
IP Flow Switching Cache, 278544 bytes
1 active, 4095 inactive, 3 added
45 ager polls, 0 flow alloc failures
Active flows timeout in 30 minutes
Inactive flows timeout in 15 seconds
Src If
Et1/1
Router#
Src Prefix
34.0.0.0
Msk
/8
Dst If
PO6/0
Dst Prefix
12.12.12.12
Monitoring and Maintaining MPLS Egress NetFlow Accounting
To monitor and maintain MPLS egress NetFlow accounting, use the following command in EXEC mode:
Command
Purpose
Router# show ip cache flow
Displays summary NetFlow switching statistics,
including the size of the packets, types of traffic,
which interfaces the traffic enters and exits, and
the source and destination addresses in the
forwarded packet.
Verifying Configuration of MPLS Forwarding
To verify that CEF has been configured properly, enter the show ip cef summary command, which
generates output similar to the following:
Router# show ip cef summary
IP CEF with switching (Table Version 49), flags=0x0
43 routes, 0 resolve, 0 unresolved (0 old, 0 new)
43 leaves, 49 nodes, 56756 bytes, 45 inserts, 2 invalidations
2 load sharing elements, 672 bytes, 2 references
1 CEF resets, 4 revisions of existing leaves
4 in-place modifications
refcounts: 7241 leaf, 7218 node
Adjacency Table has 18 adjacencies
Router#
Cisco IOS Switching Services Configuration Guide
XC-181
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
MPLS Configuration Examples
This section provides the following MPLS configuration examples:
•
Enabling MPLS Incrementally in a Network Example
•
Enabling MPLS for a Subset of Destination Prefixes Example
•
Selecting the Destination Prefixes and Paths Example
•
Displaying MPLS LDP Binding Information Example
•
Displaying MPLS Forwarding Table Information Example
•
Displaying MPLS Interface Information Example
•
Displaying MPLS LDP Neighbor Information Example
•
Enabling LSP Tunnel Signalling Example
•
Configuring an LSP Tunnel Example
•
Displaying the LSP Tunnel Information Example
•
Configuring MPLS Traffic Engineering Examples
•
Configuring MPLS VPNs Example
•
Implementing MPLS QoS Example
•
Configuring an MPLS LSC Examples
•
MPLS Egress NetFlow Accounting Example
Enabling MPLS Incrementally in a Network Example
The following example shows how to configure MPLS incrementally throughout a network of routers.
You enable MPLS first between one pair of routers (in this case, R1 and R3 shown in Figure 51) and add
routers step by step until every router in the network is label switch enabled.
router-1# configuration terminal
router-1(config)# ip cef distributed
router-1(config)# tag-switching ip
router-1(config)# interface e0/1
router-1(config-if)# tag-switching ip
router-1(config-if)# exit
router-1(config)#
router-3# configuration terminal
router-3(config)# ip cef distributed
router-3(config)# tag-switching ip
router-3(config)# interface e0/1
router-3(config-if)# tag-switching ip
router-3(config-if)# exit
router-3(config)#
Enabling MPLS for a Subset of Destination Prefixes Example
The following example shows the commands you enter at each of the routers to enable MPLS for only a
subset of destination prefixes (see Figure 51).
Router(config)# access-list-1 permit A
Router(config)# tag-switching advertise-tags for 1
Cisco IOS Switching Services Configuration Guide
XC-182
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Selecting the Destination Prefixes and Paths Example
The following example shows the commands you enter to configure the routers to select the destination
prefixes and paths for which MPLS is enabled. When you configure R2, R5, and R8 to distribute no
labels to other routers, you ensure that no routers send them labeled packets. You also need to configure
routers R1, R3, R4, R6, and R7 to distribute labels only for network A and only to the applicable adjacent
router. This configuration ensures that R3 distributes its label for network A only to R1, R4 only to R3,
R6 only to R4, and R7 only to R6 (see Figure 51).
router-2(config)#
router-5(config)#
router-8(config)#
router-1(config)#
router-1(config)#
router-1(config)#
router-1(config)#
no tag-switching advertise-tags
no tag-switching advertise-tags
no tag-switching advertise-tags
access-list permit R1
no tag-switching advertise-tags for 1
tag-switching advertise-tags for 1 to 2
exit
router-3#
router-3#
router-3#
router-3#
access-list 1 permit A
access-list 2 permit R1
tag-switching advertise-tags for 1 to 2
exit
router-4#
router-4#
router-4#
router-4#
access-list 1 permit A
access-list 2 permit R3
tag-switching advertise-tags for 1 to 2
exit
router-6#
router-6#
router-6#
router-6#
router-7#
router-7#
router-7#
router-7#
access-list 1
access-list 2
tag-switching
exit
access-list 1
access-list 2
tag-switching
exit
permit A
permit R4
advertise-tags for 1 to 2
permit A
permit R6
advertise-tags for 1 to 2
Displaying MPLS LDP Binding Information Example
The following example shows how to use the show tag-switching tdp bindings EXEC command to
display the contents of the Label Information Base (LIB). The display can show the entire database or
can be limited to a subset of entries, based on prefix, input or output label values or ranges, or the
neighbor advertising the label.
Note
This command displays downstream mode bindings. For label VC bindings, see the show
tag-switching atm-tdp bindings EXEC command.
Router# show tag-switching tdp bindings
Matching entries:
tib entry: 10.92.0.0/16, rev 28
local binding: tag: imp-null(1)
remote binding: tsr: 172.27.32.29:0, tag: imp-null(1)
tib entry: 10.102.0.0/16, rev 29
local binding: tag: 26
remote binding: tsr: 172.27.32.29:0, tag: 26
tib entry: 10.105.0.0/16, rev 30
local binding: tag: imp-null(1)
Cisco IOS Switching Services Configuration Guide
XC-183
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
remote binding: tsr: 172.27.32.29:0,
tib entry: 10.205.0.0/16, rev 31
local binding: tag: imp-null(1)
remote binding: tsr: 172.27.32.29:0,
tib entry: 10.211.0.7/32, rev 32
local binding: tag: 27
remote binding: tsr: 172.27.32.29:0,
tib entry: 10.220.0.7/32, rev 33
local binding: tag: 28
remote binding: tsr: 172.27.32.29:0,
tib entry: 99.101.0.0/16, rev 35
local binding: tag: imp-null(1)
remote binding: tsr: 172.27.32.29:0,
tib entry: 100.101.0.0/16, rev 36
local binding: tag: 29
remote binding: tsr: 172.27.32.29:0,
tib entry: 171.69.204.0/24, rev 37
local binding: tag: imp-null(1)
remote binding: tsr: 172.27.32.29:0,
tib entry: 172.27.32.0/22, rev 38
local binding: tag: imp-null(1)
remote binding: tsr: 172.27.32.29:0,
tib entry: 210.10.0.0/16, rev 39
local binding: tag: imp-null(1)
tib entry: 210.10.0.8/32, rev 40
remote binding: tsr: 172.27.32.29:0,
tag: imp-null(1)
tag: imp-null(1)
tag: 28
tag: 29
tag: imp-null(1)
tag: imp-null(1)
tag: imp-null(1)
tag: imp-null(1)
tag: 27
Displaying MPLS Forwarding Table Information Example
The following example shows how to use the show tag-switching forwarding-table command to
display the contents of the LFIB. The LFIB lists the labels, output interface information, prefix or tunnel
associated with the entry, and number of bytes received with each incoming label. A request can show
the entire LFIB or can be limited to a subset of entries. A request can also be restricted to selected entries
in any of the following ways:
•
Single entry associated with a given incoming label
•
Entries associated with a given output interface
•
Entries associated with a given next hop
•
Single entry associated with a given destination
•
Single entry associated with a given tunnel having the current node as an intermediate hop
Router# show tag-switching forwarding-table
Local
tag
26
28
29
30
34
35
36
Outgoing
Prefix
tag or VC
or Tunnel Id
Untagged
10.253.0.0/16
1/33
10.15.0.0/16
Pop tag
10.91.0.0/16
1/36
10.91.0.0/16
32
10.250.0.97/32
32
10.250.0.97/32
26
10.77.0.0/24
26
10.77.0.0/24
Untagged [T] 10.100.100.101/32
Pop tag
168.1.0.0/16
1/37
168.1.0.0/16
Cisco IOS Switching Services Configuration Guide
XC-184
Bytes tag
switched
0
0
0
0
0
0
0
0
0
0
0
Outgoing
interface
Et4/0/0
AT0/0.1
Hs5/0
AT0/0.1
Et4/0/2
Hs5/0
Et4/0/2
Hs5/0
Tu301
Hs5/0
AT0/0.1
Next Hop
172.27.32.4
point2point
point2point
point2point
10.92.0.7
point2point
10.92.0.7
point2point
point2point
point2point
point2point
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
[T]
Forwarding through a TSP tunnel.
View additional tagging info with the 'detail' option
Displaying MPLS Interface Information Example
The following example shows how to use the show tag-switching interfaces command to show
information about the requested interface or about all interfaces on which MPLS is enabled.
The per-interface information includes the interface name and indications as to whether IP MPLS is
enabled and operational.
Router# show tag-switching interfaces
Interface
Hssi3/0
ATM4/0.1
Ethernet5/0/0
Ethernet5/0/1
Ethernet5/0/2
Ethernet5/0/3
Ethernet5/1/1
IP
Yes
Yes
No
Yes
Yes
Yes
Yes
Tunnel
Yes
Yes
Yes
No
No
No
No
Operational
No
Yes
(ATM tagging)
Yes
Yes
No
Yes
No
The following shows sample output from the show tag-switching interfaces command when you
specify the detail keyword:
Router# show tag-switching interfaces detail
Interface Hssi3/0:
IP tagging enabled
TSP Tunnel tagging enabled
Tagging not operational
MTU = 4470
Interface ATM4/0.1:
IP tagging enabled
TSP Tunnel tagging enabled
Tagging operational
MTU = 4470
ATM tagging: Tag VPI = 1, Control VC = 0/32
Interface Ethernet5/0/0:
IP tagging not enabled
TSP Tunnel tagging enabled
Tagging operational
MTU = 1500
Interface Ethernet5/0/1:
IP tagging enabled
TSP Tunnel tagging not enabled
Tagging operational
MTU = 1500
Interface Ethernet5/0/2:
IP tagging enabled
TSP Tunnel tagging not enabled
Tagging not operational
MTU = 1500
Interface Ethernet5/0/3:
IP tagging enabled
TSP Tunnel tagging not enabled
Tagging operational
MTU = 1500
Cisco IOS Switching Services Configuration Guide
XC-185
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Displaying MPLS LDP Neighbor Information Example
The following example shows how to use the show tag-switching tdp neighbors EXEC command to
display the status of LDP sessions. The neighbor information branch can have information about all LDP
neighbors or can be limited to the neighbor with a specific IP address or LDP identifier, or to LDP
neighbors known to be accessible over a specific interface.
Router# show tag-switching tdp neighbors
Peer TDP Ident: 10.220.0.7:1; Local TDP Ident 172.27.32.29:1
TCP connection: 10.220.0.7.711 - 172.27.32.29.11029
State: Oper; PIEs sent/rcvd: 17477/17487; Downstream on demand
Up time: 01:03:00
TDP discovery sources:
ATM0/0.1
Peer TDP Ident: 210.10.0.8:0; Local TDP Ident 172.27.32.29:0
TCP connection: 210.10.0.8.11004 - 172.27.32.29.711
State: Oper; PIEs sent/rcvd: 14656/14675; Downstream;
Up time: 2d5h
TDP discovery sources:
Ethernet4/0/1
Ethernet4/0/2
POS6/0/0
Addresses bound to peer TDP Ident:
99.101.0.8
172.27.32.28
10.105.0.8
10.92.0.8
10.205.0.8
210.10.0.8
Enabling LSP Tunnel Signalling Example
The following example shows how to configure support for LSP tunnel signalling along a path and on
each interface crossed by one or more tunnels:
Router(config)# ip cef distributed
Router(config)# tag-switching tsp-tunnels
Router(config)# interface e0/1
Router(config-if)# tag-switching tsp-tunnels
Router(config-if)# interface e0/2
Router(config-if)# tag-switching tsp-tunnels
Router(config-if)# exit
Configuring an LSP Tunnel Example
The following example shows how to set the encapsulation of the tunnel to MPLS and how to define hops
in the path for the LSP.
Follow these steps to configure a two-hop tunnel, hop 0 being the headend router. For hops 1 and 2, you
specify the IP addresses of the incoming interfaces for the tunnel. The tunnel interface number is
arbitrary, but must be less than 65,535.
Router(config)# interface
Router(config-if)# tunnel
Router(config-if)# tunnel
Router(config-if)# tunnel
Router(config-if)# exit
tunnel 2003
mode tag-switching
tsp-hop 1 10.10.0.12
tsp-hop 2 10.50.0.24 lasthop
To shorten the previous path, delete the hop by entering the following commands:
Router(config)# interface tunnel 2003
Router(config-if)# no tunnel tsp-hop 2
Cisco IOS Switching Services Configuration Guide
XC-186
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Router(config-if)# tunnel tsp-hop 1 10.10.0.12 lasthop
Router(config-if)# exit
Displaying the LSP Tunnel Information Example
The following example shows how to use the show tag-switching tsp-tunnels command to display
information about the configuration and status of selected tunnels:
Router# show tag-switching tsp-tunnels
Signalling Summary:
TSP Tunnels Process:
RSVP Process:
Forwarding:
running
running
enabled
TUNNEL ID DESTINATION
STATUS
10.106.0.6.200310.2.0.12up up
CONNECTION
Configuring MPLS Traffic Engineering Examples
This section provides the following MPLS traffic engineering configuration examples:
•
Configuring MPLS Traffic Engineering Using IS-IS Example
•
Configuring MPLS Traffic Engineering Using OSPF Example
•
Configuring an MPLS Traffic Engineering Tunnel Example
•
Configuring Enhanced SPF Routing over a Tunnel Example
Figure 53 illustrates a sample MPLS topology. This example specifies point-to-point outgoing
interfaces. The next sections contain sample configuration commands you enter to implement MPLS
traffic engineering and the basic tunnel configuration shown in Figure 53.
Figure 53
Sample MPLS Traffic Engineering Tunnel Configuration
Router 3
12.12.12.12
S1/0
Tu
n
13 nel 2
5.0
.0
.1
S1/3
S1/0
Tunnel 2
S1/2
.1
.2
S1/0
.1
Router 1
11.11.11.11
131.0.0
Tunnel 1
2
el
nn
Tu 6.0.0
13
.2
.2
Router 2
15.15.15.15
S1/0
Tunnel 1
Tunnel 2
S1/1
.1
133.0.0 .2
S1/0
S1/3
Router 4
14.14.14.14
Tunnel 1
26683
S1/1
Router 5
17.17.17.17
Cisco IOS Switching Services Configuration Guide
XC-187
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Configuring MPLS Traffic Engineering Using IS-IS Example
This example lists the commands you enter to configure MPLS traffic engineering with IS-IS routing
enabled (see Figure 53).
Note
You must enter the following commands on every router in the traffic-engineered portion of your
network.
Router 1—MPLS Traffic Engineering Configuration
To configure MPLS traffic engineering, enter the following commands:
ip cef
mpls traffic-eng tunnels
interface loopback 0
ip address 11.11.11.11 255.255.255.255
ip router isis
interface s1/0
ip address 131.0.0.1 255.255.0.0
ip router isis
mpls traffic-eng tunnels
ip rsvp bandwidth 1000
Router 1—IS-IS Configuration
To enable IS-IS routing, enter the following commands:
router isis
network 47.0000.0011.0011.00
is-type level-1
metric-style wide
mpls traffic-eng router-id loopback0
mpls traffic-eng level-1
Configuring MPLS Traffic Engineering Using OSPF Example
This example lists the commands you enter to configure MPLS traffic engineering with OSPF routing
enabled (see Figure 53).
Note
You must enter the following commands on every router in the traffic-engineered portion of your
network.
Router 1—MPLS Traffic Engineering Configuration
To configure MPLS traffic engineering, enter the following commands:
ip cef
mpls traffic-eng tunnels
interface loopback 0
ip address 11.11.11.11 255.255.255.255
interface s1/0
ip address 131.0.0.1 255.255.0.0
mpls traffic-eng tunnels
ip rsvp bandwidth 1000
Cisco IOS Switching Services Configuration Guide
XC-188
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Router 1—OSPF Configuration
To enable OSPF, enter the following commands:
router ospf 0
network 131.0.0.0.0.0.255.255 area 0
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
Configuring an MPLS Traffic Engineering Tunnel Example
This example shows you how to configure a dynamic path tunnel and an explicit path in the tunnel.
Before you configure MPLS traffic engineering tunnels, you must enter the appropriate global and
interface commands on the specified router (in this case, Router 1).
Router 1—Dynamic Path Tunnel Configuration
In this section, a tunnel is configured to use a dynamic path:
interface tunnel1
ip unnumbered loopback 0
tunnel destination 17.17.17.17
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng bandwidth 100
tunnel mpls traffic-eng priority 1 1
tunnel mpls traffic-eng path-option 1 dynamic
Router 1—Dynamic Path Tunnel Verification
This section includes the commands you use to verify that the tunnel is up:
show mpls traffic-eng tunnels
show ip interface tunnel1
Router 1—Explicit Path Configuration
In this section, an explicit path is configured:
ip explicit-path identifier 1
next-address 131.0.0.1
next-address 135.0.0.1
next-address 136.0.0.1
next-address 133.0.0.1
Router 1—Explicit Path Tunnel Configuration
In this section, a tunnel is configured to use an explicit path:
interface tunnel2
ip unnumbered loopback 0
tunnel destination 17.17.17.17
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng bandwidth 100
tunnel mpls traffic-eng priority 1 1
tunnel mpls traffic-eng path-option 1 explicit identifier 1
Cisco IOS Switching Services Configuration Guide
XC-189
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Router 1—Explicit Path Tunnel Verification
This section includes the commands you use to verify that the tunnel is up:
show mpls traffic-eng tunnels
show ip interface tunnel2
Configuring Enhanced SPF Routing over a Tunnel Example
This section includes the commands that cause the tunnel to be considered by the enhanced SPF
calculation of the IGP, which installs routes over the tunnel for appropriate network prefixes.
Router 1—IGP Enhanced SPF Consideration Configuration
In this section, you specify that the IGP should use the tunnel (if the tunnel is up) in its enhanced SPF
calculation:
interface tunnel1
tunnel mpls traffic-eng autoroute announce
Router 1—Route and Traffic Verification
This section includes the commands you use to verify that the tunnel is up and that the traffic is routed
through the tunnel:
show
show
show
ping
show
show
traffic-eng tunnels tunnel1 brief
ip route 17.17.17.17
mpls traffic-eng autoroute
17.17.17.17
interface tunnel1 accounting
interface s1/0 accounting
Configuring MPLS VPNs Examples
This section provides the following configuration examples:
•
Configuring MPLS VPNs Example
•
Defining a Cable Subinterface Example
•
Cable Interface Bundling Example
•
Subinterface Definition on Bundle Master Example
•
Cable Interface Bundle Master Configuration Example
•
Configuring EBGP Routing to Exchange VPN Routes Between Autonomous Systems
•
Configuring EBGP Routing to Exchange VPN Routes Between Autonomous Systems in a
Confederation
Configuring MPLS VPNs Example
The following example provides a sample configuration file from a PE router:
ip cef distributed
frame-relay switching
!
ip vrf vrf1
Cisco IOS Switching Services Configuration Guide
XC-190
! CEF switching is pre-requisite for label Switching
! Define VPN Routing instance vrf1
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
rd 100:1
route-target both 100:1
! Configure import and export route-targets for vrf1
!
ip vrf vrf2
! Define VPN Routing instance vrf2
rd 100:2
route-target both 100:2
! Configure import and export route-targets for vrf2
route-target import 100:1
! Configure an additional import route-target for vrf2
import map vrf2_import
! Configure import route-map for vrf2
!
interface lo0
ip address 10.13.0.13 255.255.255.255
!
interface atm9/0/0
! Backbone link to another Provider router
!
interface atm9/0/0.1 tag-switching
ip unnumbered loopback0
no ip directed-broadcast
tag-switching atm vpi 2-5
tag-switching ip
interface atm5/0
no ip address
no ip directed-broadcast
atm clock INTERNAL
no atm ilmi-keepalive
interface Ethernet1/0
ip address 3.3.3.5 255.255.0.0
no ip directed-broadcast
no ip mroute-cache
no keepalive
! Set up Ethernet interface as VRF link to a CE router
interface Ethernet5/0/1
ip vrf forwarding vrf1
ip address 10.20.0.13 255.255.255.0
!
interface hssi 10/1/0
hssi internal-clock
encaps fr
frame-relay intf-type dce
frame-relay lmi-type ansi
!
interface hssi 10/1/0.16 point-to-point
ip vrf forwarding vrf2
ip address 10.20.1.13 255.255.255.0
frame-relay interface-dlci 16 ! Set up Frame Relay PVC subinterface as link to another
!
! CE router
router bgp 1
! Configure BGP sessions
no synchronization
no bgp default ipv4-activate
! Deactivate default IPv4 advertisements
neighbor 10.15.0.15 remote-as 1
! Define IBGP session with another PE
neighbor 10.15.0.15 update-source lo0
!
address-family vpnv4 unicast
! Activate PE exchange of VPNv4 NLRI
neighbor 10.15.0.15 activate
exit-address-family
!
address-family ipv4 unicast vrf vrf1
! Define BGP PE-CE session for vrf1
redistribute static
redistribute connected
neighbor 10.20.0.60 remote-as 65535
neighbor 10.20.0.60 activate
Cisco IOS Switching Services Configuration Guide
XC-191
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
no auto-summary
exit-address-family
!
address-family ipv4 unicast vrf vrf2
! Define BGP PE-CE session for vrf2
redistribute static
redistribute connected
neighbor 10.20.1.11 remote-as 65535
neighbor 10.20.1.11 update-source h10/1/0.16
neighbor 10.20.1.11 activate
no auto-summary
exit-address-family
!
! Define a VRF static route
ip route vrf vrf1 12.0.0.0 255.0.0.0 e5/0/1 10.20.0.60
!
route-map vrf2_import permit 10
! Define import route-map for vrf2.
...
Defining a Cable Subinterface Example
The following example shows how to define a subinterface on cable3/0:
interface cable3/0
! No IP address
! MAC level configuration only
! first subinterface
interface cable3/0.1
description Management Subinterface
ip address 10.255.1.1 255.255.255.0
cable helper-address 10.151.129.2
! second subinterface
interface cable3/0.2
ip address 10.279.4.2 255.255.255.0
cable helper-address 10.151.129.2
! third subinterface
interface cable3/0.3
ip address 10.254.5.2 255.255.255.0
cable helper-address 10.151.129.2
Cable Interface Bundling Example
The following example shows how to bundle a group of physical interfaces:
interface c3/0
and interface
c4/0
are bundled.
interface c3/0
ip address 209.165.200.225 255.255.255.0
ip address 209.165.201.1 255.255.255.0 secondary
cable helper-address 10.5.1.5
! MAC level configuration
cable bundle 1 master
int c4/0
! No IP address
! MAC layer configuration only
Cisco IOS Switching Services Configuration Guide
XC-192
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
cable bundle 1
Subinterface Definition on Bundle Master Example
The following example shows how to define subinterfaces on a bundle master and define Layer 3
configurations for each subinterface:
interface c3/0 and interface c4/0 are bundled.
interface c3/0
! No IP address
! MAC level configuration only
cable bundle 1 master
interface c4/0
! No IP address
! MAC layer configuration
cable bundle 1
! first subinterface
interface c3/0.1
ip address 10.22.64.0 255.255.255.0
cable helper-address 10.4.1.2
! second subinterface
interface c3/0.2
ip address 10.12.39.0 255.255.255.0
cable helper-address 10.4.1.2
! third subinterface
interface c3/0.3
ip address 10.96.3.0 255.255.255.0
cable helper-address 10.4.1.2
Cable Interface Bundle Master Configuration Example
The following examples show how to configure cable interface bundles:
Displaying the contents of the bundle
Router(config-if)# cable bundle ?
<1-255> Bundle number
Router(config-if)# cable bundle 25 ?
master Bundle master
<cr>
Router(config-if)# cable bundle 25 master ?
<cr>
Router(config-if)# cable bundle 25 master
Router(config-if)#
07:28:17: %UBR7200-5-UPDOWN: Interface Cable3/0 Port U0, changed state to down
07:28:18: %UBR7200-5-UPDOWN: Interface Cable3/0 Port U0, changed state to up
PE Router Configuration Example
!
! Identifies the version of Cisco IOS software installed.
version 12.0
! Defines the hostname of the Cisco uBR7246
hostname region-1-ubr
!
! Describes where the system is getting the software image it is running. In
! this configuration example, the system is loading a Cisco uBR7246 image named
Cisco IOS Switching Services Configuration Guide
XC-193
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
! AdamSpecial from slot 0.
boot system flash slot0:ubr7200-p-mz.AdamSpecial
!
! Creates the enable secret password.
enable secret xxxx
enable password xxxx
!
! Sets QoS per modem for the cable plant.
no cable qos permission create
no cable qos permission update
cable qos permission modems
!
! Allows the system to use a full range of IP addresses, including subnet zero, for
! interface addresses and routing updates.
ip subnet-zero
!
! Enables Cisco Express Forwarding.
ip cef
!
! Configures a Cisco IOS Dynamic Host Configuration Protocol (DHCP) server to insert the
! DHCP relay agent information option in forwarded BOOTREQUEST messages.
ip dhcp relay information option
!
! Enters the virtual routing forwarding (VRF) configuration mode and maps a VRF table to
! the virtual private network (VPN) called MGMT-VPN. The VRF table contains the set of
! routes that points to or gives routes to the CNR device, which provisions the cable
! modem devices. Each VRF table defines a path through the MPLS cloud.
ip vrf MGMT-VPN
!
! Creates the route distinguisher and creates the routing and forwarding table of the
! router itself.
rd 100:1
!
! Creates a list of import and/or export route target communities for the VPN.
route-target export 100:2
route-target export 100:3
!
! Maps a VRF table to the VPN called ISP1-VPN.
ip vrf ISP1-VPN
!
! Creates the route distinguisher and creates the routing and forwarding table of the
! router itself.
rd 100:2
!
! Creates a list of import and/or export route target communities for the VPN.
route-target import 100:1
!
! Maps a VRF table to the VPN called ISP2-VPN.
ip vrf ISP2-VPN
!
! Creates the route distinguisher and creates the routing and forwarding table of the
! router itself.
rd 100:3
!
! Creates a list of import and/or export route target communities for the VPN.
route-target import 100:1
!
! Maps a VRF table to the VPN called MSO-isp. Note: MSO-isp could be considered ISP-3; in
! this case, the MSO is competing with other ISPs for other ISP services.
ip vrf MSO-isp
!
! Creates the route distinguisher and creates the routing and forwarding table of the
! router itself.
rd 100:4
Cisco IOS Switching Services Configuration Guide
XC-194
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
!
! Creates a list of import and/or export route target communities for the VPN.
route-target import 100:1
!
! Builds a loopback interface to be used with MPLS and BGP; creating a loopback interface
! eliminates unnecessary updates (caused by physical interfaces going up and down) from
! flooding the network.
interface Loopback0
ip address 10.0.0.0 255.255.255.0
no ip directed-broadcast
!
! Assigns an IP address to this Fast Ethernet interface. MPLS tag-switching must be
! enabled on this interface.
interface FastEthernet0/0
description Connection to MSO core.
ip address 10.0.0.0 255.255.255.0
no ip directed-broadcast
full-duplex
tag-switching ip
!
! Enters cable interface configuration mode and configures the physical aspects of the
! 3/0 cable interface. Please note that no IP addresses are assigned to this interface;
! they will be assigned instead to the logical subinterfaces. All other commands for
! this cable interface should be configured to meet the specific needs of your cable RF
! plant and cable network.
interface Cable3/0
no ip address
ip directed-broadcast
no ip mroute-cache
load-interval 30
no keepalive
cable downstream annex B
cable downstream modulation 64qam
cable downstream interleave-depth 32
cable downstream frequency 855000000
cable upstream 0 frequency 30000000
cable upstream 0 power-level 0
no cable upstream 0 shutdown
cable upstream 1 shutdown
cable upstream 2 shutdown
cable upstream 3 shutdown
cable upstream 4 shutdown
cable upstream 5 shutdown
!
! Configures the physical aspects of the 3/0.1 cable subinterface. If cable modems have
! not been assigned IP addresses, they will automatically come on-line using the settings
! for subinterface X.1.
interface Cable3/0.1
description Cable Administration Network
!
! Associates this interface with the VRF and MPLS VPNs that connect to the MSO cable
! network registrar (CNR). The CNR provides cable modems with IP addresses and other
! initialization parameters.
ip vrf forwarding MSO
!
! Defines a range of IP addresses and masks to be assigned to cable modems not yet
associated with an ISP.
ip address 10.0.0.0 255.255.255.0
!
! Disables the translation of directed broadcasts to physical broadcasts.
no ip directed-broadcast
!
! Defines the DHCP server for cable modems whether they are associated with an ISP or
! with the MSO acting as ISP.
Cisco IOS Switching Services Configuration Guide
XC-195
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
cable helper-address 10.4.1.2 cable-modem
!
! Defines the DHCP server for PCs that are not yet associated with an ISP.
cable helper-address 10.4.1.2 host
!
! Disables cable proxy Address Resolution Protocol (ARP) and IP multicast echo on this
! cable interface.
no cable proxy-arp
no cable ip-multicast-echo
!
! Configures the physical aspects of the 3/0.2 cable subinterface.
interface Cable3/0.2
description MSO as ISP Network
!
! Assigns this subinterface to the MPLS VPN used by the MSO to supply service to
! customers—in this case, MSO-isp.
ip vrf forwarding MSO-isp
!
! Defines a range of IP addresses and masks to be assigned to cable modems associated
! with the MSO as ISP network.
ip address 10.1.0.0 255.255.255.0 secondary
!
! Defines a range of IP addresses and masks to be assigned to host devices associated
! with the MSO as ISP network.
ip address 10.1.0.0 255.255.255.0
!
! Disables the translation of directed broadcasts to physical broadcasts.
no ip directed-broadcast
!
! Defines the DHCP server for cable modems whether they are associated with an ISP or
! with the MSO acting as ISP.
cable helper-address 10.4.1.2 cable-modem
!
! Defines the DHCP server for PC host devices.
cable helper-address 10.4.1.2 host
!
! Disables cable proxy Address Resolution Protocol (ARP) and IP multicast echo on this
! cable interface.
no cable proxy-arp
no cable ip-multicast-echo
!
! Configures the physical aspects of the 3/0.3 cable subinterface
interface Cable3/0.3
description ISP1's Network
!
! Makes this subinterface a member of the MPLS VPN.
ip vrf forwarding isp1
!
! Defines a range of IP addresses and masks to be assigned to cable modems associated
! with the MSO as ISP network.
ip address 10.1.1.1 255.255.255.0 secondary
!
! Defines a range of IP addresses and masks to be assigned to host devices associated
! with the MSO as ISP network.
ip address 10.0.1.1 255.255.255.0
!
! Disables the translation of directed broadcasts to physical broadcasts.
no ip directed-broadcast
!
! Disables cable proxy Address Resolution Protocol (ARP) and IP multicast echo on this
! cable interface.
no cable proxy-arp
no cable ip-multicast-echo
!
Cisco IOS Switching Services Configuration Guide
XC-196
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
! Defines the DHCP server for cable modems whether they are associated with an ISP or
! with the MSO acting as ISP.
cable helper-address 10.4.1.2 cable-modem
!
! Defines the DHCP server for PC host devices.
cable helper-address 10.4.1.2 host
!
! Configures the physical aspects of the 3/0.4 cable subinterface
interface Cable3/0.4
description ISP2's Network
!
! Makes this subinterface a member of the MPLS VPN.
ip vrf forwarding isp2
!
! Defines a range of IP addresses and masks to be assigned to cable modems associated
! with the MSO as ISP network.
ip address 10.1.2.1 255.255.255.0 secondary
!
! Defines a range of IP addresses and masks to be assigned to host devices associated
! with the MSO as ISP network.
ip address 10.0.1.1 255.255.255.0
!
! Disables the translation of directed broadcasts to physical broadcasts.
no ip directed-broadcast
!
! Disables cable proxy Address Resolution Protocol (ARP) and IP multicast echo on this
! cable interface.
no cable proxy-arp
no cable ip-multicast-echo
!
!
cable dhcp-giaddr policy
!
!! Defines the DHCP server for cable modems whether they are associated with an ISP or
! with the MSO acting as ISP.
cable helper-address 10.4.1.2 cable-modem
!
! Defines the DHCP server for PC host devices.
cable helper-address 10.4.1.2 host
!
!
end
P Router Configuration Example
Building configuration...
Current configuration:
!
version 12.0
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname R7460-7206-02
!
enable password xxxx
!
ip subnet-zero
ip cef
ip host brios 223.255.254.253
!
interface Loopback0
ip address 10.2.1.3 255.255.255.0
Cisco IOS Switching Services Configuration Guide
XC-197
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
no ip directed-broadcast
!
interface Loopback1
no ip address
no ip directed-broadcast
no ip mroute-cache
!
interface FastEthernet0/0
ip address 1.7.108.2 255.255.255.0
no ip directed-broadcast
no ip mroute-cache
shutdown
full-duplex
no cdp enable
!
interface Ethernet1/0
ip address 10.0.1.2 255.255.255.0
no ip directed-broadcast
no ip route-cache cef
no ip mroute-cache
tag-switching ip
no cdp enable
!
interface Ethernet1/1
ip address 10.0.1.17 255.255.255.0
no ip directed-broadcast
no ip route-cache cef
no ip mroute-cache
tag-switching ip
no cdp enable
!
interface Ethernet1/2
ip address 10.0.2.2 255.255.255.0
no ip directed-broadcast
no ip route-cache cef
no ip mroute-cache
tag-switching ip
no cdp enable
!
interface Ethernet1/3
ip address 10.0.3.2 255.255.255.0
no ip directed-broadcast
no ip route-cache cef
no ip mroute-cache
tag-switching ip
no cdp enable
!
interface Ethernet1/4
ip address 10.0.4.2 255.255.255.0
no ip directed-broadcast
no ip route-cache cef
no ip mroute-cache
tag-switching ip
no cdp enable
!
interface Ethernet1/5
no ip address
no ip directed-broadcast
no ip route-cache cef
shutdown
no cdp enable
!
interface Ethernet1/6
no ip address
Cisco IOS Switching Services Configuration Guide
XC-198
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
no ip directed-broadcast
no ip route-cache cef
shutdown
no cdp enable
!
interface Ethernet1/7
no ip address
no ip directed-broadcast
no ip route-cache cef
shutdown
no cdp enable
!
router ospf 222
network 10.0.1.0 255.255.255.0 area 0
network 10.0.2.0 255.255.255.0 area 0
network 10.0.3.0 255.255.255.0 area 0
network 10.0.4.0 255.255.255.0 area 0
network 20.2.1.3 255.255.255.0 area 0
!
ip classless
no ip http server
!
!
map-list test-b
no cdp run
!
tftp-server slot0:master/120/c7200-p-mz.120-1.4
!
line con 0
exec-timeout 0 0
password xxxx
login
transport input none
line aux 0
line vty 0 4
password xxxx
login
!
no scheduler max-task-time
Cisco IOS Switching Services Configuration Guide
XC-199
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
end
Configuring EBGP Routing to Exchange VPN Routes Between Autonomous Systems
The network topology in Figure 54 shows two autonomous systems, which are configured as follows:
•
Autonomous system 1 (AS1) includes PE1, P1, EBGP1. The IGP is OSPF.
•
Autonomous system 2 (AS2) includes PE2, P2, EBGP2. The IGP is ISIS.
•
CE1 and CE2 belongs to the same VPN, which is called VPN1.
•
The P routers are route reflectors.
•
EBGP1 is configured with the redistribute connected subnets router configuration command.
•
EBGP2 is configured with the neighbor next-hop-self router configuration command.
Configuring Two Autonomous Systems
VPN1
CE1
PE1
P1
AS1
Autonomous System 1, CE1 Configuration
CE1: Company
!
interface Loopback1
ip address 1.0.0.6 255.255.255.255
!
interface Serial1/3
description Veritas
no ip address
encapsulation frame-relay
frame-relay intf-type dce
!
interface Serial1/3.1 point-to-point
description Veritas
ip address 1.6.2.1 255.255.255.252
frame-relay interface-dlci 22
!
router ospf 1
network 1.0.0.0 0.255.255.255 area 0
Cisco IOS Switching Services Configuration Guide
PE2
AS2
EBGP1
XC-200
P2
EBGP2
VPN1
CE2
47866
Figure 54
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Autonomous System 1, PE1 Configuration
PE1: Company
!
ip cef
!
ip vrf V1
rd 1:105
route-target export 1:100
route-target import 1:100
!
interface Serial0/0
description Burlington
no ip address
encapsulation frame-relay
no fair-queue
clockrate 2000000
!
interface Serial0/0.3 point-to-point
description Burlington
ip vrf forwarding V1
ip address 1.6.2.2 255.255.255.252
frame-relay interface-dlci 22
!
interface Ethernet0/1
description Vermont
ip address 100.2.2.5 255.255.255.0
tag-switching ip
!
router ospf 1
log-adjacency-changes
network 100.0.0.0 0.255.255.255 area 0
!
router ospf 10 vrf V1
log-adjacency-changes
redistribute bgp 1 metric 100 subnets
network 1.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization
neighbor R peer-group
neighbor R remote-as 1
neighbor R update-source Loopback0
neighbor 100.0.0.2 peer-group R
no auto-summary
!
address-family ipv4 vrf V1
redistribute ospf 10
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor R activate
neighbor R send-community extended
neighbor 100.0.0.2 peer-group R
no auto-summary
exit-address-family
Cisco IOS Switching Services Configuration Guide
XC-201
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Autonomous System 1, P1 Configuration
P1: Company
!
ip cef
!
interface Loopback0
ip address 100.0.0.2 255.255.255.255
!
interface Ethernet0/1
description Ogunquit
ip address 100.2.1.1 255.255.255.0
tag-switching ip
!
interface FastEthernet2/0
description Veritas
ip address 100.2.2.1 255.255.255.0
duplex auto
speed auto
tag-switching ip
!
router ospf 1
log-adjacency-changes
network 100.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor R peer-group
neighbor R remote-as 1
neighbor R update-source Loopback0
neighbor R route-reflector-client
neighbor 100.0.0.4 peer-group R
neighbor 100.0.0.5 peer-group R
!
address-family vpnv4
neighbor R activate
neighbor R route-reflector-client
neighbor R send-community extended
neighbor 100.0.0.4 peer-group R
neighbor 100.0.0.5 peer-group R
exit-address-family
Autonomous System 1, EBGP1 Configuration
EBGP1: Company
!
ip cef
!
interface Loopback0
ip address 100.0.0.4 255.255.255.255
!
interface Ethernet0/1
description Vermont
ip address 100.2.1.40 255.255.255.0
tag-switching ip
!
interface ATM1/0
description Lowell
no ip address
no atm scrambling cell-payload
no atm ilmi-keepalive
!
interface ATM1/0.1 point-to-point
Cisco IOS Switching Services Configuration Guide
XC-202
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
description Lowell
ip address 12.0.0.1 255.255.255.252
pvc 1/100
!
router ospf 1
log-adjacency-changes
redistribute connected subnets
network 100.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization
no bgp default route-target filter
bgp log-neighbor-changes
neighbor R peer-group
neighbor R remote-as 1
neighbor R update-source Loopback0
neighbor 12.0.0.2 remote-as 2
neighbor 100.0.0.2 peer-group R
no auto-summary
!
address-family vpnv4
neighbor R activate
neighbor R send-community extended
neighbor 12.0.0.2 activate
neighbor 12.0.0.2 send-community extended
neighbor 100.0.0.2 peer-group R
no auto-summary
exit-address-family
Autonomous System 2, EBGP2 Configuration
EBGP2: Company
!
ip cef
!
ip vrf V1
rd 2:103
route-target export 1:100
route-target import 1:100
!
interface Loopback0
ip address 200.0.0.3 255.255.255.255
ip router isis
!
interface Loopback1
ip vrf forwarding V1
ip address 1.0.0.3 255.255.255.255
!
interface Serial0/0
description Littleton
no ip address
encapsulation frame-relay
load-interval 30
no fair-queue
clockrate 2000000
!
interface Serial0/0.2 point-to-point
description Littleton
ip unnumbered Loopback0
ip router isis
tag-switching ip
frame-relay interface-dlci 23
!
interface ATM1/0
Cisco IOS Switching Services Configuration Guide
XC-203
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
description Ogunquit
no ip address
atm clock INTERNAL
no atm scrambling cell-payload
no atm ilmi-keepalive
!
interface ATM1/0.1 point-to-point
description Ogunquit
ip address 12.0.0.2 255.255.255.252
pvc 1/100
!
router isis
net 49.0002.0000.0000.0003.00
!
router bgp 2
no synchronization
no bgp default route-target filter
bgp log-neighbor-changes
neighbor 12.0.0.1 remote-as 1
neighbor 200.0.0.8 remote-as 2
neighbor 200.0.0.8 update-source Loopback0
neighbor 200.0.0.8 next-hop-self
!
address-family ipv4 vrf V1
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor 12.0.0.1 activate
neighbor 12.0.0.1 send-community extended
neighbor 200.0.0.8 activate
neighbor 200.0.0.8 next-hop-self
neighbor 200.0.0.8 send-community extended
exit-address-family
Autonomous System 2, P2 Configuration
P2: Company
!
ip cef
!
ip vrf V1
rd 2:108
route-target export 1:100
route-target import 1:100
!
interface Loopback0
ip address 200.0.0.8 255.255.255.255
ip router isis
!
interface Loopback1
ip vrf forwarding V1
ip address 1.0.0.8 255.255.255.255
!
interface FastEthernet0/0
description Pax
ip address 200.9.1.2 255.255.255.0
ip router isis
tag-switching ip
!
interface Serial5/0
description Lowell
Cisco IOS Switching Services Configuration Guide
XC-204
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
no ip address
encapsulation frame-relay
frame-relay intf-type dce
!
interface Serial5/0.1 point-to-point
description Lowell
ip unnumbered Loopback0
ip router isis
tag-switching ip
frame-relay interface-dlci 23
!
router isis
net 49.0002.0000.0000.0008.00
!
router bgp 2
no synchronization
bgp log-neighbor-changes
neighbor R peer-group
neighbor R remote-as 2
neighbor R update-source Loopback0
neighbor R route-reflector-client
neighbor 200.0.0.3 peer-group R
neighbor 200.0.0.9 peer-group R
!
address-family ipv4 vrf V1
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor R activate
neighbor R route-reflector-client
neighbor R send-community extended
neighbor 200.0.0.3 peer-group R
neighbor 200.0.0.9 peer-group R
exit-address-family
Autonomous System 2, PE2 Configuration
PE2: Company
!
ip cef
!
ip vrf V1
rd 2:109
route-target export 1:100
route-target import 1:100
!
interface Loopback0
ip address 200.0.0.9 255.255.255.255
ip router isis
!
interface Loopback1
ip vrf forwarding V1
ip address 1.0.0.9 255.255.255.255
!
interface Serial0/0
description Bethel
no ip address
encapsulation frame-relay
frame-relay intf-type dce
no fair-queue
clockrate 2000000
Cisco IOS Switching Services Configuration Guide
XC-205
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
!
interface Serial0/0.1 point-to-point
description Bethel
ip vrf forwarding V1
ip unnumbered Loopback1
frame-relay interface-dlci 24
!
interface FastEthernet0/1
description Littleton
ip address 200.9.1.1 255.255.255.0
ip router isis
tag-switching ip
!
router ospf 10 vrf V1
log-adjacency-changes
redistribute bgp 2 subnets
network 1.0.0.0 0.255.255.255 area 0
!
router isis
net 49.0002.0000.0000.0009.00
!
router bgp 2
no synchronization
bgp log-neighbor-changes
neighbor 200.0.0.8 remote-as 2
neighbor 200.0.0.8 update-source Loopback0
!
address-family ipv4 vrf V1
redistribute connected
redistribute ospf 10
no auto-summary
no synchronization
exit-address-family
address-family vpnv4
neighbor 200.0.0.8 activate
neighbor 200.0.0.8 send-community extended
exit-address-family
Autonomous System 2, CE2 Configuration
CE2: Company
!
interface Loopback0
ip address 1.0.0.11 255.255.255.255
!
interface Serial0
description Pax
no ip address
encapsulation frame-relay
no fair-queue
clockrate 2000000
!
interface Serial0.1 point-to-point
description Pax
ip unnumbered Loopback0
frame-relay interface-dlci 24
!
router ospf 1
network 1.0.0.0 0.255.255.255 area 0
Cisco IOS Switching Services Configuration Guide
XC-206
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Configuring EBGP Routing to Exchange VPN Routes Between Autonomous Systems in a
Confederation
The network topology in Figure 55 shows a single ISP that is partitioning the backbone with
confederations. The AS number of the provider is 100. The two autonomous systems run their own IGPs
and are configured as follows:
•
Autonomous system 1 (AS1) includes PE1, P1, EBGP1. The IGP is OSPF.
•
Autonomous system 2 (AS2) includes PE2, P2, EBGP2. The IGP is ISIS.
•
CE1 and CE2 belongs to the same VPN, which is called VPN1.
•
The P routers are route reflectors.
•
EBGP1 is configured with the redistribute connected subnets router configuration command.
•
EBGP2 is configured with the neighbor next-hop-self router configuration command.
VPN1
CE1
Configuring Two Autonomous Systems in a Confederation
PE1
P1
P2
AS1
PE2
AS2
ASBR1
VPN1
CE2
ASBR2
47867
Figure 55
Autonomous System 1, CE1 Configuration
CE1: Company
!
interface Loopback1
ip address 1.0.0.6 255.255.255.255
!
interface Serial1/3
description Veritas
no ip address
encapsulation frame-relay
frame-relay intf-type dce
!
interface Serial1/3.1 point-to-point
description Veritas
ip address 1.6.2.1 255.255.255.252
frame-relay interface-dlci 22
!
router ospf 1
network 1.0.0.0 0.255.255.255 area 0
Cisco IOS Switching Services Configuration Guide
XC-207
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Autonomous System 1, PE1 Configuration
PE1: Company
!
ip cef
!
ip vrf V1
rd 1:105
route-target export 1:100
route-target import 1:100
!
interface Serial0/0
description Burlington
no ip address
encapsulation frame-relay
no fair-queue
clockrate 2000000
!
interface Serial0/0.3 point-to-point
description Burlington
ip vrf forwarding V1
ip address 1.6.2.2 255.255.255.252
frame-relay interface-dlci 22
!
interface Ethernet0/1
description Vermont
ip address 100.2.2.5 255.255.255.0
tag-switching ip
!
router ospf 1
log-adjacency-changes
network 100.0.0.0 0.255.255.255 area 0
!
router ospf 10 vrf V1
log-adjacency-changes
redistribute bgp 1 metric 100 subnets
network 1.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization
bgp confederation identifier 100
bgp confederation identifier 100
neighbor R peer-group
neighbor R remote-as 1
neighbor R update-source Loopback0
neighbor 100.0.0.2 peer-group R
no auto-summary
!
address-family ipv4 vrf V1
redistribute ospf 10
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor R activate
neighbor R send-community extended
neighbor 100.0.0.2 peer-group R
no auto-summary
exit-address-family
Cisco IOS Switching Services Configuration Guide
XC-208
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Autonomous System 1, P1 Configuration
P1: Company
!
ip cef
!
interface Loopback0
ip address 100.0.0.2 255.255.255.255
!
interface Ethernet0/1
description Ogunquit
ip address 100.2.1.1 255.255.255.0
tag-switching ip
!
interface FastEthernet2/0
description Veritas
ip address 100.2.2.1 255.255.255.0
duplex auto
speed auto
tag-switching ip
!
router ospf 1
log-adjacency-changes
network 100.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization
bgp log-neighbor-changes
bgp confederation identifier 100
neighbor R peer-group
neighbor R remote-as 1
neighbor R update-source Loopback0
neighbor R route-reflector-client
neighbor 100.0.0.4 peer-group R
neighbor 100.0.0.5 peer-group R
!
address-family vpnv4
neighbor R activate
neighbor R route-reflector-client
neighbor R send-community extended
neighbor 100.0.0.4 peer-group R
neighbor 100.0.0.5 peer-group R
exit-address-family
Autonomous System 1, EBGP1 Configuration
EBGP1: Company
!
ip cef
!
interface Loopback0
ip address 100.0.0.4 255.255.255.255
!
interface Ethernet0/1
description Vermont
ip address 100.2.1.40 255.255.255.0
tag-switching ip
!
interface ATM1/0
description Lowell
no ip address
no atm scrambling cell-payload
no atm ilmi-keepalive
!
Cisco IOS Switching Services Configuration Guide
XC-209
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
interface ATM1/0.1 point-to-point
description Lowell
ip address 12.0.0.1 255.255.255.252
pvc 1/100
!
router ospf 1
log-adjacency-changes
redistribute connected subnets
network 100.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization
no bgp default route-target filter
bgp log-neighbor-changes
bgp confederation identifier 100
bgp confederation peers 1
neighbor R peer-group
neighbor R remote-as 1
neighbor R update-source Loopback0
neighbor 12.0.0.2 remote-as 2
neighbor 12.0.0.2 next-hop-self
neighbor 100.0.0.2 peer-group R
no auto-summary
!
address-family vpnv4
neighbor R activate
neighbor R send-community extended
neighbor 12.0.0.2 activate
neighbor 12.0.0.2 next-hop-self
neighbor 12.0.0.2 send-community extended
neighbor 100.0.0.2 peer-group R
no auto-summary
exit-address-family
Autonomous System 2, EBGP2 Configuration
EBGP2: Company
!
ip cef
!
ip vrf V1
rd 2:103
route-target export 1:100
route-target import 1:100
!
interface Loopback0
ip address 200.0.0.3 255.255.255.255
ip router isis
!
interface Loopback1
ip vrf forwarding V1
ip address 1.0.0.3 255.255.255.255
!
interface Serial0/0
description Littleton
no ip address
encapsulation frame-relay
load-interval 30
no fair-queue
clockrate 2000000
!
interface Serial0/0.2 point-to-point
description Littleton
ip unnumbered Loopback0
Cisco IOS Switching Services Configuration Guide
XC-210
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
ip router isis
tag-switching ip
frame-relay interface-dlci 23
!
interface ATM1/0
description Ogunquit
no ip address
atm clock INTERNAL
no atm scrambling cell-payload
no atm ilmi-keepalive
!
interface ATM1/0.1 point-to-point
description Ogunquit
ip address 12.0.0.2 255.255.255.252
pvc 1/100
!
router isis
net 49.0002.0000.0000.0003.00
!
router bgp 2
no synchronization
no bgp default route-target filter
bgp log-neighbor-changes
bgp confederation identifier 100
bgp confederation peers 1
neighbor 12.0.0.1 remote-as 1
neighbor 12.0.0.1 next-hop-self
neighbor 200.0.0.8 remote-as 2
neighbor 200.0.0.8 update-source Loopback0
neighbor 200.0.0.8 next-hop-self
!
address-family ipv4 vrf V1
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor 12.0.0.1 activate
neighbor 12.0.0.1 next-hop-self
neighbor 12.0.0.1 send-community extended
neighbor 200.0.0.8 activate
neighbor 200.0.0.8 next-hop-self
neighbor 200.0.0.8 send-community extended
exit-address-family
Autonomous System 2, P2 Configuration
P2: Company
!
ip cef
!
ip vrf V1
rd 2:108
route-target export 1:100
route-target import 1:100
!
interface Loopback0
ip address 200.0.0.8 255.255.255.255
ip router isis
!
interface Loopback1
ip vrf forwarding V1
ip address 1.0.0.8 255.255.255.255
Cisco IOS Switching Services Configuration Guide
XC-211
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
!
interface FastEthernet0/0
description Pax
ip address 200.9.1.2 255.255.255.0
ip router isis
tag-switching ip
!
interface Serial5/0
description Lowell
no ip address
encapsulation frame-relay
frame-relay intf-type dce
!
interface Serial5/0.1 point-to-point
description Lowell
ip unnumbered Loopback0
ip router isis
tag-switching ip
frame-relay interface-dlci 23
!
router isis
net 49.0002.0000.0000.0008.00
!
router bgp 2
no synchronization
bgp log-neighbor-changes
bgp confederation identifier 100
neighbor R peer-group
neighbor R remote-as 2
neighbor R update-source Loopback0
neighbor R route-reflector-client
neighbor 200.0.0.3 peer-group R
neighbor 200.0.0.9 peer-group R
!
address-family ipv4 vrf V1
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor R activate
neighbor R route-reflector-client
neighbor R send-community extended
neighbor 200.0.0.3 peer-group R
neighbor 200.0.0.9 peer-group R
exit-address-family
Autonomous System 2, PE2 Configuration
PE2: Company
!
ip cef
!
ip vrf V1
rd 2:109
route-target export 1:100
route-target import 1:100
!
interface Loopback0
ip address 200.0.0.9 255.255.255.255
ip router isis
!
interface Loopback1
Cisco IOS Switching Services Configuration Guide
XC-212
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
ip vrf forwarding V1
ip address 1.0.0.9 255.255.255.255
!
interface Serial0/0
description Bethel
no ip address
encapsulation frame-relay
frame-relay intf-type dce
no fair-queue
clockrate 2000000
!
interface Serial0/0.1 point-to-point
description Bethel
ip vrf forwarding V1
ip unnumbered Loopback1
frame-relay interface-dlci 24
!
interface FastEthernet0/1
description Littleton
ip address 200.9.1.1 255.255.255.0
ip router isis
tag-switching ip
!
router ospf 10 vrf V1
log-adjacency-changes
redistribute bgp 2 subnets
network 1.0.0.0 0.255.255.255 area 0
!
router isis
net 49.0002.0000.0000.0009.00
!
router bgp 2
no synchronization
bgp log-neighbor-changes
bgp confederation identifier 100
neighbor 200.0.0.8 remote-as 2
neighbor 200.0.0.8 update-source Loopback0
!
address-family ipv4 vrf V1
redistribute connected
redistribute ospf 10
no auto-summary
no synchronization
exit-address-family
address-family vpnv4
neighbor 200.0.0.8 activate
neighbor 200.0.0.8 send-community extended
exit-address-family
Autonomous System 2, CE2 Configuration
CE2: Company
!
interface Loopback0
ip address 1.0.0.11 255.255.255.255
!
interface Serial0
description Pax
no ip address
encapsulation frame-relay
no fair-queue
clockrate 2000000
!
interface Serial0.1 point-to-point
Cisco IOS Switching Services Configuration Guide
XC-213
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
description Pax
ip unnumbered Loopback0
frame-relay interface-dlci 24
!
router ospf 1
network 1.0.0.0 0.255.255.255 area 0
Implementing MPLS QoS Example
Figure 56 illustrates a sample MPLS topology that implements the MPLS QoS feature. The following
sections contain the configuration commands entered on Routers R1 to R6 and on Switches 1 and 2
included in this figure.
Sample MPLS Topology Implementing QoS
Router 2
lo0:13.13.13.13
lo0:11.11.11.11
p0/3
Router 4
p3/0/0
e0/2
e0/1
lo0:10.10.10.10
h3/1/0
lo0:12.12.12.12
e0/1
Router 1
p3/0/0
p0/3
lo0:15.15.15.15
93.0.0.1
94.0.0.1
Router 5
a1/1/0
a0/0/3
Switch 2
h2/1/0
Router 3
a2/0/0
a0/0/1
a0/0/0
a1/1/0
lo0:16.16.16.16
e0/1
a0/1/1
e0/2
e0/3
Router 6
lo0:14.14.14.14
a0/1/1
a0/0/0
a1/1/0
18970
Figure 56
Switch 1
lo0:17.17.17.17
Configuring CEF Example
The following configuration commands enable CEF. CEF switching is a prerequisite for the MPLS
feature and must be running on all routers in the network:
ip cef distributed
tag-switching ip
!
Cisco IOS Switching Services Configuration Guide
XC-214
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Running IP on Router 2 Example
The following commands enable IP routing on Router 2. All routers must have IP enabled:
Note
Router 2 is not part of the MPLS network.
!
ip routing
!
hostname R2
!
interface Loopback0
ip address 10.10.10.10 255.255.255.255
!
interface POS0/3
ip unnumbered Loopback0
crc 16
clock source internal
!
router ospf 100
network 10.0.0.0 0.255.255.255 area 100
!
Running IP on Router 1 Example
The following commands enable IP routing on Router 1:
Note
Router 1 is not part of the MPLS network.
ip routing
!
hostname R1
!
interface Loopback0
ip address 15.15.15.15 255.255.255.255
!
interface POS0/3
ip unnumbered Loopback0
crc 16
clock source internal
!
router ospf 100
network 15.0.0.0 0.255.255.255 area 100
Running MPLS on Router 4 Example
Router 4 is a label edge router. CEF and the MPLS feature must be enabled on this router. CAR is also
configured on Router 4 on interface POS3/0/0 (see the following section on configuring CAR).
!
hostname R4
!
ip routing
tag-switching ip
tag-switching advertise-tags
!
Cisco IOS Switching Services Configuration Guide
XC-215
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
ip cef distributed
!
interface Loopback0
ip address 11.11.11.11 255.255.255.255
!
interface Ethernet0/1
ip address 90.0.0.1 255.0.0.0
tag-switching ip
!
Configuring CAR Example
Lines 3 and 4 of the following sample configuration contain the CAR rate policies. Line 3 sets the
committed information rate (CIR) at 155,000,000 bits and the normal burst/maximum burst size at
200,000/800,000 bytes. The conform action (action to take on packets) sets the IP precedence and sends
the packets that conform to the rate limit. The exceed action sets the IP precedence and sends the packets
when the packets exceed the rate limit.
!
interface POS3/0/0
ip unnumbered Loopback0
rate-limit input 155000000 2000000 8000000 conform-action set-prec-transmit 5
exceed-action set-prec-transmit 1
ip route-cache distributed
!
router ospf 100
network 11.0.0.0 0.255.255.255 area 100
network 90.0.0.0 0.255.255.255 area 100
Running MPLS on Router 3 Example
Router 3 is running MPLS. CEF and the MPLS feature must be enabled on this router. Router 3 contains
interfaces that are configured for WRED, multi-VC, per-VC WRED, WFQ, and CAR. The following
sections contain these sample configurations:
!
hostname R3
!
ip cef distributed
!
interface Loopback0
ip address 12.12.12.12 255.255.255.255
!
interface Ethernet0/1
ip address 90.0.0.2 255.0.0.0
tag-switching ip
Configuring Point-to-Point WRED Example
The following commands configure WRED on an ATM interface. In this example, the commands refer
to a PA-A1 port adapter.
!
interface ATM1/1/0
ip route-cache distributed
atm clock INTERNAL
random-detect
!
Cisco IOS Switching Services Configuration Guide
XC-216
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Configuring an Interface for Multi-VC Mode Example
The following commands configure interface ATM1/1/0 for multi-VC mode. In this example, the
commands refer to a PA-A1 port adapter.
!
interface ATM1/1/0.1 tag-switching
ip unnumbered Loopback0
tag-switching atm multi-vc
tag-switching ip
!
Configuring WRED and Multi-VC Mode on a PA-A3 Port-Adapter Interface Example
The commands to configure a PA-A3 port adapter differ slightly from the commands to configure a
PA-A1 port adapter as shown previously.
On an PA-A3 port-adapter interface, distributed WRED (DWRED) is supported only per-VC, not
per-interface.
To configure a PA-A3 port adapter, enter the following commands:
!
interface ATM1/1/0
ip route-cache distributed
atm clock INTERNAL
!
interface ATM 1/1/0.1 tag-switching
ip unnumbered Loopback0
tag-switching multi-vc
tag-switching random detect attach groupname
!
Configuring Per-VC WRED Example
The following commands configure per-VC WRED on a PA-A3 port adapter only:
Note
The PA-A1 port adapter does not support the per-VC WRED drop mechanism.
!interface ATM2/0/0
no ip address
ip route-cache distributed
interface ATM2/0/0.1 point-to-point
ip unnumbered Loopback0
no ip directed-broadcast
pvc 10/100
random-detect
encapsulation aal5snap
exit
!
tag-switching ip
Cisco IOS Switching Services Configuration Guide
XC-217
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Configuring WRED and WFQ Example
Lines 5 and 6 of the following sample configuration contain the commands for configuring WRED and
WFQ on interface Hssi2/1/0:
!
interface Hssi2/1/0
ip address 91.0.0.1 255.0.0.0
ip route-cache distributed
tag-switching ip
random-detect
fair queue tos
hssi internal-clock
!
Configuring CAR Example
Lines 3 and 4 of the following sample configuration contain the CAR rate policies. Line 3 sets the CIR
at 155,000,000 bits and the normal burst/maximum burst size at 200,000/800,000 bytes. The conform
action (action to take on packets) sets the IP precedence and sends the packets that conform to the rate
limit. The exceed action sets the IP precedence and sends the packets when the packets exceed the rate
limit.
!
interface POS3/0/0
ip unnumbered Loopback0
rate-limit input 155000000 2000000 8000000 conform-action set-prec-transmit 2
exceed-action set-prec-transmit 2
ip route-cache distributed
!
router ospf 100
network 12.0.0.0 0.255.255.255 area 100
network 90.0.0.0 0.255.255.255 area 100
network 91.0.0.0 0.255.255.255 area 100
!
ip route 93.0.0.0 255.0.0.0 Hssi2/1/0 91.0.0.2
!
Running MPLS on Router 5 Example
Router 5 is running the MPLS feature. CEF and MPLS must be enabled on this router. Router 5 has also
been configured to create an ATM subinterface in multi-VC mode and to create a PVC on a
point-to-point subinterface. The sections that follow contain these sample configurations.
!
hostname R5
!
ip cef distributed
!
interface Loopback0
ip address 13.13.13.13 255.255.255.255
!
interface Ethernet0/2
ip address 92.0.0.1 255.0.0.0
tag-switching ip
Cisco IOS Switching Services Configuration Guide
XC-218
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Configuring an ATM Interface Example
The following commands create an ATM interface:
!
interface ATM1/0/0
no ip address
ip route-cache distributed
atm clock INTERNAL
!
Configuring an ATM MPLS Subinterface in Multi-VC Mode Example
The following commands create an MPLS subinterface in multi-VC mode:
!
interface ATM1/0/0.1 tag-switching
ip unnumbered Loopback0
tag-switching atm multi-vc
tag-switching ip
!
Configuring a PVC on Point-to-Point Subinterface Example
The following commands create a PVC on a point-to-point subinterface (interface ATM1/0/0.2).
!
interface ATM1/0/0.2 point-to-point
ip unnumbered Loopback0
pvc 10/100
random-detect
encapsulation aal5snap
exit
!
tag-switching ip
!
interface Hssi3/0
ip address 91.0.0.2 255.0.0.0
tag-switching ip
hssi internal-clock
!
router ospf 100
network 13.0.0.0 0.255.255.255 area 100
network 91.0.0.0 0.255.255.255 area 100
network 92.0.0.0 0.255.255.255 area 100
!
Running MPLS on Router 6 Example
Router 6 is running the MPLS feature. CEF and MPLS must be enabled on this router. The following
commands configure MPLS on an ethernet interface:
!
hostname R6
!
ip cef distributed
!
interface Loopback0
ip address 14.14.14.14 255.255.255.255
!
interface Ethernet0/1
ip address 93.0.0.1 255.0.0.0
Cisco IOS Switching Services Configuration Guide
XC-219
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
tag-switching ip
!
interface Ethernet0/2
ip address 92.0.0.2 255.0.0.0
tag-switching ip
!
interface Ethernet0/3
ip address 94.0.0.1 255.0.0.0
tag-switching ip
!
router ospf 100
network 14.0.0.0 0.255.255.255
network 92.0.0.0 0.255.255.255
network 93.0.0.0 0.255.255.255
network 94.0.0.0 0.255.255.255
!
area
area
area
area
100
100
100
100
Configuring ATM Switch 2 Example
Switch 2 is configured for MPLS and creates an ATM Forum PVC. The following commands configure
MPLS on ATM switch2:
!
hostname S2
!
interface Loopback0
ip address 16.16.16.16 255.255.255.255
!
interface ATM0/0/0
ip unnumbered Loopback0
tag-switching ip
!
interface ATM0/0/1
ip unnumbered Loopback0
tag-switching ip
atm pvc 10 100 interface ATM0/0/0 10 100
interface ATM0/0/2
no ip address
no ip directed-broadcast
!
interface ATM0/0/3
ip unnumbered Loopback0
tag-switching ip
!
interface ATM1/1/0
ip unnumbered Loopback0
tag-switching ip
!
router ospf 100
network 16.0.0.0 0.255.255.255 area 100
!
Configuring ATM Switch 1 Example
Switch 1 is configured to create an ATM Forum PVC. The following commands configure MPLS on
ATM switch1:
!
hostname S1
!
Cisco IOS Switching Services Configuration Guide
XC-220
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
interface Loopback0
ip address 17.17.17.17 255.255.255.255
!
interface ATM0/0/0
ip unnumbered Loopback0
tag-switching ip
!
Configuring Label VCs and an ATM Forum PVC Example
Line 3 of the following sample configuration contains the configuration command for an ATM Forum
PVC:
!
interface ATM0/1/1
ip unnumbered Loopback0
atm pvc 10 100 interface ATM0/0/0 10 100
tag-switching ip
!
interface ATM1/1/0
ip unnumbered Loopback0
tag-switching ip
!
router ospf 100
network 17.0.0.0 0.255.255.255 area 100
!
Configuring an MPLS LSC Examples
The following sections present the following MPLS LSC configuration examples:
•
Configuring ATM-LSRs Example
•
Configuring Multi-VCs Example
•
Configuring ATM-LSRs with a Cisco 6400 NRP Operating as LSC Example
•
Configuring ATM LSRs Through ATM Network Using Cisco 7200 LSCs Implementing Virtual
Trunking Example
•
Configuring ATM LSRs Through ATM Network Using Cisco 6400 NRP LSCs Implementing Virtual
Trunking Example
•
Configuring LSC Hot Redundancy Example
•
Configuring LSC Warm Standby Redundancy Example
•
Configuring an Interface Using Two VSI Partitions Example
•
Using an Access List to Control the Creation of Headend VCs
Configuring ATM-LSRs Example
The network topology shown in Figure 57 incorporates two ATM-LSRs in an MPLS network. This
topology includes two LSCs (Cisco 7200 routers), two BPX service nodes, and two edge LSRs
(Cisco 7500 routers).
For the IGX, use the following commands:
extended-port atm1/0 descriptor 0.x.x.0
tag-control-protocol vsi slaves 32 id x
Cisco IOS Switching Services Configuration Guide
XC-221
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Figure 57
ATM-LSR Network Configuration Example
LSC1
(Cisco 7200
series)
LSC2
(Cisco 7200
series)
ATM 3/0
ATM 3/0
1.1
ATM 2/0/0
2.2
1.1
1.3
1.3
2.2
Cisco BPX1
Cisco BPX2
ATM-LSR
ATM-LSR
ATM 2/0/0
Edge LSR2
(Cisco 7200
series)
S6908
Edge LSR1
(Cisco 7500
series)
Based on Figure 57, the following configuration examples are provided:
•
LSC1 Configuration
•
BPX1 and BPX2 Configuration
•
LSC2 Configuration
•
Edge LSR1 Configuration
•
Edge LSR2 Configuration
LSC1 Configuration
7200 LSC1:
ip cef
!
interface loopback0
ip address 192.103.210.5 255.255.255.255
!
interface ATM3/0
no ip address
tag-control-protocol vsi
!
interface XTagATM13
extended-port ATM3/0 bpx 1.3
ip unnumbered loopback0
tag-switching atm vpi 2-15
tag-switching ip
!
interface XTagATM22
extended-port ATM3/0 bpx 2.2
ip unnumbered loopback0
tag-switching atm vpi 2-5
tag-switching ip
Cisco IOS Switching Services Configuration Guide
XC-222
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
BPX1 and BPX2 Configuration
BPX1 and BPX2:
uptrk 1.1
addshelf 1.1 v 1 1
cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000
uptrk 1.3
cnfrsrc 1.3 256 252207 y 1 e 512 6144 2 15 26000 100000
uptrk 2.2
cnfrsrc 2.2 256 252207 y 1 e 512 4096 2 5 26000 100000
Note
For the shelf controller, you must configure a VSI partition for the slave control port interface
(addshelf 1.1, cnfrsrc 1.1...). However, do not configure an XTagATM port for the VSI partition (for
example, XTagATM11).
LSC2 Configuration
7200 LSC2:
ip cef
!
interface loopback0
ip address 142.2.143.22 255.255.255.255
!
interface ATM3/0
no ip address
tag-control-protocol vsi
!
interface XTagATM13
extended-port ATM3/0 bpx 1.3
ip unnumbered loopback0
tag-switching atm vpi 2-15
tag-switching ip
!
interface XTagATM22
extended-port ATM3/0 bpx 2.2
ip unnumbered loopback0
tag-switching atm vpi 2-5
tag-switching ip
!
Edge LSR1 Configuration
7500 LSR1:
ip cef distributed
!
interface loopback 0
ip address 142.6.132.2 255.255.255.255
!
interface ATM2/0/0
no ip address
!
interface ATM2/0/0.5 tag-switching
ip unnumbered loopback 0
tag-switching atm vpi 2-5
tag-switching ip
Edge LSR2 Configuration
7200 LSR2:
ip cef
interface loopback 0
ip address 142.6.142.2 255.255.255.255
!
Cisco IOS Switching Services Configuration Guide
XC-223
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
interface ATM2/0
no ip address
!
interface ATM2/0.9 tag-switching
ip unnumbered loopback 0
tag-switching atm vpi 2-5
tag-switching ip
Configuring Multi-VCs Example
When you configure multi-VC support, four label VCs for each destination are created by default, as
follows:
•
Standard (for class 0 and class 4 traffic)
•
Available (for class 1 and class 5 traffic)
•
Premium (for class 2 and class 6 traffic)
•
Control (for class 3 and class 7 traffic)
This section provides examples for the following configurations, based on the sample network
configuration shown earlier in Figure 57:
Note
•
LSC1 Configuration
•
BPX1 and BPX2 Configuration
•
LSC2 Configuration
•
Edge LSR1 Configuration
•
Edge LSR2 Configuration
The IGX series ATM switches do not support QoS.
LSC1 Configuration
7200 LSC1:
ip cef
!
interface loopback0
ip address 192.103.210.5 255.255.255.255
!
interface ATM3/0
no ip address
tag-control-protocol vsi
!
interface XTagATM13
ip unnumbered loopback 0
extended-port ATM3/0 bpx 1.3
tag-switching atm vpi 2-15
tag-switching atm cos available 25
tag-switching atm cos standard 25
tag-switching atm cos premium 25
tag-switching atm cos control 25
tag-switching ip
!
interface XTagATM23
ip unnumbered loopback 0
extended-port ATM3/0 bpx 2.2
tag-switching atm vpi 2-5
Cisco IOS Switching Services Configuration Guide
XC-224
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
tag-switching
tag-switching
tag-switching
tag-switching
tag-switching
atm
atm
atm
atm
ip
cos
cos
cos
cos
available 20
standard 30
premium 25
control 25
BPX1 and BPX2 Configuration
BPX1 and BPX2:
uptrk 1.1
addshelf 1.1 v 1 1
cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000
uptrk 1.3
cnfrsrc 1.3 256 252207 y 1 e 512 6144 2 15 26000 100000
uptrk 2.2
cnfrsrc 2.2 256 252207 y 1 e 512 4096 2 5 26000 100000
LSC2 Configuration
7200 LSC2:
ip cef
!
interface loopback0
ip address 142.2.143.22 255.255.255.255
!
interface ATM3/0
no ip address
tag-control-protocol vsi
!
interface XTagATM13
ip unnumbered loopback 0
extended-port ATM3/0 bpx 1.3
tag-switching atm vpi 2-15
tag-switching atm cos available 25
tag-switching atm cos standard 25
tag-switching atm cos premium 25
tag-switching atm cos control 25
tag-switching ip
!
interface XTagATM23
ip unnumbered loopback 0
extended-port ATM3/0 bpx 2.2
tag-switching atm vpi 2-5
tag-switching atm cos available 20
tag-switching atm cos standard 30
tag-switching atm cos premium 25
tag-switching atm cos control 25
tag-switching ip
Edge LSR1 Configuration
7500 LSR1:
ip cef distributed
interface loopback 0
ip address 142.6.132.2 255.255.255.255
!
interface ATM2/0/0
no ip address
!
interface ATM2/0/0.5 tag-switching
ip unnumbered loopback 0
tag-switching atm vpi 2-5
tag-switching atm multi-vc
tag-switching ip
Cisco IOS Switching Services Configuration Guide
XC-225
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Edge LSR2 Configuration
7200 LSR2:
ip cef
interface loopback 0
ip address 142.2.142.2 255.255.255.255
!
interface ATM2/0
no ip address
!
interface ATM2/0.9 tag-switching
ip unnumbered loopback 0
tag-switching atm vpi 2-5
tag-switching atm multi-vc
tag-switching ip
QoS Support
If LSC1 supports QoS, but LSC2 does not, LSC1 makes VC requests for the following default classes:
•
Control=QoS3
•
Standard=QoS1
LSC2 ignores the call field in the request and allocates two UBR label VCs.
If LSR1 supports QoS, but LSR2 does not, LSR2 receives the request to create multiple label VCs, but
by default, creates class 0 only (UBR).
Configuring ATM-LSRs with a Cisco 6400 NRP Operating as LSC Example
When you use the NRP as an MPLS LSC in the Cisco 6400 UAC, you must configure the NSP to provide
connectivity between the NRP and the Cisco BPX switch. When configured in this way (as shown in
Figure 58), the NRP is connected to the NSP by means of the internal interface ATM3/0/0, while external
connectivity from the Cisco 6400 UAC to the Cisco BPX switch is provided by means of the external
interface ATM1/0/0 from the NSP.
Cisco IOS Switching Services Configuration Guide
XC-226
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Figure 58
Cisco 6400 UAC NRP Operating As an LSC
ATM-LSR
ATM-LSR
Cisco 6400
Cisco 6400
LSC
(NRP)
LSC
(NRP)
ATM 3/0/0
ATM 3/0/0
LSC1
NSP
(7200)
LSC2
NSP
(7200)
ATM 1/0/0
ATM 1/0/0
1.1
2.2
1.3
1.3
Cisco
BPX1
BPX1
Cisco
BPX2
BPX2
2.2
atm2/0/0
Edge LSR2
(Cisco 7500)
30788
Edge LSR1 atm2/0/0
(Cisco 7500)
1.1
Based on Figure 58, the following configuration examples are provided:
•
6400 UAC NSP Configuration
•
6400 UAC NRP LSC1 Configuration
•
BPX1 and BPX2 Configuration
•
6400 UAC NRP LSC2 Configuration
•
Edge LSR1 Configuration
•
Edge LSR2 Configuration
6400 UAC NSP Configuration
6400 NSP:
!
interface ATM3/0/0
atm pvp 0 interface
atm pvp 2 interface
atm pvp 3 interface
atm pvp 4 interface
atm pvp 5 interface
atm pvp 6 interface
atm pvp 7 interface
atm pvp 8 interface
atm pvp 9 interface
atm pvp 10 interface
atm pvp 11 interface
atm pvp 12 interface
atm pvp 13 interface
atm pvp 14 interface
atm pvp 15 interface
ATM1/0/0 0
ATM1/0/0 2
ATM1/0/0 3
ATM1/0/0 4
ATM1/0/0 5
ATM1/0/0 6
ATM1/0/0 7
ATM1/0/0 8
ATM1/0/0 9
ATM1/0/0 10
ATM1/0/0 11
ATM1/0/0 12
ATM1/0/0 13
ATM1/0/0 14
ATM1/0/0 15
Cisco IOS Switching Services Configuration Guide
XC-227
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Note
Instead of configuring multiple PVCs, you can also configure PVP 0 by deleting all well-known VCs.
For example, you can use the atm manual-well-known-vc delete interface command on both
interfaces and then configure PVP 0, as follows:
atm pvp 0 interface ATM1/0/0 0
6400 UAC NRP LSC1 Configuration
ip cef
!
interface Loopback0
ip address 142.2.143.22 255.255.255.255
!
interface ATM0/0/0
no ip address
tag-control-protocol vsi
!
interface XTagATM13
ip unnumbered Loopback0
extended-port ATM0/0/0 bpx 1.3
tag-switching atm vpi 2-15
tag-switching ip
!
interface XTagATM22
ip unnumbered Loopback0
extended-port ATM0/0/0 bpx 2.2
tag-switching atm vpi 2-5
tag-switching ip
!
tag-switching atm disable-headend-vc
BPX1 and BPX2 Configuration
BPX1 and BPX2:
uptrk 1.1
addshelf 1.1 v 1 1
cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000
uptrk 1.3
cnfrsrc 1.3 256 252207 y 1 e 512 6144 2 15 26000 100000
uptrk 2.2
cnfrsrc 2.2 256 252207 y 1 e 512 4096 2 5 26000 100000
Note
For the shelf controller, you must configure a VSI partition for the slave control port interface
(addshelf 1.1, cnfrsrc 1.1...). However, do not configure an XTagATM port for the VSI partition (for
example, XTagATM11).
6400 UAC NRP LSC2 Configuration
ip cef
!
interface Loopback0
ip address 192.103.210.5 255.255.255.255
!
interface ATM0/0/0
no ip address
tag-control-protocol vsi
!
interface XTagATM13
ip unnumbered Loopback0
extended-port ATM0/0/0 bpx 1.3
tag-switching atm vpi 2-15
Cisco IOS Switching Services Configuration Guide
XC-228
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
tag-switching ip
!
interface XTagATM22
ip unnumbered Loopback0
extended-port ATM0/0/0 bpx 2.2
tag-switching atm vpi 2-5
tag-switching ip
!
tag-switching atm disable-headend-vc
Edge LSR1 Configuration
7500 LSR1:
ip cef distributed
!
interface loopback 0
ip address 142.6.132.2 255.255.255.255
!
interface ATM2/0/0
no ip address
!
interface ATM2/0/0.22 tag-switching
ip unnumbered loopback 0
tag-switching atm vpi 2-5
tag-switching ip
Edge LSR2 Configuration
7500 LSR2:
ip cef distributed
!
interface loopback 0
ip address 142.6.142.2 255.255.255.255
!
interface ATM2/0/0
no ip address
!
interface ATM2/0/0.22 tag-switching
unnumbered loopback 0
tag-switching atm vpi 2-5
tag-switching ip
Configuring ATM LSRs Through ATM Network Using Cisco 7200 LSCs Implementing Virtual Trunking
Example
The network topology shown in Figure 59 incorporates two ATM-LSRs using virtual trunking to create
an MPLS network through a private ATM Network. This topology includes the following:
•
Two LSCs (Cisco 7200 routers)
•
Two BPX service nodes
•
Two edge LSRs (Cisco 7500 and 7200 routers)
Cisco IOS Switching Services Configuration Guide
XC-229
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
For the IGX, use the following commands:
extended-port atm1/0 descriptor 0.x.x.0
tag-control-protocol vsi slaves 32 id x
Figure 59
ATM-LSR Virtual Trunking Through an ATM Network
LSC1
(Cisco 7200)
LS
(Cisco
ATM 3/0
A
1.1
ATM 2/0/0
2.2
1.1
1.3.2
ATM
network
Cisco BPX1
1.3.2
Cisco
Edge LSR1
(Cisco 7500)
ATM-LSR
Based on Figure 59, the following configuration examples are provided:
•
LSC1 Implementing Virtual Trunking Configuration
•
BPX1 and BPX2 Configuration
•
LSC2 Implementing Virtual Trunking Configuration
•
Edge LSR1 Configuration
•
Edge LSR2 Configuration
LSC1 Implementing Virtual Trunking Configuration
7200 LSC1:
ip cef
!
interface loopback0
ip address 192.103.210.5 255.255.255.255
!
interface ATM3/0
no ip address
tag-control-protocol vsi
!
interface XTagATM132
extended-port ATM3/0 bpx 1.3.2
ip unnumbered loopback0
tag-switching atm vp-tunnel 2
tag-switching ip
!
interface XTagATM22
extended-port ATM3/0 bpx 2.2
ip unnumbered loopback0
tag-switching atm vpi 2-5
tag-switching ip
Cisco IOS Switching Services Configuration Guide
XC-230
ATM
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
BPX1 and BPX2 Configuration
BPX1 and BPX2:
uptrk 1.1
addshelf 1.1 v 1 1
cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000
uptrk 1.3.2
cnftrk 1.3.2 100000 N 1000 7F V,TS,NTS,FR,FST,CBR,NRT-VBR,ABR,RT-VBR N TERRESTRIAL 10
0 N N Y Y Y CBR 2
cnfrsrc 1.3.2 256 252207 y 1 e 512 6144 2 2 26000 100000
uptrk 2.2
cnfrsrc 2.2 256 252207 y 1 e 512 4096 2 5 26000 100000
Note
For the shelf controller, you must configure a VSI partition for the slave control port interface
(addshelf 1.1, cnfrsrc 1.1...). However, do not configure an XtagATM port for the VSI partition (for
example, XtagATM11).
LSC2 Implementing Virtual Trunking Configuration
7200 LSC2:
ip cef
!
interface loopback0
ip address 142.2.143.22 255.255.255.255
!
interface ATM3/0
no ip address
tag-control-protocol vsi
!
interface XTagATM132
extended-port ATM3/0 bpx 1.3.2
ip unnumbered loopback0
tag-switching atm vp-tunnel 2
tag-switching ip
!
interface XTagATM22
extended-port ATM3/0 bpx 2.2
ip unnumbered loopback0
tag-switching atm vpi 2-5
tag-switching ip
Edge LSR1 Configuration
7500 LSR1:
ip cef distributed
interface loopback 0
ip address 142.6.132.2 255.255.255.255
!
interface ATM2/0/0
no ip address
!
interface ATM2/0/0.22 tag-switching
ip unnumbered loopback 0
tag-switching atm vpi 2-5
tag-switching ip
Edge LSR2 Configuration
7200 LSR2:
ip cef
interface loopback 0
ip address 142.6.142.2 255.255.255.255
!
Cisco IOS Switching Services Configuration Guide
XC-231
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
interface ATM2/0
no ip address
!
interface ATM2/0.22 tag-switching
ip unnumbered loopback 0
tag-switching atm vpi 2-5
tag-switching ip
Configuring ATM LSRs Through ATM Network Using Cisco 6400 NRP LSCs Implementing Virtual
Trunking Example
The network topology shown in Figure 60 incorporates two ATM-LSRs using virtual trunking to create
an MPLS network through a private ATM network. This topology includes two LSCs (Cisco 6400 UAC
NRP routers), two BPX service nodes, and two edge LSRs (Cisco 7500 and 7200 routers).
Cisco 6400 NRP Operating as LSC Implementing Virtual Trunking
ATM-LSR
ATM-LSR
Cisco 6400
Cisco 6400
LSC
(NRP)
LSC
(NRP)
ATM 3/0/0
ATM 3/0/0
LSC1
NSP
(7200)
LSC2
NSP
(7200)
ATM 1/0/0
ATM 1/0/0
1.1
ATM 2/0/0
2.2
1.1
1.3.2
BPX1
Cisco
BPX1
ATM
network
Edge LSR1
(Cisco 7500)
1.3.2
BPX2
Cisco
BPX2
2.2
ATM 2/0/0
Edge LSR2
(Cisco 7500)
Based on Figure 60, the following configuration examples are provided:
•
6400 UAC NSP Configuration
•
6400 UAC NRP LSC1 Implementing Virtual Trunking Configuration
•
BPX1 and BPX2 Configuration
•
6400 UAC NRP LSC2 Implementing Virtual Trunking Configuration
•
Edge LSR1 Configuration
•
Edge LSR2 Configuration
Cisco IOS Switching Services Configuration Guide
XC-232
34085
Figure 60
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
6400 UAC NSP Configuration
6400 NSP:
!
interface ATM3/0/0
atm pvp 0 interface ATM1/0/0 0
atm pvp 2 interface ATM1/0/0 2
atm pvp 3 interface ATM1/0/0 3
atm pvp 4 interface ATM1/0/0 4
atm pvp 5 interface ATM1/0/0 5
atm pvp 6 interface ATM1/0/0 6
atm pvp 7 interface ATM1/0/0 7
atm pvp 8 interface ATM1/0/0 8
atm pvp 9 interface ATM1/0/0 9
atm pvp 10 interface ATM1/0/0 10
atm pvp 11 interface ATM1/0/0 11
atm pvp 12 interface ATM1/0/0 12
atm pvp 13 interface ATM1/0/0 13
atm pvp 14 interface ATM1/0/0 14
atm pvp 15 interface ATM1/0/0 15
Note
Instead of configuring multiple PVCs, you can also configure PVP 0 by deleting all well-known VCs.
For example, you can use the atm manual-well-known-vc delete interface command on both
interfaces and then configure PVP 0, as follows:
atm pvp 0 interface ATM1/0/0 0
6400 UAC NRP LSC1 Implementing Virtual Trunking Configuration
ip cef
!
interface Loopback0
ip address 142.2.143.22 255.255.255.255
!
interface ATM0/0/0
no ip address
tag-control-protocol vsi
!
interface XTagATM132
ip unnumbered Loopback0
extended-port ATM0/0/0 bpx 1.3.2
tag-switching atm vp-tunnel 2
tag-switching ip
!
interface XTagATM22
ip unnumbered Loopback0
extended-port ATM0/0/0 bpx 2.2
tag-switching atm vpi 2-5
tag-switching ip
!
tag-switching atm disable-headend-vc
BPX1 and BPX2 Configuration
BPX1 and BPX2:
uptrk 1.1
addshelf 1.1 v 1 1
cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000
uptrk 1.3.2
cnftrk 1.3.2 100000 N 1000 7F V,TS,NTS,FR,FST,CBR,NRT-VBR,ABR,RT-VBR N TERRESTRIAL 10
0 N N Y Y Y CBR 2
cnfrsrc 1.3.2 256 252207 y 1 e 512 6144 2 2 26000 100000
uptrk 2.2
cnfrsrc 2.2 256 252207 y 1 e 512 4096 2 5 26000 100000
Cisco IOS Switching Services Configuration Guide
XC-233
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Note
For the shelf controller, you must configure a VSI partition for the slave control port interface
(addshelf 1.1, cnfrsrc 1.1...). However, do not configure an XtagATM port for the VSI partition (for
example, XtagATM11).
6400 UAC NRP LSC2 Implementing Virtual Trunking Configuration
ip cef
!
interface Loopback0
ip address 192.103.210.5 255.255.255.255
!
interface ATM0/0/0
no ip address
tag-control-protocol vsi
!
interface XTagATM132
ip unnumbered Loopback0
extended-port ATM0/0/0 bpx 1.3.2
tag-switching atm vp-tunnel 2
tag-switching ip
!
interface XTagATM22
ip unnumbered Loopback0
extended-port ATM0/0/0 bpx 2.2
tag-switching atm vpi 2-5
tag-switching ip
!
tag-switching atm disable-headend-vc
Edge LSR1 Configuration
7500 LSR1:
ip cef distributed
!
interface loopback 0
ip address 142.6.132.2 255.255.255.255
!
interface ATM2/0/0
no ip address
!
interface ATM2/0/0.22 tag-switching
ip unnumbered loopback 0
tag-switching atm vpi 2-5
tag-switching ip
Edge LSR2 Configuration
7500 LSR2:
ip cef distributed
!
interface loopback 0
ip address 142.6.142.2 255.255.255.255
!
interface ATM2/0/0
no ip address
!
interface ATM2/0/0.22 tag-switching
unnumbered loopback 0
tag-switching atm vpi 2-5
tag-switching ip
Cisco IOS Switching Services Configuration Guide
XC-234
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Configuring LSC Hot Redundancy Example
The network topology shown in Figure 61 incorporates two ATM-LSRs in an MPLS network. This
topology includes two LSCs on each BPX node and four edge LSRs.
The following configuration examples show the label-switching configuration for both standard
downstream-on-demand interfaces and downstream on demand over a VP-tunnel. The difference
between these two types of configurations is as follows:
•
Standard interface configuration configures a VPI range of one or more VPIs while LDP control
information flows in PVC 0,32.
•
VP-tunnel configures a single VPI (such as vpi 12) and uses a tag-switching atm control-vc of
vpi,32 global configuration command (for example, 12,32). You can use a VP-tunnel to establish
label-switching neighbor relationships through a private ATM cloud.
The following configuration examples are provided in this section:
•
LSC 1A Configuration
•
LSC 1B Configuration
•
LSC 2A Configuration
•
LSC 2B Configuration
•
BPX1 and BPX2 Configuration
•
Edge LSR 7200-1 Configuration
•
Edge LSR 7500-1 Configuration
•
Edge LSR 7500-2 Configuration
•
Edge LSR 7200-2 Configuration
For the IGX, use the following commands:
extended-port atm1/0 descriptor 0.x.x.0
tag-control-protocol vsi slaves 32 id x
Figure 61
ATM-LSR Network Configuration Example
LSC 1A
7200
a3/0
1.1
a2/0
7200-1
LER
a3/0
LSC 1B
7200
a3/0
LSC 2A
7200
a3/0
2.1
1.1
1.5
2.5
1.2
2.2
LSC 2B
7200
a3/0
2.1
1.5
2.5
1.2
2.2
a3/0/0
7500-2
LER
BPX-2
BPX-1
a2/0/0
a2/0
1.6.12
1.6.22
2.6.12
2.6.22
2.6.12
2.6.22
ATM cloud
1.6.12
1.6.22
7200-2
LER
35637
7500-1
LER
a2/0/0
Cisco IOS Switching Services Configuration Guide
XC-235
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Note
In the following configuration examples for the LSCs, you can use the tag-switching request-tags
for global configuration command instead of the tag-switching atm disable headend-vc global
configuration command.
LSC 1A Configuration
7200 LSC 1A:
ip cef
!
tag-switching atm disable-headend vc
!
interface loopback0
ip address 192.103.210.5 255.255.255.255
!
interface ATM3/0
no ip address
tag-control-protocol vsi id 1
!
interface XTagATM12
ip unnumbered loopback0
extended-port ATM3/0 bpx 1.2
tag-switching atm vpi 2-5
tag-switching ip
!
interface XTagATM15
ip unnumbered loopback0
extended-port ATM3/0 bpx 1.5
tag-switching atm vpi 2-15
tag-switching ip
!
interface XTagATM1612
ip unnumbered loopback0
extended-port ATM3/0 bpx 1.6.12
tag-switching atm vp-tunnel 12
tag-switching ip
!
interface XTagATM2612
ip unnumbered loopback0
extended-port ATM3/0 bpx 2.6.12
tag-switching atm vp-tunnel 12
tag-switching ip
LSC 1B Configuration
7200 LSC 1B:
ip cef
!
tag-switching atm disable-headend vc
!
!
interface loopback0
ip address 192.103.210.6 255.255.255.255
!
interface ATM3/0
no ip address
tag-control-protocol vsi id 2
!
interface XTagATM22
ip unnumbered loopback0
extended-port ATM3/0 bpx 2.2
tag-switching atm vpi 2-5
Cisco IOS Switching Services Configuration Guide
XC-236
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
tag-switching ip
!
interface XTagATM25
ip unnumbered loopback0
extended-port ATM3/0 bpx 2.5
tag-switching atm vpi 2-15
tag-switching ip
!
interface XTagATM1622
ip unnumbered loopback0
extended-port ATM3/0 bpx 1.6.22
tag-switching atm vp-tunnel 22
tag-switching ip
!
interface XTagATM2622
ip unnumbered loopback0
extended-port ATM3/0 bpx 2.6.22
tag-switching atm vp-tunnel 22
tag-switching ip
LSC 2A Configuration
7200 LSC 2A:
ip cef
!
tag-switching atm disable-headend vc
!
interface loopback0
ip address 192.103.210.7 255.255.255.255
!
interface ATM3/0
no ip address
tag-control-protocol vsi id 1
!
interface XTagATM12
ip unnumbered loopback0
extended-port ATM3/0 bpx 1.2
tag-switching atm vpi 2-5
tag-switching ip
!
interface XTagATM15
ip unnumbered loopback0
extended-port ATM3/0 bpx 1.5
tag-switching atm vpi 2-15
tag-switching ip
!
interface XTagATM1612
ip unnumbered loopback0
extended-port ATM3/0 bpx 1.6.12
tag-switching atm vp-tunnel 12
tag-switching ip
!
interface XTagATM2612
ip unnumbered loopback0
extended-port ATM3/0 bpx 2.6.12
tag-switching atm vp-tunnel 12
tag-switching ip
Cisco IOS Switching Services Configuration Guide
XC-237
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
LSC 2B Configuration
7200 LSC 2B:
ip cef
!
tag-switching atm disable-headend vc
!
interface loopback0
ip address 192.103.210.8 255.255.255.255
!
interface ATM3/0
no ip address
tag-control-protocol vsi id 2
!
interface XTagATM22
ip unnumbered loopback0
extended-port ATM3/0 bpx 2.2
tag-switching atm vpi 2-5
tag-switching ip
!
interface XTagATM25
ip unnumbered loopback0
extended-port ATM3/0 bpx 2.5
tag-switching atm vpi 2-15
tag-switching ip
!
interface XTagATM1622
ip unnumbered loopback0
extended-port ATM3/0 bpx 1.6.22
tag-switching atm vp-tunnel 22
tag-switching ip
!
interface XTagATM2622
ip unnumbered loopback0
extended-port ATM3/0 bpx 2.6.22
tag-switching atm vp-tunnel 22
tag-switching ip
BPX1 and BPX2 Configuration
BPX1 and BPX2:
uptrk 1.1
addshelf 1.1 vsi 1 1
cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000
upln 1.2
upport 1.2
cnfrsrc 1.2 256 252207 y 1 e 512 6144 2 5 26000 100000
uptrk 1.5
cnfrsrc 1.5 256 252207 y 1 e 512 6144 2 15 26000 100000
uptrk 1.6.12
cnftrk 1.6.12 110000 N 1000 7F V,TS,NTS,FR,FST,CBR,NRT-VBR,ABR,
RT-VBR N TERRESTRIAL 10 0 N N Y Y Y CBR 12
cnfrsrc 1.6.12 256 252207 y 1 e 512 6144 12 12 26000 100000
uptrk 1.6.22
cnftrk 1.6.22 110000 N 1000 7F V,TS,NTS,FR,FST,CBR,NRT-VBR,ABR,
RT-VBR N TERRESTRIAL 10 0 N N Y Y Y CBR 22
cnfrsrc 1.6.22 256 252207 y 2 e 512 6144 22 22 26000 100000
uptrk 2.1
addshelf 2.1 vsi 2 2
cnfrsrc 2.1 256 252207 y 2 e 512 6144 2 15 26000 100000
upln 2.2
upport 2.2
cnfrsrc 2.2 256 252207 y 2 e 512 4096 2 5 26000 100000
Cisco IOS Switching Services Configuration Guide
XC-238
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
uptrk 2.5
cnfrsrc 2.5 256 252207 y 2 e 512 6144 2 15 26000 100000
uptrk 2.6.12
cnftrk 2.6.12 110000 N 1000 7F V,TS,NTS,FR,FST,CBR,NRT-VBR,ABR,
RT-VBR N TERRESTRIAL 10 0 N N Y Y Y CBR 12
cnfrsrc 2.6.12 256 252207 y 1 e 512 6144 12 12 26000 100000
uptrk 2.6.22
cnftrk 2.6.22 110000 N 1000 7F V,TS,NTS,FR,FST,CBR,NRT-VBR,ABR,
RT-VBR N TERRESTRIAL 10 0 N N Y Y Y CBR 22
cnfrsrc 2.6.22 256 252207 y 2 e 512 6144 22 22 26000 100000
Note
For the shelf controller, you must configure a VSI partition for the slave control port interface
(addshelf 1.1, cnfrsrc 1.1...). However, do not configure an XtagATM port for the VSI partition (for
example, XtagATM11).
Edge LSR 7200-1 Configuration
7200-1 edge LSR:
ip cef
!
interface loopback0
ip address 192.103.210.1 255.255.255.255
!
interface ATM2/0
no ip address
!
interface ATM2/0.12 tag-switching
ip unnumbered loopback 0
tag-switching atm vpi 2-5
tag-switching ip
!
interface ATM3/0
no ip address
interface ATM3/0.22 tag-switching
ip unnumbered loopback 0
tag-switching atm vpi 2-5
tag-switching ip
Edge LSR 7500-1 Configuration
7500-1 edge LSR:
ip cef distributed
!
interface loopback0
ip address 192.103.210.2 255.255.255.255
!
interface ATM2/0/0
no ip address
!
interface ATM2/0/0.1612 tag-switching
ip unnumbered loopback0
tag-switching atm vp-tunnel 12
tag-switching ip
!
interface ATM2/0/0.1622 tag-switching
ip unnumbered loopback0
tag-switching atm vp-tunnel 22
tag-switching ip
Cisco IOS Switching Services Configuration Guide
XC-239
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Edge LSR 7500-2 Configuration
7500-2 edge LSR:
ip cef distributed
!
interface loopback0
ip address 192.103.210.3 255.255.255.255
!
interface ATM2/0/0
no ip address
!
interface ATM2/0/0.12 tag-switching
ip unnumbered loopback0
tag-switching atm vpi 2-5
tag-switching ip
!!
interface ATM3/0/0
no ip address
!
interface ATM3/0/0.22 tag-switching
ip unnumbered loopback0
tag-switching atm vpi 2-5
tag-switching ip
Edge LSR 7200-2 Configuration
7200-2 edge LSR:
ip cef
!
interface loopback0
ip address 192.103.210.4 255.255.255.255
!
interface ATM2/0
no ip address
!
interface ATM2/0.1612 tag-switching
ip unnumbered loopback0
tag-switching atm vp-tunnel 12
tag-switching ip
!
interface ATM2/0.1622 tag-switching
ip unnumbered loopback0
tag-switching atm vp-tunnel 22
tag-switching ip
Configuring LSC Warm Standby Redundancy Example
The configuration of LSC Warm Standby redundancy can be implemented by configuring the redundant
link for either a higher routing cost than the primary link or configuring a bandwidth allocation that is
less desirable. This needs to be performed only at the edge LSR nodes, because the LSCs have been
configured to disable the creation of headend VCs, which reduces the LVC overhead.
Cisco IOS Switching Services Configuration Guide
XC-240
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Configuring an Interface Using Two VSI Partitions Example
A special case may arise where a network topology can only support a neighbor relationship between
peers using a single trunk or line interface. To configure the network, perform the following steps:
Step 1
Configure the interface to use both VSI partitions. The VSI partition configuration for the interface must
be made with no overlapping VP space. For example, for interface 2.8 on the ATM-LSR, the following
configuration is required:
uptrk 2.8
cnfrsrc 2.8 256 252207 y 1 e 512 6144 2 15 26000 100000
cnfrsrc 2.8 256 252207 y 2 e 512 6144 16 29 26000 100000
Thus partition 1 will create LVCs using VPIs 2-15 and partition 2 will create LVCs using VPIs 16-29.
Step 2
Configure the control-vc. Each LSC requires a control VC (default 0,32); however, only one LSC can
use this defeat control-vc for any one trunk interface. The following command forces the control VC
assignment.
tag-switching atm control-vc <vpi>,<vci>
Therefore, LSC 1 XTagATM28 can use the default control-vc 0,32 (but it is suggested that you use 2,32
to reduce configuration confusion) and the LSC 2 XTagATM28 should use control-vc 16,32.
For the IGX, use the following commands:
extended-port atm1/0 descriptor 0.x.x.0
tag-control-protocol vsi slaves 32 id x
The following example shows the configuration steps:
LSC1 Configuration
interface XTagATM2801
ip unnumbered loopback0
extended-port ATM3/0 bpx 2.8
tag-switching atm vpi 2-15
tag-switching atm control-vc 2 32
tag-switching ip
LSC2 Configuration
interface XTagATM2802
ip unnumbered loopback0
extended-port ATM3/0 bpx 2.8
tag-switching atm vpi 16-29
tag-switching atm control-vc 16 32
tag-switching ip
Cisco IOS Switching Services Configuration Guide
XC-241
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Using an Access List to Control the Creation of Headend VCs
The following example shows how to use an access list to control the creation of headend VCs in an
MPLS network, which allows the network to support more destinations.
Figure 62 shows two edge LSRs and two ATM-LSRs. In the configuration, only LSPs between edge
LSRs are required to provide label switched paths. Other LSPs are not essential. The LSPs between LSCs
and between the LSCs and the edge LSRs are often unused and required only for monitoring and
maintaining the network. In such cases the IP forwarding path is sufficient.
Sample MPLS Network
LSC 1
192.0.0.1
2.2
Edge LSR 1
198.0.0.1
a2/0/0
BPX 1
LSC 1
192.0.0.1
1.3
1.3
BPX 2
2.2
a2/0
ATM-LSR
ATM-LSR
Edge LSR 2
198.0.0.2
46929
Figure 62
In networks that require connections only between edge LSRs, you can use the access list to eliminate
the creation of unnecessary LSPs. This allows LVC resources to be conserved so that more edge LSR
connections can be supported.
To prevent creation of LSPs between LSCs, create an access list that denies all 192.0.0.0/24 addresses.
Then, to prevent creation of LVCs from the LSCs to the edge LSRs, create an access list that denies all
198.0.0.0/24 addresses. The configuration examples for LSC 1 and 2 show the commands for performing
these tasks.
To prevent creation of LVCs from the edge LSRs to LSCs, create an access list at the edge LSRs that
denies all 192.0.0.0/24 addresses. The configuration examples for edge LSR 1 and 2 show the commands
for performing this task.
LSC 1 Configuration
7200 LSC1:
ip cef
!
tag-switching request-tags for acl_lsc
ip access-list standard acl_lsc
deny
192.0.0.0 0.255.255.255
deny
198.0.0.0 0.255.255.255
permit any
!
interface loopback0
ip address 192.0.0.1 255.255.255.255
!
interface ATM3/0
no ip address
tag-control-protocol vsi
!
Cisco IOS Switching Services Configuration Guide
XC-242
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
interface XTagATM13
extended-port ATM3/0 bpx 1.3
ip unnumbered loopback0
tag-switching atm vpi 2-15
tag-switching ip
!
interface XTagATM22
extended-port ATM3/0 bpx 2.2
ip unnumbered loopback0
tag-switching atm vpi 2-5
tag-switching ip
BPX1 and BPX2 Configuration
BPX1 and BPX2:
uptrk 1.1
addshelf 1.1 v 1 1
cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000
uptrk 1.3
cnfrsrc 1.3 256 252207 y 1 e 512 6144 2 15 26000 100000
uptrk 2.2
cnfrsrc 2.2 256 252207 y 1 e 512 4096 2 5 26000 100000
Note
For the shelf controller, you must configure a VSI partition for the slave control port interface
(addshelf 1.1, cnfrsrc 1.1...). However, do not configure an XtagATM port for the VSI partition (for
example, XtagATM11).
LSC 2 Configuration
7200 LSC2:
ip cef
!
tag-switching request-tags for acl_lsc
ip access-list standard acl_lsc
deny
192.0.0.0 0.255.255.255
deny
198.0.0.0 0.255.255.255
permit any
!
interface loopback0
ip address 192.0.0.2 255.255.255.255
!
interface ATM3/0
no ip address
tag-control-protocol vsi
!
interface XTagATM13
extended-port ATM3/0 bpx 1.3
ip unnumbered loopback0
tag-switching atm vpi 2-15
tag-switching ip
!
interface XTagATM22
extended-port ATM3/0 bpx 2.2
ip unnumbered loopback0
tag-switching atm vpi 2-5
tag-switching ip
!
Cisco IOS Switching Services Configuration Guide
XC-243
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
Edge LSR 1 Configuration
7500 LSR1:
ip cef distributed
!
tag-switching request-tags for acl_ler
ip access-list standard acl_ler
deny
192.0.0.0 0.255.255.255
permit any
!
interface loopback 0
ip address 198.0.0.1 255.255.255.255
!
interface ATM2/0/0
no ip address
!
interface ATM2/0/0.22 tag-switching
ip unnumbered loopback 0
tag-switching atm vpi 2-5
tag-switching ip
Edge LSR 2 Configuration
7200 LSR2:
ip cef
!
tag-switching request-tags for acl_ler
ip access-list standard acl_ler
deny
192.0.0.0 0.255.255.255
permit any
!
interface loopback 0
ip address 198.0.0.2 255.255.255.255
!
interface ATM2/0
no ip address
!
interface ATM2/0.22 tag-switching
ip unnumbered loopback 0
tag-switching atm vpi 2-5
tag-switching ip
MPLS Egress NetFlow Accounting Example
In the following example, the VPN routing and forwarding (VRF) instances currently configured in the
router is displayed:
Router# show ip vrf
Name
vpn1
Default RD
100:1
vpn3
300:1
Interfaces
Ethernet1/4
Loopback1
Ethernet1/2
Loopback2
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface eth1/4
Router(config-if)# mpls ?
ip
Configure dynamic MPLS forwarding for IP
label-protocol Configure label/tag distribution protocol (LDP/TDP)
mtu
Set tag switching Maximum Transmission Unit
Cisco IOS Switching Services Configuration Guide
XC-244
Configuring Multiprotocol Label Switching
MPLS Configuration Examples
netflow
traffic-eng
Configure Egress Netflow Accounting
Configure Traffic Engineering parameters
Router(config-if)# mpls net
Router(config-if)# mpls netflow ?
egress Enable Egress Netflow Accounting
MPLS egress NetFlow accounting is enabled on interface eth1/4 and debugging is turned on, as follows:
Router(config-if)# mpls netflow egress
Router(config-if)#
Router(config-if)#
Router# debug mpls netflow
MPLS Egress NetFlow debugging is on
Router#
The following example shows the current configuration in the router:
Router# show run
Building configuration...
Current configuration:
!
version 12.0
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
ip cef
no ip domain-lookup
!
The VRF is defined, as follows:
ip vrf vpn1
rd 100:1
route-target export 100:1
route-target import 100:1
!
interface Loopback0
ip address 41.41.41.41 255.255.255.255
no ip directed-broadcast
no ip mroute-cache
!
interface Ethernet1/4
ip vrf forwarding vpn1
ip address 180.1.1.1 255.255.255.0
no ip directed-broadcast
mpls netflow egress
!
Cisco IOS Switching Services Configuration Guide
XC-245
Multilayer Switching
Multilayer Switching Overview
This chapter provides an overview of Multilayer Switching (MLS).
Note
The information in this chapter is a brief summary of the information contained in the Catalyst 5000
Series Multilayer Switching User Guide. The commands and configurations described in this guide
apply only to the devices that provide routing services. Commands and configurations for Catalyst
5000 series switches are documented in the Catalyst 5000 Series Multilayer Switching User Guide.
MLS provides high-performance Layer 3 switching for Cisco routers and switches. MLS switches IP
data packets between subnets using advanced application-specific integrated circuit (ASIC) switching
hardware. Standard routing protocols, such as Open Shortest Path First (OSPF), Enhanced Interior
Gateway Routing Protocol (Enhanced IGRP), Routing Information Protocol (RIP), and Intermediate
System-to-Intermediate System (IS-IS), are used for route determination.
MLS enables hardware-based Layer 3 switching to offload routers from forwarding unicast IP data
packets over shared media networking technologies such as Ethernet. The packet forwarding function is
moved onto Layer 3 Cisco series switches whenever a partial or complete switched path exists between
two hosts. Packets that do not have a partial or complete switched path to reach their destinations still
use routers for forwarding packets.
MLS also provides traffic statistics as part of its switching function. These statistics are used for
identifying traffic characteristics for administration, planning, and troubleshooting. MLS uses NetFlow
Data Export (NDE) to export the flow statistics.
Procedures for configuring MLS and NDE on routers are provided in the “Configuring IP Multilayer
Switching” chapter.
Procedures for configuring MLS and NDE on routers are provided in the following chapters in this
publication:
•
“Configuring IP Multilayer Switching” chapter
•
“Configuring IP Multicast Multilayer Switching” chapter
•
“Configuring IPX Multilayer Switching” chapter
This chapter describes MLS. It contains the following sections:
•
Terminology
•
Introduction to MLS
•
Key MLS Features
•
MLS Implementation
•
Standard and Extended Access Lists
Cisco IOS Switching Services Configuration Guide
XC-247
Multilayer Switching Overview
Terminology
•
Introduction to IP Multicast MLS
•
Introduction to IPX MLS
•
Guidelines for External Routers
•
Features That Affect MLS
Terminology
The following terminology is used in the MLS chapters:
•
Multilayer Switching-Switching Engine (MLS-SE)—A NetFlow Feature Card (NFFC)-equipped
Catalyst 5000 series switch.
•
Multilayer Switching-Route Processor (MLS-RP)—A Cisco router with MLS enabled.
•
Multilayer Switching Protocol (MLSP)—The protocol running between the MLS-SE and MLS-RP
to enable MLS.
Introduction to MLS
Layer 3 protocols, such as IP and Internetwork Packet Exchange (IPX), are connectionless—they deliver
each packet independently of each other. However, actual network traffic consists of many end-to-end
conversations, or flows, between users or applications.
A flow is a unidirectional sequence of packets between a particular source and destination that share the
same protocol and transport-layer information. Communication from a client to a server and from the
server to the client is in separate flows. For example, HTTP Web packets from a particular source to a
particular destination are in a separate flow from File Transfer Protocol (FTP) file transfer packets
between the same pair of hosts.
Flows can be based on only Layer 3 addresses. This feature allows IP traffic from multiple users or
applications to a particular destination to be carried on a single flow if only the destination IP address is
used to identify a flow.
The NFFC maintains a Layer 3 switching table (MLS cache) for the Layer 3-switched flows. The cache
also includes entries for traffic statistics that are updated in tandem with the switching of packets.
After the MLS cache is created, packets identified as belonging to an existing flow can be
Layer 3-switched based on the cached information. The MLS cache maintains flow information for all
active flows. When the Layer 3-switching entry for a flow ages out, the flow statistics can be exported
to a flow collector application.
For information on multicast MLS, see the “Introduction to IP Multicast MLS” section in this chapter.
Cisco IOS Switching Services Configuration Guide
XC-248
Multilayer Switching Overview
Key MLS Features
Key MLS Features
Table 37 lists the key MLS features.
Table 37
Summary of Key Features
Feature
Description
Ease of Use
Is autoconfigurable and autonomously sets up its Layer 3 flow cache. Its “plug-and-play” design
eliminates the need for you to learn new IP switching technologies.
Transparency
Requires no end-system changes and no renumbering of subnets. It works with DHCP1 and requires
no new routing protocols.
Standards Based
Uses IETF2 standard routing protocols such as OSPF and RIP for route determination. You can
deploy MLS in a multivendor network.
Investment Protection Provides a simple feature-card upgrade on the Catalyst 5000 series switches. You can use MLS with
your existing chassis and modules. MLS also allows you to use either an integrated RSM or an
external router for route processing and Cisco IOS services.
Fast Convergence
Allows you to respond to route failures and routing topology changes by performing
hardware-assisted invalidation of flow entries.
Resilience
Provides the benefits of HSRP3 without additional configuration. This feature enables the switches
to transparently switch over to the Hot Standby backup router when the primary router goes offline,
eliminating a single point of failure in the network.
Access Lists
Allows you to set up access lists to filter, or to prevent traffic between members of different subnets.
MLS enforces multiple security levels on every packet of the flow at wire speed. It allows you to
configure and enforce access control rules on the RSM. Because MLS parses the packet up to the
transport layer, it enables access lists to be validated. By providing multiple security levels, MLS
enables you to set up rules and control traffic based on IP addresses and transport-layer application
port numbers.
Accounting and
Traffic Management
Allows you to see data flows as they are switched for troubleshooting, traffic management, and
accounting purposes. MLS uses NDE to export the flow statistics. Data collection of flow statistics
is maintained in hardware with no impact on switching performance. The records for expired and
purged flows are grouped and exported to applications such as NetSys for network planning,
RMON24 traffic management and monitoring, and accounting applications.
Network Design
Simplification
Enables you to speed up your network while retaining the existing subnet structure. It makes the
number of Layer 3 hops irrelevant in campus design, enabling you to cope with increases in
any-to-any traffic.
Media Speed Access
to Server Farms
You do not need to centralize servers in multiple VLANs to get direct connections. By providing
security on a per-flow basis, you can control access to the servers and filter traffic based on subnet
numbers and transport-layer application ports without compromising Layer 3 switching
performance.
Faster Interworkgroup Addresses the need for higher-performance interworkgroup connectivity by intranet and multimedia
Connectivity
applications. By deploying MLS, you gain the benefits of both switching and routing on the same
platform.
1. DHCP = Dynamic Host Configuration Protocol
2. IETF = Internet Engineering Task Force
3. HSRP = Hot Standby Router Protocol
4. RMON2 = Remote Monitoring 2
Cisco IOS Switching Services Configuration Guide
XC-249
Multilayer Switching Overview
MLS Implementation
MLS Implementation
This section provides a step-by-step description of MLS implementation.
Note
The MLS-RPs shown in the figures represent either a RSM or an externally attached Cisco router.
The MLSP informs the Catalyst 5000 series switch of the MLS-RP MAC addresses used on different
VLANs and the MLS-RP’s routing and access list changes. Through this protocol, the MLS-RP
multicasts its MAC and VLAN information to all MLS-SEs. When the MLS-SE hears the MLSP hello
message indicating an MLS initialization, the MLS-SE is programmed with the MLS-RP MAC address
and its associated VLAN number (see Figure 63).
MLS Implementation
MLS-RP multicasts its
MAC addresses and
VLAN number to all
MLS-SEs…
MLS-RP
(MLS-SE)
… all MLS-SEs
program the NFFC
with the MSLP hello
message information
12000
Figure 63
In Figure 64, Host A and Host B are located on different VLANs. Host A initiates a data transfer to
Host B. When Host A sends the first packet to the MLS-RP, the MLS-SE recognizes this packet as a
candidate packet for Layer 3 switching because the MLS-SE has learned the MLS-RP’s destination
MAC address and VLAN through MLSP. The MLS-SE learns the Layer 3 flow information (such as the
destination address, source address, and protocol port numbers), and forwards the first packet to the
MLS-RP. A partial MLS entry for this Layer 3 flow is created in the MLS cache.
The MLS-RP receives the packet, looks at its route table to determine how to forward the packet, and
applies services such as Access Control Lists (ACLs) and class of service (COS) policy.
The MLS-RP rewrites the MAC header adding a new destination MAC address (Host B’s) and its own
MAC address as the source.
Cisco IOS Switching Services Configuration Guide
XC-250
Multilayer Switching Overview
MLS Implementation
Figure 64
MLS Implementation
Because the Catalyst switch has learned
the MAC and VLAN information of the MLS-RP,
the switch starts the MLS process for the Layer 3
flow contained in this packet, the candidate packet
MLS-RP
Candidate packet
Host A
Host B
12001
(MLS-SE)
The MLS-RP routes the packet to Host B. When the packet appears back on the Catalyst 5000 series
switch backplane, the MLS-SE recognizes the source MAC address as that of the MLS-RP, and that the
packet’s flow information matches the flow for which it set up a candidate entry. The MLS-SE considers
this packet an enabler packet and completes the MLS entry (established by the candidate packet) in the
MLS cache (see Figure 65).
Figure 65
MLS Implementation
The MLS-RP routes this packet to Host B. Because the
MLS-SE has learned both this MLS-RP and the Layer 3
flow in this packet, it completes the MLS entry in the
MLS cache. The first routed packet is called the
enabler packet
MLS-RP
Enabler packet
Host A
Host B
12002
(MLS-SE)
After the MLS entry has been completed, all Layer 3 packets with the same flow from Host A to Host B
are Layer 3 switched directly inside the switch from Host A to Host B, bypassing the router
(see Figure 66). After the Layer 3-switched path is established, the packet from Host A is rewritten by
the MLS-SE before it is forwarded to Host B. The rewritten information includes the MAC addresses,
encapsulations (when applicable), and some Layer 3 information.
The resultant packet format and protocol behavior is identical to that of a packet that is routed by the
RSM or external Cisco router.
Note
MLS is unidirectional. For Host B to communicate with Host A, another Layer 3-switched path needs
to be created from Host B to Host A.
Cisco IOS Switching Services Configuration Guide
XC-251
Multilayer Switching Overview
Standard and Extended Access Lists
Figure 66
MLS Implementation
MLS-RP
With the MLS entry from Host A to B established, the
Layer 3 traffic for this flow is switched directly inside
the Catalyst switch without going to the router
Host A
Host B
12003
(MLS-SE)
Layer 3-switched packets
See the Catalyst 5000 Series Multilayer Switching User Guide for additional network implementation
examples that include network topologies that do not support MLS.
Standard and Extended Access Lists
Note
Router interfaces with input access lists cannot participate in MLS. However, any input access list
can be translated to an output access list to provide the same effect on the interface. For complete
details on how input and output access lists affect MLS, see the chapter “Configuring Multilayer
Switching.”
MLS allows you to enforce access lists on every packet of the flow without compromising MLS
performance. When you enable MLS, standard and extended access lists are handled at wire speed by
the MLS-SE. Access lists configured on the MLS-RP take effect automatically on the MLS-SE.
Additionally, route topology changes and the addition of access lists are reflected in the switching path
of MLS.
Consider the case where an access list is configured on the MLS-RP to deny access from Station A to
Station B. When Station A wants to communicate with Station B, it sends the first packet to the MLS-RP.
The MLS-RP receives this packet and checks to learn if this packet flow is permitted. If an ACL is
configured for this flow, the packet is discarded. Because the first packet for this flow does not return
from the MLS-RP, an MLS cache entry is not established by the MLS-SE.
In another case, access lists are introduced on the MLS-RP while the flow is already being Layer 3
switched within the MLS-SE. The MLS-SE immediately enforces security for the affected flow by
purging it.
Similarly, when the MLS-RP detects a routing topology change, the appropriate MLS cache entries are
deleted in the MLS-SE. The techniques for handling route and access list changes apply to both the RSM
and directly attached external routers.
Cisco IOS Switching Services Configuration Guide
XC-252
Multilayer Switching Overview
Introduction to IP Multicast MLS
Restrictions on Using IP Router Commands with MLS Enabled
The following Cisco IOS commands affect MLS on your router:
•
clear ip-route—Clears all MLS cache entries for all Catalyst 5000 series switches performing
Layer 3 switching for this MLS-RP.
•
ip routing—The no form purges all MLS cache entries and disables MLS on this MLS-RP.
•
ip security (all forms of this command)—Disables MLS on the interface.
•
ip tcp compression-connections—Disables MLS on the interface.
•
ip tcp header-compression—Disables MLS on the interface.
General Guidelines
The following is a list of general guidelines to enabling MLS:
•
When you enable MLS, the RSM or externally attached router continues to handle all non-IP
protocols while offloading the switching of IP packets to the MLS-SE.
•
Do not confuse MLS with the NetFlow switching supported by Cisco routers. MLS uses both the
RSM or directly attached external router and the MLS-SE. With MLS, you are not required to use
NetFlow switching on the RSM or directly attached external router; any switching path on the RSM
or directly attached external router will work (process, fast, and so on).
Introduction to IP Multicast MLS
The IP multicast MLS feature provides high-performance, hardware-based, Layer 3 switching of IP
multicast traffic for routers connected to LAN switches.
An IP multicast flow is a unidirectional sequence of packets between a multicast source and the members
of a destination multicast group. Flows are based on the IP address of the source device and the
destination IP multicast group address.
IP multicast MLS switches IP multicast data packet flows between IP subnets using advanced, ASIC
switching hardware, thereby off loading processor-intensive, multicast packet routing from network
routers.
The packet forwarding function is moved onto the connected Layer 3 switch whenever a supported path
exists between a source and members of a multicast group. Packets that do not have a supported path to
reach their destinations are still forwarded in software by routers. Protocol Independent Multicast (PIM)
is used for route determination.
IP Multicast MLS Network Topology
IP multicast MLS requires specific network topologies to function correctly. In each of these topologies,
the source traffic is received on the switch, traverses a trunk link to the router, and returns to the switch
over the same trunk link to reach the destination group members. The basic topology consists of a switch
and an internal or external router connected through an ISL or 802.1Q trunk link.
Figure 67 shows this basic configuration before and after IP multicast MLS is deployed (assuming a
completely switched flow). The topology consists of a switch, a directly connected external router, and
multiple IP subnetworks (VLANs).
Cisco IOS Switching Services Configuration Guide
XC-253
Multilayer Switching Overview
Introduction to IP Multicast MLS
The network in the upper diagram in Figure 67 does not have the IP multicast MLS feature enabled.
Note the arrows from the router to each multicast group in each VLAN. In this case, the router must
replicate the multicast data packets to the multiple VLANs. The router can be easily overwhelmed with
forwarding and replicated multicast traffic if the input rate or the number of outgoing interfaces
increases.
As shown in the lower diagram in Figure 67, this potential problem is prevented by having the switch
hardware forward the multicast data traffic. (Multicast control packets are still moving between the
router and switch.)
Figure 67
Basic IP Multicast MLS Network Topology
Router
Before IP multicast MLS
Trunk link
VLANs 100, 200, 300
VLAN 100
Switch
G1
member
G1
source
VLAN 300
G1
member
G1
member
VLAN 200
Router
(MMLS-RP)
After IP multicast MLS
(completely switched)
Trunk link
VLANs 100, 200, 300
Switch
(MMLS-SE)
G1
member
G1
source
G1
member
VLAN 300
G1
member
VLAN 200
18952
VLAN 100
Benefits of multicast MLS are as follows:
•
Improves throughput—The improves throughput feature improves the router’s multicast Layer 3
forwarding and replication throughput.
•
Reduces load on router—If the router must replicate many multicast packets to many VLANs, it can
be overwhelmed as the input rate and number of outgoing interfaces increase. Configuring the
switch to replicate and forward the multicast flow reduces the demand on the router.
Cisco IOS Switching Services Configuration Guide
XC-254
Multilayer Switching Overview
Introduction to IP Multicast MLS
•
Provides IP multicast scalability—If you need high throughput of multicast traffic, install a
Catalyst 5000 series switch and configure the Provides IP Multicast Scalability feature. By reducing
the load on your router, the router can accommodate more multicast flows.
•
Provides meaningful flow statistics—IP multicast MLS provides flow statistics that can be used to
administer, plan, and troubleshoot networks.
IP Multicast MLS Components
An IP multicast MLS network topology has two components:
•
Multicast MLS-Switching Engine (MMLS-SE)—For example, a Catalyst 5000 series switch with
hardware that supports IP multicast MLS. The MMLS-SE provides Layer 3 LAN-switching
services.
•
Multicast MLS-Route Processor (MMLS-RP)—Routing platform running Cisco IOS software that
supports IP multicast MLS. The MMLS-RP interacts with the IP multicast routing software and
updates the MLS cache in the MMLS-SE. When you enable IP multicast MLS, the MMLS-RP
continues to handle all non-IP-multicast traffic while off loading IP multicast traffic forwarding to
the MMLS-SE.
Layer 2 Multicast Forwarding Table
The MMLS-SE uses the Layer 2 multicast forwarding table to determine on which ports Layer 2
multicast traffic should be forwarded (if any). The Layer 2 multicast forwarding table is populated by
enabling CGMP, IGMP snooping, or GMRP on the switch. These entries map the destination multicast
MAC address to outgoing switch ports for a given VLAN.
Layer 3 Multicast MLS Cache
The MMLS-SE maintains the Layer 3 MLS cache to identify individual IP multicast flows. Each entry
is of the form {source IP, destination group IP, source VLAN}. The maximum MLS cache size is 128K
and is shared by all MLS processes on the switch (such as IP unicast MLS and IPX MLS). However, if
the total of cache entries exceeds 32K, there is increased probability that a flow will not be switched by
the MMLS-SE and will get forwarded to the router.
The MMLS-SE populates the MLS cache using information learned from the routers participating in IP
multicast MLS. The router and switch exchange information using the multicast MLSP.
Whenever the router receives traffic for a new flow, it updates its multicast routing table and forwards
the new information to the MMLS-SE using multicast MLSP. In addition, if an entry in the multicast
routing table is aged out, the router deletes the entry and forwards the updated information to the
MMLS-SE.
The MLS cache contains flow information for all active multilayer switched flows. After the MLS cache
is populated, multicast packets identified as belonging to an existing flow can be Layer 3 switched based
on the cache entry for that flow. For each cache entry, the MMLS-SE maintains a list of outgoing
interfaces for the destination IP multicast group. The MMLS-SE uses this list to determine on which
VLANs traffic to a given multicast flow should be replicated.
Cisco IOS Switching Services Configuration Guide
XC-255
Multilayer Switching Overview
Introduction to IP Multicast MLS
IP Multicast MLS Flow Mask
IP multicast MLS supports a single flow mask, source destination vlan. The MMLS-SE maintains one
multicast MLS cache entry for each {source IP, destination group IP, source VLAN}. The multicast
source destination vlan flow mask differs from the IP unicast MLS source destination ip flow mask in
that, for IP multicast MLS, the source VLAN is included as part of the entry. The source VLAN is the
multicast Reverse Path Forwarding (RPF) interface for the multicast flow.
Layer 3-Switched Multicast Packet Rewrite
When a multicast packet is Layer 3-switched from a multicast source to a destination multicast group,
the MMLS-SE performs a packet rewrite based on information learned from the MMLS-RP and stored
in the multicast MLS cache.
For example, if Server A sends a multicast packet addressed to IP multicast group G1 and members of
group G1 are on VLANs other than the source VLAN, the MMLS-SE must perform a packet rewrite
when it replicates the traffic to the other VLANs (the switch also bridges the packet in the source
VLAN).
When the MMLS-SE receives the multicast packet, it is formatted similarly to the sample shown in
Table 38.
Table 38
Layer 3-Switched Multicast Packet Header
Frame Header
IP Header
Payload
Destination
Source
Destination
Source
TTL Checksum
Group G1
MAC
Server A
MAC
Group G1 IP Server A IP n
Data
Checksum
calculation1
The MMLS-SE rewrites the packet as follows:
•
Changes the source MAC address in the Layer 2 frame header from the MAC address of the server
to the MAC address of the MMLS-RP (this MAC address is stored in the multicast MLS cache entry
for the flow)
•
Decrements the IP header Time to Live (TTL) by one and recalculates the IP header checksum
The result is a rewritten IP multicast packet that appears to have been routed by the router.
The MMLS-SE replicates the rewritten packet onto the appropriate destination VLANs, where it is
forwarded to members of IP multicast group G1.
After the MMLS-SE performs the packet rewrite, the packet is formatted as shown in Table 39:
Table 39
Layer 3-Switched Multicast Packet Header with Rewrite
Frame Header
IP Header
Destination
Source
Destination
Group G1
MAC
MMLS-RP
MAC
Group G1 IP Server A IP n – 1
Cisco IOS Switching Services Configuration Guide
XC-256
Payload
Source
TTL
Checksum
calculation2
Data Checksum
Multilayer Switching Overview
Introduction to IPX MLS
Partially and Completely Switched Flows
When at least one outgoing router interface for a given flow is multilayer switched, and at least one
outgoing interface is not multilayer switched, that flow is considered partially switched. When a partially
switched flow is created, all multicast traffic belonging to that flow still reaches the router and is
software forwarded on those outgoing interfaces that are not multilayer switched.
A flow might be partially switched instead of completely switched in the following situations:
•
Some multicast group destinations are located across the router (not all multicast traffic is received
and sent on subinterfaces of the same trunk link).
•
The router is configured as a member of the IP multicast group (using the ip igmp join-group
interface command) on the RPF interface of the multicast source.
•
The router is the first-hop router to the source in PIM sparse mode (in this case, the router must send
PIM-register messages to the rendezvous point [RP]).
•
Multicast TTL threshold or multicast boundary is configured on an outgoing interface for the flow.
•
Multicast helper is configured on the RPF interface for the flow and multicast to broadcast
translation is required.
•
Access list restrictions are configured on an outgoing interface (see the “Access List Restrictions
and Guidelines” section in the “Configuring Multicast Multilayer Switching” chapter).
•
Integrated routing and bridging (IRB) is configured on the ingress interface.
•
An output rate limit is configured on an outgoing interface.
•
Multicast tag switching is configured on an outgoing interface.
When all the outgoing router interfaces for a given flow are multilayer switched, and none of the
situations described applies to the flow, that flow is considered completely switched. When a completely
switched flow is created, the MMLS-SE prevents multicast traffic bridged on the source VLAN for that
flow from reaching the MMLS-RP interface in that VLAN, reducing the load on the router.
One consequence of a completely switched flow is that the router cannot record multicast statistics for
that flow. Therefore, the MMLS-SE periodically sends multicast packet and byte count statistics for all
completely switched flows to the router using multicast MLSP. The router updates the corresponding
multicast routing table entry and resets the expiration timer for that multicast route.
Introduction to IPX MLS
The IPX MLS feature provides high-performance, hardware-based, Layer 3 switching for LAN switches.
IPX data packet flows are switched between networks, off loading processor-intensive packet routing
from network routers.
Whenever a partial or complete switched path exists between two hosts, packet forwarding occurs on
Layer 3 switches. Packets without such a partial or complete switched path are still forwarded by routers
to their destinations. Standard routing protocols such as RIP, Enhanced IGRP, and NetWare Link
Services Protocol (NLSP) are used for route determination.
IPX MLS also allows you to debug and trace flows in your network. Use MLS explorer packets to
identify which switch is handling a particular flow. These packets aid you in path detection and
troubleshooting.
Cisco IOS Switching Services Configuration Guide
XC-257
Multilayer Switching Overview
Introduction to IPX MLS
IPX MLS Components
An IPX MLS network topology has the following components:
•
MLS-SE—For example, a Catalyst 5000 series switch with the Netflow Feature Card (NFFC II).
The MLS-SE provides Layer 3 LAN-switching services.
•
MLS-RP—For example, a Catalyst 5000 series RSM or an externally connected Cisco 4500, 4700,
7200, or 7500 series router with software that supports MLS. The MLS-RP provides Cisco
IOS-based multiprotocol routing, network services, and central configuration and control for the
switches.
•
MLSP—The protocol running between the MLS-SE and MLS-RP that enables MLS.
IPX MLS Flows
Layer 3 protocols such as IP and IPX are connectionless—they deliver every packet independently of
every other packet. However, actual network traffic consists of many end-to-end conversations, or flows,
between users or applications.
A flow is a unidirectional packet sequence between a particular source and destination that share
identical protocol and network-layer information. Communication flows from a client to a server and
from the server to the client are distinct.
Flows are based only on Layer 3 addresses. If a destination IPX address identifies a flow, then IPX traffic
from multiple users or applications to a particular destination can be carried on a single flow.
Layer 3-switched flows appear in the MLS cache, a special Layer 3 switching table is maintained by the
NFFC II. The cache contains traffic statistics entries that are updated in tandem with packet switching.
After the MLS cache is created, packets identified as belonging to an existing flow can be Layer 3
switched. The MLS cache maintains flow information for all active flows.
MLS Cache
The MLS-SE maintains a cache for IPX MLS flows and maintains statistics for each flow. An IPX MLS
cache entry is created for the initial packet of each flow. Upon receipt of a packet that does not match
any flow in the MLS cache, a new IPX MLS entry is created.
The state and identity of the flow are maintained while packet traffic is active; when traffic for a flow
ceases, the entry ages out. You can configure the aging time for IPX MLS entries kept in the MLS cache.
If an entry is not used for the specified period of time, the entry ages out and statistics for that flow can
be exported to a flow collector application.
The maximum MLS cache size is 128,000 entries. However, an MLS cache larger than 32,000 entries
increases the probability that a flow will not be switched by the MLS-SE and will get forwarded to the
router.
Note
The number of active flows that can be switched using the MLS cache depends on the type of access
lists configured on MLS router interfaces (which determines the flow mask). See the “Flow Mask
Modes” section later in this document.
Cisco IOS Switching Services Configuration Guide
XC-258
Multilayer Switching Overview
Introduction to IPX MLS
Flow Mask Modes
Two flow mask modes—destination mode and destination-source mode—determine how IPX MLS
entries are created for the MLS-SE.
You determine the mode when you configure IPX access lists on the MLS-RP router interfaces. Each
MLS-RP sends MLSP messages about its flow mask to the MLS-SE, which performs Layer 3 switching.
The MLS-SE supports only the most specific flow mask for its MLS-RPs. If it detects more than one
mask, it changes to the most specific mask and purges the entire MLS cache. When an MLS-SE exports
cached entries, it creates flow records from the most current flow mask mode. Depending on the current
mode, some fields in the flow record might not have values. Unsupported fields are filled with a zero (0).
The two modes are described, as follows:
Note
•
Destination mode—The least-specific flow mask mode. The MLS-SE maintains one IPX MLS entry
for each destination IPX address (network and node). All flows to a given destination IPX address
use this IPX MLS entry. Use this mode if no access lists have been configured according to source
IPX address on any of the IPX MLS router interfaces. In this mode the destination IPX address of
the switched flows is displayed, along with the rewrite information: rewritten destination MAC,
rewritten VLAN, and egress port.
•
Destination-source mode—The MLS-SE maintains one MLS entry for each destination (network
and node) and source (network only) IPX address pair. All flows between a given source and
destination use this MLS entry regardless of the IPX sockets. Use this mode if an access list exists
on any MLS-RP IPX interfaces that filter on source network.
The flow mask mode determines the display of the show mls rp ipx EXEC command. Refer to the
Cisco IOS Switching Services Command Reference for details.
Layer 3-Switched Packet Rewrite
When a packet is Layer 3 switched from a source host to a destination host, the switch (MLS-SE)
performs a packet rewrite based on information it learned from the router (MLS-RP) and then stored in
the MLS cache.
If Host A and Host B are on different VLANs and Host A sends a packet to the MLS-RP to be routed to
Host B, the MLS-SE recognizes that the packet was sent to the MAC address of the MLS-RP. The
MLS-SE then checks the MLS cache and finds the entry matching the flow in question.
When the MLS-SE receives the packet, it is formatted as shown in Table 40:
Table 40
Layer 3-Switched Packet Header Sent to the MLS-RP
Frame Header
Encap
Destination
Source
MLS-RP
MAC
Host A
MAC
IPX Header
Payload
Length Checksum/ Packet Destination
Type Net/Node/
IPX
Socket
Length/
Transport
Host B IPX
Control1
Source
Net/Node/
Socket
Data PAD/FCS
Host A IPX
1. Transport Control counts the number of times this packet has been routed. If this number is greater than the maximum (the
default is 16), then the packet is dropped.
Cisco IOS Switching Services Configuration Guide
XC-259
Multilayer Switching Overview
Introduction to IPX MLS
The MLS-SE rewrites the Layer 2 frame header, changing the destination MAC address to that of Host B
and the source MAC address to that of the MLS-RP (these MAC addresses are stored in the IPX MLS
cache entry for this flow). The Layer 3 IPX addresses remain the same. The MLS-SE rewrites the
switched Layer 3 packets so that they appear to have been routed by a router.
The MLS-SE forwards the rewritten packet to Host B’s VLAN (the destination VLAN is saved in the
IPX MLS cache entry) and Host B receives the packet.
After the MLS-SE performs the packet rewrite, the packet is formatted as shown in Table 41:
Table 41
Layer 3-Switched Packet with Rewrite from the MLS-RP
Frame Header
Destination
Encap
Source
Host B MAC MLS-RP
MAC
IPX Header
Length Checksum/ Packet Destination
Type Net/Node/
IPX
Socket
Length/
Transport
Host B IPX
Control
Payload
Source
Net/Node/
Socket
Data PAD/FCS
Host A IPX
IPX MLS Operation
Figure 68 shows a simple IPX MLS network topology:
•
Host A is on the Sales VLAN (IPX address 01.Aa).
•
Host B is on the Marketing VLAN (IPX address 03.Bb).
•
Host C is on the Engineering VLAN (IPX address 02.Cc).
When Host A initiates a file transfer to Host B, an IPX MLS entry for this flow is created (see the first
item in Figure 68’s table). When the MLS-RP forwards the first packet from Host A through the switch
to Host B, the MLS-SE stores the MAC addresses of the MLS-RP and Host B in the IPX MLS entry. The
MLS-SE uses this information to rewrite subsequent packets from Host A to Host B.
Similarly, a separate IPX MLS entry is created in the MLS cache for the traffic from Host A to Host C,
and for the traffic from Host C to Host A. The destination VLAN is stored as part of each IPX MLS entry
so that the correct VLAN identifier is used for encapsulating traffic on trunk links.
Cisco IOS Switching Services Configuration Guide
XC-260
Multilayer Switching Overview
Introduction to IPX MLS
Figure 68
IPX MLS Example Topology
Source IPX
Address
Destination
IPX Address
Rewrite Src/Dst
MAC Address
Destination
VLAN
01.Aa
03.Bb
Dd:Bb
Marketing
01.Aa
02.Cc
Dd:Cc
Engineering
02.Cc
01.Aa
Dd:Aa
Sales
MAC = Bb
MAC = Dd
RSM
N
MAC = Aa
ting
arke
03
/M
et 3
Net 1/Sales
Net
01
2/E
ngin
02
01.Aa:02.Cc
MAC = Cc
Data
01.Aa:02.Cc
ing
Aa:Dd
Dd:Cc
18561
Data
eer
Standard Access Lists
Note
Router interfaces with input access lists or outbound access lists unsupported by MLS cannot
participate in IPX MLS. However, you can translate any input access list to an output access list to
provide the same effect on the interface.
IPX MLS enforces access lists on every packet of the flow, without compromising IPX MLS
performance. The MLS-SE handles permit traffic supported by MLS at wire speed.
Note
Access list deny traffic is always handled by the MLS-RP, not the MLS-SE.
The MLS switching path automatically reflects route topology changes and the addition or modification
of access lists on the MLS-SE. The techniques for handling route and access list changes apply to both
the RSM and directly attached external routers.
For example, for Stations A and B to communicate, Station A sends the first packet to the MLS-RP. If the
MLS-RP is configured with an access list to deny access from Station A to Station B, the MLS-RP
receives the packet, checks its access list permissions to learn if the packet flow is permitted, and then
discards the packet. Because the MLS-SE does not receive the returned first packet for this flow from
the MLS-RP, the MLS-SE does not create an MLS cache entry.
Cisco IOS Switching Services Configuration Guide
XC-261
Multilayer Switching Overview
Guidelines for External Routers
In contrast, if the MLS-SE is already Layer 3 switching a flow and the access list is created on the
MLS-RP, MLSP notifies the MLS-SE, and the MLS-SE immediately purges the affected flow from the
MLS cache. New flows are created based on the restrictions imposed by the access list.
Similarly, when the MLS-RP detects a routing topology change, the MLS-SE deletes the appropriate
MLS cache entries, and new flows are created based on the new topology.
Guidelines for External Routers
When using an external router, follow these guidelines:
•
We recommend one directly attached external router per Catalyst 5000 series switch to ensure that
the MLS-SE caches the appropriate flow information from both sides of the routed flow.
•
You can use Cisco high-end routers (Cisco 7500, 7200, 4500, and 4700 series) for MLS when they
are externally attached to the Catalyst 5000 series switch. You can make the attachment with
multiple Ethernets (one per subnet), by using Fast Ethernet with the ISL, or with Fast Etherchannel.
•
You can connect end hosts through any media (Ethernet, Fast Ethernet, ATM, and FDDI) but the
connection between the external router and the Catalyst 5000 series switch must be through standard
10/100 Ethernet interfaces, ISL links, or Fast Etherchannel.
Features That Affect MLS
This section describes how certain features affect MLS.
Access Lists
The following sections describe how access lists affect MLS.
Input Access Lists
Router interfaces with input access lists cannot participate in MLS. If you configure an input access list
on an interface, all packets for a flow that are destined for that interface go through the router (even if
the flow is allowed by the router it is not Layer 3 switched). Existing flows for that interface get purged
and no new flows are cached.
Note
Any input access list can be translated to an output access list to provide the same effect on the
interface.
Output Access Lists
If an output access list is applied to an interface, the MLS cache entries for that interface are purged.
Entries associated with other interfaces are not affected; they follow their normal aging or purging
procedures.
Applying an output access list to an interface, when the access list is configured using the log,
precedence, tos, or establish keywords, prevents the interface from participating in MLS.
Cisco IOS Switching Services Configuration Guide
XC-262
Multilayer Switching Overview
Features That Affect MLS
Access List Impact on Flow Masks
Access lists impact the flow mask advertised by an MLS-RP. When no access list on any MLS-RP
interface, the flow mask mode is destination-ip (the least specific). When there is a standard access list
is on any of the MLS-RP interfaces, the mode is source-destination-ip. When there is an extended access
list is on any of the MLS-RP interfaces, the mode is ip-flow (the most specific).
Reflexive Access Lists
Router interfaces with reflexive access lists cannot participate in Layer 3 switching.
IP Accounting
Enabling IP accounting on an MLS-enabled interface disables the IP accounting functions on that
interface.
Note
To collect statistics for the Layer 3-switched traffic, enable NDE.
Data Encryption
MLS is disabled on an interface when the data encryption feature is configured on the interface.
Policy Route Maps
MLS is disabled on an interface when a policy route map is configured on the interface.
TCP Intercept
With MLS interfaces enabled, the TCP intercept feature (enabled in global configuration mode) might
not work properly. When you enable the TCP intercept feature, the following message is displayed:
Command accepted, interfaces with mls might cause inconsistent behavior.
Network Address Translation
MLS is disabled on an interface when Network Address Translation (NAT) is configured on the
interface.
Committed Access Rate
MLS is disabled on an interface when committed access rate (CAR) is configured on the interface.
Cisco IOS Switching Services Configuration Guide
XC-263
Multilayer Switching Overview
Features That Affect MLS
Maximum Transmission Unit
The maximum transmission unit (MTU) for an MLS interface must be the default Ethernet MTU,
1500 bytes.
To change the MTU on an MLS-enabled interface, you must first disable MLS on the interface (enter no
mls rp ip global configuration command in the interface). If you attempt to change the MTU with MLS
enabled, the following message is displayed:
Need to turn off the mls router for this interface first.
If you attempt to enable MLS on an interface that has an MTU value other than the default value, the
following message is displayed:
mls only supports interfaces with default mtu size
Cisco IOS Switching Services Configuration Guide
XC-264
Configuring IP Multilayer Switching
This chapter describes how to configure your network to perform IP Multilayer Switching (MLS). This
chapter contains these sections:
•
Configuring and Monitoring MLS
•
Configuring NetFlow Data Export
•
Multilayer Switching Configuration Examples
For a complete description of the commands in this chapter, refer to the the Cisco IOS Switching Services
Command Reference. To locate documentation of other commands that appear in this chapter, use the
command reference master index or search online.
To identify the hardware platform or software image information associated with a feature, use the
Feature Navigator on Cisco.com to search for information about the feature or refer to the software
release notes for a specific release. For more information, see the section “Identifying Supported
Platforms” in the chapter “Using Cisco IOS Software.”
Note
The information in this chapter is a brief summary of the information contained in the Catalyst 5000
Series Multilayer Switching User Guide. The commands and configurations described in this guide
apply only to the devices that provide routing services. Commands and configurations for Catalyst
5000 series switches are documented in the Catalyst 5000 Series Multilayer Switching User Guide.
For configuration information for the Catalyst 6000 series switch, see Configuring and
Troubleshooting IP MLS on Catalyst 6000 with an MSFC or the “Configuring IP Multilayer
Switching” chapter in the Catalyst 6500 Series MSFC (12.x) & PFC Configuration Guide.
Configuring and Monitoring MLS
To configure your Cisco router for MLS, perform the tasks described in the following sections. The first
section contains a required task; the remaining tasks are optional. To ensure a successful MLS
configuration, you must also configure the Catalyst switches in your network. For a full description for
the Catalyst 5000 series, see the Catalyst 5000 Series Multilayer Switching User Guide. For a full
description for the Catalyst 6000 series, see the “Configuring IP Multilayer Switching” chapter in the
Catalyst 6500 Series MSFC (12.x) & PFC Configuration Guide. Only configuration tasks and commands
for routers are described in this chapter.
•
Configuring MLS on a Router (Required)
•
Monitoring MLS (Optional)
Cisco IOS Switching Services Configuration Guide
XC-265
Configuring IP Multilayer Switching
Configuring and Monitoring MLS
•
Monitoring MLS for an Interface (Optional)
•
Monitoring MLS Interfaces for VTP Domains (Optional)
Configuring MLS on a Router
To configure MLS on your router, use the following commands beginning in global configuration mode.
Depending upon your configuration, you might not have to perform all the steps in the procedure.
Command
Purpose
Step 1
Router(config)# mls rp ip
Globally enables MLSP. MLSP is the protocol that runs
between the MLS-SE and the MLS-RP.
Step 2
Router(config)# interface type number
Selects a router interface.
Step 3
Router(config-if)# mls rp vtp-domain
[domain-name]
Selects the router interface to be Layer 3 switched and then
adds that interface to the same VLAN Trunking Protocol
(VTP) domain as the switch. This interface is referred to as
the MLS interface. This command is required only if the
Catalyst switch is in a VTP domain.
Step 4
Router(config-if)# mls rp vlan-id
[vlan-id-num]
Assigns a VLAN ID to the MLS interface. MLS requires that
each interface has a VLAN ID. This step is not required for
RSM VLAN interfaces or ISL-encapsulated interfaces.
Step 5
Router(config-if)# mls rp ip
Enables each MLS interface.
Step 6
Router(config-if)# mls rp
management-interface
Selects one MLS interface as a management interface. MLSP
packets are sent and received through this interface. This can
be any MLS interface connected to the switch.
Repeat steps 2 through 5 for each interface that will
support MLS.
Note
The interface-specific commands in this section apply only to Ethernet, Fast Ethernet, VLAN, and
Fast Etherchannel interfaces on the Catalyst RSM/Versatile Interface Processor 2 (VIP2) or directly
attached external router.
To globally disable MLS on the router, use the following command in global configuration mode:
Command
Purpose
Router(config)# no mls rp ip
Disables MLS on the router.
Cisco IOS Switching Services Configuration Guide
XC-266
Configuring IP Multilayer Switching
Configuring and Monitoring MLS
Monitoring MLS
To display MLS details including specifics for MLSP, use the following commands in EXEC mode, as
needed:
•
MLS status (enabled or disabled) for switch interfaces and subinterfaces
•
Flow mask used by this MLS-enabled switch when creating Layer 3-switching entries for the router
•
Current settings of the keepalive timer, retry timer, and retry count
•
MLSP-ID used in MLSP messages
•
List of interfaces in all VTP domains that are enabled for MLS
Command
Purpose
Router# show mls rp
Displays MLS details for all interfaces.
After entering this command, you see this display:
router# show mls rp
multilayer switching is globally enabled
mls id is 00e0.fefc.6000
mls ip address 10.20.26.64
mls flow mask is ip-flow
vlan domain name: WBU
current flow mask: ip-flow
current sequence number: 80709115
current/maximum retry count: 0/10
current domain state: no-change
current/next global purge: false/false
current/next purge count: 0/0
domain uptime: 13:03:19
keepalive timer expires in 9 seconds
retry timer not running
change timer not running
fcp subblock count = 7
1 management interface(s) currently defined:
vlan 1 on Vlan1
7 mac-vlan(s) configured for multi-layer switching:
mac 00e0.fefc.6000
vlan id(s)
1
10
91
92
93
95
100
router currently aware of following 1 switch(es):
switch id 0010.1192.b5ff
Cisco IOS Switching Services Configuration Guide
XC-267
Configuring IP Multilayer Switching
Configuring and Monitoring MLS
Monitoring MLS for an Interface
To show MLS information for a specific interface, use the following command in EXEC mode:
Command
Purpose
Router# show mls rp [interface]
Displays MLS details for a specific interface.
After entering this command, you see this display:
router# show mls rp int vlan 10
mls active on Vlan10, domain WBU
router#
Monitoring MLS Interfaces for VTP Domains
To show MLS information for a specific VTP domain use the following command in EXEC mode:
Command
Purpose
Router# show mls rp vtp-domain [domain-name]
Displays MLS interfaces for a specific VTP domain.
After entering this command, you see this display:
router# show mls rp vtp-domain WBU
vlan domain name: WBU
current flow mask: ip-flow
current sequence number: 80709115
current/maximum retry count: 0/10
current domain state: no-change
current/next global purge: false/false
current/next purge count: 0/0
domain uptime: 13:07:36
keepalive timer expires in 8 seconds
retry timer not running
change timer not running
fcp subblock count = 7
1 management interface(s) currently defined:
vlan 1 on Vlan1
7 mac-vlan(s) configured for multi-layer switching:
mac 00e0.fefc.6000
vlan id(s)
1
10
91
92
93
95
100
router currently aware of following 1 switch(es):
switch id 0010.1192.b5ff
Cisco IOS Switching Services Configuration Guide
XC-268
Configuring IP Multilayer Switching
Configuring NetFlow Data Export
Configuring NetFlow Data Export
Note
You need to enable NDE only if you will export MLS cache entries to a data collection application.
Perform the task in this section to configure your Cisco router for NDE. To ensure a successful NDE
configuration, you must also configure the Catalyst switch. For a full description, see the Catalyst 5000
Series Multilayer Switching User Guide.
Specifying an NDE Address on the Router
To specify an NDE address on the router, use the following command in global configuration mode:
Command
Purpose
Router(config)# mls rp nde-address ip-address
Specifies an NDE IP address for the router doing the Layer 3
switching. The router and the Catalyst 5000 series switch use
the NDE IP address when sending MLS statistics to a data
collection application.
Multilayer Switching Configuration Examples
In these examples, VLAN interfaces 1 and 3 are in VTP domain named Engineering. The management
interface is configured on the VLAN 1 interface. Only information relevant to MLS is shown in the
following configurations:
•
Router Configuration Without Access Lists Example
•
Router Configuration with a Standard Access List Example
•
Router Configuration with an Extended Access List Example
Router Configuration Without Access Lists Example
This sample configuration shows a router configured without access lists on any of the VLAN interfaces.
The flow mask is configured to be destination-ip.
router# more system:running-config
Building configuration...
Current configuration:
.
.
.
mls rp ip
interface Vlan1
ip address 172.20.26.56 255.255.255.0
mls rp vtp-domain Engineering
mls rp management-interface
mls rp ip
Cisco IOS Switching Services Configuration Guide
XC-269
Configuring IP Multilayer Switching
Multilayer Switching Configuration Examples
interface Vlan2
ip address 172.16.2.73 255.255.255.0
interface Vlan3
ip address 172.16.3.73 255.255.255.0
mls rp vtp-domain Engineering
mls rp ip
.
.
end
router#
router# show mls rp
multilayer switching is globally enabled
mls id is 0006.7c71.8600
mls ip address 172.20.26.56
mls flow mask is destination-ip
number of domains configured for mls 1
vlan domain name: Engineering
current flow mask: destination-ip
current sequence number: 82078006
current/maximum retry count: 0/10
current domain state: no-change
current/next global purge: false/false
current/next purge count: 0/0
domain uptime: 02:54:21
keepalive timer expires in 11 seconds
retry timer not running
change timer not running
1 management interface(s) currently defined:
vlan 1 on Vlan1
2 mac-vlan(s) configured for multi-layer switching:
mac 0006.7c71.8600
vlan id(s)
1
3
router currently aware of following 1 switch(es):
switch id 00e0.fe4a.aeff
Router Configuration with a Standard Access List Example
This configuration is the same as the previous example but with a standard access list configured on the
VLAN 3 interface. The flow mask changes to source-destination-ip.
.
interface Vlan3
ip address 172.16.3.73 255.255.255.0
ip access-group 2 out
mls rp vtp-domain Engineering
mls rp ip
.
router# show mls rp
multilayer switching is globally enabled
mls id is 0006.7c71.8600
mls ip address 172.20.26.56
Cisco IOS Switching Services Configuration Guide
XC-270
Configuring IP Multilayer Switching
Multilayer Switching Configuration Examples
mls flow mask is source-destination-ip
number of domains configured for mls 1
vlan domain name: Engineering
current flow mask: source-destination-ip
current sequence number: 82078007
current/maximum retry count: 0/10
current domain state: no-change
current/next global purge: false/false
current/next purge count: 0/0
domain uptime: 02:57:31
keepalive timer expires in 4 seconds
retry timer not running
change timer not running
1 management interface(s) currently defined:
vlan 1 on Vlan1
2 mac-vlan(s) configured for multi-layer switching:
mac 0006.7c71.8600
vlan id(s)
1
3
router currently aware of following 1 switch(es):
switch id 00e0.fe4a.aeff
Router Configuration with an Extended Access List Example
This configuration is the same as the previous examples but with an extended access list configured on
the VLAN 3 interface. The flow mask changes to ip-flow.
.
interface Vlan3
ip address 172.16.3.73 255.255.255.0
ip access-group 101 out
mls rp vtp-domain Engineering
mls rp ip
.
router# show mls rp
multilayer switching is globally enabled
mls id is 0006.7c71.8600
mls ip address 172.20.26.56
mls flow mask is ip-flow
number of domains configured for mls 1
vlan domain name: Engineering
current flow mask: ip-flow
current sequence number: 82078009
current/maximum retry count: 0/10
current domain state: no-change
current/next global purge: false/false
current/next purge count: 0/0
domain uptime: 03:01:52
keepalive timer expires in 3 seconds
retry timer not running
change timer not running
1 management interface(s) currently defined:
Cisco IOS Switching Services Configuration Guide
XC-271
Configuring IP Multilayer Switching
Multilayer Switching Configuration Examples
vlan 1 on Vlan1
2 mac-vlan(s) configured for multi-layer switching:
mac 0006.7c71.8600
vlan id(s)
1
3
router currently aware of following 1 switch(es):
switch id 00e0.fe4a.aeff
Cisco IOS Switching Services Configuration Guide
XC-272
Configuring IP Multicast Multilayer Switching
This chapter describes how to configure your network to perform IP multicast Multilayer Switching
(MLS). This chapter contains these sections:
•
Prerequisites
•
Restrictions
•
Configuring and Monitoring IP Multicast MLS
•
IP Multicast MLS Configuration Examples
For a complete description of the commands in this chapter, refer to the the Cisco IOS Switching Services
Command Reference. To locate documentation of other commands that appear in this chapter, use the
command reference master index or search online.
To identify the hardware platform or software image information associated with a feature, use the
Feature Navigator on Cisco.com to search for information about the feature or refer to the software
release notes for a specific release. For more information, see the section “Identifying Supported
Platforms” in the chapter “Using Cisco IOS Software.”
Note
The information in this chapter is a brief summary of the information contained in the Catalyst 5000
Series Multilayer Switching User Guide. The commands and configurations described in this guide
apply only to the devices that provide routing services. Commands and configurations for Catalyst
5000 series switches are documented in the Catalyst 5000 Series Multilayer Switching User Guide.
Prerequisites
The following prerequisites are necessary before MLS can function:
•
A VLAN interface must be configured on both the switch and the router. For information on
configuring inter-VLAN routing on the RSM or an external router, refer to the Catalyst 5000
Software Configuration Guide.
•
IP multicast MLS must be configured on the switch. For procedures on this task, refer to the
“Configuring IP Multicast Routing” chapter in the Cisco IOS IP Routing Configuration Guide.
•
IP multicast routing and PIM must be enabled on the router. The minimal steps to configure them
are described in the “Configuring and Monitoring IP Multicast MLS” section later in this document.
For detailed information on configuring IP multicast routing and PIM, refer to the Cisco IOS IP
Routing Configuration Guide.
Cisco IOS Switching Services Configuration Guide
XC-273
Configuring IP Multicast Multilayer Switching
Restrictions
Restrictions
You must also configure the Catalyst 5000 series switch in order for IP multicast MLS to function on the
router.
The restrictions in the following sections apply to IP multicast MLS on the router:
•
Router Configuration Restrictions
•
External Router Guidelines
•
Access List Restrictions and Guidelines
Router Configuration Restrictions
IP multicast MLS does not work on internal or external routers in the following situations:
•
If IP multicast MLS is disabled on the RPF interface for the flow (using the no mls rp ip multicast
interface configuration command).
•
For IP multicast groups that fall into these ranges (where * is in the range from 0 to 255):
– 224.0.0.* through 239.0.0.*
– 224.128.0.* through 239.128.0.*
Note
Groups in the 224.0.0.* range are reserved for routing control packets and must be flooded to all
forwarding ports of the VLAN. These addresses map to the multicast MAC address range
01-00-5E-00-00-xx, where xx is in the range from 0 to 0xFF.
•
For PIM auto-RP multicast groups (IP multicast group addresses 224.0.1.39 and 224.0.1.40).
•
For flows that are forwarded on the multicast shared tree (that is, {*, G, *} forwarding) when the
interface or group is running PIM sparse mode.
•
If the shortest path tree (SPT) bit for the flow is cleared when running PIM sparse mode for the
interface or group.
•
When an input rate limit is applied on an RPF interface.
•
For any RPF interface with access lists applied (for detailed information, see the “Access List
Restrictions and Guidelines” section later in this document).
•
For any RPF interface with multicast boundary configured.
•
For packets that require fragmentation and packets with IP options. However, packets in the flow
that are not fragmented or that do not specify IP options are multilayer switched.
•
On external routers, for source traffic received at the router on non-ISL or non-802.1Q interfaces.
•
For source traffic received on tunnel interfaces (such as MBONE traffic).
•
For any RPF interface with multicast tag switching enabled.
Cisco IOS Switching Services Configuration Guide
XC-274
Configuring IP Multicast Multilayer Switching
Configuring and Monitoring IP Multicast MLS
External Router Guidelines
Follow these guidelines when using an external router:
•
The connection to the external router must be over a single ISL or 802.1Q trunk link with
subinterfaces (using appropriate encapsulation type) configured.
•
A single external router can serve as the MMLS-RP for multiple switches, provided each switch
connects to the router through a separate ISL or 802.1Q trunk link.
•
If the switch connects to a single router through multiple trunk links, IP multicast MLS is supported
on one of the links only. You must disable IP multicast MLS on the redundant links using the no mls
rp ip multicast interface configuration command.
•
You can connect end hosts (source or multicast destination devices) through any media (Ethernet,
Fast Ethernet, ATM, and FDDI), but the connection between external routers and the switch must
be through Fast Ethernet or Gigabit Ethernet interfaces.
Access List Restrictions and Guidelines
The following restrictions apply when using access lists on interfaces participating in IP multicast MLS:
•
All standard access lists are supported on any interface. The flow is multilayer switched on all
interfaces on which the traffic for the flow is allowed by the access list.
•
Layer 4 port-based extended IP input access lists are not supported. For interfaces with these access
lists applied, no flows are multilayer switched.
•
Extended access lists on the RPF interface that specify conditions other than Layer 3 source, Layer 3
destination, and ip protocol are not multilayer switched.
For example, if the following input access list is applied to the RPF interface for a group of flows,
no flows will be multilayer switched even though the second entry permits all IP traffic (because the
protocol specified in the first entry is not ip):
Router(config)# access-list 101 permit udp any any
Router(config)# access-list 101 permit ip any any
If the following input access list is applied to the RPF interface for a group of flows, all flows except
the {s1, g1} flow are multilayer switched (because the protocol specified in the entry for {s1, g1}
is not ip):
Router(config)# access-list 101 permit udp s1 g1
Router(config)# access-list 101 permit ip any any
Configuring and Monitoring IP Multicast MLS
To configure your Cisco router for IP multicast MLS, perform the tasks described in the following
sections. The first two sections contain required tasks; the remaining tasks are optional. To ensure a
successful multicast MLS configuration, you must also configure the Catalyst switches in your network.
For a full description, refer to the Catalyst 5000 Series Multilayer Switching User Guide.
•
Enabling IP Multicast Routing (Required)
•
Enabling IP PIM (Required)
•
Enabling IP Multicast MLS (Optional, this is a required task if you disabled it.)
•
Specifying a Management Interface (Optional)
Cisco IOS Switching Services Configuration Guide
XC-275
Configuring IP Multicast Multilayer Switching
Configuring and Monitoring IP Multicast MLS
For examples of IP multicast MLS configurations, see the “IP Multicast MLS Configuration Examples”
section later in this document.
Enabling IP Multicast Routing
You must enable IP multicast routing globally on the MMLS-RPs before you can enable IP multicast
MLS on router interfaces. To enable IP multicast routing on the router, use the following command in
router configuration mode:
Command
Purpose
Router(config)# ip multicast-routing
Enables IP multicast routing globally.
Note
This section describes only how to enable IP multicast routing on the router. For detailed IP multicast
configuration information, refer to the “Configuring IP Multicast Routing” chapter in the Cisco IOS
IP Routing Configuration Guide.
Enabling IP PIM
You must enable PIM on the router interfaces connected to the switch before IP multicast MLS will
function on those router interfaces. To do so, use the following commands beginning in interface
configuration mode:
Command
Purpose
Step 1
Router(config)# interface type number
Configures an interface.
Step 2
Router(config-if)# ip pim {dense-mode | sparse-mode
| sparse-dense-mode}
Enables PIM on the interface.
Note
This section describes only how to enable PIM on router interfaces. For detailed PIM configuration
information, refer to the “Configuring IP Multicast Routing” chapter in the Cisco IOS IP Routing
Configuration Guide.
Enabling IP Multicast MLS
IP multicast MLS is enabled by default when you enable PIM on the interface. Perform this task only if
you disabled IP multicast MLS and you want to reenable it. To enable IP multicast MLS on an interface,
use the following command in interface configuration mode:
Command
Purpose
Router(config-if)# mls rp ip multicast
Enables IP multicast MLS on an interface.
Cisco IOS Switching Services Configuration Guide
XC-276
Configuring IP Multicast Multilayer Switching
IP Multicast MLS Configuration Examples
Specifying a Management Interface
When you enable IP multicast MLS, the subinterface (or VLAN interface) that has the lowest VLAN ID
and is active (in the “up” state) is automatically selected as the management interface. The one-hop
protocol Multilayer Switching Protocol (MLSP) is used between a router and a switch to pass messages
about hardware-switched flows. MLSP packets are sent and received on the management interface.
Typically, the interface in VLAN 1 is chosen (if that interface exists). Only one management interface
is allowed on a single trunk link.
In most cases, we recommend that the management interface be determined by default. However, you
can optionally specify a different router interface or subinterface as the management interface. We
recommend using a subinterface with minimal data traffic so that multicast MLSP packets can be sent
and received more quickly.
If the user-configured management interface goes down, the router uses the default interface (the active
interface with the lowest VLAN ID) until the user-configured interface comes up again.
To change the default IP multicast MLS management interface, use the following command in interface
configuration mode:
Command
Purpose
Router(config-if)# mls rp ip multicast management-interface
Configures an interface as the IP multicast MLS
management interface.
Monitoring and Maintaining IP Multicast MLS
To monitor and maintain an IP multicast MLS network, use the following commands in EXEC modes,
as needed:
Command
Purpose
Router# show ip mroute [group-name | group-address [source]]
Displays hardware switching state for outgoing
interfaces.
Router# show ip pim interface [type number] [count]
Displays PIM interface information.
Router# show mls rp ip multicast [locate] [group [source]
[vlan-id]] | [statistics] | [summary]
Displays Layer 3 switching information.
IP Multicast MLS Configuration Examples
The following sections contain example IP multicast MLS implementations. These examples include the
switch configurations, although switch commands are not documented in this router publication. Refer
to the Catalyst 5000 Command Reference for that information.
•
Basic IP Multicast MLS Network Examples
•
Complex IP Multicast MLS Network Examples
Cisco IOS Switching Services Configuration Guide
XC-277
Configuring IP Multicast Multilayer Switching
IP Multicast MLS Configuration Examples
Basic IP Multicast MLS Network Examples
This example consists of the following sections:
•
Network Topology Example
•
Operation Before IP Multicast MLS Example
•
Operation After IP Multicast MLS Example
•
Router Configuration
•
Switch Configuration
Network Topology Example
Figure 69 shows a basic IP multicast MLS example network topology.
Figure 69
Example Network: Basic IP Multicast MLS
Router
(MMLS-RP)
D
G1
G1 A
VLAN 30
10.1.30.0/24
VLAN 10
10.1.10.0/24
B
C
G1
VLAN 20
10.1.20.0/24
18501
G1 source
Switch
(MMLS-SE)
Trunk link
VLANs 10, 20, 30
The network is configured as follows:
•
There are three VLANs (IP subnetworks): VLANs 10, 20, and 30.
•
The multicast source for group G1 belongs to VLAN 10.
•
Hosts A, C, and D have joined IP multicast group G1.
•
Port 1/2 on the MMLS-SE is connected to interface fastethernet2/0 on the MMLS-RP.
•
The link between the MMLS-SE and the MMLS-RP is configured as an ISL trunk.
•
The subinterfaces on the router interface have these IP addresses:
– fastethernet2/0.10: 10.1.10.1 255.255.255.0 (VLAN 10)
– fastethernet2/0.20: 10.1.20.1 255.255.255.0 (VLAN 20)
– fastethernet2/0.30: 10.1.30.1 255.255.255.0 (VLAN 30)
Cisco IOS Switching Services Configuration Guide
XC-278
Configuring IP Multicast Multilayer Switching
IP Multicast MLS Configuration Examples
Operation Before IP Multicast MLS Example
Without IP multicast MLS, when the G1 source (on VLAN 10) sends traffic destined for IP multicast
group G1, the switch forwards the traffic (based on the Layer 2 multicast forwarding table entry
generated by the IGMP snooping, CGMP, or GMRP multicast service) to Host A on VLAN 10 and to
the router subinterface in VLAN 10.
The router receives the multicast traffic on its incoming subinterface for VLAN 10, checks the multicast
routing table, and replicates the traffic to the outgoing subinterfaces for VLANs 20 and 30. The switch
receives the traffic on VLANs 20 and 30 and forwards the traffic received on these VLANs to the
appropriate switch ports, again based on the contents of the Layer 2 multicast forwarding table.
Operation After IP Multicast MLS Example
After IP multicast MLS is implemented, when the G1 source sends traffic destined for multicast group
G1, the MMLS-SE checks its Layer 3 multicast MLS cache and recognizes that the traffic belongs to a
multicast MLS flow. The MMLS-SE forwards the traffic to Host A on VLAN 10 based on the multicast
forwarding table, but does not forward the traffic to the router subinterface in VLAN 10 (assuming a
completely switched flow).
For each multicast MLS cache entry, the switch maintains a list of outgoing interfaces for the destination
IP multicast group. The switch replicates the traffic on the appropriate outgoing interfaces (VLANs 20
and 30) and then forwards the traffic on each VLAN to the destination hosts (using the Layer 2 multicast
forwarding table). The switch performs a packet rewrite for the replicated traffic so that the packets
appear to have been routed by the appropriate router subinterface.
If not all the router subinterfaces are eligible to participate in IP multicast MLS, the switch must forward
the multicast traffic to the router subinterface in the source VLAN (in this case, VLAN 10). In this
situation, on those subinterfaces that are ineligible, the router performs multicast forwarding and
replication in software, in the usual manner. On those subinterfaces that are eligible, the switch performs
multilayer switching.
Note
On the MMLS-RP, the IP multicast MLS management interface is user-configured to the VLAN 30
subinterface. If this interface goes down, the system will revert to the default management interface
(in this case, the VLAN 10 subinterface).
Router Configuration
The following is an example configuration of IP multicast MLS on the router:
ip multicast-routing
interface fastethernet2/0.10
encapsulation isl 10
ip address 10.1.10.1 255.255.255.0
ip pim dense-mode
interface fastethernet2/0.20
encapsulation isl 20
ip address 10.1.20.1 255.255.255.0
ip pim dense-mode
interface fastethernet2/0.30
encapsulation isl 30
ip address 10.1.30.1 255.255.255.0
ip pim dense-mode
mls rp ip multicast management-interface
Cisco IOS Switching Services Configuration Guide
XC-279
Configuring IP Multicast Multilayer Switching
IP Multicast MLS Configuration Examples
You will receive the following message informing you that you changed the management interface:
Warning: MLS Multicast management interface is now Fa2/0.30
Switch Configuration
The following example shows how to configure the switch (MMLS-SE):
Console> (enable) set trunk 1/2 on isl
Port(s) 1/2 trunk mode set to on.
Port(s) 1/2 trunk type set to isl.
Console> (enable) set igmp enable
IGMP feature for IP multicast enabled
Console> (enable) set mls multicast enable
Multilayer Switching for Multicast is enabled for this device.
Console> (enable) set mls multicast include 10.1.10.1
Multilayer switching for multicast is enabled for router 10.1.10.1.
Complex IP Multicast MLS Network Examples
This example consists of the following sections:
•
Network Topology Example
•
Operation Before IP Multicast MLS Example
•
Operation After IP Multicast MLS Example
•
Router A (MMLS-RP) Configuration
•
Router B (MMLS-RP) Configuration
•
Switch A (MMLS-SE) Configuration
•
Switch B Configuration
•
Switch C Configuration
Cisco IOS Switching Services Configuration Guide
XC-280
Configuring IP Multicast Multilayer Switching
IP Multicast MLS Configuration Examples
Network Topology Example
Figure 70 shows a more complex IP multicast MLS example network topology.
Complex IP Multicast MLS Example Network
Router A
(MMLS-RP)
VLANs 10, 20
Router B
(MMLS-RP)
ISL trunks
VLANs 10, 30
Switch B
G1 source
A
B
G1
VLAN 10
172.20.10.0/24
Switch C
Switch A
(MMLS-SE)
C
D
E
G1
G1
G1
VLAN 20
172.20.20.0/24
F
VLAN 30
172.20.30.0/24
18955
Figure 70
The network is configured as follows:
•
There are four VLANs (IP subnetworks): VLANs 1, 10, 20, and 30 (VLAN 1 is used only for
management traffic, not multicast data traffic).
•
The G1 multicast source belongs to VLAN 10.
•
Hosts A, C, D, and E have joined IP multicast group G1.
•
Switch A is the MMLS-SE.
•
Router A and Router B are both operating as MMLS-RPs.
•
Port 1/1 on the MMLS-SE is connected to interface fastethernet1/0 on Router A.
•
Port 1/2 on the MMLS-SE is connected to interface fastethernet2/0 on Router B.
•
The MMLS-SE is connected to the MMLS-RPs through ISL trunk links.
•
The trunk link to Router A carries VLANs 1, 10, and 20.
•
The trunk link to Router B carries VLANs 1, 10, and 30.
•
The subinterfaces on the Router A interface have these IP addresses:
– fastethernet1/0.1: 172.20.1.1 255.255.255.0 (VLAN 1)
– fastethernet1/0.10: 172.20.10.1 255.255.255.0 (VLAN 10)
– fastethernet1/0.20: 172.20.20.1 255.255.255.0 (VLAN 20)
•
The subinterfaces on the Router B interface have these IP addresses:
– fastethernet1/0.1: 172.20.1.2 255.255.255.0 (VLAN 1)
– fastethernet2/0.10: 172.20.10.100 255.255.255.0 (VLAN 10)
– fastethernet2/0.30: 172.20.30.100 255.255.255.0 (VLAN 30)
Cisco IOS Switching Services Configuration Guide
XC-281
Configuring IP Multicast Multilayer Switching
IP Multicast MLS Configuration Examples
•
The default IP multicast MLS management interface is used on both MMLS-RPs (VLAN 1).
•
Port 1/3 on the MMLS-SE is connected to Switch B through an ISL trunk link carrying all VLANs.
•
Port 1/4 on the MMLS-SE is connected to Switch C through an ISL trunk link carrying all VLANs.
•
Switch B and Switch C perform Layer 2 switching functions only.
Operation Before IP Multicast MLS Example
Without IP multicast MLS, when Server A (on VLAN 10) sends traffic destined for IP multicast group
G1, Switch B forwards the traffic (based on the Layer 2 multicast forwarding table entry) to Host A on
VLAN 10 and to Switch A. Switch A forwards the traffic to the Router A and Router B subinterfaces in
VLAN 10.
Router A receives the multicast traffic on its incoming subinterface for VLAN 10, checks the multicast
routing table, and replicates the traffic to the outgoing subinterface for VLAN 20. Router B receives the
multicast traffic on its incoming interface for VLAN 10, checks the multicast routing table, and
replicates the traffic to the outgoing subinterface for VLAN 30.
Switch A receives the traffic on VLANs 20 and 30. Switch A forwards VLAN 20 traffic to the
appropriate switch ports (in this case, to Host C), based on the contents of the Layer 2 multicast
forwarding table. Switch A forwards the VLAN 30 traffic to Switch C.
Switch C receives the VLAN 30 traffic and forwards it to the appropriate switch ports (in this case,
Hosts D and E) using the multicast forwarding table.
Operation After IP Multicast MLS Example
After IP multicast MLS is implemented, when Server A sends traffic destined for multicast group G1,
Switch B forwards the traffic (based on the Layer 2 multicast forwarding table entry) to Host A on
VLAN 10 and to Switch A.
Switch A checks its Layer 3 multicast MLS cache and recognizes that the traffic belongs to a multicast
MLS flow. Switch A does not forward the traffic to the router subinterfaces in VLAN 10 (assuming a
completely switched flow). Instead, Switch A replicates the traffic on the appropriate outgoing
interfaces (VLANs 20 and 30).
VLAN 20 traffic is forwarded to Host C and VLAN 30 traffic is forwarded to Switch C (based on the
contents of the Layer 2 multicast forwarding table). The switch performs a packet rewrite for the
replicated traffic so that the packets appear to have been routed by the appropriate router subinterface.
Switch C receives the VLAN 30 traffic and forwards it to the appropriate switch ports (in this case,
Hosts D and E) using the multicast forwarding table.
If not all the router subinterfaces are eligible to participate in IP multicast MLS, the switch must forward
the multicast traffic to the router subinterfaces in the source VLAN (in this case, VLAN 10). In this
situation, on those subinterfaces that are ineligible, the routers perform multicast forwarding and
replication in software in the usual manner. On those subinterfaces that are eligible, the switch performs
multilayer switching.
Note
On both MMLS-RPs, no user-configured IP multicast MLS management interface is specified.
Therefore, the VLAN 1 subinterface is used by default.
Cisco IOS Switching Services Configuration Guide
XC-282
Configuring IP Multicast Multilayer Switching
IP Multicast MLS Configuration Examples
Router A (MMLS-RP) Configuration
ip multicast-routing
interface fastethernet1/0.1
encapsulation isl 1
ip address 172.20.1.1 255.255.255.0
interface fastethernet1/0.10
encapsulation isl 10
ip address 172.20.10.1 255.255.255.0
ip pim dense-mode
interface fastethernet1/0.20
encapsulation isl 20
ip address 172.20.20.1 255.255.255.0
ip pim dense-mode
Router B (MMLS-RP) Configuration
ip multicast-routing
interface fastethernet1/0.1
encapsulation isl 1
ip address 172.20.1.2 255.255.255.0
interface fastethernet2/0.10
encapsulation isl 10
ip address 172.20.10.100 255.255.255.0
ip pim dense-mode
interface fastethernet2/0.30
encapsulation isl 30
ip address 172.20.30.100 255.255.255.0
ip pim dense-mode
Switch A (MMLS-SE) Configuration
Console> (enable) set vlan 10
Vlan 10 configuration successful
Console> (enable) set vlan 20
Vlan 20 configuration successful
Console> (enable) set vlan 30
Vlan 30 configuration successful
Console> (enable) set trunk 1/1 on isl
Port(s) 1/1 trunk mode set to on.
Port(s) 1/1 trunk type set to isl.
Console> (enable) set trunk 1/2 on isl
Port(s) 1/2 trunk mode set to on.
Port(s) 1/2 trunk type set to isl.
Console> (enable) set trunk 1/3 desirable isl
Port(s) 1/3 trunk mode set to desirable.
Port(s) 1/3 trunk type set to isl.
Console> (enable) set trunk 1/4 desirable isl
Port(s) 1/4 trunk mode set to desirable.
Port(s) 1/4 trunk type set to isl.
Console> (enable) set igmp enable
IGMP feature for IP multicast enabled
Console> (enable) set mls multicast enable
Multilayer Switching for Multicast is enabled for this device.
Console> (enable) set mls multicast include 172.20.10.1
Multilayer switching for multicast is enabled for router 172.20.10.1.
Console> (enable) set mls multicast include 172.20.10.100
Multilayer switching for multicast is enabled for router 172.20.10.100.
Console> (enable)
Cisco IOS Switching Services Configuration Guide
XC-283
Configuring IP Multicast Multilayer Switching
IP Multicast MLS Configuration Examples
Switch B Configuration
The following example shows how to configure Switch B assuming VLAN Trunking Protocol (VTP) is
used for VLAN management:
Console> (enable) set igmp enable
IGMP feature for IP multicast enabled
Console> (enable)
Switch C Configuration
The following example shows how to configure Switch C assuming VTP is used for VLAN management:
Console> (enable) set igmp enable
IGMP feature for IP multicast enabled
Console> (enable)
Cisco IOS Switching Services Configuration Guide
XC-284
Configuring IPX Multilayer Switching
This chapter describes how to configure your network to perform IPX Multilayer Switching (MLS). This
chapter contains these sections:
•
Prerequisites
•
Restrictions
•
IPX MLS Configuration Task List
•
Troubleshooting Tips
•
Monitoring and Maintaining IPX MLS on the Router
•
IPX MLS Configuration Examples
For a complete description of the commands in this chapter, refer to the the Cisco IOS Switching Services
Command Reference. To locate documentation of other commands that appear in this chapter, use the
command reference master index or search online.
To identify the hardware platform or software image information associated with a feature, use the
Feature Navigator on Cisco.com to search for information about the feature or refer to the software
release notes for a specific release. For more information, see the section “Identifying Supported
Platforms” in the chapter “Using Cisco IOS Software.”
Note
The information in this chapter is a brief summary of the information contained in the Catalyst 5000
Series Multilayer Switching User Guide. The commands and configurations described in this guide
apply only to the devices that provide routing services. Commands and configurations for Catalyst
5000 series switches are documented in the Catalyst 5000 Series Multilayer Switching User Guide.
Prerequisites
The following prerequisites must be met before IPX MLS can function:
•
A VLAN interface must be configured on both the switch and the router. For information on
configuring inter-VLAN routing on the RSM or external router, refer to the Catalyst 5000 Software
Configuration Guide, Release 5.1.
•
IPX MLS must be configured on the switch. For more information refer to the Catalyst 5000
Software Configuration Guide, Release 5.1 and the Catalyst 5000 Command Reference, Release 5.1.
IPX MLS must be enabled on the router. The minimal configuration steps are described in the section
“IPX MLS Configuration Tasks.” For more details on configuring IPX routing, refer to the Cisco IOS
AppleTalk and Novell IPX Configuration Guide.
Cisco IOS Switching Services Configuration Guide
XC-285
Configuring IPX Multilayer Switching
Restrictions
Restrictions
This section describes restrictions that apply to configuring IPX MLS on the router.
General Configuration Guidelines
Be aware of the following restrictions:
•
You must configure the Catalyst 5000 series switch for IPX MLS to work.
•
When you enable IPX MLS, the RSM or externally attached router continues to handle all non-IPX
protocols, while offloading the switching of IPX packets to the MLS-SE.
•
Do not confuse IPX MLS with NetFlow switching supported by Cisco routers. IPX MLS requires
both the RSM or directly attached external router and the MLS-SE, but not NetFlow switching on
the RSM or directly attached external router. Any switching path on the RSM or directly attached
external router will function (process, fast, optimum, and so on).
External Router Guidelines
When using an external router, use the following guidelines:
•
Use one directly attached external router per switch to ensure that the MLS-SE caches the
appropriate flow information from both sides of the routed flow.
•
Use Cisco high-end routers (Cisco 4500, 4700, 7200, and 7500 series) for IPX MLS when they are
externally attached to the switch. Make the attachment with multiple Ethernet connections (one per
subnet) or by using Fast or Gigabit Ethernet with Inter-Switch Link (ISL) or IEEE 802.1Q
encapsulation.
•
Connect end hosts through any media (Ethernet, Fast Ethernet, ATM, and FDDI), but connect the
external router and the switch only through standard 10/100 Ethernet interfaces, ISL, or IEEE
802.1Q links.
Access List Restrictions
The following restrictions apply when you use access lists on interfaces that participate in IPX MLS:
•
Input access lists—Router interfaces with input access lists cannot participate in IPX MLS. If you
configure an input access list on an interface, no packets inbound or outbound for that interface are
Layer 3 switched, even if the flow is not filtered by the access list. Existing flows for that interface
are purged, and no new flows are cached.
Note
You can translate input access lists to output access lists to provide the same effect on
the interface.
Cisco IOS Switching Services Configuration Guide
XC-286
Configuring IPX Multilayer Switching
IPX MLS Configuration Task List
•
Output access lists—When an output access list is applied to an interface, the IPX MLS cache
entries for that interface are purged. Entries associated with other interfaces are not affected; they
follow their normal aging or purging procedures.
Applying access lists that filter according to packet type, source node, source socket, or destination
socket prevents the interface from participating in IPX MLS.
Applying access lists that use the log option prevents the interface from participating in IPX MLS.
•
Access list impact on flow masks—Access lists impact the flow mask mode advertised to the
MLS-SE by an MLS-RP. If no access list has been applied on any MLS-RP interface, the flow mask
mode is destination-ipx (the least specific) by default. If an access list that filters according to the
source IPX network has been applied, the mode is source-destination-ipx by default.
Restrictions on Interaction of IPX MLS with Other Features
IPX MLS affects other Cisco IOS software features as follows:
•
IPX accounting—IPX accounting cannot be enabled on an IPX MLS-enabled interface.
•
IPX EIGRP—MLS is supported for EIGRP interfaces if the Transport Control (TC) maximum is set
to a value greater than the default (16).
Restriction on Maximum Transmission Unit Size
In IPX the two endpoints of communication negotiate the maximum transmission unit (MTU) to be used.
MTU size is limited by media type.
IPX MLS Configuration Task List
To configure one or more routers for IPX MLS, perform the tasks described in the following sections.
The number of tasks you perform depends on your particular configuration.
•
Adding an IPX MLS Interface to a VTP Domain (Optional)
•
Enabling Multilayer Switching Protocol (MLSP) on the Router (Required)
•
Assigning a VLAN ID to a Router Interface (Optional)
•
Enabling IPX MLS on a Router Interface (Required)
•
Specifying a Router Interface As a Management Interface (Required)
For examples of IPX MLS configurations, see the “IPX MLS Configuration Examples” section later in
this document.
Cisco IOS Switching Services Configuration Guide
XC-287
Configuring IPX Multilayer Switching
IPX MLS Configuration Task List
Adding an IPX MLS Interface to a VTP Domain
Caution
Perform this configuration task only if the switch connected to your router interfaces is in a VTP
domain. Perform the task before you enter any other IPX MLS interface command—specifically the
mls rp ipx or mls rp management-interface command. If you enter these commands before adding
the interface to a VTP domain, the interface will be automatically placed in a null domain. To place
the IPX MLS interface into a domain other than the null domain, clear the IPX MLS interface
configuration before you add the interface to another VTP domain. Refer to the section
“Configuration, Verification, and Troubleshooting Tips” and the Catalyst 5000 Software
Configuration Guide, Release 5.1.
Determine which router interfaces you will use as IPX MLS interfaces and add them to the same VTP
domain as the switches.
To view the VTP configuration and its domain name on the switch, enter the show mls rp vtp-domain
EXEC command at the switch Console> prompt.
To assign an MLS interface to a specific VTP domain on the MLS-RP, use the following command in
interface configuration mode:
Command
Purpose
Router(config-if)# mls rp vtp-domain domain-name
Adds an IPX MLS interface to a VTP domain.
Enabling Multilayer Switching Protocol (MLSP) on the Router
To enable MLSP on the router, use the following command in global configuration mode:
Command
Purpose
Router(config)# mls rp ipx
Globally enables MLSP on the router. MLSP is the
protocol that runs between the MLS-SE and
MLS-RP.
Assigning a VLAN ID to a Router Interface
Note
This task is not required for RSM VLAN interfaces (virtual interfaces), ISL-encapsulated interfaces,
or IEEE 802.1Q-encapsulated interfaces.
Cisco IOS Switching Services Configuration Guide
XC-288
Configuring IPX Multilayer Switching
IPX MLS Configuration Task List
To assign a VLAN ID to an IPX MLS interface, use the following command in interface configuration
mode:
Command
Purpose
Router(config-if)# mls rp vlan-id vlan-id-number
Assigns a VLAN ID to an IPX MLS interface.
The assigned IPX MLS interface must be either an
Ethernet or Fast Ethernet interface with no
subinterfaces.
Enabling IPX MLS on a Router Interface
To enable IPX MLS on a router interface, use the following command in interface configuration mode:
Command
Purpose
Router(config-if)# mls rp ipx
Enables a router interface for IPX MLS.
Specifying a Router Interface As a Management Interface
To specify an interface as the management interface, use the following command in interface
configuration mode:
Command
Purpose
Router(config-if)# mls rp management-interface
Specifies an interface as the management interface.
MLSP packets are sent and received through the
management interface. Select only one IPX MLS
interface connected to the switch.
Verifying IPX MLS on the Router
To verify that you have correctly installed IPX MLS on the router, perform the following steps:
Step 1
Enter the show mls rp ipx EXEC command.
Step 2
Examine the output to learn if the VLANs are enabled.
Step 3
Examine the output to learn if the switches are listed by MAC address, indicating they are recognized
by the MLS-RP.
Cisco IOS Switching Services Configuration Guide
XC-289
Configuring IPX Multilayer Switching
Troubleshooting Tips
Troubleshooting Tips
If you entered either the mls rp ipx interface command or the mls rp management-interface interface
command on the interface before assigning it to a VTP domain, the interface will be in the null domain,
instead of the VTP domain.
To remove the interface from the null domain and add it to a new VTP domain, use the following
commands in interface configuration mode:
Command
Purpose
Step 1
Router(config-if)# no mls rp ipx
Router(config-if)# no mls rp management-interface
Router(config-if)# no mls rp vtp-domain domain-name
Removes an interface from the null domain.
Step 2
Router(config-if)# mls rp vtp-domain domain-name
Adds the interface to a new VTP domain.
Monitoring and Maintaining IPX MLS on the Router
To monitor and maintain IPX MLS on the router, use the following command in EXEC mode, as needed:
Command
Purpose
Router# mls rp locate ipx
Displays information about all switches currently
shortcutting for the specified IPX flow(s).
Router# show mls rp interface type number
Displays MLS details for a specific interface.
Router# show mls rp ipx
Displays details for all IPX MLS interfaces on the
router:
Router#
show mls rp vtp-domain domain-name
•
MLS status (enabled or disabled) for switch
interfaces and subinterfaces.
•
Flow mask required when creating Layer 3
switching entries for the router.
•
Current settings for the keepalive timer, retry
timer, and retry count.
•
MLSP-ID used in MLSP messages.
•
List of interfaces in all VTP domains enabled
for MLS.
Displays details about IPX MLS interfaces for a
specific VTP domain.
IPX MLS Configuration Examples
This section provides a complex IPX MLS network example: the Cisco 7505 switch over ISL. The
example includes router and switch configurations, even though switch commands are not documented
in this router publication. The section also includes sample configurations with no access lists and with
standard access lists. Refer to the Catalyst 5000 Command Reference, Release 5.1 for more information.
Cisco IOS Switching Services Configuration Guide
XC-290
Configuring IPX Multilayer Switching
IPX MLS Configuration Examples
Complex IPX MLS Network Examples
This example consists of the following sections:
•
IPX MLS Network Topology Example
•
Operation Before IPX MLS Example
•
Operation After IPX MLS Example
•
Switch A Configuration
•
Switch B Configuration
•
Switch C Configuration
•
MLS-RP Configuration
•
Router with No Access Lists Configuration
•
Configuring a Router with a Standard Access List Example
IPX MLS Network Topology Example
Figure 71 shows an IPX MLS network topology consisting of three Catalyst 5000 series switches and a
Cisco 7505 router—all interconnected with ISL trunk links.
Figure 71
Example Network: IPX MLS with Cisco 7505 over ISL
Cisco 7505
(MLS-RP)
Subinterfaces:
fa2/0.1 IPX network 1
fa2/0.10 IPX network 10
fa2/0.20 IPX network 20
fa2/0.30 IPX network 30
fa2/0
ISL
Trunk link
Catalyst 5509
Catalyst 5505
with NFFC
(Switch B)
(Switch A, MLS-SE) 1/1
Catalyst 5505
(Switch C)
Novell client
NC2
4/1
Novell client
NC1
1/2
1/1
ISL
Trunk link
1/3
3/1
1/1
ISL
Trunk link
3/1
Novell server
NS2
VLAN 10
IPX network 10
Novell server
NS1
23261
3/1
VLAN 30
IPX network 30
VLAN 20
IPX network 20
Cisco IOS Switching Services Configuration Guide
XC-291
Configuring IPX Multilayer Switching
IPX MLS Configuration Examples
The network is configured as follows:
•
There are four VLANs (IPX networks):
– VLAN 1 (management VLAN), IPX network 1
– VLAN 10, IPX network 10
– VLAN 20, IPX network 20
– VLAN 30, IPX network 30
•
The MLS-RP is a Cisco 7505 router with a Fast Ethernet interface (interface fastethernet2/0)
•
The subinterfaces on the router interface have the following IPX network addresses:
– fastethernet2/0.1–IPX network 1
– fastethernet2/0.10–IPX network 10
– fastethernet2/0.20–IPX network 20
– fastethernet2/0.30–IPX network 30
•
Switch A, the MLS-SE VTP server, is a Catalyst 5509 switch with Supervisor Engine III and the
NFFC II.
•
Switch B and Switch C are VTP client Catalyst 5505 switches.
Operation Before IPX MLS Example
Before IPX MLS is implemented, when the source host NC1 (on VLAN 10) sends traffic destined for
destination server NS2 (on VLAN 30), Switch B forwards the traffic (based on the Layer 2 forwarding
table) to Switch A over the ISL trunk link. Switch A forwards the packet to the router over the ISL trunk
link.
The router receives the packet on the VLAN 10 subinterface, checks the destination IPX address, and
routes the packet to the VLAN 30 subinterface. Switch A receives the routed packet and forwards it to
Switch C. Switch C receives the packet and forwards it to destination server NS2. This process is
repeated for each packet in the flow between source host NC1 and destination server NS2.
Operation After IPX MLS Example
After IPX MLS is implemented, when the source host NC1 (on VLAN 10) sends traffic destined for
destination server NS2 (on VLAN 30), Switch B forwards the traffic (based on the Layer 2 forwarding
table) to Switch A (the MLS-SE) over the ISL trunk link. When the first packet enters Switch A, a
candidate flow entry is established in the MLS cache. Switch A forwards the packet to the MLS-RP over
the ISL trunk link.
The MLS-RP receives the packet on the VLAN 10 subinterface, checks the destination IPX address, and
routes the packet to the VLAN 30 subinterface. Switch A receives the routed packet (the enabler packet)
and completes the flow entry in the MLS cache for the destination IPX address of NS2. Switch A
forwards the packet to Switch C, where it is forwarded to destination server NS2.
Subsequent packets destined for the IPX address of NS2 are multilayer switched by the MLS-SE based
on the flow entry in the MLS cache. For example, subsequent packets in the flow from source host NC1
are forwarded by Switch B to Switch A (the MLS-SE). The MLS-SE determines that the packets are part
of the established flow, rewrites the packet headers, and switches the packets directly to Switch C,
bypassing the router.
Cisco IOS Switching Services Configuration Guide
XC-292
Configuring IPX Multilayer Switching
IPX MLS Configuration Examples
Switch A Configuration
This example shows how to configure Switch A (MLS-SE):
SwitchA> (enable) set vtp domain Corporate mode server
VTP domain Corporate modified
SwitchA> (enable) set vlan 10
Vlan 10 configuration successful
SwitchA> (enable) set vlan 20
Vlan 20 configuration successful
SwitchA> (enable) set vlan 30
Vlan 30 configuration successful
SwitchA> (enable) set port name 1/1 Router Link
Port 1/1 name set.
SwitchA> (enable) set trunk 1/1 on isl
Port(s) 1/1 trunk mode set to on.
Port(s) 1/1 trunk type set to isl.
SwitchA> (enable) set port name 1/2 SwitchB Link
Port 1/2 name set.
SwitchA> (enable) set trunk 1/2 desirable isl
Port(s) 1/2 trunk mode set to desirable.
Port(s) 1/2 trunk type set to isl.
SwitchA> (enable) set port name 1/3 SwitchC Link
Port 1/3 name set.
SwitchA> (enable) set trunk 1/3 desirable isl
Port(s) 1/3 trunk mode set to desirable.
Port(s) 1/3 trunk type set to isl.
SwitchA> (enable) set mls enable ipx
IPX Multilayer switching is enabled.
SwitchA> (enable) set mls include ipx 10.1.1.1
IPX Multilayer switching enabled for router 10.1.1.1.
SwitchA> (enable) set port name 3/1 Destination D2
Port 3/1 name set.
SwitchA> (enable) set vlan 20 3/1
VLAN 20 modified.
VLAN 1 modified.
VLAN Mod/Ports
---- ----------------------20
3/1
SwitchA> (enable)
Switch B Configuration
This example shows how to configure Switch B:
SwitchB> (enable) set port name 1/1 SwitchA Link
Port 1/1 name set.
SwitchB> (enable) set port name 3/1 Source S1
Port 3/1 name set.
SwitchB> (enable) set vlan 10 3/1
VLAN 10 modified.
VLAN 1 modified.
VLAN Mod/Ports
---- ----------------------10
3/1
SwitchB> (enable)
Cisco IOS Switching Services Configuration Guide
XC-293
Configuring IPX Multilayer Switching
IPX MLS Configuration Examples
Switch C Configuration
This example shows how to configure Switch C:
SwitchC> (enable) set port name 1/1 SwitchA Link
Port 1/1 name set.
SwitchC> (enable) set port name 3/1 Destination D1
Port 3/1 name set.
SwitchC> (enable) set vlan 30 3/1
VLAN 30 modified.
VLAN 1 modified.
VLAN Mod/Ports
---- ----------------------30
3/1
SwitchC> (enable) set port name 4/1 Source S2
Port 4/1 name set.
SwitchC> (enable) set vlan 30 4/1
VLAN 30 modified.
VLAN 1 modified.
VLAN Mod/Ports
---- ----------------------30
3/1
4/1
SwitchC> (enable)
MLS-RP Configuration
This example shows how to configure the MLS-RP:
mls rp ipx
interface fastethernet 2/0
full-duplex
mls rp vtp-domain Engineering
interface fastethernet2/0.1
encapsulation isl 1
ipx address 10.1.1.1 255.255.255.0
mls rp ipx
mls rp management-interface
interface fastethernet2/0.10
encapsulation isl 10
ipx network 10
mls rp ipx
interface fastethernet2/0.20
encapsulation isl 20
ipx network 20
mls rp ipx
interface fastethernet2/0.30
encapsulation isl 30
ipx network 30
mls rp ipx
Cisco IOS Switching Services Configuration Guide
XC-294
Configuring IPX Multilayer Switching
IPX MLS Configuration Examples
Router with No Access Lists Configuration
This example shows how to configure the RSM VLAN interfaces with no access lists. Therefore, the
flow mask mode is destination.
Building configuration...
Current configuration:
!
version 12.0
.
.
.
ipx routing 0010.0738.2917
mls rp ip
mls rp ipx
.
.
.
interface Vlan21
ip address 10.5.5.155 255.255.255.0
ipx network 2121
mls rp vtp-domain Engineering
mls rp management-interface
mls rp ip
mls rp ipx
!
interface Vlan22
ip address 10.2.2.155 255.255.255.0
ipx network 2222
mls rp vtp-domain Engineering
mls rp ip
mls rp ipx
!
.
.
.
end
Configuring a Router with a Standard Access List Example
This example shows how to configure a standard access list on the RSM VLAN 3 interface. Therefore,
the flow mask mode is destination-source.
Router# show run
Building configuration...
Current configuration:
!
version 12.0
!
interface Vlan22
ip address 10.2.2.155 255.255.255.0
ipx access-group 800 out
ipx network 2222
mls rp vtp-domain Engineering
mls rp ip
mls rp ipx
!
.
Cisco IOS Switching Services Configuration Guide
XC-295
Configuring IPX Multilayer Switching
IPX MLS Configuration Examples
.
.
!
!
!
access-list 800 deny 1111 2222
access-list 800 permit FFFFFFFF FFFFFFFF
.
.
.
end
Cisco IOS Switching Services Configuration Guide
XC-296
Multicast Distributed Switching
Configuring Multicast Distributed Switching
This chapter describes the required and optional tasks for configuring Multicast Distributed Switching
(MDS).
For a complete description of the commands in this chapter, refer to the the Cisco IOS Switching Services
Command Reference. To locate documentation of other commands that appear in this chapter, use the
command reference master index or search online.
To identify the hardware platform or software image information associated with a feature, use the
Feature Navigator on Cisco.com to search for information about the feature or refer to the software
release notes for a specific release. For more information, see the section “Identifying Supported
Platforms” in the chapter “Using Cisco IOS Software.”
Prior to multicast distributed switching, IP multicast traffic was always switched at the Route Processor
(RP) in the Route Switch Processor (RSP)-based platforms. Starting with Cisco IOS Release 11.2 GS,
IP multicast traffic can be distributed switched on RSP-based platforms with VIPs. Furthermore, MDS
is the only multicast switching method on the Cisco 12000 Gigabit Switch Router (GSR), starting with
Cisco IOS Release 11.2(11)GS.
Switching multicast traffic at the RP had the following disadvantages:
•
The load on the RP increased. This affected important route updates and calculations (for BGP,
among others) and could stall the router if the multicast load was substantial.
•
The net multicast performance was limited to what a single RP could switch.
MDS solves these problems by performing distributed switching of multicast packets received at the line
cards (VIPs in the case of RSP, and line cards in the case of GSR). The line card is the interface card that
houses the VIPs (in the case of RSP) and the GSR line card (in the case of GSR). MDS is accomplished
using a forwarding data structure called a Multicast Forwarding Information Base (MFIB), which is a
subset of the routing table. A copy of MFIB runs on each line card and is always kept up to date with the
MFIB table of the RP.
In the case of RSP, packets received on non-VIP IPs are switched by the RP.
MDS can work in conjunction with Cisco Express Forwarding (CEF), unicast distributed fast switching
(DFS), or flow switching.
Cisco IOS Switching Services Configuration Guide
XC-298
Configuring Multicast Distributed Switching
MDS Configuration Task List
MDS Configuration Task List
To configure MDS, perform the task described in the following sections. The first section contains a
required task; the remaining task is optional:
•
Enabling MDS (Required)
•
Monitoring and Maintaining MDS (Optional)
Enabling MDS
To enable MDS, you must enable it globally and on at least one interface because MDS is an attribute of
the interface. Use the following commands beginning in global configuration mode:
Command
Purpose
Step 1
Router(config)# ip multicast-routing
distributed
Enables MDS globally.
Step 2
Router(config)# interface type number
Configures an interface.
Step 3
Router(config-if)# ip route-cache distributed
Enables distributed switching on the RSP. (This step is
required on the RSP platform only.)
Step 4
Router(config-if)# ip mroute-cache distributed
Enables MDS on the interface.
Repeat Steps 2 through 4 for each interface that you
want to perform MDS.
Note
When you enable an interface to perform distributed switching of incoming multicast packets, you
are configuring the physical interface, not the logical interface (subinterface). All subinterfaces are
included in the physical interface.
Monitoring and Maintaining MDS
To maintain MDS on the line cards, use the following command in EXEC mode:
Command
Purpose
Router# clear ip mds forwarding
Clears the MFIB table of the line card and resynchronizes
with the RP.
To maintain MDS on the RP, use the following commands in EXEC mode, as needed:
Command
Purpose
Router# clear ip mroute {* | group [source]}
Clears multicast routes and counts.
Router# clear ip pim interface count
Clears all packet counts on the line cards.
Cisco IOS Switching Services Configuration Guide
XC-299
Configuring Multicast Distributed Switching
MDS Configuration Example
To monitor MDS on the line cards, use the following commands in EXEC mode, as needed. Remember
that to reach a line card’s console, enter the attach slot# command, using the slot number where the line
card resides.
Command
Purpose
Router# show ip mds forwarding [group-address]
[source-address]
Displays the MFIB table, forwarding information, related
flags, and counts.
Router# show ip mds summary
Displays a summary of the MFIB.
To monitor MDS on the RP, use the following commands in EXEC mode, as needed:
Command
Purpose
Router# show ip mds stats [switching | linecard]
Displays switching statistics or line card statistics for MDS.
Router# show ip mds interface
Displays the status of MDS interfaces.
Router# show ip pim interface [type number] count
Displays switching counts for unicast distributed fast
switching and other fast switching statistics.
Router# show ip mcache [group [source]]
Displays the contents of the IP fast-switching cache.
Router# show interface stats
Displays numbers of packets that were process switched,
fast switched, and distributed switched.
MDS Configuration Example
The following example enables MDS. The ip route-cache distributed interface configuration command
is needed on the RSP only, not on the GSR.
ip multicast-routing distributed
interface pos 1/0/0
ip route-cache distributed
ip mroute-cache distributed
Cisco IOS Switching Services Configuration Guide
XC-300
VLANs
Routing Between VLANs Overview
This chapter provides an overview of VLANs. It describes the encapsulation protocols used for routing
between VLANs and provides some basic information about designing VLANs.
This chapter describes VLANs. It contains the following sections:
•
What Is a VLAN?
•
VLAN Colors
•
Why Implement VLANs?
•
Communicating Between VLANs
•
VLAN Interoperability
•
Designing Switched VLANs
What Is a VLAN?
A VLAN is a switched network that is logically segmented on an organizational basis, by functions,
project teams, or applications rather than on a physical or geographical basis. For example, all
workstations and servers used by a particular workgroup team can be connected to the same VLAN,
regardless of their physical connections to the network or the fact that they might be intermingled with
other teams. Reconfiguration of the network can be done through software rather than by physically
unplugging and moving devices or wires.
A VLAN can be thought of as a broadcast domain that exists within a defined set of switches. A VLAN
consists of a number of end systems, either hosts or network equipment (such as bridges and routers),
connected by a single bridging domain. The bridging domain is supported on various pieces of network
equipment; for example, LAN switches that operate bridging protocols between them with a separate
bridge group for each VLAN.
VLANs are created to provide the segmentation services traditionally provided by routers in LAN
configurations. VLANs address scalability, security, and network management. Routers in VLAN
topologies provide broadcast filtering, security, address summarization, and traffic flow management.
None of the switches within the defined group will bridge any frames, not even broadcast frames,
between two VLANs. Several key issues described in the following sections need to be considered when
designing and building switched LAN internetworks:
•
LAN Segmentation
•
Security
•
Broadcast Control
Cisco IOS Switching Services Configuration Guide
XC-302
Routing Between VLANs Overview
What Is a VLAN?
•
Performance
•
Network Management
•
Communication Between VLANs
LAN Segmentation
VLANs allow logical network topologies to overlay the physical switched infrastructure such that any
arbitrary collection of LAN ports can be combined into an autonomous user group or community of
interest. The technology logically segments the network into separate Layer 2 broadcast domains
whereby packets are switched between ports designated to be within the same VLAN. By containing
traffic originating on a particular LAN only to other LANs in the same VLAN, switched virtual networks
avoid wasting bandwidth, a drawback inherent to traditional bridged and switched networks in which
packets are often forwarded to LANs with no need for them. Implementation of VLANs also improves
scalability, particularly in LAN environments that support broadcast- or multicast-intensive protocols
and applications that flood packets throughout the network.
Figure 72 illustrates the difference between traditional physical LAN segmentation and logical VLAN
segmentation.
Figure 72
LAN Segmentation and VLAN Segmentation
Traditional LAN segmentation
VLAN segmentation
VLAN 1
VLAN 2
VLAN 3
LAN 1
Catalyst
VLAN switch
Shared hub
Floor 3
LAN 2
Catalyst
VLAN switch
Shared hub
Floor 2
LAN 3
Shared hub
Floor 1
Catalyst
VLAN switch
S6619
Router
Cisco IOS Switching Services Configuration Guide
XC-303
Routing Between VLANs Overview
What Is a VLAN?
Security
VLANs improve security by isolating groups. High-security users can be grouped into a VLAN, possibly
on the same physical segment, and no users outside that VLAN can communicate with them.
Broadcast Control
Just as switches isolate collision domains for attached hosts and only forward appropriate traffic out a
particular port, VLANs provide complete isolation between VLANs. A VLAN is a bridging domain, and
all broadcast and multicast traffic is contained within it.
Performance
The logical grouping of users allows an accounting group to make intensive use of a networked
accounting system assigned to a VLAN that contains just that accounting group and its servers.
That group’s work will not affect other users. The VLAN configuration improves general network
performance by not slowing down other users sharing the network.
Network Management
The logical grouping of users allows easier network management. It is not necessary to pull cables to
move a user from one network to another. Adds, moves, and changes are achieved by configuring a port
into the appropriate VLAN.
Network Monitoring Using SNMP
SNMP support has been added to provide mib-2 interfaces sparse table support for Fast Ethernet
subinterfaces. Monitor your VLAN subinterface using the show vlans EXEC command. For more
information on configuring SNMP on your Cisco network device or enabling an SNMP agent for remote
access, refer to the “Configuring SNMP” chapter in the Cisco IOS Configuration Fundamentals
Configuration Guide.
Communication Between VLANs
Communication between VLANs is accomplished through routing, and the traditional security and
filtering functions of the router can be used. Cisco IOS software provides network services such as
security filtering, quality of service (QoS), and accounting on a per-VLAN basis. As switched networks
evolve to distributed VLANs, Cisco IOS software provides key inter-VLAN communications and allows
the network to scale.
Before Cisco IOS Release 12.2, Cisco IOS support for interfaces that have 802.1Q encapsulation
configured is IP, IP multicast, and IPX routing between respective VLANs represented as subinterfaces
on a link. New functionality has been added in IEEE 802.1Q support for bridging on those interfaces and
the capability to configure and use integrated routing and bridging (IRB).
The following section describes how bridging communication between IEEE 802.1Q VLANs occurs:
•
Relaying Function
Cisco IOS Switching Services Configuration Guide
XC-304
Routing Between VLANs Overview
What Is a VLAN?
•
Native VLAN
•
PVST+
•
Integrated Routing and Bridging
Relaying Function
The relaying function level, as displayed in Figure 73, is the lowest level in the architectural model
described in the IEEE 802.1Q standard and presents three types of rules:
•
Ingress rules—Rules relevant to the classification of received frames belonging to a VLAN.
•
Forwarding rules between ports—Decides to filter or forward the frame.
•
Egress rules (output of frames from the switch)—Decides if the frame must be sent tagged or
untagged.
Figure 73
Relaying Function
Port state
information
Forwarding
process
Port state
information
Ingress
rules
Filtering
database
Egress
rules
Frame
transmission
54713
Frame
reception
The Tagging Scheme
Figure 74 shows the tagging scheme proposed by the 802.3ac standard, that is, the addition of the four
octets after the source MAC address. Their presence is indicated by a particular value of the EtherType
field (called TPID), which has been fixed to be equal to 0x8100. When a frame has the EtherType equal
to 0x8100, this frame carries the tag IEEE 802.1Q/802.1p. The tag is stored in the following two octets
and it contains 3 bits of user priority, 1 bit of Canonical Format Identifier (CFI), and 12 bits of VLAN
ID (VID). The 3 bits of user priority are used by the 802.1p standard; the CFI is used for compatibility
Cisco IOS Switching Services Configuration Guide
XC-305
Routing Between VLANs Overview
What Is a VLAN?
reasons between Ethernet-type networks and Token Ring-type networks. The VID is the identification
of the VLAN, which is basically used by the 802.1Q standard; being on 12 bits, it allows the
identification of 4096 VLANs.
After the two octets of TPID and the two octets of the Tag Control Information field there are two octets
that originally would have been located after the Source Address field where there is the TPID. They
contain either the MAC length in the case of IEEE 802.3 or the EtherType in the case of Ethernet
version 2.
Figure 74
Tagging Scheme
User
priority
6
Destination address
6
Source address
2
EtherType = 0x8100
2
Tag control information
2
MAC length/type
CFI
VID (VLAN ID) - 12 bits
Data
Variable
4
54712
PAD
FCS
The EtherType and VLAN ID are inserted after the MAC source address, but before the original
Ethertype/Length or Logical Link Control (LLC). The 1-bit CFI included a T-R Encapsulation bit so that
Token Ring frames can be carried across Ethernet backbones without using 802.1H translation.
Adding a Tag Recomputes the Frame Control Sequence
Figure 75 shows how adding a tag in a frame recomputes the Frame Control Sequence. 802.1p and
802.1Q share the same tag.
Dest
Src
Dest
Src
PRI
Adding a Tag Recomputes the Frame Control Sequence
Len/Etype
Etype
Data
Tag
FCS
Len/Etype
VLAN ID
Token ring encapsulation flag
Cisco IOS Switching Services Configuration Guide
XC-306
Original
frame
Data
FCS
(VLAN ID and
TR encapsulations
are 802.1Q,
not 802.1p)
Tagged
frame
54711
Figure 75
Routing Between VLANs Overview
What Is a VLAN?
Native VLAN
Each physical port has a parameter called PVID. Every 802.1Q port is assigned a PVID value that is of
its native VLAN ID (default is VLAN 1). All untagged frames are assigned to the LAN specified in the
PVID parameter. When a tagged frame is received by a port, the tag is respected. If the frame is untagged,
the value contained in the PVID is considered as a tag. Because the frame is untagged and the PVID is
tagged to allow the coexistence, as shown in Figure 76, on the same pieces of cable of VLAN-aware
bridge/stations and of VLAN-unaware bridges/stations. Consider, for example, the two stations
connected to the central trunk link in the lower part of Figure 76. They are VLAN-unaware and they will
be associated to the VLAN C, because the PVIDs of the VLAN-aware bridges are equal to VLAN C.
Because the VLAN-unaware stations will send only untagged frames, when the VLAN-aware bridge
devices receive these untagged frames they will assign them to VLAN C.
Figure 76
Native VLAN
VLAN A
VLAN A
PVID = A
VLAN-aware
bridge
VLAN-aware
bridge
Access
ports
PVID = C
VLAN B
PVID = C
Access
ports
PVID = C
PVID = B
PVID = A
PVID = B
VLAN B
Trunk
link
VLAN C
VLAN-unaware
end station
VLAN-unaware
end station
VLAN-unaware
end station
VLAN B
VLAN-aware
end station
54710
PVID = C
VLAN C
PVST+
PVST+ provides support for 802.1Q trunks and the mapping of multiple spanning trees to the single
spanning tree of 802.1Q switches.
The PVST+ architecture distinguishes three types of regions:
•
A PVST region
•
A PVST+ region
•
A MST region
Each region consists of a homogenous type of switch. A PVST region can be connected to a PVST+
region by connecting two ISL ports. Similarly, a PVST+ region can be connected to an MST region by
connecting two 802.1Q ports.
Cisco IOS Switching Services Configuration Guide
XC-307
Routing Between VLANs Overview
What Is a VLAN?
At the boundary between a PVST region and a PVST+ region the mapping of spanning trees is
one-to-one. At the boundary between a MST region and a PVST+ region, the ST in the MST region maps
to one PVST in the PVST+ region. The one it maps to is called the common spanning tree (CST). The
default CST is the PVST of VLAN 1 (Native VLAN).
All PVSTs, except for the CST, are tunneled through the MST region. Tunneling means that bridge
protocol data units (BPDUs) are flooded through the MST region along the single spanning tree present
in the MST region.
Note
When a Dot1q VLAN is configured on an interface, a default VLAN 1 is automatically created to
process the CST. The default VLAN 1 created is only used for processing spanning tree BPDU
packets. Even though these packets are Dot1q untagged, no other untagged data packet will be
processed by this VLAN 1. Instead, all of the untagged data packet will be processed by the explicitly
defined Native VLAN. If, however, no Native VLAN is defined, VLAN 1 will become the default the
Native VLAN 1 (it can also be explicitly defined as Native VLAN 1) to handle all the untagged
packets, including CST BPDUs and data packets.
Ingress and Egress Rules
The BPDU transmission on the 802.1Q port of a PVST+ router will be implemented in compliance with
the following rules:
•
The CST BPDU (of VLAN 1, by default) is sent to the IEEE address.
•
All the other BPDUs are sent to Shared Spanning Tree Protocol (SSTP)-Address and encapsulated
with Logical Link Control-Subnetwork Access Protocol (LLC-SNAP) header.
•
The BPDU of the CST and BPDU of the VLAN equal to the PVID of the 802.1Q trunk are sent
untagged.
•
All other BPDUs are sent tagged with the VLAN ID.
•
The CST BPDU is also sent to the SSTP address.
•
Each SSTP-addressed BPDU is also tailed by a Tag-Length-Value for the PVID checking.
The BPDU reception on the 802.1Q port of a PVST+ router will follow these rules:
•
All untagged IEEE addressed BPDUs must be received on the PVID of the 802.1Q port.
•
The IEEE addressed BPDUs whose VLAN ID matches the Native VLAN are processed by CST.
•
All the other IEEE addressed BPDUs whose VLAN ID does not match the Native VLAN and whose
port type is not of 802.1Q are processed by the spanning tree of that particular VLAN ID.
•
The SSTP addressed BPDU whose VLAN ID is not equal to the TLV are dropped and the ports are
blocked for inconsistency.
•
All the other SSTP addressed BPDUs whose VLAN ID is not equal to the Native VLAN are
processed by the spanning tree of that particular VLAN ID.
•
The SSTP addressed BPDUs whose VLAN ID is equal to the Native VLAN are dropped. It is used
for consistency checking.
Integrated Routing and Bridging
IRB enables a user to route a given protocol between routed interfaces and bridge groups or route a given
protocol between the bridge groups. Integrated routing and bridging is supported on the following
protocols:
Cisco IOS Switching Services Configuration Guide
XC-308
Routing Between VLANs Overview
VLAN Colors
•
IP
•
IPX
•
AppleTalk
VLAN Colors
VLAN switching is accomplished through frame tagging where traffic originating and contained within
a particular virtual topology carries a unique VLAN ID as it traverses a common backbone or trunk link.
The VLAN ID enables VLAN switching devices to make intelligent forwarding decisions based on the
embedded VLAN ID. Each VLAN is differentiated by a color, or VLAN identifier. The unique VLAN
ID determines the frame coloring for the VLAN. Packets originating and contained within a particular
VLAN carry the identifier that uniquely defines that VLAN (by the VLAN ID).
The VLAN ID allows VLAN switches and routers to selectively forward packets to ports with the same
VLAN ID. The switch that receives the frame from the source station inserts the VLAN ID and the
packet is switched onto the shared backbone network. When the frame exits the switched LAN, a switch
strips the header and forwards the frame to interfaces that match the VLAN color. If you are using a
Cisco network management product such as VlanDirector, you can actually color code the VLANs and
monitor VLAN graphically.
Why Implement VLANs?
Network managers can logically group networks that span all major topologies, including high-speed
technologies such as, ATM, FDDI, and Fast Ethernet. By creating virtual LANs, system and network
administrators can control traffic patterns and react quickly to relocations and keep up with constant
changes in the network due to moving requirements and node relocation just by changing the VLAN
member list in the router configuration. They can add, remove, or move devices or make other changes
to network configuration using software to make the changes.
Issues regarding benefits of creating VLANs should have been addressed when you developed your
network design. Issues to consider include the following:
•
Scalability
•
Performance improvements
•
Security
•
Network additions, moves, and changes
Communicating Between VLANs
Cisco IOS software provides full-feature routing at Layer 3 and translation at Layer 2 between VLANs.
Five different protocols are available for routing between VLANs:
•
Inter-Switch Link Protocol
•
IEEE 802.10 Protocol
•
IEEE 802.1Q Protocol
•
ATM LANE Protocol
•
ATM LANE Fast Simple Server Replication Protocol
Cisco IOS Switching Services Configuration Guide
XC-309
Routing Between VLANs Overview
Communicating Between VLANs
All five of these technologies are based on OSI Layer 2 bridge multiplexing mechanisms.
Inter-Switch Link Protocol
The Inter-Switch Link (ISL) protocol is used to interconnect two VLAN-capable Ethernet, Fast Ethernet,
or Gigabit Ethernet devices, such as the Catalyst 3000 or 5000 switches and Cisco 7500 routers. The ISL
protocol is a packet-tagging protocol that contains a standard Ethernet frame and the VLAN information
associated with that frame. The packets on the ISL link contain a standard Ethernet, FDDI, or Token Ring
frame and the VLAN information associated with that frame. ISL is currently supported only over Fast
Ethernet links, but a single ISL link, or trunk, can carry different protocols from multiple VLANs.
Procedures for configuring ISL and Token Ring ISL (TRISL) features are provided in the “Configuring
Routing Between VLANs with Inter-Switch Link Encapsulation” chapter later in this publication.
IEEE 802.10 Protocol
The IEEE 802.10 protocol provides connectivity between VLANs. Originally developed to address the
growing need for security within shared LAN/MAN environments, it incorporates authentication and
encryption techniques to ensure data confidentiality and integrity throughout the network. Additionally,
by functioning at Layer 2, it is well suited to high-throughput, low-latency switching environments. The
IEEE 802.10 protocol can run over any LAN or HDLC serial interface.
Procedures for configuring routing between VLANs with IEEE 802.10 encapsulation are provided in the
“Configuring Routing Between VLANs with IEEE 802.10 Encapsulation” chapter later in this
publication.
IEEE 802.1Q Protocol
The IEEE 802.1Q protocol is used to interconnect multiple switches and routers, and for defining VLAN
topologies. Cisco currently supports IEEE 802.1Q for Fast Ethernet and Gigabit Ethernet interfaces.
Note
Cisco does not support IEEE 802.1Q encapsulation for Ethernet interfaces.
Procedures for configuring routing between VLANs with IEEE 802.1Q encapsulation are provided in
the “Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation” chapter later in this
publication.
ATM LANE Protocol
The ATM LAN Emulation (LANE) protocol provides a way for legacy LAN users to take advantage of
ATM benefits without requiring modifications to end-station hardware or software. LANE emulates a
broadcast environment like IEEE 802.3 Ethernet on top of an ATM network that is a point-to-point
environment.
LANE makes ATM function like a LAN. LANE allows standard LAN drivers like NDIS and ODI to be
used. The virtual LAN is transparent to applications. Applications can use normal LAN functions
without the underlying complexities of the ATM implementation. For example, a station can send
broadcasts and multicasts, even though ATM is defined as a point-to-point technology and does not
support any-to-any services.
Cisco IOS Switching Services Configuration Guide
XC-310
Routing Between VLANs Overview
VLAN Interoperability
To accomplish this, special low-level software is implemented on an ATM client workstation, called the
LAN Emulation Client (LEC). The client software communicates with a central control point called a
LAN Emulation Server (LES). A broadcast and unknown server (BUS) acts as a central point to
distribute broadcasts and multicasts. The LAN Emulation Configuration Server (LECS) holds a database
of LECs and the ELANs they belong to. The database is maintained by a network administrator.
These protocols are described in detail in the Cisco Internetworking Design Guide.
ATM LANE Fast Simple Server Replication Protocol
To improve the ATM LANE Simple Server Replication Protocol (SSRP), Cisco introduced the ATM
LANE Fast Simple Server Replication Protocol (FSSRP). FSSRP differs from LANE SSRP in that all
configured LANE servers of an ELAN are always active. FSSRP-enabled LANE clients have virtual
circuits (VCs) established to a maximum of four LANE servers and BUSs at one time. If a single LANE
server goes down, the LANE client quickly switches over to the next LANE server and BUS, resulting
in no data or LE ARP table entry loss and no extraneous signalling.
The FSSRP feature improves upon SSRP such that LANE server and BUS switchover for LANE clients
is immediate. With SSRP, a LANE server would go down, and depending on the network load, it may
have taken considerable time for the LANE client to come back up joined to the correct LANE server
and BUS. In addition to going down with SSRP, the LANE client would do the following:
•
Clear out its data direct VCs
•
Clear out its LE ARP entries
•
Cause substantial signalling activity and data loss
FSSRP was designed to alleviate these problems with the LANE client. With FSSRP, each LANE client
is simultaneously joined to up to four LANE servers and BUSs. The concept of the master LANE server
and BUS is maintained; the LANE client uses the master LANE server when it needs LANE server BUS
services. However, the difference between SSRP and FSSRP is that if and when the master LANE server
goes down, the LANE client is already connected to multiple backup LANE servers and BUSs. The
LANE client simply uses the next backup LANE server and BUS as the master LANE server and BUS.
VLAN Interoperability
Cisco IOS features bring added benefits to the VLAN technology. Enhancements to ISL, IEEE 802.10,
and ATM LANE implementations enable routing of all major protocols between VLANs. These
enhancements allow users to create more robust networks incorporating VLAN configurations by
providing communications capabilities between VLANs.
Inter-VLAN Communications
The Cisco IOS supports full routing of several protocols over ISL and ATM LANE VLANs. IP, Novell
IPX, and AppleTalk routing are supported over IEEE 802.10 VLANs. Standard routing attributes such
as network advertisements, secondaries, and help addresses are applicable, and VLAN routing is fast
switched. Table 42 shows protocols supported for each VLAN encapsulation format and corresponding
Cisco IOS software releases.
Cisco IOS Switching Services Configuration Guide
XC-311
Routing Between VLANs Overview
Designing Switched VLANs
Table 42
Inter-VLAN Routing Protocol Support
Protocol
ISL
ATM LANE
IEEE 802.10
IP
Release 11.1
Release 10.3
Release 11.1
Novell IPX (default
encapsulation)
Release 11.1
Release 10.3
Release 11.1
Novell IPX (configurable
encapsulation)
Release 11.3
Release 10.3
Release 11.3
AppleTalk Phase II
Release 11.3
Release 10.3
—
DECnet
Release 11.3
Release 11.0
—
Banyan VINES
Release 11.3
Release 11.2
—
XNS
Release 11.3
Release 11.2
—
CLNS
Release 12.1
—
—
IS-IS
Release 12.1
—
—
VLAN Translation
VLAN translation refers to the ability of the Cisco IOS software to translate between different VLANs
or between VLAN and non-VLAN encapsulating interfaces at Layer 2. Translation is typically used for
selective inter-VLAN switching of nonroutable protocols and to extend a single VLAN topology across
hybrid switching environments. It is also possible to bridge VLANs on the main interface; the VLAN
encapsulating header is preserved. Topology changes in one VLAN domain do not affect a different
VLAN.
Designing Switched VLANs
By the time you are ready to configure routing between VLANs, you will have already defined them
through the switches in your network. Issues related to network design and VLAN definition should be
addressed during your network design. Refer to the Cisco Internetworking Design Guide and appropriate
switch documentation for information on these topics:
•
Sharing resources between VLANs
•
Load balancing
•
Redundant links
•
Addressing
•
Segmenting networks with VLANs—Segmenting the network into broadcast groups improves
network security. Use router access lists based on station addresses, application types, and protocol
types.
•
Routers and their role in switched networks—In switched networks, routers perform broadcast
management, route processing, and distribution, and provide communication between VLANs.
Routers provide VLAN access to shared resources and connect to other parts of the network that are
either logically segmented with the more traditional subnet approach or require access to remote
sites across wide-area links.
Cisco IOS Switching Services Configuration Guide
XC-312
Configuring Routing Between VLANs with
Inter-Switch Link Encapsulation
This chapter describes the Inter-Switch Link (ISL) protocol and provides guidelines for configuring ISL
and Token Ring ISL (TRISL) features.
For a complete description of the commands in this chapter, refer to the the Cisco IOS Switching Services
Command Reference. To locate documentation of other commands that appear in this chapter, use the
command reference master index or search online.
To identify the hardware platform or software image information associated with a feature, use the
Feature Navigator on Cisco.com to search for information about the feature or refer to the software
release notes for a specific release. For more information, see the section “Identifying Supported
Platforms” in the chapter “Using Cisco IOS Software.”
Overview of the ISL Protocol
ISL is a Cisco protocol for interconnecting multiple switches and maintaining VLAN information as
traffic goes between switches. ISL provides VLAN capabilities while maintaining full wire speed
performance on Fast Ethernet links in full- or half-duplex mode. ISL operates in a point-to-point
environment and will support up to 1000 VLANs. You can define virtually as many logical networks as
are necessary for your environment.
This chapter describes how to configure routing between VLANs using ISL encapsulation.
Frame Tagging in ISL
With ISL, an Ethernet frame is encapsulated with a header that transports VLAN IDs between switches
and routers. A 26-byte header that contains a 10-bit VLAN ID is prepended to the Ethernet frame.
A VLAN ID is added to the frame only when the frame is destined for a nonlocal network. Figure 77
shows VLAN packets traversing the shared backbone. Each VLAN packet carries the VLAN ID within
the packet header.
Cisco IOS Switching Services Configuration Guide
XC-313
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Task List
Figure 77
VLAN Packets Traversing the Shared Backbone
Green
Green
Fast Ethernet
Token
Ring
Red
Green
Blue
Blue
Red
Red
Token
Ring
S6621
Blue
ISL Encapsulation Configuration Task List
You can configure routing between any number of VLANs in your network. This section documents the
configuration tasks for each protocol supported with ISL encapsulation. The basic process is the same,
regardless of the protocol being routed. It involves the following tasks:
•
Enabling the protocol on the router
•
Enabling the protocol on the interface
•
Defining the encapsulation format as ISL or TRISL
•
Customizing the protocol according to the requirements for your environment
To configure routing between any number of VLANs in your network, perform the tasks described in the
following sections particular to your network:
•
Configuring AppleTalk Routing over ISL
•
Configuring Banyan VINES Routing over ISL
•
Configuring DECnet Routing over ISL
•
Configuring the Hot Standby Router Protocol over ISL
•
Configuring IP Routing over TRISL
•
Configuring IPX Routing over TRISL
•
Configuring VIP Distributed Switching over ISL
•
Configuring XNS Routing over ISL
•
Configuring CLNS Routing over ISL
•
Configuring IS-IS Routing over ISL
•
Monitoring and Maintaining VLAN Subinterfaces
Refer to the “ISL Encapsulation Configuration Examples” section at the end of this chapter for sample
configurations.
Configuring AppleTalk Routing over ISL
AppleTalk can be routed over VLAN subinterfaces using the ISL and IEEE 802.10 VLAN
encapsulation protocols. The AppleTalk Routing over ISL and IEEE 802.10 Virtual LANs feature
provides full-feature Cisco IOS software AppleTalk support on a per-VLAN basis, allowing standard
AppleTalk capabilities to be configured on VLANs.
Cisco IOS Switching Services Configuration Guide
XC-314
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Task List
To route AppleTalk over ISL or IEEE 802.10 between VLANs, you need to customize the subinterface
to create the environment in which it will be used. Perform the tasks described in the following sections
in the order in which they appear:
•
Enabling AppleTalk Routing
•
Defining the VLAN Encapsulation Format
•
Configuring AppleTalk on the Subinterface
Enabling AppleTalk Routing
To enable AppleTalk routing on either ISL or 802.10 interfaces, use the following command in global
configuration mode:
Command
Purpose
Router(config)# appletalk routing [eigrp
router-number]
Enables AppleTalk routing globally.
Defining the VLAN Encapsulation Format
To define the VLAN encapsulation format as either ISL or 802.10, use the following commands in
interface configuration mode:
Command
Purpose
Step 1
Router(config-if)# interface type
slot/port.subinterface-number
Specifies the subinterface the VLAN will use.
Step 2
Router(config-if)# encapsulation isl
vlan-identifier
Defines the encapsulation format as either ISL (isl) or
IEEE 802.10 (sde), and specifies the VLAN identifier or
security association identifier, respectively.
or
Router(config-if)# encapsulation sde said
Configuring AppleTalk on the Subinterface
After you enable AppleTalk globally and define the encapsulation format, you need to enable it on the
subinterface by specifying the cable range and naming the AppleTalk zone for each interface. To enable
the AppleTalk protocol on the subinterface, use the following commands in interface configuration
mode:
Command
Purpose
Router(config-if)# appletalk cable-range cable-range
[network.node]
Assigns the AppleTalk cable range and zone for the
subinterface.
Router(config-if)# appletalk zone zone-name
Assigns the AppleTalk zone for the subinterface.
Cisco IOS Switching Services Configuration Guide
XC-315
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Task List
Configuring Banyan VINES Routing over ISL
Banyan VINES can be routed over VLAN subinterfaces using the ISL encapsulation protocol. The
Banyan VINES Routing over ISL Virtual LANs feature provides full-feature Cisco IOS software Banyan
VINES support on a per-VLAN basis, allowing standard Banyan VINES capabilities to be configured
on VLANs.
To route Banyan VINES over ISL between VLANs, you need to configure ISL encapsulation on the
subinterface. Perform the tasks described in the following sections in the order in which they appear:
•
Enabling Banyan VINES Routing
•
Defining the VLAN Encapsulation Format
•
Configuring Banyan VINES on the Subinterface
Enabling Banyan VINES Routing
To begin the VINES routing configuration, use the following command in global configuration mode:
Command
Purpose
Router(config)# vines routing [address]
Enables Banyan VINES routing globally.
Defining the VLAN Encapsulation Format
To define the VINES routing encapsulation format, use the following commands in interface
configuration mode:
Command
Purpose
Step 1
Router(config-if)# interface type
slot/port.subinterface-number
Specifies the subinterface on which ISL will be used.
Step 2
Router(config-if)# encapsulation isl
vlan-identifier
Defines the encapsulation format as ISL (isl), and
specifies the VLAN identifier.
Configuring Banyan VINES on the Subinterface
After you enable Banyan VINES globally and define the encapsulation format, you need to enable
VINES on the subinterface by specifying the VINES routing metric. To enable the Banyan VINES
protocol on the subinterface, use the following command in interface configuration mode:
Command
Purpose
Router(config-if)# vines metric [whole [fractional]]
Enables VINES routing on an interface.
Configuring DECnet Routing over ISL
DECnet can be routed over VLAN subinterfaces using the ISL VLAN encapsulation protocols. The
DECnet Routing over ISL Virtual LANs feature provides full-feature Cisco IOS software DECnet
support on a per-VLAN basis, allowing standard DECnet capabilities to be configured on VLANs.
Cisco IOS Switching Services Configuration Guide
XC-316
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Task List
To route DECnet over ISL VLANs, you need to configure ISL encapsulation on the subinterface.
Perform the tasks described in the following sections in the order in which they appear.
•
Enabling DECnet Routing
•
Defining the VLAN Encapsulation Format
•
Configuring DECnet on the Subinterface
Enabling DECnet Routing
To begin the DECnet routing configuration, use the following command in global configuration mode:
Command
Purpose
Router(config)# decnet [network-number] routing
[decnet-address]
Enables DECnet on the router.
Defining the VLAN Encapsulation Format
To define the encapsulation format, use the following commands in interface configuration mode:
Command
Purpose
Step 1
Router(config-if)# interface type
slot/port.subinterface-number
Specifies the subinterface on which ISL will be used.
Step 2
Router(config-if)# encapsulation isl
vlan-identifier
Defines the encapsulation format as ISL (isl), and specifies
the VLAN identifier.
Configuring DECnet on the Subinterface
To configure DECnet routing on the subinterface, use the following command in interface configuration
mode:
Command
Purpose
Router(config-if)# decnet cost [cost-value]
Enables DECnet routing on an interface.
Configuring the Hot Standby Router Protocol over ISL
The Hot Standby Router Protocol (HSRP) provides fault tolerance and enhanced routing performance
for IP networks. HSRP allows Cisco IOS routers to monitor each other’s operational status and very
quickly assume packet forwarding responsibility in the event the current forwarding device in the HSRP
group fails or is taken down for maintenance. The standby mechanism remains transparent to the
attached hosts and can be deployed on any LAN type. With multiple Hot Standby groups, routers can
simultaneously provide redundant backup and perform loadsharing across different IP subnets.
Cisco IOS Switching Services Configuration Guide
XC-317
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Task List
Figure 78 illustrates HSRP in use with ISL providing routing between several VLANs.
Figure 78
Hot Standby Router Protocol in VLAN Configurations
Cisco IOS
router
Cisco IOS
router
HSRP
ISL
ISL
ISL
Cisco VLAN
switch
VLAN 10
VLAN 30
VLAN 20
VLAN 10
VLAN 40
S6620
VLAN 20
Cisco VLAN
switch
A separate HSRP group is configured for each VLAN subnet so that Cisco IOS router A can be the
primary and forwarding router for VLANs 10 and 20. At the same time, it acts as backup for VLANs 30
and 40. Conversely, Router B acts as the primary and forwarding router for ISL VLANs 30 and 40, as
well as the secondary and backup router for distributed VLAN subnets 10 and 20.
Running HSRP over ISL allows users to configure redundancy between multiple routers that are
configured as front ends for VLAN IP subnets. By configuring HSRP over ISLs, users can eliminate
situations in which a single point of failure causes traffic interruptions. This feature inherently provides
some improvement in overall networking resilience by providing load balancing and redundancy
capabilities between subnets and VLANs.
To configure HSRP over ISLs between VLANs, you need to create the environment in which it will be
used. Perform the tasks described in the following sections in the order in which they appear.
•
Defining the Encapsulation Format
•
Defining the IP Address
•
Enabling HSRP
Cisco IOS Switching Services Configuration Guide
XC-318
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Task List
Defining the Encapsulation Format
To define the encapsulation format as ISL, use the following commands in interface configuration mode:
Command
Purpose
Step 1
Router(config-if)# interface type
slot/port.subinterface-number
Specifies the subinterface on which ISL will be used.
Step 2
Router(config-if)# encapsulation isl
vlan-identifier
Defines the encapsulation format, and specifies the VLAN
identifier.
Defining the IP Address
After you have specified the encapsulation format, to define the IP address over which HSRP will be
routed, use the following command in interface configuration mode:
Command
Purpose
Router(config-if)# ip address ip-address mask [secondary]
Specifies the IP address for the subnet on which ISL
will be used.
Enabling HSRP
To enable HSRP on an interface, enable the protocol, then customize it for the interface. Use the
following command in interface configuration mode:
Command
Purpose
Router(config-if)# standby [group-number] ip [ip-address
[secondary]]
Enables HSRP.
Note
For more information on HSRP, see the “Configuring IP Services” chapter in the Cisco IOS IP
Configuration Guide.
To customize Hot Standby group attributes, use the following commands in interface configuration
mode, as needed:
Command
Purpose
Router(config-if)# standby [group-number] timers hellotime
holdtime
Configures the time between hello packets and the
hold time before other routers declare the active router
to be down.
Router(config-if)# standby [group-number] priority priority
Sets the Hot Standby priority used to choose the active
router.
Router(config-if)# standby [group-number] preempt
Specifies that if the local router has priority over the
current active router, the local router should attempt to
take its place as the active router.
Cisco IOS Switching Services Configuration Guide
XC-319
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Task List
Command
Purpose
Router(config-if)# standby [group-number] track type-number
[interface-priority]
Configures the interface to track other interfaces, so
that if one of the other interfaces goes down, the Hot
Standby priority for the device is lowered.
Router(config-if)# standby [group-number] authentication
string
Selects an authentication string to be carried in all
HSRP messages.
Configuring IP Routing over TRISL
The IP routing over TRISL VLANs feature extends IP routing capabilities to include support for routing
IP frame types in VLAN configurations.
Enabling IP Routing
IP routing is automatically enabled in the Cisco IOS software for routers. To reenable IP routing if it has
been disabled, use the following command in global configuration mode:
Command
Purpose
Router(config)# ip routing
Enables IP routing on the router.
Once you have IP routing enabled on the router, you can customize the characteristics to suit your
environment. If necessary, refer to the IP configuration chapters in the Cisco IOS IP Routing
Configuration Guide for guidelines on configuring IP.
Defining the VLAN Encapsulation Format
To define the encapsulation format as TRISL, use the following commands in interface configuration
mode:
Command
Purpose
Step 1
Router(config-if)# interface type
slot/port.subinterface-number
Specifies the subinterface on which TRISL will be
used.
Step 2
Router(config-if)# encapsulation tr-isl trbrf-vlan
vlanid bridge-num bridge-number
Defines the encapsulation for TRISL.
The DRiP database is automatically enabled when TRISL encapsulation is configured, and at least one
TrBRF is defined, and the interface is configured for SRB or for routing with RIF.
Cisco IOS Switching Services Configuration Guide
XC-320
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Task List
Assigning IP Address to Network Interface
An interface can have one primary IP address. To assign a primary IP address and a network mask to a
network interface, use the following command in interface configuration mode:
Command
Purpose
Router(config-if)# ip address ip-address mask
Sets a primary IP address for an interface.
A mask identifies the bits that denote the network number in an IP address. When you use the mask to
subnet a network, the mask is then referred to as a subnet mask.
Note
TRISL encapsulation must be specified for a subinterface before an IP address can be assigned to that
subinterface.
Configuring IPX Routing on 802.10 VLANs over ISL
The IPX Encapsulation for 802.10 VLAN feature provides configurable IPX (Novell-FDDI, SAP,
SNAP) encapsulation over 802.10 VLAN on router FDDI interfaces to connect the Catalyst 5000 VLAN
switch. This feature extends Novell NetWare routing capabilities to include support for routing all
standard IPX encapsulations for Ethernet frame types in VLAN configurations. Users with Novell
NetWare environments can now configure any one of the three IPX Ethernet encapsulations to be routed
using Secure Data Exchange (SDE) encapsulation across VLAN boundaries. IPX encapsulation options
now supported for VLAN traffic include the following:
•
Novell-FDDI (IPX FDDI RAW to 802.10 on FDDI)
•
SAP (IEEE 802.2 SAP to 802.10 on FDDI)
•
SNAP (IEEE 802.2 SNAP to 802.10 on FDDI)
NetWare users can now configure consolidated VLAN routing over a single VLAN trunking
FDDI interface. Not all IPX encapsulations are currently supported for SDE VLAN. The IPX interior
encapsulation support can be achieved by messaging the IPX header before encapsulating in the SDE
format. Fast switching will also support all IPX interior encapsulations on non-MCI platforms (for
example non-AGS+ and non-7000). With configurable Ethernet encapsulation protocols, users have the
flexibility of using VLANs regardless of their NetWare Ethernet encapsulation. Configuring Novell IPX
encapsulations on a per-VLAN basis facilitates migration between versions of Netware. NetWare traffic
can now be routed across VLAN boundaries with standard encapsulation options (arpa, sap, and snap)
previously unavailable. Encapsulation types and corresponding framing types are described in the
“Configuring Novell IPX” chapter of the Cisco IOS AppleTalk and Novell IPX Configuration Guide.
Note
Only one type of IPX encapsulation can be configured per VLAN (subinterface). The IPX
encapsulation used must be the same within any particular subnet; a single encapsulation must be
used by all NetWare systems that belong to the same VLAN.
Cisco IOS Switching Services Configuration Guide
XC-321
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Task List
To configure Cisco IOS software on a router with connected VLANs to exchange different IPX framing
protocols, perform the tasks described in the following sections in the order in which they are appear:
•
Enabling NetWare Routing
•
Defining the VLAN Encapsulation Format
•
Configuring NetWare on the Subinterface
Enabling NetWare Routing
To enable IPX routing on SDE interfaces, use the following command in global configuration mode:
Command
Purpose
Router(config)# ipx routing [node]
Enables IPX routing globally.
Defining the VLAN Encapsulation Format
To define the encapsulation format as SDE, use the following commands in interface configuration
mode:
Command
Purpose
Step 1
Router(config)# interface fddi slot/port.subinterface-number
Specifies the subinterface on which
SDE will be used.
Step 2
Router(config-if)# encapsulation sde vlan-identifier
Defines the encapsulation format and
specifies the VLAN identifier.
Configuring NetWare on the Subinterface
After you enable NetWare globally and define the VLAN encapsulation format, to enable the
subinterface by specifying the NetWare network number (if necessary) and the encapsulation type,
use the following command in interface configuration mode:
Command
Purpose
Router(config-if)# ipx network network encapsulation encapsulation-type
Specifies the IPX encapsulation among
Novell-FDDI, SAP, or SNAP.
Configuring IPX Routing over TRISL
The IPX Routing over ISL VLANs feature extends Novell NetWare routing capabilities to include
support for routing all standard IPX encapsulations for Ethernet frame types in VLAN configurations.
Users with Novell NetWare environments can configure either SAP or SNAP encapsulations to be routed
using the TRISL encapsulation across VLAN boundaries. The SAP (Novell Ethernet_802.2) IPX
encapsulation is supported for VLAN traffic.
NetWare users can now configure consolidated VLAN routing over a single VLAN trunking interface.
With configurable Ethernet encapsulation protocols, users have the flexibility of using VLANs
regardless of their NetWare Ethernet encapsulation. Configuring Novell IPX encapsulations on a
Cisco IOS Switching Services Configuration Guide
XC-322
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Task List
per-VLAN basis facilitates migration between versions of Netware. NetWare traffic can now be routed
across VLAN boundaries with standard encapsulation options (sap and snap) previously unavailable.
Encapsulation types and corresponding framing types are described in the “Configuring Novell IPX”
chapter of the Cisco IOS AppleTalk and Novell IPX Configuration Guide.
Note
Only one type of IPX encapsulation can be configured per VLAN (subinterface). The IPX
encapsulation used must be the same within any particular subnet: A single encapsulation must be
used by all NetWare systems that belong to the same LANs.
To configure Cisco IOS software to exchange different IPX framing protocols on a router with connected
VLANs, perform the tasks described in the following sections in the order in which they are appear:
•
Enabling NetWare Routing
•
Defining the VLAN Encapsulation Format
•
Configuring NetWare on the Subinterface
Enabling NetWare Routing
To enable IPX routing on TRISL interfaces, use the following command in global configuration mode:
Command
Purpose
Router(config)# ipx routing [node]
Enables IPX routing globally.
Defining the VLAN Encapsulation Format
To define the encapsulation format as TRISL, use the following commands in interface configuration
mode:
Command
Purpose
Step 1
Router(config-if)# interface type
slot/port.subinterface-number
Specifies the subinterface on which TRISL will be used.
Step 2
Router(config-if)# encapsulation tr-isl
trbrf-vlan trbrf-vlan bridge-num bridge-num
Defines the encapsulation for TRISL.
Configuring NetWare on the Subinterface
After you enable NetWare globally and define the VLAN encapsulation format, to enable the
subinterface by specifying the NetWare network number (if necessary) and the encapsulation type,
use the following command in interface configuration mode:
Command
Purpose
Router(config-if)# ipx network network encapsulation
encapsulation-type
Specifies the IPX encapsulation.
Cisco IOS Switching Services Configuration Guide
XC-323
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Task List
Note
The default IPX encapsulation format for Cisco IOS routers is “novell-ether” (Novell
Ethernet_802.3). If you are running Novell Netware 3.12 or 4.0, the new Novell default encapsulation
format is Novell Ethernet_802.2 and you should configure the Cisco router with the IPX
encapsulation format “sap.”
Configuring VIP Distributed Switching over ISL
With the introduction of the VIP distributed ISL feature, ISL encapsulated IP packets can be switched
on Versatile Interface Processor (VIP) controllers installed on Cisco 7500 series routers.
The second generation VIP2 provides distributed switching of IP encapsulated in ISL in VLAN
configurations. Where an aggregation route performs inter-VLAN routing for multiple VLANs, traffic
can be switched autonomously on-card or between cards rather than through the central Route Switch
Processor (RSP). Figure 79 shows the VIP distributed architecture of the Cisco 7500 series router.
Figure 79
Cisco 7500 Distributed Architecture
Route Switch Processor
IP routing
table
IP forwarding
table
Versatile
Interface
Processor
Versatile
Interface
Processor
Versatile
Interface
Processor
Distributed IP
forwarding
cache
Distributed IP
forwarding
cache
Distributed IP
forwarding
cache
Fast
Fast
Ethernet Ethernet
Fast
Fast
Ethernet Ethernet
Fast
Fast
Ethernet Ethernet
VLAN
1,2,3
VLAN
4,5,6
VLAN
7,8,9
VLAN
VLAN
10,11,12 13,14,15
S6622
CyBus
VLAN
16,17,18
This distributed architecture allows incremental capacity increases by installation of additional VIP
cards. Using VIP cards for switching the majority of IP VLAN traffic in multiprotocol environments
substantially increases routing performance for the other protocols because the RSP offloads IP and can
then be dedicated to switching the non-IP protocols.
VIP distributed switching offloads switching of ISL VLAN IP traffic to the VIP card, removing
involvement from the main CPU. Offloading ISL traffic to the VIP card substantially improves
networking performance. Because you can install multiple VIP cards in a router, VLAN routing capacity
is increased linearly according to the number of VIP cards installed in the router.
Cisco IOS Switching Services Configuration Guide
XC-324
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Task List
To configure distributed switching on the VIP, you must first configure the router for IP routing.
Perform the tasks described in the following sections in the order in which they appear:
•
Enabling IP Routing
•
Enabling VIP Distributed Switching
•
Configuring ISL Encapsulation on the Subinterface
Enabling IP Routing
To enable IP routing, use the following command in global configuration mode:
Command
Purpose
Router(config)# ip routing
Enables IP routing on the router.
Once you have IP routing enabled on the router, you can customize the characteristics to suit your
environment. Refer to the IP configuration chapters in the Cisco IOS IP Routing Configuration Guide
for guidelines on configuring IP.
Enabling VIP Distributed Switching
To enable VIP distributed switching, use the following commands beginning in interface configuration
mode:
Command
Purpose
Step 1
Router(config-if)# interface type
slot/port-adapter/port
Specifies the interface and interface configuration
mode.
Step 2
Router(config-if)# ip route-cache distributed
Enables VIP distributed switching of IP packets on
the interface.
Configuring ISL Encapsulation on the Subinterface
To configure ISL encapsulation on the subinterface, use the following commands in interface
configuration mode:
Command
Purpose
Step 1
Router(config-if)# interface type
slot/port-adapter/port
Specifies the interface, and enters interface
configuration mode.
Step 2
Router(config-if)# encapsulation isl vlan-identifier
Defines the encapsulation format as ISL, and
specifies the VLAN identifier.
Configuring XNS Routing over ISL
XNS can be routed over VLAN subinterfaces using the ISL VLAN encapsulation protocol. The XNS
Routing over ISL Virtual LANs feature provides full-feature Cisco IOS software XNS support on a
per-VLAN basis, allowing standard XNS capabilities to be configured on VLANs.
Cisco IOS Switching Services Configuration Guide
XC-325
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Task List
To route XNS over ISL VLANs, you need to configure ISL encapsulation on the subinterface.
Perform the tasks described in the following sections in the order in which they appear:
•
Enabling XNS Routing
•
Defining the VLAN Encapsulation Format
•
Configuring XNS on the Subinterface
Enabling XNS Routing
To configure XNS routing, use the following command in global configuration mode:
Command
Purpose
Router(config)# xns routing [address]
Enables XNS routing globally.
Defining the VLAN Encapsulation Format
To define the VLAN encapsulation format, use the following commands in interface configuration mode:
Command
Purpose
Step 1
Router(config-if)# interface type
slot/port.subinterface-number
Specifies the subinterface on which ISL will be used.
Step 2
Router(config-if)# encapsulation isl
vlan-identifier
Defines the encapsulation format as ISL (isl), and
specifies the VLAN identifier.
Configuring XNS on the Subinterface
To enable XNS on the subinterface by specifying the XNS network number, use the following command
in interface configuration mode:
Command
Purpose
Router(config-if)# xns network [number]
Enables XNS routing on the subinterface.
Configuring CLNS Routing over ISL
CLNS can be routed over VLAN subinterfaces using the ISL VLAN encapsulation protocol. The CLNS
Routing over ISL Virtual LANs feature provides full-feature Cisco IOS software CLNS support on a
per-VLAN basis, allowing standard CLNS capabilities to be configured on VLANs.
To route CLNS over ISL VLANs, you need to configure ISL encapsulation on the subinterface. Perform
the tasks described in the following sections in the order in which they appear:
•
Enabling CLNS Routing
•
Defining the VLAN Encapsulation Format
•
Configuring CLNS on the Subinterface
Cisco IOS Switching Services Configuration Guide
XC-326
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Task List
Enabling CLNS Routing
To configure CLNS routing, use the following command in global configuration mode:
Command
Purpose
Router(config)# clns routing
Enables CLNS routing globally.
Defining the VLAN Encapsulation Format
To define the VLAN encapsulation format, use the following commands in interface configuration mode:
Command
Purpose
Step 1
Router(config-if)# interface type
slot/port.subinterface-number
Specifies the subinterface on which ISL will be used.
Step 2
Router(config-if)# encapsulation isl
vlan-identifier
Defines the encapsulation format as ISL (isl), and
specifies the VLAN identifier.
Configuring CLNS on the Subinterface
To enable CLNS on the subinterface by specifying the CLNS network number, use the following
command in interface configuration mode:
Command
Purpose
Router(config-if)# clns enable
Enables CLNS routing on the subinterface.
Configuring IS-IS Routing over ISL
IS-IS routing can be enabled over VLAN subinterfaces using the ISL VLAN encapsulation protocol. The
IS-IS Routing over ISL Virtual LANs feature provides full-feature Cisco IOS software IS-IS support on
a per-VLAN basis, allowing standard IS-IS capabilities to be configured on VLANs.
To enable IS-IS over ISL VLANs, you need to configure ISL encapsulation on the subinterface. Perform
the tasks described in the following sections in the order in which they appear:
•
Enabling IS-IS Routing
•
Defining the VLAN Encapsulation Format
•
Configuring IS-IS on the Subinterface
Cisco IOS Switching Services Configuration Guide
XC-327
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Examples
Enabling IS-IS Routing
To configure IS-IS routing, use the following command in global configuration mode:
Command
Purpose
Step 1
Router(config)# router isis [tag]
Enables IS-IS routing, and enters router configuration
mode.
Step 2
Router(config)# net network-entity-title
Configures the NET for the routing process.
Defining the VLAN Encapsulation Format
To define the VLAN encapsulation format, use the following commands in interface configuration mode:
Command
Purpose
Step 1
Router(config-if)# interface type
slot/port.subinterface-number
Specifies the subinterface on which ISL will be used.
Step 2
Router(config-if)# encapsulation isl
vlan-identifier
Defines the encapsulation format as ISL (isl), and
specifies the VLAN identifier.
Configuring IS-IS on the Subinterface
To enable IS-IS on the subinterface by specifying the IS-IS network number, use the following command
in interface configuration mode:
Command
Purpose
Router(config-if)# clns router isis network [tag]
Specifies the interfaces that should be actively routing
IS-IS.
Monitoring and Maintaining VLAN Subinterfaces
To indicate whether a VLAN is a native VLAN, use the following command in privileged EXEC mode:
Command
Purpose
Router# show vlans
Displays VLAN subinterfaces.
ISL Encapsulation Configuration Examples
This section provides the following configuration examples for each of the protocols described in this
chapter:
•
AppleTalk Routing over ISL Configuration Examples
•
Banyan VINES Routing over ISL Configuration Example
•
DECnet Routing over ISL Configuration Example
Cisco IOS Switching Services Configuration Guide
XC-328
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Examples
•
HSRP over ISL Configuration Example
•
IP Routing with RIF Between TrBRF VLANs Example
•
IP Routing Between a TRISL VLAN and an Ethernet ISL VLAN Example
•
IPX Routing over ISL Configuration Example
•
IPX Routing on FDDI Interfaces with SDE Example
•
Routing with RIF Between a TRISL VLAN and a Token Ring Interface Example
•
VIP Distributed Switching over ISL Configuration Example
•
XNS Routing over ISL Configuration Example
•
CLNS Routing over ISL Configuration Example
•
IS-IS Routing over ISL Configuration Example
AppleTalk Routing over ISL Configuration Examples
The configuration example illustrated in Figure 80 shows AppleTalk being routed between different ISL
and IEEE 802.10 VLAN encapsulating subinterfaces.
Figure 80
Apple 100.1
VLAN 100
Routing AppleTalk over VLAN Encapsulations
Catalyst 1200
FDDI VLAN backbone using
802.10 encapsulation format
Apple 200.1
VLAN 200
FDDI SDE
fddi 1/0
Cisco 7500
series router
Wide-area link
FastEthernet 2/0
100BASE-T ISL
VLAN 3
Apple 3.1
VLAN 4
Apple 4.1
S6241
Catalyst 5000 switch
supporting 2 AppleTalk
VLANs on FastEthernet
connections with ISL
encapsulation
As shown in Figure 80, AppleTalk traffic is routed to and from switched VLAN domains 3, 4, 100, and
200 to any other AppleTalk routing interface. This example shows a sample configuration file for the
Cisco 7500 series router with the commands entered to configure the network shown in Figure 80.
Cisco 7500 Router Configuration
!
appletalk routing
interface Fddi 1/0.100
encapsulation sde 100
Cisco IOS Switching Services Configuration Guide
XC-329
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Examples
appletalk cable-range 100-100 100.2
appletalk zone 100
!
interface Fddi 1/0.200
encapsulation sde 200
appletalk cable-range
appletalk zone 200
!
interface FastEthernet
encapsulation isl 3
appletalk cable-range
appletalk zone 3
!
interface FastEthernet
encapsulation isl 4
appletalk cable-range
appletalk zone 4
!
200-200 200.2
2/0.3
3-3 3.2
2/0.4
4-4 4.2
Banyan VINES Routing over ISL Configuration Example
To configure routing of the Banyan VINES protocol over ISL trunks, you need to define ISL as the
encapsulation type. This example shows Banyan VINES configured to be routed over an ISL trunk:
vines routing
interface fastethernet 0.1
encapsulation isl 100
vines metric 2
DECnet Routing over ISL Configuration Example
To configure routing the DECnet protocol over ISL trunks, you need to define ISL as the encapsulation
type. This example shows DECnet configured to be routed over an ISL trunk:
decnet routing 2.1
interface fastethernet 1/0.1
encapsulation isl 200
decnet cost 4
HSRP over ISL Configuration Example
The configuration example shown in Figure 81 shows HSRP being used on two VLAN routers sending
traffic to and from ISL VLANs through a Catalyst 5000 switch. Each router forwards its own traffic and
acts as a standby for the other.
Cisco IOS Switching Services Configuration Guide
XC-330
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Examples
Figure 81
Hot Standby Router Protocol Sample Configuration
Enterprise
network
Cisco IOS
Cisco IOS
Cisco IOS Router A
on FastEthernet
ISL connection to a
Catalyst 5000 switch
HSRP peers
FE 1/1
FE 1/1
Cisco IOS Router B
on FastEthernet
ISL connection to a
Catalyst 5000 switch
ISL VLAN 110
Port 2/8
Port 2/9
Port 5/3
Port 5/4
Catalyst VLAN
switch
Ethernet 1/2
Ethernet 1/2
Ethernet 1/2
Host 1
Host 2
S6239
Ethernet 1/2
The topology shown in Figure 81 shows a Catalyst VLAN switch supporting Fast Ethernet connections
to two routers running HSRP. Both routers are configured to route HSRP over ISLs.
The standby conditions are determined by the standby commands used in the configuration. Traffic from
Host 1 is forwarded through Router A. Because the priority for the group is higher, Router A is the active
router for Host 1. Because the priority for the group serviced by Host 2 is higher in Router B, traffic from
Host 2 is forwarded through Router B, making Router B its active router.
In the configuration shown in Figure 81, if the active router becomes unavailable, the standby router
assumes active status for the additional traffic and automatically routes the traffic normally handled by
the router that has become unavailable.
Host 1 Configuration
interface Ethernet 1/2
ip address 10.1.1.25 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.1.1.101
Host 2 Configuration
interface Ethernet 1/2
ip address 10.1.1.27 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.1.1.102
!
Router A Configuration
interface FastEthernet 1/1.110
encapsulation isl 110
ip address 10.1.1.2 255.255.255.0
standby 1 ip 10.1.1.101
standby 1 preempt
standby 1 priority 105
standby 2 ip 10.1.1.102
standby 2 preempt
Cisco IOS Switching Services Configuration Guide
XC-331
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Examples
!
end
!
Router B Configuration
interface FastEthernet 1/1.110
encapsulation isl 110
ip address 10.1.1.3 255.255.255.0
standby 1 ip 10.1.1.101
standby 1 preempt
standby 2 ip 10.1.1.102
standby 2 preempt
standby 2 priority 105
router igrp 1
!
network 10.1.0.0
network 10.2.0.0
!
VLAN Switch Configuration
set
set
set
set
vlan 110 5/4
vlan 110 5/3
trunk 2/8 110
trunk 2/9 110
IP Routing with RIF Between TrBRF VLANs Example
Figure 82 shows IP routing with RIF between two TrBRF VLANs.
Figure 82
IP Routing with RIF Between TrBRF VLANs
Catalyst
5000 switch
TrCRF 200
100 Router
Fast Ethernet 4/0.1
TrBRF 999 / Bridge 14
5500
5.5.5.1
101
4.4.4.1
Fast Ethernet 4/0.2
Token Ring
switch
module
TrBRF 998 / Bridge 13
TrCRF 300
End station
The following is the configuration for the router:
interface FastEthernet4/0.1
ip address 10.5.5.1 255.255.255.0
encapsulation tr-isl trbrf-vlan 999 bridge-num 14
multiring trcrf-vlan 200 ring 100
multiring all
Cisco IOS Switching Services Configuration Guide
XC-332
TrCRF
Token VLAN 50
Ring
Slot 5
103
Port 2
End station
11250
TrCRF VLAN 40 Token
Slot 5 Ring
Port 1 102
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Examples
!
interface FastEthernet4/0.2
ip address 10.4.4.1 255.255.255.0
encapsulation tr-isl trbrf-vlan 998 bridge-num 13
multiring trcrf-vlan 300 ring 101
multiring all
The following is the configuration for the Catalyst 5000 switch with the Token Ring switch module in
slot 5. In this configuration, the Token Ring port 102 is assigned with TrCRF VLAN 40 and the Token
Ring port 103 is assigned with TrCRF VLAN 50:
#vtp
set vtp domain trisl
set vtp mode server
set vtp v2 enable
#drip
set set tokenring reduction enable
set tokenring distrib-crf disable
#vlans
set vlan 999 name trbrf type trbrf bridge 0xe stp ieee
set vlan 200 name trcrf200 type trcrf parent 999 ring 0x64 mode srb
set vlan 40 name trcrf40 type trcrf parent 999 ring 0x66 mode srb
set vlan 998 name trbrf type trbrf bridge 0xd stp ieee
set vlan 300 name trcrf300 type trcrf parent 998 ring 0x65 mode srb
set vlan 50 name trcrf50 type trcrf parent 998 ring 0x67 mode srb
#add token port to trcrf 40
set vlan 40
5/1
#add token port to trcrf 50
set vlan 50
5/2
set trunk 1/2 on
IP Routing Between a TRISL VLAN and an Ethernet ISL VLAN Example
Figure 83 shows IP routing between a TRISL VLAN and an Ethernet ISL VLAN.
Figure 83
IP Routing Between a TRISL VLAN and an Ethernet ISL VLAN
Catalyst
5000 switch
Ethernet ISL VLAN 12
5500
5.5.5.1
100
TrCRF 200
End station
4.4.4.1
TrBRF 999 / Bridge 14
Token Ring
switch module
in slot 5
Token
Ring
1
TrCRF100
Slot 5
Port 1
End station
11251
Router A
Ethernet
module
in slot 2
The following is the configuration for the router:
interface FastEthernet4/0.1
ip address 10.5.5.1 255.255.255.0
encapsulation tr-isl trbrf-vlan 999 bridge-num 14
multiring trcrf-vlan 20 ring 100
multiring all
!
Cisco IOS Switching Services Configuration Guide
XC-333
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Examples
interface FastEthernet4/0.2
ip address 10.4.4.1 255.255.255.0
encapsulation isl 12
IPX Routing over ISL Configuration Example
Figure 84 shows IPX interior encapsulations configured over ISL encapsulation in VLAN
configurations. Note that three different IPX encapsulation formats are used. VLAN 20 uses SAP
encapsulation, VLAN 30 uses ARPA, and VLAN 70 uses novell-ether encapsulation. Prior to the
introduction of this feature, only the default encapsulation format, “novell-ether,” was available for
routing IPX over ISL links in VLANs.
Figure 84
Configurable IPX Encapsulations Routed over ISL in VLAN Configurations
Wide-area link
carrying VLAN traffic
Cisco 7200 router
running traffic
between VLANs
RSP
Fast Ethernet links
carrying ISL traffic
FE 2/0
Workstation A
unning NetWare 4.0
on an IPX LAN with
sap encapsulation
VLAN 70
Catalyst
5000 switch
VLAN 30
Workstation B
on an IPX LAN with
arpa encapsulation
VLAN 20 Configuration
ipx routing
interface FastEthernet 2/0
no shutdown
interface FastEthernet 2/0.20
encapsulation isl 20
ipx network 20 encapsulation sap
Cisco IOS Switching Services Configuration Guide
XC-334
Catalyst
2900 switch
Workstation C
on an IPX LAN
with novell-ether
encapsulation
S6240
VLAN 20
FE 3/0
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Examples
VLAN 30 Configuration
ipx routing
interface FastEthernet 2/0
no shutdown
interface FastEthernet 2/0.30
encapsulation isl 30
ipx network 30 encapsulation arpa
VLAN 70 Configuration
ipx routing
interface FastEthernet 3/0
no shutdown
interface Fast3/0.70
encapsulation isl 70
ipx network 70 encapsulation novell-ether
IPX Routing on FDDI Interfaces with SDE Example
The following example enables IPX routing on FDDI interfaces 0.2 and 0.3 with SDE. On FDDI
interface 0.2, the encapsulation type is SNAP. On FDDI interface 0.3, the encapsulation type is Novell’s
FDDI_RAW.
ipx routing
interface fddi 0.2 enc sde 2
ipx network f02 encapsulation snap
interface fddi 0.3 enc sde 3
ipx network f03 encapsulation novell-fddi
Routing with RIF Between a TRISL VLAN and a Token Ring Interface Example
Figure 85 shows routing with RIF between a TRISL VLAN and a Token Ring interface.
Figure 85
Routing with RIF Between a TRISL VLAN and a Token Ring Interface
Catalyst 5000 switch
5500
TrCRF 200
Fast Ethernet 4/0.1
Token Ring
switch
module
TrBRF 999 / Bridge 14
100
5.5.5.1
Token
Ring 1
Token
Ring 2
End station
End station
End station
End station
TrCRF VLAN 40
Slot 5
Port 1
10777
4.4.4.1
Cisco IOS Switching Services Configuration Guide
XC-335
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Examples
The following is the configuration for the router:
source-bridge ring-group 100
!
interface TokenRing 3/1
ip address 10.4.4.1 255.255.255.0
!
interface FastEthernet4/0.1
ip address 10.5.5.1 255.255.255.0
encapsulation tr-isl trbrf 999 bridge-num 14
multiring trcrf-vlan 200 ring-group 100
multiring all
The following is the configuration for the Catalyst 5000 switch with the Token Ring switch module in
slot 5. In this configuration, the Token Ring port 1 is assigned to the TrCRF VLAN 40:
#vtp
set vtp domain trisl
set vtp mode server
set vtp v2 enable
#drip
set set tokenring reduction enable
set tokenring distrib-crf disable
#vlans
set vlan 999 name trbrf type trbrf bridge 0xe stp ieee
set vlan 200 name trcrf200 type trcrf parent 999 ring 0x64 mode srt
set vlan 40 name trcrf40 type trcrf parent 999 ring 0x1 mode srt
#add token port to trcrf 40
set vlan 40
5/1
set trunk 1/2 on
VIP Distributed Switching over ISL Configuration Example
Figure 86 shows a topology in which Catalyst VLAN switches are connected to routers forwarding
traffic from a number of ISL VLANs. With the VIP distributed ISL capability in the Cisco 7500 series
router, each VIP card can route ISL-encapsulated VLAN IP traffic. The inter-VLAN routing capacity is
increased linearly by the packet-forwarding capability of each VIP card.
Cisco IOS Switching Services Configuration Guide
XC-336
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Examples
Figure 86
VIP Distributed ISL VLAN Traffic
WAN
RSP
Cisco 7500 series router with
VIP2 or later cards routing
traffic between VLANs
CyBus
VIP
FE
VIP
FE
FE
FE
Fast Ethernet
port adapters
Fast Ethernet links
carrying ISL VLAN traffic
ISL VLAN 1
ISL VLAN 2
ISL VLAN 3
ISL VLAN 4
ISL VLAN 5
ISL VLAN 6
ISL VLAN 7
S6238
Catalyst VLAN
switches forwarding
ISL VLAN traffic
In Figure 86, the VIP cards forward the traffic between ISL VLANs or any other routing interface.
Traffic from any VLAN can be routed to any of the other VLANs, regardless of which VIP card receives
the traffic.
These commands show the configuration for each of the VLANs shown in Figure 86:
interface FastEthernet1/0/0
ip address 10.1.1.1 255.255.255.0
ip route-cache distributed
full-duplex
interface FastEthernet1/0/0.1
ip address 10.1.1.1 255.255.255.0
encapsulation isl 1
interface FastEthernet1/0/0.2
ip address 10.1.2.1 255.255.255.0
encapsulation isl 2
interface FastEthernet1/0/0.3
ip address 10.1.3.1 255.255.255.0
encapsulation isl 3
interface FastEthernet1/1/0
ip route-cache distributed
full-duplex
interface FastEthernet1/1/0.1
ip address 172.16.1.1 255.255.255.0
encapsulation isl 4
Cisco IOS Switching Services Configuration Guide
XC-337
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation
ISL Encapsulation Configuration Examples
interface Fast Ethernet 2/0/0
ip address 10.1.1.1 255.255.255.0
ip route-cache distributed
full-duplex
interface FastEthernet2/0/0.5
ip address 10.2.1.1 255.255.255.0
encapsulation isl 5
interface FastEthernet2/1/0
ip address 10.3.1.1 255.255.255.0
ip route-cache distributed
full-duplex
interface FastEthernet2/1/0.6
ip address 10.4.6.1 255.255.255.0
encapsulation isl 6
interface FastEthernet2/1/0.7
ip address 10.4.7.1 255.255.255.0
encapsulation isl 7
XNS Routing over ISL Configuration Example
To configure routing of the XNS protocol over ISL trunks, you need to define ISL as the encapsulation
type. This example shows XNS configured to be routed over an ISL trunk:
xns routing 0123.4567.adcb
interface fastethernet 1/0.1
encapsulation isl 100
xns network 20
CLNS Routing over ISL Configuration Example
To configure routing of the CLNS protocol over ISL trunks, you need to define ISL as the encapsulation
type. This example shows CLNS configured to be routed over an ISL trunk:
clns routing
interface fastethernet 1/0.1
encapsulation isl 100
clns enable
IS-IS Routing over ISL Configuration Example
To configure IS-IS routing over ISL trunks, you need to define ISL as the encapsulation type. This
example shows IS-IS configured over an ISL trunk:
isis routing test-proc2
net 49.0001.0002.aaaa.aaaa.aaaa.00
interface fastethernet 2.0
encapsulation isl 101
clns router is-is test-proc2
Cisco IOS Switching Services Configuration Guide
XC-338
Configuring Routing Between VLANs with
IEEE 802.10 Encapsulation
This chapter describes the required and optional tasks for configuring routing between VLANs with
IEEE 802.10 encapsulation.
For a complete description of the commands in this chapter, refer to the the Cisco IOS Switching Services
Command Reference. To locate documentation of other commands that appear in this chapter, use the
command reference master index or search online.
To identify the hardware platform or software image information associated with a feature, use the
Feature Navigator on Cisco.com to search for information about the feature or refer to the software
release notes for a specific release. For more information, see the section “Identifying Supported
Platforms” in the chapter “Using Cisco IOS Software.”
The IEEE 802.10 standard provides a method for secure bridging of data across a shared backbone.
It defines a single frame type known as the Secure Data Exchange (SDE), a MAC-layer frame with an
IEEE 802.10 header inserted between the MAC header and the frame data. A well-known Logical Link
Control Service Access Point notifies the switch of an incoming IEEE 802.10 frame. The VLAN ID is
carried in the 4-byte security association identifier (SAID) field.
HDLC Serial links can be used as VLAN trunks in IEEE 802.10 VLANs to extend a virtual topology
beyond a LAN backbone.
Configuring AppleTalk Routing over IEEE 802.10
AppleTalk can be routed over VLAN subinterfaces using the ISL or IEEE 802.10 VLANs feature that
provides full-feature Cisco IOS software AppleTalk support on a per-VLAN basis, allowing standard
AppleTalk capabilities to be configured on VLANs.
AppleTalk users can now configure consolidated VLAN routing over a single VLAN trunking interface.
Prior to introduction of this feature, AppleTalk could be routed only on the main interface on a LAN
port. If AppleTalk routing was disabled on the main interface or if the main interface was shut down, the
entire physical interface would stop routing any AppleTalk packets. With this feature enabled, AppleTalk
routing on subinterfaces will be unaffected by changes in the main interface with the main interface in
the “no-shut” state.
Cisco IOS Switching Services Configuration Guide
XC-339
Configuring Routing Between VLANs with IEEE 802.10 Encapsulation
Configuring AppleTalk Routing over IEEE 802.10
To route AppleTalk over IEEE 802.10 between VLANs, create the environment in which it will be used
by customizing the subinterface and perform the tasks described in the following sections in the order in
which they appear:
•
Enabling AppleTalk Routing
•
Configuring AppleTalk on the Subinterface
•
Defining the VLAN Encapsulation Format
•
Monitoring and Maintaining VLAN Subinterfaces
Enabling AppleTalk Routing
To enable AppleTalk routing on IEEE 802.10 interfaces, use the following command in global
configuration mode:
Command
Purpose
Router(config)# appletalk routing [eigrp router-number]
Enables AppleTalk routing globally.
Note
For more information on configuring AppleTalk, see the “Configuring AppleTalk” chapter in the
Cisco IOS AppleTalk and Novell IPX Configuration Guide.
Configuring AppleTalk on the Subinterface
After you enable AppleTalk globally and define the encapsulation format, you need to enable it on the
subinterface by specifying the cable range and naming the AppleTalk zone for each interface. To enable
the AppleTalk protocol on the subinterface, use the following commands in interface configuration
mode:
Command
Purpose
Router(config-if)# appletalk cable-range cable-range
[network.node]
Assigns the AppleTalk cable range and zone for the
subinterface.
Router(config-if)# appletalk zone zone-name
Assigns the AppleTalk zone for the subinterface.
Cisco IOS Switching Services Configuration Guide
XC-340
Configuring Routing Between VLANs with IEEE 802.10 Encapsulation
Routing AppleTalk over IEEE 802.10 Configuration Example
Defining the VLAN Encapsulation Format
To define the VLAN encapsulation format as either ISL or 802.10, use the following commands in
interface configuration mode:
Command
Purpose
Step 1
Router(config-if)# interface type
slot/port.subinterface-number
Specifies the subinterface the VLAN will use.
Step 2
Router(config-if)# encapsulation sde said
Defines the encapsulation format as IEEE 802.10 (sde)
and specifies the VLAN identifier or security association
identifier, respectively.
Monitoring and Maintaining VLAN Subinterfaces
To indicate whether a VLAN is a native VLAN, use the following command in privileged EXEC mode:
Command
Purpose
Router# show vlans
Displays VLAN subinterfaces.
Routing AppleTalk over IEEE 802.10 Configuration Example
The configuration example shown in Figure 87 shows AppleTalk being routed between different ISL and
IEEE 802.10 VLAN encapsulating subinterfaces.
Figure 87
Apple 100.1
VLAN 100
Routing AppleTalk over VLAN encapsulations
Catalyst 1200
FDDI VLAN backbone using
802.10 encapsulation format
Apple 200.1
VLAN 200
FDDI SDE
fddi 1/0
Cisco 7500
series router
Wide-area link
FastEthernet 2/0
100BASE-T ISL
VLAN 3
Apple 3.1
VLAN 4
Apple 4.1
S6241
Catalyst 5000 switch
supporting 2 AppleTalk
VLANs on FastEthernet
connections with ISL
encapsulation
Cisco IOS Switching Services Configuration Guide
XC-341
Configuring Routing Between VLANs with IEEE 802.10 Encapsulation
Routing AppleTalk over IEEE 802.10 Configuration Example
As shown in Figure 87, AppleTalk traffic is routed to and from switched VLAN domains 3, 4, 100, and
200 to any other AppleTalk routing interface. This example shows a sample configuration file for the
Cisco 7500 series router with the commands entered to configure the network shown in Figure 87.
Cisco 7500 Router Configuration
!
interface Fddi 1/0.100
encapsulation sde 100
appletalk cable-range
appletalk zone 100
!
interface Fddi 1/0.200
encapsulation sde 200
appletalk cable-range
appletalk zone 200
!
interface FastEthernet
encapsulation isl 3
appletalk cable-range
appletalk zone 3
!
interface FastEthernet
encapsulation isl 4
appletalk cable-range
appletalk zone 4
!
100-100 100.2
200-200 200.2
2/0.3
3-3 3.2
2/0.4
4-4 4.2
Cisco IOS Switching Services Configuration Guide
XC-342
Configuring Routing Between VLANs with
IEEE 802.1Q Encapsulation
This chapter describes the required and optional tasks for configuring routing between VLANs with
IEEE 802.1Q encapsulation.
For a complete description of the commands in this chapter, refer to the the Cisco IOS Switching Services
Command Reference. To locate documentation of other commands that appear in this chapter, use the
command reference master index or search online.
To identify the hardware platform or software image information associated with a feature, use the
Feature Navigator on Cisco.com to search for information about the feature or refer to the software
release notes for a specific release. For more information, see the section “Identifying Supported
Platforms” in the chapter “Using Cisco IOS Software.”
The IEEE 802.1Q protocol is used to interconnect multiple switches and routers, and for defining VLAN
topologies. The IEEE 802.1Q standard is extremely restrictive to untagged frames. The standard
provides only a per-port VLANs solution for untagged frames. For example, assigning untagged frames
to VLANs takes into consideration only the port from which they have been received. Each port has a
parameter called a permanent virtual identification (Native VLAN) that specifies the VLAN assigned to
receive untagged frames.
The main characteristics of IEEE 802.1Q are as follows:
•
Assigns frames to VLANs by filtering.
•
The standard assumes the presence of a single spanning tree and of an explicit tagging scheme with
one-level tagging.
IEEE 802.1Q Encapsulation VLANs Configuration Task List
You can configure routing between any number of VLANs in your network.
This section documents the configuration tasks for each protocol supported with IEEE 802.1Q
encapsulation. The basic process is the same, regardless of the protocol being routed. It involves the
following tasks:
•
Enabling the protocol on the router
•
Enabling the protocol on the interface
•
Defining the encapsulation format as IEEE 802.1Q
•
Customizing the protocol according to the requirements for your environment
Cisco IOS Switching Services Configuration Guide
XC-343
Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation
IEEE 802.1Q Encapsulation VLANs Configuration Task List
To configure IEEE 802.1Q of your network, perform the tasks described in the following sections. The
first three sections contain required tasks; the remaining tasks are optional:
•
Configuring AppleTalk Routing over IEEE 802.1Q (Required)
•
Configuring IP Routing over IEEE 802.1Q (Required)
•
Configuring IPX Routing over IEEE 802.1Q (Required)
Perform the tasks in the following sections to connect a network of hosts over a simple bridging-access
device to a remote access concentrator bridge between IEEE 802.1Q VLANs. The following sections
contain configuration tasks for the Integrated Routing and Bridging, Transparent Bridging, and PVST+
Between VLANs with IEEE 802.1Q Encapsulation feature:
•
Configuring a VLAN for a bridge-group with Default VLAN1(Optional)
•
Configuring a VLAN for a bridge-group as a Native VLAN (Optional)
•
Monitoring and Maintaining VLAN Subinterfaces (Optional)
Configuring AppleTalk Routing over IEEE 802.1Q
AppleTalk can be routed over virtual LAN (VLAN) subinterfaces using the IEEE 802.1Q VLAN
encapsulation protocol. AppleTalk Routing provides full-feature Cisco IOS software AppleTalk support
on a per-VLAN basis, allowing standard AppleTalk capabilities to be configured on VLANs.
To route AppleTalk over IEEE 802.1Q between VLANs, you need to customize the subinterface to create
the environment in which it will be used. Perform these tasks in the order in which they appear:
•
Enabling AppleTalk Routing
•
Configuring AppleTalk on the Subinterface
•
Defining the VLAN Encapsulation Format
Enabling AppleTalk Routing
To enable AppleTalk routing on IEEE 802.1Q interfaces, use the following command in global
configuration mode:
Command
Purpose
Router(config)# appletalk routing [eigrp router-number]
Enables AppleTalk routing globally.
Note
For more information on configuring AppleTalk, see the “Configuring AppleTalk” chapter in the
Cisco IOS AppleTalk and Novell IPX Configuration Guide.
Cisco IOS Switching Services Configuration Guide
XC-344
Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation
IEEE 802.1Q Encapsulation VLANs Configuration Task List
Configuring AppleTalk on the Subinterface
After you enable AppleTalk globally and define the encapsulation format, you need to enable it on the
subinterface by specifying the cable range and naming the AppleTalk zone for each interface. To enable
the AppleTalk protocol on the subinterface, use the following commands in interface configuration
mode:
Command
Purpose
Step 1
Router(config-if)# appletalk cable-range cable-range
[network.node]
Assigns the AppleTalk cable range and zone for the
subinterface.
Step 2
Router(config-if)# appletalk zone zone-name
Assigns the AppleTalk zone for the subinterface.
Defining the VLAN Encapsulation Format
To define the VLAN encapsulation format as IEEE 802.1Q, use the following commands in interface
configuration mode:
Command
Purpose
Step 1
Router(config-if)# interface fastethernet
slot/port.subinterface-number
Specifies the subinterface the VLAN will use.
Step 2
Router(config-if)# encapsulation dot1q
vlan-identifier
Defines the encapsulation format as IEEE 802.1Q
(dot1q), and specifies the VLAN identifier.
Configuring IP Routing over IEEE 802.1Q
IP routing over IEEE 802.1Q extends IP routing capabilities to include support for routing IP frame types
in VLAN configurations using the IEEE 802.1Q encapsulation.
To route IP over IEEE 802.1Q between VLANs, you need to customize the subinterface to create the
environment in which it will be used. Perform the tasks described in the following sections in the order
in which they appear:
•
Enabling IP Routing
•
Defining the VLAN Encapsulation Format
•
Assigning an IP Address to Network Interface
Enabling IP Routing
IP routing is automatically enabled in the Cisco IOS software for routers. To reenable IP routing if it has
been disabled, use the following command in global configuration mode:
Command
Purpose
Router(config)# ip routing
Enables IP routing on the router.
Cisco IOS Switching Services Configuration Guide
XC-345
Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation
IEEE 802.1Q Encapsulation VLANs Configuration Task List
Once you have IP routing enabled on the router, you can customize the characteristics to suit your
environment. If necessary, refer to the IP configuration chapters in the Cisco IOS IP Routing
Configuration Guide for guidelines on configuring IP.
Defining the VLAN Encapsulation Format
To define the encapsulation format as IEEE 802.1Q, use the following commands in interface
configuration mode:
Command
Purpose
Step 1
Router(config-if)# interface fastethernet
slot/port.subinterface-number
Specifies the subinterface on which IEEE 802.1Q will be
used.
Step 2
Router(config-if)# encapsulation dot1q vlanid
Defines the encapsulation format as IEEE 802.1Q (dot1q),
and specifies the VLAN identifier
Assigning an IP Address to Network Interface
An interface can have one primary IP address. To assign a primary IP address and a network mask to a
network interface, use the following command in interface configuration mode:
Command
Purpose
Router(config-if)# ip address ip-address mask
Sets a primary IP address for an interface.
A mask identifies the bits that denote the network number in an IP address. When you use the mask to
subnet a network, the mask is then referred to as a subnet mask.
Configuring IPX Routing over IEEE 802.1Q
IPX routing over IEEE 802.1Q VLANs extends Novell NetWare routing capabilities to include support
for routing Novell Ethernet_802.3 encapsulation frame types in VLAN configurations. Users with
Novell NetWare environments can configure Novell Ethernet_802.3 encapsulation frames to be routed
using IEEE 802.1Q encapsulation across VLAN boundaries.
To configure Cisco IOS software on a router with connected VLANs to exchange IPX Novell
Ethernet_802.3 encapsulated frames, perform the tasks described in the following sections in the order
in which they are appear:
•
Enabling NetWare Routing
•
Defining the VLAN Encapsulation Format
•
Configuring NetWare on the Subinterface
Cisco IOS Switching Services Configuration Guide
XC-346
Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation
IEEE 802.1Q Encapsulation VLANs Configuration Task List
Enabling NetWare Routing
To enable IPX routing on IEEE 802.1Q interfaces, use the following command in global configuration
mode:
Command
Purpose
Router(config)# ipx routing [node]
Enables IPX routing globally.
Defining the VLAN Encapsulation Format
To define the encapsulation format as IEEE 802.1Q, use the following commands in interface
configuration mode:
Command
Purpose
Step 1
Router(config-if)# interface fastethernet
slot/port.subinterface-number
Specifies the subinterface on which IEEE 802.1Q will
be used.
Step 2
Router(config-if)# encapsulation dot1q
vlan-identifier
Defines the encapsulation format as IEEE 802.1Q and
specifies the VLAN identifier.
Configuring NetWare on the Subinterface
After you enable NetWare globally and define the VLAN encapsulation format, you may need to enable
the subinterface by specifying the NetWare network number. Use this command in interface
configuration mode:
Command
Purpose
Router(config-if)# ipx network network
Specifies the IPX network number.
Configuring a VLAN for a bridge-group with Default VLAN1
To configure a VLAN associated to a bridge group with a default native VLAN, use the following
commands beginning in global configuration mode:
Command
Purpose
Step 1
Router(config)# interface fastethernet slot/port
Selects a particular Fast Ethernet interface for
configuration.
Step 2
Router(config-subif)# encapsulation dot1q 1
Enables IEEE 802.1Q encapsulation of traffic on a
specified subinterface in VLANs, and defaults the
associated VLAN as a native VLAN.
Step 3
Router(config-subif)# bridge-group bridge-group
Assigns each network interface to a bridge group.
Note
If there is no explicitly defined native VLAN, the default VLAN 1 becomes the native VLAN 1.
Cisco IOS Switching Services Configuration Guide
XC-347
Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation
IEEE 802.1Q Encapsulation Configuration Examples
Configuring a VLAN for a bridge-group as a Native VLAN
To configure a VLAN associated to a bridge group as a native VLAN, use the following beginning
commands in global configuration mode:
Command
Purpose
Step 1
Router(config)# interface fastethernet slot/port
Selects a particular Fast Ethernet interface for
configuration.
Step 2
Router(config-subif)# encapsulation dot1q vlan-id
native
Enables IEEE 802.1Q encapsulation of traffic on a
specified subinterface in VLANs, and
defaults to 1.
Step 3
Router(config-subif)# bridge-group bridge-group
Assigns each network interface to a bridge group.
Note
If there is an explicitly defined native VLAN, VLAN 1 will only be used to process CST.
Monitoring and Maintaining VLAN Subinterfaces
To indicate whether a VLAN is a native VLAN, use the following command in privileged EXEC mode:
Command
Purpose
Router# show vlans
Displays VLAN subinterfaces.
IEEE 802.1Q Encapsulation Configuration Examples
Configuration examples for each protocols are provided in the following sections:
•
!Configuring AppleTalk over IEEE 802.1Q Example
•
Configuring IP Routing over IEEE 802.1Q Example
•
Configuring IPX Routing over IEEE 802.1Q Example
•
VLAN 100 for Bridge Group 1 with Default VLAN 1 Example
•
VLAN 20 for Bridge Group 1 with Native VLAN Example
•
VLAN ISL or IEEE 802.1Q Routing Example
•
VLAN IEEE 802.1Q Bridging Example
•
VLAN IEEE 802.1Q IRB Example
Cisco IOS Switching Services Configuration Guide
XC-348
Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation
IEEE 802.1Q Encapsulation Configuration Examples
Configuring AppleTalk over IEEE 802.1Q Example
This configuration example shows AppleTalk being routed on VLAN 100:
!
appletalk routing
!
interface fastethernet 4/1.100
encapsulation dot1q 100
appletalk cable-range 100-100 100.1
appletalk zone eng
!
Configuring IP Routing over IEEE 802.1Q Example
This configuration example shows IP being routed on VLAN 101:
!
ip routing
!
interface fastethernet 4/1.101
encapsulation dot1q 101
ip addr 10.0.0.11 255.0.0.0
!
Configuring IPX Routing over IEEE 802.1Q Example
This configuration example shows IPX being routed on VLAN 102:
!
ipx routing
!
interface fastethernet 4/1.102
encapsulation dot1q 102
ipx network 100
!
VLAN 100 for Bridge Group 1 with Default VLAN 1 Example
The following example configures VLAN 100 for bridge group 1 with a default VLAN 1:
interface FastEthernet 4/1.100
encapsulation dot1q 1
bridge-group 1
VLAN 20 for Bridge Group 1 with Native VLAN Example
The following example configures VLAN 20 for bridge group 1 as a native VLAN:
interface FastEthernet 4/1.100
encapsulation dot1q 20 native
bridge-group 1
Cisco IOS Switching Services Configuration Guide
XC-349
Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation
IEEE 802.1Q Encapsulation Configuration Examples
VLAN ISL or IEEE 802.1Q Routing Example
The following example configures VLAN ISL or IEEE 802.10 routing:
ipx routing
appletalk routing
!
interface Ethernet 1
ip address 10.1.1.1 255.255.255.0
appletalk cable-range 1-1 1.1
appletalk zone 1
ipx network 10 encapsulation snap
!
router igrp 1
network 10.1.0.0
!
end
!
#Catalyst5000
!
set VLAN 110 2/1
set VLAN 120 2/2
!
set trunk 1/1 110,120
# if 802.1Q, set trunk 1/1 nonegotiate 110, 120
!
end
!
ipx routing
appletalk routing
!
interface FastEthernet 1/1.110
encapsulation isl 110
!if 802.1Q, encapsulation dot1Q 110
ip address 10.1.1.2 255.255.255.0
appletalk cable-range 1.1 1.2
appletalk zone 1
ipx network 110 encapsulation snap
!
interface FastEthernet 1/1.120
encapsulation isl 120
!if 802.1Q, encapsulation dot1Q 120
ip address 10.2.1.2 255.255.255.0
appletalk cable-range 2-2 2.2
appletalk zone 2
ipx network 120 encapsulation snap
!
router igrp 1
network 10.1.0.0
network 10.2.1.0.0
!
end
!
ipx routing
appletalk routing
!
interface Ethernet 1
ip address 10.2.1.3 255.255.255.0
appletalk cable-range 2-2 2.3
appletalk zone 2
ipx network 120 encapsulation snap
Cisco IOS Switching Services Configuration Guide
XC-350
Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation
IEEE 802.1Q Encapsulation Configuration Examples
!
router igrp 1
network 10.2.0.0
!
end
VLAN IEEE 802.1Q Bridging Example
The following examples configures IEEE 802.1Q bridging:
interface FastEthernet4/0
no ip address
no ip route-cache
half-duplex
!
interface FastEthernet4/0.100
encapsulation dot1Q 100
no ip route-cache
bridge-group 1
!
interface FastEthernet4/0.200
encapsulation dot1Q 200 native
no ip route-cache
bridge-group 2
!
interface FastEthernet4/0.300
encapsulation dot1Q 1
no ip route-cache
bridge-group 3
!
interface FastEthernet10/0
no ip address
no ip route-cache
half-duplex
!
interface FastEthernet10/0.100
encapsulation dot1Q 100
no ip route-cache
bridge-group 1
!
interface Ethernet11/3
no ip address
no ip route-cache
bridge-group 2
!
interface Ethernet11/4
no ip address
no ip route-cache
bridge-group 3
!
bridge 1 protocol ieee
bridge 2 protocol ieee
bridge 3 protocol ieee
Cisco IOS Switching Services Configuration Guide
XC-351
Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation
IEEE 802.1Q Encapsulation Configuration Examples
VLAN IEEE 802.1Q IRB Example
The following examples configures IEEE 802.1Q integrated routing and bridging:
ip cef
appletalk routing
ipx routing 0060.2f27.5980
!
bridge irb
!
interface TokenRing3/1
no ip address
ring-speed 16
bridge-group 2
!
interface FastEthernet4/0
no ip address
half-duplex
!
interface FastEthernet4/0.100
encapsulation dot1Q 100
bridge-group 1
!
interface FastEthernet4/0.200
encapsulation dot1Q 200
bridge-group 2
!
interface FastEthernet10/0
ip address 10.3.1.10 255.255.255.0
half-duplex
appletalk cable-range 200-200 200.10
appletalk zone irb
ipx network 200
!
interface Ethernet11/3
no ip address
bridge-group 1
!
interface BVI 1
ip address 10.1.1.11 255.255.255.0
appletalk cable-range 100-100 100.11
appletalk zone bridging
ipx network 100
!
router rip
network 10.0.0.0
network 10.3.0.0
!
bridge 1 protocol ieee
bridge 1 route appletalk
bridge 1 route ip
bridge 1 route ipx
bridge 2 protocol ieee
!
Cisco IOS Switching Services Configuration Guide
XC-352
LAN Emulation
LAN Emulation Overview
This overview chapter gives a high-level description of LAN Emulation (LANE).
Procedures for configuring LANE are provided in the following chapters in this publication:
•
“Configuring LAN Emulation” chapter
•
“Configuring Token Ring LAN Emulation” chapter
LAN Emulation
The Cisco implementation of LANE makes an ATM interface look like one or more Ethernet interfaces.
LANE is an ATM service defined by the ATM Forum specification LAN Emulation over ATM,
ATM_FORUM 94-0035. This service emulates the following LAN-specific characteristics:
•
Connectionless services
•
Multicast services
•
LAN MAC driver services
LANE service provides connectivity between ATM-attached devices and connectivity with
LAN-attached devices. This includes connectivity between ATM-attached stations and LAN-attached
stations and also connectivity between LAN-attached stations across an ATM network.
Because LANE connectivity is defined at the MAC layer, upper protocol-layer functions of LAN
applications can continue unchanged when the devices join emulated LANs (ELANs). This feature
protects corporate investments in legacy LAN applications.
An ATM network can support multiple independent ELAN networks. Membership of an end system in
any of the ELANs is independent of the physical location of the end system. This characteristic enables
easy hardware moves and location changes. In addition, the end systems can also move easily from one
ELAN to another, whether or not the hardware moves.
LANE in an ATM environment provides routing between ELANs for supported routing protocols and
high-speed, scalable switching of local traffic.
The ATM LANE system has three servers that are single points of failure. These are the LANE
Configuration Server (LECS), the ELAN server (LES), and the broadcast and unknown server (BUS).
Beginning with Cisco IOS Release 11.2, LANE fault tolerance or Simple LANE Service Replication on
the ELAN provides backup servers to prevent problems if these servers fail.
The fault tolerance mechanism that eliminates these single points of failure is described in the
“Configuring LAN Emulation” chapter. Although this scheme is proprietary, no new protocol additions
have been made to the LANE subsystems.
Cisco IOS Switching Services Configuration Guide
XC-354
LAN Emulation Overview
LAN Emulation
LANE Components
Any number of ELANs can be set up in an ATM switch cloud. A router can participate in any number
of these ELANs.
LANE is defined on a LAN client/server model. The following components are implemented:
•
LANE client—A LANE client emulates a LAN interface to higher layer protocols and applications.
It forwards data to other LANE components and performs LANE address resolution functions.
Each LANE client is a member of only one ELAN. However, a router can include LANE clients for
multiple ELANs: one LANE client for each ELAN of which it is a member.
If a router has clients for multiple ELANs, the Cisco IOS software can route traffic between the
ELANs.
•
LES—The LES for an ELAN is the control center. It provides joining, address resolution, and
address registration services to the LANE clients in that ELAN. Clients can register destination
unicast and multicast MAC addresses with the LES. The LES also handles LANE ARP (LE ARP)
requests and responses.
The Cisco implementation has a limit of one LES per ELAN.
•
LANE BUS—The LANE BUS sequences and distributes multicast and broadcast packets and
handles unicast flooding.
In this release, the LES and the LANE BUS are combined and located in the same Cisco 7000 family
or Cisco 4500 series router; one combined LECS and BUS is required per ELAN.
•
LECS—The LECS contains the database that determines which ELAN a device belongs to (each
configuration server can have a different named database). Each LANE client consults the LECS just
once, when it joins an ELAN, to determine which ELAN it should join. The LECS returns the ATM
address of the LES for that ELAN.
One LECS is required per LANE ATM switch cloud.
The LECS’s database can have the following four types of entries:
– ELAN name-ATM address of LES pairs
– LANE client MAC address-ELAN name pairs
– LANE client ATM template-ELAN name pairs
– Default ELAN name
Note
ELAN names must be unique on an interface. If two interfaces participate in LANE, the second
interface may be in a different switch cloud.
LANE Operation and Communication
Communication among LANE components is ordinarily handled by several types of switched virtual
circuits (SVCs). Some SVCs are unidirectional; others are bidirectional. Some are point-to-point and
others are point-to-multipoint. Figure 88 illustrates the various virtual channel connections
(VCCs)—also known as virtual circuit connections—that are used in LANE configuration.
Cisco IOS Switching Services Configuration Guide
XC-355
LAN Emulation Overview
LAN Emulation
Figure 88 shows LANE components: LE server stands for the LANE server (LECS), LECS stands for
the LANE configuration server, and BUS stands for the LANE broadcast.
Figure 88
LANE VCC Types
LE server
LECS
12
10
11
2
3
4
1
5
2
6
6
Client A
1–7
2–8
3–11
Control direct
Control distribute
Configure direct (client)
4–9
5–10
6–6
11–12
3
5
9
4
S3736
1
9
7
8
7
BUS
11
Client B
Multicast send
Multicast forward
Data direct
Configure direct (server)
The following section describes various processes that occur, starting with a client requesting to join an
ELAN after the component routers have been configured.
Client Joining an ELAN
The following process normally occurs after a LANE client has been enabled:
•
Client requests to join an ELAN—The client sets up a connection to the LECS—a bidirectional
point-to-point Configure Direct VCC—to find the ATM address of the LES for its ELAN.
LANE clients find the LECS by using the following methods in the listed order:
– Locally configured ATM address
– Interim Local Management Interface (ILMI)
– Fixed address defined by the ATM Forum
– PVC 0/17
•
Configuration server identifies the LES—Using the same VCC, the LECS returns the ATM address
and the name of the LES for the client’s ELAN.
•
Client contacts the server for its LAN—The client sets up a connection to the LES for its ELAN (a
bidirectional point-to-point Control Direct VCC) to exchange control traffic.
Once a Control Direct VCC is established between a LANE client and a LES, it remains up.
•
Server verifies that the client is allowed to join the ELAN—The server for the ELAN sets up a
connection to the LECS to verify that the client is allowed to join the ELAN—a bidirectional
point-to-point Configure Direct (server) VCC. The server’s configuration request contains the
client’s MAC address, its ATM address, and the name of the ELAN. The LECS checks its database
to determine whether the client can join that LAN; then it uses the same VCC to inform the server
whether the client is or is not allowed to join.
Cisco IOS Switching Services Configuration Guide
XC-356
LAN Emulation Overview
LAN Emulation
•
LES allows or disallows the client to join the ELAN—If allowed, the LES adds the LANE client to
the unidirectional point-to-multipoint Control Distribute VCC and confirms the join over the
bidirectional point-to-point Control Direct VCC. If disallowed, the LES rejects the join over the
bidirectional point-to-point Control Direct VCC.
•
LANE client sends LE ARP packets for the broadcast address, which is all 1s—Sending LE ARP
packets for the broadcast address sets up the VCCs to and from the BUS.
Address Resolution
As communication occurs on the ELAN, each client dynamically builds a local LANE ARP (LE ARP)
table. A LE ARP table belonging to a client can also have static, preconfigured entries. The LE ARP
table maps MAC addresses to ATM addresses.
Note
LE ARP is not the same as IP ARP. IP ARP maps IP addresses (Layer 3) to Ethernet MAC addresses
(Layer 2); LE ARP maps ELAN MAC addresses (Layer 2) to ATM addresses (also Layer 2).
When a client first joins an ELAN, its LE ARP table has no dynamic entries and the client has no
information about destinations on or behind its ELAN. To learn about a destination when a packet is to
be sent, the client begins the following process to find the ATM address corresponding to the known
MAC address:
•
The client sends a LE ARP request to the LES for this ELAN (point-to-point Control Direct VCC).
•
The LES forwards the LE ARP request to all clients on the ELAN (point-to-multipoint Control
Distribute VCC).
•
Any client that recognizes the MAC address responds with its ATM address (point-to-point Control
Direct VCC).
•
The LES forwards the response (point-to-multipoint Control Distribute VCC).
•
The client adds the MAC address-ATM address pair to its LE ARP cache.
•
Then the client can establish a VCC to the desired destination and send packets to that ATM address
(bidirectional point-to-point Data Direct VCC).
For unknown destinations, the client sends a packet to the BUS, which forwards the packet to all clients
via flooding. The BUS floods the packet because the destination might be behind a bridge that has not
yet learned this particular address.
Multicast Traffic
When a LANE client has broadcast or multicast traffic, or unicast traffic with an unknown address to
send, the following process occurs:
•
The client sends the packet to the BUS (unidirectional point-to-point Multicast Send VCC).
•
The BUS forwards (floods) the packet to all clients (unidirectional point-to-multipoint Multicast
Forward VCC).
This VCC branches at each ATM switch. The switch forwards such packets to multiple outputs.
(The switch does not examine the MAC addresses; it simply forwards all packets it receives.)
Cisco IOS Switching Services Configuration Guide
XC-357
LAN Emulation Overview
LAN Emulation
Typical LANE Scenarios
In typical LANE cases, one or more Cisco 7000 family routers, or Cisco 4500 series routers are attached
to a Cisco LightStream ATM switch. The LightStream ATM switch provides connectivity to the broader
ATM network switch cloud. The routers are configured to support one or more ELANs. One of the
routers is configured to perform the LECS functions. A router is configured to perform the server
function and the BUS function for each ELAN. (One router can perform the server function and the BUS
function for several ELANs.) In addition to these functions, each router also acts as a LANE client for
one or more ELANs.
This section presents two scenarios using the same four Cisco routers and the same Cisco LightStream
ATM switch. Figure 89 illustrates a scenario in which one ELAN is set up on the switch and routers.
Figure 90 illustrates a scenario in which several ELANs are set up on the switch and routers.
The physical layout and the physical components of an emulated network might not differ for the single
and the multiple ELAN cases. The differences are in the software configuration for the number of
ELANs and the assignment of LANE components to the different physical components.
Single ELAN Scenario
In a single ELAN scenario, the LANE components might be assigned as follows:
•
Router 1 includes the following LANE components:
– The LECS (one per LANE switch cloud)
– The LES and BUS for the ELAN with the default name man (for Manufacturing)
– The LANE client for the man ELAN.
•
Router 2 includes a LANE client for the man ELAN.
•
Router 3 includes a LANE client for the man ELAN.
•
Router 4 includes a LANE client for the man ELAN.
Figure 89 illustrates this single ELAN configured across several routers.
Figure 89
Single ELAN Configured on Several Routers
configuration server
man server-bus
man client
Router 1
Cisco
LightStream
ATM switch
man client
man client
Router 3
man client
Router 4
Cisco IOS Switching Services Configuration Guide
XC-358
S5040
Router 2
LAN Emulation Overview
LAN Emulation
Multiple ELAN Scenario
In the multiple LAN scenario, the same switch and routers are used, but multiple ELANs are configured.
See Figure 90.
Figure 90
Multiple ELANs Configured on Several Routers
Configuration server
man server-bus
eng server-bus
man client
Router 1
eng client
Cisco
LightStream
ATM switch
man client
eng client
man client
mkt client
Router 2
Router 3
S5039
mkt server-bus
man client
mkt client
Router 4
In the following scenario, three ELANs are configured on four routers:
•
Router 1 includes following LANE components:
– The LECS (one per LANE switch cloud)
– The LES and BUS for the ELAN called man (for Manufacturing)
– The LES and BUS functions for the ELAN called eng (for Engineering)
– A LANE client for the man ELAN
– A LANE client for the eng ELAN
•
Router 2 includes only the LANE clients for the man and eng ELANs.
•
Router 3 includes only the LANE clients for the man and mkt (for Marketing) ELANs.
•
Router 4 includes the following LANE components:
– The LES and BUS for the mkt ELAN
– A LANE client for the man ELAN
– A LANE client for the mkt ELANs
In this scenario, once routing is enabled and network level addresses are assigned, Router 1 and Router 2
can route between the man and the eng ELANs, and Router 3 and Router 4 can route between the man
and the mkt ELANs.
Cisco IOS Switching Services Configuration Guide
XC-359
Configuring LAN Emulation
This chapter describes how to configure LAN emulation (LANE) on the following platforms that are
connected to an ATM switch or switch cloud:
Note
•
ATM Interface Processor (AIP) on the Cisco 7500 series routers
•
ATM port adapter on the Cisco 7200 series and Cisco 7500 series routers
•
Network Processor Module (NPM) on the Cisco 4500 and Cisco 4700 routers
Beginning with Cisco IOS Release 11.3, all commands supported on the Cisco 7500 series routers
are also supported on the Cisco 7000 series.
This chapter contains these sections:
•
LANE on ATM
•
LANE Implementation Considerations
•
LANE Configuration Task List
•
LANE Configuration Examples
For a complete description of the commands in this chapter, refer to the the Cisco IOS Switching Services
Command Reference. To locate documentation of other commands that appear in this chapter, use the
command reference master index or search online.
To identify the hardware platform or Cisco IOS image information associated with a feature, use the
Feature Navigator on Cisco.com to search for information about the feature or refer to the Cisco IOS
release notes for a specific release. For more information, see the section “Identifying Supported
Platforms” in the chapter “Using Cisco IOS Software.”
LANE on ATM
LANE emulates an IEEE 802.3 Ethernet or IEEE 802.5 Token Ring LAN using ATM technology. LANE
provides a service interface for network-layer protocols that is identical to existing MAC layers.
No changes are required to existing upper layer protocols and applications. With LANE, Ethernet and
Token Ring packets are encapsulated in the appropriate ATM cells and sent across the ATM network.
When the packets reach the other side of the ATM network, they are deencapsulated. LANE essentially
bridges LAN traffic across ATM switches.
Cisco IOS Switching Services Configuration Guide
XC-360
Configuring LAN Emulation
LANE on ATM
Benefits of LANE
ATM is a cell-switching and multiplexing technology designed to combine the benefits of circuit
switching (constant transmission delay and guaranteed capacity) with those of packet switching
(flexibility and efficiency for intermittent traffic).
LANE allows legacy Ethernet and Token Ring LAN users to take advantage of ATM’s benefits without
modifying end-station hardware or software. ATM uses connection-oriented service with point-to-point
signalling or multicast signalling between source and destination devices. However, LANs use
connectionless service. Messages are broadcast to all devices on the network. With LANE, routers and
switches emulate the connectionless service of a LAN for the endstations.
By using LANE, you can scale your networks to larger sizes while preserving your investment in LAN
technology.
LANE Components
A single emulated LAN (ELAN) consists of the following entities: A LECS, a BUS, a LES, and LANE
clients.
•
LANE configuration server—A server that assigns individual clients to particular emulated LANs
by directing them to the LES for the ELAN. The LANE configuration server (LECS) maintains a
database of LANE client and server ATM or MAC addresses and their emulated LANs. An LECS
can serve multiple emulated LANs.
•
LANE broadcast and unknown server—A multicast server that floods unknown destination traffic
and forwards multicast and broadcast traffic to clients within an ELAN. One broadcast and unknown
server (BUS) exists per ELAN.
•
LANE server—A server that provides a registration facility for clients to join the ELAN. There is
one LANE server (LES) per ELAN. The LES handles LAN Emulation Address Resolution Protocol
(LE ARP) requests and maintains a list of LAN destination MAC addresses. For Token Ring LANE,
the LES also maintains a list of route-descriptors that is used to support source-route bridging (SRB)
over the ELAN. The route-descriptors are used to determine the ATM address of the next hop in the
Routing Information Field (RIF).
•
LANE client—An entity in an endpoint, such as a router, that performs data forwarding, address
resolution, and other control functions for a single endpoint in a single ELAN. The LANE client
(LEC) provides standard LAN service to any higher layers that interface with it. A router can have
multiple resident LANE clients, each connecting with different emulated LANs. The LANE client
registers its MAC and ATM addresses with the LES.
ELAN entities coexist on one or more Cisco routers. On Cisco routers, the LES and the BUS are
combined into a single entity.
Other LANE components include ATM switches—any ATM switch that supports the Interim Local
Management Interface (ILMI) and signalling. Multiple emulated LANs can coexist on a single
ATM network.
Simple Server Redundancy
LANE relies on three servers: the LECS, the LES, and the BUS. If any one of these servers fails, the
ELAN cannot fully function.
Cisco IOS Switching Services Configuration Guide
XC-361
Configuring LAN Emulation
LANE Implementation Considerations
Cisco has developed a fault tolerance mechanism known as simple server redundancy that eliminates
these single points of failure. Although this scheme is proprietary, no new protocol additions have been
made to the LANE subsystems.
Simple server redundancy uses multiple LECSs and multiple broadcast-and-unknown and LESs. You can
configure servers as backup servers, which will become active if a master server fails. The priority levels
for the servers determine which servers have precedence.
Refer to the “Configuring Fault-Tolerant Operation” section for details and notes on the Simple Server
Redundancy Protocol (SSRP).
LANE Implementation Considerations
The following sections contain information relevant to implementation:
•
Network Support
•
Hardware Support
•
Addressing
•
Rules for Assigning Components to Interfaces and Subinterfaces
Network Support
In this release, Cisco supports the following networking features:
•
Ethernet-emulated LANs
– Routing from one ELAN to another via IP, IPX, or AppleTalk
– Bridging between emulated LANs and between emulated LANs and other LANs
– DECnet, Banyan VINES, and XNS routed protocols
•
Token-Ring emulated LANs
– IP routing (fast switched) between emulated LANs and between a Token Ring ELAN and a
legacy LAN
– IPX routing between emulated LANs and between a Token Ring ELAN and a legacy LAN
– Two-port and multiport SRB (fast switched) between emulated LANs and between emulated
LANs and a Token Ring
– IP and IPX multiring
– SRB, source-route translational bridging (SR/TLB), and source-route transparent bridging
(SRT)
– AppleTalk for (IOS) TR-LANE and includes Appletalk fast switched routing.
– DECnet, Banyan VINES, and XNS protocols are not supported
Cisco’s implementation of LAN Emulation over 802.5 uses existing terminology and configuration
options for Token Rings, including SRB. For more information about configuring SRB, see the
chapter “Configuring Source-Route Bridging” in the Cisco IOS Bridging and IBM Networking
Configuration Guide. Transparent bridging and Advanced Peer-to-Peer Networking (APPN) are not
supported at this time.
•
Hot Standby Router Protocol (HSRP)
Cisco IOS Switching Services Configuration Guide
XC-362
Configuring LAN Emulation
LANE Implementation Considerations
For information about configuring APPN over Ethernet LANE, refer to the “Configuring APPN” chapter
in the Cisco IOS Bridging and IBM Networking Configuration Guide.
Hardware Support
This release of LANE is supported on the following platforms:
Note
•
Cisco 4500-M, Cisco 4700-M
•
Cisco 7200 series
•
Cisco 7500 series
Beginning with Cisco IOS Release 11.3, all commands supported on the Cisco 7500 series routers
are also supported on the Cisco 7000 series routers equipped with RSP7000. Token Ring LAN
emulation on Cisco 7000 series routers requires the RSP7000 upgrade. The RSP7000 upgrade
requires a minimum of 24 MB DRAM and 8 MB Flash memory.
The router must contain an ATM Interface Processor (AIP), ATM port adapter, or an NP-1A ATM
Network Processor Module (NPM). These modules provide an ATM network interface for the routers.
Network interfaces reside on modular interface processors, which provide a direct connection between
the high-speed Cisco Extended Bus (CxBus) and the external networks. The maximum number of AIPs,
ATM port adapters, or NPMs that the router supports depends on the bandwidth configured. The total
bandwidth through all the AIPs, ATM port adapters, or NPMs in the system should be limited to
200 Mbps full duplex—two Transparent Asynchronous Transmitter/Receiver Interfaces (TAXIs), one
Synchronous Optical Network (SONET) and one E3, or one SONET and one lightly used SONET.
This feature also requires one of the following switches:
•
Cisco LightStream 1010 (recommended)
•
Cisco LightStream 100
•
Any ATM switch with UNI 3.0/3.1 and ILMI support for communicating the LECS address
TR-LANE requires Cisco IOS Release 3.1(2) or later on the LightStream 100 switch and Cisco IOS
Release 11.1(8) or later on the LightStream 1010.
For a complete description of the routers, switches, and interfaces, refer to your hardware
documentation.
Addressing
On a LAN, packets are addressed by the MAC-layer address of the destination and source stations.
To provide similar functionality for LANE, MAC-layer addressing must be supported. Every LANE
client must have a MAC address. In addition, every LANE component (server, client, BUS, and LECS)
must have an ATM address that is different from that of all the other components.
All LANE clients on the same interface have the same, automatically assigned MAC address. That MAC
address is also used as the end-system identifier (ESI) part of the ATM address, as explained in the next
section. Although client MAC addresses are not unique, all ATM addresses are unique.
Cisco IOS Switching Services Configuration Guide
XC-363
Configuring LAN Emulation
LANE Implementation Considerations
LANE ATM Addresses
A LANE ATM address has the same syntax as an NSAP, but it is not a network-level address. It consists
of the following:
•
A 13-byte prefix that includes the following fields defined by the ATM Forum:
– AFI (Authority and Format Identifier) field (1 byte)
– DCC (Data Country Code) or ICD (International Code Designator) field (2 bytes)
– DFI field (Domain Specific Part Format Identifier) (1 byte)
– Administrative Authority field (3 bytes)
– Reserved field (2 bytes)
– Routing Domain field (2 bytes)
– Area field (2 bytes)
•
A 6-byte end-system identifier (ESI)
•
A 1-byte selector field
Method of Automatically Assigning ATM Addresses
We provide the following standard method of constructing and assigning ATM and MAC addresses for
use in a LECS’s database. A pool of MAC addresses is assigned to each ATM interface on the router. On
the Cisco 7200 series routers, Cisco 7500 series routers, Cisco 4500 routers, and Cisco 4700 routers, the
pool contains eight MAC addresses. For constructing ATM addresses, the following assignments are
made to the LANE components:
•
The prefix fields are the same for all LANE components in the router; the prefix indicates the
identity of the switch. The prefix value must be configured on the switch.
•
The ESI field value assigned to every client on the interface is the first of the pool of MAC addresses
assigned to the interface.
•
The ESI field value assigned to every server on the interface is the second of the pool of
MAC addresses.
•
The ESI field value assigned to the broadcast-and-unknown server on the interface is the third of the
pool of MAC addresses.
•
The ESI field value assigned to the configuration server is the fourth of the pool of MAC addresses.
•
The selector field value is set to the subinterface number of the LANE component—except for the
LECS, which has a selector field value of 0.
Because the LANE components are defined on different subinterfaces of an ATM interface, the value
of the selector field in an ATM address is different for each component. The result is a unique ATM
address for each LANE component, even within the same router. For more information about
assigning components to subinterfaces, see the “Rules for Assigning Components to Interfaces and
Subinterfaces” section later in this chapter.
For example, if the MAC addresses assigned to an interface are 0800.200C.1000 through
0800.200C.1007, the ESI part of the ATM addresses is assigned to LANE components as follows:
•
Any client gets the ESI 0800.200c.1000.
•
Any server gets the ESI 0800.200c.1001.
Cisco IOS Switching Services Configuration Guide
XC-364
Configuring LAN Emulation
LANE Implementation Considerations
•
The BUS gets the ESI 0800.200c.1002.
•
The LECS gets the ESI 0800.200c.1003.
Refer to the “Multiple Token Ring ELANs with Unrestricted Membership Example” and the “Multiple
Token Ring ELANs with Restricted Membership Example” sections for examples using MAC address
values as ESI field values in ATM addresses and for examples using subinterface numbers as selector
field values in ATM addresses.
Using ATM Address Templates
ATM address templates can be used in many LANE commands that assign ATM addresses to LANE
components (thus overriding automatically assigned ATM addresses) or that link client ATM addresses
to emulated LANs. The use of templates can greatly simplify the use of these commands. The syntax of
address templates, the use of address templates, and the use of wildcard characters within an address
template for LANE are very similar to those for address templates of ISO CLNS.
Note
E.164-format ATM addresses do not support the use of LANE ATM address templates.
LANE ATM address templates can use two types of wildcards: an asterisk (*) to match any single
character, and an ellipsis (...) to match any number of leading or trailing characters.
In LANE, a prefix template explicitly matches the prefix but uses wildcards for the ESI and selector
fields. An ESI template explicitly matches the ESI field but uses wildcards for the prefix and selector.
Table 43 indicates how the values of unspecified digits are determined when an ATM address template
is used:
Table 43
Values of Unspecified Digits in ATM Address Templates
Unspecified Digits In
Value Is
Prefix (first 13 bytes)
Obtained from ATM switch via Interim Local
Management Interface (ILMI)
ESI (next 6 bytes)
Filled with the slot MAC address1 plus
Selector field (last 1 byte)
•
0—LANE client
•
1—LES
•
2—LANE BUS
•
3—LECS
Subinterface number, in the range 0 through 255.
1. The lowest of the pool of MAC addresses assigned to the ATM interface plus a value that indicates the LANE component.
For the Cisco 7200 series routers, Cisco 7500 series routers, Cisco 4500 routers, and Cisco 4700 routers, the pool has eight
MAC addresses.
Cisco IOS Switching Services Configuration Guide
XC-365
Configuring LAN Emulation
LANE Configuration Task List
Rules for Assigning Components to Interfaces and Subinterfaces
The following rules apply to assigning LANE components to the major ATM interface and its
subinterfaces in a given router:
•
The LECS always runs on the major interface.
The assignment of any other component to the major interface is identical to assigning that
component to the 0 subinterface.
•
The server and the client of the same ELAN can be configured on the same subinterface in a router.
•
Clients of two different emulated LANs cannot be configured on the same subinterface in a router.
•
Servers of two different emulated LANs cannot be configured on the same subinterface in a router.
LANE Configuration Task List
Before you begin to configure LANE, you must decide whether you want to set up one or multiple
emulated LANs. If you set up multiple emulated LANs, you must also decide where the servers and
clients will be located, and whether to restrict the clients that can belong to each ELAN.
Bridged emulated LANs are configured just like any other LAN, in terms of commands and outputs.
Once you have made those basic decisions, you can proceed to configure LANE.
To configure LANE, perform the tasks described in the following sections:
•
Creating a LANE Plan and Worksheet
•
Configuring the Prefix on the Switch
•
Setting Up the Signalling and ILMI PVCs
•
Displaying LANE Default Addresses
•
Entering the LECS’s ATM Address on the Cisco Switch
•
Setting Up the LECS’s Database
•
Enabling the LECS
•
Setting Up LESs and Clients
Once LANE is configured, you can configure Multiprotocol over ATM (MPOA). For MPOA to work
with LANE, a LANE client must have an ELAN ID to work properly, a LANE client must have an ELAN
ID. To set up a LANE client for MPOA and give an ELAN ID perform the tasks described in the
following section:
•
Setting Up LANE Clients for MPOA
Although the sections described contain information about configuring SSRP fault tolerance, refer to the
“Configuring Fault-Tolerant Operation” section for detailed information about requirements and
implementation considerations.
Once LANE is configured, you can monitor and maintain the components in the participating routers by
completing the tasks described in the “Monitoring and Maintaining the LANE Components” section.
For configuration examples, see the “LANE Configuration Examples” section at the end of this chapter.
Cisco IOS Switching Services Configuration Guide
XC-366
Configuring LAN Emulation
LANE Configuration Task List
Creating a LANE Plan and Worksheet
Draw up a plan and a worksheet for your own LANE scenario, showing the following information and
leaving space for noting the ATM address of each of the LANE components on each subinterface of each
participating router:
•
The router and interface where the LECS will be located.
•
The router, interface, and subinterface where the LES and BUS for each ELAN will be located.
There can be multiple servers for each ELAN for fault-tolerant operation.
•
The routers, interfaces, and subinterfaces where the clients for each ELAN will be located.
•
The name of the default ELAN (optional).
•
The names of the emulated LANs that will have unrestricted membership.
•
The names of the emulated LANs that will have restricted membership.
The last three items in this list are very important; they determine how you set up each ELAN in the
LECS’s database.
Configuring the Prefix on the Switch
Before you configure LANE components on any Cisco 7200 series router, Cisco 7500 series router,
Cisco 4500 router, or Cisco 4700 router, you must configure the Cisco ATM switch with the ATM
address prefix to be used by all LANE components in the switch cloud. On the Cisco switch, the ATM
address prefix is called the node ID. Prefixes must be 26 digits long. If you provide fewer than 26 digits,
zeros are added to the right of the specified value to fill it to 26 digits.
To set the ATM address prefix on the Cisco LightStream 1010 Switch, use the following commands on
the switch beginning in global configuration mode:
Command
Purpose
Step 1
Router(config)# atm-address {atm-address |
prefix...}
Sets the local node ID (prefix of the ATM address).
Step 2
Router(config)# exit
Exits global configuration mode.
Step 3
Router# copy system:running-config
nvram:startup-config
Saves the configuration values permanently.
To set the ATM address prefix on the Cisco LightStream 100, use the following commands on the Cisco
switch:
Command
Purpose
Step 1
Router(config-route-map)# set local name ip-address
mask prefix
Sets the local node ID (prefix of the ATM address).
Step 2
Router(config-route-map)# save
Saves the configuration values permanently.
On the switches, you can display the current prefix by using the show network EXEC command.
Note
If you do not save the configured value permanently, it will be lost when the switch is reset or
powered off.
Cisco IOS Switching Services Configuration Guide
XC-367
Configuring LAN Emulation
LANE Configuration Task List
Setting Up the Signalling and ILMI PVCs
You must set up the signalling permanent virtual circuit (PVC) and the PVC that will communicate with
the ILMI on the major ATM interface of any router that participates in LANE.
Complete this task only once for a major interface. You do not need to repeat this task on the same
interface even though you might configure LESs and clients on several of its subinterfaces.
To set up these PVCs, use the following commands beginning in global configuration mode:
Command
Purpose
Step 1
Router(config-if)# interface atm
slot/0
Specifies the major ATM interface and enter interface configuration
mode:
Router(config-if)# interface atm
slot/port-adapter/0
Router(config-if)# interface atm
number
•
On the AIP for Cisco 7500 series routers; on the ATM port adapter
for Cisco 7200 series routers.
•
On the ATM port adapter for Cisco 7500 series routers.
•
On the NPM for Cisco 4500 and Cisco 4700 routers.
Step 2
Router(config-if)# atm pvc vcd vpi
vci qsaal
Sets up the signalling PVC that sets up and tears down switched virtual
circuits (SVCs); the vpi and vci values are usually set to 0 and 5,
respectively.
Step 3
Router(config-if)# atm pvc vcd vpi
vci ilmi
Sets up a PVC to communicate with the ILMI; the vpi and vci values
are usually set to 0 and 16, respectively.
Displaying LANE Default Addresses
You can display the LANE default addresses to make configuration easier. Complete this task for each
router that participates in LANE. This command displays default addresses for all ATM interfaces
present on the router. Write down the displayed addresses on your worksheet.
To display the default LANE addresses, use the following command in EXEC mode:
Command
Purpose
Router# show lane default-atm-addresses
Displays the LANE default addresses.
Entering the LECS’s ATM Address on the Cisco Switch
You must enter the LECS’s ATM address into the Cisco LightStream 100 or Cisco Lightstream 1010
ATM switch and save it permanently so that the value is not lost when the switch is reset or powered off.
You must specify the full 40-digit ATM address. Use the addresses on your worksheet that you obtained
from the previous task.
If you are configuring SSRP or Fast Simple Server Redundancy Protocol (FSSRP), enter the multiple
LECS addresses into the end ATM switches. The switches are used as central locations for the list of
LECS addresses. LANE components connected to the switches obtain the global list of LECS addresses
from the switches.
Cisco IOS Switching Services Configuration Guide
XC-368
Configuring LAN Emulation
LANE Configuration Task List
Depending on which type of switch you are using, perform one of the tasks in the following sections:
•
Entering the ATM Addresses on the Cisco LightStream 1010 ATM Switch
•
Entering the ATM Addresses on the Cisco LightStream 100 ATM Switch
Entering the ATM Addresses on the Cisco LightStream 1010 ATM Switch
On the Cisco LightStream 1010 ATM switch, the LECS address can be specified for a port or for the
entire switch.
To enter the LECS addresses on the Cisco LightStream 1010 ATM switch for the entire switch, use the
following commands beginning in global configuration mode:
Command
Purpose
Step 1
Router(config)# atm lecs-address-default
lecsaddress [sequence #]1
Specifies the LECS’s ATM address for the entire
switch. If you are configuring SSRP, include the ATM
addresses of all the LECSs.
Step 2
Router(config)# exit
Exits global configuration mode.
Step 3
Router# copy system:running-config
nvram:startup-config
Saves the configuration value permanently.
1.Refer to the LightStream 1010 ATM Switch Command Reference for further information about this command.
To enter the LECS addresses on the Cisco LightStream 1010 ATM switch per port, use the following
commands beginning in interface configuration mode:
Command
Purpose
Step 1
Router(config-if)# atm lecs-address lecsaddress
[sequence #]1
Specifies the LECS’s ATM address for a port. If you
are configuring SSRP, include the ATM addresses of
all the LECSs.
Step 2
Router(config-if)# Ctrl-Z
Exits interface configuration mode.
Step 3
Router# copy system:running-config
nvram:startup-config
Saves the configuration value permanently.
1.Refer to the LightStream 1010 ATM Switch Command Reference for further information about this command.
Entering the ATM Addresses on the Cisco LightStream 100 ATM Switch
To enter the LECS’s ATM address into the Cisco LightStream 100 ATM switch and save it permanently,
use the following commands in privileged EXEC mode:
Command
Purpose
Step 1
Router# set configserver index atm-address
Specifies the LECS’s ATM address. If you are
configuring SSRP, repeat this command for each LECS
address. The index value determines the priority. The
highest priority is 0. There can be a maximum of 4
LECSs.
Step 2
Router# save
Saves the configuration value permanently.
Cisco IOS Switching Services Configuration Guide
XC-369
Configuring LAN Emulation
LANE Configuration Task List
Setting Up the LECS’s Database
The LECS’s database contains information about each ELAN, including the ATM addresses of the LESs.
You can specify one default ELAN in the database. The LECS will assign any client that does not request
a specific ELAN to the default ELAN.
Emulated LANs are either restricted or unrestricted. The LECS will assign a client to an unrestricted
ELAN if the client specifies that particular ELAN in its configuration. However, the LECS will only
assign a client to a restricted ELAN if the client is specified in the database of the LECS as belonging
to that ELAN. The default ELAN must have unrestricted membership.
If you are configuring fault tolerance, you can have any number of servers per ELAN. Priority is
determined by entry order; the first entry has the highest priority, unless you override it with the index
option.
To set up the database, complete the tasks in the following sections as appropriate for your ELAN plan
and scenario:
•
Setting Up the Database for the Default ELAN Only
•
Setting Up the Database for Unrestricted-Membership Emulated LANs
•
Setting Up the Database for Restricted-Membership LANs
Setting Up the Database for the Default ELAN Only
When you configure a router as the LECS for one default ELAN, you provide a name for the database,
the ATM address of the LES for the ELAN, and a default name for the ELAN. In addition, you indicate
that the LECS’s ATM address is to be computed automatically.
When you configure a database with only a default unrestricted ELAN, you do not have to specify where
the LANE clients are located. That is, when you set up the LECS’s database for a single default ELAN,
you do not have to provide any database entries that link the ATM addresses of any clients with the
ELAN name. All of the clients will be assigned to the default ELAN.
To set up the LECS for the default ELAN, use the following commands beginning in global configuration
mode:
Command
Purpose
Step 1
Router(config)# lane database database-name
Creates a named database for the LECS.
Step 2
Router(lane-config-dat)# name elan-name
server-atm-address atm-address [index number]
In the configuration database, binds the name of the ELAN
to the ATM address of the LES.
If you are configuring SSRP, repeat this step for each
additional server for the same ELAN. The index
determines the priority. The highest priority is 0.
Step 3
Router(lane-config-dat)# name elan-name
local-seg-id segment-number
If you are configuring a Token Ring ELAN, assigns a
segment number to the emulated Token Ring LAN in the
configuration database.
Step 4
Router(lane-config-dat)# default-name
elan-name
In the configuration database, provides a default name for
the ELAN.
Step 5
Router(lane-config-dat)# exit
Exits from database configuration mode and return to
global configuration mode.
Cisco IOS Switching Services Configuration Guide
XC-370
Configuring LAN Emulation
LANE Configuration Task List
In Step 2, enter the ATM address of the server for the specified ELAN, as noted in your worksheet and
obtained in the “Displaying LANE Default Addresses” section.
You can have any number of servers per ELAN for fault tolerance. Priority is determined by entry order.
The first entry has the highest priority unless you override it with the index option.
If you are setting up only a default ELAN, the elan-name value in Steps 2 and 3 is the same as the default
ELAN name you provide in Step 4.
To set up fault-tolerant operation, see the “Configuring Fault-Tolerant Operation” section later in
this chapter.
Setting Up the Database for Unrestricted-Membership Emulated LANs
When you set up a database for unrestricted emulated LANs, you create database entries that link the
name of each ELAN to the ATM address of its server.
However, you may choose not to specify where the LANE clients are located. That is, when you set up
the LECS’s database, you do not have to provide any database entries that link the ATM addresses or
MAC addresses of any clients with the ELAN name. The LECS will assign the clients to the emulated
LANs specified in the client’s configurations.
To configure a router as the LECS for multiple emulated LANs with unrestricted membership, use the
following commands beginning in global configuration mode:
Command
Purpose
Step 1
Router(config)# lane database database-name
Creates a named database for the LECS.
Step 2
Router(lane-config-dat)# name elan-name1
server-atm-address atm-address [index number]
In the configuration database, binds the name of the first
ELAN to the ATM address of the LES for that ELAN.
If you are configuring SSRP, repeat this step with the same
ELAN name but with different server ATM addresses for
each additional server for the same ELAN. The index
determines the priority. The highest priority is 0.
Step 3
Router(lane-config-dat)# name elan-name2
server-atm-address atm-address [index number]
In the configuration database, binds the name of the second
ELAN to the ATM address of the LES.
If you are configuring SSRP, repeat this step with the same
ELAN name but with different server ATM addresses for
each additional server for the same ELAN. The index
determines the priority. The highest priority is 0.
Repeat this step, providing a different ELAN name and ATM
address for each additional ELAN in this switch cloud.
Step 4
Router(lane-config-dat)# name elan-name1
local-seg-id segment-number
For a Token Ring ELAN, assigns a segment number to the
first emulated Token Ring LAN in the configuration
database.
Step 5
Router(lane-config-dat)# name elan-name2
local-seg-id segment-number
For Token Ring emulated LANs, assigns a segment number
to the second emulated Token Ring LAN in the configuration
database.
Repeat this step, providing a different ELAN name and
segment number for each additional source-route bridged
ELAN in this switch cloud.
Cisco IOS Switching Services Configuration Guide
XC-371
Configuring LAN Emulation
LANE Configuration Task List
Command
Purpose
Step 6
Router(lane-config-dat)# default-name
elan-name1
(Optional) Specifies a default ELAN for LANE clients not
explicitly bound to an ELAN.
Step 7
Router(lane-config-dat)# exit
Exits from database configuration mode and return to global
configuration mode.
In the preceding steps, enter the ATM address of the server for the specified ELAN, as noted in your
worksheet and obtained in the “Displaying LANE Default Addresses” section.
To set up fault-tolerant operation, see the “Configuring Fault-Tolerant Operation” section later in this
chapter.
Setting Up the Database for Restricted-Membership LANs
When you set up the database for restricted-membership emulated LANs, you create database entries
that link the name of each ELAN to the ATM address of its server.
However, you must also specify where the LANE clients are located. That is, for each
restricted-membership ELAN, you provide a database entry that explicitly links the ATM address or
MAC address of each client of that ELAN with the name of that ELAN.
The client database entries specify which clients are allowed to join the ELAN. When a client requests
to join an ELAN, the LECS consults its database and then assigns the client to the ELAN specified in
the LECS’s database.
When clients for the same restricted-membership ELAN are located in multiple routers, each client’s
ATM address or MAC address must be linked explicitly with the name of the ELAN. As a result, you
must configure as many client entries (at Steps 6 and 7, in the following procedure) as you have clients
for emulated LANs in all the routers. Each client will have a different ATM address in the database
entries.
To set up the LECS for emulated LANs with restricted membership, use the following commands
beginning in global configuration mode:
Command
Purpose
Step 1
Router(config)# lane database database-name
Creates a named database for the LECS.
Step 2
Router(lane-config-dat)# name elan-name1
server-atm-address atm-address restricted
[index number]
In the configuration database, binds the name of the first
ELAN to the ATM address of the LES for that ELAN.
If you are configuring SSRP, repeat this step with the same
ELAN name but with different server ATM addresses for
each additional server for the same ELAN. The index
determines the priority. The highest priority is 0.
Step 3
Router(lane-config-dat)# name elan-name2
server-atm-address atm-address restricted
[index number]
In the configuration database, binds the name of the second
ELAN to the ATM address of the LES.
If you are configuring SSRP, repeat this step with the same
ELAN name but with different server ATM addresses for
each additional server for the same ELAN. The index
determines the priority. The highest priority is 0.
Repeat this step, providing a different name and a different
ATM address, for each additional ELAN.
Cisco IOS Switching Services Configuration Guide
XC-372
Configuring LAN Emulation
LANE Configuration Task List
Command
Purpose
Step 4
Router(lane-config-dat)# name elan-name1
local-seg-id segment-number
For a Token Ring ELAN, assigns a segment number to the
first emulated Token Ring LAN in the configuration
database.
Step 5
Router(lane-config-dat)# name elan-name2
local-seg-id segment-number
If you are configuring Token Ring emulated LANs, assigns a
segment number to the second emulated Token Ring LAN in
the configuration database.
Repeat this step, providing a different ELAN name and
segment number for each additional source-route bridged
ELAN in this switch cloud.
Step 6
Router(lane-config-dat)# client-atm-address
atm-address-template name elan-name1
Adds a database entry associating a specific client’s ATM
address with the first restricted-membership ELAN.
Repeat this step for each of the clients of the first
restricted-membership ELAN.
Step 7
Router(lane-config-dat)# client-atm-address
atm-address-template name elan-name2
Adds a database entry associating a specific client’s ATM
address with the second restricted-membership ELAN.
Repeat this step for each of the clients of the second
restricted-membership ELAN.
Repeat this step, providing a different name and a different
list of client ATM address, for each additional ELAN.
Step 8
Router(lane-config-dat)# exit
Exits from database configuration mode and return to global
configuration mode.
To set up fault-tolerant operation, see the “Configuring Fault-Tolerant Operation” section later in this
chapter.
Enabling the LECS
Once you have created the database, you can enable the LECS on the selected ATM interface and router
by using the following commands beginning in global configuration mode:
Command
Step 1
Purpose
If you are not currently configuring the interface, specifies
the major ATM interface where the LECS is located.
Router(config)# interface atm
slot/0[.subinterface-number]
Router(config)# interface atm
slot/port-adapter/0[.subinterface-number]
•
On the AIP for Cisco 7500 series routers; On the ATM
port adapter for Cisco 7200 series routers.
•
On the ATM port adapter for Cisco 7500 series routers.
•
On the NPM for Cisco 4500 and Cisco 4700 routers.
Router(config)# interface atm
number[.subinterface-number]
Step 2
Router(config-if)# lane config database
database-name
Link the LECS’s database name to the specified major
interface, and enable the LECS.
Cisco IOS Switching Services Configuration Guide
XC-373
Configuring LAN Emulation
LANE Configuration Task List
Command
Purpose
Step 3
Router(config-if)# lane config
auto-config-atm-address
Router(config-if)# lane config
auto-config-atm-address
or
Router(config-if)# lane config
fixed-config-atm-address
Specifies how the LECS’s ATM address will be computed.
You may opt to choose one of the following scenarios:
The LECS will participate in SSRP and the address is
computed by the automatic method.
The LECS will participate in SSRP, and the address is
computed by the automatic method. If the LECS is the
master, the fixed address is also used.
Router(config-if)# lane config
fixed-config-atm-address
The LECS will not participate in SSRP, the LECS is the
master, and only the well-known address is used.
Router(config-if)# lane config
config-atm-address atm-address-template
The LECS will participate in SSRP and the address is
computed using an explicit, 20-byte ATM address.
Step 4
exit
Exits interface configuration mode.
Step 5
Ctrl-Z
Returns to EXEC mode.
Step 6
copy system:running-config
nvram:startup-config
Saves the configuration.
Setting Up LESs and Clients
For each router that will participate in LANE, set up the necessary servers and clients for each ELAN;
then display and record the server and client ATM addresses. Be sure to keep track of the router interface
where the LECS will eventually be located.
You can set up servers for more than one ELAN on different subinterfaces or on the same interface of a
router, or you can place the servers on different routers.
When you set up a server and BUS on a router, you can combine them with a client on the same
subinterface, a