Академический Документы
Профессиональный Документы
Культура Документы
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
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 UCBs 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 Thats 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, Cisco Systems, Inc. All rights reserved.
C O N T E N T S
xxv
Supporting Documents and Resources New and Changed Information Document Conventions Cisco.com
xxx xxx xxxi xxxi xxxi xxxiii xxxiii xxix xxx xxviii
xxviii
Documentation CD-ROM Ordering Documentation Documentation Feedback Using Cisco IOS Software Getting Help
xxxiv
Example: How to Find Command Options Using the no and default Forms of Commands Saving Configuration Changes Identifying Supported Platforms Using Feature Navigator
xxxviii
xxxv xxxvii
xxxviii
iii
Contents
Basic Router Platform Architecture and Processes Cisco Routing and Switching Processes Routing Processes Switching Processes Basic Switching Paths Process Switching Fast Switching CEF Switching dCEF Switching
XC-8 XC-8 XC-6 XC-7 XC-6
Platform and Switching Path Correlation Features That Affect Performance Queueing
XC-11 XC-11 XC-10
Fast Switching Configuration Task List Enabling AppleTalk Fast Switching Enabling IP Fast Switching
XC-14
XC-13 XC-13
Enabling Fast Switching on the Same IP Interface Enabling SMDS Fast Switching
XC-15 XC-15
XC-14 XC-15
Enabling Fast Switching of IPX Directed Broadcast Packets Disabling Fast Switching for Troubleshooting Disabling AppleTalk Fast Switching Disabling DECnet Fast Switching Disabling IPX Fast Switching Disabling XNS Fast Switching Disabling Banyan VINES Fast Switching
XC-16 XC-17
XC-16 XC-16
XC-17
iv
Contents
Controlling Route Cache Invalidation for IP Displaying System and Network Statistics Adjusting the Route Cache for IPX
XC-18
Controlling IPX Route Cache Size Padding Odd-Length IPX Packets Cisco Express Forwarding Overview Benefits
XC-21 XC-22 XC-22
XC-18 XC-19
CEF Components
CEF and dCEF Additional Capabilities TMS and CEF Nonrecursive Accounting TMS Data
XC-27
How Backbone Routers Collect TMS Data Viewing the TMS Data
XC-30
XC-27
XC-30 XC-31
Viewing the TMS Data by Reading the Virtual Files That Reside on the Backbone Router Viewing TMS Data Through the show ip cef Command Viewing the BGP Neighbor Autonomous Systems Network Services Engine Virtual Profile CEF
XC-35 XC-34 XC-33 XC-33
Contents
XC-37
XC-39 XC-39
Configuring per-Destination Load Balancing Configuring per-Packet Load Balancing Selecting a Load Balancing Algorithm Configuring Network Accounting for CEF Enabling Network Accounting for CEF Using the NDA for TMS Data Collection Verifying Network Accounting Information Configuring Distributed Tunnel Switching for CEF Configuring the Network Services Engine Configuring the PXF Processor Verifying the PXF Processor Monitoring the PXF Processor
XC-45 XC-45 XC-46 XC-45 XC-40 XC-41 XC-41
XC-40
XC-41
XC-46 XC-47
Configuring Virtual Profile Switching for CEF Verifying Virtual Profile Interfaces Verifying CEF
XC-47 XC-48 XC-47
Troubleshooting Tips
Enabling CEF Consistency Checkers Displaying CEF Table Inconsistencies Clearing CEF Table Inconsistencies IP CEF Nonrecursive Accounting Example NetFlow Switching NetFlow Switching Overview Accounting Statistics NetFlow Cache NetFlow Data Format
XC-53 XC-53 XC-53
XC-49
XC-54
vi
Contents
XC-57
Autonomous System Aggregation Scheme Destination Prefix Aggregation Scheme Prefix Aggregation Scheme
XC-61 XC-62 XC-63
Protocol Port Aggregation Scheme Source Prefix Aggregation Scheme Setting a NetFlow Minimum Mask NetFlow Policy Routing Benefits
XC-66 XC-67 XC-69 XC-69 XC-66
XC-64
Restrictions
XC-70
Exporting NetFlow Switching Statistics Managing NetFlow Switching Statistics Configuring an Aggregation Cache
XC-71 XC-71
XC-72
Verifying Aggregation Cache Configuration and Data Export Configuring the Minimum Mask of a Prefix Aggregation Scheme
XC-73 XC-74
Configuring the Minimum Mask of a Destination-Prefix Aggregation Scheme Configuring the Minimum Mask of a Source-Prefix Aggregation Scheme Monitoring and Maintaining Minimum Masks for Aggregation Schemes Configuring NetFlow Policy Routing
XC-75 XC-76
XC-74
XC-75 XC-75
vii
Contents
NetFlow Aggregation Configuration Examples Autonomous System Configuration Example Destination Prefix Configuration Example Prefix Configuration Example
XC-78
Protocol Port Configuration Example Source Prefix Configuration Example Prefix Aggregation Scheme Example
Destination-Prefix Aggregation Scheme Example Source-Prefix Aggregation Scheme Example NetFlow Policy Routing Example Multiprotocol Label Switching Multiprotocol Label Switching Overview MPLS/Tag Switching Terminology Benefits
XC-84 XC-85 XC-86 XC-84 XC-83 XC-79
XC-79
Why Use MPLS Traffic Engineering? How MPLS Traffic Engineering Works Mapping Traffic into Tunnels
XC-88
XC-88
Additional Enhancements to SPF Computation Using Configured Tunnel Metrics Making the Transition from an IS-IS Network to a New Technology New Extensions for the IS-IS Routing Protocol The Problem in Theory The Problem in Practice
XC-92 XC-92 XC-92 XC-91
XC-90
First Solution for Making the Transition from an IS-IS Network to a New Technology Second Solution for Making the Transition from an IS-IS Network to a New Technology
XC-93 XC-94
viii
Contents
XC-94 XC-94
XC-98
XC-100 XC-100
Interautonomous Systems for MPLS VPNs Routing Between Autonomous Systems HSRP Support for MPLS VPNS MPLS Quality of Service
XC-111 XC-111
Specifying the QoS in the IP Precedence Field MPLS Label Switch Controller
XC-114 XC-114
XC-112
Using Controlled ATM Switch Ports as Router Interfaces Using the MPLS LSC as a Label Edge Device Creating Virtual Trunks
XC-117 XC-116
XC-116
Typical ATM Hybrid Network with Virtual Trunks Virtual Trunk Configuration Using LSC Redundancy
XC-119 XC-120 XC-121 XC-118
XC-117
How LSC Redundancy Differs from Router and Switch Redundancy How the LSC, ATM Switch, and VSI Work Together Implementing LSC Redundancy Implementation Considerations
XC-125 XC-129 XC-125
XC-121
Reducing the Number of Label Switch Paths Created in an MPLS Network Disabling the LSC from Acting as an Edge LSR
XC-134
XC-131 XC-131
ix
Contents
Using the Cisco 6400 Universal Access Concentrator as an MPLS LSC Cisco 6400 UAC Architectural Overview Control VC Setup for MPLS LSC Functions Supporting ATM Forum Protocols MPLS Egress NetFlow Accounting
XC-140 XC-135
XC-134
XC-136
Configuring the Cisco 6400 UAC to Perform Basic MPLS LSC Operations
XC-140 XC-143
XC-139
Case 1Enable MPLS Incrementally in a Network Case 2Route Labeled Packets to Network A Only Configuring a Router for MPLS Forwarding Configuring MPLS Traffic Engineering Configuring a Device to Support Tunnels
XC-147
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 MPLS Traffic Engineering Paths Case 1Engineer Traffic Across a Path Case 2Establish a Backup Path Defining VPNs
XC-154 XC-155 XC-155 XC-156 XC-156 XC-157 XC-151 XC-152 XC-149 XC-150 XC-150
XC-149
XC-153 XC-154
Configuring Static Route PE to CE Routing Sessions Configuring MPLS VPNs with Cable Interfaces Restrictions
XC-158 XC-159
XC-157
Defining Subinterfaces on a Physical Cable Interface and Assigning VRFs Configuring Cable Interface Bundles
XC-161 XC-162
XC-160
Contents
Configuring MPLS in the P Routers in the Provider Core Verifying the MPLS VPN Configuration
XC-163
XC-162
XC-163
Configuring EBGP Routing for the Exchange of VPN Routes Between Autonomous Systems XC-164 Configuring EBGP Routing for the Exchange of VPN Routes Between Subautonomous Systems in a Confederation XC-164 Displaying VPN-IPv4 LFIB Entries Verifying VPN Operation LSRs
XC-167 XC-167 XC-168 XC-169 XC-169 XC-170 XC-170 XC-166 XC-167 XC-166
Setting the MPLS Experimental Field Value Configuring the Ingress MPLS Router
Using the Modular QoS CLI to Configure the Ingress Label Switching Router Configuring a Class Map to Classify IP Packets
XC-171 XC-172 XC-172
XC-171
Configuring a Policy Map to Set the MPLS Experimental Field Configuring the Input Interface to Attach the Service Policy Using CAR to Configure the Ingress Label Switching Router Configuring a Rate Limit Access List for Classifying IP Packets Configuring the Output IP QoS of the Packet
XC-173 XC-174 XC-174 XC-175 XC-172
XC-173 XC-173
Configuring a Rate-Limit on an Input Interface to Set MPLS Packets Configuring PVC Mode in a Non-MPLS-Enabled Core Configuring Multi-VC Mode in a MPLS-Enabled Core Configuring Multi-VCs Using the Cos-Map Function Verifying QoS Operation
XC-176
XC-175
xi
Contents
Configuring the MPLS Label Switch Controller Configuring the Cisco 6400 UAC LSC
XC-176 XC-176
Configuring MPLS on the Cisco 7200 Series LSCs for BPX and IGX Switches
XC-177 XC-178
Configuring Cisco 6400 UAC NRP as an MPLS LSC Verifying MPLS LSC Configuration
XC-180 XC-180 XC-181 XC-181
Configuring the Cisco 6400 UAC NSP for MPLS Connectivity to BPX Configuring MPLS Egress NetFlow Accounting Enabling MPLS Egress NetFlow Accounting Configuring NetFlow Aggregation Cache
XC-178
Verifying MPLS Egress NetFlow Accounting Configuration Verifying Configuration of MPLS Forwarding MPLS Configuration Examples
XC-187 XC-186
Enabling MPLS Incrementally in a Network Example Selecting the Destination Prefixes and Paths Example Displaying MPLS LDP Binding Information Example Displaying MPLS Interface Information Example Enabling LSP Tunnel Signalling Example Configuring an LSP Tunnel Example
XC-191
XC-187 XC-187
XC-189
XC-191
Displaying the LSP Tunnel Information Example Configuring MPLS Traffic Engineering 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 Configuring a Traffic Engineering Filter and Route Example
xii
Contents
Subinterface Definition on Bundle Master Example Cable Interface Bundle Master Configuration Example
Configuring EBGP Routing to Exchange VPN Routes Between Autonomous Systems in a Confederation XC-212 Implementing MPLS QoS Example Configuring CEF Example Running IP on Router 2 Example Running IP on Router 1 Example
XC-219 XC-219 XC-220 XC-220 XC-220 XC-221 XC-223 XC-224 XC-225 XC-225
Running MPLS on Router 4 Example Running MPLS on Router 3 Example Running MPLS on Router 5 Example Running MPLS on Router 6 Example Configuring ATM Switch 2 Example Configuring ATM Switch 1 Example Configuring an MPLS LSC Examples Configuring ATM-LSRs Example Configuring Multi-VCs Example
Configuring ATM LSRs Through ATM Network Using Cisco 7200 LSCs Implementing Virtual Trunking Example XC-234 Configuring ATM LSRs Through ATM Network Using Cisco 6400 NRP LSCs Implementing Virtual Trunking Example XC-237 Configuring LSC Hot Redundancy Example
XC-240 XC-245 XC-246 XC-247
Configuring an Interface Using Two VSI Partitions Example Using an Access List to Control the Creation of Headend VCs MPLS Egress NetFlow Accounting Example
XC-249
xiii
Contents
Restrictions on Using IP Router Commands with MLS Enabled Introduction to IP Multicast MLS IP Multicast MLS Components Layer 3 Multicast MLS Cache IP Multicast MLS Flow Mask
XC-259 XC-259
XC-261 XC-261
XC-261
Layer 3-Switched Multicast Packet Rewrite Partially and Completely Switched Flows Introduction to IPX MLS IPX MLS Components IPX MLS Flows MLS Cache
XC-264 XC-264 XC-265 XC-265 XC-263 XC-264
XC-262 XC-263
XC-268
Access List Impact on Flow Masks Reflexive Access Lists IP Accounting Data Encryption Policy Route Maps
XC-269 XC-269 XC-269 XC-269
xiv
Contents
TCP Intercept
XC-269 XC-269
Network Address Translation Committed Access Rate Maximum Transmission Unit Configuring IP Multilayer Switching Configuring and Monitoring MLS Configuring MLS on a Router Monitoring MLS
XC-273
XC-274 XC-274
Router Configuration with a Standard Access List Example Router Configuration with an Extended Access List Example Configuring IP Multicast Multilayer Switching Prerequisites Restrictions
XC-279 XC-280 XC-280 XC-279
Access List Restrictions and Guidelines Configuring and Monitoring IP Multicast MLS Enabling IP Multicast Routing Enabling IP PIM
XC-282 XC-282 XC-282
XC-281 XC-281
Specifying a Management Interface IP Multicast MLS Configuration Examples Network Topology Example
XC-283 XC-283
XC-284
Operation Before IP Multicast MLS Example Operation After IP Multicast MLS Example Router Configuration Switch Configuration
XC-285 XC-286
XC-285 XC-285
xv
Contents
XC-286
Operation Before IP Multicast MLS Example Operation After IP Multicast MLS Example Configuring IPX Multilayer Switching Prerequisites Restrictions
XC-291 XC-292 XC-292 XC-291
XC-288 XC-288
Restrictions on Interaction of IPX MLS with Other Features Restriction on Maximum Transmission Unit Size IPX MLS Configuration Task List
XC-293 XC-294 XC-293
XC-293
Adding an IPX MLS Interface to a VTP Domain Assigning a VLAN ID to a Router Interface Enabling IPX MLS on a Router Interface Verifying IPX MLS on the Router Troubleshooting Tips
XC-296 XC-295
XC-294
XC-295
Monitoring and Maintaining IPX MLS on the Router IPX MLS Configuration Examples
XC-296 XC-297
XC-296
Complex IPX MLS Network Examples Operation Before IPX MLS Example Operation After IPX MLS Example Switch A Configuration Switch B Configuration Switch C Configuration MLS-RP Configuration
XC-299 XC-299 XC-300 XC-300
XC-301 XC-301
xvi
Contents
Multicast Distributed Switching Configuring Multicast Distributed Switching MDS Configuration Task List Enabling MDS
XC-306 XC-306 XC-306 XC-305
Monitoring and Maintaining MDS MDS Configuration Example VLANs Routing Between VLANs Overview What Is a VLAN? Security
XC-311 XC-312 XC-307
XC-311
LAN Segmentation
XC-313
XC-313
Network Management
Network Monitoring Using SNMP Communication Between VLANs Relaying Function Native VLAN PVST+
XC-316 XC-317 XC-314 XC-316
XC-313
XC-317
Communicating Between VLANs Inter-Switch Link Protocol IEEE 802.10 Protocol IEEE 802.1Q Protocol ATM LANE Protocol VLAN Interoperability VLAN Translation
XC-319 XC-319 XC-319
XC-318 XC-319
XC-320
Inter-VLAN Communications
XC-321
XC-321
xvii
Contents
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation Overview of the ISL Protocol Frame Tagging in ISL
XC-323 XC-323 XC-324 XC-324
XC-323
ISL Encapsulation Configuration Task List Configuring AppleTalk Routing over ISL Enabling AppleTalk Routing
Defining the VLAN Encapsulation Format Configuring AppleTalk on the Subinterface Configuring Banyan VINES Routing over ISL Enabling Banyan VINES Routing
XC-326
XC-326
Defining the VLAN Encapsulation Format Configuring DECnet Routing over ISL Enabling DECnet Routing
XC-327 XC-326
XC-326 XC-326
Defining the VLAN Encapsulation Format Configuring DECnet on the Subinterface Defining the Encapsulation Format Defining the IP Address Enabling HSRP
XC-329 XC-330 XC-329
Defining the VLAN Encapsulation Format Assigning IP Address to Network Interface Enabling NetWare Routing
XC-332
Configuring IPX Routing on 802.10 VLANs over ISL Defining the VLAN Encapsulation Format Configuring NetWare on the Subinterface Configuring IPX Routing over TRISL Enabling NetWare Routing
XC-332 XC-333
XC-332 XC-332
XC-333 XC-333
xviii
Contents
XC-334
Enabling VIP Distributed Switching Configuring XNS Routing over ISL Enabling XNS Routing
XC-336
XC-335
Defining the VLAN Encapsulation Format Configuring XNS on the Subinterface Configuring CLNS Routing over ISL Enabling CLNS Routing
XC-337 XC-336
XC-336
XC-336
Defining the VLAN Encapsulation Format Configuring CLNS on the Subinterface Configuring IS-IS Routing over ISL Enabling IS-IS Routing
XC-338 XC-337
XC-337 XC-337
Defining the VLAN Encapsulation Format Configuring IS-IS on the Subinterface ISL Encapsulation Configuration Examples
XC-338
XC-338 XC-338
AppleTalk Routing over ISL Configuration Examples DECnet Routing over ISL Configuration Example HSRP over ISL Configuration Example
XC-340
XC-339 XC-340
IP Routing with RIF Between TrBRF VLANs Example IPX Routing over ISL Configuration Example
XC-344
XC-342 XC-343
IP Routing Between a TRISL VLAN and an Ethernet ISL VLAN Example IPX Routing on FDDI Interfaces with SDE Example
XC-345
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
XC-348 XC-348 XC-348 XC-346
XC-345
xix
Contents
Configuring Routing Between VLANs with IEEE 802.10 Encapsulation Configuring AppleTalk Routing over IEEE 802.10 Enabling AppleTalk Routing
XC-350 XC-350 XC-351 XC-351 XC-351 XC-349
XC-349
Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation IEEE 802.1Q Encapsulation VLANs Configuration Task List Configuring AppleTalk Routing over IEEE 802.1Q Enabling AppleTalk Routing
XC-354 XC-355 XC-355 XC-353 XC-354
XC-353
Configuring AppleTalk on the Subinterface Defining the VLAN Encapsulation Format Configuring IP Routing over IEEE 802.1Q Enabling IP Routing
XC-355 XC-355
Defining the VLAN Encapsulation Format Configuring IPX Routing over IEEE 802.1Q Enabling NetWare Routing
XC-357
XC-356 XC-356
Configuring a VLAN for a bridge-group with Default VLAN1 Configuring a VLAN for a bridge-group as a Native VLAN Monitoring and Maintaining VLAN Subinterfaces IEEE 802.1Q Encapsulation Configuration Examples Configuring AppleTalk over IEEE 802.1Q Example Configuring IP Routing over IEEE 802.1Q Example Configuring IPX Routing over IEEE 802.1Q Example
XC-358 XC-358 XC-359 XC-359 XC-359
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
XC-362 XC-360 XC-361
XC-359
XC-359
xx
Contents
LANE Components
LANE Operation and Communication Client Joining an ELAN Address Resolution Multicast Traffic Typical LANE Scenarios Single ELAN Scenario Multiple ELAN Scenario Configuring LAN Emulation LANE on ATM
XC-371 XC-372 XC-372 XC-372 XC-371 XC-368 XC-369 XC-369 XC-370 XC-367 XC-368
XC-373
XC-375 XC-375
Method of Automatically Assigning ATM Addresses Using ATM Address Templates LANE Configuration Task List
XC-377 XC-378 XC-378 XC-379 XC-376
Rules for Assigning Components to Interfaces and Subinterfaces Creating a LANE Plan and Worksheet Configuring the Prefix on the Switch Displaying LANE Default Addresses Setting Up the Signalling and ILMI PVCs
XC-377
Entering the ATM Addresses on the Cisco LightStream 1010 ATM Switch Entering the ATM Addresses on the Cisco LightStream 100 ATM Switch
xxi
Contents
Setting Up the Database for Unrestricted-Membership Emulated LANs Setting Up the Database for Restricted-Membership LANs Enabling the LECS
XC-384 XC-385 XC-386 XC-383
Setting Up the Server, BUS, and a Client on a Subinterface Setting Up Only a Client on a Subinterface Setting Up LANE Clients for MPOA Configuring Fault-Tolerant Operation
XC-388 XC-388 XC-388 XC-389 XC-386
XC-387
Simple Server Redundancy Requirements Redundant Configuration Servers Redundant Servers and BUSs Implementation Considerations
XC-389
XC-392
XC-394 XC-395
Default Configuration for a Single Ethernet ELAN with a Backup LECS and LES Example Multiple Token Ring ELANs with Unrestricted Membership Example Router 1 Configuration Router 2 Configuration Router 3 Configuration Router 4 Configuration Router 1 Configuration Router 2 Configuration Router 3 Configuration Router 4 Configuration Router 1 Configuration Router 2 Configuration
XC-397 XC-398 XC-398 XC-398 XC-399 XC-396
xxii
Contents
TR-LANE with Multiport SRB Example Router 1 Configuration Router 2 Configuration Router 1 Configuration Router 2 Configuration Router 3 Configuration
XC-403 XC-404
XC-403
XC-405
Disabling LANE Flush Process Example Configuring Token Ring LAN Emulation Token Ring LANE on ATM Benefits
XC-410 XC-410 XC-409
XC-409
Token Ring LANE Configuration Task List Creating a LANE Plan and Worksheet Default LANE Configuration
XC-414 XC-414
Configuring the ATM Module from the Terminal Configuring the ATM Module from NVRAM Setting Up the Signalling PVC
XC-418 XC-418
XC-417 XC-417
Configuring the Prefix on the LightStream 1010 Switch Displaying LANE Default Addresses Configuring the LECS Database
XC-418
Setting Up the Database for Unrestricted-Membership ELANs Setting Up the Database for Restricted-Membership ELANs Binding the LECS to the ATM Interface Setting Up a LES/BUS and a LEC Setting Up a LEC for an ELAN Setting Up the LES/BUS for an ELAN
XC-425 XC-424 XC-424 XC-425
XC-421 XC-422
xxiii
Contents
XC-428
Enabling ILMI Keepalive Timeout Using UNI 3.1 Signalling Support Verifying the LANE Setup
XC-432
Configuring Fast SSRP for Redundant LANE Services Monitoring and Maintaining LANE Components Token Ring LANE Configuration Example Example Assumptions
XC-434 XC-434 XC-434 XC-433 XC-433
Configuring the LES/BUS and the LEC Example Multiprotocol over ATM Overview How MPOA Works Traffic Flow
XC-439 XC-441 XC-441 XC-439
Configuring an MPC/MPS
XC-443 XC-445
MPC Configuration Task List Configuring the ELAN ID Configuring the MPC
XC-451
xxiv
Contents
MPS Configuration Task List Configuring the ELAN ID Configuring the MPS
XC-452 XC-452
Configuring Token Ring LAN Emulation for Multiprotocol over ATM How Token Ring MPOA Works
XC-457 XC-457
XC-457
Token Ring LANE for MPOA Configuration Task List Configuring a Token Ring LEC Configuring the LECS Database Configuring the LES/BUS
XC-458 XC-458
xxv
Contents
xxvi
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.
xxv
Note
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.
Figure 1
FC
P2C
P3C
IP3R
Cisco IOS AppleTalk and Novell IPX Command Reference
Cisco IOS Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS Configuration Guide Cisco IOS Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS Command Reference
FR
IP2R
P2R
P3R
Module FC/FR: Cisco IOS User Interfaces File Management System Management
Module P3C/P3R: Apollo Domain Banyan VINES DECnet ISO CLNS XNS
WC
IC
MWC
SC
WR
IR
MWR
SR
Module WC/WR: ATM Broadband Access Frame Relay SMDS X.25 and LAPB
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
xxvi
47953
DC
TC
BC
B1R
Cisco IOS Dial Technologies Command Reference Cisco IOS Terminal Services Command Reference Cisco IOS Bridging and IBM Networking Command Reference, Volume 1 of 2
B2R
Cisco IOS Bridging and IBM Networking Command Reference, Volume 2 of 2
DR
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
Module TC/TR: ARA LAT NASI Telnet TN3270 XRemote X.28 PAD Protocol Translation
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
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
VC
QC
XC
VR
QR
XR
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
Module QC/QR: Packet Classification Congestion Management Congestion Avoidance Policing and Shaping Signalling Link Efficiency Mechanisms
Module XC/XR: Cisco IOS Switching Paths NetFlow Switching Multiprotocol Label Switching Multilayer Switching Multicast Distributed Switching Virtual LANs LAN Emulation
47954
xxvii
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.
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 MessagesThis 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 ReferenceThis 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 AcronymsThis Cisco publication compiles and defines the terms and acronyms used in the internetworking industry. New feature documentationFeature 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 notesThis documentation describes system requirements, provides new and changed information, and includes other useful information about specific software releases. Caveats documentationThis documentation provides information about Cisco IOS software defects in specific software releases.
xxviii
Document Conventions
The Cisco IOS documentation set uses the following conventions: Convention ^ or Ctrl Description 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. 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
screen boldface screen
string
Description Examples of information displayed on the screen are set in Courier font. 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
Means reader be careful. In this situation, you might do something that could result in equipment damage or loss of data.
Note
Means reader take note. Notes contain helpful suggestions or references to materials not contained in this manual.
Timesaver
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.
xxix
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
xxx
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 bug-doc@cisco.com. 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.
xxxi
xxxii
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.
xxxiii
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
Access Method Log in. From user EXEC mode, use the enable EXEC command. From privileged EXEC mode, use the configure terminal privileged EXEC command. From global configuration mode, specify an interface using an interface command. From privileged EXEC mode, use the reload EXEC command. Press the Break key during the first 60 seconds while the system is booting.
Prompt
Router> Router#
Exit Method Use the logout command. To return to user EXEC mode, use the disable command. To return to privileged EXEC mode from global configuration mode, use the exit or end command, or press Ctrl-Z. To return to global configuration mode, use the exit command. To return to privileged EXEC mode, use the end command, or press Ctrl-Z.
Router(config)#
Interface configuration
Router(config-if)#
ROM monitor
>
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
help
Purpose Provides a brief description of the help system in any command mode. Provides a list of commands that begin with a particular character string. (No space between command and question mark.) Completes a partial command name. Lists all commands available for a particular command mode. Lists the keywords or arguments that you must enter next on the command line. (Space between command and question mark.)
abbreviated-command-entry?
abbreviated-command-entry<Tab>
?
command ?
xxxiv
Command
Router> enable Password: <password> Router#
Comment Enter the enable command and password to access privileged EXEC commands. You are in privileged EXEC mode when the prompt changes to Router#. 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)#. 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)#.
Router# configure terminal Enter configuration commands, one per line. End with CNTL/Z. 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)#
xxxv
Table 2
Command
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)# 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
Comment 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.
Enter the command that you want to configure for the interface. This example uses the ip command. Enter ? to display what you must enter next on the command line. This example shows only some of the available interface IP configuration commands.
xxxvi
Using Cisco IOS Software Using the no and default Forms of Commands
Table 2
Command
Router(config-if)# ip address ? A.B.C.D IP address negotiated IP Address negotiated over PPP Router(config-if)# ip address
Comment 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. 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.
xxxvii
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.
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.
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.
xxxviii
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.
xxxix
xl
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 PathsProvides 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 SwitchingProvides 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 SwitchingProvides 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 SwitchingProvides 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.
XC-1
VLANsProvides 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 EmulationProvides 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 InternetworksVlanDirector 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.
XC-2
Basic Router Platform Architecture and Processes Basic Switching Paths Features That Affect Performance
XC-5
Cisco IOS Switching Paths Overview Basic Router Platform Architecture and Processes
Figure 2
Interface processors
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.
XC-6
S6777
Frame Relay
FDDI
ATM
Cisco IOS Switching Paths Overview Basic Router Platform Architecture and Processes
Router A 102 FDDI Update Update Router B Update 103 104 105 ATM Update Router C Update
Token Ring
Router D 106
S6778
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 FDDI header
ATM 104
S6779
XC-7
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.
Figure 5
Layer 3 IP address Wire Layer 2 MAC address
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.
XC-8
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 Route Switch Processor (RSP) CyBus Optimum switching Fast switching cache Optimum switching cache
S6780
Interface processor
Interface processor
XC-9
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.
Switching Path Process switching Fast switching CEF switching dCEF switching
Comments Initializes switching caches Default (except for IP) Default for IP
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.
XC-10
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 queueingPackets 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.
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.
XC-11
XC-12
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
XC-13
Purpose Enables fast switching (use of a high-speed route cache for IP routing). Disables fast switching and enables load balancing on a per-packet basis.
Router A
Router B
Router C
To allow IP fast switching on the same interface, use the following command in interface configuration mode: Command
Router(config-if)# ip route-cache same-interface
Purpose Enables the fast switching of packets out of the same interface on which they arrived.
XC-14
S1527a
Purpose Defines the type and unit number of the interface, and enters interface configuration mode. Sets SMDS encapsulation. Enables the interface for IP fast switching. Enables the interface for IPX fast switching. Enables the interface for AppleTalk fast switching.
Note
Turning off fast switching increases system overhead because the packets will be process switched by the systems CPU.
XC-15
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
XC-16
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.
Controlling Route Cache Invalidation for IP Displaying System and Network Statistics Adjusting the Route Cache for IPX Padding Odd-Length IPX Packets
XC-17
Purpose Allows immediate invalidation of the cache. 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.
Purpose Displays the routing table cache used to fast switch IP traffic.
Controlling IPX Route Cache Size (Optional) Controlling IPX Route Cache Invalidation (Optional)
XC-18
To set a maximum limit on the number of entries in the IPX route cache, use the following command in global configuration mode: Command
Router(config)# ipx route-cache max-size size
Purpose 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.
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.
XC-19
To enable the padding of odd-length packets, use the following commands in interface configuration mode: Command
Step 1 Step 2
Router(config-if)# no ipx route-cache Router(config-if)# ipx pad-process-switched-packets
XC-20
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 performanceCEF 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. ScalabilityCEF offers full switching capacity at each line card when dCEF mode is active. ResilienceCEF 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.
XC-21
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.
Figure 8 Cisco Express Forwarding
CEF
CEF
CEF
CEF
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:
XC-22
S6782
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.
Receives this processing... Packets destined for a Null0 interface are dropped. This can be used as an effective form of access filtering. 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.
XC-23
Table 4
Receives this processing... 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. Packets are discarded. 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.
XC-24
CEF Mode
FIB table
Interface card E1 E2
Interface card E1 E2
S6783
Workgroup LAN
Workgroup LAN
Workgroup LAN
XC-25
IPC
FE
T3
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.
XC-26
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.
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.
XC-27
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.
XC-28
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
Atlanta POP
XC-29
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
A B
47161
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.
XC-30
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.
XC-31
Figure 14
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_asciiTMS data in ASCII (human readable) format. tmstats_binaryTMS data in binary (space-efficient) format.
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>|
XC-32
Table 5 describes the fields in the file header of the TMSTATS_ASCII file.
Table 5 TMSTATS_ASCII File Header
Description File format version. The IP address of the router. The type of data being aggregated. The time of export (in seconds) since the router booted. The time of export (in seconds) since 1900-01-01 (Coordinated Universal Time (UTC)), as determined by the router. Whether Coordinated Universal Time (UTC) of the router has been synchronized by the Network Time Protocol (NTP). The time needed to capture the data (in seconds).
19
NTP
20
DURATION
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>
Field <recordType>
Description p means that the record represents dynamic label switching data or traffic engineered (TE) tunnel traffic data. The IP prefix address/mask (a.b.c.d/len format) for this IGP route. The sysUpTime when the record was first created. Internal packet count. Internal byte count. External packet count. External byte count (no trailing |).
19 11 21 21 21 20
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>
XC-33
Description t means that the record represents TE tunnel midpoint data. The IP address of the tunnel head and tunnel interface number. The sysUpTime when the record was first created. Internal packet count. Internal byte count. External packet count. External byte count (no trailing |).
XC-34
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>|
Max. Length 5 15 20 10 10 10
Description File format version. The IP address of the router. The type of data being aggregated. The time of export (in seconds) since router booted. The time of export (in seconds) since 1900-01-01, as determined by the router. The time needed to capture the data (in seconds).
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>
Description
nonrecursivePrefix/Mask The IP prefix address/mask (a.b.c.d/len format) for this IGP route. AS destinationPrefix/Mask The neighbor autonomous system. The prefix/mask for the FIB entry (typically BGP route).
Note
Before enabling the PXF processor, you must have IP routing and IP CEF switching turned on.
XC-35
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 servicesThe 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 upgradablePXF 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-proofingif 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 requirementsAn 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 performanceNetwork-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.
XC-36
FIBVirtual 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 integrationVP 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 interfacesVP CEF allows you to enable ISDN interfaces in CEF switching.
XC-37
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.
XC-37
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
Router(config)# ip cef distributed Router(config)# no ip cef distributed
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
Router(config-if)# no ip route-cache cef
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.
XC-38
Configuring per-Destination Load Balancing (Optional) Configuring per-Packet Load Balancing (Optional) Selecting a Load Balancing Algorithm (Optional)
XC-39
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
Router(config-if)# ip load-sharing per-packet
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.
Purpose Sets the load sharing algorithm to the original based on a source and destination hash. 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. Sets the load sharing algorithm to the universal algorithm that uses a source and destination, and ID hash.
XC-40
Enabling Network Accounting for CEF (Optional) Enabling a Backbone Router to Collect Traffic Matrix Statistics (TMS) Data (Optional) Verifying Network Accounting Information (Optional)
Purpose Enables the collection of the number of packets and bytes express forwarded to a destination IP address (or prefix). 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.
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.
XC-41
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
Step 1 Step 2 Step 3 Step 4
Router(config)# ip cef Router(config)# ip cef accounting non-recursive Router(config)# interface type number Router(config-if)# ip cef accounting non-recursive external
Purpose Enables CEF on the router. Enables nonrecursive accounting on the router. Specifies the interface on the backbone router that you intend to configure. 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.
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.
XC-42
Figure 15
XC-43
Figure 16
XC-44
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)
XC-45
Error Message
WARNING:PXF Exception:mac_xid=0x10000 *** IHB watchdog timer expired 6d16h:%PXF-2-EXCEPTION:pxf exception on pxf tmc. PXF processor hang and error message: WARNING:PXF Exception:mac_xid=0x8 *** External Memory Column 3 exception, type = 20 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
Workaround Enter the show pxf crash EXEC command to obtain more information. 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. This message indicates that the PXF processor encountered a serious error and crashed. To work around this problem, reload the router.
Purpose Displays PXF switching statistics for all interfaces. Displays PXF switching statistics for Ethernet interfaces. Displays PXF switching statistics for NULL interfaces. Displays PXF switching statistics for packet OC-3 interfaces. Displays PXF switching statistics for serial interfaces. Displays a summary of PXF switching statistics. Displays PXF crash information. Displays PXF routing feature tables for CEF. Displays PXF routing tables for NAT. Displays a summary of the interfaces in the router and the PXF features and capabilities that are enabled on these interfaces.
XC-46
Purpose Displays CEF adjacency table information. Displays entries in the FIB that are unresolved or displays a summary of the FIB. 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
Router# show cef
Purpose Displays which packets the line cards dropped or displays which packets were not express forwarded. Displays CEF-related interface information. Displays CEF-related interface information by line card. Displays CEF recursive and direct prefixes resolved through an adjacency. Displays all recorded CEF FIB and adjacency events. Displays the exact route for a source-destination IP address pair. Displays CEF traffic statistics.
Router# show cef interface Router# show cef linecard Router# show ip cef adjacency Router# show ip cef events Router# show ip cef exact-route Router# show ip cef traffic prefix-length
XC-47
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.
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.
Purpose Clears CEF inconsistency statistics and records found by the CEF consistency checkers. Clears CEF information from linecards.
XC-48
Router A e1/0
(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 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
XC-49
XC-50
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.
XC-53
A network flow is identified as a unidirectional stream of packets between a given source and destinationboth 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.
XC-54
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 0 to 3 4 to 7 8 to 11 12 to 15
Description Netflow export format version number and number of flows exported in this packet (1 to 24). Current time (in milliseconds) since router booted. Current seconds since 0000 UTC 1970. 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 0 to 3 4 to 7 8 to 11 12 to 15 16 to 19 20 to 23 24 to 27 28 to 31 32 to 35 36 to 39 40 to 43 44 to 47
Content srcaddr dstaddr nexthop input and output dPkts dOctets First Last srcport and dstport pad1, prot, and tos
Description Source IP address. Destination IP address. IP address of the next hop router. SNMP index of the input and output interface. Packets in the flow. Total number of Layer 3 bytes in the flows packets. SysUptime at start of flow. SysUptime at the time the last packet of flow was received. TCP/UDP source and destination port number or equivalent. Unused (zero) byte, IP protocol (for example, 6 = TCP, 17 = UDP), and IP ToS.
flags, pad2, and pad3 Cumulative OR of TCP flags. Pad 2 and pad 3 are unused (zero) bytes. reserved Unused (zero) bytes.
XC-55
Table 13 lists the byte definitions for the version 5 header format.
Table 13 Version 5 Header Format
Bytes 0 to 3 4 to 7 8 to 11 12 to 15 16 to 19 20 to 23
Description Netflow export format version number and number of flows exported in this packet (1 to 30). Current time (in milliseconds) since the router booted Current seconds since 0000 UTC 1970. Residual nanoseconds since 0000 UTC 1970. Sequence counter of total flows seen. Unused (zero) bytes.
Table 14 lists the byte definitions for the version 5 flow record format.
Table 14 Version 5 Flow Record Format
Bytes 0 to 3 4 to 7 8 to 11 12 to 15 16 to 19 20 to 23 24 to 27 28 to 31 32 to 35 36 to 39 40 to 43 44 to 47
Content srcaddr dstaddr nexthop input and output dPkts dOctets First Last srcport and dstport
Description Source IP address. Destination IP address. IP address of the next hop router. SNMP index of the input and output interface. Packets in the flow. Total number of Layer 3 bytes in the flows packets. SysUptime at start of flow. SysUptime at the time the last packet of flow was received. TCP/UDP source and destination port number or equivalent.
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. src_as and dst_as src_mask, dst_mask, and pad2 Autonomous system of the source and destination, either origin or peer. Source and destination address prefix mask bits. Pad 2 is unused (zero) bytes.
XC-56
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 requirementNetFlow aggregation caches reduce the bandwidth required between routers and NetFlow management workstations. Reduced NetFlow workstation requirementsNetFlow aggregation caches reduce the number of NetFlow management workstations required. Improved router scalabilityNetFlow aggregation caches improve the scalability of high-flow-per-second routers, such as the Cisco 7500 series.
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 Bytes
Destination BGP autonomous system Peer or origin autonomous system of the destination prefix (IP address.) Destination interface Destination port SNMP index of the output interface. Destination UDP or TCP port number.
XC-57
Table 15
Term Destination prefix First Flows Last Packets PAD Protocol Source BGP autonomous system Source interface Source port Source prefix
Definition Destination IP address ANDed with the destination prefix mask. System uptime when the first packet was switched. Number of main cache flows that were aggregated. System uptime when the last packet was switched. Number of packets in the aggregated flows. Zero field. IP protocol byte. Peer or origin autonomous system of the source prefix. SNMP index of the input interface. Source UDP or TCP port number if applicable. Source IP address ANDed with the source prefix mask, or the prefix that the source IP address of the aggregated flows belong to.
XC-58
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
Figure 18
0 4 8
0 4 8
Flows Packets Bytes First time stamp Last time stamp Source AS Source interface Destination AS
26462
12 12 16 16 20 20 24 24
Destination interface
XC-59
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
Figure 19
0 4 8 12 16 20 24
Flows Packets Bytes First time stamp Last time stamp Destination prefix Destination AS
463
Destination interface
Reserved
XC-60
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
Figure 20
0 4 8
0 4 8
Flows Packets Bytes First time stamp Last time stamp Source prefix Destination prefix Destination mask bits Source mask bits Reserved Destination AS Destination interface
26464
12 12 16 16 20 20 24 24 28 28 32 32 36 36
XC-61
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
Figure 21
0 4 8
0 4 8
Flows Packets Bytes First time stamp Last time stamp Protocol Source port PAD Reserved
26465
12 12 16 16 20 20 24 24
Destination port
XC-62
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
Figure 22
0 4 8 12 16 20 24 28
Flows Packets Bytes First time stamp Last time stamp Source prefix Source AS
26466
Reserved
XC-63
Data Fields Autonomous System Source Prefix Destination Prefix Protocol Type of Service Byte Source Port Destination Port Source Interface Destination Interface ORd 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 Last Timestamp Flows Packets Bytes
* = exported key field x = exported field
* * * * * * * * * * * * * * * * * * *
* * x x x x x x x x x x * x x x x x x x x x x
* x x x x x
XC-64
Version System uptime UNIX seconds UNIX nanoseconds Sequence number Engine type Engine ID Aggregation Reserved
Count
Aggregation version
26467
Table 17
Term Version Count System uptime UNIX seconds UNIX nanoseconds Sequence number Engine type Engine ID Aggregation Aggregation version
Definition The flow export format version number. In this case, the number is 8. The number of export records in the datagram. The number of milliseconds since the router was last booted. The number of seconds since 0000 UTC 1970. The number of residual nanoseconds since 0000UTC 1970. Sequence counter of total flows sent for this export stream. The type of switching engine. RP = 0 and LC = 1. The slot number of the NetFlow engine. The type of aggregation scheme being used. The aggregation subformat version number. The current value is 2.
XC-65
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.
Note
Setting a NetFlow minimum mask size is not available in Autonomous System aggregation and Protocol Port aggregation.
Description Looks at a Forwarding Information Base (FIB) table instead of a routing table when switching packets. Addresses the scalability and maintenance problems of a demand caching scheme. 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.
XC-66
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. dCEFThe 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.
XC-67
XC-68
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 externallyeither 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.
XC-69
Note
NetFlow does consume additional memory and CPU resources; therefore, it is important to understand the resources required on your router before enabling NetFlow.
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: Command
Step 1
Router(config)# interface type slot/port-adapter/port (Cisco 7500 series routers)
or
Router(config)# interface type slot/port (Cisco 7200 series routers)
Step 2
XC-70
Purpose 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. 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.
Purpose Changes the number of entries maintained in the NetFlow cache. The number of entries can be from 1024 to 524288. The default is 65536.
XC-71
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.
Purpose Specifies the interface, and enters interface configuration mode. Enables VIP distributed switching of IP packets on the interface. Enables NetFlow.
XC-72
To export NetFlow cache entries to a workstation when a flow expires, use the following command in global configuration mode: Command
Router(config)# ip flow-export ip-address udp-port
Purpose Enters aggregation cache configuration mode and enables an aggregation cache scheme (as, destination-prefix, prefix, protocol-port, or source-prefix). Specifies the number (in this example, 2046) of cache entries to allocate for the Autonomous System aggregation cache. 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. Specifies the number of minutes (in this example, 45) that an active entry is active. Enables the data export. Enables aggregation cache creation.
Step 2 Step 3
Router(config-flow-cache)# cache timeout active 45 Router(config-flow-cache)# export destination 10.42.41.1 9991 Router(config-flow-cache)# enabled
To confirm data export, use the following command in EXEC mode: Command
Router# show ip flow export
Purpose Displays the statistics for the data export including the main cache and all other enabled caches.
XC-73
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:
Purpose Configures the prefix aggregation cache. Specifies the minimum value for the source mask. Specifies minimum value for the destination mask.
Purpose Configures the destination aggregation cache. Specifies the minimum value for the destination mask.
Purpose Configures the source-prefix aggregation cache. Specifies the minimum value for the source mask.
XC-74
Purpose Displays the configured value of the minimum mask in the prefix aggregation scheme. Displays the configured value of the minimum mask in the destination-prefix aggregation scheme. 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.
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.
XC-75
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
Router(config-route-map)# set ip next-hop verify-availability
Purpose 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.
Purpose Displays the route map IPC message statistics in the RP or VIP.
NetFlow Configuration Example NetFlow Aggregation Configuration Examples Setting a NetFlow Minimum Prefix Mask for Router-Based Aggregation Examples
XC-76
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 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 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 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
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
AS 40 40 40 40 40 40 40 40 40 40 40 40
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
XC-77
40 40 0 300
28 10 28 06 C0 18 49 01 00 10 100 01 C0
Note
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
Description Number of bytes of memory used by the NetFlow cache. Number of active flows in the NetFlow cache at the time this command was entered. 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. Number of flows created since the start of the summary period. Number of times the NetFlow code looked at the cache to cause entries to expire (used by Cisco for diagnostics only). Number of times the NetFlow code tried to allocate a flow but could not. IP address and User Datagram Protocol (UDP) port number of the workstation to which flows are exported. Total number of flows exported and the total number of UDP datagrams used to export the flows to the workstation. Number of flows that could not be exported by the router because of output interface limitations.
added ager polls flow alloc failures Exporting flows flows exported in udp datagrams failed
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
Description IP protocol and the well-known port number as described in RFC 1340. Number of flows for this protocol since the last time statistics were cleared. Average number of flows for this protocol seen per second; equal to total flows/number of seconds for this summary period.
XC-78
Table 20
Field Packets/Flow
Description 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. 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). Average number of packets for this protocol per second (total packets for this protocol) or total number of seconds for this summary period.
Bytes/Pkt
Packets/Sec
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
Description Interface on which the packet was received. Source Border Gateway Protocol (BGP) autonomous system. This is always set to 0 in MPLS flows. IP address of the device that transmitted the packet.
Note
Interface from which the packet was transmitted. The DstIf interface can be reported as Null if the packets are any of the following:
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:
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.
Port Msk AS
XC-79
Table 21
show ip cache verbose flow Field Descriptions in NetFlow Record Display (continued)
Description IP address of the destination device. Specifies the BGP next-hop address. This is always set to 0 in MPLS flows. IP protocol well-known port number as described in RFC 1340, displayed in hexadecimal format. 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). TCP flags (result of bitwise OR of TCP flags from all packets in the flow). Number of active flows in the NetFlow cache at the time this command was entered. Number of packets switched through this flow.
Autonomous System Configuration Example Destination Prefix Configuration Example Prefix Configuration Example Protocol Port Configuration Example Source Prefix Configuration Example
XC-80
Prefix Aggregation Scheme Example Destination-Prefix Aggregation Scheme Example Source-Prefix Aggregation Scheme Example
XC-81
XC-82
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 todays 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
XC-83
MPLS Quality of Service MPLS Label Switch Controller MPLS Egress NetFlow Accounting
Table 19 lists tag switching terms (found in earlier releases of this document) and the equivalent MPLS terms used in this document.
Table 19 Equivalency Table for Tag Switching and MPLS Terms
Old Tag Switching Terminology Tag Switching Tag (short for Tag Switching) Tag (item or packet) TDP (Tag Distribution Protocol)
New MPLS Terminology Multiprotocol Label Switching (MPLS) MPLS Label 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 TFIB (Tag Forwarding Information Base) TSR (Tag Switching Router) TSC (Tag Switch Controller) ATM-TSR (ATM Tag Switch Router) TVC (Tag VC, Tag Virtual Circuit) TSP (Tag Switch Path) XTag ATM (extended Tag ATM port)
Label Switched LFIB (Label Forwarding Information Base) LSR (Label Switching Router) LSC (Label Switch Controller) ATM-LSR (ATM Label Switch Router, such as the Cisco BPX 8650 switch) LVC (Label VC, Label Virtual Circuit) LSP (Label Switch Path) XmplsATM (extended MPLS ATM port)
XC-84
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.
Command debug mpls adjacency debug mpls events debug mpls lfib cef
Description
debug tag-switching adjacency Displays changes to label switching entries in the adjacency database. debug tag-switching events debug tag-switching tfib cef Displays information about significant MPLS events. Prints detailed information about label rewrites being created, resolved, and deactivated as CEF routes are added, changed, or removed. Prints detailed information about label encapsulations while label rewrites are created or updated and placed into the label forwarding information base (LFIB). Prints detailed information about label rewrites being created and deleted as TSP tunnels are added or removed. Traces what happens when label switching is enabled or disabled.
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 tag-switching packets interface atm Displays labeled packets switched by the host router. Enters interface configuration mode, specifies ATM as the interface type, and enables the creation of a subinterface on the ATM interface.
XC-85
Table 20
Command mpls atm control-vc mpls atm vpi mpls ip (global configuration) mpls ip (interface configuration) mpls ip default-route mpls ip propagate-ttl mpls ip ttl-expiration pop
Corresponding Tag Switching Command tag-switching atm control-vc tag-switching atm vpi tag-switching ip (global configuration) tag-switching ip (interface configuration) tag-switching ip default-route tag-switching ip propagate-ttl N/A
Description Configures the VPI and VCI to be used for the initial link to the label switching peer device. Configures the range of values to be used in the VPI field for label VCs. Enables MPLS forwarding of IPv4 packets along normally routed paths for the platform. Enables MPLS forwarding of IPv4 packets along normally routed paths for a particular interface. Enables the distribution of labels associated with the IP default route. Sets the time-to-live (TTL) value when an IP packet is encapsulated in MPLS. Forwards packets using the global IP routing table or the original label stack, depending on the number of labels in the packet. Configures the range of local labels available for use on packet interfaces.
Note
The syntax of this command differs slightly from its tag-switching counterpart.
mpls mtu show mpls forwarding-table show mpls interfaces show mpls label range
Sets the per-interface maximum transmission unit (MTU) for labeled packets. Displays the contents of the label forwarding information base (LFIB). Displays information about one or more interfaces that have been configured for label switching. 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
XC-86
(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.
XC-87
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 classthat 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.
TDPUsed 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.
XC-88
IP tunnel interfacesFrom 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 moduleThis 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 extensionsRSVP operates at each LSP hop and is used to signal and maintain LSPs based on the calculated path. MPLS traffic engineering link management moduleThis 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 OSPFeach 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 forwardingThis forwarding mechanism provides routers with a Layer 2-like ability to direct traffic across multiple hops of the LSP established by RSVP signalling.
XC-89
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
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.
XC-90
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.
One or more native IP paths One or more traffic engineering tunnels A combination of native IP paths and traffic engineering tunnels
Router A
Router B
Router C
Router D
Router E
26682
XC-91
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.
The native IP path by Router A to Router B to Router C The TE tunnel Router A to Router D
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.
XC-92
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
Router A Metric = 10
MPLS TE-tunnel T1
Subnet x
Subnet y
Subnet z
26511
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.
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.
XC-93
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:
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).
Note
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.
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.
XC-94
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 twiceonce 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 LSPsDuring 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
Unpredictable resultsIn 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.
AmbiguityIf 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.
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.
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.
XC-95
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.
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.
Metric-style narrowEnables the router to generate and accept only old-style TLVs Metric-style transitionEnables the router to generate and accept both old-style and new-style TLVs Metric-style wideEnables 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:
XC-96
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).
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 serviceA 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,
XC-97
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 serviceBuilding 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.
ScalabilityIf you create a VPN using connection-oriented, point-to-point overlays, Frame Relay, or ATM virtual connections, the VPNs 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 providers core and ensures that no one device is a scalability bottleneck.
SecurityMPLS 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
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 createTo 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.
XC-98
Flexible addressingTo 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) supportQoS 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 migrationFor 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
VPN 2 Site 1
CE Site 2
PE CE
VPN 1 Site 2
CE
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.
XC-99
17265
Figure 27 shows five customer sites communicating within three VPNs. The VPNs can communicate with the following sites:
Figure 27
VPN3
Site 5
17266
Configuring BGP hub and spoke connectionsConfiguring 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 routesConfiguring 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 VRFsLimiting 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 environmentConfiguring 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 informationSetting 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 21 lists the MPLS VPN features and the associated BGP commands.
XC-100
Table 21
Name of Cisco IOS Feature Command Configuring Faster Convergence for BGP VRF Routes Limiting VRF Routes bgp scan-time import
Description Configures scanning intervals of BGP routers to decrease import processing time of routing information. Limits the number of routes in a VRF to prevent a PE router from importing too many routes. Configures PE routers to allow CE routers to readvertise all prefixes that contain duplicate ASNs to neighboring PE routers. Configures a PE router to reuse the same ASN on all sites within an MPLS VPN by overriding private ASNs. Sets a separate router ID for each interface or subinterface on the PE router for each directly attached CE router.
maximum routes
Configuring BGP Hub and neighbor allowas-in Spoke Connections Reusing ASNs in an MPLS VPN Environment Distributing BGP OSPF Routing Information neighbor as-override
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 customers 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.
XC-101
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 communitiesA, B, or Cis imported into the VRF.
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.
XC-102
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) routerRouters 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 routerRouter 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) routerRouter in the ISP or enterprise network. Customer Edge (CE) routerEdge 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.
XC-103
Figure 28
ISP-A VPN CE
ISP-A customer
PE
VPN
MSO
ISP-B VPN CE
Provider core PE
VPN B
N VP T GM M
ISP-B customer
PE
Management router
35638
Management subnet
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.
Note
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.
XC-104
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.
XC-105
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.
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.
XC-106
Interautonomous system configurations supported in an MPLS VPN can include the following:
Interprovider VPNMPLS 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 confederationsMPLS 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.
Allows a VPN to cross more than one service provider backboneThe 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 areasThe 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 meshingThe 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.
XC-107
Figure 29
Service Provider 1 RR-1 Core of P routers EBGP VPNv4 routes with label distribution RR-2
PE-1
ASBR1
ASBR2
PE-2
PE-3
CE-1 VPN1
CE-2
CE-5
VPN1
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. 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. 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 2
Step 3
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.)
Step 4
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.
XC-108
43877
CE-3
CE-4
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.
Exchanging Routes and Labels Between Autonomous Systems in an Interprovider VPN Network
Service Provider 2 RR-1 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 RR-2 Network = RD1:N Next-hop = ASBR2 Label = L3 Core of P routers
Figure 30
Service Provider 1
PE-2
PE-3
CE-1 VPN1
CE-2
CE-5
CE-3 VPN1
CE-4
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.
43878
XC-109
Figure 31
Exchanging Routes and Labels Between Autonomous Systems in an Interprovider VPN Network
Service Provider 2 RR-1 RR-2 Network = RD1:N Label = L2
Service Provider 1 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-2
PE-3
Network = N Label = L2
CE-1 VPN1
CE-2
CE-5
CE-3 VPN1
CE-4
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.
XC-110
48299
Figure 32
Service Provider 1
PE-2
PE-3
Network = N
Network = N
CE-1 VPN 1
CE-2
CE-5
43879
CE-3 VPN 1
CE-4
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-1 Service Provider 1 RR-2 Network = N IGP label = ASBR1 VPN label = L2 Core of P routers
PE-2
PE-3
Network = N
Network = N
CE-1 VPN 1
CE-2
CE-5
48300
CE-3 VPN 1
CE-4
XC-111
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.
Note
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.
XC-112
Figure 34
EBGP intra-confederation for VPNv4 routes with label distribution PE-1 CEGBP-1 CEBGP-2 PE-2
PE-3
CE-1 VPN 1
CE-2
CE-5
VPN 1
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.
43880
CE-3
CE-4
XC-113
In supplying differentiated service, MPLS QoS offers packet classification, congestion avoidance, and congestion management. Table 22 lists these functions and their descriptions.
Table 22 QoS Services and Features
Service
QoS Function
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).
Packet Committed access rate (CAR). classification Packets are classified at the edge of the network before labels are assigned. 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. 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.
Congestion management
Note
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.
XC-114
Figure 35 shows an MPLS network that connects two sites of a IP network belonging to a customer.
Figure 35
IP network
MPLS network
MPLS network
IP network
Host B
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 23:
Table 23 Device Symbols
Meaning Customer equipment 1 Service provider edge router (ingress LSR) Service provider router within the core of the network of the service provider Service provider router within the core of the network of the service provider Service provider edge router (egress LSR) Customer equipment 2
Note
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.
XC-115
41867
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.
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
XC-116
Figure 36 shows the functional relationship between the MPLS LSC and the ATM switch that it controls.
Figure 36 MPLS Label Switch Controller and Controlled ATM Switch
VSI
LC-ATM interface
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:
Cisco BPX 8600, 8650 (which includes a Cisco 7204 router), and 8680 Cisco IGX 8410, 8420, and 8430
Note
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 integrationEnables 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 routingProvides Layer 2 VCs to gigabit router backbones and integrated IP+ATM environments, including support for explicit routing and provisioning of IP VPN services. SVPNsSupports IP-based VPNs on either a Frame Relay or ATM backbone, an integrated IP-ATM backbone, or a gigabit router backbone.
S6867
XC-117
Label Switch Controller (7200 series) XTagATM61 extended-port a1/0 BPX 6.1 XTagATM62 extended-port a1/0 BPX 6.2 Master control port ATM1/0
tag-control-protocol vsi
Switch Control Protocol (Virtual Switch Interface) Switch Control Port (12.1) 6.1 Controlled Switch (BPX) 6.2 12.2
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 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.
XC-118
S6856
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
XC-119
Figure 38
MPLS
MPLS
ATM
Reduced costsBy 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 networksVSI 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.
XC-120
33962
MPLS
Figure 39
. . .
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.
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.
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
33963
XC-121
ATM-LSR-2
ATM-LSR-4
XC-122
35149
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.
Transparent ModeThe 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 modeYou 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 modeThe 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 modeYou 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.
XC-123
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.
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.
XC-124
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.
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.
Note
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 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
XC-125
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 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.
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.
XC-126
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.
XC-127
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
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.
LSC 1
XtagATM interfaces
LSC 2
Control port
XC-128
48468
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
Figure 42
LSC
LSC
LSC
LSC
Edge LSR
ATM switch
ATM networks
Edge LSR
Physical interface
ATM switch
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.
XC-129
35150
Virtual trunk
Edge LSR
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
ATM-LSR-2
ATM-LSR-4
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.
XC-130
35149
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-1 LSC-2 Virtual trunk/ VP tunnel 10 Virtual trunk/ VP tunnel 12 LSC-3 LSC-4
Virtual trunk/ VP tunnel 16 ATM switch Virtual trunk/ VP tunnel 20 Edge LSR
Edge LSR
Note: Tunnels are virtual interfaces. Physical interfaces are marked by thin lines. Logical equivalent
ATM-LSR-2
ATM-LSR-4
XC-131
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.
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.
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.
XC-132
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.
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.
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.
XC-133
Figure 45
CE router
PE router 192.168.x.x
PE router 192.168.x.x
CE router
CE router
PE router 192.168.x.x
PE router 192.168.x.x
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.
XC-134
46928
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
LSC 172.16.53.1
ATM switch
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
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
45566
XC-135
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 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.
XC-136
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.
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. NRPThe 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 adapterThe Cisco 6400 UAC uses an ATM port adapter to provide external connectivity for the NSP.
XC-137
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
N R P 1
N R P 2
PVP (n)
PVP (n)
. .
PVP (n+3)
. . x x
PVP (n+3)
E d g e L S R
PVP
PVP
L S C
N S P
30787
XC-138
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 24.
Table 24 VSI Interface Control PVCs for BPX VSI Slave Slots
VSI Interface Control VC 0/40 0/41 0/42 0/43 0/44 0/45 0/46 0/47 0/48 0/49 0/50 0/51 0/52 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 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 NSP NRP
VC = 2/35
29752
XC-139
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.)
XC-140
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 Data path between LSR1 and LSR2 for their respective networks 6.1 12.2 LSR2 LDP and routing paths between LSR1 and LSR2
Loopback = 1.1.1.1
NSP
NRP
29753
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
XC-141
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.
XC-142
Figure 50
C VPN-SC Site 1 VPN 1 P CE1 Site 2 VPN 2 Site 1 VPN 2 PE1 Collector 1 P PE2 Backbone
Site 2 VPN 1
CE5 Collector 2
PE3
CE2
CE4
CE6
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 solutionYou 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 statisticsNetFlow 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.
42949
XC-143
XC-144
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.
XC-143
Table 24 lists the cases, including the steps to perform MPLS and their corresponding Cisco IOS CLI commands.
Table 24 MPLSLevels of Control
Description
Case 1Enable 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 2Route 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 3Limit 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
e0/1 e0/2 e0/1 e0/2 e0/2
R4
e0/1 e0/1 e0/2 e0/2
R7 Network A
e0/1
R3
e0/2 e0/1 e0/4 e0/3 e0/2 e0/1
R6
e0/4 e0/3 e0/2 e0/1
Network B R8
R2
R5
XC-144
S5918
Purpose Enables MPLS between R1 and R3. In order to configure distributed VIP MPLS, you must configure dCEF switching. Enter the ip cef distributed global configuration command on all routers.
Step 2
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.
XC-145
Purpose 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
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.
XC-146
Command
Step 3 Step 4
Router(config)# no tag-switching advertise-tags Router(config)# Router(config)# Router(config)# Router(config)# access-list 2 permit R1 no tag-switching advertise-tags for 1 tag-switching advertise-tags for 1 to 2 exit
Purpose Configures R8 to distribute no labels 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. 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
Configures R3. (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.) Configures R4. (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.) Configures R6. (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.) 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.)
Step 6
Step 7
Step 8
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.
XC-147
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
Purpose Enables standard CEF operation. For information about CEF configuration and the command syntax, see the Cisco IOS Switching Services Command Reference.
Step 2
XC-148
Note
You must enable the tunnel feature on interfaces that you want to support MPLS traffic engineering.
Command
Step 1 Step 2
Router(config-if)# mpls traffic-eng tunnels
Purpose Enables MPLS traffic engineering tunnels on an interface. 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.
Purpose Enables IS-IS routing and specifies an IS-IS process for IP. This command places the router in router configuration mode. Turns on MPLS traffic engineering for IS-IS level 1. Specifies that the traffic engineering router identifier for the node is the IP address associated with interface loopback0. Configures a router to generate and accept only new-style TLVs.
Router(config-router)# mpls traffic-eng level-1 Router(config-router)# mpls traffic-eng router-id loopback0 Router(config-router)# metric-style wide
XC-149
Purpose 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
Step 3
Specifies that the traffic engineering router identifier for the node is the IP address associated with interface loopback0.
Purpose Configures an interface type and enters interface configuration mode. Gives the tunnel interface an IP address. An MPLS traffic engineering tunnel interface should be unnumbered because it represents a unidirectional link.
Router(config-if)# tunnel destination A.B.C.D Router(config-if)# tunnel mode mpls traffic-eng Router(config-if)# tunnel mpls traffic-eng bandwidth bandwidth Router(config-if)# tunnel mpls traffic-eng path-option number {dynamic | explicit {name path-name | path-number}} [lockdown]
Specifies the destination for a tunnel. Sets the tunnel encapsulation mode to MPLS traffic engineering. Configures the bandwidth for the MPLS traffic engineering tunnel. 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.
XC-150
Purpose Configures an interface type and enters interface configuration mode. Causes the IGP to use the tunnel in its enhanced SPF calculation.
This section describes two sample examples supported by traffic engineering. These cases show how you can engineer traffic across a path in the network and establish a backup route for that traffic engineered path (see Table 25). In both cases, the assumption is made that traffic from R1 and R2 (in Figure 52), which is intended for R11, would be directed by Layer 3 routing along the upper path R3-R4-R7-R10-R11.
Table 25 MPLSTraffic Engineering Paths
Descriptions The steps necessary to engineer traffic across the middle path R3-R5-R8 (see Figure 52).
Case 2Establish a backup path The steps necessary for establishing a backup traffic engineering route for the engineered traffic for Case 1. Figure 52 shows a router-only MPLS network with traffic engineered paths.
Figure 52 Sample MPLS Network with Traffic Engineered Paths
R1
e0/1 e0/1 e0/2 e0/1 e0/2 e0/3 e0/1 e0/4
R4
e0/2 e0/1
R7
e0/2
R5
e0/2 e0/1
R8
e0/2
R11
R3
e0/5 e0/1 e0/2
Network A
R6
e0/1 e0/2 e0/1
R9
e0/2
R2
S6300
XC-151
Purpose Configures support for LSP tunnel signalling along the path. In order to configure distributed VIP MPLS, you must configure dCEF switching. Enter the ip cef distributed command on all routers.
Note
To configure a Cisco 7200 series router, enter the ip cef command. To configure a Cisco 7500 series router, enter the ip cef distributed command.
Step 2
(IP (IP
address of R3:e0/1 ) address of R5:e0/1 ) (IP address of R8:e0/1) (IP address of R10:e0/1)
XC-152
Command
Step 3
At R1: Router(config)# router traffic-engineering Router(config)# traffic-engineering filter 1 egress 10.14.0.111 255.255.255.255
Purpose Configures the traffic engineering filter to classify the traffic to be routed. The filter selects all traffic where the autonomous system egress router is 10.14.0.111(10.14.0.111 is the IP address of R11:e0/1). Configures the traffic engineering route to send the engineered traffic down the tunnel.
Step 4
Purpose Enables LSP tunnel signalling along the path (where such signalling is not already enabled).
Step 2
(IP address of R3:e0/1) (IP address of R6:e0/1) Configures the traffic engineering route to send the engineered traffic down the tunnel if the middle path (case 1 route) is unavailable.
Step 3
At R1: Router(config)# router traffic-engineering Router(config)# traffic-engineering route 1 tunnel 2004 pref 200
XC-153
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
Step 1 Step 2 Step 3 Step 4 Step 5 Step 6
Router(config)# ip vrf vrf-name
Purpose Enters VRF configuration mode and defines the VPN routing instance by assigning a VRF name. Creates routing and forwarding tables. Creates a list of import or export route target communities for the specified VRF. (Optional) Associates the specified route map with the VRF. (Optional) Associates the specified export route map with the VRF. Associates a VRF with an interface or subinterface.
Router(config-vrf)# rd route-distinguisher Router(config-vrf)# route-target {import | export | both} route-target-ext-community Router(config-vrf)# import map route-map
XC-154
Purpose Configures the BGP routing process with the autonomous system number passed along to other BGP routers. Specifies a neighbors IP address or BGP peer group identifying it to the local autonomous system. Activates the advertisement of the IPv4 address family.
Step 2
Step 3
Purpose Defines IBGP parameters for VPNv4 NLRI exchange. Defines an IBGP session to exchange VPNv4 NLRIs. Activates the advertisement of the IPv4 address family.
XC-155
The default is Off for autosummary and synchronization in the VRF address-family submode.
Step 2 Step 3
Defines an EBGP session between PE and CE routers. Activates the advertisement of the IPv4 address family.
The default is Off for auto-summary and synchronization in the VRF address-family submode.
Step 3
XC-156
Purpose Defines static route parameters for every PE to CE session. 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 Step 4
Redistributes VRF static routes into the VRF BGP table. Redistributes directly connected networks into the VRF BGP table.
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.
XC-157
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.
XC-158
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).
Note
Because only the CMTS has logical subinterfaces, assignments of VRFs on the other PE devices will be to specific physical interfaces. Purpose 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. Creates a routing and forwarding table by assigning a RD to the management VPN. Exports or imports all routes for the RD of the management VPN. This determines which routes will be shared within VRFs. Imports all routes for the VPNs (isp1-vpn argument) route distinguisher. Imports all routes for the VPNs (isp2-vpn argument) RD. Creates a routing and forwarding table by assigning a RD to isp1-vpn argument) . Creates a routing and forwarding table by assigning a RD (mgmt-rd argument) to the management VPN (mgmt-vpn argument) . Exports all routes for the VPNs (isp1-vpn argument) RD. Imports all routes for the VPNs (isp1-vpn argument) RD. Exports all routes for the VPNs (mgmt-vpn argument) RD. Creates a routing and forwarding table by assigning a RD to isp2-vpn argument) . Exports all routes for the VPNs (isp2-vpn argument) RD. Imports all routes for the VPNs (isp2-vpn argument) RD. Imports all routes for the VPNs (mgmt-vpn argument) RD.
Command
Step 1
Router(config)# ip vrf mgmt-vpn
Step 2 Step 3
Router(config-vrf)# rd mgmt-rd
Router(config-vrf)# rd mgmt-rd
XC-159
Purpose Enters configuration mode. 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
Defines the first (management) subinterface with the lowest subinterface number. Valid range for n is from 1 to 255. Identifies the subinterface as the management subinterface. Assigns the subinterface to the management VPN (the MPLS VPN used by the MSO to supply service to customers). Assigns the subinterface an IP address and a subnet mask. Forwards DHCP requests from cable modems to the IP address listed. Forwards DHCP requests from hosts to the IP address listed. Defines an additional subinterface for the ISP (such as isp1). Valid range for n is 1 to 255. Identifies the subinterface (such as subinterface for the isp1-vpn argument). Assigns the subinterface to isp1-vpn VPN. Assigns the subinterface an IP address and a subnet mask. Forwards DHCP requests from cable modems to the IP address listed. Forwards DHCP requests from hosts to the IP address listed. Defines an additional subinterface for the ISP (such as isp2). Valid range for n is 1 to 255. Identifies the subinterface (such as subinterface for the isp2-vpn argument) . Assigns the subinterface to isp2-vpn VPN.
Step 4 Step 5
Step 6 Step 7 Step 8 Step 9 Step 10 Step 11 Step 12 Step 13 Step 14 Step 15 Step 16 Step 17
Router(config-subif)# cable helper-address ip-address cable-modem Router(config-subif)# cable helper-address ip-address host Router(config-if)# interface cable slot/port.n
Router(config-subif)# cable helper-address ip-address cable-modem Router(config-subif)# cable helper-address ip-address host Router(config-if)# interface cable slot/port.n
XC-160
Command
Step 18 Step 19 Step 20 Step 21
Router(config-subif)# ip address ipaddress mask
Purpose Assigns the subinterface an IP address and a subnet mask. Forwards DHCP requests from cable modems to the IP address listed. Forwards DHCP requests from hosts to the IP address listed. Returns to configuration mode, and stores the configuration or changes to your startup configuration in NVRAM.
Router(config-subif)# cable helper-address ip-address cable-modem Router(config-subif)# cable helper-address ip-address host Router(config)# copy running-config startup-config
Note
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.
Step 22
Router(config)# exit
Purpose 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
Defines the interface as the bundles master interface. Valid range for bundle-number argument is from 1 to 255.
XC-161
Command
Step 3
Router(config)# interface cable slot/port
Purpose 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
Adds the interface to the bundle specified by bundle-number. Valid range for the bundle-number argument is from 1 to 255.
Purpose Enables CEF operation. Enters FastEthernet interface configuration mode. Defines the primary IP address range for the interface. Enables the interface to be forwarded to an MPLS packet. Enables Label Distribution Protocol (LDP) on the interface.
Router(config-if)# mpls ip
XC-162
Command
Step 6
Router(config)# copy running-config startup-config
Note
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.
Step 7
Router(config)# exit
Purpose Displays the set of VRFs and interfaces. Displays the IP routing table for a VRF. Displays the routing protocol information for a VRF. Displays the forwarding table for the specified interface.
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
XC-163
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
Step 1
Router(config)# router bgp autonomous-system
Purpose 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. Disables BGP route-target filtering. All received BGP VPN-IPv4 routes are accepted by the router. 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. Enters the address-family submode and specifies a neighboring EBGP peer group. This EBGP peer group is identified to the specified autonomous system. Activates the advertisement of the VPN-IPv4 address family to a neighboring EBGP router. Exits from the address-family submode of the global configuration mode.
Step 2 Step 3
Step 4
Step 5 Step 6
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.
XC-164
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
Step 1
Router(config)# router bgp subautonomous-system
Purpose 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. Defines an EBGP confederation by specifying a confederation identifier associated with each subautonomous system. The subautonomous systems appear as a single autonomous system. Specifies the subautonomous systems that belong to the confederation (identifying neighbors from other subautonomous systems within the confederation as special EBGP peers). Disables BGP route-target community filtering. All received BGP VPN-IPv4 routes are accepted by the router. 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. Enters the address-family submode and specifies a neighboring EBGP peer group. This EBGP peer group is identified to the specified subautonomous system. 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 Activates the advertisement of the VPN-IPv4 address family to a neighboring PE router in the specified subautonomous system. Exits from the address-family submode of the global configuration mode.
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Router(config-router-af)# exit-address-family
XC-165
Purpose Displays information about all VPN-IPv4 labels. 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 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 Hs0/0 Next Hop point2point point2point
Note
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.
Purpose Displays the set of defined VRFs and interfaces. Displays information about defined VRFs and associated interfaces. Displays the IP routing table for a VRF. Displays the routing protocol information for a VRF. Displays the CEF forwarding table associated with a VRF. Displays the VRF table associated with an interface. Displays information about all BGP VPN-IPv4 prefixes. Displays label forwarding entries that correspond to VRF routes advertised by this router.
Router# show ip route vrf vrf-name Router# show ip protocols vrf vrf-name Router# show ip cef vrf vrf-name
Router# show ip interface interface-number Router# show ip bgp vpnv4 all [tags]
XC-166
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. 2. 3. 4. 5. 6.
IP packets enter into the edge of the MPLS network. 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. For each packet, the router performs a lookup on the IP address to determine the next hop LSR. The appropriate label is placed on the packet with the IP Precedence bits copied into every label entry in the MPLS header. The labeled packet is then forwarded to the appropriate output interface for processing. 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).
XC-167
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 26 lists the MPLS QoS features supported on packet interfaces.
Table 26 MPLS QoS Features Supported on Packet Interfaces
MPLS QoS Packet Feature Per-interface WRED Per-interface, per-flow WFQ Per-interface, per-class WFQ
MPLS QoS ATM Forum PVCs Feature Per-VC WRED Per-VC WRED and per VC, per-class WFQ MPLS QoS Multi-VC or LBR Feature Per-interface WRED Per-interface, per-class WFQ
X2 X
2
X2 X
2
1. This feature is only available on the PA-A3. 2. This feature is only available on the PA-A1.
XC-168
MPLS QoS ATM Forum PVCs Feature MPLS QoS ATM Forum PVCs MPLS QoS Multi-VC or LBRper-class WFQ
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):
XC-169
IP network
MPLS network
MPLS network
IP network
Host B
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.
XC-170
41867
Modular QoS CLI, the newer and more flexible methodUse this method if you do not want to consider the rate of the packets that PE1 receives. CARUse 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
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 Step 2 Step 3
Configure a class map to classify IP packets according to their IP precedence. Configure a policy map to mark MPLS packets. (Write their classification into the MPLS experimental field.) Configure the input interface to attach the service policy.
Purpose Specifies the class map to which packets will be matched. Specifies the packet characteristics that will be matched to the class. Exits class-map configuration mode.
Router(config-c-map)# end
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
XC-171
Purpose Creates a policy map that can be attached to one or more interfaces to specify a service policy. Specifies the name of the class map previously designated in the class-map command. Designates the value to which the MPLS bits are set if the packets match the specified policy map. Exits policy-map configuration mode.
Router(config-p-map-c)# end
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
Command
Step 1 Step 2 Step 3
Router(config)# interface name Router(config-int)# service-policy input policy-map name Router(config-int)# end
Purpose Designates the input interface. Attaches the specified policy map to the input interface. 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
Configure an IP rate-limit access list for classifying IP packets according to their IP precedence. Perform this step at PE1 (the ingress LSR). Configure a rate limit on an input interface to set MPLS packets. (Write the classification of the packet into the MPLS experimental field.)
XC-172
Command
Step 1 Step 2
Router(config)# access-list rate-limit acl-index precedence Router(config)# end
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
Purpose Designates the input interface. 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
XC-173
Purpose Configures a point-to-point ATM subinterface. Assigns an IP address to the subinterface. Creates a PVC on the subinterface. Activates WRED or dWRED on the interface. Sets encapsulation type for the PVC. Exits from PVC mode and enters subinterface mode. Enables MPLS IP on the point-to-point interface.
Router(config-subif)# tag-switching ip
Note
The default for the multi-VC mode creates four VCs for each MPLS destination.
Command
Step 1 Step 2 Step 3 Step 4
Router(config)# interface type number tag-switching Router(config-subif)# ip unnumbered Loopback0 Router(config-subif)# tag-switching atm multi-vc Router(config-subif)# tag-switching ip
Purpose Configures an ATM MPLS subinterface. Assigns an IP address to the subinterface. Enables ATM multi-VC mode on the subinterface. Enables MPLS on the ATM subinterface.
XC-174
Purpose Creates a QoS map. 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:
Step 3 Step 4
Exits the MPLS QoS map submode. Creates an access list. The access list acts on traffic going to the specified destination address.
Step 5
Configures the router to use a specified QoS map when an MPLS destination prefix matches the specified access list.
Purpose Specifies the interface type and number. Configures an interface to use fair queueing. Changes the class weight on the specified interface.
XC-175
Configuring Multiprotocol Label Switching Configuring the MPLS Label Switch Controller
Purpose Displays detailed information about label switching interfaces. Displays the QoS map used to assign VCs. Displays the prefix map used to assign a QoS map to network prefixes.
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
Step 1
Router(config)# interface loopback0 Router(config-if)# ip address 192.103.210.5 255.255.255.255 Router(config)# tag-switching atm disable-headend-vc
Purpose Enables a loopback interface. A loopback interface provides stable router and LDP identifiers. 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.
Step 2
XC-176
Configuring Multiprotocol Label Switching Configuring the MPLS Label Switch Controller
Command
Step 3
Router(config)# interface atm1/0 Router(config-if)# tag-control-protocol vsi id 1
Purpose 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
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
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 6
Step 7
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.
Step 8
Router(config)# ip cef
Configuring Cisco 6400 UAC NRP as an MPLS LSC (Required) Configuring the Cisco 6400 UAC NSP for MPLS Connectivity to BPX (Optional)
XC-177
Configuring Multiprotocol Label Switching Configuring the MPLS Label Switch Controller
Purpose Enables a loopback interface. A loopback interface provides stable router and LDP identifiers. Enables the VSI protocol on the control interface ATM0/0/0. 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. 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 the other extended label ATM interface by creating an extended label ATM (XTagATM) virtual interface and binding it to BPX port 12.2. Configures MPLS on the extended label ATM interface. 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 Enables CEF switching. Disables headend VC label advertisement.
Step 2 Step 3
Step 4
Step 5
Step 6
Step 7 Step 8
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
Step 1
Switch# show hardware 3/0 NRP 00-0000-00 .......
Purpose Displays the hardware connected to the Cisco 6400 UAC, including the position (3/0) of the NRP in the Cisco 6400 chassis. Specifies the ATM interface for which you want to configure PVCs and PVPs.
Step 2
XC-178
Configuring Multiprotocol Label Switching Configuring the MPLS Label Switch Controller
Command
Step 3
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
Purpose 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
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
2 3 4 5
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.
XC-179
Purpose Displays the VSI session state. Displays the MPLS-enabled interface states. Displays information about an ATM interface that controls an external ATM switch or VSI control interface. Displays information about an extended MPLS ATM interface. Displays information about the discovery of MPLS neighbors. Displays information about the MPLS neighbor relationship. Displays information about negotiated of TDP or LDP control VPs. Displays the current headend, tailend, and transit dynamic tag bindings for the destinations. Displays the tag VCs that are in bindwait state along with their destinations. Displays summary information about the number of destination networks discovered via routing protocol and the LVCs created on each extended label ATM interface.
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)
XC-180
Purpose Enables MPLS egress NetFlow accounting on the egress router interface.
Purpose | 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.
Purpose 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. 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.
XC-181
Enter the show ip cache flow EXEC command to display a summary of NetFlow switching statistics.
Note
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 Pr SrcP DstP 01 0000 0800 Pkts 5
DstIPaddress 180.1.1.2
Table 29 describes the fields in the flow switching cache lines of the output.
Table 29 show ip cache flow Field DescriptionsFlow Switching Cache
Description The two lines below this banner show the percentage distribution of packets by size range. Number of bytes of memory the NetFlow cache uses. Number of active flows in the NetFlow cache at the time this command is entered. 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. Number of flows created since the start of the summary period. Number of times the NetFlow code looked at the cache to remove expired entries (used by Cisco for diagnostics only). Number of times the NetFlow code tried to allocate a flow but could not. 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.
XC-182
Description IP protocol and the well known port number as described in RFC 1340. Number of flows for this protocol since the last time statistics were cleared. Average number of flows for this protocol seen per second; equal to total flows/number of seconds for this summary period. 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. 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). Average number of packets for this protocol per second (total packets for this protocol and the total number of seconds for this summary period). 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. 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.
Bytes/Pkt
Packets/Sec
Active(Sec)/Flow
Idle(Sec)/Flow
Table 31 describes the fields in the current flow lines of the output.
Table 31 show ip cache flow Field DescriptionsCurrent Flow
Description Internal port name of the router for the source interface. Source IP address for this flow. Internal port name of the router for the destination interface. Destination IP address for this flow. IP protocol; for example, 6 = TCP, 17 = UDP, ... as defined in RFC 1340. Source port address, TCP/UDP well known port number, as defined in RFC 1340. Destination port address, TCP/UDP well known port number, as defined in RFC 1340. 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:
XC-183
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 32 describes the fields in the flow switching cache lines of the output.
Table 32 show ip cache flow aggregation prefix Field DescriptionsFlow Switching Cache
Description Number of bytes of memory the NetFlow cache uses. Number of active flows in the NetFlow cache at the time this command is entered. 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. Number of flows created since the start of the summary period. Number of times the NetFlow code looked at the cache to remove expired entries (used by Cisco for diagnostics only). Number of times the NetFlow code tried to allocate a flow but could not.
XC-184
Table 33 describes the fields in the current flow lines of the output.
Table 33 show ip cache flow aggregation prefix Field DescriptionsCurrent Flow
Field Src If Src Prefix Msk Dst If Dst Prefix Msk Flows Pkts
Description Routers internal port name for the source interface. Source IP address for this flow. Mask source. Router's internal port name for the destination interface. Destination prefix aggregation cache scheme. Mask destination. Number of flows. 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
XC-185
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 Pr SrcP DstP Pkts
DstIPaddress
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 Msk Flows /32 1 Pkts 5
Purpose 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.
XC-186
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
XC-187
access-list 1 permit A access-list 2 permit R1 tag-switching advertise-tags for 1 to 2 exit access-list 1 permit A access-list 2 permit R3 tag-switching advertise-tags for 1 to 2 exit 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
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)
XC-188
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
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 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
XC-189
[T]
Forwarding through a TSP tunnel. View additional tagging info with the 'detail' option
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
XC-190
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
XC-191
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 Configuring a Traffic Engineering Filter and Route Example Displaying Traffic Engineering Configuration Information Example
Figure 54 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 54.
Figure 54 Sample MPLS Traffic Engineering Tunnel Configuration
Router 3 12.12.12.12
S1/1 .2 .1
S1/0
2 el nn Tu 6.0.0 13
Tu n 13 nel 2 5.0 .0
S1/3 S1/0
S1/0 .1
S1/0
Router 1 11.11.11.11
131.0.0 Tunnel 1
.2
Router 2 15.15.15.15
Tunnel 1
Router 4 14.14.14.14
Tunnel 1
Router 5 17.17.17.17
XC-192
26683
Tunnel 2
S1/2
.1
.2
S1/1
Tunnel 2
.1 133.0.0 .2 S1/0 S1/3
Note
You must enter the following commands on every router in the traffic-engineered portion of your network.
Note
You must enter the following commands on every router in the traffic-engineered portion of your network.
XC-193
XC-194
XC-195
Tunnel6 route not installed interface up, route enabled, preference 75 loop check on, passing, remote metric: connected/0
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
XC-196
interface Ethernet5/0/1 ! Set up Ethernet interface as VRF link to a CE router 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 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. ...
XC-197
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
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 cable bundle 1
XC-198
XC-199
! ! 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 ! ! 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
XC-200
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. 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 ! customersin 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 !
XC-201
! 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 ! ! 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
XC-202
! ! Defines the DHCP server for PC host devices. cable helper-address 10.4.1.2 host ! ! end
XC-203
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 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
XC-204
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
Figure 55
VPN1
PE1
P1
P2
PE2
VPN1
CE1
AS1
AS2
CE2 47866
EBGP1
EBGP2
XC-205
XC-206
XC-207
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
XC-208
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
XC-209
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
XC-210
! 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
XC-211
Configuring EBGP Routing to Exchange VPN Routes Between Autonomous Systems in a Confederation
The network topology in Figure 56 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.
Configuring Two Autonomous Systems in a Confederation
Figure 56
VPN1
PE1
P1
P2
PE2
VPN1
CE1
AS1
AS2
CE2 47867
CEBGP1
CEBGP2
XC-212
XC-213
XC-214
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
XC-215
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
XC-216
! 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
XC-217
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
XC-218
description Pax ip unnumbered Loopback0 frame-relay interface-dlci 24 ! router ospf 1 network 1.0.0.0 0.255.255.255 area 0
Router 2 p0/3
lo0:13.13.13.13 Router 5 e0/2 h3/1/0 a0/1/1 h2/1/0 Router 3 a2/0/0 a0/0/1 a0/0/0 a1/1/0
93.0.0.1 94.0.0.1
lo0:10.10.10.10
e0/1 e0/2
e0/3 Router 6
18970
Router 1 p0/3
lo0:14.14.14.14 a0/1/1
lo0:15.15.15.15
a0/0/0 a1/1/0
Switch 1
lo0:16.16.16.16
lo0:17.17.17.17
XC-219
Note
Note
XC-220
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 !
XC-221
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
XC-222
XC-223
XC-224
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 !
XC-225
interface Loopback0 ip address 17.17.17.17 255.255.255.255 ! interface ATM0/0/0 ip unnumbered Loopback0 tag-switching ip !
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
XC-226
Figure 58
LSC1 (Cisco 7200 series) ATM 3/0 1.1 Edge LSR1 (Cisco 7500 series) ATM 2/0/0 2.2 Cisco BPX1 1.3 1.3
LSC2 (Cisco 7200 series) ATM 3/0 1.1 2.2 Cisco BPX2 ATM 2/0/0 Edge LSR2 (Cisco 7200 series)
ATM-LSR
ATM-LSR
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
S6908
XC-227
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 !
XC-228
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
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 58:
LSC1 Configuration BPX1 and BPX2 Configuration LSC2 Configuration Edge LSR1 Configuration Edge LSR2 Configuration
Note
XC-229
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
XC-230
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).
XC-231
Figure 59
2.2
6400 UAC NSP Configuration 6400 UAC NRP LSC1 Configuration BPX1 and BPX2 Configuration 6400 UAC NRP LSC2 Configuration Edge LSR1 Configuration Edge LSR2 Configuration
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
XC-232
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
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
XC-233
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
Configuring ATM LSRs Through ATM Network Using Cisco 7200 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 the following:
Two LSCs (Cisco 7200 routers) Two BPX service nodes Two edge LSRs (Cisco 7500 and 7200 routers)
XC-234
Figure 60
LSC1 (Cisco 7200) A TM 3/0 1.1 A TM 2/0/0 2.2 Cisco BPX1 Edge LSR1 (Cisco 7500) A TM-LSR 1.3.2
LS (Cisco A 1.1
A TM network
1.3.2 Cisco
A TM
LSC1 Implementing Virtual Trunking Configuration BPX1 and BPX2 Configuration LSC2 Implementing Virtual Trunking Configuration Edge LSR1 Configuration Edge LSR2 Configuration
XC-235
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
XC-236
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 61 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).
Figure 61 Cisco 6400 NRP Operating as LSC Implementing Virtual Trunking
ATM network
1.3.2
2.2
ATM 2/0/0
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
34085
XC-237
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
XC-238
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
XC-239
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.
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
Figure 62
LSC 1A 7200 a3/0 1.1 a2/0 7200-1 LER a3/0 a2/0/0 7500-1 LER 1.6.12 1.6.22 1.2 2.2
LSC 2B 7200 a3/0 2.1 1.2 2.2 a2/0/0 a3/0/0 a2/0 7500-2 LER
1.6.12 1.6.22
7200-2 LER
35637
XC-240
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
XC-241
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
XC-242
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
XC-243
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
XC-244
XC-245
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.
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
XC-246
LSC 1 192.0.0.1
LSC 1 192.0.0.1
BPX 1
1.3
1.3
BPX 2
2.2 a2/0
ATM-LSR
ATM-LSR
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 !
46929
XC-247
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
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 !
XC-248
XC-249
netflow traffic-eng
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#
XC-250
Multilayer Switching
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
Terminology Introduction to MLS Key MLS Features MLS Implementation Standard and Extended Access Lists
XC-253
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 connectionlessthey 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.
XC-254
Description 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. Requires no end-system changes and no renumbering of subnets. It works with DHCP1 and requires no new routing protocols. 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 Resilience Allows you to respond to route failures and routing topology changes by performing hardware-assisted invalidation of flow entries. 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. 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. 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. 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. 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.
Access Lists
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
XC-255
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-RPs 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 64).
Figure 64 MLS Implementation
MLS-RP multicasts its MAC addresses and VLAN number to all MLS-SEs
MLS-RP
all MLS-SEs program the NFFC with the MSLP hello message information
(MLS-SE)
In Figure 65, 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-RPs 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 Bs) and its own MAC address as the source.
XC-256
12000
Figure 65
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
Host A
Host B
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 packets 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 66).
Figure 66 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
Host A
Host B
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 67). 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.
12002
12001
XC-257
Figure 67
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
See the Catalyst 5000 Series Multilayer Switching User Guide for additional network implementation examples that include network topologies that do not support MLS.
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.
XC-258
clear ip-routeClears all MLS cache entries for all Catalyst 5000 series switches performing Layer 3 switching for this MLS-RP. ip routingThe 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-connectionsDisables MLS on the interface. ip tcp header-compressionDisables 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).
XC-259
The network in the upper diagram in Figure 68 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 68, 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 68 Basic IP Multicast MLS Network Topology
Router
Trunk link VLANs 100, 200, 300 VLAN 100 G1 source G1 member G1 member VLAN 200 Switch G1 member VLAN 300
Router (MMLS-RP)
Trunk link VLANs 100, 200, 300 VLAN 100 G1 source G1 member G1 member VLAN 200
18952
Switch (MMLS-SE)
Improves throughputThe improves throughput feature improves the routers multicast Layer 3 forwarding and replication throughput. Reduces load on routerIf 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.
XC-260
Provides IP multicast scalabilityIf 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 statisticsIP multicast MLS provides flow statistics that can be used to administer, plan, and troubleshoot networks.
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.
XC-261
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 36:
Table 36 Layer 3-Switched Multicast Packet Header with Rewrite
XC-262
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.
XC-263
MLS-SEFor example, a Catalyst 5000 series switch with the Netflow Feature Card (NFFC II). The MLS-SE provides Layer 3 LAN-switching services. MLS-RPFor 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. MLSPThe protocol running between the MLS-SE and MLS-RP that enables MLS.
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.
XC-264
Destination modeThe 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 modeThe 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.
Note
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.
Encap
MLS-RP MAC
Host A MAC
Length Checksum/ Packet Destination IPX Type Net/Node/ Length/ Socket Transport Host B IPX Control1
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.
XC-265
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 Bs 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 38:
Table 38 Layer 3-Switched Packet with Rewrite from the MLS-RP
Encap
Length Checksum/ Packet Destination Type Net/Node/ IPX Socket Length/ Transport Host B IPX Control
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 69s 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.
XC-266
Figure 69
3/M Net
arke 03
Net
2/E
ngin
eer
02
ing
MAC = Cc
Data
01.Aa:02.Cc
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.
XC-267
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.
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.
Access Lists
The following sections describe how access lists affect MLS.
Note
Any input access list can be translated to an output access list to provide the same effect on the interface.
XC-268
IP Accounting
Enabling IP accounting on an MLS-enabled interface disables the IP accounting functions on that interface.
Note
Data Encryption
MLS is disabled on an interface when the data encryption feature 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.
XC-269
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
XC-270
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.
XC-271
Monitoring MLS for an Interface (Optional) Monitoring MLS Interfaces for VTP Domains (Optional)
Purpose Globally enables MLSP. MLSP is the protocol that runs between the MLS-SE and the MLS-RP. Selects a router interface. 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. 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. Enables each MLS 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.
Step 4
Step 5 Step 6
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
Router(config)# no mls rp ip
XC-272
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 Purpose Displays MLS details for all interfaces.
Command
Router# show mls rp
93
95
100
XC-273
93
95
100
XC-274
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.
Purpose 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.
Router Configuration Without Access Lists Example Router Configuration with a Standard Access List Example Router Configuration with an Extended Access List Example
XC-275
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
XC-276
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# 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:
XC-277
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
XC-278
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.
XC-279
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
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.
XC-280
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.
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
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)
XC-281
For examples of IP multicast MLS configurations, see the IP Multicast MLS Configuration Examples section later in this document.
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
Step 1 Step 2
Router(config)# interface type number Router(config-if)# ip pim {dense-mode | sparse-mode | sparse-dense-mode}
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.
XC-282
Purpose Displays hardware switching state for outgoing interfaces. Displays PIM interface information. Displays Layer 3 switching information.
Router# show ip pim interface [type number] [count] Router# show mls rp ip multicast [locate] [group [source] [vlan-id]] | [statistics] | [summary]
Basic IP Multicast MLS Network Examples Complex IP Multicast MLS Network Examples
XC-283
Network Topology Example Operation Before IP Multicast MLS Example Operation After IP Multicast MLS Example Router Configuration Switch Configuration
Router (MMLS-RP)
G1 source
Switch (MMLS-SE)
G1 A VLAN 10 10.1.10.0/24 B C G1
D G1 VLAN 30 10.1.30.0/24
VLAN 20 10.1.20.0/24
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)
XC-284
18501
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
XC-285
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.
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
XC-286
Router A (MMLS-RP)
Router B (MMLS-RP)
ISL trunks
Switch A (MMLS-SE)
D G1
E G1
C G1 VLAN 20 172.20.20.0/24
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)
18955
VLAN 30 172.20.30.0/24
XC-287
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.
Note
On both MMLS-RPs, no user-configured IP multicast MLS management interface is specified. Therefore, the VLAN 1 subinterface is used by default.
XC-288
XC-289
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)
XC-290
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.
XC-291
Restrictions
This section describes restrictions that apply to configuring IPX MLS on the router.
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).
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.
Input access listsRouter 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.
XC-292
Output access listsWhen 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 masksAccess 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.
IPX accountingIPX accounting cannot be enabled on an IPX MLS-enabled interface. IPX EIGRPMLS is supported for EIGRP interfaces if the Transport Control (TC) maximum is set to a value greater than the default (16).
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.
XC-293
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 commandspecifically 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
Router(config-if)# mls rp vtp-domain domain-name
Purpose Globally enables MLSP on the router. MLSP is the protocol that runs between the MLS-SE and MLS-RP.
This task is not required for RSM VLAN interfaces (virtual interfaces), ISL-encapsulated interfaces, or IEEE 802.1Q-encapsulated interfaces.
XC-294
To assign a VLAN ID to an IPX MLS interface, use the following command in interface configuration mode: Command
Router(config-if)# mls rp vlan-id vlan-id-number
Purpose 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.
Purpose 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.
Enter the show mls rp ipx EXEC command. Examine the output to learn if the VLANs are enabled. Examine the output to learn if the switches are listed by MAC address, indicating they are recognized by the MLS-RP.
XC-295
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
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 Router(config-if)# mls rp vtp-domain domain-name
Step 2
Purpose Displays information about all switches currently shortcutting for the specified IPX flow(s). Displays MLS details for a specific interface. Displays details for all IPX MLS interfaces on the router:
Router# show mls rp interface type number Router# show mls rp ipx
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.
Router#
Displays details about IPX MLS interfaces for a specific VTP domain.
XC-296
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
fa2/0 ISL Trunk link Catalyst 5509 Catalyst 5505 with NFFC (Switch B) (Switch A, MLS-SE) 1/1 3/1 Novell client NC1 1/1 ISL Trunk link 1/2 3/1 1/3
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
3/1
XC-297
23261
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.1IPX network 1 fastethernet2/0.10IPX network 10 fastethernet2/0.20IPX network 20 fastethernet2/0.30IPX 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.
XC-298
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)
XC-299
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
XC-300
XC-301
. . ! ! ! access-list 800 deny 1111 2222 access-list 800 permit FFFFFFFF FFFFFFFF . . . end
XC-302
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.
XC-305
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
Step 1 Step 2 Step 3 Step 4
Router(config)# ip multicast-routing distributed Router(config)# interface type number Router(config-if)# ip route-cache distributed
Purpose Enables MDS globally. Configures an interface. Enables distributed switching on the RSP. (This step is required on the RSP platform only.) 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.
Purpose 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
Router# clear ip mroute {* | group [source]} Router# clear ip pim interface count
Purpose Clears multicast routes and counts. Clears all packet counts on the line cards.
XC-306
To monitor MDS on the line cards, use the following commands in EXEC mode, as needed. Remember that to reach a line cards console, enter the attach slot# command, using the slot number where the line card resides. Command
Router# show ip mds forwarding [group-address] [source-address] Router# show ip mds summary
Purpose Displays the MFIB table, forwarding information, related flags, and counts. Displays a summary of the MFIB.
To monitor MDS on the RP, use the following commands in EXEC mode, as needed: Command
Router# show ip mds stats [switching | linecard] Router# show ip mds interface Router# show ip pim interface [type number] count
Purpose Displays switching statistics or line card statistics for MDS. Displays the status of MDS interfaces. Displays switching counts for unicast distributed fast switching and other fast switching statistics. Displays the contents of the IP fast-switching cache. Displays numbers of packets that were process switched, fast switched, and distributed switched.
XC-307
XC-308
VLANs
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:
XC-311
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 73 illustrates the difference between traditional physical LAN segmentation and logical VLAN segmentation.
Figure 73 LAN Segmentation and VLAN Segmentation
Traditional LAN segmentation VLAN segmentation VLAN 1 VLAN 2 VLAN 3
Floor 3
Floor 2
Router
Floor 1
XC-312
S6619
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 groups 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.
Relaying Function
XC-313
Relaying Function
The relaying function level, as displayed in Figure 74, is the lowest level in the architectural model described in the IEEE 802.1Q standard and presents three types of rules:
Ingress rulesRules relevant to the classification of received frames belonging to a VLAN. Forwarding rules between portsDecides to filter or forward the frame. Egress rules (output of frames from the switch)Decides if the frame must be sent tagged or untagged.
Relaying Function
Figure 74
Forwarding process
Ingress rules
Filtering database
Egress rules
Frame reception
Frame transmission
54713
XC-314
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 75 Tagging Scheme
6 6 2 2 2 Variable
Destination address Source address EtherType = 0x8100 Tag control information MAC length/type Data PAD
User priority
CFI
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.
Dest
Src
Len/Etype
Data
FCS
Original frame
Dest
Src
Etype
Tag
Len/Etype
Data
FCS
Tagged frame
PRI
54711
54712
XC-315
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 77, 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 77. 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 77 Native VLAN
VLAN A PVID = A Access ports PVID = B VLAN B Trunk link VLAN-aware bridge PVID = C VLAN-aware bridge PVID = C
VLAN A PVID = A Access ports PVID = B VLAN B VLAN C VLAN-unaware end station
PVID = 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:
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.
XC-316
54710
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.
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.
XC-317
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.
Inter-Switch Link Protocol IEEE 802.10 Protocol IEEE 802.1Q Protocol ATM LANE Protocol ATM LANE Fast Simple Server Replication Protocol
XC-318
All five of these technologies are based on OSI Layer 2 bridge multiplexing mechanisms.
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.
XC-319
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.
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 39 shows protocols supported for each VLAN encapsulation format and corresponding Cisco IOS software releases.
XC-320
Table 39
Protocol IP Novell IPX (default encapsulation) Novell IPX (configurable encapsulation) AppleTalk Phase II DECnet Banyan VINES XNS CLNS IS-IS
ISL Release 11.1 Release 11.1 Release 11.3 Release 11.3 Release 11.3 Release 11.3 Release 11.3 Release 12.1 Release 12.1
ATM LANE Release 10.3 Release 10.3 Release 10.3 Release 10.3 Release 11.0 Release 11.2 Release 11.2
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.
Sharing resources between VLANs Load balancing Redundant links Addressing Segmenting networks with VLANsSegmenting 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 networksIn 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.
XC-321
XC-322
XC-323
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation ISL Encapsulation Configuration Task List
Figure 78
Green Blue
Token Ring
Red
Red
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.
XC-324
S6621
Green
Blue
Red
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
Purpose Specifies the subinterface the VLAN will use. 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
Purpose Assigns the AppleTalk cable range and zone for the subinterface. Assigns the AppleTalk zone for the subinterface.
XC-325
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation ISL Encapsulation Configuration Task List
Enabling Banyan VINES Routing Defining the VLAN Encapsulation Format Configuring Banyan VINES on the Subinterface
Purpose Specifies the subinterface on which ISL will be used. Defines the encapsulation format as ISL (isl), and specifies the VLAN identifier.
XC-326
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
Purpose Specifies the subinterface on which ISL will be used. Defines the encapsulation format as ISL (isl), and specifies the VLAN identifier.
XC-327
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation ISL Encapsulation Configuration Task List
Figure 79 illustrates HSRP in use with ISL providing routing between several VLANs.
Figure 79 Hot Standby Router Protocol in VLAN Configurations
VLAN 20
VLAN 10
VLAN 40
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.
XC-328
S6620
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation ISL Encapsulation Configuration Task List
Purpose Specifies the subinterface on which ISL will be used. Defines the encapsulation format, and specifies the VLAN identifier.
Purpose 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
Router(config-if)# standby [group-number] ip [ip-address [secondary]]
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
Router(config-if)# standby [group-number] timers hellotime holdtime
Purpose Configures the time between hello packets and the hold time before other routers declare the active router to be down. Sets the Hot Standby priority used to choose the active router. 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.
XC-329
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation ISL Encapsulation Configuration Task List
Command
Router(config-if)# standby [group-number] track type-number [interface-priority]
Purpose 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. Selects an authentication string to be carried in all HSRP messages.
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
Router(config)# ip routing
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.
Purpose Specifies the subinterface on which TRISL will be used. 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.
XC-330
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation ISL Encapsulation Configuration Task List
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.
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.
XC-331
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
Purpose Specifies the subinterface on which SDE will be used. Defines the encapsulation format and specifies the VLAN identifier.
XC-332
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
Purpose Specifies the subinterface on which TRISL will be used. Defines the encapsulation for TRISL.
XC-333
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.
CyBus
Versatile Interface Processor Distributed IP forwarding cache Fast Fast Ethernet Ethernet
Versatile Interface Processor Distributed IP forwarding cache Fast Fast Ethernet Ethernet
VLAN 1,2,3
VLAN 4,5,6
VLAN 7,8,9
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.
XC-334
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
Router(config)# ip routing
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.
Purpose Specifies the interface and interface configuration mode. Enables VIP distributed switching of IP packets on the interface.
Purpose Specifies the interface, and enters interface configuration mode. Defines the encapsulation format as ISL, and specifies the VLAN identifier.
XC-335
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
Purpose Specifies the subinterface on which ISL will be used. Defines the encapsulation format as ISL (isl), and specifies the VLAN identifier.
Enabling CLNS Routing Defining the VLAN Encapsulation Format Configuring CLNS on the Subinterface
XC-336
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation ISL Encapsulation Configuration Task List
Purpose Specifies the subinterface on which ISL will be used. Defines the encapsulation format as ISL (isl), and specifies the VLAN identifier.
Enabling IS-IS Routing Defining the VLAN Encapsulation Format Configuring IS-IS on the Subinterface
XC-337
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation ISL Encapsulation Configuration Examples
Purpose Enables IS-IS routing, and enters router configuration mode. Configures the NET for the routing process.
Purpose Specifies the subinterface on which ISL will be used. Defines the encapsulation format as ISL (isl), and specifies the VLAN identifier.
AppleTalk Routing over ISL Configuration Examples Banyan VINES Routing over ISL Configuration Example DECnet Routing over ISL Configuration Example
XC-338
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
FDDI SDE fddi 1/0 Cisco 7500 series router Wide-area link FastEthernet 2/0 100BASE-T ISL Catalyst 5000 switch supporting 2 AppleTalk VLANs on FastEthernet connections with ISL encapsulation
S6241
As shown in Figure 81, 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 81.
Cisco 7500 Router Configuration
! appletalk routing interface Fddi 1/0.100 encapsulation sde 100
XC-339
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
XC-340
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation ISL Encapsulation Configuration Examples
Figure 82
Enterprise network
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 Cisco IOS Router B on FastEthernet ISL connection to a Catalyst 5000 switch
ISL VLAN 110 Port 2/8 Port 5/3 Catalyst VLAN switch Ethernet 1/2 Ethernet 1/2 Host 1 Ethernet 1/2 Ethernet 1/2 Host 2
S6239
The topology shown in Figure 82 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 82, 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
XC-341
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 !
Port 2
End station
End station
XC-342
11250
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
End station
End station
11251
XC-343
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation ISL Encapsulation Configuration Examples
Wide-area link carrying VLAN traffic Cisco 7200 router running traffic between VLANs
FE 2/0
FE 3/0 VLAN 70
VLAN 20
VLAN 30
VLAN 20 Configuration
ipx routing interface FastEthernet 2/0 no shutdown interface FastEthernet 2/0.20 encapsulation isl 20 ipx network 20 encapsulation sap
XC-344
S6240
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
Routing with RIF Between a TRISL VLAN and a Token Ring Interface Example
Figure 86 shows routing with RIF between a TRISL VLAN and a Token Ring interface.
Figure 86 Routing with RIF Between a TRISL VLAN and a Token Ring Interface
Catalyst 5000 switch
Token Ring 1
End station
End station
End station
End station
10777
XC-345
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation ISL Encapsulation Configuration Examples
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
XC-346
Configuring Routing Between VLANs with Inter-Switch Link Encapsulation ISL Encapsulation Configuration Examples
Figure 87
WAN
RSP Cisco 7500 series router with VIP2 or later cards routing traffic between VLANs CyBus VIP VIP Fast Ethernet port adapters
FE
FE
FE
FE
Fast Ethernet links carrying ISL VLAN traffic Catalyst VLAN switches forwarding ISL VLAN traffic
In Figure 87, 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 87:
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
S6238
ISL VLAN 1
ISL VLAN 2
ISL VLAN 3
ISL VLAN 4
ISL VLAN 5
ISL VLAN 6
ISL VLAN 7
XC-347
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
XC-348
XC-349
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
Note
For more information on configuring AppleTalk, see the Configuring AppleTalk chapter in the Cisco IOS AppleTalk and Novell IPX Configuration Guide.
Purpose Assigns the AppleTalk cable range and zone for the subinterface. Assigns the AppleTalk zone for the subinterface.
XC-350
Configuring Routing Between VLANs with IEEE 802.10 Encapsulation Routing AppleTalk over IEEE 802.10 Configuration Example
Purpose Specifies the subinterface the VLAN will use. Defines the encapsulation format as IEEE 802.10 (sde) and specifies the VLAN identifier or security association identifier, respectively.
FDDI SDE fddi 1/0 Cisco 7500 series router Wide-area link FastEthernet 2/0 100BASE-T ISL Catalyst 5000 switch supporting 2 AppleTalk VLANs on FastEthernet connections with ISL encapsulation
S6241
XC-351
Configuring Routing Between VLANs with IEEE 802.10 Encapsulation Routing AppleTalk over IEEE 802.10 Configuration Example
As shown in Figure 88, 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 88.
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
XC-352
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.
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
XC-353
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)
Enabling AppleTalk Routing Configuring AppleTalk on the Subinterface Defining the VLAN Encapsulation Format
Note
For more information on configuring AppleTalk, see the Configuring AppleTalk chapter in the Cisco IOS AppleTalk and Novell IPX Configuration Guide.
XC-354
Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation IEEE 802.1Q Encapsulation VLANs Configuration Task List
Purpose Assigns the AppleTalk cable range and zone for the subinterface. Assigns the AppleTalk zone for the subinterface.
Purpose Specifies the subinterface the VLAN will use. Defines the encapsulation format as IEEE 802.1Q (dot1q), and specifies the VLAN identifier.
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
Router(config)# ip routing
XC-355
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.
Purpose Specifies the subinterface on which IEEE 802.1Q will be used. Defines the encapsulation format as IEEE 802.1Q (dot1q), and specifies the VLAN identifier
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.
Enabling NetWare Routing Defining the VLAN Encapsulation Format Configuring NetWare on the Subinterface
XC-356
Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation IEEE 802.1Q Encapsulation VLANs Configuration Task List
Purpose Specifies the subinterface on which IEEE 802.1Q will be used. Defines the encapsulation format as IEEE 802.1Q and specifies the VLAN identifier.
Purpose Selects a particular Fast Ethernet interface for configuration. Enables IEEE 802.1Q encapsulation of traffic on a specified subinterface in VLANs, and defaults the associated VLAN as a native VLAN. Assigns each network interface to a bridge group.
Step 3
Note
If there is no explicitly defined native VLAN, the default VLAN 1 becomes the native VLAN 1.
XC-357
Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation IEEE 802.1Q Encapsulation Configuration Examples
Purpose Selects a particular Fast Ethernet interface for configuration. Enables IEEE 802.1Q encapsulation of traffic on a specified subinterface in VLANs, and defaults to 1. Assigns each network interface to a bridge group.
Step 3
Note
If there is an explicitly defined native VLAN, VLAN 1 will only be used to process CST.
!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
XC-358
Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation IEEE 802.1Q Encapsulation Configuration Examples
XC-359
Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation IEEE 802.1Q Encapsulation Configuration Examples
XC-360
Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation IEEE 802.1Q Encapsulation Configuration Examples
XC-361
Configuring Routing Between VLANs with IEEE 802.1Q Encapsulation IEEE 802.1Q Encapsulation Configuration Examples
XC-362
LAN Emulation
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:
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.
XC-365
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 clientA 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.
LESThe 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 BUSThe 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.
LECSThe 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 LECSs 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.
XC-366
Figure 89 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 89
LE server 12 7 11 11 9 10 9
4 5 6 2
4
S3736
Client A 17 28 311 Control direct Control distribute Configure direct (client) 49 510 66 1112
Client B
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 requests to join an ELANThe client sets up a connection to the LECSa bidirectional point-to-point Configure Direct VCCto 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 LESUsing the same VCC, the LECS returns the ATM address and the name of the LES for the clients ELAN. Client contacts the server for its LANThe 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 ELANThe server for the ELAN sets up a connection to the LECS to verify that the client is allowed to join the ELANa bidirectional point-to-point Configure Direct (server) VCC. The servers configuration request contains the clients 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.
XC-367
LES allows or disallows the client to join the ELANIf 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 1sSending 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.)
XC-368
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.
Router 1
Cisco LightStream ATM switch man client Router 2 Router 3 man client
S5040
XC-369
Cisco LightStream ATM switch man client eng client Router 2 Router 3 mkt server-bus man client mkt client Router 4 man client mkt client
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.
XC-370
S5039
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
Note
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.
XC-371
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 ATMs 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 serverA 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 serverA 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 serverA 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 clientAn 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 switchesany ATM switch that supports the Interim Local Management Interface (ILMI) and signalling. Multiple emulated LANs can coexist on a single ATM network.
XC-372
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).
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
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
(SRT)
AppleTalk for (IOS) TR-LANE and includes Appletalk fast switched routing. DECnet, Banyan VINES, and XNS protocols are not supported
Ciscos 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.
XC-373
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:
Cisco 4500-M, Cisco 4700-M Cisco 7200 series Cisco 7500 series
Note
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 duplextwo 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.
XC-374
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)
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 componentexcept 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.
XC-375
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.
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 40 indicates how the values of unspecified digits are determined when an ATM address template is used:
Table 40 Values of Unspecified Digits in ATM Address Templates
Value Is Obtained from ATM switch via Interim Local Management Interface (ILMI) Filled with the slot MAC address1 plus
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.
XC-376
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.
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 LECSs ATM Address on the Cisco Switch Setting Up the LECSs 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:
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.
XC-377
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 LECSs database.
Purpose Sets the local node ID (prefix of the ATM address). Exits global configuration mode. 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
Step 1 Step 2
Router(config-route-map)# set local name ip-address mask prefix Router(config-route-map)# save
Purpose Sets the local node ID (prefix of the ATM address). 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.
XC-378
Purpose Specifies the major ATM interface and enter interface configuration mode:
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
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. Sets up a PVC to communicate with the ILMI; the vpi and vci values are usually set to 0 and 16, respectively.
Step 3
XC-379
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
Step 1
Router(config)# atm lecs-address-default lecsaddress [sequence #]1
Purpose Specifies the LECSs ATM address for the entire switch. If you are configuring SSRP, include the ATM addresses of all the LECSs. Exits global configuration mode. Saves the configuration value permanently.
Step 2 Step 3
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
Step 1
Router(config-if)# atm lecs-address lecsaddress [sequence #]1
Purpose Specifies the LECSs ATM address for a port. If you are configuring SSRP, include the ATM addresses of all the LECSs. Exits interface configuration mode. Saves the configuration value permanently.
Step 2 Step 3
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 LECSs ATM address into the Cisco LightStream 100 ATM switch and save it permanently, use the following commands in privileged EXEC mode: Command
Step 1
Router# set configserver index atm-address
Purpose Specifies the LECSs 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. Saves the configuration value permanently.
Step 2
Router# save
XC-380
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
Purpose Creates a named database for the LECS. 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
If you are configuring a Token Ring ELAN, assigns a segment number to the emulated Token Ring LAN in the configuration database. In the configuration database, provides a default name for the ELAN. Exits from database configuration mode and return to global configuration mode.
Step 4 Step 5
XC-381
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.
Purpose Creates a named database for the LECS. 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
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
For a Token Ring ELAN, assigns a segment number to the first emulated Token Ring LAN in the configuration database. 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.
Step 5
XC-382
Command
Step 6 Step 7
Router(lane-config-dat)# default-name elan-name1 Router(lane-config-dat)# exit
Purpose (Optional) Specifies a default ELAN for LANE clients not explicitly bound to an ELAN. 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.
Purpose Creates a named database for the LECS. 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
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.
XC-383
Command
Step 4
Router(lane-config-dat)# name elan-name1 local-seg-id segment-number
Purpose For a Token Ring ELAN, assigns a segment number to the first emulated Token Ring LAN in the configuration database. 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 5
Step 6
Adds a database entry associating a specific clients ATM address with the first restricted-membership ELAN. Repeat this step for each of the clients of the first restricted-membership ELAN.
Step 7
Adds a database entry associating a specific clients 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.
Purpose If you are not currently configuring the interface, specifies the major ATM interface where the LECS is located.
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
Link the LECSs database name to the specified major interface, and enable the LECS.
XC-384
Command
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 Router(config-if)# lane config fixed-config-atm-address Router(config-if)# lane config config-atm-address atm-address-template
Purpose Specifies how the LECSs 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. The LECS will not participate in SSRP, the LECS is the master, and only the well-known address is used. The LECS will participate in SSRP and the address is computed using an explicit, 20-byte ATM address. Exits interface configuration mode. Returns to EXEC mode. Saves the configuration.
Setting Up the Server, BUS, and a Client on a Subinterface Setting Up Only a Client on a Subinterface
XC-385
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 Step 3
Router(config-if)# lane server-bus {ethernet | tokenring} elan-name Router(config-if)# lane client {ethernet | tokenring} [elan-name] [elan-id id]
Enables a LES and a LANE BUS for the ELAN. (Optional) Enables a LANE client for the ELAN. To participate in MPOA, configures the LES and a LANE BUS for the ELAN with the ELAN ID.
Provides a protocol address for the client. Returns to EXEC mode. Saves the configuration.
1. The command or commands depend on the routing protocol used. If you are using IPX or AppleTalk, see the relevant protocol chapter (IPX or AppleTalk) in the Cisco IOS AppleTalk and Novell IPX Configuration Guide for the commands to use.
If the ELAN in Step 3 is intended to have restricted membership, consider carefully whether you want to specify its name here. You will specify the name in the LECSs database when it is set up. However, if you link the client to an ELAN in this step, and through some mistake it does not match the database entry linking the client to an ELAN, this client will not be allowed to join this ELAN or any other. If you do decide to include the name of the ELAN linked to the client in Step 3 and later want to associate that client with a different ELAN, make the change in the LECSs database before you make the change for the client on this subinterface. Each ELAN is a separate subnetwork. In Step 4 make sure that the clients of the same ELAN are assigned protocol addresses on the same subnetwork and that clients of different emulated LANs are assigned protocol addresses on different subnetworks.
XC-386
To set up only a client for an emulated LANs, use the following commands beginning in interface configuration mode: Command
Step 1
Router(config)# interface atm slot/0.subinterface-number Router(config)# interface atm slot/port-adapter/0.subinterface-number Router(config)# interface atm number.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.
Provides a protocol address for the client on this subinterface. Enables a LANE client for the ELAN. Returns to EXEC mode. Saves the configuration.
Router(config-if)# lane client {ethernet | tokenring} [elan-name] Router(config-if)# Ctrl-Z Router# copy system:running-config nvram:startup-config
1. The command or commands depend on the routing protocol used. If you are using IPX or AppleTalk, see the relevant protocol chapter (IPX or AppleTalk) in the Cisco IOS AppleTalk and Novell IPX Configuration Guide for the commands to use.
Each ELAN is a separate subnetwork. In Step 2, make sure that the clients of the same ELAN are assigned protocol addresses on the same subnetwork and that clients of different emulated LANs are assigned protocol addresses on different subnetworks.
Note
Disabling the LE_FLUSH process affects all the LECs in a Cisco networking device. To keep LECs from sending LE_FLUSH messages to the remote LEC, use the following command in interface configuration mode:
Command
Router(config-if)# no lane client flush
XC-387
Purpose Configures the ELAN ID in the LAN Emulation Client Server (LECS) database to participate in MPOA. Configures the LES and a LANE BUS for the ELAN (ELAN). To participate in MPOA, configure the LES and a LANE BUS for the ELAN with the ELAN ID.
Caution
If an ELAN ID is supplied by both commands, make sure that the ELAN ID matches in both. For more information on configuring the MPOA client, refer to the Configuring the Multiprotocol over ATM Client chapter.
Note
This server redundancy does not overcome other points of failure beyond the router ports: Additional redundancy on the LAN side or in the ATM switch cloud are not a part of the LANE simple server redundancy feature.
XC-388
All the ATM switches must have identical lists of the global LECS addresses, in the identical priority order. The operating LECSs must use exactly the same configuration database. Load the configuration table data using the copy {rcp | tftp} system:running-config command. This method minimizes errors and enables the database to be maintained centrally in one place.
The LANE protocol does not specify where any of the ELAN server entities should be located, but for the purpose of reliability and performance, Cisco implements these server components on its routers.
Implementation Considerations
The following is a list of LANE implementation restrictions:
The LightStream 1010 can handle up to 16 LECS addresses. The LightStream 100 allows a maximum of 4 LECS addresses. There is no limit on the number of LE servers that can be defined per ELAN. When a LECS switchover occurs, no previously joined clients are affected.
XC-389
When a LES/BUS switches over, momentary loss of clients occurs until they are all transferred to the new LES/BUS. LECSs come up as masters until a higher-level LECS tells them otherwise. This is automatic and cannot be changed. If a higher-priority LES comes online, it bumps the current LES off on the same ELAN. Therefore, there may be some flapping of clients from one LES to another after a powerup, depending on the order of the LE servers coming up. Flapping should settle after the last highest-priority LES comes up. If none of the specified LE servers are up or connected to the master LECS and more than one LES is defined for an ELAN, a configuration request for that specific ELAN is rejected by the LECS. Changes made to the list of LECS addresses on ATM switches may take up to a minute to propagate through the network. Changes made to the configuration database regarding LES addresses take effect almost immediately. If none of the designated LECSs is operational or reachable, the ATM Forum-defined well-known LECS address is used. You can override the LECS address on any subinterface, by using the following commands:
lane auto-config-atm-address lane fixed-config-atm-address lane config-atm-address
Caution
When an override like this is performed, fault-tolerant operation cannot be guaranteed. To avoid affecting the fault-tolerant operation, do not override any LECS, LES or BUS addresses.
If an underlying ATM network failure occurs, there may be multiple master LECSs and multiple active LE servers for the same ELAN. This situation creates a partitioned network. The clients continue to operate normally, but transmission between different partitions of the network is not possible. When the network break is repaired, the system recovers. When the LECS is already up and running, and you use the lane config fixed-config-atm-address interface command to configure the well-known LECS address, be aware of the following scenarios:
If you configure the LECS with only the well-known address, the LECS will not participate in
the SSRP, act as a standalone master, and only listen on the well-known LECS address. This scenario is ideal if you want a standalone LECS that does not participate in SSRP, and you would like to listen to only the well-known address.
If only the well-known address is already assigned, and you assign at least one other address to
the LECS, (additional addresses are assigned using the lane config auto-config-atm-address interface command and/or the lane config config-atm-address interface command) the LECS will participate in the SSRP and act as the master or slave based on the normal SSRP rules. This scenario is ideal if you would like the LECS to participate in SSRP, and you would like to make the master LECS listen on the well-known address.
If the LECS is participating in SSRP, has more than one address (one of which is the well-known
address), and all the addresses but the well-known address is removed, the LECS will declare itself the master and stop participating in SSRP completely.
If the LECS is operating as an SSRP slave, and it has the well-known address configured, it will
configure the LECS with the well-known address and at least one other address.
XC-390
XC-391
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.
Displays the global and per-VCC LANE information for the BUS configured on any subinterface or ELAN.
Router# show lane bus [interface atm slot/0[.subinterface-number] | name elan-name] [brief] Router# show lane bus [interface atm slot/port-adapter/ 0 [.subinterface-number] | name elan-name] [brief] Router# show lane bus [interface atm number[.subinterface-number] | name elan-name] [brief]
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.
Displays the global and per-VCC LANE information for all LANE clients configured on any subinterface or ELAN.
Router# show lane client [interface atm slot/0[.subinterface-number] | name elan-name] [brief] Router# show lane client [interface atm slot/port-adapter/0[.subinterface-number] | name elan-name] [brief] Router# show lane client [interface atm number[.subinterface-number] | name elan-name] [brief]
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.
XC-392
Command
Purpose Displays the global and per-VCC LANE information for the LECS configured on any interface.
Router# show lane config [interface atm slot/0] Router# show lane config [interface atm slot/port-adapter/0] Router# show lane config [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.
Displays the LECSs database. Displays the automatically assigned ATM address of each LANE component in a router or on a specified interface or subinterface.
Router# show lane default-atm-addresses [interface atm slot/0.subinterface-number] Router# show lane default-atm-addresses [interface atm slot/port-adapter/0.subinterface-number] Router# show lane default-atm-addresses [interface atm number.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.
Display the LANE ARP table of the LANE client configured on the specified subinterface or ELAN.
Router# show lane le-arp [interface atm slot/0[.subinterface-number] | name elan-name] Router# show lane le-arp [interface atm slot/port-adapter/0[.subinterface-number] | name elan-name] Router# show lane le-arp [interface atm number[.subinterface-number] | name elan-name]
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.
Display the global and per-VCC LANE information for the LES configured on a specified subinterface or ELAN.
Router# show lane server [interface atm slot/0[.subinterface-number] | name elan-name] [brief] Router# show lane server [interface atm slot/port-adapter/0[.subinterface-number] | name elan-name] [brief] Router# show lane server [interface atm number[.subinterface-number] | name elan-name] [brief]
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.
XC-393
Default Configuration for a Single Ethernet ELAN Example Default Configuration for a Single Ethernet ELAN with a Backup LECS and LES Example Multiple Token Ring ELANs with Unrestricted Membership Example Multiple Token Ring ELANs with Restricted Membership Example TR-LANE with 2-Port SRB Example TR-LANE with Multiport SRB Example Routing Between Token Ring and Ethernet Emulated LANs Example Disabling LANE Flush Process Example
All examples use the automatic ATM address assignment method described in the Method of Automatically Assigning ATM Addresses section earlier in this chapter. These examples show the LANE configurations, not the process of determining the ATM addresses and entering them.
Router 2 Configuration
interface atm 1/0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi interface atm 1/0.1 ip address 172.16.0.3 255.255.255.0 lane client ethernet
Router 3 Configuration
interface atm 2/0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi interface atm 2/0.1
XC-394
Router 4 Configuration
interface atm 1/0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi interface atm 1/0.3 ip address 172.16.0.5 255.255.255.0 lane client ethernet
Default Configuration for a Single Ethernet ELAN with a Backup LECS and LES Example
This example configures four Cisco 7500 series routers for one ELAN with fault tolerance. Router 1 contains the LECS, the server, the BUS, and a client. Router 2 contains the backup LECS and the backup LES for this ELAN and another client. Routers 3 and 4 contain clients only. This example accepts all default settings that are provided. For example, it does not explicitly set ATM addresses for the various LANE components collocated on the router. Membership in this LAN is not restricted.
Router 1 Configuration
lane database example1 name eng server-atm-address 39.000001415555121101020304.0800.200c.1001.01 name eng server-atm-address 39.000001415555121101020304.0612.200c 2001.01 default-name eng interface atm 1/0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi lane config auto-config-atm-address lane config database example1 interface atm 1/0.1 ip address 172.16.0.1 255.255.255.0 lane server-bus ethernet eng lane client ethernet
Router 2 Configuration
lane database example1_backup name eng server-atm-address 39.000001415555121101020304.0800.200c.1001.01 name eng server-atm-address 39.000001415555121101020304.0612.200c 2001.01 (backup LES) default-name eng interface atm 1/0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi lane config auto-config-atm-address lane config database example1_backup interface atm 1/0.1 ip address 172.16.0.3 255.255.255.0 lane server-bus ethernet eng lane client ethernet
Router 3 Configuration
interface atm 2/0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi interface atm 2/0.1 ip address 172.16.0.4 255.255.255.0 lane client ethernet
XC-395
Router 4 Configuration
interface atm 1/0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi interface atm 1/0.3 ip address 172.16.0.5 255.255.255.0 lane client ethernet
Cisco LightStream ATM switch man client eng client Router 2 Router 3 mkt server-bus man client mkt client Router 4 man client mkt client
The LECS (there is one LECS for this group of emulated LANs) The LES and BUS for the ELAN for Manufacturing (man) The LES and BUS for the ELAN for Engineering (eng)
XC-396
S5039
A LANE client for the ELAN for Manufacturing (man) A LANE client for the ELAN for Engineering (eng)
A LANE client for the ELAN for Manufacturing (man) A LANE client for the ELAN for Engineering (eng)
A LANE client for the ELAN for Manufacturing (man) A LANE client for the ELAN for Marketing (mkt)
The LES and BUS for the ELAN for Marketing (mkt) A LANE client for the ELAN for Manufacturing (man) A LANE client for the ELAN for Marketing (mkt)
For the purposes of this example, the four routers are assigned ATM address prefixes and end system identifiers (ESIs) as shown in Table 41 (the ESI part of the ATM address is derived from the first MAC address of the AIP shown in the example).
Table 41 ATM Prefixes for TR-LANE Example
Router 1 Configuration
Router 1 has the LECS and its database, the server and BUS for the Manufacturing ELAN, the server and BUS for the Engineering ELAN, a client for Manufacturing, and a client for Engineering. Router 1 is configured as shown in this example:
!The following lines name and configure the configuration servers database. lane database example2 name eng server-atm-address 39.000001415555121101020304.0800.200c.1001.02 name eng local-seg-id 1000 name man server-atm-address 39.000001415555121101020304.0800.200c.1001.01 name man local-seg-id 2000 name mkt server-atm-address 39.000001415555121101020304.0800.200c.4001.01 name mkt local-seg-id 3000 default-name man ! ! The following lines bring up the configuration server and associate ! it with a database name. interface atm 1/0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi lane config auto-config-atm-address lane config database example2 ! ! The following lines configure the man server, broadcast-and-unknown server, ! and the client on atm subinterface 1/0.1. The client is assigned to the default
XC-397
! emulated lan. interface atm 1/0.1 ip address 172.16.0.1 255.255.255.0 lane server-bus tokenring man lane client tokenring man ! ! The following lines configure the eng server, broadcast-and-unknown server, ! and the client on atm subinterface 1/0.2. The client is assigned to the ! engineering emulated lan. Each emulated LAN is a different subnetwork, so the eng ! client has an IP address on a different subnetwork than the man client. interface atm 1/0.2 ip address 172.16.1.1 255.255.255.0 lane server-bus tokenring eng lane client tokenring eng
Router 2 Configuration
Router 2 is configured for a client of the Manufacturing ELAN and a client of the Engineering ELAN. Because the default ELAN name is man, the first client is linked to that ELAN name by default. Router 2 is configured as follows:
interface atm 1/0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi interface atm 1/0.1 ip address 172.16.0.2 255.255.255.0 lane client tokenring interface atm 1/0.2 ip address 172.16.1.2 255.255.255.0 lane client tokenring eng
Router 3 Configuration
Router 3 is configured for a client of the Manufacturing ELAN and a client of the Marketing ELAN. Because the default ELAN name is man, the first client is linked to that ELAN name by default. Router 3 is configured as shown here:
interface atm 2/0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi interface atm 2/0.1 ip address 172.16.0.3 255.255.255.0 lane client tokenring interface atm 2/0.2 ip address 172.16.2.3 255.255.255.0 lane client tokenring mkt
Router 4 Configuration
Router 4 has the server and BUS for the Marketing ELAN, a client for Marketing, and a client for Manufacturing. Because the default ELAN name is man, the second client is linked to that ELAN name by default. Router 4 is configured as shown here:
interface atm 3/0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi interface atm 3/0.1 ip address 172.16.2.4 255.255.255.0 lane server-bus tokenring mkt lane client tokenring mkt
XC-398
Cisco LightStream ATM switch man client eng client Router 2 Router 3 mkt server-bus man client mkt client Router 4 man client mkt client
Router 1 Configuration
Router 1 has the LECS and its database, the server and BUS for the Manufacturing ELAN, the server and BUS for the Engineering ELAN, a client for Manufacturing, and a client for Engineering. It also has explicit database entries binding the ATM addresses of LANE clients to specified, named emulated LANs. Router 1 is configured as shown here:
! The following lines name and configure the configuration servers database. lane database example3 name eng server-atm-address 39.000001415555121101020304.0800.200c.1001.02 restricted name eng local-seg-id 1000 name man server-atm-address 39.000001415555121101020304.0800.200c.1001.01 name man local-seg-id 2000 name mkt server-atm-address 39.000001415555121101020304.0800.200c.4001.01 restricted name mkt local-seg-id 3000 ! ! The following lines add database entries binding specified client ATM ! addresses to emulated LANs. In each case, the Selector byte corresponds ! to the subinterface number on the specified router.
S5039
XC-399
! The next command client-atm-address ! The next command client-atm-address ! The next command client-atm-address ! The next command client-atm-address default-name man
binds the client on Router 1s subinterface 2 to 39.0000014155551211.0800.200c.1000.02 name eng binds the client on Router 2s subinterface 2 to 39.0000014155551211.0800.200c.2000.02 name eng binds the client on Router 3s subinterface 2 to 39.0000014155551211.0800.200c.3000.02 name mkt binds the client on Router 4s subinterface 1 to 39.0000014155551211.0800.200c.4000.01 name mkt
the eng ELAN. the eng ELAN. the mkt ELAN. the mkt ELAN.
! ! The following lines bring up the configuration server and associate ! it with a database name. interface atm 1/0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi lane config auto-config-atm-address lane config database example3 ! ! The following lines configure the man server/broadcast-and-unknown server, ! and the client on atm subinterface 1/0.1. The client is assigned to the default ! emulated lan. interface atm 1/0.1 ip address 172.16.0.1 255.255.255.0 lane server-bus tokenring man lane client tokenring ! ! The following lines configure the eng server/broadcast-and-unknown server ! and the client on atm subinterface 1/0.2. The configuration server assigns the ! client to the engineering emulated lan. interface atm 1/0.2 ip address 172.16.1.1 255.255.255.0 lane server-bus tokenring eng lane client tokenring eng
Router 2 Configuration
Router 2 is configured for a client of the Manufacturing ELAN and a client of the Engineering ELAN. Because the default ELAN name is man, the first client is linked to that ELAN name by default. Router 2 is configured as shown in this example:
interface atm 1/0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi ! This client is not in the configuration servers database, so it will be ! linked to the man ELAN by default. interface atm 1/0.1 ip address 172.16.0.2 255.255.255.0 lane client tokenring ! A client for the following interface is entered in the configuration ! servers database as linked to the eng ELAN. interface atm 1/0.2 ip address 172.16.1.2 255.255.255.0 lane client tokenring eng
Router 3 Configuration
Router 3 is configured for a client of the Manufacturing ELAN and a client of the Marketing ELAN. Because the default ELAN name is man, the first client is linked to that ELAN name by default. The second client is listed in the database as linked to the mkt ELAN. Router 3 is configured as shown in this example:
XC-400
interface atm 2/0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi ! The first client is not entered in the database, so it is linked to the ! man ELAN by default. interface atm 2/0.1 ip address 172.16.0.3 255.255.255.0 lane client tokenring man ! The second client is explicitly entered in the configuration servers ! database as linked to the mkt ELAN. interface atm 2/0.2 ip address 172.16.2.3 255.255.255.0 lane client tokenring mkt
Router 4 Configuration
Router 4 has the server and BUS for the Marketing ELAN, a client for Marketing, and a client for Manufacturing. The first client is listed in the database as linked to the mkt emulated LANs. The second client is not listed in the database, but is linked to the man ELAN name by default. Router 4 is configured as shown here:
interface atm 3/0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi ! The first client is explicitly entered in the configuration servers ! database as linked to the mkt ELAN. interface atm 3/0.1 ip address 172.16.2.4 255.255.255.0 lane server-bus tokenring mkt lane client tokenring mkt ! The following client is not entered in the database, so it is linked to the ! man ELAN by default. interface atm 3/0.2 ip address 172.16.0.4 255.255.255.0 lane client tokenring
Router 2
Token Ring
Client
S5993
XC-401
Router 1 Configuration
Router 1 contains the LECS, the server and BUS, and a client. Router 1 is configured as shown in this example:
hostname Router1 ! ! The following lines configure the database cisco_eng. lane database cisco_eng name elan1 server-atm-address 39.020304050607080910111213.00000CA05B41.01 name elan1 local-seg-id 2048 default-name elan1 ! interface Ethernet0/0 ip address 10.6.10.4 255.255.255.0 ! ! The following lines configure a configuration server using the cisco_eng database on ! the interface. No IP address is needed since we are using source-route bridging. interface ATM2/0 no ip address atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi lane config auto-config-atm-address lane config database cisco_eng ! ! The following lines configure the server-bus and the client on the subinterface and ! specify source-route bridging information. interface ATM2/0.1 multipoint lane server-bus tokenring elan1 lane client tokenring elan1 source-bridge 2048 1 1 source-bridge spanning ! ! The following lines configure source-route bridging on the Token Ring interface. interface TokenRing3/0/0 no ip address ring-speed 16 source-bridge 1 1 2048 source-bridge spanning ! router igrp 65529 network 10.0.0.0
Router 2 Configuration
Router 2 contains only a client for the ELAN. Router 2 is configured as shown here:
hostname Router2 ! interface Ethernet0/0 ip address 10.6.10.5 255.255.255.0 ! ! The following lines configure source-route bridging on the Token Ring interface. interface TokenRing1/0 no ip address ring-speed 16 source-bridge 2 2 2048 source-bridge spanning ! ! The following lines set up the signalling and ILMI PVCs. interface ATM2/0 no ip address
XC-402
atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi ! ! The following lines set up a client on the subinterface and configure ! source-route bridging. interface ATM2/0.1 multipoint ip address 1.1.1.2 255.0.0.0 lane client tokenring elan1 source-bridge 2048 2 2 source-bridge spanning ! router igrp 65529 network 10.0.0.0
Virtual ring
Virtual ring
Token Ring
Token Ring
Router 1 Configuration server Server-bus Client Cisco LightStream 1010 ATM switch
Router 2 Client
S5994
Router 1 Configuration
Router 1 contains the LECS, the server and BUS, and a client. Router 1 is configured as shown in this example:
hostname Router1 ! ! The following lines configure the database with the information about the ! elan1 emulated Token Ring LAN. lane database cisco_eng name elan1 server-atm-address 39.020304050607080910111213.00000CA05B41.01 name elan1 local-seg-id 2048 default-name elan1 ! ! The following line configures virtual ring 256 on the router. source-bridge ring-group 256 ! interface Ethernet0/0 ip address 10.6.10.4 255.255.255.0 ! ! The following lines configure the configuration server to use the cisco_eng database. ! The Signalling and ILMI PVCs are also configured.
XC-403
interface ATM2/0 no ip address atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi lane config auto-config-atm-address lane config database cisco_eng ! ! The following lines configure the server and broadcast-and-unknown server and a client ! on the interface. The lines also specify source-route bridging information. interface ATM2/0.1 multipoint lane server-bus tokenring elan1 lane client tokenring elan1 source-bridge 2048 5 256 source-bridge spanning ! ! The following lines configure the Token Ring interfaces. interface TokenRing3/0 no ip address ring-speed 16 source-bridge 1 1 256 source-bridge spanning interface TokenRing3/1 no ip address ring-speed 16 source-bridge 2 2 256 source-bridge spanning ! router igrp 65529 network 10.0.0.0
Router 2 Configuration
Router 2 contains only a client for the ELAN. Router 2 is configured as follows:
hostname Router2 ! ! The following line configures virtual ring 512 on the router. source-bridge ring-group 512 ! interface Ethernet0/0 ip address 10.6.10.5 255.255.255.0 ! ! The following lines configure the Token Ring interfaces. interface TokenRing1/0 no ip address ring-speed 16 source-bridge 3 3 512 source-bridge spanning interface TokenRing1/1 no ip address ring-speed 16 source-bridge 4 4 512 source-bridge spanning ! ! The following lines configure the signalling and ILMI PVCs. interface ATM2/0 no ip address atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi ! ! The following lines configure the client. Source-route bridging is also configured. interface ATM2/0.1 multipoint ip address 1.1.1.2 255.0.0.0
XC-404
lane client tokenring elan1 source-bridge 2048 6 512 source-bridge spanning ! router igrp 65529 network 10.0.0.0
Configuration server trelan server-bus ethelan server-bus trelan client ethelan client Router 1
ATM 2/0.1 1.1.1.2 ATM 2/0.1 1.1.1.1 ATM 2/0.2 2.2.2.1 Cisco LightStream ATM switch ethelan client ATM 2/0.2 2.2.2.2
S6282
Router 3
Router 1 Configuration
Router 1 contains the LECS, a LES and BUS for each ELAN, and a client for each ELAN. Router 1 is configured as shown in this example:
hostname router1 ! ! The following lines name and configures the configuration server's database. ! The server addresses for trelan and ethelan and the ELAN ring number for ! trelan are entered into the database. The default ELAN is trelan. lane database cisco_eng name trelan server-atm-address 39.020304050607080910111213.00000CA05B41.01 name trelan local-seg-id 2048 name ethelan server-atm-address 39.020304050607080910111213.00000CA05B41.02 default-name trelan ! ! The following lines enable the configuration server and associate it ! with the cisco_eng database. interface ATM2/0 no ip address atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi lane config auto-config-atm-address lane config database cisco_eng !
XC-405
! The following lines configure the tokenring LES/BUS and LEC for trelan ! on subinterface atm2/0.1 and assign an IP address to the subinterface. interface ATM2/0.1 multipoint ip address 10.1.1.1 255.255.255.0 lane server-bus tokenring trelan lane client tokenring trelan ! ! The following lines configure the Ethernet LES/BUS and LEC for ethelan ! on subinterface atm2/0.2 and assign an IP address to the subinterface. interface ATM2/0.2 multipoint ip address 20.2.2.1 255.255.255.0 lane server-bus ethernet ethelan lane client ethernet ethelan ! ! The following lines configure the IGRP routing protocol to enable routing ! between ELANS. router igrp 1 network 10.0.0.0 network 20.0.0.0
Router 2 Configuration
Router 2 contains a client for trelan (Token Ring). Router 2 is configured as follows:
hostname router2 ! ! The following lines set up the signalling and ILMI PVCs for the interface. interface ATM2/0 no ip address no keepalive atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi ! ! The following lines configure a Token Ring LEC on atm2/0.1 and assign ! an IP address to the subinterface. interface ATM2/0.1 multipoint ip address 10.1.1.2 255.255.255.0 lane client tokenring trelan ! ! The following lines configure the IGRP routing protocol to enable routing ! between ELANS. router igrp 1 network 10.0.0.0 network 20.0.0.0
Router 3 Configuration
Router 3 contains a client for ethelan (Ethernet). Router 3 is configured as follows:
hostname router3 ! ! The following lines set up the signalling and ILMI PVCs for the interface. interface ATM2/0 no ip address no ip mroute-cache atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi ! ! The following lines configure an Ethernet LEC on atm2/0.1 and assign ! an IP address to the subinterface. interface ATM2/0.1 multipoint ip address 20.2.2.2 255.255.255.0
XC-406
lane client ethernet ethelan ! ! The following lines configure the IGRP routing protocol to enable routing ! between ELANS. router igrp 1 network 10.0.0.0 network 20.0.0.0
XC-407
XC-408
ATM Dual PHY OC-12 modules (WS-X5161 and WS-X5162) ATM Dual OC-3 modules (WS-5167 and WS-X5168)
Support for the Token Ring LANE feature was first introduced in Cisco IOS Release 12.0(7)T.
Note
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 the following sections:
Token Ring LANE on ATM Network Support Restrictions Prerequisites Token Ring LANE Configuration Task List Token Ring LANE Configuration Example
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.
XC-409
Benefits
ATM is a cell-switching and multiplexing technology that combines the benefits of circuit switching (constant transmission delay and guaranteed capacity) with those of packet switching (flexibility and efficiency for intermittent traffic). Like X.25 and Frame Relay, ATM defines the interface between the user equipment (such as workstations and routers) and the network (referred to as the User-Network Interface [UNI]). Token Ring LANE allows Token Ring LAN users to take advantage of the benefits of ATM 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, Token Ring LANs use connectionless service. Messages are broadcast to all devices on the network. With Token Ring LANE, routers and switches emulate the connectionless service of a Token Ring LAN for the end stations. By using Token Ring LANE, you can scale your networks to larger sizes while preserving your investment in LAN technology.
Note
The Catalyst 5000 series Cisco IOS Token Ring LANE software does not support Ethernet LANE or RFC 1483 permanent virtual connections (PVCs).
LANE client (LEC)A LEC emulates a LAN interface to higher-layer protocols and applications. It forwards data to other LANE components and performs LANE address resolution functions. Each LEC is a member of only one ELAN. However, a switch or a Catalyst ATM module can include LECs for multiple ELANs; there is one LEC for each ELAN of which it is a member. If a switch has LECs for multiple ELANs, the switch can route traffic between ELANs.
LANE server (LES)The LES is the control center for an ELAN. It provides joining, address resolution, and address registration services to the LECs in that ELAN. LECs can register destination unicast and multicast MAC address with the LES. The LES also handles LANE Address Resolution Protocol (LE_ARP) requests and responses and maintains a list of route descriptors that is used to support source-route bridging (SRB) over ELANs. The route descriptors are used to determine the ATM address of the next hop in the frames routing information field (RIF). There is one LES per ELAN.
LANE broadcast and unknown server (BUS)The BUS floods unknown destination traffic and forwards multicast and broadcast traffic to LECs within an ELAN. One combined LES and BUS is required for each ELAN.
LANE Configuration Server (LECS)The LECS contains the database that determines which ELAN a device belongs to (each LECS can have a different database). Each LEC contacts the LECS once to determine which ELAN it should join. The LECS returns the ATM address of the LES for that ELAN. One LECS is required for each ATM LANE switch cloud. The LECS database can have the following four types of entries:
ELAN name, ATM address of LES pairs ELAN name and the ring number of the ELAN (local-seg-id)
XC-410
LEC MAC address, ELAN name pairs LEC ATM template, ELAN name pairs Default ELAN name
Note
An ELAN name must be unique on an interface. If two interfaces participate in LANE, the second interface may be in a different switch cloud.
The server assigns individual LECs to particular ELANs by directing them to the LES for the ELAN. The LECS maintains a database of LEC and server ATM or MAC addresses and their ELANs. A LECS can serve multiple ELANs.
Fast Simple Server Redundancy Protocol (FSSRP)Token Ring LANE relies on three servers: LECS, LES, and BUS. If any one of these servers fails, the ELAN cannot fully function. Cisco has developed a fault tolerant mechanism known as Simple Server Redundancy Protocol (SSRP) that eliminates these single points of failure. Although there is only one LES per ELAN, SSRP allows you to configure redundant servers. You can configure servers to act as backup servers that become active if a master server fails. The priority levels for the servers determine which servers have precedence. FSSRP is an enhancement to the SSRP. With FSSRP, LECs no longer need to go down whenever there is a change in the master LES. This uninterrupted service is achieved by connecting the LECs simultaneously to more than one LES/BUS (up to four) so that if the master LES goes down, the backup LESs are immediately available. With the basic SSRP, the LEC must go down and completely recycle before coming back up. This operation is accomplished by keeping the control connections open to all of the active LESs and BUSs in the ELAN. Although this method uses more virtual circuits (VCs), the main benefits are the transparency and speed in the switchover.
Note
ELAN components coexist on one or more Cisco routers or Catalyst switches that contain an ATM module. On Cisco routers or Catalyst switches the LES and the BUS are combined into a single entity.
Network Support
The Token Ring LANE on the Catalyst 5000 series ATM module feature supports the following networking features:
LAN switching between ELANs and between a Token Ring ELAN and a legacy LAN Two-port and multiport SRB between ELANs and between ELANs and a Token Ring LAN SRB, source-route transparent bridging (SRT), and source-route switching
The Cisco implementation of LANE over IEEE 802.5 uses existing terminology and configuration options for Token Rings and provides for the IEEE 802.5 transport of Token Ring frames across an ATM switching fabric.
XC-411
Restrictions
Before you implement Token Ring LANE, be aware of the following restrictions:
Caution
While VLAN Trunking Protocol (VTP) Version 2 must be enabled on a Catalyst 5000 for Token Ring to function, do not use VTP to distribute VLAN configuration information between the switches. Configure the switches to operate in VTP transparent mode and manually configure the VLANs on each switch.
If you plan to run both Ethernet and Token Ring LANE, the Ethernet LANE software and the Token Ring LANE software must be run on separate ATM modules. All ATM switches have identical lists of the global LECS addresses with the identical priorities. Ensure that the spanning-tree port cost and priority for the ATM port are configured so that the ATM port is the preferred path (the lowest port cost with the highest priority). Only one LEC can be defined for each subinterface. Up to 256 subinterfaces per ATM module can be configured. Do not create more than one LEC for each Token Ring Bridge Relay Function (TrBRF) in each ATM module. While you can have only one LEC for each TrBRF in each module, you can have more than one module installed. These additional modules allow you to have more than one LEC per TrBRF, which means the module can participate in more than one ELAN. The ELANs, however, cannot be parallel or the Spanning-Tree Protocol will block one of the connections.
Note
Configuring more than one LEC for a TrBRF on a single ATM module will adversely affect frame forwarding.
Do not configure parallel ELANs within a TrBRF (parallel ELANs are those ELANs that form a loop between switches). Do not create more than one LEC for each Token Ring Concentrator Relay Function (TrCRF) per ATM module. Ensure that all-routes explorer (ARE) reduction is enabled (using the set tokenring reduction enable command) on the Token Ring module. The number of LESs that can be defined per ELAN is unlimited; however, only one LES per ELAN can be active at a time. When a LECS switchover occurs, no previously joined clients are affected. In a LES/BUS switchover, there is a momentary loss of clients until all clients are transferred to the new LES/BUS. LECSs automatically come up as masters until a higher-level LECS takes priority. Using FSSRP, you can configure redundant LESs or BUSs and LECSs to reduce the possibility of a server failure resulting in loss of communication on the LANE network. With redundant LES/BUSs and LECSs, LANE components can switch automatically to the backup LES/BUS or LECS if the primary server fails. For specific information on how to configure FSSRP, refer to the Configuring Fast SSRP for Redundant LANE Services section.
XC-412
Note
FSSRP works only with LECS and LES/BUS combinations on Cisco devices. Third-party LANE components interoperate with the LECS and LES/BUS functions of Cisco devices but cannot take advantage of the redundancy features. Additionally, FSSRP-unaware LECs on Cisco equipment cannot take advantage of FSSRP LES/BUS redundancy.
When a higher-priority LES comes online, it bumps the current LES off the same ELAN. For a short time after power on, some clients might change from one LES to another, depending upon the order of the LESs coming up. If no LES/BUS pair is up or connected to the master LECS, and more than one LES/BUS is defined for an ELAN, the LECS rejects any configuration request for that specific ELAN. Changes made to the list of LECS addresses on ATM switches can take up to 1 minute to propagate through the network. Changes made to the LECS database regarding LES addresses take effect almost immediately. If no LECS is operational or reachable, the well-known LECS address defined by the ATM Forum is used. The LECS to be used can be overridden on any subinterface by entering the following command:
lane config-atm address atm-address template
Note
To avoid affecting the LES/BUS or LEC redundancy, do not override any LECS, LES, or BUS addresses.
In an underlying ATM network failure, there can be multiple master LECS and multiple active LESs or BUSs for the same ELAN, resulting in a partitioned network. Clients continue to operate normally, but transmission between partitions of the network is not possible. The system recovers when the network break is repaired.
Prerequisites
Token Ring LANE requires that the Catalyst 5000 series switch contain one of the following ATM modules running ATM software Release 4.9b or later:
ATM Dual PHY OC-12 (WS-X5161 and WS-X5162) ATM Dual PHY OC-3 (WS-X5167 and WS-X5168)
These ATM modules provide an ATM network interface for the Catalyst 5000 series switch. Network interfaces reside on modular interface processors, which provide a direct connection between the high-speed synergy backplane and the external networks. The maximum number of ATM modules that the switch supports depends on the bandwidth configured. The Catalyst 5000 series Token Ring LANE software also requires the Catalyst 5000 series supervisor engine software Release 4.3(1a) or later and one of the following switches:
Cisco LightStream 1010 with Cisco IOS Release 12.0(1)W5 or later (recommended) Any ATM switch with UNI 3.0/3.1 and Interim Local Management Interface (ILMI) support for communicating the LECS address
XC-413
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
Note
If you plan to run both Ethernet and Token Ring LANE, the Ethernet LANE software and the Token Ring LANE software must be run on separate ATM modules.
Opening a Session from the Switch to the ATM Module Creating a LANE Plan and Worksheet Configuring the ATM Module from the Terminal Configuring the ATM Module from NVRAM Configuring the Prefix on the LightStream 1010 Switch Setting Up the Signalling PVC Displaying LANE Default Addresses Entering the LECS ATM Address on the LightStream 1010 Switch Configuring the LECS Database Binding the LECS to the ATM Interface Setting Up a LES/BUS and a LEC Configuring Redundant LANE Services Verifying the LANE Setup Monitoring and Maintaining LANE Components
Note
There can be multiple LECSs in an ATM cloud. Before configuring Token Ring LANE, you must first open a session with the ATM module in the Catalyst 5000 series switch by entering the session line configuration command from the supervisor Console> prompt. After opening the session, you see the ATM> prompt. You only have direct access to the ATM module with which you have established a session.
Note
The ATM module uses a subset of the Cisco IOS software. Generally, the Cisco IOS software works the same on the ATM module as it does on routers. After configuring the ATM module, you are ready to implement LANE.
XC-414
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
After opening the session, you see the ATM> prompt. You then have direct access only to the ATM module with which you have established a session.
Note
The ATM module uses a subset of Cisco IOS software. Generally, Cisco IOS software works the same on the ATM module as it does on routers. To configure the ATM module, you must use the ATM configuration mode in the Cisco IOS software. To enter global configuration mode, enter the configure EXEC command at the privileged EXEC prompt (ATM#). You see the following message, which asks you to specify the terminal, the NVRAM, or a file stored on a network server as the source of configuration commands:
Configuring from terminal, memory, or network [terminal]?
If you specify terminal, the run-time configuration is used. You can then save the run-time configuration into the NVRAM. If you specify memory, the run-time configuration is updated from the NVRAM. If you specify network, the run-time configuration is updated from a file in a server on the network.
Note
You cannot configure from the network. The ATM module accepts one configuration command per line. You can enter as many configuration commands as you want. You can add comments to a configuration file describing the commands you have entered. Precede a comment with an exclamation point (!) or pound sign (#). Comments are not stored in NVRAM or in the active copy of the configuration file. In other words, comments do not appear when you list the active configuration with the write terminal EXEC command or list the configuration in NVRAM with the show configuration EXEC command. Comments are stripped out of the configuration file when it is loaded to the ATM module.
Catalyst 5000 series switch interface where the LECS will be located. Catalyst 5000 series switch interface and subinterface where the LES/BUS for each ELAN will be located. For fault-tolerant operation, multiple servers can be on each ELAN. Catalyst 5000 series switch ATM modules, subinterfaces, and VLANs where the LECs for each ELAN will be located.
XC-415
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
Name of the default ELAN (optional). The default Token Ring ELAN is the same as the default TrCRF (1003). You can use the default Token Ring ELAN (trcrf-default) or configure a new one. Names of the ELANs that will have unrestricted membership. Names of the ELANs that will have restricted membership. Local segment ID for the ELAN. The local segment ID must be identical to the ring number of the TrCRF.
Note
The last three items in the list above are important because they determine how you set up each ELAN in the LECS database.
Default Value No LECS database is configured. No LES/BUS is configured. No LECs are configured.
PVCs Preferred PHY (Dual PHY modules only) Output throttling ILMI keepalives UNI version VTP
ILMI and signalling PVCs are set up. PHY A Disabled Disabled Autonegotiate (reverts to UNI 3.0 if autonegotiation fails) Disabled
Purpose Selects the terminal option and enters global configuration mode. Selects an ATM ELAN subinterface. Identifies the ELAN attached to this subinterface as a Token Ring ELAN. Exits global configuration mode. Saves the configuration file modifications to NVRAM.
ATM(config)#
ATM(config-if)# elanname
XC-416
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
In the following example, the ATM module is configured from the terminal. The interface atm 0 interface configuration command designates that ATM interface 0 is to be configured. The lane client tokenring command links TrCRF 10 to the ELAN named trcrf-10. The Ctrl-Z command quits configuration mode. The write memory command loads the configuration changes into NVRAM on the ATM module.
ATM# configure terminal ATM (config)# interface atm 0 ATM (config-subif)# lane client tokenring 10 trcrf-10 ATM (config-subif)# Ctrl-Z ATM# write memory
NVRAM stores the current configuration information in text format as configuration commands, recording only nondefault settings. The ATM module software performs a memory checksum to guard against corrupted data. As part of its startup sequence, the ATM module startup software always checks for configuration information in NVRAM. If NVRAM holds valid configuration commands, the ATM module executes the commands automatically at startup. If the ATM module detects a problem with its NVRAM or the configuration it contains, the module goes into default configuration. Problems can include a bad checksum for the information in NVRAM or the absence of critical configuration information.
Purpose Sets the local node ID (prefix of the ATM address). Exits global configuration mode. Saves the configuration values permanently.
Note
On the Cisco LightStream 1010 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. LANE prefixes must start with 39 or 47.
XC-417
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
Note
If you do not save the configured value permanently, it will be lost when the switch is reset or powered off. To display the current prefix on the Cisco LightStream 1010 switch, use the show network EXEC command.
Purpose Specifies the major ATM interface and enters interface configuration mode. Establishes 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. The vcd is the virtual channel descriptor. Sets up a PVC to communicate with the ILMI; the vpi and vci values are usually set to 0 and 16, respectively.
Step 3
XC-418
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
To enter a LECS ATM address into a LightStream 1010 switch and save it there permanently, use the following commands on the Cisco LightStream 1010 switch beginning in global configuration mode: Command
Step 1
Switch(config)# atm lecs-address-default address1 [address2...]
Purpose Specifies the LECSs ATM address for the entire switch. Use the addresses from your LANE worksheet and specify the full 40-digit ATM address. Exits global configuration mode. Saves the configuration value permanently.
Step 2 Step 3
You can configure redundant LECSs. Redundant LECSs should be configured on different devices in the LANE network. If you configure more than one LECS, make sure that all databases with the same name are identical. You can specify one default ELAN in the database. The LECS assigns any client that does not request a specific ELAN to the default ELAN. ELANs are either restricted or unrestricted. The LECS assigns a client to an unrestricted ELAN if the client specifies that particular ELAN in its configuration. However, the LECS only assigns a client to a restricted ELAN if the client is specified in the LECSs database as belonging to that ELAN. The default ELAN should 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.
When setting up the LECS database remember that the following are requirements when configuring LECs:
The VLAN name must match the ELAN name. The ring number defined when configuring the VLAN must match the local segment ID. The set vlan interface configuration command assumes that any ring number you enter is in hexadecimal. Therefore, 12 is stored as the hexadecimal value 0x12. The name elan_name local-seg-id segment_number LANE database configuration command assumes that any value you enter for the local-seg-id is in decimal unless you enter it explicitly in hexadecimal. For example, to define a TrCRF with a ring number of 12 you could enter the set vlan 12 name crf12 type trcrf ring 12 parent 100 interface configuration command or the set vlan 12 name crf12 type trcrf ring 0x12 parent 100 interface configuration command. When defining a corresponding LEC, you could enter the name crf12 local-seg-id 0x12 or name crf12 local-seg-id 18 LANE database configuration command because 18 is the decimal equivalent of 0x12.
XC-419
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
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 Setting Up the Database for Unrestricted-Membership ELANs Setting Up the Database for Restricted-Membership ELANs
A name for the database The ATM address of the LES for the ELAN A default name for the ELAN
In addition, you indicate that the LECSs ATM address is to be computed automatically. The default ELAN cannot be a restricted-membership ELAN. You do not need to specify the ATM or MAC addresses of the LECs for the default ELAN. On the Dual PHY ATM modules, you must configure redundant LESs or BUSs and a LECS, one for each PHY. When you configure a database with only a default unrestricted ELAN, you need not specify where the LECs are located. That is, when you set up the LECSs database for a single default ELAN, you need not provide any database entries that link the ATM addresses of any clients with the ELAN name. All of the clients are automatically assigned to a default ELAN. To set up the LECS for a default ELAN, use the following commands beginning in global configuration mode: Command
Step 1 Step 2
ATM(config)# lane database database-name
Purpose Enters database configuration mode for the LANE database that you specify. Binds the name of the ELAN to the ATM address of the LES in the configuration database. The index determines the priority. The highest priority is 0. Enter the ATM address of the server for the specified ELAN, as noted in your LANE 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 number.
XC-420
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
Command
Step 3
ATM(lane-config-database)# name elan-name local-seg-id segment-number
Purpose Assigns a segment number to the emulated Token Ring LAN in the configuration database. The segment number you specify for the local-seg-id keyword must remain the same for each entry you add and it must also be identical to the ring number of the TrCRF. The set vlan interface configuration command assumes that any ring number you enter is in hexadecimal. The name elan-name local-seg-id segment-number LANE database configuration command assumes that any value you enter for the local-seg-id keyword is in decimal unless you enter it explicitly in hexadecimal.
Step 4
Provides a default name for the ELAN in the configuration database. If you are setting up only a default ELAN, the elan-name argument in Step 2 and Step 3 is the same as the default ELAN name you provide in Step 4.
Step 5
ATM(lane-config-database)# exit
Exits from database configuration mode and returns to global configuration mode.
Note
After you configure the LECS database, you must bind the LECS database to the major ATM interface (ATM0) on the ATM module. For information on how to bind the database to the interface, see the Binding the LECS to the ATM Interface section later on in this chapter.
Note
In the steps listed in the task table, enter the ATM address of the server for the specified ELAN, as noted in your LANE worksheet and obtained in the Displaying LANE Default Addresses section earlier in this chapter.
XC-421
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
To configure unrestricted-membership ELANs in the LECS database, use the following commands beginning in global configuration mode: Command
Step 1 Step 2
ATM(config)# lane database database-name
Purpose Enters database configuration mode for the LANE database that you specify. Binds the name of the first ELAN to the ATM address of the LES/BUS for that ELAN in the configuration database. The index determines the priority. The highest priority is 0. Binds the name of the second ELAN to the ATM address of the LES/BUS in the configuration database. 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 3
Step 4
Assigns a segment number to the first emulated Token Ring LAN in the configuration database. The segment number you specify for local-seg-id must be identical to the ring number of the TrCRF. The set vlan command assumes that any ring number you enter is in hexadecimal. The name elan-name local-seg-id segment-number command assumes that any value you enter for the local-seg-id is in decimal unless you enter it explicitly in hexadecimal.
Step 5
Assigns a segment number to the second emulated Token Ring LAN in the configuration database. The segment number you specify for local-seg-id must be identical to the ring number of the TrCRF. The set vlan command assumes that any ring number you enter is in hexadecimal. The name elan-name local-seg-id segment-number command assumes that any value you enter for the local-seg-id is in decimal unless you enter it explicitly in hexadecimal. Repeat this step, providing a different ELAN name and segment number for each additional source-route bridged ELAN in this switch cloud.
Step 6 Step 7
(Optional) Specifies a default ELAN for LECs not explicitly bound to an ELAN. Exits database configuration mode and returns to global configuration mode.
XC-422
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
Unlike unrestricted-membership, you must also specify where the LECs 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. Those 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 LECSs database. When clients for the same restricted-membership ELAN are located in multiple switch ATM interfaces, each clients 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 as you have clients for ELANs in all the switch ATM interfaces. Each client will have a different ATM address in the database entries. To configure restricted-membership ELANs in the LECS database, use the following commands beginning in global configuration mode: Command
Step 1 Step 2
ATM(config)# lane database database-name
Purpose Enters database configuration mode for the LANE database that you specify. Binds the name of the first ELAN to the ATM address of the LES/BUS for that ELAN in the configuration database. 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
Binds the name of the second ELAN to the ATM address of the LES/BUS in the configuration database. 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.
Step 4
Assigns a segment number to the first emulated Token Ring LAN in the configuration database. The segment number you specify for the local-seg-id keyword must be identical to the ring number of the TrCRF. The set vlan interface configuration command assumes that any ring number you enter is in hexadecimal. The name elan-name local-seg-id segment-number LANE database configuration command assumes that any value you enter for the local-seg-id keyword is in decimal unless you enter it explicitly in hexadecimal.
XC-423
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
Command
Step 5
ATM(lane-config-database)# name elan-name2 local-seg-id segment-number
Purpose Assigns a segment number to the second emulated Token Ring LAN in the configuration database. The segment number you specify for the local-seg-id keyword must be identical to the ring number of the TrCRF. The set vlan interface configuration command assumes that any ring number you enter is in hexadecimal. The name elan-name local-seg-id segment-number LANE database configuration command assumes that any value you enter for the local-seg-id keyword is in decimal unless you enter it explicitly in hexadecimal. Repeat this step, providing a different ELAN name and segment number for each additional source-route bridged ELAN in this switch cloud.
Step 6
Adds a database entry associating a specific clients ATM address with a specific restricted-membership ELAN. Repeat this step for each of the clients of each of the restricted-membership ELANs on the switch cloud, in each case specifying that clients ATM address and the name of the ELAN with which it is linked.
Step 7
ATM(lane-config-database)# exit
Exits from database configuration mode and returns to global configuration mode.
Purpose If you are not currently configuring the interface, specifies the major ATM interface where the LECS is located and enters interface configuration mode. Specifies that the LECSs ATM address will be computed by the automatic method. Binds the LECSs database name to the specified major interface, and enables the LECS. Exits interface configuration mode. Saves the configuration.
ATM(config-if)# lane config auto-config-atm-address ATM(config-if)# lane config database database-name ATM(config-if)# exit ATM# copy running-config startup-config
XC-424
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
If you will have only one default ELAN, you only need to set up one server. If you will have multiple ELANs, you can set up the server for another ELAN on a different subinterface on the same interface of this switch, or you can place it on a different switch. When you set up a server and BUS on a switch, you can combine them with a client on the same subinterface, a client on a different subinterface, or no client at all on the switch. Depending on where your clients and servers are located, perform one of the following tasks for each LANE subinterface:
Purpose Specifies the subinterface for the first ELAN on this switch and enters interface configuration mode. Enables a LES/BUS for the first ELAN on the subinterface (you cannot configure more than one LES/BUS per subinterface).
Repeat Steps 1 and 2 for all LES/BUSs you want to configure on the ATM module.
ATM(config-if)# exit ATM# copy running-config startup-config
If the ELAN specified in Step 2 is intended to have restricted membership in the LECS database, carefully consider whether or not you want to specify its name here. You will specify the name in the LECS database when it is set up. However, if you link the client to an ELAN in this step, and through some mistake it does not match the database entry linking the client to an ELAN, this client will not be allowed to join this ELAN or any other. If you do decide to include the name of the ELAN linked to the client in Step 2 and later want to associate that client with a different ELAN, make the change in the LECSs database before you make the change for the client on this subinterface.
Guidelines for Setting Up a LEC Creating a Token Ring VLAN Setting Up the Token Ring VLAN on a LEC
XC-425
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
Catalyst 5000 series supervisor engine software Release 4.3(1a) and later ATM software Release 4.9(b) and later VTP Version 2
Note
While VTP version 2 must be enabled on a Catalyst 5000 for Token Ring to function, do not use VTP to distribute VLAN configuration information between the switches. Configure the switches to operate in VTP transparent mode and manually configure the VLANs on each switch. When you set up a LEC, follow these rules and recommendations:
Make sure you properly configure the LECS and LES/BUS using the ATM module command-line interface (CLI) for each VLAN before creating a LEC. VTP does not set up the LECS or LES/BUS. In the set vlan interface configuration command, the vlan_num argument represents the VLAN number to configure, and the vlan_name argument is the name of the VLAN. The VLAN name must match the ELAN name and the ring number must match the local segment ID. The set vlan interface configuration command assumes that any ring number you enter is in hexadecimal. Therefore, 0x12 or 12 is stored as the hexadecimal value 0x12. The name elan_name local-seg-id segment_number LANE database configuration command assumes that any value you enter for the local-seg-id keyword is in decimal unless you enter it explicitly in hexadecimal. For example, to define a TrCRF with a ring number of 12 you could enter the set vlan 12 name crf12 type trcrf ring 12 parent 100 interface configuration command or the set vlan 12 name crf12 type trcrf ring 0x12 parent 100 interface configuration command. When defining a corresponding LEC, you could enter name crf12 local-seg-id 0x12 or name crf12 local-seg-id 18 because 18 is the decimal equivalent of 0x12.
Before you can create a LEC, the TrBRF and TrCRF to which it will be associated must exist. Do not create more than one LEC for each TrBRF per ATM module. While you can have only one LEC per TrBRF per module, you can have more than one module installed. This allows you to have more than one LEC per TrBRF, which means the switch can participate in more than one ELAN. The ELANs, however, cannot be parallel or the Spanning-Tree Protocol will block one of the connections.
Note
Configuring more than one LEC for a TrBRF on a single ATM module will adversely affect frame forwarding.
Ensure that all-routes explorer (ARE) reduction is enabled (using the set tokenring reduction enable interface configuration command) on the Token Ring module. Do not configure parallel ELANs within a TrBRF (parallel ELANs are those ELANs that form a loop between switches). Do not create more than one LEC for each TrCRF per ATM module. A TrCRF can include only one enabled LEC from any ATM module.
XC-426
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
An ATM module LEC is assigned to a TrCRF to provide connectivity to the ATM network. In this sense, an ATM module is a logical port within the TrCRF. When assigning enabled LECs to TrCRFs, the enabled LECs of any one ATM expansion module should each be assigned to different TrCRFs.
You can change all ELAN names with the exception of VLANs 1, 1003, or 1005 whose ELAN names must remain default, trcrf-default, and trbrf-default, respectively. You cannot override the ELAN name for VLAN 1, 1003, or 1005 by using the name elan_name parameter. You can assign all other VLANs any name. When you enter the set vlan vlan_num [name vlan_name] interface configuration command in transparent mode and do not specify the optional name elan_name parameter, the software uses the names in Table 43 by default.
Table 43
If you currently have a different ELAN name for VLAN 1 or VLAN 1003, you must change the ELAN name to default (for VLAN 1) or trcrf-default (for VLAN 1003) in the LECS database. The following example shows an LECS database configuration that specifies marktng as the ELAN name for VLAN 1003:
lane database test name marktng server-atm-address 47.0091810000000061705B8301.00400B020011.01 ! interface ATM0 no ip address no ip route-cache atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi lane config auto-config-atm-address lane config database test ! interface ATM0.1 multipoint no ip route-cache lane server-bus tokenring marktng lane client tokenring 1003 marktng
You must change the ELAN name for VLAN 1003 from marktng to trcrf-default in the second and last lines of the display, as follows:
lane database test name default server-atm-address 47.0091810000000061705B8301.00400B020011.01 ! interface ATM0 no ip address no ip route-cache atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi lane config auto-config-atm-address lane config database test ! interface ATM0.1 multipoint
XC-427
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
no ip route-cache lane server-bus tokenring default lane client tokenring 1003 trcrf-default
Purpose From the supervisor module, defines the TrBRF that you will associate to TrCRF as a parent From the supervisor module, defines the TrCRF for which you are creating a LEC.
Step 2
Purpose Specifies the subinterface for an ELAN on this switch and enters interface configuration mode. Creates a LEC for the first ELAN and specifies the VLAN number and the ELAN name to which to bind the LEC. Exits configuration mode. Saves the configuration.
XC-428
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
LANE LES/BUS and LECS redundancy corrects these limitations by allowing you to configure redundant LES/BUSs so that the LECs in an ELAN can automatically switch to a backup LES if the primary LES fails. The priority of the LES/BUS pairs is established by the order in which they are entered in the LECS database. LANE LES/BUS and LECS redundancy is always enabled. You can use this redundancy feature by configuring multiple servers. LES/BUS and LECS redundancy works only with Cisco LECS and LES combinations. Third-party LANE server components continue to interoperate with the LECS and LES/BUS function of Cisco routers and switches, but cannot take advantage of the redundancy features. The following servers are single points of failure in the ATM LANE system:
Note
To configure LES/BUS and LECS redundancy, you must enable multiple, redundant, and standby LECSs and multiple, redundant, and standby LES/BUSs. The LES/BUS and LEC redundancy configuration procedure guards against failure on hardware on which LANE components are running, including all Catalyst 5000 series switches. The configuration procedure is not effective for ATM network switch failures. To enable LES/BUS and LEC redundancy, use the following commands beginning in global configuration mode:
Command
Step 1 Step 2
Switch(config)# atm lecs-address address
Purpose Allows you to enter the multiple LECS addresses on the ATM switch. Specifies redundant LES/BUSs on the ATM module. Enter the command for each LES address on the ELAN. The index determines the priority; 0 is the highest priority.
XC-429
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
Enter configuration commands, one per line. ATM(config)# interface atm0 ATM(config-if)# atm ilmi-keepalive 4 ATM(config-if)# end ATM#
These commands enable the transmission of ILMI keepalive messages and set the time between ILMI keepalive messages to 4 seconds.
Note
Note
Redundant LES/BUS pairs for a single ELAN should be configured on different ATM LANE modules in the LANE network for maximum fault tolerance. Configuring redundant LES/BUS pairs for an ELAN is a two-part process:
You must first configure the redundant LES/BUS pairs on subinterfaces for that ELAN. You must then enter the ATM addresses of the redundant LES/BUS pairs into the LECS database for the ELAN.
To configure the LES/BUS pairs, use the following commands beginning in privileged EXEC mode: Command
Step 1 Step 2
ATM# configure terminal ATM (config)# interface atm0
Purpose Enters global configuration mode. Specifies the major interface and enters subinterface configuration mode.
XC-430
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
Command
Step 3 Step 4 Step 5
ATM (config-subif)# lane fssrp ATM (config-subif)# interface atm 0. subinterface-number ATM (config-subif)# lane server-bus tokenring elan-name
Purpose Enables FSSRP on the major interface Specifies the subinterface for the first ELAN. Enables the LES/BUS for an ELAN on the subinterface (you cannot configure more than one LES/BUS per subinterface).
Repeat Steps 2 and 3 for all LES/BUSs you want to configure on this ATM module.
Step 6 Step 7
ATM (config-subif)# Ctrl-Z ATM# show lane server
Note
The LES/BUSs are not fully operational until one or more LECs are configured and the LECS database is configured and bound to the ATM module interface. This example shows how to specify the LES/BUS for an ELAN and verify the configuration:
ATM# configure terminal Enter configuration commands, one per line. End with CNTL/Z. ATM(config)# interface atm0.1 ATM(config-subif)# lane server-bus tokenring default ATM(config-subif)# interface atm0.2 ATM(config-subif)# lane server-bus tokenring Eng_ELAN ATM(config-subif)# ^Z ATM# show lane server LE Server ATM0.1 ELAN name: default Admin: up State: operational type: tokenring Max Frame Size: 4472 ATM address: 47.00918100000000E04FACB401.00100DAACC41.01 LECS used: 47.007900000000000000000000.00A03E000001.00 NOT yet connected LE Server ATM0.2 ELAN name: Eng_ELAN Admin: up State: operational type: tokenring Max Frame Size: 4472 ATM address: 47.00918100000000E04FACB401.00100DAACC41.02 LECS used: 47.007900000000000000000000.00A03E000001.00 NOT yet connected
To add the redundant LES/BUS pairs to the LECS, use the following commands beginning in privileged EXEC configuration mode: Command
Step 1 Step 2 Step 3 Step 4
ATM# show lane server ATM# configure terminal ATM (config)# lane database database-name
Purpose Displays the ATM address of the LES/BUS for the ELAN. Enters global configuration mode. Enters database configuration mode, specifying a LANE database name. Binds the name of the ELAN to the ATM addresses of the LES/BUS pairs in the order you want the services to fail over. In the configuration database, provides a default name of the ELAN.
Step 5
XC-431
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Task List
Command
Step 6 Step 7
ATM (lane-config-database)# Ctrl-Z ATM# show lane database
Purpose Exits from database configuration mode. Displays the LECS database configuration so that you can verify your changes.
This example shows how to display the ATM address of the LES/BUS of the default ELAN, how to configure the LECS database for the default ELAN, and how to verify the configuration:
ATM# show lane server LE Server ATM0.1 ELAN name: default Admin: up State: operational type: ethernet Max Frame Size: 1516 ATM address: 47.00918100000000E04FACB401.00100DAACC41.01 LECS used: 47.007900000000000000000000.00A03E000001.00 NOT yet connected ATM# configure terminal Enter configuration commands, one per line. End with CNTL/Z. ATM(config)# lane database LANE_Backbone ATM(lane-config-database)# name default server-atm-address 47.00918100000000E04FACB401.00100DAACC41.01 ATM(lane-config-database)# default-name default ATM(lane-config-database)# ^Z ATM# show lane database LANE Config Server database table 'LANE_Backbone' default elan: default elan 'default': un-restricted server 47.00918100000000E04FACB401.00100DAACC41.01 (prio 0)
Purpose Displays the LES, BUS, and LEC ATM addresses. The command output shows all the subinterfaces configured for LANE. For each subinterface, the command displays and labels the ATM addresses that belong to the LES, BUS, and the LEC. When you look at each ATM address, confirm the following items:
The prefix is the one you set up on the switch. The end-system identifier field reflects the base address of the pool of MAC addresses assigned to the ATM interface plus a value that represents the specific LANE component. The selector byte is the same number as the subinterface (converted to hexadecimal).
Enter the show lane EXEC command on each Catalyst 5000 series switch to verify the LANE setup before you set up the LECs on the next Catalyst 5000 series switch. Print the display or make a note of these ATM addresses so that you can use it when you set up the LECS database. At this point in the configuration process, the LECs are not normally operational.
XC-432
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Example
Purpose Displays the global and per-VCC LANE information for all the LANE components and ELANs configured on an interface or any of its subinterfaces. Displays the global and per-VCC LANE information for the BUS configured on any subinterface or ELAN. Displays the global and per-VCC LANE information for all LECs configured on any subinterface or ELAN. Displays the global and per-VCC LANE information for the LECS configured on any interface. Displays the LECS database. Displays the LE_ARP table of the LECs configured on the specified subinterface or ELAN. Displays the global and per-VCC LANE information for the LES configured on a specified subinterface or ELAN.
Router# show lane bus [interface atm 0 [subinterface-number] | name elan-name] [brief] Router# show lane client [interface atm 0 [subinterface-number] | name elan-name] [brief] Router# show lane config [interface atm 0]
Router# show lane database [database-name] Router# show lane le-arp [interface atm 0 [subinterface-number] | name elan-name] Router# show lane server [interface atm 0 [subinterface-number] | name elan-name] [brief]
Note
For descriptions of the output displayed by the commands listed above, see the description of the command documented in the Cisco IOS Switching Services Command Reference.
LEC
XC-433
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Example
Example Assumptions
For the example in Figure 97 the following assumptions apply:
Catalyst 5000 series switches with the ATM modules installed are running ATM software Release 4.9b or later. Catalyst 5000 series switch 1 runs the LES/BUS and LECS on interface atm0 and the LEC on interface atm0.1. Catalyst 5000 series switch 2 runs LEC on interface atm0.1. The ATM module is installed in slot 4 of both Catalyst 5000 series switches. You can change the ELAN name by entering the set vlan vlan_num [name vlan_name] command. The ELAN on the switches is essentially a new TrCRF. The ELAN name is crf112 and the VLAN ID is 112. The parent TrBRF to the TrCRF 112 is brf400 (VLAN ID 400).
Step 2
To verify the configuration of the new VLAN, enter the show vlan command. The output indicates that crf112 has been added and that brf400 is its parent:
Console> (enable) show vlan 112 VLAN Name Status Mod/Ports, Vlans ---- -------------------------------- --------- ---------------------------112 crf112 active VLAN Type SAID MTU Parent RingNo BrdgNo Stp BrdgMode Trans1 Trans2 ---- ----- ---------- ----- ------ ------ ------ ---- -------- ------ -----112 trcrf 100112 4472 400 0x112 srb 0 0 VLAN AREHops STEHops Backup CRF ---- ------- ------- ---------112 7 7 off Console> (enable)
Set up the prefix of the ATM NSAP address for the switch.
Note
XC-434
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Example
Step 2
Start a session to the ATM module by entering the session 4 interface configuration command. You see the following display:
Console> session 4 Trying ATM-4... Connected to ATM-4. Escape character is '^]'. ATM>
Step 3
Obtain the addresses of the LES/BUS for later use by entering the enable router configuration command (to enable configuration mode) and the show lane default-atm-addresses EXEC command at the ATM prompt. You see the following display:
ATM> enable ATM# ATM# show lane default-atm-addresses interface atm0 interface ATM0: LANE Client: LANE Server: LANE Bus: LANE Config Server: ATM#
Note Step 4
The two asterisks (**) represent the subinterface number byte in hexadecimal.
Using the LECS address obtained in Step 3, set the address of the default LECS in the LightStream 1010 switch by entering the configure terminal and atm lecs-address-default commands on the console of the LightStream 1010 switch. You see the following display:
Switch> enable Switch# Switch# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Switch(config)# atm lecs-address-default 47.0091810000000061705b7701.00400BFF0013.00 1 Switch(config)# end Switch#
The commands shown in this step configure the address of the LECS in the switch. The LECS ATM NSAP address is 47.0091810000000061705b7701.00400BFF0013.00. The sequence number of this LECS address, which is 1, means it is the first LECS in this switch.
Step 5
Save the configuration to NVRAM by entering the write memory command, as follows:
ATM# write memory
Step 6
Start a LES/BUS pair on Catalyst 5000 series switch 1 by entering the interface atm0 and the lane server-bus tokenring commands in global configuration mode. On the console of Catalyst 5000 series switch 1, enter the following commands:
ATM# configure terminal Enter configuration commands, one per line. End with CNTL/Z. ATM(config)# interface atm0 ATM(config-subif)# lane server-bus tokenring crf112 ATM(config-subif)# end ATM#
The commands shown in this step start a LES/BUS pair and assign the ATM 0 interface to crf112. The ELAN name is crf112, and the interface on which this LES/BUS pair is configured is atm0. The ELAN name must be the same as the VLAN name assigned to the TrCRF.
XC-435
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Example
Step 7
Save the configuration in NVRAM entering the write memory command, as follows:
ATM# write memory
Step 8
Set up the LECS database on the Catalyst 5000 series switch 1. Enter the LES address obtained in Step 3 and replace the ** with the subinterface number of the interface on which the LES/BUS is to be configured. In this example, that number is 00. Enter the lane database database_name interface configuration command, the name elan_name server-atm-address atm_address LANE database configuration command, the name elan_name local-seg-id segment_number LANE database configuration command, and the default-name elan_name commands at the ATM prompt. You see the following display:
ATM# config terminal Enter configuration commands, one per line. End with CNTL/Z. ATM(config)# lane database test ATM(lane-config-database)# name trcf-default server-atm-address 47.0091810000000061705b7701.00400BFF0011.00 ATM (lane-config-database) name crf112 local-seg-id 0x112 ATM(lane-config-database)# default-name crf112 ATM(lane-config-database)# exit ATM#
The commands shown in this step create the LECS database. The database name is test. The ELAN name is crf112. The ELAN segment number is 112. The LES ATM NSAP address is 47.0091810000000061705b7701.00400BFF0011.00.
Note
The segment number you specify for local-seg-id keyword must be identical to the ring number of the TrCRF. The set vlan command assumes that any ring number you enter is in hexadecimal. The name elan-name local-seg-id segment-number LANE database configuration command assumes that any value you enter for the local-seg-id keyword is in decimal unless you enter it explicitly in hexadecimal.
Step 9
Save the configuration in NVRAM by entering the write memory command, as follows:
ATM# write memory
Step 10
Start and bind the LECS on the Catalyst 5000 series switch 1 by entering the interface atm0, the lane config database database_name interface configuration command, and the lane config auto-config-atm-address interface configuration commands at the ATM prompt. You see the following display:
ATM# configure terminal Enter configuration commands, one per line. End with CNTL/Z. ATM(config)# interface atm0 ATM(config-if)# lane config database test ATM(config-if)# lane config auto-config-atm-address ATM(config-if)# end ATM#
The commands shown in this step start the LECS. The database to use is test. The interface on which the LECS is configured is atm0.
Step 11
Save the configuration in NVRAM by entering the write memory command, as follows:
ATM# write memory
XC-436
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Example
Step 12
Start the LEC on the Catalyst 5000 series switches 1 and 2 by entering the interface atm0.1 command and the lane client tokenring 112 crf112 interface configuration command in configuration mode on the consoles of switches 1 and 2. The interface on which the LEC is configured is atm0.1. The ELAN name is default, and it is configured to emulate Token Ring. You see the following display:
ATM# configure terminal Enter configuration commands, one per line. End with CNTL/Z. ATM(config)# interface atm0.1 ATM(config-subif)# lane client tokenring 112 crf112 ATM(config-subif)# end ATM#
Step 13
Save the configuration in NVRAM by entering the write memory command, as follows:
ATM# write memory
XC-437
Configuring Token Ring LAN Emulation Token Ring LANE Configuration Example
XC-438
Configuring the Multiprotocol over ATM Client chapter Configuring the Multiprotocol over ATM Server chapter Configuring Token Ring LAN Emulation for Multiprotocol over ATM chapter
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.
XC-439
Figure 98
MPC-A
Host A
Host B
MPOA resolution request sent from MPC-A to MPS-C NHRP resolution request sent from MPS-C to MPS-D MPOA cache-imposition request sent from MPS-D to MPC-B MPOA cache-imposition reply sent from MPC-B to MPS-D NHRP resolution reply sent from MPS-D to MPS-C MPOA resolution reply sent from MPS-C to MPC-A Shortcut VCC established
Table 44 lists and defines the MPOA terms used in Figure 98.
Table 44 MPOA Terms
MPOA Term MPOA resolution request NHRP resolution request MPOA cache-imposition request MPOA cache-imposition reply NHRP resolution reply MPOA resolution reply Shortcut VCC
Definition A request from an MPC to resolve a destination protocol address to an ATM address to establish a shortcut VCC to the egress device. An MPOA resolution request that has been converted to an NHRP resolution request. A request from an egress MPS to an egress MPC providing the MAC rewrite information for a destination protocol address. A reply from an egress MPC acknowledging an MPOA cache-imposition request. An NHRP resolution reply that eventually will be converted to an MPOA resolution reply. A reply from the ingress MPS resolving a protocol address to an ATM address. The path between MPCs over which Layer 3 packets are sent.
XC-440
12403
Traffic Flow
Figure 98 shows how MPOA messages flow from Host A to Host B. In this figure, an MPC (MPC-A) residing on a host or edge device detects a packet flow to a destination IP address (Host B) and sends an MPOA resolution request. An MPS (MPS-C) residing on a router converts the MPOA resolution request to an NHRP resolution request and passes it to the neighboring MPS/NHS (MPS-D) on the routed path. When the NHRP resolution request reaches the egress point, the MPS (MPS-D) on that router sends an MPOA cache-imposition request to MPC-B. MPC-B acknowledges the request with a cache-imposition reply and adds a tag that allows the originator of the MPOA resolution request to receive the ATM address of MPC-B. As a result, the shortcut VCC between the edge MPCs (MPC-A and MPC-B) is set up. When traffic flows from Host A to Host B, MPC-A is the ingress MPC and MPC-B is the egress MPC. The ingress MPC contains a cache entry for Host B with the ATM address of the egress MPC. The ingress MPC switches packets destined to Host B on the shortcut VCC with the appropriate tag received in the MPOA resolution reply. Packets traversing through the shortcut VCC do not have any DLL headers. The egress MPC contains a cache entry that associates the IP address of Host B and the ATM address of the ingress MPC to a DLL header. When the egress MPC switches an IP packet through a shortcut path to Host B, it appears to have come from the egress router.
Caution
For MPOA to work properly, you must first create an ELAN identifier for each ELAN. Use the lane config database or the lane server-bus ATM LANE command to create ELAN identifiers. These commands are described in the Catalyst 5000 Series Command Reference publication. An MPC/MPS can serve as one or more LAN Emulation Clients (LECs). The LEC can be associated with any MPC/MPS in the router or Catalyst 5000 series switch. A LEC can be attached both an MPC and an MPS simultaneously. Figure 99 shows the relationships between MPC/MPS and LECs.
XC-441
Figure 99
MPC/MPS 1
MPC/MPS 3
MPC/MPS 2
LEC 1
LEC 2
LEC 3
LEC 4
LEC 5
LEC 6
12402
Interface 1
Interface 2
Interface 3
ATM cloud
MPOA Components
The following components are required for an MPOA network:
MPOA Client (MPC) MPOA Server (MPS) Catalyst 5000 series ATM module LAN Emulation (LANE) Next Hop Resolution Protocol (NHRP)
An MPC identifies packets sent to an MPS, establishes a shortcut VCC to the egress MPC, and then routes these packets directly over the shortcut VCC. An MPC can be a router or a Catalyst 5000 series ATM module. An MPS can be a router or a Catalyst 5000 series Route Switch Module/Versatile Interface Processor 2 (RSM/VIP2) with an ATM interface.
Note
Since the RSM/VIP2 can also be used as a router, all references to router in this chapter refer to both a router and the RSM/VIP2 with an ATM interface.
XC-442
Benefits
MPOA provides the following benefits:
Eliminates multiple router hops between the source and the destination points of the ATM cloud by establishing shortcuts for IP packets and other protocol packets. Frees the router for other tasks by reducing IP traffic. Provides backward compatibility as an ATM network by building upon LANE, and can be implemented using both MPOA and LANE-only devices.
Configuring an MPC/MPS
To configure an MPC/MPS, perform the following tasks:
Define a name for the MPC/MPS. Attach the MPC/MPS to a major interface. This task serves two purposes:
Assigns an ATM address to the MPC/MPS. Identifies an end point for initiating and terminating MPOA virtual circuits.
Multiple MPCs/MPSs can run on the same physical interface, each corresponding to different control ATM address. Once an MPC/MPS is attached to a single interface for its control traffic, it cannot be attached to another interface unless you break the first attachment. The MPC/MPS is attached to subinterface 0 of the interface. In Figure 99, MPC/MPS 1 is attached to interface 1; MPC/MPS 1 can only use interface 1 to set up its control virtual circuits (VCs). MPC/MPS 2 is attached to interface 3; MPC/MPS 2 can only use interface 3 to set up its control VCs.
Note
An MPC/MPS can be attached to a single hardware interface only. More than one MPC/MPS can be attached to the same interface. MPC/MPS 3 and MPC/MPS 1 are both attached to interface 1, although they get different control addresses. Any LEC running on any subinterface of a hardware interface can be bound to any MPC/MPS. However, once a LEC is bound to a particular MPC/MPS, it cannot be bound to another MPC/MPS.
Note
Once a LEC has been bound to an MPC/MPS, you must unbind the LEC from the first MPC/MPS before binding it to another MPC/MPS. Typically, you will not need to configure more than one MPS in a router. Ensure that the hardware interface attached to an MPC/MPS is directly reachable through the ATM network by all the LECs that are bound to it.
Note
If any of the LECs reside on a different (unreachable) ATM network from the one to which the hardware interface is connected, MPOA will not operate properly.
XC-443
XC-444
XC-445
Configuring the Multiprotocol over ATM Client MPC Configuration Task List
Configuring the MPC (Required) Configuring the MPC Variables (Optional) Monitoring and Maintaining the MPC (Optional)
Note
To configure an MPC on a Catalyst 5000 series ATM module, establish connection with the ATM module, enter privileged mode, and then enter configuration mode. For information on performing these tasks, refer to the Catalyst 5000 Series Software Configuration Guide. Purpose Defines an ELAN ID for the LEC (in LANE database configuration mode). Configures the LEC with the ELAN ID (in interface configuration mode).
Command
Router(lane-config-dat)# name elan-name elan-id id
Caution
If an ELAN ID is supplied, make sure both commands use the same elan-id value.
Purpose In global configuration mode, defines an MPC with a specified name. In interface configuration mode, specifies the ATM interface to which the MPC is associated. In interface configuration mode, attaches an MPC to the ATM interface. In interface configuration mode, specifies the ATM interface that contains the LEC to which you will bind the MPC. In interface configuration mode, binds a LEC to the specified MPC.
Router(config-if)# interface atm {mod-num/port-num | number} Router(config-if)# mpoa client name mpc-name
Step 5
XC-446
Configuring the Multiprotocol over ATM Client MPC Configuration Task List
Purpose Defines an MPC with the specified name. (Optional) Specifies the control ATM address that the MPC should use (when it is associated with a hardware interface). (Optional) Specifies the maximum number of times a packet can be routed to the default router within shortcut-frame time before an MPOA resolution request is sent. (Optional) Sets the shortcut-setup frame time for the MPC.
Step 3
Step 4
Purpose Displays information about a specified MPC or all MPCs. Displays ingress and egress cache entries associated with an MPC. Displays all the statistics collected by an MPC. Clears cache entries. Displays all the MPOA devices that this MPC has learned. Displays the default ATM addresses for the MPC.
Router# show mpoa client [name mpc-name] cache [ingress | egress] [ip-addr ip-addr] Router# show mpoa client [name mpc-name] statistics Router# clear mpoa client [name mpc-name] cache [ingress | egress] [ip-addr ip-addr] Router# show mpoa client [name mpc-name] [remote-device]
XC-447
MPS Cisco LEC1 7200/7500/4500 LEC2 series ATM cloud Catalyst 5000 series OC-12 ELAN1 LECS LES/BUS1 LEC1 MPC1 OC-3 ELAN1 1.1.1X ELAN2 1.1.2.X
The following example configures the MPC and attaches the MPC to a hardware interface:
! Define the MPC MYMPC mpoa client config name MYMPC ! Leave everything as default exit ! Specify the ATM interface to which the MPC is attached interface ATM 1/0 ! Attach MPC MYMPC to the HW interface mpoa client name MYMPC ! Specify the ATM interface that contains the LEC to which you will bind the MPC interface atm 1/0.1 ! Bind a LANE client to the specified MPC lane client mpoa client name MYMPC ! Go back up to global config mode exit
The following example shows a typical configuration file for the first MPC:
Current configuration: ! version 11.3 ! Go to LANE database config mode exit lane database mpoa-test hostname mpc-1 ! Define the ELAN ID and ATM address name elan1 server-atm-address 47.00918100000000613E5A2F01.006070174821.01 name elan1 elan-id 101 name elan2 server-atm-address 47.00918100000000613E5A2F01.006070174821.02 name elan2 elan-id 102 ! Define the MPC mpc-1
XC-448
mpoa client config name mpc-1 interface Ethernet0 ! Go back up to global config mode exit ! Specify the ATM interface to which the MPC is attached interface ATM0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi lane config auto-config-atm-address lane config database mpoa-test ! Attach MPC mpc-1 to the HW interface mpoa client name mpc-1 ! Specify the ATM interface that contains the LEC to which you will bind the MPC interface ATM0.1 multipoint lane server-bus ethernet elan1 ! Bind a LANE client to the specified MPC lane client mpoa client name mpc-1 lane client ethernet 1 elan1 ! Go back up to global config mode exit
The following example shows a typical configuration file for the second MPC:
Current configuration: ! version 11.3 hostname mpc-2 ! Go back up to global config mode exit ! Define the MPC mpc-2 mpoa client config name mpc-2 ! Specify the ATM interface to which the MPC is attached interface ATM0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi mpoa client name mpc-2 ! Specify the ATM interface that contains the LEC to which you will bind the MPC interface ATM0.1 multipoint lane server-bus ethernet elan2 lane client mpoa client name mpc-2 lane client ethernet 2 elan2 ! Go back up to global config mode exit
XC-449
XC-450
MPS-NHRP-Routing Interaction
MPS must interact with the NHRP module in the router to smoothly propagate MPOA/NHRP packets end to end. MPOA frames are identical to NHRP frames except for some specific op-codes and extensions for MPOA. The following process explains the interaction of MPS and NHRP:
1.
MPS converts MPOA resolution requests to NHRP requests and sends it either to the next hop MPS or to the Next Hop Server (NHS), depending on the configuration. MPS searches for the next hop routing information to determine the interface and sends the packet with correct encapsulation to an MPS or an NHS.
XC-451
Configuring the Multiprotocol over ATM Server MPS Configuration Task List
2.
NHS sends resolution requests to MPS when the next hop is on a LAN Emulation (LANE) cloud or when NHS is unsure of the packet destination. MPS may do further processing, such as prompt NHS to terminate the request or throw away the packet. NHS sends resolution replies to MPS when the next hop interface is LANE or when the replies terminate in the router. Then MPS sends an MPOA resolution reply to the MPC.
3.
Shortcut Domains
Within a router, it is possible to permit shortcuts between one group of LAN Emulation Clients (LECs) and deny it between some other groups of LECs. Cisco introduces a notion of network ID associated with an MPS. By default, all the MPSs in a router get a network ID of 1. If the administrator wants to segregate traffic, then MPSs can be given different network IDs, in effect preventing shortcuts between LECs served by different MPSs. This can be configured in the definition of an MPS database. If a router has both MPS and NHRP configured, then the same network ID is required to facilitate requests, replies, and shortcuts across the MPS and NHRP. The interface-specific NHRP command (ip nhrp network-id) must be the same for an MPS; otherwise, there will be a disjointed network.
Configuring the ELAN ID (Required) Configuring the MPS (Required) Configuring the MPS Variables (Optional) Monitoring and Maintaining the MPS (Optional)
Purpose Configures the ELAN ID in the LECS database to participate in MPOA. Configures the LAN Emulation Server (LES) with the ELAN ID to participate in MPOA.
Caution
If an ELAN ID is supplied by both commands, make sure that the ELAN ID matches in both.
XC-452
Configuring the Multiprotocol over ATM Server MPS Configuration Task List
Purpose In global configuration mode, defines an MPS with the specified name. Specifies the ATM interface to attach the MPS. In interface configuration mode, attaches the MPS to the ATM interface. Specifies the ATM interface to bind the MPS to a LEC.
Router(config-if)# interface atm {slot/port.subinterface-number | number.subinterface-number} Router(config-subif)# lane client mpoa server name mps-name
Step 5
Purpose Defines an MPS with the specified name. (Optional) Specifies the control ATM address that the MPS should use (when it is associated with a hardware interface). (Optional) Specifies the holding time value for the MPS-p7 variable of the MPS. (Optional) Specifies the keepalive lifetime value for the MPS-p2 variable of the MPS. (Optional) Specifies the keepalive time value for the MPS-p1 variable of the MPS. (Optional) Specifies the network ID of the MPS.
XC-453
Purpose Displays default ATM addresses for an MPS. Displays information about a specified server or all servers depending on the specified name of the required server. Displays ingress and egress cache entries associated with a server. Displays all the statistics collected by a server including the ingress and egress cache entry creations, deletions, and failures. Clears cache entries. Originates an MPOA trigger for the specified IP address to the specified client. If a client is not specified, the MPOA is triggered to all the clients.
Router# show mpoa server [name mps-name] cache [ingress | egress] [ip-address ip-address] Router# show mpoa server [name mps-name] statistics
Router# clear mpoa server [name mps-name] cache [ingress | egress] [ip-addr ip-addr] Router# mpoa server name mps-name trigger ip-address ip-address [mpc-address mpc-address]
MPS Cisco LEC1 7200/7500/4500 LEC2 series ATM cloud Catalyst 5000 series OC-12 ELAN1 LECS LES/BUS1 LEC1 MPC1 OC-3 ELAN1 1.1.1X ELAN2 1.1.2.X
The following example configures the MPS and attaches the MPS to a hardware interface:
XC-454
! Define the MPS MYMPS mpoa server config name MYMPS ! Leave everything as default exit ! Enter into interface config mode interface ATM 1/0 ! Attach MPS MYMPS to the HW interface mpoa server name MYMPS ! Go back up to global config mode exit
XC-455
XC-456
Configuring a Token Ring LEC Configuring the LECS Database Configuring the LES/BUS
XC-457
Configuring Token Ring LAN Emulation for Multiprotocol over ATM Token Ring LANE for MPOA Configuration Task List
Defines a Token Ring LEC on a specified ELAN name. (Optional) Binds a Token Ring LEC to an MPS. (Optional) Binds a Token Ring LEC to an MPC.
Command
Step 1 Step 2 Step 3 Step 4
Router(config)# lane database database-name Router(lane-config-dat)# name elan-name server-atm-address atm-address Router(lane-config-dat)# name elan-name elan-id id Router(lane-config-dat)# name elan-name local-seg-id id
Purpose Creates a named database for the LECS. Binds the name of the ELAN to the ATM address of the LES. Defines the ELAN ID in the LECS database to participate in MPOA. Configures the local segment ID number.
Purpose Specifies the ATM subinterface to be associated with the LES/BUS. Defines a Token Ring LES/BUS on the named ELAN. The ELAN ID is optional.
Step 2
XC-458
Configuring Token Ring LAN Emulation for Multiprotocol over ATM Token Ring LANE Configuration Examples
MPOA Token Ring LANE Configuration in an IP-Routed Domain Example MPOA Token Ring LANE Configuration in an IP SRB-Routed Domain Example
Router-3 MPS-2
TR-ELAN 3 IP Subnet 3
Router-4 MPC-2
Host A
Host B
The following commands show a sample configuration for Router-1 in Figure 102:
hostname Router-1 ! ip routing ! ! Define the MPOA Client (mpc-1) configuration. ! mpoa client config name mpc-1 ! ! Configure an IP address on the Token Ring interface. !
18245
XC-459
Configuring Token Ring LAN Emulation for Multiprotocol over ATM Token Ring LANE Configuration Examples
interface TokenRing1/0 ip address 5.5.5.2 255.255.255.0 ring-speed 16 ! ! Configure a config-server and bind it to its database (mpoa-db). ! Attach the MPOA client mpc-1 to its ATM interface. ! interface ATM2/0 no ip address atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi lane config auto-config-atm-address lane config database mpoa-db mpoa client name mpc-1 ! ! Configure a LANE server-bus and LANE client on ELAN 1. Bind the ! LANE client to its MPOA Client (mpc-1). ! interface ATM2/0.1 multipoint ip address 1.1.1.1 255.255.255.0 lane server-bus tokenring 1 lane client mpoa client name mpc-1 lane client tokenring 1 ! router eigrp 1 network 1.0.0.0 network 5.0.0.0 ! end
The following commands show a sample configuration for Router-2 in Figure 102:
hostname Router-2 ! ip routing ! ! Configure the config-server database mpoa-db with configuration ! for ELANs 1 to 3 ! lane database mpoa-db name 1 server-atm-address 47.0091810000000060705BFA01.00000CA05F41.01 name 1 local-seg-id 1000 name 1 elan-id 100 name 2 server-atm-address 47.0091810000000060705BFA01.00000CA05B41.01 name 2 local-seg-id 2000 name 2 elan-id 200 name 3 server-atm-address 47.0091810000000060705BFA01.00000CA05B41.03 name 3 local-seg-id 3000 name 3 elan-id 300 ! ! Define the MPOA Server (mps-1) configuration. mpoa server config name mps-1 ! ! Configure the signalling and ILMI PVCs. Also configure a config-server ! and attach the MPOA server (mps-1) to its ATM interface. ! interface ATM4/0 no ip address atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi lane config auto-config-atm-address lane config database mpoa-db mpoa server name mps-1 ! ! Configure a Token Ring LANE client on ELAN 1 and bind the LANE
XC-460
Configuring Token Ring LAN Emulation for Multiprotocol over ATM Token Ring LANE Configuration Examples
! client to its MPOA server (mps-1). ! interface ATM4/0.1 multipoint ip address 1.1.1.2 255.255.255.0 lane client mpoa server name mps-1 lane client tokenring 1 ! ! Configure a Token Ring LANE client on ELAN 2 and bind the LANE ! client to its MPOA server (mps-1) ! interface ATM4/0.2 multipoint ip address 2.2.2.1 255.255.255.0 lane client mpoa server name mps-1 lane client tokenring 2 ! router eigrp 1 network 1.0.0.0 network 2.0.0.0 ! end
The following commands show a sample configuration for Router-3 in Figure 102:
hostname Router-3 ! ip routing ! ! Defines the MPOA Server (mps-2) configuration. mpoa server config name mps-2 ! ! Configure the signalling and ILMI PVCs and attach the MPOA ! server (mps-2) to its ATM interface. ! interface ATM2/0 no ip address atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi mpoa server name mps-2 ! ! Configure a Token Ring LANE client and LANE server-bus on ELAN 2 ! and bind the LANE client to its MPOA server (mps-2) ! interface ATM2/0.1 multipoint ip address 2.2.2.2 255.255.255.0 lane server-bus tokenring 2 lane client mpoa server name mps-2 lane client tokenring 2 ! ! Configure a Token Ring LANE client on ELAN 3 and bind the LANE ! client to its MPOA server (mps-2) ! interface ATM2/0.3 multipoint ip address 3.3.3.1 255.255.255.0 lane server-bus tokenring 3 lane client mpoa server name mps-2 lane client tokenring 3 ! router eigrp 1 network 2.0.0.0 network 3.0.0.0 ! end
The following commands show a sample configuration for Router-4 in Figure 102:
XC-461
Configuring Token Ring LAN Emulation for Multiprotocol over ATM Token Ring LANE Configuration Examples
hostname Router-4 ! ip routing ! ! Define the MPOA client (mpc-2) configuration. ! mpoa client config name mpc-2 ! ! Configure the Token Ring interface ! interface TokenRing1/0 ip address 4.4.4.1 255.255.255.0 ring-speed 16 ! ! Configure the signalling and ILMI PVCs and attach the MPOA ! client to its ATM interface. ! interface ATM2/0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi mpoa client name mpc-2 ! ! Configure a Token Ring LANE client on ELAN 3 and bind the LANE ! client to its MPOA client (mpc-2). ! interface ATM2/0.1 multipoint ip address 3.3.3.2 255.255.255.0 lane client mpoa client name mpc-2 lane client tokenring 3 ! router eigrp 1 network 3.0.0.0 network 4.0.0.0 ! end
XC-462
Configuring Token Ring LAN Emulation for Multiprotocol over ATM Token Ring LANE Configuration Examples
IP with no RIF Router-1 MPS-1 TR-ELAN2/ LIS 2 Multiring IP TR-ELAN 1 IP subnet 1 Shortcut path Edge device MPC-1 (SRB) Shortcut VCC Router-3 MPC-2 TR-ELAN 3 IP subnet 3 Router-2 MPS-2
Host A
Host B
The following commands show a sample configuration for Router-1 in Figure 103:
hostname Router-1 ! ip routing ! ! Configure the config-server database mpoa-db with configuration ! for ELANs 1 to 3 lane database mpoa-db name 1 server-atm-address 47.0091810000000060705BFA01.00000CA05F41.01 name 1 local-seg-id 1000 name 1 elan-id 100 name 2 server-atm-address 47.0091810000000060705BFA01.00000CA05B41.01 name 2 local-seg-id 2000 name 2 elan-id 200 name 3 server-atm-address 47.0091810000000060705BFA01.00000CA05B41.03 name 3 local-seg-id 3000 name 3 elan-id 300 ! ! Define the MPOA Server (mps-1) configuration. mpoa server config name mps-1
18349
IP with no RIF
IP with RIF
XC-463
Configuring Token Ring LAN Emulation for Multiprotocol over ATM Token Ring LANE Configuration Examples
! ! Configure the signalling and ILMI PVCs. Also configure a config-server ! and attach the MPOA server (mps-1) to its ATM interface. interface ATM4/0 no ip address atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi lane config auto-config-atm-address lane config database mpoa-db mpoa server name mps-1 ! ! Configure a Token Ring LANE client on ELAN 1 and bind the LANE ! client to its MPOA server (mps-1). The multiring ip configuration ! is required to terminate the RIF for IP packets on the ELAN. interface ATM4/0.1 multipoint ip address 1.1.1.2 255.255.255.0 lane client mpoa server name mps-1 lane client tokenring 1 multiring ip ! ! Configure a Token Ring LANE client on ELAN 2 and bind the LANE ! client to its MPOA server (mps-1) ! interface ATM4/0.2 multipoint ip address 2.2.2.1 255.255.255.0 lane client mpoa server name mps-1 lane client tokenring 2 ! ! router eigrp 1 network 1.0.0.0 network 2.0.0.0 ! end
The following commands show a sample configuration for Router-2 in Figure 103:
hostname Router-2 ! ip routing ! ! Defines the MPOA Server (mps-2) configuration. mpoa server config name mps-2 ! ! ! Configure the signalling and ILMI PVCs and attach the MPOA ! server (mps-2) to its ATM interface. interface ATM2/0 no ip address atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi mpoa server name mps-2 ! ! Configure a Token Ring LANE client and LANE server-bus on ELAN 2 ! and bind the LANE client to its MPOA server (mps-2) ! interface ATM2/0.1 multipoint ip address 2.2.2.2 255.255.255.0 lane server-bus tokenring 2 lane client mpoa server name mps-2 lane client tokenring 2 ! ! Configure a Token Ring LANE client on ELAN 3 and bind the LANE ! client to its MPOA server (mps-2) !
XC-464
Configuring Token Ring LAN Emulation for Multiprotocol over ATM Token Ring LANE Configuration Examples
interface ATM2/0.3 multipoint ip address 3.3.3.1 255.255.255.0 lane server-bus tokenring 3 lane client mpoa server name mps-2 lane client tokenring 3 ! router eigrp 1 network 2.0.0.0 network 3.0.0.0 ! end
The following commands show a sample configuration for Router-3 in Figure 103:
hostname Router-3 ! ip routing ! ! Define the MPOA client (mpc-2) configuration. mpoa client config name mpc-2 ! ! ! Configure the Token Ring interface interface TokenRing1/0 ip address 4.4.4.1 255.255.255.0 ring-speed 16 ! ! Configure the signalling and ILMI PVCs and attach the MPOA ! client to its ATM interface. ! interface ATM2/0 atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi mpoa client name mpc-2 ! ! Configure a Token Ring LANE client on ELAN 3 and bind the LANE ! client to its MPOA client (mpc-2). ! interface ATM2/0.1 multipoint ip address 3.3.3.2 255.255.255.0 lane client mpoa client name mpc-2 lane client tokenring 3 ! router eigrp 1 network 3.0.0.0 network 4.0.0.0 ! end
XC-465
Configuring Token Ring LAN Emulation for Multiprotocol over ATM Token Ring LANE Configuration Examples
XC-466
Index
I
BC DC FC IC IPC MWC P2C P3C QC SC TC VC WC XC Cisco IOS Bridging and IBM Networking Configuration Guide Cisco IOS Dial Technologies Configuration Guide Cisco IOS Configuration Fundamentals Configuration Guide Cisco IOS Interface Configuration Guide Cisco IOS IP Routing Configuration Guide Cisco IOS Mobile Wireless Configuration Guide Cisco IOS AppleTalk and Novell IPX Configuration Guide Cisco IOS Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS Configuration Guide Cisco IOS Quality of Service Solutions Configuration Guide Cisco IOS Security Configuration Guide Cisco IOS Terminal Services Configuration Guide Cisco IOS Voice, Video, and Fax Configuration Guide Cisco IOS Wide-Area Networking Configuration Guide Cisco IOS Switching Services Configuration Guide
N D E X
addresses Layer 2 MAC Layer 3 mapping AppleTalk AppleTalk over IEEE 802.10 in VLAN, configuration (example) XC-351 fast switching disabling enabling
XC-16 XC-13 XC-350 XC-8 XC-8 XC-321 XC-8
addressing, in VLANs
over encapsulating VLAN interfaces, configuration (example) XC-339 over IEEE 802.10 encapsulation subinterface, configuring on subinterface, routing over VLAN, customizing TR LANE support
XC-349 XC-350
Symbols
<cr>
xxxv xxxiv
XC-350
XC-373 XC-349
VLAN subinterfaces, routing over appletalk cable-range command appletalk route-cache command appletalk routing eigrp command appletalk zone command
XC-175
? command
A
access lists creating IPX MLS configuration (example) overview restrictions accounting per VLAN statistics
XC-313 XC-141 XC-267 XC-292 XC-301
APPN (Advanced Peer-to-Peer Networking), TR LANE support XC-373 ATM (Asynchronous Transfer Mode) extended label interface forum
XC-225 XC-140 XC-224 XC-178
XC-85 XC-85
XC-469
Index
definition
XC-104 XC-164
EBGP routing, configuring forwarding packets maintaining the LFIB routing between
XC-108
XC-107
XC-105
NDIS-compliant LAN drivers ODI-compliant LAN drivers protocol definition MPLS subinterface port adapter subinterface switches VCs
XC-96 XC-167 XC-135 XC-174 XC-319
B
backbone network provider services
XC-97 XC-100 XC-95
XC-226
XC-169, XC-225
backbone router interfaces for TMS collection, setting bandwidths in virtual trunks specifying
XC-376 XC-375 XC-118 XC-126 XC-42
with LSRs, configuring WRED address wildcards in templates atm lecs-address command
XC-221
ATM LANE
on XTagATM interfaces
XC-125
LANE support
atm lecs-address-default command atm pvc ilmi command atm pvc qsaal command ATM switches adding redundancy
XC-127 XC-379 XC-379
configuration (example)
XC-373
compared to an ATM label switch functioning as an IP router interfaces, configuring LSC redundancy configuring partitioning
XC-126 XC-126 XC-116
BGP (Border Gateway Protocol) PE to CE routing sessions, configuring routing sessions, configuring bit settings bottlenecks
XC-111 XC-96 XC-112 XC-357, XC-358 XC-155 XC-156
bridge-group command
XC-378, XC-447, XC-453 XC-311
XC-372
autonomous systems
Cisco IOS Switching Services Configuration Guide
XC-470
Index
XC-41
XC-21
XC-22
XC-37
XC-44
C
cache MLS MPOA MPOA
XC-254
per-destination, disabling per-packet, configuring NetFlow policy routing operation modes central CEF mode requirement
XC-256 XC-140 XC-83 XC-24
cache-imposition request
XC-440
XC-24
sample network topology (figure) supported media virtual profiling CEF mode (figure)
XC-112 XC-24 XC-96 XC-24 XC-35
XC-22
CAR (committed access rate) as a QoS building block configuring function MLS restrictions rate policies
XC-269 XC-221, XC-223 xxxv xxix XC-221 XC-167
centralized service
XC-223
carriage return (<cr>) cautions, usage in text CE (customer edge) routing sessions CEBGP assigning labels
XC-156, XC-157
virtual trunks, creating Cisco 7500 series routers Cisco BPX series switches
XC-110
XC-111
XC-233
XC-471
Index
Cisco Catalyst 5000 series switches Cisco Catalyst switches in VLANs supported
XC-319
XC-445
commands context-sensitive help for abbreviating default form, using no form, using communication
xxxvii xxxvii xxxiv
Cisco IOS configuration changes, saving Cisco LightStream 100 ATM switches LANE ATM address prefix
XC-375
XC-95
XC-378
LANE configuration servers ATM address on the Cisco LightStream 100 switches XC-377 software version, TR-LANE
XC-374
Cisco LightStream 1010 ATM switches LANE configuration servers ATM address on the Cisco LightStream 1010 switches XC-377 software version, TR-LANE Cisco.com class premium standard
XC-175 XC-175 XC-171 XC-48 XC-48 xxx XC-374
congestion management
XC-112 XC-122
clear ip mds forwarding command clear mpoa client cache command clear mpoa server cache command client-atm-address name command clns route-cache command closed user groups cnfrsrc command command syntax conventions
xxx xxxv XC-96 XC-138 XC-17
IP environment
XC-96 XC-95
XC-95
xxxiii to xxxiv
connectivity
displaying (example)
XC-161, XC-163
XC-472
Index
D
data encryption MLS restrictions
XC-269 XC-95
DRiP (Duplicate Ring Protocol) database, enabling drop mechanism drop probability dropping packets
XC-44 XC-330 XC-222 XC-167 XC-167
data hosting network commerce dCEF (distributed CEF) description disabling enabling IPC, using mode
XC-9 XC-38
E
EBGP function in autonomous systems parameters
XC-156 XC-104
edge LSR
XC-66
XC-127 XC-114
LANE support
default
restricted membership
database entries for all clients, configuring database entries for clients, adding setting up database for unrestricted membership configuration (example)
XC-175 XC-383 XC-381 XC-396 XC-382 XC-384
XC-383
decnet route-cache command decnet routing command default-name command discard policy
XC-167
distributed fair queueing, configuring documentation CD-ROM documentation conventions documentation modules documentation, ordering
xxxi xxix
XC-357, XC-358
XC-473
Index
F
fair-queue
XC-175
IEEE 802.10
fast switching description disabling AppleTalk DECnet IP IPX XNS enabling AppleTalk IP IPX
XC-14 XC-15 XC-14 XC-13 XC-14 XC-17 XC-16 XC-17 XC-16 XC-16 XC-5, XC-8, XC-13
XC-325, XC-326, XC-327, XC-329, XC-332, XC-335, XC-336, XC-337, XC-338 XC-325, XC-351 XC-15
encapsulation sde command encapsulation smds command encapsulation types encapsulations AppleTalk Phase II in VLANs formats defining ISL SAP
XC-330, XC-333 XC-330, XC-333 XC-321
VINES
XC-174, XC-222
same interface
XC-332
Novell Ethernet_802.2
XC-332 XC-349
XC-15 XC-15
XC-15
Feature Navigator See platforms, supported filtering output, show and more commands flow masks IP multicast MLS flows IP multicast MLS
XC-262 xxxviii
export target communities extended MPLS ATM port external traffic definition extranet
XC-29
XC-84
XC-41
XC-263
XC-474
Index
XC-318
I
IBGP session
XC-155
G
global configuration mode, summary of global flow cache
XC-140 xxxiv
H
hardware platforms See platforms, supported HDLC IEEE 802.10 headend LVC definition disabling
XC-140 XC-134, XC-140 xxxiv XC-453 XC-319
encapsulation standard
holding-time command
XC-33
XC-108 XC-154
hot LSC redundancy See LSC hot standby routing group attributes customizing
XC-329 XC-122
ingress label switching router, function input interface, configuring the rate limit interautonomous systems, definition interface atm command
XC-104
interface ATM for multi-VC mode, configuration (example) XC-222 interface command
XC-70, XC-72, XC-325, XC-329, XC-330, XC-332, XC-333, XC-335, XC-336, XC-337, XC-338, XC-351, XC-355, XC-356, XC-357, XC-446
XC-475
Index
interface configuration mode, summary of interface fastethernet command interface POS3/0/0 internal traffic definition Internet
XC-29 XC-41 XC-220
xxxiv
XC-48
XC-357, XC-358
ip flow-aggregation cache destination-prefix command XC-74 ip flow-aggregation cache prefix command ip flow-cache entries command ip flow-export command
XC-71 XC-74 XC-75
internodal BPX connections interprovider VPNs definition intranet IP addresses defining enabled state fast switching disabling enabling
XC-14 XC-14 XC-97, XC-167 XC-329 XC-220 XC-105
XC-138
inter-VLAN communication
XC-96
XC-313
XC-287
XC-263
inter-VLAN communication
XC-111, XC-112, XC-167 XC-170, XC-171
XC-261 XC-283
classifying
assignments
XC-223
XC-281 XC-281
external routers
XC-280
XC-284 XC-262
ip address command
topologies MDS
XC-40 XC-40 XC-40
XC-259
ip cef load-sharing algorithm original command ip cef load-sharing algorithm tunnel command ip cef load-sharing algorithm universal command
global enabling
XC-476
Index
line card packet counts, clearing line card packet counts, displaying MFIB table summary, displaying MFIB table, clearing MFIB table, displaying
XC-306 XC-307
TRISL, configuring
XC-307 XC-307 XC-307
switched packet counts, displaying switched packet counts, displaying ip multicast-routing command IP precedence, setting
XC-223 XC-38 XC-306
XC-301
ip route-cache same-interface command IP routing over IEEE 802.1Q in VLANs configuration (example) IPX configurable encapsulation formats configuration (example) encapsulation SAP
XC-332 XC-344 XC-359
XC-265
XC-331
destination-source flows
XC-264
XC-265
XC-295
encapsulation formats Ethernet V2 Novell-ether fast switching directed broadcast packets, enabling disabling enabling
XC-17 XC-15 XC-331 XC-20 XC-15
management interface, specifying MLSP on router, enabling monitoring and maintaining operation
XC-298 XC-265 XC-291 XC-292 XC-293 XC-294
XC-295
XC-296
feature interaction
XC-292
maximum transmission unit size sample network topology (figure) VLAN ID to interface, assigning
XC-477
Index
K
keepalive-lifetime command keepalive-time command
XC-453
XC-453
L
XC-19
ipx route-cache inactivity-timeout command ipx route-cache max-size command ipx routing command IPX routing, enabling NetWare subinterface, configuring VLAN encapsulation format
XC-332 XC-332 XC-19 XC-332, XC-333, XC-357
switch routers
IS-IS (Intermediate System-to-Intermediate System) XC-121 transitioning an IS-IS network to a new technology XC-91 ISL (Inter-Switch Link Protocol) Banyan VINES encapsulation DECnet encapsulation, configuring description
XC-319 XC-318 XC-324 XC-326 XC-326
XC-146
XC-146
configuration tasks
XC-323
subinterface, configuring on a
XC-323
XC-335
XC-385
traffic, distributed on VIP card XNS encapsulation ISO CLNS fast switching
XC-17
lane client mpoa client command lane client mpoa server command lane client tokenring command lane config command
XC-384
lane client mpoa client name command lane client mpoa server name command
XC-458
XC-446
XC-458 XC-453
XC-478
Index
XC-381, XC-420
XC-382
default emulated LAN, unrestricted membership mandatory XC-381 emulated LANs and subnetworks
XC-386, XC-387
default components on several routers, configuration (example) XC-394, XC-395 default, setting up database for multiple (figure)
XC-396 XC-366 XC-366, XC-370, XC-385, XC-381
ESI values derived from MAC address prefix, configuring on a switch syntax
XC-375 XC-376 XC-376 XC-376
XC-375, XC-378
templates wildcards
ESI template
XC-372
XC-386 to XC-387
changing to different emulated LAN, change database first XC-386 MAC address
XC-375 XC-386, XC-387
XC-374
configuration plan and worksheet recommended XC-378 configuration server database enabling
XC-366 XC-384 XC-367 XC-377 XC-377 XC-366 XC-379
XC-370
XC-369
XC-385 to XC-387
XC-373
XC-373
XC-479
Index
LANE (LAN emulation) supported routing protocol token ring configuring for MPOA VCC types VCCs Configure Direct (server) Control Direct Data Direct Control Distribute Multicast Forward Multicast Send types (figure)
XC-368 XC-367 XC-367, XC-368 XC-367 XC-457 XC-373
LECs commands
XC-458 XC-458 XC-458
LES/BUS, configuring
XC-458
XC-107
XC-139
lane server-bus ethernet command LANs (local area network) segmentation with VLANs Layer 2 addresses
XC-8 XC-321 XC-312 XC-321
external interface
connectionless architecture MLS cache IP multicast MLS LC-ATM ports LDP definition LE ARP
XC-84 XC-116 XC-261
standalone LSC, migrating from supported distribution protocols supported routing protocols
XC-126
XC-124 XC-121
XC-121
VSI, configuring
XC-480
Index
XC-112
restrictions terminology
XC-269 XC-254
XC-230 XC-226
with a standard access list, configuration (example) XC-276 with an extended access list, configuration (example) XC-277 without access lists, configuration (example) mls rp ip multicast command
XC-282 XC-275
PVP, configuring
XC-139
XC-179
M
mask destination command mask source command maximum burst size migration path MLS access lists cache CAR restrictions
XC-269 XC-275 XC-271 XC-258, XC-268 XC-254 XC-256 XC-97 XC-74
mls rp vtp-domain command MLSP description MLS-RP description MLS-SE description MMLS-RP interfaces, enabling on overview MMLS-SE overview
XC-261 XC-261 XC-254 XC-254 XC-254
XC-294, XC-296
XC-221
candidate packet
XC-282 XC-282
configuration (examples) configuring and monitoring data encryption restrictions enabler packet external routers usage guidelines features media NAT restrictions restrictions TCP intercept
XC-269 XC-255 XC-253 XC-254 XC-269 XC-257
XC-282
ingress label switching router more command MPLS architecture backbone configuring
XC-114 XC-167 XC-30
implementation
XC-268
XC-442
policy route-map
XC-269
configuration (examples)
XC-176
XC-187
XC-481
Index
description
ELAN ID, configuring frame processing LANE clients MPC LANE interaction
XC-388
XC-445
XC-441
multi-VC mode in MPLS-enabled core, configuring XC-174 multi-VC using cos-map function, configuring network packets
XC-111 XC-113 XC-174 XC-175
configuration (example) configuration tasks monitoring MPS configuration (example) configuration tasks monitoring
XC-454 XC-452 XC-452 XC-443 XC-447
XC-448, XC-454
XC-445
XC-448, XC-454
XC-144, XC-219
XC-452
subinterface, creating
switching and routing features traffic engineering, configuring verifying configuration virtual private network VPN configuration (example) configuration example features figure security
XC-154 XC-102 XC-96 XC-180 XC-140
virtual circuits
XC-451
XC-196 XC-199
XC-163
MPC to MPC Shortcut in an IP Routed Environment (figure) XC-459 MPC to MPC Shortcut in an IP SRB-Routed Environment (figure) XC-463 traffic flow
XC-441 XC-453
mpoa server name trigger ip-address command Multicast Forward VCC Multicast Send VCC multiple LVC model multi-VC mode BPX1 and BPX2 edge LSR1 LSC1
XC-230 XC-229 XC-368 XC-368 XC-167
XC-454
mpoa client config name command mpoa client name command benefits
XC-443 XC-440 XC-440 XC-446
configuration (example)
XC-229
XC-482
Index
distributed
MPLS-enabled core
N
name ELAN preempt command name elan-id command name local-seg-id command
XC-391
statistics
XC-72 XC-72
traffic performance NetFlow aggregation minimum mask default value description network changes
XC-75 XC-65
NBMA (nonbroadcast multiaccess) network NDE (NetFlow Data Export), configuring NDIS-compliant LAN drivers with ATM LANE NetFlow accounting benefits cache
XC-71 XC-71 XC-69 XC-319
XC-318
VlanDirector
customizing number of entries destination-prefix aggregation configuration (example) free-flow queue IP flow switching cache policy routing
XC-66 XC-72 XC-71 XC-79
management applications NetFlow statistics monitoring performance provider scalability security services
XC-141 XC-318 XC-96 XC-71
XC-74
point-to-point overlay
XC-96 XC-318 XC-318
prefix aggregation configuration (example) source-prefix aggregation minimum mask, configuring switching
XC-69 XC-77 XC-74 XC-77 XC-74
XC-313
security filtering
XC-318
XC-313
network-id command
XC-453
XC-321
XC-483
Index
XC-110
P
PA-A1 interface (ATM Lite) PA-A3 interface packet rewrite IPX MLS packets
XC-39 XC-265 XC-222 XC-221
NHRP (Next Hop Resolution Protocol) resolution reply resolution request servers
XC-441 XC-440 XC-440
classification
XC-167 XC-108
Novell Ethernet_802.2
XC-170 XC-170
configurable encapsulation NRP (Node Resource Processor) ATM switch, controlling configuring faults
XC-139 XC-135 XC-135 XC-178 XC-231
XC-138
XC-155 XC-157
functions
MPLS, running
position, displaying
virtual circuits, configuring NSP (Node Switch Processor) Cisco 6400 UAC, configuring functions
XC-135
XC-231
XC-222 XC-282
O
ODI-compliant LAN drivers with ATM LANE
XC-319 xxx
platforms, supported Feature Navigator, identify using release notes, identify using
xxxix xxxix
XC-484
Index
Q
QoS (quality of service)
XC-96 XC-168 XC-169
ATM interface supported features ATM switch supported features committed access rate configuring definition
XC-269 XC-178 XC-169 XC-111 XC-111 XC-167
configuration (example) policy map, configuring policy route-map MLS restrictions port assignments ports master control
XC-140
XC-172
XC-112 XC-112
mapped functions
XC-175
XC-176 XC-219
XC-167
XC-167 XC-167
privileged EXEC mode, summary of process switching description public IP addresses IP network
XC-97 XC-97 XC-8 xxxiv
xxxiv
XC-175
prompts, system
R
rate limit redundancy
XC-136 XC-221 XC-173
PVC (permanent virtual circuits) Cisco 6400 UAC, configuring configuring mode
XC-174 XC-224 XC-174, XC-179
in non-MPLS-enabled core, configuring on point-to-point subinterface PVP (permanent virtual paths) Cisco 6400 UAC, configuring LVC, configuring
XC-179 XC-138 XC-137
XC-365
resolution request
XC-440 XC-440
XC-485
Index
resources sharing between VLANs parameters route distribution processing route cache invalidation, controlling size
XC-18 XC-5 XC-17, XC-19 XC-321 XC-321 XC-156 xxxiv XC-321
XC-318 XC-313 XC-313 XC-96 XC-311, XC-312 XC-321 XC-96 XC-140 XC-380 XC-76
XC-47
show cef linecard command show interface stats command show ip cache command
label switching, enabling packet headers, analyzing PE routing between VLANs decisions processes
XC-6 XC-6, XC-7 XC-321 XC-96 XC-122
XC-18
show ip cache flow aggregation destination-prefix command XC-75 show ip cache flow aggregation prefix command show ip cache flow aggregation source-prefix command XC-75 show ip cef adjacency command show ip cef command show ip cef events command
XC-47 XC-33, XC-47 XC-47 XC-47 XC-48 XC-75
redundancy
routing protocols
show ip cef exact-route command show ip cef inconsistency command show ip cef summary command show ip interfaces command show ip mcache command
XC-186 XC-47
RSM/VIP2 (Route Switch Module/Versatile Interface Processor 2) XC-442 RSVP (Resource Reservation Protocol)
XC-86
S
SAID (Security Association Identifier) IEEE 802.10 scalability in VLANs
XC-349 XC-95, XC-96 XC-318
show ip mds interface command show ip mds stats command show ip mds summary command show ip route flow command
XC-486
Index
show ip route profile command show lane bus command show lane client command show lane command show lane config command show lane database command
XC-393 XC-392
XC-44
XC-392
SSRP (Simple Server Redundancy Protocol), configuring XC-379 standby authentication command standby ip command
XC-329 XC-329 XC-329 XC-329 XC-330 XC-330
show lane default-atm-addresses command show lane le-arp command show lane server command show mls rp ipx command show mls rp vtp-domain
XC-393 XC-393 XC-283
standby preempt command standby priority command standby timers command standby track command
XC-295, XC-296
XC-447
XC-447
show mpoa default-atm-addresses command show mpoa server cache command show mpoa server command show route-map ipc command show vlans command backup servers
XC-454 XC-454 XC-454
XC-5, XC-72
description NetFlow
exporting cache entries identifying packet flows NetFlow distributed next-hop destination overview paths
XC-5 XC-72 XC-6
next-hop determination
XC-5, XC-8, XC-13
XC-7
XC-487
Index
switching processes
XC-5, XC-6, XC-7, XC-8 XC-5 XC-72, XC-334
Token Ring MPOA MPC to MPC Shortcut In an IP Routed Environment (figure) XC-459 ToS (type of service) APPN HSRP
XC-373 XC-373 XC-175, XC-223
XC-335
T
Tab key, command completion
xxxiv XC-140
IP IPX traffic
XC-373 XC-373
tag-switching atm disable-headend-vc command tag-switching atm vp-tunnel command tail -end nodes tailend LVC TCP Intercept MLS restrictions TCP/IP defined definition
XC-95 XC-269 XC-89 XC-139 XC-119
broadcast
XC-85 XC-192
configuration (examples)
XC-152
interface configuration to support RSVP-based tunnel signaling and IGP flooding XC-149
XC-121
establishing VCI table entries with LSC redundancy telephony services TLVs
XC-95, XC-96
IS-IS for MPLS traffic engineering, configuring XC-149 MPLS traffic engineering tunnel, configuring
XC-92 XC-150
tunnel support, configuring traffic engineering route tunnel, configuring traffic flow
XC-457 XC-153
MPOA translation
XC-441 XC-97
traffic patterns
XC-459
MPC to MPC Shortcut in an IP Routed Environment (figure) XC-459 MPC to MPC Shortcut in an IP SRB-Routed Environment (figure) XC-463
XC-321
encapsulation
XC-330
XC-488
Index
TRISL (Token Ring Inter-Switch Link) IPX RIF configuration (example) TrBRF VLANs configuration (example) TRISL and Ethernet VLANs configuration (example) configuration (example) AppleTalk benefits
XC-373 XC-373 XC-343 XC-342 XC-342, XC-345 XC-332 XC-333
V
VCC types (figure) VCCs VINES fast switching disabling
XC-16 XC-326 XC-16 XC-367 XC-439, XC-445 XC-96
encapsulation
video conferencing
XC-326
XC-335, XC-347
XC-374
VLAN configuration (example) NetFlow distributed switching virtual channel identifier table entries, establishing virtual circuits
XC-174 XC-85
XC-72
XC-401, XC-403
XC-136
U
user EXEC mode, summary of
xxxiv
defining more than one for edge LSRs virtual trunks bandwidth configuring definition
XC-138
XC-138
XC-138
redundancy, adding
XC-489
Index
LAN segmentation Layer 2 translation Layer 3 routing load balancing native VLAN ID network changes design
XC-326 XC-318 XC-318
XC-321 XC-318
subinterface customization AppleTalk Phase II support Banyan VINES support broadcast domain colors
XC-318
management QoS
XC-313
XC-313
communication between
connecting Fast Ethernet devices DECnet over ISL encapsulation DECnet support description
XC-321 XC-311
XC-321
routers in
IEEE 802.10 encapsulation IEEE 802.1Q encapsulation BPDU reception egress rules ingress rules restrictions interoperability IP
XC-321, XC-330 XC-317
BPDU transmission
XC-314
XC-317
XC-314
XC-349
XC-490
Index
XC-115
XC-112
point-to-point
IBGP distribution
XC-96 XC-96
multiple packets
X
XC-166
operation, verifying
XC-96
XC-17
LANE support
exchanging between sub-autonomous systems in a confederation XC-164 partitioning solutions traffic VRF table
XC-96 XC-166 XC-96 XC-95
XC-373
XC-126
VSI (Virtual Switch Interface) Cisco 6400 UAC, configuring for control interface protocol VTP domain IPX MLS adding VTP domain interface
XC-294 XC-178 XC-180 XC-180 XC-126 XC-136
W
warm standby routing web hosting
XC-96 XC-122
WFQ (weighted fair queueing) as a QoS building block wildcards LANE address templates as a QoS building block
XC-376 XC-167
XC-491
Index
XC-492